«Анатомия багфиксера»: агент Serge за 80 ночей влил 29 исправлений в Transformers

Что такое Serge и где проходят границы его полномочий

Serge — это CI-агент Hugging Face, который каждую ночь ищет реальные падения тестов в Transformers, воспроизводит их на GPU, разбирается в причине, пишет патч, проверяет его и открывает pull request для ревью мейнтейнеров. Ставка сделана на работу, которую легко проверить: повторяющуюся, медленно оркестрируемую и почти всегда не требующую сложного кода — сами исправления часто простые, а дорого обходится цикл вокруг них, где мейнтейнер снова и снова возвращается к одной и той же задаче.

Каждая задача выполняется в собственном короткоживущем Kubernetes-поде: у пода нет ни GitHub-креденшелов, ни токена API кластера, а сетевой доступ ограничен GitHub, инференс-роутером Hugging Face и индексом истории Serge. Агент может пушить только ветки под префиксом serge/ и открывать pull request — ничего не попадает в main без ревью и мейнтейнера.

За 80 дней 29 его исправлений доехали до Transformers.

Цикл из шести шагов

Путь от падения до патча разбит на шесть шагов, и Serge останавливается как можно раньше, если что-то выглядит не так: отбор падений, воспроизведение, проверка того, не занимается ли проблемой кто-то ещё, генерация патча с проверками качества, верификация фикса и открытие pull request.

В CI гоняется почти 200 тысяч тестов, и какая-то доля флейков неизбежна, поэтому Serge смотрит на несколько дней назад и берёт тесты, которые стабильно падают всю неделю. Затем свежий GPU-раннер несколько раз выполняет тест: если падение не воспроизводится надёжно, задача закрывается — просить LLM чинить ненаблюдаемое падение бессмысленно.

На третьем шаге агент проверяет, не исправляет ли проблему кто-то другой: контекст из прежних issue, pull request, комментариев ревью, истории git и обсуждений мейнтейнеров даёт система relore. В случае с регрессией GPTNeoXJapanese Serge уже собирался писать фикс, но relore нашёл открытый одобренный pull request по той же проблеме, и агент остановился вместо создания дубля.

На четвёртом шаге подключается LLM: она получает локальный чекаут и итеративно правит патч в многоходовом цикле, пользуясь теми же инструментами, что и разработчик — ruff, ty и transformers-mlinter. Пятый шаг — верификация: целевой тест прогоняется пять раз на непатченном дереве и пять раз на патченном, что подтверждает и реальность падения, и стабильность фикса. Отдельный риск — оптимизация под задачу вместо решения проблемы: если патч меняет только ожидаемые значения, к нему относятся с подозрением, и такие патчи Hugging Face отклоняла.

Инфраструктурные сбои — неожиданный выход раннера, неприменённый патч, таймаут GPU-верификации — не считаются доказательством ни в пользу патча, ни против него: pull request не открывается, группа помечается как failed в трекинг-issue и повторяется следующей ночью, а ветку при таймауте GPU сохраняют без PR, чтобы её мог посмотреть человек.

На шестом шаге, если патч прошёл все предыдущие, открывается pull request и пингуются мейнтейнеры, а для каждого ночного прогона создаётся трекинг-issue: так, прогон 23 сентября собрал все отправленные группы падений и связал успешные с их pull request в issue #49034.

Пример: PVT v2

Интеграционный тест PvtV2ModelIntegrationTest::test_inference_model падал во всех семи ночных прогонах своего окна с одной и той же ошибкой на форме тензора. Причина оказалась в самом тесте: ожидаемая форма (1, 50, 512) была скопирована из теста PVT v1, тогда как PVT v2 — иерархический трансформер, возвращающий 4D-карты признаков, и для pvt_v2_b0 верна форма (1, 256, 7, 7).

Serge воспроизвёл падение на GPU; на разбор причины у модели ушло 36 ходов и 56 секунд LLM-времени, а сквозное время составило около 28 минут. Агент исправил форму, обновил индекс среза и добавил корректные ожидаемые значения, после чего прогнал тест пять раз на каждом дереве, открыл pull request, и тот влили без изменений.

Экономика: воронка отбора и цена патча

За две недели Serge отправил в работу 117 групп падений. Двадцать девять из них вообще не дошли до LLM: на базовом коммите тест уже проходил — иногда потому, что проблему успели починить в это же время; ещё две группы упали на первом запросе к инференс-эндпоинту; осталось 86 сессий с реальной работой LLM.

Из этих 86 сессий 24 дали подтверждённое событие pull request, что соответствует 19 отдельным PR; 28 закончились без безопасного патча, 18 — патчем, не прошедшим GPU-верификацию, 5 — таймаутом на верификации, 11 — ошибками на середине сессии вроде неприменённого патча, сбоя раннера или ошибки разбора вывода.

Модель — Kimi K-2.7-Code: большинство сессий стоит чуть меньше $2, а редкие длинные прогоны сдвигают среднее ближе к $3; на 86 сессий за две недели ушло около $250. В пересчёте это примерно $14 за отдельный pull request и $43 за влитый. Hugging Face называет это дешёвым на фоне оценки ручной работы: один-два часа внимания разработчика на фикс, то есть около 43 часов на 29 влитых исправлений. Следующая точка оптимизации — сама модель: Qwen3.8-27B меньше и дешевле вдвое и выше по бенчмарку DeepSWE 1.1 (42,2 против 31).

Что показали 80 дней

Первые недели были слабыми: пришлось переделывать промпты и построить relore, потому что агенту не хватало контекста об истории репозитория, чтобы принимать хорошие решения. Сегодня 29 влитых фиксов за примерно 80 дней — это около 2,5 в неделю.

Только часть отправленных падений доходит до LLM, и лишь часть из них становится pull request — это осознанный дизайн: конвейер отбрасывает слабых и непроверяемых кандидатов рано, вместо того чтобы максимизировать число патчей. Главный вывод Hugging Face: место такого агента не в замене мейнтейнеров, а в автоматизации повторяемой и проверяемой работы с эскалацией к человеку, когда нужен ревью; экономить нужно внимание мейнтейнера.

Serge остаётся экспериментом, и в Hugging Face перечисляют, что ещё предстоит улучшить: в частности, пока нет надёжного автоматического способа отличить законное обновление ожидаемых значений от reward hacking, поэтому такие патчи отклоняют вручную.