ИИ вот-вот заменит сотни тысяч должностей не только в разработке ПО, но и во множестве других областей: в журналистике, творческой работе, общении с покупателями и так далее. Это та же самая мантра, которую мы слышим по поводу каждой технологической инновации: «Компьютер полностью заменит людей». Старая история из фильмов про терминаторов.
Хотя я уже перечислил некоторые возможные последствия для ПО в своей статье «Мы снова в кризисе ПО, но в ближайшее время ИИ никого не заменит», мне бы хотелось рассмотреть, что произойдёт, если большие языковые модели (Large Language Model, LLM) полностью заменят человеческий труд. Содержание дилеммы будет практически одинаковым для всех областей, но я сосредоточусь на разработке ПО, потому что самые громкие заявления об LLM звучат как раз в её сторону.
Как и при помощи чего обучаются LLM
Если вы хотите узнать, как работают LLM, то крайне рекомендую посмотреть на YouTube видео Stable Diffusion автора Computerphile. В нём даётся очень хорошее базовое объяснение концепций и принципов работы этих алгоритмов для создания нужных результатов.
Если говорить простыми словами, LLM для генерации текста и изображений — это, по сути, мясорубки, создающие новый вид мяса на основании существующего мяса и специй, которые вы указали в промте. В процессе перемалывания ингредиенты перемалываются так долго, что они как будто становятся чем-то совершенно новым.
Проблемы переобучения LLM
Если обучить LLM на очень маленьких датасетах без предварительного использования больших объёмов обучающих данных, то мы сможем увидеть части исходной работы, на которой она обучалась. В общем случае предполагается, что проблема переобучения (overfitting) LLM возникает только в случае маленьких и специализированных датасетов.
В своей статье «Винтажное программирование на Macintosh System 7.5» я наблюдал проблему переобучения даже у таких LLM, как GPT-4, Gemini и Copilot. Трудность, с которой сталкиваются Github Copilot и GPT, заключается в том, что они неспособны создать даже простейший код операционных систем Macintosh конца 1980-х и начала 90-х, то есть Macintosh system 5, 6 и 7. Так как программирование и системы со временем меняются, LLM неспособны ориентироваться на конкретные версии целевых платформ прошлого. Это связано с тем, что в их обучающих данных часто отсутствует историческая информация, а LLM неспособны полностью ограничить эти данные конкретными историческими периодами.
LLM не могут ограничить себя конкретным моментом времени
LLM обучены на основании имеющегося сегодня статуса-кво, с упором на самые новые данные; даже этого достичь достаточно сложно. В своей статье «Внутри расширений iMessage» я вкратце рассказал о том, что LLM неспособны создавать код для новых SDK, даже если эти новые SDK входят в их модель обучения. В моём случае Github Copilot и GPT-4 постоянно генерировали код реализации Apple StoreKit1 вместо более простого и совершенного StoreKit2 для iOS. Они перекошены в сторону StoreKit1, так как объём обучающих данных для StoreKit1 намного превосходит данные для StoreKit2.
Это демонстрирует, что сложности возникают при обучении LLM и на очень маленьких, и на очень больших датасетах. Так как LLM пытаются обобщать имеющиеся у них обучающие данные, им часто не удаётся решить очень конкретные задачи, даже если их обучили на данных, содержащих решение. Чем более нишевой становится задача, тем более конкретным должен быть промт. Настолько конкретным, что в промте часто даже приходится приказывать, в каких конкретно обучающих данных (например, в каком языке программирования) нужно выполнять поиск.
Неспособность оценивать собственную работу
Когда люди работают, они могут оценивать результат своей работы, в том числе и достоверность того, что они создали. LLM пытаются имитировать это поведение, рекурсивно перерабатывая собственные результаты. Этот процесс переработки также включает в себя попытки верификации достоверности своей работы. Однако такой процесс оценки ограничен количеством этапов переработки, выполняемых LLM. Человек может потратить время, необходимое для того, чтобы повторные итерации обеспечили нужный результат, а LLM просто ограничивает количество итераций количеством этапов, а значит, и временем. Она создаёт наилучший результат, возможный за определённый временной промежуток.
Люди оценивают работу иначе, чем LLM
На написание книги «1984» Эрику Артуру Блэру (более известному как Джордж Оруэлл) понадобилось три года, с 1946-го по 1949-й. Он жил на изолированном далёком острове Джура на западе Шотландии. Работа над книгой заняла у него столько времени, сколько он посчитал необходимым, чтобы она была готова к публикации. В отличие от людей, LLM работают не до того момента, когда их результат лучше всего будет подходить под нужный, а пока не достигнут предела циклов обработки. Это можно сравнить с работой немотивированного сотрудника, заканчивающего трудиться ровно в 17 часов, вне зависимости от качества работы.
Стремясь применить фильтры качества, реализации LLM проверяют и промт, и результат на запросы недопустимого контента. Промты с прямыми запросами недопустимого контента можно легко отфильтровывать, но даже при использовании специализированных LLM для проверки промтов обобщённых LLM существуют способы применения формулировок, позволяющих обойти эти проверки и хитростью заставить LLM создать недопустимый контент.
Например, для получения недопустимых изображений человеческого тела можно использовать специализированные анатомические термины, в качестве побочного эффекта добиваясь генерации изображения гениталий. В области разработки ПО можно составить промт с запросом кода, который в качестве побочного эффекта указывает учётные данные.
Нехватка дифференциации и контекста
Чтобы предотвратить утечку через LLM контента, который они не должны создавать, применяются выходные фильтры. LLM создаёт результат (например, учётные данные в коде или недопустимые изображения), но фильтр окончательного результата обнаруживает эту информацию и удаляет результат или отдельную часть информации. Такое поведение можно наблюдать при отправке промтов DALL-E через Microsoft Copilot. Обработка занимает больше времени и результатов оказывается меньше, чем четыре генерируемые по умолчанию изображения.
При использовании медицинских терминов в обучающих данных содержится столько анатомических изображений, что модель неизбежно создаст контент, который выходной фильтр сочтёт недопустимым. Он неспособен отличить простые анатомические изображения пальца ноги от изображений обнажённых по иным причинам частей тела.
Промт create an image of a women in her 40s walking the forest barefoot. («создай изображение сорокалетней женщины, гуляющей по лесу босиком») генерирует три изображения, а одно отфильтровывается выходным фильтром. Если поменять промт на create an image of a women in her 40s walking the beach barefoot on a hot summer day. («создай изображение сорокалетней женщины, гуляющей по пляжу босиком в жаркий летний день»), то, скорее всего, все результаты будут отфильтрованы или будут доступны максимум одно-два изображения. Учитывая количество людей, пытающихся заставить LLM создавать фильтруемый контент, правила фильтра крайне строги и часто приводят к ложноположительным срабатываниям.
Из-за активной фильтрации с большим количеством ложноположительных срабатываний LLM не могут создавать результаты в специфичных областях, например, анатомии и истории. Это неизбежно приводит и к ограничениям в других областях.
Блокировки, создаваемые различными перекосами
Учитывая культурный перекос LLM, разработанных североамериканскими компаниям, они с лёгкостью создают изображения различного вооружения, но отказываются генерировать людей, стреляющих из пистолета, или изображения, связанные с большим количеством амуниции. Однако всегда существуют способы заставить LLM обойти входные и выходные фильтры при помощи промтов, которые не распознаются фильтром промтов, и создать результат, неузнаваемый выходным фильтром.
Фильтры LLM прописаны жёстко, а значит, их легко можно обойти. Такой культурный перекос часто становится причиной множества общественных и политических обсуждений ИИ и больших языковых моделей. Фильтры устанавливаются владельцами модели, но и сама LLM создаёт перекос, причина которого кроется в эффекте Матфея. Когда обучающие данные содержат очень популярную информацию, LLM склоняется к наиболее популярной, как это видно из примеров с Macintosh system 7 и Apple StoreKit2.
Перекос фильтров можно побороть ослаблением или полным отключением фильтров со стороны владельца, но естественный перекос, создаваемый эффектом Матфея, преодолеть не так просто. Популярные решения для борьбы с эффектом Матфея — это рандомизация, популяризация нового, модели временной эрозии для популяризации более свежих данных и множество других методик. Обычно они снижают эффект Матфея, но в основном не устраняют его в существенной мере.
LLM зависят от передачи им данных об инновациях
LLM переупаковывает самое популярное известное знание в новый языковой контент. Это приводит к тому, что модели стимулируют к поддержанию статус-кво вместо того, чтобы бросать ему вызов и стремиться к развитию. Более того, чтобы модели узнавали о чём-то новом, им требуется человек. Это значит, что человек должен предоставлять обучающие данные об инновациях, чтобы LLM могли включить их в свою работу. Человек также должен контролировать модели, чтобы избежать внедрения естественного перекоса в сторону статус-кво и заставить LLM усвоить более новую информацию.
Управляемый LLM мир зайдёт в тупик
Представьте, что LLM пишет ПО, документацию и управляет его клиентской поддержкой. Хотя она может внедрять отзывы клиентов в процесс совершенствования ПО, сама модель не может ничего изобретать, потому что у неё нет креативности, реализуемой изобретением новых способов или даже освоением новинок.
Рассмотрим практический пример: вам нужно создать современное и инновационное ПО для онлайн-магазина. Это будет означать, что для написания высокопроизводительного бэкенда вы, скорее всего, рассмотрите такие языки, как Go или Rust. Для хранения данных вы можете выбирать из таких движков хранения ключей и значений, как AWS DynamoDB, Cassandra и так далее. Возможно, вы выберете MongoDB, если это разумно, однако при необходимости широкого выбора опций фильтрации вы склонитесь к конкретному поисковому движку или векторной базе данных.
Если передать LLM промт с такой задачей, то с высокой долей вероятности она продемонстрирует эффект Матфея, предложив самое популярное решение. В данном случае это JavaScript с MongoDB, разбитые на различные микросервисы. Хотя это и самый популярный подход, но он далеко не самый практичный или инновационный. Если задать модели вопрос, в каких ситуациях она бы написала собственную базу данных и поисковый движок, то она ответит, что это важно для масштабирования, шардинга, расширенных функций поиска и высокой производительности. Однако она не может использовать их в своей работе.
Как LLM отличается от человека
Это означает, что если LLM будет самостоятельно создавать ПО, то потенциально станет совершенствовать его для пользователя. Однако она не сможет продвигать технические инновации и не превзойдёт границы существующих технологий. А именно этим занимается живой разработчик ПО.
Кроме того, крайне вероятно, что LLM, неспособная логически осознать систему во всей её полноте, придёт к масштабному разрастанию фич (feature creep) или, по крайней мере, спустя несколько итераций изменений погрязнет в хаосе. Учитывая то, что большинство программных продуктов имеет больше запросов изменений, чем способен обработать человек, чтобы иметь преимущество перед человеком, LLM должна будет работать постоянно.
Чего будет стоить замена разработчика ПО на LLM
С экономической точки зрения LLM, вероятно, придётся обрабатывать несколько сотен тысяч строк команд, кода, схем и тому подобного. Чтобы гарантировать точные результаты LLM, потребуются точные входные данные. Можно с уверенностью сказать, что на данный момент почасовые затраты замены разработчика ПО на LLM составляют примерно $90–120. Работая круглосуточно, LLM при $90 в час и 720 часах работы в месяц будет стоить $64800.
Чтобы LLM могла заменить разработчика ПО с выгодой, даже если не учитывать вышеупомянутые перекосы и проблемы с инновациями, затраты на неё должны упасть на 90%. Это приведёт к тому, что ежемесячные затраты на LLM будут приблизительно равны $5000–6000 плюс эксплуатационные затраты на LLM и окружающую инфраструктуру DevOps. И всё это лишь теоретически, потому что сегодня качество создаваемого LLM кода ужасно. Все коммерческие LLM сопровождают созданный ими код предупреждениями, что разработчики ПО не должны слепо использовать этот код. LLM ещё далеки от того, чтобы создавать надёжный код. Часто они не справляются даже с простейшими задачами. Не поймите меня неверно: LLM сильно помогают разработчикам ПО, но они не смогут работать без надзора.
С развитием инноваций оптимизированных под ИИ чипсетов LLM могут совершенствоваться и становиться быстрее. Но пока всё равно не доказано, что они могут быть выгоднее живых работников. Даже если труд человека обходится дороже, например, в случае Евросоюза, всё равно под вопросом, смогут ли LLM и компьютерное оборудование стать экономически конкурентоспособными в областях наподобие разработки ПО.
Под вопросом даже чат-боты техподдержки
Один из самых распространённых сценариев использования LLM — чат-боты техподдержки, заменившие живых сотрудников. Так как для нас это новинка и лишь некоторые нетехнические компании проводят их долговременные испытания, мы пока не знаем всех их проблем и не знаем, как эффект Матфея помешает этим чат-ботам предлагать актуальные решения.
Эти чат-боты техподдержки обучены на статус-кво. Это означает, что в конечном итоге им понадобится сброс, если способ функционирования бизнеса серьёзно изменится. Им понадобится существенный объём повторного обучения. Пример с галлюцинациями чат-бота Air Canada уже даёт нам понять, насколько глубоко может заблуждаться LLM в реальных условиях. Очень практичный пример: если человек устранит баг системы, то сколько времени понадобится LLM, прежде чем она прекратит предлагать актуальные ранее способы решения проблемы?
Вывод: LLM зависят от людей
Хотя компании мечтают урезать затраты на труд при помощи LLM, а профсоюзы пытаются спасти своих членов от увольнения, реальность часто находится между этими полюсами. Из-за своих логических ограничений LLM неспособны действовать без надзора, поэтому они вряд ли полностью заменят людей.
LLM — потрясающее изобретение, не стоит недооценивать их важность и инновации, которые они способны привнести для бизнеса. В конечном итоге они повысят производительность людей, потому что можно будет автоматизировать множество кропотливой или монотонной работы. Это станет огромным прогрессом для общества и экономики. LLM ускоряют и упрощают написание бойлерплейт-кода, быстрее пишут электронные письма, общаются и ищут информацию. LLM — следующая логическая итерация компьютерного ПО и всё внимание к ним со стороны общества вполне справедливо.
Однако LLM не способны заменить людей. Они могут выполнять часть человеческого труда. Но они не могут быть творческими и инновационными. Ещё при их обучении возникают специфические проблемы, которые пока не могут решить даже самые умные люди в computer science. LLM определённо совершенствуются, но современные методики реализации LLM не позволяют им логически нарушать статус-кво во всём, что они создают, и создавать нечто оригинальное.
Важно узнавать об LLM и их возможностях. Лично я ежедневно пользуюсь Microsoft Copilot, Github Copilot, Google Gemini, Leonardo, Eleven Labs и ChatGPT-4. Важно исследовать преимущества и выгоды способностей LLMs. Мне удалось снизить рабочую нагрузку в программировании на 40–50%, то есть ту задачу, которую я раньше выполнял за восемь часов, сегодня я могу решить за четыре часа или меньше. То же самое справедливо для исследований и других форм деятельности, в которых я могу пользоваться помощью LLM. Однако когда дело касается разработки инновационных решений или исследования очень специфических технических аспектов, LLM часто оказываются совершенно бесполезными.
