AI 影片搜尋評估：建立一套 30 條真實查詢測試集
用 30 條真實查詢評估 AI 影片搜尋，覆蓋相關性、鏡頭精確度、元資料篩選、失敗樣本和來源檔案回連，建立可重現的採購測試。
評估 AI 影片搜尋，應先固定有代表性的素材，再在測試前寫好 30 條查詢。查詢需覆蓋視覺含義、鏡頭語言、元資料篩選、歧義、已知失敗和來源檔案回連。預先定義相關性，保持素材、結果深度和設定一致，同時報告命中與漏檢。這樣得到的是工作流程證據，而不是通用準確度結論。
這套 30 條查詢評估會產出什麼
這是一套可重複的小規模試點，用來回答五個實際問題：
- 系統能否針對真實剪輯需求返回可用片段？
- 結果指向正確的檔案、場景、鏡頭還是時間段？
- 已驗證元資料能否限制範圍，而不會與視覺含義混為一談？
- 哪些查詢會失敗，誤報會帶來多少覆核工作？
- 選中結果能否回到原始素材並進入下一步工作流程？
這是一項採購與工作流程測試，不是科學基準。NIST TREC圍繞測試集合、主題和相關性判斷組織檢索評估；TRECVID則把共享評估方法用於影片檢索研究。內部 30 條查詢試點借鑒了固定輸入和判斷規則的原則，但結論只適用於本次素材、查詢、設定和日期。
前提：開啟產品演示前先凍結測試
評估任何產品之前，先建立測試清單：
| 項目 | 需要固定什麼 | 為什麼重要 |
|---|---|---|
| 素材集合 | 檔案、版本、時長、語言、題材和版權狀態 | 防止候選產品使用不同素材 |
| 搜尋單元 | 檔案、固定窗口、場景、鏡頭、幀或逐字稿段落 | 定義“一個結果”代表什麼 |
| 查詢集 | 30 條查詢的準確原文 | 防止看到結果後改寫弱查詢 |
| 相關性判斷 | 每條查詢的已知目標和可接受替代項 | 讓“好結果”可以覆核 |
| 結果深度 | 例如每條查詢統一查看前 10 個結果 | 保持覆核工作量一致 |
| 設定 | 模型/索引版本、篩選條件、語言和調優 | 讓復測結果可以解釋 |
| 評審人 | 角色、領域知識和分歧處理方式 | 控制主觀差異 |
| 測試日期 | 索引日期和搜尋日期 | 產品行為會隨時間變化 |
選擇有代表性且版權清晰的素材，不要一開始處理整個檔案庫。應包含普通素材、困難樣本、重複片段、長鏡頭、無聲 B-roll、訪談、低光、不同語言語音，以及幾條不應匹配任何結果的查詢。不要允許供應商私下用準備好的演示素材替換測試集合。
搜尋前定義相關性
運行每條查詢前，先寫下目標說明：
- 相關： 直接滿足請求，經過正常剪輯覆核即可使用。
- 部分相關： 主體或動作正確，但缺少鏡頭尺寸、時間、地點或版權條件等重要約束。
- 不相關： 看起來合理，但不滿足請求。
- 預期無有效結果： 素材集合中本來就沒有合格內容；返回空結果可能是正確答案。
相關性取決於任務。人物行走可能滿足寬泛檔案請求，卻不滿足演講者以低機位跟拍方式走上舞台。把判斷規則放在查詢旁邊，確保所有評審人判斷的是同一任務。
30 條 AI 影片搜尋測試查詢
把人名、項目、地區和已知目標替換為已獲授權測試素材中的真實值。保留六類結構，避免試點只測試漂亮的語義搜尋示例。
| # | 類別 | 示例查詢 | 測試內容 | 預先判斷 |
|---|---|---|---|---|
| 1 | 視覺 | 人物開啟一個紙箱 |
主體與動作 | 已知未打標籤目標 |
| 2 | 視覺 | 雙手組裝一個小型設備 |
細粒度手部與物體互動 | 已知目標與近似誤報 |
| 3 | 視覺 | 得分後慶祝的人群 |
多人動作與上下文 | 已知目標 |
| 4 | 視覺 | 夜晚有反光的雨天街道 |
天氣、場景與外觀 | 已知目標 |
| 5 | 視覺 | 演講者在白板上寫字 |
人物、物體與動作 | 已知目標 |
| 6 | 視覺 | 下班後的空辦公室 |
缺席概念與場景上下文 | 有效結果可能有主觀性 |
| 7 | 鏡頭語言 | 港口的全景建立鏡頭 |
景別與敘事功能 | 已知全景鏡頭 |
| 8 | 鏡頭語言 | 緩慢手持跟拍穿過市場 |
運鏡與節奏 | 已知跟拍片段 |
| 9 | 鏡頭語言 | 淺景深的固定特寫 |
構圖與光學外觀 | 已知目標 |
| 10 | 鏡頭語言 | 黃金時刻航拍推向海岸線 |
視角、運動與光線 | 已知目標或無有效結果 |
| 11 | 鏡頭語言 | 宣佈消息後的低機位反應鏡頭 |
角度、剪輯角色與時間上下文 | 已知反應時刻 |
| 12 | 鏡頭語言 | 深色背景上的對稱產品鏡頭 |
構圖與產品呈現 | 已知目標 |
| 13 | 混合 | Atlas 項目訪談，2025 年拍攝，人物微笑 |
元資料加視覺含義 | 已驗證項目/日期與視覺目標 |
| 14 | 混合 | 品牌 A 產品特寫，已批准付費社交媒體 |
版權篩選加視覺搜尋 | 只有已批准資產合格 |
| 15 | 混合 | 已獲歐洲授權的城市夜景無人機素材 |
地區加場景 | 版權字段必須控制資格 |
| 16 | 混合 | B 機位拍攝的主持人走上舞台 |
攝像機元資料加動作 | 已知 B 機位目標 |
| 17 | 混合 | 第 4 集廚房場景中的俯拍鏡頭 |
製作結構加鏡頭語言 | 已知集數/場景目標 |
| 18 | 混合 | 提到 onboarding 的客戶訪談，狀態=已批准 |
逐字稿含義加流程狀態 | 已批准逐字稿片段 |
| 19 | 歧義 | 看起來高端的素材 |
主觀視覺概念 | 預先定義可接受示例 |
| 20 | 歧義 | 出問題前的那個時刻 |
敘事推斷 | 預期評審分歧並記錄 |
| 21 | 歧義 | 節奏快但鏡頭不晃 |
正向與負向組合約束 | 已知替代項 |
| 22 | 歧義 | 不是訪談，而是人物對鏡頭說話 |
否定與相鄰概念 | 已知非訪談目標 |
| 23 | 歧義 | Apple |
水果、品牌或物體的實體歧義 | 標記歧義，不猜測意圖 |
| 24 | 失敗 | 雪地摩托穿越沙漠 |
空結果行為 | 預期無有效結果 |
| 25 | 失敗 | 永久獲得全球廣播授權 |
不受支持的法律推斷 | 必須要求權威元資料 |
| 26 | 失敗 | 識別簽署授權書的人 |
身份與同意邊界 | 不得從外貌推斷 |
| 27 | 工作流程 | 回答採訪問題後的安靜特寫 |
時間精確度與周邊上下文 | 已知鏡頭及相鄰內容 |
| 28 | 工作流程 | 適合 15 秒剪輯的最佳產品演示 |
檢索加人工剪輯判斷 | 多個候選，無唯一答案 |
| 29 | 工作流程 | 所選港口鏡頭的來源檔案 |
來源檔案回連 | 必須返回準確檔案路徑和時間段 |
| 30 | 工作流程 | 把三個已批准市場鏡頭加入可剪輯合集 |
多結果選擇與後續交接 | 合集必須保留源引用 |
第 13–18 條需要可信結構化欄位。影片元資料與語意搜尋解釋了為什麼版權、所有權、審批和製作 ID 應是權威篩選條件，而不能由模型猜測。第 24–26 條則專門檢查系統是否拒絕不受支援的結論。
一致地運行測試
對每個候選系統執行同一流程：
- 索引相同素材，記錄所有排除或失敗的檔案。
- 使用完全相同的查詢文字和允許的元資料篩選條件。
- 查看相同數量的結果並保存排序輸出。
- 按預先規則判斷每個結果為相關、部分相關或不相關。
- 確認結果檔案、時間範圍和周邊上下文。
- 完成後續動作：開啟來源檔案、建立 selects 或導出到目標剪輯工作流程。
- 記錄查詢改寫、供應商調優、當機、索引錯誤和人工介入。
如果改寫了查詢，必須同時保留原始版本。原始查詢衡量自然易用性，改寫查詢衡量瞭解系統偏好後可以達到的效果。所有候選系統應獲得相同的調優機會。
評估相關性與工作流程適配
評分表應暴露漏檢與覆核成本，而不是把一切壓縮成單一“準確度”。
| 指標 | 計算或觀察方法 | 含義 |
|---|---|---|
| Success@10 | 前 10 個結果內至少有一個相關結果的查詢數 / 30 | 用戶能否找到可用候選？ |
| 首個相關結果排名 | 第一個相關結果所在名次 | 需要查看多少結果？ |
| 空結果正確率 | 正確返回無合格內容的空結果查詢 / 預設空結果查詢 | 系統能否避免自信噪音？ |
| 約束通過率 | 滿足所有硬性元資料約束的混合查詢 / 混合查詢 | 篩選條件是否真正限制資格？ |
| 時間精確度 | 結果是否指向可用時刻，而非只給出包含它的檔案 | 還需拖動時間線多久？ |
| 來源檔案回連成功率 | 能開啟正確原檔案和時間段的已選結果 / 被測選擇 | 檢索結果能否完成交接？ |
| 誤報覆核時間 | 拒絕看似合理但不可用結果所花分鐘數 | 揭示隱藏人工成本 |
| 工作流程完成率 | 無需外部變通即可完成的任務 / 嘗試的工作流程任務 | 測試完整工作，而不只是搜尋 |
只有在素材集合、查詢集、相關性規則、結果深度和評審人可比時才能對比分數。如果兩位評審人意見不一致，應保留雙方判斷，再用書面規則解決。小規模試點適合決定下一步測試，並不能證明對所有檔案庫都有效。
診斷失敗模式
把失敗歸類，而不是把所有漏檢視為同一個問題：
- 素材失敗： 所需媒體未索引或無法解碼。
- 粒度失敗： 找到正確檔案，但可用時刻仍埋在長素材中。
- 視覺語義失敗： 沒識別主體、動作、構圖或關係。
- 逐字稿/音頻失敗： 語音缺失、轉寫錯誤或匹配過於字面。
- 元資料失敗： 字段缺失、過期、映射錯誤或未強制執行。
- 查詢歧義： 合理評審人對請求有不同理解。
- 邊界失敗： 系統把推斷的身份、版權或同意當作事實。
- 交接失敗： 結果無法回到正確原檔案或剪輯時間碼。
這能幫助團隊判斷應該調整素材集合、元資料治理、索引單元、模型、查詢界面還是工作流程集成，也能避免把元資料問題錯誤歸因於 AI 模型。
ShotAI 適合測試哪些部分
ShotAI 的公開語意影片搜尋說明介紹了對使用者已索引素材進行自然語言搜尋；鏡頭級管理頁面介紹了鏡頭級資產、來源引用、合集和剪輯工作流程匯出。這些能力使 ShotAI 可以參與視覺、鏡頭語言、時間精確度和來源檔案交接測試。
ShotAI 不是公共互聯網反向影片搜尋引擎、法律版權權威系統，也不是負責權限、保留、審批與分發的完整企業 DAM/MAM。經核驗的業務元資料應保存在適當記錄系統中，並測試真實集成。30 條查詢不能保證結果或證明產品優越，只是讓所有候選系統面對同樣問題。
更廣泛的選擇標準可參考AI 影片搜尋工具測試框架和影片資產管理採購指南。
試點檢查清單
- 凍結有代表性且版權清晰的素材。
- 測試前寫完 30 條查詢及預期判斷。
- 同時包含有效、歧義、混合和空結果案例。
- 保持結果深度、設定和調優機會一致。
- 保存排序輸出與評審決定。
- 核驗來源檔案、時間段與周邊上下文。
- 完成下游工作流程，而不是停在搜尋結果頁面。
- 每次報告分數時同時披露限制、干預和測試日期。
常見問題
為什麼正好使用 30 條查詢？
30 條是可管理的試點規模，可以覆蓋六種不同的失敗和工作流程類別。它不是行業標準，也不足以構成通用基準；試點發現重要缺口後應繼續擴展。
每條查詢都應該有已知正確結果嗎？
不應該。應包含歧義請求和無有效結果的查詢。實用系統應呈現不確定性，並在資格或證據缺失時避免編造匹配。
評審人應該查看多少條結果？
根據真實用戶行為在測試前固定深度，例如前 10 個結果。所有系統使用同一深度，並在結論中披露。
元資料和語義搜尋可以一起評分嗎？
可以放在同一工作流程測試，但要分別判斷。元資料篩選決定資格，語義排序負責按含義排列合格素材。
怎樣才算來源檔案回連成功？
選中結果必須在目標時間段開啟正確原始資產，並保留足夠身份資訊，供下一步剪輯、審片或導出使用。
披露
本評估指南由 ShotAI 發佈。它不包含 ShotAI benchmark，也不聲稱 ShotAI 會贏得這項測試。團隊應使用有代表性的素材運行協議，並公佈自身測試條件和限制。