OCR选型背后的文档解析能力思考

一、问题的起点：为什么“识别准确”不等于“可用”

在大语言模型与检索增强生成系统的落地过程中，一个反复出现的现象是：模型本身能力足够，但最终回答质量依然不稳定。排查链路之后，问题往往不在推理侧，而在输入端——文档解析的结果缺乏结构、上下文断裂、元素关系混乱。

传统OCR工具的核心逻辑是从图像中提取字符，输出“文字在哪里”。这一逻辑在处理简单印刷品时足够有效，但面对真实业务场景中的复杂文档，短板迅速暴露：

• 标题与正文的层级关系丢失，模型无法判断哪些内容是主旨、哪些是展开说明；
• 段落被按行或按块切割，原本连贯的论证被拆成孤立片段；
• 表格被识别为散落的单元格文本，行列对应关系不复存在；
• 跨页段落被硬生生截断，前文与后文无法建立语义关联；
• 图表、公式、印章等非纯文本元素被忽略或错误转换。

这些问题的共同后果是：RAG系统拿到的是“文字集合”，而非“文档语义”。当检索单元变成碎片化的文字块时，向量相似度计算难以定位真正的关键信息；即便检索到了相关片段，由于上下文不足，大模型在生成阶段也可能出现理解偏差或信息拼接错误。

因此，面向大模型应用的文档解析，核心诉求已经发生变化：从“字符级识别”转向“语义级结构还原”。这一转变也重新定义了OCR选型的评估维度。

二、关键能力维度：从版面还原到语义理解

2.1 版面元素的高精度识别与分类

一份技术文档通常包含多种版面元素：标题、副标题、正文段落、页眉页脚、表格、图片、公式、代码块、注释等。高精度的解析首先要求系统能够准确识别这些元素的存在，并对其进行正确分类。

分类的意义在于：不同类型的内容在大模型处理时需要不同的策略。标题用于构建文档大纲，表格需要保持行列结构，公式需要转换为可计算的表达形式，页眉页脚通常属于低价值信息应被过滤或标记。如果所有内容都被当作“普通文本”处理，模型将无法建立文档的认知框架。

2.2 坐标信息与阅读顺序的保留

识别出元素之后，还需要知道它们在页面中的位置关系。坐标信息的作用体现在两个层面：

其一，阅读顺序的恢复。多栏排版、图文混排、侧边栏注释等复杂布局中，视觉位置与逻辑阅读顺序并不一致。解析系统需要基于坐标信息判断内容块之间的先后关系，生成符合人类阅读习惯的文本流。

其二，元素间关系的表达。一个插图与其下方的说明文字之间存在语义关联，表格的标题与表格本体需要绑定，段落中的某句话可能指向一个脚注。坐标信息为这些关系的建模提供了基础数据，使得解析结果不仅是“有哪些内容”，还包括“内容之间如何组织”。

2.3 表格的完整结构保持

表格是文档中最容易在解析过程中“崩坏”的元素。简单的单元格提取会丢失合并单元格的层级关系，复杂表头中的分类信息无法体现，跨页表格被截断后前后文对不上。

面向RAG场景的表格解析需要做到：保持行列的二维结构、识别合并单元格的跨度、正确关联表头与数据单元格、将表格转换为Markdown或JSON等结构化格式。只有这样，当用户提出“对比表格中某两个指标”的问题时，系统才能给出准确的答案。

2.4 跨页内容的连续性与段落聚合

文档的分页是物理边界，但段落的语义边界不必然受分页约束。一个段落可能从第3页延续到第4页，一个表格可能横跨两页，标题可能单独出现在某一页底部而正文从下一页开始。

解析系统需要具备跨页聚合的能力：识别被分页符打断的段落并将其合并，判断标题与后续内容的归属关系，处理跨页表格的续表标记。这一能力直接影响到检索片段的完整性与模型理解的上下文充分性。

2.5 特殊元素的处理：公式、手写体、印章与条码

真实文档中还可能包含以下元素，它们对解析系统提出了额外要求：

