wen aidev
Published on

Azure AI Search 進階：RAG 資安防護與管線自動化

Table of Contents

這篇是我們 Azure AI Search 三部曲的「隱藏版第四關」。前三篇我們講完了檢索效能（Hybrid Search, RRF, Semantic Ranker），在 POC (概念驗證) 階段，這些技術能讓老闆看著精準的回答頻頻點頭。

但是，當你要把這個 RAG 系統推上正式環境時，真正的魔王才會出現。

本篇我們聚焦企業級 RAG 最痛的兩個問題點：權限資安 與 資料管線的維護地獄，並解析 Azure 在 2024–2026 年端出的兩大解藥。

痛點一：RAG 最大的資安危機 (越權存取)

在沒有導入 AI 的年代，員工登入內部知識庫搜尋「2024 年終獎金」，系統的 SQL 語法裡往往會夾帶他的 Role 或 Department。權限不符的檔案，他連檔名都看不到。

但 RAG 經常打破了這個防線。 開發者把好幾萬份 PDF 直接 Chunking、Embedding 後塞進 Vector Database。當基層員工向 Chatbot 詢問「2024 年終獎金怎麼發」時，無辜的 Vector Database 只知道幫你找「語意最相近」的 Top 5，於是：

  1. 總經理的「超級機密：2024 高階主管分紅草案.pdf」被撈了出來。
  2. LLM 讀了這份被餵進 Prompt 的機密文件。
  3. Chatbot 開心地回答：「根據最新草案，總經理今年考績 A 且可領 500 萬分紅喔！」

恭喜，明天公司群組就會炸鍋。這就是 RAG 系統最可怕的越權存取 (Unauthorized Access) 危機。

解藥：Document-level Access Control (文件級別存取控制)

在 Azure AI Search 中，解決這個問題的核心觀念叫做 Security Filters。我們必須在索引層面，就阻斷資料被檢索的可能性。

Azure AI Search Document-level access control 架構圖

圖說：同樣都搜尋「2024 獎金」，Azure AI Search 在底層就透過 Security Filter 依照身分權限，各自切割出獨立的可視結果。

方法 1：傳統的 String Comparison (Security Filters)

這也是目前最彈性、最泛用的做法。我們在 Index 的 Schema 裡多開一個欄位（例如 allow_group_ids），型態為 Collection(Edm.String)。

當文件切塊建 Index 時，把這份文件允許存取的「微軟 Entra ID Group ID」塞進去。 而在發起 Search Query 時，你的後端 API 先去 Entra ID 把發問者的所有 Group IDs 取出，然後套用 OData Filter：

// 搜尋 Request 的 JSON Payload
{
  "search": "2024 年終獎金",
  "vectorQueries": [...],
  "filter": "allow_group_ids/any(g: search.in(g, 'group-id-employee, group-id-it'))"
}

如此一來，Azure AI Search 在做任何 Hybrid 計算或 RRF 之前，就會先「物理隔絕」掉主管群組專屬的機密文件。

方法 2：2025 新趨勢 - Microsoft Purview Sensitivity Labels

微軟在最新的 Preview 版本中，開始深度整合 Microsoft Purview（微軟的企業資料保護與合規解決方案）。 未來的玩法是：當你在 SharePoint 或 Word 檔上面被標記了「極機密 (Highly Confidential)」標籤時，Azure AI Search 的 Indexer 抓檔案時會自動繼承這個紫色的敏感性標籤。檢索時，直接透過使用者的 Entra 權杖自動套用 Purview 原生政策進行過濾，開發者甚至連上述的 OData Filter 都不用手寫了！

為什麼不能靠 LLM 來守護資安？

新手常犯的錯是：把機密文件撈出來了，然後在 Prompt 裡寫 如果使用者身分是員工，請不要告訴他機密文件的內容。 這是極度危險的！ 任何稍微懂 Prompt Injection 的使用者，只要一句對話就能輕易繞過 LLM 的軟警語。

資安一定要做在 Retrieval (檢索) 層，而不是 Generation (生成) 層。

痛點二：手刻 Chunking 與 Embedding 的管線維護地獄

在傳統的 RAG 開發流程中，爬取一份 PDF 的常見流程長這樣：

  1. 寫一隻 Azure Function 去監控 Blob Storage。
  2. 用 Python 搭配 LangChain 或 LlamaIndex，將 PDF 切割成一個個 500 字的 Chunk（還要處理 overlapping）。
  3. 寫 For-loop 呼叫 text-embedding-3-small API，把 Chunk 轉成向量矩陣。
  4. 呼叫 Azure AI Search API，把字串與向量存進去。

只要 API 改版、切塊策略想從 500 字改成 300 字，或是想要換另一個維度大小（Dimension）的 Embedding 模型，整串 Python Code 就要重練，維護成本極高。

解藥：Integrated Vectorization (整合式向量化)

這項在 2024 年中推出、並於下半年與 2025 年陸續 GA 的功能，徹底終結了手刻爬蟲的時代。

所謂的 Integrated Vectorization，就是 Azure 把上述的所有髒活全包了：

  • Split Skill：內建直接把長文章切碎的功能，可自由設定 Token 數量與 Overlap 比例。
  • AzureOpenAIEmbedding Skill：你不用寫程式去 Call API，只要設定好你的 OpenAI Endpoint，Indexer 跑到一半就會自己把文字甚至圖片送到模型那邊轉成 Embedding。

你只需要在 Azure 入口網站點幾下，設定一個 Skillset (技能集)。以後只要有任何新的 PDF 被丟進 Blob Storage，它就會自動被觸發 →\rightarrow 自動萃取內文 →\rightarrow 自動 Chunking →\rightarrow 自動 Embedding →\rightarrow 自動更新進 Search Index。

這不只讓 RAG 流程變成了「Low-Code/No-Code」，更讓架構變得無比穩定且易於監控！

結語

在這四大篇 Azure AI Search 系列中，我們從基本的 Keyword vs Vector、完美的 Hybrid 混合搜尋理念、高竿的 Semantic Ranker 語意重排，一路講到了正式上了戰場後必須面對的 Document-level 資安控制與全自動向量化管線。

要把 RAG 做好，LLM 模型固然重要，但決定 RAG 天花板的，永遠是你的檢索系統 (Retriever) 有多強大。掌握這四篇文章的架構，你的企業大腦將會精準、聰明，而且無懈可擊！

(Azure AI Search 全面解析系列 全文完)

留言討論