← Todos os posts
Insight do setor 6 min de leitura

Quando a extração por LLM deixa de se pagar

O Firecrawl cobra 5x mais para extrair uma página com LLM em vez de fazer o scrape. Com 100 mil páginas por dia, a matemática entra em colapso. Quando a extração por LLM justifica o custo, e quando não.

llm-extractionweb-scrapingcost-optimizationai-scrapingarchitecture

Quando a extração por LLM deixa de se pagar

O Firecrawl cobra 1 crédito para fazer o scrape de uma página e 5 créditos para extrair campos estruturados da mesma página (Preços do Firecrawl, 2026). Isso é um acréscimo de 5x pelo mesmo HTML, enviado através de um modelo.

A promessa é real: descreva o que você quer, receba um JSON de volta, sem seletores para manter. Para layouts instáveis e alvos únicos, isso justifica o acréscimo. Mas para o pipeline de produção que puxa 500 mil páginas de produtos por dia dos mesmos cinco varejistas, não.

Vimos equipes implementarem a extração padrão por LLM, chegarem ao mês da fatura e começarem a procurar uma saída. A solução geralmente não é abandonar os LLMs. É colocá-los no lugar certo do pipeline.

A matemática fica feia rápido

Pegue o Firecrawl na ponta barata. Scrape mais extração por IA custa 6 créditos por página sem crawl, 7 créditos com crawl (Análise do ScrapeGraphAI, 2026). 100 mil páginas por dia no plano growth deles custa cerca de US$ 21 mil por mês antes das tentativas, antes de você pagar por um único proxy.

Rode seu próprio pipeline de LLM e a matemática muda, mas não fica pequena. O GPT-4o custa US$ 2,50 por milhão de tokens de entrada e US$ 10 por milhão de saída (PricePerToken, 2026). Uma página de produto após a conversão para markdown consome 4K-8K tokens de entrada. Digamos 6K de entrada, 200 de saída para um blob JSON. Com 100 mil páginas por dia, isso dá US$ 360 diários, US$ 11 mil mensais por um trabalho que seletores CSS fazem de graça após uma configuração.

Esse é o modelo barato. Mude para o Claude Sonnet 4.6 (US$ 3 de entrada, US$ 15 de saída) e a conta dobra (PE Collective, 2026). Mude para um modelo de raciocínio e adicione uma penalidade de 3 a 10x dependendo do quanto ele pensa antes de responder.

Nada disso conta as falhas. Uma taxa de alucinação de 3-5% parece inofensiva até você fazer a aritmética. Com 100 mil páginas por dia, são 3.000 a 5.000 registros errados fluindo para o seu warehouse, parecendo exatamente com os certos porque o modelo os retornou com confiança. Como a DataHen colocou: "Não é que a IA erre às vezes. É que ela erra com confiança." (DataHen, 2026).

O que as equipes experientes realmente fazem

Leia a documentação dos fornecedores que realmente rodam scrapers em produção e o padrão é consistente: híbrido. Use o LLM para entender a página uma vez, depois rode código determinístico barato para tudo o que vier a seguir.

A Zyte deixa isso claro em sua própria documentação: "Em vez de usar um LLM por página, use seu LLM para gerar seletores CSS para os campos desejados dado o HTML bruto de uma primeira página, e use esses seletores para fazer o parse de todas as outras páginas." (Guia de LLM da Zyte, 2026). A Apify recomenda o mesmo fluxo em seu guia de 2026: tente seletores CSS primeiro, use o LLM como fallback quando eles falharem (Guia Apify 2026). Um artigo da DEV Community sobre uma implementação em produção capturou a arquitetura exatamente: o caminho do seletor em cache não custa nada, o LLM só dispara quando a validação falha (DEV.to, 2026).

Então a divisão de produção fica assim:

  • O LLM inicializa o seletor (uma chamada por alvo, frações de centavo)
  • O seletor roda contra todas as páginas (grátis)
  • Um validador (geralmente um regex ou uma verificação de presença) captura o desvio
  • O desvio aciona uma reinicialização, semanas ou meses depois

O custo por página desaba de cerca de US$ 0,005 para bem abaixo de US$ 0,0001. A qualidade aumenta porque o parsing determinístico não alucina. E você gasta tokens no trabalho em que os LLMs realmente são bons: ler estruturas novas, não repetir estruturas que você já mapeou.

Onde os LLMs justificam a conta de qualquer forma

Esta não é uma peça anti-LLM. Muitos trabalhos de extração são exatamente onde o modelo é a ferramenta certa e a matemática dos créditos funciona:

  • Layouts instáveis que mudam semanalmente. Seletores que quebram toda terça-feira custam mais em tempo de engenharia do que a extração por LLM custa em tokens. Rode o modelo.
  • Alvos de cauda longa que você nunca visitará duas vezes. Não há retorno para escrever um seletor. Rode o modelo.
  • Conteúdo não estruturado onde a saída é em si um resumo. Descrições de vagas para habilidades, artigos para afirmações, avaliações para sentimentos. Seletores não podem ajudar. Rode o modelo.
  • Páginas com campos opcionais espalhados por variantes de layout. Um único template com vinte renderizações condicionais é exatamente onde os LLMs vencem cadeias de regex.

Olhe para o seu pipeline. Ordene os alvos por volume. Os 20% principais por contagem de requests quase sempre têm estrutura estável (é por isso que são os 20% principais, você os integrou deliberadamente). Eles são candidatos a seletores. A cauda longa é o lugar do modelo.

O que isso significa para a sua stack

O discurso de vendas em 2026 quer que você use a extração por LLM como padrão. A precificação por créditos faz isso parecer razoável em projetos pequenos. Deixa de ser razoável quando você escala, da mesma forma que o tamanho da pool de proxies parou de prever o sucesso real assim que o sinal subjacente quebrou.

Três lições para equipes construindo pipelines reais:

  1. Separe o fetch do parse. Se o seu fornecedor de scraping retorna apenas JSON extraído por LLM, você não pode recorrer a seletores como fallback quando a conta chegar. Escolha uma infraestrutura que te entregue o HTML e permita que você escolha o caminho de extração.
  2. Faça cache agressivo no nível do seletor. Seletores gerados são reutilizáveis em milhares de páginas. A chamada cara é a geração, não o uso.
  3. Meça o custo por registro, não por página. Um pipeline que custa US$ 0,001/página mas entrega 5% de registros ruins custa mais do que um que custa US$ 0,005/página e entrega dados limpos. Armazenamento, queries downstream e a eventual limpeza têm um peso.

Escolha a metade chata

A extração por LLM como padrão tem o formato certo para uma demo e o formato errado para produção. As equipes que estão acertando são aquelas que tratam os LLMs como uma ferramenta para entender uma página, não uma ferramenta para ler uma página. O código determinístico e chato ainda vence o jogo do volume em 2026, o modelo vence o jogo da novidade. Ambos pertencem à stack.

Na FourA, o Single e o Browser retornam a response bruta (HTML, DOM renderizado, headers, body) e param por aí. Se você faz o parse com seletores, envia para um modelo ou faz ambos, é uma decisão sua. Nós não adicionamos um multiplicador de créditos por uma extração que não fizemos.