RAG Sin LangChain: Construyendo Pipelines de Recuperación para Producción Sin un Framework de Python

LangChain se ha convertido en la recomendación predeterminada cada vez que alguien pregunta "cómo construyo RAG" en Reddit, Stack Overflow o cualquier Discord de IA. Y con razón: logró que la gente pasara de cero a un prototipo funcional más rápido que cualquier otra cosa en 2023-2024. Podías conectar una base de datos vectorial, un modelo de embeddings y un endpoint de chat completion en cincuenta líneas de Python.

Pero un número creciente de equipos de producción lo están eliminando silenciosamente. No porque LangChain sea malo — genuinamente ayudó a impulsar el ecosistema RAG. Lo están eliminando porque las cosas que hacen que LangChain sea excelente para prototipos se convierten en responsabilidades a escala de producción.

Si estás evaluando cómo construir un pipeline RAG sin LangChain, o preguntándote si deberías migrar, este es el análisis honesto: qué está realmente mal, cuáles son las alternativas y cuándo LangChain sigue siendo la elección correcta.

El Impuesto de la Abstracción

Todo framework impone un coste. Obtienes conveniencia a cambio de control. Esa compensación vale la pena cuando las abstracciones son estables, están bien documentadas y se corresponden claramente con tu modelo mental del sistema subyacente.

Las abstracciones de LangChain han tenido dificultades en los tres aspectos en entornos de producción.

Rotación de versiones. La superficie de API de LangChain ha cambiado agresivamente entre versiones. Los equipos que construyeron contra langchain==0.0.x encontraron su código roto por 0.1.x, y luego otra vez por la división langchain-core / langchain-community. En un contexto de prototipado, fijas una versión y sigues adelante. En un sistema de producción con pipelines CI/CD, auditoría de dependencias y revisiones de seguridad, cada cambio que rompe la compatibilidad cuesta horas de ingeniería.

Cajas negras de depuración. Cuando un pipeline RAG devuelve una mala respuesta, necesitas inspeccionar cada etapa: la transformación de la consulta, el embedding, el paso de recuperación, el re-ranking y el ensamblaje del prompt. LangChain envuelve cada uno de estos en capas de abstracción — cadenas, runnables, callbacks — que dificultan ver qué sucedió realmente en cada paso. Los equipos reportan que pasan más tiempo depurando el framework que depurando la lógica del pipeline.

Sobre-ingeniería de pipelines simples. La mayoría de los sistemas RAG en producción siguen un patrón directo: embeber la consulta, buscar en un almacén vectorial, ensamblar el contexto en un prompt, llamar a un modelo. Esto es quizás 100 líneas de código directo. LangChain introduce conceptos como cadenas, agentes, analizadores de salida, recuperadores y objetos de memoria para lo que es fundamentalmente un flujo de datos lineal. La sobrecarga cognitiva es real, especialmente al incorporar nuevos ingenieros al código base.

Acoplamiento al proveedor. LangChain soporta docenas de proveedores de LLM, almacenes vectoriales y modelos de embeddings a través de su capa de integración. Pero esta capa de integración significa que dependes de LangChain para mantener wrappers para cada proveedor. Cuando un proveedor actualiza su SDK, esperas a que LangChain se ponga al día. Cuando quieres usar una funcionalidad específica del proveedor, luchas contra la abstracción para acceder a ella.

Nada de esto significa que LangChain sea un mal proyecto. Significa que el framework está optimizado para amplitud y velocidad de inicio, no para las preocupaciones operativas que importan en producción: capacidad de depuración, estabilidad y transparencia.

Alternativa 1: Llamadas Directas a SDKs

El camino más común que toman los equipos al dejar LangChain es el más simple: eliminar el framework por completo y llamar directamente a los SDKs de los proveedores.

Un pipeline RAG de producción construido con llamadas directas típicamente se ve así:

1. Embeber la consulta usando el SDK de tu proveedor de embeddings (OpenAI, Cohere, o un modelo local vía sentence-transformers)
2. Buscar en tu almacén vectorial usando el cliente nativo del almacén (Pinecone, Weaviate, Qdrant, pgvector)
3. Opcionalmente re-rankear los fragmentos recuperados usando un cross-encoder o una API de re-ranking
4. Ensamblar el prompt insertando el contexto recuperado en tu plantilla de prompt
5. Llamar al LLM usando el SDK del proveedor con tu prompt ensamblado

Cada paso es una llamada a función. Cada llamada a función devuelve datos que puedes registrar, inspeccionar y probar independientemente. No hay estado de framework que gestionar, no hay sistema de callbacks que configurar, no hay abstracción de cadena entre tú y la operación real.

Cuándo encaja: Equipos con ingeniería sólida en Python/TypeScript, pipelines bien definidos que no cambiarán de forma frecuentemente, y una necesidad de observabilidad completa en cada paso. Esta es la mejor alternativa on-premise a LangChain cuando quieres cero dependencias externas más allá de los servicios que ya usas.

El coste: Escribes más código. Construyes tu propia lógica de reintentos, tu propio procesamiento por lotes, tu propia gestión de prompts. Para un solo pipeline esto es trivial. Para diez pipelines entre múltiples equipos, terminarás construyendo una biblioteca interna — que es, en efecto, tu propio mini-framework.

Alternativa 2: LlamaIndex

LlamaIndex (anteriormente GPT Index) ocupa un punto medio. Sigue siendo un framework, pero uno diseñado específicamente para recuperación e indexación en lugar de orquestación de LLM de propósito general.

