Udostępnij przez


Indeksy wektorów w usłudze Azure AI Search

Wektory to wielowymiarowe osadzanie, które reprezentują tekst, obrazy i inną zawartość matematycznie. Usługa Azure AI Search przechowuje wektory na poziomie pola, umożliwiając współistnienie zawartości wektorowej i niewektorowej w tym samym indeksie wyszukiwania.

Indeks wyszukiwania staje się indeksem wektorowym podczas definiowania pól wektorów i konfiguracji wektorów. Aby wypełnić pola wektorowe, możesz wprowadzić do nich wstępnie obliczone wektory lub użyć zintegrowanej wektoryzacji, wbudowanej funkcji usługi Azure AI Search, która generuje wektory podczas indeksowania.

W czasie zapytania pola wektorów w indeksie umożliwiają wyszukiwanie podobieństwa, w którym system pobiera dokumenty, których wektory są najbardziej podobne do zapytania wektorowego. Możesz użyć wyszukiwania wektorów do dopasowania podobieństwa samodzielnie lub wyszukiwania hybrydowego w celu uzyskania kombinacji podobieństwa i dopasowania słów kluczowych.

W tym artykule opisano kluczowe pojęcia dotyczące tworzenia indeksu wektorowego i zarządzania nim, w tym:

  • Wzorce pobierania wektorów
  • Zawartość (pola wektorowe i konfiguracja)
  • Struktura danych fizycznych
  • Operacje podstawowe

Wskazówka

Chcesz zacząć od razu? Zobacz Tworzenie indeksu wektorowego.

Wzorce pobierania wektorów

Usługa Azure AI Search obsługuje dwa wzorce pobierania wektorów:

  • Wyszukiwanie klasyczne. Ten wzorzec używa paska wyszukiwania, danych wejściowych zapytań i renderowanych wyników. Podczas wykonywania zapytania aparat wyszukiwania lub kod aplikacji wektoryzuje dane wejściowe użytkownika. Następnie wyszukiwarka wykonuje wyszukiwanie wektorowe na polach wektorów w indeksie i formułuje odpowiedź renderowaną w aplikacji klienckiej.

    W usłudze Azure AI Search wyniki są zwracane jako spłaszczone zestaw wierszy i można wybrać pola do uwzględnienia w odpowiedzi. Chociaż wyszukiwarka dopasowuje się do wektorów, indeks powinien zawierać niewektorową zawartość czytelną dla człowieka, aby uzupełnić wyniki wyszukiwania. Wyszukiwanie klasyczne obsługuje zapytania wektorowe i zapytania hybrydowe.

  • Generatywne wyszukiwanie. Modele językowe używają danych z usługi Azure AI Search do reagowania na zapytania użytkowników. Warstwa orkiestracji zwykle koordynuje monity i utrzymuje kontekst, przekazując wyniki wyszukiwania do modeli czatu, takich jak GPT. Ten wzorzec jest oparty na architekturze generacji wspomaganej odzyskiwaniem (RAG), w której indeks wyszukiwania udostępnia dane odniesienia.

Schemat indeksu wektorowego

Schemat indeksu wektorowego wymaga następujących elementów:

  • Nazwa
  • Pole klucza (ciąg)
  • Jedno lub więcej pól wektorów
  • Konfiguracja wektora

Pola niewektorowe nie są wymagane, ale zalecamy dołączenie ich do zapytań hybrydowych lub zwracanie zawartości dosłownej, która nie przechodzi przez model językowy. Aby uzyskać więcej informacji, zobacz Tworzenie indeksu wektorów.

Schemat indeksu powinien odzwierciedlać wzorzec pobierania wektorów. Ta sekcja obejmuje głównie kompozycję pól dla wyszukiwania klasycznego, ale zawiera również wskazówki dotyczące schematu dla generatywnego wyszukiwania.

Podstawowa konfiguracja pola wektora

Pola wektorowe mają unikatowe typy danych i właściwości. Oto, jak wygląda pole wektorowe w kolekcji pól:

{
    "name": "content_vector",
    "type": "Collection(Edm.Single)",
    "searchable": true,
    "retrievable": true,
    "dimensions": 1536,
    "vectorSearchProfile": "my-vector-profile"
}

