El sistema de agentes falla seriamente en producción, no fue dramático. No hubo ningún choque. Ningún mensaje de error. El sistema seguía funcionando y produciendo resultados que parecían razonables hasta que alguien los leyó con suficiente atención como para darse cuenta de que algo andaba mal.
Cuando decidimos investigarlo, nos llevó dos días de depuración descubrir qué estaba pasando. Curiosamente, el modelo no estaba alucinando y las herramientas de entrada y salida estaban dando los resultados correctos.
El problema, cuando finalmente lo encontramos, fue arquitectónico. El modelo y las herramientas se configuraron correctamente, pero la idea era que el razonamiento uniera todo el asunto, lo cual, como se puede imaginar, obviamente falló.
Resulta que el razonamiento no hace ese tipo de cosas.
Esa experiencia es a la que sigo volviendo cuando pienso por qué tantos agentes de IA que funcionan en demostraciones no sobreviven al uso en el mundo real.
No es un problema de capacidad.
Es arquitectónico.
Y si ha leído mi artículo anterior aquí sobre TDS, Por qué los ingenieros de IA están avanzando más allá de LangChain hacia arquitecturas de agentes nativos, el patrón debería resultarle familiar: sistemas construidos de arriba hacia abajo, desde el objetivo hasta las herramientas y el modelo, con la tranquila suposición de que el comportamiento inteligente llena los vacíos.
Esa suposición es lo que significa “construido al revés”. Y es más común de lo que la mayoría de los equipos creen hasta que algo se rompe.
Los agentes no son entidades. Son Sistemas.
Un agente de producción de IA no es nada inteligente.
Más bien, hay un conjunto de piezas que interactúan con diferentes responsabilidades, modos de falla y niveles de observabilidad.
El LLM es uno de esos componentes, no el sistema completo. Sólo una parte.
Puede parecer obvio cuando lo dices en voz alta. Pero el marco del “agente autónomo” que dominó 2023 y la mayor parte de 2024 siguió empujando a los ingenieros hacia un modelo mental diferente: una entidad, un bucle de razonamiento, todo manejado por el modelo.
Todo lo que necesita son herramientas, un buen aviso del sistema y la esperanza de que todo encaje.
Por el contrario, los ingenieros que han enviado productos reales basados en IA rara vez describen sus sistemas de esa manera. Lo que realmente describen suena mucho más a una arquitectura de sistemas distribuidos.
No porque leyeron un libro sobre patrones de diseño, sino porque se quemaron tantas veces que comenzaron a poner la estructura más en serio en su flujo de trabajo.
Construir de arriba hacia abajo, empezando por “qué debería hacer este agente” y trabajando hacia atrás en herramientas e indicaciones, es un comienzo rápido.
También es la forma en que terminas con un sistema donde el modelo es responsable de demasiadas cosas y nada se puede depurar individualmente.
La arquitectura se decidió por el objetivo, no por los requisitos de ingeniería.
Esa es la parte al revés.
Entonces, ¿qué implica realmente un sistema de producción?
Es fácil aceptar la versión abstracta. Así es como se ve realmente.
Cada sistema de producción de IA que he visto que funciona limpiamente tiene algo así como una capa de decisión, ya sea que el equipo lo llame así o no. Es la parte donde vive el modelo y hace su trabajo real.
El instinto es empujar todo a esta capa: analizar solicitudes, administrar la memoria, manejar los reintentos, resolver fallas de las herramientas.
Esto está bien si estás trabajando en un cuaderno Jupyter. En producción, bajo carga, con usuarios reales, esto se convierte en la parte de su sistema donde todo es culpa de todos y, la mayoría de las veces, nada se puede depurar.
La capa de decisión debe hacer una cosa bien, y es decidir qué hacer a continuación, dado un contexto determinado que ya está preparado para ello.
Ese es todo el trabajo.
¿Quién prepara el contexto? Otra cosa. ¿Quién actúa sobre la decisión? También algo más.
Ese “algo más” es la capa de orquestación, y en la mayoría de los sistemas bien construidos, es realmente solo código: condicionales, corredores asincrónicos, manejo de reintentos, enrutamiento de colas, tal vez incluso una máquina de estado dependiendo de cuán involucrado esté el flujo de trabajo.
Muchos equipos recurren a marcos aquí porque el código de orquestación simple parece demasiado simple, como si seguramente se supusiera que debería haber más infraestructura.
Generalmente no lo hay.
Cuanta menos magia contenga esta capa, más rápido encontrarás errores cuando aparezcan. Y aparecerán.
Por experiencia, aprendí esto de la manera más difícil en un proyecto donde la orquestación vivía dentro del modelo de ejecución de un marco. Algo estaba reintentando las llamadas a herramientas de una manera que corrompía el estado posterior.
Pasamos dos días buscando el problema. Dos días para un error que podría haberse resuelto en poco tiempo si la lógica de reintento hubiera sido de tres líneas de Python que escribí yo mismo.
Esto nos lleva a la capa de herramientas y ejecución, donde ocurre toda la comunicación.
Ahora, la capa de herramientas y ejecución es donde las cosas hablan con el mundo exterior. Esta capa generalmente tiene una sola tarea, y es tomar una entrada bien definida y luego producir una salida predecible.
Pero el fracaso que seguía viendo y repitiendo, honestamente, eran herramientas que intentaban ser útiles haciendo más de una cosa. Una función única que llama a una API, actualiza un caché y hace otras cosas.
En una configuración como esa, cuando se rompe, no sabes dónde. Incluso cuando intentas reemplazar la API, estás desenredando una lógica que no debería haberse enredado en primer lugar.
La memoria y el estado es donde me esforzaría más, porque es donde la mayoría de los equipos están menos preparados.
La mayoría de los equipos piensan en la memoria como “lo que sabe el modelo”. La pregunta más importante es qué sabe el sistema y si ese conocimiento está actualizado.
Recuerdo un día en el que me llevó una tarde depurar lo que parecía ser una simple “alucinación modelo”. El modelo seguía haciendo referencia a las preferencias del usuario, que, sin embargo, habían sido actualizadas hacía veinte minutos.
Ese no es un problema de modelo.
Ese es un problema de sistemas.
Y es sorprendentemente común.
En los sistemas multiagente, específicamente, el estado compartido es donde se generan fallas sutiles. Un agente actualiza algo. Los demás no lo saben.
Todos avanzan con confianza en direcciones ligeramente diferentes. El resultado parece casi correcto, lo cual es casi peor que verse mal.
Y luego está la evaluación y la observabilidad, que casi todo el mundo siempre pospone hasta que algo sale mal. Yo también he sido culpable de esto.
La diferencia que tengo en cuenta es que el registro te dice lo que pasó. La observabilidad te dice si lo que sucedió fue correcto. En un sistema determinista, son casi lo mismo.
En un sistema de IA, no lo es. Debe poder seguir la solicitud específica de principio a fin, incluida qué información tuvo que considerar el modelo, qué decisión tomó, qué llamada API externa invocó y cómo actuó según su respuesta.
Construyéndolo de la manera correcta
Comienza con el enfoque de arriba hacia abajo: quiero que un agente haga X, así que le daré las herramientas, un buen mensaje del sistema, y si el modelo es lo suficientemente inteligente, todo estará bien.
Y esto es exactamente lo que la gente usa para hacer prototipos, ¿y por qué no lo harían? No se equivocan.
Pero aquí está la cuestión: el problema es que trata la arquitectura como una consecuencia del objetivo y no como algo que se diseña deliberadamente.
Entonces el sistema crece. Ya sabes, más herramientas, más flujos de trabajo, más casos extremos, más usuarios y, de repente, no hay una base real detrás de todo eso.
La opción de abajo hacia arriba requiere más tiempo, pero es mucho más cómoda.
Comienza con los componentes básicos y se asegura de que realmente funcionen. Luego se determina qué debe comunicar cada parte, qué datos posee y de qué es responsable.
Al final, el sistema toma forma de forma natural a partir de la interacción de sus partes.
Este no es el argumento de que “los verdaderos ingenieros construyen todo desde cero”. En realidad, ni siquiera se trata de herramientas. Se trata del modelo mental con el que estás construyendo.
He visto a ingenieros utilizar marcos sofisticados y construir sistemas limpios porque entendían lo que debía hacer cada capa.
También he visto a ingenieros escribir Python básico y crear un desastre que no se puede depurar porque todavía pensaban en términos de “el agente decide todo”. Las herramientas surgen del modelo que tienes en tu cabeza, y no al revés.
El sistema multiagente más robusto con el que he tenido la oportunidad de trabajar estrechamente casi no tenía infraestructura específica de IA. Cuando vi el repositorio por primera vez, honestamente asumí que estaba viendo el código base incorrecto.
Una cola de mensajes, procesos de trabajo con distintos alcances, almacenamiento de estado compartido con contratos explícitos de lectura/escritura y un coordinador que toma decisiones de enrutamiento.
Las consultas del modelo de lenguaje fueron realizadas por los propios trabajadores, y cada uno recibió un conjunto de contexto creado previamente por un proceso diferente.
En total, se trataba de unas mil líneas de Python. He visto agentes de demostración con más código que ese. Cada parte era rastreable.
Cuando algo se comportaba inesperadamente, normalmente encontrábamos el problema en menos de una hora porque no había magia para solucionarlo. Simplemente codifique con un camino claro a través de él.
Ese sistema se construyó de abajo hacia arriba. El objetivo estaba definido, pero la arquitectura no se derivaba de él. Primero se diseñaron los componentes, se evaluaron por sí solos y luego se compusieron para implementar la funcionalidad deseada. Este último es el aspecto más importante, no el primero.
Hacia dónde creo que va esto
Hasta donde puedo decir, la dirección en la que nos dirigimos se está alejando lentamente de los “marcos de agentes” y hacia una infraestructura adecuada, con sistemas de evaluación, enrutamiento de modelos, respaldos y gestión estatal.
Al menos una parte ya existe. La mayoría aún está por llegar a medida que la gente resuelva problemas difíciles de producción en este espacio.
Lo que veo una y otra vez es que las personas que construyen los sistemas más confiables rara vez usan los mejores modelos. En cambio, lo que tienen es una comprensión clara de todo lo que sucede dentro de sus sistemas.
El modelo utilizado por dicho sistema puede ser GPT-4, pero también puede ser un modelo local pequeño. Poco importa que todo lo demás funcione correctamente.
Estamos pasando de tratar el modelo como el producto a tratar el sistema como el producto. El modelo importa, pero es sólo un componente entre muchos.
La mayoría de los agentes no fracasan porque el modelo no fuera lo suficientemente bueno. Fallan porque el sistema alrededor del modelo fue diseñado al revés, partiendo de lo que debería hacer el agente y suponiendo que la arquitectura se solucionaría por sí sola.
No es así.
Construirlo de la manera correcta, primero los componentes y luego el comportamiento, es lo que separa a los sistemas que resisten de los que parecen impresionantes hasta que no lo hacen.
¡Antes de que te vayas!
Escribo más sobre las decisiones reales de ingeniería detrás de los sistemas de IA, dónde ayudan las abstracciones, dónde perjudican y qué se necesita para construir de manera confiable.
Puedes suscribirte a mi boletín si quieres más de eso.
Conéctate conmigo