Enterprise RAG 完整指南：檢索架構、評估與企業落地

Enterprise RAG 的目標不是讓模型「看過更多文件」，而是在正確的身分與時間點，把可追溯的證據送進生成流程，並能量測答案是否真的改善。只做切塊、Embedding 與向量搜尋，通常很快就會撞上權限、版本、表格、多跳問題與無法診斷的錯誤。

這篇核心指南把 RAG 視為一條可治理的知識供應鏈，從資料進入、索引、檢索、重排、上下文組裝，到生成、評估與營運逐層說明。

一、Enterprise RAG 與一般問答有何不同？

企業情境至少多出五項要求：

• 權限一致：搜尋結果必須遵守來源系統的使用者、群組與租戶權限。
• 版本與時效：過期文件、重複版本與撤回內容不能持續影響答案。
• 可追溯：答案要指出使用了哪一段、哪個版本與何時擷取的內容。
• 可評估：能區分是沒找到、排序錯誤、上下文組裝失敗，還是模型生成錯誤。
• 可營運：在延遲、成本、更新頻率與服務等級之間做明確取捨。

因此，Enterprise RAG 不是單一模型功能，而是搜尋、資料工程、LLM 應用、安全與平台營運的交集。

二、完整 RAG 管線

1. 來源與擷取

先建立來源清冊：擁有者、敏感等級、更新方式、可用欄位與刪除機制。擷取時保留來源 URL、文件 ID、版本、時間與 ACL；如果這些資訊在入口遺失，後面很難補回治理能力。

2. 解析與切塊

切塊要跟文件結構與使用情境一致。標題、段落、表格、程式碼與頁面位置都應成為 metadata。固定字數只是基線；過小會失去上下文，過大則降低命中精度並浪費 token。

3. 索引

企業搜尋通常同時保留 lexical 與 vector 索引。前者擅長產品代號、專有名詞與精確字串；後者擅長語意相近但用詞不同的查詢。結構化關係或多跳問題，才考慮加入知識圖譜。

4. 查詢理解與檢索

先處理語言、縮寫、時間範圍與必要 filter，再執行搜尋。Hybrid Search 應以可量測的融合方式合併結果，而不是盲目增加更多 retriever。查詢改寫也要保留原始意圖，避免模型把問題改成另一件事。

5. 重排與上下文組裝

Reranker 解決「有找到但排序不對」；上下文組裝則負責去重、涵蓋不同子問題、控制 token 預算與保留引用。Top-k 越大不代表答案越好，噪音可能讓模型忽略真正證據。

6. 生成與回答政策

Prompt 應要求模型只依允許的證據回答、標註引用，並在證據不足或互相矛盾時清楚說明。對高風險領域，答案可能還需規則驗證或人工確認。

7. 回饋與評估

每次查詢保存匿名化且合規的檢索結果、重排分數、最終上下文、引用與回饋。沒有這條 trace，就無法知道改模型、改索引或改 Prompt 到底改善了哪一層。

三、如何選擇 RAG 架構？

架構	適合情境	主要代價
Vector RAG	語意查詢、內容相對同質	專有名詞與精確條件可能漏找
Hybrid RAG	多數企業文件與搜尋場景	需要融合、filter 與重排調校
GraphRAG	關係密集、多跳與全域摘要	建圖、更新與查詢成本較高
Agentic RAG	需動態選來源、分解問題或反覆驗證	延遲、成本與執行路徑更難控制
Multimodal RAG	文件含圖表、版面與影像證據	解析、索引與評測更複雜

預設建議從 Hybrid RAG 加 reranker 開始。只有評測證明瓶頸來自關係推理、跨來源規劃或視覺資訊時，才增加 Graph、Agent 或多模態能力。

四、RAG 要評估什麼？

不要只問「答案看起來好不好」。將評測拆成五層：

1. 檢索：Recall@k、MRR、nDCG，以及必要證據是否進入候選集合。
2. 上下文：證據是否相關、完整、無重複且符合 token 預算。
3. 答案：正確性、faithfulness、完整性、引用覆蓋與拒答品質。
4. 安全：ACL 洩漏率、跨租戶存取、敏感內容與 Prompt Injection 防護。
5. 營運：P50/P95 延遲、每次查詢成本、索引新鮮度與錯誤率。

評測集應從真實任務抽樣，涵蓋簡單查找、多跳、時間敏感、表格、同名實體、無答案與權限不足案例。主觀評分可用 LLM 輔助，但高風險題與抽樣校準仍需要人類判讀。

五、權限與知識治理

最安全的方式是在檢索階段套用 ACL，而不是先取回所有內容再要求模型忽略。索引要能同步刪除與權限異動；快取鍵必須包含租戶與權限範圍；引用頁面也要再次授權，避免答案沒洩漏、點進來源卻越權。

每個 chunk 至少應知道：來源、版本、擁有者、擷取時間、有效期限、語言、文件結構位置與可存取主體。對高度敏感資料，可採獨立索引、獨立加密鍵或完全不同的服務邊界。

六、常見失敗如何診斷？

症狀	先檢查	常見改善方向
完全找不到已知文件	擷取、解析、filter、索引新鮮度	修資料管線，不要先改 Prompt
找到相關內容但答案錯	重排、上下文與生成 trace	改 reranker、去重或回答政策
專有名詞常漏找	lexical 命中與 query normalization	加 Hybrid Search、字典或精確 filter
多跳問題只答一半	子問題覆蓋與來源關係	query decomposition、Graph 或 Agentic RAG
答案引用過期版本	version metadata 與刪除同步	建立有效期間和 authoritative source 規則
延遲或成本過高	各階段耗時與 token	快取、縮小候選、並行化與模型路由

診斷原則是先找到失敗發生的層級，再改對應元件。直接換更大的模型，常會掩蓋資料或檢索缺陷，卻讓成本上升。

七、從 PoC 到正式環境的路線

1. 選定一個知識領域與 50–200 個代表問題。
2. 建立 lexical、vector 與 Hybrid 基線，分開量測檢索與答案。
3. 接上來源版本與 ACL，驗證刪除、異動與跨租戶隔離。
4. 加入 reranker、引用與證據不足時的拒答。
5. 以 trace 進行錯誤分類，只針對已證實瓶頸升級架構。
6. 設定品質、P95 延遲、單次成本與索引新鮮度的上線門檻。

八、主題閱讀路徑

建議依序閱讀：

1. Agentic RAG：向量搜尋遇上代理推理
2. PixelRAG：以視覺證據處理複雜文件
3. Open Knowledge Format：讓知識可攜與可治理
4. Graph RAG 與 LLM：關係檢索與多跳推理
5. 金融 GenAI 平台工程：企業級 RAG 的治理與營運
6. LangChain OpenWiki：從開放知識建立檢索系統

完整落地成果可看 Agentic RAG 企業知識助理案例：以 98% 加權準確率與 2.6 秒平均延遲，驗證檢索、工具路由與回答流程。若需要進一步設計執行型代理，接著讀 AI Agent 完整指南。

九、限制與取捨

RAG 無法讓低品質、互相矛盾或沒有治理的知識自動變可靠，也不能保證模型對證據做出正確推論。更複雜的架構通常能處理更多問題，但也會增加資料更新、評測與營運成本。

可持續的做法是：先把資料、權限、基線與評測做好，再用實際失敗案例證明是否需要 GraphRAG、Agentic RAG 或更大的模型。