透明說明：Azure AI 搜尋服務

AI 增強是指在原始形式中不易被搜尋的內容上應用 Foundry Tools 的機器學習模型。 透過豐富化、分析與推論，創造出可搜尋的內容和結構，這些內容和結構以前並不存在。

AI 擴充是 Azure AI 搜尋服務索引子管道的選用延伸模組，可連線至與客戶的搜尋服務位於相同區域的 Foundry Tools。 濃縮管線擁有與典型索引器相同的核心組件（索引器、資料來源、索引器），並具備指定原子濃縮步驟的技能組。 技能組合可以透過基於 Foundry Tools API 內建的技能組合，例如 願景 與 語言，或是執行你提供的外部程式碼的 自訂技能 。

向量搜尋是一種資訊檢索方法，文件與查詢以向量形式以索引表示，而非純文字。 在向量搜尋中，機器學習模型由 Azure AI 搜尋服務 外部託管，能產生來源輸入的向量表示，這些輸入可以是文字、圖片、音訊或影片內容。 這種數學化且正規化的內容表示方式稱為向量嵌入，為搜尋情境提供了通用的基礎。

當所有內容都是向量時，查詢可以在向量空間中找到匹配，即使相關的原始內容屬於不同的媒體類型，例如圖片與文字，或是與查詢不同的語言。 搜尋引擎會掃描索引，尋找與查詢中向量最相似、最接近的向量內容。 以數學向量表示法配對而非關鍵字，會讓人們更有可能找到語意相同但文本上不同的匹配，例如「car」和「auto」。 這更詳細介紹了向量嵌入以及相似度演算法的運作方式。

關鍵術語

語意排序器利用查詢的語境或語意意義來計算一個新的相關性分數，將最接近原始查詢意圖的結果推向頂端。 初始結果集可以來自結合 BM25 排名的關鍵字搜尋、 向量 搜尋，或是兩者兼具的 混合搜尋 。 它還會透過擷取結果中的逐字內容來建立並回傳「說明」，以及「重點」以引起對結果中重要內容的注意。 如果查詢具有問題特徵（「水的冰點是多少」），且結果包含具有答案特徵的文字（「水在0°C或32°F時結冰」），它也能回傳「答案」。

關鍵術語

查詢重寫會創造合成查詢，這些查詢是根據實際客戶輸入而人工生成的，以提升 BM25 排名、向量搜尋或混合搜尋的召回率（從可用文件總數中擷取的相關文件比例）。 原始查詢會與合成查詢結合，以從搜尋引擎提供最佳召回率。

生成式AI提示技能是Azure AI 搜尋服務技能目錄的一部分，讓客戶能根據資料以AI生成內容來強化搜尋索引。 透過利用客戶組織自身的數據與偏好，這項技能有助於產出符合其特定需求的量身摘要、答案或洞察。

這表示當終端使用者透過 AI 搜尋搜尋客戶內容時，AI 生成的內容能提供更具資訊性且具上下文感知的結果，讓使用者更容易找到他們想要的資訊。

關鍵術語

代理檢索是一種平行查詢處理架構，使用對話式大型語言模型（LLM）作為「查詢規劃器」。LLM 會根據需要將使用者的對話紀錄轉換成一個或多個聚焦子查詢。 這些子查詢會同時在您的 Azure AI 搜尋服務 索引中執行，服務會合併前列結果，回傳如下：

• 一個包含最相關段落（基礎資料）的單一內容字串。
• 一個可選的參考陣列，可以揭露完整的原始文件或區塊。
• 一個活動陣列，列出所有操作、令牌數量與延遲，以協助成本追蹤與除錯。

關鍵術語

系統行為

在 Azure AI 搜尋服務 中，有幾個內建技能來增強 AI 功能，並善用 Foundry Tools。 請參考下方連結的每個內建技能的透明度說明，了解使用技能時的考量：

• 關鍵詞擷取技能： 語言 - 關鍵詞擷取
• 語言偵測技能： 語言-語言偵測
• 實體連結技能： 語言 - 實體連結
• 實體辨識技能： 語言 - 命名實體辨識（NER）
• PII 偵測技能：語言 - PII 偵測
• 情感技能： 語言 - 情感分析
• 影像分析技能： 視覺 - 影像分析
• OCR 技能： 視覺 - OCR
• 文件排版技能： 文件智慧

請參閱各項技能的文件，了解其能力、限制、表現、評估，以及整合與負責任使用的方法。 請注意，結合使用這些技能可能會導致複合效應（例如使用OCR時產生的錯誤，在使用關鍵詞萃取時仍會持續存在）。

使用案例

範例使用案例

由於 Azure AI 搜尋服務 是全文搜尋解決方案，AI 豐富化的目的是提升非結構化內容的搜尋功能。 以下是一些由內建技能支持的內容豐富情境範例：

• 翻譯 與 語言偵測 支援多語言搜尋。
• 實體辨識 是從大量文字中提取 人物 、 地點 及 其他實體 。
• 關鍵字擷取 能識別並輸出重要詞彙。
• OCR 能辨識二進位檔案中的印刷與手寫文字。
• 影像分析 描述影像內容，並將描述輸出為可搜尋的文字欄位。
• Integrated vectorization 是一個預覽功能，呼叫 Azure OpenAI 嵌入模型來向量化資料並將嵌入儲存在 Azure AI 搜尋服務 中以便搜尋相似性。

