Demystifying evals for AI agents: устройство оценки и заметки на полях (Рубрика #AI4SDLC)

Продолжаю тему agent harnesses. В "Demystifying evals for AI agents" ребята из Anthropic разбирают, как понять, что агент после очередного изменения стал лучше. Статья вышла 9 января 2026 года; авторы — Mikaela Grace, Jeremy Hadfield, Rodrigo Olivares и Jiri De Jonghe. Это инженерный обзор опыта Anthropic и клиентов; рекомендации основаны на отдельных практических случаях.

Сначала про основные части статьи.

🔸 Устройство eval Задача, отдельная попытка, grader, траектория и итоговое состояние среды. «Билет забронирован» в ответе агента ещё не означает, что бронь появилась в базе. Здесь же два harness: agent harness обеспечивает работу модели с инструментами, evaluation harness запускает испытания и собирает оценки. Проверяем мы модель вместе с её обвязкой.

🔸 Чем оценивать Кодом, LLM-судьёй и человеком. Для coding agents естественны тесты; для исследовательских — проверка опоры на источники и полноты; для диалоговых важны и результат, и качество общения. Оценки LLM нужно калибровать по человеческим.

🔸 Что измерять Capability evals показывают, чему агенту ещё предстоит научиться; regression evals защищают уже освоенное. А pass@k и pass^k отвечают на разные вопросы: получился ли хотя бы один успех за k попыток или успешны все k.

🔸 Как построить и поддерживать Авторы советуют начать с 20–50 реальных случаев, явно определить успех, изолировать прогоны и читать трассы. Ошибаться может и сам grader. Дальше набор нужно обновлять, а картину дополнять production-мониторингом, обратной связью и человеческой оценкой.

Теперь мои заметки по ходу чтения, которые есть в приложенном PDF

1️⃣ Знакомая инженерия Изоляция прогонов и сходство среды с production напоминают правила тестирования, eval-driven development — TDD. Даже организация работы знакомая: отдельная команда поддерживает инфраструктуру, продуктовые команды приносят задачи. Привет platform teams и stream-aligned teams. Только зелёный результат одного прогона здесь ещё не обещает зелёного следующего.

2️⃣ Ожидания тоже надо сформулировать На ранней стадии пользователей может ещё не быть, а критерии качества только складываются. Evals помогают задать этот уровень и дальше удерживать его. Особенно полезно при частых обновлениях моделей: появляется свой набор проверок для решения о переходе.

3️⃣ DOM и скриншоты Раньше я считал, что скриншоты дороже, а работа через DOM дешевле. У авторов есть обратный пример: выгрузка всего DOM может съесть больше токенов. Тут хочется отдельно считать объём переданных данных, задержку и число действий — универсального победителя из этого не получается.

4️⃣ OR, AND и независимость Метрику pass@k удобно понимать как логический OR, pass^k — как логический AND. Но расчёт p^k требует независимых попыток с одинаковой вероятностью успеха. При p = 0,75 три успеха подряд дают примерно 42% только с этими допущениями. Общая среда, оставшиеся файлы или память между попытками могут их нарушить.

5️⃣Траектории Симулятор пользователя напомнил мои разборы "SWE-Together" и "SWE-Interact". В статье рядом живут два совета: оценивать процесс и не навязывать агенту конкретную последовательность шагов. Я бы совместил их через проверку свойств процесса: агент мог начать исправление бага с теста или чтения кода, но заявление «проверено» должно относиться к окончательной версии. А права доступа и запрет записи за пределами рабочей области стоит обеспечивать самим harness: успешный eval не заменяет блокировку запрещённого действия.

#AI4SDLC #Agents #Evals #Research #Engineering #PlatformEngineering