Note
Azure AI 搜尋服務 可透過 Azure 入口網站、REST API 及 Azure SDK 取得。 它同時也是 Foundry IQ 的基礎，這是一個管理式知識層，能將企業內容轉化為可重複使用、權限感知的知識庫，供 Microsoft Foundry 入口網站中的代理使用。
在 Azure AI 搜尋中建立查詢時，您可選擇使用完整 Lucene Query Parser 語法，以建立專用的查詢形式：萬用字元、模糊搜尋、鄰近搜尋、規則運算式。 Lucene Query Parser 語法的大部分內容會在 Azure AI 搜尋中維持原樣實作，但範圍搜尋除外，範圍搜尋會透過 $filter 運算式建構。
若要使用完整 Lucene 語法，請將 queryType 設為 full，並傳入為萬用字元、模糊搜尋或完整語法支援的其他查詢形式所設計的查詢運算式。 在 REST 中，查詢運算式會在search 要求的 參數中提供。
範例 (完整語法)
以下範例是使用完整語法建構的搜尋要求。 這個特定範例示範了欄位式搜尋和片語加權。 它會尋找類別欄位包含 budget 詞彙的旅館。 包含該詞組 "recently renovated" 的文章會獲得額外的提升權重，並可能因詞組提升值（3）而排名更高。
POST /indexes/hotels-sample/docs/search?api-version=2026-04-01
{
"queryType": "full",
"search": "category:budget AND \"recently renovated\"^3",
"searchMode": "all"
}
雖然不限定於任何 queryType，但 searchMode 參數在此範例中相關。 只要查詢中出現運算子，您通常應將 searchMode=all 設定為全部，以確保所有準則皆符合。
如需更多範例，請參閱 Lucene 查詢語法範例。 如需查詢要求與參數的詳細資訊 (包含 searchMode)，請參閱搜尋文件 (REST API)。
語法基礎
下列語法基本概念適用於所有使用 Lucene 語法的查詢。
內容中的運算子評估
放置位置會決定符號要解譯為運算子，或僅是字串中的一般字元。
例如，在 Lucene 完整語法中，波浪號 (~) 同時用於模糊搜尋與鄰近搜尋。 當它置於加上引號的片語之後，~ 會調用鄰近搜尋。 當它置於詞彙結尾，~ 會調用模糊搜尋。
在詞彙內部，例如 business~analyst，此字元不會以運算子解譯。 在此情況下，假設查詢是詞彙或片語查詢，具有詞彙分析的全文搜尋會移除 ~，並將 business~analyst 拆成兩個：business 或 analyst。
上述範例以波浪號 (~) 說明，但相同原則適用於每個運算子。
逸出特殊字元
若要將任何搜尋運算子作為搜尋文字的一部分，請在字元前加上一個反斜線 (\) 進行逸出。 例如，若要針對 https:// 進行萬用字元搜尋，且 :// 是查詢字串的一部分，請指定 search=https\:\/\/*。 同樣地，已逸出的電話號碼模式可能會長得像這樣：\+1 \(800\) 642\-7676。
需要逸出的特殊字元包含下列項目：
+ - & | ! ( ) { } [ ] ^ " ~ * ? : \ /
Note
雖然逸出可讓詞元保持在一起，但在建立索引期間的詞彙分析可能會將它們移除，例如標準 Lucene 分析器會在連字號、空白與其他字元處切分字詞。 若查詢字串需要特殊字元，您可能需要一個可在索引中保留它們的分析器。 部分選項包含 Microsoft 自然語言分析器，可保留連字號組成的字詞，或用於更複雜模式的自訂分析器。 如需詳細資訊，請參閱部分詞彙、模式與特殊字元。
在 URL 中編碼不安全與保留字元
請確保 URL 中所有不安全與保留字元皆已編碼。 例如，# 是不安全字元，因為它是 URL 中的片段或錨點識別碼。 若在 URL 中使用，必須將該字元編碼為 %23。
& 與 = 是保留字元的範例，因為它們用來分隔參數與指定 Azure AI 搜尋中的值。 如需更多詳細資訊，請參閱 RFC 1738：統一資源定位符 (URL)。
不安全字元為 " ` < > # % { } | \ ^ ~ [ ]。 保留字元為 ; / ? : @ = + &。
布林運算子
您可在查詢字串中內嵌布林運算子，以提升比對精確度。 完整語法除了字元運算子外，也支援文字運算子。 請一律以全大寫指定文字布林運算子 (AND、OR、NOT)。
| 文字運算元 | Character | Example | Usage |
|---|---|---|---|
| AND | + |
wifi AND luxury |
指定比對必須包含的詞彙。 在此範例中，查詢引擎會尋找同時包含 wifi 與 luxury 的文件。 加號字元 (+) 也可直接放在詞彙前方，使其成為必須條件。 例如，+wifi +luxury 規定兩個詞彙都必須出現在單一文件的欄位中某處。 |
| OR | （無） 1 | wifi OR luxury |
在找到任一詞彙時即比對成功。 在此範例中，查詢引擎會回傳包含 wifi、luxury 其中之一或兩者的相符文件。 在 searchMode=any 中，OR 是預設的連接運算子，因此 wifi luxury 等同於 wifi OR luxury。 若使用 searchMode=all，請使用明確的 OR 運算子以取得此行為。 |
| NOT |
!、- |
wifi –luxury |
在排除該詞彙的文件上傳回比對結果。 例如，wifi –luxury 會搜尋包含 wifi 詞彙但不包含 luxury 詞彙的文件。 |
1| 字元不支援用於 OR 運算。
NOT 布林運算子
Important
NOT 運算子 (NOT、! 或 -) 在完整語法中的行為與在簡單語法中的行為不同。
- 在簡單語法中，包含否定的查詢一律會自動加入萬用字元。 例如，
-luxury會自動展開為-luxury *。 - 在完整語法中，包含否定的查詢不可與萬用字元結合。 例如，
-luxury *不允許。 - 在完整語法中，不允許只有單一否定的查詢。 例如，
-luxury不允許。 - 在完整語法中，否定的行為會像是無論 searchMode 為何，都一律以 AND 與查詢結合。
- 例如，完整語法查詢
wifi -luxury只會擷取包含wifi詞彙的文件，然後對這些文件套用-luxury的否定。
- 例如，完整語法查詢
- 若要使用否定來搜尋索引中的所有文件，建議使用搭配
any的簡單語法。 - 若要使用否定來搜尋索引中的文件子集，建議使用完整語法，或搭配 all searchMode 的簡單語法。
| 查詢類型 | 搜尋模式 | 範例查詢 | Behavior |
|---|---|---|---|
| Simple | any | wifi -luxury |
傳回索引中的所有文件。 .包含 "wifi" 詞彙的文件，或缺少 "luxury" 詞彙的文件，會比其他文件獲得較高排名。 查詢會展開為 wifi OR -luxury OR *。 |
| Simple | all | wifi -luxury |
只傳回索引中包含 "wifi" 詞彙且不包含 "luxury" 詞彙的文件。 查詢會展開為 wifi AND -luxury AND *。 |
| Full | any | wifi -luxury |
只傳回索引中包含 wifi 詞彙的文件，接著將包含 luxury 詞彙的文件從結果中移除。 |
| Full | all | wifi -luxury |
只傳回索引中包含 wifi 詞彙的文件，接著將包含 luxury 詞彙的文件從結果中移除。 |
欄位式搜尋
您可使用 fieldName:searchExpression 語法定義欄位式搜尋作業，其中 searchExpression 可為單一字詞或片語，或以括號括住的更複雜運算式，並可選擇性包含布林運算子。 以下是一些範例：
genre:jazz NOT historyartists:("Miles Davis" "John Coltrane")
若您希望多個字串以單一實體評估，請務必將多個字串放在引號內，此案例會在 artists 欄位中搜尋兩位不同的藝人。
fieldName:searchExpression 中指定的欄位必須是 searchable 欄位。 如需索引屬性如何用於欄位定義的詳細資訊，請參閱 建立索引。
Note
使用欄位式搜尋運算式時，您不需要使用 searchFields 參數，因為每個欄位式搜尋運算式都已明確指定欄位名稱。 不過，若您想執行部分範圍限定於特定欄位、其餘部分可套用到多個欄位的查詢，仍可使用 searchFields 參數。 例如，查詢 search=genre:jazz NOT history&searchFields=description 會只將 jazz 比對到 genre 欄位，同時會將 NOT history 與 description 欄位進行比對。 在 fieldName:searchExpression 中提供的欄位名稱一律優先於 searchFields 參數，因此在此範例中，我們不需要在 genre 參數中包含 searchFields。
模糊搜尋
模糊搜尋會在結構相似的詞彙中找到比對，並最多展開為 50 個符合距離條件 (2 或更小) 的詞彙。 如需詳細資訊，請參閱模糊搜尋。
若要進行模糊搜尋，請在單一字詞結尾使用波浪號 (~) 符號，並可選擇性加上 0 到 2 之間的數字參數 (預設)，以指定編輯距離。 例如，blue~ 或 blue~1 會傳回 blue、blues 與 glue。
模糊搜尋只能套用到詞彙，不能套用到加上引號的片語，但您可在多段名稱或片語中，將波浪號附加到每個詞彙上。 例如，Unviersty~ of~ Wshington~ 會比對到 University of Washington。
鄰近搜尋
鄰近搜尋用於找出文件中彼此相近的詞彙。 在片語結尾插入波浪號 ~ 符號，後面接著用來建立鄰近邊界的字詞數量。 例如，"hotel airport"~5 會在文件中找出彼此相距 5 個字詞以內的 hotel 與 airport 詞彙。
字詞提升
把搜尋想像成兩個步驟。 首先，Azure AI 搜尋服務 會找到匹配的文件。 接著，系統會對這些比賽進行排名。 關鍵字提升只影響第二步：它能將符合查詢某部分的文件推到結果的更高位置。
詞彙提升與評分曲線不同。 Boost 會提高目前查詢中某個字詞、片語或群組的權重。 評分設定檔會根據索引中定義的規則，偏重欄位或其他索引內容。
增壓範圍
緊接在你想提高權重的查詢部分後面，輸入插入號（^）和一個正數。 例如，tax^2 可以將包含 tax 的文件排在僅符合未經提升詞彙的文件之前。 預設的增壓值是 1。 你也可以使用介於 0 和 1 之間的值，例如 0.2，來降低配對的權重。
標點符號告訴你每個指令影響的詞彙：
- 欄位名稱加上冒號，稱為欄位前綴，會出現在單字、引號片語或括號群組之前。 例如，
content:告訴 Azure AI 搜尋服務 在content欄位中搜尋。 - 像
^2這樣的增強符號會出現在單字、引號括住的片語或括號括住的群組之後。 它告訴 Azure AI 搜尋服務 在排名配對時應該偏好哪個。
下表使用預設 searchMode=any，其中詞間空格的運作方式為 OR。
| Query | 可搭配的項目 | 加成偏重的項目 |
|---|---|---|
deferred tax^2 |
deferred、tax，或兩者皆可。 |
只有「tax」這個字。 |
"deferred tax"^2 |
完整的片語，詞語相鄰且依序排列。 | 完整的詞語。 |
(deferred OR tax)^2 |
deferred、tax，或兩者皆可。 |
將括號內的所有內容視為一組。 |
使用 searchMode=all 時，查詢 deferred tax^2 必須同時符合這兩個詞。 加成仍然僅適用於 tax。 若要改為匹配其中一個單字，請寫成 deferred OR tax^2。
當你想要強調整個詞組或整組內容時，請將插入點放在結尾引號或右括號後面。 括號不會創造一個短語。 當詞語必須相鄰且按特定順序出現時，請使用引號。
增壓與欄位範圍
欄位名稱後面加冒號，限制 Azure AI 搜尋服務 的搜尋範圍。 提升會改變 Azure AI 搜尋服務 對匹配的排名方式。 你可以在同一個查詢中同時使用兩者。
| Query | 這是什麼意思? |
|---|---|
content:deferred tax^2 |
欄位前綴僅適用於 deferred。 獨立 tax^2 部分使用由 選取的 searchFields欄位，或如果 searchFields 未指定則使用所有可搜尋欄位。 比賽 tax 會獲得額外的排名權重。 |
content:"deferred tax"^2 |
請只在 content 中尋找完整片語，並對該片語相符結果給予額外的排名權重。 |
content:(deferred OR tax)^2 |
僅在 content 中尋找任一個詞，並給予群組比對結果額外的排序權重。 |
例如，若 searchFields 設為 title，第一個查詢會在 deferred 中尋找 content，並在 tax 中尋找 title。 其他查詢中的引號和括號會使兩個詞都保留在 content 中。
Important
結腸和護管朝相反方向工作。 欄位前綴 content: 會用於其後的查詢部分。 提升 ^2 會套用於它前面的查詢部分。 使用引號或括號，使該部分包含多個單字。 欲了解更多資訊，請參閱 「現場搜尋 與 優先次序（分組）」。
分析器對加權查詢的影響
對於普通的單字、片語和單字組合，提升不會跳過文本分析。 在匹配之前，Azure AI 搜尋服務 仍會用每個欄位的分析器處理查詢文字。 因此，同一段已提升權重的文字，在使用不同分析器的欄位裡可能會有不同的比對結果。
帶有欄位前綴的片語或群組會使用該欄位的分析器。 沒有欄位前綴的文字會針對每個搜尋欄位使用分析器。 例如，將文字改為小寫的分析器，可以與小寫索引詞彙匹配 "DEFERRED TAX"^2 。
其他查詢形式，如百用字、正則表達式和模糊查詢，則使用不同的分析規則。 加裝加速不會改變這些規則。 欲了解更多資訊，請參閱 第二階段：詞彙分析。
規則運算式搜尋
規則運算式搜尋會根據 Apache Lucene 中有效的模式進行比對，如 RegExp 類別文件所述。
在 Azure AI 搜尋中，規則運算式為：
- 以正斜線
/括住 - 僅小寫
例如，若要找出包含 motel 或 hotel 的文件，請指定 /[mh]otel/。 規則運算式搜尋會針對單一字詞進行比對。
某些工具與語言除了 Azure AI 搜尋所施加的逸出規則之外，還會施加額外的逸出字元需求。 對於 JSON，包含正斜線的字串會以反斜線進行逸出：microsoft.com/azure/ 會變成 search=/.*microsoft.com\/azure\/.*/，其中 search=/.* <string-placeholder>.*/ 會設定規則運算式，而 microsoft.com\/azure\/ 是已逸出正斜線的字串。
regex 查詢中兩個常見符號是 . 與 *。
. 會比對任一單一字元，而 * 會將前一個字元比對 0 次或多次。 例如，/be./ 會比對 bee 與 bet，而 /be*/ 會比對 be、bee 與 beee，但不會比對 bet。 合在一起時，.* 可讓您比對任意一段字元序列，因此 /be.*/ 會比對任何以 be 開頭的詞彙，例如 better。
若您的規則運算式出現語法錯誤，請檢閱特殊字元的逸出規則。 您也可改用不同的用戶端，以確認問題是否與工具相關。
萬用字元搜尋
您可使用一般公認的語法進行多字元 (*) 或單字元 (?) 萬用字元搜尋。 完整 Lucene 語法支援首碼與中置比對。 請使用規則運算式語法進行尾碼比對。
請注意，Lucene 查詢剖析器僅支援在單一詞彙上使用這些符號，不支援片語。
| 詞綴類型 | 描述與範例 |
|---|---|
| prefix | 詞彙片段位於 * 或 ? 之前。 例如，查詢運算式 search=alpha* 會傳回 alphanumeric 或 alphabetical。 簡單語法與完整語法都支援首碼比對。 |
| suffix | 詞彙片段位於 * 或 ? 之後，並使用正斜線來分隔建構。 例如 search=/.*numeric/ 會傳回 alphanumeric。 |
| infix | 詞彙片段會包住 * 或 ?。 例如，search=non*al 會傳回 non-numerical 與 nonsensical。 |
您可以在一個運算式中組合多個運算子。 例如，980?2* 會比對 98072-1222 與 98052-1234，其中 ? 會比對單一 (必要) 字元，而 * 會比對後續任意長度的字元。
尾碼比對需要使用規則運算式正斜線 / 分隔符號。 一般而言，您不能將 * 或 ? 作為詞彙的第一個字元，除非搭配 /。 也必須注意，* 在 regex 查詢之外使用時行為不同。 在 regex 正斜線 / 分隔符號之外，* 是萬用字元，會比對任意一段字元序列，類似於 regex 中的 .*。 例如，search=/non.*al/ 會產生與 search=non*al 相同的結果集。
Note
一般而言，模式比對速度較慢，因此您可能想探索替代方法，例如 edge n-gram 詞元化，為詞彙中的字元序列建立詞元。 使用 n-gram 詞元化時，索引會變大，但查詢可能會更快執行，視模式建構與您索引的字串長度而定。 如需詳細資訊，請參閱部分字詞搜尋和具有特殊字元的模式。
分析器對萬用字元查詢的影響
在查詢剖析期間，當查詢以首碼、尾碼、萬用字元或規則運算式形式撰寫時，系統會將其原樣傳入查詢樹，並略過詞彙分析。 只有當索引包含符合您查詢指定格式的字串時，才會找到比對。 多數情況下，您在建立索引時需要使用可保留字串完整性的分析器，才能讓部分詞彙與模式比對成功。 如需詳細資訊，請參閱 Azure AI 搜尋查詢中的部分詞彙搜尋。
請考慮一種情境：您希望搜尋查詢 terminal* 傳回包含 terminate、termination 與 terminates 等詞彙的結果。
若使用 en.lucene (English Lucene) 分析器，它會對每個詞彙套用較強的詞幹還原。 例如，terminate、termination、terminates 都會在索引中詞元化為 termi。 另一方面，使用萬用字元或模糊搜尋的查詢中的詞彙完全不會經過分析，因此不會有任何結果可符合 terminat* 查詢。
另一方面，Microsoft 分析器 (此處為 en.microsoft 分析器) 較為進階，使用詞形還原而非詞幹還原。 這表示所有產生的詞元應為有效的英文單字。 例如，terminate、terminates 與 termination 大多會在索引中保持完整，對於高度依賴萬用字元與模糊搜尋的情境而言會是較佳選擇。
Note
通配符、前綴和正則表達式查詢詞會與索引中的字面標記匹配。 由於大多數分析器使用小寫索引內容，大寫詞如 Contoso* 可能無法匹配像 contoso的標記。 根據指派給該欄位的分析器之大小寫摺疊行為，請在應用程式中將這些查詢詞轉為小寫。
萬用字元與 regex 查詢的評分
Azure AI 搜尋對文字查詢使用以頻率為基礎的評分 (BM25)。 不過，對於萬用字元與 regex 查詢，由於詞彙範圍可能很廣，系統會忽略頻率因子，以避免排名偏向較罕見詞彙的比對。 對於萬用字元與 regex 搜尋，所有比對都一視同仁。
特殊字元
在某些情況下，您可能想搜尋特殊字元，例如 '❤' 表情符號或 '€' 符號。 在這些情況下，請確保您使用的分析器不會將這些字元篩除；標準分析器會略過許多特殊字元，導致它們不會進入索引。
會將特殊字元詞元化的分析器包含空白分析器，它會將任何以空白分隔的字元序列視為詞元(因此 ❤ 字串會視為一個詞元)。 此外，像 Microsoft 英文分析器 ("en.microsoft") 這類語言分析器，也會將 "€" 字串視為一個詞元。 您可以測試分析器，確認它針對指定查詢會產生哪些詞元。
使用 Unicode 字元時，請確保在查詢 url 中正確逸出符號 (例如 ❤ 會使用逸出序列 %E2%9D%A4+)。 部分 REST 用戶端會自動完成此轉換。
優先順序（群組）
使用括號來控制查詢中哪些部分會被一起評估。 例如， motel AND (wifi OR luxury) 需要 motel 和 至少包含括號內的一項： wifi 或 luxury。
在括號中的群組前加上欄位前綴，即可在同一欄位搜尋整個群組。 例如，hotelAmenities:(wifi OR pool) 僅會在 wifi 欄位中尋找 pool 或 hotelAmenities。
括號會控制 AND 和 OR 如何共同運作。 它們不需要字詞相鄰出現或按特定順序出現。 用引號表示這種行為。 要提升一個群組，將圓滑符放在結尾括號後面，例如 hotelAmenities:(wifi OR pool)^2。 更多資訊請參閱 增壓範圍。
查詢大小限制
Azure AI 搜尋會對查詢大小與組成施加限制，因為無界限的查詢可能會使您的搜尋服務不穩定。 查詢大小與組成 (子句數量) 皆有限制。 首碼搜尋長度，以及 regex 搜尋與萬用字元搜尋的複雜度也有限制。 若您的應用程式會以程式方式產生搜尋查詢，我們建議以不會產生無界限大小查詢的方式設計。
如需查詢限制的詳細資訊，請參閱 API 要求限制。