K1 論文詳解

背景

近年來,強化學習(RL)已成為大型語言模型(LLM)後訓練階段不可或缺的一環,尤其在數學推理、程式生成等任務上效果顯著。但業界普遍觀察到一個棘手現象:RL 訓練常常不穩定,甚至會突然崩潰(collapse)。這篇論文指出了背後一個容易被忽略的關鍵原因——「訓練推論不一致」(training-inference mismatch)。

現代 LLM RL 系統為了兼顧生成效率與訓練精度,通常會採用兩套不同的引擎:一套是負責採樣(rollout)的推論引擎(inference engine),另一套是負責梯度更新的訓練引擎(training engine)。這兩套引擎即便同步了完全相同的模型參數,由於底層實作(如 kernel、數值精度、batching 方式)的差異,對同一段生成軌跡(trajectory)算出來的機率仍會不同。這種差異天然引入了一種特殊的「離策略」(off-policyness)問題,持續污染訓練訊號。

過去的研究(例如 truncated importance sampling、token filtering、learning-rate decay 等方法)大多把這個問題當作「系統層級的數值誤差」來處理,想辦法縮小兩邊機率的差距。但本論文作者提出一個更根本的質疑:即使訓練引擎裡的政策確實被有效更新、變得更好,這並不保證同步到推論引擎、真正部署上線的那個政策也會變好。換句話說,大家一直在優化的「訓練政策」,可能只是一個假象(mirage),真正該關心的目標其實是「推論政策」的單調改善。

方法

作者提出一個新的優化目標,稱為 Monotonic Inference Policy Improvement(MIPI),核心原則是:RL 更新的目標不應只是讓訓練引擎裡的政策 π 變好,而應確保實際部署使用的推論政策 μ 也單調改善。

為了落地這個原則,論文提出兩步驟框架 Monotonic Inference Policy Update(MIPU):

第一步:Sampler-Referenced 候選更新。 不同於傳統做法直接對「訓練端對採樣端」的完整機率比值做 clipping(這樣容易過度限制更新幅度),MIPU 將這個比值拆解,只對「當前訓練端的更新量」做 clipping,同時另外控制「更新前的既有不一致權重」,藉此構造出候選的參數更新。

第二步:推論端差距感知的接受機制(Inference-Gap-Aware Acceptance)。 候選更新產生後,先同步到推論引擎,再用少量驗證性 rollout 估計一個「同步後差距」的代理指標(記為 T̂_post)。如果這個指標低於一個動態容忍閾值 −c,代表這次同步後推論政策很可能比訓練政策表現更差,系統就會拒絕接受這次更新,回退到前一版本;反之才真正生效。

論文用一個公式(文中的 Equation 5)把整體改善拆成三項:訓練端本身的改善量、同步前既有的機率差距、以及同步後新產生的差距,分別對應到「哪裡出了問題就在哪裡修」的設計思路,而不是籠統地去壓低所有機率差異。

實驗結果

實驗在兩個模型規模上進行:Qwen3-1.7B 與 Qwen3-4B,訓練資料分別使用 DAPO-Math-17K 與 DeepMath-103K(並過濾掉過於簡單或過難的題目)。為了製造「高不一致」場景,作者刻意採用 FP8 量化的 rollout 推論引擎,放大訓練與推論兩端的機率差距。評測基準涵蓋 MATH-500、AIME24、AMC23、Minerva、OlympiadBench 五個數學推理任務,對照組包括標準 GRPO、MIS(token filtering)與 learning-rate decay 等方法。

結果顯示,MIPU 在兩個規模上都取得最佳平均表現且訓練更穩定:

• Qwen3-4B:MIPU 平均準確率達 66.71%,在 AMC23 上達 85.00%、Minerva 達 45.96%,而多個對照組出現明顯的性能崩潰或大幅退化。
• Qwen3-1.7B:MIPU 平均準確率 53.97%,MATH-500 上達 86.52%、OlympiadBench 達 59.52%。

消融實驗進一步證實兩步驟缺一不可:只用第一步(候選更新構造)能提升候選品質,但缺乏不一致感知的過濾機制;只用第二步(拒絕機制)能避免崩潰,卻無法彌補本身品質不佳的候選更新。兩者結合才能同時兼顧性能與穩定性。另外一項有趣的對照實驗顯示,即便隨機拒絕 70% 的更新(比 MIPU 的 53.5% 拒絕率更保守),模型仍然崩潰,證明效果來自「有依據的選擇性接受」,而非單純的稀疏化或保守化。分析也指出,較小的 1.7B 模型在訓練與推論兩端的 KL 散度更大、同步後差距更不穩定,說明不一致問題在小模型上可能更嚴重。