系統行為

在向量搜尋中，搜尋引擎會在索引的嵌入空間中尋找接近查詢向量的向量。 這種技術稱為 最近鄰搜尋。 這也有助於量化物品間的相似度或距離。 高度向量相似度表示原始資料也相似。 Azure AI 搜尋服務 支援的兩種向量搜尋演算法針對此問題採取不同方法，會根據延遲、吞吐量、回憶與記憶體等不同特性做出權衡。

要找到真正的「k」個最近鄰集合，需要將輸入向量與資料集中的所有向量進行全面比較。 雖然每次向量相似度計算都相對快速，但跨大規模資料集進行這些詳盡比較，計算成本高且速度緩慢，因為所需的比較數量龐大。 此外，每個向量的維度越高，計算過程就越複雜且速度越慢。

為因應此挑戰，系統會使用近似最近鄰 (ANN) 搜尋方法，以召回率換取速度。 這些方法能有效找到一小組最可能與查詢向量相似的候選向量，從而減少向量比較的總數。 Azure AI 搜尋服務 採用階層式可導航小世界（HNSW）演算法，將高維資料點組織成機率分層圖結構，實現快速相似性搜尋，同時在搜尋準確度與計算成本間做出可調整的權衡。

Azure AI 搜尋服務 也支援多種相似度指標，以判斷每個向量結果的最近鄰與分數，包括餘弦、「歐幾里得」（亦稱「l2範數」）及「點積」。餘弦計算兩個向量之間的角度。 歐幾里得計算兩個向量之間的歐幾里得距離，即兩向量差的 l2-範數。 點積會受到兩個向量的大小及其之間的角度影響。 對於正規化嵌入空間，點積等價於餘弦相似度，但效率更高。

使用案例

範例使用案例

在許多情境中，向量搜尋非常有用，但這些限制僅受限於產生向量嵌入所用模型的能力。 以下是向量搜尋的一些一般應用情境：

• 語意搜尋：透過使用模型從文本中提取語意理解，例如使用Azure OpenAI 服務嵌入模型。
• 跨不同資料類型搜尋（多模態）：編碼來自圖片、文字、音訊和影片的內容，或是混合內容，並對所有資料進行一次搜尋。
• 多語言搜尋：使用多語言嵌入模型，將文件以多種語言表示，以尋找支援語言的結果。
• 混合搜尋：向量搜尋是在欄位層級實作，這表示你可以建立包含向量欄位和可搜尋文字欄位的查詢。 查詢會平行執行，結果會合併成單一回應。 帶有語意排序的混合搜尋結果已被證明能提供最佳的質性結果。
• 過濾向量搜尋：查詢可以包含向量查詢和篩選表達式。 套用於其他資料型態的篩選器，有助於根據其他條件納入或排除文件。
• 向量資料庫：這種純向量儲存庫用於長期記憶或大型語言模型（LLM）的外部知識庫。 例如，在 Azure Machine Learning 的提示流程中，使用 Azure AI 搜尋服務 作為向量索引，用於檢索增強生成（RAG）應用程式。

選擇使用情境時的考量

您選擇用來產生向量嵌入的特定模型，可能會有相關考量與疑慮。 每個模型可能都有其偏見與公平性的問題，應在應用前進行評估。 Azure AI 搜尋服務 並未提供任何模型來將內容向量化作為服務的一部分。 請參閱 Azure OpenAI 服務 透明度說明 以了解這些考量的範例。 其他第三方或開源軟體模型也有自己的考量需要檢視。

系統行為

對第一層檢索步驟的結果進行排序是一個高度耗費資源的過程。 為了在查詢操作預期延遲內完成排序器的處理，只有檢索引擎的前 50 個結果作為輸入送交語意排序器。 若過長，會先將 50 個結果送入摘要步驟，從每個結果中擷取最相關內容，然後再執行語意排序器。

在摘要階段，檢索文件首先會經過一個準備過程，將不同的文件輸入串接成一條長字串。 若字串過長，則會進行修剪，特別強調保留加入 語意配置欄位中的內容。 字串準備好後，會通過機器閱讀理解與語言表示模型，以判斷哪些句子和片語相對於查詢內容能提供最佳的摘要。 此階段從字串中擷取內容，將傳遞至語意排序階段，並可選擇性地輸出語 意說明 或語 意答案。

最後一步語意排名，判斷前一步擷取內容與使用者查詢的相關性，並輸出語意排名分數，範圍從4（高度相關）到0（無關）。 此步驟基於查詢文本與摘要文本，且計算比檢索層更為複雜。

使用案例

範例使用案例

語意排序器可以在多種情境中使用。 系統預期的使用情境包括：

• 檢索增強生成（Retrieval Augmented Generation，RAG）：語意排名器使您能將生成式 AI 應用的回應與符合您所定義的相關性評分門檻的搜尋結果相結合。 例如，Azure OpenAI 服務 對你的資料會使用 Azure AI 搜尋服務 來增強 Azure OpenAI 模型。 你可以在此服務中使用語意排名器，提升輸入到 Azure OpenAI 模型的資訊相關性。
• 內容搜尋：語意排名器讓你能透過分析文字與元資料，搜尋資料中相關內容。 例如，在 learn.microsoft.com 網站上，搜尋功能會使用語意排名器來提升軟體開發者搜尋 Microsoft 技術文件的相關性。
• 電子商務搜尋：語意排名器讓電子商務企業能根據語意相關性提供相關產品結果，提升搜尋體驗。 例如，線上零售商會利用語意排名器優化電子商務體驗，提供相關的搜尋結果給線上購物者。
• QnA：Azure AI 搜尋服務 讓組織能根據資料庫中的資訊回答問題，為使用者提供對話式體驗。 例如，製造商可以使用語意排名器來增強聊天機器人可用的資訊。 工程師可以利用這個聊天機器人提問，並取得與查詢相關的高度相關的內部文件，並在所取得的文件中即時獲得答案。

