Как улучшать AI-агентов с помощью лучших evals: урок Anthropic и Claude Code
Anthropic, как ни странно, выпустила в Claude Code три регрессии качества, которые не заметили собственные evals. Подумайте об этом: три регрессии за короткие шесть недель у самой продвинутой команды по оценке в AI. Если это произошло у Anthropic, это вполне может произойти и у вас — и, скорее всего, произойдет.
В удивительно откровенном разборе Anthropic объяснила, что пошло не так. 4 марта команда перевела стандартный уровень reasoning effort в Claude Code с high на medium, потому что внутренние evals показали лишь «чуть меньший интеллект при значительно меньшей задержке для большинства задач». 26 марта оптимизация кеширования, призванная очищать устаревшее состояние мышления после часа простоя, содержала баг и очищала его на каждом ходе. 16 апреля две безобидные на вид строки system prompt с просьбой к Claude быть более кратким, как выяснилось, снижали качество кодинга на 3%, но только в более широком ablation suite, который не входил в стандартные release gates.
Внутри компании ни одно из этих изменений не сработало как сигнал тревоги. Пользователи же начали жаловаться почти сразу. Вывод не в том, что Anthropic проявила небрежность. Вывод в том, что качество AI скользкое даже для команд, которые одержимы измерениями. Для всех остальных опора на ощущения — это уязвимость. Так как же это исправить?
Перестаньте выпускать продукт на ощущениях
Andrej Karpathy придумал термин «vibe coding», чтобы описать процесс, когда вы формулируете желаемый результат, позволяете модели работать и стараетесь не вглядываться слишком пристально в получившийся беспорядок. Для прототипов это допустимо, но для production software это плохой подход. Unit tests, integration tests, regression suites, canary deploys: все это стало стандартом не потому, что разработчики любят ритуалы. Это стало стандартом потому, что в какой-то момент цена угадывания превысила цену измерения.
AI наконец движется в ту же сторону, и разбор Anthropic — самый ясный сигнал того, что даже создатели базовых моделей не могут позволить себе выпускать продукт «на ощущениях». В разговорах об evals часто ошибаются, когда воспринимают их как новый, более модный вид test suite. Отчасти это так, но только отчасти. Хороший eval — это аргумент о том, что означает качество именно для вашего приложения. Он заставляет команду заранее определить, как выглядит хорошее поведение, как выглядит ошибка, какие компромиссы допустимы и какую вариативность бизнес вообще может терпеть.
Часть про вариативность — это то, где большинство команд недооценивает проблему. В рекомендациях Anthropic по evals для agents есть полезное различие между pass@k — когда агент succeeds хотя бы один раз за k попыток, — и pass^k — когда агент succeeds каждый раз за k попыток. Внутренний triage tool, которому нужен один удачный ответ после нескольких повторов, может жить с pass@k; customer-facing workflow — не может. Если задача succeeds в 75% случаев, три последовательных успешных запуска дают уже примерно 42%.
Это не какая-то бессмысленная погрешность округления. Нет, это разница между демо и продуктом.
Именно так. AI не отменяет инженерную дисциплину. Наоборот, он повышает цену ее игнорирования.
Собственные рекомендации Anthropic отражают все это. Agents «fundamentally harder to evaluate», чем одноходовые chatbots, потому что они работают в течение многих turns, вызывают tools, меняют внешнее состояние и адаптируются на основе промежуточных результатов. Поэтому совет такой: оценивать outcomes, transcripts, tool calls, cost и latency как отдельные измерения, проводить multiple trials и четко отделять 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: «Ответ звучал хорошо?» Хорошо звучать — это самое легкое, что умеют современные модели. Именно так ведут себя вероятностные системы, созданные имитировать правду, не зная ее на самом деле. И это еще и самый бесполезный signal качества, который вы можете собрать. Уверенный agent, выбравший неверный tool path, опасен.
Одна из самых интересных частей разборa Anthropic в том, что регрессии возникли из вполне разумных изменений. Снижать latency — хорошо, как и сокращать verbosity, по крайней мере иногда. То же самое относится к более хорошему caching. Никто не приходит на product meeting со словами: «Давайте сделаем coding agent хуже». Говорят: «Пользователи ненавидят ждать» или «Мы сжигаем слишком много tokens», и это правда. Но эта правда не оправдывает ошибку в виде выпущенной регрессии.
Именно поэтому AI-командам нужно перестать воспринимать quality, latency и cost как одну смешанную метрику. Это компромиссы, а не синонимы. Например, краткий ответ может быть лучше для status update, но хуже для code review. Точно так же режим reasoning с меньшими усилиями может идеально подходить для boilerplate, но вредить multi-file refactors. Оптимизация cost должна доказывать, что она не ухудшила quality, а изменение prompt — что оно не ухудшило behavior.
Так что же делать?
Если вы технологический лидер и находитесь между «у нас есть agent в production» и «мы не уверены, что наши evals вообще что-то делают», есть и надежда, и понятные ориентиры, что делать дальше.
Во-первых, относитесь к жалобам пользователей как к самому ценному входу для evals. Каждое сообщение в Slack, в котором говорится «Claude стал глупее» или «agent забыл, что мы только что ему сказали», — это тест-кейс, который еще только предстоит написать. Ошибка Anthropic была не в отсутствии eval infrastructure. Ошибка была в задержке между пользовательским сигналом и покрытием evals — две недели. Если ваш самый быстрый путь от production complaint до regression suite измеряется неделями, у вас проблема процесса, а не инструмента.
Во-вторых, пишите меньше evals, но лучше, и читайте каждый transcript. Рекомендация Anthropic использовать 20–50 задач, взятых из реальных failures, выглядит правильно, потому что вам не нужны тысячи synthetic test cases. Вам нужны лишь несколько десятков кейсов из 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 на «helpfulness» этого не поймают.
В-четвертых, сделайте regression release gate, а не release report. Если изменение ухудшает regression score, не выпускайте его. Как я уже писал ранее, в enterprise выживают те agents, которые делают немногое, но надежно и предсказуемо, а добиться этого можно только отказом от деплоя того, что ломает уже работавшее.
И наконец, пишите eval до prompt. Вы должны уметь сформулировать, как выглядит хорошее, прежде чем начнете править систему. Prompt — это средство достижения цели, а eval заранее фиксирует саму цель.
Выход за пределы demo-ware
Мы все еще слишком рано находимся в наших AI engineering journeys, чтобы нас нельзя было простить за то, что мы принимаем демонстрации на vibes за прогресс. Но этот кредит доверия не вечен. Как недавно сформулировал Jones, «многие проблемы, которые люди приписывают AI, на самом деле существовали всегда, AI лишь усилил их». Evals — это способ перестать их усиливать.
Команды, которые выиграют следующий этап AI engineering, будут не теми, у кого самые эффектные eval dashboards; они будут теми, у кого самые честные feedback loops. Они будут знать, какие failures действительно важны, когда upgrade модели помог, а когда он тихо сломал workflow. Иными словами, они будут понимать, когда их agent на самом деле становится лучше.
Evals не выглядят sexy, но именно они ведут к sexy production-ready systems.
Материал — перевод статьи с английского.