Embeddings einfach erklärt: Semantische Suche in RAG-Systemen

„Wir haben doch schon eine Suche” – dieser Einwand kommt fast immer, wenn ich mit KMU über RAG-Systeme spreche, bevor klar ist, dass die bestehende Suche nach Stichwörtern sucht und ein RAG-System nach Bedeutung. Der Unterschied entsteht an einer einzigen Stelle: dem Embedding. Es übersetzt Text in eine Form, in der Ähnlichkeit messbar wird, statt nur Wortgleichheit zu prüfen. Wer verstehen will, warum ein RAG-System manchmal überraschend gute und manchmal überraschend schlechte Treffer liefert, muss an dieser Stelle ansetzen – nicht beim Sprachmodell, das am Ende nur die Antwort formuliert.

Dieser Artikel richtet sich an Geschäftsführung, Operations, IT und Fachbereiche in KMU, die verstehen wollen, was zwischen Suchanfrage und Trefferliste eigentlich passiert, bevor sie ein Angebot für ein internes Wissenssystem bewerten oder ein bestehendes System diagnostizieren. Er ist Teil des Themen-Clusters RAG, Wissensdatenbanken und Daten; wie die Vektoren anschließend gespeichert und durchsucht werden, vertieft ein eigener Artikel im Cluster.

Begriffe kurz geklärt

• Embedding ist die mathematische Abbildung eines Textabschnitts auf einen Vektor – eine Liste von Zahlen, die dessen inhaltliche Bedeutung in einem hochdimensionalen Raum repräsentiert.
• Embedding-Modell ist das KI-Modell, das diese Abbildung durchführt. Es wurde auf großen Textmengen trainiert und hat dabei gelernt, welche Wörter und Formulierungen in ähnlichen Kontexten auftauchen – und ordnet ihnen deshalb ähnliche Vektoren zu.
• Token ist die Vorstufe zum Embedding: Ein Text wird zunächst in Wörter oder Wortteile zerlegt, bevor daraus ein Vektor entsteht.
• Einbettungsraum (Vektorraum) ist der hochdimensionale Raum, in dem alle Embeddings liegen. Seine einzige Eigenschaft, die für die Suche zählt, ist die Distanz zwischen zwei Punkten: kleine Distanz heißt große inhaltliche Nähe.

Wichtig ist die Abgrenzung nach oben: Ein Embedding ist kein RAG-System und keine Vektordatenbank. Es ist die Zutat, die eine Vektordatenbank überhaupt erst durchsuchbar macht – gespeichert wird es dort zusammen mit dem zugehörigen Textabschnitt (Chunk).

Was ist ein Embedding?

Nach kurzem Kontext direkt beantwortet: Ein Embedding ist die mathematische Übersetzung eines Textabschnitts in einen Vektor – eine Liste von Zahlen, die seine inhaltliche Bedeutung in einem hochdimensionalen Raum abbildet. Ein Embedding-Modell erzeugt diesen Vektor so, dass bedeutungsähnliche Texte im Vektorraum nah beieinander liegen, unabhängig von den verwendeten Wörtern. Genau darauf beruht die semantische Suche in RAG-Systemen: Der Retriever vergleicht nicht Wörter, sondern die Distanz zwischen Vektoren, und liefert die inhaltlich nächstgelegenen Textabschnitte zurück.

Für Menschen ist ein Embedding selbst nicht lesbar – es ist eine Zahlenreihe, aus der sich weder ablesen lässt, welcher Text dahintersteckt, noch warum das Modell genau diese Zahlen gewählt hat. Das ist praktisch relevant für Transparenzpflichten: Man kann dokumentieren, welches Modell verwendet wurde und wie es evaluiert wurde, aber nicht im Einzelfall erklären, warum ein bestimmter Vektor zu einem Text gehört.

Wie wird Text zum Vektor?

