IA agéntica

Un sistema de IA agéntica está compuesto por los siguientes componentes:

• Un componente Agent Orchestration gestiona y coordina las acciones de un conjunto de agentes. El componente Agent Orchestration puede utilizar un LLM para desglosar y generar dinámicamente flujos de trabajo para resolver tareas complejas, o puede utilizar únicamente flujos de trabajo definidos estáticamente mediante tecnologías como Business Process Modeling Notation (BPMN), Business Process Execution Language (BPEL), u otras tecnologías de flujo de trabajo.
  
  
• Uno o varios agentes, partes de software que pueden autodeterminarse y ejecutar acciones para alcanzar objetivos específicos. Los agentes suelen utilizar un LLM para generar dinámicamente planes para completar tareas. Los agentes también pueden hacer uso de herramientas para interactuar con sistemas externos, por ejemplo. una API de aplicación empresarial, almacenes de conocimiento de búsqueda, p. ej. consultar Wikipedia, o para realizar cálculos, por ejemplo. operaciones matemáticas, que no se pueden realizar con precisión o eficacia utilizando solo un LLM.
  
  
• Por último, las herramientas interactúan con fuentes y sistemas empresariales y externos para recuperar información y actualizar los sistemas de registro.

Los agentes tienen su propia arquitectura conceptual, ilustrada en la siguiente figura.

Los agentes se componen de los siguientes componentes principales:

• El componente Input es una o más fuentes de entrada que hacen que el agente realice una acción. Por lo general, se trata de una consulta en lenguaje natural o una tarea de un usuario, pero también podría ser un evento del sistema, como la creación de un archivo, un mensaje en una cola de Kafka o una llamada API estructurada.
  
  
• El componente Execution coordina las actividades del agente para llevar a cabo la tarea requerida. Normalmente, la primera tarea ejecutada por el componente Execution es (i) organizar una lista de las herramientas y recursos disponibles para el agente, y (ii) invocar el componente Planning and Reflection para generar un plan de actividad que lleve a cabo la tarea. A continuación, el componente Execution ejecuta el plan generado, invocando las herramientas y los recursos necesarios para recopilar información o alterar el entorno externo del agente; y puede volver a invocar periódicamente el componente Planning and Reflection para adaptar el plan de actividades en función de las respuestas/fallos de la herramienta.
  
  
• El componente de Planning and Reflection, comúnmente un LLM, permite al agente crear planes de acción paso a paso para realizar una tarea en respuesta a sus entradas, y reflexionar sobre los resultados de las acciones y adaptar sus planes en respuesta.
  
  
• El componente Tool Integration permite al agente utilizar ‘herramientas’ para llamar a las API y acceder a recursos para completar acciones y recopilar información que contribuya a completar la tarea global.
  
  
• El componente Memory gestiona el conocimiento a corto plazo, dentro de la tarea, el contexto y el conocimiento a largo plazo, lo que permite al agente mantener el contexto entre las invocaciones de tareas (por ejemplo, “Revertir la última orden de compra”) y proporcionar una base para el análisis de las acciones pasadas y la optimización de las acciones futuras.
  

Se pueden añadir componentes adicionales, que no se muestran en la figura, para proporcionar gestión de agentes operativos, monitorización del rendimiento y controles de seguridad como la propagación de identidades y la prevención de fugas de datos.

El diagrama siguiente ilustra el flujo de control e información a través de la arquitectura conceptual.

1. Un usuario envía una consulta a una aplicación de IA generativa (por ejemplo, un chatbot, o una interfaz de consulta dentro de una aplicación empresarial)
   
   
2. La aplicación de IA generativa pasa la consulta del usuario al Agent Orchestrator en forma de consulta sin procesar, por ejemplo, la aplicación de IA es una interfaz de chat, o bien activando un flujo de trabajo predefinido, por ejemplo, el inicio de una solicitud de compra. Se utilizará una consulta sin procesar para el tutorial.
   
   
3. El enrutador utiliza un LLM ajustado para desglosar la consulta del usuario en una serie de acciones o pasos necesarios para llegar a una respuesta. Por ejemplo, para responder a la pregunta “¿Cuál es la temperatura actual en Winnipeg, Manitoba, Canadá? ¿Cómo se compara eso con el promedio histórico para esta época del año?”, el LLM puede responder con la siguiente lista conceptual de acciones:
   
   
   • Buscar la temperatura actual de Winnipeg utilizando el agente Weather
   • Buscar la fecha actual con el agente Calendar
   • Consultar la temperatura media en Winnipeg en esta fecha usando el agente Search
   • Encontrar la diferencia entre la temperatura actual y el promedio histórico utilizando el agente Calculator
   • Formular una respuesta en lenguaje natural utilizando el agente Language
     
     
