Passa al contenuto principale

Pattern di Routing dei Modelli: cascate, classificatori e cosa arriva davvero in produzione

Intermedio

Quando il tuo prodotto fa più di una sola cosa, un unico modello smette di essere la risposta giusta per ogni richiesta. Classificare il ticket, estrarre i campi, scrivere la risposta, revisionarla — sono quattro job con quattro budget diversi di costo/latenza/qualità. Il pattern su cui tutto il campo è convergiuto nel 2026 è instradare ogni richiesta al modello che si adatta al job, ed escalare quando il modello economico non basta. Questa pagina è la guida editoriale a quei pattern: quali sono, quando arrivano in produzione, le ricette che funzionano e le failure mode da evitare.

What you'll learn
  • Conoscere i sei pattern di routing che arrivano in produzione e quando usare ciascuno
  • Capire la differenza tra routing (una decisione a monte) e cascading (escalation al fallimento)
  • Costruire il tuo primo classifier router con un prompt copia-incolla e un piano di rollout di una settimana
  • Leggere la matematica dei costi: quando il routing fa davvero risparmiare, e quando l'overhead si mangia il risparmio
  • Riconoscere gli anti-pattern che trasformano un router in un'interruzione di servizio in attesa di accadere

Perché il routing è il pattern di default nel 2026​

L'era del "un solo grande modello per tutto" è ormai silenziosamente finita. Tre forze hanno guidato il passaggio:

  • Una curva dei prezzi ampia e ben distribuita. Ogni provider maggiore ora rilascia una famiglia — Anthropic (Haiku / Sonnet / Opus), OpenAI (small / mid / frontier), Google (Flash / Pro), più i tier open-weight. I tier economici costano 10–100× meno del frontier e, su task ristretti, sono solo marginalmente peggiori. Lasciare il tier economico inattivo significa bruciare soldi.
  • Budget di latenza reali. Uno step di classificazione davanti a un support agent deve rispondere in meno di 300 ms. Un modello frontier è spesso lo strumento sbagliato per motivi diversi dal costo — è semplicemente troppo lento per quello step.
  • Specializzazione. Modelli diversi guidano davvero su task diversi — uno è migliore su JSON strutturato, un altro sul long context, un altro sul codice, un altro sul multilingua. Le classifiche cambiano ogni mese (vedi Scegliere un Modello), ma la forma — "strumenti diversi per job diversi" — è duratura.

Il risultato: un router davanti ai tuoi modelli, che decide per-richiesta dove inviare il lavoro. Il resto di questa pagina è il vocabolario di design per quel router.

Le due grandi famiglie: routing vs cascading​

Quasi ogni pattern qui sotto è una variazione di due idee. Se cogli la differenza, il resto è nomenclatura.

  • Il Routing prende una decisione a monte, prima che qualsiasi modello venga eseguito. Un classificatore (una regola, un piccolo modello, o un modello più grande) legge la richiesta, sceglie un target e passa il lavoro. Veloce, economico a regime, ma sbagliato quando il classificatore sbaglia — e non lo scopri finché non è tardi.
  • Il Cascading esegue prima il modello economico ed escala a uno più forte solo quando un segnale definito dice "questa risposta non è abbastanza buona." Robusto perché il segnale è fondato sull'output reale, ma ogni escalation paga entrambi i modelli — quindi il vantaggio sopravvive solo quando il tier economico gestisce la maggior parte del traffico da solo.

Si compongono. Un sistema di produzione di solito fa entrambi: instrada nella corsia giusta in base al tipo di task, poi fa cascade dentro la corsia in base alla confidenza del modello economico. La tassonomia di Anthropic chiama la decisione a monte "Routing" e la decomposizione dinamica "Orchestrator-Workers"; cascading è il nome usato nell'industria per la variante "prova il piccolo prima, escala al fallimento" della stessa idea.

I sei pattern che arrivano davvero in produzione​

1. Rule-based routing​

