多實例與多輪審查架構

CCA-F 考試任務說明 4.6——「設計 multi-instance 與 multi-pass 審查架構」——隸屬 Domain 4（提示工程與結構化輸出，佔比 20%），是一個 CCA-F 考生在單次 Claude 呼叫不夠可靠時所需要的模式語言。考試主要透過六個情境叢集中的兩個來考這個任務：結構化資料擷取（Structured Data Extraction，ensemble 與 judge model 模式能提升高風險欄位的精確度）以及多 agent 研究系統（Multi-Agent Research System，循序的專責 pass 與審查 instance 保護合成品質）。社群通過報告一致將 4.6 點名為「分數小但混淆性高」的主題，干擾選項聽起來都很有道理，除非你已背熟成本品質取捨與相同模型判斷的相關性錯誤失效模式。

這份學習筆記涵蓋 CCA-F 考生預期要設計的 multi-instance 與 multi-pass 完整面向：在同一輸入上平行執行 N 個 Claude instance，與在同一件輸出物上循序執行 N 個專責 pass，兩者在定義上的差異；具體的應用場景（高風險分類、法律審查、複雜程式碼分析）；ensemble voting 機制；judge model 批評模式；專責 pass 分解（語法、邏輯、合規性）；依賴關係排列 pass 順序；與單次高精力呼叫相比的成本品質取捨；跨 instance 與 pass 的 confidence 聚合；分歧升級門檻；以及用 temperature 變化作為多樣性槓桿。常見考試陷阱、CCA-F 練習錨點，以及六題 FAQ 作為收尾。

什麼是 Multi-Instance 與 Multi-Pass 審查架構？

Multi-instance 與 multi-pass 審查架構是兩個互補的模式族群，目的是讓 Claude 輸出的品質超越單次呼叫所能可靠產出的水準。它們是不同的模式，考生經常混淆，而考試正是測試你能否針對給定情境選出正確的那一個。

Multi-instance 架構將同一輸入平行送入多個獨立的 Claude instance，並聚合輸出結果（通常透過投票或評審）。變化的軸線是 Claude 本身——不同的隨機種子、不同的 temperature 設定，偶爾使用不同的模型——套用在相同的提示與相同的輸入上。

Multi-pass 架構將同一輸入依序送過多個 pass，每個 pass 使用不同的提示、角色或關注焦點。變化的軸線是審查視角——語法 pass、邏輯 pass、合規性 pass——套用在相同的輸出物上。

兩個族群可以結合（multi-pass 流水線的關鍵 pass 本身也是一個 multi-instance ensemble），但它們解決的問題不同。Multi-instance 降低單一答案的變異數。Multi-pass 將複雜的審查分解成更窄、更容易處理的子審查。

兩個族群一覽

Multi-Instance 架構 — 對同一輸入執行多次 Claude 呼叫以取得共識

最簡單的 multi-instance 架構是 N 樣本 ensemble：相同的 system prompt、相同的使用者輸入、相同的 schema，並行向 Claude 發出 N 次。每次呼叫回傳一個獨立輸出；聚合器將 N 個輸出合併為單一的最終答案。

為什麼要重複同一個呼叫 N 次

即使在 temperature 0 下，Claude 的輸出也不是完全確定性的，而在較高 temperature 時，變異數會顯著增大。對於同一個提示偶爾會給出邊緣錯誤答案的任務——分類錯誤的類別、遺漏的擷取欄位、偏移的情感標籤——執行該呼叫 N 次後取多數答案，可以平滑掉單次呼叫的雜訊。背後的統計主張很直觀：若每次呼叫以 p > 0.5 的機率獨立正確，則 N 次呼叫中多數正確的機率會隨 N 快速上升。

Multi-Instance 值得付出成本的時機

當以下三個條件同時成立時，multi-instance 才有價值：

• 單次呼叫的品質接近門檻但無法穩定超越。
• 執行 N 次呼叫的每單位成本可以接受（通常是因為下游決策的價值很高）。
• 各次呼叫之間的錯誤模式不相關（是變異數，而不是系統性盲點）。

Multi-Instance 用錯時機的情況

當底層模型對某個輸入有系統性盲點時，multi-instance 毫無幫助——若一個提示對某個邊緣案例持續給出錯誤分類，執行十次只會得到十份相同的錯誤答案。當一次高精力呼叫（更多上下文、更好的範例、更嚴格的工具 schema）就能達到品質門檻時，multi-instance 同樣無效；這種情況下，投資改善單次呼叫遠比對弱呼叫做 ensemble 更划算。

