Können mehrere Embedding-Modelle in einem privaten Suchsystem koexistieren?

Ja. Ein privates Suchsystem kann Embeddings mehrerer Modelle gleichzeitig speichern und abfragen. Der sichere Ansatz besteht darin, jedes Embedding-Modell als eigenen Vektorraum mit expliziten Dimensionen, Distanzmetrik, Version und Indexkonfiguration zu behandeln. Mischen Sie inkompatible Vektoren nicht in einer anonymen Spalte und gehen Sie nicht davon aus, dass sie vergleichbar sind.

Mehrere Modelle sind für Migrationen, mehrsprachige Suche, Bild-und-Text-Retrieval, domänenspezifische Embeddings oder A/B-Tests nützlich. Die Komplexität entsteht, wenn Ergebnisse aus diesen Vektorräumen kombiniert werden müssen.

Warum sollten Sie mehr als ein Embedding-Modell verwenden?

Eine private Wissensdatenbank entwickelt sich weiter. Wenn jedes Dokument dauerhaft an das zuerst ausgewählte Embedding-Modell gebunden wird, werden Upgrades unnötig störend.

Unterschiedliche Modelle erzeugen unterschiedliche Vektorräume

Zwei Modelle können beide Vektoren mit 768 Dimensionen erzeugen und dennoch inkompatibel sein. Die Koordinaten haben nur im Verhältnis zu dem Modell, das sie erzeugt hat, eine Bedeutung.

Dokument A
  |
  +-- Modell v1 -> vector_v1 [768]
  |
  +-- Modell v2 -> vector_v2 [1024]
  |
  +-- Bildmodell -> vector_image [512]

Eine mit Modell v2 erzeugte Abfrage sollte den v2-Vektorraum durchsuchen. Ein direkter Vergleich mit Vektoren von Modell v1 ist bedeutungslos, selbst wenn eine API die Dimensionen akzeptiert.

Die aktuelle Dokumentation zu benannten Vektoren von Qdrant unterstützt ausdrücklich mehrere Vektoren unterschiedlicher Größe und unterschiedlichen Typs im selben Punkt, jeweils unter einem separaten benannten Vektorraum.

Verwenden Sie eine Modellregistrierung, nicht nur einen Vektornamen

Speichern Sie genügend Metadaten, um jedes Embedding zu reproduzieren:

Embedding-Raum: text_v2
Modell-ID:        example/model-name
Modellrevision:  sha-or-version
Vektordimension:      1024
Metrik:          Kosinus
Normalisiert:      true
Chunking-Richtlinie: semantisch-v3
Erstellt am:      2026-09-03

Auch die Chunk-Aufteilung gehört in die Registry. Wenn Sie sowohl das Embedding-Modell als auch die Aufteilung der Dokumente ändern, verändert sich der Abruf aus zwei Gründen. Durch die explizite Angabe der Pipeline-Version werden Vergleiche und Rollbacks möglich.

-15% OFF

ZimaBoard 2 – Mini-Heimserver für Ihre große Idee

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Eine Sammlung mit benannten Vektoren oder separate Sammlungen?

Beide Designs können korrekt sein.

Die Dokumentation zu Weaviate-Sammlungen unterstützt ebenfalls mehrere benannte Vektorräume pro Objekt, jeweils mit eigener Vektorisierer- und Indexkonfiguration.

Wenn sich die Zugriffsberechtigungen unterscheiden – beispielsweise zwischen privaten und beruflichen Dokumenten –, können separate Sammlungen übersichtlicher sein, als jede Repräsentation in ein einziges Objekt zu packen.

Kann pgvector unterschiedliche Dimensionen speichern?

Ja. Die Dokumentation von pgvector zeigt eine generische vector-Spalte mit einer model_id und verwendet anschließend Ausdrucks- und partielle Indizes für Zeilen mit einer bestimmten Dimensionalität.

Das Prinzip ist dasselbe: Bewahren Sie die Modellidentität im Datenmodell und erstellen Sie den ANN-Index nur über kompatible Zeilen.

Vergleichen Sie keine rohen Ähnlichkeitswerte zwischen Modellen

Dies ist der subtilste Fehler. Eine Kosinusähnlichkeit von 0,78 bei Modell A bedeutet nicht unbedingt dieselbe Qualität wie 0,78 bei Modell B. Die Score-Verteilungen hängen vom Modelltraining, der Normalisierung, der Metrik, der Domäne und dem Indexverhalten ab.

Wenn Sie aus zwei Embedding-Modellen eine gemeinsame Ergebnisliste erstellen möchten, rufen Sie die Ergebnisse zunächst separat ab:

Abfrage
  |
  +-- Modell A -> Top-20-Ergebnisse + Ränge
  |
  +-- Modell B -> Top-20-Ergebnisse + Ränge
                      |
                      v
               Fusion / Reranker
                      |
                      v
                  abschließende Top 10

Zu den sichereren Kombinationsmethoden gehören die Rangfusion, eine modellspezifische Score-Normalisierung, die anhand Ihrer Daten kalibriert wurde, oder ein Cross-Encoder/Reranker, der den Kandidatentext nach dem Abruf bewertet.

Die Dokumentation von Weaviate zur Suche mit mehreren Zielvektoren beschreibt Strategien für die Zusammenführung, darunter normalisierte und gewichtete Kombinationen. Dies verdeutlicht, warum die Fusion über mehrere Bereiche eine explizite Strategie statt einer naiven Sortierung nach Rohbewertungen erfordert.

Wie migriert man ohne Ausfallzeit zu einem neuen Embedding-Modell?

Löschen Sie die alten Embeddings nicht zuerst. Verwenden Sie eine parallele Migration:

1. Registrieren Sie das neue Modell und den neuen Vektorbereich;
2. Erzeugen Sie neue Embeddings für neu erfasste Dokumente;
3. Füllen Sie alte Dokumente stapelweise nach;
4. Führen Sie parallele Suchvorgänge in beiden Bereichen im Hintergrund aus;
5. Vergleichen Sie Recall und Aufgabenerfolg anhand echter Fragen;
6. Wechseln Sie zum standardmäßigen Abfragebereich;
7. Behalten Sie die alten Vektoren während eines Rücksetzungszeitraums;
8. Entfernen Sie sie erst, wenn Sie ausreichend Vertrauen haben.

Weaviate weist darauf hin, dass das Hinzufügen eines neuen benannten Vektors bestehende Objekte nicht automatisch erneut vektorisiert. Dieses Verhalten sollte man im Hinterkopf behalten, denn „Das Schema unterstützt das neue Modell“ und „Alle alten Daten verfügen über neue Vektoren“ sind getrennte Meilensteine.

Mehrere Embeddings erhöhen den Speicherbedarf schneller, als viele Nutzer erwarten

Jede zusätzliche Vektordarstellung kann ein weiteres dichtes Array sowie einen weiteren ANN-Index hinzufügen. Ein zweites Embedding-Modell kann den Vektor-/Indexanteil der Datenbank daher ungefähr verdoppeln, obwohl die Originaldokumente nur einmal gespeichert werden.

Schätzung:

Vektorbytes ~=
  Dokumentabschnitte
  x Dimensionen
  x Bytes pro Element
  x Anzahl der Embedding-Bereiche

+ Overhead des ANN-Index
+ Metadaten- / Payload-Indizes

Quantisierte oder Indizes mit halber Genauigkeit können den Speicherbedarf reduzieren. Testen Sie jedoch die Abrufqualität, bevor Sie die Komprimierung auf jedes Modell anwenden.

Dies knüpft an die Frage der Architektur lokaler Wissensdatenbanken an: Embeddings sind ersetzbare abgeleitete Daten, während Quelldokumente und Metadaten die beständigen Ressourcen sind, mit denen sie neu erstellt werden können.

