2025 será el año de los sistemas agénticos

Las piezas van encajando y con la mejora del uso de las herramientas, es hora de empezar a pensar en construir estos sistemas.

Anthropic¹ lleva tiempo trabajando con docenas de equipos que crean grandes agentes de modelos lingüísticos (LLM) en distintos sectores. Y en estas implementaciones se dieron cuenta que el éxito no viene de usar frameworks complicados ni bibliotecas especializadas, sino de usar patrones simples.

Aquí tenéis el resumen de lo que han aprendido trabajando con sus clientes y construyendo agentes eficaces.

¿Qué son los agentes?

«Agente» puede definirse de varias maneras.

• Algunos definen los agentes como sistemas totalmente autónomos que funcionan de forma independiente durante periodos prolongados, utilizando diversas herramientas para realizar tareas complejas.
• Otros utilizan el término para describir implementaciones más prescriptivas que siguen flujos de trabajo predefinidos.

En Anthropic categorizan todas estas variaciones como sistemas agénticos, pero establecen una importante distinción arquitectónica entre flujos de trabajo y agentes:

• Los flujos de trabajo son sistemas en los que los LLM y las herramientas se orquestan a través de rutas de código predefinidas.
• Los agentes, por otro lado, son sistemas en los que los LLM dirigen dinámicamente sus propios procesos y el uso de herramientas, manteniendo el control sobre cómo realizan las tareas.

A continuación se exploran en detalle ambos tipos de sistemas de agentes.

Cuándo (y cuándo no) utilizar agentes

Al crear aplicaciones con LLM, siempre se recomienda encontrar la solución más sencilla posible y aumentar la complejidad sólo cuando sea necesario. Esto puede significar no construir sistemas de agentes. Los sistemas agenticos a menudo cambian la latencia y el coste por un mejor rendimiento de la tarea, y debe considerar cuándo tiene sentido esta compensación.

Cuando se justifica una mayor complejidad, los flujos de trabajo ofrecen previsibilidad y coherencia para tareas bien definidas, mientras que los agentes son la mejor opción cuando se necesita flexibilidad y toma de decisiones basada en modelos a escala. Para muchas aplicaciones, sin embargo, la optimización de llamadas LLM individuales con recuperación y ejemplos en contexto suele ser suficiente.

Cuándo y cómo utilizar frameworks

Existen muchos frameworks que facilitan la implementación de sistemas agénticos, entre los que se incluyen:

• LangGraph de LangChain;
• AI Agent framework de Amazon Bedrock;
• Rivet, un constructor de flujos de trabajo LLM GUI de arrastrar y soltar;
• Vellum, otra herramienta GUI para construir y probar flujos de trabajo complejos; y
• Azure AI Studio y Copilot Studio de Microsoft.

Estos frameworks facilitan los primeros pasos simplificando las tareas estándar de bajo nivel, como la llamada a LLM, la definición y el análisis sintáctico de herramientas y el encadenamiento de llamadas. Sin embargo, a menudo crean capas adicionales de abstracción que pueden ocultar las peticiones y respuestas subyacentes, lo que las hace más difíciles de depurar. También pueden hacer que resulte tentador añadir complejidad cuando bastaría con una configuración más sencilla.

Siempre es bueno empezar utilizando directamente las APIs de LLM: muchos patrones pueden implementarse en unas pocas líneas de código. Si utilizas un framework, asegúrate de que entiendes el código subyacente. Las suposiciones incorrectas sobre lo que hay bajo el capó son una fuente común de errores de los clientes.

Construyendo bloques, flujos de trabajo y agentes

En esta sección, exploraremos los patrones comunes de los sistemas agénticos que hemos visto en producción. Comenzaremos con el bloque de construcción básico, el LLM aumentado, y aumentaremos progresivamente la complejidad, desde flujos de trabajo compositivos sencillos hasta agentes autónomos.

Construyendo bloques: El LLM aumentado

