Czy w jednym prywatnym systemie wyszukiwania mogą współistnieć różne modele osadzania?

Eva Wong jest Technicznym pisarzem i stałym majsterkowiczem w ZimaSpace. Całe życie geek z pasją do homelabów i oprogramowania open-source, specjalizuje się w tłumaczeniu skomplikowanych koncepcji technicznych na przystępne, praktyczne przewodniki. Eva wierzy, że samodzielne hostowanie powinno być zabawą, a nie czymś onieśmielającym. Poprzez swoje samouczki umożliwia społeczności rozwiewanie tajemnic konfiguracji sprzętu, od budowy pierwszego NAS po opanowanie kontenerów Docker.

Tak. Jeden prywatny system wyszukiwania może jednocześnie przechowywać i wyszukiwać osadzenia z wielu modeli. Bezpieczne podejście polega na traktowaniu każdego modelu osadzania jako własnej przestrzeni wektorowej z określonym wymiarem, metryką odległości, wersją i konfiguracją indeksu. Nie mieszaj niekompatybilnych wektorów w jednej anonimowej kolumnie, zakładając, że można je porównywać.

Wiele modeli jest przydatnych podczas migracji, wyszukiwania wielojęzycznego, wyszukiwania łączącego obrazy i tekst, tworzenia osadzeń specyficznych dla danej dziedziny lub testów A/B. Złożoność pojawia się wtedy, gdy trzeba połączyć wyniki z tych przestrzeni.

Dlaczego warto przechowywać więcej niż jeden model osadzania?

Powód Przykład
Migracja modelu Stary enkoder pozostaje aktywny, podczas gdy nowe wektory są uzupełniane
Wyszukiwanie wielojęzyczne Ogólny model języka angielskiego + model wielojęzyczny
Różne modalności Osadzania tekstu + osadzania obrazów
Specjalizacja dziedzinowa Dokumenty ogólne + osadzania kodu
Testowanie jakości Testowanie wyszukiwania A/B przed zastąpieniem modelu produkcyjnego
Późna interakcja Gęsty retriever + reranking w stylu ColBERT

Prywatna baza wiedzy ewoluuje. Trwałe przypisanie każdego dokumentu do pierwszego wybranego modelu osadzania sprawia, że aktualizacje stają się niepotrzebnie uciążliwe.

Różne modele tworzą różne przestrzenie wektorowe

Dwa modele mogą generować wektory o długości 768 i nadal być ze sobą niekompatybilne. Współrzędne mają znaczenie wyłącznie w odniesieniu do modelu, który je wygenerował.

Dokument A
  |
  +-- Model v1 -> vector_v1 [768]
  |
  +-- Model v2 -> vector_v2 [1024]
  |
  +-- model obrazu -> vector_image [512]

Zapytanie wygenerowane za pomocą modelu v2 powinno przeszukiwać przestrzeń v2. Bezpośrednie porównywanie go z wektorami modelu v1 nie ma sensu, nawet jeśli interfejs API akceptuje takie wymiary.

Aktualna dokumentacja nazwanych wektorów Qdrant wyraźnie obsługuje wiele wektorów o różnych rozmiarach i typach w tym samym punkcie, z których każdy znajduje się w osobnej nazwanej przestrzeni wektorowej.

Używaj rejestru modeli, a nie tylko nazwy wektora

Zapisuj wystarczającą ilość metadanych, aby odtworzyć każde osadzenie:

przestrzeń_wektorowa: text_v2
identyfikator_modelu:        example/model-name
wersja_modelu:  sha-lub-wersja
wymiar_wektora:      1024
metryka:          kosinusowa
znormalizowano:      tak
zasady_segmentacji: semantyczne-v3
utworzono:      2026-09-03

Dzielenie na fragmenty również powinno należeć do rejestru. Jeśli zmienisz zarówno model embeddingów, jak i sposób dzielenia dokumentów, wyszukiwanie zmieni się z dwóch powodów. Jawne określenie wersji potoku umożliwia porównanie i wycofanie zmian.

-15% OFF

Jedna kolekcja z nazwanymi wektorami czy oddzielne kolekcje?

Oba projekty mogą być poprawne.

Projekt Najlepsze zastosowanie Kompromis
Nazwane wektory w tym samym obiekcie Te same dokumenty/ładunki we wszystkich modelach Większy rozmiar obiektów i indeksów
Oddzielne kolekcje Różne schematy, cykle życia, skala lub uprawnienia Więcej pracy związanej z synchronizacją
Jedna tabela PostgreSQL + model_id Stos oparty na SQL Indeksy muszą mieć prawidłowo określony zakres

