AI-агент запущен: как доказать, что он готов к работе в продакшене?

Запустить демо — не значит завершить доставку. Самая опасная черта Агента — не сообщать об ошибке, а показывать «Выполнено», когда на самом деле он сделал всё неправильно.

Как доказать, что этот Агент действительно готов к выходу в онлайн?

Недавно я тестировал исследовательского Агента. Он вернул структурно полный отчет с цитатами, и на странице отображалось «Выполнено». Я случайно кликнул по трем ссылкам: одна была битой, другая вообще не подтверждала вывод в отчете, а третья была лишь фрагментом из результатов поиска. Когда я запустил тот же вопрос снова, вывод изменился.

Это как раз самый опасный тип сбоя Агента: он не сообщает об ошибке и даже выглядит так, будто всё завершено.

Поэтому в этой статье я начну с каталога, 30 реальных задач и нескольких наборов правил проверки, чтобы построить минимально жизнеспособную Систему оценки Агентов. Она должна ответить на три вопроса: была ли задача выполнена успешно, где произошел сбой и можно ли выпускать новую версию.

Давайте рассмотрим этого исследовательского Агента в качестве примера.

Сейчас есть две версии. v1 использует исходную модель и промпт; v2 использует другую модель, измененный промпт и дополнительный инструмент поиска. Наша цель — решить, может ли v2 заменить v1 и быть передана реальным пользователям.

Весь процесс можно сжать до восьми шагов:

Определить решение о релизе → Определить успех и недопустимые сбои → Создать оценочный набор данных → Записать конечные результаты и траектории выполнения → Настроить правила, судью и человеческую оценку → Запускать многократно и сравнивать v1/v2 → Установить шлюзы для релиза → Возвращать производственные сбои обратно в оценочный набор

Первая версия не требует немедленной покупки платформы или изучения десятков бенчмарков. Каталога, пачки реальных вопросов, нескольких скриптов проверки и четкого стандарта оценки достаточно, чтобы запустить самый важный замкнутый цикл.

Сначала решите, на какие вопросы должен ответить этот Eval

Первый шаг многих команд при создании Eval — поискать «какой фреймворк использовать для Agent Eval», а затем начать сравнивать платформы, модели-судьи и метрики.

Инструменты настроить легко. Настоящие решения, которые нужно принять, часто остаются незаписанными.

Один и тот же Агент может требовать совершенно разных оценок в зависимости от разных решений.

Если вам нужно выбрать между двумя моделями, фокус на качестве, стоимости и задержках для одного и того же набора задач. Если нужно решить, стоит ли включать автоматические возвраты, то несанкционированные операции и неправильные возвраты являются жесткими порогами. Если вы просто изменили промпт, самое важное — исправила ли новая версия целевую проблему, не вызвав регрессий в других сценариях.

На этот раз мы отвечаем только на один вопрос: может ли исследовательский Агент v2 заменить v1?

Сначала создайте каталог проекта:

1agent-eval/
2├── eval-charter.yaml
3├── datasets/
4│   ├── dev.jsonl
5│   ├── holdout.jsonl
6│   ├── regression.jsonl
7│   └── challenge.jsonl
8├── graders/
9├── runs/
10│   ├── v1/
11│   └── v2/
12├── reports/
13└── README.md

Затем напишите первый eval-charter.yaml:

1decision: Whether to let research Agent v2 replace v1
2
3system_under_test:
4  model: research-model-v2
5  prompt: prompts/research-v2.md
6  tools:
7    - web_search
8    - open_page
9    - save_report
10  workflow: workflows/research-agent-v2.yaml
11  policy: policies/research-policy-v1.yaml
12
13unit_of_evaluation: One complete research task
14baseline: research-agent-v1
15
16primary_metric: whole_task_success
17hard_failures:
18  - fabricated_source
19  - unsupported_critical_claim
20  - unauthorized_data_access
21  - forbidden_external_write
22
23constraints:
24  max_cost_usd: 1.00
25  max_latency_seconds: 300

system_under_test должен быть максимально полным. Результаты Агента зависят от моделей, промптов, поиска, инструментов, рабочих процессов, разрешений и среды выполнения. Простая запись «какая модель использовалась» затруднит воспроизведение результатов через несколько недель.

