Busca web no agente: onde profundidade e motor importam mais que o modelo

A discussão sobre busca web em agentes está presa na pergunta errada. Todo mundo pergunta qual modelo de linguagem usar. A pergunta que decide o resultado é outra: quantas fontes aquele agente vai tocar, e com qual motor. No benchmark de 2026-08-12, que comparou os motores Exa, Parallel e Perplexity na tarefa de buscar para um agente, o resultado mudou menos quando o modelo de raciocínio trocou do que quando o orçamento de exploração mudou. O modelo é a última camada que decide. A profundidade e o motor decidem antes, e já decidiram tudo.

Por que o resultado de um agente que busca na web sofre mais com o orçamento que com o modelo?

Porque o LLM só interpreta o contexto que chegou até ele, e é o orçamento de busca que decide qual contexto chega, o que coloca a coleta à frente do raciocínio na cadeia de valor do resultado. Um modelo brilhante sobre um conjunto de fontes curto e mal escolhido produz uma resposta confiante e errada. Um modelo mediano sobre um conjunto amplo e bem curado produz uma resposta modesta e certa, que é o que paga a conta em produção. O gargalo não está na camada de raciocínio, está na camada de coleta.

Um agente que consulta a web faz três escolhas antes de o modelo escrever uma frase. Ele escolhe o motor, a profundidade e o tamanho do contexto que vai levar para o raciocínio. Nenhuma das três é feita pelo modelo. São feitas pela configuração da ferramenta, pelo rollout de function calling e pelo teto de tokens que a aplicação impõe.

Isso não deveria surpreender ninguém que já viu um agente alucinar com confiança sobre um fato que uma segunda fonte desmentiria em dez segundos. A segunda fonte simplesmente não existia na busca feita com profundidade mínima.

O custo também veste essa leitura. Cada query adicional custa em tokens de busca, em latência e, quando o motor é pago, em dinheiro por chamada. Orçamento de busca é, no fim do mês, uma linha contábil. A ferramenta que gasta mais no loop do agente é a busca web, e é a ferramenta que quase ninguém governa.

O que o benchmark de motores de busca para agentes realmente mostrou?

Ele comparou três motores, Exa, Parallel e Perplexity, na tarefa de alimentar um agente com contexto para responder a uma pergunta, e, mantido o mesmo raciocínio, trocar de motor deslocou o score em torno de 10 pontos, enquanto a distância entre um modelo de raciocínio de ponta e um eficiente em custo chegou a cerca de 15 pontos. O motor importa, mas importa menos que o modelo. E os dois juntos movem menos do que a profundidade do orçamento de busca. Cada motor tem um jeito próprio de cortar a web, de ordenar a relevância e de devolver contexto, e esse jeito é que decide a matéria-prima do agente.

A forma como o teste foi desenhado importa. Não foi um teste de "quem achou o link certo". Foi um teste de "quem devolveu o contexto que o agente precisava". Um motor pode achar uma fonte perfeita e devolvê-la enterrada num pacote ruidoso; outro pode achar uma fonte regular e devolvê-la limpa. Para o agente, a segunda é mais útil, porque o que chega ao raciocínio é um texto truncado, não um ranking de links para clicar.

Observação de leitura obrigatória antes de levar os números a sério: os resultados são reportados pelo fornecedor que rodou o teste, não verificados de forma independente. Então o que vale extrair não é o vencedor absoluto, é a direção. E a direção reconciliada do benchmark com o título do próprio fornecedor, "enquanto o motor importa, o modelo importa mais", aponta para um fio único: trocar só o motor, mantido o modelo, é mexer em menos do que trocar o modelo, e trocar o modelo puro, sem tocar no orçamento de busca, é deixar o maior ganho na mesa. A qualidade do resultado nasce da combinação, não da escolha de um único componente.

É aqui que a conversa técnica vira conversa de arquitetura. Se o motor e a profundidade dominam, então a empresa não deveria travar um motor único em código. Ela deveria ter a capacidade de trocar de motor por chamada, por custo, por confiabilidade e por exigência de profundidade da consulta em questão. Isso é roteamento. Só que o roteamento, nesse caso, não cobre o modelo, cobre a ferramenta.

