抽取品質的驗證、重試與回饋迴圈

CCA-F 考試任務說明 4.4——「實作 extraction 品質的 validation、retry 與 feedback loop」——隸屬於 Domain 4（提示工程與結構化輸出，佔比 20%），是任務 4.3（透過工具使用進行結構化輸出）在操作層面的對應篇章。任務 4.3 教你如何要求一個形狀正確的 JSON 物件；任務 4.4 教你當物件仍然回傳錯誤時該怎麼辦。CCA-F 六大情境池中的「結構化資料 extraction」情境，由任務 4.4 的題目主導，因為真實的 extraction 流水線，其定義很大程度取決於 retry 行為，而不僅僅是初始提示。

這份學習筆記完整走過 CCA-F 考生必須在架構層級設計的 validation-retry 全貌：兩層 validation 模型（schema 後接語意）、將回應從「完成」升級為「需要 retry」的觸發條件、修正式 retry 提示的精確形狀、欄位級與全文件重新 extraction 的區別、信心值校準作為優先順序訊號、暫態失敗的退避策略、防止無限 validation 迴圈的硬性上限，以及將耗盡 retry 次數的文件路由給人工審查員的升級模式。最後兩個專屬章節——常見考試陷阱與練習錨點——將每個概念連回結構化資料 extraction 情境。六題 FAQ 以考生最常提出的問題為本，作為本文的收尾。

Validation 層的用途 — 在 Extraction 後捕捉 Schema 違規與語意錯誤

Validation 層是介於 Claude 的 extraction 回應與你的下游業務系統之間的程式碼。它的職責是對每個擷取出的物件做出判斷：這份輸出是否可以安全提交，還是必須送回進行 retry？沒有 validation 層，每一個格式錯誤或語意錯誤的 extraction 都會悄無聲息地流入你的資料庫、分析流水線或面向客戶的產品。

Validation 不是 Claude 的功能——它是你的應用程式的功能。Claude 可以透過 strict tool use 的設定，讓輸出始終是語法正確的 JSON，但 Claude 無法驗證擷取出的發票總額與其明細項目是否一致、日期是否落在合理範圍內，或某個法律條款編號是否真的存在於所引用的合約中。Validation 層是你的應用程式用來定義「在現實世界中何謂正確的 extraction」的地方，而不僅僅是「可解析的 extraction」。

CCA-F 考生應內化：每個 validation 層對每次 extraction 產生三種結果之一：

1. 接受（Accept） — extraction 通過所有檢查，提交至下游系統。
2. Retry — extraction 至少未通過一項檢查，但失敗是可修復的；建立修正提示並重新呼叫 Claude。
3. 升級（Escalate） — extraction 已失敗太多次，或錯誤在結構上無法修復；將文件路由給人工審查員。

為什麼 Extraction 流水線的 Validation 是必要的

Extraction 任務是靜默失敗的最糟環境。一個分類任務對某份文件分錯類，通常只是產生一個錯誤的標籤，下游審查員可以發現。但一個 extraction 任務若出錯，產生的是一個看起來正確、能通過 JSON 解析、並能乾淨進入資料庫的結構化物件——卻帶著錯誤的發票金額、移位的小數點或錯誤的稅務管轄區。靜默的結構化錯誤遠比吵鬧的文字錯誤昂貴，這正是結構化資料 extraction 情境在 validation 設計上給予不成比例重視的原因。

Schema Validation — 以程式化 JSON Schema 檢查作為第一道 Validation 關卡

第一道 validation 關卡是 schema validation：以程式化方式檢查擷取出的物件是否符合工具定義中宣告的 JSON schema。Schema validation 捕捉缺少的必填欄位、型別不符、enum 違規，以及約束違反（min/max、pattern、format）。

Strict Tool Use 減少但不能消除 Schema 失敗

當你以 strict: true 宣告一個工具時，Claude 被約束為只能產生完全符合 schema 的輸出。必填欄位永遠存在，enum 永遠持有宣告值之一，巢狀物件結構也被保留。Strict tool use 大幅減少 schema 失敗，但並不使 schema validation 變得可選：

• 非 strict 工具定義（舊版或特定模型）仍偶爾產生 schema 違規。
• Strict mode 強制結構，不強制內容——字串欄位仍可能是空字串，數字欄位仍可能在不應為零時為零，enum 值仍可能是錯誤的 enum 成員。
• 平台層級的失敗（回應在 max_tokens 截斷時截在 JSON 中間）即使在 strict mode 下也可能產生無效輸出。

