Google's Gemini Flash résout 3 problèmes de mathématiques de niveau doctorat à l'aide d'un cadre de collaboration

Sans regarder le nom, vous penseriez certainement qu'il s'agit encore d'un modèle de haut niveau si puissant qu'il ne peut pas être publié publiquement, présentant un résultat exceptionnel :

Faire de la recherche : résoudre sept problèmes majeurs en mathématiques et en informatique en une seule fois, avec une preuve détaillée de 40 pages qui ne laisse aucune erreur détectable même par les systèmes d'audit les plus rigoureux ;

Ingénierie : J'ai écrit depuis zéro un simulateur CPU extrêmement réaliste, qui a non seulement démarré avec succès le système, mais présente une erreur de fonctionnement de 0,71 % ;

Écrire du code : j'ai optimisé le code principal des deux bibliothèques open source principales, Eigen et ParlayHash, et mes modifications ont été directement intégrées par les mainteneurs upstream.

Voici les résultats dévoilés par l'équipe Antigravity de Google le 27 août.

Dans l'article technique de Teamwork, l'équipe Antigravity de Google a présenté officiellement trois types de résultats : mathématiques, systèmes et open source.

De manière surprenante, ce n'est pas une énorme machine de calcul qui prend la relève, mais le petit modèle axé sur la rapidité et l'économie : Gemini 3.7 Flash.

Google officiel a même déclaré : il s'agit de la première fois qu'un modèle de niveau Flash réalise une recherche mathématique de niveau doctorat.

Pourquoi les modèles bon marché peuvent-ils surmonter des défis supérieurs ?

Le secret ne réside pas dans les paramètres, mais dans un cadre d'orchestration multi-agents appelé Teamwork.

Le véritable message que Google souhaite transmettre à l'industrie, c'est que ce n'est pas Flash qui s'est soudainement rendu intelligent, mais que la manière dont le travail est organisé a changé.

Qui est le protagoniste de ce relevé de notes ? Le long article technique de Google en donne une définition très rigoureuse :

7 résultats en mathématiques et en informatique théorique, initialement tous obtenus par Gemini 3.1 Pro en mode preuve longue de Teamwork.

Mais ce qui est impressionnant, c’est que trois de ces résultats concrets ont été entièrement reproduits par Gemini 3.7 Flash.

Ces trois éléments ne sont absolument pas des problèmes marginaux ajoutés pour faire du nombre : la construction de coreset pour l'approximation des sous-espaces ℓp, la borne inférieure sur la dimension de l'embedding de produit scalaire maximal, et la quantification de Hadamard réduisant directement la constante principale d'environ 5,93 fois.

Chacun de ces points est un problème ouvert reconnu dans le milieu académique.

Les quatre autres sont uniquement prises en charge par 3.1 Pro : la borne inférieure du conditionnement pour l'optimisation convexe creuse, la borne inférieure approchée optimale pour la factorisation matricielle par préfixe, le problème des cycles de Knuth, ainsi que le problème de la distance unitaire d'Erdős reproductible en mode hors ligne.

De plus, ce score record de 71 % sur l'évaluation TCSBench, qui a battu le précédent record interne de Google, a été obtenu grâce à la combinaison puissante de 3.7 Flash et 3.1 Pro, dépassant directement le précédent record de 67,7 % établi par 3.6 Flash associé à 3.1 Pro.

Parmi ceux-ci, le signal véritablement à surveiller est :

Si la structure de l’architecture est correctement établie, des modèles légers comme Flash peuvent parfaitement reproduire les recherches menées avec des modèles phares.

Cela suffit à élargir notre compréhension des capacités des petits modèles.

Teamwork est un cadre d'orchestration multi-agents développé par l'équipe Antigravity.

Il suffit de taper /teamwork-preview, et Gemini lira le prompt, choisira automatiquement le mode, et formera immédiatement un « conseil d'experts IA » qui fonctionnera pendant plusieurs heures, voire plusieurs jours.

Les résultats mathématiques mentionnés précédemment proviennent tous du mode Long Proof.

Son concept de conception est extrêmement contre-intuitif : au lieu d'accumuler des paramètres, il repose sur le fait de rassembler un groupe de Flash pour qu'ils s'entre-aiguisent, se contredisent et ciblent leurs points faibles.

Comment ces IA se réunissent-elles exactement ? Décomposé, cela fait au total quatre étapes :

Étape 1 : La « recherche de stratégie de concurrence » follement intensifiée.

