TL;DR
RETRACE — способ превратить историю старых pull request'ов (PR, запрос на слияние кода) в аккуратные записи «одна проблема → какие правки её решили». Модель смотрит на PR с двух сторон. Сначала от финального диффа назад: какие из оставшихся правок связаны с упавшими проверками. Потом по коммитам вперёд: когда правки появились, менялись или откатывались. Оба взгляда сверяются по логам CI, и в запись попадает только то, что подтверждается доказательствами. Запись хранится на трёх уровнях: конкретная правка, стратегия для похожего проекта, общий паттерн.
Главная находка: если дать агенту старый PR целиком, пользы мало. В PR перемешаны несколько проблем, неудачные попытки, откаты и посторонние правки. Агент получает много контекста и не понимает, какая правка лечит какую проблему. Поэтому «история целиком» (а также прямое повторение прошлого плана починки) работает слабо. Если же разобрать историю по проблемам, доля задач, решённых с первой попытки, растёт с ~20% до ~32%. Это рост примерно в полтора раза.
Суть метода в четыре шага. Упорядочить логи CI. Выделить кандидатов на «проблема → правка» двумя взглядами, от финала и от истории. Сверить их и выбросить всё без доказательств. Записать каждую проблему на трёх уровнях абстракции. Для новой аварии метод отдельно подбирает опыт под каждую проблему, а не под весь сбой сразу.
Схема метода
ПОДГОТОВКА (по каждому старому PR)
ШАГ 0: Разобрать логи CI → список ошибок, статус проверок (✓ / ✕ / не дошли), зависимости шагов
ШАГ 1: Взгляд от финала (endpoint) → финальный дифф разбит на группы,
для каждой: «какую ошибку лечит?» Нет связи с логами — выбросить
ШАГ 2: Взгляд по истории (development) → коммиты по порядку,
для каждого: «какие ошибки закрывает?» Откаты и посторонние правки — отдельно
ШАГ 3: Сверка → пары записей: equivalent / complementary / conflicting / distinct
Поле без доказательства из истории — удалить
ШАГ 4: Три уровня записи → L1 конкретика → L2 стратегия → L3 общий паттерн
ПРИМЕНЕНИЕ (новая авария CI)
ШАГ 5: Разбить сбой на атомарные проблемы (в т.ч. скрытые за ранними падениями)
ШАГ 6: Для каждой проблемы отдельно подобрать записи L1, L2, L3
и отфильтровать по совпадению механизма сбоя
ШАГ 7: Добавить зависимые проблемы («починишь A — вылезет B») и повторяющиеся для этого репозитория
ШАГ 8: Упорядочить, чинить по одной, в конце прогнать весь CI целиком
Шаги 0–4 можно сделать в одном длинном промпте или в нескольких запросах подряд. Шаги 5–8 — отдельная работа агента.
Пример применения
Задача: команда интернет-магазина на Python держит CI в GitLab. Разработчик месяц назад чинил красный пайплайн в PR «Обновление зависимостей». В PR 9 коммитов, правки перемешаны. Сейчас пайплайн упал снова, и хочется превратить старый PR в урок, который не утонет в шуме.
Промпт:
Ты разбираешь историю починки CI. Твоя задача — для каждой проблемы
найти правки, которые её решили, и отбросить всё остальное.
Шаг setup: ERROR: No matching distribution found for httpx==0.19.0
Шаги unit-tests и integration-tests: не запускались
Падение при повторном прогоне: AttributeError: 'Session' object has no attribute 'get_async'
c1: requirements.txt: httpx 0.18.2 → 0.25.0
c2: api_client.py: Session() → Client()
c3: api_client.py: попробовал AsyncClient()
c4: api_client.py: откатил AsyncClient(), вернул Client()
c5: utils.py: переименовал хелпер format_price → fmt_price
requirements.txt: httpx 0.18.2 → 0.25.0
api_client.py: Session() → Client()
utils.py: format_price → fmt_price
1. Организуй логи: ошибки, статус каждой проверки (прошла / упала / не дошла), зависимости между шагами. Отметь, какие проблемы могли скрываться за ранними падениями.
2. ВЗГЛЯД ОТ ФИНАЛА: разбей финальный дифф на группы связанных правок. Для каждой группы скажи, какую ошибку из логов она лечит. Если связи в логах нет — пометь «не связано».
3. ВЗГЛЯД ПО ИСТОРИИ: пройди по коммитам по порядку. Для каждого скажи, какие ошибки он закрывает. Откаченные и посторонние правки пометь отдельно и не включай в итоговую починку.
4. СВЕРКА: сравни записи двух взглядов. Для каждой пары укажи: equivalent / complementary / conflicting / distinct. Equivalent объедини, complementary склей, conflicting проверь по логам, коммитам и финальному диффу.
5. Для каждого поля записи назови доказательство из входных данных. Нет доказательства — удали поле.
По каждой проблеме:
- Проблема и вероятная причина
- Какие правки её решили (файлы, символы)
- Доказательство (строка лога, коммит)
- Зависимость: какая проблема стала видна только после этой
Затем три уровня:
L1 — конкретная запись только по этой проблеме
L2 — стратегия: замени имена файлов и функций на роли; укажи признаки сбоя, шаги починки, как проверить, ловушки
L3 — общий паттерн без привязки к репозиторию: механизм сбоя, признаки, принципы починки, условия применимости, какие проблемы обычно вылезают следом
Результат: модель выдаст отдельные записи по двум проблемам: версия пакета и смена API клиента. Переименование хелпера будет помечено как не связанное с CI. Попытка с AsyncClient будет в истории как откаченная и не попадёт в итоговую починку. Для каждой записи будут указаны доказательства. Дальше пойдут три слоя (L1, L2, L3). В L3 видна связь «обновление версии открыло поломку API». Её можно сохранить в файл с playbook'ом команды.
Почему это работает
Слабость. PR — это «сырой» результат работы человека. В нём правки по разным проблемам, пробы, откаты и посторонний рефакторинг. Итоговый дифф показывает только сумму изменений, а зелёный CI — что PR прошёл целиком. Если отдать такой PR агенту как пример, он не видит, какая правка лечит какую проблему. Старый план целиком тоже плохо переносится на новый сбой, потому что в нём та же каша.
Сильная сторона. LLM хорошо отвечает на узкие вопросы по небольшому куску: «эта группа правок связана с этой ошибкой?», «эти две записи об одном и том же?». Также она хорошо переписывает конкретику в более общий вид.
Как метод использует это. Большая запутанная задача превращается в много маленьких проверок. У двух взглядов разные слепые пятна. Финальный дифф не знает про откаты, история не знает, что в итоге осталось. Сверка по логам CI и требование доказательства для каждого поля отсекают выдумки. Три уровня абстракции нужны, потому что конкретная правка плохо переносится в другой проект, а общий паттерн теряет детали. Выбор уровня остаётся за задачей.
Рычаги управления: - Убери один из взглядов — получишь версию для случая, когда нет истории коммитов (после squash остаётся только взгляд от финала). Авторы показали: оба взгляда вместе лучше любого одного. - Требование «доказательство для каждого поля» — самый важный рычаг против выдумок. Не ослабляй. - Уровни L1/L2/L3 — для того же проекта бери L1 и L2, для другого — L3. - Разбивка по проблемам — подбирай опыт отдельно под каждую проблему, а не под весь сбой.
Шаблон промпта
Ты разбираешь историю починки {тип_системы}. Твоя задача — для каждой проблемы найти
изменения, которые её решили, и отбросить всё остальное.
{логи_ошибок_и_статусы_проверок}
{список_коммитов_по_порядку}
{финальный_дифф}
1. Организуй логи: ошибки, статус каждой проверки (прошла / упала / не дошла), зависимости между шагами. Отметь проблемы, которые могли скрываться за ранними падениями.
2. ВЗГЛЯД ОТ ФИНАЛА: разбей финальный дифф на группы связанных правок. Для каждой — какую ошибку из логов она лечит. Нет связи — «не связано».
3. ВЗГЛЯД ПО ИСТОРИИ: пройди по коммитам по порядку. Для каждого — какие ошибки он закрывает. Откаты и посторонние правки — отдельно, в итог не включай.
4. СВЕРКА: для каждой пары записей двух взглядов укажи equivalent / complementary / conflicting / distinct.
- equivalent → объедини
- complementary → склей
- distinct → оставь раздельно
- conflicting → проверь по логам, коммитам и финальному диффу
5. Для каждого поля записи укажи доказательство из входных данных. Нет доказательства — удали поле.
Для каждой проблемы:
- Проблема и вероятная причина
- Какие правки её решили
- Доказательство
- Зависимости (что обнаружилось только после этого исправления)
L1: конкретная запись только по этой проблеме
L2: стратегия — имена файлов и функций заменены ролями; признаки сбоя, шаги починки, проверка, ловушки
L3: общий паттерн — механизм сбоя, признаки, принципы починки, условия применимости, типичные проблемы-«хвосты»
Правило: L2 и L3 не добавляют новых фактов, которых нет в L1.
Что подставлять:
- {тип_системы} — CI, сборка, миграции, деплой.
- {логи_ошибок_и_статусы_проверок} — выжимка из логов с пометкой, какие шаги не запускались.
- {список_коммитов_по_порядку} — сообщения и краткое описание правок (git log -p, если влезает).
- {финальный_дифф} — суммарный дифф между сломанной и зелёной версией.
🚀 Быстрый старт — вставь в чат:
Вот шаблон RETRACE. Адаптируй под мою задачу: {опиши свою систему и что нужно разобрать}.
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит, какие логи, коммиты и дифф у тебя есть, есть ли история коммитов или только итоговый дифф, какие проверки не дошли до запуска. Эти данные нужны: метод держится на сверке двух взглядов по логам, и без них доказательства для записей брать неоткуда.
Ограничения
⚠️ Нужна история: без промежуточных коммитов остаётся один взгляд, от финального диффа. Авторы показали, что оба взгляда вместе лучше. Один взгляд даёт результат слабее.
⚠️ Полный метод требует инженерии: автоматический подбор по базе записей (поиск по похожести, фильтр, порядок проблем, последовательная починка в одном репозитории) — это код. В обычном чате воспроизводится только этап превращения одного PR в записи. Подбор записей под новую аварию придётся делать руками или собирать автоматизацию.
⚠️ Абсолютный результат скромный: лучший результат — около трети задач, решённых с первой попытки. Метод заметно помогает, но не заменяет разработчика.
⚠️ Узкая область: метод показан на починке CI в репозиториях. На других задачах, где опыт «запутан», идея может работать, но исследование этого не проверяло.
⚠️ Нет готовых промптов: в доступном тексте нет дословных промптов авторов (они, видимо, в приложении). Шаблон выше собран по описанию метода.
⚠️ Цена: много вызовов модели на каждый старый PR и на каждую новую аварию. Для редких сбоев и небольшой истории может не окупиться.
⚠️ Проверка авторов: бенчмарк создан теми же авторами. Независимых проверок в тексте нет.
Как исследовали
Команда взяла собственный набор CI-Repair-Bench: 565 починок PR из 101 репозитория, 12 категорий сбоев. Задачи тяжёлые: в среднем 10 файлов и 240 строк правок, в разы больше, чем в SWE-bench. В 84% случаев в одном PR несколько разных проблем. Именно поэтому «просто дать PR как пример» не работает.
Сравнивали три варианта: без опыта, повторение старого плана починки (Historical-Plan) и RETRACE. Проверяли двух агентов и разные модели. С mini-SWE-agent и MiniMax-M2.5 доля решённых с первой попытки выросла с 19,6% до 31,9%, с DeepSeek-V4-Flash — с 23,3% до 32,8%. Codex на подмножестве вырос с 15,5% до 27,5%. Успех засчитывался, только если проходил весь CI целиком.
Удивительный момент: повторение старого плана дало результат не лучше, а местами хуже варианта без опыта — RETRACE обошёл его на 13,5 пункта (против 12,3 пункта над «без опыта»). Нерасчленённая история не просто бесполезна, она путает. Абляции показали, что объединение двух взглядов лучше любого одного во всех настройках. Практический вывод: качество опыта важнее его объёма.
Адаптации и экстраполяции
🔧 Техника: добавить «ловушки» → меньше повторных ошибок
В уровень L2 добавляй пункт «что пробовали и откатили, и почему не сработало»:
L2 дополнительно: раздел «Ловушки» — попытки из истории коммитов, которые были откачены,
и причина (из логов или сообщений коммитов). Если причины в данных нет — пиши «причина неизвестна».
Откаты — самое ценное, что теряется в итоговом диффе. Но это моё дополнение: авторы упоминают «известные ловушки» (pitfalls) в L2, а отдельный раздел из откатов — уже адаптация.
Экстраполяция: L3-паттерны в файл инструкций агента
Если накопил несколько L3-паттернов, положи их в CLAUDE.md / AGENTS.md:
## Известные паттерны поломок CI (из истории PR)
При падении CI сначала разбей сбой на отдельные проблемы и пойми, какие проверки не запускались.
Затем сверься с паттернами ниже. Применяй паттерн, только если совпадают механизм сбоя
и условия применимости.
### Паттерн: обновление версии зависимости открывает несовместимость API
- Признаки: ошибка установки пакета в setup; после правки версии — AttributeError / ImportError в тестах
- Починка: обнови версию, затем найди вызовы изменённого API и исправь их
- Условие применимости: пакет менял мажорную/минорную версию
- Типичный «хвост»: падение интеграционных тестов, которые раньше не запускались
Авторы такой формат не проверяли (у них опыт подбирается автоматически и отдельно под каждую проблему). Идею «чинить по одной проблеме в порядке зависимостей и после всего прогнать полный CI» можно записать и прямо в инструкцию агенту.
Ресурсы
- Название работы: RETRACE: From Entangled Repair Histories to Reusable Experience for CI Repair
- Авторы: Rabeya Khatun Muna, Md Ahasanuzzaman, Md Nakhla Rafi, Yisen Xu, Jinqiu Yang, Tse-Hsun (Peter) Chen
- Организации: SPEAR Lab (Software Performance, Analysis, and Reliability), Concordia University
- Бенчмарк: CI-Repair-Bench (Muna et al., 2026) — 565 починок, 101 репозиторий, 12 категорий сбоев
- Агенты и модели: mini-SWE-agent, Codex, MiniMax-M2.5, DeepSeek-V4-Flash