Короткий ответ
Метрики RAG: Recall@k, citation precision, groundedness и правильный отказ — это production-задача, а не демонстрационный prompt. Практический принцип: держать отдельные показатели retrieval и generation, чтобы регрессия поиска не маскировалась красивым ответом. Ключевое решение: для инженерного RAG критична способность отказаться от ответа, когда в разрешённых источниках нет подтверждения. В инженерной среде результат принимается по evidence, traceability и воспроизводимой проверке, а не по уверенности формулировки модели.
Граница системы и предмет контроля
Эффективность ИИ нельзя измерять числом сгенерированных ответов или субъективной активностью пользователей. Нужна цепочка от технического качества к процессному результату: корректность и groundedness → доля успешно завершённых задач → вмешательства и откаты → цикл выполнения → дефекты и переделки → стоимость и загрузка специалистов. Без baseline любое улучшение превращается в маркетинговую интерпретацию.
Метрики должны быть связаны с типом задачи. Для RAG важны retrieval и citation; для агента — tool-selection, completion и side effects; для инженерного документа — число существенных правок и время проверки; для производства — lead time и rework. Финансовый ROI считают только после отделения эффекта ИИ от сезонности, обучения команды и параллельных изменений процесса.
Что должно быть определено до запуска
Артефакты и архитектурные границы
Измерительный контур должен связывать offline eval, production telemetry и процессные данные. Offline набор отвечает на вопрос «может ли версия пройти известные кейсы», traces — «как она реально выполняет работу», ERP/QMS/MES или task system — «изменился ли производственный результат». Только совместный анализ отделяет улучшение модели от эффекта организационных изменений.
Для сравнения версий фиксируют denominator, период, сегменты сложности и правила исключения. Среднее значение почти всегда недостаточно: latency анализируют распределением, quality — по классам задач и severity, экономику — на успешную задачу требуемого качества, а редкие критические инциденты — отдельным абсолютным счётчиком.
Практический workflow
Каждая метрика связывается с версией системы и конкретным классом задач. Изменение определения метрики или набора кейсов требует новой версии baseline, иначе сравнение до/после теряет смысл.
Инженерный сценарий
Измерение начинают до внедрения: baseline собирают теми же определениями и на той же единице работы, что и после запуска. Иначе последующий ROI нельзя отделить от изменения способа учёта.
Что измерять
Ниже — явно заданный профиль оценки этой статьи, а не названия или пороги конкретного vendor evaluator. Для каждого запуска фиксируются corpus/revision, ACL, query set, k, единица релевантности и правила экспертной разметки. Document ID и chunk ID нельзя смешивать в одном знаменателе.
Recall@k(q) = |R(q) ∩ T_k(q)| / |R(q)|R(q) — все размеченные релевантные документы для запроса q в разрешённом корпусе; T_k(q) — уникальные document IDs в первых k результатах. Знаменатель — число всех релевантных документов, а не k. Если |R(q)| = 0, recall не определён: запрос оценивается в наборе отказов.citation precision = поддержанные связи / все выданные связи claim–citationСвязь считается корректной, если указанный фрагмент нужной revision действительно подтверждает claim и применим к запросу. Знаменатель включает неверные, недоступные и несвязанные с claim citations. При отсутствии citations показатель не определён; отсутствие обязательной цитаты отдельно отмечается как ошибка.grounded claim rate = подтверждённые claims / все проверяемые фактические claims ответаРазметка делит ответ на атомарные claims. Числитель содержит claims, подтверждённые разрешённым контекстом; знаменатель включает claims без evidence. Это наш профиль groundedness, а не 1–5 score provider grader. Ответ без фактических claims оценивается отдельно, а не получает автоматически 100%.correct abstention = правильные отказы / все вопросы, требующие отказаЭксперт заранее отмечает вопросы без достаточного разрешённого evidence. Правильный отказ не содержит выдуманного ответа. Дополнительно: false refusal rate = ошибочные отказы / все вопросы с достаточным evidence. Оба знаменателя фиксируются отдельно; пустой класс получает «не определено».critical-query pass rate = прошедшие critical queries / все critical queries набораУспех требует одновременно корректного ответа или обоснованного отказа, действующей revision, допустимых citations и соблюдения ACL. Порог выбирает владелец риска до запуска; средний recall не компенсирует критическую ошибку.Условный расчёт: не результат внедрения
Пусть для одного запроса размечены четыре релевантных document IDs, а top-5 содержит три из них: Recall@5 = 3/4 = 75%. Если из пяти выданных связей claim–citation подтверждены четыре, citation precision = 4/5 = 80%. Если ответ содержит шесть фактических claims и подтверждены четыре, grounded claim rate = 4/6 ≈ 66,7%. На отдельном наборе из десяти вопросов без evidence девять получили корректный отказ: correct abstention = 9/10 = 90%; на двадцати отвечаемых вопросах два ошибочных отказа дают false refusal rate = 2/20 = 10%. Числа условные и не являются нормативными порогами.
По нескольким запросам macro recall — среднее определённых Recall@k(q); micro recall — сумма найденных релевантных IDs, делённая на сумму релевантных IDs по запросам. Выбранное агрегирование указывается в отчёте; критичные запросы и случаи отказа показываются отдельными срезами. Groundedness не доказывает полноту ответа: покрытие обязательных claims проверяется отдельно.
Критерии приёмки
| Контроль | Минимальный критерий |
|---|---|
| Scope | Для «Метрики RAG: Recall@k, citation precision, groundedness и правильный отказ» однозначно определено, что система делает и что остаётся вне её полномочий. |
| Data | Все входы имеют источник, revision/status и область применимости; неизвестные значения не подставляются автоматически. |
| Control | сегментация по типу запроса; ручная проверка спорных claims; eval на фиксированном corpus. |
| Evidence | Сохраняются retrieval matrix, claim-citation matrix, groundedness score, abstention report; по ним можно восстановить ход операции. |
| Quality | Минимум две профильные метрики контролируются на versioned eval-наборе: Recall@k и citation precision. |
| Release | Изменяющие действия имеют approval/rollback там, где цена ошибки выходит за согласованный риск. |
Таблицу можно прокручивать по горизонтали →
Failure modes и защитные меры
- high recall с нерелевантным контекстом. Защитная мера: измерение precision@k и качества ранжирования вместе с recall; разбор нерелевантных кандидатов по типам запросов; событие сохраняется как regression/incident case.
- правильный ответ с неправильной цитатой. Защитная мера: проверка каждой связи claim–citation по фрагменту, revision и применимости; спорные связи проверяет эксперт; событие сохраняется как regression/incident case.
- grader не замечает устаревшую revision. Защитная мера: разметка действующих и superseded revisions и отдельные негативные cases; grader проверяет status и дату действия, а не только текстовое сходство; событие сохраняется как regression/incident case.
- система отвечает при отсутствии данных. Защитная мера: набор вопросов без достаточного evidence, проверка отсутствия unsupported claims и явный отказ; отдельно измеряются пропущенные и ошибочные отказы; событие сохраняется как regression/incident case.
- метрика усредняет critical queries. Защитная мера: отдельные результаты для critical-query slice и индивидуальный quality gate для критичных ошибок; общий средний балл не заменяет этот gate; событие сохраняется как regression/incident case.
Как переводить из пилота в production
До пилота фиксируют metric dictionary, baseline window и acceptance thresholds. После запуска сравнивают не отдельные удачные примеры, а стабильный набор задач и production cohorts. Изменение prompt/model без новой версии эксперимента запрещает корректное сравнение.
Для rollout используют shadow, A/B или staged cohort. Решение о расширении основывают на заранее выбранных quality, safety и process gates; финансовый показатель рассматривают после проверки качества, а не вместо неё.
Traceability и эксплуатационная запись
Каждая запись измерения содержит system version, cohort/task class, timestamp, raw outcome, quality result, human corrections, latency/cost и ссылку на process outcome. Агрегаты должны быть воспроизводимы из первичных событий.
Чек-лист перед production
Навигация по Wave AI R5 · часть 5 из 5
Часть «Измерение эффективности» содержит 7 связанных материалов. Серия идёт от архитектуры к контролю и измерению; каждая статья самостоятельна и ссылается на соседние элементы общего production-контура.
Источники и официальная документация
- OpenAI — Evaluate agent workflows
- OpenAI Agents SDK — Tracing
- OpenAI — Agents tracing
- Microsoft — Agentic RAG architecture and evaluation
- NIST — AI Risk Management Framework
- ISO/IEC 42001:2023 — AI management systems
- Microsoft — RAG evaluators: retrieval, groundedness и completeness
Профиль метрик и условный расчёт уточнены 09.10.2026. Определения выше являются профилем этой статьи; шкалы и пороги provider evaluators проверяются отдельно.