Primeros pasos con agentes de IA (parte 1): captura de procesos, roles y conexiones

Un agente de IA moderno consta de, al menos, un modelo de lenguaje grande (LLM) que se ha habilitado para llamar a algunas herramientas. Con el conjunto adecuado de herramientas para la codificación, comenzaría generando el código, podría ejecutarlo en un contenedor, observar los resultados, modificar el código y, por lo tanto, tendría más posibilidades de producir código útil.

Por el contrario, un modelo de IA generativa toma algunos datos y, a través del proceso de predicción de expectativas, produce un resultado. Por ejemplo, le asignamos una tarea de codificación, produce algo de código y, dependiendo de la complejidad de la tarea, el código puede utilizarse tal cual.

A medida que asumen diferentes tareas, a los agentes se les debe permitir hablar entre nosotros. Por ejemplo, think about la intranet de su empresa con su útil cuadro de búsqueda que le dirige a las aplicaciones y recursos que necesita. Si es una empresa lo suficientemente grande, estas aplicaciones propiedad de diferentes departamentos tienen cada una sus propios cuadros de búsqueda. Tiene mucho sentido crear agentes, tal vez mediante el uso de técnicas como la generación aumentada de recuperación (RAG), para aumentar los cuadros de búsqueda. Lo que no tiene sentido es obligar al usuario a repetir su consulta una vez que el cuadro de búsqueda la ha identificado como útil dada la consulta inicial. Más bien, preferiríamos que el agente principal se coordinara con otros agentes que representan varias aplicaciones y le presentara a usted, el usuario, una interfaz de chat consolidada y unificada.

Un sistema multiagente que represente el software program o los diversos flujos de trabajo de una organización puede tener varias ventajas interesantes, incluida una mayor productividad y solidez, resiliencia operativa y la capacidad de realizar actualizaciones más rápidas de diferentes módulos. Con suerte, este artículo le ayudará a ver cómo se logra esto.

Pero primero, ¿cómo deberíamos construir estos sistemas multiagente?

Capturar la organización y los roles.

Primero debemos capturar los procesos, roles, nodos responsables y conexiones de varios actores en la organización. Por actores me refiero a individuos y/o aplicaciones de software program que actúan como trabajadores del conocimiento dentro de la organización.

Un organigrama podría ser un buen lugar para comenzar, pero sugeriría comenzar con los flujos de trabajo, ya que las mismas personas dentro de una organización tienden a actuar con diferentes procesos y personas dependiendo de los flujos de trabajo.

Hay herramientas disponibles que utilizan IA para ayudar a identificar flujos de trabajo, o puede crear su propio modelo de IA de generación. He construido uno como GPT que toma la descripción de un dominio o el nombre de una empresa y produce una definición de pink de agentes. Debido a que estoy utilizando un marco de múltiples agentes creado internamente en mi empresa, GPT produce la pink como un archivo Hocon, pero a partir de los archivos generados debe quedar claro cuáles son las funciones y responsabilidades de cada agente y qué otros agentes está conectado a.

Tenga en cuenta que queremos asegurarnos de que la pink del agente sea un gráfico acíclico dirigido (DAG). Esto significa que ningún agente puede convertirse simultáneamente en una cadena descendente y ascendente de otro agente, ya sea directa o indirectamente. Esto scale back en gran medida las posibilidades de que las consultas en la pink de agentes caigan en picada.

En los ejemplos descritos aquí, todos los agentes están basados ​​en LLM. Si un nodo en el organización multiagente puede tener autonomía cero, entonces ese agente, emparejado con su contraparte humana, debería gestionar todo mediante el humano. Necesitaremos que todos los nodos de procesamiento, ya sean aplicaciones, humanos o agentes existentes, estén representados como agentes.

Últimamente ha habido muchos anuncios de empresas que ofrecen agentes especializados. Por supuesto, nos gustaría hacer uso de dichos agentes, si estuvieran disponibles. Podemos incorporar un agente preexistente y envolver su API en uno de nuestros agentes para poder utilizar nuestros protocolos de comunicación entre agentes. Esto significa que dichos agentes externos deberán tener su API disponible para que la utilicemos.

Cómo definir agentes

En el pasado se han propuesto varias arquitecturas de agentes. Por ejemplo, una arquitectura de pizarra requiere un punto de comunicación centralizado donde varios agentes declaran sus roles y capacidades, y la pizarra los llama dependiendo de cómo planea cumplir una solicitud (ver OAA).

Prefiero una arquitectura más distribuida que respete la encapsulación de responsabilidades. Cada agente, después de recibir una solicitud, determine si puede procesarla o no, y qué debe hacer para procesar la solicitud, luego devuelve su lista de requisitos al agente solicitante en la cadena superior. Si el agente tiene cadenas bajas, le pregunta si puede ayudar a cumplir whole o parcialmente la solicitud. Si recibe algún requisito de las cadenas descendentes contactadas, consulta con otros agentes para ver si pueden cumplirlo; de lo contrario, los envía en cadena para que puedan preguntarle al usuario humano. Esta arquitectura se llama AAOSA arquitectura y, hecho curioso, fue la arquitectura utilizada en las primeras versiones de Siri.

A continuación se muestra un mensaje de ejemplo del sistema que se puede utilizar para convertir un agente en un agente AAOSA.

