Как строить evaluation системы для AI агентов? Очередной крутой блог пост от Антропиков. Читать тут. Прорывных мыслей, бенчмарков или сокрального знания тут не найти, но зато очень хорошая структура (такое пригождается на систем дизайн интервью, если что), отличный технический словарь (task, transcript, evaluation harness, agent harness, и.т.д) и призыв к действию для тех, кто активно шаманит над агентами в рабочих задачах. И действительно. Если в прошлом году все поголовно были увлечены внедрением агентов процессы, то сейчас все переходят к стадии "а как с этими агентами со-существовать" и валидировать, что со временем они так же продолжают драйвить продуктивность (чтобы это не значило). Короче говоря, не хочется вслепую обновлять модель на новую и потом ловить себя на чувстве "так а чето стало только хуже". Поэтому Eval-ы и нужны. Eval (от evaluation) – это по большому счету тест AI агента. Даете ему среду, задачу, запускаете, и оцениваете результат. На бумаге легко. На деле же каждая из переменных: среда, задача и оценка результата – безумно сложная задача. Особенно на масштабе организаций с сотнями репозиториев. Тут нужна методичность и структура. Поэтому так легко свалиться в "да пофиг, вроде стало лучше". По работе много общаюсь с энтерпрайзами и это головная боль чуть ли не каждого. Собственно поэтому мы и стали командой делать eval платформу, в которой можно эвалить разного рода контекст (например, вы сделали claude skill, а насколько он хорош? оценить можно тут) или целые репозитории и смотреть насколько хорошо агенты справляются с задачами. Но про это в другой раз. Мне из блога откликнулись такие мысли. Смотреть на Eval-ы, как на модель швейцарского сыра. Картинка к посту в пояснение. Суть в том, что одним подходом все не поймать. Поэтому нужно много слоев. Где-то часть ошибок отловят автопроверки, где-то llm-as-judge, а где-то нужно смотреть не просто в input-output поведение, а анализировать логи агента и смотреть что он там накуролесил в процессе. Чем больше в системе детерминированных проверок, тем лучше (для вас). Проще дебажить, проще менять. Вслепую делегировать работу на откуп агенту-валидатору (читай llm-as-judge), себе дороже. По мнению такого валидатора все всегда будет ХО-РО-ШО. Как минимум рубрики нужно калибровать и смотреть глазами прежде чем внедрять такое и основывать на этом выводы. * Чем раньше начнете задумываться о концепции eval-ов, тем проще будет с агентами дальше. Потому что так будет четкие аргументы, почему агент не может решать задачи именно в вашей кодовой базе и во что инвестировать, чтобы стало лучше. Несколько знакомых так уже получили промоушены в биг техах, чисто за счет какой-никакой observability-платформы для агентов. Лайфхаком не является, но намек вы поняли.