Recall, precision и context relevance: метрики retrieval RAG без путаницы

Retrieval — отдельное решение до генерации ответа

RAG может дать гладкий текст, хотя на этапе retrieval выбрал не те доказательства. Поэтому recall, precision и context relevance полезны: они проверяют переход от вопроса к контексту, который получает модель. Это не универсальный балл и не гарантия безопасного финального ответа.

Практическая единица оценки — объявленный кейс: вопрос, разрешённый корпус и его версия, доказательство, которое должно находиться, настройка top-k и ожидаемый безопасный маршрут. Без такого контракта два человека могут посчитать похожую метрику по разным документам и вложить в неё разный смысл.

Три метрики простыми словами

Recall retrieval отвечает на вопрос: нашла ли система доказательство, нужное для этого вопроса? Если актуальный пункт policy должен был попасть в кандидаты, но его нет, у этого кейса низкий recall. Recall не означает, что все выданные фрагменты полезны.

Precision retrieval спрашивает: какая доля найденных фрагментов помогает ответить именно на этот вопрос? Система может найти нужный пункт и ещё десять нерелевантных страниц. Тогда recall может быть хорошим, а precision — слабым: нужное доказательство есть, но модель получает лишний контекст.

Context relevance проверяет, релевантен и достаточен ли контекст, переданный на этап ответа. По сути это вопрос ревьюера к trace: «Может ли этот контекст подтвердить нужное утверждение?» Метрика не заменяет фактчек, контроль доступа, citations и экспертное ревью.

Один сквозной пример

Сотрудник спрашивает: «Какие командировочные расходы требуют согласования руководителя?» В актуальной policy есть нужный пункт; в старой версии есть похожий, но отменённый; в корпусе также лежат шаблоны заявок и общие новости компании.

Для кейса фиксируем актуальный пункт как expected evidence. Запускаем тот же запрос с той же trusted role, locale, фильтрами, версией индекса и top-k, что использует продукт. Затем смотрим на полученные locators.

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

Как работает небольшой цикл оценки

1. Выберите реальные формы вопросов: ожидаемые ответы, неоднозначные запросы и честные no-answer кейсы.
2. Объявите разрешённый корпус и snapshot источников. Retired, private и чужие по scope материалы исключаются до измерения ranking.
3. Запишите expected evidence как стабильный locator или ID, а не только как идеальное предложение ответа.
4. Запустите retrieval с реальными filters, версией индекса и top-k. Сохраните список locators.
5. Посмотрите recall, precision и context relevance по полезным срезам: тип документа, язык, роль, freshness или тип вопроса.
6. Отправьте сбой владельцу слоя: source coverage, lifecycle, access, chunking, query, filters, ranking, answer policy или human review.

Цель — не охота за красивым процентом, а проверяемое следующее инженерное решение.

Где метрики подходят, а где нет

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

Они не доказывают юридическую, медицинскую, финансовую или safety-корректность. Не проверяют права доступа, не решают, является ли источник авторитетным, не измеряют пользовательскую удовлетворённость и не гарантируют правильную интерпретацию cited документа. Для этого нужны отдельные controls и квалифицированное ревью.

Минимальная запись RETRIEVAL-METRICS-8

Ниже синтетическая запись полей, которые стоит сохранять. Это пример метода, а не benchmark и не результат производительности.

{
  "case_id": "policy-approval-current-01",
  "question": "Какие командировочные расходы требуют согласования?",
  "permitted_corpus": "policy-snapshot-2026-09-10",
  "expected_locators": ["travel-policy:v4#approval"],
  "run": {
    "index_version": "idx-42",
    "filters": ["role:employee", "locale:ru", "state:current"],
    "top_k": 5,
    "retrieved_locators": ["travel-policy:v4#approval", "expenses-guide:v2#receipt"]
  },
  "review": { "route": "inspect-precision-before-release" }
}

Если travel-policy:v4#approval отсутствует, сначала исследуйте coverage, lifecycle, filters и retrieval. Если он есть, но окружён нерелевантным контекстом, исследуйте precision и упаковку контекста. Если недостаточно роли пользователя или ясности запроса, маршрут должен быть clarification или safe no-answer, а не скрытое расширение retrieval.

Практический следующий шаг

Начните с 10–20 кейсов из повторяющихся реальных вопросов и отчётов о сбоях. Версионируйте кейсы и источники, сохраняйте trace и проверяйте изменения по срезам до релиза. Тогда у product owner и инженеров появляется общий язык: проблема — не просто «RAG плохо ответил», а конкретный сбой выбора evidence с понятным следующим владельцем.

Для более широкого устройства системы смотрите гайд по RAG-системам и страницу AI-специалист в Армении. Эта статья поддерживает service pages критериями оценки retrieval и не заменяет их широкий коммерческий интент.