Was Embeddings im RAG-Kontext wirklich machen

Ein Embedding-Modell verwandelt Text in einen Vektor — eine Zahlenfolge fester Länge, die die Bedeutung des Textes für ein bestimmtes Modell repräsentiert. Texte, die sich inhaltlich ähneln, landen im Vektorraum nah beieinander. Auf dieser Nähe beruht semantische Suche: Eine Frage wird ebenfalls in einen Vektor übersetzt, und das System sucht die Inhalte, deren Vektoren ihr am nächsten sind.

Diese unscheinbare Operation ist die tatsächliche Intelligenz hinter RAG-Systemen. Das große Sprachmodell beantwortet die Frage, aber es bekommt ohne Embeddings nie die richtigen Informationen vorgelegt. Wenn das Embedding-Modell die falschen Dokumente findet, hilft auch das beste Sprachmodell nicht — es antwortet auf der falschen Grundlage.

Das macht die Embedding-Wahl zu einer der unscheinbarsten und gleichzeitig wirksamsten Entscheidungen in einem RAG-Projekt. Sie wird im Pitch selten diskutiert — und ist im Betrieb oft die Ursache für „das System findet nicht, was wir wissen, dass da steht".

Drei Familien von Embedding-Modellen

Im Markt sind heute grob drei Familien an Embedding-Modellen relevant. Sie haben unterschiedliche Stärken und unterschiedliche Voraussetzungen für den Unternehmenseinsatz.

Die erste Familie sind kommerzielle Allzweck-Embeddings — Modelle der großen Anbieter, die per API angesprochen werden. Sie sind solide trainiert, decken viele Sprachen ab, sind in den meisten Fällen ein guter Startpunkt. Der Preis ist niedrig pro Aufruf, summiert sich aber bei großen Indexen, weil jedes Dokument einmal eingebettet werden muss — und bei Modellwechseln nochmal.

Die zweite Familie sind offen verfügbare Embeddings, die selbst betrieben werden können. Sie haben in den letzten Jahren stark aufgeholt und sind in bestimmten Konstellationen — Datenort, Kosten, Mehrsprachigkeit — die richtige Wahl. Sie verlangen aber ein Hosting-Modell, das die Anforderungen aus On-Premises vs. Cloud-LLMs ehrlich klärt — Embeddings haben dieselbe Diskussion in einer kleineren, aber ähnlichen Form.

Die dritte Familie sind domänenspezialisierte Embeddings — Modelle, die auf bestimmte Sprachen, Branchen oder Textsorten getuned sind. Sie liefern in engen Domänen oft spürbar bessere Ergebnisse als Allzweck-Modelle. Im Unternehmenseinsatz sind sie nicht der Default; aber sobald die Inhalte sprachlich oder fachlich besonders sind, lohnt sich der Test.

Auswahl-Dimensionen jenseits öffentlicher Benchmarks

Öffentliche Embedding-Benchmarks (etwa MTEB) sind als Orientierung nützlich, sagen aber wenig über die Eignung im konkreten Unternehmens-Setup. Sechs Dimensionen entscheiden in der Praxis.

Erstens Sprachen. Ein Embedding-Modell, das im Englischen brilliert, kann im Deutschen oder in Mischsprachen aus Fachbegriffen und Slang spürbar schwächer sein. Wer mehrsprachige Inhalte hat, braucht ein bewusst mehrsprachiges Modell — und idealerweise eins, das innerhalb einer Anfrage über Sprachgrenzen hinweg findet. Die Disziplin überschneidet sich mit den Beobachtungen aus mehrsprachigen KI-Assistenten.

Zweitens Dimensionsgröße. Embedding-Vektoren haben heute meist zwischen 512 und 4096 Dimensionen. Höhere Dimensionen sind tendenziell präziser, kosten aber mehr Speicher in der Vektor-Datenbank und mehr Rechenzeit in der Suche. Für viele Anwendungen sind 768 oder 1024 ein guter Mittelweg; sehr große Vektoren lohnen sich nur, wenn die Qualität messbar besser ist.

