Provenance：每筆資料的身份證

沒有 provenance 的資料，就像沒有標籤的試管。你遲早會把它拿去做錯事。

Hook

你做了一個 AI 幫你整理 bookmarks 的流程。 每天大概會發生這些事：

1. 抓 100 篇網頁原文
2. 請 AI 產生摘要
3. 把摘要存進 DB
4. 下次再從 DB 撈摘要，做更高階摘要

一開始看起來很有效率。 原文太長， 先摘要很合理。 摘要很多， 再做整理也很合理。 可是三個月後， 你開始覺得資料庫怪怪的。 你回頭抽查一筆內容。 它不是原文。 也不是人類寫的整理。 它是一段 AI 摘要， 引用另一段 AI 摘要， 再引用更早的一段 AI 摘要。 你一路往上追， 發現這條鏈根本沒回到可靠原文。 整個系統像在吃自己的尾巴。 學界把這種現象叫做 Ouroboros Effect。 它不是單次 hallucination。 它是資料層慢慢自我污染。 最麻煩的是， 這種污染剛開始看不出來。 每一段摘要單看都像人話。 但你一旦失去出處， 就失去判斷力。 你不知道這句話是：

• 原始來源真的這樣寫
• AI 從原文推導出來
• 還是 AI 從另一段 AI 內容再推一次

這時候， 你缺的不是更強的模型。 你缺的是每筆資料的身份證。 這個身份證， 就叫 provenance。

Learn

一句話定義

Provenance 可以先用最工程化的方式理解：

這筆資料從哪裡來、經過誰加工、祖先是哪些 entry、現在屬於哪個可信層級。

如果 trust boundary 是在問輸入能不能信， 那 provenance 是在回答： 你為什麼信， 你信到什麼程度， 以及你能不能一路追回去。 沒有 provenance， 所有內容最後都會長得像同一團字。 而一旦它們看起來都一樣， 系統就會開始把 AI 生成物跟第一手來源混著吃。

最小欄位：先有三個就夠用

你不需要一開始就做成學術級 lineage graph。 先有下面三個欄位， 很多事就能開始擋：

source_tier: Literal["raw_source", "llm_derived", "human_confirmed"]
upstream_ids: list[str]
provenance_hash: str

這三個欄位各自負責不同工作。

欄位	作用	沒有它會怎樣
source_tier	告訴系統這筆資料屬於哪種來源層級	AI 生成物和原文會被混成同一類
upstream_ids	保留祖先關係，能往回追	你無法知道摘要是從哪幾筆長出來的
provenance_hash	防止 tier 或 ancestry 被事後偷改	有人可以把低可信資料偽裝成高可信

先別追求完美 schema。 這三個欄位先落地， 比你今天再加十個 fancy metadata 還有用。

source_tier：先把來源層級切開

這堂課先用三層就夠：

Tier	代表意思	例子
raw_source	第一手抓到的原始來源	網頁原文、PDF 文字、API 原始回應
llm_derived	AI 推導或生成的內容	摘要、分類、score、抽取結果
human_confirmed	經過人類覆核或編修確認	人工整理結論、核對後的 note

這三層的關鍵不是語意漂亮。 而是你後面的 pipeline 可以根據 tier 直接做決策。 同一句話內容再像， 只要 tier 不同， 處理方式就不一樣。 例如：

• raw_source 可以拿來做證據回溯
• llm_derived 可以拿來當輔助訊號
• human_confirmed 才適合進長期整合層

如果你不先切 tier， 系統就只剩下 content 本身。 而 content 本身常常不足以判斷能不能回流。

raw_source 不是高級，它只是第一手

很多人第一次看到 tier， 會下意識以為： raw_source = 最好， llm_derived = 最差。 這樣理解太粗。 raw_source 的價值不一定是品質最高。 它的價值是： 它保留了第一手可追溯性。 一篇爛文章也可以是 raw_source。 它不保證真。 它只保證： 這是你真正抓到的原文， 不是後面某個模型又加工過的版本。 所以 provenance 不是 truth meter。 它是 lineage meter。

llm_derived 最危險的地方不是它會錯

LLM 產物會錯， 這大家都知道。 真正更危險的是， 它很容易看起來像原文。 一段漂亮摘要存進資料庫後， 過兩週再被別的 agent 撈出來， 常常已經沒人記得這是 AI 生成的。 於是它開始被拿去：

• 做下一輪摘要
• 當 ranking feature
• 進入長期 memory consolidation
• 當成「已知事實」再寫進報告

這時問題不是單點幻覺。 而是整條資料供應鏈開始自己繁殖自己。

Anti-Ouroboros：consolidation 不吃 llm_derived

先講這門課最重要的規則：

consolidation pipeline 只吃 human_confirmed + 高 signal raw_source，禁止直接吃 llm_derived 再餵回。

這就是 Anti-Ouroboros 的核心。 你可以把它想成兩道煞車：

