Indexy vyhledávání v Azure AI Vyhledávač

V Azure AI Vyhledávač je vyhledávací index prohledávatelný obsah vyhledávací služby, který je dostupný pro místní vyhledávač pro indexování, načítání agentů, fulltextové vyhledávání, vektorové vyhledávání, hybridní vyhledávání a filtrované dotazy. Index je definován schématem uloženým ve vyhledávací službě, přičemž příjem dat následuje jako druhý krok. Indexovaný obsah existuje ve vyhledávací službě kromě primárních externích úložišť dat, což je nezbytné pro dobu odezvy milisekund očekávaných v moderních vyhledávacích aplikacích. S výjimkou scénářů indexování řízeného vzdáleným agentem a indexerů se vyhledávací služba nikdy nepřipojí k externím zdrojovým datům ani k nim dotazuje.

Tento článek se zabývá klíčovými koncepty vytváření a správy indexu vyhledávání, včetně následujících:

• Obsah (dokumenty a schéma)
• Fyzická datová struktura
• Základní operace

Schéma indexu vyhledávání

V Azure AI Vyhledávač indexy obsahují vyhledávací dokumenty. Dokument je koncepčně jedna jednotka prohledávatelných dat v indexu. Prodejce může mít například dokument pro každý produkt, univerzita může mít dokument pro každou třídu, cestovní web může mít dokument pro každý hotel a cíl a tak dále. Mapování těchto konceptů na známé databázové ekvivalenty: index vyhledávání odpovídá tabulce a dokumenty jsou zhruba ekvivalentní řádkům v tabulce.

Tady je příklad toho, jak schéma indexu vypadá.

{
  "name": "name_of_index, unique across the service",
  "description" : "Health plan coverage for standard and premium plans for Northwind and Contoso employees.",
  "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 (only Edm.String fields can be keys) | false (default where applicable),
      "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 embedding models" (applies to vector fields of type Collection(Edm.Single)),
      "vectorSearchProfile": "name_of_vector_profile" (indexes can have many configurations but 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){ }
}

Kolekce fields je obvykle největší částí. Každé pole má název, datový typ a atributy, které určují využití v době dotazu.

Další prvky jsou sbalené kvůli stručnosti, ale následující odkazy obsahují podrobnosti:

• Navrhovací moduly podporují dotazy typu předběžného vyhledávání, jako je automatické dokončování.
• Skórovací profily se používají k ladění relevance.
• analyzátory se používají ke zpracování řetězců do tokenů podle lingvistických pravidel nebo jiných charakteristik podporovaných analyzátorem.
• corsOptions nebo vzdálené skriptování mezi zdroji (CORS) se používá pro aplikace, které vydává požadavky z různých domén.
• EncryptionKey konfiguruje dvojité šifrování citlivého obsahu v indexu.
• Sémantické konfiguruje sémantické přerovnání ve fulltextovém a hybridním vyhledávání.
• VectorSearch konfiguruje vektorová pole a dotazy.

Definice polí

Vyhledávací dokument je definován kolekcí fields v textu požadavku Vytvořit index. Potřebujete pole pro identifikaci dokumentu (klíče), ukládání prohledávatelného textu a polí pro podpůrné filtry, omezující vlastnosti a řazení. Můžete také potřebovat pole pro data, která uživatel nikdy neuvidí. Můžete například chtít pole pro ziskové marže nebo marketingové propagační akce, které můžete použít v bodovacím profilu k posílení skóre hledání.

Pokud jsou příchozí data hierarchická, můžete je znázorňovat v indexu jako komplexní typ, který se používá pro vnořené struktury. Ukázková datová sada, Hotels, znázorňuje složité typy pomocí adresy (Adresa obsahuje několik dílčích polí), která má vztah 1:1 s každým hotelem, a komplexní kolekci místností, kde je k jednotlivým hotelům přidruženo více místností.

Atributy pole

Atributy pole určují způsob použití pole, například jestli se používá v fulltextovém vyhledávání, fasetové navigaci, operacích řazení atd.

• Řetězcová pole jsou často označena jako searchable a retrievable.
• Pole používaná k zúžení nebo řazení výsledků hledání jsou označena jako sortable, filterablea facetable.

I když můžete nová pole přidat kdykoliv, jsou existující definice polí zamknuté v indexu po dobu jeho existence. Z tohoto důvodu vývojáři obvykle používají portál Azure k vytváření jednoduchých indexů, testování nápadů nebo použití stránek portálu Azure k vyhledání nastavení. Časté změny návrhu indexu jsou efektivnější, pokud budete postupovat pomocí kódu, aby bylo možné index snadno znovu sestavit.

Osvědčené postupy pro citlivá pole

Pokud pole obsahuje citlivé nebo důvěrné informace:

• Povolte pouze atributy pole vyžadované vaší aplikací, například searchable, filterablenebo facetable.
• Nakonfigurujte atributy polí explicitně místo toho, abyste se spoléhali na výchozí hodnoty rozhraní API nebo sady SDK.
• Nepředpokládáme, že vyloučení pole z výsledků dokumentu brání zpřístupnění prostřednictvím všech funkcí dotazu nebo formátů odpovědí.
• Před uložením citlivých informací do indexu vyhledávání zkontrolujte požadavky na aplikace a funkce.

Fyzická struktura a velikost