Schema Validation 的檢查項目

完整的 schema validation 步驟驗證：

• 存在性 — 每個必填欄位都存在。
• 型別 — 每個欄位值與其宣告的 JSON 型別相符。
• Enum 成員資格 — 限定於集合的值確實在集合內。
• 數值邊界 — min/max 約束得到滿足。
• 字串格式 — 宣告的格式（date、email、uri、uuid）可正確解析。
• 陣列長度 — minItems/maxItems 得到滿足。
• 物件深度 — 巢狀結構與宣告形狀相符。

Schema Validation 是確定性的

Schema validation 是純確定性的——同一個物件永遠產生同一個結果。這對 CCA-F 很重要，因為考試經常對比確定性的 schema 檢查與非確定性的語意檢查，並詢問哪個應該先執行。正確答案永遠是先執行 schema：如果物件在結構上損壞，語意檢查根本無法執行。

語意 Validation — 超越 Schema 合規的業務規則檢查

Schema validation 證明物件格式正確。語意 validation 證明物件正確。這是兩個不同的問題，需要不同的機制。

語意 Validation 涵蓋的範圍

語意 validation 將無法用 JSON Schema 約束表達的業務規則編碼進去。典型的檢查包括：

• 跨欄位一致性 — 發票總額等於明細項目加稅額的總和。
• 領域範圍檢查 — 訂單日期在過去 365 天內。
• 參照完整性 — 客戶 ID 確實存在於客戶資料表中。
• 邏輯依賴 — 若 has_discount 為 true，則 discount_amount 必須為正數。
• 文件一致性 — 擷取出的欄位不與其他欄位或來源文件矛盾。
• 數值合理性 — 小包裹訂單上出現 50,000 公斤的運送重量令人起疑。

語意 Validation 必須由你的應用程式實作

這是 CCA-F 的高頻陷阱。Claude 不會自動執行語意 validation。Strict tool schema 無法表達「總額必須等於明細項目的總和」。這條規則存在於你的應用程式程式碼中——無論是手寫的斷言、規則引擎，還是專門用來檢查第一次 extraction 的第二次 Claude 呼叫。Validation 層是你的程式碼，不是 Claude 的。

單一文件 vs 跨文件語意檢查

語意檢查分為兩類：

• 單一文件 — 規則只參照擷取出的物件本身（總額 = 明細之和）。
• 跨文件 — 規則參照外部狀態（客戶 ID 存在；供應商在核准清單上）。

跨文件檢查需要資料庫查詢或 API 呼叫，通常較慢且成本較高。設計 validation 層意味著決定哪些檢查對每次 extraction 執行，哪些只在某個旗標觸發時才執行。

語意 Validation 本身可以使用 Claude

CCA-F 情境中出現的一種生產模式，是使用第二次 Claude 呼叫來 validate 第一次 extraction。第一次呼叫負責 extraction；第二次呼叫獲得 extraction 加上來源文件，並被詢問 extraction 是否忠實。這有時被稱為 LLM-as-judge 模式。它不能取代確定性的規則檢查——它是捕捉規則遺漏的語意錯誤的額外層次。

Retry 觸發條件 — Schema 失敗、信心值低於閾值、必填欄位缺失

當 validation 層產生一個可行動的失敗——一個修正提示有可能修復的錯誤時，就會觸發 retry。並非所有失敗都是 retry 的候選；有些是不可恢復的，必須立即升級。CCA-F 要求考生知道三個典型的 retry 觸發條件。

觸發條件一：Schema Validation 失敗

擷取出的 JSON 違反了宣告的 schema——必填欄位缺失、值的型別錯誤、enum 超出允許集合、數值邊界被突破。Schema 失敗是高可信度的 retry 候選，因為錯誤可以精確描述：你可以告訴 Claude 確切是哪個欄位違反了哪個約束。

觸發條件二：信心值低於閾值

當 extraction schema 包含每欄位信心分數（例如，confidence: number between 0 and 1），且一個或多個欄位低於設定的閾值時，extraction 在技術上並非損壞，但不夠可信。此情況下的 retry 通常將低信心欄位清單回傳給 Claude，並指示它更仔細地重新審查那些特定欄位。

觸發條件三：必填欄位缺失或為空

