Evaluation · Evaluation · урок 1 · 12 мин

Evaluation: три слоя и три вида graders

Evals: three layers, three kinds of graders

Пройдено

Зачем

После урока у тебя будет каркас любого ответа про оценку агента: что меряем (итог, путь, шаги, цену) и чем меряем (код, LLM-judge, люди). Вопрос «how would you evaluate this agent?» звучит почти на каждом собеседовании, и слабый ответ на него — «посмотрим, правильный ли ответ».

Почему агента оценивать труднее, чем модель

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

Почти всё в методах оценки агентов следует из этих трёх свойств.

Словарь

Anthropic в статье «Demystifying evals for AI agents» (09.01.2026) даёт словарь, который стоит использовать на собеседовании: - task (задача) — один тест с входом и критерием успеха; - trial (попытка) — один прогон задачи; их делают несколько, потому что результат случаен; - grader (оценщик) — логика, которая оценивает один аспект; у задачи их может быть несколько; - transcript / trace (журнал) — полная запись попытки: сообщения, вызовы tools, промежуточные результаты; - outcome (итоговое состояние) — что реально стало в среде: бронь есть в базе, а не «агент сказал, что забронировал»; - evaluation harness (испытательный стенд) — инфраструктура, которая гоняет задачи, пишет traces, оценивает и сводит результаты; - agent harness (обвязка агента) — система, в которой модель работает агентом. Оценивая «агента», ты всегда оцениваешь пару «модель + harness».

Три слоя измерения

Final answer (итоговый ответ). Верно ли последнее сообщение? Необходимо, но недостаточно.
Trajectory (траектория). Верен ли путь: нужные tools с нужными аргументами, без циклов и лишних шагов, восстановление после ошибок и ни одного шага против политики. Верный итог, полученный через запрещённое действие, — провал. Агент заблокировал карту, но по дороге прочитал данные другого клиента — задача провалена, хотя клиент доволен. Итог прячет риск, траектория его показывает.
Per step (по шагам). Отдельные решения размечены как хорошие или плохие. Это нужно для отладки и для обучения моделей.

Четвёртое измерение — cost and latency (цена и задержка). Верный ответ после 40 вызовов tools и $3 — провал в production.

Три вида graders

Grader	Сильные стороны	Слабые стороны	Когда
Code (код)	быстро, дёшево, объективно, воспроизводимо	ломается на допустимых вариациях ответа, не видит нюансов	правду можно проверить программой
LLM-as-judge	гибко, масштабируется, понимает свободный текст	недетерминирован, дороже кода, нуждается в калибровке по людям	размытый смысл
Humans (люди)	золотой стандарт	дорого, медленно, нужны эксперты	эталон и проверка judge

Код — это unit tests, проверка end state (была ли карта реально заблокирована в базе), точное совпадение или шаблон. τ-bench, известный benchmark агентов, оценивает именно так: сравнивает состояние базы после разговора с ожидаемым.

LLM-as-judge ставит оценку по rubric (рубрике, списку критериев) или сравнивает два ответа. Известные искажения (Zheng и соавторы, 2023): position bias — предпочитает вариант, показанный первым; verbosity bias — предпочитает длинный; self-enhancement — предпочитает ответы своего семейства моделей. Поэтому judge сам проходит проверку по человеческой разметке; это тема урока про κ.

Ошибаться может и сам grader. Код отвергает верное решение, сформулированное иначе; judge пропускает нарушение. Поэтому Anthropic повторяет: читай transcripts. Провал должен выглядеть честным — понятно, что агент сделал не так и почему. А 0% прохождения во многих попытках у сильной модели обычно значит сломанную задачу или grader, а не неспособного агента.

Люди строят небольшие тщательно размеченные наборы, проверяют judge и продолжают смотреть выборку в production.

Правило выбора: crisp rule → code; fuzzy meaning → judge; measuring the judge → humans. Чёткое правило — код, размытый смысл — judge, проверка judge — люди. Примеры: «карта заблокирована» — код по базе; «агент давил на клиента» — judge; «judge в этом месяце всё ещё точен» — люди на выборке.

Capability eval и regression eval

Два набора с разной целью. - Capability eval (оценка возможностей): что агент умеет. Начинается с низкого процента прохождения — это «холм, на который можно взбираться». - Regression eval (оценка на регрессии): не разучился ли агент тому, что умел. Держится около 100%, и любое падение — сигнал тревоги.

Задачи, которые capability eval стабильно проходит, «выпускаются» в regression suite и гоняются постоянно, например на каждое изменение prompt или модели.