選擇使用情境時的考量

我們鼓勵客戶在創新解決方案或應用中使用語意排名器。 不過，在選擇使用情境時，以下是一些考量：

• 敏感資訊 ：能夠進行語意排序的機器學習模型，會處理搜尋查詢中取得的資料，包括敏感資訊如個人資訊和財務資訊。 在為此類使用情境實作語意排名器前，請考慮任何隱私與安全影響。
• 偏見與公平性 ：語意排名器由深度學習模型驅動。 這些深度學習模型是透過使用公開內容來訓練的。 客戶資料由語意排名模型評分。 選取使用案例時，請評估語意排名器的輸出，尤其是對公平性與平等性有影響的使用案例，例如雇用與招募。
• 法規遵循：部分產業如醫療與金融受到嚴格管制，可能對人工智慧與機器學習的使用有限制。 在使用語意排名器之前，請確保解決方案符合相關法規與指引。

系統行為

原始查詢會傳送到由 Azure AI 搜尋服務 主機託管的 微調小語言模型（SLM）。 此模型是透過使用公開內容訓練的。 SLM 將原始查詢轉換成一組綜合查詢。 這些合成查詢在語意上接近原始查詢的意圖，但包含不同的詞彙組合以提升搜尋引擎的記憶性。

合成查詢會與原始查詢合併，並送入搜尋引擎。 當執行 BM25 排名時，合成查詢的關鍵詞會與原始查詢合併。 當它執行 向量搜尋時，原始查詢會與合成查詢串接，然後再進行 向量嵌入 步驟。

使用案例

範例使用案例

查詢重寫可以在多種情境下使用。 查詢重寫需要使用 語意排名器。

• 與您的資料進行聊天互動：查詢重寫可讓您將生成式 AI 應用程式的回應，基礎設置於符合您定義之相關性分數閾值的相關搜尋結果。 例如，Azure OpenAI 服務 On Your Data 使用 Azure AI 搜尋服務 來增強 Azure OpenAI 模型並加入你的資料。 你可以在此服務中使用查詢重寫，提升輸入至 Azure OpenAI 模型的資訊結果的相關性。
• 對話式問答（QnA）：Azure AI 搜尋服務 讓組織能根據資料庫中可用的資訊回答問題，為使用者提供對話式體驗。 例如，製造商可以使用語意排名器來增強聊天機器人可用的資訊。 工程師可以利用這個聊天機器人提問，並取得與查詢相關的高度相關的內部文件，並在所取得的文件中即時獲得答案。

選擇使用情境時的考量

我們鼓勵客戶在創新解決方案或應用程式中使用查詢重寫。 不過，在選擇使用情境時，以下是一些考量：

• 敏感資訊與個人識別資訊：經過精細調整的 SLM——能重寫查詢——處理可能包含敏感資訊的搜尋查詢。 實作查詢重寫之前，請考慮對隱私和安全可能造成的任何影響。
• 刪除個人資訊以減少無意識偏見。 例如，在公司履歷審查過程中，可能會希望封鎖候選人的姓名、地址或電話號碼，以減少搜尋過程中無意識的性別或其他偏見。
• 法律與法規考量。 組織在使用任何 AI 搜尋時，需評估潛在的法律與監管義務，因為這些 AI 搜尋可能不適合每個產業或情境。 限制可能依地區或地方法規要求而異。 此外，AI 搜尋並非設計用於適用服務條款及相關行為準則所禁止的用途，也不得使用。

GenAI 提示技能允許客戶將其文件內容、資料來源中的資料，以及自訂提示，傳送給他們擁有的語言模型，該模型託管於 Microsoft Foundry。 語言模型處理輸入並回傳豐富內容，這些內容會與原始文件內容一併匯入搜尋索引。 此流程可依據客戶定義標準，透過 AI 生成摘要、圖片說明及實體擷取等功能，增強搜尋索引。

以下範例展示了生成式AI提示技能的運作方式。

零樣本票證摘要

目標：讓客服人員在幾秒內快速瀏覽多頁的電子郵件串。

運作方式：

• 在編制索引期間，每個冗長的票證交談都會分成邏輯區段 (初始要求、後續問題、診斷記錄等)。
• 對於每個段落，語言模型被指示「用三個簡潔的句子總結此段」。
• 最終產生的摘要在檢索過程中取代原始文本，因此代理人及下游的RAG管線只能看到精煉的本質。

為什麼有幫助：簡潔且細分層級的摘要能減少提示長度，加速回應產生，並幫助客服專注於客戶的核心問題。

少樣本實體擷取

目標：支援「顯示 Product X 因錯誤 500 而當機的所有票證」這類查詢。

運作原理

