Demystifying evals for AI agents

Introduction

Введение

Good evaluations help teams ship AI agents more confidently. Without them, it’s easy to get stuck in reactive loops—catching issues only in production, where fixing one failure creates others. Evals make problems and behavioral changes visible before they affect users, and their value compounds over the lifecycle of an agent.

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

As we described in Building effective agents, agents operate over many turns: calling tools, modifying state, and adapting based on intermediate results. These same capabilities that make AI agents useful—autonomy, intelligence, and flexibility—also make them harder to evaluate.

Как мы описали в статье Building effective agents, агенты работают на протяжении множества шагов: вызывают инструменты, изменяют состояние и адаптируются на основе промежуточных результатов. Те же возможности, которые делают AI-агентов полезными — автономность, интеллект и гибкость — одновременно усложняют их оценку.

Through our internal work and with customers at the frontier of agent development, we’ve learned how to design more rigorous and useful evals for agents. Here's what's worked across a range of agent architectures and use cases in real-world deployment.

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

The structure of an evaluation

Структура оценки

An evaluation (“eval”) is a test for an AI system: give an AI an input, then apply grading logic to its output to measure success. In this post, we focus on automated evals that can be run during development without real users.

Оценка (eval) — это тест для AI-системы: дать ИИ вход, а затем применить логику оценивания к его выходу для измерения успешности. В этой статье мы сосредоточимся на автоматических оценках, которые можно запускать в процессе разработки без участия реальных пользователей.

Single-turn evaluations are straightforward: a prompt, a response, and grading logic. For earlier LLMs, single-turn, non-agentic evals were the main evaluation method. As AI capabilities have advanced, multi-turn evaluations have become increasingly common.

Одношаговые оценки устроены просто: промпт, ответ и логика оценивания. Для ранних LLM одношаговые, неагентные оценки были основным методом. По мере роста возможностей ИИ многошаговые оценки становятся всё более распространёнными.

Agent evaluations are even more complex. Agents use tools across many turns, modifying state in the environment and adapting as they go—which means mistakes can propagate and compound. Frontier models can also find creative solutions that surpass the limits of static evals. For instance, Opus 4.5 solved a 𝜏2-bench problem about booking a flight by discovering a loophole in the policy. It “failed” the evaluation as written, but actually came up with a better solution for the user.

Оценки агентов ещё сложнее. Агенты используют инструменты на протяжении множества шагов, изменяя состояние среды и адаптируясь по ходу — а значит, ошибки могут распространяться и накапливаться. Передовые модели также способны находить креативные решения, выходящие за рамки статических оценок. Например, Opus 4.5 решил задачу бронирования авиабилета в 𝜏2-bench, обнаружив лазейку в политике. Формально он «провалил» оценку, но на деле нашёл лучшее решение для пользователя.

When building agent evaluations, we use the following definitions:

При создании оценок агентов мы используем следующие определения:

Задача (она же проблема или тестовый случай) — это отдельный тест с определёнными входами и критериями успеха.Каждая попытка выполнения задачи — это проба (trial). Поскольку выходы модели варьируются между запусками, мы проводим несколько проб для получения более стабильных результатов.Грейдер — это логика, которая оценивает определённый аспект работы агента. У задачи может быть несколько грейдеров, каждый из которых содержит несколько утверждений (иногда называемых проверками).Транскрипт (также называемый трассой или траекторией) — это полная запись пробы, включающая выходы, вызовы инструментов, рассуждения, промежуточные результаты и любые другие взаимодействия. Для Anthropic API это полный массив messages в конце запуска оценки, содержащий все вызовы к API и все полученные ответы во время оценки.Исход — это финальное состояние среды по окончании пробы. Агент бронирования авиабилетов может написать «Ваш рейс забронирован» в конце транскрипта, но исход — это наличие записи о бронировании в SQL-базе данных среды.Среда оценки (evaluation harness) — это инфраструктура, которая запускает оценки от начала до конца. Она предоставляет инструкции и инструменты, параллельно запускает задачи, записывает все шаги, оценивает выходы и агрегирует результаты.Среда агента (agent harness, или scaffold) — это система, которая позволяет модели действовать как агент: она обрабатывает входы, оркестрирует вызовы инструментов и возвращает результаты. Когда мы оцениваем «агента», мы оцениваем среду и модель, работающие вместе. Например, Claude Code — это гибкая среда для агента, и мы использовали её основные примитивы через Agent SDK для создания нашей среды для долгоживущих агентов.Набор оценок (evaluation suite) — это коллекция задач, предназначенных для измерения конкретных возможностей или поведения. Задачи в наборе обычно объединены общей целью. Например, набор оценок клиентской поддержки может тестировать возвраты, отмены и эскалации.

Why build evaluations?

Зачем создавать оценки?

When teams first start building agents, they can get surprisingly far through a combination of manual testing, dogfooding, and intuition. More rigorous evaluation may even seem like overhead that slows down shipping. But after the early prototyping stages, once an agent is in production and has started scaling, building without evals starts to break down.

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

The breaking point often comes when users report the agent feels worse after changes, and the team is “flying blind” with no way to verify except to guess and check. Absent evals, debugging is reactive: wait for complaints, reproduce manually, fix the bug, and hope nothing else regressed. Teams can't distinguish real regressions from noise, automatically test changes against hundreds of scenarios before shipping, or measure improvements.

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

We’ve seen this progression play out many times. For instance, Claude Code started with fast iteration based on feedback from Anthropic employees and external users. Later, we added evals—first for narrow areas like concision and file edits, and then for more complex behaviors like over-engineering. These evals helped identify issues, guide improvements, and focus research-product collaborations. Combined with production monitoring, A/B tests, user research, and more, evals provide signals to continue improving Claude Code as it scales.

Мы наблюдали эту эволюцию множество раз. Например, Claude Code начинался с быстрых итераций на основе обратной связи от сотрудников Anthropic и внешних пользователей. Позже мы добавили оценки — сначала для узких областей вроде лаконичности и редактирования файлов, а затем для более сложного поведения, например, избыточного усложнения кода. Эти оценки помогли выявить проблемы, направить улучшения и сфокусировать сотрудничество между исследованиями и продуктом. В сочетании с мониторингом в продакшене, A/B-тестами, исследованиями пользователей и другими методами оценки дают сигналы для дальнейшего улучшения Claude Code по мере масштабирования.

Writing evals is useful at any stage in the agent lifecycle. Early on, evals force product teams to specify what success means for the agent, while later they help uphold a consistent quality bar.

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

Descript’s agent helps users edit videos, so they built evals around three dimensions of a successful editing workflow: don’t break things, do what I asked, and do it well. They evolved from manual grading to LLM graders with criteria defined by the product team and periodic human calibration, and now regularly run two separate suites for quality benchmarking and regression testing. The Bolt AI team started building evals later, after they already had a widely used agent. In 3 months, they built an eval system that runs their agent and grades outputs with static analysis, uses browser agents to test apps, and employs LLM judges for behaviors like instruction following.

