Gemini Decision vs Gemini Decision 1 : l’un est un nom, l’autre un ID de modèle

Recherchez Gemini Decision et vous trouverez des articles sur le lancement, une entrée dans un classement, une ligne de tarification et une référence d’API, tous employant des termes légèrement différents pour la même chose. Recherchez Gemini Decision 1 et vous trouverez l’identifiant de modèle qui fonctionne réellement. Les deux chaînes diffèrent d’un seul caractère et se comportent complètement différemment dans le code : l’une est le nom que les gens donnent au produit, et l’autre est la seule valeur que POST /v1beta/decisions acceptera. Si vous avez passé un après-midi sur une 404 à vous demander pourquoi un modèle qui existe manifestement est introuvable, voici l’article qui vous aurait épargné cela.

La confusion n’est la faute de personne en particulier. Google a livré un modèle, un point de terminaison et un nom de famille dans la même version, le 11 novembre 2026, et la façon naturelle d’écrire sur ces trois éléments consiste à les raccourcir. Ce raccourci fonctionne dans un texte courant et échoue dans un corps de requête, et c’est dans l’écart entre ces deux faits que proviendront la plupart des tickets d’assistance de cette catégorie au cours du mois à venir.

À quoi correspondent les deux noms

Commencez par le mappage, car tout le reste en découle.

• Gemini Decision — un nom de produit. Il désigne la gamme de modèles décisionnels et, dans la documentation de Google, il apparaît comme libellé de famille dans le texte courant, dans le titre de la fiche modèle et dans des phrases telles que « disponible uniquement avec Gemini Decision ». Ce n'est pas un identifiant de modèle, aucun alias ne lui correspond, et le transmettre comme modèle renvoie une erreur de modèle inconnu au lieu de basculer vers le membre le plus récent de la famille.

• Gemini Decision 1 — le modèle, et l'id gemini-decision-1. C'est la valeur qui fonctionne. C'est le seul modèle servi par l'API Decisions, et la documentation le précise explicitement : l'endpoint n'est disponible qu'avec Gemini Decision 1.

Deux noms, un seul modèle, et aucun alias entre eux. C’est cette dernière partie qui est inhabituelle. La plupart des familles de modèles G​oogle proposent un alias évolutif et un id épinglé — une forme -latest pour les prototypes et une forme datée ou numérotée pour la production. Celle-ci ne propose que la forme épinglée, donc tout chemin de code construit sur l’hypothèse que les familles ont une tête flottante échouera ici plutôt que de suivre silencieusement une nouvelle version.

Là où le second nom ne cesse d’apparaître

La raison pour laquelle l’ambiguïté a la vie dure, c’est que trois systèmes distincts décrivent ce modèle et qu’aucun d’entre eux ne partage de convention de nommage.

La page de tarification le répertorie sous le nom propre du modèle, avec un tarif et une note indiquant que la sortie n’est pas applicable. La référence de l’API décrit le point de terminaison et nomme le modèle dans la phrase de disponibilité plutôt que dans un tableau de modèles. Le classement indépendant qui l’évalue utilise le nom lisible dans sa ligne et son graphique. Aucun d’eux n’est erroné, et aucun n’est un identifiant de modèle ; copier depuis l’un d’eux dans le corps d’une requête produit donc la même erreur.

Il existe une quatrième source de variation qui comptera davantage avec le temps : les écrits d’autres personnes. Les articles de lancement, les tutoriels et les réponses de forum raccourcissent tous le nom, et certains le réduisent à quelque chose qui ressemble à un id — en minuscules, avec des traits d’union, plausible. La solution consiste à ne faire confiance à aucun d’entre eux. Interrogez l’endpoint.

Comment vérifier ce qu’une clé donnée peut réellement appeler

Avant d'écrire une requête, listez les modèles auxquels la clé donne droit. L'appel standard list-models de l'API Generative Language renvoie les modèles disponibles pour votre projet avec leurs identifiants, et l'exécuter une fois règle définitivement la question pour cette clé.

Si gemini-decision-1 apparaît, vous y avez accès, et c’est cette chaîne exacte qui doit figurer dans la requête. S’il n’apparaît pas, le problème tient à l’habilitation ou à la région, pas à l’orthographe, et aucun changement de nom n’y remédiera. Ce que vous ne trouverez pas dans cette liste, c’est une entrée appelée gemini-decision, car ce modèle n’existe pas.

Le deuxième contrôle porte sur la réponse. Une réponse de décision réussie identifie le modèle qui l’a servie, de sorte qu’un pipeline qui journalise le champ modèle aux côtés de son propre identifiant de requête peut répondre à « quel modèle a produit cette réponse » des mois plus tard sans relire la configuration. Cela ressemble à de la maintenance de routine jusqu’à la première fois où quelqu’un demande pourquoi une décision a changé et où la réponse honnête est qu’un alias a été déplacé.

