Sentarme de cerca con este tema y me trajo algunas experiencias de trabajar en un par de proyectos.
Considere este escenario: ofrece una función basada en LLM, la demostración es limpia y todas las partes interesadas están contentas. Luego, tres semanas después de comenzar la producción, algo se rompe de una manera que nadie puede explicar.
Pasas una tarde mirando registros que te dicen qué pasó pero no por qué.
Luego resulta que el marco se tragó el contexto en algún lugar entre los pasos tres y cuatro, y ahora estás leyendo el código fuente que no escribiste.
Ese no es un informe de error; es una llamada de atención sobre la arquitectura.
Marcos como LangChain permiten a los ingenieros construir sistemas basados en LLM sin comprender primero cómo funcionan esos sistemas bajo presión. Al principio parece que ha llegado la caballería.
Pero créame, el costo no aparece hasta que se encuentra inmerso en un incidente de producción y ahora se pregunta por qué su agente se saltó el paso de verificación que se suponía debía ejecutar.
Esta publicación trata sobre ese costo y por qué cada vez más ingenieros, después de descubrirlo, ahora están construyendo la capa de orquestación por sí mismos.
Dale a LangChain su crédito
Recuerdo haber visto a un colega construir un oleoducto RAG funcional en unos cuarenta minutos a principios de 2023.
Pasó desde la tienda de vectores a través de la cadena de recuperación, las plantillas de mensajes y la llamada de LLM, todo conectado a la hora del almuerzo.
Seis meses antes, ese habría sido un proyecto de al menos dos semanas.
Ahora que lo pienso, así es como y por qué LangChain se extendió tan rápido.
La mayoría de los ingenieros no habían creado aplicaciones LLM antes. Nadie tenía opiniones firmes sobre la forma correcta de estructurar una cadena de recuperación o gestionar la memoria de conversaciones y otras cosas por el estilo.
LangChain apareció con respuestas que eran modulares, componibles y documentadas y, por supuesto, los equipos las tomaron de inmediato, incluido el mío.
Entonces, cuando digo que crea problemas en la producción, no estoy siendo desdeñoso. Fue optimizado para la fase en la que se encontraban la mayoría de los equipos cuando lo adoptaron. Los problemas vinieron después, cuando cambió de fase.
Donde se rompe la abstracción
Cuando estaba aprendiendo programación orientada a objetos en mi segundo año, uno de los primeros conceptos que encajó fue la abstracción: ocultar los detalles internos de cómo funciona algo y exponer solo lo que el usuario necesita.
LangChain aplica la misma idea a la orquestación de LLM. Oculta gran parte de lo que sucede dentro de su sistema para que pueda moverse más rápido.
Pero los sistemas de producción de IA exigen algo que va en contra de eso: claridad.
Necesita saber exactamente qué hizo su sistema, en qué orden, con qué entradas y por qué. No aproximadamente. Exactamente.
Las abstracciones cambian esa visibilidad por velocidad. Al principio es un trato justo, hasta que la complejidad oculta se convierte en lo que necesitas entender.
Y se muestra en más de un sentido.
La depuración es peor de lo que parece: cuando una cadena de varios pasos genera un resultado incorrecto, no estás simplemente depurando tu propio código. También está intentando comprender el flujo de ejecución del marco y qué estaba haciendo la capa de devolución de llamada detrás de escena.
Una vez pasé tres horas rastreando una falla que resultó ser un módulo de memoria que silenciosamente cortaba el contexto. La solución en sí tomó cuatro minutos. Encontrar la causa tomó medio día porque la abstracción hacía invisible el comportamiento real.
La observabilidad toca un techo: puedes integrar LangSmith y obtener rastros útiles, pero aún estás viendo las cosas a través de la lente del marco, limitado a los tramos que elige exponer. Cuando necesita visibilidad de algo específico de su lógica empresarial, termina trabajando en torno al modelo de datos del marco en lugar de simplemente medir lo que realmente importa.
El estado de múltiples agentes es donde las cosas realmente se desmoronan: en el momento en que tienes agentes coordinando, uno planificando, otros ejecutando y otro verificando, el estado compartido se convierte en el verdadero problema.
¿Quién creó esta información, cuándo y sigue siendo válida?
Un agente actualiza la memoria, otro lee una versión obsoleta y el coordinador toma una decisión basada en un contexto que ya no coincide con la realidad.
El estado administrado por el marco tiende a funcionar bien para el camino feliz y falla silenciosamente en los casos extremos. Los sistemas de producción viven en esos casos extremos.
La latencia se acumula: cada capa de abstracción agrega una sobrecarga a través de la serialización, la validación, la activación de devolución de llamada y el enrutamiento interno que se ejecuta, lo necesite o no.
En un prototipo, esa sobrecarga es invisible. Bajo tráfico real, aparece en latencia percentil, específicamente en los rangos p95 y p99 donde los usuarios realmente lo sienten.
El costo por llamada puede ser pequeño, pero en un sistema de agencia que realiza cuatro, cinco o incluso seis llamadas modelo por solicitud de usuario, esos pequeños costos se acumulan rápidamente.
En algún momento, tendrás que preguntarte si esos gastos generales todavía valen lo que te aportan.
Nada de esto es imposible de resolver dentro de un marco. Pero las correcciones empiezan a parecer como trabajar alrededor del marco en lugar de trabajar con él. Y una vez que llegas allí, resulta más difícil saber qué te ofrece todavía el marco.
Entonces, ¿cómo es realmente “construirlo usted mismo”?
La “arquitectura de agentes nativos” suena más compleja de lo que realmente es. Simplemente significa escribir la lógica de orquestación usted mismo como código de su propiedad, en lugar de depender de la abstracción de la misma por parte de un marco.
El estado es algo que usted define y actualiza explícitamente. Las herramientas son funciones claras que puedes probar por sí solas. La memoria es el código que usted escribió, por lo que es más fácil depurar, controlar y comprender qué se almacena y cómo se recupera.
La llamada al modelo es su código, lo que significa que puede instrumentarlo directamente y rastrear lo que importa.
Claro, habrá más código por adelantado. Pero cuando algo falla, la falla está en su código y no en algún lugar dentro de un modelo de ejecución escrito por otra persona.
No olvidemos que aquí los flujos de trabajo complejos se asignan de forma más natural. Cosas como la ejecución paralela, la bifurcación condicional y las tareas asíncronas de larga duración funcionan mucho mejor en patrones controlados por eventos de maneras que la ejecución en cadena síncrona no se maneja limpiamente.
Más trabajo de diseño por adelantado significa menos lucha contra incendios en el futuro.
He visto equipos reconstruir un prototipo LangChain perfectamente bueno en una capa de orquestación personalizada solo porque las arquitecturas nativas parecían más “serias”. Pasaron tres semanas más en ello y enviaron el mismo sistema con más código que mantener.
Para mí eso no es progreso.
Si está comprobando si vale la pena desarrollar una característica, entonces un marco lo llevará allí más rápido. Si tres personas usan el sistema internamente y no hay ningún busca conectado, la sobrecarga de abstracción está bien.
La pregunta no es “¿marco o nativo?” Es lo que necesitas optimizar ahora mismo. La iteración rápida sobre requisitos inciertos significa que el marco tiene sentido. Usuarios reales, acuerdos de nivel de servicio reales, coordinación de agentes y monitoreo operativo significan que la arquitectura nativa gana su costo inicial.
La mayoría de los equipos llegan a ese punto de inflexión antes de lo esperado, generalmente en la primera sesión de depuración seria o la primera vez que alguien solicita métricas detalladas, y la respuesta honesta es “no sin mucho trabajo adicional”.
Ese es el momento de repensar la arquitectura, no después de seis meses de acumular soluciones alternativas.
Los marcos son la forma en que se transfiere el conocimiento en un nuevo campo. LangChain hizo que el desarrollo de aplicaciones LLM fuera accesible para una generación de ingenieros. Ese aporte es real.
Pero la madurez en un dominio parece pasar de “configuro el marco para hacer la cosa” a “entiendo lo que estaba haciendo el marco y tomo esas decisiones yo mismo”.
No porque los frameworks sean malos, sino porque ser dueño de tu arquitectura significa que sabes lo que sucede bajo el capó.
Los ingenieros que construyen los sistemas de IA de producción más confiables no son los que tienen las herramientas más sofisticadas.
Ellos son los que pueden explicar exactamente qué hace su sistema en cualquier momento. Qué mensaje se construye, desde qué contexto, bajo qué condiciones y con qué respaldo.
Esa claridad es difícil de mantener a través de gruesas capas de abstracción.
Pensamientos finales
La deuda de abstracción es silenciosa hasta que se vuelve ruidosa. No lo notarás durante la construcción. Lo notarás cuando algo falla de una manera que el mensaje de error del marco no puede explicar.
Ese momento llega antes de lo esperado, generalmente provocado por una sesión de depuración o una solicitud de monitoreo en lugar de una reunión de planificación.
El estado y la observabilidad no son opcionales. Si no puede rastrear lo que hizo su agente y por qué, en realidad no está mejorando el sistema. Solo esperas lo mejor cada vez que te vuelves a implementar.
Trate la orquestación como una decisión arquitectónica real. Elíjalo a propósito, con las compensaciones visibles.
Los ingenieros que construyen sistemas de IA duraderos no son los que evitaron los marcos. Ellos son los que supieron cuándo dejar de dejar que el marco decidiera por ellos.
¡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