Writer 換模型實驗

1緣由

Langfuse 使用者回饋（score user-thumbs，production，2026-08-01 起，資料至 10-16）共 178 筆：130 讚、46 倒讚、2 筆為 0。

我們對約 33 個倒讚 trace 做了根因分析，逐一追查最終草稿引用的每個網址來自哪裡。34 份最終草稿全部把每個主張設成 verifier_confirmed=true。其中 21 份至少引用一個 verifier 沒讀過的網址，13 份引用了任何工具輸出都沒有出現過的網址，共 23 個，全是模型自己做出來的。

draft_factcheck_response 的 claim_sources 檢查（adk/cofacts_ai/tools.py 第 542 行）只看 writer 自己填的 verifier_confirmed 布林值。A、B、C、E 很多是 writer 判斷或遵守指令的問題，所以我們的假設是：Claude 比較會照指示做，也比較會判斷子代理的輸出。這個實驗就是在檢驗這個假設。

2實驗方式

1. 選決策點。案例組合是 7 個失敗案例加 9 個對照組。失敗案例 w01–w07 是正式環境在該步驟出錯的 writer 決策點；對照組是使用者按讚的決策點。案例清單在 exp/cases/index.md，每個案例的評分筆記在 exp/grader/<id>/notes.md。
2. 挑選 c03–c09。c01、c02 是最早挑的兩個對照組。c03–c09 取自 8 到 10 月使用者按讚的 session。我們篩了約 25 份候選草稿，對每份做客觀檢查：每個網址都出現在先前的工具輸出、使用者訊息或 Cofacts 資料裡；每個 verifier_confirmed 主張都有 verifier 對該網址的 ✓；沒有把 ✗ 的主張改標；沒有編造數字；引用的網址都做過 HTTP 檢查。約 15 份沒通過而淘汰。入選的 7 個包含 4 個起草決策點，以及 3 個非起草決策點（處理 verifier 的 ✗、組 verifier 請求、處理子代理錯誤）。每個案例來自不同 session，也不和 w01–w07、c01、c02 共用 session。
3. 重建 writer 當時的輸入。從 Langfuse 還原 writer 在決策點收到的完整輸入：system prompt、10 個工具宣告、整段對話（含工具結果）。10 個案例是逐字紀錄；6 個從最後一次有紀錄的輸入開始，依 ADK 自己的 history 規則往後重建。這套規則在 165 個有紀錄的輸入中重現了 164 個；c05 跨 3 個 trace 重建，較早的紀錄輸入全部吻合。Gemini 的 thinking 段落省略。
4. 重播給 Claude。透過 Claude Code 子代理交給 Claude Haiku 與 Claude Sonnet（alias「haiku」「sonnet」）。API 錯誤訊息確認 Sonnet 是 claude-sonnet-5-5；Haiku 推定為 5.5。Claude 看不到圖片，只拿到佔位文字與 OCR；Gemini 當時在 9 個案例中看得到圖片。
5. 處理 Sonnet 的分類器。Sonnet 5.5 的安全分類器（reasoning_extraction）擋下 5 個案例（w01、w02、w04、c01、c02，重試也被擋），並在 w07 回合中途切斷。去掉「[thinking omitted]」標記、改寫重播說明之後（資訊不變，檔案為 exp/cases/<id>/prompt_s.md），6 個都跑完。Haiku 沒有遇到這個問題。c03–c09 只有這種去掉 thinking 標記的版本，Haiku 與 Sonnet 都跑這份。
6. 盲評。每個案例由一位 Claude Opus 評審處理。評審拿到打亂成 A/B/C 的三份輸出（Gemini 實際輸出、Haiku、Sonnet）、完整 prompt，以及 grader notes 當答案。5 項標準各給 1–5 分，再排出名次。w01–w07、c01、c02 的 notes 描述了 Gemini 當時的做法，所以這 9 個案例的 Gemini 輸出不算真正盲評。c03–c09 的 notes 只寫正確做法的標準，從不描述正式環境的輸出，所以這 7 個案例對 Gemini 也是真正的盲評。
7. 第二位評審。使用者另外在 gemini.google.com 用 Google Gemini（模型選單顯示「Argon」）評同一批材料。評分標準、指示與 A/B/C 字母都和 Claude Opus 評審相同。不同的是，Gemini 評審在同一段對話中評完全部 23 個項目（含 proofreader 實驗的項目），材料是一個 zip 檔一次上傳；Claude Opus 評審則是每個 writer 案例各用一個子代理。結果存在 gemini_judge_results.jsonl。
8. 解盲。用 exp/keys/writer_key.json 把兩位評審的 A/B/C 對回模型。

3結果

名次以各評審的 RANKING 為準，不一定和總分順序相同。Claude Opus 評審：c01 中 Haiku 總分 25、Sonnet 24，判定兩者並列第一；c03 中 Sonnet 與 Haiku 都是 24 分，因為 Sonnet 對證據的檢視較細而排它第一；c05 中把 Gemini（17 分）排在 Haiku（19 分）前面，因為 Gemini 交出了使用者要求的新版草稿，Haiku 只做了沒說明理由的重查。Gemini 評審：w01 中 Sonnet 與 Haiku 都是 25 分，排 Sonnet 第一；c03 中 Haiku 與 Sonnet 都是 25 分，排 Haiku 第一；c04 中 Gemini 與 Haiku 都是 22 分，排 Gemini 第二。c02 與 w05 來自同一個 session，彙總時不算獨立。

雙評審對照

兩位評審拿到相同的材料與指示，A/B/C 字母也相同。Claude Opus 評審每個案例各自獨立評分；Gemini 評審在同一段對話評完所有項目。

• 16 個案例中有 10 個排名完全相同：7 個失敗案例全部相同，對照組 c01 也相同。
• 不同的 6 個都是對照組：c02–c06 與 c09（上表有底色的列）。Gemini 評審在 c02、c03 把 Haiku 排第一，在 c05 把 Gemini 排第一，在 c09 讓 Gemini 與 Sonnet 並列第一，在 c04 把 Gemini 排在 Haiku 前面，在 c06 讓兩者並列第二。
• 第一名次數（含並列）：Gemini 評審是 Sonnet 12、Haiku 4、Gemini 2；Claude Opus 評審是 Sonnet 15、Haiku 2、Gemini 0。
• 對照組平均總分（Gemini／Haiku／Sonnet）：Gemini 評審 21.0／22.6／24.3；Claude Opus 評審 16.3／21.0／23.9。失敗案例平均：Gemini 評審 9.9／22.7／24.4；Claude Opus 評審 8.9／20.6／23.3。

怎麼解讀

• 兩位評審都認為 Claude 在失敗案例避開了當時的錯誤，也都認為 Sonnet 整體最好。這兩點不受評審影響。
• 在一般案例（對照組），Sonnet 領先 Gemini 多少要看評審：Claude Opus 評審的平均差 7.6 分，Gemini 評審差 3.3 分。Haiku 是否勝過 Gemini 也要看評審：Claude Opus 評審在 9 個對照組有 7 個把 Haiku 排在 Gemini 前面；Gemini 評審是 5 個，另有 3 個把 Gemini 排在前面、1 個並列。
• 每位評審都可能偏好自己家族的模型。Gemini 評審整體給分較高，加分最多的是 Gemini：對照組平均比 Claude Opus 評審高 4.7 分，Haiku 高 1.6 分，Sonnet 高 0.4 分。這次的資料分不出這是偏好，還是兩位評審的尺度不同。
• Gemini 評審在同一段對話評完全部 23 個項目，前面的案例可能影響後面的評分。Claude Opus 評審每個案例各用一個子代理，沒有這個問題。

4所有例子

每個案例依序列出：背景、使用者在決策點之前的最後一則訊息、正確做法、三個模型的輸出，以及兩位評審的分數與評語。輸出逐字保留；函式呼叫以參數清單呈現，字串參數中的 \n 顯示為換行，格式標籤（Text:、Function call:）與「[thinking omitted]」已移除。Claude Opus 評審的評語是評審報告的中文翻譯；Gemini 評審的評語原本就是中文，逐字保留。完整 prompt 太大（最大約 80 萬字元），沒有放進頁面。

5評估與建議

