文档解析新范式：视觉语言模型直出Markdown，让RAG地基更稳

很多做 RAG（检索增强生成）应用的同学都有过这种体验：模型选型、向量库调优、提示词工程都花了大力气，最后线上效果却卡在了一个最不起眼的环节——文档解析。PDF 里提取出来的是一堆乱码，表格结构全部丢失，扫描件直接空白，更别提双栏论文、复杂页眉页脚和混合排版了。

Cohere 近期发布的 Parse 5（parse-v5.0）把这件事重新做了一遍。它是一个 2.3B 参数的视觉语言模型，专门干一件事：把企业文档直接转换成 Markdown。这个方向值得关注，不是因为“又多了一个大模型”，而是它传递了一个非常清晰的技术信号——企业文档解析正在从“OCR + 版面分析 + 规则后处理”的传统管道，切换到“端到端视觉语言模型直接输出结构化 Markdown”的新范式。

这篇文章不打算写成官方公告复述，而是从开发者的角度拆三层内容：第一，为什么企业文档解析会成为大模型应用的真实瓶颈；第二，Parse 5 这类专用视觉语言模型为什么能把问题简化，以及 2.3B 参数意味着什么；第三，拿到一个文档解析模型之后，怎么把它接入 RAG 链路、怎么验证效果、有哪些坑需要提前避开。如果你正在做企业知识库、合同审核、财报分析或者任何涉及“非结构化文档”的 LLM 应用，这篇文章值得读完。

1. 这篇文章真正要解决的问题

先说一个容易被低估的事实：RAG 系统的质量上限，往往不是由模型决定的，而是由“喂进去的内容”决定的。

向量检索的效果取决于文本切分的质量，文本切分的质量取决于文档解析的质量。如果原始 PDF 解析出来是乱码、表格被拍平成一行文字、扫描件里的数字识别错误，那么后面无论用多强的 Embedding 模型和生成模型，结果都会是“垃圾进，垃圾出”。

传统文档解析链路通常是这样：

扫描件/PDF -> OCR 文字识别 -> 版面分析(标题/段落/表格/图片) -> 规则后处理 -> 纯文本

这条链路的问题在于每个环节都是独立模块，错误会逐级累积。OCR 把标题里的“1.2 合同金额”识别成“1.2 合同金颉”，版面分析又没能识别出表格边界，后处理规则只能靠正则去补各种特殊情况，最后补来补去，换个版式的文档又崩了。

Parse 5 代表的思路完全不同。它直接把整个文档页面作为视觉输入，用一个视觉语言模型端到端地生成 Markdown 文本。中间不需要单独维护 OCR、版面分析、表格识别、规则修正这些模块，而是让模型自己学习“看到页面 -> 还原结构”的映射。

本文最适合的读者有几类：

• 在做企业知识库或 RAG 的工程师，当前正被 PDF 解析质量折磨。
• 想评估“视觉语言模型替换传统 OCR 管道”是否可行的技术负责人。
• 做数据中台、文档管理平台，需要把海量历史文档结构化的后端团队。
• 对多模态大模型落地感兴趣，想理解“小参数专用模型”在实际工程中的价值的研究者或开发者。

2. 基础概念：视觉语言模型与文档解析的本质变化

要理解 Parse 5，先要理解它到底在解决什么数学问题：给定一个文档页面图像，生成一段结构正确的 Markdown 文本。

视觉语言模型（Vision Language Model，VLM）是一种同时接受图像和文本输入、生成文本输出的多模态模型。常见的开源模型有 LLaVA、Qwen2-VL 等。Parse 5 属于这一类模型，但它不是那种什么都能聊的通用助手，而是一个高度专门化的解析器——输入是一页文档图像，输出是包含标题层级、表格、列表、代码块的 Markdown。

这里的本质变化，是从“识别”到“还原结构”的跃迁。

传统 OCR 关心的是“这一块文字是什么字”，版面分析关心的是“这一块属于什么类型”，它们彼此分离。而 VLM 端到端建模的是“整个页面的视觉布局如何映射为文本结构”。表格不是一堆散落的文字，而是有行、列、表头语义的结构；标题不是字体大一号的文本，而是有层级的章节信息。

