# Embeddings, Retrieval & Grounding > Semantische Repräsentationen, lexikalische und dichte Suche, Retrieval-Diagnose, Quellenvorrang und Belegbarkeit als zusammenhängende Wissenspipeline. Track: [AI-Grundlagen für den IT-Betrieb](https://physar.tech/learn/ai-foundations) Kanonische Fassung: https://physar.tech/learn/ai-foundations/embeddings-similarity Stand: 2026-09-04 Interaktiver Teil: 8 Checks (nur im Browser) ## 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. Dokumente einbetten → Vektoren speichern → **Anfrage einbetten** → nächste Nachbarn suchen → Treffer zurückgeben > **Wichtig:** Anfrage und Dokumente müssen mit **demselben** Embedding-Modell in denselben Raum abgebildet werden. Vektoren aus zwei verschiedenen Modellen sind nicht vergleichbar — auch dann nicht, wenn sie zufällig dieselbe Länge haben. 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. > **Score richtig lesen:** Ein Similarity-Score ordnet Kandidaten **relativ zur Query und zum Index**. Er ist weder Wahrheitswahrscheinlichkeit noch zwischen Modellen automatisch vergleichbar. ### 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. > **Merksatz:** Der Score ist ein **Rangkriterium**, keine Konfidenz und kein Korrektheitsnachweis. Ein fester Schwellwert ist eine betriebliche Entscheidung, keine Eigenschaft der Zahl. 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`. _[Abbildung: Lexikalische und semantische Suche decken unterschiedliche Anfragetypen ab; welche Kombination und Gewichtung sinnvoll ist, hängt an der tatsächlichen Anfrageverteilung.]_ | | | | --- | --- | | 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. ### Fehlercode und Beschreibung Nutzer suchen sowohl nach `ORA-12154` als auch nach „Datenbankname wird beim Login nicht gefunden“. **Anforderungen** - Exakte Codes dürfen nicht semantisch verwischt werden. - Paraphrasen ohne Tokenüberlappung sollen Treffer liefern. **Schritte** - BM25- und Dense-Kandidaten getrennt erzeugen. - Rankings ohne rohe Score-Gleichsetzung fusionieren. - Recall und Rang auf beiden Query-Klassen messen. **Merksatz:** Die Query-Verteilung bestimmt das Retrieval-Design; kein einzelner Suchmodus ist universell. ### 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. **Kurzcheck:** Eure Vektorsuche findet zur Anfrage „Fehler ORA-01555“ die richtige Notiz nicht, liefert aber viele allgemeine Datenbanktexte. Was ist die naheliegendste Erklärung? - [x] Ein exakter Fehlercode ist ein Bezeichner — dafür braucht es lexikalische Treffer, nicht semantische Nähe - [ ] Der Schwellwert für die Ähnlichkeit ist zu hoch eingestellt - [ ] Das Sprachmodell für die Antwort ist zu klein > Richtig. Codes tragen kaum Bedeutung im Vektorraum; benachbarte Codes wirken fast identisch. 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. _[Abbildung: Grounding als Ablauf: Frage, Suche in den eigenen Quellen, ausgewählter Kontext, gestützte Antwort mit Beleg.]_ **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. > **Merksatz:** Dokumentensuche beantwortet „Was steht dazu geschrieben?“. Sie beantwortet nicht „Wie ist der Stand gerade?“. 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. Frage → Suche → ausgewählte Passagen → Antwort → **Passagen anzeigen** 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. > **Merksatz:** Erst die Zufuhr prüfen, dann die Verarbeitung. Ein Modell kann nichts korrekt wiedergeben, was es nie gesehen hat. 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. Query und Filter sichern → **Kandidaten und Ränge prüfen** → Finalen Kontext vergleichen → Antwort gegen Evidenz prüfen → Erst dann Komponente ändern 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. **Kurzcheck:** Der Assistent nennt eine Urlaubsregelung, die vor zwei Jahren galt. Beide Fassungen liegen im Ablagesystem. Was ist der erste Schritt? - [x] Gültigkeit und Stand als Metadaten pflegen und die Suche darauf filtern - [ ] Im Prompt ergänzen, dass immer die neueste Fassung zu verwenden ist - [ ] Nur noch einen einzigen Treffer statt fünf in den Kontext legen > Richtig. Der Widerspruch entsteht im Bestand; er wird an der Quelle gelöst, nicht im Prompt. 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. > **Betriebspreis:** Grounding erhöht Aktualität und Nachvollziehbarkeit, schafft aber eine zweite Produktionskomponente mit Indexfrische, Zugriffsregeln und messbarer Retrievalqualität. 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. ## Quellen - Mikolov et al. — Efficient Estimation of Word Representations in Vector Space, ICLR Workshop 2013 - Reimers & Gurevych — Sentence-BERT: Sentence Embeddings using Siamese BERT-Networks, EMNLP 2019 - Robertson & Zaragoza — The Probabilistic Relevance Framework: BM25 and Beyond, Foundations and Trends in IR 2009 - Thakur et al. — BEIR: A Heterogeneous Benchmark for Zero-shot Evaluation of Information Retrieval Models, NeurIPS 2021 - Lewis et al. — Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks, NeurIPS 2020 - Guu et al. — REALM: Retrieval-Augmented Language Model Pre-Training, ICML 2020 - Shuster et al. — Retrieval Augmentation Reduces Hallucination in Conversation, EMNLP Findings 2021 - NIST AI Risk Management Framework (AI RMF 1.0), 2023 - Reimers & Gurevych — Sentence-BERT, EMNLP-IJCNLP 2019 — https://aclanthology.org/D19-1410/ - Robertson & Zaragoza — The Probabilistic Relevance Framework: BM25 and Beyond, 2009 — https://www.staff.city.ac.uk/~sbrp622/papers/foundations_bm25_review.pdf - Cormack, Clarke & Buettcher — Reciprocal Rank Fusion, SIGIR 2009 — https://doi.org/10.1145/1571941.1572114 - Lewis et al. — Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks, NeurIPS 2020 — https://proceedings.neurips.cc/paper/2020/hash/6b493230-Abstract.html - Thakur et al. — BEIR: A Heterogeneous Benchmark for Zero-shot Evaluation of Information Retrieval Models, NeurIPS 2021 — https://openreview.net/forum?id=wCu6T5xFjeJ - Thakur et al. — BEIR: A Heterogeneous Benchmark for Zero-shot Evaluation of IR Models, NeurIPS 2021 - Rashkin et al. — Measuring Attribution in Natural Language Generation Models, Computational Linguistics 2023 - Beyer et al. (Hrsg.) — Site Reliability Engineering, O'Reilly 2016, Kapitel Effective Troubleshooting - Ettinger — What BERT Is Not: Lessons from a New Suite of Psycholinguistic Diagnostics for Language Models, TACL 2020 - ISO/IEC 25012 — Data Quality Model (Aktualität, Konsistenz, Nachvollziehbarkeit) - Schick et al. — Toolformer: Language Models Can Teach Themselves to Use Tools, NeurIPS 2023 - Muennighoff et al. — MTEB: Massive Text Embedding Benchmark, EACL 2023