Технический вторник:Почему оркестровка является ключом к эффективному развертыванию агентов ИИ

Новичок в агентной оркестровке? Начните здесь .

Давайте посмотрим правде в глаза:агенты ИИ непросто создать или развернуть. Но как только они будут внедрены, эффект будет невероятным. Мне нравится слышать мнение клиентов UiPath, таких как Айнара Эчеандия Сагасти, руководитель отдела цифровых услуг в Lantik, которая «объединяет RPA, генеративный искусственный интеллект и агентные технологии, [чтобы сделать] государственные услуги более доступными, эффективными и ориентированными на граждан, чем когда-либо». На платформе UiPath Platform™ уже создано более 10 000 агентов искусственного интеллекта. Агенты могут повысить эффективность и прибыльность процессов, но им нужна сильная оркестрация, а также помощь автоматизации и людей в процессе.

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

1. Производительность и надежность агентов

Разработчики и пользователи часто называют ненадежность агентов ИИ препятствием для производства. Большие языковые модели (LLM) делают агентов гибкими и адаптируемыми, но это также приводит к противоречивым результатам. Это может помешать разработке и тестированию. Как выразился один инженер:"Мои агенты иногда работают идеально, а затем полностью терпят неудачу при одних и тех же входных данных. Нам нужны более эффективные способы моделирования крайних случаев и последовательного воспроизведения сбоев... мониторинг «дрейфа» агента с течением времени — настоящая головная боль».

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

Еще одна проблема — производительность базовых моделей ИИ. Большие модели могут быть ресурсоемкими или медленными, а модели меньшего размера могут работать не так хорошо. Найти правильный баланс непросто.

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

2. Контролируемое агентство и человек в курсе событий

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

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

С другой стороны, если ИИ слишком жестко контролируется или требует постоянной проверки, он не обеспечивает рентабельности инвестиций. Иногда агент может прерывать рабочие процессы или создавать больше усилий, чем экономить. Например, один разработчик объяснил, как кодирование Copilot снижает производительность, заставляя вносить исправления вручную:«Он что-то начинает, но не может закончить… Мне приходится отвлекать свое внимание на проверку и закрытие тегов, круглых скобок и т. д. Это нарушает мой поток, замедляет меня».

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

3. Вопросы стоимости и рентабельности инвестиций

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

Предприятия пытаются контролировать затраты с помощью таких методов, как оптимизация моделей и политика использования. Один пользователь описал внедрение кэширования для сокращения повторных вызовов и тщательный поиск высококачественных данных для повышения эффективности вывода. Другие сосредотачиваются на выборе правильной модели для работы:"Мне бы [хотелось] создать структуру, в которой я мог бы использовать подсказку... прогонять ее по всем различным моделям и [и] находить лучшую и дешевую. Сейчас мой ИИ-агент использует более 200 шаблонов подсказок, и их все тестирование и повторное тестирование обходятся дорого". В конечном итоге быстрое проектирование и экспериментирование с моделями влекут за собой реальные затраты.

Модели ценообразования поставщиков (за токен, за звонок и т. д.) также играют роль. Например, использование GPT-4 для всего может быть излишним, но использование более дешевой модели может снизить качество. Команды должны найти баланс, чтобы оправдать рентабельность инвестиций. Кроме того, руководство может поставить под сомнение бизнес-ценность агентских проектов, если они требуют значительных постоянных затрат на облачные услуги искусственного интеллекта или специализированную инфраструктуру. Без явных преимуществ (либо в увеличении доходов, либо в экономии средств от автоматизации) инвестиции будет трудно защитить. Таким образом, оптимизация затрат и демонстрация рентабельности инвестиций находятся в центре внимания:команды хотят «получить максимальную отдачу от вложенных средств» с помощью агентов ИИ, смешивая и сопоставляя модели, концентрируясь на наиболее ценных вариантах использования.

4. Проблемы управления, безопасности и конфиденциальности

Организации должны обеспечивать соблюдение правил безопасности, соответствия и этики для агентов ИИ, но это легче сказать, чем сделать. Конфиденциальность данных является главной проблемой:многие компании запрещают или ограничивают облачные службы искусственного интеллекта до тех пор, пока не будут уверены, что конфиденциальные данные не будут утечек. Один разработчик рассказал, что на их рабочем месте запрещены такие инструменты, как ChatGPT, из-за рисков интеллектуальной собственности:«Нет. Это считается слишком большим риском для интеллектуальной собственности, [опасаясь] что это может привести к утечке наших секретов или нарушению чьих-либо авторских прав». При использовании сторонних API-интерфейсов AI специалисты-практики беспокоятся о том, что данные клиентов могут быть случайно отправлены в эти службы.

Безопасность — еще одна проблема:автономные агенты представляют опасность, если их неправильно поместить в «песочницу». Есть сообщения о командах, добавляющих дополнительные меры безопасности поверх агентских платформ — например, «нам пришлось добавить [] уровень безопасности поверх… [и] использовать кэширование (Redis) для оптимизации затрат» при развертывании агента по привлечению потенциальных клиентов. В готовых решениях часто отсутствуют элементы управления безопасностью корпоративного уровня или управление затратами, и компаниям приходится использовать собственное управление. Кроме того, сложно гарантировать, что агенты соблюдают правила (GDPR, HIPAA и т. д.) и организационную политику, если структуры агентов не предусматривают механизмов контроля.

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

5. Трудности с развертыванием и масштабированием