Tylko niektóre typy danych są obsługiwane w przypadku pól wektorów. Najczęstszym typem jest Collection(Edm.Single), ale użycie wąskich typów może zaoszczędzić na przechowywaniu.

Pola wektorowe muszą być przeszukiwalne i dostępne, ale nie mogą być filtrowalne, możliwe do grupowania ani sortowalne. Nie mogą również mieć analizatorów, normalizatorów ani przypisywania map synonimów.

Właściwość dimensions musi być ustawiona na liczbę osadzonych elementów wygenerowanych przez model osadzania. Na przykład osadzanie tekstu-ada-002 generuje 1536 osadzania dla każdego fragmentu tekstu.

Pola wektorowe są indeksowane przy użyciu algorytmów określonych w profilu wyszukiwania wektorowego, który jest zdefiniowany gdzie indziej w indeksie, a nie pokazany w tym przykładzie. Aby uzyskać więcej informacji, zobacz Dodawanie konfiguracji wyszukiwania wektorów.

Kolekcja pól dla obciążeń wektorów podstawowych

Indeksy wektorowe wymagają więcej niż tylko pól wektorowych. Na przykład wszystkie indeksy muszą mieć pole klucza, które znajduje się id w poniższym przykładzie:

"name": "example-basic-vector-idx",
"fields": [
  { "name": "id", "type": "Edm.String", "searchable": false, "filterable": true, "retrievable": true, "key": true },
  { "name": "content_vector", "type": "Collection(Edm.Single)", "searchable": true, "retrievable": true, "dimensions": 1536, "vectorSearchProfile": null },
  { "name": "content", "type": "Edm.String", "searchable": true, "retrievable": true, "analyzer": null },
  { "name": "metadata", "type": "Edm.String", "searchable": true, "filterable": true, "retrievable": true, "sortable": true, "facetable": true }
]

Inne pola, takie jak content pole, zapewniają czytelny dla człowieka odpowiednik content_vector pola. Jeśli używasz modeli językowych wyłącznie do formułowania odpowiedzi, możesz pominąć pola zawartości niewektorów, ale rozwiązania, które wypychają wyniki wyszukiwania bezpośrednio do aplikacji klienckich, powinny mieć zawartość niewektora.

Pola metadanych są przydatne w przypadku filtrów, zwłaszcza jeśli zawierają informacje o pochodzeniu dokumentu źródłowego. Chociaż nie można filtrować bezpośrednio w polu wektorowym, można ustawić tryb filtrowania wstępnego, filtru postfiltru lub ścisłego filtru postfiltru (wersja zapoznawcza), aby filtrować przed wykonaniem zapytania wektorowego lub po nim.

Schemat wygenerowany przez kreatora importu

Zalecamy kreator importowania danych (nowy) do testowania oceny i weryfikacji koncepcji. Kreator generuje przykładowy schemat w tej sekcji.

Kreator dzieli zawartość na mniejsze dokumenty wyszukiwania, co przynosi korzyści aplikacjom RAG korzystającym z modeli językowych do formułowania odpowiedzi. Fragmentowanie pomaga pozostać w granicach danych wejściowych modeli językowych i limitów tokenów rankingu semantycznego. Zwiększa również precyzję wyszukiwania podobieństwa przez dopasowywanie zapytań względem fragmentów ściągniętych z wielu dokumentów nadrzędnych. Aby uzyskać więcej informacji, zobacz jak podzielić duże dokumenty na potrzeby rozwiązań wyszukiwania wektorów.

Dla każdego dokumentu wyszukiwania w poniższym przykładzie istnieje jeden identyfikator fragmentu, identyfikator nadrzędny, fragment, tytuł i pole wektorowe. Czarodziej:

  • Wypełnia pola chunk_id i parent_id metadanymi obiektów blob zakodowanymi w formacie base64 (ścieżka).

  • Wyodrębnia pola chunk z zawartości obiektu blob i pola title z nazwy obiektu blob.

  • Tworzy pole vector poprzez wywołanie dostarczonego przez ciebie modelu osadzania Azure OpenAI, aby zwektoryzować pole chunk. Tylko pole wektorowe jest w pełni generowane podczas tego procesu.

