Ce que Google a réellement annoncé
Google décrit Gemini 3.6 Flash comme un modèle polyvalent avec de meilleures capacités de codage, de travail de connaissance et de performance multimodale. L’article de sortie indique 17 % de tokens de sortie en moins que 3.5 Flash sur l’Artificial Analysis Index, un prix plus bas de 1,50 $ par million de tokens d’entrée et 7,50 $ par million de tokens de sortie, ainsi que moins d’étapes de raisonnement et d’appels d’outils dans les travaux multi-étapes. Il s’agit de résultats généraux rapportés par l’éditeur ; ce ne sont pas des benchmarks Unreal.
La même annonce indique DeepSWE à 49 % contre 37 % pour 3.5 Flash, MLE Bench à 63,9 % contre 49,7 %, et OSWorld-Verified à 83,0 % contre 78,4 %. Une équipe Unreal peut utiliser ces signaux pour justifier des tests d’édition de code, de navigation dans les dépôts, de preuves visuelles et de flux de travail assistés par outils. L’équipe doit toutefois publier son propre jeu de tâches, la version du moteur, la configuration matérielle, le résultat attendu et les preuves d’échec.
Un modèle opérationnel utile Gemini-vers-Unreal
Gardez le modèle en dehors de la frontière d’autorité du jeu livré. Gemini peut proposer un diff, expliquer une trace de crash, classer des captures d’écran ou rédiger un plan de test. Le dépôt Unreal, le système de build, l’éditeur, les tests automatisés, le profiler, le build empaqueté et le relecteur humain décident de l’acceptation de la proposition.
Commencez par le plus petit contexte reproductible. Incluez la version d’Unreal, le module ou le nom du Blueprint, la plateforme cible, la source pertinente, l’erreur exacte ou la capture d’écran, le comportement attendu et les contrôles d’acceptation. Excluez les secrets, les fichiers de projet non liés, les assets privés et les données utilisateur. Demandez les hypothèses et les incertitudes séparément des changements proposés afin que les relecteurs puissent rejeter une prémisse non fondée sans écarter une analyse utile.
Grille d’évaluation pour un projet réel
- Identifie correctement le sous-système Unreal propriétaire avant de proposer une modification.
- N’intervient que sur les fichiers et les responsabilités Blueprint autorisés par la frontière de la tâche.
- Il produit une explication révisable, un plan de diff, une liste de tests et un point de rollback.
- Passe la compilation, les vérifications de l’éditeur, l’automatisation, les smoke tests du build empaqueté et la revue de la plateforme cible.
- Ne révèle aucun secret, n’invente pas d’API, ne fabrique pas de succès de test, ne confond pas la sortie navigateur avec un artefact Unreal natif.
- Améliore suffisamment le temps de completion mesuré ou la qualité de révision pour justifier le coût du modèle et de la revue humaine.