BenchCAD: Was die Rekonstruktion eines ausführbaren mechanischen Bauteils zeigt – und was sie über Industriedesign nicht beweist

Welches Problem BenchCAD isoliert

Ein KI-System für die physische Produktentwicklung kann ein plausibles Bild eines Bauteils erzeugen und dennoch kein für die Konstruktion brauchbares Artefakt liefern. Um ein Modell zu ändern, zu prüfen oder in einem parametrischen Workflow wiederzuverwenden, braucht es eine ausführbare Darstellung: Operationen, Maße, Beziehungen und Logik, die eine Geometrie erzeugen. BenchCAD konzentriert sich auf die Lücke zwischen einer annähernd richtigen äußeren Erscheinung und einem parametrischen CAD-Programm, das tatsächlich ausgeführt werden kann.

BenchCAD 1.0 verwendet CadQuery als Umgebung für programmatisches CAD. Die praktische Bewertungseinheit verbindet – je nach Aufgabe – Renderings eines Bauteils, ein Ausgangsprogramm, eine Änderungsanweisung, ein CadQuery-Referenzprogramm und einen STEP-Referenzkörper. Das Modell muss Code, eine Codeänderung oder eine numerische Antwort liefern. Anschließend führt der Evaluator die Ausgabe aus und vergleicht entweder die erzeugte Geometrie oder die Antwort mit der Referenz.

Dieses Design hat eine wichtige Konsequenz: Das Benchmark benötigt kein weiteres Sprachmodell, das beurteilt, ob ein Bauteil „richtig aussieht“. Das geometrische Signal entsteht aus einer Ausführung und einem berechenbaren Vergleich mit dem Referenzkörper. Das reduziert die Subjektivität einer rein auf generativen Juroren beruhenden Bewertung. Methodische Entscheidungen verschwinden dadurch jedoch nicht: Welche Bauteile enthalten sind, wie Geometrie diskretisiert wird, welche Umgebung festgelegt ist und was als gültige Ausgabe gilt.

Das BenchCAD-Repository nennt vier Aufgaben und eine Sammlung mit 17.900 Programmen, 106 Familien, 748 Bearbeitungen und 2.400 Fragen zu 200 Bauteilen. Diese Zahlen beschreiben die veröffentlichte Zusammensetzung der Ressource. Sie belegen für sich genommen keine repräsentative Abdeckung aller Branchen, Normen oder Produkttypen des Maschinenbaus.

Die Bewertungseinheit: Code, Ansichten und eine geometrische Referenz

Bei Vision2Code ist die Eingabe eine visuelle Darstellung des Bauteils; erwartet wird ein CadQuery-Programm, das es rekonstruieren kann. Die Bewertung honoriert nicht bloß eine Textfolge, die dem ursprünglichen Programm ähnelt: Sie führt das Kandidatenprogramm aus und vergleicht den resultierenden Körper mit dem STEP-Referenzkörper. Unterschiedliche Programme können daher ähnlich abschneiden, sofern sie eine nahe Geometrie erzeugen.

Bei CodeEdit ergänzt die Eingabe ein Basisprogramm und eine Bearbeitungsanweisung. Ziel ist nicht die Rekonstruktion eines Bauteils von Grund auf, sondern die Änderung des Codes, damit seine Geometrie einem Ziel näherkommt. Diese Formulierung ähnelt stärker einem technischen Assistenzfall, bleibt aber kontrolliert: Anweisung, Ausgangspunkt, Engine und Referenz sind durch den Datensatz vorgegeben.

Vision-QA und Code-QA verändern die Art der Ausgabe. Bei Vision-QA leitet das System eine numerische Antwort aus Ansichten ab, bei Code-QA durch Schlussfolgern über Code. Die Aufgaben trennen das Lesen von Geometrie teilweise von der Programmerzeugung. Dennoch beweist eine korrekte numerische Antwort nicht, dass ein System einen Entwurf ändern kann, ohne Abhängigkeiten zu zerstören, oder ein vollständiges CAD-Projekt verwalten kann.