另外要注意一个细节：Parse 5 的名字里有“Parse”，核心是解析，不是理解。它不需要理解合同里的法律条款含义，也不需要判断财报数字是否合理，它只负责把文档“原样”翻译成 Markdown。这个边界很重要，也是它敢用 2.3B 这么小的模型来做这件事的原因——任务域收窄了，模型规模就不需要那么大。

从模型结构的角度看，Parse 5 的 2.3B 参数意味着它由一个小规模的视觉编码器和一个语言解码器组成。视觉编码器把页面图像切成视觉 token，语言解码器逐 token 生成 Markdown 文本。训练目标是标准的文本生成损失，只不过训练数据是“文档图像 -> Markdown 标注”的大规模配对数据。

3. 为什么输出 Markdown：不只是格式问题，而是 RAG 质量

很多人第一反应是：把 PDF 转成 Markdown 有什么稀奇的？不还是文本吗？这里的门道比表面看起来深得多。

Markdown 是一种轻量级标记语言，用一组简单的符号表达文档结构：#表示标题层级，|表示表格，-表示列表，反引号表示代码块。它之所以成为文档解析的理想输出格式，是因为它把“结构信息”和“纯文本内容”融为一体。

对比三种常见的解析输出格式：

对 RAG 链路来说，Markdown 的价值体现在三个层面。

第一，切分质量提升。按纯文本切分时，系统无法判断哪里是章节边界，经常把两个章节硬切在一个 chunk 里。有了#、##这样的标题标记，就相当于给了切分器一个“天然锚点”，可以做到按语义单元切块，而不是按固定字符数硬切。

第二，检索命中率提升。表格里的数据如果用纯文本表示，“金额 100 万”和“合同编号 A-2025-01”混在一长串空格里，语义相似度计算会被稀释。Markdown 表格让单元格之间有了明确的边界，Embedding 模型更容易捕捉“这一行是表头，这一列是金额”的语义关系。

第三，生成质量提升。LLM 读 Markdown 上下文时，能理解表格的行列对应关系，回答“第三季度的营收是多少”这类问题时，比读一段拍平的纯文本要可靠得多。

还有一个容易被忽略的点：Markdown 也是当前大模型流式输出的“事实标准”。前端 SSE 流式渲染、Coze 这类编排平台里的 Word 导出工作流、各类 Markdown 编辑器，都默认支持 Markdown。把解析结果统一成 Markdown，等于让“文档输入”和“模型输出”在格式上对齐了，整个链路不再需要来回做格式转换。

4. 2.3B 参数的定位：小模型、专任务、企业级部署

2.3B 在今天的模型背景下是一个“小数字”。动辄几十 B、上百 B 的多模态模型并不少见，为什么 Cohere 要专门做一个 2.3B 的解析模型？

核心原因是：企业文档解析是一个高频、高并发、强隐私约束的场景，它需要的是“稳定、快速、可私有化”，而不是“什么都会一点”。

大模型做文档解析的问题不在于能力，而在于部署成本和延迟。一次解析要跑一遍大模型推理，吞吐量上不去，GPU 成本却直线上升。而 Parse 5 的 2.3B 规模意味着什么呢？

• 单卡即可部署。一张消费级显卡甚至优化后的 CPU 环境都有可能跑起来，这在企业内网环境里非常关键。
• 推理延迟低。解析一页文档的等待时间可以控制在秒级，适合批量处理海量历史文档。
• 私有化部署可行。数据不需要出企业内网，尤其适合金融、政企、医疗等对数据出域有严格限制的行业。
• 边际成本低。批量跑几百万页文档时，单页解析成本会比调用大模型低一个量级。

但也要清醒地看到小模型的边界。2.3B 的模型不会具备强大的语义推理能力，它无法处理“这份合同是否有法律漏洞”这种问题，也不适合做开放式的文档问答。它的任务边界就是“把页面还原成 Markdown”。这恰恰是工程上最想要的“小而专”的状态——模型越专注，行为越可预期，越好测试，越好替换。

