Как разбор RAG-сбоев снижает долю необоснованных ответов с 34% до 9%

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

Главная мысль материала проста: одинаково неверный ответ может быть следствием разных поломок. Поиск мог не найти документ. Чанкинг мог разорвать важное утверждение. Реранкер мог поднять наверх похожий, но неподходящий фрагмент. Наконец, модель могла получить правильный контекст, проигнорировать его и ответить по памяти. Для каждого случая нужен свой ремонт.

Один ответ — три возможные поломки

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

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

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

Абляция показывает, что действительно повлияло на ответ

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

Затем ответ разбивают на отдельные проверяемые утверждения. Для каждого числа, срока, цены и действия требуется конкретный подтверждающий фрагмент. Простого упоминания сущности недостаточно: документ со словом «Берлин» ещё не доказывает, что Берлин назван там столицей Германии.

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

Что внедрить в рабочий RAG

Минимальный набор наблюдаемости — логировать запрос, top-k найденных фрагментов, их оценки и итоговый промпт. Для размеченных запросов полезно считать Recall@k: оказался ли нужный фрагмент среди результатов поиска. Эту метрику лучше измерять на реальном трафике, а не только на аккуратных синтетических примерах.

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

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

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