Eval hygiene: как Anthropic столкнулась с регрессиями в Claude Code и почему AI нельзя выпускать «на ощущениях»

Anthropic, как ни странно, выпустила три регрессии качества в Claude Code, которые не поймали ее собственные evals. Подумайте об этом: три регрессии всего за шесть недель у, пожалуй, самой сильной команды по evals в AI. Если это может случиться с Anthropic, это точно может случиться и с вами — и, вероятно, случится.

В неожиданно откровенном разборе Anthropic подробно объяснила, что пошло не так. 4 марта команда перевела стандартный уровень reasoning effort в Claude Code с high на medium, потому что внутренние evals показывали лишь «чуть более низкий интеллект при значительно меньшей задержке для большинства задач». 26 марта оптимизация кэширования, которая должна была очищать устаревшее состояние мышления после часа простоя, содержала баг и очищала его на каждом ходе. 16 апреля две безобидные на вид строки system prompt с просьбой к Claude быть более кратким, как оказалось, стоили 3% качества кодинга — но только на более широкой ablation suite, которая не входила в стандартный release gate.

Внутри компании ни один из этих случаев не вызвал тревоги. Пользователи же начали жаловаться почти сразу. Вывод не в том, что Anthropic небрежна. Вывод в том, что качество AI скользкое даже для команд, которые одержимы измерениями. Для всех остальных опора на «ощущения» — это риск. Так как же это исправить?

Перестаньте выпускать по ощущениям

Andrej Karpathy ввел термин “vibe coding” для описания процесса, когда вы говорите модели, что хотите получить, даете ей работать и стараетесь не вглядываться слишком пристально в получившийся беспорядок. Для прототипов это допустимо, но для production-софта это ужасный подход. Unit tests, integration tests, regression suites, canary deploys — все это стало стандартом не потому, что разработчики любят ритуалы. Это стало стандартом потому, что в какой-то момент цена угадывания превысила цену измерения.

AI наконец подходит к той же точке, и разбор Anthropic — самый ясный сигнал о том, что даже создатели базовых моделей не могут больше выпускать продукт «на ощущениях». Многое в разговоре про AI evals идет не так, когда evals начинают считать просто модной разновидностью test suite. Отчасти это так, но лишь отчасти. Хороший eval — это аргумент о том, что такое качество для вашего приложения. Он заставляет команду заранее определить, как выглядит хорошее поведение, как выглядит сбой, какие компромиссы допустимы и какую вариативность бизнес может выдержать.

Именно вариативность чаще всего недооценивают. В guidance Anthropic для agents есть полезное различие между pass@k — агент успешно справляется хотя бы один раз за k попыток — и pass^k — он справляется каждый раз за k попыток. Внутренний triage-инструмент, которому нужен один хороший ответ после пары повторных попыток, может жить с pass@k; customer-facing workflow — нет. Если задача успешно выполняется в 75% случаев, три подряд успешных запуска дают примерно 42%.

Это не какая-то бессмысленная погрешность округления. Нет, это разница между демо и продуктом.

Она совершенно права. AI не отменяет инженерную дисциплину. Напротив, он повышает цену ее игнорирования.

Собственные рекомендации Anthropic отражают именно это. Agents — «фундаментально труднее оценивать», чем однопроходные chatbots, потому что они работают в многоходовых сценариях, вызывают tools, изменяют внешнее состояние и адаптируются на основе промежуточных результатов. Поэтому рекомендация — оценивать outcomes, transcripts, tool calls, cost и latency как отдельные измерения, проводить несколько прогонов и четко отделять capability evals от regression evals, которые должны держаться почти на 100% и нужны для предотвращения отката.

Цикл улучшений

Если убрать инструменты, цикл прост: жалоба в production превращается в trace, trace — в failure mode, failure mode — в eval, eval — в regression test, а regression test — в release gate. Потом, и только потом, вы меняете prompt, заменяете model, корректируете retrieval strategy или настраиваете компромисс между cost и latency.

На практике же большинство команд делают этот цикл в обратном порядке — или не делают вовсе. Это плохо.

Плохие evals создают ложную уверенность, а это хуже, чем отсутствие уверенности. Если ваши evals слишком узкие, команды начинают оптимизировать под них. Если ваши graders хрупкие, они наказывают валидные решения и поощряют поверхностное соответствие. Если вы полностью полагаетесь на LLM-as-judge без калибровки через human review, вы просто перенесли vibes на один уровень ниже, не убрав их. Если ваш eval set никогда не меняется, он превращается в живое кладбище старых предположений.

