第三层问题出现在 Agent 场景。当 AI Agent 需要读取屏幕、理解截图或定位界面元素时文本向量体系几乎帮不上忙。所以问题并不只是“搜索效果不好”而是数据根本没有进入系统。多模态 Embedding 在做什么多模态 embedding 的核心思路并不复杂把不同模态的数据映射到同一个向量空间。在这个空间里文本、图片甚至视频帧都可以计算语义相似度。例如 CLIP 一类模型的训练方式就是让图像向量与对应描述文本在向量空间中靠近。Sentence Transformers 生态已经提供了多种这类模型的封装可以直接用于图文 embedding。当文本和图片共享同一向量空间时一些原本做不到的查询会自然出现用户输入一句话可以直接召回相关图片。用户上传一张图片可以找到相关文档。一段视频帧也可以与技术说明文本匹配。这并不是替代文本检索而是把检索维度从“文本语义”扩展到“跨模态语义”。为什么工程里几乎一定需要 Reranker只靠 embedding 做检索通常只能解决召回问题。尤其在跨模态场景中噪声会更高。举个简单例子一条查询“红色跑车”embedding 检索可能召回几十张汽车图片其中不少只是颜色或形态相似但并不完全符合语义。这就是 reranker 存在的原因。在 Sentence Transformers 的体系里常见做法是使用 cross‑encoder 作为 reranker。与 embedding 模型不同cross‑encoder 会同时读取查询和候选内容再计算相关性分数。工程上通常形成一条清晰的 pipeline向量召回embedding retrieval→ 候选集合 → reranker 精排。这种 retrieve → rerank 的结构在搜索系统里已经非常成熟在多模态 RAG 里同样适用。一个可落地的 Multimodal RAG 架构如果把这些组件组合起来多模态 RAG 的技术栈其实很清晰。第一步是数据向量化。文本直接生成 embedding图片或 PDF 页面可以通过 CLIP 类模型生成图像 embedding必要时也可以为图片附带 OCR 文本作为补充特征。第二步是统一索引。所有 embedding 进入同一个向量数据库例如 FAISS、Milvus 或 pgvector。此时文本和图片已经处在同一语义空间。第三步是检索与 rerank。查询可以是文本或图片。向量检索先召回一批候选再用 cross‑encoder reranker 重新排序提高结果相关性。最后一步才是生成。选出的上下文进入 LLM用于回答问题或生成解释。从工程角度看这条链路与传统 RAG 并没有本质不同只是 embedding 和 reranker 支持了多模态输入。多模态检索首先改变的是企业知识库消费级搜索看起来很吸引人但多模态检索最早落地的地方往往是企业内部系统。原因很直接企业数据天然就是多模态。设计团队存着大量设计稿和 UI 截图制造企业有设备照片与维修文档电商平台的商品信息本来就是图文混合。如果一个知识库可以做到两件事——用文字找到图片用图片找到文档它的价值会立刻体现出来。例如设计团队可以通过一句描述找到历史 UI维修工程师上传设备照片就能定位到对应手册页面电商团队可以用图片反查商品资料。这些场景的共同特点是需求明确而且已经有预算。谁会最先为这类系统付费从商业角度看最早买单的通常不是个人用户而是拥有大量视觉资产的团队。设计与内容团队是最典型的一类。设计稿、素材和截图很难通过传统知识库管理多模态检索可以显著降低查找成本。第二类是电商和商品平台。图文混合搜索本身就是核心业务多模态 embedding 可以提升商品匹配与内容检索能力。第三类是工业和制造企业。设备照片、检修记录和技术文档之间存在天然关联跨模态检索可以减少大量人工排查时间。这些客户已经在为知识管理或搜索系统付费只是现有工具还不具备多模态能力。一个现实可做的产品切口如果要把这项技术变成产品最直接的切口其实不是“做新的 AI 搜索引擎”而是做多模态知识库。产品形态可以非常简单用户上传任何资料——文档、截图、图片或视频片段