Агент Descript помогает пользователям редактировать видео, поэтому они построили оценки вокруг трёх измерений успешного рабочего процесса редактирования: не ломай то, что есть; делай то, что попросили; делай это хорошо. Они эволюционировали от ручной оценки к LLM-грейдерам с критериями, определёнными продуктовой командой, и периодической человеческой калибровкой, и теперь регулярно запускают два отдельных набора для бенчмаркинга качества и регрессионного тестирования. Команда Bolt AI начала строить оценки позже, когда у них уже был широко используемый агент. За 3 месяца они создали систему оценки, которая запускает их агента и оценивает результаты с помощью статического анализа, использует браузерных агентов для тестирования приложений и применяет LLM-судей для оценки поведения, например, следования инструкциям.

Some teams create evals at the start of development; others add them once at scale when evals become a bottleneck for improving the agent. Evals are especially useful at the start of agent development to explicitly encode expected behavior. Two engineers reading the same initial spec could come away with different interpretations on how the AI should handle edge cases. An eval suite resolves this ambiguity. Regardless of when they’re created, evals help accelerate development.

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

Evals also shape how quickly you can adopt new models. When more powerful models come out, teams without evals face weeks of testing while competitors with evals can quickly determine the model’s strengths, tune their prompts, and upgrade in days. 

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

Once evals exist, you get baselines and regression tests for free: latency, token usage, cost per task, and error rates can be tracked on a static bank of tasks. Evals can also become the highest-bandwidth communication channel between product and research teams, defining metrics researchers can optimize against. Clearly, evals have wide-ranging benefits beyond tracking regressions and improvements. Their compounding value is easy to miss given that costs are visible upfront while benefits accumulate later.

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

How to evaluate AI agents

Как оценивать AI-агентов

We see several common types of agents deployed at scale today, including coding agents, research agents, computer use agents, and conversational agents. Each type may be deployed across a wide variety of industries, but they can be evaluated using similar techniques. You don’t need to invent an evaluation from scratch. The sections below describe proven techniques for several agent types. Use these methods as a foundation, then extend them to your domain.

Сегодня мы видим несколько распространённых типов агентов, развёрнутых в масштабе: кодовые агенты, исследовательские агенты, агенты компьютерного управления и разговорные агенты. Каждый тип может быть развёрнут в самых разных отраслях, но оценивать их можно схожими методами. Не нужно изобретать оценку с нуля. В разделах ниже описаны проверенные методы для нескольких типов агентов. Используйте эти подходы как основу, а затем расширяйте их для своей предметной области.

Types of graders for agents

Типы грейдеров для агентов

Agent evaluations typically combine three types of graders: code-based, model-based, and human. Each grader evaluates some portion of either the transcript or the outcome. An essential component of effective evaluation design is to choose the right graders for the job.

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

Code-based graders

Грейдеры на основе кода

Model-based graders

Грейдеры на основе модели

Оценка по рубрикеУтверждения на естественном языкеПопарное сравнениеОценка по эталонуКонсенсус нескольких судей

ГибкиеМасштабируемыеУлавливают нюансыПодходят для открытых задачПодходят для свободного формата вывода

НедетерминированныеДороже кодовых грейдеровТребуют калибровки с человеческими оценщиками для точности

Human graders

Человеческие грейдеры

Экспертная рецензияКраудсорсинговая оценкаВыборочная проверкаA/B-тестированиеСогласованность между оценщиками

Золотой стандарт качестваСоответствует суждению экспертного пользователяИспользуется для калибровки модельных грейдеров

ДорогоМедленноЧасто требует доступа к экспертам в масштабе

For each task, scoring can be weighted (combined grader scores must hit a threshold), binary (all graders must pass), or a hybrid.

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

Capability vs. regression evals

Оценки возможностей и регрессионные оценки

Capability or “quality” evals ask, “What can this agent do well?” They should start at a low pass rate, targeting tasks the agent struggles with and giving teams a hill to climb.

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

Regression evals ask, “Does the agent still handle all the tasks it used to?” and should have a nearly 100% pass rate. They protect against backsliding, as a decline in score signals that something is broken and needs to be improved. As teams hill-climb on capability evals, it’s important to also run regression evals to make sure changes don’t cause issues elsewhere.

Регрессионные оценки задают вопрос: «Справляется ли агент по-прежнему со всеми задачами, которые он решал раньше?» — и должны иметь долю успеха, близкую к 100%. Они защищают от деградации: снижение результата сигнализирует, что что-то сломалось и требует исправления. По мере того как команды улучшают показатели оценок возможностей, важно также запускать регрессионные оценки, чтобы изменения не вызывали проблем в других местах.

After an agent is launched and optimized, capability evals with high pass rates can “graduate” to become a regression suite that is run continuously to catch any drift. Tasks that once measured “Can we do this at all?” then measure “Can we still do this reliably?”

После запуска и оптимизации агента оценки возможностей с высокой долей успеха могут «выпуститься» в регрессионный набор, который запускается непрерывно для обнаружения любого дрейфа. Задачи, которые когда-то измеряли «Можем ли мы это вообще сделать?», начинают измерять «Можем ли мы по-прежнему делать это надёжно?»

Evaluating coding agents

Оценка кодовых агентов

Coding agents write, test, and debug code, navigating codebases and running commands much like a human developer. Effective evals for modern coding agents usually rely on well-specified tasks, stable test environments, and thorough tests for the generated code.

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

Deterministic graders are natural for coding agents because software is generally straightforward to evaluate: does the code run and do the tests pass? Two widely used coding agent benchmarks, SWE-bench Verified and Terminal-Bench, follow this approach. SWE-bench Verified gives agents GitHub issues from popular Python repositories and grades solutions by running the test suite; a solution passes only if it fixes the failing tests without breaking existing ones. LLMs have progressed from 40% to >80% on this eval in just one year. Terminal-Bench takes a different track: it tests end-to-end technical tasks, such as building a Linux kernel from source or training an ML model.

Детерминистические грейдеры естественны для кодовых агентов, потому что программное обеспечение в целом легко оценить: запускается ли код и проходят ли тесты? Два широко используемых бенчмарка для кодовых агентов — SWE-bench Verified и Terminal-Bench — следуют этому подходу. SWE-bench Verified предоставляет агентам GitHub-issues из популярных Python-репозиториев и оценивает решения, запуская набор тестов; решение проходит, только если исправляет падающие тесты, не ломая существующие. LLM прогрессировали от 40% до >80% на этой оценке всего за один год. Terminal-Bench идёт другим путём: он тестирует сквозные технические задачи, такие как сборка ядра Linux из исходников или обучение ML-модели.

