Capítulo 1 — La evolución de la arquitectura RAG

Primera entrega del recorrido capítulo por capítulo de LLM Primer III: Enhancing Enterprise AI with RAG. En el que los dos límites estructurales de un modelo base — conocimiento congelado y procedencia ausente — resultan tener una única respuesta arquitectónica, y esa respuesta ha desarrollado cuatro caras en tres años.

Por qué existe este capítulo

Un transformer entrenado sobre un corpus fijo tiene dos límites que ningún entrenamiento adicional borra del todo. Su conocimiento termina el día en que terminó el corpus. Y no puede decirte de qué documento salió una frase, porque la frase es un promedio estadístico sobre muchos, no una cita de uno solo. El primer fallo produce respuestas confiadamente erróneas sobre cualquier cosa reciente. El segundo produce citas confiadamente erróneas. Juntos producen la patología empresarial ya familiar: una respuesta que suena a autoridad y enlaza a una cláusula que no existe.

RAG es la respuesta arquitectónica a ambos a la vez. Dejas de pedirle al modelo que lo sepa todo de antemano y empiezas a entregarle el material relevante en tiempo de inferencia, recuperado de un corpus que tú controlas. El corpus se actualiza sin reentrenar. Los pasajes recuperados se convierten en citas porque los trajiste a propósito. El trabajo del modelo se encoge del recuerdo a la síntesis. El resto del capítulo es la historia de cómo ese movimiento simple, en tres años, creció hasta cuatro arquitecturas progresivamente más capaces.

1.1 Naive RAG: embeber, recuperar, rellenar

La forma más simple es la que describe todavía cualquier tutorial público. Offline: divide el corpus en chunks, embebe cada chunk, escribe los vectores en un índice. Online: embebe la consulta, recupera los k chunks más cercanos, concaténalos en un prompt, mándalo al modelo y devuelve la respuesta con los chunks listados como citas. Dos llamadas a funciones y una búsqueda vectorial.

La demo funciona. El producto rara vez. La similitud por vecino más cercano es un proxy de relevancia, no una medida de ella, y los modelos de embedding entrenados sobre texto general de la web confunden con tranquilidad rendimiento del huerto de manzanas con beneficios trimestrales de Apple. El chunker no tiene señal de dónde terminan las frases ni de dónde empiezan las tablas. Una sola pasada de recuperación no puede servir a una pregunta cuya respuesta vive repartida en tres documentos. Y cuando la recuperación falla, el modelo sintetiza con lo que haya llegado — las citas son reales, pero no respaldan ninguna parte de la respuesta.

1.2 RAG Avanzada: heurísticas alrededor de la misma pipeline

La segunda postura mantiene la columna embed-retrieve-generate y añade procesamiento antes y después de la llamada de recuperación. Las mejoras pre-recuperación apuntan a la consulta: reescritura, expansión, descomposición, HyDE (redactar una respuesta hipotética y embeber eso como consulta). Las mejoras post-recuperación apuntan a los candidatos: un reranker cross-encoder que puntúa consulta y pasaje juntos en lugar de embeberlos por separado, deduplicación, filtrado por metadatos, compresión del contexto.

Las ganancias no son pequeñas. Un reranker cross-encoder encima de un retriever vectorial mueve típicamente la relevancia del top-5 de la banda del 50-70% a la del 75-90%. La reescritura de consultas añade otros cinco a diez puntos cuando la formulación original era ambigua. La mayoría de los sistemas en producción etiquetados simplemente como "RAG" hoy están corriendo esta arquitectura, y para un amplio abanico de problemas empresariales — Q&A sobre documentación interna, deflexión de soporte, búsqueda en la base de conocimiento — es el nivel de inversión correcto. Lo que no te da es flexibilidad. Cada consulta sigue pasando por el mismo conducto.

1.3 RAG Modular: componentes componibles, enrutamiento explícito

Hacia 2024 tanto la investigación como las herramientas habían convergido en RAG Modular. Las mismas técnicas siguen presentes, pero se exponen como componentes discretos e intercambiables y la pipeline se ensambla por petición. Un router decide qué retrievers llamar — quizá un índice vectorial denso, un índice BM25, un almacén SQL, una API externa — y los resultados se fusionan, a menudo vía reciprocal rank fusion. El reranker se selecciona según el tipo de consulta. El generador se selecciona según el nivel de calidad requerido. La arquitectura ha pasado de ser una línea de etapas a un grafo de componentes.