一個本不應該為空的欄位，回傳了空字串、null 或佔位符（"N/A"、"unknown"）。即使 schema 將該欄位宣告為選填，你的業務規則也可能要求它必須有值。Retry 可以要求 Claude 在回退為 null 之前，重新檢查來源文件以尋找缺失的資訊。

何時不應 Retry

並非每個失敗都要 retry。不可恢復的觸發條件包括：

• 來源文件無法辨識 — 再多的重新提示也無法修復 OCR 垃圾內容。
• 必要資訊不存在於來源中 — 如果發票沒有供應商稅號，Claude retry 二十次也製造不出一個。
• Retry 預算耗盡 — retry 次數已達上限（見下文）。
• Schema 定義本身損壞 — 這是程式碼缺陷，不是模型缺陷。

在上述任何情況下發送 retry，都只是浪費 token，並第二次產生相同的失敗。

Retry 提示設計 — 將 Validation 錯誤作為修正指令回饋

Retry 只有在你放入足夠資訊的情況下才有效。核心原則是：將 validation 錯誤視為給 Claude 的自然語言修正指令。這就是將損壞的 extraction 轉換為修正版本的 feedback loop。

三段式 Retry 提示

每個有效的 retry 提示組合三個元件：

1. 原始 extraction 目標 — 來源文件或其相關切片。
2. 先前（損壞的）extraction — Claude 上次產生的物件。
3. Validation 錯誤描述 — 具體哪裡出錯，以自然語言加上結構化細節說明。

Claude 接著產生一個新的 extraction，（理想情況下）修正特定的錯誤，而不干擾已經正確的欄位。

錯誤描述的格式

Validation 錯誤應結構化且精確。好的錯誤描述包含：

• 哪個欄位失敗 — 使用 JSON path（例如 line_items[2].tax_rate）。
• 它違反了什麼規則 — 「必須是 0 到 1 之間的數字」或「必填但為 null」。
• 什麼能滿足規則 — 「請將稅率擷取為小數；發票顯示 8.25%」。

對比一個糟糕的錯誤描述：「輸出有誤。」Claude 無法修正它無法定位的東西。

使用帶有 is_error: true 的 tool_result

在 agentic loop 架構中，retry feedback 通常被包裝為帶有 is_error: true 的 tool_result 區塊，錯誤描述放在 content 欄位。Claude 對 is_error: true 的反應是以修訂過的輸入重新發出工具呼叫。這個模式與任務 2.2（MCP 工具的結構化錯誤回應）所教的機制完全相同，只是應用在 extraction validation 上。

盡可能保留已成功的欄位

一個細緻但常見的生產模式：如果十一個擷取欄位中有十個正確，retry 不應從頭重新 extraction。相反地，retry 提示包含十個正確欄位，並要求 Claude 只修正那個失敗的欄位。這就是欄位級 feedback（見下方專屬章節），在 CCA-F 的替代選項是浪費的全文件重新 extraction 時，這通常是正確答案。

Retry 次數上限 — 防止無限 Validation 迴圈

每個 retry 架構都必須對每份文件的 retry 嘗試次數設置硬性上限。沒有這個上限，一份有棘手問題的文件就能消耗無限 token，產生無上限的 API 帳單。CCA-F 將 retry 上限視為基準安全要求，與 agentic loop 的迭代上限要求相呼應。

典型的 Retry 上限

• 生產 extraction 流水線 — 2 到 3 次 retry。
• 開發與除錯 — 最多 5 次 retry，配合詳細日誌記錄。
• 高價值、高成本文件 — 最多 5 次 retry 加上升級審查。

超過 5 次 retry 幾乎總是適得其反。如果三次使用不同提示的嘗試都失敗了，第四次很少會成功；失敗模式通常是結構性的（來源文件模糊不清），而非偶發性的。

Retry 次數是每份文件，而非每個 Session

一批一萬份文件並非「一個 retry 預算」；每份文件都有自己的 retry 計數。當流水線移到下一份文件時，retry 計數器重置。混淆每份文件與每批次的 retry 語意，是 CCA-F 的一個干擾模式。

追蹤 Retry 狀態

實作通常在三個地方追蹤 retry 狀態：

1. 每份文件的 retry 次數 — 對該文件的每次 retry 遞增。
2. 每條流水線的失敗率 — 如果許多文件都在耗盡 retry，表示系統性出了問題（提示退化、來源資料轉移、模型版本更換）。
3. 每欄位的 retry 歷史 — 哪些特定欄位在多份文件中持續失敗。

