Глава 13. Офлайн-оценки, онлайн-оценки и регрессионные шлюзы¶

1. Начнем с вопроса: как не выпустить тот же сбой второй раз¶

Продолжим тот же сценарий поддержки.

Команда уже пережила неприятный инцидент:

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

Но после этого возникает главный инженерный вопрос:

Как сделать так, чтобы похожее ухудшение не вернулось через две недели после очередного изменения промпта, политики или адаптера инструмента?

Вот здесь и начинается контур оценки. В этой книге его нужно читать узко и предметно: как оценочный слой, который решает, заслуживает ли изменение доверия до расширения поэтапного выпуска.

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

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

Трассы помогают понять, что произошло. SLO помогают определить, что считать здоровьем системы. Оценки отвечают на следующий вопрос: можно ли снова доверять этому поведению после изменений.

2. Офлайн-оценки нужны, чтобы менять систему до выката¶

Офлайн-оценки отвечают на очень практичный вопрос:

Если мы меняем промпт, политику, извлечение, маршрутизацию модели или поведение инструмента, станет ли система лучше или хуже на известных критичных сценариях?

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

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

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

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

Сила офлайн-оценок в том, что они позволяют сравнивать версии системы до production-трафика.

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

• process quality;
• outcome quality;
• атрибуция сбоя для controllable и uncontrollable причин.

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

Практический контракт проверяющего (verifier contract) поэтому стоит описывать явно, а не оставлять внутри промпта судьи. Минимальный контракт должен включать:

• rubric_version, чтобы команда понимала, по каким правилам выставлен verdict;
• process_score, который оценивает путь выполнения, а не только финальный результат;
• outcome_score, который оценивает фактический пользовательский или бизнес-исход;
• failure_attribution, включая controllable / uncontrollable и конкретный слой отказа;
• judge_human_agreement, чтобы автоматический судья оставался калиброванным относительно человеческого разбора;
• false_positive_budget и false_negative_budget, потому что у разных шлюзов поэтапного выпуска разная цена ошибки;
• calibration_dataset_id, чтобы изменения судьи, инструкции или рубрики можно было переиграть на стабильной выборке;
• replay_protocol, который показывает, как восстановить трассы, входы, набор политик и версию артефакта для спорного вердикта.

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

На практике полезно сохранять не только текст вердикта, но и маленькую запись вердикта проверяющего, которую также можно отразить в схеме трасс:

• verdict_id: стабильный идентификатор результата проверки;
• verifier_id: какой проверяющий или судья выдал результат;
• verifier_contract_version: версия контракта, по которой выставлен вердикт;
• input_refs: ссылки на сценарий, трассу, версию инструкции/модели и набор политик;
• evidence_refs: доказательства, на которых основан вердикт;
• blocking_decision: блокирует ли вердикт поэтапный выпуск, только предупреждает или требует человеческого разбора;
• comparison_baseline: с какой предыдущей базовой линией выпуска или оценки сравнивался результат;
• reviewer_override: был ли автоматический verdict переопределен человеком и почему.

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

3. Онлайн-оценки нужны, потому что реальный мир всегда шире тестового набора¶

Даже очень хорошие офлайн-оценки не покрывают все, что происходит в production:

• пользователи задают новые типы задач;
• распределение входов меняется;
• внешние системы деградируют;
• база извлечения растет;
• правила политик начинают вести себя иначе на новых данных.

Поэтому онлайн-оценки нужны не как замена офлайн-проверкам, а как второй контур:

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

Для агента поддержки это означает простую вещь: даже если критичный тестовый набор чистый, команда все равно должна видеть, не начал ли агент:

• чаще создавать лишние тикеты;
• чаще эскалировать без необходимости;
• хуже работать с неполными статусами;
• дороже проходить тот же запуск.

4. Лучшая связка — это не “офлайн или онлайн”, а оба контура сразу¶

Очень рабочая модель выглядит так:

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

flowchart LR
    A["Изменение кода / промпта / политики"] --> B["Офлайн-оценки"]
    B --> C["Регрессионные шлюзы"]
    C --> D["Поэтапный выпуск"]
    D --> E["Онлайн-оценки + трассы"]
    E --> F["Анализ сбоев и оценивание"]
    F --> A

Для того же сценария поддержки этот контур означает: инцидент не должен оставаться только в разборе инцидента. Он должен превращаться в оценочный сценарий и в правило поэтапного выпуска.

4.1. Симулятор пользователя полезен там, где статичных кейсов уже мало¶

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

Это особенно полезно, когда команда хочет проверить:

• как агент ведет себя в длинном диалоге;
• как меняется поведение после неидеальных ответов;
• умеет ли система корректно переспрашивать;
• не ломается ли путь политики в многоходовом сценарии;
• не деградирует ли оркестрация при вариативных пользовательских репликах.

Для агента поддержки симулятор пользователя особенно полезен в сценариях вроде:

• пользователь сначала просит проверить статус, потом резко меняет приоритет;
• агент получает неполный request_id;
• после неудачного tool call пользователь присылает новую деталь;
• система должна выбрать: эскалировать, переспросить или безопасно остановиться.

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

4.1.1. Deployment simulation добавляет предрелизный replay реального распределения¶

OpenAI описывает еще один полезный уровень между статичным eval set и живым rollout: deployment simulation.⁶ Вместо того чтобы проверять только специально написанные или adversarial prompts, команда берет реалистичные исторические контексты, приватно очищает их, убирает прежний ответ ассистента и проигрывает тот же префикс на candidate model до релиза. Для agentic settings эта идея требует не просто transcript replay, а правдоподобной симуляции tool environment, потому что одно агентное поведение может зависеть от сотен tool calls, состояния репозитория, сетевых ответов и временных сбоев.

Архитектурный вывод для этой книги простой: pre-release gate должен уметь воспроизводить не только curated incidents, но и кусок реального распределения задач. Минимальный контракт такого replay:

• source_window и правила privacy filtering;
• candidate_model или новая версия policy/runtime;
• replayed conversation_prefix без старого assistant completion;
• simulated или read-only tool_environment_ref;
• verdict по новым failure modes, behavior delta и tool-use regression;
• post-release validation hook, чтобы сравнить прогноз с фактическим rollout traffic.

Deployment simulation не заменяет red team и targeted tail-risk evals. Она закрывает другой пробел: помогает увидеть частые или emerging failures в deployment-like contexts до того, как новый model/runtime/policy попадет к широкому кругу пользователей.

4.1.2. ToolSimulator показывает отдельный контракт для симуляции инструментов¶

AWS ToolSimulator полезен как более узкий, но важный слой рядом с deployment simulation: это LLM-powered tool simulation для агентов, которые зависят от внешних инструментов.²⁰ Вместо live API calls, которые могут раскрыть PII, выполнить реальный side effect или упереться в rate limit, и вместо static mocks, которые плохо держат multi-turn workflows, симулятор генерирует ответы инструментов по registered schemas и поддерживает stateful tool simulations.

Для книги это не аргумент "используй именно Strands Evals". Это недостающий tool simulator contract для любой agent-eval платформы:

• какие инструменты разрешено симулировать, а какие должны быть read-only или запрещены;
• simulated_tool_state, начальное состояние и правила reset между прогоном cases;
• schema enforcement для tool responses и ошибок;
• fault/latency/empty-result cases, которые покрывают recovery path, а не только happy path;
• границы fidelity: что симулятор умеет имитировать, где нужен real sandbox или canary;
• метрики tool simulator fidelity, чтобы команда не путала правдоподобный mock с production-доказательством.

Практический вывод простой: для tool-heavy evals нужно отдельно ревьюить качество симулятора инструментов. Если агент проходит тест только потому, что simulator всегда возвращает удобный ответ, rollout gate должен считать это слабым сигналом, даже если финальный текст выглядит правильным.

4.1.3. Analytics-agent evals должны проверять query path, а не только ответ¶

Кейс GitHub Qubot показывает хороший production pattern для внутреннего analytics agent: context layer и agent configuration меняются через pull request, а затем проходят offline evals с known prompts, ground-truth SQL, metadata, multiple trials и отчетами по completion, accuracy и duration.⁷

Для этой книги важен не сам SQL-agent, а форма eval contract. Внутренний knowledge/data agent должен проверяться не только по тексту финального ответа, а по пути, который привел к нему:

• какой context layer был загружен;
• какие mandatory filters и ownership rules применились;
• какой query engine был выбран и почему;
• есть ли source attribution к dataset/model definition;
• что произошло при недостаточных правах или неоднозначном grain/filter;
• какой trace доказывает, что query review и access boundary не были обойдены.

Такой eval лучше ловит реальные production regressions: agent может дать правдоподобный ответ, но выбрать неправильный grain, пропустить обязательный фильтр, сослаться на устаревшее определение метрики или выполнить query там, где должен был отказать.

4.2. Непрерывный контур оценки должен замыкаться в решения о поэтапном выпуске¶

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

Хорошая операционная схема обычно выглядит так:

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

То есть контур оценки полезно мыслить не как “отдельную аналитическую активность”, а как часть управляемого change management.

Эта граница важна, потому что оценки (evals) не стоит перегружать чужими функциями жизненного цикла. Их задача — производить суждения, которыми поэтапный выпуск может пользоваться дальше, а не заменять реагирование на инциденты, дизайн телеметрии или владение парком систем.

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

Отдельный lifecycle-риск — путать eval discipline с конкретным hosted eval product. OpenAI в июне 2026 объявила deprecation для Evals platform и Agent Builder: существующие evals должны стать read-only 31 октября 2026 года, а dashboard/API Evals и Agent Builder запланированы к отключению 30 ноября 2026 года.⁹ Практический вывод для этой главы простой: hosted dashboard может быть удобным интерфейсом, но долговечной основой должны оставаться переносимые datasets, verifier contracts, traces, grading rules, export paths и release-gate decisions, которые переживают замену продукта или миграцию на другой инструмент. Если workflow должен жить дольше одного UI-продукта, перенос лучше проектировать в сторону Agents SDK или другого code-owned runtime, где eval artifacts версионируются рядом с кодом.

LangChain State of Agent Engineering добавляет к этому полезный production-readiness baseline.⁵ В их опросе 57.3% респондентов уже держат agents в production, но главным production barrier остается quality: 32% называют ее основным blocker. Одновременно observability стала почти базовой практикой: 89% организаций уже внедрили какой-то слой наблюдаемости, тогда как offline evals есть только у 52.4%. Для этой главы это важный разрыв: зрелость агента нельзя доказывать только наличием traces. Release gate должен явно видеть quality blocker, observability baseline и eval adoption gap: какие failures команда умеет объяснить, какие умеет заранее поймать, а какие пока только обнаруживает после факта.

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

Та же дисциплина должна распространяться и на изменения контракта проверяющего. Если стандарты оценивания меняются из-за новой версии контракта проверяющего, контур оценки должен поднимать это как значимый для релиза регрессионный сигнал, а не тихо считать новые вердикты напрямую сопоставимыми со старыми.

4.3. Условия завершения запуска должны быть проверяемыми¶

Практика агентного кодинга в Claude Code хорошо формулирует более общий урок: агент не должен завершать работу только потому, что результат “выглядит готовым”. Ему нужен проверяемый сигнал — тест, сборка, линтер, сравнение с эталоном, снимок экрана или внешний проверяющий контур.¹

Для агентной платформы это означает, что условие остановки стоит проектировать как часть контура оценки, а не как локальную привычку оператора. Полезно различать четыре уровня строгости:

• критерий в задании: агенту явно сказали, какой тест или проверку выполнить перед остановкой;
• сессионное условие цели: запуск продолжается, пока проверяемое условие не выполнено;
• детерминированный шлюз: скрипт или pipeline блокирует завершение, если проверка не проходит;
• независимая проверка: отдельный проверяющий, subagent или reviewer пытается опровергнуть результат свежим контекстом.

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

В схеме оценок это лучше отражать явно: stop_condition, verification_command, verification_result, verifier_actor, evidence_refs и решение, блокирует ли провал дальнейший поэтапный выпуск. Тогда “готово” становится не настроением модели, а проверяемым фактом, связанным с трассой, артефактами и политикой выпуска.

4.4. Eval readiness начинается с чистой среды и воспроизводимого следа¶

LangChain checklist по agent evaluation полезен как практическая проверка зрелости: до сложных метрик команда должна убедиться, что может запускать evals в чистой среде, повторять несколько trials, смотреть traces, фиксировать dataset и связывать verdict с конкретным поведением агента.⁴

Для этой книги это не отдельная методика, а усиление существующего контура. Eval readiness перед релизом должна включать:

• изолированную eval environment, чтобы тест не зависел от случайного состояния production;
• несколько прогонов там, где поведение недетерминированно;
• trace review для tool calls, approvals, retrieval и recovery branches;
• метрики эффективности рядом с метриками качества: latency, tool count, token budget и cost delta;
• явные scenario IDs, чтобы failed run можно было превратить в regression case;
• сохраненный verdict record, чтобы решение о rollout можно было оспорить и переиграть.

Иначе команда рискует получить красивый eval score, который нельзя расследовать. Для production agent это почти так же плохо, как отсутствие оценки: релиз выглядит управляемым, но при спорном verdict никто не может восстановить, какая версия политики, какой trace и какой tool outcome на самом деле стояли за решением.

4.5. Vulnerability harness как validation funnel, а не один scanner¶

