Il y a 3 jours, on publiait l'ablation study Oracle-X1 qui montrait comment des modules cognitifs artificiels (M1 belief, M3 persévérance) multipliaient par 4 le win rate d'une IA sur le Dragon Labyrinth de Mattel 1980. Aujourd'hui, on attaque la question d'après : peut-on remplacer ces modules cognitifs par du pur compute ?
La réponse, c'est l'observation centrale de cet article, et elle vient d'une phrase lâchée pendant une session de debug :
« L'intuition a un coût de puissance. »
Autrement dit : quand un humain expert décide en 1 seconde, il a en réalité effectué des millions de micro-simulations inconscientes — mais précompilées depuis des années de pratique. L'intuition n'est pas gratuite, elle est amortie.
La question devient alors mesurable : combien de rollouts GPU faut-il pour rattraper ce préchargement biologique ? C'est la question fondatrice du benchmark qu'on met en place (le « DLB » — Dragon Labyrinth Benchmark). Voici les premiers chiffres.
Pour mesurer ça, on a mis en place 4 approches que voici, classées par complexité croissante :
| Approche | Complexité compute | Hypothèse |
|---|---|---|
| LLM nu (Claude Haiku via API) | 1 appel / décision | Un gros modèle de langage peut jouer sans aide |
| LLM + Layers prompt | 1 appel + 5 variables injectées | Structurer le contexte suffit à débloquer le LLM |
| Oracle-X1 (code pur) | ~10 ms / décision | Code déterministe avec belief + persévérance gagne |
| MCTS brute force (Ryzen CPU) | 200-2000 rollouts × 30-80 depth | Assez de compute remplace la structure |
Testé sur 50 parties, Claude Haiku reçoit uniquement « tu es un chevalier sur une grille 8×8, le trésor est quelque part, décide ta prochaine direction ». Résultat : 0 à 1% de win rate. Le knight oscille, revient sur ses pas, se fait attraper. C'est la confirmation d'une faiblesse structurelle des LLM : la cécité spatiale.
Comme l'a résumé Gemini dans un échange consécutif à notre premier article : « L'IA ne possède pas de "carte mentale" innée. Si elle fait Haut, Droite, Bas, Gauche, elle ne comprend pas intuitivement qu'elle est revenue au point de départ. Elle traite cela comme quatre événements distincts. »
On a alors construit un Layer Humain côté serveur qui pré-calcule, à chaque tour :
Ces 4 variables sont injectées en texte dans le prompt envoyé à Claude Haiku. Même modèle, même coût en tokens, même latence. Seule la structure du contexte change.
Avec les Layers injectés, Claude fonce vers la zone candidate (M1 lui donne le centroid), recule quand le dragon approche (M4), évite les cases récemment visitées (M3), et anticipe le move du dragon (M5). Gain visuel immédiat, taux de progrès vers le trésor multiplié par un facteur estimé à 100×.
Même mesure sur Grok-3-mini + Layers : fonctionne aussi mais clairement moins bien que Claude. Le modèle compte — mais le contexte compte plus encore.
Si on implémente directement le Layer Humain en code déterministe (pas de LLM), on obtient un Oracle-X1 qui joue à 15% de win rate sur 100 parties. C'est 15× mieux qu'un LLM nu. C'est aussi 75% du meilleur score humain observé (20%). Le code structuré bat le LLM à coup sûr sur ce type de problème.
La question pour cet article : si on jette simplement énormément de CPU sur le problème, est-ce qu'on rattrape Oracle-X1 ?
Implémentation : un MCTS (Monte Carlo Tree Search) qui, pour chaque décision du knight, simule jusqu'à 2 000 rollouts par direction possible, avec une profondeur de 60 tours futurs, en samplant la position du dragon depuis le belief set. 10 000 simulations par décision, 300 000 par partie.
Pourquoi ? Parce que sans structure, les rollouts random cherchent le trésor au hasard, évitent le dragon au hasard, et finissent par se faire attraper. La compute ne remplace pas l'heuristique. Le knight sans layers, c'est un GPS sans carte.
Mais il y a une option qu'on n'a pas encore testée : brute force les paramètres du Layer Humain lui-même. Nos valeurs (fear_penalty=5, anti_osc=1.0, camp_bonus=3, greedy_prob=0.8, etc.) sont choisies à la main. Peut-être qu'il existe une configuration magique qui triple le win rate.
Pour le mesurer, on a lancé un grid search de 729 configurations (6 paramètres × 3 valeurs chacun), chacune testée sur 20 parties avec seeds fixes. Total : 14 580 parties exécutées en parallèle sur 16 threads Ryzen.
Après 2 heures 52 minutes de calcul sur 16 threads Ryzen :
Sur les 729 configurations testées, seulement 2 ont produit une victoire sur 20 parties (5% apparent). Pour vérifier si c'était statistiquement réel ou du bruit, on a rejoué ces 2 configs sur 100 parties chacune :
| Config | Wins | WR | IC 95% | Avg turns | Avg hits |
|---|---|---|---|---|---|
| TOP1 camp_bonus=3 | 2/100 | 2.0% | 0.6% - 7.0% | 19.3 | 2.38 |
| TOP2 camp_bonus=6 | 2/100 | 2.0% | 0.6% - 7.0% | 19.3 | 2.38 |
Les 5% apparents du grid n'étaient pas statistiquement significatifs — du bruit autour de 2%. Les meilleurs paramètres brute-forcés :
Oracle-X1 avec ses modules M1+M3 choisis intuitivement fait 15% de WR. Le brute force avec grid search sur les paramètres optimaux plafonne à 2%. Le compute a testé 729 configurations, et la meilleure est battue 7.5 fois par l'intuition de développement.
C'est la validation empirique la plus claire qu'on puisse donner au principe posé par Chris : « tu peux pas brute force l'inconnu ». La structure pensée à la main, même imparfaitement calibrée, encode des décisions que le grid search n'atteint jamais — parce que ces décisions ne sont pas dans l'espace paramétrique qu'on balaye. Elles sont dans l'architecture elle-même.
On a soumis ces résultats à Grok (xAI) pour avis externe. Sa réponse, en substance :
« Le plafond à 2% n'est pas une borne théorique du POMDP — c'est juste le symptôme d'une rollout policy trop faible. Ton Oracle-X1 est déjà une policy beaucoup plus forte que n'importe quel greedy-biased. En l'utilisant à l'intérieur des rollouts, le MCTS devient un lookahead bayésien qui bénéficie des heuristiques expertes que tu as déjà codées. Estimation : 18-23% WR. »
Grok recommande un pattern qu'on a commencé à implémenter : à chaque décision, le MCTS sample une hypothèse trésor du belief set, collapse temporairement le belief d'Oracle-X1 à cette seule hypothèse, et laisse Oracle-X1 jouer le rollout complet. Le MCTS ne fait plus que scorer le premier coup sur la moyenne de tous les rollouts.
Notre première implémentation brute est à 0% de WR pour l'instant — le refactor pour une vraie session partagée entre knight principal et rollouts demande un peu plus de finesse que prévu. Article de suivi prévu avec les résultats de l'hybride validé dans les jours qui viennent.
Borne théorique supérieure estimée par Grok : 25-30% WR. Au-delà, il faudrait des priors humains que même un hybride brute force ne peut produire spontanément.
Voici le cœur de l'enseignement de cette série. Quand un humain expert prend une bonne décision en 1 seconde dans un environnement inconnu, il fait en coulisse quelque chose qui ressemble énormément à ce qu'on tente de reproduire avec le Layer Humain :
La grande différence avec un LLM, c'est que chez l'humain, ces layers sont précompilés. Entraînés sur des milliers de situations depuis l'enfance. Quand tu joues au Dragon Labyrinth en 2026 après avoir fait 100 parties en 1986 en Turbo Pascal, tes intuitions viennent de 40 ans de rollouts mentaux.
L'intuition humaine ne compense pas l'absence d'info — elle ne la crée pas de rien. Elle compense par des priors bien calibrés. 40 ans de parties ont imprimé "dans ce genre de maze, le trésor est plutôt ici, pas là". Le prior humain est une forme de compression d'information historique. C'est ça le vrai moat qu'on cherche à coder.
Le LLM, lui, part à zéro. Le MCTS aussi. Pour les rattraper, il faut leur injecter ces layers — soit en prompt (via le contexte), soit en code (via des heuristiques), soit en brute force de paramètres (via grid search ou GPU).
La vision derrière ces expériences est celle d'un nouveau benchmark : le Dragon Labyrinth Benchmark (DLB). Contrairement aux benchmarks existants :
| Benchmark | Ce qu'il mesure | Faiblesse |
|---|---|---|
| 3DMark / Time Spy | Rendering graphique | Rien à voir avec l'IA |
| MLPerf | Training / inference ML classique | Dépend du modèle, pas du hardware pur |
| llama.cpp bench | Tokens/seconde LLM | Ne mesure que le débit, pas la qualité de décision |
| DLB (proposé) | Rollouts MCTS / sec + WR sur scénario déterministe | Unique : mesure la pensée, pas le calcul brut |
Un GPU optimisé CUDA pourrait théoriquement pousser à 10-100 millions de rollouts par seconde, soit 5 000× plus que notre Ryzen actuel. Ce qui permettrait de mesurer des dixièmes de pourcents de WR et de créer un classement GPU significatif.
Les étapes à venir :
Cette expérience, faite sur un jeu de 45 ans, a une portée beaucoup plus large. Elle suggère que le prochain saut d'intelligence des LLM ne viendra pas d'un modèle 10× plus grand, mais de l'intégration systématique de layers cognitifs pré-calculés en prompt. C'est ce que certains appellent déjà le tool-augmented reasoning ou le scaffolded reasoning.
Concrètement :
Le LLM devient un décideur final, pas un planificateur complet. Cette architecture hybride est déjà ce qui fait la différence entre un chatbot gadget et un agent déployable en production.
Cet article a été rédigé pendant que 16 cœurs Ryzen tournaient en parallèle pour calculer les 14 580 parties du grid search. Si tu lis cette phrase dans les heures qui suivent sa publication, les résultats sont probablement encore en cours. Reviens demain pour voir quelle configuration des 729 testées a produit le meilleur win rate — et si on a enfin battu le plafond de 15% posé par Oracle-X1 en code pur.
Article publié le 19 avril 2026 · ← Article précédent : l'ablation Oracle-X1