這些指標為後文描述的可觀測性面向提供數據。

暫態失敗的指數退避 vs 提示修正的立即 Retry

Retry 分為兩類，各有截然不同的時間規則。混淆它們是 CCA-F 的常見陷阱。

暫態失敗 — 指數退避

當失敗是平台或網路狀況——達到速率限制、5xx 回應、逾時——正確的回應是指數退避 retry。典型模式：等待 1 秒，然後 2 秒，然後 4 秒，然後 8 秒，然後 16 秒，然後升級。在速率限制上立即 retry，往往只會再次觸發速率限制。

提示修正 Retry — 立即

當失敗是內容問題（validation 錯誤、欄位缺失、低信心值），正確的回應是以修改過的提示立即 retry。等待 16 秒沒有幫助——提示才是改變的東西，不是網路。在內容 retry 上退避只是浪費時鐘時間。

不要使用同一個計數器

兩類 retry 應使用獨立的計數器。暫態 retry 和提示修正 retry 在概念上是不同的事件，不應共享預算。

與 Agentic Loop 的整合

兩類 retry 都存在於任務 1.1 所教的 agentic loop 之中。差別在於 switch 陳述式的哪個分支觸發了 retry：

• 回傳 is_error: true, errorCategory: transient 的工具的 tool_use → 指數退避 retry。
• 成功回傳工具後的 validation 失敗 → 帶修正提示的立即 retry。

Feedback Loop 架構 — 錯誤描述 + 問題輸出 → 修正後的 Extraction

Feedback loop 是將 validation、retry 觸發邏輯和 retry 提示建構，組合成單一可重複使用元件的閉迴路架構。這是 CCA-F 考生應能隨時畫出的架構圖。

五節點 Feedback Loop

1. Extract — Claude 透過 strict tool use 產生結構化輸出。
2. Schema validate — 程式化 JSON Schema 檢查。失敗時，帶著 schema 錯誤前往節點 5。
3. 語意 validate — 應用程式層級的規則檢查。失敗時，帶著語意錯誤前往節點 5。
4. 接受 — extraction 通過所有檢查；提交至下游。
5. Retry 決策 — 是否在 retry 上限以下？若是，建立修正提示並回到節點 1。若否，升級。

迴圈的輸入與輸出

每次迴圈的迭代都有明確的輸入（來源文件 + 先前 extraction + 錯誤描述）和明確的輸出（接受的 extraction 或升級封包）。送給人工審查員的封包應包含來源文件、每次 extraction 嘗試，以及每個 validation 錯誤——這讓審查員擁有完整上下文，同時也是未來提示改善的訓練資料。

迴圈的終止條件

迴圈以三種方式終止：

• 成功 — extraction 通過 schema 和語意 validation。
• Retry 上限耗盡 — 文件升級至人工審查。
• 不可恢復的錯誤 — 來源文件無法辨識或缺少關鍵資訊；直接升級，不再進行進一步 retry。

迴圈是情境特定的

CCA-F 考試池中的結構化資料 extraction 情境直接考驗這個迴圈。預期會有題目測試你是否正確區分 retry 與升級、是否使用結構化而非通用的錯誤描述，以及你的最大 retry 上限是否合理。

欄位級 Feedback — 針對特定欄位的修正 vs 全文件重新 Extraction

當多欄位 extraction 部分成功——十一個欄位中有十個有效，一個損壞——retry 可以採用兩種形狀之一。

全文件重新 Extraction

將整份來源文件重新送回，要求對每個欄位進行全新的 extraction。實作最簡單；但浪費 token，並有風險降低先前正確的欄位。當失敗顯示整個 extraction 系統性地出錯時使用（例如，Claude 誤判了文件類型）。

欄位級修正

將來源文件加上十個正確欄位，再加上針對那個損壞欄位的修正指令一起送回。Claude 的回應是一個補丁，而不是一次全新的 extraction。保留先前正確的輸出並更快收斂。

何時選擇哪種方式

• 單一欄位失敗（一個欄位錯誤，其餘正確）→ 欄位級修正。
• 跨欄位不一致（欄位彼此矛盾）→ 全文件重新 extraction。
• 系統性失敗（整個 extraction 看起來偏移或幻覺）→ 全文件重新 extraction。
• 低信心欄位批次 → 只對標記欄位進行欄位級修正。

