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.
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:
- zarejestruj nowy model i przestrzeń wektorową;
- generuj nowe embeddingi dla nowo pozyskanych dokumentów;
- uzupełniaj stare dokumenty partiami;
- uruchamiaj równoległe wyszukiwanie w obu przestrzeniach;
- porównaj trafność i skuteczność realizacji zadań na rzeczywistych pytaniach;
- przełącz domyślną przestrzeń zapytań;
- zachowaj stare wektory na czas umożliwiający wycofanie zmian;
- 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

10 najlepszych lokalnych interfejsów internetowych AI do domowych laboratoriów w 2026 roku
Porównaj 10 lokalnych interfejsów internetowych AI do samodzielnego hostowania w domowych laboratoriach, uwzględniając obsługę Ollama, RAG, agentów, dostęp wielu użytkowników, poziom trudności konfiguracji oraz...

Ile z czasem kosztuje GPT-6 Astra? Kiedy chmurowa sztuczna inteligencja ma sens w porównaniu z lokalną sztuczną inteligencją
Praktyczny przewodnik po kosztach GPT-6 Astra obejmujący zużycie tokenów, długoterminowe obciążenia AI, kompromisy między chmurą a infrastrukturą lokalną oraz znaczenie hybrydowej infrastruktury AI.

GPT-6 Astra kontra lokalna sztuczna inteligencja: które elementy agenta powinny pozostać na Twoim domowym serwerze?
GPT-6 Astra może pozostać w chmurze, podczas gdy Twój serwer domowy przechowuje lokalnie pliki, pamięć, dane RAG, narzędzia, uprawnienia i trwały stan agenta.