• 完整票證文字會與一個已完成的範例一起傳送至技能，該範例會顯示所需的輸出格式 (主要實體清單，例如產品名稱、錯誤碼、作業系統和嚴重性)。
• 模型會擷取所有出現的產品、錯誤代碼、平台和嚴重性。
• 這個結構化清單會和文件一起儲存，能夠即時篩選出顯示，例如， iOS 上所有高嚴重性當機事件。

為什麼這麼做：預先計算實體能將不受限格式的客戶訊息轉化為可過濾的資料，讓客服領導能發現模式並優先修正，無需人工解析資料。

單次票券路由分類

目標：自動將每個票證路由到正確的佇列。

運作方式：

• 每個工單都會以一個範例來分析，列出五個支援類別——計費、技術問題、帳戶存取、功能請求及一般回饋——並附有一個參考範例（「範例工單 → 計費」）。
• 模型會根據上述五個支援類別，將剛好一個標籤指派給進入 AI 搜尋服務系統作為輸入的每個票證。
• 客服台系統會用這個標籤把帳單查詢寄給財務專家，技術崩潰時則傳給工程師等等。

為什麼這麼做：快速且一致的標籤能減少錯誤轉送的工單，縮短解決時間，並提升顧客滿意度。

連鎖思維解決方案建議

目標：為客服人員提供解決問題的最佳下一步。

運作原理

• 整張工單——或其最新的客戶訊息——會被傳遞給語言模型。
• 使用者訊息在系統提示後指示模型：「內部逐步思考，但只輸出建議的下一步行動。」
• 回傳的指引可能是：「請客戶清除快取並重新安裝版本 3.2.1。」
• 客服人員可以直接複製建議，或在回應前進行修正。

為什麼有幫助：客服人員能在沒有模型私有推理鏈的情況下獲得可執行的建議，節省時間同時保持故障排除步驟簡潔且相關。 在某些情況下，客服人員不會被大量不必要的資訊淹沒。

使用案例

範例使用案例

GenAI 提示技能提升 Azure AI 搜尋服務 中的資料豐富性，協助回應相關性與使用者意圖與期望相符。 透過將 AI 生成內容整合進搜尋索引，這項技能能提供更準確且符合情境的搜尋結果。 主要應用包括：

• 生成冗長文件的簡明摘要，促進資訊快速檢索：律師事務所處理大量合約，並利用GenAI提示技能製作重點條款的簡短摘要，讓律師能在不閱讀整份文件的情況下，輕鬆審閱重要資訊。
• 為圖片建立文字描述以提升搜尋性與可及性：一家媒體公司管理著龐大的圖片庫。 透過運用GenAI提示技能，他們為每張圖片生成描述性說明，實現數位資產管理系統內的高效搜尋與組織。
• 根據自訂標準從文件中識別並提取特定實體或事實：研究機構分析科學論文，以提取有關化學化合物及其性質的提及。 GenAI 提示技能自動化此提取過程，建立結構化資料庫，讓研究人員能迅速存取相關資料。
• 將文件分類為明確類別以改善組織與檢索：保險公司每天會收到各種各類文件。 利用 GenAI 提示技能，他們會自動將這些文件分類為理賠、保單更新和客戶回饋等類別。 這簡化了他們的文件管理流程，也讓他們在需要時更容易找到特定文件。

雖然這些是常見的應用，但這項技能具有彈性，讓客戶能依照自身需求定義提示。

選擇使用情境時的考量

值得注意的是，內容、提示詞和語言模型部署完全由客戶管理。 Foundry 支援模型部署的內容安全過濾器，客戶需負責依需求配置這些過濾器。 除了 Foundry 提供的設定外，Azure AI 搜尋服務 在 GenAI 提示技能中並未套用額外的內容安全過濾器。

在實作生成式AI提示技能時，請考慮以下幾點：

• 實施人工審核 AI 生成內容的流程，特別是在應用可能影響資訊可靠性的提示轉換時。 利用 Azure AI 搜尋服務 的 debug sessions 工具在全面部署前測試範例文件的提示。
• 避免系統的使用或誤用可能導致個人遭受重大身體或心理傷害的情況。 例如，診斷病患或開立藥物的情境，可能造成重大傷害。 將有意義的人為審查與監督納入情境，有助於降低有害結果的風險。
• 仔細考慮所有生成式的使用案例。 內容產生情境可能更容易產生非預期輸出，因此需要謹慎考量與緩解措施。
• 法律與法規考量。 組織在使用任何 AI 搜尋時，需評估潛在的法律與監管義務，因為這些 AI 搜尋可能不適合每個產業或情境。 限制可能依地區或地方法規要求而異。 此外，AI 搜尋並非設計用於適用服務條款及相關行為準則所禁止的用途，也不得使用。

系統行為

原始對話或搜尋查詢會傳送到客戶擁有的 Azure OpenAI 模型，以執行查詢規劃步驟。 查詢規劃將對話拆解成一系列優化的子查詢，反映使用者的底層意圖，並以修正拼寫與擴展同義詞。 Azure AI 搜尋服務 會同時處理整個搜尋檢索系統中的所有子查詢。 子查詢首先會透過關鍵字搜尋與向量搜尋的 混合組合 來處理。 關鍵字搜尋 能在搜尋索引中找到與子查詢相似關鍵字的文件。 向量搜尋 會在搜尋索引中找到可能有不同關鍵字，但與子查詢有相似底層意義的文件。 此混合搜尋結果會由 語意排序器 重新排序，以找出與子查詢意圖最匹配的文件。 服務接著合併並移除排名結果中的重複，並套用回應限制，例如最大輸出長度，然後再回傳最終回應。