Cloudflare описывает хороший security-вариант того же принципа: vulnerability discovery полезен только тогда, когда raw findings проходят независимую validation system, а не сразу попадают к инженерам как “баги”.¹⁰ Их схема разделяет VDH (Vulnerability Discovery Harness), который активно ищет кандидатов, и VVS (Vulnerability Validation System), который делает deduplication, judgment и fixing. Discovery может быть шумным и model-volatile; validation должна быть более строгой, воспроизводимой и независимой.

Для eval-архитектуры это переносится почти напрямую:

• finding без threat model, affected boundary и working PoC/test остается candidate, а не verified issue;
• deterministic checks должны подтверждать schema, files, functions, paths, parseability patch/test и отсутствие подмены исходного кода;
• independent validator не должен иметь права создавать собственные findings и должен пытаться опровергнуть hunter;
• triage должен отделять real-but-latent, wrong-repo, duplicate и production-reachable findings;
• fixing gate должен требовать targeted fail→pass flip, блокировать post-patch failure и оставлять branch на human review;
• harness health должен ловить shallow runs: слишком быстрый hunt без findings, sub-hunts или gap tasks скорее похож на сбой инструмента, чем на доказательство отсутствия багов.

Главный вывод: хороший eval loop не просто считает score. Он превращает дешевый шум модели в проверяемые артефакты, которые можно дедуплицировать, переиграть, оспорить, связать с владельцем и безопасно довести до patch review.

5. Оценивание трасс особенно полезно для агентных систем¶

В обычных приложениях часто хватает бизнес-KPI и частоты ошибок. В агентных системах этого мало, потому что качество часто сидит внутри запуска, а не только в финальном ответе.

Оценивание трасс полезно тем, что позволяет оценивать:

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

Для нашего агента поддержки это особенно ценно, когда ответ пользователю вроде бы “нормальный”, но внутри уже видно, что система:

• слишком часто вызывает create_support_ticket;
• ходит в лишние инструменты;
• слишком рано уходит в эскалацию;
• возвращает статус без достаточного обоснования.

5.1. Поведенческие и контрольные оценки проверяют не только ответ, но и поведение системы¶

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

Именно здесь появляются:

• поведенческие оценки;
• контрольные оценки;
• automated red teaming.

Они полезны для сценариев, где обычный регрессионный набор слишком плоский:

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

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

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

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

5.2. Отказ координации тоже должен быть частью дизайна оценки¶

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

Нужно отдельно смотреть:

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

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

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

5.3. Многоходовую согласованность тоже стоит проверять отдельно¶

Минимальный eval для этого выбора должен сравнивать single-agent и multi-agent режим на двух классах задач:

• read-heavy breadth-first: несколько независимых источников, отдельные retrieval branches, финальный synthesis; multi-agent может пройти, если качество растет при приемлемом token_budget и понятной трассе;
• write-heavy shared-state: несколько шагов меняют один объект или один incident record; multi-agent должен проигрывать или блокироваться, если появляются конфликтующие действия, потеря контекста, лишние approvals или высокий merge_conflict_risk.

Такой gate защищает от красивого, но неправильного вывода “multi-agent дал лучший ответ на research demo, значит надо включить его везде”.

5.3. Multi-turn consistency тоже стоит проверять отдельно¶

Еще один полезный сигнал свежих работ: агент может выглядеть разумно в коротком сценарии и при этом постепенно входить в противоречие с самим собой в длинном контуре взаимодействия.

Это особенно важно, когда система:

• ведет длинный диалог;
• работает с накопленным состоянием;
• несколько раз пересматривает решение;
• публично объясняет свое обоснование.

Поэтому полезно держать отдельные проверки согласованности:

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

5.4. Языковая модель как судья полезна только при калибровке¶

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

Это полезный инструмент, но только если не перепутать его с источником истины.

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

• фрагменты трассы;
• исходы инструментов;
• события подтверждения;
• структурированные поля оценки;
• внешние проверки состояния там, где они доступны.

Иначе система легко начинает получать "хороший балл" за красивый текст при плохом фактическом результате.

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

Это хорошо согласуется и с более широкой HCI-дисциплиной: когда AI-система ошибается, человеку нужно понимать пределы автоматизации и иметь возможность корректировать поведение, а не слепо принимать auto-grading.²¹

Один из полезных сигналов здесь - Cohen's kappa, но важнее самого числа обычно форма расхождения: где именно судья недопонимает нарушение политики, неверное использование инструмента или неоднозначный исход.

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

