Заметки об LLM и нейросетях вообще

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

По этому поводу перечитал свои старые посты: «Отставить панику…» и «Паникуем иначе», с удовлетворением убедился, что основной посыл остался верным и на текущий момент, хотя, конечно, за это время многое стало яснее и накопился реальный опыт использования — как у меня лично, так и, не побоюсь этого слова, у человечества в целом.

Кстати, КДПВ сгененирована по тому же промпту, что и в тех старых постах — «deep learned girl in fantasy style». Пожалуй, это будет моя новая традиция для постов на подобные темы. В конце концов, не искусственный же интеллект рисовать — его никто не видел.

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

Старые тезисы

Из «Отставить панику…»

Творческие задачи (создание нового)

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

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

Целеполагание и принятие решений

Ничего не поменялось. У нейросетей нет собственного целеполагания.

Вопросы ответственности

Ничего не поменялось. Вся ответственность на человеке.

Требования новых навыков

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

Из «Паникуем иначе»

Поисковый спам и зашумление интернета

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

А вот чего я не учитывал, так это нейросетевых ответов со стороны поисковиков, которые привели к уменьшению переходов на сайты. Насколько это глобально (а не только для владельцев сайтов) плохо — на самом деле вопрос открытый.

Дипфейки и прочая

Ну, это было очевидно и это, очевидно, есть.

Безответственность программистов

Расцвело в полный рост. Вайб-кодинг и вот это всё. Эту тему я надеюсь максимально раскрыть ниже в посте.

Безответственность пользователей

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

Беспомощность пользователей

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

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

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

Практика

Проблемы

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

Базовые проблемы

Ограниченный контекст

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

Для примера: проект inat-get, рефакторингом которого я потихоньку занимаюсь, целиком в контекст не помещается никак. А это ведь небольшой пет-проект одного человека.

Можно увеличить доступный контекст за счет более дорогих тарифных планов… Но это решение очень короткого горизонта, поскольку требования к контексту растут очень быстро — как минимум квадратично от объема входных данных (размера проекта, например).

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

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

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

Ненадежность

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

Позволю себе цитату из одной хорошей статьи на Хабре¹:

Посчитаем. Если каждый шаг в рабочем процессе агента имеет 95% надежности, что является оптимистичной оценкой для текущих LLM, то:

5 шагов = 77% успешности

10 шагов = 59% успешности

20 шагов = 36% успешности

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

Немного скажу об основных причинах галлюцинаций. Чаще всего это: или противоречия в исходных данных, или недостаточность исходных данных, в том числе и условная «недостаточность», о которой я говорил выше — когда необходимые «факты» в модели есть, но связать их между собой — контекста не хватает. С этим понятно, как бороться — добавлять нужные связи в контекст (пресловутый «промпт-инжиниринг», ага), но на этом пути нас поджидает засада в лице первой причины — противоречий. Помимо того, что противоречия могут быть (и есть, просто из-за объемов) в данных, на которых тренировалась модель, мы их можем вносить и своими промптами — просто ошибаясь, людям тоже свойственно ошибаться, знаете ли…

Но, что важно, этим проблемы не исчерпываются, глюки и ошибки нейросеть может выдать (хоть и реже) просто на ровном месте. Так что контроль, проверки и еще раз контроль. Своей головой.

Вариативность

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

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

Мусор на входе

Нейросети тренируются на данных из реального интернета, а не из идеального мира. Есть такое известное высказывание: «90 процентов чего угодно — ерунда» («закон Старджона» или «откровение Старджона»²). Можно, наверное, поспорить со столь мощным обобщением, но что касается программного кода — это похоже на правду. Именно на этом «чем угодно» и тренируются нейросети. Ну, и промпты тоже попадают в это множество.

И это еще без учета целенаправленного коммерческого или политического замусоривания и отравления источников.

Предустановки

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

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

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

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

Далее две проблемы, находящиеся по другую сторону экрана и клавиатуры.

Ожидания

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

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

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

Именно об этой проблеме я и говорил ранее в пункте о «безответственности пользователей».

Недооценка контекста

А вот этот пункт новый, оценить его получилось только с собственным опытом. Суть в том, что в обычном человеческом общении у нас всегда имеется огромное количество контекста, который в явном виде не то, что не проговаривается, но даже не подразумевается. Общаясь, скажем, с коллегой, мы имеем некоторое представление друг о друге (и о себе, кстати), о скиллах и бэкграунде, о других проектах и ресурсах, которые могут быть привлечены на проект (и насколько легко), смутное, но все-таки представление о дальнейших планах… И прочая, и прочая. И бо́льшая часть этого контекста никакого значения для решения конкретной задачи не имеет. Вот только из-за неявности мы не знаем, какая именно часть таки имеет значение.

