EntityBench 盯住長片一致性

EntityBench 用長篇多鏡頭影片測試模型能否跨鏡頭維持角色、物件與場景一致。

EntityBench: Towards Entity-Consistent Long-Range Multi-Shot Video Generation 不是在追求單段影片有多漂亮，而是在問一個更實際的問題：當同一個角色、物件或地點隔了很多鏡頭再次出現時，生成模型還記不記得它是誰。對做敘事型影片、分鏡式內容或長流程影片系統的開發者來說，這件事不是加分項，而是基本門檻。

這篇論文的核心主張很直接：現有影片評估，對「長距離一致性」這件事測得不夠。很多方法只看單獨生成的片段，或是用比較簡單的連貫性指標，結果很容易高估模型在長篇故事裡的實際能力。EntityBench 想補的，就是這個落差。

這篇在解什麼痛點

長篇、多鏡頭的影片生成，難點從來不只是畫面好看。真正麻煩的是，模型要在不同鏡頭之間維持同一個故事世界：角色長得要像同一個角色，物件要像同一個物件，場景回來時也不能整個走鐘。只要其中一項失真，觀眾就會感覺「這不是同一部片」。

論文指出，現有評估方式常常沒有把這種問題逼出來。若 prompt 是彼此獨立生成的，就不一定會要求模型記住前面的實體；若評分方式太粗，就可能只看到影片流暢，卻沒看出角色身份早就漂掉。EntityBench 的目的，就是把這種失敗模式明確攤開。

對開發者而言，這個差異很重要。測單一 prompt 的模型，和測能不能撐住一整段敘事流程，是兩種完全不同的工作。前者像 demo，後者才像產品。

EntityBench 怎麼設計

EntityBench 是從真實敘事媒體整理出來的 benchmark，不是把一堆無關 prompt 湊在一起。資料規模包含 140 集與 2,491 個 shots，整體結構更接近故事內容，而不是隨機片段集合。它還使用明確的 per-shot entity schedule，追蹤角色、物件與場景在整段序列中的出現位置。

這個設計讓「請記住這個實體」變成可評估的任務，而不是一句模糊要求。論文把 benchmark 分成 easy、medium、hard 三種層級，最長可到 50 個 shots；跨 shot 的角色最多 13 個，跨 shot 的場景最多 8 個，跨 shot 的物件最多 22 個。它也包含最長 48 個 shots 的 recurrence gap，也就是同一個實體兩次出現之間可以隔很遠。

這點很關鍵，因為一致性問題通常不是在角色下一秒就壞掉，而是隔得越久越容易失憶。EntityBench 把這種長距離回歸的壓力，做成明確的測試條件。

評估不是只看一個分數

EntityBench 不只是資料集，還搭配一套三層評估框架。這套框架把不同問題拆開，不讓它們混成一團。

• Intra-shot quality：看單一 shot 自己好不好。
• Prompt-following alignment：看模型有沒有照要求生成。
• Cross-shot consistency：看跨 shot 的實體能不能維持穩定。

另外還有一個 fidelity gate。只有實際渲染正確的實體，才會進入 cross-shot scoring。這個設計很實際，因為它避免模型在第一個 shot 就畫錯人，卻還被算成「跨 shot 很一致」。

對工程團隊來說，這樣的拆法很有價值。當結果不好時，你至少能知道問題是在畫面品質、prompt 對齊，還是長距離身份維持。沒有這種分層，除錯只會變成猜謎。

基線方法 EntityMem 做了什麼

為了展示 benchmark 的效果，作者提出一個基線系統 EntityMem。它的核心概念是記憶模組：在生成開始前，先把每個實體經過驗證的視覺參考存進持久記憶庫。這樣一來，模型不必每次角色或物件重現時都重新猜它長什麼樣。

這個想法其實很務實。長篇影片的一致性，很多時候不只是生成問題，也是記憶問題。如果系統能取回可信的角色參考圖，後面再生成時就比較有機會保住同一個視覺身份。論文把 EntityMem 當作 baseline，而不是最終答案，但它清楚示範了「顯式記憶」可以怎麼幫助長篇影片生成。

換句話說，這篇不是在說把模型再堆大一點就好，而是在暗示：你可能需要一個能記住故事世界的機制。

論文實際證明了什麼

作者最主要的發現，是現有方法在跨 shot 一致性上，會隨著 recurrence distance 增加而明顯退化。這就是 EntityBench 要抓出的核心失敗：兩次出現隔得越遠，模型越難維持同一個角色、物件或場景。

論文也指出，在評估過的方法裡，顯式的 per-entity memory 帶來最高的 character fidelity 與 presence。摘要中給出的角色 fidelity 效果量是 Cohen’s d = +2.33。除此之外，摘要沒有公開完整 benchmark 細節，所以沒有更多數字可以補充。

這個結果值得注意，因為它暗示長距離一致性不只是「畫得更好」就能解決。它可能需要明確的實體儲存與重用機制。對做多鏡頭影片系統的人來說，這代表架構設計可能要往 memory-aware 的方向走，而不是只靠 prompt 逐段接力。

對開發者的實際影響

如果你在做影片生成、敘事剪輯、分鏡工具，或任何需要角色反覆出場的系統，EntityBench 提供的是更接近真實使用情境的壓力測試。它測的不只是「能不能生成影片」，而是「能不能在長篇故事裡保持世界觀一致」。

它也讓失敗分析變得更清楚。模型可能因為單 shot 畫面品質差而失敗，也可能因為 prompt 沒跟上而失敗，還可能因為跨 shot 的身份記憶斷掉而失敗。EntityBench 的價值，就是把這三種問題分開看。

這對產品團隊特別重要。因為當你要把生成模型放進實際工作流時，使用者在意的不只是某一幀好不好看，而是前後鏡頭能不能對得起來。角色錯位、物件換臉、場景漂移，這些都會直接破壞敘事可信度。

不過，這篇摘要也有明確限制。它沒有把完整評估流程、所有指標細節，或 EntityMem 的泛化範圍講完整。摘要也沒有宣稱 memory 就是終極解法。它真正證明的是：長距離一致性確實會掉，而且顯式的實體記憶是一條值得走的方向。

如果把這件事放到更大的脈絡來看，影片模型正在從短 clip 走向長故事。當長度拉高後，難題就不再只是「會不會動」，而是「能不能記得前面發生過什麼」。EntityBench 做的，就是把這個問題變成可以量測、可以比較、也可以繼續改進的 benchmark。

對台灣開發者來說，這類研究的價值很實際。它提醒你，評估一個影片模型時，不能只看單段效果。只要產品有連續劇、教學流程、角色敘事、或任何需要重複出現實體的場景，就要把一致性當成核心指標，而不是事後補救。

也因為如此，EntityBench 的意義不只是一個新 benchmark。它是在幫整個領域重新定義問題：不是生成一段好看的影片，而是生成一個記得住自己的故事世界。