Identifying potentiating events in evolutionary search using replay experiments

Imaginez que vous regardez un jeu vidéo où un personnage tente de résoudre une énigme massive. Vous le voyez enfin déchiffrer le code et gagner, mais vous n'avez aucune idée de comment il y est parvenu. A-t-il trouvé un tour astucieux par chance ? A-t-il appris une compétence secrète à mi-chemin qui a rendu la suite du jeu plus facile ? Dans le monde de l'informatique, il existe un domaine appelé l'informatique évolutionnaire. C'est comme un milieu de culture numérique où nous élevons des programmes informatiques plutôt que des bactéries. Nous les laissons « évoluer » au fil du temps, en les mélangeant et en les faisant muter pour voir s'ils peuvent devenir meilleurs pour résoudre des problèmes, comme la correction de bugs dans des logiciels ou la conception de mouvements de robots.

D'ordinaire, lorsqu'un programme informatique résout enfin un problème difficile, nous célébrons simplement la victoire. Mais les scientifiques sont curieux : Pourquoi cela a-t-il fonctionné cette fois-ci et pas la dernière ? Était-ce un changement spécifique dans le code qui a rendu le succès possible plus tard ? C'est là qu'intervient l'idée de potentialisation. Voyez cela comme un « bonus » (power-up) dans un jeu vidéo. Vous ne voyez peut-être pas le bonus agir immédiatement, mais il modifie le personnage de sorte que, plus tard, lorsqu'il trouve une clé spécifique, il puisse l'utiliser pour ouvrir une porte qu'il ne pouvait pas ouvrir auparavant. La question que cet article traite est la suivante : comment pouvons-nous regarder en arrière dans l'histoire d'un ordinateur pour trouver ces bonus cachés qui ont rendu une solution possible, même si l'ordinateur ne semblait pas plus « intelligent » à ce moment-là ?

---

Rembobiner la bande de la vie numérique

Dans cet article, Austin Ferguson et Alexander Lalejini introduisent une nouvelle façon fascinante d'étudier ces évolutions numériques en utilisant ce qu'ils appellent des expériences de relecture (replay experiments). Vous pouvez voir cela comme si vous appuyiez sur le bouton « retour rapide » d'un film, mais au lieu de simplement regarder le même film à nouveau, vous mettez pause à différents moments, vous faites une copie des personnages à cet instant précis, et vous lancez une multitude de nouveaux films à partir de ce point exact.

Dans le monde réel, des scientifiques ont fait cela avec des bactéries. Ils congèlent des échantillons de bactéries provenant de différents jours d'une expérience en laboratoire. Plus tard, ils les décongèlent et les laissent évoluer à nouveau pour voir s'ils peuvent développer un nouveau trait, comme manger un nouveau type de nourriture. Si c'est le cas, cela signifie que les bactéries s'étaient déjà « préparées » avec des changements cachés plus tôt.

Les auteurs transposent cette idée dans le monde des programmes informatiques. Ils soutiennent que nous pouvons faire la même chose avec des logiciels. Au lieu de simplement regarder un programme évoluer en espérant le meilleur, nous pouvons enregistrer des « instantanés » (snapshots) du programme à chaque étape. Ensuite, nous pouvons prendre ces instantanés et lancer des centaines de nouvelles versions légèrement différentes de l'évolution à partir de ce point. En voyant la fréquence à laquelle ces nouvelles versions réussissent, nous pouvons mesurer le potentiel (ou « potentialisation ») du programme pour résoudre le problème.

La grande surprise : Le succès ne dépend pas toujours d'être plus « fort »

Les auteurs ont mené une démonstration en utilisant un type simple de programme informatique appelé programmation génétique. Ils ont mis en place 1 000 groupes différents de ces programmes et les ont laissés tenter de résoudre un casse-tête spécifique : trier des nombres en catégories « petit », « grand » ou « ni l'un ni l'autre ».

Voici le rebondissement qu'ils ont découvert, et c'est la partie la plus importante de leur histoire : S'améliorer face au problème ne signifie pas toujours que vous vous rapprochez de la victoire.

Dans leur expérience, ils ont suivi deux éléments :

1. La Fitness (aptitude) : La manière dont le programme se comporte à l'instant T (comme un score dans un jeu).
2. La Potentialisation : La probabilité que le programme finisse par résoudre parfaitement le casse-tête si l'on continuait l'évolution.

Dans l'un de leurs groupes de test (la Population A), les programmes ont atteint un « optimum local ». C'est comme un joueur qui reste bloqué sur un plateau dans un jeu vidéo. Leur score a cessé de progresser et est resté bloqué à 75 % pendant un long moment. Pour un observateur, on aurait dit que les programmes tournaient en rond. Mais ensuite, les auteurs ont appuyé sur « retour », et ont lancé les relectures.

Ils ont découvert qu'à un moment précis de l'histoire de ce groupe, la potentialisation a soudainement bondi de 1 % à 40 %. Les programmes étaient devenus soudainement beaucoup plus susceptibles de résoudre parfaitement le casse-tête, même si leur score (fitness) n'avait pas changé du tout ! Ils étaient toujours bloqués à 75 %, mais ils avaient secrètement acquis un « bonus » qui rendait une solution parfaite possible.

C'est un événement majeur car cela suggère que, dans la recherche évolutionnaire, vous ne pouvez pas vous contenter de regarder le score actuel pour savoir si vous gagnez. Un programme peut sembler échouer ou être bloqué, mais il pourrait être assis sur un gisement d'or de potentiel qui ne s'est pas encore manifesté dans le score.

Comment ils ont procédé (la relecture « ingénierée »)

Pour prouver cela, les auteurs n'ont pas seulement fait des suppositions. Ils ont utilisé une astuce ingénieuse appelée relecture ingénierée (engineered replay). Imaginez que vous avez deux versions d'un personnage : une avec un chapeau rouge et une avec un chapeau rouge et une écharpe bleue. Vous voulez savoir quel objet l'a aidé à gagner.

Dans une relecture normale, vous lanceriez simplement de nouveaux jeux à partir de la version « chapeau rouge » et de la version « chapeau rouge + écharpe bleue ». Mais pour être extrêmement précis, les auteurs ont créé des versions « ingénierées ». Ils ont créé un nouveau personnage possédant uniquement l'écharpe bleue (qui n'existait jamais réellement dans l'histoire originale) et ont également lancé des relectures à partir de celui-ci. Cela les a aidés à déterminer exactement quel minuscule changement dans le code était le bonus secret.

Ce que cela signifie pour l'avenir

L'article ne prétend pas avoir résolu tous les mystères de l'évolution, mais suggère que les expériences de relecture sont un outil puissant que nous n'avons pas assez exploité. Il démontre que :

• L'histoire cachée compte : Le chemin parcouru par un programme pour atteindre une solution est tout aussi important que la solution elle-même.
• La Fitness est un menteur : Un score élevé ne signifie pas toujours qu'un programme est prêt à résoudre les problèmes les plus difficiles, et un score bas ne signifie pas qu'il est sans espoir.
• Nous pouvons trouver le « Pourquoi » : En revenant en arrière et en rejouant, nous pouvons identifier le moment exact où un programme a obtenu le « bonus » dont il avait besoin.

Les auteurs espèrent qu'à l'avenir, les scientifiques utiliseront ces expériences de relecture pour comprendre pourquoi certaines recherches informatiques échouent et d'autres réussissent. Peut-être qu'un jour, nous pourrons concevoir de meilleurs algorithmes capables de savoir quand continuer même lorsque le score semble mauvais, parce qu'ils peuvent sentir qu'un bonus caché est imminent. Pour l'instant, cependant, cet article est un excellent rappel que dans la jungle numérique, les changements les plus importants sont peut-être ceux que l'on ne voit pas sur le tableau des scores.