Udostępnij za pomocą


Zintegrowany magazyn wektorów w usłudze Azure DocumentDB

Użyj zintegrowanej bazy danych wektorów w usłudze Azure DocumentDB, aby bezproblemowo połączyć aplikacje oparte na sztucznej inteligencji z danymi przechowywanymi w usłudze Azure DocumentDB. Ta integracja może obejmować aplikacje utworzone przy użyciu osadzania usługi Azure OpenAI. Natywnie zintegrowana baza danych wektorów umożliwia efektywne przechowywanie, indeksowanie i wykonywanie zapytań względem danych wektorów o wysokim wymiarach przechowywanych bezpośrednio w usłudze Azure DocumentDB wraz z oryginalnymi danymi, z których są tworzone dane wektorowe. Eliminuje to konieczność transferu danych do alternatywnych magazynów wektorów i ponoszenia dodatkowych kosztów.

Co to jest magazyn wektorów?

Magazyn wektorów lub baza danych wektorów to baza danych przeznaczona do przechowywania osadzeń wektorów i zarządzania nimi, które są matematycznymi reprezentacjami danych w przestrzeni wielowymiarowej. W tej przestrzeni każdy wymiar odpowiada funkcji danych, a dziesiątki tysięcy wymiarów może służyć do reprezentowania zaawansowanych danych. Położenie wektora w tym obszarze reprezentuje jego cechy. Wyrazy, frazy lub całe dokumenty oraz obrazy, dźwięk i inne typy danych mogą być wektoryzowane.

Jak działa magazyn wektorów?

W magazynie wektorów algorytmy wyszukiwania wektorowego są używane do indeksowania i osadzania zapytań. Niektóre dobrze znane algorytmy wyszukiwania wektorów to Hierarchical Navigable Small World (HNSW), Inverted File (IVF) i DiskANN. Wyszukiwanie wektorowe to metoda, która ułatwia znajdowanie podobnych elementów na podstawie ich cech danych, a nie dokładnych dopasowań w polu właściwości. Ta technika jest przydatna w aplikacjach, takich jak wyszukiwanie podobnego tekstu, znajdowanie powiązanych obrazów, tworzenie zaleceń, a nawet wykrywanie anomalii. Służy do wykonywania zapytań dotyczących osadzeń wektorowych (list liczb) danych, które zostały utworzone za pomocą modelu uczenia maszynowego przy wykorzystaniu interfejsu API do osadzeń. Przykłady osadzania interfejsów API to osadzanie w usłudze Azure OpenAI lub przytulanie twarzy na platformie Azure. Wyszukiwanie wektorowe mierzy odległość między wektorami danych a wektorem zapytania. Wektory danych, które znajdują się najbliżej wektora zapytania, to te, które są najbardziej podobne semantycznie.

W zintegrowanej bazie danych wektorów w usłudze Azure DocumentDB można przechowywać, indeksować i wykonywać zapytania dotyczące osadzeń wraz z oryginalnymi danymi. Takie podejście eliminuje dodatkowy koszt replikowania danych w oddzielnej czystej bazie danych wektorów. Ponadto ta architektura przechowuje wektorowe osadzania i oryginalne dane razem, co usprawnia operacje na danych wielomodalnych i zapewnia większą spójność danych, skalę i wydajność.

Przypadki użycia bazy danych wektorów

Wektorowe bazy danych są używane w wielu obszarach sztucznej inteligencji i analizy danych. Pomagają one w zadaniach, takich jak zrozumienie języka naturalnego, rozpoznawanie obrazów i filmów wideo, tworzenie systemów rekomendacji i włączanie funkcji wyszukiwania. Można je znaleźć zarówno w analitycznych aplikacjach sztucznej inteligencji, jak i w aplikacjach generacyjnych sztucznej inteligencji.