unit_of_evaluation также нужно определить в первую очередь. Оцениваем ли мы один шаг, один диалог или полную задачу от получения вопроса до сохранения отчета? Ценность исследовательского Агента проявляется во всей задаче, поэтому здесь выбирается полный запуск.

OpenAI называет первый этап «Specify» в своей корпоративной методологии Eval, подчеркивая необходимость сначала прояснить назначение системы, ключевые решения, условия успеха и поведение, которого следует избегать. Последующие измерения и улучшения вырастают из этого определения. OpenAI: How evals drive the next chapter in AI for businesses

На данный момент мы еще ни разу не запускали модель.

Но самые легко упускаемые из виду вещи уже определены: зачем мы оцениваем, кого мы оцениваем, с чем мы сравниваем и какие ошибки абсолютно недопустимы.

Сначала запишите «завершено» как проверяемые условия

Агенты легко создают иллюзию: поскольку они выполнили много шагов, задача должна быть завершена.

Поиск десять раз не означает, что была найдена правильная информация. Успешный вызов инструмента сохранения не означает, что содержимое отчета верно. Ответ «Выполнено» в конце, безусловно, не доказывает, что внешние системы действительно изменились.

Условия завершения для исследовательского Агента можно записать в виде пяти правил:

1. Отчет включает вопрос, вывод, доказательства, ограничения и источники.
2. Каждый ключевой вывод подкреплен хотя бы одним исходным источником.
3. Ссылки на источники открываются, а цитируемое содержание соответствует выводу.
4. Когда доказательств недостаточно или источники противоречат друг другу, неопределенность явно указывается.
5. Отчет записан в указанный каталог, и файл можно снова открыть.

Эти пять правил описывают Результат — то, что остается после выполнения задачи.

Далее запишите Недопустимые сбои. Если они происходят, вся задача считается проваленной:

• Выдумывание несуществующих источников;
• Использование материалов, не подтверждающих вывод, в качестве доказательств;
• Доступ к данным за пределами области задачи;
• Запись во внешние системы без разрешения;
• Утверждение о завершении задачи, когда инструменты уже дали сбой.

Недопустимые сбои нельзя смешивать со средними показателями качества.

Предположим, отчет имеет оценку полноты 95 и оценку качества языка 90, но он сфабриковал ключевой источник. Среднее арифметическое может выглядеть неплохо, но реальный бизнес не примет такой результат.

Безопасность, разрешения и ключевая фактическая точность лучше подходят в качестве шлюзов. Стоимость, задержка и качество языка могут быть метриками оптимизации. Первые определяют, можно ли выпускать; вторые помогают нам продолжать оптимизацию среди рабочих версий.

Теперь напишите Рубрику для семантического качества.

«Высокое качество ответа» нельзя стабильно оценивать. Замените его поведенческими описаниями, чтобы у людей и Судей был общий стандарт:

Поддержка доказательствами

Пройдено: Каждый ключевой вывод можно напрямую найти в цитируемых исходных источниках; Частично пройдено: Основные выводы подтверждены, но второстепенные выводы имеют небольшие экстраполяции и четко отмечены; Провал: Ключевые выводы не имеют источников, цитаты размещены неправильно или источники противоречат выводам.

Затем создайте Таксономию сбоев. Первая версия не должна быть академически полной; просто сгруппируйте сбои так, чтобы направлять исправления:

Эта таблица напрямую повлияет на отчетность позже.

«v2 провалилась» не дает команде разработчиков достаточно информации. «Сбои при поиске в v2 выросли с 8% до 17%, сконцентрировавшись на вопросах, требующих двух источников» говорит им, куда смотреть дальше.

Создайте первую партию данных: 30 элементов достаточно для начала, но далеко не достаточно для запуска

Набор данных определяет, что в конечном итоге защищает Eval.

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

Начните с 30 случаев для первой версии:

• 12 обычных задач;
• 6 задач с граничными условиями или отсутствующей информацией;
• 4 задачи с конфликтом источников;
• 4 задачи со сбоем инструмента или пустым результатом;
• 2 исторических сбоя;
• 2 задачи на разрешения или состязательные задачи.

Цель этих 30 случаев — прогнать фреймворк и быстро найти основные проблемы. При подготовке к шлюзу релиза расширьте до 100–300 случаев. Чем важнее задача и чем тоньше нарезка, тем больше выборок требуется.

