← 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

Todas as startups de IA vertical enfrentam a mesma barreira no segundo mês. Elas lançam um copilot de suporte, um assistente de pesquisa jurídica ou um bot de compliance. A primeira demonstração conquista clientes. Depois, os dados envelhecem e as respostas começam a se distanciar da realidade.

Vimos equipes construírem o lado da IA de forma impecável e deixarem o lado dos dados como um detalhe de última hora. O pipeline de ingestão é um script Python rodando no laptop de alguém. Ele faz scraping de 200 URLs de origem uma vez, despeja Markdown limpo num vector store, e todo mundo comemora. Seis semanas depois, metade das respostas cita páginas removidas, APIs descontinuadas ou recursos de produto lançados em março e relançados em maio.

A correção parece simples: faça o recrawl de todas as fontes semanalmente. A realidade é mais feia. Até 2026, cerca de 60% dos sites respeitáveis bloqueiam crawlers de IA (acima de 23% no final de 2023), e as proteções não são mais verificações simples de User-Agent. Elas observam comportamento de sessão, ritmo de request e sinais em nível de handshake. Um script ingênuo que funcionou em janeiro passa a retornar silenciosamente páginas vazias em março.

Pior ainda, alguns sites agora servem conteúdo tarpit (conteúdo sem sentido gerado por cadeias de Markov que se lê como prosa real) até envenenar os seus embeddings. Assim, os seus engenheiros passam metade da semana ajustando o scraper em vez de desenvolver o produto. A qualidade da retrieval cai, os clientes percebem, e a equipe que você contratou para construir IA torna-se uma oficina de manutenção de scraper.

A Abordagem

O problema do recrawl divide-se em três decisões concretas que têm de acontecer a cada request:

  1. Renderizar ou não? A maioria dos portais de documentação serve HTML limpo. Uma fatia crescente (qualquer coisa construída em Next.js, qualquer coisa com renderização client-side) precisa de renderização de browser completa para retornar conteúdo útil.
  2. Qual proxy? Residencial, datacenter, mobile, geo-pinned, ISP específico. A escolha certa muda de acordo com o alvo.
  3. Isso realmente funcionou? Um 200 com um body vazio, ou uma página HTML de CAPTCHA, é um HTTP request bem-sucedido e um crawl que falhou.

Uma plataforma como a FourA lida com cada uma destas questões como uma prioridade de primeira classe.

Para a decisão de renderização, você chama Single para o caso rápido e barato, e Browser para alvos pesados em JS. O body da chamada tem o mesmo formato, para que o seu código de ingestão faça branching apenas uma vez numa flag por fonte, em vez de carregar cem peculiaridades específicas de sites.

Para a seleção de proxy, Proxy Finder roda como parte de todas as chamadas Single, Browser e Auto. A plataforma escolhe um exit funcionando por request, retorna o seu id opaco na response (no r.proxy top-level em Single/Browser, ou r.session.proxy em Auto), e você reutiliza esse id em chamadas subsequentes quando precisar manter o mesmo exit. O seu crawler não carrega um algoritmo próprio de rankeamento de proxy. (Escrevemos sobre o porquê do tamanho da pool ter deixado de ser o diferencial em Why Proxy Pool Size Stopped Mattering in 2026.)

E para a questão "isso realmente funcionou", todos os requests suportam um bloco validate. Você declara o que conta como sucesso: códigos de status aceitos, valores obrigatórios de header, strings no body que devem ou não aparecer. A FourA retorna um dos sete resultados, e apenas success é cobrado. Um 200 que falhe nas suas regras de conteúdo é carimbado como application_fail e nunca entra no seu dataset.

Veja como se parece uma chamada de recrawl para um portal de docs que precisa de um render de JS. Deixamos o Auto orquestrar, ele escolhe o produto certo (Single, Proxy ou Browser), lida com defesas contra bot e retorna a tripla de sessão para que o próximo recrawl consiga manter o mesmo exit:

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 alvo enviar um interstitial do Cloudflare, a regra validate.data.fail pega isso. O resultado carimbado contra o seu uso é application_fail. Você não paga por isso, e o seu código de ingestão sabe que deve tentar novamente com um proxy diferente, em vez de alimentar uma página "Just a moment..." para os embeddings.

Para o corpus mais amplo, você envolve o mesmo padrão na sua fila de jobs existente. As equipes com as quais conversamos executam diffs noturnos em relação ao crawl anterior, re-embed apenas os documentos que realmente mudaram e atualizam corpora de 500 fontes em algumas horas de tempo de relógio. A fila de jobs continua sendo sua. O churn do proxy, a decisão de renderização e o veredito de sucesso são nossos.

Resultados

Como fica o loop de atualização assim que a infraestrutura deixa de ser o gargalo (cenário ilustrativo com base em padrões que vemos entre as equipes de IA vertical):

  • 500 URLs de origem com recrawl semanal, em vez de um único de 200 URLs no lançamento
  • Tempo de engenharia no scraper: menos de 2 horas por semana, abaixo de 1-2 dias
  • Janela de obsolescência da retrieval: 5-7 dias, em vez de ser ilimitada
  • Taxa de lixo no vector store perto de zero, porque os interstitials do Cloudflare e as páginas tarpit são rejeitadas na camada validate antes de chegarem ao seu modelo de embedding
  • Custo previsível por fonte, porque os crawls com falha não aparecem na faturação

O ponto não é que qualquer uma destas opções seja mágica. O ponto é que elas são chatas. E chato é o que a IA em produção precisa. (Para saber mais sobre os casos onde a matemática deixa de funcionar com a extração de LLM hospedada, consulte When LLM Extraction Stops Paying for Itself.)

Conclusão

A maioria das equipes que constrói IA vertical acha que a vantagem competitiva é o prompt, a escolha do modelo ou o algoritmo da retrieval. Não é. A vantagem competitiva é o loop de atualização: a infraestrutura sem glamour que mantém a base de conhecimento precisa, semana após semana.

As equipes que ganharem na IA vertical até 2026 não serão as que tiverem os prompts mais inteligentes. Serão aquelas cujos utilizadores nunca percebem que os dados são atuais, porque sempre são.