Что такое RAG — на примере папки с документами

Представьте папку с двумястами договорами, инструкциями и протоколами встреч. Сотрудник спрашивает: «Какой срок уведомления о расторжении у клиента “Север”?» Обычная языковая модель не видит вашу папку и может только угадать типичный срок. RAG-система сначала ищет нужный договор и пункт, а уже потом формулирует ответ.

Аббревиатура расшифровывается как Retrieval-Augmented Generation — генерация, дополненная поиском. Важны обе части: поиск должен принести правильный контекст, а модель — аккуратно использовать его.

Как это работает

В простом варианте процесс состоит из пяти этапов.

1. Подготовка документов

Система извлекает текст из PDF, Word, таблиц или веб-страниц. Уже здесь возникают ошибки: скан может плохо распознаться, таблица — потерять заголовки, а колонтитул — повториться на каждой странице.

Поэтому до «умного поиска» полезно проверить несколько документов вручную. Если исходный текст испорчен, модель не восстановит надёжно то, чего не увидела.

2. Деление на фрагменты

Документ редко кладут в поиск целиком. Его делят на небольшие части — chunks. Слишком короткий фрагмент теряет контекст, слишком длинный содержит много лишнего и расходует окно контекста.

Хорошее деление учитывает структуру: заголовки, пункты договора, строки таблицы, вопросы и ответы. Абзац «Срок — 30 дней» бесполезен, если рядом не осталось название условия, к которому он относится.

3. Индексация

Каждый фрагмент превращается в числовое представление смысла — embedding — и сохраняется в поисковом индексе. Запрос пользователя преобразуется таким же способом. Система ищет близкие по смыслу фрагменты, даже если в них использованы другие слова.

Например, запрос «как прекратить договор» может найти пункт «порядок одностороннего расторжения», хотя формулировки не совпадают буквально.

4. Формирование контекста

Найденные фрагменты вместе с вопросом передаются модели. Часто сюда добавляют название файла, номер страницы, дату документа и инструкцию не отвечать при недостатке данных.

Метаданные важны не меньше текста. Если действующая и устаревшая инструкции попали в один индекс без даты, поиск может вернуть обе.

5. Генерация ответа

Модель соединяет найденные сведения в понятный ответ и, в хорошем интерфейсе, показывает ссылки на исходные места. Это не отменяет проверку: модель может неверно объединить два фрагмента или сделать вывод, которого прямо нет в документах.

Этап	Типичная ошибка	Как обнаружить
Извлечение	Пропали таблицы, подписи или часть скана	Сравнить текст с оригиналом
Фрагментация	Условие отделилось от заголовка	Посмотреть найденный chunk целиком
Поиск	Вернулся похожий, но не тот документ	Проверить файл, дату и раздел
Генерация	Модель добавила неподтверждённый вывод	Сопоставить каждое утверждение с цитатой

Чем RAG отличается от загрузки файла в чат

Если вы прикрепили один договор и задали вопрос, интерфейс может передать файл модели целиком или тоже использовать внутренний поиск. Для пользователя это выглядит одинаково, но при большой библиотеке разница становится существенной.

RAG нужен, когда документов больше, чем разумно помещать в один запрос, они регулярно обновляются или ответы должны ссылаться на конкретные места. Система индексирует библиотеку заранее и в каждый запрос подставляет только наиболее подходящие части.

Это также отличается от дообучения. Fine-tuning меняет поведение модели на примерах, а RAG подставляет актуальные знания во время ответа. Для справочников, политик и договоров обычно важнее обновляемость и цитаты, поэтому поиск подходит лучше.

Пример: база внутренних правил

Допустим, в компании есть папки «Отпуска», «Командировки» и «Закупки». Пользователь спрашивает: «Можно ли самому купить билет и получить компенсацию?»

Хорошая система должна:

1. Найти действующую политику командировок, а не старый приказ.
2. Вернуть пункт о самостоятельной покупке.
3. Подтянуть связанное ограничение по классу билета.
4. Указать исключения и необходимое согласование.
5. Дать ссылку на файл и страницы.

Если поиск вернул только фразу «расходы компенсируются», модель может уверенно сказать «да» и пропустить условия. Это классическая ошибка: ответ звучит разумно, но контекст был неполным.

Как задавать вопросы RAG-системе

Полезно сразу потребовать доказательства и границы ответа.

Ответь только по приложенным документам.

Вопрос: [вопрос]

Для каждого вывода укажи:
- название файла;
- раздел или страницу;
- короткую подтверждающую цитату.

Если документы противоречат друг другу,
покажи обе версии и их даты.

Если ответа нет, напиши «в документах не найдено»
и перечисли, какой информации не хватает.

Такой промпт не исправит плохой поиск, но сделает пробелы заметнее.

Как проверить RAG до запуска

Соберите 30–50 реальных вопросов: простых, сложных и провокационных. Для каждого заранее отметьте правильный документ и минимальные элементы ответа.

Проверяйте отдельно:

• retrieval recall — попал ли нужный фрагмент в найденные;
• точность источника — не выбран ли устаревший или чужой документ;
• faithfulness — подтверждается ли ответ переданным контекстом;
• полезность — помогает ли формулировка решить задачу;
• отказ — умеет ли система честно не отвечать при отсутствии данных.

Одна общая оценка скрывает причину ошибки. Если нужный документ не найден, смена языковой модели почти не поможет; нужно чинить индекс, метаданные или формулировку поиска.

Когда RAG не нужен

Не стоит строить поисковую систему ради трёх коротких неизменных файлов. Проще приложить их к запросу или собрать один хорошо структурированный справочник.

RAG также не заменяет:

• базу данных для точных остатков, цен и статусов;
• вычисления, которые должны выполняться программой;
• права доступа к документам;
• редакционный процесс и владельца информации;
• юридическую или профессиональную проверку критичных решений.

Безопасность и права доступа

Поисковый индекс — это ещё одна копия корпоративных данных. Пользователь не должен получать фрагмент только потому, что он семантически похож на запрос. Права нужно применять до передачи текста модели и проверять при каждом поиске.

Не смешивайте общие и конфиденциальные документы в один безусловно доступный индекс. Храните источник, владельца, дату, версию и уровень доступа как обязательные метаданные. Подробнее — в статье «Какие данные нельзя отправлять нейросети».

Главное

RAG полезен не потому, что делает модель всезнающей. Он ограничивает задачу проверяемой библиотекой и даёт возможность показать источник. Хорошая система отвечает не только «что», но и «откуда это взято» — а при отсутствии данных не маскирует пробел уверенным текстом.