RAG Frameworks: LangChain vs LangGraph vs LlamaIndex

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

Resultados de la evaluación de frameworks de RAG

La evaluación consistió en 100 consultas, ejecutando cada framework el conjunto completo 100 veces para obtener promedios estables.

• Tokens promedio: Tokens totales consumidos en todas las llamadas al LLM (enrutador, calificador de documentos, calificador de respuestas y generador), incluye tanto prompts (con contexto recuperado) como finalizaciones. Menos = menor costo 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 el LLM API y las llamadas a herramientas. Menos = framework más ligero.

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

Hallazgos Clave

1. Nos enfocamos en controlar lo controlable: 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 de enrutador (heurístico + modelo), retorno temprano de calculadora, límite compartido de tokens de contexto, rúbrica de calificació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 de la lógica de orquestación. Estas diferencias son reales, pero no la fuente principal de las brechas de latencia >1 s; la mayor parte del tiempo se gasta en I/O con modelos/herramientas externas.
3. El rendimiento sigue a los tokens (bajo estas restricciones): DSPy muestra la menor sobrecarga de framework (~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 para Haystack (~1.57k), luego LlamaIndex (~1.60k); DSPy y LangGraph están ~2.03k, y LangChain ~2.40k.
4. La ruta de enrutamiento/herramienta importa: Ligeros cambios en el enrutamiento inicial (recuperador vs. web vs. calculadora) y el comportamiento de respaldo afectan tanto los tokens como el tiempo, incluso cuando los prompts y presupuestos están alineados.

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

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

• Serialización de prompt y mensaje: Cada framework envuelve el mismo contenido lógico con un formato ligeramente diferente antes de enviarlo al LLM, creando diferencias de tokens pequeñas pero consistentes.
• Ensamblaje de contexto: El orden preciso y la inclusión de metadatos dentro del contexto concatenado pueden diferir ligeramente por framework, afectando el conteo final de tokens.
• Desempates de enrutamiento: En casos límite, diferencias sutiles en cómo un framework analiza la salida JSON del enrutador pueden llevar a una elección inicial de herramienta diferente.

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

La arquitectura de RAG agéntico 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 BGE-small normalizados.
• Calificar Documentos: Un juez LLM evalúa la relevancia del documento. Si es irrelevante, activa un respaldo de búsqueda web.
• Generar Respuesta: Usa un LLM con temperatura=0.0 y un límite compartido de tokens de contexto para generar un borrador de respuesta.
• Calificar 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. Los resultados de la calculadora, sin embargo, se devuelven directamente, omitiendo los pasos de generación y calificación.

Ejemplos de Flujo de Trabajo

Escenario A — Acierto directo de la base de datos:

Escenario B — Evento reciente activa herramienta web:

Escenario C — La calculadora proporciona un retorno temprano:

Escenario D — BD vectorial insuficiente, recurre a búsqueda web:

Metodología de frameworks de RAG

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

1. Componentes principales y configuración

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

• LLMs:
  • Modelo: Todos los nodos (enrutador, generador, calificador) usaron el modelo openai/gpt-4.1-mini a través de la API de OpenRouter.
  • Determinismo: la temperatura se estableció en 0.0 para todas las llamadas al LLM para asegurar la máxima consistencia en enrutamiento, generación y calificación.
  • Límites de tokens: Se aplicaron límites estrictos de max_tokens: 256 para el enrutador y calificadores, y 512 para el generador. Esto previene diferencias de latencia causadas por un framework generando respuestas excesivamente largas.
• Modelo de embedding y recuperación:
  • Modelo: Todos los frameworks usaron 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 DSPy normalizado.)
  • Recuperación: Se consultó el almacén vectorial Qdrant para k=5 (5 documentos principales) en todas las implementaciones.
• Herramientas:
  • Búsqueda web: La evaluación se restringió a solo Tavily (max_results=3).
  • Calculadora: Las cinco implementaciones usaron la librería sympy para el análisis y evaluación de expresiones matemáticas, asegurando capacidades idénticas.

2. Flujo de control y política de RAG

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

