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

A 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 (Firecrawl pricing, 2026). Isso representa 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 pontuais, o custo extra compensa. Mas para o pipeline de produção que extrai 500K páginas de produtos por dia dos mesmos cinco varejistas, não compensa.

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

A conta fica feia rapidamente

Pense na Firecrawl como a opção mais barata. Scrape mais extração por IA custa 6 créditos por página sem crawl, 7 créditos com crawl (ScrapeGraphAI breakdown, 2026). 100K páginas por dia no plano de crescimento custam cerca de US$ 21K por mês antes das tentativas de reenvio, e antes de você pagar por um único proxy.

Execute seu próprio pipeline de LLM e a conta muda, mas não fica barata. 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 de 4K a 8K tokens de entrada. Digamos 6K de entrada e 200 de saída para um bloco JSON. Com 100K páginas por dia, isso dá US$ 360 diários, US$ 11K mensais para um trabalho que seletores CSS fazem de graça após uma única configuração.

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

Nada disso inclui as falhas. Uma taxa de alucinação de 3% a 5% parece inofensiva até você fazer as contas. Em 100K páginas por dia, são de 3.000 a 5.000 registros incorretos entrando no seu data warehouse, parecendo exatamente corretos 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 de fornecedores que realmente executam scrapers em produção e o padrão é consistente: híbrido. Use a LLM para entender a página uma vez e, depois, execute um código determinístico barato para tudo o que se segue.

A Zyte explica isso claramente em sua própria documentação: "Em vez de usar uma LLM por página, use sua LLM para gerar seletores CSS para os campos desejados a partir do HTML bruto de uma primeira página, e use esses seletores para analisar todas as outras páginas." (Zyte LLM guide, 2026). A Apify recomenda o mesmo fluxo em seu guia de 2026: tente seletores CSS primeiro, recorrendo à LLM quando eles falharem (Apify 2026 guide). Um artigo da DEV Community sobre uma implementação em produção capturou a arquitetura perfeitamente: o caminho do seletor em cache não custa nada, a LLM só é acionada quando a validação falha (DEV.to, 2026).

Portanto, a divisão em produção funciona assim:

A LLM inicializa o seletor (uma chamada por alvo, frações de centavo)
O seletor é executado em cada página (grátis)
Um validador (geralmente uma regex ou uma verificação de presença) detecta desvios
O desvio aciona uma nova inicialização, semanas ou meses depois

O custo por página cai de cerca de US$ 0,005 para bem menos de US$ 0,0001. A qualidade aumenta porque a análise determinística não alucina. E você gasta tokens no trabalho em que as LLMs são realmente boas: ler estruturas novas, não repetir estruturas que você já mapeou.

Onde as LLMs justificam o custo de qualquer forma

Este não é um artigo contra as LLMs. Muitos trabalhos de extração são exatamente onde o modelo é a ferramenta certa e a conta dos créditos fecha:

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. Execute o modelo.
Alvos de cauda longa que você nunca visitará duas vezes. Não compensa escrever um seletor. Execute o modelo.
Conteúdo não estruturado onde a própria saída é um resumo. Descrições de vagas para habilidades, artigos para alegações, avaliações para sentimento. Seletores não ajudam. Execute o modelo.
Páginas com campos opcionais espalhados por variantes de layout. Um único template com vinte renderizações condicionais é exatamente onde as LLMs superam cadeias de regex.

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

O que isso significa para a sua stack

A promessa dos fornecedores em 2026 quer que você use a extração por LLM como padrão. O preço por crédito faz com que isso pareça razoável em projetos pequenos. Deixa de ser razoável quando você escala, da mesma forma que o tamanho do pool de proxies deixou de prever o sucesso real assim que o sinal subjacente quebrou.

Três pontos importantes para equipes que constroem pipelines reais:

Separe o fetch do parse. Se o seu fornecedor de scraping apenas retorna JSON extraído por LLM, você não poderá recorrer a seletores quando a fatura chegar. Escolha uma infraestrutura que lhe entregue o HTML e permita que você escolha o caminho de extração.
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.
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, consultas downstream e a eventual limpeza têm seu peso.

Escolha a parte chata

O padrão de extração por LLM é o formato certo para uma demo e o formato errado para a produção. As equipes que estão acertando são aquelas que tratam as LLMs como uma ferramenta para entender uma página, não uma ferramenta para ler uma página. O código determinístico 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 devolvem a response bruta (HTML, DOM renderizado, headers, body) e param por aí. Se você analisa com seletores, envia para um modelo ou faz ambos, a escolha é sua. Não cobramos um multiplicador de créditos por uma extração que não realizamos.