TL;DR
La Gemini Decision 1 de Google transforme une entrée multimodale partagée en choix structurés pour les workflows d’agents. L’opportunité n’est pas celle d’un chatbot moins cher : c’est le traitement par lots de petites décisions tout en mesurant les erreurs, l’escalade et le coût d’un résultat accepté.
Introduction
Le 11 novembre, Google a introduit l’API Gemini Decisions pour des décisions bornées telles que le routage, la sélection d’outils et les contrôles de politique. Elle accepte jusqu’à 1 000 questions indépendantes sur une entrée partagée contenant du texte, des images, de l’audio, de la vidéo et des PDF, avec une limite de 256K tokens. (Source : Google — Gemini Decisions API)
Le lancement élargit le marché des modèles de décision couvert dans notre analyse de l’API OpenAI Decisions. Il répond aussi à un problème pratique dans les workflows multi-agents évoqués dans notre analyse de Gemini Swarm : une décision de routage peut être petite, mais la répéter à chaque étape fait s’accumuler la latence, les erreurs et les coûts de contexte.
Ce que l’API renvoie réellement
Au lieu de rédiger une explication token par token, le modèle évalue des réponses prédéfinies en une seule passe avant. Google propose une probabilité oui/non, un choix parmi 2 à 255 options, et un score pondéré selon une grille ordonnée. Les applications reçoivent des scores de confiance et doivent décider quoi en faire. (Source : Google — Gemini Decisions API)
Pour une prise en charge en assurance, une seule requête pourrait combiner un formulaire scanné, des photos de dommages et un enregistrement d’appel, puis signaler les preuves manquantes, sélectionner une file d’attente et évaluer l’urgence. Il ne s’agit pas d’un endpoint d’extraction généraliste : si une question ultérieure dépend d’une réponse antérieure, le code applicatif ou un appel de suivi doit gérer cette dépendance. (Source : VentureBeat — Google’s Gemini Decision 1 model)
Le traitement par lots change le calcul des coûts
Google annonce 0,10 $ par million de tokens d’entrée et aucun frais sur les tokens de sortie. L’entrée partagée est facturée une fois par requête, tandis que chaque question ajoute ses propres tokens d’instruction et de critères. Un palier gratuit est disponible pour le prototypage. (Source : Google — Gemini Decisions API)
Prenons un dossier de 4 000 tokens et 20 contrôles ajoutant 50 tokens chacun. Au tarif publié, une requête groupée de 5 000 tokens coûte 0,50 $ pour 1 000 dossiers ; 20 requêtes distinctes qui renvoient le dossier coûtent 8,10 $ pour 1 000 dossiers. Cette illustration exclut les nouvelles tentatives, les appels en aval et la revue, et suppose que ce sont là les nombres de tokens facturés. (Source : VentureBeat — Google’s Gemini Decision 1 model)
Google rapporte une latence de bout en bout médiane de 150 à 250 ms pour ses contextes testés jusqu’à 16K tokens, avec peu de variation entre 1 et 100 questions. Ce n’est pas une garantie pour un contexte complet de 256K ou 1 000 questions ; le téléversement de médias, le réseau et le traitement applicatif nécessitent leurs propres mesures. (Source : Google — Gemini Decisions API)
Benchmarks et alternatives
Dans la comparaison de lancement de Google, VentureBeat rapporte des scores JevBench de 92,2 % pour Gemini Decision 1, 90,9 % pour GPT-6 Luna et 90,0 % pour Jev 1.14. Sur When2Call, Jev devance Gemini de 82,0 % à 79,9 %. Ce sont des résultats rapportés par les fournisseurs sur des tests particuliers, et non la garantie qu’un système routera mieux votre propre trafic. (Source : VentureBeat — Google’s Gemini Decision 1 model)
L’API Decisions d’OpenAI prend en charge jusqu’à 400 questions par requête et annonce le même tarif d’entrée de 0,10 $, plus un tarif distinct de lecture de cache pour le contexte réutilisé. Jev de TypeSafe annonce 0,042 $ par million de tokens d’entrée ; VentureBeat rapporte également une prise en charge des images sur opt-in. Les formats d’entrée, la mise en cache et les limites de questions comptent autant que le prix catalogue. (Sources : OpenAI — Decisions API; VentureBeat — Google’s Gemini Decision 1 model)
La frontière de la production
Une probabilité n’est pas une autorisation. Évaluez les modèles candidats en mode shadow sur du trafic réel étiqueté, y compris les cas rares et les entrées adverses. Fixez des seuils distincts pour chaque décision ; surveillez les erreurs parmi les cas traités automatiquement, le taux de revue humaine, la latence de queue et le coût total par résultat correct.
Conservez l’authentification, les plafonds de dépenses et l’approbation des écritures irréversibles dans du code déterministe. Pour les dossiers sensibles, comparez les conditions de données payantes et gratuites du fournisseur avant d’envoyer des éléments ; un classificateur rapide ne remplace ni la gouvernance ni la responsabilité humaine.
FAQ
Gemini Decision 1 peut-il rédiger un rapport ?
Il évalue des réponses bornées plutôt que de générer de la prose libre. Utilisez une étape de génération distincte pour un rapport.
Les questions peuvent-elles dépendre les unes des autres au sein d’un lot ?
Les questions sont indépendantes. Enchaînez les décisions dépendantes dans le code ou utilisez une autre requête.
Un score de confiance élevé garantit-il la sécurité ?
Non. Testez la calibration et les taux d’erreur sur votre propre trafic, et conservez des contrôles déterministes et une revue humaine pour les actions à conséquences.
La fenêtre de contexte complète est-elle couverte par la latence annoncée ?
Non. Les conditions de latence citées par Google couvrent des entrées jusqu’à 16K tokens, et non l’intégralité de la fenêtre de contexte annoncée.