REAL-MM-RAG：真实场景多模态检索基准的设计与工程实践

干检索这行的人大概都有过这种体验：公开榜单上排名靠前的模型，拿自家数据一测就露馅。尤其是做RAG（检索增强生成）相关系统的团队，纯文本的检索基准已经卷得足够成熟了，但一旦数据里混进表格、图片、截图、扫描件，整个链路的表现就变得难以预测。

REAL-MM-RAG就是冲着这个缺口来的。它全称叫A Real-World Multi-Modal Retrieval Benchmark，一个聚焦真实世界场景的多模态检索基准测试。我做这套东西的出发点很直接：现有的多模态评测大多停留在“图文匹配”这种实验室任务上，而真实业务里的检索是“用户拿一段文字或一张截图，去一个混杂着PDF、网页、表格、图片的知识库里找证据”。这篇文章会把整个基准的设计思路、数据标注方法、评估指标、工程实现，以及我在搭建和调优过程中踩过的坑，全部拆开来说一遍。适合正在做多模态RAG、企业知识库检索，或者准备从单模态往多模态迁的工程团队参考。

1. 为什么要做REAL-MM-RAG：真实场景和标准基准之间的断层

1.1 现有基准到底测了什么

这些年大家在多模态检索上没少下功夫。纯文本侧的基准，比如段落检索和问答类数据集，测试的核心能力非常单一：给定一个文字查询，从文本库里把相关的段落找出来。这类评测对文档结构、版面复杂度的模拟几乎为零，语料默认是干净的、按段落切分好的、没有图片打断的。

跨模态侧的基准则是另外一路，主流评测方式是把“图片”和“文字描述”配对，考察模型能否在给定一种模态时检索到另一种模态。这类基准训练出来的模型对“这是一张猫的图片”和“a photo of a cat”这种对称关系学得很好，但真实业务里的查询远没有这么对称。用户不会说“请检索一张包含XX接口的图纸图片”，他们更可能是截图里画了个红圈，配上一句“这个位置在文档哪一页有说明”。

这两类基准之间，恰好缺了一个中间地带：既不是纯文本段落检索，也不是简单的图文语义匹配，而是把真实文档中所有模态当作一个整体去检索。REAL-MM-RAG想补的正是这块。它不测模型能不能理解“猫和cat是同一个东西”，而是测系统能不能在几十页的维修手册里，把一张产品爆炸图连同旁边的参数表格一起捞出来，供后续的生成模块引用。

1.2 真实世界的多模态检索难在哪

如果只是把图片和文本混在一起建索引，那问题还不算大。真正的难点在于真实文档的结构会对检索造成系统性干扰，我拆成四类来说。

第一类是模态碎片化。文档里最常见的情况是“正文说见图3，图3在第5页”。文本切块时，正文节点和图节点各管各的，没有关联。检索模型匹配到了“见图3”，但返回给用户的是一句没头没尾的文字，真正的图没有跟着出来。线下检索只看相关性还好，放到RAG的生成链路里就很致命，模型对着“图见第5页”这句话没法做任何推断。

第二类是语义不对称。用户在查资料时的表达往往是口语化、不精确的，比如“那个带红色按钮的电源模块”，但文档里对应的术语可能是“PSU-300W rev.B”或者“电源冗余模块”。纯文本精确匹配直接被毙掉，向量召回又在短文本上不稳定。更麻烦的是，如果这个模块的图片是主体，文本只有一句图注，那单模态索引基本无解。

第三类是OCR噪声和表格结构。扫描件里的错字、表格转成纯文本后行列关系丢失、图片被压缩后细节不可辨——这些问题单拎出来每一个都足够让评估指标掉好几个点，但它们真实存在于每个企业知识库里。拿一份干净语料测系统，自然测不出这些问题的水平。

第四类是查询本身可能是多模态的。用户拍一张设备照片，问“这个型号有没有对应配件”。文本查询和图片查询在索引策略上是两条路，查询一到手就要做路由判断，这又是额外的工程。现有基准根本没有这一层，所以大多数RAG系统直到上了线，才被这种真实查询方式打懵。