使用案例

範例使用案例

• 自訂聊天機器人的基礎資料。 將聊天機器人連結到公司的官方人資政策和員工手冊，當有人問「我有多少天假期？」時，聊天機器人能直接從這些文件中提取答案，而非猜測。
• 裝備企業知識助理尊重使用者情境、篩選條件與聊天歷史。 例如，當員工詢問特定期間的目標時，助理會使用其角色、目前篩選條件 (例如，區域：美國)，以及進行中的交談 (例如，上一個主題是「Q2 管道」) 來產生個人化回應。
• 處理單一關鍵字查詢召回率低的複雜資訊搜尋工作。 這些任務可能包括故障排除指南、醫學文獻研究或產品比較。 例如，如果技術人員僅搜尋「裝置錯誤」並獲得通用結果，代理檢索器可以將整個對話歷史納入考量，包括裝置型號、軟體版本、維護歷史及網路狀態，以呈現精確且相關的文章。
• 確保對取回的物品、原因及成本完全透明。 例如，在摘要監管文件與過去審計結果時，了解確切來源（例如「2023年第二季的SEC申報」）、選擇理由（例如「匹配關鍵字：風險揭露、衍生性金融商品」）以及相關成本（例如代幣使用）至關重要。

選擇使用情境時的考量

• 延遲：新增第二個 LLM 呼叫以進行查詢規劃，必然會延長要求的來回時間。 即使是快速的模型，您也應該在高峰流量下對延遲進行基準測試，確認對使用者的整體體驗仍然維持在可接受的水平。 當延遲至關重要時，可以考慮快取頻繁查詢或使用較小且較快速的規劃模型。
• 成本：收費分為兩個維度——OpenAI 模型代幣與搜尋排名代幣。 查詢規劃呼叫由 Azure OpenAI 對輸入與輸出標記計費，而每個子查詢則由 Azure AI 搜尋服務 對必須排序的標記計費。 排名代幣在公開預覽初期是免費的。 事先估算你的工作負載所需的模型和排序代幣數量。
• 敏感輸入：整個對話紀錄會轉交給規劃模型，意味著任何可識別或商業敏感的資料都會離開你的即時信任範圍。 在調用 LLM 前，請移除、遮罩或修訂這類資料，並在您的資料保護態勢中記錄該緩解措施。
• 區域與預覽限制：代理檢索僅在有語意排序器的區域內使用。 個別代理人只能指向一個搜尋索引。 確認你資料和模型所承載的區域是否支援代理檢索，若需要跨越多個索引或地理區域，則規劃獨立代理。
• 合規性：確認使用以大型語言模型為驅動的查詢規劃器是否符合特定產業或區域性要求（例如資料駐留、隱私，或醫療或金融領域的自動決策規則）。 確保適當的人為監督與控制。 考慮加入控制措施，協助開發者及時驗證、審查及/或批准行動，可能包括檢視預定任務或呼叫外部資料來源。
• 法律與法規考量：使用者在使用任何 Foundry 工具與解決方案時，需評估潛在的具體法律與法規義務，這些工具可能不適用於所有產業或情境。 此外，Foundry 工具或解決方案並非設計用於適用服務條款及相關行為準則中禁止的用途。

Azure AI 搜尋服務中的 AI 擴充會使用服務的索引子和資料來源功能呼叫 Foundry Tools，以執行內容擴充。 此過程中所使用的索引器及資料來源的限制將適用。 請參閱索引器與資料來源文件以獲取相關限制的更多資訊。 Azure AI 搜尋服務 中 AI 豐富流程所使用的每個 Foundry 工具的限制也將適用。 請參閱 各服務的透明度說明 以了解這些限制。

技術限制、操作因素與射程

所有上傳到 Azure AI 搜尋服務 的向量，必須由服務外部使用您選擇的模型產生。 你有責任考量每個模型的技術限制與操作因素，以及它所建立的嵌入是否符合你的使用情境，甚至是否適合。 這包括從內容中推斷意義的推論，以及向量嵌入空間的維度。

向量化模型會建立一個嵌入空間，定義應用程式最終使用者的搜尋體驗。 如果模型與期望的使用情境不符，或產生的嵌入優化不佳，可能會對功能與效能產生負面影響。

雖然向量搜尋的許多限制來自於產生嵌入的模型，但在查詢時你還應該考慮一些額外的選項。 您可以從兩種演算法中選擇一種，以判斷向量搜尋結果的相關性：窮盡 k 最近鄰 (KNN) 或分層可導覽小世界。 窮盡 k 最近鄰 (KNN) 會對整個向量空間執行暴力式搜尋，透過計算所有資料點配對之間的距離，並尋找查詢點的精確 k 個最近鄰，找出與查詢最相似的相符項。 雖然演算法更精確，但速度可能較慢。 若低延遲是主要目標，可考慮使用階層式可導航小世界（Hierarchical Navigable Small World，HNSW）演算法。 HNSW 在高維嵌入空間中執行高效的近似最近鄰（ANN）搜尋。 更多相關資訊請參閱 向量搜尋文件 。

提升系統效能的最佳實務

