Чем отличается от соседних заметок Agent Evals отвечает, что мерить у агента и как устроен шлюз. RAG Metrics даёт готовый дашборд для RAG. Эта заметка — про то, откуда метрика вообще берётся, когда готовой нет.
Организационная ошибка, с которой всё начинается
Инженеров изолируют от предметных экспертов: бизнес заказывает интеллект, инженеры запираются и начинают его воспроизводить. Проблема в том, что они точно не знают, что воспроизводить, и придумывают метрики, удобные и понятные только им самим.
Метрики рождаются из практики реальных проблем реального продукта. Для чат-бота поддержки список выглядит так: ответ не решает проблему; ответ кажется правильным, но ошибочен (страшнее первого); ответ оскорбляет пользователя (ещё страшнее). Составить такой список может только тот, кто знает, что система должна делать.
Три класса задач меряются по-разному
| Класс | Как измеряется |
|---|---|
| Есть точный ответ | Сравнение с эталоном — точным совпадением, текстовыми метриками или отдельной моделью. Наглядная форма: доля случаев с правильным ответом |
| Ответ можно проверить | Прогнать проверку: тесты для кода, формальная верификация для доказательства. Наглядная форма: доля решённых задач, иногда с k попытками |
| Правильный ответ неизвестен | Продуктовые критерии: что такое хороший ответ. Каждый критерий переводится в бинарный и агрегируется |
Третий класс — самый трудный и самый частый: там лежит большинство интересных задач.
Оснастка вокруг неверного критерия производит надёжный мусор
Довод, из-за которого эта заметка стоит раньше всех остальных по порядку работ. Проверки, гейты, автоматические прогоны и бюджеты усиливают выбранный критерий приёмки, а не исправляют его. Критерий неверен — и вся конструкция начинает надёжно, воспроизводимо и в масштабе выдавать не то, причём с зелёными отчётами.
Направление здесь важнее оговорки: плохая оснастка вокруг верного критерия даёт шумный результат, который видно; хорошая оснастка вокруг неверного даёт ровный результат, который не видно, потому что все индикаторы зелёные по построению.
Практическое следствие: прежде чем вкладываться в проверки, надо предъявить критерий тому, кто знает предметную область, и получить от него «да, вот это и есть хороший ответ». Порядок обратный привычному — сначала выстраданная разметка, потом автоматизация вокруг неё, а не наоборот.
Инструкцию разметки нельзя написать — её выстрадывают
Ключевой шаг. Предметный эксперт не может запереться и написать критерии: получится текст, оторванный от практики. Работающая процедура:
- Выписать критерии один раз и объяснить команде.
- Взять небольшую корзинку — например, сто примеров — и разметить всей командой с перекрытием, вслепую, по два человека на пример.
- Обсудить все расхождения: почему одному ответ релевантен, а другому нет.
- Занести результат обсуждения в инструкцию и повторять, пока согласованность не станет приемлемой.
Смысл процедуры в одном: субъективность в разметке высушивается до минимума. В теории критерии всем понятны; на реальных данных всё ломается — плохие ответы получают хороший вердикт, хорошие плохой, а часть критериев вообще непонятно как применять.
Просмотрщик данных — условие, а не удобство
Чтобы построить метрику, смотреть придётся много. Значит, каждому члену команды должно хотеться заглянуть в данные, а не продираться через двадцать колонок и тридцать кликов. Агрегируется всё нужное для понимания случая: контекст диалога, вопрос, ответ, важные внешние факторы.
Выбор инструмента зависит от задачи: таблицы — самый дешёвый вариант, но плохо показывают длинные диалоги и ломаются при массовой разметке; специализированные платформы разметки дают инструменты для потока; трассировочные системы удобнее всего для отладки агентов (Agent Observability).
Кто размечает
Люди — там, где нужна глубокая доменная экспертиза: достоверность юридической консультации оценит только человек с практикой и нормативкой под рукой. Операционно это тяжело: обучение, экзамен по заранее размеченным примерам, регулярный контроль качества, борьба с халтурой.
Модель-судья — там, где задача проще: настраивается быстрее, размечает за сутки то, что люди делали бы годами, и главное — не требует операционной работы (LLM as Judge). Качество судьи меряется как задача первого класса: сами размечаем корзинку, сравниваем вердикты, считаем долю совпадений.
Метрика живёт не дольше продукта
Продукт меняется, пользователи задают другие вопросы, появляется новый функционал. Проверка: собрать свежую эталонную корзинку и посмотреть, работают ли текущие метрики. Если критерии устарели — возвращаться к шагу с инструкцией; если разметка испортилась — к настройке разметчиков.
Итеративный цикл, в котором метрика применяется
Метрика нужна не сама по себе, а чтобы двигаться по проблемам: собрать корзинку входных задач, оценить качество, кластеризовать проблемы по двум осям — по тематикам и по причинам поломки. Дальше на каждую проблему: гипотеза → реализация → замер → принять или отбросить.
Правило, которое чаще всего нарушают: проверять по одной гипотезе за раз. Десять одновременно накрученных ручек не дают понять, какая сработала.
Связано с
- Agent Evals — что мерить и как устроен шлюз качества
- LLM as Judge — калибровка судьи и его искажения
- RAG Metrics — готовый дашборд, когда домен типовой
- Agent Observability — где смотреть трассы при разметке
- Intelligence vs Judgment — почему без протокола метрики не строятся
- Behavioral Evals — оценка поведения, а не только исхода
- Benchmarks Agents — почему чужой бенчмарк не заменяет свою метрику
- Harness Optimization — оснастка как настраиваемый параметр; здесь про то, что она усиливает, а не выбирает