DocLang:AI时代文档标记语言,在单一格式中同时保留语义、结构、几何布局、治理元数据

2026年6月，LF AI & Data基金会成立DocLang规范工作组，IBM、NVIDIA、Red Hat、ABBYY、HumanSignal联合推动。这不是又一个文档转换工具——它试图重新定义”文档”这个概念本身。

一个被忽视了35年的技术债

PDF诞生于1991年，DOCX的前身可以追溯到1983年的Rich Text Format，HTML的表格标签在1997年就基本定型。

这些格式有一个共同的底层假设：读者是人。

PDF的核心是”渲染指令”——告诉显示设备在每个坐标放什么字形；DOCX的核心是”排版规则”——字号、段距、页边距；HTML的核心是”超文本呈现”——内容如何在浏览器窗口中布局。它们关心的都是”看起来像什么”，而不是”是什么意思”。

这导致了一个在企业AI团队中广泛存在但很少被正式讨论的问题：我们每天喂给大模型的企业知识，本质上是在让AI做”逆向工程”。

一份IBM年报PDF包含层级标题、交叉引用、财务表格、脚注、图表注释。人类读者可以瞬间理解”表3-2中的Q4营收数字对应的是亚太区合并口径”，但AI系统需要经历OCR→布局分析→表格提取→语义映射的多重转换，每一步都可能丢失信息或引入错误。

2026年6月9日，LF AI & Data基金会正式宣布成立DocLang Specification Working Group^[1]，试图从根上解决这个问题。

这不是一次渐进式改进，而是一次格式范式的切换——从”人类可读”到”AI原生”。

DocLang到底做了什么？

先看一句话定义：DocLang是一种面向AI系统的文档标记语言，目标是在单一格式中同时保留语义、结构、几何布局、治理元数据，并与LLM分词器实现1:1映射。

这句话里有四个关键词值得拆开看：

语义层（Semantic Layer）

传统文档格式中，”营收”这两个字和它在财务表中的位置关系是隐含的。你需要理解上下文才能判断这是”总营收”还是”分区域营收”，是”合并口径”还是”母公司口径”。

DocLang在格式层面就要求显式标注语义角色——一个数值不仅仅是文本节点，它是<tabular>元素中某个<cell>的内容，关联着特定的行标题、列标题和上下文语义体（semantic body）。

这意味着AI系统不再需要”猜测”一个数字的含义——含义已经编码在格式结构中。

几何层（Geometric Layer）

文档中的空间位置承载信息。页眉和正文的区别、脚注与正文的关联、表格中合并单元格的语义范围——这些都依赖几何信息。

DocLang同时保留了语义结构和几何坐标，让AI系统既能理解”这是一个三级标题”，也能知道”它出现在第3页左上角，下面是两个并排的表格”。

分词器对齐（Tokenizer Alignment）

这是DocLang与之前所有”文档→结构化数据”方案最本质的区别。

传统的Markdown、HTML、LaTeX转换方案，都是先把文档转成人类可读的文本格式，再由LLM的分词器（tokenizer）去”理解”这个文本。问题在于，这些格式中充斥着对AI无用的标记符号——HTML的<div class="section-header">、LaTeX的\begin{table}[htbp]——它们消耗token却不贡献语义，有些甚至误导模型。

DocLang的XML词汇表是专门针对LLM分词器设计的。规范中的每个标签都与分词器的token边界对齐，实现了”格式标记”与”模型输入”之间的1:1映射。没有冗余标记，没有歧义解析，同一个文档无论经过哪个工具处理，产出的token序列都是一致的。

治理元数据（Governance Metadata）

这是企业场景中最容易被忽视、但上线后最致命的问题。

DocLang允许在文档内部嵌入隐私标记、提取范围限制、模型训练权限等治理策略。这些信息不再散落在外部权限系统或合规文档中，而是与内容本身绑定。

当一份包含客户PII信息的合同被转换为DocLang格式时，”这部分内容不得用于模型训练”的约束是文档自身的属性，而不是外挂的策略规则。

基准测试说了什么？

ABBYY创建了DocLang Interactive Benchmark^[2]，用IBM 2025年年报作为测试文档，对比PDF和DocLang在输入大模型时的差异。结果如下：

数据来源：The Register报道^[3]，引用ABBYY基准测试

37%的token节省听起来不错，但更大的意义在于确定性的提升。PDF→LLM的转换链路中，不同OCR引擎、不同解析器对同一份文档的解读可能完全不同。一份合同今天用Adobe Acrobat解析和明天用开源工具解析，产出可能不一致。