Drittens Kontextlänge. Wie viele Tokens kann das Embedding-Modell in einem einzigen Vektor zusammenfassen? Modelle mit kurzer Kontextlänge zwingen zu kleineren Chunks; Modelle mit längerem Kontext erlauben gröbere Strukturen. Welcher Schnitt passt, hängt am Inhalt — Handbücher und Verträge verlangen oft anderes als Tickets oder FAQs.

Viertens Kosten und Latenz. Bei kleinen Indizes vernachlässigbar, bei mehreren Millionen Dokumenten ein realer Faktor — sowohl in der einmaligen Indexierung als auch bei Reembedding nach einem Modellwechsel. Latenz pro Anfrage-Vektor ist meist unkritisch, summiert sich aber in agentischen Setups mit vielen Suchen.

Fünftens Datenort und Vertrag. Welche Inhalte gehen pro Aufruf an wen, mit welcher Aufbewahrungsregel? Diese Frage ist nicht reine Sicherheitsdiskussion, sondern in vielen Branchen handfeste Bedingung — eine seriöse rechtliche Bewertung ersetzt diesen Beitrag nicht.

Sechstens Stabilität und Lebenszyklus. Wie oft veröffentlicht der Anbieter neue Versionen, wann werden ältere abgekündigt, wie aufwendig ist ein Wechsel? Embedding-Modelle sind auf den ersten Blick unauffällig; ein Modellwechsel verlangt aber häufig einen vollständigen Reembedding-Lauf — und damit echten Aufwand. Wer hier auf einen Anbieter mit unklaren Lebenszyklen setzt, sammelt stille technische Schulden.

Wann Reembedding nötig wird — und wie es geplant gehört

Ein Embedding-Modell ist eine Entscheidung mit Lebenszyklus, nicht ein einmaliger Aufruf. Drei Situationen erzwingen ein Reembedding eines Indexes — und sie sollten beim ersten Bau ehrlich eingepreist sein.

Erstens ein Modellwechsel. Embedding-Vektoren verschiedener Modelle sind nicht kompatibel — eine Suche mit einem neuen Anfrage-Vektor in einem Index aus alten Vektoren liefert kein sinnvolles Ergebnis. Wer das Modell wechselt, muss den gesamten Index neu erzeugen.

Zweitens massive inhaltliche Änderungen. Wenn die Wissensbasis stark wächst, sich umstrukturiert oder eine neue Themenklasse aufgenommen wird, kann sich die Sinnhaftigkeit alter Embeddings verschieben — vor allem wenn das Modell beim Indexieren noch nicht die heutige Domänenbreite kannte.

Drittens schlechte Trefferqualität, die anders nicht zu erklären ist. Wenn Datenpflege, Chunking und Retrieval ausgeschöpft sind und die Treffer trotzdem schwach bleiben, ist das Embedding-Modell der nächste sinnvolle Verdacht — vor allem wenn neuere oder besser geeignete Modelle inzwischen verfügbar sind.

Praktisch gehört in jeden produktiven RAG-Betrieb ein Reembedding-Plan: wer löst es aus, in welchem Zeitfenster, mit welcher Auswertung gegen die alte Welt. Ohne diesen Plan wird Reembedding entweder zu spät oder zu chaotisch durchgeführt.

Hybride Suche statt purer Vektorsuche

Reine semantische Suche ist die Grunddisziplin — aber in Unternehmensinhalten selten ausreichend. Vier Eigenheiten sprechen für hybride Verfahren, die Vektorsuche mit klassischer Volltextsuche kombinieren.

Erstens exakte Treffer für Bezeichner: Produktnamen, Bestellnummern, Kontonummern, Vertrags-IDs. Semantische Suche findet hier oft das „Ähnliche"; in der Praxis braucht es das Exakte. Ein hybrides Verfahren mit klassischer Stichwort-Suche im Hintergrund liefert dort, wo Vektorsuche allein versagt.