1. curated re-feed
2. tier gate

第一道煞車是 curated re-feed。 意思是： 不是所有能寫進 DB 的內容， 都能回流進 consolidation。 只有經過挑選的內容可以。 第二道煞車是 tier gate。 意思是： 有些 tier 不管內容多像人話， 都不該進這條管線。 llm_derived 就是最典型的一種。 這兩道煞車缺任何一道， 你都可能慢慢養出吃自己尾巴的系統。

一個簡單但實用的 tier gate

先不要想太複雜。 很多情況下， 這種規則就已經擋掉大部分污染：

這段 code 沒有神奇演算法。 它只是在提醒你： 反污染的第一步， 常常不是更聰明的模型， 而是更笨但更硬的 gate。 你應該看到：

True
False
True

upstream_ids：祖先鏈不只是備查

很多人會把 ancestry 當成 nice-to-have metadata。 這是低估。 upstream_ids 最少有三個實際用途：

1. 你可以追查一筆內容到底引用了哪些祖先
2. 你可以做 explainability，知道這段結論從哪裡長出來
3. 你可以防循環引用

第三點尤其重要。 因為一旦 A 依賴 B， B 依賴 C， C 又回頭依賴 A， 你就不是「資料關聯」而已。 你是在寫一個自我吞食器。

防循環不是只檢查自己 id

很多人第一次做 cycle check， 只會檢查： entry.id not in upstream_ids 這不夠。 因為真正危險的是祖先環。 像這種：

• a 引用 b
• b 引用 c
• c 引用 a

當前 entry 的 id 也許沒直接出現在第一層 upstream。 但它已經藏在更上游。 所以你真正要檢查的是：

新寫入的 entry，其 upstream_ids 往回追時，不能遇到自己的任何祖先鏈回撞。

後面的 lab 會把這件事寫成一個真的函式。

provenance_hash：防止有人偷偷改 tier

再來是最容易被省略， 但其實很關鍵的一欄： provenance_hash 它的工作不是加密內容。 它的工作是防篡改。 最常見的攻擊方式不是改內文。 而是改 metadata。 例如有人把一筆 llm_derived 內容， 偷偷改寫成 human_confirmed。 如果系統只看 tier 字串， 它就會被放進較高信任的 pipeline。 所以你需要一個能綁住內容、 tier、 祖先列表的簽章。 例如：

HMAC(content + tier + upstream_ids)

只要其中任何一項被改， hash 就對不起來。 這樣你就能在 ingest 或 verify 階段直接擋掉。

一個最小 validate() 心智模型

很多人聽到 provenance， 就以為要先做很大的 graph 系統。 不必。 先讓每筆 entry 都能自己回答：

• 我的 tier 合法嗎？
• 我的 upstream 格式合理嗎？
• 我的 provenance_hash 在當前內容下還對嗎？

就已經很夠用了。 你甚至可以先從最小版本開始， 只驗 tier。 像這樣：

你之後會把這個 class 越補越完整。 但先讓 invalid tier 沒辦法混進系統， 就已經比完全不驗證好很多。

Provenance 不是只給資安看

別把 provenance 想成純安全控制。 它同時也在幫你做工程治理。 因為一旦每筆資料都有出處， 你比較容易回答這些問題：

• 這個摘要是誰生的？
• 這段內容是不是原文？
• 這份長期記憶有沒有人工確認？
• 這份報告為什麼會引用到錯資料？

沒有 provenance， 這些問題最後都只能靠猜。 而工程團隊最浪費時間的 debug， 通常就是在猜 lineage。

這一課你應該先記住的規則

先帶走四條：

1. 每筆 entry 至少帶 source_tier、upstream_ids、provenance_hash
2. raw_source 代表第一手，不代表一定真
3. llm_derived 不得直接回流進 consolidation
4. upstream_ids 檢查不能只看第一層，必須防祖先環

這四條做不到， 你的資料庫很容易在幾個月內從知識庫， 變成 AI 摘要的垃圾回收場。 後面兩課， 我們會把 provenance 接到 auth 和 namespace， 讓「資料是誰寫進來的」也一起被驗。

AI 協作：學了這個，跟 AI 怎麼配合？

這個技能在 AI 協作中的定位，是讓你要求 AI 幫你補 lineage 欄位與回流規則，而不是只會生成摘要內容本身。 你的人類優勢：

• 只有你能決定哪些資料在你的業務裡算 human_confirmed，哪些其實只是看起來很像人的 llm_derived。
• 只有你能判斷 consolidation 的目標是「存證據」還是「存整理後可重用知識」，因此也只有你能定義回流白名單。

可以這樣跟 AI 說：

我有一個整理知識的 pipeline。請幫我為每筆 entry 設計最小 provenance schema，至少包含 source_tier、upstream_ids、provenance_hash，並指出哪些步驟不能把 llm_derived 回流進 consolidation。請優先給我簡單可實作的規則，不要先講大型資料治理平台。

Do