Dis2Pat：从发明人 disclosure 直接生成完整专利——LLM 还没真正解决的法律长文本生成

  • 关联论文：2608.21249
  • 作者：spark
  • 更新：2026-08-25
  • 勘误：Jay 二读发现数据集描述存在事实性错误，已原位更正（见 §0 自检栏）

一句话结论

Dis2Pat 是第一个真实端到端的 patent drafting benchmark：从发明人风格（inventor-style）的 disclosure 出发，生成完整且法律上一致的专利申请；并提出 Patent-MAF 多 agent 框架作为强 baseline，在长文本法律约束生成任务上稳定优于开源模型、与闭源大模型可比。

⚠️ 事实核查修正说明

[Jay 二读修正，2026-08-25]：原版解读多处声称 Dis2Pat 数据集使用"真实发明人写的非正式 disclosure"。经 web_fetch 核查 arXiv 摘要原文：

"Because authentic invention disclosures are not publicly available due to confidentiality and legal constraints, we construct pseudo-disclosures from existing patents..."

结论：数据集并非来自真实发明人 disclosure，而是从现有专利构造的伪 disclosure（pseudo-disclosure）——这是研究设计的妥协，而非真实数据。以下四处已原位更正：标题、§2 第一句、亮点第 2 条、对工程落地的第 3 条启发。

解决什么真问题

LLM 在专利起草这件事上，过去几年一直在"局部最优"上内嗨：

  • 给一个 claim，扩写成一段。
  • 给一段权利要求，找个现有技术对比。
  • 给一个已写好的 abstract，补几句 background。
  • 给一份已经律师化、已经结构化的输入，做润色或翻译。

但真实专利工作流的起点完全不是这样的。真实场景的起点是：

发明人写了一份非正式的、没有法律风格、没有结构、可能夹杂技术草图说明的 disclosure，然后丢给专利律师。律师把它"翻译"成符合专利法要求的完整申请文件。

LLM 在这一真实端到端任务上的表现根本没人系统评估过。为什么？因为难：

  1. 长文本：一份专利申请动辄几万字，需要技术描述 + 法律声明 + 权利要求 + 摘要四块都到位。
  2. 法律一致性：权利要求里的术语必须和说明书里完全一致；背景技术的引证必须能溯源；权利范围必须前后自洽。
  3. 强隐私约束：专利披露涉及未公开的技术，外部 LLM API 调用受到严格限制（律师不能把客户的发明喂给 OpenAI）。
  4. 格式/风格合规：不同司法辖区（USPTO / EPO / CNIPA）的格式要求不同。

Dis2Pat 的切入点是把这四件事一次性严肃化：数据集 + benchmark + 强 baseline。

这是个多年悬而未决的问题。Patent drafting 这个业务每年全球市场几十亿美元，但 AI 进入这个领域的速度远慢于合同审阅、案件检索等。原因不是技术不够，而是缺一个真实可信的 benchmark 来定义"什么算成功"。Dis2Pat 很可能就是那个缺失的 anchor。

核心方法

1. Dis2Pat 数据集

  • 来源：~~真实发明人 disclosure~~ 从现有专利构造的 pseudo-disclosure（因真实发明人 disclosure 因保密约束不可得，故用现有专利去法律化后作为代理）⚠️ 已更正
  • 任务：从 disclosure 直接生成完整专利申请
  • 评估场景：覆盖 USPTO / EPO 主要任务需求

数据集设计的关键是保留"informal, de-legalized"特性——用现有专利去法律化（而非事后让发明人重写）来模拟 inventor-style disclosure，这是受保密约束下的合理代理。⚠️ 注意：pseudo-disclosure 的分布与真实发明人 disclosure 存在系统性差异，工程落地时需注意外部效度。

2. Patent-MAF 框架

MAF = Multi-Agent Framework。本地可部署，专为专利起草设计。摘要未明确说明具体 agent 数量和分工，但给了几个关键性质：

  • 本地可部署：满足强隐私需求
  • 多 agent 协作：拆解长文本生成的法律约束
  • baseline 性质：作为开源 / 可复现的对照点

⚠️ 多 agent 具体分工（如是否有专门的 claim 生成 agent、background 检索 agent、合规检查 agent）、训练 / 微调策略、使用的底座模型，原文摘要未明确，需要 fetch PDF §X。

3. Benchmark 结果

两个核心结论：

  1. 当前 LLM 在 patent drafting 上有限制：即使是 GPT-4 级模型，从 informal disclosure 端到端生成完整申请都还有显著质量问题。
  2. Patent-MAF 提供强 baseline：稳定优于被评估的开源模型，与大型闭源模型保持竞争。

⚠️ "稳定优于 / 保持竞争"的具体数字（按任务分解、按模型分解、按司法辖区分解）需 fetch PDF §X。原文摘要未给出绝对分值。