Once you have a set of pass-or-fail tests for validating the key outcomes of a coding task, it’s often useful to also grade the transcript. For instance, heuristics-based code quality rules can evaluate the generated code based on more than passing tests, and model-based graders with clear rubrics can assess behaviors like how the agent calls tools or interacts with the user.

Когда у вас есть набор тестов «прошёл/не прошёл» для валидации ключевых исходов кодовой задачи, часто полезно также оценивать транскрипт. Например, эвристические правила качества кода могут оценивать сгенерированный код не только по прохождению тестов, а модельные грейдеры с чёткими рубриками — оценивать поведение агента: как он вызывает инструменты или взаимодействует с пользователем.

Example: Theoretical evaluation for a coding agent

Пример: теоретическая оценка для кодового агента

Consider a coding task where the agent must fix an authentication bypass vulnerability. As shown in the illustrative YAML file below, one could evaluate this agent using both graders and metrics. 

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

task: id: "fix-auth-bypass_1" desc: "Fix authentication bypass when password field is empty and ..." graders: - type: deterministic_tests required: [test_empty_pw_rejected.py, test_null_pw_rejected.py] - type: llm_rubric rubric: prompts/code_quality.md - type: static_analysis commands: [ruff, mypy, bandit] - type: state_check expect: security_logs: {event_type: "auth_blocked"} - type: tool_calls required: - {tool: read_file, params: {path: "src/auth/*"}} - {tool: edit_file} - {tool: run_tests} tracked_metrics: - type: transcript metrics: - n_turns - n_toolcalls - n_total_tokens - type: latency metrics: - time_to_first_token - output_tokens_per_sec - time_to_last_token

task: id: "fix-auth-bypass_1" desc: "Fix authentication bypass when password field is empty and ..." graders: - type: deterministic_tests required: [test_empty_pw_rejected.py, test_null_pw_rejected.py] - type: llm_rubric rubric: prompts/code_quality.md - type: static_analysis commands: [ruff, mypy, bandit] - type: state_check expect: security_logs: {event_type: "auth_blocked"} - type: tool_calls required: - {tool: read_file, params: {path: "src/auth/*"}} - {tool: edit_file} - {tool: run_tests} tracked_metrics: - type: transcript metrics: - n_turns - n_toolcalls - n_total_tokens - type: latency metrics: - time_to_first_token - output_tokens_per_sec - time_to_last_token

Note that this example showcases the full range of available graders for illustration. In practice, coding evaluations typically rely on unit tests for correctness verification and an LLM rubric for assessing overall code quality, with additional graders and metrics added only as needed.

Обратите внимание, что этот пример демонстрирует полный спектр доступных грейдеров для наглядности. На практике оценки кода обычно опираются на юнит-тесты для проверки корректности и LLM-рубрику для оценки общего качества кода, а дополнительные грейдеры и метрики добавляются по мере необходимости.

Evaluating conversational agents

Оценка разговорных агентов

Conversational agents interact with users in domains like support, sales, or coaching. Unlike traditional chatbots, they maintain state, use tools, and take actions mid-conversation. While coding and research agents can also involve many turns of interaction with the user, conversational agents present a distinct challenge: the quality of the interaction itself is part of what you're evaluating. Effective evals for conversational agents usually rely on verifiable end-state outcomes and rubrics that capture both task completion and interaction quality. Unlike most other evals, they often require a second LLM to simulate the user. We use this approach in our alignment auditing agents to stress-test models through extended, adversarial conversations.

Разговорные агенты взаимодействуют с пользователями в таких областях, как поддержка, продажи или коучинг. В отличие от традиционных чат-ботов, они поддерживают состояние, используют инструменты и выполняют действия в ходе разговора. Хотя кодовые и исследовательские агенты тоже могут включать множество шагов взаимодействия с пользователем, разговорные агенты ставят особую задачу: качество самого взаимодействия — часть того, что вы оцениваете. Эффективные оценки для разговорных агентов обычно опираются на проверяемые конечные состояния и рубрики, которые охватывают как выполнение задачи, так и качество взаимодействия. В отличие от большинства других оценок, они часто требуют второй LLM для имитации пользователя. Мы используем этот подход в наших агентах аудита выравнивания для стресс-тестирования моделей через длительные состязательные диалоги.

Success for conversational agents can be multidimensional: is the ticket resolved (state check), did it finish in <10 turns (transcript constraint), and was the tone appropriate (LLM rubric)? Two benchmarks that incorporate multidimensionality are 𝜏-Bench and its successor, τ2-Bench. These simulate multi-turn interactions across domains like retail support and airline booking, where one model plays a user persona while the agent navigates realistic scenarios.

Успех разговорных агентов может быть многомерным: решён ли тикет (проверка состояния), завершился ли диалог менее чем за 10 шагов (ограничение транскрипта) и был ли тон уместным (LLM-рубрика)? Два бенчмарка, учитывающих многомерность — 𝜏-Bench и его преемник τ2-Bench. Они моделируют многошаговые взаимодействия в таких областях, как розничная поддержка и бронирование авиабилетов, где одна модель играет роль пользователя, а агент решает реалистичные сценарии.

Example: Theoretical evaluation for a conversational agent

Пример: теоретическая оценка для разговорного агента

Consider a support task where the agent must handle a refund for a frustrated customer.

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

graders: - type: llm_rubric rubric: prompts/support_quality.md assertions: - "Agent showed empathy for customer's frustration" - "Resolution was clearly explained" - "Agent's response grounded in fetch_policy tool results" - type: state_check expect: tickets: {status: resolved} refunds: {status: processed} - type: tool_calls required: - {tool: verify_identity} - {tool: process_refund, params: {amount: "<=100"}} - {tool: send_confirmation} - type: transcript max_turns: 10 tracked_metrics: - type: transcript metrics: - n_turns - n_toolcalls - n_total_tokens - type: latency metrics: - time_to_first_token - output_tokens_per_sec - time_to_last_token

graders: - type: llm_rubric rubric: prompts/support_quality.md assertions: - "Agent showed empathy for customer's frustration" - "Resolution was clearly explained" - "Agent's response grounded in fetch_policy tool results" - type: state_check expect: tickets: {status: resolved} refunds: {status: processed} - type: tool_calls required: - {tool: verify_identity} - {tool: process_refund, params: {amount: "<=100"}} - {tool: send_confirmation} - type: transcript max_turns: 10 tracked_metrics: - type: transcript metrics: - n_turns - n_toolcalls - n_total_tokens - type: latency metrics: - time_to_first_token - output_tokens_per_sec - time_to_last_token

As in our coding agent example, this task showcases multiple grader types for illustration. In practice, conversational agent evaluations typically use model-based graders to assess both communication quality and goal completion, because many tasks—like answering a question—may have multiple “correct” solutions.

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

Evaluating research agents

Оценка исследовательских агентов

Research agents gather, synthesize, and analyze information, then produce outputs like an answer or report. Unlike coding agents where unit tests provide binary pass/fail signals, research quality can only be judged relative to the task. What counts as “comprehensive,” “well-sourced,” or even “correct” depends on context: a market scan, due diligence for an acquisition, and a scientific report each require different standards.

Исследовательские агенты собирают, синтезируют и анализируют информацию, а затем создают результат — ответ или отчёт. В отличие от кодовых агентов, где юнит-тесты дают бинарный сигнал «прошёл/не прошёл», качество исследования можно оценить только относительно задачи. Что считать «исчерпывающим», «хорошо подкреплённым источниками» или даже «правильным» — зависит от контекста: обзор рынка, due diligence при поглощении и научный отчёт требуют разных стандартов.

Research evals face unique challenges: experts may disagree on whether a synthesis is comprehensive, ground truth shifts as reference content changes constantly, and longer, more open-ended outputs create more room for mistakes. A benchmark like BrowseComp, for example, tests whether AI agents can find needles in haystacks across the open web—questions designed to be easy to verify but hard to solve.

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

One strategy to build research agent evals is to combine grader types. Groundedness checks verify that claims are supported by retrieved sources, coverage checks define key facts a good answer must include, and source quality checks confirm the consulted sources are authoritative, rather than simply the first retrieved. For tasks with objectively correct answers (“What was Company X’s Q3 revenue?”), exact match works. An LLM can flag unsupported claims and gaps in coverage but also verify the open-ended synthesis for coherence and completeness.

Одна из стратегий построения оценок исследовательских агентов — комбинирование типов грейдеров. Проверки обоснованности удостоверяют, что утверждения подкреплены найденными источниками; проверки покрытия определяют ключевые факты, которые должен содержать хороший ответ; проверки качества источников подтверждают, что использованные источники авторитетны, а не просто первые найденные. Для задач с объективно правильными ответами («Какова была выручка компании X за Q3?») работает точное совпадение. LLM может отмечать необоснованные утверждения и пробелы в покрытии, а также проверять открытый синтез на связность и полноту.

Given the subjective nature of research quality, LLM-based rubrics should be frequently calibrated against expert human judgment to grade these agents effectively.

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

Computer use agents

Агенты компьютерного управления

Computer use agents interact with software through the same interface as humans—screenshots, mouse clicks, keyboard inputs, and scrolling—rather than through APIs or code execution. They can use any application with a graphical user interface (GUI), from design tools to legacy enterprise software. Evaluation requires running the agent in a real or sandboxed environment where it can use software applications and checking whether it achieved the intended outcome. For instance, WebArena tests browser-based tasks, using URL and page state checks to verify the agent navigated correctly, along with backend state verification for tasks that modify data (confirming an order was actually placed, not just that the confirmation page appeared). OSWorld extends this to full operating system control, with evaluation scripts that inspect diverse artifacts after task completion: file system state, application configs, database contents, and UI element properties.

Агенты компьютерного управления взаимодействуют с программным обеспечением через тот же интерфейс, что и люди — скриншоты, клики мышью, ввод с клавиатуры и прокрутку — а не через API или выполнение кода. Они могут использовать любое приложение с графическим интерфейсом (GUI), от инструментов дизайна до устаревшего корпоративного ПО. Оценка требует запуска агента в реальной или песочной среде, где он может использовать программные приложения, и проверки, достиг ли он намеченного результата. Например, WebArena тестирует задачи в браузере, используя проверки URL и состояния страницы для подтверждения корректной навигации, а также проверку состояния бэкенда для задач, изменяющих данные (подтверждая, что заказ действительно размещён, а не просто отображена страница подтверждения). OSWorld расширяет это до полного управления операционной системой, с оценочными скриптами, которые проверяют разнообразные артефакты после выполнения задачи: состояние файловой системы, конфигурации приложений, содержимое баз данных и свойства элементов UI.

Browser use agents require a balance between token efficiency and latency. DOM-based interactions execute quickly but consume many tokens, while screenshot-based interactions are slower but more token-efficient. For example, when asking Claude to summarize Wikipedia, it is more efficient to extract the text from the DOM. When finding a new laptop case on Amazon, it is more efficient to take screenshots (as extracting the entire DOM is token-intensive). In our Claude for Chrome product, we developed evals to check that the agent was selecting the right tool for each context. This enabled us to complete browser-based tasks faster and more accurately.

Агенты для работы в браузере требуют баланса между эффективностью использования токенов и задержкой. Взаимодействие на основе DOM выполняется быстро, но потребляет много токенов, тогда как взаимодействие на основе скриншотов медленнее, но эффективнее по токенам. Например, когда вы просите Claude обобщить Wikipedia, эффективнее извлечь текст из DOM. Когда нужно найти новый чехол для ноутбука на Amazon, эффективнее делать скриншоты (поскольку извлечение всего DOM требует много токенов). В нашем продукте Claude for Chrome мы разработали оценки для проверки, что агент выбирает правильный инструмент для каждого контекста. Это позволило нам выполнять браузерные задачи быстрее и точнее.

How to think about non-determinism in evaluations for agents

Как рассматривать недетерминированность в оценках агентов

Regardless of agent type, agent behavior varies between runs, which makes evaluation results harder to interpret than they first appear. Each task has its own success rate—maybe 90% on one task, 50% on another—and a task that passed on one eval run might fail on the next. Sometimes, what we want to measure is how often (what proportion of the trials) an agent succeeds for a task.

Независимо от типа агента, его поведение варьируется между запусками, что делает результаты оценки сложнее для интерпретации, чем кажется на первый взгляд. У каждой задачи своя доля успеха — возможно, 90% для одной задачи и 50% для другой — и задача, которая прошла на одном запуске оценки, может провалиться на следующем. Иногда нас интересует, как часто (в какой доле проб) агент успешно справляется с задачей.

Two metrics help capture this nuance:

Две метрики помогают уловить этот нюанс:

pass@k measures the likelihood that an agent gets at least one correct solution in k attempts. As k increases, pass@k score rises: more “shots on goal” means higher odds of at least 1 success. A score of 50% pass@1 means that a model succeeds at half the tasks in the eval on its first try. In coding, we’re often most interested in the agent finding the solution on the first try—pass@1. In other cases, proposing many solutions is valid as long as one works.

pass@k измеряет вероятность того, что агент получит хотя бы одно правильное решение за k попыток. С увеличением k показатель pass@k растёт: больше «ударов по воротам» означает больше шансов на хотя бы 1 успех. Показатель 50% pass@1 означает, что модель справляется с половиной задач в оценке с первой попытки. В кодировании нас чаще всего интересует, найдёт ли агент решение с первой попытки — pass@1. В других случаях допустимо предложить много решений, если хотя бы одно сработает.

