RAG如七夕鹊桥大工程：文档解析落地负面案例解析

RAG技术就像七夕鹊桥工程，如何让query和chunk精准相遇是关键；文档解析落地中又有哪些坑需要避开？

今天主要聊两个话题：一个是RAG，一个是文档解析。先拿七夕搭桥这事儿做个比喻，加深理解；文档解析这块，则从实际落地使用角度出发，总结几个常见问题，以及背后的逻辑和应对思路。多总结、多归纳、多从底层实现分析，总有收获。

一、RAG如七夕，鹊桥大工程

今天是七夕节，社区里有个很形象的比喻：七夕搭桥，恰好可以类比RAG技术路线。为了让用户查询和文档片段实现更精准的“相遇”，我们设计了查询改写、分块策略以及索引优化等多种方案。

很多时候，RAG召不回内容，是因为这桥太窄，或者排在后面的，全是些“山寨牛郎织女”。所谓的山寨，就是伪文档，说白了就是不相关的文档在那儿“冒充”。

query和文档两端优化的实质，就是让这群“喜鹊”（检索机制）认出那对真正的牛郎织女，让他们露出来。而喜鹊的职责——也就是这个检索方式，不管是向量嵌入也好，关键词匹配也罢——得把桥筑牢。不是一次性拉倒，要持久，要稳当。

这就叫，“RAG过七夕，鹊桥大工程”。

二、再看文档解析实际落地存在的问题

1. 文档解析技术的统一测试脚本

有一个文档解析技术测试脚本集合，覆盖了当前主流的各类多模态OCR模型。这个开源项目的参考价值在于，可以用它来做不同模型的统一对比测试，省去自己从头搭建评估框架的力气。

2. 重复输出的问题

遇到无法识别的输入，模型陷入无限输出——这种情况怎么避免？一个直接方案是添加采样参数，例如设置"frequency_penalty": 0.1, "repetition_penalty": 1.1。但要注意，惩罚值设得过高，反而会影响模型输出的效果和准确率。这里需要官方对开源和内部的模型做充分测试，评估不同参数对推理结果准确率的影响。

3. 国产化适配的问题

在CPU或昇腾910B上部署OCR模型的尝试，验证了在CPU及NPU上进行模型部署的可行性。结论比较直接：速度无法接受。用行业里的话说，就是“让领导死了这条心”。这类问题在国产化适配中非常普遍。国产适配真正做好，才能让技术在实际场景中落地应用。

4. 用户输入不可控的问题

对于手机拍摄的屏幕内容，尤其是屏幕纹路比较严重的情况下，识别效果很差。这种情况，得考虑先自己做图像预处理，不能指望模型直接完美输出。

这个问题在MinerU文档解析工具中也有体现。翻拍电脑屏幕的JPG图片无法识别，但转成PDF格式后反而可以识别——这个现象值得深入思考，背后跟图像编码格式和文档处理管线的差异有关。

5. Layout预测错误的问题

经常把流程图识别成了表格。文档中有大量流程图时，MinerU会把部分流程图识别为表格。从原因上看，流程图被识别为表格是已知的局限：两者在版面结构上存在高度相似性——方框、线条、网格等元素让现有模型和启发式规则难以准确区分。

给出的解决思路有两个：一是直接关闭表格识别（将table-config里的enable设为false），这样所有表格和流程图都不会被识别为表格；二是在Markdown或JSON输出后，用脚本做二次筛查和修正，根据内容特征或版面结构过滤掉那些被误判的非真实表格。

6. Markdown中无序列表的换行不被识别的问题

这个问题本质上是不换行的问题——代码内容被当成普通文本合并成一行，丢掉了换行。原因在于，MinerU当前布局模型还没有专门识别和处理代码块，所有程序文本被当作普通文本处理。给出的建议是用正则或脚本对Markdown或JSON结果做后处理，或者在MinerU的backend/pipeline相关模块中尝试自定义格式化逻辑。

经验表明：文档解析的落地，往往不是单个模型的问题，而是一个涵盖数据预处理、模型适配、后处理校正、硬件选型等多环节的系统工程。摸清每一个环节的边界，才能让需要两个文字精确相遇的桥梁，不至于在最后一里路断掉。