4. El Orchestrator invoca entonces el agente correspondiente para cada acción de la lista. Continuando con el ejemplo del paso 3:
   
   
   • El Orchestrator invoca al agente Weather para recuperar la temperatura actual de Winnipeg, -1 °C.
   • El Orchestrator invoca al agente Calendar para obtener la fecha actual, 9 de noviembre de 2023.
   • El Orchestrator utiliza el agente Search para encontrar la temperatura normal en Winnipeg el 9 de noviembre, 1,4 °C.
   • El Orchestrator invoca al agente Calculator para encontrar la diferencia entre las dos temperaturas, -1 - 1,4 = -2,4
   • El Orchestrator utiliza el agente Language para formular una respuesta a la consulta inicial utilizando los datos recopilados
      
5. Cuando se invoca un agente, puede, al igual que el Orchestrator, usar un LLM para planificar sus acciones. Continuando con el ejemplo, el agente Weather recibiría la solicitud “¿Cuál es la temperatura actual en Winnipeg?”, para lo que generaría el siguiente plan:
   
   
   • Buscar en qué país se encuentra Winnipeg
   • Buscar el servicio meteorológico nacional autorizado para el país de Winnipeg
   • Utilizar la API Weather para consultar al servicio meteorológico la temperatura actual en Winnipeg.
   • A continuación, el agente buscaría el país en el que se encuentra Winnipeg (Canadá) utilizando un LLM o un servicio externo, utilizaría ese valor para buscar el servicio meteorológico nacional de Canadá (Environment Canada) y utilizaría la API Weather para obtener el temperatura actual de Winnipeg.
      
6. La respuesta resultante se devuelve a la aplicación de IA generativa; en nuestro ejemplo “La temperatura actual en Winnipeg es de -1 °C. Eso es 2,4 °C más frío que la norma histórica de 1,4 °C”.
   
   
7. La respuesta formulada se devuelve al usuario.

El diagrama anterior ilustra la correspondencia de los productos de IBM con la arquitectura de la IA agéntica.

watsonx Orchestrate es una solución de IA agéntica ‘todo en uno’ que combina:

• publicación y gestión de herramientas (llamadas habilidades en watsonx Orchestrate);
• composición de habilidades en procesos complejos de varios pasos mediante flujos de trabajo declarativos; y
• agentes específicos de dominio prediseñados para áreas de negocio horizontales, como recursos humanos y compras.

watsonx.ai Agent Builder es una herramienta low-code/no-code que permite a los desarrolladores crear agentes y definir y gestionar herramientas mediante flujos prediseñados.

Estrategia de orquestación

La orquestación de agentes se puede implementar mediante varios enfoques. Un enfoque de orquestación centralizada utiliza un único componente de orquestación maestro para gestionar las acciones de todos los demás agentes del sistema. Disponer de un único punto de configuración y gestión hace que el sistema en su conjunto sea fácil de gestionar y controlar, y que la resolución de problemas resulte sencilla. La desventaja es que un único punto de control puede convertirse en un cuello de botella y provocar problemas de escalabilidad a medida que aumentan los volúmenes de solicitudes o el número de agentes.

Un enfoque de orquestación descentralizada implementa una cola de tareas de la que los agentes extraen tareas y publican resultados, y encamina tareas de varias partes entre sí; similar a un sistema de pizarra. Las soluciones de orquestación descentralizada son muy robustas y tolerantes a fallos, pero son difíciles de diseñar y solucionar a medida que los sistemas se vuelven más grandes y con mayores capacidades.

