Garbage in Garbage out

Wir beschäftigen uns gerade viel mit Retrieval, also damit, wie KI-Systeme in Dokumenten nachschlagen, und stellen fest: Wie gut so ein System wird, entscheidet sich zum größten Teil, bevor das Modell überhaupt beteiligt ist. Welches Modell man nimmt, ist trotzdem eine spannende Frage. Sie hängt nur an der anderen. Und dazwischen sitzt eine hartnäckige Annahme.

Pray, Mr. Babbage

Charles Babbage baute im 19. Jahrhundert an mechanischen Rechenmaschinen und schrieb 1864 in seinen Lebenserinnerungen eine Anekdote auf. Zwei Mal sei er von Abgeordneten gefragt worden, einmal aus dem Oberhaus, einmal aus dem Unterhaus, und beide Male fing die Frage gleich an: „Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?“ Sagen Sie mal, Herr Babbage, wenn man falsche Zahlen in die Maschine steckt, kommen dann die richtigen Antworten heraus? Babbage merkt dazu trocken an, er sei nicht in der Lage zu erfassen, welche Art von gedanklicher Verwirrung eine solche Frage überhaupt hervorrufen könne.

Ganz so verwirrt war die Frage allerdings nicht. 1864 gab es keine Vorstellung davon, was eine Rechenmaschine ist. Kein Vorbild, keine Erfahrung, nichts, woran man sich hätte orientieren können. Wer kein Modell von einer Sache hat, urteilt nach dem, was am plausibelsten wirkt, und plausibel war ein mechanischer Gehilfe, der mitdenkt und Fehler stillschweigend ausbügelt. Genau das ist der Teil der Geschichte, der heute noch trägt.

Die klügste Antwort auf diese Frage steht allerdings nicht bei Babbage. Ada Lovelace, Mathematikerin, übersetzte 1843 einen französischen Aufsatz über seine Analytical Engine und versah ihn mit eigenen Anmerkungen, die am Ende zwei Drittel der Veröffentlichung ausmachten. In der letzten dieser Anmerkungen warnt sie ausdrücklich vor übertriebenen Vorstellungen davon, was die Maschine könne. Sie erhebe keinen Anspruch darauf, etwas von sich aus hervorzubringen, sie tue, was man ihr zu befehlen wisse. Und dann der Satz, an dem ich hängen geblieben bin: „Its province is to assist us in making available what we are already acquainted with."

Ihr Gebiet ist es, uns dabei zu helfen, verfügbar zu machen, womit wir bereits vertraut sind. Das ist, hundertachtzig Jahre bevor jemand das Wort in diesem Sinn benutzte, eine ziemlich exakte Beschreibung dessen, was Retrieval tut. Und es steckt gleich die Grenze mit ab: Was nicht verfügbar gemacht wurde, kann auch nicht herausgeholt werden.

Rund neunzig Jahre später bekam dasselbe Prinzip in der frühen Computerbranche einen Namen. Garbage in, garbage out. Woher genau die Formulierung stammt, ist bis heute strittig, mal wird ein Zeitungsartikel von 1957 über Mathematiker der US Army genannt, mal ein IBM-Ausbilder, der sie seinen Kursteilnehmern eingebläut haben soll. Babbage taucht in diesen Geschichten nicht als Urheber auf, sondern als der, der das Problem lange vorher beschrieben hatte.

Das Erstaunliche ist, dass die Frage der beiden Abgeordneten nie ganz verschwunden ist. Sie hat nur die Maschine gewechselt. Wer heute ein KI-System mit eigenen Dokumenten füttert, bekommt von allen Seiten suggeriert, dass sich das damit erledigt hat. Die Modelle sind ja so klug, die sortieren das schon. Und anders als bei Babbages Zahnrädern klingt das sogar plausibel, weil die Systeme sprachlich tatsächlich verblüffend sicher wirken.

Ein Werkzeug, das alles kann, verkauft sich schlicht besser als eines, dessen Grenzen im Datenblatt stehen.

Alleskönner, sagt die Werbung

Woher die Annahme kommt, ist kein Rätsel. Die Firmen hinter den großen Modellen vermarkten sie als Alleskönner, und aus ihrer Sicht ist das völlig nachvollziehbar. Ein Werkzeug, das alles kann, verkauft sich schlicht besser als eines, dessen Grenzen im Datenblatt stehen.

Dazu kommt die tägliche Erfahrung, und die bestätigt die Botschaft. Wer ChatGPT benutzt wie früher Google, bekommt beeindruckend gute Antworten. Nur beantwortet das Modell dabei aus dem, was es beim Training gesehen hat, aus einem Weltwissen von unfassbarem Umfang. Eine Assistenz, die ausschließlich aus 13 Dokumenten einer Kommune antworten soll, ist eine andere Maschine mit einer anderen Aufgabe. Sie darf genau das nicht tun, was das Modell im Alltag so souverän wirken lässt.

