Verifiable AI – Warum Sprachmodelle ohne Rechenweg und Gegenprobe an einer Holzbox scheitern

Du stehst im Baumarkt vor dem Holzzuschnitt und brauchst sechs Bretter aus 16 mm starkem MDF für ein geschlossenes 4-Liter-Lautsprechergehäuse (Markaudio Pluvia 7.2 HD). Auf dem Smartphone liefert ein aktuelles Frontier-Sprachmodell in Sekunden eine fertige Zuschnittliste samt 45-Minuten-Bauanleitung. Doch als die fertig gesägten Bretter zu Hause auf dem Tisch liegen, stehen die Front- und Rückplatten um exakt 3,2 cm wie zwei Stützfüße über. Auf Nachfrage gibt die KI zunächst dir die Schuld („Du hast die Platten um 90° verdreht“) – und merkt erst vier Nachrichten später mitten im eigenen Satz, dass ihre Geometrie unmöglich aufgehen kann.

Sprachmodelle berechnen Geometrie nicht über ein räumliches Modell, sondern sagen Text-Tokens Schritt für Schritt voraus. Schreibt ein Modell in einer Tabelle sofort das Endergebnis (25,2 × 18,2 cm) ohne den Zwischenschritt der Kantenaddition hin, überspringt es die Prüfung, welche Plattenkante auf welcher aufliegt. Zudem verteidigt es einmal geschriebene Fehler im selben Chatverlauf hartnäckig, während lange Erklärungen die Kontrolle im Alltag erschweren. Verlässliche Antworten entstehen erst, wenn Prompts den Rechenweg direkt in jeder Zeile sowie eine explizite Gegenprobe erzwingen.

Warum verrechnet sich ein Top-Modell an einer simplen Holzbox?

Ein geschlossener Quader aus sechs stumpf auf Stoß verleimten Holzplatten wirkt wie eine Aufgabe aus der Mittelstufe. Dennoch treffen bei einer Zuschnittliste zwei grundlegende Eigenschaften von Autoregressive LLMs (Sprachmodelle, die jedes nächste Wort (Token) rein statistisch auf Basis der bisher erzeugten Wortfolge vorhersagen, ohne vorab einen vollständigen Rechenplan im Arbeitsspeicher anzulegen.) aufeinander: fehlende räumliche Repräsentation und das Überspringen von Zwischenrechnungen in Tabellen.

Im konkreten Fallbeispiel (Gehäuseplanung für einen Markaudio Pluvia 7.2 HD Breitbänder mit 16 mm = 1,6 cm MDF-Wandstärke) legte das Modell folgende Konstruktion fest:

• Geplantes Innenmaß: 15,0 cm (Breite) × 22,0 cm (Höhe) × 13,5 cm (Tiefe) = 4,455 Liter Bruttovolumen.
• Vom Modell vorgegebene Bauweise: „Deckel und Boden liegen zwischen den Seitenwänden; Front und Rückwand werden vorne und hinten komplett stumpf aufgedoppelt.“

Für diese Vorgabe gab die KI im Baumarkt folgende Zuschnittliste aus:

Der Kantenstoß-Trugschluss: Algebra vs. Topologie

Das Volumen eines Quaders (15,0 × 22,0 × 13,5 cm = 4,455 l) ist einfache Algebra. Eine stumpfe Stoßverbindung in drei Raumachsen erfordert dagegen Topologie (Die räumliche Beziehung und Anschlusslogik von Bauteilen untereinander – hier die Frage, welche Plattenkante durchgeht und welche um zwei Wandstärken gekürzt werden muss.): Wenn vier Bretter (zwei Seitenwände, ein Deckel, ein Boden) einen umlaufenden Rahmen der Tiefe 13,5 cm bilden, überlappt bei einem stumpfen Stoß immer nur ein Plattenpaar das andere.

Steckt man die 15,0 cm breiten Deckel- und Bodenplatten wie von der KI gefordert zwischen die 22,0 cm hohen Seitenwände, addiert sich die doppelte Wandstärke (2 × 1,6 cm = 3,2 cm) zwar zur Breite (15,0 + 3,2 = 18,2 cm), aber nicht zur Höhe. Die Gesamthöhe des Rahmens bleibt exakt die Länge der Seitenwände (22,0 cm), während die lichte Innenhöhe der Kammer auf 22,0 − 3,2 = 18,8 cm schrumpft (das Bruttovolumen fällt um 14,5 % von 4,46 l auf 3,81 l).