意義

這篇論文的貢獻不只是又一種穩定 RL 訓練的技巧,而是重新定義了問題本身:以往大家把訓練推論不一致視為「該被縮小的系統誤差」,這篇論文則指出真正該優化的目標函數本來就沒有對齊——訓練引擎裡看似成功的更新,同步到推論引擎後未必真正變好。這個視角的轉換,對所有採用分離式訓練/推論架構的 RLHF、RLVR(RL with Verifiable Rewards)系統都有參考價值,尤其是在越來越多團隊用量化(FP8/INT8)加速推論、卻同時放大不一致問題的當下。

MIPU 的做法也提示了一個實務上可行的方向:與其一味追求更精確的數值對齊(成本高、且未必能完全消除差距),不如在更新流程中加入「驗證再接受」的機制,用少量額外運算成本換取訓練穩定性與最終部署效果的保證。這對正在規模化訓練推理模型(reasoning model)的團隊而言,是一個值得納入 pipeline 的實用手法。作者也坦言目前實驗僅限於中等規模模型(1.7B、4B),且驗證式過濾會帶來額外運算開銷,未來若能設計更高效率的估計器,應可進一步降低導入成本,讓這套「以推論政策為真正目標」的思路更容易被業界大規模採用。

背景

過去兩年,具身智能(Embodied AI)研究快速累積出兩大類模型:視覺-語言-動作模型(vision-language-action models,VLA),像是把大型視覺語言模型接上動作輸出頭,直接讓機器人「看得懂、聽得懂、做得到」;以及世界-動作模型(world-action models,WAM),試圖同時建模環境動態與動作決策。這些模型在論文和 demo 中表現亮眼,但一旦要把它們部署到真實機器人上,問題就浮現了:每個模型團隊各自維護一套 Python 推理棧,依賴特定的深度學習框架、特定後端(CUDA、特定晶片 SDK),再加上大量針對特定機器人寫的「膠水程式碼」(glue code)。當你想把同一個模型換到不同的邊緣硬體、不同機械臂、不同模擬器上跑,幾乎等於重寫一遍部署管線。

更根本的問題是,現有的推理引擎(例如常見的 LLM serving 框架)是為「請求-回應」(request-response)場景設計的——使用者送一個 prompt,等模型吐出一串 token。但具身智能的部署場景完全不同:機器人控制迴路本身就是閉迴路(closed-loop),不同模組(感知、規劃、底層控制)需要在不同的頻率下運行(multi-rate execution);推理必須是 batch size 為 1、以延遲(latency)優先,而不是像雲端服務那樣追求高吞吐量;輸入輸出也不再是固定的 token 序列,而是攝影機影像、多視角輸入、關節角度、力回饋等各種感測器資料與控制訊號。這些「執行契約」(runtime contract)上的落差,是現有推理框架無法直接套用到機器人身上的核心原因。

方法

作者(共 9 位研究者,含 Ling Xu、Chuyu Han、Borui Li 等)提出 Embodied.cpp,一個用 C++ 撰寫的、可移植的具身模型推理引擎。他們先對具代表性的 VLA 模型與 WAM 模型做架構分析,發現儘管模型細節各異,但存在一條共通的執行路徑(shared execution path),可以拆解成五層:

1. 輸入適配器(input adapters):負責把多路感測器資料——多視角相機影像、本體感覺(proprioception)、語言指令等——轉換成模型可用的張量格式。
2. 序列建構器(sequence builders):將不同模態的輸入組織成模型所需的序列結構,處理動作分塊(action chunking)、歷史上下文等。
3. 骨幹網路執行(backbone execution):實際運行 transformer 骨幹(例如 Hunyuan-VL 或 PaliGemma),這是計算量最大的部分。
4. 輸出頭插件(head plugins):針對不同模型的輸出格式(例如離散動作 token、連續動作向量)做模組化解碼,方便替換不同模型的輸出頭而不動骨幹程式碼。
5. 部署適配器(deployment adapters):把推理結果接到實際的機器人控制介面或模擬器 API 上。

在這個分層架構之上,Embodied.cpp 實作了三個關鍵能力:模組化的多速率執行(讓感知、規劃、控制可以各自以不同頻率跑,而不互相阻塞)、以延遲優先的融合推理(fused inference,針對 batch-1 場景做算子融合以降低單步延遲),以及可擴充的算子與 I/O 支援(方便未來加入新的感測模態或新模型架構)。整個系統透過統一的後端抽象層,讓同一套程式碼可以部署到不同的異質硬體、不同機器人本體、甚至不同模擬器上,不需要為每個目標平台重寫邏輯。

實驗結果

作者在兩個 VLA 模型與一個 WAM 基準上驗證了 Embodied.cpp:

• HY-VLA(採用 Hunyuan-VL 骨幹,三視角輸入):在 RoboTwin 模擬環境的 place_empty_cup(放空杯)任務上,達到 100.0% 的任務成功率,閉迴路執行完全成功,但由於骨幹網路較大,單步延遲較高。
• pi0.5(採用較輕量的 PaliGemma 骨幹,搭配延伸的動作分塊機制):任務成功率達到 91.0%,雖然略低於 HY-VLA,但攤銷後的單步計算成本更低,更適合對延遲敏感的場景。
• LingBot-VA(WAM 基準):由於邊緣裝置上的穩定性限制,目前只完成單個 Transformer block 的初步基準測試。透過 Q4_K 量化,該 block 的記憶體占用從 312.2 MiB 大幅降至 88.1 MiB,同時精度損失控制在很小範圍內——平均絕對誤差低於 3.3×10⁻²,餘弦相似度維持在 9.997×10⁻¹ 以上,顯示量化幾乎沒有犧牲模型輸出的準確性。

這些數字合起來說明兩件事:一是 Embodied.cpp 在追求跨硬體、跨模型可移植性的同時,並沒有犧牲原模型的任務表現(高成功率被完整保留);二是它在資源受限的邊緣裝置上,能透過量化等手段大幅壓縮記憶體占用(降幅接近 72%),這對於機械臂控制盒、機器人上的嵌入式運算單元這類記憶體吃緊的硬體非常關鍵。

意義

Embodied.cpp 的價值不在於提出一個更強的模型,而在於解決「模型做出來了,卻難以落地」的工程斷層。目前具身智能領域的論文往往聚焦在模型精度與泛化能力上,但業界工程師心裡都清楚:把一個在 A100 上跑得很順的 VLA 模型,搬到某個機械臂廠商自帶的異質晶片上,往往要花掉比訓練模型本身還多的時間去對接框架、改資料格式、重寫控制迴路的同步邏輯。Embodied.cpp 提出的五層架構,本質上是把「模型相關的部分」(骨幹、輸出頭)和「部署相關的部分」(輸入適配、部署適配)解耦,讓同一套 runtime 可以像「一次撰寫,到處部署」一樣服務不同模型與不同硬體。

這對整個具身智能生態的意義在於:如果未來 VLA、WAM 這類模型要像今天的大型語言模型一樣快速普及,勢必需要類似 llama.cpp 在 LLM 領域扮演的角色——一個輕量、可移植、C++ 撰寫、不依賴龐大 Python 生態的推理底層。Embodied.cpp 的命名本身也暗示了這種對標。論文中的量化結果(記憶體降低 72%、精度幾乎無損)也提示了一條清晰的路徑:未來邊緣機器人要同時搭載視覺-語言理解與動作生成能力,量化與算子融合會是繞不開的技術手段。當然,目前 WAM 部分僅完成單個 Transformer block 的初步驗證,尚未做到完整模型的端到端部署,這也說明具身模型的邊緣化落地仍在早期階段,後續仍需更多硬體與模型組合的驗證才能確立這套架構的普適性。

背景

資料科學的核心工作,是把雜亂、異質的原始資料轉換成可執行的商業洞見——清理資料、寫SQL、跑統計模型、畫圖表、寫報告,這一整套流程過去高度依賴人力,耗時又難以規模化。近年大型語言模型(LLM)驅動的「資料代理人」(data agent)被視為自動化這條流水線的最有希望方案:給它一份資料集和一句任務描述,代理人就能自主規劃步驟、寫程式碼、執行、除錯,最後產出答案。

問題是,業界始終缺少一套夠嚴謹、夠細緻的測試基準來評估這些代理人。既有的評測要麼題目來源單一(常常只用學術用的Kaggle題目),要麼標註粗糙(只看最終答案對不對,看不出代理人卡在哪個環節),很難反映真實業務場景的複雜度和多樣性。這正是清華大學團隊(第一作者Zhaoyan Sun,通訊作者包括資料庫領域知名學者Guoliang Li,共13位作者)提出AgenticDataBench的動機——打造一個涵蓋真實產業場景、且能拆解到「技能」顆粒度的資料代理人評測平台。

方法

AgenticDataBench的建置分四步走。第一,團隊從15個垂直領域蒐集真實資料集與任務,其中包含5個來自一家頭部金融科技(fintech)公司的真實B2B業務案例,其餘領域涵蓋農業、電商、能源、娛樂、醫療、貸款風險評估、行銷、房地產、社群網路、體育、旅遊、交通等,資料來源包括UCI Machine Learning Repository、NYC計程車/TLC資料、Natural Earth地理資料、NCI GDC生醫資料庫、Amazon評論、Our World in Data等公開資料集。

第二,為了避免真實任務重複、又要填補某些領域缺乏真實任務的空缺,團隊定義了「資料科學技能」(data science skill)這個概念——也就是資料處理中會反覆出現的操作模式(例如缺失值處理、多表join、時間序列聚合等)。這些技能是透過對Stack Overflow上大規模的問答解法做「技能對齊的層次式聚類」(skill-aligned hierarchical clustering)萃取出來的,用技能覆蓋數量來量化基準的完整度。

第三,針對真實業務任務,團隊在挑選題目時特意最大化「技能組合的多樣性」,確保案例能涵蓋各種實務情境組合,而不是同一種模式重複出現。第四,對於缺乏真實任務的冷門領域,團隊設計了一套系統化的LLM任務生成方法,依據萃取出的技能自動構造出完整的工作流程與任務,並搭配細粒度的標準答案(ground-truth)標註。

最終,AgenticDataBench共包含344個任務、覆蓋433種資料科學技能、涉及97個資料集、總資料量達27.3GB。團隊也開源了配套的測試沙盒(testbed),讓研究者可以直接跑自己的代理人並取得技能層級的表現拆解。

實驗結果

團隊用這套基準評測了目前主流的資料代理人與底層模型,涵蓋GPT-4o、Claude系列、DeepSeek、Qwen3、GLM等,以及多種以程式碼執行為核心的代理人框架。評測不只看「整個任務是否成功」這種二元結果,更透過細粒度標註,把每個任務拆成多個技能步驟分別打分——這樣即便代理人沒有完全解出任務,也能看出它在「資料清理」「統計建模」「多表關聯」「視覺化呈現」等不同技能上的具體強弱。

論文公開的結果顯示,即便是目前最強的商用代理人,在跨越15個領域、433種技能組合的真實任務前,整體成功率仍有明顯落差,且落差會隨任務所需技能數量增加而擴大——換句話說,單一技能的簡單題目代理人普遍應付得來,但需要串接多種技能、模擬真實分析師工作流程的複合任務,才是現有代理人的主要弱點。這也是AgenticDataBench相比過去「只看最終答案對錯」的評測方式,能提供的最大附加價值:技能層級的診斷讓研究者能精準定位模型該往哪個方向補強,而不是只知道「贏了」或「輸了」。

意義

AgenticDataBench的價值不只是又添一個評測榜,而是把「資料代理人」這個快速崛起的應用場景,從模糊的整體成功率,拉到可以逐項拆解、可追蹤進步的技能地圖上。5個來自真實金融科技公司的B2B案例,更讓評測結果直接對接產業實務,而不是停留在教科書式的Kaggle題目。

對開發資料代理人的團隊來說,這套基準提供了一個可重複、可比較的訓練與調優回饋迴路:哪些技能該加強、哪些領域資料分布特別「刁鑽」,都能在344個任務、433種技能組合中被量化出來。對更廣泛的LLM agent研究社群而言,這也再次印證了一個趨勢——評測基準正在從「任務通過與否」演化為「多步驟工作流程中每一步的可解釋性評分」,這對打造真正能取代部分資料分析師工作的AI系統,是不可或缺的一塊拼圖。隨著代理人在複合技能任務上的成功率被持續刷新,AgenticDataBench很可能會成為衡量這條進步曲線的重要標尺。