RAG-система может найти подходящий документ и всё равно дать неподтверждённый ответ. Причина часто не в самой языковой модели: ответ может выйти за пределы retrieved-фрагментов, потерять важное условие или уверенно заполнить пробел догадкой. Проверить, насколько RAG-ответ опирается на источники, можно небольшим набором запросов с заранее размеченными фактами и контекстом.
Такой тест отвечает на узкий практический вопрос: достаточно ли найденных фрагментов для ответа и действительно ли каждый существенный тезис следует из них? Для этого отдельно оценивают полноту поиска, соответствие ответа контексту и поведение системы, когда источники не дают ответа. Метрики помогают сравнивать версии, но не заменяют проверку конкретных ошибок.
Что именно означает «ответ подтверждён источником»
Сначала разделите три компонента RAG: запрос, найденный контекст и итоговый ответ. Оценка только текста ответа не показывает, возникла ли ошибка на этапе поиска или генерации.
Например, пользователь спрашивает: «Сколько дней даётся на возврат?» В документе сказано: «Возврат возможен в течение 30 дней после доставки, за исключением товаров из категории X». Если модель отвечает «30 дней» без оговорки, число подтверждено, но ответ может вводить в заблуждение для товара из исключённой категории. Если нужная категория не указана в запросе, полезный ответ должен сохранить условие или уточнить обстоятельства.
Разбейте ответ на атомарные утверждения: сроки, числа, названия, ограничения, причинно-следственные связи и рекомендации. Для каждого отметьте, какой именно фрагмент его подтверждает. Утверждение может быть:
- подтверждено контекстом;
- противоречит контексту;
- не подтверждено найденными материалами;
- требует дополнительного источника или уточнения запроса.
Последние два статуса важно не объединять. Тезис может быть верным в реальности, но если система не получила подтверждающий фрагмент, конкретный RAG-прогон не обосновывает его.
Как проверить RAG-ответ на подтверждение контекстом
Соберите компактный набор запросов из реальных сценариев: вопросы с прямым фактом, вопрос с исключением, вопрос, требующий объединить два фрагмента, и запрос, ответа на который в базе нет. Для каждого зафиксируйте ожидаемый ответ и документы, которые должны его обосновать.
Запускайте запрос через полный конвейер и сохраняйте не только финальный текст, но и найденные фрагменты с идентификаторами документов. Затем разбейте ответ на утверждения и сопоставьте их с контекстом. Практическая ручная таблица может выглядеть так:
| Утверждение ответа | Подтверждающий фрагмент | Результат |
|---|---|---|
| Возврат возможен в течение 30 дней | Документ A: «в течение 30 дней после доставки» | Подтверждено |
| Правило действует для всех товаров | В найденном отрывке нет такого условия | Не подтверждено |
| Отсчёт начинается с даты заказа | Документ говорит о доставке | Противоречит |
Для небольшого теста этого достаточно, чтобы заметить типичные ошибки: модель добавляет условие от себя, подменяет дату отсчёта или превращает частный случай в общее правило. Считайте результат отдельно для каждого вопроса, а затем сводите показатели по всему набору. Один средний балл может скрыть критический провал на вопросах о сроках или исключениях.
Три измерения: полнота поиска, точность контекста и опора ответа
Документация Ragas описывает метрики, которые разделяют разные части оценки. Faithfulness оценивает, подтверждаются ли утверждения ответа предоставленным контекстом. Context recall связан с тем, удалось ли извлечь информацию, необходимую для эталонного ответа. Context precision оценивает, насколько найденный контекст релевантен, а не заполнен лишними фрагментами.
Это не взаимозаменяемые показатели:
- Низкая полнота контекста может означать, что поиск не извлёк нужный фрагмент. Генератору нечем надёжно ответить.
- Низкая точность контекста указывает, что среди извлечённых отрывков много нерелевантного. Они увеличивают шум и могут сбить модель.
- Низкая faithfulness означает, что ответ содержит тезисы, которых не подтверждают переданные модели материалы.
Высокая оценка по одной метрике не гарантирует качественную систему целиком. Например, модель может строго пересказывать один найденный фрагмент, но пропустить документ с ключевым исключением. Тогда ответ выглядит grounded, однако сам поиск неполон.
В исследовании RAGAS авторы предложили оценивать RAG-конвейеры через автоматизированные метрики, используя вопросы, ответы и контекст. Это полезная основа для сравнения, но автоматическая оценка зависит от качества исходных примеров, используемой модели-судьи и формулировок критериев. Не интерпретируйте один score как сертификат достоверности.
Минимальный воспроизводимый набор тестов
Создайте файл, в котором у каждого теста есть вопрос, ожидаемые факты, обязательные фрагменты и условие отказа. Полезны четыре типа примеров:
Прямой факт. Ответ содержится в одном коротком фрагменте.
Исключение. Общее правило сопровождается оговоркой, которую легко пропустить.
3. Объединение сведений. Ответ требует связать данные из двух документов.
4. Нет ответа. В базе нет нужного факта, либо доступные материалы не позволяют выбрать однозначный вариант.
Для каждого запуска сохраняйте версию индекса, настройки retrieval, промпт генерации, модель и дату прогона. Иначе сравнение изменений будет неоднозначным: результат мог измениться из-за другой модели, а не из-за обновлённого разбиения документов.
Минимальная запись для одного примера может выглядеть так:
json
{
«question»: «Сколько дней действует правило и для каких товаров есть исключение?»,
«expected_claims»: [
«Срок составляет 30 дней после доставки»,
«Товары категории X исключены»
],
«required_sources»: [«policy-returns»],
«answerable»: true
}
Проверяйте именно тот текст и те фрагменты, которые увидит пользователь или генератор. Если поисковый слой вернул только часть предложения, потерял заголовок раздела или не передал дату публикации, оценка по полному документу даст слишком оптимистичную картину.
Как отдельно измерить ошибки поиска и генерации
Если итоговый ответ ошибочен, проверьте контекст до того, как менять промпт. Есть два разных случая:
Нужного подтверждения нет среди найденных отрывков. Это прежде всего проблема retrieval, индексации или разбиения на фрагменты. Проверьте, присутствует ли документ в индексе, подходят ли размер и перекрытие чанков, не теряются ли заголовки и метаданные. Затем повторите запрос с эталонным документом: если модель отвечает правильно при наличии нужного отрывка, причина, вероятно, выше по конвейеру.
Подтверждение есть, но модель добавляет неподдержанный тезис. Это ошибка генерации или инструкции. Сравните ответ при неизменном контексте, попросите модель указывать доказательный фрагмент и обозначать неизвестное. Но не считайте более строгий промпт исправлением, пока не повторите весь набор тестов: он может снизить число догадок и одновременно увеличить необоснованные отказы.
Полезен контрольный прогон с вручную подставленным эталонным контекстом. Он отделяет способность модели работать с доказательством от способности поиска его найти. Такой тест не отражает поведение системы целиком; он нужен для диагностики конкретного сбоя.
Как обрабатывать вопросы без ответа в базе
Добавьте примеры, где ответ отсутствует, противоречив или зависит от недостающей детали. Успешное поведение — не обязательно фраза «не знаю»: система может запросить уточнение или сказать, какой именно источник не содержит нужных данных.
Для каждого такого примера проверьте три вещи:
- не выдумывает ли модель число, срок или правило;
- отделяет ли предположение от факта;
- не выдаёт ли общие знания за результат поиска по конкретной базе.
Оценивать отказ лучше по заранее заданному критерию. Например, ответ засчитывается, если он прямо указывает на отсутствие подтверждения в предоставленных материалах и не подставляет неподтверждённый факт. Отказ на вопрос, где ответ явно есть в контексте, тоже является ошибкой: чрезмерно осторожная система может быть безопасной на вид, но бесполезной для пользователя.
Не полагайтесь только на то, что модель сама проставляет цитаты. Ссылку можно сформировать без действительной связи между источником и тезисом. Сверяйте каждое существенное утверждение с цитируемым отрывком; проверяйте, что фрагмент действительно доступен по указанному идентификатору и содержит нужное условие.
Когда автоматическая оценка полезна, а когда нужен редактор
Автоматический оценщик удобен для повторного прогона большого набора после смены модели, индекса или параметров поиска. Он помогает выявить регрессии и отсортировать подозрительные ответы для ручного разбора. При этом оценки могут зависеть от формулировки вопроса, языка, длины ответа и выбранного оценщика.
Проверьте автоматическую разметку на вручную оценённой выборке — особенно на отрицаниях, исключениях, датах и числах. Если судья считает пересказ равнозначным подтверждению, хотя в ответе потеряна важная оговорка, доработайте критерий или дополняйте оценку проверками правил. Для русскоязычных документов отдельно включите примеры со склонениями, сокращениями и вариантами написания названий: совпадение слов само по себе не доказывает совпадение смысла.
Для разработки удобно хранить результаты каждого прогона в одном формате: входной запрос, retrieved-фрагменты, ответ, разметка утверждений, показатели и конфигурация системы. В качестве библиотеки для экспериментов можно рассмотреть Sentence Transformers, но оценочная обвязка не заменяет собственный набор проверенных примеров. Важнее, чтобы команда могла повторить тест и понять, какой этап изменился.
Что проверить перед тем, как доверять результату
Перед сравнением версий убедитесь, что тестовый набор отражает реальные пользовательские вопросы, а эталонные ответы и источники проверены человеком. Повторите прогон при фиксированных настройках и отдельно разберите случаи, где метрики разошлись: высокая опора ответа при неполном контексте, например, не означает, что система нашла всё необходимое.
Для практической проверки достаточно начать с небольшой выборки, включить вопросы с исключениями и отсутствующим ответом и вручную сопоставить утверждения с отрывками. Затем автоматизируйте повторные прогоны и оставьте человеку проверку наиболее рискованных классов ошибок. Итоговый отчёт должен показывать не только среднюю оценку, но и конкретные неподтверждённые тезисы, пропущенные источники и ложные отказы.
