YouTube 视频搜索：一半的活儿根本不用模型

一句话

这一章表面是「做一个视频搜索」，内核是一道跨模态检索题：用户给的是文字，库里躺的是画面。书给的答案不是训一个更大的模型去「理解视频」，而是把系统劈成两条互不依赖的检索路——文本元数据走传统倒排索引、视觉内容走表示学习加近似最近邻——再用一个多级漏斗把两路候选收敛成一个可排序的相关性分。难点从来不在模型，在评估口径与线上线下的分工。

Glossary · 术语表

坐标

本章是《ML 系统设计面试》Part II 十道真题的第 3 道。上承 Ch2 视觉搜索——那里查询和物料都是图，这里查询是文字、物料是视频，既跨了模态又多了时间维度；下启 Ch5 有害内容检测，把「多路信号怎么融合」继续往下推。现实对应任何「用文字找非文字内容」的场景：视频平台站内搜索、素材库、企业知识库、多模态 RAG 的检索层。

这章要解决什么

搜索引擎能工作的前提是被搜的东西身上有字。网页有正文，商品有标题和参数，视频什么都没有——只有一串像素和一条音轨。

最朴素的解法是让上传者自己填元数据，然后照网页搜索那一套做。这条路能跑，但漏掉两大块：

• 写下来的不等于拍下来的。标题写着「周末 vlog」的视频里可能有整段红色跑车雨中漂移；用户搜「跑车 漂移」，倒排索引一个词都对不上。
• 写下来的还可能是骗人的。标题党与堆砌热门词是 UGC 平台常态，纯词面匹配对这类噪声毫无抵抗力。

补人工标注也不成立：YouTube 侧长期公开引用的上传速度是每分钟数百小时新视频，就算一个人 1 倍速看完立刻打标，也要几百人同时看才追得平当天增量，何况「该打哪些标签」本身就没有封闭集合。

所以这一章真正要回答的是：怎么让「画面里有什么」也变成可检索的，同时不把已经很好用的词面检索扔掉。

核心内容，讲透

第一个决定：劈成两条路，而不是训一个更大的模型

书先把问题翻译成 ML 任务：输入一段查询文本，输出一个按相关性排序的视频列表——这是排序问题而非分类问题，没有「标准答案集」，只有相对顺序。真正定调的是下一个决定：两条检索路并行。

• 文本检索：对标题、简介、标签、ASR 自动字幕建倒排索引，用成熟的词面打分出候选。这条路完全不需要机器学习。
• 视觉检索：把视频画面和查询文本各自编码成向量，在同一个空间里比「近不近」。这条路才是本章的 ML 主体。

为什么不合成一路？因为两者的失败模式正好互补：词面检索会漏掉「没写出来的内容」，向量检索则会犯「看着像就算相关」的错，在专名、型号、人名这类要精确字面匹配的查询上尤其吃亏。拆成两条独立的路还有工程红利——能分别扩容、分别灰度，一条坏了另一条还在。

视频怎么变成向量：先抽帧，再选编码器

一条 10 分钟、30 fps 的视频有 18000 帧；十亿条视频若逐帧过网络，任何预算都会被烧穿。所以第一步永远是抽帧：按固定间隔（比如每秒 1 帧，10 分钟就只剩 600 帧）或按镜头切换抽关键帧，再统一解码、缩放、归一化。编码器则有两条路线：

• video-level（视频级）：用 3D 卷积或带时序注意力的 Transformer 吃一整段，能抓住动作——「漂移」「扣篮」「切菜」这类语义只存在于帧与帧之间的变化里。代价是算力和内存都贵一个量级。
• frame-level（帧级）：每帧单独过一个图像编码器（如 ViT），再把这些向量池化成一条。便宜得多，还能直接复用现成的图文预训练权重；但时序基本丢光——一段视频正放和倒放，在它眼里几乎一样。

书的倾向很实际：先上 frame-level，因为十亿量级的全库编码是一笔真金白银的账；等确认时序语义确实是瓶颈，再对特定品类升级到 video-level。这是本章最典型的「成本先于精度」的判断。

把文字和画面钉进同一个空间：对比学习

两个编码器各吐一条向量，凭什么「文字的向量」和「画面的向量」能直接比？靠训练时强行对齐。

