Embeddings im RAG: Die Brücke zwischen Dokumenten und Modellen

In einer Retrieval-Augmented Generation (RAG) Architektur fungieren Embeddings als Bindeglied zwischen der menschlichen Sprache und den mathematischen Berechnungen der Vektordatenbank. Sie übersetzen Textinhalte in eine geometrische Struktur, in der inhaltliche Verwandtschaften berechenbar werden. Die Qualität des Embedding-Modells entscheidet massgeblich darüber, ob das System relevante Dokumente findet.

Während der Beitrag zu Embeddings die mathematische Grundidee erklärt, fokussiert diese Seite die konkrete Rolle im RAG-Workflow – vom Chunking über die Indexierung bis zur Vektorsuche.

Der Embedding-Einsatz in zwei Phasen

Ein RAG-System nutzt das Embedding-Modell in zwei völlig unterschiedlichen Prozessphasen:

Phase 1: Die Indexierung (Ingestion Time)

Bevor das System Fragen beantworten kann, müssen die Dokumente aufbereitet werden.

1. Die Originaldokumente (z. B. FAQs, PDFs) werden eingelesen und in kleine Chunks zerlegt.
2. Jeder Chunk wird an das Embedding-Modell gesendet.
3. Das Modell gibt für jeden Chunk einen Vektor (z. B. ein Array aus 1536 Zahlen) zurück.
4. Der Text-Chunk wird zusammen mit seinem Vektor und optionalen Metadaten (Dateiname, Kategorie, Berechtigungen) in der Vektordatenbank gespeichert.

Phase 2: Die Suchabfrage (Query Time)

Gibt ein Benutzer eine Frage ein, startet der Echtzeit-Prozess.

1. Die Benutzerfrage wird an dasselbe Embedding-Modell gesendet, das bei der Indexierung genutzt wurde.
2. Das Modell erzeugt einen Suchvektor.
3. Die Vektordatenbank vergleicht diesen Suchvektor mit allen gespeicherten Vektoren und liefert die Textabschnitte mit der grössten Übereinstimmung (z. B. via Kosinus-Ähnlichkeit) zurück.

---

Auswahlkriterien für RAG-Embedding-Modelle

Nicht jedes Embedding-Modell eignet sich für jedes Firmenprojekt. Bei der Technologieauswahl müssen Entwickler folgende Faktoren berücksichtigen:

• Mehrsprachigkeit (Multilingualität): Sollen Dokumente auf Deutsch, Französisch, Italienisch und Englisch durchsucht werden? Modelle wie Cohere Multilingual oder BGE-M3 sind darauf trainiert, sprachübergreifend gleiche Vektoren für gleiche Bedeutungen zu erzeugen (z. B. liegt der Vektor für „Hund“ sehr nahe am Vektor für „dog“).
• Maximal unterstützte Textlänge (Context Window): Ältere Modelle konnten nur 512 Tokens pro Chunk verarbeiten. Moderne Modelle unterstützen 8000 Tokens oder mehr, was flexiblere Chunking-Strategien erlaubt.
• Vektordimensionen: Grössere Vektoren (z. B. 3072 Dimensionen) speichern feinere semantische Unterschiede, benötigen jedoch mehr Speicherplatz in der Vektordatenbank und erhöhen die Suchdauer leicht.
• Hosting-Modell (Cloud vs. On-Premises): Möchten Sie sensible Daten nicht an externe APIs senden, können Sie Open-Source-Modelle (wie all-MiniLM-L6-v2) lokal auf eigenen Servern betreiben.

---

Embedding-Modelle für RAG im Vergleich

Die Modellwahl ist ein Abwägen zwischen Präzision, Kosten und Datenschutz. Diese Tabelle zeigt typische Profile:

Modelltyp	Dimensionen	Stärke	Einschränkung
Cloud-API (z. B. OpenAI text-embedding-3-large)	bis 3072	hohe Qualität, wenig Wartung	Daten verlassen das Haus, laufende Kosten
Multilingual (z. B. Cohere, BGE-M3)	1024	sprachübergreifende Treffer	grösserer Index
Open-Source lokal (z. B. all-MiniLM-L6-v2)	384	volle Datenhoheit, kostenlos	geringere semantische Tiefe

Kleine Dimensionen (384) sparen Speicher und beschleunigen die Suche, erfassen aber feinere Nuancen schlechter. Grosse Dimensionen (3072) liefern präzisere Treffer, kosten aber Speicher und Latenz.

---

Indexierung vs. Suche: Die zwei Phasen gegenübergestellt

Aspekt	Indexierung (Ingestion Time)	Suche (Query Time)
Eingabe	alle Dokument-Chunks	eine Benutzerfrage
Häufigkeit	einmalig pro Dokument(änderung)	bei jeder Anfrage live
Ergebnis	gespeicherte Vektoren + Metadaten	temporärer Suchvektor
Modell	identisch in beiden Phasen	identisch in beiden Phasen

Die Kernregel lautet: Index- und Query-Embedding müssen vom selben Modell stammen, sonst liegen Frage und Dokumente in inkompatiblen Vektorräumen.

---

Praxisbeispiel: Semantische Nähe statt Stichwort

Ein Unternehmens-Wiki enthält den Satz: «Mitarbeitende können ihren Jahresurlaub über das Self-Service-Portal beantragen.»

• Frage des Nutzers: «Wie reiche ich Ferien ein?»
• Reine Stichwortsuche: findet nichts – weder «Ferien» noch «einreichen» kommen im Dokument vor.
• Embedding-Suche: Der Suchvektor von «Ferien einreichen» liegt sehr nahe am Vektor von «Jahresurlaub beantragen», weil beide dieselbe Bedeutung tragen. Der Chunk wird korrekt gefunden.
• Grenze: Fragt der Nutzer nach dem internen Antragsformular «HR-Form-4012», findet die Embedding-Suche es schlecht – hier braucht es zusätzlich Hybrid Search mit Stichwortanteil.

Dieses Zusammenspiel ist der Grund, warum produktionsreife Systeme Embeddings selten allein einsetzen, sondern mit Stichwortsuche und Reranking kombinieren.

[!TIP] Die Wahl des Embedding-Modells legt den Grundstein für die Suchpräzision Ihrer Firmen-KI. Unsere Demo-Infrastruktur auf allerate.dev zeigt Ihnen live, wie wir Dokumente performant verarbeiten. Probieren Sie es aus in der RAG-Demo.