La diferencia clave en filosofía: LangChain intenta abstraer toda la pila de aplicaciones LLM (agentes, herramientas, memoria, cadenas). LlamaIndex se enfoca estrictamente en el problema de indexación y recuperación de datos — cómo conseguir el contexto correcto para el modelo.

En la práctica, esto significa que las abstracciones de LlamaIndex se corresponden más estrechamente con lo que los pipelines RAG realmente hacen. Sus conceptos centrales — nodos, índices, motores de consulta y recuperadores — corresponden directamente a las etapas de un pipeline de recuperación. Pasas menos tiempo luchando contra el framework porque el modelo mental del framework coincide con el problema.

LlamaIndex también ha sido más conservador con los cambios de API, aunque ha tenido su propia cuota de reestructuración (la división llama-index-core reflejó la modularización de LangChain).

Cuándo encaja: Equipos que quieren las conveniencias del framework — integraciones preconstruidas, valores predeterminados sensatos, utilidades de análisis de documentos — sin la superficie de abstracción extensa de LangChain. LlamaIndex es particularmente fuerte si tu pipeline involucra procesamiento complejo de documentos (fragmentación jerárquica, síntesis multi-documento, extracción estructurada de PDFs).

El coste: Sigues dentro de un framework. Sigues dependiendo de los mantenedores para mantener las integraciones actualizadas. Pero la superficie es menor, así que el riesgo de dependencia es menor.

Alternativa 3: Constructores Visuales de Pipelines

Una tercera categoría ha surgido para equipos que quieren construir pipelines RAG sin LangChain y sin escribir código de orquestación de pipelines en absoluto: constructores visuales de pipelines y plataformas low-code.

Herramientas como Flowise, Langflow, Haystack Studio y plataformas empresariales dedicadas te permiten ensamblar pipelines de recuperación conectando nodos en un grafo visual. Cada nodo representa un paso — embedding, recuperación, re-ranking, generación — y la plataforma maneja la ejecución, el monitoreo y el despliegue.

Algunas de estas herramientas usan LangChain o LlamaIndex internamente pero te protegen de la complejidad del framework. Otras están construidas sobre sus propios motores de ejecución.

Cuándo encaja: Equipos donde las personas que construyen pipelines RAG son expertos en el dominio (analistas de datos, gerentes de producto, ingenieros de soluciones) en lugar de ingenieros backend. También es útil para experimentación rápida — puedes probar veinte estrategias de fragmentación diferentes en una tarde intercambiando nodos.

El coste: Intercambias control a nivel de código por facilidad de uso. La personalización más allá de lo que la plataforma soporta requiere soluciones alternativas o plugins. La optimización del rendimiento es más difícil cuando no puedes ver ni modificar el código subyacente. Y agregas una dependencia de plataforma sobre tu infraestructura.

Cuándo LangChain Sigue Siendo la Elección Correcta

Sería deshonesto escribir un artículo sobre RAG sin LangChain y no reconocer dónde LangChain genuinamente brilla.

Aprendizaje y prototipado. Si eres nuevo en RAG y quieres entender las partes móviles, los tutoriales y recursos comunitarios de LangChain no tienen rival. Obtendrás un prototipo funcional más rápido con LangChain que con cualquier otro enfoque. Las abstracciones que se convierten en responsabilidades en producción son activos cuando estás aprendiendo — te permiten enfocarte en conceptos sin ahogarte en detalles de implementación.

Experimentación rápida. Cuando necesitas probar una docena de estrategias de recuperación, proveedores de modelos y patrones de prompts en una semana, las integraciones plug-and-play de LangChain ahorran tiempo real. La amplitud del framework es una ventaja cuando estás explorando, aún no comprometido con una arquitectura específica.

Arquitecturas centradas en agentes. Si tu sistema genuinamente necesita comportamiento agéntico — uso de herramientas, razonamiento multi-paso, enrutamiento dinámico — las abstracciones de agentes de LangChain (especialmente vía LangGraph) están entre las más maduras disponibles. Las llamadas directas a SDKs se complican rápido cuando estás construyendo agentes autónomos.

Equipos pequeños con necesidades amplias. Una startup de tres personas construyendo una funcionalidad de IA no necesita una arquitectura de pipeline a medida. LangChain los lleva al mercado más rápido, y los costes operativos de sus abstracciones no se materializan hasta que alcanzan una escala que es un buen problema tener.

El Marco de Decisión

Aquí hay una forma simple de pensar sobre qué enfoque se ajusta a tu situación:

La respuesta honesta es que no existe un enfoque universalmente mejor. Los equipos que construyen pipelines de recuperación para producción sin un framework de Python tienden a converger en llamadas directas a SDKs para los pipelines principales y mantienen un framework para experimentación. Los equipos que necesitan moverse rápido y aún no están preocupados por la madurez operativa están bien servidos por LangChain.

Lo importante es tomar la decisión deliberadamente, basándose en las restricciones específicas de tu equipo — no porque "todos usan LangChain" o porque "los frameworks son malos". Ambas afirmaciones se desmoronan bajo el peso de cualquier decisión de ingeniería real.

Dónde Encaja Ertas

Ertas está diseñado para equipos que ya han decidido que quieren control sobre su infraestructura de IA. Ya sea que estés llamando directamente a los SDKs de proveedores, usando LlamaIndex o migrando desde LangChain, Ertas maneja la capa operativa debajo: despliegue de modelos, gestión de pipelines de datos y controles de gobernanza.

Tú construyes el pipeline RAG a tu manera. Ertas se asegura de que funcione de manera confiable, cumpla con las normativas y escale sin re-arquitectura. Sin opiniones de framework impuestas — solo infraestructura que no se interpone en tu camino.