• 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 ruta heurística basada en regex verifica primero patrones obvios de calculadora o búsqueda web (p. ej., símbolos matemáticos, años como “2024”).
  2. Un nodo enrutador LLM toma luego su propia decisión.
  3. La decisión final prioriza la heurística para calculadoras, difiriendo en caso contrario a la elección del LLM.
• Presupuesto de contexto: Esta es una de las estandarizaciones más críticas. Antes de llamar al nodo generar_respuesta, todo el contexto de documentos recuperados y resultados de búsqueda web se concatenan y luego se truncan a un límite compartido de 2000 tokens usando una utilidad común truncate_to_token_budget. Esto asegura que el LLM generador en cada framework reciba una entrada del mismo tamaño exacto, evitando que algún framework sea favorecido o perjudicado por la verbosidad de su contexto recuperado.
• Política de calificación de respuestas:
  • Rúbrica indulgente: El nodo calificar_respuesta usa un prompt indulgente idéntico en todos los frameworks, instruyendo al juez LLM para aceptar respuestas semánticamente similares y razonablemente completas.
  • Manejo de fallos: La lógica para manejar un análisis JSON fallido del calificador se estandarizó. Si la salida del calificador no es JSON válido, el sistema por defecto asigna una calificación permisiva (fundamentado=True, completo=True), imitando un escenario del mundo real donde no se querría que un analizador frágil rechace una respuesta por lo demás buena. Los campos estructurados de DSPy retornan (sin análisis JSON), esto se registra como una diferencia de robustez, no una ventaja de rendimiento.
• Retorno temprano de calculadora: Como se ve en el código, una llamada exitosa al nodo calculadora establece directamente la respuesta_final y termina el flujo de trabajo temprano. Esta es una optimización significativa que se aplica consistentemente, evitando que la ruta de la calculadora invoque innecesariamente los LLMs de generar y calificar_respuesta.
• Alineación DSPy. Para mantener la equidad con las líneas base sin CoT, DSPy usa dspy.Predict (sin CoT) para Enrutador y GeneradorRespuesta. Las firmas reflejan los contratos de nodo de otros frameworks; cuando están disponibles, los conteos de tokens usan el uso reportado por el modelo, en caso contrario, respaldo tiktoken.

3. Instrumentación y métricas

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

• Latencia: Se usó time.perf_counter() de alta precisión para todas las mediciones de tiempo. La Sobrecarga del Framework se calcula consistentemente como Latencia Total – Latencia de Llamadas Externas.
• Tokenización: Todos los conteos de tokens para prompts y finalizaciones se calcularon usando tiktoken, la codificación cl100k_base, asegurando una única fuente de verdad para las métricas de tokens. La métrica “Tokens Promedio” reportada en los resultados representa la suma acumulativa de todos los tokens de entrada (prompt) y salida (finalización) para cada llamada al LLM (p. ej., enrutador, calificadores, generador) dentro de un único flujo de trabajo de consulta.
• Gestión de estado: Aunque la sintaxis de implementación varía (TypedDict de LangGraph, clase de LlamaIndex, diccionario de LangChain), la estructura del estado es funcionalmente idéntica. Cada framework pasa el mismo conjunto de claves (pregunta, documentos, resultados_web, etc.) entre nodos, asegurando que la lógica del flujo de control opere sobre la misma información.

Al imponer estas estrictas estandarizaciones a nivel de código, esta evaluación busca ir más allá de las comparaciones superficiales y ofrecer un análisis replicable del rendimiento del framework bajo una política de RAG fija.

Interpretando 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 son impulsadas principalmente por los conteos 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 fueron impulsadas por el conteo de tokens y las variaciones en la ruta de herramientas.
• No se puede generalizar: Los resultados son específicos de esta arquitectura, modelos, prompts, recuperador y proveedor web; cambiar estos puede alterar las clasificaciones.

