Nicht jede Suche braucht ein LLM

Die Frage hinter der Frage

Kaum ein Gespräch über das eigene Wissen kommt heute ohne die Frage aus, wie man ein LLM daran anbindet. Die Dokumentation soll durchsuchbar werden, der Support soll schneller Antworten finden, und Kundinnen sollen im Produkt eine Frage stellen können, statt sich durch Menüs zu klicken. Das ist ein berechtigter Wunsch, und große Sprachmodelle sind beeindruckende Werkzeuge.

Sobald es konkret wird, tauchen allerdings dieselben Fragen auf. Was kostet jede einzelne Anfrage, wenn sie über eine externe API läuft? Wie lange wartet jemand auf die Antwort? Dürfen die Fragen unserer Nutzer und die Inhalte unseres Wissens überhaupt zu einem fremden Anbieter? Und was passiert, wenn das Modell eine Antwort erfindet, die plausibel klingt, aber in keinem unserer Texte steht?

Diese Fragen verschwinden oft, wenn man das eigentliche Ziel genauer ansieht. In vielen Fällen will niemand einen Text generieren lassen, sondern die richtige Stelle im vorhandenen Wissen finden. Das ist eine Suchaufgabe, und für Suchaufgaben gibt es Werkzeuge, die deutlich kleiner, schneller und günstiger sind als ein großes Sprachmodell.

LLM, SLM, RAG und Embeddings kurz eingeordnet

Ein LLM, also ein Large Language Model, ist ein Sprachmodell mit Milliarden von Parametern, das Text versteht und neuen Text erzeugt. Es läuft meist bei einem Anbieter auf Grafikkarten, weil es für den Betrieb auf einem gewöhnlichen Server zu groß ist. Ein SLM, ein Small Language Model, arbeitet nach demselben Prinzip, ist aber so klein, dass es auf eigener Hardware oder sogar auf einem Laptop läuft. Dafür ist es weniger vielseitig und macht bei schwierigen Aufgaben schneller Fehler.

RAG steht für Retrieval-Augmented Generation und beschreibt kein Modell, sondern ein Muster. Bevor das Sprachmodell antwortet, sucht ein System die passenden Stellen aus dem eigenen Wissen heraus und legt sie dem Modell als Grundlage vor, sodass es nicht aus dem Gedächtnis antwortet, sondern aus deinen Texten. Der entscheidende Teil von RAG ist damit die Suche davor, denn das Modell kann nur so gut antworten, wie die gefundenen Stellen passen.

Embeddings sind genau das Werkzeug für diese Suche. Ein Embedding-Modell erzeugt keinen Text, sondern übersetzt einen Text in eine Liste von Zahlen, die seine Bedeutung beschreibt. Solche Modelle sind um Größenordnungen kleiner als ein LLM. Daraus folgt eine nüchterne Einsicht: Wer vor allem finden will, braucht oft nur den ersten Schritt von RAG und gar kein Sprachmodell, das am Ende formuliert.

Stufe eins: Schlagworte und Index

Die leichteste Form der Suche kennt jeder. Man zerlegt Überschriften, Zusammenfassungen und Fließtext in einzelne Wörter, entfernt Füllwörter wie „und" oder „der" und merkt sich in einem Index, in welchem Dokument welches Wort wie oft vorkommt. Ein bewährtes Verfahren wie BM25 gewichtet dabei seltene Wörter stärker als häufige, weil „DNS" mehr über einen Text verrät als „Server".

Ein solcher Index für ein paar hundert Seiten belegt nur einen winzigen Teil des Arbeitsspeichers und beantwortet eine Anfrage praktisch sofort. Er braucht kein Modell, keine Grafikkarte und keinen externen Dienst. Für viele Produkte ist das bereits eine gute Suche, und als Basis bleibt sie auch in den folgenden Stufen erhalten.

Der Nachteil liegt in der Natur der Sache, denn die Schlagwortsuche vergleicht Wörter und keine Bedeutungen. Wer „die Cloud-Rechnung explodiert" eintippt, findet den Artikel über Kostenkontrolle nur dann, wenn dort genau diese Wörter stehen. Die Absicht hinter der Frage erfasst ein Wortindex nur so weit, wie die suchende Person zufällig dieselben Begriffe verwendet wie die schreibende.

Stufe zwei: Embeddings verstehen die Absicht

