Il parser basato su selettori CSS si rompe quando il sito cambia layout. Il parser basato su LLM non si rompe, ma addebita un costo per ogni pagina. Nel 2026, la scelta tra i due ha smesso di essere una questione di gusto: i prezzi dei modelli si sono allontanati di decine di volte, e la stessa pagina può costare 3.000 o 20.000 token a seconda di ciò che inviate al modello. Di seguito è riportato un confronto tra tre approcci in termini di costi, affidabilità e traffico dei proxy, calcolato per 1.000 e un milione di pagine.
In breve: cosa scegliere
- Selettori (CSS/XPath) — un modello di pagina, grandi volumi, layout stabile. Il costo di estrazione è vicino a zero, ma il supporto ricade sullo sviluppatore.
- Estrazione LLM — molti siti diversi, layout instabile, compiti una tantum. Pagate per i token su ogni pagina e dovete convalidare la risposta.
- Ibrido — LLM scrive i selettori una volta, poi i selettori funzionano, e il modello viene chiamato solo quando il controllo dei dati fallisce. Per la maggior parte dei parser permanenti, questo è l'ottimale.
Criteri di confronto
Confrontiamo su cinque punti che influenzano realmente il costo finale e la qualità dei dati:
- costo di estrazione per 1.000 pagine;
- comportamento al cambio di layout;
- precisione e rischio di valori inventati;
- velocità e latenza;
- consumo di traffico proxy — come vedrete, dipende poco dalla scelta del metodo.
Quanto costa l'estrazione LLM: calcoliamo in base ai prezzi di ottobre 2026
I prezzi ufficiali per un milione di token (ingresso / uscita) sul piano standard:
- 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.
Google e Anthropic offrono un Batch API con uno sconto del 50% su ingresso e uscita — per il parsing dove la risposta non è necessaria immediatamente, questo è il primo strumento di risparmio.
La variabile principale non è il modello, ma ciò che inviate ad esso
Una pagina HTML grezza, quando viene inviata al modello, occupa solitamente da 10 a 40 mila token. Cloudflare, lanciando la funzione Markdown for Agents, ha fornito un esempio: lo stesso post del blog pesa 16.180 token in HTML e 3.150 token in Markdown — meno 80%. Altre misurazioni su notizie, documentazione e schede prodotto mostrano una riduzione dal 67 al 94%.
Per il calcolo, prendiamo delle assunzioni: pagina grezza — 20.000 token, pulita fino a Markdown — 3.000, più 500 token per istruzioni e schema, in uscita 300 token JSON. Per 1.000 pagine otteniamo:
| Modello | HTML grezzo (20,5 milioni ingresso) | Markdown (3,5 milioni ingresso) |
|---|---|---|
| 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 |
La variazione è di 70 volte tra l'opzione peggiore e quella migliore con lo stesso risultato. Due terzi di questa differenza proviene dalla pulizia dell'ingresso, non dalla scelta del modello. Su un milione di pagine al mese, ciò equivale a circa $470 o oltre $33.000.
Un'altra nota: i modelli Claude a partire dalla versione 4.7 utilizzano un nuovo tokenizzatore, che, secondo i dati di Anthropic, fornisce circa il 30% in più di token per lo stesso testo. Confrontando le fatture di diverse generazioni di modelli, tenete conto di questo: Haiku 4.5 funziona con il vecchio tokenizzatore.
Selettori: quasi gratis, finché il sito non cambia
Eseguire un selettore CSS o XPath su una pagina già scaricata costa una frazione di millisecondo di CPU. Nella guida di ScrapingBee, la stima è la seguente: su un layout stabile, un selettore è circa 10 volte più economico e veloce dell'estrazione LLM. Nella pratica, la differenza è ancora maggiore, poiché il selettore non ha una richiesta di rete all'API del modello.
Il costo dei selettori è nel supporto:
- il sito ha rinominato una classe o ha avvolto un blocco in un nuovo div — il parser restituisce silenziosamente campi vuoti;
- i test A/B mostrano modelli diversi a visitatori diversi, e alcune pagine non vengono parsate;
- su 50 siti diversi, gestite 50 set di selettori.
Lo scenario più pericoloso non è il fallimento, ma la corruzione silenziosa dei dati: il selettore cattura un elemento adiacente, e nel database viene scritto per settimane il vecchio prezzo invece di quello attuale.
LLM: resistente ai layout, ma capace di inventare
I modelli non hanno bisogno di un percorso preciso verso l'elemento — cercano "prezzo" per significato. Questo risolve il problema delle classi rinominate e dei diversi modelli. Ma emergono tre tipi di errori tipici, che descrivono tutti coloro che hanno eseguito tali parser in produzione:
- valori inventati — il modello "indovina" un prezzo o un articolo che non è presente nella pagina;
- campi mancanti — parte dei dati non è stata estratta;
- deriva della struttura — una stringa invece di un numero, un altro nome di chiave.
La protezione è obbligatoria: schema di risposta rigoroso, convalida (ad esempio, Pydantic), temperature = 0 e ripetizione in caso di errore. Zero temperature riduce la variazione, ma non elimina completamente le allucinazioni. Per prezzi e scorte, è ragionevole aggiungere un controllo "il valore appare effettivamente nel testo della pagina".
Anche la latenza è più alta: al tempo di caricamento della pagina tramite proxy si aggiunge la risposta del modello — da frazioni di secondo a diversi secondi. Per il monitoraggio una volta al giorno, questo non è importante, ma per il monitoraggio delle cadute è critico.
Ibrido: LLM scrive selettori, non estrae dati
Il terzo approccio è direttamente supportato da librerie popolari. In Crawl4AI c'è una funzione di generazione dello schema: il modello guarda una volta i campioni HTML e restituisce un insieme di selettori CSS/XPath, dopodiché l'estrazione avviene senza chiamate LLM. Nella documentazione si sottolinea che questo è un costo una tantum, e lo schema può essere riutilizzato senza limitazioni; con più campioni, il modello spesso sceglie selettori più stabili in base agli attributi invece di quelli fragili di posizione come nth-child.
Schema operativo dell'ibrido:
- LLM genera selettori da 3 a 5 campioni di pagine dello stesso modello.
- Il parser lavora sui selettori, ogni registrazione viene controllata da un validatore: i campi sono al loro posto, i tipi sono corretti, il prezzo è in un intervallo ragionevole.
- Se la percentuale di registrazioni non valide supera la soglia (diciamo, 2-5%), la pagina passa all'estrazione LLM, e lo schema viene rigenerato.
- Il nuovo schema viene testato su un campione di controllo e solo dopo sostituisce il vecchio.
In questo modo pagate per il modello solo nei momenti di cambio di layout, e non per ogni pagina di un milione.
Tabella riassuntiva
| Criterio | Selettori | Estrazione LLM | Ibrido |
|---|---|---|---|
| Costo di estrazione | circa zero | $0,5–33 per 1.000 pag. | circa zero + chiamate una tantum |
| Cambio di layout | si rompe, spesso silenziosamente | di solito resiste | si ripara automaticamente |
| Rischio di dati inventati | nessuno (ma c'è "non quell'elemento") | c'è, necessaria convalida | minimo |
| Velocità | massima | + risposta del modello su ogni pagina | come per i selettori |
| Molti siti diversi | costoso da mantenere | punto di forza | buono, schema per ogni modello |
| Traffico proxy | uguale — il modello non riduce i byte scaricati | ||
Riguardo ai proxy: LLM non risparmia traffico
Un errore comune nei calcoli è pensare che un parser "intelligente" sia più economico in rete. No: la conversione da HTML a Markdown avviene dopo il download, quindi attraverso il proxy passa l'intera pagina con qualsiasi metodo di estrazione. Eccezione: siti dove il proprietario ha attivato la restituzione di Markdown tramite l'intestazione Accept: text/markdown (come nella funzione Cloudflare), ma questa è una decisione del sito, non vostra.
Per dare un'idea: con un peso HTML di 200 KB senza immagini, 1.000 pagine equivalgono a circa 0,2 GB, o circa $0,54 per proxy residenziali a $2,70 per GB. Confrontate con la tabella sopra: inviando HTML grezzo a Claude Haiku 4.5, il costo per il modello risulterà 40 volte superiore al costo per il proxy, mentre con Markdown e Flash-Lite saranno comparabili. Se renderizzate le pagine con un browser headless, il traffico aumenterà notevolmente — ci sono misurazioni nel nostro confronto sul consumo di traffico di Playwright, Puppeteer e requests per 1.000 pagine.
Ciò che influisce realmente sul traffico con qualsiasi metodo:
- non scaricare immagini, font e analisi se non necessari;
- cercare un JSON API interno invece di HTML;
- non fare ripetizioni inutili: ogni ban e retry sono byte pagati. Maggiori dettagli su perché il costo per GB è ingannevole — nell'analisi del costo reale di una registrazione riuscita.
Per cataloghi semplici senza rigida protezione anti-bot, bastano proxy datacenter a $1,50 per GB; i residenziali sono necessari dove gli IP di hosting vengono bloccati all'ingresso.
Raccomandazioni per scenari
- Monitoraggio dei prezzi di uno o tre marketplace, centinaia di migliaia di schede. Ibrido o selettori puri con validatore. LLM da collegare solo per la rigenerazione dello schema.
- Raccolta di dati da centinaia di siti eterogenei (lead, offerte di lavoro, contatti). Estrazione LLM su Markdown tramite un modello economico in modalità batch. Non avviare senza uno schema rigoroso e convalida.
- Ricerca una tantum su alcune migliaia di pagine. LLM: per pochi dollari risparmiate giorni nella scrittura dei selettori.
- Dati dove un errore costa denaro (prezzi per repricing, scorte). Selettori o ibrido più verifica del valore con il testo originale della pagina.
- RAG e basi di conoscenza. Qui serve testo puro, non struttura: conversione in Markdown senza estrazione di campi, modello — solo nella fase di risposta.
Conclusione
L'estrazione LLM non ha sostituito i selettori, ma ha spostato il punto di scelta. La soluzione più economica è l'ibrido: il modello scrive e ripara i selettori, e non legge ogni pagina. Se non potete fare a meno del modello su ogni pagina, prima pulite l'ingresso fino a Markdown e usate batch: questi due passaggi riducono il costo di 5-10 volte prima di iniziare a scegliere il modello. E ricordate, il traffico proxy non dipende dal metodo di estrazione: dovete risparmiare su ciò che scaricate, non su come analizzate.