• 請花時間在 A/B 測試你的應用程式，涵蓋你期望支援的不同內容和查詢類型。 找出哪種查詢體驗最適合你的需求。
• 請花時間測試包含完整輸入內容的模型，了解它在許多情況下的行為。 這些內容可能包含潛在敏感的輸入，以了解模型是否存在任何固有偏見。 Azure OpenAI 負責任 AI 概述提供了如何負責任地使用 AI 的指引。
• 請考慮在你的應用程式架構中加入Azure AI 內容安全。 它包含一個 API，用以偵測應用程式與服務中有害的使用者生成及 AI 生成文字或圖片。

評估並整合向量搜尋以供你使用。

為了確保最佳效能，請自行評估你計畫實施的解決方案，使用向量搜尋。 遵循評估流程，包括：（1） 利用部分內部利害關係人評估結果，（2） 利用 A/B 實驗向使用者推廣向量搜尋，（3） 在服務首次部署於體驗時納入關鍵績效指標（KPI）與指標監控，以及 （4） 測試並調整語意排序器配置及/或索引定義， 包括使用者介面擺放或業務流程等周邊體驗。

Microsoft 透過使用多元資料集，嚴格評估向量搜尋在延遲、回憶及相關性方面，衡量結果的速度、可擴展性與準確性。 評估的主要重點應放在選擇適合你特定使用情境的模型，了解模型的限制與偏見，並嚴格測試端到端向量搜尋的經驗。

技術限制、操作因素與射程

有時語意結果、說明文字和答案看起來可能不正確。 語意排名器所使用的模型是基於多種資料來源（包括 開放原始碼 及 Microsoft Bing 語料庫的精選資料）訓練的。 語意排名器支援 多種語言 ，並嘗試將使用者查詢與搜尋結果內容匹配。 語意排名器也是一項付費功能，且需額外付費，這在預測端到端解決方案的整體成本時應予以考量。

語意排序器最有可能在語意豐富的內容（例如文章和描述）中提升相關性。 它會尋找詞語之間的上下文與相關性，提升符合查詢內容更合理的匹配。 語言理解「尋找」內容中的摘要、說明和答案，但與 Azure OpenAI 服務 的生成模型 GPT-3.5 或 GPT-4 不同，它不會自行生成這些模型。 回應中僅包含來源文件的逐字文字，然後可在搜尋結果頁面呈現，提供更有效率的搜尋體驗。

目前使用最先進的預訓練模型進行摘要與排名。 為了維持使用者期望的搜尋快速效能，語意摘要和排名僅應用在由預設評分演算法評分的前 50 名結果上。 輸入是從搜尋結果中的內容推導而來。 它無法回溯搜尋索引，存取搜尋文件中未在查詢回應中回傳的其他欄位。 輸入受制於8,960個代幣長度。 這些限制是維持毫秒響應時間所必需的。

預設評分演算法來自 Bing 與 Microsoft Research，並整合於 Azure AI 搜尋服務 基礎架構中作為附加功能。 這些模型在內部使用，不對開發者開放，且不可配置。 欲了解更多關於支持語意排名器的研究與 AI 投資的資訊，請參見 Bing 的 AI 如何賦能 Azure AI 搜尋服務（Microsoft 研究部落格）.

語意排名器同時提供答案、說明文字及回應中的重點標示。 例如，若模型將查詢分類為問題，且對答案有 70% 信心，則回傳語意答案。 此外，語意說明會提供結果中最相關的內容，並提供簡短的片段，強調該摘要中最相關的詞彙或片語。

語意排名結果基於底層搜尋索引中的資料，模型則根據從索引取得的資訊提供相關性排名、答案與說明。 在正式環境中使用語意排序器之前，進行進一步測試並確保資料集準確且適合預期使用情境非常重要。 欲了解更多資訊及如何評估語意排序器的範例，請參閱 此處的內容與附錄。

系統效能

在許多 AI 系統中，效能通常以準確度為基準——也就是 AI 系統提供正確預測或輸出的頻率。 在大型自然語言模型中，兩個不同的使用者可能會對相同的輸出產生不同看法，對其實用性或相關性有不同看法，這意味著這些系統的效能必須更靈活地定義。 在這裡，我們廣義上認為效能是指應用程式能如你和使用者預期般運作，包括不會產生有害輸出。

語意排名器是基於公開內容訓練的。 因此，語意相關性會根據索引中的文件及針對索引的查詢而有所不同。 使用這些內容做決策時，務必運用自己的判斷和研究。

提升系統效能的最佳實務

• 請花時間用不同查詢類型來測試你的應用程式，例如關鍵字與混合式語意排名器。 找出哪種查詢體驗最適合你的需求。
• 請花時間根據 功能文件設定語意配置。
• 如果你對搜尋索引中資訊的準確性沒有信心，就不要輕信語意答案。
• 不要總是信任語意字幕，因為它們是透過一系列模型從客戶內容中提取，並預測出最相關的答案，以簡短片段呈現。

語意排名器的評估

評估方法

語意排名器透過內部測試評估，包括對多個資料集的自動與人工判斷，以及內部客戶的回饋。 測試包括依相關性或不相關性評分文件，並依相關性排序。 同樣地，字幕與回答功能也透過內部測試進行排名。

評估結果

我們努力確保所有模型更新不會造成退步（也就是說，更新後的模型應該只會提升目前的生產模型）。 系統會使用適合所評估功能的指標，將每個候選項目直接與目前生產模型進行比較 (例如，用於排名的標準化折扣累積增益，以及用於答案的精確度/召回率)。 語意排名模型透過使用涵蓋不同屬性（語言、長度、格式、風格與語調）的多元訓練資料進行訓練、調整與評估，以支援最廣泛的搜尋情境。 我們的訓練與測試數據來自：