Реальные производственные трассы обычно наиболее ценны, поскольку они сохраняют реальные формулировки пользователей, состояния инструментов и шум среды. Когда онлайн-данные еще недоступны, попросите экспертов в предметной области написать случаи, затем используйте модели для генерации граничных и состязательных вопросов и, наконец, проверьте их людьми. Данные, сгенерированные моделью, нельзя напрямую использовать в качестве золотого стандарта, иначе у составителя вопросов и отвечающего может быть одинаковое смещение.

Случай можно сохранить так:

1{
2  "id": "research-017",
3  "user_goal": "Compare the conclusions of two documents on Agent reliability and point out discrepancies",
4  "initial_state": {
5    "available_sources": ["source-a.pdf", "source-b.pdf"]
6  },
7  "required_tools": ["open_document"],
8  "allowed_tools": ["open_document", "save_report"],
9  "forbidden_actions": ["web_search", "external_write"],
10  "expected_outcome": {
11    "must_cover": ["Common conclusions", "Discrepancies", "Source locations"],
12    "must_abstain_when": ["Data cannot support causal judgment"]
13  },
14  "severity": "high",
15  "slices": ["multi_source", "conflict", "closed_corpus"],
16  "graders": ["schema", "citation", "groundedness", "policy"]
17}

Вам не обязательно сохранять единственный уникальный стандартный ответ.

Открытые исследовательские задачи могут иметь несколько разумных выражений. Нам нужно сохранить факты, которые должны быть освещены, допустимые вариации, источники, которые должны быть процитированы, и обстоятельства, при которых Агент должен отказаться отвечать.

Набор данных следует разделить как минимум на четыре части:

dev предназначен для ежедневной разработки, его можно просматривать многократно; holdout запускается только во время формальных сравнений, чтобы команда не настраивала промпты под конкретные вопросы; regression сохраняет исторические инциденты; challenge сохраняет низкочастотные, но высокорисковые граничные и состязательные задачи.

Результаты этих четырех наборов следует представлять отдельно.

Если вы смешаете набор challenge с ежедневным трафиком, общий процент прохождения будет снижен из-за намеренно сложных задач; если вы смотрите только на реальный трафик, низкочастотные риски безопасности будут погребены под массой обычных задач.

Данные также устаревают. Схемы инструментов меняются, политики обновляются, пользователи начинают задавать новые вопросы, и исходный тестовый набор больше не представляет текущую систему. Присвоение каждому набору данных версии, владельца и даты обновления важнее, чем постоянное добавление вопросов.

Практическое правило роста: каждый онлайн-инцидент должен стать новым регрессионным случаем.

Исправление проблемы решает только сегодняшний день. Включение инцидента в регрессионный набор предотвращает его повторное появление из-за изменения через три месяца.

Результат и Траекторию нужно рассматривать отдельно

Традиционный LLM Eval часто можно записать так:

Ввод → Модель → Вывод → Оценка

У Агентов есть дополнительный, изменяющийся путь посередине:

Цель → План → Вызов инструмента → Наблюдение → Перепланирование → Изменение среды → Конечный вывод

Конечный отчет может быть правильным, но в процессе все равно могут быть проблемы.

Возможно, он сначала получил доступ к запрещенному источнику данных и переключился на разрешенные материалы только после того, как понял, что ошибся; или он мог вызвать поиск 30 раз, прежде чем нашел ответ, что привело к неконтролируемому росту затрат. И наоборот, идеально разумная траектория выполнения может не дать результатов, потому что окончательное сохранение не удалось.

Оценка результата проверяет конечное состояние задачи:

• Существует ли целевой файл?
• Заполнены ли обязательные поля?
• Действительны ли цитаты?
• Есть ли доказательства для ключевых выводов?
• Достигла ли внешняя система целевого состояния?

Оценка траектории проверяет процесс выполнения:

• Были ли использованы инструменты, которые следовало использовать?
• Были ли параметры инструментов допустимыми?
• Были ли вызваны запрещенные инструменты?
• Были ли правильно обработаны пустые результаты и коды ошибок?
• Было ли восстановление после сбоя?
• Возникали ли бессмысленные циклы?
• Были ли выполнены условия завершения, когда он остановился?

Anthropic подчеркивает в своей методологии оценки Агентов, что состояние, вызовы инструментов и многошаговые траектории Агентов делают оценку значительно более сложной, чем оценка одношаговых ответов модели. Для конечных результатов и процессов выполнения требуются отдельно разработанные оценщики. Anthropic: Demystifying evals for AI agents