實作形狀

欄位級修正通常透過在用戶訊息中加入先前的 extraction 作為上下文來實作，並附上明確的指令：「以下是先前的 extraction。欄位 X 因 Y 而無效。請產生更新後的 extraction，修正欄位 X 並保持所有其他欄位不變。」

CCA-F 的偏好

社群通過報告指出，當問題將錯誤描述為「<specific_field> 無效」而非「extraction 有誤」時，CCA-F 情境傾向偏好欄位級修正而非全文件重新 extraction。仔細閱讀問題——錯誤的範圍通常是正確 retry 形狀的提示。

信心值校準 — 使用欄位級信心分數來優先安排 Validation

成熟的 extraction schema 在每個欄位上都包含一個 confidence 分數。Claude 被要求不僅擷取值，還要評估對 extraction 的信心程度。信心分數驅動 validation 優先順序和 retry 觸發條件。

如何在 Schema 中宣告信心欄位

新增平行欄位結構或巢狀 { value, confidence } 物件：

• 扁平平行：invoice_total 和 invoice_total_confidence。
• 巢狀：invoice_total: { value: 1234.56, confidence: 0.92 }。

巢狀結構通常更整潔、更易於 validate。

使用信心值作為 Retry 觸發條件

為每個欄位（或欄位類別）定義信心閾值。若信心低於閾值，該欄位就加入 retry 目標清單。典型閾值：

• 關鍵欄位（金額、日期、法律識別碼）— 0.90。
• 標準欄位（姓名、描述）— 0.75。
• 選填欄位（備註、標籤）— 0.60。

校準並不完美

Claude 自我回報的信心值並不是校準過的機率。它更接近「這讓我感覺有多確定」的評分。將信心分數視為相對優先順序訊號——「哪些欄位值得更多審查」——而非頻率主義意義上的機率。

將信心值與語意檢查交叉比對

通過語意 validation 但信心值低的欄位仍應被標記。未通過語意 validation 但信心值高的欄位，揭示 Claude 自信地犯了錯——這是一個需要收緊 validation 規則或提示標準的訊號。

Retry 耗盡後的升級 — N 次嘗試失敗後路由至人工審查

當達到 retry 上限，但 extraction 仍未通過 validation 時，feedback loop 以升級作為終止。升級不是「失敗」——它是一個設計好的結果，將文件移至一個人工審查員有足夠上下文可以完成 extraction 的佇列。

升級封包應包含的內容

• 來源文件 — 內嵌或以 URI 參照。
• 每次 extraction 嘗試 — Claude 產生的 N 次嘗試。
• 每個 validation 錯誤 — 每次嘗試的 schema 失敗和語意失敗。
• 任何工具錯誤 — 過程中發生的暫態失敗。
• 元資料 — 文件類型、retry 次數、消耗的總 token 數、時間戳記。
• 建議重點欄位 — 審查員不應該必須從頭重新 validate。

升級路由

升級並不總是流向單一的人工佇列。常見的路由規則包括：

• 依欄位類型 — 稅務識別碼流向財務訓練的審查員；法律條款流向法律團隊。
• 依信心模式 — 多個低信心欄位表示文件品質問題；路由至文件收件團隊。
• 依文件來源 — 某些供應商或文件類別有專屬的審查員。

升級為提示改善提供原料

升級的 extraction 是改善 extraction 提示的最佳訓練訊號。收集升級封包、分析常見的失敗模式，並改善提示和 schema。若一條流水線對許多文件都因同一個欄位的同一個原因升級，這在告訴你提示缺少對某個案例的覆蓋。

不要靜默地丟棄失敗的 Extraction

一個細微的反模式：當 retry 耗盡時，流水線「失敗」了這份文件並記錄在某處，但沒有人工審查員看到它。這比沒有流水線更糟——它製造了 extraction 覆蓋率的假象，同時悄悄遺失文件。升級必須是一個設計完善、受監控的佇列，附有服務水準協議（SLA），而不是一個丟棄資料夾。

可觀測性 — 記錄每個 Validation 結果和 Retry 嘗試

生產環境的 validation-retry 迴圈若沒有遙測數據就無法運作。有六個訊號至關重要：

需要埋點的訊號

