Inteligencia ejecutiva del proyecto LangChain

Las inteligencias de planificación-ejecución proporcionan una solución más rápida, más rentable y de mayor rendimiento para la ejecución de tareas que los diseños anteriores. Este artículo le guiará a través de la construcción de tres inteligencias de planificación en LangGraph.

Hemos introducido tres inteligencias de modo "planificar y ejecutar" en la plataforma LangGraph. Estas inteligencias presentan varias mejoras con respecto a las inteligencias clásicas del modo Razonar y Actuar (ReAct).

⏰ En primer lugar, estas inteligencias son capaces de realizar procesos de tareas de varios pasos con mayor rapidez, ya que no es necesario volver a solicitar la participación de inteligencias grandes después de completar cada acción. Cada subtarea puede completarse sin necesidad de llamadas adicionales al modelo de lenguaje grande (LLM), o llamadas a un soporte LLM más ligero.

💸 En segundo lugar, pueden reducir eficazmente los costes en comparación con las inteligencias ReAct. Si se necesitan llamadas LLM para subtareas, normalmente se utilizan modelos más pequeños y específicos del dominio. Los modelos grandes sólo se invocan cuando es necesario realizar pasos de (re)planificación y generar respuestas finales.

🏆 Por último, al pedir al planificador que "piense" explícitamente paso a paso en el proceso necesario para completar toda la tarea, estas inteligencias pueden obtener mejores resultados en términos de tasa y calidad de finalización de la tarea. El desarrollo de pasos de razonamiento detallados ha sido una técnica validada para mejorar los resultados. Segmentar el problema también puede conducir a un rendimiento más centrado y eficiente de la tarea.

Fondo

En el último año, los agentes inteligentes y las máquinas de estado basadas en modelos lingüísticos han surgido como un prometedor paradigma de diseño para desarrollar productos de IA flexibles y eficientes.

El núcleo de un agente es un modelo de lenguaje como herramienta genérica de resolución de problemas que lo conecta a recursos externos para responder preguntas o realizar tareas.

Normalmente, los agentes inteligentes basados en modelos lingüísticos pasan por los siguientes pasos principales:

1. Proponer una acción: el modelo lingüístico genera un texto que responde directamente al usuario o se comunica a una función.
2. Ejecutar acción: el código llama a otro software para realizar, por ejemplo, consultas a la base de datos o llamadas a la API y otras operaciones.
3. Observar Observar: reaccionar a la retroalimentación de las llamadas a las herramientas, ya sea llamando a otra función o respondiendo al usuario.

ReAct Los agentes inteligentes son un buen ejemplo de ello, ya que utilizan ciclos repetitivos de pensar, actuar y observar para guiar el modelo lingüístico:

Piensa: Debería llamar a Search() para buscar el resultado del partido actual.
Acción: Buscar("¿Cuál es la puntuación del partido X actual?")
Observación: El marcador actual es 24-21
... (Repetir N veces)

Se trata de una trayectoria típica de un agente inteligente al estilo ReAct.

Este enfoque utilizaCadena de pensamientopara que en cada paso se tome una única decisión. Aunque esto puede ser eficaz para tareas sencillas, tiene algunos inconvenientes importantes:

1. Cada llamada a la herramienta requiere una llamada al modelo lingüístico.
2. El modelo lingüístico planifica un subproblema cada vez. Esto puede dar lugar a trayectorias de procesamiento subóptimas, ya que no se ve obligado a "razonar" sobre el conjunto de la tarea.

Una forma eficaz de superar estas dos deficiencias es incluir un paso explícito de planificación. A continuación se presentan dos ejemplos de este tipo de diseños que hemos implementado en LangGraph.

Sistema de planificación y ejecución

Agentes de ejecución del programa

Esta sencilla estructura se basa en el trabajo de Wang et al [Consejos de planificación y resolución] propuesto por Yohei Nakajima y basado en [BabyAGI], que se convirtió en la arquitectura típica de los agentes de planificación. Contiene dos componentes básicos principales:

1. Un planificador (A) planificador), se encarga de dirigir un modelo de lenguaje (LLM) para generar planes de varios pasos para tareas complejas.
2. Actuadores múltiples (Ejecutor(s)) que puede procesar los requisitos de consulta del usuario, así como un paso en el plan e invocar una o más herramientas para realizar esa tarea.

Una vez finalizada la ejecución de la tarea, el agente vuelve a aparecer con una nueva solicitud de planificación, momento en el que decide si simplemente proporciona una respuesta para finalizarla o si genera más planes según sea necesario (si el plan original no alcanzó su objetivo).

Este diseño de agente evita la necesidad de depender de un gran modelo de lenguaje de planificación para cada invocación de la herramienta. Sin embargo, como no admite operaciones de asignación de variables y la herramienta debe invocarse en serie, se requiere un modelo de lenguaje distinto para cada tarea.