Der Vorgang läuft in zwei Schritten ab. Zuerst zerlegt das Embedding-Modell den Text in Token – Wörter oder Wortteile. Anschließend wandelt es diese Tokenfolge in einen Vektor um, der die im Training gelernten Bedeutungszusammenhänge widerspiegelt: Wörter, die häufig in ähnlichen Kontexten vorkommen, erhalten ähnliche Vektoren. Dasselbe Modell wendet exakt denselben Vorgang später auf jede neue Suchanfrage an – nur so sind Anfrage- und Chunk-Vektoren überhaupt vergleichbar.

Entscheidend ist dabei: Die Aufteilung eines Dokuments in Chunks passiert vor dem Embedding, nicht danach. Wie sinnvoll diese Aufteilung ist – ob ein Chunk einen abgeschlossenen Gedanken enthält oder mitten im Satz endet – beeinflusst direkt, wie brauchbar das daraus entstehende Embedding ist. Ein technisch einwandfreies Embedding-Modell kann eine schlechte Chunk-Aufteilung nicht ausgleichen; dieses Thema vertieft ein eigener Artikel im Cluster.

Warum beeinflusst das Modell Treffer?

Jedes Embedding-Modell hat mit seinen Trainingsdaten eine eigene, in sich konsistente Vorstellung davon gelernt, welche Begriffe zusammengehören. Zwei unterschiedliche Modelle erzeugen für denselben Text unterschiedliche Vektoren – beide können in sich korrekt sein und trotzdem völlig verschiedene Nachbarschaften im jeweiligen Vektorraum ergeben. Das ist der Grund, warum ein Wechsel des Embedding-Modells in einem laufenden RAG-System praktisch immer eine Neuvektorisierung des gesamten Bestands erfordert – alte und neue Vektoren sind nicht kompatibel.

Für deutschsprachige Anwendungsfälle heißt das konkret: Bei der Auswahl eines Embedding-Modells sollten die spezifischen Anforderungen berücksichtigt werden, insbesondere ob das Modell mit deutschsprachigen Texten trainiert wurde. Ist das nicht der Fall, kann es einer Anfrage weniger relevante Chunks zuordnen – nicht weil das Modell fehlerhaft arbeitet, sondern weil es die feinen Bedeutungsunterschiede deutscher Formulierungen, Komposita und Fachbegriffe schlicht nicht in vergleichbarer Tiefe gelernt hat wie ein Modell, das überwiegend auf englischsprachigen Texten trainiert wurde.

Wie testet man deutsche Inhalte?

Eine Modell-Beschreibung, die „mehrsprachig” verspricht, ist kein Test. In meiner Arbeit prüfe ich Embedding-Modelle für deutschsprachige Anwendungsfälle mit einem festen Satz eigener Referenzfragen, bevor eine Entscheidung fällt – nicht mit dem Datenblatt des Anbieters. Das Prinzip: Für jede Frage steht vorher fest, welcher Chunk die richtige Antwort liefern sollte; danach wird geprüft, ob das Modell ihn tatsächlich unter den obersten Treffern findet.

Testfall-Typ	Beispielhafte Prüfung	Worauf er hinweist
Synonyme und Umformulierung	Anfrage nutzt andere Wörter als der Zieltext, gleiche Bedeutung	Ob das Modell Bedeutung statt Wortgleichheit erkennt
Zusammengesetzte Fachbegriffe	Deutsche Komposita (z. B. Branchenbegriffe des eigenen Unternehmens)	Ob die deutsche Wortbildung korrekt verarbeitet wird
Umgangssprache vs. Fachsprache	Interne, alltägliche Formulierung einer Mitarbeiterfrage	Ob das Modell auch Suchanfragen „wie sie wirklich gestellt werden” trifft
Tippfehler und Kurzformen	Anfrage mit realistischem Tippfehler oder Abkürzung	Robustheit gegenüber echter Nutzereingabe
Negativfall	Anfrage zu einem Thema, das im Bestand nicht vorkommt	Ob das System erkennbar „nichts Passendes” liefert statt zu raten

Eigenes Testverfahren Philogic Labs, abgeleitet aus Beratungs- und Umsetzungsprojekten.