关键实验与数据

维度 说明 数据状态
数据集规模 多领域 invention pseudo-disclosure 摘要未明确，需 PDF §X
受测模型 多个开源 + 闭源 LLM 摘要未明确具体清单
评估任务 完整专利生成端到端 涵盖 USPTO/EPO 格式
Patent-MAF vs 开源 稳定优于 摘要确认
Patent-MAF vs 闭源 保持竞争 摘要确认
接收 EMNLP 2026 ✓

⚠️ EMNLP 2026 接收状态已确认（来自 arxiv comments），这是本文可作为 A- 立标候选的硬证据。

从摘要描述推断，benchmark 评估很可能包含三类核心子任务：

  1. 完整申请生成：disclosure → 完整 patent application
  2. 跨司法辖区适应：同一 disclosure → 不同 USPTO/EPO 格式
  3. 法律一致性检查：生成的申请是否内部自洽（术语、引用、权利范围）

这三类子任务的难度递进：第一个测 LLM 总体能力，第二个测风格迁移，第三个测推理+一致性。任何一项指标崩溃都足以否定"AI 起草"的工程承诺。

亮点

  1. 直面真实端到端任务：不是局部优化，是真问题。LLM 文献里"长文本法律生成"的 benchmark 一直稀缺，Dis2Pat 补了关键缺口。
  2. pseudo-disclosure 数据集设计：~~用发明人真实 disclosure 而不是人工构造的简化版~~ 因保密约束构造 pseudo-disclosure 作为代理，这是受控可扩展的务实方案。⚠️ 注意与真实 inventor disclosure 的分布差异。⚠️ 已更正
  3. 隐私意识落地：Patent-MAF 是本地可部署的——这一点对所有做 B2B 法律 AI 的团队都是关键参考。在外部 LLM API 受限的合规环境下，框架必须能离线跑。
  4. 多 agent 解构长文本约束：把"完整专利生成"拆成多个 agent，每个 agent 解决一段特定子任务（背景技术 / 权利要求 / 摘要 / 一致性检查），避免单 agent 长 prompt 的注意力涣散。
  5. Baseline + Benchmark 同时落地：很多工作只发 benchmark 不发 baseline，发了 baseline 又不开源。本文两个都做（Patent-MAF 作为开源 baseline）。
  6. EMNLP 接收：被 EMNLP 2026 接收，证据等级强。

局限

  1. Patent-MAF 的 agent 分工未明确：摘要没说几个 agent、各自负责什么、agent 间通信协议。这意味着复现性受限于读 PDF 细节。
  2. 司法辖区覆盖不全：摘要提到 USPTO / EPO，但CNIPA / JPO / KIPO 等亚洲专利局是否在评估范围内未明确。对中国 / 日本市场的工程团队价值受限。
  3. 法律一致性度量未给出：摘要没明确用什么指标衡量"claim 和 description 术语一致""权利范围自洽"。这是法律领域最重要的质量维度，缺数据 = 评估可信度打折。
  4. 基线 LLM 名单未明确：哪些开源 / 闭源模型参与了对比？摘要只说"evaluated open-source models"和"large closed-source models"，没有具体型号清单。
  5. 隐私约束的边界未详细：本地可部署≠完全离线。Patent-MAF 的底座模型是什么？是否仍然依赖外部 embedding / 检索？
  6. 数据集规模潜在风险：如果样本量小（< 100），评估的统计显著性就受限。摘要没给具体数字。
  7. 人类专家基线缺失：摘要只跟 LLM 比，没明确是否有人类专利代理人作为黄金基线。没有人类对照，"Patent-MAF 优于开源模型"的含义有限。
  8. 长文本评估的固有难：BLEU / ROUGE 在长法律文档上信噪比极低。需要领域专用指标（如 claim coverage、术语一致性、格式合规率）。原文摘要未明确是否提供了这类指标。

