← Todos os posts
Caso de uso 6 min de leitura

O Problema do Recrawl: Mantendo Pipelines de RAG Atualizados

Sua base de conhecimento de RAG fica desatualizada na semana em que você a lança. Veja como equipes fazem o 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 a mesma barreira 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 ficam desatualizados e as respostas começam a se desviar da realidade.

Vimos equipes construírem o lado da IA de forma limpa e o lado dos dados como um detalhe secundário. O pipeline de ingestão é um script Python rodando no laptop de alguém. Ele faz o scrape de 200 URLs de origem uma vez, joga Markdown limpo em um vector store e todos comemoram. Seis semanas depois, metade das respostas cita páginas removidas, APIs descontinuadas ou recursos de produto que foram lançados em março e atualizados novamente em maio.

A solução parece simples: fazer o recrawl de cada fonte semanalmente. A realidade é mais difícil. Até 2026, cerca de 60% dos sites confiáveis bloqueiam crawlers de IA (contra 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 de handshake. Um script ingênuo que funcionava em janeiro passa a retornar páginas vazias silenciosamente em março.

Pior ainda, alguns sites agora servem conteúdo do tipo tarpit (gerações de Markov sem sentido que parecem prosa real) até envenenar seus embeddings. Assim, seus engenheiros passam metade da semana corrigindo o scraper em vez de entregar o produto. A qualidade da recuperação cai, os clientes percebem e a equipe que você contratou para construir IA se torna uma oficina de manutenção de scrapers.

A Abordagem

O problema do recrawl 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 serve HTML limpo. Uma parcela crescente (qualquer coisa construída em Next.js, qualquer coisa com renderização no lado do cliente) precisa de renderização completa do navegador para retornar conteúdo útil.
  2. Qual proxy? Residencial, datacenter, móvel, geo-localizado, específico de ISP. A escolha certa muda conforme o alvo.
  3. Funcionou de verdade? Um status 200 com corpo vazio, ou uma página HTML de CAPTCHA, é uma request HTTP bem-sucedida e um crawl malsucedido.

Uma plataforma como a FourA lida com cada um desses pontos como uma prioridade de primeira classe.

Para a decisão de renderização, você chama o Single para o caso rápido e barato, e o Browser para alvos pesados em JS. O corpo da chamada tem o mesmo formato, de modo que seu código de ingestão se ramifica apenas uma vez em uma flag por fonte, em vez de carregar centenas de particularidades de sites específicos.

Para a seleção de proxy, o Proxy Finder roda como parte de cada chamada Single, Browser e Auto. A plataforma escolhe uma saída ativa por request, retorna seu ID opaco no meta.proxy da response, e você reutiliza esse ID em chamadas seguintes quando precisar manter a mesma saída. Seu crawler não precisa carregar um algoritmo próprio de classificação de proxies. (Escrevemos sobre o motivo pelo qual 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 "funcionou de verdade", cada request suporta um bloco validate. Você declara o que conta como sucesso: códigos de status aceitos, valores de header obrigatórios, strings no corpo que devem ou não aparecer. A FourA retorna um de sete resultados, e apenas success é cobrado. Um status 200 que falha nas suas regras de conteúdo recebe a marcação application_fail e nunca entra no seu conjunto de dados.

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 defesas contra bots e retorna a tripla 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"]    — rendered body
# r["meta"]    — { "proxy": "<base36 id>", "cookies": [...], "userAgent": "..." }
# On the next recrawl, pass r["meta"]["proxy"] back as `ignoreProxies: [<id>]` to avoid
# the same exit, or via /api/single with `proxy: <id>` to stick to it.

Se o alvo apresentar uma tela intermediária do Cloudflare, a regra validate.data.fail a captura. 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 alimentar os embeddings com uma página de "Just a moment...".

Para o corpus mais amplo, você envolve o mesmo padrão na sua fila de jobs existente. As equipes com quem conversamos executam diffs noturnos em relação ao crawl anterior, geram novos embeddings apenas para os documentos que realmente mudaram e atualizam acervos de 500 fontes em poucas horas de tempo de relógio. A fila de jobs continua sendo sua. A rotatividade de proxies, a decisão de renderização e o veredito de sucesso são nossos.

Resultados

Como fica o ciclo de atualização assim que 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 com recrawl semanal, em vez de um disparo único de 200 URLs no lançamento
  • Tempo de engenharia no scraper: menos de 2 horas por semana, antes de 1 a 2 dias
  • Janela de obsolescência de recuperação: 5 a 7 dias, em vez de ilimitada
  • Taxa de lixo no vector store próxima de zero, porque telas intermediárias do Cloudflare e páginas tarpit são rejeitadas na camada validate antes de chegarem ao seu modelo de embedding
  • Custo previsível por fonte, porque crawls malsucedidos não aparecem no faturamento

O ponto não é que algo disso seja mágico. O ponto é que é entediante. E o entediante é o que a IA em produção precisa. (Para saber mais sobre onde a matemática deixa de funcionar com extração de LLM hospedada, consulte Quando a extração por LLM deixa de se pagar.)

Principal Conclusão

A maioria das equipes que constroem IA vertical pensa que o diferencial competitivo é o prompt, a escolha do modelo ou o algoritmo de recuperação. Não é. O diferencial é o ciclo de atualização: a infraestrutura sem glamour que mantém a base de conhecimento íntegra semana após semana.

As equipes que vencerão na IA vertical até 2026 não serão aquelas com os prompts mais inteligentes. Serão aquelas cujos usuários nunca notarão se os dados estão atualizados, porque eles sempre estarão.