Diese Erwartung sitzt fest, bevor jemand das erste Mal etwas eintippt. Mein Kollege Ben hat das an anderer Stelle ausführlicher beschrieben, mit Rückgriff auf die Akzeptanzforschung: Nutzer bilden ihre Haltung gegenüber einem System bereits vor der ersten Interaktion.

In Projekten begegnet uns das regelmäßig. Wenn eine spezialisierte Assistenz bei einer Detailfrage passt oder vorsichtig antwortet, ist die Verwunderung groß, und im ungünstigen Fall richtet sie sich gegen uns. Das kann doch ChatGPT auch. Kann es, nur eben nicht aus diesen Dokumenten und nicht mit der Verbindlichkeit, die eine Behörde braucht.

Es lohnt sich, das früh anzusprechen, statt zu hoffen, dass es niemandem auffällt. Und es hilft zu erklären, was beim Nachschlagen in Dokumenten tatsächlich passiert. Das ist nämlich etwas ganz anderes, als die meisten vermuten.

Man erkennt ein Wort an seiner Gesellschaft

Kurzer Umweg in die Linguistik. 1957 formulierte der britische Sprachwissenschaftler John Rupert Firth einen Satz, der heute in fast jedem NLP-Lehrbuch steht: Man erkenne ein Wort an der Gesellschaft, die es hält. Wörter, die in ähnlichen Zusammenhängen auftauchen, haben ähnliche Bedeutungen.

Randbemerkung, weil sie mir gefällt: Die eigentliche Argumentation dazu hatte der Amerikaner Zellig Harris schon 1954 vorgelegt, mit deutlich mehr Formalismus. Firth hatte den zitierfähigeren Satz. Man ahnt, wer heute in den Fußnoten steht.

Diese Idee, die Distributionshypothese, ist das Fundament dessen, was heute Embedding heißt. Ein Text wird in eine lange Zahlenreihe übersetzt, die seine Bedeutung ungefähr abbildet. Die Vorstellung, die dabei hilft, ist eine Landkarte: Jeder Textabschnitt bekommt einen Punkt, inhaltlich Verwandtes liegt nah beieinander, ganz gleich, aus welcher Datei es ursprünglich stammt. Stellt jemand eine Frage, wird auch die Frage zu einem Punkt auf dieser Karte, und das System holt sich, was in der Nachbarschaft liegt.

Die echte Karte hat übrigens nicht zwei Dimensionen, sondern einige hundert. Für die Vorstellung ändert das nichts. Für das Gefühl, wie viel Platz da drin ist, schon.

Vorher muss allerdings noch etwas passieren, und dieser Schritt wird in Erklärungen gerne übersprungen: Die Dokumente werden zerlegt. In Abschnitte von ein paar Sätzen, Chunks genannt, weil die Karte nicht mit ganzen Dokumenten arbeitet, sondern mit Teilen. Wo genau geschnitten wird, entscheidet eine Pipeline, nicht ein Mensch.

Wo es kippt

Und hier fällt der Annahme in sich zusammen. Nicht, weil die Modelle schlecht wären, sondern weil die Karte nur so gut sein kann wie die Punkte darauf.

Ein Schnitt mitten im Satz oder mitten durch eine Tabelle erzeugt ein Fragment, das für sich genommen nichts bedeutet. Gefunden werden kann es trotzdem.

Dann die Sache mit der Gültigkeit. Eine alte und eine neue Gebührenordnung liegen als Nachbarn nebeneinander, die Frage nach der Gebühr trifft beide, und welche davon noch gilt, steht nirgends auf der Karte. Sie kennt Ähnlichkeit, nicht Gültigkeit.

Fast noch unangenehmer ist der verlorene Kontext. Die Einschränkung, dass eine Regelung nur für ein bestimmtes Gebiet gilt, steht oft einen Absatz weiter oben und fällt beim Zerschneiden weg. Übrig bleibt ein Satz, der isoliert schlicht falsch ist.

Und dann die Redundanz: Zwölf Dateien mit derselben Aussage in leichten Varianten füllen mit ihren Abschnitten gemeinsam die Trefferliste. Die eine gute Antwort hängt derweil auf Platz vierzehn.

Keiner dieser vier Fälle ist ein Modellproblem. Alle vier entstehen, bevor das Modell überhaupt beteiligt ist.

Die Reihenfolge umdrehen

