Embeddings, Retrieval & Grounding

Das Problem: Bedeutung ist nicht Zeichenkette

Klassische Suche vergleicht Zeichenketten. Wer nach „Drucker geht nicht“ sucht, findet kein Dokument, das „Ausgabegerät ohne Funktion“ heißt — obwohl es exakt die Antwort enthält. Umgekehrt findet die Volltextsuche zuverlässig genau die Ticketnummer, nach der du gesucht hast.

Embeddings schließen die erste Lücke. Ein Embedding-Modell bildet einen Text auf einen Vektor ab — eine lange Zahlenliste. Texte mit ähnlicher Bedeutung landen in diesem Raum nahe beieinander, unabhängig von den verwendeten Wörtern.

Embedding — Ein Zahlenvektor, den ein Modell aus einer Eingabe erzeugt. Seine Geometrie ist für eine trainierte Ähnlichkeitsaufgabe nützlich, aber keine universelle Repräsentation von Wahrheit.

Ein Embedding-Pfad besteht aus mehr als einer Vektordatenbank: Dokumente werden geschnitten und normalisiert, ein Embedding-Modell erzeugt Vektoren, ein Index sucht Kandidaten, optional ordnet ein Reranker neu, und erst danach erhält ein Generator Kontext. Jede Stufe kann relevante Information verlieren. Darum protokolliert die Diagnose Query, Filter, Kandidaten mit Rang, verwendete Dokumentversion und die tatsächlich an das Modell übergebenen Ausschnitte.

Chunking bestimmt, was überhaupt als Treffer zurückkommen kann. Zu kleine Ausschnitte verlieren Voraussetzungen und Gültigkeit; zu große Ausschnitte vermischen Themen und verbrauchen Kontext. Speichere Parent-ID, Abschnitt, Version und Zugriffsmetadaten mit jedem Chunk. Evaluiere nicht nur, ob irgendein Chunk des richtigen Dokuments auftaucht, sondern ob der gelieferte Ausschnitt die Antwort tatsächlich trägt. Preis: Hierarchisches oder Small-to-big-Retrieval erhöht Index- und Laufzeitkomplexität.

Wie Ähnlichkeit gemessen wird

Nähe wird über ein Ähnlichkeitsmaß bestimmt, in der Praxis meist die Kosinus-Ähnlichkeit — sie vergleicht die Richtung zweier Vektoren und ignoriert deren Länge. Das Ergebnis ist eine Zahl: höher heißt ähnlicher.

Eine Suche läuft damit so ab: Alle Dokumente werden einmal in Vektoren übersetzt und gespeichert. Zur Suchzeit wird die Anfrage in denselben Raum übersetzt und die nächstliegenden Dokumentvektoren werden zurückgegeben.

Cosinus-Ähnlichkeit vergleicht den Winkel zweier Vektoren; Skalarprodukt und euklidische Distanz sind weitere gebräuchliche Maße. Welches Maß sinnvoll ist, hängt davon ab, wie das Embedding-Modell trainiert und ob Vektoren normalisiert wurden. Ein willkürlicher Wechsel des Distanzmaßes kann Rankings verändern. Nutze die Empfehlung des Modellartefakts als Startpunkt und entscheide anhand eines gelabelten Retrieval-Sets, nicht anhand einzelner Scorewerte.

Semantisch ähnlich ist nicht fachlich richtig

Das größte Missverständnis: Ein hoher Ähnlichkeitswert bedeutet nicht, dass ein Dokument die Frage beantwortet. Er bedeutet, dass es im gleichen Themenraum liegt. „Wie setze ich das Passwort zurück?“ ist einem Text über das Sperren von Konten sehr ähnlich — und beantwortet die Frage trotzdem nicht.

Besonders unzuverlässig ist Ähnlichkeit bei Verneinung und feinen Unterschieden. „Zugriff erlaubt“ und „Zugriff nicht erlaubt“ liegen im Vektorraum sehr nah beieinander, sind fachlich aber gegenteilig.

Semantische Nähe beantwortet die Frage, ob Texte im gelernten Raum ähnlich repräsentiert sind. Sie beantwortet nicht, ob eine Aussage aktuell, autorisiert oder korrekt ist. „Backup erfolgreich“ und „Backup fehlgeschlagen“ teilen fast alle Begriffe und können nah liegen, obwohl die Negation betrieblich entscheidend ist. Metadatenfilter, exakte Token-Suche, Dokumentstatus und fachliche Validierung ergänzen deshalb den Vektorvergleich.

Auch Schwellwerte sind distributionsabhängig. Ein fester Cosinuswert kann in einem eng homogenen Korpus viele irrelevante Treffer zulassen und in einem breiten Korpus relevante ausschließen. Wähle Top-k und Schwelle gegen gelabelte Queries, beobachte Recall und nachgelagerte Präzision und segmentiere exakte Codes von semantischen Fragen. Nachteil: Ein großes k erhöht Recall, kostet aber Reranking und Kontextbudget; ein kleines k kann die richtige Quelle früh verlieren.

Lexikalisch oder semantisch — beides hat eine Stärke

Vektorsuche gewinnt bei umschriebenen, natürlichsprachigen Fragen. Lexikalische Suche gewinnt bei exakten Bezeichnern: Ticketnummern, Fehlercodes, Artikelnummern, Hostnamen, Paketnamen. Solche Zeichenfolgen tragen kaum Bedeutung — im Vektorraum liegt TCK-4711 genauso nah an TCK-4712.

Anfrage enthält exakte Kennungen, Codes, Namen

lexikalische Suche stärker gewichten

Anfrage ist eine umschriebene Frage in eigenen Worten

Vektorsuche stärker gewichten

Gemischte Anfragelast

beide Wege kombinieren — die Aufteilung an echten Anfragen messen

Wie man diese Kombination in einem produktiven Retrieval-System auslegt, ist Thema des LLMOps-Pfads. Hier zählt nur die Diagnose: Welchen Anfragetyp habe ich vor mir?

BM25 gewichtet Termtreffer unter anderem nach Seltenheit und Dokumentlänge. Es ist stark bei Fehlercodes, Produktnamen und exakten IDs. Dense Retrieval kann Paraphrasen verbinden, die kein Wort teilen. Eine gemischte Ops-Query-Verteilung enthält meist beides. Hybrid Retrieval führt Kandidaten aus mehreren Rankings zusammen, etwa mit Reciprocal Rank Fusion. Der Preis sind zwei Indizes, mehr Tuning und eine aufwendigere Ursachenanalyse.

Das Embedding-Modell ist ein eigenes Bauteil

Ein Embedding-Modell ist nicht das Sprachmodell, das später die Antwort formuliert. Es ist eine eigene Komponente mit eigener Version, eigenen Kosten und eigener Qualität — und es bestimmt die Geometrie eures Index.

• Ein Modellwechsel macht alle gespeicherten Vektoren ungültig: Der gesamte Bestand muss neu eingebettet werden.
• Ein Wechsel ist deshalb ein Datenmigrationsvorhaben mit Laufzeit, Kosten und Umschaltplan — kein Konfigurationsparameter.
• Fachjargon, Abkürzungen und interne Produktnamen trennen generische Modelle oft schlecht; das merkt man nur an eigenen Testfragen, nicht an einem fremden Bestenlistenwert.

Ein Embedding-Modellwechsel ist eine Datenmigration. Vektoren verschiedener Modelle liegen nicht in einem gemeinsamen garantierten Raum; auch neue Dimensionen oder Normalisierung können den Index unbrauchbar machen. Baue einen neuen Index neben dem alten, embedde denselben versionierten Korpus neu, vergleiche beide mit demselben Eval-Set und schalte kontrolliert um. Nachteil: Zeitweise entstehen doppelte Speicher- und Rechenkosten. Ein In-place-Mix spart kurzfristig Ressourcen, zerstört aber Interpretierbarkeit.

Zwei Arten von Wissen

Ein Modell verfügt über parametrisches Wissen: das, was beim Training in die Gewichte gelangt ist — unscharf, ohne Quellenangabe, mit einem Stichtag und ohne alles Interne. Daneben steht bereitgestelltes Wissen: das, was die Anwendung zur Laufzeit in den Kontext legt.

Grounding heißt, eine Antwort auf bereitgestelltes Wissen zu stützen statt auf parametrisches. Der Gewinn ist nicht nur Aktualität, sondern Belegbarkeit: Zu jeder Aussage lässt sich die Passage zeigen, aus der sie stammt.

Parametrisches Wissen — Muster, die während des Trainings in Modellgewichten verdichtet wurden und zur Laufzeit nicht als einzeln versionierte Datensätze adressierbar sind.

Bereitgestelltes Wissen gelangt dagegen als Kontext oder Tool-Ergebnis in genau einen Aufruf. Es kann aktuell, intern und zitierbar sein, ist aber durch Kontextbudget und Retrievalqualität begrenzt. Diese Trennung erklärt, warum ein Modell eine allgemeine Linux-Frage aus Gewichten beantworten kann, für den heutigen Wartungsstatus aber eine Live-Quelle braucht. Die Anwendung muss festlegen, welche Quelle Vorrang hat, wenn beide widersprechen.

Drei Wege, Wissen zuzuführen

Direkt in den Kontext legen

kleine, feste Wissensmenge — Richtlinie, Preisliste, Systemprompt

Vorher suchen und die Treffer beilegen

große Dokumentenbestände — das übliche Retrieval-Muster

Werkzeug aufrufen

Live-Zustand und Berechnungen — Ticketstatus, Lagerbestand, Verfügbarkeit

Die Wahl folgt der Frage, wo die Wahrheit liegt. Steht sie in Dokumenten, ist Suche richtig. Steht sie in einem System und ändert sich minütlich, ist ein Werkzeugaufruf richtig — ein nächtlich indexierter Ticketstatus ist zur Abfragezeit bereits falsch.

Drei Wege decken unterschiedliche Datenformen ab. Direkter Kontext passt zu kurzen, bekannten Unterlagen. Retrieval wählt aus vielen unstrukturierten Dokumenten. Tools fragen strukturierte oder veränderliche Systeme zur Laufzeit ab. RAG ist daher kein Ersatz für jede Integration: Ein Dokumentenindex ist für Runbooks geeignet, ein CMDB- oder Monitoring-API für den aktuellen Zustand. Preis des Tools: zusätzliche Verfügbarkeits-, Autorisierungs- und Timeout-Pfade.

Bei Tools wird der Query-Contract enger als bei Retrieval. Statt eine natürliche Frage direkt in SQL zu verwandeln, stellt die Anwendung eine benannte Operation wie get_current_incidents(service_id) bereit, validiert Argumente und begrenzt Rechte. Nachteil: Jede Operation braucht API-Design. Sie liefert dafür aktuelle strukturierte Daten und trennt Sprachinterpretation von Zugriff und Abfrage.

Belegbarkeit ist eine Systemeigenschaft

Ein häufiger Irrtum: Man weist das Modell an, Quellen zu nennen — und hält das Ergebnis für einen Beleg. Wenn das Modell die Quellenangabe selbst formuliert, ist sie derselbe wahrscheinlichkeitsbasierte Text wie der Rest der Antwort und kann erfunden sein.

Belastbar wird es, wenn die Anwendung die Verknüpfung herstellt: Sie weiß, welche Passagen sie in den Kontext gelegt hat, zeigt sie an und verlinkt auf das Originaldokument. Der Nutzer prüft dann gegen die Passage, nicht gegen eine Behauptung.

Belegbarkeit entsteht nur, wenn die Antwort auf tatsächlich verwendete Quellen zurückgeführt werden kann. Eine nachträglich passend aussehende Quellenliste reicht nicht. Speichere Dokument-ID, Version, Ausschnitt und Retrieval-Rang zusammen mit der Antwort. Prüfe anschließend, ob die Aussage durch den Ausschnitt gestützt wird. Nachteil: Zitatpflicht kann Antworten verkürzen oder ablehnen, wenn Evidenz fehlt; genau das macht die Wissensgrenze sichtbar.

Das häufigste Fehlerbild: die Suche, nicht das Modell

Wenn eine gestützte Antwort falsch ist, gibt es zwei Möglichkeiten: Der richtige Inhalt war nicht im Kontext — oder er war da und das Modell hat ihn falsch verwendet. In der Praxis ist der erste Fall der weitaus häufigere.

Deshalb beginnt die Fehlersuche immer mit derselben Frage: Welche Passagen wurden tatsächlich gefunden und übergeben? Wer das nicht protokolliert, kann diese Frage nicht beantworten und landet reflexhaft beim Prompt-Tuning — der teuersten Form des Ratens.

