Du besitzt 20.000 Dokumente.
Ein Nutzer fragt:
Wie kann ich mein Passwort zurücksetzen?
In keinem Dokument steht exakt dieser Satz.
Die passende Anleitung trägt vielleicht die Überschrift:
Zugangsdaten ändern und neues Kennwort vergeben
Eine klassische Suche nach dem Wort:
Passwort
könnte diesen Treffer übersehen.
Für einen Menschen ist trotzdem sofort klar:
Passwort zurücksetzen
und:
Kennwort neu vergeben
behandeln nahezu dasselbe Problem.
Genau hier werden Embeddings interessant.
Ein Embedding übersetzt Inhalte in eine numerische Repräsentation – einen Vektor –, sodass mathematisch mit Bedeutungsbeziehungen gearbeitet werden kann. Moderne Embeddingmodelle werden unter anderem für semantische Suche, Ähnlichkeitsvergleiche, Clustering und Klassifikation eingesetzt. (OpenAI)
Vereinfacht:
"Passwort zurücksetzen"
↓
Embedding-Modell
↓
[0.17, -0.82, 0.04, 0.61, ...]
Ein anderer Text:
"Kennwort neu vergeben"
↓
Embedding-Modell
↓
[0.16, -0.79, 0.07, 0.58, ...]
Die tatsächlichen Vektoren wären wesentlich länger.
Entscheidend ist die Idee:
Texte mit ähnlicher Bedeutung können ähnliche numerische Repräsentationen erhalten.
Damit wird aus einem sprachlichen Problem ein mathematisches Suchproblem.
Ein Embedding ist ein Vektor
Der Begriff Vektor klingt komplizierter, als er für das Grundverständnis sein muss.
Ein Vektor ist zunächst einfach eine geordnete Reihe von Zahlen.
Zum Beispiel:
[0.4, -0.2, 0.8]
Dieser Vektor besitzt drei Dimensionen.
Man könnte ihn deshalb theoretisch als Punkt in einem dreidimensionalen Raum darstellen.
y
|
| ●
|
|
----------+------------ x
/
/
z
Moderne Text-Embeddings besitzen wesentlich mehr Dimensionen.
Dann können wir diesen Raum nicht mehr anschaulich zeichnen.
Mathematisch funktioniert das Prinzip trotzdem.
Jede Eingabe bekommt eine Position im Vektorraum
Beispielsweise:
Hund
↓
Embedding
↓
Vektor A
Katze
↓
Embedding
↓
Vektor B
Steuererklärung
↓
Embedding
↓
Vektor C
Wenn das Embeddingmodell seine Aufgabe gut erfüllt, können A und B im mathematischen Raum ähnlicher sein als A und C.
Schon frühe Verfahren wie Word2Vec zeigten, dass trainierte Vektorrepräsentationen syntaktische und semantische Beziehungen zwischen Wörtern abbilden können. (research.google)
Die Zahlen selbst sind für Menschen kaum interessant
Nehmen wir:
Hund =
[0.137, -0.744, 0.219, 0.881, ...]
Man sollte die erste Zahl nicht interpretieren als:
0.137 = Tierhaftigkeit
und die zweite als:
-0.744 = Fellmenge
So einfach sind moderne Embeddingräume nicht aufgebaut.
Die Bedeutung ist über viele Dimensionen und deren Zusammenspiel verteilt.
Für uns ist deshalb normalerweise nicht wichtig, was eine einzelne Zahl bedeutet.
Interessant ist:
Wie verhält sich der gesamte Vektor zu anderen Vektoren?
Ähnlichkeit entsteht über Abstände beziehungsweise Richtungen
Angenommen, wir haben drei Texte:
A:
Wie ändere ich mein Passwort?
B:
Ich möchte ein neues Kennwort festlegen.
C:
Wie optimiere ich Bilder für WordPress?
Nach der Embeddingberechnung erhalten wir:
A → Vektor A
B → Vektor B
C → Vektor C
Dann können wir mathematisch messen:
Wie ähnlich sind A und B?
Wie ähnlich sind A und C?
Das Modell sollte idealerweise erkennen:
Ähnlichkeit(A,B)
>
Ähnlichkeit(A,C)
Obwohl A und B nicht dieselben Wörter verwenden.
Genau das ist der Kern semantischer Suche.
Semantisch bedeutet: nach Bedeutung statt nur nach Zeichenfolge
Eine klassische Keyword-Suche arbeitet stark mit konkreten Begriffen.
Anfrage:
Auto reparieren
Dokument:
Fahrzeug instand setzen
Die Wortüberschneidung ist gering.
Semantisch liegen beide Aussagen jedoch nahe.
Ein Embeddingsystem kann diese Beziehung möglicherweise erkennen.
Synonyme sind ein einfaches Beispiel
Zum Beispiel:
Passwort
Kennwort
oder:
Auto
Fahrzeug
oder:
Kündigung
Vertrag beenden
Doch moderne Embeddings können weit über einfache Synonymtabellen hinausgehen.
Sie können ganze Sätze oder Abschnitte so repräsentieren, dass Bedeutungsähnlichkeit mathematisch vergleichbar wird. Sentence-BERT wurde beispielsweise gerade dafür entwickelt, semantisch sinnvolle Satzrepräsentationen zu erzeugen, die effizient über Kosinusähnlichkeit miteinander verglichen werden können. (arXiv)
Semantische Ähnlichkeit ist mehr als Wortähnlichkeit
Vergleiche:
Mein Hund braucht Futter.
und:
Was kann ich meinem Labrador zu fressen geben?
Viele Wörter unterscheiden sich.
Die Themen liegen trotzdem nah beieinander.
Dagegen:
Die Aktie des Unternehmens ist auf den Hund gekommen.
enthält das Wort:
Hund
hat semantisch aber wenig mit Tierfutter zu tun.
Eine reine Keywordlogik sieht das Wort.
Eine gute semantische Repräsentation berücksichtigt stärker den Kontext.
Embeddings können ganze Sätze repräsentieren
Frühere populäre Verfahren konzentrierten sich stark auf einzelne Wörter.
Moderne Systeme können Embeddings erzeugen für:
Wörter,
Sätze,
Absätze,
Dokumentteile,
Dokumente,
Code.
Die Entwicklung von Satz-Embeddings war insbesondere für Anwendungen wie semantische Suche wichtig, weil nicht jedes Dokumentpaar gemeinsam durch ein großes Modell geschickt werden muss: Vektoren können vorab berechnet und anschließend effizient verglichen werden. (arXiv)
Warum ist das Vorabberechnen so wichtig?
Stell dir vor, deine Wissensbasis besitzt:
1.000.000 Textabschnitte
Ein Nutzer stellt eine Frage.
Extrem ineffizient wäre:
Frage
+
Abschnitt 1
→ großes Sprachmodell
Frage
+
Abschnitt 2
→ großes Sprachmodell
...
Frage
+
Abschnitt 1.000.000
→ großes Sprachmodell
Das wären eine Million aufwendige Vergleiche.
Embeddings ändern die Architektur.
Dokument-Embeddings werden einmal berechnet
Zunächst:
Dokument 1
↓
Embedding-Modell
↓
Vektor 1
Dokument 2
↓
Embedding-Modell
↓
Vektor 2
und so weiter.
Diese Vektoren werden gespeichert.
Bei einer neuen Frage muss nur noch für die Frage ein neues Embedding erzeugt werden.
Nutzerfrage
↓
Embedding
↓
Query-Vektor
Danach sucht das System mathematisch nach ähnlichen vorhandenen Vektoren.
Damit wird Bedeutung durch Geometrie suchbar
Das ist die entscheidende Idee.
Sprache
↓
Embedding
↓
Vektorraum
↓
Ähnlichkeit berechnen
Wir machen aus:
Welche Texte behandeln ungefähr dasselbe Thema?
eine mathematisch berechenbare Aufgabe.
Was bedeutet Cosine Similarity?
Eine häufig verwendete Methode zum Vergleich von Embeddings ist die Kosinusähnlichkeit, meist englisch Cosine Similarity.
Dabei wird vereinfacht stärker die Richtung zweier Vektoren als ihre absolute Länge betrachtet.
Man kann sich zwei Pfeile vorstellen.
B
↗
↗ A
------------------
Zeigen A und B ungefähr in dieselbe Richtung, ist ihre Kosinusähnlichkeit hoch.
Zeigen sie stark unterschiedlich:
↑ A
|
-------+------→ B
ist sie geringer.
Sentence-BERT verwendet beispielsweise Kosinusähnlichkeit zum Vergleich semantischer Satz-Embeddings. (arXiv)
Warum heißt das Kosinus?
Aus der Geometrie kennen wir den Winkel zwischen Vektoren.
Für zwei Vektoren kann mathematisch berechnet werden:
cos(θ)
wobei θ der Winkel zwischen ihnen ist.
Gleiche Richtung:
θ = 0°
cos(0°) = 1
Bei orthogonalen Richtungen:
θ = 90°
cos(90°) = 0
In realen Embeddingsystemen interessiert meist weniger die Schulgeometrie selbst als:
Welcher Vektor ist dem Query-Vektor am ähnlichsten?
Auch der Dot Product kann verwendet werden
Eine weitere wichtige Operation ist das Skalarprodukt, englisch Dot Product.
Je nach Embeddingmodell und Normalisierung können unterschiedliche Ähnlichkeits- beziehungsweise Distanzmaße sinnvoll sein.
Bei auf Länge 1 normalisierten Embeddings kann die Kosinusähnlichkeit über das Skalarprodukt besonders effizient berechnet werden. OpenAI weist beispielsweise für seine normalisierten Embeddings darauf hin, dass Kosinusähnlichkeit und euklidische Distanz dadurch dasselbe Ranking erzeugen. (OpenAI Help Center)
Für das Grundverständnis genügt:
Embedding A
+
Embedding B
↓
Ähnlichkeitsfunktion
↓
Score
Ein Similarity Score ist keine Wahrscheinlichkeit
Das ist wichtig.
Angenommen:
Ähnlichkeit = 0,84
Das bedeutet nicht automatisch:
84 % Wahrscheinlichkeit,
dass beide Texte dasselbe bedeuten
Es ist ein mathematischer Ähnlichkeitswert innerhalb des verwendeten Embeddingraums und der verwendeten Vergleichsmethode.
Wie ein Wert interpretiert werden sollte, hängt ab von:
Embeddingmodell,
Daten,
Aufgabe,
Schwellenwerten.
Deshalb gibt es keinen universellen perfekten Grenzwert
Man kann nicht allgemein sagen:
ab 0,80 = relevant
unter 0,80 = irrelevant
Für eine Anwendung könnte:
0,73
ein hervorragender Treffer sein.
Für eine andere möglicherweise nicht.
Schwellenwerte sollten anhand echter Beispieldaten getestet werden.
Ähnlichkeit bedeutet außerdem nicht Identität
Zwei Texte können semantisch sehr ähnlich sein und sich trotzdem in einer entscheidenden Information widersprechen.
Zum Beispiel:
Das Gerät unterstützt maximal 16 GB RAM.
und:
Das Gerät unterstützt maximal 32 GB RAM.
Nahezu alle Wörter und die gesamte Satzstruktur sind ähnlich.
Die entscheidende Zahl ist jedoch unterschiedlich.
Ein Embeddingsystem kann beide Texte deshalb sehr ähnlich einordnen.
Das ist vollkommen logisch.
Embeddings beantworten primär:
Welche Inhalte sind semantisch verwandt?
Nicht:
Sind alle Tatsachen darin identisch?
Noch deutlicher wird es bei Verneinungen
Das Medikament darf gemeinsam mit X verwendet werden.
und:
Das Medikament darf nicht gemeinsam mit X verwendet werden.
Die Texte besitzen enorme sprachliche Ähnlichkeit.
Inhaltlich ist ihr Unterschied entscheidend.
Das zeigt eine fundamentale Grenze:
Semantische Nähe ersetzt keine fachliche Prüfung.
Embeddings sind keine Wahrheitsmaschine
Das passt direkt zu unserem Artikel über KI-Halluzinationen.
Ein Embedding kann hervorragend erkennen:
Dieses Dokument behandelt dieselbe Frage.
Es kann daraus nicht automatisch ableiten:
Dieses Dokument enthält die richtige Antwort.
RAG kann relevante Quellen finden.
Die Qualität dieser Quellen bleibt eine eigene Frage.
Was ist semantische Suche?
Eine semantische Suche arbeitet vereinfacht so:
Dokumente
↓
Embeddings berechnen
↓
Vektoren speichern
Nutzerfrage
↓
Embedding berechnen
↓
ähnlichste Dokumentvektoren suchen
↓
passende Dokumente
OpenAI nennt semantische Suche ausdrücklich als einen typischen Anwendungsfall von Text-Embeddings. (OpenAI)
Das unterscheidet sich grundlegend von ausschließlich zeichenbasierter Suche.
Keyword-Suche und semantische Suche lösen unterschiedliche Probleme
Keyword-Suche ist hervorragend, wenn man exakt weiß, wonach man sucht.
Beispielsweise:
ERR_SSL_PROTOCOL_ERROR
Da möchte ich wahrscheinlich Dokumente mit genau dieser Fehlermeldung.
Semantische Suche ist besonders stark bei:
Warum funktioniert meine verschlüsselte
Website-Verbindung nicht mehr?
Obwohl die Dokumentation vielleicht nie exakt diese Formulierung verwendet.
Keyword-Suche besitzt also weiterhin große Vorteile
Embeddings machen klassische Suche nicht überflüssig.
Bei:
Produktnummern,
Fehlercodes,
Personennamen,
URLs,
Artikelnummern,
exakten Zitaten
ist lexikalische Suche häufig hervorragend.
Wenn jemand sucht:
KB-97281
möchte ich wahrscheinlich exakt:
KB-97281
finden.
Ein semantisch ähnlicher anderer Produktcode hilft wenig.
Deshalb ist Hybrid Search besonders interessant
Eine moderne Suche kann beide Ansätze kombinieren:
Nutzerfrage
↓
├── Keyword-Suche
│
└── semantische Vektorsuche
↓
Ergebnisse kombinieren
↓
Ranking
Dann erhält man:
exakte Begriffstreffer
und:
Bedeutungsähnlichkeit.
Das kann besonders bei technischen Wissenssystemen sehr leistungsfähig sein.
Wie entsteht ein Embedding technisch?
Vereinfacht erhält ein spezielles Modell einen Text.
"Wie ändere ich mein Passwort?"
Der Text wird zunächst – ähnlich wie bei Sprachmodellen – in Tokens zerlegt.
Text
↓
Tokenizer
↓
Tokens
Danach verarbeitet das Embeddingmodell die Tokenfolge und erzeugt daraus einen Vektor fester Dimension.
Tokens
↓
Embedding-Modell
↓
[0.021, -0.517, 0.882, ...]
Der genaue interne Prozess hängt von der Modellarchitektur ab.
Ein Embeddingmodell und ein generatives Sprachmodell haben unterschiedliche Aufgaben
Ein Sprachmodell soll typischerweise:
Text
↓
neuen Text erzeugen
Ein Embeddingmodell soll dagegen:
Text
↓
Vektor erzeugen
Es beantwortet deine Frage also normalerweise nicht.
Du gibst ein:
Wie funktioniert DNS?
und bekommst nicht:
DNS ist das Domain Name System …
sondern sinngemäß:
[0.017, 0.462, -0.291, ...]
Diese Zahlen sind für andere Software bestimmt.
Embeddings sind damit eher Infrastruktur als Benutzeroberfläche
Ein Endnutzer sieht die Vektoren meistens nie.
Er sieht nur:
Frage
↓
passende Antwort
Im Hintergrund kann jedoch passieren:
Frage
↓
Embedding
↓
Vektorsuche
↓
relevante Dokumente
↓
Sprachmodell
↓
Antwort
Embeddings sind damit ein typisches Beispiel für KI-Technik, die sehr wichtig ist, obwohl sie im fertigen Produkt nahezu unsichtbar bleibt.
Ein Embeddingmodell muss nicht dasselbe Modell wie das Sprachmodell sein
Das ist ebenfalls wichtig.
Eine Architektur kann verwenden:
Embedding-Modell A
→ Dokumentensuche
und:
Sprachmodell B
→ Antwort generieren
Beide erfüllen unterschiedliche Aufgaben.
Man sollte deshalb nicht fragen:
Welches LLM verwenden wir für unsere Embeddings?
Die Komponenten können völlig getrennt sein.
Dokumente und Suchanfrage sollten kompatibel eingebettet werden
Wenn Dokumente mit einem bestimmten Embeddingmodell verarbeitet wurden, sollte die spätere Suchanfrage in denselben kompatiblen Vektorraum übersetzt werden.
Sonst sind die Koordinaten nicht sinnvoll miteinander vergleichbar.
Man kann sich vorstellen:
Modell A:
eigene Landkarte
Modell B:
andere Landkarte
Die Koordinate:
[17, 24]
hat ohne gemeinsame Karte keine gemeinsame Bedeutung.
Ein Modellwechsel kann deshalb Neuindexierung bedeuten
Du hast:
5 Millionen Dokument-Chunks
mit Embeddingmodell A verarbeitet.
Nun wechselst du zu Modell B.
Die neuen Query-Vektoren sollten nicht einfach gegen alte, inkompatible Dokumentvektoren verglichen werden.
In vielen Architekturen bedeutet ein Modellwechsel deshalb:
Dokumente
↓
mit neuem Embeddingmodell erneut verarbeiten
↓
neuen Index aufbauen
Das sollte bei großen Wissenssystemen bereits bei der Planung berücksichtigt werden.
Embeddings sollten deshalb versioniert werden
Eine Datenbank könnte beispielsweise speichern:
chunk_id
embedding
embedding_model
embedding_version
created_at
Dann lässt sich später nachvollziehen:
Mit welchem Modell wurde dieser Vektor erzeugt?
Das klingt zunächst nach Verwaltungsdetail.
Bei Millionen gespeicherten Vektoren wird es sehr wichtig.
Was ist eine Dimension?
Ein Embedding kann beispielsweise besitzen:
Dimension 1
Dimension 2
Dimension 3
...
Dimension n
Je mehr Dimensionen vorhanden sind, desto mehr numerische Werte enthält jeder Vektor.
Ein vereinfachtes dreidimensionales Embedding wäre:
[0.2, -0.7, 0.4]
Ein reales modernes Embedding kann sehr viel länger sein.
Mehr Dimensionen bedeuten auch mehr Speicher
Angenommen, ein Vektor besitzt:
1.000 Werte
und du speicherst:
10 Millionen Vektoren
Dann müssen bereits:
10 Milliarden Zahlenwerte
gespeichert werden.
Zusätzlich kommen:
IDs,
Metadaten,
Suchindex
hinzu.
Die Größe eines Embeddings ist deshalb eine reale Infrastrukturentscheidung.
Größer ist auch hier nicht automatisch besser
Ein höherdimensionaler Vektor kann mehr Repräsentationskapazität besitzen.
Aber:
mehr Dimensionen
bedeuten auch:
mehr Speicher,
mehr Netzwerkverkehr,
größere Indizes.
Entscheidend ist die tatsächliche Suchqualität für die Aufgabe.
Wie bei Sprachmodellen sollte man nicht ausschließlich eine einzelne Größenkennzahl optimieren.
Was ist eine Vektordatenbank?
Nun haben wir vielleicht Millionen Embeddings.
Wir brauchen ein System, das sehr schnell beantworten kann:
Welche 10 gespeicherten Vektoren sind diesem Query-Vektor am ähnlichsten?
Eine dafür optimierte Datenhaltung wird häufig als Vektordatenbank beziehungsweise Vector Store bezeichnet.
Für große Mengen Embeddings empfehlen auch aktuelle Embedding-Dokumentationen spezialisierte Vektorsuche, um die nächstgelegenen Vektoren effizient abzurufen. (OpenAI Help Center)
Eine Vektordatenbank speichert mehr als Zahlen
Typischerweise brauchen wir mindestens:
ID
Embedding-Vektor
Originaltext oder Referenz
Metadaten
Beispiel:
ID:
4711
Text:
"Um Ihr Kennwort zurückzusetzen ..."
Embedding:
[0.18, -0.44, ...]
Quelle:
handbuch.pdf
Kapitel:
Accountverwaltung
Version:
3.2
Sprache:
de
Damit kann ein Treffer später wieder mit dem tatsächlichen Inhalt verbunden werden.
Der Vektor allein reicht nicht
Die Suche findet:
Vektor 4711
Aber ein Sprachmodell braucht letztlich den dazugehörigen Text.
Deshalb wird meist gespeichert:
Vektor
↔
Chunk-ID
↔
Originalinhalt
Die Vektorsuche findet die ID.
Das System lädt den Text.
Dann gelangt dieser Text in das Kontextfenster des Sprachmodells.
Was bedeutet Nearest Neighbor Search?
Der Query-Vektor befindet sich irgendwo im Embeddingraum.
Nun wollen wir die nächsten Nachbarn finden.
● Dokument D
● A
★ Query
● B
● C
A und B liegen nahe.
C und D weiter entfernt.
Die Suche liefert beispielsweise:
1. B
2. A
3. D
Das nennt man vereinfacht Nearest Neighbor Search.
Was bedeutet Top-K?
Häufig fordert ein System nicht nur den einen besten Treffer an.
Sondern beispielsweise:
Top-K = 5
Dann werden die fünf ähnlichsten Treffer zurückgegeben.
Treffer 1
Treffer 2
Treffer 3
Treffer 4
Treffer 5
Das K steht einfach für die gewünschte Anzahl.
Warum nicht nur Top-1?
Der mathematisch ähnlichste Treffer muss nicht zwingend die beste Informationsquelle sein.
Vielleicht liefert:
Treffer 1:
Definition.
Treffer 2:
wichtige Ausnahme.
Treffer 3:
konkrete Anleitung.
Für eine gute Antwort können mehrere Abschnitte nötig sein.
Deshalb erhält ein RAG-System häufig mehrere Kandidaten.
Zu großes K kann wiederum schaden
Wenn du statt fünf Treffern:
100
lädst, entstehen:
mehr Tokens,
mehr irrelevanter Kontext,
mehr mögliche Widersprüche.
Das passende K sollte daher getestet werden.
Wieder gilt:
mehr
≠
automatisch besser
Exakte Suche kann bei riesigen Datenmengen teuer werden
Bei wenigen hundert Vektoren kann man theoretisch jeden Query-Vektor mit jedem gespeicherten Vektor vergleichen.
Bei:
100 Millionen Vektoren
wird das aufwendig.
Deshalb verwenden große Vektorsuchsysteme häufig Verfahren für Approximate Nearest Neighbor Search.
Dabei wird nicht zwangsläufig jeder einzelne Vektor vollständig geprüft.
Das System versucht sehr schnell sehr gute nahe Kandidaten zu finden.
„Approximate“ bedeutet bewussten Kompromiss
Man tauscht teilweise:
absolut exakte Suche
gegen:
sehr schnelle Suche
mit hoher Trefferwahrscheinlichkeit
Bei großen Suchsystemen kann das ein sinnvoller Trade-off sein.
Welche Indexstruktur geeignet ist, hängt unter anderem ab von:
Datenmenge,
Dimensionen,
Latenz,
Updatehäufigkeit,
gewünschter Genauigkeit.
Metadatenfilter sind mindestens so wichtig wie Vektorähnlichkeit
Angenommen, dein Wissenssystem besitzt Dokumente in:
Deutsch,
Englisch,
Französisch.
Der Nutzer möchte nur deutsche Dokumente.
Dann könnte man filtern:
language = de
Oder:
product = wordpress
Oder:
version = 6
Oder:
customer_id = 172
Metadaten begrenzen den Suchraum.
Besonders wichtig sind Berechtigungsfilter
Angenommen, ein Mitarbeiter darf nur Dokumente aus Abteilung A lesen.
In der gemeinsamen Vektordatenbank liegen aber auch:
Gehaltslisten,
Geschäftsführungsprotokolle,
vertrauliche Kundendaten.
Dann darf die Architektur nicht lauten:
semantisch suchen
↓
geheime Dokumente finden
↓
LLM bekommt alles
↓
Prompt sagt:
"Bitte nicht verraten."
Sondern:
Benutzer
↓
Berechtigung bestimmen
↓
nur erlaubten Datenraum durchsuchen
↓
Treffer
↓
LLM
Die Zugriffskontrolle muss vor beziehungsweise bei der Retrievalauswahl wirken.
Vektorsuche ersetzt keine Rechteverwaltung
Die Datenbank weiß:
Dokument A ist semantisch passend.
Das bedeutet nicht:
Nutzer darf Dokument A lesen.
Relevanz und Berechtigung sind zwei getrennte Dimensionen.
relevant?
+
erlaubt?
Nur wenn beides erfüllt ist, sollte der Inhalt in den Kontext gelangen.
Embeddings sind auch kein Datenschutzzauber
Man könnte denken:
Ich speichere nicht den Klartext, sondern nur Embeddings. Also sind die Daten anonym.
Diese Schlussfolgerung ist zu riskant.
Embeddings sind abgeleitete Repräsentationen der ursprünglichen Information und sollten bei sensiblen Inhalten ebenfalls als schützenswerte Daten behandelt werden.
Besonders in einem realen System existieren häufig ohnehin zusätzliche Verknüpfungen zu:
Dokument-ID,
Nutzer-ID,
Metadaten,
Originalinhalt.
Die Sicherheitsarchitektur sollte deshalb nicht davon ausgehen, dass ein Zahlenvektor automatisch harmlos ist.
Wie kommen Dokumente in eine Vektordatenbank?
Der Prozess wird häufig als Ingestion bezeichnet.
Zum Beispiel:
PDF
↓
Text extrahieren
↓
bereinigen
↓
in Chunks teilen
↓
Embedding für jeden Chunk erzeugen
↓
Vektor + Text + Metadaten speichern
Damit ist die Wissensbasis vorbereitet.
Warum werden Dokumente in Chunks geteilt?
Nehmen wir ein Handbuch mit:
300 Seiten
Ein einziges Embedding für das komplette Dokument wäre häufig zu grob.
Das Dokument behandelt:
Installation.
Konfiguration.
Backup.
Benutzerrechte.
Fehlerbehebung.
Eine Frage nach Passwortänderung würde gegen eine Repräsentation des gesamten Handbuchs verglichen.
Der relevante kleine Abschnitt könnte in der Gesamtbedeutung untergehen.
Kleinere Abschnitte erzeugen präzisere Suchziele
Statt:
1 Handbuch
→ 1 Embedding
kann man erzeugen:
Handbuch
↓
Chunk 1 → Embedding
Chunk 2 → Embedding
Chunk 3 → Embedding
...
Chunk 200 → Embedding
Nun kann die Suche exakt den Abschnitt finden, der die Frage behandelt.
Chunkgröße ist deshalb entscheidend
Zu großer Chunk:
viel Kontext
aber
unscharfe thematische Mischung
Zu kleiner Chunk:
präzise
aber
Zusammenhang kann fehlen
Die richtige Größe hängt ab von:
Dokumentstruktur,
Fragetyp,
Embeddingmodell,
späterem Sprachmodell.
Ein Absatz ist nicht automatisch ein perfekter Chunk
Manchmal besteht ein sinnvoller Abschnitt aus:
Überschrift
plus:
zwei Absätzen.
Oder:
einer Tabelle.
Oder:
einer Liste mit Erklärung.
Reines Schneiden nach exakt:
500 Tokens
kann Zusammenhänge zerstören.
Semantische beziehungsweise strukturelle Grenzen sind häufig wertvoll.
Überschriften sollten im Chunk erhalten bleiben
Stell dir vor, im Handbuch steht:
## Passwort zurücksetzen
1. Öffnen Sie ...
2. Wählen Sie ...
Wenn der Chunk nur enthält:
1. Öffnen Sie ...
2. Wählen Sie ...
fehlt dem Embedding ein wichtiger Bedeutungsanker.
Besser kann sein:
Titel:
Passwort zurücksetzen
Inhalt:
1. Öffnen Sie ...
Das erhöht die semantische Information des Abschnitts.
Metadaten sollten nicht mit Embeddinginhalt verwechselt werden
Ein Dokument besitzt:
Produkt: WordPress
Version: 6
Sprache: Deutsch
Man kann diese Informationen teilweise in den Text für das Embedding aufnehmen.
Oder separat als Metadaten speichern.
Beides erfüllt unterschiedliche Aufgaben.
Metadata Filter:
Version = 6
ist exakt.
Semantische Ähnlichkeit:
ungefähr dasselbe Thema
ist probabilistisch.
Wo möglich, sollten exakte Bedingungen auch exakt behandelt werden.
Das ist wieder dieselbe Architekturregel wie bei LLMs
eindeutige Regel
→ klassische Software
unscharfe Bedeutung
→ KI
Embeddings sind hervorragend für:
Welche Texte passen thematisch?
Eine SQL-Datenbank ist besser für:
Welche Dokumente haben version = 6?
Zusammen sind beide stärker.
Was geschieht bei der Nutzeranfrage?
Nachdem alle Dokumente vorbereitet sind:
Nutzer:
"Wie ändere ich mein Passwort?"
Schritt 1:
Frage
↓
Embeddingmodell
↓
Query-Vektor
Schritt 2:
Query-Vektor
↓
Vektordatenbank
↓
ähnlichste Chunks
Schritt 3:
Treffer
↓
Originaltexte laden
Nun besitzt das System vielleicht:
Chunk A:
"Kennwort zurücksetzen ..."
Chunk B:
"Zugangsdaten ändern ..."
Chunk C:
"Account-Wiederherstellung ..."
Damit ist noch keine Antwort generiert
Bis hierhin haben wir nur gesucht.
Das ist wichtig.
Embeddings beantworten die Frage nicht.
Sie helfen zunächst:
relevante Information zu finden.
Nun kann ein Sprachmodell eingeschaltet werden:
Frage
+
gefundene Chunks
↓
LLM
↓
Antwort
Und genau diese Kombination führt uns zum nächsten Thema:
RAG.
Embeddings sind nicht dasselbe wie RAG
Diese Begriffe werden häufig vermischt.
Embedding:
Information
→ Vektor
Vektorsuche:
Query-Vektor
→ ähnliche Vektoren finden
RAG:
Frage
↓
Informationen abrufen
↓
in Modellkontext geben
↓
Antwort generieren
Embeddings können ein zentraler Bestandteil von RAG sein.
RAG ist aber der größere Prozess.
RAG braucht nicht zwingend ausschließlich Embeddings
Ein Retrievalsystem kann auch verwenden:
Keyword-Suche,
Datenbankfilter,
Knowledge Graphs,
Suchmaschinen,
APIs.
Ein leistungsfähiges RAG-System kann mehrere Verfahren kombinieren.
Zum Beispiel:
Frage
↓
├── semantische Suche
├── Keyword-Suche
└── Metadatenfilter
↓
Kandidaten
↓
Ranking
↓
LLM
Embeddings sind ein Werkzeug innerhalb dieser Architektur.
Was bedeutet Reranking?
Angenommen, die Vektorsuche findet:
50 Kandidaten
Diese sind grundsätzlich ähnlich.
Nun kann ein zweiter Schritt genauer prüfen:
Welche fünf beantworten die Frage am besten?
50 Kandidaten
↓
Reranker
↓
Top 5
Dieser zweite Schritt darf aufwendiger sein, weil nicht mehr die gesamte Datenbank betrachtet wird.
Warum nicht gleich den aufwendigsten Vergleich für alles verwenden?
Weil:
1.000.000 Dokumente
×
teurer Modellvergleich
aufwendig wäre.
Besser:
schnelle Embeddingsuche
↓
kleine Kandidatenmenge
↓
präziseres Reranking
Das ist ein häufiges allgemeines Suchprinzip:
erst grob reduzieren
↓
dann fein beurteilen
Embeddings können auch für Clustering verwendet werden
Nehmen wir:
100.000 Kundenanfragen
Wir wissen noch nicht, welche Themen darin vorkommen.
Für jede Nachricht wird ein Embedding erzeugt.
Dann können ähnliche Vektoren gruppiert werden.
Vielleicht entstehen Cluster rund um:
Rechnung
Login
Versand
Passwort
Kündigung
Fehler
Embeddings wurden schon früh ausdrücklich als nützliche Repräsentationen für Clustering und Klassifikation beschrieben. (OpenAI)
Clustering braucht nicht zwingend vorher definierte Kategorien
Das ist interessant.
Bei Klassifikation sagen wir:
Kategorie A
Kategorie B
Kategorie C
Beim Clustering können wir zunächst fragen:
Welche natürlichen Gruppen befinden sich überhaupt in meinen Daten?
Danach kann ein Mensch oder ein Sprachmodell die Cluster interpretieren.
Embeddings können Duplicate Content finden
Angenommen, eine Website besitzt:
10.000 Artikel.
Ein neuer Text soll veröffentlicht werden.
Man könnte sein Embedding berechnen.
Dann sucht man die ähnlichsten bestehenden Artikel.
neuer Artikel
↓
Embedding
↓
bestehender Artikelindex
↓
Top 10 ähnliche Artikel
Danach kann geprüft werden:
Ist das wirklich ein neues Thema?
Oder existiert bereits ein nahezu identischer Beitrag?
Das ist für große Contentprojekte besonders interessant
Bei wenigen Artikeln kennt der Redakteur den Bestand.
Bei:
100.000 Seiten
nicht mehr.
Embeddings können helfen:
Themendopplungen zu finden,
ähnliche Beiträge zu erkennen,
interne Linkkandidaten zu bestimmen,
Themencluster zu bilden.
Sie ersetzen nicht die redaktionelle Entscheidung.
Sie reduzieren den Suchraum.
Embeddings eignen sich hervorragend für interne Verlinkung
Neuer Artikel:
Wie funktionieren Passkeys?
Man berechnet das Embedding.
Dann findet das System ähnliche vorhandene Seiten:
Passwortmanager
Zwei-Faktor-Authentifizierung
Sichere Passwörter
Account-Sicherheit
Phishing
Das sind potenzielle interne Linkziele.
Nun kann ein zweiter Schritt prüfen:
Welche Verbindung ist inhaltlich tatsächlich sinnvoll?
Semantische Nähe bedeutet aber nicht automatisch einen guten Link
Artikel A:
Was ist ein Passwort?
Artikel B:
Die Geschichte des Passworts.
Sehr ähnlich.
Aber möglicherweise hilft B dem Leser des aktuellen Absatzes nicht.
Interne Links brauchen zusätzlich:
Kontext,
Nutzerwert,
redaktionelle Absicht.
Embeddings liefern Kandidaten.
Nicht die endgültige Entscheidung.
Embeddings können Suchintentionen gruppieren
Nehmen wir Keywords:
wordpress schneller machen
wordpress performance verbessern
wordpress seite lädt langsam
wordpress geschwindigkeit erhöhen
Diese Begriffe unterscheiden sich.
Semantisch liegen sie nahe.
Embeddings können helfen, solche Suchanfragen thematisch zu clustern.
Damit könnten Contentteams erkennen:
Diese Keywords gehören wahrscheinlich zu demselben Artikel.
Aber SEO-Intent ist komplexer als Vektorähnlichkeit
Zum Beispiel:
wordpress hosting
und:
bestes wordpress hosting
liegen semantisch eng zusammen.
Die Suchintention kann dennoch unterschiedlich sein.
Ersteres:
Informationssuche.
Zweites:
stärker kommerzieller Vergleich.
Daher sollte Embeddingähnlichkeit nicht automatisch die gesamte Suchintention bestimmen.
Embeddings können Empfehlungen ermöglichen
Ein Nutzer liest Artikel A.
Das System sucht:
Embedding von Artikel A
↓
ähnlichste Artikel
und erhält:
Artikel B
Artikel C
Artikel D
Damit können thematisch verwandte Inhalte vorgeschlagen werden.
Das funktioniert auch bei:
Produkten,
Supportfällen,
Dokumenten,
Stellenanzeigen.
Empfehlungen brauchen zusätzliche Geschäftslogik
Der ähnlichste Artikel könnte:
bereits gelesen worden sein.
Oder:
veraltet.
Oder:
für eine andere Zielgruppe gedacht.
Deshalb kann die endgültige Auswahl verwenden:
semantische Ähnlichkeit
+
Aktualität
+
Nutzerstatus
+
Qualität
+
Geschäftsregeln
Embeddings liefern wieder nur ein Signal.
Embeddings können Klassifikation vereinfachen
Angenommen, wir haben Beispieltexte für:
Support
Verkauf
Rechnung
Eine neue Nachricht wird eingebettet.
Dann kann untersucht werden, welchen bekannten Beispielen sie am ähnlichsten ist.
Das kann bereits als einfacher Klassifikationsansatz funktionieren.
Je nach Aufgabe kann ein spezialisiertes Modell oder LLM aber geeigneter sein.
Embeddings können Anomalien sichtbar machen
Wenn die meisten Datenpunkte in bestimmten Bereichen des Vektorraums liegen und ein neuer Punkt extrem weit entfernt ist, kann das auf:
ungewöhnlichen Inhalt
hinweisen.
Auch Anomalieerkennung gehört zu den Anwendungen, für die Embeddingrepräsentationen genutzt werden können. (OpenAI)
Das bedeutet nicht automatisch:
Dieser Datensatz ist fehlerhaft.
Nur:
Er unterscheidet sich stark von den üblichen Mustern.
Embeddings können Code repräsentieren
Nicht nur natürliche Sprache lässt sich einbetten.
Auch Programmcode kann in Vektoren übersetzt werden.
Dann kann eine Anfrage lauten:
Funktion zum Prüfen einer E-Mail-Adresse
und das System sucht passende Codeabschnitte, obwohl der exakte Wortlaut in der Funktion nicht vorkommt.
Text- und Code-Embeddings wurden gezielt für solche Such- und Ähnlichkeitsaufgaben entwickelt. (OpenAI)
Das macht semantische Codesuche möglich
Klassische Suche:
validate_email
findet Funktionen, die exakt so heißen.
Semantische Suche könnte auch finden:
check_mail_address()
oder:
is_valid_recipient()
wenn der Code tatsächlich eine ähnliche Aufgabe erfüllt.
Für große Codebasen kann das enorm nützlich sein.
Mehrsprachige Embeddings können Sprachgrenzen überwinden
Ein geeignetes mehrsprachiges Embeddingmodell kann Texte unterschiedlicher Sprachen in einen vergleichbaren semantischen Raum einordnen.
Dann könnte eine deutsche Anfrage:
Wie ändere ich mein Passwort?
möglicherweise eine passende englische Dokumentation finden:
Resetting your account password
Die Qualität hängt stark vom konkreten Embeddingmodell und den unterstützten Sprachen ab.
Das sollte deshalb mit den tatsächlich benötigten Sprachen getestet werden.
Übersetzen vor der Suche ist damit nicht immer notwendig
Eine Alternative wäre:
deutsche Frage
↓
ins Englische übersetzen
↓
englische Suche
Multilinguale Embeddings können den Zwischenschritt teilweise vermeiden.
Ob das für die jeweilige Anwendung besser funktioniert, ist eine Evaluationsfrage.
Eigennamen können semantische Suche schwierig machen
Anfrage:
Casiopeya
Hier geht es vielleicht nicht um allgemeine Bedeutung.
Der genaue Name selbst ist wichtig.
Keyword-Search kann hier sehr stark sein.
Deshalb ist wieder die Kombination interessant:
lexikalische Suche
+
semantische Suche
Dasselbe gilt für Modellnummern
RTX 4060 Ti
ist keine beliebige semantische Beschreibung.
Die exakte Zeichenfolge ist wichtig.
Vektorsuche allein könnte ähnliche Grafikkartenmodelle finden.
Das ist vielleicht hilfreich.
Vielleicht aber gerade unerwünscht.
Gute Suchsysteme verstehen unterschiedliche Querytypen
Eine Anfrage:
ERR_CONNECTION_RESET
→ eher exakter Suchbegriff.
Eine Anfrage:
Warum bricht meine Browser-Verbindung
zum Server ständig ab?
→ semantische Suche sinnvoll.
Ein fortgeschrittenes System kann Suchstrategien abhängig von der Anfrage kombinieren.
Wie beurteilt man ein Embeddingmodell?
Nicht anhand eines einzigen schönen Beispiels.
Man braucht ein Testset.
Zum Beispiel:
100 reale Nutzerfragen
Für jede ist bekannt:
Welche Dokumente sollten gefunden werden?
Nun wird gemessen:
Findet Modell A die relevanten Dokumente?
Wie hoch im Ranking?
Wie oft fehlen wichtige Treffer?
Retrieval braucht eigene Kennzahlen
Ein RAG-System kann falsch antworten, weil das Sprachmodell schlecht war.
Oder weil Retrieval das richtige Dokument nie gefunden hat.
Deshalb sollte die Suchqualität separat bewertet werden.
Zum Beispiel sinngemäß:
War das relevante Dokument
unter den Top 5?
Wenn nicht, kann das Sprachmodell wenig dafür.
Recall ist bei Retrieval besonders wichtig
Vereinfacht gefragt:
Wie viele der relevanten Dokumente haben wir überhaupt gefunden?
Wenn von zehn relevanten Dokumenten nur zwei im Kandidatenset auftauchen, fehlt dem späteren System viel Information.
Ein breiter Retrievalschritt kann deshalb hohen Recall priorisieren.
Danach reduziert ein Reranker die Kandidaten.
Precision beantwortet eine andere Frage
Wie viele unserer gefundenen Treffer waren tatsächlich relevant?
Top 10:
7 relevant
3 irrelevant
ist anders als:
1 relevant
9 irrelevant
Je nach Anwendung braucht man einen guten Kompromiss zwischen:
Recall
und:
Precision.
RAG-Evaluation muss Retrieval und Generation trennen
Eine sinnvolle Diagnose lautet:
1. Wurde die richtige Information gefunden?
2. Wurde sie in den Kontext gegeben?
3. Hat das Sprachmodell sie korrekt verwendet?
Wenn Schritt 1 scheitert, bringt Promptoptimierung bei Schritt 3 möglicherweise überhaupt nichts.
Embeddings können veralten, obwohl der Vektor selbst nicht „alt“ wird
Das Dokument verändert sich.
Der gespeicherte Vektor repräsentiert aber weiterhin die alte Textversion.
Beispiel:
alte Seite:
maximal 10 Benutzer
neue Seite:
maximal 50 Benutzer
Wenn der Text aktualisiert wird, sollte auch das Embedding aktualisiert werden.
Sonst sucht die Datenbank weiterhin anhand des alten Inhalts.
Dokumentänderungen brauchen deshalb Re-Embedding
Pipeline:
Dokument geändert
↓
betroffene Chunks bestimmen
↓
neue Embeddings erzeugen
↓
alte Vektoren ersetzen
Nicht zwingend die gesamte Wissensbasis muss neu berechnet werden.
Nur die veränderten Teile.
Gelöschte Dokumente müssen auch aus dem Index verschwinden
Sonst kann passieren:
Die Datei wurde aus dem Wissenssystem gelöscht.
Der Vektor existiert aber weiterhin.
Retrieval findet ihn noch.
Das kann:
veraltete Antworten
oder sogar:
Berechtigungsprobleme
verursachen.
Datenlebenszyklus und Vektorindex müssen synchron bleiben.
Jede Chunk-ID sollte daher auf einen realen Datensatz zeigen
Beispielsweise:
chunk_id: 4711
document_id: 83
revision: 17
Dann kann das System prüfen:
Existiert die Quelle noch?
Ist die Revision aktuell?
Darf der Nutzer sie sehen?
Erst danach wird sie verwendet.
Embeddings eignen sich nicht als Ersatz für den Originaltext
Ein wichtiger Fehler wäre:
Original löschen
↓
nur Embedding behalten
und später erwarten:
Rekonstruiere mir exakt den ursprünglichen Absatz.
Das Embedding ist nicht als verlustfreie Textkompression gedacht.
Es ist eine Repräsentation für maschinelle Aufgaben wie Ähnlichkeitsvergleich.
Der Originalinhalt sollte separat gespeichert werden, wenn er später benötigt wird.
Ein Embedding ist also kein ZIP-Archiv
Bei ZIP:
Datei
↓
komprimieren
↓
ZIP
↓
entpacken
↓
identische Datei
Bei Embedding:
Text
↓
Embedding
↓
semantische Repräsentation
Eine verlustfreie Rückübersetzung ist nicht der Zweck.
Embeddings sind ebenfalls keine Hashwerte
Ein kryptografischer Hash soll kleine Änderungen stark sichtbar machen.
Beispiel:
Dokument A
→ Hash X
ein Zeichen verändert
→ völlig anderer Hash Y
Ein Embedding verfolgt nahezu das gegenteilige Ziel.
Kleine beziehungsweise bedeutungserhaltende Textänderungen sollen häufig zu ähnlichen Repräsentationen führen.
Passwort ändern
und:
Kennwort ändern
sollen semantisch nahe bleiben.
Hashing beantwortet:
Sind diese Daten exakt dieselben?
Embedding beantwortet eher:
Sind diese Inhalte ähnlich?
Das sind völlig unterschiedliche Aufgaben.
Embeddings sind auch keine Verschlüsselung
Verschlüsselung soll Daten unter Verwendung eines Schlüssels vor unberechtigtem Lesen schützen.
Embeddings sollen semantische Repräsentationen erzeugen.
Daraus folgt:
Embedding
≠
Verschlüsselung
Sensible Vektordaten brauchen weiterhin geeigneten Zugriffsschutz.
Ein schönes Beispiel: Supportsystem
Angenommen, ein Unternehmen besitzt:
50.000 gelöste Supporttickets
Neues Ticket:
Seit dem Pluginupdate ist nur noch eine weiße Seite sichtbar.
Embedding:
neues Ticket
↓
Vektor
Dann Suche:
ähnliche alte Tickets
Ergebnisse vielleicht:
Ticket 812:
White Screen nach Pluginupdate
Ticket 1733:
PHP Fatal Error nach Pluginupdate
Ticket 9144:
Theme-Konflikt nach Update
Nun kann ein Mitarbeiter oder Sprachmodell sehen:
Wie wurden ähnliche Probleme gelöst?
Das ist etwas anderes als ein Sprachmodell nach der Lösung zu fragen
Ohne Retrieval:
LLM
→ allgemeines WordPress-Wissen
Mit Embeddings:
LLM
+
ähnliche reale Fälle aus diesem Unternehmen
Damit entsteht firmenspezifisches Wissen zur Laufzeit.
Genau das macht RAG so interessant.
Ein weiteres Beispiel: eigene Wissenswebsite
Stell dir Casiopeya später mit tausenden Wissensartikeln vor.
Nutzer fragt:
Warum zeigt Google meine neue Seite nicht an?
Semantische Suche könnte finden:
Google indexiert meine Seite nicht
robots.txt verstehen
noindex verstehen
XML-Sitemap
Canonical-Tag
Obwohl die Frage keinen dieser exakten Titel nennt.
Das System besitzt damit eine eigene semantische Wissensnavigation.
Embeddings können auch die normale Website-Suche verbessern
Statt nur:
Suche nach exakt enthaltenen Wörtern
könnte eine Suche thematisch passende Artikel finden.
Frage:
Meine Seite taucht nicht bei Google auf.
Treffer:
Google indexiert meine Seite nicht
Das wäre für den Leser deutlich natürlicher.
Trotzdem sollte die Suchoberfläche verständlich bleiben
Der Nutzer muss nicht wissen:
Wir erzeugen gerade einen 1.536-dimensionalen Vektor und führen ANN Retrieval durch.
Er tippt einfach seine Frage.
Gute Technologie verschwindet hinter einer einfachen Nutzung.
Embeddings können ein Wissensnetz automatisch unterstützen
Wir haben bei Casiopeya bewusst Themen-Hubs.
Ein automatisches System könnte jeden neuen Artikel einbetten und fragen:
Welche bestehenden Artikel liegen
semantisch besonders nahe?
Daraus entstehen Kandidaten für:
interne Links,
„Weiterlesen“-Elemente,
Clusterzuordnung,
Duplicate-Prüfung.
Das wäre langfristig ein sehr brauchbarer Baustein einer automatisierten Redaktion.
Embeddings können auch thematisch überraschende Verbindungen zeigen
Zum Beispiel könnte ein Artikel über:
KI-Agenten
starke Nähe zu:
API-Sicherheit
zeigen.
Obwohl beide in unterschiedlichen Navigationsbereichen liegen.
Das kann wertvolle Querverlinkungen sichtbar machen.
Eine starre Kategoriehierarchie würde solche Beziehungen möglicherweise weniger deutlich zeigen.
Genau deshalb sind Wissensnetze nicht dasselbe wie Ordnerbäume
Ordnerstruktur:
Artikel gehört genau hierher.
Embeddingraum:
Artikel besitzt gleichzeitig
Ähnlichkeiten zu vielen Themen.
Beide Modelle ergänzen sich hervorragend.
Navigation gibt klare Orientierung.
Semantische Ähnlichkeit zeigt Querbeziehungen.
Embeddings können dabei helfen, neue Themencluster zu entdecken
Wenn über Jahre hunderte Artikel entstehen, kann man ihre Vektoren analysieren.
Vielleicht bilden sich Gruppen rund um:
WordPress-Sicherheit
Performance
Hosting
KI-Automatisierung
Fotografie
Das kann zeigen:
Wo besteht bereits viel Content?
Wo fehlen Verbindungen?
Wo behandeln mehrere Artikel nahezu dasselbe Thema?
Visualisierung ist möglich – aber nur nach Dimensionsreduktion
Ein Embedding besitzt vielleicht sehr viele Dimensionen.
Unser Bildschirm nur zwei.
Um den Vektorraum grafisch darzustellen, müssen die Daten deshalb auf zwei oder drei Dimensionen reduziert werden.
Dann erhält man beispielsweise eine Punktwolke.
● ● ●
●● ●
▲ ▲
▲ ▲ ▲
■ ■
■ ■
Die Gruppen können thematische Cluster repräsentieren.
Die Visualisierung ist jedoch eine vereinfachte Projektion.
Nicht der vollständige ursprüngliche Raum.
Nähe in der Grafik ist deshalb nicht exakt dieselbe wie Nähe im Originalraum
Bei der Dimensionsreduktion gehen zwangsläufig Informationen verloren.
Eine hübsche zweidimensionale Karte sollte deshalb eher als Analysehilfe verstanden werden.
Nicht als perfekte Darstellung sämtlicher Embeddingbeziehungen.
Embeddings können auch für personalisierte Empfehlungen genutzt werden
Man könnte beispielsweise ein Profil aus mehreren gelesenen Artikeln ableiten und verwandte Inhalte suchen.
Dabei entstehen allerdings zusätzliche Datenschutzfragen.
Denn aus Nutzungsverhalten werden nun möglicherweise semantische Interessenprofile.
Technisch interessant bedeutet nicht automatisch datenschutzrechtlich oder redaktionell sinnvoll.
Datenminimierung bleibt wichtig
Wenn für eine Suchfunktion reicht:
Dokumentinhalt
+
technische Dokument-ID
muss man nicht automatisch zusätzlich speichern:
Name,
E-Mail,
private Nutzerinformationen.
Dasselbe Prinzip aus Sicherheit & Datenschutz gilt auch bei Vektorsystemen:
Nur Daten speichern und verarbeiten, die für die Aufgabe tatsächlich notwendig sind.
Embeddings können lokal erzeugt werden
Wie Sprachmodelle können auch Embeddingmodelle lokal betrieben werden.
Eine mögliche Architektur:
Dokument
↓
lokales Embeddingmodell
↓
lokale Vektordatenbank
↓
lokales LLM
Damit kann eine vollständige RAG-Pipeline auf eigener Infrastruktur laufen.
Das kann für vertrauliche Wissensbestände interessant sein.
Embeddingmodelle sind oft erheblich kleiner als große generative Modelle
Ihre Aufgabe ist enger:
Input
→ Vektor
statt:
komplexe generative Antwort
Deshalb können spezialisierte Embeddingmodelle in vielen Fällen ressourcenschonender betrieben werden als große Chatmodelle.
Welche Hardware tatsächlich notwendig ist, hängt vom konkreten Modell, Datenvolumen und gewünschten Durchsatz ab.
Bei vielen Dokumenten zählt Durchsatz
Wenn einmalig:
1.000.000 Chunks
eingebettet werden müssen, interessiert:
Wie viele Texte kann das System pro Sekunde verarbeiten?
Das ist eine andere Leistungsanforderung als:
ein einzelner Chat.
Nach der ersten Indexierung müssen häufig nur noch:
neue
oder:
veränderte
Dokumente eingebettet werden.
Embeddings lassen sich gut vorberechnen
Das ist einer ihrer großen praktischen Vorteile.
Dokumenttext ändert sich nicht?
Dann muss sein Vektor nicht bei jeder Suchanfrage neu berechnet werden.
Dokument
↓
einmal Embedding
↓
speichern
↓
tausende Suchanfragen
Nur die jeweilige Query wird neu eingebettet.
Genau diese Vorberechenbarkeit macht semantische Suche skalierbar.
Caching kann zusätzlich helfen
Wiederholt sich dieselbe oder nahezu dieselbe technische Anfrage häufig, können weitere Optimierungen möglich sein.
Aber die größte Einsparung entsteht bereits dadurch:
Dokument-Embeddings werden nicht ständig neu erzeugt.
Wie viele Embeddings benötigt ein Dokument?
Das hängt vom Chunking ab.
Ein Artikel mit:
5.000 Wörtern
könnte beispielsweise in:
10 Chunks
geteilt werden.
Dann entstehen:
10 Embeddings
Ein anderes Chunking könnte:
20
erzeugen.
Das beeinflusst:
Indexgröße,
Retrievalpräzision,
Speicherkosten.
Kleine Chunks erhöhen die Zahl der Vektoren
Angenommen:
100.000 Dokumente.
Durchschnittlich:
10 Chunks.
Dann:
1.000.000 Vektoren
Bei 20 Chunks:
2.000.000 Vektoren
Chunkgröße ist deshalb nicht nur Qualitätsfrage.
Sie ist auch Infrastrukturfrage.
Overlap erhöht die Datenmenge zusätzlich
Wenn benachbarte Chunks sich überlappen:
Chunk 1:
A B C
Chunk 2:
C D E
wird C zweimal eingebettet.
Das hilft möglicherweise, Kontext über Grenzen hinweg zu erhalten.
Es erhöht aber:
Tokenverbrauch bei der Indexierung,
Vektoranzahl beziehungsweise Textmenge,
Redundanz.
Auch dieser Parameter sollte getestet statt dogmatisch festgelegt werden.
Überschriftenbasierte Chunks können bei Wissensartikeln besonders sinnvoll sein
Casiopeya-Artikel besitzen klare H2-Abschnitte.
Ein möglicher Chunk könnte bestehen aus:
H2-Überschrift
+
zugehöriger Text
Damit hat jeder Abschnitt bereits eine semantische Einheit.
Bei sehr langen H2-Abschnitten müsste weiter unterteilt werden.
Die vorhandene Inhaltsstruktur kann also direkt für RAG genutzt werden.
Ein Chunk sollte alleine genügend Sinn ergeben
Schlechter Chunk:
Dies gilt jedoch nur in diesem Fall.
Welcher Fall?
Die notwendige Information befindet sich im vorherigen Chunk.
Besser wäre, Kontext so zu gestalten, dass der Abschnitt möglichst selbstständig interpretierbar bleibt.
Das verbessert sowohl Embeddings als auch spätere LLM-Verarbeitung.
Dokumenttitel können zusätzlich eingebunden werden
Chunk:
"TTL beschreibt die Lebensdauer ..."
Mit Dokumenttitel:
Dokument:
Was ist DNS?
Abschnitt:
TTL
Text:
TTL beschreibt die Lebensdauer ...
Nun besitzt das Embedding mehr Kontext darüber, worum es geht.
Das kann die Retrievalqualität verbessern.
Aber Metadaten dürfen das Embedding nicht dominieren
Wenn in jedem Chunk hundertmal steht:
CASIOPEYA KI Wissen WordPress ...
wird die Repräsentation unnötig verzerrt.
Auch bei Embeddings gilt:
relevante Kontextinformation ja,
Keyword-Stuffing nein.
Embeddings müssen mit realen Fragen getestet werden
Ein theoretisch starkes Modell kann für deine Fachsprache schwächer sein.
Zum Beispiel:
deutsche Steuerbegriffe,
österreichisches Recht,
WordPress-Fachbegriffe,
medizinische Terminologie.
Deshalb sollte ein Testset aus wirklichen späteren Nutzerfragen bestehen.
Nicht nur aus generischen Benchmarkfragen.
Die richtige Evaluation könnte so aussehen
Frage 1
→ erwartete Dokumente A, C
Frage 2
→ erwartetes Dokument F
Frage 3
→ erwartete Dokumente B, D
Dann:
Embeddingmodell A
↓
Top 5
Embeddingmodell B
↓
Top 5
Vergleichen.
Erst dann weißt du, welches Modell für dein System besser funktioniert.
Der billigste Embeddingdienst kann wirtschaftlich trotzdem der beste sein
Wenn Modell A:
minimal bessere Benchmarkwerte
aber:
vierfach höhere Kosten
besitzt, kann Modell B für Millionen Dokumente vernünftiger sein.
Umgekehrt können schlechte Retrievalergebnisse anschließend teure große LLM-Aufrufe verursachen.
Man sollte deshalb die gesamte Pipeline betrachten.
Retrievalqualität beeinflusst LLM-Kosten
Schlechtes Retrieval:
20 Chunks laden
↓
großer Kontext
↓
teure Antwort
Gutes Retrieval:
5 relevante Chunks
↓
kleinerer Kontext
↓
bessere Informationsdichte
Embeddings beeinflussen damit indirekt:
Tokenverbrauch,
Latenz,
Halluzinationsrisiko.
Ein gutes Retrieval kann ein kleineres LLM leistungsfähiger machen
Großes Modell ohne passende Informationen:
muss raten
Kleineres Modell mit:
exakten relevanten Dokumenten
kann bei einer konkreten Wissensaufgabe hervorragend funktionieren.
Das zeigt erneut:
Modellgröße ist nur ein Teil der KI-Architektur.
Die Wissensbasis kann wichtiger sein als das Chatmodell
Für einen Firmenassistenten interessiert den Mitarbeiter vielleicht:
Wie lautet unsere interne Reisekostenregel?
Das größte allgemeine Modell der Welt hilft wenig, wenn es diese interne Richtlinie nicht kennt.
Ein gutes Embedding- und Retrievalsystem liefert:
die richtige Richtlinie.
Dann braucht das Sprachmodell hauptsächlich noch:
lesen,
zusammenfassen,
erklären.
Embeddings verschieben KI vom Modellwissen zu eigenem Wissen
Ohne Retrieval:
Was weiß das Modell?
Mit Retrieval:
Was steht in meinen Daten?
Das ist ein fundamentaler Unterschied.
Gerade für Unternehmen und Wissensportale ist das häufig wichtiger als die nächste kleine Verbesserung eines allgemeinen Sprachmodells.
Embeddings und Fine-Tuning werden häufig verwechselt
Du möchtest ein LLM mit deiner Unternehmensdokumentation verbinden.
Idee:
Dann trainiere ich das Modell mit allen PDFs.
Das ist häufig nicht die passende erste Lösung.
Wenn sich Wissen regelmäßig ändert, ist Retrieval meist wesentlich flexibler.
Dokument ändern
↓
Embedding aktualisieren
statt:
Dokument ändern
↓
Modell erneut trainieren
Fine-Tuning verändert eher das Modellverhalten
Vereinfacht:
RAG / Retrieval
→ Welche Information bekommt das Modell?
Fine-Tuning
→ Wie verhält sich das Modell?
Das ist keine absolute Trennung für jeden denkbaren Anwendungsfall.
Als praktisches Grundmodell ist sie sehr hilfreich.
Embeddings und Kontextfenster ergänzen sich
Ein riesiger Dokumentbestand:
10 Millionen Tokens
passt vielleicht nicht sinnvoll gleichzeitig in den Modellkontext.
Embeddings suchen:
die relevanten 5.000 Tokens
Diese gelangen dann ins Kontextfenster.
Damit löst Retrieval ein fundamentales Kontextproblem.
Man kann sich Embeddings als Bibliothekar vorstellen
Das Sprachmodell ist der Fachautor.
Der Embeddingindex ist der Bibliothekar.
Frage:
Was sagen unsere Unterlagen über Backups?
Der Bibliothekar sucht:
Regal 4
Ordner 7
Seiten 23–27
Der Autor liest diese Unterlagen und formuliert die Antwort.
Ohne Bibliothekar müsste der Autor:
die gesamte Bibliothek gleichzeitig lesen.
Oder:
aus dem Gedächtnis raten.
Eine gute Bibliothek braucht trotzdem Ordnung
Der beste semantische Suchalgorithmus hilft wenig, wenn:
Dokumente doppelt,
veraltet,
falsch,
schlecht benannt,
ohne Version
vorliegen.
RAG und Embeddings machen gutes Informationsmanagement nicht überflüssig.
Sie machen dessen Qualität sogar besonders sichtbar.
Garbage in, garbage out gilt auch hier
Wissensbasis:
falsche Anleitung
↓
perfektes Embedding
↓
perfektes Retrieval
↓
LLM
↓
perfekt formulierte falsche Antwort
Die Technik hat exakt funktioniert.
Die Ausgangsdaten waren schlecht.
Retrievalqualität und Wissensqualität müssen deshalb getrennt betrachtet werden.
Ein sinnvoller Produktionsprozess besitzt mehrere Qualitätsebenen
Dokumentqualität
↓
Chunkqualität
↓
Embeddingqualität
↓
Retrievalqualität
↓
Reranking
↓
Kontextqualität
↓
LLM-Antwort
↓
Verifikation
Jede Ebene beeinflusst die nächste.
Das erklärt auch, warum RAG-Projekte manchmal trotz eines sehr guten Sprachmodells enttäuschen.
Embeddings sind nicht „kleine LLM-Gedanken“
Ein weiterer falscher Eindruck wäre:
Das Embedding enthält die Zusammenfassung dessen, was das Sprachmodell über den Text denkt.
Ein Embedding ist eine numerische Repräsentation, die für bestimmte Ähnlichkeits- und Machine-Learning-Aufgaben optimiert wurde.
Es ist keine versteckte kleine Prosazusammenfassung.
Man kann Embeddings deshalb nicht sinnvoll lesen
[0.81, -0.27, 0.14, ...]
sagt einem Redakteur nichts.
Das ist völlig in Ordnung.
Embeddings sind eine Maschinenschnittstelle.
Menschen arbeiten weiterhin mit:
Text,
Titeln,
Dokumenten.
Was du dir über Embeddings merken solltest
Embeddings übersetzen Inhalte in numerische Vektorrepräsentationen.
Text
↓
Embedding-Modell
↓
Vektor
Semantisch ähnliche Inhalte können dadurch ähnliche Positionen beziehungsweise Richtungen in einem hochdimensionalen Vektorraum erhalten. Solche Repräsentationen werden unter anderem für semantische Suche, Ähnlichkeitsvergleich, Clustering und Klassifikation verwendet. (OpenAI)
Ein Embedding ist:
keine Datenbankantwort.
keine Verschlüsselung.
kein Hash.
keine verlustfreie Kompression.
keine Garantie für Wahrheit.
Es ist eine mathematische Repräsentation, mit der andere Systeme arbeiten können.
Der wichtigste Anwendungsfall für unser weiteres KI-Verständnis lautet:
Dokumente
↓
Embeddings
↓
Vektordatenbank
Frage
↓
Embedding
↓
ähnliche Dokumente finden
Die Ähnlichkeit kann beispielsweise über Cosine Similarity beziehungsweise verwandte Vektoroperationen bestimmt werden. Satz-Embedding-Verfahren wie Sentence-BERT wurden ausdrücklich dafür entwickelt, semantische Repräsentationen effizient über solche Ähnlichkeitsmaße vergleichen zu können. (arXiv)
Für große Datenbestände werden die Vektoren häufig in darauf optimierten Suchsystemen beziehungsweise Vektordatenbanken gespeichert. (OpenAI Help Center)
Dokumente werden dabei meist nicht als ein riesiger Block behandelt.
Sie werden in Chunks zerlegt:
Dokument
↓
Chunk 1
Chunk 2
Chunk 3
↓
je ein Embedding
Bei einer Anfrage werden anschließend passende Chunks gefunden.
Frage
↓
Embedding
↓
Top-K ähnliche Chunks
Diese Chunks können danach einem Sprachmodell als Kontext gegeben werden.
Damit entsteht der Kern unseres nächsten Themas:
Retrieval
+
Generation
=
RAG
Besonders wichtig ist aber:
semantisch ähnlich
≠
faktisch identisch
Die Sätze:
Maximal 16 GB RAM.
und:
Maximal 32 GB RAM.
können semantisch extrem ähnlich sein.
Trotzdem widersprechen sie sich an der entscheidenden Stelle.
Embeddings helfen deshalb beim Finden.
Sie übernehmen nicht automatisch die Faktenprüfung.
Ebenso sollte semantische Suche klassische Methoden nicht unnötig verdrängen.
Für:
Produktnummern
Fehlercodes
exakte Namen
URLs
kann Keyword-Suche hervorragend sein.
Eine starke Architektur kombiniert deshalb häufig:
Keyword Search
+
Vector Search
+
Metadatenfilter
+
Reranking
Und gerade für eigene KI-Wissenssysteme ist noch ein Prinzip entscheidend:
Nicht alles Wissen
in das Sprachmodell trainieren.
Sondern relevantes Wissen
im richtigen Moment finden
und in den Kontext geben.
Embeddings liefern dafür eines der wichtigsten Werkzeuge.