• 数学公式：需要转换为LaTeX或MathML等结构化表达，而非作为普通文本或图片输出；
• 手写体：在批注、签名、表单等场景中出现，需要专门的识别策略；
• 印章与二维码：在合同、证明文件、票据中常见，其存在本身可能具有法律或业务流程意义，需要被标记或提取；
• 表单字段：键值对形式的结构化信息，要求解析结果保留字段名与填写内容的对应关系。

这些元素的正确处理，往往是区分“通用OCR”与“文档智能解析”的分水岭。

三、结构化输出：为什么Markdown与JSON成为主流选择

解析结果的输出格式直接影响下游系统的接入效率。当前业界实践中，Markdown与JSON是两个主要选项，它们各有侧重。

Markdown的优势在于其语义表达能力：标题层级（#、##）天然对应文档结构，表格语法保留行列关系，列表、引用、代码块等语法覆盖常见内容形态。将解析结果输出为Markdown，相当于在保留可读性的同时注入了结构信息，大模型可以直接理解并利用这些标记。

JSON的优势在于其机器可处理性：每个内容块可以作为独立对象，附带类型标签、坐标信息、置信度元数据等。这对于需要精细控制检索粒度的系统尤为重要——开发者可以根据元素类型筛选索引范围，或利用坐标信息实现原文定位与高亮回显。

在实际工程中，理想的解析系统通常支持同时输出两种格式，或在不同环节选择不同格式：解析阶段使用JSON获取详细的元素信息，下游任务中使用Markdown作为模型输入的标准化文本。

rag-">四、在RAG链路中的具体价值体现

理解了能力维度之后，还需要回答一个更实际的问题：文档解析质量的提升，究竟如何转化为RAG系统的效果提升？

在索引构建阶段，结构化解析结果可以支持更合理的切分策略。系统可以按标题层级划定语义块边界，避免在段落中间强制截断；表格可以作为独立的检索单元而非被打散；低价值的页眉页脚可以在索引前被过滤，减少噪声。

在检索阶段，带有类型标签的内容块可以支持更精准的过滤条件。当用户提问聚焦于表格数据时，系统可以优先检索表格类型的内容块；当问题涉及某个章节的主题时，标题信息可以作为相关性判断的加分项。

在生成阶段，完整且连续的上下文让大模型有充分的信息基础进行推理。表格结构与标题层级的保留，使得模型在回答“总结第二章的要点”或“对比表中A与B的数值”时，能够正确理解引用内容的意义。

进一步而言，在不进行模型微调的前提下，提升输入文档的质量是对系统效果最直接、成本最可控的优化手段之一。模型的推理能力上限由参数与训练数据决定，但如果输入信息本身就存在结构性缺损，再强的模型也无法从残缺的原料中还原出准确的答案。

五、选型建议与实践考量

对于正在构建知识库、智能问答或RAG应用的团队，在评估文档解析方案时，建议从以下几个维度进行考察：

评估维度	关键问题
格式覆盖	支持哪些输入格式？PDF、扫描件、Office文档、图片是否都能处理？
元素识别	是否识别标题、表格、公式、页眉页脚、手写体、印章等？
结构保持	表格是否保持行列关系？跨页段落是否聚合？阅读顺序是否正确？
输出格式	是否支持Markdown、JSON等结构化输出？是否包含坐标信息？
接入便利性	API设计是否清晰？是否支持批量处理？返回结果的解析成本如何？

此外，建议在实际接入前进行小规模基线测试：选取业务中具有代表性的文档样本（包含复杂表格、跨页段落、图文混排等场景），对比解析结果在检索命中率与答案准确率上的差异。这类测试的结论通常比参数对比更有参考价值。

最后需要强调的是，文档解析不是一次性解决的问题。不同业务场景下的文档形态差异显著，最优方案往往需要在通用能力基础上，结合具体场景进行针对性调优。选型的关键，是找到在识别精度、结构理解深度、输出灵活性三者之间与自身业务需求最匹配的方案。