Velikost vektorových indexů a zachování v mezích limitů
Pro každé vektorové pole Azure AI Search vytvoří interní vektorový index pomocí parametrů algoritmu zadaných v poli. Vzhledem k tomu, že Azure AI Search ukládá kvóty na velikost vektorového indexu, měli byste vědět, jak odhadnout a monitorovat velikost vektoru, abyste měli jistotu, že zůstanete pod limity.
Poznámka:
Poznámka o terminologii. Fyzická datová struktura indexu vyhledávání interně zahrnují nezpracovaný obsah (používaný pro načítání vzorů vyžadujících ne tokenizovaný obsah), invertované indexy (používané pro prohledávatelná textová pole) a vektorové indexy (používané pro prohledávatelná vektorová pole). Tento článek vysvětluje limity pro interní vektorové indexy, které se vrátí ke každému z vašich vektorových polí.
Tip
Obecná dostupnost vektorové kvantizace a konfigurace úložiště. Používejte funkce, jako jsou úzké datové typy, skalární kvantování a eliminace redundantního úložiště, abyste zůstali pod kvótou vektorů a kvótou úložiště.
Klíčové body týkající se velikosti kvót a vektorových indexů
Velikost vektorových indexů se měří v bajtech.
Kvóty vektorů jsou založené na omezeních paměti. Všechny prohledávatelné vektorové indexy musí být načteny do paměti. Zároveň musí být dostatek paměti i pro ostatní operace za běhu. Existují kvóty vektorů, aby se zajistilo, že celkový systém zůstává stabilní a vyvážený pro všechny úlohy.
Vektorové indexy se také vztahují na kvótu disku v tom smyslu, že všechny indexy podléhají kvótě disku. Pro indexy vektorů neexistuje žádná samostatná kvóta disku.
Kvóty vektorů se u vyhledávací služby vynucují jako celek na oddíl, což znamená, že pokud přidáte oddíly, kvóta vektorů se zprovozní. Kvóty vektorů pro jednotlivé oddíly jsou u novějších služeb vyšší. Další informace naleznete v tématu Omezení velikosti vektorových indexů.
Postup kontroly velikosti a množství oddílů
Pokud si nejste jistí, jaké jsou limity vyhledávací služby, můžete získat informace dvěma způsoby:
Na webu Azure Portal na stránce Přehled vyhledávací služby se na kartě Vlastnosti i na kartě Využití zobrazují velikost oddílu a úložiště a také velikost vektorové kvóty a vektorového indexu.
Na webu Azure Portal můžete na stránce Škálování zkontrolovat počet a velikost oddílů.
Postup kontroly data vytvoření služby
Novější služby vytvořené po 3. dubnu 2024 nabízejí pět až desetkrát více vektorového úložiště jako starší služby se stejnou fakturační sazbou. Pokud je vaše služba starší, zvažte vytvoření nové služby a migraci obsahu.
Na webu Azure Portal otevřete skupinu prostředků, která obsahuje vaši vyhledávací službu.
V levém podokně v části Nastavení vyberte Nasazení.
Vyhledejte nasazení vyhledávací služby. Pokud existuje mnoho nasazení, pomocí filtru vyhledejte "search".
Vyberte nasazení. Pokud máte více než jednu, kliknutím se podívejte, jestli se přeloží do vyhledávací služby.
Rozbalte podrobnosti o nasazení. Mělo by se zobrazit datum vytvoření a datum vytvoření.
Teď, když znáte věk vyhledávací služby, zkontrolujte limity kvót vektorů na základě vytvoření služby: Limity velikosti vektorového indexu.
Jak získat velikost vektorových indexů
Požadavek na vektorové metriky je operace roviny dat. Pomocí webu Azure Portal, rozhraní REST API nebo sad Azure SDK můžete získat vektorové využití na úrovni služby prostřednictvím statistik služby a pro jednotlivé indexy.
Informace o využití najdete na kartě Využití na stránce Přehled. Stránky portálu se aktualizují každých několik minut, takže pokud jste index nedávno aktualizovali, chvíli počkejte, než zkontrolujete výsledky.
Následující snímek obrazovky je pro starší vyhledávací službu Standard 1 (S1) nakonfigurovanou pro jeden oddíl a jednu repliku.
- Kvóta úložiště je omezení disku a zahrnuje všechny indexy (vektor a nevector) ve vyhledávací službě.
- Kvóta velikosti vektorového indexu je omezení paměti. Je to množství paměti potřebné k načtení všech interních vektorových indexů vytvořených pro každé vektorové pole ve vyhledávací službě.
Snímek obrazovky ukazuje, že indexy (vektor a nevector) spotřebovávají téměř 460 megabajtů dostupného diskového úložiště. Vektorové indexy spotřebovávají na úrovni služby téměř 93 megabajtů paměti.
Kvóty velikosti indexu úložiště i vektoru se při přidávání nebo odebírání oddílů zvětšují nebo snižují. Pokud změníte počet oddílů, zobrazí se na dlaždici odpovídající změna v kvótě úložiště a vektoru.
Poznámka:
Na disku nejsou vektorové indexy 93 megabajtů. Vektorové indexy na disku zabírají přibližně třikrát více místa než vektorové indexy v paměti. Podrobnosti najdete v tématu Vliv vektorových polí na diskové úložiště .
Faktory ovlivňující velikost vektorových indexů
Existují tři hlavní komponenty, které ovlivňují velikost interního vektorového indexu:
- Nezpracovaná velikost dat
- Režie z vybraného algoritmu
- Režie při odstraňování nebo aktualizaci dokumentů v rámci indexu
Nezpracovaná velikost dat
Každý vektor je obvykle matice čísel s plovoucí desetinnou čárkou s jednoduchou přesností v poli typu Collection(Edm.Single).
Vektorové datové struktury vyžadují úložiště reprezentované v následujícím výpočtu jako "nezpracovaná velikost" vašich dat. Pomocí této nezpracované velikosti můžete odhadnout požadavky na velikost vektorového indexu vektorových polí.
Velikost úložiště jednoho vektoru je určena jeho rozměrovou velikostí. Vynásobte velikost jednoho vektoru počtem dokumentů obsahujících toto vektorové pole, abyste získali nezpracovanou velikost:
raw size = (number of documents) * (dimensions of vector field) * (size of data type)
| Datový typ EDM | Velikost datového typu |
|---|---|
Collection(Edm.Single) |
4 bajty |
Collection(Edm.Half) |
2 bajty |
Collection(Edm.Int16) |
2 bajty |
Collection(Edm.SByte) |
1 bajt |
Režie paměti z vybraného algoritmu
Každý přibližný algoritmus nejbližšího souseda (ANN) generuje další datové struktury v paměti, aby bylo možné efektivně vyhledávat. Tyto struktury spotřebovávají více místa v paměti.
V případě algoritmu HNSW se režijní náklady na paměť pohybuje mezi 1 % a 20 %.
Režie paměti je nižší pro vyšší rozměry, protože nezpracovaná velikost vektorů se zvyšuje, zatímco nadbytečné datové struktury zůstávají pevnou velikostí, protože ukládají informace o připojení v grafu. V důsledku toho příspěvek dodatečných datových struktur představuje menší část celkové velikosti.
Režie paměti je vyšší pro větší hodnoty parametru mHNSW , který určuje počet obousměrných propojení vytvořených pro každý nový vektor během sestavování indexu. Je to proto, že m přispívá přibližně 8 bajtů na 10 bajtů na dokument vynásobený m.
Následující tabulka shrnuje procentuální náklady zjištěné v interních testech:
| Dimenze | Parametr HNSW (m) | Procento režie |
|---|---|---|
| 96 | 4 | 20 % |
| 200 | 4 | 8 % |
| 768 | 4 | 2 % |
| 1536 | 4 | 1 % |
| 3072 | 4 | 0,5 % |
Tyto výsledky ukazují vztah mezi dimenzemi, parametrem mHNSW a režií paměti pro algoritmus HNSW.
Režie při odstraňování nebo aktualizaci dokumentů v rámci indexu
Pokud je dokument s vektorovým polem odstraněn nebo aktualizován (aktualizace jsou interně reprezentovány jako operace odstranění a vložení), podkladový dokument se označí jako odstraněný a přeskočí během dalších dotazů. S indexovanými novými dokumenty a roste interní vektorový index, systém tyto odstraněné dokumenty vyčistí a uvolní prostředky. To znamená, že pravděpodobně uvidíte prodlevu mezi odstraněním dokumentů a uvolněním podkladových prostředků.
Označujeme to jako poměr odstraněných dokumentů. Vzhledem k tomu, že poměr odstraněných dokumentů závisí na charakteristikách indexování vaší služby, neexistuje žádný univerzální heuristický odhad tohoto parametru a neexistuje žádné rozhraní API ani skript, které vrací poměr, který se pro vaši službu projeví. Vidíme, že polovina našich zákazníků má odstraněný poměr dokumentů menší než 10 %. Pokud máte tendenci provádět odstranění nebo aktualizace s vysokou frekvencí, můžete pozorovat vyšší poměr odstraněných dokumentů.
To je další faktor ovlivňující velikost vektorového indexu. Bohužel nemáme mechanismus pro zobrazení aktuálního poměru odstraněných dokumentů.
Odhad celkové velikosti dat v paměti
Při zohlednění výše popsaných faktorů použijte k odhadu celkové velikosti vektorového indexu následující výpočet:
(raw_size) * (1 + algorithm_overhead (in percent)) * (1 + deleted_docs_ratio (in percent))
Pokud chcete například vypočítat raw_size, předpokládejme, že používáte oblíbený model Azure OpenAI s text-embedding-ada-002 1 536 dimenzemi. To znamená, že jeden dokument by spotřeboval 1 536 Edm.Single (float) nebo 6 144 bajtů, protože každý Edm.Single z nich je 4 bajty. 1 000 dokumentů s jedním, 1 536rozměrným vektorovým polem by spotřebovalo celkem 1000 dokumentů x 1536 float/doc = 1 536 000 float nebo 6 144 000 bajtů.
Pokud máte více vektorových polí, musíte tento výpočet provést pro každé vektorové pole v indexu a přidat je všechny dohromady. Například 1 000 dokumentů se dvěma 1 536rozměrnými vektorovými poli, spotřebovávají 1000 bajtů x 2 pole x 1536 floats/doc x 4 bajty/float = 12 288 000 bajtů.
Pokud chcete získat velikost vektorového indexu, vynásobte tuto raw_size režií algoritmu a odstraněným poměrem dokumentů. Pokud je režie vašeho algoritmu pro zvolené parametry HNSW 10 % a poměr odstraněných dokumentů je 10 %, získáme: 6.144 MB * (1 + 0.10) * (1 + 0.10) = 7.434 MB.
Vliv vektorových polí na diskové úložiště
Většina tohoto článku obsahuje informace o velikosti vektorů v paměti. Pokud chcete vědět o velikosti vektoru na disku, spotřeba disku pro vektorová data je přibližně třikrát větší než velikost vektorového indexu v paměti. Pokud je například vaše vectorIndexSize využití 100 megabajtů (10 milionů bajtů), použili byste alespoň 300 megabajtů kvóty pro přizpůsobení indexů vektorů storageSize .