Minska vektorstorleken genom kvantisering, smala datatyper och lagringsalternativ
Den här artikeln beskriver hur du använder kvantisering av vektorer och andra tekniker för att minska vektorstorleken i Azure AI Search. Sökindexet anger definitioner för vektorfält, inklusive egenskaper som används för att ange smala datatyper eller styra om en kopia av vektorinnehåll behålls för sökresultat. Kvantisering anges också i indexet och tilldelas till vektorfältet via dess vektorprofil.
De flesta funktioner som beskrivs i den här artikeln är allmänt tillgängliga i REST-API :et 2024-07-01 och i Azure SDK-paket som riktar sig mot den versionen. Den senaste förhandsversionen lägger till stöd för trunkerade dimensioner om du använder text-embedding-3-large eller text-embedding-3-small för vektorisering.
Ett exempel i slutet av den här artikeln visar variationerna i vektorstorlek för var och en av de metoder som beskrivs i den här artikeln.
Utvärdera alternativen
Som ett första steg granskar du de tre metoderna för att minska mängden lagringsutrymme som används av vektorfält. Dessa metoder är inte ömsesidigt uteslutande och kan kombineras för maximal minskning av vektorstorleken.
Vi rekommenderar inbyggd kvantisering eftersom den komprimerar vektorstorleken i minnet och på disken med minimal ansträngning och som tenderar att ge mest nytta i de flesta scenarier. Däremot kräver smala typer (förutom float16) en särskild ansträngning för att göra dem och stored
sparar på disklagring, vilket inte är lika dyrt som minne.
Metod | Varför använda detta alternativ? |
---|---|
Lägga till skalär eller binär kvantisering | Använd kvantisering för att komprimera interna float32- eller float16-inbäddningar till int8 (skalär) eller Byte (binär). Det här alternativet minskar lagringen i minnet och på disken utan försämrad frågeprestanda. Mindre datatyper som int8 eller Byte skapar vektorindex som är mindre innehållsrika än de med större inbäddningar. För att kompensera för informationsförlust innehåller inbyggd komprimering alternativ för bearbetning efter fråga med okomprimerade inbäddningar och översampling för att returnera mer relevanta resultat. Reranking och översampling är specifika funktioner i den inbyggda kvantiseringen av float32- eller float16-fält och kan inte användas på inbäddningar som genomgår anpassad kvantisering. |
Trunkera dimensioner för MRL-kompatibla text-embedding-3-modeller (förhandsversion) | Använd alternativet för att använda färre dimensioner på text-embedding-3-modeller. I Azure OpenAI har de här modellerna tränats om med tekniken Matryoshka Representation Learning (MRL) som producerar flera vektorrepresentationer på olika komprimeringsnivåer. Den här metoden ger snabbare sökningar och minskade lagringskostnader, med minimal förlust av semantisk information. I Azure AI Search har MRL stöd för skalära och binära kvantiseringar. När du använder någon av kvantiseringsmetoderna kan du också ange en truncateDimension egenskap för dina vektorfält för att minska dimensionaliteten för text-inbäddningar. |
Tilldela mindre primitiva datatyper till vektorfält | Smala datatyper, till exempel float16, int16, int8 och Byte (binär) förbrukar mindre utrymme i minnet och på disken, men du måste ha en inbäddningsmodell som matar ut vektorer i ett smalt dataformat. Eller så måste du ha anpassad kvantiseringslogik som matar ut små data. Ett tredje användningsfall som kräver mindre arbete är omarbetning av inbäddning av inbyggda float32-inbäddningar som produceras av de flesta modeller till float16. Mer information om binära vektorer finns i Index binära vektorer. |
Eliminera valfri lagring av hämtningsbara vektorer | Vektorer som returneras i ett frågesvar lagras separat från vektorer som används vid frågekörning. Om du inte behöver returnera vektorer kan du inaktivera hämtningsbar lagring, vilket minskar den totala disklagringen per fält med upp till 50 procent. |
Alla dessa alternativ definieras för ett tomt index. Om du vill implementera någon av dem använder du Azure Portal, REST API:er eller ett Azure SDK-paket som riktar sig till den API-versionen.
När indexet har definierats kan du läsa in och indexeras som ett separat steg.
Alternativ 1: Konfigurera kvantisering
Kvantisering rekommenderas för att minska vektorstorleken eftersom den sänker både minnes- och disklagringskraven för float16- och float32-inbäddningar. För att kompensera effekterna av ett mindre index kan du lägga till översampling och omrankning över okomprimerade vektorer.
Kvantisering gäller för vektorfält som tar emot float-type-vektorer. I exemplen i den här artikeln är Collection(Edm.Single)
fältets datatyp för inkommande float32-inbäddningar, men float16 stöds också. När vektorerna tas emot på ett fält med komprimering konfigurerad utför motorn automatiskt kvantisering för att minska fotavtrycket för vektordata i minnet och på disken.
Två typer av kvantisering stöds:
Scalar-kvantisering komprimerar flyttalvärden till smalare datatyper. AI Search stöder för närvarande int8, vilket är 8 bitar, vilket minskar vektorindexstorleken fyrfaldigt.
Binär kvantisering konverterar flyttal till binära bitar, vilket tar upp 1 bit. Detta resulterar i upp till 28 gånger lägre vektorindexstorlek.
Följ dessa steg om du vill använda inbyggd kvantisering:
- Använd Skapa index eller Skapa eller uppdatera index för att ange vektorkomprimering
- Lägg till
vectorSearch.compressions
i ett sökindex - Lägg till en
scalarQuantization
ellerbinaryQuantization
konfiguration och ge den ett namn - Ange valfria egenskaper för att minimera effekterna av förlust av indexering
- Skapa en ny vektorprofil som använder den namngivna konfigurationen
- Skapa ett nytt vektorfält med den nya vektorprofilen
- Läs in indexet med float32- eller float16-data som kvantifieras under indexeringen med den konfiguration som du definierade
- Du kan också köra frågor mot kvantiserade data med hjälp av parametern översampling om du vill åsidosätta standardvärdet
Lägga till "komprimeringar" i ett sökindex
I följande exempel visas en partiell indexdefinition med en fältsamling som innehåller ett vektorfält och ett vectorSearch.compressions
avsnitt.
Det här exemplet innehåller både scalarQuantization
eller binaryQuantization
. Du kan ange så många komprimeringskonfigurationer som du behöver och sedan tilldela de som du vill ha till en vektorprofil.
POST https://[servicename].search.windows.net/indexes?api-version=2024-07-01
{
"name": "my-index",
"fields": [
{ "name": "Id", "type": "Edm.String", "key": true, "retrievable": true, "searchable": true, "filterable": true },
{ "name": "content", "type": "Edm.String", "retrievable": true, "searchable": true },
{ "name": "vectorContent", "type": "Collection(Edm.Single)", "retrievable": false, "searchable": true, "dimensions": 1536,"vectorSearchProfile": "vector-profile-1"},
],
"vectorSearch": {
"profiles": [ ],
"algorithms": [ ],
"compressions": [
{
"name": "use-scalar",
"kind": "scalarQuantization",
"scalarQuantizationParameters": {
"quantizedDataType": "int8"
},
"rerankWithOriginalVectors": true,
"defaultOversampling": 10
},
{
"name": "use-binary",
"kind": "binaryQuantization",
"rerankWithOriginalVectors": true,
"defaultOversampling": 10
}
]
}
}
Viktiga punkter:
kind
måste anges tillscalarQuantization
ellerbinaryQuantization
rerankWithOriginalVectors
använder de ursprungliga, okomprimerade vektorerna för att beräkna om likheten och beräkna om de översta resultaten som returneras av den första sökfrågan. De okomprimerade vektorerna finns i sökindexet även omstored
det är falskt. Den här egenskapen är valfri. Standard är sant.defaultOversampling
Parlamentet anser att det finns en bredare uppsättning potentiella resultat för att kompensera för minskningen av informationen från kvantiseringen. Formeln för potentiella resultat består avk
i frågan, med en översamplingsmultiplikator. Om frågan till exempel anger enk
av 5 och översampling är 20, begär frågan effektivt 100 dokument för användning vid omrankning, med den ursprungliga okomprimerade vektorn för det ändamålet. Endast de högstk
rankade resultaten returneras. Den här egenskapen är valfri. Standardvärdet är 4.quantizedDataType
är valfritt och gäller endast för skalära kvantiseringar. Om du lägger till den måste den vara inställd påint8
. Det här är den enda primitiva datatypen som stöds för skalbar kvantisering just nu. Standard ärint8
.
Lägg till HNSW-algoritmen
Kontrollera att ditt index har HNSW-algoritmen (Hierarchical Navigable Small Worlds). Inbyggd kvantisering stöds inte med fullständig KNN.
"vectorSearch": {
"profiles": [ ],
"algorithms": [
{
"name": "use-hnsw",
"kind": "hnsw",
"hnswParameters": {
"m": 4,
"efConstruction": 400,
"efSearch": 500,
"metric": "cosine"
}
}
],
"compressions": [ <see previous section>]
}
Skapa och tilldela en ny vektorprofil
Om du vill använda en ny kvantiseringskonfiguration måste du skapa en ny vektorprofil. Det är nödvändigt att skapa en ny vektorprofil för att skapa komprimerade index i minnet. Den nya profilen använder HNSW.
I samma indexdefinition skapar du en ny vektorprofil och lägger till en komprimeringsegenskap och en algoritm. Här är två profiler, en för varje kvantiseringsmetod.
"vectorSearch": { "profiles": [ { "name": "vector-profile-hnsw-scalar", "compression": "use-scalar", "algorithm": "use-hnsw", "vectorizer": null }, { "name": "vector-profile-hnsw-binary", "compression": "use-binary", "algorithm": "use-hnsw", "vectorizer": null } ], "algorithms": [ <see previous section> ], "compressions": [ <see previous section> ] }
Tilldela en vektorprofil till ett nytt vektorfält. Datatypen för fältet är antingen float32 eller float16.
I Azure AI Search är
Collection(Edm.Single)
EDM-motsvarigheterna (Entity Data Model) för typerna float32 respektive float16 ochCollection(Edm.Half)
.{ "name": "vectorContent", "type": "Collection(Edm.Single)", "searchable": true, "retrievable": true, "dimensions": 1536, "vectorSearchProfile": "vector-profile-hnsw-scalar", }
Läs in indexet med indexerare för pull-modellindexering eller API:er för push-modellindexering.
Så här fungerar skalbar kvantisering i Azure AI Search
Scalar-kvantisering minskar upplösningen för varje tal inom varje vektorbäddning. I stället för att beskriva varje tal som ett 16-bitars eller 32-bitars flyttalsnummer använder det ett 8-bitars heltal. Den identifierar ett intervall med tal (vanligtvis 99:e percentilens lägsta och högsta) och delar upp dem i ett begränsat antal nivåer eller lagerplatser och tilldelar varje lagerplats en identifierare. I 8-bitars scalar-kvantisering finns det 2^8 eller 256 möjliga intervall.
Varje komponent i vektorn mappas till närmaste representativa värde inom den här uppsättningen kvantiseringsnivåer i en process som liknar avrundning av ett verkligt tal till närmaste heltal. I den kvantiserade 8-bitarsvektorn står identifierarnumret i stället för det ursprungliga värdet. Efter kvantiseringen representeras varje vektor av en matris med identifierare för de lagerplatser som dess komponenter tillhör. Dessa kvantiserade vektorer kräver mycket färre bitar att lagra jämfört med den ursprungliga vektorn, vilket minskar lagringskraven och minnesfotavtrycket.
Så här fungerar binär kvantisering i Azure AI Search
Binär kvantisering komprimerar högdimensionella vektorer genom att representera varje komponent som en enda bit, antingen 0 eller 1. Den här metoden minskar drastiskt minnesfotavtrycket och påskyndar vektorjämförelseåtgärder, vilket är avgörande för sök- och hämtningsuppgifter. Benchmark-tester visar upp till 96 % minskning av vektorindexstorleken.
Det är särskilt effektivt för inbäddningar med dimensioner större än 1024. För mindre dimensioner rekommenderar vi att du testar kvaliteten på binär kvantisering eller provar skalär i stället. Dessutom har vi upptäckt att BQ fungerar mycket bra när inbäddningar centreras runt noll. De flesta populära inbäddningsmodeller som OpenAI, Cohere och Mistral är centrerade runt noll.
Använda MRL-komprimering och trunkerade dimensioner (förhandsversion)
MRL-komprimering på flera nivåer sparar på vektorlagring och förbättrar frågesvarstiderna för vektorfrågor baserat på text inbäddningar. I Azure AI Search erbjuds MRL-stöd endast tillsammans med en annan kvantiseringsmetod. Om du använder binär kvantisering med MRL får du maximal minskning av vektorindexstorleken. För att uppnå maximal lagringsminskning använder du binär kvantisering med MRL och stored
ställer in på false.
Den här funktionen är en förhandsversion. Den är tillgänglig i 2024-09-01-preview
och i beta-SDK-paket som riktar sig till den förhandsversionen av API:et.
Krav
- Text-embedding-3-small, Text-embedding-3-large (endast textinnehåll).
- Nya vektorfält av typen
Edm.Half
ellerEdm.Single
(du kan inte lägga till MRL-komprimering i ett befintligt fält). - HNSW-algoritm ( inget stöd för fullständig KNN i den här förhandsversionen).
- Konfigurera skalär eller binär kvantisering. Vi rekommenderar binär kvantisering.
Klienter som stöds
- REST API 2024-09-01-preview
- Kontrollera ändringsloggarna för varje Azure SDK-betapaket: Python, .NET, Java, JavaScript.
Det finns för närvarande inget stöd för Azure Portal eller Azure AI Studio.
Så här använder du MRL-utökade textbäddningar
MRL är en funktion i textembedding-modellen. Följ dessa steg för att dra nytta av dessa funktioner i Azure AI Search.
- Ange ett
vectorSearch.compressions
objekt i indexdefinitionen. - Inkludera en kvantiseringsmetod, antingen skalär eller binär (rekommenderas).
- Inkludera parametern
truncationDimension
inställd på 512 eller så lågt som 256 om du använder modellen textinbäddning-3-large. - Ange en vektorprofil som anger HNSW-algoritmen och vektorkomprimeringsobjektet.
- Tilldela vektorprofilen till ett vektorfält av typen
Edm.Half
ellerEdm.Single
i fältsamlingen.
Det finns inga ändringar på frågesidan för att använda en MRL-kompatibel textinbäddningsmodell. Integrerad vektorisering, text-till-fråga-konverteringar vid frågetillfället, semantisk rangordning och andra relevansförbättringsfunktioner som att ändra rangordning med ursprungliga vektorer och översampling påverkas inte av MRL-stöd.
Indexeringen går långsammare på grund av de extra stegen, men frågorna går snabbare.
Exempel på en konfiguration för vektorsökning som stöder MRL
I följande exempel visas en konfiguration för vektorsökning som uppfyller kraven och rekommendationerna för MRL.
truncationDimension
är en komprimeringsegenskap. Den anger hur mycket vektordiagrammet ska krympas i minnet tillsammans med en komprimeringsmetod som skalär eller binär komprimering. Vi rekommenderar 1 024 eller högre för truncationDimension
med binär kvantisering. En dimensionalitet på mindre än 1 000 försämrar kvaliteten på sökresultaten när du använder MRL och binär komprimering.
{
"vectorSearch": {
"profiles": [
{
"name": "use-bq-with-mrl",
"compression": "use-mrl,use-bq",
"algorithm": "use-hnsw"
}
],
"algorithms": [
{
"name": "use-hnsw",
"kind": "hnsw",
"hnswParameters": {
"m": 4,
"efConstruction": 400,
"efSearch": 500,
"metric": "cosine"
}
}
],
"compressions": [
{
"name": "use-mrl",
"kind": "truncation",
"rerankWithOriginalVectors": true,
"defaultOversampling": 10,
"truncationDimension": 1024
},
{
"name": "use-bq",
"kind": "binaryQuantization",
"rerankWithOriginalVectors": true,
"defaultOversampling": 10
}
]
}
}
Här är ett exempel på en fullständigt angiven vektorfältdefinition som uppfyller kraven för MRL.
Kom ihåg att vektorfält måste vara av typen Edm.Half
eller Edm.Single
. Vektorfält måste ha en vectorSearchProfile
egenskap som avgör algoritmen och komprimeringsinställningarna. Vektorfält har en dimensions
egenskap som används för att ange antalet dimensioner för bedömning och rangordning av resultat. Värdet ska vara dimensionsgränsen för den modell som du använder (1 536 för textinbäddning-3-small).
{
"name": "text_vector",
"type": "Collection(Edm.Single)",
"searchable": true,
"filterable": false,
"retrievable": false,
"stored": false,
"sortable": false,
"facetable": false,
"key": false,
"indexAnalyzer": null,
"searchAnalyzer": null,
"analyzer": null,
"normalizer": null,
"dimensions": 1536,
"vectorSearchProfile": "use-bq-with-mrl",
"vectorEncoding": null,
"synonymMaps": []
}
Alternativ 2: Tilldela smala datatyper till vektorfält
Ett enkelt sätt att minska vektorstorleken är att lagra inbäddningar i ett mindre dataformat. De flesta inbäddningsmodeller matar ut 32-bitars flyttalsnummer, men om du kvantifierar dina vektorer, eller om inbäddningsmodellen stöder det internt, kan utdata vara float16, int16 eller int8, som är betydligt mindre än float32. Du kan hantera dessa mindre vektorstorlekar genom att tilldela en smal datatyp till ett vektorfält. I vektorindexet förbrukar smala datatyper mindre lagringsutrymme.
Granska de datatyper som används för vektorfält för rekommenderad användning:
Collection(Edm.Single)
32-bitars flyttals (standard)Collection(Edm.Half)
16-bitars flyttals (smal)Collection(Edm.Int16)
16-bitars signerat heltal (smalt)Collection(Edm.SByte)
8-bitars signerat heltal (smalt)Collection(Edm.Byte)
8-bitars osignerat heltal (tillåts endast med paketerade binära datatyper)
I den listan avgör du vilken datatyp som är giltig för inbäddningsmodellens utdata eller för vektorer som genomgår anpassad kvantisering.
Följande tabell innehåller länkar till flera inbäddningsmodeller som kan använda en smal datatyp (
Collection(Edm.Half)
) utan extra kvantisering. Du kan casta från float32 till float16 (med )Collection(Edm.Half)
utan extra arbete.Inbäddningsmodell Interna utdata Tilldela den här typen i Azure AI Search text-embedding-ada-002 Float32
Collection(Edm.Single)
ellerCollection(Edm.Half)
text-embedding-3-small Float32
Collection(Edm.Single)
ellerCollection(Edm.Half)
text-embedding-3-large Float32
Collection(Edm.Single)
ellerCollection(Edm.Half)
Cohere V3-inbäddningsmodeller med int8 embedding_type Int8
Collection(Edm.SByte)
Andra smala datatyper kan användas om din modell genererar inbäddningar i det mindre dataformatet, eller om du har anpassad kvantisering som konverterar vektorer till ett mindre format.
Se till att du förstår kompromisserna för en smal datatyp.
Collection(Edm.Half)
har mindre information, vilket resulterar i lägre upplösning. Om dina data är homogena eller kompakta kan det leda till oacceptabla resultat vid frågetillfället om du förlorar extra detaljer eller nyanser eftersom det finns mindre information som kan användas för att skilja mellan närliggande vektorer.Definiera och skapa indexet. Du kan använda Azure Portal, Skapa eller Uppdatera index (REST API) eller ett Azure SDK-paket för det här steget.
Kontrollera resultatet. Förutsatt att vektorfältet är markerat som hämtningsbart använder du Sökutforskaren eller Sök – POST för att verifiera att fältinnehållet matchar datatypen.
Om du vill kontrollera storleken på vektorindexet använder du Azure Portal eller REST-API:et (GET Statistics).
Kommentar
Fältets datatyp används för att skapa den fysiska datastrukturen. Om du vill ändra en datatyp senare kan du antingen släppa och återskapa indexet eller skapa ett andra fält med den nya definitionen.
Alternativ 3: Ställ in egenskapen stored
för att ta bort hämtningsbar lagring
Egenskapen stored
är boolesk i en definition av vektorfält som avgör om lagringen allokeras för innehåll i hämtningsbara vektorfält. Egenskapen stored
är true som standard. Om du inte behöver vektorinnehåll i ett frågesvar kan du spara upp till 50 procent lagringsutrymme per fält genom att ange stored
falskt.
Överväganden för att ställa in stored
på false:
Eftersom vektorer inte är läsbara för människor kan du utelämna dem från resultat som skickas till LLMs i RAG-scenarier och från resultat som återges på en söksida. Behåll dem dock om du använder vektorer i en nedströmsprocess som använder vektorinnehåll.
Men om indexeringsstrategin innehåller partiella dokumentuppdateringar, till exempel "merge" eller "mergeOrUpload" i ett dokument, bör du vara medveten om att inställningen
stored
false leder till att vektorer i det icke-lagrade fältet utelämnas under sammanfogningen. För varje "sammanslagning" eller "mergeOrUpload"-åtgärd måste du ange vektorfälten utöver andra icke-bevektorfält som du uppdaterar, annars kommer vektorn att tas bort.
Kom ihåg att attributionen stored
inte kan ångras. Den anges när index skapas på vektorfält när fysiska datastrukturer skapas. Om du vill hämta vektorinnehåll senare måste du släppa och återskapa indexet, eller skapa och läsa in ett nytt fält som har den nya attributionen.
I följande exempel visas fältsamlingen för ett sökindex. Ställ in stored
på false för att permanent ta bort hämtningsbar lagring för vektorfältet.
PUT https://[service-name].search.windows.net/indexes/demo-index?api-version=2024-07-01
Content-Type: application/json
api-key: [admin key]
{
"name": "demo-index",
"fields": [
{
"name": "vectorContent",
"type": "Collection(Edm.Single)",
"retrievable": false,
"stored": false,
"dimensions": 1536,
"vectorSearchProfile": "vectorProfile"
}
]
}
Viktiga punkter:
Gäller endast för vektorfält .
Påverkar lagring på disk, inte minne, och det har ingen effekt på frågor. Frågekörningen använder ett separat vektorindex som inte påverkas av
stored
egenskapen.Egenskapen
stored
anges när index skapas på vektorfält och kan inte ångras. Om du vill hämta innehåll senare måste du släppa och återskapa indexet eller skapa och läsa in ett nytt fält som har den nya attributionen.Standardvärden är
stored
inställda på true ochretrievable
inställda på false. I en standardkonfiguration lagras en hämtningsbar kopia, men den returneras inte automatiskt i resultat. Närstored
är sant kan du växlaretrievable
mellan sant och falskt när som helst utan att behöva återskapa ett index. Närstored
är falskt,retrievable
måste vara falskt och kan inte ändras.
Exempel: komprimeringstekniker för vektorer
Här är Python-kod som demonstrerar kvantisering, smala datatyper och användning av den lagrade egenskapen: Kodexempel: Vektorkvantisering och lagringsalternativ med Python.
Den här koden skapar och jämför lagrings- och vektorindexstorlek för varje alternativ:
****************************************
Index Name: compressiontest-baseline
Storage Size: 21.3613MB
Vector Size: 4.8277MB
****************************************
Index Name: compressiontest-compression
Storage Size: 17.7604MB
Vector Size: 1.2242MB
****************************************
Index Name: compressiontest-narrow
Storage Size: 16.5567MB
Vector Size: 2.4254MB
****************************************
Index Name: compressiontest-no-stored
Storage Size: 10.9224MB
Vector Size: 4.8277MB
****************************************
Index Name: compressiontest-all-options
Storage Size: 4.9192MB
Vector Size: 1.2242MB
Sök-API:er rapporterar lagring och vektorstorlek på indexnivå, så index och inte fält måste ligga till grund för jämförelsen. Använd GET Index Statistics eller ett motsvarande API i Azure SDK:erna för att hämta vektorstorlek.
Fråga ett kvantiserat vektorfält med hjälp av översampling
Frågesyntaxen för ett komprimerat eller kvantiserat vektorfält är samma som för icke-komprimerade vektorfält, såvida du inte vill åsidosätta parametrar som är associerade med översampling eller omrankning med ursprungliga vektorer.
Kom ihåg att vektorkomprimeringsdefinitionen i indexet har inställningar för och defaultOversampling
för rerankWithOriginalVectors
att minimera effekterna av ett mindre vektorindex. Du kan åsidosätta standardvärdena för att variera beteendet vid frågetillfället. Om defaultOversampling
det till exempel är 10.0 kan du ändra det till något annat i frågebegäran.
Du kan ange översamplingsparametern även om indexet inte uttryckligen har en rerankWithOriginalVectors
definition eller defaultOversampling
definition. Om du oversampling
anger vid frågetillfället åsidosätter indexinställningarna för den frågan och kör frågan med en effektiv rerankWithOriginalVectors
som true.
POST https://[service-name].search.windows.net/indexes/demo-index/docs/search?api-version=2024-07-01
Content-Type: application/json
api-key: [admin key]
{
"vectorQueries": [
{
"kind": "vector",
"vector": [8, 2, 3, 4, 3, 5, 2, 1],
"fields": "myvector",
"oversampling": 12.0,
"k": 5
}
]
}
Viktiga punkter:
Gäller för vektorfält som genomgår vektorkomprimering per tilldelning av vektorprofil.
Åsidosätter
defaultOversampling
värdet eller introducerar översampling vid frågetillfället, även om indexets komprimeringskonfiguration inte angav alternativ för översampling eller omrankning.