坑一：把 RAG 當成文件上傳功能
很多團隊第一步會把 PDF、內規、產品手冊、客服知識庫全部丟進向量資料庫，然後期待助理自然回答正確。這通常很快會遇到問題：文件版本混亂、段落切得太碎、表格內容失真、舊政策和新政策同時被召回，最後模型只能把不一致的材料包裝成一段看似合理的答案。
企業 RAG 的第一個工程重點是知識治理，不是 embedding。要先定義哪些文件是正式來源、誰負責維護、版本如何淘汰、文件更新後如何重新索引。若文件本身沒有明確標題、日期、部門、適用產品、適用地區，檢索階段就很難做出可靠判斷。
實務上，我們會建議先從高價值且邊界清楚的知識域開始，例如內部 IT 支援、產品規格查詢、客服 SOP 或業務問答。範圍縮小後，才容易建立文件標準、答案格式和回饋流程。先求可控，再逐步擴大，比一次導入全公司知識更穩。
坑二：只調模型，不設計檢索
RAG 的答案品質很大一部分取決於檢索，而不是最後那次生成。若召回內容錯了、少了或彼此衝突，再強的模型也只能在錯誤上下文裡猜。常見問題包括 chunk 太長導致噪音過多、chunk 太短導致上下文不足、只用向量相似度忽略關鍵字、沒有針對權威文件加權，也沒有針對時間或文件類型做過濾。
檢索設計需要看使用情境。客服問答通常重視標準答案與可追溯來源，工程知識庫可能需要保留程式碼片段和錯誤訊息，法務或合約類查詢則更需要精準引用和版本限制。不同場景適合不同切分策略、metadata、reranking 和 fallback 流程。
- 文件切分：依章節、標題、表格和語意邊界切，不只依固定字數。
- Metadata：保留來源、部門、版本、日期、權限、產品線與語言，讓系統能過濾而不是全庫亂找。
- Hybrid search：結合向量搜尋與關鍵字搜尋，處理型號、錯誤碼、專有名詞和精確條款。
- Reranking：在初步召回後重新排序，降低語意相近但不適用文件的干擾。
- 引用來源：讓答案附上來源段落或文件名稱，方便使用者判斷可信度。
坑三：忽略權限、資料邊界與稽核
企業 RAG 不是公司版搜尋框而已。它會把散落在雲端硬碟、ERP、CRM、客服系統、專案文件和內部資料庫的資訊重新組合成答案。若權限模型沒有跟原系統一致，AI 助理可能讓使用者看到本來不該看的客戶資料、薪資資訊、合約條款或研發文件。
正確做法是把權限視為檢索條件的一部分，而不是只在介面層做限制。使用者身分、部門、角色、專案成員資格、資料分類，都應該進入 retrieval pipeline。若後端串接 LINE、Slack、Teams、CRM 或 ERP，也要明確定義每個通道可讀取的資料範圍。
另一個常被低估的是稽核。企業系統需要知道誰問了什麼、系統召回哪些文件、模型輸出什麼答案、使用者是否採納或回報錯誤。這些紀錄不只是合規需求，也是後續改善檢索、文件品質和提示詞策略的主要依據。
坑四：沒有評測集，只靠感覺驗收
RAG demo 很容易看起來成功，因為測試者通常問的是系統剛被餵進去的資料，而且問題寫法接近文件標題。真正上線後，使用者會用口語、錯字、簡稱、跨部門語境和模糊需求提問。若沒有評測集，團隊很難分辨品質下降是因為文件更新、embedding 模型改變、chunk 策略不佳，還是提示詞造成。
評測集不需要一開始就很大，但需要真實。可以從客服紀錄、內部工單、業務常見問答、教育訓練題目和歷史搜尋字串整理。每題至少要標出期望答案、可接受來源、不可回答條件，以及是否需要轉人工或查原系統。
驗收時要同時看幾件事：是否召回正確文件、答案是否忠於來源、是否承認資料不足、引用是否可追溯、不同角色看到的答案是否符合權限。只看答案漂不漂亮，容易把風險藏起來。
坑五：上線後沒有人營運
RAG 上線不是結案。企業知識每天在變，產品改版、流程更新、人員異動、系統欄位調整，都會影響答案品質。若沒有資料擁有者、問題回報機制和定期評測，系統會慢慢變成另一個沒人信任的內部工具。
穩定的做法是把 RAG 當成產品營運。需要定期檢查高頻問題、無答案問題、錯誤引用、低信心回答和使用者負評。文件更新要能觸發重新索引，重大政策或價格調整要有優先更新流程，敏感資料要能快速下架。
企業導入 RAG 的核心不是追最新模型，而是把知識、系統、權限和使用情境接好。若內部已有 ERP、CRM、LINE 官方帳號、IoT 平台或雲端資料湖，最好從架構一開始就讓工程、資料治理和系統整合一起設計，後面會少很多補洞成本。