Multi-Pass 架構 — 對同一輸出物執行循序專責 Pass

Multi-pass 架構透過數個循序的 pass 審查同一輸出物（法律文件、程式碼差異、客服草稿），每個 pass 的關注焦點都比單一的全方位審查提示更窄。早期 pass 的輸出作為結構化上下文傳入後期 pass。

為什麼要讓 Pass 專業化

一個提示要求 Claude「審查這個 pull request 的安全性、效能、風格、測試覆蓋率和業務邏輯」，會將注意力稀薄地分散在所有五個視角上。同樣的五個關切，拆成五個循序 pass 分別執行，每個關切都能獲得一次 Claude 呼叫的完整指令預算與完整輸出預算。社群回報的考試措辭明確指出：只要視角之間會相互爭奪注意力，將複雜判斷分解成更窄步驟的效果就會優於單一的超大提示。

三 Pass 的典型形狀

常見的 CCA-F 等級流水線長這樣：

1. 結構 pass — 輸出物的形狀對嗎？（有效的 JSON、預期的章節是否存在、必填欄位是否填寫。）
2. 內容 pass — 給定業務背景，內容正確嗎？（事實是否與來源一致、邏輯是否合理、主張是否有據可查。）
3. 風格／合規性 pass — 輸出物是否符合呈現規範與法規要求？（語調、長度、必要的揭露聲明、禁止語句。）

每個 pass 產生一份結構化報告（通過／未通過加上注記），下一個 pass 接收這份報告。最終輸出是綜合裁定。

Multi-Pass 就是以審查者角色進行的提示串鏈

Multi-pass 審查是提示串鏈的特定應用。串鏈提示文件描述了通用模式；multi-pass 審查將其縮小到每個步驟都是審查者從不同角度檢視同一輸出物的情況，而非由建構者產生新的輸出物。

應用場景 — 高風險分類、法律審查、複雜程式碼分析

CCA-F 的情境題傾向挑選單次呼叫「看起來勉強夠用」的應用場景，然後要求你說明多一道審查架構的額外成本是否合理。三個典型的應用族群承載了絕大部分的考題權重。

高風險分類（結構化資料擷取情境）

當分類標籤驅動下游業務決策——詐欺／非詐欺、升級／自動關閉、監管申報的匹配／不匹配——時，單次呼叫的變異數直接轉化為業務風險。一個五 instance 的 ensemble 搭配 majority vote，能將 85% 準確率的單次呼叫提升到精準度高出許多的最終答案，通常成本仍遠低於錯誤標籤的下游代價。

法律審查

法律文件結合了數個各自獨立複雜的審查視角——條款間的定義一致性、交叉引用完整性、符合特定司法管轄規則、合約條款邊界——這些視角無法乾淨地塞進一個提示中。以每個視角各一個 pass、依依賴關係串鏈的 multi-pass 流水線，表現持續優於單一的「審查這份合約」呼叫。Multi-pass 的結果也更容易稽核，因為每個 pass 各自產生獨立的審查軌跡。

複雜程式碼分析（使用 Claude Code 的程式碼生成情境）

程式碼審查需要正確性審查、安全性審查、風格審查和測試覆蓋率審查。Multi-pass 流水線讓每個視角在自己的 pass 中執行，以結構 pass（diff 能不能編譯？）作為後續語義 pass 的閘道。對於極高風險的變更，關鍵 pass（例如安全性）本身可以作為 multi-instance ensemble 執行，結合兩個族群的優點。

其他生產等級的候選場景

• 醫療分診記錄審查（multi-pass：症狀擷取，接著風險評分，接著處置建議）。
• 財務揭露草稿（multi-pass：事實，接著合規性，接著語調；在合規性 pass 加上 multi-instance）。
• 學術同儕審查模擬（對同一篇論文執行 multi-instance，搭配 temperature 變化以呈現多元批評）。

Ensemble Voting — 跨獨立 Instance 的 Majority Vote 以提升穩健性

Ensemble voting 是最典型的 multi-instance 聚合器。三種投票策略幾乎涵蓋了所有考試情境。

單純 Majority Vote

N 個 instance 各自產生一個類別輸出。聚合器選取票數最多的類別。平局由確定性規則打破（例如取字典序最小的標籤，或用打破平局的提示重新詢問）。這是單標籤分類的正確聚合器（垃圾郵件／非垃圾郵件、12 個選項的類別、嚴重等級 1-5）。

