Partiell termsökning och mönster med specialtecken (bindestreck, jokertecken, regex, mönster)

Artikel
03/20/2024

En partiell termsökning refererar till frågor som består av termfragment, där du i stället för en hel term kanske bara har början, mitten eller slutet av termen (kallas ibland prefix, infix eller suffixfrågor). En partiell termsökning kan innehålla en kombination av fragment, ofta med specialtecken som bindestreck, bindestreck eller snedstreck som ingår i frågesträngen. Vanliga användningsfall är delar av ett telefonnummer, en URL, koder eller bindestreckade sammansatta ord.

Partiella termer och specialtecken kan vara problematiska om indexet inte har en token som representerar textfragmentet som du vill söka efter. Under den lexikala analysfasen av indexering (förutsatt att standardstandardanalysator) ignoreras specialtecken, sammansatta ord delas upp och blanksteg tas bort. Om du söker efter ett textfragment som ändrades under lexikal analys misslyckas frågan eftersom ingen matchning hittas. Tänk på det här exemplet: ett telefonnummer som +1 (425) 703-6214 (tokeniserat som "1", "425", "703", "6214") visas inte i en "3-62" fråga eftersom innehållet faktiskt inte finns i indexet.

Lösningen är att anropa en analysator under indexering som bevarar en fullständig sträng, inklusive blanksteg och specialtecken om det behövs, så att du kan inkludera blanksteg och tecken i frågesträngen. Med en hel, orkeniserad sträng kan mönstermatchning för "börjar med" eller "slutar med" frågor, där mönstret du anger kan utvärderas mot en term som inte transformeras av lexikal analys.

Om du behöver stöd för sökscenarier som anropar analyserat och icke-analyserat innehåll bör du överväga att skapa två fält i indexet, ett för varje scenario. Ett fält genomgår lexikal analys. Det andra fältet lagrar en intakt sträng med hjälp av en innehållsbevarande analysator som genererar helsträngstoken för mönstermatchning.

Om partiell termsökning

Azure AI Search söker efter hela tokeniserade termer i indexet och hittar ingen matchning på en partiell term om du inte inkluderar operatorer för jokerteckenplatshållare (* och ?) eller formaterar frågan som ett reguljärt uttryck.

Partiella termer anges med hjälp av följande tekniker:

Reguljära uttrycksfrågor kan vara valfritt reguljärt uttryck som är giltigt under Apache Lucene.
Jokerteckenoperatorer med prefixmatchning refererar till ett allmänt känt mönster som innehåller början av en term, följt av * eller ? suffixoperatorer, till exempel search=cap* matchning på "Cap'n Jack's Waterfront Inn" eller "Gacc Capital". Prefixmatchning stöds i både enkel och fullständig Lucene-frågesyntax.
Jokertecken med infix och suffixmatchning placerar * operatorerna och ? inuti eller i början av en term, och kräver syntax för reguljära uttryck (där uttrycket omges av snedstreck). Frågesträngen (search=/.*numeric.*/) returnerar till exempel resultat på "alfanumeriskt" och "alfanumeriskt" när suffix och infix matchar.

För reguljära uttryck, jokertecken och fuzzy-sökning används inte analysverktyg vid frågetillfället. För dessa frågeformulär, som parsern identifierar av förekomsten av operatorer och avgränsare, skickas frågesträngen till motorn utan lexikal analys. För dessa frågeformulär ignoreras analysatorn som anges i fältet.

Kommentar

När en partiell frågesträng innehåller tecken, till exempel snedstreck i ett URL-fragment, kan du behöva lägga till escape-tecken. I JSON är ett snedstreck / undantaget med ett bakåtsnedstreck \. search=/.*microsoft.com\/azure\/.*/ Därför är syntaxen för URL-fragmentet "microsoft.com/azure/".

Lösa problem med partiell/mönstersökning

När du behöver söka efter fragment, mönster eller specialtecken kan du åsidosätta standardanalysatorn med en anpassad analysator som fungerar under enklare tokeniseringsregler och behålla hela strängen i indexet.

Metoden ser ut så här:

Definiera ett andra fält för att lagra en intakt version av strängen (förutsatt att du vill analysera och icke-analyserad text vid frågetillfället)
Utvärdera och välj bland de olika analysverktyg som genererar token på rätt detaljnivå
Tilldela analysatorn till fältet
Skapa och testa indexet

1 – Skapa ett dedikerat fält

Analysverktyg avgör hur termer tokeniseras i ett index. Eftersom analysverktyg tilldelas per fält kan du skapa fält i indexet för att optimera för olika scenarier. Du kan till exempel definiera "featureCode" och "featureCodeRegex" för att stödja regelbunden fulltextsökning på den första och avancerad mönstermatchning på den andra. Analysverktygen som tilldelats varje fält avgör hur innehållet i varje fält tokeniseras i indexet.

