最近，Cohere 发布了新一代文档解析模型 Parse 5（parse-v5.0）。它的定位很明确：通过一个 2.3B 参数的视觉语言模型，把企业文档直接转换为结构化 Markdown。如果只从名字看，它像是升级版 OCR；但从 RAG、文档问答和企业知识图谱的搭建链路来看，它的核心价值不是“识别文字”，而是把标题层级、表格列关系、列表嵌套、页眉页脚和扫描版式一并还原成可被下游系统消费的结构。
企业在处理合同、年报、技术手册、验收报告和审批单时，最怕的不是文档页数多，而是版式复杂。扫描件里没有文字层，图片中表格的边框被阴影覆盖，多栏页面的阅读顺序经常被打乱。这些问题如果不解决，文档解析阶段就已经把信息丢了，后面的向量化、检索、摘要和问答都会在错误数据上工作。Parse 5 试图把“看清整页并输出 Markdown”这两件事放进同一个模型里，让解析结果尽可能接近原始文档的信息结构。
下面先从文档解析在 LLM 工作流中的位置讲起，再说明 Parse 5 的模型机制，然后给出一套最小可运行的调用流程、质量验证方法和排查路径。
1. 文档解析为什么成为 LLM 应用的瓶颈
1.1 解析结果直接决定 RAG 的检索上限
RAG（Retrieval-Augmented Generation）是当前企业 LLM 应用最常见的落地方式。它的流程大致是：先对文档做解析，再把文本切成 chunk，转为向量，用户提问时先在向量库中检索相关片段，最后把片段交给 LLM 生成回答。
这里最容易被忽视的是第一步。很多人投入大量精力调提示词、换 embedding 模型，却忽略了解析结果的质量。如果解析输出的是乱序文本，即使 chunk 和向量做得再好，检索到的内容也可能缺少上下文。例如一份采购合同，正文“数量：200 套”和表头“设备清单”如果被拆成两段，回答时就很难把数量归属到对应的设备行。
Markdown 之所以成为文档解析的目标格式，是因为它在“信息完整”和“结构可计算”之间取得平衡。纯文本丢失标题和表格关系，JSON 适合程序消费但不适合人类阅读和后续生成，Markdown 则可以被渲染成 HTML，也能转成 Word 或 PDF，还能按标题和表格切分 chunk。这样解析结果既可以用于 RAG，也可以继续进入人工校对流程。
1.2 传统解析方案的失效场景
传统文档解析通常有两条路线。一条是规则和正则匹配，适合版式固定的表单；另一条是 OCR 加 PDF 文字提取库，例如 Tesseract、pdfplumber、PyMuPDF、Textract。这两条路线在常见文档里表现尚可，但面对企业真实文档会出现几个高频问题。
问题一：扫描件没有文字层。OCR 能识别文字，却不等于理解版面。页眉页脚、水印、批注会混进正文，多栏页面的阅读顺序可能被打乱。
问题二：表格结构易丢。PDF 提取库能拿到单元格文字，但合并单元格、跨行表头、嵌套列表很难还原成规范表格，输出往往是逐行文本，列与列的对应关系要人工才能读懂。
问题三：图片、公式和图表被忽略。视觉内容在企业文档中占比很高，但传统 OCR 通常不负责解释图片语义，公式更常被转成乱码或直接跳过。
| 方案 | 能识别文字 | 能识别版面 | 能还原表格 | 能输出 Markdown | 典型代价 |
|---|---|---|---|---|---|
| 正则规则 | 部分 | 否 | 否 | 否 | 只适合固定版式 |
| OCR | 是 | 弱 | 弱 | 否 | 文字顺序易错 |
| PDF 提取库 | 是 | 中 | 弱 | 部分 | 扫描件无法处理 |
| 视觉语言模型 | 是 | 是 | 是 | 是 | 需要模型或 API 成本 |
1.3 视觉语言模型带来的变化
Parse 5 这类模型把“视觉理解”和“结构化生成”合并成一个任务。输入是一页文档的图像内容，输出是一段 Markdown 文本。模型不只是识别某个字符，还要判断这段文字属于一级标题还是二级标题，某个单元格和哪个表头对齐，列表项嵌套了几层。
这对企业文档处理最直接的好处是：不再需要为了不同版式分别写解析规则。只要用一批样例验证输出质量，再针对不稳定文档做后处理，就能覆盖大多数场景。当然，视觉模型也不是银弹。它同样会把水印误识别为正文，也会把复杂合并单元格输出成简化表格。所以下文会说明如何在调用 Parse 5 时设置合理的参数，以及如何通过后处理和人工抽检控制质量。
2. Parse 5 的模型机制与 2.3B 参数定位
2.1 视觉语言模型如何“看懂”文档
视觉语言模型（Vision-Language Model，VLM）通常由三部分构成：视觉编码器、连接模块和语言模型。视觉编码器把输入图片切分并编码成视觉特征；连接模块把视觉特征映射到语言模型的输入空间；语言模型根据视觉特征和任务指令，逐 token 生成输出文本。
文档解析场景里，任务指令通常类似于“将这张图片中的文档转换为 Markdown 格式”。模型看到的不只是一行行文字，而是整页的排版信息。它能够感知标题字号、表格边框、列表缩进、图片位置和阅读顺序。这就是它比纯 OCR 更适合企业文档的原因：OCR 解决“是什么字”，视觉语言模型同时解决“这句话在整个页面里处于什么位置、属于什么结构”。
2.2 2.3B 参数规模意味着什么
Parse 5 的参数规模是 2.3B。这个规模在视觉语言模型中属于中等偏小级别。对企业用户来说，参数规模影响的主要是部署成本、推理速度和输出质量三者之间的平衡。
更大的模型通常理解能力更强，但显存占用高、单次推理时间长；更小的模型速度快、成本低，但复杂版式下出错更多。2.3B 模型如果直接部署在 GPU 推理服务中，相比几十 B 甚至上百 B 的模型，资源占用明显更低，批量处理长文档时更划算。具体能支持多高的并发、单页推理需要多少毫秒，必须结合实际部署环境和文档类型测量，不能只看参数量。
这里要特别提醒：如果 Parse 5 是通过 API 方式使用的，用户侧不需要关心模型部署细节，但仍然需要关心批量调用时的 QPS 限制、超时时间和单次请求的文件大小。这些参数直接影响任务耗时和成本预算。
2.3 输出格式为何锁定 Markdown
Parse 5 的最大特点不是“识别准确”，而是“输出类型固定为 Markdown”。Markdown 虽然不像 XML 那样严格，但它有一套约定的结构语法：#表示一级标题，|与---表示表格，-或1.表示列表，反引号包裹代码块，$表示行内公式。
这些语法不是给终端用户看的，而是给下游程序看的。当一个解析结果包含标题层级时，RAG chunk 就能按标题切分；当表格被还原成 Markdown 表格时，问答模型才能判断哪个表头对应哪个单元格。实际项目中，还可以用 Markdown 解析库把结果渲染成 HTML 后做进一步处理。这也是前端“SSE 流式输出 markdown 渲染器”能流行起来的原因：模型逐段生成 Markdown，前端边接收边渲染，用户不用等整篇文档解析完。
需要注意的是，模型输出的 Markdown 是否完全符合规范，取决于训练数据和解码策略。生产环境应该把“输出字符串”和“解析后的结构”分开看待，不要直接信任原始输出。
3. 调用 Parse 5 前的准备工作
3.1 获取账号、API Key 与文档版本
在调用之前，建议先确认三件事。
第一，Parse 5 的官方文档地址，以及当前最新版本是哪个模型 ID。不同版本的接口路径、字段名和模型名称可能不同。
第二，如何创建 API Key。绝大多数云端模型服务都要求请求头携带认证信息，通常格式为 Bearer Token。
第三，是否有试用额度。第一次测试不要直接上传大量生产文档，先用一两页样例跑通调用链路。
API Key 必须通过环境变量或密钥管理服务注入，不要写死在代码里，更不要提交到 Git 仓库。这里给出一个常见的环境变量设置方式：
export COHERE_API_KEY="your-api-key-here"在 Windows PowerShell 中则使用$env:COHERE_API_KEY="your-api-key-here"。设置完成后，可以通过一个简单的读取命令确认变量是否生效：
python -c "import os; print('KEY_IS_SET' if os.environ.get('COHERE_API_KEY') else 'KEY_MISSING')"注意：不要只验证请求能发出，还要验证密钥、文件读取、响应解析和错误分支是否都符合预期。
3.2 准备 Python 运行环境
示例代码使用 Python 3.10 作为基础环境。核心依赖只需要requests，如果使用官方 SDK，则按官方说明安装对应包。这里以通用 HTTP 调用方式演示，方便在不同语言和不同 SDK 版本间迁移。
创建一个虚拟环境并安装依赖：
python -m venv .venv source .venv/bin/activate pip install requests python-dotenv如果项目里使用了.env文件，需要注意它也应该被加入.gitignore。不推荐把密钥写在普通配置文件中。
3.3 确认输入文档的格式与大小限制
企业文档形态很多，常见的是 PDF、PNG、JPG、TIF。视觉语言模型的输入通常是图像，因此 PDF 需要按页转成图片后再送入模型，或者由服务端自动完成分页和图像化。
在开始批量调用前，建议先建立一张输入约束检查表：
| 检查项 | 常见建议 | 检查方式 |
|---|---|---|
| 文件格式 | 优先 PDF、PNG、JPG | 查看文件扩展名和 MIME |
| 单文件大小 | 按官方限制执行 | 使用ls -lh查看 |
| 页面数量 | 长文档建议分批 | 用 PyMuPDF 读取页数 |
| 清晰度 | 扫描件建议 300 DPI 以上 | 查看图片分辨率 |
| 敏感信息 | 脱敏后再上传 | 人工抽检或规则扫描 |
不要假设所有格式都支持。实际项目里常见问题是：上传了高分辨率 TIF 导致请求超时，或者上传了带密码的 PDF 导致解析报错。这些问题都应该在导入阶段提前拦截。
4. 最小可运行案例：把企业 PDF 转成 Markdown
4.1 准备一份包含表格和扫描内容的测试文档
为了验证 Parse 5 的效果，测试文档要具备三个要素：标题层级、表格、页眉页脚或水印。最简单的做法是生成一个含标题、表格、列表的 PDF，再通过打印预览导出为扫描版。
下面用 Python 的reportlab生成一个最简单的测试 PDF，方便本地复现：
from reportlab.lib.pagesizes import A4 from reportlab.pdfgen import canvas # 生成一个带标题、表格、页脚的测试 PDF c = canvas.Canvas("sample_invoice.pdf", pagesize=A4) width, height = A4 c.setFont("Helvetica-Bold", 18) c.drawString(50, height - 60, "Invoice Report") c.setFont("Helvetica", 12) c.drawString(50, height - 100, "Project: Enterprise AI Platform") c.drawString(50, height - 120, "Date: 2025-01-15") c.setFont("Helvetica-Bold", 12) c.drawString(50, height - 160, "Item Name") c.drawString(200, height - 160, "Quantity") c.drawString(300, height - 160, "Unit Price") items = [("Parse API", "5", "100.00"), ("Storage", "2", "50.00")] y = height - 180 for name, quantity, price in items: c.setFont("Helvetica", 12) c.drawString(50, y, name) c.drawString(200, y, quantity) c.drawString(300, y, price) y -= 20 c.setFont("Helvetica", 9) c.drawString(50, 30, "Page 1 / Confidential") c.save() print("sample_invoice.pdf created")这段代码生成的 PDF 文字可以直接提取，适合先验证基本调用流程。更接近真实企业的测试应该再使用扫描仪或图像截图，让文档没有可复制的文字层，这样模型才会真正依赖视觉理解能力。
4.2 使用 Python 发送解析请求
下面使用 HTTP 请求访问 Parse 5。注意，这里展示的是通用请求结构，实际 API 地址、请求字段和返回结构以官方最新文档为准。
import os import base64 import requests API_URL = "https://api.cohere.com/v2/parse" # 示例地址，以官方文档为准 API_KEY = os.environ.get("COHERE_API_KEY") FILE_PATH = "sample_invoice.pdf" if not API_KEY: raise RuntimeError("COHERE_API_KEY is not set") with open(F
