Что не так с вашим кодом, сгенерированным большими языковыми моделями?

Китайские ученые провели обширное исследование на 7 популярных LLM, генерируя с помощью них код, а потом выявляя и анализируя ошибки. Им удалось не только выявить и категоризировать наиболее частые закономерности ошибок, но и предложить метод их устранения.

Далее будет вольный краткий перевод с комментариями.

Для исследования были выбраны 7 моделей.

Бенчмарк для оценки моделей включал все образцы из HumanEval+ и MBPP+, а также 600 образцов из APPS+, в общей сложности 1000 образцов. Кроме того, для оценки эффективности генерации кода LLM в реальных проектах ученые создали реальный эталонный тест RWPB из репозиториев GitHub, созданных в 2024 году.

В рамках ограничений эксперимента сгенерированный код считался правильным, если он проходил проверку компилятора, выполнялся без ошибок и выводил ожидаемый результат для предопределенных входных данных. Кроме того, правильный код должен был пройти все тестовые случаи в бенчмарке, поскольку различные тестовые случаи охватывают различную семантику. Только пройдя все тесты, сгенерированный код мог продемонстрировать полное выполнение всех требований.

1. Код, сгенерированный моделями, обычно имеет меньше строк, но немного более высокую сложность, в то время как количество API аналогично количеству канонических решений. Примечательно, что код, сгенерированный Claude-3, имеет тенденцию включать меньше строк кода и более низкую сложность при использовании большего количества API, что, вероятно, связано с тем, что Claude-3 использует API для замены частей сложной реализации кода.

Различия в характеристиках кода между кодом, сгенерированным моделями, и каноническими решениями на HumanEval+. CC обозначает цикломатическую сложность.

2. Неверный код содержит больше комментариев, чем верный код.
Для HumanEval+ неправильный код, особенно от Claude-3 и Deepseek‑Coder, имеет тенденцию иметь больше разнообразных комментариев, чем правильный код. Аналогично, в наборе данных APPS+ дополнительные модели имеют тенденцию включать комментарии как в правильный, так и в неправильный код, с тенденцией к получению более высокого медианного числа комментариев в неправильном коде.

Это явление можно объяснить двумя потенциальными факторами. Во‑первых, сложные проблемы, присутствующие в корпусах кода, используемых для обучения этих LLM, часто содержат больше комментариев. Следовательно, LLM могут научиться воспроизводить эту модель, что приведет к генерации большего количества комментариев при решении сложных задач. Во‑вторых, LLM могут генерировать дополнительные комментарии как форму контекстного или пояснительного контента, когда они не уверены в правильности сгенерированного кода. Однако эти комментарии не значительно повышают точность LLM, поскольку уровень корректности остается низким.

3. По мере того, как описания проблем в бенчмарках удлиняются и становятся более сложными, LLM испытывают трудности с выполнением требований формата ввода‑вывода и с большей вероятностью генерируют неполные синтаксические структуры. Это связано с тем, что более длинные и сложные описания проблем затрудняют для LLM запоминание деталей, а длина сгенерированного кода может привести к ошибкам, таким как непарные скобки.

4. Неправильное использование API составляет наибольшую долю runtime ошибок в большинстве бенчмарков. Существует три основных ошибки, связанных с неправильным использованием API: AttributeError (20,9%), TypeError (50%) и ValueError (26,9%). AttributeError возникает, когда делается недопустимая ссылка на отсутствующий атрибут API. TypeError возникает, когда API применяется к объекту неправильного типа, в то время как ValueError возникает, когда предоставляется аргумент правильного типа, но неподходящее значение.

5. Реализация алгоритма часто неоптимальна, как правило, с высокой временной сложностью, что не позволяет программе завершиться в установленные сроки. Для более сложных алгоритмических задач LLM, как правило, используют циклы или глубокий поиск без оптимизированных условий выхода. Кроме того, частое использование рекурсивных алгоритмов значительно увеличивает временную сложность.

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

Источник: Хабр