Der virtuelle Servicetechniker als Edge Agent

Es ist 02:40 Uhr. Eine Anlage meldet einen Drehzahlabfall, der Durchsatz bricht ein, und der einzige Mensch in der Halle ist ein Bediener, der die Maschine fährt, aber nicht gebaut hat. Der nächste Servicetechniker ist Stunden entfernt, das Telefon-Hotline-Fenster ist zu, und ein Ticket bedeutet im besten Fall morgen früh eine Antwort. Bis dahin steht die Linie oder läuft auf Verdacht weiter. Genau hier setzt ein virtueller Servicetechniker an. Ein KI-Agent auf der Maschine, der zwischen Anlage und Bediener vermittelt, lokal, sofort, ohne dass jemand erst ein Ticket aufmachen muss.

Wissen ist da, nur nicht vor Ort

Das Erfahrungswissen über eine Maschine existiert, in Handbüchern, Schaltplänen, in den Köpfen erfahrener Techniker und in Jahren von Sensordaten. Es ist nur selten dort, wo es nachts um halb drei gebraucht wird. Standorte mit wenigen Maschinen halten keinen eigenen Instandhalter vor. Nacht- und Wochenendschichten haben dünne Besetzung. Und jede Eskalation kostet, nämlich Wartezeit, Anfahrt und einen Technikertermin für etwas, das vielleicht ein gelöster Stecker war.

Ein Edge Agent verschiebt den ersten Schritt der Diagnose dorthin, wo die Maschine steht. Er ersetzt den Menschen nicht. Er gibt dem Bediener vor Ort das Wissen, das sonst erst über eine Eskalationskette ankäme. Augmentierung, nicht Ablösung, und die Entscheidung bleibt beim Bediener.

Anomalie zuerst erkennen mit klassischer ML

Der Agent muss nicht für jede Schwankung ein Sprachmodell bemühen. Die erste Stufe ist klassische Mustererkennung direkt auf den Sensordaten, mit Schwellwerten und Hysterese, Trendüberwachung und Anomalieerkennung auf Vibration, Temperatur, Strom und Drehzahl. Das läuft deterministisch und ressourcenschonend auf dem Gerät und entscheidet zuverlässig, dass etwas vom Normalbild abweicht.

Diese Intelligenz-Kaskade ist bewusst gestuft. Zuerst Regeln, dann klassisches ML, dann ein On-Device-KI-Sprachmodell, und erst als Ausnahme ein großes Cloud-Modell. Der Punkt ist Sparsamkeit, und die teuerste Stufe wird nur gezogen, wenn die günstigere nicht reicht. Für die überwiegende Mehrheit industrieller Diagnoseaufgaben genügt ein kleines, lokal laufendes Modell.

Verständlich erklären mit einem lokalen SLM

Erkennen ist das eine, einordnen das andere. Sobald die Anomalie steht, übernimmt ein lokales Small Language Model (1 bis 3B Parameter), das neben der Engine über einen lokalen, OpenAI-kompatiblen Inferenzserver läuft. Seine Aufgabe ist nicht, kreativ zu sein, sondern die Messlage in Worte zu fassen, die ein Bediener um halb drei nachts versteht. Was weicht ab, welche plausiblen Ursachen kommen infrage, und welcher Schritt steht als Nächstes an.

Entscheidend ist die Erdung. Das Modell halluziniert keine Anleitung, sondern stützt jede Aussage auf eine Wissensbasis aus Handbüchern, Schaltplänen, früheren Sensorverläufen und dokumentiertem Erfahrungswissen. Über semantische Suche (Vektorsuche) holt der Agent die passenden Stellen heran und formuliert daraus eine schrittweise Anleitung. Wo eine wissensintensive Aufgabe ein größeres Modell verlangt, lässt sich optional ein Cloud-LLM zuschalten, die Ausnahme und nicht der Normalfall.

Kritisches bleibt lokal

Die Logik, auf die es ankommt, läuft auf dem Gerät und funktioniert auch dann, wenn die Verbindung wegbricht. Anomalieerkennung, das lokale SLM und die Bedienerführung brauchen kein Netz. Nur die optionalen Bausteine gehen nach außen, also ein Cloud-Modell für Wissensschweres und Web-Recherche. Diese Trennung ist Absicht, und der virtuelle Servicetechniker ist nachts und am Wochenende genau dann verfügbar, wenn die Anbindung am dünnsten ist.

Sicherheit entsteht hier nicht aus einer Genehmigungsschicht, sondern aus der Architektur selbst, also lokale Ausführung, Container-Isolation und ein graph-first aufgebauter Ablauf, in dem der Graph das Programm ist und das KI-Modell nur ein Knoten darin. Jeder Schritt ist nachvollziehbar und begrenzt, kein Agent, der frei im System schaltet, sondern ein klar umrissener Ablauf.

Ein Szenario aus einer dünn besetzten Nachtschicht

Ein Bediener fährt nachts allein eine Linie an einem kleinen Standort. Eine Pumpe zeigt ein leicht erhöhtes Vibrationsmuster, der Durchsatz sinkt. Statt zu warten oder die Linie auf Verdacht zu stoppen, sieht der Bediener am Terminal eine Meldung des Edge Agents. Die Anomalie ist benannt, mit den auffälligen Messwerten, und es folgt eine kurze, geerdete Erklärung samt drei Prüfschritten, abgeleitet aus dem Handbuch und ähnlichen früheren Verläufen. Der Bediener arbeitet die Schritte ab, identifiziert eine teilverstopfte Zuleitung, behebt sie und dokumentiert den Fall. Kein Ticket, keine Anfahrt, kein Stillstand bis zum Morgen. Falls die Schritte nicht greifen, eskaliert er, aber nun mit einem vorbereiteten Befund statt einem leeren Anruf.

So läuft das am Edge

Technisch ist das ein gerichteter Ablaufgraph auf einem einzigen Binary, das auf der vorhandenen Hardware vor Ort läuft, vom kleinen Embedded-Board bis zum Industrierechner, dasselbe Binary, ohne Neuimplementierung.

1. Trigger. Ein Schwellwert-Trigger mit Hysterese oder ein eingehender MQTT-Messwert startet den Ablauf, sobald die Sensorik vom Normalbild abweicht, ohne Cloud-Schleife, denn der Auslöser sitzt am Gerät.
2. Klassifikation. Klassische ML-Knoten bewerten das Muster und entscheiden, ob es sich um eine echte Anomalie handelt oder um Rauschen.
3. Erdung über die Wissensbasis. Ein Retrieval-Knoten holt per semantischer Suche die relevanten Handbuch- und Schaltplan-Passagen sowie ähnliche frühere Verläufe.
4. Erklärung durch das lokale SLM. Das On-Device-Modell fasst Messlage plus abgerufenes Wissen zu einer schrittweisen, bedienerverständlichen Anleitung zusammen.
5. Ausgabe und Protokoll. Die Führung erscheint am Terminal, der Fall wird in den dauerhaften lokalen Speicher geschrieben.

Der gesamte kritische Pfad, von Trigger und Klassifikation über die SLM-Erklärung bis zur Bedienerführung, läuft offline auf dem Gerät. Die Cloud ist die zuschaltbare Ausnahme, nicht die Voraussetzung.

Das Wichtigste in Kürze

• Ein virtueller Servicetechniker als Edge Agent verlagert den ersten Diagnoseschritt auf die Maschine, wertvoll besonders nachts, am Wochenende und an Standorten mit wenigen Maschinen.
• Die Intelligenz-Kaskade spart bewusst. Klassisches ML erkennt die Anomalie, ein lokales SLM erklärt sie schrittweise, und ein Cloud-LLM kommt nur bei wissensintensiven Ausnahmen dazu.
• Jede Aussage ist über semantische Suche auf einer Wissensbasis aus Handbüchern, Schaltplänen und Erfahrungswissen geerdet, ohne erfundene Anleitung.
• Der kritische Pfad bleibt lokal und offlinefähig, und die Sicherheit folgt aus lokaler Ausführung, Container-Isolation und dem graph-first aufgebauten, nachvollziehbaren Ablauf.
• Augmentierung statt Ablösung. Die Entscheidungshoheit bleibt beim Bediener, und der Agent liefert das Wissen, nicht das Urteil.