Внедрение ИИ в процессы разработки и отладки неизменно сопровождается изматывающими обсуждениями с участием юристов, комплаенс-менеджеров и специалистов по кибербезопасности. И это понятно – никому не хочется нести ответственность за риски, связанные с безопасностью данных, конфиденциальностью и соблюдением авторских прав. Однако самый важный вопрос – как использование ИИ повлияет на качество готового продукта – обычно остается без внимания. Именно эту проблему мы и обсудим.
Смена парадигмы
«Раньше я тратил все свое время на написание кода, а теперь я его трачу на исправление и отладку сгенерированных ChatGPT ответов».
Самая популярная сейчас точка зрения на использование генеративного ИИ в разработке заключается в следующем: давайте делегируем утомительную задачу по написанию кода чат-ботам, чтобы программисты могли сосредоточиться на более творческих аспектах работы.
Такого мнения придерживается, например, Андрей Карпаты:
«В любом случае, сфера разработки программного обеспечения претерпит значительные изменения. Работа программистов будет все больше напоминать управление автоматизированными процессами, когда их основная задача будет заключаться в задавании общих директив, концептуальных идей или стратегических ориентиров на английском языке».
Аналогичная мысль высказывается в одном из курсов LinkedIn (к слову, на этой платформе теперь доступно 250+ бесплатных курсов по ИИ) об ИИ-ассистентах разработчика:
«Это инструменты повышения продуктивности, ускоряющие рабочие процессы при одновременном улучшении качества конечного продукта».
В общем, в том или ином виде эту точку зрения можно встретить везде – от сенсационных видео и статей до высказываний влиятельных личностей вроде гендиректора NVIDIA, который считает, что профессия программиста скоро станет неактуальной, потому что с помощью ИИ разработчиком может стать каждый. Эта парадигма предполагает смену должностной инструкции разработчика – переключение с программирования на:
- Написание промптов и проверку сгенерированного кода.
- Направление ИИ-модели на получение желаемого результата.
В конце концов, средний разработчик печатает со скоростью 40 слов в минуту, а GPT-4 легко выдает 1100.
Разработчик + ИИ = больше кода + более высокое качество кода
Однако на практике оплата подписки на GitHub Copilot не обязательно приведет к немедленному и очевидному повышению производительности или упрощению рабочих процессов. Последствия могут быть многогранными, неоднозначными, и не сразу проявятся в полной мере. Связано это с текущими ограничениями GPT и LLM.
Oграничения GPT и LLM
Поскольку времена, когда вместо языков программирования будут использоваться человеческие языки, еще не настали, поговорим о доступных инструментах генерации кода – GPT и LLM.
Галлюцинации
Это самый очевидный и серьезный недостаток генеративного ИИ на данном этапе развития. Причем с технической точки зрения ответы GPT/LLM на 100% являются галлюцинациями. Результаты выглядят вполне разумно и корректно (по большей части) только потому, что ИИ-модели бредят реальными данными. Но из-за самой архитектуры генеративного ИИ появление неверных, бессмысленных или вымышленных фрагментов в ответах неизбежно – это и есть галлюцинации в уже привычном нам смысле.
Другая распространенная проблема, которую тоже можно отнести к галлюцинациям – неверное понимание промпта и контекста. Очень часто чат-боты игнорируют часть инструкций и фрагменты контекста, либо видят в запросе/контексте что-то, чего там точно нет. С этой точки зрения RAG вряд ли можно назвать надежным средством от галлюцинаций. Единственное решение этой проблемы – принципиально новая архитектура генеративных моделей. И пока она не появится, модели будут иметь неизбежную склонность к генерации ерунды.
Иррациональность
GenAI неплохо справляется с генерацией логически простого текста, но с более сложными логическими рассуждениями (и тем более со сложным кодом) дела обстоят хуже. Это связано с акцентом на синтаксис вместо семантики – модели генерируют каждое последующее слово, руководствуясь языковой структурой, а не глубоким пониманием смысла.
Отсутствие надежной индикации уверенности
Даже самые продвинутые на сегодняшний день модели еще не могут надежно определять границы своих знаний и помечать части вывода, в которых они не уверены.
Ограниченный объем контекста
Размер контекста, который модель может обрабатывать одновременно, очень мал для решения большинства практических задач. Например, GPT-4 с окном контекста 128к может вместить только 24 средних файла из ядра Linux. Беты Claude 3 и Gemini 1.5 уже оперируют с контекстом 1 млн, но и этого объема мало для работы с реальными проектами. К тому же обработка объемного контекста влечет за собой дополнительные проблемы:
- Возрастание количества вызовов API.
- Снижение производительности – с 10-кратным увеличением контекста потребность в ресурсах повышается в 100 раз.
Нестабильность
Если ИИ-модель натыкается на редкое или необычное сочетание токенов, которые не встречались при обучении (или встречались крайне редко), это может вызвать неожиданное поведение в генерации последующих токенов. Этот эффект обычно нарастает как снежный ком, и приводит к полной потере когерентности и смысла генерируемого текста: модель срывается в режим бессмысленного вывода и уже не может правильно интерпретировать исходный контекст. Вероятность появления SolidGoldMagikarp'ов при генерации кода выше, чем при генерации обычного текста.
Зависимость от качества обучающих данных
Обучающие данные для LLM содержат большие объемы кода из разных источников. Очевидно, это по большей части репозитории опенсорсных проектов. При обучении на таких данных неизбежны последствия:
- Код из открытых репозиториев может быть средним или даже посредственным по качеству – из-за огромного количества учебных и заброшенных проектов.
- В ходе подготовки огромного массива данных невозможно оценить качество кодовой базы и отфильтровать только лучшие образцы.
- Когда LLM генерирует код, она генерирует его в рамках того распределения данных, на которых она была обучена – и посредственные обучающие данные приводят к посредственным результатам.
- В наборах данных преобладают устаревшие версии библиотек и фреймворков. Соответственно, LLM будет генерировать код с использованием этих устаревших версий.
Итог – код, сгенерированный современными LLM, зачастую оказывается:
- Посредственным, поскольку обучающие данные содержат много кода среднего и низкого качества.
- Морально и технически устаревшим.
- Уязвимым, потому что модель воспроизводит ошибки из своих обучающих данных, или использует небезопасные библиотеки и параметры. Copilot, к примеру, повторяет уязвимый код и усугубляет проблему безопасности для каждого проекта, в котором используется. А этот код для аутентификации, написанный ChatGPT, работает исправно, но содержит 5 серьезных уязвимостей.
Бомбы замедленного действия
Случайные галлюцинации и устаревшие библиотеки, на первый взгляд, не такая уж большая проблема – ведь сгенерированный код всегда можно подправить. Но на практике чтение готового кода требует больше умственных усилий, чем написание собственного. Именно поэтому большинство разработчиков с неохотой берутся за код-ревью. То же самое происходит со сгенерированным кодом – вместо того, чтобы исправлять его вручную, разработчики отправляют его чат-боту с указанием «исправь». Это менее энергозатратный цикл работы с меньшей нагрузкой на мышление.
Статистика показывает, что после появления Copilot разработчики стали чаще добавлять и копипастить код, нежели обновлять/удалять уже существующий, что явно свидетельствует о нежелании вникать в детали и делать полноценные код-ревью. А недавнее исследование указывает на формирование халатного отношения к написанию кода с помощью ИИ: разработчики начинают вести себя, как нерадивые студенты, которые в последний момент сдают курсовики, наспех состряпанные из интернетной копипасты.
Почему ИИ-ассистенты все же вам пригодятся
Сенсационные заголовки СМИ сильно подпортили репутацию LLM/GPT, расширив пропасть между тем, что ИИ уже может делать хорошо, и тем, чего многие от него ожидают. На данном этапе ИИ-ассистенты ближе к эргономичным инструментам вроде продвинутых версий IntelliSense или ReSharper:
- Они не являются полностью автономными агентами, способными взять на себя сложные задачи (и даже простые) – GenAI еще не достиг такого уровня.
- Ассистенты пока еще не произвели никакой реальной революции в разработке, и пока еще не могут кардинально изменить жизнь разработчиков.
- Интегрируя AI-инструменты в рабочие процессы, важно делать это критически, понимая их ограничения и потенциальные риски.
- Разработчики должны скрупулезно контролировать качествo кода, генерируемого ИИ, гарантируя его надежность перед внедрением в продукты.
Но, несмотря на нынешние ограничения LLM/GPT и во многом обоснованный скептицизм, уже невозможно представить возврат к работе без инструментов на основе генеративного ИИ. Большинство разработчиков, так или иначе, используют ИИ – чат-ботов и IDE-ассистентов. И это правильно: при сдержанных ожиданиях и ясном понимании возможностей и ограничений языковых моделей, лежащих в основе различных ИИ-помощников, их действительно можно использовать для повышения личной производительности, пусть и не радикального.
При подготовке статьи использовалась публикация AI-assisted coding, Sleeping on a Volcano.
Комментарии