Шесть метрик оценки RAG, которые важны в производственной среде

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

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

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

Дополнительный контекст не помогал. Иногда это даже мешало. Релевантные фрагменты поступали вместе с дубликатами, нерелевантными данными и периодическими конфликтами.

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

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

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

Шесть показателей особенно полезны: Recall@K, nDCG, MRR, Faithfulness, Latency и Cost. Каждый из них выявляет разный тип сбоя. Вместе они объясняют, как прототип превращается в систему, которой можно управлять.

Начните с поиска информации

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

1. Recall@K — степень покрытия необходимых данных

Показатель Recall@K определяет, какая доля по-настоящему релевантных элементов входит в топ-K результатов поиска.

Возьмем бота для ITSM, сталкивающегося с вопросом: «Служба оплаты перестала работать после смены базы данных — какие шаги восстановления мне следует выполнить?» Предположим, требуется пять фактов. Среди пяти лучших результатов поиска содержатся только четыре из них. Значение Recall@5 составляет 0,80.

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

Это также объясняет, почему фиксированное значение top_k = 5 не является абсолютным стандартом. При увеличении значения K с 5 до 10 показатель воспроизводимости растёт с 0,80 до 0,94, что указывает на то, что в индексе присутствуют нужные данные, но выборка слишком ограничена. Увеличение K также может привести к перегрузке запроса шумом — именно поэтому далее рассматриваются метрики ранжирования.

2. nDCG — находятся ли лучшие результаты ближе к верху?

Одного лишь уровня покрытия недостаточно. Важна и позиция.

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

Оценки nDCG (нормализованный дисконтированный кумулятивный прирост) показывают степень релевантности и поощряют размещение наиболее значимых элементов в начале списка. Классическая работа Järvelin и Kekäläinen по дисконтированному приросту была создана именно для этой цели.

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

Воспроизводимость проверяет эффективность поиска, а nDCG — качество интеллектуального ранжирования.

3. MRR — как быстро появляется первый полезный результат?

Среднее обратное ранжирование сосредотачивается на первом релевантном результате:

[
RR = \frac{1}{\text{rank of first relevant result}}
]

Ранг 1 → RR 1,0. Ранг 5 → RR 0,2. При среднем расчете по набору запросов MRR является четким показателем того, что первый хороший результат доминирует в результатах поиска.

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

Когда «больше контекста» имеет обратный эффект

Несмотря на улучшение показателей поиска, качество ответов продолжало снижаться. Модель тонула в избыточном и противоречивом тексте. Показатели ранжирования объясняют эту проблему: более большое значение K без улучшения порядка ввода приводит к появлению шума в запросе, что заставляет модель выполнять проверки на соответствие реальности.

4. Верность — утверждения, связанные с полученным текстом

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

Не следует смешивать критерий верности с критерием корректности.

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

• Верность: подтверждается ли она тем, что было найдено?
• Правильность: соответствует ли она предусмотренной политике?

Это разделение имеет значение каждый раз, когда базы знаний меняются в рабочей системе.

5. Задержка — сколько могут выдержать качественные пользователи

Качество работы в офлайн-режиме бесполезно, если продукт не может позволить себе такую задержку.

Сравним два варианта. У первого достигается точность ответов 91% при задержке поиска 120 мс. У второго — 93% при задержке 650 мс. По одной только точности второй вариант лучше. Однако ограничения продукта определяют, действительно ли второй вариант лучше. Интерактивные ассистенты с жесткими лимитами на время ответа могут отклонить такую задержку, причем поиск — это лишь часть общего времени.

Живой запрос может включать переписывание, получение данных, переранжирование, сбор контекста и генерацию. Необходимо измерять отдельные этапы и весь путь обработки. Лучше использовать распределения, чем средние значения. Среднее время в 400 мс при P95 в 1,8 секунды совершенно не похоже на показатели системы, у которой значения P50/P95/P99 остаются низкими.

С самого начала необходимо включать показатели задержек в план оценки — а не рассматривать их как метрику работы после фиксации архитектуры.

6. Стоимость — что происходит при миллионах запросов

Экономические аспекты становятся значимыми сразу, когда прототип превращается в продукт.

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

Если размер каждого блока составляет в среднем 600 токенов, то:

Final K = 5

будет вставлено примерно 3 000 полученных токенов. Перейти к:

Final K = 15

И вы ближе к значению 9 000 — в три раза больше, чем полученная масса. Незначительный трафик скрывает реальные затраты. Миллионы запросов превращают это в вариант выбора продукта. Параметр top-k одновременно является регулятором качества, задержки и стоимости.

Что на самом деле означает «настройка размера блока и параметра top-k»

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

Создайте примерно 200 репрезентативных запросов, охватывающих устранение неполадок, процедуры, инциденты/RCA, правила, неоднозначности, многоэтапные операции и крайние случаи. Пусть эксперты в данной области оценят их релевантность.

Изучайте различные размеры блоков, например:

Chunk sizes:
256
512
1024
2048

а также гриды с перекрытием / кандидатами K, например:

Overlap:
64
128
256Candidate K:
5
10
20

Грид 4 × 3 × 3 даёт примерно 36 конфигураций. Оцените каждую более чем одним показателем:

Recall@K
nDCG@K
MRR
Answer correctness
Faithfulness
Latency
Cost

Затем выберите оптимальный баланс между качеством, задержкой и стоимостью — а не максимальную воспроизводимость или показатель F1 по умолчанию.

Результаты экспериментов, противоречащие интуиции

Предположим, три конфигурации дают следующие показатели:

• A: Recall@10 0.94, nDCG@10 0.81, точность 0.89, степень соответствия 0.95, P95 510 мс, $0.025
• B: Recall@10 0.91, nDCG@10 0.88, точность 0.94, степень соответствия 0.96, P95 560 мс, $0.027
• C: Recall@10 0.97, nDCG@10 0.79, точность 0.86, степень соответствия 0.76, P95 820 мс, $0.034

Только по показателю Recall лидирует конфигурация C. Однако она дает самые слабые результаты — похоже, дополнительная обработка данных негативно сказывается на генерации ответов. У конфигурации B меньший показатель Recall, но она опережает по nDCG, точности и степени соответствия при лишь незначительном увеличении задержки и затрат. Именно эту конфигурацию стоит более подробно изучить, и это объясняет, почему правило «побеждает наивысший балл по поиску» является плохим универсальным принципом. Необходимо оптимизировать под реальные цели продукта.

Неудача → дальнейшее исследование

• Низкий показатель Recall@K → разбиение на части, использование эмбеддингов, фильтры индекса и метаданных, формирование запросов, стратегия поиска

Сильная способность к воспроизведению, слабый показатель nDCG → ранжирование/переранжирование

Сильная способность к поиску, слабая точность ответов → сбор контекста, упорядочивание, формулировка запросов, генерация

Вероятные, но не подтвержденные ответы → точность/обоснованность

Хорошее качество, плохая задержка → анализ каждого этапа

Хорошее качество, высокая стоимость → выбор K-количество кандидатов, окончательное K-количество, размер блоков, сжатие, кэширование, выбор модели, эффективность токенов

Этот чек-лист превращает отладку в процедуру.

Поддерживайте цикл отладки в рабочей среде

Однократный тест-бенчмарк — это не конечная цель. Необходима непрерывная оценка. Реальный трафик отличается от специально подобранных наборов данных: меняется формулировка запросов, документы обновляются, правила изменяются, появляются новые сервисы, возникают крайние случаи. Расширяйте набор данных для оценки на основе сбоев в рабочей среде.

Зрелая система оценки

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

Спросите перед настройкой

Когда кто-то требует указать размер фрагментов и значение параметра top-k, сначала задайте вопросы: что мы оптимизируем, как выглядит набор с метками и во сколько обходится ошибочное получение результата? С этими ответами настройки превращаются в экспериментальные данные.

Одним из возможных результатов может быть:

512 tokens
128 overlap
Candidate K = 20
Final K = 5

Другим —

1024 tokens
64 overlap
Candidate K = 10
Final K = 4

Семантическое разделение на фрагменты может оказаться лучше обоих подходов. Инструмент переранжирования может сделать окончательное значение K более важным, чем начальное значение K.

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

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

Хватит угадывать параметры

Нет такого мифического оптимального размера фрагментов, нет универсального параметра top-k, и ни один показатель сам по себе не может свидетельствовать о готовности к развертыванию. Даже высокий показатель Recall@K может ухудшить качество ответов. Эффективный поиск информации всё равно может привести к необоснованным утверждениям. Высокая точность тоже может оказаться бесполезной, если при масштабировании растут задержки или затраты.

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

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

Затем значение chunk_size=512 или top_k=5 является доказательством, а не мнением.

Размещение шести показателей на одной странице

Практичный формат таблицы оценок для еженедельного анализа RAG может выглядеть так:

• Recall@K и MRR для оценки «нашли ли мы доказательства и как быстро?»
• nDCG для оценки «поместили ли мы лучшие доказательства в начало?»
• Надежность и корректность ответа для оценки «оставалась ли генерация честной и точной?»
• Задержки P50/P95 для оценки «могут ли пользователи ждать?»
• Затраты на один успешный ответ для оценки «могут ли финансы ждать?»

Проанализируйте их вместе. Повышение показателя Recall@K при снижении точности — это не успех. Сокращение задержки, приводящее к падению значения nDCG, тоже не является успехом. Смысл использования шести метрик заключается в том, чтобы сделать эти компромиссы видимыми, а не скрыть их в одном числе F1.

Абсолютная истина — это ограниченный ресурс

Качество метрик зависит от качества ярлыков, которые стоят за ними. Если эксперты в данной области никогда не определяют, какие фрагменты являются релевантными, то показатель Recall@K бесполезен. Если никто не оценивает степень релевантности, значение nDCG превращается в шумный бинарный показатель. Если критерии оценки точности несогласованы, результаты оценок будут смещаться.

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

От эксперимента к контролю изменений

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

Почему прототипы врут

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

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

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