RAG Frameworks: LangChain frente a LangGraph frente a LlamaIndex

Comparamos 5 frameworks RAG: LangChain, LangGraph, LlamaIndex, Haystack y DSPy, construyendo el mismo flujo de trabajo RAG agéntico con componentes estandarizados: modelos idénticos (GPT-4.1-mini), embeddings (BGE-small), recuperador (Qdrant) y herramientas (búsqueda web de Tavily). Esto aísla la verdadera sobrecarga y eficiencia de tokens de cada framework.

RAG frameworks: resultados del benchmark

El benchmark consistió en 100 consultas, y cada framework ejecutó el conjunto completo 100 veces para proporcionar promedios estables.

• Tokens promedio: Total de tokens consumidos en todas las llamadas LLM (enrutador, evaluador de documentos, evaluador de respuestas y generador), incluye tanto prompts (con contexto recuperado) como completions. Menor = menor coste de API.
• Sobrecarga del framework: Tiempo puro de orquestación (ms), el procesamiento interno del framework (lógica de enrutamiento, gestión de estado, etc.), excluyendo llamadas LLM y API y herramientas. Menor = framework más ligero.

Todas las implementaciones lograron un 100 % de precisión en el conjunto de pruebas. Se usaron los mismos modelos, temperaturas, proveedor de recuperación, herramienta de búsqueda web y un límite compartido de tokens de contexto.

Conclusiones clave

1. Nos centramos en controlar lo que se puede controlar: Misma familia de modelos y temperaturas, max_tokens a nivel de nodo, recuperador (Qdrant + BGE-small, k=5, normalización activada), proveedor web (solo Tavily), política del enrutador (heurística + modelo), retorno temprano de la calculadora, límite compartido de tokens de contexto, rúbrica de evaluación idéntica, instrumentación unificada. Esto reduce sustancialmente los principales factores de confusión en nuestras mediciones.
2. La sobrecarga del framework es medible pero pequeña: Observamos ~3–14 ms por consulta provenientes de la lógica de orquestación. Estas diferencias son reales, pero no son la principal fuente de las brechas de latencia >1 s; la mayor parte del tiempo se dedica a E/S con modelos/herramientas externos.
3. El rendimiento sigue a los tokens (bajo estas restricciones): DSPy muestra la sobrecarga del framework más baja (~3.53 ms). Haystack (~5.9 ms) y LlamaIndex (~6 ms) le siguen, mientras que LangChain (~10 ms) y LangGraph (~14 ms) son más altos. El uso de tokens es más bajo en Haystack (~1.57k), luego LlamaIndex (~1.60k); DSPy y LangGraph están en ~2.03k, y LangChain en ~2.40k.
4. La ruta de enrutamiento/herramientas importa: Pequeños cambios en el enrutamiento inicial (recuperador frente a web frente a calculadora) y en el comportamiento de fallback afectan tanto a los tokens como al tiempo, incluso cuando los prompts y los presupuestos están alineados.

¿Por qué persisten las diferencias? El “ADN del framework”

A pesar de la estandarización, persisten pequeñas variaciones en el recuento de tokens y en la latencia. Estas son atribuibles a los comportamientos inherentes de bajo nivel de cada framework, su “ADN”.

• Serialización de prompts y mensajes: Cada framework envuelve el mismo contenido lógico con un formato ligeramente diferente antes de enviarlo al LLM, creando deltas de tokens pequeños pero consistentes.
• Ensamblaje del contexto: El orden exacto y la inclusión de metadatos dentro del contexto concatenado pueden diferir ligeramente según el framework, lo que afecta al recuento final de tokens.
• Desempates de enrutamiento: En casos límite, las diferencias sutiles en cómo el framework analiza la salida JSON del enrutador pueden dar lugar a una elección inicial de herramienta distinta.

En esta configuración, la huella de tokens parece ser el principal factor, más que el tiempo de ejecución del framework.

La arquitectura RAG agéntica compartida

Para lograr una comparación justa, las cinco implementaciones se construyeron sobre el mismo flujo de control:

• Enrutador: Un nodo híbrido de modelo y heurística que elige recuperador, búsqueda web o calculadora.
• Recuperar documentos: Obtiene los 5 documentos principales de Qdrant usando embeddings normalizados de BGE-small.
• Evaluar documentos: Un juez LLM evalúa la relevancia de los documentos. Si son irrelevantes, activa una búsqueda web de respaldo.
• Generar respuesta: Usa un LLM con temperature=0.0 y un límite compartido de tokens de contexto para generar una respuesta preliminar.
• Evaluar respuesta: Un segundo juez LLM evalúa el borrador en cuanto a fundamentación, contradicciones (alucinaciones) y completitud.
• Respaldo y retorno temprano: Se activa una búsqueda web si la calificación de la respuesta es insuficiente. Sin embargo, los resultados de la calculadora se devuelven directamente, omitiendo los pasos de generación y evaluación.

