Proxy-Pointer RAG: raciocínio temporal sem pré-compilação semântica

O Retrieval-Augmented Generation (RAG) empresarial enfrenta um desafio crescente: consultas temporais que exigem correlacionar informações distribuídas em dezenas de documentos ao longo de anos. Uma nova arquitetura chamada Proxy-Pointer propõe resolver isso sem o custo de pré-compilação semântica que alternativas como LLM-Wiki exigem.

O artigo de Partha Sarkar no Towards Data Science compara as duas abordagens usando um cenário real: rastrear o histórico de aquisições de uma empresa ao longo de uma década.

O problema: consultas temporais em RAG

O RAG tradicional funciona bem para perguntas contidas em um único documento. Mas falha em perguntas como:

• “Quais empresas adquirimos na última década?”
• “Como nossa estratégia de IA evoluiu desde 2018?”
• “Quais compromissos de sustentabilidade anunciados em relatórios anteriores foram cumpridos?”

Essas consultas exigem correlacionar informações de múltiplos documentos (relatórios anuais, contratos) ao longo do tempo — algo que o chunking tradicional não resolve.

LLM-Wiki: compilar conhecimento na ingestão

A abordagem LLM-Wiki registra o contexto temporal movendo o raciocínio para o momento da ingestão. Cada documento é processado por um LLM que extrai entidades, relacionamentos e fatos, mesclando-os em páginas canônicas como “Aquisições”, “Estratégia de IA”, “Sustentabilidade”.

Quando o usuário pergunta “quais empresas foram adquiridas?”, o sistema consulta a página canônica de aquisições — não os documentos originais.

Problema fundamental: o sistema precisa prever, durante a ingestão, quais informações serão necessárias para todas as perguntas futuras. Isso cria um trade-off entre completude (custo alto de processar tudo) e omissão (perguntas que exigirão revisitar documentos originais).

Proxy-Pointer: adiar a semântica para o momento da consulta

O Proxy-Pointer inverte a lógica. Em vez de pré-compilar conhecimento semântico, ele constrói uma representação estrutural (árvore esquelética) de cada documento na ingestão — um processo puramente baseado em regex, com custo zero de LLM. A compilação semântica é adiada para o momento da consulta.

Como funciona:

1. Chunking com limites de seção: chunks são criados dentro dos limites de cada seção do documento, nunca sobrepondo seções subsequentes
2. Metadados estruturais: cada chunk é etiquetado com a seção de origem e limites de linha, permitindo navegação precisa
3. Busca vetorial + reranker: seleciona as top-k seções mais relevantes para a consulta, usando metadados estruturais como filtro

Para a pergunta “quais empresas foram adquiridas na última década?”:

• LLM-Wiki: analisou todos os 10 relatórios anuais (200 páginas cada) durante a ingestão para construir a página canônica de aquisições
• Proxy-Pointer: busca apenas as seções de M&A dos 10 relatórios (top-5 seções × 10 relatórios = 50 seções), analisa semanticamente apenas essas seções quando a consulta chega

Diferenças arquiteturais

Quando usar cada abordagem

Organizações com corpora estáveis e consultas conceituais altamente repetitivas podem se beneficiar da base de conhecimento compilada do LLM-Wiki. Grandes repositórios empresariais com documentos em evolução, perguntas imprevisíveis e análise temporal ocasional se beneficiam mais do Proxy-Pointer.

O ponto central vai além dessas duas arquiteturas: o conhecimento deve ser compilado porque pode ser útil um dia, ou sintetizado apenas quando alguém pergunta?

Código aberto

O Proxy-Pointer é totalmente open-source (licença MIT) e está disponível no GitHub. O repositório inclui casos de uso prontos para teste.