Главная проблема использования ИИ (Иллюзии Интеллекта) при разработке ПО

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

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

Ложные ожидания от внедрения ИИ

Подавляющее большинство статей о прорывах в области ИИ преследуют одну простую цель - продать свое решение, и целевых аудиторий как минимум две:

Первая - это люди с недостаточной квалификацией, которым внушают, что с помощью ИИ они смогут выполнять работу более высококлассных специалистов, что создает ложное чувство расширения собственных возможностей и якобы дает возможность самостоятельно писать программы без каких-либо навыков программирования (это тот самый вайб-кодинг), которое разбивается о первую же реальную и нетривиальную задачу.

И вторая, более серьезная аудитория, - это менеджмент компаний, которым продают идею оптимизации расходов: зачем платить команде дорогих сотрудников, если можно заменить их одним специалистом с низкой квалификацией и подпиской на ИИ-сервис? Расчет прост: сократить фонд оплаты труда, заменив обычный, но дорогой человеческий труд на дешевый, но непредсказуемый на основе ИИ-агентов.

В сфере разработки программного обеспечения этот тренд проявился особенно ярко. Некоторые компании поддались всеобщей эйфории и начали массово сокращать опытные команды и заменять их более дешевыми решениями с привлечением ИИ. Но оценка первых результатов оказалась отрезвляющей. Процесс разработки превратился в непредсказуемое и неконтролируемое шаманство. В итоге на рынке наметилась обратная тенденция: компании, которые, уже столкнувшись с хаосом после внедрения ИИ, начинают без шума и пафоса возвращать ранее уволенных сотрудников.

Мои не оправдавшиеся надежды

Поводом для написания этой статьи послужила очередная психологическая война (не найду более подходящего определения) с LLM в попытке решить относительно простую задачу, а именно написать систему сборки проекта на CMake вместо пользовательского Makefile. Сам проект включает в себя пару файлов на C++, которые компилируются с помощью clang. Из одного получается плагин для компилятора (обычный so-файл), а из второго - исполняемый файл с юнит-тестами для Google Test Framework.

С учетом того, что изначально сборка выполняется корректно, а все тесты проходят, я надеялся, что подобная задача будет по плечу любому ИИ-помощнику. К сожалению, ожидания полностью разошлись с реальностью, так как мало того, что сборка проекта с помощью CMake так и не заработала, так еще Имитация Интеллекта самовольно создала новый файл, хотя я уже ученый и в промте стоял явный запрет на такие действия (не создавать новые файлы, кроме явно перечисленных). Кроме этого, была самопроизвольно изменена лицензия проекта с LGPL на MIT и был полностью изменен файл документации, где подробное описание проекта было заменено на два десятка строк с описанием процесса сборки, которая, кстати, так и не заработала!

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

Разработка ПО - не шаманство!

Разработка ПО - уже давно инженерия с контролем качества и воспроизводимостью результатов. И один из основных процессов в разработке ПО - это отладка кода, которая зачастую заключается в многократном повторении одного и того же сценария, чтобы найти причину возникновения неправильного поведения программы.

Современные большие языковые модели (LLM) не «понимают» задачу в инженерном смысле. Это вероятностные системы, которые не вычисляют единственно верный ответ, а на основании входных данных и запроса (промта) генерируют наиболее вероятную последовательность слов (токенов) на основе гигантского массива данных, на котором их обучали.

А теперь представим сценарий: разработчик использует ИИ для генерации фрагмента кода. Он пишет промт, на основании которого получает рабочий код и внедряет его. Через неделю ему нужно внести небольшое изменение. Он пишет новый промпт для доработки кода и все перестает работать. Он пытается поправить исходный пром и... тоже ничего не получается. В чем причина: только ли в изменении запроса? Или модель просто сгенерировала другой вариант из-за изменившейся «фазы луны» (нового SEED, изменившихся системного промта у провайдера или дообучения модели)?

Один и тот же промт, отправленный на одну и ту же модель, может выдавать разные данные, и ни о какой воспроизводимости результатов здесь не может быть и речи, так как на это влияет множество дополнительных факторов:

• Существует много провайдеров и их моделей Модели от OpenAI, Google, Anthropic или GigaChat на один и тот же запрос дадут разный код, потому что их архитектуры и данные для обучения различаются.

• Обновления модели - провайдер может обновить модель без уведомления пользователя. Та версия, что вчера генерировала идеальный код, сегодня после обновления может выдавать совершенно другой результат.

• Скрытые настройки - системный промт (внутренние инструкции, которые модель получает перед обработкой вашего запроса), настройки цензуры и безопасности постоянно меняются провайдером, и это напрямую влияет на генерацию итогового результата.

• Temperature - параметр, который контролирует степень «креативности» и случайности ответа, и даже небольшое его изменение кардинально меняет результат.

• SEED - начальное значение для генератора псевдослучайных чисел, и если оно не зафиксировано, то каждый запуск модели с одними и теми же данными также будет уникальным.

В итоге работа с ИИ превращается в настоящее шаманство. Вы получили хороший результат? Отлично! Но вы не можете гарантировать, что получите его снова. Отсутствие повторяемости результата делает невозможным разработку ПО из-за непредсказуемости даже малейших доработок существующего кода и невозможности отладки промптов!

Воспроизводимость результатов как обязательное требование к ИИ

Прежде чем начинать использовать любые ИИ-модели как серьезный инструмент при разработке ПО, необходимо решить проблему воспроизводимости (повторяемости) результатов хотя бы в рамках одной версии модели.

У пользователя должен быть какой-либо механизм, который будет гарантировать, что на один и тот же запрос можно получить один и тот же ответ (неважно, правильный он или нет), иначе без возможности повторного воспроизведения запросов, ИИ навсегда останется игрушкой, а не рабочим инструментом инженеров.

Самый простой и очевидный вариант реализации подобного механизма - это в начале сессии или при генерации ответа отдавать вместе с ним специальный токен, который включает в себя (или каким-то образом идентифицирует) все внутренние настройки сессии провайдера.

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

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

И раз уж на эту статью меня уговорили добавить плашку «Сезона ИИ в разработке», то было бы логично с моей стороны предложить разработчикам GigaChat попробовать реализовать механизм воспроизводимости результатов в рамках своего сервиса. Это превратило бы GigaChat из интересного экспериментального продукта в профессиональный инструмент, который можно без опаски интегрировать в серьезные процессы разработки программного обеспечения.