从另一个角度看，这也代表了一种趋势：在大模型应用落地时，与其用一个什么都干的通用大模型，不如拆出若干个“单任务小模型”，每个模型只负责一个环节。解析交给 Parse 5 这样的专用模型，召回交给专门的 Embedding 和 Rerank 模型，生成交给通用 Chat 模型。这条“组合式架构”是企业级 AI 落地更务实的路径。

5. 典型场景与不适用场景

在决定要不要引入一个文档解析模型之前，先明确它适合做什么、不适合做什么。

从 Parse 5 的产品定位来看，典型适用场景包括：

• 扫描版 PDF 和纸质文档翻拍件，传统 OCR 容易出错的场景。
• 表格密集型文档，比如财务报表明细、销售数据表、物流清单。
• 版式复杂的报告，比如双栏论文、带页眉页脚的公司年报、各种保险条款。
• 合同和发票，需要把关键字段和条款结构完整还原到下游系统。
• PPT 和宣传物料，图片文字混杂，需要识别图像内文字并保留层级。

同时也要明确不适用场景：

这里要特别强调一个容易被忽略的问题：文档解析模型的输入方式。Parse 5 这类模型通常以页面图像为输入，所以在接入时需要考虑 PDF 的栅格化（把每一页转成图像）流程。如果原始 PDF 本身就是扫描件，那直接使用；如果是电子生成型 PDF，也可以先渲染成图像再交给模型。这一步对最终解析质量影响很大，建议在实际项目里分别做对比测试。

如果只看表面，很容易误以为“能看图的模型就能解析文档”。实际上，通用 VLM 虽然能看图，但输出格式不稳定、表格识别率不高、长文档容易丢信息。Parse 5 的价值在于它是一个专门为“文档结构还原”优化过的模型，输出的是干净、可校验的 Markdown，而不是一段随心所欲的自然语言描述。

6. 接入思路：从文档到 RAG 的完整链路

下面进入实操层面。由于 Parse 5 的具体 SDK 和接口细节以官方文档为准，这里重点演示一条通用的接入模式：解析服务调用 -> Markdown 存储 -> Markdown 感知切分 -> 向量化。

6.1 整体链路设计

一个典型的企业文档 RAG 链路如下：

原始文档(PDF/图片/PPT) | v 文档解析服务(Parse 5 或同类模型) | v Markdown 文件(保留标题、表格、列表结构) | v Markdown 感知切分(按标题层级分块) | v Embedding -> 向量库 -> 检索 -> LLM 生成

把解析服务抽象成一个接口，是后续替换和灰度发布的关键。不要一开始就和某个厂商的 SDK 深度耦合。

6.2 解析服务调用模式

先写一个通用的解析客户端抽象类：

# 文件路径：ingestion/parser_client.py # 说明：这是一个接入文档解析服务的通用抽象模式。 # 实际使用 Parse 5 时，请以官方 SDK 或 API 文档为准， # 这里重点演示“调用解析器 -> 拿到 Markdown -> 保存”这条主链路。 class DocumentParser: """文档解析器客户端抽象类。""" def __init__(self, endpoint: str, api_key: str): self.endpoint = endpoint self.api_key = api_key def parse(self, file_path: str) -> str: """ 解析单个文档，返回 Markdown 文本。 参数: file_path: 本地文件路径，如 ./contracts/2025_demo.pdf 返回: str: 文档解析后的 Markdown 内容 """ raise NotImplementedError("请接入 Parse 5 官方 SDK 的实现") # 使用示例：批量解析某个目录下的 PDF from pathlib import Path def batch_parse(input_dir: str, output_dir: str, parser: DocumentParser) -> list: input_path = Path(input_dir) output_path = Path(output_dir) output_path.mkdir(parents=True, exist_ok=True) results = [] for pdf_file in input_path.glob("*.pdf"): md_text = parser.parse(str(pdf_file)) md_file = output_path / f"{pdf_file.stem}.md" md_file.write_text(md_text, encoding="utf-8") results.append((pdf_file.name, md_file.name, len(md_text))) return results

在真实项目中，DocumentParser.parse里需要处理分页、超时重试、并发限制等细节。如果 Parse 5 支持本地权重部署，也可以直接写成加载模型推理的方式，接口保持一致即可。

6.3 Markdown 感知切分

拿到 Markdown 之后，不要急着按固定字符数切分。先按标题层级把文档切成“语义块”，再对超过阈值的块做二次切分。下面是一个简化的实现：