Le système fait simultanément émerger plusieurs solutions candidates et attribue à chaque solution un « spécialiste de la contradiction » dédié, dont le seul KPI est de réfuter cette solution.

Il est intéressant de noter que les propositions vigoureusement critiquées ne sont pas directement jetées à la poubelle, mais restent dans le processus malgré les nombreuses opinions opposées.

Après tout, dans un chemin sans issue, on trouve souvent l'inspiration qui peut sauver des vies.

Étape 2 : Suivez le guide, « décomposez avec précision ».

Une fois une stratégie fiable sélectionnée, le système la décompose en une série de sous-problèmes interdépendants, qu'il organise en un graphe topologique rigoureux. Les tâches indépendantes peuvent être exécutées en parallèle, tandis que celles ayant un ordre de priorité attendent leur tour.

Étape 3 : Le « championnat interne » à la concurrence féroce.

À l’intérieur de chaque sous-question, organisez un nouveau tournoi d’élimination : les nœuds lisent les propositions candidates tout en prenant en compte les critiques acerbes, afin de collaborer pour créer une version améliorée.

Si l'évaluation globale échoue, relancez avec les objections accumulées jusqu'à ce que toutes les failles soient comblées.

Étape 4 : L'apprentissage inter-roues, qui consiste à tirer des leçons de ses erreurs.

Les brouillons échoués sont laissés inchangés pour le prochain tour, et chaque piège franchi par les validateurs est soigneusement enregistré dans le « registre des pièges ».

Les chemins bloqués et les conclusions validées sont synchronisés en temps réel dans la base de connaissances partagée, disponibles pour tous à tout moment.

Réseau de tournoi en mode Long Proof : chaque stratégie candidate est accompagnée d'un falsificateur, et les voies rejetées restent dans le processus avec leurs objections.

En suivant ce processus, il ne s'agit pas tant d'un superordinateur froid et impersonnel que d'une réplication d'une réunion de recherche extrêmement rigoureuse, où personne ne peut tenter de s'en sortir par la ruse.

Ici, toute proposition doit d'abord être mise à mal plusieurs fois ; seules les idées les plus solides réussissent à passer.

Cela guérit directement l’hystérie collective la plus courante chez les systèmes multi-agents traditionnels :

Auparavant, lorsqu'un IA déviait involontairement le rythme, les autres IA suivaient aveuglément, construisant de plus en plus haut sur une base erronée.

La force de l'équipe, c'est simplement transformer le « fait de se chercher des noises » en un système rigoureux dont personne ne peut échapper.

Parmi ces sept résultats, le plus remarquable et le plus souvent mal interprété est sans doute le problème de Knuth's Cycles, proposé par Donald Knuth.

En fait, cette question a déjà été résolue par l'IA cet printemps.

Donald Knuth, conférence de Noël de Stanford 2023.

À la fin février de cette année, Claude Opus 4.6 a produit en environ une heure une construction pour les cas impairs, forçant Knuth à écrire deux fois « Shock ! » en début d'article.

Ensuite, les modèles gpt-5.3-codex et GPT-5.4 Pro ont pris le relais pour compléter les cas pairs les plus difficiles.

À la mi-avril, Gartner a clairement confirmé dans la version révisée de son article que le cas pair est désormais sans ambiguïté.

Qu'est-ce que Google a fait cette fois-ci ?

En bref, Google a trouvé deux nouvelles constructions plus élégantes et plus simples pour les cas pairs, et a simultanément publié deux premières preuves détaillées de plus de 40 et 70 pages.

Ce document de plus de 40 pages, certifié par une vérification formelle avec Lean, ne présente aucune erreur même pour une machine.

C'est bien sûr une contribution académique solide, mais son véritable intérêt réside dans « la présentation d'une preuve plus élégante », et non dans une véritable rupture depuis zéro.

Cela met plutôt en lumière le véritable atout de Teamwork :

Il n'a pas cherché à combler l'« intelligence isolée » d'un modèle unique, mais a totalement résolu la faiblesse collaborative des multiples agents intelligents, souvent désunis et suiveurs, grâce à des mécanismes de jeu et d'organisation institutionnalisés, libérant ainsi la « sagesse collective ».

Même mécanisme de détection d'erreurs, Google change de mode et le prend directement pour résoudre des projets techniques exigeants.

Cet article technique détaille clairement l'utilisation de Gemini 3.7 Flash. L'équipe a construit dès le départ un simulateur CPU RISC-V exécutant des cycles de manière désordonnée.

