RAG如七夕，鹊桥大工程：再看文档解析实际落地badcase

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

今天是七夕节，在社区做了个一个很形象的比喻。

七夕搭桥，可以类比RAG，为了让q跟chunk更好地遇见，我们有query改写，

也有chunk切分以及索引等各类方案。

很多时候rag召不回来，是这个桥太窄，或者排在后面，有很多山寨牛郎织女。这个山寨，就是fake doc，就是不相关。很多冒充的。

q，d两头的优化，就是让这批喜鹊们，认识出那对真正的牛栏织女，他俩得露出来，然后，喜鹊的职责，就是这个检索方式，Embedding也好，关键词也行，得把桥筑牢了，别一次性，得持久，得稳当。

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

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

1、Docs Parsing Techniques，jupyter 笔记本集合，对目前多模态OCR模型做的统一测试脚本，https://github.com/AdemBoukhris457/Docs_Parsing_Techniques?tab=readme-ov-file，可以借鉴的点是，可以用于我们去做不同模型的使用和对比测试。

2、重复输出的问题，遇到无法识别的一直无限输出，这种情况怎么避免，方案是：添加采样参数可以解决， 例如"frequency_penalty": 0.1, "repetition_penalty": 1.1 。惩罚过高，会影响模型输出。 需要官方测试 开源和内部的 不同的参数 ，对推理结果准确率的影响。ref:https://github.com/rednote-hilab/dots.ocr/issues/99

3、国产化适配的问题。在 CPU/910B 部署dots.ocr模型的一些尝试，验证在CPU及NPU上验证模型部署的可行性。结论：速度无法接受，让领导死了这条心。https://github.com/rednote-hilab/dots.ocr/issues/102，https://github.com/rednote-hilab/dots.ocr/issues/74

这类问题很普遍，如：https://github.com/Yuliang-Liu/MonkeyOCR/issues/51，国产适配好，才能用好。

4、用户输入不可控问题。对于手机拍摄屏幕，屏幕纹路比较严重的情况下，识别效果不行。https://github.com/rednote-hilab/dots.ocr/issues/120，这种考虑自己先进行预处理。

这个问题，在mineru中也有体现，例如，https://github.com/opendatalab/MinerU/issues/3380，翻拍电脑屏幕的jpg图片无法识别，转成pdf却可以。

5、layout预测错误问题，会经常把流程图识别成table。文档中有很多流程图，mineru会把一部分流程图识别成table，https://github.com/opendatalab/MinerU/issues/3270

从原因上看，程图被识别成 table 是已知的局限，主要因为两者在版面结构上有相似性（如方框、线条、网格等），现有模型和启发式规则无法准确区分。

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

6、markdown中无序列表的换行不识别问题，这个问题其实是不换行问题。需要做后处理。https://github.com/opendatalab/MinerU/issues/3274，也见于https://github.com/opendatalab/MinerU/issues/3112

原因方面，这是 MinerU 当前布局模型的已知限制，代码块（如程序文本）尚未被模型专门识别和处理，因此所有代码内容会被当作普通文本合并成一行，缺少换行。

给出的建议是建议用正则或脚本对 markdown/JSON 结果做后处理，在 mineru/backend/pipeline 相关模块尝试自定义格式化逻辑