El bloque de construcción básico de los sistemas agenticos es un LLM mejorado con mejoras como la recuperación, las herramientas y la memoria. Los modelos actuales de Anthropic pueden utilizar activamente estas capacidades, generando sus propias consultas de búsqueda, seleccionando las herramientas adecuadas y determinando qué información retener.

Recomendamos centrarse en dos aspectos clave de la implementación: adaptar estas capacidades a su caso de uso específico y asegurarse de que proporcionan una interfaz fácil y bien documentada para tu LLM. Aunque hay muchas formas de implementar estas ampliaciones, una de ellas es a través de nuestro recientemente publicado Protocolo de contexto de modelo, que permite a los desarrolladores integrarse con un creciente ecosistema de herramientas de terceros con una sencilla implementación de cliente.

Para el resto de este post, asumiremos que cada llamada LLM tiene acceso a estas capacidades aumentadas.

Flujo de trabajo: Encadenamiento de peticiones

El encadenamiento de peticiones descompone una tarea en una secuencia de pasos, donde cada llamada LLM procesa la salida de la anterior. Puede añadir comprobaciones programáticas (véase «puerta» en el diagrama siguiente) en cualquier paso intermedio para asegurarse de que el proceso sigue su curso.

Cuándo utilizar este flujo de trabajo: Este flujo de trabajo es ideal para situaciones en las que la tarea puede descomponerse fácil y limpiamente en subtareas fijas. El objetivo principal es compensar la latencia por una mayor precisión, haciendo que cada llamada LLM sea una tarea más sencilla.

Ejemplos en los que el encadenamiento de instrucciones es útil:

• Generar textos de marketing y traducirlos a otro idioma.
• Redactar el esquema de un documento, comprobar que el esquema cumple determinados criterios y, a continuación, redactar el documento basándose en el esquema.

Flujo de trabajo: Enrutamiento

El enrutamiento clasifica una entrada y la dirige a una tarea de seguimiento especializada. Este flujo de trabajo permite separar las tareas y crear instrucciones más especializadas. Sin este flujo de trabajo, la optimización de un tipo de entrada puede perjudicar el rendimiento de otras entradas.

Cuándo utilizar este flujo de trabajo: El enrutamiento funciona bien para tareas complejas en las que hay categorías distintas que se manejan mejor por separado, y en las que la clasificación se puede manejar con precisión, ya sea mediante un LLM o un modelo/algoritmo de clasificación más tradicional.

Ejemplos de utilidad del enrutamiento

• Dirigir diferentes tipos de consultas de atención al cliente (preguntas generales, solicitudes de reembolso, asistencia técnica) a diferentes procesos, avisos y herramientas.
• Dirigir preguntas fáciles/comunes a modelos más pequeños como Claude 3.5 Haiku y preguntas difíciles/inusuales a modelos más capaces como Claude 3.5 Sonnet para optimizar el coste y la velocidad.

Flujo de trabajo: Paralelización

En ocasiones, los LLM pueden trabajar simultáneamente en una tarea y agregar sus resultados mediante programación. Este flujo de trabajo, la paralelización, se manifiesta en dos variantes clave:

• Seccionamiento: Dividir una tarea en subtareas independientes que se ejecutan en paralelo.
• Votación: Ejecutar la misma tarea varias veces para obtener diversos resultados.

Cuándo utilizar este flujo de trabajo: La paralelización es eficaz cuando las subtareas divididas pueden paralelizarse para ganar velocidad, o cuando se necesitan múltiples perspectivas o intentos para obtener resultados de mayor confianza. Para tareas complejas con múltiples consideraciones, los LLM suelen funcionar mejor cuando cada consideración se gestiona mediante una llamada LLM independiente, lo que permite centrar la atención en cada aspecto específico.

Ejemplos en los que la paralelización resulta útil

