RAG ou Web Search? Como decidir entre indexar, buscar ao vivo e combinar os dois

Tem um padrão que aparece em quase todo agente que sai do "demo bonitinho" e vai pra produção: a hora de decidir de onde vem o dado.

Você tem catálogo próprio? Indexa em vector DB e roda RAG. Precisa de preço atual de marketplace? Busca ao vivo. Precisa dos dois pra responder "qual o melhor preço pra esse produto hoje"? Aí o jogo muda — e a maioria dos agentes que vejo na rua erra exatamente nesse ponto.

Esse post é sobre o trade-off. Quando indexar, quando buscar ao vivo, quando combinar — e como modelar isso num caso concreto: um agente de ofertas que cruza catálogo interno com scraping de marketplaces externos.

TL;DR

• O que é: matriz de decisão entre RAG (catálogo indexado) e Web Search (busca ao vivo) para agentes que precisam de informação fresca + contexto proprietário.
• Stack: Claude API (web search nativo), Pinecone/pgvector (RAG), LangChain ou LlamaIndex pro roteamento.
• Custo/Acesso: web search nativo da Anthropic custa $10 por 1.000 buscas + tokens. RAG depende do vector DB.
• Quando importa: todo agente que mistura "dado interno estável" com "dado externo que muda toda hora".

O contexto: RAG e Web Search resolvem problemas diferentes

Antes era simples. Você tinha um corpus, jogava num vector DB, fazia retrieval semântico, mandava pro modelo. RAG resolvia tudo.

Aí os labs liberaram busca na web nativa. A Anthropic lançou o web search tool na API em 2025, e a OpenAI fez o mesmo via Responses API. De repente você tem dois caminhos pro mesmo problema "como dar ao modelo informação que ele não tem no peso".

E os dois caminhos têm trade-offs opostos.

RAG é bom quando:

• O dado é seu (catálogo, base de clientes, documentação interna).
• O corpus é grande, mas razoavelmente estável.
• Você precisa de latência baixa (10–50ms num vector DB bem dimensionado).
• Você quer controle fino sobre o que entra no contexto.

Web Search nativo é bom quando:

• O dado muda toda hora (preço, estoque, notícia, cotação).
• A fonte é pública e indexada.
• Você não quer manter pipeline de ingestão.
• Você aceita pagar por busca e a latência de uma chamada externa.

Confundir os dois é o que faz agente alucinar preço de produto que mudou ontem, ou faz agente queimar $10 a cada 1.000 perguntas que poderiam ter sido respondidas com um lookup de 5ms num índice próprio.

Quando indexar (RAG)

Regra prática: se o dado é seu e raramente muda do dia pra noite, indexa.

Exemplos óbvios:

• Catálogo de produtos da sua loja.
• Base de conhecimento interna (Confluence, Notion, docs de engenharia).
• Histórico de tickets de suporte.
• PDFs de manuais, contratos, políticas.
• Transcrições de calls de venda.

Você ganha três coisas: latência (busca em milissegundos), custo previsível (depois do upfront de embeddings, cada query é barata) e controle. Você decide o chunking, o reranking, o filtro por metadata. A documentação do LangChain sobre RAG já trata isso como o padrão default — e é, pra esse cenário.

Pra catálogo de produto, especificamente, vale puxar o jogo do hybrid search: combina busca densa (embedding semântico) com busca esparsa (BM25 em palavra-chave) e filtro por metadata. A Pinecone documenta o padrão direto e mostra por que isso é praticamente obrigatório em e-commerce: ninguém quer que "tênis preto número 42" devolva um tênis branco número 38 só porque o embedding achou ambos "parecidos".

# Exemplo: query híbrida com filtro de metadata no Pinecone
results = index.query(
    vector=dense_embedding,
    sparse_vector=sparse_embedding,
    top_k=10,
    filter={
        "category": {"$eq": "tenis"},
        "in_stock": {"$eq": True},
        "price": {"$lte": 500}
    },
    include_metadata=True
)

Esse trecho resolve 80% dos casos de busca de produto. RAG bem feito é arquitetura, não prompt.

Quando buscar ao vivo (Web Search)

Regra prática: se o dado é público, muda em horas, e ficar indexando dá mais trabalho do que vale, busca ao vivo.

Exemplos:

• Preço de produto em marketplace concorrente.
• Disponibilidade de voo, hotel, ingresso.
• Cotação de moeda, ação, cripto.
• Notícia do dia, resultado de jogo, lançamento.
• Feed de ofertas de site que você não controla.

A web search da Anthropic, por exemplo, já vem com citações automáticas — toda resposta vem com url, title e cited_text da fonte usada. Isso é importante por dois motivos: rastreabilidade (você consegue auditar de onde o agente tirou a informação) e produto (você pode mostrar o link ao usuário, virar conteúdo verificável).

{
  "type": "web_search_20260209",
  "name": "web_search",
  "max_uses": 5,
  "allowed_domains": ["mercadolivre.com.br", "amazon.com.br", "magazineluiza.com.br"]
}

Detalhe que muita gente perde: o allowed_domains é o que separa "agente útil" de "agente que vai puxar resposta de blog SEO duvidoso". Se você vai usar busca ao vivo num produto, sempre restringe domínio. Sem exceção.

Custo? $10 por 1.000 buscas no Claude, mais os tokens das páginas que entram no contexto. Em escala, isso pesa. Por isso o próximo bloco é o mais importante.

Quando combinar — o caso do agente de ofertas