К чему это приводит? А к тому, что формулируя задачу наивно, как бы мы формулировали ее человеку, мы даем нейросети недостаточно данных. И нейросеть эти пробелы додумывает. Пусть не совсем от балды, а как наиболее правдоподобные, исходя из тех данных, на которых она тренирована, но к нашим конкретным условиям нерелевантно.

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

Что же делать? Можно максимально подробно расписать все условия, но это: а) не гарантирует, что вы ничего не забудете; б) практически гарантирует, что вы напихаете в контекст много лишнего, а контекст, как неоднократно говорилось выше, не резиновый и не бесплатный; и в) чем больше вы пропишете, тем больше шансов, что где-то допустите противоречие.

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

Производные проблемы

Стоимость

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

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

А радикальным нейрооптимистам, пророчествующим о скором и неминуемом сращении LLM и «интернета вещей», придется подождать, как минимум, до строительства сферы Дайсона³).

Каша из версий

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

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

В принципе, отслеживая такие моменты и внося соответствующие указания в диалоге (или в системном промпте), можно с этим справиться, но это опять дополнительные трудозатраты и дополнительный расход контекста.

Накопление мусора

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

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

Мифология и тренды

Вайб-кодинг

Если кто не в курсе, вайб-кодинг — это когда вы описываете человеческим языком задачу, а нейросеть генерит весь (или почти весь) код. На первый взгляд, звучит слишком красиво, чтобы быть правдой, но… В интернете полно историй успеха на этом поприще, т.е. как минимум в некоторых случаях, это работает.

Что же с ним не так? Или всё так, и сбылась вековая мечта каждого продакт-менеджера — избавиться от человеческого фактора в лице разработчиков? Начнем с того, что под этим зонтичным маркетинговым термином объединяют сильно разные кейсы.

Профессиональный разработчик быстро накидал прототип, пример, PoC.

Оно работает, проверка концепции выполнена, прототип можно показывать (не разваливается сразу), развитие и поддержка изначально не предусмотрены по определению. Все, что не касается основной идеи, которая проверяется/демонстрируется, сделано максимально шаблонным способом.
Не-разработчкик сделал себе приложение, выполняющее нужную ему задачу.

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

Да, это тоже называют вайб-кодингом.

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

Почему-то во всех таких случаях автор продает не это приложение, а непосредственно LLM или услуги по внедрению, курсы по пользованию LLM и прочая… Кому ты веришь больше: настоящему гуру или собственным бесстыжим глазам?..

Короче, если стряхнуть маркетинговый булшит, то никакого вайба не останется. В сухом остатке имеем просто некоторый инструмент, который позволяет что-то делать быстрее или проще, но не меняет картину принципиально. Даже возможность, не имея навыков программирования, слепить какой-то работающий код — на самом деле совсем не нова — мода на nocode-платформы уже была и ничем особо не кончилась (равно как и появление когда-то RAD-инструментов). Другой вариант: делаем медленно, с увеличенной когнитивной нагрузкой, поскольку нужно думать и о разработке, и о «дрессировке» нейросети для разработки, и безо всяких гарантий, что работа будет вообще завершена. Ну, а ситуацию, когда мы пишем код сами, обращаясь к LLM только по отдельным вопросам как к консультанту, вайб-кодингом пока называть не принято.

Что же касается рассказов о сияющих перспективах (а так же пугалок), исходящих от заинтересованных лиц, следует их даже не делить на десять, а просто игнорировать, поскольку в современном пиаре чувство меры отсутствует полностью.

Промпт-инжиниринг

Новая «профессия» как бы народилась… Натурально уже ищут людей на соответствующие вакансии ~~(с десятилетним опытом)~~. У меня этот термин вызывает ассоциации с более старым — «YAML-разработчик» — но последний все-таки обычно употребляется в ироничном ключе.

Нет, конечно, навык четко и полно излагать, чего хочешь — вещь полезная, но опять же не новая. Отличия от навыков постановки задачи человекам не так уж велики, хотя некоторые и имеются — как я выше писал, нужно учитывать неявный контекст.

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

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

Короче, умение формулировать промпты — не профессия, а инструментальный навык, полезный в самых разных областях деятельности, но бессмысленный в сферической форме в вакууме.