Na przykład można użyć wektorowej bazy danych do:

  • Identyfikowanie podobnych obrazów, dokumentów i piosenek na podstawie ich zawartości, motywów, tonacji i stylów.
  • Zidentyfikuj podobne produkty na podstawie ich cech, funkcji i grup użytkowników.
  • Zalecanie zawartości, produktów lub usług na podstawie preferencji poszczególnych osób.
  • Zalecanie zawartości, produktów lub usług na podstawie podobieństw grup użytkowników.
  • Zidentyfikuj najlepsze możliwe opcje z dużej puli wyborów, aby spełnić złożone wymagania.
  • Identyfikowanie anomalii danych lub fałszywych działań, które różnią się od dominujących lub normalnych wzorców.
  • Zaimplementuj pamięć trwałą dla agentów sztucznej inteligencji.
  • Włącz generowanie wspomagane pozyskiwaniem (RAG).

Zintegrowana baza danych wektorów a czysta baza danych wektorów

Istnieją dwa typowe typy implementacji wektorowej bazy danych: czysta wektorowa baza danych i zintegrowana baza danych wektorów w bazie danych NoSQL lub relacyjnej bazie danych.

Czysta wektorowa baza danych efektywnie przechowuje osadzanie wektorów i zarządza nimi wraz z niewielką ilością metadanych. Jest to oddzielone od źródła danych, z którego pochodzą osadzenia.

Baza danych wektorów zintegrowana z wysoce wydajnym bazą danych NoSQL lub relacyjnymi bazami danych zapewnia dodatkowe możliwości. Zintegrowana baza danych wektorów w bazie danych NoSQL lub relacyjnej może przechowywać, indeksować i przetwarzać zapytania dotyczące osadzeń wraz z odpowiadającymi im oryginalnymi danymi. Takie podejście eliminuje dodatkowy koszt replikowania danych w oddzielnej czystej bazie danych wektorów. Ponadto utrzymywanie wektorowych osadzeń i oryginalnych danych lepiej ułatwia operacje na danych wielomodalnych i zapewnia większą spójność danych, skalę i wydajność.

Bazy danych wektorów typu open source

Gdy deweloperzy wybierają wektorowe bazy danych, opcje typu open source zapewniają wiele korzyści. Open source oznacza, że kod źródłowy oprogramowania jest dostępny bezpłatnie, umożliwiając użytkownikom dostosowywanie bazy danych zgodnie z ich konkretnymi potrzebami. Ta elastyczność jest korzystna dla organizacji, które podlegają unikatowym wymaganiom prawnym dla danych, takich jak firmy w branży usług finansowych.

Kolejną zaletą baz danych wektorów open source jest silna obsługa społeczności, z której korzystają. Aktywne społeczności użytkowników często przyczyniają się do rozwoju tych baz danych, zapewniają pomoc techniczną i udostępniają najlepsze rozwiązania, promując innowacje.

Niektóre osoby decydują się na bazy danych wektorów typu open source, ponieważ są "bezpłatne", co oznacza, że nie ma kosztów nabycia ani używania oprogramowania. Alternatywą jest użycie warstw bezpłatnych oferowanych przez usługi zarządzanej bazy danych wektorów. Te usługi zarządzane zapewniają nie tylko bezpłatny dostęp do określonego limitu użycia, ale także upraszczają obciążenie operacyjne dzięki obsłudze konserwacji, aktualizacji i skalowalności. W związku z tym korzystając z darmowej warstwy zarządzanych usług bazy danych wektorowych, można uzyskać oszczędności kosztów przy jednoczesnym zmniejszeniu obciążenia zarządzania. Takie podejście pozwala skupić się bardziej na podstawowych działaniach, a nie na administrowaniu bazami danych.

Wybieranie najlepszej bazy danych wektorów open source

Wybór najlepszej bazy danych wektorów open source wymaga rozważenia kilku czynników. Wydajność i skalowalność bazy danych mają kluczowe znaczenie, ponieważ mają wpływ na to, czy baza danych może obsługiwać określone wymagania dotyczące obciążenia. Bazy danych z wydajnymi możliwościami indeksowania i wykonywania zapytań zwykle oferują optymalną wydajność. Innym czynnikiem jest pomoc techniczna społeczności i dokumentacja dostępna dla bazy danych. Niezawodna społeczność i duża dokumentacja mogą zapewnić cenną pomoc. Na przykład usługa DocumentDB jest popularną bazą danych wektorów typu open source:

Najbardziej popularna opcja może nie być najlepszą opcją dla Ciebie. W związku z tym należy porównać różne opcje na podstawie funkcji, obsługiwanych typów danych i zgodności z istniejącymi narzędziami i platformami, których używasz. Należy również pamiętać o wyzwaniach związanych z bazami danych wektorów open source.

Wyzwania związane z bazami danych wektorów open source

Większość baz danych wektorów open source, w tym wymienionych wcześniej, to czyste bazy danych wektorów. Innymi słowy, są one przeznaczone do przechowywania tylko osadzania wektorów i zarządzania nimi wraz z niewielką ilością metadanych. Ponieważ działają one oddzielnie od oryginalnych danych, musisz przenieść dane między różnymi usługami. Ta złożoność zwiększa dodatkowe koszty, sprawia, że elementy są bardziej złożone i mogą spowalniać systemy produkcyjne.

Stanowią one również wyzwania typowe dla baz danych typu open source:

  • Konfiguracja: potrzebna jest szczegółowa wiedza na temat instalowania, konfigurowania i obsługi bazy danych, szczególnie w przypadku złożonych wdrożeń. Optymalizacja zasobów i konfiguracji podczas operacji skalowania w górę wymaga ścisłego monitorowania i korekt.
  • Konserwacja: musisz zarządzać własnymi aktualizacjami, poprawkami i konserwacją. Wiedza na temat uczenia maszynowego nie wystarczy; Musisz również mieć duże doświadczenie w administrowaniu bazą danych.
  • Pomoc techniczna: Oficjalna pomoc techniczna może być ograniczona w porównaniu z usługami zarządzanymi, opierając się bardziej na pomocy społeczności.

W związku z tym, podczas gdy początkowo bezpłatne, bazy danych wektorów typu open source generują znaczne koszty podczas skalowania. Rozszerzanie operacji wymaga większej ilości sprzętu, wykwalifikowanych pracowników IT i zaawansowanego zarządzania infrastrukturą, co prowadzi do wyższych wydatków związanych ze sprzętem, personelem i kosztami operacyjnymi. Skalowanie baz danych wektorów open source może być finansowo wymagające pomimo braku opłat licencyjnych.

Rozwiązywanie problemów z bazami danych wektorów open source

W pełni zarządzana baza danych wektorów, która integruje się w wysoce wydajnej bazie danych NoSQL lub relacyjnej bazie danych, pozwala uniknąć dodatkowych kosztów i złożoności baz danych wektorów typu open source. Taka baza danych przechowuje, indeksuje i przeszukuje osadzania wraz z odpowiednimi oryginalnymi danymi. Takie podejście eliminuje dodatkowy koszt replikowania danych w oddzielnej czystej bazie danych wektorów. Ponadto utrzymywanie wektorowych osadzeń i oryginalnych danych razem lepiej ułatwia operacje na danych wielomodalnych i zapewnia większą spójność danych, skalę i wydajność. W międzyczasie w pełni zarządzana usługa pomaga deweloperom uniknąć problemów z konfigurowaniem, konserwowaniem i poleganiem na pomocy społeczności dla bazy danych wektorów open source. Ponadto niektóre zarządzane usługi baz danych wektorowych oferują bezpłatny dożywotni poziom.

Przykładem jest zintegrowana baza danych wektorów w usłudze Azure DocumentDB. Ta konfiguracja pozwala deweloperom zaoszczędzić pieniądze, takie jak w przypadku baz danych wektorów open source. Jednak w przeciwieństwie do opcji typu open source dostawca usług zajmuje się konserwacją, aktualizacjami i skalowaniem. Uaktualnianie jest szybkie i łatwe przy zachowaniu niskich całkowitych kosztów posiadania (TCO), gdy nadszedł czas na skalowanie operacji w górę. Za pomocą tej usługi można również wygodnie skalować aplikacje Bazy danych MongoDB, które są już w środowisku produkcyjnym.

Usługa Azure DocumentDB zapewnia niezawodne funkcje wyszukiwania wektorów, co umożliwia szybkie wyszukiwanie podobieństw w złożonych zestawach danych. Aby przeprowadzić wyszukiwanie wektorów w usłudze Azure DocumentDB, należy najpierw utworzyć indeks wektorowy. Chociaż usługa Azure DocumentDB oferuje wiele opcji, poniżej przedstawiono ogólne wskazówki ułatwiające rozpoczęcie pracy na podstawie rozmiaru zestawu danych:

IVF HNSW DiskANN (zalecane)
Opis Indeks IVFFlat dzieli wektory na listy, a następnie wyszukuje podzbiór najbliżej wektora zapytania. Indeks HNSW tworzy graf wielowarstwowy. DiskANN to przybliżony algorytm wyszukiwania najbliższego sąsiada zaprojektowany pod kątem wydajnego wyszukiwania wektorów w dowolnej skali.
Kluczowe kompromisy Plusy: Szybsze czasy kompilacji, mniejsze użycie pamięci.
Minusy: Niższa efektywność zapytań (pod względem kompromisu pomiędzy szybkością a stopą przywołania).
Plusy: Lepsza wydajność zapytań (w kontekście kompromisu między szybkością a dokładnością) może być osiągnięta na pustej tabeli.
Minusy: Wolniejsze czasy kompilacji, większe użycie pamięci.
Plusy: Wydajna w dowolnej skali, wysoki wskaźnik odnalezienia, wysoka przepustowość, małe opóźnienia.
Liczba wektorów Poniżej 10 000 Do 50 000 Do 500 000+
Zalecana warstwa klastra M10 lub M20 M30 i nowsze M30 i nowsze

Indeksy DiskANN można używać w warstwach M30 i wyższych. Aby utworzyć indeks DiskANN, ustaw parametr "kind" na "vector-diskann", według tego szablonu:

{ 
    "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>, 
            } 
        } 
    ] 
}
(No changes needed) Typ Description
index_name ciąg Unikatowa nazwa indeksu.
path_to_property ciąg Ścieżka prowadząca do właściwości, która zawiera wektor. Ta ścieżka może być właściwością najwyższego poziomu lub ścieżką notacji kropkowej do właściwości. Wektory muszą być w number[], aby można je było indeksować i używać w wynikach wyszukiwania wektorowego. Wektor używający innego typu, takiego jak double[], uniemożliwia indeksowanie dokumentu. Nieindeksowane dokumenty nie są zwracane w wyniku wyszukiwania wektorowego.
kind ciąg Typ indeksu wektorowego do utworzenia. Dostępne opcje to vector-ivf, vector-hnswi vector-diskann.
dimensions liczba całkowita Liczba wymiarów podobieństwa wektorów. Usługa DiskANN obsługuje maksymalnie 16 000 wymiarów (z kwantyzacją produktu), a przyszłe wsparcie jest planowane na ponad 40 000.
similarity ciąg Metryka podobieństwa do użycia z indeksem. Możliwe opcje to COS (odległość cosinusu), L2 (odległość euklidesowa) i IP (produkt wewnętrzny).
maxDegree liczba całkowita Maksymalna liczba krawędzi na węzeł na grafie. Ten parametr waha się od 20 do 2048 (wartość domyślna to 32). Wyższe maxDegree jest odpowiednie dla zestawów danych o wysokiej wymiarowości i/lub wysokich wymaganiach dotyczących dokładności.
lBuild liczba całkowita Ustawia liczbę kandydatów sąsiadów ocenianych podczas budowy indeksu DiskANN. Ten parametr, który waha się od 10 do 500 (wartość domyślna to 50), równoważy dokładność i obciążenie obliczeniowe: wyższe wartości zwiększają jakość i dokładność indeksu, ale zwiększają czas kompilacji

