多來源合成的資訊來源與不確定性

多來源合成的 information provenance 與 uncertainty 是 Claude Certified Architect — Foundations（CCA-F）考試的收尾任務說明，涵蓋任務 5.6：「在多來源合成中保存 information provenance 並處理 uncertainty。」Domain 5（情境管理與可靠性）佔考試總分的 15%，而任務 5.6 錨定了這個領域在架構層面最具挑戰性的模式——一套多 agent 研究系統，必須追蹤哪個來源產生了哪個 claim、辨識來源互相矛盾的情況，並將 uncertainty 呈現出來，而非掩蓋它。社群的通過報告顯示，information provenance 是 Domain 5 難度最高的任務說明之一，關鍵原因在於：Claude 不會自動追蹤來源或標記 uncertainty，所有你希望出現在最終輸出中的 provenance 保證，都必須透過提示詞、schema 和 orchestration 邏輯從頭設計進去。

這份學習筆記逐一走過 CCA-F 考生在系統層面需要架構的每個大綱要點：provenance 問題本身、結構化的 claim-source 對應、讓引用可追溯的識別欄位、多來源衝突解決、輸出 schema 中的 uncertainty 表示方式、model confidence 與 source reliability 的區別、hedged language 模式、來源品質加權、cross-source triangulation、provenance audit trail，以及由 uncertainty 驅動的升級機制。Information provenance 與 uncertainty 在 multi-agent-research-system 情境和 structured-data-extraction 情境中出現最密集；兩個情境的實作範例貫穿全文，作為模式的錨點。最後以五個考試陷阱和七題 FAQ 收尾。

Provenance 問題 — 失去對哪個來源產生哪個 Claim 的追蹤

Information provenance 是合成輸出的一種屬性：最終答案中的每個 claim 都能溯源至產生它的特定來源文件、chunk 和檢索步驟。Provenance 問題是天真的多來源合成管線預設的失敗模式：Claude 讀完五份文件後寫出一段自信的段落，你卻無法用機械方式判斷哪個句子來自哪份 PDF。沒有 information provenance，你就無法稽核幻覺、無法遵守來源層級的存取控制、無法在受監管的領域正確引用，也無法在發生下游爭議時不重跑整個合成流程就修正問題。

為什麼天真的合成會丟失 Provenance

典型的天真模式長這樣：從向量索引中取回五段文字、將它們拼在提示詞的「Sources:」標題下、請 Claude「摘要相關資訊」。Claude 會產出一份乾淨的摘要——但那份摘要是混合體。歸屬在 Claude 開始寫新段落的那一刻就消失了。這是 information provenance 失敗的預設樣貌，而所有提到「研究系統」、「合成」或「多來源」的 CCA-F 情境，都在測試你是否知道如何在架構上繞過這個問題。

將 Provenance 視為第一優先的設計目標

Information provenance 不是事後才加上去的功能，它是一個會重塑管線每個階段的約束條件：檢索時為每個 chunk 儲存來源 ID、提示詞要求 Claude 產出 claim 而非散文、輸出 schema 對每個 claim 強制要求 citation 欄位、下游驗證拒絕任何 claim 缺少來源 ID 的輸出。CCA-F 題目獎勵那些把 information provenance 視為管線層級屬性、而非事後標注的考生。

結構化的 Claim-Source 對應 — 為每個擷取出的 Claim 附加來源引用

Information provenance 的機械核心是結構化的 claim-source 對應：一筆將合成輸出中每個原子 claim 與支撐它的來源識別符配對的記錄。這個模式用「claim 陣列，每個 claim 帶有明確的 source 陣列」（可驗證、可機械檢查）取代了「散文加腳注」（無法驗證）的做法。

Claim 作為原子單位

Information provenance 設計將合成輸出分解為原子 claim——單一、可查核的斷言——而非段落。「Acme Corp 在 2026 年 Q2 回報了 42 億美元的營收」是一個 claim。「Acme Corp 今年表現良好，營收強勁且利潤率持續改善」是一個段落，裡面藏著三個 claim。Claim 是可以強制執行 information provenance 的單位；段落不是。

輸出 Schema 強制執行 Information Provenance

Information provenance 透過傳入 strict tool use 的輸出 schema 來強制執行。典型的 schema 長這樣：