Der veröffentlichte Bestand enthält CadQuery-Programme, Renderings und numerische Fragen. Dass ein Artefakt in einem öffentlichen Datensatz oder Repository sichtbar ist, führt zu einer üblichen Unsicherheit bei der Modellbewertung: Material könnte vor dem Training bestimmter Systeme zugänglich gewesen sein. Die vorliegenden Quellen erlauben weder, für jedes Modell im Leaderboard konkrete Kontaminationskontrollen festzustellen, noch das Fehlen einer früheren Exposition nachzuweisen.

Wie bewertet wird: Ausführung, Volumenüberlappung und Verbesserung gegenüber einer Baseline

Die Vision2Code-Metrik verbindet zwei Bedingungen. Erstens muss das Programm ausgeführt werden. Zweitens muss sich der erzeugte Körper mit dem Referenzkörper überlappen, nachdem beide auf ein Voxelraster mit der Auflösung 64³ abgebildet wurden. Das Leaderboard beschreibt den Wert als volumetrischen IoU multipliziert mit dem Anteil ausführbarer Programme. Diese Multiplikation verhindert, dass gute Geometrie in wenigen Fällen eine hohe Quote von Ausführungsfehlern verdeckt.

Diese Signale müssen getrennt gelesen werden. Die Ausführungsrate zeigt, ob Ausgaben von der festgelegten Umgebung akzeptiert werden und eine bewertbare Geometrie erzeugen. Der IoU zeigt, wie stark das diskretisierte Volumen der ausführbaren Ausgaben mit der Referenz übereinstimmt. Ein Programm kann fehlerfrei laufen und dennoch einen falschen Körper erzeugen. Es kann auch eine vernünftige Strategie ausdrücken, aber wegen einer API, eines Imports oder einer Ausnahme scheitern; dann liefert es keine bewertbare Geometrie.

Bei CodeEdit verwendet das Leaderboard nicht einfach den finalen IoU. Es normiert die Verbesserung gegenüber der Ausgangsgeometrie: Vom IoU des Modells wird der IoU der Baseline abgezogen, anschließend wird durch den verbleibenden Abstand zu eins geteilt; danach wird das Ergebnis auf den Bereich zwischen null und eins begrenzt. Verbessert eine Bearbeitung den Ausgangspunkt nicht – auch bei einer nicht ausführbaren Ausgabe –, trägt sie null bei. Diese Wahl belohnt überprüfbaren Fortschritt und vermeidet, dass eine Änderung als Erfolg gilt, wenn sie ein bereits nahes Bauteil nur unverändert lässt.

Für Vision-QA und Code-QA beschreibt die Dokumentation eine symmetrische Ratio-Genauigkeit für numerische Fragen. Praktisch hängt die Bewertung von der relativen Nähe zwischen vorhergesagter und referenzierter Antwort ab, symmetrisch gegenüber Über- und Unterschätzung. Um kleine Unterschiede sicher zu deuten, müsste die konkrete Implementierung zu Toleranzen, Rundungen, Nullen und Antwortformaten geprüft werden. Die bereitgestellten Hinweise erläutern nicht alle Grenzfälle.

Welche Ergebnisse tatsächlich vergleichbar sind

Eine BenchCAD-Zahl erhält vergleichbare Bedeutung nur bei gleichem Protokoll. Mindestens müssen die konkrete Benchmark-Version, der Datensplit, die Aufgabe und die Art des Ergebnisses identifiziert werden. Vision2Code ist nicht mit CodeEdit gleichzusetzen, ebenso wenig ein ausgewählter Teilbestand mit einer vollständigen Auswertung. Zahlen, die mit unterschiedlichen Werkzeugen, Reparaturschleifen oder Inferenzbudgets erzielt wurden, gehören ebenfalls nicht ohne Weiteres in dieselbe Kategorie.

Der veröffentlichte Beitragsprozess verlangt Rohvorhersagen und die Ausführungskonfiguration. Er besagt, dass die Maintainer die Ausgaben mit dem offiziellen Evaluator erneut bewerten, bevor operative Ergebnisse in das Leaderboard aufgenommen werden. Das ist relevant, weil dadurch eine einheitliche Ausführungs- und Bewertungspolitik gelten kann, statt nur eine vom Modellbetreiber erklärte Zahl zu akzeptieren. Die Neubewertung macht die Erzeugungsbedingungen allerdings nicht automatisch identisch.

