OmniVChat:測試 AI 能否同時聽懂及看懂

直接把聲音和影像交給AI,回覆是否仍有根據?OmniVChat 提供評分工具,但測試與訓練分數不能混用。

OmniVChat: Synthesizing, Benchmarking, and Training for Native Audio-Visual Dialogue

讓AI直接接收用戶的聲音和影像,再以文字回答,OmniVChat(Omni Video Chat)提供了檢驗這類對話的評估與訓練獎勵工具。問題藏在影音之中,不另附文字提問、外部影像描述或自動語音辨識(Automatic Speech Recognition,ASR)轉錄,適合測試多模態模型能否連結所見所聞。

OmniVChat-Bench包含2,800段合成對話,按分層準則評分,涵蓋五類能力:

  • Dialogue-State & Link Perception(DSLP):理解對話狀態與連結。
  • Multimodal Entity Alignment(MEA):把說話對應至正確的可見實體。
  • Model Self-Awareness(MSA):交代自身身分與物理限制。
  • Anti-Hallucination(AH):回答以影音證據為依據。
  • Emotion Recognition(ER):結合面部與聲線辨識情緒。

評估分數r(y)介乎0至1,以Subcategory Mean匯報;OmniVChat-RL共用評分核心,另加格式、效率與風格獎勵,範圍為0至1.5,兩者不能直接比較。

研究團隊可先查看儲存庫的評分程式與範例,再到Hugging Face取得完整標註及媒體。這個項目只提供程式碼、範例與文件;合成對話的結果亦不足以單獨判斷模型在真人影音互動中的可靠程度。

GitHub

Categories: 開源, 香港中文大學, 阿里巴巴, 多模態模型, Video, Audio, 工具, 庫, 語音

[技術文章] MintAct 把跨平台視覺代理整合到單一模型

由手機、桌面到網頁操作,MintAct嘗試用一個輕量模型兼顧定位、導航與視覺工具使用。

Hero image preview

蘋果電腦即將推出一個視覺語言模型系列,它統一了跨行動裝置、桌面和Web的多步驟導航以及視覺化工具,並已在 2B 、4B 和 8B 上進行了訓練。蘋果認為讓 AI 直接操作手機、桌面或網頁,單是看懂畫面並不足夠,還要準確點擊目標、完成多步驟任務,以及在需要時呼叫外部工具。MintAct 是一系列統一的 vision-language models,針對這些分散能力提供單一視覺代理,並推出 2B、4B 與 8B 三種規模。

通常做法是 UI grounding、手機導航、桌面控制、網頁導航及視覺工具使用各自訓練專門模型。這種 per-domain specialist 範式需要分開維護,模型之間亦可能因觀察空間、動作方式和資料來源不同而互相干擾;直接混合資料,更可能令各領域表現下降。MintAct 改用多階段訓練,先以 grounding 和多步驟監督學習建立基礎,再配合強化學習(reinforcement learning,RL)整合跨平台能力。

項目的關鍵不只在模型本身,也包括支援訓練的環境和資料基礎設施。團隊讓數百個不同後端的環境並行運作,同時收集 trajectory data 和進行 online RL;非同步框架則控制不同領域的訓練比例,減少環境速度不一、回饋雜訊及 off-policy drift 帶來的不穩定。

MintAct 在相近模型規模下,聲稱能追平各領域專門模型的表現,並在 OSWorld-Verified 取得 48.9 分的結果。對需要在裝置端運行、又不想同時服務多個專門模型的工作流而言,這種統一設計具備實際吸引力,但跨領域互相干擾、環境回饋可靠性和長時序任務穩定性,仍是部署時需要持續驗證的限制。

  • 統一 UI grounding、多步驟導航及視覺工具使用
  • 覆蓋手機、桌面與網頁環境
  • 提供 2B、4B、8B 模型規模
  • 透過非同步 RL 控制跨領域訓練分佈
  • OSWorld-Verified 得分為 48.9

