Mage-VL把视频Token壓到25%

以前我把視頻當圖片序列硬抽帧，現在我先看壓縮碼和事件，再決定要不要喂給模型。

我盯視頻模型這件事已經有一陣子了。最煩的不是模型不夠聰明，而是輸入太浪費：一段視頻先抽帧、再切塊、再喂進視覺編碼器，最後大半 Token 都在重複描述同一件事。你明明只是想讓模型看懂一個動作，結果管線像在給每一幀發薪水。更別提均勻抽帧這件事本身就很彆扭，關鍵瞬間常常漏掉，沒信息的鏡頭卻塞了一堆。最後你得到的不是更好的理解，而是更貴的理解。

這次把我拉回來的，是微軟在知乎上分享的 Mage-VL。我第一次看到這篇時，注意力其實不只在「少 75% Token」這句話，而是它怎麼把 caption prompt 當成一個可以反覆打磨的東西。原文把問題講得很工程：先讓評估 agent 找問題，再讓 prompt modifier 做最小修改，幾輪之後把 dense caption pipeline 調穩。這種做法很像我自己踩過的坑，模型不穩時，很多時候不是模型本體壞了，是前處理和標註鏈路太隨便。

別再把視頻當成一串平均值了

告別均勻抽帧，直接讀壓縮碼，Token 少 75%。

這句話是整篇最直接的地方。所謂「直接讀壓縮碼」，意思不是先把視頻完整解碼成一幀幀圖片，再做視覺處理，而是盡量從壓縮視頻流裡拿信息。也就是說，模型不必先把所有像素都復原出來，再自己想辦法刪掉沒用內容。

我以前做多模態管線時，最常見的錯誤就是默認「視頻=圖片序列」。這在原型階段很方便，但一旦上量，成本就開始發瘋。更糟的是，均勻抽帧有一種表面公平感：每隔 N 帧取一張，看起來很規範，實際上對動作類、事件類視頻非常不友好。關鍵動作可能只持續 0.5 秒，你偏偏沒抽到；長鏡頭裡無聊的靜態畫面卻被抽了很多張。

我會把這件事理解成兩層收益。第一層是速度和成本，少 Token 直接減少計算。第二層更重要，輸入更貼近視頻原始結構，模型拿到的是更有信息密度的表徵，而不是被抽帧策略稀釋過的近似樣本。

如果你要落地這個思路，我會先問三個問題：視頻裡真正有信息的片段是不是集中在少數時刻？你的任務是動作識別、事件理解，還是靜態檢索？你是不是只是因為「大家都這麼做」才抽帧？如果答案偏向前兩項，那就該認真考慮壓縮域輸入、關鍵幀選擇，或者至少用內容感知的採樣替代純均勻採樣。

• 先統計你現在視頻管線的 Token 分布，看看是不是大頭都浪費在重複畫面上。
• 把均勻抽帧改成事件驅動採樣，哪怕只是先做一個簡單的鏡頭切分。
• 如果你的模型棧允許，盡量保留壓縮視頻中的結構信息，而不是一上來就全解碼。

省 Token 不等於少看，關鍵是看得更像人

Mage-VL 這類工作最容易被誤讀成「只是為了省算力」。我不這麼看。省算力只是表面結果，真正值錢的是它逼你重新思考：模型到底需要看到什麼，才算真的理解視頻。

人看視頻時也不是逐像素處理。我們會盯動作變化、物體關係、鏡頭切換、聲音線索、字幕線索。模型如果還在死啃均勻抽帧，本質上就是在用最笨的方式模擬觀看。直接讀壓縮碼的價值在於，它更接近視頻編碼本身攜帶的時序和運動信息，而不是把視頻先拍扁成圖片再補救。

我在做檢索系統時也遇到過類似問題。早期我們瘋狂加特徵，最後發現最有效的不是再堆一個特徵頭，而是把無效輸入減掉。視頻任務更明顯，因為原始數據就更貴。你每多抽一帧，都是在給後面的注意力層加負擔。

如果你要把這套思路搬進自己的項目，我建議別一上來就追求「完全不解碼」。先做一個中間版本：保留壓縮流中的時間結構，減少無信息帧的展開，再觀察任務指標和延遲的變化。很多時候，工程上最實用的不是最激進的方案，而是能穩定上線的那一檔。