Ejemplos de flujo de trabajo

Escenario A: acierto directo desde la base de datos:

Escenario B: un evento reciente activa la herramienta web:

Escenario C: la calculadora proporciona un retorno temprano:

Escenario D: base de datos vectorial insuficiente, recurre a la búsqueda web:

RAG frameworks: metodología

Las cinco implementaciones lograron un 100 % de precisión en nuestro conjunto de pruebas de 100 consultas, coincidiendo con las respuestas de referencia. Este fue el requisito fundamental, que garantizaba que cada framework pudiera ejecutar con éxito el mismo flujo de trabajo RAG agéntico antes de medir las diferencias de rendimiento.

1. Componentes principales y configuración

Las herramientas fundamentales se estandarizaron para eliminar las variables de rendimiento en el origen.

• LLMs:
  • Modelo: Todos los nodos (enrutador, generador, evaluador) usaron el modelo openai/gpt-4.1-mini a través de la OpenRouter API.
  • Determinismo: la temperatura se fijó en 0.0 para todas las llamadas LLM con el fin de garantizar la máxima consistencia en enrutamiento, generación y evaluación.
  • Límites de tokens: Se aplicaron límites estrictos de max_tokens: 256 para el enrutador y los evaluadores, y 512 para el generador. Esto evita diferencias de latencia causadas por un framework que genere respuestas excesivamente largas.
• Modelo de embedding y recuperación:
  • Modelo: Todos los frameworks utilizaron BAAI/bge-small-en-v1.5 de HuggingFace.
  • Normalización: Un paso crítico para el rendimiento, normalize_embeddings se estableció en True en los cinco frameworks. (LangChain/LangGraph mediante encode_kwargs; LlamaIndex mediante normalize=True; Haystack mediante normalize_embeddings; recuperador de DSPy normalizado.)
  • Recuperación: Se consultó el almacén vectorial Qdrant para un k=5 (5 documentos principales) en todas las implementaciones.
• Herramientas:
  • Búsqueda web: El benchmark se restringió a solo Tavily (max_results=3).
  • Calculadora: Las cinco implementaciones usaron la biblioteca sympy para el análisis y la evaluación de expresiones matemáticas, garantizando capacidades idénticas.

2. RAG: flujo de control y política

El proceso de “toma de decisiones” del agente se replicó explícitamente en todos los casos.

• Lógica de enrutamiento: Se implementó una estrategia de enrutamiento híbrida en los cinco scripts para equilibrar la inteligencia del modelo con reglas deterministas:
  1. Una heurística basada en regex, heuristic_route, comprueba primero los patrones obvios de calculadora o búsqueda web (por ejemplo, símbolos matemáticos, años como “2024”).
  2. A continuación, un nodo enrutador LLM toma su propia decisión.
  3. La decisión final prioriza la heurística para las calculadoras; en caso contrario, se remite a la elección del LLM.
• Presupuestación del contexto: Esta es una de las estandarizaciones más críticas. Antes de llamar al nodo generate_answer, todo el contexto de los documentos recuperados y los resultados de la búsqueda web se concatenan y luego se truncan a un límite compartido de 2000 tokens mediante una utilidad común truncate_to_token_budget. Esto asegura que el LLM generador de cada framework reciba una entrada exactamente del mismo tamaño, evitando que un único framework se vea beneficiado o perjudicado por la verbosidad del contexto recuperado.
• Política de evaluación de respuestas:
  • Rúbrica indulgente: El nodo grade_answer utiliza un prompt idéntico e indulgente en todos los frameworks, indicando al juez LLM que acepte respuestas semánticamente similares y razonablemente completas.
  • Gestión de fallos: Se estandarizó la lógica para gestionar un análisis fallido de JSON por parte del evaluador. Si la salida del evaluador no es JSON válida, el sistema recurre a una calificación permisiva (grounded=True, complete=True), imitando un escenario del mundo real en el que no querrías que un parser frágil suspendiera una respuesta que por lo demás es buena. Los campos estructurados de DSPy se devuelven (sin análisis de JSON); esto se registra como una diferencia de robustez, no como una ventaja de rendimiento.
• Retorno temprano de la calculadora: Como se ve en el código, una llamada exitosa a calculator_node establece directamente final_answer y finaliza el flujo de trabajo de forma anticipada. Esta es una optimización significativa que se aplica de manera consistente, evitando que la ruta de la calculadora invoque innecesariamente los LLM de generación y evaluación.
• Alineación de DSPy. Para mantener la equidad con las líneas base sin CoT, DSPy utiliza dspy.Predict (sin CoT) para Router y AnswerGenerator. Las firmas reflejan los contratos de nodos de otros frameworks; cuando están disponibles, los recuentos de tokens usan el uso informado por el modelo; de lo contrario, se usa el fallback de tiktoken.

