Dela via

Enkel frågesyntax i Azure AI Search

  • Artikel

För fulltextsökningsscenarier implementerar Azure AI Search två Lucene-baserade frågespråk, var och en justerad till en frågeparser. Simple Query Parser är standardvärdet. Den omfattar vanliga användningsfall och försök att tolka en begäran även om den inte är perfekt sammansatt. Den andra parsern är Lucene Query Parser och stöder mer avancerade frågekonstruktioner.

Den här artikeln är referensen till frågesyntaxen för den enkla frågeparsern.

Frågesyntax för båda parsarna gäller för frågeuttryck som skickas i parametern search för en frågebegäran, som inte ska förväxlas med OData-syntaxen, med dess egen syntax och regler för filter och orderby uttryck i samma begäran.

Även om den enkla parsern baseras på klassen Apache Lucene Simple Query Parser utesluter implementeringen i Azure AI Search fuzzy-sökning. Om du behöver fuzzy-sökning bör du överväga den alternativa fullständiga Lucene-frågesyntaxen i stället.

Exempel (enkel syntax)

Det här exemplet visar en enkel fråga som skiljer sig "queryType": "simple" från och giltig syntax. Även om frågetypen anges nedan är det standardvärdet och kan utelämnas om du inte återgår från en alternativ typ. Följande exempel är en sökning över oberoende termer, med ett krav på att alla matchande dokument innehåller "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"
}

Parametern searchMode är relevant i det här exemplet. När booleska operatorer finns i frågan bör du vanligtvis ställa in searchMode=all så att alla villkor matchas. Annars kan du använda standardvärdet searchMode=any som gynnar återkallande framför precision.

Fler exempel finns i Exempel på enkel frågesyntax. Mer information om frågebegäran och parametrar finns i Sökdokument (REST API).

Nyckelordssökning på termer och fraser

Strängar som skickas till parametern search kan innehålla termer eller fraser på valfritt språk som stöds, booleska operatorer, prioritetsoperatorer, jokertecken eller prefixtecken för "börjar med"-frågor, escape-tecken och URL-kodningstecken. Parametern search är valfri. Ospecificerad, sök (search=* eller search=" ") returnerar de 50 översta dokumenten i godtycklig (orankad) ordning.

  • En termsökning är en fråga med en eller flera termer, där något av termerna betraktas som en matchning.

  • En frassökning är en exakt fras som omges av citattecken " ". Till exempel, medan Roach Motel (utan citattecken) skulle söka efter dokument som innehåller Roach och/eller Motel var som helst i valfri ordning, "Roach Motel" (med citattecken) matchar endast dokument som innehåller hela frasen tillsammans och i den ordningen (lexikal analys gäller fortfarande).

Beroende på din sökklient kan du behöva undvika citattecknen i en frassökning. I en POST-begäran kan till exempel en frassökning "Roach Motel" i begärandetexten anges som "\"Roach Motel\"". Om du använder Azure SDK:er kommer sökklienten att undvika citattecknen när söktexten serialiseras. Din sökfras kan skickas som "Roach Motel".

Som standard genomgår alla strängar som skickas i parametern search lexikal analys. Se till att du förstår tokeniseringsbeteendet för analysatorn som du använder. När frågeresultaten är oväntade kan orsaken ofta spåras till hur termer tokeniseras vid frågetillfället. Du kan testa tokenisering på specifika strängar för att bekräfta utdata.

Alla textindata med en eller flera termer anses vara en giltig startpunkt för frågekörning. Azure AI Search matchar dokument som innehåller någon eller alla termer, inklusive eventuella variationer som hittas under analysen av texten.

Hur enkelt det än låter finns det en aspekt av frågekörningen i Azure AI Search som kan ge oväntade resultat, vilket ökar i stället för att minska sökresultaten när fler termer och operatorer läggs till i indatasträngen. Om den här expansionen faktiskt sker beror på införandet av en NOT-operator, kombinerat med en searchMode parameterinställning som avgör hur NOT tolkas i termer av AND eller OR beteenden. Mer information finns i operatorn NOT under Booleska operatorer.

Booleska operatorer

Du kan bädda in booleska operatorer i en frågesträng för att förbättra precisionen för en matchning. I den enkla syntaxen är booleska operatorer teckenbaserade. Textoperatorer, till exempel ordet AND, stöds inte.

Tecken Exempel Förbrukning
+ pool + ocean En AND åtgärd. Stipulerar till exempel pool + ocean att ett dokument måste innehålla båda villkoren.
| pool | ocean En OR åtgärd hittar en matchning när någon av termerna hittas. I exemplet returnerar frågemotorn en matchning i dokument som innehåller antingen pool eller ocean båda. Eftersom OR är standardkonjunktionsoperatorn kan du också utelämna den, så att pool ocean den motsvarar pool | ocean.
- pool – ocean En NOT åtgärd returnerar matchningar för dokument som exkluderar termen.

Parametern searchMode för en frågebegäran styr om en term med operatorn NOT är ANDed eller ORed med andra termer i frågan (förutsatt att det inte finns några booleska operatorer på de andra termerna). Giltiga värden inkluderar any eller all.

searchMode=any ökar återkallandet av frågor genom att inkludera fler resultat och tolkas som standard - som "OR NOT". Till exempel pool - ocean matchar dokument som antingen innehåller termen pool eller de som inte innehåller termen ocean.

searchMode=all ökar precisionen för frågor genom att inkludera färre resultat och tolkas som standard - som "AND NOT". Med kommer frågan pool - ocean till exempel searchMode=anyatt matcha dokument som innehåller termen "pool" och alla dokument som inte innehåller termen "ocean". Detta är utan tvekan ett mer intuitivt beteende för operatorn - . Därför bör du överväga att använda searchMode=all i stället för searchMode=any om du vill optimera sökningar efter precision i stället för att återkalla, och Dina användare använder ofta operatorn - i sökningar.

När du bestämmer dig för en searchMode inställning bör du överväga användarinteraktionsmönster för frågor i olika program. Användare som söker efter information är mer benägna att inkludera en operatör i en fråga, till skillnad från e-handelswebbplatser som har fler inbyggda navigeringsstrukturer.

Prefixfrågor

För "börjar med"-frågor lägger du till en suffixoperator (*) som platshållare för resten av en term. En prefixfråga måste börja med minst ett alfanumeriskt tecken innan du kan lägga till suffixoperatorn.

Tecken Exempel Förbrukning
* lingui* kommer att matcha på "språklig" eller "linguini" Asterisken (*) representerar ett eller flera tecken med godtycklig längd och ignorerar skiftläge.

Precis som filter letar en prefixfråga efter en exakt matchning. Därför finns det ingen relevansbedömning (alla resultat får en sökpoäng på 1,0). Tänk på att prefixfrågor kan vara långsamma, särskilt om indexet är stort och prefixet består av ett litet antal tecken. En alternativ metod, till exempel tokenisering av gränsen n-gram, kan utföras snabbare. Termer som använder prefixsökning får inte vara längre än 1 000 tecken.

Enkel syntax stöder endast prefixmatchning. För suffix eller infixmatchning mot slutet eller mitten av en term använder du den fullständiga Lucene-syntaxen för jokerteckensökning.

Undfly sökoperatorer

I den enkla syntaxen innehåller sökoperatorerna följande tecken: + | " ( ) ' \

Om något av dessa tecken ingår i en token i indexet kan du undvika det genom att prefixa det med ett enda omvänt snedstreck (\) i frågan. Anta till exempel att du använde en anpassad analysator för hela termen tokenisering och att ditt index innehåller strängen "Luxury+Hotel". Om du vill få en exakt matchning på den här token infogar du ett escape-tecken: search=luxury\+hotel.

För att göra det enkelt för de mer typiska fallen finns det två undantag till den här regeln där det inte behövs att fly:

  • Operatorn - NOT behöver bara vara undantagen om det är det första tecknet efter ett blanksteg. Om visas - i mitten (till exempel i 3352CDD0-EF30-4A2E-A512-3B30AF40F3FD) kan du hoppa över att fly.

  • Suffixoperatorn * behöver bara vara undantagen om det är det sista tecknet före ett blanksteg. Om visas * i mitten (till exempel i 4*4=16) behövs ingen undflyende.

Kommentar

Som standard tar standardanalysatorn bort och bryter ord på bindestreck, blanksteg, et-tecken och andra tecken under lexikal analys. Om du behöver specialtecken kvar i frågesträngen kan du behöva en analysator som bevarar dem i indexet. Vissa alternativ inkluderar Microsofts analysverktyg för naturligt språk, som bevarar bindestreckade ord, eller en anpassad analysator för mer komplexa mönster. Mer information finns i Partiella termer, mönster och specialtecken.

Koda osäkra och reserverade tecken i URL:er

Se till att alla osäkra och reserverade tecken kodas i en URL. Till exempel är "#" ett osäkert tecken eftersom det är en fragment-/fästpunktsidentifierare i en URL. Tecknet måste kodas till %23 om det används i en URL. '&' och '=' är exempel på reserverade tecken eftersom de avgränsar parametrar och anger värden i Azure AI Search. Mer information finns i RFC1738: Uniform Resource Locators (URL).

Osäkra tecken är " ` < > # % { } | \ ^ ~ [ ]. Reserverade tecken är ; / ? : @ = + &.

Specialtecken

Specialtecken kan variera från valutasymboler som $eller €, till emojis. Många analysverktyg, inklusive standardanalysatorn, utesluter specialtecken under indexering, vilket innebär att de inte visas i ditt index.

Om du behöver specialteckenrepresentation kan du tilldela en analysator som bevarar dem:

  • Whitespace-analysatorn tar hänsyn till alla teckensekvenser avgränsade med blanksteg som token (så emojin "❤" skulle betraktas som en token).

  • Ett språkanalysverktyg, till exempel Microsoft English Analyzer (en.microsoft), skulle ta strängen $eller €som en token.

För bekräftelse kan du testa en analysator för att se vilka token som genereras för en viss sträng. Som du kan förvänta dig kanske du inte får fullständig tokenisering från en enda analysator. En lösning är att skapa flera fält som innehåller samma innehåll, men med olika analystilldelningar (till exempel description_en, description_froch så vidare för språkanalysverktyg).

När du använder Unicode-tecken kontrollerar du att symbolerna är korrekt undantagna i fråge-URL:en (till exempel för "❤" skulle använda escape-sekvensen %E2%9D%A4+). Vissa webbklienter gör den här översättningen automatiskt.

Prioritet (gruppering)

Du kan använda parenteser för att skapa underfrågor, inklusive operatorer i den parentesiska instruktionen. Söker till exempel motel+(wifi|luxury) efter dokument som innehåller termen "motell" och antingen "wifi" eller "lyx" (eller båda).

Begränsningar för frågestorlek

Om ditt program genererar sökfrågor programmatiskt rekommenderar vi att du utformar det på ett sådant sätt att det inte genererar frågor av obundna storlekar.

  • För GET får längden på URL:en inte överstiga 8 kB.

  • För POST (och andra begäranden), där brödtexten i begäran innehåller search och andra parametrar som filter och orderby, är den maximala storleken 16 MB. Ytterligare gränser är:

    • Söksatsens maximala längd är 100 000 tecken.
    • Det maximala antalet satser i search (uttryck avgränsade med AND eller OR) är 1024.
    • Den maximala söktermens storlek är 1 000 tecken för prefixsökning.
    • Det finns också en gräns på cirka 32 kB för storleken på en enskild term i en fråga.

Mer information om frågegränser finns i API-begärandebegränsningar.

Nästa steg

Om du ska skapa frågor programmatiskt kan du läsa Fullständig textsökning i Azure AI Search för att förstå stegen i frågebearbetningen och konsekvenserna av textanalys.

Du kan också läsa följande artiklar om du vill veta mer om frågekonstruktion: