4.8 Bilan et ouvertures
La motivation de ce nouveau cadre d’acquisition de problèmes par contraintes est dans le but de dépasser les limites des cadres de la littérature. Le but était de voir comment nous pouvions, à partir de problèmes proches du problème réel de l’utilisateur, généraliser un modèle décrivant à la fois ces problèmes et celui ciblé par l’utilisateur. Ces problèmes proches ont déjà été résolus par l’utilisateur d’une autre manière, par exemple à la main, mais leurs données, telles les variables et les domaines diffèrent par rapport à son nouveau problème. Nous avons donc proposé de passer par un langage de modélisation plus expressif que le langage de base bas-niveau des CSP consistant à fournir les ensembles X de variables, D des domaines et C des contraintes. Dans ce langage, X et D ne sont pas donnés. Il y a bien des variables et des domaines mais leurs descriptions sont fournies par l’utilisateur uniquement au moment où il souhaite créer une instance du problème, pouvant être résolue par un solveur. Nous avons choisi comme langage un sous-ensemble de la logique du premier ordre permettant d’exprimer une large classe de problème par contraintes. Ce choix a été préféré dans un souci de réutilisation des techniques, voire des systèmes, de programmation logique inductive. Cependant, comme le montrent les expérimentations présentées dans le chapitre suivant, les problèmes représentés par les CPS posent de sérieuses difficultés aux systèmes d’apprentissage ce qui nous a conduit à développer un algorithme tirant parti de la structure de ces modèles.
Ainsi, nous obtenons un cadre où l’utilisateur doit fournir des solutions et non-solutions de problèmes, proches mais suffisamment différents de son problème cible. Une fois le modèle appris, l’utilisateur fournit, sous forme de tables, les variables et domaines du problème dont il cherche une solution. Notre système construit alors un CSP qui peut être résolu par les nombreux solveurs existant en programmation par contraintes.
Ce cadre offre plusieurs pistes de développement. La première consiste à enrichir le lan-gage des CPS afin de pouvoir traiter plus de types de problèmes. Ajouter la quantification existentielle, les agrégats pour proposer des contraintes plus complexes (comme Σ par exemple). . . sont des pistes à étudier. Cela doit cependant se faire en gardant à l’esprit un souci de complexité pour la partie apprentissage. Cependant exploiter une structure plus forte dans notre langage, nous éloignant ainsi du cadre ILP traditionnel, pourrait per-mettre ce genre d’enrichissement. On pourrait considérer des objets, plus expressifs que les variables, mais pouvant simplifier à la fois l’expression des contraintes et l’apprentissage des règles. Dans les jeux de données que nous avons utilisés, nous pouvons constater la présence d’objets comme les reines, les tâches ou encore les cours, auxquels sont liés des caractéristiques, les positions des reines par exemples, sur lesquelles sont ensuite posées les contraintes. Nous pourrions avoir une approche consistant à chercher les contraintes uniquement en considérant un unique objet. Ensuite, il s’agirait de voir si on peut trouver des contraintes entre plusieurs objets de manière incrémentale. D’un tout autre côté, un reproche pouvant être fait à notre cadre concerne la nécessité par l’utilisateur de fournir des non-solutions de problèmes proches. En effet, si les solutions peuvent être facilement trouvées grâce à des données historiques, il est difficile d’imaginer que soient gardées des non-solutions. Nous sommes partis de l’idée que si l’utilisateur souhaitait utiliser notre cadre, c’est qu’il n’arrivait pas à trouver de solutions à son problème actuel. Nous pou-vons, de notre point de vue, supposer qu’il soit alors facilement capable de produire des non-solutions. Cependant, cette manière de générer des contres-exemples peut produire des non-solutions très riches en informations qui d’une part ne seront pas toutes exploitées
4.8. BILAN ET OUVERTURES
(dès qu’une règle est apprise permettant de dire que c’est une non-solution, cet exemple est « jeté ») et d’autre part qui pourront induire en erreur les algorithmes d’apprentissage (en mélangeant deux règles par exemple) et ainsi perdre en efficacité. Nous pouvons alors sortir deux pistes. La première consisterait à mieux exploiter ces exemples, en les « com-pressant » pour faire ressortir des singularités[KZ10]. Une autre consisterait à ne demander que des solutions à l’utilisateur et ensuite trouver un moyen de générer de petits exemples que l’utilisateur aurait à étiqueter, c’est-à-dire des requêtes. De tel exemples permettraient de créer un espace de recherche plus petit dans la phase d’apprentissage et par conséquent d’utiliser des approches complètes.
Chapitre 5
Générer-et-Tester et opérateur
bidirectionnel
5.1 Introduction
Pour répondre aux problèmes rencontrés dans la phase d’apprentissage, nous avons développé une nouvelle approche d’apprentissage, bi-directionnelle et de type générer-et-tester[LMV10]. Dans cette approche, nous proposons de réduire progressivement l’espace de recherche en ciblant la zone où pourrait se trouver une règle discriminante. Pour cela, nous maintenons deux hypothèses, (�i, ⊥i), bornant l’espace de recherche. Notre opérateur de raffinement produira de nouvelles bornes (�i+1, ⊥i+1) telles que �i+1sera plus spécifique que �i et ⊥i+1 sera plus générale que ⊥i. La recherche s’arrêtera alors quand �i = ⊥i si possible, couple représentant une unique hypothèse, la règle retournée par notre approche. Ces deux hypothèses sont liées entre elles par une relation de saturation [Rou92, Rou90] permettant d’assurer que tous les littéraux de ⊥i sont atteignables à partir de �i, c’est-à-dire peuvent être ajoutés à �i en respectant les entrées/sorties des prédicats.
L’intérêt de maintenir ces deux bornes est qu’elles permettent de rendre plus efficace l’utilisation d’approche incomplète grâce à des heuristiques plus précises sur des données structurées comme les CPS.
Ce chapitre se divise de la manière suivante. La première partie décrit le langage des exemples utilisé dans notre approche avec notamment une description de l’opération de saturation[Rou92, Rou90] permettant de compléter les exemples avec des informations présentes dans la base de connaissances. Ensuite, nous caractériserons notre espace de recherche en commençant par la description du langage des hypothèses (section 5.3) puis l’espace de recherche que nous utilisons (section 5.4). Nous pourrons alors présenter notre opérateur de raffinement avec ses principales caractéristiques puis la stratégie d’utilisation dans le cadre de l’apprentissage de CPS. Nous finirons par les expériences liés au chapitre précédent, montrant l’efficacité de notre technique dans la tâche d’apprentissage de notre cadre d’acquisition de CSP.
Ce chapitre est inspiré des travaux publiés dans [LMV10] en collaboration avec Lionel Martin et Christel Vrain.