Weil die KI für Front und Rückwand pauschal auf beide Achsen 3,2 cm aufgeschlagen hatte (25,2 × 18,2 cm), ragten Front und Rückwand auf dem 22,0 cm hohen Rahmen zwangsläufig um 25,2 − 22,0 = 3,2 cm über.

Warum verteidigt die KI ihre falschen Maße über vier Nachrichten hinweg?

Noch lehrreicher als der Rechenfehler selbst ist die Reaktion des Modells, als der Fehler zu Hause beim Zusammenlegen auffällt. Statt die Maße sofort zu korrigieren, durchläuft der Chat drei typische Phasen, die in der aktuellen Forschung als strukturelle Schwächen großer Sprachmodelle dokumentiert sind:

1. In-Context Stubbornness (Stures Festhalten am eigenen Text)

Auf den Hinweis, dass die Box im Probelauf zwei überstehende „Füße“ hat, antwortet die KI: „Die Maße stimmen, aber du hast die Platten an zwei Stellen um 90° verdreht zusammengelegt.“ Auch nach erneutem Widerspruch behauptet das Modell weiter: „Die Bretter, die du aus dem Baumarkt geholt hast, sind nicht falsch zugeschnitten.“

Wie Huang et al. (ICLR 2024) zeigen, gelingt Sprachmodellen eine intrinsische Selbstkorrektur ohne externes Prüfsignal fast nie. Sobald die fehlerhafte Tabelle im Kontextfenster steht, wirkt Autoregressive Anchoring (Das Phänomen, dass ein Sprachmodell seine eigenen früheren Aussagen im selben Chatverlauf als hochwahrscheinliche Fakten behandelt und nachfolgende Antworten zur Rechtfertigung dieser Ankerwerte formuliert.): Das Modell behandelt seine eigene Tabelle als gesetzte Wahrheit und erfindet im Zweifel abenteuerliche Bedienungsfehler des Nutzers, um den Widerspruch aufzulösen.

2. Denken während des Tippens: Der „Halt“-Moment im vierten Anlauf

Erst im vierten Anlauf versucht das Modell, dem Nutzer vorzurechnen, man müsse die 15,0 cm breiten Deckel- und Bodenplatten einfach oben auf statt zwischen die 22,0 cm hohen Seitenwände legen. Während es diesen Gedanken Satz für Satz ausschreibt, passiert im Original-Chat Folgendes:

1Höhe: 1,6 cm Boden + 22,0 cm Seitenwand + 1,6 cm Deckel = exakt 25,2 cm.
2Breite: 15,0 cm + Kanten bündig = 15,0 cm Innenbreite.
3(Wenn die Deckel/Bodenplatten 15,0 cm breit sind und oben/unten draufsitzen,
4fehlen an der Außenbreite 2× 1,6 cm, falls sie nicht überdecken).
5Halt – genau da lag die unsaubere Kantenlogik in meiner ersten Tabelle:
6Packt man Deckel/Boden zwischen die Seiten, ist die Breite außen 18,2 cm,
7aber die Höhe nur 22,0 cm. Packt man sie oben drauf, ist die Höhe 25,2 cm,
8aber die Breite außen nur 15,0 cm.

Dieser mitten im Satz auftretende „Halt“-Moment entlarvt die Mechanik: Solange die KI in ihrer ersten Antwort nur die nackten Zahlen 25,2 × 18,2 cm in eine Tabelle schrieb, fand keine Kantenprüfung statt. Erst als sie die Additionskette für Höhe und Breite explizit in Text-Tokens ausschreiben musste, kollidierten die Zahlen sichtbar im Kontextfenster.

3. Verbosity Bias und Schönfärberei (Sycophancy)

Warum fällt ein solcher 3,2-cm-Fehler im Baumarkt nicht sofort beim Blick aufs Handy auf? Weil die KI die drei fehlerhaften Tabellenzeilen in über 250 Wörter Zusatzinformationen verpackt: Dämmwatte-Tipps, Ponal-Express-Trockenzeiten, Stichsägen-Ratschläge und Einbauresonanzen (fc ≈ 108 Hz, Qtc ≈ 0,84).