Мы все умрем!™

Апокалиптические прогнозы о смерти профессий, как и следовало ожидать, оказались преждевременны.

Дело ведь не в том, что написание кода или текста — это какой-то рокет-сайнс, доступный только избранным. Дело в том, что реальный мир сложен, бизнес-системы и взаимоотношения между ними сложны, и программные системы современные тоже очень сложны. Отдельный человек для написания какого-то участка кода требуется не потому, что архитектор всей системы не способен этот код написать, а потому, что у архитектора хватает своих задач на своем уровне. Ресурс внимания не безграничен, и практика как раз показала, что LLM со своим окном контекста, как у золотой рыбки, не просто не превосходят человека, а существенно от него отстают. Но даже если (когда) они в этом плане человека догонят, революции не случится из-за других ограничений.

Что касается «контрпримеров» с массовыми сокращениями, надо смотреть каждый случай отдельно, причем с привлечением внутренней информации. Мы все прекрасно видели, как в последние годы сфера IT нещадно раздувалась, причем зачастую извращенными способами, когда главным преимуществом была физическая молодость и так называемые «софт-скиллы»… Сокращение же раздутых штатов и оптимизация процессов — вещи, придуманные не вчера и не в IT.

А вот прогнозы относительно трансформации профессий пока не оправдываются. Просто потому что новые навыки, как выясняется, не так уж и новы. Да, есть специфика, которую надо иметь в виду, но ничего революционного, ничего такого, что отменяло бы старые навыки и способы работы.

Польза

Ладно, хватит критики и пессимизма, давайте посмотрим, чем этот стакан наполовину полон. Реально LLM — это большой шаг, сопоставимый, наверное, с появлением общедоступного интернета. Так что дальше я изложу, как этим можно пользоваться (исходя из моего личного опыта), впрочем, об ограничениях тоже постараюсь не забыть.

В программировании

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

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

Пред-планирование и планирование

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

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

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

На этом этапе можно переходить к планированию и определении архитектуры решения.

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

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

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

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

Рефакторинг

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

Смежные области

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

Например, для меня одной из таких областей будет фронт-енд.

Использование LLM как консультанта позволяет сделать это что-то гораздо быстрее и качественнее. Главное — понимать ее ответы, хотя бы за несколько уточняющих итераций.

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

Самообучение

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

Не легче, поскольку когнитивная нагрузка — это суть любого обучения, а не побочка — но именно удобней.

Проблема белого листа и резиновая уточка

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

Есть «метод резиновой уточки» — попытаться объяснить проблему неодушевленному предмету (или домашнему животному), которого ты не будешь стесняться, и при этом, вербализируя собственно затык и обстоятельства его возникновения, упорядочиваешь картину в своей голове и приходишь к какому-то выводу, или, хотя бы, к пути решения.

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

Некоторые люди одушевляют машину и, следовательно, начинают ее стесняться и стремятся выглядеть в ее глазах как-то получше… Но, боюсь, этим людям и уточка с котом не слишком помогут…

Нужно только помнить, что ступор, вызванный переутомлением или выгоранием, такими средствами не лечится.

Критический разбор и поиск слабых мест

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

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

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

Технические аспекты

Здесь мы вступаем на зыбкую почву, так что оговорок и ограничений будем много. Как общее правило можно сформулировать следующее: Никогда не тянем в свою кодовую базу то, чего не понимаем! LLM легко генерирует код, но не дает никаких гарантий относительно него.

Пойдем от менее сомнительного к более.

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

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

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

Генерация тестов и встроенной документации. С одной стороны, это прекрасно работает как генерация шаблона текстов и документации. С другой — требует тщательной проверки, поскольку здесь у нас имеется переход от кода к смыслу этого кода, с чем LLM не всегда адекватно справляется.

В общем, способно изрядно ускорить работу, но без ручной проверки и корректировки в репозиторий не пускаем.

Генерация нетипового кода по детальному заданию. Здесь начинаются проблемы, и нужно быть крайне внимательным, разбирая и понимая все нюансы.

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

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

По этому поводу даже было интересное исследование (см. другую статью на Хабре⁴), которое показало некоторое замедление работы при использовании LLM. К самому исследованию нужно относиться тоже осторожно, не увлекаясь обобщениями, но прочитать статью стоит.

