Gemini 4 Argon : qui vérifie une sortie d’un million de tokens ?

Google a annoncé Gemini 4 Argon le 30 septembre, avec un plafond de sortie d’un million de tokens, contre 64K auparavant. L’annonce ne précise pas ici si les tokens de raisonnement sont comptabilisés dans ce plafond. C’est une limite annoncée, pas la preuve d’un million de tokens de travail final et utile. [1]

Notre argument est qu’un budget de génération accru rend la conception de l’acceptation plus importante. Une équipe pourra peut-être demander une modification plus vaste, mais quelqu’un devra toujours déterminer ce qui a été terminé, ce qui a été vérifié et ce qui peut être mis en service en toute sécurité. Ces questions diffèrent de celle de la quantité qu’un modèle peut produire.

Prenons une migration hypothétique de dépôt de code. Une longue exécution pourrait produire du code, des tests, de la documentation et un journal des modifications. Davantage de sortie pourrait réduire les interruptions, mais aussi laisser davantage d’éléments à rapprocher. Le bénéfice dépend de la part de ces éléments qui devient une modification acceptée ; nous n’avons pas testé ce scénario avec Argon.

Avant une exécution, définissez le livrable et les preuves attendues : quels composants doivent changer, quels tests doivent réussir, quelles interfaces doivent rester compatibles et qui donne son accord. Une tâche doit pouvoir se terminer bien en dessous de son plafond de sortie. Épuiser le budget disponible n’est pas un critère d’achèvement.

Le même raisonnement s’applique à un dossier de recherche ou à un lot de contenus. Les citations doivent étayer les affirmations, les documents doivent être cohérents et les révisions doivent préserver le sens voulu. Une génération plus longue ne transforme pas une affirmation non étayée en preuve. Mesurez les résultats utilisables et vérifiés plutôt que de célébrer la longueur d’une transcription.

La page du modèle de Google indique 77,9 % sur DeepSWE v1.1 et 55,0 % sur FrontierSWE v2. Il s’agit d’évaluations de programmation différentes. Elles ne représentent pas un taux universel d’achèvement pour votre dépôt. Le tableau distingue également les plages de contexte de GraphWalks, qui concernent l’entrée, pas la longueur de la sortie. [2]

La méthodologie utilise 650 cas GraphWalks avec un contexte allant jusqu’à 128K et 200 entre 256K et un million. Les résultats d’Argon utilisent généralement le réglage de raisonnement le plus élevé et pass@1, avec des exceptions : OSWorld rapporte un score partiel hors ligne en retenant le meilleur de trois essais. Certains résultats comparatifs proviennent d’autres fournisseurs ou de classements. [3]

Nous n’avons trouvé dans cette méthodologie aucun test d’acceptation de bout en bout d’une sortie d’un million de tokens. C’est une limite des éléments examinés, pas une affirmation selon laquelle ce travail serait impossible. Les progrès aux évaluations justifient d’étudier des tâches précises ; ils ne dispensent pas de tester l’exactitude, les omissions et la reprise dans vos propres conditions.

Une approche pratique consiste à diviser l’acceptation en unités sans supposer que le modèle doit s’arrêter après chacune. Pour une migration, ces unités pourraient être un module, ses tests et ses preuves de compatibilité. Pour un lot éditorial, un article, ses sources et sa révision approuvée. Chaque unité nécessite un résultat identifiable.

Utilisez l’automatisation lorsque la réussite peut être vérifiée mécaniquement : contrôles de compilation, validation de schémas, détection de doublons ou inventaire des fichiers requis. Réservez la relecture humaine au sens, aux arbitrages importants et aux affirmations qu’un test mécanique ne peut trancher. Une compilation réussie répond à une question plus étroite que celle de la justesse de la modification demandée.

La vérification doit faire apparaître ce qui reste inachevé. Une passation utile liste les unités acceptées, les unités rejetées, les dépendances non résolues et le motif de fin de l’exécution. Sinon, un résumé final impressionnant peut masquer un travail partiel. La personne qui vérifie a besoin de preuves jointes au résultat, pas seulement de l’assurance du modèle que tout est terminé.

Un long travail nécessite des conditions d’arrêt explicites : une limite de temps, un plafond de coût, trop d’échecs répétés ou une décision exigeant une nouvelle autorisation. Ce sont des contrôles de processus recommandés ; nous n’affirmons pas qu’Argon propose une API particulière pour les appliquer.

Conservez un point de contrôle permettant une reprise avant les modifications importantes. Notez quelle sortie a été appliquée et laquelle est seulement proposée, pour qu’une exécution ultérieure ne répète pas une action et ne s’appuie pas sur un résultat non accepté. Si l’exécution échoue à mi-parcours, la reprise doit partir d’un état vérifié, pas de la dernière phrase optimiste.

Comptez le coût de la vérification et de la correction avec celui de la génération. Un modèle peut coûter moins cher par token tout en produisant davantage de travail à examiner. Comparez le temps et l’effort totaux par livrable accepté, y compris les exécutions ayant échoué. Le bon budget est celui qui permet un progrès fiable, pas la plus grande quantité de contenu généré.

Lors de la vérification, l’accès à Argon via Fairwind était réservé aux partenaires de confiance approuvés. Ce n’est pas un accès public général. Les équipes hors programme ne doivent pas supposer que la publication d’une page du modèle signifie qu’elles peuvent le déployer aujourd’hui. [4]

En attendant un accès auquel vous soyez éligible, préparez un petit jeu d’évaluation à partir de travaux terminés que vous avez le droit d’utiliser. Incluez des cas courants, des dépendances difficiles et des cas où la bonne réponse consiste à s’arrêter. Gardez le processus existant comme référence et définissez l’acceptation avant de voir la réponse du nouveau modèle.

Si l’accès devient disponible, comparez les mêmes tâches, outils et autorisations. Consignez l’acceptation dès la première exécution, les corrections, les omissions et l’effort de reprise. Un budget de sortie accru est intéressant s’il améliore ces éléments. Nous n’avons pas vérifié la disponibilité d’Argon via RouterShift et ne revendiquons ici aucune prise en charge par le produit.

L’objection la plus forte à l’ajout de points de contrôle est qu’ils peuvent interrompre un travail qui bénéficie d’une seule longue trajectoire. C’est un véritable arbitrage de conception. Les points de contrôle et la vérification n’imposent pas de fragmenter chaque génération ; un système peut préserver une longue exécution tout en produisant des livrables vérifiables au fil du travail.

Cet article ne permet pas d’établir si Argon améliorera un processus d’entreprise donné. Nous n’avons ni exécuté le modèle, ni reproduit ses évaluations, ni vérifié comment le raisonnement est comptabilisé dans le plafond de sortie. Notre recommandation est une méthode d’évaluation des travaux longs, pas une conclusion sur les performances.

L’évolution possible consiste à passer de la relecture d’une réponse à l’acceptation d’un ensemble de travaux. Davantage de capacité élargit ce qu’un modèle peut tenter. L’adoption professionnelle dépendra de la capacité des équipes à voir, vérifier et récupérer ce qu’il a réellement livré.