{
  "name": "featureCode",
  "type": "Edm.String",
  "retrievable": true,
  "searchable": true,
  "analyzer": null
},
{
  "name": "featureCodeRegex",
  "type": "Edm.String",
  "retrievable": true,
  "searchable": true,
  "analyzer": "my_custom_analyzer"
},

2 – Ange en analysator

När du väljer en analysator som producerar heltermstoken är följande analysverktyg vanliga val:

Analyzer	Funktioner
språkanalysverktyg	Bevarar bindestreck i sammansatta ord eller strängar, vokalmutationer och verbformer. Om frågemönster innehåller bindestreck kan det vara tillräckligt att använda ett språkanalysverktyg.
Sökord	Innehållet i hela fältet tokeniseras som en enda term.
Blanksteg	Separerar endast på blanksteg. Termer som innehåller bindestreck eller andra tecken behandlas som en enda token.
anpassad analys	(rekommenderas) När du skapar en anpassad analys kan du ange både tokenizer- och tokenfiltret. De tidigare analysverktygen måste användas som de är. Med en anpassad analys kan du välja vilka tokenizers och tokenfilter som ska användas. En rekommenderad kombination är nyckelordstokeniseraren med ett gemenertokenfilter. Den inbyggda nyckelordsanalysatorn ger i sig inte gemener och versaler, vilket kan leda till att frågor misslyckas. En anpassad analysator ger dig en mekanism för att lägga till filtret för gemenertoken.

Med hjälp av en REST-klient kan du lägga till REST-anropet testanalys för att inspektera tokeniserade utdata.

Indexet måste finnas i söktjänsten, men det kan vara tomt. Med tanke på ett befintligt index och ett fält som innehåller bindestreck eller partiella termer kan du prova olika analysverktyg över specifika termer för att se vilka token som genereras.

Kontrollera först standardanalysatorn för att se hur termerna tokeniseras som standard.
```
{
"text": "SVP10-NOR-00",
"analyzer": "standard"
}
```

Utvärdera svaret för att se hur texten tokeniseras i indexet. Observera hur varje term är gemener, bindestreck borttagna och delsträngar uppdelade i enskilda token. Endast de frågor som matchar dessa token returnerar det här dokumentet i resultatet. En fråga som innehåller "10-NOR" misslyckas.

{
    "tokens": [
        {
            "token": "svp10",
            "startOffset": 0,
            "endOffset": 5,
            "position": 0
        },
        {
            "token": "nor",
            "startOffset": 6,
            "endOffset": 9,
            "position": 1
        },
        {
            "token": "00",
            "startOffset": 10,
            "endOffset": 12,
            "position": 2
        }
    ]
}

Ändra nu begäran så att den whitespace använder analysatorn eller keyword :
```
{
"text": "SVP10-NOR-00",
"analyzer": "keyword"
}
```
Den här gången består svaret av en enda token, versaler, med bindestreck bevarade som en del av strängen. Om du behöver söka efter ett mönster eller en partiell term, till exempel "10-NOR", har frågemotorn nu grunden för att hitta en matchning.
```
{

    "tokens": [
        {
            "token": "SVP10-NOR-00",
            "startOffset": 0,
            "endOffset": 12,
            "position": 0
        }
    ]
}
```

Viktigt!

Tänk på att frågeparsers ofta är gemener i ett sökuttryck när du skapar frågeträdet. Om du använder en analysator som inte använder gemener vid indexering och du inte får förväntade resultat kan det vara orsaken. Lösningen är att lägga till ett gemenertokenfilter enligt beskrivningen i avsnittet "Använd anpassade analysverktyg" nedan.

3 – Konfigurera en analysator

Oavsett om du utvärderar analysverktyg eller går vidare med en specifik konfiguration måste du ange analysatorn för fältdefinitionen och eventuellt konfigurera själva analysatorn om du inte använder en inbyggd analysator. När du byter analysverktyg behöver du vanligtvis återskapa indexet (släpp, återskapa och läsa in det igen).

Använda inbyggda analysverktyg

Inbyggda analysverktyg kan anges med namn på en analyzer egenskap för en fältdefinition, utan att det krävs någon extra konfiguration i indexet. I följande exempel visas hur du ställer in analysatorn whitespace på ett fält.

Andra scenarier och mer information om andra inbyggda analysverktyg finns i Inbyggda analysverktyg.

    {
      "name": "phoneNumber",
      "type": "Edm.String",
      "key": false,
      "retrievable": true,
      "searchable": true,
      "analyzer": "whitespace"
    }

Använda anpassade analysverktyg

Om du använder en anpassad analysator definierar du den i indexet med en användardefinierad kombination av tokenizer, tokenfilter med möjliga konfigurationsinställningar. Referera sedan till den i en fältdefinition, precis som du skulle göra med en inbyggd analysator.

