Kann AI Baupläne lesen? Wir haben nachgemessen.

18. August 2026 · 9 Min. Lesezeit · Simon Prast

Wer einen Bauplan in ChatGPT einfügt und eine Fachfrage stellt, bekommt in aller Regel erfundene Zahlen und vage Aussagen. Die meisten Leute ziehen daraus den Entschluss, dass LLMs mit CAD-Plänen einfach noch nicht gut genug arbeiten können. Wir haben für einen Kunden, der mit ArchiCAD arbeitet, eine Gegenthese getestet: Ein AI-Modell bekommt die Werkzeuge, die ein Mensch am Plantisch auch verwendet, und muss damit Fehler auf einem einfachen Grundriss finden (A) und eine Mengenermittlung für eine Projektkalkulation an einem echten, 44-seitigen CAD-Drawing durchführen (B).

Den daraus entstandenen Prototyp haben wir mit unserem Eval Harness auf Leistung und Konsistenz geprüft. Folgend kurz ein Überblick über die Ergebnisse dessen sowie über die Methodik, welche wir zur Umsetzung und zur Leistungsbeurteilung angewendet haben.

Ausgangssituation: Warum ein in ChatGPT angehängter Bauplan nicht verarbeitbar ist

Eine Planseite ist groß und die Schrift darauf klein: Der Lüftungsgrundriss aus unserem Test B hat 36 x 24 Zoll; ein Tag eines Luftauslasses darauf hat eine Schrifthöhe von 3 mm. Wenn man diese Seite in einen Chat einfügt, wird es auf rund 1.500 Pixel Kantenlänge verkleinert, womit aus den 3 mm fünf Pixel werden und ein Kettenmaß oder eine Raumnummer auf der Vorschau zu einem grauen Fleck wird. Ein Mensch könnte daraus natürlich niemals einen Plan lesen, und das Modell kann es genauso wenig, weil es einfach kein lesbares Bild bekommt.

Der Mensch löst das am Plantisch mit Lupe und Lineal und am Bildschirm mit Zoom und Ebenensteuerung. Unsere These war, dass ein Frontier-AI-Modell bereits heute mit denselben Werkzeugen Pläne in einer Qualität auswerten kann, die einem Menschen ggü. konkurrenzfähig ist, allerdings in einem Bruchteil der Zeit. Getestet haben wir die Konsistenz der Arbeit des AI-Modells.

Der Testaufbau

Wir haben mit zwei Plänen und zwei Aufgaben gearbeitet:

• Plan A, Fehlersuche: Ein synthetischer, bewusst einfach gehaltener Wohnungsgrundriss im Maßstab 1:100 auf einer A3-Seite, in den wir absichtlich zwei Fehler eingebaut haben: Die Maßkette behauptet für das Schlafzimmer 4,00 m, gezeichnet sind aber 3,485 m, und das Wohnzimmer ist mit 5,86 m beschriftet, gezeichnet sind 5,80 m. Beides fällt nicht auf, wenn man nur den Zahlen glaubt. Unser Test-Prompt zu diesem Task lautet „Prüf diesen Plan auf Fehler“, explizit ohne Hinweis darauf, wo der Fehler sein könnte.
• Plan B, Ausschreibungsfrage: Basis dafür sind die öffentlichen Ausschreibungsunterlagen für die Sanierung eines Freizeitzentrums in Georgia (USA). Der Plan besteht aus 44 Seiten Haustechnik, Sanitär und Elektro als Vektor-PDF mit gesamt 190 CAD-Ebenen und bis zu 111.000 Vektorelementen pro Seite. Die Frage haben wir so gestellt, wie sie auch ein Kalkulant oder ein Subcontractor stellen könnte: „Wie viele Deckenauslässe muss ich für diese Sanierung bestellen, welche Typen sind das, und wie groß?“

Das Modell ist in beiden Fällen Claude Opus 5 in Claude Code via Agent SDK. In der Testbedingung „mit Toolset“ bekommt es einen eigenen Workspace mit dem Original-PDF und einem Toolkit auf Basis von PyMuPDF, das folgende Dinge kann:

• Übersicht und Zoom: ganze Seiten oder Ausschnitte davon mit 300 dpi Auflösung rendern und ansehen
• Text mit Koordinaten: jede Beschriftung des Vektor-PDFs mit ihrer zugehörigen Position finden und so zusammenhängende Texte verstehen und zuordnen
• Fangen: die nächsten Vektorkanten neben einem Punkt abrufen, damit die AI wirklich misst und nicht schätzt
• Messen: Koordinaten zweier Punkte angeben, und die AI erhält die Distanz, umgerechnet über den Maßstab aus dem Plankopf
• Ebenen: CAD-Ebenen ein- und ausblenden, zum Beispiel nur Zuluft ohne Abluft
• Markieren: Befunde als beschriftete Rahmen und Linien in den Plan zeichnen, was gegen Halluzinationen und beim Double-Checking hilft