И последнее правило совсем простое: если команда оценивает изменение промпта, не стоит одновременно менять и промпт, и модель. Иначе потом нельзя будет сделать честный причинный вывод о том, что именно улучшило или ухудшило систему.

6. Что стоит включать в набор оценок¶

Очень частая ошибка: набор оценок состоит из приятных демо-сценариев. Такие наборы почти не помогают.

Хороший набор обычно включает:

• задачи успешного пути;
• неоднозначные запросы пользователей;
• попытки prompt injection;
• краевые случаи извлечения;
• сценарии с недостающими данными;
• тайм-аут инструмента и случаи частичного сбоя;
• потоки с обязательным подтверждением;
• cross-tenant и privacy-sensitive сценарии.

Для агента поддержки это означает, что в наборе должны лежать не только “проверить статус и ответить”, но и:

• “создать тикет, но инструмент вернул неоднозначный результат”;
• “пользователь прислал срочную фразу, которую нельзя слепо сохранять как предпочтение”;
• “извлечение вернуло конфликтующие статусы”;
• “путь подтверждения должен остановить операцию записи”.

Именно сложные и неприятные сценарии чаще всего дают реальную инженерную пользу.

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

6.1. Слой памяти тоже должен входить в набор оценок явно¶

Отдельно полезно проверять не только ответ, но и качество состояния между запусками.

Это означает сценарии на:

• решения write / no-write;
• извлечение устаревшего профиля;
• противоречия между записями профиля;
• небезопасное сохранение;
• поведение удаления и revision;
• дрейф памяти на длинном горизонте.

Иначе инциденты памяти будут попадать в разбор инцидентов, но не будут возвращаться в регрессионную дисциплину.

7. Регрессионный шлюз должен быть формальным, а не “посмотрели глазам蔶

Команды часто говорят: “Мы протестировали, вроде стало не хуже”. Для агентной системы эксплуатационного уровня этого слишком мало.

Регрессионный шлюз полезно строить как явный набор правил, например:

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

Для агента поддержки это означает, что регрессом считается не только “агент стал чаще ошибаться”, но и:

• он стал чаще дублировать попытки инструмента записи;
• чаще уходит в ненужную эскалацию;
• чаще пишет лишнее в память;
• стал дороже решать тот же класс задач.

Тогда решение о поэтапном выпуске перестает зависеть только от интуиции автора изменения.

7.1. Harness тоже должен оцениваться как часть системы¶

GitHub Copilot agentic harness дает хороший практический сигнал: качество агентной системы нельзя сводить к качеству модели.⁸ Harness управляет tools, context и workflow, поэтому его нужно сравнивать как отдельный слой: same model, same benchmark task, нормализованный context window, reasoning effort, tool selection и MCP servers, а затем сравнение с model-vendor harness.

Для release gate это меняет набор метрик. Помимо task resolution стоит явно смотреть:

• token efficiency;
• run-to-run variance;
• wall-clock duration;
• tool-call count и retry budget;
• cost profile для разных классов задач;
• качество Auto model selection или другого model router;
• деградации памяти, context handling и skill triggering.

Практический вывод: если команда меняет harness, context strategy или model routing, ей нужен harness-level release gate. Иначе можно ошибочно решить, что "модель стала лучше" или "модель стала хуже", хотя реальная причина лежит в orchestration layer.

7.2. Quality regression может жить в продуктовой обвязке¶

Постмортем Anthropic по Claude Code quality reports показывает ту же проблему в более болезненном виде.¹⁹ Пользователи видели деградацию Claude Code, Claude Agent SDK и Claude Cowork, хотя API и inference layer не были причиной. Три изменения лежали в продуктовой обвязке: default reasoning effort был снижен ради latency, stale-session optimization начала repeatedly pruning older thinking, а system prompt instruction для меньшей verbose output ухудшила coding quality.

Для release gate это отдельный failure pattern: model unchanged → harness/config/prompt/context change → quality regression → user reports before eval reproduction. Значит, проверка релиза должна явно версионировать model_id, effort_default, context_pruning_policy, prompt_bundle_version, cache_header_behavior, harness_version и rollout_slice. Иначе команда будет искать "ухудшение модели" там, где регресс создали latency optimization, cache policy или prompt hygiene.

Практический контракт после такого инцидента: prompt changes получают per-model eval suite and ablation; intelligence/latency tradeoffs получают soak period and gradual rollout; context-pruning changes получают stale-session regression cases; dogfooding должно использовать public build, а не только internal testing build. User feedback тоже становится сигналом gate, но его нужно связывать с конкретными version slices, чтобы broad complaint не растворялся в normal variance.

