5-3.2 L'acquisition et la formalisation des connaissances

Dans la littérature sur les systèmes experts, le but d'un système est avant tout de nature pratique. Il s'agit en fait d'assister un décideur en mettant à sa disposition les connaissances dont il a besoin pour résoudre certains cas difficiles. Un modéliseur s'intéresse aussi à ce genre de performance, mais pour lui un système doit d'abord systématiser un ensemble de connaissances, voire même représenter une théorie. La construction d'un système doit tenir compte de buts scientifiques qui vont au-delà de la performance. Donc, avant de construire un système, il faut savoir à quoi il servira.

En ce qui concerne la LAIE, il faut se demander, par exemple, si le but est la simulation d'un décideur particulier, s'il faut modéliser une politique générale d'application d'une loi ou encore une combinaison des deux comme nous le faisons dans le système P-Lex décrit dans la section 5-4 "La dimension politique dans l'application d'une loi" [p. 207]. En ce qui concerne le système M-Lex, notre but est assez simple: nous postulons qu'il est possible de modéliser un "décideur-type" qui adopte l'interprétation standard (préconisée par le gouvernement central) de la législation. Nous ne prétendons pas non plus modéliser la façon dont les décideurs raisonnent normalement. Il est probable que le mécanisme le plus fréquemment utilisé dans ce genre de décision juridique est le raisonnement par cas (anglais: "case based reasoning"). Les décideurs utilisent des prototypes pour résoudre des cas simples comme l'acquisition d'un appartement de vacances. Pour des cas plus difficiles, ils consultent des cas similaires dans la jurisprudence et les adaptent au cas particulier. Leurs conclusions sont normalement vérifiées en consultant les textes de la loi. Toutefois, sur demande, ces décideurs seraient capables de fournir un raisonnement juridique. Il se trouve par ailleurs partiellement dans le texte justifiant la décision. M-Lex ne modélise donc pas un processus cognitif, mais des décisions que le décideur peut justifier "post hoc" en utilisant un raisonnement plus analytique, voisin de celui employé par le système.

Pour construire M-Lex, nous avons tenté de traduire un texte juridique en un système de type "Mycin". La Lex Friederich est écrite dans un style moderne utilisant un langage relativement clair et simple. Toutefois, la traduction ne fut pas aussi simple que nous nous l'étions imaginée. La structure du texte n'inclut pas son mode d'emploi. Celui-ci réside à la fois dans le savoir-faire des juristes et dans la sémantique du langage juridique. Il faut par exemple encoder un certain nombre de paramètres qui structurent le processus d'inférence. Citons un exemple: dans cette loi, il y a des exceptions à certains articles, mais nulle part il n'est dit explicitement qu'il faut vérifier (pour chaque paragraphe) qu'il n'existe pas d'exceptions. En généralisant, on peut constater que les lois ne sont pas rédigées avec l'idée d'un arbre de décision dans la tête et c'est au modéliseur de le fournir. Il va de soi qu'on peut construire des arbres très différents pour un même texte et qui aboutissent malgré tout au même résultat. On peut faire la distinction entre les connaissances statiques (la législation, la jurisprudence, les commentaires dans les revues spécialisées, les conseils donnés par des spécialistes, etc) et les connaissances dynamiques qui permettent d'exploiter les connaissances statiques pour résoudre des cas. Ces dernières doivent être reconstituées par le modéliseur.

Il existe des questions d'efficacité et de facilité d'usage. L'efficacité aujourd'hui pour ce genre de système ne pose plus un problème important, mais c'était le cas quand nous avons construit M-Lex. Toutefois, comme principe général , nous avons toujours préféré la clarté à l'efficacité, car le modèle en soi est un document scientifique. On doit pouvoir lire les paramètres et les règles du système en cas de nécessité. Quant à l'efficacité du cheminement du raisonnement qui est perçu par l'utilisateur, on touche à une problématique plus délicate. Faut-il, par exemple, identifier dès le départ d'une séance la grande masse des cas standard avec quelques questions bien ciblées et ainsi arriver rapidement aux conclusions? Ou faut-il faire subir à l'utilisateur toutes les questions "suggérées" par une approche analytique et "top-down" de la lecture de la loi? Tout dépend de nouveau du but du système.

