OneStreamer：直播 AI 如何先記證據、再決定何時回答？（2026）

2026 年 10 月 1 日，南京大學等機構的研究團隊在 arXiv 發布了論文 〈OneStreamer: Unifying Perception, Memory, and Proactive Response in Streaming Video Interaction〉。OneStreamer 想解決直播 AI 的一道難題：畫面還在流動時，它必須先留下未來可能有用的證據，卻不知道稍後會有人問什麼。這篇先還原論文的設計與數據，再檢查比較方式和失敗案例，最後談它適合被拿來驗證什麼。

OneStreamer 要解決的，是問題來之前的記憶

想像攝影機掃過一間屋子，三分鐘後有人問：「孩子在哪裡可以看書？」答案也許是早已離開畫面的那張小黃桌。只保留最近幾秒的影像會忘掉它；把整段影片的視覺 token 都留下，又會擠占當下畫面的處理空間。論文把這個取捨寫得很直接：

The challenge is to form reusable factual memory without compromising real-time perception.

中文：難點在於建立可重用的事實記憶，同時不犧牲即時感知。

OneStreamer 論文摘要

OneStreamer 的做法是把「看見什麼」先寫成有時間位置的文字紀錄，再把近期影像與先前紀錄一起交給模型回答。這是可追溯到畫面區間的壓縮描述，並不是把每一幀原封不動存下來；它的價值與風險都從這裡開始。

模型如何一邊看、一邊決定何時說話

兩層文字記憶：細節與事件摘要

論文稱這套機制為 PHCM。</Observe> 寫下短片段中的物件、動作與變化；</Summary> 概括已經完成的事件。兩者都應只根據當下已看見的影像產生，並標上來源時間。當舊影格離開近期視覺視窗，文字仍留在對話歷史裡，供後續問題使用。這比「等問題來了才回頭找影格」更早做選擇：當下沒記到的細節，後來就可能無從找回。

等待也要學，但不能讓「保持沉默」主宰訓練

另一部分 PSTL 管的是輸出時機。模型可產生 </Silence> 繼續觀察、</Standby> 表示相關證據正在出現但尚不足夠，或用 </Response> 開始回答。影片裡需要等待的時刻遠多於需要答覆的時刻；團隊因此保留每個啟動輸出的訓練位置，並抽選具有代表性的狀態轉換與持續位置。其餘狀態 token 仍在序列中，只是不計入狀態損失；答案文字的監督並未被一起刪掉。

訓練資料也按「當時可見的證據」安排文字與回答時間。作者把自建串流標註及清理過的開源資料合成 OneStreamer-1M，論文附錄列出 1,160,004 筆訓練紀錄，分成感知與記憶問答、主動互動、主動問答和文字記憶四類。這個數字是紀錄筆數，不能讀成 116 萬支獨立影片。模型從 Qwen3-VL-4B-Instruct 初始化，論文報告用 32 張 H200 訓練一個 epoch；成績反映的是整套資料與方法的組合。

八項第一的說法，範圍到哪裡？

在論文的主表中，OneStreamer 的 4B 模型在八個評測的已列比較方法裡都取得最高彙總分。下表保留原表的原生量尺；ViSpeak 是 0–5 分，其他欄位也各有自己的任務與評分方式，不能把八個數字直接相加當成一個總能力。

評測	OneStreamer	Qwen3-VL 基底
OVOBench	72.1	58.8
StreamingBench Real-Time	86.9	81.8
OVBench	66.8	55.4
ODVBench	71.3	57.6
ProactiveVQA	48.7	34.3
OmniMMI	36.6	29.4
OVO-Timing	41.6	29.4
ViSpeak	2.87	2.41

兩組消融更能檢查機制。相同 checkpoint 與近期 16 影格設定下，保留自動寫出的紀錄，把 OVOBench 的 Backward ASI 從 63.5 提到 71.6；另一個回溯指標 EPM 只從 62.0 到 62.6，而且仍低於保留完整視覺歷史的 63.0。PSTL 在只監督 27.5% 標註狀態 token 時，三個主動回應評測都勝過論文列出的密集監督與等量隨機抽樣。這些數據支持「哪些狀態值得教」與「先寫記憶再回答」值得繼續研究，還不足以宣稱每一種舊事細節都能穩定記住。

評測邊界也要讀進來：作者的附錄說，比較模型有些沿用原論文報告分數，有些由團隊用公開 checkpoint 重跑；OneStreamer 則依各評測採不同的影格率、視窗與任務設定。SimpleStream 的獨立論文提醒，單純的近期影格視窗已能在某些串流評測得到強成績，記憶模組必須在可比設定下證明增益。OneStreamer 的同 checkpoint 消融正朝這個方向做，但跨模型的「八項第一」仍應讀成作者在指定比較表中的結果，不是外部驗證過的通用排名。

最值得看的反例：記錯之後，誰來改？

論文附錄主動展示了一個失敗案例。模型在 00:10 說有人「正在關上印表機」，影像其實顯示上蓋被掀開；後續 00:11–00:13 畫面更清楚，它卻保持沉默，沒有在展示的序列裡修正先前說法。這個反例比一個漂亮總分更能指出系統缺口：文字紀錄只會保留模型以為自己看見的事，不會自動變成不可錯的證據。

AlphaLab 的判讀：把「記得」拆成三件事

記錄覆蓋率比記錄容量更關鍵

只要文字是不可逆的壓縮，漏掉的顏色、方位或先後順序就不會因為保存更久而回來。真正要測的是：在不知道未來問題時，系統能留下多少日後用得到的細節？因此部署前需要故意延後發問，拿未見過的物件和時序問題測遺漏，而不是只測影片播放當下的回答。

回答時機需要「可回頭更正」

等待到證據足夠才答，確實比逢畫面就出聲更有用。但一旦答錯，下一秒的新影像可能推翻舊結論。印表機案例說明，回應控制若只學會何時首答，仍缺少「發現矛盾、撤回並改答」的明確評測。監控、穿戴式助理或即時協作場景都應把更正率與更正延遲列入驗收。

速度數字要連同測試條件看

論文在一段 360 秒影片、單張 H200 的線上記憶測試中，PHCM 平均每秒更新耗時 0.636 秒，低於其一秒輸入間隔；另有答案階段的首 token 時間 0.124 秒，但那個數字使用已預先算好的文字記憶。兩者不能拼成「所有現場設備都能 0.124 秒回應」。換長影片、多路鏡頭或不同硬體，仍需重新測量吞吐量、記憶增長與漏答。

我同意作者把感知、先記證據和等待回答放進同一個訓練問題，也同意同 checkpoint 的記憶消融提供了比單一排行榜更好的線索。我存疑的是把文字記憶稱為可靠事實紀錄的語氣：它可能漏記，也可能像印表機例子那樣留下錯誤，後續沒有自動修正。

接下來該怎麼看 OneStreamer

如果你在評估串流影片代理，先設三道驗收題：隔一段時間再問，看它是否仍能指出原本的畫面證據；放入容易混淆的動作變化，看它會不會承認與修正錯答；把同一段測試搬到實際硬體，分開量記憶寫入與回答延遲。研究團隊已公開程式與評測說明，讀者可以從設定與原始評測表追查數字；本文並未執行模型或獨立重現八項成績。