RAG простыми словами: где теряется смысл документа
RAG часто объясняют одной фразой: «модель отвечает по вашим документам». В реальной системе между файлом и финальным ответом есть несколько независимых этапов. Документ нужно прочитать, разделить на фрагменты, проиндексировать, найти по запросу, отфильтровать по правам и только потом передать модели. Сбой на любом слое даст уверенный, но неполный ответ. Поэтому RAG — не новая память нейросети, а конвейер поиска и генерации, который можно проверять по частям.
Четыре участника конвейера
Источник — актуальный файл, его версия, владелец и права. Индексатор превращает содержимое в поисковые фрагменты и сохраняет метаданные. Поиск выбирает кандидатов по словам или смыслу запроса. Генератор читает найденный контекст и формулирует ответ. Пользователь видит только последний этап, но исправлять нужно тот, где исчезло условие.
Представьте регламент возврата: «товар принимается в течение 14 дней, кроме случаев с повреждённой упаковкой». Если при разбиении исключение попало в соседний кусок, поиск может вернуть только число 14. Модель честно перескажет полученный фрагмент, но итог будет неправильным для клиента. В таком случае смена модели не решает проблему.
Что происходит с файлом
Перед индексированием зафиксируйте формат, дату и контрольный хэш. Проверьте, читаются ли таблицы, списки, сноски и сканы. Разбивайте текст так, чтобы заголовок и относящееся к нему исключение оставались вместе. Слишком маленькие куски теряют контекст, слишком большие добавляют шум и расходуют лимит окна.
Сохраняйте рядом с каждым фрагментом название документа, номер раздела, дату действия и роль, которой он доступен. Без этих метаданных невозможно показать цитату и отфильтровать закрытый файл. Устаревшую версию удаляйте не только из папки, но и из индекса и кэша.
Как проходит один запрос
Пользователь спрашивает: «Можно ли вернуть товар на 15-й день?» Система преобразует вопрос в поисковый запрос, получает несколько кандидатов и применяет фильтр доступа. Затем в контекст передаются фрагменты с датой и заголовком. Модель должна ответить только на их основании, назвать исключение и указать, если подтверждения нет.
Попросите интерфейс показать найденные фрагменты до генерации, хотя бы в режиме отладки. Если в списке нет нужного пункта, измеряйте поиск, а не красоту текста. Если источник найден, но пересказ неверен, проблема уже на слое генерации или промпта.
Мини-эксперимент на одной базе
Возьмите десять страниц внутренней инструкции и составьте 20 вопросов: восемь прямых, четыре с синонимами, четыре с опечатками и четыре вне области. Для каждого укажите ожидаемый фрагмент и допустимый отказ. Включите вопрос, где ответ разбросан между двумя разделами, и вопрос по старой версии документа.
| Слой | Что записать | Какой дефект ищем |
|---|---|---|
| Чтение файла | число страниц и таблиц | потеря строки или минуса |
| Разбиение | границы фрагментов | отделено исключение |
| Поиск | найденные номера разделов | возвращена старая версия |
| Права | роль тестового пользователя | виден закрытый фрагмент |
| Генерация | цитата и ответ | выдуман факт или пропущено условие |
Повторите набор после изменения размера фрагмента и после обновления индекса. Сравнивайте полноту источника, точность цитаты, долю корректных отказов и время ответа. Не переносите цифры на другую базу: качество RAG зависит от конкретных документов.
Не путайте переформулировку запроса с выдумыванием
Поисковый слой иногда расширяет короткий вопрос синонимами и названием раздела. Это может повысить полноту, но добавляет риск: система способна незаметно изменить намерение пользователя. Сохраняйте исходную формулировку рядом с расширенной и показывайте их в отладочном журнале. На тесте добавьте вопрос с отрицанием и вопрос, где одно слово имеет два значения. Проверьте, что переформулировка не убрала «не», не подставила другую дату и не добавила роль пользователя. Если расширенный запрос приводит к другому документу, остановите генерацию и попросите уточнение. Так поиск остаётся помощником, а не скрытым автором вопроса.
RAG и дообучение — разные задачи
RAG подаёт актуальный текст во время запроса и удобен для регламентов, цен и инструкций. Fine-tuning закрепляет стиль, формат или классификацию, но не является удобным хранилищем еженедельных изменений. Подробное сопоставление ролей описано в материале о RAG и fine-tuning.
Гибридная схема возможна: поиск возвращает факт и источник, а настроенная модель оформляет ответ по шаблону. При этом дата и цитата должны оставаться видимыми, а отсутствие фрагмента — приводить к паузе.
Где RAG не стоит применять в одиночку
Внешние новости, творческие идеи и запросы, требующие свежего поиска в интернете, не решаются внутренним индексом без разрешённого канала обновлений. Для критичных юридических, медицинских и финансовых решений RAG может подготовить черновик, но не заменить специалиста. Модель не проверяет достоверность документа и не знает, что файл устарел, если приложение не передало статус версии.
Права и приватность
Фильтр доступа выполняется до формирования контекста. Запрет нельзя сообщать пользователю через найденный закрытый фрагмент: сам фрагмент не должен попасть в запрос. Обезличивайте документы локально и ограничивайте резервные копии; практический порядок описан в гайде по маскированию.
Проверьте срок хранения запросов, журналов и индекса у внешнего провайдера. Локальное размещение уменьшает передачу данных, но требует защиты диска, ключей и резервных копий. Записывайте версию индекса, чтобы после обновления можно было объяснить изменение ответа.
Итог
RAG полезен, когда нужно дать модели контролируемый контекст и показать человеку основание ответа. Он не исправляет плохие документы, не гарантирует правду и не заменяет редактора. Начните с одной базы, измеряйте чтение, разбиение, поиск, права и генерацию отдельно, а затем повторяйте тест после каждого изменения. Так становится понятно, где действительно помогает поиск, а где лучше оставить обычную инструкцию или ручное решение.