1. 多模态 RAG 到底在解决什么问题1.1 从纯文本 RAG 的天花板说起做过 RAG 项目的人大概都有过这种体验文本知识库跑得挺顺召回率、命中率都还看得过去结果一遇到 PDF 扫描件、产品手册、财报图表、工程图纸整条链路立刻趴窝。原因不复杂——传统 RAG 的检索单元是文本块而现实世界里大量高价值信息压根就不是纯文本形态存在的。我去年接手过一个招投标场景的知识库项目客户丢过来三千多份文件里面混杂着扫描版合同、带复杂表格的报价单、带页眉页脚的实施方案、还有一堆带流程图的附件。最开始我用常规的文本抽取加切分方案跑出来的效果惨不忍睹表格被拆成乱序的字符流章节标题和正文混在一起页码信息全丢检索出来的片段根本没法定位到原文。这就是纯文本 RAG 的天花板——它假设信息是线性的、连续的、可无损转成字符串的但真实文档不是这样。多模态 RAG 要解决的核心问题就是让检索系统能够理解并利用文档的视觉结构信息。这里的多模态不是指花哨的图片生成而是指把文本、版面布局、图像区域、表格结构这些不同模态的信息统一纳入检索和生成流程。文档解析负责把非结构化文档转成结构化表示视觉检索负责在向量空间里同时匹配文字语义和视觉特征两者配合才能把 RAG 的召回质量拉上一个台阶。1.2 文档解析与视觉检索的分工边界很多人会把文档解析和视觉检索混为一谈觉得上了 OCR 就等于做了多模态。实际上这两件事的职责完全不同我习惯用一个类比来解释文档解析像是把一本纸质书拆解成带目录、带页码、带图表标注的电子版视觉检索像是给这本书建一个既能按关键词查、又能按长得像什么查的索引系统。文档解析的输出目标是一份结构化文本它要保留页码、章节层级、段落边界、表格行列关系、图片位置这些元信息。视觉检索的目标是构建多路召回能力既能在文本 embedding 空间里找语义相近的段落也能在视觉 embedding 空间里找版面相似的页面或图表。两者是上下游关系解析质量决定了检索的上限检索策略决定了生成阶段能拿到多少有效上下文。我见过不少团队一上来就堆视觉模型结果解析层输出的文本本身就是乱的再强的检索也救不回来。所以我的建议永远是先把文档解析做扎实再考虑视觉检索的增强。这个顺序反了投入产出比会非常难看。1.3 适合谁来参考这套方案这篇内容适合三类人一是正在做企业知识库、合同审查、招投标文件处理的工程师你们大概率已经被复杂文档折磨过二是做 RAG 应用但对多模态还没系统下手的开发者想搞清楚从哪切入三是技术负责人需要评估多模态 RAG 的落地成本和收益边界。前置知识方面你至少得懂基本的 RAG 流程切分、embedding、向量检索、重排、生成用过至少一个向量数据库对 OCR 有概念性的了解。不需要你精通视觉模型训练因为工程落地阶段大部分工作是解析管线和检索策略的调优而不是从头训模型。2. 文档解析把非结构化文档变成可检索的结构化文本2.1 解析管线的整体设计思路一条完整的文档解析管线我通常拆成五个阶段格式识别、版面分析、内容抽取、结构重建、质量校验。每个阶段都有坑而且坑和坑之间会互相放大。格式识别阶段要判断输入是原生 PDF、扫描 PDF、图片、Office 文档还是混合体。这个判断直接决定后续走哪条路径——原生 PDF 可以直接抽文本层扫描件必须走 OCROffice 文档走专门的解析库。我踩过的一个坑是有些 PDF 前几页是原生文本后面夹着扫描页如果整份文件按一种策略处理扫描页会直接变成空白。版面分析阶段要做的是识别页面上的区域类型正文、标题、表格、图片、页眉页脚、页码。这一步的准确性直接决定结构重建的质量。传统做法是用规则加投影分析现在更稳的是用版面检测模型比如基于 LayoutLM 系列或者 DocLayNet 训练出来的检测器。我实测下来纯规则方案在规整文档上够用但一遇到多栏排版、跨页表格就开始崩。内容抽取阶段文本区域走 OCR 或文本层抽取表格区域走专门的表格识别图片区域可以选择性地做图像描述生成。这里有个关键决策图片要不要转成文字描述。我的经验是对于流程图、架构图这类信息密度高的图生成描述是有价值的对于装饰性图片生成描述反而会引入噪声不如直接保留图片引用。结构重建阶段是把抽取出来的碎片按阅读顺序拼回带层级的文档树。这一步最容易被忽视但它恰恰是后续检索能定位到第 3 章第 2 节第 4 段的关键。质量校验阶段则是用规则或小模型检查解析结果比如检测空段落比例、表格行列数异常、页码连续性等。2.2 OCR 选型本地方案与云服务的取舍OCR 选型是文档解析里最纠结的一环。我把常见方案列个表对比一下这些都是我在实际项目里用过的。方案类型代表工具优势劣势适用场景本地开源Tesseract免费、可离线、可定制中文识别率一般、版面处理弱对成本敏感、数据不能出内网本地开源PaddleOCR中文效果好、支持版面分析部署稍重、需要调参中文文档为主的生产环境本地开源Umi-OCR开箱即用、支持竖排批量处理能力有限小规模、快速验证本地开源RapidOCR基于 ONNX、部署轻复杂版面支持一般边缘设备、轻量场景云服务各家云 OCR识别率高、支持票据合同模板按量计费、数据出境顾虑结构化字段抽取、票据场景我个人的选择逻辑是这样的如果数据敏感度不高、预算充足、且需要抽取固定模板票据的关键字段比如合同里的金额、单位、时间云 OCR 的模板能力确实省事。但如果是通用文档、数据不能出内网我会优先选 PaddleOCR中文场景下它的综合表现最均衡。Tesseract 我一般只在两种情况下用一是需要快速验证流程二是目标文档是印刷体英文。它的中文识别在复杂版面上掉点很明显尤其是竖排文本和带背景噪声的扫描件。Umi-OCR 有个竖排/纵向阅读顺序开关处理古籍或者竖排排版时挺方便但它的定位更偏向桌面工具做批量管线要额外封装。提示OCR 选型不要只看单字识别率版面分析能力往往比识别率更影响最终效果。一个识别率 98% 但阅读顺序全乱的方案实际可用性远不如识别率 95% 但结构完整的方案。2.3 结构化输出的字段设计文档解析的输出到底该长什么样这个设计决定了后面检索和生成的便利程度。我推荐的最小字段集是这样的{ doc_id: contract_2024_001, page_num: 3, block_type: paragraph, section_path: [第三章, 3.2 付款条款], content: 甲方应在合同签订后三十日内支付首期款项..., bbox: [120, 340, 560, 420], table_data: null, image_ref: null }这里几个字段值得展开说。section_path是章节层级路径它让检索结果能直接告诉用户这段话出自第三章第二节而不是只给一个孤立的文本块。bbox是文本块在页面上的坐标视觉检索和结果高亮都靠它。block_type区分段落、标题、表格、图片生成阶段可以据此决定怎么组织上下文。表格数据我建议单独存成二维数组或者 HTML 表格字符串不要硬塞进content字段。因为表格的检索逻辑和段落不一样段落靠语义相似度表格往往靠表头关键词匹配。混在一起会让两边的效果都变差。页码信息千万别丢。我见过太多解析方案把页码当噪声过滤掉结果检索出来的内容无法定位原文用户根本没法核对。页码、章节、段落这三层定位信息是多模态 RAG 相比纯文本 RAG 的核心优势之一。2.4 解析质量的校验与兜底解析管线跑通只是开始真正难的是保证质量稳定。我一般会设几道校验关卡。第一道是空内容检测如果某页解析出来的文本长度低于阈值比如 50 字符大概率是 OCR 失败或者版面分析漏检需要标记出来人工复核或走备用解析路径。第二道是阅读顺序校验检查解析出的文本块顺序是否符合从上到下、从左到右的常规阅读逻辑。多栏排版最容易在这里出问题我遇到过双栏 PDF 被解析成左右交错的情况读起来完全不通。第三道是表格完整性校验检查表格的行列数是否合理有没有出现某行单元格数量突变的情况。跨页表格是重灾区需要专门的合并逻辑。第四道是页码连续性校验如果解析结果里页码跳号或者重复说明页面处理环节有问题。兜底策略上我会准备两条解析路径主路径用效果最好的方案备用路径用更保守但更稳的方案。主路径失败时自动切换同时记录失败样本用于后续优化。这个设计在实际生产里救过我好几次尤其是遇到格式特别刁钻的文档时。3. 视觉检索让检索系统看懂版面3.1 视觉检索要解决的核心痛点纯文本检索有个根本性缺陷它把文档当成一袋词丢掉了版面信息。但很多检索需求恰恰依赖版面。比如用户想找那份带流程图的实施方案或者表格里有报价明细的那一页纯文本检索根本无从下手因为这些特征不在文字里。视觉检索的价值就在这里。它通过视觉 embedding 把页面的版面特征编码成向量让找长得像某类版面的页面成为可能。同时视觉特征还能辅助文本检索做重排——当两个文本块语义相似度接近时版面位置、字体大小、是否在表格内这些视觉信号可以帮助判断哪个更相关。我做过一个对比实验在招投标文件检索场景下纯文本检索的 Top-5 命中率大概在 62%加入视觉特征重排后提升到 78%。提升主要来自两类查询一类是定位特定章节视觉上标题层级明显一类是找特定表格视觉上表格结构明显。3.2 视觉 embedding 的构建方式视觉 embedding 的构建有几种主流思路我按落地难度从低到高排一下。最简单的是页面截图 通用视觉模型。把每页渲染成图片用 CLIP 这类模型编码成向量。优点是实现快缺点是粒度粗一页里可能混着多个主题检索精度有限。进阶一点的是区域截图 视觉模型。结合文档解析的 bbox把每个文本块或表格区域单独截图编码。粒度细了但计算量上去了而且区域切分的质量直接影响效果。再进一步是版面特征 文本特征融合。除了视觉 embedding还把版面特征位置、大小、类型编码成结构化向量和文本 embedding 拼接或加权融合。这种方式效果最好但工程复杂度也最高。我实际项目里用得最多的是第二种因为它在效果和成本之间比较平衡。具体做法是文档解析阶段输出的每个 block根据 bbox 从页面渲染图里裁出对应区域缩放到统一尺寸过视觉编码器得到向量存进向量库时和文本向量并列存储。注意视觉 embedding 的维度通常比文本 embedding 高存储和检索成本要提前算清楚。如果文档量在十万页级别全量存视觉向量对向量库的压力不小需要考虑降维或者分层索引。3.3 多路召回与融合排序视觉检索不是替代文本检索而是和它配合。我常用的架构是三路召回加融合排序。第一路是文本语义召回用文本 embedding 在段落级别检索这是基础盘。第二路是视觉相似召回用视觉 embedding 在区域级别检索补充版面相关的查询。第三路是关键词召回用 BM25 或类似算法做精确匹配兜住那些语义模型搞不定的专有名词、编号、代码。三路召回的结果合并后过一层重排模型。重排模型我一般用交叉编码器输入是查询和候选片段的文本加视觉特征输出相关性分数。融合策略上我倾向于给文本语义召回较高权重视觉召回作为补充信号关键词召回作为精确匹配的保障。这里有个实操细节不同召回路径的分数尺度不一样不能直接相加。我通常先对每路分数做归一化再用加权求和或者学习排序的方式融合。权重需要根据业务场景调没有万能值。3.4 视觉检索的存储与索引设计存储设计上我建议文本向量和视觉向量分开存但用同一个 doc_id 和 block_id 关联。这样检索时可以灵活组合也方便单独优化某一路。索引结构上如果向量库支持多向量字段可以直接在一个 collection 里存两种向量。如果不支持就建两个 collection检索时分别查再合并。我实测下来分开存的可维护性更好因为两路向量的更新频率和重建成本不一样。分层索引是个值得考虑的优化。对于超大规模文档库可以先用一个粗粒度的页面级索引做初筛再用细粒度的区域级索引做精排。这样能把检索延迟控制在可接受范围内。我做过一个测试百万级页面的库不分层检索延迟在秒级分层后能压到百毫秒级。4. 实操落地从零搭一条多模态 RAG 管线4.1 环境准备与依赖选型我按最小可跑通的配置来列这套组合我在多个项目里验证过稳定性和效果都还行。# 文档解析核心 pip install paddleocr paddlepaddle pip install pdfplumber pymupdf pip install python-docx openpyxl # 向量与检索 pip install sentence-transformers pip install chromadb pip install rank-bm25 # 视觉编码 pip install open_clip_torch pip install pillow # 生成与编排 pip install langchain pip install ollama选型理由说一下。PaddleOCR 负责 OCR 和版面分析中文场景综合表现最好。PyMuPDF 负责原生 PDF 的文本层抽取和页面渲染速度比 pdfplumber 快不少两者可以互补——PyMuPDF 抽文本和渲染图pdfplumber 处理复杂表格。ChromaDB 作为向量库轻量、易部署适合中小规模验证。OpenCLIP 做视觉编码开源、可离线、模型选择多。Ollama 跑本地生成模型避免依赖外部服务。如果你要上生产向量库可以换成 Milvus 或 Qdrant生成模型可以换成更大参数量的本地模型或者走内部推理服务。但验证阶段上面这套足够跑通全流程。4.2 文档解析的完整实现先写解析主流程。核心思路是先判断文档类型再走对应解析路径最后统一输出结构化 block 列表。import fitz # PyMuPDF from paddleocr import PaddleOCR ocr PaddleOCR(use_angle_clsTrue, langch, show_logFalse) def parse_pdf(pdf_path): doc fitz.open(pdf_path) blocks [] for page_idx, page in enumerate(doc): text page.get_text().strip() if len(text) 50: # 原生文本层可用直接抽取 page_blocks extract_native_blocks(page, page_idx) else: # 扫描页走 OCR pix page.get_pixmap(dpi200) img_path f/tmp/page_{page_idx}.png pix.save(img_path) page_blocks extract_ocr_blocks(img_path, page_idx) blocks.extend(page_blocks) return blocksextract_native_blocks用 PyMuPDF 的get_text(dict)拿到带 bbox 的文本块再根据字体大小和位置推断标题层级。extract_ocr_blocks调 PaddleOCR拿到文本、置信度和 bbox再按 y 坐标排序还原阅读顺序。阅读顺序还原这块有个细节PaddleOCR 返回的结果是按检测顺序排的不一定是阅读顺序。我的做法是先按 bbox 的 y 中心聚类成行行内按 x 排序行间按 y 排序。多栏排版需要先做栏检测这个可以用 PaddleOCR 的版面分析能力或者自己写个基于 x 坐标分布的简单聚类。表格处理单独走一条路径。PyMuPDF 有find_tables()方法能识别一部分表格结构。识别不了的用 PaddleOCR 的表格识别模型。表格输出成二维数组同时保留 bbox 和所在页码。4.3 向量化与索引构建解析完拿到 block 列表接下来做向量化。文本向量和视觉向量分开处理。from sentence_transformers import SentenceTransformer import open_clip import torch from PIL import Image text_model SentenceTransformer(BAAI/bge-large-zh-v1.5) clip_model, _, preprocess open_clip.create_model_and_transforms( ViT-B-32, pretrainedlaion2b_s34b_b79k ) def build_index(blocks, page_images): text_vectors [] visual_vectors [] metadatas [] for block in blocks: # 文本向量 tv text_model.encode(block[content]) text_vectors.append(tv) # 视觉向量从页面图裁出 bbox 区域 page_img page_images[block[page_num]] x0, y0, x1, y1 block[bbox] crop page_img.crop((x0, y0, x1, y1)) crop_tensor preprocess(crop).unsqueeze(0) with torch.no_grad(): vv clip_model.encode_image(crop_tensor) visual_vectors.append(vv.squeeze().numpy()) metadatas.append({ doc_id: block[doc_id], page_num: block[page_num], section_path: .join(block[section_path]), block_type: block[block_type] }) return text_vectors, visual_vectors, metadatas文本模型我选 BGE 系列中文语义检索效果稳。视觉模型选 ViT-B-32参数量适中编码速度快精度够用。如果对视觉检索精度要求更高可以换 ViT-L-14但编码成本会上去。存进 ChromaDB 时文本向量和视觉向量分别建 collection用 block_id 关联。检索时两路分别查再按 block_id 合并。4.4 检索与生成的串联检索阶段我实现一个三路召回加融合的函数。def hybrid_retrieve(query, top_k10): # 文本语义召回 text_results text_collection.query( query_embeddings[text_model.encode(query)], n_resultstop_k * 2 ) # 视觉召回查询本身是文本时用文本编码器近似 query_visual clip_model.encode_text( open_clip.tokenize([query]) ).detach().numpy() visual_results visual_collection.query( query_embeddingsquery_visual, n_resultstop_k * 2 ) # 关键词召回 bm25_results bm25_index.get_top_n(query, top_k * 2) # 融合排序 merged merge_and_rerank( text_results, visual_results, bm25_results, query ) return merged[:top_k]融合排序我用一个简单的加权方案起步文本语义 0.5视觉 0.3关键词 0.2。这个权重不是拍脑袋是我在几个项目里调出来的经验值。文本语义是主力视觉补充版面信号关键词兜精确匹配。实际项目里可以根据业务反馈微调。生成阶段把检索到的 Top-K 片段按章节路径和页码排序拼成上下文加上系统提示词丢给生成模型。提示词里我会明确要求模型引用来源格式是根据第 X 页第 Y 节。这样用户能核对也方便后续做引用溯源。def build_prompt(query, retrieved_blocks): context_parts [] for block in retrieved_blocks: header f[来源第{block[page_num]}页 {block[section_path]}] context_parts.append(f{header}\n{block[content]}) context \n\n.join(context_parts) prompt f基于以下文档内容回答问题引用时请标注来源页码和章节。 文档内容 {context} 问题{query} return prompt5. 常见问题与排查技巧实录5.1 解析阶段的典型故障问题一扫描件 OCR 后文本乱序。这是最常见的。排查思路是先看 OCR 返回的 bbox 是否正常如果 bbox 正常但顺序乱说明是排序逻辑的问题。多栏排版需要先做栏检测我一般用 x 坐标的直方图找栏边界再按栏内排序。如果 bbox 本身就乱说明 OCR 的检测环节有问题可能需要换模型或者调整检测参数。问题二表格被拆成散乱文本。检查解析时有没有走表格专用路径。如果走了还乱看表格识别模型是否支持跨页合并。跨页表格需要根据表头重复出现或者列对齐关系做合并这个逻辑得自己写。问题三页码信息丢失。检查解析时有没有把页眉页脚当噪声过滤掉。页码通常在页面边缘容易被版面分析误判为页眉页脚。我的做法是单独识别页码区域保留其文本和位置不参与正文排序但存入元数据。问题四章节层级识别错误。标题层级靠字体大小和加粗判断但有些文档标题和正文的字体差异不明显。这种情况我会结合编号模式如第一章1.1一做辅助判断规则加模型双保险。5.2 检索阶段的典型故障问题一视觉检索召回结果和查询不相关。先检查视觉 embedding 的质量。如果区域截图裁得不准视觉向量就是噪声。检查 bbox 是否正确裁剪时有没有留足边距。另外通用 CLIP 模型对文档版面的理解有限如果效果持续不好可以考虑用文档版面数据微调或者换用专门针对文档训练的视觉模型。问题二多路召回融合后排序不合理。检查各路分数的归一化是否正确。不同召回路径的分数分布差异很大直接加权会出问题。我一般用 min-max 归一化或者用排名倒数作为融合依据后者更鲁棒。问题三检索延迟过高。视觉向量维度高检索慢是正常的。优化方向有三个降维PCA 或量化、分层索引先粗筛再精排、限制视觉召回的候选数量。我实测下来把视觉召回候选数控制在文本召回的 1.5 倍以内延迟能明显下降效果损失很小。问题四专有名词检索不到。这是语义模型的通病。关键词召回就是兜这个的。如果 BM25 也兜不住检查分词是否正确专有名词有没有被切碎。必要的话建一个专有名词词典检索时做同义词扩展。5.3 生成阶段的典型故障问题一模型编造来源。提示词里明确要求引用来源但模型还是可能编。解决办法是在后处理阶段校验引用如果引用的页码或章节在检索结果里不存在就标记为可疑。更严格的做法是只允许模型从给定片段里摘录不允许改写来源信息。问题二上下文超长导致截断。多模态 RAG 检索回来的片段往往比纯文本多容易超上下文窗口。我的做法是按相关性排序后截断同时保证每个章节至少保留一个片段避免信息断层。表格片段优先保留因为表格信息密度高。问题三生成内容与原文不符。这是幻觉问题。除了提示词约束我还会在生成后做一次事实校验用检索结果和生成内容做比对标出可能不一致的地方。这个校验可以用小模型做也可以用规则做。5.4 常见问题速查表故障现象可能原因排查方向解决思路OCR 文本乱序阅读顺序还原逻辑缺失检查 bbox 和排序代码加栏检测和行聚类表格结构错乱未走表格专用解析检查 block_type 判断接入表格识别模型页码丢失被当页眉页脚过滤检查版面分析规则单独识别页码区域视觉召回不准区域裁剪或模型问题检查 bbox 和截图质量调边距或换模型检索延迟高视觉向量维度大看检索耗时分布降维或分层索引专有名词漏召语义模型局限看关键词召回结果加词典和同义词扩展生成编造来源提示词约束不足看引用是否可校验后处理校验引用上下文超长召回片段过多看 token 数按相关性截断5.5 几条踩坑换来的经验第一条解析质量决定一切。我见过太多团队在检索和生成上花大力气结果解析层输出的文本本身就是错的后面怎么调都白搭。建议把至少一半的优化精力放在解析上。第二条视觉检索不是万能的。它对版面相关的查询有效对纯语义查询帮助有限。不要指望加了视觉检索就能解决所有召回问题该做关键词召回还得做。第三条权重需要按业务调。我给的 0.5/0.3/0.2 只是起步值。合同审查场景可能关键词权重更高技术文档场景可能语义权重更高。上线后一定要根据实际查询日志调权重。第四条保留原始文档的定位信息。页码、章节、bbox 这些信息在生成阶段可能用不上但在用户核对和问题排查时价值巨大。别为了省存储把这些丢了。第五条小步验证别一上来就全量。先拿几百份文档跑通全流程验证效果和性能再逐步扩量。我见过一上来就处理百万文档结果解析管线有 bug返工成本极高。6. 多模态 RAG 的扩展方向6.1 从文档解析到知识图谱文档解析输出的结构化文本其实可以直接喂给知识图谱构建管线。章节层级天然就是树结构表格里的实体关系可以抽成三元组图片描述可以挂到对应节点上。这样检索时就不只是向量匹配还能走图查询对复杂推理类问题帮助很大。我试过把合同文档解析后构建成知识图谱节点是条款、金额、时间、主体边是引用、依赖、冲突关系。检索哪些条款和付款相关这类问题时图查询比向量检索精准得多。当然图谱构建的成本也高适合高价值场景。6.2 多模态融合的进阶玩法现在的方案里文本和视觉向量是分开存、分开查、后期融合。更进阶的做法是训练一个多模态融合编码器把文本和视觉特征在编码阶段就融合。这样检索时只需要一路查询效率和效果都可能更好。但训练成本高需要标注数据适合有条件的团队。另一个方向是引入版面图结构。把文档页面表示成图节点是文本块和图像区域边是空间邻接和阅读顺序关系。用图神经网络编码能更好地捕捉版面语义。这个方向学术界研究挺多工程落地还不多见。6.3 与 Agent 结合的可能性多模态 RAG 和 Agent 结合是个有意思的方向。Agent 可以根据查询类型动态选择检索策略语义查询走文本检索版面查询走视觉检索精确查询走关键词检索。甚至可以让 Agent 多轮检索第一轮粗筛第二轮针对性地深入某个章节。我最近在试的一个玩法是让 Agent 先判断查询意图再决定要不要触发视觉检索。这样能避免不必要的视觉编码开销也能提升检索精度。实测下来对于明确的语义查询跳过视觉检索能省 40% 左右的延迟效果几乎无损。文档解析这块后续还可以扩展的方向包括手写体识别、公式识别、多语言混排处理。视觉检索可以扩展的方向包括跨页版面匹配、图表内容理解、版面相似度聚类。这些方向都有实际需求但落地难度和成本需要单独评估。我个人在实际操作中的体会是多模态 RAG 的价值不在于技术多炫而在于它能不能解决纯文本 RAG 解决不了的实际问题。如果你的业务场景里复杂文档占比高、检索需求依赖版面信息那这套方案值得投入。如果文档本身就很规整、查询也很简单那可能纯文本方案就够了没必要为了多模态而多模态。技术选型永远要回到业务价值上这是我做了这么多项目最深的感受。