Dokumentacja kolekcji Weaviate również obsługuje wiele nazwanych przestrzeni wektorowych w jednym obiekcie, z których każda ma własną konfigurację wektoryzera i indeksu.

Jeśli uprawnienia są różne — na przykład dokumenty rodzinne i służbowe — osobne kolekcje mogą być przejrzystszym rozwiązaniem niż umieszczanie każdej reprezentacji w jednym obiekcie.

Czy pgvector może przechowywać różne liczby wymiarów?

Tak. Dokumentacja pgvector pokazuje ogólną kolumnę vector z wartością model_id, a następnie wykorzystuje indeksy wyrażeń i indeksy częściowe dla wierszy o określonej liczbie wymiarów.

Zasada jest taka sama: zachowaj identyfikator modelu w modelu danych i twórz indeks ANN wyłącznie dla zgodnych wierszy.

Nie porównuj surowych wyników podobieństwa między modelami

To najbardziej subtelny problem. Podobieństwo cosinusowe 0,78 z Modelu A nie musi oznaczać takiej samej jakości jak 0,78 z Modelu B. Rozkłady wyników zależą od trenowania modelu, normalizacji, metryki, domeny i działania indeksu.

Jeśli chcesz uzyskać jedną listę wyników z dwóch modeli embeddingów, najpierw wyszukuj osobno:

Zapytanie
  |
  +-- Model A -> 20 najlepszych wyników + rankingi
  |
  +-- Model B -> 20 najlepszych wyników + rankingi
                      |
                      v
               fuzja / reranker
                      |
                      v
                  ostateczne 10 najlepszych wyników

Bezpieczniejsze metody łączenia obejmują fuzję rankingów, normalizację wyników specyficzną dla modelu, skalibrowaną na Twoich danych, lub cross-encoder/reranker oceniający tekst kandydata po wyszukaniu.

Dokumentacja wyszukiwania wielokierunkowego Weaviate przedstawia strategie łączenia, w tym kombinacje znormalizowane i ważone, co pokazuje, dlaczego fuzja wyników z różnych przestrzeni wymaga określonej strategii, a nie naiwnego sortowania według surowych wyników.

Jak przeprowadzić migrację do nowego modelu embeddingów bez przestoju?

Najpierw nie usuwaj starych embeddingów. Użyj migracji równoległej:

  1. zarejestruj nowy model i przestrzeń wektorową;
  2. generuj nowe embeddingi dla nowo pozyskanych dokumentów;
  3. uzupełniaj stare dokumenty partiami;
  4. uruchamiaj równoległe wyszukiwanie w obu przestrzeniach;
  5. porównaj trafność i skuteczność realizacji zadań na rzeczywistych pytaniach;
  6. przełącz domyślną przestrzeń zapytań;
  7. zachowaj stare wektory na czas umożliwiający wycofanie zmian;
  8. usuwaj je dopiero, gdy zyskasz wysoką pewność.

Weaviate zaznacza, że dodanie nowego nazwanego wektora nie powoduje automatycznej ponownej wektoryzacji istniejących obiektów. Warto o tym pamiętać, ponieważ „schemat obsługuje nowy model” i „wszystkie stare dane mają nowe wektory” to dwa odrębne etapy.

Wiele embeddingów zwiększa zajętość miejsca szybciej, niż przewiduje wielu użytkowników

Każda dodatkowa reprezentacja wektorowa może dodać kolejną gęstą tablicę oraz kolejny indeks ANN. Drugi model embeddingów może więc w przybliżeniu podwoić wektorową i indeksową część bazy danych, mimo że oryginalne dokumenty są przechowywane tylko raz.

Szacunek:

bajty wektorów ~=
  fragmenty dokumentów
  x liczba wymiarów
  x liczba bajtów na element
  x liczba przestrzeni embeddingów

+ narzut indeksu ANN
+ indeksy metadanych / payloadów

Indeksy z kwantyzacją lub niską precyzją mogą zmniejszyć zajmowane miejsce, ale przed zastosowaniem kompresji do każdego modelu sprawdź jakość wyszukiwania.

Więcej informacji na temat architektury lokalnej bazy wiedzy: embeddingi to wymienne dane pochodne, natomiast dokumenty źródłowe i metadane są trwałymi zasobami, które pozwalają je odtworzyć.

