Wyszukiwanie wektorów Mosaic AI

W tym artykule przedstawiono przegląd Wyszukiwania Wektorowego Mosaic AI, zawierający informacje o tym, co to jest i jak działa.

Co to jest wyszukiwanie wektorów w Mosaic AI?

Mozaikowe wyszukiwanie wektorów sztucznej inteligencji to rozwiązanie do wyszukiwania wektorów wbudowane w platformę analizy danych usługi Databricks i zintegrowane z jej narzędziami do zapewniania ładu i produktywności. Wyszukiwanie wektorowe to typ wyszukiwania zoptymalizowany pod kątem pobierania reprezentacji wektorowych. Osadzanie to matematyczne reprezentacje semantycznej zawartości danych, zwykle danych tekstowych lub obrazów. Osadzanie jest generowane przez duży model językowy i jest kluczowym składnikiem wielu generowanych aplikacji sztucznej inteligencji, które zależą od znajdowania dokumentów lub obrazów, które są podobne do siebie. Przykłady to systemy RAG, systemy rekomendacji oraz rozpoznawanie obrazów i wideo.

Z Mosaic AI Vector Search, tworzysz indeks wyszukiwania wektorów na podstawie tabeli Delta. Indeks zawiera osadzone dane z metadanymi. Następnie możesz wykonać zapytanie względem indeksu przy użyciu interfejsu API REST, aby zidentyfikować najbardziej podobne wektory i zwrócić skojarzone dokumenty. Można skonstruować indeks tak, aby automatycznie się synchronizował po zaktualizowaniu bazowej tabeli Delta.

Aplikacja Mosaic AI Vector Search obsługuje następujące elementy:

• Hybrydowe wyszukiwanie podobieństwa słów kluczowych.
• Filtrowanie.
• Reranking.
• Listy kontroli dostępu (ACL) do zarządzania punktami końcowymi wyszukiwania wektorów.
• Synchronizuj tylko wybrane kolumny.
• Zapisz i synchronizuj wygenerowane osadzania.

Jak działa wyszukiwanie wektorów Mosaic AI?

Wyszukiwanie wektorowe Mosaic AI używa algorytmu HNSW (Hierarchical Navigable Small World) do wyszukiwania przybliżonego najbliższego sąsiada (ANN) i metryki odległości L2 do mierzenia podobieństwa wektorów osadzania. Jeśli chcesz użyć podobieństwa cosinusowego, musisz znormalizować osadzenia punktu danych przed wprowadzeniem ich do wyszukiwania wektorowego. Gdy punkty danych są znormalizowane, klasyfikacja wygenerowana przez odległość L2 jest taka sama jak ta generowana przez podobieństwo cosinusowe.

Mosaic AI Vector Search obsługuje również hybrydowe wyszukiwanie słów kluczowych, które łączy wyszukiwanie osadzeń opartych na wektorach z tradycyjnymi technikami wyszukiwania opartymi na słowach kluczowych. Takie podejście dopasowuje dokładne wyrazy w zapytaniu, a jednocześnie używa wyszukiwania podobieństwa opartego na wektorach w celu przechwycenia relacji semantycznych i kontekstu zapytania.

Dzięki zintegrowaniu tych dwóch technik wyszukiwanie słów kluczowych hybrydowych pobiera dokumenty zawierające nie tylko dokładne słowa kluczowe, ale także te, które są koncepcyjnie podobne, zapewniając bardziej kompleksowe i odpowiednie wyniki wyszukiwania. Ta metoda jest szczególnie przydatna w aplikacjach RAG, w których dane źródłowe mają unikatowe słowa kluczowe, takie jak jednostki SKU lub identyfikatory, które nie są odpowiednie do wyszukiwania czystego podobieństwa.

Aby uzyskać szczegółowe informacje na temat interfejsu API, zobacz Dokumentację zestawu SDK języka Python i Wykonywanie zapytań względem indeksu wyszukiwania wektorów.

Obliczanie wyszukiwania podobieństwa

Obliczenie wyszukiwania podobieństwa używa następującej formuły:

gdzie dist to odległość euklidesowa między q zapytania a wpisem indeksu x:

Algorytm wyszukiwania słów kluczowych

Wyniki istotności są obliczane przy użyciu rozwiązania Okapi BM25. Przeszukiwane są wszystkie kolumny tekstowe lub ciągowe, w tym kolumny osadzania tekstu źródłowego i metadanych w formacie tekstowym lub ciągowym. Funkcja tokenizacji dzieli się na granice wyrazów, usuwa znaki interpunkcyjne i konwertuje cały tekst na małe litery.

Jak połączone są wyszukiwanie podobieństwa i wyszukiwanie słów kluczowych

