Bemærk
Adgang til denne side kræver godkendelse. Du kan prøve at logge på eller ændre mapper.
Adgang til denne side kræver godkendelse. Du kan prøve at ændre mapper.
Cosmos DB in Fabric tilbyder nu effektiv vektorindeksering og søgning. Denne funktion er designet til at håndtere multimodale, højdimensionelle vektorer, hvilket muliggør effektiv og nøjagtig vektorsøgning i alle skalaer. Du kan nu gemme vektorer direkte i dokumenterne sammen med dine data. Hvert dokument i databasen kan ikke kun indeholde traditionelle skemafrie data, men også multimodale højdimensionelle vektorer som andre egenskaber for dokumenterne. Denne colocation af data og vektorer muliggør effektiv indeksering og søgning, da vektorerne gemmes i den samme logiske enhed som de data, de repræsenterer. Hvis vektorer og data holdes samlet, forenkles datastyring, arkitekturer for AI-programmer og effektiviteten af vektorbaserede handlinger.
Cosmos DB i Fabric giver den fleksibilitet, den giver, når du vælger vektorindekseringsmetoden:
En "flad" eller k-nærmeste naboer nøjagtig søgning (også kaldet brute-force) kan give 100% hentning tilbagekaldelse for mindre, fokuseret vektor søgninger. især når de kombineres med forespørgselsfiltre og partitionsnøgler.
Et kvantiseret fladt indeks, der komprimerer vektorer ved hjælp af DiskANN-baserede kvantiseringsmetoder for at opnå bedre effektivitet i kNN-søgningen.
DiskANN, en pakke med avancerede vektorindekseringsalgoritmer, der er udviklet af Microsoft Research for at styrke effektiv og høj nøjagtighed af multimodal vektorsøgning i alle skalaer.
Vektorsøgning i Cosmos DB kan kombineres med alle andre understøttede NoSQL-forespørgselsfiltre og -indekser ved hjælp af WHERE delsætninger. Denne kombination gør det muligt for dine vektorsøgninger at være de mest relevante data for dine programmer.
Denne funktion forbedrer kernefunktionerne i Cosmos DB, hvilket gør den mere alsidig til håndtering af vektordata og søgekrav i AI-programmer.
Hvad er et vektorlager?
Et vektorlager eller en vektordatabase er en database, der er designet til at gemme og administrere vektorintegreringer, som er matematiske repræsentationer af data i et højdimensionalt rum. På dette område svarer hver dimension til en funktion i dataene, og titusinder af dimensioner kan bruges til at repræsentere avancerede data. En vektors placering i dette område repræsenterer dens egenskaber. Ord, udtryk eller hele dokumenter samt billeder, lyd og andre typer data kan alle vektoriseres.
Hvordan fungerer en vektorbutik?
I et vektorlager bruges vektorsøgealgoritmer til at indeksere og forespørge om integreringer. Nogle kendte vektorsøgealgoritmer omfatter Hierarkisk Navigable Small World (HNSW), Inverted File (IVF), DiskANN osv. Vektorsøgning er en metode, der hjælper dig med at finde lignende elementer, der er baseret på deres dataegenskaber i stedet for præcise match i et egenskabsfelt. Denne teknik er nyttig i programmer som f.eks. at søge efter lignende tekst, finde relaterede billeder, komme med anbefalinger eller endda registrere uregelmæssigheder. Den bruges til at forespørge vektor-embeddings af dine data, som du har skabt, ved hjælp af en maskinlæringsmodel ved hjælp af en embeddings-API. Eksempler på integrerings-API'er er Azure OpenAI Embeddings eller Hugging Face på Azure. Vektorsøgning måler afstanden mellem datavektorerne og forespørgselsvektoren. De datavektorer, der er tættest på din forespørgselsvektor, er dem, der viser sig at være mest ens semantisk.
I den integrerede vektordatabase i Cosmos DB i Fabric kan integreringer gemmes, indekseres og forespørges sammen med de oprindelige data. Denne fremgangsmåde fjerner de ekstra omkostninger ved replikering af data i en separat ren vektordatabase. Desuden holder denne arkitektur vektorintegreringerne og de oprindelige data samlet, hvilket bedre faciliterer flermodale datahandlinger og giver større datakonsistens, skalering og ydeevne.
Politikker for objektbeholdervektor
Hvis du udfører vektorsøgning med Cosmos DB i Fabric, skal du definere en vektorpolitik for objektbeholderen. Denne politik indeholder vigtige oplysninger, så databaseprogrammet kan udføre effektiv søgning efter vektorer, der findes i objektbeholderens dokumenter. Denne konfiguration informerer også politikken for vektorindeksering om nødvendige oplysninger, hvis du vælger at angive en. Følgende oplysninger er inkluderet i den indeholdte vektorpolitik:
path: den egenskab, der indeholder vektoren (påkrævet).datatype: datatypen for vektoregenskaben. Understøttede typer erfloat32(standard),int8oguint8.dimensions: Dimensionaliteten eller længden af hver vektor i stien. Alle vektorer i en sti skal have det samme antal dimensioner. (standard1536).distanceFunction: Den metrikværdi, der bruges til at beregne afstand/lighed. Understøttede målepunkter er:cosine, som har værdier fra $-1$ (mindst lignende) til $+1$ (mest lignende).dot product, som har værdier fra $-\infty$ (mindst lignende) til $+\infty$ (mest lignende).euclidean, som har værdier fra $0$ (mest lig) til $+\infty$ (mindst ens).
Note
Hver entydige sti kan højst have én politik. Der kan dog angives flere politikker, hvis de alle er rettet mod en anden sti.
Objektbeholderens vektorpolitik kan beskrives som JSON-objekter. Her er to eksempler på gyldige politikker for objektbeholdervektorer:
En politik med en enkelt vektorsti
{
"vectorEmbeddings": [
{
"path": "/vector1",
"dataType": "float32",
"distanceFunction": "cosine",
"dimensions": 1536
}
]
}
En politik med to vektorstier
{
"vectorEmbeddings": [
{
"path": "/vector1",
"dataType": "float32",
"distanceFunction": "cosine",
"dimensions": 1536
},
{
"path": "/vector2",
"dataType": "int8",
"distanceFunction": "dotproduct",
"dimensions": 100
}
]
}
Du kan få flere oplysninger og eksempler på indstillinger for en objektbeholdervektorpolitik i eksempler på vektorindekseringspolitik.
Politikker for vektorindeksering
Vektorindekser øger effektiviteten, når du udfører vektorsøgninger ved hjælp af systemfunktionen VectorDistance . Vektorsøgninger har lavere ventetid, højere gennemløb og mindre ru-forbrug, når der bruges et vektorindeks. Du kan angive disse typer vektorindekspolitikker:
| Description | Maksimale dimensioner | |
|---|---|---|
flat |
Gemmer vektorer på det samme indeks som andre indekserede egenskaber. | 505 |
quantizedFlat |
Kvantizes (komprimerer) vektorer, før de gemmes på indekset. Denne politik kan forbedre ventetiden og dataoverførselshastigheden på bekostning af en lille mængde nøjagtighed. | 4096 |
diskANN |
Opretter et indeks, der er baseret på DiskANN, til hurtig og effektiv omtrentlig søgning. | 4096 |
Note
Og quantizedFlat indeksene diskANN kræver, at mindst 1.000 vektorer indsættes. Dette minimum er for at sikre nøjagtigheden af kvantiseringsprocessen. Hvis der er færre end 1.000 vektorer, udføres der i stedet en fuld scanning, og det medfører højere gebyrer for en vektorsøgningsforespørgsel.
Der er et par punkter, du skal være opmærksom på:
Indekstyperne
flatogquantizedFlatbruger Cosmos DB's indeks til at gemme og læse hver vektor under en vektorsøgning. Vektorsøgninger med etflatindeks er brutale søgninger og giver 100% nøjagtighed eller genkaldelse. Det vil altså være en garanti for, at de finder de mest lignende vektorer i datasættet. Der findes dog en begrænsning af505dimensioner for vektorer på et fladt indeks.Indekset
quantizedFlatgemmer de kvantiserede (komprimerede) vektorer i indekset. Vektorsøgninger medquantizedFlatindeks er også brutale søgninger, men deres nøjagtighed kan være lidt mindre end 100% da vektorerne kvantiseres, før de føjes til indekset. Vektorsøgninger medquantized flatskal dog have lavere ventetid, højere gennemløb og lavere omkostninger for jernbanevirksomhed end vektorsøgninger på etflatindeks. Dette indeks er en god mulighed for mindre scenarier eller scenarier, hvor du bruger forespørgselsfiltre til at indsnævre vektorsøgningen til et relativt lille sæt vektorer.quantizedFlatanbefales, når antallet af vektorer, der skal indekseres, er omkring 50.000 eller færre pr. fysisk partition. Denne anbefaling er dog blot en generel retningslinje, og den faktiske ydeevne skal testes, da hvert scenarie kan være forskelligt.Indekset
diskANNer et separat indeks defineret specifikt for vektorer ved brug af DiskANN, en suite af højtydende vektorindekseringsalgoritmer udviklet af Microsoft Research. DiskANN-indekser kan tilbyde nogle af de laveste ventetider, højeste gennemløb og de laveste forespørgsler om RU-omkostninger, samtidig med at den høje nøjagtighed bevares. DiskANN er generelt den mest højtydende af alle indekstyper, hvis der er mere end 50.000 vektorer pr. fysisk partition.
Her er eksempler på gyldige vektorindekspolitikker:
{
"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"
}
]
}
Important
Den vektorsti, excludedPaths der er føjet til sektionen i indekseringspolitikken for at sikre optimeret ydeevne til indsættelse. Hvis vektorstien ikke tilføjes, excludedPaths medfører det højere enhedsgebyr og ventetid for vektorindsætninger.
Important
Jokertegn (*, []) understøttes ikke i øjeblikket i vektorpolitikken eller vektorindekset.
Udfør vektorsøgning med forespørgsler ved hjælp af VECTORDISTANCE
Når du har oprettet en objektbeholder med den ønskede vektorpolitik og indsat vektordata i objektbeholderen, kan du udføre en vektorsøgning ved hjælp af den indbyggede VECTORDISTANCE funktion i en forespørgsel. Et eksempel på en NoSQL-forespørgsel, der projekterer lighedsscoren som aliasset scoreog sorterer i rækkefølge, der ligner mindst ens:
SELECT TOP 10
c.title,
VECTORDISTANCE(c.contentVector, [1,2,3]) AS score
FROM
container c
ORDER BY
VECTORDISTANCE(c.contentVector, [1,2,3])
Important
Brug altid en TOP N delsætning i sætningen SELECT i en forespørgsel. Ellers forsøger vektorsøgningen at returnere mange flere resultater, hvilket medfører, at forespørgslen koster flere anmodningsenheder og har en højere ventetid end nødvendigt.