如何用資料合約在30分鐘內解決AI幻覺問題：技術實作步驟與驗證方法

今天來聊聊 AI 幻覺 (Hallucination)。對，就是大型語言模型（LLM）一本正經胡說八道的那個問題。你一定遇過，問它個公司內部規定，它給你一個根本不存在的版本，還附上假的連結。這問題真的很煩，而且超危險。

很多人以為解決方法是換個更強的 AI 模型、或餵它更多資料。我自己是覺得... 這方向可能從一開始就錯了。問題的核心，往往不是模型不夠聰明，而是它吃的「資料來源」太亂、沒人管。

重點一句話

想在半小時內大幅降低 AI 幻覺？別再糾結模型了，從「資料合約 (Data Contracts)」下手，嚴格控管 AI 能接觸到的事實來源。

為什麼 AI 總是在胡說八道？

你一定看過這種場景。公司導入一個很酷的聊天機器人，號稱能回答所有內部知識。結果...

狀況一：無中生有。 員工問：「最新的差旅費報銷上限是多少？」AI 回答了一個數字，但沒人知道這數字哪來的。完全沒有來源，跟都市傳說一樣。
狀況二：時空錯亂。 AI 抓到了「差旅費政策」文件，但抓到的是三年前的舊版本。員工照著去做，結果被財務退件。這比完全找不到還慘。
狀況三：團隊內戰。 A 團隊說 AI 講的才是對的，B 團隊說他們手上的文件才是最新版。兩邊吵半天，沒人能證明 AI 的答案究竟是基於哪個檔案的哪一段。

老實說，這根本不是 AI 的錯。你把一個人丟進一個塞滿了過期文件、錯誤標籤、還有各種小道消息的圖書館，然後要他立刻給你正確答案... 他大概也會瘋掉。AI 就是那個可憐的傢伙。

那些「聽起來有用」卻沒效的解法

為了解決幻覺，大家通常會試幾招。但說真的，單獨使用它們，效果很有限。我把它們跟「資料合約」這個思路放在一起比較，你馬上就懂了。

常見解法	為什麼常常會失敗？	「資料合約」的思路是？
換個更大的模型 (e.g., GPT-5)	更聰明不等於更老實。學術測試（像史丹佛最近的研究）都說了，大模型在壓力下還是會瞎掰。它只是掰得更流暢、更讓你看不出破綻。	模型是「大腦」，不是「事實來源」。我們不換大腦，而是給它一本經過驗證、有頁碼的「教科書」。
餵它更多文件	這根本是災難。沒有整理過的資料倒進去，只是增加噪音。AI 從 100 份垃圾裡找答案，跟從 10000 份垃圾裡找答案，找到對的機率... 你懂的。	重質不重量。先把那一本「教科書」定義清楚。寧可 AI 只懂三件事但都懂對，也不要它懂三百件事但都懂錯。
要求 AI 附上引用來源	在沒有嚴格控管下，AI 給的引用連結可能是壞的、連到舊版的、甚至是它「幻想」出來的。裝飾作用大於實際意義。	引用是「結果」，不是「手段」。我們要先建立一個可信的、有版本號的資料庫，然後「強制」AI 只能從這裡面引用，而且連結必須有效。

怎麼做：用「資料合約」三步驟把 AI 管起來

yarn

OK，所以到底什麼是「資料合約」？

你把它想像成一份跟資料來源簽的「君子協定」。這份協定用幾行字說清楚：你是誰？你從哪來？你多久更新一次？你的內容格式是什麼？ 透過這份合約，我們就能把 AI 的知識範圍，從一個混亂的垃圾場，限縮到幾個可信賴、可追蹤的來源。

整個過程可以拆成三個階段，或是說三個「閘門」。

合約 (Contracts): 先定義好，哪些資料來源是「可信的」。指定它的主人是誰、多久更新、schema 長怎樣。
檢索 (Retrieval): AI 在找答案時，必須遵守合約。例如，只找打了「v2.0」標籤的文件，或過去 30 天內更新過的資料。
答案 (Answer): AI 給出的每個答案，都必須附上「證據」，像是文件 ID 或段落編號，證明它不是自己亂編的。

這個想法其實跟一些國際標準不謀而合。像美國國家標準暨技術研究院（NIST）就一直在提倡，不要指望 AI 自己變乖，你得把具體的控制項綁在 AI 系統的每個環節上。而台灣的數位發展部（MODA）發布的「生成式 AI 參考指引」也強調了資料品質和风险管理的重要性。雖然 NIST 的方法更偏向技術層面的強制控制，而 MODA 的指引比較是原則性的建議，但你看，核心精神是一樣的：管好輸入，才能期待輸出。

步驟一：評估現況 (大概 5 分鐘)

先不用動任何程式碼。打開你家那個 RAG 應用，然後誠實回答下面幾個問題。我自己是覺得，光是回答這些問題，你大概就知道問題出在哪了。

真相在哪？ 你的 AI 到底被允許讀取哪些資料夾或資料庫？有明確的清單嗎？
誰該負責？ 每個資料來源，有指定「負責人」嗎？有規定它應該多久更新一次嗎？（例如：每天早上六點前）
版本分得清嗎？ 你有辦法明確告诉 AI「去讀 v1.9 版的政策」，而不是「v2.0 版」嗎？
證據拿得出來嗎？ 每個答案，都有附上一個可以點回去、真實有效的連結或資料列 ID 嗎？
它會說「我不知道」嗎？ 當 AI 找不到高可信度的答案時，它是會承認「我不知道」，還是硬掰一個給你？

上面任何一題的答案是「No」或「不確定」，恭喜你，那就是你該動手的地方。

步驟二：動手修復 (大概 15 分鐘)

這一步是核心。我們要把剛剛的「君子協定」寫下來，然後調整系統讓它生效。

1. 建立你的第一份「資料合約」（差不多 10 行字）

不用想得太複雜。就針對一個你最重要的資料來源（例如：產品價格目錄），建立一個文字檔或放在你的 Confluence/Notion 裡，內容大概長這樣：

# 資料合約範例
 Name & Owner: "產品價格目錄 v2.0 - 負責人: Maya"
 Scope: "僅包含零售 SKU，不含批發價。"
 Schema (簡化): "sku_id, price_usd, effective_date, region"
 Freshness SLA: "每日 06:00 CT 前更新；若過期则阻擋存取。"
 Provenance: "來自 ERP 系統的 X 表格；變動日誌保留 90 天。"
 Quality checks: "sku_id 不得重複；price_usd > 0。"
 Access: "僅允許 Retail_RAG 服務帳號唯讀存取。"
 Retention: "保留 12 個月；到期封存至冷儲存。"
 Versioning: "使用語意版本號 vMAJOR.MINOR。"
 Deprecation: "v1.x 版本已於 2025-09-01 凍結。"

你看，很簡單吧？但這幾行字威力強大。它等於是為你的資料來源建立了一張「身分證」。

2. 收緊「檢索」的繩子 (大概 5 分鐘)

有了合約，接下来就要讓 RAG 系統學會「認證」。

依約過濾： 只索引那些有「合約認證=True」標籤的資料路徑。沒有合約的，一律不准碰。
釘選版本： 在檢索時，明確要求版本。例如，在搜尋 query 裡加上 version:v2.* 之類的過濾條件。
時間限制： 優先選取在合約規定的「保鮮期」內編輯过的文件。
減少雜訊： 適度降低檢索回來的文檔數量（也就是 `top-k` 參數）。文件少，但精準，比大海撈針好。

3. 強制答案附上「證據」 (大概 5 分鐘)

最後一步，不准 AI 空口說白話。

要求模型輸出的時候，必須是結構化的格式，例如 `citations: [doc_id_123, row_id_456]`。
在系統中間加一道檢查。如果 AI 給出的答案裡，有任何一個 citation 連結是壞的，就直接攔截整個答案，不送出去。這叫 "fail-closed"，超級重要。
如果經過層層過濾，真的找不到可信的證據，AI 的標準答案必須是「對不起，關於這個問題，我目前沒有足夠的資訊可以回答。」

最近有些研究，像《Nature》期刊上的文章也證實了，RAG 的品質關鍵不只在於模型大小，更在於「精選的來源」和「可測量的檢索」。這跟我們的思路完全一致。

步驟三：鎖定成果，變成自動化流程 (大概 10 分鐘)

做一次不難，難的是維持。所以最後要把這套方法變成團隊的 SOP。

建立範本： 在你的程式碼倉庫裡建一個 /contracts/ 資料夾，放一個 YAML 範本。以後要加新的資料來源，就從複製範本開始。
CI/CD 檢查： 在每次有人想修改檢索邏輯時，自動跑一個小的評估測試。如果「有根據答案比例 (Grounded-Answer Rate)」下降了，就直接阻擋合併 (block merge)。
預設拒絕： 把「沒有合約，就沒有索引，就沒有答案」設為系統的預設規則。
定期檢查： 每週自動發通知，提醒那些資料來源沒有遵守「更新 SLA」的負責人。

常見錯誤與修正

我知道，在推動這個的時候，你可能會聽到一些反對的聲音，或是自己也有些迷思。這裡列出幾個最常見的坑。

「供應商說他們的新模型已經修好幻覺了。」 呃，聽聽就好。就算是 OpenAI 自己對 GPT-5 的說明（如果有的話）也會很保守。模型的進步是真的，但把它們當成不會犯錯的神，那你就输了。把它當成一個「很有用的助理」，而不是「真理的化身」。
「文件越多，AI 就越懂、越接近真相。」 完全錯誤。再說一次，未經整理的資料是噪音，不是知識。先策展，再檢索。Curate first, then retrieve.
「AI 都有給引用，看起來很棒啊。」 你真的點進去看了嗎？那些連結是連到正確的版本嗎？還是根本是 404？沒經過驗證的引用，跟賭博沒兩樣。