Пару дней назад на западе очень сильно хайпанула статья «Assessing the Impact of Code Changes on the Fault Localizability of Large Language Models» в которой говорится о том, что используемые компаниями бенчмарки для того, чтобы помериться у кого длиньше круче модель - куча 💩💩💩 И реальный выхлоп куда ниже заявленного. Модели реально справляются не с 70-80% при их использовании в сопровождении проекта, а держатся где-то на уровне 30%...
Статья крутится не вокруг разработки нового софта, а вокруг его сопровождения (фикским баги). В ходе исследования ученые пощупали применение 10 различных LLM для решения 750,013 задач для датасете из более чем 1300 приложений, написанных на Python/Java.
Как проходило исследование? 🤩
В программный код приложений динамически добавлялись различные баги (спецификацию софта не трогали) и модель просили их найти. После того, как она справлялась с поставленной задачей, вокруг добавленного бага вносились семантические изменения в код. То есть добавлялись комментарии и куски «мертвого» кода, меняли имя переменной, функции или метода и переставляли их местами и т.д.
Другими словами, не меняя принцип работы программы и не добавляя еще один баг, вносили «косметический» шум для LLM, после чего снова просили найти добавленную ранее ошибку в приложение. И вот тут-то начались приколы...
- Переименование переменных в среднем привело к тому, что точность моделей составила 29.02%
- Вводящие в заблуждение комментарии - 25.63%, из чего следует, что LLM реально опираются на комментарии
- При наличие мертвого кода точность составила 20.38%
- Перестановка функций в Java при сохранении той же логики работы приложения привели к падению точности на 83%
И чем больше такого «шума», тем быстрее падает точность работы моделей... и даже использование новомодных LLM улучшило результат только на ~1-2% (то есть - ни о чем)
Что это значит для нас? 👀
Рассуждения агентов (если судить по предварительным выводам из статьи) о нашем коде привязаны к его признакам (паттерны, базовые конструкции, общеизвестные подходы и т.д.), а не семантике. На эту мысль ученых натолкнул тот факт, что тупое изменение имени переменных, перестановка функций местами (с начала файла с кодом в конец), добавление ничего не значащих или вводящих в заблуждение комментариев... То есть всего того, что реально не влияет на семантику (смысловую составляющую) кодовой базы, привело к такой посадке точности в работе LLM 👀
Говоря другими словами, агент ищет баг ориентируясь не на смысловую составляющую кодовой базы, а только на используемые вами базовые конструкции написания кода, из-за чего и наблюдается такая посадка в точности при нахождении ровно того же бага, что и был найден до этого, но находящегося теперь в окружении не меняющего логику работы программы шума 🤔
p.s. Блин… это что получается, теперь и при дебаге с ИИ придется напрягать свои извилины? 😂😂😂