L'exécution hors séquence est une fonctionnalité standard des processeurs modernes à haute performance, et c'est aussi le point le plus susceptible de faire planter les émulateurs.

Le travail d'équipe se déroule en deux étapes : d'abord, garantir la correction des fonctionnalités de l'architecture micro, en écrivant soi-même une pipeline hors séquence et un tampon de réordonnancement pour démarrer avec succès le système d'exploitation xv6 jusqu'au shell ; ensuite, aligner les horaires cycle par cycle.

Processus de démarrage du noyau xv6 et d'accès au shell par l'émulateur RISC-V construit par Teamwork.

Le plus grand défi, que Google appelle « le fossé de l'exécution silencieuse ».

L'état de la microarchitecture du simulateur peut dériver silencieusement sur plusieurs centaines de cycles, et lorsque des erreurs sont signalées au niveau de l'architecture, la source d'origine est déjà introuvable.

La solution de Teamwork consiste à isoler le simulateur de référence Spike dans un environnement sandboxé pour empêcher les agents de tricher ou de plagier, puis à effectuer une simulation synchronisée en pas de temps fermés, avec vérification à chaque étape.

Finalement, ce simulateur a exécuté plus de 100 benchmarks standards RISC-V et a présenté une erreur moyenne de 0,71 % en cycles par rapport au matériel BOOM sur des charges de test inédites.

Google discloses: Cycle alignment comparison between Teamwork simulator and BOOM hardware shows an average error of 0.71% on test loads.

Cependant, il faut préciser qu'il s'agit d'un simulateur au niveau logiciel, pas d'une conception de puce RTL, et encore moins de la fabrication de puces.

Par rapport aux mathématiques et aux simulateurs, la dernière catégorie de résultats semble la moins impressionnante, mais ses preuves sont les plus solides.

Eigen est une bibliothèque d'algèbre linéaire hautement performante largement utilisée dans le monde C++.

Teamwork a identifié une implémentation sous-optimale d'une multiplication de vecteur matriciel en ligne ou en colonne et a directement implémenté un chemin rapide SIMD.

Dans la table de hachage parallèle ParlayHash, Teamwork a introduit les optimisations de Swiss Table, doublant le débit initial d'insertion avec 64 threads, augmentant le débit global par thread de 1,5 fois et réduisant la mémoire utilisée par élément de 25 %.

Ces deux modifications ne sont pas des performances auto-évaluées faites en vase clos, mais du vrai code, rigoureusement examiné par la communauté open source et officiellement fusionné dans la branche principale par des mainteneurs externes.

Plus remarquable que le score de performance est une déclaration de l'auteur en fin d'article mathématique : la preuve a d'abord été produite par le système d'agents Gemini interne à Google, puis vérifiée et éditée par l'auteur.

Les agents explorent follement des feuilles de brouillon infinies, tandis que les humains se chargent de signer et d'approuver finalement. C'est la répartition la plus réelle actuelle dans la recherche sur l'IA.

Google l'a lui-même clairement déclaré : ces problèmes auraient normalement pris des experts de premier plan plusieurs mois à résoudre ; Teamwork réduit le cycle d'essais et d'erreurs, mais le volant et le droit de signature finale restent entre les mains des humains.

La seconde moitié de la recherche en IA ne se joue plus sur la taille des paramètres des modèles, mais sur la qualité de l'équipe IA.

Plus le modèle est bon marché et semblable à un produit d'usage courant, plus la validation et la supervision humaines deviennent précieuses.

Autrefois, l'homme était celui qui résolvait les problèmes. Aujourd'hui, l'homme est celui qui les pose et les valide.

Gartner a trouvé une preuve manuscrite pour Claude, puis a appris que quelqu'un l'avait vérifiée avec Lean ; il a déclaré : « C'est vraiment une bonne chose », car il « commet de plus en plus d'erreurs récemment ».

Même la preuve du lauréat du prix Turing âgé de 88 ans doit passer par le vérificateur ; les preuves écrites par l’IA ne peuvent pas faire exception.

Pour les tâches de résolution, les machines en feront de plus en plus. Pour la phase de validation, il faut impérativement qu'une personne soit présente.

Références :

https://antigravity.google/blog/teamwork-when-ai-becomes-a-research-partner

https://www-cs-faculty.stanford.edu/~knuth/papers/claude-cycles.pdf

Cet article provient du compte WeChat « Nouvelle Intelligence », auteur : Apocalypses de l'ASI, éditeur : Yuan Yu