企业官网建设流程全解析

1. 多模态离线RAG是怎么来的，以及为什么选EmbeddingGemma 2

先说个实际场景。我之前在给内部知识库做问答系统的时候，遇到一个很头疼的问题：很多PDF、Word文档里不只是纯文字，还有产品截图、表格截图、流程图，甚至在制造业和医疗行业，很多有效信息干脆就是图片里的文字或标注。用传统纯文本embedding跑RAG，图片直接被丢掉，问"那个图里的参数是多少"就完全答不上来。后来意识到，要解决这类问题，就得让文档里的图片也参与检索，也就是多模态RAG。

多模态RAG的常规做法是走"图片描述生成"路线——先把图片喂给视觉大模型生成一段文字描述，再对描述文本做向量化。这方案有效但麻烦，因为每一张图都要跑一次推理，批处理慢、成本高，而且描述的内容会丢失很多细节。另一条路就是直接用多模态embedding模型，把文本和图片映射到同一个向量空间，让"图片本身"和"文字描述"都能被检索到。EmbeddingGemma 2就是为这条路设计的，特别是740M这个参数版本，正好卡在本地离线部署的甜点上。

再说"离线"这个需求。很多企业场景数据敏感，文档不能出内网，更不允许送到第三方API去向量化，本地化部署是硬要求。而离线部署的难点不只是模型权重怎么下载，更在于显存占用、推理速度、与现有LLM的对齐方式这些都得更抠细节。EmbeddingGemma 2 740M模型本身大小约1.4GB（fp16），向量维度896维，支持最长4096 token的文本以及192个视觉token的图像输入，这意味着普通16G内存的消费级显卡也能跑，甚至是纯CPU环境也可以接受。这篇文章把我实际跑通的完整流程、踩过的坑、还有调优心得整理一遍，给正好在评估离线多模态RAG方案的朋友做个参考。

2. EmbeddingGemma 2技术拆解：这个模型到底强在哪

2.1 模型结构与关键指标

EmbeddingGemma 2是Google推出的第二代嵌入模型系列，有2B和740M两个尺寸版本。740M版本基于Gemma 2 2B的backbone裁剪蒸馏而来，在保持小型化的同时继承了Gemma 2优秀的语义理解能力。核心指标如下：

比较关键的是896维输出。市面上很多模型比如OpenAI的text-embedding-3-small是1536维，BGE系列是1024维，Nomic Embed是768维。维度和检索效果没有绝对关系，但会影响索引文件大小和检索速度。896维在一众embedding模型里处于中间位置，在信息表达丰富度和存储开销之间找到了一个不错的平衡点。

2.2 多模态能力是怎么实现的

EmbeddingGemma 2训练时使用了对比学习方法，目标是让文本和图像在同一向量空间中的距离有语义意义。具体来说，模型内部有独立的文本编码器和视觉编码器，两者产生的隐向量被投影到同一个嵌入空间。因此支持四种检索模式：

• 文本检索文本：和传统embedding一样
• 图像检索文本：用图片去搜相关文本描述
• 文本检索图像：用文本搜图片
• 图像检索图像：用图片搜相似图片

这个能力非常实用。比如我们知识库里有一张架构图，用户输入"网络拓扑"就能把这张图捞出来；反过来，用户上传一张截图，系统能找出解释这张图的文字段落。这个能力在传统方案里需要同时部署文本模型和视觉模型才能实现，现在一个模型搞定。

2.3 740M版本和2B版本怎么选

两个版本我都在本地跑过。2B版需要显存至少6GB（fp16推理），速度也慢不少；740M版只需2GB左右显存，batch size 8跑起来也毫无压力。从检索效果看，2B版在长文本（超过1K token）场景确实更好，但740M版通过配合合理的分块策略，完全能弥补这个差距。我的建议是：先在自己的数据集上分别跑round-robin测试，用Recall@N和MRR做对比，差在3个点以内就直接上740M，部署和运维成本都比2B香太多。

2.4 与BGE、CLIP、Ada-002的横向对比

CLIP的问题在于它只"懂"图像内容而不太"懂"文本语义，拿来做多模态RAG检索时召回率不稳定。BGE-M3和Ada-002都很优秀，但都是纯文本，解决不了图片参与检索的问题。EmbeddingGemma 2是当前少数能把"文本+图片统一向量化、本地离线跑"做完整的模型。

