Résumé technique : Les graphes de connaissances comme couche de données manquante pour les opérations d'actifs industriels basées sur les LLM

Énoncé du problème

Les agents actuels de modèles de langage (LLM) destinés aux opérations d'actifs industriels présentent une précision limitée lorsqu'ils raisonnent sur des dépôts de documents plats (par exemple, CouchDB, YAML, CSV). Le benchmark AssetOpsBench (Patel et al., 2026) a établi que même les modèles de pointe comme GPT-4 et GPT-4.1 atteignent un taux maximal d'achèvement des tâches d'environ 65 % sur 139 scénarios de maintenance industrielle. L'étude a identifié que les échecs ne sont souvent pas dus à un manque de capacité de raisonnement, mais plutôt à des « échecs d'accès aux données ». Plus précisément, les LLM éprouvent des difficultés avec des opérations que les moteurs de requêtes structurées gèrent de manière déterministe, telles que :

• Compter les événements à travers plusieurs documents non structurés.
• Corréler des données provenant de sources disparates sans liens explicites.
• Parcourir les dépendances implicites entre équipements.
• Éviter les hallucinations d'identifiants d'équipement ou de lectures de capteurs.

L'hypothèse centrale de cet article est que, pour les domaines opérationnels structurés, le modèle de données sous-jacent aux outils constitue le goulot d'étranglement principal, et non le paradigme d'orchestration des LLM.

Méthodologie

Les auteurs ont évalué trois architectures distinctes en utilisant les mêmes 139 scénarios AssetOpsBench, en faisant varier uniquement la couche de données et le rôle du LLM :

1. Architecture A (Référence - LLM augmenté par des outils) :

   • Mécanisme : Le LLM analyse l'intention, sélectionne les outils, formule des arguments, récupère les données brutes depuis des dépôts de documents, interprète les résultats et synthétise une réponse.
   • Couche de données : Dépôts de documents plats (CouchDB, YAML, CSV).
   • Rôle du LLM : Effectue tout le raisonnement, la traversal des données et l'agrégation.

2. Architecture B (NLQ + Graphe) :

   • Mécanisme : Le LLM est contraint de générer des requêtes Cypher structurées basées sur un schéma typé. Le moteur de graphe exécute la requête de manière déterministe, et le LLM synthétise la réponse finale à partir des résultats structurés.
   • Couche de données : Un graphe de connaissances (KG) typé comportant 781 nœuds, 955 arêtes et 16 types de relations (étendu à 1 360 nœuds et 2 500 arêtes dans le pipeline complet).
   • Rôle du LLM : Génération de code (Langage naturel vers Cypher).

3. Architecture C (Gestionnaires déterministes) :

   • Mécanisme : Des gestionnaires pré-codés correspondent directement aux motifs de questions et aux requêtes Cypher.
   • Couche de données : Le même graphe de connaissances.
   • Rôle du LLM : Aucun.

Construction du graphe de connaissances :
Les auteurs ont construit un pipeline ETL transformant les sources de données AssetOpsBench en un schéma de graphe contenant 14 étiquettes de nœuds (par exemple, Site, Équipement, Capteur, Mode de défaillance) et 21 types d'arêtes (par exemple, contient_équipement, surveille, dépend_de). Le graphe inclut :

• Des hiérarchies d'équipements avec les classifications ISA-95 et ISO 14224.
• Des métadonnées de capteurs liées aux équipements.
• Des modes de défaillance avec des embeddings Sentence-BERT de 384 dimensions pour la recherche de similarité vectorielle.
• Des journaux d'événements avec des capacités temporelles.
• Une topologie de dépendance modélisant les dépendances thermiques/électriques et les infrastructures partagées.

L'implémentation utilise Samyama, une base de données de graphes intégrée prenant en charge OpenCypher, l'indexation vectorielle HNSW et les algorithmes de graphes (PageRank, NSGA-II).

Résultats clés

Performance sur 139 scénarios

L'étude démontre une amélioration significative des performances en changeant la couche de données, même en maintenant le modèle LLM constant :

• Architecture A (Référence) : Taux de réussite de 65 % (91/139), correspondant au plafond du classement AssetOpsBench.
• Architecture B (NLQ + Graphe) : Taux de réussite de 82–83 % (114–116/139) utilisant GPT-4, GPT-4o et GPT-4.1. Cela représente une amélioration d'environ 17 points de pourcentage par rapport à la référence en utilisant la même famille de modèles.
• Architecture C (Déterministe) : Taux de réussite de 99 % (137/139). Les deux échecs ont été attribués à des incohérences de format de réponse dans le regroupement des ordres de travail, et non à des lacunes de connaissances.

Évaluation élargie (467 scénarios)

Lors de l'évaluation contre la version étendue AssetOpsBench publiée sur HuggingFace (467 scénarios répartis sur 6 domaines) :

• Gestionnaires déterministes : Ont atteint un taux de réussite de 100 % (467/467) avec un score moyen de 0,848.
• Capacités natives du graphe : Les auteurs ont introduit 40 nouveaux scénarios nécessitant une dépendance multi-sauts, une similarité vectorielle et une criticité PageRank. Sur ces derniers, l'approche par graphe de connaissances a atteint un taux de réussite de 100 % et un score moyen de 0,927, contre 85 % et 0,602 pour une référence GPT-4o sans graphe.

Latence et coût

• Latence : Les requêtes de graphe déterministes ont affiché une moyenne de 63 ms, contre 5 à 11 secondes pour les architectures basées sur les LLM.
• Coût : Pour 10 000 requêtes quotidiennes, une architecture entièrement pilotée par LLM coûte 300–500 $, tandis que les requêtes de graphe déterministes coûtent 0 $ après l'ETL initial.

Signification et revendications

L'article postule que la couche de données est le goulot d'étranglement principal dans les domaines opérationnels structurés, agissant comme un levier plus significatif pour l'amélioration des performances que les paradigmes d'orchestration des LLM (Agent-Comme-Outil vs Plan-Exécuter).

Les auteurs introduisent le concept d'« Utilisation inversée des LLM » :

• Au lieu de demander au LLM de raisonner sur des données brutes (une tâche large et sujette aux erreurs), le système demande au LLM de générer des requêtes structurées à partir d'un schéma typé (une tâche étroite de génération de code où les LLM excellent).
• Le moteur de graphe gère ensuite les parties « difficiles » : la traversal, le comptage, les jointures et l'exécution algorithmique.
• Cette séparation des préoccupations permet au système d'atteindre une précision quasi parfaite sur les motifs de requêtes connus tout en conservant la flexibilité des interfaces en langage naturel pour les requêtes nouvelles.

L'article conclut que pour les données industrielles structurées, les graphes de connaissances servent de couche d'intégration essentielle entre les données brutes et le raisonnement basé sur les LLM. Les résultats suggèrent que la génération de requêtes consciente du schéma surpasse le raisonnement sur des données libres pour tout domaine structuré, et que des gestionnaires déterministes peuvent atteindre une fiabilité quasi parfaite pour les motifs opérationnels connus.

Limites et mises en garde

Les auteurs notent explicitement plusieurs limites :

• Hypothèse de données propres : Le benchmark utilise des données propres et structurées. Les environnements industriels réels impliquent des capteurs bruyants, des PDF numérisés et des noms incohérents, ce qui nécessite des LLM au niveau de l'ingestion des données (extraction et résolution d'entités) plutôt que seulement au niveau de la requête.
• Déterministe vs Autonome : Le taux de réussite de 99 % de l'Architecture C reflète une solution pré-codée, et non la capacité d'un agent autonome à trouver des réponses indépendamment.
• Limites structurelles : Les scénarios nécessitant une inférence ML (par exemple, prévision de séries temporelles, prédiction de durée de vie restante) ne peuvent pas être résolus par la simple interrogation de données stockées ; ils nécessitent des modèles analytiques externes.
• Nondéterminisme : Les résultats NLQ reposent sur une génération stochastique par les LLM ; la caractérisation de la variance sur plusieurs graines est reportée à un travail futur.