Resumo Técnico: De RAG Naive para Recuperação Agêntica Profunda para Conformidade Regulatória

1. Domínio do Problema e Motivação

O artigo aborda a implementação de Grandes Modelos de Linguagem (LLMs) em setores altamente regulamentados, focando especificamente na necessidade da Ontario Power Generation (OPG) de analisar milhares de páginas de registros regulatórios para a Ontario Energy Board (OEB). O desafio central não é meramente responder perguntas, mas projetar um sistema que recupere, de forma confiável, eficiente e verificável, o contexto de autoridade de um corpus vasto, proprietário e em contínua evolução.

Os autores identificam um modo de falha crítico nas implementações padrão: a Rotura de Contexto (Context Rot). Eles argumentam que o comprimento do contexto não é um recurso gratuito. À medida que as janelas de contexto se expandem com tokens irrelevantes, a competição de atenção degrada a qualidade da resposta e os sinais de recuperação enfraquecem. Consequentemente, o objetivo muda de maximizar o volume bruto de contexto para maximizar a densidade de evidência relevante.

O artigo rejeita explicitamente o ajuste fino (fine-tuning) de domínio específico como a solução primária para este caso de uso. O ajuste fino é considerado economicamente incompatível com corpora em evolução, onde o conhecimento congela no momento do treinamento, enquanto os registros regulatórios são atualizados frequentemente. Em vez disso, os autores defendem a Engenharia de Contexto — a construção deliberada de um contexto de inferência de alto sinal através de recuperação, filtragem e compressão.

2. Evolução Metodológica

O artigo traça a evolução do pipeline de recuperação através de três estágios distintos, cada um motivado por modos de falha específicos da iteração anterior.

Estágio I: Baseline de RAG Naive

• Arquitetura: Um pipeline padrão envolvendo OCR/extração estruturada, fragmentação (chunking) (500–800 tokens), incorporação (embedding) e recuperação híbrida (vetor denso + palavra-chave) com reclassificação por cross-encoder.
• Limitações: O sistema é determinístico e sem estado (stateless). Se a recuperação inicial falhar em apresentar os fragmentos relevantes devido a incompatibilidade de vocabulário ou dependências de múltiplos saltos (multi-hop), o LLM não consegue se autocorrigir. A única mitigação é aumentar o número de fragmentos recuperados ($k$), o que aumenta linearmente o custo e a latência, ao mesmo tempo em que exacerba a rotura de contexto.
• Resultado: Embora funcional para buscas simples, carece de flexibilidade para lidar com consultas regulatórias complexas de múltiplos saltos.

Estágio II: Recuperação Agêntica via Chamada de Função (Function Calling)

• Arquitetura: O LLM transita de um consumidor passivo para um recuperador ativo. Ele é equipado com uma ferramenta de busca e reformula iterativamente as consultas com base em resultados intermediários (feedback de pseudo-relevância).
• Mecanismos Chave:
  • Descoberta Progressiva: O agente emite múltiplas chamadas de ferramenta com consultas refinadas, estreitando o espaço de busca usando filtros de metadados (ex: IDs de exibição específicos ou anos de casos tarifários).
  • Escalação de Fragmento para Documento: Uma regra de decisão é introduzida para escalar da recuperação de fragmentos para a leitura do documento completo apenas quando o ganho de evidência esperado ($\Delta U$) justifica o acréscimo de latência ($\Delta T$) e custo ($\Delta C$).
  • Particionamento de Capacidade: Para satisfazer as restrições de residência de dados canadense, o conteúdo visual (gráficos/diagramas) que requer inferência visual é delegado a um modelo hospedado no Canadá, enquanto o agente de raciocínio principal permanece separado.
• Limitações: A chamada de função introduz o overhead de esquemas JSON. Em cenários de pior caso, com muitas consultas de baixa qualidade, o consumo de tokens pode exceder o baseline do Estágio I.

Estágio III: Recuperação Agêntica Profunda (PEA-CAE)