Ein Embedding-Modell liest einen Text und gibt einen Vektor zurück, also eine feste Anzahl von Zahlen. Bei dem Modell, das wir einsetzen, sind es 384. Man kann sich jeden Text als Punkt in einem Raum mit 384 Richtungen vorstellen, und das Modell ist so trainiert, dass Texte mit ähnlicher Bedeutung nahe beieinander liegen, auch wenn sie kein einziges Wort teilen. „Die Cloud-Rechnung explodiert" und „Wie senken wir unsere AWS-Kosten?" landen deshalb in derselben Gegend.

Gesucht wird, indem man auch die Frage in einen Vektor übersetzt und ihn mit allen gespeicherten Vektoren vergleicht. Das Maß dafür ist die Kosinus-Ähnlichkeit, die angibt, wie sehr zwei Vektoren in dieselbe Richtung zeigen. Sind alle Vektoren auf die Länge eins normiert, reduziert sich das auf ein einfaches Skalarprodukt, und der Vergleich mit den rund 500 Textblöcken dieses Kompendiums je Sprache dauert auf einem normalen Prozessor deutlich weniger als eine Millisekunde. Eine spezielle Vektordatenbank braucht es bei dieser Größe nicht.

Wichtig ist, dass die teure Arbeit vorher passiert. Die Inhalte werden einmal vektorisiert, und das Ergebnis wird als Datei mitgeliefert. Zur Laufzeit muss das Modell nur noch die eine kurze Frage übersetzen. Unser Modell ist ein quantisiertes multilingual-e5-small im ONNX-Format, das nach dem Kürzen auf lateinische Schriftzeichen rund 57 MB groß ist und geladen etwa 275 MB Arbeitsspeicher belegt. Es läuft auf einem einzelnen Prozessorkern ohne Grafikkarte, und eine Frage ist nach dem ersten Laden in wenigen Millisekunden beantwortet.

Der Workflow: Embeddings lokal erzeugen

Der gesamte Ablauf läuft auf dem eigenen Rechner, sodass weder Inhalte noch spätere Suchanfragen einen externen Dienst erreichen. Er besteht aus wenigen Schritten, die ein einzelnes Skript nacheinander ausführt.

Zuerst wird das Modell genau einmal von Hugging Face geladen, und zwar in einer fest vorgegebenen Version, deren Dateien per SHA-256 geprüft werden. Weil wir nur Deutsch und Englisch bedienen, kürzen wir das Vokabular auf lateinische Schriftzeichen, was den Speicherbedarf halbiert, ohne die Zerlegung deutscher oder englischer Texte zu verändern. Das gekürzte Modell wird ins Repository eingecheckt, damit weder der Build noch der laufende Server jemals etwas herunterladen.

Danach werden die Inhalte in Textblöcke zerlegt, im Fachjargon Chunks. Jeder Artikel liefert seine Zusammenfassung, seine Abschnitte, die wir zu Blöcken von höchstens etwa 1.200 Zeichen packen, und jede FAQ-Antwort als eigenen Block. Ein Block soll von genau einer Sache handeln, weil sein Vektor dann präzise ist. Überschrift und Titel werden vorangestellt, damit auch ein Absatz, der nur „das" oder „es" sagt, weiß, worum es geht. Grafiken tragen ihre Bildunterschrift bei, Code wird übersprungen, weil sich Listings schlecht vektorisieren lassen.

Jeder Block wird anschließend mit dem Präfix „passage:" vektorisiert, eine Frage später mit „query:", weil das Modell genau auf diese Paare trainiert wurde. Zu jedem Block speichern wir einen Hash aus Modell und Text. Ändert sich nur ein Absatz, wird nur dieser eine neu berechnet, und alles andere wird aus dem letzten Lauf übernommen, sodass ein Durchlauf meist nur Sekunden dauert. Am Ende steht eine JSON-Datei von rund 3,4 MB, die zusammen mit dem Code eingecheckt wird.

npm run embeddings

# 1. Modell prüfen: fest vorgegebene Version, SHA-256 je Datei, gekürzt
# 2. Artikel in Textblöcke zerlegen: Zusammenfassung, Abschnitte, FAQs, Intents
# 3. Nur geänderte Blöcke vektorisieren (Hash aus Modell und Text)
# 4. embeddings.json schreiben: ein Block pro Zeile, 384 Zahlen je Vektor

