Kompresja indeksu wektorowego zmniejsza zużycie pamięci RAM, przechowując reprezentacje o niższej precyzji, ale wynikające z tego zniekształcenie odległości może obniżyć skuteczność wyszukiwania najbliższych sąsiadów.
Domowy indeks RAG może bez problemu pomieścić sto tysięcy fragmentów, a po latach gromadzenia dokumentów, zdjęć i transkrypcji zacząć być ograniczany przez pamięć. Kwantyzacja pozwala przechowywać w pamięci więcej wektorów, jednak jakość wyszukiwania zależy od tego, czy skompresowane odległości zachowują tę samą kolejność kandydatów co wartości w pełnej precyzji. Wynik zależy od rozkładu embeddingów, stopnia kompresji, typu indeksu, szerokości zbioru kandydatów oraz tego, czy oryginalne wektory pozostają dostępne do ponownego szeregowania.
Kompresja zmniejsza rozmiar wektorów, ale nie wszystkich kosztów indeksu
Indeks wektorowy wykorzystuje pamięć na wartości embeddingów, struktury grafowe lub partycjonujące, identyfikatory, metadane, narzut alokatora oraz tymczasowe bufory zapytań. Kompresja przede wszystkim zmniejsza rozmiar reprezentacji embeddingów. Łącza HNSW i metadane mogą pozostać podobne, dlatego całkowita oszczędność pamięci RAM może być mniejsza, niż sugerowałby współczynnik kompresji wektorów.
Wektory o wysokim wymiarze są kosztowne, ponieważ każdy wymiar przechowywany jako wartość w pełnej precyzji zwiększa zużycie pamięci i koszt obliczania odległości. Zastąpienie tych wartości zwartymi kodami zmniejsza rozmiar danych przechowywanych w pamięci i może poprawić efektywność pamięci podręcznej.
Praktyczna oszczędność zależy więc od budowy indeksu. Wektory zmiennoprzecinkowe o wysokim wymiarze zwykle oferują duży potencjał redukcji, natomiast małe wektory z rozbudowanymi połączeniami grafowymi mogą zapewnić proporcjonalnie mniejsze oszczędności. Przed kompresją i po niej mierz zużycie pamięci rezydentnej procesu oraz rozmiar plików indeksu, zamiast mnożyć surowy rozmiar wektorów przez liczbę dokumentów.
Kwantyzacja wprowadza zniekształcenie odległości
Kwantyzacja skalarna mapuje każdy wymiar na mniejszy zakres liczbowy, natomiast kwantyzacja produktowa dzieli wektor na podprzestrzenie i przechowuje wybory z kodowników. Obie metody zastępują dokładne współrzędne przybliżeniami. Odległość zapytania jest następnie obliczana względem odtworzonych wartości lub odległości kodownika, a nie względem oryginalnego wektora zmiennoprzecinkowego.
Eksperymenty z kwantyzacją produktową oceniają kompresję, mierząc zniekształcenie odległości po odtworzeniu oraz skuteczność wyszukiwania. Bardziej zwarte kody mogą zmniejszyć opóźnienia lub zużycie pamięci, ale utrudniają też prawidłowe uporządkowanie bliskich sobie kandydatów, gdy ich rzeczywiste odległości są podobne.
Skuteczność wyszukiwania spada, gdy trafny sąsiad znajdzie się poniżej progu wyboru kandydatów, a nie po prostu dlatego, że każda odległość jest nieco błędna. Zapytania, w których między trafnymi i nietrafnymi fragmentami istnieje wyraźna różnica, mogą dobrze znosić silną kompresję; gęste sąsiedztwa semantyczne z wieloma niemal równorzędnymi wynikami są bardziej wrażliwe.
Poszerzenie zbioru kandydatów i ponowne szeregowanie mogą przywrócić skuteczność
Wyszukiwanie dwuetapowe wykorzystuje skompresowane wektory do znalezienia szerokiej listy wstępnej, a następnie ponownie oblicza odległości z użyciem wektorów o wyższej precyzji dla tych kandydatów. Nadpróbkowanie daje trafnym elementom więcej szans na przetrwanie przybliżonego pierwszego etapu, a ponowne szeregowanie przywraca właściwą kolejność tam, gdzie zwarte kody zatarły niewielkie różnice odległości.
Wyższe poziomy kompresji zazwyczaj obniżają skuteczność wyszukiwania, natomiast nadpróbkowanie i ponowne szeregowanie mogą poprawić dokładność. Odzyskiwanie jakości wymaga dodatkowych odczytów, pamięci i pracy podczas zapytania, dlatego kompresja przesuwa koszty między zasobami, zamiast całkowicie eliminować koszt jakościowy.
Przechowywanie pełnych wektorów na dysku może utrzymać niewielkie zużycie pamięci RAM, ale zwiększa opóźnienie przechowywania podczas ponownego szeregowania. Przechowywanie ich w RAM-ie poprawia opóźnienia, lecz zmniejsza korzyść z kompresji pamięci. Użyteczna konfiguracja zależy od tego, czy domowy serwer ogranicza pojemność pamięci, liczba operacji wejścia-wyjścia na sekundę nośnika, czy wymagania dotyczące czasu odpowiedzi.
Skuteczność trzeba mierzyć dla lokalnego zadania wyszukiwania
Zbuduj zbiór referencyjny, uruchamiając dokładne lub przeprowadzone z wysoką precyzją wyszukiwanie dla reprezentatywnych zapytań, a następnie porównaj, czy wyszukiwanie skompresowane zwraca tych samych trafnych sąsiadów w obrębie top-k. Uwzględnij parafrazy, nazwy własne, niemal identyczne dokumenty, rzadkie terminy oraz zapytania, których odpowiedź zależy od niewielkiej różnicy w materiale dowodowym.
Uzupełnia to pewność ugruntowania wyszukiwania: podobieństwo sąsiadów i wsparcie dla odpowiedzi są powiązane, ale nie są tym samym. Mierz Recall@k względem bazowego wyszukiwania, a także sprawdzaj, czy pominięte lub przestawione fragmenty zmieniają materiał dowodowy dostępny dla generatora.
Nie ma uniwersalnie najlepszego wyboru między maksymalną kompresją a maksymalną precyzją. Zwiększaj kompresję do momentu, w którym pamięć RAM, opóźnienia i skuteczność zadania osiągną pożądany kompromis, a następnie powtarzaj testy po zmianach modelu embeddingów lub korpusu. Konfiguracja sprawdzająca się przy ogólnym podobieństwie zdjęć może być zbyt stratna dla wyszukiwania w dokumentacji technicznej zawierającej wiele semantycznie sąsiadujących fragmentów.
Centrum Technologii i Sztucznej Inteligencji
Więcej do przeczytania

Dlaczego architektura domowego serwera Jellyfin zmienia się wraz z dodawaniem usług
Serwer Jellyfin staje się stosem usług w miarę dodawania kolejnych aplikacji, dlatego należy jasno określić odpowiedzialność za procesor, pamięć masową, sieć, dane uwierzytelniające, kopie...

Jak mierzyć wydajność Jellyfin, nie myląc pamięci podręcznej z wydajnością sprzętu
Wiarygodny test wydajności Jellyfin oznacza oddzielnie stan zimny i ciepły, aby buforowane metadane lub strony systemu plików nie zostały pomylone z trwałą wydajnością sprzętu.

Ile zapasu iGPU potrzebuje Jellyfin dla wielu użytkowników?
Zapas iGPU w Jellyfin zależy od rodzaju obciążenia: zachowaj margines powyżej najtrudniejszej powtarzalnej mieszanki jednoczesnych transkodowań, a nie arbitralnego procentu wykorzystania.