Una regola scritta a mano (regex, keyword, campo della richiesta, lunghezza del messaggio) decide il target. Nessun modello viene eseguito per prendere la decisione.

  • Quando vince. Il segnale è inequivocabile ed economico: "se la richiesta contiene un code fence, invia al modello di coding", "se il cliente è sul piano Enterprise, invia al tier frontier", "se l'input è > 200k token, invia al modello long-context."
  • Quando si rompe. La regola silenziosamente marcisce col cambiare del dominio — nuovi modi di dire, nuovi intent, edge case che il regex non aveva mai anticipato. Ogni "if X then Y" è un piccolo pezzo di tech debt.
  • Portalo in produzione quando. Hai uno o due carve-out ad alto valore (un tier a pagamento, un code path, una lingua) e vuoi zero overhead di latenza.

2. Classifier routing (LLM-as-router)​

Un modello piccolo e veloce legge la richiesta e restituisce un'etichetta — "billing" | "technical" | "sales" | "other" — che sceglie l'handler downstream. Anthropic dà questo come uno dei loro esempi canonici: domande facili ad Haiku, difficili a Sonnet.

  • Quando vince. Hai un insieme piccolo e stabile di categorie e ciascuna merita il suo prompt/tool set/modello. Un singolo prompt specialistico per categoria batte un unico gigantesco system prompt fai-tutto.
  • Quando si rompe. Le categorie si sovrappongono (molte richieste reali sono "billing e technical"), il classificatore instrada male in silenzio, o il tuo set di etichette esplode oltre ~10 categorie e le scelte diventano rumorose.
  • Portalo in produzione quando. Puoi enumerare i primi 5–8 tipi di richiesta e ciascuno beneficia materialmente di un handler diverso.

Prompt classifier-router (portabile tra Claude/GPT/Gemini)

You are a request classifier for a support product.

Read the CUSTOMER MESSAGE below and return a JSON object with:
- "category": one of ["billing", "technical", "account", "sales", "other"]
- "confidence": a number from 0.0 to 1.0
- "reason": one short sentence explaining the pick

If you are less than 0.7 confident, use "other" and say why.
Return ONLY the JSON, no prose, no code fence.

CUSTOMER MESSAGE:
"""
{{message}}
"""

3. Complexity-based routing​

Invece di cosa riguarda la richiesta, stimi quanto è difficile — lunghezza, numero di entità, se fa riferimento a numeri/codice, se è probabile l'uso di tool — e scegli un tier di conseguenza: economico per facile, mid per medio, frontier per difficile.

  • Quando vince. Il tipo di task è grosso modo omogeneo (per esempio "rispondere a una domanda di coding") ma le singole richieste variano molto in difficoltà. Invece di pagare prezzi frontier per una domanda di sintassi di due righe, paghi prezzi Haiku per quelle e riservi il frontier per i refactor multi-file.
  • Quando si rompe. Lo "score di difficoltà" è in realtà "lunghezza del prompt", e i prompt lunghi non sono sempre prompt difficili. Un utente incolla un enorme stack trace e fa una domanda banale al riguardo — il tuo router fa upgrade inutilmente.
  • Portalo in produzione quando. Hai varianza misurabile in difficoltà dentro un tipo di task e segnali chiari (lunghezza, presenza di codice, numero di sottodomande) che correlano con essa.

4. Cascade (economico-prima, escalation al fallimento)​

Prova prima il modello economico. Controlla la risposta contro un segnale di fallimento. Se fallisce, riprova sul modello più forte. Questo è il pattern che l'industria porta in produzione più di ogni altro, perché il "segnale" è fondato su ciò che il modello ha effettivamente detto — non su un'ipotesi su ciò che dirà.

  • Cosa conta come segnale? Qualsiasi cosa economica e affidabile: validazione dello schema su un output JSON, un check "questo risponde alla domanda?" fatto da un LLM judge, un campo esplicito "needs_help": true che il modello può emettere quando non è sicuro, un test downstream che esegue il codice, un logprob basso sul token della risposta quando il provider lo espone.
  • Matematica dei costi. Il risparmio sopravvive solo quando il tier economico gestisce la maggior parte del traffico. Se il 90% delle richieste viene risolto dal modello economico e il 10% escala, paghi 0.9 × economico + 0.1 × (economico + forte) ≈ per lo più economico. Se la metà escala, stai pagando più di quanto pagheresti usando sempre il modello forte.
  • Quando vince. Task con un chiaro segnale "ha funzionato?" — codice che gira o non gira, JSON che valida o no, estrazione dove il campo o matcha la sorgente o no.
  • Quando si rompe. Nessun segnale di fallimento economico, oppure il modello economico pensa di aver avuto successo quando non è così (fallimento silenzioso — il caso peggiore).
  • Portalo in produzione quando. Puoi nominare il segnale di fallimento in una frase e non richiede il modello forte per essere controllato.

