On avait une IA à 15 % de win rate sur le Mattel 1981. On a voulu l'empiler sous MCTS pour passer à 25-30 %. Elle est tombée à 0 %. Vingt parties. Une leçon structurelle sur la composition des algorithmes.
Oracle-X1 est l'agent IA qu'on a construit pour jouer à Dragon Labyrinth (Mattel 1981) en observation partielle — comme un humain, sans voir le dragon. Il intègre cinq couches cognitives qu'on appelle le Layer Humain :
Résultat en observation partielle : 15 % de win rate sur 800 parties (vs 0-2 % pour brute force, 20 % pour un humain expert, 98 % pour le TMS1100 original qui triche avec l'info complète).
Monte Carlo Tree Search est l'algo standard pour les jeux à information imparfaite. Il construit un arbre des actions possibles et simule des rollouts pour évaluer chaque branche. Plus on simule, meilleure la décision.
L'intuition naïve : si on remplace les rollouts aléatoires de MCTS par des rollouts Oracle-X1, chaque simulation devient intelligente. MCTS hybride = structure (Layer Humain) + exploration (arbre) = mieux que chaque outil seul.
C'est ce que font les grosses IA modernes : AlphaZero empile MCTS + réseau neuronal. MuZero pareil. Le combo "recherche + modèle appris" est la recette standard du deep RL en 2020-2025.
| Métrique | Oracle-X1 pur | Hybrid MCTS V2 |
|---|---|---|
| Win rate (20 parties) | ~15 % | 0 % |
| Temps par partie | 3-5 s | ~62 s (20×) |
| Timeouts | rares | 10 / 20 |
| Morts 3 hits | rares | 10 / 20 |
0 victoire sur 20 parties, 20 fois plus lent. MCTS n'a pas boosté Oracle-X1, il l'a cassé.
Oracle-X1 utilise M3 (momentum killer) et M5 (ToM + commitment memory) pour suivre une trajectoire cohérente. Quand on clone sa session dans un rollout MCTS, tous les rollouts depuis le même état de belief convergent vers des scores similaires.
Conséquence : MCTS ne peut plus discriminer entre les 4 actions possibles à la racine. Tous les enfants ont le même score. Il choisit quasi-aléatoirement. Sur un jeu où la moindre erreur coûte une blessure, c'est mortel.
Pour faire tourner Oracle-X1 dans un rollout, il faut fixer une position de trésor (sinon le modèle de dragon ne sait pas où aller). On échantillonne une position dans le belief state courant.
Problème : avec 2 à 10 candidats et 50 rollouts, l'espérance des scores est dominée par le bruit d'échantillonnage. Deux actions quasi-équivalentes finissent avec des scores qui diffèrent plus par hasard que par qualité. MCTS choisit le bruit.
Depth=40 semble raisonnable. Mais Oracle-X1 est optimisé pour des parties complètes (~60-80 tours). Tronqué à 40, la plupart des rollouts finissent avant d'atteindre le trésor. Les scores deviennent des fonctions de "distance restante au trésor", qui ne différencient pas assez les actions au début d'une partie.
Augmenter depth → temps par rollout explose. Déjà à 62 s/partie, doubler la profondeur signifierait 2 min par partie. Économiquement infaisable pour un prototype local.
Pourquoi AlphaZero marche-t-il ? Parce que son réseau neuronal, entraîné par self-play, produit des évaluations différenciables à la racine de chaque position. Deux actions vraiment différentes donnent des évaluations vraiment différentes. MCTS exploite cette différence.
Pourquoi Oracle-X1 casse sous MCTS ? Parce qu'il est discret au lieu de continu. Son choix d'action est un filtre à règles ("évite le dragon", "va au trésor", "ne reviens pas d'où tu viens"). À une position donnée, il produit à peu près le même comportement long-terme quelle que soit l'action initiale, parce que M3-M5 rattrapent vite les écarts. MCTS cherche des différences qui n'existent pas.
Il y a une lecture positive de ce résultat négatif : Oracle-X1 seul bat MCTS + Oracle-X1. Sa structure cognitive est un optimum local qui n'a pas besoin d'exploration externe.
Un chevalier humain expérimenté ne fait pas MCTS dans sa tête. Il suit ses heuristiques, son intuition spatiale, sa conviction sur la position du dragon. C'est ce que fait Oracle-X1. L'empiler sous un algo de recherche, c'est l'équivalent d'obliger un grand maître d'échecs à tirer ses coups aux dés pondérés.
Trois pistes restées sur la table, documentées pour mémoire :
On les laisse en TODO. La leçon principale est déjà solide.
Ce résultat a une portée au-delà de Dragon Labyrinth. Dans le trading algorithmique, le choix technique entre "agent structuré à heuristiques" et "agent exploratoire à recherche" revient tout le temps.
Notre hypothèse après ce test : un portefeuille de 60 stratégies spécialisées avec cross-pollination (approche structurée) a probablement plus de valeur qu'un gros modèle unique avec rollouts MCTS (approche exploratoire). C'est d'ailleurs le pari de notre benchmark Dragon, où on teste empiriquement cette hypothèse avec un jeu assez petit pour être compris mais assez grand pour être dur.
Si vous voulez reproduire ces tests à la maison — Hybrid MCTS tourne en single-thread Python sur CPU, mais les rollouts Oracle-X1 en parallèle tirent parti d'un bon CPU. Brute force GPU (12M parties/h) demande en revanche une carte dédiée.
Code open sur le repo de la série Dragon Labyrinth : hybrid_mcts_v2.py + grok_belief_core.py. python3 hybrid_mcts_v2.py 20 50 40 (20 parties, 50 rollouts, depth 40).
Non. MCTS fonctionne parfaitement quand le rollout est différenciant. Random rollouts sur Go de 9×9 sont différenciants. Oracle-X1 sur Dragon ne l'est pas, parce qu'il converge trop vite vers sa trajectoire. Le cadre compte.
PUCT nécessite une policy prior probabiliste. Oracle-X1 produit des décisions déterministes, pas de distribution de probabilité sur les actions. Il aurait fallu softmaxer artificiellement les scores, ce qui aurait ajouté un hyperparamètre bruyant.
On a 12M parties brute force loguées. Pré-entraîner un DT dessus serait légitime. Mais on ne sait pas si un transformer petit (~10-50M params) généralise sur un POMDP discret, et on ne veut pas monter à 1B+ params pour un side project. À tester si quelqu'un lance un projet Research-as-a-Service sur Dragon.
Publié le 22 avril 2026 par OutilsIA. Source : journal de dev dragon_ablation/HYBRID_MCTS_FINDING.md, 20 parties Hybrid MCTS V2 sur Ryzen CPU.