Привет, гики и гикессы! Сегодня у нас на повестке дня – наболевшая тема AI-агентов. Казалось бы, вот оно, будущее автоматизации, но не тут-то было. По данным VentureBeat, компании столкнулись с серьезной проблемой: надежностью.
AI-агенты входят в эру перестройки
После первой волны безумного внедрения AI-агентов в производственные процессы, организации обнаружили, что LLM (большие языковые модели) сами по себе не гарантируют успех. Долгосрочные AI-воркфлоу должны выдерживать сбои, сохранять состояние, восстанавливаться после неудач, управлять затратами на вывод и координировать работу с API, инструментами и корпоративными системами.
Preeti Somal, старший вице-президент по инженерии в Temporal Technologies, заявила на последнем мероприятии AI Impact Series в Нью-Йорке: "У нас есть много клиентов, которые приходят к нам, когда строят версию 2.0 того же агента. Им нужно было двигаться очень быстро, но они не позаботились о сантехнике. Все ломается и горит, и тогда они возвращаются к перестройке с надежным фундаментом".
Для компании Temporal, занимающейся оркестровкой рабочих процессов, чья инфраструктура предшествует нынешней волне agentic AI, этот сдвиг отражает более широкое осознание предприятиями: производственные AI-системы требуют устойчивого исполнения, управления состоянием, видимости рабочих процессов и механизмов для восстановления в случае сбоя моделей или подчиненных систем. Agentic AI зарядил знакомые инженерные проблемы.
"Эти шаблоны не обязательно новы, - сказала Сомал. - AI просто заряжает их".
Agentic системы добавляют дополнительную сложность, потому что они часто включают в себя длительные, многоэтапные процессы, охватывающие несколько служб, моделей, API и инструментов. Один рабочий процесс может вызывать несколько больших языковых моделей, получать доступ к системам поиска, запускать внешние приложения и управлять состоянием в течение часов или дней. Инженерные вопросы, по словам Сомала, часто возникают только после развертывания.
"Люди будут писать агентов, но не думали о том, что произойдет, если агент выйдет из строя, - сказала она. - Нужно ли мне будет запускать весь поток агента снова?" Для предприятий, работающих в условиях ограничений по затратам, ответ имеет значение. Перезапуск рабочих процессов после сбоев может увеличить расходы на вывод, увеличить задержку и создать плохой опыт для клиентов.
Сомал сравнила нынешний момент с более ранним периодом внедрения корпоративных облачных технологий, когда организации сразу перешли к миграции рабочих нагрузок, прежде чем подумать о том, что им нужно перепроектировать базовые архитектуры, если они хотят, чтобы эти рабочие нагрузки выдержали долгосрочную перспективу.
"Эта спешка с AI в мире, где вы даже не модернизировали свое приложение, немного напоминает мне тот lift-and-shift, который произошел в облаке, - сказала она. - Все поняли, что вы тратите больше денег на облако, и мы не получили там никакой выгоды".
Почему долго работающие агенты требуют новой архитектуры
Корпоративные рабочие процессы все чаще включают агентов, выполняющих действия в течение длительных периодов времени, иногда охватывающих много часов при взаимодействии с инструментами и системами. Проблемы надежности усугубляются, когда рабочие процессы сохраняются во времени, и это влияет как на состояние, так и на память, две идеи, которые часто рассматриваются взаимозаменяемо в разговорах об AI.
Состояние касается выполнения рабочего процесса. Оно включает в себя то, где находится агент в процессе, какие действия уже выполнены и где следует возобновить восстановление после сбоя. Память или контекст фиксирует информацию, которую агент переносит через взаимодействия или задачи.
"Состояние агента связано с тем, какой шаг и какие действия были выполнены, и если что-то выйдет из строя, откуда вы хотите восстановиться, в отличие от контекста и памяти", - пояснила Сомал. Это различие становится все более важным, когда предприятия начинают выходить за рамки простых взаимодействий с чат-ботами и переходят к более длительным бизнес-процессам. Сомал привела пример из здравоохранения с участием клиента Abridge, где рабочие процессы обрабатывают посещения врачей через несколько этапов, включая обработку аудио, суммирование, вызовы моделей и генерацию после посещения.
"В этом потоке есть не только одна часть, - сказала Сомал. - Взятие видео и нарезка его, взятие сводок, вызов LLM, создание сводки после посещения - все это оркеструется". Для предприятий это означает, что успешные агенты все больше зависят от систем, которые могут выдерживать перебои, координировать работу между службами и поддерживать непрерывность во времени.
Появление детерминированного скелета
Полезной основой для проектирования корпоративного AI является детерминированный скелет, сказала Сомал, именно так они думают о роли Temporal. "Он обозначает путь, по которому вы хотите идти, - сказала она. "Он вызывает мозг, но если мозг не отвечает, он вызовет его снова. Если мозг отвечает, но следующий шаг не удастся, он подхватит с того места, где произошел сбой". В этом случае языковая модель выступает в качестве вероятностной системы, производящей переменные результаты, в то время как программное обеспечение для оркестровки поддерживает надежность выполнения вокруг нее. И эта концепция имеет значение, потому что корпоративные системы все чаще требуют согласованности, даже когда модели остаются недетерминированными. Рабочий процесс закупок, сводка по здравоохранению, эскалация поддержки клиентов или процесс соответствия требованиям не могут просто молча выйти из строя, потому что истекло время вызова модели или произошел сбой внешней зависимости.
"Больше всего вас волнует то, чтобы вы могли восстановиться и чтобы вы не платили налог на токены, если что-то пойдет не так", - сказала Сомал.
Надежность, видимость и экономика расходов на токены
Поскольку руководители предприятий оценивают рентабельность инвестиций в AI, видимость затрат становится все более важной проблемой. Долго работающие агенты часто совершают несколько вызовов моделей в сложных рабочих процессах, что может создать непрозрачные схемы расходов. Сомал описала одно из операционных преимуществ оркестровки как видимость того, где накапливаются затраты. Поскольку рабочие процессы можно наблюдать шаг за шагом, команды могут видеть, где потребляются токены в процессе агента.
"У вас есть видимость всего этого потока в одном окне, - сказала она. - Теперь вы можете видеть, где вы тратите токены в агенте, который состоит из нескольких шагов и вызывает несколько разных систем". Восстановление рабочего процесса также определяет экономическую эффективность. Без надежной оркестровки сбой на поздней стадии может заставить организации перезапустить весь процесс с самого начала, включая все предыдущие вызовы моделей. Сомал сказала, что системы, разработанные с учетом восстановления, могут возобновить выполнение с точки прерывания.
"Вы подхватываете с того места, где произошел сбой, - сказала она. - Мы экономим вам затраты на повторный запуск агента с первого шага". Предприятиям необходимо создать pa