Усиление мутаций генетического улучшения с использованием больших языковых моделей

Обзор контента

• Абстрактный
• Введение
• Экспериментальная установка
• Полученные результаты
• Выводы и будущая работа
• Рекомендации

Абстрактный

Большие языковые модели (LLM) успешно применяются для решения задач разработки программного обеспечения, включая восстановление программ. Однако их применение в методах поиска, таких как генетическое улучшение (GI), до сих пор в значительной степени не исследовано. В этой статье мы оцениваем использование LLM в качестве операторов мутации для GI для улучшения процесса поиска. Мы расширяем набор инструментов Gin Java GI, чтобы вызывать API OpenAI для внесения изменений в инструмент JCodec. Мы случайным образом выбираем пространство изменений, используя 5 различных типов редактирования. Мы обнаружили, что количество патчей, прошедших модульные тесты, на 75 % выше при редактировании на основе LLM, чем при стандартном редактировании вставкой. Далее мы наблюдаем, что патчи, найденные с помощью LLM, как правило, менее разнообразны по сравнению со стандартными правками. Мы запустили GI с локальным поиском, чтобы найти улучшения во время выполнения. Хотя многие улучшающие патчи найдены с помощью GI, улучшенного LLM, лучший улучшающий патч был найден с помощью стандартного GI.

Введение

Поскольку программные системы становятся больше и сложнее, для их обслуживания требуются значительные ручные усилия [2]. Чтобы сократить усилия разработчиков по обслуживанию и оптимизации программного обеспечения, необходимы автоматизированные парадигмы. Генетическое улучшение (GI) [15] применяет методы поиска для улучшения нефункциональных свойств существующего программного обеспечения, таких как время выполнения, а также функциональных свойств, таких как исправление ошибок. Хотя GI добился успеха в промышленности [12,13], он по-прежнему ограничен набором операторов мутации, которые он использует при поиске [14].

Модели больших языков (LLM) имеют широкий спектр приложений, поскольку они способны обрабатывать текстовые запросы без дополнительного обучения для конкретной задачи. LLM прошли предварительное обучение на миллионах репозиториев кода, охватывающих множество различных языков программирования [5]. Их использование для задач разработки программного обеспечения имело большой успех [9,6], а также показало перспективность для восстановления программ [17,19].

Кан и Ю [10] предположили, что существует неиспользованный потенциал использования LLM для улучшения GI. GI использует одни и те же операторы мутации для разных задач оптимизации. Эти операторы создаются вручную до начала поиска и, таким образом, приводят к ограничению пространства поиска. Мы предполагаем, что добавление предложений патчей LLM в качестве дополнительного оператора мутации обогатит пространство поиска и приведет к более успешным вариантам.

В этой статье мы проводим несколько экспериментов, чтобы выяснить, может ли использование LLM в качестве оператора мутации в GI повысить эффективность и результативность поиска. Наши результаты показывают, что патчи, сгенерированные LLM, имеют частоту компиляции 51,32% и 53,54% для случайного и локального поиска соответственно (с категорией подсказки «Средний»). Ранее было показано, что LLM (с использованием модели LLM «как есть») создает код, который компилируется примерно в 40% случаев [16,18]. Мы обнаружили, что случайно выбранные правки на основе LLM компилируются и проходят модульные тесты чаще, чем стандартные правки GI. Мы наблюдаем, что количество патчей, прошедших модульные тесты, для правок на основе LLM на 75 % выше, чем для правок с вставкой GI. Однако мы наблюдаем, что патчи, обнаруженные с помощью LLM, менее разнообразны. Для локального поиска наилучшее улучшение достигается при использовании стандартных правок GI Statement, за которыми следуют правки на основе LLM. Эти результаты демонстрируют потенциал LLM как операторов мутаций и подчеркивают необходимость дальнейших исследований в этой области.

Экспериментальная установка

Чтобы проанализировать использование LLM в качестве оператора мутации в GI, мы использовали модель GPT 3.5 Turbo от OpenAI и набор инструментов GI Gin [3]. Мы экспериментировали с двумя типами поиска, реализованными в Gin: случайный поиск и локальный поиск. Запросы к LLM с использованием OpenAI API осуществлялись через библиотеку Langchain4J, с температурой 0,7. Целевым проектом для улучшения в наших экспериментах был популярный проект JCodec [7], написанный на Java. «Горячие» методы, на которые будут нацелены изменения, были определены с помощью инструмента профилирования Gin путем повторения профилирования 20 раз и объединения полученного набора.

