RAISE: RAG Design as an Architecture Search Problem

Resumo Técnico: RAISE: Design de RAG como um Problema de Busca de Arquitetura

Declaração do Problema
Sistemas de Geração Aumentada por Recuperação (RAG) envolvem inúmeras escolhas de design acopladas, incluindo reescrita de consultas, estratégias de fragmentação, profundidade de recuperação, mecanismos de reranking e compressão de contexto. Na prática, esses componentes são tipicamente configurados por meio de heurísticas ou ajuste por tentativa e erro. Essa abordagem dificulta a avaliação sistemática, a reprodutibilidade e a comparação justa entre diferentes sistemas RAG. Esforços existentes para otimizar configurações de RAG (por exemplo, AutoRAG, Self-RAG, AutoRAG-HP) utilizam pipelines, conjuntos de dados, espaços de busca e protocolos de avaliação díspares, deixando o campo sem um framework compartilhado para comparar algoritmos de otimização sob condições controladas.

Metodologia
Os autores formulam o design de RAG como um problema de Busca de Arquitetura, tratando-o especificamente como a seleção de configurações de pipeline que otimizam o desempenho de ponta a ponta sob um orçamento de avaliação fixo. Para permitir um estudo controlado, eles introduzem o RAISE (RAG Intelligence Search Engine), um framework e benchmark abrangentes.

• Arquitetura do Framework: O RAISE desacopla o sistema em três componentes:

  1. Abstração de Pipeline: Um grafo acíclico direcionado (DAG) parametrizado e modular que representa o fluxo de trabalho do RAG. O espaço de busca $\Theta$ é o produto cartesiano dos espaços de configuração para seis módulos: Reescritor de Consultas, Fragmentador, Recuperador de Texto/Visual, Reranker, Poda e Gerador. Isso suporta pipelines apenas de texto e multimodais (texto-visão).
  2. Camada de Avaliação: Mapeia configurações para recompensas em nível de tarefa. A função objetivo é uma média em nível de conjunto de dados da qualidade de geração, suportando métricas lexicais (ROUGE-L, BLEU, METEOR, token-F1), semânticas e baseadas em modelos.
  3. Interface do Controlador: Uma API padronizada através da qual 13 algoritmos de otimização distintos propõem configurações ($\theta_t$) e recebem recompensas ($r_t$) do ambiente. Isso trata a configuração de RAG como um problema de otimização de caixa preta.

• Ambientes de Benchmark: O framework é instanciado em sete conjuntos de dados públicos que representam desafios diversos de RAG:

  • Texto: TriviaQA (documentos longos), HotpotQA (multi-hop), MS MARCO (recuperação/reranking), SQuAD v2 (controle de extração/alucinação), LongBench-MF (contexto longo/campo cruzado) e LongBench-Qasper (raciocínio científico).
  • Multimodal: ScienceQA (ancoragem visual-textual).
    Cada ambiente usa um subconjunto proxy fixo (100 pares QA) para garantir viabilidade computacional, mantendo a estrutura da tarefa.

• Algoritmos de Otimização: O estudo avalia 13 algoritmos agrupados em sete famílias: Busca Aleatória, Trajetória Local (Guloso, Descida de Coordenadas, Simulated Annealing, Busca Local Iterativa), SMBO/Bayesianos (TPE), Estimativa de Distribuição (Método de Entropia Cruzada), Evolutivos (Evolução Regularizada), Bandit (Amostragem de Thompson, UCB) e estilo RL (GRPO, Dr. GRPO, Reinforce++).

Resultados Chave
Os autores conduziram uma avaliação controlada usando três sementes aleatórias e um orçamento de 30 avaliações de configuração por algoritmo por ambiente.

1. Interação Otimizador-Ambiente: Nenhum algoritmo de otimização único domina em todos os ambientes. O desempenho é altamente dependente da tarefa. Por exemplo, a Busca Gulosa teve o melhor desempenho no HotpotQA e TriviaQA, enquanto o Método de Entropia Cruzada (CEM) liderou no MS MARCO, e a Busca Aleatória foi competitiva no ScienceQA. Classificações agregadas não refletem superioridade universal; em vez disso, os resultados devem ser interpretados como interações entre a estratégia de busca e o ambiente RAG específico.
2. Sensibilidade de Módulos: Estudos de ablação revelam que o impacto de módulos específicos do pipeline varia conforme a estrutura da tarefa.
   • TriviaQA (documentos longos) é mais sensível à reescrita de consultas e poda.
   • HotpotQA (multi-hop) depende fortemente da profundidade de recuperação.
   • LongBench-MF é altamente sensível às configurações top-k de recuperação.
     Isso confirma que escolhas de pipeline ótimas não são globalmente transferíveis, mas dependem da estrutura de evidência da tarefa.
3. Busca vs. Aleatório: Sob orçamentos correspondentes, métodos de otimização explícitos geralmente superam a amostragem aleatória, embora os ganhos sejam frequentemente modestos. Métodos adaptativos (por exemplo, Bandit, estilo RL) tendem a performar melhor em tentativas posteriores, focando em configurações promissoras.
4. Estabilidade do Proxy: O estudo constatou que tamanhos de tarefas proxy de 100–200 exemplos fornecem estabilidade suficiente para classificar otimizadores, com retornos decrescentes para subconjuntos maiores.

Significado e Alegações
O artigo afirma que o RAISE fornece um substrato experimental comum para pesquisa justa, reprodutível e sistemática sobre otimização de hiperparâmetros de RAG. Ao separar o controlador, o espaço de busca e o ambiente, o RAISE reduz confusões relacionadas à implementação do pipeline e protocolos de avaliação.

Os autores argumentam que a busca de arquitetura de RAG deve ser relatada como interações otimizador-ambiente em vez de através de um único leaderboard universal. Eles postulam que o campo requer benchmarks padronizados semelhantes ao HPOBench ou YAHPO Gym para avançar a compreensão de como diferentes vieses de busca performam sob restrições específicas de RAG. O framework é projetado para ser extensível, permitindo que novos algoritmos de otimização e tarefas de benchmark sejam integrados sem alterar a implementação central do pipeline.

Limitações
Os autores reconhecem que seus experimentos instanciam um espaço de busca fixo sobre modelos específicos (série Qwen3) e valores discretos. Famílias de modelos alternativas, backends de recuperação ou espaços de busca contínuos podem alterar o comportamento do algoritmo. Além disso, a dependência de ambientes proxy leves e um orçamento fixo (30 tentativas) facilita a comparação ampla, mas não substitui estudos com conjunto de dados completo ou orçamento elevado. A objetivo principal usa um agregado lexical e em nível de token com pesos iguais, tratando métricas semânticas e baseadas em modelos como sinais auxiliares.