3. 实操准备：环境搭建与模型加载

3.1 硬件需求评估

先说明我自己的环境：单张RTX 3060 12G显存，64G内存，Linux系统。740M模型fp16加载大约占用1.4GB显存，比如做RAG，还需要同时跑本地LLM，一般建议显存至少8GB比较从容。如果条件再紧张一点，CPU推理也可以跑——EmbeddingGemma 2的推理速度在CPU上虽然慢，但embedding任务是一次性批量处理，可接受。实测纯CPU（16核虚拟机）跑740M模型，文本embedding速度约为每秒15-20条（平均长度512 token），图片embedding每秒约2-3张。批量离线处理几百份文档，也不用等太久。

3.2 依赖安装与模型下载

JSON、transformers、torch、faiss这些基础依赖我就不啰嗦了，重点说下模型的加载方式。EmbeddingGemma 2官方权重发布在HuggingFace上，可以通过transformers直接加载。当前支持需要使用transformers 4.46版本以上，建议直接用最新稳定版。官方代码加载方式：

import torch from transformers import AutoModel, AutoTokenizer model_id = "google/embeddinggemma-740m" tokenizer = AutoTokenizer.from_pretrained(model_id) model = AutoModel.from_pretrained( model_id, trust_remote_code=True, torch_dtype=torch.float16, device_map="cuda" ) model.eval()

这里几个细节非常关键：

第一，trust_remote_code必须为True，因为模型使用了自定义的建模代码，不开启会直接报错。

第二，torch_dtype建议设为fp16。如果显存足够，fp32精度更高但显存翻倍；如果很紧张，可以用8bit量化加载，效果损失在评测里约为1-2个点（MAP@10）。

第三，device_map设auto，让transformers自动把模型放到GPU上。如果只想用CPU，可以不传这个参数，模型会默认在CPU上跑。

3.3 模型加载时的常见报错

加载阶段最常见的报错是KeyError: 'embeddinggemma'，原因是transformers版本过低，不含该模型架构。解决办法就是升级transformers到最新版。另一个报错是CUDA out of memory，发生在显存小于2GB或者同时跑了其他大模型的情况下。这时候建议把fp16改为8bit量化，或者改用CPU跑。

还遇到过TrustRemoteCodeError，这是transformers对远程代码的安全提示。因为EmbeddingGemma 2使用了自定义的模型类，不在transformers内置模型列表中，这是正常现象，确认权重来源可靠（官方仓库）即可放心打开。

4. 完整离线RAG流程：从文档到答案检索

4.1 文档预处理：混合内容的解析

文档预处理是整个流程里最容易被低估的环节。我的经验是：无论PDF、Word还是HTML，都要先转成统一的中间格式，再做分块和切图。

具体流程：

1. 文本和图片分离。用PyMuPDF解析PDF时，除了提取文本块，还需要识别页面上的图像对象并单独保存。注意，这里有一个技巧：文本块的坐标和图片对象的坐标可以关联起来，后续做chunk时可以知道每一段文字附近有哪些图。

2. 图片裁剪与缩放。直接从PDF抽取的图片分辨率参差不齐。EmbeddingGemma 2的视觉编码器期望输入分辨率1408x1408，内部会切分为192个patch。建议把图片等比缩放到最大边1408px，不够的直接补边。这里不建议暴力拉伸，否则会影响OCR和特征提取效果。

3. 构建多模态chunk。对每一段文字，检查它周围是否有图片，如果有就把图片token追加到文本token之后，组成一个"图文混合chunk"。这个chunk就是后面向量化的最小单元。

from transformers import AutoProcessor processor = AutoProcessor.from_pretrained("google/embeddinggemma-740m") # 文本+图片混合输入 text = "这是架构说明段落" image = load_image("diagram.png") inputs = processor( text=text, images=image, return_tensors="pt", padding=True, truncation=True, max_length=4096 )

4.2 向量化与索引构建

向量化这一步可以直接调用模型的forward方法：

with torch.no_grad(): outputs = model(**inputs.to("cuda")) # 获取归一化之后的向量 embeddings = outputs.last_hidden_state[:, 0] # [CLS] token embeddings = torch.nn.functional.normalize(embeddings, p=2, dim=-1) embeddings = embeddings.cpu().numpy().astype(np.float32)

这里有个地方容易踩坑：向量必须做L2归一化。EmbeddingGemma 2训练时使用了归一化嵌入方式，如果不归一化，后续用内积做相似度计算时分数会失真。归一化之后，内积等价于余弦相似度，数值范围在-1到1之间，方便设置阈值。

向量库的选型上，FAISS是目前最轻量的方案，适合单机百万级向量的检索场景。构建索引：

import faiss dim = 896 index = faiss.IndexFlatIP(dim) # 内积索引，配合归一化向量等于余弦相似度 index.add(embeddings) faiss.write_index(index, "knowledge_base.index")

如果文档量很大（超过500万向量），建议改用IVF索引或者HNSW索引。但小规模场景下，暴力索引（Flat）速度已经足够快，而且召回质量最高。别为了追求"高级"引入不必要的索引类型。

4.3 检索流程与阈值设定

查询时同样需要把query做向量化，然后搜索引：

query = "系统架构图中数据库部署在哪个节点？" query_inputs = processor(text=query, return_tensors="pt").to("cuda") with torch.no_grad(): query_emb = model(**query_inputs).last_hidden_state[:, 0] query_emb = torch.nn.functional.normalize(query_emb, p=2, dim=-1) query_emb = query_emb.cpu().numpy().astype(np.float32) scores, indices = index.search(query_emb, k=5)

关于阈值，实测经验如下：

这个阈值在不同数据集上会有波动，建议用一个标注好的小数据集做一遍盲测，画出PR曲线后确定最优阈值。真实场景下0.60为界是比较稳妥的起点。

4.4 与本地LLM无缝对接

检索出来的多模态chunk，怎么喂给只有文本输入的本地LLM？这里就需要做"图文转文本"的适配。我采用的方法是：

1. 对检索到的图片，调用本地视觉模型生成结构化描述（我用的是Qwen2.5-VL-7B，视觉理解能力强）
2. 将文字上下文和图片描述拼接为prompt
3. 交给本地LLM生成最终回答

messages = [ {"role": "system", "content": "你是知识库问答助手，根据提供的上下文和图片描述回答问题，若信息不足请如实说明"}, {"role": "user", "content": f""" 【上下文】 {context_text} 【图片描述】 {image_description} 【问题】 {query} """} ]

这一步是纯离线RAG必需的操作。有人会问，既然已经有视觉LLM，为什么不用它直接替代多模态检索？原因还是成本。视觉LLM跑一张图的推理耗时约2-5秒，而多模态embedding只需要0.1秒左右。检索阶段只需要判断"这张图跟问题是否相关"，用轻量的embedding模型就够快速完成粗筛，命中后再调用视觉LLM做精细理解，两者各司其职，整体效率最优。

5. 我踩过的那些坑：多模态RAG的调优实录

5.1 图片召回效果差，问题在"切图策略"

第一次跑通流程后，我发现用户用截图去检索文档时，召回效果明显低于文字查询。排查了半天，根因是PDF里有些"图片"其实是整页的扫描版文字，我抽出来时没有先做OCR，导致这些图里只有图像像素，没有可检索的语义信息。

解决方案是：预处理阶段对所有图片先做一次OCR文本提取，把识别出的文字一并拼入文本部分。具体操作是用PaddleOCR批量跑一遍，将每张图的OCR结果保存为同名txt文件，然后再构建多模态chunk时，自动检测到存在同名OCR文件就追加文本内容。经过这一步，图片召回率提升了约15%。

5.2 维度不一致：768还是896

EmbeddingGemma 2支持768维输出模式，需要加载时指定output_hidden_states=True并从特定层取出。这个特性主要是为了兼容旧版索引体系（比如还在用OpenAI Ada-002 1536维的同事迁移过来降维使用）。但我的教训是：如果不是已有索引非要复用，尽量使用默认896维。768维模式因为跳过了部分层，在检索评测中会掉1-2个点，尤其是跨语言场景下更明显。过度追求降维兼容会牺牲效果，不划算。

5.3 长文档怎么处理：截断还是切片

4096 token上限意味着平均约3000个汉字（中文场景更少）的文本量。直接把超过长度限制的文档全部截断会丢失关键信息。我的经验是采用"滑动窗口+重叠"策略：窗口设为1024 token，重叠128 token。检索时按chunk召回，再把命中的chunk前后各拼接一个邻居chunk作为上下文，这样既保证检索粒度精准，又能给LLM足够上下文生成答案。