Fünf bis zehn Fragen pro Kategorie reichen für eine erste, belastbare Einschätzung – wichtig ist nicht die Menge, sondern dass die Fragen aus echten internen Anwendungsfällen stammen statt aus einer generischen Beispielliste. Trifft das System bei diesen Referenzfragen regelmäßig daneben, liegt es häufiger am Embedding-Modell oder an der Chunk-Aufteilung als am nachgelagerten Sprachmodell, das oft fälschlich als Fehlerquelle vermutet wird.

Welche Datenschutzfragen gibt es?

Sobald personenbezogene Daten in den Textabschnitten stecken – Namen in Verträgen, Kundendaten in Support-Tickets –, braucht bereits die Erzeugung und Speicherung der Embeddings eine eigene datenschutzrechtliche Rechtsgrundlage. Das ergibt sich laut Datenschutzkonferenz nicht automatisch daraus, dass der Einsatz des KI-Systems insgesamt sinnvoll erscheint; es ist ein eigener Prüfpunkt.

Drei Punkte sind bei Embeddings speziell relevant:

Embeddings sind Pseudonymisierung, keine Anonymisierung. Ein Vektor selbst ist für Menschen nicht lesbar – trotzdem bleibt er ein personenbezogenes Datum, wenn er aus personenbezogenem Text entstanden ist. Nach dem BSI besteht das Risiko der Embedding Inversion: Wer Zugriff auf Text-Vektor-Paare und eine ausreichende Anzahl davon hat, kann ein Modell trainieren, das aus einem Embedding den ursprünglichen Text durch iterative Anpassung rekonstruiert. Die Speicherung als Vektor suggeriert damit eine Sicherheit, die technisch nicht in jedem Fall gegeben ist.

Zweckbindung bei der Tokenisierung. Bereits bei der Einbettung von Tokensequenzen ist zu prüfen, ob diese noch dem ursprünglichen Verarbeitungszweck dient – relevant ist das, weil die Einbettung sowohl der Verarbeitung durch ein Sprachmodell als auch der semantischen Suche dient, also zwei Zwecken gleichzeitig. Wer personenbezogene Chunks in eine Vektordatenbank aufnimmt, sollte diese Doppelnutzung explizit berücksichtigen, statt sie stillschweigend vorauszusetzen.

Vergiftete Wissensbasen. Wird die Wissensbasis über Retrieval-Augmented Generation befüllt, können laut BSI Angreifende manipulierte Inhalte einschleusen, die das Modell bei bestimmten Eingaben zu vordefinierten, sachlich falschen Ausgaben verleiten (Knowledge Poisoning). Das betrifft nicht das Embedding-Modell selbst, sondern die Quellen, aus denen embeddete Chunks stammen – ein Grund, warum Dokumente aus unbekannten oder nicht vertrauenswürdigen Quellen laut Datenschutzkonferenz grundsätzlich nicht verwendet werden sollten.

Der Vorteil gegenüber trainierten Modelldaten bleibt bestehen: Ein Embedding-Eintrag ist direkt adressierbar und damit gezielt löschbar, wenn das Quelldokument entfernt wird – anders als Wissen, das in den Gewichten eines trainierten Sprachmodells steckt.

Stand Juli 2026, keine Rechtsberatung. Bei Datenschutzfragen im konkreten Projekt gehört die Prüfung von Rechtsgrundlage, Zugriffsschutz und Löschprozessen in die Hände einer Datenschutzbeauftragten oder Rechtsberatung.

Umsetzung: worauf es in der Praxis ankommt

Wer ein RAG-System aufsetzt oder ein bestehendes bewertet, sollte vier Fragen zum Embedding klären, bevor die Tool-Auswahl beginnt:

1. Passt das Modell zur Sprache der Dokumente? Mit den eigenen Referenzfragen aus dem Testverfahren oben prüfen, nicht mit dem Marketingtext des Anbieters.
2. Ist die Chunk-Aufteilung mit dem Embedding-Modell abgestimmt? Sehr lange oder inhaltlich zerrissene Chunks führen auch bei einem guten Modell zu unscharfen Vektoren.
3. Wo werden personenbezogene Chunks vor dem Embedding gefiltert oder anonymisiert? Dieser Schritt gehört vor die Vektorisierung, nicht danach.
4. Wer verantwortet die Neuvektorisierung bei einem Modellwechsel? Da Vektoren unterschiedlicher Modelle nicht kompatibel sind, ist das kein einmaliger Aufwand, sondern ein wiederkehrender Betriebspunkt, sobald Anbieter neue Modellversionen ausrollen.

In meiner Arbeit sehe ich häufiger, dass diese vier Fragen erst nach der Tool-Entscheidung gestellt werden – dann meist als teure Nacharbeit, wenn sich zeigt, dass die Trefferqualität für deutschsprachige Inhalte nicht ausreicht.

Risiken & Grenzen

• Ein gutes Embedding-Modell garantiert keine guten Antworten. Es sorgt nur dafür, dass die richtigen Textabschnitte gefunden werden – was das Sprachmodell daraus macht, ist eine andere Frage.
• Sprachqualität ist schwer im Voraus zu beurteilen. Ohne eigenen Test mit echten internen Anfragen bleibt die Eignung eines Modells für deutschsprachige Inhalte Vermutung statt Wissen.
• Vektoren sind kein Datenschutz-Freifahrtschein. Die Speicherung als Zahlenreihe reduziert Lesbarkeit, aber nicht automatisch den Personenbezug oder das Rekonstruktionsrisiko.
• Modellwechsel sind teurer als sie aussehen. Jede Aktualisierung des Embedding-Modells bedeutet Neuvektorisierung des gesamten Bestands – das gehört in die Betriebsplanung, nicht in eine spontane Entscheidung.
• Komplexe Zusammenhänge über mehrere Chunks hinweg werden leicht übersehen. Die Ähnlichkeitssuche findet inhaltlich naheliegende Treffer, nicht zwingend logisch vollständige Antworten.

Checkliste: Embeddings bewerten und einführen

1. Wir haben geprüft, ob das Embedding-Modell mit deutschsprachigen Texten trainiert wurde, statt uns auf „mehrsprachig” zu verlassen.
2. Wir haben eigene Referenzfragen aus echten internen Anwendungsfällen getestet, inklusive Synonyme, Fachbegriffen und Negativfällen.
3. Die Chunk-Aufteilung ist auf das gewählte Embedding-Modell abgestimmt, nicht unabhängig davon entstanden.
4. Personenbezogene Daten werden vor der Vektorisierung gefiltert oder anonymisiert, soweit sie für den Zweck nicht erforderlich sind.
5. Für die Erzeugung und Speicherung von Embeddings aus personenbezogenen Texten liegt eine geprüfte Rechtsgrundlage vor.
6. Uns ist bewusst, dass Embeddings Pseudonymisierung, keine Anonymisierung sind – Zugriffsschutz auf die Vektordatenbank ist entsprechend geregelt.
7. Referenzdokumente für die Wissensbasis stammen aus geprüften, vertrauenswürdigen Quellen – ein Schutz gegen vergiftete Inhalte.
8. Es gibt einen definierten Löschprozess, der Quelldokument und zugehöriges Embedding gemeinsam adressiert.
9. Verantwortlichkeit für eine Neuvektorisierung bei künftigem Modellwechsel ist geklärt, nicht erst beim Wechsel selbst.

Wer diese Punkte vor der Tool-Auswahl klärt, vermeidet die häufigste Ursache enttäuschender RAG-Systeme: ein technisch sauberes Sprachmodell auf einer Vektorbasis, die für die eigene Sprache und den eigenen Dokumentenbestand nie richtig getestet wurde. Wenn du prüfen willst, ob dein Anwendungsfall mit dem richtigen Embedding-Modell und Testverfahren steht: Ein kostenloses Erstgespräch klärt das in 45 Minuten, und unser Beratungsangebot für interne Wissenssysteme findest du auf der Startseite.