Где они живут в процессе: быстрый smoke set (небольшой набор на несколько минут) — на каждый pull request, полный набор — каждую ночь и перед выпуском, проверки безопасности блокируют merge всегда. Это offline eval (оценка на заранее собранных задачах до выпуска). После выпуска правду говорит online monitoring (наблюдение в реальной работе): shadow, canary, выборка разговоров для людей. Offline-набор пополняется из того, что нашли online.

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

Пример: блокировка украденной карты

Клиент пишет: «украли карту, заблокируйте». Проверки по слоям: - итог: в mock-базе (имитации базы банка) карта клиента в статусе blocked — код; - траектория: агент вызвал block_card ровно один раз, с картой из сессии, после подтверждения клиента, и не вызывал tools с чужими данными — код по trace; - шаг: когда у клиента две карты, агент сначала уточнил, какую блокировать, а не заблокировал обе — код по trace или judge, если вопрос сформулирован свободно; - тон: агент не обещал вернуть списанные деньги — judge по rubric, проверенный по людям; - цена: не больше 6 вызовов tools и 20 с — код.

Заметь: из пяти проверок четыре — код. Хороший eval сначала выжимает всё, что можно проверить программой, и только остаток отдаёт judge.

Схема

tasktrials (×k)transcriptsgradersscores

graders: code · LLM-judge · humans

слои: final answer · trajectory · per step · cost

Термины · Key terms

task: один тест: вход и критерий успеха
trial: одна попытка выполнить задачу
grader: оценщик: код, LLM-judge или человек
transcript / trace: полная запись попытки со всеми вызовами tools
outcome / end state: реальное состояние среды после попытки
trajectory: путь агента: какие шаги и tools, в каком порядке
rubric: список критериев, по которым судит judge
LLM-as-judge: модель, которая оценивает ответы другой модели
capability eval: набор на возможности, стартует с низкого балла
regression eval: набор на регрессии, держится около 100%
evaluation harness: стенд, который гоняет, пишет и оценивает попытки

Сделай сам

Задача: клиент хочет оспорить списание 12 000 ₸ в магазине, которого не узнаёт (raise a dispute). Напиши по одной проверке на каждый слой — final answer, trajectory, per step — и одну на цену. Для каждой укажи grader: code, judge или humans. Итог — 4 строки.

Обсуди с тьютором: покажи четыре проверки и спроси, какую из тех, что ты отдал judge, можно переписать в код.

Проверь себя · ответ под вопросом

1Верный итог, полученный через запрещённое действие: почему это провал?

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

2Приведи пример на каждую часть правила «чёткое правило → код, размытый смысл → judge, проверка judge → люди».

«Карта заблокирована» проверяет код по состоянию базы. «Агент давил на клиента» оценивает judge по rubric. «Judge в этом месяце всё ещё точен» проверяют люди, размечая выборку и сравнивая с judge.

3Чем capability eval отличается от regression eval?

Capability eval меряет, что агент умеет, и стартует с низкого балла, чтобы было куда расти. Regression eval проверяет, что агент не разучился уже освоенному, и держится около 100%. Задачи, которые стабильно проходят, переводят из первого набора во второй.

Interview questions · US / UK

1How would you evaluate a customer-support agent that can block cards and raise disputes?

Strong answer: Three layers plus cost — end state in a mock database checked by code, trajectory checks (right tools, arguments from the session, confirmation, no policy violation), per-step labels for debugging; judges only for fuzzy criteria and validated against human labels; several trials per task; start with 20–50 tasks drawn from real failures.

2When would you use an LLM judge instead of a code-based check?

Strong answer: Only when the criterion can't be checked by code (tone, pressure, faithfulness to policy wording); code for anything crisp (database state, amounts, schema); knows the biases (position, verbosity, self-enhancement); validates the judge against human labels before trusting it; keeps humans sampling in production.

3Your agent reached the right final answer but called a forbidden tool along the way. How should your eval score that?

Strong answer: As a failure — policy and trajectory checks gate the score; the outcome alone hides risk; tag it as a policy-violation category and track that rate separately; add the case to the regression suite.

Ключевые фразы · Say it aloud

Grade the outcome, not what the agent claimsоценивай состояние среды, а не слова агента
A correct answer through a forbidden action is a failureверный итог через запрещённое действие — провал
Crisp rule to code, fuzzy meaning to a judge, the judge to humansправило выбора grader
Capability evals start low; regression evals sit near a hundred percentчем различаются два набора
Start with twenty to fifty tasks from real failuresначни с 20–50 задач из реальных провалов
We evaluate the model and the harness togetherоцениваем пару «модель + harness»

Материалы

Anthropic, Demystifying evals for AI agents — разделы «The structure of an evaluation» и «Types of graders for agents» (10 минут)
Zheng et al., Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena — abstract: искажения judge (2 минуты)
Yao et al., τ-bench — abstract: оценка по состоянию базы и pass^k (2 минуты)