FaithEyes 把工具服從訓練出來

以前是模型看起來很會用工具，現在是先把工具忠實度訓練進去，再讓它在視覺任務裡少亂猜。

我這陣子一直在弄 agent workflow，最煩的不是模型不會答，是它太愛自作主張。明明已經接了工具，結果它還是用嘴巴硬掰；明明該查圖、該算數、該驗證，它偏偏先講一個聽起來很順的答案。你一開始以為是推理壞掉，後來才發現根本是紀律壞掉。這種 bug 最討厭，因為它不會當場爆炸，只會慢慢把你的 pipeline 弄髒。

所以我看到這篇 Zhihu 整理 论文分享 | 智能体 最新进展，一路點到 FaithEyes GitHub，我就停下來看了。它講得很直白：用兩段式 SFT + RL，配合改過的開源資料，可以把視覺感知、推理和工具忠實度一起往上推。這句話我很買單，因為我現在最缺的不是會講話的模型，是會照規矩做事的模型。

FaithEyes 這個名字聽起來有點宗教味，但方法論其實很務實。它不是在賣神奇感，而是在處理一個老問題：工具不是裝上去就會用，得訓練成習慣。

把工具使用當成政策，不要當成 prompt 花招

Training via a two-stage SFT + RL pipeline on adapted open-source data, FaithEyes attains competitive or superior accuracy across visual perception and reasoning benchmarks, while markedly improving tool faithfulness.

翻譯一下就是：它不是只靠一句「請在需要時使用工具」來賭模型自律，而是把工具行為做成可學、可罰、可調的政策。先用 SFT 教它基本動作，再用 RL 把真正想要的行為推上去。這個順序很重要，因為工具使用本來就不是語言問題，是行為問題。

我以前也偷懶過。加個 tool schema、塞幾句 system prompt、再補一句「請謹慎使用工具」，看起來很完整，實際上常常只是把失控延後。簡單題它還會乖，題目一複雜就開始亂猜。最可怕的是它會把猜測包裝成自信答案，讓你以為它有查過。沒有，它只是很會演。

實操寫法很直接：你要把「何時叫工具、何時不要叫、叫完怎麼根據結果回答」都變成訓練目標。資料裡要有三種樣本：必須叫工具、明明不用叫工具、叫完之後要修正原本猜測。少了這三種，你就只是在訓練一個更會講漂亮話的模型。

• 把工具調用視為決策，不是語氣。
• 在資料裡明確標出「應呼叫」與「不應呼叫」的情境。
• 讓模型學會看完工具結果再回答，不要先下結論再硬拗。

SFT 先教動作，RL 再修掉投機

FaithEyes 的兩段式設計我覺得很對味，因為每一段在處理不同爛攤子。SFT 是模仿，先讓模型知道標準流程長什麼樣子；RL 是偏好塑形，逼它在壓力下也照這個流程走。這件事對 agent 特別重要，因為你真正要的不是「看起來像會用工具」，而是「在不確定時真的去用工具」。

工具忠實度其實有兩層。第一層是機械層：格式對不對、參數有沒有亂填、工具輸出有沒有被照抄錯。第二層是判斷層：該不該叫工具、叫了之後有沒有老實根據結果回答、能不能在證據不足時停下來。很多模型第一層還行，第二層一塌糊塗，因為它太習慣靠語感補洞。

我自己在測影像任務時就遇過這種狀況。SFT 完之後，乾淨題目它會照流程走；但一遇到模糊圖、遮擋圖、資訊不完整的圖，它就開始偷懶，直接用先驗知識補答案。RL 的價值就在這裡：你不是在抽象地獎勵「聰明」，你是在具體地懲罰「跳過工具還硬答」這種投機行為。

• 先用 SFT 教固定 trace：觀察、決策、呼叫、讀取、回答。
• 再用 RL 獎勵 grounded answer、正確 tool choice、以及不亂編工具結果。
• reward 別搞太花，太花模型就學會鑽洞。

如果你的 reward 只看最後答案準不準，模型很可能偷偷省略工具步驟。如果你的 reward 連忠實度一起看，才有機會把行為拉回來。這就是 FaithEyes 讓我覺得實用的地方：它不是在修辭上講 agent，而是在訓練上管 agent。

開源資料可以用，但要先洗成行為資料

原文提到它是用 adapted open-source data。這個 adapted 我看得很重，因為這三個字通常就是整個方案的命門。開源資料本身不會自動變成 agent 訓練資料。原始資料常常格式混亂、任務風格不一、答案品質參差不齊，你如果直接倒進去，模型學到的通常不是能力，是雜訊。

我理解這裡的做法，應該是把資料整理成符合目標行為的樣子。像是把平面的 QA 改成工具調用軌跡，把多模態樣本統一成同一種 trace，把不可靠的答案清掉，或把原本缺少步驟的樣本補成可學的決策序列。重點不是資料來源多漂亮，重點是資料能不能教出你要的政策。

我看過不少團隊把 data prep 當清潔工活，這真的很浪費。對 agent 來說，資料整理本身就是模型設計。你沒有把行為順序寫進樣本，模型就只能自己猜；你把順序寫得亂七八糟，模型就會很有效率地學會亂七八糟。這種效率很可怕，因為它看起來像進步。

• 每筆樣本統一成固定 trace 格式。
• 刪掉沒有觀察依據、卻硬給答案的樣本。
• 把感知、推理、工具使用三類資料分開配比，別讓其中一類壓死其他類。

如果你本來就有自己的工具集，資料轉換規則一定要寫清楚。工具名稱、參數欄位、輸出格式，最好都固定。資料愈乾淨，後面 RL 才不會變成在救火。

工具忠實度才是 agent 真正的 KPI

我很喜歡原文把 “tool faithfulness” 拉出來講，這才是該被盯著的指標。很多 demo 看起來很聰明，因為它會講一堆話；但真正上線之後，最要命的往往不是答錯，而是它答錯得很像真的。工具忠實度就是在防這件事。

什麼叫忠實？就是模型的最終回答要跟工具結果對得上。工具沒回那個數字，它不能自己補一個。工具明明已經給了證據，它不能裝作沒看到。工具告訴它 A，它不能最後寫成 B 再用一堆漂亮句子包裝。這些都不是小錯，這些是會把產品搞爛的錯。

我以前就被這種模型坑過。影像裡明明只有 3 個物件，它回我 4 個，還講得頭頭是道。你要是只看文字流暢度，會覺得它很會講；你要是看證據鏈，就會發現它根本沒在尊重事實。FaithEyes 值得看的地方，就是它把這件事當訓練目標，而不是事後審計。

• 把 tool call、tool output、final answer 分開記錄。
• 單獨評分 final answer 是否被 tool output 支撐。
• 加入拒絕猜測的負樣本，讓模型學會停手。

如果你做的是視覺助理，這點更重要。圖片最會騙人，因為人類自己也常常看錯。模型如果在不確定時願意說不知道，通常比硬猜一個看似合理的答案更有價值。

視覺感知和推理要分開施壓

原文還提到它在 visual perception 和 reasoning benchmark 上都有不錯表現。這句話我會解讀成：這套訓練不是只在某一種題型上刷分，而是有在照顧不同失敗模式。這很關鍵，因為感知錯和推理錯，根本不是同一種問題。

感知錯通常是細節漏掉、定位不準、讀圖不乾淨；推理錯通常是步驟串錯、證據拿錯、太相信腦內猜測。你只補其中一邊，另一邊還是會炸。很多 agent stack 的毛病就在這裡，它們把所有東西都叫 reasoning，然後期待一個模型全包。結果就是看起來什麼都會，實際上什麼都不穩。

實操上，我會把評估拆成幾個桶：感知、推理、工具選擇、工具忠實度、最後答案正確率。不要用一個總分把全部蓋掉。總分漂亮不代表系統可用，尤其是當某一桶已經爛到不行的時候。你如果沒拆開看，通常就是在自我安慰。

• 評估桶分開算，別只看 aggregate。
• 保留模糊圖、遮擋圖、干擾圖，測模型會不會偷猜。
• 把「需要再查一次」也當成可接受行為之一。

我很少講這麼直，但 agent 真的不能只靠單一分數活著。你要的是穩定，不是一次性的漂亮成績。

這套方法比一味追大模型更有用

我不是反對模型變大，變大通常是好事。但在 agent 場景裡，大不等於可靠。FaithEyes 讓我覺得實用，是因為它給了一條更可操作的路：先把行為訓練對，再談規模。對很多團隊來說，這比一直追 checkpoint 更實際，因為你真的能控制資料、控制 reward、控制行為定義。

而且產品角度也很現實。你如果有一個稍微沒那麼花俏、但很忠實的模型，通常比一個什麼都敢答的模型好救很多。你少寫很多補丁，少做很多後處理，少跟使用者解釋「它差一點就對了」。這些時間省下來，才是真的。

我自己的結論很簡單：如果你已經有夠用的 base model，下一輪迭代先別急著追更大。先把資料、訓練訊號、工具政策做紮實。很多 agent 的瓶頸不是智商，是它到底有沒有照證據做事。

FaithEyes 給我的啟發就是這樣：模型不只要會答，還要知道自己該從哪裡答。

可抄的模板

# FaithEyes-style tool-faithful vision agent template

## 目標
訓練一個視覺代理，做到：
- 證據不足時會叫工具
- 證據足夠時不亂叫工具
- 最終答案只根據觀察與工具輸出，不自己編

## Stage 1: SFT

### 統一資料格式
每筆樣本固定包含：
1. observation（圖像/文字/上下文）
2. instruction（使用者任務）
3. tool_policy（call_tool / no_tool）
4. tool_call（若需要）
5. tool_output（工具回傳）
6. final_answer（最後答案）

### 範例 schema
{
  "observation": "",
  "instruction": "",
  "tool_policy": "call_tool | no_tool",
  "tool_call": {
    "name": "",
    "arguments": {
      "...": "..."
    }
  },
  "tool_output": "",
  "final_answer": ""
}

### SFT 資料原則
- 加入必須用工具的正樣本
- 加入不需要工具的反例
- 加入「先猜錯、再根據工具修正」的樣本
- 全部樣本統一成同一種 trace
- 刪掉沒有證據卻硬答的資料

## Stage 2: RL

### reward components
- task_accuracy：答案是否正確
- tool_faithfulness：最後答案是否被工具輸出支撐
- tool_choice：是否正確決定要不要叫工具
- format_validity：工具呼叫格式是否正確

### reward sketch
reward =
  1.0 * task_accuracy +
  1.0 * tool_faithfulness +
  0.5 * tool_choice +
  0.2 * format_validity

### penalties
- hallucinated tool output
- unsupported numerical claims
- 該查卻不查
- 不該查卻亂查
- 工具結果和最終回答不一致

## Evaluation buckets
分開追蹤：
- visual perception
- visual reasoning
- tool selection accuracy
- tool faithfulness
- final answer accuracy

## Inference prompt
你是一個會用工具的視覺代理。

規則：
1. 如果觀察已足夠，直接回答。
2. 如果證據不足，呼叫適當工具。
3. 不要編造工具結果。
4. 最終回答只能根據觀察與工具輸出。

User task:
{{instruction}}

Observation:
{{observation}}

輸出：
- decision
- tool call（若需要）
- grounded final answer

## 上線前檢查
- [ ] 我有工具使用與不使用工具的樣本嗎？
- [ ] 我有把忠實度獨立評分嗎？
- [ ] 每個答案都能追到觀察或工具輸出嗎？
- [ ] 我有訓練模型拒絕亂猜嗎？
- [ ] 我有把感知與推理分開評估嗎？

如果是我自己要開工，我會直接拿這份骨架去改：換成我的工具、我的任務標籤、我的 reward 權重。這才是重點。很多人只複製架構，沒複製行為定義，最後訓練出來的東西看起來像 agent，實際上只是更會裝懂。

來源我點的是這篇 Zhihu 整理文，以及 FaithEyes GitHub repo。我這篇是根據公開整理和 repo 入口做的方法論拆解，模板是我自己整理後改寫的，不是原文逐字照搬。

如果你要追原始脈絡，也可以看 GitHub、Zhihu，再對照相關作者與專案頁面去補細節。