Por que o orçamento de busca pesa mais que a escolha do modelo de linguagem?

Porque todo o valor de um modelo de raciocínio é desperdiçado quando o contexto que ele recebe é raso, ruidoso ou tendencioso. Um LLM excelente não resolve a ausência de informação. Ele escreve uma frase boa demais sobre informação pobre demais, e esse é o pior resultado possível de produção, porque é indetectável no fluxo.

Pense no que a profundidade faz em três níveis. No nível um, o agente consulta uma única página e responde; no nível dois, ele abre os links de referência daquela página. É ali, no nível dois, que já nasce matéria nova. No nível três, ele segue encadeamentos entre domínios confiáveis e cruza versões. Cada nível custa mais em latência e em tokens de busca, mas cada nível remove uma classe de erro que os níveis anteriores não conseguem nem nomear.

A latência é o adversário silencioso. Uma busca com profundidade alta pode levar dezenas de segundos, e o usuário de um agente B2B não tem meia hora de paciência para uma query de rotina. Então a decisão não é "buscar mais", é "buscar mais quando a pergunta merece". Uma pergunta de faturamento merece profundidade alta. Uma pergunta de preenchimento de formulário não. Decidir quando escalar a profundidade é uma política, e políticas são exatamente o que um gateway de IA sabe aplicar.

O custo por query fecha o argumento. Cada nível de profundidade multiplica chamadas ao motor e tokens de contexto. Numa operação com milhares de queries por dia, a diferença entre profundidade mínima e alta é a diferença entre uma conta pequena e uma conta que exige assinatura de dois níveis, a mesma dinâmica de composição de custo do custo operacional do gateway em produção. Sem teto de gasto na busca, o orçamento de busca é infinito até o dia em que chega a fatura.

Como a busca web se comporta como ferramenta dentro do loop do agente?

Ela se comporta como qualquer outra ferramenta exposta por function calling ou por um protocolo de conexão, um ponto de entrada que o agente decide chamar no meio do seu raciocínio. Para o gateway, a busca web não é ontologicamente diferente de uma chamada de API de cálculo, de banco de dados ou de qualquer conector. É uma ferramenta com uma assinatura, um custo e um perfil de comportamento.

E esse é o detalhe que quase todo mundo perde. Quando a busca web está dentro do loop, ela é chamada sob demanda, às vezes dezenas de vezes numa única resposta. Cada chamada é uma decisão de roteamento esperando para acontecer: qual motor serve esta consulta, com que profundidade, dentro de qual teto de gasto. Hoje essa decisão é tomada por default, no código do agente, travada na hora em que alguém escolheu o motor e nunca mais olhou.

O protocolo de conexão fez esse desenho ainda mais maduro. Um agente conectado por um padrão de troca de mensagens entre sistemas, o mesmo que aproxima MCP e ferramentas no loop de um agente, expõe ferramentas de forma estruturada, com descrição, parâmetros e limites legíveis por máquina, o modelo que o protocolo MCP generaliza para qualquer sistema. Isso significa que a camada que intercepta as chamadas do agente consegue ver cada ferramenta, cada parâmetro e cada custo previsto antes de deixar a chamada passar. A visibilidade existe. O que falta é aplicar política a essa visibilidade.

É aqui que o gateway deixa de ser um roteador de modelo e passa a ser a camada que governa a chamada inteira do agente. A régua não muda por que o alvo agora é uma ferramenta. Muda apenas o objeto.

Como a política de roteamento se estende do modelo para a ferramenta de busca?

A mesma política que o gateway aplica ao LLM, rotear por custo, por confiabilidade, por latência e por profundidade, é aplicável à ferramenta de busca, com os mesmos critérios e com a mesma matemática de fallback. O gateway registra o desempate por custo por query, o failover automático quando um motor degrada e o teto de gasto por chave, por projeto ou por agente, exatamente como faz por token. A extensão não pede um produto novo. Pede aplicar a política existente a um novo alvo, do mesmo jeito que a avaliação de endpoint funciona como política de roteamento do modelo.