• Arquitetura: Um sistema maduro que apresenta planejamento explícito, delegação de subagentes hierárquicos e síntese de ferramentas baseada em código.
• Mecanismos Chave:
  • Planejamento Explícito: O agente decompõe consultas complexas em uma sequência de subpergunta antes do início da recuperação, armazenando achados intermediários em uma memória de trabalho.
  • Subagentes Hierárquicos: Para evitar a rotura de contexto em longas cadeias de raciocínio, o agente principal gera subagentes para tarefas subordinadas delimitadas. Os subagentes realizam pesquisas profundas e retornam apenas resumos comprimidos, evitando que artefatos de recuperação intermediária consumam a janela de contexto do agente principal.
  • Síntese de Ferramentas Baseada em Código: Em vez de funções JSON pré-definidas, o agente escreve código Python/Bash em tempo de execução para interagir com APIs e processar dados. Isso amortiza o overhead das ferramentas e permite expressividade combinatória sem um limite fixo de ferramentas.
  • Framework PEA-CAE: O sistema é formalizado como Aquisição Progressiva de Evidências com Escalação Consciente de Custo (Progressive Evidence Acquisition with Cost-Aware Escalation). Ele impõe regras para filtrar primeiro, comprimir precocemente, escalar tardiamente e comprimir a amplitude.

3. Principais Contribuições

O artigo apresenta cinco contribuições primárias:

1. Caracterização Algorítmica: Uma análise estágio a estágio de três arquiteturas de recuperação implantadas em produção, vinculando modos de falha específicos a transições arquiteturais.
2. Framework Formal (PEA-CAE): Uma formalização da política de recuperação madura que equilibra a aquisição de evidências com restrições de custo e latência.
3. Análise Empírica: Dados de rastreamento operacional demonstrando os compromissos entre utilização da janela de contexto, precisão de recuperação e frequência de escalação.
4. Padrão de Soberania de Dados: Uma estratégia de particionamento de capacidade para implantações de múltiplas jurisdições, separando o processamento visual (hospedado localmente) do raciocínio geral.
5. Conexão Teórica: Uma análise comparativa vinculando o design de sistemas práticos (reformulação adaptativa de consulta, descoberta progressiva de documentos) às teorias clássicas de recuperação de informação e de busca de informação (information foraging).

4. Resultados e Observações

Com base em rastreamentos operacionais do sistema de Estágio III (Agente Profundo):

• Taxa de Sucesso: Em uma amostra de 14 execuções, todas as 6 execuções agênticas da OEB foram bem-sucedidas.
• Latência: As durações das tarefas variaram de 24,8 segundos a 223 segundos (mediana de 92,1s), refletindo um loop de pesquisa sustentado em vez de uma busca de passagem única.
• Eficiência de Escalação: O sistema demonstrou uma razão de busca-para-escalação de aproximadamente 9,6:1. A extração de documentos completos ocorreu em apenas ~10% dos eventos de recuperação, confirmando a intenção de design de "escalação seletiva".
• Variância de Latência: A extração de documentos completos mostrou alta latência de cauda (até 12,14s), reforçando a necessidade de manter a escalação seletiva para evitar a degradação do desempenho.

5. Significância e Alegações

O artigo afirma que, para grandes corpora regulatórios em evolução, a engenharia de contexto é um caminho mais tratável e economicamente viável do que o ajuste fino de domínio específico. A "inteligência" do sistema reside não nos pesos do modelo, mas nos algoritmos que constroem janelas de contexto de alto sinal.

Os autores argumentam que a progressão do RAG ingênuo para a recuperação agêntica profunda espelha ideias clássicas de recuperação de informação, introduzindo primitivas de sistema práticas, tais como:

• Reformulação adaptativa de consultas.
• Descoberta progressiva de documentos.
• Sumarização de subagentes hierárquicos.

A tese central é que o contexto permanece um recurso escasso, mesmo à medida que os tamanhos nominais das janelas crescem. Portanto, a estratégia ideal é recuperar progressivamente, escalar seletivamente e comprimir agressivamente. O artigo conclui que o sucesso operacional em IA regulada depende menos da adaptação do modelo e mais da gestão conjunta da qualidade da recuperação, do overhead das ferramentas, da latência e do crescimento do contexto.