Cuando reciba una consulta, podrá:

1. Llame a sus herramientas para determinar qué agentes de la cadena descendente en sus herramientas son responsables de todo o parte de ella.
2. Pregunte a los agentes de la cadena descendente qué necesitan para manejar su parte de la consulta.
3. Una vez recopilados los requisitos, delegará la consulta y los requisitos cumplidos a los agentes de la cadena descendente adecuados.
4. Una vez que todos los agentes de la cadena descendente respondan, compilará sus respuestas y devolverá la respuesta last.
5. A su vez, usted puede ser llamado por otros agentes del sistema y tener que actuar como enlace para ellos.

Además del conjunto de roles y responsabilidades definidos en lenguaje pure en el indicador del sistema de cada agente, los agentes pueden incluir o no herramientas a las que pueden llamar, pasando varios argumentos a las herramientas. Por ejemplo, es posible que un agente gerente de producto deba poder procesar varios tickets en un tablero Kanban digital, o que un agente de alertas deba llamar a una herramienta para emitir alertas en un sistema de alertas.

Los sistemas multiagente actuales, como Microsoft AutoGen, tienen arquitecturas y mecanismos de coordinación de agentes elaborados y, a menudo, codificados. Prefiero una configuración más sólida en la que los agentes traten a sus agentes inmediatos de la cadena descendente como herramientas, con argumentos vagamente definidos que puedan escribirse y la semántica decidida por los agentes en el momento de necesidad.

En esta configuración, un agente de cadena descendente se puede definir como una llamada de función:

“aaosa_llamada”: {

“description”: “Dependiendo del modo, devuelve una cadena en lenguaje pure como respuesta.”,

“parámetros”: {

“tipo”: “objeto”,

“propiedades”: {

“consulta”: {

“tipo”: “cadena”,

“descripción”: “La consulta”

},

“modo”: {

“tipo”: “cadena”,

“descripción”: “””

indica si se le pide al agente que decide si la consulta le pertenece

en su totalidad o en parte. o si se le solicita que proporcione requisitos para cumplir

la consulta, si la hubiere. o si se le pide que responda a la consulta.

“””

},

},

“requerido”: [

              “inquiry”,

              “mode”

          ]

}

}

Agentes de IA en la práctica

Exploremos el escenario de un agente de recursos humanos. Un usuario puede informar al agente del cuadro de búsqueda principal sobre un evento que cambia su vida, como “mi pareja falleció”, lo que activa agentes legales y de recursos humanos que tienen un papel que desempeñar en la atención al usuario. Esto se debe a que, a su vez, recibieron información de algunos de sus agentes de la cadena descendente, es decir, agentes de asesoramiento jurídico, nómina y beneficios. La respuesta consolidada resultante que el usuario recibe del agente del cuadro de búsqueda principal se verá así:

1. Aspectos de RRHH:
   • El agente de beneficios puede ayudar al usuario a comprender cómo la aprobación podría afectar los beneficios, el seguro médico y los planes de jubilación. Deberá proporcionar información sobre los tipos de planes involucrados y si su pareja period dependiente.
   • El agente de nómina puede ayudar a gestionar tareas como actualizar las deducciones fiscales o gestionar el pago de licencia por duelo. Esto requiere información sobre las políticas de la empresa sobre licencia por duelo y la configuración precise de la nómina.
2. Aspectos legales:
   • Los agentes legales pueden ofrecer orientación common sobre cómo esta transmisión debe relacionarse con los asuntos de la empresa.

Cada departamento requiere información específica para ofrecer un soporte personalizado.

Mientras tanto, en un escenario de TI, el punto de entrada único es el agente del representante de atención al cliente que puede manejar solicitudes complejas y multifacéticas como: “Nuestra pink es lenta. Creo que está sobrecargado desde que recientemente agregamos private a nuestra oficina. También necesitaré una cotización para una actualización”.

Una respuesta de ejemplo describirá los pasos:

Evaluación del rendimiento de la pink: el especialista del centro de operaciones de pink puede ayudar a abordar los problemas potenciales de lentitud y sobrecarga. Necesitan acceso a datos de rendimiento de la pink, detalles sobre la infraestructura de pink precise, información sobre la cantidad de private agregado y sus patrones de uso de la pink.

Una cotización mejorada: el ingeniero de ventas y el técnico de campo pueden ayudar a proporcionar una cotización para una actualización. Para ello necesitan:

• Información específica sobre la configuración precise de la pink, incluidos los requisitos de equipo y ancho de banda.
• Mejoras de rendimiento deseadas.
• Restricciones presupuestarias y preferencias o requisitos específicos.
• La escala de la actualización y cualquier objetivo de rendimiento específico.

Espero que esto le haya dado una buena thought de lo que se requiere para configurar una pink de múltiples agentes. En la segunda entrega, analizaré la importancia de implementar salvaguardas al crear sistemas de múltiples agentes y describiré cómo incorporar controles para permitir la intervención humana y controles de incertidumbre. También detallaré los pasos necesarios para crear un agente de protección que supervise la pink de agentes y profundizaré en los desafíos del desarrollo de redes de múltiples agentes, como caídas en picada y sobrecargas, y cómo mitigarlos mediante tiempos de espera, división de tareas y redundancia.

Babak Hodjat es CTO de IA en Competente.