2. REAL-MM-RAG的评测设计：从数据到指标怎么定

2.1 数据构成与任务划分

REAL-MM-RAG的数据全部来自脱敏后的真实业务文档，这一点是这个基准区别于其他实验室数据集的核心。我们从知识库中抽出6000多份文档，涵盖网页存档、PDF手册、PPT导出、扫描文件、Excel表格以及产品实拍图。文档不是孤立的，而是依据主题被组织成若干业务主题库，检索时要按整个知识库范围进行，这样才贴近“打开搜索框找东西”的真实使用条件。

任务划分上没有走复杂的路线，一共定义了四类检索任务。第一类是纯文本检索，用文字查询检索文档中的文本块，检索单元是切好的信息块。第二类是跨模态检索，包含两项子任务：文搜图和图搜文。第三类是复合查询检索，也是我认为最有价值的一类：查询是“图片+文字”的组合，比如一张接口截图加上一句“对应的针脚定义在哪里”。第四类是重排序任务，给定首轮召回得到的候选集合，模型要判断结果是否真的相关，这个任务直接服务于RAG链路里“精排”这一环。

标注环节上，标注员需要先通读原始文档，把每个查询对应的“最小证据单元”标出来。举个例子，查询“产品A的拆解步骤”对应的证据可能是文字步骤列表加一张内部结构图，两者必须同时被标注为一个整体；只标其中一个都不算完成。每条查询至少由双人独立标注，不一致的交给仲裁。这套双人标注加最小证据单元的流程，保证了参考答案不会因为标注粒度太粗而虚高。

2.2 指标怎么选，为什么不能只看MRR

指标这件事，如果照搬纯文本检索那套，会出问题。REAL-MM-RAG保留了三个经典指标：Recall@10、MRR@10和nDCG@10，用来和现有工作做对比，这是必要的。但针对多模态的特点，我们额外设计了两个衡量维度。

第一个是模态覆盖率。最终答案里，如果查询目标是“一张图加一段文字”，那么系统返回的结果必须同时涵盖图片节点和文本节点，才算一次完整命中。单出文本结果、单出图片结果都属于部分命中。这个指标可以直接反映RAG系统在生成阶段的信息完备性——你召回了一个“见图5”，但没有把图5捞出来，生成模型就算再强，也没法凭空把图上的内容说出来。

第二个是端到端生成结果的事实一致性。对于RAG场景，光看检索指标还是不够的，检索好不代表最后回答好。我们会抽一部分查询，让系统基于检索结果生成最终答案，再交给专家按“是否忠实于检索证据、是否有关键信息缺失”来打分。这一项不追求自动评分，靠的是人工抽检加辅助打分工具。虽然成本高，但它是衡量基准是否真的对RAG场景有价值的关键一步。

指标的使用逻辑其实很简单：真实用户要的不是“排在第一位的答案”，而是“整个结果列表能凑齐解决他问题的信息”。所以Recall@10和模态覆盖率，优先级高过MRR。排名好不好是体验问题，信息全不全才是成败问题。

3. 工程拆解：怎么搭一套可复现的评测基线

3.1 文档预处理链路

拿到原始文档，第一步就是版面分析。这一步的目标是把一页纸拆成有语义的区块：标题区、正文文本区、表格区、图片区、页眉页脚区。实现上可以用开源的版面分析模型，也可以自己训练一个简单的检测模型，关键是把“图片”“表格”“文本”分段标出来。页眉页脚这类噪音区块直接丢弃，不进入索引。

第二步是OCR。扫描件和图片中的文字都需要OCR提取，识别结果会作为图片节点的附属文本，一并写入索引。需要注意，OCR文本虽然可能有错字，但它提供了图片的“可检索性”，价值远大于噪声带来的负面影响。第三步是表格序列化，这一步最容易被偷懒省略，但恰恰很关键——表格不能直接转成纯文本，行列关系一旦丢失，内容虽然能召回，但生成模型没法读懂。常见的做法是把表格转成带行号、列名的线性化文本，或者保留HTML结构。我更推荐保留结构化的序列表示，因为它还能支持后续的表格问答，这是纯文本做不到的。

