Représentations symboliques, contraintes et raisonnement

Statut documentaire : guide — voir Maturité et preuves.

La qualité d’un système neuro-symbolique appliqué à la génération de modules métier dépend directement de la qualité de ses représentations symboliques. Il ne suffit pas de disposer d’un LLM performant ; il faut aussi disposer d’objets formels capables d’exprimer la structure du domaine, ses règles, ses dépendances et ses points de contrôle. Sans ces objets, le neuro-symbolique se réduit à une rhétorique sans vérification.

La première représentation à mettre en place est le graphe ontologique des packages. Ce graphe décrit les packages du patrimoine, leur niveau ontologique, leurs dépendances autorisées, leurs concepts racines, leurs spécialisations connues et leurs événements publiés. Ce graphe n’est pas seulement documentaire. Il sert de support de validation. Lorsqu’un moteur neuronal propose un nouveau concept ou une nouvelle dépendance, le système symbolique peut vérifier si cette proposition est légitime au regard du graphe. Si un package fondationnel reçoit une dépendance sortante vers un package sectoriel, la violation est immédiatement détectable.

La deuxième représentation est celle des contraintes de typage conceptuel. Chaque concept doit être caractérisé comme entité, rôle, relation, événement, document, accord, ressource, valeur ou état. Ces catégories ne sont pas interchangeables. Elles servent à contrôler la qualité de la modélisation générée. Si le système neuronal propose Absence comme entité durable dans un package où elle devrait être un événement, la couche symbolique peut signaler l’incohérence. De même, si un rôle comme Learner est transformé en type fondamental dans un package censé rester abstrait, le système peut exiger soit une justification, soit un reclassement.

La troisième représentation est celle des invariants de package. Un invariant encode une règle qui doit rester vraie pour toute instance légitime du module. Par exemple, dans un package party, on peut exprimer qu’un identifiant principal actif d’un type donné doit être unique pour une partie, ou qu’une relation active doit relier deux parties valides sur une période temporelle cohérente. Le rôle de la couche symbolique n’est pas seulement de stocker ces invariants, mais de les réinjecter dans la génération elle-même. Lorsque le système demande au LLM de produire la documentation ou les actions métier du package, il peut lui fournir explicitement la liste des invariants à respecter.

La quatrième représentation est celle des règles de projection. Dans un environnement réel, le patrimoine de domaine n’est utile que s’il peut être projeté vers des formats concrets : Markdown GitLab Wiki, PlantUML, XML métier, pseudo-code de services, schémas de tests. Or chacun de ces formats possède une grammaire. La couche symbolique doit donc contenir des règles ou des gabarits de projection. Le moteur neuronal se charge ensuite de remplir ces gabarits avec le contenu sémantique du module. Cette séparation entre contenu et forme réduit fortement le risque d’artefacts non intégrables.

La cinquième représentation est celle des règles de raisonnement local. Il ne s’agit pas nécessairement d’un moteur logique complet. Même des règles simples apportent beaucoup. On peut exprimer qu’un concept sectoriel doit avoir un ancêtre transverse ou fondationnel explicite, qu’un package transverse ne doit pas référencer un terme interdit issu d’un secteur précis, ou qu’une documentation de module doit mentionner explicitement sa responsabilité, ses invariants, ses événements et ses dépendances. Ce type de raisonnement symbolique sert de garde-fou permanent.

Exemple de contrainte symbolique

Prenons le package party. Une règle symbolique peut être formulée ainsi : « Aucun concept de ce package ne doit comporter un nom ou une définition directement spécifique à un secteur, sauf s’il est introduit comme simple exemple dans la documentation narrative. » Si la couche neuronale propose Student, Teacher, Patient ou Customer comme concepts centraux du package, la couche symbolique peut automatiquement demander une correction et forcer une reformulation en termes de PartyRole ou de spécialisations ultérieures.

Schéma de coopération entre représentation et génération

@startuml
rectangle "Graphe ontologique\npackages, niveaux,\ndépendances" as GO
rectangle "Contraintes de typage\nentité, rôle, relation,\névénement..." as CT
rectangle "Invariants\net règles locales" as INV
rectangle "Gabarits de projection\nMarkdown, XML, UML" as GP
rectangle "Moteur neuronal\ngénération / reformulation" as N

GO --> N : contexte structurant
CT --> N : contraintes
INV --> N : règles à respecter
GP --> N : formats cibles
N --> GO : propositions à valider
@enduml