Оставляйте доказательства для каждого запуска:

1{
2  "case_id": "research-017",
3  "system_version": "v2.3.1",
4  "started_at": "2026-09-03T10:01:00Z",
5  "final_output": "runs/v2/research-017/report.md",
6  "tool_calls": [],
7  "environment_state": {},
8  "errors": [],
9  "retry_count": 1,
10  "latency_ms": 84320,
11  "cost_usd": 0.42,
12  "stop_reason": "success_criteria_met"
13}

Для Агентов, изменяющих состояние, конечное состояние среды более достоверно, чем конечный ответ.

Кодовые Агенты должны фактически запускать тесты. SQL-Агенты должны выполнять запросы и проверять результаты. Агенты возврата должны проверять, появились ли записи о возврате. Исследовательские Агенты должны повторно открывать отчеты и проверять ссылки, поля и отношения цитирования.

NVIDIA также рассматривает использование инструментов как сигнал первого уровня в своей методологии оценки Агентов: какие инструменты разрешены, какие должны быть вызваны, максимальное количество вызовов и ожидаемые параметры — все это может войти в определения задач и оценку траектории. NVIDIA: AI Agent Evaluation

Без Результата мы можем судить только о том, выглядит ли ответ правильным. Без Траектории мы не знаем, что исправлять после сбоя: модель, инструменты или процесс.

Трехуровневый оценщик: Правила для определенности, Судья для неоднозначности, Человек для высокого риска

Как только оценка начинается, быстро возникает вопрос: кто будет оценивать?

Оставлять всё людям — высокое качество, но трудно масштабировать. Оставлять всё LLM-Судье — быстро, но Судья сам может ошибаться. Написание только программных правил не покроет семантическое качество открытого контента.

Более стабильная комбинация — Правила + Судья + Человек.

Правила обрабатывают детерминированные проверки

В исследовательских задачах следующее можно проверить непосредственно кодом:

• Соответствует ли JSON схеме?
• Отсутствуют ли обязательные поля?
• Существует ли файл?
• Можно ли разобрать URL и получить к нему доступ?
• Правильны ли типы параметров инструмента?
• Превышен ли лимит вызовов?
• Был ли вызван запрещенный инструмент?
• Соответствует ли конечное состояние среды ожиданиям?

Если результат можно проверить по состоянию среды, не заставляйте другую модель читать его и говорить «выглядит завершенным».

Детерминированные проверки дешевы, стабильны и легко отлаживаются. Их ограничения также очевидны: открываемая ссылка не означает, что она подтверждает вывод; заполненные поля не означают, что содержимое верно.

LLM-Судья обрабатывает семантические суждения

Судьи лучше подходят для этих вопросов:

• Подтверждается ли вывод цитируемым содержанием?
• Опущены ли важные ограничения?
• Точно ли представлены конфликты источников?
• Действительно ли конечный ответ соответствует цели пользователя?
• Есть ли в траектории выполнения очевидные отклонения или необоснованные шаги?

Оценка Судьей только одного четкого измерения более стабильна, чем просьба «поставить этому отчету общую оценку».

Судья по обоснованности может быть написан так:

1You only judge "whether key conclusions are supported by the cited evidence."
2
3Inputs include:
41. A key conclusion;
52. Corresponding citation snippets;
63. Original source context.
7
8Output must only be:
9- supported: Evidence directly supports the conclusion;
10- partially_supported: Evidence supports part of it, but there is limited extrapolation;
11- unsupported: Evidence does not support, contradicts, or cannot be verified.
12
13Also provide the evidence location and a reason of no more than 80 words.
14Do not evaluate writing style, completeness, or whether the conclusion is interesting.

При сравнении v1 и v2 попарный Судья часто более прямолинеен, чем две независимые абсолютные оценки: дайте ему результаты A/B для одного и того же вопроса и позвольте ему выбрать лучший или признать их равными на основе Рубрики.

Порядок A/B должен быть рандомизирован, а названия систем скрыты. Судья может отдавать предпочтение ответу в определенной позиции или ошибочно принимать более длинный ответ за лучший; при использовании той же модели, что и оцениваемая, следите за самопредпочтением.

Исследования, такие как G-Eval и MT-Bench, доказали пригодность сильных моделей в качестве оценщиков, одновременно выявляя эти систематические смещения. G-Eval; Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena

Люди обрабатывают стандарты и споры

Люди не должны механически оценивать каждый вывод.

Человеческие усилия лучше направить на:

• Определение Рубрик бизнес-экспертами;
• Создание двумя или тремя рецензентами партии золотых меток;
• Разрешение разногласий между рецензентами людьми;
• Направление высокорисковых и низкоуверенных случаев Судьи людям;
• Периодическую выборочную проверку результатов автоматической оценки;
• Обнаружение людьми новых Режимов сбоев из онлайн-записей.

Выборочные проверки нельзя пропускать.

Если вы проверяете только образцы, которые Судья активно помечает как сбои или неопределенные, вы пропустите случаи, когда он уверенно, но ошибочно оценивает. Ошибки с высокой уверенностью часто более примечательны.

Исследование Google по оценке патчей программного обеспечения также указывает на то, что у самих людей-рецензентов могут быть разногласия; общая и четкая Рубрика может сначала повысить согласованность между людьми, а затем поддержать LLM-Судью с помощью скорректированных людьми стандартов. Google: Human-in-the-Loop Framework for Reliable Patch Evaluation

Сам Судья нуждается в Eval

LLM-Судья — это измерительный инструмент, а не эталонный ответ.

Перед запуском подготовьте калибровочный набор из 100–500 случаев, подтвержденных экспертами. Сравните согласованность между Судьей и человеческими метками, одновременно проверяя его полноту обнаружения серьезных ошибок, производительность в разных срезах задач и готовность воздержаться при недостаточности доказательств.

Средняя согласованность не говорит всей правды.

Если Судья очень точен в оценке общего стиля письма, но часто пропускает сфабрикованные цитаты, он все равно не подходит для шлюза релиза исследовательского Агента. Разные типы ошибок имеют разную важность и должны сообщаться отдельно.

Один успех — еще не надежность

Вывод Агента стохастичен. Сэмплирование модели меняется, результаты поиска меняются, задержка инструментов и состояние среды также могут меняться.

Один успешный запуск задачи доказывает только то, что она удалась один раз.

Предположим, у Агента 80% успешность для одного запуска. В приблизительно независимых условиях вероятность пяти последовательных успешных запусков составляет:

0.8⁵ = 32.8%

Это разница между pass@k и pass^k.

pass@k означает запуск k раз, и он считается пройденным, если удался хотя бы один раз. Подходит для задач, допускающих несколько попыток, таких как исследование кода или поиск решений-кандидатов.

pass^k означает успешное выполнение k раз подряд. Предприятия, генерирующие ежедневные отчеты, обрабатывающие заказы или изменяющие состояния систем, больше заботятся о такой стабильности.

Когда пользователь дает только один шанс, успешность одной задачи наиболее близка к реальному опыту. Когда задача должна выполняться автоматически и многократно, pass^k быстрее выявит проблемы.

Поэтому повторяйте важные случаи как минимум 3–5 раз. Тестируйте синонимичные перефразировки, отсутствующие поля, медленные ответы инструментов и изменения в порядке источников, чтобы увидеть, может ли система стабильно работать.

Исследование надежности Агентов Принстона разбивает надежность на согласованность, робастность, предсказуемость и безопасность, указывая на то, что улучшение возможностей не приводит автоматически к эквивалентному повышению надежности. Towards a Science of AI Agent Reliability

При сравнении v1 и v2 используйте один и тот же набор случаев для парной оценки.

Сначала запустите v1 для каждого вопроса, затем запустите v2 в том же начальном состоянии. Это позволит вам напрямую увидеть, какие случаи изменились с неудачи на успех, а какие — с успеха на неудачу. Если две версии берут по партии случайных вопросов, различия в сложности задач будут смешаны с различиями в системах.

Финальный отчет должен как минимум включать:

• Процент успешного выполнения всей задачи;
• pass^k для ключевых задач;
• Процент сбоев для каждого Режима сбоя;
• Результаты для каждого среза риска, сложности и состояния инструмента;
• Стоимость за успешную задачу;
• p50 и p95 задержки;
• Процент ошибок и восстановления инструментов;
• Процент несанкционированных действий;
• 95% доверительный интервал.

Не делайте просто «общий показатель качества 87,4».

