Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Модель-оценщик кода научились автоматически подстраивать по исходам разработки: прошёл ли набор изменений тесты, приняли его или закрыли. В препринте Meta, который ещё не прошёл рецензирование и приводит замеры самих авторов, AutoRefine поднял согласие с исходами на независимой проверке с 0,16 до 0,51. Команды могут обновлять контроль качества вслед за агентом, не размечая каждый пример вручную.
Как исход разработки превращается в инструкцию оценщика
Оценщик получает заголовок, описание, изменения кода и дополнительные материалы вроде плана тестирования. Его задача — пропустить или отклонить изменение. Метка приходит из процесса разработки: тесты прошли или упали, изменение влили или от него отказались.
Такая разметка почти ничего не стоит, но смешивает качество кода с обстоятельствами процесса. Изменение могут закрыть из-за скрытого теста, дубликата, смены приоритетов или сломанной сборки. Если оценщик этого не видит, он не сможет вывести правильное правило из кода.
AutoRefine сначала передаёт пример модели-учителю. Она видит те же материалы, что и будущий оценщик, а также итоговую метку. Учитель либо объясняет исход фактами из доступного кода, либо воздерживается от решения и исключает пример из калибровки. Явно ошибочную метку он также может исправить, но в экспериментах это происходило редко.
После фильтрации оценщик запускается на обучающей части данных. Другая модель разбирает расхождения между его ответами и сохранёнными метками, а затем переписывает инструкцию. Каждое новое основание для отказа дополняется условием, при котором изменение следует принять: это мешает оценщику улучшать формальную точность простым отклонением всего подряд.
AutoRefine меняет только инструкцию, а не веса модели. Отдельная проверочная часть выбирает лучший вариант и останавливает цикл. Патчи агента при этом записывают один раз и повторно предъявляют оценщику, поэтому самого агента не приходится перезапускать на каждой итерации.
Фильтрация меток помогает, пока причина видна в коде
На изменениях с надёжным результатом выполнения AutoRefine поднял Scott’s π с 0,36 до 0,60. Этот показатель измеряет согласие оценщика с метками и вычитает совпадения, которые можно получить случайно из-за соотношения принятых и отклонённых примеров. Одна лишь настройка порога такого результата не дала.
В отдельной проверке исследователи случайно исказили 25 % исходов. Учитель чаще отбрасывал подменённые отказы, чем настоящие, и снизил долю ошибочных меток до 20 %. Значит, фильтр действительно удаляет часть шума, а не просто уменьшает обучающий набор.
Эффект на текущем процессе сохранился в независимой выборке из 17 наборов изменений. Однако на старых изменениях прежний оценщик оказался лучше обновлённого. Инструкция учится не абстрактному качеству кода, а правилам и распределению конкретного процесса, поэтому после изменения агента, входных данных или порядка проверки её приходится калибровать заново.
Проверки охватывают промышленный монорепозиторий Meta и одного агента для оптимизации производительности. Независимые выборки невелики, каждый цикл калибровки запускали по одному разу, а учитель и оценщик относились к одной модельной семье. Результат показывает рабочий механизм, но не доказывает, что те же пороги и качество сохранятся в другом репозитории или процессе.
Когда менять инструкцию, а когда добавлять входы
Главный практический сигнал AutoRefine — не итоговая точность, а частота отказов учителя. Если исход можно объяснить по патчу и плану тестирования, инструкция оценщика может извлечь из него правило. Если учитель регулярно воздерживается, очередная редакция инструкции не добавит отсутствующий факт.
Это проявилось на ошибках, которые обнаруживали только скрытые тесты. Без эталонного исправления патчи выглядели корректными, поэтому учитель исключал почти все такие отказы. Когда оценщику показывали эталонное изменение, у него появлялись основания увидеть дефект, и калибровка работала лучше.
Для рабочего контура это разделяет две задачи. Если оценщик видит причину решения, команда может автоматически обновлять его инструкцию по накопленным исходам. Если причина остаётся за пределами входа, нужно передать результаты тестов, эталонный патч, комментарий проверяющего или другой источник, который объясняет решение.
Метки слияния и отказа также стоит разделять по этапам. Закрытый черновик часто отражает внутренний отбор, а отказ после проверки кода — решение рецензента. Смешивание этих событий заставляет оценщик предсказывать процесс вместо качества изменения.
AutoRefine не устраняет ручную проверку, но меняет место, где она нужна. Вместо постоянной разметки команда может следить за долей необъяснимых исходов, хранить отдельные выборки для разных версий агента и сначала запускать обновлённого оценщика параллельно с действующим. Рост числа отказов учителя тогда укажет, что оценщику не хватает данных, а падение качества на новой версии процесса — что инструкция устарела.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
