K1 論文詳解

背景

現在市面上大多數語音或視覺助理,骨子裡仍是「一問一答」的半雙工架構:使用者說完一段話,系統才開始處理、再輸出回應。這種模式在真人對話裡其實很不自然——人與人交談時會同時聽、同時想、隨時可以插話或用「嗯」「對啊」這類 backchannel 來回應,而不需要對方講完才開口。當互動場景加入畫面(例如視訊通話、直播陪伴、機器人視覺),系統還必須持續「看」著不斷變化的畫面,把對話錨定在當下的視覺情境裡,而不是只處理錄好的一段影片。

更麻煩的是,真實任務常常需要「查資料」「呼叫工具」「做長時間推理」,這些動作可能要花上好幾秒甚至更久。如果系統為了完成一個工具呼叫就整個卡住,對話就會失去即時感,使用者會覺得助理「當機」或「不理人」。過去的研究要嘛專注在讓對話更即時(全雙工語音),要嘛專注在讓推理更強(工具呼叫、agent),很少有系統同時把「即時互動」與「背景任務執行」揉合在同一套架構裡。

來自 Ant Group(螞蟻集團,與清華大學合作)的 Venus 團隊,提出了 Realtime-Venus,試圖同時解決這兩個問題:讓助理既能像人一樣自然地全雙工對話,又能在背景默默處理需要較長時間的任務,事後再把結果自然地插回對話中。

方法

Realtime-Venus 的核心是兩個各 9B(90 億參數)、分別訓練的模型:

• Realtime-Venus-Omni:處理音訊+視覺的全雙工互動,適合視訊類場景;
• Realtime-Venus-Audio:專注於純語音的全雙工對話。

兩者都被設計成「完整的對話前端」(complete conversational frontend),把三件事整合在同一個共享的因果時間軸(causal timeline)上:持續感知使用者輸入(語音、畫面)、對話控制(何時該說話、何時該安靜聆聽、何時該打斷)、以及原生語音生成(直接生成語音,而不是先出文字再轉語音)。這條時間軸同時記錄使用者輸入、模型輸出,以及「委派事件」(delegation events)——也就是任務被丟給背景處理的時間點與結果回傳的時間點,讓模型能感知到「我剛剛請了一個任務,結果現在回來了」。

支撐這套機制的是一個雙迴圈執行環境(dual-loop runtime):前景迴圈負責維持即時對話,不會因為任何耗時任務而卡頓或停止回應;背景則交給一個叫 Realtime-Venus-Harness 的組件,非同步地執行推理、查詢、工具呼叫等任務。任務做完後,結果不是生硬地插播,而是被整合進「正在進行的」對話裡,讓助理像是「一邊聊天一邊順手把事情辦好」,再自然地把結果講給使用者聽。

在訓練上,兩個模型採用共通的後訓練(post-training)配方,結合三種資料/軌跡:離線的理解類資料(offline understanding)、主動式全雙工對話軌跡(proactive full-duplex trajectories,教會模型何時該主動開口、何時該讓、何時該打斷)、以及委派工作流(delegation workflows,教會模型如何拆分「當下要回什麼」與「該丟給背景做什麼」)。这種訓練方式讓同一個模型骨幹既能維持自然對話的節奏感,又具備類 agent 的任務執行能力。

實驗結果

在視覺理解與串流影片類的評測中,Realtime-Venus-Omni 在所有參與比較的「線上模型」(online models,即能即時處理串流輸入的模型)裡,於 8 個影片 benchmark 中的 6 個拿下最高分,其中包括:

• StreamingBench:70.2%
• OVO-Bench:64.7%
• Daily-Omni:81.3%

在語音理解與口語問答方面,Realtime-Venus-Audio 在 8 個音訊類 benchmark 中,於以下項目領先所有對比模型:

• MMAU:78.0%
• MMAU-Pro:63.2%
• Llama Questions:83.8%
• Speech CMMLU:67.8%

同時在 VoiceBench AlpacaEval 上打平目前最佳成績,達到 4.81 分。