La source principale de connaissance utilisée pour la modélisation de M-Lex était la loi et sa perception dans Delley et al. (82). Une autre aide importante pour la modélisation étaient les décisions (écrites) par les instances de décision. Pour déterminer des arbres de raisonnement, nous avons tenté de procéder à des expériences "think aloud" avec des collègues juristes qui résolvent un cas à haute voix. Leur utilité était limitée, car ils avaient beaucoup de difficulté à expliciter à haute voix les étapes d'un raisonnement qu'ils ne considèrent pas comme important ou qu'ils ne font pas de façon très consciente. Toutefois, il était intéressant de constater qu'il existait de grandes différences en fonction de leur connaissance de la loi. On a aussi pu constater que des stratégies très différentes étaient utilisées dans des sections différentes de la loi. Face à ces variations, nous avons finalement décidé de faire ce travail d'encodage du savoir-faire sur une base ad-hoc. Voici un résumé de la procédure que nous avons employée:

La Lex Friederich est une loi assez complexe, mais le texte de la loi possède une structure hiérarchique assez claire. Donc, la première chose à faire était d'identifier les sous-tâches principales à effectuer durant la "procédure de recherche" associée à la résolution d'un cas. Il fallait donc trouver les relations logiques entres les articles et "nommer" les étapes les plus importantes du raisonnement. Nous avons d'abord commencé à dessiner des réseaux précis de décision. Cela s'est avéré compliqué et inutile. Finalement la solution intermédiaire consistait à prendre une grande feuille de papier et à dessiner les relations "et" et "ou" entres les articles principaux. Comme nous l'avons déjà mentionné, les articles d'exception posaient quelques problèmes. Ils ne se trouvent pas au même endroit dans le texte, mais lors d'un raisonnement dynamique, il faut en tenir compte simultanément. Dans M-Lex, nous déclenchons ces tests lors de l'évaluation des faits juridiques concernés. Par exemple, l'exception à la règle d'autorisation est testée lorsqu'il y a détermination de la nature de la personne ou du type d'acquisition.
Une fois les connections logiques les plus importantes déterminées, nous avons créé un système représentant uniquement le niveau "supérieur" de décision, capable de prendre une décision en fonction des paramètres très "élevés" de "personne", "acquisition" et "motif". Mycin se prête très bien à cette méthode du "stepwise refinement", car ces paramètres du type "Inferred" sont demandés à l'utilisateur, s'il n'arrive pas à les déduire lui-même. Une fois que cet embryon a fonctionné, nous avons écrit la définition de tous les paramètres dont le système complet allait avoir besoin. C'était un exercice complètement inutile, car il fallait les transformer et les restructurer trop souvent par la suite.
Avec cette structure "top-level" en place, nous nous sommes attaqués aux modules "acquisition", "définition de la personne" et "motif". Nous avons rapidement traduit tous les articles qui semblaient être simples à coder. Le résultat immédiat fut un système qui ne fonctionnait pas du tout. Toutefois ce "scale-up" nous a permis de voir les possibilités et les limites de la coquille "mini-mycin". L'étape suivante consistait à reprogrammer ou à rajouter certaines facilités au programme. Ce qui nous avait le plus frappé par contre était le constat qu'un texte légal qui a l'air clair et précis est en fait très ambigu en termes computationnels. Il existe un très grand nombre de conditions implicites, de disjonctions exclusives, etc. qui sont évidentes pour l'interpréte humain, mais qu'il faut rendre explicites dans un système informatique. Voici un exemple simple: une personne morale ne peut pas être héritier légal, mais ce n'est écrit nulle part dans ce texte. Un autre problème qui s'est posé est le fait que certains paragraphes ne concernent qu'un nombre très limité de types de personnes ou d'acquisitions. Un système qui ne filtre pas ces contraintes pose trop de questions à l'utilisateur et l'irrite, car elles sont inutiles dans ce contexte précis.
Finalement, il a fallu procéder à une réorganisation du système pour mieux diriger le processus d'inférence (avec pour but de rendre le système plus agréable en évitant les questions inutiles). Il existe deux méthodes de base pour piloter et limiter la recherche: dans chaque règle, on peut inclure des paramètres/valeurs qui doivent êtres vrais (ou faux) avant de s'attaquer aux paramètres qui suivent dans une prémisse. L'autre méthode consiste à créer des contextes Mycin spécialisés dans lesquels on canalise certains cas spécifiques. Cette deuxième stratégie est plus efficace et parfois plus élégante, par contre il faut plus de règles et on rencontre des problèmes du passage des valeurs de paramètres d'un contexte vers un autre.

