Перейти к основному содержимому

Оцените своего агента Claude (Evals)

Продвинутый

Вы подправили промпт, и он кажется лучше — но так ли это? Без evals (оценок) вы летите вслепую: каждое изменение — это подбрасывание монетки, и вы узнаёте о поломке от рассерженного пользователя, а не от теста. Evals превращают «ощущения» в число, которому можно доверять, которое можно отстоять и отслеживать во времени. Это самое главное, что отличает любительские промпты от продакшен-уровня работы с Claude.

What you'll learn
  • Почему «мне это выглядит хорошо» — не тест, и что измерять вместо этого
  • Постройте golden dataset из РЕАЛЬНЫХ сбоев (снизу вверх), а не из выдуманных
  • Оценивайте кодом там, где можете, и LLM-as-judge там, где не можете
  • Подключите evals в CI, чтобы изменение промпта или модели никогда не дало незаметную регрессию

Образ мышления: измеряйте, не угадывайте​

Три правила, которые вас спасут:

  • Снизу вверх лучше, чем сверху вниз. Сначала собирайте реальные сбои, затем проектируйте метрику, чтобы их ловить. Eval, построенный на реальных поломках, предсказывает реальные поломки; eval, придуманный у доски, в основном измеряет ваше воображение.
  • Число, которое можно перезапустить. Eval повторяем: одинаковые входы → сопоставимый результат. Именно это позволяет честно сравнить промпт v1 и v2 или claude-haiku-4-5 и claude-sonnet-5.
  • Дёшево запускать — запускайте часто. Если на это у человека уходит полдня, этого не произойдёт. Автоматизируйте.

Постройте golden dataset (снизу вверх)​

Ваш golden dataset — сердце любого eval: тщательно отобранный набор входов с известными правильными ожиданиями.

Guided walkthrough1 of 4
  1. Начинайте с реальных плохих выводов: продакшен-трейсов, баг-репортов, тикетов поддержки. Именно эти случаи имеют значение.

Оценка: сначала код, потом судья​

Тянитесь к самой дешёвой надёжной проверке в первую очередь.

  • Программные (детерминированные) проверки — используйте их везде, где у ответа есть структура: точное совпадение / совпадение по ключевым словам, «валидный JSON по этой схеме», «вызвал ли он правильный инструмент с правильными аргументами», «меньше N токенов / меньше X мс». Быстро, бесплатно и никогда не флаки.
  • LLM-as-judge — для размытых измерений (полезность, тон, верность источнику), которые сопротивляются коду. Дайте судье рубрику, а не ощущение, и откалибруйте его по человеческим разметкам, прежде чем доверять ему.

:::warning У судей есть предвзятости LLM-судьи склоняются к более длинным ответам (предвзятость к многословию) и к тому варианту, который показан первым (позиционная предвзятость). Защита: строгая рубрика, попарное сравнение вместо абсолютной оценки, перестановка порядка ответов и перепроверка судьи на размеченном человеком срезе. Судья — это один слой, а не весь тест. :::

Рубрика LLM-as-judge (стартовая)

You are a strict grader. You are given a QUESTION, a REFERENCE answer, and a MODEL answer.
Score the MODEL answer from 1-5 on (a) faithfulness to the reference and (b) helpfulness.
Output ONLY JSON, nothing else: {"score": <1-5>, "reason": "<one short sentence>"}

QUESTION: {{question}}
REFERENCE: {{reference}}
MODEL: {{model_answer}}

Для агентов тестируйте ещё и траекторию​

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

Подключите это в CI​

Вот где evals окупаются: сделайте регрессии невозможными для мёрджа.

Guided walkthrough1 of 3
  1. Оценивайте программно, где возможно; запускайте судью на остальном.
Словарь evals
Нажмите Enter или пробел, чтобы перевернуть карточку. Используйте стрелки влево и вправо для перехода между карточками.Показан термин.
1 / 4

Проверь себя

0/3
  1. Какой самый надёжный первый выбор для оценки eval?
  2. Откуда в основном должны браться случаи golden dataset?
  3. Для АГЕНТА что нужно оценивать сверх финального ответа?
Key takeaways
  • Нет eval = релиз «на ощущениях». Постройте его, прежде чем доверять промпту или агенту.
  • Golden dataset из реальных сбоев; растите его каждую неделю на новых регрессиях.
  • Сначала проверки на основе кода; LLM-as-judge (с рубрикой, откалиброванный) для размытых частей.
  • Для агентов оценивайте траекторию, а не только вывод.
  • Запускайте это в CI и валите сборку при падении — так качество перестаёт регрессировать.

Источники и дополнительное чтение​

Дальше​