Chiediamo all’AI di analizzare un documento.
Il sistema decide quale modello deve leggerlo, quale deve interpretarlo e quale deve controllare il risultato.
A noi arriva una sola risposta.
Delegare questa scelta può semplificare il lavoro. Può anche lasciare meno visibile una decisione che incide sul risultato: quale capacità abbiamo utilizzato per ciascun passaggio e secondo quali priorità?
Una novità concreta: modelli diversi nella stessa sessione
Il 12 novembre 2026 Google ha presentato Gemini 4 Hydrogen e annunciato Orchestrator in Google Antigravity. Nell’annuncio descrive un sistema che può passare dinamicamente tra modelli come Carbon e Hydrogen durante la stessa sessione. L’obiettivo dichiarato è combinare capacità di ragionamento ed efficienza nell’esecuzione. [1]
La notizia offre uno spunto per ragionare sul controllo. Questo articolo non è una prova del prodotto: non abbiamo misurato sul campo la qualità delle sue scelte e non assumiamo che tutte le funzioni proposte qui siano disponibili nella sua interfaccia.
Che cosa significa scegliere automaticamente un modello
Il routing dei modelli è l’instradamento di una richiesta verso uno dei modelli disponibili. Nel linguaggio quotidiano possiamo dire che «sceglie l’AI», ma la decisione appartiene a un sistema: può coinvolgere regole, configurazioni o un componente addestrato per selezionare il modello.
Non è necessariamente lo stesso modello che, mentre risponde, decide di sostituirsi con un altro. Non coincide nemmeno con il lavoro di più agenti: scegliere a chi assegnare una richiesta e coordinare più attività sono problemi collegati, ma distinti.
La ricerca affronta il tema da prima di questo annuncio. RouteLLM, presentato alla International Conference on Learning Representations (ICLR) nel 2025, studia router addestrati usando dati di preferenza per scegliere tra modelli con capacità e costi differenti. I risultati riguardano le valutazioni dello studio, non certificano qualunque sistema di selezione automatica. [2]
Il modello migliore rispetto a quale obiettivo?
«Scegli automaticamente il modello migliore» lascia una domanda aperta. Migliore per ottenere una risposta rapida, per ridurre il costo oppure per gestire un passaggio difficile?
Un esempio pubblico della distinzione si trova nel riferimento ModelRoutingPreference di Google Cloud: prevede preferenze per la qualità, per il costo o per un bilanciamento tra i due. È un riferimento diverso dall’annuncio di Antigravity; non dimostra che Orchestrator esponga le stesse impostazioni. [3]
Nel lavoro aziendale proporrei di aggiungere un criterio: le conseguenze di un errore. Una richiesta breve può riguardare un’informazione decisiva; una richiesta lunga può essere una semplice riformattazione. La lunghezza del messaggio, da sola, non descrive il rischio del compito.
Il requisito dovrebbe essere definito prima della scelta: quali errori renderebbero inutilizzabile il risultato? Quanto tempo è accettabile? Quali modelli e servizi sono ammessi per quei dati?
Un esempio: due Excel e un consuntivo
Immaginiamo di chiedere a un assistente di unire due fogli mensili e preparare un consuntivo. Uno dei file contiene un movimento duplicato e un costo senza importo. È un esempio didattico, non un test di Orchestrator.
Il sistema potrebbe distribuire lettura, analisi e stesura su modelli diversi. La suddivisione può essere utile, purché il problema rilevato resti visibile nei passaggi successivi.
| Passaggio | Risultato necessario | Controllo proposto |
|---|---|---|
| Acquisire i fogli | Identificare righe, colonne e importi mancanti. | Confrontare i dati acquisiti con gli originali, usando controlli deterministici dove possibile. |
| Trattare le anomalie | Distinguere un duplicato da due movimenti reali; non trasformare il valore mancante in zero. | Applicare regole concordate o chiedere la decisione mancante prima di consolidare. |
| Calcolare e spiegare | Produrre totali coerenti e una relazione che segnali il risultato ancora parziale. | Verificare i calcoli con formule o script e controllare che il testo conservi le limitazioni. |
Il fallimento può rimanere nascosto se il prospetto appare completo ma la relazione perde l’avvertenza sul costo sconosciuto. Non basta sapere che sono stati usati più modelli, né che uno di essi è considerato particolarmente capace.
Occorre verificare il requisito lungo l’intero percorso. Cambiare modello non risolve un’informazione mancante e non autorizza a inventarla.
Che cosa dovremmo poter ricostruire
Per le attività rilevanti proporrei una traccia essenziale: modello e versione effettivamente utilizzati, configurazione applicata, fase svolta, eventuale sostituzione e verifiche eseguite. Se uno di questi dati non è disponibile, il limite dovrebbe rimanere esplicito.
La spiegazione generata dall’assistente non sostituisce il registro dell’esecuzione. «Ho scelto il modello più adatto» è una dichiarazione; per sapere quale modello abbia davvero lavorato occorre una prova fornita dall’ambiente che gestisce le richieste.
Questo non richiede di conservare indiscriminatamente documenti e conversazioni nei log. Proporrei di registrare i riferimenti necessari alla ricostruzione, con accessi e tempi di conservazione appropriati, evitando credenziali e contenuti riservati superflui.
Il costo va valutato sul lavoro completato
Un costo inferiore per una singola chiamata è soltanto una parte della valutazione. Per decidere se il processo convenga, confronterei anche il numero di tentativi, il tempo di verifica e le correzioni necessarie.
Non presumo che un modello più economico generi più errori, o che uno più costoso dia sempre risultati migliori. È una relazione da verificare sul compito concreto, con il metodo di fatturazione effettivo: un abbonamento, una quota d’uso e il consumo fatturato per chiamata non sono la stessa cosa.
Nel caso dei due Excel, il confronto utile sarebbe tra elaborazioni che rispettano gli stessi criteri: dati mancanti segnalati, duplicati trattati correttamente e calcoli verificati. Una relazione più veloce ma incompleta non soddisfa quel requisito.
Delegare entro confini dichiarati
Prima di affidare la selezione a un sistema, proporrei poche decisioni esplicite: modelli ammessi, vincoli sui dati, priorità tra qualità e tempi, limiti di spesa e casi nei quali fermarsi o richiedere una revisione.
Le istruzioni del progetto possono descrivere questi criteri. La disponibilità dei modelli, i permessi e gli eventuali blocchi devono però essere governati anche dalla configurazione e dal codice. Se il modello ammesso non è disponibile, il comportamento previsto deve essere chiaro: attendere, fermarsi o usare un’alternativa già autorizzata.
Per valutare il risultato userei casi rappresentativi con requisiti verificabili, mantenendo traccia della configurazione. Un cambiamento rilevante dei modelli disponibili o dei criteri di selezione richiederebbe un nuovo confronto. Questa è una proposta di metodo, non la descrizione di una funzione verificata in Antigravity.
La scelta automatica può togliere all’utente un compito ripetitivo. I criteri che rendono accettabile quella scelta devono però restare verificabili.
Il punto da cui partirei è questo:
- sappiamo quali compromessi abbiamo autorizzato, e abbiamo prove sufficienti per giudicare il risultato?
Fonti consultate
Fonti pubbliche consultate il 13 novembre 2026. Le funzioni annunciate sono attribuite ai rispettivi produttori; lo scenario Excel e le proposte di controllo sono elaborazioni dell’autore.
- Koray Kavukcuoglu, Google, Introducing Gemini 4 Hydrogen, 12 novembre 2026, pagina aggiornata il 13 novembre 2026. Annuncio di Hydrogen e Orchestrator in Google Antigravity.
- Isaac Ong e altri, RouteLLM: Learning to Route LLMs from Preference Data, International Conference on Learning Representations, 2025. Ricerca sull’instradamento tra modelli, distinta dai prodotti Google.
- Google Cloud, ModelRoutingPreference, riferimento alle preferenze di instradamento. Non è documentazione delle impostazioni di Orchestrator.
Nessun commento:
Posta un commento