依 Confidence 加權投票

每個 instance 不只回傳標籤，還回傳 confidence 分數。票數依 confidence 加權。高 confidence 的 instance 影響力大於兩個低 confidence 的 instance。這個做法需要模型產生校準的 confidence——預設情況下模型往往做不到，所以在依賴加權投票之前，務必評估校準程度。

結構化擷取的欄位級投票

針對結構化擷取，投票是逐欄位進行的。若五個 instance 各自擷取含有 name、date_of_birth、diagnosis_code 欄位的 JSON 物件，聚合器對每個欄位獨立投票。這非常重要，因為單一 instance 可能對四個欄位完全正確但遺漏了其中一個；欄位級投票保留了正確的四個欄位，並以 ensemble 多數結果取代第五個。

為什麼選奇數 N

對於 majority vote 的 ensemble，永遠選奇數 N（3、5、7），這樣在二元或少數類別的問題上就不可能出現平局。偶數 N 需要打破平局的機制，這要嘛增加延遲（重新詢問），要嘛引入偏差（永遠選第一個、永遠選最高 confidence 的）。

Judge Model 模式 — 用第二個 Claude Instance 評分或批評第一個輸出

Judge model 模式是一種兩步驟的 multi-instance 架構：第一個 instance 產生候選輸出，第二個 instance——judge——對候選輸出評分、批評，或接受／拒絕。Judge instance 被給予不同的、以審查為導向的 system prompt。

兩種常見變體

• 評分加閘控（Score-and-gate） — judge 回傳數值分數加上通過／未通過；低於門檻的輸出被拒絕，然後重新生成、升級，或轉給人工審查者。
• 批評加修訂（Critique-and-revise） — judge 回傳結構化反饋（具體問題，不只是成績），原始 instance 根據反饋重新生成，循環持續直到 judge 核准或達到重試上限。

Judge 帶來價值的時機

當審查任務比生成任務更容易時，judge 才能帶來價值。撰寫連貫的摘要很難；評估摘要是否忠實呈現來源較為容易。起草一個符合法規的條款很難；檢查一個草稿條款是否達到七個必要要點較為容易。這種不對稱性是將生成與審查分離的核心理由。

相關性錯誤的風險

由於 judge 通常與候選產生者使用相同的 Claude 模型，模型的任何系統性盲點都被 judge 共享。若 Claude 持續誤讀某個慣用語，judge 也不會標記出來。相同模型的 judge 能有效降低隨機錯誤和風格錯誤，但無法捕捉相關性錯誤。社群通過報告將此列為反覆出現的陷阱——聲稱「judge 保證正確性」的答案是錯的。

Judge 提示設計

Judge 提示應明確說明評分標準，應足夠簡潔以讓 judge 的注意力完全用於審查，並應要求結構化輸出（schema 或 tool use），讓聚合器能以程式化方式對 judge 的裁定採取行動。以自由格式散文為基礎建立的 judge，很難整合進可靠的流水線。

專責 Pass 設計 — 將審查分解成語法、邏輯、合規性 Pass

專責 pass 設計是將廣泛的審查切分為窄小 pass 的技藝，每個 pass 都能由單次 Claude 呼叫準確執行。細節因領域而異，但方法是一致的。

選取正交視角

好的 pass 是正交的——它們審查輸出物的不同維度，使其發現不會重疊。語法、邏輯和合規性是正交的：語法關乎形式，邏輯關乎意義，合規性關乎規則。選取不當的 pass 會重疊（例如「風格」和「語調」大多會重複彼此的發現），浪費每個 pass 的呼叫預算。

保持每個 Pass 的範疇窄小

每個 pass 的提示應控制在大約一頁的焦點指令以內。指令長達好幾頁的 pass，實際上是多個 pass 假裝成一個，應進一步拆分。

產生結構化報告，而非散文

每個 pass 都應產生結構化報告（tool use 或 JSON schema），讓流水線能在不需要解析自由文字的情況下對發現採取行動。語法 pass 回傳 {issue, location, severity} 的清單。邏輯 pass 回傳 {claim, status, evidence} 的清單。合規性 pass 回傳 {rule_id, satisfied, explanation} 的清單。

將發現整合回輸出物

專責 pass 通常匯入一個最終修訂 pass，由它接收輸出物加上所有 pass 的報告，並產生修訂後的版本。這有別於審查 pass 本身，應作為獨立的呼叫來撰寫。

