Gemini Decision vs Gemini Decision 1: Uno è un nome, l'altro è un ID di modello

Cerca Gemini Decision e troverai la copertura del lancio, una voce in classifica, una riga di prezzo e un riferimento API, tutti con parole leggermente diverse per la stessa cosa. Cerca Gemini Decision 1 e troverai l'ID del modello che funziona davvero. Le due stringhe differiscono per un solo carattere e si comportano in modo completamente diverso nel codice: una è il nome con cui le persone chiamano il prodotto, l'altra è l'unico valore che POST /v1beta/decisions accetterà. Se hai passato un pomeriggio su un 404 chiedendoti perché un modello che esiste chiaramente non si riesca a trovare, questo è l'articolo che ti avrebbe salvato.

La confusione non è un errore di nessuno in particolare. G​oogle ha rilasciato un modello, un endpoint e un nome di famiglia nella stessa release l'11 novembre 2026, e il modo naturale di scrivere di tutti e tre è abbreviarli. L'abbreviazione funziona nella prosa e fallisce nel corpo di una richiesta, e il divario tra questi due fatti è all'origine della maggior parte dei ticket di supporto di questa categoria che arriveranno nel corso del prossimo mese.

A cosa corrispondono i due nomi

Inizia con la mappatura, perché tutto il resto ne consegue.

• Gemini Decision — un nome di prodotto. Indica la linea di modelli decisionali e, nella documentazione ufficiale di Google, compare come etichetta della famiglia nel testo, nell'intestazione della scheda del modello e in frasi come "disponibile solo con Gemini Decision". Non è un ID di modello, non esiste alcun alias dietro di esso e, se lo si passa come modello, restituisce un errore di modello sconosciuto invece di ricadere sul membro più recente della famiglia.

• Gemini Decision 1 — il modello, e l'id gemini-decision-1. Questo è il valore che funziona. È l'unico modello servito dall'API Decisions, e la documentazione lo afferma esplicitamente: l'endpoint è disponibile solo con Gemini Decision 1.

Due nomi, un modello e nessun alias tra loro. Quest'ultima parte è l'elemento insolito. La maggior parte delle famiglie di modelli Google offre un alias dinamico e un id fisso — una forma -latest per i prototipi e una forma datata o numerata per la produzione. Questa offre solo la forma fissa, quindi qualsiasi percorso di codice basato sul presupposto che le famiglie abbiano un riferimento fluttuante fallirà qui anziché seguire silenziosamente una nuova versione.

Dove il secondo nome continua ad apparire

La ragione per cui l'ambiguità tiene è che tre sistemi distinti descrivono questo modello e nessuno di essi condivide una convenzione di denominazione.

{{1}}La pagina dei prezzi lo elenca con il nome proprio del modello{{/1}}, insieme a una tariffa e a una nota che {{2}}l'output non è applicabile{{/2}}. {{3}}Il riferimento API descrive l'endpoint{{/3}} e nomina il modello nella {{4}}frase di disponibilità{{/4}} anziché in una tabella dei modelli. {{5}}La classifica indipendente che lo sottopone a benchmark usa il nome leggibile{{/5}} nella sua riga e nel suo grafico. {{6}}Nessuno di questi è sbagliato{{/6}}, e {{7}}nessuno di essi è un id di modello{{/7}}, quindi copiare da uno qualsiasi di essi in un corpo della richiesta produce lo stesso errore.

C’è una quarta fonte di variazione che conterà sempre di più con il passare del tempo: gli scritti di altre persone. Gli articoli sul lancio, i tutorial e le risposte nei forum abbreviano tutti il nome, e alcuni lo riducono a qualcosa che sembra un id: minuscolo, con trattini, plausibile. La soluzione non è fidarsi di nessuno di loro. Chiedi all’endpoint.

Come verificare cosa può effettivamente chiamare una determinata chiave

Prima di scrivere una richiesta, elenca i modelli a cui la chiave ha diritto. La chiamata standard list-models sull'API Generative Language restituisce i modelli disponibili per il tuo progetto con i relativi ID e, eseguendola una volta, risolve definitivamente la questione per quella chiave.

Se compare gemini-decision-1, hai accesso, e quella stringa esatta è ciò che va nella richiesta. Se non compare, il problema riguarda l'abilitazione o la regione, non l'ortografia, e nessun cambio di nome potrà aiutare. Quello che non troverai in quell'elenco è una voce chiamata gemini-decision, perché non esiste un modello del genere.

Il secondo controllo riguarda la risposta. Una risposta decisionale andata a buon fine identifica il modello che l'ha servita, quindi una pipeline che registra il campo model insieme al proprio request id può rispondere a "quale modello ha prodotto questa risposta" mesi dopo senza rileggere la configurazione. Sembra manutenzione ordinaria finché non arriva la prima volta in cui qualcuno chiede perché una decisione è cambiata e la risposta onesta è che un alias è stato spostato.

