【2026 最新】AI 影片偵測器還可靠嗎？RA-Bench 壓縮穩健性與 False Positive 教學

你把同一支真人影片丟進 AI 影片偵測器，原檔顯示「像真人」，上傳平台再下載後卻突然被判成 AI。影片內容沒有換人，變的是壓縮、尺寸與幀率；如果偵測器跟著翻盤，問題就不只是「準不準」，而是它能不能承受真實世界的傳播流程。

這篇專為第一次做評估的讀者而寫。文中的 benchmark 數字都明確歸因於 RA-Bench 作者與指定版本，不改寫成本站自行執行的結果；你會學會如何用自己的合法素材，依官方規格設計一個小型、成對、可追溯的壓縮穩健性檢查，並看懂 false positive（誤把真人判成 AI）究竟怎麼發生。

先說結論：原檔準，不等於上線後可靠

• 小型實驗的用途是抓脆弱點，不是替偵測器頒發證書。樣本太少時，一個誤判就會讓錯誤率大幅跳動。
• 同一門檻、同一批影片、real／generated 做相同退化。否則你測到的可能是資料處理差異，不是生成痕跡。
• 一定要報 false positive。只看 accuracy（準確率）或 AUC，會藏住真人創作者最在意的傷害。
• 偵測分數只適合分流複查。它不能單獨證明作者、生成器、動機，甚至不能證明畫面中的事件真假。

先記住本文的核心公式：

可信的 AI 影片偵測器評估 ＝ 成對資料 × 固定門檻 × 相同退化 × 錯誤案例回看

把偵測器想成機場安檢門：它可以提醒你「這個要再看」，但警報本身不是判決。真正的目標，是在盡量少攔錯真人影片的前提下，仍抓得到多少生成影片。

RA-Bench 為什麼讓 AI 影片偵測器重新被檢查？

截至 2026 年 8 月 17 日，RA-Bench v2 預印本收錄 17,886 支危機事件影片：1,830 個真人 anchor（可理解為配對的真實基準）與 16,056 支由 9 個影像轉影片生成來源製作的影片。它刻意讓 real 與 generated 共享語意內容，減少偵測器只靠「題材不同」作弊的空間。

其中 LastMile 測試更貼近「影片在網路上走一遭」。依指定版本的 repository manifest，T0 是標準化原檔、不再額外編碼；T1 是 VP9 CRF 36 再轉 H.264 CRF 28（medium）；T2 是縮小到 0.5 倍後走 T1；T3 是改成 8 fps 後走 T1；T4 是加入 AP-style 合成新聞角標後走 T1；T5 則把縮放、8 fps、角標與 T1 全部組合。論文表格把六欄標成 Original、T1、T1+T2、T1+T3、T1+T4、Full；它們是六個分開比較的配對條件，不是把同一檔案依欄位一路反覆加工。實體 manifest 每個條件有 1,650 列：150 支 real、1,350 支主 benchmark generated，另加 150 支不納入 benchmark 平均的 auxiliary_control generated。所以上述論文主比較每個條件是 1,500 個影片實例，六個條件共 9,000 個；若連 auxiliary control 一起盤點，實體列數則是 9,900。這是受控模擬，不等於任何一家平台的實際上傳與轉碼管線。

RA-Bench 作者報告，七個傳統偵測器的來源等權平均 AUC 從 Original 的 51.4 降到 Full 的 47.3；在 FPR 不高於 5% 的 ROC operating point，平均 TPR 從 5.7% 降到 2.8%。五種微調後多模態模型設定的 FakeR——也就是生成影片中被判為 generated 的比例——則由各列等權算術平均的 46.0% 降到約 1.4%。但個別模型反應並不一致：D3 的 AUC 反而從 49.3 升到 54.1，TPR@FPR≤5% 也從 4.4% 升到 5.4%；這仍是接近隨機的排序與很低的 operating-point recall，不能解讀成實務可靠性獲得證明。因此正確結論不是「壓縮一定讓每個偵測器變差」，而是排名、門檻與退化方式會互相作用，不能拿單一原檔分數外推。

官方公開媒體清單約 93.8 GB；經權利審查後，1,319／1,830 個真人 anchor 隨檔案提供，另外 511 個只留來源 URL。所以下面的練習以自有素材為主。若你要使用 RA-Bench 公開資料，請依官方逐筆標記查看 rights 與 release mode，不能把「可下載」直接等同「可任意重製」。

先懂 4 個指標：別再只看 accuracy

① Confusion matrix：四格錯誤帳本

把 generated 當正類：TP 是成功抓到生成影片，FN 是漏掉生成影片，TN 是正確放過真人，FP 則是誤傷真人。對創作者而言，FP 往往比抽象的總準確率更有感。

② Recall／TPR：生成影片抓到多少？

TPR = TP ÷ (TP + FN)。TPR 高代表漏網少，但如果你把門檻降得太低，也可能把大量真人一起攔下。

③ FPR：真人有多少被誤傷？

FPR = FP ÷ (FP + TN)。NIST AI 100-4整理指出，有專家主張 accuracy、F1 或 AUROC 未必能呈現關鍵傷害，也有研究偏好查看指定低 FPR 下還剩多少 TPR；文件同時強調，門檻與指標是否足夠取決於使用情境。若你的政策門檻是 1%，TPR@1%FPR就是在該 operating point 檢查 TPR，而不是放諸四海皆準的標準。

④ Precision：收到警報時，真的有多少是 generated？

Precision = TP ÷ (TP + FP)，而且會被母體比例影響。以下是假設算術，不是任何平台的 AI 影片占比：若 10,000 支影片只有 1% 是 generated，偵測器 TPR 80%、FPR 1%，會得到 80 個 TP，卻也有 99 個 FP；警報的 precision 只有 44.7%。

AUC 則是在所有門檻上衡量排序能力，不是 accuracy，也不是「這支影片有 83% 機率為 AI」。除非偵測器另做過符合使用情境的機率校準，請把輸出叫做 score（分數），不要叫 probability（機率）。想更完整理解評估思維，可以先讀 AlphaLab 的AI Evals 新手指南與模型排行榜判讀教學。

AI 影片偵測器壓縮測試：6 步小型流程

第 1 步：把問題寫成能被推翻的假設

痛點：「這個 detector 很準」沒有條件，也就無法驗證。解法：先寫成：「在門檻固定後，經 T1 重編碼、T2 縮放與 T3 改幀率，真人 FPR 不高於 X，generated TPR 不低於 Y。」X、Y 應來自你的實際風險容忍度，不要看完測試結果才回頭挑漂亮數字。

第 2 步：做一個有 provenance 的配對小集

痛點：真人全是手機直拍、generated 全是網路下載，偵測器可能只學會容器、解析度或幀率。解法：先用你有權使用的日常場景做 20 組 anchor；每組保留一支自攝真人片，以及用同一場景起始影格、在允許用途的生成服務製作的影片。危機、犯罪或真人肖像不是練習所必需。

建立 manifest.csv，至少記錄 clip_id, anchor_id, label, source, model_version, created_at, rights, sha256。同一 anchor 的所有版本只能落在同一個 split，否則 train／calibration／test 會互相洩漏。這與C2PA 與內容來源證明的核心觀念相通：先保留「它從哪裡來、經過什麼」，再談偵測。若你想比較另一種訊號，也可延伸讀文字浮水印的限制。

第 3 步：先跑 Original baseline，凍結設定

痛點：每次改抽幀方式、模型版本或門檻，前後結果就不能比較。解法：先記下 detector 名稱、commit／API 版本、裝置、抽幀規則、score 方向與門檻。輸出統一成：

clip_id,anchor_id,label,variant,score
r001,a001,0,original,0.18
g001,a001,1,original,0.81

你可以接任何能輸出連續分數的偵測器；例如 D3 官方 repository提供研究用推論流程，但其環境與模型前處理並不是一般筆電的一鍵工具。先把「資料與評估器」跑通，再決定是否投入 GPU。

還要先統一 score 方向：本文與 RA-Bench 都把較高的 fake_score 定義為「generated 證據較強」。但在本文檢視的 D3 commit c798fbc 中，資料標籤雖是 real=0、fake=1，stock evaluator 卻以 1-y_true 對原始 dis_2nd_std 計算 AP，表示較大的 D3 原始值偏向 real。D3 adapter 因此要在評估前宣告一個全域轉換，例如 fake_score = -raw_score；不能針對來源或條件事後翻向。stock evaluator 也只輸出彙總文字、每個 CSV 最多取前 1,000 筆，不會直接產生 RA-Bench 要求的逐項 prediction CSV。「training-free」同樣仍使用預訓練 encoder，不代表不需要模型或運算資源。

第 4 步：對 real／generated 做完全相同的退化

痛點：只壓縮 generated，會把「有沒有被處理」變成答案提示。解法：同一段指令套到兩類影片，並保存每個衍生檔與原檔的 anchor 關係。先安裝 FFmpeg；下面是依指定版本官方規格撰寫的 T1 指令範本：先 VP9，再轉回 H.264。執行前仍要核對自己的 FFmpeg build 與輸入格式。

ffmpeg -i input.mp4 -an -map_metadata -1 \
  -c:v libvpx-vp9 -crf 36 -b:v 0 t1.webm

ffmpeg -i t1.webm -an -map_metadata -1 \
  -c:v libx264 -crf 28 -preset medium \
  -pix_fmt yuv420p -movflags +faststart t1-reencode.mp4

T2 與 T3 不能先輸出一個預設 codec 的中間 MP4，否則會多一次未定義的有損編碼。正確做法是把縮放或 8 fps filter 直接併入 T1 的 VP9 first pass，再走相同的 H.264 second pass：

# T2：縮放直接併入 VP9 first pass
ffmpeg -i input.mp4 -an -map_metadata -1 \
  -vf 'scale=trunc(iw*0.5/2)*2:trunc(ih*0.5/2)*2' \
  -c:v libvpx-vp9 -crf 36 -b:v 0 t2.webm
ffmpeg -i t2.webm -an -map_metadata -1 \
  -c:v libx264 -crf 28 -preset medium \
  -pix_fmt yuv420p -movflags +faststart t2.mp4

# T3：8 fps 直接併入 VP9 first pass
ffmpeg -i input.mp4 -an -map_metadata -1 \
  -vf 'fps=8' -c:v libvpx-vp9 -crf 36 -b:v 0 t3.webm
ffmpeg -i t3.webm -an -map_metadata -1 \
  -c:v libx264 -crf 28 -preset medium \
  -pix_fmt yuv420p -movflags +faststart t3.mp4

T4 是加入官方定義的 AP-style 合成新聞角標後走 T1；T5 則依 manifest 組合縮放、8 fps、角標與 T1。角標資產、位置與處理順序都屬條件的一部分，不能用任意圖樣替代後仍宣稱等同官方資料。這些指令只描述受控轉換；若要評估某個實際平台，還要另外建立合規、按日期記錄的平台上傳與下載流程。

第 5 步：門檻只在 calibration set 選一次

痛點：Original 用 0.7、壓縮版改用 0.4，會把穩健性問題藏起來。解法：用獨立 calibration set 選出能滿足目標 FPR 的門檻，凍結後一次套用所有 test variant。流程可寫成：

threshold = choose_on_calibration(target_fpr=policy_fpr_limit)
for variant in ["original", "reencode", "resize", "fps8", "badge", "full"]:
    score = detector(test_clips[variant])
    report_confusion_matrix(score, threshold)
    report_precision_recall_fpr(score, threshold)

policy_fpr_limit 是你在看結果前依使用風險訂下的部署限制；它和 RA-Bench 用完整 ROC 計算的 TPR@FPR≤5% 是兩種不同報告方式。小樣本只能演練程序：若 test 只有 20 支真人片，每多 1 個 FP，觀察到的 FPR 就跳 5 個百分點，根本無法證明「FPR 只有 1%」。要做正式低誤判估計，必須擴大獨立真人樣本，報信賴區間，並以原始 anchor／來源群組做 clustered bootstrap，而不是把每一幀或每個轉檔都當成獨立樣本。

第 6 步：配對回看每一次翻盤

痛點：平均 AUC 可能看似只掉一點，卻掩蓋同一支片從 TN 翻成 FP。解法：用 anchor_id把 Original 與退化版並排，分成四組：正確→正確、正確→錯誤、錯誤→正確、錯誤→錯誤。逐支記錄是重編碼、縮放、幀率或角標觸發 score 漂移，再回查場景、運動、字幕與來源。

這一步也是建立任務型評估的核心；若你想看另一種「先定失敗條件、再做 adversarial case」的範例，可參考AI Agent 搜尋 API 評估教學。方法可以跨任務搬用，指標卻不能跨資料集硬比。

