第三层问题出现在 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 搜索引擎”，而是做多模态知识库。
产品形态可以非常简单：
用户上传任何资料——文档、截图、图片或视频片段；