滑动窗口具体做法：

def chunk_text(text, max_tokens=1024, overlap=128): tokens = tokenizer.tokenize(text) chunks = [] start = 0 while start < len(tokens): end = min(start + max_tokens, len(tokens)) chunk_tokens = tokens[start:end] chunk_text = tokenizer.convert_tokens_to_string(chunk_tokens) chunks.append(chunk_text) start = end - overlap return chunks

5.4 批量向量化的显存管理

批量处理大量文档时，最容易把显存打爆。我建议batch size控制在8-16之间，根据显存大小动态调节。另外注意在每次forward之后调用torch.cuda.empty_cache()释放显存碎片。实测12G显存下batch size 16进行文本向量化没有问题，但如果同时跑了视觉LLM，batch size要降到4。

另外一个细节：图片embedding比文本embedding更吃显存，因为视觉编码器中间层特征图较大。如果图文混合输入一次给太多，很容易OOM。我实际用的方案是文本和图片分别编码，然后对向量做加权拼接或直接分开存索引，检索时分别算分数再融合排序，这样显存压力小，控制也更灵活。

5.5 检索分数抖动和归一化问题

有一段时间检索分数整体偏低，0.5以下的比例明显偏高。排查后发现是我在构建索引前做了一次额外的L2归一化，query端也做了归一化，但文档embedding在保存到磁盘时是用fp32存的，查询时读出来是fp32，而索引内部用的是fp32，理论上是没问题的。真正的问题是——我保存embedding时用了np.float16！精度损失导致向量幅值产生偏移。后来统一改为fp32存储，分数恢复稳定。

6. 常见问题排查速查表

还有一个经验是，混合检索（BM25稀疏检索 + 向量稠密检索）在中文场景下提升非常明显。EmbeddingGemma 2 740M本身对中文支持不算顶级，但中文query如果包含大量专有名词，BM25能命中关键词而向量检索能理解语义，两者融合的RFF分数比单一检索平均高出约8%。具体融合方式采用：

final_score = 0.7 * vector_score + 0.3 * bm25_score

这个权重是我在多个数据集上调出来的经验值，整体比较稳。

7. 选型建议与最终心得

如果你在纠结要不要选EmbeddingGemma 2 740M，我的建议可以总结成三句话：

第一，你的知识库里有图片吗？有的话，传统的纯文本embedding方案已经不够用了，EmbeddingGemma 2是目前本地部署、多模态、效果好三者兼顾的最优解之一。没有图片需求的话，BGE-M3可能是更稳的选择，毕竟中文支持和轻量稀疏检索的组合非常成熟。

第二，你的运行环境有多紧张？只有2GB显存或者干脆没GPU，740M版本是少数能跑起来的多模态embedding方案。要求再低一点可以上量化版本，但检索效果会损失一些，需要自行权衡。

第三，你的文档语言构成是什么？纯中文场景，建议搭配BM25混合检索一起上；中英混合场景，EmbeddingGemma 2的跨语言能力还算够用；英文场景，效果非常扎实。

我在实际项目中最深的体会是：离线多模态RAG的真正难点不在模型本身，而在工程管线——文档切分、图片预处理、OCR对位、向量归一化、混合检索融合，每一个环节都直接影响最终答案质量。EmbeddingGemma 2 740M只是链条中的一环，但它是让整个链条从"能跑"变成"好用"的重要一环。它的价值在于，用极低的部署成本把"图片参与检索"这一能力带到了完全离线的环境中，让那些对数据安全极其敏感的场景终于可以跳出"纯文本检索"的局限。

最后分享一个调优技巧。做多模态RAG评测时，一定要单独评估"文本→图片"和"图片→图片"这两类检索效果，因为它们的召回率通常比文本→文本低10%以上。你需要针对这两类场景单独准备测试集，然后调整图片预处理方案和融合权重。别只盯着总体的平均指标，细分的检索质量才是项目能否真正落地的关键。

这套方案我已在多个内部场景跑通，稳得很。如果你是正在评估embedding模型选型或者准备搭建离线RAG的开发者，希望这篇文章能帮你省去那些我踩过的弯路。