Service-RAG für die Fertigung: was der Techniker im Außendienst tatsächlich aus Ihrem System ziehen muss

Worum es geht: die Kurzfassung

• Wartungsdokumentation ist der lohnendste RAG-Use-Case in der Fertigung. Mehr Wissen pro Maschine als irgendwo sonst im Betrieb, dazu fast jeder Außendienst-Einsatz unter Zeitdruck.
• Drei Wissensquellen müssen zusammenkommen: Maschinenhandbuch (PDF), Service-Historie (ERP/CRM/Eigenentwicklung), Hersteller-Updates (Newsletter, Service-Bulletins). Bei intern entwickelten Maschinen plus Konstruktionszeichnungen und Stücklisten.
• Mobile-First UX ist Pflicht. Der Techniker fragt am Tablet oder Smartphone, oft mit schlechter Konnektivität und in lauter Halle. Sprachsteuerung und große Touch-Targets entscheiden über Akzeptanz.
• Bandbreiten realistisch: 70–85 % korrekte Erstantworten bei sauber indexierten Quellen, 5–15 % Eskalation an Senior-Techniker oder Hersteller-Hotline.
• Datenresidenz entscheidend. Konstruktionsdaten gehen nicht in eine externe Cloud: entweder EU-Inferenz mit AVV oder On-Premise.

Warum der Außendienst-Techniker das stärkste RAG-Argument ist

In Mittelstands-Fertigung steckt typisch Wissen in drei Köpfen: dem Konstrukteur, der die Maschine entworfen hat; dem Werkstattleiter, der jede Sondervariante gesehen hat; und dem Senior-Techniker im Außendienst, der die typischen Störungen kennt. Wenn einer dieser drei ausfällt, krankt oder in Rente geht, fehlt dem Betrieb genau das Wissen, das nicht im System steht.

Ein RAG-System (siehe unsere allgemeine Einführung zu RAG) macht aus diesem stillen Wissen explizites Wissen, nicht durch magisches Verstehen, sondern durch saubere Indexierung der Quellen und semantische Suche. Für den Außendienst-Techniker bedeutet das konkret:

• Antwort in 10–30 Sekunden auf Fragen, die heute 5–30 Minuten Telefonieren bedeuten.
• Antwort mit Quellenangabe: der Techniker sieht, ob die Information aus dem Handbuch (zuverlässig), aus einem Vorgänger-Service-Bericht (oft zuverlässig) oder aus dem Hersteller-Newsletter (manchmal überholt) stammt.
• Antwort ohne Konnektivitätsabhängigkeit im Idealfall: bei lokaler Inferenz auf einem mitgeführten Edge-Gerät oder mit Cache-Strategie.

Der Effekt: Erstreparaturquote (Fix on First Visit) steigt typisch um 10–25 Prozentpunkte, mittlere Einsatzdauer pro Service-Termin sinkt um 15–30 %.

Die drei Wissensquellen, und wie sie typisch aussehen

Ein produktiver Service-RAG zieht aus mindestens drei Quellen. Die Datenlage in jedem Mittelstands-Betrieb ist unterschiedlich, aber die Kategorien wiederholen sich:

Quelle 1: Maschinenhandbuch und Konstruktionsdaten

Form: PDF (oft mehrere hundert Seiten, oft schlecht gescannt), CAD-Stücklisten, Schaltpläne. Bei Hersteller-Maschinen vom Hersteller gepflegt, bei Eigenentwicklungen intern. Typische Probleme: Versions-Drift (Maschine M-23-Rev-B hat ein anderes Handbuch als M-23-Rev-C), Mischsprachen (Deutsch / Englisch / Italienisch je nach Hersteller), schlechte OCR-Qualität bei alten Scans.

Lösung: OCR mit moderner Engine (Tesseract 5, AWS Textract, Azure Document Intelligence), strukturelle Erkennung von Kapiteln und Tabellen, Versions-Tagging pro Chunk, sprachübergreifende Embeddings (z. B. intfloat/multilingual-e5-large).

Quelle 2: Service-Historie und Reparaturberichte

Form: CRM-Tickets (Salesforce Service Cloud, HubSpot Service, Zoho Desk, Eigenentwicklung), Freitext-Reparaturberichte, Foto-Anhänge. Typische Probleme: unstrukturierte Eingabe („Kunde sagt es brummt”, „Filter wieder rein”), unterschiedlicher Detaillierungsgrad pro Techniker, oft fehlende Fehlerklassifikation.

Lösung: Strukturierende Re-Klassifikation der historischen Tickets durch ein LLM (mit Sample-Review durch Senior-Techniker), Verlinkung jedes Tickets mit der betroffenen Maschine und Komponente, Extraktion von Symptom, Diagnose und Lösung pro Ticket.

