Lucene-querysyntaxis in Azure Cognitive Search

Bij het maken van query's kunt u kiezen voor de Lucene Query Parser-syntaxis voor gespecialiseerde queryformulieren: jokertekens, fuzzy zoekopdrachten, zoeken op nabijheid, reguliere expressies. Veel van de Lucene Query Parser-syntaxis wordt intact geïmplementeerd in Azure Cognitive Search, metuitzondering van bereikzoekingen die zijn samengesteld via $filter expressies.

Als u de volledige Lucene-syntaxis wilt gebruiken, stelt u het queryType in op 'full' en gebruikt u een queryexpressiepatroon voor jokertekens, fuzzy zoekopdrachten of een van de andere queryformulieren die worden ondersteund door de volledige syntaxis. In REST worden query-expressies opgegeven in de parameter van een zoekopdracht naar search documenten (REST API).

Voorbeeld (volledige syntaxis)

Het volgende voorbeeld is een zoekaanvraag die is samengesteld met behulp van de volledige syntaxis. In dit specifieke voorbeeld ziet u in-field search en term boosting. Er wordt naar hotels ge zoek waar het categorieveld de term 'budget' bevat. Documenten met de zin 'recent vernieuwd' worden hoger gerangschikt als gevolg van de term boostwaarde (3).

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

Hoewel deze parameter niet specifiek is voor een querytype, searchMode is deze in dit voorbeeld relevant. Wanneer operators zich op de query, moet u over het algemeen instellen om ervoor te zorgen searchMode=all dat aan alle criteria wordt voldaan.

Zie Lucene query syntax examples (Voorbeelden van Lucene-querysyntaxis) voor aanvullende voorbeelden. Zie Documenten zoeken (REST API)voor meer informatie over de queryaanvraag en parameters, waaronder searchMode.

Basisprincipes van syntaxis

De volgende syntaxisprincipes zijn van toepassing op alle query's die gebruikmaken van de Lucene-syntaxis.

Evaluatie van operatoren in context

Plaatsing bepaalt of een symbool wordt geïnterpreteerd als een operator of gewoon een ander teken in een tekenreeks.

In de volledige Lucene-syntaxis wordt de tilde (~) bijvoorbeeld gebruikt voor zoeken bij fuzzy zoekopdrachten en zoeken op nabijheid. Wanneer ~ na een aangehaalde zin wordt geplaatst, roept ~ zoeken op nabijheid aan. Wanneer deze aan het einde van een term wordt geplaatst, roept ~ fuzzy zoekopdrachten aan.

Binnen een term, zoals 'business~analyst', wordt het teken niet geëvalueerd als operator. In dit geval, ervan uitgaande dat de query een term of woordgroepenquery is, wordt de ~ door zoeken in volledige tekst met lexicale analyse ontslist en wordt de term 'business~analyst' in twee: bedrijfsanalist of analist.

Het bovenstaande voorbeeld is de tilde (~), maar hetzelfde principe is van toepassing op elke operator.

Escape-tekens voor speciale tekens

Als u een van de zoekoperators wilt gebruiken als onderdeel van de zoektekst, escapet u het teken door het voorvoegsel te plaatsen met één backslash ( \ ). Voor een zoekopdracht met jokertekens op , waarbij deel uitmaakt van de https:// :// querytekenreeks, geeft u bijvoorbeeld search=https\:\/\/* op. Op dezelfde manier kan een patroon met een telefoonnummer met een escape-nummer er als deze \+1 \(800\) 642\-7676 uitzien.

Speciale tekens waarvoor escape-tekens zijn vereist, zijn onder andere:
+ - & | ! ( ) { } [ ] ^ " ~ * ? : \ /

Notitie