最能體現「全雙工」設計價值的,是在 Full-Duplex-Bench v1.5 上的表現:Realtime-Venus-Audio 能對使用者的插話(interruption)做出回應的比例達到 75%;而在三種需要「不打斷、繼續講」的情境下——使用者只是發出 backchannel(如「嗯哼」)、使用者其實在對別人說話(other-directed speech)、背景環境有其他聲音(background speech)——模型的**繼續對話比率(continuation rate)**分別達到 97%、88%、86%,在這三項指標上全面超過 Gemini 3.1 Live 與 GPT-4o。這意味著 Realtime-Venus 不只是「反應快」,更懂得判斷「這時候到底該不該接話」,這是全雙工對話裡最難拿捏的分寸。

意義

Realtime-Venus 的價值不在於單一項 benchmark 的分數,而在於它示範了一種「對話即操作系統」的架構思路:把即時感知、對話輪替、語音生成與非同步任務執行,全部統一在一條共享的因果時間軸上處理。過去要達成「邊聊邊查資料」的效果,往往得靠工程上的取巧(例如硬插入「稍等一下」的固定話術),而 Realtime-Venus 把「委派」本身變成模型訓練資料的一部分,讓模型自己學會何時該說「我先幫你查一下」、何時該在結果回來後自然地接話,而不會讓對話卡住。

其次,9B 這個規模也值得留意——比起動輒數百億參數的通用大模型,Realtime-Venus 用相對精簡的模型規模,專注在「對話前端」這個垂直場景上做深度優化,同時涵蓋語音理解、視覺理解與輪替判斷,顯示針對特定互動形態做垂直優化,能在有限算力下取得對話体验上的顯著提升,而不必一味堆參數量。

對於語音助理、陪伴型 AI、客服機器人、甚至機器人視覺互動等應用而言,「打斷判斷」與「背景任務不卡對話」這兩個能力如果能做到 Realtime-Venus 展示的水準,將直接影響使用者的真實體驗——不再是生硬的一問一答,而更接近人與人交談時那種流暢、隨時可插話、又能默默把事情辦妥的自然感。這也預告了下一代語音助理的競爭重點,可能會從「回答得準不準」逐漸轉移到「接話接得自不自然、任務丟得順不順」。

背景

近年來,大型語言模型在解題能力上突飛猛進,但「教育」這個場景其實遠比單純解題複雜。一個真正能用在課堂或自學情境的教育基礎模型,除了要能解出數學、理化等 K-12(幼兒園到高中)題目之外,還必須理解課綱結構(哪個年級該教什麼概念、概念之間的先後順序)、能診斷學生錯在哪裡(diagnostic reasoning),以及懂得如何用循序漸進、啟發式的方式引導學生,而不是直接給答案(pedagogical scaffolding)。

然而,現有的教育向語言模型多半只專精其中一塊:有些模型專注在「解題」,擅長把數學題目算對;有些則專注在「家教式對話」,擅長用蘇格拉底式提問引導學生思考,但解題能力普通。研究團隊觀察到一個關鍵問題:大部分教育資料集的訓練資料是「依照來源(哪個出版社、哪個題庫)」或「依照任務(選擇題、問答題)」來組織的,而不是依照模型該具備的「能力」來設計。這種組織方式導致訓練出來的模型能力失衡——擅長解題的家教機器人不會教,擅長對話的家教機器人不會算。

為了解決這個落差,研究團隊提出了 OmniEdu,一個開源的 K-12 教與學基礎模型家族,試圖用「能力導向」而非「來源導向」的方式重新設計指令微調(instruction-tuning)資料,讓同一個模型同時具備解題、懂課綱、會診斷、會引導這四種能力。

方法

OmniEdu 的核心貢獻不在於全新的模型架構,而在於一套精心設計的資料建構與微調 pipeline。研究團隊整合了超過 100 個教育資源與通用指令資料來源,並將所有訓練樣本圍繞四個核心能力重新組織:

1. subject competence(學科能力):確保模型具備扎實的學科知識與解題能力;
2. curriculum grounding(課綱扎根):讓模型理解不同年級、不同單元之間的知識脈絡與先後順序;
3. diagnostic reasoning(診斷推理):訓練模型判斷學生的錯誤答案是卡在哪個環節、屬於哪種常見迷思概念;
4. pedagogical action and scaffolding(教學行動與鷹架引導):讓模型懂得用提示、追問、分步引導等方式協助學生自己想通,而不是直接餵答案。

資料處理 pipeline 包含五個階段:確定性清洗(deterministic cleaning,去除格式錯誤、重複或損壞的樣本)、語意審核與改寫(semantic auditing and rewriting,修正不精確或有問題的教學語言)、任務特定的品質評分(依照不同任務類型分別打分,而非用單一標準一視同仁)、token 預算下的多樣性選擇(在有限的訓練 token 額度內,盡量挑選涵蓋面廣、不重複的樣本),以及教學指令分派(pedagogical instruction assignment,把樣本正確標記到上述四種能力類別中,確保四類能力的資料量不會嚴重失衡)。

經過這套流程,最終產出 69,999 筆訓練樣本、共 1,596 萬(15.96M)個監督式回應 token,其中 60,951 筆是教育專屬樣本(其餘為通用指令資料,用來維持模型的一般能力不退化)。研究團隊基於這批資料,對三種規模的基礎模型進行微調,分別產出 OmniEdu-4B、OmniEdu-9B 與 OmniEdu-27B,涵蓋從輕量到中大型的部署情境,方便不同算力條件的教育應用(例如本地部署在學校伺服器,或雲端大規模服務)採用。

實驗結果

研究團隊在三大類教育評測與一個通用能力評測上驗證 OmniEdu 的效果:課綱理解、K-12 解題能力,以及教學家教能力。結果顯示,教育導向的微調在所有模型規模(4B、9B、27B)、所有三組教育 benchmark 上都帶來一致的提升,而不是只在某個尺寸或某個任務上有效。

以最大的 OmniEdu-27B 為例,具體數字如下:

• K12-Bench(K-12 解題與課綱理解綜合評測):Exact Match(EM)達到 63.12%,F1 分數達到 76.69%;
• MathFish(數學相關評測):準確率達到 85.89%;
• EDUMATH(數學教育評測):達到 86.95%;
• MathTutorBench 的 Scaffold 設定(評估模型是否能用鷹架式引導而非直接給答案來教學):達到 78.74%;
• LongTutor(長篇家教對話評測):在所有參評模型中,OmniEdu 拿下最高的 Teaching 平均分 3.02 分。

這些數字的意義在於,OmniEdu 並非在某一項任務上「偏科」拿高分,而是在解題準確度(K12-Bench、MathFish、EDUMATH)與教學引導品質(MathTutorBench Scaffold、LongTutor Teaching)兩個方向上同時取得業界領先或具競爭力的表現。論文同時強調,即便是最小的 4B 模型,教育導向調校後在三組 benchmark 上相較未調校前也都有一致提升,顯示這套方法在小模型上依然有效,並非只靠堆大模型參數量取勝。

意義

OmniEdu 這篇研究的價值,不只是又推出一組性能亮眼的開源模型,更重要的是它示範了一個方法論上的轉向:與其把教育資料按「題庫來源」或「任務格式」分類拼湊,不如按「模型該具備的能力」重新設計訓練資料組成。這個思路其實可以類比到其他垂直領域的模型微調——例如醫療、法律等場景,同樣存在「專業知識」與「溝通引導」難以兼顧的問題,OmniEdu 的能力導向資料建構 pipeline(清洗、審核改寫、品質評分、多樣性選擇、能力標註)提供了一套可複製的方法框架。

其次,OmniEdu 以開源形式釋出 4B、9B、27B 三種規模,意味著從資源有限的學校、教育新創,到有算力的雲端服務商,都能依照自身需求選擇合適的模型規模落地應用,而不必依賴閉源、按 API 呼叫計費的商用大模型。這對於教育資源相對不均的地區(例如偏鄉學校或開發中國家)特別有意義,因為較小的 4B 模型也能在教育導向調校後取得明顯提升,降低了「用得起好用的 AI 家教」的門檻。

最後,LongTutor 上 Teaching 平均分 3.02 分拿下所有參評模型最高分,以及 MathTutorBench Scaffold 設定的 78.74% 表現,顯示模型不只是「會算」,而是真的朝「像一個好老師一樣引導學生思考」的方向前進。這對於教育科技產業未來設計 AI 家教產品、智慧學習平台、自適應學習系統(adaptive learning)都有直接的參考價值——未來的教育 AI 產品評估,或許也應該像 OmniEdu 這樣,同時檢視解題正確率與教學引導品質這兩個維度,而不是只看模型考試考幾分。

背景

近年 LLM agent 已經不再只做單輪問答，而是被丟進動輯需要數十步甚至數百步的長任務裡——寫一整個功能、跑一組實驗、除錯一個複雜的 repo。這類任務的成敗，往往不是取決於「模型會不會寫程式」，而是取決於它在關鍵岔路口選了哪條路：該先驗證哪個假設？該在哪個既有實作基礎上繼續蓋、還是砍掉重練？該堅持原本的除錯方向、還是換個角度？作者把這種「在長任務裡持續做出好決策」的能力稱為 agent 的 taste（品味）。

問題是，現有的 agent benchmark 幾乎都只看「end-to-end 成不成功」——任務最後有沒有通過測試、有沒有解決 issue。這種指標沒辦法告訴我們：模型是不是在過程中做對了關鍵選擇，還是純粹靠運氣、靠暴力嘗試撞對答案。換句話說，業界一直缺一把尺，專門量測「決策品質」本身，而不是被稀釋在整條漫長軌跡裡的最終結果。

這篇論文（arXiv:2609.25804，Wenbo Pan、Zhichao Liu 等九位作者合著）正是要補上這塊空白，提出 Taste-Bench，一個自動從真實 agent 執行軌跡中挖掘出來的「品味測驗」。

方法

Taste-Bench 的核心設計是「決策岔路」（decision fork）：找到軌跡中某個時間點，agent 面前有多條可走的路，其中一條後來被證實明顯更好。評測時模型只能看到岔路口之前的內容，必須在不知道後續發展的情況下做選擇——這正好模擬真實世界中「當下決策、事後才知道對錯」的處境。

論文用兩種完全自動化、不需要人工標註的方式挖掘岔路：

第一種是平行嘗試（parallel trajectories）：同一個任務被 agent 跑了多次，在某個共同的前綴之後，不同次嘗試分岔走向不同方向，最後有的成功、有的失敗（或表現較差）。分岔點之前的共同部分就變成題目情境，較好的分支即為正確答案。

第二種是單軌跡內的繞路（detours）：在單一條軌跡裡，agent 一開始選了一個方法、中途踩雷失敗、之後才調整方向並成功復原。論文用一個「生成模型」在軌跡裡自動定位三個事件——承諾採用某方法、觀察到失敗、換方向後復原——藉此重建出一個岔路題目。

這兩種方法都是靠「事後諸葛」（hindsight）來提供監督訊號：後續發生了什麼，決定了當初哪個選項才是對的。整個資料集最終彙整出 502 道題目，題材來自工程（如修 bug、寫功能）與研究類任務的真實軌跡。

評測時，論文找了 14 個當前最前沿的模型，涵蓋 Claude、GPT、Grok、DeepSeek、GLM、MiniMax、Mistral 等家族，並在相同的 token 預算下統一測試，確保比較公平。由於每題都要求模型在兩種候選排列順序下都答對，隨機猜測的基準線是 25%。

