Agentes de pesquisa profunda precisam de grafos de evidências

Em 15 de maio de 2026, Zhen Zhang e coautores publicaram Argus, um sistema de agentes de pesquisa profunda que trata a pesquisa como montagem de evidências, não como busca paralela por força bruta.¹

Essa diferença importa.

Agentes de pesquisa profunda conseguem executar muitas buscas, abrir muitas páginas e escrever respostas longas. Mas uma resposta longa não prova que o agente encontrou as evidências que faltavam. A busca paralela pode duplicar o mesmo conjunto de fontes, empurrar mais trechos para o contexto e ainda deixar a parte difícil sem sustentação.

Agentes de pesquisa profunda precisam de grafos de evidências. O agente deve saber quais afirmações precisam de apoio, quais evidências já existem, quais ainda faltam e quais frases finais dependem de quais fontes.

TL;DR

Agentes de pesquisa profunda não devem medir progresso pela quantidade de buscas executadas nem pelo volume de contexto preenchido. Devem medir progresso pela cobertura de evidências.

Argus oferece uma forma útil para a área. Seu Searcher reúne rastros de evidências para subconsultas, enquanto seu Navigator mantém um grafo de evidências compartilhado, verifica quais peças ainda faltam, distribui mais trabalho de busca e produz uma resposta final rastreável às fontes.¹ Isso afasta a pesquisa profunda de “executar mais agentes” e a aproxima de “montar a prova que falta”.

O mesmo padrão aparece em pesquisas recentes sobre agentes. paper.json dá aos artigos afirmações endereçáveis e limites de escopo.² ACDL dá ao contexto dos agentes uma linguagem formal de descrição.³ Trabalhos sobre exploração argumentam que agentes precisam de pontos de verificação verificáveis antes de agir.⁴ ARIS enquadra a principal falha da pesquisa de longo horizonte como sucesso plausível sem sustentação.⁵ AgentForesight defende auditoria online antes que um erro decisivo se espalhe por uma execução multiagente.⁶

A regra prática: toda resposta de pesquisa profunda deve carregar um grafo de evidências ou um pacote de revisão que mostre o que o agente provou, o que inferiu e o que continua sem solução.

Principais aprendizados

Para quem constrói agentes: - Acompanhe evidências como um grafo de afirmações, fontes, lacunas e dependências. - Direcione o trabalho de busca para evidências ausentes em vez de repetir consultas amplas.

Para equipes de produto: - Mostre cobertura de fontes, afirmações não resolvidas e desperdício com buscas duplicadas. - Permita que revisores inspecionem por que a resposta final cita cada fonte.

Para pesquisadores: - Separe coleta de evidências da síntese da resposta. - Avalie cobertura e rastreabilidade, não apenas a pontuação da resposta final.

Para operadores: - Trate um relatório longo e confiante como inacabado até que o grafo de evidências feche suas lacunas importantes. - Pergunte quais afirmações ainda não têm apoio primário antes de aceitar a resposta.

Por que a busca paralela trava?

Busca paralela parece progresso.

Dê a mesma pergunta de pesquisa a 10 agentes, e o sistema produz movimento. Agentes pesquisam, resumem, comparam e retornam descobertas parciais. A síntese final pode parecer completa porque a transcrição contém muitas fontes.

A falha fica escondida na redundância.

Argus nomeia esse problema diretamente. O artigo argumenta que respostas de pesquisa profunda combinam evidências complementares, enquanto execuções paralelas muitas vezes duplicam essas peças em vez de completá-las.¹ Mais execuções podem levar o contexto de agregação ao limite sem preencher as partes ausentes.¹

A lição não é “nunca paralelize”. A lição é “paralelize usando um mapa”.

O que Argus acrescenta?

Argus divide a pesquisa profunda em 2 papéis.

O Searcher coleta rastros de evidências para uma subconsulta por meio de interação no estilo ReAct.¹ O Navigator mantém um grafo de evidências compartilhado, verifica quais peças ainda faltam, direciona Searchers para coletá-las e raciocina sobre o grafo concluído para produzir uma resposta final rastreável às fontes.¹

Essa divisão de papéis muda o objeto de trabalho.

O Navigator dá ao agente uma memória do que a resposta ainda não tem. Sem essa camada, agentes paralelos podem continuar retornando evidências para a mesma afirmação fácil.

Argus também relata ganhos de desempenho. Com uma base MoE 35B-A3B, o artigo relata que Argus ganha 5,5 pontos com um único Searcher e 12,7 pontos com 8 Searchers paralelos, em média, em 8 benchmarks.¹ O detalhe importante não é só a pontuação. O detalhe importante é a arquitetura que torna úteis os Searchers adicionais.

Searchers se tornam úteis porque o Navigator os direciona para as evidências ausentes.

O que um grafo de evidências deve acompanhar?

Um grafo de evidências deve representar a resposta antes que a prosa se cristalize em torno dela.

No mínimo, ele deve acompanhar:

As arestas importam mais que os nós.

O grafo não precisa de formalidade acadêmica de banco de dados em grafo. Um objeto JSON, uma tabela de rastros ou um pacote de revisão pode funcionar. A propriedade importante é a capacidade de inspeção: outro revisor consegue ver por que a resposta diz o que diz.

Por que grafos de evidências ajudam revisores?

Revisores precisam de um objeto menor que a transcrição inteira.

Uma transcrição de pesquisa profunda pode incluir dezenas de chamadas de ferramenta, fontes, resumos, novas tentativas e notas. Em geral, o revisor quer respostas para perguntas mais precisas:

• Quais afirmações finais têm apoio direto?
• Quais afirmações dependem de interpretação secundária?
• Qual fonte aparece mais de uma vez sob resumos diferentes?
• Qual pergunta ausente o agente parou de investigar?
• Qual citação sustenta apenas o contexto, não a afirmação central?
• Qual limitação deve estreitar a resposta final?

Um grafo de evidências dá essa superfície aos revisores.

Essa estrutura combina naturalmente com pacotes de revisão. Uma resposta final não deve entregar apenas prosa. Deve entregar o estado das evidências que produziu essa prosa.

Como paper.json se encaixa?

Grafos de evidências precisam de objetos de fonte melhores.

Se cada artigo acadêmico entra no grafo como um PDF indiferenciado, o grafo ainda terá nós grosseiros. Um nó de afirmação pode apontar para um artigo, mas não consegue apontar facilmente para uma subafirmação, limite de escopo, definição ou comando de reprodução.

paper.json melhora a camada de entrada. A proposta dá aos artigos IDs estáveis de afirmação, listas explícitas do que não é afirmado, comandos shell por figura e IDs estáveis de definição.² Um agente de pesquisa pode usar esses IDs como nós do grafo.

Essa conexão importa para a qualidade das citações. A resposta pode citar C2 de um artigo em vez de citar vagamente o artigo inteiro. O grafo também pode registrar que C2 carrega uma limitação de does_not_claim[].

Grafos de evidências e artigos legíveis por agentes resolvem problemas vizinhos. O arquivo do artigo torna a evidência mais fácil de endereçar. O grafo torna a evidência mais fácil de montar.

Como a descrição de contexto se encaixa?

Agentes de pesquisa profunda também precisam saber o que entrou no contexto e quando.

ACDL, Agentic Context Description Language, mira esse problema na camada de prompt. O artigo argumenta que sistemas de agentes não têm um padrão para descrever composição de prompt e dinâmica de contexto, recorrendo a prosa, diagramas ou inspeção de código.³ ACDL dá aos sistemas construções para sequências de mensagens por função, conteúdo dinâmico, referências indexadas no tempo e estruturas condicionais ou iterativas.³

Um grafo de evidências deve se conectar ao estado do contexto.

A forma do contexto afeta a forma da evidência. Uma fonte não pode sustentar a resposta se o sintetizador nunca viu a passagem relevante. Uma limitação não pode restringir a resposta se ninguém a colocou no contexto.

Sistemas de pesquisa profunda precisam dos dois objetos: uma descrição de contexto e um grafo de evidências.

Por que a exploração importa?

Agentes de pesquisa podem se apegar cedo demais a uma trilha promissora.

“Look Before You Leap” identifica o aproveitamento prematuro como um modo de falha para agentes LLM em ambientes desconhecidos.⁴ O artigo apresenta Exploration Checkpoint Coverage como uma métrica verificável para saber se os agentes descobrem estados, objetos e affordances importantes antes da execução da tarefa.⁴

A pesquisa profunda tem a mesma forma. Agentes podem encontrar uma trilha plausível e começar a responder antes de entender o espaço de fontes.

Um grafo de evidências deve preservar uma fase de exploração:

1. Identificar as classes de afirmações de que a resposta precisará.
2. Mapear tipos prováveis de fonte.
3. Buscar fontes primárias antes de comentários.
4. Registrar classes de fontes ausentes como nós de lacuna.
5. Distribuir buscas direcionadas para as lacunas.
6. Sintetizar apenas depois que lacunas importantes forem fechadas ou receberem ressalvas explícitas.

Essa fase de exploração impede que o agente trate a primeira boa fonte como o centro da resposta.

O grafo dá ao agente um motivo para continuar procurando: uma lacuna aberta permanece visível.

O que dá errado sem o grafo?

Agentes de pesquisa de longa duração podem falhar sem parecer quebrados.

ARIS enquadra a falha central como sucesso plausível sem sustentação: um agente de longa duração produz afirmações cujo apoio de evidências permanece incompleto, mal relatado ou herdado do próprio enquadramento do agente.⁵ Essa falha pode passar por uma revisão casual porque o relatório final parece polido.

AgentForesight aborda um problema relacionado em sistemas multiagente. Ele argumenta que um único erro decisivo pode se espalhar por uma trajetória de longo horizonte, enquanto a atribuição pós-fato chega tarde demais para intervir.⁶ Seu auditor online vê apenas o prefixo atual e precisa decidir se continua ou emite um alerta antes que a trajetória completa termine.⁶