Finalement, le système a fonctionné à notre satisfaction par rapport aux buts que nous nous sommes fixés. Toutefois, la traduction du langage juridique en langage "Mycin" n'a pas toujours été simple et parfois l'esthétique en a souffert. Voilà quelques remarques et quelques modifications que nous avons apportées à la coquille d'origine pour l'adapter aux spécificités du raisonnement juridique:

Dans le système Mycin d'origine, les contextes étaient utilisés pour représenter un bloc cohérent d'informations sur un patient. Dans M-Lex, nous utilisons les contextes plutôt comme "bloc de tâche" (Angl. "task blocks"), pour structurer un processus de déduction. Dans un système Mycin typique, un patient peut avoir plusieurs instances d'un même contexte (par exemple la liste de toutes les opérations). Ainsi, le système demande toujours s'il faut créer un contexte avant de procéder à la détermination des paramètres. Pour contourner ce mécanisme pas toujours utile, nous avons modifié le système pour avoir des contextes "inferred" qui se créent automatiquement et des contextes "single" pour éviter les duplications.
Nous avons déjà mentionné le problème de l'élimination des recherches inutiles. Les coquilles Mycin standard tracent toujours toutes les règles pour déterminer un paramètre. Cela n'est pas utile en droit, aussi coupons-nous la recherche d'un paramètre lorsqu'une valeur trouvée possède un CF de 1. Sinon, il nous en fallu rédiger des règles qui contiennent implicitement de l'information heuristique de recherche. Nous avons déjà parlé de la notion de filtre, une prémisse qui doit être vraie avant que les autres clauses puissent être tracées. Il est parfois utile de demander son avis à l'utilisateur en ce qui concerne la direction de "recherche" à entreprendre. On peut également hiérarchiser les règles juridiques en découpant un paramètre juridique en deux ou plusieurs paramètres Mycin et en rajoutant un paramètre qui fait la différentiation. Une dernière stratégie mentionnée consiste à créer des contextes pour y diriger des recherches.
En réorganisant la structure d'une loi, on arrive à créer un système qui tourne. Toutefois, il serait intéressant de pouvoir préserver le plus possible la structure d'un texte, ceci pour des raisons scientifiques (le code comme modèle que l'on peut lire) ou pour des raisons pratiques (les modifications et vérifications analytiques). A notre avis il faut veiller à ce que les paramètres importants du système correspondent à des paramètres que l'on peut identifier dans un texte juridique. Lorsqu'il fallait opérer avec une autre organisation pour les besoins d'inférence, nous avons trouvé la solution suivante pour ne pas rester trop "éloigné": si un paramètre (fait) légal ne pouvait pas être utilisé pour organiser et pour piloter la recherche, nous l'avons remplacé par des paramètres heuristiques représentant un sous-ensemble des valeurs possibles du paramètre légal. Mais lorsque nous déterminons la valeur d'un tel paramètre, nous insérons dans la base de données également une paire paramètre-valeur représentant directement l'article de la loi en question. Les règles concernées possèdent donc au moins deux clauses dans la conclusion comme dans la figure 5-10. Une qui sert au processus d'inférence ("search") et l'autre qui fait référence directe à la loi et sert à imprimer le résultat d'une consultation. En séparant l'analyse et la présentation du résultat, on ne s'éloigne peut-être même pas beaucoup de la réalité. Un juriste peut en effet automatiquement faire ces découpages heuristiques et il note également les résultats de son raisonnement sous forme présentable.

Il existe d'autres difficultés que nous pourrions mentionner et certaines apparaîtront sans doute dans le contexte d'autres modélisations. Toutefois, nous pensons avoir mis en évidence les plus importantes.