pass^k measures the probability that all k trials succeed. As k increases, pass^k falls since demanding consistency across more trials is a harder bar to clear. If your agent has a 75% per-trial success rate and you run 3 trials, the probability of passing all three is (0.75)³ ≈ 42%. This metric especially matters for customer-facing agents where users expect reliable behavior every time.

pass^k измеряет вероятность того, что все k проб будут успешными. С увеличением k показатель pass^k падает, поскольку требование стабильности на большем числе проб — более высокая планка. Если ваш агент имеет 75% успеха за пробу и вы проводите 3 пробы, вероятность прохождения всех трёх составляет (0.75)³ ≈ 42%. Эта метрика особенно важна для клиентских агентов, где пользователи ожидают надёжного поведения каждый раз.

Both metrics are useful, and which to use depends on product requirements: pass@k for tools where one success matters, pass^k for agents where consistency is essential.

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

Going from zero to one: a roadmap to great evals for agents

От нуля к единице: дорожная карта к отличным оценкам агентов

This section lays out our practical, field-tested advice for going from no evals to evals you can trust. Think of this as a roadmap for eval-driven agent development: define success early, measure it clearly, and iterate continuously.

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

Collect tasks for the initial eval dataset

Соберите задачи для начального набора оценок

Step 0. Start early

Шаг 0. Начните рано

We see teams delay building evals because they think they need hundreds of tasks. In reality, 20-50 simple tasks drawn from real failures is a great start. After all, in early agent development, each change to the system often has a clear, noticeable impact, and this large effect size means small sample sizes suffice. More mature agents may need larger, more difficult evals to detect smaller effects, but it’s best to take the 80/20 approach in the beginning. Evals get harder to build the longer you wait. Early on, product requirements naturally translate into test cases. Wait too long and you're reverse-engineering success criteria from a live system.

Мы видим, как команды откладывают создание оценок, полагая, что им нужны сотни задач. На самом деле 20–50 простых задач, составленных из реальных сбоев — отличное начало. В конце концов, на ранних стадиях разработки агента каждое изменение системы часто оказывает заметное влияние, и этот большой размер эффекта означает, что малых выборок достаточно. Более зрелым агентам могут потребоваться более крупные и сложные оценки для обнаружения мелких эффектов, но в начале лучше применять принцип 80/20. Оценки становится сложнее строить, чем дольше вы ждёте. На ранних этапах требования к продукту естественным образом превращаются в тестовые случаи. Ждёте слишком долго — и вам придётся обратным инжинирингом извлекать критерии успеха из работающей системы.

Step 1. Start with what you already test manually

Шаг 1. Начните с того, что вы уже тестируете вручную

Begin with the manual checks you run during development—the behaviors you verify before each release and common tasks end users try. If you're already in production, look at your bug tracker and support queue. Converting user-reported failures into test cases ensures your suite reflects actual usage; prioritizing by user impact helps you invest effort where it counts.

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

Step 2: Write unambiguous tasks with reference solutions

Шаг 2: Пишите однозначные задачи с эталонными решениями

Getting task quality right is harder than it seems. A good task is one where two domain experts would independently reach the same pass/fail verdict. Could they pass the task themselves? If not, the task needs refinement. Ambiguity in task specifications becomes noise in metrics. The same applies to criteria for model-based graders: vague rubrics produce inconsistent judgments.

Добиться правильного качества задач сложнее, чем кажется. Хорошая задача — это задача, для которой два эксперта в предметной области независимо пришли бы к одному и тому же вердикту «прошёл/не прошёл». Смогли бы они сами пройти эту задачу? Если нет, задачу нужно доработать. Двусмысленность в спецификациях задач превращается в шум в метриках. То же касается критериев для модельных грейдеров: размытые рубрики дают непоследовательные оценки.

Each task should be passable by an agent that follows instructions correctly. This can be subtle. For instance, auditing Terminal-Bench revealed that if a task asks the agent to write a script but doesn’t specify a filepath, and the tests assume a particular filepath for the script, the agent might fail through no fault of its own. Everything the grader checks should be clear from the task description; agents shouldn’t fail due to ambiguous specs. With frontier models, a 0% pass rate across many trials (i.e. 0% pass@100) is most often a signal of a broken task, not an incapable agent, and a sign to double-check your task specification and graders. For each task, it’s useful to create a reference solution: a known working output that passes all graders. This proves that the task is solvable and verifies graders are correctly configured.

Каждая задача должна быть решаемой агентом, который корректно следует инструкциям. Это может быть неочевидно. Например, аудит Terminal-Bench показал, что если задача просит агента написать скрипт, но не указывает путь к файлу, а тесты предполагают конкретный путь, агент может провалиться не по своей вине. Всё, что проверяет грейдер, должно быть ясно из описания задачи; агенты не должны проваливаться из-за двусмысленных спецификаций. При работе с передовыми моделями 0% прохождений на множестве проб (т. е. 0% pass@100) чаще всего сигнализирует о сломанной задаче, а не о неспособном агенте, и является поводом перепроверить спецификацию задачи и грейдеры. Для каждой задачи полезно создать эталонное решение: заведомо рабочий результат, проходящий все грейдеры. Это доказывает, что задача решаема, и подтверждает корректность настройки грейдеров.

Step 3: Build balanced problem sets

Шаг 3: Создавайте сбалансированные наборы задач

Test both the cases where a behavior should occur and where it shouldn't. One-sided evals create one-sided optimization. For instance, if you only test whether the agent searches when it should, you might end up with an agent that searches for almost everything. Try to avoid class-imbalanced evals. We learned this firsthand when building evals for web search in Claude.ai. The challenge was preventing the model from searching when it shouldn’t, while preserving its ability to do extensive research when appropriate. The team built evals covering both directions: queries where the model should search (like finding the weather) and queries where it should answer from existing knowledge (like “who founded Apple?”). Striking the right balance between undertriggering (not searching when it should) or overtriggering (searching when it shouldn’t) was difficult, and took many rounds of refinements to both the prompts and the eval. As more example problems come up, we continue to add to evals to improve our coverage.

Тестируйте как случаи, когда поведение должно проявиться, так и когда оно не должно. Односторонние оценки ведут к односторонней оптимизации. Например, если вы тестируете только, ищет ли агент когда нужно, вы можете получить агента, который ищет почти по любому поводу. Старайтесь избегать несбалансированных по классам оценок. Мы усвоили это на собственном опыте при создании оценок для веб-поиска в Claude.ai. Задача заключалась в том, чтобы не дать модели искать, когда не нужно, при этом сохранив её способность проводить обширное исследование, когда это уместно. Команда создала оценки в обоих направлениях: запросы, по которым модель должна искать (например, узнать погоду), и запросы, на которые она должна ответить из имеющихся знаний (например, «кто основал Apple?»). Найти правильный баланс между недостаточным срабатыванием (не ищет, когда нужно) и избыточным срабатыванием (ищет, когда не нужно) было непросто, и потребовалось много итераций как промптов, так и самой оценки. По мере появления новых примеров мы продолжаем пополнять оценки для улучшения покрытия.