Wyniki wyszukiwania słów kluczowych i wyszukiwania podobieństwa są łączone przy użyciu funkcji RRF (Reciprocal Rank Fusion).

Funkcja RRF najpierw ponownie ocenia każdy dokument z każdej metody na podstawie uzyskanych wcześniej wyników.

rrf_param steruje względnym znaczeniem dokumentów o wyższych i niższych rangach. Na podstawie literatury rrf_param ma wartość 60.

Wyniki są znormalizowane tak, aby najwyższy możliwy wynik wynosi 1 przy użyciu następującego współczynnika normalizacji:

Ostateczny wynik dla każdego dokumentu jest obliczany w następujący sposób:

Zwracane są dokumenty z najwyższymi wynikami końcowymi.

Opcje dostarczania zanurzeń wektorów

Aby utworzyć indeks wyszukiwania wektorowego w usłudze Databricks, musisz najpierw zdecydować, jak zapewnić osadzanie wektorów. Usługa Databricks obsługuje trzy opcje.

Opcja 1: Indeks Delta Sync z osadzonymi danymi obliczonymi przez usługę Databricks

W przypadku tej opcji należy podać źródłową tabelę delty zawierającą dane w formacie tekstowym. Usługa Databricks oblicza osadzenia, używając określonego modelu, i opcjonalnie zapisuje osadzenia do tabeli w Unity Catalog. Podczas aktualizowania tabeli delty indeks pozostaje zsynchronizowany z tabelą delty.

Na poniższym diagramie przedstawiono proces:

1. Obliczanie osadzania zapytań. Zapytanie może zawierać filtry metadanych.
2. Wykonaj wyszukiwanie podobieństwa, aby zidentyfikować najbardziej odpowiednie dokumenty.
3. Zwróć najbardziej odpowiednie dokumenty i dołącz je jako część zapytania.

Opcja 2. Indeks synchronizacji różnicowej z osadzanymi własnymi funkcjami

W przypadku tej opcji należy podać źródłową tabelę delty zawierającą wstępnie obliczone osadzanie. Podczas aktualizowania tabeli delty indeks pozostaje zsynchronizowany z tabelą delty.

Na poniższym diagramie przedstawiono proces:

1. Zapytanie składa się z osadzeń i może zawierać filtry metadanych.
2. Wykonaj wyszukiwanie podobieństwa, aby zidentyfikować najbardziej odpowiednie dokumenty. Zwróć najbardziej odpowiednie dokumenty i dołącz je jako część zapytania.

Opcja 3. Indeks dostępu wektorów bezpośrednich

W przypadku tej opcji należy ręcznie zaktualizować indeks przy użyciu interfejsu API REST po zmianie tabeli osadzania.

Na poniższym diagramie przedstawiono proces:

Opcje punktu końcowego

Aplikacja Mosaic AI Vector Search oferuje następujące opcje, dzięki czemu można wybrać konfigurację punktu końcowego, która spełnia wymagania aplikacji.

• Standardowe punkty końcowe mają pojemność 320 milionów wektorów w wymiarze 768.
• Punkty końcowe zoptymalizowane pod kątem magazynu mają większą pojemność (ponad miliard wektorów w wymiarze 768) i zapewniają 10-20-krotne szybsze indeksowanie. Zapytania dotyczące punktów końcowych zoptymalizowanych pod kątem przechowywania mają nieco większe opóźnienie wynoszące około 250 milisekund. Ceny tej opcji są zoptymalizowane pod kątem większej liczby wektorów. Aby uzyskać szczegółowe informacje o cenach, zobacz stronę cennika wyszukiwania wektorów. Aby uzyskać informacje na temat zarządzania kosztami wyszukiwania wektorów, zobacz Przewodnik zarządzania kosztami dla Mosaic AI Vector Search.

Typ punktu końcowego należy określić podczas tworzenia punktu końcowego.

Zobacz również Ograniczenia punktów końcowych zoptymalizowanych pod kątem przechowywania.

Jak skonfigurować wyszukiwanie wektorowe Mosaic AI

Aby użyć funkcji Mosaic AI Vector Search, należy utworzyć następujące elementy:

• Punkt końcowy wyszukiwania wektorów. Ten punkt końcowy obsługuje indeks wyszukiwania wektorowego. Można zapytać i aktualizować punkt końcowy przy użyciu interfejsu API REST lub SDK. Aby uzyskać instrukcje, zobacz Tworzenie punktu końcowego wyszukiwania wektorów.

  Punkty końcowe są skalowane automatycznie w górę, aby obsługiwać rozmiar indeksu lub liczbę współbieżnych żądań. Punkty końcowe zoptymalizowane pod kątem magazynu są skalowane automatycznie w dół po usunięciu indeksu. Standardowe punkty końcowe nie są automatycznie skalowane w dół.

