Как строить 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-платформы для агентов. Лайфхаком не является, но намек вы поняли.

Sutskever's List.

Согласно лору интернета, это список статей, которым Илья поделился в частной беседе с John Carmack (известный разработчик, создатель Doom, впоследствии работал над Oculus), добавив:

 ‘If you really learn all of these, you’ll know 90% of what matters today.’

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

Список состоит из статей по CNN, RNN, механизмам внимания, scaling laws и другим актуальным на сегодняшний день понятиям.

Если допустить, что список дейсвтительно подлинный, то по мнению Ильи весь современный Deep Learning можно покрыть чуть ли не 30 работами. Мне кажется, в целом совпадает с реальностью, так как как больших идей действительно не так много.

Интересно, что одного это не проверенного источника оказалось достаточно, чтобы издательство Manning выпустило книгу с одноименным названием. Посмотреть и при желании купить можно тут. Книга еще формально в разработке, но все главы уже доступны.

Не берусь судить о качестве книги целиком, бегло прочитал только одну главу. Про наш с вами любимый self attention. Глава построена на основе культовой статьи Attention Is All You Need.

И честно...мне показалось это бесполезнейшим текстом. Если автор пишет для новичков, то из тех скудных диаграм и примеров точно не будет ничего понятно. А если автор пишет для тех кто разбирается и хочет углубить знания, то он не привносит ничего нового. Оригинальная работа, например, не очень углубляется в детали того, зачем нужна нормировка QK произведения на корень из размерности эмбеддингов. Оригинальная статья так же и не дает детальных пояснений почему позиционные эмбеддинги считается через чередование sin, cos и какие свойства это дает. Казалось бы, вот супер годный контент для углубления и раскрытия в книге. Но автор ограничивается не самыми сильными аналогиями. Если взять статью и идти в гугл / чатгпт каждый раз когда непонятно, то можно углубить свои знания сильно быстрее.

А название и правда крутое.
What Did Ilya See?

AI компании продолжают захватывать лондонскую подземку. В этот раз реклама Lovable о простоте вайбкодинга.

Все конечно круто, но только рекламщики явно не учили, что интернет в местном метро вещь довольно редкая, и как правило между станциями не ловит. На ветке Виктория так точно.

Последние пару месяцев я плотно работал над этим релизом, и наконец-то мы выкатываем его в опенсорс!

📟 Встречайте SWE-rebench-V2: самый большой открытый, мультиязычный датасет для обучения кодовых агентов!

Вместе с командой Nebius AI R&D мы построили пайплайн для масштабного сбора задач из реальных GitHub репозиториев и теперь делимся всем с комьюнити. На текущий момент это самый большой и разнообразный открытый датасет подобных задач в мире.

Что внутри:
> 32 000+ задач — на базе реальных issue + готовый Docker-образ.
> 20 языков программирования. Некоторые языки (например, Lua или Clojure) вообще никогда раньше не были покрыты!
> 120 000+ дополнительных задач, собранных на базе реальных PR.
> Качество — задачи отфильтрованы и размечены с помощью ансамбля LLM. Также мы обогатили их метаданными и добавили интерфейсы, которые проверяются в тестах.

Вместе с датасетом мы дропаем техрепорт со всеми деталями нашего пайплайна и прогонами моделей.

📄 Статья и датасет

👾 Наш Discord (мы там онлайн, залетайте с фидбеком и вопросами).

✉️ Пост в X

Если есть любые мысли, идеи, предложения - приходите!

🔁 Буду благодарен за репост и пересылку!

Сегодня ребята из Nebius релизнули новую версию SWE-rebench-v2.

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

Видно, что ребята проделали колоссальную работу, чтобы собрать такой датасет. Поддержите лайком на HF Papers, чтобы больше людей знали про хорошую статью!

И отдельно порекомендую канал Ибрагима, автора статьи. Все про кодинговых агентов, крутые технические заметки, карьера в рисерче и наблюдения из жизни!

Столкнулся недавно с тем, что перформанс популярных кодинговых агентов на внутренних бенчмарках, может значимо скакать (3-7%) в зависимости от времени суток и нагрузки на провайдера.

Дело в том, что в пиковые часы агенты могут медленнее генерировать решения из-за большого трафика. Особенно сильно у меня проседал Claude Code. Как результат, наблюдал всплеск AgentTimeoutError при прогонах автономных бенчей.

Единственного решения такой проблемы нет, есть только много вариантов с своими нюансами. 1) Ограничивать не время, а доступный бюджет на задачу 2) Увеличивать время на выполнение задачи на основе прошлых прогонов 3) Ловить пики и запускать бенчи только когда нет высокого трафика. И еще много-много эвристик. Все решения по-своему плохи, когда у тебя весь продукт про эвалы, но это уже другой момент.

Интересно было посмотреть, сталкивается ли кто-то еще с подобными проблемами. И из свежего наткнулся на заметку от самих Антропиков – Quantifying infrastructure noise in agentic coding evals. Они делятся в целом своим опытом борьбы с шумом в инфраструктуре.