3. Instrumentación y métricas

El proceso de medición fue idéntico, utilizando utilidades y principios compartidos.

• Latencia: Se utilizó time.perf_counter() de alta precisión para todas las mediciones de tiempo. La sobrecarga del framework se calcula de manera consistente como Latencia total – Latencia de llamadas externas.
• Tokenización: Todos los recuentos de tokens para prompts y completions se calcularon con tiktoken, la codificación cl100k_base, lo que garantiza una única fuente de verdad para las métricas de tokens. La métrica “Tokens promedio” reportada en los resultados representa la suma acumulada de todos los tokens de entrada (prompt) y de salida (completion) de cada llamada LLM (por ejemplo, enrutador, evaluadores, generador) dentro de un único flujo de trabajo de consulta.
• Gestión del estado: Aunque la sintaxis de implementación varía (TypedDict de LangGraph, la clase de LlamaIndex, el diccionario de LangChain), la estructura del estado es funcionalmente idéntica. Cada framework pasa el mismo conjunto de claves (question, documents, web_results, etc.) entre nodos, lo que garantiza que la lógica del flujo de control opere sobre la misma información.

Al imponer estas estrictas estandarizaciones a nivel de código, este benchmark pretende ir más allá de las comparaciones superficiales y ofrecer un análisis replicable del rendimiento de los frameworks bajo una política RAG fija.

Interpretación de los resultados:

• Se puede concluir: En esta configuración específica y altamente controlada, la sobrecarga de orquestación tiende a ser menor; las diferencias están impulsadas principalmente por el recuento de tokens y las rutas de herramientas.
  • En esta configuración específica y altamente controlada, la sobrecarga del framework es insignificante.
  • Las diferencias de rendimiento estuvieron impulsadas por el recuento de tokens y las variaciones en las rutas de herramientas.
• No se puede generalizar: Los resultados son específicos de esta arquitectura, modelos, prompts, recuperador y proveedor web; cambiarlos puede alterar las clasificaciones.

Experiencia del desarrollador: una comparación cualitativa

El rendimiento no es el único factor; cómo se siente construir con un framework es igualmente importante.

• LangGraph: el grafo declarativo
  Utiliza un paradigma basado en grafos. Se definen nodos y se conectan con aristas (incluida add_conditional_edges), de modo que el flujo de control forma parte de la arquitectura. El estado se tipa mediante un TypedDict con actualizaciones de estilo reductor (Annotated[…, add]).
  • Elegir LangGraph para: flujos de trabajo complejos con múltiples ramas, reintentos y ciclos; su estructura escala en robustez y mantenibilidad a medida que los agentes crecen.
• LlamaIndex: orquestación imperativa
  Un script procedimental donde el flujo de control es if/else estándar de Python; el “grafo” vive en el código. El estado es una clase dedicada PipelineState, y el framework proporciona primitivas limpias de recuperación (VectorStoreIndex → .as_retriever(k=5)).
  • Elegir LlamaIndex para: flujos de trabajo legibles en un solo archivo donde se valora una lógica procedimental clara y una depuración sencilla.
• LangChain: imperativo con componentes declarativos
  La orquestación sigue siendo un script de Python, pero las tareas individuales son pequeñas cadenas componibles que usan el operador | (por ejemplo, prompt | llm | parser). El estado es un dict de Python flexible y sin tipado.
  • Elegir LangChain para: prototipado rápido o equipos que ya están en el ecosistema de LangChain y que prefieren componer pequeñas unidades declarativas dentro de un controlador imperativo más grande.
• Haystack: orquestación manual basada en componentes Componentes tipados y reutilizables (@component) con E/S explícita, mientras que el flujo de control sigue siendo Python estándar (if/else). Es fácil cambiar backends de LLM, recuperador o web, además de contar con instrumentación de primera clase por paso (tiempo externo frente a tiempo del framework).
  • Elegir Haystack para: pipelines listos para producción y testeables, con contratos claros y control detallado.
• DSPy: programas centrados en firmas (menos líneas de código)
  Define una tarea mediante una firma (entradas/salidas + intención) y luego la implementa con Modules que encapsulan los prompts y las llamadas LLM. Centraliza la gestión de prompts y uso y elimina el código repetitivo; cambiar los internos (por ejemplo, Predict ↔ CoT) no cambia el contrato.
  • Elegir DSPy para: mínimo boilerplate, flujos legibles en un solo archivo, desarrollo dirigido por contrato (con optimizadores opcionales).

Sacrificar el rendimiento óptimo por la comparabilidad