Experiencia de desarrollo: 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
  Usa un paradigma de grafo primero. Defines nodos y los conectas con aristas (incluyendo add_conditional_edges), por lo que el flujo de control es parte de la arquitectura. El estado se tipa mediante un TypedDict con actualizaciones estilo reductor (Annotated[…, add]).
  • Elige 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 procedural donde el flujo de control es Python estándar if/else; el “grafo” vive en tu código. El estado es una clase dedicada PipelineState, y el framework proporciona primitivas de recuperación limpias (VectorStoreIndex → .as_retriever(k=5)).
  • Elige LlamaIndex para: flujos de trabajo legibles en un solo archivo donde valoras una lógica procedural clara y depuración fácil.
• LangChain: Imperativo con componentes declarativos
  La orquestación sigue siendo un script Python, pero las tareas individuales son cadenas pequeñas y componibles usando el operador | (p. ej., prompt | llm | parser). El estado es un dict Python flexible y sin tipado.
  • Elige LangChain para: Prototipado rápido o equipos ya en el ecosistema LangChain que prefieren componer pequeñas unidades declarativas dentro de un controlador imperativo más grande.
• Haystack: Basado en componentes, orquestación manual Componentes tipados y reutilizables (@component) con I/O explícita, mientras el flujo de control permanece en Python plano (if/else). Fácil de intercambiar backends de LLM/recuperador/web, además de instrumentación por paso de primera clase (tiempo externo vs. framework).
  • Elige Haystack para: pipelines listos para producción, testeables, con contratos claros y control detallado.
• DSPy: Programas de firma primero (menos líneas de código)
  Define una tarea mediante una firma (entradas/salidas + intención), luego la implementa con Módulos que encapsulan el prompting y las llamadas al LLM. Centraliza el manejo de prompts/uso y elimina código repetitivo; intercambiar internos (p. ej., Predict ↔ CoT) no cambia el contrato.
  • Elige DSPy para: mínimo boilerplate, flujos legibles en un solo archivo, desarrollo basado en contratos (con optimizadores opcionales).

Intercambiando rendimiento óptimo por comparabilidad

• LangGraph podría sobresalir con sus optimizaciones de grafo nativas 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 dramáticamente diferentes al usar sus optimizadores de firma (como MIPROv2) y prompting de Cadena de Pensamiento, lo que puede mejorar significativamente la calidad de las respuestas.
• Haystack podría aprovechar su caché listo para producción, características de procesamiento por lotes y optimizaciones a nivel de componente 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 esta evaluación.
• LangChain podría brillar con su extenso ecosistema de herramientas y optimizaciones de LCEL (LangChain Expression Language) cuando no está restringido a nuestro conjunto de herramientas estandarizado.

El “mejor” framework depende de si optimizas 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

Lectura adicional

Explora otras evaluaciones de RAG, como:

• Modelos de Embedding: OpenAI vs Gemini vs Cohere
• Mejor Base de Datos Vectorial para RAG: Qdrant vs Weaviate vs Pinecone
• Evaluación de RAG agéntico: enrutamiento multi-base de datos y generación de consultas
• RAG Híbrido: Mejorando la Precisión de RAG

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 vs LangGraph vs LlamaIndex}},
  year   = {2026},
  month  = aug,
  howpublished    = {\url{https://aimultiple.com/rag-frameworks}},
  note   = {AIMultiple. Recuperado el 4 de Agosto de 2026}
}

Cem Dilmegani

Analista Principal

Síguenos

Cem ha sido el analista principal en AIMultiple desde 2017. AIMultiple informa a cientos de miles de empresas (según similarWeb), incluido el 60% de Fortune 500 cada mes.

El trabajo de Cem ha sido citado por publicaciones globales líderes como Business Insider, Forbes, Washington Post, firmas globales como Deloitte, HPE y ONG como el Foro Económico Mundial y organizaciones supranacionales como la Comisión Europea.

A lo largo de su carrera, Cem se ha desempeñado 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.

Lideró la estrategia tecnológica y las adquisiciones de una empresa de telecomunicaciones reportando directamente al CEO. También lideró el crecimiento comercial de la empresa de tecnología profunda Hypatos, que alcanzó 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 habla regularmente en conferencias internacionales de tecnología. Se graduó de la Universidad de Bogazici 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 analista 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