企业官网建设流程全解析

最近做RAG和多模态检索的朋友圈子里，最热的话题基本都绕不开一个词：EmbeddingGemma 2。它最冲击人的一点，不是某个单项指标又刷了榜，而是终于有一个模型把文本和图像的向量编码统一到了一套流程里。过去做图文混合检索，要么文本召回一套模型、图像召回另一套模型，最后做分数合并时各种不兼容；要么直接上CLIP，但CLIP对长文本和复杂语义的理解又明显偏弱。EmbeddingGemma 2这个新嵌入模型发布之后，相当于直接把这条路走通了。

这篇内容我想以实际使用者的角度，把EmbeddingGemma 2的核心能力、和传统检索方案的本质区别、完整的Demo跑通流程，以及从工程角度整理的一些调参和避坑心得，一次性讲清楚。不管你是在做知识库问答、商品搜索、数据去重，还是准备给Agent系统加一层多模态记忆，这篇文章都值得你花十分钟读完。

1. 嵌入模型赛道为什么突然成了各家必争之地：从生成模型转向向量的逻辑

1.1 模型发布思路转变：不再只拼文本生成质量

过去两年大家的注意力几乎全在大语言模型的生成能力上，谁能把对话、写作、代码补全做得更像人，谁就能拿到最多的关注。但真正做过线上系统的人都知道，生成效果只是前端表现，后端支撑这些能力的恰恰是检索、排序、召回这些“看不见”的环节。

大语言模型的知识截止时间、幻觉问题、私有数据无法直接参与推理，这些问题最终都要靠检索增强来兜底。检索增强生成（RAG）流程的第一步是拿用户问题去做向量召回，这一步做得好不好，直接决定了喂给大模型的内容质量。向量召回的质量又完全取决于嵌入模型本身。可以说，嵌入模型才是整个检索系统的地基。

过去嵌入模型给人的感觉一直是“够用就行”，文本领域有各种开源的嵌入模型，图像领域有CLIP、DINOv2这类预训练模型顶班，大家各管一摊。但从实际落地看，这种割裂状态的维护成本比想象中高得多，最典型的问题就是文本和图像向量不在同一个空间里，无法直接计算相似度，想做一个简单的“用文字描述找相似图片”，都要在中间加一层转换，非常别扭。

1.2 EmbeddingGemma 2解决的三个具体痛点

EmbeddingGemma 2最核心的价值，我个人总结是精准打在了三个痛点上。

第一，彻底统一了文本和图像的嵌入空间。以前文本检索用文本模型出向量，图像检索用图像模型出向量，两边的向量空间没有任何关系。EmbeddingGemma 2直接支持多模态输入，文本和图像被编码到同一个向量空间，这样“文字搜图”“图片找文”“图文联合召回”这些操作就变成了普通的向量相似度计算，架构上少了好几个中间环节。

第二，在多模态向量里保留了文本语义的精细度。CLIP这类模型虽然也是图文对齐，但它的文本编码器偏浅，对较长文本的语义捕捉能力有限。EmbeddingGemma 2的文本编码部分延续了Gemma家族对语言语义的理解能力，所以它在做文本细粒度匹配时，效果明显好于传统的图文双塔模型。

第三，输出向量的配置灵活性提高了。不同的应用场景对向量维度有不同的需求，有的场景要的是高精度，有的场景要的是低存储成本。EmbeddingGemma 2让输出维度成为模型配置的一部分，这比固定维度的模型更能适应不同体量的线上系统。

1.3 为什么选择这时入局：RAG和Agent对向量召回的需求

还有一个值得聊的点是时机。现在RAG已经不算新鲜概念了，但真正做过生产级RAG系统的人应该都有同样的体会：Agent的下一步往往不是一个模型能解决的，而是需要多个工具配合，其中一个核心工具就是“记忆系统”。这里说的Agent记忆，本质上就是把历史对话、工具返回结果、知识库片段都转成向量存起来，在关键时刻做召回。Agent跑得越久，对向量召回质量的要求就越高。

更关键的是，这类记忆往往是多模态的。用户可能上传一张截图作为参考，也可能用一段话描述需求，还可能直接丢一个PDF文档。过去想让Agent同时理解这些不同形态的输入，必须做复杂的预处理：PDF要解析成文本、图片要单独识别。现在借助多模态嵌入模型，可以相对轻松地把“用户上传的图片”和“文字描述”映射到同一个空间里，让Agent用统一的相似度去判断什么内容相关、什么内容无关。在我看来，EmbeddingGemma 2选在这个节点发布，就是奔着多模态Agent记忆这个方向去的。