"name": "example-index-from-import-wizard",
"fields": [
  { "name": "chunk_id", "type": "Edm.String", "key": true, "searchable": true, "filterable": true, "retrievable": true, "sortable": true, "facetable": true, "analyzer": "keyword"},
  { "name": "parent_id", "type": "Edm.String", "searchable": true, "filterable": true, "retrievable": true, "sortable": true},
  { "name": "chunk", "type": "Edm.String", "searchable": true, "filterable": false, "retrievable": true, "sortable": false},
  { "name": "title", "type": "Edm.String", "searchable": true, "filterable": true, "retrievable": true, "sortable": false},
  { "name": "vector", "type": "Collection(Edm.Single)", "searchable": true, "retrievable": true, "dimensions": 1536, "vectorSearchProfile": "vector-1707768500058-profile"}
]

Jeśli projektujesz przechowywanie wektorowe dla aplikacji typu RAG i czatowych, możesz utworzyć dwa indeksy:

  • Jeden dla zawartości statycznej indeksowanej i wektoryzowanej.
  • Jeden dla konwersacji, które mogą być używane w przepływach monitów.

W celach ilustracyjnych w tej sekcji użyto chat-with-your-data-solution-accelerator do utworzenia indeksów chat-index i conversations.

Zrzut ekranu przedstawiający indeksy utworzone przez akcelerator.

Następujące pola z chat-index obsługują generatywne doświadczenia wyszukiwania:

"name": "example-index-from-accelerator",
"fields": [
  { "name": "id", "type": "Edm.String", "searchable": false, "filterable": true, "retrievable": true },
  { "name": "content", "type": "Edm.String", "searchable": true, "filterable": false, "retrievable": true },
  { "name": "content_vector", "type": "Collection(Edm.Single)", "searchable": true, "retrievable": true, "dimensions": 1536, "vectorSearchProfile": "my-vector-profile"},
  { "name": "metadata", "type": "Edm.String", "searchable": true, "filterable": false, "retrievable": true },
  { "name": "title", "type": "Edm.String", "searchable": true, "filterable": true, "retrievable": true, "facetable": true },
  { "name": "source", "type": "Edm.String", "searchable": true, "filterable": true, "retrievable": true  },
  { "name": "chunk", "type": "Edm.Int32", "searchable": false, "filterable": true, "retrievable": true },
  { "name": "offset", "type": "Edm.Int32", "searchable": false, "filterable": true, "retrievable": true }
]

Następujące pola z conversations obsługują orkiestrację i historię czatów:

"fields": [
    { "name": "id", "type": "Edm.String", "key": true, "searchable": false, "filterable": true, "retrievable": true, "sortable": false, "facetable": false },
    { "name": "conversation_id", "type": "Edm.String", "searchable": false, "filterable": true, "retrievable": true, "sortable": false, "facetable": true },
    { "name": "content", "type": "Edm.String", "searchable": true, "filterable": false, "retrievable": true },
    { "name": "content_vector", "type": "Collection(Edm.Single)", "searchable": true, "retrievable": true, "dimensions": 1536, "vectorSearchProfile": "default-profile" },
    { "name": "metadata", "type": "Edm.String", "searchable": true, "filterable": false, "retrievable": true },
    { "name": "type", "type": "Edm.String", "searchable": false, "filterable": true, "retrievable": true, "sortable": false, "facetable": true },
    { "name": "user_id", "type": "Edm.String", "searchable": false, "filterable": true, "retrievable": true, "sortable": false, "facetable": true },
    { "name": "sources", "type": "Collection(Edm.String)", "searchable": false, "filterable": true, "retrievable": true, "sortable": false, "facetable": true },
    { "name": "created_at", "type": "Edm.DateTimeOffset", "searchable": false, "filterable": true, "retrievable": true },
    { "name": "updated_at", "type": "Edm.DateTimeOffset", "searchable": false, "filterable": true, "retrievable": true }
]

Poniższy zrzut ekranu przedstawia wyniki wyszukiwania w conversationsEksploratorze wyszukiwania:

