Jednoduchá syntaxe dotazů ve službě Azure AI Search

  • Článek

Pro scénáře fulltextového vyhledávání azure AI Search implementuje dva dotazovací jazyky založené na Lucene, přičemž každý z nich je zarovnaný k analyzátoru dotazů. Analyzátor jednoduchých dotazů je výchozí. Řeší běžné případy použití a snaží se interpretovat požadavek, i když není dokonale složený. Další analyzátor je Lucene Query Parser a podporuje pokročilejší konstrukce dotazů.

Tento článek je referenčními informacemi o syntaxi dotazu pro jednoduchý analyzátor dotazů.

Syntaxe dotazu pro oba analyzátory se vztahuje na výrazy dotazu předávané v search parametru požadavku dotazu, ne zaměňovat se syntaxí OData s vlastní syntaxí a pravidly pro filter výrazy orderby ve stejném požadavku.

I když je jednoduchý analyzátor založený na třídě Apache Lucene Simple Query Parser , její implementace ve službě Azure AI Search vylučuje přibližné vyhledávání. Pokud potřebujete přibližné vyhledávání, zvažte místo toho alternativní úplnou syntaxi dotazu Lucene.

Příklad (jednoduchá syntaxe)

Tento příklad ukazuje jednoduchý dotaz rozlišující "queryType": "simple" a platnou syntaxi. I když je typ dotazu nastavený níže, jedná se o výchozí hodnotu, kterou je možné vynechat, pokud se nevrátíte z alternativního typu. Následující příklad je hledání nezávislých termínů s požadavkem, aby všechny odpovídající dokumenty obsahovaly "pool".

POST https://{{service-name}}.search.windows.net/indexes/hotel-rooms-sample/docs/search?api-version=2024-07-01
{
  "queryType": "simple",
  "search": "budget hotel +pool",
  "searchMode": "all"
}

Parametr searchMode je v tomto příkladu relevantní. Vždy, když jsou v dotazu logické operátory, měli byste obecně nastavit searchMode=all , aby se zajistilo, že se shodují všechna kritéria. V opačném případě můžete použít výchozí nastavení searchMode=any , které upřednostňuje odvolání oproti přesnosti.

Další příklady najdete v příkladech syntaxe jednoduchých dotazů. Podrobnosti o požadavku a parametrech dotazu najdete v tématu Hledat dokumenty (REST API).

Hledání klíčových slov podle termínů a frází

Řetězce předané parametru search můžou obsahovat termíny nebo fráze v libovolném podporovaném jazyce, logických operátorech, operátorech priority, zástupných znacích nebo znacích předpony pro dotazy "začíná" a řídicími znaky a znaky kódování adresy URL. Parametr search je volitelný. Nezadané, vyhledávání (search=* nebo search=" ") vrátí prvních 50 dokumentů v libovolném pořadí (bez pořadí).

  • Hledání termínů je dotaz jednoho nebo více termínů, kde se některý z termínů považuje za shodu.

  • Hledání frází je přesná fráze uzavřená do uvozovek " ". Když by například Roach Motel (bez uvozovek) vyhledaly dokumenty, které obsahují Roach Motel nebo kdekoli v libovolném pořadí, "Roach Motel" (s uvozovkami) se budou shodovat pouze s dokumenty, které obsahují celou frázi společně a v tomto pořadí (lexikální analýza stále platí).

V závislosti na vašem vyhledávacím klientovi může být nutné uvozovky v hledání frází uvozovek. Například v požadavku POST může být zadáno vyhledávání "Roach Motel" frází v textu požadavku jako "\"Roach Motel\"". Pokud používáte sady Azure SDK, hledanému klientovi se při serializaci hledaného textu uvozovky zobrazí uvozovky. Vaše hledaná fráze může být odeslána jako "Roach Motel".

Ve výchozím nastavení všechny řetězce předané v parametru search procházejí lexikální analýzou. Ujistěte se, že rozumíte chování tokenizace analyzátoru, který používáte. Pokud jsou výsledky dotazů neočekávané, je často možné zjistit, jak se termíny v době dotazu tokenizují. Tokenizaci můžete otestovat u konkrétních řetězců , abyste potvrdili výstup.

Jakýkoli textový vstup s jedním nebo více termíny se považuje za platný výchozí bod pro provádění dotazu. Azure AI Search bude odpovídat dokumentům, které obsahují některé nebo všechny termíny, včetně všech variant nalezených během analýzy textu.

Stejně jednoduché jako tento zvuk existuje jeden aspekt provádění dotazů ve službě Azure AI Search, který může vést k neočekávaným výsledkům, což zvyšuje místo snížení výsledků hledání, protože do vstupního řetězce se přidávají další termíny a operátory. Zda k tomuto rozšíření skutečně dochází, závisí na zahrnutí operátoru NOT v kombinaci s nastavením parametru searchMode , který určuje, jak NENÍ interpretován z hlediska AND chování nebo OR chování. Další informace naleznete v operátoru NOT v části Logické operátory.

Logické operátory

Logické operátory můžete vložit do řetězce dotazu, abyste zlepšili přesnost shody. V jednoduché syntaxi jsou logické operátory založené na znakech. Textové operátory, například slovo AND, nejsou podporované.

Znak Příklad Využití
+ pool + ocean Operace AND . Například stanoví, pool + ocean že dokument musí obsahovat oba termíny.
| pool | ocean Operace OR najde shodu, když se najde některý z termínů. V tomto příkladu dotazovací modul vrátí shodu u dokumentů obsahujících buď pool nebo ocean obojí. Vzhledem k tomuOR, že je výchozí operátor spojení, můžete jej také vynechat, což pool ocean je ekvivalent .pool | ocean
- pool – ocean NOT Operace vrátí shodu u dokumentů, které termín vylučují.

Parametr searchMode požadavku na dotaz určuje, jestli je ANDtermín s NOT operátorem ed nebo ORs jinými termíny v dotazu (za předpokladu, že neexistují žádné logické operátory v ostatních termínech). Platné hodnoty zahrnují any nebo all.

searchMode=any zvyšuje úplnost dotazů zahrnutím dalších výsledků a ve výchozím nastavení - se interpretuje jako "NEBO NOT". Bude například pool - ocean odpovídat dokumentům, které obsahují termín pool , nebo dokumenty, které termín neobsahují ocean.

searchMode=all zvýší přesnost dotazů tím, že zahrne méně výsledků a ve výchozím nastavení - se interpretuje jako "A NE". Dotaz například searchMode=anypool - ocean bude odpovídat dokumentům, které obsahují termín "fond" a všechny dokumenty, které neobsahují termín "oceán". To je pravděpodobně intuitivnější chování operátora - . Proto byste místo toho měli zvážit použití searchMode=any searchMode=all, pokud chcete optimalizovat hledání s přesností místo úplnosti a uživatelé často operátor používají - při hledání.

Při rozhodování o searchMode nastavení zvažte vzory interakce uživatelů pro dotazy v různých aplikacích. Uživatelé, kteří hledají informace, budou pravděpodobně do dotazu zahrnout operátora, a ne na weby elektronického obchodování, které mají více předdefinovaných navigačních struktur.

Dotazy předpon

Pro dotazy "začíná" přidejte operátor přípony (*) jako zástupný symbol pro zbytek termínu. Před přidáním operátoru přípony musí dotaz předpony začínat alespoň jedním alfanumerickým znakem.

Znak Příklad Využití
* lingui* se bude shodovat s "lingvistií" nebo "linguini" Hvězdička (*) představuje jeden nebo více znaků libovolné délky a ignoruje malá a velká písmena.

Podobně jako filtry hledá dotaz předpony přesnou shodu. Proto neexistuje žádné vyhodnocování relevance (všechny výsledky obdrží skóre hledání 1,0). Mějte na paměti, že dotazy na předpony mohou být pomalé, zejména pokud je index velký a předpona se skládá z malého počtu znaků. Alternativní metodologie, jako je například tokenizace n-gramu edge, může být rychlejší. Termíny používající vyhledávání předpon nesmí být delší než 1 000 znaků.

Jednoduchá syntaxe podporuje pouze porovnávání předpon. Pro příponu nebo přiřazování párování na konci nebo uprostřed termínu použijte úplnou syntaxi Lucene pro vyhledávání se zástupnými znaménou znaménkem.

Escaping search operators

Operátory vyhledávání v jednoduché syntaxi obsahují tyto znaky: + | " ( ) ' \

Pokud některý z těchto znaků je součástí tokenu v indexu, uvozte ho předponou jediným zpětným lomítkem (\) v dotazu. Předpokládejme například, že jste použili vlastní analyzátor pro tokenizaci celého termínu a váš index obsahuje řetězec "Luxury+Hotel". Pokud chcete získat přesnou shodu s tímto tokenem, vložte řídicí znak: search=luxury\+hotel.

Aby se v případě typických případů zjednodušily, existují dvě výjimky tohoto pravidla, kdy není potřeba utéct:

  • Operátor - NOT musí být řídicí znak pouze v případě, že je prvním znakem za prázdným znakem. - Pokud se zobrazí uprostřed (například v 3352CDD0-EF30-4A2E-A512-3B30AF40F3FD), můžete přeskočit escaping.

  • Operátor * přípony musí být řídicí pouze v případě, že se jedná o poslední znak před prázdným znakem. * Pokud se zobrazí uprostřed (například v 4*4=16), není potřeba žádné eskapace.

Poznámka:

Ve výchozím nastavení standardní analyzátor odstraní a přeruší slova u spojovníků, prázdných znaků, ampersandů a dalších znaků během lexikální analýzy. Pokud potřebujete, aby v řetězci dotazu zůstaly speciální znaky, budete možná potřebovat analyzátor, který je zachová v indexu. Mezi volby patří analyzátory přirozeného jazyka Microsoftu, které zachová slova s dělením slov, nebo vlastní analyzátor pro složitější vzory. Další informace naleznete v části Částečné termíny, vzory a speciální znaky.

Kódování nebezpečných a rezervovaných znaků v adresách URL

Zajistěte, aby všechny nebezpečné a rezervované znaky byly kódovány v adrese URL. Znak #je například nebezpečný znak, protože se jedná o identifikátor fragmentu nebo ukotvení v adrese URL. Znak musí být kódován tak, aby %23 byl použit v adrese URL. '&' a '=' jsou příklady vyhrazených znaků, protože oddělují parametry a určují hodnoty ve službě Azure AI Search. Další informace najdete v tématu RFC1738: Uniform Resource Locators (URL) (Uniform Resource Locators).

Nebezpečné znaky jsou " ` < > # % { } | \ ^ ~ [ ]. Rezervované znaky jsou ; / ? : @ = + &.

Speciální znaky

Speciální znaky můžou být v rozsahu od symbolů měny, jako je $nebo €, až po emoji. Mnoho analyzátorů, včetně výchozího standardního analyzátoru, vyloučí během indexování speciální znaky, což znamená, že v indexu nebudou reprezentovány.

Pokud potřebujete speciální reprezentaci znaků, můžete přiřadit analyzátor, který je zachová:

  • Analyzátor prázdných znaků považuje za tokeny libovolnou posloupnost znaků oddělenou prázdnými znaky (takže emoji ❤ "' by se považovalo za token).

  • Analyzátor jazyka, jako je například Microsoft English Analyzer (en.microsoft), by jako token vzal řetězec $nebo €.

Pro potvrzení můžete otestovat analyzátor , abyste zjistili, jaké tokeny se pro daný řetězec vygenerují. Jak můžete očekávat, nemusíte z jednoho analyzátoru získat úplnou tokenizaci. Alternativním řešením je vytvořit více polí, která obsahují stejný obsah, ale s různými přiřazeními analyzátoru (například description_en, description_fratd. pro analyzátory jazyka).

Pokud používáte znaky Unicode, ujistěte se, že jsou symboly v adrese URL dotazu správně uchycené (například pro znak '❤' by používalo řídicí sekvenci %E2%9D%A4+). Někteří weboví klienti tento překlad dělají automaticky.

Priorita (seskupení)

K vytvoření poddotazů, včetně operátorů v závorkách, můžete použít závorky. Vyhledá například motel+(wifi|luxury) dokumenty obsahující termín "motel" a buď "wi-fi" nebo "luxury" (nebo obojí).

Omezení velikosti dotazů

Pokud vaše aplikace generuje vyhledávací dotazy prostřednictvím kódu programu, doporučujeme ho navrhnout tak, aby negenerovala dotazy s nevázanou velikostí.

  • V případě get nemůže délka adresy URL překročit 8 kB.

  • Pro POST (a jakýkoli jiný požadavek), kde text požadavku obsahuje search a další parametry, jako filter orderbya , maximální velikost je 16 MB. Mezi další omezení patří:

    • Maximální délka vyhledávací klauzule je 100 000 znaků.
    • Maximální počet klauzulí v search (výrazy oddělené operátorem AND nebo OR) je 1024.
    • Maximální velikost hledaného termínu je 1000 znaků pro hledání předpon.
    • Existuje také limit přibližně 32 kB velikosti libovolného jednotlivého termínu v dotazu.

Další informace o limitech dotazů najdete v tématu Omezení požadavků rozhraní API.

Další kroky

Pokud budete dotazy vytvářet programově, projděte si fulltextové vyhledávání ve službě Azure AI Search a seznamte se s fázemi zpracování dotazů a důsledky analýzy textu.

Další informace o konstrukci dotazů najdete také v následujících článcích: