Как измерять качество RAG-системы

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

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

Что именно оценивается в RAG

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

На практике цепочка качества включает больше двух технических модулей:

1. загрузку документов, разделение на фрагменты и сохранение метаданных;

2. обработку запроса, поиск и повторное ранжирование;

3. сборку контекста в окне модели;

4. генерацию ответа;

5. привязку утверждений к цитатам;

6. проверку прав доступа, безопасности и результата для пользователя.

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

Начните с репрезентативного эталонного набора

Без эталонных примеров качество RAG оценивается в основном по ощущениям. Хорошей отправной точкой станет проверенный экспертами набор, где для каждого случая указаны как минимум:

• вопрос пользователя в той форме и на том языке, в которых он возникает в работе;

• допустимый ответ или ключевые факты, обязательные для ответа;

• необходимые документы и, желательно, конкретные фрагменты;

• источники, которые использовать нельзя, например устаревшая версия политики;

• признак того, можно ли вообще ответить на вопрос по базе знаний;

• роль пользователя и уровень доступа;

• категория риска и возможные последствия ошибки.

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

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

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

Качество поиска документов

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

Precision@k: насколько чисты первые результаты

Precision@k показывает, какая доля первых k найденных фрагментов относится к вопросу. Если из первых пяти фрагментов только два помогают ответить, Precision@5 равен 0,4.

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

Recall@k: не потеряно ли важное

Recall@k показывает, сколько из всех отмеченных в эталоне необходимых фрагментов попало в первые k результатов. Если для ответа нужны основная политика и таблица исключений, а система нашла только политику, точность может выглядеть приемлемо, но полнота поиска будет недостаточной. Метрика context recall от Ragas похожим образом проверяет, какая часть утверждений эталонного ответа подтверждается найденным контекстом.

MRR и nDCG: достаточно ли высоко находится лучший источник

MRR, или mean reciprocal rank, полезен, когда у вопроса обычно есть один главный источник. Метрика дает высокий результат, если первый релевантный документ находится на первой позиции, и быстро снижает оценку, если тот расположен ниже.

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

Ни одна метрика поиска сама по себе не гарантирует успешный ответ. Разбивайте результаты по типам запросов, системам-источникам, языкам и ролям пользователей. Хорошее среднее значение Recall@k может скрывать, что финансовые политики находятся стабильно, а вопросы отдела кадров на латышском языке часто дают сбой.

Точность источников и цитат

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

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

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

Авторитетность и актуальность. Использована ли утвержденная действующая процедура, а не старое приложение, презентация или дубликат? Необходимо хранить владельца документа, версию, дату вступления в силу и статус. При конфликте источников система должна применять явное правило приоритета или сообщать о неопределенности.

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

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

Надежность ответа и groundedness — не одно и то же

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

• правильность — совпадают ли выводы с эталоном и правилами предметной области;

• обоснованность — можно ли вывести каждое фактическое утверждение из разрешенного контекста;

• полнота — не пропущено ли важное для решения условие или исключение;

• релевантность — отвечает ли текст прямо на вопрос без отвлекающего содержания;

• соблюдение инструкций — выдержаны ли формат, тон, границы действий и правила эскалации;

• калиброванный отказ — сообщает ли система о недостатке данных, когда это необходимо, и не отказывается ли отвечать при достаточных доказательствах.

В документации Microsoft по оценке RAG похожим образом разделены оценка процесса — поиск и поиск документов — и оценка системы, куда входят groundedness, релевантность и полнота ответа. Этот подход полезен, даже если конкретный инструмент Microsoft не используется.

Вопросы с ответом и без ответа следует оценивать отдельно. В первом случае измеряются правильность и полнота. Во втором — насколько надежно система воздерживается от догадки. Уверенный вымысел о несуществующей политике обычно опаснее корректного отказа.

Автоматизированный судья не является истиной

Часть проверок можно выполнять детерминированно: совпадение идентификаторов документов, статус версии, фильтры прав, задержку, стоимость и точные значения полей. Более сложные свойства текста можно оценивать с помощью LLM-судьи, но только при наличии конкретной рубрики и примеров для каждого уровня.

У LLM-судей есть собственные искажения. Они могут предпочитать более длинные ответы, определенную формулировку или одну позицию в парном сравнении. Сначала создайте контрольную выборку с человеческой разметкой и измерьте согласие автоматического судьи с экспертами. OpenAI рекомендует парное сравнение или четкий критерий «прошел/не прошел», подробную рубрику и калибровку модельных оценок по человеческим меткам.

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

От офлайн-тестирования к мониторингу в работе

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

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

• долю ответов «данных недостаточно» и отказов;

• повторные перефразированные вопросы в одной сессии;

• исправления пользователей и передачу запроса человеку;

• открытие цитат и сообщения о проблемах с источником;

• завершение задачи, а не только получение ответа;

• задержку поиска, модели и всей системы;

• стоимость успешно завершенной задачи;

• попытки несанкционированного поиска и инциденты безопасности.

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

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

Матрица ошибок: что исправлять при плохом результате

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

Практический пример

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

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

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

Как определить порог запуска

Универсального порога качества RAG нет. Цена ошибки различается для внутреннего поиска по документам и для ассистента, который рекомендует действия в финансовом или кадровом процессе. Устанавливайте пороги по категориям риска, а не одно среднее значение для всей системы.

До запуска определите как минимум:

• отдельные минимальные пороги полноты поиска, поддержки цитат и правильности ответа;

• нулевую терпимость к известным нарушениям доступа;

• обязательный правильный отказ в критических случаях без ответа;

• запрет регрессий в тестах высокого риска;

• приемлемые задержку и стоимость при ожидаемой нагрузке;

• ответственных за инциденты, актуальность источников и поддержку тестового набора.

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

Вывод

Надежная RAG-система — не та, которая просто пишет уверенно. Она находит необходимые доказательства, не пропускает в контекст закрытые или устаревшие источники, связывает утверждения с правильными фрагментами и умеет отказаться от ответа, когда основания недостаточны.

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