From Business Events to Auditable Decisions: Ontology-Governed Graph Simulation for Enterprise AI

Ce papier présente LOM-action, une architecture d'IA d'entreprise qui garantit des décisions auditable et fiables en simulant de manière déterministe l'évolution des graphes d'ontologie en réponse aux événements métier, surpassant ainsi les modèles LLM conventionnels en éliminant le phénomène d'« précision illusoire ».

L'essentiel

🚦 Le Dilemme de l'IA d'Entreprise : Répondre vite ou Répondre juste ?

Imaginez que vous embauchez un super-intendant (une Intelligence Artificielle) pour gérer les affaires d'une grande entreprise. Ce super-intendant a lu tous les livres du monde : il est brillant, il parle parfaitement, et il peut répondre à n'importe quelle question instantanément.

Le problème ?
Si vous lui demandez : "Puis-je dépenser 50 000 € pour ce projet ?", il va probablement vous répondre : "Bien sûr ! C'est une excellente idée !" parce que, dans son immense bibliothèque de connaissances, dépenser de l'argent est souvent une bonne chose.

Mais il a oublié de vérifier votre réalité actuelle :

1. Votre entreprise est en période de gel des dépenses.
2. Votre département a déjà dépassé son budget.
3. Vous n'avez pas l'autorisation de signer ce montant.

L'IA a donné une réponse fluide et intelligente, mais dangereuse et fausse pour votre situation spécifique. C'est ce que les auteurs appellent une "fausse précision" (ou illusive accuracy). L'IA a l'air juste, mais elle a ignoré les règles du jeu.

---

🏗️ La Solution : LOM-action (Le "Simulateur de Réalité")

Les chercheurs de Yonyou proposent une nouvelle architecture appelée LOM-action. Au lieu de laisser l'IA répondre directement, ils lui imposent une règle stricte : "Avant de répondre, tu dois simuler la situation."

Voici comment cela fonctionne, avec une analogie simple :

