Embeddings und Vektoren: Wie Sprache zu Mathematik wird

Was sind Embeddings?

Ein Embedding ist eine Zahlenliste – ein Vektor – die einen Text, ein Bild, einen Audio-Schnipsel oder ein Code-Fragment in einem hochdimensionalen Raum platziert. Die Liste ist nicht zufällig: ähnliche Inhalte landen nahe beieinander, unähnliche weiter auseinander. Der Satz „Mandant zahlt verspätet" liegt im Raum nah bei „Kunde ist in Verzug" – auch wenn kein einziges Wort gleich ist. Genau diese Eigenschaft macht semantische Suche möglich.

Technisch erzeugt ein Embedding-Modell die Vektoren. Die heute gängigen Modelle (Mai 2026) liefern Vektoren mit 384, 768, 1024 oder 3072 Dimensionen. Mehr Dimensionen heisst feinere Unterscheidung, aber auch mehr Speicher und langsamere Suche. Für Deutsch sind BGE-large-de (1024 Dim, lokal lauffähig), OpenAI text-embedding-3-small (1536 Dim, 0.02 USD pro 1M Tokens) und Cohere embed-multilingual-v3 (1024 Dim, 100+ Sprachen) die drei dominanten Optionen.

Die Vektoren leben in einer Vektor-Datenbank (siehe Vergleich). Eine Suchanfrage wird durch dasselbe Modell embedet und dann mittels einer Distanz-Metrik gegen den Bestand verglichen. Drei Metriken sind üblich: cosine similarity (Standard, dimensionsunabhängig), dot product (schneller, aber Magnituden-empfindlich) und euclidean distance (selten, für geometrische Daten). Wer normalisierte Embeddings nutzt, kann cosine und dot austauschen – viele Production-Setups tun das, weil dot in der Praxis schneller berechnet wird und auf moderner Hardware bessere SIMD-Auslastung liefert.

Warum es wichtig ist

Ohne Embeddings gibt es kein RAG, keine semantische Suche, keinen sinnvollen KI-Assistenten auf eigenen Dokumenten. Klassische Volltext-Suche (Lucene, Postgres tsvector, Elasticsearch) sucht Stichwörter. Wer „Verzug" in der Wissensbasis sucht, findet keinen Treffer für „verspätete Zahlung" – obwohl die Antwort genau dort steht. Embeddings schliessen diese Lücke.

Für Treuhand- und Anwaltsbüros ist die Sprachvielfalt entscheidend. Mandanten schreiben auf Deutsch, Englisch, gelegentlich Französisch, manche Geschäftsunterlagen kommen auf Italienisch. Ein gut gewähltes mehrsprachiges Modell (Cohere embed-multilingual-v3 oder BGE-multilingual) erlaubt cross-lingual Retrieval: eine deutsche Frage findet einen englischen Vertrag, weil die semantische Nähe sprachübergreifend funktioniert.

Die Kosten sind in den letzten 18 Monaten dramatisch gesunken. text-embedding-3-small kostet 0.02 USD pro 1M Tokens (Stand Mai 2026, Quelle: OpenAI Pricing). Eine 10.000-Dokumente-Wissensbasis mit durchschnittlich 5.000 Tokens pro Dokument kostet einmalig rund 1 USD im Embedding. Speicher und Re-Indexing dazu bleiben unter 5 CHF pro Monat. Anders gesagt: die wirtschaftliche Hemmschwelle ist verschwunden.

Wie es funktioniert

Ein Embedding entsteht in einem neuronalen Netz, das auf Millionen Texten trainiert wurde. Die letzten Schichten des Netzes liefern den Vektor. Bei Transformer-basierten Modellen (alle modernen Embedding-Modelle) wird typischerweise der CLS-Token oder ein Mean-Pool über alle Token-Embeddings als finale Repräsentation genommen.

Dimensionen: 384 (kleinster sinnvoller Wert, z.B. all-MiniLM-L6-v2, sehr schnell) bis 3072 (text-embedding-3-large, beste Qualität). Faustregel: 768 oder 1024 ist der Sweet-Spot für die meisten KMU-Anwendungen. 3072 lohnt sich nur bei sehr feinen Unterscheidungen – z.B. zwei ähnlichen Vertragsklauseln, deren Differenz juristisch zählt.

Distanz-Metriken: cosine similarity misst den Winkel zwischen zwei Vektoren (1.0 = identisch, 0 = orthogonal, -1 = entgegengesetzt). Dot product entspricht cosine, wenn beide Vektoren normalisiert sind (Länge = 1). Euclidean distance misst direkten Abstand, ist aber bei hochdimensionalen Vektoren weniger trennscharf (Fluch der Dimensionalität).

Modellauswahl in der Schweiz, Stand Mai 2026:

- BGE-large-de (BAAI, open-source, 1024 Dim): lokal lauffähig auf Hetzner-CPU, kein Daten-Egress, MTEB-Rang oben für Deutsch. Ideal für revDSG-strenge Mandate. - OpenAI text-embedding-3-small (1536 Dim, kürzbar auf 256–1536): Standardwahl wenn US-Hosting akzeptabel, beste Mehrsprachigkeit innerhalb der OpenAI-Familie. Kürzung („Matryoshka") spart Speicher ohne grossen Qualitätsverlust. - Cohere embed-multilingual-v3 (1024 Dim): die stärkste Wahl wenn DE/FR/IT/EN gemischt sind; EU-Hosting via Cohere-EU verfügbar. - Mistral Embed (1024 Dim, EU-gehostet): jung, gut für EU-Daten-Residenz.

MTEB-Leaderboard (Massive Text Embedding Benchmark, Muennighoff et al. 2022): die laufende Referenz für Embedding-Qualität. Wer eine Auswahl trifft, sollte zumindest die Top-20 für die Zielsprache prüfen.

Embedding-Workflow in 6 Schritten

1. 01Sprache und Volumen klären: hauptsächlich Deutsch? mehrsprachig DE/FR/IT/EN? wie viele Dokumente? Das bestimmt das Modell.
2. 02Modell wählen: BGE-large-de für Deutsch lokal, text-embedding-3-small für Standard-Cloud, embed-multilingual-v3 für mehrsprachig – Auswahl gegen MTEB-Leaderboard für Zielsprache validieren.
3. 03Distanz-Metrik festlegen: cosine ist Default; bei normalisierten Vektoren dot product für Performance-Gewinn.
4. 04Dimensionen-Trade-off entscheiden: 1024 oder 1536 als Default; 384 nur bei sehr grossen Beständen mit Latenz-Druck; 3072 nur bei sehr feinen Unterscheidungen.
5. 05Embedding-Pipeline implementieren: Dokumente in Chunks (300–800 Tokens) schneiden, durch Modell jagen, Vektoren mit Metadaten in Vektor-DB (Qdrant) speichern.
6. 06Qualität messen: 30–50 reale Beispielfragen mit erwartetem Ergebnis pflegen, Recall@5 und MRR über die Zeit überwachen, bei Drift Re-Embedding auslösen.

Wann Embeddings einsetzen

Embeddings braucht jedes System, das Text semantisch verstehen muss: Suche, Klassifikation, Clustering, Duplikat-Erkennung, Empfehlung. Konkret: ein RAG-System für Mandantenanfragen, ein Klassifikator für eingehende E-Mails (Lohn, Steuer, Mahnung), ein Duplikate-Check für Belege, eine Ähnlichkeits-Suche für juristische Präzedenzfälle.

Besonders nützlich werden Embeddings, wenn die Suchanfragen vage oder umformuliert sind. Ein Mandant fragt: „Was muss ich beim Wegzug aus Zürich beachten?" – die Antwort liegt in einem Dokument, das „Wohnsitzwechsel und Steuerfolgen Kanton Zürich" heisst. Volltextsuche findet das nicht; ein anständiges Embedding-Modell findet es. Auch für mehrsprachige Bestände (CH-typisch DE/FR/IT/EN) sind Embeddings dem klassischen Index überlegen.

Wann NICHT

Nicht jeder Suchfall braucht Embeddings. Bei strukturierten Daten mit klaren Feldern (Mandanten-Nr., Datum, Betrag) bleibt SQL die richtige Wahl – schneller, billiger, exakter. Bei Codesuche mit exakten Symbolen (Funktionsnamen, Klassen) liefert ripgrep oder Sourcegraph präzisere Treffer als jedes Embedding-Modell.

Embeddings versagen, wenn die semantische Nähe trueglich ist. Ein Embedding sieht „Vertrag auflösen" und „Vertrag aufsetzen" als sehr nah – der Unterschied ist juristisch aber maximal. Solche Fälle brauchen entweder ein Cross-Encoder-Reranking (BGE-reranker, Cohere Rerank 3) oder eine zusätzliche Filter-Logik. Embeddings allein sind nicht präzise genug für harte Entscheidungen.

Vor- und Nachteile

Häufige Fragen

Verwandte Themen

Quellen

1. Muennighoff et al., MTEB: Massive Text Embedding Benchmark (arXiv) · 2022-10
2. OpenAI Embeddings – Models & Pricing (text-embedding-3-small/large) · 2026-04
3. Cohere Embed v3 – multilingual model docs · 2026-03
4. BAAI BGE – Open-Source Embedding Models · 2025-09
5. MTEB Leaderboard (Hugging Face Spaces) · 2026-05