Lucene-frågesyntax i Azure Cognitive Search

  • Artikel
  • 11 minuter för att läsa

När du skapar frågor kan du välja Lucene Query Parser-syntaxen för specialiserade frågeformulär: jokertecken, fuzzy-sökning, närhetssökning, reguljära uttryck. En stor del 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 anges frågeuttryck i search parametern för en sökdokumentbegäran (REST API).

Exempel (fullständig syntax)

Följande exempel är en sökbegäran som har konstruerats med den fullständiga syntaxen. Det här exemplet visar fältsökning och termsökning. Den söker efter hotell där kategorifältet innehåller termen "budget". Dokument som innehåller frasen "nyligen uppsnad" rangordnas högre på grund 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, searchMode men är relevant i det här exemplet. När operatorer finns på frågan bör du vanligtvis ange searchMode=all för att se till att alla kriterier matchas.

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

Grunderna i syntax

Följande syntaxprinciper 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 den fullständiga Lucene-syntaxen 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ökningen. 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 operator. 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å: företag ELLER analytiker.

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

Undantag för specialtecken

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

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

Anteckning

Även om undantag håller ihop token kan lexikal analys under indexering ta bort dem. Till exempel kommer Lucene-standardanalysen att bryta 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. Några alternativ är Microsofts analysverktyg förnaturligt språk, som bevarar bindestreck eller ett anpassat analysverktyg 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. #är till exempel ett osäkert tecken eftersom det är ett fragment/ankar-ID i en URL. Tecknet måste vara kodat till om %23 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 versaler.

Textoperator Tecken Exempel Användning
AND &, + wifi + luxury Anger de termer som en matchning måste innehålla. I exemplet letar frågemotorn efter dokument som innehåller både wifi och luxury . Plustecknet ( + ) används för de termer som krävs. Anger till +wifi +luxury exempel att båda termerna måste visas någonstans i fältet i ett enda dokument.
ELLER | wifi | luxury Söker efter 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 eller båda. Eftersom OR är standardoperatorn för konsumtion kan du även lämna den utanför, så wifi luxury att motsvarar wifi | luxury .
NOT !, - wifi –luxury Returnerar matchningar för dokument som exkluderar termen. Söker till wifi –luxury exempel efter dokument som har termen men inte wifi luxury .

Parametern i en frågebegäran styr om en term med OPERATORN INTE är ANDed eller ORed med andra termer i frågan (förutsatt att det inte finns någon operator eller operator i searchMode + de andra | termerna). Giltiga värden är any eller all .

searchMode=any ökar återkallandet av frågor genom att inkludera fler resultat, och som - standard tolkas som "OR NOT". Matchar till wifi -luxury exempel dokument som antingen innehåller termen eller de som inte innehåller termen wifi luxury .

searchMode=all ökar precisionen för frågor genom att inkludera färre resultat och som standard tolkas som "AND NOT". Matchar till wifi -luxury exempel dokument som innehåller termen och inte innehåller termen wifi "lyx". Detta är utan tvekan ett mer intuitivt beteende för - operatören. Därför bör du överväga att använda i stället för om du vill optimera sökningar för precision i stället för träffsäkerhet, och användarna searchMode=all searchMode=any använder ofta - operatorn i sökningar.

När du bestämmer dig searchMode för en inställning bör du tänka på användarinteraktionsmönstren för frågor i olika program. Användare som söker efter information är mer troliga att inkludera en operatör i en fråga, i stället för e-handelswebbplatser som har mer inbyggda navigeringsstrukturer.

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

  • genre:zz NOT history

  • artists:("Miles Miles" "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ökning efter två distinkta konstnärer i artists fältet.

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

Anteckning

När du använder fältsökuttryck behöver du inte använda parametern eftersom varje searchFields fältsökuttryck uttryckligen har ett angivet fältnamn. Du kan dock fortfarande använda parametern 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 searchFields för flera fält. Frågan skulle till exempel search=genre:jazz NOT history&searchFields=description bara jazz matcha med genre fältet, medan den skulle matcha NOT history med description fältet. Fältnamnet som anges i har alltid företräde framför parametern, vilket är anledningen till att vi inte behöver inkludera i parametern i fieldName:searchExpression det searchFields här genre searchFields exemplet.

En fuzzy-sökning hittar matchningar i termer som har en liknande konstruktion och expanderar en term upp till högst 50 termer som uppfyller avståndskriterierna för två eller mindre. Mer information finns i Fuzzy search.

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

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

Närhetssökningar används för att hitta termer som är 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 "hotell" och "flygplats" inom 5 ord från varandra i ett dokument.

Termstärning

Termförstärkning syftar på att rangordna ett dokument högre om det innehåller den förstärkta 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 i stället för specifika termer.

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

För att öka en term använder du symbolen "^" med en boost-faktor (ett tal) i slutet av termen du söker. Du kan också höja frasen. Ju högre boost-faktor, desto mer relevant blir termen i förhållande till andra söktermer. Som standard är boost-faktorn 1. Även om boost-faktorn måste vara positiv kan den vara mindre än 1 (till exempel 0,20).

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

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

Vissa verktyg och språk medför ytterligare krav på escape-tecken. För JSON är strängar som innehåller ett snedstreck ryms med ett omvänt snedstreck: "microsoft.com/azure/" blir där ställer in det reguljära uttrycket och är strängen med ett snedstreck som hoppas search=/.*microsoft.com\/azure\/.*/ search=/.* <string-placeholder>.*/ microsoft.com\/azure\/ över.

Du kan använda allmänt igenkänd syntax för sökningar med flera ( ) eller ett * ( ? ) tecken. Fullständig Lucene-syntax stöder prefix-, infix- och suffixmatchning.

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 Termfragment kommer * före eller ? . Ett frågeuttryck av returnerar search=alpha* till exempel "alfanumeriskt" eller "alfabetiskt". Prefixmatchning stöds i både enkel och fullständig syntax.
Suffix Termfragment kommer * efter eller , med ett ? snedstreck för att avgränsa -konstruktionen. Returnerar till search=/.*numeric./ exempel "alfanumeriskt".
Infix Termfragment * omsluter eller ? . Returnerar till search=/.non*al./ exempel "icke-numeriska" och "ical".

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

Matchning av suffix och infix kräver snedstrecksavgränsare för / reguljära uttryck. När du skriver kod kan du i allmänhet inte använda en * eller ? som det första tecknet i en term, eller inom en term, utan / . I vissa verktyg, till exempel Postman eller Azure Portal, är undantag inbyggd och du kan ofta köra en fråga utan avgränsaren.

Anteckning

Som regel är mönstermatchningen långsam, så du kanske vill utforska alternativa metoder, till exempel n-gram-tokenisering för kant som skapar token för sekvenser av tecken i en term. Med n-gram-tokenisering blir indexet större, men frågor kan köras snabbare, beroende på mönstrets konstruktion och längden på de strängar som du indexerar.

Effekten av ett analysverktyg på jokerteckenfrågor

Under frågeparsning skickas frågor som formuleras som prefix, suffix, jokertecken eller reguljära uttryck som-är till frågeträdet, vilket kringgår lexikal analys. Matchningar hittas bara om indexet innehåller strängarna i det format som frågan anger. I de flesta fall behöver du ett analysverktyg 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 "avslutas".

Om du skulle använda analysatorn en.lucene (engelska Lucene) skulle det 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 som använder jokertecken eller fuzzy-sökning alls. Därför skulle det inte finnas några resultat som matchar frågan "terminat*".

På den andra sidan är Microsoft-analysverktygen (i det här fallet analysatorn en.microsoft) 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 är ett bättre alternativ för scenarier som är beroende av jokertecken och fuzzy-sökning.

Bedömning av jokertecken och regex-frågor

Azure Cognitive Search använder frekvensbaserad bedömning(TF-IDF)för textfrågor. Men för jokertecken- och regex-frågor där omfånget kan vara brett ignoreras frekvensfaktorn för att förhindra att rangordningen går mot matchningar från sällsyntare termer. Alla matchningar behandlas lika för jokertecken- och regex-sökningar.

Specialtecken

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

Analysverktyg som tokeniserar specialtecken inkluderar analysatorn för blanksteg, som tar hänsyn till alla teckensekvenser som avgränsas med blanksteg som token (så strängen "❤" anses vara en token). Dessutom skulle ett språkanalysverktyg som Microsoft English Analyzer ("en.microsoft") ta strängen "..."" som en token. Du kan testa ett analysverktyg för att se vilka token som genereras för en viss fråga.

När du använder Unicode-tecken kontrollerar du att symboler är korrekt rymmde i fråge-URL:en (till exempel för "❤" använder 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 efter dokument som innehåller termen "hotel" och antingen motel+(wifi|luxury) "Wifi" eller "lyx" (eller båda).

Fältgruppering är liknande men omfattar gruppering till ett enda fält. Du kan till hotelAmenities:(gym+(wifi|pool)) exempel söka i fältet "hotelAmenities" efter "hotel" och "wifi", eller "hotel" och "pool".

Storleksgränser för frågor

Det finns en gräns för storleken på frågor som du kan skicka till Azure Cognitive Search. Mer specifikt kan du ha högst 1 024 satser (uttryck avgränsade med AND, OR och så vidare). Det finns också en gräns på cirka 32 kB för storleken på en enskild term i en fråga. 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.

Se även