Certains liens materiel peuvent etre affilies, sans surcout. Prix et disponibilites a verifier sur le site marchand.
On a logué 5000 parties Oracle-X1 sur Dragon Labyrinth. Puis on a fait tourner un n-gram miner sur les séquences de mouvements. Le résultat est plus brutal que prévu : les mouvements répétés gagnent, attendre tue. Une leçon universelle pour les agents en observabilité partielle.
Pour chaque partie loguée, on enregistre la séquence des mouvements du chevalier : up, down, left, right, pass. Sur 5000 parties, ça donne environ 400 000 mouvements en tout, répartis par cluster de labyrinthe (voir l'article précédent sur les 8 clusters topologiques).
On compte tous les trigrammes (triplets de mouvements consécutifs) et on mesure leur win rate : proportion de fois où ce triplet apparaît dans une partie gagnante vs perdante. Seuils : trigramme doit apparaître au moins 5 fois pour être comptabilisé.
| Trigramme | Win rate | Observations |
|---|---|---|
| up → up → up | 29 % | 939 |
| left → left → left | 28 % | 582 |
| up → left → left | 31 % | 198 |
| up → up → left | 24 % | 887 |
| down → down → left | 21 % | 1150 |
Baseline Oracle-X1 : 14 % WR sur l'ensemble. Ces patterns gagnent 1.5× à 2× la moyenne. Ce n'est pas subtil — c'est deux fois plus.
| Trigramme | Win rate | Observations |
|---|---|---|
| down → pass → right | 0 % | 20 |
| down → up → down | 0 % | 21 |
| left → down → pass | 0 % | 10 |
| pass → left → left | 0 % | 8 |
| right → up → pass | 0 % | 8 |
pass, et les oscillations down-up-down ou left-right-left. 0 victoire sur des dizaines d'observations. Le chevalier qui hésite ou attend meurt.
Deux explications coexistent :
pass sont celles où M3 a détecté un piège et le chevalier a reculé.
Le pass est particulièrement catastrophique parce qu'il donne un tour au dragon sans rien accomplir. Le dragon se rapproche. Le chevalier n'a gagné que du temps — qu'il n'a pas.
Tous les clusters ne se ressemblent pas. Le cluster 3 (labyrinthes denses, trésor proche du camp) a des patterns top à 30-32 % WR. Le cluster 6 (très fragmenté, dead-ends) plafonne à 8-10 % WR sur les mêmes patterns.
| Cluster | Topologie | WR baseline | Meilleur pattern | WR pattern |
|---|---|---|---|---|
| 0 | Ouvert, trésor loin | ~20 % | up-up-up | 20 % |
| 1 | Modéré, ouvert | ~29 % | up-up-up | 29 % |
| 3 | Dense, trésor proche | ~25 % | up-left-left | 32 % |
| 6 | Fragmenté, dead-ends | ~8 % | down-left-down | 10 % |
L'environnement domine la tactique. Même les meilleurs patterns ne sauvent pas un agent dans un labyrinthe mal foutu. Réciproquement, les mauvais patterns (avec pass) sont universellement mortels — aucun cluster ne les rend viables.
Applications immédiates :
Maintenant qu'on connaît les patterns gagnants, on peut biaiser Oracle-X1 pour les privilégier :
pass sauf si M4 (fear field) signale un dragon imminentHypothèse : Oracle-X3 devrait gagner 2-4 points de WR supplémentaires. Si l'ensemble X1+X2+X3 se comporte comme X1+X2 (21.5 % en ensemble), on pourrait atteindre 25-28 % WR — largement au-dessus du plafond humain expert.
Le code est dans le repo Dragon Labyrinth. pattern_miner.py prend en entrée le log des parties (dlb_games_log.jsonl) et les clusters (wiki_clusters.json), et sort wiki_patterns.json. Environ 30 secondes sur un CPU moyen pour 5000 parties.
Formule du score :
score = win_rate × sqrt(total_observations)
C'est un compromis entre qualité (win rate) et robustesse statistique (nombre d'observations). Un pattern avec 80 % WR sur 3 observations passe loin derrière un pattern à 25 % WR sur 1000 observations.
On a testé n=2 : signal trop bruité (beaucoup de patterns communs, peu différenciants). n=4 : pas assez d'occurrences par pattern unique pour avoir de la significativité. n=3 est le sweet spot : assez riche pour capturer des tactiques cohérentes, assez fréquent pour être fiable.
Informellement oui. Observé sur 30 parties jouées par un humain expert : proportion de pass proche de 0, streaks de 3+ mouvements dans la même direction fréquents. L'intuition humaine converge naturellement vers ce que les données prouvent.
Oui. On va l'appliquer à Pac-Man Symmetric dès qu'on aura logué 5000 parties. Hypothèse : les patterns gagnants seront probablement "rester mobile" (up-up-up, left-left-left) et les patterns perdants "oscillation" et "longue pause en intersection".
Oui, le code pattern_miner.py est minimal (87 lignes) et les 5000 parties d'entraînement sont reproductibles avec les seeds 0 à 4999. Lancez python3 pattern_miner.py dlb_games_log.jsonl wiki_clusters.json wiki_patterns.json 3.
Publié le 22 avril 2026 par OutilsIA. Source : wiki_patterns.json (5000 parties Oracle-X1, 8 clusters k-means, ~400 000 mouvements). Code : pattern_miner.py, 87 lignes.