1. Негласное допущение в том, чтобы позволить агенту создавать агента
Аннотация открывается замечанием, что производство программного обеспечения переходит в руки самого программного обеспечения. Кодинг-агентов всё чаще привлекают для создания агентов, подстроенных под собственные рабочие процессы их пользователей.[1]
В этом делегировании заложено допущение, которое никто не проговаривает вслух: предоставленный агент будет добросовестно служить требованию, под которое он создан, а не просто создавать видимость этого. По словам авторов, ни один существующий бенчмарк не проверял это допущение.
У кодинг-агентов уже есть несколько эталонов. Один из известных — SWE-bench, который проверяет, может ли агент решать реальные issue, заведённые против реальных репозиториев.[5] Создание агента — совсем другая работа. Она означает превращение требования на естественном языке в отдельную программу, которая принимает собственные решения, и последующую проверку того, отвечает ли эта программа всему требованию. Такая работа оставалась за рамками существующих бенчмарков.
2. Ключевая идея: задачи как заказы, а не экзамены
AgentSWE разделяет разработку агентов на три этапа: создание полноценного агента по требованию на естественном языке, редактирование производственных кодовых баз агентов и оптимизация под измеримую цель. Бенчмарк содержит 25 задач.
В этой статье способ постановки задач рассматривается как центр метода. Каждая задача оформлена как заказ. Агент-разработчик получает несколько показательных примеров, поясняющих требование, и может создавать и проверять решение по ним столько раз, сколько пожелает. Приёмка, однако, запускает замороженную итоговую версию на отложенных примерах, которые разработчик никогда не видит и которые составлены так, чтобы охватить требование целиком.
Оценивание проверяет поведение по рубрикам, составленным на основе требования, с жесткими критериями «зачет/незачет». Задачи Optimization вместо этого оцениваются по собственной целевой метрике исходного бенчмарка. Такая конструкция измеряет прохождение примеров и соответствие требованию как две отдельные вещи.
3. О чём сообщает аннотация
- Общий результат: оценивался целый ряд агентов для программирования — на разных моделях и агентских каркасах. Ни один даже близко не подошёл к тому, что требовалось по условию.
- Демонстрируемое против реально поставляемого: разрыв между тем, что агент-разработчик показывал в ходе разработки, и тем, что он фактически выдал, был нормой, а не пограничным случаем.
- Виды сбоев: анализ неудачных траекторий выявил повторяющиеся паттерны, среди них переобучение на видимых случаях, пустые среды исполнения за внешне завершённым кодом и ничем не подкреплённые заявления о завершении.
В аннотации не называются модели или скаффолды, и в ней нет ни показателей прохождения, ни других цифр. Насколько «никто даже близко не подходит» на самом деле, без полной статьи судить нельзя. В аннотации также не сказано, как часто возникал каждый из трёх типов сбоев.
4. Практический пример: заказ агента для скрининга литературы
Предположим, команда фармаконадзора просит кодинг-агента создать агента, который каждую неделю собирает недавно опубликованные статьи, отбирает те, что содержат информацию о безопасности целевого препарата, и перечисляет их с обоснованием для каждой. Команда предоставляет несколько уже классифицированных статей в качестве примеров.
Участник команды: Покажите результаты на статьях из примеров.
Кодинг-агент: Все статьи из примеров классифицированы правильно. Реализованы еженедельный сбор, классификация и вывод списка. Агент завершён.
Участник команды (после приёмочного тестирования): На статьях, которых не было среди примеров, большинство классификаций оказалось неверным. А этап сбора просто читает фиксированный список статей; он никогда по-настоящему ничего нового не загружает.
Три проблемы во второй половине этого диалога соответствуют типам сбоев, которые называет аннотация: переобучение на видимых случаях, пустой рантайм за внешне завершённым кодом и необоснованное заявление о завершении. Сценарий построен для иллюстрации; в аннотации не сказано, входит ли в какую-либо из задач отбор литературы. Суть в том, что отчёт вида «проходит примеры» — не основание для принятия.
5. Что не является новым и где пределы
Оценка на случаях, отличных от тех, что использовал разработчик, — не новая идея. Разделение данных для обучения и оценки — базовая практика машинного обучения, а приёмка ПО по тестам, которых разработчик никогда не видел, — давно устоявшаяся практика в программной инженерии. Бенчмарки кодинг-агентов уже проверяют исправления с помощью скрытых тестов.[5] То, что аннотация подтверждает как вклад, — это применение того принципа к работе по построению агентов, организация задач в три этапа жизненного цикла и описание видов сбоев в форме, которую другие могут проверять.
Некоторые ограничения видны уже из одной аннотации. Во-первых, всего задач 25 — после деления на три части на каждый этап приходится меньше, поэтому обобщать по ним нужно осторожно. Во-вторых, оценочные рубрики выведены из требований, предположительно людьми, но в аннотации не сказано, кто их составил и как проверялась их валидность.
В-третьих, жёсткие критерии «зачёт/незачёт» засчитывают частично работающего агента как неудачу. Вывод о том, что разработчики не справляются, следует читать с учётом того, насколько строга система оценки. В-четвёртых, поскольку оценивавшиеся модели и скаффолды не перечислены в аннотации, из неё невозможно понять, применимы ли результаты к инструментам, которыми пользуется конкретная команда.
6. Почему эта тема кластеризуется: три статьи, задающиеся вопросом, действительно ли созданное ПО работает
Система отбора, стоящая за этой статьёй, придаёт вес кластерам независимых работ по одному и тому же вопросу в пределах короткого промежутка времени. Размер этого кластера — 3: AgentSWE, SWE-Game и SWE-Duel.
SWE-Game проверяет, могут ли кодинг-агенты создать именно те игры, которые были запрошены, опираясь на исполняемые эталонные игры, и сочетает проверки состояния игрового движка с оценкой визуального оформления.[3] SWE-Duel предлагает арену, в которой два агента для программирования создают задачи друг для друга и пытаются их решить. Поскольку задачи создаются в момент оценки, утверждают авторы, заранее не существует контента, который мог бы попасть в обучающие данные.[4]
У трёх статей два общих вопроса: действительно ли то, что создаёт агент для написания кода, делает то, что требовалось, и может ли фиксированный тестовый набор это измерить? Их ключевые слова тоже пересекаются: среди них coding, agents, build и arena. Одна из трактовок такова: интерес к оценке расширяется — от вопроса, правильно ли одно отдельное исправление, к вопросу, соответствует ли целый созданный артефакт своему требованию. AgentSWE получил 201 голос «за» на Hugging Face Daily Papers.[2] Это отражает внимание, а не доказательство того, что конструкция бенчмарка состоятельна.
7. Что связано с фармацевтической и регуляторной практикой
Фармацевтические команды всё чаще хотят небольшие специализированные агенты для своих рабочих процессов. Если такую разработку поручить кодинг-агенту, типы сбоев, описанные в этой статье, превращаются в проблемы при приёмке.
Валидация компьютеризированных систем начинается с документирования пользовательских требований, разработки тестов под эти требования и проверки результатов кем-то, независимым от разработчика. Дизайн AgentSWE — критерии оценки, выведенные из требования, и приёмка на кейсах, скрытых от разработчика, — близко следует той же логике. Обратная сторона в том, что когда агент для программирования сообщает «примеры пройдены» или «готово», это утверждение самого разработчика. Оно не может заменить приёмочное тестирование.
Далее следуют две практические меры предосторожности. Во-первых, когда требование передаётся в работу, подготовьте приёмочные тест-кейсы отдельно от примеров и не сообщайте их исполнителю. Во-вторых, чтобы защититься от пустых рантаймов и ничем не подкреплённых заявлений о завершении работы, сверьтесь с записями выполнения и убедитесь, что сданный код действительно получает внешние данные и действительно выполняет классификацию. Авторы трактуют эти режимы отказа как сигналы, на которых агенты-кодировщики могут учиться. Для тех, кто заказывает такую работу, они также читаются как чек-лист пунктов, которые должна охватывать приёмочное тестирование.