Pexon Consulting | 11 Min. Lesezeit | 25.05.2026
TL;DR
Ein Service-Copilot mit RAG sichert das Erfahrungs-Wissen Ihrer Senior-Techniker, bevor 59% von ihnen in unter fünf Jahren in Rente gehen. Pexon Consulting baut das Pattern aus Interview-Capture, Hybrid-Retrieval auf Wartungsberichten und Multi-Modal-Eskalation mit VLM für technische Zeichnungen. Pilot-Ergebnis aus Industrieprojekten: Service-Tickets in 8-15 Minuten geschlossen statt 35-50 Minuten.
Was 2026 jeden Service-Leiter wach hält
Die Demografie ist nicht abstrakt, sie steht auf der Personalliste. Das IAB hat in seiner Erwerbsprognose 2026 dokumentiert, dass 59% der über-55-jährigen Techniker im verarbeitenden Gewerbe innerhalb der nächsten fünf Jahre in Rente gehen. Die Bundesagentur für Arbeit rechnet mit 2,2 bis 2,8 Millionen Erwerbstätigen, die zwischen 2025 und 2030 den Arbeitsmarkt verlassen. Für jeden Industriebetrieb mit Field-Service-Mannschaft ist das eine Zeitbombe — nicht in zehn Jahren, sondern jetzt.
Der schmerzhafte Teil ist nicht der Abgang an sich, das hat jedes Personalwesen modelliert. Schmerzhaft ist, was geht: 25 bis 35 Jahre Erfahrungs-Wissen pro Senior-Techniker — wie sich ein bestimmtes Motorgeräusch anhört, welche Klemme nach acht Jahren typischerweise driftet, welcher Sensor in welcher Anlage falsch ausschlägt, weil die Kabellage 1998 anders verlegt wurde. Dokumentiert ist davon, wenn wir ehrlich messen, irgendwo zwischen 10 und 20 Prozent. Der Rest sitzt in Köpfen und geht.
Wir haben in den letzten 18 Monaten in vier Industrieprojekten den Service-Copilot als Antwort auf genau dieses Problem gebaut. Die Erkenntnis aus diesen Projekten: RAG ist die richtige Foundation, aber die kritische Arbeit ist nicht der Retrieval-Code, sondern die strukturierte Erfassung des nicht-dokumentierten Wissens vor der Pensionierung.
Was ein Service-Copilot konkret leistet
Stellen Sie sich einen 28-jährigen Service-Techniker vor, der zum ersten Mal an Anlage X arbeitet. Die Steuerung schaltet bei 73 Grad in den Notlauf, obwohl die Spezifikation 85 Grad als Schwelle nennt. Im klassischen Setup ruft er den Senior an, wartet 30 Minuten auf Rückruf und bekommt am Ende einen Satz wie „Das ist immer der Temperatursensor in Modul Z, nach acht Jahren driftet er nach unten — Sensor tauschen, neu kalibrieren, fertig“. Diese Information existiert nirgendwo dokumentiert, sie sitzt im Kopf des Seniors.
Mit Service-Copilot tippt der Techniker am Tablet „Anlage Typ X schaltet bei 73 Grad in Notlauf, Spec sagt 85 Grad“ — und bekommt nach drei Sekunden die strukturierte Antwort: „Bekanntes Muster aus 14 Servicetickets der letzten 6 Jahre. Wahrscheinlichste Ursache: Sensor-Drift Modul Z nach 7-9 Betriebsjahren. Lösungsweg: Sensor T-2031 tauschen (Lagernummer A-4477), Kalibrierung gegen Referenzwert 84,2 Grad bei 20 Grad Raumtemperatur. Bestätigt durch Senior-Techniker M.K. in Interview-Snippet 037.“ Mit Citation. Mit Audit-Trail. Mit Foto des Sensors aus dem Wartungsbericht 2024.
Das ist die UX, die wir liefern. Drunter läuft Agentic RAG mit hybridem Retrieval, VLM-Eskalation für technische Zeichnungen und ein sehr spezifischer Capture-Prozess für Senior-Wissen — der eigentliche Kern.
Die sieben Quellen, die ein Service-Copilot braucht
Wer einen Service-Copilot baut und nur die Service-Manuals indiziert, baut ein besseres SharePoint mit semantischer Suche. Das löst nicht das Problem. Die echten Wissens-Quellen, die wir in jedem Projekt einbinden:
Wir raten ab, mit Quelle 1 zu starten. Die echten Hebel liegen in Quelle 3 (CRM-Tickets — meist riesiger Korpus, kaum genutzt) und Quelle 4 (Interviews — die Wissens-Versicherung gegen den Renteneintritt).
Senior-Wissen erfassen: die kritischste Phase
Hier scheitern die meisten Projekte. Wir haben drei Patterns durchprobiert und ein klares Verfahren entwickelt, das funktioniert.
Erstens: 60- bis 90-minütige strukturierte Interviews pro Senior-Techniker, audio-aufgezeichnet mit Mitarbeiter-Einwilligung. Die Fragen sind nicht „Was wissen Sie?“, sondern spezifisch: „Welche Fehler an Anlagentyp X haben Sie in den letzten 10 Jahren am häufigsten gesehen? Welcher war am tückischsten zu finden? Wie haben Sie ihn final identifiziert?“ Pro Senior 80 bis 200 verwertbare Wissens-Snippets nach Transkription.
Zweitens: Transkription mit Whisper Large v3 self-hosted (keine Cloud bei Mitarbeiterdaten), Chunking nach Q&A-Paaren, Tagging mit Maschinen-Typ, Fehlerklasse, Schweregrad. Die Tagging-Logik validieren wir gegen die CRM-Ticket-Taxonomie, damit später Cross-Search funktioniert.
Drittens — und das ist der Senior-Wertschätzungs-Trick: Die Senior-Techniker bekommen ihre Snippets vor der Indexierung zur Freigabe. Sie sehen, dass ihr Wissen strukturiert wird, nicht „abgesaugt“. Sie können Snippets korrigieren, ergänzen, ablehnen. Das ist nicht nur Compliance, das ist die Akzeptanz, die das Projekt überhaupt erst möglich macht. Wir haben in einem Projekt erlebt, was passiert, wenn dieser Schritt fehlt: Senior-Belegschaft blockiert das Projekt vier Monate, weil sie sich entwertet fühlt.
import whisper
import json
from pathlib import Path
model = whisper.load_model("large-v3")
def process_interview(audio_file: str, senior_id: str):
result = model.transcribe(audio_file, language="de", word_timestamps=True)
prompt = f"""Strukturiere das Interview als JSON-Liste.
Jeder Eintrag enthält: frage_kategorie, frage_kurz, antwort, fehlerklasse,
maschinen_typ, schweregrad (1-5), erfahrungs_quellen (Jahre).
Transkript:
{result['text']}"""
snippets = llm_strukturieren(prompt) # GPT-4o oder Claude Sonnet
Path(f"snippets/{senior_id}_pending_review.json").write_text(
json.dumps(snippets, ensure_ascii=False, indent=2)
)
return snippetsArchitektur: Hybrid-Retrieval plus VLM-Eskalation
Die produktive Architektur ist nicht reine Vector-Search. Wartungsberichte enthalten viele Maschinen-IDs, Klemmenbezeichner und Bauteilnummern — alle exact-match-relevant. Reines Dense-Embedding verfehlt diese Treffer. Wir kombinieren BM25 (für Exact-Match) und Dense-Embedding (für semantische Ähnlichkeit) in einem Ensemble-Retriever.
from langchain_qdrant import QdrantVectorStore
from langchain_community.retrievers import BM25Retriever
from langchain.retrievers import EnsembleRetriever
from langchain_community.cross_encoders import HuggingFaceCrossEncoder
dense = QdrantVectorStore.from_existing_collection(
embedding=embeddings,
collection_name="service-knowledge-base",
url="http://qdrant.pexon.local:6333",
).as_retriever(search_kwargs={"k": 12})
bm25 = BM25Retriever.from_documents(all_service_docs, k=12)
hybrid = EnsembleRetriever(retrievers=[dense, bm25], weights=[0.6, 0.4])
reranker = HuggingFaceCrossEncoder(model_name="BAAI/bge-reranker-v2-m3")
def retrieve_for_query(query: str, top_k: int = 8):
candidates = hybrid.invoke(query)
pairs = [(query, c.page_content) for c in candidates]
scores = reranker.score(pairs)
ranked = sorted(zip(candidates, scores), key=lambda x: x[1], reverse=True)
return [doc for doc, _ in ranked[:top_k]]Der Re-Ranker bringt regelmäßig 15-25% bessere Antwortqualität bei gleicher Latency. Bei einer Knowledge-Base mit 10 Jahren Service-Historie reden wir über 8-15 Millionen Vektoren — Qdrant skaliert das deutlich besser als pgvector, das wir bei diesem Volumen nicht mehr empfehlen.
Wenn der Techniker ein Foto schickt — Schaltschrank, defektes Bauteil, Verkabelungs-Detail — eskaliert das System an ein VLM. Wir nutzen dafür Qwen2.5-VL 7B self-hosted bei DSGVO-Pflicht, GPT-4o Vision über Azure OpenAI EU bei Standard-Setups.
def query_with_foto(text_query: str, foto_b64: str):
candidates = retrieve_for_query(text_query)
context = "nn".join(c.page_content for c in candidates)
response = vlm_client.chat.completions.create(
model="gpt-4o",
messages=[{"role": "user", "content": [
{"type": "text", "text": f"""Frage: {text_query}
Kontext aus Service-Wissen:
{context}
Foto des Bauteils ist beigefügt. Beantworte die Frage präzise,
zitiere Quellen mit [Snippet-ID]. Bei Unsicherheit explizit sagen."""},
{"type": "image_url", "image_url": {"url": foto_b64}},
]}],
temperature=0.0,
)
return response.choices[0].message.contentWas wir aus echten Projekten gelernt haben
Ein deutscher Hersteller von Energie-Komponenten in Bayern hat in den vergangenen 18 Monaten einen Service-Copilot in diesem Muster aufgebaut. Ausgangslage: 28 Senior-Techniker im internationalen Field-Service, 17 davon gehen bis 2030 in Rente. Wartungsberichte aus 12 Jahren lagen in einem SharePoint, durchsuchbar nur über Dateinamen.
Die Phasen, die sich in fast jedem Projekt wiederholen: 4 Wochen Datenerfassung und Pipeline-Bau (CRM-Anbindung, SharePoint-Indexierung). 6 Wochen Senior-Interviews und Snippet-Review (parallel zur Pipeline). 4 Wochen MVP-Frontend für Service-Techniker (Mobile-First, Tablet-tauglich). 6 Wochen Eval und Iteration mit echten Service-Tickets aus dem Echtbetrieb. Nach 5 Monaten produktiv mit dem ersten Geschäftsbereich, danach Roll-Out auf weitere.
Das Ergebnis nach 9 Monaten Produktivbetrieb: Service-Tickets werden in 8 bis 15 Minuten geschlossen statt 35 bis 50 Minuten. Junior-Techniker schaffen 70 bis 80 Prozent der Fälle, für die sie früher den Senior gerufen hätten. Senior-Wissen ist strukturiert dokumentiert — und wertgeschätzt, weil die Senior-Mannschaft als Autoren der Snippets sichtbar bleibt.
Was bei Service-Copilot-Projekten regelmäßig schiefgeht
Wir raten ab: Mit Service-Manuals starten und Interviews später nachholen. Das ist die häufigste Fehlentscheidung. Senior-Techniker gehen jetzt in Rente, Service-Manuals laufen nicht weg. Die Reihenfolge muss umgekehrt sein.
Wir raten ab: Naives RAG für Service-Anfragen. Wartungsfragen sind fast immer Multi-Hop — „Welche Klemme bei welchem Sensor unter welcher Betriebsbedingung?“ Drei Sub-Queries, die ein naiver Retriever nicht zerlegt. Wir setzen Agentic RAG ein, mit LangGraph als Orchestrierung. Wer noch klassisches RAG fährt, sollte zuerst diesen Architektur-Schritt machen.
Wir raten ab: Cloud-LLM ohne EU-Region für Wartungsdaten mit Kundenbezug. Wartungsberichte enthalten regelmäßig Standort-Adressen, Kundennamen, Anlagen-IDs — DSGVO-relevant. Azure OpenAI in der EU-Region mit AVV ist das Minimum, self-hosted Qwen oder Llama bei strengerer Anforderung. Standard-OpenAI-Endpoint geht nicht.
Vierter Klassiker: Mobile UX als Nachgedanke. Ein Service-Techniker bedient das Tablet mit Handschuhen, bei Sonneneinstrahlung, gelegentlich in lauten Umgebungen. Wir designen die UI explizit mobile-first, mit Voice-Input-Option und großen Touch-Zielen. Ein desktop-zentriertes Service-Copilot-Interface scheitert in der Praxis.
Häufig gestellte Fragen
Was ist ein Service-Copilot und wie unterscheidet er sich von einem Wiki?
Ein Service-Copilot ist ein Agentic-RAG-System speziell für technisches Service-Wissen — kombiniert strukturierte Doku, Wartungsberichte, CRM-Tickets, Senior-Interviews und Anlagen-Fotos in einer abfragebaren Wissensbasis mit Citation und Audit-Trail. Ein Wiki ist statisch und manuell gepflegt. Der Service-Copilot retrieved semantisch über Millionen Snippets, eskaliert bei Bildern an ein VLM und liefert Antwort mit Quellen-Verweis in Sekunden.
Wie lange dauert ein Service-Copilot-Pilot bei Pexon?
Sechs Wochen für einen belastbaren MVP mit einem Geschäftsbereich, fünf Monate bis voll-produktiver Betrieb. Phase 1: Datenpipeline und Interviews parallel (Woche 1-6). Phase 2: MVP-Frontend (Woche 7-10). Phase 3: Eval, Iteration, Roll-Out (Monat 3-5). Der kritische Pfad ist immer die Interview-Phase — Termine mit Senior-Technikern sind nicht beschleunigbar.
Wie erfassen wir das Wissen der Senior-Techniker ohne dass sie das Tool ablehnen?
Drei Regeln aus eigener Erfahrung. Erstens: Senior-Techniker als Autoren sichtbar machen, ihre Snippets mit Namens-Tag versehen, im UI als Quelle zitierbar. Zweitens: Pre-Indexierungs-Review — jeder Senior sieht und genehmigt seine Snippets bevor sie produktiv werden. Drittens: Service-Copilot als Verstärker des Seniors framen, nicht als Ersatz. Das ist nicht Marketing-Sprech, das ist die einzige Konstellation, in der das Projekt akzeptiert wird.
Was kostet ein Service-Copilot in Mittelstand-Größenordnung?
Pilot mit einem Geschäftsbereich, 5-10 Senior-Interviews, einem CRM-Anschluss und MVP-Frontend: 80-130k EUR über 6 Wochen. Voller Roll-Out auf 3-5 Geschäftsbereiche mit 30-50 Senior-Interviews, mehreren Datenquellen, Mobile-App und Eval-Pipeline: 250-450k EUR über 4-6 Monate. Laufender Betrieb (LLM-Kosten, Updates, Snippet-Pflege): typisch 4.000-9.000 EUR im Monat.
Müssen wir die alten Wartungsberichte erst digitalisieren?
Wenn sie als Scans im SharePoint liegen, ist OCR-Schritt nötig — Azure Document Intelligence verarbeitet 95%+ der Standardlayouts out-of-the-box bei einem Cent pro Seite. Handschriftliche Anteile schaffen 75-85% mit VLM-Eskalation. Reine Papier-Archive aus den 1990ern: Scan zuerst, das ist eine eigene Initiative von 8-12 Wochen je nach Volumen. Wir empfehlen, die letzten 5 Jahre zuerst zu nehmen — sie haben den meisten Lösungs-Bezug zur aktuellen Anlagengeneration.
Nächster Schritt
Wenn Sie absehen, dass Ihr Service-Team in den nächsten drei bis fünf Jahren signifikant Senior-Wissen verliert: Wir machen ein 90-Minuten-Sparring mit Ihrem Service-Leiter, COO und einem Senior-Techniker. Wir zeigen den realistischen Pilot-Pfad, die Interview-Methodik und die Architektur-Entscheidungen für Ihre konkrete Datenlage.
Verwandte Themen
→Agentic RAG mit LangGraph — Live-Code
→Document Intelligence — Hub-Page
→Fertigung — Branchen-Lösungen
