【论文深度拆解】轻量全模态向量的“瑞士军刀”：Google 新作 EmbeddingGemma 2 如何用 744M 参数与模块化架构破除多模态检索的显存与延迟魔咒

发表于 更新于 阅读次数： 本文字数： 5.4k 阅读时长 ≈ 20 分钟

在当今企业级多模态检索系统、视频知识库、多模态智能体（Agentic RAG）与本地端侧 AI 应用的研发中，软件工程师与系统架构师们最常遭遇的工程梦魇莫过于——多模态处理链路的“胶水化”与“臃肿化”。

面对音视频、图片与图文混排文档，传统的工程做法往往是将系统拆分为多级微服务流水线：音频 -> ASR 语音识别服务 -> 纯文本 -> 文本向量模型；或者 图片/视频帧 -> Caption 视觉打标服务 -> 文本向量模型。这种架构在工程上带来了灾难性的级联延迟、显存翻倍与网络 I/O 开销，更导致了严重的不可逆信息衰减（ASR 错字导致整条检索失败，Caption 抹杀细粒度几何视觉与背景声音）。而另一派做法——直接调用 8B 乃至几十 B 的重型多模态大模型（MLLM）提取向量，高昂的 GPU 显存门槛和低下的 QPS 吞吐，又让端侧部署与高并发服务化沦为天方夜谭。

2026 年 10 月底，Google 的 EmbeddingGemma 团队在 arXiv 上发布了最新前沿工作：

《EmbeddingGemma 2: Unified and Efficient Multimodal Representations》 (arXiv:2610.37364, 2026)

论文提出了轻量级、开源全模态向量模型 EmbeddingGemma 2。它仅用 744M 总参数量（纯文本仅 271M，图文仅 439M），以极具工业美感的“微内核 + 插件化”架构，将文本、图像、音频、视频乃至任意交错图文音混合数据原生映射至同一个 768 维超球面几何空间。在 Google Pixel 11 Pro 端侧设备上，其 INT4 量化版本的运行时峰值内存最低仅需 191 MB，一举打破了多模态表征在大模型时代的“显存墙”与“延迟墙”！

论文题目：EmbeddingGemma 2: Unified and Efficient Multimodal Representations
作者团队：Henrique Schechter Vera, Sahil Dua, Jovan Andonov, Tom Duerig, Mojtaba Seyedhosseini 等（Google EmbeddingGemma Team）
论文链接：https://arxiv.org/abs/2610.37364
开源地址：https://ai.google.dev/gemma/docs/embeddinggemma
开源协议：CC BY 4.0（权重与代码完全开源开放）
核心领域：Multimodal Embeddings, Vector Retrieval, Video Moment Retrieval, Audio Understanding, On-Device AI, Matryoshka Representation Learning (MRL)

01. 架构设计：微内核 + 插件化的“乐高式”解耦

在软件系统设计中，最忌讳的是“为了一个使用频次不高的偶发功能，将全系统的基底资源常驻占用翻上几倍”。工业界很多多模态向量模型往往铁板一块，无论用户只想做文本搜索还是做相册图文检索，都必须在显存中拉起一个完整的重型容器。

EmbeddingGemma 2 采用了极为地道的微内核（Microkernel）与模块化插件（Pluggable Encoders）解耦架构：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
             ┌─────────────────────────────────────────┐
             │    Audio Encoder (305M, Conformer)      │  ──► [可插拔音频插件]
             └────────────────────┬────────────────────┘
                                  │
             ┌────────────────────▼────────────────────┐
             │     Vision Encoder (167M, ViT-16)       │  ──► [可插拔视觉插件]
             └────────────────────┬────────────────────┘
                                  │
          Soft Tokens Interleaved │ (统一线性投影至 d_M = 512 维)
                                  ▼
┌──────────────────────────────────────────────────────────────────┐
│      Bidirectional Transformer Backbone (271M, Gemma 4 改造)       │  ──► [核心微内核]
└─────────────────────────────────┬────────────────────────────────┘
                                  │ Mean-Pooling & Linear Projection
                                  ▼
             统一的 768 维全模态对齐几何空间 (可 MRL 截断)

