RAISE: RAG Design as an Architecture Search Problem

Resumen Técnico: RAISE: Diseño de RAG como un Problema de Búsqueda de Arquitectura

Enunciado del Problema
Los sistemas de Generación Aumentada por Recuperación (RAG) implican numerosas decisiones de diseño acopladas, que incluyen la reescritura de consultas, estrategias de fragmentación, profundidad de recuperación, mecanismos de reordenamiento y compresión de contexto. En la práctica, estos componentes suelen configurarse mediante heurísticas o ajuste por ensayo y error. Este enfoque dificulta la evaluación sistemática, la reproducibilidad y la comparación justa entre diferentes sistemas RAG. Los esfuerzos existentes para optimizar configuraciones de RAG (por ejemplo, AutoRAG, Self-RAG, AutoRAG-HP) utilizan pipelines, conjuntos de datos, espacios de búsqueda y protocolos de evaluación dispares, dejando al campo sin un marco compartido para comparar algoritmos de optimización bajo condiciones controladas.

Metodología
Los autores formulan el diseño de RAG como un problema de Búsqueda de Arquitectura, tratándolo específicamente como la selección de configuraciones de pipeline que optimizan el rendimiento de extremo a extremo bajo un presupuesto de evaluación fijo. Para permitir un estudio controlado, introducen RAISE (Motor de Búsqueda de Inteligencia RAG), un marco y una referencia integrales.

• Arquitectura del Marco: RAISE desacopla el sistema en tres componentes:

  1. Abstracción del Pipeline: Un grafo acíclico dirigido (DAG) parametrizado y modular que representa el flujo de trabajo de RAG. El espacio de búsqueda $\Theta$ es el producto cartesiano de los espacios de configuración para seis módulos: Reescritor de Consultas, Fragmentador, Recuperador de Texto/Visual, Reordenador, Poda y Generador. Esto soporta tanto pipelines de solo texto como multimodales (texto-visión).
  2. Capa de Evaluación: Mapea configuraciones a recompensas a nivel de tarea. La función objetivo es un promedio a nivel de conjunto de datos de la calidad de generación, soportando métricas léxicas (ROUGE-L, BLEU, METEOR, token-F1), semánticas y basadas en modelos.
  3. Interfaz del Controlador: Una API estandarizada a través de la cual 13 algoritmos de optimización distintos proponen configuraciones ($\theta_t$) y reciben recompensas ($r_t$) del entorno. Esto trata la configuración de RAG como un problema de optimización de caja negra.

• Entornos de Referencia: El marco se instancia en siete conjuntos de datos públicos que representan desafíos diversos de RAG:

  • Texto: TriviaQA (documentos largos), HotpotQA (multi-salto), MS MARCO (recuperación/reordenamiento), SQuAD v2 (extractivo/control de alucinaciones), LongBench-MF (contexto largo/campo cruzado) y LongBench-Qasper (razonamiento científico).
  • Multimodal: ScienceQA (anclaje visual-textual).
    Cada entorno utiliza un subconjunto proxy fijo (100 pares de preguntas y respuestas) para garantizar la viabilidad computacional manteniendo la estructura de la tarea.

• Algoritmos de Optimización: El estudio evalúa 13 algoritmos agrupados en siete familias: Búsqueda Aleatoria, Trayectoria Local (Greedy, Descenso de Coordenadas, Recocido Simulado, Búsqueda Local Iterativa), SMBO/Bayesiano (TPE), Estimación de Distribución (Método de Entropía Cruzada), Evolutivo (Evolución Regularizada), Bandit (Muestreo de Thompson, UCB) y estilo RL (GRPO, Dr. GRPO, Reinforce++).

Resultados Clave
Los autores realizaron una evaluación controlada utilizando tres semillas aleatorias y un presupuesto de 30 evaluaciones de configuración por algoritmo por entorno.

1. Interacción Optimizador-Entorno: Ningún algoritmo de optimización único domina en todos los entornos. El rendimiento depende altamente de la tarea. Por ejemplo, la Búsqueda Greedy tuvo el mejor desempeño en HotpotQA y TriviaQA, mientras que el Método de Entropía Cruzada (CEM) lideró en MS MARCO, y la Búsqueda Aleatoria fue competitiva en ScienceQA. Las clasificaciones agregadas no reflejan una superioridad universal; en cambio, los resultados deben interpretarse como interacciones entre la estrategia de búsqueda y el entorno RAG específico.
2. Sensibilidad de Módulos: Los estudios de ablación revelan que el impacto de módulos específicos del pipeline varía según la estructura de la tarea.
   • TriviaQA (documentos largos) es más sensible a la reescritura de consultas y a la poda.
   • HotpotQA (multi-salto) depende en gran medida de la profundidad de recuperación.
   • LongBench-MF es altamente sensible a la configuración de top-k de recuperación.
     Esto confirma que las elecciones óptimas de pipeline no son transferibles globalmente, sino que dependen de la estructura de evidencia de la tarea.
3. Búsqueda vs. Aleatorio: Bajo presupuestos igualados, los métodos de optimización explícita generalmente superan al muestreo aleatorio, aunque las ganancias suelen ser modestas. Los métodos adaptativos (por ejemplo, Bandit, estilo RL) tienden a desempeñarse mejor en ensayos posteriores al enfocarse en configuraciones prometedoras.
4. Estabilidad del Proxy: El estudio encontró que tamaños de tareas proxy de 100–200 ejemplos proporcionan estabilidad suficiente para clasificar optimizadores, con rendimientos decrecientes para subconjuntos más grandes.

Significado y Afirmaciones
El artículo afirma que RAISE proporciona un sustrato experimental común para una investigación justa, reproducible y sistemática sobre la optimización de hiperparámetros en RAG. Al separar el controlador, el espacio de búsqueda y el entorno, RAISE reduce factores de confusión relacionados con la implementación del pipeline y los protocolos de evaluación.

Los autores argumentan que la búsqueda de arquitectura de RAG debe reportarse como interacciones optimizador-entorno en lugar de a través de una única tabla de clasificación universal. Postulan que el campo requiere referencias estandarizadas similares a HPOBench o YAHPO Gym para avanzar en la comprensión de cómo diferentes sesgos de búsqueda se desempeñan bajo restricciones específicas de RAG. El marco está diseñado para ser extensible, permitiendo la integración de nuevos algoritmos de optimización y tareas de referencia sin alterar la implementación central del pipeline.

Limitaciones
Los autores reconocen que sus experimentos instan un espacio de búsqueda fijo sobre modelos específicos (serie Qwen3) y valores discretos. Otras familias de modelos, backends de recuperación o espacios de búsqueda continuos pueden alterar el comportamiento del algoritmo. Además, la dependencia de entornos proxy ligeros y un presupuesto fijo (30 ensayos) facilita la comparación amplia, pero no sustituye estudios con conjuntos de datos completos o presupuestos grandes. El objetivo principal utiliza un agregado léxico y a nivel de token con pesos iguales, tratando las métricas semánticas y basadas en modelos como señales auxiliares.