【2026 最新】StreamEval 教學：用 CPU Mock 看懂互動影片修改、保留與時間對齊

你看著一段正在播放的影片，輸入「把外套變紅」，人物確實變紅了，背後的招牌卻一起換字；另一段背景保住了，修改卻晚了好幾秒。StreamEval 教學要帶你看懂的，就是這些被「畫面很順」掩蓋的差別。

這篇寫給第一次接觸影片評測的讀者。先用白話拆開考卷，再走一個免 GPU、免模型 API Key 的 CPU Mock（程式替身）案例；動手部分需要 Git、Python 與終端機。你最後要能拿事件時間線、輸出影格和判分欄位對帳，而不只是看到安裝成功。

本文於 2026 年 10 月 23 日核對官方論文與程式，固定提交 253a1f30f9c43f9f6ccf0fab93ac8abd689caf5e。AlphaLab 已以 Python 3.12.13 跑完下列合成案例及紀錄驗證；本次未呼叫真實影片模型或自動評審。

先說結論：何時要改、改對什麼、什麼要留

互動影片評測＝何時要改＋改對什麼＋什麼要留。把它想成現場換布景：導演臨時喊「換紅外套」，演員要在指定時點換對衣服，桌子、人物身分和正在發生的動作也要接得上。漂亮的單張截圖，只回答其中一部分。

• 先看每個事件的實際釋出時間，再找正確效果首次穩定出現的位置。
• Following 看指定操作與目標；Edit Success 還要一起滿足期限、範圍、狀態、穩定效果與保護要求。
• Preservation 對照同一來源時間的非目標內容與動作；別拿不同時間的畫面硬比。
• Mock 用來檢查接線與證據；正式模型比較還要固定輸入路徑、評審與完整考卷。

一、StreamEval 教學先拆五個零件

StreamEval 論文於 2026 年 10 月 20 日提交，研究的是生成過程中持續收到新要求的影片。論文列出五種任務、300 道腳本案例，長度為 15–300 秒；這是作者的評測設計，不是保證任意影片服務都適用的一張通用排行榜。

• ①「工作單」cases.jsonl：放初始化資料、事件內容和釋出規則。它描述何時發什麼，不是把整張時間線先交給模型。
• ②「答案本」oracles.jsonl：放預期結果、時間窗與要保護的內容，只給評測端使用。
• ③「素材清單」manifest.json：把素材路徑、類型及 SHA-256 雜湊綁在一起；雜湊像檔案指紋，用來確認拿的是同一份素材。
• ④「場務」Harness：等系統準備好後，依時鐘逐步放入要求，並保存輸出和收件紀錄。
• ⑤「裁判」Judge：從留下的證據做結構化觀察，再由固定規則算分；收到指令的回報不是裁判結論。

官方資料格式明確區分前三種檔案。看整份案例的人是可信排程器；模型只應收到已到時間的輸入。若提前把答案本和後面指令一起餵給模型，就像讓考生先看答案，測到的能力已經變了。執行層的背景可接著讀 Agent Harness 是什麼。

二、先看一題：0 秒修改，5 秒重設

官方 合成案例程式會自行產生測試素材。這次選 sa.v1.901.instruction_edit：總長 15 秒，e000 在第 0 毫秒送出「Make the square red.」，e001 在第 5,000 毫秒送出「Reset the square.」。這是安裝與軟體檢查用案例，與正式論文考卷分開。

要特別注意：素材由 FFmpeg 測試圖樣產生；這個簡化答案本只寫「要求的變化可見」。它適合看事件如何被釋出，並沒有替你準備一套完整、已校準的紅方塊語意評測。初學時先把「輸入文字說什麼」和「替身實際會做什麼」分開。

MockModel 的實作在編輯任務中沿用最新來源影格，收到事件後依事件 ID 產生色調、邊框和文字標記。它沒有在這條路徑解析「紅色」或執行語意上的重設。因此兩個事件都回 applied，仍不足以證明外套改對、背景保住或重設成功。

三、StreamEval 教學實作：CPU 跑一題，再打開收據

第一步「固定考場」：準備隔離環境

