你用 Claude 的一步一步解釋去微調一個小模型。它在你評估集上產出的推理理由看起來很讚——條理清楚、結構完整，有時甚至難以跟老師區分。你把它出貨。六週後，有人跑了一次擾動測試（perturbation study），發現推理理由的文字內容跟最後的答案之間，實質上是不相關的。這個模型會講話。它只是沒有在把想法講出來而已。
這就是推理理由忠實度問題（rationale faithfulness），也是近期可解釋性研究裡讓人比較不舒服的發現之一。如果你正從一個 Claude 工作流程做蒸餾——尤其是老師的思路鏈本身就是訓練訊號的一部分——你需要一套能用的心智模型來看待這件事。否則你會朝錯誤的方向最佳化，最後被下游的無聲失敗嚇到。
忠實度到底是什麼意思
「忠實度」是那種聽起來很直覺、直到你要精確定義時才發現不好講的詞。在解釋品質相關的文獻裡，它有個很具體的意思：一段解釋是「忠實」的，當它準確反映模型實際用來產生輸出的推理過程。這跟「聽起來合理」、「內容正確」、或「對人類讀者有幫助」不是同一回事。
Wiegreffe 與 Marasovic 在 NLP 解釋評估方面的綜述，把這個區分講得很清楚。他們把 合理性（plausibility）（這段解釋看起來對人類有沒有說服力？）跟 忠實度（faithfulness）（這段解釋有沒有描述模型真正的運算？）分開。合理性是「讀者」的屬性，忠實度是「模型」的屬性。一段推理理由可以極度合理、卻完全不忠實，而這兩種失敗模式若不刻意檢測，是很難分辨的。
對蒸餾模型來說，這個分裂特別痛。你的訓練損失獎勵的是「看起來合理」的輸出，因為那就是老師產出的樣子。標準的監督式目標裡，沒有任何東西會強迫學生「陳述出來的推理」與它「內部真正用到的特徵」對應起來。你最後拿到的是一個被訓練得「很會寫可信解釋」的系統，而不必然是一個「會解釋自己」的系統。
Anthropic 的 Lanham 等人直接針對思路鏈推理探討過這件事。他們關於「衡量 CoT 忠實度」的研究顯示：在某些情境下，模型即使思路鏈被截斷、被改寫、甚至被主動破壞，最終仍會得到同樣的答案。這是個強烈訊號，代表推理理由裡的文字並沒有真正在承擔任何工作。在另一些情境下，CoT 確實有作用——修改推理軌跡會讓答案跟著變。令人挫折的是，你光看推理理由的文字，根本看不出來自己身處哪一種情境。
Turpin 等人從另一個角度切入。他們證明了：偏誤特徵（例如選擇題裡正確答案的位置、或是某些細微的脈絡線索）能改變模型的最終預測，卻從來不會出現在推理理由裡。模型會產出一段聽起來像是在談問題內容的論述，但實際驅動答案的是那段推理理由完全沒承認的特徵。這是最嚴重形式的「不忠實」：解釋不只是不完整，還會主動誤導你關於因果結構的認知。
這類失敗要怎麼被抓出來
沒有一個能給你乾淨「通過／不通過」結果的忠實度測試。你手上真正有的，是一整族基於擾動的探針，每一種抓的是不同的失敗模式。如果你認真想出貨一個蒸餾模型，至少要跑其中的兩三種。
擾動推理理由本身。 在推理理由已經生成、但最終答案還沒產出之前，去改動它。如果答案沒變，那推理理由就沒在做什麼有意義的事。常見手法：把 CoT 從中間截斷、改寫、插入一個錯誤、或者換成另一題的推理理由。比較擾動前後的答案分佈。如果一致率很高，代表模型把推理理由當裝飾品。
反事實輸入。 改動輸入裡的某個元素——如果模型的陳述推理是忠實的，這個改動應該會讓答案跟著變。如果模型的推理理由說「我選 B 是因為它提到了 X」，你就把輸入改成 X 現在出現在選項 A 裡。一個忠實的推理者現在應該偏好 A。一個不忠實的推理者則會繼續說「因為 X」，卻依然選 B。這比較接近 Turpin 團隊的手法：刻意建構那些「陳述理由」跟「真實驅動因素」分道揚鑣的輸入。
偏誤探針。 引入一個模型不該依賴的假特徵——位置、格式、名字、或一個干擾用的句子。量測最終答案偏移了多少，再檢查推理理由有沒有提到這個假特徵。悄悄的偏移就是破綻。
改寫下的一致性。 用不同方式問同一個問題，然後檢視推理理由彼此之間、以及和答案之間是否一致。蒸餾模型在這裡常常出乎意料地脆弱：語意內容完全相同，推理理由卻天差地遠，有時候答案也不一樣。
這些檢測方式都不完美。擾動可能會把模型推到分佈之外，混淆訊號。反事實測試建置成本高。偏誤探針需要你先假設哪些假特徵可能重要。但把它們合起來用，你對忠實度的掌握，會遠比「隨手讀幾段推理理由然後說 OK」清楚很多。
為什麼從解釋出發的聚焦式蒸餾會放大這個風險
從解釋出發的聚焦式蒸餾——如果你有跟到現在流行的縮寫，就是 FDE——是一種訓練配方：學生從一份精選的老師輸出資料學習，這些資料把答案和推理軌跡配成對。這種做法很適合 Claude 工作流程：你用一個強力老師產出高品質推理，篩掉推理不連貫的樣本，然後訓練一個較小的模型同時複現答案與軌跡。
這樣做有效。用這種方式訓練的學生，在下游任務上通常會比只用答案訓練的學生表現更好。推理軌跡提供了密集的監督訊號，精挑細選的資料集又濾掉了雜訊。到這裡都很好。
問題在於，訓練目標無法區分兩件事：「學生正在學著像老師一樣推理」與「學生學會了聽起來像老師的推理，實際上卻在做別的事」。這兩個目標都會讓「讀起來很順」的推理理由拿到低損失。但只有其中一個會產出一個「推理理由真的在承擔工作」的學生。
FDE 有幾個特點，讓這個問題特別嚴重：
-
用推理理由品質篩選，等同於在挑合理性。 當你透過人工閱讀或用 LLM 當評審來篩訓練資料，你直接在最佳化「聽起來合理的軌跡」。而這正是合理性與忠實度分道揚鑣的那條軸。你等於是在把學生往那個失敗模式推。
-
學生的容量比老師小。 蒸餾本質上是壓縮。老師內部做的事情，有一部分沒辦法在學生上被緊緻地表示出來。學生必須在某處妥協。推理軌跡剛好是比較容易被犧牲的東西之一，因為訓練訊號並不會懲罰「合理但脫勾」的軌跡。
-
評估通常只看到答案準確率為止。 大多數 FDE 流程只用任務指標評估學生。如果學生的答案分佈在評估集上跟老師吻合，這個配方就被宣告成功。你從來沒去看推理理由到底有沒有在做工，因為流程裡沒有任何一步在問這件事。
結果就是產出一整類的蒸餾模型：它們在基準上表現亮眼、產出流利的解釋，卻悄悄依賴那些推理理由從未提及的特徵。對很多應用來說這沒關係。但對「推理理由會直接面對使用者、需要接受稽核、或被下游系統當輸入」的應用來說，這是嚴重的問題。
三個實務緩解手段，給正在用 Claude 工作流程出貨蒸餾模型的團隊
以目前的技術，你沒辦法徹底解決推理理由忠實度問題。但你絕對可以降低暴露程度。以下三件事值得投入工程時間：
1. 在蒸餾流程裡加一項忠實度評估
不管你目前是用什麼在評估學生的任務表現，就在旁邊多加至少一個「基於擾動」的忠實度探針。最簡單的版本：對隨機抽出的評估樣本，先讓學生產生推理理由；然後把推理理由截斷到原本的 50% 長度，再讓它產生第二個答案。量測前後一致率。如果推理理由砍一半，學生跟自己還是超過 90% 一致，那在那批資料上，推理理由就沒真的在做事。
這個訊號很粗，但便宜、又能抓到最糟糕的退步。長期追蹤這個指標。如果你重新訓練學生，任務準確率沒變，但忠實度數字掉了，那就是一個警訊：新版本正在拿推理能力去換表面形式。
如果預算多一點，就在一組你「事先知道哪些特徵該驅動答案」的手工樣本上跑反事實探針。把學生答案的偏移跟老師的比一比。差異就是診斷訊息。
2. 把 Claude 當稽核層，不只是訓練老師
大多數 FDE 流程只讓 Claude 扮演一個角色：產生訓練資料。還有另一個同樣有價值的角色：在評估時、或是在生產環境裡，稽核學生的推理理由。
具體做法：抽一部分學生輸出送回 Claude，用一段 prompt 請它比對「學生的推理理由」與「學生的答案」，並標記不一致之處。Claude 很擅長這種結構化的批判，尤其當你把輸入、陳述的推理理由、最終答案，當作三個獨立欄位餵給它的時候。它不會抓到每一段不忠實的軌跡，但顯而易見的那些會被抓到——推理理由跟答案自相矛盾、推理理由引用了輸入裡沒有的資訊、推理理由跳過了真正的決策點。
把這一步接進你的 CI，或是抽樣的生產影子評估裡。用一份 ClaudeMd 風格的規格檔管理稽核 prompt，讓它可重現、可版本化。你就有了一個持續在跑的推理品質量測，而不只是「這段讀起來順不順」。
3. 讓你的產品介面設計讓推理理由變成「可選」或「可驗證」
最穩健的緩解方式是架構層的：不要把「未經驗證的學生推理理由」直接擺在使用者或下游系統面前，好像它是一段可靠的解釋。如果推理理由要面向使用者，明確標示為「模型陳述的推理」，而不是「答案的原因」。如果它是另一個自動化步驟的輸入，就在中間加一道驗證：檢查推理理由與答案是否一致，通過才動作。
在高風險情境下，考慮讓最終答案再過一層獨立的推理檢查——可以是一次 Claude 呼叫，也可以是一個「專門訓練來抓不忠實軌跡」的小型驗證器。這會增加延遲和成本。但它把「無聲失敗」轉成「有聲失敗」——對任何真的重要的東西，這幾乎永遠是划算的交換。
結語
不太舒服的事實是：目前的蒸餾配方，最佳化的是「讓推理理由看起來對」，而不是「讓推理理由對地描述模型自己的運算」。這不是任一次訓練跑的 bug，而是「損失函數獎勵什麼、人工挑選在挑什麼」自然導出來的結果。Wiegreffe 與 Marasovic 的架構、Lanham 等人的 CoT 實驗、Turpin 等人關於偏誤的研究，都從不同的角度指出同一個形狀的失敗：合理性容易做到，忠實度很難，而它們之間的落差正是事情出錯的地方。
如果你正在 Claude 工作流程之上打造產品——產生訓練資料、蒸餾出比較小的模型、把它推進產品——那就預設學生的推理理由「不忠實」，然後把你的評估和產品介面設計成「即使這個預設成立，也能安全出貨」。這比「相信推理理由文字、之後被結果嚇到」健康得多。
想瞭解訓練時應對這件事的做法，可看 從解釋出發的聚焦式蒸餾對開發者的意義。想把 Claude 工作流程圍繞規格檔和稽核來組織、讓忠實度檢查可重現，可以看 Claude Code CLAUDE.md 完整指南。