合同条款提取：法律AI数据准备指南

构建一个真正好用的合同AI，起点是一个数据问题。模型需要训练样本：一批合同，其中的特定条款已经被识别出来、归好类型、做过评估。在训练开始之前，你需要一条管道，把单个条款从原始合同文档里提取出来，整理成可以标注的形态。

本指南讲的就是这条管道：提取步骤、标注方法、由谁来打标签、质量要求、输出格式，以及训练一个可用的合同审查模型大概需要多大的数据集。

合同AI模型做什么

合同AI在条款层面运作，而不是文档层面。真正有用的任务包括条款分类（这一条属于什么类型的约定？）、义务提取（这一方需要做什么？）、不利条款识别（这条约定是否偏离标准条款，并因此带来风险？），以及比对（这一条和我们的标准立场差在哪里？）。

这些任务都要求模型在上下文中理解单个条款。只用完整合同文档训练、缺少条款级结构的模型，学到的是把合同文本和文档级标签关联起来。这对某些分类任务有用，但支撑不了条款级的工作。

能够支撑这些任务的训练数据结构是条款级的：每一条训练样本是一个条款（或者一组相关约定），并带上标明条款类型、风险分级和相关元数据的标签。

需要哪些训练数据

对条款分类模型来说，每条训练样本是一段文本，对应合同中的一个条款或一节，外加一个标明条款类型的标签。对风险分类模型来说，每条样本还要有一个风险标签（标准、非标准、需上报），用来表示这一条是否需要谈判。

如果是同时判定条款类型和风险的多标签模型：

{
  "text": "In no event shall either party's liability under this agreement exceed the total fees paid by Customer in the twelve-month period immediately preceding the claim.",
  "clause_type": "limitation_of_liability",
  "risk_level": "standard",
  "governing_law": "New York",
  "agreement_type": "enterprise_software",
  "mutual": true
}

元数据字段（适用法律、协议类型、该条款是否为双向）能让模型学到随情境变化的标准。一条在软件许可协议里属于标准写法的责任限制条款，放到专业服务协议里可能就成了非标准。缺了这层上下文，模型做不出这个区分。

提取管道

条款提取分四步：文档摄入、章节切分、条款边界检测、元数据标准化。

**文档摄入。**合同以 PDF（法院备案版、扫描原件、打印后再扫描的版本）和 Word 文档（草稿版、留痕版、清稿版）的形式进来。PDF 的处理方式取决于它是数字生成的（自带文本层）还是扫描来的（需要 OCR）。Word 文档应当直接从 .docx 格式处理，而不是先导出成 PDF，因为 .docx 保留了标题结构和样式信息，这些对切分很有帮助。

扫描版 PDF 在早期交易的档案里很常见，处理它们必须先跑一遍 OCR。合同文档的 OCR 质量通常不错，因为合同用的是对比度高的标准正文字体。失败主要集中在几类：手写与印刷混排的签署页、文字上叠加了印章或批注的文件，以及先传真再扫描的文件（两次退化叠加）。

**章节切分。**摄入之后，合同正文被切成一个个章节。一个章节对应协议顶层结构中的一个带编号标题（1. 定义、2. 服务、3. 费用等）。章节靠标题格式来识别：编号标题的字号或字重通常比正文更醒目。

麻烦在于合同的标题格式并不统一。有的协议用罗马数字（I.、II.、III.），有的用小数编号（1.1、1.2），有的用字母（A.、B.），还有的干脆只有文字、没有编号前缀。只认一种编号格式的切分方案，碰到排版不同的合同就会漏掉章节。

稳健的做法是把格式识别和一个兜底的模型方案结合起来：前者从文档最前面的 20 个章节判断这一份具体用的是哪种编号风格，后者用来处理排版异常的文件。

**条款边界检测。**在章节内部，还要把单个条款分开。合同里的一个「章节」可能只有一句话，也可能有三十句。章节内条款之间的边界对应主题上的逻辑断点：从一个话题（许可方授予什么）转到另一个话题（被许可方不得做什么）。

这一层的边界检测需要语义理解，格式线索本身不够用。在章节内部，段落分隔并不能可靠地指示条款边界：有些约定跨了好几段，却仍然是同一条；有些各自独立的条款，又挤在同一段里。

准备训练数据时可以务实一些：简单章节（不到 200 词）按章节整体切，复杂章节按小节切（用 5.1、5.2 这样的小数编号）。这是对条款切分的一种近似，它切出的片段足够小，能成为有意义的训练单元，同时省掉了语义级边界检测的全部复杂度。