先以 python3 --version 確認 Python ≥3.10，並確認 Git 可用。下列以已安裝 Python 3.12 的 macOS／Linux 為例；其他符合版本可替換建立環境那行的執行檔。請使用新的練習資料夾，先讀取取回的 README 與套件設定，再安裝。

git clone https://github.com/StreamEval/StreamEval.git streameval-lab
cd streameval-lab
git checkout 253a1f30f9c43f9f6ccf0fab93ac8abd689caf5e
python3.12 -m venv .venv
source .venv/bin/activate
python -m pip install -e ".[runtime,judge,dev]"

這份 官方 CPU 入門不用下載完整 benchmark，也不用設定供應商金鑰。安裝仍會下載 Python 依賴與 FFmpeg 套件；「免 GPU」指這個替身案例的運算路線，並不代表後續所有模型評測都只用 CPU。

第二步「開小考」：產生素材、執行、驗證

python -m streameval.benchmark.synthetic --out .smoke
streameval run --model streameval.models.mock:MockModel --track instruction_edit --case sa.v1.901.instruction_edit --benchmark .smoke/set --data .smoke/data --out .smoke/attempt
streameval validate-run .smoke/attempt --benchmark .smoke/set --data .smoke/data

第一行產生五種合成案例及素材；第二行只跑剛才那一題；第三行核對 attempt（一次執行資料夾）的結構與證據。.smoke 必須不存在或為空；要重跑時換成新的輸出目錄，保留上一輪。本站這次結果為 status: completed，收到 397 張輸出影格；驗證為 attempts: 1, invalid: 0。

第三步「查三張收據」：時間、回報、畫面

依 官方 run contract，先打開 .smoke/attempt/result.json。讀 scheduler.opportunities，把每筆 released_at_ns 減去 started_at_ns，再除以一百萬得到毫秒。本次兩筆約為 0.025 與 5,000.010 毫秒；這是輸入釋出時點，不是正確修改的反應延遲。

再看 dispatch 的事件 ID 與 ack，確認送出的 e000、e001 都有回報。最後開 browser/frame_samples.jsonl，沿每列的 case_ms 與 path 找到 browser/frames/ 裡的 JPEG。先確認標記換了，再問它是否真的符合原指令。

本次留下 60 張抽樣影格；同時 source_push_stats.dropped_late 為 174，表示部分來源影格因遲到未按原計畫推送。這輪仍通過資料夾驗證，正好說明結構有效、來源推送品質、語意結果是三項檢查。397 張不能拿來宣稱模型 FPS，也不能據此比較真實服務延遲。

另外執行官方完整測試，結果為 56 項通過、1 項失敗；失敗項目取得 215 筆來源影格，未達測試要求的超過 300 筆。這是本機這次執行的來源推送門檻未過，沒有完成即時輸送品質驗收；排查效能前，先保留這份失敗紀錄。

四、三種結果怎麼讀？改對、太晚、誤改分開看

下面是自訂判讀練習，並非官方案例或模型成績：第 2 秒要求把外套改紅，期限設為第 4 秒；背景招牌與人物動作需要保留。先寫好這張答案，再看片。這也延續了 AI Evals 教學 的原則：成功條件先於成果。

• A「準時且乾淨」：第 3 秒起外套穩定變紅，招牌與動作符合來源。你有理由往編輯成功核對，仍需逐項檢查目標、範圍及狀態。
• B「改對卻太晚」：第 4.5 秒才出現正確效果。即使之後看起來很漂亮，已錯過這題期限，Edit Success 不能通過；Following 則依它自己的事件觀察窗判斷，不能直接套用另一欄結果。
• C「外套紅了，招牌也變了」：第 3 秒完成外套修改，卻破壞保護內容。這影響 Preservation，也使要求保留內容的 Edit Success 失敗；只盯衣服會漏掉它。

Following 可白話讀成「有沒有對指定目標做指定操作」；Edit Success 是「整張修改驗收單是否一起過關」；Preservation 是「不該動的內容與來源動作是否保住」。三者的評估單位與要求不同，所以不能把它們互相替代。確切定義可對照 官方指標協定。

時間對齊尤其容易看錯。來源第 8 秒人物轉頭，你拿輸出第 8 秒去比來源第 0 秒，自然可能看起來不同。官方會記錄來源時間並考慮量得的處理落差；重設時要回到當下正在前進的來源，而非開場的靜止照片。遇到異常，先查對應來源影格，再說是否遺失動作。

五、五種任務各自讀分，別混成全能冠軍

StreamEval 的內容指標採 0–100 分，但適用欄位隨任務改變。下圖把英文欄位翻成中文閱讀提示：「跟隨」是 Following、「編輯成功」是 Edit Success、「保留」是 Preservation；參考相符、身分與連續性則各有自己的檢查對象。

Overall 只平均該任務適用的內容指標。文字條件世界生成與圖片條件世界生成的欄位就有差別；不同任務的 80 分，不能直接讀成同一種能力。正式彙整還會依重複執行、條件與五個時長層逐層平均，不是把所有影格丟進同一桶計數。

缺證據也不能悄悄刪題。協定保留必要機會在分母中；缺必要輸出計零，尚無法完成判讀的項目以 unresolved 留下，顯示值依規則形成下界。它不等於「已證實全部失敗」，也不是信賴區間。讀分時同時問：總共有幾次機會，完成多少觀察，哪些仍待判讀？

六、什麼時候才需要真模型、GPU 或付費評審？

若目的只是理解案例、時間戳與檔案關係，先停在合成 Mock。若你要回答某個模型能否照時完成編輯，就要接真實模型，並依 該 adapter 的部署與授權要求準備已有權使用的硬體或服務；GPU、自架成本與託管 API 費用，取決於選的系統。

自動評審是另一筆工作。官方量測有效性章節明說，軟體 smoke tests 不能建立評審有效性；應針對完全相同的模型、提示、抽樣與規則獨立驗證。判錯的裁判會把漂亮數字算得很精確，仍然判錯。先用你能人工核對的正確、延遲與誤改樣本校準，再談排名。

真正比較時，另存模型版本、輸入轉換、觀察端點、評審設定、案例與重複次數。官方把送入音訊、文字、參考圖等路徑分開聲明；經轉換的輸入不能只因任務名稱相同就視為完全等價。分階段執行指南也區分採集、評審、組裝與彙整，讓你知道費用和失敗發生在哪一步。

素材同樣先分層：這次練習使用自行產生的測試圖；正式 benchmark 包含有各自授權的第三方來源影片。若要公開編輯輸出，先按 官方素材署名清單核對對應檔案，保留所需作者、來源、授權與修改說明。先選自己有權處理的素材，也讓送往評審的畫面範圍保持清楚。

常見問題：八個直接答案

1. StreamEval 是幫我生成影片的 App 嗎？

本篇使用的是評測工具鏈。影片由接入的系統產生；它負責安排輸入、留下證據並依規則評估。

2. 一定要有 GPU 才能開始嗎？

不用。官方合成素材與 Mock 走 CPU；換真模型時，再依該系統要求準備資源。

3. validate-run 通過，就能說修改成功嗎？

不能。它核對紀錄契約與證據完整性；原指令是否做對，還需要內容判讀。

4. applied 就是模型答對了嗎？

不是這個結論。它是事件回報；本篇 Mock 對不同文字採同一套事件覆色邏輯。

5. 改對但晚一秒，能算成功嗎？

先看那題期限。Edit Success 明確要求符合 deadline；主觀覺得還能接受，不能改掉事先的考卷。

6. 背景變了，一定是模型破壞嗎？

先對齊來源時間。來源本來就在動；比較相應時點與宣告的保護內容，才知道是否誤改。

7. 哪個 Overall 最大，就選哪個嗎？

先對同任務與輸入條件。再看你必要的指標、缺失證據、評審校準與使用成本，別跨考卷直接排序。

8. 跑一題就能替產品下結論嗎？

先把它當理解工具的起點。正式選型要有代表性的案例與失敗樣本，並固定相同條件重複測試。

給新手的三個重點

• 先看事件何時真的送出，再找正確效果；不要把 ack 的時間當成成功時間。
• 每次修改同時問目標、期限與保護內容，並用相應來源時間查畫面。
• 先驗資料流，再驗模型，最後驗裁判；每一層都保留能回看的證據。