1.1 核心组件职责分工

  1. 主干微内核（Backbone，271M 参数）：
    • 继承自 Gemma 4 的自回归 Decoder，但在模型初始化阶段直接将因果因果掩码（Causal Mask）切换为双向自注意力（Bidirectional Attention）。
    • 配置为 n=24n=24 层 Transformer，隐藏层维度 dM=512d_M=512，最后接全局均值池化（Mean-Pooling）与线性投影层，归一化输出 768 维稠密特征向量。
  2. 视觉插件（Vision Encoder，167M 参数）：
    • 采用 Patch Size 为 16 的 Vision Transformer（ViT）。
    • 将输入的静态图片或视频帧切块编码，输出维度为 dV=768d_V=768 的连续 Soft Tokens，经由轻量线性投影层 ϕvis\phi_{\text{vis}} 映射至主干维度 dM=512d_M=512。
  3. 音频插件（Audio Encoder，305M 参数）：
    • 基于 Google Universal Speech Model (USM) 架构，由 2 层下采样卷积与 12 层 Conformer 模块构成。
    • 输入为 Mel Filterbank 特征，按 40ms 窗口进行时域切片，每秒音频稳定产出 25 个维度为 dA=1536d_A=1536 的 Soft Tokens，再经由 ϕaud\phi_{\text{aud}} 降维映射。

1.2 工程红利：显存与算力的弹性按需装配（Selective Modality Loading）

得益于输入层在进入 Backbone 前已由适配器完成统一维度对齐，该架构在工程部署时支持根据业务形态动态裁剪与按需装配：

业务场景 加载组件 总参数量 INT4 运行期内存 (Pixel 11 Pro 实测) 适用业务类型
纯文本/代码搜索 仅加载 Backbone 271M 191 MB 桌面级本地代码索引、企业内网文档检索、轻量 RAG
相册/图像检索 Backbone + Vision Encoder 439M 447 MB 手机端本地相册语义搜图、电商商品图像搜索、图文文档识别
语音/播客检索 Backbone + Audio Encoder 577M ~500 MB 语音备忘录搜文本、会议录音语义定位、跨语种音频检索
全功能多模态/视频 全部组件完整装配 744M 567 MB 复杂视频时序检索、多模态智能体、带音轨长视频理解

在现代移动设备上，整套全模态底座常驻仅消耗 500 多兆内存，即使在资源极其逼仄的边缘网关容器或本地客户端上也能游刃有余。

02. 数据协议与交互接口：统一序列化（Wire Protocol）与非对称指令

如何让一个模型在底层毫无歧义地解析一段“图文混排的 PDF 页面”、或者一段“带背景音乐和解说的动态视频”？EmbeddingGemma 2 没有设计多套复杂的通信通道，而是制定了如同 RPC 协议一般的统一多模态数据序列化规范。

2.1 统一的报文帧定界符（Delimiters）

模型将所有多媒体软 Token 与文本 Token 串联成一条最长为 8192 的扁平数组流，并用特殊定界符包覆：

1
2
3
4
5
全局序列流: <|BOS|> ⊕ [Segment 1] ⊕ [Segment 2] ⊕ ... ⊕ [Segment M] ⊕ <|EOS|>

• 文本段: [Text Token IDs]
• 图像段: <|SOI|> ⊕ [Vision Soft Tokens] ⊕ <|EOI|>
• 音频段: <|SOA|> ⊕ [Audio Soft Tokens] ⊕ <|EOA|>

2.2 视频时序切片的“音画交错（Interleaved Video-Audio）”设计

针对传统视频检索常年忽略音轨的缺陷，论文提出了极其简洁的物理时间对齐协议：

  • 采样基准：以 1 fps（每秒 1 帧）提取画面帧；
  • 最大帧数约束：全局设定每视频最多采样 Nfrm=32N_{\text{frm}} = 32 帧（长视频均匀采样，短视频直接截断）；
  • 物理时间戳嵌入：在每个画面帧和每 1 秒音频片段前，直接插入人类可读的 ASCII 文本时间戳 MM:SS！
1
2
3
4
5
【视频序列流在系统内部的实际展开方式】

[00:01] <|SOI|> [第 1 帧画面 Soft Tokens] <|EOI|> [00:01] <|SOA|> [第 1 秒原声音轨 Soft Tokens] <|EOA|>
[00:02] <|SOI|> [第 2 帧画面 Soft Tokens] <|EOI|> [00:02] <|SOA|> [第 2 秒原声音轨 Soft Tokens] <|EOA|>
...

