💬 NLP

GeoMathCode: Understanding Interleaved Math-Code Reasoning for Geometry Problem Solving

Cet article présente GeoMathCode, un cadre qui améliore la résolution de problèmes de géométrie en utilisant du code programmatique comme sorties visuelles intermédiaires, révélant que l'affinement supervisé dissocie le raisonnement et la génération de code, tandis que les structures syntaxiques hiérarchiques capturent des informations mathématiques plus riches que les représentations visuelles.

Auteurs originaux : Yingji Zhang, Yong Dai, André Freitas

Publié 2026-05-26

📖 5 min de lecture🧠 Analyse approfondie

CC BY 4.0

Auteurs originaux : Yingji Zhang, Yong Dai, André Freitas

Article original sous licence CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Ceci est une explication générée par l'IA de l'article ci-dessous. Elle n'a pas été rédigée ni approuvée par les auteurs. Pour une précision technique, consultez l'article original. Lire la clause de non-responsabilité complète

Imaginez que vous essayez de résoudre une énigme géométrique complexe, comme déterminer comment deux courbes interagissent sur un graphique. Habituellement, lorsqu'un ordinateur tente de résoudre ce problème, il peut simplement « penser » en mots ou essayer de dessiner une image pixel par pixel. Mais cet article introduit une nouvelle façon pour les ordinateurs de penser : GeoMathCode.

Voici une décomposition de ce que les chercheurs ont réalisé, en utilisant des analogies simples :

1. Le Problème : Dessiner avec des Pixels vs Écrire des Instructions

Imaginez que vous voulez enseigner à un robot à dessiner un cercle parfait.

L'Ancienne Méthode (Basée sur les Pixels) : Vous dites au robot : « Colorie ce point précis en rouge, puis celui-ci, puis celui-ci... » C'est comme essayer de peindre un chef-d'œuvre en disant à quelqu'un exactement quel coup de pinceau faire à chaque seconde. C'est désordonné, difficile à vérifier pour détecter les erreurs, et si le robot fait une toute petite erreur, l'image entière semble fausse.
La Nouvelle Méthode (GeoMathCode) : Au lieu de peindre des points, vous donnez au robot un ensemble d'instructions (du code). Vous dites : « Dessine un cercle de rayon 5. » Le robot écrit un court programme pour le faire. C'est comme donner une recette plutôt qu'une peinture. C'est précis, facile à vérifier (le code a-t-il fonctionné ?), et s'il y a une erreur, vous pouvez voir exactement où la recette a mal tourné.

Les chercheurs ont construit une vaste bibliothèque de problèmes mathématiques où la « solution » n'est pas seulement une réponse finale, mais un mélange de mots (expliquant la logique) et de code (les instructions pour dessiner la forme).

2. La Grande Découverte : Deux « Salles du Cerveau » Différentes

La partie la plus intéressante de l'article est ce qu'ils ont découvert à l'intérieur du « cerveau » de l'ordinateur (son espace de mémoire interne) pendant qu'il résolvait ces problèmes.

Ils ont découvert que l'ordinateur possède deux « salles » séparées pour penser :

Salle A (La Salle de Logique) : C'est là que l'ordinateur détermine les règles mathématiques (par exemple : « Puisque la courbe s'ouvre vers le bas, les valeurs augmentent lorsque nous nous déplaçons vers la gauche »).
Salle B (La Salle de Dessin) : C'est là que l'ordinateur écrit le code pour dessiner réellement les lignes.

L'Analogie : Imaginez un chef cuisinant un repas complexe.

Dans la Salle A, le chef réfléchit : « Je dois d'abord faire revenir les oignons, puis ajouter les épices. » (Le raisonnement).
Dans la Salle B, le chef hache physiquement les légumes et allume la cuisinière (Le code).

L'article a révélé que ces deux activités se produisent dans des parties complètement différentes du cerveau de l'ordinateur. Elles ne se mélangent pas. L'ordinateur n'utilise pas la partie « dessin » pour l'aider à « réfléchir » aux mathématiques ; il utilise la partie « réflexion » pour décider quoi dessiner, puis bascule vers la partie « dessin » pour exécuter le plan.

3. L'Effet de « Formation » : Organiser le Chaos

Les chercheurs ont également testé ce qui se passe lorsqu'ils « forment » l'ordinateur (un processus appelé Affinement Supervisé ou SFT) en utilisant leur nouvelle bibliothèque de problèmes.

Avant la Formation : La « pensée » de l'ordinateur était un peu chaotique. C'était comme une bibliothèque où les livres étaient jetés par terre en tas. Il y avait beaucoup d'informations, mais c'était désordonné et difficile à naviguer.
Après la Formation : La « pensée » de l'ordinateur est devenue comme une bibliothèque bien organisée. Les livres (les idées) étaient toujours là, mais maintenant ils étaient triés en rangées ordonnées. L'ordinateur ne s'est pas seulement rendu « plus intelligent » en ajoutant plus de livres ; il est devenu plus intelligent en organisant les livres qu'il possédait déjà. Cela a rendu ses chemins de raisonnement plus clairs et plus structurés.

4. Le Code est Meilleur pour les « Symboles Mathématiques » que les Images

Enfin, ils ont comparé la compréhension des symboles mathématiques par l'ordinateur (comme $\sqrt{}$ pour la racine carrée ou $\pi$ pour pi) lorsqu'il utilisait du code par rapport à lorsqu'il utilisait des images.

La Découverte : L'ordinateur comprenait le sens des symboles mathématiques beaucoup mieux lorsqu'il écrivait du code que lorsqu'il regardait ou générait simplement une image.
L'Analogie : C'est comme la différence entre lire une partition musicale (code) et écouter un enregistrement (image). La partition vous dit exactement quelles sont les notes et comment elles se rapportent les unes aux autres. L'enregistrement sonne simplement bien. L'ordinateur a découvert que la « partition » (le code) détenait le secret de la logique mathématique bien mieux que l'« enregistrement » (l'image visuelle).