Pass 排序 — 依依賴關係排列 Pass 順序（結構 → 內容 → 風格）

正確排列 pass 順序，其重要性不亞於選擇 pass 本身。錯誤的順序會浪費預算在後來 pass 的發現已被其他 pass 推翻的情況上。

依賴關係優先排序

先執行結構 pass（輸出物的形狀是否正確？），接著執行內容 pass（它說的內容是否正確？），最後執行風格或合規性 pass（它是否符合規範？）。顛倒這個順序——例如在結構 pass 之前執行合規性 pass——可能導致合規性 pass 審查了一個結構 pass 之後會直接拒絕的輸出物，白白浪費合規性的工作。

遇到硬性失敗時短路退出

若結構 pass 回傳「這根本不是一份有效的合約」，就不要執行內容 pass。在硬性失敗上提前退出，是排序的類比版本，對應 agentic loop 內部的重試或中止決策——最便宜的工作是你跳過的工作，因為前一步驟已經給出了答案。

讓 Pass 相互輸入

某些 pass 需要前面 pass 的輸出作為輸入。「事實查核」pass 需要「主張擷取」pass 先列出所有主張。「審閱標記」pass 需要「差異擷取」pass 先列出所有變更。流水線 DAG 而非嚴格的線性串鏈，能乾淨地表達這些依賴關係。

在安全時平行化正交 Pass

真正獨立的 pass 可以平行執行。語法 pass 不依賴邏輯 pass 的輸出，反之亦然；並行執行它們能縮短掛鐘延遲，且不會改變聚合結果。

成本品質取捨 — Multi-Instance 與單次高精力呼叫的經濟學比較

Multi-instance 架構將每單位成本乘以 N。在使用 ensemble 之前，每位 CCA-F 架構師都應先問：單次高精力呼叫——更好的上下文、更好的範例、更嚴格的工具 schema、更強大的模型——是否能以更低成本達到品質門檻？

三個預算問題

1. 品質空間 — 單次呼叫已經接近門檻，還是遠低於門檻？對遠低於門檻的呼叫做 ensemble 仍然讓你低於門檻。對接近門檻的呼叫做 ensemble 才能把你推過去。
2. 成本空間 — 下游決策的價值是否足以合理化 N 倍的呼叫成本？一份免費電子報中使用的 0.001 美元分類，無法支撐五 instance 的 ensemble；而用於閘控一份一萬美元法律申請的 0.001 美元分類，顯然可以。
3. 延遲空間 — 使用者等得及嗎？Multi-instance 通常是平行的（除了最慢的那個呼叫外沒有額外延遲），但 multi-pass 是循序的（所有 pass 的延遲加總）。在延遲敏感的情境中，multi-pass 比其成本表看起來更昂貴。

批次處理作為成本槓桿

對於非延遲敏感的 multi-instance 流水線，Message Batches API 將每次呼叫的成本降低約一半（目前定價享 50% 折扣）。五 instance 的 ensemble，若以一個批次作業提交所有 instance，成本接近 2.5 instance 的同步 ensemble。當流水線位於面向使用者的請求內部時，批次不適用，因為批次結果可能需要長達 24 小時。

單次高精力呼叫作為反向設計

搭配更豐富上下文、更多範例、更嚴格的 JSON schema（strict tool use）和更強大模型（Opus 級別而非 Sonnet 級別）的單次呼叫，有時以相同成本擊敗五 instance 的 ensemble。考試獎勵在預設採用 N 樣本 ensemble 之前考慮過這種反向設計的架構師。

Confidence 聚合 — 跨 Instance 或 Pass 合併 Confidence 訊號

Ensemble 或 multi-pass 流水線產生的不只是最終答案——它也產生比任何單次呼叫所能回報的更豐富的 confidence 訊號。

同意率作為 Confidence

在單純 majority 的 ensemble 中，投票給獲勝答案的 instance 比例，是 confidence 的可用代理指標。五 instance 全數同意是強 confidence。三 instance 中的三 instance 同意是弱 confidence，應觸發人工審查。這個代理指標是模型無關的——即使模型本身不產生校準的 confidence 分數，它也能運作。

來自每個 Instance 分數的加權 Confidence

當每個 instance 回傳 confidence 分數時，最終 confidence 可以計算為獲勝投票的加權平均值。這比單純的同意率更具資訊量，但需要模型產生校準的分數。