Die Tools selbst enthalten keine AI: Sie rendern Pixel und lesen Vektorkanten sowie Textobjekte aus dem PDF; alles andere ist Arithmetik, und wo das Modell zoomt oder was es nachmisst, entscheidet es selbst.

In der Kontrollbedingung „ohne Toolset“ bekommt dasselbe Modell dieselbe Frage aus Test A und den Plan als Bild mit 1.568 Pixeln Kantenlänge in den Chat eingefügt. Das entspricht dem üblichen Nutzerverhalten in ChatGPT oder Claude und ist unsere Baseline für den Test.

Unser Eval Harness führt die Tests automatisiert und vielfach aus. Er startet jeden Run frisch, ohne Erinnerung an die vorherigen, verlangt die Antwort in einem festen JSON-Schema und übergibt sie einem deterministischen Scorer, der sie mit einer Ground Truth vergleicht, die wir vorab aus der Vektorgeometrie der PDFs abgeleitet und manuell überprüft haben. Plan A lief 30 Mal je Bedingung (mit und ohne Toolset), Plan B 30 Mal mit Toolset.

Plan A: Versteckte Maßfehler

Mit Toolset haben alle 30 Runs die Wandkanten per Vektor-Fang bestimmt und das Schlafzimmer mit 3,485 m nachgemessen, bei einem mittleren Messfehler von einem Millimeter. Ebenfalls alle 30 haben gemeldet, dass die Maßkette in Summe 10,575 m ergibt, während das Gesamtmaß 10,00 m sagt, und darüber hinaus auch den zweiten eingebauten Fehler gefunden, die 5,86 m beim Wohnzimmer, das mit 5,80 m gezeichnet ist.

Ohne Toolset, also mit dem Plan als Bild im Chat, hat das Modell das Maß 4,00 in 28 von 30 Runs ebenfalls als verdächtig benannt, konnte aber nicht sagen, was richtig wäre: Zwölf Runs haben den Wert aus den übrigen Beschriftungen zurückgerechnet und sind bei 3,425 m gelandet, weil sie das falsche 5,86 als richtig übernommen haben, dreizehn haben aus den Pixeln 3,43 m geschätzt, und nur ein Run lag mit seiner Schätzung innerhalb unserer Toleranz von fünf Zentimetern. Die 6 cm beim Wohnzimmer hat ohne Toolset kein Run gesehen, den Widerspruch in der Maßkette immerhin 17 von 30.

Der Testplan hatte mehr Fehler, als wir eingebaut hatten

20 der 30 „mit Toolset“-Runs haben zusätzlich gemeldet, dass der Schwenkbogen der Schlafzimmertür eine Türbreite neben der Wandöffnung liegt, also über massiver Wand, und die Vektorgeometrie gab dem Modell recht, weil der Generator des Testplans den Bogen in die falsche Richtung gezeichnet hatte. Auch die drei Flächenangaben der Räume passten nicht zur Geometrie, was alle 30 Toolset-Runs angemerkt haben. Beide Befunde haben wir als richtig gewertet.

Ein erfundener Fehler mit Toolset war eine Anmerkung zur Schreibweise „11,5“ eines korrekten Wandmaßes, während es ohne Toolset sieben Runs mit einer erfundenen Abweichung waren, darunter zwei, die das korrekte Gesamtmaß von 7,00 m für falsch erklärt haben.

Plan B: die Ausschreibungsfrage

Jeder der 30 Runs hat unter den 44 Seiten den Lüftungsgrundriss M101 identifiziert und dort die Lüftungsauslass-Tags gezählt, bevor er Größen und Modellnummern aus der Bauteil-Tabelle auf Seite M601 geholt und gegen den Grundriss geprüft hat. In allen 30 Antworten standen dieselben Stückzahlen, nämlich 5, 4, 15, 1, 3, 4 und 3 Stück für die Typen A, B, C, D, H, I und J. Zwei Raumnummern, die auf der Seite unter einem einzelnen Buchstaben stehen (dem F und dem M von „TLT F“ und „TLT M“) und beim reinen Textabgleich wie ein Auslass-Tag mit Luftmenge aussehen, wurden in jedem Run aussortiert, und 22 Runs haben das in ihrer Antwort auch begründet. Größen und Modellnummern waren in allen 30 Antworten richtig, und M601 stand jedes Mal in der Liste der genutzten Seiten.