训练数据是〈查询文本, 视频〉的配对，主要来自搜索日志——用户搜了这句话、点开并看完了这条视频，就记一条正样本。负样本几乎不用额外标注：同批次里的其他视频就是负样本，它们恰好与这句查询相关的概率极低。

目标函数用对比损失：让配对那一对的相似度 sim(q, v)（通常就是两条向量的点积）尽量高、让这句查询与批内其他视频的相似度尽量低。说人话：把「这句话该配哪段画面」做成一道从一批候选里挑出正确那个的选择题，反复考，逼两个编码器把该配对的东西摆到一起。

这套结构就是双塔：两座塔互不看对方，只在最后用一次点积相遇。它看起来是个限制——模型没机会做文字与画面的细粒度交互——却换来了本章最关键的工程性质：视频侧可以整个离线算完。

服务：四级漏斗，和双塔真正的分工

线上一次查询走四段（图 1）：查询理解做纠错与意图判断，顺手把查询编码成向量；候选生成两路并行；排序对剩下的几百条跑重模型，可做查询与视频特征的交互，并加上用户画像、视频质量、新鲜度；重排序承接业务规则——过滤违规、同频道去重、地区限制、多样性。

为什么召回必须用 ANN 而不是精确检索？十亿条向量逐个算点积不可能在毫秒内完成；ANN 靠量化与分层索引把它压到毫秒级，代价是偶尔漏掉真正最近的那几条。召回阶段容得下这种错——它本来就只负责「别漏太多」，精度由后两级兜底。

双塔的价值在这里兑现：视频向量离线批量算好、灌进索引，线上只给查询算一次向量。全库编码一次可能占掉 GPU 集群几天，但摊到每次查询上接近于零。反过来说，换模型就意味着全库重算加索引重建——这是这套架构最大的一笔隐性成本，也是书里着墨最少、面试里最值得主动提的一点。

评估：离线四个、线上三个，各量不同的东西

离线用 precision@k、recall@k、MRR、mAP，线上看点击率、完播率、总观看时长——各自在量什么、何时该用，见下一节的表 3。这里只留最该记住的一句：离线涨、线上不涨是常态。原因不玄：离线集合采自历史日志，天然只包含「当时被展示过的视频」，而新模型想推的那些从未被展示过的好视频，在离线集合里连出现的机会都没有。

关键权衡与选型

表 1 · 两条检索路：覆盖什么、在哪失手

表 2 · 视频编码器选型

表 3 · 指标怎么挑（离线四个 + 线上三个）

为什么重要 / 落到真实系统

双塔 + 对比学习 + ANN 这套三件套，今天已经是工业界「用文字找非文字」的默认骨架：电商以文搜图、素材库检索、多模态 RAG 的检索层，结构都和这一章一模一样。面试里的高频追问集中在两处——为什么不做单塔交互模型（答：物料侧无法离线预算，十亿量级不可能在线逐条过模型），以及离线涨线上不涨怎么查（答：先怀疑评估集的曝光偏差，再查线上线下特征是否一致）。

易错点与争议

• 把「向量近」当成「内容相关」。ANN 返回的是表示空间里的邻居，而表示是从训练分布里学来的；训练里没出现过的品类（冷门运动、专业设备、小语种口播）会近得毫无道理，且不报错、只是悄悄给错答案。
• 把点击日志当干净标签。点击强烈受排序位置影响——排第一的天然被点得多，用它训出来的模型会把现有排序的偏见学回去并自我强化。用交互当标签确实省钱，但曝光偏差的账要自己补（随机流量、位置去偏）。
• 以为向量检索该取代词面检索。在专名、型号、人名、精确短语上，词面匹配至今常常更准，这正是工业界普遍保留混合检索的原因。本章的两条路不是过渡形态，是终态。同理，只报一个 precision@k 而不交代 k 取多大、相关性由谁标、查询集怎么采样，这个数根本不可比。
• 时代局限：书成于 2023 年，此后视频理解大幅转向端到端多模态大模型和「先生成摘要再检索摘要」的路线。但「两条路 + 多级漏斗」的服务骨架反而更稳固了——新模型越重，就越必须靠离线预算和多级过滤才上得了线。

要点