如何判讀結果？三層使用規則

1. 綠燈：流程可繼續測。設定凍結、兩類同樣退化、門檻來自獨立 calibration，而且每個錯誤都有配對回看。這只代表實驗設計合格，還不代表 detector 已可部署。
2. 黃燈：只拿來分流。只要 score 對任一合理退化大幅漂移，或低 FPR 下 TPR 太低，就把結果標成「需要複查」，結合來源、原檔、metadata、Content Credentials 與其他證據。
3. 紅燈：不能據此定性。沒有原檔、來源不明、門檻未校準、只測 generated、把 score 當機率，或用同一批資料挑門檻又報成 test，都不足以支持公開指控。

C2PA 官方 explainer也把界線說得很清楚：provenance 記錄內容歷程，不替內容真假背書；缺少 Content Credentials 也不能自動視為可疑。偵測、來源證明、事實查核與人工鑑識是互補層，不是四選一。制度面還可延伸讀AI 內容透明規則。

6 個最常踩的坑

1. 只秀最高 accuracy：改報 TP、FP、TN、FN、precision、recall 與固定 FPR 下的 TPR。
2. 每個條件各挑最佳門檻：除非部署時真的知道轉檔條件，否則門檻必須固定。
3. 只處理 generated：退化必須 class-symmetric，real 與 generated 一視同仁。
4. 把衍生檔拆到不同 split：同一 anchor 全家綁在一起，避免資料洩漏。
5. 把 200 個轉檔當 200 個獨立事件：有效獨立單位仍是原始 anchor／來源；報告時要保留群聚關係。
6. 看到 improvement 就宣稱穩健：壓縮後 AUC 上升也可能是新 shortcut；要看低 FPR、未見來源與配對錯誤轉移。

AI 影片偵測器 FAQ

1. 偵測器分數很高，就能證明影片是 AI 嗎？

不能。它是特定模型、資料與版本下的訊號，只能支持分流或進一步查核；不能單獨推論作者、意圖、事件真假或使用哪個生成器。

2. 壓縮一定會讓 AI 影片偵測器變差嗎？

不一定。RA-Bench 的整體平均下降，但個別 detector 在 Full 條件反而上升。你要測的是 detector × transform 的互動，不是預設單一方向。

3. AUC 50 代表 50% 影片判對嗎？

不是。AUC 近 0.5 表示排序接近隨機；實際判對率還取決於門檻與兩類比例。

4. 小型 subset 能算 TPR@1%FPR 嗎？

能算出數字，但通常不能做可靠主張。真人樣本太少時，FPR 的解析度與不確定性都太粗。小集適合驗證管線、找翻盤案例；正式結論要擴充樣本與信賴區間。

5. T4 的新聞角標可以隨便換一張嗎？

不能把任意替代品當成同一 benchmark 條件。角標的資產、位置與處理順序都可能改變偵測分數。若不是使用官方 release 中對應的處理結果，就應標成自己的延伸條件，不能和論文數字直接比較。

6. 這套 FFmpeg 流程等於真實社群平台嗎？

不等於。它是可控制、可重跑的代理條件。若你的真實部署面向某平台，下一階段還要用合規帳號與素材檢查真正的上傳—下載路徑，並記錄日期與平台設定。

7. 一定要裝 D3 或準備 GPU 嗎？

不一定。資料、退化與評估層可以先用任一會輸出 score 的 detector 接上；是否需要 GPU 取決於該 detector。研究模型通常比商用 API 更需要環境準備。

8. 有 C2PA 就不需要 AI 偵測器了嗎？

不是替代關係。C2PA 回答內容歷程，detector 尋找統計痕跡；兩者都不能單獨判定事件真假，應和來源查核一起使用。

給新手的 5 個帶走重點

1. 先問「固定多少真人誤判時，還抓得到多少 generated？」
2. real／generated 要共用 anchor、split 與退化流程。
3. 門檻只在 calibration set 選一次，test 不准偷調。
4. 小 subset 是煙霧警報器測試，不是整棟大樓的消防認證。
5. 輸出叫 score；結論叫「需複查」，不要越級叫定罪。

如果你想把這套思路延伸到自己的 AI 工作流，可從AlphaLab AI 專區挑一個任務，再到AI 實戰課程把評估與自動化串起來。