Recherche · Apprentissage de règles

Apprendre des règles lisibles à partir d'exemples

Souvent, l'entreprise sait reconnaître les bons et les mauvais cas sans savoir formuler la règle qui les sépare : quelles commandes vérifier, quels clients sont éligibles, qui est senior. La programmation logique inductive, ou ILP, retrouve cette règle à partir d'exemples étiquetés. Contrairement à un modèle statistique, le résultat est une règle écrite, que l'on peut lire, discuter et déployer.

Comment ça marche

Apprendre de ses échecs

On fournit trois choses : des faits connus sur les cas, un biais qui dit quels prédicats la règle a le droit d'utiliser et jusqu'à quelle longueur, et des exemples positifs et négatifs. Le moteur énumère des règles candidates, teste chacune contre les exemples et tire de chaque échec une contrainte qui élimine des familles entières de candidates. Il assemble enfin le plus petit programme qui couvre tous les exemples positifs sans aucun négatif.

01Faits connus
02Biais
03Exemples étiquetés
04Règle testée

Aucun appel au modèle de langage n'est nécessaire. Une variante, facultative, peut demander au modèle de proposer un biais ou des règles de départ à partir d'une description ; le programme final est toujours testé formellement contre les exemples.

Contrôle des commandes

Quelles commandes vérifier ?

Le service client a marqué quatre commandes qui méritaient une vérification et cinq qui n'en méritaient pas. On cherche la règle qui les sépare, à partir de quatre signaux.

Apprendre la règle

Les faits, le biais, les exemples : le moteur rend le programme.

Résultat obtenu sur le serveur : deux règles, « nouveau client et montant élevé » ou « carte étrangère et adresse de livraison différente », qui couvrent les quatre cas à vérifier et aucun des cinq autres.

ilp:learnVVL

[kb set "cmd_verif"]
[facts "cmd_verif"
  "montant_eleve(c1)." "nouveau_client(c1)."
  "montant_eleve(c2)." "nouveau_client(c2)." "carte_etrangere(c2)."
  "carte_etrangere(c3)." "adresse_differente(c3)."
  "carte_etrangere(c4)." "adresse_differente(c4)." "montant_eleve(c4)."
  "montant_eleve(c5)." "nouveau_client(c6)." "carte_etrangere(c7)."
  "adresse_differente(c8)." "nouveau_client(c8)."
  "montant_eleve(c9)." "adresse_differente(c9)."]
$biais = [ilp:bias [JSON '{
  "target": "a_verifier/1",
  "predicates": [
    {"name": "a_verifier",         "modes": ["+commande"], "role": "head", "is_bk": false},
    {"name": "montant_eleve",      "modes": ["+commande"]},
    {"name": "nouveau_client",     "modes": ["+commande"]},
    {"name": "carte_etrangere",    "modes": ["+commande"]},
    {"name": "adresse_differente", "modes": ["+commande"]}],
  "types": {"commande": "symbolic"}, "max_body": 2, "max_clauses": 3}']]
$positifs = [JSON '[["c1"], ["c2"], ["c3"], ["c4"]]']
$negatifs = [JSON '[["c5"], ["c6"], ["c7"], ["c8"], ["c9"]]']
$regle = [ilp:learn $biais "a_verifier" $positifs $negatifs [JSON '[]'] [JSON '{"beam_width": 128, "seed": 7}'] "cmd_verif"]
$regle.program

Déployer la règle apprise

La règle apprise est un programme logique testé. Elle s'ajoute telle quelle à une base de production et s'applique aux nouvelles commandes.

Résultat obtenu sur le serveur : la commande c42 est à vérifier, la commande c43 ne l'est pas.

en productionVVL

[kb set "cmd_prod"]
[facts "cmd_prod" "montant_eleve(c42)." "nouveau_client(c42)." "carte_etrangere(c43)."]
[for $clause $regle.program [[rules "cmd_prod" $clause]]]
[query VVL "cmd_prod" "a_verifier(c42)?"]      # oui : nouveau client, montant élevé
[query VVL "cmd_prod" "a_verifier(c43)?"]      # non : carte étrangère seule

Auditer une règle existante

Confronter une règle écrite à la main aux exemples

Avant sa mise en service : combien de bons cas elle couvre, et si elle en attrape de mauvais.

ilp:testVVL

$clause = [JSON '["a_verifier(C) :- montant_eleve(C)."]']
[ilp:test $clause "a_verifier" $positifs $negatifs [JSON '[]'] "cmd_verif"]
# { n_pos, covered_pos, covered_neg, complete, consistent }

Résultat obtenu sur le serveur : la règle « montant élevé » couvre 3 des 4 commandes à vérifier mais signale aussi 2 commandes saines ; elle n'est ni complète ni cohérente.

Autres cas

Ressources humaines, et apprentissage guidé

Ressources humaines : qui est senior ?

Les responsables savent désigner les profils seniors. L'apprentissage retrouve le critère : expérimenté et certifié. Hugo, certifié mais sans expérience, et Carol, expérimentée mais sans certification, obligent la règle à combiner les deux.

Résultat obtenu sur le serveur : senior(X) si certifie(X) et experimente(X), couverture de 3 sur 3, statut testé.

rh_seniorVVL

[kb set "rh_senior"]
[facts "rh_senior"
  "experimente(alice)." "experimente(carol)." "experimente(eve)." "experimente(grace)."
  "certifie(alice)." "certifie(eve)." "certifie(grace)." "certifie(hugo)."]
$biais = [ilp:bias [JSON '{
  "target": "senior/1",
  "predicates": [
    {"name": "senior",      "modes": ["+personne"], "role": "head", "is_bk": false},
    {"name": "experimente", "modes": ["+personne"]},
    {"name": "certifie",    "modes": ["+personne"]}],
  "types": {"personne": "symbolic"}, "max_body": 2, "max_clauses": 2}']]
$r = [ilp:learn $biais "senior" [JSON '[["alice"], ["eve"], ["grace"]]']
                [JSON '[["carol"], ["hugo"], ["bob"], ["dave"]]']
                [JSON '[]'] [JSON '{"beam_width": 128, "seed": 7}'] "rh_senior"]
[ilp:explain $r]

Guider l'apprentissage par une description

Lorsque les prédicats utiles ne sont pas évidents, une description en langage naturel peut orienter la recherche. Le modèle de langage propose des pistes, et le programme retenu reste testé contre les exemples.

ilp:induceVVL

$r = [ilp:induce
  "A grandparent is two generations of parent. Use parent/2, male/1, female/1."
  "grandparent" 2
  $pos $neg
  [JSON '{"n_seeds": 5, "max_body": 3, "beam_width": 128, "seed": 42}']
  "ilp_llm_bootstrap"]

Garanties

Ce qu'il garantit, et ses limites

Le résultat est une règle lisible, testée contre chaque exemple, avec sa couverture : pas une boîte noire.
La règle retenue est la plus simple compatible avec les exemples. Si les exemples ne distinguent pas deux critères, la règle n'en retiendra qu'un : la qualité des exemples compte plus que leur nombre.
Le biais borne la recherche ; l'élargir rend l'apprentissage plus lent.
Une règle apprise peut être soumise à une politique de validation avant d'être mise en production.

Passer à la pratique

Appliquer ces travaux à vos processus ?

Ces outils sont des instructions du langage VVL : nos partenaires les mettent en œuvre chez leurs clients, sur les plateformes ProSuite.

Devenir partenaire Tous les sujets