KI für technische Dokumentation: vom PDF-Berg zur beantwortbaren Frage

KI für technische Dokumentation heißt in der Praxis: Handbücher, Datenblätter, Prüfprotokolle und Wartungsberichte so aufbereiten, dass ein System eine konkrete Frage aus der Instandhaltung mit Dokument, Version und Seite beantwortet – oder sagt, dass es keinen Beleg gefunden hat. Ob das gelingt, entscheidet sich nicht beim Sprachmodell, sondern davor: bei der Inventur des Bestands, beim Parsing der PDFs und beim Zuschnitt der Textabschnitte. Dieser Artikel beschreibt genau diese Vorstufe, die in Produktbeschreibungen meist fehlt.

Was heißt eigentlich „KI für technische Dokumentation“?

Hinter dem Begriff stecken drei technisch verschiedene Ebenen, die in Angeboten oft vermischt werden. Die erste ist die Volltextsuche: Alle Dokumente werden textlich erfasst und indexiert, gefunden werden exakte Wörter und Wortstämme. Die zweite ist die semantische Suche: Textabschnitte werden als Vektoren abgelegt, gefunden wird, was inhaltlich nahe an der Frage liegt, auch ohne Wortübereinstimmung. Die dritte ist die generative Antwort mit Beleg, meist als Retrieval Augmented Generation (RAG) bezeichnet: Ein Sprachmodell formuliert aus den gefundenen Abschnitten eine Antwort und verweist auf die Fundstellen.

In der Praxis wollen viele Betriebe direkt auf die dritte Ebene, obwohl die zweite häufig schon das eigentliche Problem löst: Handbücher durchsuchbar zu machen, damit ein Instandhalter die richtige Seite im richtigen Dokument findet. Eine Suche, die Treffer mit Kontext und Seitenzahl liefert, ist schneller abgenommen, leichter zu prüfen und günstiger im Betrieb. Die generative Antwort lohnt sich, wenn Fragen regelmäßig mehrere Dokumente kombinieren oder Nutzer in Alltagssprache fragen, die von der Herstellerterminologie abweicht.

Embedding

Ein Zahlenvektor, der die Bedeutung eines Textabschnitts abbildet. Ähnliche Inhalte liegen im Vektorraum nahe beieinander, auch wenn sie andere Wörter verwenden.

Chunk

Der Textabschnitt, der als kleinste Einheit indexiert und später gefunden wird. Seine Grenzen entscheiden, ob eine Information vollständig oder zerschnitten ankommt.

Retrieval

Die Suche nach den Chunks, die zu einer Frage am besten passen, in der Regel über den Abstand der Vektoren. Der Retriever liefert Kandidaten, keine Antwort.

Reranking

Ein zweiter, genauerer Bewertungsschritt, der die gefundenen Kandidaten neu sortiert. Er filtert Treffer heraus, die nur oberflächlich passen.

Welche Dokumentarten lassen sich heute realistisch erschließen?

Am besten lassen sich Dokumente erschließen, die digital erzeugt wurden und einen linearen Textfluss haben; am schlechtesten solche, deren Information in Grafik, Symbolik oder Handschrift steckt. Dazwischen liegt der Großteil eines gewachsenen Bestands. Eine Sortierung nach Dokumentklasse ist deshalb der erste Schritt jeder KI-Dokumentenanalyse in der Industrie, noch vor jeder Werkzeugauswahl. Wer technische Dokumentation mit KI auswerten will, sollte Tab. 02 gegen den eigenen Bestand durchgehen (OCR: optische Zeichenerkennung, P&ID: Rohrleitungs- und Instrumentenfließbild, CMMS: Instandhaltungssoftware).

