RAG-система объединяет генеративную модель с механизмом поиска по внешнему корпусу документов. В исходной работе о retrieval-augmented generation такой подход описан как сочетание параметрической памяти модели и непараметрической памяти, доступной через поисковый индекс. основание
Проверять такую систему одной итоговой метрикой недостаточно. Ошибка может возникнуть при формулировке запроса, поиске документов, выборе фрагментов, построении контекста или генерации ответа. Исследования RAGAS и ARES поэтому разделяют оценку релевантности контекста, соответствия ответа найденным данным и полезности итогового ответа. основание основание
Зачем проводить оценку до производственного запуска
Прототип часто выглядит убедительно на нескольких демонстрационных вопросах, однако такие примеры не показывают устойчивость системы на редких формулировках, конфликтующих документах и запросах без ответа. NIST рекомендует рассматривать измерение и управление рисками как процессы, проходящие через жизненный цикл ИИ-системы, а не как разовую проверку перед публикацией. основание
Цель предварительной оценки состоит не в поиске абстрактного «процента качества». Команде нужно определить, при каких запросах система помогает пользователю, когда должна отказаться от ответа и какие ошибки блокируют запуск. Для этого проверка должна связывать продуктовый сценарий, тестовые данные, наблюдаемые дефекты и решение о допустимости риска.
Редакционная рекомендация: заранее сформулируйте три решения, которые будут приниматься по результатам теста. Например: запускать ли систему для всех пользователей, ограничивать ли её одной предметной областью и требуется ли обязательная проверка ответа человеком.
Модель оценки из трёх уровней
Первый уровень — поиск. Он отвечает на вопрос, попали ли в выбранный контекст документы, необходимые для корректного ответа. RAGAS рассматривает качество извлечённого контекста отдельно от качества генерации, поскольку релевантный ответ невозможно стабильно получить из нерелевантных фрагментов. основание
Второй уровень — опора ответа на контекст. Здесь проверяется, следует ли утверждение из найденных материалов или модель добавила сведения, которых в них нет. ARES использует для оценки RAG три измерения: релевантность контекста, достоверность ответа относительно контекста и релевантность ответа запросу. основание
Третий уровень — продуктовая полезность. Формально обоснованный текст может быть бесполезен из-за неполноты, неясной структуры, неверного уровня детализации или отсутствия следующего действия. Этот уровень необходимо задавать в терминах конкретного сценария: оператор поддержки должен быстро решить обращение, аналитик — найти подтверждённый факт, сотрудник — понять внутреннее правило.
Три уровня нельзя смешивать в один балл на раннем этапе. Иначе команда увидит падение итоговой оценки, но не поймёт, требуется ли менять индекс, разбиение документов, инструкцию модели или интерфейс ответа.
Как собрать проверочный набор
Проверочный набор начинается с карты пользовательских задач. Для каждой задачи фиксируются тип запроса, ожидаемый источник, допустимая форма ответа и опасная ошибка. NIST AI RMF связывает измерение риска с контекстом применения, воздействием системы и характеристиками, которые организация считает существенными. основание
В набор стоит включить прямые вопросы, перефразированные запросы, неполные формулировки, запросы с ошибочной предпосылкой, вопросы к устаревшим документам и случаи, для которых в корпусе нет достаточного основания. Последняя группа особенно важна: система должна уметь сообщать о недостатке данных, а тест должен отличать корректный отказ от необоснованного ответа.
Эталон необязательно должен состоять из единственной идеальной формулировки. Полезнее хранить обязательные факты, запрещённые выводы, подходящие документы и критерии приемлемого ответа. Такой формат снижает зависимость проверки от стилистического совпадения с заранее написанным текстом.
Редакционная рекомендация: сохраняйте происхождение каждого тестового случая. Отдельные метки для реального обращения, экспертного сценария и специально сконструированного граничного примера помогут понять, насколько результаты отражают рабочую нагрузку.
Метрики и роль экспертной проверки
Автоматическая оценка позволяет регулярно сравнивать версии системы на одном наборе. RAGAS предлагает безэталонные метрики для компонентов RAG, включая оценку извлечённого контекста и ответа. основание ARES сочетает автоматически подготовленные данные, модели-судьи и небольшое количество человеческих аннотаций для проверки нескольких измерений качества. основание
Автоматический судья также является моделью и может ошибаться. Поэтому его выводы нельзя принимать как независимую истину. Практическая схема включает калибровочную выборку, которую размечают профильные специалисты, сравнение решений судьи с этой разметкой и периодический пересмотр расхождений.
Для продуктового решения полезно вести не только средние значения, но и доли критических дефектов. К ним могут относиться ссылка на неподходящий документ, уверенное утверждение при отсутствии основания, смешение разных редакций правила и раскрытие информации за пределами разрешённого контекста. Список критических дефектов определяется риском конкретного применения.
Редакционная рекомендация: не компенсируйте критическую ошибку высоким средним баллом по безопасным вопросам. Используйте отдельный порог для дефектов, после которых выпуск блокируется независимо от остальных результатов.
Практический пример проверки внутреннего помощника
Рассмотрим условный проект: помощник отвечает сотрудникам по внутренним регламентам. Корпус содержит действующие документы, архивные редакции и справочные материалы. Пример не описывает опыт реальной компании и используется только для демонстрации метода.
Команда сначала группирует запросы по задачам: оформление отпуска, согласование закупки, доступ к системе и поиск ответственного подразделения. Для каждого случая эксперт указывает действующий документ, минимальный набор обязательных сведений и условия, при которых помощник должен перенаправить вопрос человеку.
Затем каждый ответ проверяется по цепочке. На этапе поиска фиксируется, оказался ли нужный документ среди выбранных фрагментов. На этапе обоснованности отмечается, подтверждены ли контекстом сроки, роли и ограничения. На продуктовом этапе эксперт оценивает, может ли сотрудник выполнить следующее действие без дополнительного уточнения.
Если нужный документ не найден, изменение промпта генератора не считается основным исправлением: сначала исследуются индексирование, фильтры доступа, метаданные и разбиение текста. Если документ найден, но модель объединяет несовместимые пункты, проверяются состав контекста и инструкция по работе с противоречиями. Если ответ точен, но неудобен, меняются формат и интерфейс, а не поисковая часть.
Итогом теста становится журнал дефектов с указанием уровня сбоя, риска, воспроизводимого примера и владельца исправления. Такой журнал позволяет сопоставлять версии системы по причинам ошибок, а не только по итоговому числу.
Критерии качества оценки
Качественная оценка обладает воспроизводимостью: одинаковая версия системы, корпуса и параметров должна проверяться на зафиксированном наборе по неизменной процедуре. Она также обладает диагностичностью: результат показывает компонент, в котором возникла проблема.
Проверочный набор должен покрывать основные задачи, опасные ошибки и отсутствие ответа в данных. Критерии должны быть связаны с действиями пользователя, а не ограничиваться общими характеристиками вроде «ответ выглядит хорошо». Решение о запуске должно опираться на заранее установленные пороги и правила обработки критических дефектов.
Источники тестовых документов, версия индекса, конфигурация поиска и инструкция модели должны сохраняться вместе с результатом. Без такой фиксации сравнение двух прогонов может отражать одновременное изменение нескольких факторов, из-за чего причина улучшения или ухудшения останется неизвестной.
Отдельный критерий — проверяемость. Эксперт должен иметь возможность увидеть запрос, извлечённые фрагменты, ответ, локальные ссылки и решение оценщика. Это соответствует общей задаче управления рисками через документированные процессы измерения и наблюдения. основание
Дополнительный контрольный проход для RAG-оценки
Редакционная рекомендация: перед решением о запуске команда повторно просматривает все случаи, где автоматический оценщик и профильный эксперт разошлись. Для каждого расхождения фиксируются запрос, найденные фрагменты, спорное утверждение, причина решения эксперта и предполагаемый уровень риска. Затем тот же случай добавляется в закрытую контрольную выборку и проверяется после следующего изменения индекса, модели или инструкции. Такой проход не заменяет основные метрики, но помогает обнаружить систематическую ошибку оценщика, которую среднее значение может скрыть. Отдельно отмечаются вопросы без достаточного основания: корректный отказ в них считается ожидаемым поведением, а не снижением полезности системы.
Ограничения применимости
Описанная схема требует корпуса документов, для которого можно определить допустимые источники и проверить происхождение ответа. Она хуже подходит для творческих задач, где нет устойчивого эталона фактов, а ценность зависит от оригинальности или субъективного восприятия.
Безэталонные автоматические метрики сокращают объём ручной работы, но не устраняют необходимость экспертной проверки. RAGAS прямо рассматривает автоматизированную оценку RAG-компонентов, а ARES сохраняет человеческие аннотации как часть своей процедуры. основание основание
Результаты теста действительны только для проверенной комбинации корпуса, поискового контура, модели и инструкций. Обновление документов или замена модели может изменить поведение системы, поэтому после существенных изменений требуется повторный прогон.
Наконец, техническая корректность не заменяет юридическую, безопасностную или отраслевую экспертизу. Для сценариев с высоким ущербом правила допуска и человеческого контроля должны определяться ответственными специалистами в соответствующей области.
Вывод
Оценка RAG-системы должна разделять качество поиска, обоснованность генерации и полезность для пользовательской задачи. Такое разделение поддерживается исследовательскими подходами RAGAS и ARES, которые рассматривают компоненты RAG по нескольким измерениям. основание основание
Рабочий процесс состоит из карты сценариев, проверочного набора, экспертной калибровки, автоматических прогонов и журнала диагностированных дефектов. Решение о запуске принимается по заранее установленным критериям, включая отдельные правила для критических ошибок.
Главный результат проверки — не универсальный рейтинг модели, а подтверждённое понимание того, где система надёжна, где должна ограничивать ответ и какие изменения действительно уменьшают риск.
