Grundlagen
Was sind Embeddings? Vektoren für semantische Suche und RAG
Ein Embedding ist eine numerische Repräsentation eines Datenobjekts – Text, Bild, Audio und mehr – als Vektor in einem hochdimensionalen Raum. Ein dafür trainiertes Modell bildet bestimmte Beziehungen so ab, dass ähnliche oder zusammengehörige Inhalte rechnerisch verglichen werden können; es speichert aber nicht die „Bedeutung selbst“. Embeddings sind die Grundlage für semantische Suche, Empfehlungen, Clustering und Retrieval – etwa in RAG. Wichtig: semantische Nähe ist keine Gleichheit und keine Wahrheitsprüfung.
Was ist ein Embedding?
Ein Embedding ist eine numerische Repräsentation eines Datenobjekts in einem Vektorraum. Ein dafür trainiertes Modell versucht, bestimmte für die Aufgabe relevante Eigenschaften oder Beziehungen so abzubilden, dass ähnliche bzw. zusammengehörige Inhalte rechnerisch verglichen werden können. Bei Text können etwa semantisch verwandte Aussagen im Embedding-Raum näher beieinanderliegen als inhaltlich unabhängige Texte. Embeddings sind dabei nicht auf Text beschränkt – auch Code, Bilder, Audio oder Produkte lassen sich einbetten.
Ein Embedding ist nicht „Bedeutung als Zahl“. Das Modell wurde darauf trainiert, bestimmte Beziehungen nutzbar zu machen – was „ähnlich“ heißt, hängt von Trainingsdaten, Trainingsziel, Modell, Aufgabe, Sprache und Domäne ab. Ein Embedding speichert nicht die „wahre Bedeutung“ eines Textes.
Deshalb ist ähnlich nicht gleich identisch. Konstruiertes Beispiel: „Der Vertrag läuft am 31. Dezember aus.“ und „Der Vertrag endet Ende Dezember.“ liegen semantisch nah – zu Recht. Aber auch „Das Medikament senkt den Blutdruck.“ und „Das Medikament erhöht den Blutdruck.“ teilen viele Wörter und denselben Kontext, meinen aber das Gegenteil. Ein Embedding-System muss solche Unterschiede gelernt haben, sonst liefert eine Ähnlichkeitssuche problematische Treffer.
| Nicht verwechseln | Klarstellung |
|---|---|
| Embedding ≠ Token | Ein Token ist eine Eingabeeinheit; ein Embedding ist ein Vektor zum Vergleich (siehe auch „Token-Embedding“ unten). |
| Embedding ≠ Vektordatenbank | Das Embedding ist die Repräsentation, die Vektordatenbank nur die Infrastruktur zum Speichern/Suchen. |
| Embedding ≠ RAG | Embedding ist eine Repräsentation, RAG eine Systemarchitektur. |
| Embedding ≠ Hash | Ein Hash ändert sich bei kleinen Eingabeänderungen stark; ein Embedding soll Ähnlichkeit erhalten. |
| Embedding ≠ Verschlüsselung | Ein Embedding schützt den Ursprungstext nicht – es kann sensible Informationen enthalten. |
Vektoren und Dimensionen
Ein Vektor ist hier vereinfacht eine geordnete Liste numerischer Werte, z. B. [0.12, -0.43, 0.81, …] (schematisches Beispiel – keine echte Modellausgabe). Die Werte sind Koordinaten in einem hochdimensionalen Raum. Einzelne Dimensionen sind normalerweise nicht direkt menschlich interpretierbar – Dimension 1 ist nicht „das Thema“, Dimension 2 nicht „die Stimmung“.
Ein Embedding mit z. B. 768 Dimensionen besteht aus 768 Komponenten. Mehr Dimensionen bedeuten nicht automatisch höhere Qualität; sie beeinflussen aber Speicherbedarf, Indexgröße, Rechenaufwand und Latenz. Die Qualität hängt vom Modell und seiner Trainingsmethode ab, nicht allein von der Dimensionszahl.
Manche Modelle nutzen Matryoshka Representation Learning: Sie werden so trainiert, dass auch verkürzte Präfixe des Vektors noch brauchbar sind – ein Trade-off zwischen Speicher, Geschwindigkeit und Retrievalqualität. Vektoren einfach willkürlich abzuschneiden funktioniert nur, wenn das Modell das ausdrücklich unterstützt.
Wort-, Satz- und Dokument-Embeddings
Embeddings gibt es auf verschiedenen Ebenen. Historische Wort-Embeddings (Word2Vec, GloVe, fastText) geben einem Wort eine feste Repräsentation. Kontextuelle Modelle (seit BERT) erzeugen dagegen je nach Satz unterschiedliche Repräsentationen desselben Wortes – „Jaguar fährt schnell.“ vs. „Der Jaguar jagt im Regenwald.“ Ein ganzer Abschnitt kann zu einem Satz-/Text-Embedding verdichtet werden; längere Inhalte werden als Dokument-Embeddings abgebildet – je nach Modell als ein Vektor, mehrere Vektoren oder chunk-basiert. Nicht jeder Text besitzt also zwingend genau einen Vektor: Neben klassischem Single-Vector-Retrieval gibt es Multi-Vector-/Late-Interaction-Ansätze (z. B. ColBERT).
„Embedding“ kann zweierlei meinen: das interne Token-Embedding, mit dem ein Transformer Token-IDs in Vektoren wandelt, und das Retrieval-/Satz-Embedding, das einen Satz, Absatz oder ein Bild zum externen Vergleich repräsentiert. Beides hängt zusammen, ist aber nicht identisch.
Wie Embedding-Modelle lernen: Contrastive Learning
Viele moderne Embedding-Modelle werden kontrastiv trainiert: Das Modell lernt, zusammengehörige bzw. relevante Paare im Vektorraum näher zusammenzubringen und unpassende weiter auseinander – schematisch passend → näher, unpassend → weiter. Besonders nützlich sind dabei Hard Negatives: Beispiele, die oberflächlich sehr ähnlich wirken, aber nicht die richtige Antwort sind. Das ist eine Vereinfachung – nicht jedes Modell nutzt exakt dieselbe Loss-Funktion. Dasselbe Prinzip verbindet bei CLIP Bild- und Textrepräsentationen in einem gemeinsamen Raum.
Wie Ähnlichkeit berechnet wird
„Nähe“ im Vektorraum wird über ein Ähnlichkeits- bzw. Distanzmaß bestimmt:
| Maß | Was es vergleicht |
|---|---|
| Cosine Similarity | den Winkel bzw. die Richtung zweier Vektoren |
| Dot Product | das Skalarprodukt (Richtung und Länge) |
| Euclidean Distance | den geometrischen Abstand |
Welches Maß passt, hängt vom konkreten Modell ab – die Modelldokumentation beachten, nicht pauschal immer Cosine verwenden. Manche Modelle liefern normalisierte Vektoren; dann können verschiedene Maße unter Umständen dieselbe Rangfolge erzeugen.
Ein Cosine-Wert von 0,82 ist nicht „82 % Übereinstimmung“. Solche Scores sind ohne empirische Kalibrierung keine Prozente. Und: semantische Nähe ist keine Faktenprüfung – auf „Wie hoch ist der Mehrwertsteuersatz?“ kann ein alter Artikel mit historischem Satz perfekt passen und trotzdem veraltet sein. Retrievalqualität ≠ Faktualität (siehe Halluzinationen).
Semantische Suche
Bei der semantischen Suche werden Anfrage und Inhalte als Vektoren verglichen. Beispiel: die Anfrage „Wie kann ich meine Rechnung automatisch auslesen?“ und ein Dokument „OCR- und KI-gestützte Extraktion von Rechnungsdaten“ teilen kaum Wörter, aber ein passendes Modell erkennt die thematische Beziehung – keine Garantie, das Modell muss zu Sprache und Domäne passen.
Wichtig ist die Unterscheidung symmetrisch vs. asymmetrisch: Bei symmetrischer Suche vergleicht man ähnliche Textarten (Satz ↔ Satz, etwa für Duplikate). Bei asymmetrischer Suche haben Anfrage und Dokument unterschiedliche Rollen – eine kurze Frage gegen einen langen Regelabschnitt. Moderne, instruction-aware Modelle nutzen dafür je nach Anbieter unterschiedliche Aufgaben oder Query-/Document-Präfixe (Retrieval-Query, Retrieval-Document, Klassifikation, Clustering …). Nicht denselben Präfix blind für jedes Modell verwenden.
Keyword, Dense, Sparse und Hybrid
Dense Embeddings sind kompakte Vektoren für semantische Ähnlichkeit (Synonyme, Paraphrasen). Sparse Representations sind hochdimensional mit vielen Nullwerten und bilden eher lexikalische, termbasierte Signale ab. Keyword-Suche wie BM25 ist dabei nicht „schlechte Suche“:
| Ansatz | Stärken | Grenzen |
|---|---|---|
| Keyword / BM25 (lexikalisch) | Eigennamen, Produktnummern, Fehlercodes, exakte & seltene Begriffe | Synonyme/Paraphrasen |
| Dense Vector Search | semantische Ähnlichkeit, andere Wortwahl | exakte Codes/IDs, sehr seltene Terme |
| Hybrid Search | kombiniert lexikalisch + semantisch | mehr Aufwand; Qualität je nach Datensatz |
Hybrid Search kombiniert beides und ist oft stark – aber nicht automatisch immer besser; das hängt von Daten und Use Case ab.
Embedding-Modell ist nicht Vektordatenbank
Ein häufiges Missverständnis: „Embeddings werden in einer Vektordatenbank gespeichert.“ Das ist zu absolut. Embeddings können gespeichert bzw. indexiert werden in einer spezialisierten Vektordatenbank, einer Datenbank mit Vektor-Erweiterung, einer Suchmaschine mit Vector Search, einem lokalen Index, einer In-Memory-Struktur oder in Dateien der eigenen Anwendung.
Ein Embedding-Modell und eine Vektordatenbank sind zwei Komponenten. Das Modell erzeugt Vektoren; die Datenbank speichert Vektoren und Metadaten und sucht ähnliche Einträge. Die Datenbank ist Infrastruktur, nicht Teil der Definition eines Embeddings.
Bei wenigen Vektoren kann man alle direkt vergleichen (exakte Suche). Bei Millionen wäre das ineffizient – deshalb kommen Approximate-Nearest-Neighbor-Verfahren (ANN) wie HNSW zum Einsatz. ANN nimmt einen Trade-off zwischen Geschwindigkeit, Speicher und Recall in Kauf: Es findet sehr ähnliche Kandidaten schneller, kann aber einzelne echte Nachbarn verpassen. HNSW, IVF oder Flat Search sind Index-/Suchverfahren – keine Embedding-Modelle. Eine Vektordatenbank ergänzt die Suche meist um Metadaten-Filter (Sprache, Datum, Kategorie, Berechtigung).
Embeddings in RAG
Embeddings sind eine mögliche Retrievaltechnik in RAG – aber RAG ist nicht definitionsgemäß Dense-Embedding-Retrieval. Auch Keyword-/Hybrid-Suche, ein Knowledge Graph, SQL oder APIs können Retrieval liefern. Und umgekehrt: eine Anwendung kann Vector Search nutzen, ohne anschließend ein LLM aufzurufen (Produktsuche, Bildsuche, Empfehlung, Dublettenerkennung).
Embedding ist eine Repräsentation, RAG eine Systemarchitektur – nicht synonym. Embedding Search dient oft als erste Stufe; ein Reranker (häufig ein Cross-Encoder) bewertet danach die Top-Kandidaten genauer. Bi-Encoder (Query und Dokument getrennt) sind schnell und vorab indexierbar; Cross-Encoder sind genauer, aber teurer.
Chunking und Metadaten
Große Dokumente werden für Retrieval in Abschnitte („Chunks“) zerlegt. Chunking ist ein Optimierungsproblem – feste Tokenanzahl, Absätze, Überschriftenabschnitte, semantische Segmentierung, Sliding Window mit Overlap. Keine Methode ist universell optimal. Wichtig: ein Chunk ist nicht das Embedding (das Embedding ist die Repräsentation des Chunks) und ein Chunk ist nicht ein Token (ein Chunk enthält viele Tokens).
- Zu kleine Chunks: fehlender Kontext, unvollständige Aussagen, sehr viele Indexeinträge.
- Zu große Chunks: mehrere Themen in einem Vektor, relevante Passage wird verwässert, mehr Kontext für das LLM.
- Overlap kann Infos an Abschnittsgrenzen retten, vergrößert aber den Index und kann Dubletten erzeugen. Keine feste „20 %“-Regel – nur nach Evaluation.
Metadaten machen Retrieval oft stärker als reine Vektorähnlichkeit: erst filtern (Sprache = de, Jahr ≥ 2025, Kunde X), dann semantisch suchen. Für „Welche Rechnung hat Rechnungsnummer 481516?“ ist eine normale strukturierte Datenbankabfrage geeigneter als Vektorsuche. Ein Embedding-Index ersetzt keine Datenbank und kein Berechtigungssystem.
Modellwahl: MTEB, Deutsch und Multilingualität
Das beste Embedding-Modell hängt von Aufgabe, Sprache und Daten ab. Kriterien sind u. a. Retrieval vs. Ähnlichkeit vs. Klassifikation vs. Clustering, Multilingualität, Domäne, Input-Länge, Dimensionen, Latenz, Speicher, Kosten, lokale Ausführbarkeit und Lizenz. Der MTEB (Massive Text Embedding Benchmark) bewertet Modelle über mehrere Aufgabentypen – aber ein Modell, das eine Aufgabe anführt, muss nicht bei jeder anderen führen. Keine Rangliste einfach aus dem Gesamt-Leaderboard ableiten.
Für eine deutschsprachige Website besonders wichtig: Multilingualität darf nicht nur an englischen Benchmarks beurteilt werden. Mehrsprachige Benchmarks wie MMTEB helfen, aber „multilingual“ ist keine Garantie, dass Deutsch, Fachdeutsch, Komposita, Umlaute und Eigennamen gleich gut funktionieren – im Zweifel an realen deutschen Queries testen (keine erfundenen Eigentests).
Vektoren unterschiedlicher, unabhängig trainierter Modelle liegen in verschiedenen Räumen und sollten nicht direkt verglichen werden – Query und Dokumente mit demselben bzw. ausdrücklich kompatiblen Setup einbetten. Ein Modellwechsel bedeutet meist Re-Embedding: Dokumente neu einbetten, Index neu aufbauen, Retrieval neu evaluieren. Deshalb Embedding-Modell, Version, Dimension, Normalisierung, Chunking und Präfixe versionieren.
Multimodale Embeddings
Ein gemeinsamer multimodaler Embedding-Raum kann Modalitäten verbinden: eine Textanfrage „rotes Fahrrad vor einem Haus“ findet passende Bilder, oder ein Bild findet ähnliche Bilder und Textbeschreibungen. Historisch wichtig war CLIP, das Bild- und Textrepräsentationen aus zusammengehörigen Paaren lernte; ImageBind bindet mehrere Modalitäten in einen Raum. 2026 gibt es auch kommerzielle, nativ multimodale Embedding-Modelle (z. B. Google Gemini Embedding), die Text, Bilder, Audio, Video und PDFs gemeinsam repräsentieren – konkrete Spezifikationen ändern sich schnell, daher offizielle Model Card prüfen. Mehr unter multimodale KI.
Lokale Embeddings
Embeddings lassen sich häufig lokal erzeugen. Vorteile: Dokumente müssen ggf. nicht an eine externe API gesendet werden, Offline-Betrieb, kontrollierbare Modellversion, keine API-Kosten je Anfrage. Aber lokal ist nicht automatisch sicher, korrekt, performant oder lizenzfrei – zu prüfen sind Lizenz, Deutsch-Qualität, Hardware, Updates und Zugriffsschutz. Ein offenes Beispiel (Stand 09.08.2026): multilingual-e5-large (MIT-Lizenz, 1024 Dimensionen, u. a. Deutsch). Aktuelle Modelle vergleichst du im Verzeichnis lokaler Modelle – keine Rangliste hier.
Datenschutz und Sicherheit
Embeddings sind nicht automatisch anonym. Aktuelle Forschung zur Embedding Inversion zeigt, dass sich aus Text-Embeddings große Teile des Originaltexts rekonstruieren lassen. Das heißt nicht, dass jedes Embedding vollständig rückrechenbar ist – aber Embeddings sensibler Texte sollten nicht als anonymisierte Daten behandelt werden.
Zwei weitere Punkte für Unternehmen: Erstens ersetzt semantische Suche kein Berechtigungssystem – Zugriffsrechte (Mandant, Rolle, Dokumentrechte) müssen vor bzw. während des Retrievals greifen, sonst finden Nutzer Dokumente, die sie nicht sehen dürfen. Zweitens können bei RAG semantisch gefundene Dokumente versteckte Anweisungen enthalten – das Embedding-Modell bewertet Relevanz, nicht Vertrauenswürdigkeit. Retrieval daher mit Sicherheitslogik kombinieren (siehe Prompt Injection). Details zum Datenschutz: Datenschutz.
Ein Embedding enthält außerdem kein Prüfdatum: Es „weiß“ nicht, ob eine Information aktuell, wahr oder von wem sie ist. Solche Angaben gehören als Metadaten separat verwaltet. Und: Ändert sich ein Dokument, muss sein Embedding neu erzeugt werden – Datenänderung, Re-Embedding und Index-Update gehören zusammen.
Häufige Fehler bei Embedding-Systemen
| Fehler | Folge |
|---|---|
| Falsches Modell (englisch für Fachdeutsch) | schlechtere Treffer bei deutschen Fachtexten |
| Modelle mischen | inkompatible Vektorräume, unbrauchbare Ähnlichkeit |
| Schlechte Chunks | fehlender Kontext oder vermischte Themen |
| Nur Dense Search | exakte IDs, Namen, Codes werden schlecht gefunden |
| Kein Reranking | grobe Top-Treffer ohne Feinbewertung |
| Keine Metadatenfilter | veraltete oder unberechtigte Dokumente im Ergebnis |
| Fester Similarity-Threshold | ohne Evaluation unzuverlässig |
| Modellwechsel ohne Re-Embedding | alte und neue Vektoren passen nicht zusammen |
| Embeddings als anonym behandeln | Datenschutzrisiko (Inversion) |
| Retrievalqualität nicht messen | Fehler bleiben unentdeckt |
Bei RAG lohnt es sich, zwei Ebenen getrennt zu evaluieren: Wurde die richtige Passage gefunden (Retrieval)? Und hat das LLM daraus die richtige Antwort erzeugt (Generation)? Ist die Antwort falsch, zuerst prüfen: Retrievalfehler, Generationsfehler, veraltete Quelle oder falsches Chunking? Für Retrieval helfen Kennzahlen wie Recall@k, Precision@k, MRR oder nDCG – entscheidend bleibt: findet das System die tatsächlich benötigte Passage?
Praxis-Checkliste: Embedding-System planen
- Welche Aufgabe (Retrieval, Ähnlichkeit, Klassifikation, Clustering)?
- Welche Sprache und Domäne haben die Daten?
- Brauche ich semantische, lexikalische oder hybride Suche?
- Wie werden Dokumente sinnvoll segmentiert (Chunking)?
- Welches Embedding-Modell passt zur Aufgabe und zu Deutsch?
- Sind Query- und Dokument-Encoding kompatibel?
- Welche Metadatenfilter und Zugriffsrechte gelten?
- Brauche ich einen Reranker?
- Wie messe ich Retrievalqualität an echten Anfragen?
- Wie versioniere ich Modell und Index, und was passiert bei Änderungen?
Weiterführend: RAG, Tokens & Kontextfenster, Large Language Models, Multimodale KI, Halluzinationen und das Modellverzeichnis.
Quellen und weiterführende Informationen
- Mikolov et al. (arXiv): „Efficient Estimation of Word Representations in Vector Space" (Word2Vec) (2013). Wissenschaftliche Primärquelle · abgerufen am 09.08.2026
- Pennington, Socher, Manning (ACL Anthology): „GloVe: Global Vectors for Word Representation" (2014). Wissenschaftliche Primärquelle · abgerufen am 09.08.2026
- Bojanowski et al. (arXiv): „Enriching Word Vectors with Subword Information" (fastText) (2016). Wissenschaftliche Primärquelle · abgerufen am 09.08.2026
- Devlin et al. (arXiv): „BERT" – kontextuelle Repräsentationen (2018). Wissenschaftliche Primärquelle · abgerufen am 09.08.2026
- Reimers & Gurevych (arXiv): „Sentence-BERT" – Satz-Embeddings (Bi-Encoder) (2019). Wissenschaftliche Primärquelle · abgerufen am 09.08.2026
- Neelakantan et al. (OpenAI · arXiv): „Text and Code Embeddings by Contrastive Pre-Training" (2022). Wissenschaftliche Primärquelle · abgerufen am 09.08.2026
- Radford et al. (arXiv): „Learning Transferable Visual Models From Natural Language Supervision" (CLIP) (2021). Wissenschaftliche Primärquelle · abgerufen am 09.08.2026
- Muennighoff et al. (arXiv): „MTEB: Massive Text Embedding Benchmark" (2022). Benchmark/Publikation · abgerufen am 09.08.2026
- Enevoldsen et al. (arXiv): „MMTEB: Massive Multilingual Text Embedding Benchmark" (2025). Benchmark/Publikation · abgerufen am 09.08.2026
- Kusupati et al. (arXiv): „Matryoshka Representation Learning" (2022). Wissenschaftliche Primärquelle · abgerufen am 09.08.2026
- Khattab & Zaharia (arXiv): „ColBERT" – Late Interaction / Multi-Vector-Retrieval (2020). Wissenschaftliche Primärquelle · abgerufen am 09.08.2026
- Robertson & Zaragoza: „The Probabilistic Relevance Framework: BM25 and Beyond" (2009). Fachpublikation · abgerufen am 09.08.2026
- Malkov & Yashunin (arXiv): „Hierarchical Navigable Small World graphs" (HNSW / ANN) (2016). Wissenschaftliche Primärquelle · abgerufen am 09.08.2026
- Morris et al. (arXiv): „Text Embeddings Reveal (Almost) As Much As Text" (Embedding Inversion) (2023). Wissenschaftliche Primärquelle · abgerufen am 09.08.2026
- Girdhar et al. (arXiv): „ImageBind: One Embedding Space To Bind Them All" (2023). Wissenschaftliche Primärquelle · abgerufen am 09.08.2026
Häufige Fragen
Was ist ein Embedding einfach erklärt?
Eine numerische Darstellung eines Inhalts als Vektor, mit der sich ähnliche oder zusammengehörige Inhalte rechnerisch vergleichen lassen.
Was ist ein Vektor bei KI?
Eine geordnete Liste von Zahlen, die als Koordinaten in einem hochdimensionalen Raum dienen. Ähnliche Inhalte liegen dort näher beieinander.
Ist ein Embedding dasselbe wie ein Token?
Nein. Ein Token ist eine Eingabeeinheit; ein Embedding ist ein Vektor. Intern wandeln Modelle Token-IDs zwar in Token-Embeddings um – das ist aber nicht dasselbe wie ein Satz- oder Dokument-Embedding zum Vergleich.
Ist ein Embedding dasselbe wie eine Vektordatenbank?
Nein. Das Embedding ist die Repräsentation; die Vektordatenbank ist die Infrastruktur, die Vektoren speichert und ähnliche sucht.
Wofür werden Embeddings verwendet?
Für semantische Suche, Retrieval (auch in RAG), Empfehlungen, Clustering, Klassifikation, Deduplizierung und multimodale Suche.
Wie funktioniert semantische Suche?
Anfrage und Inhalte werden als Vektoren dargestellt; das System findet die im Vektorraum ähnlichsten Einträge – auch bei anderer Wortwahl. Das Modell muss zu Sprache und Domäne passen.
Was ist Cosine Similarity?
Ein Maß, das den Winkel bzw. die Richtung zweier Vektoren vergleicht. Der Wert ist aber keine Prozent-Übereinstimmung und sollte je Modell und Use Case kalibriert werden.
Braucht jedes RAG-System Embeddings?
Nein. RAG kann auch Keyword-Suche, Hybrid-Suche, einen Knowledge Graph, SQL oder APIs für das Retrieval nutzen. Embeddings sind nur eine Möglichkeit.
Kann ich Embeddings verschiedener Modelle mischen?
In der Regel nicht. Vektoren unabhängig trainierter Modelle liegen in verschiedenen Räumen. Query und Dokumente mit demselben bzw. kompatiblen Modell einbetten.
Sind mehr Dimensionen besser?
Nein. Mehr Dimensionen erhöhen vor allem Speicher, Index und Latenz. Die Qualität hängt vom Modell und seinem Training ab.
Was ist Hybrid Search?
Die Kombination aus lexikalischer Suche (z. B. BM25) und Dense Vector Search, um exakte Begriffe und semantische Ähnlichkeit gemeinsam zu nutzen – nicht automatisch immer besser.
Kann ich Embeddings lokal erzeugen?
Ja, mit offenen Modellen auf eigener Hardware. Das ist datensparsam, aber nicht automatisch sicher – Lizenz, Deutsch-Qualität, Hardware und Zugriffsschutz prüfen.
Sind Embeddings anonym?
Nein. Forschung zeigt, dass sich aus Embeddings große Teile des Originaltexts rekonstruieren lassen. Embeddings sensibler Daten nicht als anonym behandeln.
Wie wähle ich ein Embedding-Modell?
Nach Aufgabe, Sprache, Domäne, Input-Länge, Dimensionen, Latenz, Kosten und Lizenz. Benchmarks wie MTEB/MMTEB sind Ausgangspunkt, ersetzen aber keinen Test auf den eigenen Daten.