Quelle 3: Hersteller-Updates und externe Bulletins

Form: PDF-Newsletter, Hersteller-Portale, Service-Bulletins, Rückrufaktionen. Typische Probleme: dezentrale Verteilung (per Mail an unterschiedliche Personen), unklare Aktualität, sprachliche Variation.

Lösung: Automatischer Scrape oder strukturierte Einlieferung über ein dediziertes Postfach (hersteller-updates@), Tagging nach Hersteller und Maschinen-Modell, automatische Aktualitäts-Markierung bei Hersteller-Versions-Updates.

Wie eine Anfrage technisch durchläuft

Der typische Fluss in unter zwei Sekunden:

1. Eingabe. Techniker tippt oder spricht: „Welcher Hydraulikdruck ist für die Anlage X1 bei Schmiermittel Y zulässig?”
2. Anreicherung. Aus dem aktuellen Service-Auftrag (Maschine, Kunde, Komponente) wird Kontext beigesteuert: der Agent weiß, welche genaue Variante der X1 vor Ort steht.
3. Retrieval. Semantische Suche über alle indexierten Chunks der drei Quellen. Top-15 Treffer mit Quellenmix, gewichtet nach Quelle (Handbuch > Service-Historie > Hersteller-Update bei Konflikten).
4. Re-Ranking. Ein kleineres Cross-Encoder-Modell prüft Relevanz der 15 Treffer und reduziert auf die Top-5.
5. Antwortgenerierung. Ein LLM formuliert die Antwort, zitiert die Quellen mit Seitenzahl oder Ticket-ID, markiert Unsicherheiten explizit.
6. Eskalations-Check. Wenn die Confidence niedrig ist oder die Frage sicherheitsrelevant (Hochspannung, Druckspeicher, ATEX-Zone), wird ein „Bitte Senior-Techniker konsultieren”-Hinweis vorangestellt.

Der Mensch bleibt im Loop. Die Antwort ist eine Empfehlung mit Quellen, nicht ein Befehl.

Mobile-First UX: was am Techniker-Gerät wirklich funktioniert

Die elegante Web-Oberfläche, die im Büro überzeugt, scheitert in der Werkshalle. Was funktioniert:

• Sprachsteuerung als Standard-Eingabe. Whisper oder ein vergleichbares Speech-to-Text-Modell läuft lokal auf dem Tablet. Tippen mit Handschuhen ist die Ausnahme.
• Große Touch-Targets für Folgefragen („Zeig mir das Schaltbild”, „Welche Ersatzteile habe ich dabei?”). Mindestens 48 px Touch-Größe.
• Cache-First-Architektur. Service-Aufträge der nächsten 24 Stunden plus die zugehörigen Wissens-Chunks werden vorgeladen. Im Funkloch funktioniert das System weiter.
• Quellen-Sprung in einem Tap. Wenn der Techniker an der Antwort zweifelt, kann er die zitierte Handbuchseite oder das alte Service-Ticket sofort öffnen.
• Foto-Eingabe für Diagnose-Hilfe. Foto eines Bauteils → Embedding-Suche im Konstruktionsdaten-Index → „Das ist das Magnetventil MV-403.”

In den ersten Wochen werden Sie unterschätzen, wie sehr „lauter Hintergrund” und „schmutzige Hände” die UX dominieren. Planen Sie eine zweite Sprachmodell-Runde nach 4 Wochen ein, in der Sie Wake-Word und Sprach-Confidence neu kalibrieren.

Datenresidenz für die Fertigung: drei pragmatische Szenarien

Konstruktionsdaten, Reparaturberichte und Kundennamen sind sensible Daten. Die ernsthaften Optionen 2026:

• EU-Cloud mit AVV. Azure OpenAI in der EU-Region, AWS Bedrock EU, Mistral La Plateforme. Gut für 60–70 % der Mittelstandsfälle: günstig, schnell live, sauberer AVV.
• On-Premise / Werks-Inferenz. Ein lokaler GPU-Server (1–2 H100) im eigenen Rechenzentrum. Llama 3.3 70B oder Qwen 2.5 72B als Inferenz, lokaler Vektor-Store (Qdrant, Weaviate, pgvector). Sinnvoll bei militärischen Komponenten, Schutzrechtsschutz, sehr restriktivem Geheimhaltungsvertrag mit Kunden.
• Hybrid. Sensible Dokumente (Konstruktionszeichnungen, militärrelevantes Material) auf einer separaten On-Premise-Instanz; alltägliches Wissen (Handbücher von Drittherstellern, allgemeine Service-Berichte) in der EU-Cloud. In unseren Projekten der häufigste Setup für Maschinenbauer mit gemischtem Kundenportfolio.