Wykonaj wyszukiwanie wektorowe za pomocą DiskANN

Aby przeprowadzić wyszukiwanie wektorowe, użyj $search etapu potoku agregacji i wykonaj zapytanie za pomocą operatora cosmosSearch. Funkcja DiskANN umożliwia wyszukiwanie o wysokiej wydajności w ogromnych zestawach danych z opcjonalnym filtrowaniem, takim jak filtry geoprzestrzenne lub tekstowe.

{
  "$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>]}}}
      ]}
    }
  }
},
(No changes needed) Typ Description
lSearch liczba całkowita Określa rozmiar listy kandydatów dynamicznych do wyszukiwania. Wartość domyślna to 40, z konfigurowalnym zakresem od 10 do 1000. Zwiększenie wartości wzmacnia przypominanie, ale może zmniejszyć szybkość wyszukiwania.
k liczba całkowita Definiuje liczbę wyników wyszukiwania do zwrócenia. Wartość k musi być mniejsza lub równa lSearch.

Przykład użycia indeksu DiskANN z filtrowaniem

Dodawanie wektorów do bazy danych

Aby użyć wyszukiwania wektorowego z filtrami geoprzestrzennymi, dodaj dokumenty zawierające zarówno wektorowe osadzanie, jak i współrzędne lokalizacji. Embeddingi można utworzyć przy użyciu własnego modelu, embeddingów Azure OpenAI lub interfejsu API, takiego jak Hugging Face na 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)

Tworzenie indeksu wektora DiskANN

W poniższym przykładzie pokazano, jak skonfigurować indeks wektora DiskANN z funkcjami filtrowania. Ten przykład obejmuje tworzenie indeksu wektorów na potrzeby wyszukiwania podobieństwa, dodawanie dokumentów z właściwościami wektorowymi i geoprzestrzennymi oraz indeksowanie pól w celu uzyskania większej liczby filtrów.

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
            }
        }
    ]
})

To polecenie tworzy indeks wektora contentVector DiskANN w polu w exampleCollectionprogramie , włączając wyszukiwanie podobieństwa. Dodaje również:

  • Indeks w is_open polu, dzięki czemu można filtrować wyniki na podstawie tego, czy firmy są otwarte.
  • Indeks geoprzestrzenny w location polu do filtrowania według odległości geograficznej.

Aby znaleźć dokumenty z podobnymi wektorami w określonym promieniu geograficznym, określ queryVector wyszukiwanie podobieństwa i uwzględnij filtr geoprzestrzenny.

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)

W tym przykładzie wyszukiwanie podobieństwa wektorów zwraca najbardziej najbliższe k wektory na podstawie określonej COS metryki podobieństwa, filtrując wyniki w celu uwzględnienia tylko otwartych firm w promieniu 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]
    }
  }
]

Ten wynik przedstawia najważniejsze dokumenty podobne do queryVector; ograniczone do promienia 100 mil i otwartych firm. Każdy wynik zawiera wynik podobieństwa i metadane, co pokazuje, w jaki sposób funkcja DiskANN w usłudze Azure DocumentDB obsługuje połączone wektorowo i geoprzestrzenne zapytania dla wzbogaconych środowisk wyszukiwania, wrażliwych na lokalizację.

Pobieranie definicji indeksu wektorowego

Aby pobrać definicję indeksu wektora z kolekcji, użyj listIndexes polecenia :

db.exampleCollection.getIndexes();

W tym przykładzie vectorIndex jest zwracany ze wszystkimi cosmosSearch parametrami, które zostały użyte do utworzenia indeksu:

[
  { 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'
  }
]

Teraz można wykonywać wyszukiwania wektorów przy użyciu dowolnego obsługiwanego filtru zapytań, takiego jak $lt, , $lte$eq$neq$gte$gt$in$nini .$regex