Używaj różnych modeli dla różnych ścieżek zapytań

Nie musisz przeszukiwać każdej przestrzeni wektorowej dla każdego pytania. Kieruj zapytania zgodnie z potrzebą:

Zapytanie Przestrzeń embeddingów
Instrukcje domowe po angielsku general_text_v2
Notatki po chińsku i angielsku multilingual_v1
Pytanie dotyczące kodu źródłowego code_v1
Znajdź podobne zdjęcie image_v1
Nieznane / szerokie wyszukiwanie dwie przestrzenie + fuzja rankingów

Niewielki klasyfikator zapytań może wybrać odpowiednią przestrzeń, natomiast niejednoznaczne wyszukiwania mogą być kierowane do dwóch reprezentacji, a następnie łączyć wyniki.

Uprawnienia muszą obowiązywać przed fuzją

Nie pobieraj nieautoryzowanych kandydatów z każdej przestrzeni wektorowej w nadziei, że końcowy reranker ich ukryje. Stosuj uprawnienia użytkownika i dokumentu na każdym etapie pobierania danych, aby poufne fragmenty nie trafiały do zbioru kandydatów, dzienników ani promptu rerankera.

W przypadku prywatnego wyszukiwania na serwerze NAS ta sama zasada kontroli dostępu musi obowiązywać podczas migracji modeli. Nowy indeks powinien dziedziczyć metadane uprawnień dokumentu, zamiast stawać się tymczasową, niezabezpieczoną kopią.

Przewodnik po prywatnym asystencie AI zapewnia szerszy kontekst: wyszukiwanie wektorowe jest użyteczne tylko wtedy, gdy respektuje te same granice prywatności danych co magazyn plików.

Lista kontrolna QA dla wielu osadzeń

  • Nadaj każdej przestrzeni osadzeń unikalny identyfikator modelu i wersji.
  • Zapisuj wymiary, normalizację i metrykę odległości.
  • Wersjonuj dzielenie na fragmenty i wstępne przetwarzanie.
  • Nigdy nie odpytuj indeksu jednego modelu wektorem innego modelu.
  • Nie porównuj bezpośrednio surowych wyników między przestrzeniami bez kalibracji.
  • Stosuj uprawnienia w każdej ścieżce pobierania danych.
  • Uzupełnij nowe wektory przed zmianą modelu domyślnego.
  • Oceniaj rozwiązanie na podstawie rzeczywistych pytań i znanych trafnych dokumentów.
  • Zachowaj poprzedni indeks przez okres umożliwiający wycofanie zmian.
  • Uwzględnij dodatkowe wektory i indeksy w planowaniu pojemności dysku i pamięci RAM.

Najczęściej zadawane pytania

Czy dwa modele osadzania mogą używać różnych wymiarów w jednej bazie danych?

Tak, jeśli baza danych obsługuje oddzielne nazwane przestrzenie wektorowe, kolekcje lub indeksy dla każdego zgodnego wymiaru. Qdrant, Weaviate i pgvector oferują wzorce umożliwiające takie rozwiązanie.

Czy mogę zmienić modele osadzania bez ponownego osadzania starych dokumentów?

Nie, jeśli chcesz, aby stare dokumenty były wyszukiwalne w przestrzeni wektorowej nowego modelu. Nowy wektor zapytania nie jest zgodny z osadzeniami wygenerowanymi przez inny model.

Czy powinienem zachować stare osadzenia na zawsze?

Nie. Zachowaj je na czas ewaluacji i wycofywania zmian. Po zweryfikowaniu nowego modelu i zakończeniu migracji usunięcie przestarzałych wektorów może odzyskać znaczną ilość miejsca oraz pamięci indeksu.

Ostateczny werdykt

Wiele modeli osadzania może bezproblemowo współistnieć w jednym prywatnym systemie wyszukiwania, gdy ich przestrzenie wektorowe pozostają jawnie rozdzielone. Przechowuj metadane modelu i potoku, odpytuj każdą przestrzeń za pomocą odpowiadającego jej enkodera, świadomie łącz wyniki i migruj, uzupełniając dane równolegle. Niebezpieczny projekt nie polega na używaniu „więcej niż jednego modelu”. Problemem jest utrata informacji o tym, który model wygenerował dany wektor, oraz udawanie, że każdy wynik podobieństwa oznacza to samo.

Centrum Technologii i Sztucznej Inteligencji

Więcej do przeczytania

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.