Vektorindexstorlek och att hålla sig under gränser
För varje vektorfält konstruerar Azure AI Search ett internt vektorindex med hjälp av de algoritmparametrar som anges i fältet. Eftersom Azure AI Search inför kvoter för vektorindexstorlek bör du veta hur du beräknar och övervakar vektorstorlek för att säkerställa att du håller dig under gränserna.
Kommentar
En anteckning om terminologi. Internt innehåller de fysiska datastrukturerna i ett sökindex rådata (används för hämtningsmönster som kräver icke-tokeniserat innehåll), inverterade index (används för sökbara textfält) och vektorindex (används för sökbara vektorfält). Den här artikeln beskriver gränserna för de interna vektorindex som backar upp vart och ett av dina vektorfält.
Dricks
Vektorkvantisering och lagringskonfiguration är nu i förhandsversion. Använd funktioner som smala datatyper, skalbar kvantisering och eliminering av redundant lagring för att hålla dig under vektorkvot och lagringskvot.
Viktiga punkter om kvot- och vektorindexstorlek
Vektorindexstorlek mäts i byte.
Vektorkvoter baseras på minnesbegränsningar. Alla sökbara vektorindex måste läsas in i minnet. Samtidigt måste det också finnas tillräckligt med minne för andra körningsåtgärder. Vektorkvoter finns för att säkerställa att det övergripande systemet förblir stabilt och balanserat för alla arbetsbelastningar.
Vektorindex är också föremål för diskkvot, i den meningen att alla index, vektorer och icke-belackare, är ämnesdiskkvoter. Det finns ingen separat diskkvot för vektorindex.
Vektorkvoter tillämpas på söktjänsten som helhet, per partition, vilket innebär att om du lägger till partitioner ökar vektorkvoten. Vektorkvoter per partition är högre för nyare tjänster:
Så här kontrollerar du partitionens storlek och kvantitet
Om du inte är säker på vilka gränserna för söktjänsten är kan du hämta den här informationen på två sätt:
På sidan Översikt för söktjänsten i Azure-portalen visar både fliken Egenskaper och fliken Användning partitionsstorlek och lagring, samt storlek på vektorkvot och vektorindex.
På sidan Skala i Azure-portalen kan du granska antalet och storleken på partitioner.
Så här kontrollerar du datumet då tjänsten skapades
Nyare tjänster som skapats efter den 3 april 2024 erbjuder fem till tio gånger mer vektorlagring som äldre med samma faktureringshastighet på samma nivå. Om tjänsten är äldre kan du överväga att skapa en ny tjänst och migrera ditt innehåll.
Öppna den resursgrupp som innehåller söktjänsten i Azure-portalen.
Välj Distributioner under Inställningar längst till vänster.
Leta upp distributionen av söktjänsten. Om det finns många distributioner använder du filtret för att söka efter "search".
Välj distributionen. Om du har fler än en klickar du igenom för att se om den matchar din söktjänst.
Visa distributionsinformation. Du bör se Skapad och skapandedatum.
Nu när du känner till din söktjänsts ålder granskar du vektorkvotgränserna baserat på hur tjänsten skapas:
Så här hämtar du vektorindexstorlek
En begäran om vektormått är en dataplansåtgärd. Du kan använda Azure-portalen, REST-API:er eller Azure SDK:er för att hämta vektoranvändning på tjänstnivå via tjänststatistik och för enskilda index.
Användningsinformation finns på fliken Användning på översiktssidan. Portalsidor uppdateras med några minuters mellanrum, så om du nyligen har uppdaterat ett index väntar du lite innan du kontrollerar resultatet.
Följande skärmbild är för en äldre S1-söktjänst (Standard 1), konfigurerad för en partition och en replik.
- Lagringskvoten är en diskbegränsning och omfattar alla index (vektor och icke-bevektor) i en söktjänst.
- Vektorindexstorlekskvot är en minnesbegränsning. Det är mängden minne som krävs för att läsa in alla interna vektorindex som skapats för varje vektorfält i en söktjänst.
Skärmbilden visar att index (vektor och icke-bevektor) förbrukar nästan 460 mb tillgängligt diskutrymme. Vektorindex förbrukar nästan 93 mb minne på tjänstnivå.
Kvoter för både lagring och vektorindex ökar eller minskar när du lägger till eller tar bort partitioner. Om du ändrar antalet partitioner visar panelen en motsvarande ändring i lagrings- och vektorkvoten.
Kommentar
På disken är vektorindex inte 93 megabyte. Vektorindex på disken tar upp ungefär tre gånger mer utrymme än vektorindex i minnet. Mer information finns i Hur vektorfält påverkar disklagring .
Faktorer som påverkar vektorindexstorlek
Det finns tre huvudkomponenter som påverkar storleken på ditt interna vektorindex:
- Rådatastorlek
- Overhead från den valda algoritmen
- Omkostnader för att ta bort eller uppdatera dokument i indexet
Rådatastorlek
Varje vektor är vanligtvis en matris med flyttal med enkel precision i ett fält av typen Collection(Edm.Single).
Vektordatastrukturer kräver lagring, som representeras i följande beräkning som "råstorlek" för dina data. Använd den här råstorleken för att uppskatta storlekskraven för vektorindex för dina vektorfält.
Lagringsstorleken för en vektor bestäms av dess dimensionalitet. Multiplicera storleken på en vektor med antalet dokument som innehåller vektorfältet för att få den råa storleken:
raw size = (number of documents) * (dimensions of vector field) * (size of data type)
| EDM-datatyp | Datatypens storlek |
|---|---|
Collection(Edm.Single) |
4 byte |
Collection(Edm.Half) |
2 byte |
Collection(Edm.Int16) |
2 byte |
Collection(Edm.SByte) |
1 byte |
Minnesomkostnader från den valda algoritmen
Varje ungefärlig algoritm för närmaste granne (ANN) genererar extra datastrukturer i minnet för att möjliggöra effektiv sökning. Dessa strukturer förbrukar extra utrymme i minnet.
För HNSW-algoritmen varierar minneskostnaderna mellan 1 % och 20 %.
Minneskostnaderna är lägre för högre dimensioner eftersom vektorernas råstorlek ökar, medan de extra datastrukturerna förblir en fast storlek eftersom de lagrar information om anslutningen i diagrammet. De extra datastrukturernas bidrag utgör därför en mindre del av den totala storleken.
Minneskostnaderna är högre för större värden för HNSW-parametern m, som avgör antalet dubbelriktade länkar som skapats för varje ny vektor under indexkonstruktionen. Detta beror på att m bidrar med cirka 8 byte till 10 byte per dokument multiplicerat mmed .
I följande tabell sammanfattas de omkostnader som observerats i interna tester:
| Dimensioner | HNSW-parameter (m) | Omkostnader i procent |
|---|---|---|
| 96 | 4 | 20 % |
| 200 | 4 | %8 |
| 768 | 4 | %2 |
| 1536 | 4 | 1 % |
Dessa resultat visar relationen mellan dimensioner, HNSW-parameter och mminnesomkostnader för HNSW-algoritmen.
Omkostnader för att ta bort eller uppdatera dokument i indexet
När ett dokument med ett vektorfält antingen tas bort eller uppdateras (uppdateringar representeras internt som en borttagnings- och infogningsåtgärd) markeras det underliggande dokumentet som borttaget och hoppas över under efterföljande frågor. När nya dokument indexeras och det interna vektorindexet växer rensar systemet de borttagna dokumenten och återtar resurserna. Det innebär att du förmodligen ser en fördröjning mellan att ta bort dokument och de underliggande resurser som frigörs.
Vi refererar till detta som förhållandet för borttagna dokument. Eftersom förhållandet för borttagna dokument beror på indexeringsegenskaperna för din tjänst finns det ingen universell heuristisk för att uppskatta den här parametern, och det finns inget API eller skript som returnerar förhållandet som gäller för din tjänst. Vi observerar att hälften av våra kunder har ett borttaget dokumentförhållande som är mindre än 10 %. Om du tenderar att utföra högfrekventa borttagningar eller uppdateringar kan du observera ett högre förhållande för borttagna dokument.
Detta är en annan faktor som påverkar storleken på ditt vektorindex. Tyvärr har vi ingen mekanism för att visa upp ditt aktuella borttagna dokumentförhållande.
Beräkna den totala storleken för dina data i minnet
Använd följande beräkning för att beräkna den totala storleken på ditt vektorindex med hänsyn till de tidigare beskrivna faktorerna:
(raw_size) * (1 + algorithm_overhead (in percent)) * (1 + deleted_docs_ratio (in percent))
Om du till exempel vill beräkna raw_size antar vi att du använder en populär Azure OpenAI-modell text-embedding-ada-002 med 1 536 dimensioner. Det innebär att ett dokument skulle förbruka 1 536 Edm.Single (flyttal) eller 6 144 byte eftersom var och en Edm.Single är 4 byte. 1 000 dokument med ett enda, 1 536 dimensionellt vektorfält skulle förbruka totalt 1 000 dokument x 1 536 floats/doc = 1 536 000 floats eller 6 144 000 byte.
Om du har flera vektorfält måste du utföra den här beräkningen för varje vektorfält i ditt index och lägga till dem alla tillsammans. Till exempel använder 1 000 dokument med två 1 536 dimensionella vektorfält 1 000 dokument x 2 fält x 1 536 floats/doc x 4 byte/float = 12 288 000 byte.
För att få vektorindexstorleken multiplicerar du den här raw_size med algoritmens omkostnader och borttagna dokumentförhållande. Om dina algoritmkostnader för dina valda HNSW-parametrar är 10 % och ditt borttagna dokumentförhållande är 10 %, får vi: 6.144 MB * (1 + 0.10) * (1 + 0.10) = 7.434 MB.
Hur vektorfält påverkar disklagring
Merparten av den här artikeln innehåller information om storleken på vektorer i minnet. Om du vill veta om vektorstorleken på disken är diskförbrukningen för vektordata ungefär tre gånger så stor som vektorindexet i minnet. Om din vectorIndexSize användning till exempel är 100 mb (10 miljoner byte) skulle du ha använt minst 300 MB storageSize kvot för att hantera dina vektorindex