Considere o roteamento por custo. Motores de busca para agentes cobram por query em escalas que podem diferir em múltiplas vezes. Para uma consulta de baixo valor, o roteador escolhe o motor barato. Para uma consulta que assina um contrato, o roteador escolhe o motor caro, porque o custo da resposta errada é maior do que o custo da query certa. Isso é a mesma lógica de "qual modelo para qual request", só que no nível da ferramenta.

O roteamento por confiabilidade segue o mesmo desenho. Um motor fica estável durante três dias e degrada numa quarta-feira. Com failover de ferramenta, o tráfego da busca migra em milissegundos para um motor reserva, e o usuário final não vê nada além de uma resposta que chegou no prazo. Sem failover, o agente devolve um erro de motor que parece um erro de produto.

O roteamento por profundidade é o mais novo e o mais negligenciado. Ele desempata o conflito entre qualidade e latência: pergunta simples, profundidade mínima; pergunta de consequência, profundidade alta. Para isso o gateway precisa ler a intenção da chamada, o que já faz na camada de classificação de intenção que usa na escolha de modelo. A ferramenta herda a classificação que o modelo já tinha, e é esse conjunto de critérios que deve estar na mesa de quem ainda está avaliando como escolher um gateway.

O que muda na prática ao rotear só o LLM em vez de rotear o modelo e a ferramenta?

Muda o que o gateway enxerga, o que ele governa e o que ele pode auditar em cada chamada do agente. Roteando só o LLM, a empresa domina o custo por token e o failover do raciocínio, mas deixa a busca, que é a parte mais cara do loop, funcionando num único motor, com profundidade fixa e sem teto. É governar a menor conta e ignorar a maior. A maior decide o risco.

A coluna da direita é a que o Nexforce Router aplica. O Router governa o custo e a confiabilidade de cada chamada do agente, incluindo a ferramenta de busca, com teto de gasto por chave, por projeto ou por agente e com failover que migra o tráfego em milissegundos. Ele não escolhe o motor por você. Ele aplica a mesma política de roteamento que já aplica ao LLM.

O argumento prático se encerra numa frase: quem roteia só o modelo está resolvendo o problema de 20% do custo e 20% do risco, enquanto a fatura barulhenta e o ponto único de falha do loop estão na busca. A extensão da política à ferramenta é a diferença entre governar a chamada e governar só a aparência dela.

Como começar a aplicar roteamento de ferramenta na busca web do agente?

Começar não exige reescrever o agente. Exige trocar um ponto de integração e inspecionar a ferramenta. O caminho é incremental e cabe numa sprint.

1. Listar as ferramentas que o agente chama hoje e medir o custo de cada uma, começando pela busca web, que costuma ser a mais cara.
2. Unificar a entrada das chamadas num único gateway, que passa a ver o modelo e cada ferramenta chamada dentro do loop.
3. Definir a política de profundidade por tipo de pergunta, separando a consulta de rotina da consulta de consequência.
4. Configurar o failover de motor para o caso de degradação, com um motor reserva para absorver a troca em milissegundos.
5. Fixar um teto de gasto por chave ou por projeto que cubra a busca, e não só o modelo.
6. Auditar as chamadas reais por uma semana e ajustar a classificação de intenção que decide a profundidade.

O passo seis é o que separa um desenho de uma política que funciona. A qualidade do roteamento de ferramenta vem de observar o que o agente realmente chama, em que custo, com que falhas, e ajustar a régua. Sem a telemetria das chamadas, o mesmo tipo de rastreabilidade que sustenta a observabilidade de LLM, o roteamento é uma aposta com bons argumentos e nenhuma evidência.

E há um ganho que não aparece na tabela. Quando a política cobre a ferramenta, a mesma decisão de roteamento que economiza na busca barata e investe na busca cara vira a base de uma auditoria completa de cada chamada. Cada chamada é rastreável, cada critério de escolha é explicável e cada failover deixa um rastro. Para um comprador B2B que precisa explicar o que o agente fez, isso vale mais do que qualquer ponto de percentual de qualidade.

Perguntas frequentes sobre busca web e roteamento em agentes

O modelo de linguagem não é o que decide a qualidade da resposta do agente?

O modelo interpreta o contexto, mas o orçamento de busca decide qual contexto chega até ele. Um modelo bom sobre fontes rasas e mal escolhidas produz uma resposta confiante e errada. Trocar o modelo sem tocar na profundidade é deixar o ganho maior na mesa: o motor isolado move o resultado menos do que o modelo, e a profundidade do orçamento move mais do que os dois.

O que é o orçamento de busca de um agente?

É o conjunto de escolhas de como o agente coleta informação: qual motor de busca usa, quantas páginas e níveis de link percorre e quanto contexto leva para o raciocínio. Cada nível custa latência, tokens e, em motores pagos, dinheiro por query.

A busca web dentro do agente é uma ferramenta roteável como o LLM?

Sim. Dentro do loop, a busca é uma ferramenta exposta por function calling ou por um protocolo de conexão, com assinatura e custo. O gateway aplica a ela a mesma política de roteamento que aplica ao modelo: custo, confiabilidade, failover e teto de gasto.

Por que o Nexforce Router governa a busca web se ele é um roteador de LLM?

O Router governa o custo e a confiabilidade de cada chamada do agente, incluindo as ferramentas que ele chama dentro do loop, e a busca web é a mais cara delas. Ele estende a mesma política de roteamento do LLM à ferramenta, sem virar produto de agentes.

Preciso reescrever o agente para rotear a ferramenta de busca?

Não. O caminho une a entrada das chamadas no gateway, define a profundidade por tipo de pergunta, configura failover de motor e fixa um teto que cubra a busca. A troca é incremental e cabe numa sprint.

Referências e Leitura Complementar

O ponto sobre ampliar a política de roteamento para as ferramentas do agente, tratando a avaliação da chamada como decisão de política, conversa diretamente com a avaliação de endpoint como política de roteamento. Para quem está na fase de compra, o guia de como avaliar e escolher um gateway de IA é a leitura de suporte. A base de custo sobre a qual essa conta se sustenta está no levantamento sobre o custo operacional do gateway em produção. Para entender como as ferramentas de um agente entram no loop por um padrão de mensagens entre sistemas, o texto sobre MCP e ferramentas segue o encadeamento. E a telemetria que faz o passo seis funcionar, rastrear cada chamada, é o coração do guia de observabilidade de LLM. Cada um segue um fio do argumento.

Um modelo bom não conserta um contexto ruim

Existe uma hierarquia batida de otimização que quase toda equipe de IA descobre na marra. Trocar de modelo é fácil, escrever uma prompt melhor é fácil, e medir quanto de informação a busca deixou na mesa é o que ninguém faz. O mesmo time que passa seis semanas avaliando fornecedores de modelo deixa o motor da busca web travado numa linha de código que ninguém revisita, e é justamente ali que mora o pior custo e o pior risco do loop do agente.

Roteamento de busca não é um capricho de engenharia. É a mesma disciplina que o time já aplica ao LLM, custo, confiabilidade, failover, teto, só que aplicada à ferramenta que o loop mais usa e mais gasta. A empresa que entende isso não precisa escolher entre um motor caro e um barato, nem entre profundidade alta e baixa. Precisa de uma política que escolha por ela, por chamada, olhando a intenção, o custo e a consequência de cada pergunta.

O Nexforce Router existe para isso: governar o custo e a confiabilidade de cada chamada do agente, incluindo a ferramenta de busca, com a mesma política que já governa o modelo. Quem roteia só o modelo resolve metade do problema. Quem estende a política à ferramenta passa a governar a chamada inteira, da intenção à última fonte tocada. O próximo passo é trocar o ponto de integração e começar a medir. Os dados vão fazer o resto.