Elija los frameworks RAG según la carga de trabajo, no por el prestigio de LangChain

El problema en contexto

Descubrir a las 2 de la mañana que una dependencia transitiva de LangChain introdujo cambios que rompían el funcionamiento, que los valores fijados habían cambiado y que el equipo de soporte pasó una hora intentando resolver el problema para restaurar una función que, en esencia, solo recuperaba fragmentos de texto y respondía a ellos, es una forma muy dura de enfrentarse a la situación.

El problema real no era un solo corte de servicio. El equipo ya no podía explicar su propio proceso de recuperación de datos. LangChain había sido la opción predeterminada desde el inicio; todos recurrían a ella, pero las abstracciones se acumularon hasta que el sistema se volvió opaco. Los sistemas opacos fallan por la noche, y lo hacen de forma lenta, porque nadie puede identificar con precisión qué capa está dañada.

Esto no es un ataque personal. LangChain cumple su función cuando un producto realmente necesita herramientas para realizar llamadas, gestionar memoria, generar prompts y orquestar procesos en múltiples pasos. El problema surgió al utilizar un orquestador genérico para tareas que nunca fueron de tipo agente.

El principio

Elija un marco RAG según la carga de trabajo, no por tendencias del mercado. Las abstracciones aumentan la latencia, la superficie de dependencias y las dificultades para depurar. Se paga ese costo cuando el problema coincide con lo que abstrae el marco; de lo contrario, es un lastre inútil.

Un mismo producto puede ocultar dos tipos de cargas de trabajo bajo una misma marca. Ejemplo: búsqueda semántica empresarial en documentos internos y verificación rápida de documentos en PDFs subidos. Ninguno de ellos funciona como agente. Pagar el costo total de orquestación dos veces para dos tareas dedicadas es un desperdicio evidente.

Un mapa práctico de las herramientas para tareas tiene un aspecto diferente una vez que se eliminan las etiquetas de marketing. Haystack de Deepset suele ser adecuado para pipelines de recuperación de producción explicables. LlamaIndex resulta útil para pruebas rápidas de documentos privados, con un camino corto desde los archivos hasta las respuestas. Las plataformas de diálogo como Rasa son adecuadas para flujos de soporte basados en intenciones. Botpress o Dialogflow son ideales para bots de clientes de bajo código. Hugging Face Transformers sirven a equipos que necesitan control total del modelo o su ajuste fino. CrewAI, AutoGen y DSPy son adecuados para experimentos de orquestación multiagente.

Esas soluciones centradas en agentes fueron evaluadas de manera honesta y siguen siendo interesantes cuando el producto realmente requiere la colaboración de agentes. Sin embargo, debido a dos tipos de cargas de trabajo de recuperación, Haystack y LlamaIndex salieron ganadores en el único criterio relevante para esta migración.

Compromisos

Búsqueda semántica empresarial — requiere soluciones explicables, verificables, escalables y autohospedables → Haystack (más componentes; se ejecuta una base de datos vectorial).

Verificación de calidad de documentos PDF subidos — necesita una configuración rápida, baja latencia y bajo consumo de recursos → LlamaIndex (diseñado intencionalmente para tareas específicas; no es un orquestador).

Agente multiherramienta real — requiere herramientas, memoria y plantillas → LangChain / CrewAI (latencia y dependencias que afectan al flujo principal).

Haystack está orientado a pipelines modulares con recuperación, enrutamiento y generación explícitos, funciona con backends reales (Elasticsearch, OpenSearch, Weaviate) y puede ser autohospedado para garantizar privacidad. Las etapas del pipeline permanecen claras:

from haystack.document_stores import InMemoryDocumentStore
from haystack.nodes import DensePassageRetriever, FARMReader
from haystack.pipelines import ExtractiveQAPipeline

document_store = InMemoryDocumentStore()
retriever = DensePassageRetriever(document_store=document_store)
reader = FARMReader(model_name_or_path="deepset/roberta-base-squad2")pipeline = ExtractiveQAPipeline(reader=reader, retriever=retriever)
response = pipeline.run(query="What is Haystack used for?")

El Retriever obtiene los documentos; el lector selecciona a los candidatos más adecuados. Cuando algo es lento o incorrecto, se debe inspeccionar un nodo. Cambie InMemoryDocumentStore por OpenSearch sin tener que reescribir el resto del código.

LlamaIndex conecta los LLM con datos locales —procesamiento, indexación, consultas— y, por diseño, es más sencillo que LangChain:

from llama_index import SimpleDirectoryReader, GPTTreeIndex

documents = SimpleDirectoryReader("<directory_path>").load_data()
index = GPTTreeIndex(documents)
response = index.query("What is the purpose of this document?")

Tres pasos desde una carpeta de PDF hasta un índice consultable. Para funcionalidades que deben responder en pocos segundos, eliminar la sobrecarga de orquestación reduce directamente la latencia.

En comparación con un sistema monolítico de LangChain, la arquitectura basada en Haystack + LlamaIndex ofrece una latencia p95 menor, aproximadamente la mitad de dependencias en el camino RAG, mayor claridad ante fallos a nivel de nodo, menos incidentes relacionados con cambios en el framework, una mejor adaptación para implementaciones propias, y un tiempo de integración de horas en lugar de días.

Cómo adoptarlo

Evite una reescritura total. Proceda por fases y haga mediciones:

1. Modo sombra — las mismas consultas a rutas antiguas y nuevas; diferencias en respuestas y latencia sin impacto en el usuario.
2. Cambio gradual mediante banderas de funcionalidad — redirigir el tráfico en porcentajes una vez que la calidad evaluada sea igual o superior a la del sistema actual.
3. Separar cargas de trabajo independientes — migrar la verificación de PDF por separado si no comparte estado con la búsqueda.
4. Eliminar lo último — quitar la dependencia antigua solo después de que ambas rutas sigan funcionando correctamente en una versión lanzada.

conjunto de pruebas (preguntas fijas con respuestas conocidas y correctas) convierte la pregunta “¿es buena la nueva ruta?” en un número. El modo sombra a menudo muestra resultados mixtos: mejores resultados en algunas consultas y respuestas demasiado cortas en otras; por eso se debe dirigir el contenido extenso a un lector generativo y mantener el enfoque extractivo para búsquedas precisas. Un cambio de framework sin mediciones es una apuesta al azar.

Principio rector: no exagere con esta división estricta (los bots de soporte pueden preferir Rasa; el trabajo con modelos en bruto puede requerir Transformers). No prohíba permanentemente LangChain: guárdelo para el día en que aparezca un agente verdaderamente multiusos.

Hacia dónde vamos a partir de ahora

El trabajo a corto plazo seguirá siendo medido: reclasificación en Haystack, lectores generativos para respuestas largas, quizás un experimento con intenciones de Rasa; siempre se elegirá la herramienta adecuada según la carga de trabajo. La moda en los frameworks volverá a cambiar (CrewAI, AutoGen, DSPy, RAGFlow, Flowise, …). Los equipos que toman decisiones basadas en el revuelo tecnológico tienen que reconsiderar todo el conjunto de herramientas cada temporada. Los equipos que nombran las tareas y eligen las herramientas según ellas solo revisan la parte que ha cambiado. Si LangChain parece obstaculizar el trabajo en producción, la solución suele ser elegir el framework adecuado para la tarea concreta, no más LangChain.

Qué cambios trae el enfoque “primero la carga de trabajo” en los procesos organizacionales

La revisión de arquitectura deja de preguntar “¿estamos estandarizados en LangChain?” y comienza a preguntar “¿qué cargas de trabajo existen y qué herramienta se ajusta a cada una?”. Eso suena burocrático; así es como los equipos evitan otro monolito opaco. Anoten las cargas de trabajo: busquen en la wiki corporativa, realicen pruebas con PDF para los archivos subidos, piensen en un agente multiherramienta futuro y quizás en un bot para intenciones de soporte. Asignen responsables y objetivos de rendimiento por cada carga de trabajo. La elección del framework se convierte en un detalle de implementación bajo cada fila.

También resultan más sencillas las revisiones de adquisiciones y seguridad. Haystack autohospedado junto con OpenSearch implica un tipo de conversación distinto relacionada con los límites de datos, a diferencia de un creador de bots SaaS. LlamaIndex en almacenamiento temporal para subidas también es diferente. Agrupar los tres bajo un único ticket de “plataforma de IA” oculta esas diferencias.

Los manuales de operaciones de emergencia deben mencionar los nodos, no los frameworks. “La latencia del Retriever es alta” es algo accionable. “LangChain es lento” no lo es. Después de la división, las páginas ahora indican el tiempo de consulta en OpenSearch o la saturación de la GPU del lector, en lugar de tratar de resolver misterios relacionados con las dependencias.

También cambia la forma de capacitar a los nuevos ingenieros. En lugar de una semana dedicada a conocer todo sobre LangChain, la inducción al trabajo puede consistir en: aquí está el diagrama del pipeline de Haystack; aquí está el script de tres pasos de LlamaIndex; aquí está el conjunto de evaluación; aquí está cómo ejecutar el modo sombra. El tiempo necesario para generar la primera propuesta útil disminuye porque el camino más utilizado es más corto.

Nada de esto prohíbe el uso de LangChain. Lo que se prohíbe es fingir que un único orchestrador es la única opción viable cuando la mitad del producto no está basado en agentes. Cuando finalmente aparezca en el roadmap un asistente multiherramienta real, LangChain o CrewAI podrán presentarse con una descripción clara del trabajo a realizar, además de un conjunto de evaluación listo para usar.

Siga midiendo. Siga nombrando las cargas de trabajo. Mantenga la ruta crítica lo suficientemente corta como para que un ingeniero de soporte cansado aún pueda explicarla a las 2 a.m.