Provavelmente já teve este momento: o seu agente de codificação acabou de escrever um refactor elegante, gerou um diagrama de arquitetura perfeito, e depois pergunta-lhe "quanto está a cobrar o nosso principal concorrente neste momento?" — e ele ou inventa algo, ou diz-lhe que os seus dados de treino pararam há seis meses.
A culpa não é do modelo. Claude, GPT, Gemini — todos são brilhantes a raciocinar. Nenhum deles consegue ver a web ao vivo por conta própria. Então os programadores acabam por remendar chaves de API do Google, bases de dados vetoriais e chamadas LLM, tentando construir algo que deveria ser um único comando.
O problema tem um nome: a lacuna de pesquisa na infraestrutura de agentes de IA. E a solução não é mais pipelines RAG. É uma abordagem completamente diferente.
O RAG foi construído para documentos internos, não para a internet
Retrieval-Augmented Generation funciona maravilhosamente quando os seus dados residem numa base de dados vetorial e mudam uma vez por trimestre. Manuais de colaboradores. Especificações de produtos. Dados históricos. Indexe, consulte, está feito.
O problema começa quando precisa de algo que não está no seu índice.
Um concorrente lança um novo escalão de preços. Uma regulamentação muda. Uma biblioteca da qual depende tem um bug crítico que toda a gente no Hacker News está a comentar. O seu pipeline RAG não sabe nada disto. Não pode saber — só vê o que lhe deu da última vez que reconstruiu o índice.
Já vi equipas tentarem corrigir isto com calendários de reconstrução mais rápidos. Depois com pesquisa híbrida. Depois com pipelines separados para dados internos e externos. Cada camada torna o sistema mais capaz — e mais frágil. Cada nova fonte de dados é mais uma integração. Cada integração é mais uma coisa que se avaria às 2 da manhã.
A verdadeira questão não é que o RAG seja mau. É que o RAG foi projetado para responder "o que diz a nossa política sobre X" — não "o que está a acontecer no mundo neste momento".
O que a pesquisa grounded realmente faz
A pesquisa grounded obtém informações ao vivo da web no momento em que pergunta. Não de um índice. Não de um snapshot. Do que está publicamente disponível agora, com um URL de fonte associado a cada afirmação.
É mais próximo de como investigaria algo: pesquisar, analisar algumas fontes, sintetizar uma resposta e citar de onde veio cada parte. A diferença é que o seu agente fá-lo em segundos em vez de minutos.
Uma comparação rápida para tornar a diferença concreta:
| Aspeto | RAG Tradicional | Grounded Search |
|---|---|---|
| Origem dos dados | Os seus documentos indexados | A web ao vivo, agora mesmo |
| O que conhece | O que indexou | O que é publicamente acessível |
| Quando fica desatualizado | Assim que a fonte muda | Não fica — obtém fresco de cada vez |
| Configuração | Pipeline de indexação, BD vetorial, chunking | Um comando CLI |
O RAG ainda vence para dados privados — registos de clientes, finanças internas, qualquer coisa que não deva tocar na internet pública. A arquitetura prática a que a maioria das equipas chega: RAG para conhecimento interno, pesquisa grounded para contexto externo. O agente escolhe com base no que lhe está a ser perguntado.
Como um agente realmente usa isto
A CLI é deliberadamente simples porque os agentes não importam bibliotecas — executam comandos.
anycap search "Acme Corp precário enterprise Q2 2026" \
--citations \
--output precos-acme.json
O agente recebe uma resposta estruturada com citações. Pode passar a resposta ao utilizador, alimentá-la no passo seguinte de um fluxo de trabalho ou armazená-la para mais tarde. Sem complicações com chaves de API. Sem SDK Python para encapsular. Apenas uma ferramenta que o agente pode invocar da mesma forma que invoca ls ou git diff.
O que torna isto poderoso não é a pesquisa por si só. É que a pesquisa se torna uma ferramenta entre muitas que o agente pode encadear. Pesquisar preços de concorrentes. Investigação aprofundada sobre o panorama de mercado. Gerar um visual comparativo. Compilar tudo num relatório. Publicá-lo.
Uma CLI. Uma autenticação. O agente move-se entre capacidades sem código de integração personalizado para cada etapa.
Já vi este padrão funcionar particularmente bem para monitorização competitiva. Um agente verifica preços de concorrentes semanalmente, compara com a semana anterior, assinala alterações e envia um resumo no Slack. Um cron job, zero middleware.
O que realmente importa ao escolher uma ferramenta de pesquisa
Esqueça as matrizes de funcionalidades por um instante. Eis o que eu realmente testaria se estivesse a avaliar ferramentas de pesquisa grounded:
Cita corretamente? Teste 20 consultas em que sabe a resposta certa. Para cada uma, clique nas citações e verifique se realmente apoiam o que a ferramenta alegou. Uma ferramenta que devolve respostas corretas com citações erradas é mais perigosa do que uma que admite não saber. Já perdi meio dia a perseguir um "facto" de uma ferramenta de pesquisa que citava uma fonte que dizia o oposto.
Qual é a velocidade real? Não a latência de marketing. A latência P99 quando 50 agentes estão a aceder simultaneamente. Um pipeline de agente que espera 8 segundos por cada etapa de pesquisa vai frustrar todos os envolvidos.
Lida bem com casos extremos? Pergunte algo obscuro. Algo recente. Algo onde as fontes discordam. Uma boa ferramenta expõe o conflito em vez de fazer a média da discordância transformando-a em disparate.
É CLI ou SDK? Isto importa mais do que parece. Os agentes não fazem from x import y. Invocam comandos. Uma ferramenta atrás de uma biblioteca Python é uma ferramenta que o seu agente não pode usar sem que escreva um wrapper primeiro.
Por que isto importa mais do que parece
A lacuna de pesquisa não é um inconveniente menor. É o maior fator isolado que impede os agentes de lidarem com fluxos de trabalho reais de investigação. Um agente que raciocina mas não pesquisa é como um programador com o Stack Overflow bloqueado — capaz, mas desligado da informação de que realmente precisa.
A solução não é complicada. Só não é o que a maioria das equipas procura primeiro, porque o RAG é familiar e a lacuna de pesquisa só se torna óbvia quando o seu agente entrega confiantemente informação errada a alguém que confiou nele.
Se os seus agentes estão a bater nessa parede — a funcionar perfeitamente com dados internos, mas a desmoronar-se no momento em que precisam de algo externo — provavelmente não é o seu modelo. Provavelmente não são os seus prompts. É que a arquitetura de pesquisa foi construída para um problema diferente.
Leitura adicional:
- Melhores Ferramentas de Deep Research para Agentes de IA em 2026 — Quando a pesquisa única não é suficiente
- Google AI Search para Programadores — O que as mudanças na pesquisa com IA do Google significam para construtores de agentes
- Melhores Ferramentas de IA para Pesquisa Empresarial — Grounded search comparado com Glean, Perplexity e Copilot
- Fluxos de Trabalho Agentivos: Guia Completo — Construir pipelines que encadeiam pesquisa, geração e ação