Multimodalidad, contexto largo y benchmarks: hacia dónde va RAG

Última entrega de la serie. Toca separar lo que está madurando de verdad de lo que sigue siendo material de conferencia, atender de una vez a la pregunta que aparece en cada conversación sobre RAG —si el contexto largo lo hace innecesario— y cerrar el recorrido de los siete bloques con el principio que los atraviesa.

Lo que está madurando

Recuperación multimodal

Durante años, «indexar un documento» significó extraer su texto y tirar el resto. Los gráficos, los esquemas, las capturas y buena parte de las tablas se perdían en la ingesta, y con ellos una fracción considerable de la información de manuales técnicos, informes financieros y presentaciones.

Eso está cambiando por dos vías. La primera es indirecta y ya es práctica común: describir la imagen con un modelo de visión durante la indexación e indexar esa descripción como texto. Funciona, es barata de razonar y encaja con todo el pipeline existente, pero introduce una pérdida —la descripción es una interpretación— y un coste de indexación notable.

La segunda es directa: modelos de embeddings que sitúan imagen y texto en un mismo espacio vectorial, de modo que una pregunta en lenguaje natural puede recuperar una página completa sin pasar por texto intermedio. Es un enfoque que ha ganado tracción con rapidez para documentos con mucha maquetación, porque evita la parte más frágil de todo el pipeline, que es la extracción. Su coste está en el tamaño del índice y en que las herramientas de filtrado y evaluación alrededor están menos maduras.

Las tablas siguen siendo el caso peor. Una tabla no es texto ni es imagen: es una estructura, y la respuesta a una pregunta sobre ella suele exigir operar con sus celdas, no citarlas. La combinación que mejor funciona hoy sigue siendo la menos elegante: extraer la tabla a un formato estructurado, indexar por separado una descripción en prosa y responder con código sobre los datos cuando la pregunta es de cálculo.

Agentes de recuperación

El paso de «una consulta, una búsqueda» a «un sistema que decide cuántas búsquedas hace y en qué fuentes» ha dejado de ser experimental para preguntas complejas o comparativas, como vimos en la entrega 21. Lo que ha madurado no son los agentes en abstracto, sino un patrón concreto y acotado: descomponer la pregunta, buscar por partes, comprobar si lo recuperado basta y volver a buscar si no, con un límite duro de iteraciones.

Lo que no ha madurado es el control de coste y latencia. Un agente que decide por sí mismo cuántas llamadas hace tiene una distribución de coste con cola larga, y en producción eso obliga a presupuestos explícitos por consulta y a rutas rápidas para las preguntas simples, que siguen siendo la mayoría.

Memoria a largo plazo

La idea de que el sistema recuerde de una sesión a otra —preferencias, historial, hechos sobre el usuario— es útil y está apareciendo en producto. Técnicamente es RAG sobre un corpus personal muy pequeño y muy volátil, y hereda todos los problemas de esta serie más dos propios: decidir qué merece recordarse, y resolver las contradicciones cuando lo recordado deja de ser cierto. Es también un asunto de privacidad de primer orden. Yo lo pondría en «funciona para preferencias, es delicado para hechos».

Benchmarks serios

Durante mucho tiempo evaluar un RAG significaba medir el modelo generador y confiar. Han aparecido conjuntos de evaluación específicos que miden el sistema completo y no sólo su última pieza. RAGBench agrupa dominios distintos con anotaciones pensadas para evaluar por separado la recuperación y la fidelidad de la respuesta. CRAG se planteó como reto público con preguntas de dificultad variada, incluidas las que exigen combinar varias fuentes y las que no tienen respuesta. LegalBench-RAG lleva el ejercicio a un dominio donde la precisión de la cita importa tanto como la respuesta.

La aportación de todos ellos es la misma y es la correcta: separar las métricas por etapa. Un sistema puede fallar por recuperación o por generación, y un número agregado esconde cuál de las dos. La advertencia también es la de siempre, y vale para cualquier ranking: un resultado bueno en un benchmark general dice poco sobre tu corpus, tu idioma y tus preguntas. Sirven para descartar candidatos y para orientar; el criterio final sigue siendo tu golden dataset.

Lo que sigue siendo promesa

El RAG «autoafinable», que ajusta sus propios parámetros observando los resultados, es una idea razonable con muy pocas implantaciones defendibles: el bucle de realimentación es lento y ruidoso, y equivocarse en la dirección del ajuste degrada el sistema sin que nadie lo note.

Los grafos de conocimiento generados automáticamente sobre corpus grandes siguen teniendo un coste de indexación alto y una calidad de extracción irregular. GraphRAG resuelve una familia de preguntas que ninguna otra técnica resuelve —las que exigen agregar información dispersa en decenas de documentos—, y ahí está justificado. Como sustituto general del RAG vectorial, no.

Y el prometido «fin del chunking» —arquitecturas que hagan innecesario decidir cómo trocear— no ha llegado. Las técnicas recientes de la entrega 11 reducen el daño de un troceado malo; ninguna elimina la decisión.