在訓練部分，作者展示「品味是可以被蒸餾出來的」：用一個已經看過任務結果的「教師」模型（帶著岔路後的示範答案）去指導一個「學生」模型（只看到岔路口之前的題目、看不到答案）。訓練上採用凍結的 base model（Qwen3.6-27B）搭配 LoRA adapter，透過 forward KL divergence 讓學生的輸出分佈對齊教師產生的推理 token，藉此把「事後才看得出來的判斷力」內化成學生在「事前」就能做出的決策能力。為了確保學到的是可遷移的判斷力而非死記硬背，評測時特別採用任務不重疊（task-disjoint）的切分方式。

實驗結果

最好的模型 GPT-5.6 Sol 在 Taste-Bench 上平均準確率也只有 59.7%，GPT-5.5 緊追在後為 59.5%，其餘模型的分數則相當分散，普遍偏低——而隨機猜對的基準線是 25%。換句話說，即便是最頂尖的前沿模型，在「當下判斷哪個方向未來會更好」這件事上，表現離「精準」還有很大一段距離。

論文進一步發現兩個值得注意的現象：

第一，決策所需證據出現得越晚，準確率掉得越兇。如果佐證岔路好壞的關鍵資訊就在岔路口附近（in-prefix），平均準確率有 62.3%；但如果要等到後續投入大量工作才會顯現出「這條路是對的」，準確率會驟降到只剩 21.0%——幾乎跟瞎猜差不多。這說明模型很擅長判斷「眼前的線索」，卻很不擅長預判「需要長遠鋪陳才會顯現價值」的選擇，這恰好是長任務中最考驗判斷力的那種決策。

第二，加大推理預算（reasoning budget）幾乎沒有幫助。跨模型測試下，提高思考量對準確率的影響只在 -0.2 到 +2.2 個百分點之間浮動，且在任何時間跨度層級都沒有觀察到明顯改善。這暗示「品味」不是單純靠多想幾步就能補上的能力，而更像是一種需要另外訓練、內化的判斷力。

在下游驗證上，作者在 41 個保留（held-out）的 SWE-bench Pro 任務上做了端到端測試：沒有任何建議時，baseline 成功率為 14.6%；如果 agent 在岔路口能拿到「正確答案」的建議，成功率跳升到 39.0%，等於提升了 24.4 個百分點；而使用蒸餾出的學生模型給出的建議，成功率達到 33.7%，提升 19.1 個百分點——也就是說，學生模型雖然沒有教師那樣的「上帝視角」，卻已經拿到了大部分（most of this bound）潛在的效益提升。

意義

這篇論文的價值不只是「又多了一個 benchmark」，而是指出了當前 agent 評測體系的一個結構性盲點：我們一直在用「任務最後成不成功」這個高度滯後、高度雜訊的訊號來衡量 agent 能力，卻沒有工具去拆解「過程中每一次關鍵抉擇」的品質。Taste-Bench 把這個抽象概念變成了可自動、可規模化生成的測驗，而且完全不需要昂貴的人工標註——這對於想持續擴充、迭代 benchmark 的研究團隊來說是重要的工程貢獻。

更關鍵的發現是「reasoning budget 不管用」這一點：這直接挑戰了「只要讓模型多想一點，長任務表現就會變好」的常見假設，暗示未來要提升 agent 在長任務中的表現，可能需要的不是更多算力去做更長的思維鏈，而是專門針對「早期判斷、晚期驗證」這種因果延遲問題做訓練。

而蒸餾實驗證明品味是「可教的」——教師模型憑藉事後諸葛的優勢做出正確判斷，這個判斷力可以透過 LoRA 微調與 KL 散度對齊，轉移給一個事前就得做決定的學生模型，並且這個能力還能泛化到訓練時完全沒見過的任務類型（SWE-bench Pro），帶來實打實的 end-to-end 成功率提升（14.6% 到 33.7%，直逼上限 39.0%）。這替「用高品質示範資料 + 蒸餾」這條路線提供了一個具體、可驗證的成功案例，也為未來訓練更「有判斷力」而非單純「更能算」的 agent，提供了一個明確的方法論範本。對正在打造工程或研究型 agent 產品的團隊來說，這代表除了衝刺 end-to-end pass rate 之外，或許也該開始針對「決策點」本身設計訓練訊號與評測指標。