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

Vektoroptimeringstekniker är nu allmänt tillgängliga. Använd funktioner som smala datatyper, skalär och binär 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 omfattas också av diskkvot, i den meningen att alla index ä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. Mer information finns i Storleksgränser för vektorindex.

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:

• I Azure Portal på sidan Översikt för söktjänsten visar både fliken Egenskaper och fliken Användning partitionsstorlek och lagring, samt vektorkvot och vektorindexstorlek.

• På Azure Portal på sidan Skala kan du granska antalet partitioner och storleken.

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.

1. I Azure Portal öppnar du den resursgrupp som innehåller söktjänsten.

2. Välj Distributioner under Inställningar i den vänstra rutan.

3. Leta upp distributionen av söktjänsten. Om det finns många distributioner använder du filtret för att söka efter "search".

4. Välj distributionen. Om du har fler än en klickar du igenom för att se om den matchar din söktjänst.

   

5. Visa distributionsinformation. Du bör se Skapad och skapandedatum.

   

6. Nu när du känner till din söktjänsts ålder granskar du vektorkvotgränserna baserat på hur tjänsten skapas: Storleksgränser för vektorindex.

Så här hämtar du vektorindexstorlek

En begäran om vektormått är en dataplansåtgärd. Du kan använda Azure Portal, 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.

Portal

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 .

REST

REST-API:er för dataplan (alla nyare API:er tillhandahåller vektoranvändningsstatistik):

• GET Service Statistics returnerar kvot och användning för söktjänstens all-up.
• GET Index Statistics returnerar användning för ett visst index.

Användning och kvot rapporteras i byte.

Här är GET-tjänststatistik:

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

Svaret innehåller mått för storageSize, som inte skiljer mellan vektor- och icke-vektorindex. Statistiken vectorIndexSize visar användning och kvot på tjänstnivå.

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

Du kan också skicka en GET-indexstatistik för att hämta indexets fysiska storlek på disken, plus storleken på vektorfälten i minnet.

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

Svaret innehåller användningsinformation på indexnivå. Det här exemplet baseras på indexet som skapades i snabbstarten för integrerad vektorisering som segmenterar och vektoriserar PDF-filer för hälsoplan. Varje segment bidrar till documentCount.

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

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 %
3072	4	0,5 %

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 megabyte (10 miljoner byte) skulle du ha använt minst 300 MB storageSize kvot för att hantera dina vektorindex.