1. 一个反直觉的跑分结果0.8B 参数怎么把 235B 拉下马第一次看到这个对比数据的时候我的反应和大多数人一样——是不是评测集选得巧、是不是只挑了对自己有利的指标。毕竟在文档解析这个圈子里参数规模长期被当作硬通货235B 级别的模型在通用理解任务上几乎是碾压式的存在。但把 MPDocBench 的细分项拆开看之后我改变了看法这场对比比的不是谁更聪明而是谁更适合长文档结构化解析这个具体活儿。先把结论摆出来在长文档解析这类任务上模型参数量带来的边际收益远小于架构对文档结构先验的利用效率。0.8B 能赢 11 分赢的不是知识储备赢的是对页码、章节、段落、表格这套文档骨架的建模方式。235B 模型如果只是把长文档当成一坨超长文本去理解它在结构还原上的表现反而不如一个专门为结构设计的轻量模型。这件事对做工程落地的人意义很大。过去我们选型文档解析方案第一反应是找个大模型 API 丢进去结果发现成本高、延迟大、页码和章节层级还经常错乱。现在这个对比告诉我们文档解析是一个结构化任务不是一个纯语义理解任务选型逻辑要换。这篇内容我打算把长文档解析这件事从头拆一遍它到底在比什么、State-Recurrent 这类架构为什么在长文档上有优势、MPDocBench 这类评测集在考什么、以及如果你要自己搭一套能输出页码章节段落结构化文本的流水线具体该怎么选型和落地。适合正在做合同、招标文件、实施方案解析的工程同学也适合想搞清楚文档解析到底难在哪的技术读者。2. 长文档解析到底在比什么不是读懂是还原骨架2.1 短文档解析和长文档解析是两回事很多人把文档解析理解成 OCR 加一点版面分析这个认知在单页文档上没问题放到几百页的合同或招标文件上就崩了。短文档解析的核心目标是把这一页的内容识别出来长文档解析的核心目标是把整份文档的层级结构还原出来。这两个目标的难度完全不在一个量级。举个具体的例子。一份 300 页的招标文件里面有章、节、条、款四级标题有跨页的表格有页眉页脚有附录和附件还有大量详见第 X 章的交叉引用。你要输出的结构化文本不只是把文字提取出来还要能回答这些问题第 47 页那段话属于哪一章哪一节这个表格跨了 3 页它的表头是什么这个条款的编号是 3.2.1 还是 3.2.1.1附录是从第几页开始的短文档解析根本不需要处理这些因为一页之内没有跨页结构也没有全局编号体系。长文档解析的难点80% 在结构20% 在文字识别。这也是为什么一个 0.8B 的专用模型能打赢 235B 的通用模型——通用模型文字识别可能更强但结构还原不是它的强项。2.2 结构化输出的四个硬指标我把长文档解析的输出质量拆成四个可量化的指标后面选型和评测都围绕这四个来看指标含义常见失败表现页码准确性每段文本对应的物理页码跨页段落页码归属错误章节层级标题的层级关系和编号把正文误判为标题层级错乱段落边界段落的起止位置多段合并成一段或一段被切碎表格结构表格的行列和跨页合并跨页表格被拆成两个独立表格这四个指标里页码准确性和章节层级是最容易被忽视、也最影响下游使用的。我见过太多方案文字提取准确率 99%但页码全错导致法务同学拿着结构化文本去核对原文时完全对不上最后这套方案直接废弃。2.3 为什么读懂不是关键这里要澄清一个误区。很多人觉得文档解析难是因为文档里的语言难懂其实不是。合同和招标文件的语言高度模板化专业术语重复率极高一个 0.8B 的模型在领域微调后完全能读懂。真正难的是在超长上下文里保持结构一致性。一份 500 页的文档模型要在处理第 480 页的时候还记得第 3 页定义的章节编号规则还要保证第 480 页的段落归属和第 3 页的层级体系一致。这是长程依赖问题不是语义理解问题。235B 模型如果用的是标准注意力机制处理 500 页文档时要么截断、要么注意力稀释结构一致性反而保不住。提示评估一个文档解析方案时别只看文字识别准确率。拿一份 200 页以上的真实文档重点检查第 150 页之后的章节层级和页码是否还准确这才是分水岭。3. State-Recurrent 架构为什么在长文档上占便宜3.1 标准注意力的长文档困境要理解 State-Recurrent 的优势先得说清楚标准 Transformer 在长文档上为什么会吃力。标准注意力机制的计算复杂度是序列长度的平方级一份 500 页文档转成 token 可能是几十万甚至上百万直接算注意力矩阵在工程上不现实。业界的常规做法是分块处理把文档切成若干段每段单独解析最后拼接。这个做法有个致命问题——块与块之间没有状态传递。第 10 块不知道第 9 块结束时的章节层级是什么也不知道当前处于哪一章。结果就是每块都从零状态开始章节编号经常重置跨块段落被硬生生切断。另一种做法是滑动窗口让相邻块有重叠。这能缓解边界问题但解决不了全局结构一致性——窗口再大也覆盖不了整份文档第 480 页依然看不到第 3 页的编号规则。3.2 State-Recurrent 的核心思路把结构状态带着走State-Recurrent 架构的思路很直接维护一个随文档推进而更新的状态向量这个状态承载的是当前文档结构上下文比如当前章节路径、编号规则、表格是否未闭合等。每处理一个块状态更新一次下一个块接着用。用生活化的类比标准分块处理像是一群人接力读一本书但每个人拿到的是撕下来的散页不知道前面读到哪了State-Recurrent 像是同一个人从头读到尾读到哪心里都有数知道现在在第几章第几节。这个设计带来的直接好处有三个章节层级跨页保持一致状态里记着当前章节路径翻页不会丢。跨页表格能正确合并状态里标记表格未闭合下一页继续接。页码归属准确状态里带着当前物理页码段落归属不会错。而且因为状态是固定维度的向量不随文档长度增长所以内存占用和计算量对文档长度是近似线性的不是平方级。这就是 0.8B 模型能在长文档上跑得动、还跑得好的根本原因——它把长程依赖压缩进了一个可控的状态里。3.3 参数量小反而成了优势这里有个反直觉的点在 State-Recurrent 这类架构下参数量小不一定是劣势。因为结构解析这个任务本身不需要海量世界知识它需要的是对文档格式规律的精确建模。一个 0.8B 的模型只要训练数据里覆盖了足够多的文档结构模式就能把状态更新逻辑学得很准。反过来235B 的通用模型如果没针对结构做专门设计它的聪明反而可能带来副作用——它会用自己的语言理解去脑补结构把一些格式上的细节忽略掉。我实测过一些通用大模型做文档解析它们经常把页眉页脚的内容混进正文或者把编号列表当成普通段落就是因为它们太习惯理解语义而忽略了尊重格式。注意这不是说大模型没用而是说在文档解析这个特定任务上架构匹配度比参数规模更重要。选型时先看架构是否支持长程结构状态再看参数规模。4. MPDocBench 这类评测集在考什么以及怎么自己造评测4.1 公开评测集的考察维度MPDocBench 这类长文档解析评测集和通用 OCR 评测集的最大区别在于它把结构还原质量作为核心评分项而不是只看文字准确率。通常包含这几个维度的考察多页文档的章节层级还原给一份几十到几百页的文档要求输出带层级的结构化文本评分看层级是否正确。跨页元素处理跨页表格、跨页段落、跨页列表看是否能正确合并。页码对齐每段文本的页码标注是否和原文一致。复杂版面双栏、图文混排、脚注、页边批注等。这些维度的评分通常不是简单的字符匹配而是结构化的树对比——把预测的结构树和标注的结构树做编辑距离计算。这意味着光把文字识别对是不够的结构错了照样扣分。4.2 公开评测集的局限但我要泼一盆冷水公开评测集只能作为参考不能作为选型的唯一依据。原因有三个第一公开评测集的文档类型有限。MPDocBench 可能偏重学术论文或技术报告但你的实际业务可能是招标文件或医疗病历版面规律完全不同。第二评测集的标注粒度未必匹配你的需求。有的评测集只标到章节级但你需要标到条款级那评测高分不代表你的场景能用。第三评测集的文档长度可能不够极端。如果评测集最长只有 50 页而你的文档动辄 500 页那长程结构一致性的问题在评测集上根本暴露不出来。4.3 自建评测集的实操方法我的建议是公开评测集用来筛掉明显不行的方案自建评测集用来做最终选型。自建评测集的做法如下从真实业务文档里抽样挑 20 到 30 份有代表性的文档覆盖不同长度短的 20 页长的 300 页以上、不同版面单栏、双栏、带表格、不同结构复杂度。人工标注结构树不需要标全文标关键节点就行——每章的起始页码、章节编号、跨页表格的合并关系。标注量控制在每份文档 30 分钟以内。定义评分脚本把预测结果和标注做结构化对比重点算三个分章节层级准确率、页码对齐率、跨页元素合并率。跑对比测试把候选方案都跑一遍看哪个在你的真实文档上表现最好。这套流程我自己跑过好几轮最大的收获是很多在公开评测集上分数接近的方案在真实文档上差距能拉到 20 分以上。因为真实文档的脏程度远超评测集页眉页脚不规范、扫描件倾斜、表格线断裂这些才是真正的考验。评测方式优点局限适用阶段公开评测集可横向对比省事文档类型和长度受限初筛自建评测集贴合真实业务标注成本高终选线上灰度真实反馈周期长上线后5. 从零搭一套能输出页码章节段落的结构化解析流水线5.1 整体架构设计如果你要自己搭一套文档解析流水线输出带页码、章节、段落的结构化文本我建议的架构是四层输入层文档预处理包括格式转换PDF 转图像或文本、扫描件纠偏、去噪。版面分析层识别页面上的版面元素——标题、正文、表格、图片、页眉页脚输出每个元素的位置和类型。结构解析层这是核心用 State-Recurrent 类模型或等效的长程结构建模方案把逐页的版面元素串成带层级的结构树同时维护页码和章节状态。输出层把结构树序列化成目标格式比如带层级标记的 Markdown、JSON 或 XML每段附带页码和章节路径。这个架构里结构解析层是决定成败的一层。版面分析现在有很多成熟方案输出层是纯工程唯独结构解析层需要长程状态建模能力这也是 0.8B 专用模型能发挥价值的地方。5.2 版面分析这一步的坑版面分析看起来简单实际坑很多。我列几个最常踩的页眉页脚的识别。很多方案把页眉页脚当正文处理导致每页都混入重复内容。正确做法是在版面分析阶段就标记页眉页脚区域结构解析时直接过滤。但难点在于有些文档的页眉里包含章节名这个信息其实有用不能简单丢弃要提取出来辅助章节识别。跨页表格的检测。一个表格从第 47 页跨到第 49 页版面分析在单页视角下会把它识别成三个独立表格。要正确合并必须在结构解析层用状态标记表格未闭合。这就是 State-Recurrent 状态的价值所在。双栏排版的阅读顺序。双栏文档如果按从左到右、从上到下的顺序读会把左右栏内容交错。正确做法是先读完左栏再读右栏但版面分析要能判断哪些区域属于左栏、哪些属于右栏。提示版面分析阶段不要追求一步到位先把元素类型和位置识别准阅读顺序和跨页合并交给结构解析层处理。分层处理比一锅端更容易调试。5.3 结构解析层的状态设计如果你用 State-Recurrent 类方案状态向量里至少要包含这几类信息当前章节路径比如[第3章, 3.2节, 3.2.1条]用于判断新标题应该挂在哪一级。编号计数器记录当前各级编号的递增值用于校验和补全编号。未闭合元素标记比如表格是否未闭合、列表是否未结束。当前物理页码用于给每段文本标注页码。状态更新的逻辑是每处理完一个版面元素根据元素类型决定是否更新状态。遇到标题更新章节路径遇到表格开始标记未闭合遇到表格结束清除标记每翻一页更新页码。这套状态设计的好处是可解释、可调试。当输出结构出错时你可以回溯状态变化定位是哪一步更新逻辑有问题而不是面对一个黑盒模型干瞪眼。5.4 输出格式的选择输出格式直接影响下游可用性。我对比过几种常见格式格式优点缺点适用场景Markdown可读性好层级用 # 表示页码信息不好嵌入人工阅读JSON结构清晰字段灵活体积大不直观程序处理XML层级表达强可加属性冗余多传统系统对接HTML保留版面信息解析复杂需要还原版面我的建议是主输出用 JSON附带一个 Markdown 视图。JSON 里每个节点包含type标题/段落/表格、level层级、page页码、content内容、children子节点。这样程序处理方便需要人工看的时候再渲染成 Markdown。6. 实测中的意外情况与排查链路6.1 章节编号突然重置我遇到过一个典型问题一份 400 页的文档前 200 页章节编号正常到第 201 页突然从第 1 章重新开始。排查下来发现文档中间有一个分册标记模型把这个标记当成了新文档的开始状态被重置了。排查链路是这样的先看输出结构树定位到编号重置的具体页码再回看该页的版面分析结果发现有一个特殊的分隔符元素最后确认是状态更新逻辑里遇到分隔符就重置了章节路径。修复方法是区分文档分隔符和分册分隔符只有前者才重置状态。这个坑的教训是状态重置的触发条件要设计得足够细不能一遇到分隔符就重置要区分分隔符的语义。6.2 跨页表格被拆成两个另一个高频问题是跨页表格合并失败。表现是第 47 页的表格和第 48 页的表格在输出里是两个独立表格表头重复出现。根因通常是版面分析在第 47 页末尾识别到表格结束因为页面到底了状态里的表格未闭合标记被清除第 48 页的表格就被当成新表格。修复方法是表格是否结束不能只看页面边界要看是否有表格结束的视觉信号比如表格线闭合、后续是正文段落。如果页面到底但表格线未闭合状态标记要保留。6.3 页码偏移一页页码偏移是个隐蔽的坑。表现是输出里所有页码都比实际少 1。排查发现是文档有封面和目录页模型从正文第一页开始计数但用户期望的页码是物理页码含封面。这个问题的本质是页码定义不统一。修复方案是在输出里同时提供两种页码物理页码PDF 实际页序和逻辑页码文档内标注的页码。下游用哪个自己选。6.4 排查方法论把这几个案例抽象一下长文档解析的排查方法论是定位现象从输出结构树里找到出错的具体位置和页码。回溯状态看该位置的状态向量是什么和预期差在哪。检查输入回看该页的版面分析结果确认输入是否正确。验证逻辑检查状态更新逻辑看是哪条规则导致了错误状态。构造最小复现把出错的那几页单独抽出来构造一个最小测试用例方便反复调试。这套方法论的关键是状态可观测。如果你的方案是个纯黑盒这五步根本走不通。这也是我推荐 State-Recurrent 这类显式状态方案的原因之一——它天生可观测、可调试。7. 选型建议什么场景该用轻量专用模型什么场景该上大模型7.1 按文档类型选不是所有文档解析都适合轻量专用模型。我的经验是格式规范的文档合同、招标文件、实施方案、技术标准优先用轻量专用模型。这类文档结构规律强专用模型的状态建模能发挥最大价值成本还低。格式混乱的文档扫描件、手写批注、复杂图文混排可能需要大模型兜底。这类文档的版面变化太大专用模型的训练数据未必覆盖。混合场景用轻量模型做主力大模型做兜底。轻量模型处理不了的页面路由给大模型。7.2 按成本约束选成本是个绕不开的现实问题。235B 模型跑一份 500 页文档的成本可能是 0.8B 模型的几十倍甚至上百倍。如果你的业务量大这个差距直接决定方案可行性。我算过一笔账假设一份文档平均 200 页每天处理 1000 份用大模型 API 的成本可能是每天几千块用自部署的轻量模型硬件摊销下来每天可能只要几十块。在文档解析这种高频、大批量的场景下轻量专用模型的成本优势是决定性的。7.3 按精度要求选如果业务对精度要求极高比如法律合同解析错一个字都不行那可能需要大模型加人工复核。但如果精度要求是结构正确、文字准确率 99% 以上轻量专用模型完全够用。关键是要把精度要求拆解到具体指标。是文字准确率要求高还是结构还原要求高前者可能需要大模型后者轻量专用模型反而更强。7.4 一个务实的组合方案综合下来我推荐的务实方案是主力0.8B 级别的 State-Recurrent 专用模型负责结构解析和大部分文字识别。兜底大模型 API只处理专用模型置信度低的页面。后处理规则引擎做编号校验、页码对齐、格式规范化。人工复核只复核低置信度片段而不是全文。这个组合方案在成本、精度、可维护性之间取得了平衡。我实测下来90% 以上的页面由轻量模型处理只有不到 10% 需要大模型兜底整体成本比纯大模型方案低一个数量级精度还更好。注意兜底路由的阈值要调。阈值太松大模型调用量大成本下不来阈值太紧精度保不住。建议用自建评测集跑几轮找到成本和精度的平衡点。8. 我个人在实际操作中的几点体会做文档解析这几年最大的体会是这个领域的核心竞争力不在模型多大而在对文档结构的理解有多深。0.8B 赢 235B 这件事本质上是一个懂文档结构的人赢了一个聪明但不懂文档结构的人。第二个体会是评测要趁早自建。我早期太依赖公开评测集选了一个在评测集上分数很高的方案结果上线后发现真实文档上表现很差返工成本很高。后来养成习惯任何方案选型前先用自己的文档跑一遍心里才有底。第三个体会是状态设计要留调试接口。State-Recurrent 这类方案最大的好处是状态可观测但前提是你要把状态暴露出来。我在实现时会把每一步的状态变化打成日志出问题时能快速回溯。这个投入在后期排查时能省下大量时间。最后一个实用技巧处理超长文档时先做一次全局的目录提取。很多文档前面有目录页目录里包含了完整的章节结构和页码。把目录解析出来作为先验能大幅提升后续结构解析的准确率。这个技巧在合同和招标文件上特别有效因为这类文档的目录通常很规范。
