在实际应用中，企业知识库的内容往往不局限于纯文本。产品手册包含示意图和表格，培训材料里有操作截图，会议记录中嵌入了白板照片，甚至有些文档本身就是扫描件。如果只对文字部分做索引，图片、图表中的关键信息就会在检索环节丢失，导致回答不完整甚至错误。
多模态嵌入模型正是为解决这一问题而设计的。它的核心能力是：将文本、图像等不同类型的数据，映射到同一个向量空间中，使得语义相近的图文在向量位置上彼此靠近。 这意味着你可以用一段文字去检索一张相关图片，也可以用一张图片去匹配包含相似内容的文本片段。
为什么需要多模态嵌入
单一文本嵌入在纯文字场景下已经足够好用，但一旦涉及视觉信息，就会出现明显的检索盲区。例如：
- 用户问：“这个产品的接口在什么位置？”如果知识库中的产品接口图没有被索引，系统就只能凭文字描述拼凑答案，很可能遗漏关键细节。
- 技术文档中，核心参数有时候直接写在表格截图里，若只索引了文档正文，这些参数就成了“看不见的知识”。
多模态嵌入模型将图像也变成可检索的向量，让系统能够“看到”并理解视觉内容，补齐了纯文本检索的短板。
如何工作
多模态嵌入模型通常采用双编码器架构：一个编码器处理图像，另一个编码器处理文本，两个编码器输出的向量被对齐到同一空间。这样，无论是文本、图像还是图文混合的内容，都可以用统一的方式进行相似度比较。
常见的代表模型包括 OpenAI 的 CLIP、Google 的 SigLIP，以及一些开源替代如 Chinese-CLIP 等。它们在训练时就学会了将匹配的图文对拉近、不匹配的拉远，从而建立起跨模态的语义关联。
在 RAG 系统中，使用多模态嵌入模型通常只需要在索引阶段增加一个图像处理步骤：
- 文档解析时，不仅提取文本，还保留页面中的图片、表格截图等视觉元素；
- 将每张图片单独送入图像编码器，生成对应的图像向量；
- 将图片向量和其周围的文本向量一起存入向量数据库，并记录位置关系；
- 检索时，用户问题（文本）通过文本编码器生成查询向量，与库中所有向量（包括文本向量和图像向量）进行相似度匹配，从而召回最相关的图文片段。
实用建议与注意事项
- 从实际需求出发：并非所有 RAG 场景都需要多模态嵌入。如果知识库中几乎没有视觉信息（如纯文字的法规库），引入多模态模型反而会增加成本和复杂度。建议先盘点知识源中图像、表格的占比，再决定是否采用。
- 嵌入模型的选择：对中文场景，可优先考虑支持中英双语且在多模态对齐上表现良好的模型（如 Chinese-CLIP），避免跨语言理解偏差。若涉及专业领域图像（如医学影像、工程图纸），可能需要针对具体领域微调或寻找专业预训练模型。
- 图像预处理很重要：密集的图表、多栏扫描件直接整页送入模型往往效果不佳。应在解析阶段将图像合理切分成有独立含义的区域（如单个图表、单个示意图），再分别进行向量化。
- 存储与成本考量：图像向量维度通常较高，大规模索引会占用较多存储空间。可根据图像的信息密度有选择地索引，例如略去纯装饰性图片，只对说明性、数据性图像进行嵌入。
一个真实场景
某医疗设备公司为其技术支持系统搭建了 RAG 知识库，包含上千份设备维修手册。这些手册中大量故障排除流程是用流程图展示的，文字部分仅做简要说明。早期采用纯文本嵌入时，检索到的片段经常缺少完整的排故逻辑，因为关键步骤都在图里。
改用多模态嵌入模型后，团队在索引时将每张流程图单独提取并向量化。当工程师搜索“注射泵报错 E03 后如何复位”时，系统不仅返回了相关的文字说明，还把包含复位操作步骤的流程图一并召回。模型基于这些图文片段生成的回答，准确度大幅提升，呼叫中心的升级工单减少了近三成。
总之，多模态嵌入模型扩展了 RAG 系统处理真实世界知识的能力边界。在知识形式越来越丰富的当下，它正从一个“锦上添花”的选项，变成很多场景中“不可或缺”的基础能力。