Zweitens Sprachvarianten und Tippfehler. Klassische Suche mit Stemming, Synonymen oder fehlertoleranter Logik fängt oft auf, was reine Vektorsuche überseht. In Mehrsprach-Setups ist diese Schicht besonders wichtig.

Drittens Filterung nach Metadaten: Datum, Typ, Mandant, Status, Berechtigung. Diese Filter haben mit semantischer Ähnlichkeit nichts zu tun und müssen vor oder nach dem semantischen Schritt angewendet werden — sauber getrennt von der eigentlichen Suche.

Viertens Re-Ranking. Auf eine breite semantische Vorauswahl folgt ein zweiter Schritt mit einem präziseren Modell, das die Top-Treffer nochmal bewertet. Re-Ranker sind selbst eine eigene Modellklasse und in produktiven RAG- Setups ein verlässlicher Qualitätsgewinn — bei kleinem zusätzlichem Aufwand.

Vector-Datenbanken: was sie leisten — und was nicht

Eine Vector-Datenbank speichert die Embeddings, indiziert sie für schnelle Nachbarschaftssuche und liefert die nächsten Treffer zu einem Anfrage-Vektor. Das klingt einfach, hat aber im Unternehmenseinsatz drei Eigenheiten, die früh entschieden werden sollten.

Erstens: Skalierung. Indizes mit zehntausend Vektoren laufen auf jeder modernen Datenbank gut — Indizes mit zehn Millionen oder mehr verlangen bewusste Architektur. ANN-Verfahren (approximate nearest neighbor) bringen hier Geschwindigkeit auf Kosten leichter Ungenauigkeit; die Konfiguration entscheidet über das Verhältnis.

Zweitens: Berechtigungs-Filter. Eine Vector-Datenbank, die Berechtigungen ignoriert, ist ein Risiko — besonders im Multi-Mandanten-Setup. Filter müssen pro Anfrage angewendet werden und sollten in den Index-Strukturen so abgebildet sein, dass sie nicht zur Performance-Bremse werden.

Drittens: Aktualisierungslogik. Wie wird ein Inhalt aus dem Index entfernt, wenn er nicht mehr gilt? Wie werden geänderte Inhalte ersetzt, ohne zwischenzeitlich beide Versionen im Index liegen zu haben? Diese Lifecycle-Frage wird oft zu spät beantwortet — und ist gleichzeitig die wichtigste, damit ein RAG-System langfristig konsistent bleibt. Wir haben sie in den Beobachtungen aus Datenqualität für KI-Projekte allgemein behandelt.

Welche konkrete Vector-Datenbank gewählt wird, hängt am Stack: in PostgreSQL-Welten ist pgvector eine pragmatische Wahl, in Cloud-nativen Setups bieten Anbieter wie Pinecone, Weaviate, Qdrant oder Vespa eigene Schwerpunkte. Wichtiger als die konkrete Wahl ist, dass die Anwendung sie austauschbar ansprechen kann — ähnlich wie bei der Modellanbindung in einer LLM-Gateway-Architektur.

Wann eigene Domain-Embeddings sich tatsächlich lohnen

Selbst trainierte oder fein-getunte Embedding-Modelle sind im Unternehmenseinsatz ein Spezialfall. In den allermeisten Anwendungen liefern Allzweck-Modelle ausreichend gute Ergebnisse — der Aufwand für eigenes Training rechtfertigt sich nur unter spezifischen Bedingungen.

Sinnvoll wird eigenes Embedding-Tuning, wenn der inhaltliche Bereich sehr eng und sehr eigen ist, große Mengen an domänenspezifischen Trainingsdaten verfügbar sind und die Antwortqualität nachweislich an den Allzweck-Modellen scheitert. In dieser Konstellation ist die Frage strukturell verwandt mit dem, was wir im Beitrag Fine-Tuning, RAG oder Prompting für Sprachmodelle ausgeführt haben — und die Antwort lautet meistens: erst die anderen Hebel ausreizen, dann gezielt nachziehen.

Tests und Beobachtbarkeit für Embeddings