Design the eval harness and graders

Спроектируйте среду оценки и грейдеры

Step 4: Build a robust eval harness with a stable environment

Шаг 4: Создайте надёжную среду оценки со стабильным окружением

It’s essential that the agent in the eval functions roughly the same as the agent used in production, and that the environment itself doesn’t introduce further noise. Each trial should be “isolated” by starting from a clean environment. Unnecessary shared state between runs (leftover files, cached data, resource exhaustion) can cause correlated failures due to infrastructure flakiness rather than agent performance. Shared state can also artificially inflate performance. For example, in some internal evals we observed Claude gaining an unfair advantage on some tasks by examining the git history from previous trials. If multiple distinct trials fail because of the same limitation in the environment (like limited CPU memory), these trials are not independent because they’re affected by the same factor, and the eval results become unreliable for measuring agent performance.

Крайне важно, чтобы агент в оценке функционировал примерно так же, как агент в продакшене, и чтобы само окружение не вносило дополнительный шум. Каждая проба должна быть «изолирована», начинаясь с чистого окружения. Ненужное общее состояние между запусками (оставшиеся файлы, кешированные данные, исчерпание ресурсов) может вызывать коррелированные сбои из-за нестабильности инфраструктуры, а не производительности агента. Общее состояние может также искусственно завышать результаты. Например, в некоторых внутренних оценках мы заметили, что Claude получал нечестное преимущество на отдельных задачах, изучая историю git от предыдущих проб. Если несколько разных проб проваливаются из-за одного и того же ограничения среды (например, недостаточного объёма оперативной памяти), эти пробы не являются независимыми, поскольку на них влияет один и тот же фактор, и результаты оценки становятся ненадёжными для измерения производительности агента.

Step 5: Design graders thoughtfully

Шаг 5: Проектируйте грейдеры вдумчиво

As discussed above, great eval design involves choosing the best graders for the agent and the tasks. We recommend choosing deterministic graders where possible, LLM graders where necessary or for additional flexibility, and using human graders judiciously for additional validation.

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

There is a common instinct to check that agents followed very specific steps like a sequence of tool calls in the right order. We’ve found this approach too rigid and results in overly brittle tests, as agents regularly find valid approaches that eval designers didn’t anticipate. So as not to unnecessarily punish creativity, it’s often better to grade what the agent produced, not the path it took.

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

For tasks with multiple components, build in partial credit. A support agent that correctly identifies the problem and verifies the customer but fails to process a refund is meaningfully better than one that fails immediately. It’s important to represent this continuum of success in results.

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

Model grading often takes careful iteration to validate accuracy. LLM-as-judge graders should be closely calibrated with human experts to gain confidence that there is little divergence between the human grading and model grading. To avoid hallucinations, give the LLM a way out, like providing an instruction to return “Unknown” when it doesn’t have enough information. It can also help to create clear, structured rubrics to grade each dimension of a task, and then grade each dimension with an isolated LLM-as-judge rather than using one to grade all dimensions. Once the system is robust, it’s sufficient to use human review only occasionally.

Оценивание моделью часто требует тщательной итерации для подтверждения точности. LLM-судей следует тщательно калибровать с человеческими экспертами, чтобы убедиться в малом расхождении между человеческой и модельной оценкой. Чтобы избежать галлюцинаций, дайте LLM возможность отступить, например, инструкцию возвращать «Неизвестно», когда информации недостаточно. Также помогает создавать чёткие, структурированные рубрики для оценки каждого измерения задачи и оценивать каждое измерение отдельным LLM-судьёй, а не одним для всех измерений. Когда система надёжна, достаточно прибегать к человеческой рецензии лишь изредка.

Some evaluations have subtle failure modes that result in low scores even with good agent performance, as the agent fails to solve tasks due to grading bugs, agent harness constraints, or ambiguity. Even sophisticated teams can miss these issues. For example, Opus 4.5 initially scored 42% on CORE-Bench, until an Anthropic researcher found multiple issues: rigid grading that penalized “96.12” when expecting “96.124991…”, ambiguous task specs, and stochastic tasks that were impossible to reproduce exactly. After fixing bugs and using a less constrained scaffold, Opus 4.5’s score jumped to 95%. Similarly, METR discovered several misconfigured tasks in their time horizon benchmark that asked agents to optimize to a stated score threshold, but the grading required exceeding that threshold. This penalized models like Claude for following the instructions, while models that ignored the stated goal received better scores. Carefully double-checking tasks and graders can help avoid these problems.

Некоторые оценки имеют тонкие режимы отказа, приводящие к низким баллам даже при хорошей работе агента, поскольку агент не решает задачи из-за ошибок в оценивании, ограничений среды агента или двусмысленности. Даже опытные команды могут упустить эти проблемы. Например, Opus 4.5 изначально набрал 42% на CORE-Bench, пока исследователь Anthropic не обнаружил множество проблем: жёсткое оценивание, штрафующее «96.12» при ожидании «96.124991…», двусмысленные спецификации задач и стохастические задачи, которые невозможно было точно воспроизвести. После исправления ошибок и использования менее ограничивающей среды результат Opus 4.5 подскочил до 95%. Аналогично, METR обнаружили несколько неправильно настроенных задач в их бенчмарке временного горизонта, которые просили агентов оптимизировать до заявленного порога баллов, но оценивание требовало превышения этого порога. Это штрафовало модели вроде Claude за следование инструкциям, тогда как модели, игнорирующие заявленную цель, получали лучшие оценки. Тщательная перепроверка задач и грейдеров помогает избежать этих проблем.

Make your graders resistant to bypasses or hacks. The agent shouldn’t be able to easily “cheat” the eval. Tasks and graders should be designed so that passing genuinely requires solving the problem rather than exploiting unintended loopholes.

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

Maintain and use the eval long-term

Поддерживайте и используйте оценку в долгосрочной перспективе

Step 6: Check the transcripts

Шаг 6: Проверяйте транскрипты

You won't know if your graders are working well unless you read the transcripts and grades from many trials. At Anthropic, we invested in tooling for viewing eval transcripts and we regularly take the time to read them. When a task fails, the transcript tells you whether the agent made a genuine mistake or whether your graders rejected a valid solution. It also often surfaces key details about agent and eval behavior.

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

Failures should seem fair: it’s clear what the agent got wrong and why. When scores don’t climb, we need confidence that it’s due to agent performance and not the eval. Reading transcripts is how you verify that your eval is measuring what actually matters, and is a critical skill for agent development.

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

Step 7: Monitor for capability eval saturation