软件工程直觉：不需要专门在 CUDA 算子层面去手写复杂的多模态交叉注意力同步逻辑，直接通过时间戳标头将时间信息转化为自然序列，后端的双向自注意力机制就能在单一前向传播中同时理解“画面在变化”与“伴随的语音/音效在推进”。

2.3 业务接入防踩坑：非对称任务前缀（Task Instructions）

在系统工程落地中，许多后端工程师习惯于将用户的原始提问直接喂给模型：

1
2
# ❌ 错误示范：直接裸传文本
query_embedding = model.encode("如何用 Python 读取视频？")

在双塔检索架构中，这种做法会导致检索召回率断崖式下滑。论文在 Appendix A 中严格规范了查询端（Query）与库端（Document/Target）的非对称协议：

1
2
3
4
5
6
7
8
9
10
11
• 用户检索查询端 (Query):
  "task: search result | query: 如何用 Python 读取视频？"

• 数据库入库端 (Document / Passage):
  "title: OpenCV 视频解码实战 | text: 使用 cv2.VideoCapture 可以快速..."

• 语义相似度匹配 (Semantic Similarity):
  "task: sentence similarity | query: {文本内容}"

• 代码库搜索 (Code Search):
  "task: search code | query: {代码功能意图描述}"

工程避坑建议：在微服务架构的 API 网关或数据接入层，务必将这一层模板拼装逻辑固化在中间件内，杜绝上层业务透传裸字符串。

03. 架构的“减法哲学”：为什么敢砍掉 PLE 查找表？

在 Gemma 3n 和 Gemma 4 的原始架构中，设计了一项名为 Per-Layer Embeddings (PLE) 的技术：为了给深层网络提供直接的残差指导，除了对输入进行线性变换外，模型还专门维护了一个庞大的专用 Token 查找表（Dedicated Lookup Table）。

1. 软件工程师的工程质疑

  1. 显存膨胀：该表必须为词表中的数十万 Token 维护独立的嵌入参数，白白吃掉宝贵的显存；
  2. 模态不公平（Modality Bias）：Lookup Table 依赖离散的文本字典 ID（Discrete Token ID），图像和音频映射出的是连续的 Soft Tokens，根本无法去查表！ 这导致模型在深层计算时，对文本产生了严重的私有加速通路，破坏了全模态联合空间的平衡。

2. 论文团队的减法改造与实测

团队大胆移除了专门的 Lookup Table，将 PLE 简化为纯线性投影（Projection-only）：各层直接从共享的输入嵌入序列 Tin\mathbf{T}_{\text{in}} 中进行门控投影更新：

