Rozmiar indeksu wektorowego i pozostawanie w granicach

Dla każdego pola wektorowego usługa Azure AI Search konstruuje indeks wektorów wewnętrznych przy użyciu parametrów algorytmu określonych w polu. Ponieważ usługa Azure AI Search nakłada limity przydziału na rozmiar indeksu wektorowego, musisz wiedzieć, jak oszacować i monitorować rozmiar wektora, aby upewnić się, że nie przekraczasz limitów.

Uwaga

Uwaga dotycząca terminologii. Wewnętrznie fizyczne struktury danych indeksu wyszukiwania obejmują nieprzetworzone treści (używane do pobierania wzorców wymagających nie tokenizowanej zawartości), odwróconych indeksów (używanych do wyszukiwania pól tekstowych) i indeksów wektorów (używanych do wyszukiwania pól wektorów). W tym artykule wyjaśniono limity indeksów wektorów wewnętrznych, które są z powrotem dla każdego pola wektora.

Napiwek

Kwantyzacja wektorów i konfiguracja magazynu jest teraz dostępna w wersji zapoznawczej. Korzystaj z funkcji, takich jak wąskie typy danych, kwantyzacja skalarna i eliminacja nadmiarowego magazynu, aby pozostać w ramach limitu przydziału wektorów i przydziału magazynu.

Kluczowe punkty dotyczące rozmiaru limitu przydziału i indeksu wektorowego

• Rozmiar indeksu wektorowego jest mierzony w bajtach.

• Przydziały wektorów są oparte na ograniczeniach pamięci. Wszystkie indeksy wektorów z możliwością wyszukiwania muszą zostać załadowane do pamięci. Jednocześnie musi istnieć wystarczająca ilość pamięci dla innych operacji środowiska uruchomieniowego. Limity przydziału wektorów istnieją, aby zapewnić, że ogólny system pozostanie stabilny i zrównoważony dla wszystkich obciążeń.

• Indeksy wektorowe podlegają również limitowi przydziału dysku, w tym sensie, że wszystkie indeksy, wektor i niewektory, podlegają przydziałowi dysku. Brak oddzielnego limitu przydziału dysku dla indeksów wektorów.

• Przydziały wektorów są wymuszane w usłudze wyszukiwania jako całość na partycję, co oznacza, że w przypadku dodawania partycji limit przydziału wektorów wzrasta. Przydziały wektorów partycji są wyższe w przypadku nowszych usług:

  • Limit przydziału wektorów dla usług utworzonych po 3 kwietnia 2024 r.
  • Limit przydziału wektorów dla usług utworzonych między 1 lipca 2023 r. a 3 kwietnia 2024 r.
  • Limit przydziału wektorów dla usług utworzonych przed 1 lipca 2023 r.

Jak sprawdzić rozmiar partycji i ilość

Jeśli nie masz pewności, jakie są limity usługi wyszukiwania, oto dwa sposoby uzyskiwania tych informacji:

• W witrynie Azure Portal na stronie Przegląd usługi wyszukiwania na karcie Właściwości i karcie Użycie są wyświetlane rozmiar partycji i magazyn, a także wektorowy przydział i rozmiar indeksu wektorowego.

• W witrynie Azure Portal na stronie Skalowanie możesz przejrzeć liczbę i rozmiar partycji.

Jak sprawdzić datę utworzenia usługi

Nowsze usługi utworzone po 3 kwietnia 2024 r. oferują pięć do dziesięciu razy więcej miejsca do magazynowania wektorowego co starsze usługi w tej samej warstwie. Jeśli twoja usługa jest starsza, rozważ utworzenie nowej usługi i migrację zawartości.

1. W witrynie Azure Portal otwórz grupę zasobów zawierającą usługę wyszukiwania.

2. W okienku po lewej stronie w obszarze Ustawienia wybierz pozycję Wdrożenia.

3. Znajdź wdrożenie usługi wyszukiwania. Jeśli istnieje wiele wdrożeń, użyj filtru, aby wyszukać frazę "wyszukaj".

