GitHub 项目观察 · 企业文档处理
企业做 AI 知识库，最容易被低估的一步，不是选哪个大模型，也不是向量数据库用哪家。
更早的一步是：那些 PDF、合同扫描件、报价单、财务报告、PPT、Word、Excel，能不能先被稳定地读出来。
很多 RAG 项目最后答得乱，不一定是模型不行，而是文档一开始就被切坏了。页眉页脚混进正文，表格被拉平成一坨文字，合同条款顺序错位，发票字段和备注混在一起，财报里的 XBRL 数据没有被当成结构化信息处理。
这就是 docling-project/docling 值得单独看的原因。
它不是一个聊天机器人，也不是完整知识库产品。它更像企业文档 Agent 的“入口层”：把复杂文档转换成 Markdown、JSON、HTML 等更适合下游 AI 系统使用的结构化内容。
一句话概括：Docling 解决的不是“让 AI 回答问题”，而是先把企业文档拆成 AI 能可靠检索、引用和处理的材料。
它真正解决的痛点
企业文档不是干净的纯文本。
一份采购合同里有目录、编号条款、签章页、附件表格；一份供应商报价单里有图片、表格、批注和页脚；一份年报里可能包含复杂表格、公式、图表和 XBRL；一份员工手册里有层级标题、制度正文、审批流程图。
如果只是用普通 PDF 文本抽取工具，最常见的问题有三个。
第一，阅读顺序会乱。两栏排版、页眉、脚注、侧边说明，可能被按页面坐标硬拼在一起。AI 后面看到的是“文字”，但不是人真正阅读的那份文档。
第二，表格会失真。采购、财务、销售、HR 的很多关键信息都在表格里：金额、税率、供应商、付款条件、岗位要求、薪酬档位、KPI。表格一旦被转成无结构文本，后面的问答和抽取都会变得不稳定。
第三，溯源会变难。企业不能只要一个“看起来合理”的答案，还要知道答案来自哪份文件、哪一段、哪张表。文档入口层如果没有保留结构和元数据，后面再补引用会很痛苦。
Docling 的定位正好卡在这里：它把 PDF、Word、PPT、HTML、图片等文档转换成统一的文档表示，再导出为 Markdown、JSON、HTML、纯文本等格式。官方 CLI 还支持 OCR、表格结构识别、图片导出模式、不同 PDF backend，以及面向 PDF/图片的 VLM pipeline。
换句话说，它不是替你做知识库，而是把知识库的原材料先处理干净。
适合哪些企业场景
第一个场景是合同和法务材料预处理。
法务或采购部门常见需求是：找出合同里的付款节点、违约条款、自动续约条款、验收条件、盖章主体和附件清单。这里不能只把合同全文塞进模型。更合理的做法是先用 Docling 把文档转成结构化 Markdown 或 JSON，再做条款分块、字段抽取、人工复核和知识库索引。
第二个场景是发票、报价单、采购单和供应商材料。
采购和财务最关心的是表格里的字段，而不是整份文件的“摘要”。Docling 的表格结构处理能力，适合放在发票识别、供应商比价、采购台账入库之前。它不能替代财务审核，但可以减少人工复制字段、整理附件、核对格式的时间。
第三个场景是财报和经营报告。
Docling README 里已经提到对 XBRL 文档的解析支持，这对财务报告、监管披露、上市公司年报这类场景很有意义。企业如果要做“经营分析问答”或“财务报告助手”，第一步不是让模型读 PDF，而是把报告里的章节、表格、指标和引用拆出来。
第四个场景是内部制度、员工手册和培训资料。
HR 做员工问答时，最怕制度被模型答错。制度文档通常有版本、章节、适用范围和例外条件。Docling 可以作为制度资料进入知识库前的转换层，后续再配合权限、版本号和人工审核，做成“员工制度问答”或“HR 服务台”。
第五个场景是企业历史资料归档。
很多公司有几十万份老 PDF、扫描件、PPT 和 Word。直接让业务部门上传到知识库，结果往往是检索质量参差不齐。更稳的路径是先做批处理：转换、抽检、去重、打标签、入库。Docling 适合在这个流水线里负责“转换和结构保真”。
怎么上手
官方 README 给出的安装方式很直接：
pip install docling
当前 README 提醒，Docling 2.70.0 之后不再支持 Python 3.9，需要使用 Python 3.10 或更高版本。
最简单的转换命令是：
docling myfile.pdf
如果你想同时导出 Markdown 和 JSON，并关闭 OCR，可以用官方文档里的写法：
docling myfile.pdf --to json --to md --no-ocr
批处理目录也在官方示例里：
docling ./input/dir --from pdf --from docx --to md --to json --output ./scratch
Python 里也可以直接调用：
from docling.document_converter import DocumentConverter
source = "https://arxiv.org/pdf/2408.09869"
converter = DocumentConverter()
result = converter.convert(source)
print(result.document.export_to_markdown())
企业试点时，不建议一上来就处理全量历史文档。更实际的做法是挑 50 到 100 份典型材料：合同、扫描件、表格型 PDF、PPT、制度 Word、财务报告各放一些，跑完后检查三件事。
一是表格有没有保住结构；二是标题层级和阅读顺序是否符合人读文档的顺序；三是导出的 Markdown 或 JSON 能不能被后面的 RAG、字段抽取或审核流程稳定消费。
如果这三件事过不了，后面换再大的模型也很难救。
它不该被当成什么
Docling 不应该被包装成“企业知识库全套方案”。
它不负责用户权限，不负责审批流，不负责知识库前台，也不保证模型回答一定正确。它解决的是文档进入 AI 管线前的基础清洗和结构化问题。
这反而是它的价值。
企业做 AI 落地，最怕跳过基础工程，直接做聊天界面。前台看起来能问，后台却是脏文档、乱切片、无版本、无引用。Docling 适合放在更早的位置：先把文档处理变成可重复、可检查、可接入流水线的步骤。
谁应该先试？
有大量 PDF、Word、PPT、扫描件，并且准备做合同问答、制度问答、采购资料入库、财报解析、RAG 知识库的团队，可以先试。
谁应该先等等？
如果公司只有少量干净 Markdown 或网页文档，或者主要需求是聊天 UI 和权限管理，Docling 本身不是第一优先级。你可能更需要 Dify、AnythingLLM、RAGFlow 这一类上层产品，再在文档质量不够时补 Docling。
真正的判断标准很简单：如果你的 AI 应用经常答错，是因为“没找到正确文档”或“引用段落乱了”，先看文档入口层。
Docling 解决的就是这个入口。
附录
Repo 资料卡
- Repo：
docling-project/docling - 地址：https://github.com/docling-project/docling
- 官方定位：Get your documents ready for gen AI
- 典型输出：Markdown、JSON、YAML、HTML、Text、DocTags、WebVTT
- 适合场景：合同解析、发票/采购单处理、财报结构化、制度文档入库、RAG 前处理
资料与来源
- GitHub README：https://github.com/docling-project/docling
- Docling v2 文档：https://docling-project.github.io/docling/v2/
- CLI reference：https://docling-project.github.io/docling/reference/cli/
- Quickstart：https://docling-project.github.io/docling/getting_started/quickstart/
- Docling 官网：https://www.docling.ai/
- 技术报告：https://arxiv.org/abs/2408.09869