8. Практические правила для контура оценки¶

Если нужен короткий инженерный каркас, обычно достаточно таких правил:

1. Каждый заметный инцидент должен превращаться в оценочный сценарий и правило поэтапного выпуска.
2. Офлайн- и онлайн-оценки должны жить вместе: один контур ловит регрессии до релиза, другой после релиза.
3. Оценивание трасс стоит держать на критичных путях записи и policy-sensitive потоках, а не только на успешном пути.
4. Набор данных нужно обновлять по реальным сбоям, а не только по старым демо-сценариям.
5. Регрессионный шлюз должен быть машиночитаемым и блокировать не только регрессии качества, но и safety, cost, escalation и регрессии контракта verifier.

9. Пример политики для оценочных шлюзов¶

Ниже очень практичный шаблон:

gates:
  offline:
    min_task_success_rate: 0.97
    max_policy_violation_rate: 0.002
    max_avg_cost_delta_pct: 8
  online:
    max_slo_burn_rate: 1.0
    max_manual_intervention_rate: 0.08
    max_unknown_side_effect_rate: 0.0005
  rollout:
    require_offline_pass: true
    require_online_shadow_period: true

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

10. Простой кодовый пример решения о регрессии¶

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

from dataclasses import dataclass

@dataclass
class EvalSummary:
    task_success_rate: float
    policy_violation_rate: float
    avg_cost_delta_pct: float

def passes_regression_gate(summary: EvalSummary) -> bool:
    if summary.task_success_rate < 0.97:
        return False
    if summary.policy_violation_rate > 0.002:
        return False
    if summary.avg_cost_delta_pct > 8:
        return False
    return True

Код очень простой, но именно такая простота делает шлюз понятным для команды.

11. Онлайн-оценки должны быть связаны со стратегией выкладки¶

Очень полезно не выкатывать большие изменения сразу на всех, а использовать:

• shadow mode;
• canary-этап;
• ограниченную экспозицию арендаторов;
• эксперименты с маршрутизацией модели;
• поэтапный выпуск политики.

Тогда онлайн-оценки становятся не просто наблюдением “что-то пошло не так”, а контролируемым этапом выпуска.

Для того же агента поддержки это означает: если новый адаптер или новый промпт изменяет поведение на сложных сценариях статуса, команда должна увидеть это в canary или shadow, а не после широкого выпуска.

11.1. Хороший симулятор не заменяет реальные данные, а дополняет их¶

Важно не переоценивать симулятор пользователя.

Он не заменяет:

• реальные production-трассы;
• реальные паттерны жалоб;
• реальные распределения стоимости и задержки;
• реальные postmortem инцидентов.

Но он очень полезен как промежуточный слой между офлайн-набором и живым выпуском, потому что позволяет быстрее проверить:

• устойчивость диалога;
• поведение handoff;
• дисциплину эскалации;
• качество fallback;
• policy-sensitive ходы.

11.2. Production evals должны замыкать цикл обратно в разработку¶

Отдельный практический паттерн хорошо виден в AWS Agent-EvalKit: оценка агента не должна оставаться разовым benchmark перед запуском.¹¹ Полный цикл выглядит как pipeline: план оценки по коду и risk areas, генерация или импорт тестовых случаев, инструментирование трасс, запуск агента по сценариям, вычисление метрик по трассам и отчет с конкретными рекомендациями к коду.

Microsoft Foundry Open Trust Stack добавляет к этому удобную связку между политиками, evals и runtime controls.¹² ASSERT полезен как напоминание, что eval cases должны выводиться из organizational policies and requirements, а не только из случайных regression prompts. Agent Control Specification (ACS) дополняет это переносимыми control checkpoints: если eval показывает, что агент проваливает policy requirement, исправление должно выражаться не только в prompt change, но и в контрольной точке до tool call, после tool result или перед external action.

Новый слой Foundry делает этот контур еще более прикладным: production traces можно превращать в curated, versioned evaluation datasets.¹³ Это важная граница между observability и learning system. Трасса сама по себе еще не тест: ее нужно отобрать, очистить, привязать к expected outcome, версии агента, evaluator version и privacy policy. Но когда такая запись становится dataset item, реальное поведение пользователя возвращается в offline regression gate, а не остается только строкой в dashboard.

Google Cloud Agent Platform делает production-сторону этого контура явной: Online Monitors постоянно берут выборку трасс развернутого агента из Cloud Trace и Cloud Logging, запускают настроенные evaluation metrics, пишут результаты обратно в Cloud Logging и экспортируют численные оценки в Cloud Monitoring.¹⁵¹⁴ Переносимый контракт здесь не “посмотреть dashboard”, а live trace → sampled eval → score → alert or regression gate → reviewed improvement. Каждая выбранная строка должна сохранять trace_id, agent_version, tool_calls, expected_outcome, grader_version, score, failure_mode и review_required, чтобы команда могла переиграть решение и сравнить его между релизами.

Работа Google Discovery Bench добавляет второе предупреждение: командам нужно evaluate your evals.¹⁶ Benchmark может скрывать хрупкий ground truth, нестабильную сложность или pass/fail threshold, который не видит cliff, где агент резко ломается при чуть более расплывчатом запросе пользователя. Поэтому зрелый eval loop калибрует сам evaluator: измеряет сложность задачи, разбирает disagreement, версионирует rubrics и считает grader drift релизным риском.

Самое важное здесь не конкретный toolkit, а форма контура. Production traces нужно превращать не только в dashboards, но и в новые тестовые случаи, regression thresholds и code-level fixes. Если реальный трафик показывает, что агент красиво отвечает поверх пустого tool output, это не просто observability signal. Это будущий eval case на faithfulness, tool-use discipline и fallback behavior.

Anthropic хорошо формулирует соседний риск: агентные evals часто требуют экспертного суждения, но эксперт не должен превращаться в бесконечный ручной grader.¹⁷¹⁸ Правильный контракт — expert review → rubric update → representative dataset item → automated or sampled regression. Эксперт нужен, чтобы определить, что считается хорошим исходом в неоднозначной задаче, отличить допустимый альтернативный путь от ошибки и отбраковать хрупкие path-based проверки. После этого система должна сохранять критерий, пример, причину решения и границу применимости, иначе expertise остается устной традицией команды.

В зрелом контуре после каждого значимого изменения команда должна уметь:

• переиспользовать уже собранные test cases и instrumentation;
• добавить сценарии из production logs или ручного разбора;
• сравнить отчеты между версиями агента;
• привязать failed metric к конкретной трассе и месту в коде;
• прогнать качество на реальных traces из production sampling, а не только на синтетике.

Именно так eval loop становится release discipline: он принимает сигналы из разработки, production, инцидентов и ручной экспертизы, а возвращает не “score ухудшился”, а проверяемую работу для следующего изменения.

12. Что чаще всего ломается в культуре оценки¶

Проблемы тут довольно типовые:

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

Если это происходит, контур оценки превращается в ритуал, а не в механизм улучшения.

13. Быстрый тест зрелости для контура оценки¶

Команде не стоит думать, что у нее уже есть дисциплина оценки, только потому, что она гоняет benchmark-набор и иногда смотрит на несколько онлайн-метрик.

Более сильная планка такая:

• инциденты превращаются в оценочные сценарии и правила поэтапного выпуска;
• офлайн- и онлайн-оценки работают как единый контур, а не как отдельные ритуалы;
• регрессионные шлюзы блокируют не только сбои задачи, но и safety, cost, escalation и регрессии контракта verifier;
• трассы оцениваются как доказательства, а не просто складируются как пассивная телеметрия;
• набор продолжает учиться на реальных сбоях.

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

13.1. Практикум: превратить trace review в regression gate¶

Предыдущая глава дала язык SLO, а глава 11 дала трассу спорного запуска. Теперь полезно сделать следующий практический шаг: превратить один trace review в формальный regression gate.

Начни не с набора тестов, а с карточки сбоя:

trace_to_eval_source:
  trace_id: trace-support-042
  incident_class: duplicate_ticket_after_timeout
  observed_failure:
    - create_ticket returned timeout
    - side_effect status was unknown
    - retry path risked second ticket
  required_evidence:
    - idempotency_key
    - approval_id
    - tool_policy_decision
    - tool_execution
    - run_failed_or_safe_run_complete
    - verification_result

Затем сформулируй, какое поведение новая версия системы обязана повторять, а какое запрещено. Для агентных систем это важнее, чем просто “ответ должен быть похож”.

regression_gate:
  scenario_id: support_duplicate_ticket_after_timeout
  source_trace_ids:
    - trace-support-042
  input_replay:
    user_request: "создай тикет по проблеме онбординга"
    injected_tool_result: "timeout_after_possible_side_effect"
  expected_outcomes:
    max_ticket_side_effects: 1
    idempotency_key_required: true
    unknown_side_effect_not_success: true
    manual_reconciliation_or_safe_stop: true
    trace_contains_verification_result: true
  blocking_rules:
    - duplicate_ticket_created
    - missing_idempotency_key
    - missing_tool_policy_decision
    - side_effect_unknown_reported_as_success
    - verifier_contract_missing

