Közelítő keresés a helyesírási hibák és elírások kijavításához

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.

Azure AI Keresés 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 keresés kiterjesztése a közeli egyezésekre olyan hatással van, hogy automatikusan kijavítja az elírást, amikor az eltérés csak néhány rossz helyre került 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és esetén a gráfnak lehet "unversty, universty, university, universe, inverse". Azok a dokumentumok, amelyek bármelyikével megegyeznek a grafikonon, szerepelnek az eredményekben. 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. "Univerzum" és "inverz", amelyek szemantikailag eltérőek, egyeznek, 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 "szükséges műveletek minimális száma (beszúrások, törlések, helyettesítések vagy két szomszédos karakter felcserélése), hogy az egyik szót a másikra módosítsa".

Az Azure AI Keresés:

  • 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 elemé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ési feltételként viszik fel az index tokenjeire. 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.

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 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újthat. A kompromisszum az, hogy az n-gram indexelés nagyon storage intenzív, é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 a "retrieve" például "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 a fordított indexek tokenjei 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ő nyelvi elemző használata különbséget jelenthet abban, hogy egy kifejezés a felhasználó által megadott értékkel kompatibilis módon kerül-e szegmentálásra.

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/docs/search?api-version=2026-04-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.

Megjegyzé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 "homályos" kereséssel a "speciális" kulcsszóra, é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álja újra a kérést, és vegyen ki több betűt a "különleges" szóból ("pe"):

search=scial~&highlight=Description

Eddig nem változott a válasz. Mivel az alapértelmezett távolság 2 fok, két karakter "pe" eltávolítása a "special" szóból még mindig lehetővé teszi a sikeres egyezést erre a kifejezésre.

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

Próbálkozzon még egy kéréssel, módosítsa tovább a keresési kifejezést úgy, hogy eltávolít egy utolsó karaktert, összesen három karakter törlésével (a 'speciális'-ból "scal").

search=scal~&highlight=Description

Ugyanez a válasz lesz visszaadva, de most ahelyett, hogy a "speciális" egyezést használták, 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."
    ]
}

A kibővített példa célja annak bemutatása, hogy a kiemelés milyen tisztaságot adhat az olyan eredményeknek, amelyek nem egyértelműek. 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 elszalasztja a váltást a "különleges" állapotról az "SQL" állapotra.

Kapcsolódó tartalom

  • Utolsó frissítés időpontja: