Limites et perspectives de ESCHER

L’approche AMAS suivie avec ESCHER est en rupture avec les méthodes classiques de contrôle. Cela permet de solutionner certains problèmes récurrents, mais pose également de nouvelles limites. Aussi, bien qu’ayant été validé en regard des objectifs initiaux, ESCHER laisse place à des améliorations.

6.3.2.1 Formalisation

La limite la plus importante concerne l’aspect théorique de l’approche. En effet, rien ne permet de prouver formellement que ESCHER converge systématiquement vers un optimum, ni que l’optimum trouvé est global. En outre, l’apprentissage a été conçu pour se poursuivre indéfiniment. Aussi, aucun critère ne permet de déterminer si le compromis actuel de criticité est le résultat final du contrôle, ou si ESCHER va finir par trouver une meilleure solution.

Ceci est illustré par la figure 6.20 qui montre l’évolution de la criticité maximale de 100 tests de 2000 cycles effectués avec la boîte noire à 4 entrées et 4 sorties utilisée dans la section 6.1.4, et initialisé de manière identique. Cette boîte noire est particulièrement difficile à contrôler, car l’ordre dans lequel les entrées sont modifiées impacte l’évolution du niveau de criticité. En effet, un certain nombre d’entrées n’influencent pas les niveaux de criticité tant qu’une autre entrée n’a pas atteint une certaine valeur. Ainsi, lorsque la criticité maximale arrête de diminuer, ESCHER doit trouver quelles sont les prochaines entrées qui doivent être modifiées, et cela peut prendre du temps. C’est pour cela que l’on observe des paliers de

criticité sur la figure 6.20 (autour de 70, de 52, et de 25). On voit que, selon les tests, le niveau de criticité maximal met plus ou moins longtemps à passer d’un palier à l’autre. Certains tests atteignent la criticité minimale en moins de 100 cycles, tandis que d’autres n’y sont toujours pas au bout de 2000. Le palier autour de 52 semble particulièrement difficile à passer. La moyenne (en rouge), et surtout la médiane (en bleu), nous indiquent cependant que plus le temps passe, plus la proportion de tests à atteindre le palier de criticité minimale augmente. En prolongeant suffisamment le test, tous les niveaux de criticité devraient atteindre le palier le plus bas.

Toutefois, il est impossible de s’assurer, sans "ouvrir" la boîte noire, que le palier minimal de criticité atteint est effectivement le meilleur compromis possible. Rien ne dit qu’aucune amélioration du niveau de criticité (aller en-dessous du palier à 10 dans notre exemple) n’est possible en continuant le test sur une plus longue durée. Surveiller le nombre d’Agents Contextes créés peut être un bon indicateur, mais n’est pas suffisant. Lorsqu’il n’augmente plus, cela traduit une certaine stabilité du système, mais qui peut n’être que temporaire.

Ce problème concerne spécifiquement l’aspect apprentissage, une fois les Agents Contextes créés et stabilisés, ESCHER n’est plus gêné par ces paliers. La boîte noire utilisée pour cet exemple est un cas extrême où les paliers sont nombreux. Ce problème est par exemple beaucoup moins présent avec le moteur réel, mais impose tout de même la présence d’un superviseur humain qui décide du moment où l’essai peut être stoppé.

Deux pistes doivent être explorées pour améliorer cet aspect de notre système. D’une part, il manque probablement une SNC à découvrir qui permettrait aux Agents Contrôleurs de sortir plus rapidement d’un palier. D’autre part, formaliser l’approche AMAS est une tâche extrêmement difficile, une perspective à long terme, qui permettrait de prouver des propriétés telle que la convergence, et ainsi nous aider dans l’analyse des résultats obtenus.

6.3.2.2 Bruit et latence

