Die geerbte Halluzination

Kapitel 4 — Die geerbte Halluzination

Dies ist vielleicht die lehrreichste Geschichte der gesamten Untersuchung, da sie ein Thema berührt, das in Tutorials ignoriert wird und das dennoch mehr Schaden anrichtet als alle anderen zusammen: die Qualität der eingehenden Daten.

Ein amerikanisches Fahrradunternehmen – nennen wir es so aus Respekt – verfügte über ein riesiges Fotoarchiv, Tausende von Produktbildern, Veranstaltungen, Kunden auf Fahrrädern, Werbereisen. Es war das visuelle Erbe des Unternehmens, das in fünfzehn Jahren Kampagnen angesammelt wurde. In einem Moment der Weitsicht hatte jemand einen automatischen Tagging-Dienst verwendet, um jeder Fotografie eine Liste von „vorhandenen Objekten“ hinzuzufügen: „Fahrrad, Helm, Straße, Berg, Person“. Metadaten, die theoretisch für die zukünftige visuelle Suche nützlich sind. Neben den Fotos gespeichert, jahrelang vergessen, dann wiedergefunden und in das neue Unternehmens-RAG eingespeist, mit der natürlichen Überzeugung, dass „mehr Metadaten besser sind“.

Nach der Aufnahme lieferte die Bildersuche surreale Ergebnisse. Suchte man nach "Fahrrad in der Stadt" erschien ein Foto von einem See. Suchte man nach "Model mit Helm" erschien ein Oldtimer. Suchte man nach "Berg" erschien alles Mögliche – eine zufällige Stichprobe aus dem gesamten Archiv, als ob das System ein Los gezogen hätte. Das Team deutete zunächst das visuelle Embedding-Modell als Ursache an. Dann den Re-Ranker (siehe vorheriges Kapitel, um zu verstehen, warum diese Spur besonders verlockend war). Dann die Qualität der von der KI generierten Beschreibungen.

Die eigentliche Untersuchung, diesmal mit einer direkten query SQL an die Datenbank durchgeführt, zeigte etwas groteskes. Von 3997 Katalogfotos hatten alle, wirklich alle, die exakt gleiche Liste von Objekten. Eine Liste von neunzehn Elementen — "Auto, Motorrad, See, Meer, Berg, Fahrrad, Helm, Straße, Stadt, Person..." — die keinerlei Bezug zum Inhalt des jeweiligen Fotos hatte. Sie war vor Jahren von einer anderen Website importiert worden, als Satz generischer Tags, um ein obligatorisches Feld des CMS zu füllen. Niemand im Unternehmen erinnerte sich mehr daran. Die Fotos wurden von System zu System weitergegeben und trugen diese Geisteretiketten mit sich, plausibel genug, um keinen Verdacht zu erwecken, giftig genug, um jede darauf basierende Suche zu korrumpieren. Die Suchmaschine nutzte sie fleißig als Symptom für Inhalte. Und gab für jede Anfrage jedes Foto zurück, mit einem gewissen Grad an Halluzination, der durch das Naturgesetz garantiert wurde.

Der Knackpunkt, der wehtut, wenn man ihn versteht, ist, dass "verrauschte" Daten in einem RAG kein hörbares Rauschen verursachen. Sie verlangsamen das System nicht, erzeugen keine Fehler und lassen keine Warnleuchten aufleuchten. Sie untergraben lediglich still und leise die Qualität der Ergebnisse. Und wenn das nachgelagerte Sprachmodell fünf Dokumente erhält, von denen vier nicht zum Thema passen, sagt es nicht "diese sind irrelevant, frag mich etwas anderes": Es erstellt sorgfältig eine Antwort, die diese mischt, und die Antwort klingt immer plausibel. Immer. Die finale –Halluzination–, diese erfundene Antwort, über die wir uns beklagen, entsteht nicht im Modell, wie es in der vorherrschenden Erzählung dargestellt wird. Sie entsteht vorher in den Daten. Das Modell ist nur derjenige, der sie in einen grammatikalisch einwandfreien Satz verpackt. Aber die Schuld liegt woanders, weiter zurück, in dem, was Sie dem System Monate bevor Sie ihm etwas fragten, zu essen gegeben haben.

Diese Beobachtung hat praktische Konsequenzen, die Geld kosten. Die erste Aufgabe beim Aufbau eines seriösen Enterprise-RAG ist es, bevor man eine einzige Zeile Code schreibt, eine Autopsie der eigenen Daten durchzuführen. Woher stammen sie. Wer hat sie berührt. Welche Felder werden beobachtet und welche sind fossile Überreste früherer Systeme. Welche Metadaten haben heute eine Bedeutung und welche hatten sie 2017, ohne dass sich jemals jemand die Mühe gemacht hat, sie zu bereinigen. Es ist eine wenig glamouröse, sehr archivorientierte Arbeit, die in Tutorials völlig fehlt, oft als "nicht-technisch" wahrgenommen und daher von den Entwicklungsteams ignoriert wird. Aber ohne diese anfängliche Hygiene wird jede noch so geniale Architektur einfach zu einem sehr leistungsstarken Verstärker für sehr alten Müll.

Im Fall des amerikanischen Unternehmens war die Lösung brutal und richtig: Das Feld "Objekte" leeren, die Metadaten von Grund auf mit einem modernen Bilderkennungsmodell neu erstellen, das auf jedes einzelne Foto angewendet wird, und diesmal erfassen, wann und wie jedes Metadatum erstellt wurde. Langweilige Arbeit. Ergebnis: Die Suche begann endlich zu funktionieren. Nicht, weil sie das Modell geändert hatten. Weil sie im Keller aufgeräumt hatten.