{
  "claims": [
    {
      "claim_id": "c-001",
      "text": "Acme Corp 在 2026 年 Q2 回報了 42 億美元的營收。",
      "sources": [
        {"source_id": "doc-acme-10Q-2026Q2", "chunk_index": 14}
      ],
      "uncertainty": "low"
    }
  ]
}

在工具定義上設定 strict: true，Claude API 就會拒絕回傳任何 claim 上缺少 sources 陣列的輸出。Information provenance 的保證是機械性的，不是禮貌性的。

為什麼結構化對應勝過內嵌引用

散文中的內嵌引用（「Acme 回報了 42 億美元 [1]」）看起來合理，但很脆弱：Claude 可能忘記加標記、重複標記，或標錯編號。JSON schema 中的結構化 claim-source 對應是可機械驗證的——驗證器可以程式化地斷言每個 claim 至少有一個來源、每個來源 ID 都存在於檢索日誌中、沒有幻覺 ID 混入其中。這個嚴格程度的 information provenance，才是研究等級管線與玩具 demo 的分水嶺。

來源識別欄位 — URL、文件 ID、Chunk Index、檢索時間戳記

光是「Acme 10-Q」這樣的來源 ID 還不足以滿足 information provenance 的要求。生產等級的來源參照需要包含足夠的欄位，以便唯一定位支撐該 claim 的精確文字段落，並證明證據在合成當下確實存在。

最小可行的來源參照

就 CCA-F 而言，每個 information provenance 來源參照的最少必填欄位為：

• URL 或文件 URI — 來源的標準定位符。
• 文件 ID — 穩定的內部識別符（雜湊值、UUID 或外部主鍵）。
• Chunk index 或頁碼 — 子文件段落識別符。
• 檢索時間戳記 — 從來源拉取內容的時刻。
• 來源類型 — 列舉類型（web、internal-wiki、CRM、knowledge-base、uploaded-pdf 等）。

每個欄位的重要性

URL 讓人工稽核員可以解析來源。文件 ID 讓你可以去重並與檢索日誌進行 join。Chunk index 將證據縮小至特定段落。檢索時間戳記可以證明合成當下來源中確實存在該證據——當來源會變動（wiki、網頁、票務系統）時，這一點至關重要，因為日後的讀者需要知道當時引用的是哪個版本。沒有檢索時間戳記的 information provenance 較弱，因為來源可能在合成與稽核之間悄悄改變。

在多 Agent 研究系統中的來源參照

在 multi-agent-research-system 的 CCA-F 情境中，多個 subagent 可能獨立檢索到重疊的內容。Information provenance schema 必須攜帶足夠的識別符，以便偵測兩個 subagent 是否引用了同一個 chunk（用於 cross-source triangulation），以及它們是否引用了來自同一文件但不同 chunk 的內容。Chunk index 是使這種區分成為可能的欄位。

多來源衝突解決 — 當來源對同一事實有不同說法

多來源合成經常拉入互相矛盾的來源。最舊的 CRM 備註說客戶用的是 Basic 方案；帳務 API 說是 Pro；上週的客服案例逐字稿說「我剛升級了」。Information provenance 讓你看見衝突；衝突解決政策決定合成輸出要說什麼。

四種衝突解決政策

1. 最新優先 — 依 retrieved_at 或來源發布日期打破平手。適用於可變的事實（方案等級、地址、狀態）。
2. 權威來源優先 — 依來源類型打破平手（帳務 API > CRM 備註 > 自由文字逐字稿）。適用於其中一個來源是系統記錄（system of record）的情況。
3. 同時呈現 — 呈現兩個值及其來源。適用於事實確實無法解決、需要由下游人工仲裁的情況。
4. 升級 — 拒絕合成；將衝突交還給人工審查員。適用於高風險事實（法律、醫療、財務）。

在提示詞中明文指定政策

衝突解決政策必須在系統提示詞中明確指定。「若帳務 API 與 CRM 備註不一致，信任帳務 API，並將 CRM 的值記錄在 claim 的 conflicting_sources 欄位中。」缺少這個指令，Claude 會靜默地選擇一個看起來合理的值——藉由隱藏衝突來破壞 information provenance。

conflicting_sources 欄位

成熟的 information provenance schema 在每個 claim 上增加 conflicting_sources 陣列，使已解決的衝突仍然在輸出中可見。解決後採用的值存放在 sources，落敗的值存放在 conflicting_sources。下游稽核員可以檢視 conflicting_sources 清單，以驗證政策是否被正確套用。