第四步是层级切块。切块不能按固定字符数硬切，要按文档的结构来。一个章节下的正文、图片、表格应该尽量关联在同一个段落组下，同时保留章节标题、页码这些上下文信息。我在实际工程里的做法是：每个块节点额外挂一个“片段父节点”字段，存章节路径；图片节点再挂一个“所在段落组”字段，这样在处理“图片+正文”这类跨模态引用关系的时候，检索层可以额外加一个源头关联约束。

3.2 索引与检索的配置参考

预处理完成后，进入索引环节。文本块用稠密向量加BM25的混合检索，图片节点则单独处理：图片本身的embedding加OCR文本的embedding，共同组成图片节点的索引。注意，图片节点不能只靠图像向量，必须把OCR文本向量也挂上去。实际测试中，纯图像向量在短文本查询上的表现非常不稳定，配上OCR文本后召回率能提升好几个点。

复合查询的路径需要单独处理。当检测到查询中携带图片时，文本部分走文本索引，图片部分走图片索引，然后各自取回的结果再在融合层做加权。可以用一个简单的规则判断查询是否含图，不需要动用复杂的多模态分类模型，因为查询本身是输入给系统的，有没有图片文件是一眼能看出来的事。

下面给出一份我在基线实验里用过的配置参考：

preprocessing: layout_model: layout_v2 ocr_model: ocr_server_b table_mode: structured_line chunking: text_block_size: 512 text_block_overlap: 64 preserve_structure: true indexing: text_index: dense_model: multilingual_embedding_large sparse_method: bm25 image_index: visual_model: clip_large attach_ocr_text: true retrieval: top_k_candidates: 100 fusion_weights: dense: 0.6 sparse: 0.4 image_text_weight: 0.5 rerank: enabled: true top_n: 50 model: cross_encoder_multimodal_v2

这套配置的核心思想是“混合召回加精排”。混合召回负责广撒网，cross-encoder负责精细化打分，最后再靠人工规则保证模态覆盖。权重不能拍脑袋定，fusion_weights需要在验证集上跑一小批数据，观察哪路召回对结果贡献大，再调。

3.3 重排序为什么能显著提升效果

只靠双塔模型做召回，速度快，但文本和图片两个模态的特征不在同一个空间里，排序质量粗糙。重排序阶段，我通常用一个可以同时吃“查询文本+候选文本”或“查询文本+候选图片”的交叉编码器，对前100个候选逐一打分。

交叉编码器最大的特点是查询和候选会做深层交互，因此能捕捉到双塔模型捕捉不到的细粒度语义。代价是慢，所以它只能作用于小候选集。我常用的策略是先粗召回100个候选，重排序后取前50个。50这个数字是在成本和效果之间折中的结果——取10个的时候，有些关键图片节点已经被排到后面丢了；取100个又会让下游生成模块的输入过长。

一个容易被忽略的点是，重排序之后最好加一条硬规则：如果查询集中在某个章节，保证该章节的结果至少有两条进入最终列表。因为真实的问答场景里，信息往往是分散在多段的，靠模型打分很容易把同一来源的高相似结果全部顶到前面，反而漏了其他角度的补充信息。

4. 评测和调优实录：那些躲不掉的坑

4.1 高频问题速查表

这套基准跑下来的实际体验，和公开论文里光鲜的数字差别很大。下面这张表是我在搭建和调优过程中遇到的高频问题的汇总，基本覆盖了第一次接触多模态RAG评测时容易踩的坑。

4.2 一个把图片查询得分从0.31拉到0.66的案例

这套基准最典型的一次调优来自图片检索链路。第一次跑基线的时候，我直接沿用了纯文本RAG的流程：文档切块、文本向量化、BM25混合检索，完全没处理图片。结果整个系统在纯文本查询上的Recall@10还挺正常，但一到图片查询就崩了，图片检索的Recall@10只有0.31，基本等于靠运气。

