Метрики качества RAG нужны, чтобы отличать «стало лучше» от «кажется, стало лучше». Без них настройка превращается в перебор наугад, а решение о продолжении работ принимается по впечатлению.
Главный принцип: измерять поиск и генерацию раздельно. Общая оценка «доля верных ответов» говорит, что система плоха, но не говорит, что именно чинить.
Метрики поиска
Recall@k — доля вопросов, у которых нужный фрагмент попал в первые k результатов. Основная метрика первого этапа: если фрагмента нет в выдаче, дальше чинить нечего. Считается напрямую: из 100 вопросов набора у 82 нужный фрагмент нашёлся в топ-10 — recall@10 равен 0,82. Важно мерить при том k, который уходит в модель: если генератор получает 8 фрагментов, а метрику считают при k=50, она будет красивой и бесполезной — найденное на 30-м месте до модели не дойдёт.
Precision@k — какая доля выданных фрагментов действительно релевантна. В топ-10 релевантны три фрагмента — precision@10 равен 0,3. Низкое значение означает, что контекст забивается посторонним текстом, и за каждый посторонний фрагмент платят токенами.
MRR — насколько высоко в списке оказывается первый правильный фрагмент. Считается так: вопрос, у которого правильный фрагмент на первом месте, даёт 1, на втором — 0,5, на третьем — 0,33; значения усредняются по набору. MRR 0,5 — правильный фрагмент в среднем на второй позиции. Показывает, поможет ли реранкинг: если правильное есть, но низко, поможет.
NDCG — учитывает и позицию, и степень релевантности, если она размечена не бинарно. Со шкалой «точно — частично — не относится» различает выдачу с нужным на первом месте и с нужным на втором и смежным на первом. При бинарной разметке NDCG почти ничего не добавляет к MRR.
Метрики ответа
Опора на источник (faithfulness). Все ли утверждения ответа подтверждаются переданными фрагментами. Считается как доля подтверждённых утверждений: ответ из пяти утверждений, где четыре опираются на фрагменты, даёт 0,8. Прямо измеряет склонность выдумывать; подробнее — в статье про faithfulness.
Релевантность ответа. Отвечает ли ответ на заданный вопрос, а не на соседний. Ловит красивый подробный ответ не на тот вопрос.
Полнота. Не потерялась ли часть ответа, если он собирался из нескольких фрагментов.
Корректность отказа. Отвечает ли система «не нашлось» там, где ответа в документах действительно нет. Недооценённая метрика: система, которая никогда не отказывает, обязательно выдумывает.
Как собрать набор для проверки
Нужны реальные вопросы с эталонными ответами и указанием, в каком фрагменте лежит ответ. 50–100 штук достаточно для осмысленного сравнения версий.
Обязательно включите вопросы, ответа на которые в документах нет — иначе не измерить корректность отказа. Доля таких вопросов в наборе — примерно пятая часть.
Источник вопросов — обращения пользователей, а не фантазия разработчика. Люди спрашивают иначе, чем предполагают те, кто строит систему.
Стратификация важнее размера. Триста однотипных вопросов хуже, чем восемьдесят, разбитых по типам документов, темам и формам вопроса — короткий, развёрнутый, с опечаткой. Без срезов метрика усредняет: улучшение в одной категории скрывает деградацию в другой. По два-три перефразирования одного факта ловят хрупкость к формулировке: расхождение между ними — сигнал, что поиск цепляется за слова, а не за смысл.
Разметка — главная статья затрат. Вопрос с эталонным фрагментом и каноническим ответом занимает 5–15 минут эксперта, набор в сотню вопросов — один-два дня.
Набор — живой артефакт. Пополняйте его вопросами из ошибок в эксплуатации; эталоны пересобирайте при заметных изменениях базы знаний — иначе набор дрейфует вслед за дрейфом данных. Держите версии набора и сравнивайте конфигурации на одной версии; доля «боевых» вопросов — не выше трети, иначе набор выродится в одни трудные случаи.
Автоматическая оценка и её пределы
Оценивать ответы другой моделью (LLM-as-judge) удобно и дёшево, и для сравнения версий между собой обычно достаточно. Но абсолютные значения такой оценки не стоит принимать за истину: модель-судья имеет свои систематические перекосы, в частности склонна выше оценивать многословные ответы.
Перекосы судьи предсказуемы, потому проверяемы. Помимо многословия: самопредпочтение — судьи выше ставят ответы моделей собственного семейства; чувствительность к порядку — в парном сравнении победитель зависит от того, первым или вторым его показали; доверие уверенному тону. Парное сравнение гоняют в двух порядках и усредняют; судьёй берут модель из другого семейства, чем оцениваемая.
Судью калибруют по ручной разметке. 20–30 ответов оценивают вручную и прогоняют через судью; если расхождения с людьми больше трети случаев, дорабатывают промпт судьи — критерии, требование цитировать фрагмент, — а не верят цифрам.
Судья стохастичен. При ненулевой температуре повторный прогон даёт другие цифры; для метрик судью запускают с температурой 0, а близкие результаты перепроверяют повторными прогонами.
Разумная схема — автоматическая оценка на каждую версию плюс ручная проверка выборки перед решениями, которые чего-то стоят.
Методика сравнения версий
Одна переменная за итерацию. Если одновременно сменить размер чанка, модель эмбеддинга и промпт, рост метрики не приписать ничему — следующий шаг снова будет перебором. Исключение — связанные пары вроде смены эмбеддинг-модели с обязательной переиндексацией: их меряют как одну переменную.
Один набор и один судья на обе версии. Сравниваемые конфигурации гоняют на идентичном наборе одним судьёй с одними параметрами; смена судьи или пополнение набора между прогонами обнуляет сравнение.
Порог значимости. На наборе в 100 вопросов разница в 2–3 процентных пункта — внутри шума, особенно у стохастической генерации. Устойчивой считайте разницу, которая сохраняется при повторном прогоне и на обеих половинах набора; всё меньше 5 пунктов — «не доказано», а не «стало лучше».
Каждый прогон — зафиксированная конфигурация. Версия модели генератора и судьи, промпт, k, пороги, версия набора — всё регистрируется, например в трекере экспериментов, — иначе нельзя ни воспроизвести рост цифр, ни вернуться к лучшей конфигурации.
Что чинить по сочетанию метрик
Низкий recall@k — проблема индексации и запроса. Порядок по цене: нарезка документов и качество эмбеддингов, затем формулировка запроса, затем гибридный поиск, дополняющий векторный лексическим. Метрики ответа тут чинить бессмысленно.
Recall высокий, MRR низкий — проблема порядка. Нужное находится, но глубоко; в этой ситуации реранкинг обычно даёт самый дешёвый прирост качества.
Recall и порядок в порядке, precision низкий — забор шума. Уменьшайте k или поднимайте порог отсечения. Сюда же низкая корректность отказа: система отвечает на вопросы без ответа в документах — лечится тем же порогом.
Поиск здоров, faithfulness низкий — проблема генерации. Сначала промпт и требование цитировать источник, затем модель и её параметры; индекс трогать бессмысленно — вход у модели правильный.
Диагностику ведите от дешёвого к дорогому. Сначала 5–10 неудачных вопросов из эксплуатации: что вернул поиск, что ушло в модель — типовая причина видна уже на них. Полный прогон набора подтверждает гипотезу и измеряет масштаб, а не ищет причину.
Частые вопросы
С каких метрик начинать?
С recall@k на поиске. Если нужный фрагмент не попадает в выдачу, все метрики ответа бессмысленны — модели просто не из чего строить правильный ответ. Сначала добиваются полноты поиска, потом занимаются точностью и генерацией.
Сколько вопросов нужно для проверочного набора?
Для сравнения версий между собой хватает 50–100 при условии, что вопросы взяты из реальных обращений и покрывают разные типы. Важнее размера то, что примерно пятая часть должна быть вопросами без ответа в документах.
Можно ли оценивать ответы другой моделью?
Для сравнения версий — да, это дёшево и работает. Абсолютные значения такой оценки принимать за истину не стоит: у модели-судьи есть свои перекосы, например склонность выше оценивать длинные ответы. Перед серьёзными решениями выборку проверяют вручную.
Зачем измерять отказы?
Потому что система, которая никогда не отвечает «не нашлось», обязательно выдумывает. Доля корректных отказов на вопросах без ответа в документах — прямой показатель того, насколько системе можно доверять там, где цена ошибки высока.
Почему метрики растут, а пользователям лучше не становится?
Обычно набор перестал отражать реальные обращения: вопросы в нём «чище» боевых — без опечаток и пересечения тем. Сверьте набор с журналом обращений за месяц и добавьте 10–20 вопросов из реальных сбоев.
Можно ли сравнивать версии, оценённые разными судьями?
Нет. Смена судьи меняет шкалу: разница оценок отражает судей, а не системы. Корректно — перезапустить обе версии одним судьёй с одними параметрами, взяв его не из семейства оцениваемой модели.