合約條款提取：法律 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 攝取根據 PDF 是數位創建的（存在文字層）還是掃描的（需要 OCR）需要不同的處理。Word 文件應從 .docx 格式而非 PDF 匯出格式處理，因為 .docx 保留了有助於分段的標題結構和樣式資訊。

對於掃描的 PDF——在舊協議的交易存檔中很常見——必須先運行 OCR。合約文件上的 OCR 品質通常很高，因為合約使用高對比度的標準正文字體。主要的 OCR 失敗是：混合手寫和印刷的簽名頁、有圖章或標注覆蓋在文字上的文件，以及先傳真後掃描的文件（雙重退化）。

部分分段。 攝取後，合約文字被分割成部分。一個部分對應合約頂層結構的編號標題（1. 定義，2. 服務，3. 費用等）。部分通過標題格式識別——比正文文字更大或更粗的編號標題。

挑戰在於合約標題格式不標準。一些協議使用羅馬數字（I.、II.、III.），一些使用十進位編號（1.1、1.2），一些使用字母編號（A.、B.），一些只使用沒有數字前綴的文字。依賴單一編號格式的分段方法，將在格式不同的合約中遺漏部分。

一個穩健的分段方法結合格式檢測（從前 20 個部分識別此特定文件中使用的編號風格）和針對格式不尋常文件的後備基於模型的方法。

條款邊界檢測。 在一個部分內，必須分隔單個條款。合約中的「部分」可能包含一個句子或三十個句子。部分內條款之間的邊界對應主題事項的邏輯分割——從一個主題（許可人授予什麼）到另一個主題（被許可人不能做什麼）的過渡。

此級別的條款邊界檢測需要語義理解，而不僅僅是格式提示。在一個部分內，段落分隔是條款邊界的不可靠指標——一些條款跨越多個段落而不成為不同的條款，而一些不同的條款共享一個段落。

對於訓練資料準備，一個務實的方法：在簡單部分（少於 200 個詞）按部分級別分段，在複雜部分（使用十進位編號如 5.1、5.2）按子部分級別分段。這不是完美的條款分段，但它產生的片段足夠小，可以成為有意義的訓練單元，同時不需要語義條款邊界檢測的全部複雜性。

元資料標準化。 分段後，每個條款片段需要從文件中提取元資料：適用法律（通常在「適用法律」部分）、協議類型（通常在標題或引言中）、執行日期（通常在簽名欄中）以及當事人類型（供應商/客戶、僱主/員工等）。

這些欄位並不總是存在或格式一致。在條款級別標注開始之前，對每個文件執行元資料提取步驟，缺少關鍵元資料的文件被標記以供手動完成。

誰做標注

合約審查的標注任務是條款類型分類和風險評估。這是法律判斷任務，而非機械標記任務。

對於條款類型分類，有合約審查經驗的法務助理可以可靠地分類大多數條款類型：責任限制、賠償、保密、控制權變更、轉讓、爭議解決、終止、IP 所有權、保證以及其他標準條款。邊緣案例——結合多種條款類型元素的條款、不尋常的定制條款、司法管轄區特定的起草模式——需要助理律師級別的投入。

對於風險評估，分類的判斷強度更高。「這個責任限制條款是標準的還是非標準的？」需要了解律師事務所的標準立場、客戶的風險承受能力，以及條款與典型市場條款的比較。這需要助理或高級助理律師的投入，特別是在指南制定期間。

實際標注工作流程：助理律師設計標注架構並編寫指南。法務助理對大量文件應用標籤。助理律師審查樣本（10-15%）並處理升級的邊緣案例。合夥人在項目開始前和前 50 份合約後審查指南，以校準風險分類定義。

品質要求

標注者間一致性。 對於條款類型分類，Cohen's kappa 超過 0.75 是合理的目標。低於 0.70 表示指南模糊性，將產生嘈雜的訓練資料。對於風險分類，一致性自然會更低（0.60-0.70 是典型的），因為風險評估涉及判斷——但系統性的分歧（一些標注員始終對某些條款類型評為更高風險）表示應通過指南修訂解決的校準問題，而非在資料中平均掉。

標注指南的具體性。 標注指南必須包括：條款類型的完整清單、每種類型的一句話定義、每種類型的 2-3 個正面示例、1-2 個負面示例（常見的混淆項），以及可能適合多種類型的條款的決策規則。沒有這種具體性，標注者間一致性將很低。

邊緣案例處理。 指南必須規定如何處理：結合兩種類型的條款（用主要類型標記，標記為多類型）、太短而無法可靠分類的條款（最小長度閾值，標記以供審查），以及起草方式非常不尋常的條款（用最接近的類型標注，標記為不尋常）。

輸出格式

標注的條款資料以 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,000 小時的法律專業人員時間。按典型的法務助理費率，這是一個有意義但不過分的投資——而且它生產的訓練資料集，是任何出售通用法律 AI 的供應商無法複製的。

---

相關閱讀

• 律師事務所如何在不分享特權文件的情況下構建 AI 模型 — 特權保護和法律 AI 資料管道
• 領域專家被鎖在 AI 資料管道之外 — 為什麼標注工具必須為律師而非 ML 工程師設計
• 企業 AI 資料準備指南 — 完整企業資料準備管道概覽