Uncertainty 表示方式 — 在結構化輸出中使用明確的 Uncertainty 旗標

Information provenance 告訴你一個 claim 從哪裡來；uncertainty 表示方式告訴你對它的信任程度。CCA-F 等級的合成管線會在輸出的每個 claim 上附加明確的 uncertainty 旗標，而不是把 uncertainty 埋在「可能」或「據報」這類散文措辭裡。

Uncertainty 作為列舉欄位

最乾淨的表示方式是在每個 claim 上設置列舉型的 uncertainty 欄位，其值集合小而定義明確：

• high — 來源涵蓋率低、來源互相衝突，或 claim 需要從多個 chunk 推論得出。
• medium — 單一權威來源；無佐證。
• low — 多個互相佐證的權威來源；無衝突。
• unverified — 沒有來源提供直接證據；claim 是 Claude 的推論或外推。

為什麼列舉優於自由格式

列舉型的 uncertainty 欄位在機械上是可篩選的——「只顯示 high 和 unverified 的 claim」是一個下游查詢——而自由格式的 uncertainty 字串則不行。CCA-F 情境持續獎勵結構化列舉而非散文標注，因為結構才能支撐驗證、路由和自動升級。

Claude Confidence 不等於 Source Reliability

一個微妙但考試關鍵的區別：Claude 對它從來源中擷取到正確值的內部 confidence，不等於來源本身的 reliability。一個 claim 可以從一個本身不可靠的來源中以高 confidence 擷取出來。Information provenance schema 必須將這兩個維度分開，通常透過第二個列舉欄位，例如 source_quality: authoritative | reputable | user-generated | unverified。

Confidence vs Uncertainty — 區分 Model Confidence 與 Source Reliability

Confidence 與 uncertainty 的區別值得單獨一個 H2，因為它是 Domain 5 社群通過報告中最常答錯的概念。把這兩者視為同義詞的 CCA-F 考生，至少會在一道計分題上失分。

Model Confidence

Model confidence 是 Claude 對擷取品質的內部訊號：「我有 95% 的把握，這份 10-Q 中的營收數字是 42 億美元。」這是關於合成步驟本身的陳述。Model confidence 對 10-Q 是否正確毫無說明；它只告訴你 Claude 是否正確地讀懂了 10-Q。

Source Reliability

Source reliability 是來源的屬性，而非模型的屬性：「這份 10-Q 是一份由上市公司在 SEC 監管下撰寫的受規管財務申報文件。」受規管申報文件的 source reliability 高；精心維護的 wiki 中等；未經驗證的使用者生成內容低。相同的擷取任務可以在 source reliability 低的來源上達到高 model confidence（Claude 清楚地讀懂了那則 Reddit 留言；但那則留言本身可能是錯的）。

Output Uncertainty 是兩者的交集

最終輸出中的 uncertainty 是你回報給下游消費者的值。它是 model confidence 與 source reliability 的交集，再由 cross-source corroboration 進一步調整。只有在三個條件同時滿足時，一個 claim 才能達到 low uncertainty：高 model confidence、authoritative 來源，以及至少一個佐證來源。

這個區別中的考試陷阱

典型的干擾說法是：「Claude 的 log probability 很高，所以合成的 claim 是可靠的。」錯。高 log probability 表示 Claude 對擷取有信心，而非對來源有信心。另一個干擾說法：「來源是 SEC，所以無論 Claude 如何摘要都是可靠的。」也錯——source reliability 是必要條件，但不充分。正確答案必須同時處理兩個維度。

Hedged Language 模式 — 生成文字中 Uncertainty 的語言標記

即使你的輸出 schema 強制要求結構化的 uncertainty 欄位，每個 claim 的 text 欄位仍然是自然語言，而 Claude 在那段散文中選用的語氣修飾是有意義的。設計良好的提示詞會指示 Claude 使 hedged language 與結構化的 uncertainty 值保持一致。

標準的語氣修飾標記

