如果你做过检索类的项目大概率体验过这种别扭文本检索用文本嵌入模型图片检索又得找另一个视觉嵌入模型两套向量空间各说各话想做一个“用一句话同时搜文本和图片”的功能要么维护两个索引再手动融合要么额外训练一层映射怎么都不够痛快。EmbeddingGemma 2 正是冲着这个痛点来的一个 740M 参数的多模态嵌入模型把文本和图片映射到同一个向量空间支持文本、图像、图文拼接三种输入方式而且模型体量控制得很克制完全可以在本地显卡、甚至纯 CPU 环境下做推理。这篇文章就围绕这个模型把多模态嵌入到底解决了什么问题、本地部署怎么做、有哪些值得注意的坑一次说清楚。适合要做多模态检索、知识库问答、以图搜图或内容去重的开发者参考。1. 多模态嵌入到底解决了什么事1.1 从“两把尺子”到“一把尺子”先解释一个基础问题为什么多模态嵌入模型值得单独关注。常规做法里文本检索用文本嵌入模型图像检索用视觉嵌入模型两套模型各自输出向量但它们的向量空间没有对齐——文本向量和图像向量之间的余弦相似度没有意义。真要做图文混合检索常见办法是“文本召回文本、图片召回图片最后在应用层做加权合并”这个合并的权重往往要靠经验调而且不同类型的内容之间没法直接比较相似度。EmbeddingGemma 2 这类多模态嵌入模型则把文本和图片编码到同一个语义空间里。这有点像以前查资料得翻两本不同词典而现在是一本词典词条之间可以直接对照。用户在搜索框里输入一句自然语言系统可以同时召回相关的文本段落和相关图片用同一套相似度分数排序不需要再头疼“文本的0.75和图片的0.73能不能直接比”。这一点在处理真实业务时非常省心不用自己设计复杂的多路融合逻辑。1.2 740M 参数是个什么量级模型参数规模是很多人关心的问题。我的第一反应也是740M 会不会太小实际用下来这个担心可以放一放。嵌入模型和生成式大模型的任务逻辑完全不同。生成式 LLM 要“无中生有”地写句子需要大量参数存储世界知识和语言生成能力嵌入模型的任务只是把输入压缩成一个稠密向量本质上做的是“语义编码 排序”的工作不需要庞大的知识库也没有逐 token 生成的开销。740M 参数这个规模带来的好处非常直接。按 fp16 计算权重占用大约是 740M × 2 字节 ≈ 1.5GB即使是 fp32也就是约 3GB。这意味着 4GB 显存的入门显卡跑起来毫无压力8GB 显存可以开比较大的 batch 做批量索引构建没有独显的机器也能用 CPU 跑文本嵌入速度会慢一些但完全可用。加上现在很多业务对数据隐私有硬性要求模型能本地化部署是一个极有吸引力的点——向量化这块数据不出内网直接在本地算。1.3 典型的落地姿势多模态嵌入模型的应用场景我用实际项目里的几类需求来说明。第一类是多模态 RAG。知识库里既有 PDF 文本也有架构图、流程图、产品截图。传统做法是图片先转文字再进文本检索但截图里的版式、配色、图表结构一旦转文字就丢了。现在可以直接把截图编码成向量入库用户提问“我们系统的登录链路是怎么设计的”系统会同时召回相关代码文档和那张流程图效果比先 OCR 再检索稳定得多。第二类是电商或内容平台的融合搜索。用户描述“红色运动鞋适合跑步穿”系统需要同时匹配商品标题、描述文本和商品主图。统一的向量空间让文本和图片在一个索引里直接对比搜索结果更完整实现也更简单。第三类是内容去重和聚类。图文帖子、广告素材、用户生成内容都可以编码成同一空间的向量做相似度聚类找出“换了个标题但配图一模一样”的内容。不需要分别对文本和图片各做一套去重流程。2. 核心设计拆解融合结构、输出与训练目标2.1 不是简单的双塔而是带交互的融合编码多模态检索模型大致分两类。一类是双塔结构文本塔和图像塔完全独立最后只把两个向量拼在一起或相加这种结构工程上简单但文本和图像在中间层没有信息交互。另一类是融合结构文本和图像先各自编码成 token再送入同一个主干网络继续处理让它们在自注意力机制里互相“看”到对方。EmbeddingGemma 2 更接近后者。文本分支沿用 Gemma 系列的 decoder-only 编码方式图像分支由视觉编码器把图片变成若干图像 token再经过投影层映射到文本 token 的语义表示空间最后一起进入主干网络做交互编码。这种设计的好处是最终输出的融合向量不是简单拼接而是真正“理解”了文字和图像之间的关系。比如输入一段文字和一张图模型能知道“这张图是否在说文字里的内容”而不是仅仅把两边特征堆在一起。2.2 三种输入方式对应三种嵌入这个模型在工程上最实用的地方是支持纯文本、纯图像、图文拼接三种输入模式。纯文本模式就是常规文本嵌入适合处理文档、商品描述、用户 query。纯图像模式直接把图片编码成向量适合以图搜图、图片去重。图文拼接模式则是把一段文字和一张图片一起输入输出一个融合向量适合“商品主图 商品文案”这种成对内容建索引或者做图文相关性匹配。三种模式共用同一个向量空间这是非常关键的设计。业务方可以把文本数据、图片数据、图文组合数据全部放进一个索引查询时无论是输入文字还是输入图片都能和所有类型的数据向量直接计算相似度。我实际建过的一个知识库系统就是用一套索引同时承载了文档块、流程图截图、以及“截图 解释文字”组合三种数据整个架构非常干净。2.3 训练目标和 Matryoshka 带来的隐藏福利模型训练采用的思路是大规模图文对比学习让匹配的图文对在向量空间中靠近让随机采样的负样本对远离。这个目标保证了跨模态的语义对齐质量。更值得一提的是训练时采用了 Matryoshka 表示学习。简单理解这种技术让向量的“前一部分”也能独立携带语义信息。模型输出 768 维向量你可以只取前 256 维或 512 维检索效果损失通常在几个百分点以内。这意味着一开始就多了一种优化存储的手段向量库空间不够时可以截断维数来换容量这在后面实际部署时会重点讲到。3. 本地部署实操加载、编码与检索全流程3.1 环境准备和加载方式先准备环境。建议 Python 3.10 以上核心依赖是深度学习框架、transformers 库以及图片处理库。我习惯这样初始化python -m venv .venv source .venv/bin/activate # Windows 是 .venv\Scripts\activate pip install torch transformers sentence-transformers pillow注意一点这个模型在 transformers 里需要加载自定义代码所以trust_remote_codeTrue不能省。模型下载需要先去托管平台完成授权确认然后在代码里填入你权限对应的仓库 ID。import torch from transformers import AutoModel, AutoProcessor model_id 你的模型仓库ID/embeddinggemma-2-740m model AutoModel.from_pretrained( model_id, trust_remote_codeTrue, torch_dtypetorch.float16, device_mapauto, ) processor AutoProcessor.from_pretrained( model_id, trust_remote_codeTrue, )torch_dtypetorch.float16能把权重占用压到约 1.5GB这对小显存机器非常重要。如果推理环境换了新机器第一次会自动下载权重建议先单独跑一次加载脚本把权重缓存好后续离线也能用。3.2 三种输入的编码代码文本嵌入是最高频的使用方式代码很直接def encode_text(text: str): inputs processor( text[text], return_tensorspt, paddingTrue, truncationTrue, max_length512, ) inputs {k: v.to(model.device) for k, v in inputs.items()} with torch.no_grad(): outputs model(**inputs) return outputs[output_embeddings][0]图像嵌入类似只需要把 PIL 图片传进去from PIL import Image def encode_image(image_path: str): image Image.open(image_path).convert(RGB) inputs processor(images[image], return_tensorspt) inputs {k: v.to(model.device) for k, v in inputs.items()} with torch.no_grad(): outputs model(**inputs) return outputs[output_embeddings][0]文本和图片同时输入时把两个参数一起传def encode_pair(text: str, image_path: str): image Image.open(image_path).convert(RGB) inputs processor( text[text], images[image], return_tensorspt, paddingTrue, truncationTrue, ) inputs {k: v.to(model.device) for k, v in inputs.items()} with torch.no_grad(): outputs model(**inputs) return outputs[output_embeddings][0]这里有个实操细节EmbeddingGemma 系列在 transformers 里通常用output_embeddings这个键返回归一化后的向量不同镜像或版本偶尔会用别的键名。遇到KeyError别慌打印outputs.keys()看一眼就有答案一般就是text_embeddings、image_embeddings、output_embeddings这三种命名之一。3.3 入库和检索的完整小流程一个典型的本地检索流程分三步批量编码建索引、编码查询、计算相似度取 top-k。批量建索引时注意控制 batch 大小显存不够就把 batch 调小def encode_texts(texts: list[str], batch_size32): all_embs [] for i in range(0, len(texts), batch_size): batch texts[i : i batch_size] inputs processor( textbatch, return_tensorspt, paddingTrue, truncationTrue, max_length512, ) inputs {k: v.to(model.device) for k, v in inputs.items()} with torch.no_grad(): outputs model(**inputs) all_embs.extend(outputs[output_embeddings].cpu().numpy()) return np.stack(all_embs)因为模型输出的向量已经做了 L2 归一化检索时直接用点积就是余弦相似度不需要额外除以模长import numpy as np def search(query_emb, db_embs, top_k5): scores db_embs query_emb ids np.argsort(scores)[::-1][:top_k] return [(int(i), float(scores[i])) for i in ids]本地演示用 numpy 没问题数据量大就换正式的向量检索库。文本和图片向量统一入库检索时也不需要区分类型这正是统一向量空间最舒服的地方。3.4 关于维度截断和存储优化的补充前面提到的 Matryoshka 特性实践里可以直接用。768 维向量在向量库中单条占 768 × 4 字节 ≈ 3KB100 万条就是约 3GB如果截断到 256 维单条约 1KB100 万条约 1GB存储和检索耗时长尾差距非常明显。截断代码很简单emb_768 outputs[output_embeddings][0].cpu().numpy() emb_256 emb_768[:256] emb_256 emb_256 / np.linalg.norm(emb_256) # 截断后重新归一化注意截断后的向量一定要重新做一次 L2 归一化。模型输出的完整向量是单位向量但截断出来的子向量不是直接拿去算余弦相似度数值会有偏差。这个细节我在一个项目里踩过当时检索出来的排序明显异常排查半天发现是忘了重新归一化。4. 常见问题与排查技巧实录4.1 常见问题速查现象可能原因处理方式首次加载缓慢或一直卡住权重需从远程下载网络受限先手动下载权重到本地缓存改用本地目录加载加载时提示自定义代码被拒绝缺少 trust_remote_codeTrue加载参数里补充 trust_remote_codeTrue显存溢出 OOMbatch 太大或精度过高调小 batch、改用 fp16、加 max_length 限制输出向量维度和预期不符读错了输出键或没截断打印 outputs.keys() 核对键名相似度普遍偏高、区分度差截断后未重新归一化截断后重新归一化到单位长度图片结果明显不对图片方向、分辨率异常统一预处理图片转 RGB避免过小或挤压变形的图4.2 加载失败与离线部署本地部署最容易遇到的问题就是下载。模型权重动辄 1GB 以上网络状况不好的时候经常加载到一半就断。更稳妥的做法是找一台网络通畅的机器先跑一次加载代码把权重缓存好然后把缓存目录整体拷贝到目标机器代码里直接指向本地路径model AutoModel.from_pretrained( /data/models/embeddinggemma-2-740m, trust_remote_codeTrue, torch_dtypetorch.float16, device_mapauto, )需要确认的是模型仓库里的自定义模型代码文件也要一起拷贝别只拷权重。这个问题我在转移部署环境时遇到过权重有、代码文件漏了加载直接报错。4.3 显存和内存优化技巧小显存机器上的经验可以总结成几句话能开 fp16 就开 fp16图片按 batch 处理不要一张一张塞完整原图文本设置 max_length 截断不要让超长文本打满整个上下文窗口。实在挤不出显存也可以用 CPU 推理。740M 参数在 CPU 上跑文本编码单条大约几百毫秒到一两秒虽然相比 GPU 慢一个量级但对离线批量建索引来说依然可用。我的建议是建索引这种离线任务可以慢慢跑线上查询还是至少配一块 4GB 显存的显卡体验差别很大。4.4 检索效果不理想的排查方向如果检索效果不理想先不要怀疑模型按下面顺序排查。第一个方向是输入数据。文本过长时语义被稀释需要提前分块图片如果是旋转了 90 度的手机截图模型看到的构图完全不对检索结果自然乱预处理时统一转正、转 RGB。第二个方向是相似度计算方式。确认向量是否归一化确认向量库配置的是余弦距离而不是欧氏距离。第三个方向是召回策略。纯向量召回对精确关键词匹配不敏感比如搜“订单号 ERR-2024-001”这种向量相似度反而不如一个关键词匹配管用。稳妥的做法是混合检索向量召回 关键词召回合并再用简单加权或 RRF 算法融合排序这是我目前在业务里比较推荐的方案。5. 实践中积累的几个体会用这个模型跑了几个真实项目之后说几点个人体会。第一上生产之前一定要先拿自己的业务数据做评测不要盲信公开榜单。我习惯在项目早期抽出 100 组真实的图文对和 100 组难负样本跑一次召回率再决定要不要用。这比看任何宣传指标都实在。第二向量库的维数要一开始就定好。768 维还是截断成 256/512 维会影响索引结构和存储规划中途改维数意味着全部重建索引代价很高。如果预算紧建议直接上 256 维先跑通再评估精度损失。第三图文同时入库时一定要在元数据里记录每条向量的类型和对应的原始文档 ID。多模态索引里最痛苦的事情就是召回了一张图却不知道它属于哪个文档、哪一页、哪个章节没有丰富的元数据后面的“溯源”功能根本做不起来。最后这个模型在授权协议上有一些使用限制比如不能把它拿来训练或蒸馏成竞品嵌入模型用于搜索类产品时也有署名要求。商用前先仔细读一遍模型卡片的条款避免项目上线后被合规问题卡脖子。体量小、能本地跑、图文统一向量空间这三个特性放在一起让 EmbeddingGemma 2 很适合作为多模态检索系统的基础组件。把它和好的分块策略、混合召回、以及业务评测闭环结合起来是可以稳定支撑起一个完整检索服务的。