Обратите внимание, чего нет в хорошем eval: «Звучал ли ответ хорошо?» Звучать убедительно — самое простое, что умеют современные модели. Именно это и делают вероятностные системы, созданные имитировать правду, не зная ее. Это еще и самый бесполезный quality signal, который можно собрать. Уверенный agent, выбравший неправильный tool path, опасен.

Одна из самых интересных деталей разбора Anthropic в том, что регрессии возникли из разумных изменений. Снижение latency — хорошо, как и уменьшение verbosity, пусть и не всегда. То же касается более качественного caching. Никто не приходит на product meeting и не говорит: «Давайте сделаем coding agent хуже». Говорят: «Пользователи ненавидят ждать» или «Мы слишком много тратим токенов», и это справедливо. Но эта справедливость не оправдывает ошибку выпуска регрессии.

Именно поэтому AI-командам нужно перестать считать quality, latency и cost одним общим blended metric. Это компромиссы, а не синонимы. Например, краткий ответ может быть лучше для status update, но хуже для code review. Точно так же режим reasoning с меньшими усилиями может идеально подходить для boilerplate, но вредить multi-file refactors. Любая cost optimization должна доказывать, что не ухудшила качество, а любое изменение prompt должно доказывать, что не сломало поведение.

Что же делать?

Если вы tech leader и находитесь между «у нас есть agent в production» и «мы не уверены, что наши evals вообще что-то делают», есть и надежда, и понятные шаги.

Во-первых, воспринимайте жалобы пользователей как самый ценный вход для evals. Каждое сообщение в Slack в духе «Claude стал глупее» или «agent забыл, что мы ему только что сказали» — это готовый тест-кейс, который еще предстоит записать. Ошибка Anthropic была не в отсутствии eval infrastructure. Проблемой была задержка между сигналом от пользователей и покрытием evals — две недели. Если самый быстрый путь от production complaint до regression suite измеряется неделями, это проблема процесса, а не инструмента.

Во-вторых, пишите меньше, но лучше evals и читайте каждый transcript. Рекомендация Anthropic брать 20–50 задач, извлеченных из реальных сбоев, — правильная форма, потому что вам не нужны тысячи синтетических тест-кейсов. Вам нужны несколько десятков сценариев из production incidents, оцененных с помощью смеси code-based checks для того, что можно детерминированно проверить, и LLM-as-judge, откалиброванного по human review, для того, что проверить нельзя.

В-третьих, обязательно зашивайте ценности продукта в eval. Если вы строите coding assistant, то вас волнуют прохождение tests, сохранение style, отсутствие security mistakes и то, чтобы инструмент не «разгребал» весь repo грубой силой. Если вы строите customer-support agent, фокус смещается на factuality, tone, escalation, policy compliance, resolution rate и на то, не создала ли система новых проблем, решая старые. Универсальные graders по «полезности» этого не уловят.

В-четвертых, сделайте regression release gate, а не release report. Если изменение ухудшает regression score, не выпускайте его. Как я уже писал ранее, в enterprise выживают те agents, которые надежно и предсказуемо делают несколько вещей, и единственный способ прийти к этому — отказываться деплоить все, что ломает уже работавшее.

Наконец, пишите eval до prompt. Вы должны уметь сформулировать, что такое «хорошо», еще до того, как начнете править систему. Prompt — это средство, а eval заранее фиксирует цель.

Выход за пределы demo-ware

Мы все еще настолько рано на пути AI engineering, что нам, пожалуй, можно простить, если мы принимаем demo с vibe-driven подходом за прогресс. Но это прощение не будет вечным. Как недавно заметил Jones, «многие проблемы, в которых люди обвиняют AI, на самом деле существовали всегда — AI лишь усилил их». Именно evals помогают перестать их усиливать.

Победят в следующей фазе не те, у кого самые сложные eval dashboards, а те, у кого самые честные feedback loops. Они будут знать, какие сбои действительно важны, когда обновление model помогло, а когда тихо сломало workflow. Иными словами, они будут понимать, когда их agent действительно становится лучше.

Evals не выглядят эффектно, но именно они приводят к эффектным production-ready systems.

Материал — перевод статьи с английского.

Оригинал: Making AI work through eval hygiene