Intelligens keresés a helyesírási hibák és elírások kijavításához

  • Cikk
  • 5 perc alatt elolvasható

Azure Cognitive Search támogatja az intelligens keresést, amely a bemeneti sztringben szereplő elírásokat és hibásan írt kifejezéseket kompenzáló lekérdezéstípus. Ezt úgy teszi, hogy hasonló összetételű kifejezéseket keres. A közeli találatokat lefedő keresés kibontása az elírás automatikus javításának hatására jár, ha az eltérés csak néhány téves karakterből áll.

Ez egy lekérdezésbővítési gyakorlat, amely hasonló összetételű kifejezések alapján hoz létre egyezést. Ha intelligens keresést ad meg, a keresőmotor létrehoz egy hasonlóan összeállított kifejezésekből álló gráfot ( determinisztikus véges automatonelmélet alapján) a lekérdezés összes teljes kifejezéséhez. Ha például a lekérdezés három kifejezést tartalmaz: "washingtoni egyetem", a lekérdezés search=university~ of~ washington~ minden kifejezéséhez létrejön egy gráf (a homályos keresésben nincs leállítási szó, ezért az "of" gráfot kap).

A gráf legfeljebb 50 bővítésből vagy permutációból áll minden kifejezésből, és rögzíti a helyes és a helytelen változatokat is a folyamatban. A motor ezután visszaadja a legfontosabb találatokat a válaszban.

Az "egyetem" kifejezéshez hasonló kifejezések esetében a gráf "unversty, universty, university, universe, inverz" kifejezéssel rendelkezhet. A gráfban szereplő dokumentumok az eredmények között szerepelnek. Ellentétben azokkal a lekérdezésekkel, amelyek a szöveget elemzik ugyanannak a szónak a különböző formáinak ("egerek" és "egér") kezeléséhez, a homályos lekérdezések összehasonlítását arcértéken, a szöveg nyelvi elemzése nélkül végzik el. A "világegyetem" és az "inverz", amelyek szemantikailag eltérőek, egyezni fognak, mert a szintaktikai eltérések kicsik.

Az egyezés akkor sikeres, ha az eltérések kettő vagy kevesebb szerkesztésre korlátozódnak, ahol a szerkesztés egy beszúrt, törölt, helyettesített vagy transzponált karakter. A különbséget meghatározó sztringkorrekciós algoritmus a Damerau-Levenshtein távolságmetrika . Ez a "műveletek minimális száma (beszúrások, törlések, helyettesítések vagy két szomszédos karakter átültetése) szükséges, hogy az egyik szót a másikra módosítsuk".

A Azure Cognitive Search:

  • Az intelligens lekérdezések a teljes kifejezésekre vonatkoznak, de a kifejezéseket ÉS szerkezeteken keresztül is támogathatja. Az "Unviersty~ of~ "Wshington~" például a "Washingtoni Egyetem" szerint egyezik.

  • A szerkesztés alapértelmezett távolsága 2. Egy érték ~0 nem jelez bővítést (csak a pontos kifejezés számít egyezésnek), de megadhat ~1 egy különbségi fokot vagy egy szerkesztést.

  • Az intelligens lekérdezések legfeljebb 50 permutációval bővíthetik a kifejezéseket. Ez a korlát nem konfigurálható, de hatékonyan csökkentheti a bővítések számát, ha a szerkesztési távolságot 1-re csökkenti.

  • A válaszok olyan dokumentumokból állnak, amelyek megfelelő egyezést tartalmaznak (legfeljebb 50).

A lekérdezések feldolgozása során az intelligens lekérdezések nem esnek át lexikális elemzésen. A lekérdezés bemenete közvetlenül a lekérdezési fához lesz hozzáadva, és ki van bontva a kifejezések diagramjának létrehozásához. Az egyetlen végrehajtott átalakítás az alsó burkolat.

A gráfokat együttesen a rendszer az indexben lévő tokenekkel egyező feltételekként küldi el. Képzelhető el, hogy a homályos keresés eredendően lassabb, mint a többi lekérdezési űrlap. Az index mérete és összetettsége meghatározhatja, hogy az előnyök elegendőek-e a válasz késésének ellensúlyozásához.

Megjegyzés

Mivel a homályos keresés általában lassú, érdemes lehet megvizsgálni az olyan alternatívákat, mint az n-gram indexelés, a rövid karaktersorozatok (két és három karaktersorozat a bigram és a trigram tokenek esetében). A nyelvtől és a lekérdezési felülettől függően az n-gram jobb teljesítményt nyújthat. A kompromisszum az, hogy az n-gram indexelés nagyon tárolóigényes, és sokkal nagyobb indexeket hoz létre.

Egy másik alternatíva, amelyet figyelembe vehet, ha csak a legrégibb eseteket szeretné kezelni, szinonimatérkép lenne. Például a "search" leképezése a "serach, serch, sarch" vagy "retrieve" értékre a "retreive" értékre.

A "kereshetőként" attribútumú sztringmezők intelligens keresésre alkalmasak.

Az elemzők nem használhatók bővítőgráf létrehozásához, de ez nem jelenti azt, hogy az elemzőket figyelmen kívül kell hagyni a homályos keresési forgatókönyvekben. Az elemzők az indexelés során fontos szerepet játszik a tokenizálásban, ahol az invertált indexekben lévő tokenek a gráftal való egyeztetéshez használatosak.

Mint mindig, ha a teszt lekérdezések nem a várt egyezéseket állítják elő, kísérletezzen különböző indexelő elemzőkkel. Próbálkozzon például egy nyelvelemzővel , és ellenőrizze, hogy jobb eredményeket kap-e. Egyes nyelvek, különösen a magánhangzó-mutációkkal rendelkezők, kihasználhatják a Microsoft természetes nyelvi feldolgozók által generált inflexiós és szabálytalan szóformákat. Bizonyos esetekben a megfelelő nyelvelemző használata különbséget tehet abban, hogy a kifejezés jogkivonata a felhasználó által megadott értékkel kompatibilis módon van-e jogkivonatosítva.

Az intelligens lekérdezések a teljes Lucene-lekérdezési szintaxissal jönnek létre, a teljes Lucene lekérdezéselemzőt invokálják, és egy tilde karaktert ~ fűznek hozzá a felhasználó által megadott összes teljes kifejezés után.

Íme egy példa egy olyan lekérdezési kérelemre, amely intelligens keresést hív meg. Négy kifejezést tartalmaz, amelyek közül kettő hibásan van beírva:

POST https://[service name].search.windows.net/indexes/hotels-sample-index/docs/search?api-version=2020-06-30
{
    "search": "seatle~ waterfront~ view~ hotle~",
    "queryType": "full",
    "searchMode": "any",
    "searchFields": "HotelName, Description",
    "select": "HotelName, Description, Address/City,",
    "count": "true"
}

  1. Állítsa a lekérdezés típusát a teljes Lucene szintaxisra (queryType=full).

  2. Adja meg azt a lekérdezési sztringet, amelyben az egyes kifejezéseket egy tilde (~) operátor követi az egyes kifejezések végén (search=<string>~). A lekérdezés bemenetének minden kifejezéséhez létrejön egy bővítőgráf.

    Adjon meg egy választható paramétert, egy 0 és 2 közötti számot (alapértelmezett), ha meg szeretné adni a szerkesztési távolságot (~1). A "blue~" vagy a "blue~1" kifejezés például a "blue", a "blues" és a "glue" értéket adja vissza.

Igény szerint javíthatja a lekérdezési teljesítményt úgy, hogy a kérést adott mezőkre hatókörrel adhatja meg. A paraméter használatával searchFields adja meg, hogy mely mezőkben szeretne keresni. A tulajdonsággal select azt is megadhatja, hogy mely mezők lesznek visszaadva a lekérdezési válaszban.

Az egyszerű teszteléshez a Kereséskezelőt vagy a Postmant javasoljuk egy lekérdezési kifejezésen keresztüli iteráláshoz. Mindkét eszköz interaktív, ami azt jelenti, hogy gyorsan végiglépkedhet egy kifejezés több változatán, és kiértékelheti a visszaadandó válaszokat.

Ha az eredmények nem egyértelműek, a találatok kiemelésével azonosíthatja az egyezést a válaszban.

Megjegyzés

A találatok kiemelésének használata a homályos találatok azonosítására korlátozásokkal rendelkezik, és csak az alapszintű intelligens kereséshez működik. Ha az index pontozási profilokkal rendelkezik, vagy ha a lekérdezést több szintaxissal rétegezi, előfordulhat, hogy a találatkiemelés nem tudja azonosítani az egyezést.

1. példa: intelligens keresés a pontos kifejezéssel

Tegyük fel, hogy a következő sztring létezik egy keresési dokumentum egyik "Description" mezőjében: "Test queries with special characters, plus strings for MSFT, SQL and Java."

Kezdje egy intelligens kereséssel a "special" kifejezésre, és adja hozzá a találatok kiemelését a Leírás mezőhöz:

search=special~&highlight=Description

A válaszban, mivel hozzáadott találatkiemelést, a formázás a "special" kifejezésre lesz alkalmazva az egyező kifejezésként.

"@search.highlights": {
    "Description": [
        "Test queries with <em>special</em> characters, plus strings for MSFT, SQL and Java."
    ]

Próbálkozzon újra a kéréssel, és írja le a "különleges" szöveget több levél ("pe") kivételével:

search=scial~&highlight=Description

Eddig nem történt változás a válaszban. Az alapértelmezett 2 fokos távolság használatával a két karakter "pe" eltávolítása a "speciális" karakterből továbbra is lehetővé teszi a sikeres egyezést ezen a kifejezésen.

"@search.highlights": {
    "Description": [
        "Test queries with <em>special</em> characters, plus strings for MSFT, SQL and Java."
    ]

Még egy kéréssel tovább módosíthatja a keresési kifejezést úgy, hogy kivesz egy utolsó karaktert összesen három törléshez (a "speciálistól" a "scal"-ig):

search=scal~&highlight=Description

Figyelje meg, hogy a rendszer ugyanazt a választ adja vissza, de most a "special" helyett az intelligens egyezés az "SQL"-en van.

        "@search.score": 0.4232868,
        "@search.highlights": {
            "Description": [
                "Mix of special characters, plus strings for MSFT, <em>SQL</em>, 2019, Linux, Java."
            ]

Ennek a kibontott példának a lényege annak az egyértelműségnek a szemléltetése, hogy a találatok kiemelése nem egyértelmű eredményeket hozhat. A függvény minden esetben ugyanazt a dokumentumot adja vissza. Ha a dokumentumazonosítókra támaszkodott volna az egyezés ellenőrzéséhez, előfordulhat, hogy elmulasztotta a "speciális" helyett az "SQL" közötti váltást.

Lásd még