Jenseits manueller RFQ-Datenextraktion: Praktische Alternativen (und warum generische LLMs bei technischen Zeichnungen noch versagen)

· Written by Jochen Mattes

Verfügbar in:

RFQ-Workflows scheitern immer noch an derselben Stelle: Jemand öffnet eine technische Zeichnung, blinzelt bei Beschriftungen, rät die Einheiten, interpretiert Abkürzungen und tippt manuell strukturierte Daten in ein Angebotsdatenblatt, ERP oder Kalkulationstool. Es ist langsam, inkonsistent und schwer skalierbar – besonders wenn Zeichnungen von verschiedenen Lieferanten, Ländern und Disziplinen stammen.

Die gute Nachricht: Es gibt echte Alternativen zur manuellen Extraktion. Die schlechte Nachricht: Viele "KI"-Ansätze versagen aus vorhersagbaren Gründen – besonders wenn sie auf generische OCR und allgemeine LLMs setzen.

Dieser Artikel skizziert die wichtigsten Ansätze, die Sie heute verwenden können, wofür sie gut sind, wo sie versagen und wie Sie eine Extraktionsstrategie wählen, die tatsächlich bei realen Zeichnungen funktioniert.

Die Alternativen zur manuellen Extraktion (und ihre Kompromisse)

1) Manuell bleiben, aber den Prozess standardisieren

Was es ist: Menschliche Extraktion mit Checklisten, Vorlagen und Schulungen.

Warum Teams das machen: Es ist flexibel und bewältigt Grenzfälle.

Wo es scheitert:

  • Skaliert nicht mit dem RFQ-Volumen
  • Teuer und schwer zu besetzen
  • Qualität hängt von Einzelpersonen ab
  • Keine konsistente Nachverfolgbarkeit zwischen Prüfern

Manuelle Arbeit kann "optimiert" werden, aber sie wird selten zu einem Wettbewerbsvorteil.

2) Generische OCR + Regeln/Regex + Tabellen

Was es ist: OCR auf PDF/TIFF ausführen, dann den resultierenden Text mit Regeln (Regex, Schlüsselwort-Wörterbücher, Heuristiken) parsen.

Wo es funktioniert:

  • Saubere Schriftfelder
  • Konsistente Schriften/Ausrichtung
  • Enge Zeichnungsfamilien mit strengen Konventionen

Wo es in der Produktion scheitert:

  • Rotations- und Orientierungsprobleme: gedrehte Notizen, schräge Beschriftungen, gespiegelte Scans, gemischte Orientierungen über Ansichtsfenster hinweg
  • Symbole und technische Notation: Durchmessersymbole, Oberflächenfinish, GD&T-Rahmen, gestapelte Toleranzen
  • Brüchigkeit: Ein Lieferant ändert das Layout, und Ihr Regelsatz bricht zusammen
  • Mehrdeutigkeit: Regeln haben Schwierigkeiten, Bedeutung zu "entscheiden", wenn dasselbe Token verschiedene Dinge bedeuten kann

Dieser Ansatz kann schnelle Erfolge liefern, aber er wird tendenziell zu einem wachsenden Haufen von Ausnahmen.

3) CAD/PLM-gesteuerte Extraktion (BOM, PMI, modellbasierte Definition)

Was es ist: Zeichnungen vermeiden und aus nativem CAD, PMI, BOMs und strukturierten PLM-Objekten extrahieren.

Wo es funktioniert:

  • Interne Fertigung mit moderner CAD-Governance
  • Geschlossene Engineering-Umgebungen
  • Organisationen, die tatsächlich die maßgeblichen Quelldateien haben

Wo es scheitert:

  • RFQs kommen oft nur als PDF/TIFF
  • Lieferanten und Kunden teilen natives CAD nicht konsistent
  • Legacy-Zeichnungen und gescannte Archive werden nicht abgedeckt
  • MBD-Adoption ist uneinheitlich über Branchen hinweg

Wenn Sie zu strukturiertem CAD/PLM wechseln können – großartig. Aber die meiste RFQ-Realität läuft immer noch über Zeichnungen.

4) Multimodale LLMs für Zeichnungsextraktion

