Red Hat mete AutoRAG en OpenShift AI para ajustar pipelines RAG sin disparar el coste
La compañía propone separar la indexación, la recuperación y el mantenimiento en tres pipelines independientes y medir la calidad con conjuntos de evaluación reproducibles.
Red Hat ha integrado AutoRAG en OpenShift AI, su plataforma para desplegar y operar modelos, con una promesa concreta: que los equipos ajusten la recuperación de sus pipelines RAG sin recurrir a la fuerza bruta cada vez que la precisión cae. El argumento es que ensanchar la ventana de contexto no arregla nada y encarece la factura.
Quien haya llevado un RAG de la demo a producción reconoce el patrón. Un PDF limpio entra en el prototipo, el índice vectorial se construye con el código del tutorial y las respuestas salen impecables. Seis meses después el corpus son miles de manuales a varias columnas, informes con tablas y contratos escaneados sin capa de texto: la precisión se hunde. La reacción habitual, duplicar el tamaño de los fragmentos, recuperar veinte candidatos y cambiar a un modelo frontera más caro, sube la latencia y el consumo de memoria en la GPU sin que la calidad acompañe.
Por qué ensanchar el contexto empeora las cosas
Red Hat apunta a dos mecanismos. El primero es la degradación de la atención: meter fragmentos poco relevantes introduce ruido, y los modelos sufren sesgo posicional. Rinden mejor cuando el dato clave está al principio o al final del prompt y peor cuando queda enterrado en medio. Los modelos de contexto largo actuales resuelven mejor la búsqueda de un hecho aislado, pero siguen cayendo cuando la respuesta exige combinar varios hechos repartidos por la ventana. Es lo que Databricks documentó en su análisis y lo que ya aparecía en el trabajo de Liu et al. sobre contexto largo.
El segundo mecanismo es económico. Cada token del prompt se procesa antes de generar nada, así que el tiempo hasta el primer token se dispara. Pasar de 384 a 16.000 tokens consume memoria de caché KV en la GPU, reduce el espacio disponible y obliga a aprovisionar clústeres multi-GPU más grandes solo para mantener la concurrencia. Anthropic llegó a la misma conclusión en su propuesta de recuperación contextual: forzar la ventana sube coste y latencia sin garantizar mejor recuperación.
Tres pipelines en lugar de uno
La arquitectura que defiende el fabricante parte el RAG en tres procesos independientes. El de indexación corre por lotes o de forma programada: parsea los ficheros, extrae metadatos, normaliza el diseño, trocea, genera embeddings y llena el almacén vectorial, con Docling para convertir maquetas complejas a Markdown estructurado. El de recuperación trabaja en tiempo real: búsqueda híbrida densa y por palabra clave, reranking, control de acceso por roles, construcción del prompt y generación, apoyado en vLLM y llm-d para el enrutado de inferencia consciente de la caché KV. El tercero, de mantenimiento, opera en segundo plano con MLflow para actualizaciones, borrados, peticiones de derecho al olvido, re-embedding y detección de deriva del corpus.
Sobre esa base, AutoRAG se encarga de medir. Gen AI studio dentro de OpenShift AI automatiza la evaluación con conjuntos reproducibles en lugar de comprobar unas cuantas preguntas a ojo, y cubre tres métricas de producción: corrección del contexto, es decir, si los fragmentos recuperados contienen los datos necesarios, y otras dos que el texto original deja a medias.
Todo esto lo firma Red Hat sobre su propio producto. En la entrada no hay ningún banco de pruebas independiente ni cifras de mejora atribuidas a AutoRAG, y el proveedor es también quien elige el ejemplo. Queda por ver si la optimización automática aguanta con corpus ajenos al suyo y con presupuestos de GPU reales.
