Co powoduje, że wektorowa baza danych zwraca innych sąsiadów po kompaktowaniu?

Eva Wong

IceWhale author

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.

What Causes a Vector Database to Return Different Neighbors After Compaction? - Zima Store Online

Baza danych wektorowych może zwrócić innych sąsiadów po kompaktowaniu, ponieważ te same embeddingi mogą zostać przeorganizowane w nowo zbudowanej strukturze wyszukiwania przybliżonego.

W przypadku lokalnego serwera RAG ta zmiana często wygląda podejrzanie: celowo nie wykonano ponownego osadzania dokumentów, a mimo to znane zapytanie zwraca nieco inną listę top-k po konserwacji. Kluczowe jest rozróżnienie między wartościami wektorów a indeksem ANN, który je przeszukuje. Kompaktowanie może zachować pierwsze z nich, jednocześnie przebudowując drugie.

Kompaktowanie może zastąpić kilka segmentów wyszukiwania nowym indeksem

Baza danych wektorowych często gromadzi osobne segmenty w miarę wstawiania, aktualizowania i usuwania dokumentów. Kompaktowanie konsoliduje te elementy, dzięki czemu system ma mniej struktur do przeszukiwania i mniej nieaktualnych danych do przechowywania.

Qdrant udostępnia optymalizatory ukierunkowane na liczbę i rozmiar segmentów, zamiast traktować kolekcję jak jeden trwale niezmienny graf. Gdy kompaktowanie tworzy większy zoptymalizowany segment, fizyczna struktura wyszukiwania może zostać przebudowana, mimo że wektory logiczne pozostają niezmienione.

To rozróżnienie ma znaczenie w przypadku prywatnego indeksu RAG: embeddingi mogą mieć identyczne wartości liczbowe przed konserwacją i po niej, podczas gdy przybliżony graf wyszukiwania łączący te wektory będzie inny.

Przybliżone wyszukiwanie najbliższych sąsiadów zależy od topologii grafu

HNSW nie porównuje zapytania ze wszystkimi wektorami. Nawiguje po wielowarstwowym grafie i podąża ograniczonym zestawem obiecujących połączeń, dlatego przebyta ścieżka wpływa na to, którzy kandydaci zostaną sprawdzeni.

Elasticsearch wyjaśnia, że podczas scalania segmentów może być konieczne ponowne obliczenie grafów HNSW. Przebudowany graf może łączyć te same wektory w inny sposób, ponieważ na krawędzie wpływają kolejność tworzenia, stan usunięcia oraz heurystyki grafu.

Jeśli dwóch kandydatów ma bardzo podobne odległości, niewielka zmiana topologii może sprawić, że jeden trafi do zbioru kandydatów, a drugi nie zostanie odwiedzony. Rezultatem są inni przybliżeni sąsiedzi bez żadnej zmiany modelu embeddingów.

Parametry wyszukiwania decydują o zakresie eksploracji nowego grafu

Po kompaktowaniu baza danych może przeszukiwać jeden większy graf zamiast kilku mniejszych. To samo żądanie top-k może więc przechodzić przez inną przestrzeń kandydatów, nawet gdy skonfigurowany budżet wyszukiwania wydaje się niezmieniony.

Weaviate opisuje kompromis między parametrem ef HNSW a jakością wyszukiwania: większa lista kandydatów zazwyczaj poprawia odtwarzalność wyników, zwiększając jednocześnie nakład pracy. W pobliżu granicy rankingu niewielki wysiłek wyszukiwania zwiększa wrażliwość wyników na sposób zbudowania grafu.

Przydatną metodą diagnostyczną jest porównanie wyników przybliżonych z wyszukiwaniem o wysokiej wartości ef lub z wyszukiwaniem dokładnym na małym zestawie testowym. Jeśli dokładni sąsiedzi pozostają stabilni, a sąsiedzi ANN się zmieniają, kompaktowanie zmieniło ścieżkę wyszukiwania, a nie wektory.

Featured

ZimaCube 2 Osobisty domowy NAS w chmurze

ZimaCube2

Usunięcia i aktualizacje zmieniają to, które węzły przetrwają przebudowę

Przed kompaktowaniem usunięte lub zastąpione rekordy mogą nadal istnieć fizycznie jako znaczniki usunięcia lub wpisy w ewidencji na poziomie segmentu. Wyszukiwanie je odfiltrowuje, ale ich wcześniejsza obecność może wpływać na graf zbudowany wcześniej.

