Диагностика сбоев RAG: карта этапов и судья основанности на уровне утверждений
Определите место сбоя в конвейере RAG, затем создайте судью основанности LLM, который будет проверять утверждения по одному и апробироваться с помощью человеческих оценщиков с использованием коэффициента Каппы.
Источники: How to Diagnose RAG Failures with a Groundedness Judge
Когда бот RAG начинает отвечать неправильно
Развертывание приложения RAG — это ещё не конец работы, тем более в производственной среде. Рано или поздно оно начинает давать неверные ответы, и первой задачей становится поиск причины. В системе существует как минимум семь мест, где может произойти скрытая ошибка: разбиение на фрагменты, генерация эмбеддингов, поиск информации, переранжирование результатов, сбор контекста, генерация текста и сам запрос, объединяющий все эти элементы. Плохой окончательный ответ почти ничего не говорит о том, в каком именно момент произошла ошибка. Некоторые инженеры тратили целую неделю на оттачивание формулировки запроса для генерации текста, хотя причиной была ошибка в разбиении данных на фрагменты.
Существует довольно механический способ выявления причин сбоя. Затем возникает вторая проблема — измерение степени обоснованности на крупном масштабе, поскольку анализ каждой транскрипции становится невозможным после этапа проверки концепции. ИИ-модель, действующая в роли судьи, может выполнять эту задачу, но у самих судей тоже бывают сбои, которые так же легко ускользнуть от внимания, как и ошибки RAG, которые они должны выявлять. Оба аспекта рассматриваются ниже: отслеживание причин сбоев до их источника и создание надежного инструмента оценки обоснованности.
Сначала найдите сломанную ссылку
Конвейер RAG представляет собой цепочку, и первой задачей является определение того, какая ссылка вышла из строя, прежде чем кто-либо внесет изменения в запрос. Приведенная ниже схема служит основой для выявления проблемы. Она не является исчерпывающей и может быть доработана под конкретную систему и сценарий использования.
Порядок действий выбран намеренно: сначала устраняются проблемы с поиском, а затем — с генерацией. Инжиниринг промптов не может исправить окно контекста, в котором никогда не было нужных фактов. Команды часто работают в обратном порядке, пять раз переписывая системный промпт, в то время как алгоритм переранжирования понижает значимость того отрывка, который имел бы значение. Недорогие решения с большой отдачей, такие как улучшенное разделение текста на части или гибридный поиск, должны стоять перед дорогостоящими методами, такими как тонкая настройка алгоритма переранжирования или переобучение любых моделей.
Три реальных симптома показывают, как используется эта схема:
- Ответы даются уверенно, хотя документы совсем не касаются темы. Это не поиск, поскольку нет ничего релевантного для получения информации. Это сбой в генерации или отказ от ответа: модель не считает фразу «У меня этого нет» приемлемым ответом.
- Бот предоставляет правдоподобную, но устаревшую информацию. Проблема почти никогда не заключается в разбиении на фрагменты. Индекс устарел, поскольку документы изменились, но никто их не восстановил.
- Вопросы, требующие одного факта, решаются успешно, однако любые вопросы, нуждающиеся в двух фактах из двух документов, терпят неудачу. Это сбой в поиске, характерный для многократных запросов, поскольку один проход поиска не может найти два элемента, каждый из которых сильно отличается от запроса.
Следующий шаг — взять фактически найденный контекст для неудачного примера и прочитать его перед внесением каких-либо изменений. Если факта там нет, проблема в поиске. Если он там есть, но модель всё равно ошибается, проблема в генерации текста. Эта проверка может сэкономить дни.
Что означает основанность
Чтение транскрипций подходит лишь для небольшого числа случаев, но бесполезно при обработке тысяч. Здесь на сцену выходит судья в виде ЯИ, специально разработанный для оценки обоснованности, также известной как верности. Его задача — определить, можно ли каждое утверждение в ответе проследить до какого-либо элемента в полученном контексте.
Одна тонкая деталь сразу мешает людям: обоснованность и корректность — это разные понятия. Истинный ответ может быть необоснованным, например, когда модель знает факт благодаря обучению, а не из документов. Обоснованный ответ может оказаться неверным, если сам отобранный фрагмент был устаревшим или неверным. При оценке технологии RAG важна именно обоснованность, поскольку она показывает, эффективно ли была выполнена задача по поиску информации, независимо от качества исходных документов.
Судья на уровне утверждений
Одно-единственное запросное предложение с просьбой оценить степень обоснованности от 1 до 5 кажется разумным, но на деле бывает практически бесполезным. Оно даёт число без каких-либо пояснений, а именно оценка полного ответа — это та область, в которой ГЛМ проявляют несогласованность. Гораздо эффективнее разбить ответ на отдельные утверждения и проверить каждое из них отдельно.
Исходное запросное предложение содержит указание на роль системы, согласно которой модель выступает в качестве оценщика обоснованности; в нём приводится вопрос, полученный контекст и сгенерированный ответ, а также заранее указывается, что задача не заключается в определении того, верен ли ответ в целом. Затем просится извлечь утверждения и проверить каждое из них по отдельности на соответствие контексту, указывая для каждого вердикт и соответствующий фрагмент текста.
SYSTEM:
You are a groundedness evaluator. You will be given a QUESTION, a CONTEXT
(retrieved passages), and an ANSWER generated by an AI assistant. Your job
is NOT to judge whether the answer is true in general, or well-written, or
relevant — only whether it is fully supported by the CONTEXT.
Do the following:
1. Decompose the ANSWER into a list of atomic claims (each claim = one
discrete factual statement, not a compound sentence).
2. For each claim, decide:
- SUPPORTED: directly stated or reasonably entailed by CONTEXT
- CONTRADICTED: conflicts with CONTEXT
- UNSUPPORTED: not addressed by CONTEXT at all (NOT the same as "false")
3. Quote the exact span of CONTEXT used as evidence for each claim
(or "none" if UNSUPPORTED/CONTRADICTED).
4. Give a one-sentence rationale per claim.
5. groundedness_score = (# SUPPORTED) / (# total claims).
Be strict: a claim that adds specificity not in CONTEXT (context says "a
discount applies," answer says "a 20% discount applies") is UNSUPPORTED.
Return valid JSON only:
{
"claims": [{"claim": "...", "verdict": "...", "evidence_span": "...", "rationale": "..."}],
"groundedness_score": 0.0,
"num_claims": 0
}
QUESTION: {question}
CONTEXT: {context}
ANSWER: {answer}
Некоторые дизайнерские решения должны быть четко определены, поскольку сначала они не кажутся очевидными:
- Оценка на уровне утверждения. Одного общего балла трудно отладить. Решения по отдельным утверждениям показывают точно, какое утверждение не прошло проверку, что важно, когда кто-то должен устранить коренную причину.
- Обязательный диапазон доказательств. Требование к судье приводить подтверждающий текст побуждает его основывать решения на доказательствах, а не на вероятности, а также позволяет человеку-рецензенту быстро проверить решение, не перечитывая весь контекст.
- НЕПОДТВЕРЖДЕНО против ПРОТИВОРЕЧИТ. Противоречие доказательствам и просто отсутствие подтверждения — это два разных типа ошибок с разными способами их устранения. Объединение их в одну категорию «плохо» приводит к потере диагностических деталей.
- Прямое указание на необходимость строгости. Судьи ИИ склонны к снисхождению в граничных случаях, особенно когда ответ кажется правдоподобным, а требование строгости снижает эту тенденцию.
Проверка судьи на соответствие людям
Этот шаг всегда пропускается, но именно он определяет, имеет ли какой-либо из остальных смысл: судью необходимо проверить на соответствие человеческим оценкам перед тем, как доверять её результатам.
Процесс прост: берутся от 100 до 200 примеров, человек независимо оценивает обоснованность ответов, после чего рассчитывается степень согласия с помощью коэффициента Каппа. Чистая точность вводит в заблуждение, если большинство ответов обоснованы, поскольку судья, всегда ставящая оценку «обосновано», показывает хорошие результаты, но на самом деле бесполезна. Также необходимо проверить на наличие типичных предубеждений судьи:
- Предубеждение, связанное с порядком: меняется ли вердикт при перестановке контекстных фрагментов?
- Склонность к излишней подробности: отдаёт ли судья предпочтение более длинным ответам, независимо от того, действительно ли они лучше обоснованы?
- Склонность к самопредпочтению: если судья принадлежит к той же семье моделей, что и генератор, он может более благосклонно оценивать результаты работы этой семьи.
- Склонность к снисхождению: уменьшается ли согласие постепенно на протяжении недель по мере изменения модели судьи или версии запроса?
Низкое значение каппы в одной категории — это признак необходимости корректировки критериев оценки для этой категории. Это не означает, что система RAG там неисправна. Люди постоянно путают эти понятия, и в следующем разделе рассматривается именно это различие.
Чтение панели управления как оператор
Представьте панель управления, разделённую по типам запросов. Правильная позиция — это позиция оператора, а не наблюдателя за табло с результатами.
Общий средний показатель демонстрирует незначительное снижение, что может ввести в заблуждение. По отдельным позициям показатели выглядят следующим образом.
- Простой поиск фактов остается стабильно высоким как с точки зрения достоверности, так и согласованности. И система, и судья считают его простым в использовании. В одиночку он скучен, но снижение показателей будет свидетельствовать о сбое в чем-то основном: индексации, поиске данных или формулировке вопроса судьей, а не в процессе рассуждения или двусмысленности.
- Многократный анализ и сравнение резко ухудшились. При κ=0.71 согласованность лишь умеренная, поэтому шум в длинных ответах, которые трудно разложить на составляющие, может частично объяснять этот феномен. Прежде чем говорить о регрессии, возьмите пять неудачных примеров и проверьте, находятся ли оба фрагмента, необходимые для ответа, в контексте. Если пришел только один фрагмент, это проблема поиска и воспроизведения информации: однократный плотный поиск часто упускает два факта, которые не похожи друг на друга и на запрос, и решение заключается в разложении запроса или использовании нескольких запросов, а не в корректировке подсказок. Если оба фрагмента пришли, но сравнение всё равно не сработало, виновата синтезация, причем основным фактором является эффект «потери посередине»: модель опирается на первый фрагмент и уделяет второму слишком мало внимания.
- Числовые и финансовые показатели показывают κ=0,52. Это слабая степень согласованности, но самый выраженный сигнал в таблице, поскольку это означает, что судье здесь пока нельзя доверять. Для судьи-ИИ добиться числового эквивалента действительно сложно: «20%», «примерно пятая часть» и «скидка 20 долларов с товара стоимостью 100 долларов» — это одно и то же утверждение в разных формулировках. Разумным решением будет не вмешиваться в систему RAG до тех пор, пока критерии оценки не будут уточнены, ведь работа с ненадежными цифрами тратит время разработчиков.
- Политические и процедурные аспекты остаются стабильными, как и в первой строке, но по другой причине: ответы обычно берутся из одного хорошо структурированного документа и не требуют синтеза информации из нескольких источников. Если показатели снижаются, первым подозреваемым не является процесс рассуждения. Скорее всего, список разделен на части по границам блоков данных, из-за чего у модели остаются шаги с 1 по 3, а шаги 4 и 5 придумываются самостоятельно.
- Вне диапазона требует первого устранения ошибки, несмотря на то, что n=20 делает его самым маленьким сегментом. При κ=0.90 оценщик здесь очень надежен, поскольку обнаружить выдуманный ответ без подтверждающего контекста гораздо проще, чем оценить тонкие числовые или многоэтапные утверждения. Именно эта надежность делает снижение качества ответа правдоподобным, и это самая опасная ошибка в таблице. Система перешла от правильного признания «Я не знаю» к уверенному выдумыванию ответов, что хуже, чем неверная цифра, поскольку по тону это неотличимо от правильного ответа. Возможные причины: система поиска возвращает похожие на нужные фрагменты, которые модель воспринимает как разрешение на ответ, или недавняя изменение в запросе или самой модели тихо устранило инструкцию о воздержании. Начните с оценок сходства в результатах поиска для этого сегмента. Если ответы находятся близко к уровню шума, но модель всё равно отвечает, значит, отсутствует фильтр порога релевантности перед генерацией.
Метод в пяти шагах
Вся процедура сводится к следующему:
- не доверяйте суммарным показателям
- перед тем как доверять оценкам, проверяйте надёжность судьи
- разделяйте данные по категориям
- на основе фактических данных определяйте, на каком этапе возникла проблема
- определяйте приоритет по сочетанию степени серьёзности и уровня уверенности, а не по тому, насколько сильно изменился показатель
Практические рекомендации для новых оценщиков
- Каждая оценённая ответность требует дополнительного вызова LLM. При большом объёме работы оценивайте лишь выборку, а не всё, и разделяйте её по категориям запросов, чтобы редкие, но критически важные случаи не затерялись среди многочисленных простых запросов.
- Повторно проверяйте значение каппы каждый раз, когда меняется модель судьи или её промпт. Любое изменение приводит к появлению нового судьи.
- Судья, привыкший к числовым особенностям или специфической терминологии одной области, автоматически не применяет свои навыки в другой, поэтому калибровка должна проводиться отдельно для каждой области, а не один раз для всего в целом.
Все приведённые здесь примеры и графики носят иллюстративный характер и не взяты из реальной производственной системы. Фреймворк и структура запросов служат разумной отправной точкой.
Где это заканчивается
Приведённый выше материал охватывает подходы к локализации ошибок, разницу между обоснованностью и корректностью, механизм оценки на уровне утверждений, а также этап калибровки, который многие игнорируют. Остаётся одно ограничение: всё это предполагает наличие одного чистого блока полученного контекста. Это предположение нарушается, когда система использует инструменты, объединяет шаги по получению информации или основывается на собственных промежуточных результатах, как это делают агентные системы. Определение обоснованности без возможности сравнения с единым блоком контекста и соответствующая корректировка механизма оценки представляют собой отдельную проблему.
Связанная литература
- Практические рекомендации: Где изучить RAG с нуля в 2026 году: курсы и — Подробное руководство по практическим рекомендациям: Где изучить RAG с нуля в 2026 году: курсы и: контракты, проверки и блоки кода для команд, внедряющих эту технологию.
- RAG с LangChain с нуля: загрузчики, фрагменты, эмбеддинги, оценка — Пошаговое создание системы вопросов и ответов на основе документов: загрузка файлов, разбиение на фрагменты, эмбеддинги, этапы индексации и поиска, а также способы оценки качества найденных ответов.