今天是2025年8月29日，星期五，北京，雨，8月份的最后一个工作日
我们来看两个话题，一个是RAG，一个是文档解析。
RAG如七夕，鹊桥大工程，做个比喻，加深印象。
文档解析上，还是从使用角度出发， 总结一些问题以及对应的产生逻辑、应对思路。
多总结，多归纳，多从底层实现分析，会有收获。
一、RAG如七夕，鹊桥大工程
今天是七夕节，在社区做了个一个很形象的比喻。
七夕搭桥，可以类比RAG，为了让q跟chunk更好地遇见，我们有query改写，
也有chunk切分以及索引等各类方案。
很多时候rag召不回来，是这个桥太窄，或者排在后面，有很多山寨牛郎织女。这个山寨，就是fake doc，就是不相关。很多冒充的。
这就叫，“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 相关模块尝试自定义格式化逻辑