• "according to [source]"（根據〔來源〕） — 中立歸屬，無語氣修飾。
• "reportedly" / "reported to"（據報道） — 中度語氣修飾；暗示 claim 存在於某個來源但尚未獨立驗證。
• "may" / "might" / "could"（可能） — 高度語氣修飾；暗示存在實質 uncertainty 或推論。
• "appears to" / "is likely"（似乎是） — 高度語氣修飾；Claude 正在進行推論。
• "inferred from"（從……推論） — 明確標記外推；應始終搭配 unverified 或 high uncertainty。

使散文語氣修飾與結構化 Uncertainty 一致

常見的失敗模式是散文中大量語氣修飾，但結構化的 uncertainty 欄位卻寫著 low，或反過來。這種不一致讓讀散文的下游人工和讀結構的自動化系統都感到困惑。系統提示詞應明確要求對齊：「在 text 欄位中使用與 uncertainty 等級相符的 hedged language；low 的 claim 使用直接陳述，medium 以上必須使用明確的語氣修飾標記。」

客戶服務情境中的語氣修飾

在客戶服務合成情境中，「客戶的方案是 Pro」（無語氣修飾，low uncertainty）和「根據最新票單，客戶的方案似乎是 Pro」（有語氣修飾，medium uncertainty）有非常大的差異。這個差異決定了 agent 是否能自主執行帳務操作，或必須升級給人工處理。Information provenance 使這個區分在機械上可見。

Source Quality 加權 — 將權威來源視為較高 Confidence

並非所有來源都值得同等權重。生產等級的 information provenance 管線在決定每個 claim 的最終 uncertainty 之前，會依照預設的權威層級對來源進行加權。

分層的來源層級體系

典型的企業多 agent 研究系統層級：

1. Tier 1 — 系統記錄（Systems of record）（帳務 API、HRIS、版本控制的 repository）。對其管轄的事實具有最高權威性。
2. Tier 2 — 精心整理的內部知識（工程 wiki、已核准的 runbook）。可靠但偶爾過時。
3. Tier 3 — 交易日誌（客服票單歷史、聊天記錄）。對已發生的事情準確，但不一定反映當前狀態。
4. Tier 4 — 外部公開來源（供應商文件、新聞、網路搜尋結果）。作為背景資訊使用；盡可能與較高 tier 的來源交叉驗證。
5. Tier 5 — 使用者生成（論壇貼文、社群解答）。最低權重；在斷言前需要佐證。

加權的實際做法

加權在系統提示詞中指定，並由輸出 schema 強制執行。「當 Tier 1 來源與 Tier 3 來源不一致時，信任 Tier 1，並將 Tier 3 的值記錄在 conflicting_sources 中。只有 Tier 4 或 Tier 5 來源支撐的 claim，除非至少有一個 Tier 1-3 的來源佐證，否則 uncertainty 必須為 medium 或更高。」

加權對 Information Provenance 的重要性

沒有明確加權，Claude 會套用一種管線擁有者無法稽核的隱性、不穩定排序。有了明確加權，information provenance 就是確定性的——相同的輸入永遠產出相同的信任決策，人工稽核員可以驗證政策是否被套用。

Cross-Source Triangulation — 在斷言高 Confidence 之前要求佐證

Triangulation 是 information provenance 的技術，要求多個獨立來源同意，才能將一個 claim 提升至 low uncertainty。它是對抗幻覺和「引用一則 Reddit 留言當成事實」這類失敗模式最有力的防禦。

Triangulation 規則

典型的 triangulation 政策是：「只有當至少兩個來自不同文件（且理想上來自不同來源 tier）的來源佐證該 claim 時，才能以 uncertainty: low 發出這個 claim。只有單一來源支撐的 claim，無論該來源權威性多高，一律預設為 uncertainty: medium。」

為什麼必須是不同文件，而非不同 Chunk

Triangulation 要求不同文件（理想上是不同來源類型），而非同一文件的不同 chunk。同一份 10-Q 的兩個 chunk 並非獨立證據——它們共享同一位作者和同一個編輯流程。把文件內部的 chunk 計為 triangulation 是常見的天真錯誤；CCA-F 情境題測試你是否能區分文件內部同意（非 triangulation）和跨文件同意（triangulation）。

多 Agent 研究系統中的 Triangulation

在 multi-agent-research-system 情境中，coordinator 可以刻意將多個 subagent 分派至獨立的來源池，以便實現 triangulation。Subagent A 搜尋公司 wiki，subagent B 搜尋票務系統，subagent C 搜尋外部網路結果。當三者都回傳相同的事實時，coordinator 就將該事實提升至 low uncertainty。這是 information provenance 架構的直接應用，在 CCA-F 練習題中頻繁出現。