Eine Embedding-Wahl ist nur so gut wie die Tests, mit denen sie geprüft wird. Drei Bausteine machen den Unterschied zwischen einem System, das im Demo überzeugt, und einem, das im Betrieb verlässlich findet.

Erstens ein kuratiertes Set realer Anfragen mit erwarteten Quellen. Welche Frage soll welches Dokument finden? Diese Bewertung erfolgt nicht gegen Bauchgefühl, sondern gegen einen Testdatensatz, der wachsen darf, aber stabil bleibt. Diese Disziplin überschneidet sich mit unserer Sicht auf LLM-Qualitätssicherung.

Zweitens Modell-Vergleichstests. Vor jeder Produktiv-Entscheidung für ein Embedding-Modell lohnt ein Vergleich gegen mindestens ein Alternativ-Modell auf demselben Test-Set. Öffentliche Benchmarks ersetzen das nicht; was im eigenen Inhaltsbereich gut findet, sieht man erst im eigenen Setup.

Drittens laufende Beobachtung im Betrieb. Welche Anfragen finden keine guten Treffer? Welche Inhalte werden auffällig oft oder auffällig selten gefunden? Welche Anfragen kommen wieder und wieder, obwohl die Antwort für eine menschliche Stichprobe falsch war? Diese Beobachtbarkeit gehört in die selbe Schicht, die wir im Beitrag zu LLM-Monitoring und Observability beschrieben haben.

Typische Fehler beim Embedding-Setup

Der häufigste Fehler ist, das erstbeste Embedding-Modell zu nehmen, weil es im Tutorial des Anbieters auftauchte. Diese Wahl funktioniert am Anfang erstaunlich oft — und kommt im Betrieb spürbar zurück, sobald die Inhalte breiter, mehrsprachiger oder spezifischer werden.

Der zweite Fehler ist, sich auf reine Vektorsuche zu verlassen. Ohne hybride Verfahren mit klassischer Volltextsuche oder Filterung scheitert das System verlässlich an Bezeichnern, Tippfehlern und Metadaten — Punkte, an denen die schönste semantische Suche nichts hilft.

Der dritte Fehler ist, Reembedding nicht einzuplanen. Wer das Embedding-Modell beim ersten Bau festschreibt, ohne den Wechsel architektonisch vorzudenken, baut sich eine teure Migration für den Tag, an dem das Modell nicht mehr verfügbar ist oder ein deutlich besseres erscheint.

Der vierte Fehler ist, Berechtigungen erst nachträglich in die Vector-Datenbank einzubauen. Wer einen Index ohne Mandanten- oder Rollen-Filter aufbaut, kann ihn später nicht mehr sauber nachbessern, ohne ihn neu zu indexieren — mit allen damit verbundenen Aufwänden.

Der fünfte Fehler ist, den Embedding-Schritt von der inhaltlichen Pflege zu entkoppeln. Wer schlecht gepflegte Inhalte mit dem besten Modell embeddet, bekommt präzise Treffer auf schlechte Inhalte — die Antwort wird dadurch nicht besser. Inhaltspflege und Embedding-Setup sind zwei Seiten derselben Disziplin.

Wann externe Unterstützung sinnvoll ist

Für ein erstes RAG-System mit überschaubarem Inhaltsbereich lässt sich die Embedding-Wahl intern stemmen, wenn das Team Erfahrung mit Vektorsuche hat. Sobald aber große Indizes, Mehrsprachigkeit, Multi-Mandanten-Setups, Migrationen oder agentische Anwendungen mit vielen Suchen zusammenkommen, lohnt sich ein gezielter Blick von außen — auf Modellauswahl, Hybridsuche, Vector-Datenbank-Architektur und Reembedding-Strategie.

Wir arbeiten mit Unternehmen, die Embeddings nicht als Konfigurationsfrage, sondern als architektonische Grundentscheidung verstehen. Wenn das zu Ihrer Situation passt, sprechen Sie uns an — am besten zu Beginn, wenn Modellauswahl, Vector-DB und Aktualisierungslogik noch gestaltbar sind. Den passenden Rahmen dafür bieten wir über AI Engineering und unser LLM-QA.