Les trois erreurs que cette ambiguïté provoque réellement

• Le 404 « modèle inconnu ». L'évidence même. gemini-decision dans le corps de la requête renvoie une erreur qui ressemble à un problème de permissions, mais qui n'en est pas un. Si l'erreur mentionne le modèle plutôt que le projet, vérifiez la chaîne avant de vérifier le compte de facturation.

• L’hypothèse silencieuse d’alias. Plus difficile à repérer. Une équipe qui a intériorisé les conventions -latest écrit une configuration avec un nom de famille et une étape de résolution, et l’étape de résolution renvoie discrètement le nom de famille littéral lorsqu’aucun alias n’existe. La défaillance n’apparaît alors qu’à la première requête réelle plutôt qu’au déploiement, ce qui est le pire moment possible.

• L’hypothèse d’un point de terminaison erroné. Plus subtil encore, car le modèle existe et le nom est correct : gemini-decision-1 envoyé à un point de terminaison generate-content ordinaire échoue toujours. Le modèle n’est pas du tout appelable de cette manière. C’est une cible de probabilités uniquement sur le point de terminaison decisions, et une requête qui lui demande de la prose demande quelque chose qu’il ne produit pas. Toute bibliothèque cliente qui utilise par défaut les complétions de chat aura besoin d’un chemin explicite.

Ce que cela dit du modèle, pas seulement de son nom

Le nommage est le symptôme de la véritable décision de conception : il ne s’agit pas d’un modèle de chat avec un format de sortie différent. Un modèle de chat renvoie du texte, si bien que son identifiant peut être échangé librement entre fournisseurs, proxys et passerelles qui parlent tous le même schéma. Un modèle qui renvoie des probabilités calibrées sur vos propres questions typées n’a pas de schéma commun de ce type, et son identifiant est lié à un seul point de terminaison avec une seule forme de requête.

C’est pourquoi la famille n’a pas encore d’alias flottant ni de second membre : il n’y a rien avec quoi être compatible. Cela explique aussi pourquoi le modèle ne peut pas simplement être ajouté à un routeur généraliste. OrcaRouter ne prend pas en charge gemini-decision-1, car un point de terminaison uniquement de probabilités n’est pas une cible chat-completions, et le placer derrière une clé qui parle ce schéma serait une promesse que la couche de routage ne peut pas tenir. Ce que nous prenons en charge dans l’espace de décision, c’est typesafe/jev-1.14 de TypeSafe, un modèle de décision appelable via la même interface que tout le reste du catalogue.

La partie d'un pipeline de décision que le routeur sert bel et bien est celle de la rédaction — l'appel génératif qui produit la réponse candidate ou la grille d'évaluation que le scoreur évalue ensuite. Cet appel s'exécute sur plus de 200 modèles via un seul endpoint, avec le prix catalogue du fournisseur répercuté à 0 % de marge, et c'est l'appel où changer de fournisseur est un changement de configuration plutôt qu'une réécriture. L'appel de scoring, en revanche, est lié à un seul endpoint par conception, et une architecture honnête le traite comme une dépendance fixe plutôt que comme quelque chose à contourner par le routage.

Si vous devez choisir entre les deux chaînes d’un formulaire

Il existe une version de cette question qui ne porte pas du tout sur les identifiants, et il vaut la peine d’y répondre directement parce que la formulation y invite : quelqu’un qui compare « G​emini Decision » à « G​emini Decision 1 » peut croire qu’il a affaire à deux produits, un ancien et un plus récent, et vouloir savoir lequel adopter. Il n’y en a qu’un. Rien appelé G​emini Decision n’est sorti avant G​emini Decision 1, et le nom plus court est l’étiquette de famille d’une famille qui ne compte actuellement qu’un seul membre.

La conséquence concrète est que tout tableau comparatif, test ou benchmark que vous trouvez et qui les répertorie comme deux entrées distinctes décrit en réalité deux fois le même modèle. Deux lignes, un seul modèle, un seul prix. Si les deux lignes divergent sur un chiffre, c'est que l'une des deux est obsolète, et non qu'elles mesurent des choses différentes.

L'essentiel

Utilisez gemini-decision-1 dans chaque corps de requête, chemin d’endpoint et valeur de configuration, et n’utilisez « G​emini Decision » que là où un humain le lit. Il n’y a aucun alias sur lequel se replier, aucun second modèle caché derrière le nom plus court, et aucun chemin chat-completions vers le nom plus long. Le coût de se tromper est faible — un 404, un après-midi de confusion — mais le coût de supposer qu’un alias existe est plus élevé, car cette erreur passe la revue et échoue en production. Verrouillez l’identifiant, journalisez le modèle que la réponse nomme, et traitez le nom de famille comme de la prose.