Dela via

Integrerat vektorarkiv i Azure DocumentDB

Använd den integrerade vektordatabasen i Azure DocumentDB för att sömlöst ansluta AI-baserade program till dina data som lagras i Azure DocumentDB. Den här integreringen kan omfatta appar som du har skapat med hjälp av Azure OpenAI-inbäddningar. Med den inbyggda integrerade vektordatabasen kan du effektivt lagra, indexeras och köra frågor mot högdimensionella vektordata som lagras direkt i Azure DocumentDB, tillsammans med de ursprungliga data som vektordata skapas från. Det eliminerar behovet av att överföra dina data till alternativa vektorlager och medför extra kostnader.

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) och DiskANN. 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 fråga vektorinbäddningar (listor med siffror) för dina data som du skapade med hjälp av en maskininlärningsmodell med hjälp av ett INBÄDDNINGS-API. Exempel på inbäddnings-API:er ä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 Azure DocumentDB kan du lagra, indexera och fråga inbäddningar tillsammans med de ursprungliga data. 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.

Användningsfall för vektordatabas

Vektordatabaser används inom många områden inom AI och dataanalys. De hjälper till med uppgifter som att förstå naturligt språk, känna igen bilder och videor, skapa rekommendationssystem och driva sökfunktioner. Du hittar dem i både analytiska AI- och generativa AI-program.

Du kan till exempel använda en vektordatabas för att:

  • Identifiera liknande bilder, dokument och låtar baserat på deras innehåll, teman, känslor och format.
  • Identifiera liknande produkter baserat på deras egenskaper, funktioner och användargrupper.
  • Rekommendera innehåll, produkter eller tjänster baserat på enskilda personers preferenser.
  • Rekommendera innehåll, produkter eller tjänster baserat på användargruppers likheter.
  • Identifiera de bästa möjliga alternativen från en stor pool med val för att uppfylla komplexa krav.
  • Identifiera dataavvikelser eller bedrägliga aktiviteter som skiljer sig från dominerande eller normala mönster.
  • Implementera beständigt minne för AI-agenter.
  • Aktivera hämtningsförhöjd generering (RAG).

Integrerad vektordatabas jämfört med ren vektordatabas

Det finns två vanliga typer av implementeringar av vektordatabaser: ren vektordatabas och integrerad vektordatabas i en NoSQL- eller relationsdatabas.

En ren vektordatabas lagrar och hanterar effektivt vektorbäddningar tillsammans med en liten mängd metadata. Den är separat från den datakälla som inbäddningarna härleds från.

En vektordatabas som integreras i en högpresterande NoSQL- eller relationsdatabas ger extra funktioner. Den integrerade vektordatabasen i en NoSQL- eller relationsdatabas kan lagra, indexera och fråga inbäddningar tillsammans med motsvarande ursprungliga data. Den här metoden eliminerar den extra kostnaden för att replikera data i en separat ren vektordatabas. Att hålla ihop vektorbäddningar och ursprungliga data underlättar dessutom flermodala dataåtgärder och ger bättre datakonsekvens, skalning och prestanda.

Vektordatabaser med öppen källkod

När utvecklare väljer vektordatabaser ger alternativen med öppen källkod många fördelar. Öppen källkod innebär att programvarans källkod är tillgänglig fritt, vilket gör det möjligt för användare att anpassa databasen efter deras specifika behov. Den här flexibiliteten är fördelaktig för organisationer som omfattas av unika regelkrav för data, till exempel företag inom finansbranschen.

En annan fördel med vektordatabaser med öppen källkod är det starka communitystöd de har. Aktiva användargrupper bidrar ofta till utvecklingen av dessa databaser, ger stöd och delar metodtips och främjar innovation.

Vissa individer väljer vektordatabaser med öppen källkod eftersom de är "kostnadsfria", vilket innebär att det inte kostar något att skaffa eller använda programvaran. Ett alternativ är att använda de kostnadsfria nivåer som erbjuds av hanterade vektordatabastjänster. Dessa hanterade tjänster ger inte bara kostnadsfri åtkomst upp till en viss användningsgräns, utan förenklar även driftbelastningen genom att hantera underhåll, uppdateringar och skalbarhet. Genom att använda den kostnadsfria nivån för hanterade vektordatabastjänster kan du därför uppnå kostnadsbesparingar samtidigt som du minskar hanteringskostnaderna. Med den här metoden kan du fokusera mer på dina kärnaktiviteter i stället för på databasadministration.

Välj den bästa vektordatabasen med öppen källkod

