Criação de um pipeline RAG com dados da Web em tempo real (sem índices desatualizados)

Um pipeline RAG em tempo real recupera informações da web aberta no momento da consulta, em vez de ler a partir de um índice vetorial pré-rastreado. Isso mantém as respostas atualizadas, pois os dados são obtidos quando o usuário faz a consulta, e não semanas antes, quando o rastreamento foi executado. A contrapartida é direta: a busca em tempo real aumenta a latência e o custo por consulta, enquanto um índice em cache é rápido, mas fica desatualizado. A maioria dos sistemas de produção que observamos se situa no meio-termo híbrido, buscando em tempo real para consultas urgentes e reutilizando blocos em cache sob um TTL de atualização.

Pontos principais

• O RAG clássico consulta um índice estático; portanto, a data máxima de atualização é a data do seu último rastreamento.
• O Live-web RAG identifica fontes por meio de uma API de pesquisa, busca e limpa as páginas no momento da consulta e, em seguida, fundamenta a resposta com citações.
• O difícil não é a recuperação. O difícil é decidir quando buscar os dados em tempo real e quando reutilizar um trecho armazenado em cache, o que é determinado por um TTL de atualização específico para cada tópico.
• Em 2025, a Gartner previu que 40% dos aplicativos corporativos contariam com agentes de IA específicos para tarefas até o final de 2026, um aumento em relação aos menos de 5% atuais, e esses agentes precisam de dados atualizados.
• O Markdown bem estruturado é mais eficaz do que o HTML bruto na etapa de ingestão, pois reduz o custo de tokenização e remove elementos de navegação, anúncios e código padrão antes da segmentação.

O RAG clássico fazia sentido quando o seu corpus era uma base de conhecimento de atualização lenta: documentos, políticas, tickets. No entanto, ao direcioná-lo para a web aberta, o modelo deixa de funcionar. Os preços mudam, surgem notícias, os rankings se alteram, e um índice vetorial criado na última terça-feira retorna com segurança a realidade da última terça-feira. A solução não é um índice maior ou uma programação de rastreamento mais rápida. Em vez disso, consiste em adiar a busca até o momento da consulta para os dados que realmente se alteram. RAG é a geração aumentada por recuperação (RAG): um modelo gera respostas a partir dos documentos que você busca e fornece a ele, e não apenas com base em seus pesos de treinamento. Este artigo apresenta a arquitetura etapa por etapa e, em seguida, aborda a lógica de atualização que distingue o RAG com dados da web em tempo real da versão clássica. Para obter um contexto mais amplo sobre como fornecer dados atualizados aos agentes, comece pelo artigo sobre Como conceder acesso à web em tempo real a agentes de IA.

Por que o RAG clássico perde eficácia quando aplicado a dados da web?

O RAG clássico fica desatualizado porque responde com base em um instantâneo. Você rastreia, segmenta, incorpora e armazena; depois, cada consulta consulta essa cópia congelada até o próximo rastreamento. Para um corpus estável, isso é aceitável. Para a web aberta, no entanto, isso é um problema, e a demanda por agentes de dados atualizados está aumentando. Em 2025, a Gartner projetou que 40% dos aplicativos corporativos contarão com agentes de IA para tarefas específicas até o final de 2026, contra menos de 5% em 2025. Os agentes que respondem a perguntas reais não podem basear-se em dados desatualizados.

O problema da desatualização tem duas vertentes. Primeiro, a cobertura: a web que o senhor indexou no mês passado não contém páginas que ainda não existiam, portanto, nenhuma estratégia de recuperação, por mais inteligente que seja, consegue recuperá-las. Segundo, a desatualização: as páginas que você indexou sofreram alterações sem que você percebesse, e suas representações ainda apontam para o texto antigo. Reindexar em um intervalo mais curto reduz a janela de desatualização, mas nunca a fecha, e, ao mesmo tempo, consome recursos de computação em páginas que ninguém irá consultar.

O RAG em tempo real inverte a ordem. Em vez de pré-buscar tudo e esperar que a página correta esteja no índice, você descobre e busca as fontes no momento da consulta. Como resultado, o custo passa de “rastrear a web inteira continuamente” para “buscar as poucas páginas necessárias para essa consulta”. Para saber mais sobre por que a fundamentação é importante e como ela reduz a alucinação, consulte nosso guia sobre treinamento de LLMs com dados da web em tempo real.

