Busca agentic vira o novo benchmark de raciocínio

Na quarta, a pauta correta não é “mais um chatbot”. É a camada abaixo: como um modelo decide buscar, ler, verificar e parar.

O radar das últimas 24–72 horas veio com dois sinais fortes no arXiv: OpenSeeker-v2: Pushing the Limits of Search Agents with Informative and High-Difficulty Trajectories e Rethinking Reasoning-Intensive Retrieval: Evaluating and Advancing Retrievers in Agentic Search Systems. Hacker News veio vazio no recorte recebido; isso tira o termômetro social da equação e deixa a análise mais dependente de paper, método e fonte primária.

O ponto técnico é simples e incômodo: medir retrieval como ranking de documentos ficou pequeno demais para sistemas que pesquisam em múltiplos passos.

O que saiu

Dois papers recentes atacam a mesma falha de avaliação por ângulos complementares.

O primeiro, OpenSeeker-v2, coloca ênfase em trajetórias informativas e difíceis para agentes de busca. A palavra importante aqui é trajetória. Não basta perguntar se o documento certo aparece no top-k. O sistema precisa decompor a questão, gerar consultas intermediárias, escolher fontes, extrair evidência, revisar hipótese e produzir resposta.

O segundo, Rethinking Reasoning-Intensive Retrieval, mira o mesmo problema por dentro do retriever. Em tarefas que exigem raciocínio, a recuperação não é uma etapa isolada; ela altera o caminho de inferência. Um documento recuperado cedo demais, tarde demais ou com contexto incompleto pode empurrar o sistema para uma resposta errada mesmo quando a evidência existe no corpus.

No lado de produto, a OpenAI publicou material oficial do GPT-5.5 Instant System Card, enquanto o Google destacou webhooks na Gemini API para jobs longos e orientados a eventos. São sinais diferentes da mesma transição: modelos deixaram de ser chamadas síncronas isoladas e passaram a operar dentro de fluxos persistentes, com ferramentas, estado e ações.

Esse é o deslocamento real: de modelo responde para sistema executa uma investigação curta.

Por dentro

Um benchmark clássico de retrieval normalmente pergunta:

1. dada uma query;
2. recupere documentos;
3. compare com documentos anotados como relevantes;
4. calcule métrica como recall, precision, MRR ou nDCG.

Isso funciona para busca lexical, busca vetorial e muitos casos de RAG simples. Mas falha em perguntas que precisam de encadeamento.

Exemplo: “qual laboratório publicou o método X, qual dataset ele usou, e como o resultado se compara ao modelo Y?”. A pergunta contém pelo menos três subproblemas. Um agente razoável pode precisar buscar o paper original, abrir uma tabela, identificar métrica, depois buscar o modelo Y e normalizar a comparação. Se o benchmark só mede se o primeiro paper apareceu no top-10, ele perdeu o fenômeno.

Em busca agentic, a unidade natural vira:

estado inicial
→ consulta 1
→ documentos candidatos
→ leitura seletiva
→ hipótese parcial
→ consulta 2
→ nova evidência
→ verificação
→ resposta final com citação

O erro também muda de forma. Há pelo menos cinco classes:

• erro de decomposição: o sistema quebra a pergunta de modo errado;
• erro de consulta: o sistema formula termos ruins para o mecanismo de busca;
• erro de recuperação: o retriever não traz evidência suficiente;
• erro de leitura: o modelo ignora ou distorce o trecho relevante;
• erro de parada: o sistema responde cedo demais ou continua buscando sem necessidade.

A maioria dos benchmarks antigos comprime tudo isso em uma nota final. Isso é confortável para leaderboard e ruim para engenharia.

O avanço metodológico de papers nessa linha é forçar a avaliação da trajetória. Se duas respostas finais estão corretas, mas uma chegou por evidência limpa e outra por sorte estatística, elas não devem receber o mesmo crédito. Se duas respostas finais estão erradas, mas uma falhou na recuperação e outra falhou na síntese, o diagnóstico também precisa separar os casos.

Essa distinção parece acadêmica até você tentar operar um agente em produção. Sem telemetria por etapa, o time fica cego: troca o modelo quando deveria trocar o retriever; aumenta contexto quando deveria melhorar query rewriting; adiciona ferramentas quando deveria remover caminhos ruins.

O que muda

A primeira mudança é que dados de trajetória passam a valer mais.

No treinamento supervisionado tradicional, pares pergunta-resposta já ajudam. Em agentes, pares pergunta-resposta são subespecificados. O exemplo útil mostra as ações intermediárias: qual consulta foi feita, qual documento foi aberto, qual trecho sustentou a conclusão e quando o sistema decidiu parar.

Isso favorece laboratórios que conseguem gerar, filtrar e auditar trajetórias em escala. Aqui a disputa US x China fica interessante.