Att välja den bästa vektordatabasen med öppen källkod kräver att du överväger flera faktorer. Databasens prestanda och skalbarhet är avgörande eftersom de påverkar om databasen kan hantera dina specifika arbetsbelastningskrav. Databaser med effektiva indexerings- och frågefunktioner ger vanligtvis optimala prestanda. En annan faktor är communitysupporten och dokumentationen som är tillgänglig för databasen. En robust community och omfattande dokumentation kan ge värdefull hjälp. DocumentDB är till exempel en populär vektordatabas med öppen källkod:

Det mest populära alternativet kanske inte är det bästa alternativet för dig. Därför bör du jämföra olika alternativ baserat på funktioner, datatyper som stöds och kompatibilitet med befintliga verktyg och ramverk som du använder. Du bör också tänka på utmaningarna med vektordatabaser med öppen källkod.

Utmaningar med vektordatabaser med öppen källkod

De flesta vektordatabaser med öppen källkod, inklusive de som angavs tidigare, är rena vektordatabaser. Med andra ord är de utformade för att endast lagra och hantera inbäddningar av vektorer, tillsammans med en liten mängd metadata. Eftersom de fungerar separat från dina ursprungliga data måste du flytta data mellan olika tjänster. Den här komplexiteten medför extra kostnader, gör saker och ting mer komplexa och kan göra produktionssystemen långsammare.

De utgör också de utmaningar som är typiska för databaser med öppen källkod:

  • Installation: Du behöver djupgående kunskaper för att installera, konfigurera och använda databasen, särskilt för komplexa distributioner. För att optimera resurser och konfiguration vid uppskalning krävs noggrann övervakning och justeringar.
  • Underhåll: Du måste hantera dina egna uppdateringar, korrigeringar och underhåll. Maskininlärningsexpertis räcker inte. Du måste också ha omfattande erfarenhet av databasadministration.
  • Support: Det officiella stödet kan begränsas jämfört med hanterade tjänster och förlitar sig mer på hjälp från gemenskapen.

Även om det är kostnadsfritt till en början medför vektordatabaser med öppen källkod därför betydande kostnader vid uppskalning. Att utöka verksamheten kräver mer maskinvara, kompetent IT-personal och avancerad infrastrukturhantering, vilket leder till högre kostnader för maskinvara, personal och driftskostnader. Att skala vektordatabaser med öppen källkod kan vara ekonomiskt krävande trots bristen på licensavgifter.

Hantera utmaningarna med vektordatabaser med öppen källkod

En fullständigt hanterad vektordatabas som integreras i en högpresterande NoSQL- eller relationsdatabas undviker den extra kostnaden och komplexiteten för vektordatabaser med öppen källkod. En sådan databas lagrar, indexerar och frågar inbäddningar tillsammans med motsvarande ursprungliga data. Den här metoden eliminerar den extra kostnaden för att replikera data i en separat ren vektordatabas. Att hålla ihop vektorbäddningar och ursprungliga data underlättar dessutom flermodala dataåtgärder och ger bättre datakonsekvens, skalning och prestanda. Under tiden hjälper den fullständigt hanterade tjänsten utvecklare att undvika besväret med att konfigurera, underhålla och förlita sig på communityhjälp för en vektordatabas med öppen källkod. Dessutom erbjuder vissa hanterade vektordatabastjänster en kostnadsfri livstidsnivå.

Ett exempel är den integrerade vektordatabasen i Azure DocumentDB. Med den här konfigurationen kan utvecklare spara pengar på samma sätt som med vektordatabaser med öppen källkod. Men till skillnad från alternativ med öppen källkod tar tjänstleverantören hand om underhåll, uppdateringar och skalning åt dig. Uppgraderingen är snabb och enkel samtidigt som du behåller en låg total ägandekostnad (TCO) när det är dags att skala upp verksamheten. Du kan också använda den här tjänsten för att enkelt skala MongoDB-program som redan finns i produktion.

Azure DocumentDB tillhandahåller robusta vektorsökningsfunktioner så att du kan utföra sökningar med höghastighetslikhet i komplexa datamängder. För att utföra vektorsökning i Azure DocumentDB måste du först skapa ett vektorindex. Azure DocumentDB erbjuder flera alternativ, men här är några allmänna riktlinjer som hjälper dig att komma igång baserat på storleken på din datauppsättning:

IVF HNSW DiskANN (rekommenderas)
Beskrivning Ett IVFFlat-index delar in vektorer i listor och söker sedan efter en delmängd närmast frågevektorn. Ett HNSW-index skapar ett flerskiktsdiagram. DiskANN är en ungefärlig algoritm för närliggande sökning som är utformad för effektiv vektorsökning i valfri skala.
Viktiga kompromisser Proffsen: Snabbare byggtider, lägre minnesanvändning.
Nackdelar: Lägre frågeprestanda (när det gäller hastighetsåterkallningsavvägning).		 Fördelar: Bättre frågeprestanda (när det gäller avvägning mellan hastighet och återkallning) kan möjliggöras på en tom tabell.
Nackdelar: Långsammare byggtider, högre minnesanvändning.		 Fördelar: Effektiv i alla storlekar, hög återkallelse, högt dataflöde, låg svarstid.
Antal vektorer Under 10 000 Upp till 50 000 Upp till 500 000+
Rekommenderad klusternivå M10 eller M20 M30 och senare M30 och senare

Du kan använda DiskANN-index på M30- och högre nivåer. Om du vill skapa DiskANN-indexet anger du parametern "kind" enligt "vector-diskann" följande mall:

{ 
    "createIndexes": "<collection_name>",
    "indexes": [
        {
            "name": "<index_name>",
            "key": {
                "<path_to_property>": "cosmosSearch"
            },
            "cosmosSearchOptions": { 
                "kind": "vector-diskann", 
                "dimensions": <integer_value>,
                "similarity": <string_value>,
                "maxDegree" : <integer_value>, 
                "lBuild" : <integer_value>, 
            } 
        } 
    ] 
}
Fält Typ Description
index_name snöre Unikt namn på indexet.
path_to_property snöre Sökväg till egenskapen som innehåller vektorn. Den här sökvägen kan vara en egenskap på högsta nivån eller en pricknoteringssökväg till egenskapen. Vektorer måste vara en number[] som ska indexeras och användas i vektorsökningsresultat. En vektor som använder en annan typ, till exempel double[], förhindrar att dokumentet indexeras. Icke-indexerade dokument returneras inte i resultatet av en vektorsökning.
kind snöre Typ av vektorindex som ska skapas. Alternativen är vector-ivf, vector-hnswoch vector-diskann.
dimensions integer Antal dimensioner för vektorlikhet. DiskANN stöder upp till 16 000 dimensioner (med produktkvantisering), med framtida stöd planerat för 40 000+.
similarity snöre Likhetsmått att använda med indexet. Möjliga alternativ är COS (cosinusavstånd), L2 (Euklidiska avstånd) och IP (inre produkt).
maxDegree integer Maximalt antal kanter per nod i diagrammet. Den här parametern sträcker sig från 20 till 2048 (standardvärdet är 32). Högre maxDegree är lämpligt för datauppsättningar med höga krav på dimensionalitet och/eller hög noggrannhet.
lBuild integer Anger antalet kandidatgrannarna som utvärderas under indexkonstruktionen i DiskANN. Den här parametern, som sträcker sig från 10 till 500 (standardvärdet är 50), balanserar noggrannhet och beräkningskostnader: högre värden förbättrar indexkvaliteten och noggrannheten men ökar byggtiden

Utföra en vektorsökning med DiskANN

Om du vill utföra en vektorsökning använder du $search sammansättningens pipelinesteg och frågar med operatorn cosmosSearch . DiskANN möjliggör högpresterande sökningar i massiva datauppsättningar med valfri filtrering, till exempel geospatiala eller textbaserade filter.

{
  "$search": {
    "cosmosSearch": {
      "path": "<path_to_property>",
      "query": "<query_vector>",  
      "k": <num_results_to_return>,  
      "filter": {"$and": [
        { "<attribute_1>": { "$eq": <value> } },
        {"<location_attribute>": {"$geoWithin": {"$centerSphere":[[<longitude_integer_value>, <latitude_integer_value>], <radius>]}}}
      ]}
    }
  }
},
Fält Typ Description
lSearch integer Anger storleken på den dynamiska kandidatlistan för sökning. Standardvärdet är 40, med ett konfigurerbart intervall från 10 till 1 000. Att öka värdet förbättrar återkallandet, men kan minska sökhastigheten.
k integer Definierar antalet sökresultat som ska returneras. Värdet k måste vara mindre än eller lika med lSearch.

Exempel med ett DiskANN-index med filtrering

Lägga till vektorer i databasen

Om du vill använda vektorsökning med geospatiala filter lägger du till dokument som innehåller både vektorinbäddningar och platskoordinater. Du kan skapa inbäddningarna med hjälp av din egen modell, Azure OpenAI-inbäddningar eller ett API som Hugging Face på Azure.