5. Ensemble / verify-and-vote​

Esegui la stessa richiesta su N modelli in parallelo e riconcilia le risposte — prendi il voto di maggioranza, prendi la prima schema-valida, o invia tutte le N a un judge model che sceglie la migliore.

  • Quando vince. La qualità conta più del costo o della latenza: ricerca legale, riassunto medico, estrazione finanziaria ad alto rischio, "revisiona questo contratto in cerca di red flag." Utile anche per matematica dura e codice, dove modelli diversi fanno errori diversi e la loro intersezione è più affidabile di ogni singolo modello.
  • Quando si rompe. Paghi N× il costo ed erediti la latenza del modello più lento per ogni richiesta. Gli ensemble sono una tassa che accetti per la qualità, non un modo per risparmiare.
  • Portalo in produzione quando. Il costo di sbagliare la risposta è almeno un ordine di grandezza maggiore del costo di N chiamate al modello — cosa quasi mai vera per il traffico consumer e spesso vera per i workflow enterprise.

6. Fallback (disponibilità, non costo)​

Prova il primario; su 429/5xx/timeout, riprova in modo trasparente su un secondario da un provider diverso. Questo è il pattern di cui ogni app multi-modello seria ha bisogno anche se non usa nessuno degli altri.

  • Quando vince. Ogni volta che il tuo provider primario ha un'interruzione o ti mette il throttle esattamente nel momento sbagliato. Il fallback è un pattern di affidabilità, non di ottimizzazione dei costi — il secondario è di solito il tier equivalente di un altro provider, non un modello più economico.
  • Cosa tenere d'occhio. Il fallback path è codice non testato la maggior parte del tempo; regredirà. Fai passare almeno una piccola quota di traffico live sul secondario di continuo, così scopri che la forma della risposta è cambiata prima di doverci contare durante un'interruzione.
  • Portalo in produzione quando. Il tuo SLO di uptime è più alto di quello di qualsiasi singolo provider, o una dipendenza single-provider è un rischio di business (contratti, disponibilità regionale, geopolitica).

Confronto a colpo d'occhio​

PatternDecisione presaAggiunge latenza?Aggiunge costo?Rischio principale
Rule-basedPrima che il modello partaNoNoLe regole marciscono silenziosamente al cambiare degli input
ClassifierPrima, da un piccolo modello+ una chiamata veloce+ una chiamata economicaInstrada male quando le categorie si sovrappongono
Complexity-basedPrima, da un'euristicaTrascurabileTrascurabile"Difficoltà" spesso significa "lunghezza"
CascadeDopo che il modello economico ci prova+ retry all'escalationPer lo più economico a regimeSuccesso silenzioso su una risposta sbagliata
EnsembleEsegue N in parallelo, riconciliaIl più lento degli NN×Stai comprando qualità, non risparmiando
FallbackSolo al fallimento del primario0 nel happy path0 nel happy pathNon testato finché non serve

Ricette reali che vanno in produzione​

I pattern qui sopra sono Lego. In produzione si compongono. Tre ricette che vediamo ripetutamente:

  • Agente di customer support. Il classifier router sceglie una corsia (billing / technical / account / sales), ogni corsia ha il suo system prompt e tool set, dentro la corsia technical un cascade prova prima un modello economico ed escala al frontier quando scatta una tool call "needs escalation". Un fallback tra provider avvolge tutto. Risultato: il 70–90% del traffico non tocca mai il modello frontier.
  • Assistente di coding. Il rule-based routing su tipo di file e dimensione del diff invia piccole edit a un tier economico e refactor multi-file a un coding-specialist. Un cascade sull'output — "la patch si applica pulita e passa lo smoke test?" — escala i fallimenti a un modello più forte. Confronta con la field guide in Claude vs GPT vs Gemini per il coding.
  • RAG QA su un corpus documentale. Il classifier sceglie tra "risponde dal contesto" (economico) e "serve ragionamento cross-document" (mid). Un ensemble di due modelli fa cross-check della risposta per documenti ad alto rischio (contratti, filing). Confronta con Retrieval-Augmented Generation.

