零 token 视频去重听起来像是一个省钱技巧真正跑通之后你会发现它其实是把一个本质问题重新回答了视频重不重复到底应该由谁来判断。先还原一个场景。我的素材库里积累了几千条视频同一场活动手机直出的原片、转码后的压缩版、加了字幕的发布版、剪辑软件自动生成的代理文件全混在一起。想把这些重复内容找出来只看文件名和修改时间基本不可靠。人工去翻几百条还能忍几千条就是灾难。最初想过抽几帧发给多模态大模型让它描述画面并判断是否重复。结果有两个麻烦一是几千条视频全部过 APItoken 成本和排队时间都很可观二是模型的判断并不稳定同一个视频用不同 prompt 问两次结论可能有出入。更关键的是它把“压缩后的同一段视频”和“同一个场景的不同机位素材”都叫“相似”但对去重来说这两种情况的处理逻辑完全不同。这件事让我把方向换了一下视频去重不应该走“问模型”这条路而应该走“指纹比对”这条路。真正的解法是把重复检测变成一套可本地运行、可批量执行、可复现判断的工程流程。token 为零只是这条路线带来的副产品更重要的是你能解释每条视频为什么被归为重复你能在新增素材时复用同一套判断规则你能在下一次跑批时得到和上一次一致的结果。下面我把这套流程从头拆开讲。1. 先搞懂“零 token”去重的真实边界1.1 视频重复不是一种形态至少有三层很多人动手之前没有定义清楚“重复”的含义导致后续方案选错。第一层是完全重复。同一个文件只是文件名不同或者同一个视频被原封不动地复制到多个目录。这一层不需要抽帧直接用文件级哈希比如 SHA-256就能百分百定位。文件内容一致哈希必然一致。第二层是同源不同版本。同一个剪辑成片被导出成不同分辨率、不同码率、不同封装格式或者加过片头片尾、字幕、调色。画面内容基本一致但文件字节完全不同。这一层靠文件哈希做不到需要做内容级指纹也就是从画面本身算出签名。第三层是近似重复。同一个真实场景由不同设备、不同机位、不同时间拍摄出来的素材。画面在语义上“像”但不是同一段视频。比如同一场发布会两台摄像机从不同角度录制内容显然相关但用去重工具处理时要非常小心它到底应该被认为是重复还是作为同一素材组的多个版本保留这取决于你的业务目标。理解这三层之后大量误判的原因就清楚了很多人用第三层的语义向量去处理第二层的去重任务或者反过来用第二层的精确指纹去归并第三层的相似素材。方案本身没有错错的是匹配目标不一致。1.2 大模型做视频去重为什么又贵又不稳定大模型天然适合做“理解”不适合做“集合归类”。你可以让它看几段视频画面然后给你一个“内容接近”的自然语言结论但它不擅长在一个包含几万条视频的库里完成全量两两比较。原因有三个成本线性放大视频去重本质是两两比较N 条视频如果要全部做一次匹配比较次数会膨胀。如果每一条都要把诸多帧送到 API 里做一次推理费用会随数据量快速上升。结论不可复现多模态模型的输出受采样参数影响同一个输入温度系数不同结果就可能不同。而去重是一个需要审计的流程最好做到“这次判重复下次依然判重复”。语义相似不等于重复模型说“这两个视频都在讲同一件事”不代表它们在文件管理层面应该被合并。去重需要的是可量化的、可调阈值的判断而不是一段语义描述。所以“零 token”的实质不是技术上的噱头而是换了一个判断模型放弃语义问答改用内容签名。它不关心画面里是山还是水、有没有人说话只关心这组画面是否在某个误差范围内一致。2. 一条完整的零 token 视频去重链路2.1 抽帧把视频压缩成一组代表图视频是连续画面直接把每一帧都拿去比较既慢也没必要。一分钟 30 秒的视频有 1800 帧但相邻帧之间往往高度相似。合理做法是抽出一批能代表视频内容的“关键帧”。最稳妥的起步方式是固定间隔采样。例如每秒抽一帧或者每 5 秒抽一帧。固定间隔的好处是逻辑简单、覆盖均匀不会因为某个镜头切换点没有被检测到而遗漏内容。更精细的做法是叠加场景切变检测。当画面发生明显跳变时额外补抽一帧。这样既能控制帧总数又能尽量保留镜头切换造成的内容变化。实际工程中先固定间隔跑通再用场景检测做补充是比较常见的路径。抽帧工具一般选 FFmpeg 或 OpenCV。我建议把 FFmpeg 作为外部命令执行它解码能力强、参数成熟、几乎涵盖所有输入格式。OpenCV 也能做但遇到一些特殊编码时解码稳定性不如 FFmpeg。2.2 指纹把帧变成固定长度的数字签名拿到帧之后要做的不是直接比较像素。像素级比较对分辨率、压缩噪声、亮度变化极其敏感两个明明是同一段视频的帧只要编码参数不同像素差值就会很大。正确做法是计算“感知哈希”。常见的有 dHash、aHash、pHash。它们做的事情本质上是一样的把图像缩放到固定尺寸经过某种变换后生成一串固定长度的二进制哈希值。同一画面经过缩放、压缩、轻微亮度调整后计算出的哈希可能只差几个比特位。感知哈希适合“同源不同版本”的去重。到了更复杂的近似重复场景可以让本地模型把帧编码成特征向量。比如使用 CLIP 的图像编码器将一帧变成一个 512 维或 768 维的浮点数向量。这样两帧是否相似就变成两个向量之间的余弦相似度是否超过阈值。这里说的“零 token”并不是说本地向量模型内部没有 token 概念而是说整个计算过程不调用线上按 token 计费的推理服务所有开销都在自己可控的成本范围内。对业务方来说它不产生 token 账单也不会因为 API 并发限制而阻塞排队。2.3 匹配从“帧是否相似”上升到“视频是否重复”单帧指纹相等不代表视频重复。需要把一条视频的所有帧指纹和另一条视频的所有帧指纹做一次综合匹配。一个朴素但有效的做法是对视频 A 的每一帧在视频 B 的帧序列里找最相似的帧如果距离小于阈值就记作一次命中最后统计命中帧占 A 总帧数的比例。超过某个比例判定两个视频在内容层面重复。这种方法不要求两个视频长度完全一致。比如一个 60 秒的视频和一个 58 秒的视频只要主体画面大部分能对上就可能是片头片尾不一致的版本。时长比例校验可以作为辅助条件但不要把它设得太死。如果指纹是向量比较方式可以换成向量索引。把所有帧的向量加入 faiss 索引然后用每个向量做一次 top-k 搜索批量算相似度。这比逐个做两层循环快很多。3. 最小可用闭环从单个视频到批量库3.1 先跑一个最小闭环不要上来就搞工程化如果你只是想验证这条路线是否可行不要一开始就装一堆框架、配分布式队列。先把“单条视频 → 抽帧 → 算指纹 → 两两比较”这条路走通再谈规模。环境建议用 Python 3.10 以上。核心依赖只有几样FFmpeg、Pillow、imagehash、numpy。如果后面要加语义向量再装 transforms 或 sentence-transformers。抽帧可以用 FFmpeg 命令行完成ffmpeg -i input.mp4 -vf fps1 -q:v 2 frame_%04d.jpg这条命令表示每秒抽一帧输出为从 frame_0001.jpg 开始的序列图。fps1是每秒抽 1 帧-q:v 2控制输出图像质量。实际落地时这个间隔要根据视频内容和时长调整。短视频素材 1 秒 1 帧通常够用长时间讲座或监控视频可以降到每 10 秒 1 帧动作频繁的游戏录像或宣传片可能需要每秒 2 到 3 帧。然后对每一帧计算感知哈希from PIL import Image import imagehash hash imagehash.phash(Image.open(frame_0001.jpg))pHash 会把图像统一缩放到固定尺寸做离散余弦变换后取低频系数再量化成二进制哈希。它不直接比较原始像素所以对压缩、缩放、轻微亮度变化有更好的容忍度。两帧之间用汉明距离判断相似度h1 imagehash.phash(Image.open(frame_0001.jpg)) h2 imagehash.phash(Image.open(frame_0002.jpg)) distance h1 - h2这里的减法在 imagehash 库中返回的是两个哈希之间的汉明距离。汉明距离越小两帧越相似。阈值可以先给 10再根据你的数据校准。3.2 把“帧相似”升级成“视频相似”单帧相似不能直接说视频重复因为一个视频里总会有一些通用画面例如黑场、转场、字幕页。所以要在视频层面做统计。示例逻辑def find_duplicate(video_a_frames, video_b_frames, hash_threshold10, match_ratio0.8): hit 0 for frame in video_a_frames: for candidate in video_b_frames: if frame - candidate hash_threshold: hit 1 break ratio hit / len(video_a_frames) return ratio match_ratio这个实现很粗糙但作为验证已经足够。match_ratio0.8表示视频 A 中 80% 的帧都能在视频 B 中找到相似帧时判定为重复。要注意这是有方向的从 A 到 B 的命中率高不代表从 B 到 A 也高。如果一个是完整版一个是删减版A 是长视频时命中率可能下降。所以批量比较时通常两个方向都要算一次或者保留命中率的较低值作为参考。3.3 从单条扩展到目录批量单条验证通过后再扩展到整个目录。批量化要处理三件事视频遍历扫描目录下所有视频文件按扩展名过滤常见格式。中间产物管理每一条视频抽出的帧和算出的哈希建议存成中间文件比如 pickle 或 json避免下一次重复抽帧。两两比较次数控制如果只有几百条视频全量两两比较可以接受如果上万条就要把指纹放进索引用近似最近邻搜索替代暴力匹配。优先做“指纹入库”而不是“每次全量重算”。第一次跑批很慢但特征入库后新增视频只需要与库中的指纹索引比对成本会大幅下降。4. 真正决定效果的不是模型而是这四个参数4.1 采样间隔召回率与计算量的平衡点抽帧密度直接决定你能否“看到”一个视频里的关键画面。采样太稀疏短镜头或中间插入的提示字幕会被漏掉太密集相邻帧高度重复白白增加后续计算量。起步可以用每秒 1 帧然后刻意找几条“难以区分”的样例观察漏检情况。如果某个视频内容较短但动作变化快就把间隔缩小到每 0.5 秒 1 帧如果视频是长时间静止画面比如讲座可以把间隔拉大到 10 秒 1 帧。更合理的做法是先看视频的时长和场景数量再决定每秒抽几帧。4.2 哈希阈值精确与召回的天平感知哈希的汉明距离阈值不是固定的。10 和 15 之间可能就差很多阈值越大越容易把不同的视频判断为重复阈值越小越容易漏掉真正重复的视频。建议从一个较严格的值开始例如 8 或 10然后用已知重复的样本验证逐步放宽到能召回全部样本的最低阈值。不要追求“一套阈值打天下”。不同来源的视频压缩程度不同最佳阈值自然不同。如果发现同一个视频的转码版本在 pHash 下的距离经常在 12 到 15 之间那 10 的阈值就会漏掉它。这时有两个选择一是把阈值调到 15但接受误报升高的风险二是改用更稳定的指纹比如对关键区域单独哈希减弱字幕和水印的干扰。4.3 用感知哈希还是语义向量感知哈希和语义向量解决的不是同一个问题。感知哈希更接近“同源副本检测”它对转码、缩放、亮度变化鲁棒但对“换机位、换角度”无能为力。语义向量更接近“近义内容匹配”CLIP 这类模型能理解画面里拍的是同一个场景但两个机位的画面在像素层面完全不同感知哈希几乎不可能把它们识别为相似。如果你的目标是清理素材库里的“同一个文件的各种版本”首选感知哈希因为计算快、可解释、误报低。如果你的目标是“把同一场活动的所有相关素材归组”那感知哈希不够需要上 CLIP 之类的语义向量模型。两者不冲突先用感知哈希做精确去重再对剩余样本做语义聚类是一个合理的递进流程。4.4 批处理与并发资源比算法更容易成为瓶颈批量跑视频去重时真正影响速度的往往不是算法而是 I/O、帧解码和内存。用 FFmpeg 抽帧时CPU 解码是主要开销用 CLIP 提特征时GPU 才是关键。如果只有 CPU高分辨率视频抽帧会非常慢建议先降采样到较窄的宽度。比如把帧缩放到 256 像素宽再算哈希或喂给模型速度会明显提升对“画面是否相同”的影响通常可以忽略。并发方面建议先单进程跑通再考虑多进程。两个视频同时抽帧如果磁盘读写已经饱和并发不会带来收益反而会竞争资源。内存方面感知哈希只有几十字节一帧内存压力小高维特征向量则是按兆计算的几万条视频会让内存不够这时内存映射或向量索引是必须考虑的。5. 零 token 方案与传统大模型方案的选型边界5.1 零 token 方案的强项零 token 方案真正强的地方不是“省钱”而是三个特性可批量抽帧、算哈希、比索引每一步都可以写成批量任务用定时调度去跑不需要人工逐条发送。可离线不依赖公网服务和 API 密钥内网环境、离线机房都能运行。可复现同样的输入、同样参数输出一定一样。这在素材审计、版权存证、数据集清洗场景里很重要。如果你的需求是“把库里几万条视频每隔一段时间去重一遍”零 token 方案几乎是唯一现实的选择。大模型路线不是不好而是每次全量扫描的费用和耗时在一个数量级之外。5.2 零 token 方案的短板短板也明显。它不理解高层语义无法回答“这个视频是不是另一个视频的二次剪辑”如果二次剪辑做了大量裁剪、加速、转场、画中画感知哈希的匹配率会低到不可用。语义向量模型能缓解一部分但它对“同源但姿态不同”的内容也可能产生很多误报。另外对严重变形的视频比如把画面上下翻转、镜像、加了大量滤镜动画目前的本地指纹方案基本无能为力。不是完全没有解决思路比如可以生成多种变换版本的指纹但代价是特征量成倍增加。这时候就需要问自己这种极端场景在你的素材库里占多大比例如果只是极少数不值得为它牺牲全库的性能。5.3 混合策略零 token 粗筛 大模型精排更务实的做法是分两步走。第一步用零 token 方案做粗筛把明显重复、同源不同版本的视频直接标记出来。这一步解决大部分数据量不产生 token 消耗。第二步对没有命中但又有“值得怀疑”的边界样本抽少量帧送进多模态大模型做精确判断。这样大模型只用处理原本数据的 2% 到 5%token 消耗大幅下降准确率也能保住。判断哪些样本“值得怀疑”可以在零 token 阶段设置一个缓冲区间。比如相似度 0.6 到 0.8 的样本不直接判定交给大模型精排。低于 0.6 的直接放行高于 0.8 的直接去重。这个缓冲区间的大小取决于你对误报的容忍度。6. 常见问题排查与长期维护建议6.1 一个从现象到根因的排查顺序遇到“两个明显重复的视频程序却没识别出来”不要急着调参数。按下面的顺序排查先确认重复的定义。是同一个文件的副本同源不同版本还是同一场景的不同机位三层定义对应不同指纹策略。再检查抽帧结果。打开抽出的帧看一遍有没有黑帧、花屏、缩略图模糊到无法辨识内容采样间隔会不会刚好避开了画面差异最大的区域检查指纹层。如果是感知哈希用一条已知重复的视频打印帧间汉明距离的分布看阈值是否离实际分布太远。检查视频级比较。判断逻辑是否要求两个视频帧数一致如果 A 是完整版、B 是删减版单向命中率是否被错误使用检查中间产物。有没有可能抽帧的是旧文件而目标视频已经更新了文件路径、缓存、哈希库版本都会造成“明明改了代码却没生效”的假象。6.2 批量落地最常见的工程问题在实际批量跑的时候最常踩的坑有三个。第一个是路径和权限。视频文件所在的目录如果有中文名、特殊字符或者没有读权限FFmpeg 命令会在抽帧阶段直接失败。批量处理时建议先做一个文件清单记录路径、大小、时长再逐条处理失败时要保留日志。第二个是中间产物不落盘。如果每次跑批都重新抽帧、重新算哈希之前的结果作废时间和算力成本都白花了。第一次跑通后把指纹结果和抽帧配置一起存下来后续增量只需处理新增视频。第三个是比较规模失控。如果用两层循环做全量两两匹配几百条视频时还能跑几千条就开始变慢。视频数量增长到上万时复杂度会快速上升必须换成向量索引或分桶策略先缩小候选集再做精确比较。6.3 长期使用要补的三层能力如果这套流程要长期放在媒体资产管理流程里除了去重逻辑本身建议再补三层能力调度能力把扫描、抽帧、指纹计算、索引更新写成可定时执行的任务避免每次手工运行。结果审计能力每一次判定重复时保存证据包括命中的帧编号、相似度分数、触发规则。后续如果发现误判可以直接回溯。阈值漂移感知不同批次视频来源可能不同压缩方式、分辨率分布都会变化。如果某一天发现重复率明显下降或误报率明显上升先检查是不是新批次视频的特征已经偏离了当初校准阈值时的分布。收个尾回到最开始的那个素材库。真正让去重跑起来的不是某个更贵的模型而是一套可控的判断规则你能解释什么算重复什么不算你能在日志里回溯为什么这条被分到重复组你能在下一次新增素材时复用同一套指纹索引。零 token 视频去重就是这样一层底座。它不追求模型“看懂”视频而是追求用更低成本、更确定的方式把重复内容稳定地找出来。先把这一步做扎实后面要不要引入多模态大模型以及在哪个环节引入才有讨论的基础。