Etudiante-chercheuse en informatique – sciences des données, elle et ses encadrants ont travaillé sur une solution d’aide à l’utilisateur pour les tâches répétitives
Par Sintia Dounang
Lors du Cari’2022 tenu récemment, Vous avez présenté un article intitulé « QuickFill, QuickMixte : approches par blocs pour la réduction du nombre de programmes en synthèse de programmes ». De quoi s’agit-il ?
Déjà, c’est quoi la synthèse de programmes ? C’est un sous domaine de l’intelligence artificielle qui se sert des spécifications de l’utilisateur dans le but de fournir des programmes permettant à ce dernier d’automatiser ses tâches. Si on prend l’exemple de la génération d’adresses e-mails à partir des noms et prénoms pour 2 000 – 10 000 (ou plus) étudiants de la faculté des sciences, ce serait très pénible et laborieux pour une personne lambda de parcourir les noms et prénoms de chaque étudiant afin de générer l’adresse correspondante. Il est donc possible à partir de quelques exemples de concevoir des programmes (formules) qui nous permettent plutôt de générer des adresses e-mails de manière automatique. Dans la littérature, un exemple d’outil capable d’effectuer cette tâche est « FlashFill ». C’est un système de traitement automatique des chaînes de caractères dans les systèmes tableurs. L’on peut se poser la question de savoir, pourquoi faire du traitement de chaînes de caractères dans les tableurs ? On sait que les tableurs à la base sont construits pour effectuer des calculs ce qui explique pourquoi on y trouve des fonctions sophistiquées pour faire des calculs. Par contre pour les chaînes de caractère, il y a des fonctions élémentaires et donc pour faire des traitements beaucoup sophistiqués, on peut le faire par apprentissage sur des exemples. C’est ainsi que dans le cadre de ce travail nous nous sommes intéressés à cet outil qui est d’ailleurs l’un des systèmes de synthèse de programmes les plus connus de la littérature qui est intégré à toutes les versions récentes d’Excel (depuis 2011). Nous l’avons étudié en profondeur pour le comprendre question de relever d’éventuelles limites. Ce qu’on a compris avec FlashFill c’est qu’il fonctionne bien sauf que dans certains cas l’utilisateur va devoir fournir beaucoup d’exemples. Celui-ci n’a pas toujours la capacité de fournir des exemples représentatifs. Il peut donner des exemples mais qui n’aident pas le système à mieux comprendre son intention. Aussi les programmes retournés par FlashFill sont très nombreux. Parmi ces programmes certains sont spécifiques aux exemples. Suite à ces remarques, on s’est dit qu’un utilisateur qui a la capacité pour une entrée donnée de spécifier sa sortie a également la capacité de faire un matching (association) entre les sous-parties de l’entrée et les sous-parties de la sortie. Si par exemple je veux retourner IBM à partir d’International Business Machine, cet utilisateur a la capacité de me dire : I provient de International, B de Business et M de Machine. En ce moment la spécification est beaucoup plus fine, on sait dorénavant où aller chercher chaque sous-partie de la sortie.
Qu’est ce qui a motivé cette recherche ?
Les tâches répétitives sont des tâches qui demandent beaucoup de temps, elles sont fastidieuses. Ces tâches répétitives ont la possibilité d’être automatisées, ceci via l’usage d’un code. C’est-à-dire vous avez des tâches répétitives à effectuer, vous écrivez un petit code qui fera le travail à votre place. La vérité c’est que les utilisateurs en général ne sont pas des programmeurs ; ils n’ont pas la capacité de coder et pour ceux qui en sont capables, le temps d’écriture du code est parfois proche du temps de résolution manuelle de la tâche. Donc ce qui a motivé ce travail c’est qu’avec l’outil FlashFill l’utilisateur n’a pas besoin de coder, il a juste besoin de fournir des exemples de ce qu’il a envie de faire et on se sert de ces exemples pour comprendre son problème et lui poser des programmes pour traiter automatiquement d’autres instances.
Qu’est ce qui en ressort de cette recherche ?
L’intuition derrière les approches « QuickFill QuickMixte » que nous avons proposé était qu’en ajoutant des interactions supplémentaires à FlashFill, on réduirait non seulement le nombre de programmes que FlashFill retourne, le taux de programmes corrects se verrait augmenté, et aussi, on demanderait moins d’exemples à l’utilisateur dans certains cas de figures. Ces hypothèses ont été vérifiées c’est-à-dire, dans un cas où le FlashFill existant a besoin de 3 exemples entrées-sorties pour comprendre réellement ce que l’utilisateur souhaite effectuer comme tâche ; avec « QuickFill, QuickMixte », on avait des cas où avec un seul exemple on captait exactement l’intention de l’utilisateur ; ce qui implique que, tous les programmes générés soient corrects de sorte qu’en exécutant n’importe quel programme sur d’autres exemples les résultats retournés sont les résultats attendus ce qui satisfait l’utilisateur.
Dans d’autres cas FlashFill retournait beaucoup de programmes et parmi ces programmes d’autres étaient spécifiques aux exemples d’apprentissage. Ce qui fait que, si j’exécute ce programme sur d’autres exemples, la sortie retournée ne sera pas la sortie attendue. Autrement dit, on n’aide pas vraiment l’utilisateur. Donc les hypothèses étaient de voir si ajouter des interactions pouvaient aider à réduire le nombre de programme ce qui a été fait, si cela pouvait aider à augmenter le taux de programmes corrects (ce sont les programmes qui fonctionnent sur tous les exemples), tout en réduisant le nombre d’exemples devant être fournis par l’utilisateur dans certains cas. Ces différentes hypothèses ont été vérifiées empiriquement.
Cela a-t-il déjà été implémenté ? ou alors comment est-ce qu’on devrait l’implémenter ?
C’est déjà implémenté. Il faut noter que FlashFill étant un produit propriétaire (Microsoft) son code source n’est pas accessible. Pour vérifier nos intuitions, nous avons commencé par faire une ré-implémentation partielle de FlashFill parce que c’est assez costaud. À côté de cela nous avons aussi implémenté les deux approches QuickFill et QuickMixte proposées que nous avons testées sur plusieurs données.
Quelles sont les difficultés que vous avez rencontrées ?
La difficulté au début de ce travail est que je découvrais la synthèse des programmes. C’est certes un domaine étudié depuis des décennies et qui est d’ailleurs en pleine croissance mais à mon niveau c’était nouveau en tout point. Ensuite quand on s’est concentré sur le papier FlashFill, j’avais aussi des difficultés parce qu’il y avait beaucoup de choses à digérer, il fallait surtout comprendre en profondeur pour pouvoir passer à l’implémentation. Aussi au niveau des données – nous n’avons pas trouvé pour des données réelles qui sont en adéquation avec FlashFill – nous nous sommes inspirés des exemples représentatifs présentés dans l’article et d’un générateur de données en ligne basé sur les expressions régulières pour générer des données utilisées lors des expérimentations. Les jeux de données n’étaient pas de très grandes tailles pour éviter les problèmes de ressources. La recherche s’est faite sur une période d’un an.