Zwei Klassen verdienen einen Zusatz. Wer Datenblätter automatisch auslesen will, braucht keine Antwortmaschine, sondern saubere Tabellenextraktion: Der Kennwert gehört mit Einheit, Prüfbedingung und Fußnote in ein Feld, nicht in einen Fließtext-Chunk. Und wer Normen mit KI recherchieren will, stößt auf ein nicht-technisches Problem: Normtexte sind urheberrechtlich geschützt und lizenziert. Ob die Lizenz eine Volltextindexierung im internen System abdeckt, klären Sie vor dem Import mit dem Lizenzgeber; bis dahin bleiben Metadaten, Inhaltsverzeichnisse und die eigenen Umsetzungsdokumente der sichere Weg.

Bei Wartungsberichten liegt der Wert weniger in der einzelnen Meldung als im Muster über Jahre – dieselbe Störung, dieselbe Komponente, dieselbe Schicht. Wie sich Störungshistorien dafür aufbereiten lassen, steht in Wartungsberichte und Störungshistorien mit KI auswerten.

Woran das Parsing scheitert – und wie Sie es vorher merken

Parsing scheitert selten am Text und fast immer am Layout. Ein PDF speichert keine Absätze, Tabellen oder Überschriften, sondern positionierte Zeichen. Alles, was ein Mensch als Struktur sieht, muss ein Parser rekonstruieren – und genau dabei entstehen die Fehler, die später in jeder Antwort landen. Die häufigsten Muster in technischer Dokumentation:

• —Mehrspaltige Layouts, deren Spalten zeilenweise ineinander gelesen werden
• —Tabellen ohne Rahmenlinien, bei denen Spaltenzuordnung und Einheiten verloren gehen
• —Fußnoten und Randbemerkungen, die mitten im Fließtext auftauchen
• —Maßangaben, Toleranzen und Warnsymbole, die als Grafik eingebettet sind und keine Textebene haben
• —Kopf- und Fußzeilen mit Dokumentnummer und Revisionsstand, die in jeden Abschnitt wandern und die Suche verwässern
• —Tabellen über einen Seitenumbruch, die als zwei Tabellen ohne Kopfzeile ankommen

Textextraktion und Layout-Erkennung sind zwei verschiedene Aufgaben. Die Extraktion liest Zeichen aus; die Layout-Erkennung entscheidet, welche Zeichen zu welchem Block gehören, in welcher Reihenfolge die Blöcke zu lesen sind und ob ein Block Tabelle, Überschrift oder Bildunterschrift ist. Werkzeuge, die nur extrahieren, liefern bei einer einspaltigen Betriebsanleitung brauchbare Ergebnisse und bei einem Datenblatt Zeichensalat.

Dafür gibt es einen öffentlichen Maßstab. OmniDocBench, auf der CVPR 2025 vorgestellt, umfasste im Paper 981 PDF-Seiten aus neun Dokumenttypen; die aktuelle Fassung des Datensatzes (v1.6) enthält 1.651 Seiten aus zehn Typen. Bewertet wird getrennt: Text über die normalisierte Edit Distance, Tabellenstruktur über TEDS (Tree-Edit-Distance-based Similarity), Formeln über CDM (Character Detection Matching), Lesereihenfolge ebenfalls über die Edit Distance. Seitenattribute wie unscharfer Scan, Wasserzeichen, farbiger Hintergrund und Spaltenzahl sind einzeln annotiert.

Die Autoren berichten einen deutlichen Genauigkeitsverlust bei mehrspaltigen und komplexen Layouts sowie bei unscharfen Scans, Wasserzeichen und farbigen Hintergründen; eine der getesteten Pipelines erkannte handschriftliche Notizen vollständig als Abbildung. Für Sie heißt das: Sie können nachsehen, wie ein Verfahren auf Seiten abschneidet, die Ihren eigenen ähneln – und von einem Anbieter eine TEDS-Zahl für Tabellen verlangen statt einer Demo auf seinen Beispieldokumenten.

Chunking: der unterschätzte Schritt

Chunking legt fest, welche Texteinheit das System später findet und dem Sprachmodell vorlegt – und damit, ob eine Antwort überhaupt vollständig sein kann. Der einfachste Weg sind gleich große Abschnitte mit einer festen Zeichenanzahl – und für technische Dokumentation ist er oft die schlechteste Wahl. Solche Schnitte trennen Warntexte von ihrer Handlungsanweisung, die Normreferenz von der Anforderung, auf die sie sich bezieht, und Tabellenzeilen von ihrer Kopfzeile.