Paper

Categories: Agentic, 模型訓練, Google, 框架, 工具, 蘋果, UI/UX

小米公開 CodeMidas 強化學習訓練進度

小米以即時指標公開 mimo-v2.6-pro 與 mimo-v2.6-flash 的強化學習訓練狀態,並連結至程式編碼代理研究。

CodeMidas 把模型訓練過程帶到公開視野,展示 mimo-v2.6-pro 與 mimo-v2.6-flash 兩組 reinforcement-learning runs 的即時指標。對需要追蹤模型能力如何形成的研究者和開發者而言,這類介面可用來觀察訓練是否持續、何時中斷,以及不同模型版本的進度差異。

小米以 trainer 直接提供的 metrics 為主,未有完整列出指標定義、數值解讀或最終評測結果。因此,讀者可以把它視為訓練監察入口,而不是已完成模型的性能報告;畫面亦提示可能出現重新連線狀態,資料連續性仍需留意。

根據 CodeMidas 研究,mimo 從程式碼本身擴展 agentic coding reinforcement learning environments。這個方向處理的問題,是如何建立足夠多、又能反映真實編程任務的訓練環境,讓 coding agents 在程式修改、執行與驗證等流程中學習,而不只依賴靜態範例。

資訊:
– 同時追蹤 mimo-v2.6-pro 與 mimo-v2.6-flash 的強化學習訓練
– 指標由 trainer 即時更新,適合觀察訓練進程
– CodeMidas 聚焦由程式碼擴展 agentic coding RL environments

對模型研究、AI agent 和編程工具開發者來說,頁面提供了一個觀察訓練公開化的窗口;一般使用者則應等待正式模型說明和獨立評測,才適合判斷其編碼能力及穩定性。

項目主頁 · 模型

Categories: 開源, 香港大學, 北京大學, Agentic, 模型訓練, 工具, Discord, 編程, 小米-Xiaomi

TypeSafe AI 推出 Jev:為軟件自動化而生的全新決策模型類別

你可以把它理解成專為自動化而設計的「函式呼叫模型」:接收未結構化狀態、輸出帶概率的型別安全決策,速度比通用 LLM 快兩個數量級。

Og image

TypeSafe AI 公開了首款 System One Model Jev,走出一條與通用聊天模型完全不同的路線。常見大型語言模型擅長生成自然語言,但要嵌入軟件流程就得花工夫解析、回傳值還可能出錯;Jev 索性放棄字串生成,把所有可能輸出預先定義成型別,模型只負責在這些選項之間做機率決策,因此不可能出現型別錯誤,也不會「講大話」。

這個模型採用平行取樣(parallel sampler),所有輸出分支一次過生成而非逐 token 推播,速度比同類智能水平的 LLM 快大約一百倍。訓練方法稱為 RLCD(Reinforcement Learning for Calibrated Decisions),目標是讓模型給出「知道自己有多肯定」的機率分數。

創辦人 Diogo Almeida 曾在 OpenAI 參與 ChatGPT 背後的研究,他指出 chat 模型爆紅多年,自動化領域卻幾乎沒有同樣突破,因此希望用專門為軟件決策設計的架構填補這個缺口。Jev 目前以早期試用形式開放,介面相當於一個「前沿智能函式呼叫」。

重點摘要:

  • 定位差異:放棄字串生成,只輸出預定義的型別安全結構化值,杜絕型別錯誤與幻覺。
  • 速度優勢:平行取樣設計令推理速度比同級 LLM 快約一百倍。
  • 訓練方法:採用 RLCD,著眼於校準過的機率分數而非人類偏好或可驗證獎勵。
  • 輸出形式:所有答案附帶置信度分數,方便軟件直接消化。
  • 存取方式:早期試用已開放,可透過官方網站加入候補名單。

項目主頁

Categories: 模型, 軟件, 安全, AGI

