今天是2024年11月12日，星期二，北京，天气雾。
先说关于RAG切分的开源库Chonkie：https://github.com/bhavnicksm/chonkie，https://pypi.org/project/chonkie/，支持TokenChunker: Splits text into fixed-size token chunks；WordChunker: Splits text into chunks based on words；SentenceChunker: Splits text into chunks based on sentences；SemanticChunker: Splits text into chunks based on semantic similarity；SDPMChunker: Splits text using a Semantic Double-Pass Merge approach共5种切分方式，详细看https://github.com/bhavnicksm/chonkie/blob/main/DOCS.md，一些对比结论：https://github.com/bhavnicksm/chonkie/blob/main/benchmarks/README.md，跟其他切分组件(如LangChain、LlamaIndex)的对比，可作为再次温习使用。
今天，我们来看看关于实际业务落地中的文档顺序的问题，文档阅读顺序，这个问题其实很常见，一方面，这个可以用于文档转markdown，尤其是涉及到包括双栏、多栏等问题时候，更需要能够保持阅读顺序，当然，还存在于OCR这个关键环节当中。
我们来看看一些具体的代表思路，供大家一起参考。
一、OCR中的阅读顺序问题
在实际生产应用中，扫描文档的布局信息通常是通过一个前置的OCR组件活动，词语的顺序按照布局坐标框从上到下、从左到右的顺序排列，因而会产生阅读顺序问题，即词语排列顺序和人类阅读顺序不符的问题，举下面一个例子：
现实场景下扫描文档的阅读顺序问题。最右侧是根据OCR结果自动排列的伪阅读顺序，和人类阅读顺序相冲突。
这类问题的一个解决方案，可以参考《Reading Order Matters: Information Extraction from Visually-rich Documents by Token Path Prediction》(https://arxiv.org/abs/2310.11016)的一个方案，当然也有现在使用大模型进行ocr修正的方案，例如llm_aided_ocr(https://github.com/Dicklesworthstone/llm_aided_ocr)，通过LLM对OCR提取的文本进行纠错与格式调整，对应的prompt如下：
二、文档布局中的阅读顺序问题**
另一个是文档布局的阅读顺序问题，一般在进行版式布局分析之后，可以得到各个区块的boundingbox，然后根据这个bouding的信心，使用启发式方法 (Heuristic Method)，按照从左到右从上到下的顺序排列进行处理。这种方式显然是不是很worked的。
如《XYLayoutLM: Towards Layout-Aware Multimodal Networks For Visually-Rich Document Understanding》(https://arxiv.org/pdf/2203.06947)中提到的XFUN数据集，红色表示顺序是错误的。
里面最为直接的方式就是(a) descending by (Y,X)或者(b) descending by X+Y，这个面对这种表格的情况显然是不够好的，所以也就提出了xycut(这个很早，在1995年提出的Recursive xy cut using bounding boxes of connected components. In ICDAE, 1995)方案。
相较于启发式的XY Cut，Augmentd XY Cut以一定的概率给文本框的box一些小的x轴和y轴上的平移扰动，从而生成一些合理的阅读顺序，以模拟现实场景中ocr的识别噪声，从而提升模型的鲁棒性。也就是底下的思路：
对应的图例如下：
实现代码可以在：https://github.com/littletomatodonkey/Augment-XY-CUT/blob/main/README.md中找到。
另一种方式就是使用深度学习的方式来做，例如，《LayoutReader: Pre-training of Text and Layout for Reading Order Detection》(https://arxiv.org/pdf/2108.11591,https://github.com/microsoft/unilm/tree/master/layoutreader)提到的方案，使用LayoutLM的布局模型作为编码器。
在编码阶段，LayoutReader将源序列和目标序列打包成一个连续的输入序列，并设计了自注意力掩码来控制token之间的可见性。在解码阶段，模型预测源序列中的索引。
又如，《DLAFormer: An End-to-End Transformer For Document Layout Analysis》(https://arxiv.org/abs/2405.11757O)，定义了三种不同类型的关系，然后将顺序问题转换为关系预测。
例如： 内部区域关系（Intra-region relationship），在同一个文本区域内，所有相邻文本行之间建立内部区域关系，如果文本区域只包含一行文本，则该文本行的关系被指定为自引用；区域间关系（Inter-region relationship），表现出逻辑联系的区域对之间的区域间关系，如两个相邻段落之间或一个表格与其相应的标题或脚注之间的关系以及逻辑角色关系（Logical role relationship），包括标题、小节标题、段落等。由于每个文本区域都被分配了一个逻辑角色，因此在文本区域中的每行文本与其相应的逻辑角色单元之间建立逻辑角色关系。这种关系定义就很有趣，不当可以做阅读顺序，还可以做区域逻辑关系抽取；
然后模型上，通过Unified Relation Prediction Head模块计算文本行/区块查询与逻辑角色查询之间的逻辑关系得分以实现关系分类。
但是，基于这种深度学习的方式来做顺序，其实并不快，丽日以下的对比，因为是decode方式的，所以一旦页面中待排序的区域数量很多，那么解码的时间回随之变长，此外还有部署显卡成本。
所以，在更多时候，我们还是会使用augumented xycut这种方式来做，简单、高效。
总结
本文主要介绍了关于文档顺序的问题，但虽然有这么多方案，简单、高效解决问题才更有趣，开源的代码也很多，可以多看看。
参考文献
1、https://blog.csdn.net/yjh_SE007/article/details/140062523
2、https://github.com/littletomatodonkey/Augment-XY-CUT
3、https://arxiv.org/pdf/2203.06947
4、https://arxiv.org/abs/2310.11016
关于我们
老刘，NLP开源爱好者与践行者，主页：https://liuhuanyong.github.io。
对大模型&知识图谱&RAG&文档理解感兴趣，并对每日早报、老刘说NLP历史线上分享、心得交流等感兴趣的，欢迎加入社区，社区持续纳新。
加入会员方式：关注公众号，在后台菜单栏中点击会员社区->会员入群加入