Hoewel escape-tekens tokens bij elkaar houden, kan lexicale analyse tijdens het indexeren ze mogelijk stripen. Met de standaard Lucene Analyzer worden bijvoorbeeld woorden over afbreekstreedelen, witruimten en andere tekens afgebroken. Als u speciale tekens in de querytekenreeks nodig hebt, hebt u mogelijk een analysefunctie nodig die deze in de index behoudt. Enkele opties zijn analyses van natuurlijke taalvan Microsoft, waarmee afbreekstreeepte woorden behouden blijven, of een aangepaste analyse voor complexere patronen. Zie Gedeeltelijke termen, patronen en specialetekens voor meer informatie.

Onveilige en gereserveerde tekens in URL's coderen

Zorg ervoor dat alle onveilige en gereserveerde tekens zijn gecodeerd in een URL. #is bijvoorbeeld een onveilig teken omdat het een fragment/anker-id in een URL is. Het teken moet worden gecodeerd naar als %23 het wordt gebruikt in een URL. '&' en '=' zijn voorbeelden van gereserveerde tekens wanneer ze parameters scheidingstekens en waarden opgeven in Azure Cognitive Search. Zie RFC1738: Uniform Resource Locators (URL) voor meer informatie.

Onveilige tekens zijn " ` < > # % { } | \ ^ ~ [ ] . Gereserveerde tekens zijn ; / ? : @ = + & .

Booleaanse operators

U kunt Booleaanse operators insluiten in een queryreeks om de nauwkeurigheid van een overeenkomst te verbeteren. De volledige syntaxis ondersteunt naast tekenoperators ook tekstoperators. Geef altijd booleaanse tekstoperators (AND, OR, NOT) op in alle caps.

Tekstoperator Teken Voorbeeld Gebruik
AND &, + wifi + luxury Hiermee geeft u termen op die een overeenkomst moet bevatten. In het voorbeeld wordt met de query-engine naar documenten met zowel als wifi op zoek luxury gaan. Het plusteken ( + ) wordt gebruikt voor de vereiste termen. Stelt bijvoorbeeld dat beide termen ergens in het veld +wifi +luxury van één document moeten worden weergegeven.
OF | wifi | luxury Zoekt een overeenkomst wanneer een van beide term wordt gevonden. In het voorbeeld retourneert de query-engine overeenkomst op documenten met wifi of luxury beide. Omdat OR de standaardoperator voor combinatie is, kunt u deze ook weg laten, zodat wifi luxury dit het equivalent is van wifi | luxury .
NOT !, - wifi –luxury Retourneert overeenkomsten op documenten die de term uitsluiten. Zoekt bijvoorbeeld wifi –luxury naar documenten met de term , maar niet wifi luxury .

De parameter voor een queryaanvraag bepaalt of een term met de searchMode not-operator ANDed of ORed is met andere termen in de query (ervan uitgaande dat er geen operator of op de andere termen + | staat). Geldige waarden zijn any of all .

searchMode=any verhoogt het terughalen van query's door meer resultaten op te geven en wordt standaard - geïnterpreteerd als 'OR NOT'. Komt bijvoorbeeld overeen met documenten die de term bevatten of documenten wifi -luxury die niet de term wifi luxury bevatten.

searchMode=all verhoogt de precisie van query's door minder resultaten op te geven en wordt standaard geïnterpreteerd als 'EN NIET'. Komt bijvoorbeeld wifi -luxury overeen met documenten die de term bevatten en niet de term wifi 'luxe' bevatten. Dit is misschien wel een intuïtiever gedrag voor de - operator. Daarom moet u overwegen om te gebruiken in plaats van als u zoekopdrachten wilt optimaliseren voor precisie in plaats van terughalen, en Uw gebruikers gebruiken de operator vaak searchMode=all searchMode=any in - zoekopdrachten.

Houd bij het bepalen van searchMode een instelling rekening met de interactiepatronen van gebruikers voor query's in verschillende toepassingen. Gebruikers die informatie zoeken, nemen eerder een operator op in een query, in plaats van e-commercesites met meer ingebouwde navigatiestructuren.

U kunt een veldzoekbewerking definiëren met de syntaxis, waarbij de zoekexpressie één woord of een woordgroep kan zijn, of een complexere expressie tussen haakjes, eventueel met fieldName:searchExpression Booleaanse operators. Enkele voorbeelden zijn:

  • genre:jazz NOT history

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

Zorg ervoor dat u meerdere tekenreeksen tussen aanhalingstekens zet als u wilt dat beide tekenreeksen als één entiteit worden geëvalueerd. In dit geval zoekt u naar twee verschillende tekenreeksen in het artists veld.

Het veld dat is opgegeven in fieldName:searchExpression moet een veld searchable zijn. Zie Index maken voor meer informatie over hoe indexkenmerken worden gebruikt in velddefinities.

Notitie

Wanneer u veldzoekexpressie gebruikt, hoeft u de parameter niet te gebruiken, omdat voor elke veldzoekexpressie expliciet een searchFields veldnaam is opgegeven. U kunt de parameter echter nog steeds gebruiken als u een query wilt uitvoeren waarbij bepaalde onderdelen zijn gericht op een specifiek veld, en de rest kan worden toegepast op searchFields verschillende velden. De query zou bijvoorbeeld search=genre:jazz NOT history&searchFields=description alleen overeenkomen met het jazz genre veld, terwijl deze overeen zou komen NOT history met het description veld. De veldnaam in heeft altijd voorrang op de parameter . Daarom hoeven we in dit voorbeeld niet op te nemen fieldName:searchExpression searchFields in de parameter genre searchFields .

Bij fuzzy zoekopdrachten worden overeenkomsten gevonden in termen die een vergelijkbare constructie hebben, door een term uit te breiden tot het maximum van 50 termen die voldoen aan de afstandscriteria van twee of minder. Zie Fuzzy zoeken voor meer informatie.

Als u fuzzy zoekopdrachten wilt doen, gebruikt u het tilde~-symbool aan het einde van één woord met een optionele parameter, een getal tussen 0 en 2 (standaard), dat de bewerkingsafstand aangeeft. 'blue~' of 'blue~1' zou bijvoorbeeld 'blue', 'blue', 'blue' en 'glue' retourneren.

Fuzzy zoekopdrachten kunnen alleen worden toegepast op termen, niet op woordgroepen, maar u kunt de tilde aan elke term afzonderlijk in een meerdelige naam of woordgroep appen. 'Unviersty~ of~ 'Wsh~ ~ ' komt bijvoorbeeld overeen op 'University of Washington'.

Zoekopdrachten op nabijheid worden gebruikt om termen te vinden die zich dicht bij elkaar in een document bevinden. Voeg een tilde -symbool '~' toe aan het einde van een woordgroep, gevolgd door het aantal woorden dat de nabijheidsgrens maakt. Vindt bijvoorbeeld de termen hotel en luchthaven binnen 5 woorden van "hotel airport"~5 elkaar in een document.

Term boosting

Term boosting verwijst naar het hoger rangschikken van een document als het de boost-term bevat, ten opzichte van documenten die de term niet bevatten. Dit wijkt af van scoreprofielen omdat scoreprofielen bepaalde velden stimuleren in plaats van specifieke termen.

In het volgende voorbeeld ziet u de verschillen. Stel dat er een scoreprofiel is dat overeenkomsten verhoogt in een bepaald veld, bijvoorbeeld genre in het voorbeeld musicstoreindex. Term boosting kan worden gebruikt om bepaalde zoektermen verder te verbeteren dan andere. Zal bijvoorbeeld documenten die de zoektermen in het genreveld bevatten, een hoger niveau geven rock^2 electronic dan andere doorzoekbare velden in de index. Daarnaast worden documenten met de zoekterm steen hoger geclassificeerd dan de andere zoekterm elektronisch als gevolg van de term boostwaarde (2).

Als u een term wilt stimuleren, gebruikt u het symbool caret, ^, met een boostfactor (een getal) aan het einde van de term die u zoekt. U kunt ook zinnen verbeteren. Hoe hoger de boostfactor, des te relevanter is de term ten opzichte van andere zoektermen. De boostfactor is standaard 1. Hoewel de boostfactor positief moet zijn, kan deze kleiner zijn dan 1 (bijvoorbeeld 0,20).

Een zoekopdracht in een reguliere expressie vindt een overeenkomst op basis van patronen die geldig zijn onder Apache Lucene, zoals beschreven in de RegExp-klasse. In Azure Cognitive Search wordt een reguliere expressie tussen slashes / ingesloten.

Als u bijvoorbeeld documenten wilt zoeken met 'hotel' of 'hotel', geeft u /[mh]otel/ op. Zoekopdrachten in reguliere expressies worden afgestemd op enkele woorden.

Voor sommige hulpprogramma's en talen gelden aanvullende escape-tekenvereisten. Voor JSON worden tekenreeksen met een slash met een slash naar achteren voorzien van een escape-tekenreeks: 'microsoft.com/azure/' wordt de plek waar de reguliere expressie wordt gezet en is de tekenreeks met een slash met een search=/.*microsoft.com\/azure\/.*/ search=/.* <string-placeholder>.*/ microsoft.com\/azure\/ escape-tekenreeks.

U kunt algemeen herkende syntaxis gebruiken voor zoekopdrachten met jokertekens voor meerdere ( ) of * ? één ( ). Volledige Lucene-syntaxis biedt ondersteuning voor het overeenkomen van voorvoegsels, invoegsels en achtervoegsels.

Let op: de Lucene-queryparser ondersteunt het gebruik van deze symbolen met één term en niet met een woordgroep.

Type bevestigt Beschrijving en voorbeelden
Voorvoegsel Termfragment komt vóór * of ? . Een queryexpressie van search=alpha* retourneert bijvoorbeeld 'alfanumeriek' of 'alfabetisch'. Overeenkomende voorvoegsels worden ondersteund in zowel eenvoudige als volledige syntaxis.
Achtervoegsel Term fragment komt na * of , met een slash om de constructie te ? scheidingsteken. Retourneert search=/.*numeric./ bijvoorbeeld 'alfanumeriek'.
Infix Termfragmenten worden * omsluiten of ? . Retourneert search=/.non*al./ bijvoorbeeld 'niet-numeriek' en 'niet-numeriek'.

U kunt operators in één expressie combineren. Bijvoorbeeld overeenkomsten op 980?2* '98072-1222' en '98052-1234', waarbij overeenkomt met één (vereist) teken en overeenkomt met tekens met een willekeurige lengte ? * die volgen.

Voor het overeenkomen van achtervoegsels en invoegsels zijn de slash-scheidingstekens van de reguliere expressie / vereist. Over het algemeen kunt u bij het schrijven van code geen * of ? symbool als het eerste teken van een term, of binnen een term, zonder / de . In bepaalde hulpprogramma's, zoals Postman of Azure Portal, is escape ingebouwde en kunt u vaak een query uitvoeren zonder het scheidingsteken.

Notitie

Als regel is patroonmatching traag, dus misschien wilt u alternatieve methoden verkennen, zoals edge n-gram-tokenization die tokens maakt voor reeksen tekens in een term. Met n-gram-tokenisatie is de index groter, maar kunnen query's sneller worden uitgevoerd, afhankelijk van de constructie van het patroon en de lengte van de tekenreeksen die u indexeert.

Impact van een analyse op query's met jokertekens

Tijdens het parseren van query's worden query's die zijn geformuleerd als voorvoegsel, achtervoegsel, jokerteken of reguliere expressies zoals ze zijn doorgegeven aan de querystructuur, zodat lexicale analyse wordt overgeslagen. Overeenkomsten worden alleen gevonden als de index de tekenreeksen bevat in de indeling die door uw query wordt opgegeven. In de meeste gevallen hebt u tijdens het indexeren een analyse nodig die de tekenreeksintegriteit behoudt, zodat gedeeltelijke term- en patroonmatching slaagt. Zie Partial term search in Azure Cognitive Search query's voor meer informatie.

Denk aan een situatie waarin u mogelijk wilt dat de zoekquery 'terminat*' resultaten retourneert die termen bevatten als 'beëindigen', 'beëindiging' en 'beëindigd'.

Als u de lucene-analyse van en.lucene (Engels Lucene) zou gebruiken, zou er voor elke term een agressieve afsterfing worden toegepast. Zo worden 'terminate', 'termination', 'terminates' allemaal ge tokeniseerd naar het token 'termi' in uw index. Aan de andere kant worden termen in query's met jokertekens of fuzzy zoekopdrachten helemaal niet geanalyseerd. Er zijn dus geen resultaten die overeenkomen met de 'terminat*'-query.

Aan de andere kant zijn de Microsoft-analyses (in dit geval de en.microsoft analyzer) iets geavanceerder en gebruiken ze virtualisatie in plaats van een stemming. Dit betekent dat alle gegenereerde tokens geldige Engelse woorden moeten zijn. 'beëindigen', 'terminates' en 'termination' blijven bijvoorbeeld grotendeels in de index en zijn een voorkeurskeuze voor scenario's die veel afhankelijk zijn van jokertekens en fuzzy zoekopdrachten.

Query's met jokertekens en regex scoren

Azure Cognitive Search maakt gebruik van scores op basis van frequentie(TF-IDF)voor tekstquery's. Voor query's met jokertekens en regex waarbij het bereik van termen mogelijk breed kan zijn, wordt de frequentiefactor echter genegeerd om te voorkomen dat de rangschikking aftekent ten opzichte van overeenkomsten van zeldzamere termen. Alle overeenkomsten worden gelijk behandeld voor zoekopdrachten met jokertekens en regex.

Speciale tekens

In sommige gevallen wilt u mogelijk zoeken naar een speciaal teken, zoals een emoji ❤ of het teken '€'. In dergelijke gevallen moet u ervoor zorgen dat de analyzer die u gebruikt, deze tekens niet filtert. De standaardanalyse omzeilt veel speciale tekens, met uitzondering van deze van uw index.

Analyses die speciale tekens tokeniseren, omvatten de 'whitespace'-analyse, waarbij rekening wordt gehouden met tekenreeksen gescheiden door witruimten als tokens (zodat de '❤'-tekenreeks als een token wordt beschouwd). Ook zou een taalanalyse zoals de Microsoft English Analyzer ('en.microsoft') de tekenreeks '€' als token nemen. U kunt een analyse testen om te zien welke tokens er worden gegenereerd voor een bepaalde query.

Wanneer u Unicode-tekens gebruikt, moet u ervoor zorgen dat symbolen op de juiste wijze worden gesequenseerd in de query-URL (bijvoorbeeld voor '❤' gebruikt u de escapereeks %E2%9D%A4+ ). Postman doet deze vertaling automatisch.

Prioriteit (groeperen)

U kunt haakjes gebruiken om subquery's te maken, inclusief operators binnen de haakjes-instructie. Zoekt bijvoorbeeld motel+(wifi|luxury) naar documenten met de term 'kunt u' en 'wifi' of 'luxe' (of beide).

Veldgroepering is vergelijkbaar, maar het bereik van de groepering is beperkt tot één veld. In het veld hotelAmenities wordt bijvoorbeeld gezocht hotelAmenities:(gym+(wifi|pool)) naar "hotelAmenities" en "wifi", of "hotel" en "pool".

Limieten voor querygrootten

Er is een limiet voor de grootte van query's die u naar uw Azure Cognitive Search. U kunt met name uit 1024 -clausules (expressies gescheiden door AND, OR, etc.) komen. Er is ook een limiet van ongeveer 32 kB voor de grootte van elke afzonderlijke term in een query. Als uw toepassing zoekquery's programmatisch genereert, wordt u aangeraden deze zodanig te ontwerpen dat er geen query's van niet-gebonden grootte worden gegenereerd.

Zie ook