模糊搜尋以校正拼寫錯誤和錯字
Azure AI 搜尋服務支援模糊搜尋，這種查詢類型可補正輸入字串中的錯字和拼錯字詞。 模糊搜尋會掃描具有類似組合的字詞。 擴展搜尋以涵蓋接近相符項目，可在不一致僅為幾個錯位字元時自動校正錯字。
什麼是模糊搜尋？
這是查詢擴充的運用，可產生具有類似組合的詞彙相符項目。 指定模糊搜尋時，搜尋引擎會針對查詢中的所有整個詞彙，建立類似組合詞彙的圖表 (根據 確定有限狀態自動機理論 (deterministic finite automaton theory))。 例如，假使您的查詢包含三個詞彙 "university of washington"，則引擎會針對查詢 search=university~ of~ washington~ 中的每個字詞建立圖表 (模糊搜尋沒有停用字詞移除功能，因此 "of" 會取得圖表)。
針對每個詞彙，圖表可包含最多 50 種擴充或排列組合，並在程序中擷取正確和不正確的變體。 引擎接著會在回應中傳回最相關的前幾個相符項目。
對於類似 "university" 的字詞，圖表可能會有 "unversty, universty, university, universe, inverse"。 結果中會包含符合圖表項目的所有文件。 不同於分析文字以處理相同字組不同形式 (「mice」和「mouse」) 的其他查詢，模糊查詢中的比較是以臉部值進行，而不會對文字進行任何語言分析。 雖然「Universe」和「inverse」在語意上不相同，但因為語法構造差異很小，因此屬於相符項目。
如果不一致限於兩個或更少的編輯內，則會判定為相符，所謂的編輯是指插入、刪除、替代或轉置的字元。 指定差異的字串更正演算法是 Damerau-Levenshtein 距離 計量。 其描述為「將一個字組變更為另一個字組所需的最小作業數目 (作業包括插入、刪除、替代或兩個相鄰字元的換位)」。
在 Azure AI 搜尋服務中：
模糊查詢適用於整個字詞。 不直接支援片語，但您可以透過 AND 建構，在多部分片語的每個字詞上指定模糊比對。 例如：
search=dr~ AND cleanin~。 此查詢運算式會尋找 "dry cleaning" 的相符項目。編輯的預設距離為 2。
~0的值表示沒有擴充 (只會將確切字詞視為相符)，但您可以指定~1以設為一單位的差異，或一次編輯。模糊查詢可以擴充最多 50 種排列組合的字詞。 此限制無法設定，但您可以將編輯距離減少至 1，藉此有效減少擴充數目。
回應是由包含相關符合項目 (最多 50 個) 的文件所組成。
在查詢處理期間，模糊查詢不會進行語彙分析。 查詢輸入會直接新增至查詢樹狀結構，並擴充以建立字詞圖表。 唯一執行的轉換是切換為小寫。
整體而言，圖表會提交作為索引中語彙基元的比對準則。 當然，模糊搜尋天生就比其他查詢方法更慢。 索引的大小和複雜度可以決定效益是否足以抵銷回應的延遲。
注意
由於模糊搜尋通常很慢，因此探索 n-gram 索引編製等替代方案可能也是不錯的選擇，此方式可提供簡短字元序列的連續性 (二字元組和三字元組語彙基元的兩和三個字元序列)。 根據您的語言和查詢介面，n-gram 或許能提供更佳的效能。 但相對地，n-gram 索引編制的缺點是非常耗用儲存體，而且會產生更大的索引。
若是要處理最棘手的情況，可以考慮另一個替代方法：同義字對應。 例如，將「search」對應至「serach、serch、sarch」或「retrieve」對應至「retreive」。
模糊搜尋的索引編製
屬性為「searchable (可搜尋)」的字串欄位是模糊搜尋的候選項目。
分析器不會用於建立擴充圖表，但這並不表示在使用模糊搜尋時應該忽略分析器。 分析器對於索引編製期間的語彙基元化至關重要，其中反轉索引中的語彙基元會用來與圖表進行比對。
和往常一樣，如果測試查詢未產生您預期的相符項目，請嘗試不同的索引分析器。 例如，請嘗試語言分析器來看看是否能獲得更好的結果。 某些語言，特別是具有元音變換 (vowel mutations) 的語言，適合搭配 Microsoft 自然語言處理器所產生的變化和不規則字組形式。 在某些情況下，使用正確的語言分析器可能影響字詞的語彙基元化方式是否符合使用者所提供的值。
如何叫用模糊搜尋
模糊查詢是使用完整的 Lucene 查詢語法所建構，請叫用完整的 Lucene 查詢剖析器，並在使用者輸入的每個完整詞彙後面附加一個波浪號 (~)。
以下是叫用模糊搜尋的查詢要求範例。 查詢包含四個字詞，其中兩個字詞拼寫錯誤：
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"
}
將查詢類型設定為完整的 Lucene 語法 (
queryType=full)。提供查詢字串，其中每個字詞後面接著一個波浪號 (
~) 運算子，放在每個完整字詞的結尾 (search=<string>~)。 系統會針對查詢輸入中的每個字詞建立擴充圖表。如果您想要指定編輯距離 (
~1)，請包含選擇性參數 (介於 0 到 2 (預設) 之間的數字)。 例如，"blue~" 或 "blue~1" 會傳回 "blue"、"blues" 和 "glue"。
您可以選擇將要求範圍設定為特定欄位，藉此改善查詢效能。 使用 searchFields 參數指定要搜尋的欄位。 您也可以使用 select 屬性來指定查詢回應中傳回的欄位。
測試模糊搜尋
若要簡單測試，我們建議透過搜尋總管或 REST 用戶端逐一查看查詢運算式。 這兩個工具都是互動式工具，這表示您可以快速瀏覽字詞的多個變體，並評估傳回的回應。
當結果模棱兩可時，搜尋結果醒目提示可協助您識別回應中的相符項目。
注意
使用搜尋結果醒目提示來識別模糊相符項目有限制，而且僅適用於基本模糊搜尋。 如果您的索引具有評分設定檔，或您以更多語法分層查詢，則搜尋結果醒目提示可能無法識別相符項目。
範例 1：使用確切字詞的模糊搜尋
假設搜尋文件中的 "Description" 欄位中存在下列字串："Test queries with special characters, plus strings for MSFT, SQL and Java."
首先針對「special」進行模糊搜尋，並將搜尋結果醒目提示新增至 [描述] 欄位：
search=special~&highlight=Description
在回應中，因為您新增了搜尋結果醒目提示，因此格式設定會套用至「special」作為比對字詞。
"@search.highlights": {
"Description": [
"Test queries with <em>special</em> characters, plus strings for MSFT, SQL and Java."
]
}
再次嘗試要求，並透過取出數個字母 ("pe") 將「special」拼寫錯誤：
search=scial~&highlight=Description
到目前為止，回應沒有任何變更。 使用預設值為 2 度距離，從「special」移除兩個字元 "pe"，仍可以成功比對該字詞。
"@search.highlights": {
"Description": [
"Test queries with <em>special</em> characters, plus strings for MSFT, SQL and Java."
]
}
再嘗試一個要求，藉由刪除最後一個字元來進一步修改搜尋字詞，目前共有三個刪除 (從「special」變為 "scal")：
search=scal~&highlight=Description
請注意，雖然傳回的回應相同，但現在不是比對「special」，而是針對「SQL」的模糊比對。
"@search.score": 0.4232868,
"@search.highlights": {
"Description": [
"Mix of special characters, plus strings for MSFT, <em>SQL</em>, 2019, Linux, Java."
]
}
此擴充範例的重點在於說明搜尋結果醒目提示可能會造成模棱兩可的結果。 在所有情況下，都會傳回相同的文件。 如果您依賴文件識別碼來驗證相符項目，則可能會忽略從「special」到「SQL」的轉變。