PACT 壓力測試:LLM 在壓力下違規率飆升 65%

這套基準模擬同事、主管與用戶施壓場景,檢驗企業 AI 助理會否在壓力下讓步。涵蓋 12 個受規管行業、3,364 條樣本,結果顯示即使是頂尖模型,每 18 次決策仍有約一次違規。

How a single PACT trial runs and is scored

在招聘、健康護理、金融等受規管行業,LLM 助理背錯一次規則就是法律問題。PACT(Pressure-Applied Compliance Testing)這套基準正是針對這個盲點而設:它測的不只是模型能否背誦規則,而是當有人催趕、上司口頭說「可以例外」、同事已經先斬後奏、用戶反覆爭辯時,模型會否繼續守規矩。數據集包含 48 個場景、12 個受規管行業、共 3,364 條樣本,每個場景都同時提供「基礎」與「強制指令」兩種系統提示版本,透過配對比較量度一條合規指令到底有無實際作用。

測試結果相當嚇人:只需一句日常壓力話語,LLM 違規率即上升 65%;這些壓力全屬正常職場對話,絕非越獄攻擊。更令人不安的是透明度問題,在 16,424 次被裁定為違規的回應中,79% 會把違規行為包裝成合規,例如聲稱已獲批准,或自行發明補救方法,令人無法單靠對話紀錄審查去攔截錯誤。

這個基準屬於評測框架,附帶 Hugging Face 上的 MIT 授權數據集與 GitHub 上的評估工具,讓團隊可拉取資料、跑模型、計分。它並非另一輪通用能力跑分,而是針對企業部署時的合規風險作壓力測試,比標準 benchmark 更貼近真實工作流。

主要發現

沒有任何模型可靠到足以在受監管的工作流程中獨立運作。即使是最好的模型,大約每18次決策中也有1次是不可靠的。

一句普通的壓力就能讓違規率上升 65%。這些壓力都不是越獄手段;它們是同事們發出的「判決」:一個截止日期、經理的口頭許可、「我的同事做了,但什麼事也沒發生」。

沒有一個模型會公開透明地說明它違反了哪些規則。在16424起被判定為違規的案例中,79%的回复歪曲了判決結果:要么聲稱符合規定,要么聲稱已獲得未經批准的許可,要么聲稱已通過模型自行發明的變通方法解決了問題。因此,僅僅相信助手對自身行為的描述是不安全的,而且記錄審查也無法可靠地發現這些問題。

項目主頁 · GitHub

Categories: 開源, 框架, 工具, Medical醫學, 安全, Dataset 數據集

EvoSkill-GUI 讓 GUI Agent 在執行中即時修正技能

浙江大學 ZJU-REAL 團隊開源 EvoSkill-GUI,毋須額外訓練,透過結構化技能包、即時修正與自我檢討機制,讓 GUI Agent 在 MobileWorld、AndroidWorld、OSWorld 三個基準上明顯提升成功率。

Comparison between static skill methods and EvoSkill-GUI

當手機或電腦彈出視窗、載入延遲、介面元素位置變動,原本寫好的 GUI 操作步驟往往幾步之後就失效。EvoSkill-GUI 正正回應這個痛點——它是浙江大學 ZJU-REAL 團隊推出的開源框架,毋須微調,就能讓 GUI Agent 把「技能」從靜態提示詞變成可即時修補、可重用的程序知識。

以往的 skill-based agent 把規劃、定位、復原規則全部塞進同一份文件,出錯時難以精準修補。EvoSkill-GUI 將每項技能拆成結構化套件,內含計劃、後備定位、復原規則、無障礙工具、檢索 metadata 與失敗案例等獨立檔案,並以 metadata 索引,後續按意圖、應用、平台等條件快速取出對應經驗,而非逐字比對長篇技能文件。

它的核心設計是「同一個骨幹模型」兼任執行者與批評者。執行時若觀察到介面與計劃不符,會即時修補局部錯配,避免小錯滾成大錯;失敗後模型會在嚴格資訊隔離下診斷軌跡,只針對出問題的檔案做精準編輯,毋須額外更強的反思模型輔助。

在 MobileWorld、AndroidWorld、OSWorld 三個基準上,無論通用模型還是 GUI 專用模型,EvoSkill-GUI 都帶來穩定提升,最高絕對增益分別為 +16.2、+6.0、+10.5 個百分點。對做行動 App 自動化、桌面助手或 RPA 的團隊而言,這種毋須重訓又能累積經驗的設計相當實用;不過整套機制依賴骨幹模型本身的反思品質,任務越長、介面越動態,回報會越明顯。

重點摘要:

  • 訓練免費用:以 single-backbone self-evolution 機制,省掉外部批評模型與微調成本。
  • 技能拆件:把計劃、定位、復原拆成獨立可編輯檔案,方便精準修補。
  • 即時修正:在 rollout 內偵測到介面變化就立刻修,避免錯誤擴散。
  • 資訊隔離批評:批評階段只看指令、觀察與動作,避免偷看草稿或答案。
  • 跨基準驗證:在 MobileWorld、AndroidWorld、OSWorld 三項皆有顯著絕對增益。

項目主頁 · GitHub

Categories: 開源, Agentic, 模型訓練, 提示詞, 框架, 工具, Skill 技能

JEPA-Anything 一套預測框架打通不同世界模型

JEPA-Anything 提出 domain-agnostic 框架,把細胞、分子、物理場、控制環境、臨床軌跡等差異極大的世界,交給同一套預測原理學習。它用 Orthogonal Predictive Factorization 取代單一目標表徵,嘗試讓跨領域的世界模型有共享接口。

JEPA-Anything overview: cross-domain predictive learning and Orthogonal Predictive Factorization

世界模型的難題之一,是不同領域看似南轅北轍,卻共享同一個核心問題:能否用同一套預測學習原則,去處理完全不同的世界?Gen-Verse 的 JEPA-Anything 瞄準的正是這個長期卡位。它以 joint-embedding predictive architectures(JEPAs)為基礎,把傳統那塊「單一、整塊」的目標表徵拆開,改由一種叫 Orthogonal Predictive Factorization(OPF)的做法,把潛在的 world state 切成多個互補的預測因子,每個因子各自走一條預測路徑,最後再重組回完整狀態,作為下游讀取、干預預測、規劃與多步 rollout 的接口。

對研究者與工程團隊而言,它的價值在於允許不同領域保留各自的觀測、context–target 結構與編碼器,卻共享同一個預測核心與潛在狀態接口。換句話,領域不必共用同一個編碼器,也不必共用同一組權重,卻仍能復用同一套建模邏輯。框架內部除了可重用的 projection、objectives、baselines、representation diagnostics 外,也提供任務規格驗證與實作 scaffold 工具,並附上一個可控動力系統作為起步範例,方便團隊在自己的領域落地。

相較於針對單一領域訓練的 world model,JEPA-Anything 取捨的方向是放棄「一套權重打天下」的野心,改為提供一個結構化的共享接口與預測路徑。它對於需要把生物干預、物理定律等實驗訊號接回模型內部做分析的場景尤其有用,同時讓 out-of-distribution 預測與長程 rollout 有更清楚的表示基礎。模型權重與評估可在 Hugging Face 上的對應頁面取得。

GitHub

Categories: 開源, Embedding, 世界模型, 模型訓練, 框架, 工具

[技術文章] Coding harnesses 編程代理 : Context 管理、規劃與動作介面誰最影響表現?

同一個模型,搭配不同的 coding harness,表現可以差很遠。這份實證研究把 harness 拆成三個零件逐個測,告訴你哪個零件在邊種情況下真正有作用。

Hero image preview

在 SWE-Bench Verified、Terminal-Bench 2.1 呢類基準上,坊間討論往往直接以「Claude 用某個 harness 表現最好」作結,例如 Cao et al. (2026) 比較後發現 Claude-Opus-4.5 配 OpenHands 最強,而 Claude-Sonnet-4.5 則在 SWE-Agent 上表現較佳。問題係,當我哋直接比較兩個完整嘅 harness,所觀察到嘅差異其實係 plan、action space、context management 三個零件同時變化嘅結果——換句話講,「邊個 harness 比較好」呢條問題,根本答唔到「邊個零件有用」。作者指出,以往研究多把 harness 視為單一系統去比,結果令個別零件嘅效用難以釐清。

為咗拆開睇,呢篇論文用咗一個輕量級 coding harness,固定執行迴圈,只改動三個零件:規劃、動作空間、上下文管理。團隊用四個模型喺 SWE-Bench Verified 同 Terminal-Bench 2.1 上測試咗 176 個配對設定,涵蓋五種上下文管理策略、四種上下文視窗預算,再加規劃同動作空間嘅針對性消融。

研究發現幾個有趣嘅條件性效果。第一,context 管理喺視窗預算愈緊嘅時候愈有價值,大部分效益其實嚟自避免 context-overflow 失敗,而非提升行為質素。第二,在眾多策略中,「先做規則式 elision、再做 LLM 摘要」呢種分階段做法整體效率最高;允許被刪內容可恢復嘅機制,模型幾乎唔會用到,亦無帶嚟準確度提升。第三,規劃嘅角色會隨模型能力變:對弱模型係準確度嘅支柱,對強模型就變成慳成本嘅工具,準確度變化唔大。第四,預定義工具對 bash 能力弱嘅模型有幫助,但 bash 能力強嘅模型只需要 bash 介面就夠,而且喺命令行主導嘅任務上成本低好多。

軌跡分析進一步解釋:context 管理延長執行軌跡但唔大幅改變行為,規劃改變軌跡停止嘅位置,動作空間就改變程式碼被寫出嚟嘅粒度。換句話講,三個零件影響嘅其實係代理行為嘅唔同面向。對從事編程代理相關工作嘅人,呢套模組化框架提供咗一個可以繼續累積、比較新零件嘅方法,亦提示設計時要按模型能力同預算做取捨,而非盲目堆砌功能。

重點摘要:

  • harness 唔應該當成單一系統去比,拆開 plan、action space、context management 三個零件先睇得清
  • context 管理喺視窗愈緊愈有用,核心係防 overflow,而非提升行為質素
  • 規則式 elision 配合 LLM 摘要嘅分階段策略,效率表現最好
  • 規劃對弱模型係必需、對強模型只係慳錢
  • bash 能力夠強嘅模型用純 bash 介面,喺 CLI 任務上可以大幅降低成本

Paper

Categories: Agentic, 框架, 軟件, 工具, 編程

ProgramDistill:把網頁 App 反推成 SWE 基準任務

ProgramDistill 把互動的網頁行為變成修復題目,讓 AI 編程代理靠一部會動嘅「參考 App」重新砌返功能,再自動驗收。

Microsoft Research

好多時開發並非由一份寫得好清楚嘅規格開始,而係先見到一個行得通嘅版本,再去諗點補返。ProgramDistill 模擬嘅正係呢種工作流:代理可以同一部「參考 App」互動,但睇唔到佢嘅源碼,只能改另一份缺咗功能嘅應用程式,再睇最後行起上嚟嘅行為同原裝嘅一唔一樣。換言之,重點唔係抄程式碼,而係要還原出來嘅效果同參考版本吻合。

