A vektorindex mérete és a korlátok alatt marad
Az Azure AI Search minden vektormezőhöz létrehoz egy belső vektorindexet a mezőben megadott algoritmusparaméterek használatával. Mivel az Azure AI Search kvótákat ír elő a vektorindexek méretére, ismernie kell a vektorméret becslését és monitorozását, hogy a korlátok alatt maradjon.
Feljegyzés
Megjegyzés a terminológiáról. Belsőleg a keresési index fizikai adatstruktúrái közé tartoznak a nyers tartalom (a nem jogkivonatos tartalmat igénylő lekérési mintákhoz), az invertált indexek (kereshető szövegmezőkhöz) és a vektorindexek (kereshető vektormezőkhöz). Ez a cikk az egyes vektormezők belső vektorindexeinek korlátait ismerteti.
Tipp.
A vektorkvantálás és a tárolókonfiguráció előzetes verzióban érhető el. Használjon olyan képességeket, mint a keskeny adattípusok, a skaláris kvantálás és a redundáns tárolás megszüntetése, hogy a vektorkvóta és a tárolási kvóta alatt maradjon.
A kvóta és a vektorindex méretének főbb pontjai
A vektorindex mérete bájtban van mérve.
A vektorkvóták memóriakorlátozásokon alapulnak. Minden kereshető vektorindexet be kell tölteni a memóriába. Ugyanakkor elegendő memóriának kell lennie más futtatókörnyezeti műveletekhez is. A vektorkvóták biztosítják, hogy a teljes rendszer stabil és kiegyensúlyozott maradjon az összes számítási feladat esetében.
A vektorindexek lemezkvótára is vonatkoznak, abban az értelemben, hogy minden index lemezkvótára vonatkozik. A vektorindexekhez nincs külön lemezkvóta.
A vektorkvóták a keresési szolgáltatás egészére vannak kényszerítve partíciónként, ami azt jelenti, hogy partíciók hozzáadása esetén a vektorkvóta felmegy. A partíciónkénti vektorkvóták magasabbak az újabb szolgáltatások esetében:
A partíció méretének és mennyiségének ellenőrzése
Ha nem biztos abban, hogy mik a keresési szolgáltatás korlátai, az alábbi két módon szerezheti be ezeket az információkat:
Az Azure Portal Keresési szolgáltatás Áttekintés lapján a Tulajdonságok lap és a Használat lap is megjeleníti a partíció méretét és a tárterületet, valamint a vektorkvóta és a vektorindex méretét.
Az Azure Portal Méretezés lapján áttekintheti a partíciók számát és méretét.
A szolgáltatás létrehozásának dátuma
A 2024. április 3. után létrehozott újabb szolgáltatások ötször-tízszer több vektoros tárterületet kínálnak, mint a régebbiek, azonos szintű számlázási díjszabás mellett. Ha a szolgáltatás régebbi, fontolja meg egy új szolgáltatás létrehozását és a tartalom migrálását.
Az Azure Portalon nyissa meg a keresési szolgáltatást tartalmazó erőforráscsoportot.
A bal szélső panelen, a Gépház alatt válassza a Központi telepítések lehetőséget.
Keresse meg a keresési szolgáltatás üzembe helyezését. Ha sok üzemelő példány van, a szűrővel keressen rá a "keresésre".
Válassza ki az üzembe helyezést. Ha több is van, kattintson ide, és ellenőrizze, hogy az feloldja-e a keresési szolgáltatást.
Bontsa ki az üzembe helyezés részleteit. Ekkor megjelenik a Létrehozás és a létrehozás dátuma.
Most, hogy megismerte a keresési szolgáltatás korát, tekintse át a vektorkvóta korlátait a szolgáltatás létrehozása alapján:
Vektorindex méretének lekérése
A vektormetrikák kérése adatsík-művelet. Az Azure Portal, a REST API-k vagy az Azure SDK-k használatával szolgáltatásstatisztikákon és egyéni indexeken keresztül kaphat vektorhasználatot a szolgáltatás szintjén.
A használati adatok az Áttekintés lap Használat lapján találhatók. A portállapok néhány percenként frissülnek, így ha nemrég frissített egy indexet, várjon egy kicsit az eredmények ellenőrzése előtt.
Az alábbi képernyőkép egy régebbi Standard 1 (S1) keresési szolgáltatáshoz készült, amely egy partícióhoz és egy replikához van konfigurálva.
- A tárkvóta lemezkvótát jelent, amely magában foglalja a keresési szolgáltatás összes indexét (vektort és nonvektort).
- A vektorindex-méretkvóta memóriakorlát. Ez a keresési szolgáltatás egyes vektormezőihez létrehozott összes belső vektorindex betöltéséhez szükséges memória mennyisége.
A képernyőkép azt jelzi, hogy az indexek (vektorok és nonvektorok) közel 460 megabájtnyi rendelkezésre álló lemeztárolót használnak fel. A vektorindexek szolgáltatásszinten közel 93 megabájt memóriát használnak fel.
A partíciók hozzáadásakor vagy eltávolításakor mind a tárterület, mind a vektorindex méretének kvótái növekednek vagy csökkennek. Ha módosítja a partíciók számát, a csempe a tárterület és a vektorkvóta megfelelő változását jeleníti meg.
Feljegyzés
Lemezen a vektorindexek nem 93 megabájt. A lemez vektorindexei körülbelül háromszor több helyet foglalnak el, mint a memória vektorindexei. A részletekért tekintse meg, hogyan befolyásolják a vektormezők a lemeztárolót .
A vektorindex méretét befolyásoló tényezők
A belső vektorindex méretét három fő összetevő befolyásolja:
- Az adatok nyers mérete
- A kijelölt algoritmus többletterhelése
- Az indexen belüli dokumentumok törlésével vagy frissítésével kapcsolatos többletterhelés
Az adatok nyers mérete
Minden vektor általában egy egy pontosságú lebegőpontos számokat tartalmazó tömb egy típusmezőben Collection(Edm.Single).
A vektoros adatstruktúrák tárolást igényelnek, amely az alábbi számításban az adatok "nyers méreteként" jelenik meg. Ezzel a nyers mérettel megbecsülheti a vektormezők vektorindex-méretére vonatkozó követelményeket.
Egy vektor tárolási méretét a méret határozza meg. Szorozza meg egy vektor méretét a vektormezőt tartalmazó dokumentumok számával a nyers méret eléréséhez:
raw size = (number of documents) * (dimensions of vector field) * (size of data type)
| EDM-adattípus | Az adattípus mérete |
|---|---|
Collection(Edm.Single) |
4 bájt |
Collection(Edm.Half) |
2 bájt |
Collection(Edm.Int16) |
2 bájt |
Collection(Edm.SByte) |
1 bájt |
A kijelölt algoritmus memóriaterhelése
Minden közelítő szomszéd (ANN) algoritmus extra adatstruktúrákat hoz létre a memóriában a hatékony keresés érdekében. Ezek a struktúrák extra helyet foglalnak el a memóriában.
A HNSW algoritmus esetében a memóriaterhelés 1% és 20% között mozog.
A memóriaterhelés alacsonyabb a magasabb dimenziók esetében, mivel a vektorok nyers mérete nő, míg a további adatstruktúrák rögzített méretűek maradnak, mivel a gráfon belül tárolják a kapcsolat adatait. Következésképpen a további adatstruktúrák hozzájárulása a teljes méret kisebb részét képezi.
A memóriaterhelés nagyobb a HNSW paraméter mnagyobb értékeinél, ami meghatározza, hogy hány kétirányú kapcsolat jön létre minden új vektorhoz az indexépítés során. Ennek az az oka m , hogy dokumentumonként körülbelül 8 bájttal és 10 bájttal mszorozva járul hozzá.
Az alábbi táblázat a belső tesztekben megfigyelt többletterhelési százalékokat foglalja össze:
| Dimenziók | HNSW paraméter (m) | Többletterhelés százalékos aránya |
|---|---|---|
| 96 | 4 | 20% |
| 200 | 4 | 8% |
| 768 | 4 | 2% |
| 1536 | 4 | 1% |
| 3072 | 4 | 0.5% |
Ezek az eredmények a dimenziók, a HNSW paraméter més a HNSW-algoritmus memóriaterhelése közötti kapcsolatot mutatják be.
Az indexen belüli dokumentumok törlésével vagy frissítésével kapcsolatos többletterhelés
Ha egy vektormezővel rendelkező dokumentumot törölnek vagy frissítenek (a frissítések belsőleg törlési és beszúrási műveletként jelennek meg), az alapul szolgáló dokumentumot töröltként jelöli meg, és a későbbi lekérdezések során kihagyja. Az új dokumentumok indexelése és a belső vektorindex növekedésével a rendszer megtisztítja ezeket a törölt dokumentumokat, és visszanyeri az erőforrásokat. Ez azt jelenti, hogy valószínűleg késés tapasztalható a dokumentumok törlése és a felszabadított mögöttes erőforrások között.
Ezt a törölt dokumentumok arányának tekintjük. Mivel a törölt dokumentumok aránya a szolgáltatás indexelési jellemzőitől függ, nincs univerzális heurisztikus paraméter ennek a paraméternek a becsléséhez, és nincs olyan API vagy szkript, amely visszaadja a szolgáltatásra érvényes arányt. Megfigyeltük, hogy ügyfeleink fele 10%-nál kisebb törölt dokumentumokkal rendelkezik. Ha általában nagy gyakoriságú törléseket vagy frissítéseket végez, akkor előfordulhat, hogy magasabb a törölt dokumentumok aránya.
Ez egy másik tényező, amely befolyásolja a vektorindex méretét. Sajnos nincs mechanizmusunk a törölt dokumentumok aktuális arányának felszínre hozására.
A memóriában lévő adatok teljes méretének becslése
A korábban ismertetett tényezők figyelembevételével a vektorindex teljes méretének becsléséhez használja a következő számítást:
(raw_size) * (1 + algorithm_overhead (in percent)) * (1 + deleted_docs_ratio (in percent))
A raw_size kiszámításához tegyük fel például, hogy egy népszerű Azure OpenAI-modellt text-embedding-ada-002 használ 1536 dimenzióval. Ez azt jelenti, hogy egy dokumentum 1536 Edm.Single (lebegőpontos) vagy 6144 bájtot használna fel, mivel mindegyik Edm.Single 4 bájt. 1000 dokumentum egyetlen, 1536 dimenziós vektormezővel összesen 1000 docs x 1536 floats/doc = 1 536 000 lebegőpontos vagy 6 144 000 bájtot használna fel.
Ha több vektormezővel rendelkezik, ezt a számítást az index minden egyes vektormezőjéhez el kell végeznie, és össze kell adnia őket. Például 1000 dokumentum két 1536 dimenziós vektormezővel, 1000 dokumentum x 2 mező x 1536 lebegőpontos/doc x 4 bájt/lebegőpontos = 12 288 000 bájt.
A vektorindex méretének megállapításához szorozza meg ezt a raw_size az algoritmus terhelésével és a törölt dokumentumaránysal. Ha a választott HNSW-paraméterek algoritmusterhelése 10%, a törölt dokumentum aránya pedig 10%, akkor a következőt kapjuk: 6.144 MB * (1 + 0.10) * (1 + 0.10) = 7.434 MB.
A vektormezők hatása a lemeztárolóra
A cikk nagy része a memória vektorainak méretéről nyújt tájékoztatást. Ha tudni szeretné a lemez vektorméretét, a vektoradatok lemezhasználata nagyjából háromszorosa a memória vektorindexének. Ha például a vectorIndexSize használat 100 megabájtnál (10 millió bájt) van, akkor legalább 300 megabájt kvótát storageSize használt volna a vektorindexek elhelyezéséhez.