Переход агента ИИ от проверки концепции к производству может вызвать множество проблем. Пользователи сообщают, что то, что работает в контролируемой демонстрации, часто не соответствует реальному масштабу, объему и сложности. Общие проблемы включают задержку и пропускную способность (агенты на базе LLM могут быть слишком медленными для приложений с высоким трафиком или приложений реального времени), а также эксплуатационные издержки, связанные с надежной работой системы. Как сказал Адриан Кребс, соучредитель и генеральный директор Kadoa:«Не имеет значения, используете ли вы структуру оркестровки, если основная проблема заключается в том, что агенты ИИ [являются] слишком медленными, слишком дорогими и слишком ненадежными». Командам часто приходится перепроектировать архитектуру для повышения эффективности — используя кэширование, замену моделей или упрощение логики агента — просто для удовлетворения требований к производительности.

Также существует проблема развертывания в различных средах (облако, локально, на периферийных устройствах) с сохранением согласованности. В условиях предприятия не все отделы захотят использовать одни и те же инструменты, что усложняет стандартизированное развертывание. Проблемы оперативного масштабирования, такие как мониторинг, ведение журналов и обновление агентов на местах, также недостаточно развиты. Один пользователь Reddit отметил, что даже базовая отладка может оказаться «кошмаром… журналы ошибок часто загадочны и не содержат четкого руководства по устранению неполадок». Это становится еще сложнее, когда задействовано много агентов. Все это может замедлить внедрение агентов. Даже крупные поставщики признали, что клиенты «только начинают» и значимые масштабные результаты все еще появляются.

6. Сложности многоагентной оркестровки

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

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

7. Проблемы совместимости и интеграции моделей

Ни один агент искусственного интеллекта не является доминирующим на рынке. Сегодня организации могут использовать OpenAI, завтра перейти на модель с открытым исходным кодом и интегрировать различные сторонние инструменты. Но совместимость и плавная интеграция являются серьезной проблемой. Интеграция инструментов и моделей часто требует специальных адаптеров или связующего кода. Например, подключение агента к собственной базе данных или внутреннему API может потребовать значительных усилий, если платформа не была разработана с учетом этого. Разработчики утверждают, что многие фреймворки «тяжелы» и исходят из допущений, которые не подходят для всех случаев использования:«К сожалению, многие из этих фреймворков довольно тяжелые, если вам нужны только основы».

И наоборот, «независимость от фреймворка» часто означает написание большого количества шаблонов с нуля. Пользователи хотят не изобретать велосипед, не зацикливаясь на этом. Один разработчик описал выбор более гибкой библиотеки специально для максимальной совместимости:«Я много пробовал… В конце концов я остановился на использовании [Instructor], потому что я мог быстро переключаться между LLM – как локальными/ОС, так и проприетарными – и я мог везде иметь один и тот же структурированный ввод/вывод». Это подчеркивает необходимость в агентах, которые позволяют легко заменять модели или услуги ИИ для удовлетворения растущих потребностей.

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

8. Проблемы привязки к поставщику и совместимости

Модели и платформы искусственного интеллекта быстро меняются. Многие команды хотят иметь лучшее в своем классе и опасаются, что выбор решения для ИИ-агента одного поставщика может лишить их гибкости в будущем. Существует множество агентских фреймворков, каждая из которых имеет свои собственные API и особенности. Один разработчик сравнил это с увлечением JavaScript-фреймворками:«Через несколько месяцев у нас, вероятно, будет версия «TODO-приложения» в 100 различных веб-фреймворках JS… Даже просто понять их все — огромная задача».

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

Возможности агентной оркестровки

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

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

<ли>

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

<ли>

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

<ли>

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

<ли>

Функциональная совместимость и избежание привязки:нейтральный уровень оркестрации позволяет командам подключать различные модели или сервисы ИИ по мере необходимости, не привязываясь к экосистеме одного поставщика. Это смягчает страх перед необходимостью все перестраивать, если вы смените провайдера. Как утверждал один инженер, цель состоит в том, чтобы конечные пользователи «не беспокоились о привязке к поставщику… чтобы системы искусственного интеллекта работали бесперебойно на разных платформах, а не запирали пользователей в экосистеме одного поставщика». Говоря на «общем языке» с несколькими серверными модулями искусственного интеллекта (OpenAI, Anthropic, модели с открытым исходным кодом и т. д.), уровень оркестрации гарантирует, что вы всегда сможете выбрать лучший инструмент для работы и действовать в случае изменения технологий или цен.

<ли>

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

<ли>

Оптимизация затрат и гибкость ресурсов. Независимая от поставщика платформа может динамически выбирать между различными моделями или маршрутами, чтобы минимизировать затраты и одновременно удовлетворить потребности в производительности. Например, он может использовать более дешевую локальную модель для простых запросов и вызывать более дорогой API только для сложных случаев — прозрачно для конечного пользователя. Он также может пакетировать запросы, кэшировать результаты или регулировать частоту запуска агента. Одна команда сообщила, что делала это вручную (добавляя кэширование и используя более дешевую модель для определенных задач); интеллектуальная платформа оркестрации могла бы автоматически выполнять такую ​​оптимизацию. Кроме того, не будучи привязанными к одному поставщику, организации могут воспользоваться преимуществами ценовой конкуренции — переключившись на более рентабельную услугу, если кто-то поднимет цены. Эта гибкость повышает рентабельность инвестиций, поскольку оркестрация гарантирует, что вы используете ресурсы наиболее эффективным способом («самая лучшая и дешевая» модель для каждого задания, по желанию пользователей).

Прочитайте «Полное руководство по агентной оркестровке».

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

<ли>

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

<ли>

Объединяет искусственный интеллект с людьми и роботами для достижения лучших результатов

<ли>

Объединяет многоагентную сложность в управляемую структуру

<ли>

Избегает ограничений одного поставщика

<ли>

Обеспечивает управление, необходимое для развертывания в масштабе предприятия.

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

Дальше: