Not
Åtkomst till den här sidan kräver auktorisering. Du kan prova att logga in eller ändra kataloger.
Åtkomst till den här sidan kräver auktorisering. Du kan prova att ändra kataloger.
Cosmos DB i Fabric erbjuder nu effektiv vektorindexering och sökning. Den här funktionen är utformad för att hantera flermodala, högdimensionella vektorer, vilket möjliggör effektiv och korrekt vektorsökning i valfri skala. Nu kan du lagra vektorer direkt i dokumenten tillsammans med dina data. Varje dokument i databasen kan inte bara innehålla traditionella schemafria data, utan även flermodala högdimensionella vektorer som andra egenskaper för dokumenten. Den här samlokaliseringen av data och vektorer möjliggör effektiv indexering och sökning, eftersom vektorerna lagras i samma logiska enhet som de data de representerar. Att hålla ihop vektorer och data förenklar datahantering, AI-programarkitekturer och effektiviteten för vektorbaserade åtgärder.
Cosmos DB i Fabric erbjuder den flexibilitet som erbjuds när du väljer vektorindexeringsmetod:
En "flat" eller k-närmaste grannars exakt sökning (som ibland kallas brute-force) kan ge 100% återkallning för mindre, fokuserade vektorsökningar. särskilt när de kombineras med frågefilter och partitionsnycklar.
Ett kvantiserat platt index som komprimerar vektorer med hjälp av DiskANN-baserade kvantiseringsmetoder för bättre effektivitet i kNN-sökningen.
DiskANN, en uppsättning toppmoderna vektorindexeringsalgoritmer som utvecklats av Microsoft Research för att ge effektiv sökning med flera modala vektorer med hög noggrannhet i alla storlekar.
Vektorsökning i Cosmos DB kan kombineras med alla andra NoSQL-frågefilter och -index som stöds med hjälp av WHERE satser. Med den här kombinationen kan dina vektorsökningar vara de mest relevanta data för dina program.
Den här funktionen förbättrar kärnfunktionerna i Cosmos DB, vilket gör den mer mångsidig för hantering av vektordata och sökkrav i AI-program.
Vad är en vektorbutik?
Ett vektorlager eller en vektordatabas är en databas som är utformad för att lagra och hantera inbäddningar av vektorer, som är matematiska representationer av data i ett högdimensionellt utrymme. I det här utrymmet motsvarar varje dimension en funktion i data och tiotusentals dimensioner kan användas för att representera avancerade data. En vektors position i det här utrymmet representerar dess egenskaper. Ord, fraser eller hela dokument och bilder, ljud och andra typer av data kan alla vektoriseras.
Hur fungerar ett vektorlager?
I ett vektorlager används algoritmer för vektorsökning för att indexera och fråga inbäddningar. Några välkända vektorsökningsalgoritmer är HNSW (Hierarchical Navigable Small World), Inverted File (IVF), DiskANN osv. Vektorsökning är en metod som hjälper dig att hitta liknande objekt baserat på deras dataegenskaper i stället för exakta matchningar i ett egenskapsfält. Den här tekniken är användbar i program som att söka efter liknande text, hitta relaterade bilder, göra rekommendationer eller till och med identifiera avvikelser. Den används för att köra frågor mot vektorinbäddningar av dina data som du skapade med hjälp av en maskininlärningsmodell med hjälp av ett inbäddnings-API. Exempel på API:er för inbäddningar är Azure OpenAI-inbäddningar eller Hugging Face på Azure. Vektorsökning mäter avståndet mellan datavektorerna och frågevektorn. De datavektorer som är närmast din frågevektor är de som är mest lika semantiskt.
I den integrerade vektordatabasen i Cosmos DB i Fabric kan inbäddningar lagras, indexeras och efterfrågas tillsammans med den ursprungliga datan. Den här metoden eliminerar den extra kostnaden för att replikera data i en separat ren vektordatabas. Dessutom håller den här arkitekturen samman vektorbäddningar och ursprungliga data, vilket bättre underlättar multimodala dataåtgärder och ger bättre datakonsekvens, skalning och prestanda.
Policys för containervektorer
Om du utför vektorsökning med Cosmos DB i Fabric måste du definiera en vektorprincip för containern. Den här principen innehåller viktig information för databasmotorn för att utföra effektiv likhetssökning efter vektorer som finns i containerns dokument. Den här konfigurationen informerar också vektorindexeringsprincipen om nödvändig information om du väljer att ange en. Följande information ingår i policyn för inneslutna vektorer:
path: egenskapen som innehåller vektorn (krävs).datatype: datatypen för vektoregenskapen. Typer som stöds ärfloat32(standard),int8, ochuint8.dimensions: Dimensionaliteten eller längden på varje vektor i sökvägen. Alla vektorer i en sökväg bör ha samma antal dimensioner. (förval1536).distanceFunction: Måttet som används för att beräkna avstånd/likhet. Mått som stöds är:cosine, som har värden från $-1$ (minst liknande) till $+1$ (mest liknande).dot product, som har värden från $-\infty$ (minst liknande) till $+\infty$ (mest liknande).euclidean, som har värden från $0$ (mest liknande) till $+\infty$ (minst liknande).
Anmärkning
Varje unik sökväg kan ha högst en princip. Flera policyer kan dock anges om de alla riktar sig mot olika sökvägar.
Containervektorprincipen kan beskrivas som JSON-objekt. Här är två exempel på giltiga principer för containervektorer:
En princip med en enda vektorsökväg
{
"vectorEmbeddings": [
{
"path": "/vector1",
"dataType": "float32",
"distanceFunction": "cosine",
"dimensions": 1536
}
]
}
En princip med två vektorsökvägar
{
"vectorEmbeddings": [
{
"path": "/vector1",
"dataType": "float32",
"distanceFunction": "cosine",
"dimensions": 1536
},
{
"path": "/vector2",
"dataType": "int8",
"distanceFunction": "dotproduct",
"dimensions": 100
}
]
}
Mer information och exempel på inställningar för en containervektorprincip finns i principexempel för vektorindexering.
Principer för vektorindexering
Vektorindex ökar effektiviteten när du utför vektorsökningar med hjälp av VectorDistance systemfunktionen. Vektorsökningar har lägre svarstid, högre dataflöde och mindre RU-förbrukning när du använder ett vektorindex. Du kan ange följande typer av principer för vektorindex:
| Beskrivning | Maximala dimensioner | |
|---|---|---|
flat |
Lagrar vektorer i samma index som andra indexerade egenskaper. | 505 |
quantizedFlat |
Kvantifierar (komprimerar) vektorer innan de lagras i indexet. Den här principen kan förbättra svarstiden och dataflödet på bekostnad av en liten mängd noggrannhet. | 4096 |
diskANN |
Skapar ett index baserat på DiskANN för snabb och effektiv ungefärlig sökning. | 4096 |
Anmärkning
Indexen quantizedFlat och diskANN kräver att minst 1 000 vektorer infogas . Det här minimumet är att säkerställa kvantiseringsprocessens noggrannhet. Om det finns färre än 1 000 vektorer körs en fullständig genomsökning i stället och leder till högre RU-avgifter för en vektorsökningsfråga.
Några punkter att notera:
Indextyperna
flatochquantizedFlatanvänder Cosmos DB:s index för att lagra och läsa varje vektor under en vektorsökning. Vektorsökningar med ettflat-index är brute force-sökningar och ger 100 % noggrannhet och återkallning. De kommer alltså garanterat att hitta de mest liknande vektorerna i datamängden. Det finns dock en begränsning av505dimensioner för vektorer i ett platt index.Indexet
quantizedFlatlagrar kvantiserade (komprimerade) vektorer i indexet. Vektorsökningar medquantizedFlatindex är också råstyrkesökningar, men deras noggrannhet kan vara något mindre än 100 % eftersom vektorerna kvantifieras innan de läggs till i indexet. Vektorsökningar medquantized flatbör dock ha lägre svarstid, högre dataflöde och lägre RU-kostnad än vektorsökningar i ettflatindex. Det här indexet är ett bra alternativ för mindre scenarier eller scenarier där du använder frågefilter för att begränsa vektorsökningen till en relativt liten uppsättning vektorer.quantizedFlatrekommenderas när antalet vektorer som ska indexeras är någonstans runt 50 000 eller färre per fysisk partition. Den här rekommendationen är dock bara en allmän riktlinje och den faktiska prestandan bör testas eftersom varje scenario kan skilja sig åt.Indexet
diskANNär ett separat index som definierats specifikt för vektorer som använder DiskANN, en uppsättning vektorindexeringsalgoritmer med höga prestanda som utvecklats av Microsoft Research. DiskANN-index kan erbjuda några av de lägsta svarstiderna, det högsta dataflödet och de lägsta RU-kostnadsfrågorna, samtidigt som hög noggrannhet bibehålls. I allmänhet är DiskANN den mest högpresterande av alla indextyper om det finns fler än 50 000 vektorer per fysisk partition.
Här är exempel på giltiga principer för vektorindex:
{
"indexingMode": "consistent",
"automatic": true,
"includedPaths": [
{
"path": "/*"
}
],
"excludedPaths": [
{
"path": "/_etag/?"
},
{
"path": "/vector1/*"
}
],
"vectorIndexes": [
{
"path": "/vector1",
"type": "diskANN"
}
]
}
{
"indexingMode": "consistent",
"automatic": true,
"includedPaths": [
{
"path": "/*"
}
],
"excludedPaths": [
{
"path": "/_etag/?"
},
{
"path": "/vector1/*",
},
{
"path": "/vector2/*",
}
],
"vectorIndexes": [
{
"path": "/vector1",
"type": "quantizedFlat"
},
{
"path": "/vector2",
"type": "diskANN"
}
]
}
Viktigt!
Vektorsökvägen har lagts till i excludedPaths avsnittet i indexeringsprincipen för att säkerställa optimerad prestanda för infogning. Att inte lägga till vektorsökvägen till excludedPaths resulterar i högre kostnad för förfrågningsenhet och fördröjningstid för vektorinfogningar.
Viktigt!
Jokertecken (*, []) stöds för närvarande inte i vektorprincipen eller vektorindexet.
Utföra vektorsökning med frågor med hjälp av VECTORDISTANCE
När du har skapat en container med önskad vektorprincip och infogat vektordata i containern kan du utföra en vektorsökning med hjälp av den inbyggda VECTORDISTANCE funktionen i en fråga. Ett exempel på en NoSQL-fråga som projicerar likhetspoängen som alias scoreoch sorterar i den ordning som mest liknar minst lika:
SELECT TOP 10
c.title,
VECTORDISTANCE(c.contentVector, [1,2,3]) AS score
FROM
container c
ORDER BY
VECTORDISTANCE(c.contentVector, [1,2,3])
Viktigt!
Använd alltid en TOP N villkor i SELECT uttrycket för en fråga. Annars försöker vektorsökningen returnera många fler resultat, vilket gör att frågan kostar fler enheter för begäranden (RU:er) och har högre svarstid än nödvändigt.