«Quale modello dovremmo chiamare?» un tempo sembrava una domanda sulle API. In un numero crescente di organizzazioni, è più vicina a una questione di approvvigionamento, ingegneria delle prestazioni e architettura.
Questo cambiamento segue da un semplice sviluppo: ora esistono molti modelli, offerti da numerosi provider, con punti di forza, prezzi, profili di latenza, opzioni di distribuzione e condizioni contrattuali sostanzialmente diversi. L’accordo annunciato da Stripe per acquisire OpenRouter è un segnale utile. La singola API di OpenRouter copre più di 400 modelli di oltre 80 provider, con criteri di instradamento che includono la complessità del compito, il prezzo, la velocità, l’affidabilità, la latenza, il throughput e i costi specifici dei provider.
Il ruolo emergente non corrisponde necessariamente a un nuovo titolo. Può collocarsi tra l’ingegneria delle piattaforme AI, l’architettura, l’approvvigionamento, le operazioni di inferenza o l’ingegneria del prodotto. Ma la sua responsabilità sta diventando riconoscibile: decidere quale modello debba gestire quale lavoro, entro quali vincoli, con quale fallback e sulla base di quali evidenze.
L’instradamento è una decisione di policy mascherata da infrastruttura
Un router ingenuo chiede: «Qual è il modello più economico?» Un router utile pone una domanda più specifica: «Qual è il modello meno costoso che soddisfa i requisiti di qualità, latenza, affidabilità, privacy e operatività di questa richiesta?»
Questi requisiti variano a seconda del compito. Un classificatore per l’assistenza clienti può aver bisogno di un output strutturato prevedibile e di una bassa latenza. Un compito di programmazione difficile può giustificare un modello più lento ma più capace. Una pipeline di riepilogazione ad alto volume può favorire un modello più piccolo, soprattutto se la sua qualità risulta adeguata dopo i test. Un flusso di lavoro regolamentato può richiedere una determinata regione, una policy di conservazione o un accordo con uno specifico provider indipendentemente dal prezzo dei token.
Ecco perché l’instradamento appartiene alle revisioni architetturali, non soltanto al codice dell’applicazione. Il percorso scelto determina più di una fattura. Può influire sulla localizzazione dei dati, sull’esposizione alle interruzioni, sull’osservabilità, sulla coerenza delle risposte, sul comportamento nell’uso degli strumenti e sulla quantità di revisione umana richiesta a valle.
Le quattro discipline alla base di una seria funzione di instradamento
1. Approvvigionamento: confrontare l’intero servizio, non il prezzo dei token in evidenza
I prezzi dei modelli sono facili da confrontare nel modo sbagliato. I token di input e output possono avere tariffe diverse. L’input memorizzato nella cache, l’elaborazione batch, il servizio prioritario e le richieste con contesto lungo possono modificare il calcolo. Il prezzo nominale di un provider dice inoltre poco su ritentativi, limiti di frequenza, assistenza, impegni minimi, egress o costo ingegneristico della migrazione.
Il responsabile dell’instradamento dovrebbe mantenere un inventario di modelli e provider con campi quali:
- prezzi di input, output, contenuti memorizzati nella cache e batch;
- limiti di contesto e di output;
- limiti di frequenza documentati e throughput osservato;
- distribuzioni della latenza, non soltanto la latenza media;
- disponibilità e comportamento in caso di timeout;
- condizioni relative all’uso dei dati, alla conservazione, alla localizzazione e ai contratti;
- funzionalità supportate, incluse le chiamate agli strumenti, l’output strutturato, la visione e lo streaming;
- opzioni di fallback e migrazione.
Il risultato è più vicino a una distinta base tecnologica che a un elenco di nomi di modelli. Dovrebbe essere riesaminato quando cambiano prezzi, policy, versioni dei modelli o volumi aziendali.
2. Ingegneria delle prestazioni: misurare il compito, non la classifica
I benchmark generali possono aiutare a orientarsi, ma le decisioni di instradamento richiedono test specifici per il carico di lavoro. Un modello che si comporta bene in un benchmark pubblico di programmazione potrebbe non essere la scelta migliore per i repository interni, le convenzioni di denominazione, gli schemi degli strumenti o i controlli di sicurezza di un’organizzazione.
Costruite un set di valutazione rappresentativo a partire da richieste reali, rimuovendo o controllando il materiale sensibile. Etichettate i risultati che contano: correttezza fattuale, JSON valido, selezione riuscita degli strumenti, superamento dei test del codice, comportamento nei rifiuti, necessità di escalation e stile accettabile. Registrate quindi il costo, il tempo al primo token, la latenza totale, la percentuale di timeout, la percentuale di ritentativi e la lunghezza del completamento.
Non riducete troppo presto il risultato a un unico punteggio. Un punteggio ponderato può nascondere una grave modalità di errore. Per esempio, un modello con una qualità media eccellente ma frequenti chiamate agli strumenti malformate può essere inadatto a un flusso di lavoro automatizzato. Un modello più lento può essere economicamente preferibile se le sue risposte riducono la costosa revisione umana.
Utilizzate un processo champion-and-challenger: mantenete un percorso attualmente approvato, testate le alternative sullo stesso corpus e promuovete un challenger solo quando supera soglie esplicite di qualità e operatività. Le affermazioni riportate dai provider dovrebbero essere trattate come input per un piano di test, non come prova che un modello si comporterà in modo analogo nel vostro ambiente.
3. Architettura: rendere sostituibile la scelta del modello
Il routing diventa costoso quando le ipotesi specifiche del modello si propagano in tutta un’applicazione. Un design resiliente separa l’attività aziendale dalla chiamata al provider.
Definite un contratto interno per le capacità. Potrebbe specificare che un’operazione di «classificazione» restituisce uno schema fisso, campi relativi alla confidenza o all’astensione, un identificatore del modello e un identificatore di tracciamento. Un’operazione di «stesura della risposta» potrebbe specificare vincoli sul tono, requisiti relativi alle citazioni e un budget massimo di latenza. Gli adattatori dei provider traducono quindi quel contratto nelle singole API.
Mantenete sotto controllo versione prompt, schemi, definizioni degli strumenti, regole di sicurezza e policy di routing. Registrate quale snapshot del modello e quale provider hanno gestito ogni richiesta. Conservate informazioni sufficienti per riprodurre una decisione senza trattenere inutilmente contenuti sensibili degli utenti.
Progettate deliberatamente i fallback. Un fallback potrebbe essere un altro provider, un modello più piccolo, un flusso di lavoro in coda o un percorso di revisione umana. Non dovrebbe cambiare silenziosamente il significato dell’attività. Se l’output strutturato è obbligatorio, il fallback deve supportare lo stesso contratto oppure attivare un’escalation controllata.
4. Governance: decidere quando non effettuare il routing automaticamente
Alcune richieste non dovrebbero essere inviate al modello disponibile più economico, né ad alcun modello esterno. La policy di routing deve prevedere regole di esclusione per dati riservati, decisioni ad alto impatto, lingue non supportate, contesti insolitamente lunghi o azioni che richiedono un passaggio di approvazione umana.
I team dovrebbero inoltre distinguere tra un modello tecnicamente disponibile e un modello approvato per un determinato utilizzo. I requisiti di approvvigionamento e legali possono variare a seconda dell’unità aziendale. Un modello può essere eccellente in una valutazione e tuttavia inutilizzabile per un flusso di lavoro i cui termini di gestione dei dati non sono compatibili con l’organizzazione.
Una tabella pratica per il routing
Una policy iniziale può essere semplice ed esplicita:
| Classe dell’attività | Obiettivo principale | Possibile percorso | Criterio di escalation |
|---|---|---|---|
| Estrazione ad alto volume | Schema valido e basso costo unitario | Modello di piccole o medie dimensioni con rigorosa convalida dell’output | Errore dello schema o bassa confidenza |
| Analisi complessa | Qualità e gestione delle evidenze | Modello più avanzato con un budget di latenza maggiore | Evidenze mancanti, ambiguità o segnalazione di policy |
| Assistenza interattiva | Rapidità percepita della risposta | Modello a bassa latenza, eventualmente seguito da un perfezionamento | Bassa fiducia o richiesta dell’utente di maggiore profondità |
| Flusso di lavoro sensibile | Gestione dei dati approvata e verificabilità | Fornitore approvato contrattualmente o implementazione controllata | Dati, azione o giurisdizione non approvati |
La tabella esatta varierà da un’organizzazione all’altra. Il punto importante è che le regole di instradamento dovrebbero essere leggibili dagli stakeholder di prodotto, sicurezza, finanza e ingegneria, non sepolte in un’istruzione condizionale.
Cosa significa per chi sta costruendo la propria carriera
I candidati più forti per questo lavoro combineranno diversi tipi di competenza. Dovranno comprendere abbastanza di machine learning da ragionare su capacità e degrado; abbastanza di ingegneria dei sistemi da gestire latenza, ritentativi, limiti di frequenza e modalità di errore; abbastanza di finanza da modellare il costo totale; e abbastanza di approvvigionamento e governance da valutare gli impegni e le restrizioni dei fornitori.
Dovranno inoltre sentirsi a proprio agio nello scrivere documenti decisionali. Un documento utile spiega perché è stato selezionato un percorso, quali evidenze lo supportano, quali rischi restano e quale evento dovrebbe far scattare una nuova valutazione. Questo è più prezioso che memorizzare gli ultimi nomi dei modelli, perché nomi e prezzi dei modelli continueranno a cambiare.
Un progetto portfolio compatto potrebbe dimostrare questa competenza senza richiedere un ampio sistema in produzione. Scegli un carico di lavoro, crea un set di valutazione con dati oscurati, collega tre fornitori di modelli o modelli locali tramite un’interfaccia comune e confronta qualità, validità dello schema, percentili di latenza, tassi di errore e costo mensile stimato a diversi volumi. Aggiungi regole di policy per gli input sensibili e un percorso di fallback. Pubblica la metodologia di test e i limiti.
Sii preciso su ciò che il progetto dimostra. Non dimostra che un modello sia universalmente il migliore. Dimostra che sai trasformare un problema ambiguo di scelta del modello in una policy operativa misurabile.
Il segnale per la carriera
L’instradamento dei modelli sta diventando strategicamente importante perché l’intelligenza non è più una singola dipendenza fissa. È un portafoglio di servizi con diversi compromessi e un’economia in evoluzione. I team che trattano questo portafoglio come un’infrastruttura intercambiabile possono ridurre i costi, ma possono anche creare problemi nascosti di qualità, conformità e affidabilità. I team che lo trattano come un impegno permanente verso un singolo modello possono perdere opportunità migliori.
La disciplina emergente si colloca tra questi due estremi: abbastanza astratta da consentire il cambio di fornitore, abbastanza specifica da preservare la qualità del compito e abbastanza basata sulle evidenze da giustificare la scelta. Questa è l’opportunità professionale dell’instradamento dei modelli: non scegliere un’API una volta, ma costruire il sistema decisionale che continui a scegliere bene.
Tom Whitfield è il redattore umano responsabile di AI Career Brief, che tratta competenze, ruoli e mosse strategiche per lavorare nell’era dell’IA.
