Rozmiar i limity indeksu wektorowego

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.

Wewnętrznie fizyczne struktury danych indeksu wyszukiwania obejmują:

• Zawartość nieprzetworzona (używana do pobierania wzorców wymagających zawartości niekenizowanej)
• Odwrócone indeksy (używane do wyszukiwania pól tekstowych)
• Indeksy wektorowe (używane 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.

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

• Rozmiar indeksu wektorowego jest mierzony w bajtach.

• Łączna pamięć usługi zawiera wszystkie pliki indeksu wektorowego. Usługa Azure AI Search obsługuje różne kopie plików indeksów wektorowych w różnych celach. Oferujemy inne opcje zmniejszenia nakładu pracy związanego z magazynem indeksów wektorów , eliminując niektóre z tych kopii.

• Przydziały wektorów są wymuszane w usłudze wyszukiwania jako całość, na każdą partycję. W przypadku dodawania partycji zwiększa się również przydział wektorów. Przydziały wektorów partycji są wyższe w przypadku nowszych usług. Aby uzyskać więcej informacji, zobacz Vector index size limits (Limity rozmiaru indeksu wektorowego).

• Nie wszystkie algorytmy używają limitu przydziału rozmiaru indeksu wektorowego. Przydziały wektorów są ustanawiane na podstawie wymagań dotyczących pamięci wyszukiwania przybliżonego najbliższego sąsiada (ANN). Pola wektorowe utworzone za pomocą algorytmu Hierarchical Navigable Small World (HNSW) muszą znajdować się w pamięci podczas wykonywania zapytania ze względu na charakter losowego dostępu procedur przechodzenia opartych na grafach. Pola wektorowe używające pełnego algorytmu K-Nearest Neighbors (KNN) są ładowane do pamięci dynamicznie, strona po stronie, podczas wykonywania zapytania, w związku z czym nie zużywają przydziału wektora.

Sprawdzanie rozmiaru partycji i ilości

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

• W portalu Azure na stronie Przegląd usługi wyszukiwania, karty Właściwości i Użycie wyświetlają rozmiar partycji i magazyn, a także przydział wektorów i rozmiar indeksu wektora.

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

Limit wektorów różni się w zależności od daty utworzenia usługi.

Sprawdzanie rozmiaru 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.

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

{
    "@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
    }
}

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

{
    "@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ą przestrzeni przechowywania, przedstawionej w następujących obliczeniach jako "surowy rozmiar" danych. Aby oszacować wymagania dotyczące rozmiaru indeksu pól wektorowych, użyj tego rozmiaru surowego.

Wymiarowość jednego wektora określa rozmiar pamię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)

Obciążenie pamięcią z wybranego algorytmu

Każdy algorytm ANN generuje dodatkowe struktury danych w pamięci, aby umożliwić wydajne wyszukiwanie. 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% dla nieskompresowanych wektorów float32 (Edm.Single).

Wraz ze wzrostem wymiarowości procent obciążenia pamięci spada. Dzieje się tak, ponieważ pierwotny rozmiar wektorów zwiększa się, podczas gdy inne struktury danych, które przechowują informacje o łączności grafu, pozostają stałym rozmiarem dla danego melementu . W rezultacie względny wpływ tych dodatkowych struktur danych zmniejsza się w stosunku do ogólnego rozmiaru wektora.

Obciążenie pamięci zwiększa się o większe wartości parametru mHNSW , który określa liczbę łączy dwukierunkowych utworzonych dla każdego nowego wektora podczas budowy indeksu. Dzieje się tak, ponieważ każde łącze współtworzy około 8 do 10 bajtów na dokument, a całkowite obciążenie jest proporcjonalnie skalowane do m.

Poniższa tabela zawiera podsumowanie wartości procentowych narzutów obserwowanych w testach wewnętrznych dla nieskompresowanych pól wektorowych:

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

W przypadku pól wektorowych używających technik kompresji, takich jak kwantyzacja skalarna lub binarna, wydaje się, że procent narzutu zajmuje większy procent całkowitego rozmiaru indeksu wektorowego. Wraz ze spadkiem rozmiaru danych względny wpływ struktur danych o stałym rozmiarze używanych do przechowywania informacji o łączności grafu staje się bardziej znaczący.

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 1536 wymiarami. Oznacza to, że jeden dokument będzie używał 1536 Edm.Single (typu zmiennoprzecinkowego), czyli 6144 bajty, ponieważ każdy Edm.Single ma 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 1,000 dokumentów z dwoma 1536-wymiarowymi polami wektorów zużywa 1,000 dokumentów x 2 pola x 1536 liczb zmiennoprzecinkowych na dokument x 4 bajty na liczbę zmiennoprzecinkową = 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% i procent usuniętych dokumentów 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. Aby uzyskać informacje na temat obciążenia magazynu indeksów wektorów, zobacz Eliminowanie opcjonalnych wystąpień wektorów z magazynu.

Treści powiązane

• Wyszukiwanie wektorowe w usłudze Azure AI Search
• Wybieranie podejścia do optymalizacji magazynu i przetwarzania wektorów