---
title: "Warum ein Sprachmodell keine Datenbank ist"
source: https://bitvaria.com/keine-datenbank
---

27\. Aug. 2026 · Daniel Schleipfer · [KI](https://bitvaria.com/category/ki/)  · 5 min read

# Warum ein Sprachmodell keine Datenbank ist

Eine Extraktion liest zuverlässig Werte aus Verträgen, bis ein Feld einmal fehlt. Dieselbe Anfrage liefert trotzdem eine Zahl, sauber formatiert, nur erfunden. Warum ein Sprachmodell keine Datenbank ist und was das für die Prüfung bedeutet.

![Eine Extraktion liest zuverlässig Werte aus Verträgen, bis ein Feld einmal fehlt. Dieselbe Anfrage liefert trotzdem eine Zahl, sauber formatiert, nur erfunden. Warum ein Sprachmodell keine Datenbank ist und was das für die Prüfung bedeutet.](https://bitvaria.com/_astro/keine-datenbank.NEfw5zCf.jpg)

> **Warum liefert ein Sprachmodell nicht immer die geforderte Antwortform?**
> 
> Weil kein interner Schritt die Ausgabe gegen ein Schema prüft. Das Modell erzeugt Token für Token das statistisch plausibelste nächste Wort, auch wenn das Ergebnis nicht der erwarteten Struktur entspricht.

Eine Extraktion liest aus Verträgen das Zahlungsziel aus. Bei den meisten Dokumenten stimmt die Zahl. Ein Vertrag hat aber keine eigene Klausel dazu. Dieselbe Anfrage liefert trotzdem eine Zahl. Sauber formatiert, in der erwarteten Form. Nur erfunden. Niemand hat das geprüft. Die Antwort sah aus wie immer.

## Eine Antwort ist noch keine geprüfte Antwort

Eine Datenbank-Abfrage liefert eine geprüfte Zeile oder einen Fehler. Diesen zweiten Fall kennt ein Sprachmodell nicht. Es setzt den Text bei jeder Anfrage [Wort für Wort fort](https://bitvaria.com/sampling), immer mit dem plausibelsten nächsten Wort. Fehlt eine Information im Text, macht das für das Modell keinen Unterschied. “Steht da” und “klingt plausibel” erzeugen denselben nächsten Schritt. Deshalb kommt fast immer eine Antwort in der erwarteten Form zurück. Geprüft ist damit noch nichts.

Diese Sichtweise hat einen Namen: das Modell als unzuverlässige Funktion.

Die Serie, und wo dieser Begriff sitzt

Dieser Begriff sitzt bei "Mental Models" in der Gruppe "Die Maschine".

## Für die Technik-Tiefe

Der Blick unter die Haube zeigt, warum das so ist. Ein Sprachmodell hat keinen eingebauten Prüfschritt gegen die Realität. Bei jedem Wort erzeugt es eine Wahrscheinlichkeitsverteilung über das gesamte Vokabular und zieht daraus [das nächste Token](https://bitvaria.com/sampling), unabhängig davon, ob das gewählte Token durch den Kontext belegt ist oder nur zum Muster passt. Aus diesem einen Mechanismus folgen fünf beobachtbare Fehlerklassen:

-   **Falscher Typ:** Statt der geforderten drei Werte kommt ein ganzer Satz, weil kein interner Schritt die Ausgabe gegen ein Schema prüft.
-   **Halluzination:** Das Modell setzt einen erfundenen, aber stimmig klingenden Fakt fort, weil “stimmig” und “belegt” für die Token-Erzeugung dasselbe Signal sind.
-   **Ignorierte Anweisung:** Eine Systemvorgabe verliert gegen ein Muster, das im übrigen Kontext stärker vertreten ist.
-   **Preisgabe der eigenen Anweisung:** Es gibt keine harte Grenze zwischen Anweisung und Text. Beides sind Tokens im selben Kontextfenster.
-   **Nichtdeterminismus:** Selbst bei [Temperature 0](https://bitvaria.com/sampling) bleibt die Ausgabe nur nahezu deterministisch, durch Rundung in der Fließkomma-Arithmetik und Batching auf der GPU.

Jede dieser fünf Klassen ist eine direkte Folge davon, wie Token-Erzeugung funktioniert, kein behebbarer Einzelfehler.

## Wenn die Prüfung fehlt

Zwei der fünf Fehlerklassen oben haben in der Produktion einen eigenen Namen und eine eigene Verteidigung. Ein falscher Typ zählt als fehlerhafte JSON-Ausgabe, ihre Verteidigung ist eine Kombination aus Constrained Decoding, Schema-Validierung, einem Reparatur-Durchlauf und einer Fallback-Kette. Ein halluzinierter Werkzeug-Aufruf zählt als schwacher Vertrag, seine Verteidigung sind geprüfte Tool-Verträge mit Argument-Validierung und Idempotenz. Beide Themen sind eigene Kapitel dieser Serie.

Für deutsche Mittelstandsprojekte kommt eine praktische Konsequenz dazu. Eine erfundene Zahl in einem internen Entwurf ist ärgerlich. Dieselbe erfundene Zahl in einem Feld, das in ein Buchhaltungs- oder Vertragssystem einfließt, wird zu einer Aussage mit Beleg-Anspruch, ganz ohne echten Beleg. Revisionssicherheit verlangt, dass ein Wert im System auf seine Quelle zurückführbar ist. Ein unvalidierter Modell-Aufruf erfüllt das nicht, egal wie sauber die Ausgabe formatiert ist.

Die Abhilfe ist nicht ein längerer oder höflicherer Prompt. Sie ist eine Prüfung außerhalb des Modells: ein Schema, das die Form erzwingt, ein Abgleich, der den Wert gegen die Quelle im Dokument hält, und bei Feldern mit echtem Gewicht ein Mensch, der die auffälligen Fälle sieht, bevor sie weiterlaufen.

* * *

**Eine Datenbank liefert eine geprüfte Zeile oder einen Fehler. Ein Sprachmodell liefert fast immer eine Antwort in der erwarteten Form. Geprüft ist sie damit noch nicht.**

Nächster Begriff: **Continuous Batching**. Wie eine GPU neue Anfragen mitten im Lauf aufnimmt, statt auf ein volles Batch zu warten.

## Häufige Fragen

**Warum liefert ein Sprachmodell nicht immer die geforderte Antwortform?** Weil kein interner Schritt die Ausgabe gegen ein Schema prüft. Das Modell erzeugt Token für Token das statistisch plausibelste nächste Wort, auch wenn das Ergebnis nicht der erwarteten Struktur entspricht.

**Was ist eine Halluzination bei einem Sprachmodell?** Eine Antwort, die plausibel klingt, aber durch keine Quelle im Kontext oder in den Trainingsdaten belegt ist. Für die Token-Erzeugung fühlt sich ein erfundener Fakt genauso an wie ein belegter.

**Warum kann ein Sprachmodell die eigene Systemanweisung preisgeben?** Weil es keine harte Grenze zwischen Anweisung und übrigem Text gibt. Beides liegt als Tokens im selben Kontextfenster.

**Wie prüft man die Antwort eines Sprachmodells zuverlässig?** Außerhalb des Modells: ein Schema, das die Form erzwingt, ein Abgleich gegen die Quelle im Dokument, und bei Feldern mit echtem Gewicht ein Mensch, der auffällige Fälle vor der Weiterverarbeitung sieht.

* * *

*Teil der Serie [AI-Engineering-Begriffe erklärt](https://bitvaria.com/ai-engineering-begriffe). Verwandt: [Warum ein Modell auf dieselbe Frage fast nie zweimal dieselbe Antwort gibt](https://bitvaria.com/sampling) (Sampling) und [Was ist ein Token?](https://bitvaria.com/was-ist-ein-token) (Tokenisierung)*

-   [ki](https://bitvaria.com/tag/ki/)
-   [ai-engineering](https://bitvaria.com/tag/ai-engineering/)
-   [llm](https://bitvaria.com/tag/llm/)
-   [halluzination](https://bitvaria.com/tag/halluzination/)
-   [mental-models](https://bitvaria.com/tag/mental-models/)

Share:

[Back to Blog](https://bitvaria.com/blog/)

## Erklärte Begriffe

- **Halluzination**: Eine Antwort, die plausibel klingt, aber durch keine Quelle im Kontext oder in den Trainingsdaten belegt ist.
- **Preisgabe der eigenen Anweisung**: Prompt Leakage. Das Modell gibt Teile seiner eigenen Systemanweisung preis, wenn geschickt danach gefragt wird.