Provenance Audit Trail — 記錄檢索與合成步驟以確保可追溯性

輸出中的 information provenance 是有價值的；管線日誌中的 information provenance 才是讓輸出在數週或數月後仍可稽核的關鍵。Audit trail 捕捉完整的檢索與合成歷史，使任何最終 claim 都能被重現或反駁。

Provenance Audit Trail 記錄的內容

最小規模的 information provenance audit trail 為每次合成運行記錄以下內容：

• Run ID — 合成調用的唯一識別符。
• 檢索事件 — 查詢文字、向量索引版本、回傳的 chunk 及其 ID 與檢索時間戳記。
• 工具呼叫 — Claude 發出的每個 tool_use 區塊、回傳的每個 tool_result。
• Subagent 分派 — 哪個 subagent 處理哪個子任務，以及其自己的 run 子 ID。
• 衝突解決 — 每個偵測到的多來源衝突及其解決政策。
• 最終合成輸出 — 完整的結構化 claim 陣列，包含 uncertainty 旗標和 conflicting_sources。
• Session ID — 將合成綁定到對話的 Agent SDK session 識別符。

為什麼 Audit Trail 超出 Context Window 的範疇

Audit trail 必須存放在 Claude context window 之外——通常是外部日誌存儲（物件儲存、耐久訊息佇列或 SIEM）。Context window 只能容納長時間運行的合成所累積的一小部分內容，而被修剪的 context 是無法恢復的。Information provenance 要求檢索和合成事件必須是耐久的，而非暫時的。

Session ID 與 Audit Trail 之間的連結

Agent SDK session ID 是合成運行與 audit trail 之間的連結原語。Fork 一個 session，audit trail 就必須記錄 fork 點；恢復一個 session，audit trail 就必須將恢復後的日誌連結到父記錄。這個連結使 information provenance 能夠跨越 session 邊界存活——在長時間運行的研究工作流程中，這是常見的模式。

Uncertainty 升級 — 將低 Provenance 的斷言路由至人工驗證

Information provenance 在升級時發揮最大價值。一個為每個 claim 標記明確 uncertainty 的合成管線，可以自動將高 uncertainty 的 claim 路由至人工驗證，而無需強迫人工閱讀整個輸出。

升級路由規則

典型的 information provenance 升級政策是：「任何 uncertainty: high 或 unverified 的 claim，或任何在未解決政策下 conflicting_sources 非空的 claim，或任何來源全部屬於 Tier 4 / Tier 5 的 claim，在最終輸出釋出給下游消費者之前，都要路由給人工審查員。」

客戶服務情境中的升級

在 customer-support-resolution-agent 情境中，information provenance 管線接收客戶票單，從 CRM、帳務系統和知識庫進行檢索，並合成一份帶有每個 claim 來源的提議解決方案。關於客戶方案等級的 claim（Tier 1，帳務 API）是 low uncertainty，agent 可以自主行動。從先前票單推論出的客戶情緒 claim（Tier 3，交易日誌）是 medium 或 high uncertainty，必須在發送語氣敏感的回覆之前交給人工確認。Information provenance 使這個路由在機械上成為可能。

升級 vs 拒絕

升級不等於拒絕合成。架構良好的管線會產出帶有每個 claim uncertainty 的完整合成結果，然後只將高 uncertainty 的子集升級。因為某個 claim 不確定就拒絕整個合成，會浪費已對可靠 claim 完成的工作。

白話說明

抽象的 information provenance 機制，一旦錨定在考生已經熟悉的具體情境上，就會變得直觀。以下三個類比涵蓋了 provenance 與 uncertainty 的完整面貌。

類比一：古籍善本室的編目員