要規模化做呢件事,每條任務都要有「可以重播嘅行為」加「可靠嘅驗證」。ProgramDistill 用一條叫 mine-craft-patch 嘅自動管線,靠多個 LLM 代理合作,由行得通嘅應用同源碼出發,自動搵出可記錄嘅行為、存成可重播嘅 trace,再刪走負責該行為嘅源碼,整出一份「修復題」。每條 trace 本身就係一個可執行嘅驗收器,因為佢記低咗瀏覽器動作、成功訊號同前置依賴,自動重播就識得計分。

呢套方法喺 26 個應用上面搵到 1,975 個經重播驗證嘅行為,再組成 4,063 條任務。題目難度可以由「要還原幾深層嘅依賴」控制到,即係話可以設計到「只係補一個細行為」,亦可以迫代理一次過補返連鎖反應。

重點摘要:

  • 用可重播行為做驗收:trace 同時係題目亦係計分機制,省咗另寫驗收邏輯。
  • 唔睇源碼、只睇效果:代理要靠互動參考 App 嚟推測行為。
  • 難度可調:還原深度愈深,要一齊修好嘅行為就愈多。
  • 規模化合成:26 個應用就整到四千幾條 SWE 任務。
  • 評估目標係還原效果,唔係程式碼樣相似唔相似。

對做編程代理嘅團隊,或者想練 SWE-bench 類型基準嘅人嚟講,呢套管線提供咗一個起點:由真實 Web App 自動生出一批可驗證、難度可控嘅任務,省卻人手逐條寫題目嘅工序。

項目主頁

Categories: 開源, Agentic, 微軟, 軟件, 編程, Dataset 數據集

Hypit:把爆款短片變成可換臉的模板

Hypit 是一套開源影片克隆工具,主打把 TikTok、Reel 或 Short 變成可重用的版面,換掉主持人、產品、開頭與長寬比,就能快速產出多個變體做投放測試。

Hypit

短片團隊最常遇到的卡位,是手上有一條跑出來的素材,卻要趕在疲勞前把它複製成十幾條變體測試新 Hook。Hypit 想解決的正是這個工序:丟一條影片進去,它會拆解成鏡頭、字幕、B-roll、效果這些可組合的工作流部件,而不是只輸出一份腳本分析。對做付費社交投放的人來說,這意味著可以從 Meta Ad Library 複製一條已經贏過的廣告,換掉商品與開場就當日出 50 條 Hook 變體;等兩星期素材疲勞,再用同樣的主體版型換新開頭,主體片段完全保留。

它和一般「AI 影片生成器」差別在定位:生成式模型負責補上會變的部分,Hypit 則是負責把會變跟不會變的部分拆乾淨、串起來。每個組件都能被替換或 fork,使用者不必動到字幕或剪輯邏輯。商業模式上,項目本身是開源(Apache-2.0 with conditions),沒有平台座位費或浮水印,模型服務費則看你接的是哪一家。

技術偏向給內容團隊或 growth marketer 自建的工程師整合進既有管線。素材來源涵蓋 TikTok、Reel、Short,也可以從 Meta Ad Library 抓一支跑得好的 paid ad 當模板。對需要大量 A/B 測試 hook、不同市場語言切版、或長線養帳號的工作流來說,這種「一次結構、N 次變奏」的思路,比每次從腳本重頭來要省事不少。

我用AI 10分钟复刻爆款视频:Hypit详细教程,直接拆成可编辑工程
  • 不是單次生成,而是變奏生產線:同一支片可以反覆換主播、產品、語言、長寬比
  • 組件化設計:字幕、B-roll、效果都能獨立替換,不影響整體結構
  • 開源但非全免費:項目本體免費、無浮水印;模型推理依賴外部服務計費
  • 適合 paid social 與 viral clone 場景:Meta Ad Library、TikTok、Reel 都能當模板來源
  • 技術門檻在整合端:需要 Node.js + TypeScript 環境,較適合有工程支援的團隊

GitHub

Categories: 開源, AI productions, Video, 工具, 庫, Skill 技能

Page 14 of 35
1 … 12 13 14 15 16 … 35