Шаг 7: Отслеживайте насыщение оценок возможностей

An eval at 100% tracks regressions but provides no signal for improvement. Eval saturation occurs when an agent passes all of the solvable tasks, leaving no room for improvement. For instance, SWE-Bench Verified scores started at 30% this year, and frontier models are now nearing saturation at >80%. As evals approach saturation, progress will also slow, as only the most difficult tasks remain. This can make results deceptive, as large capability improvements appear as small increases in scores. For example, the code review startup Qodo was initially unimpressed by Opus 4.5 because their one-shot coding evals didn’t capture the gains on longer, more complex tasks. In response, they developed a new agentic eval framework, providing a much clearer picture of progress.

Оценка со 100% прохождением отслеживает регрессии, но не даёт сигнала для улучшений. Насыщение оценки происходит, когда агент проходит все решаемые задачи, не оставляя пространства для роста. Например, результаты SWE-Bench Verified начинались с 30% в этом году, а передовые модели сейчас приближаются к насыщению на уровне >80%. По мере приближения к насыщению прогресс также замедляется, так как остаются только самые сложные задачи. Это может делать результаты обманчивыми, поскольку большие улучшения возможностей выглядят как малые приросты в баллах. Например, стартап по ревью кода Qodo изначально не был впечатлён Opus 4.5, потому что их одношаговые кодовые оценки не фиксировали прирост на более длинных и сложных задачах. В ответ они разработали новый агентный фреймворк оценки, который дал гораздо более ясную картину прогресса.

As a rule, we do not take eval scores at face value until someone digs into the details of the eval and reads some transcripts. If grading is unfair, tasks are ambiguous, valid solutions are penalized, or the harness constrains the model, the eval should be revised. 

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

Step 8: Keep evaluation suites healthy long-term through open contribution and maintenance

Шаг 8: Поддерживайте здоровье наборов оценок в долгосрочной перспективе через открытый вклад и сопровождение

An eval suite is a living artifact that needs ongoing attention and clear ownership to remain useful.

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

At Anthropic, we experimented with various approaches to eval maintenance. What proved most effective was establishing dedicated evals teams to own the core infrastructure, while domain experts and product teams contribute most eval tasks and run the evaluations themselves.

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

For AI product teams, owning and iterating on evaluations should be as routine as maintaining unit tests. Teams can waste weeks on AI features that “work” in early testing but fail to meet unstated expectations that a well-designed eval would have surfaced early. Defining eval tasks is one of the best ways to stress-test whether the product requirements are concrete enough to start building.

Для продуктовых команд, работающих с ИИ, владение и итерация оценок должны быть столь же привычными, как сопровождение юнит-тестов. Команды могут потратить недели на AI-функции, которые «работают» при раннем тестировании, но не соответствуют невысказанным ожиданиям, которые хорошо спроектированная оценка выявила бы рано. Определение задач для оценки — один из лучших способов проверить, достаточно ли конкретны требования к продукту, чтобы начинать разработку.

We recommend practicing eval-driven development: build evals to define planned capabilities before agents can fulfill them, then iterate until the agent performs well. Internally, we often build features that work “well enough” today but are bets on what models can do in a few months. Capability evals that start at a low pass rate make this visible. When a new model drops, running the suite quickly reveals which bets paid off.

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

The people closest to product requirements and users are best positioned to define success. With current model capabilities, product managers, customer success managers, or salespeople can use Claude Code to contribute an eval task as a PR—let them! Or, even better, actively enable them.

Люди, наиболее близкие к требованиям продукта и пользователям, лучше всего подготовлены для определения успеха. С текущими возможностями моделей продакт-менеджеры, менеджеры по успеху клиентов или менеджеры по продажам могут использовать Claude Code для внесения задачи оценки в виде PR — позвольте им это делать! Или, ещё лучше, активно содействуйте этому.

How evals fit with other methods for a holistic understanding of agents

Как оценки вписываются в другие методы для целостного понимания агентов

Automated evaluations can be run against an agent in thousands of tasks without deploying to production or affecting real users. But this is just one of many ways to understand agent performance. A complete picture includes production monitoring, user feedback, A/B testing, manual transcript review, and systematic human evaluation.

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

An overview of approaches for understanding AI agent performance

Обзор подходов к пониманию производительности AI-агентов

Более быстрая итерацияПолная воспроизводимостьНет влияния на пользователейМожно запускать при каждом коммитеТестирует сценарии в масштабе без необходимости развёртывания в продакшене

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

Выявляет реальное поведение пользователей в масштабеОбнаруживает проблемы, которые пропускают синтетические оценкиПредоставляет ground truth о фактической производительности агентов

Реактивный подход; проблемы доходят до пользователей до того, как вы о них узнаётеСигналы могут быть зашумлённымиТребует инвестиций в инструментированиеОтсутствует ground truth для оценивания

Измеряет реальные пользовательские результаты (удержание, завершение задач)Контролирует смешивающие факторыМасштабируемо и систематично

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

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

Разреженная и смещённая в сторону самостоятельно обратившихсяСклоняется к серьёзным проблемамПользователи редко объясняют, почему что-то не сработалоНе автоматизированаОсновная опора на пользователей для обнаружения проблем может негативно влиять на пользовательский опыт

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

ТрудоёмкоНе масштабируетсяПокрытие непоследовательноУсталость рецензентов или разные рецензенты могут влиять на качество сигналаОбычно даёт только качественный сигнал, а не чёткую количественную оценку

Эталонные суждения о качестве от нескольких человеческих оценщиковПодходит для субъективных или двусмысленных задачДаёт сигнал для улучшения модельных грейдеров

Относительно дорого и медленноСложно проводить частоРасхождения между оценщиками требуют согласованияСложные области (юриспруденция, финансы, здравоохранение) требуют привлечения человеческих экспертов для проведения исследований

These methods map to different stages of agent development. Automated evals are especially useful pre-launch and in CI/CD, running on each agent change and model upgrade as the first line of defense against quality problems. Production monitoring kicks in post-launch to detect distribution drift and unanticipated real-world failures. A/B testing validates significant changes once you have sufficient traffic. User feedback and transcript review are ongoing practices to fill the gaps: triage feedback constantly, sample transcripts to read weekly, and dig deeper as needed. Reserve systematic human studies for calibrating LLM graders or evaluating subjective outputs where human consensus serves as the reference standard.

Эти методы соответствуют различным стадиям разработки агента. Автоматические оценки особенно полезны до запуска и в CI/CD — они запускаются при каждом изменении агента и обновлении модели как первая линия защиты от проблем с качеством. Мониторинг в продакшене включается после запуска для обнаружения дрейфа распределения и непредвиденных сбоев в реальных условиях. A/B-тестирование валидирует значительные изменения при наличии достаточного трафика. Обратная связь от пользователей и просмотр транскриптов — это непрерывные практики для заполнения пробелов: постоянно разбирайте обратную связь, еженедельно читайте выборку транскриптов и углубляйтесь по мере необходимости. Систематические человеческие исследования оставляйте для калибровки LLM-грейдеров или оценки субъективных результатов, где консенсус людей служит эталонным стандартом.

