Primeros pasos con los agentes de IA (parte 2): autonomía, salvaguardas y dificultades

en nuestro primera entregadescribimos estrategias clave para aprovechar los agentes de IA para mejorar la eficiencia empresarial. Expliqué cómo, a diferencia de los modelos de IA independientes, los agentes refinan las tareas de forma iterativa utilizando el contexto y herramientas para mejorar resultados como la generación de código. También hablé de cómo los sistemas multiagente fomentan la comunicación entre departamentos, creando una experiencia de usuario unificada e impulsando la productividad, la resiliencia y las actualizaciones más rápidas.

El éxito en la construcción de estos sistemas depende de mapear roles y flujos de trabajo, así como de establecer salvaguardas como supervisión humana y controles de errores para garantizar una operación segura. Profundicemos en estos elementos críticos.

Salvaguardias y autonomía

Los agentes implican autonomía, por lo que se deben incorporar varias salvaguardas a un agente dentro de un sistema multiagente para reducir errores, desperdicio, exposición authorized o daños cuando los agentes operan de forma autónoma. Aplicar todas estas salvaguardas a todos los agentes puede ser excesivo y plantear un desafío de recursos, pero recomiendo encarecidamente considerar a todos los agentes del sistema y decidir conscientemente cuáles de estas salvaguardas necesitarían. No se debe permitir que un agente opere de forma autónoma si se cumple alguna de estas condiciones.

Condiciones de intervención humana explícitamente definidas.

Activar cualquiera de un conjunto de reglas predefinidas determina las condiciones bajo las cuales un humano necesita confirmar el comportamiento de algún agente. Estas reglas deben definirse caso por caso y pueden declararse en el indicador del sistema del agente – o, en casos de uso más críticos, aplicarse mediante un código determinista externo al agente. Una de esas reglas, en el caso de un agente de compras, sería: “Todas las compras deben ser verificadas y confirmadas primero por un ser humano. Llame a su función ‘check_with_human’ y no continúe hasta que devuelva un valor”.

Agentes de salvaguarda

Un agente de salvaguardia puede combinarse con un agente con la función de verificar si hay comportamientos riesgosos, poco éticos o de incumplimiento. Se puede obligar al agente a comparar siempre todos o ciertos elementos de su comportamiento con un agente de salvaguardia, y no proceder a menos que el agente de salvaguardia dé el visto bueno.

Incertidumbre

Nuestro laboratorio publicó recientemente un papel en una técnica que puede proporcionar una medida de incertidumbre sobre lo que genera un modelo de lenguaje grande (LLM). Dada la propensión de los LLM a confabular (comúnmente conocida como alucinaciones), dar preferencia a una determinada salida puede hacer que un agente sea mucho más confiable. Aquí también hay que pagar un coste. Evaluar la incertidumbre requiere que generemos múltiples resultados para la misma solicitud de modo que podamos ordenarlos según la certeza y elegir el comportamiento que tenga la menor incertidumbre. Eso puede ralentizar el sistema y aumentar los costos, por lo que debe considerarse para agentes más críticos dentro del sistema.

Botón de desconexión

Puede haber ocasiones en las que necesitemos detener todos los procesos autónomos basados ​​en agentes. Esto podría deberse a que necesitamos coherencia o a que hemos detectado un comportamiento en el sistema que debe detenerse mientras averiguamos qué está mal y cómo solucionarlo. Para flujos de trabajo y procesos más críticos, es importante que esta desconexión no dé como resultado que todos los procesos se detengan o se vuelvan completamente manuales, por lo que se recomienda implementar un modo de operación alternativo determinista.

Órdenes de trabajo generadas por agentes

No todos los agentes dentro de una crimson de agentes necesitan estar completamente integrados en aplicaciones y API. Esto puede llevar un tiempo y se necesitan algunas iteraciones para hacerlo bien. Mi recomendación es agregar una herramienta de marcador de posición genérica a los agentes (normalmente nodos hoja en la crimson) que simplemente emitiría un informe o una orden de trabajo, que contiene acciones sugeridas que se deben tomar manualmente en nombre del agente. Esta es una excelente manera de iniciar y poner en funcionamiento su crimson de agentes de manera ágil.

Pruebas