**元数据标准化。**切分完成后，每个条款片段都需要从文档里提取的元数据：适用法律（一般在「适用法律」一节）、协议类型（常见于标题或鉴于条款）、签署日期（常见于签署栏）、当事方类型（供应商／客户、雇主／雇员等）。

这些字段未必都存在，格式也未必一致。元数据提取要在条款级标注开始之前对每份文档跑一遍，关键元数据缺失的文档会被标出来，交给人工补齐。

谁来做标注

合同审查的标注任务是条款类型分类和风险评估。这是一项法律判断工作，而非机械的贴标签工作。

条款类型分类方面，有合同审查经验的律师助理可以可靠地判定大部分条款类型：责任限制、赔偿、保密、控制权变更、转让、争议解决、终止、知识产权归属、保证，以及其他标准约定。边缘情况需要助理律师层面的介入：糅合了多种条款类型要素的约定、罕见的定制条款、带有特定法域起草习惯的写法。

风险评估方面，判断的分量更重。「这条责任限制条款算标准还是非标准？」要回答它，得知道律所的标准立场是什么、客户的风险偏好在哪里，以及这一条和市场上的常见条款相比如何。这需要助理律师或高级助理律师参与，制定指南的阶段尤其如此。

实操中的标注流程是这样的：助理律师设计标注框架并撰写指南；律师助理完成绝大部分文档的打标；助理律师抽查其中 10-15%，并处理上报上来的边缘情况；合伙人在项目启动前审阅指南，并在头 50 份合同完成后再审一次，用来校准风险分级的定义。

质量要求

**标注者间一致性。**条款类型分类可以把 Cohen's kappa 高于 0.75 当作合理目标。低于 0.70 说明指南存在歧义，会产出噪声很大的训练数据。风险分类的一致性天然会更低（0.60-0.70 是常见水平），因为风险评估本身涉及判断。不过，系统性的分歧（某些标注者一贯把特定类型的条款评为更高风险）说明存在校准问题，应当通过修订指南来解决，而不是在数据里被平均掉。

**标注指南的细致程度。**标注指南必须包含：完整的条款类型清单、每一类的一句话定义、每一类两到三个正例、一到两个反例（常见的易混项），以及一条款可能同时符合多个类型时的判定规则。缺了这种细致程度，标注者间一致性会很低。

**边缘情况的处理。**指南必须写明这几种情况怎么处理：兼具两种类型的条款（按主要类型打标，并标记为多类型）、短到无法可靠分类的条款（设最小长度阈值，标记待审）、起草方式非常特殊的条款（按最接近的类型标注，并标记为异常）。

输出格式

标注好的条款数据以 JSONL 导出，用于微调：

{"text": "...", "clause_type": "limitation_of_liability", "risk_level": "standard", "governing_law": "Delaware", "agreement_type": "enterprise_software", "mutual": true, "word_count": 52}
{"text": "...", "clause_type": "indemnification", "risk_level": "escalate", "governing_law": "California", "agreement_type": "professional_services", "mutual": false, "word_count": 241}

训练集应当做分层：各条款类型的占比大致相当（或者按该类型在真实审查工作中出现的频率加权），并且刻意采样一批风险需上报的样本，这类样本在实务中很少见，却正是模型必须学会的。

可用模型所需的数据集规模

覆盖 15 种最常见条款类型的条款分类模型：

• 最小可行：200 份标注合同，各类型合计约 4,000-8,000 个条款样本
• 够用：350 份标注合同，8,000-15,000 个条款样本，类型分布良好
• 扎实：500 份以上标注合同，15,000-25,000 个条款样本，并在协议类型和适用法律上带有元数据的多样性

风险分类模型的数据量要求相近，但稀有类别的问题更突出。在真实档案里，需上报的高风险条款可能只占全部条款的 5-10%。标注时刻意过采样高风险条款（把已知含有异常约定的文档批次分派给标注者）有助于缓解这种不均衡。

一个 350 份合同的标注项目，按每份合同 2-3 小时（含质量复核）计算，大约需要 700-1,050 小时的法律专业人员工时。按常见的律师助理费率算，这笔投入不小，但也谈不上难以承受，而且它产出的训练数据集，是任何售卖通用法律AI的供应商都复制不了的。

延伸阅读

• 律所如何在不共享特权文件的情况下构建AI模型：特权保护与法律AI数据管道
• 领域专家被挡在AI数据管道之外：标注工具要让律师用得上，不只是给ML工程师用
• 企业AI数据准备指南：企业数据准备管道的全流程概览