Nos Estados Unidos, OpenAI, Anthropic e Google DeepMind têm produto, tráfego, integração com navegador, nuvem e feedback de uso. Esse é um ativo enorme para aprender onde agentes falham. Mas o produto também impõe latência, custo e superfície de erro pública.

Na China, grupos como DeepSeek, Alibaba/Qwen, Moonshot e Zhipu têm mostrado agressividade em eficiência, abertura de pesos e engenharia de dados. Com restrição de chip avançado, a pressão empurra para MoE, quantização, destilação e dados sintéticos mais fortes. Em busca agentic, essa restrição pode virar incentivo correto: menos força bruta, mais trajetória bem curada.

A segunda mudança é que benchmark final sem log intermediário perde valor.

Um resultado agregado pode esconder sistemas perigosamente diferentes. Um agente que acerta 70% com 3 buscas verificáveis é muito diferente de um agente que acerta 70% com 15 buscas ruidosas e citações frágeis. O primeiro custa menos, depura melhor e escala melhor. O segundo parece bom no placar e ruim na infraestrutura.

A terceira mudança é que latência vira parte do raciocínio.

O anúncio do Google sobre webhooks na Gemini API aponta para uma arquitetura prática: jobs longos, callbacks, eventos. Isso combina com agentes que precisam fazer várias chamadas, esperar ferramenta externa e retomar estado. Não é glamour de modelo; é encanamento. Mas agente útil depende de encanamento.

A OpenAI, com system card para GPT-5.5 Instant, joga outro lado: variantes rápidas e personalizadas precisam manter qualidade sob orçamento de tempo mais apertado. “Instant” só presta se o sistema souber quando não deve ser instantâneo. Para perguntas simples, resposta direta. Para pergunta com evidência externa, busca e verificação. O roteador passa a ser tão importante quanto o decodificador.

Brasil nisso

O Brasil não aparece como ator central nesses papers nem nos anúncios oficiais do radar. Esse é o fato.

Mas o tema importa diretamente para o mercado brasileiro por uma razão menos elegante: muito produto nacional vendido como assistente corporativo ainda é RAG raso com interface de chat. PDF entra, embedding sai, top-k volta, modelo resume. Isso resolve FAQ interna e quebra quando a pergunta exige comparação, temporalidade, exceção contratual ou múltiplas fontes.

Bancos, escritórios, seguradoras, varejo e setor público têm exatamente esse tipo de pergunta. “Qual cláusula vale para este caso?” raramente está em um parágrafo único. “Por que este pedido foi negado?” exige log, regra, documento, data e exceção. “Qual fornecedor descumpriu SLA?” exige agregação e evidência.

A oportunidade brasileira não está em treinar um frontier model do zero. Está em construir avaliação séria para agentes em português, com corpora de domínio, logs auditáveis e métricas por etapa. Quem fizer isso direito vende menos slide e mais sistema que aguenta auditoria técnica.

Também há uma vantagem local: português jurídico, financeiro e regulatório tem baixa cobertura nos benchmarks globais. Um agente que funciona em inglês aberto na web pode falhar feio em contrato brasileiro, ata, edital, acórdão e norma interna. Esse buraco é produto.

Leitura crítica

Minha posição: busca agentic é o benchmark certo para 2026, mas a área ainda está suja de placar bonito e diagnóstico fraco.

O erro dos últimos dois anos foi tratar RAG como remendo universal. Colocou-se um retriever na frente do modelo e vendeu-se aquilo como memória, ferramenta, raciocínio e governança ao mesmo tempo. Tecnicamente, era só uma aproximação útil. Agora a conta chegou.

Papers como OpenSeeker-v2 e trabalhos sobre retrieval intensivo em raciocínio movem a discussão para o lugar certo: trajetórias, dificuldade, evidência e falha por etapa. Isso é melhor do que mais uma tabela de MMLU com décimo de ponto.

A crítica também vale para laboratórios grandes. System cards e releases de produto ajudam, mas não substituem logs reproduzíveis de avaliação. Se um modelo “instantâneo” responde melhor, quero saber em quais classes de pergunta ele buscou, quando recusou buscar, quantas ferramentas chamou, qual foi a taxa de citação quebrada e qual erro dominou. Sem isso, o release informa pouco para engenharia.

O eixo US x China aqui não será decidido apenas por parâmetro e GPU. Será decidido por quem construir o melhor ciclo:

tarefa difícil
→ trajetória observada
→ erro localizado
→ dado novo
→ treino ou ajuste
→ avaliação reproduzível

Esse ciclo é menos fotogênico do que lançar um modelo com nome novo. Também é onde sistemas úteis nascem.

Andrej Karpathy assina a Fronteira Tech às quartas. Pesquisador de inteligência artificial, ex-OpenAI e ex-Tesla AI, escreve sobre modelos, dados, chips e avaliação com foco em mecanismos reproduzíveis.