Еще из общих рекомендаций: не помешает ссылка на какой-то хороший (в плане стиля кода) пример, а также указание в инструкциях писать идиоматично для выбранного языка. На Ruby можно писать, как на бейсике, но читать эту лапшу из if-ов будет неприятно. Правда, чтобы понимать идиоматичный код, нужно самому неплохо знать язык…

В написании текстов

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

Тем не менее, извлечь пользу можно и в этом случае.

Белый лист

О проблеме белого листа я уже сказал в контексте программирования, в написании текстов она еще более выражена. LLM позволяет спокойно и не стесняясь обсудить разрозненные мысли и составить план текста, прояснить основные тезисы, обдумать композицию и так далее. Ну и просто самому погрузиться в контекст и начать писать.

Опять же: не машина составляет вам план, а вы составляете его, проконсультировавшись с машиной.

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

Поиск данных

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

Еще тут стоит отметить, что не все LLM одинаково полезны. Используем те, которые сразу выдают ссылки и вообще заточены под поиск, а не выдумывание источников.

Вычитка

И вот здесь LLM становятся практически незаменимым инструментом. Нет, машина не заменит редактора в издательском деле, как из-за огромного количества неявного контекста, так и, главное, из-за ответственности, но в плане саморедактуры (не путать с самоцензурой) — просто огромный профит. Даже просто вычитка другим человеком с незамыленным глазом всегда была полезна, а здесь мы еще и избавляемся от субъективности, личного отношения к тексту и автору.

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

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

Но мы можем попросить найти:

Логические нестыковки и внутренние противоречия;
Стилистические несоответствия разных частей текста;
Недостаточно ясные места;
И еще какие-то недостатки, которые хотим обнаружить до отправки текста читателю.

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

Тут, наверное, будет уместно сказать, как же я всем этим воспользовался при написании данного текста… Ну, во-первых, все планирование обошлось без консультаций с LLM. Во-вторых, я воспользовался Perplexity, чтобы найти одну из ссылок по описанию содержания, причем предварительно я поискал в гугле и непосредственно на Хабре, но недостаточно помнил ключевые слова. И в-третьих, при вычитке мне Grok рекомендовал повыкидывать многое, оставив практически только раздел «Практика» и минимум рассуждений в конце. Наверное, если бы я готовил текст для какого-то издания, а не для личного блога, я бы так и поступил, но блог я воспринимаю в том числе и как пространство «для потрепаться», поэтому не стал ничего резать. Вместо этого, наоборот, добавил данный комментарий.

Перевод

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

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

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

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

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

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

В «быту» и вообще

Если коротко:

Всегда перепроверяйте информацию, полученную от нейросети.
Никогда не определяйте нейросетью грибы!

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

Сформулирую несколько общих тезисов:

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

Но и тут может быть не все гладко. Например, мне как-то нейросети посоветовали на камере Canon EOS 77D воспользоваться кнопками, которые есть только на старших моделях… Тут и проблемы с версиями проявились, и конформность к пользователю — на самом деле задача не решалась на данной модели в принципе.
Спрашивать о каких-то быстро меняющихся вещах, типа погоды или курсов валют, довольно бессмысленно. Но можно спрашивать о сервисах, предоставляющих такую информацию в реальном времени.
Нейросети позволяют пошагово углубиться в какую-то тему посредством уточняющих вопросов.
LLM не является божественным кладезем абсолютного знания. Надежность любых сведений зависит от источника этих сведений, поэтому проверка источников обязательна, даже если вы не хотите или не можете полностью прочитать и оценить сам источник. Но даже надежные источники не застрахованы от ошибок и устаревания.
Поэтому при принятии серьезных решений, где вы рискуете деньгами или здоровьем, вам придется или углубиться в тему самому, или обратиться к специалисту (юристу, врачу и т.д.).
С географией и ориентацией в пространстве у LLM все плохо, мои попытки составить их посредством маршрут через несколько недалеко расположенных населенных пунктов никакого результата, кроме пары минут смеха, не дали. При этом маршрут был описан в деталях, типа «повернуть после моста с колодцем», вот только эти детали на местности не существуют… Ну и крюки на десятки километров — это запросто. К счастью, есть простые и более менее адекватные геоинформационные сервисы для этих целей.