Zur Laufzeit wird die Datei einmal geladen und validiert, und das Modell wird erst bei der ersten Frage in den Speicher geholt. Damit der Server bei vielen Fragen gleichzeitig nicht überlastet, rechnet er immer nur eine Frage auf einmal und lässt höchstens eine kurze Warteschlange zu. Ist die voll oder das Modell nicht verfügbar, antwortet die Schlagwortsuche allein, sodass die Seite nie leer bleibt.

Schlagworte, Absichten und Aliase kombinieren

Embeddings sind stark bei der Absicht, aber schwächer bei exakten Begriffen. Wer nach „BM25" oder einem bestimmten Produktnamen sucht, will genau dieses Wort finden und keinen Text, der ungefähr dasselbe meint. Deshalb ersetzt die zweite Stufe die erste nicht, sondern ergänzt sie. Jede Frage durchläuft parallel die Schlagwortsuche und die Vektorsuche, und beide liefern ihre eigene Rangliste.

Die Ranglisten lassen sich nicht direkt verrechnen, weil ein BM25-Wert und eine Kosinus-Ähnlichkeit völlig verschiedene Skalen haben. Wir verwenden deshalb Reciprocal Rank Fusion, bei der nur der Rang zählt. Eine Seite bekommt aus jeder Liste einen Beitrag, der umso größer ist, je weiter oben sie dort steht, und wer in mehreren Listen weit oben auftaucht, landet ganz vorn. Jede Liste filtert vorher mit ihrer eigenen Schwelle, damit eine Frage nach dem Wetter nicht doch irgendeinen Artikel findet.

Als dritte Liste kommen die Absichten hinzu, die wir Intents nennen. Zu jedem Artikel formulieren wir einige Sätze, mit denen jemand sein Problem beschreibt, bevor er weiß, dass dieser Artikel die Antwort ist, etwa „nach jedem Deployment geht etwas kaputt". Diese Sätze werden wie Fragen vektorisiert und nie angezeigt. Eine Frage, die einem solchen Satz ähnelt, zieht den passenden Artikel nach vorn, auch wenn der Artikel selbst ganz andere Worte verwendet.

Bleibt das Problem der Fachsprache. Im eigenen Team heißt es vielleicht „KI", in der englischen Dokumentation „AI", und manche schreiben „künstliche Intelligenz" aus. Für das Embedding ist das kein Problem, weil es die Begriffe ohnehin als gleichbedeutend erkennt, sogar über Sprachen hinweg. Die Schlagwortsuche dagegen sieht drei verschiedene Wörter. Deshalb faltet sie solche Aliase vor dem Indizieren auf einen gemeinsamen Begriff zusammen, sodass „AI" auch Texte findet, in denen „KI" steht, und zählt den Begriff dabei nur einmal, damit ein Synonym die Wertung nicht künstlich aufbläht.

Dasselbe Prinzip trägt für jede interne Fachsprache. Wenn euer Team „Mandant" sagt, eure Kunden aber „Account" schreiben, oder wenn ein Produkt intern einen Codenamen trägt, gehört genau diese Zuordnung in eine kleine, gepflegte Alias-Liste. Ergänzend tragen unsere Artikel eigene Schlagworte für Begriffe, die weder im Titel noch in der Zusammenfassung stehen, wie ein Werkzeug oder einen Standard, auf dem ein Artikel aufbaut. Sie werden durchsucht, aber nie angezeigt.

Wann sich ein LLM doch lohnt

Diese Stufen ersetzen kein Sprachmodell, wo wirklich formuliert werden muss. Wenn eine Antwort aus mehreren Quellen zusammengesetzt, zusammengefasst oder in einen neuen Zusammenhang übertragen werden soll, ist ein LLM das richtige Werkzeug, und RAG mit einer guten Suche davor ist dann der saubere Weg. Auch dort entscheidet allerdings die Suchqualität darüber, ob die Antwort stimmt.

Für viele Anwendungsfälle reicht es aber, den Menschen direkt zur richtigen Stelle zu führen. Das ist schneller, weil keine Antwort generiert werden muss, günstiger, weil keine Anfrage über eine bezahlte API läuft, vertraulicher, weil keine Frage den eigenen Server verlässt, und ehrlicher, weil nichts erfunden werden kann. Was angezeigt wird, steht wirklich so im Text.

Genau so arbeitet die Suche in diesem Kompendium. Stell ihr unter Frag das Kompendium eine Frage in deinen eigenen Worten, mit Tippfehler, auf Englisch oder mit „AI" statt „KI", und schau, wo du landest. Wenn du eine solche Suche für dein eigenes Produkt oder Wissen aufbauen willst, sprich uns gern an.