# 文件路径：ingestion/md_chunker.py # 按 Markdown 标题层级切分，避免把两个章节混在一个 chunk 里。 import re def chunk_markdown(md_text: str, max_chunk_size: int = 1500): lines = md_text.splitlines() chunks = [] current_chunk = [] for line in lines: is_heading = re.match(r"^#{1,6}\s+", line) if is_heading and current_chunk: # 遇到新标题且当前块非空，先把当前块落盘 chunk_text = "\n".join(current_chunk).strip() if chunk_text: chunks.append(chunk_text) current_chunk = [line] else: current_chunk.append(line) # 超长保护：接近阈值时按段截断，下一轮从剩余内容继续 current_size = sum(len(x) for x in current_chunk) if current_size >= max_chunk_size and not is_heading: chunk_text = "\n".join(current_chunk).strip() if chunk_text: chunks.append(chunk_text) current_chunk = [] if current_chunk: chunks.append("\n".join(current_chunk).strip()) return chunks

这个切分器的核心逻辑是“标题即边界”。生产环境里还需要考虑表格完整性：如果一个 Markdown 表格太长，应该整表保留或按行拆分，而不是从表格中间拦腰切断。另外，代码块和引用的边界处理也要单独设计。切分策略会直接决定检索质量，建议针对自己的语料做多组对比实验。

6.4 质量校验脚本

解析结果不能直接入库，需要先做一轮结构检查。这里给一个简单的校验脚本，统计标题数量、表格数量、代码块数量，并检查表格列数是否一致：

# 文件路径：evaluation/check_markdown.py # 校验解析输出的 Markdown 是否结构完整，用于批量质检。 import re from pathlib import Path def check_md_structure(md_text: str) -> dict: report = {} report["heading_count"] = len(re.findall(r"^#{1,6}\s+", md_text, re.MULTILINE)) report["table_count"] = len(re.findall(r"^\|.+\|$", md_text, re.MULTILINE)) report["fence_count"] = md_text.count("```") // 2 table_lines = re.findall(r"^\|.+\|$", md_text, re.MULTILINE) col_widths = set() for line in table_lines: if re.match(r"^\|[\s:\-|]+\|$", line): continue col_widths.add(line.count("|")) report["table_column_mismatch"] = len(col_widths) > 1 return report def main(folder: str): for md_file in Path(folder).glob("*.md"): text = md_file.read_text(encoding="utf-8") report = check_md_structure(text) print(f"{md_file.name}: {report}") if __name__ == "__main__": main("output_md")

运行方式：

python evaluation/check_markdown.py output_md

如果发现table_column_mismatch为 True，说明某个表格各行列数不一致，属于解析异常，需要标记出来人工复核。

另外可以用 Markdown lint 工具做语法检查：

npx markdownlint-cli output_md/*.md

也可以把 Markdown 转成 HTML 或 Word 做人工抽查：

pandoc output_md/sample.md -t html -o sample.html

这一步的主要目的是确保生成结果能被标准 Markdown 渲染器正常解析。如果连 Typora、VS Code 的 Markdown 插件都渲染异常，说明模型输出的语法层有问题，需要检查提示词或输入图像分辨率。

7. 效果验证与常见问题排查

评估一个文档解析模型，不能只看“感觉还不错”。建议从四个维度建立评测集：

• 结构还原率：标题层级是否正确，列表、引用、代码块是否保留。
• 表格正确率：行数列数是否一致，表头是否识别，单元格内容是否准确。
• 原文保真度：加粗、下划线、脚注等特殊格式是否丢失。
• 乱码率：识别出的文字中是否存在明显字符错误。

评测集建议选 100 到 300 个覆盖典型场景的真实文档，人工标注正确答案后，用脚本自动比对解析结果。每次更换模型版本或调整参数，都重新跑一遍评测集，用数字说话。

关于 Parse 5 的接入，比较容易踩坑的有这么几个问题：

排查顺序有一个原则：先看输入，再看输出。先确认原始文档图像有没有问题，再确认模型输出是不是稳定，最后才考虑业务链路的问题。很多时候问题不在模型，而在中间渲染这一步——PDF 转图像的 DPI、颜色空间、图像压缩率都会直接影响识别效果。

还有一点需要提醒：文档解析是典型的高置信度任务，但再强的模型也有失败样本。生产环境一定要保留原始文件路径和解析状态字段，方便失败后重跑，而不是把解析结果直接覆盖原文件。

8. 最佳实践与工程建议

基于企业文档解析的常见工程经验，整理几条建议。

8.1 保留原始文件，解析结果可重建

千万不要只存解析后的 Markdown，不保留原始 PDF。Markdown 只是“中间产物”，模型升级后随时可以重新解析出更好的结果。存储设计上建议：原始文件 -> 解析结果 -> 向量索引，三层分开放，每一层都能独立重建。

8.2 按文档类型做灰度切换

不要一次性把所有文档切到新解析方案上。可以按文档类型分桶，比如先切 20 页以内的标准合同，验证通过后再切扫描件，最后切复杂的双栏论文。每切一批，就对比旧方案和新方案的评测指标。这种灰度策略可以最大限度降低业务风险。

8.3 对解析结果做缓存

文档应该做内容哈希，相同的文档不要重复解析。哈希可以基于文件二进制，也可以基于页面图像。企业知识库经常出现同一个合同的多个版本重复上传，没有缓存会产生大量不必要的解析开销。

8.4 关注成本与性能权衡

2.3B 模型可以在单卡部署，但并不是说所有场景都必须本地化。如果只是偶尔处理少量文档，用 API 调用更省事；如果是几十万、上百万页的历史文档批量处理，私有化部署更划算。建议先做一个小样本的规模化测试，估算单页解析成本和吞吐量，再决定部署方式。

8.5 建立人工抽检机制

解析质量不可能 100% 正确，特别是表格和数字。在金融、医疗这类对准确性要求高的场景，建议在关键字段上增加规则校验或人工抽检流程。比如从 Markdown 里提取合同编号、金额、日期等字段，用正则做一致性校验，不通过则进入人工复核队列。

8.6 保持接入层抽象

像第 6 节演示的那样，把解析服务封装成统一接口。这样无论是替换解析服务商、升级模型版本，还是在不同部署方案之间切换，业务层都不需要改动。文档解析领域迭代非常快，保持接口稳定是降低长期维护成本的关键。

8.7 注意安全与合规边界

企业文档经常包含敏感信息，解析服务如果部署在外部，必须确认数据不会离开企业的合规边界。涉及权限、数据存储和删除策略时，遵循最小权限原则。测试时只用脱敏数据，生产环境在全量接入前做好安全评审和数据流审计。

9. 总结与后续学习方向

Parse 5 这件事给我们的核心启发是：大模型应用不是模型越大越好，而是“在正确的位置用正确规模的模型”。企业文档解析的高频、批量、隐私敏感特征，决定了它更适合一个小而专的视觉语言模型来完成。把复杂文档还原成 Markdown，既解决了传统 OCR 管道的脆弱性问题，又为 RAG 链路提供了结构干净、可切分、可校验的中间表示。

如果你正在做企业知识库相关项目，下一步可以分三步走：

第一步，先拿自己手上的 20 个真实文档跑通解析流程，把 PDF 转成 Markdown，用 Typora 或 VS Code 的 Markdown 预览肉眼检查一遍，看表格和标题还原到什么程度。这一步成本很低，但能帮你快速建立对视觉语言模型解析能力的直观认识。

第二步，建立一个小规模评测集，把解析结果和人工标注对齐，量化评估结构还原率和表格正确率。没有评测集，后面任何优化决策都是拍脑袋。

第三步，关注模型迭代和多模态技术进展。文档解析领域还在快速发展，Parse 5 只是其中一个代表，未来还会出现更强的版式理解、更精准的表格还原、更低的部署成本。保持接入层抽象，才能在技术升级时平稳过渡。

文档解析看起来是 RAG 链路里最不性感的一环，但它恰恰是最值得投入、回报最稳定的一环。把这件事做扎实，你的 RAG 应用才真正有了可靠的地基。建议收藏这篇文章，在搭建或改造文档处理管道时，把里面的验证方法和工程建议当作一份对照清单来用。