把一份几十页的产品手册、一堆扫描合同、几十页会议 PPT，以及同事随手拍的白板照片，全部丢进同一个知识库，然后让问答系统不仅能引用里面的话，还能看懂流程图、表格和截图里的关键信息，最后给出带页码和出处依据的回答——这就是多模态 RAG 工作流要解决的事。它不是简单粗暴地把图片“塞”进向量库就完事，而是从文档解析、版面分析、图像理解、多模态索引到召回排序和答案生成的一整条链路。很多团队做 RAG 做到一半会发现：纯文本检索很顺，一旦文档里混着图，召回质量立刻崩。图片里明明写了“红色指示灯闪烁对应电源故障”，用户用自然语言问“设备红灯闪是什么问题”，文本检索却一个字都匹配不到。这不是模型不行，而是工作流设计里少了多模态这一层。这篇文章面向两类人：一类是做企业内部知识库、客服问答、文档助手，正被“图文混排文档”折磨的开发者；另一类是刚接触 RAG，想知道多模态方案和水有多深的技术选型者。我会把这套工作流拆成六个部分讲清楚：单模态为什么不够、整体管线怎么搭、文档解析和分块怎么做、索引怎么建、召回排序怎么调、最后怎么验证效果。1. 为什么单独拎出“多模态”这条线：单模态RAG的瓶颈1.1 你现在的RAG只做了一半标准的 RAG 流程大家都很熟：把文档切成文本块，用嵌入模型转成向量，用户提问时做相似度检索，拿回 top-k 块塞进大模型生成答案。这套流程处理纯文本没问题，但真实文档几乎都是图文混排的。我见过很多项目在评估阶段就发现：答案答非所问或者直接说“资料中没有提到”。一查索引，发现关键答案其实在文档某张截图里。传统文本抽取流程把图片区域当作空白丢弃，或者只留下 OCR 出来的一堆文字碎片，没有标题、没有段落结构、没有上下文。用户问的是图形的语义，比如“这张拓扑图里哪台交换机是核心节点”，文本检索根本无从下手。1.2 多模态不是“让AI能看图”，而是信息不丢失多模态 RAG 的核心价值不是让模型拥有视觉能力，而是保证知识库里的信息在“切块—向量化—检索—生成”全链路中不丢失。图片里包含的信息通常分几类：图片上的文字：比如截图里的按钮名称、报错信息、图表坐标轴的标签；图片的结构关系：比如流程图里框与框的连线、组织结构图的层级关系；图片的视觉语义：比如“绿灯亮代表运行正常”“左上角的指示灯是电源”；表格的二维结构：比如哪些单元格属于同一行、哪一列是数值。如果只用一种文本抽取方案，以上四类信息至少丢掉一半。多模态 RAG 的思路就是把这些信息用不同的处理手段分别提出来，再在同一个索引和检索体系里统一使用。1.3 适用场景和反模式适合做的场景：企业产品手册问答、招标文档审查、医疗影像报告解读（结合文本报告和影像截图）、课堂讲义问答、会议纪要加白板照片的知识库。这类场景的共同点是“文档里存在不可替代的视觉信息”，答案要是不看图根本说不清。不适合做的场景也要说清楚：如果文档基本是纯文本，图片只是装饰，或者业务对图片的实时性要求极高，比如监控视频帧流，那多模态 RAG 并不是最优解。硬件成本、解析耗时、存储开销都会翻几倍，而且视觉模型调用在长文档批量处理时并不便宜。先把场景和收益想清楚再动手，这个项目才值得做。2. 多模态RAG工作流的整体管线设计2.1 从文件进来那一刻开始分层多模态 RAG 和单模态 RAG 的第一步相同，都是文件接入，但从文件接入之后就分叉了。完整管线大致是这样：文件接入：PDF、Word、PPT、图片、扫描件、网页；文档解析：版面检测、OCR、表格还原、标题层级识别；多模态分块：生成文本块、图片块、表格块，并建立块之间的关联关系；内容增强：对图片生成文字描述，对表格生成摘要，对 OCR 文本做纠错；向量化：文本块用文本嵌入模型，图片块用视觉嵌入模型或统一多模态嵌入模型；索引构建：向量索引 + 关键词索引 + 元数据过滤字段；检索召回：多路并行召回，文本、图片、表格各自召回候选；排序融合：重排序、按块类型加权、置信度过滤；上下文合成：把相关文本、图片描述、原图按 token 限制拼装；答案生成：使用纯文本大模型或多模态大模型生成带引用的回答。这个流程里最容易被忽略的是第 3 和第 4 步。很多人以为把 PDF 按页转成图片，再用视觉模型一次性处理就好。实际上，如果没有区域级的分块，检索时就无法定位到“某一页的左上角那张图”，只能整页返回，命中精度很差。2.2 两种主流路线：密集提取 vs 粗粒度挂载我在实际工程里见过两类主流做法，各有取舍。第一类是密集提取路线：文档解析阶段把所有图片、表格、公式区域单独抠出来，做成独立的索引块。图片块包含原图路径、OCR 文本、图像描述、来源坐标和页码；表格块包含还原出的 Markdown 表格和原始表格截图。检索阶段这些块和文本块地位平等。优点是召回精确，用户问“图里的接线方式”可以直接命中图片块；缺点是解析链路复杂，图片块如果太多，索引体积和检索耗时会明显上升。第二类是粗粒度挂载路线：不做密集抠图，而是把图片和它所在的段落绑定为一个超级块。比如一个第五章的段落，包含正文文字和一张插图，整体作为一个索引单元。检索时用文本向量匹配，需要回答时把整块内容，包括图片，一起喂给多模态模型。优点是实现简单，不容易漏上下文；缺点是图片的位置和语义可能不够紧，检索精度受限。选哪条路线，我建议从“最终回答是否需要展示原图”来反推。如果问答系统要把原图作为答案的一部分展示给用户，那必须走密集提取，因为只有独立图片块才能准确定位和返回。如果只是让助手参考图里的信息、最终输出纯文字总结，那粗粒度挂载可以省掉很多工作量。2.3 工作流设计的关键决策点在动手搭之前，有几个决策点必须提前定，不然后面返工的成本很高。分块粒度：图片是按整图建块，还是把图里的子区域（比如流程图中的每个框）再拆？一般建议按“语义完整”为准，整图建块是最稳妥的起步方案。图片是否裁剪保存：密集提取路线必须把抠出来的图片保存为独立文件，或者至少保存坐标，方便后续展示。是否使用视觉模型生成描述：强烈建议做，这是性价比最高的一步。是否做表格结构还原：如果文档里表格占比高，必须做，否则表格块就是废块。是否结合关键词检索：建议加，多模态向量对精确数字、型号、人名匹配并不擅长，BM25 类关键词检索能补位。生成模型是否多模态：如果已经有支持图像输入的多模态大模型，可以在生成阶段直接传原图；否则只能传 OCR 文本和图像描述。这些决策没有标准答案，但底线是：每一种类型的块都必须有结构化的元数据，方便后面单独调试。3. 文档解析与分块策略：图片、表格、PDF、PPT怎么处理3.1 解析管线不要从OCR开始，先从布局开始很多人处理 PDF 的第一反应是整页 OCR。这个做法风险很大。OCR 会把页面上的文字按坐标顺序吐出来，但完全不理解“哪段文字对应哪张图”，也不理解“这个框是标题还是正文”。正确做法是先用版面布局模型把页面切分成不同区域。模型通常会输出若干区域，每个区域带类型和坐标框，例如“标题”“正文”“图片”“表格”“页眉页脚”。拿到这些区域之后，再对图片区域做 OCR 和图像理解，对表格区域做表格结构识别。举个例子，一份设备安装手册的某一页，左侧是结构图，右侧是文字说明。布局检测之后，左侧图片区可以被单独提取，右侧文字区按段落切块。如果反过来先用 OCR，你得到的是文字说明和图片里标注的数字混在一起的一堆无序文本，检索效果很难好。3.2 图片处理的四个层次图片绝不是“转成文字”就完事。我按信息保真度把图片处理分成四个层次，实际项目里可以按需选择：原图保留：必须做。原图用于展示、溯源，也是多模态模型输入的原材料。OCR 文字提取：把图片内出现的所有文字提取出来，包括图注、坐标轴、标注框里的文本。这一步解决“图上写了什么”。图像语义描述：用一个视觉语言模型看完整张图，生成一段自然语言描述，例如“该图展示系统架构分为三层，上层是应用服务，中间是消息队列，下层是数据库”。这一步解决“这张图表达什么意思”。向量化：图像经过视觉编码器得到向量，用于图文跨模态检索。这一步解决“用户用一句自然语言，能不能匹配到这张图”。四个层次应该在索引字段里各占一席。OCR 文本和图像描述都作为可检索文本，原图路径作为展示字段，图像向量作为辅助召回信号。3.3 表格解析是最容易翻车的地方表格识别是最容易让多模态 RAG 翻车的部分。PDF 里的表格本质上是坐标线条和文字的堆叠，没有真正的行和列结构。如果用文本切块的方式处理，一个完整表格很可能被切成几十个碎片，检索时间一长，召回结果完全不可用。我的经验是两步走：第一步，用表格结构识别模型把表格还原成单元格坐标，再转成 Markdown 或 HTML 格式。第二步，把还原出来的文本表格和原始表格渲染截图一起保存为表格块。这样既保留了语义结构，又保留了视觉版式。表格块和普通文本块在检索时要有不同的待遇。表格的检索关键词往往包含列名、数字范围、单位、表头信息，分块时要保持整表完整，不要强行按 token 切割。如果表格特别长，至少也要按“表头+若干行”为一个语义单元，并且反复带上表头信息。3.4 分块参数的实操建议分块参数没有银弹，只能给一组我常用的起点：普通文本块：512 到 1024 token，重叠 100 到 150 token；图片块：整图作为一个块，单个块内包含 OCR 文本、描述文本、原图路径、图片类型；表格块：一个表格尽量作为一个块；如果超大，按行组拆，但每组重复表头；代码块：如果文档包含代码，按函数或代码段切，不要按行切。每个块的元数据字段建议固定为：来源文件名、文件版本、页码、块类型、布局区域坐标、所属章节路径、OCR置信度、生成时间。这些字段在后续重排和过滤时非常关键。比如用户追问“在第六章里找”，可以直接用元数据过滤；如果 OCR 置信度太低，也可以通过阈值把它从候选中剔除。4. 向量化与索引构建：文本向量、图像向量、混合检索4.1 文本向量和图像向量要不要进同一个向量空间这是多模态 RAG 选型里一个绕不开的问题。目前有三条路线：路线一：用同一个多模态嵌入模型把文本和图像同时编码到同一向量空间。好处是用户查询文本可以直接和图片向量计算相似度，天然支持跨模态检索。坏处是模型选择面窄，维度固定，更新成本高。路线二：文本和图像各用各的编码模型，分别建索引，检索时两路召回再合并。好处是可以灵活替换模型，坏处是要处理两种向量之间的分数不可比问题，还要设计合并逻辑。路线三：把图片先转成文本描述，只建文本索引。这是最简单的方式，效果往往比我预期的好。坏处是图片里很多微妙的视觉细节会丢失，比如按钮间距、颜色、边框状态。我的建议是：起步阶段先走路线三，把所有图片的语义描述转成文本，混入文本索引。等验证了场景确实需要“以图搜图”或“图文联合检索”，再上路线一或路线二。不要一上来就追求复杂的多模态向量。4.2 图像描述是“穷人版多模态”，但真管用给每张图片生成一段高质量描述，是多模态 RAG 里性价比最高的一笔投入。描述不要泛泛地说“这是一张图”，而是要把图里和业务相关的关键信息写清楚。举例来说，针对一张设备状态面板截图，生成描述时应该包含：面板的整体布局、每个指示灯的颜色和位置、对应的文字标签、以及可能的含义。这样的描述和用户的提问“设备红色指示灯闪烁是正常吗”就有很高的文本相似度，检索系统不需要真正理解图像内容也能命中。实际操作中，我会同时保存两份描述：一份是简短的“图注型描述”，用于快速召回；另一份是详细的“像素级描述”，用于生成阶段给大模型补充上下文。如果预算有限，至少保证第一份描述是结构化的，像“图中从左到右依次是……，其中第三个是……，颜色为……”。4.3 混合检索的排序合并多模态 RAG 强烈建议做混合检索，也就是向量检索 + 关键词检索并行。向量擅长语义匹配，关键词擅长精确匹配型号、编号、品牌词。比如用户问“AK-300 型号的安装孔距是多少”，向量可能因为语义太近召回一堆不相关内容，关键词能直接拉住具体型号。多路召回之后要合并排序。最简单的做法是加权融合，比如：最终得分 = 0.6 × 向量相似度 + 0.3 × 关键词得分 + 0.1 × 元数据匹配得分。但要注意，不同检索源的分数分布完全不同，直接加权前必须先做归一化，或者把每路结果都转成排名序号再融合。还有一个实操细节：向量检索不能只取一个索引。图片块的描述文本和文本块的正文往往是两套文本，如果它们混在同一索引里，检索向量分布会互相干扰。稳妥的做法是给文本块和图片描述块各建一个索引，或者至少在向量字段上打类型标签，召回时分别限制各类型的数量。4.4 索引更新与去重文档更新时最头疼的问题就是重复和过期。一个文档改了两版，旧版本块还留在索引里，回答时可能同时引用新旧内容，产生矛盾。建议以“文件版本”为索引单元。每处理一个新文档，给这个文档分配一个全局唯一的文档ID和版本ID，所有块都记录这两个字段。更新时，先按文档ID删除所有旧块，再写入新块。删除操作要有幂等性，避免重复跑任务时把索引插两遍。另外，图片块去重也不能忽略。同一张图片在 PPT 和 PDF 里可能会出现多次，视觉特征高度相似。可以在图片入库时计算一个感知哈希，如果哈希接近，保留清晰度高的那一条，并把其他位置的引用信息合并进元数据。5. 检索排序与多模态融合：召回之后怎么办5.1 召回不等于答案，重排决定质量第一次召回通常会拉回 20 到 50 个候选块，但真正有用的可能只有两三个。如果直接把 top-k 塞给生成模型，不仅浪费 token，还容易引入干扰信息。重排这一步必须做。对于文本块，可以用一个交叉编码器模型，把查询和候选块拼接后打分，比单塔向量相似度准得多。对于图片块，不能直接用交叉编码器打分，因为输入不是纯文本。我的做法是：把图片块里面的“OCR 文本 + 图像描述”拼成一段文本，再让交叉编码器打分。这样图片块和文本块在重排阶段就统一到了同一套打分逻辑上。5.2 跨模态置信度校准这里有一个多数人都会踩的坑：不同来源的分数完全不可比。OCR 输出置信度 0.95 的文本，图像描述模型输出的得分可能是 0.7，交叉编码器输出可能是 0.1 到 0.9 的 logits，它们根本不是同一个量纲。所以不能只依赖模型分数，还要在业务层做硬规则。我从实践中总结出的校准策略：设置类型底线：表格块必须包含至少 3 个单元格，否则过滤；OCR 置信度过滤：低置信度的图片块不进入最终候选；类型配额：最终给生成模型的上下文里，文本块最多 N 个，图片块最多 M 个，防止某种类型霸屏；人工反馈回传：把用户点击、点赞、踩过的回答作为重排模型微调样本，这是最有效的长期优化路径。5.3 上下文窗口怎么塞多模态内容生成阶段的输入组装，是很多人会忽略的信息丢失重灾区。如果生成模型是纯文本模型，那就只能把图片的 OCR 文本、图像描述、表格 Markdown 拼进去，原图没法用。这时要注意控制总量，不要贪多，恨不得二十个块全塞进去。一旦上下文太长，模型会把关键信息淹没在无关内容里。如果生成模型支持图像输入，组装方式又不一样。多模态模型的对话消息里，图像是一个独立的内容类型，和文字消息并列。实际操作中，我通常只选择 2 到 3 张最关键的图片传入，并且每张图片都用文字标注一下来源位置，比如“参考图片来自第 3 页左上角”。这样模型既能看图，又能知道图在原始文档里的位置。5.4 幻觉与引用控制多模态 RAG 的幻觉问题比单模态更隐蔽。文本模型面对一张无法真正看到的图时，很容易根据描述文本脑补细节。比如图像描述只写了“图中有一个红色指示灯”，模型却回答“红色指示灯表示温度过高”，这个结论不一定有依据。我处理这个问题的方式是双管齐下。第一，在提示词里明确要求“只能依据给定材料回答，如果材料中没有明确说明，必须说信息不足”。第二，要求回答逐条列出依据，引用格式可以是“[来源文件，第X页，块类型：图片]”。这样用户能点击溯源，系统也能在评测时自动检查引用是否存在于真实输入中。6. 生成阶段与评测：如何验证工作流有效性6.1 评测指标：不能只看回答是否流畅多模态 RAG 如果只看“回答是否流畅”，会掉进严重的评测陷阱。回答流畅不代表检索正确，更不代表图片信息被正确使用。我建议至少盯住五个指标。召回命中率：标准答案里提到的依据块，是否出现在检索返回的候选块里。这是最底层指标，如果这里失败，后面全是空谈。引用准确率：模型回答中列出的每个来源，是否真的包含支持该句结论的内容。这比召回率高一个层次，可以防止模型瞎编来源。答案忠实度：把答案和给定材料交给裁判模型打分，判断是否出现了材料之外的信息。多模态场景下尤其要检查图片细节有没有被错误脑补。视觉依赖度：评测集中有多少问题属于“必须看图才能回答”，系统对这类问题的成功率是多少。这个指标能直接反应多模态改造的价值。端到端任务成功率：不问具体某一步，而是模拟真实用户完整走一遍问答流程，看最终答案是否让用户满意。这是业务方最关心的指标。6.2 构建一份“多模态评测集”没有评测集的 RAG 改造都是自嗨。我建议从真实业务文档里挑 100 到 200 个问题，覆盖文本、图片、表格三种类型，组成专属评测集。针对每个问题，除了写标准答案，还要标注“期望依据类型”。比如：问题：“设备面板上哪个灯表示电源正常？”期望依据类型：图片区域 OCR是否必须原图展示：是允许的回答内容：“右上角绿色指示灯常亮表示电源正常”标注完这些字段之后，每次工作流改动，都能精确看到“图片类问题有没有变好”“表格类问题有没有变坏”。有了这份评测集，很多争论都可以直接量化。6.3 分模块调试：先分开看，再合起来多模态 RAG 链路长，出了问题最难定位。所以我一直坚持模块化调试，不给中间状态留黑盒。当发现一个回答不对，先判断问题出在哪一层。手段是打印每一层的中间结果：解析层打印版面区域列表、OCR 文本、表格结构；索引层打印每类块数量和向量字段内容；检索层打印每路召回命中和分数；重排层打印最终送入生成的候选块列表；生成层打印完整的 prompt 消息内容。哪个环节的预期状态不对，就修哪里。一个真实案例：某次问答系统总是答不出图片里的型号信息。我以为图像描述没写全，后来打印检索结果才发现，图片块的描述文本生成了，但索引更新任务跑挂了，根本没有写入向量库。只看最终答案，永远查不到这里。6.4 常见失败模式与对策最后把我在多模态 RAG 项目里遇到最多的失败模式整理成一张表，做踩坑参考。失败现象根本原因对策图片块检索不到图片描述太泛，或未写入索引用结构化描述模板，检查索引更新任务表格答案残缺表格被拆成多个碎片整表建块，保留 Markdown 和截图双格式回答里出现图中没有的细节模型根据描述脑补限制只能使用给定材料，加入不确定性提示图片块总是排在前面向量分数未归一化对分数做归一化，按类型配额控制上下文爆掉图片原图占用大量 token控制传入图片数量，图片压缩或降分辨率文档更新后答案新旧矛盾旧块未清理按文档版本做全量替换，删除旧版本块用户找不到答案来源回答没有引用编号生成时强制加入来源列表我在实际操作中的体会是，多模态 RAG 工作流真正难的从来不是某一个模型有多强，而是文件解析、分块、索引、检索、生成这五个环节的衔接是否够稳。每次改一个参数，都要回归一次评测集，看整体曲线是向上还是向下。把各个模块的日志和中间结果留好，遇到问题可以先按环节缩小范围，再去调具体模型和阈值，这条路虽然不性感，但最可靠。最后再分享一个小技巧：先拿 30 到 50 份有代表性的文档把全链路跑通，再做 500 份以上的批量扩充。小批量调试时还能人工看中间结果，大批量一上，很多隐藏问题就会迅速放大。
把一份几十页的产品手册、一堆扫描合同、几十页会议 PPT，以及同事随手拍的白板照片，全部丢进同一个知识库，然后让问答系统不仅能引用里面的话，还能看懂流程图、表格和截图里的关键信息，最后给出带页码和出处依据的回答——这就是多模态 RAG 工作流要解决的事。它不是简单粗暴地把图片“塞”进向量库就完事，而是从文档解析、版面分析、图像理解、多模态索引到召回排序和答案生成的一整条链路。很多团队做 RAG 做到一半会发现：纯文本检索很顺，一旦文档里混着图，召回质量立刻崩。图片里明明写了“红色指示灯闪烁对应电源故障”，用户用自然语言问“设备红灯闪是什么问题”，文本检索却一个字都匹配不到。这不是模型不行，而是工作流设计里少了多模态这一层。这篇文章面向两类人：一类是做企业内部知识库、客服问答、文档助手，正被“图文混排文档”折磨的开发者；另一类是刚接触 RAG，想知道多模态方案和水有多深的技术选型者。我会把这套工作流拆成六个部分讲清楚：单模态为什么不够、整体管线怎么搭、文档解析和分块怎么做、索引怎么建、召回排序怎么调、最后怎么验证效果。1. 为什么单独拎出“多模态”这条线：单模态RAG的瓶颈1.1 你现在的RAG只做了一半标准的 RAG 流程大家都很熟：把文档切成文本块，用嵌入模型转成向量，用户提问时做相似度检索，拿回 top-k 块塞进大模型生成答案。这套流程处理纯文本没问题，但真实文档几乎都是图文混排的。我见过很多项目在评估阶段就发现：答案答非所问或者直接说“资料中没有提到”。一查索引，发现关键答案其实在文档某张截图里。传统文本抽取流程把图片区域当作空白丢弃，或者只留下 OCR 出来的一堆文字碎片，没有标题、没有段落结构、没有上下文。用户问的是图形的语义，比如“这张拓扑图里哪台交换机是核心节点”，文本检索根本无从下手。1.2 多模态不是“让AI能看图”，而是信息不丢失多模态 RAG 的核心价值不是让模型拥有视觉能力，而是保证知识库里的信息在“切块—向量化—检索—生成”全链路中不丢失。图片里包含的信息通常分几类：图片上的文字：比如截图里的按钮名称、报错信息、图表坐标轴的标签；图片的结构关系：比如流程图里框与框的连线、组织结构图的层级关系；图片的视觉语义：比如“绿灯亮代表运行正常”“左上角的指示灯是电源”；表格的二维结构：比如哪些单元格属于同一行、哪一列是数值。如果只用一种文本抽取方案，以上四类信息至少丢掉一半。多模态 RAG 的思路就是把这些信息用不同的处理手段分别提出来，再在同一个索引和检索体系里统一使用。1.3 适用场景和反模式适合做的场景：企业产品手册问答、招标文档审查、医疗影像报告解读（结合文本报告和影像截图）、课堂讲义问答、会议纪要加白板照片的知识库。这类场景的共同点是“文档里存在不可替代的视觉信息”，答案要是不看图根本说不清。不适合做的场景也要说清楚：如果文档基本是纯文本，图片只是装饰，或者业务对图片的实时性要求极高，比如监控视频帧流，那多模态 RAG 并不是最优解。硬件成本、解析耗时、存储开销都会翻几倍，而且视觉模型调用在长文档批量处理时并不便宜。先把场景和收益想清楚再动手，这个项目才值得做。2. 多模态RAG工作流的整体管线设计2.1 从文件进来那一刻开始分层多模态 RAG 和单模态 RAG 的第一步相同，都是文件接入，但从文件接入之后就分叉了。完整管线大致是这样：文件接入：PDF、Word、PPT、图片、扫描件、网页；文档解析：版面检测、OCR、表格还原、标题层级识别；多模态分块：生成文本块、图片块、表格块，并建立块之间的关联关系；内容增强：对图片生成文字描述，对表格生成摘要，对 OCR 文本做纠错；向量化：文本块用文本嵌入模型，图片块用视觉嵌入模型或统一多模态嵌入模型；索引构建：向量索引 + 关键词索引 + 元数据过滤字段；检索召回：多路并行召回，文本、图片、表格各自召回候选；排序融合：重排序、按块类型加权、置信度过滤；上下文合成：把相关文本、图片描述、原图按 token 限制拼装；答案生成：使用纯文本大模型或多模态大模型生成带引用的回答。这个流程里最容易被忽略的是第 3 和第 4 步。很多人以为把 PDF 按页转成图片，再用视觉模型一次性处理就好。实际上，如果没有区域级的分块，检索时就无法定位到“某一页的左上角那张图”，只能整页返回，命中精度很差。2.2 两种主流路线：密集提取 vs 粗粒度挂载我在实际工程里见过两类主流做法，各有取舍。第一类是密集提取路线：文档解析阶段把所有图片、表格、公式区域单独抠出来，做成独立的索引块。图片块包含原图路径、OCR 文本、图像描述、来源坐标和页码；表格块包含还原出的 Markdown 表格和原始表格截图。检索阶段这些块和文本块地位平等。优点是召回精确，用户问“图里的接线方式”可以直接命中图片块；缺点是解析链路复杂，图片块如果太多，索引体积和检索耗时会明显上升。第二类是粗粒度挂载路线：不做密集抠图，而是把图片和它所在的段落绑定为一个超级块。比如一个第五章的段落，包含正文文字和一张插图，整体作为一个索引单元。检索时用文本向量匹配，需要回答时把整块内容，包括图片，一起喂给多模态模型。优点是实现简单，不容易漏上下文；缺点是图片的位置和语义可能不够紧，检索精度受限。选哪条路线，我建议从“最终回答是否需要展示原图”来反推。如果问答系统要把原图作为答案的一部分展示给用户，那必须走密集提取，因为只有独立图片块才能准确定位和返回。如果只是让助手参考图里的信息、最终输出纯文字总结，那粗粒度挂载可以省掉很多工作量。2.3 工作流设计的关键决策点在动手搭之前，有几个决策点必须提前定，不然后面返工的成本很高。分块粒度：图片是按整图建块，还是把图里的子区域（比如流程图中的每个框）再拆？一般建议按“语义完整”为准，整图建块是最稳妥的起步方案。图片是否裁剪保存：密集提取路线必须把抠出来的图片保存为独立文件，或者至少保存坐标，方便后续展示。是否使用视觉模型生成描述：强烈建议做，这是性价比最高的一步。是否做表格结构还原：如果文档里表格占比高，必须做，否则表格块就是废块。是否结合关键词检索：建议加，多模态向量对精确数字、型号、人名匹配并不擅长，BM25 类关键词检索能补位。生成模型是否多模态：如果已经有支持图像输入的多模态大模型，可以在生成阶段直接传原图；否则只能传 OCR 文本和图像描述。这些决策没有标准答案，但底线是：每一种类型的块都必须有结构化的元数据，方便后面单独调试。3. 文档解析与分块策略：图片、表格、PDF、PPT怎么处理3.1 解析管线不要从OCR开始，先从布局开始很多人处理 PDF 的第一反应是整页 OCR。这个做法风险很大。OCR 会把页面上的文字按坐标顺序吐出来，但完全不理解“哪段文字对应哪张图”，也不理解“这个框是标题还是正文”。正确做法是先用版面布局模型把页面切分成不同区域。模型通常会输出若干区域，每个区域带类型和坐标框，例如“标题”“正文”“图片”“表格”“页眉页脚”。拿到这些区域之后，再对图片区域做 OCR 和图像理解，对表格区域做表格结构识别。举个例子，一份设备安装手册的某一页，左侧是结构图，右侧是文字说明。布局检测之后，左侧图片区可以被单独提取，右侧文字区按段落切块。如果反过来先用 OCR，你得到的是文字说明和图片里标注的数字混在一起的一堆无序文本，检索效果很难好。3.2 图片处理的四个层次图片绝不是“转成文字”就完事。我按信息保真度把图片处理分成四个层次，实际项目里可以按需选择：原图保留：必须做。原图用于展示、溯源，也是多模态模型输入的原材料。OCR 文字提取：把图片内出现的所有文字提取出来，包括图注、坐标轴、标注框里的文本。这一步解决“图上写了什么”。图像语义描述：用一个视觉语言模型看完整张图，生成一段自然语言描述，例如“该图展示系统架构分为三层，上层是应用服务，中间是消息队列，下层是数据库”。这一步解决“这张图表达什么意思”。向量化：图像经过视觉编码器得到向量，用于图文跨模态检索。这一步解决“用户用一句自然语言，能不能匹配到这张图”。四个层次应该在索引字段里各占一席。OCR 文本和图像描述都作为可检索文本，原图路径作为展示字段，图像向量作为辅助召回信号。3.3 表格解析是最容易翻车的地方表格识别是最容易让多模态 RAG 翻车的部分。PDF 里的表格本质上是坐标线条和文字的堆叠，没有真正的行和列结构。如果用文本切块的方式处理，一个完整表格很可能被切成几十个碎片，检索时间一长，召回结果完全不可用。我的经验是两步走：第一步，用表格结构识别模型把表格还原成单元格坐标，再转成 Markdown 或 HTML 格式。第二步，把还原出来的文本表格和原始表格渲染截图一起保存为表格块。这样既保留了语义结构，又保留了视觉版式。表格块和普通文本块在检索时要有不同的待遇。表格的检索关键词往往包含列名、数字范围、单位、表头信息，分块时要保持整表完整，不要强行按 token 切割。如果表格特别长，至少也要按“表头+若干行”为一个语义单元，并且反复带上表头信息。3.4 分块参数的实操建议分块参数没有银弹，只能给一组我常用的起点：普通文本块：512 到 1024 token，重叠 100 到 150 token；图片块：整图作为一个块，单个块内包含 OCR 文本、描述文本、原图路径、图片类型；表格块：一个表格尽量作为一个块；如果超大，按行组拆，但每组重复表头；代码块：如果文档包含代码，按函数或代码段切，不要按行切。每个块的元数据字段建议固定为：来源文件名、文件版本、页码、块类型、布局区域坐标、所属章节路径、OCR置信度、生成时间。这些字段在后续重排和过滤时非常关键。比如用户追问“在第六章里找”，可以直接用元数据过滤；如果 OCR 置信度太低，也可以通过阈值把它从候选中剔除。4. 向量化与索引构建：文本向量、图像向量、混合检索4.1 文本向量和图像向量要不要进同一个向量空间这是多模态 RAG 选型里一个绕不开的问题。目前有三条路线：路线一：用同一个多模态嵌入模型把文本和图像同时编码到同一向量空间。好处是用户查询文本可以直接和图片向量计算相似度，天然支持跨模态检索。坏处是模型选择面窄，维度固定，更新成本高。路线二：文本和图像各用各的编码模型，分别建索引，检索时两路召回再合并。好处是可以灵活替换模型，坏处是要处理两种向量之间的分数不可比问题，还要设计合并逻辑。路线三：把图片先转成文本描述，只建文本索引。这是最简单的方式，效果往往比我预期的好。坏处是图片里很多微妙的视觉细节会丢失，比如按钮间距、颜色、边框状态。我的建议是：起步阶段先走路线三，把所有图片的语义描述转成文本，混入文本索引。等验证了场景确实需要“以图搜图”或“图文联合检索”，再上路线一或路线二。不要一上来就追求复杂的多模态向量。4.2 图像描述是“穷人版多模态”，但真管用给每张图片生成一段高质量描述，是多模态 RAG 里性价比最高的一笔投入。描述不要泛泛地说“这是一张图”，而是要把图里和业务相关的关键信息写清楚。举例来说，针对一张设备状态面板截图，生成描述时应该包含：面板的整体布局、每个指示灯的颜色和位置、对应的文字标签、以及可能的含义。这样的描述和用户的提问“设备红色指示灯闪烁是正常吗”就有很高的文本相似度，检索系统不需要真正理解图像内容也能命中。实际操作中，我会同时保存两份描述：一份是简短的“图注型描述”，用于快速召回；另一份是详细的“像素级描述”，用于生成阶段给大模型补充上下文。如果预算有限，至少保证第一份描述是结构化的，像“图中从左到右依次是……，其中第三个是……，颜色为……”。4.3 混合检索的排序合并多模态 RAG 强烈建议做混合检索，也就是向量检索 + 关键词检索并行。向量擅长语义匹配，关键词擅长精确匹配型号、编号、品牌词。比如用户问“AK-300 型号的安装孔距是多少”，向量可能因为语义太近召回一堆不相关内容，关键词能直接拉住具体型号。多路召回之后要合并排序。最简单的做法是加权融合，比如：最终得分 = 0.6 × 向量相似度 + 0.3 × 关键词得分 + 0.1 × 元数据匹配得分。但要注意，不同检索源的分数分布完全不同，直接加权前必须先做归一化，或者把每路结果都转成排名序号再融合。还有一个实操细节：向量检索不能只取一个索引。图片块的描述文本和文本块的正文往往是两套文本，如果它们混在同一索引里，检索向量分布会互相干扰。稳妥的做法是给文本块和图片描述块各建一个索引，或者至少在向量字段上打类型标签，召回时分别限制各类型的数量。4.4 索引更新与去重文档更新时最头疼的问题就是重复和过期。一个文档改了两版，旧版本块还留在索引里，回答时可能同时引用新旧内容，产生矛盾。建议以“文件版本”为索引单元。每处理一个新文档，给这个文档分配一个全局唯一的文档ID和版本ID，所有块都记录这两个字段。更新时，先按文档ID删除所有旧块，再写入新块。删除操作要有幂等性，避免重复跑任务时把索引插两遍。另外，图片块去重也不能忽略。同一张图片在 PPT 和 PDF 里可能会出现多次，视觉特征高度相似。可以在图片入库时计算一个感知哈希，如果哈希接近，保留清晰度高的那一条，并把其他位置的引用信息合并进元数据。5. 检索排序与多模态融合：召回之后怎么办5.1 召回不等于答案，重排决定质量第一次召回通常会拉回 20 到 50 个候选块，但真正有用的可能只有两三个。如果直接把 top-k 塞给生成模型，不仅浪费 token，还容易引入干扰信息。重排这一步必须做。对于文本块，可以用一个交叉编码器模型，把查询和候选块拼接后打分，比单塔向量相似度准得多。对于图片块，不能直接用交叉编码器打分，因为输入不是纯文本。我的做法是：把图片块里面的“OCR 文本 + 图像描述”拼成一段文本，再让交叉编码器打分。这样图片块和文本块在重排阶段就统一到了同一套打分逻辑上。5.2 跨模态置信度校准这里有一个多数人都会踩的坑：不同来源的分数完全不可比。OCR 输出置信度 0.95 的文本，图像描述模型输出的得分可能是 0.7，交叉编码器输出可能是 0.1 到 0.9 的 logits，它们根本不是同一个量纲。所以不能只依赖模型分数，还要在业务层做硬规则。我从实践中总结出的校准策略：设置类型底线：表格块必须包含至少 3 个单元格，否则过滤；OCR 置信度过滤：低置信度的图片块不进入最终候选；类型配额：最终给生成模型的上下文里，文本块最多 N 个，图片块最多 M 个，防止某种类型霸屏；人工反馈回传：把用户点击、点赞、踩过的回答作为重排模型微调样本，这是最有效的长期优化路径。5.3 上下文窗口怎么塞多模态内容生成阶段的输入组装，是很多人会忽略的信息丢失重灾区。如果生成模型是纯文本模型，那就只能把图片的 OCR 文本、图像描述、表格 Markdown 拼进去，原图没法用。这时要注意控制总量，不要贪多，恨不得二十个块全塞进去。一旦上下文太长，模型会把关键信息淹没在无关内容里。如果生成模型支持图像输入，组装方式又不一样。多模态模型的对话消息里，图像是一个独立的内容类型，和文字消息并列。实际操作中，我通常只选择 2 到 3 张最关键的图片传入，并且每张图片都用文字标注一下来源位置，比如“参考图片来自第 3 页左上角”。这样模型既能看图，又能知道图在原始文档里的位置。5.4 幻觉与引用控制多模态 RAG 的幻觉问题比单模态更隐蔽。文本模型面对一张无法真正看到的图时，很容易根据描述文本脑补细节。比如图像描述只写了“图中有一个红色指示灯”，模型却回答“红色指示灯表示温度过高”，这个结论不一定有依据。我处理这个问题的方式是双管齐下。第一，在提示词里明确要求“只能依据给定材料回答，如果材料中没有明确说明，必须说信息不足”。第二，要求回答逐条列出依据，引用格式可以是“[来源文件，第X页，块类型：图片]”。这样用户能点击溯源，系统也能在评测时自动检查引用是否存在于真实输入中。6. 生成阶段与评测：如何验证工作流有效性6.1 评测指标：不能只看回答是否流畅多模态 RAG 如果只看“回答是否流畅”，会掉进严重的评测陷阱。回答流畅不代表检索正确，更不代表图片信息被正确使用。我建议至少盯住五个指标。召回命中率：标准答案里提到的依据块，是否出现在检索返回的候选块里。这是最底层指标，如果这里失败，后面全是空谈。引用准确率：模型回答中列出的每个来源，是否真的包含支持该句结论的内容。这比召回率高一个层次，可以防止模型瞎编来源。答案忠实度：把答案和给定材料交给裁判模型打分，判断是否出现了材料之外的信息。多模态场景下尤其要检查图片细节有没有被错误脑补。视觉依赖度：评测集中有多少问题属于“必须看图才能回答”，系统对这类问题的成功率是多少。这个指标能直接反应多模态改造的价值。端到端任务成功率：不问具体某一步，而是模拟真实用户完整走一遍问答流程，看最终答案是否让用户满意。这是业务方最关心的指标。6.2 构建一份“多模态评测集”没有评测集的 RAG 改造都是自嗨。我建议从真实业务文档里挑 100 到 200 个问题，覆盖文本、图片、表格三种类型，组成专属评测集。针对每个问题，除了写标准答案，还要标注“期望依据类型”。比如：问题：“设备面板上哪个灯表示电源正常？”期望依据类型：图片区域 OCR是否必须原图展示：是允许的回答内容：“右上角绿色指示灯常亮表示电源正常”标注完这些字段之后，每次工作流改动，都能精确看到“图片类问题有没有变好”“表格类问题有没有变坏”。有了这份评测集，很多争论都可以直接量化。6.3 分模块调试：先分开看，再合起来多模态 RAG 链路长，出了问题最难定位。所以我一直坚持模块化调试，不给中间状态留黑盒。当发现一个回答不对，先判断问题出在哪一层。手段是打印每一层的中间结果：解析层打印版面区域列表、OCR 文本、表格结构；索引层打印每类块数量和向量字段内容；检索层打印每路召回命中和分数；重排层打印最终送入生成的候选块列表；生成层打印完整的 prompt 消息内容。哪个环节的预期状态不对，就修哪里。一个真实案例：某次问答系统总是答不出图片里的型号信息。我以为图像描述没写全，后来打印检索结果才发现，图片块的描述文本生成了，但索引更新任务跑挂了，根本没有写入向量库。只看最终答案，永远查不到这里。6.4 常见失败模式与对策最后把我在多模态 RAG 项目里遇到最多的失败模式整理成一张表，做踩坑参考。失败现象根本原因对策图片块检索不到图片描述太泛，或未写入索引用结构化描述模板，检查索引更新任务表格答案残缺表格被拆成多个碎片整表建块，保留 Markdown 和截图双格式回答里出现图中没有的细节模型根据描述脑补限制只能使用给定材料，加入不确定性提示图片块总是排在前面向量分数未归一化对分数做归一化，按类型配额控制上下文爆掉图片原图占用大量 token控制传入图片数量，图片压缩或降分辨率文档更新后答案新旧矛盾旧块未清理按文档版本做全量替换，删除旧版本块用户找不到答案来源回答没有引用编号生成时强制加入来源列表我在实际操作中的体会是，多模态 RAG 工作流真正难的从来不是某一个模型有多强，而是文件解析、分块、索引、检索、生成这五个环节的衔接是否够稳。每次改一个参数，都要回归一次评测集，看整体曲线是向上还是向下。把各个模块的日志和中间结果留好，遇到问题可以先按环节缩小范围，再去调具体模型和阈值，这条路虽然不性感，但最可靠。最后再分享一个小技巧：先拿 30 到 50 份有代表性的文档把全链路跑通，再做 500 份以上的批量扩充。小批量调试时还能人工看中间结果，大批量一上，很多隐藏问题就会迅速放大。