同事要在多個地方反覆搜尋
政策、工作手冊、個案記錄及產品資料可能分散在共享硬碟、業務系統和資料庫。
企業 RAG 及 AI 知識系統
讓團隊從公司知識中找到有出處的答案
將獲批准的文件、資料庫及內部系統接駁至 AI 助手。每次查詢先按使用者權限篩選資料，再檢索相關內容，回覆時附上來源，方便團隊核對。
RAG 可以減少缺乏根據的回覆，但不保證每個答案都正確。我們會按工作風險設定引用來源、拒答、評估及人工覆核規則。
資料流程示意
先核對權限，再檢索及生成答案
只有使用者獲准查閱的資料，才會進入本次檢索及模型上下文。
- 01
已登入使用者
查詢附有已驗證的身份及角色資料。
- 02
權限檢查
檢索前先套用資料來源及租戶篩選。
包括獲准資料來源排除受限制資料 - 03
混合檢索
語義及關鍵字搜尋找出相關段落，再整理排序。
- 04
附來源回覆
助手按檢索所得資料回答，並列出引用來源。
有來源支持的答案現行程序要求發布前取得批准。[1] 例外情況應按既定途徑上報。[2]
[1] 程序第 4.2 節[2] 上報指引
全流程控制
- 評估題目
- 審計記錄
- 資料更新狀態
回覆規則
回答 · 拒答 · 交由人員處理
困難不只在於接駁 AI 模型
公司知識通常分散在不同文件和系統，資料負責人、更新時間及查閱權限各有不同。知識助手要真正幫到日常工作，必須先處理這些現實問題。
資料更新後沒有清晰同步安排
如果系統沒有處理刪除、替換及重新建立索引，答案可能引用已過時的文件。
每位使用者可看的資料不同
當部門、客戶或租戶的權限各異，一個不設權限的共用搜尋索引並不足夠。
團隊未有一致的答案評估方法
如果沒有代表性問題及預期引用資料，團隊很難判斷檢索質素是改善了，還是純粹變了。
受管控的知識系統可以處理甚麼
適合先從一個可清楚界定資料、使用者、權限及覆核人的流程開始。以下是常見起點，並非預製產品。
內部政策及程序搜尋
協助員工找到現行指引，執行工作前可以開啟引用段落核對。
客戶服務及技術支援
檢索獲批准的故障排查、服務及產品資料，遇上例外情況時交由人員跟進。
產品及銷售知識
從持續更新的目錄、規格及獲批准商業資料中回答詳細問題。
員工入職及營運指引
按職能提供相關程序，同時避免顯示與工作無關的內部內容。
受權限管控的記錄查詢
就一個明確營運問題，整合可查閱的文件、資料庫記錄及 API 結果。
正式使用前，
評估不只看答案措辭，也要檢查系統選了哪些證據。試點開始前，我們會先訂好測試問題、失敗時的處理方式及覆核負責人。
- 01
資料及引用是否相關
檢查檢索段落能否支持答案，以及引用是否指向正確章節。
- 02
具代表性的測試問題
按實際工作準備一般、含糊、過時及帶有誤導性的問題。
- 03
證據不足時的處理
當獲准資料未能支持答案，助手應拒答或交由指定人員處理。
- 04
權限及租戶測試
確認使用者無法檢索或推斷其角色、機構或記錄範圍以外的內容。
- 05
資料更新週期檢查
測試更新、刪除、替換及重新建立索引，避免系統繼續使用已作廢內容。
- 06
營運監察項目
在已訂服務範圍內監察檢索質素、回應時間、模型用量及成本。
權限情境示意
內容進入模型前，
使用者身份、資料負責人及查詢時篩選會一同運作。模型只應收到這位使用者就本次查詢有權檢索的資料。
- 接駁 OAuth2、SAML 或 Active Directory
- 查詢時按 metadata 篩選
- 租戶及文件級資料分隔
- 記錄證據及回覆決定
使用者身份
營運經理 · 已驗證員工角色
此角色可以查閱
現行營運程序及已批准產品手冊
不會進入檢索
人事文件及負責範圍以外的客戶記錄
可以提供的結果
只按獲准段落作答，列出引用來源並保留審計記錄
技術架構
按資料特性及管控要求選擇檢索架構
實際組合取決於文件質素、更新頻率、語言、資料量、回應速度及部署要求。以下模式會按用途選用，不一定全部需要。
01文件及數據匯入
自動 ETL 流程可處理 PDF、DOCX、JSON 及 API payload，配合版面感知 OCR、metadata 擷取，以及 recursive 或 sliding-window 分段。每項資料同時保留負責人、版本及權限資料。
02混合檢索
密集向量檢索可按需要採用 HNSW 或 Flat 索引，以及 cosine 或 inner-product 距離。BM25 負責關鍵字配對，再以 Reciprocal Rank Fusion 合併候選結果。
03Cross-encoder 重新排序
Cohere Rerank 或 BGE-Reranker 等次級模型，可在組合 prompt 前重排 top-k 候選內容，減少無關上下文及不必要的 token 用量。
04按權限檢索
企業身分系統可透過 OAuth2、SAML 或 Active Directory 接駁。查詢時的 metadata 篩選會先套用租戶、角色及文件規則，才把文字加入模型上下文。
05評估及日常營運
版本化測試題目、檢索記錄、引用檢查、審計日誌、資料更新工作及用量監察，讓發布後的變更可以追查及覆核。
先釐清工作流程及資料界線，
OpenAI、Claude、DeepSeek 及 Qwen 可作為生成或推理模型的評估選項。選擇時要按部署方式、供應商條款，以及模型在既定測試題目的實際表現作決定。
OpenAI
工具整合、模型能力及企業管控
Claude
長上下文及文件量較多的流程
DeepSeek
需要評估成本及部署安排的用途
Qwen
需要評估中文表現及部署安排的用途
選擇準則
- 數據處理方式
- 語言表現
- 回應時間及成本
- 上下文及工具支援
- 託管限制
先做好有限度試點，
試點應集中測試一個實際流程，並使用真實權限及具代表性的問題。確定證據、失敗處理及營運負責人後，才逐步擴大使用範圍。
- 01
檢視資料來源及權限
整理使用者、問題、系統、資料負責人、敏感程度及更新安排。
- 02
建立有限度試點
匯入已批准的資料，接駁一個有實際用途的使用流程。
- 03
評估檢索及答案
量度證據相關度、引用、拒答、權限規則及回覆質素。
- 04
接入日常工作流程
整合身份驗證、應用、API、覆核隊列、日誌及支援流程。
- 05
持續監察及改善
擴大範圍前，先檢查資料變更、失敗問題、用量、回應時間及成本。
系統仍需要人員管理的部分
RAG 改變的是尋找及呈現證據的方法，不會取代資料質素、權限或業務決定的負責人。
- 答案即使附有引用，也可能誤解內容或遺漏重要背景。高風險決定仍需安排合適人員覆核。
- 如果獲准資料不完整、互相矛盾或未有更新，回覆也可能出現同樣問題。
- 權限控制依賴正確的身份、metadata 及資料來源設定。角色或連接方式改變後，需要重新測試。
- 模型及檢索表現會隨設定、資料內容或供應商更新而改變，正式使用後仍要繼續評估。
Private AI、雲端或混合部署
選模型前，先決定哪些資料可以離開機構。私有託管本身不代表安全，仍要審視權限、記錄，以及傳送至每項外部服務的資料。
| 部署方式 | 資料及模型安排 | 運作及維護責任 |
|---|---|---|
| 雲端模型服務 | 把獲准使用的檢索內容傳送至模型供應商，先核對保留政策、處理地區及可傳送的資料。 | 供應商管理模型；項目仍需處理資料接駁、權限、用量及支援。 |
| 私有部署 | 在議定的私有環境運行檢索和所選模型，並核實遙測及配套服務沒有超出資料邊界。 | 需要規劃運算容量、模型更新、備份及評估。即使用量不高，專用基建仍可能產生固定成本。 |
| 混合部署 | 把指定資料來源或檢索服務留在私有環境，只向雲端模型傳送獲准內容。必須確認實際傳出的資料。 | 需要維護兩邊的連接，包括資料篩選、身份驗證、網絡故障及供應商變更。 |
FAQ
常見問題
企業 AI 知識庫的成本包括甚麼？
初期工作量取決於文件解析和整理、資料接駁、權限對應及評估要求。運行費用則包括索引更新、模型用量、儲存、監察及支援。應先用具代表性的問題和文件格式試行，再估算較大規模部署。
甚麼是 RAG 檢索增強生成？
RAG 會先從已批准的資料來源檢索相關內容，再把內容交給 AI 模型作為回答依據。這可讓答案較容易追查，但不代表每次回答都正確。
企業知識系統可以使用哪些資料？
項目可按需要處理 PDF、DOCX、結構化數據、資料庫、API 及現有知識庫。每種來源都需要合適的解析、metadata、更新、刪除及權限處理。
系統可否沿用現有用戶權限？
可以，但需要正確對應身份、來源權限、metadata 及索引邊界，並經過測試。實際做法取決於機構的身份系統、資料庫、租戶模式及部署環境。
RAG 可以防止 AI 提供錯誤答案嗎？
不可以。資料質素、文件解析、檢索設定、權限資料及模型行為都會影響結果。我們會按議定情境設定引用、拒答、評估、記錄及人工覆核安排。
系統可以接入哪些 AI 模型？
系統可按需要接入 OpenAI、Claude、DeepSeek 或 Qwen 等服務。實際模型和供應方式會按語言、資料政策、部署、回應時間、成本及整合要求確認。
一起釐清範圍、時間表及下一步
先從團隊真正需要回答的問題開始
準備一小批具代表性的問題、相關資料來源，以及應該有權使用的人員。我們可以一起釐清資料界線、試點範圍及判斷成效所需的證據。
第一步是實際討論範圍，不會預先假設 AI 可以取代流程負責人。