Por último, un enfoque de orquestación jerárquica combina elementos de los enfoques centralizado y descentralizado. En la orquestación jerárquica, se utiliza un orquestador maestro para coordinar las acciones de los agentes de alto nivel que, a su vez, pueden invocar a otros agentes para completar tareas complejas. Esto conserva gran parte de la facilidad de gestión y control de un enfoque centralizado, pero reduce la posibilidad de que el componente de control central se convierta en un cuello de botella con grandes volúmenes de solicitudes y/o un gran número de agentes.

Granularidad del agente

La granularidad de un agente de IA se refiere a la complejidad de las tareas que el agente puede realizar. Un agente de alta granularidad puede ser capaz de realizar muchas tareas o un pequeño número de tareas con gran detalle, mientras que un agente de baja granularidad solo puede ser capaz de realizar un pequeño número o incluso una sola tarea con un bajo nivel de detalle. Para que quede más claro, piense en un agente de servicio de atención al cliente. Un agente de baja granularidad solo puede responder a preguntas sencillas sobre un producto (por ejemplo, “¿Está en negro?”), mientras que un agente de alta granularidad puede comprobar los inventarios locales y organizar la entrega del producto al domicilio del cliente.

Los diseñadores de soluciones agénticas deben decidir el grado de granularidad que deben tener los agentes individuales dentro del sistema, por ejemplo, si es mejor tener un número reducido de agentes de alta granularidad o un número mayor de agentes de baja granularidad. Las amplias capacidades de los agentes de alta granularidad tienen como contrapartida unos mayores requisitos de recursos informáticos y unos tiempos de finalización de las tareas más largos. Aunque menos capaces, el enfoque limitado de los agentes de baja granularidad significa que requieren menos recursos informáticos y que, por lo general, completarán las tareas mucho más rápido.

Aunque aún se desconoce el nivel ‘adecuado’ de granularidad, las primeras experiencias sugieren que la creación de agentes de baja granularidad alineados con procesos empresariales centrados, por ejemplo, Purchase_Order_Processing_Agent, produce un buen equilibrio entre los requisitos de recursos, la velocidad de procesamiento y la complejidad de la solución. Los agentes de baja granularidad pueden entonces incorporarse a flujos de trabajo estáticos, o ser invocados por agentes de alta granularidad como parte de un proceso mayor.

Flujos de trabajo estáticos vs. dinámicos

Los diseñadores de soluciones de IA agéntica deben lograr un equilibrio entre los agentes que siguen procesos y flujos de trabajo estáticos y predefinidos y que los flujos de trabajo se generen de forma dinámica en respuesta a las instrucciones del usuario. Aunque no hay una respuesta correcta o incorrecta, se recomienda a los arquitectos que tengan en cuenta las siguientes recomendaciones y consideraciones:

• Los flujos de trabajo estáticos deben utilizarse para procesos empresariales compuestos por múltiples pasos complejos que cruzan dominios de conocimiento (por ejemplo, legal y contabilidad), o que estén sujetos a supervisión regulatoria. El uso de flujos de trabajo estáticos en estos casos ofrece a los arquitectos varios beneficios:

  • Los flujos de trabajo estáticos son (relativamente) sencillos de instrumentar, monitorizar y auditar, y los propios flujos de trabajo pueden utilizarse como prueba de cumplimiento normativo. Los flujos de trabajo generados dinámicamente son más difíciles de monitorizar a medida que se ejecutan y las ejecuciones individuales de los procesos deben reconstruirse a partir de los registros individuales de los agentes. Los flujos de trabajo dinámicos también tienen el potencial de variar la secuencia de las tareas, lo que complica aún más la auditoría y el control del cumplimiento.
    
    
  • Contar con ‘transferencias’ bien definidas entre las áreas de especialización proporciona una clara separación de responsabilidades y facilita garantizar que la información transmitida sea completa y correcta. Aunque se puede lograr lo mismo con un flujo de trabajo generado dinámicamente, requiere más atención en el diseño y la implementación para lograrlo
    
    
• Los flujos de trabajo dinámicos deben utilizarse para actividades o funciones de ‘un solo paso’ que se realizan en un intervalo de tiempo reducido, no traspasan los ámbitos de conocimiento y cuya ejecución no está sujeta a supervisión ni controles normativos.