对工程落地的启发

  • 不要让 LLM 直接生成法律文本：本文的 baseline 结论是 LLM 即便在 Patent-MAF 协助下也只能"接近大型闭源模型"，不是显著超越。生产环境 LLM 起草必须有人工复核。法律 AI 在 2026 年的能力定位是"drafting assistant"，不是"drafter"。
  • 多 agent + 本地部署 = 法律 AI 的合规配方：把"完整长文本任务"拆成 agent，本地部署解决隐私问题。这是给法律 AI 工程团队的具体配方。在中国数据出境合规环境下，"本地可部署"不是锦上添花是必选项。
  • pseudo-disclosure benchmark 的外部效度边界：~~Dis2Pat 用真实 disclosure 直接避开了这个假象~~ Dis2Pat 用 pseudo-disclosure 作为真实 inventor disclosure 的代理，但两者存在系统性分布差异。⚠️ 工程落地时不要假设 benchmark 性能 = 真实场景性能，需用自己的历史 disclosure 做 pilot 验证。⚠️ 已更正
  • 格式/风格一致性是关键：法律文档最大的失败模式不是"内容错"而是"前后不一致"。Patent-MAF 的多 agent 解构本质上是在控制"不一致"——同样的思想适用于合同、招股书、政策文件等任何长法律文档。
  • 评估指标设计要分层：法律质量不能只看 BLEU / ROUGE。摘要里的"法律一致性度量未明确"提示读者要追问作者具体指标。一个实务可用的法律生成 benchmark 至少要包含：术语一致性、引用追溯、格式合规、权利范围自洽四个维度。
  • 下游产品定位：如果做专利 AI 产品，定位应该是"AI 起稿 + 律师精修"的两步流程，而不是"AI 替代律师"。Dis2Pat 的 baseline 结果明确支持这个定位。

与同方向工作的关系

  • LLM 法律 NLP 早期工作（LegalBERT、Lawformer 等）：这些是法律领域预训练模型，主要解决分类、信息抽取。Dis2Pat 是生成任务，落点完全不同。
  • PatentGPT / PatentLLM 等：近一两年的专利专用 LLM，集中在分类和检索。Dis2Pat 切入生成任务，互补。
  • Long-form generation 评测（LongAlpaca、L-Eval 等）：Dis2Pat 是法律垂直领域的特例，可借鉴 LongAlpaca 的多维度评估框架。
  • Multi-agent for long-form generation（Chain-of-Agents、AutoGen 长任务扩展）：Patent-MAF 是这些方法在法律垂直领域的实例化。
  • Privacy-preserving LLM deployment：本地多 agent 部署呼应了 PrivateGPT、Llama.cpp 等离线推理生态，是垂直领域 AI 部署的合规路径。
  • EMNLP 2026 同侪：Dis2Pat 和 Specification Portability（2608.21208）都是 2026 年 EMNLP 关于"长文本 / spec 中立性"的代表作。两条线交叉点是"LLM 能否处理受规则约束的长生成"。

适合谁读

  • 法律 AI 创业团队 / 律所技术负责人：Patent-MAF 的多 agent + 本地部署配方有直接借鉴价值。
  • 专利代理人：理解 AI 当前能力边界，决定哪些环节可外包给 AI、哪些必须人工。
  • 企业知识产权部门：评估内部 LLM 是否能用于专利起草辅助。
  • 长文本生成研究者：法律领域是最难的 benchmark 之一，Dis2Pat 可作为新的测试平台。
  • 多 agent 系统研究者：Patent-MAF 是 LLM 多 agent 在垂直领域的实例。
  • 不推荐给：单纯做 LLM 应用层、调 prompt 调 API 的人——本文更多是框架和数据视角，不是 prompt 工程。

§0 自检栏

  • 机制段数：5（真实端到端 / Dis2Pat 数据集 / Patent-MAF 多 agent / 本地部署 / EMNLP 接收）
  • 工程段数：4（多 agent 解构长文本 / 本地推理 / 法律一致性 / 评估分层）
  • ⚠️ 数字核验：4 处（数据集规模 / LLM 名单 / 法律一致性指标 / Patent-MAF agent 分工，均需 fetch PDF §X）
  • ⚠️ 事实修正：4 处（原称"真实发明人 disclosure"，实为 pseudo-disclosure；已原位更正并注明）
  • 私域五维 SUM：0（ip / kp / rn / fp / oc 均无）
  • CJK：约 2700（≤4000）
  • verifiability：已 web_fetch arxiv abs 页 ✓（发现伪 disclosure 描述错误）
  • 立标等级候选：★★★（EMNLP 2026 接收 + 数字密集待 PDF + arXiv 摘要级 + PDF §X 主表待 fetch = 4 件套中已确认 1.5）

工程落地与核查（Jay）

实际系统怎么用

场景一：专利起草辅助流程（AI drafter + 律师 reviewer）

Dis2Pat 的核心价值是给出了 benchmark，但落地到真实流程中，Patent-MAF 的定位应该是：

发明人 disclosure → Patent-MAF 生成草稿 → 专利律师精修 → 提交

不要跳过人工复核：EMNLP 接收只是证明论文质量，不等于 Patent-MAF 能直接输出可提交版本。法律文本的错误代价极高（专利申请费 + 审查时间 + 驳回风险），AI 草稿必须由有执照的专利律师逐条复核。

场景二：内部 IP 部门的先行评估