Si le bruit a finalement eu un impact limité sur les expériences menées sur moteur réel, la raison de ce fait (sous-échantillonner la variable) n’est pas satisfaisante. En outre, la SNC 9 (l’apprentissage de l’amplitude d’une action) n’était pas implémentée lors de ces tests. Or, elle se base sur la vitesse de variation des niveaux de criticité, qui peut être fortement impactée par le bruit. Cela laisse à penser que la résolution de cette SNC ne fonctionnerait pas dans les conditions de nos expériences.

ESCHER est incapable de gérer les cas où l’effet d’une action sur une entrée ne devient observable sur une sortie qu’après une longue durée. Par exemple, avec un moteur, il faut modifier certains paramètres et les maintenir dans leur nouvel état pendant un temps prolongé (de l’ordre de la centaine de cycles pour ESCHER) avant que la température ne commence à diminuer. ESCHER a peu de chance de voir des Agents Contextes rendre compte de ce fait, surtout si d’autres variables ont changé de valeur entre temps.

Ces deux aspects, le bruit et la latence, sont des éléments propres à l’environnement de ESCHER qui devraient être appris par ce dernier. Les prochains travaux doivent se concentrer sur la découverte des SNC permettant de gérer le bruit et la latence. Nous pensons que

les SNC correspondant à ces deux problèmes sont en fait identiques. En effet, il s’agit de déterminer si une variation perçue en sortie est due au bruit, ou bien à une action passée.

6.3.2.3 Extraire les connaissances acquises

ESCHER acquiert des connaissances au sujet du procédé contrôlé au cours du temps. Ces connaissances sont distribuées dans tous les Agents Contextes, et ne sont donc pas accessibles directement depuis l’extérieur. Ceci n’est pas une limite en regard de la fonction première de ESCHER. Toutefois, il est dommage de ne pas pouvoir réutiliser ces connaissances à d’autres fins (comme par exemple obtenir un modèle calculable du procédé contrôlé).

Aussi, extraire les connaissances apprises par ESCHER représente une perspective à court terme intéressante. À première vue, la tâche semble relativement aisée, puisque les informations sont stockées explicitement dans les agents. Elle présente néanmoins quelques défis (notamment l’agrégation d’informations contradictoires provenant d’agents différents).

6.3.2.4 Le paradoxe du contrôle d’un système inconnu

ESCHER est un contrôleur capable de gérer un système préalablement inconnu (à l’excep- tion de ses entrées et sorties). La fonction d’un contrôleur est de placer le système contrôlé dans un état désiré, spécifié par l’utilisateur. Mais, si le système contrôlé est véritablement inconnu, comment l’utilisateur peut-il être sûr de ne donner au contrôleur que des objectifs réalisables ?

Cela rejoint, en partie, le problème de savoir détecter si l’optimum a été trouvé ou si une meilleure solution va être découverte. C’est une limite qui ne provient pas du contrôleur lui-même, mais de la connaissance que l’utilisateur a du système contrôlé. Les capacités d’apprentissage d’un contrôleur permettent de contrôler un système qui est inconnu du contrôleur, mais l’utilisateur doit au minimum avoir une idée de ce qu’il est possible de faire ou non. L’apprentissage est un moyen d’épargner le travail que demande le transfert des connaissances de l’utilisateur au contrôleur (qui se fait habituellement par la construction d’un modèle mathématique, ou par un paramétrage important et précis).

Mais il est possible d’aller plus loin dans l’apprentissage. Un contrôleur pourrait, par exemple, être capable d’apprendre les limites du système qu’il contrôle, et ainsi avertir l’utilisateur en cas de consignes irréalisables. Le contrôleur apprenant pourrait également être capable de détecter ses propres limites actuelles, et d’apprendre comment les dépasser. Par exemple, ESCHER pourrait se rendre compte qu’il n’est pas capable d’apprendre les effets se produisant sur une longue échelle de temps. Dans le cas d’un AMAS, cela signifierait que le système est capable de détecter de nouvelles SNC (et de trouver comment les résoudre) qui n’auraient pas été prévues par le concepteur, voire de détecter des fonctions locales manquantes et de créer le type d’agent pouvant les accomplir.