Beim Lesen einer Leaderboard-Zeile sollte eine technische verantwortliche Person die vollständige Konfiguration verlangen: CadQuery-Version und Abhängigkeiten, Zugriff auf Python und externe Werkzeuge, maximale Zahl an Iterationen, Einsatz von Zwischenrenderings, Zeitlimits, verfügbarer Kontext, Temperatur oder Sampling-Strategie sowie Rechenbudget. Ein Agent, der Code ausführen, Fehler beobachten und ihn mehrfach reparieren kann, löst operativ ein anderes Problem als ein Modell mit einer einzigen Antwort.

Auch die Behandlung fehlgeschlagener Ausgaben ist entscheidend. Bei Vision2Code verringern Ausführungsfehler das aggregierte Ergebnis über den Ausführungsanteil. Bei CodeEdit erzielt eine nicht ausführbare Ausgabe oder eine Ausgabe ohne Verbesserung gegenüber der Baseline keine Verbesserung. Nur den IoU erfolgreicher Fälle zu veröffentlichen, würde gerade einen zentralen Teil der Schwierigkeit verbergen: reproduzierbare Programme in der vorgegebenen Umgebung zu erzeugen.

Was geometrische Übereinstimmung nicht misst

BenchCAD liefert Evidenz für geometrische Rekonstruktion unter begrenzten Bedingungen, keine Zertifizierung industrieller Konstruktion. Dieselbe äußere Geometrie kann mit mehreren Konstruktionsabsichten vereinbar sein. Wandstärke, Bohrungsposition oder Radius können aus einer Belastung, Schnittstelle, Norm, Fertigungsmaschine, Montageschrittfolge oder Kostenentscheidung folgen, die sich nicht zuverlässig aus Ansichten und einem Referenzkörper ableiten lässt.

Das Benchmark validiert weder Maß- und Formtoleranzen, Passungen, Oberflächen, Materialien, Behandlungen, thermische Eigenschaften, Strukturverhalten noch Ermüdungslebensdauer. Ein Bauteil kann einen hohen IoU erreichen und dennoch an einer wesentlichen Bedingung scheitern: Es passt nicht zum Gegenstück, lässt das vorgesehene Bearbeitungswerkzeug nicht zu, trägt die Last nicht oder verletzt regulatorische Anforderungen. Solche Eigenschaften erfordern explizite Anforderungen, spezialisierte Analysen, Materialdaten und je nach Fall Prototypen oder Prüfungen.

Die Bewertung konzentriert sich außerdem auf einzelne Bauteile und Programme in einer kontrollierten Umgebung. Sie belegt weder die Verwaltung komplexer Baugruppen, externer Referenzen und interner Bibliotheken noch Änderungssteuerung, Nachverfolgbarkeit von Entscheidungen, Peer Review, Zugriffskontrolle oder Interoperabilität mit CAD-, PLM- und Dokumentenmanagementsystemen eines Unternehmens. Ein Copilot kann in einer Phase nützlich sein, ohne für einen autonomen Freigabeprozess geeignet zu sein.

Die verantwortungsvolle Lesart lautet deshalb nicht, BenchCAD sei unzureichend, sondern dass es eine klar begrenzte Frage beantwortet. Wenn geklärt werden soll, ob generierter CAD-Code läuft und sich einer Referenz annähert, ist es ein direkteres Signal als ein visueller Vergleich. Für eine Einführung müssen zusätzliche Tests die realen Risiken des Produkts und der Organisation abbilden.

BenchCAD 1.0 und BenchCAD 2.0 dürfen nicht als dasselbe dargestellt werden

