Техдиректор Amazon призвал не спешить с ИИ и вспомнил про опыт

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

Такая осторожность выглядит неожиданно в устах человека, который более двадцати лет занимает пост технического директора Amazon и всегда отказывался принимать слово «невозможно». Рассказывая о закулисной истории облачных вычислений, Фогельс любит вспоминать фразу пионера вычислительной техники Грейс Хоппер о том, что разработчику нужно остерегаться установки «мы всегда делали именно так». Почему же человек, который постоянно призывает инженеров ломать шаблоны, теперь советует не торопиться с ИИ? Ответ, вероятно, кроется в истории одного сбоя базы данных.

Двенадцатого декабря 2004 года Amazon находился в разгаре рождественского сезона покупок. Покупатели, набравшие товаров на 25 долларов, получали бесплатную доставку, но времени на пересылку оставалось всё меньше, и заказ, сделанный слишком поздно, мог не успеть к празднику. Именно в этот день отказал общий диск, на котором работала клиентская база данных: пользователи не могли войти в систему и оформить заказ. По воспоминаниям Фогельса, сбой продолжался более двенадцати часов и обошёлся Amazon в миллионы долларов. Когда поставщик базы данных явился для разбора, технический директор ждал извинений, но услышал: «Вам следовало лучше тестировать». Сначала это возмутило его, однако позже он признал, что масштаб Amazon давно вышел за рамки, на которые было рассчитано коммерческое программное обеспечение, и спорить с поставщиком бессмысленно — следующего сбоя это не предотвратит.

Тогда команда задалась более фундаментальным вопросом: как Amazon на самом деле использует базы данных? Выяснилось, что примерно в 70 процентах случаев реляционные базы применялись для доступа по типу «ключ — значение». Для корзины покупок системе достаточно было по идентификатору пользователя достать нужную корзину, а не вытаскивать корзины всех клиентов ради сложного запроса. Отталкиваясь от реальных сценариев доступа, инженеры построили хранилище «ключ — значение» под названием Dynamo, ставшее предшественником DynamoDB. Эта история легко проецируется на сегодняшний день: раньше реляционная база была тем самым тяжёлым молотком, которым колотили по любой задаче с данными, а теперь таким же универсальным молотком рискует стать большая языковая модель.

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

Когда разговор заходит о принципиальных изменениях, которые принесли облачные вычисления, Фогельс особенно выделяет смену экономической модели. Раньше, покупая корпоративное ПО, компания подписывала контракт на пять или десять лет: менеджер с трудом представлял потребности следующего года, но деньги приходилось платить вперёд. Фогельс сравнивает это с посетителем ресторана, который сразу оставляет тысячу долларов, а если не доел — возврата не будет. Облака связали объём потребления ресурсов с оплатой, и «сжатие» инфраструктуры обрело практический смысл: ночью, когда пользователей мало, ненужные ресурсы можно отключить. Затраты наконец вошли в архитектурные обсуждения, а бизнес-подразделения должны отвечать, сколько действительно стоит та или иная возможность. В эпоху ИИ к этому счёту добавились новые статьи.

Например, на вопрос, почему для интеллектуальных агентов забывание стало важной инженерной проблемой, Фогельс ответил прямо: если агент перед каждой задачей сканирует всё, что знает, накладные расходы становятся огромными, и разработчикам нужно придумать, как оставить только действительно важное для задачи. Он также отметил, что некоторые инструменты программирования при перезапуске заново загружают содержимое проекта: вчера пользователь уже заплатил за эту подготовку, а сегодня платит снова. Механизм памяти между сессиями Kiro как раз призван сократить такую повторную работу. Поэтому помимо того, насколько модель умна, разработчику приходится спрашивать, сколько бесполезных действий она повторяет ради выполнения одной задачи. Это же объясняет, почему Фогельс готов говорить о меньших моделях и открытых моделях вроде DeepSeek, Qwen и Kimi: по его наблюдениям, некоторые клиенты после серии экспериментов обнаружили, что небольшие модели уже закрывают их потребности, а стоят заметно дешевле. Что использовать, как использовать и сколько за это платить — эти старые вопросы никуда не исчезают и в эпоху ИИ.

Даже если компания посчитала расходы, перед командой разработчиков встаёт другая проблема. Чат-бот выдаёт текст, и человек может прочитать его и решить, что делать. Агент же действует от имени пользователя: меняет маршрут, вызывает инструменты, запускает программы. Если модель даёт неверный ответ, ошибка может превратиться в реальные последствия по ходу выполнения. Фогельс признаётся, что охотно доверил бы агенту перебронировать билет, но требует, чтобы система знала, как действовать, помнила его предпочтения и при этом была ограничена рамками. Эта приверженность границам проявилась и в истории Nitro: ранние облака опирались на виртуализацию, когда один физический сервер делился между несколькими пользователями, но программный слой, управлявший виртуальными машинами, сетью и хранилищем, сам потреблял ресурсы и со временем мог стать узким местом. В AWS построили Nitro, переложив значительную часть сетевых и дисковых функций на специализированное оборудование и убрав полноценное Linux-окружение dom0, что сняло узкое место по производительности и сократило поверхность атаки.

