Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Исследователи из The University of Texas at Austin и Cisco Research разработали CROCODIL для уменьшения лишних изменений при редактировании кода, созданного другой LLM; работа опубликована как препринт, не проходивший рецензирования. По замерам авторов, обученная версия Olmo3 7B сокращала размер правок примерно вдвое. Результат важен командам, где разработчики используют несколько ассистентов или меняют модель между этапами работы над кодом.
Что сделали
Авторы разделили работу моделей на две роли. Модель-исполнитель заново пишет существующую функцию по её сигнатуре, описанию проекта, вызываемым функциям и другим фрагментам контекста. Затем модель-редактор получает реализацию и должна внести изменение из реального запроса на слияние GitHub.
Если исполнитель и редактор совпадают, авторы называют это редактированием собственного кода. Если функцию создала одна модель, а меняет другая, это перекрёстное редактирование. Такая схема позволяет отделить сложность задачи от реакции редактора на чужой стиль: одно изменение применяется к реализациям нескольких моделей.
Размер правки измеряли посимвольным расстоянием Левенштейна — количеством вставок, удалений и замен между исходной и изменённой функциями. Перед расчётом код форматировали с помощью rustfmt, удаляли комментарии и пустые строки, чтобы не считать чисто оформительские различия.
CROCODIL дообучает редактор с двумя связанными сигналами награды. Награда за сходство штрафует большие отклонения от входного кода, а награда за выполнение учитывает сборку и прохождение тестов. Их произведение должно не просто сделать патч короче, а сохранить требуемое поведение. Для оптимизации авторы применили обучение с подкреплением GRPO и обучали только Olmo3 7B.
Что показали
У открытых моделей собственные реализации получали меньшие изменения в 14 из 16 сравнений с чужими реализациями. Разница доходила до 14%. Это указывает не только на общую склонность модели переписывать код, но и на дополнительную реакцию на стиль другого генератора. Haiku 4.5 такого устойчивого поведения не показала.
После обучения с CROCODIL редактор делал меньшие изменения в коде каждого из использованных исполнителей. Эффект сохранялся и на задачах, где одновременно проходили все тесты у базовой и обученной моделей: уменьшение нельзя объяснить только тем, что новая версия чаще проваливала сложные правки.
Доля успешно собирающихся и проходящих все тесты изменений выросла для реализаций всех исполнителей, кроме самой Olmo3 7B. При этом в 19,94% случаев обученная модель не меняла функцию вообще. Авторы отдельно исключили такие ответы: преимущество по сборке сохранилось на том же наборе исполнителей, поэтому результат не сводится к отказу от редактирования.
Более строгая инструкция в системном запросе — требование сделать минимально возможное изменение — не уменьшала патчи и не повышала успешность стабильно. По замерам авторов, одного уточнения запроса оказалось недостаточно, чтобы воспроизвести эффект дообучения.
Ограничения
Корпус состоит только из проектов на Rust с GitHub. После тестирования и фильтрации у разных моделей-исполнителей осталось от 79 до 603 задач редактирования. Работа рассматривает изменения отдельных функций, а не патчи, затрагивающие несколько функций, файлов, конфигурацию сборки или миграции данных.
В исследовании участвовали пять LLM, причём закрытой была только Haiku 4.5. CROCODIL проверяли на одной сравнительно небольшой модели — Olmo3 7B. Работа не показывает, сохранится ли эффект на GPT-5, Claude Opus, других языках программирования и более крупных изменениях репозитория.
Авторы сравнили обученную модель с базовой версией и вариантом со строгой инструкцией, но не проверили другие методы дообучения для ограничения размера патча. Тесты и сборка оценивают функциональную корректность в пределах собранных сценариев, однако исследование не измеряет время ревью, число дефектов после слияния и стоимость эксплуатации такого контура.
Что это значит
Работа не даёт оснований менять основной стек моделей только ради меньших различий в патчах. Результат получен на одном языке, на уровне функций и после дообучения одной открытой модели. Для команд, использующих закрытые API без доступа к весам и обучению, CROCODIL пока скорее задаёт способ оценки, чем готовую технику внедрения.
Планы стоит скорректировать там, где несколько LLM последовательно работают с одной кодовой базой: например, одна генерирует функцию, другая исправляет тесты, а третья проводит рефакторинг. Обычный бенчмарк редактора может не выявить лишние изменения, если весь исходный код написан людьми или той же моделью. В испытания следует добавить матрицу «исполнитель — редактор», измерять размер патча после форматирования и отдельно проверять сборку и тесты.
Для собственных моделей работа предлагает практичную конструкцию целевой функции: минимальность изменения не должна оцениваться отдельно от выполнения задачи. Однако штраф за размер патча требует настройки. В качественном анализе авторы нашли случаи, когда обученная модель не распространяла переименование идентификатора по функции. Поэтому контроль должен учитывать не только лишние строки, но и недостающие обязательные изменения.
Источники
Иллюстрация: рисунок из статьи «CROCODIL: Cross-Model Code Editing with LLMs», Linghan Zhong, Aditya Thimmaiah, Jayanth Srinivasa и др., CC BY 4.0
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