Ve Azure AI Vyhledávač je fyzická struktura indexu z velké části interní implementací. Můžete získat přístup ke schématu, načtení a dotazování jeho obsahu, monitorovat jeho velikost a spravovat její kapacitu. Microsoft ale spravuje infrastrukturu a fyzické datové struktury uložené ve vyhledávací službě.

Velikost indexu můžete monitorovat na stránce správy Search > Indexy na portálu Azure. Případně můžete vydat požadavek GET INDEX pro vyhledávací službu nebo žádost o statistiku služby a zkontrolovat hodnotu velikosti úložiště.

Velikost indexu je určena takto:

• Množství a složení dokumentů.
• Atributy na jednotlivých polích: Načitatelné nezatěžují index, ale filtrovatelné, řaditelné a fasetovatelné spotřebovávají více úložiště pro ukládání netokenizovaného textu.
• Konfigurace indexu Konkrétně bez ohledu na to, jestli zahrnete navrhovače nebo specializované analyzátory. Pokud použijete tokenizátor edgeNgram k ukládání doslovných sekvencí znaků (a, ab, abc, abcd), index je větší než při použití standardního analyzátoru.

Složení a množství dokumentů se určuje podle toho, co se rozhodnete importovat. Nezapomeňte, že index vyhledávání by měl obsahovat jenom obsah, který je užitečný pro vaši vyhledávací aplikaci. Pokud zdrojová data obsahují binární pole, vyloučíte tato pole, pokud nepoužíváte rozšiřování AI k prolomení a analýze obsahu za účelem vytvoření textově prohledávatelných informací.

Atributy pole určují chování. Aby bylo toto chování podporováno, proces indexování vytvoří potřebné datové struktury. Například pole typu Edm.String"prohledávatelné" vyvolá fulltextové vyhledávání, které prohledává invertované indexy pro tokenizovaný termín. Naproti tomu atribut "filterable" nebo "sortable" podporuje iteraci nad nemodifikovaným řetězcem.

Navrhovatelé jsou konstrukce, které podporují dotazy s předběžným zadáním nebo automatické dokončování. Pokud zahrnete sugestivní modul, proces indexování vytvoří datové struktury potřebné pro doslovné shody znaků. Návrhy se implementují na úrovni jednotlivých polí, takže zvolte pouze ta pole, která jsou rozumná pro automatické doplňování.

Základní operace a interakce

Nyní, když máte lepší představu o tom, co je index, tato část představuje operace indexu za běhu, včetně připojení k jednomu indexu a jeho zabezpečení.

Izolace indexu

V Azure AI Vyhledávač pracujete současně s jedním indexem. Všechny operace související s indexem cílí na jeden index. Neexistuje žádný koncept souvisejících indexů ani spojení nezávislých indexů pro indexování nebo dotazování.

Nepřetržitě dostupný

Index je okamžitě k dispozici pro dotazy hned po indexování prvního dokumentu, ale není plně funkční, dokud nebudou indexovány všechny dokumenty. Interně se index distribuuje mezi oddíly a spouští se na replikách. Fyzický index se spravuje interně. Logický index spravujete.

Index je nepřetržitě dostupný a nedá se pozastavit ani přecházet do offline režimu. Vzhledem k tomu, že je navržená pro průběžné operace, aktualizace obsahu a přidání samotného indexu probíhají v reálném čase. Pokud se požadavek shoduje s aktualizací dokumentu, můžou dotazy dočasně vrátit neúplné výsledky.

Kontinuita dotazů existuje pro operace dokumentů, jako je aktualizace nebo odstranění, a pro úpravy, které nemají vliv na existující strukturu nebo integritu indexu, například přidání nových polí. Strukturální aktualizace, jako je změna existujících polí, se obvykle spravují pomocí pracovního postupu vyřazení a opětovného sestavení ve vývojovém prostředí nebo vytvořením nové verze indexu v produkční službě.

Aby se zabránilo opětovnému sestavení indexu, někteří zákazníci, kteří provádějí malé změny, "verzují" pole vytvořením nového, které spoluexistuje s předchozí verzí. V průběhu času to vede k opomenutému obsahu prostřednictvím zastaralých polí a zastaralých definic uživatelských analyzátorů, zejména v produkčním indexu, jehož replikace je nákladná. Tyto problémy můžete vyřešit během plánovaných aktualizací indexu jako součást správy životního cyklu indexu.

Připojení koncového bodu a zabezpečení

Všechny požadavky na indexování a dotazy cílí na index. Koncové body jsou obvykle jedním z následujících způsobů:

Jak se připojit k indexu

1. Startujte pomocí portálu Azure a řídicího panelu vyhledávací služby.

2. Zkuste jiné klienty pro programový přístup. Pro první kroky doporučujeme rychlé starty:

   • Rychlý start: Připojení k vyhledávací službě
   • Rychlý začátek: REST
   • Rychlý průvodce: Fulltextové vyhledávání
   • Rychlý start: Agentní vyhledávání

Další kroky

Praktické zkušenosti s vytvářením indexu můžete získat pomocí téměř libovolné ukázky nebo návodu pro Azure AI Vyhledávač. Pro začátek můžete zvolit některý z úvodních návodů z nabídky obsahu.

Budete se ale také chtít seznámit s metodologiemi načítání indexu s daty. Definice indexu a strategie importu dat jsou definovány společně. Následující články obsahují další informace o vytváření a načítání indexu.

• Vytvoření indexu vyhledávání
• Aktualizace indexu
• Vytvoření úložiště vektorů
• Vytvoření aliasu indexu
• Přehled importu dat
• Načtení indexu