4. Wybierz wdrożenie. Jeśli masz więcej niż jeden, kliknij, aby sprawdzić, czy jest rozpoznawana w usłudze wyszukiwania.

   

5. Rozwiń szczegóły wdrożenia. Powinna zostać wyświetlona wartość Utworzono i data utworzenia.

   

6. Teraz, gdy znasz wiek usługi wyszukiwania, przejrzyj limity przydziałów wektorów na podstawie tworzenia usługi:

   • Po 3 kwietnia 2024 r.
   • Od 1 lipca 2023 r. do 3 kwietnia 2024 r.
   • Przed 1 lipca 2023 r.

Jak uzyskać rozmiar indeksu wektorowego

Żądanie metryk wektorów to operacja płaszczyzny danych. Możesz użyć witryny Azure Portal, interfejsów API REST lub zestawów SDK platformy Azure, aby uzyskać użycie wektorów na poziomie usługi za pośrednictwem statystyk usługi i poszczególnych indeksów.

Portal

Informacje o użyciu można znaleźć na karcie Użycie strony Przegląd. Strony portalu są odświeżane co kilka minut, więc jeśli ostatnio zaktualizowano indeks, poczekaj trochę przed sprawdzeniem wyników.

Poniższy zrzut ekranu dotyczy starszej usługi wyszukiwania w warstwie Standardowa 1 (S1), skonfigurowanej dla jednej partycji i jednej repliki.

• Limit przydziału magazynu jest ograniczeniem dysku i obejmuje wszystkie indeksy (wektor i niewektor) w usłudze wyszukiwania.
• Limit przydziału rozmiaru indeksu wektorowego jest ograniczeniem pamięci. Jest to ilość pamięci wymaganej do załadowania wszystkich indeksów wektorów wewnętrznych utworzonych dla każdego pola wektora w usłudze wyszukiwania.

Zrzut ekranu wskazuje, że indeksy (wektor i niewektor) zużywają prawie 460 megabajtów dostępnego magazynu dyskowego. Indeksy wektorowe zużywają prawie 93 megabajty pamięci na poziomie usługi.

Limity przydziału zarówno rozmiaru magazynu, jak i indeksu wektorowego zwiększają się lub zmniejszają podczas dodawania lub usuwania partycji. Jeśli zmienisz liczbę partycji, na kafelku zostanie wyświetlona odpowiednia zmiana przydziału magazynu i wektora.

Uwaga

Na dysku indeksy wektorów nie są 93 megabajty. Indeksy wektorów na dysku zajmują około trzy razy więcej miejsca niż indeksy wektorów w pamięci. Aby uzyskać szczegółowe informacje, zobacz Jak pola wektorów wpływają na magazyn dysków.

REST

Użyj następujących interfejsów API REST płaszczyzny danych (wersja 2023-10-01-preview, 2023-11-01 i nowsze) dla statystyk użycia wektorów:

• Funkcja GET Service Statistics zwraca limit przydziału i użycie dla całej usługi wyszukiwania.
• Funkcja GET Index Statistics zwraca użycie dla danego indeksu.

Użycie i limit przydziału są raportowane w bajtach.

Oto statystyki usługi GET:

GET {{baseUrl}}/servicestats?api-version=2023-11-01  HTTP/1.1
    Content-Type: application/json
    api-key: {{apiKey}}

Odpowiedź zawiera metryki dla elementu storageSize, które nie rozróżnia indeksów wektorów i niewektorów. Statystyka vectorIndexSize przedstawia użycie i limit przydziału na poziomie usługi.

{
    "@odata.context": "https://my-demo.search.windows.net/$metadata#Microsoft.Azure.Search.V2023_11_01.ServiceStatistics",
    "counters": {
        "documentCount": {
            "usage": 15377,
            "quota": null
        },
        "indexesCount": {
            "usage": 13,
            "quota": 15
        },
        . . .
        "storageSize": {
            "usage": 39862913,
            "quota": 2147483648
        },
        . . .
        "vectorIndexSize": {
            "usage": 2685436,
            "quota": 1073741824
        }
    },
    "limits": {
        "maxFieldsPerIndex": 1000,
        "maxFieldNestingDepthPerIndex": 10,
        "maxComplexCollectionFieldsPerIndex": 40,
        "maxComplexObjectsInCollectionsPerDocument": 3000
    }
}