I tre errori che questa ambiguità causa effettivamente

• Il 404 del modello sconosciuto. Quello ovvio. gemini-decision nel corpo della richiesta restituisce un errore che sembra un problema di autorizzazioni e non lo è. Se l'errore menziona il modello invece del progetto, controlla la stringa prima di controllare l'account di fatturazione.

• L'assunzione silenziosa dell'alias. Più difficile da individuare. Un team che ha interiorizzato le convenzioni -latest scrive una configurazione con un nome di famiglia e un passaggio di risoluzione, e il passaggio di risoluzione restituisce silenziosamente il nome di famiglia letterale quando non esiste alcun alias. Il guasto si manifesta quindi alla prima richiesta reale anziché al deploy, che è il momento peggiore possibile.

• L'assunzione dell'endpoint errato. Ancora più sottile, perché il modello esiste e il nome è corretto: gemini-decision-1 inviato a un normale endpoint generate-content fallisce comunque. Il modello non è affatto richiamabile in quel modo. È un target che restituisce solo probabilità sull'endpoint decisions, e una richiesta che gli chiede prosa sta chiedendo qualcosa che non produce. Qualsiasi libreria client che usa per impostazione predefinita chat completions avrà bisogno di un percorso esplicito.

Cosa dice questo sul modello, non solo il suo nome

La denominazione è un sintomo della vera decisione di progettazione, ovvero che questo non è un modello di chat con un formato di output diverso. Un modello di chat restituisce testo, quindi il suo id può essere scambiato liberamente tra fornitori, proxy e gateway che parlano tutti lo stesso schema. Un modello che restituisce probabilità calibrate sulle tue domande tipizzate non ha uno schema comune di questo tipo, e l'id è vincolato a un solo endpoint con una sola forma di richiesta.

Ecco perché la famiglia non ha ancora un alias fluttuante e nessun secondo membro: non c'è nulla con cui essere compatibili. Spiega anche perché il modello non può essere semplicemente aggiunto a un router generico. OrcaRouter non include gemini-decision-1, perché un endpoint che fornisce solo probabilità non è una destinazione chat-completions, e metterlo dietro una chiave che parla quello schema sarebbe una promessa che il livello di routing non può mantenere. Ciò che invece includiamo nello spazio decisionale è typesafe/jev-1.14 di TypeSafe, un modello decisionale richiamabile tramite la stessa interfaccia di tutto il resto nel catalogo.

La parte di una pipeline decisionale che il router serve davvero è la metà dedicata alla stesura — la chiamata generativa che produce la risposta candidata o la rubrica che il valutatore poi valuta. Tale chiamata viene eseguita su oltre 200 modelli su un unico endpoint, con il prezzo di listino del fornitore trasferito a un ricarico dello 0%, ed è la chiamata in cui cambiare fornitore è una modifica di configurazione anziché una riscrittura. La chiamata di scoring, al contrario, è vincolata a un unico endpoint per progettazione, e l'architettura onesta la tratta come una dipendenza fissa anziché come qualcosa da aggirare tramite il routing.

Se stai scegliendo tra le due stringhe di un modulo

Esiste una versione di questa domanda che non riguarda affatto gli identificatori, e vale la pena rispondere direttamente perché la formulazione lo invita: chi confronta "G​emini Decision" con "G​emini Decision 1" potrebbe credere di trovarsi davanti a due prodotti, uno più vecchio e uno più recente, e voler sapere quale adottare. Ce n'è solo uno. Nulla chiamato G​emini Decision è stato rilasciato prima di G​emini Decision 1, e il nome più breve è l'etichetta della famiglia per una famiglia che attualmente ha un solo membro.

La conseguenza pratica è che qualsiasi tabella comparativa, recensione o benchmark in cui entrambi compaiano come voci separate sta descrivendo due volte lo stesso modello. Due righe, un modello, un prezzo. Se le due righe non concordano su un numero, una delle due è obsoleta anziché misurare qualcosa di diverso.

In definitiva

Usa gemini-decision-1 in ogni corpo della richiesta, percorso dell'endpoint e valore di configurazione, e usa "G​emini Decision" solo dove lo legge una persona. Non c'è alcun alias su cui ripiegare, nessun secondo modello nascosto dietro il nome più corto e nessun percorso chat-completions verso quello più lungo. Il costo di sbagliare è piccolo — un 404, un pomeriggio di confusione — ma il costo di dare per scontato che esista un alias è maggiore, perché quell'errore sopravvive alla revisione e fallisce in produzione. Fissa l'id, registra nel log il modello indicato nella risposta e tratta il nome della famiglia come prosa.