最近Cohere 发布了新一代文档解析模型 Parse 5parse-v5.0。它的定位很明确通过一个 2.3B 参数的视觉语言模型把企业文档直接转换为结构化 Markdown。如果只从名字看它像是升级版 OCR但从 RAG、文档问答和企业知识图谱的搭建链路来看它的核心价值不是“识别文字”而是把标题层级、表格列关系、列表嵌套、页眉页脚和扫描版式一并还原成可被下游系统消费的结构。企业在处理合同、年报、技术手册、验收报告和审批单时最怕的不是文档页数多而是版式复杂。扫描件里没有文字层图片中表格的边框被阴影覆盖多栏页面的阅读顺序经常被打乱。这些问题如果不解决文档解析阶段就已经把信息丢了后面的向量化、检索、摘要和问答都会在错误数据上工作。Parse 5 试图把“看清整页并输出 Markdown”这两件事放进同一个模型里让解析结果尽可能接近原始文档的信息结构。下面先从文档解析在 LLM 工作流中的位置讲起再说明 Parse 5 的模型机制然后给出一套最小可运行的调用流程、质量验证方法和排查路径。1. 文档解析为什么成为 LLM 应用的瓶颈1.1 解析结果直接决定 RAG 的检索上限RAGRetrieval-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 ModelVLM通常由三部分构成视觉编码器、连接模块和语言模型。视觉编码器把输入图片切分并编码成视觉特征连接模块把视觉特征映射到语言模型的输入空间语言模型根据视觉特征和任务指令逐 token 生成输出文本。文档解析场景里任务指令通常类似于“将这张图片中的文档转换为 Markdown 格式”。模型看到的不只是一行行文字而是整页的排版信息。它能够感知标题字号、表格边框、列表缩进、图片位置和阅读顺序。这就是它比纯 OCR 更适合企业文档的原因OCR 解决“是什么字”视觉语言模型同时解决“这句话在整个页面里处于什么位置、属于什么结构”。2.2 2.3B 参数规模意味着什么Parse 5 的参数规模是 2.3B。这个规模在视觉语言模型中属于中等偏小级别。对企业用户来说参数规模影响的主要是部署成本、推理速度和输出质量三者之间的平衡。更大的模型通常理解能力更强但显存占用高、单次推理时间长更小的模型速度快、成本低但复杂版式下出错更多。2.3B 模型如果直接部署在 GPU 推理服务中相比几十 B 甚至上百 B 的模型资源占用明显更低批量处理长文档时更划算。具体能支持多高的并发、单页推理需要多少毫秒必须结合实际部署环境和文档类型测量不能只看参数量。这里要特别提醒如果 Parse 5 是通过 API 方式使用的用户侧不需要关心模型部署细节但仍然需要关心批量调用时的 QPS 限制、超时时间和单次请求的文件大小。这些参数直接影响任务耗时和成本预算。2.3 输出格式为何锁定 MarkdownParse 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_KEYyour-api-key-here在 Windows PowerShell 中则使用$env:COHERE_API_KEYyour-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 转成 Markdown4.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, pagesizeA4) 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 Parse 5：用视觉语言模型将复杂文档解析为结构化Markdown
最近Cohere 发布了新一代文档解析模型 Parse 5parse-v5.0。它的定位很明确通过一个 2.3B 参数的视觉语言模型把企业文档直接转换为结构化 Markdown。如果只从名字看它像是升级版 OCR但从 RAG、文档问答和企业知识图谱的搭建链路来看它的核心价值不是“识别文字”而是把标题层级、表格列关系、列表嵌套、页眉页脚和扫描版式一并还原成可被下游系统消费的结构。企业在处理合同、年报、技术手册、验收报告和审批单时最怕的不是文档页数多而是版式复杂。扫描件里没有文字层图片中表格的边框被阴影覆盖多栏页面的阅读顺序经常被打乱。这些问题如果不解决文档解析阶段就已经把信息丢了后面的向量化、检索、摘要和问答都会在错误数据上工作。Parse 5 试图把“看清整页并输出 Markdown”这两件事放进同一个模型里让解析结果尽可能接近原始文档的信息结构。下面先从文档解析在 LLM 工作流中的位置讲起再说明 Parse 5 的模型机制然后给出一套最小可运行的调用流程、质量验证方法和排查路径。1. 文档解析为什么成为 LLM 应用的瓶颈1.1 解析结果直接决定 RAG 的检索上限RAGRetrieval-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 ModelVLM通常由三部分构成视觉编码器、连接模块和语言模型。视觉编码器把输入图片切分并编码成视觉特征连接模块把视觉特征映射到语言模型的输入空间语言模型根据视觉特征和任务指令逐 token 生成输出文本。文档解析场景里任务指令通常类似于“将这张图片中的文档转换为 Markdown 格式”。模型看到的不只是一行行文字而是整页的排版信息。它能够感知标题字号、表格边框、列表缩进、图片位置和阅读顺序。这就是它比纯 OCR 更适合企业文档的原因OCR 解决“是什么字”视觉语言模型同时解决“这句话在整个页面里处于什么位置、属于什么结构”。2.2 2.3B 参数规模意味着什么Parse 5 的参数规模是 2.3B。这个规模在视觉语言模型中属于中等偏小级别。对企业用户来说参数规模影响的主要是部署成本、推理速度和输出质量三者之间的平衡。更大的模型通常理解能力更强但显存占用高、单次推理时间长更小的模型速度快、成本低但复杂版式下出错更多。2.3B 模型如果直接部署在 GPU 推理服务中相比几十 B 甚至上百 B 的模型资源占用明显更低批量处理长文档时更划算。具体能支持多高的并发、单页推理需要多少毫秒必须结合实际部署环境和文档类型测量不能只看参数量。这里要特别提醒如果 Parse 5 是通过 API 方式使用的用户侧不需要关心模型部署细节但仍然需要关心批量调用时的 QPS 限制、超时时间和单次请求的文件大小。这些参数直接影响任务耗时和成本预算。2.3 输出格式为何锁定 MarkdownParse 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_KEYyour-api-key-here在 Windows PowerShell 中则使用$env:COHERE_API_KEYyour-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 转成 Markdown4.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, pagesizeA4) 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