Как мы автоматизировали переход Браузера на новые версии Chromium

Каждые четыре недели Браузер переезжает на новую версию Chromium. Для пользователя это почти незаметно, но для команды разработчиков обновления стабильно превращаются в испытание. Каждый переход — человеко-месяцы работы, тысячи коммитов апстрима, конфликтов кода и ошибок компиляции. Простой авторезолв справляется только с тривиальными случаями.

Всё это — очень трудозатратная рутина, поэтому мы решили её автоматизировать. В этом посте расскажем, как мы использовали LLM-агента, чтобы разрешать конфликты и чинить компиляции. Разберёмся по порядку

Шаг 1. Учим модель разруливать конфликты кода

Первый подход был прямолинейным: скормить LLM целый файл и попросить «починить конфликты». Это не сработало, потому что контекст слишком велик: в Chromium есть файлы на 20 тысяч строк C++. Модели не хватает сил всё запомнить, и качество ответов падает.

Мы перешли к локальному контексту: небольшие файлы подавали целиком. Для больших находили блоки с конфликтами и добавляли ограниченный контекст до и после, а далее отправляли в LLM с промптом.

Затем мы взяли кейсы, с которыми не справлялась старая авторезолвилка, и превратили их в размеченный набор примеров. Данные разделили на train и бенчмарк. Train разбили на блоки и для каждого просили LLM вывести «не более 10 общих правил решения конфликтов» на основе человеческих резолвов. Результат прогнали через суммаризацию, а в финальный промпт добавили «пролог и эпилог» из «банка памяти» по браузеру.

Если решение LLM совпадало с тем, что дала бы старая авторезолвилка, код вливали сразу. В 98% таких случаев дополнительные правки не требовались. Для остальных оставили одного ревьюера вместо двух.

Как мы оценивали качество

Точное совпадение с человеческим резолвом (byte-to-byte). На бенчмарке 63% решений полностью совпали с тем, как конфликт решал разработчик

«Смысловая» проверка через LLM-as-a-Judge. Для каждого конфликта описали аспекты корректного решения (убраны маркеры, сохранены локальные правки, учтены изменения апстрима). По этой метрике получился 81% успешных решений

Шаг 2. Учим модель чинить компиляции

Чтобы пофиксить ошибку, нужно найти релевантное изменение в Chromium, понять, что именно поменялось, и учесть локальный контекст.

Мы разобрали и сгруппировали ошибки прошлых мерджей. Оказалось, что 10 крупнейших кластеров покрывают около 99% проблем. Это позволило перейти к типологии.

В основе агента — поиск нужного изменения в апстриме. Мы добились, чтобы по тексту ошибки он стабильно находил релевантные коммиты. Показатель HitRate вырос с 32% до 57%. Для половины кейсов также потребовался поиск по локальному репозиторию для учёта контекста.

Чтобы сократить число итераций, ввели двухуровневую схему: быстрые попытки для типовых случаев и сложный флоу — для остальных. Это снизило среднее количество шагов с 60 до 20. Генерацию кода изолировали от поиска: утверждённый план разбили на атомарные задачи и отправили в ноду на базе Aider. Теперь можно чинить ошибки параллельно.

Итоги в цифрах

Конфликты считали через FTE — сколько полной занятости удалось высвободить за цикл мерджа. Получилось примерно 50%. Это заметная экономия усилий команды.

С починкой компиляции метрики другие. На ранних версиях инструмент исправлял 50–60% ошибок из датасета прошлых мерджей. После того как мы добавили агентский поиск и планирование, доля выросла примерно до 80%. В реальной работе инструмент автоматически исправляет около 70% переданных ему ошибок. При этом он экономит примерно 32% времени на починке.

А в полной статье на Хабре рассказываем:

Почему ошибки компиляции становятся основной нагрузкой
Что происходит при мердже Chromium
Какой урок мы усвоили из этой истории и где LLM действительно помогает

Подписывайтесь:
@Yandex4ML
@YandexML