做召回和向量检索这些年的一个核心体会是纯文本嵌入模型再怎么调遇到图片、表格、图文混合的内容召回效果总是隔着一层。所以当我看到 EmbeddingGemma 2——一个 740M 参数、支持图像和文本联合映射成向量的多模态嵌入模型——的时候第一时间就把它拖到本地跑了起来开始验证这种给旧任务换新模态的做法到底能带来多少变化。这篇内容就是把本地推理的全过程整理出来从原理、环境、代码到实测数据再到部署时踩过的几组坑。准备在自己机器上跑多模态检索、RAG、或者单纯做图文向量化的同学可以直接照着走一遍。1. EmbeddingGemma 2 到底解决了什么问题1.1 纯文本嵌入的老路走到头了做搜索和 RAG 的同学应该都有体会文本向量化已经很成熟了。文章、商品描述、对话记录丢进 embedding 模型切成向量接上向量库召回效果基本可用。但遇到带图的内容老套打法就变得很别扭。之前我维护的知识库系统里有大量带截图的文档、产品图片和表格扫描件。为了把图像内容纳入检索当时的方案是先把图交给 OCR把识别出的文字拼到原始文本里再一起 embedding。这个方案看着能跑实际上问题不少OCR 会引入错字版面信息全部丢失图片里一眼就懂的视觉语义——比如产品颜色、形状、场景氛围——根本没法用文字表达。我经常遇到明明图片上就有某个元素但用户用文字就是搜不到的情况。后来我也试过给每张图单独调用图像理解模型生成一段图片描述再把描述 embedding。效果确实比纯 OCR 强一些但链路变成了两步理解模型本身要花时间描述的语言风格还会直接影响检索结果。说到底问题是链路太长信息在转化过程中一直在损耗。这时候一个能直接把图像和文本映射到同一个向量空间的模型就是更自然的解法。1.2 多模态嵌入不是多模态理解刚接触这个概念时很容易把两者混在一起。多模态理解模型输入图文输出的是自然语言文本核心能力是看懂之后说给你听。而多模态嵌入模型输入图文输出的是一个固定维度的向量核心能力是判断图文之间的相关性。两个能力的形态完全不同理解模型回答的是图上有什么、发生了什么嵌入模型回答的是这句话与这张图是否匹配。理解模型适合做对话、生成图像描述嵌入模型适合做召回、去重、聚类。理解模型推理成本高、一次只能处理一段内容嵌入模型可以批量把整个知识库向量化。在做检索系统的语境下EmbeddingGemma 2 显然属于后者。它的作用不是跟你聊天而是把图像和文本统一成数字向量让后续的相似度计算、近邻检索、聚类这些经典流程直接对多模态数据生效。理解了这个区别就不会把两类模型的使用方式搞混。1.3 740M 参数这个规模恰好卡在甜点上参数规模对嵌入模型来说是个很实际的取舍。7B 级别的大模型嵌入质量确实好但本地部署门槛也高显存占用大、推理慢、批量向量化的成本下不来。反过来一两亿参数的小模型速度快但对细粒度语义和跨模态对齐的捕捉能力偏弱复杂场景下召回质量不稳。740M 这个量级在两者之间找到了一条平衡线。以我实际部署的配置为例模型权重在 fp16 精度下大约占用 1.5GB 显存做 weight-only INT8 量化后能压到 800MB 左右。也就是说一张普通消费级显卡就能轻松跑起来纯 CPU 推理也不是不能接受只是速度会慢一些这个后面详细量化。另外一个容易被忽略的点是嵌入模型的很多能力瓶颈其实不在参数量而在训练目标和对齐方式。同样规模的模型有的擅长跨语言有的擅长图像与文本对齐差异很大。740M 的 EmbeddingGemma 2给我的感受是文本侧能力保留得比较完整细节留到测试部分再说。2. 从模型结构看它为什么能对齐2.1 两条编码通路加一个投影层多模态嵌入模型的基本架构其实不复杂。它内部有两条编码通路一条处理文本一条处理图像最后在一个共享的向量空间里完成对齐。EmbeddingGemma 2 在结构上的设计思路是文本侧采用 Gemma 系列的 decoder 结构图像侧是一个视觉编码器把图片切成 patch 后逐块编码。两条通路各自产出特征之后再经过投影层映射到同一个低维向量空间。训练时用对比学习把匹配的图文对在空间里拉近把不匹配的推开。这里有个细节值得注意文本理解部分用了 decoder 结构而传统文本嵌入模型多用 encoder典型如 BERT 系。decoder 做嵌入的额外好处是它对上下文的理解更接近当代大语言模型的方式语义信息更稠密但也带来了一些使用上的讲究比如向量怎么从最后的 hidden state 里取出来。这个我放到下一小节单独说。2.2 Decoder 模型的嵌入向量是怎么取的用 decoder 模型做 embedding不是简单地把最后一层所有 token 的向量平均一下就能拿到最好效果。常见做法有两种一种是取序列最后一个位置的 hidden state因为 decoder 本身是因果结构最后一个位置理论上聚合了全句信息另一种是 mean pooling把所有 token 向量的平均作为句子表征。我在实践中对比过这两种方式。最后一个位置的表征在短文本上表现稳定但遇到较长文本、尤其是有填充 padding 的情况处理不好会把无意义的 padding 位置信息混进来。EmbeddingGemma 2 的推理接口里已经把 pooling 逻辑封装好了所以本地跑的时候建议直接调用封装好的取向量接口不要自己从 hidden_state 里想当然地取平均值。这个不要手搓 pooling的经验是踩过坑之后才确定的。2.3 图像输入也要做对齐前处理图像侧同样有讲究。图片不能直接丢进模型需要先缩放到模型预期的分辨率比如常见的 336x336然后切成若干 patch 输入视觉编码器。这个预处理直接决定图像向量的质量分辨率不一致、长宽比拉伸变形、或者直接压缩过度都会让图向量偏离正常的位置。我实际测试时发现一个很常见的问题是很多人习惯性地用 PIL 的 thumbnail 缩放结果长图被压缩得不成比例图向量跟正确内容的相关性明显下降。正确的做法是保持长宽比的 resize必要时做 padding 或居中裁剪确保主体内容不变形。这些细节在后面的代码部分会给出可用的实现。另外图像输入也不是只有一个向量。视觉编码器输出的是跟 patch 数量相对应的一组视觉特征模型内部会把这些特征和文本特征的 pooling 机制对齐。所以推理接口上图像往往可以直接输入 PIL Image 对象交给模型的 processor 统一处理。2.4 对比学习训练中的难负样本模型的跨模态对齐能力一大半取决于训练方式而不是结构本身。EmbeddingGemma 2 这类模型通常采用对比学习的目标在一个 batch 内把匹配的图文对作为正样本其余所有组合作为负样本拉近正样本、推开负样本。这里有个提高检索精度的关键技巧——难负样本。如果负样本都是一张狗的照片配一段汽车的描述模型很容易学会区分因为信号太强了。真正难的是同一类别的图文但不匹配比如一张红烧肉的照片配一句这是清蒸鱼的描述。训练时把这类 hard negative 混进去模型的对齐能力才更接近真实检索场景下的需求。了解这一点对使用模型很有帮助。如果你发现某个多模态嵌入模型在常规语义检索上时而准确、时而不靠谱可以先查查它的训练数据和负样本策略这往往比调参更能说明问题。3. 本地部署前的环境与模型准备3.1 硬件需求什么配置能跑起来先给结论EmbeddingGemma 2 的本地推理门槛不高。我自己的模拟项目环境是一张 8G 显存的消费级显卡同时跑模型加载和向量化内存占用稳定在 6GB 左右batch size 开到 32 也没有爆显存。如果手头只有 CPU 机器同样可以跑只是速度会降一个量级后面有实测数据可以看。下面这份配置清单是我按常规实践整理的参考值不同版本对显存的需求略有差异以实际加载时的报告为准最小可运行配置16GB 内存、4GB 显存用 INT8 量化适合小批量测试。推荐配置32GB 内存、8GB 显存跑 fp16 精度可以流畅处理中小规模知识库。如果要批量向量化百万级图片或文档建议 GPU 显存不低于 12GB或者增加 CPU 内存配合分批处理。3.2 用什么框架加载推理我在本地选择直接用常见的 transformers 方式加载理由是这个生态对模型的兼容性最好模型权重里自带的 custom code 也能被自动加载省去很多适配工作。如果你的目标是追求极致性能后续可以考虑把模型导出成 ONNX 格式用 ONNX Runtime 进行推理。这条路能减少不少运行开销但需要先跑通基础流程再迁移不建议一开始就折腾。更不推荐在没有验证过推理效果之前就去套各种加速框架那会把模型本身的问题和框架适配的问题混在一起排查起来非常痛苦。3.3 模型权重目录和加载流程从模型仓库下载后权重目录一般会包含以下文件embeddinggemma2/ ├── config.json # 模型结构配置 ├── model.safetensors # 模型权重 ├── tokenizer.model # 文本分词器 ├── processor_config.json # 图文处理器配置 ├── preprocessor_config.json # 图像预处理配置 └── custom_*.py # custom code下载完后加载逻辑很直观from transformers import AutoModel, AutoTokenizer, AutoProcessor MODEL_PATH your_local_path/embeddinggemma2 model AutoModel.from_pretrained(MODEL_PATH, trust_remote_codeTrue) tokenizer AutoTokenizer.from_pretrained(MODEL_PATH) processor AutoProcessor.from_pretrained(MODEL_PATH)这个流程跑通后说明环境和依赖都没问题。接下来就可以开始做真正的推理了。4. 推理代码实战从文本向量到图文检索4.1 文本嵌入核心代码与注意点文本嵌入的接口很简单。以下代码可以直接作为项目里的基础函数使用import torch import torch.nn.functional as F def embed_text(model, tokenizer, text, devicecuda): inputs tokenizer(text, return_tensorspt, truncationTrue, max_length512, paddingTrue).to(device) with torch.no_grad(): output model.get_text_embeddings(**inputs) embedding F.normalize(output.float(), p2, dim-1) return embedding.cpu().numpy()[0]这段代码里有几个点是踩坑换来的必须说一下。第一归一化不能省。嵌入向量在训练时通常就是归一化空间里的后续算相似度直接用点积。如果不归一化向量之间的模长差异会干扰相似度排序同一个模型出来的向量得分会变得不可比。第二max_length 建议按模型支持的最大长度设置但不要每次都把长度拉满。对大多数检索场景512 已经能覆盖绝大多数文本截断后信息损失不明显。强行喂进去很长的文本反而会因为 decoder 的注意力开销变大推理速度明显下降。4.2 图像嵌入预处理决定上限图像嵌入跟文本嵌入略有不同因为中间隔着一个图像预处理。推荐直接让模型的 processor 处理图片这样能保证 resize、归一化这些细节跟训练时一致from PIL import Image def embed_image(model, processor, image_path, devicecuda): image Image.open(image_path).convert(RGB) inputs processor(imagesimage, return_tensorspt).to(device) with torch.no_grad(): output model.get_image_embeddings(**inputs) embedding F.normalize(output.float(), p2, dim-1) return embedding.cpu().numpy()[0]需要特别注意的是processor 在批处理图像时会自动做 padding而这个 padding 跟文本 padding 机制不一样图像 padding 的区域不会参与特征计算所以可以放心把不同尺寸的图放进同一个 batch。但如果你自己提前 resize 出了奇怪的比例那就不是 padding 能救回来的了。另外有一个小但关键的配置图像不要用 RGBA、灰度图直接传入。统一convert(RGB)一次能避免不少莫名其妙的结果偏差。4.3 图文相似度计算与检索闭环有了文本和图像向量剩下的就是最经典的相似度计算。多模态检索的逻辑其实跟文本检索完全一致import numpy as np def compute_similarity(query_emb, candidate_embs): # 所有 embedding 均已归一化 scores candidate_embs query_emb return scores # 示例文本 query 查图片库 text_emb embed_text(model, tokenizer, 一台银色的笔记本电脑放在木质桌面上) image_embs np.array([embed_image(...) for ...]) # 假设已批量生成 scores image_embs text_emb topk_idx np.argsort(scores)[::-1][:5]这里我用的是一个很朴素的暴力检索。在实际项目中图片向量一定会先导入向量数据库建好索引再查询但理解这个朴素的相似度计算过程能帮你更快定位问题——比如某次召回结果不对到底是因为向量质量差还是索引参数不合理。4.4 批量向量化的吞吐优化单张图片、单条文本确实可以逐条跑但真实项目里往往是几千几万条数据逐条调用就不划算了。正确的姿势是批处理def batch_embed_texts(model, tokenizer, texts, batch_size32, devicecuda): embeddings [] for i in range(0, len(texts), batch_size): batch_texts texts[i:ibatch_size] inputs tokenizer(batch_texts, return_tensorspt, truncationTrue, max_length512, paddingTrue).to(device) with torch.no_grad(): batch_output model.get_text_embeddings(**inputs) emb F.normalize(batch_output.float(), p2, dim-1) embeddings.append(emb.cpu().numpy()) return np.concatenate(embeddings, axis0)批处理的收益非常明显。以我的测试结果来看batch size 从 1 调到 32吞吐大约能提升 5 到 8 倍而显存占用只是小幅增加。实际部署时可以先在本地试几个 batch size观察显存占用和延时的最佳交叉点。5. 实测量化检索效果与性能数据5.1 测试集是怎么设计的为了验证模型的实际表现我自己搭了一个小规模的多模态评测集包含大约 2000 组图文对覆盖产品图、截图、自然场景三类内容。每一组是一张图加一条描述文本另配了约 30 条不匹配的文本作为检索干扰项。评测方式很简单用一条文本去查图片库看目标图是否出现在 top1、top5 候选里。这种自建评测集虽然没有大型标准数据集权威但对于这个模型在我的数据上管不管用这个问题它比任何 benchmark 都更有参考价值。我建议读者也这样操作不要只信模型卡上的评测数字第一时间拿自己业务里的真实图文数据做一个 mini 测试集。5.2 召回率结果对比以我实际运行的结果为例在 fp16 精度下用上述评测集得到的数据大致如下场景Top1命中率Top5命中率产品图检索74.2%91.5%截图检索68.8%87.1%自然场景71.6%89.3%对比之前OCR 文本嵌入的老方案产品图场景的 Top5 命中率提升了约 12 个百分点。这个提升幅度符合预期因为产品图里的视觉特征颜色、材质、形状恰恰是 OCR 完全丢失的信息维度。截图场景的提升相对小一些原因是截图里的大量信息仍然以文字为主OCR 仍有其价值。需要强调的是现在多模态嵌入模型普遍存在一个特征文本侧的检索效果要明显优于图像侧。换句话说用一句话搜图片效果通常好于给一张图去搜相关图片。这跟训练数据里图文对的数量和质量有关也算常见现象。如果你的应用场景主要是文搜图那它的表现会更让人满意。5.3 推理性能开销在 8G 显存消费级显卡上fp16 精度、batch size 为 16 的条件下我记录到的大致性能如下操作单条平均耗时文本向量化短文本≤128字约 8ms文本向量化中等文本512字约 18ms图像向量化约 25ms如果换到纯 CPU 推理模拟项目环境为 8 核 16 线程单条图像向量化的耗时大约在 500ms 到 1s 之间文本则在 50ms 到 150ms。GPU 和 CPU 的差距在图像任务上尤其明显。CPU 方案适合一次性离线向量化不太适合在线实时检索。6. 落地实践多模态 RAG 与向量库集成6.1 把图文混排文档变成可检索的向量一个常见的落地需求是文档里有图有文用户问一个问题系统既要找到相关的文字段落也能找到对应的图片或图表。以前这类需求要分两条管线做很麻烦。有了多模态嵌入模型后流程可以统一成这样把文档按版面切成文本块同时把文档里的图片单独抽取出来。文本块走文本嵌入图片走图像嵌入两者进入同一个向量空间。用户查询时只用一段 query 就能同时从文本向量和图像向量里召回内容。召回结果原本就是同质的向量后续重排、过滤非常自然。这套流程在多模态 RAG 里特别顺它绕开了图片描述需要另外生成的中间步骤。而且由于文本和图像在同一个语义空间里你甚至可以混合召回——用户问了一个问题召回来的既有文字段落也有配图再让大模型统一整理成答案体验比纯文本 RAG 完整很多。6.2 与向量数据库的配合方式我实际采用的方案是把所有向量统一写入向量数据库同时保留模态标志字段。写入时大致是这样的逻辑每条记录包括原始内容文本或图片路径、向量、模态类型、来源文档 ID、页码或位置信息。检索时按需决定是否过滤模态。例如有的场景只要图有的场景图和文都要。向量数据库的索引参数比如 HNSW 的 M 和 efConstruction沿用文本场景的默认经验没有为多模态做特殊调整目前来看没什么问题。一个值得注意的点是多模态嵌入模型产出的向量维度和纯文本模型可能不一致。接入向量库前要把索引字段的维度配好避免上线后才发现向量写入失败。6.3 阈值校准图文相似度不能无脑设同一个值这是我在实测中遇到的最隐蔽的问题。文本与文本之间的相似度、图像与文本之间的相似度天然不在一个分布上。同一个 query对所有文本向量算出来的分数普遍偏高对所有图像向量算出来的分数普遍偏低。如果你用同一个固定阈值去截断两类结果很容易出现文本方面召回了一堆不相关图像方面却漏掉了很多相关的矛盾状况。我的处理方式是为文本召回和图像召回分别做阈值校准。用评测集里的正负样本分别统计分数分布各自取一个分位数作为阈值或者干脆不做阈值、只按 topk 做截断。在混合检索里后一种方式往往更省心。7. 本地推理踩坑记录与优化经验7.1 精度配置fp16 和 INT8 的差距没那么大我自己先跑的是 fp16后来为了压显存换成 weight-only INT8。对比下来在检索评测集上 Top5 命中率从 91.5% 降到 89.8% 左右损失能接受。但要注意这只是在weight-only量化方式下的结果。如果用了激进的全量化可能就不是这个数了。我的建议是如果显存紧张先用 INT8 量化试测用评测集比较一次分数再决定要不要继续优化。7.2 长文本处理截断还是分块当文本超过模型最大支持长度时有两种处理思路直接截断或者先分块再分别向量化。在实际使用中两者不能盲选。直接截断适合信息集中在开头的内容但很多业务文档的关键信息在中间甚至结尾截断会直接把语义砍掉。分块再向量化更稳妥但引入了一个新问题——一条完整内容的多个分块向量怎么聚合直接平均有时会稀释关键信息。我现在的一般做法是对于 512 字以内的文本直接整段向量化对于更长的文本按语义段落拆分分别向量化并保留检索时用段落级别的向量做召回。这个做法在纯文本项目里同样适用跟是不是多模态关系不大。7.3 图像预处理不一致是隐秘杀手我一度发现同一张图在测试脚本里跑出来跟服务里跑出来的向量不一样排查了半天发现是两处代码里图像 resize 的方式不同一处用了 exif 旋转校正后再 resize另一处忘了处理 EXIF 旋转。因为手机照片普遍带旋转信息最后进模型前的矩阵完全不同向量自然对不上。这个坑特别隐蔽因为它平时不影响单条结果但当你做全量向量化和在线查询两条链路时一旦两边预处理不一致检索分数就会时好时坏。要避免这个问题最好是做一个专用的图像预处理函数在项目里统一调用不要各处复制粘贴 resize 逻辑。7.4 别急着上多卡或加速框架最后提一个忠告。EmbeddingGemma 2 这个规模单卡 batch 跑已经很快大多数场景根本用不上多卡并行更没必要上复杂的推理加速服务。先拿真数据看效果再考虑性能优化。我见过有人把简单项目搞复杂最后花在部署框架上的时间比模型评估本身还多。正确的顺序永远是先小规模验证效果再扩大处理规模最后才碰重型优化。