Multi-Pass 的 Confidence 是合取性的

在 multi-pass 流水線中，所有 pass 都必須核准，輸出物才能通過。整體 confidence 是每個 pass confidence 的乘積（或最小值），而非總和。若合規性 pass 有 70% 的 confidence，結構 pass 有 99% 的 confidence，則流水線 confidence 最多只有 70%。

校準比絕對值更重要

Confidence 分數只有在校準時才有用——0.8 的 confidence 應對應 80% 的實際準確率。Claude 的原始 confidence 分數通常未校準，需要在應用層進行校準（例如透過留存的驗證集），才能驅動路由決策。

分歧處理 — Instance 投票分歧顯著時的升級機制

Multi-instance 流水線最有價值的地方在於它的分歧訊號。當 instance 同意時，流水線順利通過；當 instance 分歧時，流水線浮現了一個真實的不確定性，值得特別處理。

升級的門檻

典型的生產門檻：

• 全數同意 — 自動接受答案。
• 超過多數（例如 5 中的 4）— 接受但記錄日誌以供定期稽核。
• 勉強多數（例如 5 中的 3）— 升級給人工審查者或更高能力的模型。
• 沒有多數 — 轉給人工審查；不自動解決。

升級目標

• 人工審查者 — 高風險工作的典型升級對象。
• 更大的模型 — 有時將爭議輸入送過 Opus 而非 Sonnet 就能解決分歧（成本遠低於永遠執行 Opus）。
• Extended thinking 變體 — 某些分歧在使用鼓勵更深思熟慮的 extended thinking system prompt 執行同一輸入時會得到解決。
• 補充上下文重試 — 提供更多上下文（來源文件、標準範例）通常能將三中的三轉為五中的五。

分歧記錄本身就是一項產品

每次分歧都是提示、範例或 schema 可能需要改進的訊號。一條將分歧軌跡與完整上下文一起存檔的生產流水線，就擁有了提示改進的反饋迴路。這正是 Anthropic 升級指南強調以完整上下文記錄分歧以供定期審查的原因。

Temperature 變化 — 在 Instance 之間使用不同 Temperature 設定以產生多樣性

以 temperature 0 執行 N 個 instance，會得到 N 個幾乎相同的答案，這違背了 ensemble 的目的。Temperature 變化是產生足夠多樣化輸出、使 majority voting 有意義的主要槓桿。

Temperature 與多樣性的關係曲線

在 temperature 0 時，Claude 的輸出盡可能是確定性的——ensemble instance 會收斂到相同的答案。在適中的 temperature（約 0.5）時，輸出的變化足以讓投票有資訊量，同時每個單獨的輸出品質仍然高。在極高的 temperature（超過 1.0）時，輸出變得不穩定，品質的下降速度快過多樣性的提升。

實用的 Temperature 排程

• 所有 instance 在 0.5 到 0.7 之間 — 簡單、有效，且是社群回報的預設值。
• 交錯 temperature（例如 0.3、0.5、0.7、0.9、1.1）— 適合創意任務，需要廣泛的風格選擇時有用。
• Temperature 0 加種子變化 — 若有支援；提供嚴格控制的多樣性。不一定總是可用。

Temperature 不是品質槓桿

提高 temperature 不會讓 Claude 更聰明；它讓 Claude 的輸出更多樣化。Temperature 在 multi-instance 架構中的作用純粹是產生足夠的多樣性使投票有意義。低 temperature 且無種子變化會讓 ensemble 失效；高 temperature 且無品質守衛會讓 ensemble 崩潰。

將 Temperature 與 Tool Use 結合

當擷取透過 strict tool use 強制執行時，schema 是固定的，但 schema 內部的值仍會隨 temperature 變化。temperature 0.5 的五 instance 擷取 ensemble 仍會產生五個有效的 JSON 物件；投票接著對這五個物件逐欄位進行。

結合 Multi-Instance 與 Multi-Pass

兩個族群是互補的，且經常結合使用。Multi-pass 流水線中的關鍵 pass 通常作為 multi-instance ensemble 執行，而非關鍵的 pass 則保持為單次呼叫。

範例流水線

一個合約審查流水線：

1. 結構 pass（單次呼叫，成本低）。
2. 內容 pass（單次高精力呼叫）。
3. 合規性 pass（五 instance 的 ensemble 搭配欄位級投票，因為合規性錯誤的風險高且 ensemble 能防止單次呼叫的變異數）。
4. 修訂 pass（單次呼叫，使用所有前述 pass 的報告）。

