Indexy vyhledávání ve službě Azure AI Search
Ve službě Azure AI Search je vyhledávací index váš prohledávatelný obsah dostupný pro vyhledávací web pro indexování, fulltextové vyhledávání, vektorové vyhledávání, hybridní vyhledávání a filtrované dotazy. Index je definován schématem a uloženým ve vyhledávací službě, přičemž import dat následuje jako druhý krok. Tento obsah existuje ve vaší vyhledávací službě kromě primární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ářů indexerů řízených indexováním se vyhledávací služba nikdy nepřipojí ke zdrojovým datům ani se na tato data dotazuje.
Pokud chcete vytvořit a spravovat index vyhledávání, pomůže vám tento článek porozumět následujícím bodům:
- Obsah (dokumenty a schéma)
- Fyzická datová struktura
- Základní operace
Radši se hned chytáte? Místo toho si přečtěte téma Vytvoření vyhledávacího indexu .
Schéma indexu vyhledávání
Ve službě Azure AI Search 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, tisková organizace může mít dokument pro každý článek, 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.
Struktura dokumentu je určena schématem indexu, jak je znázorněno v následujícím příkladu. Kolekce "fields" je obvykle největší částí indexu, kde se každé pole jmenuje, přiřadí datový typ a přiřazuje se s povoleným chováním, které určují, jak se používá.
{
"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){ }
}
Další prvky jsou sbalené kvůli stručnosti, ale následující odkazy obsahují podrobnosti:
- návrhy podporují dotazy typu dopředu, jako je automatické dokončování.
- Bodovacíprofiles 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é konfigurace sémantického řazení v fulltextu 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. Integrovaná ukázková datová sada Hotels znázorňuje složité typy pomocí adresy (obsahuje více podpolů), které mají vztah 1:1 s každým hotelem, a komplexní kolekci Rooms, 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čená jako prohledávatelná a "retrievable". Pole použitá k zúžení výsledků hledání zahrnují "sortable", "filterable" a "facetable".
| Atribut | Popis |
|---|---|
| "prohledávatelné" | Fulltextové nebo vektorové vyhledávání. Textová pole podléhají lexikální analýze, jako je například dělení slov během indexování. Pokud nastavíte prohledávatelné pole na hodnotu jako "slunečný den", interně se rozdělí na jednotlivé tokeny "slunečný" a "den". Podrobnosti najdete v článku Jak funguje fulltextové vyhledávání. |
| "filtrovatelné" | Odkazované v dotazech $filter. Filtrovatelná pole typu Edm.String nebo Collection(Edm.String) neprocházejí dělením slov, takže porovnání jsou určená jenom pro přesné shody. Pokud například nastavíte takové pole f na "slunečný den", $filter=f eq 'sunny' nenajde žádné shody, ale $filter=f eq 'sunny day' bude. |
| "seřaditelné" | Ve výchozím nastavení systém řadí výsledky podle skóre (bodů), můžete ale nakonfigurovat řazení na základě polí v dokumentech. Pole typu Collection(Edm.String) nemohou být seřazená. |
| "facetable" | Obvykle se používá v prezentaci výsledků hledání, která obsahuje počet nalezených položek podle kategorie (například hotely v konkrétním městě). Tuto možnost nelze použít s poli typu Edm.GeographyPoint. Pole typu Edm.String , která jsou filtrovatelná, "řaditelná" nebo "facetable" můžou mít maximálně 32 kilobajtů. Podrobnosti najdete v článku Vytvoření indexu (REST API). |
| "key" | Jedinečný identifikátor pro dokumenty v indexu. Jako pole key se musí zvolit právě jedno pole a musí být typu Edm.String. |
| "retrievable" | Určuje, jestli může být pole vrácené ve výsledku hledání. To je užitečné, když chcete použít pole (například zisková marže) jako filtr, řazení nebo bodovací mechanismus, ale nechcete, aby bylo pole viditelné pro koncového uživatele. Tento atribut musí být true pro pole typu key. |
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 k vytváření jednoduchých indexů, testování nápadů nebo k vyhledání nastavení pomocí stránek portálu. Časté změny návrhu indexu jsou efektivnější, pokud budete postupovat pomocí kódu, aby bylo možné index snadno znovu sestavit.
Poznámka:
Rozhraní API, která používáte k sestavení indexu, mají různá výchozí chování. U rozhraní REST API je ve výchozím nastavení povolená většina atributů (například "prohledávatelné" a "načítání" platí pro pole řetězců) a často je stačí nastavit jenom v případě, že je chcete vypnout. Pro sadu .NET SDK platí opak. U jakékoli vlastnosti, kterou explicitně nenastavíte, je výchozím nastavením zakázat odpovídající chování hledání, pokud ho výslovně nepovolíte.
Fyzická struktura a velikost
Ve službě Azure AI Search je fyzická struktura indexu z velké části interní implementací. Ke svému schématu můžete přistupovat, dotazovat se na jeho obsah, monitorovat jeho velikost a spravovat kapacitu, ale samotné clustery (indexy, horizontální oddíly a další soubory a složky) spravuje Microsoft interně.
Velikost indexu můžete monitorovat na kartě Indexy na webu Azure Portal nebo vystavením požadavku GET INDEX vůči vyhledávací službě. Můžete také vydat žá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 pro jednotlivá pole
- Konfigurace indexu (konkrétně bez ohledu na to, jestli zahrnete návrhy)
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 pouze prohledávatelný obsah. Pokud zdrojová data obsahují binární pole, vynecháte tato pole, pokud nepoužíváte rozšiřování AI k prolomení a analýze obsahu, aby se vytvořily prohledávatelné informace pro text.
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ězci. Příklad v další části ukazuje varianty velikosti indexu na základě vybraných atributů.
Návrhy jsou konstrukce, které podporují dotazy typu dopředu nebo automatické dokončování. Pokud tedy zahrnete navrhujícího, proces indexování vytvoří datové struktury potřebné pro doslovné shody znaků. Návrhy se implementují na úrovni pole, takže zvolte pouze pole, která jsou pro typ rozumná.
Příklad demonstrující důsledky úložiště atributů a návrhy
Následující snímek obrazovky znázorňuje vzory úložiště indexů vyplývající z různých kombinací atributů. Index je založený na ukázkovém indexu nemovitostí, který můžete snadno vytvořit pomocí Průvodce importem dat a předdefinovaných ukázkových dat. I když se schémata indexu nezobrazují, můžete odvodit atributy na základě názvu indexu. Například index realestate-searchable má vybraný atribut "prohledávatelný" a nic jiného, realestate-retrievable index má vybraný atribut "retrievable" a nic jiného atd.
I když jsou tyto varianty indexů poněkud umělé, můžeme na ně odkazovat, abychom zjistili, jak atributy ovlivňují úložiště:
- "Retrievable" nemá žádný vliv na velikost indexu.
- "filterable", "sortable", "facetable" spotřebovávají větší úložiště.
- s návrhem má velký potenciál pro zvětšení velikosti indexu, ale ne tolik, jako by to na snímku obrazovky značilo (všechna pole, která by mohla být vybrána pro návrhy, což není pravděpodobně scénář ve většině indexů).
V předchozí tabulce se také neprojeví účinek analyzátorů. 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.
Základní operace a interakce
Teď, když máte lepší představu o tom, co je index, představuje tato část operace běhu indexu, včetně připojení a zabezpečení jednoho indexu.
Poznámka:
Při správě indexu mějte na paměti, že neexistuje žádná podpora portálu nebo rozhraní API pro přesun nebo kopírování indexu. Místo toho zákazníci obvykle nasměrují řešení nasazení aplikace na jinou vyhledávací službu (pokud používá stejný název indexu) nebo název revidují tak, aby vytvořili kopii v aktuální vyhledávací službě, a pak ji sestavili.
Izolace indexu
Ve službě Azure AI Search pracujete s jedním indexem najednou, kde 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 nebude plně funkční, dokud nebudou indexovány všechny dokumenty. Interně se index vyhledávání distribuuje mezi oddíly a spouští se na replikách. Fyzický index se spravuje interně. Logický index spravujete vy.
Index je nepřetržitě dostupný a není možné ho pozastavit nebo převést do offline režimu. Vzhledem k tomu, že je určená pro průběžné operace, probíhají všechny aktualizace obsahu nebo přidání samotného indexu v reálném čase. V důsledku toho můžou dotazy dočasně vrátit neúplné výsledky, pokud se požadavek shoduje s aktualizací dokumentu.
Všimněte si, že kontinuita dotazů existuje pro operace dokumentů (aktualizace nebo odstranění) a pro úpravy, které neovlivňují stávající strukturu a integritu aktuálního indexu (například přidání nových polí). Pokud potřebujete provést strukturální aktualizace (změna existujících polí), ty 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, zvolí pole "verze" vytvořením nového, který společně s předchozí verzí existuje. V průběhu času to vede k osamocenému obsahu ve formě zastaralých polí nebo zastaralých definic vlastních analyzátorů, zejména v produkčním indexu, který je nákladný k replikaci. Tyto problémy můžete vyřešit u plánovaných aktualizací indexu v rámci 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ů:
| Koncový bod | Připojení ion a řízení přístupu |
|---|---|
<your-service>.search.windows.net/indexes |
Cílí na kolekci indexů. Používá se při vytváření, výpisu nebo odstraňování indexu. Správa práva k těmto operacím jsou k dispozici prostřednictvím správce.Klíče rozhraní API nebo role Přispěvatel vyhledávání |
<your-service>.search.windows.net/indexes/<your-index>/docs |
Cílí na kolekci dokumentů jednoho indexu. Používá se při dotazování indexu nebo aktualizace dat. Pro dotazy jsou dostatečná práva ke čtení a jsou k dispozici prostřednictvím klíčů rozhraní API pro dotazy nebo role čtenáře dat. Pro aktualizaci dat jsou vyžadována práva správce. |
Jak se připojit ke službě Azure AI Search
Začněte s webem Azure Portal. Předplatitelé Azure nebo osoba, která vytvořila vyhledávací službu, může spravovat vyhledávací službu na webu Azure Portal. Předplatné Azure vyžaduje oprávnění přispěvatele nebo vyššího oprávnění k vytváření nebo odstraňování služeb. Tato úroveň oprávnění stačí k úplné správě vyhledávací služby na webu Azure Portal.
Zkuste jiné klienty pro programový přístup. Pro první kroky doporučujeme rychlé starty:
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 Search. Pro začátek můžete zvolit některý z rychlých startů z 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.