RAG нашёл документ, но ответил неверно: где искать ошибку

Внутренний ИИ-помощник уверенно пересказывает правила возврата, но ссылается на прошлогоднюю редакцию. Замена модели может ничего не исправить: в запрос уже попал устаревший документ. В другом случае поиск находит нужный пункт, а ответ теряет оговорку о сроке. Внешне обе ошибки похожи, однако чинить нужно разные части системы.

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

Начните с вопроса, на который помощник ошибается

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

Для такого разбора полезен небольшой журнал: вопрос, ожидаемый документ и пункт, найденные фрагменты, ответ, вид ошибки. Это не попытка заранее написать все ответы за ИИ. Вы фиксируете критерий приемки: какой факт должен сохраниться и на какой источник сотрудник сможет сослаться. Отдельно помечайте вопросы, на которые в базе вообще нет ответа. Корректный отказ на них тоже результат.

Разделение качества поиска и качества генерации лежит в основе исследовательской работы RAGAs. Авторы предложили оценивать несколько сторон RAG, в том числе без заранее размеченных эталонных ответов. Для рабочей системы такие оценки удобны как сигнал для проверки; они не освобождают владельца регламента от просмотра спорных случаев.

Проверьте, что вы положили в индекс

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

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

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

Когда имеет смысл усложнять поиск

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

Разбор Meilisearch описывает реранкинг как отдельный этап и обращает внимание на цену дополнительной задержки. Практический вопрос для вашей базы проще: стали ли нужные пункты попадать в контекст чаще и насколько выросло время ответа? Сравнивайте изменения на одной выборке вопросов. Если одновременно сменить модель, разбиение документов и поиск, причину улучшения будет трудно установить.

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

Если нужен помощник для команды с поиском по внутренним материалам, на странице ИИ-ассистентов PROMAREN можно обсудить задачу и требования к внедрению. Для такого разговора полезнее принести несколько неудачных ответов с источниками, чем общий запрос «сделать ИИ точнее».

Три проверки, которые нельзя свести к одному баллу

Первая — нашёлся ли нужный материал. В Ragas метрика context precision оценивает расположение релевантных фрагментов в выдаче. Но высокая точность ещё не означает, что найдено всё необходимое. В нашем примере общий регламент может быть релевантным, а исключение отсутствовать. Поэтому отдельно проверьте полноту: все ли условия для ответа представлены в контексте.

Вторая — подтверждается ли ответ найденным текстом. Метрика faithfulness проверяет опору утверждений ответа на переданный контекст. Она не устанавливает истинность самого документа. Если в базе устаревшее правило, согласованный с ним ответ может получить хорошую оценку и всё равно навредить работе. Проверка актуальности источника остаётся отдельной задачей.

Третья — решена ли задача пользователя. Ответ может аккуратно пересказывать документ и не сообщать, что делать в конкретной ситуации. Для каждого контрольного вопроса запишите ожидаемое действие: найти срок, объяснить исключение, назвать ответственного или передать вопрос специалисту. Проверяющий должен видеть, где ответ помогает принять решение, а где только создаёт впечатление осведомлённости.

Автоматическая оценка тоже зависит от настроек и модели, которая её выставляет. Для сравнения версий сохраняйте одинаковые условия проверки и просматривайте примеры вручную. Особое внимание уделите расхождениям: когда балл вырос, а ответ стал менее полезным, или когда оценщик наказал правильный отказ вместо выдуманного ответа.

Как принять первую рабочую версию

Для стартового прогона можно взять двадцать-тридцать реальных вопросов из обращений команды. Это рабочая рекомендация для первого разбора, а не достаточная статистическая выборка для доказательства качества. Включите простые вопросы, исключения, запросы без ответа и случаи с ограниченным доступом. Владелец базы должен проверить ожидаемые документы до сравнения вариантов.

Сохраняйте время ответа и стоимость вместе с качеством. Условный пример: реранкер исправил два важных вопроса, но заметно увеличил ожидание. Для внутреннего справочника такой обмен может подойти, для короткого клиентского диалога — потребовать другой настройки. Порог приемки определяют требования конкретного сервиса, а не чужой красивый процент.

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