Dlaczego wiele kolekcji RAG konkuruje o pamięć RAM na serwerze domowym?
Wiele kolekcji RAG konkuruje o pamięć RAM, ponieważ każda z nich utrzymuje własne wektory, graf wyszukiwania, indeksy metadanych, pamięci podręczne i aktywny zestaw roboczy.
Serwer domowy może rozdzielać dokumenty rodzinne, instrukcje techniczne, metadane zdjęć, notatki służbowe i historię inteligentnego domu na różne kolekcje RAG ze względów prywatności lub w celu uzyskania bardziej precyzyjnego wyszukiwania. Pliki źródłowe mogą bez problemu mieścić się na dysku, podczas gdy warstwa wyszukiwania zużywa znacznie więcej pamięci, niż oczekiwano. Każda kolekcja może ładować indeks przybliżonych najbliższych sąsiadów, filtry danych, metadane segmentów, ostatnio używane strony i bufory zapytań; usługi generowania embeddingów i rerankingu dodają obok tych kolekcji własne rezydentne modele.
Każda kolekcja tworzy oddzielną strukturę wyszukiwania
Kolekcja wektorów to nie tylko folder z embeddingami. Wyszukiwarki zazwyczaj przechowują wartości wektorów oraz graf sąsiedztwa lub inną strukturę przybliżonego wyszukiwania, która pozwala uniknąć skanowania każdego rekordu.
Weaviate wskazuje wektory i grafy HNSW jako dwóch głównych użytkowników pamięci w przechowywanym w pamięci indeksie przybliżonych najbliższych sąsiadów.
Utworzenie pięciu kolekcji może więc oznaczać pięć niezależnie adresowalnych indeksów, nawet jeśli korzystają z tego samego modelu embeddingów i działają w jednym procesie bazy danych. Rozdzielenie poprawia zasady dostępu i utrzymanie tylko wtedy, gdy korzyści z wyszukiwania uzasadniają zwielokrotnienie zestawów roboczych.
Wymiary i narzut indeksu zwielokrotniają podstawowe zużycie pamięci
Surowe zużycie pamięci przez wektory rośnie wraz z liczbą wektorów, wymiarami embeddingów i liczbą bajtów przypadających na składową. Przeszukiwalny indeks dodaje do surowej tablicy odnośniki grafu, identyfikatory, wyrównanie, metadane i narzut alokatora.
Milvus udostępnia wzór na pamięć indeksu wektorowego i zauważa, że wdrożenie HNSW może wymagać znacznie więcej pamięci niż same nieindeksowane wektory.
Oszacuj każdą kolekcję osobno, a następnie zsumuj wyniki. Kolekcja zawierająca mniej dokumentów nadal może być kosztowna, jeśli korzysta z embeddingów o dużej liczbie wymiarów, składowych o pełnej precyzji lub grafu dostrojonego pod kątem wysokiego współczynnika trafności.
Spójność grafu to kompromis między pamięcią RAM, trafnością i szybkością
HNSW łączy każdy wektor z sąsiednimi węzłami. Większa liczba połączeń może poprawić nawigację i trafność, ale każda zapisana krawędź zużywa pamięć i zwiększa koszt tworzenia indeksu.
Redis wyjaśnia, jak spójność grafu jest kontrolowana przez parametry, które tworzą kompromis między rozmiarem indeksu, trafnością i sposobem działania wyszukiwania.
Różne kolekcje mogą dziedziczyć te same agresywne ustawienia domyślne, nawet jeśli tylko jedna z nich ich potrzebuje. Użyj profilu o niższym zużyciu pamięci dla małych archiwów lub kolekcji o niskiej współbieżności, zamiast dostrajać każdy indeks pod kątem najbardziej wymagającego obciążenia wyszukiwania.
Mapowanie pamięci przenosi obciążenie do współdzielonej pamięci podręcznej stron
Umieszczenie wektorów lub danych grafu na dysku z użyciem mapowania pamięci może zmniejszyć trwale rezydentną alokację procesu. Nie sprawia jednak, że aktywne strony stają się wolne; system operacyjny nadal buforuje w pamięci RAM ostatnio używane bloki indeksu.
Porównanie pamięci Qdrant pokazuje, jak wektory mapowane w pamięci zmniejszają mierzone zużycie RAM, jednocześnie wprowadzając kompromis dotyczący opóźnień, gdy dane są pobierane z pamięci masowej.
Gdy zapytania przeskakują między kilkoma kolekcjami, ich często używane strony mogą wzajemnie wypierać się z pamięci podręcznej stron. To samo obciążenie może wypierać dane systemu plików używane przez aplikacje do zdjęć, kontenery, bazy danych i udziały sieciowe na serwerze domowym.
Indeksy większe niż pamięć RAM płacą większą liczbą operacji wejścia-wyjścia
Indeks może przekraczać fizyczną pamięć i nadal obsługiwać zapytania, ale większa część każdej ścieżki wyszukiwania musi być wtedy odczytywana z dysku SSD. Losowy dostęp i chybienia pamięci podręcznej stają się częścią opóźnienia pobierania wyników.
PlanetScale opisuje indeksy większe niż pamięć RAM, które przechowują w pamięci mniejszą strukturę nawigacyjną, przenosząc większą część danych wektorów lub list odwrotności do pamięci masowej.
Może to być dobry kompromis na serwerze domowym, gdy wyszukiwania są sporadyczne, a indeks znajduje się na szybkim dysku SSD. To złe założenie, gdy kilka kolekcji otrzymuje współbieżne zapytania lub współdzieli powolny dysk z bazami danych aplikacji i obciążeniami związanymi z multimediami.
Duplikaty danych i oddzielne usługi dodają ukryte kopie
Ten sam embedding może znajdować się w magazynie dokumentów, indeksie wektorowym, pamięci podręcznej aplikacji oraz kolekcji kopii zapasowej lub tymczasowej. Oddzielne kontenery mogą również ładować identyczne modele embeddingów lub rerankingu do różnych przestrzeni adresowych procesów.
Omówienie unikania zduplikowanego przechowywania wektorów przez Memgraph pokazuje, dlaczego architektura indeksu zmienia liczbę kopii jednego przeszukiwalnego rekordu przechowywanych w pamięci.
Liczba kolekcji to zatem tylko jedna część budżetu. Zanim uznasz, że odpowiada za to wyłącznie baza danych wektorowych, zinwentaryzuj zduplikowane wektory, stare wersje indeksów, tymczasowe kolekcje używane podczas przebudowy, procesy modeli i buforowane wyniki.
Konsoliduj kolekcje zgodnie z zasadami dostępu i obciążeniem
Używaj oddzielnych kolekcji, gdy wymagają różnych uprawnień, wymiarów embeddingów, zasad przechowywania danych, harmonogramów aktualizacji lub granic awarii. Same etykiety tematyczne nie zawsze wymagają oddzielnego indeksu fizycznego.
Współdzielona kolekcja z metadanymi dzierżawcy, właściciela, źródła lub kategorii może ponownie wykorzystywać jeden indeks, podczas gdy filtry ograniczą wyszukiwanie do zamierzonego zakresu. Przed konsolidacją przetestuj trafność filtrowanego wyszukiwania, ponieważ zbyt duża mieszana kolekcja może powodować własne koszty związane z rankingiem i utrzymaniem.
Wyjaśnienie ZimaSpace dotyczące tego, dlaczego lokalne środowisko uruchomieniowe AI rezerwuje pamięć, pomaga właściwie interpretować monitoring: zachowane strony i pamięci podręczne mogą być ponownie używanym stanem roboczym, a nie wyciekiem, ale nadal konkurują z resztą serwera.
Ustal budżet pamięci RAM przed dodaniem kolejnej kolekcji
Zapisuj liczbę wektorów, wymiary, precyzję, typ indeksu, ustawienia grafu, rozmiar indeksu metadanych, pamięć rezydentną po rozgrzaniu oraz szczytowe zużycie pamięci podczas pozyskiwania danych i współbieżnych zapytań. Mierz cały stos, a nie tylko pulpit nawigacyjny bazy danych.
Zostaw zapas dla systemu operacyjnego, pamięci podręcznej stron, kontenerów, baz danych, udostępniania plików i lokalnego modelu językowego. Jeśli aktywność wymiany lub liczba poważnych błędów stron rośnie podczas odpytywania drugiej kolekcji, zestawy robocze nie mieszczą się już razem z odpowiednim zapasem.
Zmniejsz liczbę wymiarów lub precyzję, jeśli pozwalają na to testy trafności, ogranicz spójność grafu, przenieś rzadko używane wektory do pamięci mapowanej, ogranicz współbieżność zapytań, wyładuj nieużywane modele i usuń zastąpione kolekcje, zanim kupisz więcej pamięci RAM.
Najczęściej zadawane pytania
Czy jedna duża kolekcja RAG zawsze zużywa mniej pamięci?
Często pozwala uniknąć zduplikowanego narzutu indeksu, ale może wymagać bardziej złożonego filtrowania i obniżyć jakość wyszukiwania, gdy niezwiązane treści współdzielą jedną przestrzeń rankingową. Konsoliduj kolekcje dopiero po przetestowaniu granic dostępu i trafności.
Czy mapowanie pamięci eliminuje konkurencję o pamięć RAM?
Nie. Ogranicza trwale rezydentne alokacje, ale aktywne strony indeksu nadal zajmują pamięć podręczną stron systemu operacyjnego i mogą wypierać strony używane przez inne kolekcje i aplikacje.
Dlaczego zużycie RAM pozostaje wysokie po zakończeniu zapytania RAG?
Baza danych, alokator, system operacyjny lub środowisko uruchomieniowe modelu mogą zachowywać strony i bufory do ponownego użycia. Sprawdź, czy pamięć jest wykorzystywana ponownie przy kolejnych zapytaniach oraz czy pojawia się aktywność wymiany lub presja związana z brakiem pamięci, zanim uznasz to za wyciek.
Polecane produkty
Centrum Technologii i Sztucznej Inteligencji
Więcej do przeczytania
Dlaczego przewidywania dotyczące inteligentnego domu stają się mniej trafne po sezonowych zmianach rutyny?
Sezonowe rutyny zmieniają zależność między czasem, czujnikami, obecnością domowników a pożądanymi działaniami, przez co model wytrenowany na podstawie wcześniejszych nawyków staje się nieaktualny.
Dlaczego domowy rejestrator NVR pomija krótkie zdarzenia, gdy włączone jest śledzenie obiektów?
Śledzenie wymaga wystarczającej liczby detekcji, aby rozpocząć i potwierdzić trajektorię, dlatego obiekt obecny przez krótki czas może zniknąć, zanim rejestrator NVR utworzy prawidłowe zdarzenie.
Dlaczego etykiety zdjęć generowane przez AI zmieniają się po aktualizacji modelu?
Aktualizacja modelu zmienia sposób reprezentacji i ustalania rankingu używanych do przypisywania etykiet, dlatego to samo zdjęcie może przekroczyć inne granice semantyczne lub poziomy pewności.
