{"id":505,"date":"2026-03-09T18:22:35","date_gmt":"2026-03-09T18:22:35","guid":{"rendered":"https:\/\/blog.rebalai.com\/es\/2026\/03\/09\/langchain-vs-llamaindex-vs-haystack-building-produ\/"},"modified":"2026-03-18T22:31:14","modified_gmt":"2026-03-18T22:31:14","slug":"langchain-vs-llamaindex-vs-haystack-building-produ","status":"publish","type":"post","link":"https:\/\/blog.rebalai.com\/es\/2026\/03\/09\/langchain-vs-llamaindex-vs-haystack-building-produ\/","title":{"rendered":"LangChain vs LlamaIndex vs Haystack: Lo que aprend\u00ed construyendo RAG en producci\u00f3n"},"content":{"rendered":"

Pas\u00e9 las \u00faltimas dos semanas<\/a> migrando un sistema RAG entre tres frameworks \u2014 y no fue una decisi\u00f3n voluntaria. Empezamos con LangChain, las abstracciones se volvieron dif\u00edciles de mantener, alguien del equipo sugiri\u00f3 LlamaIndex, probamos eso, y al final termin\u00e9 revisando Haystack casi de casualidad mientras buscaba una soluci\u00f3n a otro problema. As\u00ed que lo hice bien: mont\u00e9 un benchmark real con nuestros datos reales y med\u00ed lo que<\/a> importa.<\/p>\n

Trabajo en un equipo de seis personas, construimos un sistema RAG para un cliente fintech. El corpus tiene alrededor de 480k documentos \u2014 PDFs escaneados (los peores, siempre), HTML de sus portales internos, y algo de Markdown de sus wikis. Presupuesto m\u00e1ximo de inferencia: $800\/mes. Eso descart\u00f3 varias opciones antes de llegar siquiera a cuestiones de arquitectura.<\/p>\n

Las versiones que prob\u00e9: LangChain 0.3.15, LlamaIndex 0.12.3, Haystack 2.7.1.<\/p>\n

LangChain 0.3.15 \u2014 El ecosistema que a veces juega en tu contra<\/h2>\n

LangChain fue mi punto de partida porque ya lo conoc\u00eda. Y ese mismo conocimiento fue parte del problema \u2014 ten\u00edamos c\u00f3digo de un proyecto de hace ocho meses que hubo que reescribir parcialmente porque las interfaces hab\u00edan cambiado. Otra vez.<\/p>\n

La API ha mejorado, ser\u00e9 honesto. LCEL (LangChain Expression Language) funciona bien cuando lo entiendes de verdad<\/a>. La composici\u00f3n de cadenas con el operador |<\/code> queda limpia, y el tracing con LangSmith nos ahorr\u00f3 horas de debugging en staging.<\/p>\n

from langchain_core.runnables import RunnablePassthrough\nfrom langchain_core.output_parsers import StrOutputParser\nfrom langchain_anthropic import ChatAnthropic\n\n# El retriever con score_threshold fue la parte que m\u00e1s tardamos en afinar.\n# 0.72 fue nuestro n\u00famero despu\u00e9s de<\/a> ~200 consultas de evaluaci\u00f3n manual.\nretriever = vectorstore.as_retriever(\n    search_type="similarity_score_threshold",\n    search_kwargs={"k": 5, "score_threshold": 0.72}\n)\n\n# LCEL en acci\u00f3n \u2014 se lee bien y en general funciona bien\nchain = (\n    {"context": retriever | format_docs, "question": RunnablePassthrough()}\n    | prompt\n    | ChatAnthropic(model="claude-opus-4-6", temperature=0)\n    | StrOutputParser()\n)\n<\/code><\/pre>\n
El problema no es la calidad t\u00e9cnica del framework. LangChain intenta cubrir todo \u2014 agentes, memoria, herramientas, cadenas, RAG \u2014 y el precio de esa amplitud es que la profundidad en retrieval espec\u00edficamente no est\u00e1 a la altura de la competencia. Cuando quise implementar sentence window retrieval o hierarchical node parsing, tuve que construirlo yo mismo o buscar en la comunidad. Hay soluciones, s\u00ed, pero en cinco versiones distintas de la librer\u00eda, no siempre queda claro cu\u00e1l aplica a la tuya.<\/p>\n
Un momento concreto que me sac\u00f3 de quicio: en diciembre intent\u00e9 usar MultiVectorRetriever<\/code> con documentos largos y me top\u00e9 con un bug reportado en el<\/a> GitHub de LangChain (issue #12847) donde los document IDs se sobreescrib\u00edan silenciosamente. Funcionaba en local pero no en producci\u00f3n<\/a> \u2014 diferencia en la versi\u00f3n de Chroma, result\u00f3 ser. Dos d\u00edas perdidos en eso.<\/p>\n
Para proyectos donde necesitas m\u00e1xima flexibilidad y tienes equipo dispuesto a mantener c\u00f3digo propio, LangChain tiene sentido<\/a>. Para RAG puro, hay mejores opciones.<\/p>\n
LlamaIndex 0.12.3 \u2014 Cuando la calidad del retrieval realmente importa<\/h2>\n
Cambi\u00e9 a LlamaIndex con escepticismo. Me sorprendi\u00f3.<\/p>\n
Est\u00e1 mucho m\u00e1s enfocado en el<\/a> problema de indexing y retrieval, y eso se nota en los detalles de implementaci\u00f3n. La combinaci\u00f3n que m\u00e1s movi\u00f3 nuestros n\u00fameros fue SentenceWindowNodeParser<\/code> con MetadataReplacementPostProcessor<\/code>. La idea: indexas oraciones individuales para tener precisi\u00f3n en el<\/a> retrieval, pero al momento de generar la respuesta reemplazas ese fragmento con una ventana de contexto mayor. Bajamos el hallucination rate de ~12% a aproximadamente 4% con este cambio solo. Eso es lo que<\/a> quiero decir con “profundidad en retrieval” \u2014 no una feature de marketing, sino herramientas concretas para un problema concreto.<\/p>\n
from llama_index.core import VectorStoreIndex, Settings\nfrom llama_index.core.node_parser import SentenceWindowNodeParser\nfrom llama_index.core.postprocessor import MetadataReplacementPostProcessor\n\n# Esta combinaci\u00f3n fue la que realmente<\/a> cambi\u00f3 nuestras m\u00e9tricas de evaluaci\u00f3n\nnode_parser = SentenceWindowNodeParser.from_defaults(\n    window_size=3,                           # 3 oraciones de contexto por lado\n    window_metadata_key="window",\n    original_text_metadata_key="original_text",\n)\n\nSettings.node_parser = node_parser\nSettings.chunk_size = 512  # m\u00e1s peque\u00f1o de lo que<\/a> us\u00e1bamos antes con LangChain\n\nindex = VectorStoreIndex.from_documents(\n    documents,\n    show_progress=True,\n)\n\n# El postprocessor reemplaza el nodo recuperado con su ventana de contexto\n# justo antes de armar el prompt \u2014 la magia est\u00e1 aqu\u00ed\nquery_engine = index.as_query_engine(\n    similarity_top_k=6,\n    node_postprocessors=[\n        MetadataReplacementPostProcessor(target_metadata_key="window")\n    ],\n)\n<\/code><\/pre>\n
Lo que no me convenci\u00f3: el sistema de configuraci\u00f3n global con Settings<\/code> se siente torpe cuando tienes m\u00faltiples pipelines en el<\/a> mismo proceso. Cada vez que necesit\u00e1bamos cambiar algo para un sub\u00edndice espec\u00edfico, sobreescrib\u00edamos configuraciones globales y rez\u00e1bamos para que los tests de integraci\u00f3n no se pisaran entre s\u00ed. El ServiceContext<\/code> directo era una opci\u00f3n pero est\u00e1 deprecado en 0.12.x, y la historia de migraci\u00f3n no es del todo limpia.<\/p>\n
Tambi\u00e9n: la documentaci\u00f3n asume que usas sus abstracciones de punta a punta. Cuando quisimos integrar LlamaIndex solo para el retrieval y usar nuestro propio sistema de generaci\u00f3n, hubo m\u00e1s fricci\u00f3n de lo esperado. No imposible, pero tampoco el camino documentado.<\/p>\n
Igual, si el retrieval de calidad es tu prioridad principal, LlamaIndex tiene la mejor caja de herramientas de los tres. Por bastante margen.<\/p>\n
Haystack 2.7.1 \u2014 El que nadie<\/a> menciona en los tutoriales<\/h2>\n
Ser\u00e9 directo: no esperaba que Haystack me sorprendiera tanto.<\/p>\n
Tiene una fracci\u00f3n del mindshare de los otros dos, y eso es una l\u00e1stima porque para ambientes de producci\u00f3n tiene ventajas reales. El modelo mental es distinto al de LangChain y LlamaIndex: todo es un pipeline de componentes conectados, y ese pipeline es un ciudadano de primera clase \u2014 lo puedes serializar a YAML, versionarlo, desplegarlo con configuraci\u00f3n externa.<\/p>\n
# pipeline.yaml \u2014 esto es<\/a> real, no pseudoc\u00f3digo de blog\ncomponents:\n  retriever:\n    type: haystack.components.retrievers.InMemoryEmbeddingRetriever\n    init_parameters:\n      document_store: !component document_store\n      top_k: 5\n  prompt_builder:\n    type: haystack.components.builders.PromptBuilder\n    init_parameters:\n      template: |\n        Contexto: {% for doc in documents %}{{ doc.content }}{% endfor %}\n        Pregunta: {{ question }}\n        Respuesta:\nconnections:\n  - sender: retriever.documents\n    receiver: prompt_builder.documents\n<\/code><\/pre>\n
Eso suena aburrido hasta que<\/a> est\u00e1s en tu tercer deployment del d\u00eda y alguien de QA quiere correr la versi\u00f3n exacta del pipeline que fall\u00f3 en staging. Ser capaz de versionar el pipeline como un artefacto separado del c\u00f3digo de aplicaci\u00f3n es algo que los otros dos no tienen de serie.<\/p>\n
Donde me cost\u00f3 caro: la comunidad es significativamente m\u00e1s peque\u00f1a. Pas\u00e9 cuatro horas un martes intentando entender por qu\u00e9<\/a> mi DocumentSplitter<\/code> ignoraba los saltos de p\u00e1gina en PDFs. Nada en Stack Overflow. El Discord de Haystack ten\u00eda una pregunta similar sin respuesta de hace tres meses. Al final le\u00ed el c\u00f3digo fuente \u2014 hay un par\u00e1metro split_by=\"page\"<\/code> que no est\u00e1 en la gu\u00eda de inicio r\u00e1pido pero s\u00ed en el API reference si sabes d\u00f3nde buscar. Ese tipo de fricci\u00f3n se acumula cuando hay plazos encima.<\/p>\n
La observabilidad est\u00e1 mejor pensada, especialmente si ya usas OpenTelemetry. El tracing sale de caja con detalle sobre qu\u00e9 componente tom\u00f3 cu\u00e1nto tiempo, sin pagar por herramientas externas.<\/p>\n
No s\u00e9 si Haystack escala m\u00e1s all\u00e1 de lo que<\/a> nosotros probamos \u2014 alrededor de 2,000 queries diarios en producci\u00f3n<\/a>. Mi intuici\u00f3n dice que s\u00ed, pero no tengo datos propios para afirmarlo.<\/p>\n
El Viernes que Casi Me Hace Cambiar de Opini\u00f3n<\/h2>\n
Estaba casi decidido por LlamaIndex cuando pas\u00f3 algo que me hizo repensar el criterio de evaluaci\u00f3n completo.<\/p>\n
Un viernes por la tarde \u2014 cl\u00e1sico \u2014 empuj\u00e9 una actualizaci\u00f3n al servicio de indexaci\u00f3n. El proceso de background para indexar documentos nuevos empez\u00f3 a consumir memoria de forma inconsistente. No todos los runs, tal vez uno de cada cuatro. El problema: en LlamaIndex 0.12.x, hay edge cases en el manejo de memoria al indexar documentos con embeddings de p\u00e1ginas muy largas \u2014 PDFs de m\u00e1s de 200 p\u00e1ginas en nuestro caso. Encontr\u00e9 la issue en GitHub pero no hab\u00eda fix todav\u00eda.<\/p>\n
La soluci\u00f3n que termin\u00e9 usando fue procesar esos documentos en batches m\u00e1s peque\u00f1os con un wrapper propio. Funcion\u00f3, pero me dej\u00f3 pensando: \u00bfcu\u00e1nto tiempo deber\u00eda gastar parchando comportamiento de framework versus construyendo producto?<\/p>\n
Pensaba que la calidad del retrieval era el criterio m\u00e1s importante, pero en producci\u00f3n<\/a> la operabilidad importa tanto o m\u00e1s. La pregunta que no me hab\u00eda hecho al inicio del benchmark.<\/p>\n
Con Haystack, el mismo escenario hubiera sido m\u00e1s predecible \u2014 el pipeline expl\u00edcito hace m\u00e1s obvio d\u00f3nde puede fallar y d\u00f3nde intervenir. Con LangChain hubiera tenido m\u00e1s opciones de configuraci\u00f3n pero tambi\u00e9n m\u00e1s superficie de error. No hay respuesta perfecta. Solo hay tradeoffs que vale la pena<\/a> conocer antes de comprometer el stack de un cliente.<\/p>\n
Mi Recomendaci\u00f3n (sin el “depende de tu caso de uso”)<\/h2>\n
Voy directo: si en 2026<\/a> est\u00e1s arrancando un nuevo proyecto RAG de cero con un corpus de escala media o grande, te recomiendo LlamaIndex para la capa de indexaci\u00f3n y retrieval. La toolbox de retrieval avanzado no tiene competencia real en los otros dos frameworks, y esa diferencia se traduce en m\u00e9tricas concretas.<\/p>\n
Si tu equipo valora la operabilidad y la reproducibilidad de pipelines sobre la velocidad de prototipado inicial \u2014 y especialmente si ya tienen cultura de infraestructura-como-c\u00f3digo \u2014 considera Haystack. La curva de adopci\u00f3n es m\u00e1s alta, pero lo que<\/a> ganas en predictibilidad en producci\u00f3n<\/a> compensa.<\/p>\n
LangChain tiene sentido<\/a> en un escenario espec\u00edfico: si necesitas construir agentes con herramientas complejas, o si tu equipo ya lo conoce bien y el costo de migraci\u00f3n supera el beneficio. El ecosistema de integraciones es el m\u00e1s amplio de los tres. Pero para RAG puro, es la opci\u00f3n con m\u00e1s overhead de mantenimiento.<\/p>\n
Aqu\u00ed lo que<\/a> no esperaba aprender: el framework que eliges afecta c\u00f3mo piensas el problema, no solo c\u00f3mo lo implementas. LangChain te hace pensar en cadenas. LlamaIndex te hace pensar en nodos y retrieval. Haystack te hace pensar en pipelines y componentes. Si tu modelo mental ya encaja con uno de esos paradigmas, eso es informaci\u00f3n v\u00e1lida para la decisi\u00f3n \u2014 m\u00e1s v\u00e1lida que cualquier benchmark sint\u00e9tico.<\/p>\n
Mi setup actual: LlamaIndex para indexaci\u00f3n y retrieval, FastAPI por encima, m\u00e9tricas propias con Prometheus. Ninguno de los tres me convenci\u00f3 con su historia de observabilidad nativa, as\u00ed que ah\u00ed constru\u00ed algo propio. En los pr\u00f3ximos meses voy a mirar si la integraci\u00f3n OpenTelemetry de Haystack madura lo suficiente para reemplazar eso \u2014 pero por ahora, lo que tenemos funciona.<\/p>\n
<\/p>\n","protected":false},"excerpt":{"rendered":"
Pas\u00e9 las \u00faltimas dos semanas migrando un sistema RAG entre tres frameworks \u2014 y no fue una decisi\u00f3n voluntaria.<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"site-sidebar-layout":"default","site-content-layout":"","ast-site-content-layout":"default","site-content-style":"default","site-sidebar-style":"default","ast-global-header-display":"","ast-banner-title-visibility":"","ast-main-header-display":"","ast-hfb-above-header-display":"","ast-hfb-below-header-display":"","ast-hfb-mobile-header-display":"","site-post-title":"","ast-breadcrumbs-content":"","ast-featured-img":"","footer-sml-layout":"","ast-disable-related-posts":"","theme-transparent-header-meta":"","adv-header-id-meta":"","stick-header-meta":"","header-above-stick-meta":"","header-main-stick-meta":"","header-below-stick-meta":"","astra-migrate-meta-layouts":"default","ast-page-background-enabled":"default","ast-page-background-meta":{"desktop":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"ast-content-background-meta":{"desktop":{"background-color":"var(--ast-global-color-4)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"var(--ast-global-color-4)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"var(--ast-global-color-4)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"footnotes":""},"categories":[1],"tags":[],"class_list":["post-505","post","type-post","status-publish","format-standard","hentry","category-general"],"_links":{"self":[{"href":"https:\/\/blog.rebalai.com\/es\/wp-json\/wp\/v2\/posts\/505","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blog.rebalai.com\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.rebalai.com\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.rebalai.com\/es\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.rebalai.com\/es\/wp-json\/wp\/v2\/comments?post=505"}],"version-history":[{"count":11,"href":"https:\/\/blog.rebalai.com\/es\/wp-json\/wp\/v2\/posts\/505\/revisions"}],"predecessor-version":[{"id":764,"href":"https:\/\/blog.rebalai.com\/es\/wp-json\/wp\/v2\/posts\/505\/revisions\/764"}],"wp:attachment":[{"href":"https:\/\/blog.rebalai.com\/es\/wp-json\/wp\/v2\/media?parent=505"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.rebalai.com\/es\/wp-json\/wp\/v2\/categories?post=505"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.rebalai.com\/es\/wp-json\/wp\/v2\/tags?post=505"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}