還有一個現實問題：視頻任務的評估經常只看最終準確率，忽略輸入成本。這個習慣很糟。你應該把 Token 數、延遲、吞吐一起看，不然很容易把一個昂貴的模型誤判成「更強」。

caption 不是標註完就完了，它本身就是產品

我最想拆的，不是視頻編碼，而是他們對 caption 的處理方式。很多團隊做 dense caption 時，默認流程是：寫個 prompt，批量跑一遍，覺得差不多就收工。問題是，這種 prompt 往往是一錘子買賣，後面出了問題只能靠人工補洞，越補越亂。

這篇分享裡提到的做法更像我願意接受的工程流：把 caption prompt 當成可迭代對象。先用評估 agent 去找問題，再讓 prompt modifier 做最小修改，多輪驗證後再定版。這流程聽起來很朴素，但我覺得它比「多加幾條規則」可靠得多。

也就是說，他們沒有把 prompt 當成靈感產物，而是當成配置文件。配置文件就該能測、能改、能回滾。你今天覺得某個描述方式不錯，明天數據一變它就可能失效。把 prompt 交給評估閉環，才不會一直靠拍腦袋。

我以前也很討厭這種「先寫再說」的 caption 方式。尤其是 dense caption，文本一長，問題就開始變複雜：有的句子太泛，有的句子重複，有的句子把背景寫得比主體還多。人工看幾條樣本會覺得沒問題，一跑到全量就露餡。評估 agent 的價值就在這裡，它可以系統地把壞例子撈出來，而不是等你在 demo 現場翻車。

怎麼應用？我會把 caption 流程拆成三步：生成、評估、最小修訂。生成階段先別追求完美；評估階段專門找空泛、重複、漏檢、錯位；修訂階段只改最小必要部分，不要每輪都重寫 prompt。這樣你才能知道到底是哪一條改動帶來了改善。

• 把 caption prompt 版本化，像代碼一樣管理。
• 單獨保存失敗樣本，別讓它們淹沒在平均分裡。
• 每次修改只動一個變數，不然你永遠不知道是誰起了作用。

評估 agent 的角色，不是判官，是挑刺的人

我很喜歡「評估 agent」這個位置安排。它不是來宣布誰對誰錯的，而是來找毛病的。這個區別很重要。很多自動化評估系統一上來就想給最終分數，結果分數看著漂亮，問題一個都沒抓住。

在 caption 這種任務裡，真正有用的評估往往不是一句總分，而是具體指出：哪裡寫得太空、哪裡漏了動作、哪裡把物體關係說反了。只有這樣，prompt modifier 才知道該怎麼改。否則你得到的只是「效果一般」，這句話對工程沒有任何幫助。

我自己做過類似的閉環，最開始也犯過錯：讓評估模塊輸出太多維度，最後沒人知道先改什麼。後來我學會把評估結果壓成幾類高頻問題，比如「主體缺失」「動作不明確」「背景噪聲過多」「時序錯亂」。這就足夠了。你不需要十幾個評分維度，你需要的是能驅動下一輪修改的診斷信息。

如果你也要搭這個東西，我建議評估 agent 先回答三個問題：這條 caption 是否覆蓋了核心事件？是否把次要信息寫得過頭？是否存在明顯幻覺或錯配？這三項已經能篩掉大部分垃圾輸出。等系統穩定了，再考慮更細的指標。

還有個工程上的小脾氣：別讓評估 agent 變成另一個黑箱。它的輸出最好是可讀的、可追蹤的、可對比的。否則你只是把人工挑刺換成機器挑刺，麻煩一點都沒少。

最小修改，比大改更像真正的迭代

「prompt modifier 做最小修改」這點，我覺得特別對。很多人一看到問題就想推倒重來，結果每輪都改太多，最後連自己都不知道哪句 prompt 真的有效。最小修改的好處是可解釋，壞處是慢一點，但我寧願慢一點，也不想在錯誤方向上狂奔。

這句話翻成工程語言就是：你要把 prompt 當成實驗對象，而不是創作對象。實驗對象的修改原則是盡量少動，保證因果關係清楚。這樣你才能積累出一套穩定的經驗，而不是一堆互相打架的「我感覺應該這樣寫」。

我以前做提示詞調優時，最常見的失敗模式就是「越改越長」。一開始只想補一個約束，後來變成一大段說明書。結果模型確實更聽話了，但也更僵硬了。最小修改的思路能避免這個問題：只補缺口，不重寫邏輯。

實際操作上，我會把 prompt modifier 的職責限制得很窄：只允許改動一個句子、一個約束、一個順序，或者一個示例。然後每輪都保留 diff。這樣你能很快看出哪些改動是有效的，哪些只是心理安慰。

如果你團隊裡有人喜歡「一次性把 prompt 寫到完美」，我建議你直接拿失敗樣本給他看。讓他看看大改之後指標為什麼飄，通常比講道理有效得多。工程不是作文比賽，改得漂亮不等於改得對。

我會怎麼把這套思路搬進自己的項目

如果是我來復刻 Mage-VL 這類思路，我不會先急著追論文裡的全部細節。我會先搭一個小而穩的版本：輸入側減少無效 Token，caption 側建立評估閉環，修改側堅持最小變更。三件事同時做，系統才不會只在演示裡好看。

第一步是看輸入。你要知道自己到底在為哪些帧付費。第二步是看 caption。你要知道文本裡哪些信息是穩定有用的，哪些只是噪聲。第三步是看迭代。你要知道每一次修改到底改善了什麼。只要這三件事跑通，後面再談更複雜的壓縮策略和更細的對齊方式，才不會空中樓閣。

我特別建議把這套流程做成可復用模板，而不是一次性腳本。因為只要你開始接新數據集、新任務、新 caption 風格，臨時拼的流程就會開始掉鏈子。模板化之後，團隊裡不同人接手也不會完全失控。

最後說句實話：很多多模態項目失敗，不是模型不行，而是輸入、標註、評估三件事沒有連起來。Mage-VL 這篇分享最有價值的地方，不只是「少 75% Token」，而是它提醒我，真正能省下來的，往往是那些原本就不該喂給模型的東西。

可抄的模板

# Mage-VL-style video caption iteration template

## 1) Input policy
- Do not rely on uniform frame sampling by default.
- Prefer compressed-domain features or event-aware sampling.
- Track token budget before and after any change.

## 2) Caption generation prompt
You are writing dense video captions.
Focus on:
- main actor or object
- main action or event
- important temporal changes
- visible scene context only when it helps disambiguation

Avoid:
- repeated background descriptions
- vague filler like "the scene shows"
- over-explaining obvious details
- hallucinating unseen actions

## 3) Evaluation agent prompt
Review the caption and report only actionable issues.
Return a short list with labels:
- missing_subject
- missing_action
- temporal_error
- redundant_detail
- hallucination
- weak_specificity

For each issue, include:
- exact problematic phrase
- why it is a problem
- one minimal fix suggestion

## 4) Prompt modifier rules
When revising the caption prompt:
- make the smallest possible change
- change only one rule at a time
- keep a diff log
- do not rewrite the full prompt unless the structure is broken

## 5) Iteration loop
repeat until stable:
1. generate captions
2. evaluate failures
3. apply one minimal prompt change
4. rerun on the same validation set
5. compare token count, error rate, and caption quality

## 6) Decision rule
Keep a prompt change only if it improves:
- coverage of key events
- reduction of hallucination
- caption specificity
- stability across samples

If a change helps only on a few examples but hurts generalization, revert it.

這份模板不是原文照搬，是我把這次分享拆成能直接上手的工程版本。你可以先拿它跑一個小驗證集，再慢慢把輸入側的壓縮碼方案和 caption 評估閉環接進去。

原始來源是知乎專欄文章 《微軟 Mage-VL：告別均勻抽帧，直接讀壓縮碼，Token 少 75%》。我這裡做的是基於該文公開內容的工程化拆解，模板部分是我重新整理後的可複製版本，不是原文照搬。其他權威參考可看 Microsoft、GitHub 與 arXiv。