Nos Prometieron Agentes, pero Todo lo que Obtuvimos Fueron Cadenas Estáticas

En la primavera de 2023, el mundo se emocionó con la emergencia de agentes de IA basados en LLM. Potentes demos como AutoGPT y BabyAGI demostraron el potencial de los LLM que funcionan en un bucle, eligiendo la próxima acción, observando sus resultados y eligiendo la próxima acción, un paso a la vez (también conocido como el marco de trabajo ReACT). Este nuevo método se esperaba que impulsara a los agentes que realizaran tareas multietapa de manera autónoma y genérica. Dale un objetivo y un conjunto de herramientas y se encargará del resto. Para finales de 2024, el panorama estará lleno de agentes de IA y marcos de trabajo para la construcción de agentes. Pero, ¿cómo se miden frente a la promesa?

Es seguro decir que los agentes impulsados por el marco de trabajo ReACT naive sufren de limitaciones severas. Dale una tarea que requiera más de unos pocos pasos, utilizando más de unas pocas herramientas y fallarán miserablemente. Más allá de sus obvios problemas de latencia, perderán la pista, no seguirán las instrucciones, se detendrán demasiado pronto o demasiado tarde y producirán resultados muy diferentes en cada intento. Y no es de extrañar. El marco de trabajo ReACT toma las limitaciones de los LLM impredecibles y las compone por el número de pasos. Sin embargo, los constructores de agentes que buscan resolver casos de uso del mundo real, especialmente en la empresa, no pueden hacerlo con ese nivel de rendimiento. Necesitan resultados confiables, predecibles y explicables para flujos de trabajo multietapa complejos. Y necesitan sistemas de IA que mitiguen, en lugar de exacerbar, la naturaleza impredecible de los LLM.

Entonces, ¿cómo se construyen los agentes en la empresa hoy en día? Para casos de uso que requieren más de unas pocas herramientas y unos pocos pasos (por ejemplo, RAG conversacional), los constructores de agentes han abandonado en gran medida la promesa dinámica y autónoma de ReACT para métodos que confían pesadamente en la cadena estática – la creación de cadenas predefinidas diseñadas para resolver un caso de uso específico. Este enfoque se asemeja a la ingeniería de software tradicional y está lejos de la promesa de agente de ReACT. Logra niveles más altos de control y confiabilidad, pero carece de autonomía y flexibilidad. Las soluciones son, por lo tanto, intensivas en desarrollo, estrechas en aplicación y demasiado rígidas para abordar altos niveles de variación en el espacio de entrada y el entorno.

Para estar seguros, las prácticas de cadena estática pueden variar en cuán “estáticas” son. Algunas cadenas utilizan LLM solo para realizar pasos atómicos (por ejemplo, para extraer información, resumir texto o redactar un mensaje) mientras que otras también utilizan LLM para tomar algunas decisiones dinámicamente en tiempo de ejecución (por ejemplo, un LLM que enruta entre flujos alternativos en la cadena o un LLM que valida el resultado de un paso para determinar si debe ejecutarse nuevamente). En cualquier caso, siempre que los LLM sean responsables de alguna toma de decisiones dinámica en la solución – inevitablemente nos encontramos en un compromiso entre confiabilidad y autonomía. Cuanto más estática es una solución, es más confiable y predecible, pero también menos autónoma y, por lo tanto, más estrecha en aplicación y más intensiva en desarrollo. Cuanto más dinámica y autónoma es una solución, es más genérica y simple de construir, pero también menos confiable y predecible.

Este compromiso se puede representar en el siguiente gráfico:

Esto plantea la pregunta, ¿por qué aún no hemos visto un marco de trabajo de agente que pueda colocarse en el cuadrante superior derecho? ¿Estamos condenados a comerciar la confiabilidad por la autonomía para siempre? ¿No podemos obtener un marco de trabajo que proporcione la interfaz simple de un agente ReACT (tomar un objetivo y un conjunto de herramientas y figurearlo) sin sacrificar la confiabilidad?