Strukturbasiertes Chunking folgt stattdessen dem Dokument: Ein Abschnitt endet dort, wo die nächste Überschrift derselben oder einer höheren Ebene beginnt. Tabellen bleiben als Einheit zusammen und tragen ihre Kopfzeile in jeden Teil, wenn sie geteilt werden müssen. Warnhinweise bleiben mit dem Arbeitsschritt verbunden, zu dem sie gehören. Die Orientierungshilfe der Datenschutzkonferenz zu RAG-Systemen benennt die systembedingte Schwäche: Informationen, die logisch zusammengehören, aber keine ausreichende semantische Nähe aufweisen, landen unter Umständen nicht im selben Chunk. Gutes Chunking ist der Versuch, genau das zu verhindern.

Ebenso wichtig sind die Metadaten, die jeder Chunk mitführt. Ohne sie kann das System später weder nach Maschinentyp filtern noch eine Seitenzahl nennen. Mindestens gehören dazu:

• —Dokument-ID und Titel
• —Version bzw. Revisionsstand und Ausgabedatum
• —Kapitelpfad, etwa „7 › 7.3 › 7.3.2 Lagerdeckel montieren“
• —Seitenzahl oder Seitenbereich
• —Maschinentyp, Baureihe und Seriennummernbereich
• —Sprache der Fassung
• —Dokumentklasse (Anleitung, Datenblatt, Protokoll, Bericht)
• —Gültigkeitsstatus (gültig, ersetzt, zurückgezogen)

{
  "chunk_id": "BA-4711-C_007-003-002",
  "document_id": "BA-4711",
  "title": "Betriebsanleitung Rundtaktmaschine RT-200",
  "revision": "C",
  "issued": "2024-03-15",
  "status": "gueltig",
  "language": "de",
  "doc_class": "betriebsanleitung",
  "chapter_path": ["7 Instandhaltung", "7.3 Spindeleinheit", "7.3.2 Lagerdeckel montieren"],
  "pages": [112, 113],
  "machine_type": "RT-200",
  "serial_range": "RT200-2019-0001..RT200-2023-0450",
  "text": "WARNUNG – Vor Beginn der Arbeiten Hauptschalter ausschalten und gegen Wiedereinschalten sichern. …"
}

Versionsstände, Mehrsprachigkeit und Gültigkeit

Dasselbe Handbuch existiert in einem gewachsenen Betrieb typischerweise in mehreren Revisionen, und nur eine davon gilt für die Maschine, die gerade steht. Ein Antwortsystem, das den Gültigkeitsbezug nicht kennt, mischt Anzugsmomente aus Revision B mit Sicherheitsabständen aus Revision D – in einer Antwort, die flüssig und plausibel klingt. In der Instandhaltung ist das keine Unschärfe, sondern ein Sicherheitsrisiko.

Drei Fälle müssen vor dem Import geklärt sein. Erstens der Revisionsbezug: Welche Dokumentversion gilt für welchen Seriennummernbereich, und wer pflegt diese Zuordnung? Zweitens die Sprachfassungen: Deutsche und englische Ausgaben desselben Dokuments sind nicht immer inhaltsgleich; Kapitel fehlen oder wurden später ergänzt. Das System sollte wissen, welche Fassung die Referenz ist. Drittens der Status: Zurückgezogene Dokumente dürfen gefunden werden – aber nur mit Kennzeichnung und nie als Grundlage einer Antwort ohne diesen Hinweis.

