Quando devi estrarre qualche centinaio di campi tipizzati da una pila di documenti, il riflesso è mandare ogni campo a una API hosted di classe flagship. Funziona, ma la bolletta diventa la voce più grande della pipeline, e la maggior parte di quei campi è un lookup che un modello molto più piccolo gestisce bene. La risposta, argomenta un articolo su Towards Data Science, non è “usa il modello grande” né “usa il modello piccolo”: è scegliere il modello per criteri, verificare, ed escalare solo quando la verifica fallisce — una struttura nota in letteratura come LLM cascade.
L’analisi è basata su un benchmark reale: qualche centinaio di campi tipizzati su decine di documenti, con uno sweep di venti modelli locali contro un flagship hosted, tutti a temperature 0 con output JSON.
Cosa dicono i numeri
Tre risultati orientano il design. Primo, più grande non è meglio: un modello 4B (qwen3:4b) e un 7B (mistral:7b) guidano il campo locale, mentre un 12B e un 14B (gemma3:12b, phi4:14b) restano sotto. Il conteggio dei parametri è un predittore scarso. Secondo, c’è un pavimento: i modelli sotto i 2B crollano (qwen2.5:1.5b al 12%, llama3.2:1b al 6%) e un 0.5B restituiva JSON vuoto. Terzo, costo non è velocità: il flagship hosted rispondeva in circa 1,4 secondi per campo, più veloce della maggior parte dei modelli locali da 7B a 14B (dai 2,6 ai 7,6 secondi su una singola GPU consumer).
La leva più forte, però, non è la dimensione ma il contenuto del prompt. Inserendo il glossario del dominio, il piccolo modello locale è passato dal 38% al 62% di campi corretti e il flagship dal 62% al 100%.
La cascade
Il meccanismo ha tre mosse. Si sceglie il modello di partenza per criteri — confidenzialità del documento, affidabilità dell’output tipizzato, complessità della trasformazione. Si valida ogni risposta (shape corretta, span citati esistenti, testo effettivamente presente nella fonte) e si escala al modello successivo solo se la validazione fallisce, in un loop limitato che, se anche il modello più forte fallisce, restituisce un “not answered” tipizzato invece di un valore sbagliato. Quando il problema è una trasformazione difficile — trasformare 3M in 3000000 — conviene splittare: il modello indica la riga sorgente e il codice deterministico fa la conversione. L’autore avverte però che l’architettura fully-local “il modello punta, il codice formatta” ha abbassato l’accuracy rispetto a un modello capace che estrae e formatta in un colpo solo: lo split è uno strumento reale con un costo reale, da misurare.
In sintesi
- La dimensione del modello non ordina l’accuracy; famiglia e training contano di più.
- Arricchire il prompt con il vocabolario del dominio è più efficace di salire di parametri.
- Cascade economica di default più validazione ed escalation limitata: si paga il modello costoso solo sui casi che lo richiedono.
Fonte: Loop Engineering for RAG Generation: An LLM Cascade from a Cheap Local Model Up to a Hosted Flagship — https://towardsdatascience.com/loop-engineering-for-rag-generation-an-llm-cascade-from-a-cheap-local-model-up-to-a-hosted-flagship/
Hai qualcosa da aggiungere? Unisciti alla discussione.