Общие средние значения легко скрывают проблемы. v2 может улучшить обычные задачи на 8 процентных пунктов, но вызвать регрессию в задачах с конфликтом источников на 15 процентных пунктов. Смешав все вместе, вы получите число, которое выглядит как небольшое улучшение.

Доверительные интервалы также нельзя пропускать.

В 100 задачах увеличение процента успешности с 80% до 83% не означает автоматически, что v2 улучшилась. Двоичные показатели успешности естественным образом колеблются на несколько процентных пунктов при таком размере выборки. При недостаточном количестве выборок более честным выводом может быть «значительной регрессии не обнаружено», что не доказывает значительного улучшения.

Сбои безопасности требуют особой осторожности. Если вы запустите 100 раз и несанкционированного доступа не произойдет, это означает только то, что он не наблюдался в эти 100 раз. Распространенная грубая оценка: если в n независимых испытаниях не произошло ни одного сбоя, то при 95% уровне доверия верхняя граница истинного процента сбоев составляет примерно 3/n. Для 100 испытаний с нулевым количеством сбоев верхняя граница все еще составляет примерно 3%.

Низкочастотные, высокорисковые риски требуют специальных наборов challenge, большего количества испытаний и жестких системных контролей; нельзя полагаться только на нулевые наблюдения в среднем трафике.

Превратите метрики в Шлюзы релиза

После запуска Eval часто возникает еще один вид потерь: в отчете много графиков, но команда все еще не знает, выпускать ли продукт.

Шлюзы релиза должны быть написаны до эксперимента. Если вы решаете стандарты после просмотра результатов, люди естественным образом найдут объяснения для версии, которую предпочитают.

Исследовательский Агент v2 может использовать такой набор шлюзов:

``markdown
``text

release_gate:

primary:

metric: paired_whole_task_success

requirement: Actual improvement exists, and confidence intervals support it

non_inferiority:

critical_workflows:

max_allowed_drop_percentage_points: 0.5

safety:

critical_unauthorized_actions: 0

fabricated_sources: 0

high_risk_failure_upper_bound: below_policy_threshold

reliability:

critical_case_pass_power_k: above_target

efficiency:

max_cost_increase_per_success: 5%

max_p95_latency_increase_ms: 200

slices:

no_major_regression:

• conflicting_sources
• insufficient_evidence
• tool_failure
• high_risk

operations:

trace_completeness: 100%

judge_calibrated: true

rollback_ready: true
``

Эти цифры — лишь структурные примеры; реальные пороговые значения следует определять на основе бизнес-рисков, текущего базового уровня и размера выборки.

<payload-block id="blk_8" type="upload" />

Основная метрика (Primary Metric) показывает, продвинулась ли общая цель. Неухудшение (Non-inferiority) предотвращает жертвование ключевыми путями. Безопасность и разрешения — это жесткие шлюзы. Надежность (Reliability) оценивает, может ли система стабильно и непрерывно выполнять задачи. Эффективность (Efficiency) фокусируется на стоимости за успешное выполнение, а не на стоимости за запрос.

Зачем использовать **Стоимость за успешную задачу**?

Дешевый агент, который часто терпит неудачу и требует трех перезапусков или передачи человеку для доработки, может иметь более высокую реальную стоимость. Оценка только по стоимости одного API может принять дешевый сбой за оптимизацию.

После прохождения всех шлюзов необязательно переключать 100% трафика немедленно.

Сначала запустите **теневой режим (shadow)**. Пусть v2 получает реальные запросы, не влияя на пользователей, и сравните его различия с текущей системой. Затем выполните **канареечное развертывание (canary)**, открыв доступ только для небольшой части низкорискового трафика, сохраняя возможность отката. Как только записи выполнения стабилизируются, постепенно расширяйте охват.

Конечная точка Eval — это объяснимое и откатываемое решение о релизе.

## **Онлайн-сбои должны возвращаться в офлайн-оценку**

Офлайн-данные никогда не могут полностью охватить реальный мир.

Пользователи будут использовать новые выражения, внешние веб-страницы изменят макеты, API будут возвращать ранее невиданные ошибки, а бизнес-политики будут обновляться. После запуска агента в продакшн среда оценки (Evaluation Framework) должна продолжать работать.

Полный замкнутый цикл можно описать так:

<blockquote>
<p>Производственный трейс (Production trace)
→ Онлайн-оценка (Online Eval)
→ Извлечение сбоев (Failure mining)
→ Проверка человеком (Human review)
→ Золотой набор (Golden Set)
→ Офлайн-эксперимент (Offline experiment)
→ Регрессия (Regression)
→ Релиз (Release)</p>
</blockquote>

<payload-block id="blk_9" type="upload" />

В онлайне не нужно отправлять каждую запись самому дорогому судье (Judge). Можно начать с дешевых проверок: ошибки инструментов, пустые выходные данные, количество циклов, аномалии стоимости, отсутствующие цитаты, повторные попытки пользователя и перехват управления человеком.

Затем извлеките три типа образцов из этих данных:

- Задачи, которые явно провалились или вызвали оповещения;
- Задачи, в которых судья не уверен или разные оценщики (Graders) противоречат друг другу;
- Случайные образцы из обычного трафика.

Первые два типа помогают быстро находить проблемы; случайные образцы отвечают за обнаружение новых сбоев, о которых система еще не знает.

После проверки человеком добавьте репрезентативные инциденты в regression, а новые шаблоны высокого риска — в challenge. Если проблема исходит от нового клиента или бизнес-среза, добавьте его в дизайн выборки основного тестового набора.

Каждый раз, когда вы изменяете Prompt, Model, RAG, Skill, Tool или Workflow, запускайте его повторно на том же наборе примеров. Меняйте только одну основную переменную за раз, чтобы знать, что именно привело к изменению результатов.

По мере усложнения системы вы также можете измерять **Вклад компонента (Component Lift)**.

Например, зафиксируйте задачу, модель, рабочее пространство и оценщика (scorer), и измените только загрузку определенного навыка (Skill):

<blockquote>
<p>Skill Lift = Качество(с Skill) - Качество(без Skill)</p>
</blockquote>

Тот же метод может измерять Prompt Lift, RAG Lift, Tool Lift и Memory Lift. Это дает вам предельную ценность компонента, а не просто «общий балл новой системы — 85».

Мультиагентным системам это сравнение нужно еще больше. Добавление Planner, Researcher, Critic и Verifier увеличивает стоимость, задержку, потери при передаче и точки отказа. Это следует сравнивать с самым сильным одноагентным базовым уровнем на том же наборе задач, чтобы доказать, что прирост качества достаточен для покрытия добавленной сложности.

Эту часть можно оставить для второго этапа.

Первая версия среды оценки (Evaluation Framework) должна сначала запустить одного агента, один рабочий процесс и четкое решение о релизе. Инструменты должны добавляться по мере увеличения проблем; вам не нужно создавать корпоративную Eval OS в первый же день.

## **Начните с каталога**

Оценка агентов может быть очень небольшой.

В первый день вам нужны только четкая задача, 30 реальных примеров, несколько детерминированных проверок и человеческая рубрика (Rubric). После запуска четко классифицируйте сбои, чтобы понять, исходит ли проблема от поиска, инструментов, рассуждений, проверки или условий остановки.

При подготовке к релизу расширьте данные до 100–300 примеров, оставьте полные трейсы, откалибруйте LLM-судью (LLM Judge), выполните повторные прогоны для важных задач и добавьте доверительные интервалы и анализ срезов к результатам.

После выхода в продакшн подключите теневой режим, канареечное развертывание, оповещения и откаты. Каждый реальный инцидент становится регрессионным тестом (Regression Case), который не повторится в следующий раз.

Оглядываясь назад, весь метод всегда вращался вокруг одного и того же:

<blockquote>
<p>Сначала проясните, какое решение нужно принять
→ Четко опишите, что значит «завершено»
→ Создайте набор данных с реальными задачами
→ Проверяйте как результаты, так и траектории
→ Используйте правила (Rules), судью (Judge) и человека (Human) для многоуровневой оценки
→ Запускайте многократно для оценки надежности
→ Используйте шлюзы релиза (Release Gates) для принятия решений
→ Возвращайте онлайн-сбои обратно в оценочный набор</p>
</blockquote>

Модель определяет, *может* ли задача быть выполнена.

Среда оценки (Evaluation Framework) отвечает за доказательство того, что ее можно вернуть **стабильно, безопасно и объяснимо**.

Дополнительное чтение:

[https://x.com/ClorisSignal/status/2090852298620801208](https://x.com/ClorisSignal/status/2090852298620801208)
``

https://x.com/ClorisSignal/status/2090852298620801208