它解决什么问题
把几十种文档格式统一拆成带类型的结构化元素
拖动滑块完成拼图,通过后发送验证码
独立第三方 AI 评测平台 · 只用实测数据
把几十种文档格式统一拆成带类型的结构化元素
Unstructured · 解析库 / 托管 API
整理日期:2026-10-13 · 文档解析 · 同分类 7 个
上面几项是本条目的关键信息摘要,正文整理见下方「详细说明」与「关键信息」。
把几十种文档格式统一拆成带类型的结构化元素
把文档切成 Title、NarrativeText、Table 这类带类型的元素,并保留元素之间的父子关系与页码来源,切分和引用时可以按元素边界走;格式覆盖面广,同一套接口既能处理本地文件,也能直接对接官方托管服务。
默认走规则解析,版式复杂的 PDF 容易丢表格结构和阅读顺序,需要额外接高精度模型或第三方解析器;依赖链较重,不同格式的解析质量差距大,落地前必须按自己的文档类型抽样验证。
需要统一处理 PDF、Word、PPT、HTML、邮件等多种来源,并希望输出带类型元素方便切分的团队。
只处理单一格式的 PDF,或者对解析延迟和部署体积有硬约束的场景。
标签取自各项目公开信息里的分类字段,未做二次归类。
| 方案 | 形态 | 定位 | 许可证 |
|---|---|---|---|
| Docling | 解析库 / CLI | 把 PDF 与 Office 文档转成结构化 Markdown 与 JSON | MIT |
| Marker | 解析库 / CLI / 托管 API | 用视觉模型把 PDF 与扫描件转成 Markdown | Apache-2.0 |
| MinerU | 解析库 / CLI | 面向中文文档的 PDF 解析与 OCR 工具链 | LicenseRef-MinerU-Open-Source-License |
| LlamaParse | 托管 API | 把复杂 PDF 与 Office 文档解析成结构化文本的云服务 | — |
| PyMuPDF4LLM | 解析库 | 基于 PyMuPDF 的 PDF 转 Markdown 轻量封装 | AGPL-3.0 |
| olmOCR | 工具包 / CLI | 把 PDF 线性化成适合训练与检索的干净文本 | Apache-2.0 |
| MarkItDown | 转换库 / CLI | 把多种文件统一转成 Markdown 供大模型读取 | MIT |
同一分类内的方案才适合横向比较;定位列已按详情页原文截断
绝大多数情况是接进现有系统:网关统一多模型接入与配额,框架负责编排与工具调用,检索负责把内部资料接进上下文。只有训练、私有化部署与大规模推理才需要另起服务面,所以这几类条目归在同一栏,按上面的顺序看即可。
不是。网关解决「请求怎么送到模型」——统一协议、密钥、配额、路由与降级;Agent 框架解决「模型怎么组织成能干活的程序」——编排、工具调用、记忆与状态。
需要统一处理 PDF、Word、PPT、HTML、邮件等多种来源,并希望输出带类型元素方便切分的团队。
只处理单一格式的 PDF,或者对解析延迟和部署体积有硬约束的场景。
官方仓库标注的许可证是 Apache-2.0。另外要注意:默认走规则解析,版式复杂的 PDF 容易丢表格结构和阅读顺序,需要额外接高精度模型或第三方解析器;依赖链较重,不同格式的解析质量差距大,落地前必须按自己的文档类型抽样验证。许可证以仓库 LICENSE 原文为准,商用前请逐条核对。
它属于「文档解析」这一类,本页下方的对比表列出同分类的其他条目;跨分类的方案解决的问题不同,不适合直接比优劣。
页面文字只做中文整理,数值不改写;仓库地址、许可证与版本请以官方仓库为准,本站与所列项目无隶属关系。
条目信息取自各项目官方仓库与文档;定位、优势与注意事项为中文归纳,数值不改写,仓库地址、许可证与版本以官方为准。