När målet är heltermstokenisering rekommenderas en anpassad analysator som består av en nyckelordstokeniserare och ett gemenertokenfilter.

Nyckelordstokeniseraren skapar en enda token för hela innehållet i ett fält.
Tokenfiltret med gemener omvandlar versaler till gemener. Frågeparsers brukar ge gemener och versaler textindata. Lägre hölje homogeniserar indata med de tokeniserade termerna.

I följande exempel visas en anpassad analysator som tillhandahåller nyckelordstokeniseraren och ett gemenertokenfilter.

{
"fields": [
  {
  "name": "accountNumber",
  "analyzer":"myCustomAnalyzer",
  "type": "Edm.String",
  "searchable": true,
  "filterable": true,
  "retrievable": true,
  "sortable": false,
  "facetable": false
  }
],

"analyzers": [
  {
  "@odata.type":"#Microsoft.Azure.Search.CustomAnalyzer",
  "name":"myCustomAnalyzer",
  "charFilters":[],
  "tokenizer":"keyword_v2",
  "tokenFilters":["lowercase"]
  }
],
"tokenizers":[],
"charFilters": [],
"tokenFilters": []
}

Kommentar

Tokenizer keyword_v2 - och lowercase tokenfiltret är kända för systemet och använder deras standardkonfigurationer, vilket är anledningen till att du kan referera till dem med namn utan att behöva definiera dem först.

4 – Skapa och testa

När du har definierat ett index med analysverktyg och fältdefinitioner som stöder ditt scenario läser du in dokument som har representativa strängar så att du kan testa partiella strängfrågor.

Använd en REST-klient för att fråga efter partiella termer och specialtecken som beskrivs i den här artikeln.

I föregående avsnitt beskrevs logiken. Det här avsnittet går igenom varje API som du bör anropa när du testar din lösning.

Ta bort index tar bort ett befintligt index med samma namn så att du kan återskapa det.
Skapa index skapar indexstrukturen i söktjänsten, inklusive analysverktygsdefinitioner och fält med en analysspecifikation.
Läs in dokument importerar dokument med samma struktur som ditt index, samt sökbart innehåll. Efter det här steget är ditt index redo att fråga eller testa.
Test Analyzer introducerades i Ange en analysator. Testa några av strängarna i ditt index med hjälp av olika analysverktyg för att förstå hur termer tokeniseras.
Sökdokument förklarar hur du skapar en frågebegäran med enkel syntax eller fullständig Lucene-syntax för jokertecken och reguljära uttryck.

För partiella termfrågor, till exempel att fråga "3-6214" för att hitta en matchning på "+1 (425) 703-6214", kan du använda den enkla syntaxen: search=3-6214&queryType=simple.

För infix- och suffixfrågor, till exempel att fråga "num" eller "numeriskt för att hitta en matchning i "alfanumeriskt", använder du den fullständiga Lucene-syntaxen och ett reguljärt uttryck: search=/.*num.*/&queryType=full

Justera frågeprestanda

Om du implementerar den rekommenderade konfigurationen som innehåller filtret keyword_v2 tokenizer och gemener kanske du ser en minskning av frågeprestanda på grund av extra tokenfilterbearbetning över befintliga token i ditt index.

I följande exempel läggs ett EdgeNGramTokenFilter till för att göra prefixmatchningar snabbare. Token genereras i kombinationer med 2–25 tecken som innehåller tecken. Här är ett exempel på progression från två till sju token: MS, MSF, MSFT, MSFT/, MSFT/S, MSFT/SQ, MSFT/SQL.

Extra tokenisering resulterar i ett större index. Om du har tillräckligt med kapacitet för att hantera det större indexet kan den här metoden med snabbare svarstid vara den bästa lösningen.

{
"fields": [
  {
  "name": "accountNumber",
  "analyzer":"myCustomAnalyzer",
  "type": "Edm.String",
  "searchable": true,
  "filterable": true,
  "retrievable": true,
  "sortable": false,
  "facetable": false
  }
],

"analyzers": [
  {
  "@odata.type":"#Microsoft.Azure.Search.CustomAnalyzer",
  "name":"myCustomAnalyzer",
  "charFilters":[],
  "tokenizer":"keyword_v2",
  "tokenFilters":["lowercase", "my_edgeNGram"]
  }
],
"tokenizers":[],
"charFilters": [],
"tokenFilters": [
  {
  "@odata.type":"#Microsoft.Azure.Search.EdgeNGramTokenFilterV2",
  "name":"my_edgeNGram",
  "minGram": 2,
  "maxGram": 25,
  "side": "front"
  }
]
}

Nästa steg

Den här artikeln förklarar hur analysverktyg både bidrar till frågeproblem och löser frågeproblem. Som ett nästa steg bör du titta närmare på analysverktyg som påverkar indexering och frågebearbetning.