O parser baseado em seletores CSS quebra quando o site muda o layout. O parser baseado em LLM não quebra, mas cobra por cada página. Em 2026, a escolha entre eles deixou de ser uma questão de gosto: os preços dos modelos se dispararam em dezenas de vezes, e a mesma página pode custar 3.000 ou 20.000 tokens, dependendo do que você enviou para o modelo. Abaixo está uma comparação de três abordagens em termos de custo, confiabilidade e tráfego de proxy, considerando 1.000 e um milhão de páginas.
Resumindo: o que escolher
- Seletores (CSS/XPath) — um modelo de página, grandes volumes, layout estável. O custo de extração é próximo de zero, mas o suporte recai sobre o desenvolvedor.
- Extração LLM — muitos sites diferentes, layout instável, tarefas pontuais. Você paga por tokens em cada página e deve validar a resposta.
- Híbrido — o LLM escreve seletores uma vez, depois os seletores funcionam, e o modelo é chamado apenas quando a verificação de dados falha. Para a maioria dos parsers permanentes, isso é o ideal.
Criterios de comparação
Comparamos em cinco pontos que realmente afetam o custo final e a qualidade dos dados:
- custo de extração por 1.000 páginas;
- comportamento ao mudar o layout;
- precisão e risco de valores inventados;
- velocidade e latência;
- consumo de tráfego de proxy — como você verá, isso quase não depende do método escolhido.
Quanto custa a extração LLM: calculando pelos preços de outubro de 2026
Os preços oficiais por um milhão de tokens (entrada / saída) na tarifa padrão:
- Gemini 2.5 Flash-Lite — $0,10 / $0,40;
- Gemini 3.1 Flash-Lite — $0,25 / $1,50;
- Claude Haiku 4.5 — $1 / $5;
- Gemini 3.5 Flash — $1,50 / $9.
A Google e a Anthropic têm uma API em lote com 50% de desconto na entrada e saída — para scraping, onde a resposta não precisa ser imediata, esse é o primeiro alavancador de economia.
A principal variável — não é o modelo, mas o que você envia para ele
Uma página HTML bruta ao ser enviada para o modelo geralmente ocupa de 10 a 40 mil tokens. A Cloudflare, ao lançar a função Markdown for Agents, deu um exemplo: a mesma postagem de blog pesa 16.180 tokens em HTML e 3.150 tokens em Markdown — uma redução de 80%. Outras medições em notícias, documentação e cartões de produtos mostram uma redução de 67% a 94%.
Para o cálculo, vamos considerar as suposições: página bruta — 20.000 tokens, limpa para Markdown — 3.000, mais 500 tokens para instruções e esquema, resultando em 300 tokens JSON. Em 1.000 páginas, obtemos:
| Modelo | HTML Bruto (20,5 milhões de entrada) | Markdown (3,5 milhões de entrada) |
|---|---|---|
| Gemini 2.5 Flash-Lite | ≈ $2,17 | ≈ $0,47 |
| Gemini 3.1 Flash-Lite | ≈ $5,58 | ≈ $1,33 |
| Claude Haiku 4.5 | ≈ $22,00 | ≈ $5,00 |
| Gemini 3.5 Flash | ≈ $33,45 | ≈ $7,95 |
A variação é de 70 vezes entre a pior e a melhor opção com o mesmo resultado. Dois terços dessa diferença vêm da limpeza da entrada, e não da escolha do modelo. Em um milhão de páginas por mês, isso pode custar cerca de $470 ou mais de $33.000.
Mais um detalhe: os modelos Claude a partir da versão 4.7 usam um novo tokenizador que, segundo a Anthropic, gera cerca de 30% mais tokens para o mesmo texto. Ao comparar as contas de diferentes gerações de modelos, considere isso — o Haiku 4.5 opera com o tokenizador antigo.
Seletores: quase gratuitos, até o site mudar
A execução de um seletor CSS ou XPath em uma página já baixada custa uma fração de milissegundo do processador. No guia da ScrapingBee, a avaliação é a seguinte: em um layout estável, um seletor comum é cerca de 10 vezes mais barato e mais rápido que a extração LLM. Na prática, a diferença é ainda maior, pois o seletor não faz uma solicitação de rede para a API do modelo.
O custo dos seletores está no suporte:
- se o site renomear uma classe ou envolver um bloco em um novo div — o parser silenciosamente retorna campos vazios;
- testes A/B mostram diferentes modelos para diferentes visitantes, e parte das páginas não é parseada;
- em 50 sites diferentes, você mantém 50 conjuntos de seletores.
O cenário mais perigoso não é a falha, mas a corrupção silenciosa dos dados: o seletor captura um elemento adjacente, e um preço antigo é gravado na base de dados por semanas em vez do atual.
LLM: resistente ao layout, mas capaz de inventar
Os modelos não precisam de um caminho exato para o elemento — eles buscam "preço" pelo significado. Isso elimina o problema de classes renomeadas e diferentes modelos. Mas surgem três falhas típicas que todos que executaram esses parsers em produção descrevem:
- valores inventados — o modelo "adivinha" um preço ou artigo que não está na página;
- campos ausentes — parte dos dados não foi extraída;
- deriva de estrutura — uma string em vez de um número, outro nome de chave.
A proteção é obrigatória: um esquema de resposta rigoroso, validação (por exemplo, Pydantic), temperature = 0 e repetição em caso de erro. Zero de temperatura reduz a variação, mas não elimina completamente as alucinações. Para preços e estoques, é sensato adicionar uma verificação "o valor realmente aparece no texto da página".
A latência também é maior: ao tempo de carregamento da página através do proxy, soma-se a resposta do modelo — de frações de segundo a vários segundos. Para monitoramento uma vez por dia, isso não é importante; para rastreamento de quedas, é crítico.
Híbrido: LLM escreve seletores, não extrai dados
A terceira abordagem é diretamente suportada por bibliotecas populares. No Crawl4AI, há uma função de geração de esquema: o modelo observa amostras de HTML uma vez e retorna um conjunto de seletores CSS/XPath, após o que a extração ocorre sem chamadas ao LLM. A documentação enfatiza que esse é um custo único, e o esquema pode ser reutilizado sem restrições; com várias amostras, o modelo frequentemente escolhe seletores mais robustos com base em atributos em vez de frágeis posicionais como nth-child.
O esquema de trabalho do híbrido:
- O LLM gera seletores com base em 3-5 amostras de páginas de um único modelo.
- O parser trabalha com os seletores, cada registro é verificado por um validador: campos no lugar, tipos corretos, preço em uma faixa razoável.
- Se a proporção de registros inválidos ultrapassar o limite (digamos, 2-5%), a página vai para a extração LLM, e o esquema é regenerado.
- O novo esquema é testado em uma amostra de controle e só depois substitui o antigo.
Dessa forma, você paga pelo modelo apenas nos momentos de mudança de layout, e não por cada uma das milhões de páginas.
Tabela resumida
| Critério | Seletores | Extração LLM | Híbrido |
|---|---|---|---|
| Custo de extração | próximo de zero | $0,5–33 por 1.000 págs. | próximo de zero + chamadas únicas |
| Mudança de layout | quebra, muitas vezes silenciosamente | geralmente sobrevive | conserta automaticamente |
| Risco de dados inventados | não há (mas há "não é o elemento") | existe, validação necessária | mínimo |
| Velocidade | máxima | + resposta do modelo em cada página | como os seletores |
| Muitos sites diferentes | caro para suporte | ponto forte | bom, esquema para cada modelo |
| Tráfego de proxy | igual — o modelo não reduz os bytes baixados | ||
Sobre proxies: LLM não economiza tráfego
Um erro comum nos cálculos é pensar que um parser "inteligente" é mais barato na rede. Não é: a conversão de HTML para Markdown ocorre após o download, portanto, uma página completa passa pelo proxy em qualquer método de extração. A exceção são sites onde o proprietário habilitou a entrega de Markdown pelo cabeçalho Accept: text/markdown (como na função da Cloudflare), mas essa é uma decisão do site, não sua.
Para escala: com um peso de HTML de 200 KB sem imagens, 1.000 páginas equivalem a cerca de 0,2 GB, ou aproximadamente $0,54 em proxies residenciais a $2,70 por GB. Compare com a tabela acima: ao enviar HTML bruto para o Claude Haiku 4.5, a conta do modelo será 40 vezes maior que a conta do proxy, enquanto no Markdown e Flash-Lite elas são comparáveis. Se você renderiza páginas com um navegador headless, o tráfego aumentará exponencialmente — medições estão em nossa comparação de consumo de tráfego do Playwright, Puppeteer e requests em 1.000 páginas.
O que realmente afeta o tráfego em qualquer método:
- não baixar imagens, fontes e análises, se não forem necessárias;
- procurar uma API JSON interna em vez de HTML;
- não fazer repetições desnecessárias: cada banimento e retry são bytes pagos. Para mais informações sobre por que o preço por GB é enganoso, veja a análise do custo real de um registro bem-sucedido.
Para catálogos simples sem proteção anti-bot rigorosa, são suficientes proxies de datacenter a $1,50 por GB; proxies residenciais são necessários onde os IPs de hospedagem são cortados na entrada.
Recomendações para cenários
- Monitoramento de preços de um a três marketplaces, centenas de milhares de cartões. Híbrido ou seletores puros com validador. Conectar LLM apenas para regeneração de esquema.
- Coleta de dados de centenas de sites diversos (leads, vagas, contatos). Extração LLM em Markdown através de um modelo barato em modo batch. Não executar sem um esquema rigoroso e validação.
- Pesquisa pontual em várias milhares de páginas. LLM: por unidades de dólares você economiza dias na escrita de seletores.
- Dados onde um erro custa dinheiro (preços para repricing, estoques). Seletores ou híbrido mais verificação do valor com o texto original da página.
- RAG e bases de conhecimento. Aqui não é necessária uma estrutura, mas texto puro: conversão para Markdown sem extração de campos, modelo — apenas na etapa de resposta.
Conclusão
A extração LLM não substituiu os seletores, mas deslocou o ponto de escolha. O mais barato é o híbrido: o modelo escreve e conserta seletores, em vez de ler cada página. Se não for possível evitar o modelo em cada página, primeiro limpe a entrada para Markdown e use batch: esses dois passos reduzem a conta em 5-10 vezes antes de você começar a escolher o modelo. E lembre-se, o tráfego de proxy não depende do método de extração: você deve economizá-lo no que baixa, e não no que analisa.