60 秒视频，29 秒建完索引：本地视频搜索已经能跑在笔记本上

Google DeepMind 的 EmbeddingGemma 2 把文本、图像、视频、音频映射到同一个向量空间。Avi Chawla 用这套模型做了个本地视频搜索界面，输入自然语言，它能找到匹配帧并跳到对应时间戳。整个流程跑在笔记本上。

Avi 在推文里给了几个数字。测试机器是 Apple M3 Pro，用 CPU 跑。60 秒视频建索引花了 29 秒。9 次查询平均耗时 25 毫秒。保存下来的帧向量占用 180 KiB。视频只索引一次。之后每次搜索，把查询文本嵌入成向量，再和已保存的帧向量比较。处理过程没有离开本地。推文还提到，开发者已经写了 Rust 原生实现，用于本地推理。

这段描述里有两个容易被混在一起的概念。模型权重的内存占用，可以通过量化压低。检索索引的存储成本，是另一笔账。Unsloth 提供了一个 176 MB 的 4-bit GGUF checkpoint，用于文本嵌入，不包含完整的多模态处理链路。视频帧向量看起来很小，但视频数量增加后，索引会持续增长。

Avi 随后把话题引向二进制量化。他写了篇长文，解释怎样把 RAG 的原始向量存储压到 32 倍。做法不复杂：float32 向量每个维度占 32 位，二进制量化把每个维度变成 1 位。存储和内存占用降到约 1/32。检索时用 Hamming 距离比较两个二进制向量，看它们有多少位不同。

文章里提到，Perplexity 在搜索索引里用这项技术，Azure 在检索管道里用，HubSpot 在 AI 助手里用。Avi 用 LlamaIndex、Milvus、Kimi-K2 on Groq 搭了一套示例：把文档嵌入转成二进制向量，存进 Milvus 的 BIN_FLAT 索引，度量用 HAMMING；查询也做二进制量化，取 top-k 上下文，再交给 LLM 生成答案。他在 PubMed 数据集上查询了 3600 万条以上向量，耗时低于 30 毫秒。代码放在 GitHub，链接在文末。

对普通读者，可以把它理解成给向量做极端压缩。全精度向量像一份写满小数点的坐标表，二进制向量只保留每个维度在零的哪一侧。相似度比较变成数不同位的个数。速度快，存储省，代价是信息变粗。

回复里有人给出了代价的具体数字。Vishwraj Jadav 说他在 FortiqAI 用约 5 万份印度法院案件测试过二进制量化：检索速度快很多，top-k 召回很强，top-1 准确率下降 8 到 12 个百分点。他的建议是二进制用于召回，float 向量用于重排。另一位回复者 Abdel Latrache 也提到，大规模数据里 Hamming 距离适合做性能优化，但二进制向量需要 rerank 补回精度。

Avi 在文章末尾也留了提醒。二进制量化让向量搜索层更高效，生产环境的检索很少只有一次向量查找。真实 agent 会同时从 Slack、GitHub、Jira、数据库和文档里拉上下文。鉴权、同步、查询路由、权限、重排，都会和嵌入搜索一样成为一等公民。二进制量化是一块很强的检索基础设施，不是整个检索系统的全部故事。

回到视频搜索。60 秒视频索引 29 秒，查询 25 毫秒，帧向量 180 KiB，这些数字说明本地多模态检索已经进入可用区间。它适合隐私敏感、离线、个人素材库这类场景。真要上生产，索引会随着视频数量增长，二进制召回后面还得接重排。省内存和保精度，需要分开设计。

来源：