Możesz również wysłać statystykę indeksu GET, aby uzyskać fizyczny rozmiar indeksu na dysku oraz rozmiar w pamięci pól wektorów.

GET {{baseUrl}}/indexes/vector-healthplan-idx/stats?api-version=2023-11-01  HTTP/1.1
    Content-Type: application/json
    api-key: {{apiKey}}

Odpowiedź zawiera informacje o użyciu na poziomie indeksu. Ten przykład jest oparty na indeksie utworzonym w zintegrowanym przewodniku Szybki start wektoryzacji, który fragmentuje i wektoryzuje pliki PDF planu kondycji. Każdy fragment współtworzy documentCountplik .

{
    "@odata.context": "https://my-demo.search.windows.net/$metadata#Microsoft.Azure.Search.V2023_11_01.IndexStatistics",
    "documentCount": 147,
    "storageSize": 4592870,
    "vectorIndexSize": 915484
}

Czynniki wpływające na rozmiar indeksu wektorowego

Istnieją trzy główne składniki wpływające na rozmiar indeksu wektora wewnętrznego:

• Nieprzetworzone rozmiary danych
• Obciążenie z wybranego algorytmu
• Obciążenie związane z usuwaniem lub aktualizowaniem dokumentów w indeksie

Nieprzetworzone rozmiary danych

Każdy wektor jest zwykle tablicą liczb zmiennoprzecinkowych o pojedynczej precyzji w polu typu Collection(Edm.Single).

Struktury danych wektorowych wymagają magazynu reprezentowanego w następujących obliczeniach jako "nieprzetworzonego rozmiaru" danych. Użyj tego nieprzetworzonego rozmiaru , aby oszacować wymagania dotyczące rozmiaru indeksu wektorowego pól wektorów.

Rozmiar magazynu jednego wektora zależy od jego wymiarowości. Mnożenie rozmiaru jednego wektora przez liczbę dokumentów zawierających to pole wektora w celu uzyskania rozmiaru pierwotnego:

raw size = (number of documents) * (dimensions of vector field) * (size of data type)

Typ danych EDM	Rozmiar typu danych
Collection(Edm.Single)	4 bajty
Collection(Edm.Half)	2 bajty
Collection(Edm.Int16)	2 bajty
Collection(Edm.SByte)	1 bajt

Obciążenie pamięcią z wybranego algorytmu

Każdy przybliżony algorytm najbliższego sąsiada (ANN) generuje dodatkowe struktury danych w pamięci w celu umożliwienia wydajnego wyszukiwania. Te struktury zużywają dodatkowe miejsce w pamięci.

W przypadku algorytmu HNSW obciążenie pamięci mieści się w zakresie od 1% do 20%.

Obciążenie pamięci jest mniejsze w przypadku wyższych wymiarów, ponieważ zwiększa się rozmiar pierwotny wektorów, podczas gdy dodatkowe struktury danych pozostają stałym rozmiarem, ponieważ przechowują informacje o łączności w grafie. W związku z tym wkład dodatkowych struktur danych stanowi mniejszą część ogólnego rozmiaru.

Obciążenie pamięci jest wyższe w przypadku większych wartości parametru mHNSW, który określa liczbę łączy dwukierunkowych utworzonych dla każdego nowego wektora podczas budowy indeksu. Jest to spowodowane tym, że m współtworzy około 8 bajtów do 10 bajtów na dokument pomnożony przez m.

W poniższej tabeli przedstawiono podsumowanie wartości procentowych narzutów obserwowanych w testach wewnętrznych:

Wymiary	Parametr HNSW (m)	Procent narzut
96	100	20%
200	100	8%
768	100	2%
1536	100	1%