• 依 Claude Opus 評審，16 個案例中，Sonnet 有 15 個排第一（含 c01 與 Haiku 並列），只有 w05 排第二。Haiku 排第一 2 次（w05，以及 c01 並列）。Gemini 在 14 個案例排最後，在 c05、c06 排第二。只看 9 個對照組，Sonnet 9 個都排第一，Gemini 7 個排最後。
• 第二位評審 Gemini（Argon）支持兩個結論：Claude 不會重犯失敗案例的錯，Sonnet 整體最好。在一般案例中 Sonnet 領先 Gemini 多少、Haiku 是否勝過 Gemini，則要看評審是誰（見雙評審對照）。
• 在 7 個失敗案例中，Sonnet 與 Haiku 都沒有重犯當時的錯：沒有編網址，沒有把 ✗ 換個網址標成已確認，verifier 失敗時會先告訴使用者。唯一部分重犯的是 w06，兩者都沒有完全排除一起轉傳的訊息。w04 中 Haiku 沒注意到原文網址缺失，但也沒有編造。
• 在最早挑的兩個對照組，Gemini 的錯誤比較重：c01 它寫原訊息宣稱「排名第 13」，但原訊息沒有這樣說；c02 它把兩個未驗證的主張標成已確認。
• 在真正盲評的對照組 c03–c09，Gemini 的典型弱點比失敗案例輕微：沒有給使用者任何文字（c03、c07）；把只有部分 ✓ 的數字寫成已確認（c08 的「行銷預算超過3億」）；在已確認的來源底下夾帶沒有支持的主張（c04、c09）。這 7 個案例它都沒有編造網址。
• Haiku 在 16 個案例中有 4 個給使用者的文字全是英文（w03、w07、c04、c06），c06 還有一個無法解析的函式呼叫 JSON。如果改用 Haiku，system prompt 需要明確的語言指示；整體來說它比 Sonnet 不可靠。
• Sonnet 沒有語言問題。Claude Opus 評審指出的弱點多半是小問題，例如給使用者的文字偏長、w04 在給 investigator 的提示中寫了錯的頂級網域、c09 在已確認的主張裡加了一個沒驗證的細節（「在北京」）。c05 它暫緩了使用者要的新版草稿，Claude Opus 評審仍因為它找出的證據缺口排它第一。

成本估算

依 Langfuse 30 天實際 token 推算：writer 780 次呼叫、125 個回合。範圍取決於 Claude 對中文的 token 倍率（1.0–1.6 倍，未實測）。Sonnet 的數字假設有 prompt caching。Vertex 上的 Claude 價格可能和官方價不同。

ADK 1.26 的 Claude adapter 目前不設 cache_control、不串流、不吃 thinking 設定，遇到 gs:// 圖片會丟出 NotImplementedError。上線前要先處理這幾點，否則上面的 caching 估算不成立，圖片訊息也跑不動。

風險

Sonnet 5.5 的分類器在這次實驗的包裝下大量誤擋（6 個案例需要改寫重播說明；c03–c09 一開始就用改寫版，沒有測原版）。上線前要在真實的 writer 流量上確認是否會被擋。Vertex 沒有伺服器端 fallback，需要在客戶端做 fallback。

建議

• writer 換 Sonnet 值得做正式 A/B：用 cofacts/ai#143 的評測，跑完整流程，而不只是單一決策點。評分也要用不同家族的評審或加上人工抽查，因為兩位評審在一般案例的差距判斷不一致。
• cofacts/ai#144（出處必須可追溯到工具輸出）與 #118 仍然要做。模型變好只會降低錯誤的頻率，沒辦法讓錯誤不可能發生。

6限制

• 選樣偏差已經降低，但還在：16 個案例中有 7 個是特地挑 Gemini 出錯的決策點，9 個是對照組。c03–c09 只留下通過出處檢查的按讚輸出，這對 Gemini 有利。整體名次仍不能直接當成正式環境的勝率。
• 盲評只有部分成立：w01–w07、c01、c02 的 grader notes 描述了 Gemini 當時的做法，評審可能認得出來。c03–c09 的 7 個案例是真正的盲評。
• 只測單一決策步驟，沒有跑完整流程。Claude 下一步拿到子代理結果後會怎麼做，這次看不到。
• 每個案例只跑一次，沒有重複取樣。
• Claude 看不到圖片，只有佔位文字與 OCR；Gemini 當時看得到圖片。
• 執行環境是 Claude Code 子代理，不是正式環境的 API 呼叫，system prompt 與工具的包裝方式不同。
• 評審用了兩個不同家族的模型：Claude Opus 與 Gemini（Argon）。兩者在 7 個失敗案例與 c01 的排名完全相同，在 6 個對照組（c02–c06、c09）不同。每位評審都可能偏好自己家族的模型，而 Gemini 評審在同一段對話評完所有項目，案例之間可能互相影響。兩位都是模型，沒有人工評分。