Галлюцинация в RAG-системе почти никогда не связана с «плохой моделью». В большинстве случаев причина в качестве поиска: релевантный фрагмент не попал в контекст, а модель, обязанная ответить, достроила ответ по смыслу. Поэтому работа с качеством начинается не с промпта, а с данных и архитектуры поиска.

Почему RAG ошибается на внутренних документах

Типичные причины: нарезка по 1000 символов «по пробелам», которая рвёт таблицы и пункты регламента; отсутствие метаданных (версия документа, подразделение, дата вступления в силу); поиск только по векторной близости без учёта точных терминов вроде «п. 4.2.1» или артикулов номенклатуры.

Отдельная проблема — сканы и PDF. Если OCR прочитал «ЗАО» как «340», а таблицу разбил на строки без заголовков, поиск по этому фрагменту не сработает никогда. Мусор в индексе — прямой путь к уверенным неверным ответам.

Три уровня контроля

Первый — retrieval, второй — генерация, третий — верификация ответа.

На уровне retrieval нужны структурная нарезка (по заголовкам и пунктам, а не по символам), гибридный поиск BM25 + вектор, реранкер и фильтры по метаданным. Кандидатов до реранка стоит брать с запасом — 20–50 фрагментов, иначе нужный пункт не доживёт до финального top-k.

На уровне генерации — жёсткий системный промпт: отвечать только по переданным фрагментам, ссылаться на источник, при отсутствии данных писать «в документах нет ответа». Модель должна иметь право отказаться, иначе она будет выдумывать.

На уровне верификации — постпроверка: цитаты в ответе сверяются с контекстом, каждый факт должен быть подтверждён фрагментом. Это делается дешёвой моделью или правилами и отсекает большую часть выдумок до показа пользователю.

Практические шаги

1. Соберите золотой набор: 100–300 реальных вопросов сотрудников с эталонными ответами и указанием документа-источника. Без него вы не измеряете качество, а обсуждаете впечатления.
2. Замерьте baseline: recall@10, точность цитат, доля корректных отказов.
3. Почините парсинг и нарезку — это даёт наибольший прирост при наименьших затратах.
4. Добавьте гибридный поиск и реранкер, проверьте прирост на золотом наборе.
5. Настройте промпт с обязательной ссылкой на пункт документа.
6. Введите регрессионные тесты: каждое изменение промпта или индекса прогоняется через золотой набор в CI.

Метрики, которые стоит смотреть

Ключевые метрики поиска — recall@k и MRR. Для генерации — faithfulness (доля утверждений, подтверждённых контекстом) и answer relevance. Для продукта — доля отказов и доля эскалаций на оператора: рост отказов при падении эскалаций означает, что модель научилась честно молчать.

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

Российская специфика

В российских компаниях основной массив — это сканы, DOCX с ручной вёрсткой, выгрузки из 1С и ЭДО, регламенты с версиями и приложениями. Часто всё это лежит в закрытом контуре без доступа к внешним API, поэтому OCR, эмбеддинги и реранкер должны работать локально, а данные не покидать периметр — этого требуют 152-ФЗ и внутренняя ИБ.

Практика показывает: локальные модели (bge-m3, e5, ru-en-RoSBERTa) на доменных данных дают качество не хуже облачных, если дообучить их на парах «вопрос — фрагмент» из вашей же базы. Дообучение на 2–5 тыс. таких пар обычно поднимает recall@10 на 15–30%.

Как мы можем помочь

Мы собираем RAG-контуры под ключ: аудит и парсинг документов, локальные модели и реранкеры, гибридный поиск, цитирование источников, золотой набор и регрессионные тесты в CI. Работаем в закрытом контуре и встраиваем ответы в 1С, CRM и корпоративный портал. Обсудить проект