Как проверить обоснованность ответов RAG по таблице доказательств

Чек-лист проверки обоснованности RAG-ответов — groundedness — полезен только тогда, когда после проверки остаётся доступная для аудита запись. Разделите каждый тестовый ответ на существенные утверждения, свяжите каждое утверждение с точным фрагментом источника и присвойте ограниченный вердикт с письменным обоснованием. Затем сохраните запрос, извлечённые фрагменты, ответ, цитаты, версии источников и версию системы, чтобы позднее повторить тот же сценарий. Результат — не оценка точности и не обещание истинности ответа. Это таблица доказательств на уровне утверждений: она показывает, что подтверждают видимые данные, где цитата лишь прикреплена и где система должна зафиксировать честное отсутствие ответа.

В статье описан именно такой протокол фиксации и повторного прогона. Он намеренно не заменяет более широкое объяснение обоснованного ИИ-поиска, цитат и честного отказа. Его узкая задача — сделать один тестовый ответ проверяемым, не изобретая бенчмарк и не пряча человеческое решение внутри показателя успешности.

Кто подготовил этот протокол, как и зачем

Указанный автор — Michael Shamanoff, основатель Achla AI. Протокол подготовлен по утверждённому владельцем редакционному брифу, текущему артефакту продукта и официальной документации Microsoft, Ragas и AWS. Спрос на эту тему остаётся экспериментальной гипотезой: данных GSC, Keyword Planner, лицензированного объёма запросов или устойчивой подсказки автодополнения нет.

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

Начните с зафиксированного набора доказательств

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

Ниже используется синтетический пример. Он описывает вымышленный магазин и не является результатом Achla AI или клиента. В русской версии текст синтетических источников и ответа локализован, а их идентификаторы и версии сохранены.

Запрос Q-017: «Можно ли вернуть товар финальной распродажи позднее чем через 30 дней и когда начинается обработка возврата денег?»

Источник D-01, `/returns`, версия `returns-v4`, фрагмент `p04`: «Товары, купленные непосредственно в магазине-примере, можно вернуть в течение 30 календарных дней с момента доставки. Товары финальной распродажи возврату не подлежат».

Источник D-02, `/refunds`, версия `refunds-v2`, фрагмент `p07`: «Обработка возврата денег начинается после поступления возвращённого товара на склад».

Ожидаемое состояние доказательств: D-01 подтверждает 30-дневный срок для подходящих товаров, купленных непосредственно в магазине, и явно исключает товары финальной распродажи. D-02 подтверждает событие, с которого начинается обработка возврата денег. Ни один фрагмент не указывает продолжительность обработки.

Зафиксированный ответ A-017: «Любой товар можно вернуть в течение 30 дней, включая товары финальной распродажи.[D-01] Возврат денег начинается при отправке запроса.[D-02] Обычно он завершается в течение пяти дней».

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

Разделите ответ на существенные утверждения

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

Для A-017 таблица фиксирует четыре утверждения:

1. C-017-1: Вернуть можно любой товар.
2. C-017-2: Срок возврата составляет не более 30 дней.
3. C-017-3: Обработка возврата денег начинается при отправке запроса.
4. C-017-4: Обработка возврата денег обычно завершается в течение пяти дней.

Фраза «включая товары финальной распродажи» относится к C-017-1: она расширяет формулировку «любой товар» и противоречит явному исключению. Утверждение о 30 днях выделено отдельно, потому что фрагмент подтверждает этот срок с учётом ограничений области действия. Последнее утверждение о продолжительности также отделено: ни один извлечённый фрагмент не обсуждает срок обработки.

Такое разбиение не позволяет одному подтверждённому фрагменту замаскировать неподтверждённый. Оно также делает разногласия видимыми: проверяющий может оспорить границу C-017-1, не меняя незаметно вердикт для C-017-2. Для научных и технических коллекций тот же принцип важен в поиске с приоритетом цитат, хотя определять существенность иногда должен профильный эксперт.

Постройте таблицу доказательств на уровне утверждений

Используйте одну строку для каждого существенного утверждения. Рабочая таблица доказательств должна содержать:

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

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

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

В официальных системах применяются близкие разграничения. Документация Microsoft по оценке RAG отделяет оценку извлечения от оценки ответа. Ragas описывает faithfulness через утверждения, которые могут быть подтверждены извлечённым контекстом. AWS документирует отдельные режимы retrieve-only и retrieve-and-generate. Эти источники помогают отделять оценку релевантности извлечения от оценки обоснованности RAG-ответа, но не задают универсального порога для этой таблицы.

Отделяйте прикрепление цитаты от смысловой поддержки

Поле «прикреплена» отвечает на механический вопрос: связал ли зафиксированный ответ ID источника с утверждением или предложением? Поле «подтверждено» отвечает на смысловой вопрос: обосновывает ли точный фрагмент утверждение с сохранением важных ограничений, исключений, количеств и времени?

Не объединяйте эти поля. Проверка поддержки цитат отвечает на оба вопроса независимо. У C-017-1 цитата прикреплена, но процитированный фрагмент противоречит утверждению. У C-017-4 нет ни прикреплённой цитаты, ни извлечённого подтверждения. В другом сценарии показанной цитаты может не быть, хотя извлечённый фрагмент подтверждает утверждение; это проблема прикрепления, а не доказательство сбоя извлечения.

Используйте четыре ограниченных смысловых вердикта:

• подтверждено (`supported`): видимый фрагмент подтверждает существенное утверждение и его важные оговорки;
• подтверждено частично (`partially supported`): фрагмент подтверждает отделимую часть, но оставляет существенную оговорку, область действия или связь нерешённой;
• не подтверждено (`unsupported`): видимые фрагменты не обосновывают утверждение или противоречат ему;
• невозможно оценить (`not assessable`): запись неполна либо решение требует экспертизы или доказательств за пределами зафиксированного сценария.

Каждому вердикту нужно письменное обоснование. Метка — это указатель, а не анализ. Для «невозможно оценить» укажите, чего именно не хватает; эта метка не должна становиться удобной заменой проверке.

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

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

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

Фиксируйте честное отсутствие ответа как полноценный результат

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

В текущем проверенном артефакте Achla AI основной путь обоснованного ответа (grounded) требует одновременно текст ответа и цитаты, прежде чем считать этот путь обоснованным; виджет также имеет видимое состояние отсутствия ответа и может показывать ссылки на источники. Это описание проверенной локальной реализации, а не утверждение о производительности или надёжности. Для отсутствия ответа тоже нужны метаданные повторного прогона, потому что в более поздней версии источника недостающий факт может появиться.

Сохраняйте метаданные повторного прогона и версий

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

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

При регрессионном повторе RAG создавайте новый ID прогона. Не перезаписывайте старый ответ и не добавляйте новые фрагменты задним числом в прежнюю запись. Сравнивайте строки утверждений только при совместимых сценариях. Если изменился запрос, снимок источников или указатель теперь ведёт на другой текст, отметьте это явно. Изменившийся результат может заслуживать изучения, но сама таблица не устанавливает причину изменения.

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

Соберите пакет для аудита

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

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

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

Ограничения

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

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

Примените таблицу к ограниченному корпусу сайта

Выберите небольшой версионируемый набор реальных вопросов посетителей, включите хотя бы один известный пробел в доказательствах и сохраняйте пакет аудита при каждом повторе. Так получится проверяемый чек-лист обоснованности RAG без утверждений сверх того, что показывает запись.

Если вы хотите проверить процесс на контенте, который контролируете, подключите свой сайт, а решения о фактах, безопасности и публикации оставьте человеку.