The most effective teams combine these methods: automated evals for fast iteration, production monitoring for ground truth, and periodic human review for calibration.

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

Conclusion

Заключение

Teams without evals get bogged down in reactive loops—fixing one failure, creating another, unable to distinguish real regressions from noise. Teams that invest early find the opposite: development accelerates as failures become test cases, test cases prevent regressions, and metrics replace guesswork. Evals give the whole team a clear hill to climb, turning “the agent feels worse” into something actionable. The value compounds, but only if you treat evals as a core component, not an afterthought.

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

The patterns vary by agent type, but the fundamentals described here are constant. Start early and don’t wait for the perfect suite. Source realistic tasks from the failures you see. Define unambiguous, robust success criteria. Design graders thoughtfully and combine multiple types. Make sure the problems are hard enough for the model. Iterate on the evaluations to improve their signal-to-noise ratio. Read the transcripts!

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

AI agent evaluation is still a nascent, fast-evolving field. As agents take on longer tasks, collaborate in multi-agent systems, and handle increasingly subjective work, we will need to adapt our techniques. We’ll keep sharing best practices as we learn more.

Оценка AI-агентов — это всё ещё зарождающаяся, быстро развивающаяся область. По мере того как агенты берутся за более длительные задачи, сотрудничают в мультиагентных системах и выполняют всё более субъективную работу, нам нужно будет адаптировать наши методы. Мы продолжим делиться лучшими практиками по мере накопления опыта.

Acknowledgements

Благодарности

Written by Mikaela Grace, Jeremy Hadfield, Rodrigo Olivares, and Jiri De Jonghe. We're also grateful to David Hershey, Gian Segato, Mike Merrill, Alex Shaw, Nicholas Carlini, Ethan Dixon, Pedram Navid, Jake Eaton, Alyssa Baum, Lina Tawfik, Karen Zhou, Alexander Bricken, Sam Kennedy, Robert Ying, and others for their contributions. Special thanks to the customers and partners we have learned from through collaborating on evals, including iGent, Cognition, Bolt, Sierra, Vals.ai, Macroscope, PromptLayer, Stripe, Shopify, the Terminal Bench team, and more. This work reflects the collective efforts of several teams who helped develop the practice of evaluations at Anthropic.

Авторы: Mikaela Grace, Jeremy Hadfield, Rodrigo Olivares и Jiri De Jonghe. Мы также благодарны David Hershey, Gian Segato, Mike Merrill, Alex Shaw, Nicholas Carlini, Ethan Dixon, Pedram Navid, Jake Eaton, Alyssa Baum, Lina Tawfik, Karen Zhou, Alexander Bricken, Sam Kennedy, Robert Ying и другим за их вклад. Особая благодарность клиентам и партнёрам, у которых мы учились в ходе совместной работы над оценками, включая iGent, Cognition, Bolt, Sierra, Vals.ai, Macroscope, PromptLayer, Stripe, Shopify, команду Terminal Bench и других. Эта работа отражает коллективные усилия нескольких команд, которые помогли развить практику оценок в Anthropic.

Appendix: Eval frameworks

Приложение: фреймворки для оценок

Several open-source and commercial frameworks can help teams implement agent evaluations without building infrastructure from scratch. The right choice depends on your agent type, existing stack, and whether you need offline evaluation, production observability, or both.

Harbor is designed for running agents in containerized environments, with infrastructure for running trials at scale across cloud providers and a standardized format for defining tasks and graders. Popular benchmarks like Terminal-Bench 2.0 ship through the Harbor registry, making it easy to run established benchmarks along with custom eval suites.

Braintrust is a platform that combines offline evaluation with production observability and experiment tracking—useful for teams that need to both iterate during development and monitor quality in production. Its `autoevals` library includes pre-built scorers for factuality, relevance, and other common dimensions.

LangSmith offers tracing, offline and online evaluations, and dataset management with tight integration into the LangChain ecosystem. Langfuse provides similar capabilities as a self-hosted open-source alternative for teams with data residency requirements.

Несколько open-source и коммерческих фреймворков помогут командам реализовать оценки агентов без создания инфраструктуры с нуля. Правильный выбор зависит от типа вашего агента, существующего стека и того, нужна ли вам офлайн-оценка, наблюдаемость в продакшене или и то, и другое.Harbor предназначен для запуска агентов в контейнеризованных средах, с инфраструктурой для проведения проб в масштабе у различных облачных провайдеров и стандартизированным форматом для определения задач и грейдеров. Популярные бенчмарки, такие как Terminal-Bench 2.0, распространяются через реестр Harbor, что упрощает запуск как устоявшихся бенчмарков, так и пользовательских наборов оценок.Braintrust — это платформа, сочетающая офлайн-оценку с наблюдаемостью в продакшене и отслеживанием экспериментов, полезная для команд, которым нужно итерировать в процессе разработки и мониторить качество в продакшене. Его библиотека `autoevals` включает готовые скореры для фактологичности, релевантности и других распространённых измерений. LangSmith предлагает трассировку, офлайн- и онлайн-оценки и управление датасетами с тесной интеграцией в экосистему LangChain. Langfuse предоставляет аналогичные возможности в виде self-hosted open-source альтернативы для команд с требованиями к размещению данных.

Arize offers Phoenix, an open-source platform for LLM tracing, debugging, and offline or online evaluations, and AX, a SaaS offering that extends Phoenix for scale, optimization and monitoring.

Many teams combine multiple tools, roll their own eval framework, or just use simple evaluation scripts as a starting point. We find that while frameworks can be a valuable way to accelerate progress and standardize, they’re only as good as the eval tasks you run through them. It’s often best to quickly pick a framework that fits your workflow, then invest your energy in the evals themselves by iterating on high-quality test cases and graders.

Arize предлагает Phoenix — open-source платформу для трассировки, отладки и офлайн- или онлайн-оценки LLM, а также AX — SaaS-решение, расширяющее Phoenix для масштабирования, оптимизации и мониторинга. Многие команды комбинируют несколько инструментов, создают собственный фреймворк оценки или просто используют простые скрипты оценки как отправную точку. Мы считаем, что хотя фреймворки могут быть ценным способом ускорить прогресс и стандартизировать процесс, они хороши лишь настолько, насколько хороши задачи оценки, которые вы через них прогоняете. Зачастую лучше быстро выбрать фреймворк, подходящий вашему рабочему процессу, а затем вложить энергию в сами оценки, итерируя над высококачественными тестовыми случаями и грейдерами.