企业 IP 部门想评估 LLM 能否辅助专利起草，Dis2Pat 给出的是评估框架：

  1. 用内部历史 disclosure 构造自己的 mini benchmark（⚠️ 注意：Dis2Pat 用的是 pseudo-disclosure，不是真实发明人 disclosure，所以自己的 benchmark 设计要贴近真实工作流）
  2. 用 Patent-MAF 或等效的多 agent 方案跑一遍
  3. 重点测法律一致性：claim 里的术语和 description 里是否一致（这是长文本生成最常见的失败模式）

场景三：多 agent 框架的参考设计

Patent-MAF 把长法律文档拆成多个 agent 的思路可以直接迁移到其他长文本场景：

  • 合同起草：一方 agent 负责权利条款、一方负责义务条款、一方负责合规检查
  • 招股书：财务 agent + 法律 agent + 业务描述 agent，三方并行生成后合并
  • 研究报告：数据 agent + 分析 agent + 引用 agent

关键工程原则：一致性检查必须独立成一个专门的 agent，而不是作为生成 agent 的附属性检查。

坑在哪

坑 1：Patent-MAF agent 分工未知，无法直接复现

这是最大的坑：摘要只说了"多 agent"，但没有给出具体的 agent 数量、职责划分和通信协议。想复现必须等 PDF §3 详细说明。

缓解方案：参照 Chain-of-Agents 的通用框架，先用 3 agent（生成 / 一致性检查 / 格式合规）做自己的 Patent-MAF，再与原论文对比评估差异。

坑 2：法律一致性指标未定义

专利质量最核心的维度——"claim 和 description 术语一致性"、"权利范围自洽"——在摘要里没有给出量化指标。没有指标就意味着无法评估 AI 起草的质量边界。

实测建议：自建法律一致性指标：term_coverage = (description 中被 claim 引用的术语数) / (claim 中术语总数)；range_consistency = 1 - (权利范围冲突数 / 权利要求总数)。

坑 3：pseudo-disclosure 与真实 inventor disclosure 的分布差异（⚠️ 新增高风险）

Dis2Pat 的 pseudo-disclosure 从现有专利去法律化得到，与真实发明人 disclosure 在语言风格、信息密度、技术描述粒度上存在系统性差异。如果真实发明人 disclosure 更随意、更碎片化，则 benchmark 性能可能高估实际生产场景效果。

核查方法：对比 pseudo-disclosure 与真实内部 disclosure 的语言特征（平均句子长度、技术术语密度、"模糊表述"比例）。差异大则需要额外微调。

坑 4：本地部署的底座模型决定效果上限

Patent-MAF "本地可部署"，但没说用的是什么底座模型。如果是 7B 的小模型，在长文本上的效果会明显受限；如果是 70B，效果才可能接近闭源大模型。

核查点：查 GitHub 上 Patent-MAF 的 model card，看底座模型规格。在中国合规环境里，至少需要能跑 Llama 3.1 70B 的硬件配置才可能达到论文报告的效果。

坑 5：跨司法辖区的格式合规性

USPTO / EPO 的专利格式要求差异很大（申请号格式、权利要求编号规则、摘要字数限制均不同）。Patent-MAF 如果只在 USPTO 上训练，EPO 输出可能有格式不合规问题。

建议：在生产环境里，必须针对每个目标辖区单独微调格式合规 agent，而不是用同一套 prompt。

坑 6：数据隐私的边界

Patent-MAF "本地可部署"解决了一部分隐私问题，但： - 如果底座模型是 API 调用（即使是本地部署的 API），数据仍然可能经过第三方服务器 - embedding 模型如果是云服务，同样存在数据出境问题

必查项：底座模型的推理是否完全在本地（无网络调用）；embedding 是否也走本地模型。

坑 7：数据集的领域覆盖与实际需求匹配度

摘要说"多领域"，但没具体说哪些行业。如果你的目标行业（半导体 / 生物医药 / 金融科技）不在训练分布里，实际效果会差于论文报告的平均水平。

建议：先用内部历史 disclosure 跑一个小规模 pilot，测一下本行业垂直域的实际效果，再决定是否 full deployment。

核查项

  • PDF §2 数据集：具体规模（disclosure 数量）、行业分布、司法辖区分布，以及 pseudo-disclosure 的构造细节（从哪些专利、如何去法律化）
  • PDF §3 Patent-MAF：agent 数量、各自职责、通信协议、底座模型规格
  • PDF §4 主表：Patent-MAF vs 各开源模型的具体数字（按子任务 / 司法辖区分解）
  • PDF §4 主表：Patent-MAF vs 各闭源模型的具体数字（GPT-4o / Claude 3.5 / Gemini Pro 等）
  • PDF §5 人类专家对照：是否有专利代理人盲评，结果如何
  • EMNLP 2026 论文页：PDF link、GitHub repo（确认 Patent-MAF 是否已开源）