Конкретно, рассказывают, что отловили неприятный эффект, который сказывался на результатах бенчмарка Terminal Bench.

Kubernetes кластер команды был устроен так, что если агент во время выполнения задачи в изолированной среде, в контейнере, вдруг превышал лимит на гарантированно отведенные ему ресурсы, то контейнер сразу умирал.

У контейнерных рантаймов обычно есть два отдельных параметра на ресурсы: гарантированные ресурсы, которые резервируется заранее, и жёсткий upper bound, при превышении которого контейнер просто убивается. Если выставить их в одно и то же значение (что было сделано у антропиков), то нет запаса на непредвиденные всплески – любое отклонение приведет к OOM контейнера, который в норме спокойно бы дожил до конца задачи.

В общем, они заметили что процент таких ошибок большой (достигает 6% по их графикам) и решили расслабить ограничения, увеличив зазор лимита на ресурсы в 1x, 2x, ... 4x и наконец убрав ограничение совсем.

Результаты на картинке снизу. Инфраструктурные ошибки почти ушли, а скоры выросли пропорционально, на 6%. Приятно и полезно.

Отдельно пишут и про другие источники шума, в частности time limit constraints, которые по их опыту влияют на результаты бенчей, но конкретных исследований и замеров не проводили.

Так что да, если релизите модель или бенч, убедитесь, что результаты достоверны и не зависят от шума в инфре, или искусственных ограничений. А то сегодня +2% на бенче может быть SOTA!

Андрей @asmekal описал свой опыт собеседований на ML роли за 25 год и скомпилировал мысли в один классный лонгрид:
https://asmekal.github.io/blog/posts/interviews-2025-ml-research-engineer-uk

Тут полезные советы, примеры вопросов и что вообще можно ждать в собесах от стартапов, биг теха и фронтир лаб. Рекомендую почитать, особенно тем, кому актуально!

Литкод для numpy

В тему к посту выше

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

Формально, это конечно же никакой ни литкод. Но из-за того что задачи часто могут звучать далекими от жизни, можно сказать, что элемент литкода присутствует. Как правило, решение будет состоять из того, чтобы написать наивное решение с циклами, увидеть какой-то паттерн и найти как это можно свести к существующим операциям над тензорами (слайсы, бродкастинг, паддинг, cumsum, маскирование и так далее).

Пример подобной задачи:

Given a binary array mask and a value fill_value, return an array of the same length where each contiguous run of 1s is replaced by its 0-based run id (from left to right), and each 0 is replaced by fill_value.

mask = [0, 0, 1, 1, 0, 0, 1, 1, 1, 0, 1, 0, 1, 1, 1, 1, 0, 1, 0]
fill_value = -1

# output
[-1, -1, 0, 0, -1, -1, 1, 1, 1, -1, 2, -1, 3, 3, 3, 3, -1, 4, -1]

Или чуть более сложная версия (с точки зрения векторных операций):

Given a binary array mask, return an array of the same length where each contiguous run of 1s is replaced by its run length, and each 0 stays 0.

mask = [0, 1, 1, 0, 1, 1, 1, 0, 1]

# output
[0, 2, 2, 0, 3, 3, 3, 0, 1]

Такие секции не очень частое явление. Их можно увидеть в стартапах, организованных выходцами из больших лаб, где компании ориентированы на обучение своих моделей. Из того что я слышал, таким подходом пытаются заменить классический литкод про алгоритмы и структуры данных – чем-то более похожим, что делают ML инженеры. Подписчик вытянул подобные вопросы в 2 из 5 процессов с стартапами SF based.

Похоже ли это на ML инженерию в жизни? Частично. Когда-то я и в сам возился с сложными процессингом батчей и без эффективных операций над матрицами все работало крайне медленно; хорошее решение заняло часы (еще до агентской эпохи), много принтов и тестов, чтобы убедиться в правильности. Но в рамках интервью, пока что звучит как какое-то задротство. Классический ML Coding / ML Debugging, который хотя бы про известные кусочки мл архитектур, выглядит более разумно.

Остается важный вопрос. А как готовиться к такого рода задачам? Я не нашел одного хорошего ответа, как прокачивать свои навыки в такой нишевой теме, но вот несколько ссылок и советов:

1. Комфортно чувствовать себя при работе с ключевыми операциями над тензорами. Порешать упражнения из популярного репозитория тут
2. Более структурированный курс с набором упражнений на codechef
3. Платформы-тренажеры с вопросами в стиле интервью: tensorgym, tensortonic, deep-ML

Возможно, в комментарии еще накидают полезных ресурсов!
Кто знает, возможно такой формат адаптируют повсеместно, тогда будем гриндить новый тип литкода!

В прошлом году делал пост с подборкой ресурсов для желающих разобраться в деталях RLHF. Одним из ключевых ресурсов была книга довольно уважаемого рисерчера и преподавателя Nathan Lambert.

Сегодня у него вышло обновление. Автор оформил книгу в виде бесплатного мини-курса с видео-лекциями, слайдами и кодом.

Получилось 4 лекции по часу, от введения до математики и реализации.

Лекции на ютубе смотреть тут