想像故宮博物院善本室裡的一位文獻編目員。每一部古籍都有詳細的館藏登錄：收藏號、冊次、頁碼、入藏年份，甚至鈐印的印記。當研究員提問時，編目員不會說「館裡某個地方有本書提到這件事」——他會翻出館藏登錄，給出精確的索書號、冊次和頁碼。研究員可以走到書架前，取出那個版本，在引用頁讀到那段文字。這就是 information provenance。現在想像一位編目員把三部古籍的內容融合成一段話，卻拒絕說明哪個事實出自哪部書。研究員根本無從查證。這就是沒有 provenance 的多來源合成。CCA-F 等級的管線讓 Claude 具備編目員的登錄紀律：合成輸出中的每個 claim，都帶著來源文件、chunk index 和檢索時間戳記——相當於索書號、頁碼和版本年份。當兩部古籍記載不同，編目員不會悄悄選一個；他在登錄卡上注明歧異，讓研究員自行判斷。這就是帶有 conflicting_sources 的多來源衝突解決。一個心智模型：information provenance 就是把善本室的編目登錄套用在 Claude 身上。

類比二：保險公司的理賠查勘員

保險公司的查勘員在調查損失時，不會照單全收任何說法。他蒐集證據——警察報告、目擊者陳述、現場照片、維修估價——並在每一件文件上加蓋日期、來源和 provenance 備註。當查勘員撰寫最終裁定時，每個事實斷言都指向檔案中的某件證據。若兩個目擊者說法不同，查勘員同時記錄兩份陳述，並說明哪份的權重較高、原因為何。不確定的項目——「申請人聲稱但無佐證」——明確標記，而不是融合進散文裡。理賠檔案是 audit trail；最終裁定書是合成輸出；文件上的戳印是來源參照欄位。一位沒有佐證就寫出流暢摘要的查勘員，是不稱職的。Claude 多來源管線中的 information provenance，要求同樣的紀律：每個 claim 指向證據、每個分歧都有記錄、每個不確定項目都有標記。列舉型的 uncertainty 欄位就是查勘員的「聲稱但未佐證」戳記。Triangulation 就是查勘員「單一目擊者不足以認定爭議事實」的規則。

類比三：電視調查報導的雙來源查核

台灣的調查報導節目依照明確的雙來源原則運作：在播出一個有爭議的事實之前，記者必須從第二個獨立來源取得佐證。單一匿名爆料不夠；單一洩漏的文件不夠。獨立性至關重要——兩位記者引用同一份新聞稿，不算兩個來源，只算一個來源讀了兩遍。若雙來源查核無法完成，記者使用語氣修飾措辭（「消息人士指出」、「據悉」、「相關人士透露」），反映資訊的結構化 uncertainty。來源意見相左時，新聞報導呈現雙方立場並分別歸屬。播出前，事實查核組會審閱查核筆記——這等同於將高 uncertainty 的 claim 升級給人工審查。CCA-F 的 information provenance 架構就是一個用提示詞和 schema 實作的調查報導室：triangulation 是雙來源原則，source quality 加權是新聞室的層級體系（通訊社 > 新聞稿 > 匿名線報），hedged language 是記者的散文措辭，而查核筆記就是 audit trail。

考試當天選用哪個類比

• 關於來源識別欄位與 audit trail 的題目 → 善本室編目員類比。
• 關於 uncertainty 旗標與衝突解決的題目 → 理賠查勘員類比。
• 關於 triangulation 與 source quality 加權的題目 → 調查報導雙來源類比。

常見考試陷阱

CCA-F 任務 5.6 持續利用五種反覆出現的 information provenance 陷阱模式。全部五種都有社群通過報告記錄在案，並以合理的干擾選項形式出現。

陷阱一：假設 Claude 會自然地引用來源

任務 5.6 最常被引用的錯誤，是假設只要在提示詞中包含來源文件，Claude 就會自動在輸出中引用它們。它不會。多來源 Claude 管線中的 information provenance，需要一個帶有必填 sources 陣列的明確輸出 schema，並透過 strict tool use 強制執行。提出「請 Claude 在散文中引用來源」而無結構性強制機制的答案，是錯的。

陷阱二：混淆 Model Confidence 與 Source Reliability

一個 claim 可以從 source reliability 低的來源中以高 model confidence 擷取出來。干擾答案把「Claude 有信心」框架成等同於「claim 是可靠的」。正確的心智模型將 model confidence（擷取品質）與 source reliability（來源權威性）分開，並且只有在兩個維度都滿足、且有 cross-source corroboration 時，才認為 claim 是 low uncertainty。

陷阱三：將 Audit Trail 存放在 Context Window 中

一個天真的做法是在對話歷史中累積檢索和合成日誌，讓「Claude 日後可以參考」。Context window 在 audit trail 派上用場之前很久就會被修剪、壓縮或達到上限。Information provenance audit trail 必須存放在以 session ID 為鍵的耐久外部儲存中；提出在 context 中儲存 audit trail 的答案，在架構上是不健全的。

陷阱四：將文件內部的 Chunk 計為 Triangulation

同一文件的兩個 chunk 並非獨立證據。干擾選項提出「10-Q 的多個 chunk 都同意，所以 claim 已經 triangulated」。錯。Triangulation 要求不同文件（且理想上是不同來源 tier），因為編輯流程的獨立性才是讓佐證有意義的關鍵。CCA-F 情境題特別以「來自同一來源的多個 chunk」作為干擾，期待考生拒絕它作為 low uncertainty 斷言的充分條件。

陷阱五：升級整個合成而非只升級標記的子集

當某些 claim 被偵測到有 uncertainty 時，正確的回應是部分釋出：發出完整的結構化輸出、標記不確定的子集，並只將標記的子集路由給人工審查。干擾選項提出「若有任何 claim 不確定，就什麼都不回傳」或「重新從頭合成直到所有 claim 都有信心為止」。兩者都浪費了已對可靠 claim 完成的工作，也違背了結構化 uncertainty 表示方式的初衷。

練習錨點

Information provenance 與 uncertainty 在六個 CCA-F 情境中的兩個出現最密集。將以下內容視為任務 5.6 情境叢集題的架構骨幹。

Multi-Agent-Research-System 情境

在這個情境中，coordinator agent 將多個 subagent 分派至獨立的來源池——公司 wiki、票務系統、外部網路、內部 CRM——每個 subagent 從自己的證據庫回答相同的研究問題。Subagent 回傳結構化的 claim 陣列，coordinator 合成一份帶有完整 information provenance 的最終答案：每個輸出 claim 引用產生它的 subagent、來源文件與 chunk，以及指定的 uncertainty 等級。預期會有題目測試 cross-source triangulation（coordinator 何時可以將 claim 提升至 low uncertainty？）、衝突解決政策（subagent 意見相左時誰說了算？）、audit trail 外部化（檢索日誌存放在哪裡？），以及 uncertainty 升級（哪些 claim 路由給人工？）。

Structured-Data-Extraction 情境

在這個情境中，Claude 被要求從一份或多份來源文件中擷取結構化記錄（合約條款、發票欄位、合規屬性）。此處的 information provenance 較少涉及多 agent orchestration，更多是關於每個欄位的來源歸屬：每個擷取的欄位都帶著文件 URI、頁碼或 chunk，以及 uncertainty 旗標。預期會有題目測試 strict tool use 對每個欄位來源 schema 的強制執行、缺少證據的處理方式（來源不包含請求欄位時要發出什麼 uncertainty 值？）、結構化欄位與散文摘要之間的 hedged language 對齊，以及驗證輸出中的來源 ID 確實存在於檢索日誌中。

FAQ — Information Provenance 與 Uncertainty 前七大問題

在 Claude 多來源管線中，information provenance 究竟是什麼？

Information provenance 是 Claude 合成輸出中的每個原子 claim，都能溯源至特定來源文件、chunk、檢索時間戳記，以及（在多 agent 系統中）產生它的 subagent 的屬性。Claude 不會自動產生 information provenance——它必須透過帶有每個 claim 必填來源欄位的結構化輸出 schema、拒絕 schema 違規的 strict tool use，以及後合成驗證（確認引用的來源 ID 確實存在於檢索日誌中）來設計。Information provenance 是 CCA-F 任務 5.6 所考核的核心能力，社群通過報告將「假設 Claude 自然會引用來源」列為 Domain 5 最高頻的錯誤之一。

如何強制要求每個 claim 至少有一個來源？

透過 tool use 定義結構化輸出 schema，其中每個 claim 物件都有必填且非空的 sources 陣列；在工具定義上設定 strict: true；並加入後合成驗證，拒絕任何 claim 的 sources 陣列為空或包含不存在於檢索日誌中的 ID 的輸出。Strict tool use 提供 schema 層級的強制執行；後驗證提供語義層級的強制執行（防止格式正確但捏造的來源 ID）。兩者都是生產等級 information provenance 的必要條件——schema 強制執行無法單獨防止一個格式正確但捏造的來源 ID 混入。

Model confidence 與 source reliability 有什麼差異？