Ну и еще раз про грибы. Я — активный пользователь iNaturalist, соответственно, представляю себе, на что способна его нейросеть в плане определения всего живого (это не LLM, надо понимать, это именно специализированная нейросеть computer vision). Это, судя по всему, лучшая нейросеть в плане распознавания объектов живой природы на фотографиях из того, что имеется на данный момент времени, она постоянно дотренировывается и совершенствуется. И в общем, результаты феноменально хороши. Однако я регулярно сталкиваюсь с наблюдениями, где нейросеть iNaturalist определяет бледную поганку как что-то съедобное. Да, грибы вообще сложная группа для чисто визуального определения, и ошибки в них понятны. Но надо это иметь в виду и не доверять вопросы жизни и смерти (собственной) никакой нейросети.

Размышления

Ну что ж… Пора покинуть скучную плоскость фактов и вернуться в чертоги чистого разума. Далее будут исключительно мои измышления, предположения и всякие теоретизирования.

Революция?

Так что, произошла технологическая революция с выходом LLM к массовому пользователю? И да, и нет. То есть: да — революция, но нет — еще не произошла. Мы еще в самом начале пути понимания, как эту технологию использовать. И маркетинговые хвалилки и пугалки не продвигают нас вперед, а скорее толкают куда-то вбок и назад.

Я тут не говорю про компьютерное зрение и прочие аналитические нейросети — с ними как раз все понятно, у них назначение и цель создания совпадают. Я именно про LLM, которые позволяют делать неочевидные изначально вещи. В этом есть некоторая магия — когда технология, построенная на языке, дает работать со смыслами.

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

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

Пузырь?

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

Вот это засовывание LLM везде (а еще засовывание букв «AI» в название) — это, конечно, пузырь, ситуация примерно такая же, как несколько лет назад, когда во все щели пихали блокчейн.

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

Направления развития

Тенденции

Какие тенденции есть уже сейчас? Ну, во-первых, разнообразная интеграция, встраивание во всевозможные программы. Да, зачастую это маркетинговый булшит, но есть (и будут появляться) и вполне рабочие идеи. Во-вторых, состыковка разных нейросетей между собой с центром на LLM. Сейчас это в основном вопросы ввода (распознавание речи и изображений).

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

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

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

Перспективы

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

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

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

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

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

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

AGI не будет

Ну и еще чего я совершенно не жду в обозримом будущем, так это создания AGI как искусственного интеллекта, обладающего самосознанием и способного к принятию решений.

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

Что, впрочем, не запрещает разработку все более сложных и точных имитаций человеческого мышления из комплексов разных нейросетей и алгоритмов. Просто то, что мы называем волей или самосознанием в них не зародится.
А во-вторых, он на самом-то деле никому и не нужен. Государства бы не отказались от идеального солдата, корпорации — от идеального работника… Но кому нужен идеальный профсоюзный лидер и идеальный сутяжник? Точнее, кто готов оплатить его разработку?

Искусственные же ограничения, как мы уже видим на существующих LLM, с одной стороны — потенциально обходятся, с другой — увеличивают вероятность галлюцинаций…

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

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

Итог

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

LLM работают и могут быть весьма полезны, но не решают всех задач и не заменяют человека (и не заменят).
Существуют серьезные ограничения на применимость.
Экстенсивное расширение применения LLM экономически неоправданно.
Работа с использованием LLM не требует принципиально новых навыков, скорее развития старых.
Вайб-кодинг — это маркетинговый булшит, а промпт-инженер — не профессия.
В программировании наибольшая польза возникает не в кодинге, а в планировании и ревью.
Генерация кода крайне ненадежна и как автоматический процесс не работает.
LLM не сокращают сложность и когнитивную нагрузку, хотя при правильном применении позволяют сконцентриваться на сути, а не на инструментарии.
Генерация текста, если речь идет о написании чего-то сущностного, не работает.
При этом в вычитке и переводах LLM дают огромный профит.
LLM может очень эффекктивно применяться при самообучении (но может наоборот — давать ложное ощущение понимания).
Полагаться на LLM в важных вопросах рискованно и просто опасно.
Мы еще только начинаем понимать области применимости LLM и генеративных сетей вообще.
Сейчас LLM пытаются прикрутить ко всему подряд, и это пузырь.
В дальнейшем предполагаю уклон в специализацию и локальность.
А также интеграцию специализированных нейросетей в сложные системы.

«Почему я не верю в ИИ-агентов в 2025 году, несмотря на то, что сам их разрабатываю», https://habr.com/ru/articles/950072/ ↩ ↩²
https://ru.wikipedia.org/wiki/Закон_Старджона ↩
https://ru.wikipedia.org/wiki/Сфера_Дайсона ↩
«Исследование METR: использование Cursor замедляет опытных разработчиков на 19%», https://habr.com/ru/articles/927072/ ↩