上一篇把 RAG 的用途與風險列出來了。接下來進入 PoC 驗收，我會先準備好資料與驗收條件：哪些文件能放進來、誰能查，以及怎麼知道回答是合適的。

本篇名詞小筆記

• Milvus：開源向量資料庫，用來儲存向量並執行相似度搜尋。
• Embedding：嵌入向量，將文字轉成數值表示，讓系統可以計算語意相似度。
• HNSW：Hierarchical Navigable Small World，一種近似最近鄰搜尋索引，用來加快向量查詢。
• Metadata Filter：中繼資料過濾，在向量檢索時依權限、版本或分類先排除不符合條件的文件。
• Top-K：相似度最高的前 K 筆結果；K 代表預計取回的資料筆數。

今天要解決的問題

放進幾份文件，問幾個問題，答案大致正確，看到這裡很容易覺得已經可以用了。不過，我還會繼續確認文件版本與權限。企業裡每個人能看的資料不同，這一段也要真的測過。

例如，回答引用了一份使用者原本沒有權限看的文件。內容可能答得很正確，權限卻出了問題。如果一直用管理員帳號測試，就很容易漏掉這個情況。

架構師視角：資料來源白名單與檢索關係

每份候選文件，我會先記錄負責人、來源、版本、有效日、機密等級、允許群組與保留期限。擁有者核准、版本與分類都確認後，再納入 PoC。文件撤回或權限調整，索引也要跟著更新。

下面的圖先整理文件進庫與查詢取回這兩條路徑：文字由 Embedding 模型轉成向量存進 Milvus，查詢則經過 HNSW 索引與權限過濾，才取回 Top-K 結果。這一套最後是否採用，還是要看 PoC 的資料量、權限過濾、召回品質、延遲與維護成本。

圖 Day 22-1：檢索與權限過濾路徑。

無權查看的內容，不能被帶進模型輸入，所以我會特別看圖裡權限 Filter 的位置：檢索時就要排除這些片段。這一段除了正常查詢，也要換不同群組的帳號測試。

另外，原始文件已經不能用了，系統卻還持續拿舊內容回答，這是要避免的。所以文件更新事件發出後，有一個 consumer 監聽它，先刪掉舊的 chunk，再在背景重新索引；撤回也走同一條路，只刪不重建。同步方式已經定了，從事件發出到索引更新的延遲上限，還要在 PoC 量測。

工程師視角：權限、引用與拒答規則

原本的資料權限要一路保留。使用者不能看的文件，在檢索階段就排除，不先交給模型再要求它隱藏。所以可見範圍不是由呼叫端在請求裡指定，而是後端依登入身分算出來，再交給向量資料庫當過濾條件；呼叫端就算多填了範圍也會被忽略。有一支測試會刻意在請求裡多填範圍，確認取回的結果沒有因此變多。

遇到 SOP 改版時，使用者要知道自己看到的答案來自哪一份內容。所以回答也要讓人找得到出處，來源、版本與引用段落都列出來。

資料不夠、內容衝突、文件過期或權限不足，都要有對應的拒答或人工處理方式。內容衝突指的是檢索回來的片段對同一個問題講法互相矛盾，最常見的是同一份 SOP 的新舊版本同時被取回。呼叫端要知道是哪一種，後面才有辦法接手，所以四種都先分類回覆：

• 資料不夠：回「找不到相關內容」，後續補資料。
• 內容衝突：回「內容不一致，已轉人工」，系統不挑一邊回答，由文件擁有者確認哪一版有效。
• 文件過期：回「內容全部過期」，請文件擁有者確認。
• 權限不足：回「有內容但使用者沒有權限看」，不透露任何片段，只說應該向誰申請。

策略取捨與限制

前面要準備的事情不少，所以範圍可以先小一點。挑低風險、能人工覆核的情境，驗證好資料與權限，再慢慢擴大，也比較容易掌握每一步的結果。

驗證方式與衡量指標

PoC 先建立固定題庫：一組不再變動的提問，每題事先標好應該被檢索到的來源，之後調參數、換資料都用同一份重測。再分別測試資料納管、權限隔離、檢索、生成、拒答與稽核紀錄：

要分享結果時，大家得知道數字是怎麼來的，所以樣本、資料集、環境與計算方式也一起寫出來。

今天先整理到這裡

把資料與權限準備好，再看檢索與回答的結果，最後決定可用範圍，這是我想採取的順序。下一篇，回到 API，看看限流、逾時、重試與冪等怎麼一起安排。

參考資料

1. OWASP, LLM Top 10，查閱日期：2026-10-05。
2. NIST, NIST AI RMF，查閱日期：2026-10-05。
3. Milvus, Milvus Documentation，查閱日期：2026-10-05。