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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5.1. Behavioral evals и control evals проверяют не только ответ, но и поведение системы¶

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

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

• behavioral evals;
• control evals;
• automated red teaming.

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

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

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

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

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

5.2. Coordination failure тоже должна быть частью eval design¶

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

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

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

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

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

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

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

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

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

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

5.4. LLM-as-a-judge полезен только при калибровке¶

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. Каждый заметный инцидент должен превращаться в оценочный сценарий и правило раскатки.
2. Офлайн- и онлайн-оценки должны жить вместе: один контур ловит регрессии до релиза, другой после релиза.
3. Оценивание трасс стоит держать на критичных путях записи и policy-sensitive потоках, а не только на happy path.
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-раскатку;
• ограниченную экспозицию арендаторов;
• эксперименты с маршрутизацией модели;
• поэтапную раскатку политики.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Схема трасс и каталог событий
• Схема наборов для оценки и правил проверки
• Схема артефактов жизненного цикла
• Research frontier: память, наблюдаемость и надежность multi-agent систем
• Глава 12. SLO для агентных систем
• Глава 25. Behavioral evals, control evals и automated red teaming
• Глава 14. Платформенная команда и продуктовые команды
• Часть V. Надежность и наблюдаемость
• Источники