Вопрос «насколько хорошо работает наша RAG-система» не имеет одного ответа, и попытка свести его к одному проценту — главная причина, по которой улучшения идут вслепую.
Система состоит из двух разнородных частей. Поиск отвечает за то, попали ли нужные сведения в контекст. Генерация — за то, правильно ли модель ими воспользовалась. Ошибки у них разные, лечатся по-разному, и общая метрика их смешивает.
Практическое следствие: если мерить только конечный ответ, вы видите, что стало хуже, но не знаете, где чинить. Если мерить раздельно — знаете сразу.
Метрики поиска
Считаются по набору вопросов, для которых известно, какие фрагменты содержат ответ.
Полнота в первых K (recall@k). Доля вопросов, где нужный фрагмент попал в первые K результатов. Главная метрика поиска: если фрагмента нет в контексте, дальше всё бессмысленно.
Считают обычно при K, равном числу передаваемых в модель фрагментов, и при K побольше — чтобы отличать «не нашлось вообще» от «нашлось, но низко».
Позиция первого верного (MRR). Насколько высоко стоит нужный фрагмент. Разница между recall@20 и recall@5 показывает, есть ли смысл в реранкинге: если нужное находится, но стоит низко — есть.
Точность в первых K. Какая доля переданных фрагментов действительно относится к вопросу. Низкая точность означает шум в контексте: ответ размывается, а обращение дорожает.
Три метрики отвечают на три разных вопроса, и все три нужны:
| Что показывает | Метрика | Что делать при низком значении |
|---|---|---|
| Находится ли нужное вообще | recall@20 | чинить нарезку и поиск |
| Стоит ли оно высоко | recall@5, MRR | добавить реранкинг |
| Не слишком ли много лишнего | точность@5 | отсекать по порогу, уменьшить K |
Метрики генерации
Считаются по ответам, а не по фрагментам.
Обоснованность. Подтверждается ли каждое утверждение ответа переданными фрагментами. Прямая мера выдумывания: если в ответе есть то, чего нет в источниках, — модель дописала от себя.
Самая важная метрика генерации в бизнес-применении.
Полнота ответа. Использована ли вся относящаяся к делу информация из переданных фрагментов. Ловит характерную ошибку: правило воспроизведено, исключение к нему потеряно.
Релевантность. Отвечает ли текст на заданный вопрос, а не на соседний.
Корректность отказа. Отказывается ли система, когда подходящих сведений нет, и не отказывается ли, когда они есть. Метрика, которую почти никогда не считают, хотя именно она отличает надёжную систему от той, что уверенно врёт в трудных случаях.
Как собрать тестовый набор
Без набора измерять нечего. Это разовая работа на день-два, которая окупается на первом же изменении настроек.
Берите реальные вопросы. Из обращений, переписки, поисковых запросов по внутренней базе. Придуманные вопросы формулируются словами документа и потому находятся всегда — на них система выглядит лучше, чем есть.
50–100 вопросов для начала достаточно, если они покрывают разные типы: общие, с точными обозначениями, с уточнениями, из разных разделов корпуса.
Для каждого укажите правильный фрагмент (или несколько) и краткий эталонный ответ.
Обязательно включите вопросы без ответа — те, на которые в корпусе сведений нет. Без них нельзя измерить корректность отказа, а это как раз тот класс, где системы чаще всего врут.
Держите набор отдельно от корпуса и не правьте под систему. Набор, подогнанный под текущее поведение, перестаёт что-либо показывать.
Как оценивать
Поиск оценивается автоматически. Известно, какой фрагмент правильный, — проверка сводится к сравнению идентификаторов. Быстро, дёшево, воспроизводимо.
Генерация оценивается сложнее. Три способа:
- Человеком. Точнее всего, дорого, не воспроизводится при каждом изменении.
- Моделью-судьёй. Другая модель оценивает ответ по критериям. Дёшево и повторяемо, но оценка сама по себе приблизительна, и её стоит откалибровать по человеческой на выборке.
- Сравнением с эталоном. Работает для коротких фактических ответов, плохо — для развёрнутых.
Разумная схема: поиск мерить автоматически при каждом изменении, генерацию — моделью-судьёй регулярно и человеком выборочно.
Пример разбора результатов
Условные числа двух версий системы. Показывает, зачем измерять раздельно.
| Метрика | Версия 1 | Версия 2 |
|---|---|---|
| Полнота в первых 20 | 0,71 | 0,93 |
| Полнота в первых 5 | 0,52 | 0,61 |
| Точность в первых 5 | 0,34 | 0,29 |
| Обоснованность ответа | 0,88 | 0,84 |
| Корректность отказа | 0,45 | 0,41 |
| Доля верных ответов | 0,49 | 0,57 |
Что здесь видно.
Версия 2 лучше по конечному результату — 0,57 против 0,49. На этом обычно и останавливаются.
Но раздельные метрики говорят больше. Полнота в первых 20 выросла сильно (0,71 → 0,93) — поиск стал находить нужное. А полнота в первых 5 выросла слабо (0,52 → 0,61): найденное стоит низко. Это прямое указание: следующий шаг — реранкинг, и он даст больше, чем дальнейшая возня с поиском.
Точность при этом упала (0,34 → 0,29): в контекст попадает больше лишнего. Это плата за расширенный поиск, и она же объясняет небольшое снижение обоснованности — модели передают больше шума.
Корректность отказа низкая в обеих версиях (0,45 и 0,41) и не улучшается. Это отдельная проблема, никак не связанная с поиском: системе не задан порог, ниже которого она должна говорить «не знаю». Чинится не поиском, а сценарием отказа.
Что было бы видно по одной метрике. Только «стало лучше на 8 пунктов». Ни того, что надо ставить реранкинг, ни того, что система врёт почти в шести случаях из десяти там, где должна отказаться.
Что мерить в эксплуатации
Тестовый набор показывает качество на фиксированных вопросах. В работе нужны ещё показатели, которые собираются сами:
- доля отказов — растёт, значит корпус отстал от вопросов;
- доля ответов без источника — модель ответила от себя;
- оценка лучшего кандидата от реранкера — распределение показывает, часто ли система работает на слабых фрагментах;
- число переданных фрагментов и объём контекста — прямо влияет на стоимость;
- обращения к человеку после ответа системы — самый честный признак, что ответ не помог;
- кнопка «ответ не помог» — дешёвый источник конкретных случаев для разбора.
Отдельно: прогоняйте тестовый набор после каждого изменения — нарезки, модели, промпта, настроек поиска. Изменение, ухудшившее результат, откатывается. Без этого улучшения одного класса вопросов молча ломают другой.
Частые вопросы
Как измерить качество RAG-системы?
Раздельно по двум частям. Для поиска: попал ли нужный фрагмент в результаты и на какой позиции. Для генерации: подтверждается ли ответ переданными фрагментами, полон ли он и корректно ли система отказывается при отсутствии данных. Одно общее число показывает, что стало хуже, но не показывает, где чинить.
Сколько вопросов нужно в тестовом наборе?
Для начала 50–100 реальных вопросов, покрывающих разные типы: общие, с точными обозначениями, уточняющие, из разных разделов корпуса. Обязательно включите вопросы, ответа на которые в корпусе нет — иначе нельзя проверить, умеет ли система отказываться.
Можно ли оценивать ответы автоматически?
Поиск — да, полностью: известно, какой фрагмент правильный. Генерацию оценивают моделью-судьёй, что дёшево и повторяемо, но саму оценку стоит откалибровать по человеческой на выборке. Полностью автоматическая оценка развёрнутых ответов остаётся приблизительной.
Какая метрика самая важная?
Для поиска — полнота: если нужного фрагмента нет в контексте, всё остальное не имеет значения. Для генерации — обоснованность: подтверждается ли сказанное источниками. Эти две отвечают за то, чтобы система не врала.
Что делать, если поиск находит нужное, но ответ всё равно неверный?
Значит проблема в генерации, а не в поиске, и это редкий случай. Смотрите, сколько фрагментов передаётся: при большом количестве лишнего модель размывает ответ. Проверьте формулировку инструкции и наличие требования отвечать только по переданным источникам.
Как часто нужно мерить?
Тестовый набор — после каждого изменения настроек, нарезки или модели: это единственный способ отличить улучшение от ухудшения. Эксплуатационные показатели — постоянно, они собираются сами и показывают, когда корпус начал отставать от вопросов.
Что дальше
Если полнота низкая — смотрите «Почему RAG не находит документ» и «Чанкинг документов». Если нужное находится, но стоит низко — «Реранкинг». Если система врёт при отсутствии данных — «Цитирование источников». Как считать эффект в деньгах — «Как измерить эффект от внедрения ИИ».
Построение тестового набора и регулярная оценка качества входят в работу по разработке и внедрению ИИ.