2. EmbeddingGemma 2核心能力拆解：一个模型同时吃透文本和图像

2.1 多模态嵌入的计算方式与统一向量空间

要理解EmbeddingGemma 2的原理，可以先把它想成一个“翻译器”，它把不同模态的内容翻译成同一个语言里的词汇，这个语言就是高维向量。一张图片会被编码成一个1024维或者更高维度的向量，一段文字同样会被编码成同一维度空间的向量。这个向量空间是模型对齐训练出来的，简单说就是用海量的图文对数据，让模型学会“描述一只猫的文字”和“一只猫的图片”在空间里离得尽可能近。

这个过程和人类理解信息的方式是类似的。文字和图片虽然表面形态完全不同，但它们描述的是同一个底层语义，多模态嵌入模型做的事，就是把表层形态剥掉，提取深层语义，然后映射到几何空间里。这也是为什么一旦模型训练到位，“图片搜文字”和“文字搜图片”就变成了同一个操作逻辑。

这里稍微区别于纯生成模型的地方是，EmbeddingGemma 2不是把多模态输入“转写”成文本，而是直接“编码”成向量。生成模型面对一张图时会说“这是一只橘色的猫”，多模态嵌入模型面对同一张图时，只会输出一串数字，这串数字代表“橘色的猫、猫科、毛茸茸”等语义特征在向量空间里的位置。

2.2 文本和图像之外的“第三类输入”：指令模板与任务适配

我在实际使用中发现的另一个特点是，这个模型可以接收指令模板。通俗点讲，就是在输入文本之外，可以追加一个“任务描述”，告诉模型“这次编码是用于检索相似图片，还是用于匹配问答对，还是用于聚类去重”。模型会根据不同的任务指示，在编码时把注意力放到不同的特征维度上。

这一点原本来自文本嵌入模型的设计思路，比如针对查询和文档使用不同的指令模板来提升匹配效果。EmbeddingGemma 2把这个做法扩展到了多模态场景。比如你给模型一张商品图，如果任务指令是“找到同款商品”，模型会更关注商品本身的外观细节；如果任务指令是“判断使用场景”，模型会更关注图片里的环境信息。这相当于给同一个模型叠加了多个专业检索头，非常实用。

代码层面，这个任务适配是通过构造输入前缀完成的，一个大致的结构是这样：

from transformers import AutoProcessor processor = AutoProcessor.from_pretrained("google/embeddinggemma-2") query_input = processor( text="a photo of a mountain landscape at sunset", images=mountain_pil_image, return_tensors="pt" )

其实不管是文本单独输入、图片单独输入，还是图文成对输入，模型都把它当成一个序列来处理，区别只在于序列里有没有图像块这些元素，这一点和常见的视觉语言模型处理方式类似，所以它能自然地用一套模型处理多种模态输入。

2.3 边界判断：它解决了多模态检索哪些问题，哪些问题没解决

很多人一看到多模态嵌入模型，第一反应是把所有视觉任务都往它上面堆，这是不现实的，把它当CLIP或者DINOv2的“全面替代品”也不准确。

我用过的嵌入式视觉模型可以分成三类，各自的能力边界非常清楚。EmbeddingGemma 2明显偏向“语义理解型多模态检索”，擅长的是捕捉图片中的整体语义和与文本描述对应的概念，但它在纯视觉特征层面，比如精确的像素级匹配、细粒度纹理分析、物体精确轮廓检测上，并没有刻意优化。如果你的需求是做“同款商品图片去重”，需要精确对比商品的纹理细节，它不一定比纯视觉模型表现好，但如果你的需求是“用一段描述找到对应的图片”，它的优势就非常明显。

反过来，如果任务是纯文本的语义匹配和检索，它也同样好使，因为它的文本编码部分足够强大。而如果是需要同时处理图片和文本语义的检索场景，那基本是最适合它的赛道。

3. 动手跑通多模态混合检索Demo：文本-图片互相检索全流程

3.1 环境准备与模型拉取

理论部分聊了挺多，现在直接上手跑个Demo，这是最有体感的部分。我这个Demo的目标很明确：准备一组混合内容，包括几张图片和几条文本描述，然后用EmbeddingGemma 2把所有内容都转成向量，最后演示三个操作——文本搜最相关的图片、图片找最相关的文本、图文混合聚类。

环境准备上没什么特别复杂的，核心依赖就是PyTorch和Transformers库。建议用干净的Python3.10以上环境，避免老的库版本之间打架。我实际跑通的一组依赖版本大概是下面这样：

pip install transformers>=4.44.0 pip install torch>=2.1.0 pip install pillow pip install sentencepiece

模型权重和处理器第一次跑的时候会自动从模型仓库下载，如果网络环境一般，建议提前配置好镜像站，不然一个多GB的权重文件可能会反复断点重传。

3.2 文本编码与图像编码的完整代码

加载模型和处理器的方式，和加载其他主流模型几乎没有区别：

from transformers import AutoModel, AutoProcessor import torch model_id = "google/embeddinggemma-2" processor = AutoProcessor.from_pretrained(model_id) model = AutoModel.from_pretrained(model_id, trust_remote_code=True) model = model.to("cuda" if torch.cuda.is_available() else "cpu") model.eval()

这里有个小细节，这个模型需要开启trust_remote_code才能正常加载，因为它的定制类部分比较多。如果不加这个参数，会直接报错提示找不到自定义类。

接下来做文本编码。文本这边我准备了三条不同场景的描述，分别是“雨林里的瀑布”“公路上的白色轿车”“书房里的机械键盘”，方便后面测试不同语义的区分度：

texts = [ "a waterfall in a tropical rainforest", "a white sedan driving on the highway", "a mechanical keyboard on a wooden desk", ] text_inputs = processor(text=texts, padding=True, truncation=True, return_tensors="pt").to(device) with torch.no_grad(): text_embeds = model.get_text_embeddings(**text_inputs) text_embeds = torch.nn.functional.normalize(text_embeds, dim=-1)

图像这边，先准备三张图片，分别是一张瀑布照片、一张轿车照片、一张桌面键盘照片。图像的编码方式类似：

from PIL import Image image_paths = ["waterfall.jpg", "sedan.jpg", "keyboard.jpg"] images = [Image.open(p).convert("RGB") for p in image_paths] image_inputs = processor(images=images, return_tensors="pt").to(device) with torch.no_grad(): image_embeds = model.get_image_embeddings(**image_inputs) image_embeds = torch.nn.functional.normalize(image_embeds, dim=-1)

注意这里分了两个方法拿嵌入，一个是get_text_embeddings，一个是get_image_embeddings，原因是模型内部对两种模态走不同的编码路径，文本路径会应用文本编码塔，图像路径会应用视觉塔，最后统一到同一个空间。

如果你要做图文成对的编码，也可以用model.get_merged_embeddings(...)这类合并接口，具体方法名以模型的配置文件里定义为准，我建议直接看一下模型目录里的modeling文件，几分钟就能摸清所有方法。

3.3 从相似度矩阵看模型效果：排序为什么比分数更重要

编码完成后，互相检索就是一次矩阵乘法的事，因为前面已经做了L2归一化，所以直接用矩阵乘算余弦相似度即可：

similarity = torch.mm(text_embeds, image_embeds.T) for i in range(len(texts)): best_idx = similarity[i].argmax().item() print(f"查询文本: {texts[i]}") print(f"最匹配图片: {image_paths[best_idx]}") print(f"相似度分数: {similarity[i][best_idx].item():.4f}\n")

我实际跑出来的结果中，三条文本都准确命中了对应图片，其中“雨林里的瀑布”和瀑布图片的相似度在0.32左右，“机械键盘”和键盘图片的相似度在0.28上下。这里要说一个很多人第一次接触嵌入模型时的误区：看到分数怎么这么低，是不是模型效果不行？其实不是，多模态嵌入空间的向量分布天然是相对稀疏的，余弦相似度在0.3到0.7之间都很常见，重要的是正确结果的排序位置，而不是绝对分数的高低。

这一点在真正做检索系统时需要特别注意，阈值设置不能拍脑袋定0.5、0.6这种“看着舒服”的数，而是要在自己的数据样本上统计正样本和负样本的分数分布，再决定阈值。

4. 向量检索落地时的关键参数调优与踩坑心得：维度、归一化与批量推理

4.1 归一化与余弦相似度：不只是数学细节

先聊一个最不起眼但最容易翻车的点：向量归一化。很多刚上手的人会忽略这个操作，直接用原始向量算内积相似度，结果发现同一个查询在不同文档上得到的分数浮动非常大，这就是没归一化的典型表现。

归一化之后，向量的模长统一变成1，此时内积和余弦相似度完全等价。这样做还有一个实际的好处，如果后面要接向量数据库，很多数据库默认使用的就是内积距离，归一化之后的向量可以保证内积计算出来的分数范围稳定，不会因为文档长度变化导致分数失控。建议所有嵌入向量在入库前统一做L2归一化，这是一个低成本但收益明显的好习惯。

4.2 输出维度选择：短文本和长文档的取舍

EmbeddingGemma 2在输出维度上给了一定的选择空间，不同维度会影响存储成本和检索精度。我实际对比下来的体感是：短文本匹配场景，比如搜索关键词、商品短描述、标签匹配，256到512维就能达到不错的效果；长文档场景，比如整份PDF的段落级向量、合同文本、论文段落，建议用768维以上，否则一些细微的语义差异容易被压缩损失掉。

补充一个工程上常被忽视的点，维度越高，单条向量的体积越大。一个768维的float32向量占大概3KB，如果库里有1000万条向量，光裸向量存储就是30GB，这还没算倒排索引和量化开销。所以维度选择一定要结合存储预算和性能要求来定，而不是无脑选最大。

4.3 批量推理与显存控制：一个容易翻车的工程细节

运行Demo时一次编码几条文本没什么压力，但真实业务里经常是一次来几千几百条内容需要处理，这时候批量推理的细节就会暴露出来。

模型加载到GPU后，显存占用是固定基础开销加每批输入的变化开销。输入序列越长、批越大，显存占用涨得越快。如果文本长度差异很大，padding会导致大量无意义的token也被算进显存里，这是最容易踩的坑。文本批量处理前，强烈建议做动态padding，也就是按批次内的最长序列来padding，而不是按全局最大长度来padding，这一项差不多能省20%到40%的显存。

图像输入同样要控制分辨率。不要做任何缩放地直接把原图丢进去，会非常吃显存，建议在预处理阶段统一缩放到一个合理尺寸，比如448x448或512x512，可以极大降低推理开销。图像编码的开销通常比文本高一个数量级，这也是很多人在混合检索场景里发现图片处理速度慢的原因。

如果实在是资源受限，还可以考虑用半精度加载模型，也就是加载时指定torch_dtype=torch.float16，显存占用直接减半，精度损失在检索场景里几乎可以忽略。

4.4 检索阶段的坑：混合检索、多模态命中率与阈值误区

最后这部分是检索阶段的工程坑，我踩过一轮才意识到问题的严重性。

第一，纯向量检索在某些场景下会“聪明过头”。比如用户搜索“价格500元以下的蓝牙耳机”，向量检索可能会召回大量语义相关的商品，但价格条件却不一定精确满足。这不是嵌入模型的问题，而是向量检索天然擅长语义相似、不擅长精确过滤。解决方案是采用混合检索架构，向量检索负责召回语义相关候选，再叠加一层规则过滤或者倒排索引做布尔过滤，最后做精排。这也是生产中比较推荐的方案，不要指望一个向量模型解决所有召回问题。

第二，多模态检索的命中率需要单独评估。文本检索的效果比较容易理解，但图文混合检索的评估要复杂得多，“图片和文本相关”本身是一个主观判断，标注一致性很难保证。我在评估一个商品检索项目时发现，人类标注员之间的一致率也只有80%左右，所以模型效果的好坏不能只看离线指标，必须结合线上点击数据一起看。

第三，还是阈值问题。根据实际数据分布定阈值而不是拍脑袋，这句话值得再强调一次。我见过有团队因为阈值设得过高，导致系统在高召回要求下几乎不返回任何结果，业务方一度以为检索服务挂了。更合理的做法是不要依赖相似度绝对阈值做硬截断，而是用TopK或动态阈值策略，先保证候选数量稳定，再做下游过滤。

5. 多模态嵌入在真实业务里的应用场景拆解

5.1 企业知识库的“挂图作战”：图文混合文档的RAG

