Wenn KI-Daten sauber aussehen, aber falsch sind: Warum Schema-Checks allein nicht reichen

Stellen Sie sich vor, Ihr Web-Scraper liefert eine scheinbar perfekte Datenzeile: rating: 7 auf einer 5-Sterne-Plattform. Das JSON ist valide, der HTTP-Statuscode 200, die Selektoren unverändert. Doch die Bewertung von sieben Sternen existiert nicht – die KI hat sie erfunden. Dieses Szenario ist kein Einzelfall, sondern ein systematisches Problem beim Einsatz von Large Language Models (LLMs) zur Datenextraktion aus unstrukturiertem Text. Während klassische Scraper scheitern, wenn sich die Struktur einer Webseite ändert, versagen LLMs oft im Verborgenen: Sie liefern syntaktisch korrekte, aber semantisch falsche Daten – und passieren alle automatisierten Prüfungen, weil diese nur die Form, nicht den Inhalt validieren.

Warum strukturierte Ausgabe das Problem verschärft

Der Einsatz von strukturierten Ausgabeformaten wie response_format: json_schema soll die Zuverlässigkeit von KI-Extraktionen erhöhen. Doch in der Praxis führt dies oft zu einer Verschleierung von Unsicherheit. Modelle neigen dazu, fehlende oder unsichere Felder nicht als null oder leer zu belassen, sondern mit plausiblen, aber erfundenen Werten zu füllen – einfach, weil das Schema eine vollständige Struktur verlangt. Diese Tendenz wird durch die Architektur der LLMs verstärkt: Sie optimieren für Konsistenz in der Ausgabe, nicht für inhaltliche Korrektheit.

Dieses Verhalten lässt sich in zwei Kategorien unterteilen:

• Explizite Falschangaben: Das Modell erfindet Werte, die außerhalb des möglichen Wertebereichs liegen. Ein Beispiel ist eine Bewertung von sieben Sternen auf einer 5-Sterne-Skala oder ein zukünftiges Datum als Review-Tag.
• Implizite Falschdarstellungen: Das Modell leitet aus unscharfen Textpassagen falsche Schlussfolgerungen ab. Ein klassisches Beispiel ist die Markierung einer Bewertung als „verifiziert“, obwohl der Text keinerlei Hinweise darauf enthält.

Diese Fehler sind besonders tückisch, weil sie oft erst in nachgelagerten Prozessen auffallen – etwa wenn die falschen Daten in eine Datenbank geschrieben, für Analysen genutzt oder sogar als Grundlage für weitere KI-Antworten herangezogen werden. Ein Beispiel aus der Praxis: Ein Agent speicherte eine von einem LLM erfundene Information als Fakt ab, die später in weiteren Interaktionen wiederholt wurde – mit potenziell schwerwiegenden Folgen.

Die Grenzen automatisierter Prüfmechanismen

Automatisierte Tests wie Schema-Checks, HTTP-Statuscode-Prüfungen oder Selektor-Validierungen sind essenziell, um strukturelle Probleme zu erkennen. Sie decken jedoch nur einen Teil des Problems ab. Ein HTTP-Statuscode 200 bestätigt lediglich, dass die Seite erreichbar ist – nicht, dass die extrahierten Inhalte korrekt sind. Selbiges gilt für die Validierung des JSON-Formats: Ein syntaktisch korrektes Dokument kann inhaltlich wertlos sein.

Um semantische Fehler zu erkennen, sind manuelle oder regelbasierte Validierungen notwendig. Diese können umfassen:

• Wertebereichsprüfungen: Eine Bewertung muss zwischen 1 und 5 Sternen liegen. Jeder Wert außerhalb dieses Bereichs ist ein klares Indiz für eine Falschangabe.
• Konsistenzprüfungen: Die Anzahl der extrahierten Bewertungen muss mit der auf der Webseite angezeigten Anzahl übereinstimmen. Eine Differenz von mehreren hundert Bewertungen deutet auf einen Fehler hin.
• Kontextprüfungen: Die Sprache des Review-Textes muss mit der angegebenen Region übereinstimmen. Ein deutscher Text mit der Markierung „US“ ist ein Warnsignal.
• Zeitliche Plausibilität: Review-Daten dürfen nicht in der Zukunft liegen. Auch relative Angaben wie „vor drei Tagen“ müssen korrekt in ein absolutes Datum umgewandelt werden.

Diese Prüfungen sind jedoch nicht allumfassend. Sie können nur offensichtliche Regelverstöße erkennen – nicht jedoch plausible Lügen innerhalb des erlaubten Rahmens. Ein Beispiel: Ein Modell gibt eine Bewertung von vier Sternen an, obwohl die tatsächliche Bewertung bei zwei Sternen liegt. Solange der Wert innerhalb des Wertebereichs liegt, wird er nicht erkannt.

Praxiserfahrungen aus dem Echtbetrieb

In produktiven Umgebungen zeigen sich diese Fehler wiederholt, auch wenn sie nicht immer direkt sichtbar sind. Ein Beispiel aus dem Trustpilot-Scraping: Über 2.000 Scraping-Läufe ergaben keine systematischen Strukturprobleme, aber vereinzelte semantische Abweichungen. Die meisten dieser Fehler wurden erst bei manuellen Stichproben oder in nachgelagerten Analysen erkannt.

Die Herausforderung liegt darin, dass es keine standardisierten Metriken gibt, um die Häufigkeit solcher Fehler zu messen. Ohne kontrollierte Experimente oder detaillierte Logging-Mechanismen sind präzise Aussagen zur Fehlerquote kaum möglich. Dennoch lassen sich aus den beobachteten Mustern allgemeine Empfehlungen ableiten:

• Ergänzen Sie Ihre Validierungspipeline um regelbasierte Prüfungen, die über die reine Syntax hinausgehen.
• Nutzen Sie menschliche Überprüfungen für kritische Daten, insbesondere in Szenarien, in denen falsche Informationen schwerwiegende Folgen haben können.
• Vermeiden Sie die unkritische Übernahme von KI-generierten Daten in nachgelagerte Systeme. Eine zusätzliche Validierungsschicht kann hier Abhilfe schaffen.

Ein Blick in die Zukunft: Wie lassen sich semantische Fehler vermeiden?

Die Lösung liegt nicht in der Abschaffung strukturierter Ausgaben, sondern in der Ergänzung um inhaltliche Validierungsmechanismen. Modelle sollten nicht nur syntaktisch korrekte, sondern auch semantisch plausible Daten liefern. Dies erfordert:

• Hybride Validierungsansätze, die regelbasierte Prüfungen mit maschinellem Lernen kombinieren.
• Feedback-Schleifen, in denen menschliche Prüfer falsche Daten markieren und das Modell daraus lernt.
• Transparenz über Unsicherheiten, etwa durch die Angabe von Konfidenzwerten für extrahierte Felder.

Solange diese Mechanismen nicht flächendeckend implementiert sind, bleibt die Gefahr bestehen, dass sauber aussehende, aber falsche Daten unbemerkt in Systeme gelangen. Die Verantwortung liegt damit nicht nur bei den Entwicklern von KI-Systemen, sondern auch bei denjenigen, die deren Ausgaben nutzen – und hier besonders bei denjenigen, die automatisierte Prüfungen als ausreichend betrachten.

Die Lektion ist klar: Ein grünes Häkchen in Ihrem Monitoring-Dashboard garantiert keine korrekten Daten. Es ist nur der erste Schritt. Der zweite – und entscheidende – Schritt ist die Frage: Sind die Werte, die Sie extrahiert haben, wirklich wahr?