Zrzut ekranu eksploratora wyszukiwania z wynikami indeksu zaprojektowanym dla aplikacji RAG.

W naszym przykładzie wynik wyszukiwania wynosi 1,00, ponieważ wyszukiwanie jest niekwalifikowane. Kilka pól obsługuje orkiestrację i przepływy monitów:

  • conversation_id identyfikuje każdą sesję czatu.
  • type wskazuje, czy zawartość pochodzi od użytkownika, czy asystenta.
  • created_at i updated_at usuwają rozmowy z historii.

Struktura fizyczna i rozmiar

W usłudze Azure AI Search fizyczna struktura indeksu jest w dużej mierze implementacją wewnętrzną. Możesz uzyskać dostęp do jego schematu, załadować i wykonać zapytanie dotyczące jego zawartości, monitorować jego rozmiar i zarządzać jego pojemnością. Firma Microsoft zarządza jednak infrastrukturą i fizycznymi strukturami danych przechowywanymi w usłudze wyszukiwania.

Rozmiar i substancja indeksu są określane przez:

  • Ilość i kompozycja dokumentów.

  • Atrybuty w poszczególnych polach. Na przykład do filtrowania pól jest wymagana większa ilość miejsca do magazynowania.

  • Konfiguracja indeksu, w tym konfiguracja wektora określająca sposób tworzenia wewnętrznych struktur nawigacji. Możesz wybrać HNSW lub wyczerpujący KNN do wyszukiwania podobieństwa.

Usługa Azure AI Search nakłada limity na magazyn wektorowy, co pomaga zachować zrównoważony i stabilny system dla wszystkich obciążeń. Aby ułatwić utrzymanie limitów, użycie wektorów jest śledzone i zgłaszane oddzielnie w witrynie Azure Portal oraz programowo za pośrednictwem statystyk usług i indeksów.

Poniższy zrzut ekranu przedstawia usługę S1 skonfigurowaną z jedną partycją i jedną repliką. Ta usługa ma 24 małe indeksy, z których każdy ma średnio jedno pole wektorowe obejmujące 1536 osadzeń. Drugi kafelek przedstawia limit przydziału i użycie indeksów wektorów. Ponieważ indeks wektorowy jest wewnętrzną strukturą danych utworzoną dla każdego pola wektorowego, magazyn indeksów wektorów jest zawsze ułamkiem ogólnego magazynu używanego przez indeks. Pola niewektorowe i inne struktury danych zużywają resztę.

Zrzut ekranu przedstawiający kafelki użycia z magazynem, indeksem wektorów i liczbą indeksów.

Limity i oszacowania indeksów wektorowych zostały omówione w innym artykule, ale należy zwrócić uwagę na dwa punkty: maksymalny rozmiar magazynu zależy od daty utworzenia oraz warstwy cenowej usługi wyszukiwania. Nowsze usługi tej samej warstwy mają znacznie większą pojemność dla indeksów wektorów. Z tych powodów należy wykonać następujące czynności:

Podstawowe operacje i interakcja

W tej sekcji przedstawiono operacje wektorowego środowiska uruchomieniowego, w tym nawiązywanie połączenia z pojedynczym indeksem i zabezpieczanie go.

Uwaga

Brak obsługi portalu ani interfejsu API do przenoszenia lub kopiowania indeksu. Zazwyczaj kierujesz wdrożenie aplikacji do innej usługi wyszukiwania (używając tej samej nazwy indeksu) lub zmień nazwę, aby utworzyć kopię w bieżącej usłudze wyszukiwania, a następnie ją zbuduj.

Izolacja indeksu

W usłudze Azure AI Search pracujesz z jednym indeksem jednocześnie. Wszystkie operacje związane z indeksem dotyczą pojedynczego indeksu. Nie ma pojęcia powiązanych indeksów ani łączenia niezależnych indeksów na potrzeby indeksowania lub wykonywania zapytań.

Stale dostępne