Come costruire il tuo primo router in una settimana​

Guided walkthrough1 of 7
  1. Strumenta i prompt *reali* che il tuo prodotto già invia. Te ne servono almeno alcune centinaia, idealmente categorizzati per esito (risolto / escalato / sbagliato). Senza traffico ground-truth stai tirando a indovinare dove il router dovrebbe inviare le cose.

Cosa arriva davvero in produzione (field notes 2026)​

  • Le cascade vanno in produzione molto più dei router appresi. Sistemi di ricerca come RouteLLM addestrano un router su dati di preferenza e possono tagliare i costi 2× o più su benchmark standard (vedi il paper RouteLLM) — ma addestrare e mantenere un router appreso è vera ingegneria. La maggior parte dei team ottiene gran parte dei vantaggi con "economico-prima + escalation esplicita".
  • Il classificatore è quasi sempre un modello di chat economico, non un fine-tune. Modelli Haiku-class o Flash-class con un buon prompt raggiungono la soglia di accuratezza per 5–8 categorie. Fai fine-tune solo se sei in scala e il classificatore economico è il tuo collo di bottiglia.
  • L'evaluator conta più del router. Un router senza un loop di metriche è un'ipotesi. Strumenta ogni decisione di routing con richiesta → modello scelto → esito, e revisiona ogni settimana. Non puoi tunare ciò che non misuri.
  • Infrastruttura e design sono separabili. I pattern qui sopra sono neutrali rispetto a linguaggio e provider. L'idraulica — un endpoint per provider, chiavi virtuali, cap di spesa per team, prompt caching — è ciò che un AI gateway ti dà. Una volta che sai quale pattern vuoi, vedi AI gateway: LiteLLM, OpenRouter, Portkey, Vercel per la scelta concreta.

Anti-pattern da evitare​

  • Il classificatore che chiama il modello frontier. Se scegliere una corsia costa quanto girare il modello forte, non hai risparmiato niente e hai aggiunto latenza. I classificatori devono essere economici.
  • Cascade senza un segnale di fallimento. "Il modello economico ha restituito qualcosa, quindi abbiamo finito" non è un segnale — è una scommessa. Ogni cascade ha bisogno di un check definito che il modello economico può fallire.
  • Proliferazione di regole. Dieci regole sono gestibili. Cento sono un classificatore scritto a mano senza i test. Quando il tuo set di regole supera i ~15 branch, buttalo via e usa un piccolo modello.
  • Ensemble come strategia di costo. Far girare tre modelli in parallelo per risparmiare è un errore di categoria — gli ensemble costano N× per comprare qualità, non per risparmiare costo. Se stai usando un ensemble per compensare un primario scarso, aggiusta il primario.
  • Nessun fallback path. Ogni model provider prima o poi va giù. Un prodotto single-provider erediterà quell'interruzione. Vedi AI gateway per l'idraulica.
  • Routing senza osservabilità. Un router che invia silenziosamente tutto nella corsia sbagliata sembra a posto finché la qualità non crolla due settimane dopo. Logga ogni decisione con l'hash dell'input, il modello scelto, l'esito e il costo — e revisiona settimanalmente.

Verifica la tua comprensione​

Check yourself

0/3
  1. Hai un prodotto di support dove il 90% delle richieste viene risolto correttamente da un modello economico, ma il restante 10% richiede il frontier. Quale pattern ti dà il maggior risparmio di costo?
  2. La guida 'Building Effective Agents' di Anthropic definisce il Routing come:
  3. Stai costruendo un classifier router. Il tuo prompt di classificatore gira su un modello frontier perché 'l'accuratezza conta'. Qual è il problema?

Prossimi passi​

Fonti​

  • Anthropic — Building Effective Agents — definizioni canoniche dei workflow Routing e Orchestrator-Workers.
  • Paper RouteLLM (arXiv 2406.18665) — un router appreso addestrato su dati di preferenza; dimostra il potenziale del pattern, anche se la maggior parte dei team in produzione ancora manda in produzione regole + classificatore + cascade piuttosto che routing appreso.