La respuesta es – ¡podemos y lo haremos! Pero para eso, necesitamos darnos cuenta de que lo hemos estado haciendo todo mal. Todos los marcos de trabajo actuales para la construcción de agentes comparten un error común: confían en los LLM como el componente dinámico y autónomo. Sin embargo, el elemento crucial que nos falta – lo que necesitamos para crear agentes que sean autónomos y confiables – es la tecnología de planificación. Y los LLM no son grandes planificadores.

Pero primero, ¿qué es “planificación”? Por “planificación” nos referimos a la capacidad de modelar explícitamente cursos de acción alternativos que conduzcan a un resultado deseado y explorar y explotar eficientemente estos cursos de acción bajo restricciones de presupuesto. La planificación debe realizarse a nivel macro y micro. Un plan macro desglosa una tarea en pasos dependientes e independientes que deben ejecutarse para lograr el resultado deseado. Lo que a menudo se pasa por alto es la necesidad de planificación microorientada para garantizar resultados deseados a nivel de paso. Hay muchas estrategias disponibles para aumentar la confiabilidad y lograr garantías a nivel de paso individual mediante el uso de más cómputo en tiempo de inferencia. Por ejemplo, podrías parafrasear consultas de búsqueda semántica múltiples veces, podrías recuperar más contexto por una consulta dada, podrías utilizar un modelo más grande y podrías obtener más inferencias de un LLM – lo que resulta en resultados más satisfactorios para los requisitos de los que elegir el mejor. Un buen planificador micro puede utilizar eficientemente el cómputo en tiempo de inferencia para lograr los mejores resultados bajo un presupuesto de cómputo y latencia determinado. De esa manera, los sistemas de IA planificados pueden mitigar la naturaleza probabilística de los LLM para lograr resultados garantizados a nivel de paso. Sin tales garantías, estamos de vuelta al problema de error compuesto que socavará incluso el mejor plan a nivel macro.

Pero, ¿por qué los LLM no pueden servir como planificadores? Después de todo, son capaces de traducir instrucciones de alto nivel en cadenas razonables de pensamiento o planes definidos en lenguaje natural o código. La razón es que la planificación requiere más que eso. La planificación requiere la capacidad de modelar cursos de acción alternativos que puedan razonablemente conducir al resultado deseado Y razonar sobre la utilidad esperada y los costos esperados (en cómputo y/o latencia) de cada alternativa. Mientras que los LLM pueden generar potencialmente representaciones de cursos de acción disponibles, no pueden predecir su utilidad y costos correspondientes. Por ejemplo, ¿cuáles son la utilidad y los costos esperados de utilizar el modelo X versus el modelo Y para generar una respuesta por un contexto particular? ¿Cuál es la utilidad esperada de buscar una pieza de información en particular en el corpus de documentos indexados versus una llamada a la API de CRM? Su LLM no comienza a tener una idea. Y por buena razón – las trazas históricas de estos rasgos probabilísticos rara vez se encuentran en la naturaleza y no se incluyen en los datos de entrenamiento de LLM. También tienden a ser específicos del entorno de herramientas y datos en el que el sistema de IA operará, a diferencia del conocimiento general que los LLM pueden adquirir. Y aunque los LLM pudieran predecir la utilidad y los costos esperados, razonar sobre ellos para elegir el curso de acción más efectivo es una deducción lógica de la teoría de la decisión, que no se puede asumir que se realice de manera confiable mediante las predicciones de token siguientes de los LLM.

Así que, ¿cuáles son los ingredientes que faltan para la tecnología de planificación de IA? Necesitamos modelos de planificador que puedan aprender de la experiencia y la simulación para modelar explícitamente cursos de acción alternativos y probabilidades de utilidad y costo correspondientes por una tarea particular en un entorno de herramientas y datos particular. Necesitamos un Lenguaje de Definición de Plan (PDL) que se pueda utilizar para representar y razonar sobre dichos cursos de acción y probabilidades. Necesitamos un motor de ejecución que pueda ejecutar de manera determinista y eficiente un plan determinado en PDL.

Algunas personas ya están trabajando arduamente para cumplir con esta promesa. Hasta entonces, sigan construyendo cadenas estáticas. Solo por favor, no las llamen “agentes”.