1. Le Bureau des Règles (L'Ontologie)

Imaginez que l'entreprise possède un Bureau des Règles géant et vivant. Ce bureau contient non seulement les lois, mais aussi les contrats en cours, les budgets actuels, et qui a le droit de faire quoi. C'est la "vérité" de l'entreprise.

2. La Boîte de Sable (Le Sandbox)

Quand un événement arrive (ex: une demande de remboursement), l'IA ne va pas directement dans le Bureau des Règles pour chercher une réponse.
Elle prend d'abord une copie exacte du Bureau des Règles et la place dans une Boîte de Sable isolée. C'est comme un terrain de jeu sécurisé où l'on peut faire des essais sans casser le vrai système.

3. L'Acteur de Théâtre (La Simulation)

C'est ici que la magie opère. L'IA joue le rôle d'un metteur en scène dans cette Boîte de Sable :

• "Attends, ce département a un budget gelé ?" -> Action : Elle retire virtuellement les cases "argent" de la copie.
• "Ce contrat est expiré ?" -> Action : Elle efface les lignes correspondantes.
• "Ce nouveau projet ajoute une taxe ?" -> Action : Elle ajoute une nouvelle case "taxe" à la copie.

Elle transforme la copie du Bureau des Règles pour qu'elle reflète exactement la situation de votre demande spécifique. C'est la Simulation.

4. La Décision (Le Jugement)

Une fois que la copie est mise à jour (c'est maintenant le "Graphique de Simulation"), l'IA regarde uniquement cette copie modifiée pour répondre.

• Si elle demande : "Y a-t-il de l'argent ?", elle regarde la copie où l'argent a été retiré.
• Réponse : "Non, pas possible."

Et surtout, chaque étape est enregistrée. Si un auditeur demande demain : "Pourquoi avez-vous refusé ?", l'IA peut montrer le film complet : "J'ai retiré l'argent parce que le budget était gelé, comme le montre cette ligne du registre." C'est une décision traçable et vérifiable.

---

🎭 Les Deux Modes de l'IA

L'IA fonctionne comme un acteur qui change de costume selon la situation :

• Mode "Compétence" (Skill Mode) : Pour les tâches courantes (ex: "Vérifier le solde"), elle utilise des outils pré-enregistrés, comme un ouvrier qui utilise une clé anglaise. C'est rapide et précis.
• Mode "Raisonnement" (Reasoning Mode) : Pour les cas nouveaux et complexes, elle sort de sa boîte d'outils, regarde la copie de la Boîte de Sable, et réfléchit elle-même pour trouver une solution.

---

📊 Les Résultats : Pourquoi c'est révolutionnaire ?

Les chercheurs ont testé leur système contre des IA de pointe (comme Doubao ou DeepSeek). Voici ce qu'ils ont découvert :

• Les IA classiques : Elles ont eu 80% de bonnes réponses en apparence. Mais si l'on regarde comment elles ont trouvé la réponse, elles ont souvent ignoré les règles de l'entreprise. Elles ont deviné juste par chance, sans vérifier la Boîte de Sable. C'est comme un élève qui devine la réponse d'un problème de maths sans montrer ses calculs : c'est faux, même si le résultat est bon.
• LOM-action : Elle a eu 94% de bonnes réponses, mais surtout, elle a suivi 98% du processus correct. Elle a toujours vérifié la Boîte de Sable avant de répondre.

Le mot clé : "Fausse Précision" (Illusive Accuracy)
C'est le phénomène où une IA semble très intelligente (elle donne la bonne réponse) mais pour les mauvaises raisons (elle n'a pas respecté les règles). LOM-action élimine ce risque.

---

🌟 En Résumé

Imaginez que vous conduisez une voiture.

• Les IA actuelles sont comme un passager qui vous dit : "Tourne à gauche, c'est la route la plus rapide !" (Il a lu la carte, mais il ne voit pas le panneau "Route fermée" devant lui).
• LOM-action est comme un GPS intelligent qui d'abord vérifie les travaux, les bouchons et vos permissions de conduite sur une carte virtuelle, puis vous dit : "Tourne à droite, car la route de gauche est fermée aujourd'hui."

L'objectif n'est pas seulement d'avoir une IA qui parle bien, mais d'avoir une IA qui prend des décisions sûres, vérifiables et conformes aux règles de l'entreprise. C'est la différence entre un conseiller brillant mais imprévisible, et un gestionnaire de confiance qui ne fait jamais d'erreur de procédure.

Résumé technique

1. Problématique : L'échec architectural des agents LLM en entreprise

L'article identifie une défaillance fondamentale dans les systèmes d'agents basés sur les grands modèles de langage (LLM) actuels lorsqu'ils sont appliqués à l'entreprise :

• Espace de connaissance non restreint : Les LLM génèrent des réponses en puisant dans un espace de connaissances illimité et statique, sans simuler comment les conditions métier actives (contrats, politiques de dépenses, portée organisationnelle) modifient ce contexte.
• Fluence sans ancrage : Les réponses sont souvent fluides et grammaticalement correctes, mais elles ne sont pas dérivées du graphe de connaissances tel qu'il est défini par le scénario métier réel.
• Absence de traçabilité : Ces décisions ne possèdent pas de piste d'audit (audit trail) vérifiable.
• Le phénomène de « Précision Illusive » (Illusive Accuracy) : Les modèles peuvent atteindre une haute précision sur la réponse finale (Acc) tout en échouant totalement à suivre le processus de raisonnement requis (F1 de la chaîne d'outils), donnant une fausse impression de fiabilité.

2. Méthodologie : LOM-action et la Simulation de Graphe

L'article propose LOM-action, une architecture qui introduit une simulation de graphe pilotée par les événements et régie par une ontologie d'entreprise (EO). Le principe central est que la décision ne doit jamais être prise sur le graphe statique, mais uniquement sur une copie évolutive du graphe, mise à jour selon les conditions du scénario.

Le Pipeline : Événement → Simulation → Décision

Le processus se déroule en trois phases strictes :

1. Phase 1 : Analyse du Scénario (Scenario Parsing)
   • Le système reçoit un événement métier structuré.
   • Il aligne l'événement sur les sémantiques de l'ontologie d'entreprise (EO) pour identifier les conditions de scénario actives (prédicats de contrainte ou d'augmentation).
   • Pour les scénarios complexes, cela génère un « programme de scénario » (séquence d'opérations graphiques).
2. Phase 2 : Simulation en Bac à Sable (Sandbox Simulation)
   • Une copie du graphe d'entreprise est instanciée dans un environnement isolé (bac à sable) avec un graph_id unique.
   • Les conditions du scénario sont appliquées de manière déterministe via des appels d'API (ex: suppression de nœuds non autorisés, ajout de nouvelles entités).
   • Cela produit le graphe de simulation valide ($G_{sim}$), qui est la seule base autorisée pour la prise de décision.
   • Note : Le graphe d'entreprise original (EO) n'est jamais modifié.
3. Phase 3 : Dérivation de la Décision
   • La décision (ex: chemin le plus court, vérification de connectivité) est calculée exclusivement sur $G_{sim}$.
   • Chaque étape est journalisée pour créer une trace de décision entièrement traçable et rejouable.

Architecture à Double Mode

LOM-action utilise une architecture hybride pour gérer les requêtes :

• Mode Compétence (Skill Mode) : Si une compétence est enregistrée dans l'ontologie (ex: calcul de flux maximal), le modèle appelle directement l'outil correspondant sur le bac à sable. Le graphe brut ne rentre jamais dans le contexte du LLM.
• Mode Raisonnement (Reasoning Mode) : Si aucune compétence enregistrée ne couvre la tâche, le modèle fusionne les sous-graphes pertinents, les élimine du bruit, et effectue un raisonnement en contexte (in-context reasoning) sur cette représentation compacte.

Principes de Déploiement

L'article définit quatre principes clés pour l'IA d'entreprise :

1. Minimiser la logique métier dans le code ; la maximiser dans l'ontologie.
2. Tout contexte doit être ancré dans l'ontologie (aucune chaîne brute non résolue).
3. Privilégier les modèles LOM (fine-tunés) aux LLM de pointe pour les tâches de raisonnement, en utilisant les grands modèles uniquement pour les tâches qu'ils ne peuvent pas gérer.
4. Gouverner l'environnement : LOM agit comme un « juge » (LOM-as-Judge) pour valider les sorties des outils avant qu'elles ne soient écrites.

3. Contributions Clés

1. Innovation de Simulation de Scénario : Introduction d'une étape de simulation de bac à sable obligatoire où les prédicats de contrainte autorisés par l'EO modifient le graphe avant toute décision. Cela comble l'écart de simulation laissé par les LLM de pointe.
2. Innovation de Dérivation de Décision : Mise en œuvre du pipeline séquentiel via une architecture à double mode, garantissant que chaque décision produit une trace d'audit rejouable.
3. Principe « Simulation First » et Indice de Précision Illusive :
   • Définition de l'indice IA(M) = Acc(M) - F1_chain(M).
   • Démonstration qu'une haute précision (Acc) sans un F1 de chaîne d'outils élevé indique un échec de conformité et d'audit, même si la réponse semble correcte.

4. Résultats Expérimentaux

L'évaluation a été réalisée sur un benchmark de 11 tâches (2 200 échantillons d'entraînement, 1 100 tests) comparant LOM-action (basé sur Qwen3.5-27B, fine-tuné) à deux modèles de pointe en mode zéro-shot : Doubao-1.8 et DeepSeek-V3.2.

• Précision Globale (Accuracy) :
  • LOM-action : 93,82 %
  • Doubao-1.8 : 80,00 %
  • DeepSeek-V3.2 : 80,18 %
• F1 de la Chaîne d'Outils (Tool-Chain F1) : C'est la métrique critique mesurant la conformité au processus de simulation.
  • LOM-action : 98,74 %
  • Doubao-1.8 : 24,42 %
  • DeepSeek-V3.2 : 36,21 %
• Phénomène de Précision Illusive :
  • Sur les tâches de base (traversée de graphe), les modèles de base atteignent ~98-100 % de précision mais un F1 de 0,00. Ils donnent la bonne réponse en contournant la simulation (en utilisant leur connaissance paramétrique), ce qui est inacceptable pour l'audit.
  • LOM-action montre un avantage de 4 fois en termes de F1, prouvant que l'architecture de simulation régie par l'ontologie est supérieure à la simple mise à l'échelle du modèle.
• Tâches de Simulation de Scénario : Sur les tâches où le graphe doit être modifié avant la décision (ex: fc_constraint_connection), LOM-action atteint 100 % de précision contre ~64-66 % pour les baselines, confirmant que le contournement de la phase de simulation conduit à des décisions erronées dans un contexte métier.

5. Signification et Conclusion

L'article conclut que l'IA d'entreprise ne peut pas être construite uniquement sur des LLM généralistes. La fiabilité et l'auditabilité des décisions d'entreprise dépendent d'une architecture qui force la simulation des conditions de scénario avant toute inférence.

• Changement de paradigme : Le passage d'une IA qui « répond à partir de l'espace de connaissances non restreint » à une IA qui « répond à partir du graphe évolué par le scénario ».
• Implication architecturale : La simulation n'est pas une optimisation, c'est une condition préalable non négociable. Un système qui optimise avant de simuler est intrinsèquement inadapté à l'entreprise.
• Avenir : Les travaux futurs visent à intégrer le standard SKILLS (ontologie formelle pour les compétences), à renforcer la gouvernance via la boucle RAC (Reason-Align-Construct), et à valider l'approche à l'échelle de l'entreprise (grands graphes, domaines financiers/HR).

En résumé, LOM-action démontre que la confiance dans l'IA d'entreprise ne vient pas de la taille du modèle, mais de la rigueur de l'architecture de simulation régie par l'ontologie, garantissant que chaque décision est auditable, traçable et dérivée du contexte métier réel.