Como é uma arquitetura RAG em tempo real na web?

Um pipeline RAG em tempo real na web passa por sete etapas: compreensão da consulta, descoberta de fontes em tempo real, busca e limpeza, segmentação e incorporação, recuperação dos k principais resultados, fundamentação da geração com citações e, por fim, armazenamento em cache com um TTL de atualização. As seis primeiras etapas produzem a resposta. A sétima etapa decide o que você mantém, para que a próxima consulta semelhante possa pular a busca em tempo real. Cada etapa é concreta e, na prática, a maioria das falhas remonta a uma etapa fraca de descoberta de fontes ou de busca.

Aqui está o fluxo na forma de uma lista de etapas:

1. compreensão da consulta -> reformular a pergunta do usuário em intenção de pesquisa
2. descoberta de fontes -> a API de pesquisa retorna URLs candidatas
3. recuperação + limpeza -> renderizar cada URL em Markdown limpo
4. fragmentação + incorporação -> dividir o Markdown, incorporar fragmentos no momento da consulta
5. recuperação dos k melhores -> classificar fragmentos com base na incorporação da consulta
6. fundamentação + citação -> o LLM responde utilizando apenas os fragmentos recuperados, com links para as fontes
7. cache + TTL -> armazenar fragmentos com um prazo de validade para reutilização

As etapas a seguir descrevem cada passo. Nenhuma delas requer um índice pré-construído de grandes dimensões. O “armazenamento vetorial” aqui é pequeno e de curta duração, frequentemente limitado a uma única consulta ou sessão.

Etapa 1: compreensão da consulta

Transforme a pergunta bruta do usuário em intenção de pesquisa antes de consultar a web. Elimine preenchimentos conversacionais, expanda abreviações e extraia as entidades e a urgência temporal. Por exemplo, “Quais são as últimas notícias sobre a aquisição da X” implica atualidade; uma pergunta de definição, não. Esta etapa determina o grau de prioridade que o restante do pipeline dará aos dados recentes em detrimento dos fragmentos armazenados em cache. De baixo custo de operação, com grande retorno em termos de qualidade.

Etapa 2: descoberta de fontes em tempo real

É na fase de descoberta que a maioria dos pipelines falha discretamente, pois o modelo não consegue basear-se em páginas que nunca encontrou. Descoberta de fontes é a etapa que converte a intenção da consulta em um conjunto de URLs candidatos, normalmente por meio de uma API de pesquisa, em vez de adivinhar domínios. Um endpoint de SERP com segmentação geográfica é importante neste contexto: os resultados para "melhor X perto de mim" ou uma consulta de preço variam de acordo com o país e a cidade, e o objetivo é apresentar as fontes que o usuário realmente veria. Para uma comparação das opções, consulte APIs de pesquisa na web para agentes.

Esta é a primeira etapa em que a API Web Render da Massive entra em ação. O endpoint de pesquisa (/pesquisar) recupera resultados da SERP dos principais motores de busca e permite a segmentação geográfica por país, região ou cidade. Para consultas que dependem do que diz um resumo gerado por IA, em espera=ai espera até um minuto por uma visão geral da IA, e aguardando respostas recupera a seção “Perguntas frequentes”. Você obtém o conjunto de URLs de candidatos, classificados da mesma forma que um usuário real naquela localidade os veria.

Etapa 3: buscar e limpar

É na recuperação das páginas candidatas que o RAG em tempo real se depara com as defesas da web moderna, e a web moderna é hostil aos bots. Em 2025, a Imperva relatou que Os bots automatizados representaram 51% de todo o tráfego da web em 2024, a primeira vez em uma década que os bots ultrapassaram os humanos, com os bots maliciosos representando 37%. Os sites respondem bloqueando de forma agressiva, de modo que as solicitações ingênuas dos data centers são questionadas ou recebem conteúdo falso.

