Warum die Wissenssuche nichts findet: vier Fehler unter dem Prompt

Eine Wissenssuche, die nichts findet, sieht genauso aus wie eine, die nichts weiß: der Agent antwortet freundlich und daneben. Die Versuchung ist dann groß, am Prompt zu drehen, weil das billig ist und sich nach Arbeit anfühlt. In den Fällen, die ich zuletzt auseinandergenommen habe, lag der Fehler jedes Mal eine Schicht tiefer — im Abruf, nicht in der Formulierung.

Erst messen, was zurückkam

Der erste Handgriff bei einer schlechten Antwort ist nicht, die Antwort zu lesen, sondern die Treffer. Also: Welche Textstücke hat die Suche geliefert, in welcher Reihenfolge, mit welchem Abstandswert? Das kostet eine Logzeile pro Abruf und entscheidet die Diagnose in einer Minute statt an einem Nachmittag.

Denn es gibt genau zwei Zustände, und sie brauchen entgegengesetzte Maßnahmen. Stand die richtige Passage unter den Treffern und wurde trotzdem nicht benutzt, ist es ein Formulierungs- oder Reihenfolgeproblem — dafür ist der Prompt zuständig. War sie nicht dabei, ist jede Prompt-Änderung verlorene Zeit, weil das Modell etwas verwenden soll, das es nie gesehen hat. Wer diesen Unterschied nicht misst, optimiert mit verbundenen Augen und hält den nächsten Zufallstreffer für einen Fortschritt.

Zeichen sind keine Token

Die häufigste stille Fehlerquelle beim Aufbau des Index ist eine Stapelgrenze, die in Zeichen gezählt wird, während das Einbettungsmodell in Token rechnet. Für glatten englischen Text geht die Daumenregel von etwa vier Zeichen pro Token meist auf. Für alles andere nicht: deutsche Komposita, Quellcode, Bezeichner mit Unterstrichen und vor allem Schriften ohne lateinische Buchstaben verschieben das Verhältnis deutlich. Ein Stapel, der die Zeichengrenze brav einhält, kann das Tokenfenster weit sprengen — und die Schnittstelle lehnt ihn ab oder schneidet ihn ab.

Dasselbe gilt für die zweite, meist völlig unbeachtete Grenze: die Anzahl der Eingaben pro Aufruf. Wer nur die Gesamtlänge deckelt, baut eine Pipeline, die bei vielen sehr kurzen Abschnitten in dieselbe Wand läuft. Beide Grenzen gehören explizit in den Code, und der Fehlerfall gehört getestet — nicht der Erfolgsfall, der funktioniert ohnehin. Sonst zeigt sich der Mangel nicht beim Entwickeln, sondern beim nächsten Import, der eine Nacht lang still die Hälfte der Dokumente überspringt und am Morgen als erledigt gemeldet wird.

Ohne Namensraum ist Ähnlichkeit nur Rauschen

Semantische Suche beantwortet die Frage "was klingt hier ähnlich" — nicht die Frage "was gehört hier dazu". In einem Wissensbestand mit mehreren Projekten sind das zwei verschiedene Dinge. Die Notiz aus dem Nachbarprojekt, in der dieselben Vokabeln stehen, ist semantisch ein hervorragender Treffer und fachlich grober Unfug.

Die Gegenmaßnahme ist unspektakulär: jedes Dokument bekommt beim Schreiben einen Bereich — Projekt, Mandant, Abteilung, Themenraum — und jede Abfrage filtert darauf, bevor sie Ähnlichkeit vergleicht. Das ist kein Feinschliff, sondern Fundament. Ich halte es inzwischen für wichtiger als die Wahl des Einbettungsmodells, und es ist erheblich billiger zu ändern. Wer es beim Aufbau weglässt, rüstet es später unter Schmerzen nach, weil die Herkunft der alten Einträge dann nicht mehr zuverlässig rekonstruierbar ist.

Drei Fragen, drei Werkzeuge

Der letzte Fehler ist einer der Denkgewohnheit: Suche als Antwort auf jede Frage. Es sind aber drei verschiedene Anliegen, und nur eines davon ist eine Suche.

• "Wo steht etwas zu X?" — das ist die Suche. Sie liefert Ausschnitte quer durch den Bestand, bewusst oberflächlich.
• "Was steht da genau?" — das ist ein Lesezugriff auf ein Dokument. Ein Ausschnitt mit drei Zeilen Kontext ist keine Grundlage für eine Zusammenfassung, und das Modell merkt den Unterschied nicht; es füllt die Lücke mit Plausibilität.
• "Was hängt damit zusammen?" — das sind die expliziten Verweise, die jemand gesetzt hat. Semantische Nachbarschaft ist dafür ein schlechter Ersatz: sie findet, was ähnlich formuliert ist, und nicht, was sachlich verknüpft wurde.

Bietet ein System nur das erste Werkzeug an, werden die anderen beiden Fragen trotzdem gestellt — und mit Ausschnitten beantwortet. Das ist die Klasse von Fehlern, die nie eine Fehlermeldung erzeugt. Die Antwort ist flüssig, gut formuliert und genau an den Stellen falsch, an denen der Ausschnitt endete.

Fazit

Eine Wissenssuche ist kein Modellproblem, sondern eine Lieferkette: Zerlegung, Einbettung, Filterung, Abruf — und erst am Ende der Prompt. Drei Dinge würde ich in jedem neuen Aufbau von Tag eins an mitnehmen: die Treffer mitprotokollieren, Grenzen in der Einheit zählen, in der sie gelten, und jedem Dokument einen Bereich geben. Das Unangenehme daran ist, dass keine dieser Maßnahmen nach Fortschritt aussieht. Das Angenehme ist, dass man danach weiß, warum eine Antwort falsch war, statt es zu vermuten.