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

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, inspiré de l'approche « apprendre de ses échecs », é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.

  1. Faits connus
  2. Biais
  3. Exemples étiquetés
  4. Règle testée

Aucun appel au modèle de langage n'est nécessaire. Une variante, facultative, peut demander au modèle de langage 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.

Exemples en entreprise

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.

[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

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.

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.

[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

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

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.

[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]

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

Auditer une règle existante

Une règle rédigée à la main peut être confrontée aux exemples étiquetés avant d'être mise en service : combien de bons cas elle couvre, et si elle en attrape de mauvais.

$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.

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.

$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"]

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.

Appliquer ces travaux à vos processus ?

Le diagnostic part de votre fonctionnement réel et identifie les décisions qui peuvent être confiées à l'IA.

Discuter avec nous sur WhatsApp