Razonamiento más allá de la observación independiente

En [ReWOO], Xu et al. idearon un novedoso modelo de agente que invierte la forma tradicional en la que cada tarea debe depender del Gran Modelo de Lenguaje (LLM) al permitir que las tareas posteriores dependan de los resultados de la tarea anterior. El modelo se implementa incorporando la función de asignación de variables en la planificación de salida. La siguiente figura muestra el diseño de este modelo de agente.

Modelo de agente ReWOO

El planificador se encarga de generar una lista de planes que incluye "plan" (razonamiento) alternado con la línea "E#". Por ejemplo, para la consulta "¿Cuáles son las estadísticas de quarterback de los contendientes a la Super Bowl de este año?", el planificador podría generar el siguiente plan:

El plan: necesito conocer los equipos que juegan la Super Bowl este año
E1: Buscar [¿quién juega en la Super Bowl?] PLAN: Necesito saber quién es el quarterback de cada equipo
E2: LLM [QB del primer equipo #E1] PLAN: Necesito saber quién es el QB de cada equipo
E3: LLM [2º equipo QB #E1] Plan: Tengo que buscar las estadísticas del primer quarterback
E4: Buscar [#E2's QB stats] Plan: Necesito buscar las estadísticas del segundo quarterback
E5: Buscar [#E3's quarterback stats]

Tenga en cuenta que el planificador (planificador) Cómo puede hacer referencia a la salida anterior mediante sintaxis como `#E2`. Esto significa que es posible realizar una serie de tareas sin tener que reprogramar cada vez.

"Trabajadores (trabajadorEl nodo ")" iterará a través de cada tarea y asignará sus resultados a variables predeterminadas. Y, cuando se ejecuten las llamadas a tareas posteriores, estas variables se sustituirán por los resultados correspondientes.

En última instancia, el "resolver (Solucionador) "Integrar todos los resultados para llegar a la respuesta final.

Esta filosofía de diseño de agentes puede ser más eficiente que un modelo simple de planificar-ejecutar, ya que cada tarea contiene sólo la información contextual necesaria (es decir, sus entradas y valores variables).

Sin embargo, este diseño sigue basándose en la ejecución secuencial de tareas, lo que puede dar lugar a tiempos de ejecución totales más largos.

LLMCompiler

Agente LLMCompiler

LLMCompiler Es una combinación de [Equipo Kim] desarrollaron una arquitectura de agentes que está diseñada para mejorar la eficiencia de ejecución de tareas sobre el plan-ejecutar previamente descrito con agentes ReWOO, e incluso más rápido que las llamadas a herramientas paralelas de OpenAI.

El LLMCompiler consta de las siguientes partes principales:

1. PlanificadorEl programa genera un grafo acíclico dirigido (DAG) de tareas. Cada tarea incluye herramientas, parámetros y una lista de dependencias.

2. Unidad de obtención de tareas (TFU) Responsable de la programación y ejecución de tareas. Puede aceptar un flujo de tareas y programarlas cuando se satisfagan sus dependencias. Dado que muchas herramientas requieren llamadas adicionales al motor de búsqueda o al LLM, esta ejecución paralela puede aumentar significativamente la velocidad (hasta 3,6 veces según el artículo).

3. Conector (Joiner)Esta parte puede replanificar o finalizar dinámicamente la tarea basándose en el historial completo de la ejecución de la tarea, incluidos los resultados de la ejecución de la tarea. Es el paso de la sesión LLM que determina si se presenta directamente el resultado final o se devuelve el progreso al planificador para continuar el trabajo.

El punto clave de esta arquitectura para acelerar la aplicación es:

• planificadorLa salida delstreaming; es capaz de producir salidas instantáneas de los parámetros de las tareas y sus dependencias.
• unidad de adquisición de tareas Recibe las tareas y comienza a programarlas cuando se satisfacen todas las dependencias.
• Los parámetros de la tarea pueden servariantees decir, los resultados de las tareas anteriores en el grafo acíclico dirigido. Por ejemplo, el modelo puede representarse mediante search("${1}") para consultar el contenido de búsqueda generado por la Tarea 1. Este enfoque permite al agente trabajar de forma más eficiente que las llamadas a herramientas paralelas normales de OpenAI.

Al organizar las tareas en un grafo acíclico dirigido, no sólo se ahorra un tiempo valioso al invocar la herramienta, sino que también se ofrece una mejor experiencia al usuario.

resúmenes

Estas tres arquitecturas proxy son prototipos del patrón de diseño Planificar-Hacer, que separan el "planificador" basado en LLM del tiempo de ejecución de la herramienta. Si su aplicación requiere múltiples llamadas a la herramienta o API, estos enfoques pueden acortar el tiempo que se tarda en llegar al resultado final y ayudarle a reducir costes reduciendo el número de llamadas a LLM de nivel superior.