1. 每份文件的 retry 次數 — 在你的語料庫中的分佈，揭示哪種文件類型最難處理。
2. 每欄位的 validation 失敗率 — 哪些欄位最常失敗；是提示改善的候選。
3. Schema vs 語意失敗比率 — 若語意失敗佔主導，你的提示太寬鬆；若 schema 失敗佔主導，你的 strict tool use 設定有誤。
4. Retry 收斂率 — 第 1 次 vs 第 2 次 vs 第 3 次嘗試中，有多少比例的 retry 成功。
5. 升級率 — 達到人工審查的文件總百分比。
6. 每次接受 extraction 消耗的 token — 每單位成功輸出的成本。

警示閾值

當上述任何指標偏離基準線時發出警示。例如，模型版本升級後 schema 失敗率突然跳升，是 extraction 提示在新模型上退化的早期預警。

Feedback Loop 品質隨時間改善

一條良好埋點的 validation-retry 流水線，會成為一個飛輪：可觀測性訊號驅動提示改善，改善的提示降低 retry 率，降低的 retry 率釋放預算用於額外的 extraction 或更徹底的語意檢查。沒有可觀測性的流水線，停滯在其初始品質水平，再也無法提升。

白話說明

抽象的 validation-retry 機制，一旦錨定在實體系統上就會變得直觀。三個不同的類比涵蓋了完整的設計面向。

類比一：辦桌師傅的出菜關卡

想像一位在繁忙辦桌現場坐鎮出菜口的主廚。每一道從廚房出來的菜，都要在出菜口停下來讓主廚過目：蛋白質正確、配菜正確、溫度正確、擺盤合乎規範。那個檢查就是 validation。如果這道菜完美無缺，就交給上菜人員（接受）。如果這道菜有可修復的缺陷——裝飾物擺錯、醬汁淋錯地方——主廚就帶著具體的修正意見退回：「12 桌點的是醬汁放旁邊，不是淋在主菜上。重新擺盤。」這就是欄位級 retry——你不需要重做整道菜，只要修正那個問題就好。如果這道菜根本性地錯誤——肉切錯部位、過火無法挽救——主廚就把整盤菜退回廚房重做（全文件重新 extraction）。如果廚房把同一盤菜退了三次還是做不對，主廚就把菜免費招待、讓餐廳經理親自去向客人道歉（升級至人工審查）。出菜口就是 validation 層。帶著具體指示的退菜就是 feedback loop。免費招待加派經理就是 retry 耗盡後的升級。一個沒有出菜口的廚房，會把壞菜直接送到客人桌上——等同於沒有 validation 的流水線靜默提交損壞的 extraction。

類比二：文字編輯的校稿標記

想像一位作者把初稿交給文字編輯。文字編輯拿著紅筆通篇閱讀。文法錯誤是機械性且確定性的（schema validation）——主詞和動詞不一致、缺少逗號、標題格式錯誤。內容錯誤是語意性且需要判斷的（語意 validation）——第三段引用的事實與第一段矛盾、引言歸屬的人名錯誤、結論中的論點與前文論據不呼應。文字編輯不會把草稿整篇重寫；他們標記出具體問題，附上備註交回：「第 4 頁第 2 段——這句話是愛因斯坦說的，不是波耳。請修正。」那份標記就是修正式 retry 提示——錯誤描述加上問題輸出加上來源上下文。作者修改後重新送審。如果稿子在三輪之後仍有問題，總編輯就把這篇文章抽出來，改派資深作者接手（升級）。一個只說「寫得不好」而不指向具體段落的編輯，完全沒有用——這就是為什麼 retry 提示必須包含具體的欄位路徑和具體的規則違反，而不只是「extraction 有誤」。

類比三：機場安全檢查流程

把 extraction 流水線想像成行李通過機場安全檢查的過程。第一個關卡是 X 光掃描——一個確定性的自動化檢查，尋找特定的形狀（schema validation）。如果掃描器看到明顯的違禁物品，行李就被標記。第二個關卡是人工檢查員打開行李，依照詳細規則組核對內容物（語意 validation）——超過 100 毫升的液體、散放在托運行李中的電池、看起來合法但違反特定規定的物品。一個未通過 X 光的行李，可能只需要重新擺放再掃一次（帶修正的立即 retry）。一個有可修復問題的行李——筆電需要拿出來——觸發的是針對性修正，而不是把整個行李清空（欄位級修正）。連續多次未通過檢查的行李，就被帶到旁邊請督導審查（升級）。安全人員絕不會因為隊伍太長就揮手讓行李直接通過——那等同於為了達到吞吐量目標而讓流水線接受失敗的 extraction。架構比速度更重要。

