RAG 的成敗，不在檢索而在知識庫：為何我們該談的是 Knowledge Operations

在導入生成式 AI 應用時，我們常過度專注於 RAG（檢索增強生成）的技術細節，卻忽略了更根本的問題。許多 RAG 專案之所以無法發揮預期效益，並非檢索演算法不夠先進，而是底層的知識庫本身就是一團迷霧。事實上，RAG 的真正瓶頸往往是個知識運維（Knowledge Operations）問題。若不從源頭解決數據品質，再強大的 AI 模型也只會產出精美的垃圾，這對追求可靠性的企業級應用而言，無疑是致命傷。

為什麼我們的 RAG 系統會「一本正經地胡說八道」？

許多團隊都遇過這種情況：一個精心調校、基於內部文件的問答 AI，卻給出令人啼笑皆非的答案。它可能引用一份三年前的專案草稿來回答目前的產品規格，或將某次客戶投訴的特殊處理方式當成標準作業流程。這並非典型的模型「幻覺」（Hallucination），因為 AI 並沒有憑空捏造，它確實「看見」了這些資訊。日本開發者 continuitymodel 將這種現象稱為「參照污染」（Reference Pollution）。

參照污染的核心問題在於，AI 無法區分資訊的「狀態」與「權威性」。在它眼中，一份放在共享硬碟裡、標題為 產品計畫_final_v3_final.docx 的文件，與正式發布在內部知識庫的官方文件，具有同等的參考價值。當知識庫中充斥著草稿、過期版本、個人筆記與未經核准的流程文件時，AI 就會像一個勤奮但缺乏判斷力的實習生，將所有找到的資料都當成事實。一份 2024 年的研究報告 "Seven Failure Points When Engineering a Retrieval Augmented Generation System" 也指出，資料來源的品質是 RAG 系統最常見的失敗點之一，其影響遠大於檢索演算法的選擇。

參照污染的根源：當知識庫成為數位垃圾場

參照污染並非技術問題，而是組織知識管理的沉痾。多年來，企業的數位文件散落在四處：Confluence、SharePoint、Google Drive、甚至個人的 Slack 訊息中。這些地方往往缺乏統一的管理規範，逐漸演變成數位垃圾場。當我們試圖將這些未經整理的資料直接餵給 RAG 系統時，無異於要求 AI 在垃圾堆裡找出黃金。

這些「數位污染物」通常可以歸為幾類：

• 版本混亂（Version Chaos）： 文件缺乏明確的版本號與發布狀態，大量的 `_draft`、`_v2`、`_old` 檔案同時存在，AI 無法判斷何者為最新、最權威的版本。
• 狀態不明（Ambiguous Status）： 文件沒有生命週期的概念，草稿、審核中、已發布、已封存的文件混雜在一起。AI 可能會引用一份已被否決的提案內容。
• 脈絡喪失（Context Loss）： 獨立的會議記錄、腦力激盪的筆記、或是 email 中的片段討論，脫離了原始脈絡後，其資訊可能產生誤導。
• 例外流程（Exception Handling）： 為了應對單一客戶或特殊市場所制定的臨時方案，被 AI 誤解為所有情況都適用的標準流程。

這些問題由來已久。事實上，許多資料科學研究都指出，資料清理與準備工作佔據了從業者高達 80% 的時間。如今，這個挑戰從結構化數據延伸到了非結構化的知識文件。在 AI 時代，知識庫的整潔度，直接決定了 AI 應用的天花板。

如何建立一個「AI-Ready」的知識庫？

解決參照污染的根本之道，是將 RAG 專案從一個單純的技術導入，升級為一次推動「知識運維」（Knowledge Operations, 或稱 Knowledge Ops）的組織級別行動。

如同 DevOps 改變了軟體開發與維運的文化，Knowledge Ops 旨在為組織的知識資產建立一套系統化的生命週期管理流程。其終極目標是讓知識庫從一個被動的儲存容器，轉變為一個主動管理、值得信賴的「單一事實來源」（Single Source of Truth, SSOT）。

具體而言，我們可以從幾個方向著手：

1. 建立權威性指標： 為所有文件引入明確的狀態標籤，例如「草稿 Draft」、「審核中 In Review」、「已發布 Published」、「已封存 Archived」。這是最基本也最關鍵的一步。RAG 系統在檢索時，應預設只查詢「已發布」狀態的文件。
2. 善用元數據（Metadata）： 除了內容本身，文件的元數據同等重要。為文件加上如建立日期、最後更新日、作者、適用部門、有效期限等元數據，能大幅提升檢索的精準度。例如，AI 可以根據使用者的問題，篩選出「過去一年內」且「由法務部門發布」的相關文件。許多向量資料庫（如 Pinecone）都已支援基於元數據的過濾查詢，這應成為 RAG 架構的標準配備。
3. 導入生命週期管理： 知識文件也應該有生命週期。建立定期的審核機制（例如，每季或每半年），由文件的負責人或部門確認其內容是否依然有效。過時的資訊應被明確標示或直接歸檔，而不是留在原地製造噪音。

你的 RAG 系統，能力上限取決於你知識庫的最低標準。與其不斷更換 embedding 模型，不如先從建立一份乾淨、可信的知識來源開始。

從 2020 年 RAG 概念被提出至今，社群的討論大多集中在 chunking 策略、embedding 模型選擇、或是更複雜的檢索 Agent 架構。這些固然重要，但它們都建立在一個理想的假設之上：我們的知識庫是乾淨且可信的。然而在真實的商業世界，這往往是錯的第一步。與其追求技術上的邊際效益，不如回歸基本功，將 RAG 專案視為一次徹底改革內部知識管理的契機。這不僅能讓 AI 應用真正落地，其帶來的組織紀律與效率提升，價值可能遠超 AI 本身。

延伸閱讀

• RAGの隠れた失敗モード：参照汚染とBRMという設計思想
• Seven Failure Points When Engineering a Retrieval Augmented Generation System
• Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks
• What is knowledge management and why is it important?

我是江中喬，一位具有 TPM 與產品管理背景的 AI 系統建構者，目前專注於 AI 認知增強系統與多 Agent 協作架構的設計與實踐。