Produktionshalle, zwei Uhr nachts. Ein erfahrener Techniker sucht in einem 3.400-seitigen Gerätehandbuch, welchen Schmierstofftyp und welche Menge der Hersteller für ein Lager bei Temperaturen über 80 °C vorschreibt. Das PDF hat inkonsistente Seitennummerierung, die relevante Wertetabelle ist als Bild eingescannt, und die Norm, auf die das Handbuch verweist, befindet sich in einer separaten Datei. Nach 40 Minuten findet er, was er gesucht hat. Dieselbe Situation wiederholt sich dutzende Male pro Schicht, im gesamten Werk.
Genau dieses Problem lösen LLM über industrieller Dokumentation. Es geht nicht um einen Buzzword — es ist ein konkreter, verifizierbarer Use-Case, bei dem ein korrekt eingesetztes System messbare Stunden pro Bediener und Monat einspart. Dieser Artikel trifft die Entscheidung: was funktioniert, wo der naive Ansatz scheitert und was Sie lösen müssen, bevor Sie beginnen.
Was Sie eigentlich erreichen wollen
Klären Sie vor der Architektur, was Sie vom System erwarten. In der Praxis sehen wir drei unterschiedliche Use-Cases, die sich ähneln, aber verschiedene Anforderungen haben:
1. Suche und Q&A für Techniker — der Techniker stellt eine natürlichsprachliche Frage, das System antwortet mit einem Verweis auf einen konkreten Abschnitt des Handbuchs oder der Norm. Kein bloßes Abtippen von Text, sondern eine Antwort mit Quellenangabe: „Gemäß Abschnitt 7.3.2 des Gerätehandbuchs XY ist das vorgeschriebene Schmiermittel ISO VG 220, alle 2.000 Betriebsstunden aufzutragen."
2. SOP-Navigation und Schritt-für-Schritt-Assistenz — ein Bediener arbeitet nach einer Vorgehensweise und benötigt eine Erklärung eines Schritts, eine Alternative bei einem nicht verfügbaren Werkzeug oder eine schnelle Überprüfung, ob er das Richtige tut. Das System muss deterministisch und präzise sein — eine falsche Antwort bei einem Fertigungsverfahren hat direkte Kosten.
3. Normative Compliance und Audit-Unterstützung — ein Ingenieur muss schnell feststellen, welche Dokumentationsteile die Anforderungen einer bestimmten Norm abdecken (z. B. ISO 9001, IEC 62443, ATEX), oder Lücken identifizieren. Das erfordert ein Verständnis sowohl der Normstruktur als auch der internen Dokumentation.
Jeder dieser Use-Cases hat unterschiedliche Anforderungen an Präzision, Latenz und Evaluierungsmethodik. Sie in einem einzigen Piloten zu vermischen, ist ein häufiger Fehler.
Warum naives RAG bei industriellen Dokumenten scheitert
RAG — die Abkürzung für Retrieval-Augmented Generation — ist die grundlegende Architektur: Dokumente werden in Teile (Chunks) zerlegt, in einer Vektordatenbank gespeichert, bei einer Anfrage werden relevante Teile gefunden und dem Modell vorgelegt. Bei gewöhnlichen Dokumenten funktioniert das gut. Bei industriellen Dokumenten stoßen Sie auf vier Probleme, die aktiv gelöst werden müssen.
Problem 1: Tabellen werden durch naives Chunking zerstückelt
Ein Gerätehandbuch enthält eine Tabelle mit 30 Zeilen und 8 Spalten: Gerätetyp, Betriebstemperatur, Schmierstofftyp, Intervall, Menge, Norm, Anmerkung, Höhenlage. Naives Chunking nach Zeichenanzahl zerschneidet diese Tabelle in 4 Fragmente. Jedes Fragment verliert den Kontext der Spalten, die auf der vorherigen Seite standen.
Lösung: ein Dokumenten-Parser, der Tabellen erkennt und als Ganzes erhält, gegebenenfalls in strukturierter Form konvertiert (JSON, Markdown-Tabelle). Werkzeuge wie LlamaIndex verfügen über spezialisierte Parser für diese Fälle. Multimodale Modelle (z. B. Qwen2.5-VL) können Tabellen auch aus eingescannten PDFs extrahieren — was bei älteren Handbüchern häufig vorkommt.
Problem 2: Zeichnungen und Schaltpläne sind für text-only RAG unsichtbar
Elektrische Schaltpläne, Hydraulikdiagramme, P&ID (Piping and Instrumentation Diagrams) — das sind zentrale Teile der technischen Dokumentation, die eine text-only Pipeline einfach überspringt. Fragt ein Techniker „Wo ist Ventil V-12 im Hydraulikschema der Linie L2 eingebaut?", antwortet text-only RAG mit „Information in den Dokumenten nicht gefunden" oder halluziniert.
Die Lösung hängt von den verfügbaren Ressourcen ab. Der einfachere Weg: für Schlüsselzeichnungen strukturierte Textbeschreibungen erstellen (einmalig, manuell oder mit Unterstützung eines VLM), die gemeinsam mit dem übrigen Text indexiert werden. Der aufwendigere Weg: eine vollwertige multimodale Pipeline, bei der das VLM die Bildbeschreibung direkt bei der Indexierung generiert — funktioniert, erfordert aber bei jedem neuen Dokument ein rechenintensives Modell.
Problem 3: Normversionen und Querverweise
Industrielle Dokumentation ist voll von Verweisen: „Vorgehen gemäß ISO 14119:2013, Anhang D" oder „Siehe Zeichnung D-04-7812-rev3". Naives RAG löst diese Verweise nicht auf — es lädt das Fragment, in dem die Norm erwähnt wird, hat aber keinen Zugriff auf den eigentlichen Norminhalt, wenn dieser nicht im Index enthalten ist. Ergebnis: eine Antwort, die den Verweis zitiert, aber keine tatsächliche Information enthält.
Lösung: konsequentes Quellmanagement. Vor der Inbetriebnahme muss explizit entschieden werden, welche Normen und Versionen zum Index gehören, und ein Aktualisierungsprozess bei Revisionen eingeführt werden. Dies ist ebenso ein organisatorisches wie ein technisches Problem.
Problem 4: Das Context Window ist nicht unbegrenzt
Auch das 1M-Token-Kontextfenster von Frontier-Modellen ist keine Lösung für ein 5.000-seitiges Handbuch. Die Aufmerksamkeit des Modells streut bei extrem langen Eingaben — ein Phänomen, das die Forschung wiederholt bestätigt. RAG bleibt auch bei Modellen mit langem Kontext relevant, weil es selektiv nur die relevanten Teile lädt statt des gesamten Dokuments.
Wie man eine zuverlässige Pipeline aufbaut
Eine bewährte Pipeline für industrielle Dokumentation hat mehrere Schichten über dem grundlegenden RAG.
Dokumentenvorbereitung (Ingestion)
Dies ist der längste und am meisten unterschätzte Schritt. Vor der Indexierung:
- Inhaltstypen unterscheiden: reiner Text, Tabellen, Bilder, Zeichnungen. Jeder Typ verdient eine eigene Verarbeitung.
- Eingescannte Dokumente über OCR — nicht das alte
Tesseractfür komplexe technische Dokumente, sondern ein spezialisiertes VLM oder eine Document-Intelligence-API, die den Seitenkontext versteht (Zahl in der rechten Ecke = Seitenzahl, dieselbe Zahl in einer Tabelle = kritischer Wert). Mehr zu dieser Schicht im Artikel OCR und Document Intelligence für die Industrie. - Metadaten: für jeden Chunk Quelldokument, Seitenzahl, Abschnitt, Dokumentversion und Gültigkeitsdatum speichern. Ohne Metadaten sind keine Quellenangaben möglich.
- Hierarchische Struktur: Kapitel → Unterkapitel → Tabelle/Verfahren.
LlamaIndexbietet native Unterstützung für hierarchisches Chunking.
Retrieval — mehr als nur Vektorsuche
Die reine Vektorsuche hat Schwächen: Sie erfasst semantisch ähnliche Passagen, kann aber eine exakte Schlüsselwortübereinstimmung verpassen (Teilenummer, Alarmcode, Gerätebezeichnung). Hybrid Search — Kombination aus BM25 (Schlüsselwörter) und Vektoren — ist im industriellen Kontext wichtiger als bei gewöhnlichen Anwendungen. Lesen Sie dazu Hybrid Search mit BM25 und Vektoren, wo das im Detail ausgeführt wird.
Fügen Sie über der hybriden Suche einen Reranker hinzu — ein Modell, das die Ergebnisse nach Relevanz zur Frage sortiert. Der BGE Reranker (frei verfügbar) oder eine API (z. B. Cohere Rerank) verbessert die Präzision bei langen Dokumenten mit wiederkehrenden Phrasen deutlich.
Generierung mit Quellenangaben
Das ist der entscheidende Unterschied zu einem gewöhnlichen Chatbot: Jede Antwort muss einen Verweis auf eine konkrete Quelle enthalten. Der Prompt muss explizit verlangen: - Welches Dokument, welcher Abschnitt, welche Seite. - Wörtliches Zitieren des kritischen Werts statt Paraphrasierung. - Explizite Aussage, wenn die Information in den verfügbaren Dokumenten nicht vorhanden ist.
Der letzte Punkt ist entscheidend. Die Antwort „Diese Information finde ich in den verfügbaren Handbüchern nicht" ist deutlich besser als ein selbstsicherer halluzinierter Wert. Die Konfiguration eines System-Prompts, der das Modell zur expliziten Äußerung von Unsicherheit anhält, ist wichtiger als die Modellwahl. Mehr zu Quellenangaben und Grounding in RAG finden Sie im Artikel Quellenangaben und Grounding in RAG.
Evaluierung vor dem Einsatz
Setzen Sie Techniker keinem System aus, das Sie nicht an realen Fragen getestet haben. Ein grundlegendes Evaluierungsset:
- 50–100 Fragen aus realen Situationen, mit denen Techniker tatsächlich konfrontiert sind
- Für jede Frage eine verifizierte Antwort mit Quellenangabe (Gold Standard)
- Messung: Faithfulness (stimmt die Antwort mit der Quelle überein?), Answer Relevance (beantwortet sie die Frage?), Halluzinationsrate
Produktionssysteme setzen sich Ziele: Faithfulness ≥ 95 %, Halluzinationsrate ≤ 2 %. Korrekt implementiertes RAG reduziert Halluzinationen um 60–71 % gegenüber einem reinen LLM ohne Grounding — beseitigt sie aber nicht vollständig.
Modellwahl: Cloud vs. On-Premises
Für industrielle Dokumente gilt eine andere Logik als für öffentliche Deployments. Technische Dokumentation enthält oft internes Know-how, Konstruktionsparameter, Sicherheitsverfahren. Viele Unternehmen, insbesondere in regulierten Branchen, möchten diese Daten nicht außerhalb ihrer eigenen Infrastruktur haben.
On-Premises Open-Weight-Modelle sind 2026 eine realistische Wahl:
Qwen 2.5undQwen 3Familie (Apache-2.0-Lizenz, geeignet für kommerzielle Deployments) — stark im Document Understanding einschließlich multimodaler Varianten.Mistral Small(~22B) — gutes Verhältnis von Leistung zu Hardware-Anforderungen.DeepSeek R1/V3(MIT-Lizenz) — starkes Reasoning, geeignet für komplexere Fragen zu Normen und deren Interpretation.
Richtwerte für den Hardware-Bedarf: für ein 7B-Modell reicht eine Karte mit 12–14 GB VRAM (QLoRA/quantized inference), für ein 22B-Modell benötigen Sie 24 GB+ oder mehrere GPUs. Mehr zur Hardware-Auswahl im Artikel Custom-PC für lokale LLM.
Für Unternehmen ohne sensible Daten oder mit klarer Data-Governance-Richtlinie sind Frontier-Modelle (Claude Sonnet, GPT-4o-Klasse) beim komplexen Reasoning über strukturierte Dokumente deutlich leistungsfähiger — gegen API-Kosten und Daten-Egress.
Organisatorische Voraussetzungen, die Technologie nicht löst
Aus dutzenden RAG-Deployments über Dokumentation haben wir gesehen, dass der technische Teil meist das kleinere Problem ist als der organisatorische.
Dokumentenversionsverwaltung. Wenn ein Handbuch in fünf Versionen auf verschiedenen gemeinsamen Laufwerken ohne klare Kennzeichnung der aktuellen Version existiert, indexieren Sie Chaos. Vor dem KI-Einsatz muss eine Single Source of Truth existieren — eine einzige maßgebliche Quelle für die aktuelle Dokumentation. Das ist kein KI-Problem, sondern ein Document-Management-Problem.
Verantwortlichkeit für Index-Aktualisierungen. Wer fügt wann ein neues Handbuch hinzu? Wer invalidiert eine alte Normversion? Ohne einen definierten Prozess arbeitet das System nach 6 Monaten mit veralteten Daten, und die Techniker verlieren das Vertrauen darin.
Angemessene Erwartungen bei den Technikern. Ein System, das auf 10 % der Fragen nicht antwortet und „Ich weiß es nicht" sagt, ist ein korrekt konfiguriertes System. Wenn Techniker eine 100 %-Abdeckung erwarten, wird das erste „Ich weiß es nicht" als Versagen interpretiert. Onboarding ist Teil des Projekts.
Wo das System scheitert — und was dagegen zu tun ist
Auch ein gut aufgebautes System hat Grenzen. Eine ehrliche Definition dieser Grenzen vor dem Go-live schützt das Projekt vor Enttäuschungen.
Prozedurale Sicherheit: Das System sollte niemals die einzige Wahrheitsquelle für Vorgehensweisen bei Arbeiten unter Spannung, Arbeiten in ATEX-Zonen oder anderen sicherheitskritischen Operationen sein. RAG vs. Fine-Tuning für industrielle Deployments erläutert, wann Fine-Tuning besser als RAG ist — genau für diese Fälle — aber auch ein fine-getuntes Modell ersetzt keine zertifizierte Schulung und Prüfung durch eine verantwortliche Person.
Neue Geräte ohne Dokumentation: Wenn ein Gerät nicht im Index ist, antwortet das System nicht. Das ist ein Feature, kein Bug — schlimmer wäre es, wenn es eine nicht existierende Dokumentation halluzinieren würde.
Komplexe Diagnostik: Fragen wie „Warum vibriert mein Gerät mehr als üblich?" gehen über dokumentenbasierte Q&A hinaus. Hier ist der Platz für Predictive Analytics und Sensordaten, nicht für RAG über Handbücher.
Häufige Fragen
Brauchen wir Fine-Tuning, oder reicht RAG?
Für die meisten Use-Cases über Dokumentation reicht RAG — es erfordert keine Datensatzvorbereitung, kein Training und kein Risiko einer Modell-Degradation. Fine-Tuning schafft Mehrwert, wenn das Modell die spezifische Terminologie Ihres Unternehmens verstehen oder in einem bestimmten Format antworten soll. Den Entscheidungsrahmen finden Sie im Artikel RAG vs. Fine-Tuning.
Wie stellen wir sicher, dass das System keine technischen Werte halluziniert?
Kombination aus drei Maßnahmen: (1) ein Prompt, der explizit untersagt, außerhalb der verfügbaren Quellen zu antworten, und eine Quellenangabe verlangt, (2) ein Reranker, der die Qualität des abgerufenen Kontexts verbessert, (3) ein Evaluierungsset mit regelmäßigen Tests. Eine Halluzinationsrate unter 2–3 % erreichen Sie bei konsequenter Implementierung — null niemals.
Verarbeitet das System Dokumente auf Deutsch, Englisch und Slowakisch?
Ja, moderne Embedding-Modelle (z. B. BGE-M3) sind mehrsprachig und funktionieren sprachübergreifend gut. Fragen und Antworten können in einer anderen Sprache als das Quelldokument vorliegen. In der Praxis empfehlen wir, Dokumente in ihrer Originalsprache zu indexieren und das Modell in der Antwort übersetzen zu lassen — so bleibt die terminologische Präzision erhalten.
Wie lange dauert die Implementierung eines Piloten?
Ein Pilotsystem für eine Dokumentationsart (z. B. Handbücher für ein Gerät) mit Evaluierungsset und einer einfachen Benutzeroberfläche liegt im Umfang von 4–8 Wochen. Die Datenvorbereitung (OCR, Bereinigung, Versionsverwaltung) nimmt mehr Zeit in Anspruch als die eigentliche technische Implementierung. Ein vollwertiges Produktionssystem mit mehreren Dokumentationstypen und Integration in bestehende Systeme: 3–6 Monate.
Funktioniert das auch für ISO-Normen und regulatorische Dokumente?
Ja, aber mit einem wichtigen Vorbehalt: Normen unterliegen dem Urheberrecht (ISO, EN, DIN). Sie können eine erworbene Norm nicht einfach in ein internes System hochladen — prüfen Sie die Lizenzbedingungen. In der Praxis indexieren Unternehmen interne Dokumente, die die Norm umsetzen (technische Vorschriften, Checklisten), und verweisen auf konkrete Anforderungsnummern, anstatt den normativen Text wörtlich zu zitieren.
*Wenn Sie überlegen, wie Sie unter den spezifischen Bedingungen Ihrer Dokumentation erste Schritte unternehmen können — Use-Case-Verifizierung, Beurteilung der verfügbaren Daten, Architekturvorschlag — stehen wir für eine Beratung zur Verfügung. MP Industrial Solutions implementiert RAG über industrieller Dokumentation von der Datenvorbereitung bis zum Produktionseinsatz.*