Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Агент для программирования стал реже бросать работу на последнем шаге: он точнее соблюдал требования, сохранял прежнее поведение и лучше проверял собственные решения. Surge AI получила улучшение на каждом внешнем наборе задач, хотя работа не прошла рецензирование и все замеры выполнили сами авторы. Результат показывает, что обучение может переносить не знание конкретного набора задач, а привычку проверять работу до сдачи.
Награда учитывала и новые функции, и поломки старых
Kimi K2.7 Code дообучили с подкреплением на 1700 агентных задачах двух типов. В первом типе модель меняла настоящие репозитории, во втором — выполняла задания в среде с командной строкой. Проверки оставались скрытыми, а эталонного решения агент не видел.
Модель содержит триллион параметров, из которых для каждого токена работают 32 миллиарда. Авторы не обновляли её целиком, а добавили адаптер LoRA и провели один проход по обучающим задачам. Алгоритм GSPO сравнивал несколько вариантов решения одной задачи и повышал вероятность тех траекторий, которые получили больше награды.
Ключевую роль играло устройство этой награды. Агент получал частичный балл за каждое выполненное требование, поэтому даже незавершённые решения можно было сравнивать между собой. Но если изменение ломало хотя бы одну проверку прежнего поведения, вся награда обнулялась.
Такая схема одновременно давала четыре сигнала. Нужно было удержать все пункты спецификации, проверить случаи за пределами собственной реализации, не сломать работающий код и самостоятельно построить надёжную проверку результата. Обучение не поощряло короткий путь, при котором новая функция проходит часть тестов ценой регрессии.
Частичный балл особенно полезен на сложных задачах. При простой награде «решено или нет» все неудачные попытки выглядят одинаково, даже если одна почти готова, а другая не работает вовсе. Здесь агент мог получить преимущество за дополнительное выполненное требование, пока сохранял старое поведение.
Перенеслись инженерные привычки, а не формат теста
Доля задач, решённых с первой попытки, выросла на SWE-Bench Pro на 4,7 процентного пункта, на DeepSWE — на 12,4, а на SWE-Marathon — на 20. Улучшение сохранилось при смене агентной оболочки — набора инструментов, подсказок и управляющего цикла, через который модель работает с кодом. На двух наборах медианная траектория также стала короче примерно на четверть или треть.
До обучения многие ошибки уже были близки к успешному решению. В проваленных запусках DeepSWE базовая модель в медиане проходила 86% проверок требуемого поведения. Ей чаще не недоставало знания языка или библиотеки: она теряла один пункт спецификации, писала слишком узкие тесты, допускала регрессию либо подтверждала решение проверкой, основанной на том же неверном предположении.
Один разобранный пример касался интерфейса промежуточного обработчика FastAPI. Базовая модель реализовала почти всю функцию, но разместила два требуемых метода на уровне модуля, а не в объекте обработчика. Обученная версия сохранила эти методы там, где обещала спецификация.
В другой задаче базовая модель проверяла только форму функции, которую уже поддерживал её код, и пропустила альтернативную форму из требования. После обучения агент выводил положительные, отрицательные и граничные случаи из спецификации, а не из собственной реализации. В задачах без готового эталона он создавал независимую опору: аналитическое решение, эмулятор или генератор тестовых данных.
Перенос проверяли на Kimi K2.7 Code в семействах SWE-Bench, DeepSWE, Terminal-Bench и SWE-Marathon. Они включали изменения в репозиториях, работу через командную строку и многочасовую сборку целых систем; часть наборов и две агентные оболочки не использовались при обучении. При этом речь идёт об одной модели и лабораторных задачах, а разбор поведения охватывает выбранные авторами примеры, которые обученная версия решила впервые.
Командам стоит менять проверку задач, а не сразу модель
Работа не даёт основания заменить текущую модель только ради этого метода. Она показывает более практичное направление: качество обучающего сигнала может зависеть не от объёма однотипных задач, а от того, насколько точно каждая задача раскладывается на проверяемые требования.
Для собственной системы кодовых агентов из этого следуют три изменения. Спецификацию стоит превращать в отдельные проверяемые условия, прежнее поведение защищать обязательным набором регрессионных тестов, а новые функции оценивать частично, не смешивая их с поломками старых. Если агент не получает эталон, среда должна позволять ему написать независимую проверку, эмулятор или генератор примеров.
Особенно заметен жёсткий запрет на обмен нового поведения на старое. Обычная доля пройденных тестов позволяет агенту выиграть, добавив функцию и одновременно сломав редкий сценарий. Обнуление награды при регрессии убирает такой путь и учит сначала фиксировать, что должно остаться неизменным.
Этот подход не обещает того же прироста на меньшей модели или в производственном репозитории с неполными тестами. Но он меняет приоритет эксперимента: прежде чем собирать больше задач или менять базовую LLM, имеет смысл проверить, различает ли награда почти готовое решение, полное выполнение спецификации и реализацию с регрессией.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