Résumé

En bref, cet article dit :

Arrêtez de faire dessiner des images pixel par pixel aux ordinateurs pour résoudre des mathématiques ; laissez-les écrire du code à la place. C'est plus propre et plus facile à vérifier.
Les ordinateurs séparent la « réflexion » du « dessin ». Ils utilisent différents espaces mentaux pour la logique et pour la génération de code.
La formation organise le cerveau. Enseigner à un ordinateur avec cette méthode n'ajoute pas seulement des faits ; elle arrange son processus de pensée en une structure nette et efficace.
Le code est le meilleur traducteur. Lorsqu'il s'agit de comprendre des symboles mathématiques complexes, écrire du code est un outil plus puissant pour l'ordinateur que de regarder des images.

Résumé Technique : GeoMathCode

Énoncé du Problème

Le raisonnement mathématique dans les Grands Modèles de Langage Multimodaux (MLLM) repose souvent sur la génération de solutions en plusieurs étapes pour des problèmes de géométrie. Bien que des approches récentes comme MathCanvas tentent d'imiter le raisonnement humain en intégrant des constructions visuelles auxiliaires (par exemple, dessiner des lignes ou des points), elles reposent généralement sur une génération d'images basée sur les pixels. Les auteurs identifient deux limitations principales dans ce paradigme :

Alignement et Vérification : La génération croisée fine (texte vers images basées sur les pixels) est intrinsèquement difficile à aligner et à vérifier, augmentant le potentiel de propagation des erreurs.
Complexité du Système : Les approches basées sur les pixels nécessitent souvent des générateurs spécifiques aux visions supplémentaires, compliquant l'architecture du système.

L'article postule que, bien que les représentations programmatiques (code) soient précises et vérifiables, il reste incertain de savoir si un raisonnement mathématique-code entrelacé redéfinit fondamentalement la géométrie latente du raisonnement multimodal ou s'il ne sert que de sortie auxiliaire. Plus précisément, les auteurs cherchent à comprendre comment les trajectoires de raisonnement évoluent à travers les couches et si les représentations symboliques du code capturent les concepts géométriques différemment des représentations visuelles.

Méthodologie

1. Construction du Jeu de Données : GeoMathCode

Les auteurs introduisent GeoMathCode, un jeu de données multimodal public conçu pour le raisonnement mathématique-code entrelacé. Le pipeline de construction implique :

Source : L'utilisation de MathCanvas comme ressource principale, couvrant huit domaines mathématiques (Algèbre, Géométrie Analytique, Calcul, etc.).
Génération : L'emploi de Gemini 3-Flash pour générer des solutions entrelacées contenant un raisonnement textuel, du code Python exécutable et des visualisations correspondantes.
Vérification : Un pipeline de vérification automatisé multi-niveaux assure la qualité :
- Moteur Basé sur des Règles (GPT-5.1) : Extrait les étapes clés de raisonnement (« pick-points ») et les règles mathématiques.
- Vérificateur (Gemini 3-Pro) : Valide l'exactitude de la réponse finale, la logique du raisonnement textuel et l'exécution du code.
- Sandbox : Filtre les échantillons avec une exécution de code erronée, déclenchant une régénération itérative.
Échelle : Le jeu de données final comprend 10 000 échantillons d'entraînement et 1 000 échantillons de test, équilibrés avec un ratio 1:1 de questions avec et sans diagrammes.

2. Cadre d'Analyse Empirique

L'étude évalue des MLLM représentatifs (Qwen3/3.5, LLaVA-Next, InternVL3.5) en utilisant à la fois un Fine-Tuning Supervisé (SFT) à paramètres complets et LoRA. L'analyse se concentre sur deux perspectives :

