Wyszukiwanie indeksów w usłudze Azure AI Search

W usłudze Azure AI Search indeks wyszukiwania to zawartość z możliwością wyszukiwania dostępna dla wyszukiwarki do indeksowania, wyszukiwania pełnotekstowego, wyszukiwania wektorowego, wyszukiwania hybrydowego i filtrowanych zapytań. Indeks jest definiowany przez schemat i zapisywany w usłudze wyszukiwania, a importowanie danych następuje po drugim kroku. Ta zawartość istnieje w usłudze wyszukiwania, oprócz podstawowych magazynów danych, co jest niezbędne do czasu odpowiedzi w milisekundach oczekiwanych w nowoczesnych aplikacjach wyszukiwania. Z wyjątkiem scenariuszy indeksowania opartego na indeksatorze usługa wyszukiwania nigdy nie łączy się z danymi źródłowymi ani nie wykonuje zapytań.

Jeśli chcesz utworzyć indeks wyszukiwania i zarządzać nim, ten artykuł pomaga zrozumieć następujące kwestie:

• Zawartość (dokumenty i schemat)
• Struktura danych fizycznych
• Operacje podstawowe

Wolisz być praktyczne od razu? Zamiast tego zobacz Tworzenie indeksu wyszukiwania.

Schemat indeksu wyszukiwania

W usłudze Azure AI Search indeksy zawierają dokumenty wyszukiwania. Koncepcyjnie dokument jest pojedynczą jednostką danych z możliwością wyszukiwania w indeksie. Na przykład sprzedawca detaliczny może mieć dokument dla każdego produktu, organizacja informacyjna może mieć dokument dla każdego artykułu, witrynę podróży może zawierać dokument dla każdego hotelu i miejsca docelowego itd. Mapowanie tych pojęć na bardziej znane odpowiedniki bazy danych: indeks wyszukiwania jest równa tabeli, a dokumenty są w przybliżeniu równoważne wierszom w tabeli.

Struktura dokumentu jest określana przez schemat indeksu, jak pokazano w poniższym przykładzie. Kolekcja "pól" jest zazwyczaj największą częścią indeksu, w której każde pole ma nazwę, przypisano typ danych i przypisuje się je dozwolonym zachowaniem, które określają sposób jej użycia.

{
  "name": "name_of_index, unique across the service",
  "fields": [
    {
      "name": "name_of_field",
      "type": "Edm.String | Collection(Edm.String) | Collection(Edm.Single) | Edm.Int32 | Edm.Int64 | Edm.Double | Edm.Boolean | Edm.DateTimeOffset | Edm.GeographyPoint",
      "searchable": true (default where applicable) | false (only Edm.String and Collection(Edm.String) fields can be searchable),
      "filterable": true (default) | false,
      "sortable": true (default where applicable) | false (Collection(Edm.String) fields cannot be sortable),
      "facetable": true (default where applicable) | false (Edm.GeographyPoint fields cannot be facetable),
      "key": true | false (default, only Edm.String fields can be keys),
      "retrievable": true (default) | false,
      "analyzer": "name_of_analyzer_for_search_and_indexing", (only if 'searchAnalyzer' and 'indexAnalyzer' are not set)
      "searchAnalyzer": "name_of_search_analyzer", (only if 'indexAnalyzer' is set and 'analyzer' is not set)
      "indexAnalyzer": "name_of_indexing_analyzer", (only if 'searchAnalyzer' is set and 'analyzer' is not set)
      "normalizer":  "name_of_normalizer", (applies to fields that are filterable)
      "synonymMaps": "name_of_synonym_map", (optional, only one synonym map per field is currently supported)
      "dimensions": "number of dimensions used by an emedding models", (applies to vector fields only, of type Collection(Edm.Single))
      "vectorSearchProfile": "name_of_vector_profile" (indexes can have many configurations, a field can use just one)
    }
  ],
  "suggesters": [ ],
  "scoringProfiles": [ ],
  "analyzers":(optional)[ ... ],
  "charFilters":(optional)[ ... ],
  "tokenizers":(optional)[ ... ],
  "tokenFilters":(optional)[ ... ],
  "defaultScoringProfile": (optional) "...",
  "corsOptions": (optional) { },
  "encryptionKey":(optional){ },
  "semantic":(optional){ },
  "vectorSearch":(optional){ }
}

Inne elementy są zwinięte w celu zwięzłości, ale następujące linki zawierają szczegółowe informacje:

• sugestorzy obsługują zapytania z wyprzedzeniem, takie jak autouzupełnianie.
• pliki scoringProfile są używane do dostrajania istotności.
• analizatory są używane do przetwarzania ciągów w tokeny zgodnie z regułami językowymi lub innymi cechami obsługiwanymi przez analizator.
• corsOptions lub zdalne wykonywanie skryptów między źródłami (CORS) jest używane w przypadku aplikacji, które wysyłają żądania z różnych domen.
• encryptionKey konfiguruje podwójne szyfrowanie poufnej zawartości w indeksie.
• Semantyka konfiguruje semantyczną reranking w trybie pełnotekstowym i hybrydowym.
• vectorSearch konfiguruje pola i zapytania wektorowe.

Definicje pola

Dokument wyszukiwania jest definiowany przez kolekcję "pola" w treści żądania Utwórz indeks. Potrzebne są pola do identyfikacji dokumentu (kluczy), przechowywania tekstu z możliwością wyszukiwania i pól do obsługi filtrów, aspektów i sortowania. Mogą być również potrzebne pola danych, których użytkownik nigdy nie widzi. Na przykład możesz chcieć, aby pola marży zysku lub promocji marketingowych można użyć w profilu oceniania, aby zwiększyć wynik wyszukiwania.

Jeśli dane przychodzące mają charakter hierarchiczny, można je przedstawić w indeksie jako typ złożony, używany dla zagnieżdżonych struktur. Wbudowany przykładowy zestaw danych Hotels ilustruje złożone typy przy użyciu pola Adres (zawiera wiele pól podrzędnych), które mają relację jeden do jednego z każdym hotelem, oraz złożoną kolekcję Rooms, gdzie wiele pokoi jest skojarzonych z każdym hotelem.

Atrybuty pól

Atrybuty pól określają sposób użycia pola, np. czy są używane w wyszukiwaniu pełnotekstowym, nawigacji aspektowej, operacjach sortowania itd.

Pola ciągów są często oznaczone jako "możliwe do wyszukiwania" i "możliwe do pobrania". Pola używane do zawężenia wyników wyszukiwania obejmują "sortowalne", "filtrowalne" i "facetable".

Atrybut	opis
"z możliwością wyszukiwania"	Wyszukiwanie pełnotekstowe lub wektorowe. Pola tekstowe podlegają analizie leksykalnej, takiej jak łamanie wyrazów podczas indeksowania. Jeśli ustawisz pole z możliwością wyszukiwania na wartość podobną do "słonecznego dnia", wewnętrznie zostanie ono podzielone na poszczególne tokeny "słoneczne" i "dzień". Aby uzyskać więcej informacji, zobacz Jak działa wyszukiwanie pełnotekstowe.
"filtrowalne"	Odwołania do tego atrybutu znajdują się w zapytaniach $filter. Pola z możliwością filtrowania typu Edm.String lub Collection(Edm.String) nie są poddawane łamaniu wyrazów, dlatego porównania są przeznaczone tylko dla dokładnych dopasowań. Jeśli na przykład ustawisz takie pole f na "słoneczny dzień", $filter=f eq 'sunny' nie znajdzie żadnych dopasowań, ale $filter=f eq 'sunny day' będzie.
"sortowalne"	Domyślnie system sortuje pozycje według wyników, ale można również ustawić sortowanie według poszczególnych pól w dokumentach. Pola typu Collection(Edm.String) nie mogą być "sortowalne".
"aspektable"	Zwykle używany w prezentacji wyników wyszukiwania, która zawiera liczbę trafień według kategorii (na przykład hotele znajdujące się w określonym mieście). Tej opcji nie można używać z polami typu Edm.GeographyPoint. Pola typu Edm.String , które można filtrować, "sortowalne" lub "facetable" mogą mieć długość co najwyżej 32 kilobajtów. Aby uzyskać więcej informacji, zobacz Create Index (REST API) (Tworzenie indeksu [interfejs REST API]).
"klucz"	Unikatowy identyfikator dokumentów w indeksie. Można wybrać tylko jedno pole klucza i musi ono być typu Edm.String.
"Możliwe do pobrania"	Określa, czy pole może być zwracane w wynikach wyszukiwania. Jest to przydatne, gdy chcesz użyć pola (takiego jak marża zysku) jako mechanizmu filtrowania, sortowania lub oceniania, ale nie chcesz, aby pole było widoczne dla użytkownika końcowego. Ten atrybut musi przyjmować wartość true dla pól typu key.

Chociaż możesz w dowolnym momencie dodać nowe pola, istniejące definicje pól są zablokowane przez cały czas istnienia indeksu. Z tego powodu deweloperzy zazwyczaj używają portalu do tworzenia prostych indeksów, testowania pomysłów lub używania stron portalu w celu wyszukania ustawień. Częsta iteracja po projekcie indeksu jest bardziej wydajna, jeśli stosujesz podejście oparte na kodzie, które pozwala na odbudowanie indeksu w prosty sposób.

