Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Проверка кодинг-агента по одной подробно описанной задаче из трекера не отражает работу разработчика в IDE: требования раскрываются постепенно, а просьбы написать код чередуются с вопросами, планированием и проверкой результата. JetBrains Research показала, что последовательная подача задачи примерно удваивает затраты на агента без устойчивого изменения доли решённых задач; препринт не рецензирован, а числа в нём получили сами авторы. Для оценки интерактивного продукта одного итогового патча недостаточно — нужно учитывать весь поток запросов.
Реальный сеанс не похож на задачу из трекера
Авторы собрали 4 782 сеанса разработчиков с агентами внутри JetBrains IDEs и описали их через поток задач. Он включает длину диалога, тип каждого пользовательского сообщения и переходы между соседними типами.
Для основного анализа взяли сеансы как минимум с тремя сообщениями пользователя — таких оказалось 33%. Запросы распределили по типам: исправление ошибки, новая функция, объяснение существующего кода, планирование, проверка кода, запуск и другие действия.
Разрыв с обычными бенчмарками виден не только в длине диалога. В SWE-Bench Pro новые функции и исправления ошибок составляют 93,8% задач, тогда как в рабочих сеансах эти два типа не покрывают и половины сообщений. Разработчик может начать с функции, затем спросить о текущем поведении проекта, уточнить план и попросить проверить изменение.
Простой подсчёт типов здесь не сработает. Два набора могут содержать одинаковую долю вопросов и задач на реализацию, но различаться порядком: вопрос до изменения проверяет понимание исходного кода, а тот же вопрос после изменения — способность удержать новый контекст.
Три публичных корпуса взаимодействий также заметно отличались от рабочих сеансов и друг от друга. Поэтому «реалистичный поток» нельзя задать один раз для всех продуктов: его нужно измерять на сценариях конкретного IDE-помощника, агента для трекера или средства проверки кода.
Как превратить готовый бенчмарк в последовательность запросов
Метод SWE-TaskFlow сохраняет репозиторий, среду запуска, исходные требования и итоговые тесты существующего бенчмарка. Он меняет только слой взаимодействия — сообщения, которые агент получает по ходу работы.
Сначала подробную постановку делят на три последовательные части. Каждая должна быть выполнима в текущем состоянии репозитория, не добавлять новых требований и дословно сохранять технические детали. Если разделить задачу без искажений нельзя, она остаётся одношаговой.
Затем в диалог добавляют проверяемые вопросы о проекте: например, как работает существующий участок кода. Вопрос строят по репозиторию и траектории агента, который уже решил исходную задачу. Вместе с ним сохраняют скрытый эталонный ответ и исполняемый сценарий, подтверждающий, что вопрос корректен до и после патча и не раскрывает решение.
Из нескольких вариантов последовательности выбирают тот, который ближе к целевому потоку. Для этого TFAS сравнивает распределение длин, типов сообщений и переходов между ними. В пилоте на 700 задачах SWE-Bench Pro добавление вопросов и подбор их позиции подняли TFAS с 59,6 до 77,8.
Такой бенчмарк даёт больше сигналов, чем итоговое «решено или нет». Тесты можно запускать после каждой раскрытой части требований, а ответы на вопросы — сопоставлять с эталоном. Это помогает различить агента, который понял проект и последовательно выполнил запросы, и агента, который случайно пришёл к проходящему тесты патчу.
Для IDE-агента придётся пересмотреть оценку и бюджет
Если продукт получает полностью сформулированную задачу и автономно готовит патч, итоговые тесты остаются подходящей основной проверкой. Работа не показывает, что многошаговый протокол лучше ранжирует модели: доля решённых задач менялась нестабильно и оставалась сопоставимой с разбросом между запусками.
Для интерактивного агента вывод практичнее. Команде стоит собрать обезличенную статистику собственных сеансов, выделить типы запросов и переходы между ними, а затем воспроизвести эту смесь в отдельном наборе проверок. Чужой корпус может описывать другой продукт и давать неверные веса планированию, объяснению кода или проверке изменений.
Меняется и расчёт затрат. Последовательное раскрытие требований примерно удвоило стоимость работы агента, хотя конечный результат не стал стабильно лучше или хуже. Оценка по одному длинному запросу поэтому может занижать бюджет эксплуатации продукта, где пользователь регулярно уточняет задачу.
Границы пилота достаточно узкие: авторы использовали один набор задач, четыре модели с общей оболочкой mini-swe-agent и поток из JetBrains IDEs. Все сообщения готовили заранее, поэтому проверка измеряет память и адаптацию к постепенно раскрытым требованиям, но не реакцию пользователя на действия агента. Классификаторы согласились по 76,1% меток, при этом отдельного набора с человеческой разметкой для проверки точности не было.
SWE-TaskFlow поэтому полезнее воспринимать не как универсальный новый рейтинг, а как схему сборки собственного бенчмарка. Она позволяет оставить проверенные репозитории и тесты, но добавить тот порядок взаимодействий, от которого в реальном продукте зависят затраты и качество работы агента.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