Milvus wyjaśnia, że HNSW przechowuje jawną strukturę grafu oprócz surowych wektorów. Przebudowa po usunięciu nieaktualnych rekordów tworzy graf na podstawie zbioru, który pozostał.

Może to zmienić lokalne połączenia wokół dokumentu domowego, nawet jeśli sam dokument nigdy nie był edytowany. Notatka może zyskać lub stracić pobliski węzeł pośredniczący, zmieniając region, do którego wyszukiwanie ANN dotrze jako pierwszego.

Remisy i wyniki bardzo zbliżone mogą się odwrócić, nawet gdy odległości się nie zmieniają

Wiele prywatnych zbiorów zawiera niemal identyczne dane: powtarzające się instrukcje, pliki w różnych wersjach, podpisy zdjęć, skopiowane notatki lub fragmenty z tym samym tekstem szablonowym. Ich wyniki cosinusowe lub iloczyny skalarne mogą być niemal nie do odróżnienia.

Wyjaśnienie HNSW firmy Pinecone pokazuje, jak ograniczenia nawigacji po grafie wyznaczają sprawdzane wektory. Gdy dwa elementy znajdują się blisko progu, inna ścieżka kandydatów lub kolejność rozstrzygania remisu może zmienić zwracane top-k bez istotnej różnicy semantycznej.

Aplikacje nie powinny więc traktować pozycji 7 zamiast 8 na liście sąsiadów jako trwałego twierdzenia o tożsamości. Gdy deterministyczne zachowanie ma znaczenie, należy przechowywać stabilne identyfikatory dokumentów i porównywać rzeczywiste odległości.

Wyszukiwanie dokładne wyznacza granicę między zmianą danych a zmianą ANN

Najlepszym sposobem rozdzielenia tych zjawisk jest utrzymywanie małego, powtarzalnego zestawu zapytań oraz rejestrowanie przed konserwacją embeddingów, metryki odległości, dokładnych wyników top-k, przybliżonych wyników top-k, ustawień indeksu i wersji bazy danych.

Omówienie zmian domeny embeddingów w prywatnym wyszukiwaniu opublikowane przez ZimaSpace dotyczy innej klasy problemów: zmienia się sama przestrzeń wektorowa. Kompaktowanie należy diagnozować osobno, ponieważ może zmienić przybliżone wyszukiwanie, pozostawiając tę przestrzeń bez zmian.

Przewodnik ZimaSpace dotyczący wyszukiwania dokumentów i przepływów RAG przedstawia kontekst aplikacyjny: stabilna tożsamość dokumentów i ewaluacja mają znaczenie, nawet gdy warstwa ANN może działać przybliżenie.

Jeśli zmieniają się dokładne wyniki, należy sprawdzić wektory, filtry, normalizację, metrykę lub wersje danych. Jeśli dokładne wyniki pozostają bez zmian, a wyniki ANN się zmieniają, przyczyną jest rekonstrukcja indeksu, nakład pracy wyszukiwania, obsługa remisów lub układ segmentów.

Kompaktowanie nie powinno zatem gwarantować identycznej co do bajta kolejności sąsiadów w przybliżonym indeksie. Deterministyczne sortowanie wymaga dokładniejszego wyszukiwania lub reguł rozstrzygania remisów na poziomie aplikacji.

FAQ

Czy kompaktowanie zmienia wektory embeddingów?

Nie samo w sobie. Standardowe kompaktowanie lub scalanie segmentów reorganizuje pamięć masową i indeksy. Embeddingi zmieniają się tylko wtedy, gdy aplikacja ponownie je generuje, poddaje kwantyzacji, normalizuje lub w inny sposób przepisuje wartości wektorów.

Czy dokładni najbliżsi sąsiedzi powinni zmienić się po kompaktowaniu?

Powinni pozostać tacy sami, jeśli zachowane wektory, metryka i reprezentacja liczbowa są niezmienione, z wyjątkiem rzeczywistych remisów wyników lub szczegółów implementacji zmiennoprzecinkowej.

Czy przebudowa HNSW może odtworzyć dokładnie dawny ranking?

Nie zawsze. HNSW jest przybliżony, a budowa grafu może zależeć od kolejności wstawiania, randomizacji, usunięć i szczegółów implementacji. Dokładny ranking wymaga wyczerpującego lub innego deterministycznego porównania.