Eine technische Zeichnung enthält weit mehr als nur ein Bild eines Bauteils. Sie beschreibt Maße, Toleranzen, Bohrungen, Gewinde, Oberflächenbeschaffenheit und Fertigungsanweisungen. Um diese Informationen in verwertbare Daten umzuwandeln, müssen kleine Markierungen gefunden, korrekt gelesen und ihre Position auf der Seite beibehalten werden.
Diese letzte Anforderung ist entscheidend. Ein System könnte beispielsweise Folgendes: 50 ± 0,2 korrekt auslesen, aber einem falschen Element zuweisen. Bei Software, die Konstruktions- oder Angebotsablaufprozesse unterstützt, reicht die Zahl allein nicht aus.
Drawing2Data-Bench ist das Toolkit von COGITA zur Entwicklung und Bewertung von KI für dieses Problem. Es verbindet drei Teile der Arbeit miteinander: die Erstellung beschrifteter Zeichnungen aus CAD‑Dateien, das Testen von Bild-Sprache-Modellen und das Trainieren eines speziellen Detektors.
Die dokumentierten Experimente zeigen ein aufschlussreiches Muster: Allzweckmodelle können zwar einen Großteil des Textes erkennen, doch die präzise Lokalisierung bleibt schwierig. Ein spezieller RF‑DETR‑Detektor erzielt in dem vorgestellten Vergleich die höchste Box-Präzision, während Gemini 3.5 Flash den höchsten Box-F1‑Wert erreicht. Das Verständnis dieses Unterschieds hilft zu erklären, warum das Toolkit alle drei Komponenten enthält.
Was das Repository enthält
| Komponente | Was es bewirkt | Warum das wichtig ist |
|---|---|---|
Generation/ | Wandelt 3D‑CAD‑Modelle in 2D‑Zeichnungen und zugehörige Beschriftungen um. | Erstellt Trainingsbeispiele, ohne dass jede Annotation manuell markiert werden muss. |
Benchmarks/ | Führt Modelle auf Zeichnungen aus und wertet deren strukturierte Vorhersagen aus. | Trennt die Qualität der Textextraktion von der Fähigkeit, Annotationen zu finden. |
Extraktion/ | Trainiert und wendet den RF‑DETR‑Large-Detektor an. | Bietet ein spezielles Modell zum Auffinden von Annotationsbereichen. |
Der Arbeitsablauf beginnt mit einem CAD‑Modell. Der Generator erzeugt ein Bild und die dazugehörigen Referenzbeschriftungen. Diese Paare können dann sowohl zum Trainieren eines Detektors als auch zum Bewerten von Modellen anhand bekannter Antworten verwendet werden. Die Beschreibung jeder Komponente befindet sich in der Repository-Übersicht.
1. Beschriftete 2D‑Zeichnungen aus 3D‑CAD‑Daten generieren
Um ein Bildmodell zu trainieren, benötigt man Beispiele dafür, was es erkennen soll. Bei einer technischen Zeichnung könnte das beispielsweise ein Rechteck um eine Bemaßung, eine Beschriftung, die angibt, um welche Art von Bemaßung es sich handelt, sowie den darin enthaltenen Text sein.
Das Erstellen dieser Beschriftungen von Hand ist zeitaufwendig. Eine einzige Seite kann Dutzende kleiner Annotationen enthalten, und die Person, die die Beschriftungen anbringt, muss sich mit der technischen Notation auskennen.
Der Generator des Repositorys, AutoDraft, erstellt die Zeichnung und die dazugehörigen Beschriftungen gemeinsam. Es akzeptiert STEP, IGES und BREP Dateien, in denen 3D‑CAD‑Geometrie gespeichert ist. Anhand dieser Geometrie wählt das Programm Ansichten aus, zeichnet das Bauteil, fügt Bemaßungen und Beschriftungen hinzu und ordnet diese auf einem Blatt an. Das Ergebnis ist ein PNG‑Bild und COCO‑Annotationen. COCO ist ein gängiges Datensatzformat, das Objekte, deren Kategorien und deren Positionen in einem Bild erfasst.
Eine generierte Zeichnung mit ihren Referenzbeschriftungen. Die roten Boxen stammen aus den Datensätzen von Annotationen des Generators; sie stellen die Antworten dar, die ein Detektor lernen soll.
AutoDraft unterstützt 12 Annotationskategorien, darunter Bemaßungen, Radien, Fasen, Bohrungen, Gewinde, Symbole für Oberflächenbeschaffenheit, Anmerkungen, Tabellen und Ansichtsbeschriftungen. Außerdem umfasst es GD&T, oder geometrische Bemaßung und Tolerierung, sowie Bezugselemente (Datums) Datumsangaben, die Referenzmerkmale, anhand derer Maße und Toleranzen festgelegt werden.
Eine Annotation umfasst ihre Kategorie, ihren Text und ihren Begrenzungsrahmen. In zusätzlichen Feldern werden Informationen wie der Messwert, die Ansicht und die Angabe, ob eine Bemaßung künstlich erzeugt wurde, gespeichert. Bei den meisten Rahmen steht die Annotation selbst im Mittelpunkt und nicht die Längsmaßangabe oder die Führungslinie um sie herum. Eine Tabelle wird durch einen Rahmen dargestellt, der den gesamten Block umgibt.
Abwechslung hilft einem Modell, mehr als nur ein Layout zu lernen
AutoDraft bietet zehn Zeichnungsstile mit unterschiedlichen Blattlayouts, Pfeilspitzen, Textplatzierungen, Toleranzen und Titelblöcken. Das Programm kann Schnittansichten erstellen, die innere Merkmale sichtbar machen, sowie vergrößerte Detailansichten und separate Ansichten von Körpern in einer Baugruppe. Auch die Darstellungsdetails variieren innerhalb eines Stils.
Dies ist von Bedeutung, da ein Modell, das anhand eines festen Layouts trainiert wurde, möglicherweise nur lernt, wo Beschriftungen üblicherweise erscheinen, anstatt sie zu erkennen. Eine größere Bandbreite an Layouts bietet Entwicklern eine bessere Ausgangsbasis für das Training von Modellen, die 2D‑Zeichnungen verarbeiten.
Da die Beschriftungen Text enthalten, könnten die generierten Daten auch für zukünftige OCR- oder Vision-Language-Fine-Tuning-Prozesse genutzt werden. Der derzeit in diesem Repository bereitgestellte Trainingscode konzentriert sich auf die Objekterkennung.
Es gibt einen wichtigen Unterschied zu beachten: Einige Spezifikationen sind synthetisch. Werte für die Oberflächenbeschaffenheit werden generiert, und bestimmte andere Annotationen können ebenfalls generiert werden, wenn die CAD‑Datei keine eingebetteten Fertigungsinformationen enthält. Diese Elemente werden gekennzeichnet. Sie können einem Modell zwar vermitteln, wie ein Symbol oder eine Beschriftung aussieht, doch sollten ihre fiktiven Werte nicht als echte Anforderungen an das Originalbauteil behandelt werden. Siehe die Dokumentation zur Generierung zu den unterstützten Konventionen und Einschränkungen.
2. Messen, was Gemini und GPT tatsächlich extrahieren
Ein Vision-Language-Modell, auch bekannt als VLM, akzeptiert sowohl Bilder als auch Text. Drawing2Data-Bench enthält neben dem lokalen Detektor auch Adapter für Gemini- und GPT‑Modelle über OpenRouter.
Der Benchmark fordert jedes VLM auf, strukturierte Merkmale zurückzugeben: den Text der Annotation, die Kategorie, den Begrenzungsrahmen und den Konfidenzwert. Die Vorhersagen werden als JSON gespeichert und anschließend mit den Referenzlabels verglichen. Über eine YAML‑Konfiguration werden der Datensatz, die Modelle, die Metriken und die Anzahl der Beispiele ausgewählt.
Dadurch lassen sich drei separate Fragen stellen:
- Hat das Modell die Annotation gefunden? Die vorhergesagte Box muss sich ausreichend mit der Referenzbox überschneiden.
- Hat das System die Annotation korrekt gelesen und klassifiziert? Der Text und die Kategorie müssen übereinstimmen.
- Hat es beides am selben Ort gemacht? Der Text, die Kategorie und die Position müssen alle korrekt sein.
Für das Box-Matching verwendet der Benchmark Intersection over Union, oder IoU: die gemeinsame Fläche zweier Rechtecke, geteilt durch die von ihnen insgesamt abgedeckte Fläche. Für eine Übereinstimmung ist ein IoU‑Wert von über 0,5 erforderlich. Dadurch ist die Bewertung strenger als die einfache Überprüfung, ob sich ein Rechteck in der Nähe der richtigen Zahl befindet.
Der dargestellte Vergleich
In der Benchmark-Dokumentation wird ein Lauf mit dem Namen benchmark_15, unter Verwendung von 15 generierten Zeichnungen. Die folgende Tabelle gibt die Lokalisierungsergebnisse wieder. Alle drei Werte sind umso besser, je höher sie sind.
| Modell | Box-Genauigkeit | Box-Trefferquote (Recall) | Box F1 |
|---|---|---|---|
Lokaler RF‑DETR‑Detektor (benutzerdefiniert) | 0.9777 | 0.6050 | 0.7474 |
| Gemini 3.1 Flash Lite | 0.6525 | 0.6381 | 0.6453 |
| Gemini 3.5 Flash | 0.7762 | 0.7569 | 0.7664 |
| GPT-5.6 Luna* | 0.2066 | 0.2029 | 0.2047 |
| GPT-5.6 Terra | 0.5363 | 0.3674 | 0.4361 |
| GPT-5.6 Sol | 0.5430 | 0.5580 | 0.5504 |
Quelle: dokumentierte Benchmark-Ergebnisse. Lunas Ergebnisse umfassen 14 Ausgaben, da eine Antwort die maximale Ausgabelänge überschritten hat. Die Modellnamen sind dem Repository zu entnehmen.
Präzision gibt an, wie hoch der Anteil der vorhergesagten Boxen ist, die mit den Referenzannotationen übereinstimmen. Rückruf gibt an, wie viel vom Referenz-Annotationsbestand gefunden wurde. F1 kombiniert beides, sodass ein Modell keinen hohen F1‑Wert erzielen kann, indem es lediglich einige wenige, sehr genaue Boxen zurückgibt.
Die Präzision des lokalen Detektors von 97.77% ist höher als die jedes VLM in diesem Durchlauf. 60.50%Die Trefferquote (Recall) von 60.50% zeigt jedoch, dass dabei immer noch viele Annotationen übersehen werden. Gemini 3.5 Flash findet mehr davon und erzielt das beste Gleichgewicht zwischen Präzision und Recall.
Diese Boxscores ignorieren Text und Kategorie. Ein korrekt lokalisiertes Rechteck kann als Treffer gewertet werden, selbst wenn sein Text leer ist oder seine Klasse falsch ist.
Das Lesen des Textes ist nur ein Teil des Problems
Die Merkmalsmetriken ergänzen die Bewertung um Text und Kategorie. In der ersten Spalte unten wird die Position nicht berücksichtigt; in der zweiten muss die Annotation zudem an der richtigen Stelle stehen.
| VLM | Genauer Text + Kategorie F1 | Genauer Text + Kategorie + Ort F1 |
|---|---|---|
| Gemini 3.1 Flash Lite | 0.8352 | 0.5922 |
| Gemini 3.5 Flash | 0.8615 | 0.6797 |
| GPT-5.6 Luna* | 0.8279 | 0.1869 |
| GPT-5.6 Terra | 0.7246 | 0.4033 |
| GPT-5.6 Sol | 0.8529 | 0.5041 |
Quelle: dieselbe Benchmark-Ergebnisse, mit derselben Ausnahme für Luna, die 14 Ausgänge umfasst. Beim exakten Abgleich werden der gespeicherte Text und die Kategorie miteinander verglichen. Tabellenfunktionen verwenden Bezeichnungen wie TITELBLOCK; bei diesem Durchlauf wird nicht die Transkription jeder einzelnen Tabellenzelle ausgewertet.
Jedes Modell verliert an Boden, sobald der Standort zu einem Anforderungskriterium wird. Bei Gemini 3.5 Flash sinkt die Punktzahl von 0,8615 bis 0,6797. Bei GPT-5.6 Sol sinkt er von 0,8529 bis 0,5041.
Diese Lücke ist für Entwickler die wertvollste Erkenntnis. Ein Modell kann zwar viele korrekte Beschriftungen zurückgeben, ohne diese jedoch zuverlässig auf der Zeichnung zu platzieren. Eine überzeugende Textantwort belegt daher nicht, dass die Zeichnung korrekt extrahiert wurde. Selbst eine korrekte Lokalisierung der Beschriftungen ist nur ein Schritt auf dem Weg, jede Beschriftung mit dem physischen Merkmal zu verknüpfen, das sie beschreibt.
Der Vergleich von sechs Modellen in einer Zeichnung aus dem Repository. Es handelt sich hierbei um Modellvorhersagen, nicht um Referenzrahmen. Die Abbildungen veranschaulichen Unterschiede hinsichtlich der Abdeckung und der Platzierung; die Tabellen oben fassen den berichteten Durchlauf zusammen.
3. Einen spezialisierten RF‑DETR‑Detektor trainieren
Die Extraktionskomponente verwendet RF‑DETR Large, einen Objektdetektor, der darauf trainiert wurde, Annotationsbereiche zu finden und zu klassifizieren.
Seine Aufgabe besteht darin, Rahmen um Objekte wie Bemaßungen, Anmerkungen und Tabellen zu erstellen. Es gibt ihren Text nicht wieder. Der Benchmark-Adapter gibt für jede Erkennung ein leeres Textfeld zurück, was die Nullwerte des Detektors bei den ausgewiesenen Textmetriken erklärt.
In der Dokumentation zur Datenextraktion wird ein generierter Datensatz beschrieben, der aus 9.378 Bilder und 228.327 Annotationen, aufgeteilt wie folgt:
| Split | Bilder | Annotationen |
|---|---|---|
| Training | 6,513 | 158,727 |
| Validierung | 1,886 | 45,942 |
| Test | 979 | 23,658 |
Trainingsbeispiele dienen dem Training des Modells; Validierungsbeispiele dienen der Überwachung seines Fortschritts; Testbeispiele werden zur Bewertung beiseite gelegt. Diese Datensatzzahlen beschreiben die dokumentierte Trainingsarbeit, während der obige VLM‑Vergleich die separate Benchmark-Konfiguration mit 15 Stichproben verwendet.
Der beschriebene Trainingslauf umfasste 20 Epochen, d. h. 20 Durchläufe durch die Trainingsdaten. Das Trainingsskript wendet zudem Transformationen wie Rotation, perspektivische Verzerrung, Unschärfe, Rauschen und Komprimierung an, um den Detektor mit weniger makellosen Bildern zu konfrontieren.
Die mit dem Repository bereitgestellten, aufgezeichneten Trainingskurven. Die Erkennungswerte verbessern sich im Laufe des Durchlaufs, während die Trainings- und Validierungsfehler im Allgemeinen abnehmen.
Die Dokumentation berichtet einen abschließenden Validierungswert von 0,9352 für mAP@50 und 0,7245 für mAP@50:95 bei den gemittelten Modellgewichten. Hierbei handelt es sich um Objekt-Erkennungswerte: Der zweite bewertet die Übereinstimmung von Rahmen unter einer Reihe von zunehmend strengeren Überlappungsanforderungen. Sie stammen aus einem anderen Bewertungsaufbau und sollten getrennt von den F1‑Werten des kleinen Benchmarks betrachtet werden. Die Dokumentation zur Extraktion bietet die vollständigen Trainingsdaten sowie die Ergebnisse pro Kurs.
Das Beispiel zur eigenständigen Inferenz enthält 14 Erkennungen bei einem Konfidenzschwellenwert von 0,5. Es zeigt die erkannten Bereiche ohne OCR‑Transkription. Es handelt sich um ein eigenständiges Beispiel, das nicht Teil des oben genannten Vergleichs der sechs Modelle ist.
Im vorgestellten Benchmark übertrifft der Detektor vier der fünf VLMs bei Box F1 und alle fünf bei der Box-Präzision. Dies untermauert einen praktischen Ansatz für die weitere Arbeit: Verwenden Sie ein spezialisiertes Modell, um vielversprechende Bereiche zu identifizieren, und leiten Sie diese Ausschnitte anschließend zur Erkennung an ein OCR‑System oder ein VLM weiter. Das Repository stellt den Detektor und die Auswertungswerkzeuge bereit; diese kombinierte Erkennungs-Pipeline bleibt ein nächster Schritt.
So können Sie das Toolkit ausprobieren
Klonen Sie zunächst das Repository und installieren Sie dessen Abhängigkeiten:
git clone https://github.com/COGITA‑AI/drawing2data-bench.git
cd drawing2data-bench
python -m pip install -r requirements.txtErstellen Sie einen kleinen Datensatz anhand der mitgelieferten CAD‑Beispiele:
python -m generation.cli "generation/examples/models/*.step" -o datasetÜberprüfen Sie die generierten Labels vor dem Training:
python -m generation.tools.coco_view dataset/trainSofern ein geeigneter Datensatz und eine CUDA‑GPU zur Verfügung stehen, lautet der Einstiegspunkt für das Training:
python -m extraction.train \
--dataset-dir ./dataset \
--epochs 20 \
--batch-size 8 \
--grad-accum-steps 2Das mitgelieferte Trainingsskript wählt CUDA direkt aus. Die wenigen enthaltenen CAD‑Beispiele sind hilfreich, um den Generator kennenzulernen; zur Reproduktion der dokumentierten Trainingsergebnisse sind der größere Datensatz und die entsprechende Konfiguration erforderlich.
Für die VLM‑Auswertung erläutert der Benchmark-Leitfaden die Konfiguration und die Einstellung von OPENROUTER_API_KEY . Benchmark-Befehle werden ausgeführt von Benchmarks/. Der generierte Benchmark-Datensatz hat einen eigenen erwarteten Speicherort, benchmarks/datasets/generated/data/; die bloße Erstellung des Trainingsdatensatzes führt noch nicht dazu, dass dieser mit Daten gefüllt wird.
Das Repository enthält einen Link zu einem einem gemeinsamen Artefaktordner für größere Dateien. Das überprüfte Git-Checkout enthält den Quellcode, Beispiel-CAD‑Dateien, Dokumentation und Abbildungen, jedoch nicht den vollständigen Trainingsdatensatz, Checkpoints oder Rohdaten benchmark_15 Ausgaben.
Was diese Ergebnisse belegen
Drawing2Data-Bench bietet einen konkreten Ausgangspunkt für die Generierung von Trainingsdaten und die Bewertung spezifischer Aufgaben zum Verständnis von Zeichnungen. Die vorgestellten Ergebnisse zeigen, warum Textqualität, Lokalisierungsgenauigkeit und Annotationsabdeckung separat bewertet werden müssen.
Die derzeitigen Erkenntnisse weisen zudem deutliche Grenzen auf. Der Vergleich basiert auf einer kleinen synthetischen Stichprobe, und laut Dokumentation lässt sich der Detektor nur in geringem Maße auf echte gedruckte Zeichnungen übertragen. Alle VLMs verwenden eine gemeinsame Eingabeaufforderung und Koordinatenkonvention, sodass es sich um einen Vergleich unter diesen Rahmenbedingungen handelt. Unterschiedliche Eingabeaufforderungen oder Vorverarbeitungsschritte könnten die Rangfolge verändern. Die Zahlen in diesem Artikel geben die im Repository dokumentierten Experimente wieder; sie wurden für diesen Artikel nicht unabhängig neu durchgeführt. Eine neue Reproduktion sollte zudem die Koordinatenskalierung und die Kategorizierung in den aktuellen Adaptern überprüfen.
Für Teams, die technische Software entwickeln, macht das Toolkit die nächsten Experimente greifbar: Beispiele generieren, die Beschriftungen überprüfen, Modelle anhand repräsentativer Zeichnungen vergleichen und messen, welche Verbesserungen sich ergeben, wenn Erkennung und Textlesung kombiniert werden.
Entdecken Sie den Code und die Dokumentation im „Drawing2Data-Bench“-Repository von COGITA.
