Wie eine Maschine den richtigen Absatz findet

Ein Sprachmodell kennt das, was in seinen Trainingsdaten stand. Es kennt nicht Ihre Verträge, Ihre Akten oder die Korrespondenz des letzten Quartals. Die naheliegende Lösung — einfach alles in die Frage hineinkopieren — trägt nur erstaunlich kurz: Schon ein einzelner Dienstleistungsvertrag übersteigt das, was ein Modell auf einmal sinnvoll überblicken kann, und ein ganzes Archiv erst recht.

Also muss sich etwas vor das Modell stellen und für jede Frage entscheiden, welche Handvoll Absätze es lesen darf. Genau das meint „Retrieval“, und nahezu alles, was solche Systeme gut oder unbrauchbar macht, passiert dort — bevor das Modell ein einziges Wort erzeugt hat.

Zuerst wird das Dokument zerschnitten

Retrieval kann immer nur ein Stück zurückgeben, das es auch gibt. Der erste Schritt ist deshalb, Dokumente in Abschnitte zu schneiden — meist ein paar Sätze lang — und diese Schnitte sind keine Formsache. Eine Klausel, die auf einer Grenze liegt, besteht danach aus zwei Hälften, und keine der beiden beantwortet noch irgendetwas.

Schematisch, keine Messung. Hervorgehoben ist die Klausel, welche die Frage beantwortet. Der zweite Schnitt fällt mitten hinein, sie wird also zum Endstück des einen und zum Anfangsstück des nächsten Abschnitts — und eine Suche, die eines der beiden Stücke liefert, liefert etwas, das nichts beantwortet. Abschnittsgrenzen sind die unscheinbarste Entscheidung im ganzen System und eine der folgenreichsten.

Dann wird jedes Stück zu einer Position

Jeder Abschnitt läuft durch ein zweites, viel kleineres Modell — ein Embedding-Modell —, das ihn in eine Liste von Zahlen verwandelt. Hier sind es 384. Diese Liste ist eine Position in einem Raum mit 384 Achsen, und das Modell ist so trainiert, dass Text mit ähnlicher Bedeutung an ähnlichen Stellen landet. Nicht ähnlicher Wortlaut: ähnliche Bedeutung.

Das ist der Kniff, auf dem alles Weitere ruht. Bedeutung lässt sich schlecht durchsuchen. Geometrie lässt sich gut durchsuchen. Sobald jeder Absatz ein Punkt ist, wird aus „finde die passende Stelle“ ein „finde die nächstgelegenen Punkte“, und das ist Rechnen.

Die Frage ist ein Punkt im selben Raum

Eine Frage wird genauso eingebettet wie ein Abschnitt — dasselbe Modell, derselbe Raum. Dann nimmt das System die Abschnitte, deren Positionen ihr am nächsten liegen, und genau die darf das Modell lesen.

Die Abbildung unten tut das an einem fiktiven kommunalen Software-Dienstvertrag, zerlegt in 18 Klauseln. Wählen Sie eine Frage und sehen Sie, wo sie landet.

Fragen Sie den Vertrag:

Wählen Sie oben eine Frage, um zu sehen, welche Klauseln sie findet.

18 Klauseln eines fiktiven kommunalen Dienstvertrags, eingebettet mit paraphrase-multilingual-MiniLM-L12-v2 — 384 Dimensionen, einmal beim Erzeugen dieser Seite berechnet, es wird also nichts in Ihrem Browser geladen oder ausgeführt. Die Position ist eine PCA-Projektion der echten Embeddings auf zwei Achsen; diese beiden tragen 30% der Varianz, das Bild ist also ein flacher Schatten des tatsächlichen Raums, und zwei Punkte, die nah aussehen, müssen es nicht sein. Die Farbe ist die Abschnittsüberschrift, unter der die Klausel geschrieben wurde — eine Angabe, die das Modell nie gesehen hat, hier abgebildet, damit Sie seine Arbeit prüfen können. Die Rangfolge wird immer in allen 384 Dimensionen berechnet, nie aus den flachgedrückten Positionen — deshalb kann die Reihenfolge der hervorgehobenen Klauseln im Bild leicht durcheinander wirken.

Lesen Sie das Diagramm als Schatten, nicht als Landkarte. Zwei Achsen vertreten 384, die Farbgruppen verschwimmen auf dem Bildschirm also deutlich stärker ineinander als im Raum, in dem das Modell tatsächlich arbeitet — die Rangliste daneben ist die ehrliche Ansicht, denn ihre Zahlen stammen aus allen 384 Dimensionen. Wofür das Bild taugt: Es zeigt, dass eine Frage dieselbe Art von Objekt ist wie ein Absatz, im selben Raum, nah an manchem und fern von anderem.

Zwei Dinge darin lohnen den zweiten Blick.

Fragen Sie „Was passiert, wenn Kundendaten in falsche Hände geraten?“, und oben steht die Klausel über die Meldung einer Datenschutzverletzung binnen 24 Stunden. Die beiden teilen sich kein einziges Wort. Der Vertrag sagt nirgends „falsche Hände”, er sagt „Verletzung des Schutzes personenbezogener Daten“. Und selbst Kundendaten und Daten sind für eine Stichwortsuche zwei verschiedene Zeichenketten — das deutsche Kompositum trennt, was inhaltlich zusammengehört. Das Embedding findet die Stelle trotzdem, weil beide Formulierungen fast dasselbe bedeuten, und Bedeutungsnähe ist genau das, was dieser Raum abbildet.