• Indeks wyszukiwania wektorowego. Indeks wyszukiwania wektorów jest tworzony na podstawie tabeli delty i jest zoptymalizowany pod kątem zapewniania wyszukiwania w czasie rzeczywistym przybliżonego najbliższego sąsiada (ANN). Celem wyszukiwania jest zidentyfikowanie dokumentów, które są podobne do zapytania. Indeksy wyszukiwania wektorowego pojawiają się i są zarządzane przez Unity Catalog. Aby uzyskać instrukcje, zobacz Tworzenie indeksu wyszukiwania wektorów.

Ponadto jeśli zdecydujesz się, aby usługa Databricks obliczała osadzanie, możesz użyć wstępnie skonfigurowanego punktu końcowego interfejsów API modelu podstawowego lub utworzyć punkt końcowy obsługujący model służący do obsługi wybranego modelu osadzania. Aby uzyskać instrukcje, zobacz interfejsy API modelu z płatnością na podstawie tokena lub Utwórz punkty końcowe obsługujące model podstawowy.

Aby wykonać zapytanie dotyczące punktu końcowego obsługującego model, należy użyć interfejsu API REST lub zestawu SDK języka Python. Zapytanie może definiować filtry na podstawie dowolnej kolumny w tabeli delty. Aby uzyskać szczegółowe informacje, zobacz Używanie filtrów dla zapytań, dokumentacji interfejsu API lub dokumentacji zestawu SDK języka Python.

Requirements

• Obszar roboczy z włączonym Unity Catalog.
• Włączono bezserwerowe obliczenia. Aby uzyskać instrukcje, zobacz Połącz się z obliczeniami bezserwerowymi.
• W przypadku standardowych punktów końcowych tabela źródłowa musi mieć włączony Strumień danych zmian. Zobacz Używanie kanału danych zmian Delta Lake na platformie Azure Databricks.
• Aby utworzyć indeks wyszukiwania wektorowego, musisz mieć uprawnienia CREATE TABLE w schemacie wykazu, w którym zostanie utworzony indeks.

Uprawnienia do tworzenia punktów końcowych wyszukiwania wektorów i zarządzania nimi są konfigurowane przy użyciu list kontroli dostępu. Zobacz kontrole dostępu (ACL) punktu końcowego wyszukiwania wektorów .

Ochrona i uwierzytelnianie danych

Usługa Databricks implementuje następujące mechanizmy kontroli zabezpieczeń w celu ochrony danych:

• Każde żądanie klienta do Mosaic AI Vector Search jest logicznie izolowane, uwierzytelniane i autoryzowane.
• Mosaic AI Vector Search szyfruje wszystkie dane w spoczynku (AES-256) i podczas przesyłania (TLS 1.2+).

Mosaic AI Vector Search obsługuje dwie metody uwierzytelniania: zasady usługi i osobiste tokeny dostępu (PATs). W przypadku aplikacji produkcyjnych Databricks zaleca używanie głównych kont usługowych, które mogą mieć wydajność dla poszczególnych zapytań o do 100 ms szybciej w stosunku do osobistych tokenów dostępu.

• Token głównego obiektu usługi. Administrator może wygenerować token jednostki usługi i przekazać go do API lub SDK. Zobacz Use service principals (Używanie jednostek usługi). Dla zastosowań w środowisku produkcyjnym Databricks zaleca użycie tokenu jednostki usługi.

  # Pass in a service principal
  vsc = VectorSearchClient(workspace_url="...",
          service_principal_client_id="...",
          service_principal_client_secret="..."
          )
  

• Osobisty token dostępu. Możesz użyć osobistego tokenu dostępu do uwierzytelniania za pomocą narzędzia Mosaic AI Vector Search. Zobacz token uwierzytelniania dostępu osobistego. Jeśli używasz zestawu SDK w środowisku notatnika, zestaw SDK automatycznie generuje token PAT na potrzeby uwierzytelniania.

  # Pass in the PAT token
  client = VectorSearchClient(workspace_url="...", personal_access_token="...")
  

Klucze zarządzane przez klienta (CMK) są obsługiwane w punktach końcowych utworzonych 8 maja 2024 r. lub później.

Monitorowanie użycia i kosztów

Tabela rozliczanego systemu użycia umożliwia monitorowanie użycia i kosztów skojarzonych z indeksami wyszukiwania wektorowego i punktami końcowymi. Oto przykładowe zapytanie:

WITH all_vector_search_usage (
  SELECT *,
         CASE WHEN usage_metadata.endpoint_name IS NULL THEN 'ingest'
              WHEN usage_type = "STORAGE_SPACE" THEN 'storage'
              ELSE 'serving'
        END as workload_type
    FROM system.billing.usage
   WHERE billing_origin_product = 'VECTOR_SEARCH'
),
daily_dbus AS (
  SELECT workspace_id,
       cloud,
       usage_date,
       workload_type,
       usage_metadata.endpoint_name as vector_search_endpoint,
       CASE WHEN workload_type = 'serving' THEN SUM(usage_quantity)
            WHEN workload_type = 'ingest' THEN SUM(usage_quantity)
            ELSE null
            END as dbus,
       CASE WHEN workload_type = 'storage' THEN SUM(usage_quantity)
            ELSE null
            END as dsus
 FROM all_vector_search_usage
 GROUP BY all
ORDER BY 1,2,3,4,5 DESC
)
SELECT * FROM daily_dbus

Możesz również wykonywać zapytania dotyczące użycia według polityki budżetowej. Zobacz Mozaikowe wyszukiwanie wektorów sztucznej inteligencji: zasady budżetowe.

Aby uzyskać szczegółowe informacje na temat zawartości tabeli użycia rozliczeniowego, zobacz Billable usage system table reference. Dodatkowe zapytania znajdują się w poniższym przykładowym notesie.

Notatnik dla zapytań dotyczących tabel systemu wyszukiwania wektorowego

Pobierz laptopa

Limity rozmiaru zasobów i danych

W poniższej tabeli przedstawiono podsumowanie limitów rozmiaru zasobów i danych dla punktów końcowych i indeksów wyszukiwania wektorów:

Następujące limity dotyczą tworzenia i aktualizowania indeksów wyszukiwania wektorowego:

Następujące limity dotyczą interfejsu API zapytań.

Ograniczenia

• Nazwa _id kolumny jest zarezerwowana. Jeśli tabela źródłowa ma kolumnę o nazwie _id, zmień jej nazwę przed utworzeniem indeksu wyszukiwania wektorowego.
• Uprawnienia na poziomie wierszy i kolumn nie są obsługiwane. Można jednak zaimplementować własne listy kontroli dostępu (ACL) na poziomie aplikacji, korzystając z interfejsu API filtrowania.
• Nie można sklonowania indeksu do innego obszaru roboczego. Żądania między obszarami roboczymi można tworzyć przy użyciu zestawu SDK usługi Databricks lub interfejsu API REST.

Ograniczenia dotyczące punktów końcowych zoptymalizowanych pod kątem przechowywania

Ograniczenia w tej sekcji dotyczą tylko punktów końcowych zoptymalizowanych pod kątem przechowywania. Punkty końcowe zoptymalizowane pod kątem przechowywania są w publicznej wersji zapoznawczej.

• Tryb ciągłej synchronizacji nie jest obsługiwany.
• Synchronizowanie kolumn nie jest obsługiwane.
• Wymiar osadzania musi być podzielny przez 16.
• Aktualizacja przyrostowa jest częściowo obsługiwana. Każda synchronizacja musi ponownie skompilować fragmenty indeksu wyszukiwania wektorowego.
  • W przypadku indeksów zarządzanych wszystkie wcześniej obliczone operacje osadzania są ponownie używane, jeśli wiersz źródłowy nie uległ zmianie.
  • Należy przewidzieć znaczne zmniejszenie całkowitego czasu potrzebnego na synchronizację w porównaniu ze standardowymi punktami końcowymi. Zestawy danych zawierające 1 miliard wektorów osadzeń powinny zakończyć synchronizację w czasie poniżej 8 godzin. Synchronizacja mniejszych zestawów danych zajmie mniej czasu.
• Obszary robocze zgodne z protokołem FedRAMP nie są obsługiwane.
• Klucze zarządzane przez klienta (CMK) nie są obsługiwane.
• Aby użyć niestandardowego modelu osadzania dla zarządzanego indeksu usługi Delta Sync, należy włączyć zapytanie AI dla modeli niestandardowych i modeli zewnętrznych w wersji zapoznawczej. Zobacz Zarządzanie wersjami zapoznawczami usługi Azure Databricks , aby dowiedzieć się, jak włączyć podglądy.
• Punkty końcowe zoptymalizowane pod kątem przechowywania obsługują maksymalnie 1 miliard wbudowań wektorów o wymiarze 768. Jeśli masz większy przypadek użycia na dużą skalę, skontaktuj się z zespołem ds. kont.

Dodatkowe zasoby

• Wdróż czatbota LLM wykorzystując Retrieval Augmented Generation (RAG), modele bazowe i wyszukiwanie wektorowe.
• Tworzenie punktów końcowych i indeksów wyszukiwania wektorów
• Wykonywanie zapytań względem indeksu wyszukiwania wektorów
• Przykładowe notatniki wyszukiwania wektorowego