Uwaga

Interfejsy API używane do tworzenia indeksu mają różne zachowania domyślne. W przypadku interfejsów API REST większość atrybutów jest domyślnie włączona (na przykład "z możliwością wyszukiwania" i "pobieranie" dotyczy pól ciągów) i często trzeba je ustawić tylko wtedy, gdy chcesz je wyłączyć. W przypadku zestawu .NET SDK odwrotnie jest prawda. W przypadku każdej właściwości, która nie jest jawnie ustawiona, ustawieniem domyślnym jest wyłączenie odpowiedniego zachowania wyszukiwania, chyba że zostanie ona w szczególności włączona.

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, wykonywać zapytania dotyczące jego zawartości, monitorować jego rozmiar i zarządzać pojemnością, ale klastry (indeksy, fragmenty i inne pliki i foldery) są zarządzane wewnętrznie przez firmę Microsoft.

Rozmiar indeksu można monitorować na karcie Indeksy w witrynie Azure Portal lub wysyłając żądanie GET INDEX względem usługi wyszukiwania. Możesz również wydać żądanie statystyki usługi i sprawdzić wartość rozmiaru magazynu.

Rozmiar indeksu jest określany przez:

• Ilość i kompozycja dokumentów
• Atrybuty w poszczególnych polach
• Konfiguracja indeksu (w szczególności niezależnie od tego, czy uwzględniasz sugestory)

Kompozycja i ilość dokumentów są określane przez wybrane opcje importowania. Pamiętaj, że indeks wyszukiwania powinien zawierać tylko zawartość z możliwością wyszukiwania. Jeśli dane źródłowe zawierają pola binarne, pomiń te pola, chyba że używasz wzbogacania sztucznej inteligencji do łamania i analizowania zawartości w celu utworzenia informacji z możliwością wyszukiwania tekstu.

Atrybuty pól określają zachowania. Aby obsługiwać te zachowania, proces indeksowania tworzy niezbędne struktury danych. Na przykład dla pola typu Edm.String"wyszukiwanie" wywołuje wyszukiwanie pełnotekstowe, które skanuje odwrócone indeksy dla tokenizowanego terminu. Natomiast atrybut "filtrowalny" lub "sortowalny" obsługuje iterację w niezmodyfikowanych ciągach. W przykładzie w następnej sekcji przedstawiono odmiany rozmiaru indeksu na podstawie wybranych atrybutów.

Sugestory to konstrukcje, które obsługują zapytania typu z wyprzedzeniem lub autouzupełniania. W związku z tym po dołączeniu sugestora proces indeksowania tworzy struktury danych niezbędne do dopasowania znaków dosłownych. Sugestory są implementowane na poziomie pola, dlatego wybieraj tylko te pola, które są uzasadnione dla typu z wyprzedzeniem.

Przykład pokazujący implikacje magazynu atrybutów i sugestorów

Poniższy zrzut ekranu przedstawia wzorce magazynu indeksów wynikające z różnych kombinacji atrybutów. Indeks jest oparty na przykładowym indeksie nieruchomości, który można łatwo utworzyć za pomocą kreatora importu danych i wbudowanych przykładowych danych. Chociaż schematy indeksu nie są wyświetlane, można wywnioskować atrybuty na podstawie nazwy indeksu. Na przykład indeks realestate-searchable ma zaznaczony atrybut "z możliwością wyszukiwania" i nic innego, indeks realestate-retrievable ma wybrany atrybut "pobieranie" i nic innego i tak dalej.

Chociaż te warianty indeksu są nieco sztuczne, możemy odwoływać się do nich w celu szerokiego porównania wpływu atrybutów na magazyn:

• "Pobieranie" nie ma wpływu na rozmiar indeksu.
• "filtrowalne", "sortowalne", "facetable" zużywają więcej miejsca w magazynie.
• Sugestor ma duży potencjał zwiększania rozmiaru indeksu, ale nie tak samo, jak na zrzucie ekranu (wybrano wszystkie pola, które mogłyby zostać rozpoznane sugerowanie, co nie jest prawdopodobnym scenariuszem w większości indeksów).

Również nie odzwierciedlane w poprzedniej tabeli jest efektem analizatorów. Jeśli używasz tokenizera edgeNgram do przechowywania dosłownych sekwencji znaków (a, ab, abc, abcd), indeks jest większy niż w przypadku używania analizatora standardowego.

Podstawowe operacje i interakcja