Durch Verbosity Bias (Die durch menschliches Feedback-Training (RLHF) antrainierte Neigung von Sprachmodellen, unnötig lange, höfliche und fachsprachlich ausgeschmückte Antworten zu generieren, die Kompetenz suggerieren.) entsteht eine enorme Generation-Verification Gap (Das Missverhältnis zwischen den minimalen Kosten, eine plausibel klingende KI-Antwort zu generieren (Sekunden), und dem hohen kognitiven Aufwand, deren Korrektheit im Detail zu überprüfen.): Wer im Baumarkt unter Zeitdruck steht, wird von der Informationsflut erschlagen und verlässt sich auf den autoritären Tonfall. Und als der Nutzer die Platten am Ende um 90° gedreht zusammenleimt (die 25,2 × 18,2 cm Platten links und rechts als Seitenwangen, sodass vorne, hinten und oben alles bündig schließt und unten 3,2 cm hohe Kufen entstehen), verkauft die KI selbst diesen Notbehelf noch euphorisch als „integrierten Standfuß zur akustischen Entkopplung auf dem Schreibtisch“.

Interaktiver Kantenstoß- & Invarianten-Inspektor

Prüfe im Simulator selbst, warum sich die drei Bretterpaare der Original-KI-Liste in keiner Lage zu einem bündigen Quader fügen lassen, wie der reale 90°-Werkstatt-Hack funktioniert und wie die beiden mathematisch korrekten Zuschnittlisten mit expliziter Gegenprobe aussehen:

Was zeigt dieser Vergleich für den Umgang mit KI?

Der Simulator verdeutlicht zwei Dinge: Erstens lässt sich der Fehler in der Original-Liste (22,0 cm Seitenwand vs. 25,2 cm Frontplatte) sofort erkennen, sobald in der dritten Tabellenspalte der explizite Rechenweg neben dem Maß steht. Zweitens zeigt das Szenario „2. Realer Werkstatt-Rettungsbau“, dass menschliches räumliches Vorstellungsvermögen dem Sprachmodell überlegen war: Weil die kleinen Deckelplatten (15,0 cm) zusammen mit den 22,0 cm Platten (2 × 1,6 cm Dicke) exakt 15,0 + 3,2 = 18,2 cm Tiefe ergaben, passten die großen 25,2 × 18,2 cm Platten als seitliche Außenwangen bündig an den Kern – eine topologische Lösung, die das Sprachmodell selbst am Ende des Chats nicht nachvollziehen konnte.

Wie zwinge ich Sprachmodelle zu überprüfbaren Antworten? (Der Taschenrechner-Vertrag)

Früher galt im Mathematikunterricht eine einfache Regel: Ein nacktes Endergebnis aus dem Taschenrechner zählt null Punkte, wenn der Rechenweg fehlt. Bei Sprachmodellen erfüllt diese Schulregel einen doppelten Zweck:

1. Für das Modell (Chain-of-Thought in-place): Wenn das Modell gezwungen ist, vor das Gleichheitszeichen die konkrete Addition zu schreiben (15,0 cm Innen + 2 × 1,6 cm Seitenwand = 18,2 cm), berechnet es den Wert anhand der geschriebenen Tokens, statt eine Zahl zu schätzen.
2. Für den Menschen (5-Sekunden-Audit): Im Baumarkt oder im Code-Review kannst du eine nackte Zahl (18,2 cm) nicht prüfen, ohne alles selbst im Kopf neu zu konstruieren. Eine ausgeschriebene Zeile (15,0 + 2 × 1,6 = 18,2 cm) prüfst du dagegen in zwei Sekunden auf Plausibilität.

Kopierbares Prompt-Rezept für überprüfbare Berechnungen & Pläne

Nutze dieses Prompt-Muster auf dem Smartphone oder im Arbeitsalltag, wenn du Zuschnittlisten, Mengenberechnungen, Konfigurationswerte oder technische Umrechnungen brauchst, die auf Anhieb stimmen müssen:

Deterministisches Prüfskript für rechteckige Gehäuse (Python)

Wer ein Sprachmodell über Tool-Calling oder eine Code-Umgebung nutzt, lässt es statt einer Texttabelle ein kurzes Prüfskript mit harten assert-Bedingungen (Invariante (Eine Bedingung, die nach einer Berechnung oder Transformation unter allen Umständen wahr sein muss – etwa dass die Außenhöhe des Rahmens exakt der Höhe der aufgeleimten Frontplatte entspricht.)) generieren und ausführen. Schlägt eine Kantenbedingung fehl, bricht das Skript mit einem AssertionError ab, bevor falsches Holz gesägt wird:

1from dataclasses import dataclass
2
3@dataclass(frozen=True)
4class CutBoard:
5    name: str
6    count: int
7    length_cm: float
8    width_cm: float
9    formula: str
10
11def verify_flush_speaker_box(
12    inner_w_cm: float,
13    inner_h_cm: float,
14    inner_d_cm: float,
15    thickness_cm: float,
16    top_between_sides: bool = True,
17) -> list[CutBoard]:
18    """
19    Berechnet einen stumpf verleimten 6-Platten-Quader (Front/Rückwand aufgedoppelt)
20    und prüft deterministisch alle Kanten- und Volumen-Invarianten.
21    """
22    two_t = round(2 * thickness_cm, 4)
23    outer_w = round(inner_w_cm + two_t, 4)
24    outer_h = round(inner_h_cm + two_t, 4)
25
26    # Front & Rückwand decken den Rahmen vorne und hinten vollflächig ab
27    front_back = CutBoard(
28        name="Front & Rückwand",
29        count=2,
30        length_cm=outer_h,
31        width_cm=outer_w,
32        formula=f"({inner_h_cm} + 2×{thickness_cm}) × ({inner_w_cm} + 2×{thickness_cm})",
33    )
34
35    if top_between_sides:
36        # Seiten laufen über die volle Außenhöhe; Deckel/Boden klemmen dazwischen
37        sides = CutBoard(
38            name="Seitenwände (durchgehend)",
39            count=2,
40            length_cm=outer_h,
41            width_cm=inner_d_cm,
42            formula=f"({inner_h_cm} + 2×{thickness_cm} = {outer_h}) × {inner_d_cm}",
43        )
44        top_bottom = CutBoard(
45            name="Deckel & Boden (dazwischen)",
46            count=2,
47            length_cm=inner_w_cm,
48            width_cm=inner_d_cm,
49            formula=f"{inner_w_cm} (Innenbreite) × {inner_d_cm}",
50        )
51        frame_outer_h = sides.length_cm
52        frame_outer_w = round(top_bottom.length_cm + two_t, 4)
53        real_inner_h = round(sides.length_cm - two_t, 4)
54        real_inner_w = top_bottom.length_cm
55    else:
56        # Deckel/Boden laufen über die volle Außenbreite; Seiten stehen dazwischen
57        sides = CutBoard(
58            name="Seitenwände (dazwischen)",
59            count=2,
60            length_cm=inner_h_cm,
61            width_cm=inner_d_cm,
62            formula=f"{inner_h_cm} (Innenhöhe) × {inner_d_cm}",
63        )
64        top_bottom = CutBoard(
65            name="Deckel & Boden (aufliegend)",
66            count=2,
67            length_cm=outer_w,
68            width_cm=inner_d_cm,
69            formula=f"({inner_w_cm} + 2×{thickness_cm} = {outer_w}) × {inner_d_cm}",
70        )
71        frame_outer_h = round(sides.length_cm + two_t, 4)
72        frame_outer_w = top_bottom.length_cm
73        real_inner_h = sides.length_cm
74        real_inner_w = round(top_bottom.length_cm - two_t, 4)
75
76    # Harte Invarianten-Prüfung (verhindert den 3,2-cm-KI-Fehler)
77    assert frame_outer_h == front_back.length_cm, (
78        f"Höhen-Überstand! Rahmen ({frame_outer_h} cm) != Front ({front_back.length_cm} cm)"
79    )
80    assert frame_outer_w == front_back.width_cm, (
81        f"Breiten-Überstand! Rahmen ({frame_outer_w} cm) != Front ({front_back.width_cm} cm)"
82    )
83    assert sides.width_cm == top_bottom.width_cm == inner_d_cm, "Rahmentiefe nicht bündig!"
84
85    target_vol_l = round((inner_w_cm * inner_h_cm * inner_d_cm) / 1000, 3)
86    real_vol_l = round((real_inner_w * real_inner_h * inner_d_cm) / 1000, 3)
87    assert target_vol_l == real_vol_l, f"Volumen-Drift: {real_vol_l} l != {target_vol_l} l"
88
89    return [front_back, sides, top_bottom]
90
91if __name__ == "__main__":
92    # Markaudio Pluvia 7.2 HD: 15,0 × 22,0 × 13,5 cm innen, 16 mm (1,6 cm) MDF
93    boards = verify_flush_speaker_box(15.0, 22.0, 13.5, thickness_cm=1.6, top_between_sides=True)
94    for b in boards:
95        print(f"{b.count}x {b.name:28s}: {b.length_cm:5.1f} × {b.width_cm:5.1f} cm  |  {b.formula}")

