← Todos os posts
Caso de uso 6 min de leitura

O Problema do Recrawl: Mantendo Pipelines RAG Atualizados

A sua base de conhecimento RAG envelhece na semana em que você a publica. Veja como equipes fazem recrawl de centenas de fontes verticais sem estourar o orçamento de engenharia.

ragai-trainingdata-collectionvertical-aiuse-case

O Desafio

Startups de IA vertical enfrentam o mesmo obstáculo por volta do segundo mês. Elas lançam um copilot de suporte, um assistente de pesquisa jurídica ou um bot de conformidade. A primeira demonstração conquista clientes. Depois, os dados envelhecem e as respostas começam a se distanciar da realidade.

Vimos equipes construírem a parte de IA com perfeição e deixarem a parte de dados para depois. O pipeline de ingestão é um script em Python rodando no laptop de alguém. Ele faz scraping de 200 URLs de origem uma vez, descarrega Markdown limpo em um vector store, e todos comemoram. Seis semanas depois, metade das respostas cita páginas removidas, APIs descontinuadas ou recursos de produtos lançados em março e alterados novamente em maio.

A solução parece simples: rastrear todas as fontes semanalmente. A realidade é mais complexa. Até 2026, cerca de 60% dos sites confiáveis bloqueiam crawlers de IA (acima dos 23% no final de 2023), e as proteções não são mais simples verificações de User-Agent. Elas analisam o comportamento da sessão, o ritmo das requests e sinais no nível do handshake. Um script ingênuo que funcionava em janeiro passa a retornar páginas vazias silenciosamente em março.

Pior ainda, alguns sites agora entregam conteúdo tarpit (conteúdo sem sentido gerado por cadeias de Markov que parece texto real) até contaminar seus embeddings. Assim, seus engenheiros passam metade da semana corrigindo o scraper em vez de entregar produto. A qualidade da recuperação cai, os clientes percebem, e o time contratado para criar IA vira uma equipe de manutenção de scrapers.

A Abordagem

O problema do rastreamento periódico se divide em três decisões concretas que precisam ocorrer a cada request:

  1. Renderizar ou não? A maioria dos portais de documentação entrega HTML limpo. Uma parcela crescente (tudo construído em Next.js ou com renderização no cliente) precisa de renderização completa no navegador para retornar conteúdo útil.
  2. Qual proxy usar? Residencial, datacenter, móvel, com geolocalização fixa ou específico por ISP. A escolha certa varia conforme o alvo.
  3. Realmente funcionou? Um status 200 com body vazio, ou uma página de verificação, é uma request HTTP bem-sucedida, mas um crawl com falha.

Uma plataforma como o FourA trata cada uma dessas questões como prioridade.

Para a decisão de renderização, você chama Single para o caso mais barato e rápido, e Browser para alvos com muito JS. A estrutura do body da chamada é a mesma, para que seu código de ingestão use apenas uma condição baseada em uma flag por fonte, em vez de carregar centenas de ajustes específicos para cada site.

Para a seleção de proxy, o Proxy Finder é executado em todas as chamadas Single, Browser e Auto. A plataforma escolhe uma saída funcional por request, retorna seu id opaco na response (no r.proxy de nível superior em Single/Browser, ou r.session.proxy em Auto), e você reutiliza esse id nas chamadas seguintes quando precisar manter a mesma saída. Seu crawler não precisa ter um algoritmo próprio de classificação de proxies. (Explicamos por que o tamanho do pool deixou de ser o diferencial em Por que o tamanho do pool de proxies deixou de importar em 2026.)

E para a pergunta "realmente funcionou?", toda request suporta um bloco validate. Você declara o que conta como sucesso: status codes aceitos, valores de header obrigatórios, strings no body que devem ou não aparecer. O FourA retorna um de sete resultados, e apenas success é faturável. Um 200 que falha nas suas regras de conteúdo é marcado como application_fail e nunca entra no seu dataset.

Veja como é uma chamada de recrawl para um portal de documentação que precisa de renderização JS. Deixamos o Auto orquestrar, ele escolhe o produto certo (Single, Proxy ou Browser), lida com proteções antibot e retorna a trinca de sessão para que o próximo recrawl possa manter a mesma saída:

import requests

r = requests.post(
    "https://api.foura.ai/api/auto",
    headers={"Authorization": "Bearer pk_live_..."},
    json={
        "url": "https://docs.example.com/changelog",
        "validate": {
            "status": {"accept": [200]},
            "data":   {"accept": ["<article"], "fail": ["captcha", "Just a moment"]},
        },
    },
).json()

# r["data"] or r["body"]   — rendered content (Auto runs the right sub-product per host;
#                            Single populates "data", Browser populates "body")
# r["session"]              — { "proxy": "<base36 id>", "cookies": [...], "userAgent": "..." }
# On the next recrawl, pass r["session"]["proxy"] back as `ignoreProxies: [<id>]` to avoid
# the same exit, or via /api/single with `proxy: <id>` to stick to it.

Se o destino exibir um interstitial da Cloudflare, a regra validate.data.fail intercepta isso. O resultado registrado no seu uso é application_fail. Você não paga por isso, e seu código de ingestão sabe que deve tentar novamente com um proxy diferente em vez de enviar uma página de "Just a moment..." para os embeddings.

Para o corpus mais amplo, você encapsula o mesmo padrão na sua fila de jobs existente. Equipes com quem conversamos executam diffs noturnos em relação ao crawl anterior, geram embeddings novamente apenas para os documentos que realmente mudaram e atualizam corpora de 500 fontes em poucas horas de tempo real de execução. A fila de jobs continua sendo sua. O churn de proxies, a decisão de renderização e o veredito de sucesso são nossos.

Resultados

Como fica o loop de atualização quando a infraestrutura deixa de ser o gargalo (cenário ilustrativo baseado em padrões que observamos em equipes de IA vertical):

  • 500 URLs de origem rastreadas novamente a cada semana, em vez de um disparo único de 200 URLs no lançamento
  • Tempo de engenharia no scraper: menos de 2 horas por semana, abaixo dos 1-2 dias anteriores
  • Janela de desatualização de recuperação: 5-7 dias, em vez de ilimitada
  • Taxa de lixo no vector store próxima de zero, porque interstitials da Cloudflare e páginas de tarpit são rejeitados na camada validate antes de chegarem ao seu modelo de embedding
  • Custo previsível por fonte, porque crawls com falha não aparecem na fatura

A questão não é que nada disso seja mágico. A questão é que tudo isso é previsível e rotineiro. E previsibilidade é exatamente o que a IA em produção exige. (Para saber mais sobre onde a conta deixa de fechar com extração via LLM hospedada, consulte Quando a extração com LLM deixa de compensar.)

Principal conclusão

A maioria das equipes que desenvolvem IA vertical acredita que o diferencial competitivo está no prompt, na escolha do modelo ou no algoritmo de recuperação. Não está. O diferencial competitivo é o loop de atualização: a infraestrutura sem glamour que mantém a base de conhecimento precisa semana após semana.

As equipes que vão liderar a IA vertical até 2026 não serão aquelas com os prompts mais engenhosos. Serão aquelas cujos usuários nunca percebem que os dados estão atualizados, porque eles sempre estão.