Grafos de evidências ajudam nos dois problemas.

O grafo não garante a verdade. Ele dá à verdade uma estrutura que a equipe consegue auditar.

O que produtos de pesquisa profunda devem mostrar?

Produtos de pesquisa profunda devem expor o estado das evidências.

O usuário não deve ver apenas uma resposta final com notas de rodapé. A interface deve mostrar:

Essa interface dá aos usuários uma forma de conduzir a execução. Eles podem pedir ao agente que preencha uma lacuna específica em vez de dizer “pesquise mais”. Podem rejeitar uma afirmação fraca sem descartar a resposta inteira. Podem ver quando o agente tem evidências suficientes para parar.

Uma boa UX de pesquisa profunda deve tornar as evidências ausentes visíveis antes que a prosa final as esconda.

O que as equipes devem construir primeiro?

Comece com uma tabela simples de evidências antes de construir um motor de grafo.

Depois, acrescente distribuição de trabalho:

1. Antes da síntese, liste todas as afirmações ausentes de alto valor.
2. Envie cada afirmação ausente a um Searcher com uma consulta estreita.
3. Exija que o Searcher retorne evidência ou uma indicação explícita de que não encontrou nada.
4. Atualize o grafo.
5. Sintetize apenas a partir de afirmações sustentadas e com ressalvas.

Essa primeira versão pode continuar simples. Uma tabela em Markdown pode superar uma transcrição invisível se obrigar o agente a mostrar a cobertura de evidências.

O padrão digno

Agentes de pesquisa profunda devem conquistar confiança mostrando sua estrutura de evidências.

Mais buscas podem ajudar. Mais agentes podem ajudar. Contexto mais longo pode ajudar. Nenhum desses insumos prova que a resposta final cobriu as peças ausentes.

Uma execução digna de pesquisa profunda deve responder 4 perguntas:

• Quais afirmações o agente tentou provar?
• Quais fontes sustentam cada afirmação?
• Quais lacunas ou conflitos permanecem?
• Quais frases finais dependem de quais evidências?

Quando essas respostas continuam visíveis, os usuários conseguem revisar o trabalho. Quando desaparecem dentro de uma prosa polida, os usuários precisam confiar em um resumo sem ver a forma da prova.

Pesquisa profunda precisa de grafos de evidências porque pesquisa não é um problema de contagem de buscas. Pesquisa é um problema de peças ausentes.

Resumo rápido

Agentes de pesquisa profunda precisam de grafos de evidências porque a busca paralela pode duplicar agrupamentos de fontes fáceis enquanto afirmações importantes permanecem sem sustentação. Argus oferece um padrão forte: um Searcher coleta rastros de evidências, enquanto um Navigator acompanha um grafo de evidências compartilhado, distribui trabalho para as peças ausentes e produz uma resposta rastreável às fontes.¹

A mesma lição se conecta a pesquisas adjacentes. paper.json melhora objetos de fonte no nível do artigo.² ACDL descreve como o contexto entra em sistemas de agentes.³ Pontos de verificação de exploração tornam a coleta de informações verificável.⁴ ARIS e AgentForesight mostram por que resultados polidos de longo horizonte precisam de evidências e revisão online antes que erros se espalhem.⁵⁶

A regra operacional é direta: não peça a um agente de pesquisa profunda apenas uma resposta. Peça o grafo de evidências que tornou a resposta possível.

FAQ

O que é um grafo de evidências para agentes de pesquisa profunda?

Um grafo de evidências conecta afirmações, fontes, trechos, lacunas, conflitos, limites de escopo e frases da resposta final. Ele permite que revisores vejam quais evidências sustentam cada parte de uma resposta de pesquisa profunda.

Por que a busca paralela não basta?

A busca paralela pode duplicar fontes e preencher contexto sem encontrar as evidências ausentes. Agentes de pesquisa profunda precisam de um mapa compartilhado do que a resposta ainda não tem.

Qual foi a contribuição do Argus?

Argus dividiu a pesquisa profunda nos papéis de Searcher e Navigator. O Searcher coleta rastros de evidências, enquanto o Navigator mantém um grafo de evidências compartilhado, distribui buscas para peças ausentes e produz uma resposta final rastreável às fontes.¹

Como paper.json se relaciona com grafos de evidências?

paper.json dá aos artigos acadêmicos IDs estáveis de afirmação, limites de escopo, definições e comandos de reprodução. Grafos de evidências podem usar esses IDs como nós precisos em vez de citar um artigo inteiro de forma vaga.²

O que um produto deve mostrar aos usuários?

Um produto deve mostrar cobertura de afirmações, links de evidências, lacunas não resolvidas, agrupamentos de buscas duplicadas, conflitos entre fontes, limites de escopo e decisões de revisão antes de pedir que usuários confiem na prosa final.

Referências