考試當天選用哪個類比

• 關於 retry 迴圈架構和接受-retry-升級三態的題目 → 辦桌師傅的出菜關卡類比。
• 關於錯誤描述品質和欄位級修正的題目 → 文字編輯校稿類比。
• 關於 schema vs 語意 validation 順序和 retry 耗盡後的升級的題目 → 機場安全檢查類比。

常見考試陷阱

CCA-F Domain 4 在 validation 和 retry 迴圈周圍利用五種反覆出現的陷阱模式。全部五種都在社群通過報告中以合理的干擾選項形式被記錄。

陷阱一：未修改提示就 Retry

提議「retry extraction」但未指定 retry 包含 validation 錯誤的答案是錯的。在 Claude 已經失敗過的相同提示上 retry，幾乎總是以同樣方式失敗。修正式 retry 必須嵌入具體的 validation 錯誤，讓 Claude 擁有上一次嘗試所沒有的資訊。

陷阱二：假設 Claude 執行語意 Validation

將 Claude 視為自我 validating 的答案——「Claude 將產生正確的輸出，因為 strict tool use 強制執行 schema」——混淆了 schema 合規與語意正確性。Claude 的 strict tool use 保證輸出的 JSON 符合 schema，但業務規則（總額 = 明細之和、日期在範圍內、ID 存在）必須由你的應用程式實作。任何將語意 validation 單獨委派給 Claude 的答案都是錯的。

陷阱三：沒有 Retry 上限

任何未指定硬性 retry 上限的 validation-retry 設計，都未達到基準安全標準。無限 retry 的流水線，可能因為一份有問題的文件而燒光 API 預算。正確的上限通常是每份文件 2 到 3 次。

陷阱四：混淆暫態退避與提示修正 Retry

指數退避是暫態失敗（速率限制、網路逾時、5xx 回應）的正確策略。立即 retry 是提示修正失敗（validation 錯誤）的正確策略。在 schema 違規後等待 16 秒是浪費時鐘時間；不退避就 retry 速率限制錯誤是浪費嘗試次數。干擾答案將兩類混在一起。

陷阱五：沒有升級路徑

當達到上限後靜默結束的 retry 架構——沒有人工審查佇列、沒有警示、沒有日誌 hook——產生靜默的資料品質債務。正確的設計始終包含一個升級封包，由來源文件、每次 extraction 嘗試、每個 validation 錯誤和元資料組成，路由至帶有 SLA 的受監控人工審查佇列。

練習錨點

Validation-retry 內容在 CCA-F 六大情境池的結構化資料 extraction 情境中大量出現。將以下內容視為情境叢集題的核心骨幹。

結構化資料 Extraction 情境 — 任務 4.4 直擊

在這個情境中，一條流水線接收一批文件串流（發票、合約、病歷、結構化表單），並為下游系統產生資料庫就緒的物件。Validation-retry 迴圈是流水線的骨幹。預期會有題目測試：

• Schema vs 語意 validation 順序 — 永遠先執行 schema。
• Retry 提示建構 — 嵌入具體錯誤，而非通用的「再試一次」。
• 欄位級修正 vs 全文件重新 extraction — 單一欄位失敗用欄位級修正；系統性失敗用全文件重新 extraction。
• Retry 上限與升級 — 2 到 3 次 retry，然後帶完整上下文封包升級。
• 信心值作為 retry 觸發 — 低信心欄位獲得目標性的重新審查。
• is_error: true 的 tool_result 形狀 — 當 extraction 透過工具使用連接時，validation feedback 的機械傳遞者。

跨情境適用性

Validation-retry 模式也出現在「客服解決方案 Agent」情境（擷取的工單元資料必須在路由前 validate）和「多 Agent 研究系統」情境（subagent 輸出在協調者使用之前必須依 schema validate）。在這兩種情況下，都適用同樣的五節點 feedback loop 架構。

干擾選項識別練習

在情境題中，閱讀每個選項時留意以下紅旗：

• 「Retry extraction」但未指定修正提示。
• 「Claude 將 validate 輸出」但未進行應用程式層級的語意檢查。
• 「最多 retry N 次」但達到上限時沒有升級路徑。
• 「在 retry 前等待 16 秒」出現在 validation 失敗上（錯——那是暫態 retry 邏輯）。
• 「重新 extract 所有欄位」當錯誤只指向單一欄位時（浪費）。