Was es ist: Das Zeichnungsbild/PDF an ein vision-fähiges LLM weiterleiten und nach strukturierter Ausgabe fragen.

Warum es attraktiv aussieht:

  • Minimaler Setup
  • Behandelt viele Formate
  • "Versteht" Kontext besser als reines Regex – manchmal

Die zwei großen Probleme (in der Praxis):

Problem A: OCR ist immer noch der Engpass (besonders bei Rotation)

Die meisten LLM-basierten Extraktions-Pipelines hängen immer noch von OCR unter der Haube ab. Bei echten Zeichnungen haben Sie:

  • gedrehte Anmerkungen (90°-Schriftfelder, schräge Notizen, gedrehte Ansichtsbeschriftungen)
  • gemischte Orientierungen auf demselben Blatt
  • Stempel, Scan-Schräglage, schwacher Text, niedrige DPI
  • beengte Beschriftungen nahe der Geometrie

Wenn OCR den Text übersieht oder verfälscht, kann das LLM nicht zuverlässig wiederherstellen. Sie erhalten stille Auslassungen ("es hat die Hälfte des Schriftfelds nicht extrahiert") oder selbstbewusste, aber falsche Vermutungen.

Problem B: Domänen-Mehrdeutigkeit ist kein "Sprachproblem" – es ist ein Kontextproblem

Technische Zeichnungsabkürzungen sind nicht universell. Dasselbe Token kann verschiedene Dinge bedeuten, abhängig von Domäne, Region und Zeichnungskonventionen.

Beispiele:

  • "C45": wird von vielen Ingenieuren häufig als Stahlgüte interpretiert, aber in anderen Kontexten kann es eine Fase (Länge + Winkel) bezeichnen, abhängig von Notationsstil und lokaler Praxis.
  • "SM2": in einem optischen/mechanisch-optischen Kontext kann es einen Gewindestandard bezeichnen (z.B. SM-Serie Objektivtubus-Gewinde). In anderen Kontexten (und in einigen regionalen Abkürzungen) kann dasselbe Muster als Fasendefinition (Länge, Winkel) interpretiert werden.
  • Oberflächenrauheit (Ra) und Einheiten: US- vs EU-Zeichnungen können Rauheitserwartungen unterschiedlich darstellen, und Schriftfelder machen Einheiten oft nicht explizit. Wenn die Zeichnung Einheiten nicht klar definiert, muss Ihr System ableiten oder zumindest Mehrdeutigkeit kennzeichnen.

Generische LLMs neigen dazu, "alles auf einmal zu lösen", aber ohne tiefe, explizite Domänenmodelle können sie nicht konsistent die Freiheit des Zeichners (die kreative Abkürzung und lokale Konventionen) entfernen und in deterministische, prüfbare Struktur umwandeln.

Wie ein produktionstauglicher Ansatz aussieht: Extraktion + Normalisierung + Interpretation

Wenn Sie möchten, dass RFQ-Extraktion im großen Maßstab funktioniert, benötigen Sie typischerweise eine Pipeline, die drei Dinge gut macht:

  1. Die Zeichnung zuverlässig lesen Robuste OCR und Symbolbehandlung über Rotationen, Scan-Artefakte und Multi-Orientierungs-Blätter hinweg.

  2. Die Freiheit des Zeichners normalisieren Viele Notationen in eine kanonische Darstellung abbilden (so wie Menschen es tun, aber konsistent).

  3. Im Kontext interpretieren Entscheiden, was ein Token bedeutet, basierend auf der Domäne, Herkunft, Standards und umgebenden Hinweisen der Zeichnung – und kennzeichnen, wenn das System nicht sicher sein kann.

Genau hier übertreffen domänenspezifische Systeme allgemeine LLM-Ansätze.

Wie sich Werk24 anders als "Nur-LLM-Extraktion" positioniert

Werk24 konzentriert sich seit Jahren auf das Verständnis technischer Zeichnungen, speziell um die beiden größten Fehlermodi oben zu beseitigen.

1) Rotation ist kein Sonderfall

Werk24s Extraktions-Pipeline ist darauf ausgelegt, Rotation und gemischte Orientierungsinhalte als erstklassige Anforderung zu behandeln. Gedrehter Text, schräge Beschriftungen und häufige Scan-Realitäten werden als normale Eingabe behandelt – nicht als Ausnahmen.