• Seccionamiento:
  • Implementación de barandillas en las que una instancia del modelo procesa las consultas de los usuarios mientras otra las examina en busca de contenido o solicitudes inapropiados. Esto tiende a funcionar mejor que tener la misma llamada LLM para gestionar tanto los guardarraíles como la respuesta principal.
  • Automatización de pruebas para evaluar el rendimiento de LLM, en las que cada llamada LLM evalúa un aspecto diferente del rendimiento del modelo en una solicitud determinada.
• Votación:
  • Revisión de un fragmento de código en busca de vulnerabilidades, en la que varios avisos diferentes revisan y marcan el código si encuentran un problema.
  • Evaluar si un determinado contenido es inapropiado, con múltiples avisos que evalúan diferentes aspectos o requieren diferentes umbrales de votación para equilibrar falsos positivos y negativos.

Flujo de trabajo: Orquestador-trabajadores

En el flujo de trabajo orquestador-trabajadores, un LLM central divide dinámicamente las tareas, las delega en los LLM trabajadores y sintetiza sus resultados.

Cuándo utilizar este flujo de trabajo: Este flujo de trabajo es adecuado para tareas complejas en las que no se pueden predecir las subtareas necesarias (en codificación, por ejemplo, el número de archivos que deben modificarse y la naturaleza del cambio en cada archivo probablemente dependan de la tarea). Aunque topográficamente es similar, la diferencia clave con la paralelización es su flexibilidad: las subtareas no están predefinidas, sino que las determina el orquestador en función de la entrada específica.

Ejemplo de utilidad de los orquestadores-trabajadores:

• Codificación que realiza cambios complejos en varios archivos cada vez.
• Tareas de búsqueda que implican recopilar y analizar información de múltiples fuentes en busca de posible información relevante.

Flujo de trabajo: Evaluador-optimizador

En el flujo de trabajo evaluador-optimizador, una llamada LLM genera una respuesta mientras que otra proporciona evaluación y retroalimentación en un bucle.

Cuándo utilizar este flujo de trabajo: Este flujo de trabajo es particularmente eficaz cuando tenemos criterios de evaluación claros, y cuando el refinamiento iterativo proporciona un valor medible. Los dos signos de una buena adaptación son, en primer lugar, que las respuestas del LLM pueden mejorarse de forma demostrable cuando un humano articula su retroalimentación; y en segundo lugar, que el LLM puede proporcionar dicha retroalimentación. Esto es análogo al proceso iterativo de escritura por el que puede pasar un escritor humano al producir un documento pulido.

Ejemplos en los que el evaluador-optimizador resulta útil:

• Traducción literaria en la que hay matices que el LLM traductor puede no captar inicialmente, pero en la que un LLM evaluador puede aportar críticas útiles.
• Tareas de búsqueda complejas que requieren múltiples rondas de búsqueda y análisis para recopilar información exhaustiva, en las que el evaluador decide si se justifican más búsquedas.

Agentes

Los agentes están apareciendo en la producción a medida que los LLM maduran en capacidades clave: comprensión de entradas complejas, razonamiento y planificación, uso fiable de herramientas y recuperación de errores. Los agentes comienzan su trabajo con una orden del usuario humano o una conversación interactiva con él. Una vez que la tarea está clara, los agentes planifican y operan de forma independiente, pudiendo volver al humano para obtener más información o juicio. Durante la ejecución, es crucial que los agentes obtengan la «verdad sobre el terreno» del entorno en cada paso (como resultados de llamadas a herramientas o ejecución de código) para evaluar su progreso. Los agentes pueden hacer una pausa para recibir información humana en los puntos de control o cuando se encuentren con bloqueos. La tarea suele terminar al finalizar, pero también es habitual incluir condiciones de parada (como un número máximo de iteraciones) para mantener el control.

Los agentes pueden manejar tareas sofisticadas, pero su implementación suele ser sencilla. Normalmente son sólo LLM que utilizan herramientas basadas en la retroalimentación del entorno en un bucle. Por tanto, es crucial diseñar conjuntos de herramientas y su documentación de forma clara y meditada. En el Apéndice 2 («Ingeniería de sus herramientas») se describen las mejores prácticas para el desarrollo de herramientas.

