今天是2025年7月2日，星期三，北京，晴
今天继续来记录一些文档解析的问题，实际上，我们已经在之前的文章中做过几期了，包括，分析过GOT-OCR、MinerU、ppocrv5、monkeyocr、dophin等开源方案，最近也出了Nanonets-OCR或者OCRFlux等，我们也做过解读。
《真实场景下文档解析中的2大类8个常见问题：目录层级解析、布局检测、阅读顺序及长表格拼接》(https://mp.weixin.qq.com/s/DxIXNkF4lHzVzgw6tiSwCA)，提到多个问题，包括8个问题，pocrv5模型的具体表现？布局检测的问题？阅读顺序的问题？文档背景的干扰问题？文档目录层级解析问题？长表格的拼接问题等等。我们可以将其归并为文档解析处理中的检测问题和语义解析问题两大块内容。
又如：《再思考文档解析最新趋势方案及7类真实场景下文档解析Badcase记录》(https://mp.weixin.qq.com/s/OcQXshrVo9gow-ADqpElHw)，包括7个问题，包括为什么要先做版面分析？为什么不用一个模型在做三个阶段的任务？换成多模态文档解析之后的经典显存问题？下划线的问题，如何解码得到？关于文档跨页拼接的问题等。
现在我们从issues继续看几个典型使用问题，包括数学公式解码、阅读顺序评测、内容遗漏、大写识别、合并页面、幻觉问题、表格带公式等8 个问题。
从实际的业务case出发，看在实际应用过程中会遇到什么问题，以及怎么理解并解释，这其实能够更清晰和直接。
一、从github issues看文档解析8个真实问题
还是回归到具体落地问题，从实际的业务case出发，看在实际应用过程中会遇到什么问题，以及怎么理解并解释。
1、文档解析中的内容遗漏问题及通用性问题
继续看文档解析中的问题，ref:https://github.com/Yuliang-Liu/MonkeyOCR/issues/54
其实是版式分析layout 标签的问题。
另外，关于文档解析中的图片通用性问题，问题是：医疗的诊断表，包含印刷体和非常潦草的手写体。
建议是，对于拍照文档和手写文本，模型目前解析能力比较有限，可以尝试切换布局检测模型为Structure/layout_zh.pt吗，这个对于拍照文档检测效果稍微好一点。
另外，将图片处理为完全黑白的格式可以缓解背景颜色的干扰。
ref:https://github.com/Yuliang-Liu/MonkeyOCR/issues/109
2、文档解析中的公式重复输出问题
这个在我们训练时也出现过，就是测试多行推导公式时，会滥用\qquad，甚至会填充上千个\qquad，这也是语法的问题，训练数据的问题，大家在构造数据的时候可以关注。
ref:https://github.com/Yuliang-Liu/MonkeyOCR/issues/32
3、文档解析中的大写识别问题
中文数字大写识别效果很差，ref:https://github.com/Yuliang-Liu/MonkeyOCR/issues/129，
繁体字应该属于多语言的范畴，MonkeyOCR目前没有使用繁体字数据进行训练，所以繁体字识别可能不好，之后会计划支持繁体字和多语言。
4、文档解析中的阅读顺序评测问题
测量指标Edit如何衡量阅读顺序？ref:https://github.com/Yuliang-Liu/MonkeyOCR/issues/123，论文中衡量版面顺序的算法是Edit，论文是如何在版面层级上测量编辑距离，而非字符层级上的呢。
是编辑距离只能衡量字符插入、删除和替换，因此不能在文字层面上测量，因为版面顺序的结果本质是检测打乱了的文字顺序。OmniDocBench的阅读顺序是按照文本块级别的顺序index进行编辑距离的计算的，可以反应整体的阅读顺序性能。
5、文档解析中的layout缓解误差传播问题
关于为什么monkeyocr这种 layout可以缓解error propagation，ref:https://github.com/Yuliang-Liu/MonkeyOCR/issues/111，
问题是：本质上还是一个pipeline的方法，只是中间识别各种element的时候都使用了同一个大模型而已。因此前面的layout出现了问题，还是会影响后面。所以本方法除了更换了中间识别的模型，和其他pipeline的区别在哪里呢？
从回答上看，不用文本行检测和行内公式检测，减少了检测模型的使用，自然就减少了一部分误差；
以往的主流pipeline方法在做文本块识别的时候会调用公式检测、公式识别、文字检测以及文字识别等多个模型，例如行内公式的识别首先会检测出行内公式，再将检测得到的内容扣出来，送入公式识别模型进行识别，例如一个非常典型的错误例子——这些方法在公式检测时可能会将上一行单词的一部分截取下来，导致公式上下标识别错误。
但是，这个问题确实可以缓解公式的检测问题。但是对于text和table的效果提升文章内似乎并没有提到是如何做到的，这部分的检测和传统的pipeline似乎并无不同，当前的瓶颈主要集中在版面（layout）检测部分。
版面检测的不准确会对表格识别效果造成一定影响，因此目前只能在一定程度上缓解这一问题。
6、文档解析中的合并页面的问题
这个其实在ocrflux中重点讲过，这个在dolphin的issues也有提及，ref:https://github.com/bytedance/Dolphin/issues/46
其中提到一个点，可以关注，“近期也在做文档电子化这块的工作，目前比较通用且效果不错的的方案是，先做分类看是简历、分栏论文、法律文书等，再针对性做layout识别，对每个layout区域做识别（这个部分就可以用传统rapidOCR、视觉大模型、有线无线表格识别等工具了），识别完之后再做融合。“”
这里面做文档的分类，这个路由其实并不太现实，并且需要维护多个layout模型，分类的特征并不明显。
7、文档解析中的幻觉问题
幻觉问题，来自于pretrain和后面的对齐阶段，并且受训练数据影响很大，例如，pdf文件识别后的md结果文件，出现大量和pdf内不相关的内容，ref:https://github.com/bytedance/Dolphin/issues/80
官方回复是：简历场景Dolphin支持的并不好，目前支持的最好的是论文场景，后续会进行简历场景的优化。
8、表格解析中的内部数学公式的识别问题
在使用Dolphin模型处理PDF中的表格时，发现模型对表格内部的数学公式（特别是分数和上标）识别效果不佳，在表格解析模式下，模型似乎倾向于将公式的格式信息（如分数线、上标位置）丢失，并输出为纯文本，导致后续无法正确渲染。
ref:https://github.com/bytedance/Dolphin/issues/63
（文：老刘说NLP）