Del via


Vektordatabaser

En vektordatabase lagrer og behandler data i form av vektorer, som er numeriske matriser med datapunkter.

Bruken av vektorer gjør det mulig for komplekse spørringer og analyser, fordi vektorer kan sammenlignes og analyseres ved hjelp av avanserte teknikker som vektorlikhetssøk, kvantisering og klynger. Tradisjonelle databaser er ikke godt egnet for håndtering av de høydimensjonale dataene som blir stadig vanligere i dataanalyse. Vektordatabaser er imidlertid utformet for å håndtere høydimensjonale data, for eksempel tekst, bilder og lyd, ved å representere dem som vektorer. Vektordatabaser er nyttige for oppgaver som maskinlæring, behandling av naturlig språk og bildegjenkjenning, der målet er å identifisere mønstre eller likheter i store datasett.

Denne artikkelen gir litt bakgrunn om vektordatabaser og forklarer begrepsmessig hvordan du kan bruke et Eventhouse som vektordatabase i Sanntidsintelligens i Microsoft Fabric. Hvis du vil ha et praktisk eksempel, kan du se Opplæring: Bruke et eventhouse som vektordatabase.

Nøkkelkonsepter

Følgende nøkkelkonsepter brukes i vektordatabaser:

Vektor likhet

Vektorlikhet er et mål på hvor forskjellige (eller lignende) to eller flere vektorer er. Vektor-likhetssøk er en teknikk som brukes til å finne lignende vektorer i et datasett. Vektorer sammenlignes ved hjelp av en avstandsmåling, for eksempel euklidisk avstand eller cosinuslikitet. Jo nærmere to vektorer er, jo mer lik er de.

Innebygginger

Innebygging er en vanlig måte å representere data på i et vektorformat for bruk i vektordatabaser. En innebygging er en matematisk representasjon av et stykke data, for eksempel et ord, et tekstdokument eller et bilde, som er utformet for å fange opp den semantiske betydningen. Innebygginger opprettes ved hjelp av algoritmer som analyserer dataene og genererer et sett med numeriske verdier som representerer nøkkelfunksjonene. En innebygging for et ord kan for eksempel representere betydningen, konteksten og relasjonen til andre ord. Prosessen med å opprette innebygginger er enkel. Selv om de kan opprettes ved hjelp av standard python-pakker (for eksempel spaCy, sent2vec, Gensim), genererer Store språkmodeller (LLM) innebygginger av høyeste kvalitet for semantisk tekstsøk. Du kan for eksempel sende tekst til en innebyggingsmodell i Azure OpenAI, og den genererer en vektorrepresentasjon som kan lagres for analyse. Hvis du vil ha mer informasjon, kan du se Forstå innebygginger i Azure OpenAI-tjenesten.

Generell arbeidsflyt

Skjema for hvordan du bygger inn, lagrer og spør tekst som er lagret som vektorer.

Den generelle arbeidsflyten for bruk av en vektordatabase er som følger:

  1. Bygg inn data: Konverter data til vektorformat ved hjelp av en innebyggingsmodell. Du kan for eksempel bygge inn tekstdata ved hjelp av en OpenAI-modell.
  2. Lagre vektorer: Lagre de innebygde vektorene i en vektordatabase. Du kan sende de innebygde dataene til et Eventhouse for å lagre og administrere vektorene.
  3. Innebyggingsspørring: Konverter spørringsdataene til vektorformat ved hjelp av samme innebyggingsmodell som brukes til å bygge inn de lagrede dataene.
  4. Spørringsvektorer: Bruk vektor-likhetssøk til å finne oppføringer i databasen som ligner på spørringen.

Eventhouse som vektordatabase

Kjernen i Vector Similarity Search er muligheten til å lagre, indeksere og spørre vektordata. Eventhouses gir en løsning for håndtering og analyse av store mengder data, spesielt i scenarioer som krever analyse og utforskning i sanntid, noe som gjør det til et utmerket valg for lagring og søking av vektorer.

Følgende komponenter for aktiver bruken av Eventhouse en vektordatabase:

  • Den dynamiske datatypen, som kan lagre ustrukturerte data, for eksempel matriser og egenskapsposer. Datatypen anbefales derfor for lagring av vektorverdier. Du kan øke vektorverdien ytterligere ved å lagre metadata relatert til det opprinnelige objektet som separate kolonner i tabellen.
  • Kodingstypen Vector16 som er utformet for lagring av vektorer av flyttall i 16-biters presisjon, som bruker Bfloat16 i stedet for standard 64-biters. Denne kodingen anbefales for lagring av ML-vektorinnbygginger, da den reduserer lagringskravene med en faktor på fire og akselererer vektorbehandlingsfunksjoner som series_dot_product() og series_cosine_similarity() etter størrelsesstørrelse.
  • Funksjonen series_cosine_similarity , som kan utføre vektor-likhetssøk oppå vektorene som er lagret i Eventhouse.

Optimaliser for skalering

Hvis du vil ha mer informasjon om hvordan du optimaliserer vektor-likhetssøk, kan du lese bloggen.

Følg følgende fremgangsmåte for å maksimere ytelsen og de resulterende søketidene:

  1. Angi kodingen av innebyggingskolonnen til Vektctor16, 16-biters koding av vektorkoeffisientene (i stedet for standard 64-biters).
  2. Lagre tabellen for innebyggingsvektorer på alle klyngenoder med minst én skår per prosessor, som utføres av følgende trinn:
    1. Begrens antall innbyggingsvektorer per skår ved å endre ShardEngineMaxRowCount for skåringspolicyen. Hardingspolicyen balanserer data på alle noder med flere omfang per node, slik at søket kan bruke alle tilgjengelige prosessorer.
    2. Endre RowCountUpperBoundForMerge for sammenslåingspolicyen. Flettepolicyen er nødvendig for å undertrykke sammenslåingsgrader etter inntak.

Eksempel på optimaliseringstrinn

I eksemplet nedenfor er en statisk vektortabell definert for lagring av 1M-vektorer. Innebyggingspolicyen er definert som Vektctor16, og policyene for harding og fletting er satt til å optimalisere tabellen for vektorantallssøk. La oss anta at klyngen har 20 noder hver har 16 prosessorer. Tabellens skår bør inneholde maksimalt 1000000/(20*16)=3125 rader.

  1. Følgende KQL-kommandoer kjøres én etter én for å opprette den tomme tabellen og angi de nødvendige policyene og kodingen:

    .create table embedding_vectors(vector_id:long, vector:dynamic)                                  //  This is a sample selection of columns, you can add more columns
    
    .alter column embedding_vectors.vector policy encoding type = 'Vector16'                         // Store the coefficients in 16 bits instead of 64 bits accelerating calculation of dot product, suppress redundant indexing
    
    .alter-merge table embedding_vectors policy sharding '{ "ShardEngineMaxRowCount" : 3125 }'       // Balanced data on all nodes and, multiple extents per node so the search can use all processors 
    
    .alter-merge table embedding_vectors policy merge '{ "RowCountUpperBoundForMerge" : 3125 }'      // Suppress merging extents after ingestion
    
  2. Inntak av dataene til tabellen som ble opprettet og definert i forrige trinn.

Neste trinn