Почему RAG придумывает ответы по документам компании и как найти причину

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

RAG (Retrieval Augmented Generation) означает генерацию с поиском: система сначала находит в ваших документах релевантные фрагменты, затем передает их модели вместе с вопросом.

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

Сначала определите тип ошибки

Жалоба «бот придумывает» описывает симптом, а не причину. Прежде чем что-либо изменять, разберите несколько реальных неправильных ответов и отнесите каждый к одному из типов.

Факта нет в документах. Ответа на вопросы в базе знаний просто нет, а модель его сформулировала. Здесь проблема не в поиске, а в том, что система не умеет честно говорить "в документах этого нет".

Устаревший документ. Факт есть, но в старой версии регламента, а новая версия либо не попала в индекс, либо существует рядом со старой.

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

Неправильный вывод. Модель получила правильный фрагмент, но ответила не за ним: смешала с другим, пропустила условие, повторила общее знание вместо текста документа.

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

Учебный пример: политика возврата

Пример вымышлен. Компания сменила политику возврата товара: раньше срок был 14 дней, теперь 30. Через неделю после обновления бот поддержки отвечает клиентам «14 дней». Причина одинаковым ответом не определяется. Рассмотрим три разных сбоя, каждый из которых дает именно этот ответ.

Сбой 1. В индекс попал старый файл. Новую версию регламента положили в другую папку, которую индексация не охватывает. В индексе есть только документ с 14 днями. Модель отвечает правильно за тем, что получила. Исправление: процесс обновления источников. Новый документ должен заменять старый в индексе, а старый должен быть удален или помечен как недействительный.

Сбой 2. Поиск вернул обе версии без даты. В индексе есть и старый, и новый документ. Поиск возвращает оба фрагмента, а в тексте фрагментов нет ни даты, ни номера версии. Модель видит две противоречивые цифры и выбирает одну. Исправление: метаданные. Каждый фрагмент должен нести дату вступления в силу и статуса документа, а поиск должен отфильтровывать недействительные версии до того, как фрагменты попадут в модель.

Сбой 3. Модель получила новую версию, но повторила старое правило. Поиск сработал правильно, в контексте только новый документ с 30 днями. Но модель ответила «14 дней», например, потому, что отвечала из общего представления о типовых условиях возврата, а не из текста. Исправление: генерация. Требовать ответ с цитатой из данного фрагмента, проверять, что число в ответе совпадает с числом во фрагменте, и тестировать этот сценарий отдельно.

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

Проверьте исходный документ

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

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

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

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

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

Права доступа. Имеет ли система доступ к нужному документу? Убедитесь, что текущий пользователь имеет право на документ. Если права нет, корректное поведение – не раскрыть документ; такой случай не исправляется расширением доступа только для полноты ответа.

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

Проверьте поиск и составление контекста

Если документ правильный и в индексе есть, следующий вопрос: нашел ли его поиск и дошел ли найденный фрагмент модели в пригодном виде.

Поиск

Для проблемного вопроса посмотрите, какие фрагменты вернули поиск, в каком порядке и с какими оценками сходства. Ответ на три вопроса:

1. Необходим ли фрагмент среди результатов? Если нет, проблема в поиске: в том, как документ разбит на фрагменты, в формулировке запроса, в настройках поиска.
2. На какой он позиции? Если нужный фрагмент есть, но на десятом месте после девяти нерелевантных, в контекст он может не попасть из-за ограничения количества фрагментов.
3. Не заглушен ли он шумом? Методика OpenAI отдельно называет ситуацию, когда слишком много нерелевантного контекста заглушает правильную информацию и вызывает вымышленные ответы.

Составление контекста

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

• Обрезка. Найдено десять фрагментов, а в запрос попали пять. Был ли среди них нужен?
• Потеря метаданных. Дата и статус документа были в индексе, но не попали в текст, который видит модель.
• Позиция в длинном контексте. Исследование Lost in the Middle (2023) на двух задачах, поиске ответа в нескольких документах и ​​поиске значения по ключу показало U-образную зависимость. Качество было самым высоким, когда нужная информация стояла в начале или конце контекста, и заметно падала, когда она была посередине. Авторы отмечают, что спад сохранялся даже для моделей, специально предназначенных для долгого контекста. Это результат для исследованных на тот момент моделей и задач, а не характеристика всех современных моделей. Но это аргумент проверить на вашей системе, влияет ли позиция фрагмента на ответ.

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

Проверьте генерацию

Если правильный фрагмент дошел до модели в подходящем виде, а ответ неверен, проблема в генерации.

Метод проверки прост и трудоемок: сопоставьте каждое значимое утверждение ответа с текстом представленных фрагментов. Значимыми числятся числа, сроки, условия, исключения, наименования документов. Для каждого определите одно из трех:

• подтверждено: есть во фрагменте и передано правильно;
• искаженное: есть во фрагменте, но передано с ошибкой (другое число, пропущенное условие);
• неподтверждено: во фрагментах этого нет, модель добавила от себя.

Искаженные и неподтвержденные утверждения указывают на проблемы генерации. Типичные исправления: более четкая инструкция отвечать только по предоставленному тексту и говорить, когда ответа нет; требование цитировать фрагмент; проверка формата ответа кодом; отдельные тесты на числа и сроки. Методика OpenAI для проблем такого типа советует сначала работать с инструкциями, а доучение рассматривать, если примеры улучшают точность.

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

Таблица диагностики

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

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

Измерьте исправление

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

Контрольная выборка. Набор вопросов с эталонными ответами, которые проверили люди, знающие предмет. Методика OpenAI рекомендует строить набор вопросов с эталонными ответами еще до оптимизации и упоминает ориентир от 20 вопросов для начальной работы с инструкциями. Включите в выборку вопрос всех четырех типов ошибок, в частности вопрос, ответ на который в документах нет.

Что считать. Не только часть правильных ответов. Отдельно считайте корректные отказы (система честно сказала, что ответа нет), ложные отказы (ответ был, а система отказала) и неправильные ответы. Исправление, которое уменьшает выдумки ценой того, что бот отказывает на половину вопросов, может быть хуже начального состояния.

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

Автоматическая оценка. Инструменты типа Ragas предлагают оценивать отдельно три аспекта: находит ли поиск релевантные и сфокусированные фрагменты, или модель использует их достоверно, и качество самого ответа. Авторы описывают эти метрики как не требующие эталонных аннотаций от людей. Это удобно для частых прогонов. В исследовании Ragas оценка реализована через запросы к LLM; это не независимое доказательство истинности. К тому же faithfulness означает соответствие предоставленному контексту: если именно источник устаревший, высокая оценка согласованности еще не делает ответ правильным. Сверяйте автоматические оценки с эталонными ответами и ручной выборочной проверкой людьми, особенно для вопросов, где ошибка стоит дорого: деньги, сроки, юридические условия.

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

Организуйте обратную связь

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

Что хранить для каждой ошибки:

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

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

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

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

Что сделать в ближайшее время:

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

Часто задаваемые вопросы