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 adota uma abordagem híbrida, realizando buscas em tempo real para consultas urgentes e reutilizando blocos armazenados em cache dentro de um prazo de validade (TTL) para garantir a atualidade.

Pontos principais

• O RAG clássico fornece respostas a partir de um índice estático; portanto, seu limite máximo de atualização é a data do seu último rastreamento.
• O Live-web RAG identifica fontes por meio da Web Search API, busca e limpa as páginas no momento da consulta e, em seguida, fundamenta a resposta com citações.
• A parte difícil não é a recuperação. Trata-se de decidir quando buscar dados em tempo real e quando reutilizar um trecho armazenado em cache, o que é regido por um TTL de atualização específico para cada tópico.
• Em 2025, a Gartner projetou que 40% dos aplicativos corporativos contariam com agentes de IA específicos para determinadas 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 é superior ao 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 divisão em blocos.

O RAG clássico fazia sentido quando 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 de última hora, os rankings se alteram, e um índice vetorial criado na última terça-feira retorna, com toda a certeza, a realidade da última terça-feira. A solução não é um índice maior nem uma programação de rastreamento mais rápida. Em vez disso, consiste em adiar a obtenção dos dados que realmente se alteram para o momento da consulta. RAG trata-se da geração aumentada por recuperação (RAG): um modelo gera respostas a partir de documentos que o usuário busca e fornece a ele, e não apenas com base em seus pesos de treinamento. Esta publicação apresenta a arquitetura etapa por etapa e, em seguida, aborda a lógica de atualização que diferencia 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 a eficácia quando aplicado a dados da web?

O RAG clássico fica desatualizado porque responde com base em um instantâneo. Você realiza o rastreamento, divide em blocos, 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 específicos para determinadas tarefas até o final de 2026, em comparação com 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. Em segundo lugar, a desatualização: as páginas que o senhor indexou sofreram alterações sem que o senhor percebesse, e suas representações ainda apontam para o texto antigo. Realizar um novo rastreamento em um intervalo mais curto reduz a janela de desatualização, mas nunca a elimina por completo; além disso, gasta recursos computacionais em páginas que ninguém irá consultar.

O RAG na web 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 a importância do grounding e como ele reduz as alucinações, 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, obtenção e limpeza, segmentação e incorporação, recuperação dos k melhores 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 determina o que será mantido, de modo que a próxima consulta semelhante possa pular a etapa de busca em tempo real. Cada etapa é concreta e, na prática, a maioria das falhas remonta a uma etapa deficiente de descoberta de fontes ou de busca.

A seguir, apresentamos o fluxo na forma de uma lista de etapas:

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

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

Etapa 1: compreensão da consulta

Transforme a pergunta bruta do usuário em intenção de busca antes de acessar a web. Elimine expressões de preenchimento da conversa, 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, por outro lado, não. Essa etapa determina o grau de prioridade que o restante do fluxo de trabalho 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 se basear 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 busca, 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 senhor deseja apresentar as fontes que o usuário realmente veria. Para uma comparação das opções, consulte Web Search API para agentes.

Esta é a primeira etapa em que o Web Render API da Massive entra em ação. O endpoint de pesquisa (/search) recupera resultados da SERP dos principais mecanismos de busca e permite a segmentação geográfica por país, subdivisão ou cidade. Para consultas que se baseiam no que um resumo de IA apresenta, awaiting=ai aguarda até um minuto por uma visão geral da IA, e awaiting=answers consulta a seção “As pessoas também perguntam”. Você obtém o conjunto de URLs de candidatos, classificados da mesma forma que um usuário real naquela localidade os veria.

Etapa 3: coleta e limpeza

A recuperação das páginas candidatas é o ponto em 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 informou 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 com bloqueios agressivos, de modo que as solicitações ingênuas provenientes de centros de dados são questionadas ou recebem conteúdo falso.

Há dois requisitos nesta etapa. 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. O Web Render API da Massive realiza consultas por meio de uma rede de dispositivos reais 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 com IPs residenciais em sites protegidos costuma ser significativamente maior do que com IPs de data center (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 (/browser) oferece suporte a format=markdown como uma saída de primeira classe, retornando um Markdown pronto para LLM, sem navegação, anúncios e texto padrão. Isso é importante antes da divisão em blocos: 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 extraídas por essa consulta, esse processo é rápido e econômico; o senhor está incorporando kilobytes, e 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 autônomo. Os títulos do Markdown oferecem limites naturais que o HTML bruto não oferece.

Etapa 5: recuperar os k melhores

Classifique os trechos recém-incorporados em relação à incorporação da consulta e mantenha os k melhores. Com um corpus pequeno 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. A regra aqui é manter apenas os trechos que ultrapassem um limiar de relevância, para que uma fonte fraca 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 trata-se da 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 conferir a resposta com a página ativa. A fundamentação em textos recuperados neste exato momento é o objetivo principal de 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 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-o novamente assim que ele expirar. A validade TTL é um tempo de validade (TTL) por chunk que indica por quanto tempo uma recuperação armazenada 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 informação expirada 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, tratar-se de uma pergunta definicional estável, um TTL longo é adequado e o sistema 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 o vencimento. Um TTL lida com a obsolescência baseada no tempo, mas alguns eventos exigem invalidação imediata: uma página que o senhor citou retorna um erro 404, uma fonte em que o senhor confia 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 por eventos é o que diferencia um pipeline de web dinâmica de um índice clássico que simplesmente refaz o rastreamento por meio de uma tarefa 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 ativamente para rastreadores em massa. A Cloudflare informou que, em Em 1º de julho de 2025, começou a bloquear os rastreadores de IA por padrão em cerca de 20% da web e lançou um mercado de pagamento por rastreamento. Como resultado, a manutenção de um índice pré-criado 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. Caso deseje disponibilizar esse pipeline para agentes como uma ferramenta acionável, veja como criar um MCP Server 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 correspondente no cache já tiver ultrapassado seu TTL; reutilize um bloco armazenado em cache quando ele ainda estiver atualizado e a consulta for estável. A decisão é tomada para cada consulta, com base no sinal de sensibilidade ao tempo da Etapa 1 e no TTL restante do bloco. É na aplicação correta dessa regra que o senhor 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. No entanto, recorra à busca em tempo real quando houver falha no cache, o bloco tiver expirado, a consulta tiver a intenção de obter dados recentes ou a fonte armazenada em cache tiver sido invalidada. Isso mantém as consultas comuns e repetidas com baixo custo, ao mesmo tempo em que garante que as consultas voláteis estejam atualizadas.

Ajuste os limites observando dois modos de falha. 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 (demasiadas consultas em tempo real em consultas estáveis) levam na direção oposta. Pelo que observamos nas cargas de trabalho dos agentes, não existe uma configuração única correta; o equilíbrio adequado depende da composição do seu tráfego e da velocidade com que suas fontes realmente se alteram.

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% registrados em 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 coletam dados da 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 do 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