Graphe de connaissances pour pont roulant LXD
Solution Technique — Graphe de Connaissances pour le Diagnostic des Pannes de Pont Roulant
Le graphe de connaissances transforme les données dispersées de la maintenance des ponts roulants — enregistrements de pannes, ordres de travail, données de pièces de rechange et paramètres d'équipement — en un réseau sémantique structuré. La chaîne technique comprend quatre niveaux : la couche de données (ordres de maintenance / enregistrements de pannes / alertes de capteurs / remplacements de pièces / normes industrielles / manuels d'équipement), la couche d'extraction des connaissances (reconnaissance d'entités BiLSTM+CRF + extraction de relations, F1=91,2 %), la couche de stockage du graphe (Neo4j Enterprise 5.x, modèle de graphe orienté propriétés, ≥ 500 000 nœuds), et la couche applicative (raisonnement diagnostique / recommandation de plans de maintenance / recherche de pannes similaires / Q&R intelligente). Le système est déployé dans la base de connaissances interne de Kelude, couvrant 8 types de ponts roulants, 243 modes de panne et 1 580 cas de panne.
Le diagnostic des pannes d'un pont roulant repose traditionnellement sur l'expérience individuelle des ingénieurs de maintenance. Sur un cycle de vie de 15 à 20 ans, de l'installation à la mise hors service, un pont roulant génère des centaines d'ordres de travail et d'enregistrements de pannes — mais ces données structurées ou semi-structurées, dispersées dans différents systèmes (ERP, CMMS, Excel), ne constituent pas un actif de connaissances réutilisable. La technologie du graphe de connaissances, via la reconnaissance d'entités nommées (NER), l'extraction de relations (RE) et le stockage en graphe (Neo4j), transforme ces informations fragmentées en un réseau sémantique reliant équipement, panne, cause, mesure et pièce de rechange. Cet article s'appuie sur la construction de la base de connaissances de pannes de Kelude Industries Lourdes pour présenter l'ensemble de la solution d'ingénierie, de la collecte des données au raisonnement par requête sur le graphe. La solution technique ci-dessous se réfère à la documentation officielle Neo4j (Neo4j Graph Data Science Manual v5.x, 2024), au kit d'outils de traitement du langage naturel HanLP (version 2.1, 2023) et à l'expérience de déploiement réelle du projet de base de connaissances de pannes de Kelude (n° de projet KL-KG-2024-001).
Sources de données et entités du graphe de connaissances pour le diagnostic de pannes
Les données du graphe de connaissances pour les pannes de pont roulant proviennent de quatre dimensions : ① les dossiers d'équipement (modèle / capacité / portée / hauteur de levage / classe de fonctionnement / numéro de série / date de mise en service) ; ② les ordres de travail de panne (date de la panne / numéro d'équipement / symptôme / code de défaut / processus de recherche de panne / mesure de maintenance / pièce de rechange remplacée / technicien / durée d'arrêt) ; ③ les données de capteurs (valeur efficace de vibration / température / courant / historique des dépassements de charge) ; ④ les normes industrielles (clauses de jugement de panne pertinentes des normes ISO 4301 / TSG 51 — Règlement technique de sécurité des équipements spéciaux / FEM 1.001, entre autres). Après extraction des entités et des relations, 6 types d'entités et 9 types de relations sont définis :
| Type d | Nom d | Exemple | Ordre de grandeur |
|---|---|---|---|
| pont roulantÉquipement | Crane | QD32t-023/ LD10t-156 | 500+ |
| Symptôme de panne | Fault | Levageglissement de charge/gougeage du rail du pont roulant/Frein Bruit anormal | 243 Type |
| Cause de panne | Cause | Garniture de frein Usure/Surface de Roulement Piqûre/Accouplement Flanc de dent Usure | 480+ |
| Maintenance Mesure | Action | Remplacement Garniture de frein/réglage Jeu de frein/Remplacement Accouplement | 620+ |
| Pièce de Rechange Matériau | Part | YWZ5-315/23Frein/Roue ZGY-600 | 1,200+ |
| Norme Clause | Standard | norme ISO 4301 / FEM 1.001《grue Conception Spécification Interprétation des clauses clés: Charge/Structure/Mécanisme/Électrique/Cinq grands systèmes de sécurité》 5.2.3 | 80+ |
| Type de relation | Nœud source / Nœud cible | Description |
|---|---|---|
| has_fault | Crane Fault | Un certain appareilpont roulant A subi une panne |
| has_symptom | Fault | A subi une panne APanne associée BApparition simultanée |
| caused_by | Fault Cause | Une panne causée par une cause |
| resolved_by | Fault Action | Une panne résolue par une mesure |
| uses_part | Action Part | Une mesure nécessitant le remplacement de Pièce de Rechange |
| ref_standard | Fault Standard | Lié à la panne Norme Clause |
| similar_to | Fault | A subi une panne AAvec la panne BSimilaire(Similarité cosinus＞0.8) |
| located_in | Crane Location | pont roulant Situé à Atelier/Section de production |
| occurred_at | Fault Time | Moment de la panne |
Extraction d'entités et de relations — Implémentation BiLSTM+CRF
L'extraction des connaissances constitue l'étape la plus critique de la construction du graphe. Le système s'appuie sur un modèle de séquençage BiLSTM+CRF (réseau de mémoire bidirectionnelle à long terme + champ aléatoire conditionnel), avec HanLP 2.1 comme pipeline de prétraitement (segmentation, étiquetage morphosyntaxique et analyse de dépendances). L'entraînement a été réalisé sur 2 400 textes de pannes de ponts roulants annotés manuellement. Le schéma d'annotation BIOES (Begin/Inside/Outside/End/Single) est utilisé, avec 6 types d'entités × BIOES = 30 étiquettes d'annotation.
Stockage Neo4j et requêtes Cypher pour graphe de connaissances
Les triplets extraits (entité tête - relation - entité queue) sont stockés dans la base de données graphe Neo4j Enterprise 5.x. Le modèle Labeled Property Graph est utilisé : chaque nœud porte un label, et chaque relation possède un type et une direction. Volume de données : ≥58 000 nœuds et ≥126 000 relations (au 30 juin 2026).
Exemple de requête Cypher typique :
// RequêteQD32t-023Historique complet des défauts du pont roulant et mesures de maintenance associées MATCH (c:Crane {id: 'QD32t-023'})-[r1:has_fault]->(f:Fault) OPTIONAL MATCH (f)-[r2:resolved_by]->(a:Action) OPTIONAL MATCH (a)-[r3:uses_part]->(p:Part) RETURN f.name AS symptôme de panne, a.name AS Historique complet des défauts du pont roulant et mesures de maintenance associées, p.name AS Remplacement de pièces de rechange ORDER BY f.severity DESC// Raisonnement diagnostique par parcours de graphe：Un pont roulant présente"Glissement de charge au levage"，Pistes de diagnostic et pièces de rechange recommandées MATCH path = (f:Fault {name: 'Glissement de charge au levage'})-[*1..2]-(n) WHERE ANY(label IN labels(n) WHERE n:Action OR n:Part OR n:Cause) RETURN path LIMIT 30// Recherche de défauts similaires（Basé sur les causes communes+des mesuresJaccardSimilarité） MATCH (f1:Fault {name: 'Bruit anormal du frein'})-[r1]->(n) MATCH (f2:Fault)-[r2]->(n) WHERE f2 <> f1 WITH f2, COUNT(DISTINCT n) AS common, COLLECT(DISTINCT n.name) AS shared_nodes ORDER BY common DESC LIMIT 5 RETURN f2.name, common, shared_nodesRaisonnement sémantique et question-réponse intelligente
La valeur d'un graphe de connaissances réside dans sa capacité de raisonnement. Le système prend en charge trois modes de raisonnement :
①Raisonnement par règles — basé sur un arbre de décision prédéfini pour le diagnostic de pannes (ensemble de règles IF-THEN, rédigé par 3 ingénieurs seniors en maintenance de ponts roulants, couvrant 8 types d'équipements × 243 pannes × 480+ causes, soit 1 520 règles au total), implémenté par parcours de graphe Cypher pour un diagnostic automatique ;
②Raisonnement par classement de chemins — à partir d'un nœud de panne donné, les solutions de maintenance candidates sont classées par marche aléatoire (Personalized PageRank, 20 itérations, probabilité de redémarrage 0,15). Précision Top-3 : 86,4% (ensemble de validation N=500) ;
③Question-réponse sémantique — conversion NL2Cypher basée sur des modèles (transformation de requêtes en langage naturel en requêtes Cypher), prenant en charge 12 modèles de questions (par exemple « Quelles pannes ce pont roulant a-t-il rencontrées ? » MATCH(c:Crane)...).
Approche traditionnelle vs graphe de connaissances : comparaison
| Élément de comparaison | Solution traditionnelle(Base de données relationnelle+Recherche par mots-clés) | Solution de graphe de connaissances(Neo4j+Raisonnement sémantique) |
|---|---|---|
| Modèle de données | Table bidimensionnelle, Association par clé étrangère | Graphe de propriétés, Nœud-Relation-Propriété |
| Requête de corrélation de pannes | Multi-tables JOIN(3~5Tables), Temps de réponse500ms~3s | Parcours de graphe, Temps de réponse＜50ms |
| Raisonnement multi-sauts(Par exemple: Causes et mesures de panne Pièce de Rechange) | Nécessite4Occurrence SQLRequête de corrélation de pannes+Assemblage au niveau applicatif | Unique Cypher Parcours de graphe[1..4]Saut |
| Détection de pannes similaires | Basé sur la correspondance de mots-clés d, Faible précision | Basé sur la structure du graphe Jaccard Similarité cosinus+Page Rank |
| Réutilisation des connaissances | Dépend de l, Perte de connaissances due à la rotation du personnel | Stockage persistant du graphe de connaissances, Partage d |
| Démarrage à froid de nouveaux équipements | Nécessite l | Raisonnement par transfert basé sur la structure du graphe d |
| Flexibilité des requêtes | Rapports prédéfinis, Requêtes ad hoc nécessitant développement | Cypher Requête ad hoc, Web En libre-service via l |
Questions Fréquentes
Q : Quelle quantité de données est nécessaire pour qu’un graphe de connaissances soit réellement exploitable ?
A : Pour démarrer, il est recommandé de disposer d’au moins 500 enregistrements de défauts (incluant symptôme + cause + mesure corrective), ce qui correspond à environ 6 000 à 8 000 entités et 12 000 à 15 000 relations. À cette échelle, le taux de précision des recommandations de défauts Top-3 dépasse 70 %. Lorsque le volume de données atteint 2 000+ enregistrements (l’échelle actuelle de ce projet), la précision monte à 86 %. En phase de démarrage à froid, il est possible d’importer des données publiques sur les défauts et des clauses de normes comme base de connaissances initiale.
Q : Quelle est la différence fondamentale entre Neo4j et MySQL/PostgreSQL pour la gestion des connaissances de défauts ?
A : La différence clé réside dans l’efficacité des requêtes multi-sauts. Par exemple, pour interroger « les mesures de maintenance des défauts similaires à ceux déjà rencontrés sur un pont roulant donné », MySQL nécessite 5 à 8 jointures (réponse en secondes), et une fois la structure des tables figée, il est difficile d’ajouter de nouvelles dimensions de relations. Neo4j, grâce à la correspondance de motifs à longueur variable `[*1..4]`, exécute une seule requête Cypher avec une réponse inférieure à 50 ms. De plus, le modèle de graphe supporte nativement l’extension horizontale : l’ajout de nouveaux types d’entités ou de relations ne requiert aucune modification de schéma.
Q : Quelle quantité de données annotées manuellement est nécessaire pour l’extraction des entités et relations ?
A : Ce projet utilise 2 400 données annotées manuellement (28 600 entités, 12 400 relations), pour un coût d’annotation d’environ 1 536 € (3 annotateurs × 10 jours × 51 €/jour). Si le budget d’annotation est limité, une approche par supervision à distance (Distant Supervision) peut être adoptée : elle exploite les tables BOM de pièces de rechange et les codes de défaut existants pour générer automatiquement des données faiblement annotées, puis une vérification manuelle est effectuée. Cette méthode permet de réduire le volume d’annotation à 400 à 600 enregistrements, au prix d’une baisse de la valeur F1 de 91,2 % à environ 85 %.
Q : Les 12 modèles de requêtes NL2Cypher sont-ils suffisants ?
A : Les 12 modèles couvrent environ 85 % des scénarios de requêtes quotidiennes sur la base de connaissances de défauts (selon les statistiques des journaux de maintenance de Kelude sur 3 mois). Les modèles se répartissent en 3 catégories fonctionnelles : requêtes de défauts (défaut d’un équipement, cause d’un défaut, mesures associées à une cause), requêtes de pièces de rechange (pièces utilisées pour une mesure, mesures compatibles avec une pièce) et requêtes d’analyse statistique (fréquence des défauts TOP N, équipements avec le cycle de maintenance le plus long). Les requêtes en langage naturel qui sortent du cadre de ces modèles sont actuellement traitées par une suggestion de syntaxe Cypher complétée manuellement.