Nesta fase, há dois requisitos. Primeiro, sua solicitação precisa passar pela camada anti-bot da página; caso contrário, você será redirecionado para uma página de erro. Proxies residenciais encaminhar as solicitações por meio de dispositivos reais de consumidores, de modo que o tráfego tenha origem em endereços IP residenciais, em vez de um intervalo de endereços de data center sinalizado. A API Web Render da Massive executa consultas em uma rede real de dispositivos de consumidores que abrange mais de 195 países, com aproximadamente 1,3 milhão de dispositivos ativos diariamente. Em nossos testes, a taxa de sucesso de IPs residenciais em sites protegidos costuma ser significativamente maior do que a de data centers (faixas aproximadas: residencial ~85-99% contra data center ~20-40%); considere isso como uma referência do fornecedor, e não como uma pesquisa independente.

Em segundo lugar, o senhor deseja um texto limpo, e não HTML bruto. O endpoint de navegação (/navegador) oferece suporte a format=markdown como um resultado de primeira classe, retornando um Markdown pronto para LLM, sem elementos de navegação, anúncios e texto padrão. Isso é importante antes da segmentação: o Markdown reduz substancialmente a contagem de tokens em comparação com o HTML bruto, o que diminui o custo de incorporação e geração e mantém seus blocos significativos, em vez de repletos de links de menu. Profissionais da área documentaram o mesmo efeito (dev.to, Ferramentas de navegador para agentes de IA – Parte 4: Ignore o navegador(2026).

Etapa 4: agrupar e integrar

Divida o Markdown limpo em blocos e incorpore-os no momento da consulta. Como o corpus consiste apenas nas poucas páginas que essa consulta extraiu, o processo é rápido e econômico; você está incorporando kilobytes, não um rastreamento da web. Mantenha os trechos alinhados à estrutura do Markdown, por título e parágrafo, para que cada trecho permaneça independente. Os títulos do Markdown oferecem limites naturais que o HTML bruto não oferece.

Etapa 5: recuperar os k melhores

Classifique os fragmentos recém-incorporados em relação à incorporação da consulta e mantenha os k melhores. Com um corpus reduzido por consulta, a recuperação é simples e é possível utilizar um valor k mais alto; em seguida, deixe que o modelo de geração faça a filtragem. O importante aqui é manter apenas os fragmentos que ultrapassem um limiar de relevância, para que uma fonte de baixa qualidade não dilua a janela de contexto.

Etapa 6: fundamentar a argumentação com referências

Forneça ao modelo apenas os trechos recuperados e instrua-o a responder com base neles, incluindo um link de fonte para cada afirmação. Aterramento é a prática de restringir a resposta de um modelo às evidências recuperadas, em vez de à sua memória paramétrica; portanto, este é o contrato de fundamentação: sem fragmento, sem afirmação. Como cada fragmento traz sua URL de origem da Etapa 2, as citações são automáticas, e um leitor (ou uma verificação posterior) pode comparar a resposta com a página ativa. A fundamentação em texto recuperado neste exato momento é o objetivo principal de se estar ao vivo.

Etapa 7: armazenamento em cache com um TTL de validade

Armazene os blocos que você recuperou com um prazo de validade para que a próxima consulta semelhante possa reutilizá-los, em vez de recuperá-los novamente. É isso que torna o RAG em tempo real viável em grande escala. O cache transforma a segunda consulta idêntica de uma recuperação completa em tempo real em uma simples consulta de pesquisa, e o TTL é o que garante a precisão dessa pesquisa. A próxima seção aborda como configurá-lo.

Como evitar índices desatualizados com TTLs de validade?

É possível evitar índices desatualizados atribuindo um TTL de validade a cada bloco armazenado em cache e recuperando os dados novamente assim que ele expirar. A validade TTL é um tempo de validade (TTL) por bloco que indica por quanto tempo uma recuperação em cache permanece confiável antes de precisar ser atualizada. O TTL é específico por tópico, não global: o preço de uma ação pode ser válido por segundos, as especificações de um produto por dias e uma definição de enciclopédia por semanas. Quando uma consulta chega, você verifica primeiro o cache, fornece os blocos que ainda estão dentro de seu TTL e aciona uma busca em tempo real para qualquer item expirado ou ausente. Esse é o meio-termo híbrido: rápido quando possível, atualizado quando necessário.

Defina o TTL já na fase de análise da consulta. Se a Fase 1 tiver sinalizado a pergunta como sensível à atualidade, reduza ou ignore o TTL e force uma busca em tempo real. Se, por outro lado, for uma pergunta de definição estável, um TTL longo é adequado e você pode servir a resposta a partir do cache. Essa é a alavanca que controla sua latência e seu custo: mais recuperações em tempo real significam respostas mais atualizadas e maior custo por consulta; mais acertos no cache significam o contrário.

A invalidação é tão importante quanto a expiração. Um TTL lida com a obsolescência baseada no tempo, mas alguns eventos exigem invalidação imediata: uma página que você citou retorna um erro 404, uma fonte confiável publica uma correção ou uma entidade conhecida por sua volatilidade (um placar ao vivo, uma notícia de última hora) aparece na consulta. Crie um caminho de invalidação explícito para esses casos, em vez de esperar o tempo passar. Em resumo, a combinação de TTL por tópico com a invalidação orientada a eventos é o que diferencia um pipeline de web dinâmica de um índice clássico que simplesmente refaz o rastreamento em um cron.

Mais um motivo pelo qual o conteúdo dinâmico tende a superar um índice estático em 2025: a web aberta está se fechando cada vez mais para os rastreadores em massa. A Cloudflare informou que em Em 1º de julho de 2025, começou a bloquear robôs de IA por padrão em cerca de 20% da web e lançou um mercado de rastreamento pago. Como resultado, a manutenção de um índice pré-construído da web aberta torna-se mais difícil e mais cara a cada trimestre. A recuperação no momento da consulta por meio de uma rede de dispositivos reais contorna o problema do rastreamento em massa, pois você recupera algumas páginas que um usuário real poderia acessar, e não toda a web de acordo com uma programação. Se desejar expor esse pipeline a agentes como uma ferramenta acionável, veja como criar um servidor MCP para extração de dados da web.

Quando é que se deve buscar um bloco em tempo real em vez de reutilizar um bloco armazenado em cache?

Recupere os dados em tempo real quando a consulta for sensível à atualidade ou quando a entrada de cache correspondente tiver ultrapassado seu TTL; reutilize um bloco em cache quando ele ainda estiver atualizado e a consulta for estável. A decisão é tomada por consulta, com base no sinal de sensibilidade ao tempo da Etapa 1 e no TTL restante do bloco. Acertar nessa regra é onde você gasta seu orçamento de latência e custo; portanto, ajuste-a com base no tráfego real, e não em suposições.

Uma abordagem prática por padrão: trate o cache como o caminho mais rápido e a busca em tempo real como a garantia de precisão. Sirva a partir do cache quando houver um bloco dentro do TTL que atinja seu limite de relevância. Recorra à busca em tempo real, no entanto, quando o cache falhar, o bloco tiver expirado, a consulta tiver intenção de atualidade ou a fonte em cache tiver sido invalidada. Isso mantém as consultas comuns e repetidas econômicas, ao mesmo tempo em que garante que as voláteis estejam atualizadas.

Ajuste os limites observando dois tipos de falhas. Respostas desatualizadas (um TTL de cache definido como muito longo para aquele tópico) levam a TTLs mais curtos e a mais consultas em tempo real. Picos de custo e latência (muitas atualizações em tempo real em consultas estáveis) levam à direção oposta. Pelo que observamos nas cargas de trabalho dos agentes, não existe uma configuração única correta; o equilíbrio certo depende da composição do seu tráfego e da rapidez com que suas fontes realmente mudam.

Fontes

• Gartner, A Gartner prevê que 40% dos aplicativos corporativos contarão com agentes de IA para tarefas específicas até 2026, um aumento em relação aos menos de 5% previstos para 2025, 2025. https://www.gartner.com/en/newsroom/press-releases/26/08/2025 – A Gartner prevê que 40% dos aplicativos corporativos contarão com agentes de IA para tarefas específicas até 2026, um aumento em relação aos menos de 5% registrados em 2025
• Imperva, Relatório sobre bots maliciosos de 2025, 2025. https://www.imperva.com/resources/resource-library/reports/2025-bad-bot-report/
• Cloudflare, A Cloudflare acaba de mudar a forma como os rastreadores de IA vasculham a Internet em geral, 2025. https://www.cloudflare.com/press/press-releases/2025/cloudflare-just-changed-how-ai-crawlers-scrape-the-internet-at-large/
• dev.to, Ferramentas de navegador para agentes de IA – Parte 4: Ignore o navegador, 2026. https://dev.to/stevengonsalvez/browser-tools-for-ai-agents-part-4-skip-the-browser-save-80-on-tokens-304c