文件來源：

• 學術與產業基準
• 客戶資料（僅測試，經客戶同意執行）
• 綜合資料

查詢來源：

• 基準查詢集
• 客戶提供的查詢集（僅測試，經客戶許可執行）
• 合成查詢集
• 人工產生的查詢集

用於評分查詢與文件配對的標籤來源：

• 學術與產業基準標籤
• 客戶標籤（僅測試，經客戶同意執行）
• 合成資料標籤
• 人工評分標籤

評估並整合語意排名器以供你使用

語意排序器的效能會因實際用途及使用者使用環境而異。 透過推動語意排序功能的深度學習模型所提供的相關性品質，與您的搜尋索引資料品質直接相關。 例如，目前模型的詞彙限制僅考慮前 8,960 個詞作為語意答案。 因此，如果搜尋查詢的語意答案是在長文件的末尾（超過8,960個標記限制）時，答案將不會被提供。 同樣的規則也適用於字幕。 此外，語意設定會依優先順序列出相關搜尋欄位。 你可以重新排序這份清單中的欄位，以幫助調整相關性以更符合你的需求。

為確保情境中最佳效能，客戶應自行評估所實施的解決方案，並使用語意排名器。 客戶通常應遵循一套評估流程，以下包括：（1） 利用部分內部利害關係人評估結果，（2） 利用 A/B 實驗向使用者推送語意排名器，（3） 在服務首次部署於體驗時納入 KPI 與指標監控，以及 （4） 測試並調整語意排序器配置及/或索引定義， 包括使用者介面擺放或業務流程等周邊體驗。

如果您正在高風險領域或產業開發應用程式，如醫療保健、人力資源、教育或法律領域，請評估該應用程式在您情境中的運作狀況，實施強而有力的人工監督，評估使用者對應用程式限制的理解程度，並遵守所有相關法律。 根據你的情況考慮其他緩解措施。

技術限制、操作因素與射程

有時合成查詢可能不正確、限制過多，或成本過高。 查詢重寫支援 多種語言 ，並嘗試重寫使用者查詢以最大化召回率，必須指定查詢語言作為輸入。 查詢重寫是 Semantic Ranker（Azure AI 搜尋服務 功能，旨在提升搜尋相關性）的一部分，這是一項付費功能，需額外付費。 這點在預測端到端解決方案的整體費用時應納入考量。 查詢重寫只有在啟用語意排序器時才能使用。

在正式環境（應用程式的正式版本）中使用查詢重寫之前，進行進一步測試並確保合成查詢適合預期使用情境非常重要。 欲了解更多資訊及評估查詢重寫的範例，請參閱 此處的內容與附錄。

系統效能

在大型自然語言模型中，兩個不同的使用者可能會對相同的輸出產生不同看法，對其實用性或相關性有不同看法，這意味著這些系統的效能必須更靈活地定義。 在這裡，我們廣義上認為效能是指應用程式能如你和使用者預期般運作，包括不會產生有害輸出。

查詢重寫的效能會因實際應用及使用者使用條件而異。 查詢重寫模型所提供的綜合查詢品質與原始搜尋查詢直接相關。

為確保其情境中最佳效能，客戶應自行評估所實施的解決方案，並使用查詢重寫技術。 客戶通常應遵循以下評估流程：

1. 利用部分內部利害關係人來評估結果，
2. 使用 A/B 實驗向使用者推出查詢重寫，且
3. 在首次部署服務於體驗時，納入關鍵績效指標（KPI）與指標監控

提升系統效能的最佳實務

• 為您的應用程式進行不同查詢類型（全文、向量、混合或其他查詢）的 A/B 測試。 找出哪種查詢體驗最適合你的需求。
• 不要總是假設每個由查詢重寫產生的合成查詢都能反映原始查詢的精確意圖。 合成查詢由經過微調的 SLM 產生，該系統產生的查詢語意與原始查詢的意圖相似，但可能不完全符合意圖。

查詢重寫評估

評估方法

查詢重寫透過內部測試評估，包括對多個資料集的自動化與人工判斷，以及內部客戶的回饋。 測試包括評估語意排序結果與查詢重寫的相關性，與僅用語意排序結果的相關性比較。

評估結果

每個候選模型會直接與目前部署的模型進行比較，並使用適合評估特徵的指標。 查詢重寫模型透過使用廣泛的公開資料來調整與評估，這些資料代表具有不同屬性（語言、長度、格式、風格與語調）的查詢，以支援最廣泛的搜尋情境。 我們的訓練與測試數據來自：

文件來源：

• 學術與產業基準
• 客戶資料（僅測試，經客戶同意執行）

查詢來源：

• 基準查詢集
• 客戶提供的查詢集（僅測試，經客戶許可執行）
• 合成查詢集
• 人工產生的查詢集

用於評分查詢與文件配對的標籤來源：

• 學術與產業基準標籤
• 客戶標籤（僅測試，經客戶同意執行）
• 合成資料標籤
• 人工評分標籤

評估並整合查詢重寫以供你使用。

由於查詢重寫是以公開內容訓練，因此合成查詢會根據向其發出的查詢而有所不同。 因此，使用這些內容做決策時，務必運用自己的判斷和研究。