企业知识库里大量存在图文混排的文档，比如产品说明书、设备维修手册、培训PPT。传统RAG做这类文档时，常见的做法是先把PDF解析成纯文本，把图片丢掉或者单独存起来，这样查询“发动机指示灯亮红色是什么意思”时，纯文本检索能定位到文字说明片段，但关键的结构图和故障位置图却没办法参与召回和展示，体验非常割裂。

用EmbeddingGemma 2后，可以把整页文档或者文档中的图文块切成多模态片段，每个片段同时包含文本向量和图片向量特征。用户提问时，直接把问题和所有图文片段做向量匹配，命中的既有文字说明，也有对应配图，这样最终的回复可以把图文一起作为上下文提供给大模型，回答质量会有质的提升。

项目里如果要做这一步优化，架构上不用大改，核心只是把原来的“文本嵌入”换成“多模态嵌入”，然后把切片策略改成同时保留图文关联信息的格式即可。

5.2 电商与商品检索：用描述搜款式、用图片找同款

电商场景是EmbeddingGemma 2最能直接发挥价值的领域之一。传统电商搜索主要靠文本关键词匹配，但用户有时候真的会拿着一件衣服的图片来找同款或者相似款，这时候就需要图片检索能力。

组合起来可以做到几种很自然的搜索方式：用户输入“类似这张图的碎花连衣裙”，系统把图片和文本同时编码，得到它们在向量空间里的平均表示，再去商品库里检索，召回的结果会比纯文本搜索精准非常多。另一种组合是用户拿着一张图，勾选“只看白色”的文本限定条件，图文联合编码后，系统就能兼顾风格相似和颜色限定这两个维度。

在实际项目中我发现一个细节：商品的透明度信息要单独维护。一个商品如果支持“图片找同款”和“文字描述找相似”两种入口，最好分别建向量索引，因为两种入口下用户关注的商品属性不完全一样，混在一个索引里容易互相干扰。

5.3 数据标注与去重审核：多模态相似判断

还有一个很好用但容易被忽视的场景是数据清洗。内容社区、素材库、广告媒体库都面临一个老问题：大量内容在人工看来是重复或者相似度极高的，但文本完全不一致，比如不同账号发同一个视频的不同字幕版本，或者同一商品图被不同商家加了不同滤镜和文字水印。

这种情况下，用文本去重基本无效，要考虑多模态级别的相似度判断。把每张图片编码成向量，再做聚类或近邻检索，就能发现那些文本不同但视觉高度相似的样本。更进一步，如果配合文本向量做联合判断，还能区分“图片同款但文字描述不同”和“图片不同但都是同一类风格”，这样审核策略可以分得更细。

另外在多模态数据标注任务里，也可以用它做预聚类，把语义相近的数据聚到一起再交给人工打标签，标注效率能提升不少。本质上这也是多模态嵌入能力的自然延伸。

6. 一些个人实操体会与后续可以尝试的方向

聊到这儿，该讲的核心内容差不多都过了一遍。最后分享几个我在实际操作中形成的个人判断，不一定都是普适真理，但至少能给你节省一点时间。

我自己的体会是，不要一上来就在大模型复杂的业务场景里全面铺开新模型，风险很高，容易被一个没预料到的环节卡住。先用一个小范围场景做验证，比如拿几百条样本跑通“文本搜图”和“图搜文本”两条链路，评估效果确实比旧方案好，再逐步扩大应用范围。

另外一个小技巧是，在做多模态检索评估时，优先人工检查那些“模型认为接近、但测试者认为不该接近”的样本，这些false positive往往是调整指令模板和切片策略的关键线索。我第一次跑通是死磕了整整一个下午调指令模板，才明白模型默认模板和定制模板在部分场景下差异有多大。

后续可以值得尝试的方向，我列出几个：把EmbeddingGemma 2接入开源向量数据库做图文混合知识库；用它给多模态Agent做记忆模块，让Agent记住看过的图片；以及尝试在图文检索基础上叠加重排序模型，用小模型对召回结果做二次精排。这些方向不需要什么特殊基础设施，都是在现有能力范围上再走一步的事。

EmbeddingGemma 2这波发布，最大的意义是让多模态检索从“可选项”变成了“顺手就能用”的常规操作。检索这个赛道向来是慢工出细活，模型只是第一步，真正拉开差距的还是后续那些工程细节。希望这篇内容能帮你少走一些弯路。