Cuándo utilizar agentes: Los agentes pueden utilizarse para problemas abiertos en los que es difícil o imposible predecir el número de pasos necesarios y en los que no se puede codificar una ruta fija. El LLM funcionará potencialmente durante muchos turnos, y debes tener cierto nivel de confianza en su toma de decisiones. La autonomía de los agentes los hace ideales para escalar tareas en entornos de confianza.

La naturaleza autónoma de los agentes implica mayores costes y la posibilidad de que los errores se agraven. Recomendamos realizar pruebas exhaustivas en entornos aislados, junto con las barreras de seguridad adecuadas.

Ejemplos de utilidad de los agentes (ejemplos de Anthropic):

• Un agente de programación para resolver tareas de SWE-bench, que implican ediciones de muchos archivos basadas en la descripción de una tarea;
• La implementación de referencia de «uso del ordenador», en la que Claude utiliza un ordenador para realizar las tareas.

Combinación y personalización de estos patrones

Estos bloques de construcción no son prescriptivos. Son patrones comunes que los desarrolladores pueden moldear y combinar para adaptarlos a diferentes casos de uso. La clave del éxito, como con cualquier otra característica LLM, es medir el rendimiento e iterar sobre las implementaciones. Sólo se debe considerar la posibilidad de añadir complejidad cuando se demuestre que mejora los resultados.

Resumen

El éxito en el espacio LLM no consiste en construir el sistema más sofisticado. Se trata de construir el sistema adecuado a sus necesidades. Empiece con indicaciones sencillas, optimícelas con una evaluación exhaustiva y añada sistemas de agentes de varios pasos sólo cuando las soluciones más sencillas se queden cortas.

Al implantar agentes, intentamos seguir tres principios básicos:

1. Mantener la sencillez en el diseño del agente.
2. Dar prioridad a la transparencia mostrando explícitamente los pasos de planificación del agente.
3. Elabora cuidadosamente tu interfaz agente-ordenador (ACI) mediante una exhaustiva documentación y pruebas de la herramienta.

Los frameworks pueden ayudarle a empezar rápidamente, pero no dude en reducir las capas de abstracción y construir con componentes básicos a medida que avanza hacia la producción. Siguiendo estos principios, podrá crear agentes que no sólo sean potentes, sino también fiables, mantenibles y en los que confíen sus usuarios.

¿Quieres saber más sobre las soluciones de inteligencia artificial generativa de Microsoft? En DQS/ te asesoramos. ¿Por qué no nos preguntas cómo podemos ayudarte?

Información basada en la publicación Building effective agents de Anthropic.

1. Anthropic es una empresa estadounidense de investigación y desarrollo de inteligencia artificial (IA) fundada en 2021 por antiguos miembros de OpenAI, notablemente los hermanos Dario y Daniela Amodei. La misión de Anthropic se centra en desarrollar sistemas de IA que sean seguros, fiables y alineados con los valores humanos. La empresa se distingue por su enfoque en la ética y la seguridad en el desarrollo de la IA, promoviendo un uso responsable de esta tecnología.
   Anthropic ha desarrollado un modelo de lenguaje conocido como Claude, que compite con otros modelos como ChatGPT de OpenAI y Gemini de Google. Claude está diseñado para comprender y generar texto de manera natural, con un énfasis particular en evitar contenido perjudicial o sesgado y en proporcionar fuentes para respaldar sus respuestas.
   Además de su trabajo en modelos de lenguaje, Anthropic ha recibido significativas inversiones de compañías como Google y Amazon, convirtiéndose en un jugador importante en el paisaje de la IA. Su enfoque incluye la investigación en la creación de sistemas que minimicen riesgos, abordando problemas como el sesgo, la desinformación y la falta de transparencia en los modelos de IA. ↩︎