Для экспериментов со случайной выборкой мы настроили прогоны с редактированием на уровне операторов (копировать/удалить/заменить/заменить из [14] и вставить разрыв/продолжить/возврат из [4]) и редактированием LLM, генерируя 1000 запросов каждого типа случайным образом. . Для каждого модульного теста использовался тайм-аут в 10 000 миллисекунд, чтобы отловить бесконечные циклы, возникшие в результате изменений; превышение тайм-аута считается провалом теста. Для локального поиска эксперименты ставились аналогично. Было проведено 10 повторных прогонов (по одному для каждого из 10 самых популярных методов), но прогоны были ограничены 100 оценками, в результате чего в общей сложности получилось 1000 оценок, что соответствует случайному поиску. На практике это составляло 99 правок за один запуск, поскольку первое использовалось для определения времени исходного непропатченного кода.

Мы экспериментировали с тремя разными подсказками для отправки запросов в LLM для обоих типов поиска: простая подсказка, средняя подсказка и подробная подсказка. Со всеми тремя приглашениями наша реализация запрашивает пять различных вариантов имеющегося кода. Простое приглашение запрашивает только код без какой-либо дополнительной информации. Среднее приглашение предоставляет дополнительную информацию о предоставленном коде и требованиях, как показано на рисунке 1. В частности, мы предоставляем LLM используемый язык программирования, проект, к которому принадлежит код, а также инструкции по форматированию. Подробное приглашение дополняет среднее приглашение примером полезного изменения. Этот пример был взят из результатов, полученных Brownlee et al. [4]. Патч представляет собой успешный пример вставки редактирования, примененной к проекту jCodec (т. е. редактирования, которое скомпилировалось, прошло модульные тесты и обеспечило ускорение по сравнению с исходным кодом). Мы используем один и тот же пример для всех подробных запросов на подсказку, использованных в наших экспериментах; это связано с тем, что LLM способны к индуктивному рассуждению, когда пользователь представляет конкретную информацию, и LLM может использовать эти входные данные для генерации более общих утверждений, что дополнительно улучшено в GPT-4 [8].

