正在加载，请稍候
768 维截断到 256 维只是第一刀：多模态索引的真实体积等于维度截断 × 量化档位 × 每页向量数，100 万条索引压缩后仍有约 800 MB。
2026 年 10 月 6 日，Google DeepMind 把 EmbeddingGemma 2 以 Apache 2.0 协议开源：740M 参数，基于 Gemma 4 架构，原生把文本、代码、图像、音频、视频映射进同一个 768 维向量空间。对企业知识库团队来说，这是把“产品手册截图、会议录像、客服录音”一起纳进检索入口的信号。但入口统一不等于成本统一——下面把三笔隐性账和四个工程决策算清楚。
过去两年大多数企业知识库是“文本 RAG”：把 PDF 抽成文本、切片、embedding、检索（这套链路的完整工程清单可参考站内 RAG 知识库搭建的 6 个工程决策）。这个链路能跑，是因为被检索的对象恰好都是文本。但真实的企业语料里，信息密度最高的往往不是文本段落。
这三类语料的共同点是：它们的“可检索单元”是页面、时间戳或片段，而不是文本段落。当嵌入模型能原生吃下图像与音频后，团队第一反应通常是“那就都转成向量扔进一个库”，而这正是后面几笔账的起点。
EmbeddingGemma 2 的卖点是 single, natively multimodal model，官方描述是“把 text、images、audio、video 的组合映射进一个统一嵌入空间”。但统一空间省下的是检索入口的复杂度，代价分摊在存储、延迟和召回三个维度上，且三者并不均匀。
维度决定存储。EmbeddingGemma 2 用 Matryoshka Representation Learning（MRL），允许把 768 维输出动态截断到 512、256 或 128 维，官方给出的上限是“最高 6 倍存储压缩”。按 float32 粗算，单向量的账是这样：
| 输出维度 | 单向量近似体积（float32） | 相对 768 维 | 典型取舍 |
|---|---|---|---|
| 768 | 约 3.0 KB | 1× | 精度优先，语料量可控 |
| 512 | 约 2.0 KB | 约 0.67× | 默认档，性价比区间 |
| 256 | 约 1.0 KB | 约 0.33× | 大语料、以召回速度优先 |
| 128 | 约 0.5 KB | 约 0.17× | 冷热分层里的冷数据 |
但截断只是第一刀。多模态语料里真正吃内存的是“多向量”表示——比如用晚交互（late-interaction）方式把每一页的图块各编码一个向量，一个页面可能产出数百个向量。Weaviate 在 2026 年 9 月的 HFresh 文章里点出了根因：HNSW 的图和向量缓存常驻内存，数据量从百万涨到十亿级时内存成为硬瓶颈。他们的 RQ8 量化把质心向量内存降 4 倍，RQ1 量化把 posting 里的向量数据相对 float32 最多压 32 倍。同月发布的 4-bit 旋转量化给出更实用的中间档：4-bit 在相近召回下把堆内存再降 45%。作为量级参照，一个 100 万条、1536 维的索引，压缩后的 code 就有约 800 MB，已经远超 CPU 缓存。
所以“统一向量空间”的真实存储成本 = 维度截断 × 量化档位 × 每页向量数。只盯着维度会低估一个数量级。
EmbeddingGemma 2 是模块化设计：文本工作负载最少只要 270M 参数的主干，视觉编码器 170M、音频编码器 300M 作为可选模块。官方给的在设备端量化后的实测是，文本-only 权重在 Pixel 11 Pro 上约 191 MB 常驻内存，全模态模型约 567 MB。
这组数字在手机上是优势，搬到企业服务器的推理进程里就变成另一个问题：首次请求触发模态编码器加载时，会有明显的冷启动。如果线上是“文本查询命中率 99%、偶发图片查询”，却把视觉与音频编码器常驻，等于用 3 倍的常驻内存换那 1% 的请求；反过来若采用按需加载省内存，就要接受这批请求的首跳延迟被拉长。可选缓解方式是把多模态编码跑成独立的 warm pool，或用预热请求在低峰期保持编码器驻留——但这些都是工程权衡，没有免费午餐。
统一空间意味着“文本向量”和“图像向量”可以直接比余弦距离，但不意味着两类召回质量一样好。官方给出的一个可量化改进是代码场景：MTEB Code 从 68.76 提升到 78.68，即 +9.92 分。文本、图像、音频各自的最佳表现也并未被官方描述为等同。
更微妙的是跨模态匹配本身。晚交互模型尤其“各向异性”（anisotropic），Weaviate 的量化文章提到，对这类嵌入做中心化（centering）能在多个数据集上把 recall@10 提高 +0.1 到 +6.1 个百分点。换句话说，同一个“统一空间”里，不同模态的向量分布可能并不同构，简单等权混排会被分布差异带的偏。这一点在落地阶段往往被“我们已经统一了向量空间”这句话掩盖过去。
统一向量空间给了“混库”的技术可行性，但运维上不一定划算。混库的收益是查询只需一次检索、重排逻辑简单；代价是不同模态的量化档位、EF 参数、更新频率差异被抹平，且一个模态的索引重建会牵动全局。实践中常见的折中是：共享同一个嵌入模型版本，但按模态分 collection，查询时并行检索再合并——这样每个 collection 可以独立选 4-bit 或 8-bit 量化、独立设定召回数量，而模型口径仍然一致。
如果不同模态的分数分布不同构（见上一节），一个只吃文本的交叉编码器重排器没法处理图像召回结果。要么选一个支持多模态输入的 reranker，要么退一步：只用原始相似度做跨模态粗排，把重排预算留给 Top-K 里的文本结果。后者实现简单，但在图表类查询上会明显吃亏。
视频不是一个“文档”，拆法直接决定召回。EmbeddingGemma 2 的 8K 上下文（比上一代大 4 倍）官方说最多可处理 5.5 分钟音频、29 张图片或 58 个视频帧。这意味着单请求的覆盖面有限，需要用滑动窗口切段并给每段打时间戳。采样率上，“每秒一帧”通常过剩，“按场景切换抽帧”（PPT 翻页、白板书写停顿）精度更高但要多一串视觉预处理。务实做法是先按固定间隔抽帧建立基线，再用查询日志里“找错时间点”的 badcase 反推需要加密的区段。
多模态检索的评测集必须把“答案锚定到可定位单元”——具体到某一页、某个时间戳，而不是整篇文档。否则模型返回同文档的相邻片段也会被算作命中，指标虚高。建议：从真实工单与搜索日志抽样，按模态分层，每组不少于 30 条；起步规模 150–300 条即可跑出方向，之后再逐步扩充。评测口径至少覆盖 recall@k 与“答案所在单元的命中率”两项。
一个常见且代价高昂的偷懒做法是：把 PDF 或截图先 OCR 成文本，再走原来那套文本 embedding。这在纯文本页面上没问题，在图表页面上则会系统性丢掉答案。
Weaviate 在 2026 年 9 月的一篇实测里给了直接证据：用 NVIDIA FY2026 四个季度的投资者 PPT 建库（共 92 页，全是图表和对照表），用晚交互多向量模型直接编码页面图像，不加任何 OCR 或切片。问 automotive revenue 随时间怎么变化，返回的是 Q2 FY26 那页柱状图（五个季度 $346M → $586M，同比 +69% Y/Y）——而这一页上根本找不到 change 或 over time 这两个词。模型匹配的是“五根递增的柱子”这个图像特征。
反过来看纯文本链路：同样的问题只会命中包含相关词汇的文字段，那张柱状图对索引是完全不可见的。这也解释了为什么很多企业知识库上线后，用户反馈“简单事实能查，趋势类问题永远答不准”——不是生成模型不行，是趋势信息在入库那一步就丢了。这类链路级失误，我们在 检索增强生成落地五个坑 里也复盘过。
多模态语料天然比纯文本敏感——录音里可能有客户信息，截图里可能是未发布的定价。私有化交付的边界建议按数据敏感度切，而不是按“整条链路”一刀切。
| 环节 | 建议归属 | 理由 |
|---|---|---|
| 原始音视频 / 未脱敏截图存储 | 必须本地 | 敏感原件不出域是合规底线 |
| 嵌入推理（含多模态编码器） | 必须本地 | 推理输入即原始内容，走外网即等价于外发 |
| 向量库与索引 | 必须本地 | 向量可反推语义，视为衍生敏感数据 |
| 模型权重下载 / 推理框架镜像 | 可托管 | Apache 2.0 权重，无数据泄露面 |
| 已脱敏的公开文档嵌入 | 可走托管 API | 内容本身已公开，无敏感性 |
EmbeddingGemma 2 的 Apache 2.0 协议意味着权重可以直接落到内网，推理框架也有充分选择：官方列出 transformers、sentence-transformers、MLX、vLLM、llama.cpp、SGLang、Ollama、LMStudio，微调可参考 Unsloth 的指引，向量存储官方点名了 Qdrant。对一个要求“数据不出域”的企业知识库而言，这套组合基本能把 270M 文本主干加按需的多模态编码器完整搬进内网。选型上，开源大模型私有化部署实测 里的评估方法同样适用于嵌入模型。这里要强调：私有化要验收的是“数据流向”，而不是某个具体加密技术的验收口径——判断标准是原始音视频、推理输入、向量索引三者是否都在域内，而不是把某一种可信执行环境写进合同。关于“数据不出域”的可证明口径，站内另一篇 「数据不出域」怎么被证明 有专门讨论，本文只做数据流向层面的划分，不重复其验收标准。
不一定。统一空间解决的是“查询向量与文档向量可比”，不解决召回质量均匀性——EmbeddingGemma 2 的视觉（170M）与音频（300M）编码器本身是可选的。工程上仍建议按模态分 collection、但共享同一模型版本，这样每个 collection 能独立调量化档位和召回数。
MRL 截断是渐进降级，不是无损压缩。512/256/128 三档是官方给出的可用区间，但具体损失取决于你的语料分布。上线前必须用自建评测集跑 recall@k 对照，而不是直接照搬官方数字。
从真实工单与搜索日志抽样，答案必须锚定到可定位单元（某一页 / 某时间戳），按模态分层，每组至少 30 条、总量 150–300 条起步。低于这个量级，跨模态的质量差异会被噪声淹没。
只做域内检索与排序时，740M 级别的自托管多模态模型在内网场景通常够用；但若涉及跨语言的复杂语义匹配或超大语料的高吞吐批处理，仍应以自建评测结果决定是否保留托管 API 作为补充，而不是凭直觉替换。