Wenn eine Antwort falsch ist, friere zuerst die Retrieval-Ausgabe ein. Fehlt das richtige Dokument in den Top-k-Kandidaten, untersuche Query, Chunking, Filter und Suchmodus. Ist es vorhanden, aber nicht im finalen Kontext, liegt der Fehler bei Auswahl oder Budget. Liegt es im Kontext und wird ignoriert, untersuche Prompt, Widersprüche und Generator. Ein Modellwechsel vor dieser Trennung kann Symptome verschieben, ohne die fehlerhafte Stufe zu reparieren.

Zum Retrieval-Trace gehören auch Berechtigungsfilter. Ein Dokument, das der Nutzer nicht sehen darf, darf nicht erst nach dem Ranking aus dem Modelloutput entfernt werden; bereits sein Inhalt im Kontext ist eine Offenlegung. Filter müssen mit derselben Identität und Mandantenzuordnung arbeiten wie der restliche Prozess. Preis: Frühe Filter verkleinern Kandidatenmengen und können bei falschen Metadaten Recall verlieren. Das ist ein Datenqualitätsproblem, kein Grund für späte Zugriffskontrolle.

Widersprüche und Vorrang

Reale Bestände enthalten Widersprüche: eine gültige Richtlinie, ein veralteter Entwurf, eine Ausnahmeregelung für einen Standort. Legt man alles gemeinsam in den Kontext, entscheidet das Modell faktisch, welcher Version es folgt — eine Entscheidung, die es nicht treffen kann und nicht treffen soll.

• Vorrang gehört an die Quelle: Gültigkeit, Stand und Geltungsbereich als Metadaten pflegen und danach filtern.
• Veraltete Fassungen aus dem durchsuchbaren Bestand entfernen oder klar als ungültig markieren.
• Bleiben Widersprüche zwangsläufig bestehen, ist das ein Fall zum Anzeigen statt zum Auflösen — der Nutzer sieht beide Passagen.

Quellenvorrang muss als Datenregel ausdrücklich vorliegen. Mögliche Achsen sind Gültigkeitsstatus, Version, Herausgeber, Mandant und Zeit. Das Modell soll nicht aus Formulierungsstil erraten, welches von zwei Runbooks verbindlich ist. Filtere ungültige Dokumente vor dem Ranking oder liefere Metadaten samt klarer Regel. Preis: Harte Filter können Recall senken, wenn Metadaten fehlen; deshalb ist Metadatenqualität Teil des Retrieval-SLO.

Grenzen — und wohin es weitergeht

Grounding behebt keinen Wissensmangel, für den es keine Quelle gibt, und es macht keine Rechenaufgabe richtig. Es verlagert das Problem von „Was weiß das Modell?“ zu „Was ist auffindbar, aktuell und darf gesehen werden?“ — inklusive der Frage nach Zugriffsrechten, denn ein Suchindex erbt sie nicht automatisch.

Wie man ein produktives Retrieval-System auslegt — Zerlegung der Dokumente, Kombination der Suchverfahren, Nachrangierung, Qualitätsmessung — ist Gegenstand des LLMOps-Pfads. Dieses Modul liefert die Entscheidungen davor: ob Grounding das richtige Mittel ist, wo die Wahrheit liegt und wie Fehler zugeordnet werden.

Retrieval liefert Dokumentwissen, keinen garantierten Live-Zustand und keine Berechtigung. Eine Seite kann beschreiben, wie ein Dienst normalerweise neu gestartet wird; ob er gerade gestört ist und wer ihn stoppen darf, beantworten Monitoring und Autorisierung. Der richtige Grenzsatz lautet: Dokumente für Erklärung, Tools für Zustand, Code für Rechte. Gleich im Check entscheidest du acht Fälle von Modellwechsel und Suchmodus bis Quellenpflicht und Live-Abfrage.

Halte außerdem eine No-answer-Klasse im Eval-Set. Wenn kein autorisiertes aktuelles Dokument existiert, ist eine Ablehnung richtig. Ohne solche Fälle optimiert ein Team nur darauf, immer etwas zu finden und belohnt damit falsche Evidenz. Preis: Nutzer erhalten weniger scheinbar vollständige Antworten; die Wissensabdeckung wird als Produktlücke sichtbar.