Редактирование LLM применяется путем случайного выбора оператора блока в целевом «горячем» методе. Содержимое этого блока находится in the prompt. The first code block in the LLM response is identified. Gin uses JavaParser (https://javaparser.org) internally to represent target source files, so we attempt to parse the LLM suggestion with JavaParser, and replace the original block with the LLM suggestion.

Полученные результаты

В первом эксперименте сравниваются стандартные мутации GI, а именно правки вставки и утверждения, с правками LLM с использованием подсказок разной детализации (простых, средних и подробных) с использованием случайной выборки. В таблице 1 показаны результаты для всех исправлений, а также только для уникальных исправлений. Мы сообщаем, сколько патчей было успешно проанализировано JavaParser (названо «Действительно»), сколько скомпилировано и сколько прошло все модульные тесты (названы «Пройдено»). Мы исключили патчи, синтаксически эквивалентные оригинальному программному обеспечению. Лучшие результаты выделены жирным шрифтом .

Мы видим, что, хотя значительно больше действительных исправлений было найдено при использовании стандартных правок «Вставка» и «Операция», больше подходящих исправлений можно было найти с помощью правок, сгенерированных LLM. В частности, для подсказок Medium и Detailed модульные тесты прошли 292 и 230 патчей соответственно. Для редакций Insert и Statement только 166 и 91 редакция прошли модульные тесты соответственно. Как ни странно, горячие методы с самой низкой/самой высокой скоростью прохождения исправлений различались для каждого оператора: понимание этой разницы будет интересно для будущих исследований.

Также примечательно, что патчи LLM менее разнообразны: стандартными операторами мутаций было найдено более чем на 50% больше уникальных патчей, чем LLM с использованием Medium.

и Подробные подсказки. Однако при использовании приглашения Simple ни один патч не прошел модульные тесты, поскольку предлагаемые правки часто не могли быть разобраны. Таким образом, необходимы подробные подсказки, чтобы заставить LLM генерировать полезные результаты.

Мы дополнительно исследовали различия между подсказками Medium и Detailed, чтобы понять снижение производительности при использовании Detailed (в уникальных наборах исправлений), поскольку в Medium было больше скомпилированных и переданных исправлений. На обоих уровнях подсказок сгенерированный ответ был одинаковым для 42 случаев (из общего числа уникальных действительных случаев). Однако «Подробный» имел тенденцию генерировать более длинные ответы, в среднем 363 символа, тогда как «Средний» имел в среднем 304 символа. Мы вручную проверили несколько подробных ответов на запросы, в которых мы определили некоторые переменные из других файлов, что потенциально предлагает значительное расширение набора вариантов кода, которые может исследовать GI.

Второй эксперимент расширяет наш анализ, сравнивая эффективность стандартного редактирования и редактирования LLM с локальным поиском. В таблице 2 показаны результаты эксперимента «Локальный поиск». Мы сообщаем о количестве компилируемых и передаваемых исправлений, а также о количестве исправлений, в которых были обнаружены улучшения во время выполнения. Кроме того, мы сообщаем о среднем и лучшем улучшении в миллисекундах (мс). В таблице мы исключили все пустые патчи. Как и прежде, лучшие результаты выделены жирным шрифтом .

Опять же, мы видим, что больше патчей, прошедших модульные тесты, можно найти с помощью LLM, используя подсказки Medium и Detailed. Кроме того, при использовании LLM с этими подсказками можно найти дополнительные улучшения. В частности, при использовании Medium и Detailed мы обнаружили 164 и 196 улучшений соответственно, в то время как при использовании Insert — только 136, а при Statement — 71. Наилучшее улучшение было достигнуто при 508 мс при редактировании Statement. Лучшее улучшение, найденное с помощью LLM (с использованием приглашения Medium), позволило улучшить время выполнения только на 395 мс. Мы также изучили ряд изменений в результатах локального поиска, чтобы понять различия между подсказками среднего и подробного характера из-за низкой скорости компиляции ответов подробных подсказок. В этом примере последовательность изменений направлена на встраивание вызова функции clip. Подробное приглашение попыталось включить вызов почти сразу после нескольких изменений, что, вероятно, привело к недопустимому коду. С другой стороны, приглашение Medium внесло менее радикальные изменения, постепенно совершенствуя код. Все началось с замены выражения тройного оператора оператором if-then-else и вызовами системных функций, прежде чем в конечном итоге была предпринята попытка встроить вызов функции клипа.

Выводы и будущая работа

Генетическое улучшение программного обеспечения во многом зависит от операторов мутации, которые оно использует в процессе поиска. Чтобы диверсифицировать операторы и еще больше обогатить пространство поиска, мы включили в качестве оператора модель большого языка (LLM).

Ограничения . Подводя итог, можно сказать, что в будущей работе следует рассматривать проекты, выходящие за рамки нашей цели — jCodec. В наших экспериментах использовался API, который не давал нам возможности контролировать ответы, генерируемые LLM, или каким-либо образом их изменять или оптимизировать. Хотя во время наших экспериментов мы не наблюдали изменений в поведении, OpenAI может изменить модель в любое время, поэтому в будущей работе следует учитывать локальные модели. Мы экспериментировали только с тремя типами запросов для запросов LLM и в рамках этого ограниченного числа запросов обнаружили различия в результатах. Наконец, наша реализация анализа ответов от LLM была относительно упрощенной. Однако это будет означать лишь то, что наши сообщаемые результаты пессимистичны и что оператор, базирующийся на LLM, может добиться еще большего улучшения.

Краткое содержание . Мы обнаружили, что, хотя при стандартном редактировании с использованием случайной выборки было обнаружено больше действительных и разнообразных исправлений, при редактировании на основе LLM было обнаружено больше исправлений, прошедших модульные тесты. Например, при редактировании LLM с использованием приглашения Medium мы обнаружили более чем на 75 % больше исправлений, прошедших модульные тесты, чем при классическом редактировании вставкой. В нашем эксперименте с локальным поиском мы обнаружили наилучшее улучшение при редактировании оператора (508 мс). Лучшее улучшение на основе LLM было обнаружено при использовании подсказки Medium (395 мс). Таким образом, существует потенциал в изучении подходов, сочетающих LLM и «классические» правки GI.

Наши эксперименты показали, что подсказки, используемые для запросов LLM, сильно влияют на результаты. Таким образом, в будущей работе мы надеемся больше экспериментировать с быстрым инжинирингом. Также может быть полезно смешивать подсказки: например, начиная со среднего, а затем переключаясь на подробный, чтобы внести более крупные изменения, выходящие за пределы локальных минимумов. Кроме того, может быть интересной возможность объединения правок LLM с другими, такими как стандартное копирование/удаление/замена/замена или шаблоны PAR [11]. Наконец, мы надеемся провести более обширные эксперименты по дополнительным тестовым программам.

Доступность данных. Код, подсказки LLM и экспериментальная инфраструктура, данные оценки и результаты доступны в виде открытого исходного кода по адресу [1]. Код также находится в ветке «llm» на github.com/gintool/gin (коммит 9fe9bdf; ответвление от главного коммита 2359f57 в ожидании полной интеграции с Gin).

Благодарности UKRI EPSRC EP/P023991/1 и ERC 741278.

Рекомендации

1. Артефакт усиления мутаций генетического улучшения с использованием больших языковых моделей. Зенодо (сентябрь 2023 г.). https://doi.org/10.5281/zenodo.8304433

   
   

2. Бёме М., Соремекун Э.О., Чаттопадьяй С., Угеруге Э., Зеллер А.: Где находится ошибка и как ее исправить? Эксперимент с практиками. В: Учеб. Симпозиум ACM по основам программной инженерии. стр. 117–128 (2017)

   
   

3. Браунли А.Е., Петке Дж., Александер Б., Барр Э.Т., Вагнер М., Уайт Д.Р.: Джин: исследования по генетическому улучшению стали проще. В: ГЕККО. стр. 985–993 (2019)

   
   

4. Браунли А.Е., Петке Дж., Расберн А.Ф.: Внедрение ярлыков для более быстрого выполнения кода Java. В: IEEE CEC 2020. с. 1–8

   
   

5. Чен М., Творек Дж., Джун Х., Юань К., Пинто HPdO, Каплан Дж., Эдвардс Х., Бурда Ю., Джозеф Н., Брокман Г. и др. др.: Оценка больших языковых моделей, обученных на коде. Препринт arXiv arXiv:2107.03374 (2021 г.)

   
   

6. Фан, А., Гоккая, Б., Харман, М., Любарский, М., Сенгупта, С., Ю, С., Чжан, Дж. М.: Большие языковые модели для разработки программного обеспечения: обзор и открытые проблемы (2023)

7. Github — jcodec/jcodec: основной репозиторий Jcodec, https://github.com/jcodec/jcodec

   
   

8. Хан, С.Дж., Рэнсом, К.Дж., Перфорс, А., Кемп, К.: Индуктивные рассуждения у людей и большие языковые модели. Исследования когнитивных систем с. 101155 (2023)

   
   

9. Хоу, X., Лю, Ю., Ян, З., Гранди, Дж., Чжао, Ю., Ли, Л., Ван, К., Луо, X., Ло, Д., Ван, Х.: Большие языковые модели для разработки программного обеспечения: систематический обзор литературы. arXiv:2308.10620 (2023)

   
   

10. Канг С., Ю С.: На пути к целенаправленному генетическому улучшению с помощью больших языковых моделей. arXiv:2304.09386 (2023)

    
    

11. Ким Д., Нам Дж., Сонг Дж., Ким С.: Автоматическое создание исправлений на основе написанных человеком исправлений (2013), http://logging.apache.org/log4j/

    
    

12. Кирбас С., Винделс Э., Макбелло О., Келлс К., Пагано М., Салански Р., Новак В., Уинтер Э., Коунселл С., Боуз Д., Холл Т., Харальдссон С., Вудворд Дж.: О внедрении автоматического программного восстановления в Bloomberg. Программное обеспечение IEEE 38 (4), 43–51 (2021 г.)

    
    

13. Маржинеан А., Бадер Дж., Чандра С., Харман М., Цзя Ю., Мао К., Молс А., Скотт А.: Sapfix: Автоматизированный сквозной ремонт в шкала. В: ИКСИ-ГОЭИ. стр. 269–278 (2019)

    
    

14. Петке Дж., Александер Б., Барр Э.Т., Браунли А.Е., Вагнер М., Уайт Д.Р.: Ландшафты преобразования программ для автоматизированной модификации программ с использованием Gin. Эмпирическая разработка программного обеспечения 28 (4), 1–41 (2023)

    
    

15. Петке Дж., Харальдссон С.О., Харман М., Лэнгдон В.Б., Уайт Д.Р., Вудворд Дж.Р.: Генетическое улучшение программного обеспечения: комплексный обзор. Транзакции IEEE по эволюционным вычислениям 22, 415–432 (2018)

    
    

16. Сиддик М.Л., Сантос Дж., Танвир Р.Х., Ульфат Н., Рифат Ф.А., Лопес В.К.: Исследование эффективности больших языковых моделей при создании модульных тестов. Препринт arXiv arXiv:2305.00418 (2023 г.)

    
    

17. Собания Д., Бриш М., Ханна К., Петке Дж. Анализ эффективности автоматического исправления ошибок в чатgpt. В: Международный семинар IEEE/ACM по автоматизированному восстановлению программ (APR), 2023 г. стр. 23–30. Компьютерное общество IEEE (2023 г.)

    
    

18. Ся, К.С., Палтенги, М., Тиан, Дж.Л., Прадел, М., Чжан, Л.: Универсальный фаззинг с помощью больших языковых моделей. Препринт arXiv arXiv:2308.04748 (2023 г.)

    
    

19. Ся, К.С., Чжан, Л.: Продолжайте разговор: исправление 162 из 337 ошибок по цене 0,42 доллара США за каждую с помощью чатгпт. Препринт arXiv arXiv:2304.00385 (2023 г.)