5 Die meisten Angebote zur KI-gestützten vorausschauenden Wartung versprechen dasselbe: ein Modell, das einen nahenden Ausfall früher bemerkt als ein Mensch. Dieses Versprechen ist real, und die Erkennung hat sich stark verbessert. Ein Alarm ist aber nur der erste Schritt einer Reparatur. Jemand muss immer noch herausfinden, welche Komponente ausfällt, um welche Art von Ausfall es sich handelt und wie dringend er ist. In diesem zweiten Schritt liegen die schwierigen Probleme. Und genau dieser Schritt wird am wenigsten gemessen. Was KI-gestützte vorausschauende Wartung tatsächlich leistet Vorausschauende Wartung nutzt Telemetriedaten von Anlagen, um abzuschätzen, wann etwas ausfallen wird, damit Arbeiten vorher eingeplant werden können. Die Anlage kann eine Pumpe, eine Turbine, eine Fahrzeugflotte oder ein Serverrack sein. Die Daten sehen in jedem Fall ähnlich aus: viele Sensoren, die jeweils eine Zeitreihe liefern und kontinuierlich abgetastet werden. KI kommt auf drei Ebenen ins Spiel, und es lohnt sich, sie getrennt zu betrachten. Erkennen. Geschieht gerade etwas Ungewöhnliches, und wann hat es begonnen? Erklären. Welche Signale – und damit welche Komponenten – sind verantwortlich? Interpretieren. Um welche Art von Ausfall handelt es sich, wie schwerwiegend ist er und was sollte ein Techniker tun? Jede Ebene baut auf der vorherigen auf. Und jede ist deutlich schwieriger als die vorherige. Gemessen wird vor allem die Erkennung Die Anomalieerkennung in Zeitreihen ist ein ausgereiftes Forschungsgebiet. Es gibt Dutzende Methoden, von statistischen Baselines bis zu tiefen Autoencodern, und eine lange Liste öffentlicher Benchmarks, um sie zu vergleichen. Die meisten dieser Benchmarks bewerten nur eines: Hat das Modell das richtige Zeitfenster markiert? Das ist eine nützliche Frage. Es ist aber nicht die Frage, die ein Wartungsteam um zwei Uhr nachts stellt. Das Team will wissen, wo es suchen soll. Ein Modell, das zuverlässig anschlägt, aber auf das falsche Subsystem zeigt, schickt die Leute in die falsche Richtung – und eine falsche Richtung kann mehr Zeit kosten als ein verspäteter Alarm. Was ein Benchmark für Speichersysteme über diese Lücke zeigt Ein im Oktober 2026 veröffentlichter Benchmark testet alle drei Ebenen anhand derselben Daten. SHAD (Scality High-dimensional Anomaly Detection) (auf Englisch) wurde von Forschenden von Inria und Scality auf Basis der Telemetrie eines verteilten Objektspeichersystems, Scality RING, entwickelt. Der Aufbau kommt der vorausschauenden Wartung im Produktivbetrieb nahe. Jede Aufzeichnung umfasst 171 Metriken eines Multi-Server-Clusters mit gleichmäßiger Last. Anschließend haben Ingenieure kontrollierte Fehler aus drei Familien eingespeist: Festplattenausfälle, Serverausfälle wie Netzwerkpartitionen und beeinträchtigte Verbindungen sowie Ausfälle einzelner Software-Speicherknoten. Was den Datensatz auszeichnet, ist die Annotation. Jede Aufzeichnung vermerkt, wann der Fehler auftrat, welche Metriken auf die Grundursache zurückgehen, wie kritisch er war, sowie eine schriftliche Beschreibung des Vorfalls. So lässt sich ein Modell nicht nur nach der Erkennung, sondern auch nach Erklärung und Interpretation bewerten. Die Ergebnisse entsprechen den drei Ebenen. Die Erkennung funktionierte. Unter 18 Detektoren schnitten semi-überwachte Methoden am besten ab. Keine einzelne Methode war bei jedem Anomalietyp genau – das deckt sich mit den Erfahrungen aus der Praxis. Die Erklärung war kaum besser als Zufall. Als die Autoren die besseren Detektoren fragten, welche Metriken ihre Anomaliewerte bestimmten, waren die Antworten laut Paper „nearly indistinguishable from a random baseline in term of dimension localization“. Ihr Fazit ist deutlich: „good detection accuracy does not inherently translate into diagnostic utility.“ Die Interpretation war schwach. Fünf große Sprachmodelle, einmalig und ohne aufgabenspezifisches Training gepromptet, hatten Mühe, den Anomalietyp zu benennen oder auf die betroffene Komponente zu zeigen. Zusätzlicher Kontext zum System verbesserte die zeitliche Einordnung der Anomalie, nicht aber die Einschätzung des Schweregrads. Diese Ergebnisse stammen von einem System und einem Lastprofil, und die LLM-Tests nutzten Zero-Shot-Prompting mit einem einzigen Aufruf. Das sagen die Autoren selbst. Das Muster verdient dennoch Beachtung, denn die Bedingungen sind keineswegs ungewöhnlich. Warum Erklären schwieriger ist als Erkennen Die Erkennung stellt eine Ja-Nein-Frage zum gesamten System. Die Erklärung fragt, welches von vielen korrelierten Signalen entscheidend ist – und reale Infrastruktur erschwert diese Frage auf mehrere Arten. Signale bewegen sich gemeinsam. Eine ausfallende Festplatte erhöht die Latenz auf der Festplatte, dann auf dem Server und dann auf den Client-Verbindungen, die sie nutzen. Ein Modell sieht viele Metriken gleichzeitig abweichen und hat keine eingebaute Möglichkeit, Ursache und Folge zu unterscheiden. Resiliente Systeme verbergen ihre eigenen Ausfälle. Verteilte Systeme sind darauf ausgelegt, Fehler abzufangen. In SHAD erzeugten Ausfälle von Speicherknoten das schwächste Signal der drei Familien, weil der Cluster die Arbeit umverteilte. Gutes Engineering für Verfügbarkeit erschwert das Monitoring. Ausfälle können sich über die Zeit entwickeln. Eine Kaskade von Festplattenausfällen oder eine langsam nachlassende Verbindung sieht anders aus als ein einzelner sauberer Bruch. Ein Modell, das vor allem mit abrupten Fehlern trainiert wurde, erkennt schleichende womöglich zu spät oder ordnet sie falsch zu. Nichts davon ist speicherspezifisch. Jede Maschine mit Redundanz und vielen voneinander abhängigen Teilen hat dieselben Eigenschaften. Wo große Sprachmodelle ihren Platz haben LLMs sind ein naheliegender Kandidat für den Interpretationsschritt. Sie schreiben flüssige Zusammenfassungen, und viele Wartungstools nutzen sie bereits, um Arbeitsaufträge zu entwerfen oder die Vorfallhistorie zusammenzufassen. Einen Text aus Informationen zu formulieren, die ein Techniker bereits gesammelt hat, ist eine andere Aufgabe, als rohe multivariate Telemetrie zu lesen und den Fehler zu benennen. Die SHAD-Ergebnisse legen nahe, dass ein Allzweckmodell die zweite Aufgabe ohne Anpassung nicht gut bewältigt. Die Verbesserung durch zusätzlichen Systemkontext deutet auf eine realistischere Rolle hin: ein LLM, das mit einem Detektor, einer Komponentenübersicht und einer Historie früherer Vorfälle zusammenarbeitet, statt Sensordaten allein zu lesen. Was das für ein Programm zur vorausschauenden Wartung bedeutet Für Teams, die KI-gestützte vorausschauende Wartung bewerten oder aufbauen, betreffen die praktischen Lehren weniger die Modelle als vielmehr Daten und Evaluierung. Testen Sie die gesamte Kette. Fragen Sie jeden Anbieter oder jedes interne Team, wie ihr System bei der Erklärung abschneidet – nicht nur bei der Erkennung. Fragen Sie, welcher Anteil der Alarme einen Techniker beim ersten Versuch zur richtigen Komponente führt. Wenn das niemand misst, weiß es niemand. Annotieren Sie für die Diagnose, nicht nur für Alarme. Die meisten Vorfallsprotokolle halten fest, dass etwas kaputtging und wann. Weit weniger dokumentieren, welche Signale auf die Grundursache zurückgingen, wie schwerwiegend das Ereignis war und was unternommen wurde. Erst diese reichhaltigere Annotation macht Erklärung später trainier- und testbar. Bewahren Sie die Historie auf. Rohe Telemetrie plus gut annotierte Vorfälle ist das Kapital, das jedes künftige Modell verbessert. Es geht aber leicht durch kurze Aufbewahrungsfristen oder aggressives Downsampling verloren. Langlebige, hochaufgelöste Sensorhistorie passt gut auf eine für Skalierung ausgelegte Kapazitätsebene, wo sie für das erneute Training verfügbar bleibt, ohne Hot Data zu verdrängen. Behalten Sie bei der Diagnose einen Menschen im Prozess. Die Erkennung lässt sich mit angemessener Sicherheit automatisieren. Nach aktuellem Kenntnisstand profitiert die Ursachenzuordnung von einem Experten, der die Vorschläge des Modells bestätigen oder verwerfen kann. Das Wichtigste in Kürze Behandeln Sie Erkennung und Diagnose als getrennte Fähigkeiten. Ein System kann beim Ersten gut und beim Zweiten nahezu nutzlos sein. Messen Sie, was der Techniker braucht. Fragen Sie, wie oft ein Alarm auf die richtige Komponente zeigt – nicht nur, wie oft er rechtzeitig auslöst. Investieren Sie in annotierte, aufbewahrte Telemetrie. Aus einer kontextreichen Vorfallhistorie lernt jedes künftige Diagnosemodell. Der rote Faden ist einfach: Vorausschauende Wartung zahlt sich aus, wenn sie den Weg vom Alarm zur Behebung verkürzt. Die Erkennung beginnt diesen Weg. Erklärung und Interpretation vollenden ihn – und dort liegen die offenen Probleme. Öffentliche Benchmarks auf Basis realer Systeme mit Labels für Grundursache und Schweregrad sind der Weg, auf dem das Fachgebiet diese Lücke schließen wird. Häufig gestellte Fragen Was ist KI-gestützte vorausschauende Wartung? KI-gestützte vorausschauende Wartung wendet maschinelles Lernen auf Telemetriedaten von Anlagen an, um Ausfälle vorherzusehen, sodass Reparaturen geplant statt reaktiv erfolgen können. Sie umfasst in der Regel Anomalieerkennung auf vielen Sensor-Zeitreihen sowie Werkzeuge, die Technikern helfen, das vom Modell Gemeldete zu diagnostizieren und darauf zu reagieren. Was ist der Unterschied zwischen Anomalieerkennung und Ursachenanalyse? Die Anomalieerkennung stellt fest, dass etwas Ungewöhnliches geschieht und wann. Die Ursachenanalyse ermittelt, welche Komponente oder welches Signal verantwortlich ist. Ein Modell kann Anomalien genau erkennen und dennoch Schwierigkeiten haben, die Ursache zu lokalisieren – besonders in Systemen, in denen sich viele Signale gemeinsam bewegen. Können große Sprachmodelle Anlagenausfälle anhand von Sensordaten diagnostizieren? In aktuellen Benchmark-Tests schnitten Allzweck-LLMs, die einmalig und ohne aufgabenspezifisches Training gepromptet wurden, bei der Bestimmung von Anomalietyp und -ort aus multivariater Telemetrie schlecht ab. Sie eignen sich besser zum Zusammenfassen und Dokumentieren von Vorfällen oder für die Zusammenarbeit mit Detektoren und Systemkontext. Was ist der SHAD-Benchmark? SHAD ist ein öffentlicher Benchmark für Anomalieerkennung in Zeitreihen mit 215 multivariaten Aufzeichnungen eines verteilten Speichersystems. Er enthält Labels für Zeitpunkt, ursächliche Metriken, Schweregrad sowie eine schriftliche Erklärung jedes Fehlers. Code und Daten sind auf GitHub (auf Englisch) unter der Lizenz AGPL-3.0 verfügbar. Welche Daten muss ein Programm zur vorausschauenden Wartung aufbewahren? Hochaufgelöste Telemetriehistorie und Vorfallsprotokolle, die Grundursache, Schweregrad und Lösung festhalten. Erst diese Kombination ermöglicht es, Modelle für die Diagnose neu zu trainieren und zu bewerten – nicht nur für die Erkennung. Weiterführende Lektüre: Detect, Explain, Interpret: An End-to-End Benchmark for Time Series Anomaly Detection, Explainability and Interpretability (auf Englisch) (arXiv, 2026) und Tiered storage for AI: scalable performance and cost control.