Wann reicht ein Verifikations-Prompt und wann braucht man echte Werkzeuge?

Ein Prompt mit Rechenweg und Gegenprobe verbessert die Nachvollziehbarkeit erheblich, macht aus einem Sprachmodell aber noch kein CAD-Programm. Die folgende Übersicht grenzt ab, wann welcher Prüfmechanismus ausreicht:

Checkliste: 4-Punkte-Prüfung vor dem Vertrauen in KI-Maße

Bevor du mit einer von der KI berechneten Liste in den Baumarkt fährst, Daten in Produktion übernimmst oder ein technisches Rezept umsetzt, prüfe diese vier Punkte:

• Steht der Rechenweg neben jeder Zahl? Wenn in einer Tabelle nur nackte Endmaße (25,2 × 18,2 cm) stehen, verlange die ausgeschriebene Herleitung (22,0 + 2 × 1,6 = 25,2 cm) in derselben Zeile.
• Sind die Schnittstellen-Annahmen explizit benannt? Prüfe, ob das Modell vorab festgelegt hat, welches Bauteil durchgeht und welches dazwischen liegt (bei sechs Brettern muss die doppelte Wandstärke genau dort abgezogen oder addiert werden, wo Stoßkanten aufeinandertreffen).
• Geht die 5-Sekunden-Gegenprobe im Kopf auf? Addiere stichprobenartig für jede Raumachse die Innenmaße und Wandstärken: Ergeben Deckelbreite plus zwei Seitenwände wirklich die Breite der Frontplatte?
• Neuer Chat statt Endlos-Diskussion bei Widersprüchen: Sobald du merkst, dass ein KI-Ergebnis physisch nicht zusammenpasst, diskutiere nicht im selben Thread weiter, sondern prüfe die nackten Zahlen in einer neuen Sitzung oder per Code-Skript.

Quellen und nächste Schritte

Die psychologischen und architektonischen Ursachen hinter dem hier dokumentierten Baumarkt-Fallbeispiel sind in der KI- und HCI-Forschung (Human-Computer Interaction) eingehend untersucht:

• Huang et al. (ICLR 2024): Large Language Models Cannot Self-Correct Reasoning Yet – Weist nach, warum Sprachmodelle eigene Denkfehler im selben Kontextfenster ohne externes Prüfsignal (Oracle/Compiler) kaum selbst korrigieren und stattdessen an ihrer Erstantwort festhalten.
• Wei et al. (NeurIPS 2022): Chain-of-Thought Prompting Elicits Reasoning in Large Language Models – Erklärt den Grundmechanismus, warum das explizite Ausschreiben von Zwischenschritten vor dem Ergebnis die Fehlerrate bei mehrstufigen Rechenaufgaben senkt.
• Sharma et al. (ICLR 2024): Towards Understanding Sycophancy in Language Models – Untersucht, warum durch RLHF trainierte Modelle zu gefälligen, wortreichen Antworten und Schönfärberei neigen, statt Unsicherheiten oder Fehler klar zu benennen.
• Bansal et al. (CHI 2021): Does the Whole Exceed its Parts? The Effect of AI Explanations on Complementary Team Performance – Zeigt empirisch, dass lange, überzeugend formulierte KI-Erklärungen bei Menschen unkritische Übernahme (Over-Reliance) fördern, statt die Fehlererkennung zu verbessern.

Wie sich lange, schwer prüfbare Textblöcke auf der Benutzeroberfläche durch kompakte, bei Bedarf aufklappbare Erklärungen entschärfen lassen, zeigt die Kachel Explainable Text. Wie autonome Agenten beim 3D-Druck durch harte, deterministische Sicherheitsfilter und OpenSCAD-Code daran gehindert werden, fehlerhafte Geometrie direkt an reale Hardware zu senden, beschreibt die Kachel 3D-Druck MCP.