LangChain Project Executive Intelligence

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

Мы представили на платформе LangGraph три интеллекта, работающих в режиме "планируй и выполняй". Эти интеллекты демонстрируют ряд улучшений по сравнению с классическими интеллектами, работающими в режиме Reason and Act (ReAct).

Во-первых, эти интеллекты способны быстрее выполнять многоэтапные задачи, поскольку после завершения каждого действия не нужно снова запрашивать участие больших интеллектов. Каждая подзадача может быть выполнена без дополнительных вызовов большой языковой модели (LLM) или обращений к более легкой поддержке LLM.

💸 Во-вторых, они могут эффективно снизить затраты по сравнению с интеллектами ReAct. Если для подзадач требуются вызовы LLM, обычно используются небольшие, специфичные для конкретной области модели. Большие модели вызываются только тогда, когда необходимо выполнить шаги (повторного) планирования и сгенерировать окончательные ответы.

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

Фон

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

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

Как правило, интеллектуальные агенты, основанные на языковых моделях, проходят следующие основные этапы:

1. предложение действия: языковая модель генерирует текст, который отвечает непосредственно пользователю или передается функции.
2. выполнение действия: код вызывает другое программное обеспечение для выполнения, например, запроса к базе данных или вызова API и других операций.
3. наблюдать Наблюдать: реагировать на обратную связь от вызовов инструмента, либо вызывая другую функцию, либо отвечая пользователю.

ReAct Интеллектуальные агенты являются хорошим примером этого, используя повторяющиеся циклы мышления, действия и наблюдения для управления языковой моделью:

Подумайте: я должен вызвать Search(), чтобы найти счет текущего матча.
Действие: Search("Какой счет в текущем матче X?")
Наблюдение: Текущий счет 24-21
... (Повторить N раз)

Это типичная траектория движения интеллектуального агента в стиле ReAct.

Этот подход используетЦепь мыслейподсказки, чтобы на каждом шаге принималось только одно решение о действии. Хотя такой подход может быть эффективен для решения простых задач, он имеет ряд существенных недостатков:

1. каждый вызов инструмента требует вызова языковой модели.
2. языковая модель планирует по одной подпроблеме за раз. Это может привести к неоптимальным траекториям обработки, так как она не вынуждена "рассуждать" обо всей задаче.

Эффективным способом преодоления этих двух недостатков является включение явного этапа планирования. Ниже приведены два примера таких конструкций, которые мы реализовали в LangGraph.

Система "Планируй и выполняй

Агенты-исполнители программ

Эта простая структура основана на работе Wang et al [Советы по планированию и решению проблем], предложенный Йохеем Накадзимой и опирающийся на его [BabyAGI], которая стала типичной архитектурой агента планирования. Он содержит два основных базовых компонента:

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

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

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

Рассуждения, выходящие за рамки независимого наблюдения

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

Модель агента ReWOO

Планировщик отвечает за генерацию списка планов, в котором "plan" (рассуждение) чередуется со строкой "E#". Например, для запроса "Какова статистика квотербеков у претендентов на Суперкубок этого года?" планировщик может сгенерировать следующий план:

План: я должен знать команды, играющие в Суперкубке в этом году
E1: Поиск [кто играет в Суперкубке?] ПЛАН: Мне нужно знать, кто является квотербеком каждой команды.
E2: LLM [КБ первой команды #E1] ПЛАН: Мне нужно знать, кто является КБ каждой команды.
E3: LLM [2-я команда QB #E1] План: мне нужно посмотреть статистику первого квотербека
E4: Search [#E2's QB stats] План: Мне нужно посмотреть статистику второго квотербека.
E5: Поиск [статистики квотербека #E3]

Обратите внимание, что планировщик (планировщик) Как он может ссылаться на предыдущий вывод с помощью синтаксиса, например `#E2`. Это означает, что можно выполнять серию задач без необходимости каждый раз заново планировать их выполнение.

"Рабочие (рабочийУзел ")" выполняет итерации по каждой задаче и присваивает их выходы заранее определенным переменным. При последующих вызовах задач эти переменные заменяются соответствующими результатами.

В конечном счете, "разрешитель (Решатель) "Интегрируйте все выходы, чтобы получить окончательный ответ.

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

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

LLMCompiler

LLMCompiler Agent

LLMCompiler Это сочетание [Команда Ким] разработали архитектуру агентов, которая призвана повысить эффективность выполнения задач по сравнению с ранее описанным планом-выполнением с помощью агентов ReWOO, и даже быстрее, чем параллельные вызовы инструментов OpenAI.

LLMCompiler состоит из следующих основных частей:

1. Планировщик: Он генерирует направленный ациклический граф (DAG) задач. Каждая задача включает инструменты, параметры и список зависимостей.

2. Блок получения заданий (TFU) Отвечает за планирование и выполнение задач. Он может принимать поток задач и планировать их выполнение, когда их зависимости будут удовлетворены. Поскольку многие инструменты требуют дополнительных вызовов поисковой системы или LLM, такое параллельное выполнение может значительно увеличить скорость (до 3,6 раза, согласно статье).

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

Ключевым моментом этой архитектуры является ускорение реализации:

• планировщикВыходпотоковое вещание; он способен мгновенно выдавать параметры задач и их зависимости.
• блок получения заданий Получает задания, поступающие потоком, и начинает планировать их выполнение, когда все зависимости удовлетворены.
• Параметры задачи могут бытьвариантт.е. выходы предыдущих задач в направленном ациклическом графе. Например, модель может быть представлена следующим образом search("${1}") для запроса поискового контента, сгенерированного в задаче 1. Такой подход позволяет агенту работать более эффективно, чем обычные параллельные вызовы инструментов OpenAI.

Организация задач в направленный ациклический граф позволяет не только сэкономить драгоценное время при вызове инструмента, но и повысить удобство работы с ним.

резюме

Эти три прокси-архитектуры являются прототипами паттерна проектирования Plan-Do, отделяющего управляемый LLM "планировщик" от времени выполнения инструмента. Если ваше приложение требует многократных обращений к инструменту или API, эти подходы могут сократить время достижения конечного результата и помочь вам снизить затраты за счет уменьшения количества обращений к LLM более высокого уровня.