Dos consecuencias prácticas. Primero, el sistema es testeable de un modo que las posturas anteriores no eran — cada componente puede evaluarse y reemplazarse de manera independiente. Segundo, el sistema es ajustable por clase de consulta: una búsqueda factual atraviesa un retriever rápido y un generador pequeño, una síntesis multi-documento atraviesa varios retrievers y uno grande, las dos sirviéndose de la misma librería de componentes. El precio es operativo. Cuando una respuesta es incorrecta, la pregunta ¿dónde se torció esto? tiene ahora muchas respuestas posibles, y el equipo necesita instrumentación capaz de localizar el fallo en un único componente. Invierte en la observabilidad antes de la arquitectura modular, no después.

1.4 RAG Agéntica: el LLM corre la pipeline

La cuarta postura invierte una suposición que las tres anteriores compartían en silencio — que el LLM es el último paso. En RAG Agéntica, el LLM corre la pipeline. Dado un catálogo de herramientas (búsqueda vectorial, SQL, web fetch, reranker, calculadora), el modelo piensa, elige una herramienta, observa el resultado, vuelve a pensar y termina cuando tiene una respuesta o llega a un límite de pasos. La arquitectura ha dejado de ser una pipeline y se ha convertido en un pequeño programa que el modelo escribe de nuevo para cada consulta.

Esto compra planificación multi-paso, selección dinámica de herramientas y patrones multi-agente como planner/retriever/critic/writer. Cuesta latencia, gasto en tokens y reproducibilidad — una sola consulta es ahora un árbol de decisiones en lugar de una secuencia fija, y consultas patológicas pueden gastar muchos turnos dando vueltas antes de producir una respuesta. Los sistemas agénticos en producción necesitan controles de presupuesto, límites de pasos y políticas de timeout que las pipelines fijas nunca tuvieron que pensar. El caso de uso correcto son preguntas cuya profundidad es variable e impredecible: síntesis de investigación, búsqueda legal sobre jurisprudencia, revisión de literatura. El caso de uso incorrecto es un bot de soporte estático, donde el bucle agéntico añade una varianza que la carga no necesitaba.

1.5 RAG frente a fine-tuning

La pregunta que todo equipo termina haciéndose. El planteamiento honesto es que resuelven problemas distintos. RAG aborda problemas de conocimiento — el modelo no sabe X, X cambia y el usuario necesita una cita. El fine-tuning aborda problemas de comportamiento — el modelo conoce la respuesta pero la presenta en formato incorrecto, se niega a seguir la plantilla de la empresa o divaga donde debería ser conciso. RAG es barato de montar y caro por consulta. El fine-tuning es caro una vez y barato por consulta. RAG itera en minutos (cambia un documento); el fine-tuning itera en días. Una heurística útil: si el fallo es el modelo no sabe, recurre a RAG. Si el fallo es el modelo sabe pero lo hace mal, recurre al fine-tuning. Muchos sistemas maduros acaban haciendo ambas cosas, pero empieza por RAG — la mayor parte de los fallos empresariales son fallos de conocimiento, no de comportamiento.

Lo que prepara el Capítulo 1

Toda arquitectura RAG — sea cual sea de las cuatro la que elijas — está aguas abajo de lo bien que pueda leer sus documentos fuente. Una pipeline Modular de última generación con un orquestador agéntico sigue trabajando con chunks que salieron de un paso de parsing en algún sitio aguas arriba. Si ese paso perdió la estructura de la tabla, descolocó el orden de lectura multi-columna o reemplazó los pies de figura por OCR estropeado, todos los componentes posteriores razonan sobre entrada corrupta. La arquitectura fija el techo del sistema. El parser fija su suelo. En la mayoría de los sistemas en producción importa más el suelo, porque la mayoría de los sistemas en producción están lejísimos del techo.

Próximamente — Capítulo 2: Parsing inteligente de documentos. Por qué una utilidad ingenua de PDF-a-texto destruye la calidad de la recuperación sin avisar, qué preserva en realidad el parsing consciente del layout y la alternativa multimodal que recupera directamente sobre imágenes de página.