定位问题的方式是指标倒推。先看失败用例，发现所有失败查询都有一个共性：文档里明明有对应图片，但系统检索到的全是文本块。进一步查索引结构，发现图片在预处理时被单独存成了一个二进制对象，向量化只是对图片本身做了embedding，OCR文本完全没挂进来。图片在系统里是一个“孤儿节点”，文本查询自然碰不到它。

改法并不复杂。第一步，把版面分析的结果改为“图片+OCR文本+图注”作为一个复合节点进入索引，图片的visual embedding和OCR文本向量都挂在这个节点下。第二步，在查图片时，让文本查询向量和图片向量先各走各的召回通道，再把得分融合。第三步，针对图片质量参差的问题，统一做了一次缩放和对比度归一化，避免真实业务图入库时尺寸差异过大影响向量分布。

改动之后，图片检索的Recall@10从0.31升到0.66，整体所有任务的加权平均从0.72升到0.86。这个涨幅不是因为换了什么复杂模型，而是把本来零散挂在系统里的图片信息接回了主链路。从中我最想强调的是：跑这套基准的价值，就是能把“图片检索不好用”这种模糊感知，变成“某类节点缺失”这种可定位的具体问题。

5. REAL-MM-RAG还能扩展到哪些场景

5.1 这套基准适合谁用

从规模上看，REAL-MM-RAG不是给做纯学术模型的团队准备的，它更适合以下三类团队：一是正在做企业内部知识库搜索的团队，尤其是数据里带大量产品手册、技术图纸、扫描合同的；二是已经在单模态RAG上跑通，但想判断要不要往多模态投入的团队；三是做客服助手、设备维修辅助、专业知识问答这类垂直应用的团队，这类应用对“图片+文字”混合证据的需求特别高。

对这类团队来说，REAL-MM-RAG的价值不只是给出一个分数。它更像一套体检流程：哪些任务类型做得好、哪些节点没挂上、哪些指标虚高，比总分更能反映系统真实的健康状态。拿我们自己的经验来说，第一次完整跑完这套基准的产出，是一份给产品团队看的“能力边界报告”，明确列了系统在哪些查询类型上不能承诺效果。

5.2 后续还能怎么扩展

当前版本的REAL-MM-RAG聚焦在静态文档检索上，后续扩展有三个明确方向。一是流式增量数据，现实中的知识库每周都在更新，文档一旦更新，旧索引和新索引之间不能互相覆盖错误，这需要基准引入时效性评估。二是长视频片段和音频，真实场景里用户查“刚才那个操作演示在哪一步”，需要的检索单元是视频片段而不是帧，这是完全不同的切割和表征方式。三是多语言混合场景，跨语言查询和文档混合出现时，embedding模型的表现会明显分化，也需要一套专门的评测任务来约束。

如果你只想把一个方向做深，我建议先做流式增量。因为基准的长期价值在于能反复用来回归，而知识库更新是每个业务都会遇到的场景。静态快照式的评估跑几次就失真了，只有动态更新的评测集才跟得上真实系统的变化节奏。

5.3 回到真实场景的一点体会

在我实际推进这套基准的过程中，最大的感悟是：评测基准的分数不能完全代表线上效果，但它最大的价值，是把你对系统的模糊感知变成可定位的指标。任何一个做检索系统的人，都应该先正视一个问题：你的文档库里有多少信息是藏在图片、表格和扫描件里的？如果这个比例超过三分之一，而你还在用纯文本基准来测系统，那你对系统能力的认知大概率是错的。

REAL-MM-RAG的构建过程让我重新梳理了多模态检索的最佳实践：版面分析不能省，图片节点必须挂OCR文本，表格必须保留结构，硬规则和多样性约束要结合使用，指标设计必须围绕“证据完整性”而不是单纯的排名高低。如果你正在准备把RAG系统推向真实数据，我建议你也从这些点入手，一点点把线下的“感觉”变成线上可验证的数字。