• LangGraph podría destacar con sus optimizaciones nativas de grafos cuando se le permite usar ejecución paralela, caché de estado y su sistema de aristas condicionales para lógica de ramificación compleja.
• DSPy podría mostrar resultados drásticamente diferentes al usar sus optimizadores de firmas (como MIPROv2) y prompting de Chain-of-Thought, lo que puede mejorar significativamente la calidad de las respuestas.
• Haystack podría aprovechar su caché listo para producción, sus funciones de procesamiento por lotes y sus optimizaciones a nivel de componentes que desactivamos por equidad.
• LlamaIndex podría beneficiarse de sus estrategias avanzadas de indexación, motores de consulta y capacidades multimodales que no se ejercitaron en este benchmark.
• LangChain podría brillar con su amplio ecosistema de herramientas y las optimizaciones de LCEL (LangChain Expression Language) cuando no está limitado a nuestro conjunto de herramientas estandarizado.

El “mejor” framework depende de si se optimiza para: velocidad de desarrollo, mantenibilidad, rendimiento o patrones arquitectónicos específicos.

No te pierdas nuestros análisis comparativos e insights basados en datos. El botón abre Google; seleccionar AIMultiple confirma que deseas ver AIMultiple con más frecuencia en los resultados de búsqueda de Google.

Añadir como fuente preferida

Lecturas adicionales

Explore otros benchmarks de RAG, como:

• Modelos de embedding: OpenAI frente a Gemini frente a Cohere
• Mejor base de datos vectorial para RAG: Qdrant frente a Weaviate frente a Pinecone
• Benchmark de RAG agéntico: enrutamiento entre múltiples bases de datos y generación de consultas

Cita este benchmark

Elige el formato que se ajuste al lugar donde vas a publicar. Pegar la versión con enlace en tu CMS conserva el enlace de retroceso.

@misc{dilmegani2026,
  author = {Dilmegani, Cem and Sarı, Ekrem},
  title  = {{RAG Frameworks: LangChain frente a LangGraph frente a LlamaIndex}},
  year   = {2026},
  month  = aug,
  howpublished    = {\url{https://aimultiple.com/rag-frameworks}},
  note   = {AIMultiple. Recuperado el 31 de Agosto de 2026}
}

Registro de cambios

7 actualizaciones

Todas7General5Metodología2

1. 202629 de Ene

   Se añadió el número de consultas y ejecuciones a la metodología de evaluación comparativa.

2. 27 de Ene

   Actualizados los resultados y la metodología del benchmark de frameworks RAG.

3. 202510 de Nov

   Añadida la definición de tokens promedio y sobrecarga del framework a los resultados del benchmark de frameworks RAG.

4. 1 de Nov

   Se reemplazaron los datos de rendimiento en la sección Hallazgos Clave.

5. 1 de Nov

   Se reemplazó la descripción de la metodología en la sección de marcos RAG.

6. 31 de Oct

   Se añadió Haystack y DSPy a la comparación de frameworks RAG.

7. 31 de Oct

   Se actualizó el número de implementaciones en la sección de metodología.

Cem Dilmegani

Analista Principal

Síguenos

Cem ha sido el analista principal en AIMultiple desde 2017.

El trabajo de Cem en AIMultiple ha sido citado por publicaciones líderes mundiales como Business Insider, Forbes, Morning Brew y Washington Post, empresas globales como Deloitte y HPE, ONG como World Economic Forum y organizaciones supranacionales como European Commission. [1], [2], [3], [4], [5]

A lo largo de su carrera, Cem trabajó como consultor tecnológico, comprador de tecnología y emprendedor tecnológico. Asesoró a empresas en sus decisiones tecnológicas en McKinsey & Company y Altman Solon durante más de una década. También publicó un informe de McKinsey sobre digitalización.

Dirigió la estrategia tecnológica y las adquisiciones de una empresa de telecomunicaciones reportando al CEO. También lideró el crecimiento comercial de la empresa de deep tech Hypatos, que alcanzó unos ingresos recurrentes anuales de 7 dígitos y una valoración de 9 dígitos desde 0 en 2 años. El trabajo de Cem en Hypatos fue cubierto por publicaciones tecnológicas líderes como TechCrunch y Business Insider.

Cem participa habitualmente en conferencias internacionales de tecnología. Se graduó en Bogazici University como ingeniero informático y tiene un MBA de Columbia Business School.

Ver perfil completo

Investigado por

Ekrem Sarı

Investigador de IA

Síguenos

Ekrem es investigador de IA y científico de datos en AIMultiple. Diseña y ejecuta benchmarks prácticos para sistemas de IA y LLM.

Ver perfil completo

Sé el primero en comentar

Tu dirección de correo electrónico no será publicada. Todos los campos son obligatorios. Los comentarios se dejan en su idioma original.

Nombre

Dirección de correo electrónico

Comentario

0/450

Publicar comentario