Lucene-frågesyntax i Azure Cognitive Search

När du skapar frågor i Azure Cognitive Search kan du välja den fullständiga Lucene Query Parser-syntaxen för specialiserade frågeformulär: jokertecken, fuzzy-sökning, närhetssökning, reguljära uttryck. Mycket av Lucene Query Parser-syntaxen implementeras intakt i Azure Cognitive Search, med undantag för *intervallsökningar, som konstrueras via $filter uttryck.

Om du vill använda fullständig Lucene-syntax anger du queryType till "full" och skickar ett frågeuttryck med mönster för jokertecken, fuzzy-sökning eller något av de andra frågeformulär som stöds av den fullständiga syntaxen. I REST tillhandahålls frågeuttryck i parametern search för en REST API-begäran (Search Documents ).

Exempel (fullständig syntax)

I följande exempel skapas en sökbegäran med den fullständiga syntaxen. Det här exemplet visar sökning i fält och termförstärkning. Den söker efter hotell där kategorifältet innehåller termen "budget". Alla dokument som innehåller frasen "nyligen renoverad" rangordnas högre som ett resultat av termen boost-värde (3).

POST /indexes/hotels-sample-index/docs/search?api-version=2020-06-30
{
  "queryType": "full",
  "search": "category:budget AND \"recently renovated\"^3",
  "searchMode": "all"
}

Parametern är inte specifik för någon frågetyp, men den searchMode är relevant i det här exemplet. När operatorerna finns i frågan bör du vanligtvis ange searchMode=all så att alla kriterier matchas.

Fler exempel finns i Exempel på Lucene-frågesyntax. Mer information om frågebegäran och parametrar, inklusive searchMode, finns i Sök dokument (REST API).

Grunderna i syntax

Följande syntaxgrunder gäller för alla frågor som använder Lucene-syntaxen.

Operatorutvärdering i kontext

Placering avgör om en symbol tolkas som en operator eller bara ett annat tecken i en sträng.

I fullständig Lucene-syntax används till exempel tilde (~) för både fuzzy-sökning och närhetssökning. När den placeras efter en citerad fras anropar ~ närhetssökning. När den placeras i slutet av en term anropar ~ fuzzy-sökning.

Inom en term, till exempel "business~analyst", utvärderas inte tecknet som en operatör. I det här fallet, förutsatt att frågan är en term eller frasfråga, tar fulltextsökning med lexikal analys bort ~ och bryter termen "business~analyst" i två: affärs- eller analytiker.

Exemplet ovan är tilde (~), men samma princip gäller för varje operator.

Undantagna specialtecken

Om du vill använda någon av sökoperatorerna som en del av söktexten kan du undvika tecknet genom att prefixa det med ett enda omvänt snedstreck (\). Om du till exempel vill söka med jokertecken i https://, där :// är en del av frågesträngen, anger search=https\:\/\/*du . På samma sätt kan ett undantaget telefonnummermönster se ut så här \+1 \(800\) 642\-7676.

Specialtecken som kräver undantag omfattar följande:
+ - & | ! ( ) { } [ ] ^ " ~ * ? : \ /

Anteckning

Även om undantag håller samman token, kan lexikal analys under indexeringen ta bort dem. Lucene-standardanalyseraren bryter till exempel ord på bindestreck, blanksteg och andra tecken. Om du behöver specialtecken i frågesträngen kan du behöva ett analysverktyg som bevarar dem i indexet. Vissa alternativ är Microsoft analysverktyg för naturligt språk, som bevarar bindestreck 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 Cognitive Search. Mer information finns i RFC1738: Uniform Resource Locators (URL).

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

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. Den fullständiga syntaxen stöder textoperatorer utöver teckenoperatorer. Ange alltid text booleska operatorer (AND, OR, NOT) i alla versaler.

Textoperator Tecken Exempel Användning
AND + wifi AND luxury Anger villkor som en matchning måste innehålla. I exemplet söker frågemotorn efter dokument som innehåller både wifi och luxury. Plustecknet (+) kan också användas direkt framför en term för att göra det nödvändigt. Stipulerar till exempel +wifi +luxury att båda termerna måste visas någonstans i fältet för ett enda dokument.
ELLER (ingen) 1 wifi OR luxury Hittar en matchning när någon av termerna hittas. I exemplet returnerar frågemotorn matchning för dokument som innehåller antingen wifi eller luxury båda. Eftersom OR är standardkonjunktionsoperatorn kan du också utelämna den, så att wifi luxury motsvarar wifi OR luxury.
NOT !, - wifi –luxury Returnerar matchningar för dokument som exkluderar termen. Söker till exempel wifi –luxury efter dokument som har wifi termen men inte luxury.

Observera att OPERATORN NOT (NOT, !, eller -) beter sig annorlunda i fullständig syntax än i enkel syntax. I fullständig syntax kommer negationer alltid att andeds på frågan som wifi -luxury tolkas som "wifi AND NOT luxury" oavsett om parametern searchMode är inställd på any eller all. Detta ger dig ett mer intuitivt beteende för negationer som standard.

En enda negation, till exempel frågan -luxury , tillåts inte i fullständig söksyntax och returnerar alltid en tom resultatuppsättning.

1 Tecknet | stöds inte för OR-åtgärder.

Fältsökning

Du kan definiera en fältsökningsåtgärd med syntaxen fieldName:searchExpression , där sökuttrycket kan vara ett enda ord eller en fras, eller ett mer komplext uttryck inom parenteser, om du vill med booleska operatorer. Några exempel är följande:

  • genre:jazz NOT history

  • artists:("Miles Davis" "John Coltrane")

Se till att placera flera strängar inom citattecken om du vill att båda strängarna ska utvärderas som en enda entitet, i det här fallet söker du efter två distinkta artister i fältet artists .

Fältet som anges i fieldName:searchExpression måste vara ett searchable fält. Mer information om hur indexattribut används i fältdefinitioner finns i Skapa index .

Anteckning

När du använder fältsökuttryck behöver du inte använda parametern searchFields eftersom varje fältsökuttryck har ett fältnamn uttryckligen angivet. Du kan dock fortfarande använda parametern searchFields om du vill köra en fråga där vissa delar är begränsade till ett visst fält och resten kan gälla för flera fält. Frågan search=genre:jazz NOT history&searchFields=description skulle till exempel bara matcha jazz med fältet genre , medan den skulle matcha NOT history med fältet description . Fältnamnet som anges i fieldName:searchExpression har alltid företräde framför parametern searchFields , vilket är anledningen till att vi i det här exemplet inte behöver inkludera genre i parametern searchFields .

Fuzzy-sökning

En fuzzy-sökning hittar matchningar i termer som har en liknande konstruktion, vilket utökar en term upp till maximalt 50 termer som uppfyller avståndskriterierna för två eller mindre. Mer information finns i Fuzzy-sökning.

Om du vill göra en fuzzy-sökning använder du tilde-symbolen "~" i slutet av ett ord med en valfri parameter, ett tal mellan 0 och 2 (standard), som anger redigeringsavståndet. Till exempel skulle "blue~" eller "blue~1" returnera "blue", "blues" och "glue".

Fuzzy-sökning kan bara tillämpas på termer, inte fraser, men du kan lägga till tilde i varje term individuellt i ett namn eller en fras i flera delar. Till exempel skulle "Unviersty~ av~ "Wshington~" matcha på "University of Washington".

Närhetssökning

Närhetssökningar används för att hitta termer som finns nära varandra i ett dokument. Infoga en tilde-symbol "~" i slutet av en fras följt av antalet ord som skapar närhetsgränsen. Till exempel "hotel airport"~5 hittar termerna "hotel" och "airport" inom fem ord från varandra i ett dokument.

Termstär

Termhöjning syftar på att rangordna ett dokument högre om det innehåller den förbättrade termen, i förhållande till dokument som inte innehåller termen. Detta skiljer sig från bedömningsprofiler i att bedömningsprofiler ökar vissa fält snarare än specifika termer.

I följande exempel visas skillnaderna. Anta att det finns en bedömningsprofil som ökar matchningar inom ett visst fält, till exempel genren i exemplet musicstoreindex. Termförstärkning kan användas för att ytterligare öka vissa söktermer högre än andra. Till exempel rock^2 electronic ökar dokument som innehåller söktermer i genrefältet högre än andra sökbara fält i indexet. Dessutom kommer dokument som innehåller söktermstenen att rangordnas högre än den andra söktermen elektronisk som ett resultat av termen boost-värde (2).

Om du vill öka en term använder du cirkumflexen "^", med en ökningsfaktor (ett tal) i slutet av termen som du söker i. Du kan också höja fraserna. Ju högre ökningsfaktor, desto mer relevant blir termen i förhållande till andra söktermer. Som standard är boostfaktorn 1. Även om boostfaktorn måste vara positiv kan den vara mindre än 1 (till exempel 0,20).

Sökning efter reguljära uttryck

En sökning med reguljära uttryck hittar en matchning baserat på mönster som är giltiga under Apache Lucene, enligt beskrivningen i klassen RegExp. I Azure Cognitive Search omges ett reguljärt uttryck av mellan snedstreck /.

Om du till exempel vill hitta dokument som innehåller "motell" eller "hotell" anger du /[mh]otel/. Sökningar med reguljära uttryck matchas mot enstaka ord.

Vissa verktyg och språk ställer andra krav på escape-tecken. För JSON är strängar som innehåller ett snedstreck undantagna med ett bakåtsnedstreck: "microsoft.com/azure/" blir search=/.*microsoft.com\/azure\/.*/ där search=/.* <string-placeholder>.*/ konfigurerar det reguljära uttrycket och microsoft.com\/azure\/ är strängen med ett undantaget snedstreck.

Två vanliga symboler i regex-frågor är . och *. En . matchar ett tecken och ett * matchar det föregående tecknet noll eller flera gånger. Matchar till exempel /be./ termerna "bee" och "bet" medan /be*/ matchar "be", "bee" och "beee" men inte "bet". .* Tillsammans kan du matcha alla serier med tecken så /be.*/ att de matchar alla termerna som börjar med "vara" till exempel "bättre".

Sökning med jokertecken

Du kan använda allmänt erkänd syntax för flera (*) eller enstaka (?) jokerteckensökningar. Fullständig Lucene-syntax stöder matchning av prefix, infix och suffix.

Observera att Lucene-frågeparsern stöder användningen av dessa symboler med en enda term och inte en fras.

Affixtyp Beskrivning och exempel
Prefix Termfragmentet kommer före * eller ?. Ett frågeuttryck för search=alpha* returnerar till exempel "alfanumeriskt" eller "alfabetisk". Prefixmatchning stöds i både enkel och fullständig syntax.
Suffix Termfragmentet kommer efter * eller ?, med ett snedstreck för att avgränsa konstruktionen. Returnerar till exempel search=/.*numeric/ "alfanumeriskt".
Infix Termfragment omger * eller ?. Returnerar till exempel search=non*al "icke-numeriska" och "meningslösa".

Du kan kombinera operatorer i ett uttryck. Till exempel 980?2* matchar på "98072-1222" och "98052-1234", där ? matchar på ett enda (obligatoriskt) tecken och * matchar på tecken med en godtycklig längd som följer.

Suffixmatchning kräver snedstrecksavgränsare / för reguljära uttryck. I allmänhet kan du inte använda en * - eller ? -symbol som det första tecknet i en term utan /. Det är också viktigt att observera att kommer att * bete sig annorlunda när det används utanför regex-frågor. Utanför eller regex-avgränsare * för snedstreck / är ett jokertecken och matchar alla serier med tecken ungefär som .* i regex. Till exempel search=/non.*al/ genererar samma resultatuppsättning som search=non*al.

Anteckning

Som regel är mönstermatchning långsam, så du kanske vill utforska alternativa metoder, till exempel tokenisering med n-gram-gränsenheter som skapar token för sekvenser med tecken i en term. Med n-gram-tokenisering blir indexet större, men frågor kan köras snabbare, beroende på mönsterkonstruktionen och längden på de strängar som du indexerar. Mer information finns i Partiell termsökning och mönster med specialtecken.

Påverkan av ett analysverktyg på jokerteckenfrågor

Under frågeparsning skickas frågor som är formulerade som prefix, suffix, jokertecken eller reguljära uttryck som de är till frågeträdet, vilket kringgår lexikal analys. Matchningar hittas bara om indexet innehåller strängarna i det format som din fråga anger. I de flesta fall behöver du en analysator under indexeringen som bevarar strängintegriteten så att partiell term- och mönstermatchning lyckas. Mer information finns i Partiell termsökning i Azure Cognitive Search frågor.

Tänk dig en situation där du kanske vill att sökfrågan "terminat*" ska returnera resultat som innehåller termer som "avsluta", "avslutning" och "avslutar".

Om du skulle använda en.lucene-analysatorn (Engelska Lucene) skulle den tillämpa aggressiv ordstamsigenkänning för varje term. Till exempel kommer "avsluta", "avslutning", "avslutar" alla att tokeniseras ned till token "termi" i ditt index. Å andra sidan analyseras inte termer i frågor med jokertecken eller fuzzy-sökning alls. Därför skulle det inte finnas några resultat som skulle matcha frågan "terminat*".

Å andra sidan är Microsoft analysverktygen (i det här fallet en.microsoft analyzer) lite mer avancerade och använder lemmatisering i stället för att härstamma. Det innebär att alla genererade token ska vara giltiga engelska ord. Till exempel förblir "avsluta", "avslutar" och "avslutning" mestadels hela i indexet och skulle vara ett bättre val för scenarier som är mycket beroende av jokertecken och fuzzy-sökning.

Bedömning av jokertecken- och regex-frågor

Azure Cognitive Search använder frekvensbaserad bedömning (BM25) för textfrågor. Men för jokertecken- och regexfrågor där termer kan vara breda ignoreras frekvensfaktorn för att förhindra att rangordningen påverkar matchningar från mer sällsynta termer. Alla matchningar behandlas lika för sökningar med jokertecken och regex.

Specialtecken

I vissa fall kanske du vill söka efter ett specialtecken, till exempel en emoji ❤ eller tecknet €. I sådana fall ska du se till att analysatorn du använder inte filtrerar bort dessa tecken. Standardanalysatorn kringgår många specialtecken, exklusive dem från ditt index.

Analysverktyg som tokeniserar specialtecken inkluderar analysverktyg för "blanksteg", som tar hänsyn till alla teckensekvenser avgränsade med blanksteg som token (så strängen "❤" betraktas som en token). Dessutom skulle ett språkanalysverktyg som Microsoft engelska analysverktyg ("en.microsoft"), ta strängen "€" som en token. Du kan testa ett analysverktyg för att se vilka token den genererar för en viss fråga.

När du använder Unicode-tecken kontrollerar du att symbolerna är korrekt undantagna i fråge-URL:en (till exempel om "❤" skulle använda escape-sekvensen %E2%9D%A4+). Postman 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).

Fältgruppering är liknande men omfångsbegränsar gruppering till ett enda fält. Till exempel hotelAmenities:(gym+(wifi|pool)) söker fältet "hotelAmenities" efter "gym" och "wifi", eller "gym" och "pool".

Storleksgränser för frågor

Azure Cognitive Search begränsar frågestorleken och sammansättningen eftersom obundna frågor kan destabilisera söktjänsten. Det finns gränser för frågestorlek och sammansättning (antalet satser). Det finns också gränser för längden på prefixsökning och för komplexiteten i regex-sökning och sökning med jokertecken. 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 obegränsad storlek.

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

Se även