Orquestadores: LangChain, LangGraph y LlamaIndex
Qué abstrae cada uno, dónde se solapan y cuál encaja con flujos lineales, con grafos o con indexación intensiva.
Penúltima entrega del bloque de plataformas. Resuelto dónde viven los vectores, queda quién coordina el flujo. Tres bibliotecas dominan la conversación, se solapan bastante y se comparan mal, casi siempre porque no se distingue qué abstrae cada una.
Un orquestador no aporta ninguna capacidad nueva a un sistema RAG. Todo lo que hacen estas bibliotecas se puede escribir a mano: llamar a un modelo de embeddings, consultar un índice, montar un prompt, llamar a un modelo generador. Lo que aportan es estructura, integraciones y vocabulario compartido, y por eso su valor depende mucho más del tamaño del equipo y de la complejidad del flujo que de la calidad del código que generan.
LangChain: componer y conectar
LangChain nació como una capa de composición: una interfaz común para modelos, almacenes de vectores, cargadores de documentos, divisores de texto y herramientas, más una forma de encadenar todo eso.
Su aportación real es el catálogo de integraciones. Cambiar de proveedor de embeddings, de base vectorial o de modelo generador es cambiar una clase por otra, y eso tiene un valor concreto en una fase de exploración donde vas a probar cuatro combinaciones antes de decidir. También aporta un montón de piezas ya escritas —divisores, cargadores, recuperadores con distintas estrategias, plantillas— que ahorran código de baja intensidad intelectual.
Su modelo de composición actual es una interfaz declarativa donde los componentes se encadenan con un operador de tubería, con soporte homogéneo para invocación síncrona, asíncrona, por lotes y en flujo continuo. Esa homogeneidad es la parte más útil: conseguir streaming y ejecución por lotes correctos a mano es tedioso.
Su límite aparece cuando el flujo deja de ser lineal. Las cadenas se leen bien cuando A lleva a B y B lleva a C; en cuanto hay una decisión que puede volver atrás, un bucle o un estado que sobrevive entre pasos, la abstracción empieza a estorbar. Fue justamente esa presión la que produjo LangGraph.
LangGraph: estado, ciclos y decisiones
LangGraph, del mismo equipo, cambia la metáfora: en lugar de una cadena, un grafo de estados. Se define un objeto de estado, unos nodos que lo transforman y unas aristas que pueden ser condicionales, de modo que el flujo puede ramificar, converger y volver sobre sus pasos.
Esa forma encaja exactamente con las técnicas que vimos en el bloque tercero. Un Corrective RAG de la entrega 19 es un grafo: recuperar, evaluar la relevancia de lo recuperado, y según el resultado responder o reformular la consulta y volver a recuperar. Un agente de la entrega 21 es un grafo con un nodo que decide qué herramienta usar y una arista que devuelve el control al mismo nodo tras cada paso. Escrito como cadena lineal, eso es un enredo; escrito como grafo, se lee.
Aporta además tres cosas que a mano cuestan trabajo: persistencia del estado entre invocaciones, que es lo que permite conversaciones de varios turnos y reanudar un flujo interrumpido; puntos de interrupción para meter una aprobación humana en mitad del proceso; y un límite explícito de iteraciones, que es la red de seguridad ante un bucle que no converge.
El precio es conceptual. Definir un grafo de estados para un flujo que en realidad es lineal añade ceremonia sin ganancia. Si tu RAG es recuperar, montar prompt y responder, LangGraph es un martillo desproporcionado.
LlamaIndex: indexación y estructuras de recuperación
LlamaIndex ataca la otra mitad del problema. Su centro de gravedad no es el flujo, sino cómo se estructura el corpus y cómo se recupera de él.
Ahí es donde ofrece más que las otras dos: conectores de datos hacia decenas de orígenes, un modelo de nodos con relaciones explícitas entre fragmentos —padre, hijo, anterior, siguiente— que hace natural el patrón padre-hijo de la entrega 10, recuperadores por ventana de frases, resumen jerárquico de documentos largos, índices de árbol y de grafo de conocimiento, y enrutamiento de la consulta entre varios índices.
Si tu problema es que los documentos son largos, heterogéneos y con estructura interna que importa —informes con secciones, manuales con jerarquía, colecciones que exigen decidir primero en qué subconjunto buscar—, LlamaIndex trae hecho lo que en otra biblioteca tendrías que montar.
Su parte débil, simétricamente, es la orquestación compleja: tiene abstracciones de agentes y de flujos, pero no es donde ha puesto su esfuerzo. Y comparte con LangChain un problema de superficie: hay varias formas de hacer lo mismo, con distintos niveles de abstracción, y la documentación no siempre deja claro cuál es la vigente.
Dónde se solapan y dónde no
El solapamiento es amplio y es la causa de casi toda la confusión. Las tres cargan documentos, trocean, calculan embeddings, hablan con bases vectoriales y construyen prompts. Se pueden usar juntas —es habitual indexar con LlamaIndex y orquestar con LangGraph— y ninguna impide usar la otra.
La forma útil de distinguirlas es por dónde está su centro de gravedad:
| Tipo de flujo | Encaje | Por qué |
|---|---|---|
| RAG lineal: recuperar, montar prompt, responder | Código plano, o LangChain si vas a cambiar de piezas | No hay complejidad que abstraer |
| Híbrido con reranking y varias fuentes | LangChain o LlamaIndex | Componentes ya escritos y una interfaz común |
| Corpus con jerarquía, ventanas y padre-hijo | LlamaIndex | Su modelo de nodos con relaciones está pensado para esto |
| Enrutamiento entre varios índices | LlamaIndex | Los enrutadores de consulta son una abstracción propia |
| Corrective o Self-RAG con bucle de verificación | LangGraph | Aristas condicionales y límite de iteraciones |
| Agente con herramientas y varios pasos | LangGraph | Estado persistente y control del ciclo |
| Conversación multiturno con memoria | LangGraph | Persistencia del estado entre invocaciones |
| Flujo con aprobación humana intermedia | LangGraph | Puntos de interrupción y reanudación |
El coste de la abstracción
Esta parte se cuenta poco y conviene decirla entera.
Dependencias. Instalar uno de estos paquetes con sus integraciones arrastra un árbol de dependencias considerable. Cada una es una superficie de actualización, un posible conflicto de versiones y algo que auditar si tu organización revisa el suministro de software. En un contenedor de producción, eso pesa en el tamaño de la imagen y en el tiempo de arranque.
Depuración opaca. Es el coste más real. Cuando una respuesta sale mal, quieres ver el prompt exacto que llegó al modelo, con los fragmentos en el orden en que se pegaron. Con varias capas de abstracción entre tu código y la llamada, ese prompt está construido tres niveles más abajo, y llegar a él implica activar trazas, leer código ajeno o instrumentar. En un RAG escrito a mano, ese prompt es una variable que puedes imprimir.
Velocidad de cambio. Estas bibliotecas se mueven muy deprisa. Han reorganizado sus paquetes, cambiado interfaces recomendadas y depreciado abstracciones enteras en cuestión de meses. La consecuencia práctica: casi todos los ejemplos y tutoriales que encuentres estarán escritos para una versión que ya no es la vigente, y el código que escribas hoy exigirá mantenimiento por razones que no tienen nada que ver con tu producto. Fija versiones exactas y planifica actualizaciones deliberadas en lugar de sufrirlas.
Rendimiento y control. Las capas añaden latencia —poca, pero medible— y, más importante, esconden decisiones. Cuántos tokens se reservan para el contexto, cómo se truncan los fragmentos que no caben, en qué orden se colocan, qué se hace si el recuperador devuelve cero resultados: todo eso son decisiones de calidad que la biblioteca toma por defecto y que tú deberías estar tomando conscientemente, porque son exactamente las que vimos en la entrega 06.
Cuándo compensa
La regla que funciona: el orquestador compensa en proporción a la complejidad del flujo y al número de piezas que vas a cambiar.
Compensa claramente en la fase de exploración, cuando vas a probar tres bases vectoriales y dos modelos de embeddings antes de decidir; en flujos con ciclos, estado o decisiones, donde escribir la máquina de estados a mano es reinventar LangGraph peor; en corpus con estructura jerárquica no trivial, donde LlamaIndex trae hecho el trabajo; y en equipos grandes, donde tener un vocabulario y una estructura comunes reduce la variabilidad entre personas.
No compensa cuando el flujo es lineal y estable, cuando las piezas ya están decididas, cuando el equipo es de una o dos personas que conocen bien el dominio, o cuando la latencia y el control fino del prompt son requisitos duros. Y no compensa nunca como sustituto de entender qué hace el sistema: usar un orquestador sin saber qué prompt se está enviando es el camino más corto a un RAG que falla sin que nadie sepa por qué.
Qué viene ahora
La siguiente entrega cierra este bloque tomando en serio la alternativa que acaba de asomar: escribir el RAG sin framework. Qué hace realmente el sistema por dentro, por qué eso cabe en unas doscientas líneas, qué se gana en control y depuración, y en qué momento concreto conviene rendirse y adoptar una biblioteca. Es una entrega de nivel avanzado, con el esqueleto de un RAG mínimo comentado.
Los tres libros gratuitos de los que nace esta serie están disponibles en PDF y EPUB: RAG para tu negocio (nivel básico), RAG por dentro (intermedio) y RAG en producción (avanzado).
Aviso de contenido generado con inteligencia artificial.
Este artículo ha sido redactado con la asistencia de sistemas de inteligencia artificial y revisado antes de su publicación. Se informa de ello de forma expresa en cumplimiento de la normativa vigente sobre transparencia en el uso de IA.