Was Sie nicht tun sollten: Konstruktionsdaten direkt in eine USA-API hochladen. Selbst mit Zero-Data-Retention-Add-on ist die Drittlands-Diskussion 2026 noch nicht abschließend geklärt. Mehr dazu in unserer Compliance-Übersicht.

Realistische Bandbreiten

• Trefferquote auf Erstantwort 70–85 % bei sauber indexierten Quellen (Handbuch, Service-Historie, Hersteller-Bulletins). Bei nicht-indexierten Quellen (z. B. ungescannte Papierdokumente) fällt die Quote schnell auf 40–60 %.
• Antwortzeit am Gerät unter 3 Sekunden für die typische Frage, wenn das Tablet online ist; unter 6 Sekunden bei mobilem 4G.
• Eskalations-Quote 5–15 % in den ersten Wochen, sinkend auf 3–8 % nach drei Monaten Optimierung.
• Trainings-Aufwand für die Techniker 1–2 Stunden pro Person. Das System ist absichtlich so schlank gehalten, dass es keine separate Schulung braucht.

Häufige Fragen

Müssen wir alle Handbücher selbst digitalisieren? Bei Hersteller-Maschinen meist nicht. Hersteller liefern aktuelle Handbücher in den meisten Fällen als PDF mit ordentlichem Volltext aus. Älter als 10 Jahre und nur als Scan: ja, dann hilft eine moderne OCR-Stufe. Aufwand: 100–300 € pro Handbuch extern, oder eine OCR-Pipeline (Tesseract 5 oder AWS Textract) intern.

Was passiert mit unstrukturierten Service-Tickets? Die werden vor dem Indexieren strukturiert. Ein LLM extrahiert Symptom, Diagnose, Lösung und Ersatzteile pro Ticket. Aufwand bei 5.000 historischen Tickets: 1–3 Personentage für die Pipeline, 2–4 Stunden Inferenz, plus Sample-Review durch Senior-Techniker.

Wer hält das System aktuell? Hersteller-Updates landen automatisch im System (siehe Quelle 3). Handbuch-Updates werden manuell eingespeist, typisch durch den Service-Verantwortlichen, der bei jedem Major-Update einen kurzen Workflow durchläuft (PDF einlesen, Version markieren, alte Version archivieren). Aufwand 10–30 Minuten pro Update.

Lohnt sich das auch für kleinere Service-Organisationen? Ab 5 aktiven Außendienst-Technikern und mindestens 30 unterschiedlichen Maschinen-Modellen im Service-Portfolio rechnet sich ein eigener Service-RAG. Darunter funktioniert oft eine generische Lösung wie Notion AI oder Confluence AI besser.

Wie integrieren wir das in unser bestehendes Field-Service-Management-System (Microsoft FSM, ServiceNow, Salesforce Field Service)? Über die jeweilige API. FSM-Systeme bieten alle ein Activity-Log, in das der RAG-Hinweis als interne Notiz geschrieben wird; die Eingabe des Technikers läuft typisch über eine schlanke Companion-App oder ein eingebettetes Web-View.

Brauchen wir ein PIM-/CMS-System für die Quellen? Nein. Die Quellen können in ihren bestehenden Systemen bleiben, der RAG indexiert sie. Wenn Sie ohnehin ein DAM (Digital Asset Management) oder eine zentrale Dokumentenablage einführen, integrieren Sie den RAG dort hinein.

Wo Sie ansetzen, wenn Sie heute starten möchten

Drei Schritte, mit denen Sie eine seriöse Pilot-Entscheidung treffen können:

1. Eine Liste der Top-50-Service-Anfragen der letzten 12 Monate erstellen. Welche Fragen kommen wiederholt von welchen Maschinen? Diese Liste zeigt, ob ein RAG die wirklichen Engpässe trifft oder nur Show-Effekte erzielt.
2. Den aktuellen Quellenbestand kartieren. Wie viele Handbücher liegen digital vor, in welcher Qualität? Wie strukturiert ist die Service-Historie? Diese Bestandsaufnahme entscheidet über den Implementierungsaufwand.
3. Eine Pilot-Maschinen-Linie wählen. Eine Baureihe mit hoher Service-Last und vollständiger Dokumentation. Dort lässt sich der Mehrwert in 6–10 Wochen messbar zeigen, bevor Sie auf das Gesamt-Portfolio skalieren.

Wenn Sie wissen wollen, welche Maschinen-Linie sich für einen Service-RAG-Piloten eignet, und ob Ihre Datenlage trägt, vereinbaren Sie ein Beratungsgespräch. 30 Minuten reichen für eine ehrliche Einschätzung der drei Hauptquellen und des realistischen Aufwands.