Dieses Metadatenmodell müssen Sie nicht erfinden. Mit iiRDS, dem Intelligent Information Request and Delivery Standard, pflegt die tekom, der Fachverband für technische Kommunikation, einen offenen Standard, der Metadaten für Informationsanfragen und ein Paketformat für die Auslieferung technischer Information definiert. Die aktuelle Version 1.3 erschien im November 2025; Spezifikation und RDF-Schemata stehen unter einer Creative-Commons-Lizenz. Selbst wenn Ihre Lieferanten noch nicht in iiRDS ausliefern, eignet sich das Vokabular als Vorlage für die eigenen Chunk-Metadaten – und als Lieferformat, das Sie im Lastenheft neuer Maschinen fordern können.

Quellenangabe und Antwortverweigerung als Abnahmekriterium

Eine Antwort ohne Dokument, Version und Seite ist in der technischen Dokumentation wertlos, weil niemand sie prüfen kann. Die Quellenangabe dient nicht dem Komfort; sie macht die Antwort überhaupt erst zu einer belastbaren Information, für die jemand Verantwortung übernehmen kann. Der zweite Teil desselben Kriteriums ist die Verweigerung: Findet das Retrieval keinen ausreichenden Beleg, muss das System das sagen, statt aus dem Vorwissen des Sprachmodells (Large Language Model, LLM) zu antworten. Die Datenschutzkonferenz beschreibt in ihrer Orientierungshilfe das Zielbild eines RAG-Systems so:

Dieselbe Orientierungshilfe merkt in einer Fußnote an, dass dieser Idealfall technisch nicht immer erreicht wird und Vorwissen des Modells ungewollt in die Ausgabe gelangen kann. Das BSI beschreibt in seiner Publikation zu generativen KI-Modellen, warum das kritisch ist: Halluzinationen erscheinen glaubhaft, insbesondere wenn auf Referenzen verwiesen wird, die selbst erfunden sein können. Das BSI empfiehlt nutzenden Unternehmen deshalb eine individuelle Risikoanalyse vor der Integration.

In der Dokumentenanalyse heißt das konkret: Belegpflicht pro Aussage, ein Schwellenwert für die Trefferqualität, unterhalb dessen nicht geantwortet wird, ein Protokoll aus Frage, verwendeten Chunks und Antwort – und die Übernahme der Zugriffsrechte aus dem Quellsystem, damit niemand per Frage an ein Dokument kommt, das er nicht öffnen darf. Wie sich das in eine Architektur übersetzt, beschreibt Chatbot für technische Handbücher: Architektur, Quellenangabe und Grenzen.

Wo die Technik heute versagt

Es gibt Dokumentklassen, bei denen auch gute Werkzeuge heute keine verlässliche Erschließung liefern – und es ist besser, das vor dem Projekt zu wissen als danach. Die folgenden Fälle gehören in einem ersten Pilot nicht in den Index, sondern auf eine Liste für später:

• —Schaltpläne und P&ID-Fließbilder: Die Information liegt in Symbolen und Verbindungen, nicht in Text
• —Handschriftliche Vermerke auf Protokollen und Zeichnungen
• —Tabellen über mehrere Seiten mit wiederholter oder fehlender Kopfzeile
• —Schlecht gescannte Altbestände: schief, unscharf, mit Stempeln und Wasserzeichen
• —Symbolik ohne Legende, deren Bedeutung nur im Betriebswissen existiert
• —Maßketten, Toleranzen und Oberflächenangaben in Fertigungszeichnungen

Wie weit die Forschung bei Zeichnungen ist, zeigt ein Projekt des Fraunhofer IPA zur automatischen Erkennung fertigungsrelevanter Informationen in 2D-Zeichnungen. Dort werden Bemaßungen, Toleranzen und Zusatzangaben wie eine Wärmebehandlung per OCR ausgelesen und Symbole mit einem YOLO-Netz erkannt. Das Institut selbst gibt die Erkennungsrate mit etwa 70 Prozent an. Diese Zahl ist eine Fremdangabe des Fraunhofer IPA aus einem Forschungskontext, kein Betriebswert – und sie bedeutet: Rund drei von zehn Angaben muss ein Mensch nachprüfen. Für das Auffinden der richtigen Zeichnung reicht das; als automatische Quelle für Fertigungsparameter nicht.