Model confidence 是 Claude 對擷取品質的內部訊號——Claude 對它正確讀懂來源的把握程度。Source reliability 是來源本身的屬性——撰寫方和編輯流程的可信程度。兩者是正交的：Claude 可以從 reliability 低的來源中以高 confidence 擷取（正確讀懂一則不可靠的 Reddit 留言），也可以從 reliability 高的來源中以低 confidence 擷取（對 SEC 申報文件只有部分工具存取權限）。最終輸出的 uncertainty 應該是兩個維度加上 cross-source corroboration 的交集，而不是僅憑 Claude 的 confidence。混淆兩者是 CCA-F Domain 5 前五大陷阱之一。

如何處理來源衝突？

在系統提示詞中指定衝突解決政策——最新優先、權威來源優先、同時呈現，或升級——並在輸出 schema 的每個 claim 上增加 conflicting_sources 陣列，使落敗的值仍可稽核。解決後採用的值存放在 sources；落敗的值（連同各自的 ID 和檢索時間戳記）存放在 conflicting_sources。絕不讓 Claude 在沒有記錄政策的情況下靜默地選一個值。CCA-F 題目持續對「讓 Claude 自行決定」而無明確衝突解決規則的答案扣分。

為什麼文件內部的佐證不算 Triangulation？

Triangulation 是關於編輯流程的獨立性，而非文字的重複。同一份 10-Q 申報文件的兩個 chunk 共享同一位作者、同一個法律審查周期和同一個發布事件。若申報文件對某個事實有誤，每個 chunk 都對那個事實有誤。Cross-source triangulation 要求跨不同文件（且理想上是不同來源 tier）的同意，因為這種同意能在單一編輯失誤面前倖存。CCA-F 情境題特別提供「來自同一來源的多個 chunk 同意」作為干擾，並期待考生拒絕它作為 low uncertainty 斷言的充分條件。

Provenance Audit Trail 應存放在哪裡？

存放在耐久的外部儲存中——物件儲存（S3 / R2）、專用的稽核資料庫或 SIEM——以 Agent SDK session ID（以及每次合成調用的 run ID）為鍵。Claude context window 不是可行的位置，因為它在 audit 真正重要之前就會被修剪、摘要或壓縮。Audit trail 必須捕捉：檢索事件（查詢、索引版本、回傳的 chunk）、每個 tool_use 和 tool_result、每個 subagent 分派、每個衝突解決，以及最終的結構化輸出。Information provenance 是一種耐久性屬性，而耐久性意味著以 session 識別符連結的帶外儲存。

Uncertainty 何時應觸發人工升級，何時只需語氣修飾？

當 claim 超過可設定的 uncertainty 閾值（通常是 high 或 unverified）、conflicting_sources 在未解決政策下非空，或支撐來源全部屬於最低 tier（使用者生成、未驗證的外部來源）時，升級處理。當 claim 由單一權威來源支撐且無矛盾證據時，使用語氣修飾（散文標記如「據悉」或「似乎是」，與 medium 結構化 uncertainty 對齊）。決策規則是：當下游自主行動在該 uncertainty 下不安全時，升級；當人工讀者應該被提醒但系統仍可繼續運作時，使用語氣修飾。永遠只升級標記的 claim 子集，而非整個合成——部分釋出能保留已對可靠 claim 完成的工作。

延伸閱讀

• Session management — Agent SDK: https://docs.anthropic.com/en/docs/claude-code/sdk/sdk-sessions
• Long context prompting tips: https://docs.anthropic.com/en/docs/build-with-claude/prompt-engineering/long-context-tips
• Context windows — Claude API Docs: https://docs.anthropic.com/en/docs/build-with-claude/context-windows
• Increase output consistency — structured outputs: https://docs.anthropic.com/en/docs/test-and-evaluate/strengthen-guardrails/increase-consistency
• Strict tool use — schema-guaranteed output: https://docs.anthropic.com/en/docs/agents-and-tools/tool-use/strict-tool-use
• Building effective agents — escalation and human-in-the-loop: https://docs.anthropic.com/en/docs/build-with-claude/agentic-loop

Related ExamHub topics: 跨長互動的對話情境管理, 人工審查工作流程與 Confidence 校準, 多 Agent Orchestration 與 Coordinator-Subagent 模式, 升級與歧義解決.