Te wyniki pokazują relację między wymiarami, parametrem mHNSW i obciążeniem pamięci dla algorytmu HNSW.

Obciążenie związane z usuwaniem lub aktualizowaniem dokumentów w indeksie

Gdy dokument z polem wektorowym zostanie usunięty lub zaktualizowany (aktualizacje są wewnętrznie reprezentowane jako operacja usuwania i wstawiania), dokument źródłowy jest oznaczony jako usunięty i pomijany podczas kolejnych zapytań. Gdy nowe dokumenty są indeksowane i rośnie indeks wektorów wewnętrznych, system czyści te usunięte dokumenty i odzyskuje zasoby. Oznacza to, że prawdopodobnie zauważysz opóźnienie między usuwaniem dokumentów a zwalnianiem bazowych zasobów.

Nazywamy to współczynnikiem usuniętych dokumentów. Ponieważ współczynnik usuniętych dokumentów zależy od właściwości indeksowania usługi, nie ma uniwersalnej heurystyki do oszacowania tego parametru i nie ma interfejsu API ani skryptu, który zwraca stosunek w mocy dla usługi. Zauważamy, że połowa naszych klientów ma współczynnik usuniętych dokumentów mniejszy niż 10%. Jeśli zwykle wykonujesz usunięcia lub aktualizacje o wysokiej częstotliwości, może być obserwowany wyższy współczynnik usuniętych dokumentów.

Jest to kolejny czynnik wpływający na rozmiar indeksu wektorowego. Niestety, nie mamy mechanizmu uwidoślenia bieżącego współczynnika usuniętych dokumentów.

Szacowanie całkowitego rozmiaru danych w pamięci

Biorąc pod uwagę wcześniej opisane czynniki, aby oszacować całkowity rozmiar indeksu wektorowego, użyj następującego obliczenia:

(raw_size) * (1 + algorithm_overhead (in percent)) * (1 + deleted_docs_ratio (in percent))

Na przykład aby obliczyć raw_size, załóżmy, że używasz popularnego modelu Azure OpenAI z text-embedding-ada-002 wymiarami 1536. Oznacza to, że jeden dokument będzie używać 1536 Edm.Single (zmiennoprzecinkowych) lub 6144 bajtów, ponieważ każdy z nich Edm.Single wynosi 4 bajty. 1000 dokumentów z pojedynczym, 1536-wymiarowym polem wektorowym zużywa łącznie 1000 dokumentów x 1536 floats/doc = 1,536 000 zmiennoprzecinków lub 6144 000 bajtów.

Jeśli masz wiele pól wektorowych, musisz wykonać to obliczenie dla każdego pola wektora w indeksie i dodać je razem. Na przykład 1000 dokumentów z dwoma polami wektorów 1536-wymiarowych zużywa 1000 dokumentów x 2 pól x 1536 zmiennoprzecinkowych/dokumentów x 4 bajty/zmiennoprzecinkowe = 12 288 000 bajtów.

Aby uzyskać rozmiar indeksu wektorowego, należy pomnożyć tę raw_size przez obciążenie algorytmu i usunięty współczynnik dokumentów. Jeśli obciążenie algorytmu dla wybranych parametrów HNSW wynosi 10%, a usunięty stosunek dokumentu wynosi 10%, otrzymujemy: 6.144 MB * (1 + 0.10) * (1 + 0.10) = 7.434 MB.

Wpływ pól wektorów na magazyn dyskowy

Większość tego artykułu zawiera informacje o rozmiarze wektorów w pamięci. Jeśli chcesz wiedzieć o rozmiarze wektora na dysku, użycie dysku dla danych wektorowych wynosi mniej więcej trzy razy więcej niż rozmiar indeksu wektorowego w pamięci. Jeśli na przykład vectorIndexSize użycie wynosi 100 megabajtów (10 milionów bajtów), użyto co najmniej 300 megabajtów limitu przydziału storageSize w celu uwzględnienia indeksów wektorów