У Nitro есть интересный принцип — «пассивная коммуникация»: гипервизор ждёт команды от контроллера Nitro, а если тот сам инициирует обращение, это поведение, которого в нормальном процессе быть не должно, и платформа может вывести подозрительную систему из обслуживания для расследования. По этой логике легко понять и требования Фогельса к агентам: что пользователь разрешает системе, должно быть оговорено заранее. Он приводит простой пример: пользователь может указать, что агент не должен тратить больше ста долларов в день, а при превышении требуется участие человека. По его словам, Amazon спроектировала для агентов механизм исполнения правил, который проверяет доступ к инструментам и запуск скриптов, ограничивая действия явно выданными полномочиями: даже если модель считает, что дело стоит сделать, исполнительная система проверит, есть ли на это право. Не тормозят ли такие ограничения эффективность агента? Отвечая, Фогельс сначала говорит об ответственности: «Ты это построил — ты за это отвечаешь». Разработчик агента должен контролировать его, а какие действия предприняла система и не вышла ли она за границы, в конечном счёте отвечает человек.

Доверие к ИИ Фогельс вписывает в опыт распределённых систем: инженеры никогда не исходят из того, что каждый компонент всегда надёжен, поэтому нужны репликация, изоляция и механизмы отказоустойчивости; лишь настороженность к отдельным компонентам позволяет доверять системе в целом. Правда, чтобы защитные механизмы стали доступными клиентам и не замедляли задачи заметно, инженерам приходится идти на компромиссы. Lambda столкнулась с похожей трудностью: в своё время WeTransfer, обрабатывая файлы, загруженные в S3, держал парк вычислительных инстансов, которые просто ждали появления новых файлов, и клиент содержал целую инфраструктуру ради ожидания события. AWS решила взять эту работу на себя, позволив клиенту присылать код и платить за время выполнения и память, но эффективно реализовать это внизу оказалось непросто: использовавшиеся для изоляции клиентов виртуальные машины были слишком велики для функций и дороги, и лишь после того, как изоляцию сделали лёгкими микровиртуальными машинами на базе Firecracker, утилизация ресурсов выросла. Затем пришлось заняться холодным стартом: перед выполнением функции система готовит окружение, код и зависимости, а SnapStart сокращает эти издержки, сохраняя снимок уже инициализированного окружения. Клиент видит лишь вызов функции, а команда инженеров продолжает шлифовать изоляцию, распределение ресурсов, запуск и сеть — Фогельс называет это «невидимой инженерной инновацией».

Когда агенты начинают писать код, эти вопросы возвращаются к самой команде разработчиков. О занятости младших инженеров Фогельс говорит, что Amazon нанимает их столько же, сколько и раньше, а затем переводит разговор на обучение новичков: выпускник, попавший в команду S3, может столкнуться с кодом двадцатилетней давности, и школа вряд ли научит его понимать такую систему и сотрудничать с теми, кто её поддерживает. Поэтому он ценит любопытство, способность учиться и опыт участия в открытых проектах: если новичок работал в открытом сообществе, значит, его код смотрели другие и ему приходилось решать проблемы вместе с людьми. ИИ может объяснить новичку правила команды и сэкономить время опытных инженеров, а в Kiro Фогельс подчёркивает подход, движимый спецификацией: разработчик сначала описывает требования, архитектуру и правила разработки, а затем поручает работу системе. Однако скорость генерации кода выросла, а скорость его понимания и проверки у команды не обязательно поспевает. Фогельс упоминает понятие, на которое разработчикам стоит обратить внимание, — «долг валидации»: раньше, чтобы уложиться в сроки, разработчики шли на компромиссы и записывали, что потом исправят, накапливая технический долг, а теперь часть сгенерированного ИИ кода ещё не проверена, и команда накапливает другой долг. Сдвинутый на миллиметры элемент интерфейса и код, способный раскрыть клиентские данные, имеют совершенно разные последствия, поэтому проверки нужно расставлять по риску и вкладывать силы туда, где валидация нужнее всего.

По логике Фогельса, команде легко нарастить объём кода, но способность понимать этот код и отвечать за его последствия требует отдельного измерения; иначе сэкономленное сегодня время придётся потратить завтра на разбор и переделку. Вот почему он настаивает, чтобы младшие инженеры читали код и вместе с опытными коллегами проводили ревью и обсуждения: инструмент может объяснить знание, но суждение, необходимое человеку перед конкретной задачей, накапливается постепенно. «У опыта нет алгоритма сжатия», — говорит Фогельс, и эта фраза хорошо отвечает на тревогу разработчиков. Впрочем, говоря о поездке в Китай, он приводит пример, который делает его оптимистичнее в отношении применения ИИ: он потратил немало времени, рассказывая о визите в организацию «Дами хэ Сяоми», которая оказывает поддержку детям с расстройством аутистического спектра, синдромом дефицита внимания и гиперактивности и другими особенностями развития. По его словам, организация использует ИИ для анализа учебных записей, наблюдения за прогрессом детей и подготовки рекомендаций для реабилитологов, а специалисты уже с профессиональным суждением решают, какие предложения принять. Его впечатлило то, что ИИ сократил для специалистов объём рутинной работы и позволил им больше сил отдавать детям и семьям.

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