Indeks jest natychmiast dostępny dla zapytań, gdy tylko pierwszy dokument jest indeksowany, ale nie jest w pełni operacyjny, dopóki wszystkie dokumenty nie zostaną zindeksowane. Wewnętrznie indeks jest dystrybuowany między partycjami i wykonywany na replikach. Indeks fizyczny jest zarządzany wewnętrznie. Zarządzasz indeksem logicznym.

Indeks jest stale dostępny i nie można go wstrzymać ani przejąć do trybu offline. Ponieważ jest ona przeznaczona do ciągłej operacji, aktualizacje zawartości i dodatki do samego indeksu są wykonywane w czasie rzeczywistym. Jeśli żądanie zbiega się z aktualizacją dokumentu, zapytania mogą tymczasowo zwracać niekompletne wyniki.

Ciągłość zapytań istnieje dla operacji dokumentów, takich jak odświeżanie lub usuwanie, oraz modyfikacje, które nie mają wpływu na istniejącą strukturę lub integralność indeksu, takie jak dodawanie nowych pól. Aktualizacje strukturalne, takie jak zmiana istniejących pól, są zazwyczaj zarządzane przy użyciu przepływu pracy polegającego na usunięciu i odbudowaniu w środowisku deweloperskim lub przez utworzenie nowej wersji indeksu w usłudze produkcyjnej.

Aby uniknąć ponownego kompilowania indeksu, niektórzy klienci wprowadzający małe zmiany wersjonują pole, tworząc nową wersję, która współistnieje z poprzednią. Z czasem prowadzi to do osieroconej zawartości poprzez przestarzałe pola i przestarzałe definicje analizatora niestandardowego, zwłaszcza w indeksie produkcyjnym, który jest kosztowny do replikacji. Te problemy można rozwiązać podczas planowanych aktualizacji indeksu w ramach zarządzania cyklem życia indeksu.

Połączenie punktu końcowego

Wszystkie indeksowanie wektorów i żądania zapytań są kierowane do indeksu. Punkty końcowe są zwykle jednym z następujących elementów:

Punkt końcowy Połączenie i kontrola dostępu
<your-service>.search.windows.net/indexes Obiekt docelowy kolekcji indeksów. Używany podczas tworzenia, wyświetlania listy lub usuwania indeksu. Uprawnienia administratora są wymagane dla tych operacji i dostępne za pośrednictwem kluczy interfejsu API administratora lub roli Współautor wyszukiwania.
<your-service>.search.windows.net/indexes/<your-index>/docs Obiekt docelowy kolekcji dokumentów pojedynczego indeksu. Używane podczas wykonywania zapytań dotyczących indeksu lub odświeżania danych. W przypadku zapytań wystarczające są prawa odczytu, które są dostępne za pośrednictwem kluczy API zapytań lub roli czytelnika danych. W przypadku odświeżania danych wymagane są prawa administratora.
  1. Upewnij się, że masz uprawnienia lub klucz dostępu interfejsu API. Jeśli nie wysyłasz zapytań dotyczących istniejącego indeksu, potrzebujesz uprawnień administratora lub przypisania roli Współautor do zarządzania zawartością i wyświetlania jej w usłudze wyszukiwania.

  2. Zacznij od witryny Azure Portal. Osoba, która utworzyła usługę wyszukiwania, może wyświetlać ją i zarządzać nią, w tym udzielać dostępu innym osobom na stronie Kontrola dostępu (IAM).

  3. Przejdź do innych klientów w celu uzyskania dostępu programowego. Na początek zalecamy Szybki start: wyszukiwanie wektorów przy użyciu interfejsu REST i repozytorium azure-search-vector-samples.

Zarządzanie magazynami wektorów

Platforma Azure udostępnia platformę monitorowania, która obejmuje rejestrowanie diagnostyczne i alerty. Zalecamy wykonanie następujących czynności:

Bezpieczny dostęp do danych wektorowych

Usługa Azure AI Search implementuje szyfrowanie danych, połączenia prywatne dla scenariuszy bez Internetu i przypisania ról w celu zapewnienia bezpiecznego dostępu za pośrednictwem identyfikatora Entra firmy Microsoft. Aby uzyskać więcej informacji na temat funkcji zabezpieczeń przedsiębiorstwa, zobacz Zabezpieczenia w usłudze Azure AI Search.