Fragen Sie, wie schnell eine Rechnung zu begleichen ist, und es wird enger. Die richtige Klausel — Zahlung binnen 30 Tagen — steht mit 0,583 vorn. Aber auf Platz drei liegt mit 0,471 die Kündigungsfrist von drei Monaten: falscher Abschnitt, falsche Antwort, und trotzdem dicht dran. Fristen ähneln Fristen. Das ist der Normalzustand eines Retrieval-Systems, kein Sonderfall.

Der Wert weiß nicht, ob die Antwort da ist

Nun die vierte Frage: Wie viele Fristen im Vertrag sind kürzer als drei Monate?

Das Retrieval antwortet selbstbewusst. Sein bester Treffer erreicht 0,657 — mehr als die richtige Antwort auf die Rechnungsfrage erreicht hat. Und er ist nutzlos, denn in keiner einzelnen Klausel steht diese Antwort. Sie zu beantworten hieße, alle 18 zu lesen, jede Frist herauszusuchen, jede mit drei Monaten zu vergleichen und zu zählen. Retrieval ist dafür gebaut, die drei nächstgelegenen Absätze zu liefern. Es kann nicht zählen, und an einem hohen Wert ist das nicht zu erkennen.

Das ist das Wichtigste, was man über Ähnlichkeitssuche wissen muss: Der Wert misst, wie sehr ein Abschnitt der Frage ähnelt, nicht ob er die Antwort enthält. Ein System, das „bester Treffer über Schwellwert“ mit „wir haben, was wir brauchen“ verwechselt, reicht dem Modell drei plausible, unpassende Absätze und die Aufforderung zu antworten — und das Modell erfindet den Rest, gefällig wie es ist. Was das kostet und welche eine Regel das meiste davon abstellt, ist hier gemessen.

Ganze Klassen ganz gewöhnlicher betrieblicher Fragen haben diese Form. Wie viele Verträge laufen im dritten Quartal aus? Welcher Lieferant kommt am häufigsten vor? Hat sich diese Klausel seit der letzten Fassung geändert? Keine davon ist ein Retrieval-Problem, und alle kommen genau so daher wie eines.

Zwei Durchgänge, nicht einer

Das Mittel gegen die knappen Fehltreffer ist kein besseres Embedding-Modell. Es ist ein zweiter Durchgang.

Schematisch, keine Messung. Die erste Stufe vergleicht vorberechnete Positionen und kann ein ganzes Archiv in Millisekunden durchgehen — sie hat Frage und Klausel aber getrennt beurteilt, lange bevor die beiden einander begegnet sind. Die zweite Stufe liest sie zusammen, ein Paar nach dem anderen: viel zu langsam für alles, deutlich genauer auf einer engen Auswahl.

Warum die beiden Stufen sich in der Qualität unterscheiden, lohnt eine klare Formulierung. Im ersten Durchgang wurde die Klausel vor Monaten eingebettet, allein, ohne jede Ahnung, was man sie einmal fragen würde — verglichen werden zwei Zusammenfassungen, die nichts voneinander wussten. Ein Reranker liest Frage und Klausel gleichzeitig und kann deshalb bemerken, dass es beim Begleichen einer Rechnung um Zahlungsbedingungen geht und dass eine Kündigungsfrist eine Frist ganz anderer Art ist. Das ist der knappe Abstand von oben, aufgelöst.

Bezahlt wird das mit Zeit, und darum lässt niemand diese Stufe über das ganze Archiv laufen: erst billig und weit, dann teuer und eng.

Wo es in der Praxis schiefgeht

Die Fehlerbilder sind selten exotisch:

Grenzen. Eine Definition, die ein Schnitt zerteilt, eine Tabelle getrennt von ihrer Überschrift, eine Antwort, die den Satz davor braucht. Siehe die erste Abbildung.
Fragen, die zusammenfassen müssen. Zählen, vergleichen, „wie oft“, „welches ist das neueste“ — die Form aus der vierten Frage. Dafür braucht es Filter und strukturierte Abfragen, keine Vektoren.
Hauseigenes Vokabular. Ein allgemeines Embedding-Modell hat Ihre internen Kürzel nie gesehen und weiß nicht, dass „BV-34“ eine Betriebsvereinbarung ist. Es legt den Abschnitt irgendwohin und wird Ihnen darin nie widersprechen.
Komposita. Das Deutsche klebt seine Substantive zusammen. Kundendaten und Daten sind für einen Menschen ein Wortbestandteil auseinander und für einen Stichwortindex zwei unverwandte Zeichenketten — weshalb hybride Aufbauten, die auf Stichwortsuche setzen, im Deutschen echte Sorgfalt brauchen.
Zwei Sprachen. Eine deutsche Frage an ein englisches Dokument funktioniert nur, wenn das Embedding-Modell dafür trainiert wurde. Das Modell hinter der Abbildung oben ist es; die verbreiteten Standardmodelle sind rein englisch und scheitern daran lautlos.
Scans und Tabellen. Eine Zahl in einer Zelle verliert Zeilen- und Spaltenüberschrift in dem Moment, in dem die Tabelle zu einer Textzeile plattgedrückt wird, und eine gescannte Seite enthält überhaupt keinen Text, bevor ihn jemand erkannt hat.

Nichts davon löst sich, indem man ein größeres Sprachmodell wählt. Es löst sich, bevor das Sprachmodell überhaupt erreicht ist — darin, wie Dokumente geschnitten werden, was neben ihnen indexiert wird, welche Fragen am Retrieval vorbeigeleitet werden und was das System tut, wenn der beste Treffer schlicht nicht gut genug ist.

Das Letzte ist der Punkt, an dem Vertrauen entsteht oder verloren geht, und Gegenstand der nächsten Notiz.