Részleges kifejezéskeresés és minták speciális karakterekkel (kötőjelek, helyettesítő karakterek, regex, minták)

Megjegyzés

Azure AI Keresés a Azure portálon, REST API-kon és Azure SDK-k keresztül érhető el. Emellett a Foundry IQ-t is támogatja, amely a vállalati tartalmakat újrafelhasználható, engedélytudatos tudásbázisokká alakítja át az Microsoft Foundry portálon található ügynökök számára.

A részleges kifejezéskeresés olyan lekérdezéseket jelent, amelyek kifejezéstöredékekből állnak, ahol egy teljes kifejezés helyett csak a kifejezés eleje, közepe vagy vége található, illetve ezek előtag-, infix- vagy utótaglekérdezésekként is ismertek. A részleges kifejezéskeresés tartalmazhat töredékek kombinációját, gyakran speciális karakterekkel, például kötőjelekkel, gondolatjelekkel vagy perjelekkel, amelyek a lekérdezési sztring részét képezik. A gyakori használati esetek közé tartoznak a telefonszámok, URL-címek, kódok vagy kötőjeles összetett szavak részei.

A részleges kifejezések és speciális karakterek akkor lehetnek problémásak, ha az index nem rendelkezik a keresni kívánt szövegtöredéknek megfelelő jogkivonattal. A kulcsszóindexelés lexikális elemzési fázisában (feltételezve az alapértelmezett standard elemzőt) a speciális karakterek elvetése, az összetett szavak felosztása és a szóközök törlése történik. Ha a lexikális elemzés során módosított szövegrészletet keres, a lekérdezés meghiúsul, mert nem található egyezés. Vegyük ezt a példát: egy telefonszám, mint +1 (425) 703-6214 (tokenized as "1", "425", "703", "6214"), nem jelenik meg egy "3-62" lekérdezésben, mert ez a tartalom valójában nem szerepel az indexben.

A megoldás egy olyan elemző meghívása az indexelés során, amely megőrzi a teljes sztringet, szükség esetén szóközöket és speciális karaktereket is, hogy a szóközöket és karaktereket belefoglalhassa a lekérdezési sztringbe. A teljes, fel nem darabolt karakterlánc lehetővé teszi a "kezdődik" vagy "végződik" lekérdezések mintaegyeztetését, ahol a megadott minta kiértékelhető egy olyan kifejezéssel, amelyet nem alakít át lexikális elemzés.

Ha támogatnia kell az elemzett és nem elemzett tartalmakat hívó keresési forgatókönyveket, érdemes lehet létrehoznia két mezőt az indexben, egyet az egyes forgatókönyvekhez. Egy mező lexikális elemzésen megy keresztül. A második mező egy érintetlen karakterláncot tárol egy tartalommegőrző elemző használatával, amely teljes karakterlánc tokeneket bocsát ki a mintaillesztéshez.

Az Azure AI Keresés teljes jogkivonatos kifejezéseket keres az indexben, és nem talál egyezést részleges kifejezésen, kivéve, ha helyettesítő helyőrző operátorokat (* és ?) tartalmaz, vagy normál kifejezésként formázza a lekérdezést.

A részleges kifejezések a következő technikákkal vannak megadva:

  • A reguláris kifejezés-lekérdezések bármely olyan reguláris kifejezés lehetnek, amely az Apache Lucene alatt érvényes.

  • Az előtagegyeztetéssel rendelkező helyettesítő karakterek olyan általánosan felismert mintára utalnak, amely magában foglalja a kifejezés kezdetét, amelyet *? utótag-operátorok követnek, például search=cap* a "Cap'n Jack's Waterfront Inn" vagy a "Highline Capital" esetében. Az előtagok egyeztetése egyszerű és teljes Lucene lekérdezési szintaxisban is támogatott.

  • Wildcard karakterek infix és utótag egyezéssel a * és ? operátorokat egy kifejezésen belül vagy annak elején helyezik el, és reguláris kifejezés szintaxis szükséges (ahol a kifejezés perjelekkel van bezárva). Például a lekérdezési sztring (search=/.*numeric.*/) "alfanumerikus" és "alfanumerikus és alfabetikus" eredményt ad vissza utótag- és infix-egyezésként.

A reguláris kifejezés, a helyettesítő karakterek és a homályos keresés esetén az elemzők nem használhatók a lekérdezési időpontban. Ezen lekérdezési űrlapok esetében, amelyeket az elemző operátorok és elválasztók jelenlétével észlel, a rendszer lexikális elemzés nélkül továbbítja a lekérdezési sztringet a motornak. Ezen lekérdezési űrlapok esetében a mezőn megadott elemző figyelmen kívül lesz hagyva.

Megjegyzés

Ha egy részleges lekérdezési kifejezés karaktereket (például mint a perjelek) tartalmaz egy URL-töredékben, előfordulhat, hogy fel kell vennie a escape karaktereket. A JSON-ban az előre perjel / egy hátrafelé fordított perjellel \szökik meg. search=/.*microsoft.com\/azure\/.*/ Ezért a "microsoft.com/azure/" URL-töredék szintaxisa.

Mivel maga a lekérdezési kifejezés nincs elemezve, a szó szoros értelmében megfelel az indexnek, így egy ilyen Contoso* lekérdezés nulla eredményt ad vissza, ha az elemző kisbetűs indexelt tartalmat ad vissza. További információ: Az elemző hatása a helyettesítő karakterek lekérdezéseire.

Részleges és mintakeresési problémák megoldása

Ha töredékeket, mintákat vagy speciális karaktereket kell keresnie, felülbírálhatja az alapértelmezett elemzőt egy olyan egyéni elemzővel, amely egyszerűbb tokenizálási szabályok szerint működik, és megtartja a teljes sztringet az indexben.

A megközelítés a következőképpen néz ki:

  1. Adjon meg egy második mezőt a sztring eredeti változatának tárolására (feltéve, hogy a lekérdezési időben szüksége van az elemzett és az elemzés nélküli szövegre is).
  2. Értékelje ki és válassza ki azokat a különböző elemzőket, amelyek a megfelelő részletességi szinten bocsátanak ki tokeneket.
  3. Az elemző hozzárendelése a mezőhöz
  4. Az index létrehozása és tesztelése

1 – Dedikált mező létrehozása

Az elemzők határozzák meg, hogyan vannak tokenizálva a kifejezések egy indexben. Mivel az elemzők mezőnként vannak hozzárendelve, létrehozhat mezőket az indexben a különböző forgatókönyvekhez való optimalizáláshoz. Definiálhatja például a "featureCode" és a "featureCodeRegex" kifejezést, hogy támogassa a normál teljes szöveges keresést az elsőn, a másodikon pedig speciális mintaegyezést. Az egyes mezőkhöz rendelt elemzők határozzák meg, hogy az egyes mezők tartalma hogyan van tokenizálva az indexben.

{
  "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 – Elemző beállítása

Ha olyan elemzőt választ, amely teljes kifejezéseket tokentál, az alábbi elemzők gyakori választások:

Elemző Viselkedésmódok
nyelvelemzők Megőrzi a kötőjeleket összetett szavakban vagy sztringekben, magánhangzó-mutációkban és igealakokban. Ha a lekérdezési minták kötőjeleket tartalmaznak, a nyelvelemző használata elegendő lehet.
kulcsszó A teljes mező tartalma egyetlen kifejezésként van tokenizálva.
Szóköz Csak a fehér helyeken különválaszt. A kötőjeleket vagy más karaktereket tartalmazó kifejezések egyetlen tokenként vannak kezelve.
egyéni elemző (ajánlott) Az egyéni elemző létrehozásával megadhatja a tokenizert és a token szűrőt is. Az előző elemzőket változatlanul kell használni. Az egyéni elemző lehetővé teszi, hogy kiválassza, mely tokenizálókat és token szűrőket használja.

Az ajánlott kombináció a kulcsszó tokenizáló egy kisbetűs token szűrővel. A beépített kulcsszóelemző önmagában nem alakítja kisbetűssé a nagybetűs szöveget, ami a lekérdezések sikertelenségéhez vezethet. Egy egyéni elemző mechanizmust biztosít a kisbetűs token szűrő hozzáadásához.

REST-ügyfél használatával hozzáadhatja a Test Analyzer REST-hívást a tokenizált kimenet vizsgálatához.

Az indexnek léteznie kell a keresési szolgáltatásban, de üres lehet. Egy meglévő index és egy kötőjeleket vagy részleges kifejezéseket tartalmazó mezőben különböző elemzőket próbálhat ki a konkrét kifejezéseken, hogy lássa, milyen tokeneket bocsát ki.

  1. Először ellenőrizze a Standard elemzőt, hogy alapértelmezés szerint hogyan vannak tokenizálva a kifejezések.

    {
    "text": "SVP10-NOR-00",
    "analyzer": "standard"
    }
    
  2. A válasz kiértékelése, hogy megállapítható legyen, hogyan van a szöveg tokenizálva az indexen belül. Figyelje meg, hogyan történik az egyes kifejezések kisbetűssé alakítása, a kötőjelek eltávolítása és a részszövegek egyedi jelölőkké bontása. Csak azok a lekérdezések fogják visszaadni ezt a dokumentumot az eredményekben, amelyek ezen tokenek alapján egyeznek. A "10-NOR" szöveget tartalmazó lekérdezés sikertelen lesz.

    {
        "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
            }
        ]
    }
    
  3. Most módosítsa a kérést az whitespace vagy a keyword elemző használatára.

    {
    "text": "SVP10-NOR-00",
    "analyzer": "keyword"
    }
    
  4. A válasz ezúttal egyetlen nagybetűs tokenből áll, a szövegrész részeként megőrzött kötőjelekkel. Ha egy mintán vagy egy részleges kifejezésen (például "10-NOR" kifejezésen) kell keresnie, a lekérdezési motornak most már megvan az alapja egyezés megtalálásához.

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

Fontos

Vegye figyelembe, hogy a lekérdezéselemzők gyakran kisbetűssé alakítják a kifejezéseket egy keresés során, amikor a lekérdezési fát építik fel. Ha olyan elemzőt használ, amely nem ad kisbetűs szövegbevitelt az indexelés során, és nem kapja meg a várt eredményeket, ez lehet az oka. A megoldás egy kisbetűs token szűrő hozzáadása, az "Egyéni elemzők használata" című szakaszban az alábbiak szerint leírtak alapján.

3 – Elemző konfigurálása

Akár kiértékeli az elemzőket, akár előrehalad egy adott konfigurációval, meg kell adnia az elemzőt a meződefinícióban, és esetleg magát az elemzőt is konfigurálnia kell, ha nem használ beépített elemzőt. Az elemzők felcserélésekor általában újra kell építeni az indexet (törölni, újra létrehozni és betölteni).

Beépített elemzők használata

A beépített elemzők név alapján adhatók meg egy analyzer meződefiníció tulajdonságán, és nincs szükség további konfigurálásra az indexben. Az alábbi példa bemutatja, hogyan állíthatja be a whitespace elemzőt egy mezőn.

Más forgatókönyvek esetén és az egyéb beépített elemzőkről további információt a beépített elemzők című témakörben talál.

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

Egyéni elemzők használata

Ha egyéni elemzőt használ, definiálja azt az indexben a tokenizer felhasználó által definiált kombinációjával, a tokenszűrővel és a lehetséges konfigurációs beállításokkal. Ezután hivatkozzon rá egy meződefinícióra, ugyanúgy, mint egy beépített elemzőre.

Amikor a cél a teljes kifejezéses tokenizálás, egy kulcsszó tokenizálóból és kisbetűs token szűrőből álló egyéni elemző ajánlott.

  • A kulcsszó tokenizáló egyetlen tokent hoz létre egy mező teljes tartalmához.
  • A kisbetűs token szűrő kisbetűkké alakítja át a nagybetűket. A lekérdezéselemzők általában kisbetűssé alakítják a nagybetűs szövegbeviteleket. Az alsó burkolat homogenizálja a bemeneteket a tokenizált kifejezésekkel.

Az alábbi példa egy egyéni elemzőt mutat be, amely a kulcsszó szókivonatolót és egy kisbetűs szűrőt biztosít.

{
"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": []
}

Megjegyzés

A keyword_v2 jogkivonat-kezelő és lowercase a jogkivonat-szűrő ismert a rendszer számára, és az alapértelmezett konfigurációkat használja, ezért név szerint hivatkozhat rájuk anélkül, hogy először meg kellene határoznia őket.

4 – Felépítés és tesztelés

Miután definiált egy indexet a forgatókönyvet támogató elemzőkkel és meződefiníciókkal, töltse be a reprezentatív sztringekkel rendelkező dokumentumokat, hogy tesztelhesse a részleges sztringes lekérdezéseket.

REST-ügyfél használatával lekérdezheti a cikkben ismertetett részleges kifejezéseket és speciális karaktereket.

Az előző szakaszok elmagyarázták a logikát. Ez a szakasz végigvezeti a megoldás tesztelése során meghívandó API-kon.

  • Az Index törlése eltávolít egy azonos nevű meglévő indexet, hogy újra létre tudja hozni.

  • Az Index létrehozása létrehozza a keresési szolgáltatás indexstruktúráját, beleértve az elemződefiníciókat és az elemző specifikációval rendelkező mezőket.

  • A Dokumentumok betöltése olyan dokumentumokat importál, amelyek struktúrája megegyezik az indexével, valamint kereshető tartalommal. A lépés után az index készen áll a lekérdezésre vagy tesztelésre.

  • A Test Analyzer a Set an analyzer (Elemző beállítása) című témakörben jelent meg. Az index bizonyos kifejezéseit különféle elemzők segítségével tesztelje, hogy megértse, hogyan történik a tokenizálás.

  • A keresési dokumentumok bemutatja, hogyan hozhat létre lekérdezési kérést egyszerű szintaxissal vagy teljes Lucene szintaxissal helyettesítő karakterek és reguláris kifejezések esetében.

    Részleges kifejezések lekérdezéséhez, például a "3-6214" lekérdezésére, hogy egyezést találjon "+1 (425) 703-6214"-el, használhatja az egyszerű szintaxist: search=3-6214&queryType=simple.

    Az infix- és utótag-lekérdezésekhez, például a "szám" vagy a "numerikus" lekérdezéshez használja a teljes Lucene szintaxist és egy reguláris kifejezést: search=/.*num.*/&queryType=full

Előtag- és utótag-lekérdezések optimalizálása

Az előtagok és utótagok alapértelmezett elemzővel való egyeztetéséhez további lekérdezési funkciókra van szükség. Az előtagok helyettesítő keresést igényelnek, az utótagok pedig rendszeres kifejezéskeresést igényelnek. Mindkét funkció csökkentheti a lekérdezési teljesítményt.

Az alábbi példa egy EdgeNGramTokenFilter előtagot vagy utótagot ad hozzá, amely gyorsabb egyezést eredményez. A tokenek 2–25 karakteres kombinációiban jönnek létre. Íme egy példa a két-hét token közötti progresszióra: MS, MSF, MSFT, MSFT/, MSFT/S, MSFT/SQ, MSFT/SQL. EdgeNGramTokenFilter olyan paramétert side igényel, amely meghatározza, hogy a sztring karakterkombinációi melyik oldaláról jönnek létre. Használja a front előtag-lekérdezésekhez és a back utótag-lekérdezésekhez.

A további tokenizálás nagyobb indexet eredményez. Ha elegendő kapacitással rendelkezik a nagyobb index elhelyezéséhez, ez a gyorsabb válaszidővel rendelkező megközelítés lehet a legjobb megoldás.

{
"fields": [
  {
    "name": "accountNumber_prefix",
    "indexAnalyzer": "ngram_front_analyzer",
    "searchAnalyzer": "keyword",
    "type": "Edm.String",
    "searchable": true,
    "filterable": false,
    "retrievable": true,
    "sortable": false,
    "facetable": false
  },
  {
    "name": "accountNumber_suffix",
    "indexAnalyzer": "ngram_back_analyzer",
    "searchAnalyzer": "keyword",
    "type": "Edm.String",
    "searchable": true,
    "filterable": false,
    "retrievable": true,
    "sortable": false,
    "facetable": false
  }
],

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

A következő lekérdezéssel kereshetünk olyan fiókszámokat, amelyek 123-tal kezdődnek:

{
  "search": "123",
  "searchFields": "accountNumber_prefix"
}

A végződésű 456fiókszámok kereséséhez az alábbi lekérdezést használhatjuk:

{
  "search": "456",
  "searchFields": "accountNumber_suffix"
}