企业官网建设流程全解析

如果你做过检索类的项目，大概率体验过这种别扭：文本检索用文本嵌入模型，图片检索又得找另一个视觉嵌入模型，两套向量空间各说各话，想做一个“用一句话同时搜文本和图片”的功能，要么维护两个索引再手动融合，要么额外训练一层映射，怎么都不够痛快。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_code=True不能省。模型下载需要先去托管平台完成授权确认，然后在代码里填入你权限对应的仓库 ID。

import torch from transformers import AutoModel, AutoProcessor model_id = "你的模型仓库ID/embeddinggemma-2-740m" model = AutoModel.from_pretrained( model_id, trust_remote_code=True, torch_dtype=torch.float16, device_map="auto", ) processor = AutoProcessor.from_pretrained( model_id, trust_remote_code=True, )

torch_dtype=torch.float16能把权重占用压到约 1.5GB，这对小显存机器非常重要。如果推理环境换了新机器，第一次会自动下载权重，建议先单独跑一次加载脚本把权重缓存好，后续离线也能用。

3.2 三种输入的编码代码

文本嵌入是最高频的使用方式，代码很直接：

def encode_text(text: str): inputs = processor( text=[text], return_tensors="pt", padding=True, truncation=True, max_length=512, ) 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_tensors="pt") 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_tensors="pt", padding=True, truncation=True, ) 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_size=32): all_embs = [] for i in range(0, len(texts), batch_size): batch = texts[i : i + batch_size] inputs = processor( text=batch, return_tensors="pt", padding=True, truncation=True, max_length=512, ) 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_k=5): 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 字节 ≈ 3KB，100 万条就是约 3GB；如果截断到 256 维，单条约 1KB，100 万条约 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 常见问题速查

4.2 加载失败与离线部署

本地部署最容易遇到的问题就是下载。模型权重动辄 1GB 以上，网络状况不好的时候经常加载到一半就断。更稳妥的做法是找一台网络通畅的机器，先跑一次加载代码把权重缓存好，然后把缓存目录整体拷贝到目标机器，代码里直接指向本地路径：

model = AutoModel.from_pretrained( "/data/models/embeddinggemma-2-740m", trust_remote_code=True, torch_dtype=torch.float16, device_map="auto", )

需要确认的是，模型仓库里的自定义模型代码文件也要一起拷贝，别只拷权重。这个问题我在转移部署环境时遇到过，权重有、代码文件漏了，加载直接报错。

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 很适合作为多模态检索系统的基础组件。把它和好的分块策略、混合召回、以及业务评测闭环结合起来，是可以稳定支撑起一个完整检索服务的。