這個混合設計只在最重要的地方花費 N 倍的呼叫成本。

為什麼不對每個 Pass 都做 Ensemble

由於 multi-instance 的成本以 N 線性增長，對 multi-pass 流水線中的每個 pass 都做 ensemble，成本會乘以各 pass N 值的乘積。一個三 pass 流水線，每個 pass 五個 instance，每個輸出物需要十五個呼叫預算。架構師只對單次呼叫變異數是主要風險的 pass 做 ensemble。

審查架構的可觀測性

審查流水線的可觀測性是 agentic loop 可觀測性的超集。每個 instance 的輸出、每個 pass 的輸出、每次投票結果，以及每份分歧軌跡，都必須能夠存檔。

應記錄的內容

• 每個 instance 的輸出（完整 JSON 或文字）。
• 每個 instance 的 confidence 分數（若有產生）。
• 每個欄位的聚合投票結果。
• 每個 pass 的報告（結構化發現）。
• Pass 依賴軌跡（哪些 pass 執行了、以什麼順序、使用什麼輸入）。
• 分歧軌跡（instance ID、temperature、分歧輸出），附上足以重現的上下文。

為什麼記錄是一等重要的事

審查流水線通常會被稽核。法律審查流水線必須能解釋為何某個條款被核准。醫療分診流水線必須能解釋為何某份記錄被路由到處置 X。流水線的輸出不只是最終裁定——它是最終裁定加上支撐它的推理軌跡。

白話說明

三個截然不同的類比涵蓋了 multi-instance 與 multi-pass 審查架構的完整面貌。

類比一：主治醫師會診 — 高風險診斷的 Multi-Instance Ensemble

想像一位有模糊診斷的病患。單一醫師對影像的判讀可能有 85% 的準確率——通常正確，偶爾出錯。對於高風險案例，醫院召集五位獨立主治醫師，各自不互相溝通地審閱同一張影像。五位中的四位說「良性」；一位說「惡性」。會議現在既有多數答案，也有清晰的分歧訊號。若五位全數同意，案例就結案；因為有一位不同意，會議升級至切片檢查。這是縮小版的 multi-instance 架構。影像是輸入。每位醫師是一個 Claude instance。醫師間的差異是多樣性——若每位醫師都出自同一個訓練計畫，他們的錯誤是相關的，會議帶來的提升效益較少（相同模型 judge 的問題）。打破平局或升級的規則是分歧處理。切片檢查是升級目標。Multi-instance 審查幾乎在每個方面都是一群獨立審查者看同一份輸出物的會議。

類比二：出版社的編輯流程 — Multi-Pass 循序專責審查

想像一份書稿經歷出版社的編輯流程。發展性編輯先讀，問「這本書的方向對嗎——結構是否連貫、主旨是否清晰？」若書稿通過發展性編輯，文字編輯接著讀，問「事實是否正確、主張是否有引用、邏輯是否合理？」若通過文字編輯，文案編輯接著讀，審查風格與語態。通過後，校對編輯最後讀，修正錯字與格式。每位編輯的工作都很窄、很專業。沒有人試圖同時扮演所有種類的編輯——這正是每個人在各自視角上都表現卓越的原因。這是縮小版的 multi-pass 架構。書稿是輸出物。每位編輯是一個專責的 Claude pass。在前面的編輯尚未簽核前就傳給後面的編輯是浪費——在結構上需要大幅改寫的書稿上修正錯字是白費功夫，這正是 pass 排序之所以重要的原因。遇到硬性失敗時短路退出，就是發展性編輯拒絕一份無法挽救的書稿；讓文案編輯審閱它毫無意義。Multi-pass 審查，非常接近於書籍出版的編輯流水線。

類比三：飛機起飛前的組員確認程序 — 兩個族群合用勝過單獨使用任一個

航空安全不依賴單一飛行員讀一份檢查清單。起飛前，機長和副機長逐一跑過一系列檢查清單——氣象、燃油、重量平衡、系統——兩位飛行員獨立讀出並確認每個項目。這些循序的清單是 multi-pass 架構：每份清單是一個專責 pass，涵蓋不同的視角，以依賴關係優先排序（燃油在重量平衡之前，重量平衡在引擎啟動之前）。每份清單上的雙人交叉確認是二 instance 的 multi-instance 架構：當機長和副機長各自獨立讀出燃油量並同意時，系統的 confidence 高於單一飛行員的讀出。若他們不同意，就升級（再看一次、詢問地面人員）。航空安全是現實世界中結合 multi-pass 排序與 multi-instance 交叉確認的典範案例，其經濟邏輯（兩個族群的成本都高於單一飛行員讀一份清單，且兩者在高後果任務上都值得）可以直接套用到高風險的 Claude 流水線上。