消除這些干擾選項，通常能將選項範圍縮小到一個明確正確的答案。

FAQ — Validation 與 Retry Loop 前六大問題

Validation 與 Claude 自身的輸出正確性有何不同？

Validation 是應用程式層級的檢查，確保輸出可以安全地向下游提交。Claude 的 strict tool use 可以強制執行 schema 合規（結構），但無法強制執行業務規則、跨欄位一致性、參照完整性或領域範圍合理性。這些檢查存在於你的 validation 層中。將 Claude 視為自我 validating 是 CCA-F Domain 4 的前五大錯誤之一；語意正確性永遠是呼叫端應用程式的責任。

何時應 Retry，何時應升級至人工審查員？

當失敗是可行動的時，就 retry——可以指向特定欄位、可以指出具體的規則違反，且來源文件合理地包含正確資訊。當達到 retry 上限（通常每份文件 2–3 次）、來源文件無法辨識或不完整、或失敗具有額外的 Claude 呼叫無法修復的結構性特徵時，就升級。升級封包應包含每次 extraction 嘗試和每個 validation 錯誤，讓人工審查員擁有完整的上下文。

欄位級修正與全文件重新 Extraction 有何差別？

欄位級修正將來源文件加上先前（大部分正確的）extraction，加上針對特定欄位的修正指令一起送回；它保留先前正確的輸出並更快收斂。全文件重新 extraction 丟棄先前的輸出，要求 Claude 重新產生整個 extraction。對單一欄位失敗選擇欄位級修正；對系統性失敗選擇全文件重新 extraction（文件類型錯誤、跨欄位不一致、幻覺規模的錯誤）。

為什麼考試偏好在 Validation 失敗上立即 Retry 而非退避？

因為退避針對的是平台層級的狀況（速率限制、網路逾時），在失敗是內容問題時毫無益處。等待不能讓 validation 失敗消失——提示才是必須改變的變數。指數退避屬於暫態失敗的 retry 路徑（在工具錯誤被分類為暫態時）；帶修改提示的立即 retry 屬於內容 retry 路徑（在 schema 或語意失敗時）。混淆兩者是常見的干擾模式。

如何建構修正式 Retry 提示？

組合三個元件：（1）原始 extraction 目標（來源文件或相關切片），（2）先前損壞的 extraction，（3）以 JSON path 指名失敗欄位、以自然語言陳述違反的規則、並提示預期修正的結構化錯誤描述。當 extraction 透過 strict tool use 連接時，將錯誤包裝為帶有 is_error: true 的 tool_result。避免諸如「輸出有誤」這樣模糊的錯誤描述——Claude 無法修正它無法定位的東西。

信心分數在 Validation 與 Retry 決策中扮演什麼角色？

欄位級信心分數是 Claude 在每個擷取值旁邊發出的自我回報訊號。它們用於優先安排 validation、在低信心欄位上觸發目標性 retry，以及在即使 schema 和語意檢查通過的情況下，標記 extraction 供人工審查。信心分數不是校準過的機率——將它們視為相對優先順序工具。通過所有 validation 但信心值低的欄位仍值得再看一眼；未通過 validation 但信心值高的欄位，顯示 Claude 是自信地犯了錯——這是一個需要收緊提示標準或 validation 規則的訊號。

延伸閱讀

• Handle tool calls — tool_result format and error responses: https://docs.anthropic.com/en/docs/agents-and-tools/tool-use/handle-tool-calls
• Strict tool use — schema-guaranteed output: https://docs.anthropic.com/en/docs/agents-and-tools/tool-use/strict-tool-use
• Increase output consistency — structured outputs: https://docs.anthropic.com/en/docs/test-and-evaluate/strengthen-guardrails/increase-consistency
• Building effective agents — agentic loop reference: https://docs.anthropic.com/en/docs/build-with-claude/agentic-loop
• Tool use with Claude — overview and agentic loop: https://docs.anthropic.com/en/docs/agents-and-tools/tool-use/overview

Related ExamHub topics: Structured Output via Tool Use and JSON Schemas, Explicit Criteria Prompt Design, Iterative Refinement and Progressive Improvement, Error Propagation in Multi-Agent Systems.