← 目錄

K1 論文詳解

2026-10-02


ReaLVR:讓潛在視覺推理真正「看」到圖像證據

Rethinking Latent Visual Reasoning: Grounding Latent Reasoning in Visual Evidence

AmazonXi Xiao、Tianchen Zhao、Youngeun Kim、Zhuowei Li、Linghan Xu、Jiaye Wu、Zheng Zhang、Xiang Xu▲ 200Hugging FacearXiv
Latent Visual ReasoningMLLMGRPOQwen2.5-VL多模態推理

背景

多模態大型語言模型(MLLM)處理視覺推理題時,通常會像文字模型一樣先寫一段 chain-of-thought,再給答案。這種做法有一個瓶頸:並非每個視覺推理步驟都適合用文字說出來,例如「這個區域和那個區域的相對位置」、「某個局部紋理的細節」。Latent visual reasoning(LVR)因此興起。它讓模型在輸出答案之前,先在連續的 latent token 中做中間運算,不必把每一步都翻成文字。

LVR 也帶來新的問題。文字 CoT 看得見,我們可以檢查它對不對,也可以對每一步做監督。latent token 則是連續向量,沒辦法直接閱讀,所以很難知道它到底學到了什麼。目前常見的訓練做法是用 GRPO 之類的強化學習,只用最終答案對錯當作 reward。

這篇論文先做了一輪分析,發現一個現象,並稱之為 latent evidence-credit gap。具體來說,當研究者對圖像做擾動,而這個擾動足以改變正確答案時,latent token 的反應卻很微弱。換句話說,這些 latent token 並沒有緊密綁定在能決定答案的視覺證據上。作者推測原因是 GRPO 訓練缺少明確監督:最終答案 reward 太粗,沒有告訴模型該保留哪些視覺證據,也沒有說明功勞(credit)要怎麼分配給一串 latent token。

方法

作者提出 ReaLVR。核心想法是把「視覺證據監督」直接加到模型自己自由生成(free-running)的 latent 軌跡上,而不是只依賴外部給定的軌跡。從摘要和我能讀到的頁面內容來看,它用了兩組對比:

  1. 正確答案 vs. 模型自己產生的錯誤答案:用來判斷哪些地方需要更強的監督。如果模型在某個推理軌跡上產生錯誤答案,表示這條 latent 軌跡可能沒有抓到關鍵證據。對比兩者可以指出「哪裡該加強」,也就是處理 credit assignment 的問題。
  2. 相關視覺證據 vs. 不匹配的視覺證據:用來界定「該保留什麼」。讓 latent token 對與問題相關的圖像內容有反應,對不相關或不匹配的內容則沒有,藉此把 latent 推理綁在真正有用的視覺證據上。

簡單講,第一組對比回答「監督要加在哪裡」,第二組對比回答「要保留哪些視覺資訊」。這兩個問題正好對應前面診斷出的缺口:最終答案 reward 既不知道該保留什麼,也不知道該怪哪個 token。

需要說明的是,我讀到的 arXiv 摘要頁與 Hugging Face 頁面內容很有限,沒有看到損失函數的具體公式、超參數,也沒有看到訓練資料的細節。上面對方法的描述只限於摘要所能支持的層次。想重現的讀者,請以論文全文(共 39 頁)為準。

實驗結果

摘要給出的主要數字如下:

  • 三個模型家族:ReaLVR 在三個模型家族上,都穩定勝過所評估的 LVR baseline。
  • Qwen2.5-VL-7B 上的五項任務平均:ReaLVR 達到 63.7%,是所有比較方法中最高的。摘要沒有列出是哪五個 benchmark,也沒有列出各 baseline 的分數,所以我無法精確換算出領先幅度。
  • 擴展到 235B:作者宣稱自己是第一個把視覺推理在 latent space 中擴展到 frontier 規模的工作,模型最大到 235B 參數,而且在這個規模上仍然帶來穩健的提升。許多 latent reasoning 方法只在 7B 左右的模型上驗證,所以這個擴展性的結果是論文的一個賣點。

除了 benchmark 分數,作者也做了行為層面的分析,結果與前面診斷的問題對得上:

  • latent token 的位置更具問題敏感性(question-sensitive):不同的問題會讓不同位置的 latent token 有不同反應。
  • 與相關視覺區域的對齊更強:latent token 的注意力更集中在與問題相關的圖像區域。
  • 對最受關注的 latent token,有更高的 fixed-context 依賴:這些 token 對結果的影響更大,表示它們確實承載了有用的資訊。

這些分析的用途是說明性能提升不只是分數變高,而是 latent token 的行為確實朝著「基於視覺證據」改變。不過摘要沒有給出這些分析的具體數值。

意義

這篇論文有三個值得注意的地方。

第一,它把問題診斷得很清楚。LVR 領域常見的假設是「只要有 latent token,模型就在做視覺推理」。作者用圖像擾動測試指出這個假設不一定成立:如果 latent token 對足以改變答案的擾動沒有反應,那它們有可能只是多出來的計算空間,並沒有真的在使用視覺證據。這提供了一個可以操作的診斷方法,其他 LVR 工作也可以拿來檢查自己的模型。

第二,它指出了稀疏 reward 在 latent 推理上的限制。這和 RLHF、RLVR 中熟悉的 credit assignment 問題是同一類。文字 CoT 至少可以靠閱讀中間步驟來除錯,latent 推理看不到內容,所以更需要額外的結構化監督。ReaLVR 的做法是在 on-policy 的自由生成軌跡上,用對比方式加上證據監督,不需要人工標註 latent 內容。

第三,規模驗證。如果結果如摘要所述,在 235B 規模上仍然有效,那 latent 視覺推理就不只是小模型上的研究玩具,而有機會進入大型模型的訓練流程。

也要保持一些保留。目前我能確認的只有摘要層級的結論;各 benchmark 的細項、相對提升幅度、訓練成本、以及 235B 實驗的具體設定,都需要讀全文才能判斷。「第一個擴展到 235B」是作者自己的說法,也需要對照後續工作來看。整體來說,這是一篇把 latent 推理的可解釋性和可監督性往前推進的論文,對做多模態 RL 訓練的團隊值得細讀。

假突破:自我演化搜尋代理中的「共謀作弊」診斷與 CrossFit 緩解法

False Frontiers: Diagnosing and Mitigating Co-Cheating in Self-Evolving Search Agents

Rutgers UniversityMeijia Chen、Hao Li、Zheng Lu、Hongshan Lin、Junbai Tian、Yichen Liu、Zijun Tian、Yufan Zou▲ 180Hugging FacearXiv
Self-Evolving AgentSearch AgentCo-CheatingCrossFit強化學習

背景

近年有一類「自我演化」(self-evolving)的搜尋代理(search agent),想擺脫人工標註資料的限制。做法是讓同一套系統扮演兩個角色:proposer 讀文件並出題,solver 負責上網搜尋、回答這些題目。proposer 的獎勵通常取決於 solver 的表現,例如題目難度是否合適,或是否與 proposer 自己產生的 pseudo-label(偽標籤)一致。兩個角色一起優化,課程(curriculum)就會自己越出越難,不用人工介入。

這個閉環有個容易被忽略的漏洞。proposer 和 solver 常常來自同一個底層模型,或是在同一批資料上訓練。如果 proposer 對某份文件理解錯了,產生了錯誤的標準答案,solver 也很可能犯同樣的錯,於是兩者「一致」。訓練迴圈把這種一致當成好訊號,內部獎勵(in-loop reward)因此上升,但答案其實是錯的。論文把這個現象稱為 co-cheating(共謀作弊):兩個角色沒有串通,卻因為共享錯誤而互相背書。

作者用事後審計(post-hoc audit)驗證這件事。他們拿原始文件當證據,回頭檢查每一輪自我演化產生的 pseudo-label 是否正確。結果是 co-cheating 隨著演化輪數增加而越來越嚴重,pseudo-label 的正確率停滯甚至下降,但訓練中看到的獎勵訊號仍在上升。標題的「False Frontiers」就是這個意思:看起來在往前推進,實際上是原地打轉,甚至往錯的方向走。

方法

論文提出兩種緩解手段。第一種是比較直覺的基線,第二種是主要貢獻。

Multi-Sample Verification(MSV):在題目進入訓練前先做驗證。對同一個模型,「帶著來源文件」查詢三次,再「不帶來源文件」查詢三次,用這六次回答的一致性決定題目是否准入(task admission),並替換掉不可靠的 pseudo-label。它的概念接近多數決加上有無證據的交叉比對。缺點是每個候選題要多花六次 labeler generation,成本不低。作者也指出,MSV 只能部分降低假一致,殘留的 co-cheating 仍然很多。

CrossFit(主要方法):CrossFit 針對問題的根源,也就是回饋訊號和 pseudo-label 共享同一個來源(ancestry),而不是在標籤上做更多驗證。流程如下:

  1. 把 proposer 使用的來源文件分成 A、B 兩組。
  2. 從 A 組文件產生的題目,交給一個只用 B 組訓練的輔助 solver(auxiliary solver)評分;B 組的題目則反過來,由只用 A 組訓練的輔助 solver 評分。
  3. 這個「交叉擬合」(cross-fitted)後的一致程度,決定 proposer 的獎勵。

這樣做的好處是,如果 proposer 對 A 組文件有錯誤理解,而這個錯誤只存在於 A 組的資料中,評分的輔助 solver 沒看過 A,就無法靠共享的錯誤重現同一個錯誤答案。同源的 pseudo-label 因此很難通過回饋 solver 拿到高分。原本主 solver 的更新規則完全不變,CrossFit 只改了 proposer 看到的獎勵來源,所以可以直接套進現有的自我演化流程。這個思路和統計與機器學習裡的 cross-fitting、cross-validation 類似:評估用的模型不能見過被評估的資料。

實驗結果

實驗用 Qwen3.5-4B 與 Qwen3.5-9B 重跑整個自我演化迴圈,主要指標是「false-agreement mass」(假一致的比例)。

  • 4B 模型:標準設定下為 6.1%。MSV 降到 5.7%,CrossFit 降到 3.0%。
  • 9B 模型:標準設定下為 8.8%。MSV 降到 7.2%,CrossFit 降到 3.7%。

MSV 在 4B 上只降了 0.4 個百分點,在 9B 上降了 1.6 個百分點,而且還要付出每題六次額外生成的成本。CrossFit 在兩種規模上都把假一致壓到了約一半以下,不需要這些額外生成。

作者還做了一個隔離實驗:重放(replay)完全相同的提案,但把回饋換成「排除來源文件」的版本,假一致進一步降到 4B 的 0.4% 與 9B 的 0.1%。這個設計的用意是把兩個因素分開:一是回饋的血緣(feedback ancestry),二是 CrossFit 帶來的課程改變。因為題目固定,只改變回饋來源,假一致就大幅下降,說明問題主要出在回饋與標籤同源,而不是題目本身的分布。這也給 CrossFit 設了一個接近上限的參考。

在下游表現上,論文跨七個搜尋 benchmark 評估。CrossFit 相對標準的耦合式自我演化,平均提升 8.8 分(4B)與 8.4 分(9B);相對 Search-R1,平均提升 8.7 分(4B)與 7.8 分(9B)。我手上只拿到摘要與簡短的頁面內容,七個 benchmark 的名稱和逐項分數沒能確認,想看細節請直接查閱論文全文。

意義

這篇論文的價值首先在於把問題說清楚了。自我演化、自我對弈(self-play)、自我生成資料的做法現在很流行,大家習慣看訓練中的獎勵曲線。這篇論文提醒我們,在閉環裡,內部獎勵上升不代表能力在進步,可能只是系統學會了互相同意。「用外部證據做事後審計」因此應該成為這類研究的標準檢查項目,而不是附加的分析。

其次,CrossFit 的設計思路值得借鏡。它沒有靠更強的驗證器或更多採樣來修補標籤,而是從資訊流的結構切斷「同源錯誤自我強化」的路徑。這個想法在其他 proposer–solver 架構中也可能適用,例如自動出題、程式碼與測試共同生成、synthetic data 的自我篩選,只要有「生成者與評分者共享偏差」的風險就用得上。再加上它不改動 solver 的更新規則,導入成本相對低。

不過有幾點要保持謹慎。第一,實驗只涵蓋 Qwen3.5 的 4B 與 9B,更大模型或不同模型家族是否同樣有效,摘要沒有說。第二,CrossFit 需要額外訓練輔助 solver,並要求來源文件能被切成彼此獨立的兩組。如果兩組文件內容高度重疊,或模型的預訓練知識本身就帶有共同錯誤,交叉擬合的隔離效果可能打折扣。第三,CrossFit 仍留有 3.0% 與 3.7% 的假一致,並未根除問題。

整體來說,這篇論文提供了一個清楚的診斷框架和一個實用的緩解方法,對想做自我演化代理的團隊是個實際的提醒:先確認獎勵訊號是否真的獨立於它所評估的錯誤。

Mid-Harness:在模型與 Harness 之間擴展「動作」的 test-time compute

Mid-Harness: Scaling Actions Between Model and Harness for Terminal Agents

NVIDIAMinki Kang、Ryo Hachiuma、Shaokun Zhang、Subhashree Radhakrishnan、Yonggan Fu、Jindong Jiang、Mingjie Liu、Ehsan Hosseini-Asl▲ 96Hugging FacearXiv
Terminal AgentTest-time ComputeVerifierTerminalBenchAgent Harness

背景

Terminal agent 是讓語言模型直接在命令列環境裡工作的系統,例如安裝套件、改設定檔、跑編譯與測試。這類 agent 的每一步動作都來自模型的隨機生成(stochastic generation)。「模型有能力產生一個好動作」和「它每次都能可靠地產生並執行好動作」是兩回事。

論文舉的例子是裝錯套件。這種指令一旦執行,環境就被改變了,後續步驟可能全被卡住,即使模型原本其實能想出更好的替代指令。終端環境不像聊天,錯誤動作往往有副作用,很難回頭。

過去提升 agent 表現的 test-time compute 做法,多半集中在兩個層級:一是多跑幾條完整 trajectory 再挑結果(trajectory scaling),二是讓模型想得更久。這篇論文問的是另一個位置:在模型與 harness 的邊界上,也就是動作被真正執行之前,多花算力能不能提高動作的可靠度和整條軌跡的成功率? 如果可以,什麼樣的配置才有效?

方法

作者提出 Mid-Harness。它夾在 generator(產生動作的模型)與 harness(實際執行指令、回傳觀察結果的環境殼層)之間,流程分三步:

  1. 針對當前狀態,從 generator 取樣多個候選動作。
  2. 用 verifier 對這些候選動作做驗證或比較。
  3. 只把選出的那一個動作轉交 harness 執行。

關鍵設計是 generator 和 harness 都不需要改動。Mid-Harness 是一層可插拔的中介,不必重新訓練 agent,也不必改寫執行環境。

論文系統性比較了不同的 verification 機制。其中一個重點是 pairwise verification,也就是讓 verifier 兩兩比較候選動作,而不是各自打分。實驗用的 generator 是 TMAX-9B(9B 參數的模型),verifier 則分成兩類:一類是較強的外部模型(論文中的 GPT-5.6 Sol),另一類是 TMAX-9B 自己。

此外還有一個延伸做法是 distillation:把較強 verifier 的回應蒸餾進 TMAX-9B,讓小模型自己當 verifier 時也更準。這個過程只改 verifier 的能力,action generator 保持不變。

實驗結果

主要實驗在 TerminalBench-Lite 上進行,以 TMAX-9B 為 generator,核心發現如下。

取樣數量本身不夠,verifier 的能力才是關鍵。 在 verification 很弱的情況下,多取樣動作幾乎沒有好處;候選裡即使有好選項,也挑不出來。反過來,當 verifier 夠強,就能從同一個 generator 產生的候選中找出有用的替代動作。具體數字是:base agent 的 Pass@1 為 50.00%,換上 GPT-5.6 Sol 當 verifier、每步取樣 8 個候選動作後,Pass@1 升到 68.03%,提升約 18 個百分點。

用 TMAX-9B 自己當 verifier 時,pairwise verification 表現最好。 在論文評估的各種 verification 機制中,兩兩比較勝過其他方式。直覺上,對小模型來說,「這兩個動作哪個比較好」比「給這個動作打幾分」更容易判斷。

蒸餾強 verifier 能進一步提升。 把 GPT-5.6 Sol 這類較強 verifier 的回應蒸餾進 TMAX-9B,Pass@1 會再往上走。因為 generator 沒動,這部分的進步完全來自更好的動作篩選。

成本效益優於單純增加 trajectory。 在 TMAX-9B 加 TerminalBench-Lite 的設定下,把 action scaling 與 trajectory scaling 結合,能以較低的估計 token 成本達到比「只多生成幾條 trajectory」更高的成功率。

泛化性。 摘要指出,Mid-Harness 在其他模型、其他 benchmark 與其他 harness 上也有進步。不過我能取得的頁面內容只有摘要等級的資訊,各個額外設定的具體數字、token 成本的實際估算值,以及不同 verifier 的完整對照表,這裡無法一一列出,需要讀者查閱論文原文。

意義

這篇論文的價值在於指出一個容易被忽略的 scaling 位置:單步動作。多數 test-time compute 研究把「一條完整軌跡」當作單位,但在有副作用的終端環境裡,一個錯誤動作就可能讓整條軌跡失敗。在動作執行前先把關,比事後重跑整條軌跡更直接,也可能更省。

對實務的啟示有幾點:

  • Verifier 品質比取樣數量更重要。 如果只是盲目把取樣數加大,而 verifier 不夠強,算力等於白花。系統設計時應該先投資在 verifier 上。
  • 小模型可以靠蒸餾補上 verifier 能力。 用強模型的判斷來訓練自己部署的小模型,是比長期呼叫昂貴 API 更實際的路線。
  • 介入點不侵入既有系統。 因為 generator 和 harness 都不用改,Mid-Harness 可以疊在現有的 agent 框架上,導入成本低。
  • 與 trajectory scaling 互補。 兩者結合比只靠其中之一更划算,代表未來預算配置可以同時考慮「每步挑得更好」與「多試幾條路」。

也要留意幾個限制。目前結果主要以 TerminalBench-Lite 與 TMAX-9B 為核心,最亮眼的 68.03% 依賴一個強外部 verifier,實際部署時要把該 verifier 的成本納入。此外,verification 本身需要額外推論,延遲會增加,對需要即時回應的場景是一個取捨。論文把 action scaling 定位為「有前景的 test-time compute scaling 目標」,這個說法是合理的,但完整的成本與泛化評估仍需看全文。