Ergebnis: Sie verlieren nicht die Hälfte des Schriftfelds, weil es gedreht ist, und Sie brauchen keine "perfekte PDF"-Richtlinie, um konsistente Ausgabe zu erhalten.

2) Domänenwissen ist in die Interpretationsschicht eingebaut

Werk24 ist darauf ausgelegt, Zeichnungsnotation zu entmehrdeutigen, indem domänenbewusster Kontext angewendet wird – weil derselbe String legitimerweise verschiedene Dinge bedeuten kann.

In der Praxis umfasst dies:

  • erkennen, ob eine Zeichnung optisch vs mechanisch ist (und welche Konventionen folgen)
  • Abkürzungen basierend auf dieser Klassifikation unterschiedlich interpretieren
  • regionale Konventionen handhaben (z.B. US vs EU Gewohnheiten, Standards-Einfluss)
  • fehlende Einheiten ableiten oder kennzeichnen (anstatt stillschweigend zu raten)
  • strukturierte Ausgaben produzieren, die über Lieferanten hinweg konsistent bleiben

Das Ziel ist nicht nur "Text extrahieren", sondern verwendbare RFQ-Daten zu liefern: Abmessungen, Toleranzen, Materialien, Oberflächenanforderungen, Gewinde und Metadaten – interpretiert so, wie ein erfahrener Prüfer sie interpretieren würde, aber mit Wiederholbarkeit und Nachverfolgbarkeit.

Eine pragmatische Checkliste für die Wahl eines Extraktionsansatzes

Bei der Bewertung von Alternativen (OCR+Regeln, LLMs, Domänenplattformen) stellen Sie diese Fragen:

  • Rotation & Orientierung: Behandelt es gedrehten/gemischten Text zuverlässig, oder brauchen Sie "saubere PDFs"?
  • Symbol- & Notationsunterstützung: Durchmesser, GD&T-Rahmen, gestapelte Toleranzen, Oberflächenfinish, Gewinde – nativ behandelt?
  • Mehrdeutigkeitsbehandlung: Entscheidet und erklärt es, oder rät es stillschweigend?
  • Kontextklassifikation: Erkennt es Zeichnungsdomäne und Standards-Einfluss (ISO/ASME, optisch/mechanisch)?
  • Einheiten & fehlende Schriftfeld-Info: Leitet es fehlende Einheiten und regionale Unterschiede ab/kennzeichnet sie?
  • Prüfbarkeit: Können Sie extrahierte Felder zu Zeichnungsregionen und Vertrauen zurückverfolgen?
  • Mensch-in-der-Schleife: Können Prüfer effizient verifizieren/überschreiben, wenn nötig?
  • Integration: API-first? Export-Formate? Passt in RFQ/Kalkulations/ERP-Workflows?
  • Konsistenz im großen Maßstab: Verschlechtert sich die Leistung, wenn Lieferanten variieren?

Wo LLMs immer noch helfen (wenn richtig verwendet)

LLMs können an den Rändern wertvoll sein:

  • RFQ-Pakete zusammenfassen
  • Lieferantenfragen entwerfen ("bitte Oberflächenfinish-Einheiten bestätigen")
  • ähnliche historische Teile abgleichen nachdem Sie vertrauenswürdige strukturierte Daten haben
  • Notizen übersetzen (mit sorgfältiger Validierung)

Aber der Kern-Extraktionsschritt – besonders von unordentlichen Zeichnungen – braucht Zuverlässigkeit, Normalisierung und Domäneninterpretation. Das ist nicht, wo generische LLMs heute glänzen.

Fazit

Wenn Ihr RFQ-Prozess von technischen Zeichnungen abhängt, ist die größte Freischaltung nicht "KI, die Bilder lesen kann". Es ist ein System, das:

  • Zeichnungen robust lesen kann (einschließlich Rotation),
  • Notationsvariabilität entfernen,
  • und Bedeutung im Kontext interpretieren kann – konsistent.

Diese Kombination ist es, was Zeichnungen in strukturierte RFQ-Eingaben verwandelt, denen Sie vertrauen, die Sie automatisieren und skalieren können. Werk24 ist speziell dafür gebaut.