Они обещали нам агентов, но все, что мы получили, – статические цепочки

Весной 2023 года мир возбудился вокруг появления агентов, основанных на LLM. Мощные демонстрации, такие как AutoGPT и BabyAGI, продемонстрировали потенциал LLM, работающих в цикле, выбирающих следующее действие, наблюдая за результатами и выбирающих следующее действие, шаг за шагом (также известный как фреймворк ReACT). Этот новый метод должен был обеспечить работу агентов, которые автономно и универсально выполняют многоступенчатые задачи. Дайте им цель и набор инструментов, и они займутся остальным. К концу 2024 года ландшафт будет полон агентов и фреймворков для построения агентов. Но как они соответствуют обещаниям?

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

Итак, как строятся агенты в корпоративной среде сегодня? Для случаев, которые требуют более чем несколько инструментов и несколько шагов (например, разговорный RAG), строители агентов в основном отказались от динамического и автономного обещания ReACT в пользу методов, которые сильно полагаются на статические цепочки – создание предопределенных цепочек, предназначенных для решения конкретной задачи. Этот подход напоминает традиционное программное обеспечение и далек от агентского обещания ReACT. Он обеспечивает более высокие уровни контроля и надежности, но лишен автономии и гибкости. Решения, поэтому, интенсивно требуют разработки, узкие по применению и слишком жесткие, чтобы решить высокие уровни вариации во входном пространстве и окружающей среде.

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

Этот компромисс можно представить в следующей графике:

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

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

Но сначала, что такое “планирование”? Под “планированием” мы понимаем способность явно моделировать альтернативные курсы действий, которые приводят к желаемому результату, и эффективно исследовать и использовать эти альтернативы под бюджетными ограничениями. Планирование должно проводиться как на макро-, так и на микроуровне. Макроплан разбивает задачу на зависимые и независимые шаги, которые должны быть выполнены для достижения желаемого результата. Часто упускается из виду необходимость микропланирования, направленного на гарантию желаемых результатов на уровне шага. Существует много доступных стратегий для повышения надежности и достижения гарантий на уровне отдельного шага путем использования большего количества вычислений во время вывода. Например, можно перефразировать запросы семантического поиска несколько раз, можно получить больше контекста для данного запроса, можно использовать более крупную модель и можно получить больше выводов из LLM – все это приводит к получению более результатов, удовлетворяющих требованиям, из которых можно выбрать лучший. Хороший микропланировщик может эффективно использовать вычисления во время вывода, чтобы достичь лучших результатов под заданным бюджетом вычислений и задержки. Чтобы масштабировать инвестиции ресурсов по мере необходимости конкретной задачи. Таким образом, планомерные системы ИИ могут смягчить вероятностную природу LLM, чтобы достичь гарантированных результатов на уровне шага. Без таких гарантий мы возвращаемся к проблеме нарастающей ошибки, которая подорвет даже лучший макроплан.

Но почему LLM не могут служить планировщиками? Ведь они способны переводить высокоуровневые инструкции в разумные цепочки мыслей или планы, определенные в естественном языке или коде. Причина в том, что планирование требует больше, чем это. Планирование требует способности моделировать альтернативные курсы действий, которые могут разумно привести к желаемому результату, И рассуждать о ожидаемой полезности и ожидаемых затратах (в вычислениях и/или задержке) каждой альтернативы. Хотя LLM потенциально могут генерировать представления доступных курсов действий, они не могут предсказать их соответствующую ожидаемую полезность и затраты. Например, какие ожидаемая полезность и затраты использования модели X против модели Y для генерации ответа для конкретного контекста? Какова ожидаемая полезность поиска конкретного куска информации в корпусе индексированных документов против вызова API к CRM? Ваша LLM даже не начинает понимать. И по хорошей причине – исторические следы этих вероятностных черт редко встречаются в дикой природе и не включены в данные обучения LLM. Они также имеют тенденцию быть специфичными для конкретной среды инструментов и данных, в которой будет работать система ИИ, в отличие от общих знаний, которые могут получить LLM. И даже если LLM могли бы предсказать ожидаемую полезность и затраты, рассуждение о них для выбора наиболее эффективного курса действий – это логическое решение теоретической дедукции, которое не может быть надежно выполнено предсказаниями следующего токена LLM.

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

Некоторые люди уже усердно работают над выполнением этого обещания. До тех пор, пока продолжайте строить статические цепочки. Только, пожалуйста, не называйте их “агентами”.