Megosztás a következőn keresztül:

Homályos keresés a hibás elírások és elírások kijavításához

  • Cikk

Az Azure AI Search támogatja a homályos keresést, amely egy olyan lekérdezéstípus, amely kompenzálja a bemeneti sztring elírásait és hibásan írt kifejezéseit. Homályos kereséssel keres olyan kifejezéseket, amelyek hasonló összetételűek. A találatok közötti keresés kibontásával automatikusan kijavítható egy elírás, ha az eltérés csak néhány helytelen karakterből áll.

Ez egy lekérdezésbővítési gyakorlat, amely hasonló összetételű kifejezéseken hoz létre egyezést. Ha egy homályos keresés van megadva, a keresőmotor létrehoz egy gráfot (a determinisztikus véges automaton elmélet alapján) hasonlóan összeállított kifejezésekből, a lekérdezés összes teljes kifejezéséhez. Ha például a lekérdezés három kifejezést "university of washington"tartalmaz, a lekérdezés search=university~ of~ washington~ minden kifejezéséhez létrejön egy gráf (a homályos keresésben nincs stop-word eltávolítás, ezért "of" gráfot kap).

A gráf legfeljebb 50 bővítésből vagy permutációból áll minden egyes kifejezésből, és rögzíti a helyes és helytelen változatokat is a folyamatban. A motor ezután a válaszban a legfontosabb releváns egyezéseket adja vissza.

Az "egyetem" kifejezéshez hasonlóan a gráfnak lehet "unversty, universty, university, universe, inverse". A diagramon szereplő dokumentumokat az eredmények tartalmazzák. Más lekérdezésekkel ellentétben, amelyek a szöveget elemzik ugyanannak a szónak a különböző formáinak ("egerek" és "egér") kezelésére, a homályos lekérdezések összehasonlítását arcértéken végzik anélkül, hogy nyelvi elemzést végeznek a szövegen. A szemantikailag eltérő "univerzum" és "inverz" egyezni fog, mert a szintaktikai eltérések kicsik.

Az egyezés akkor sikeres, ha az eltérések két 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 (két szomszédos karakter beszúrása, törlése, helyettesítése vagy átültetése) szükséges, hogy az egyik szót a másikra módosítsa".

Az Azure AI Searchben:

  • A homályos lekérdezés egész kifejezésekre vonatkozik. A kifejezések közvetlenül nem támogatottak, de a többrészes kifejezések minden egyes kifejezésére megadhat egy-egy homályos egyezést az AND-szerkezeteken keresztül. Például: search=dr~ AND cleanin~. Ez a lekérdezési kifejezés egyezéseket talál a "száraz tisztítás" kifejezéssel.

  • A szerkesztés alapértelmezett távolsága 2. Egy érték ~0 nem jelent bővítést (csak a pontos kifejezés tekinthető egyezésnek), de megadhat ~1 egy bizonyos fokú különbséget vagy egy szerkesztést.

  • A homályos lekérdezések legfeljebb 50 permutációval bővíthetik a kifejezéseket. Ez a korlát nem konfigurálható, de a szerkesztési távolság 1-esre való csökkentésével hatékonyan csökkentheti a bővítések számát.

  • A válaszok egy releváns egyezést tartalmazó dokumentumokból állnak (legfeljebb 50).

A lekérdezésfeldolgozás során a homályos 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 gráfjának létrehozásához. Az egyetlen végrehajtott átalakítás az alsó burkolat.

A gráfokat együttesen egyező feltételként küldi el a rendszer az index tokenjeihez. Ahogy el tudja képzelni, 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.

Feljegyzé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 előrehaladásával (két és három karaktersorozat bigram- és trigram-tokenekhez). A nyelvtől és a lekérdezési felülettől függően az n-gram jobb teljesítményt nyújt. A kereskedelem 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 megfontolhatna, ha csak a legrelehetőbb eseteket szeretné kezelni, szinonimatérkép lenne. A "search" leképezése például "serach, serch, sarch" vagy "retrieve" to "retreive".

A "kereshetőnek" tulajdonított sztringmezők zavaros keresésre alkalmasak.

Az elemzők nem használhatók bővítődiagram 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 fontosak a tokenizáláshoz az indexelés során, ahol az invertált indexekben lévő jogkivonatok a gráfhoz való egyeztetéshez használatosak.

Mint mindig, ha a tesztelési 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óval rendelkező nyelvek kihasználhatják a Microsoft természetes nyelvi processzorai által létrehozott inflexiós és szabálytalan szóalakokat. Bizonyos esetekben a megfelelő nyelvelemző használata különbséget tehet abban, hogy egy kifejezés jogkivonatos, a felhasználó által megadott értékkel kompatibilis módon van-e jogkivonatosítva.

A homályos lekérdezések a teljes Lucene-lekérdezés szintaxisával jönnek létre, a teljes Lucene-lekérdezéselemzőt invesztálják, és hozzáfűznek egy tilde karaktert ~ a felhasználó által megadott összes teljes kifejezés után.

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

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

  1. Állítsa be 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 teljes kifejezések végén (search=<string>~). A lekérdezés bemenetében minden kifejezéshez létrejön egy bővítőgráf.

    Adjon meg egy opcionális 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 "kék~" vagy a "kék~1" kifejezés például a "kék", a "blues" és a "glue" értéket adja vissza.

Ha szeretné, javíthatja a lekérdezés teljesítményét, ha a kérést adott mezőkre hatókörbe rendezi. A paraméter használatával searchFields adja meg, hogy mely mezőkben szeretne keresni. A tulajdonság használatával select megadhatja, hogy mely mezők lesznek visszaadva a lekérdezési válaszban.

Az egyszerű teszteléshez javasoljuk, hogy a Search Explorert vagy egy REST-ügyfelet a 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 visszatérő válaszokat.

Ha az eredmények nem egyértelműek, a találatkiemelés segíthet azonosítani a válaszban szereplő egyezést.

Feljegyzés

A találatkiemelés használata a homályos találatok azonosítására korlátozásokkal rendelkezik, és csak az alapszintű fuzzy 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 kiemelés nem tudja azonosítani az egyezést.

1. példa: homályos keresés a pontos kifejezéssel

Tegyük fel, hogy a következő sztring "Description" egy keresőmezőben található egy keresődokumentumban: "Test queries with special characters, plus strings for MSFT, SQL and Java."

Kezdje a "speciális" kereséssel, és adjon hozzá találatkiemelést a Leírás mezőhöz:

search=special~&highlight=Description

A válaszban, mivel találatkiemelést adott hozzá, a program a "speciális" kifejezésre alkalmazza a formázást 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 be a "különleges" szöveget több levél ("pe"):

search=scial~&highlight=Description

Eddig nem változott a válasz. Mivel az alapértelmezett 2 fok távolság, két karakter "pe" eltávolítása a "speciális" 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 összesen három törléshez (a "speciálistól" a következőig) kivesz egy utolsó karaktert "scal":

search=scal~&highlight=Description

Figyelje meg, hogy a rendszer ugyanazt a választ adja vissza, de most a "speciális" helyett a homályos 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 az, hogy bemutassa azokat az egyértelműségeket, amelyek a kiemeléssel nem egyértelmű eredményeket hozhatnak. Minden esetben ugyanazt a dokumentumot adja vissza. Ha a dokumentumazonosítókra támaszkodott volna egyezés ellenőrzéséhez, előfordulhat, hogy kihagyta a "különleges" és az "SQL" közötti váltást.

Lásd még