Леонид Ильич Брежнев написал собственноручно три книги — «Мало земли», «Возражение» и «Цели нет» © Бородатый советский анекдот
..
— Пустите нас в Скрытые Столетия, — прервал её Харлан, — и мы всё исправим. Смогли же мы в освоенных нами Столетиях добиться наивысшего блага…
— Наивысшего блага? — насмешливо переспросила Нойс. — А что это такое? Кто отвечает на этот вопрос? Ваши Счётные машины, ваши Анализаторы, ваш Кибермозг? Но кто настраивает машины? Кто вкладывает в них программу? Кто задаёт им оценки? Ведь даже Кибермозг не обладает большим прозрением, чем человек, он только быстрее решает проблемы, только быстрее! А что является благом с точки зрения Вечности? Я отвечу тебе. Безопасность. И ещё раз Безопасность! Осторожность! Умеренность! Ничего сверх меры. Никакого риска без стопроцентной уверенности в успехе. © Конец Вечности
Генеративный ИИ демонстрирует знатный прогресс в последнее время — даже вроде как решил одну из задач тысячелетия, правда, с весьма существенными оговорками. Оставим в стороне вопросы финансовые, насколько устойчива вся схема финансирования этих компаний.
Хотелось бы поговорить в этой новости о проблеме, которую я бы условно назвал «Не бывает плохих учеников, только плохие учителя». Смысл в том, что вычислительные мощности, используемые ИИ, модели и архитектуры — это все, конечно, замечательно, но не имеет смысла без правильного целеполагания, закладываемого в системы. Как гласит старая немецкая поговорка, хромой, бредущий в правильном направлении, обгонит всадника, скачущего не туда.
Данная статья о том, что если компании, эксплуатирующие ИИ, не ставят цели улучшения пользовательского ПО, то все усилия по строительству дата‑центров, производству чипов и памяти, совершенствованию моделей — не приведут к улучшению этого самого ПО. По факту эта статья является отсылкой к классической статье «Почему новый дизайн Gmail такой медленный?», написанной задолго до прихода генеративного ИИ в массы.
Брюзжание старика, или зачем ломать то, что работало?
Здесь приводятся примеры из экосистемы Google, но это не претензии конкретно к Google и я не испытываю ненависти к этой компании. Она выбрана в качестве примера по двум причинам: а) как раз она располагает ресурсами и весьма квалифицированными кадрами для исправления этих косяков без всякого ИИ; б) именно Google сделала возможным генеративный ИИ с помощью эпохальной статьи — правда, сама не смогла вовремя этим потенциалом воспользоваться (опять же к вопросу о целеполагании).
Пример 1. У меня на телефоне стоит почтовик Gmail (что как бы естественно для Андроида). С определенного момента в нем сломалась система уведомлений. Точнее, как. Когда приходит очередное письмо, мне всплывает уведомление с заголовком и частью текста, и кнопками типа «Archive» и «Mark as read». Так вот, с определенного момента (где‑то года два назад) кнопка Archive сломалась. Т.е. на нее нажимаешь, уведомление меняет статус на «Archived», но остается висеть в уведомлениях. Более того, если зайти в приложение Gmail, то там письмо по прежнему в непрочитанных и ни в какой архив не ушло. Приходится нажимать там уже на удаление, и оно исчезает. Происходит такое поведение 50 на 50 — иногда нормально отправляет в архив из уведомления, иногда остается.
Я код почтовика не видел, но готов предположить, что уведомления, когда нажимаешь на кнопку, отсылают сообщение в какую‑то очередь на обработку, и она должна дернуть в ответ callback. Но периодически сообщения теряются в очереди, или callback не вызывается. Типичные проблемы консенсуса в распределенных системах.
Сломалось это, как я уже сказал, где‑то два года назад. С тех пор так и не исправили, проверено на двух разных телефонах от разных производителей и с разными версиями Андроида. Кстати, есть подозрения, что это как‑то связано с gemini — посмотрите хотя бы это обращение в поддержку Gmail. Что характерно, никакой реакции от команды не последовало. А потому не последовало, что нет такой цели — сделать приложение как можно лучше и удобнее. Есть лишь «Сделать достаточно рабочим, чтобы пользователь от нас не сбежал» (хотя пользователю на андроиде в принципе очень сложно избавиться от экосистемы Google). Для сравнения, почтовик Яндекс таким не страдает. Он не идеален, но кто из нас идеален. Но по крайней мере у него нечасто встречается «Оно работало, а с очередным обновлением сломалось».
Пример 2. Google Pay. Если предыдущий пример просто раздражает (удалить письмо таки можно, просто надо сделать больше телодвижений), то данный пример уже конкретно мешает по жизни. Есть у Google Pay/Wallet одна противная черта — он периодически перестает работать после обновлений. То он не распознает NFC модуль, то платежные терминалы перестают принимать его — примеры раз, два. Чаще всего решается либо полной перезагрузкой телефона, очисткой и удалением приложения. Либо (что хуже), приходится ждать, когда заработает после очередного обновления (а когда оно выйдет, неясно). Мне однажды так пришлось ждать месяц.
Я понимаю, когда выкатывают новое приложение, и оно не совсем стыкуется с устройством, но здесь приложению уже много лет, да и модуль NFC в моих телефонах не менялся, стандарт взаимодействия с ним тоже не меняется. Как можно сломать что‑нибудь здесь?
C точки зрения разработки ПО, такого не должно происходить. Вам нужно, во‑первых, иметь обширный набор тестов, покрывающий спецификацию взаимодействия с NFC‑модулями. Во‑вторых, иметь на руках основную линейку телефонов, на которые выкатывать новую версию перед выходом в свет и проверять ее. Обратите внимание, речь в обращениях в поддержку идет не о каких‑то древних моделях или экзотических сборках телефонов из подпольных китайских цехов, а о Google Pixel 9 (!) и Samsung. Если Вам лень проверить это даже для собственной линейки телефонов, то чего Вы ждете от ИИ, обученного Вами же?
Пример 3. Ну это просто песня последних недели‑двух. У меня сломался на телефоне каст YouTube на мой телевизор. Т.е. теперь, когда я его включаю, он подключается через раз. Что хуже, когда ролик заканчивается, и я включаю новый, этот новый ролик не транслируется автоматом на ТВ (как было раньше)! Нет, он запускается на моем телефоне, и мне нужно тыкать в приложении YouTube и жать на трансляцию. После каждого ролика. И это не то что бы моя личная проблема — тред в реддите. Кстати, сломали, по ходу, не только для Android, но и для iOS.
Т.е. никто не тестировал вообще ничего. Да и некогда нам, мы заняты другим... Кстати, чем другим?
Какая выгода от ИИ?
Ключевая проблема с генеративным ИИ сейчас четко выражена COO Uber — пока что повышение производительности от ИИ не удается отследить — нет четкого ROI. Забудем пока про программистов как таковых, чья производительность типа как должна повыситься в 10 раз. Зададим два вопроса насчет внедрения ИИ:
Генеративный ИИ стартовал в конце 2022 года (привет, ChatGPT). Сейчас на дворе конец 2026. Какие прорывные программы появились за это время — ну там что‑то типа Google Search, или Карты, или Uber? Или игры какие‑нибудь? И даже если такие примеры есть, они действительно оправдывают затраты? Т.е. вместо того, чтобы обучать кучу моделей и тратиться на строительство дата‑центров, не дешевле было бы доплачивать программистам за разработку, как и раньше?
Допустим, новых прорывных программ, полезных для пользователей не появилось, ладно. Но хотя бы благодаря ИИ старые программы работают лучше? Меньше багов, быстрее откликаются? Должен же был ИИ помочь с этим, раз он разгружает программистов?
Вернемся еще раз к задаче Навье‑Стокса, которую OpenAI решил (или не решил, или грамотно распорядился идеями двух математиков, не суть важно). Мы сейчас не о самом решении, а о том, что они выбирают в качестве цели. Как я понял, на решение задачи было брошено 100 тысяч одних курьеров агентов и затрачено огромное количество вычислительных мощностей. Оно и понятно — ведь заголовок в газете «Модель от OpenAI решила одну из задач тысячелетия» очень располагает к тебе потенциальных инвесторов. Представьте вместо него заголовок «Модель от OpenAI исправила баг с зависанием кнопки Archive в Gmail». Как‑то не очень звучит. Хотя польза от второго для пользователей больше.
Не хочу показаться приземленным циником. Я к тому, что у нас уже есть решение одной из задач тысячелетия — 20 с лишним лет назад Григорий Перельман доказал гипотезу Пуанкаре. Ну и как — сильно улучшилась чья‑то жизнь от этого? Да не особо. Наука — вещь такая, особенно математика. Очень многие открытия в ней неясно как применить, причем зачастую на протяжении даже не десятилетий, а столетий. Например, теория чисел и разные интересные факты насчет простых чисел на протяжении веков не имели практической отдачи, до появления современной криптографии. Однако в науке нельзя отделить мух от котлет, то есть выделить чисто прикладные направления и вкладываться в них. Можно только сократить финансирование в общем и загубить фундаментальные исследования вместе с прикладными.
Однако OpenAI — это не кафедра математики при вузе, финансируемая из госбюджета в интересах всего общества в целом (пусть и без прибыли). Это все‑таки частная компания. Ее решение задачи Навье‑Стокса, при всей шумихе в прессе, не принесет ей никакой ощутимой прибыли в обозримом будущем. Поскольку инженеры еще должны понять, как использовать это решение на практике, а это может быть очень нескоро. Грубо говоря — дедлайн по финансовым обязательствам OpenAI может наступить куда раньше, чем отдача от решения задачи Навье‑Стокса.
Отсутствие практической отдачи от моделей вызвано еще одним обстоятельством — материалом для обучения моделей.
Мы все учились понемногу чему‑нибудь и как‑нибудь...
Я начал этот блог со статьи про инфляцию программного обеспечения. Исторически сложилось так, что в конце 80-х и начале 90-х те, кто фокусировался на оптимизации ПО до последнего байта и максимальной утилизации каждого такта процессора, проиграли в конкурентной гонке тем, кто делал ПО не максимально быстрым и эффективным, а достаточно шустро выпускал его на рынке в расчете на то, что аппаратные мощности ПК в то время росли семимильными шагами, и приложение, которое работает не очень быстро сейчас, начнет летать через год на новом ПК пользователя.
Эта война и ее исход имели серьезные последствия для всей инженерии ПО в целом. Одно из неожиданных следствий — это поведение языковых моделей. На чем они обучены? Есть, разумеется, отличный пласт литературы, как писать программы, чтобы летали даже на старом 286-м. Вот отличный цикл статей на Хабре для примера.
Проблема заключается в том, что данные знания обычно фокусируются в ряде весьма специфических отраслей как‑то: встраиваемые системы, компьютерная графика в играх и так далее. Т.е. там, где без этого чисто физически не обойдешься. Мало того, что зачастую эти знания сфокусированы в корпоративной документации и не публикуются в нормальных учебниках (попробуйте с ходу найти учебник, где объяснялось бы, как программировать микроконтроллеры в автомобилях или самолетах). Сам объем публично доступной информации по этому поводу резко уступает массиву информации, написанному в совершенно другой парадигме (даже парадигмах).
Последние 20–30 лет протекают в ПО под лозунгом «Move fast and break things». Микросервисы, облачные платформы, и так далее. Все это базируется на разных критериях успеха, но надежность и скорость ПО к ним не относятся.
Я не имею доступа к внутренней кухне OpenAI/Anthropic и не знаю, какие задачи ставятся перед разработчиками моделей. Но вряд ли эта задача звучит так «А натренируй‑ка модель так, чтобы она по просьбе пользователя делала современные приложения, но так, чтобы они летали на смартфонах с двумя ядрами и 2 Гбайтами оперативки». Однако даже если предположить, что такую цель перед ними реально ставят — вряд ли создатели моделей смогут найти достаточно обучающей документации именно в таком стиле.
А дальше замкнутый цикл — раньше джун, написавший дико неоптимизированный код, работающий за O(N^3), в теории получал по шапке от сеньора во время Code Review и постепенно начинал понимать, что так делать не надо. Сейчас же языковая модель радостно по запросу джуна сделает жутко неоптимизированный код. Она невиновата, ее так учили. Этот код попадает на гитхаб еще, если компания не чурается Open Source, и служит материалом для обучения новых моделей.
Я, кстати, с оптимизмом отношусь к языковым моделям. Например, я считаю, что ее вполне можно заставить сделать код быстрее, если, скажем, не давать ей доступа к тестом, и поставить в этих тестах жесткие проверки перформансов. Главное, чтобы модель не могла, видя, что тест падает, потому что 1000 вызовов метода не уложилась в одну секунду, поправить сам тест. Тогда, по идее, получая постоянный отклик, она может написать код, который и по памяти будет укладываться, и по времени. Другой вопрос — как часто вы видели использование LLM в таком контексте? Чтобы заставить Claude или Cursor писать код таким образом, надо самому в этом разбираться и провести очень серьезную подготовительную работу по контексту.
Сделать быстрее — можно, а зачем?
На вопрос «Сделает ли ИИ разработку ПО лучше?» ответ неутешительный. Ведь руководители крупных компаний не ставили задачи по оптимизации кода или ui/ux в течение минимум 10 лет до появления генеративного ИИ в 2022. Если они не делали этого до прихода ИИ, почему кто‑то решил, что такая цель появится сейчас?
И ладно бы, если программы просто не улучшались. Так ведь из‑за модных парадигм вайб‑кодинга и сокращений штата айтишников под этим соусом мы еще и получаем ухудшение уже имеющихся продуктов. Google тут один из ярких примеров, но это вообще тренд индустрии, даже получивший собственное название — Enshittification.
Так что, даже если мы и получим AGI, автоматического улучшения качества жизни в плане использования ПО это не принесет, если не прилагать определенных усилий. В конце концов, менеджеры и программисты многих компаний и так обладают естественным интеллектом, но почему‑то проблемы пользователей не спешат решить. Если естественному интеллекту нет до Вас дела, то почему искусственному должно быть не все равно?