DocLang要解决的是”文档理解的可复现性”问题——同一份文档，无论经过哪个合规的DocLang转换工具，产出的AI输入都是相同的。

ABBYY AI战略副总裁Maxime Vermeir对此的表述是：”DocLang为现代AI系统创造了一个更具确定性的基础。”

而成本维度上，ABBYY AI价值与赋能负责人Jon Knisley给出了更大的数字：”根据模型不同，客户可以预期4倍到30倍以上的成本降低。”

为什么是现在？

这个问题值得想清楚。

PDF不是不能用，企业用PDF跑了这么多年也没出大事。为什么2026年突然需要一个新标准？

三个力量的汇聚：

第一，Agent工作流的规模化。 当AI应用还停留在”问一个问题、得一个答案”的阶段时，文档解析的小误差可以通过后续prompt来弥补。但当企业开始部署自主Agent——一个Agent读取合同、提取条款、比对合规要求、生成审批意见——任何一个环节的文档理解错误都会在链条中放大。Agent对文档质量的敏感度远高于单次问答。

第二，多模型、多工具生态的碎片化。 企业不可能只用一个模型。GPT做文本生成、Claude做复杂推理、开源模型做敏感数据处理——每个模型的tokenizer不同，对同一份Markdown或HTML的解析方式也不同。没有统一格式，就没有跨模型的一致性。

第三，合规压力的升级。 欧盟AI法案已经生效，企业需要追踪”哪些文档内容被用于训练哪个模型”。当治理策略散落在外部系统中时，这种追踪几乎不可能做到精确。DocLang的内嵌治理元数据直接回应了这个需求。

DocLang + Docling：完整的文档AI技术栈

理解DocLang不能脱离Docling。

Docling^[4]是IBM苏黎世研究团队在2024年开源的文档处理工具包，目前也在LF AI & Data基金会下。它解决的是”文档摄取”问题——把PDF、Word、PPT、HTML、图片等各种格式转换成结构化表示。

如果说Docling是”从多种格式到结构化数据”的转换引擎，那DocLang就是”结构化数据应该长什么样”的标准规范。

两者的关系类似于：

• • Docling ≈ 浏览器（负责解析和渲染）
• • DocLang ≈ HTML（定义内容应该用什么格式表达）

这种组合创建了一个完整的开源文档AI技术栈：

原始文档（PDF/Word/PPT/图片）
    ↓  [Docling 摄取与解析]
DocLang格式（语义+结构+布局+治理）
    ↓  [标准化表示层]
LLM / VLM / Agent（消费结构化文档）

这意味着企业不再需要为每个文档类型编写定制解析器，不再需要为每个模型调整预处理流程。Docling负责”读懂”，DocLang负责”表达”，模型负责”理解”——三层解耦，各司其职。

企业数据团队的行动框架

对于企业数据团队来说，DocLang目前处于v0.6阶段（Apache 2.0协议），已经可以通过pip install doclang安装参考验证器。但距离生产级部署还有一些现实问题需要考虑。

以下是一个分阶段的行动框架：

第一阶段：评估与试点（1-2个月）

做什么：

• • 选取3-5个高频文档处理场景（如合同审查、财报分析、合规报告提取）
• • 用Docling将现有文档转换为DocLang格式
• • 对比现有Pipeline和DocLang Pipeline在token消耗、响应延迟、输出质量上的差异
• • 重点评估：对你们特有的文档类型（行业报表、内部模板、扫描件等），DocLang的语义标注是否足够

关键判断点： 如果你们的文档主要是结构化的（表格多、层级清晰），收益会非常明显。如果主要是非结构化的长文本（法律条文、技术手册），收益相对有限但确定性提升仍有价值。

第二阶段：Pipeline集成（2-4个月）

做什么：

• • 将DocLang集成到现有文档处理Pipeline中，作为Docling和下游模型之间的标准中间层
• • 建立文档→DocLang→模型的标准化流程，替代原有的”每个文档类型一个定制解析器”模式
• • 在DocLang格式中嵌入治理元数据，建立文档使用策略与内容本身的绑定关系
• • 对接A/B测试框架，持续对比新旧Pipeline的效果

架构建议： 不要把DocLang当作”替代现有格式”的方案，而是作为”AI消费层的标准中间表示”。原始文档仍然以PDF/Word形式存储（满足人类阅读和归档需求），DocLang格式作为AI Pipeline的输入层独立维护。

第三阶段：标准化与规模化（4-6个月）