Der übliche Ablauf sieht so aus, dass jemand hochlädt, was da ist, und danach versucht wird, die Unordnung technisch aufzufangen. Über Chunking-Strategien, über die Auswahl des Embedding-Modells, vor allem aber über den Prompt oder eben ein sehr "mächtiges" Modell. Dieses Kontrukt wird dann zum Auffangnetz für alles, was die Datenbasis nicht hergibt, muss Widersprüche moderieren und Lücken kaschieren, und wird mit jeder Runde komplexer.

Wir haben das in einem Projekt zu einer kommunalen Assistenz umgedreht und die intensive Aufbereitung vor das System gezogen. 13 gewachsene Dokumente, Konzeptpapiere, FAQ-Listen, Schreiben von Beiräten, technische Regelwerke, alles in unterschiedlicher Tiefe und Aktualität. Statt sie so wie sie waren ins Embedding zu geben, haben wir sie erst gesichtet, und zwar zusammen mit einem Coding-Agent, der sowohl das Embedding-Verfahren als auch den späteren Einsatzzweck kennt. Daraus entstand ein Verarbeitungs-Prompt, der die inhaltliche Aufbereitung durch ein Modell mit großem Kontextfenster gesteuert hat.

Herausgekommen ist eine gegliederte Wissensbasis. Ein Kernhandbuch mit 52 aufbereiteten FAQ, eine technische Referenz, ein Nachschlagewerk für Zuständigkeiten und Anträge, ein separater Block für ortsspezifische Fakten. Und, sehr spannender "Beifang", eine Liste aller Widersprüche und Lücken, die dabei aufgefallen sind.

Diese Liste ist der eigentliche Fund. Widersprüche, die in einer über Jahre gewachsenen Sammlung längst niemandem mehr auffallen, werden durch die strukturierte Aufbereitung sichtbar. Man kann sie klären, solange noch jemand weiß, welche Fassung gilt. Ohne diesen Schritt kommen sie später als merkwürdige Antworten wieder heraus, und dann sucht man den Fehler im Prompt.

Möglicher Nebeneffekt: Wenn die Basis sauber ist, darf der Prompt wieder einfach werden. Er muss weniger Ausnahmen abfangen und wird dadurch stabiler.

Grob, dann genau

Inzwischen läuft in dem Projekt noch ein zweiter Schritt. Die Suche auf der Landkarte ist schnell, aber grob, weil sie nur Positionen vergleicht und nicht den Text selbst liest. Ein sogenannter Reranker liest die Frage und jeden Kandidaten noch einmal richtig und sortiert danach, was tatsächlich passt.

Das ist genauer aber teurer, weshalb man es nicht über den ganzen Bestand laufen lässt. Die Kartensuche liefert eine großzügige Vorauswahl, erst die geht durch den Reranker. Wer schon einmal in einer Poststelle stand, kennt das Prinzip: erst grob in Bahnen, dann von Hand.

Nicht jedes Nachschlagen braucht eine Landkarte

Noch eine Erkenntnis aus einem anderen Projekt: Dort steht neben der semantischen Suche auch ein Tool bereit, das direkt eine strukturierte Datenbank abfragt. Der Blick in die Logs war eindeutig. Sobald der Scope einer Anwendung eng genug ist, greift das Modell fast nur noch zum Datenbank-Tool. Eine präzise Abfrage schlägt die freie Ähnlichkeitssuche, sobald man weiß, wonach gefragt wird.

Das ist keine Absage an Vector-Datenbanken. Es ist eine Erinnerung daran, dass die Landkarte eine von mehreren Antworten ist, neben Graph-Strukturen, klassischen Abfragen und gezielten Tools. Welche trägt, hängt davon ab, wie eng der Scope ist und in welcher Form die Daten überhaupt vorliegen.

Und wenn sich die Fakten ändern?

Der offensichtliche Einwand. Eine aufbereitete Wissensbasis ist kein Denkmal. Gebühren steigen, Zuständigkeiten wandern, Fristen laufen ab, und irgendwann steht in der schön strukturierten Datei etwas, das nicht mehr stimmt.

Ein Teil der Antwort ist eine Trennung, die schon bei der Aufbereitung gezogen wird. Was sich häufig ändert, gehört gar nicht erst auf die Karte. Termine, Gebühren, aktuelle Stände kommen besser zur Laufzeit aus einer Datenbank, wo genau ein Wert gepflegt wird statt fünf Kopien in vier Dokumenten. Was übrig bleibt, ist der stabile Teil, und der ist meist kleiner als gedacht.

Für alles andere denken wir gerade in Richtung einer agentischen Struktur, die im Moment des Hochladens im Kleinen wiederholt, was am Anfang im Großen passiert ist: die neue Information auswerten, das Relevante extrahieren, es dem Bestand gegenüberstellen und an der passenden Stelle ergänzen oder ersetzen. Der spannende Teil daran ist nicht das Ergänzen, sondern der Abgleich, denn genau dort tauchen Widersprüche auf, solange sie noch klärbar sind.

Fertig gedacht ist das nicht. Die offene Frage ist, wo der Mensch bleibt. Vollautomatisch widerspricht dem ganzen Ansatz. Jede Änderung einzeln freigeben zu lassen scheitert an dem, woran es in Fachabteilungen ohnehin scheitert, nämlich an der Zeit. Vermutlich liegt die Antwort dazwischen: Automatik für Ergänzungen, Freigabe genau dann, wenn der Abgleich einen Konflikt findet.

Wovon das Modell abhängt

Jetzt doch noch zum Modell, denn hier wird es interessant.

Der Reflex bei KI-Projekten geht zum größten verfügbaren Modell. Verständlich, die großen Modelle der Spitzenklasse, in der Branche Frontier-Modelle genannt, können erstaunlich viel. Für eine Assistenz, die Fragen zu einem klar umrissenen kommunalen Thema beantwortet, sind sie allerdings maßlos überdimensioniert. Man kauft dabei die Fähigkeit mit ein, japanische Lyrik zu übersetzen und C++ zu debuggen, und bezahlt sie bei jeder einzelnen Anfrage mit.

Der Preis ist nicht nur Geld. Die stärksten dieser Modelle sind geschlossen, man kann sie gar nicht selbst betreiben. Sie laufen beim Anbieter, und damit verlässt jede Anfrage samt der mitgeschickten Dokumentabschnitte das eigene Haus. In öffentlichen und regulierten Kontexten ist genau das die Frage, an der Projekte hängenbleiben, lange bevor jemand über Antwortqualität spricht. Dazu kommt der Energieverbrauch, über den man auch dann reden sollte, wenn ihn niemand auf der Rechnung sieht.

Deswegen ist die spannendere Richtung gerade nicht das nächstgrößere Modell, sondern das kleinstmögliche, das die Aufgabe noch beherrscht. Small Language Models, die auf eigener Hardware laufen, deren Kosten kalkulierbar sind und bei denen die Daten dort bleiben, wo sie hingehören.

Und jetzt schließt sich der Kreis. Dass ein großes Modell schlechte Datenaufbereitung noch ein Stück weit überspielt, klingt erst mal nach einem Vorteil. Es ist aber vor allem eine Versicherung gegen den eigenen Datenbestand, und die wird bei jeder einzelnen Anfrage neu bezahlt.

Dreht man es um, wird die Rechnung deutlich besser. Klar umrissene Aufgabe, saubere Wissensbasis, und dann reicht ein Modell, das einen Bruchteil der Ressourcen braucht. Antworten kommen schneller, weil weniger gerechnet wird. Die Kosten pro Anfrage sind kalkulierbar, statt an einer Preisliste zu hängen, die jemand anders schreibt. Der Betrieb könnte sogar teilweise auf eigener Hardware laufen, die Daten bleiben im Haus, und niemand muss erklären, warum Anfragen von Bürger:innen über einen Server in einem anderen Rechtsraum laufen.

Der Aufwand verschwindet dabei nicht, er wandert nur. Weg aus dem laufenden Betrieb, hin an den Anfang. Einmal gründlich aufbereiten kostet Zeit, aber es kostet sie ein einziges Mal, und danach wird jede Anfrage billiger, schneller und nachvollziehbarer.

Diesen Zusammenhang halte ich für unterschätzt. Datenqualifizierung wird meist als Frage besserer Antworten diskutiert. Sie entscheidet aber genauso darüber, wie klein, wie günstig, wie datensparsam und wie eigenständig betreibbar ein System am Ende sein kann. Wer die Basis in Ordnung bringt, kauft sich damit die Freiheit, auf die ganz große Maschine zu verzichten.

Fazit

Babbages Abgeordnete stellten ihre Frage einer Maschine aus Zahnrädern. Die Maschine hat sich seither ziemlich verändert, die Frage nicht. Sie klingt heute nur eleganter, weil das System zurückreden kann.

Garbage in, garbage out gilt also weiterhin. Nur bedeutet Garbage in diesen Projekten fast nie Datenmüll. Es sind Dokumente, die inhaltlich völlig in Ordnung sind, geschrieben für Menschen, die den Kontext ohnehin kennen. Sie sind nur nie für eine Maschine aufbereitet worden, die genau diesen Kontext nicht hat.

Das lässt sich beheben, und Lovelace hat vor hundertachtzig Jahren aufgeschrieben, worin die Arbeit besteht. Verfügbar machen, womit wir bereits vertraut sind. Der schwierige Teil steckt bis heute im Verfügbarmachen, nicht in der Maschine. Und je sorgfältiger man es tut, desto weniger Maschine braucht man danach.

KI hat beim Schreiben dieses Artikels unterstützt