Agora o caso real. Imagina que você tá construindo um agente de ofertas:

• Você tem um catálogo próprio (10 mil SKUs, atualizado por integração com ERP).
• Você quer comparar com preços de concorrentes em 5 marketplaces externos.
• O usuário pergunta: "qual o melhor preço pra um iPhone 15 Pro 256GB hoje?"

Cair só em RAG não funciona — você não tem o preço do concorrente indexado, e mesmo que tivesse, indexaria ele desatualizado. Cair só em web search também não funciona — você joga fora o que tem de melhor, que é seu catálogo estruturado, com SKU normalizado, estoque, margem.

A solução é arquitetura, não escolha binária. O agente precisa:

1. Identificar o produto no catálogo interno (RAG sobre catálogo, hybrid search com filtro por categoria).
2. Resolver atributos canônicos (modelo, capacidade, cor) a partir do match interno.
3. Disparar web search com query estruturada nos marketplaces permitidos, usando os atributos canônicos.
4. Cruzar e ranquear os resultados — preço externo vs. interno, frete, prazo, confiabilidade da fonte.
5. Responder com citação — preço interno do catálogo + preço externo com link.

Esse é o padrão que o LlamaIndex chama de agentic retrieval: o agente decide qual fonte consultar baseado na pergunta, em vez de você decidir no código de cima.

# Esqueleto: agente com duas ferramentas
tools = [
    {
        "name": "search_internal_catalog",
        "description": "Busca produtos no catálogo interno por nome, SKU ou categoria. Retorna preço próprio, estoque, atributos canônicos.",
        "input_schema": {...}
    },
    {
        "type": "web_search_20260209",
        "name": "web_search",
        "allowed_domains": [
            "mercadolivre.com.br",
            "amazon.com.br",
            "magazineluiza.com.br",
            "casasbahia.com.br",
            "americanas.com.br"
        ],
        "max_uses": 5
    }
]

O modelo decide a ordem. Numa pergunta como "esse produto tem no estoque?", ele só usa o catálogo interno. Em "qual o melhor preço de mercado?", ele usa os dois — primeiro pra resolver canonicidade, depois pra comparar.

Matriz de decisão

Pra fechar a régua mental:

Critério mais simples ainda: busque interno primeiro, externo só quando não tiver resposta. Isso reduz custo, latência e variabilidade. Web search vira fallback ou enriquecimento, não a porta de entrada.

Limitações e pontos de atenção

Três armadilhas que vejo direto:

1. Custo escapa quando você não restringe max_uses. Sem limite, um agente curioso vai pesquisar a mesma coisa de quatro ângulos diferentes. Define max_uses de 3 a 5 por turno. Se o modelo quer mais, é sinal de que sua orquestração tá mal modelada.

2. Latência de web search é incompatível com UX síncrono. Cada busca é segundos, não milissegundos. Pra chat com streaming dá pra esconder, mas pra autocomplete, busca de produto em tempo real, qualquer coisa que precise de feedback instantâneo — RAG, sempre. Web search vai pro pipeline async ou pra perguntas explícitas do usuário.

3. Scraping de marketplace via web search nativo nem sempre funciona. Marketplace sério bloqueia bot. O web search dos labs usa engines tipo Google/Bing por trás, então depende da página estar indexada e renderizada. Pra preço dinâmico, muitas vezes você vai precisar de uma camada própria (API oficial do marketplace quando existe, ou scraper dedicado com rotação de proxy) e expor isso como tool customizada — não a web_search nativa.

CTA

Se você tá construindo agente que precisa misturar dado próprio com dado externo, isso aqui é a parte que separa protótipo de produto. Entra no Clã Beer & Code — é onde a galera tá montando RAG de verdade, agente com múltiplas tools, avaliação, observabilidade. Sem hype, com código que roda.

FAQ rápido

Posso usar só web search e esquecer RAG?

Pode, se o seu produto for 100% sobre dado público e fresco. Mas você vai pagar caro por escala e perder controle sobre relevância. Praticamente todo agente sério mistura os dois.

Qual vector DB usar pra RAG de catálogo?

Pinecone, Qdrant, Weaviate, pgvector — todos resolvem. Pra começar e validar, pgvector dentro do Postgres que você já tem é o caminho mais barato. Vai pra dedicado quando o volume justificar.

Web search da Anthropic ou da OpenAI?

As duas funcionam. Anthropic tem dynamic filtering com web_search_20260209 que filtra resultado antes de gastar token de contexto — útil pra busca técnica densa. OpenAI tem domain filtering parecido. Decida pelo modelo que você já usa, não pela tool.

Como evitar alucinação quando o agente combina as duas fontes?

Força citação obrigatória no prompt do sistema. Se vier do catálogo interno, marca "fonte: catálogo". Se vier de web search, mostra o link. Se o agente não souber de onde tirou, ele tem que dizer "não sei". Sem isso, vira chute com cara de resposta.

Conclusão

RAG e web search não são tecnologias concorrentes. São camadas complementares de um agente bem arquitetado. RAG dá controle, latência e custo previsível pro que é seu. Web search dá frescor e amplitude pro que é do mundo.

A decisão de quando usar cada um é menos sobre o modelo e mais sobre como você modela o problema. Começa pelo dado: de onde ele vem, quanto tempo é válido, quem confia nele. A arquitetura cai como consequência.

O próximo passo é evals: medir quando o roteamento errou, quando o agente foi pra web search sem precisar, quando ficou no RAG e perdeu informação fresca. Mas isso é assunto pra outro post.