考試當天選用哪個類比

• 關於 multi-instance ensemble、voting 與 judge 模式的題目 → 主治醫師會診類比。
• 關於 multi-pass 流水線、專責 pass 與排序的題目 → 出版社編輯流程類比。
• 關於結合兩個族群與成本品質取捨的題目 → 飛機起飛前組員確認程序類比。

常見考試陷阱

CCA-F Domain 4 持續利用五種與 multi-instance 和 multi-pass 審查相關的反覆出現陷阱模式。全部五種都偽裝成合理的干擾選項出現在社群通過報告中。

陷阱一：將 Multi-Instance 視為正確性保證

Multi-instance 降低變異數；它並不降低相關性錯誤。若底層 Claude 模型對某個輸入有系統性盲點，ensemble 中的每個 instance 都共享這個盲點，每個 instance 都回傳相同的錯誤答案。干擾答案將 ensemble 框架為「保證正確」或「對模型錯誤免疫」；兩種框架都是錯的。正確的框架是 ensemble 以 N 倍成本換取隨機錯誤上更低的變異數。

陷阱二：相同模型的 Judge 宣稱獨立性

產生者與 judge 都是相同模型的 judge model 流水線，存在相關性錯誤的風險。若 Claude 持續誤讀某個法律措辭，Claude judge 也會錯過相同的錯誤。考試獎勵能認出這個限制並選擇使用不同模型的 judge（若可用）、高風險工作的人工審查者，或「judge 審查 N 個候選輸出」的 ensemble 形態的考生。

陷阱三：低估 Multi-Pass 的延遲

由於 multi-pass 是循序執行的，延遲線性累加。一個四 pass 的流水線，每個 pass 兩秒，在任何批次或面向使用者的渲染之前就需要八秒。將 multi-pass 用於低延遲聊天工作流程的干擾答案通常是錯的。考試獎勵將延遲敏感的工作路由到單次呼叫（可能搭配 strict tool schema），將延遲不敏感的工作路由到 multi-pass 流水線的考生。

陷阱四：結構化擷取使用整體物件投票

當五個 instance 各自回傳含有十個欄位的 JSON 物件時，整體物件投票在任何一個欄位有分歧時就丟棄所有正確的欄位。欄位級投票保留最多的資訊。將 ensemble 擷取描述為「選取多數 JSON 物件」的干擾答案是微妙的錯誤。正確的聚合器是逐欄位投票。

陷阱五：在成本敏感的流水線上沒有先嘗試更好的單次呼叫就做 Ensemble

Multi-instance 將成本乘以 N。若 temperature 0 搭配更嚴格 schema 或更多範例的單次呼叫就能達到品質門檻，ensemble 就是浪費的成本。考試獎勵能說明已嘗試或排除較簡單干預措施後才使用 ensemble 的架構師。跳過改善單次呼叫就直接做 ensemble 的干擾答案通常是錯的。

練習錨點

Multi-instance 與 multi-pass 概念最集中地出現在六個 CCA-F 情境中的兩個。

結構化資料擷取情境

在這個情境中，Claude 從非結構化文字——發票、申報表、法律申請書、臨床記錄——中擷取結構化欄位（實體、日期、金額、分類標籤）。單次呼叫的變異數通常是主要的錯誤來源，尤其在邊緣案例輸入上。預期會有題目測試你是否正確設計一個帶 temperature 變化的 multi-instance ensemble、是否採用欄位級投票而非整體物件投票、是否認識到相同模型判斷的相關性錯誤限制，以及是否將分歧路由到人工審查而非靜默地以多數解決。Strict tool use 幾乎總是在同一個流水線中使用，以確保每個 instance 回傳 schema 有效的物件。

多 Agent 研究系統情境

