Même un détecteur qui ne peut rien apprendre retombe sur le même raccourci : le problème est dans l'œil, pas dans l'apprentissage

Piste débutant

Là où on en était

Depuis le Chapitre 11, un fait dérangeant traîne au centre de toute cette campagne, jamais

réparé : la boussole du planificateur — celle qui compare une histoire imaginée à un souvenir

de succès — pointe à l'envers une fois sortie de son terrain d'entraînement. Chaque

tentative depuis (Chapitres 12 à 16) a construit quelque chose autour de ce problème —

une mémoire des lieux visités, un réflexe anti-noyade, une prédiction d'exploration — sans

jamais s'attaquer directement à la boussole elle-même. Ce chapitre raconte les deux premières

tentatives qui visent directement le cœur du problème. Aucune des deux ne fonctionne. Mais

ensemble, elles apprennent quelque chose d'important sur où se cache réellement ce défaut.

Première idée : ne pas réparer la boussole, apprendre à ne pas lui faire confiance

Au lieu de corriger le jugement biaisé de la boussole, cette première idée essaie de le

contourner autrement : construire un détecteur séparé, dont le seul travail est de repérer

« cette image ressemble à quelque chose que le modèle n'a jamais bien vu à l'entraînement » —

et si c'est le cas, ignorer la boussole et laisser la main à la mémoire des lieux visités

(Chapitre 12), qui elle a déjà fait ses preuves.

La particularité de ce détecteur, c'est qu'il ne s'entraîne pas du tout, au sens où

l'apprentissage automatique l'entend d'habitude. Pas de réseau de neurones, pas de

descente de gradient (la méthode habituelle par laquelle un modèle ajuste peu à peu ses

réglages internes pour améliorer un score). Il se contente de mesurer, une bonne fois pour

toutes, à quoi ressemble la forme statistique typique — la moyenne et la dispersion — des

images d'entraînement dans l'espace compressé (l'embedding, la représentation compacte

que fabrique le modèle à partir d'une image) que le modèle utilise déjà. Ensuite, pour

n'importe quelle nouvelle image, il calcule simplement à quelle distance elle se trouve de

cette forme typique. Plus loin = plus suspect. C'est une formule mathématique fixe, pas

quelque chose qui « apprend » au sens où un raccourci trompeur pourrait s'y glisser en

douce.

Ce détecteur a été soumis à trois tests, sur les mêmes images déjà utilisées pour prouver

au Chapitre 11 que la boussole était inversée :

1. Sait-il distinguer un terrain connu d'un terrain inconnu ? Presque, mais raté de

justesse — la différence entre les deux catégories n'était pas assez nette.

1. Est-ce qu'il repère spécifiquement les images où la boussole s'est trompée, et pas

juste « n'importe quelle image un peu différente » ? Raté plus clairement — le détecteur

réagissait à « c'est un décor différent », pas à « c'est ici que le jugement est faux ».

1. Est-ce qu'il se laisse distraire par un détail sans rapport, comme la simple luminosité

de l'image ? Raté nettement, et c'est le résultat le plus important des trois : le

détecteur suivait la luminosité presque autant que les précédentes tentatives ratées des

Chapitres 10, 14 et 15.

Pourquoi ce troisième échec compte plus que les cinq précédents

Voilà le point le plus important de ce chapitre. Cinq fois avant celle-ci (Chapitres 10, 11,

14 en comptant ses deux moitiés, et 15), un système entraîné s'est fait piéger par la

luminosité de la scène au lieu de vraiment juger la présence d'un arbre. On aurait pu penser

que le problème venait de la façon dont ces systèmes apprenaient — un raccourci facile que

l'entraînement finissait toujours par trouver, comme une pente de facilité. Mais ce nouveau

détecteur n'apprend rien du tout. C'est une formule fixe, sans réglages ajustables, sans

possibilité de « tricher » en trouvant un raccourci pendant un entraînement — parce qu'il n'y

a pas d'entraînement.

Et pourtant, il tombe exactement dans le même piège.

Cela change complètement l'explication la plus probable. Le problème n'est vraisemblablement

pas « nos méthodes d'entraînement trouvent toujours le même mauvais raccourci ». Le problème

est plus profond : la confusion entre « c'est un arbre proche » et « c'est sombre » semble

être déjà présente dans la façon même dont le modèle de base compresse une image en

représentation compacte — avant même qu'un quelconque apprentissage supplémentaire

n'intervienne. N'importe quel calcul construit par-dessus cette représentation, aussi

prudent soit-il, hérite du même défaut, parce que le défaut est dans le matériau brut, pas

dans la façon de le travailler.

Deuxième idée, plus modeste : le problème vient-il d'un manque de photos sombres ?

La deuxième piste de ce chapitre revient sur une vieille hypothèse jamais vérifiée

directement, datant du tout début de cette enquête (le raccourci de luminosité corrigé — sans

succès — au Chapitre 10) : et si le modèle confondait obscurité et absence d'arbre simplement

parce qu'il n'avait presque jamais vu de scènes sombres pendant son tout premier

entraînement ?

La vérification est simple, sans rien entraîner : compter, dans les données d'entraînement

d'origine, la proportion d'images sombres ou sous l'eau. Résultat : à peine 1 % — l'hypothèse

d'un manque de diversité était donc bien fondée, pour ce modèle d'origine.

Mais le Chapitre 14 avait déjà réentraîné une version du modèle sur un mélange de données

beaucoup plus large, incluant beaucoup de scènes issues du vrai jeu de fabrication — et

cette vérification montre que ces données-là contenaient déjà 16 à 22 % d'images sombres ou

sous l'eau, même en comptant large. L'image bizarre repérée au Chapitre 14 (celle dont le

score a empiré après le réentraînement) n'était donc pas un cas extrême jamais rencontré : elle

ressemble à beaucoup d'autres images déjà présentes dans les données d'entraînement.

Conclusion : pour ce cas précis, manquer de photos sombres n'est plus une explication

plausible. Si quelqu'un reprend un jour la réparation du modèle de base, la piste la plus

prometteuse n'est probablement pas « plus de données », mais quelque chose dans *la façon

dont l'entraînement compare des scènes différentes entre elles* — un point que personne n'a

encore testé.

Ce que ça change pour la suite

Ces deux résultats négatifs, mis ensemble, ferment une question et en éclaircissent une

autre :

• Sixième confirmation indépendante du même piège de luminosité — après un petit module

entraîné, ce même module réentraîné, une variation de lumière artificielle, un modèle

géant tout fait, un calcul de couleur fait main, et maintenant une simple formule

statistique sans aucun apprentissage. Six façons complètement différentes de s'y prendre,

un seul et même mur.

• La piste « pas assez de données sombres » est fermée pour le cas précis qui l'avait

motivée — pas parce que plus de données ne servirait jamais à rien en général, mais parce

que, dans ce cas précis, il y en avait déjà assez.

• Le projet se retrouve donc devant un choix net, pas encore tranché : soit réentraîner le

cœur même du modèle avec un objectif d'entraînement différent — un chantier lourd,

jamais tenté jusqu'ici — soit accepter ce défaut comme une limite connue du projet et

continuer à construire sur ce qui fonctionne déjà (exécuter les plans plus longtemps, la

mémoire des lieux visités, le réflexe anti-noyade). Ce n'est pas encore décidé, et ce

chapitre ne tranche pas à la place de qui de droit.

Comme pour chaque chapitre de ce site : deux vraies tentatives, deux échecs honnêtes, et un

résultat qui, même négatif, apprend quelque chose de solide sur la nature du problème.