Con Agentes basados ​​en LLMestamos ganando solidez a costa de la coherencia. Además, dada la naturaleza opaca de los LLM, estamos tratando con nodos de caja negra en un flujo de trabajo. Esto significa que necesitamos un régimen de prueba diferente para los sistemas basados ​​en agentes que el utilizado en el software program tradicional. La buena noticia, sin embargo, es que estamos acostumbrados a probar este tipo de sistemas, ya que hemos estado operando organizaciones y flujos de trabajo impulsados ​​por humanos desde los albores de la industrialización.

Si bien los ejemplos que mostré anteriormente tienen un punto de entrada único, todos los agentes en un sistema multiagente tienen un LLM como cerebro y, por lo tanto, pueden actuar como punto de entrada al sistema. Deberíamos usar divide y vencerás, y primero probar subconjuntos del sistema comenzando desde varios nodos dentro de la jerarquía.

También podemos emplear IA generativa para generar casos de prueba que podamos ejecutar contra la crimson para analizar su comportamiento y obligarla a revelar sus debilidades.

Finalmente, soy un gran defensor del sandboxing. Estos sistemas deberían lanzarse primero a menor escala dentro de un entorno controlado y seguro, antes de implementarse gradualmente para reemplazar los flujos de trabajo existentes.

Sintonia FINA

Un error común con respecto a la IA de generación es que mejora cuanto más la usas. Obviamente esto está mal. Los LLM están previamente capacitados. Dicho esto, se les puede ajustar para sesgar su comportamiento de varias maneras. Una vez que se ha diseñado un sistema multiagente, podemos optar por mejorar su comportamiento tomando los registros de cada agente y etiquetando nuestras preferencias para construir un corpus de ajuste.

Escollos

Los sistemas multiagente pueden caer en picada, lo que significa que en ocasiones una consulta puede no terminar nunca y los agentes hablan perpetuamente entre sí. Esto requiere algún tipo de mecanismo de tiempo de espera. Por ejemplo, podemos consultar el historial de comunicaciones de una misma consulta, y si crece demasiado o detectamos un comportamiento repetitivo, podemos finalizar el flujo y empezar de nuevo.

Otro problema que puede ocurrir es un fenómeno que llamaré sobrecarga: esperar demasiado de un solo agente. El estado precise de la técnica para los LLM no nos permite entregar a los agentes instrucciones largas y detalladas y esperar que las sigan todas, todo el tiempo. Además, ¿mencioné que estos sistemas pueden ser inconsistentes?

Una mitigación para estas situaciones es lo que yo llamo granularización: dividir los agentes en múltiples agentes conectados. Esto scale back la carga sobre cada agente y hace que los agentes sean más consistentes en su comportamiento y menos propensos a caer en picada. (Un área interesante de investigación que está llevando a cabo nuestro laboratorio es la automatización del proceso de granularización).

Otro problema común en la forma en que se diseñan los sistemas multiagente es la tendencia a definir un agente coordinador que llama a diferentes agentes para completar una tarea. Esto introduce un único punto de falla que puede resultar en un conjunto bastante complejo de roles y responsabilidades. Mi sugerencia en estos casos es considerar el flujo de trabajo como un proceso en el que un agente completa parte del trabajo y luego se lo entrega al siguiente.

Los sistemas multiagente también tienen la tendencia a pasar el contexto a otros agentes a lo largo de la cadena. Esto puede sobrecargar a esos otros agentes, puede confundirlos y, a menudo, es innecesario. Sugiero permitir que los agentes mantengan su propio contexto y restablecer el contexto cuando sabemos que estamos tratando con una nueva solicitud (algo así como funcionan las sesiones para los sitios internet).

Finalmente, es importante señalar que existe un listón relativamente alto para las capacidades del LLM utilizado como cerebro de los agentes. Los LLM más pequeños pueden necesitar mucha ingeniería o ajustes rápidos para cumplir con las solicitudes. La buena noticia es que ya existen varios agentes comerciales y de código abierto, aunque relativamente grandes, que superan el listón.

Esto significa que el costo y la velocidad deben ser una consideración importante al construir un sistema multiagente a escala. Además, se deben establecer expectativas de que estos sistemas, si bien son más rápidos que los humanos, no serán tan rápidos como los sistemas de software program a los que estamos acostumbrados.

Babak Hodjat es CTO de IA en Competente.