Teraz, gdy już wiesz, czym jest indeks, w tej sekcji przedstawiono operacje czasu wykonywania indeksu, w tym nawiązywanie połączenia z pojedynczym indeksem i zabezpieczanie go.

Uwaga

Podczas zarządzania indeksem należy pamiętać, że nie ma żadnej obsługi portalu ani interfejsu API do przenoszenia lub kopiowania indeksu. Zamiast tego klienci zazwyczaj wskazują swoje rozwiązanie wdrażania aplikacji w innej usłudze wyszukiwania (jeśli używasz tej samej nazwy indeksu) lub popraw nazwę, aby utworzyć kopię w bieżącej usłudze wyszukiwania, a następnie skompilować ją.

Izolacja indeksu

W usłudze Azure AI Search pracujesz z jednym indeksem naraz, gdzie wszystkie operacje związane z indeksem są przeznaczone dla 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 będzie w pełni operacyjny, dopóki wszystkie dokumenty nie zostaną zindeksowane. Wewnętrznie indeks wyszukiwania jest dystrybuowany między partycjami i wykonywany na replikach. Indeks fizyczny jest zarządzany wewnętrznie. Indeks logiczny jest zarządzany przez Użytkownika.

Indeks jest stale dostępny, bez możliwości wstrzymania ani przełączenie go w tryb offline. Ponieważ jest ona przeznaczona do ciągłej operacji, wszelkie aktualizacje zawartości lub dodatki do samego indeksu są wykonywane w czasie rzeczywistym. W związku z tym zapytania mogą tymczasowo zwracać niekompletne wyniki, jeśli żądanie zbiega się z aktualizacją dokumentu.

Zwróć uwagę, że ciągłość zapytań istnieje dla operacji dokumentu (odświeżanie lub usuwanie) oraz modyfikacji, które nie mają wpływu na istniejącą strukturę i integralność bieżącego indeksu (na przykład dodawanie nowych pól). Jeśli konieczne jest wprowadzenie aktualizacji strukturalnych (zmiana istniejących pól), są one zwykle zarządzane przy użyciu przepływu pracy upuszczania i ponownego kompilowania w środowisku deweloperskim lub przez utworzenie nowej wersji indeksu w usłudze produkcyjnej.

Aby uniknąć ponownego kompilowania indeksu, niektórzy klienci, którzy wprowadzą niewielkie zmiany, zdecydują się na "wersję" pola, tworząc nowe, które współistnieją obok poprzedniej wersji. Z czasem prowadzi to do oddzielonej zawartości w postaci przestarzałych pól lub przestarzałych definicji analizatora niestandardowego, zwłaszcza w indeksie produkcyjnym, który jest kosztowny do replikacji. Te problemy można rozwiązać w przypadku planowanych aktualizacji indeksu w ramach zarządzania cyklem życia indeksu.

Połączenie i zabezpieczenia punktu końcowego

Wszystkie żądania indeksowania i 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. Administracja prawa są wymagane dla tych operacji, dostępne za pośrednictwem administratora Klucze interfejsu API lub rola 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ń prawa odczytu są wystarczające i dostępne za pośrednictwem kluczy interfejsu API zapytań lub roli czytnika danych. W przypadku odświeżania danych wymagane są prawa administratora.

Jak nawiązać połączenie z usługą Azure AI Search

1. Zacznij od witryny Azure Portal. Subskrybenci platformy Azure lub osoba, która utworzyła usługę wyszukiwania, mogą zarządzać usługą wyszukiwania w witrynie Azure Portal. Subskrypcja platformy Azure wymaga uprawnień współautora lub wyższego uprawnienia do tworzenia lub usuwania usług. Ten poziom uprawnień jest wystarczający do pełnego zarządzania usługą wyszukiwania w witrynie Azure Portal.

2. Wypróbuj innych klientów, aby uzyskać dostęp programowy. Zalecamy przewodniki Szybki start dotyczące pierwszych kroków:

   • Szybki start: REST
   • Szybki start: zestawy SDK platformy Azure

Następne kroki

Praktyczne tworzenie indeksu można uzyskać przy użyciu niemal dowolnego przykładu lub przewodnika dotyczącego usługi Azure AI Search. Na początek możesz wybrać dowolny z przewodników Szybki start z spisu treści.

Warto jednak zapoznać się również z metodologiami ładowania indeksu z danymi. Strategie definicji indeksu i importowania danych są definiowane razem. Poniższe artykuły zawierają więcej informacji na temat tworzenia i ładowania indeksu.

• Tworzenie indeksu wyszukiwania
• Tworzenie magazynu wektorów
• Tworzenie aliasu indeksu
• Omówienie importowania danych
• Ładowanie indeksu