После этого добавь слой суждения проверяющего. Он должен оценивать не только финальный текст, но и процесс:

verifier_contract:
  verifier_id: support-write-safety-v1
  process_checks:
    - policy_before_tool
    - approval_before_high_risk_write
    - idempotency_key_reused_for_reconciliation
    - no_blind_retry_after_unknown_side_effect
  outcome_checks:
    - user_received_safe_status
    - no_duplicate_ticket
  failure_attribution:
    allowed_values:
      - prompt_routing
      - policy_gate
      - tool_adapter
      - verifier_gap
      - external_system

Теперь gate становится пригодным для релизного решения. Если меняется prompt, модель, tool adapter, политика подтверждений или схема повторов, этот сценарий должен запускаться до расширения canary. Если он падает, команда спорит не о вкусе ответа, а о конкретном нарушенном правиле.

Минимальная форма решения о выпуске:

rollout_judgment:
  change_id: chg-support-write-path-2026-06
  gate: support_duplicate_ticket_after_timeout
  verdict: blocked
  blocking_reason: side_effect_unknown_reported_as_success
  next_action:
    - fix_retry_policy
    - rerun_offline_eval
    - keep_canary_at_current_wave

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

14. Что делать сразу после этой главы¶

Если команда хочет быстро проверить свой контур оценки, достаточно пройти по короткому списку:

1. Есть ли curated офлайн-набор оценок для критичных сценариев?
2. Есть ли сигнал онлайн-оценки, связанный с трассировкой и SLO?
3. Умеет ли команда оценивать не только финальный ответ, но и ход запуска?
4. Есть ли формальный регрессионный шлюз перед поэтапным выпуском?
5. Учитываются ли безопасность и стоимость, а не только успех задачи?
6. Обновляется ли набор оценок по следам реальных инцидентов?

Если на несколько вопросов подряд ответ “нет”, значит слой оценки у команды уже есть, но сильный оценочный слой еще не собран.

В этот момент у команды уже может быть скоринговая активность, но еще нет того типа дисциплины оценки, пригодной для проверки выпуска, на который последующие операционные функции могут уверенно опираться.

15. Модель доказательности этой главы¶

Эту главу стоит читать как модель суждения, а не как чеклист бенчмарков:

• Устойчивые утверждения: успех финального ответа недостаточен; оценки должны учитывать качество процесса, качество исхода, атрибуцию сбоя и регрессионные шлюзы.
• Вендорская практика: рекомендации Google Cloud по управлению агентами и современные материалы по агентным платформам рассматривают оценки как часть поэтапного выпуска и операционного контроля, а не только выбора модели.
• Research и human-AI practice: работы по human-centered evaluation напоминают, что кажущееся согласие или удовлетворенность пользователей могут скрывать слабые сигналы суждения.
• Практика среды исполнения: связанные с трассами строки оценки, выводы проверяющего, шлюзы поэтапного выпуска и причины неудачных запусков делают доказательства оценки проверяемыми для операторов.
• Противоположный взгляд: автоматические судьи привлекательны, потому что масштабируют проверку и уменьшают человеческое узкое место. Эта глава принимает эту пользу, но трактует вывод судьи как доказательство для калибровки, а не как авторитет, которому надо подчиняться; высокорисковые решения о поэтапном выпуске всё равно требуют разбора расхождений, владельца рубрики и атрибуции, подкрепленной трассой.
• Авторская интерпретация: эта книга трактует оценки как слой релизного суждения между наблюдаемостью и управлением жизненным циклом.
• Быстро меняющаяся область: judge-модели, симуляторы и автоматизированные техники red-team будут быстро меняться; потребность в явных шлюзах и атрибутируемых сбоях — нет.

16. Что читать дальше¶

Часть V к этому моменту уже собирает эксплуатационный контур целиком: трассировку, SLO и цикл оценки. Следующий логичный слой здесь уже организационный, потому что такие платформы упираются не только в код, но и в устройство команды.

17. Полезные справочные страницы¶

• Схема трасс и каталог событий
• Схема наборов для оценки и правил проверки
• Схема артефактов жизненного цикла
• Исследовательский фронтир: память, наблюдаемость и надежность многоагентных систем
• Глава 12. SLO для агентных систем
• Глава 25. Поведенческие оценки, контрольные оценки и автоматизированное соревновательное тестирование
• Глава 14. Платформенная команда и продуктовые команды
• Часть V. Надежность и наблюдаемость
• Источники