Verschiedene Modelle für verschiedene Abfragerouten verwenden

Sie müssen nicht jede Vektordarstellung für jede Frage durchsuchen. Leiten Sie die Suche je nach Bedarf weiter:

Ein kleiner Abfrageklassifikator kann den passenden Bereich auswählen, während mehrdeutige Suchen über zwei Repräsentationen hinweg ausgeweitet und die Ergebnisse zusammengeführt werden können.

Berechtigungen müssen vor der Fusion angewendet werden

Rufe nicht unbefugte Kandidaten aus jedem Vektorraum ab und hoffe, dass der abschließende Reranker sie verborgen hält. Wende Benutzer- und Dokumentberechtigungen in jeder Abrufstufe an, damit sensible Chunks nicht in den Kandidatensatz, die Protokolle oder den Reranker-Prompt gelangen.

Bei der Suche auf einem privaten NAS muss dieselbe Zugriffskontrollregel auch bei Modellmigrationen erhalten bleiben. Ein neuer Index sollte die Berechtigungsmetadaten des Dokuments übernehmen, anstatt zu einer vorübergehend ungeschützten Kopie zu werden.

Der Leitfaden zum privaten KI-Assistenten bietet den größeren Kontext: Vektorsuche ist nur dann nützlich, wenn sie dieselben Grenzen für private Daten respektiert wie der Dateispeicher.

QA-Checkliste für mehrere Embeddings

• Gib jedem Embedding-Raum eine eindeutige Modell-/Versions-ID.
• Dokumentiere Dimensionen, Normalisierung und Distanzmetrik.
• Versioniere Chunking und Vorverarbeitung.
• Frage niemals den Index eines anderen Modells mit dem Vektor eines Modells ab.
• Vergleiche rohe Werte aus verschiedenen Räumen nicht direkt, ohne sie zu kalibrieren.
• Setze Berechtigungen innerhalb jedes Abrufpfads durch.
• Fülle die neuen Vektoren nach, bevor du den Standard änderst.
• Evaluiere mit echten Fragen und bekannten relevanten Dokumenten.
• Behalte den bisherigen Index während eines Rollback-Zeitfensters.
• Berücksichtige zusätzliche Vektoren und Indizes bei der Kapazitätsplanung für Festplatte und RAM.

FAQs

Können zwei Embedding-Modelle in einer Datenbank unterschiedliche Dimensionen verwenden?

Ja, wenn die Datenbank für jede kompatible Dimension separate benannte Vektorräume, Sammlungen oder Indizes unterstützt. Qdrant, Weaviate und pgvector bieten dafür entsprechende Ansätze.

Kann ich das Embedding-Modell wechseln, ohne alte Dokumente erneut zu vektorisieren?

Nicht, wenn du die alten Dokumente im Vektorraum des neuen Modells durchsuchbar halten möchtest. Ein neuer Abfragevektor ist nicht mit Embeddings kompatibel, die von einem anderen Modell erzeugt wurden.

Soll ich alte Embeddings für immer behalten?

Nein. Behalte sie während der Evaluierung und für ein Rollback. Sobald das neue Modell validiert und die Migration abgeschlossen ist, können veraltete Vektoren entfernt werden, wodurch sich erheblicher Speicherplatz und Indexspeicher zurückgewinnen lassen.

Abschließendes Urteil

Mehrere Embedding-Modelle können problemlos in einem privaten Suchsystem koexistieren, wenn ihre Vektorräume eindeutig bleiben. Speichere Modell- und Pipeline-Metadaten, frage jeden Raum mit dem passenden Encoder ab, führe die Ergebnisse gezielt zusammen und migriere durch paralleles Nachbefüllen. Das gefährliche Design ist nicht „mehr als ein Modell“, sondern der Verlust des Überblicks darüber, welches Modell welchen Vektor erzeugt hat, sowie die Annahme, dass jeder Ähnlichkeitswert dasselbe bedeutet.