六週、六十億支影片：一個影片搜尋產品的建造日誌

打造一個影片搜尋產品——使用者輸入一句話，就能在數百萬支影片裡找到那個瞬間——實際上要經歷什麼？這是從圈選分片、過濾、索引、去重到上線的逐週日誌，包括專案中途的意外，以及整件事花了多少錢。貫穿全程的基礎：一個 60 億支影片、7 億個獨立頻道、為訓練而生的影片資料集。

日誌比案例研究誠實。這一篇保留了所有犯過的錯。

第一週：訂範圍，以及「決定不自己爬」的決策

產品目標：搜尋影片內容——「找到主廚折蛋白霜的那個片段」——語料以數十萬小時計。第一次架構討論很快傾向自建採集，然後算術開始了。

影音平台封鎖批次存取、並在規模上偵測採集。轉碼數十萬小時本身就是一條基礎設施開支。而去重——同一片段被重新編碼、裁切、跨頻道重傳——是一個研究問題，不是一支腳本。可信的自建採集路徑，在第一個可用索引出現之前，要先燒掉兩個季度的工程。

替代方案：授權一份商業語料的篩選分片。Thordata 的影片資料集——60 億支原始影片、來自 7 億個獨立頻道，為 LLM 與多模態訓練而建——以結構化紀錄交付，帶字幕、頻道譜系與詮釋資料，約 每 1,000 筆 $0.25。當週的決策：買廣度，把工程力留給搜尋問題本身——那才是產品差異化真正住的地方。

第二週：把語料過濾到產品需要的範圍

六十億支影片不是語料，是一整個大陸。產品只需要其中一個區域：教學型烹飪內容、英文與日文、十分鐘以內、有字幕。過濾發生在儲存的上游——這正是結構化紀錄在經濟上的全部訣竅：你付費並儲存的是符合產品的那個分片，不是整個大陸：

最後那條是晚些才加上的——那是第四週的故事。

第三週：索引管線

分片進了物件儲存之後，管線樸素無奇、建得飛快：字幕抽取、圖文聯合嵌入、索引寫入。

def index_shard(shard):
    for rec in shard:
        if not rec.get("caption_text"):
            continue                        # 只收對齊配對
        clip_windows = segment(rec, seconds=30)
        for i, window in enumerate(clip_windows):
            index.upsert({
                "id": f"{rec['record_id']}:{i}",
                "video": rec["video_url"],
                "start": window["start"],
                "text": window["caption"],
                "channel": rec["channel_id"],
                "embedding": embed(window),   # 多模態編碼器
            })

資料集紀錄格式裡的兩個結構選擇直接回本：record_id 讓重新索引擁有穩定的鍵，而 channel_id 讓第四週的修復成為可能。

第四週：去重的意外

第一次評估跑完，回傳結果裡同一個技法被十二支近乎相同的影片示範。不是完全相同——不同編碼、不同浮水印、稍有不同的裁切——但內容一樣。語料的頻道多樣性（7 億個頻道，意味著同一支熱門教學到處被重傳）恰恰讓近似重複變得普遍。

修復是兩道手續：影片指紋的內容雜湊比對抓重新編碼，頻道感知的排序把重傳相對於原創降權。每筆紀錄裡可回溯至來源的頻道譜系，讓「原創還是重傳」變成可解的問題而不是猜謎。這一道手續對檢索品質的提升，超過整個專案裡任何一次嵌入模型的更換。

第五週：評估，與頻道均衡的修復

團隊的評估集是 200 個人工標注的查詢。熱門技法的準確率很好，冷門技法很差——而原因直接寫在索引組成裡：少數高產能頻道主宰了檢索結果。第二週的頻道上限過濾（回頭補上）把檢索重新平衡到語料的長尾——那正是產品差異化所在：有名的教學誰都找得到；產品的價值是找到沒沒無聞的那一支。

這就是「頻道多元資料集」在產品形式上的安靜論證：多樣性不是學術美德，它是檢索覆蓋率。

第六週：上線，與分銷的問題

上線帶來一個語料回答不了的問題：產品的頁面在搜尋裡站在哪裡？影片搜尋產品靠自然流量吃飯，而富含影片的 SERP——影片輪播、精選摘要——持續洗牌。

團隊加入 SERP 監控解決方案，追蹤產品頁與被索引片段在目標關鍵字、各區域的出現位置，量價約 每 1,000 次結構化回應 $0.70。供應資料集的同一家供應商，也供應搜尋側的情報——一個帳戶、一個控制台、一張發票——而且排名資料與影片索引落在同一個資料倉儲，下季路線圖上「排名與索引內容類型有沒有相關性」的分析已經就位。

帳目

值得注意的模式：資料很便宜，運算是預算，而工程時間花在它該花的地方——產品真正的難題上。這就是「從為訓練而生的語料起步」而非「先建採集」的完整論證。

我們常被問到的問題

為什麼不直接用平台的 API？ 平台 API 服務的是它們的產品，不是你的：速率限制、受限欄位、約束下游產品的條款，而且沒有字幕或頻道譜系結構。為訓練與產品用途而建的資料集，出貨時就把結構與授權對話都處理好了。

索引需要多新鮮？ 對搜尋產品而言，新鮮度是產品決策：多數查詢每週夠了，趨勢類每天。排程採集讓節奏變成改設定，而不是改專案。

多語語料值得嗎？ 對首發市場，值得：日文教學內容在現有產品裡明顯被忽略，而語料的頻道多樣性意味著分片裡有足夠的量可以形成差異。

有沒有考慮把搜尋資料也當檢索語料？ 專案後期有——而且它已經在下一版路線圖上。把技法與食譜查詢的結構化 SERP 結果餵進同一個索引，產品就能在「哪支影片示範這個技法」之外，回答「這個技法在搜尋裡浮出哪些結果」。SERP 監控解決方案交付的資料流，與影片紀錄使用同樣的結構化、帶時間戳記形狀，所以它接進的是既有管線，而不是一條新管線。

有什麼會做得不一樣？ 頻道上限過濾第一天就該上；SERP 能見度監控該在上線前而不是上線後開始跑——上線前那幾週的基線資料，是錢也回買不到的唯一東西。如果你的路線圖上有影片搜尋產品，試點打法現在已經很成熟：圈分片、索引、去重、均衡、上線——六週，讓語料做那些原本會吃掉你前兩個季度的粗活。