Die Quellen unterscheiden zwischen einem veröffentlichten Benchmark mit Aufgaben, Metriken und Leaderboard und einer späteren Initiative namens BenchCAD 2.0. Das Repository von BenchCAD 1.0 dokumentiert die vier Aufgaben, seine Umgebung und den Ergebnisprozess. Seine Zitationsmetadaten bezeichnen das Artefakt als Datensatz, nennen Version 0.1.0 und ein angegebenes Veröffentlichungsdatum vom 24. Juni 2026. Dieses Datum ist als vom Projekt deklarierte Metadatenangabe zu lesen; allein belegt es weder, wann einzelne Ergebnisse ausgeführt wurden, noch welche genaue Revision jeder Teilnehmende verwendet hat.

BenchCAD 2.0 wird als Datenpipeline auf Basis von Community-Beiträgen beschrieben, mit einem Ziel von 150 Familien und prüfbaren parametrischen Entwürfen, einschließlich industrieller Komponenten und Baugruppen. Das Repository selbst erklärt ausdrücklich, dass es keine Bewertungs- oder Scoring-Pipeline ist. Der geplante Datenumfang darf daher nicht mit einem verfügbaren Leaderboard, einem validierten Protokoll oder einer direkt mit BenchCAD 1.0 vergleichbaren Zahl verwechselt werden.

Diese Trennung schützt vor zwei Fehlern: Erstens davor, ein Versprechen künftiger Abdeckung als bereits vorhandenes Leistungsmaß darzustellen. Zweitens davor, Ergebnisse zwischen Versionen zu übertragen, obwohl sich Bauteile, Familien, Quellen, Annotationen oder Bewertungsregeln ändern können. Solange für BenchCAD 2.0 kein veröffentlichtes Evaluations- und Scoring-Protokoll existiert, ist die vorsichtige Aussage: Es beschreibt einen Prozess zum Aufbau von Daten, kein gleichwertiges Leaderboard.

Checkliste für Anbieterankündigungen und Kaufentscheidungen

Bei einer Ankündigung, die BenchCAD zitiert, sollte die erste Frage konkret sein: Welche Aufgabe hat das System gelöst? Zu behaupten, ein Modell sei „stark in CAD“, ohne anzugeben, ob es Code aus Bildern erzeugt, ein Programm bearbeitet oder numerische Fragen beantwortet, vermischt unterschiedliche Fähigkeiten. Die zweite Frage ist operativ: Umfasst die Zahl eine vollständige Ausführung, wie wurden Fehler behandelt und wurden Rohvorhersagen mit dem offiziellen Evaluator erneut bewertet?

Die dritte Frage betrifft die Bedingungen: Welche Werkzeuge, Iterationen und welches Budget waren zulässig? Bei agentischen Systemen verändern diese Variablen Ergebnis und Kosten wesentlich. Die vierte ist statistisch: Wurde der komplette Split oder eine Auswahl bewertet, und wie viele Fälle sind enthalten? Die fünfte verlagert die Diskussion auf das Produkt: Welche unabhängige Validierung erfolgte für Toleranzen, Fertigungsprozess, Baugruppe und Kundenanforderungen?

Eine belastbare Antwort kann zurückhaltend sein: „In Vision2Code von BenchCAD 1.0 erzeugte das System unter der angegebenen Umgebung und dem genannten Budget Programme, deren ausgeführte Geometrie eine bestimmte volumetrische Übereinstimmung bei einer bestimmten Ausführungsrate erreichte.“ Diese Formulierung sagt, was gemessen wurde, ohne aus einer Benchmark-Metrik eine Engineering-Garantie zu machen. Die Entscheidung über einen Einsatz sollte zusätzlich auf einem Pilot mit Bauteilen, Regeln und Werkzeugen beruhen, die für den eigenen Kontext repräsentativ sind.

Der zentrale Wert von BenchCAD liegt gerade darin, eine überprüfbare Grenze sichtbar zu machen: von einer visuellen, textlichen oder Code-Eingabe zu einem Programm, das die CAD-Umgebung ausführen kann und dessen Geometrie prüfbar ist. Diese Grenze ist anspruchsvoll und relevant. Industriedesign und Produktfreigabe überschreiten jedoch weitere Grenzen, die das Benchmark nicht zu lösen beansprucht.

Weiter entdecken

Korrekturen und Transparenz

Wenn du falsche oder veraltete Angaben findest, sende uns die Seite und die zu prüfende Quelle.