Vectorindexgrootte en onder limieten blijven
Voor elk vectorveld maakt Azure AI Search een interne vectorindex met behulp van de algoritmeparameters die in het veld zijn opgegeven. Omdat Azure AI Search quota's oplegt voor vectorindexgrootte, moet u weten hoe u vectorgrootte kunt schatten en bewaken om ervoor te zorgen dat u onder de limieten blijft.
Notitie
Een opmerking over terminologie. Intern bevatten de fysieke gegevensstructuren van een zoekindex onbewerkte inhoud (gebruikt voor het ophalen van patronen waarvoor niet-tokenized inhoud is vereist), omgekeerde indexen (gebruikt voor doorzoekbare tekstvelden) en vectorindexen (gebruikt voor doorzoekbare vectorvelden). In dit artikel worden de limieten voor de interne vectorindexen uitgelegd die elk van uw vectorvelden terugzetten.
Tip
Vector kwantisatie en opslagconfiguratie is nu algemeen beschikbaar. Gebruik mogelijkheden zoals smalle gegevenstypen, scalaire kwantisatie en verwijdering van redundante opslag om onder vectorquotum en opslagquotum te blijven.
Belangrijke punten over quotum- en vectorindexgrootte
De grootte van de vectorindex wordt gemeten in bytes.
Vectorquota zijn gebaseerd op geheugenbeperkingen. Alle doorzoekbare vectorindexen moeten in het geheugen worden geladen. Tegelijkertijd moet er ook voldoende geheugen zijn voor andere runtimebewerkingen. Er bestaan vectorquota om ervoor te zorgen dat het algehele systeem stabiel en evenwichtig blijft voor alle workloads.
Vectorindexen zijn ook onderworpen aan schijfquotum, in de zin dat alle indexen een schijfquotum hebben. Er is geen afzonderlijk schijfquotum voor vectorindexen.
Vectorquota worden afgedwongen voor de zoekservice als geheel, per partitie, wat betekent dat als u partities toevoegt, het vectorquotum toeneemt. Vectorquota per partitie zijn hoger voor nieuwere services. Zie Limieten voor de grootte van vectorindexen voor meer informatie.
Partitiegrootte en hoeveelheid controleren
Als u niet zeker weet wat de limieten voor uw zoekservice zijn, kunt u deze informatie op twee manieren ophalen:
In De Azure-portal op de pagina Overzicht van de zoekservice geven zowel het tabblad Eigenschappen als het tabblad Gebruik de partitiegrootte en opslag weer, evenals vectorquota en vectorindexgrootte.
In Azure Portal kunt u op de pagina Schaal het aantal en de grootte van partities bekijken.
De aanmaakdatum van de service controleren
Nieuwere services die na 3 april 2024 zijn gemaakt, bieden vijf tot tien keer meer vectoropslag als oudere services met hetzelfde factureringstarief. Als uw service ouder is, kunt u overwegen een nieuwe service te maken en uw inhoud te migreren.
Open in Azure Portal de resourcegroep die uw zoekservice bevat.
Selecteer Implementaties in het meest linkse deelvenster onder Instellingen.
Zoek de implementatie van uw zoekservice. Als er veel implementaties zijn, gebruikt u het filter om te zoeken naar 'zoeken'.
Selecteer de implementatie. Als u meer dan één account hebt, klikt u door om te zien of deze wordt omgezet in uw zoekservice.
Vouw de implementatiedetails uit. Als het goed is, ziet u Gemaakt en de aanmaakdatum.
Nu u de leeftijd van uw zoekservice kent, bekijkt u de limieten voor vectorquota op basis van het maken van de service: Limieten voor de grootte van vectorindexen.
De grootte van de vectorindex ophalen
Een aanvraag voor vectormetrieken is een gegevensvlakbewerking. U kunt Azure Portal, REST API's of Azure SDK's gebruiken om vectorgebruik op serviceniveau te verkrijgen via servicestatistieken en voor afzonderlijke indexen.
Gebruiksgegevens vindt u op het tabblad Gebruik van de pagina Overzicht. Portalpagina's worden elke paar minuten vernieuwd. Als u onlangs een index hebt bijgewerkt, wacht u even voordat u de resultaten controleert.
De volgende schermopname is voor een oudere Standard 1 -zoekservice (S1), geconfigureerd voor één partitie en één replica.
- Opslagquotum is een schijfbeperking en bevat alle indexen (vector en niet-vector) in een zoekservice.
- Het quotum voor de grootte van de vectorindex is een geheugenbeperking. Dit is de hoeveelheid geheugen die nodig is om alle interne vectorindexen te laden die zijn gemaakt voor elk vectorveld in een zoekservice.
De schermopname geeft aan dat indexen (vector en nonvector) bijna 460 megabytes aan beschikbare schijfopslag verbruiken. Vectorindexen verbruiken bijna 93 megabytes geheugen op serviceniveau.
Quota voor zowel opslag- als vectorindexgrootte nemen toe of verkleinen wanneer u partities toevoegt of verwijdert. Als u het aantal partities wijzigt, wordt op de tegel een bijbehorende wijziging in opslag- en vectorquotum weergegeven.
Notitie
Op schijf zijn vectorindexen niet 93 megabytes. Vectorindexen op schijf nemen ongeveer drie keer meer ruimte in beslag dan vectorindexen in het geheugen. Zie Hoe vectorvelden van invloed zijn op schijfopslag voor meer informatie.
Factoren die invloed hebben op de grootte van de vectorindex
Er zijn drie belangrijke onderdelen die van invloed zijn op de grootte van uw interne vectorindex:
- Onbewerkte grootte van de gegevens
- Overhead van het geselecteerde algoritme
- Overhead van het verwijderen of bijwerken van documenten in de index
Onbewerkte grootte van de gegevens
Elke vector is meestal een matrix van drijvendekommanummers met één precisie, in een veld van het type Collection(Edm.Single).
Vectorgegevensstructuren vereisen opslag, die in de volgende berekening wordt weergegeven als de 'onbewerkte grootte' van uw gegevens. Gebruik deze onbewerkte grootte om de vereisten voor de vectorindexgrootte van uw vectorvelden te schatten.
De opslaggrootte van één vector wordt bepaald door de dimensionaliteit. Vermenigvuldig de grootte van één vector met het aantal documenten met dat vectorveld om de onbewerkte grootte te verkrijgen:
raw size = (number of documents) * (dimensions of vector field) * (size of data type)
| EDM-gegevenstype | Grootte van het gegevenstype |
|---|---|
Collection(Edm.Single) |
4 bytes |
Collection(Edm.Half) |
2 bytes |
Collection(Edm.Int16) |
2 bytes |
Collection(Edm.SByte) |
1 byte |
Geheugenoverhead van het geselecteerde algoritme
Elk dichtstbijzijnde buur algoritme (ANN) genereert extra gegevensstructuren in het geheugen om efficiënt zoeken mogelijk te maken. Deze structuren verbruiken extra ruimte binnen het geheugen.
Voor het HNSW-algoritme ligt de geheugenoverhead tussen 1% en 20%.
De geheugenoverhead is lager voor hogere dimensies omdat de onbewerkte grootte van de vectoren toeneemt, terwijl de extra gegevensstructuren een vaste grootte blijven omdat ze informatie over de connectiviteit in de grafiek opslaan. De bijdrage van de extra gegevensstructuren vormt dus een kleiner deel van de totale grootte.
De geheugenoverhead is hoger voor grotere waarden van de HNSW-parameter m, die het aantal bidirectionele koppelingen bepaalt dat voor elke nieuwe vector is gemaakt tijdens het bouwen van de index. Dit komt doordat m een bijdrage van ongeveer 8 bytes aan 10 bytes per document wordt vermenigvuldigd met m.
De volgende tabel bevat een overzicht van de overheadpercentages die in interne tests zijn waargenomen:
| Afmetingen | HNSW-parameter (m) | Overheadpercentage |
|---|---|---|
| 96 | 4 | 20% |
| 200 | 4 | %8 |
| 768 | 4 | %2 |
| 1536 | 4 | %1 |
| 3072 | 4 | 0,5% |
Deze resultaten laten de relatie zien tussen dimensies, HNSW-parameter men geheugenoverhead voor het HNSW-algoritme.
Overhead van het verwijderen of bijwerken van documenten in de index
Wanneer een document met een vectorveld wordt verwijderd of bijgewerkt (updates worden intern weergegeven als verwijder- en invoegbewerking), wordt het onderliggende document gemarkeerd als verwijderd en overgeslagen tijdens volgende query's. Naarmate er nieuwe documenten worden geïndexeerd en de interne vectorindex groeit, schoont het systeem deze verwijderde documenten op en maakt het de resources vrij. Dit betekent dat u waarschijnlijk een vertraging ziet tussen het verwijderen van documenten en de onderliggende resources die worden vrijgemaakt.
Dit wordt de verhouding tussen verwijderde documenten genoemd. Omdat de verhouding van verwijderde documenten afhankelijk is van de indexeringskenmerken van uw service, is er geen universele heuristiek om deze parameter te schatten en er is geen API of script dat de verhouding voor uw service retourneert. We zien dat de helft van onze klanten een verwijderde documentenverhouding heeft van minder dan 10%. Als u vaak verwijderingen of updates met een hoge frequentie uitvoert, kunt u een hogere verhouding tussen verwijderde documenten bekijken.
Dit is een andere factor die van invloed is op de grootte van uw vectorindex. Helaas hebben we geen mechanisme om de huidige verhouding tussen verwijderde documenten weer te geven.
De totale grootte voor uw gegevens in het geheugen schatten
Als u rekening wilt houden met de eerder beschreven factoren, gebruikt u de volgende berekening om de totale grootte van uw vectorindex te schatten:
(raw_size) * (1 + algorithm_overhead (in percent)) * (1 + deleted_docs_ratio (in percent))
Als u bijvoorbeeld de raw_size wilt berekenen, gaan we ervan uit dat u een populair Azure OpenAI-model gebruikt, text-embedding-ada-002 met 1536 dimensies. Dit betekent dat één document 1536 Edm.Single (floats) of 6.144 bytes verbruikt omdat elk Edm.Single 4 bytes is. 1000 documenten met één, 1.536 dimensional vectorveld verbruikt in totaal 1000 docs x 1536 floats/doc = 1536.000 floats of 6.144.000 bytes.
Als u meerdere vectorvelden hebt, moet u deze berekening uitvoeren voor elk vectorveld in uw index en ze allemaal bij elkaar optellen. 1000 documenten met twee 1.536 dimensionale vectorvelden verbruiken bijvoorbeeld 1000 docs x 2 velden x 1536 floats/doc x 4 bytes/float = 12.288.000 bytes.
Als u de grootte van de vectorindex wilt verkrijgen, vermenigvuldigt u deze raw_size door de overhead van het algoritme en de verwijderde documentverhouding. Als de overhead van uw algoritme voor de gekozen HNSW-parameters 10% is en uw verwijderde documentverhouding 10% is, krijgen we het volgende: 6.144 MB * (1 + 0.10) * (1 + 0.10) = 7.434 MB
Hoe vectorvelden van invloed zijn op schijfopslag
De meeste van dit artikel bevat informatie over de grootte van vectoren in het geheugen. Als u meer wilt weten over vectorgrootte op schijf, is het schijfverbruik voor vectorgegevens ongeveer drie keer zo groot als de vectorindex in het geheugen. Als uw vectorIndexSize gebruik bijvoorbeeld 100 megabytes (10 miljoen bytes) bedraagt, zou u ten minste 300 megabytes storageSize aan quotum hebben gebruikt om uw vectorindexen te kunnen gebruiken.