Un chatbot pour les données d’arrêt ouvre de nouvelles voies dans la production

De la perturbation opérationnelle aux insights basés sur les données – Comment un chatbot IA basé sur la Retrieval Augmented Generation révolutionne l’analyse des pannes de machines.

Introduction : Quand l’arrêt des machines devient un problème d’information

Dans les environnements de fabrication modernes, minimiser les arrêts est crucial, car chaque minute d’interruption  entraîne des coûts considérables et réduit le  temps de production. Malgré le soutien logiciel des systèmes d’exécution de la fabrication (MES), une grande partie du potentiel d’analyse rapide des données reste inexploitée. Les rapports d’incidents sont souvent non structurés et dispersés sur plusieurs systèmes, ce qui complique leur analyse.

C’est là qu’intervient un prototype basé sur les grands modèles de langage (LLM) combinés à la Retrieval Augmented Generation (RAG). Son objectif : permettre un accès immédiat et précis aux données d’arrêt en langage naturel, les interpréter et les exploiter pour optimiser la production au quotidien.

Les données d’arrêt et leurs trésors inexploités

Dans l’exemple de projet spécifique chez Hoffmann Neopac AG, un fabricant de premier plan d’emballages plastiques haut de gamme, toutes les perturbations d’installations sont enregistrées sous forme de « Notes d’arrêt » directement sur le panneau de ligne.  En parallèle, des capteurs collectent des données de performance telles que la vitesse et le taux de rebut par machine.

Plusieurs défis se posent :

• Les données d’arrêt sont souvent non structurées, car elles sont consignées sous forme de notes libres.
• Des analyses détaillées, comme l’identification des matériaux à l’origine des arrêts fréquents ou des pannes récurrentes sur certaines lignes, nécessitent des compétences avancées en analyse de données.
• De nombreux collaborateurs  ne disposent ni des connaissances techniques ni du temps nécessaire pour effectuer des analyses complexes.

Le résultat : des informations précieuses restent souvent inexploitées, car le traitement des données est perçu comme trop complexe.

RAG comme solution: Comment les modèles d’IA intègrent des sources de connaissances externes

RAG répond précisément à cette problématique. Alors que les modèles de langage classiques (LLM) ne tirent leur « monde » que des vastes quantités de texte dans leur ensemble de données d’entraînement, RAG leur permet d’accéder à des sources de connaissances supplémentaire. Cette connaissance supplémentaire peut être une base de données, un système de fichiers ou internet.

La Figure 1 illustre le flux du workflow RAG [1]

Le processus se déroule en trois étapes :

1. Retrieve : Une requête, comme « Montre-moi les causes d’erreur les plus courantes en août sur la ligne 1 », est envoyée par l’utilisateur à un récupérateur. Celui-ci recherche dans une source de connaissances et récupère les informations pertinentes.
2. Augment : Les entrées trouvées sont combinées avec la requête originale et transmises au modèle de langage (LLM) en tant que contexte étendu ({Requête + Information}).
3. Generate : Le LLM crée une réponse contextuelle et factuelle. Ce processus empêche la création de contenu inventé (« hallucinations ») et permet des réponses précises à partir des données spécifiques de l’entreprise sans avoir à réentraîner le modèle lui-même.

Neo4j et Chatbot : Une architecture pour les données structurées

Pour que le système comprenne les liens entre produit, ligne et catégorie de panne, une approche basée sur une base de données graphe est utilisée. Le prototype s’appuie sur Neo4j AuraDB [2] , où des entités telles que « Downtime » et « TubeLine » sont stockées sous forme de nœuds, tandis que lesrelations comme « OCCURS_ON » (arrêt sur une ligne) sont représentées par des arêtes. Un tel modèle de graphe est particulièrement adapté aux LLM, car il peut être facilement représenté en langage naturel. Les LLM reconnaissent les modèles linguistiques et les relations au sein de la structure du graphe. De plus, le langage de requête Cypher [3] , spécialement développé pour les bases de données graphes, est plus intuitif et lisible que SQL (Structured Query Language), notmment lorsqu’il s’agit de gérer des relations complexes entre plusieurs entités.

La Figure 2 illustre l’architecture du chatbot et montre l’interaction entre les composants individuels :

1. Frontend du Chatbot : Via un tableau de bord Streamlit [4] , les utilisateurs peuvent faire des requêtes en langage naturel. Le frontend transmet la requête à l’Agent LangChain, qui génère une requête appropriée et renvoie le résultat en texte brut.
2. API du Chatbot : C’est ici que s’exécute le workflow RAG proprement dit, contrôlé par la bibliothèque LangChain [5] . L’Agent LangChain décide, en fonction de la question, d’utiliser la Neo4j Cypher Chain (pour les requêtes de données structurées) ou la Downtime Vector Chain (pour les recherches sémantiques). Les requêtes correspondantes sont transmises à Neo4j AuraDB, et les résultats alimentent la génération de réponse.
3. Database Neo4j : Contient toutes les données traitées provenant des diverses sources de données.

Ce processus empêche la création de contenu inventé (« hallucinations ») et permet des réponses précises à partir des données spécifiques de l’entreprise sans avoir à réentraîner le modèle lui-même.

Cypher Chain et Vector Chain : Deux approches pour différents types de données

Pour les informations structurées comme les données de production, la Cypher Chain est la plus appropriée. Dans ce casle LLM effectue des recherches dans la base de données graphe à l’aide de requêtes Cypher. La situation est différente avec les Downtime-Notes, qui contiennent des rapports de perturbation courts et similaires. Ici, on utilise la Vector Chain, basée sur la recherche vectorielle sémantique . Les Downtime-Notes sont converties en vecteurs à l’aide de modèles d’embedding et stockées. Ces modèles traduisent des mots ou des phrases en vecteurs numériques pour capturer des termes similaires. De cette façon, les formulations sémantiquement équivalentes sont également reconnues. Neo4j peut être étendu de manière flexible en tant que base de données vectorielle. Les requêtes sont également converties en vecteurs d’embedding et comparées à l’aide de métriques de distance pour trouver des rapports de perturbation correspondants, même lorsque les formulations diffèrent les unes des autres.

Évaluation : Précision, coût, temps d’inférence

Une préoccupation centrale était l’évaluation de différents modèles d’IA. Dans une première phase de prototype, des LLM d’OpenAI ont été testés [6] . Les résultats pour 30 questions test (anglais et allemand) montrent :

• gpt-4o-mini s’est avéré être le « sweet spot » : Haute précision (plus de 86 % en anglais, jusqu’à 90 % en allemand) combinée à des coûts faibles et des temps de réponse courts.
• gpt-4o a fourni des résultats tout aussi précis dans certains cas, mais était plusieurs fois plus coûteux.
• gpt-3.5-turbo était abordable mais parfois imprécis pour des requêtes. complexes.

Surtout pour les entreprises qui adressent un grand nombre de questions par semaine à leur chatbot, le  temps d’inférence et les coûts sont des critères déterminants. Dans ce contexte, le modèle 4o-mini, plus léger, offre un équilibre attractif.

Conclusion : Un nouveau standard pour des décisions basées sur les données

Le chatbot LLM-RAG démontre comment les modèles d’IA peuvent apporter une réelle valeur ajoutée dans l’industrie. Au lieu de recherches laborieuses, les spécialistes reçoivent rapidement des réponses précises sur les temps d’arrêt, les causes d’erreur et les chiffres de performance. L’interaction entre la base de données graphe et la Retrieval Augmented Generation offre des analyses précises et contextualisées. L’utilisation de l’IA dans l’environnement de production ne se limite plus aux prévisions ou à la maintenance prédictive. Grâce aux  solutions RAG, les sources de données spécifiques à l’entreprise peuvent être utilisées efficacement pour prendre des décisions éclairées. Le résultat est une efficacité accrue, des coûts réduits et une transparence améliorée dans la production – un pas décisif vers l’usine intelligente.

References

1 A. Kimothi, „1 Large Language Models and the Need for Retrieval Augmented Generation,“ in A Simple Guide to Retrieval Augmented, Manning Publications, 2024, pp. 1-17.

2 Neo4j Inc., „Neo4j AuraDB: Fully Managed Graph Database,“ 2025. [Online]. Available: https://neo4j.com/product/auradb/. [Zugriff am 10 03 2025].

3 Neo4j Inc., „Cypher Manual,“ 2025. [Online]. Available: https://neo4j.com/docs/cypher-manual/current/introduction/. [Zugriff am 10 03 2025].

4 Snowflake Inc., „A faster way to build and share data apps,“ 2024. [Online]. Available: https://streamlit.io/. [Zugriff am 10 03 2025].

5 LangChain, „Applications that can reason. Powered by LangChain,“ 2025. [Online]. Available: https://www.langchain.com/. [Zugriff am 10 03 2025].

6 OpenAI, „OpenAI Platform,“ 2025. [Online]. Available: https://platform.openai.com/docs/models. [Zugriff am 10 03 2025].