Performance Post-Entraînement : Évaluation de métriques incluant la Précision de la Réponse (Ans Acc), la justesse du raisonnement textuel, la Précision du Code, la Correction Mathématique du Code et la Cohérence Texte-Code.
Analyse de la Géométrie Latente : Investigation de l'espace de représentation interne des modèles à travers :
- Analyse des Trajectoires : Mesure des distances euclidiennes entre les étapes de raisonnement et les étapes de code à travers les couches du transformeur.
- Régularisation de Variété : Quantification de la capacité informationnelle et de la complexité géométrique en utilisant le Rang Effectif (ERank) et la Dimension Intrinsèque (ID).
- Structure de l'Espace de Code : Analyse de la représentation latente de la syntaxe du code (flux de contrôle, appels de fonctions, flux de données) en utilisant KNN et SVM linéaire pour évaluer le regroupement local et la séparabilité linéaire globale.
- Sondage Symbolique : Comparaison de la capacité des embeddings de code par rapport aux embeddings visuels à capturer des symboles mathématiques fins (par exemple, $\sqrt{}$ , $\triangle$ , $\angle$ ).

Résultats Clés

1. Performance et Désentanglement

Le SFT Améliore la Performance : Le Fine-Tuning Supervisé améliore considérablement les performances sur tous les modèles. Qwen3.5-9B-SFT obtient les meilleurs résultats globaux (Score moyen 0,73), surpassant les bases et les variantes LoRA.
Désentanglement Raisonnement-Code : Les visualisations PCA et l'analyse des trajectoires révèlent que les étapes de raisonnement et les étapes de génération de code forment des sous-espaces latents désengagés.
- Le modèle repose principalement sur les trajectoires de raisonnement textuel pour la prédiction de la réponse finale.
- La génération intermédiaire de code agit comme une représentation exécutable auxiliaire plutôt que comme une modalité de raisonnement active guidant directement la réponse finale.
- Cela suggère une séparation fonctionnelle entre le raisonnement mathématique et l'exécution programmatique dans l'espace latent.

2. Régularisation de Variété via SFT

Raisonnement Structuré : Le SFT augmente le Rang Effectif (ERank) des représentations de raisonnement (indiquant une diversité informationnelle plus riche) tout en réduisant simultanément la Dimension Intrinsèque (ID) (indiquant une complexité géométrique locale plus faible).
Interprétation : Cela suggère que le SFT ne fait pas que compresser les représentations, mais réorganise les trajectoires de raisonnement en chemins computationnels plus structurés, canoniques et réutilisables, équilibrant la diversité informationnelle avec la régularité géométrique.

3. Espace de Code Hiérarchique

Sous-espaces Syntaxiques : Les structures syntaxiques hiérarchiques (par exemple, flux de contrôle, appels de fonctions) émergent comme des sous-espaces latents structurés.
Dynamiques d'Abstraction : Bien que les catégories sémantiques de haut niveau restent préservées, le regroupement lexical fin devient mixte dans les couches plus profondes. Le modèle réorganise les API en variétés d'exécution-sémantique partagées basées sur les rôles fonctionnels.
Supériorité du Code sur les Visuels : Les représentations latentes de code capturent les concepts symboliques mathématiques fins (par exemple, opérateurs spécifiques et formes géométriques) plus efficacement que les représentations visuelles, comme en témoigne une précision de classification plus élevée dans les tâches de sondage.

Signification et Revendications

L'article revendique fournir un nouveau jeu de données et une analyse systématique de la structure géométrique latente sous-jacente au raisonnement mathématique-code entrelacé. Les contributions principales sont :

Jeu de Données : L'introduction de GeoMathCode, qui facilite l'étude des sorties intermédiaires programmatiques dans la résolution de problèmes de géométrie.
Insights sur la Géométrie Latente : La démonstration que les étapes de raisonnement et de code sont désengagées dans l'espace latent, remettant en question l'idée que la génération de code est une modalité de raisonnement active de la même manière que les modalités visuelles pourraient l'être.
Effets du SFT : La découverte que le SFT régularise la variété de raisonnement, la rendant plus informative tout en étant géométriquement régulière, plutôt que de simplement augmenter la complexité.
Code contre Visuels : La preuve que les représentations symboliques de code sont supérieures aux représentations visuelles pour capturer des concepts mathématiques fins.

Les auteurs concluent que ces résultats motivent de futures recherches sur l'interprétabilité mécaniste dans les LLM, spécifiquement concernant l'exécution de code, et le potentiel de l'apprentissage par renforcement basé sur le pick-point pour améliorer la fiabilité du raisonnement. Ils reconnaissent les limitations concernant la dépendance aux évaluateurs basés sur les LLM et la précision relativement faible de la réponse finale, suggérant que les travaux futurs devraient se concentrer sur l'évaluation symbolique automatique et les approches d'apprentissage par renforcement (par exemple, GRPO, DAPO).