Pl=RMSNorm(pl(Tin)),Gl=σ(gl(Hl′)),Ul=RMSNorm(ul(Gl⊙Pl))\mathbf{P}_l = \text{RMSNorm}(p_l(\mathbf{T}_{\text{in}})), \quad \mathbf{G}_l = \sigma(g_l(\mathbf{H}'_l)), \quad \mathbf{U}_l = \text{RMSNorm}(u_l(\mathbf{G}_l \odot \mathbf{P}_l))

在 MMEB-v2 基准上的对比实验直接证实了这一架构减法的优越性（Table 2）：

PLE 策略 参数开销 MMEB-v2 综合分 图像 Hit@1 视频 Hit@1 富文档理解 NDCG@5
带专用 Lookup 查找表 额外增加显存 55.07 54.57 47.13 61.76
纯投影架构 (Projection-only) 零冗余显存 55.46 (+0.39) 54.67 (+0.10) 47.82 (+0.69) 62.37 (+0.61)

工程启示：在多模态联合表征系统的设计中，不要轻易给单一模态开“后门特权”。剥离面向离散文本的专用查找表，不仅减轻了系统重量，而且消除模态偏置后反而全面提升了音画理解质量。

04. 训练流水线工程：三阶段演进与“放飞自我的学生”

EmbeddingGemma 2 在训练方法论上展现出了高度工业化的 Pipeline 设计。它不是盲目地将所有数据一股脑端到端硬训，而是精心构筑了三阶段课程学习（Curriculum Learning）：

flowchart TD
    subgraph S1["阶段 1：纯文本预热 (Text Pre-finetuning)"]
        D1["~300B Tokens 纯文本、代码、多语言数据"] --> M1["大 Batch Size (稳定梯度并增加批内负例)<br/>纯蒸馏模式 (Distillation) 学习 Gemini Embedding 2"]
        M1 --> W1["核心目的：将 Gemma 因果掩码无损过渡至双向自注意力"]
    end

    subgraph S2["阶段 2：全模态扩充蒸馏 (Multimodal Pre-finetuning)"]
        W1 --> D2["~2T Tokens 引入图像、音频、视频、跨模态数据"]
        D2 --> M2["继续维持大 Batch Size 纯蒸馏模式<br/>由大模型教师直接注入多模态对齐几何框架"]
    end

    subgraph S3["阶段 3：独立单飞微调 (Multimodal Finetuning)"]
        M2 --> D3["~600B Tokens 领域高精数据集 (商品搜索/医学影像/代码/工具)"]
        D3 --> M3["彻底停用蒸馏！<br/>全面转向对比学习 (Contrastive) + 正交正则 (Spread-out) + MRL"]
        M3 --> W3["核心目的：摆脱教师束缚，让 744M 小模型摸索最适合自身的紧凑流形"]
    end

    subgraph S4["阶段 4：收尾工程 (Post-Processing & Delivery)"]
        W3 --> Merge["单轨迹模型融合 (Model Merging along trajectory)<br/>未加权平均最终 Checkpoint 与早期 Checkpoint，抗过拟合"]
        Merge --> QAT["尾部补丁式 QAT (Tail-Patch QAT)<br/>冻结浮点权重单步蒸馏，低成本产出极高保真度的 INT4 Checkpoint"]
    end

核心工程思考：为什么阶段 3 坚决停用“大模型蒸馏”？

通常工程师会形成思维定式：“老师（Gemini Embedding 2）越强，学生一直亦步亦趋地蒸馏，性能肯定越好”。但消融实验（Table 3）给出了完全相反的结论：

训练阶段配置 算力消耗 MMEB-v2 综合分 图像 Hit@1 视频 Hit@1 富文档 NDCG@5
阶段 2 结束节点 基础基线 52.27 50.10 43.26 62.26
继续延长大模型蒸馏 等量计算预算 52.28 (+0.01) 49.74 (-0.36) 43.86 (+0.60) 62.40 (+0.14)
切换为对比学习独立微调 55.46 (+3.19) 54.67 (+4.57) 47.82 (+4.56) 62.37 (+0.11)
  • 底层直觉解释：教师模型拥有千亿级超大参数，其输出的几何空间如同“高维大平层”；而学生模型只有 744M，强行在微调期模仿老师的绝对空间坐标，等于把大户型家具生搬硬套进紧凑公寓，造成局部特征挤压变形。
  • 解法直觉：前两阶段用蒸馏完成“通识普及”，阶段 3 果断切断蒸馏，通过对比学习让小模型自主重构最适合 744M 容量的内部特征空间，单此一项改动就让图像与视频检索迎来了 4.5 个百分点的跨越式暴涨！

05. 视频特征工程：时序采样、音画交错与 140-Token 黄金甜点位

视频作为信息密度最高、动态变化最剧烈的媒介，在这篇论文中得到了最为详尽的工程剖析。

1. 视频 Token 预算的“暗坑”消融（Table 5）

在处理静态图像时，通常常识认为输入的 Token 越多、分辨率越高，识别越准。但对于视频，论文的消融实验揭示出了惊人的性能反转曲线：

1
2
3
4
5
6
【单帧 Vision Token 预算对视频检索性能的非线性影响】

单帧 70 Tokens  ──► Hit@1: 46.33  (时空细节丢失严重)
单帧 140 Tokens ──► Hit@1: 47.99  (性能稳步上升)
单帧 280 Tokens ──► Hit@1: 48.51  (接近饱和边际)
单帧 560 Tokens ──► Hit@1: 46.52  (暴跌 -1.99！发生明显的反噬)

为什么单帧 560 个 Token 反而会导致视频理解崩溃？

  1. 显存与序列爆炸：32 帧画面以单帧 560 Tokens 计算，将产生 32×560=17,92032 \times 560 = 17,920 个 Soft Tokens，远超常规自注意力计算的舒适区；
  2. 注意力钝化（Attention Dilution）：视频中的大量帧包含静止或无关背景，过度的 Token 数量会稀释注意力矩阵，模型开始在全局背景噪点中迷失；
  3. 均值池化（Mean-Pooling）稀释效应：最终向量是由全部输出 Token 做全局均值得到的。海量的静态背景 Token 权重严重冲淡了真正代表核心动作的局部关键 Token。

工业落地铁律：处理 PDF/扫描件时，Token 预算应拉满（560 Tokens 最佳）；而处理动态视频切片时，单帧 140 Tokens 是不可逾越的“黄金甜点位”。

2. 视频细分任务评测全貌（MMEB-v2 榜单实测）

在严苛的 MMEB-v2 视频细分赛道中，EmbeddingGemma 2（439M 视觉态）展现出了超越自身体量的统治力：

1
2
3
4
5
6
7
8
9
【EmbeddingGemma 2 视频专项能力全景】
• 视频分类 (Video CLS): 56.2 (识别场景主题与动作大类)
• 视频问答 (Video QA) : 48.6 (跨帧时序因果逻辑理解)
• 文本搜视频 (Video RET): 47.2 (自然语言定位视频片段)
• 视频时刻检索 (Video MRET): 50.6 (精确到秒级的时序定位)
─────────────────────────────────────────────────────────────
• 综合视频平均分 (Video All): 50.7
  - 超越同量级 Jina Embed v5 Omni Nano (986M, 仅 30.7 分) 整整 +20 分！
  - 超越 1.93B 规模的 Eddy-VL (50.0 分)！

06. 向量数据库落地实战：MRL 阶梯存储与正交化抗噪

算法模型的向量最终是要导入向量数据库（如 Milvus、Qdrant、PGVector）进行海量 ANN 索引与线上低延迟查询的。论文在向量空间几何设计上，为数据库研发人员准备了两大杀器：

1. Matryoshka（俄罗斯套娃表示学习）：多模态降维的“断崖预警”

EmbeddingGemma 2 原生输出 768 维向量，同时支持截取前 512、256 和 128 维使用。然而，论文实测揭示了文本与多模态在截断容忍度上的巨大分歧（Table 8 & Table 9）：

1
2
3
4
5
6
7
【MRL 截断维度对各模态性能的影响趋势】

维度规格      纯英文文本 (MTEB)   多语言文本 (MTEB)   多模态综合 (MMEB-v2)   多模态视频 (Video)
768 维 (基准)     68.5               61.4               59.0                 50.7
512 维           68.4 (-0.1)        60.8 (-0.6)        58.4 (-0.6)          50.3 (-0.4)
256 维           67.8 (-0.7)        60.4 (-1.0)        56.2 (-2.8)          49.3 (-1.4)
128 维           65.7 (-2.8)        57.9 (-3.5)        45.6 (-13.4！⬇)      40.6 (-10.1！⬇)
  • 纯文本：语义相对收敛，即便强行截到 128 维，性能折损依然控制在 3%~5% 以内；
  • 多模态：由于同时要承载图像空间几何、物体类别、视频时序变化以及声学特征，信息熵极高。截到 128 维会引发严重的几何流形碰撞（Collision），导致综合指标断崖式跳水 13.4 分！

数据库存储与检索选型方案：

  • 纯文本 RAG：直接采用 128 维，存储成本降低 83%；
  • 多模态与视频库：256 维是极限黄金甜点位——相比全量 768 维仅有不到 3 分的轻微折损，却能砍掉 66% 的显存、磁盘占用与网络传输带宽；切勿盲目把多模态向量压缩到 128 维！

2. Spread-out 正交正则化：拯救向量数据库的 HNSW 索引

在高维空间中，深度模型常常将所有样本的向量挤压在一个狭窄的圆锥体内部（即各向异性 Anisotropy），导致任意两个无关视频的余弦相似度可能都高达 0.85。这会导致向量数据库中的图索引（如 HNSW）产生严重的误导走偏，且向量量化（PQ/SQ）容错极差。

论文在训练目标中引入了基于全局正交正则（GOR）的 Spread-out 损失：

LS=1B(B−1)∑i≠j(qi⊤qj)2+1B(B−1)∑i≠j(pi+⊤pj+)2\mathcal{L}_S = \frac{1}{B(B-1)}\sum_{i \neq j}(\mathbf{q}_i^\top \mathbf{q}_j)^2 + \frac{1}{B(B-1)}\sum_{i \neq j}(\mathbf{p}_i^{+\top} \mathbf{p}_j^+)^2

它强行将随机采样的样本对在单位球面上推向互相正交（点积平方趋近于 0），把整个空间“完全撑开”。

系统工程收益：

  1. ANN 检索召回率大幅改善：高维球面的利用率被拉满，极大降低了相似向量扎堆造成的聚类歧义；
  2. 极佳的抗量化噪声能力：使得模型在做 INT4（Q4_0 / Q4_C）极限制裁时，精度损失几乎可以忽略不计（全精度 61.36 vs INT4 60.96）。

07. 竞品对比与工程选型直觉（VS Qwen3-VL、Jina Omni 等）

在评估引入新技术时，工程师最需要清晰的技术对比矩阵：

评估维度 EmbeddingGemma 2 (Google) Qwen3-VL-Embedding (Alibaba) Jina Embed v5 Omni Nano
整体定位 端侧级极致轻量全模态向量 云端重型高精度视文检索底座 开源轻量全模态尝试
总参数量 744M (视文 439M, 纯文本 271M) 2.0B / 8.0B 986M
原生模态支持 文本 + 图像 + 视频 + 音频 (语音/环境音) 文本 + 图像 + 视频 (❌ 无音频) 文本 + 图像 + 视频 + 音频
MMEB-v2 综合分 59.01 77.8 (8B 榜首) / ~71+ (2B) 43.61
视频专项得分 50.7 (大幅超车同量级) 极高 (70+ 水平) 30.7
端侧部署内存 Q4_C 下 191MB ~ 567MB (Pixel 手机直跑) > 2.0GB ~ 6.0GB (需高端云端 GPU) ~1.5GB 左右
代码搜索得分 78.68 (MTEB Code 越级绝杀) 未专门侧重轻量代码基线 缺失高分代码支持

选型决策树：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
你的核心业务场景是什么？
  │
  ├──► 追求极致准确率，预算充足，云端大卡常驻，解析超细粒度图表/PDF
  │     └──► 坚决选择 【Qwen3-VL-Embedding (2B/8B)】
  │
  ├──► 预算有限，高并发 API 服务，需要极速响应与超低每 QPS 成本
  │     └──► 首选 【EmbeddingGemma 2 (439M 视觉态)】
  │
  ├──► 手机端本地相册搜图、离线桌面应用、汽车智能座舱
  │     └──► 唯一解 【EmbeddingGemma 2 (Q4_C 量化版，仅占几百兆内存)】
  │
  ├──► 视频库检索且【包含关键对话、旁白或音效】(如影视库/短视频/播客)
  │     └──► 首选 【EmbeddingGemma 2 (音画交错原生提取，彻底抛弃 ASR 流水线)】
  │
  └──► 企业内网极轻量代码知识库 / IDE 智能搜索
        └──► 首选 【EmbeddingGemma 2 (仅加载 271M 纯文本微内核，78.68 分高维代码理解)】

08. 结语与系统架构师落地清单

Google 的这篇 《EmbeddingGemma 2》 是一篇典型“以工业系统落地为首要牵引”的优秀工作。它没有陷入无休止堆砌参数的学术游戏，而是用扎实的系统解耦、规范的数据报文以及严谨的训练消融，为多模态向量检索的轻量化与高可用指明了道路。

最后，为准备接入这套模型的架构师与开发团队梳理一份落地 Checklist：

  1. [ ] 动态按需加载：明确业务边界，纯文本业务严禁拉起视觉与音频塔，常驻内存保持在 200MB 以内；
  2. [ ] 必须加上指令前缀：接入侧 API 严格按 Appendix A 拼装 task: search result | query:，严禁裸文本传参；
  3. [ ] 视频切片规范：按 1 fps 采样，单视频帧数上限卡在 32 帧，单帧视觉 Token 预算严格限制为 140 Tokens，绝不盲目放大；
  4. [ ] 音画交错利用：若视频自带清晰音轨，直接启用 MM:SS 时间戳交错协议，无需再挂载额外的 ASR 语音识别服务；
  5. [ ] 数据库维度阶梯配置：纯文本库采用 128 维截断，多模态与视频库建议统一采用 256 维黄金甜点位，结合 Spread-out 正交特性，开启 HNSW 索引高吞吐检索。