技術限制、操作因素與射程

雖然生成式AI提示技能具備強大功能，但仍需了解某些限制：

• 這項技能依賴於 Foundry 內客戶設定的內容篩選功能。 Azure AI 搜尋服務 並未為此技能提供額外的內容安全機制。
• AI 生成內容的品質取決於提示的有效性及底層語言模型。 必須進行徹底測試，以確保產出符合所需標準。
• 處理大量資料並搭配複雜提示可能需要大量運算資源，並可能導致延遲。 明智規劃與分配資源，不僅維持效能與成本效益，也避免資料處理可能延誤。

系統效能

提升系統效能的最佳實務

為了優化GenAI提示技能的效能：

• 利用 Azure AI 搜尋服務 的 debug sessions 工具測試範例文件的提示，確保 AI 生成的內容符合預期，然後才全面部署。
• 設計清晰且詳盡的提示，有效引導語言模型，減少輸出不相關或不準確的可能性。
• 監控系統效能，並根據需要擴展資源，以應付 AI 處理的計算需求。
• 鼓勵在發表或發布前對產出進行人工監督。 有了生成式 AI，有可能產生可能冒犯或與當前任務無關的內容。

生成式AI提示技能評估

評估並整合生成式AI提示技能以便於你使用

為了在你的具體情境中最大化生成式AI提示技能的效益，請考慮以下步驟：

• 確定具體的豐富目標，例如產生簡潔摘要、擷取關鍵實體或建立描述性元資料，以使技能的應用與您的業務需求相符。
• 先從部分資料開始，評估技能表現並做出必要的調整。 此方法允許在全面部署前進行受控實驗與精進。
• 建立機制來監控 AI 生成內容的品質與影響。 徵求最終用戶回饋，以找出改進空間，並確保豐富資料符合用戶期望。

技術限制、操作因素與射程

有時，LLM 產生的子查詢可能無關、過於限制，或會提高代幣成本。 代理檢索支援 GPT-4o 家族所處理的所有語言，但產生的查詢計畫品質仍取決於使用者輸入的清晰度。 由於代理檢索依賴每個子查詢的語意排序器，因此你必須在索引上啟用語意排序器。 語意排名器是一種高級的代幣式功能;雖然在公開預覽初期會免除排名費用，但之後會生效，並應納入總擁有成本。

在將代理檢索導入生產環境前，請進行額外測試，以確認子查詢與回傳段落是否適合預期使用情境，延遲與成本是否符合服務水準目標，且接地資料不會暴露敏感或不合規內容。

系統效能

如同任何大型語言模型系統，不同使用者對回傳段落的有用性或相關性可能有不同判斷，因此效能必須靈活定義。 對於代理檢索，我們認為良好的效能意味著端對端應用程式能提供用戶期望的內容——且不會產生不可接受的延遲、成本或有害輸出。

代理檢索的有效性取決於許多現實世界的因素：

• 提示 / 對話歷史長度
• LLM 產生子查詢數量
• 索引大小與結構（關鍵字、向量、混合型）
• 規劃模型的選擇（GPT-4o 與 GPT-4o-mini）
• 語意搜尋配置與分數閾值

提升系統效能的最佳實務

• 總結或刪減舊的聊天回合，以保持代幣使用率低。
• 調整排名門檻，只回傳高度相關的段落
• 盡可能使用濾鏡

代理檢索的評估

代理檢索已透過內部測試評估，包括對多個資料集的自動化與人工判斷。 測試包括評估代理檢索結果與僅語意排序結果的相關性。

評估方法

每個候選代理檢索配置由其規劃提示詞、模型變體、子查詢數量及排名閾值來定義，並與生產基準線進行面對面的比較評估。 我們套用一系列針對多查詢檢索情境的相關性、安全性、延遲與成本指標。 為確保在實際應用情境下的可靠性，調整與測試會針對廣泛的公開與客戶核准資料集進行，這些資料集在語言、查詢長度、格式、風格及對話語氣上有所不同。 測試資料來源：

文件來源：

• 學術與產業基準
• 客戶資料（僅測試，經客戶同意執行）
• 查詢來源：
• 基準查詢集
• 客戶提供的查詢集（僅測試，經客戶許可執行）
• 合成查詢集
• 人工產生的查詢集

用於評分查詢與文件配對的標籤來源：

• 學術與產業基準標籤
• 客戶標籤（僅測試，經客戶同意執行）
• 合成資料標籤
• 人工評分標籤

評估並整合能動性檢索以供您使用

由於代理檢索規劃器主要以公開資料訓練，其產生子查詢的品質與相關性會因你的網域及特定使用者提示而異。 為了在您的特定情境中最大化代理檢索的效益，請考慮以下步驟：

• 在使用輸出前驗證其內容，以推動業務關鍵決策：手動檢查產生的子查詢樣本及回傳文件，確認其符合領域術語、準確性及合規要求。
• 向規劃師提供專屬領域的資訊。 提供同義詞地圖，以及完整的交談歷程記錄，這樣 LLM 便可以用與您的內容相符的語言改寫和分解查詢，以提升召回率和精準度。
• 實作備援或護欄邏輯：若規劃器產生低信心或超出範圍的子查詢，請將請求導向較簡單的關鍵字或向量搜尋，或向使用者呈現澄清提示，防止不可靠答案向下傳遞。