Un robot de conversation:
quelques réflexions
Idée de base
Ma première idée était de créer un "robot-météo", capable de parler de la pluie et du beau temps, quelqu'un avec qui on pourrait avoir une conversation du genre de celle qu'on a dans un ascenseur (!). Puis je me suis dit: autant mettre en pratique mes connaissances d'informatique. J'ai donc décidé de créer un robot qui devait être capable d'aider les gens à diagnostiquer et résoudre les problèmes qu'ils pourraient avoir avec leur ordinateur. Idéalement, on décrirait une panne au robot, et il nous suggérait une solution pour y remédier. Par exemple, si l'ordinateur ne démarre pas, il proposerait de contrôler que la prise de courant est branchée.
Réalisation
En fait, le résultat final ne correspond pas vraiment à mes ambitions de départ, et mon robot est tout juste capable de parler d'ordinateurs comme on parle... de la pluie et du beau temps. Je doute donc qu'il soit d'une grande utilité pour apporter une solution à vos pannes informatiques (bien que si vous lui dites "Mon ordinateur ne démarre pas", il vous suggère effectivement de contrôler le courant!).
Mais dans l'aventure, j'ai quand même appris deux ou trois choses intéressantes:
- Les expressions régulières sont à la fois très puissantes, et très limitées. Lorsqu'on introduit certains patterns relativement complexes, on est d'abord surpris de voir que ça marche effectivement (même pour des cas qu'on n'avait pas prévu!). Mais les expressions régulières ne sont pas suffisantes pour créer un robot comme celui qui était envisagé. En effet, la structure des phrases peut varier énormément. Il faudra par exemple deux patterns différents pour reconnaître "mon ordinateur a un problème" et "j'ai un problème avec mon ordinateur", qui ont pourtant la même signification. Pour que le robot réponde de façon relativement sensée à l'utilisateur, il faudrait donc créer un nombre énorme d'expressions.
- Une autre difficulté est liée au fait que le robot générique de Ken n'a aucune mémoire (dans sa version de base en tout cas). A chaque phrase de l'utilisateur, il oublie tout et repart de zéro Pour un robot diagnostiqueur de pannes, c'est un défaut rédhibitoire! En effet, à moins que l'utilisateur ne soit capable de décrire tous les aspects de son problème en une seule phrase, le robot ne pourra fournir que des éléments de réponse fragmentaires et incomplets. Dans les manuels techniques, le diagnostic de pannes se fait souvent à l'aide d'arbres de décision, qui ne peuvent être implémentés avec un robot du type décrit ici.
Conclusion
Un robot diagnostiqueur de pannes devrait donc disposer (1) d'outils plus puissants pour un traitement "sérieux" de la langue naturelle et (2) d'une "mémoire", afin de pouvoir accumuler les informations au fur et mesure de la conversation et les utiliser pour poser des questions pertinentes à l'utilisateur. Il est clair qu'un tel programme n'aura alors plus grand chose à voir avec le robot générique de Ken.