Zur Orientierung: So sieht die ganze Seite M101 aus, wie es das Modell zuerst als Übersicht rendert. Links der Grundriss mit dem Lüftungsnetz, in der Mitte die Anmerkungen zur Seite, rechts der Plankopf mit dem Maßstab 1/8" = 1'-0" und der Seitennummer. In dieser Größe lässt sich erkennen, wo Räume und Kanäle liegen, aber kein einziges Tag lesen. Genau in diesem Zustand kommt ein Plan im Chat an.

Wir zoomen jetzt in den oberen Teil des Grundrisses, den Trakt mit dem MP Room und den Sanitärräumen dahinter. Das ist der Ausschnitt, den das Modell in einem typischen Run mit 300 dpi rendert und ansieht:

Die einzige Varianz zwischen den Antworten von Test B ist der Frage geschuldet

Von den sieben Zuluft-Typen sind laut Tabelle zwei Wandauslässe, und genau darin weichen die 30 Antworten teilweise voneinander ab: 17 Runs haben „Deckenauslässe“ wörtlich genommen und 28 Stück in fünf Typen gemeldet, mit dem Hinweis auf die sieben Wandauslässe, während 13 Runs alle 35 Zuluftauslässe in sieben Typen genannt haben. Der Kalkulant bekommt in beiden Fällen dieselbe Information, nur die Grenze des Wortes „Decke“ wurde unterschiedlich gezogen, was eine Unschärfe der Frage ist und keine der Planlesung. Ein Assistent sollte an dieser Stelle nachfragen oder beide Lesarten nennen, bevor er eine Bestellmenge nennt. Das Modell hat die Wandauslässe in allen 30 Runs ausgewiesen, die Information war also jedes Mal vollständig.

Ein Run kostet zu API-Preisen ca. 3,90 $ und dauert knapp sieben Minuten. Das Modell hat im Schnitt 34 Tool Calls durchgeführt und zehn Ausschnitte angesehen, während ein Kalkulant für dieselbe Antwort mit zwei Seiten nebeneinander etwa 45 Minuten brauchen dürfte.

Was wir daraus mitnehmen

Das Modell war in diesem Test nie das Problem, denn sobald es den Plan so sehen kann wie ein Mensch, misst es und schätzt nicht mehr. Die Präzision kommt dabei aus der Geometrie und den Textobjekten im PDF, die ein Vektor-Export aus ArchiCAD oder Revit mitbringt und ein Scan verliert. Wir haben ähnliche Einschränkungen in der Fähigkeit von AI-Modellen bereits des Öfteren beobachtet: Genaue Definition von Arbeitsweisen sowie Erstellen von Tools und Kontext sind mitunter die wichtigsten Dinge, die jedes Unternehmen aktuell erarbeiten muss.

Jede Zahl bleibt in unserer Methodik nachprüfbar, weil es zu jedem Befund den Ausschnitt gibt, den das Modell angesehen hat, sowie die Messung, die es darauf gemacht hat. Falls die Plausibilität der Zahl nicht stimmt, besteht jederzeit die Möglichkeit, die jeweilige Stelle im Plan zu öffnen. Und weil die einzige Streuung im Test aus dem Wort „Decke“ kam, gehört unsere interne Instruction an das AI-Modell dahingehend geschärft, dass auf eine unscharfe Frage konsistent eine Rückfrage kommt statt einer uneinheitlichen Antwort.

Das Toolset aus diesem Test ist bereits in pinedock verfügbar.

Methodik in Kürze

• 90 Runs, davon Plan A 30 Mal mit Toolset und 30 Mal ohne Toolset sowie Plan B 30 Mal mit Toolset.
• Modell Claude Opus 5 im Claude-Code-Harness über das Agent SDK, wobei jeder Run denselben Prompt und dieselbe Tool-Beschreibung bekommt, ohne Hinweis auf Art oder Ort eines Fehlers.
• Antwort als festes JSON-Schema, ausgewertet von einem deterministischen Scorer gegen eine Ground Truth aus der Vektorgeometrie der PDFs.
• Kosten zu API-Listenpreisen. Zu jedem Run gibt es ein Protokoll mit allen Tool Calls und den betrachteten Ausschnitten sowie die zusammengefasste Begründung des Modells.
• Plansatz: „Renovation & Addition to North Macon Park Recreation Center“, Macon-Bibb County, Georgia, USA, 2016, öffentliche Ausschreibungsunterlagen.

Wenn du das mit deinen eigenen Plänen sehen willst, reichen zwei bis drei Vektor-PDF-Exporte aus deinem CAD und ein paar Fragen, deren Antwort deine Kalkulation schon kennt, für eine Demo an deinem Material.

Code und Rohdaten

Das Toolkit, der Eval Harness mit Scorern und Ground Truth sowie die Protokolle, Antworten und Scores aller 90 Runs liegen in einem GitHub-Repository. Trag deine E-Mail-Adresse ein und du bekommst den Link direkt hier und per Mail.