Aby użyć filtrowania wstępnego, najpierw należy zdefiniować indeks standardowy dla właściwości, według której chcesz filtrować, oprócz indeksu wektorowego. Oto przykład tworzenia indeksu filtru:

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

Po utworzeniu indeksu filtru możesz dodać klauzulę "filter" bezpośrednio do zapytania wyszukiwania wektorowego. W tym przykładzie pokazano, jak filtrować wyniki, w których "title" wartość właściwości nie znajduje się na podanej liście:

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' }
}
]);

Ważne

Aby zoptymalizować wydajność i dokładność wstępnie filtrowanych wyszukiwań wektorów, rozważ dostosowanie parametrów indeksu wektorowego. W przypadku indeksów DiskANN zwiększenie maxDegree lub lBuild może uzyskać lepsze wyniki. W przypadku indeksów HNSW eksperymentowanie z wyższymi wartościami dla m, efConstructionlub efSearch może zwiększyć wydajność. Podobnie w przypadku indeksów IVF dostrajanie numLists lub nProbes może prowadzić do bardziej zadowalających wyników. Ważne jest przetestowanie określonej konfiguracji z danymi, aby upewnić się, że wyniki spełniają Twoje wymagania. Te parametry wpływają na strukturę indeksu i zachowanie wyszukiwania, a optymalne wartości mogą się różnić w zależności od właściwości danych i wzorców zapytań.

Korzystanie z narzędzi orkiestracji dużych modeli językowych (LLM)

Używanie jako wektorowej bazy danych z jądrem semantycznym

Użyj jądra semantycznego, aby zorganizować pobieranie informacji z usługi Azure DocumentDB i usługi LLM. Aby uzyskać więcej informacji, zobacz repozytorium GitHub.

Używanie jako wektorowej bazy danych w języku LangChain

Użyj biblioteki LangChain, aby zorganizować pobieranie informacji z usługi Azure DocumentDB i usługi LLM. Aby uzyskać więcej informacji, zobacz LangChain integrations for Azure DocumentDB (Integracje langchain dla usługi Azure DocumentDB).

Używanie jako semantycznej pamięci podręcznej w usłudze LangChain

Użyj języka LangChain i usługi Azure DocumentDB, aby zorganizować buforowanie semantyczne przy użyciu wcześniej zarejestrowanych odpowiedzi LLM, które mogą zaoszczędzić koszty interfejsu API LLM i zmniejszyć opóźnienie odpowiedzi. Aby uzyskać więcej informacji, zobacz Integracja aplikacji LangChain z usługą Azure DocumentDB.

Funkcje i ograniczenia

  • Obsługiwane metryki odległości: L2 (Euclidean), produkt wewnętrzny i cosinus.
  • Obsługiwane metody indeksowania: IVFFLAT, HNSW i DiskANN.
  • Przy użyciu DiskANN i kwantyzacji produktów można indeksować wektory do 16 000 wymiarów.
  • Korzystanie z HNSW lub IVF z połową precyzji umożliwia indeksowanie wektorów do 4000 wymiarów.
  • Bez żadnej kompresji domyślny maksymalny wymiar wektora indeksowania wynosi 2000.
  • Indeksowanie dotyczy tylko jednego wektora na ścieżkę.
  • Można utworzyć tylko jeden indeks na ścieżkę wektora.

Podsumowanie

W tym przewodniku pokazano, jak utworzyć indeks wektorowy, dodać dokumenty, które mają dane wektorowe, przeprowadzić wyszukiwanie podobieństwa i pobrać definicję indeksu. Korzystając z naszej zintegrowanej bazy danych wektorów, można efektywnie przechowywać, indeksować i wykonywać zapytania względem danych wektorów o wysokim wymiarach bezpośrednio w usłudze Azure DocumentDB. Umożliwia to odblokowanie pełnego potencjału danych za pomocą osadzeń wektorów i umożliwia tworzenie bardziej dokładnych, wydajnych i zaawansowanych aplikacji.

Następny krok