La pregunta del contexto largo

Las ventanas de contexto han crecido varios órdenes de magnitud en pocos años, y con cada salto reaparece el argumento: si caben cientos de miles de tokens, ¿para qué recuperar? Pégalo todo.

El argumento tiene una parte cierta que conviene reconocer. Para corpus pequeños y estables —un manual, un contrato, un conjunto de políticas que cabe entero— montar un pipeline de recuperación es sobreingeniería, y meter el documento completo en el contexto da mejores resultados con menos piezas. Esa frontera se ha movido a favor del contexto largo y seguirá moviéndose. Muchos proyectos que hoy empiezan por montar un RAG deberían empezar por probar sin él.

Pero la respuesta general sigue siendo que no, por cuatro razones que no dependen del tamaño de la ventana.

• Coste. Se paga por token de entrada en cada consulta. Enviar un corpus de un millón de tokens para responder a una pregunta cuya respuesta ocupa dos mil es pagar quinientas veces lo necesario, y multiplicado por el volumen diario. La caché de contexto del proveedor abarata este escenario de forma notable, pero no lo convierte en gratis ni en competitivo frente a recuperar cinco fragmentos.
• Trazabilidad. Con recuperación sabes exactamente qué material fundamenta la respuesta, porque es el que enviaste. Con el corpus entero en el contexto, la atribución vuelve a ser una afirmación del modelo sobre sí mismo. En cualquier dominio donde haya que justificar una respuesta, esa diferencia es decisiva.
• Control de acceso. Esta es la razón que cierra la discusión y la que menos se menciona. Si el contexto es el corpus entero, todos los usuarios ven el mismo corpus. No hay forma de aplicar permisos por documento sobre un contexto único, salvo construir uno distinto por usuario, que es exactamente recuperación con filtro. La entrega 45 explicaba por qué filtrar después de generar no vale: aquí no hay ni siquiera dónde filtrar.
• Escala y frescura. Ningún corpus corporativo real cabe en ninguna ventana. Y aunque cupiera, actualizar un contexto cacheado con cada cambio de documento reintroduce el problema de indexación por otra puerta.

Lo que sí ha cambiado, y es una conclusión práctica útil, es el reparto de trabajo. Con ventanas amplias se puede ser menos tacaño con el contexto: enviar diez o veinte fragmentos en vez de tres, incluir el documento padre completo del que salió el fragmento, permitir historiales de conversación largos. La recuperación deja de tener que acertar con precisión quirúrgica y pasa a tener que acertar con holgura, que es un problema bastante más fácil. Contexto largo y RAG no compiten: el primero relaja las exigencias del segundo.

Para seguir

Cuarenta y siete entregas dan para un recorrido completo, y merece la pena verlo entero de una vez.

El bloque primero (01-07) fijó los fundamentos: qué problema resuelve RAG, los seis componentes del pipeline, embeddings, bases vectoriales, índices aproximados, el prompt aumentado, y la comparación con fine-tuning y contexto largo. El segundo (08-13) fue el menos vistoso y el más determinante: ingesta, tres entregas de troceado, metadatos y ciclo de vida del corpus. El tercero (14-21) recorrió las técnicas de recuperación, de la línea base a la búsqueda híbrida, el reranking, la transformación de consultas, HyDE, los bucles de autocorrección, GraphRAG y los agentes.

El cuarto (22-27) se ocupó de elegir modelos —embeddings comerciales, abiertos, en español, generadores y rerankers—; el quinto (28-35), de elegir infraestructura, desde pgvector hasta los gestionados, con la comparativa completa y el caso a favor de prescindir de framework. El sexto (36-40) fue el de la evaluación: las tres capas de métricas, recuperación, generación, herramientas y el golden dataset. Y este séptimo (41-47) ha cubierto la producción: arquitectura de referencia, economía y cachés, alucinaciones, seguridad del corpus, permisos y multi-tenant, observabilidad y este cierre.

Si hubiera que quedarse con una sola frase de las cuarenta y siete entregas, sería la que ha ido apareciendo desde la primera: la calidad de la recuperación pone el techo a la calidad del sistema. Ningún modelo generador, por bueno que sea, responde bien a partir de material equivocado. Ninguna plantilla de prompt compensa un fragmento que no se recuperó. Ninguna optimización de coste importa si la respuesta no es correcta. El trabajo aburrido —limpiar la ingesta, decidir el troceado, poner metadatos, construir cincuenta preguntas con respuesta verificada— es donde se decide si el sistema sirve. Lo demás son detalles de implementación sobre ese techo.

Los tres libros gratuitos de los que nace esta serie están disponibles en PDF y EPUB: RAG para tu negocio (nivel básico), RAG por dentro (intermedio) y RAG en producción (avanzado).

Aviso de contenido generado con inteligencia artificial.
Este artículo ha sido redactado con la asistencia de sistemas de inteligencia artificial y revisado antes de su publicación. Se informa de ello de forma expresa en cumplimiento de la normativa vigente sobre transparencia en el uso de IA.