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

> **Autor:** Lukas Kopischke (Lead Software-Engineer, Düsseldorf)
> **Kanonische URL:** https://lukiluki.me/garden/verifiable-ai
> **Markdown-Endpunkt:** https://lukiluki.me/garden/verifiable-ai.md
> **Kategorie:** KI & Agents | **Tags:** Verifiable AI, Prompt Engineering, Chain-of-Thought, Invariants, AI UX
> **Veröffentlicht:** 2026-11-02 | **Aktualisiert:** 2026-11-02
> **Zusammenfassung:** Warum Sprachmodelle ohne Rechenweg an einer Holzbox scheitern und wie explizite Zwischenschritte sowie Gegenproben KI-Antworten in Sekunden prüfbar machen.

---
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.

> **Merksatz:**
> Ein nacktes KI-Ergebnis ohne Rechenweg ist wie eine Klassenarbeit ohne Zwischenschritte: Zwinge Sprachmodelle dazu, jede Zahl als sichtbare Formel herzuleiten und am Ende durch eine Gegenprobe (Invariante) zu beweisen.

## 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:

| Bauteil | Stück | KI-Zuschnittmaß | Vom Modell gedachte Rolle | Tatsächlicher geometrischer Effekt |
| :--- | :--- | :--- | :--- | :--- |
| **Front & Rückwand** | 2 | 25,2 × 18,2 cm | Vorne und hinten auf den Rahmen aufleimen | Höhe `22,0 + 2 × 1,6 = 25,2 cm`, Breite `15,0 + 2 × 1,6 = 18,2 cm` |
| **Seitenwände** | 2 | 22,0 × 13,5 cm | Stehen vertikal, schließen Deckel/Boden ein | **Fehler:** Wenn Deckel/Boden *dazwischen* liegen, ist der Rahmen außen nur 22,0 cm hoch! |
| **Deckel & Boden** | 2 | 15,0 × 13,5 cm | Klemmen horizontal zwischen den Seiten | Rahmenbreite außen wächst auf `15,0 + 2 × 1,6 = 18,2 cm` (bündig zur Front) |

### 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)](https://arxiv.org/abs/2310.01798) 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:

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

  #### Empfohlen (Do): Proof-Carrying Output (Ergebnis + Rechenweg + Gegenprobe)
Verlange in Tabellen immer eine eigene Spalte für die Formel (`Innenmaß ± n × Wandstärke = Zuschnitt`) und darunter eine maximal dreizeilige Gegenprobe (Invariante), die beweist, dass Außenmaße und Stückzahlen in allen drei Achsen aufgehen. Verbiete einleitende Ratschläge.
  #### Vermeiden (Don't): Offene Alltags-Prompts und Nachbohren im selben Chat
Frage niemals offen („Welche Maße brauche ich für 16 mm?“) ohne Formatvorgabe. Und wenn ein Ergebnis falsch aussieht: Diskutiere nicht im selben Chat („Stimmt das wirklich?“), sondern starte einen frischen Chat oder verlange einen Python-Code-Check, um das Autoregressive Anchoring zu durchbrechen.

> **Wann das Modell Python statt Text nutzen sollte**
> Moderne Frontier-Modelle verfügen über eine integrierte Code-Sandbox (Python/Code-Execution). Bei unstrukturierten Alltagsfragen auf dem Smartphone („Mach mir kurz eine einfache Box mit Loch“) schalten Router-Modelle diese Sandbox jedoch häufig nicht ein, sondern antworten im schnellen Textmodus. Der explizite Befehl **„Berechne und verifiziere die Maße per Python-Skript, bevor du antwortest“** zwingt das Modell aus dem statistischen Raten in eine deterministische Prüfung.

### 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:

```python
from dataclasses import dataclass

@dataclass(frozen=True)
class CutBoard:
    name: str
    count: int
    length_cm: float
    width_cm: float
    formula: str

def verify_flush_speaker_box(
    inner_w_cm: float,
    inner_h_cm: float,
    inner_d_cm: float,
    thickness_cm: float,
    top_between_sides: bool = True,
) -> list[CutBoard]:
    """
    Berechnet einen stumpf verleimten 6-Platten-Quader (Front/Rückwand aufgedoppelt)
    und prüft deterministisch alle Kanten- und Volumen-Invarianten.
    """
    two_t = round(2 * thickness_cm, 4)
    outer_w = round(inner_w_cm + two_t, 4)
    outer_h = round(inner_h_cm + two_t, 4)

    # Front & Rückwand decken den Rahmen vorne und hinten vollflächig ab
    front_back = CutBoard(
        name="Front & Rückwand",
        count=2,
        length_cm=outer_h,
        width_cm=outer_w,
        formula=f"({inner_h_cm} + 2×{thickness_cm}) × ({inner_w_cm} + 2×{thickness_cm})",
    )

    if top_between_sides:
        # Seiten laufen über die volle Außenhöhe; Deckel/Boden klemmen dazwischen
        sides = CutBoard(
            name="Seitenwände (durchgehend)",
            count=2,
            length_cm=outer_h,
            width_cm=inner_d_cm,
            formula=f"({inner_h_cm} + 2×{thickness_cm} = {outer_h}) × {inner_d_cm}",
        )
        top_bottom = CutBoard(
            name="Deckel & Boden (dazwischen)",
            count=2,
            length_cm=inner_w_cm,
            width_cm=inner_d_cm,
            formula=f"{inner_w_cm} (Innenbreite) × {inner_d_cm}",
        )
        frame_outer_h = sides.length_cm
        frame_outer_w = round(top_bottom.length_cm + two_t, 4)
        real_inner_h = round(sides.length_cm - two_t, 4)
        real_inner_w = top_bottom.length_cm
    else:
        # Deckel/Boden laufen über die volle Außenbreite; Seiten stehen dazwischen
        sides = CutBoard(
            name="Seitenwände (dazwischen)",
            count=2,
            length_cm=inner_h_cm,
            width_cm=inner_d_cm,
            formula=f"{inner_h_cm} (Innenhöhe) × {inner_d_cm}",
        )
        top_bottom = CutBoard(
            name="Deckel & Boden (aufliegend)",
            count=2,
            length_cm=outer_w,
            width_cm=inner_d_cm,
            formula=f"({inner_w_cm} + 2×{thickness_cm} = {outer_w}) × {inner_d_cm}",
        )
        frame_outer_h = round(sides.length_cm + two_t, 4)
        frame_outer_w = top_bottom.length_cm
        real_inner_h = sides.length_cm
        real_inner_w = round(top_bottom.length_cm - two_t, 4)

    # Harte Invarianten-Prüfung (verhindert den 3,2-cm-KI-Fehler)
    assert frame_outer_h == front_back.length_cm, (
        f"Höhen-Überstand! Rahmen ({frame_outer_h} cm) != Front ({front_back.length_cm} cm)"
    )
    assert frame_outer_w == front_back.width_cm, (
        f"Breiten-Überstand! Rahmen ({frame_outer_w} cm) != Front ({front_back.width_cm} cm)"
    )
    assert sides.width_cm == top_bottom.width_cm == inner_d_cm, "Rahmentiefe nicht bündig!"

    target_vol_l = round((inner_w_cm * inner_h_cm * inner_d_cm) / 1000, 3)
    real_vol_l = round((real_inner_w * real_inner_h * inner_d_cm) / 1000, 3)
    assert target_vol_l == real_vol_l, f"Volumen-Drift: {real_vol_l} l != {target_vol_l} l"

    return [front_back, sides, top_bottom]

if __name__ == "__main__":
    # Markaudio Pluvia 7.2 HD: 15,0 × 22,0 × 13,5 cm innen, 16 mm (1,6 cm) MDF
    boards = verify_flush_speaker_box(15.0, 22.0, 13.5, thickness_cm=1.6, top_between_sides=True)
    for b in boards:
        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:

| Aufgabenklasse | Risiko ohne Gegenprobe | Empfohlene Verifikations-Methode | Wann ein anderes Werkzeug überlegen ist |
| :--- | :--- | :--- | :--- |
| **Einfache Quader, Mengen & Umrechnungen im Alltag** | Vergessene Kantenabzüge (`2 × d`), Einheitenfehler, versteckte Annahmen im Fließtext | **Proof-Carrying Prompt:** Formel direkt in der Tabellenzeile + 3-Zeilen-Invarianten-Check am Ende | Ein dedizierter Online-Zuschnittrechner oder ein kurzes Tabellenkalkulations-Blatt ist bei Standardkisten schneller und fehlerfrei. |
| **Mehrteilige Zuschnitt- & Schachtelungspläne (Nesting)** | Sägeblattbreite (*Kerf*) fehlt, Platten überlappen sich zweidimensional | **Code-Execution (Python):** KI schreibt und startet ein Prüfskript mit `assert`-Invarianten | Ab 10+ Bauteilen oder Gehrungsschnitten sind echte CAD-Tools (FreeCAD, Fusion, OpenSCAD) und Zuschnitt-Optimierer zwingend vorzuziehen. |
| **Fehlerkorrektur nach falschem KI-Ergebnis** | *Autoregressive Anchoring:* KI verteidigt den Fehler und gibt dem Nutzer die Schuld | **Fresh-Context Falsifikation:** Ergebnis ohne den alten Chatverlauf in einem neuen Chat auf Fehler prüfen lassen | Selbst nachmessen und die Gegenprobe (`A + 2 × d = B`) mit dem Taschenrechner tippen dauert oft nur 15 Sekunden. |

## 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](https://arxiv.org/abs/2310.01798) – 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](https://arxiv.org/abs/2201.11903) – 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](https://arxiv.org/abs/2310.13548) – 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](https://arxiv.org/abs/2006.14779) – 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](/garden/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](/garden/3d-print-mcp).

---
*Quelle: [Lukas Kopischke – Digital Garden](https://lukiluki.me/garden/verifiable-ai) | Vollständiger Index: [llms.txt](https://lukiluki.me/llms.txt)*