做什么：

• • 将DocLang纳入企业数据治理框架，作为文档AI就绪度（AI-readiness）的评估标准之一
• • 建立跨团队的DocLang格式规范使用指南
• • 关注工作组后续版本更新（v0.6→v1.0），参与标准制定以影响规范演进方向
• • 评估DocLang在多Agent系统中的互操作性价值——当多个Agent需要共享同一份文档理解时，统一格式的价值倍增

冷思考：DocLang的挑战与边界

任何新标准在早期都需要冷静看待几个问题：

1. 生态成熟度。 目前原生支持DocLang的工具只有Docling和ABBYY FineReader Engine。微软的MarkItDown、开源社区的Marker等项目尚未宣布支持。在生态足够丰富之前，企业可能需要自建转换层。

2. 规范稳定性。 v0.6意味着规范仍在快速迭代中。GitHub仓库显示248次提交、最新的提交就在今天（6月16日），说明开发非常活跃，但也意味着API和格式细节可能变化。生产环境使用需要做好版本锁定和兼容性测试。

3. 迁移成本。 对于已经建立成熟文档处理Pipeline的企业，切换到DocLang意味着重新验证整个链路的输出质量。这不是”换个格式”那么简单，而是需要重新测试下游所有依赖文档理解结果的系统和模型。

4. 与既有标准的竞争。 DocLang不是唯一试图解决”文档→AI”问题的方案。LLaMA-Parse、Unstructured.io、LlamaIndex的文档连接器等都在提供类似能力。DocLang的差异化在于它是开放标准而非商业产品，但在实际采用中，”开放标准”的优势往往需要时间才能兑现。

5. “AI原生”的边界在哪？ DocLang解决的是”文档格式如何更好地服务AI”，但它不解决”AI如何更好地理解非结构化知识”的更深层问题。对于高度专业化、领域特定的文档（如医疗影像报告、工程图纸），DocLang的通用语义标注可能仍需要领域扩展。

写在最后

回到开头那个问题：为什么我们需要一个AI原生的文档格式？

因为格式不是中性的。格式决定了什么信息被保留、什么信息被丢弃、什么信息需要推断。PDF为人类阅读优化了35年，它在”看起来怎么样”这件事上做到了极致，但在”意味着什么”这件事上几乎是空白的。

DocLang的真正价值不在于又做了一个文档转换工具——市场上从来不缺这类工具。它的价值在于试图建立一个开放标准，让”文档的AI就绪表示”有一个统一的、厂商中立的、可互操作的定义。

就像HTML之于Web、Kubernetes之于云原生——真正的变革不来自更好的工具，而来自统一的标准。

对企业数据团队来说，现在不需要All-in DocLang，但需要开始关注这个方向。因为一旦标准确立，生态加速，先行者的Pipeline架构优势会变成显著的竞争壁垒。

文档格式的下一次范式转换，可能已经开始。

参考来源：

1. 1. LF AI & Data Foundation官方公告^[5]
2. 2. DocLang GitHub仓库^[6]
3. 3. Unite.AI: DocLang Aims to Become the Universal Language for AI-Ready Documents^[7]
4. 4. It’s FOSS: DOCX, PDFs Were Not Built for AI^[8]
5. 5. The Register: A modest proposal: Reformat everything to make documents more palatable to AI^[3]

引用链接

[1] DocLang Specification Working Group: https://lfaidata.foundation/press-release/2026/06/09/lf-ai-data-foundation-launches-doclang-specification-working-group-to-advance-an-open-standard-for-ai-native-documents/
[2] DocLang Interactive Benchmark: https://doclang-benchmark.abbyy.tech/
[3] The Register报道: https://worldnl.com/a-modest-proposal-reformat-everything-to-make-documents-more-palatable-to-ai-407316.html
[4] Docling: https://github.com/docling-project/docling
[5] LF AI & Data Foundation官方公告: https://www.kmworld.com/Articles/News/News/LF-AI–Data-Foundation-create-DocLang-Specification-Working-Group-to-formulate-an-open-standard-for-AI-native-documents-175215.aspx
[6] DocLang GitHub仓库: https://github.com/doclang-project/doclang
[7] Unite.AI: DocLang Aims to Become the Universal Language for AI-Ready Documents: https://www.unite.ai/doclang-aims-to-become-the-universal-language-for-ai-ready-documents/
[8] It’s FOSS: DOCX, PDFs Were Not Built for AI: https://itsfoss.com/news/doclang-new-open-document-standard-for-ai/