Fuzzy-sökning för att korrigera felstavningar och stavfel
Azure AI Search stöder fuzzy-sökning, en typ av fråga som kompenserar för stavfel och felstavade termer i indatasträngen. Fuzzy-sökning söker efter termer som har en liknande sammansättning. Om du expanderar sökningen för att täcka nära matchningar får det en autokorrigering av ett stavfel när avvikelsen bara är några få felplacerade tecken.
Det är en frågeexpansionsövning som genererar en matchning på termer som har en liknande sammansättning. När en fuzzy-sökning anges skapar sökmotorn ett diagram (baserat på deterministisk finita automatonteori) med liknande sammansatta termer, för alla hela termer i frågan. Om frågan till exempel innehåller tre termer "university of washington"
skapas ett diagram för varje term i frågan search=university~ of~ washington~
(det finns ingen stoppordsborttagning i fuzzy-sökningen, så "of"
hämtar ett diagram).
Diagrammet består av upp till 50 expansioner, eller permutationer, av varje term, som samlar in både korrekta och felaktiga varianter i processen. Motorn returnerar sedan de översta relevanta matchningarna i svaret.
För en term som "universitet" kan diagrammet ha "unversty, universty, university, universe, inverse"
. Alla dokument som matchar dem i diagrammet ingår i resultaten. I motsats till andra frågor som analyserar texten för att hantera olika former av samma ord ("möss" och "mus"), görs jämförelserna i en fuzzy-fråga till nominellt värde utan någon språklig analys av texten. "Universe" och "inverse", som är semantiskt olika, kommer att matcha eftersom syntaktiska avvikelser är små.
En matchning lyckas om avvikelserna begränsas till två eller färre redigeringar, där en redigering är ett infogat, borttaget, ersatt eller transponerat tecken. Strängkorrigeringsalgoritmen som anger differentiell är måttet Damerau-Levenshtein avstånd . Det beskrivs som det minsta antal åtgärder (infogningar, borttagningar, ersättningar eller införlivanden av två intilliggande tecken) som krävs för att ändra ett ord till det andra.
I Azure AI Search:
Fuzzy-frågan gäller för hela termer. Fraser stöds inte direkt, men du kan ange en fuzzy-matchning för varje term i en fras i flera delar via AND-konstruktioner. Exempel:
search=dr~ AND cleanin~
Det här frågeuttrycket hittar matchningar vid "kemtvätt".Standardavståndet för en redigering är 2.
~0
Värdet betyder ingen expansion (endast den exakta termen anses vara en matchning), men du kan ange~1
för en grad av skillnad eller en redigering.En fuzzy-fråga kan expandera en term på upp till 50 permutationer. Den här gränsen kan inte konfigureras, men du kan effektivt minska antalet expansioner genom att minska redigeringsavståndet till 1.
Svaren består av dokument som innehåller en relevant matchning (upp till 50).
Under frågebearbetningen genomgår fuzzy-frågor inte lexikal analys. Frågeindata läggs till direkt i frågeträdet och expanderas för att skapa ett diagram med termer. Den enda transformering som utförs är lägre hölje.
Tillsammans skickas graferna som matchningsvillkor mot token i indexet. Som du kan föreställa dig är fuzzy-sökningen i sig långsammare än andra frågeformulär. Indexets storlek och komplexitet kan avgöra om fördelarna är tillräckliga för att kompensera svarstiden för svaret.
Anteckning
Eftersom fuzzy-sökning tenderar att vara långsam kan det vara värt att undersöka alternativ som n-gram indexering, med dess progression av korta teckensekvenser (två och tre teckensekvenser för bigram- och trigramtoken). Beroende på språk och frågeyta kan n-gram ge dig bättre prestanda. Kompromissen är att n-gram indexering är mycket lagringsintensiv och genererar mycket större index.
Ett annat alternativ, som du kan överväga om du bara vill hantera de mest avskyvärda fallen, skulle vara en synonymkarta. Till exempel mappning av "sök" till "serach, serch, sarch" eller "retrieve" till "retreive".
Strängfält som tilldelas som "sökbara" är kandidater för fuzzy-sökning.
Analysverktyg används inte för att skapa ett expansionsdiagram, men det betyder inte att analysverktyg ska ignoreras i fuzzy-sökscenarier. Analysverktyg är viktiga för tokenisering under indexering, där token i de inverterade indexen används för matchning mot grafen.
Om testfrågor inte producerar de matchningar du förväntar dig experimenterar du som alltid med olika indexanalysverktyg. Prova till exempel en språkanalysator för att se om du får bättre resultat. Vissa språk, särskilt de med vokalmutationer, kan dra nytta av böjning och oregelbundna ordformer som genereras av Microsofts naturliga språkprocessorer. I vissa fall kan det göra skillnad om en term tokeniseras på ett sätt som är kompatibelt med värdet som tillhandahålls av användaren med hjälp av rätt språkanalysator.
Fuzzy-frågor konstrueras med den fullständiga Lucene-frågesyntaxen, anropar den fullständiga Lucene-frågeparsern och lägger till ett tilde-tecken ~
efter varje hel term som angetts av användaren.
Här är ett exempel på en frågebegäran som anropar fuzzy-sökning. Den innehåller fyra termer, varav två är felstavade:
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"
}
Ange frågetypen till den fullständiga Lucene-syntaxen (
queryType=full
).Ange frågesträngen där varje term följs av en tilde-operator (
~
) i slutet av varje hel term (search=<string>~
). Ett expansionsdiagram skapas för varje term i frågeindata.Inkludera en valfri parameter, ett tal mellan 0 och 2 (standard), om du vill ange redigeringsavståndet (
~1
). Till exempel skulle "blue~" eller "blue~1" returnera "blue", "blues" och "glue".
Du kan också förbättra frågeprestanda genom att omfångssöka begäran till specifika fält. Använd parametern searchFields
för att ange vilka fält som ska sökas. Du kan också använda select
egenskapen för att ange vilka fält som returneras i frågesvaret.
För enkel testning rekommenderar vi Sökutforskaren eller en REST-klient för iterering över ett frågeuttryck. Båda verktygen är interaktiva, vilket innebär att du snabbt kan gå igenom flera varianter av en term och utvärdera svaren som kommer tillbaka.
När resultaten är tvetydiga kan träffmarkering hjälpa dig att identifiera matchningen i svaret.
Anteckning
Användningen av träffmarkering för att identifiera fuzzy-matchningar har begränsningar och fungerar bara för grundläggande fuzzy-sökning. Om ditt index har bedömningsprofiler, eller om du lagrar frågan med mer syntax, kan träffmarkeringen misslyckas med att identifiera matchningen.
Anta att följande sträng finns i ett "Description"
fält i ett sökdokument: "Test queries with special characters, plus strings for MSFT, SQL and Java."
Börja med en fuzzy-sökning på "special" och lägg till träffmarkering i fältet Beskrivning:
search=special~&highlight=Description
I svaret, eftersom du har lagt till träffmarkering, tillämpas formatering på "special" som matchande term.
"@search.highlights": {
"Description": [
"Test queries with <em>special</em> characters, plus strings for MSFT, SQL and Java."
]
}
Försök igen, felstava "special" genom att ta ut flera bokstäver ("pe"
):
search=scial~&highlight=Description
Hittills har ingen ändring av svaret gjorts. Med standardvärdet 2 graders avstånd tillåter borttagning av två tecken "pe"
från "special" fortfarande en lyckad matchning på den termen.
"@search.highlights": {
"Description": [
"Test queries with <em>special</em> characters, plus strings for MSFT, SQL and Java."
]
}
Försök med ytterligare en begäran, ändra söktermen ytterligare genom att ta ut ett sista tecken för totalt tre borttagningar (från "special" till "scal"
):
search=scal~&highlight=Description
Observera att samma svar returneras, men nu i stället för att matcha på "special" är fuzzy-matchningen på "SQL".
"@search.score": 0.4232868,
"@search.highlights": {
"Description": [
"Mix of special characters, plus strings for MSFT, <em>SQL</em>, 2019, Linux, Java."
]
}
Poängen med det här utökade exemplet är att illustrera den klarhet som träffmarkering kan ge tvetydiga resultat. I samtliga fall returneras samma dokument. Om du hade förlitat dig på dokument-ID:t för att verifiera en matchning hade du kanske missat skiftet från "special" till "SQL".