Pexon Consulting | 11 Min. Lesezeit | 08.07.2026
TL;DR
Ein Field-Service-Copilot ist ein KI-Wissensbot, der Service-Technikern direkt an der Anlage Wartungs- und Fehlerdiagnose-Antworten liefert, offline und mehrsprachig. Pexon (80 Mitarbeiter, Deutschland, Microsoft Partner) baut ihn als lokales RAG-System auf Edge-Hardware, ohne Cloud-Zugriff am Einsatzort. Ergebnis: 20 bis 35 Prozent bessere Erstlösungsquote, weniger Zweitanfahrten.
Warum ein Techniker vor dem Stufenschalter kein WLAN hat
Ein Service-Techniker steht in einer Umspannstation in Chile, vor einem offenen Stufenschalter (OLTC) an einem Leistungstransformator. Das Kontaktabbrand-Muster passt zu keinem Standardfall. Das Servicehandbuch liegt als 400-Seiten-PDF auf einem Firmenserver in Deutschland. Mobilfunk: kein Empfang. Genau hier scheitern die meisten cloud-basierten Assistenten.
Das ist kein Randfall. Für Feldeinsätze in Gebäuden, Kellern, Schaltanlagen und abgelegenen Standorten ist Offline-Fähigkeit 2026 kein Nice-to-have mehr, sondern Grundvoraussetzung. Die App muss vollständig ohne Verbindung funktionieren und erst bei Empfang synchronisieren.
Bei energietechnischen Anlagen kommt die Kritikalität dazu. Laut CIGRE gehen bis zu ein Drittel aller Transformator-Ausfälle auf den Stufenschalter zurück, und OLTC-bezogene Fehler verursachen über 30 Prozent der Transformator-Störungen. Ein falsch interpretiertes Kontaktbild oder ein übersehener Ölwert kostet nicht nur eine Zweitanfahrt, sondern potenziell einen Netzausfall.
Wir sehen bei einem unserer Kunden, einem globalen Hersteller und Serviceanbieter für Stufenschalter und Transformatoren-Komponenten, genau dieses Muster: Erfahrene Techniker gehen in Rente, die Anlagen stehen weltweit, und das Wissen steckt in PDFs, die niemand mit ins Feld nimmt. Der Field-Service-Copilot ist die Antwort darauf.
Was ein Field-Service-Copilot an der Anlage konkret macht
Ein Field-Service-Copilot liest den Auftrag, zieht die relevante Anlagenhistorie, benennt die wahrscheinlichsten Fehlerbilder und führt den Techniker in Klartext durch die Diagnose. Der Unterschied zu einem generischen Chatbot: Er antwortet aus dem eigenen Servicewissen (Handbücher, Prüfprotokolle, Reparaturberichte), nicht aus dem offenen Internet, und er tut das ohne Verbindung.
Der Techniker beschreibt, was er sieht („Kontaktabbrand an Wählerkontakt 3, Öl trüb“), und das System synthetisiert aus tausenden Seiten Servicedokumentation den wahrscheinlichsten Grund und den korrekten Handgriff. In der Praxis bedeutet das drei Dinge:
- Fehlerdiagnose vor Ort statt Rückruf in die Zentrale.
- Wartungsschritte gemäß IEC 60076 als geführte Checkliste, statt im PDF blättern.
- Antworten in der Sprache des Technikers, egal ob Deutsch, Spanisch oder Portugiesisch.
75 Prozent der Unternehmen berichten, dass KI ihre Erstlösungsquote verbessert. In konkreten Techniker-Copilot-Projekten liegt die Verbesserung der First-Time-Fix-Rate bei 20 bis 35 Prozent. Bei Anfahrtskosten, die im Feld schnell mehrere hundert Euro pro unnötigem Einsatz erreichen (in der US-Solarbranche im Schnitt 475 US-Dollar pro vermeidbarer Zweitanfahrt), rechnet sich das nach wenigen verhinderten Truck-Rolls.
Unsere klare Empfehlung: Der Copilot muss das Servicewissen des Herstellers spiegeln, nicht Weltwissen. Ein generischer LLM-Chat halluziniert bei OLTC-Spezifika, weil die Trainingsdaten die Anlage nicht kennen. Deshalb RAG, deshalb eigene Dokumente.
So läuft der Copilot offline: lokales RAG auf Edge-Hardware
Die kurze Antwort: Modell, Vektor-Index und Dokumente liegen komplett auf einem robusten Gerät am oder beim Techniker, es geht keine Anfrage ins Netz. Der Sprung von der Cloud-Demo zum Feldgerät ist die eigentliche Ingenieursarbeit, und genau hier scheitern die meisten Eigenbau-Versuche.
Das Modell läuft quantisiert. GGUF-Quantisierung im Format Q4_K_M erhält 95 bis 98 Prozent der Modellqualität bei rund 75 Prozent Speicherersparnis und ist 2026 der Standard für Edge-Deployment. Als lokales Modell nutzen wir je nach Gerät ein aktuelles offenes LLM wie qwen2.5-7b-instruct oder llama-3.3 in der Q4_K_M-Variante, betrieben über Ollama oder direkt llama.cpp.
Als Hardware hat sich ruggedized Edge-Compute bewährt. Auf einem NVIDIA Jetson Orin (40 bis 275 TOPS je nach Modul, Stand Juli 2026) läuft ein 7B-Modell in Q4_K_M mit rund 14 Token pro Sekunde Generierung bei unter 15 Watt, genug für eine flüssige Frage-Antwort-Interaktion. Ollama unterstützt die Jetson-Plattform mit CUDA out of the box.
Der Retrieval-Teil ist ein lokaler Vektor-Index über die Servicedokumente. Kein externer Vektor-Store, keine API. Hier ein minimales, lauffähiges Offline-RAG-Setup in Python:
# Offline-RAG an der Anlage: lokaler Index + lokales LLM, kein Internet
# Voraussetzung: Ollama laeuft lokal auf dem Edge-Geraet (Jetson / Mini-PC)
import chromadb
from sentence_transformers import SentenceTransformer
import ollama
# Embedding-Modell laeuft lokal, keine Cloud-API
embedder = SentenceTransformer("intfloat/multilingual-e5-small")
# Persistenter Vektor-Store auf der lokalen Platte des Geraets
client = chromadb.PersistentClient(path="/opt/copilot/index")
col = client.get_or_create_collection("oltc_service")
def frage(text: str, sprache: str = "de") -> str:
# 1. Frage in Vektor umwandeln (lokal)
q_vec = embedder.encode([f"query: {text}"]).tolist()
# 2. Passende Handbuch-Abschnitte holen (lokal, offline)
treffer = col.query(query_embeddings=q_vec, n_results=4)
kontext = "nn".join(treffer["documents"][0])
# 3. Antwort mit lokalem Modell erzeugen, streng auf Kontext begrenzt
prompt = (
f"Antworte auf {sprache}. Nutze NUR den folgenden Servicekontext. "
f"Wenn die Antwort nicht im Kontext steht, sage das ehrlich.nn"
f"KONTEXT:n{kontext}nnFRAGE: {text}"
)
antwort = ollama.chat(
model="qwen2.5:7b-instruct-q4_K_M",
messages=[{"role": "user", "content": prompt}],
)
return antwort["message"]["content"]
print(frage("Kontaktabbrand am Waehlerkontakt, Oel truebe. Naechster Schritt?"))Das Indexieren der Dokumente passiert einmalig in der Zentrale, das Ergebnis wird auf das Gerät gespiegelt. Deutsche Kommentare im Code sind Absicht: Die Techniker-Teams, die das später warten, lesen sie.
Mehrsprachig und weltweit: der eigentliche Härtetest
Ein globaler Serviceeinsatz heißt: dasselbe Handbuch, Techniker in einem Dutzend Sprachen. Hier trennt sich ein robuster Field-Service-Copilot vom Demo-Projekt. Die Dokumentation ist meist Deutsch oder Englisch, die Frage kommt auf Spanisch, und die Antwort soll auf Spanisch zurückkommen, ohne dass jemand das Handbuch übersetzt.
Wir lösen das über ein mehrsprachiges Embedding-Modell (im Beispiel oben multilingual-e5-small), das Frage und Dokument im selben Vektorraum ablegt. So findet eine spanische Frage den deutschen Handbuchabschnitt. Das lokale LLM antwortet dann in der Sprache des Nutzers. Kein separater Übersetzungsdienst, keine Cloud, kein zusätzlicher Latenz-Sprung.
Das funktioniert in der Praxis nur, wenn die Dokumentenqualität stimmt. Ein RAG-System ist so gut wie das, was reingeht. Bei technischen Dokumenten mit Tabellen, Wartungsplänen und Normbezügen scheitert naives PDF-Chunking regelmäßig, ein Punkt, den wir in unserem Beitrag zu den Grenzen von Standard-RAG bei technischen Dokumenten ausführlich zeigen. Für energietechnische Handbücher heißt das: strukturerhaltendes Parsing, damit ein Anzugsmoment nicht von seiner Zeile getrennt wird.
Und ja, es gibt einen demografischen Druck dahinter. Das Erfahrungswissen der Senior-Techniker verschwindet schneller, als es dokumentiert wird, ein Zusammenhang, den wir am Beispiel der Rentenwelle beim Wissens-Transfer im Service durchgerechnet haben. Der Copilot ist auch ein Weg, dieses Wissen zu konservieren, bevor es in Rente geht.
Datensouveränität: warum offline hier kein Kompromiss ist
Offline ist bei energietechnischen Anlagen nicht nur eine Empfängnis-Frage, sondern eine Sicherheits- und Souveränitäts-Frage. Servicedaten von Transformatoren in einer Umspannstation sind KRITIS-relevant. Sie dürfen den Standort oft gar nicht verlassen, und der Betreiber will keine Anlagendetails in einer US-Cloud.
Ein lokal betriebener Copilot löst das strukturell: Wenn keine Anfrage das Gerät verlässt, gibt es keinen Datenabfluss. Über 40 Prozent der Enterprise-KI-Workloads enthalten 2026 bereits eine lokale Inferenz-Komponente, genau aus diesem Grund. Das ist kein Rückschritt gegenüber der Cloud, sondern für diesen Use-Case die überlegene Architektur.
Wir bauen solche Sovereign-Setups auf einem Deutschland-gehosteten AI-App-Stack auf, wenn eine zentrale Wissensbasis nötig ist, und spiegeln die Feldgeräte daraus. Die Architektur-Prinzipien dahinter beschreiben wir im Kontext von Datensouveränität bei KI.
Unsere Erfahrung: Der Souveränitäts-Vorteil ist bei Energieversorgern und KRITIS-Betreibern oft das ausschlaggebende Argument, nicht die Erstlösungsquote. Beides bekommt man mit demselben lokalen Aufbau.
Kosten, Zeitrahmen und wann sich der Pilot rechnet
Ein belastbarer Pilot ist keine Jahresrechnung. Wir setzen einen ersten produktiven Field-Service-Copilot als 6-Wochen-Pilot auf, mit einer klar abgegrenzten Anlagenklasse (etwa eine OLTC-Baureihe) und einer Handvoll Feldgeräte. Der Aufwand liegt für ein solches Pilotprojekt im niedrigen fünfstelligen Bereich, die Hardware pro Feldgerät (Jetson-Klasse) deutlich darunter.
Die Rechnung ist einfach: Der globale OLTC-Markt liegt 2026 bei rund 712 Millionen US-Dollar und wächst mit 5,5 Prozent jährlich, das Servicegeschäft dahinter ist der eigentliche Umsatzträger. Jede vermiedene Zweitanfahrt an eine abgelegene Umspannstation spart Reise-, Personal- und Ausfallkosten, die einen Piloten oft schon nach einer zweistelligen Zahl von Einsätzen amortisieren.
Wann raten wir ab? Wenn Ihre Servicedokumentation nicht existiert oder chaotisch ist. Der Copilot erzeugt kein Wissen, er macht vorhandenes zugänglich. Ist die Dokumentation dünn, investieren Sie zuerst dort. Alles andere ist Geldverschwendung.
Häufig gestellte Fragen
Was kostet ein Field-Service-Copilot?
Ein erster produktiver Field-Service-Copilot als 6-Wochen-Pilot liegt typisch im niedrigen fünfstelligen Bereich, plus Hardware pro Feldgerät (Edge-Compute der Jetson-Klasse) im niedrigen vierstelligen Bereich. Der Löwenanteil steckt nicht im Modell, sondern im sauberen Ingest der Servicedokumente. Bei mehreren vermiedenen Zweitanfahrten rechnet sich das oft nach wenigen Einsätzen.
Läuft der Copilot wirklich komplett offline?
Ja. Modell, Vektor-Index und Dokumente liegen lokal auf dem Edge-Gerät, jede Anfrage wird ohne Netz beantwortet. Synchronisiert wird nur, wenn wieder Empfang da ist, und auch das nur für Updates der Wissensbasis, nie für die Anfragen selbst. Das ist bei KRITIS-relevanten Anlagen der entscheidende Punkt.
Offline-Copilot oder Cloud-Chatbot: was ist besser für Service im Feld?
Für Feldeinsätze an energietechnischen Anlagen gewinnt offline. Der Cloud-Chatbot fällt genau dort aus, wo der Techniker ihn braucht (kein Empfang), und bei KRITIS-Anlagen ist der Datenabfluss ein Ausschlusskriterium. Cloud ist sinnvoll für die zentrale Wissenspflege, nicht für die Antwort an der Anlage.
Welches lokale Modell nutzt Pexon dafür?
Je nach Gerät ein aktuelles offenes LLM, etwa Qwen 2.5 7B oder Llama 3.3 in der Quantisierung Q4_K_M, betrieben über Ollama oder llama.cpp. Q4_K_M erhält 95 bis 98 Prozent der Qualität bei rund 75 Prozent Speicherersparnis, das macht den Betrieb auf robuster Feldhardware erst praktikabel.
Wie geht der Copilot mit mehreren Sprachen um?
Über ein mehrsprachiges Embedding-Modell landen Frage und Handbuchabschnitt im selben Vektorraum, eine spanische Frage findet also den deutschen Handbuchtext. Das lokale LLM antwortet dann in der Sprache des Technikers. Kein separater Übersetzungsdienst, alles offline auf dem Gerät.
Nächster Schritt
Sie haben Anlagen im Feld, dokumentiertes Servicewissen in PDFs und Techniker ohne Empfang vor Ort? Dann lohnt der Pilot. Wir prüfen mit Ihnen in einem kurzen Call, ob Ihre Dokumentation den Aufbau schon trägt.
Verwandte Themen
→llama.cpp: Quantisierung und lokale Inferenz auf Edge-Hardware