在這個情境中，協調器 agent 指派 subagent 研究子問題，並將其發現合成為最終報告。Multi-pass 審查出現在合成階段：結構 pass（報告是否包含所有必要章節？）、事實 pass（主張是否有 subagent 發現支持？）以及連貫性 pass（合成是否流暢？）在報告回傳給使用者之前依序執行。關鍵 pass（例如事實查核）可能是 multi-instance ensemble。預期會有題目測試你是否能依依賴關係排列 pass 順序、在結構 pass 失敗時短路退出、只對關鍵 pass 做 ensemble，以及將分歧透過協調器的升級邏輯浮現出來。

FAQ — Multi-Instance 審查前五大問題

Multi-Instance 與 Multi-Pass 審查架構的差別是什麼？

Multi-instance 對相同輸入使用相同提示平行執行 N 個 Claude 呼叫，並透過投票、平均或 judge 聚合輸出。它的變化軸線是 Claude 本身的隨機性（跨 instance 的 temperature 變化）。Multi-pass 對相同輸出物使用不同提示循序執行 N 個 Claude 呼叫，每個 pass 套用更窄的審查視角（結構、內容、合規性）。它的變化軸線是審查角度。Multi-instance 降低單一判斷的變異數；multi-pass 將廣泛的判斷分解成更窄的子判斷。兩個族群是互補的——multi-pass 流水線可以對其關鍵 pass 做 ensemble——但它們解決的問題不同，且在考試上經常被混淆。

什麼時候應該使用 judge model 而非單純的 majority voting？

當審查任務真的比生成任務更容易時，使用 judge model——例如，檢查一份摘要草稿是否涵蓋七個必要要點，比撰寫摘要更容易。當任務本質上是分類（垃圾郵件／非垃圾郵件、十二個選項的類別），且任何單一 instance 都有合理的準確率時，使用單純的 majority voting。Judge 增加每次呼叫的成本（judge 呼叫本身也是一次 Claude 呼叫），且當兩者使用相同模型時，judge 與產生者共享相關性錯誤，因此它不是 voting 的萬能替代品。當相關性錯誤風險高時，使用不同模型的 judge 或人工審查者。

如何決定 multi-instance ensemble 要執行幾個 instance（N）？

選取奇數 N（3、5、7），使二元和少數類別問題不可能出現平局。對中等 confidence 的任務從 N = 3 開始，當單次呼叫遠低於門檻時擴大到 N = 5 或 N = 7。N 超過 7 之後，邊際品質提升急速下降，而成本持續線性增長。若下游決策的風險極高（醫療、法律、法規），考慮採用 N = 5 instance 在分歧時輸入給人工審查者的混合設計，而非一味提高 N。

Multi-Pass 的 Pass 應該平行還是循序執行？

每當後面的 pass 依賴前面 pass 的輸出時，循序執行——結構 pass 必須在內容 pass 之前，因為在結構無效的輸出物上做內容審查是浪費的工作。當 pass 真正獨立時，平行執行——對同一份文件的語法 pass 和邏輯 pass 不互相依賴，可以並行執行以縮短掛鐘延遲。將流水線建模為 DAG 而非嚴格的串鏈；DAG 同時捕捉了必要的循序依賴關係和安全的平行機會。

如何處理 multi-instance ensemble 內部的分歧？

依同意率定義升級門檻：全數同意自動接受，超過多數同意時附日誌接受，勉強多數時升級給人工審查者或更大的模型，沒有多數時永遠升級。不要靠取相對多數靜默解決分歧——這丟棄了 ensemble 產生的最有價值的訊號。記錄每份分歧軌跡（所有 instance 輸出、temperature 和 confidence 分數），讓提示或 schema 能隨時間改進。在 instance 有分歧時省略升級路徑的 CCA-F 情境答案，即便其餘的聚合邏輯正確，也通常是錯的。

延伸閱讀

• Claude 4 prompting best practices: https://docs.anthropic.com/en/docs/build-with-claude/prompt-engineering/claude-4-best-practices
• Chain complex prompts for stronger performance: https://docs.anthropic.com/en/docs/build-with-claude/prompt-engineering/chain-prompts
• Increase output consistency — structured outputs: https://docs.anthropic.com/en/docs/test-and-evaluate/strengthen-guardrails/increase-consistency
• Batch processing — Message Batches API: https://docs.anthropic.com/en/docs/build-with-claude/batch-processing
• Building effective agents — escalation and human-in-the-loop: https://docs.anthropic.com/en/docs/build-with-claude/agentic-loop

Related ExamHub topics: 驗證、重試與擷取品質的反饋迴路, 明確標準的提示設計, Few-Shot Prompting 與輸出一致性, 人工審查工作流程與 Confidence 校準.