Kundenprofil
Ein Mechanical Engineer bei einem mittelständischen Hersteller von Präzisionskomponenten ist für die GD&T-(geometrische Bemaßung und Tolerierung)-Compliance-Prüfung technischer Zeichnungen verantwortlich, bevor diese zur Fertigung freigegeben werden. Die Rolle umfasst eingehende Lieferantzeichnungen ebenso wie interne Konstruktionsunterlagen: Alles, was in die Fertigung gelangt, muss vor dem Zuschnitt der Teile gegen den geltenden Standard geprüft werden. Baugruppen mit rotierenden Komponenten, Zahnradtrieben und Presssitz-Sleeve-Schnittstellen gehören zu den anspruchsvollsten Prüfobjekten — Maßketten, Koaxialität und Rundlauftoleranzen wirken sich direkt auf Funktion und Lebensdauer aus.
Das Team arbeitet in einer Umgebung mit hoher Variantenvielfalt und geringen Stückzahlen, in der die Zeichnungsqualität je nach Kunde und Lieferant stark variiert. Ein konsistenter, nachvollziehbarer Audit-Prozess — einer, der dokumentierte Ergebnisse mit expliziten Standardverweisen liefert — ist entscheidend, um Prüfentscheidungen in Lieferantenaudits und internen Design-Review-Meetings zu verteidigen. Allgemeine Markierungen auf einer Zeichnung reichen nicht mehr aus; Qualitätsteams erwarten heute, dass jeder Befund an eine konkrete Klausel und ein konkretes Merkmal gebunden ist.
Problem
Zwei strukturelle Probleme machten den bestehenden Prüfprozess schwer skalierbar.
Das erste war der Referenz-Engpass. Der maßgebliche GD&T-Standard des Unternehmens ist ein 411-seitiges technisches Handbuch. Kein Ingenieur kann diese Menge an Spezifikationsdetails während einer laufenden Zeichnungsprüfung im Arbeitsgedächtnis halten. Der herkömmliche Ansatz — das PDF in einem zweiten Fenster offen zu lassen und manuell zu suchen — ist langsam, inkonsistent und erzeugt Audit-Protokolle, die eher auf Einschätzungen als auf standardgestützten Befunden beruhen. Wenn eine Prüfentscheidung eine Lieferanten-Qualitätsdiskussion überstehen muss, hat ein Befund ohne Seitenreferenz wenig Gewicht.
Das zweite Problem war der Zugriff auf strukturierte Daten. Die Zeichnungen kamen als proprietäre DWG-Dateien an. Bevor überhaupt GD&T-Logik angewendet werden konnte, benötigte der Ingenieur eine strukturierte Darstellung des Annotationsinhalts der Zeichnung: Layouts im Papierbereich, Textzeichenfolgen, Maßangaben, Blockeinfügungen und mögliche GD&T-Feature-Control-Frames. Das manuell, Entität für Entität, zu erledigen ist bei komplexen Baugruppen nicht praktikabel. Ohne einen skriptbasierten Extraktionsschritt blieb nur ein visueller Durchgang — der keine Entitätszitate liefern kann, nicht automatisierbar ist und sich bei einer Zeichnungsrevision nicht reproduzieren lässt.
Die geprüfte Zeichnung — eine Stahlspulenbaugruppe aus Zahnrädern und einer Hülse — verdeutlichte beide Probleme gleichzeitig. Sie enthielt erkennbare Fertigungsabsicht, war aber nie nach einem modernen GD&T-Vollständigkeitsstandard geprüft worden. Jede Lücke zu identifizieren, für jede die relevante Handbuchklausel zu zitieren und einen strukturierten Bericht zu erstellen, der mit Korrekturanweisungen an den Ursprung zurückgegeben werden konnte, erforderte einen Workflow, den die vorhandenen Werkzeuge nicht unterstützen konnten.
Warum jetzt
Die Anforderungen an die Lieferantenqualität wurden schrittweise verschärft, und die interne Checkliste des Unternehmens für Design-for-Manufacture-Prüfungen wurde aktualisiert, um für jede rotierende oder passgenaue Baugruppe vor der Freigabe eine explizite GD&T-Abdeckung zu verlangen — Bezugsrahmen, Feature-Control-Frames, Oberflächenangaben und Prüfkriterien für die Abnahme.
Die Stahlspulenzeichnung war ein repräsentativer Fall: brauchbare Geometrie, teilweise Bemaßung und ein Satz Fertigungsnotizen, der Absicht andeutete, ohne die aktualisierte Vollständigkeitsschwelle zu erfüllen. Eine Zeichnung mit einem allgemeinen Befund zurückzugeben, war nicht mehr akzeptabel. Der neue Prozess verlangte aufgelistete Lücken mit Standardverweisen. Das manuell für eine mehrteilige rotierende Baugruppe — Zahnrad, Hülse, Spulenkörper — gegen eine 411-seitige Referenz zu tun, während gleichzeitig eine DWG-zu-strukturierte-Daten-Konvertierung vor der Prüfung stand, hätte pro Zeichnung den Großteil eines Arbeitstags beansprucht. Bei dem Prüfvolumen, das das Team bewältigte, war dieses Tempo nicht tragfähig.
Warum energent.ai
Mehrere Alternativen wurden geprüft, bevor sich das Team für energent.ai entschied.
Ein eigenständiges PDF-Annotationstool konnte Begriffe im Handbuch finden, bot aber keine Möglichkeit, Standardverweise mit bestimmten Zeichnungselementen zu verknüpfen oder einen strukturierten Audit-Bericht zu erzeugen. Eine versionskontrollierte Zeichnungs-Checkliste in einer Tabellenkalkulation sorgte für Konsistenz, erforderte aber weiterhin, dass ein Mensch jede Zeile ausfüllt, indem er Zeichnung und Standard in getrennten Fenstern liest. Einen spezialisierten Zeichner mit der Extraktions- und Cross-Referencing-Arbeit zu beauftragen, hätte Vorlaufzeit und Kosten pro Zeichnung erhöht, ohne die Wiederholbarkeit zu verbessern.
Auch andere KI-Tools wurden evaluiert, aber der Prüf-Workflow erforderte Fähigkeiten, die nur wenige in einer einzigen Sitzung kombinierten: eine binäre CAD-Datei im DWG-Format einlesen, Konvertierungs- und Extraktionsskripte ausführen, strukturierte Ausgaben in CSV und JSON schreiben, ein 411-seitiges technisches PDF laden und verarbeiten, eine abfragbare Referenz über dieses Dokument hinweg ohne Halluzinationsrisiko aufrechterhalten und einen zitierfähigen Engineering-Bericht erzeugen — alles innerhalb einer kohärenten Sitzung und ohne manuelle Übergaben zwischen Umgebungen.
Die Fähigkeit von energent.ai, Python- und Bash-Skripte innerhalb derselben Agentensitzung wie die Dokumentenanalyse auszuführen, war der entscheidende Faktor. Der Agent konnte den DWG-zu-DXF-Konverter ausführen, Extraktionsskripte gegen die Ausgabe laufen lassen, strukturierte Tabellen mit Entitäts- und Raumbezügen erzeugen und diese Tabellen anschließend zusammen mit der Handbuchreferenz nutzen, um einen Bericht zu verfassen, der Zeile für Zeile geprüft werden konnte.
Der Agent ging auch das Halluzinationsrisiko explizit an. Statt zu behaupten, alle 411 Seiten zuverlässig ins Arbeitsgedächtnis geladen zu haben — was der Agent selbst für ein Dokument dieser Länge als unzuverlässig kennzeichnete —, baute er eine externe strukturierte Referenz auf, bestehend aus semantischen Notizen auf Seitenebene, einem Konzeptinventar und einem CSV/JSON-Leselog. Jede Aussage im finalen Bericht ließ sich auf einen Seitenbereich im Quelldokument zurückführen. Diese Prüfbarkeit war eine Anforderung, kein Bonus.
Workflow
Die Sitzung führte eine sechsstufige Pipeline von der Roh-DWG-Datei bis zum finalen Engineering-Report aus.
Schritt 1 — DWG-zu-DXF-Konvertierung. Der Agent führte die CAD-Konvertierungsfunktion auf der Quelldatei aus und erzeugte ein validiertes DXF im AC1027-Format, bestätigt durch eine Integritätsprüfung nach der Konvertierung. Dabei zeigte sich sofort ein entscheidendes strukturelles Detail: Der Annotationsinhalt der Zeichnung befand sich fast vollständig in einem Paper-Space-Layout namens "lito" und nicht im Model Space. Eine naive Extraktion mit Ziel Model Space hätte nahezu leere Tabellen geliefert und den Großteil des für GD&T relevanten Inhalts der Zeichnung verfehlt.
Schritt 2 — Entitätsextraktion in strukturierte Dateien. Ein Extraktionsskript inventarisierte jede Entität im Paper-Space-Layout: Textzeichenfolgen, Bemaßungsannotationen, Blockeinfügungen, Layer und Koordinatenausdehnungen. Die Ausgabe wurde in einer JSON-Extraktionszusammenfassung geschrieben — einer maschinenlesbaren Karte der Zeichnung mit räumlichen Handles, die im nachgelagerten Report referenziert werden konnten.
Schritt 3 — Isolierung von GD&T-Kandidaten. Ein zweites Skript filterte die extrahierten Entitäten nach GD&T-relevantem Inhalt: Toleranzangaben, Bezugskennzeichnungen, Materialbedingungsmodifikatoren und Fertigungsnotizen. Die Ergebnisse wurden in ein strukturiertes CSV mit GD&T-Kandidaten geschrieben, das der Agent während der gesamten Prüfphase abfragte.
Schritt 4 — Aufbau der Handbuch-Referenz. Der Agent verarbeitete das 411-seitige GD&T-Handbuch in drei abrufbare Ebenen: semantische Notizen auf Seitenebene, ein Konzeptinventar und ein CSV/JSON-Leselog. Die Designentscheidung war bewusst getroffen — statt zu versuchen, das gesamte Dokument im Arbeitskontext zu halten, ermöglichte die strukturierte externe Referenz Konzeptabfragen mit Seitenbereichszitaten während der Prüfung. Der Wissensbaum ist über zukünftige Zeichnungsprüfungen hinweg wiederverwendbar, ohne die Indexierungsarbeit zu wiederholen.
Schritt 5 — Querverweisgestützte Engineering-Prüfung. Mit den Zeichnungstabellen und der Handbuch-Referenz verfasste der Agent einen detaillierten Engineering-Report in Markdown. Jeder Befund zitierte einen DXF-Entity-Handle für die Position in der Zeichnung sowie ein Handbuchkonzept mit Seitenbereich als Normgrundlage. Der Report trennte bestätigte gute Praxis von wesentlichen Lücken, listete empfohlene minimale GD&T-Ergänzungen vor der Freigabe auf und kennzeichnete ausdrücklich Klauseln, die von Symbolen oder Prüfdiagrammen abhängen, als visuell gegen die ursprünglichen PDF-Abbildungen zu prüfen.
Schritt 6 — Bereitstellungspaket. Es wurden vier Dateien erzeugt: die konvertierte DXF-Datei, der Engineering-Review-Report in Markdown, die GD&T-Kandidaten-Annotierungstabelle im CSV-Format und die Zeichnungsextraktionszusammenfassung in JSON. Jede Datei erfüllt eine eigene Rolle — die DXF für nachgelagerte CAD-Tools, der Report für die Korrekturanforderung, CSV und JSON als prüfbare Evidenzbasis.
Ergebnisse
Die Engineering-Prüfung identifizierte sechs wesentliche GD&T-Lücken in der Zeichnung der Stahlspulenkörper-Baugruppe:
- Fehlende Angabe des Zeichnungsstandards
- Schwaches oder mehrdeutiges Bezugsreferenzschema
- Fehlende Rundlauf- und Koaxialitätskontrollen für eine rotierende Baugruppe
- Keine Positionstoleranzen für Lochbilder angegeben
- Unzureichend spezifizierte Presspassungs-Schnittstelle
- Anforderungen an die Zahnradprüfung ohne Akzeptanzkriterien aufgeführt
Ein siebter Befund — Anforderungen an die dynamische Auswuchtung ohne Akzeptanzkriterien — ergab sich aus der strukturierten Kandidatentabelle und nicht aus einer rein visuellen Prüfung, was den Wert der Entitätsebene-Extraktion gegenüber einer ausschließlich visuellen Analyse verdeutlicht.
Jede Lücke wurde mit dem relevanten Handbuchkonzept und Seitenbereich verknüpft, sodass der Ingenieur für jede Korrekturanforderung eine dokumentarische Grundlage hatte, statt nur eine Liste unbelegter Meinungen. Der Report zeigte außerdem auf, was die Zeichnung gut machte — bestätigte Praktiken, die keine Überarbeitung benötigten —, sodass die Korrekturanforderung fokussiert und umsetzbar war und nicht einer pauschalen Ablehnung gleichkam.
Auf der Referenzseite wurde das 411-seitige Handbuch in einen persistenten, abfragbaren Wissensbaum überführt. Statt eines statischen PDFs, das für jede neue Zeichnung manuell durchsucht werden muss, verfügt das Team nun über eine strukturierte CSV/JSON-Referenz, die der Agent für jede nachfolgende Prüfung nach Konzepten abfragen kann. Die Extraktions- und Prüf-Pipeline — vom DWG-Eingang bis zum strukturierten Report — ist auf jeder eingehenden Zeichnung wiederholbar und kann bei Zeichnungsrevisionen erneut ausgeführt werden.
Nachweis
"Was ich nicht erwartet hatte, war die Qualität der Zitate. Jeder Punkt im Report hatte einen DXF-Handle, der auf die exakte Annotation in der Zeichnung verwies, und einen Handbuch-Seitenbereich, der die Anforderung stützte. Das ist nichts, was ich in einer einzigen manuellen Prüfsitzung erzeugen könnte — alles per Hand zu verknüpfen würde den Großteil eines Tages dauern." — Maschinenbauingenieur, Präzisionskomponentenfertigung
Das finale Lieferpaket des Agenten umfasste einen vollständigen Engineering-Review-Report, gegliedert in bestätigte gute Praxis, wesentliche Lücken, Zeichnungspositionsreferenzen über Entity-Handles, Zitate zu Handbuchkonzepten und Seitenbereichen sowie empfohlene minimale Ergänzungen vor der Freigabe. Das GD&T-Kandidaten-CSV diente als nachvollziehbares Annotationsinventar, das jeden Befund untermauerte.
Vertrauenshinweis
Der Agent macht eine wichtige Grenze ausdrücklich: Befunde, die von GD&T-Symbolen, Toleranzrahmendiagrammen oder Illustrationen zur Prüfaufstellung abhängen, erfordern eine visuelle Prüfung anhand der ursprünglichen PDF-Abbildungen. Das Leselog und das Konzeptinventar ermöglichen eine fundierte Argumentation zu GD&T-Anforderungen, ersetzen jedoch nicht die menschliche Prüfung von in Abbildungen abhängigen Inhalten. Engineering-Reports aus diesem Workflow sollten als Erstprüfung mit vollständiger Dokumentennachverfolgbarkeit behandelt werden — nicht als endgültige Freigabe. Ein qualifizierter GD&T-Praktiker sollte symbolabhängige Befunde bestätigen, bevor die Zeichnung an den Urheber zurückgegeben oder für die Fertigung freigegeben wird.