Was OCR bei technischen Zeichnungen konkret leistet und wo eine manuelle Freigabe bleiben muss, behandelt Technische Zeichnungen automatisch auslesen: Was OCR kann und wo es aufhört.

In welcher Reihenfolge Sie vorgehen

Die Reihenfolge ist wichtiger als das Werkzeug. Wer mit der Werkzeugauswahl beginnt, bewertet Angebote gegen die Vorführdokumente des Anbieters statt gegen den eigenen Bestand. Die sechs Schritte drehen das um: Erst Bestand verstehen und Erfolg definieren, dann bauen.

1. 01

   Dokumentinventur

   Erfassen, was es gibt: Dokumentklasse, Anzahl, Format, Ablageort, Eigentümer, Revisionsstand, Sprache. Nicht vollständig, aber repräsentativ – die Checkliste unten führt durch die Prüfpunkte.

2. 02

   Qualitätsstichprobe

   20 typische Seiten quer durch die Klassen durch das vorgesehene Parsing schicken und Fehler zählen. Ergebnis: Welche Klassen kommen in den Pilot, welche warten.

3. 03

   Zielfragen sammeln

   Zwei Wochen lang notieren Instandhaltung, Schichtleitung und Arbeitsvorbereitung jede Frage, für die sie in Dokumenten nachschlagen mussten. Das ist die echte Anforderung.

4. 04

   Testfragenkatalog anlegen

   Aus den Zielfragen 30 bis 50 Fragen mit erwarteter Quelle (Dokument, Version, Seite) und erwarteter Antwort. Mindestens fünf ohne Beleg im Bestand – sie prüfen die Verweigerung.

5. 05

   Pilot auf einem Maschinentyp

   Ein Maschinentyp mit vollständiger, aktueller Dokumentation. Nicht der schwierigste Fall, sondern der, an dem sich die Kette von der PDF bis zur belegten Antwort sauber durchmessen lässt.

6. 06

   Abnahme gegen den Katalog

   Jede Testfrage wird bewertet: richtige Quelle, korrekte Antwort, Verweigerung dort, wo sie hingehört. Erst wenn die Quote stimmt, kommen weitere Dokumentklassen und Maschinentypen dazu.

Eine Entscheidung gehört an den Anfang, nicht ans Ende: Wo läuft das System? Lieferantenverträge, Prüfprotokolle mit Namen und Zeichnungen mit Fertigungs-Know-how sind keine Daten, die man beiläufig an einen Dienst außerhalb der EU schickt. EU-Hosting oder Eigenbetrieb ist eine Architekturentscheidung, die Modellwahl, Hardware und Betriebskosten bestimmt. Was der Eigenbetrieb praktisch bedeutet, steht in LLM on premise im Industriebetrieb; welche technischen Anforderungen die Datenschutzaufsicht an RAG-Systeme stellt, in RAG auf eigenen Dokumenten und die DSK-Orientierungshilfe.

Fazit: Dokumentenarbeit vor Modellarbeit

KI für technische Dokumentation ist überwiegend Dokumentenarbeit und erst zum Schluss Modellarbeit. Wer den Bestand inventarisiert, das Parsing an eigenen Seiten misst, entlang der Dokumentstruktur chunkt und Gültigkeit als Metadatum führt, bekommt ein System, dessen Antworten sich prüfen lassen. Wer diese Vorstufe überspringt, bekommt eine flüssige Oberfläche über einem unsortierten Bestand.

Der nächste Schritt ist klein: eine Inventur mit der Checkliste oben, 20 Seiten Stichprobe und 30 Testfragen mit erwarteter Quelle. Damit lässt sich jedes Angebot und jeder Pilot gegen den eigenen Bestand bewerten. Wenn Sie diesen Einstieg mit jemandem durchsprechen möchten, der die Kette von der PDF bis zur belegten Antwort baut, finden Sie die Einordnung von ralwo unter KI-Lösungen für technische Dokumente.