Relevância não é filtro, é roteiro: a Tencent repensa a busca agêntica
Em vez de usar o modelo de recuperação para escolher quais documentos entram no contexto, o RARG usa a pontuação de relevância para dizer ao agente em que ordem vasculhar o corpus. Resultado: 84% de acerto contra 78% da linha de base — com menos chamadas de ferramenta.
Há duas formas de um agente de IA procurar informação num acervo grande. A primeira, dominante desde que o RAG virou padrão, é pré-selecionar: um modelo de embedding pontua os documentos por relevância, os melhores entram no contexto, e o agente responde a partir do que recebeu. A segunda, mais recente, é deixar o agente vasculhar o acervo por conta própria, rodando buscas textuais em sequência — algo mais parecido com um programador usando grep do que com um mecanismo de busca.
A segunda abordagem tem uma vantagem clara: o agente pode refinar a consulta, seguir pistas, voltar atrás. E uma desvantagem igualmente clara: sem orientação, ele se perde. Um grep ingênuo num acervo de um milhão de documentos devolve milhares de correspondências em ordem arbitrária, das quais o agente lê as primeiras — que muito provavelmente não são as melhores.
O RARG, publicado por pesquisadores da Tencent com o Instituto de Engenharia da Informação da Academia Chinesa de Ciências, resolve isso com uma inversão simples de propósito. A relevância continua sendo calculada por um recuperador denso, mas deixa de servir para filtrar o que o agente vê. Passa a servir para ordenar como ele procura.
A distinção que o paper cobra
Os autores colocam o argumento de forma direta: nos sistemas atuais, "a relevância permanece primariamente um mecanismo para construir o espaço, em vez de um sinal de execução de granularidade fina" dentro dele. Traduzindo: usa-se o modelo de recuperação para desenhar a caixa de areia e depois se abandona essa informação, deixando o agente cavar às cegas dentro dela.
O RARG mantém o sinal vivo durante toda a exploração, em três pontos distintos:
- Ordenação em nível de documento: o ranking define quais arquivos o
greppercorre primeiro — e a busca roda em linha única, sem paralelismo, justamente para que a ordem ranqueada seja preservada na saída. - Ponto de entrada inicial: os parágrafos mais relevantes para a consulta são entregues ao agente de saída, dando um começo de exploração em vez de uma folha em branco.
- Rerank em nível de correspondência: quando a saída da ferramenta precisa ser truncada — e sempre precisa —, o que sobrevive ao corte são os trechos locais mais relevantes, não os primeiros a aparecer.
A implementação é deliberadamente rasteira. Um recuperador por embedding monta arquivos de "escopo" com até 10 mil documentos ordenados, e o agente executa algo na linha de cat /tmp/scope_N.txt | xargs -d '\n' rg PATTERN. Nenhuma arquitetura nova, nenhum treino especial — apenas a decisão de não jogar fora o ranking depois de usá-lo uma vez.
Os números, e por que a contagem de chamadas importa
No BrowseComp-Plus com 100 mil documentos, usando GPT-4.5-mini como modelo do agente, o RARG++ chegou a 84% de acerto com 23,9 chamadas de ferramenta em média. A linha de base RISE ficou em 78% com 28,7 chamadas. Mais acerto com menos tentativas é a assinatura de um sinal de orientação que realmente funciona: o agente não está compensando com força bruta, está convergindo antes.
O teste mais informativo é o de escala. Ao aumentar o acervo para um milhão de documentos, o RARG++ manteve 79%, enquanto o RISE caiu para 69%. Ou seja: a degradação com o tamanho do corpus — o calcanhar de aquiles da interação direta com acervo — foi cortada pela metade. Em recuperação pura, no benchmark BRIGHT, a variante RARG+ marcou 53,36 de nDCG@10, à frente de sistemas especializados em recuperação.
Por que isso é mais interessante do que parece
Nos últimos dois anos, a discussão sobre busca em sistemas de IA se organizou como uma disputa binária: recuperação densa por embeddings versus agentes que exploram o acervo com ferramentas de texto. Cada campo apontava a fraqueza do outro — os embeddings não raciocinam, os agentes não escalam.
O que o RARG mostra é que a disputa estava mal formulada. O recuperador denso não precisa competir com o agente pelo controle da busca; ele pode operar como camada de orientação, dizendo por onde começar e o que ler primeiro, enquanto o agente mantém a liberdade de reformular e voltar atrás. É uma divisão de trabalho, não uma escolha de arquitetura.
Os limites do resultado
Duas ressalvas honestas. A primeira é que os ganhos dependem da qualidade do recuperador que gera o ranking — se a ordenação inicial for ruim, o RARG orienta o agente na direção errada com mais eficiência do que antes. O método herda o viés do embedding em vez de corrigi-lo.
A segunda é a execução em linha única para preservar a ordem. Funciona, mas é uma escolha que troca latência por fidelidade de ranking — em acervos muito maiores, ou em cenários com restrição de tempo de resposta, esse custo pode deixar de ser aceitável.
O que fica
A parte elegante deste trabalho não está no ganho de seis pontos percentuais, está na observação que o produziu: os sistemas já calculavam a relevância de que precisavam e a descartavam cedo demais. Boa parte do avanço em agentes de busca nos próximos meses provavelmente virá menos de modelos maiores e mais desse tipo de auditoria — descobrir qual sinal útil o pipeline já produz e está jogando fora antes da hora.
Perguntas Frequentes
O que é busca agêntica?
É a abordagem em que um modelo de linguagem interage diretamente com um acervo de documentos usando ferramentas — busca textual, leitura de arquivos, refinamento de consulta — em vários passos, em vez de receber um conjunto fixo de trechos previamente recuperados. Ganha em flexibilidade e perde em previsibilidade e escala.
Qual a diferença entre o RARG e o RAG tradicional?
No RAG tradicional, o modelo de embedding seleciona os trechos que entram no contexto e o processo termina aí. No RARG, a pontuação de relevância continua sendo usada durante toda a exploração: define a ordem em que os arquivos são varridos, o ponto de partida da busca e o que sobrevive quando a saída da ferramenta precisa ser cortada.
Por que a contagem de chamadas de ferramenta importa?
Cada chamada consome tokens de contexto, tempo e dinheiro. Um agente que acerta mais usando menos chamadas está convergindo por orientação melhor, não por tentativa e erro — e o custo por consulta cai junto com a latência.