from pymongo import MongoClient

client = MongoClient("<your_connection_string>")
db = client["test"]
collection = db["testCollection"]

documents = [
    {"name": "Eugenia Lopez", "bio": "CEO of AdventureWorks", "is_open": 1, "location": [-118.9865, 34.0145], "contentVector": [0.52, 0.20, 0.23]},
    {"name": "Cameron Baker", "bio": "CFO of AdventureWorks", "is_open": 1, "location": [-0.1278, 51.5074], "contentVector": [0.55, 0.89, 0.44]},
    {"name": "Jessie Irwin", "bio": "Director of Our Planet initiative", "is_open": 0, "location": [-118.9865, 33.9855], "contentVector": [0.13, 0.92, 0.85]},
    {"name": "Rory Nguyen", "bio": "President of Our Planet initiative", "is_open": 1, "location": [-119.0000, 33.9855], "contentVector": [0.91, 0.76, 0.83]}
]

collection.insert_many(documents)

Skapa ett DiskANN-vektorindex

I följande exempel visas hur du konfigurerar ett DiskANN-vektorindex med filtreringsfunktioner. Det här exemplet omfattar att skapa vektorindexet för likhetssökning, lägga till dokument med vektor- och geospatiala egenskaper och indexeringsfält för mer filtrering.

db.command({
    "createIndexes": "testCollection",
    "indexes": [
        {
            "name": "DiskANNVectorIndex",
            "key": {
                "contentVector": "cosmosSearch"
            },
            "cosmosSearchOptions": {
                "kind": "vector-diskann",
                "dimensions": 3,
                "similarity": "COS",
                "maxDegree": 32,
                "lBuild": 64
            }
        },
        { 
            "name": "is_open",
            "key": { 
                "is_open": 1 
            }      
        },
        {
            "name": "locationIndex",
            "key": {
                "location": 1
            }
        }
    ]
})

Det här kommandot skapar ett DiskANN-vektorindex på contentVector fältet i exampleCollection, vilket möjliggör likhetssökningar. Den lägger också till:

  • Ett index för fältet is_open så att du kan filtrera resultat baserat på om företag är öppna.
  • Ett geospatialt index på fältet location för att filtrera efter geografisk närhet.

Om du vill hitta dokument med liknande vektorer inom en specifik geografisk radie anger du queryVector för likhetssökning och inkluderar ett geospatialt filter.

query_vector = [0.52, 0.28, 0.12]
pipeline = [
    {
        "$search": {
            "cosmosSearch": {
                "path": "contentVector",
                "vector": query_vector,
                "k": 5,
                "filter": {
                    "$and": [
                        {"is_open": {"$eq": 1}},
                        {"location": {"$geoWithin": {"$centerSphere": [[-119.7192861804, 34.4102485028], 100 / 3963.2]}}}
                    ]
                }
            }
        }
    }
]

results = list(collection.aggregate(pipeline))
for result in results:
    print(result)

I det här exemplet returnerar vektorlikhetssökningen de översta k närmaste vektorerna baserat på det angivna COS likhetsmåttet, samtidigt som resultaten filtreras så att de endast omfattar öppna företag inom en radie på 100 mil.

[
  {
    similarityScore: 0.9745354109084544,
    document: {
      _id: ObjectId("645acb54413be5502badff94"),
      name: 'Eugenia Lopez',
      bio: 'CEO of AdventureWorks',
      is_open: 1,
      location: [-118.9865, 34.0145],
      contentVector: [0.52, 0.20, 0.23]
    }
  },
  {
    similarityScore: 0.9006955671333992,
    document: {
      _id: ObjectId("645acb54413be5502badff97"),
      name: 'Rory Nguyen',
      bio: 'President of Our Planet initiative',
      is_open: 1,
      location: [-119.7302, 34.4005],
      contentVector: [0.91, 0.76, 0.83]
    }
  }
]

Det här resultatet visar de vanligaste liknande dokumenten till queryVector– begränsade till en radie på 160 mil och öppna företag. Varje resultat innehåller likhetspoäng och metadata som visar hur DiskANN i Azure DocumentDB stöder kombinerade vektor- och geospatiala frågor för berikade, platskänsliga sökupplevelser.

Hämta definitioner för vektorindex

Om du vill hämta vektorindexdefinitionen från samlingen använder du listIndexes kommandot:

db.exampleCollection.getIndexes();

I det här exemplet vectorIndex returneras med alla cosmosSearch parametrar som användes för att skapa indexet:

[
  { v: 2, key: { _id: 1 }, name: '_id_', ns: 'test.exampleCollection' },
  {
    v: 2,
    key: { vectorContent: 'cosmosSearch' },
    name: 'vectorSearchIndex',
    cosmosSearch: {
      kind: <index_type>, // options are `vector-ivf`, `vector-hnsw`, and `vector-diskann`
      numLists: 3,
      similarity: 'COS',
      dimensions: 3
    },
    ns: 'test.exampleCollection'
  }
]

Nu kan du köra vektorsökningar med valfritt frågefilter som stöds, till exempel $lt, $lte, $eq, $neq$gte, $gt, $in, $ninoch $regex.

Om du vill använda förfiltrering måste du först definiera ett standardindex för den egenskap som du vill filtrera efter, utöver ditt vektorindex. Här är ett exempel på hur du skapar ett filterindex:

db.runCommand({
  "createIndexes": "<collection_name>",
  "indexes": [ {
    "key": {
      "<property_to_filter>": 1
    },
    "name": "<name_of_filter_index>"
  }
  ]
});

När filterindexet är på plats kan du lägga till "filter" satsen direkt i vektorsökningsfrågan. Det här exemplet visar hur du filtrerar resultat där "title" egenskapens värde inte finns i den angivna listan:

db.exampleCollection.aggregate([
  {
    '$search': {
      "cosmosSearch": {
        "vector": "<query_vector>",
        "path": <path_to_vector>,
        "k": num_results,
        "filter": {<property_to_filter>: {"$nin": ["not in this text", "or this text"]}}
      },
      "returnStoredSource": True }},
  {'$project': { 'similarityScore': { '$meta': 'searchScore' }, 'document' : '$$ROOT' }
}
]);

Viktigt!

Om du vill optimera prestanda och noggrannhet för dina förfiltrerade vektorsökningar bör du överväga att justera vektorindexparametrarna. För DiskANN-index kan det ge bättre resultat att öka maxDegree eller lBuild. För HNSW-index kan du experimentera med högre värden för m, efConstructioneller efSearch förbättra prestandan. På samma sätt, för IVF-index , justering numLists eller nProbes kan leda till mer tillfredsställande resultat. Det är viktigt att testa din specifika konfiguration med dina data för att säkerställa att resultaten uppfyller dina krav. Dessa parametrar påverkar indexstrukturen och sökbeteendet, och optimala värden kan variera beroende på dina dataegenskaper och frågemönster.

Använda orkestreringsverktyg för stor språkmodell (LLM)

Använda som vektordatabas med semantisk kernel

Använd semantisk kernel för att orkestrera din informationshämtning från Azure DocumentDB och din LLM. Mer information finns i GitHub-lagringsplatsen.

Använda som vektordatabas med LangChain

Använd LangChain för att samordna din informationshämtning från Azure DocumentDB och din LLM. Mer information finns i LangChain-integreringar för Azure DocumentDB.

Använda som en semantisk cache med LangChain

Använd LangChain och Azure DocumentDB för att orkestrera semantisk cachelagring med hjälp av tidigare inspelade LLM-svar som kan spara kostnader för LLM API och minska svarstiden. Mer information finns i LangChain-integrering med Azure DocumentDB.

Funktioner och begränsningar

  • Avståndsmått som stöds: L2 (Euklidiska), inre produkt och cosinus.
  • Indexeringsmetoder som stöds: IVFFLAT, HNSW och DiskANN.
  • Med DiskANN och produktkvantisering kan du indexisera vektorer upp till 16 000 dimensioner.
  • Om du använder HNSW eller IVF med halv precision kan du indexera vektorer upp till 4 000 dimensioner.
  • Utan komprimering är den maximala standardvektordimensionen för indexering 2 000.
  • Indexering gäller endast för en vektor per sökväg.
  • Du kan bara skapa ett index per vektorsökväg.

Sammanfattning

Den här guiden visar hur du skapar ett vektorindex, lägger till dokument som har vektordata, utför en likhetssökning och hämtar indexdefinitionen. Med hjälp av vår integrerade vektordatabas kan du effektivt lagra, indexeras och köra frågor mot högdimensionella vektordata direkt i Azure DocumentDB. Det gör att du kan frigöra den fulla potentialen för dina data via vektorbäddningar, och det ger dig möjlighet att skapa mer exakta, effektiva och kraftfulla program.

Relaterat innehåll

Nästa steg

Skapa ett livstidskluster på den kostnadsfria nivån för Azure DocumentDB

  • Last updated on