AutoRAG entra en OpenShift AI para ajustar el RAG sin ir a ojo
Red Hat añade AutoRAG, una herramienta open source que barre configuraciones de RAG, las puntúa contra un conjunto de evaluación y devuelve el patrón ganador listo para llamar desde un endpoint.
AutoRAG ya está en OpenShift AI como vista previa tecnológica. Es una herramienta open source que busca automáticamente la mejor configuración de un pipeline de generación aumentada por recuperación (RAG) para un corpus concreto, en lugar de dejar que alguien la elija a ojo siguiendo un tutorial. Red Hat ha publicado junto a ella una demo de extremo a extremo que arranca con una carpeta de políticas internas y termina en un asistente de cumplimiento normativo que responde con citas.
El patrón RAG no es la parte difícil. Lo que atasca a los equipos es la configuración: tamaño de los fragmentos, solapamiento, cuántos recuperar, qué modelo de embeddings usar y cómo se hace la búsqueda. No hay un ajuste universal; el bueno depende de los documentos y de las preguntas, así que no puede venir por defecto. Hay que descubrirlo corpus a corpus, y en un entorno regulado eso no es un sitio cómodo donde quedarse.
Barrido, puntuación y clasificación
En la consola de OpenShift AI, dentro de gen AI studio, se crea una ejecución de optimización de AutoRAG. Se elige un modelo de generación —la demo usa Llama 3.1 8B Instruct servido en vLLM— y un modelo de embeddings, se conecta el origen de datos (un bucket de almacenamiento de objetos con el compendio de políticas) y se sube un conjunto de evaluación etiquetado: pares de pregunta y respuesta esperada sacados de los propios documentos. La demo trae 25.
Después se elige la métrica a optimizar, por ejemplo fidelidad, que mide si la respuesta se ciñe a lo que dicen los documentos recuperados. A partir de ahí AutoRAG hace el trabajo que de otro modo serían días de prueba y error: explora distintos tamaños de fragmento, modelos de embeddings y ajustes de recuperación, ejecuta cada configuración contra el conjunto de evaluación y puntúa los resultados con un LLM que actúa como juez. Las candidatas acaban en una tabla ordenada, y cada una se puede abrir para ver qué hace exactamente: el método de troceado, el modelo de embeddings, la estrategia de recuperación, el almacén vectorial al que se ata y sus puntuaciones. Se puede validar ahí mismo, conversando con el patrón contra los documentos antes de escribir una sola línea de aplicación.
Es el mismo principio que Red Hat ya contó al montar este bucle a mano, solo que ahora lo ejecuta la plataforma.
Del resultado al endpoint
La diferencia con hacerlo por tu cuenta es que el patrón ganador no es un archivo de configuración pendiente de implementar: ya tiene detrás un almacén vectorial indexado y se llama desde un endpoint. La consola genera fragmentos de código en Python, Go, Node.js y curl con la URL del endpoint, una clave de API y el identificador del almacén vectorial.
El escenario de la demo es un banco europeo ficticio, Fed Aura Capital Bank, con seis políticas internas inventadas de unas 10.000 palabras que cruzan DORA, MiFID II, MiCA, CSRD, CRD V, Basel IV y la normativa AML/KYC, incluida la Travel Rule para transferencias por encima de 1.000 euros. Todo es ficticio, pero la forma del problema es la de cualquier entidad regulada.
Las herramientas de este tipo se juzgan por lo que ahorran en operación. Aquí la promesa es concreta: menos tiempo eligiendo ajustes y un resultado medido en lugar de estimado. Queda la advertencia habitual: sigue siendo una vista previa tecnológica y la demo la firma el propio fabricante, no una validación independiente.
