Почему RAG отвечает неверно: диагностика по шагам от документа до ответа

Первый вопрос диагностики: ошибка поиска или ошибка ответа

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

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

Не меняйте модель, пока не знаете, нашёл ли поиск нужный фрагмент.

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

Как измерять: золотой набор и две метрики

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

• Найден ли нужный фрагмент. Для каждого вопроса проверяем, попал ли правильный фрагмент в число найденных (например, в первые пять). Это метрика поиска, её часто называют полнотой на k.
• Верен ли ответ при правильном контексте. Подаём модели заведомо правильный фрагмент и смотрим, ответит ли она верно. Это проверка генерации отдельно от поиска.
• Честный отказ. В набор добавляем вопросы, ответа на которые в базе нет. Правильное поведение — отказ.
• Верная ссылка. Указан ли именно тот документ и пункт.

Две первые метрики вместе показывают, где проблема: если поиск находит нужное редко, чиним поиск; если находит, а ответы неверны, чиним генерацию. Набор запускают после каждого изменения, иначе правка одного вопроса незаметно ломает другие. Как проводить такую проверку у агентов в целом, описано в статье «Как оценить качество AI-агента».

Шесть участков, где ломается RAG

1. Данные: документа нет, он устарел или плохо читается

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

2. Нарезка: фрагмент без контекста или слишком большой

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

• Резать по смыслу (раздел, пункт, строка таблицы), а не по числу символов.
• Хранить вместе с фрагментом название документа, заголовки разделов и номер пункта.
• Таблицы резать по строкам, добавляя заголовки столбцов в каждую.
• Для длинных документов хранить связь «фрагмент — родительский раздел», чтобы при необходимости подтянуть соседний текст.

3. Поиск: только по смыслу или только по словам

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

4. Вопрос: короткий, неоднозначный или зависит от истории

Пользователи пишут «а сколько?» или «и для командировок?», где смысл лежит в предыдущей реплике. Поиск по такому тексту бесполезен. Помогают переписывание вопроса с учётом истории («сколько дней отпуска положено при командировке») и уточняющий вопрос системы, когда вопрос неоднозначен. Для длинных диалогов важно, как устроена память, см. «Память AI-агента».

5. Ранжирование и сборка запроса: нужное найдено, но потерялось

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

6. Генерация: модель достраивает или игнорирует контекст

Даже при правильном контексте модель иногда отвечает «из общих знаний», склеивает два противоречивых фрагмента или обобщает условие там, где оно относилось к частному случаю. Что помогает: инструкция отвечать только по найденному, требование цитаты, проверка кодом, что цитата есть в источнике, и явный отказ при отсутствии ответа. Как писать такие инструкции, разобрано в статье «Системный промпт AI-агента».

Симптомы и лечение: таблица для быстрой диагностики

Чего делать не стоит

• Менять модель первым делом. Это самое дорогое действие с самым непонятным результатом. Сначала проверьте, находит ли поиск нужное.
• Увеличивать число фрагментов без измерения. Больше контекста не значит лучше, часто результат ухудшается и цена растёт.
• Добавлять документы «на всякий случай». Мусор в индексе вытесняет нужное. Лучше меньше документов, но актуальных и с владельцем.
• Лечить симптомы в промпте. Фраза «не ошибайся» не заменяет исправление нарезки или поиска. Правка промпта под один вопрос обычно ломает другой.
• Судить по нескольким диалогам. Без золотого набора невозможно понять, стало ли лучше.

Если система работает внутри вашего контура, к этому добавляются свои вопросы про мощность и качество открытых моделей: «Локальные LLM для AI-агентов».

Порядок работ, когда качество не устраивает

1. Собрать золотой набор вопросов с известными источниками и добавить вопросы без ответа.
2. Измерить две метрики: находит ли поиск нужный фрагмент и верен ли ответ при правильном контексте.
3. Начать с данных: версии, дубли, плохие сканы, права.
4. Затем нарезка: контекст фрагмента, таблицы, заголовки.
5. Затем поиск: сочетание по смыслу и по словам, фильтры по метаданным, переписывание вопроса.
6. Затем ранжирование и сборка запроса: реранкер, число фрагментов, порядок.
7. И только после этого инструкция и модель: формат, цитата, отказ, проверка кодом.
8. После каждого шага прогонять золотой набор и фиксировать результат.

Эта последовательность стоит в основе того, как мы настраиваем ИИ-ассистента по базе знаний. Выбор между поиском по документам и дообучением модели обсуждается в статье «Дообучение или RAG».