简介面向法律科技从业者、NLP算法工程师及法律文档处理研究者的DeepSeek法律文档智能摘要与要点快速提取方案系统覆盖从法律文本解析、术语图谱构建到保留法律效力的精简文书生成全流程适合作为技术方案设计与工程落地的参考。资源为单个PDF文件大小12.47MB共446页、50个大章节文档内目录、书签大纲和章节跳转均可正常使用文字与图表显示完整。目前已有141人学习下载。前18章详细展开法律文档处理痛点与技术栈全景、多层级语义分割、法律实体关系事件抽取、法律效力要素标注体系、小样本标注、数据增强、模型初始化、数据划分、混合损失函数、超参数调优、训练过程监控及多GPU分布式训练等内容后续章节继续覆盖微调数据准备、微调策略选择等实践环节。整份资料条理清晰既可作为系统学习讲义也可按目录快速定位到特定技术模块方便对照自身项目选用。1. 法律摘要不是“摘要”而是“效力保全”为什么抽象式生成值得做一份 446 页的法律文书人工通读至少需要两天但用 DeepSeek 这类大模型做智能摘要十分钟就能拿到一个“能看懂”的精简版。问题在于这个精简版敢不敢拿去给领导签字、给外部律师复核法律摘要翻车的代价不是文字不够流畅而是义务主体换位、法条编号漂移、“应当”变成“可以”这类效力损伤。标题里这个方案的核心是把抽象式文本生成用在最需要结构约束的场景——先拆 PDF再逐条摘要最后层级合并并在每一层都想办法保住条款效力。适合正在做法律文档智能化、合规审阅和长 PDF 信息压缩的工程与产品团队。2. DeepSeek 抽象式摘要的核心选型抽取式、生成式与法律效力的三角权衡2.1 为什么抽取式摘要在法律长文档上行不通做法律文档摘要很多团队第一反应是拿 TextRank 或 BERT 系列模型做抽取式摘要从原文里挑得分高的句子按顺序拼成一段。这个思路在新闻、论文场景问题不大但到了法律文书上基本走不通。原因是法律文本的“要点”很少落在单个句子上一个完整的义务链通常是“主体—行为—期限—后果—依据”跨多个条款出现。抽取式只能摘句子摘不出这条链路。举一个实际例子一份供货合同里第三条约定交货时间第二十二条约定逾期违约金第四十八条约定不可抗力免责。三个句子各自单独看都是有效信息但抽出来拼在一起读者无法建立“逾期交货触发违约金”这个因果关联。人工写摘要时会把这三条合并成一句“乙方逾期交货的应按第二十二条向甲方支付违约金。”这正是抽取式方法的死穴它做的是字符级压缩不是语义级压缩。抽取式的另一个问题是压缩率太低。我见过一些抽了 60 多句话的精简版篇幅只剩原来的三分之一不到就号称“摘要”但读起来和目录没什么区别。法律文书要求摘要具备可转述性——可以直接拿给决策层或外部律师读而不是让人再去翻原文确认逻辑。这个诉求决定了单靠句子拼接不现实。可以看下面的对比理解为什么抽象式生成在“用户感受”上明显占优但风险也同步升高维度抽取式抽象式DeepSeek字面忠实度高逐字摘录中高受 Prompt 约束压缩率低通常只能压缩 50% 左右高可压缩至 10% 左右跨条款逻辑合并基本做不到能做但有幻觉风险法条号与主体一致性不易出错需要程序化校验落地成本低本地模型即可需要 API 调用与校验管线可见抽象式生成不是“更高级的抽取”而是换了一条技术路线。它用模型的语言组织能力替代句子拼接代价是模型的“自由发挥”在法律场景里是危险的。所以选型结论不是“用抽象式替代抽取式”而是“用抽象式生成 强约束 校验”三个环节缺一个都不要上线。2.2 抽象式生成的落地前提分块、层级与检索三件套把抽象式生成直接用于法律摘要最常见也最致命的错误是整篇 446 页一次性喂给模型。且不论 token 成本和上下文窗口是否够用模型对超长输入的注意力分布会严重衰减开头和结尾的内容记得住中部大量条款直接被忽略生成的摘要可能只覆盖前 20 页和最后 10 页的内容。解决这个问题没有捷径必须“分治”把长文档拆成可处理的语义块逐块生成摘要再按章节层级逐步合并。完整的方案流水线在我这边是四段式PDF 解析与章节树构建先提取文档结构和目录层级明确哪些内容属于同一章、同一节、同一条。按条、款、项分块法律文本的天然语义边界就是“条”。一个分块的基本单位是一条或一组容量接近的条避免把完整法条切成两半。层级摘要先对每个分块做块级摘要再对章做章级摘要最后把所有章级摘要合并成全文精简版。效力校验法条号一致性比对、规范力度词检查、要素召回率计算以及人工抽检。这个链路里的“检索”指的是跨层级的指代还原。比如块级摘要里出现“上述约定”合并到章级时必须知道“上述”指哪个条款否则最终精简版里都是悬浮的指代词。常见做法是在块级摘要时强制模型把指代词展开成具体条款对象而不是把问题留给下一层。分块和层级听起来是朴素的工程手段但正是这套“笨办法”把抽象式生成的幻觉风险压到了可控范围。模型每次只需要处理一两个条的内容出错范围小回溯定位也方便——哪一条摘要不对直接重跑那一条而不是整篇重新生成。2.3 DeepSeek 的上下文与成本考量446 页 PDF 的拆解思路按照每页 800 字左右估算446 页 PDF 对应 35 万字符以上折算成 token 接近 9 万到 12 万。这个体量即使塞进当前主流大模型的上下文窗口单次调用的成本也高得离谱而且生成质量必然下滑。分层摘要方案的核心收益不只是在质量上也在成本上块级摘要阶段每次只消耗几百到一千 token章级合并阶段每次消耗几千 token总成本远低于一次性处理全文。DeepSeek 的 API 调用方式和 OpenAI 兼容用已有的 chat.completions 接口就能接。对多数团队来说这意味着后端改造成本很低——不需要自己部署推理服务也不需要换一套 SDK。如果确实有数据合规要求也可以考虑本地部署 DeepSeek 的开源权重但那是另一个话题做方案验证阶段直接走 API 是最快的路径。这里的关键参数不是模型本身而是分块大小和温度系数。分块太大单次摘要容易丢细节分块太小产生的摘要块数量太多后续合并时上下文碎片化。我一般把单块容量控制在 800 到 1500 字符之间温度调到 0.1 以下让模型的输出尽量保守。温度这个参数是法律摘要场景里最容易被忽略的默认温度下模型会“发挥”得更好但法律文本不需要发挥。3. 从 446 页 PDF 到结构化文本法律文书的层级解析与分块策略3.1 先用 PDF 结构做分治提取目录和标题层级拿到一份 446 页的 PDF第一步不是直接丢给模型而是先用工具把 PDF 转成带层级结构的文本。法律文书大多是排版规范的 Word 或 LaTeX 导出物标题字号和正文字号有明确区分。用 PyMuPDF 可以提取每个文本块的字体大小再根据字号差异推断标题层级。import fitz # PyMuPDF def extract_heading_structure(pdf_path, body_size_threshold12.0): 提取 PDF 中的标题层级。 思路正文通常为 10.5pt 或 12pt 左右明显大于正文字号的文本块视为标题。 返回按页码排序的 (level, text) 列表。 doc fitz.open(pdf_path) headings [] for page_idx, page in enumerate(doc): d page.get_text(dict) for block in d[blocks]: if lines not in block: continue for line in block[lines]: for span in line[spans]: size span[size] text span[text].strip() if not text: continue if size body_size_threshold * 1.3: # 字号明显大于正文视为标题 level 1 if size body_size_threshold * 1.6 else 2 headings.append({page: page_idx 1, level: level, text: text}) doc.close() return headings这段代码的核心判断依据是“字号倍差”。法律文书的章标题通常比正文大 1.6 倍以上节标题大约在 1.3 倍左右。body_size_threshold需要按文档实际排版调节——如果正文是 12pt章标题可能是 16pt 或 18pt如果正文是 10.5pt阈值就相应下调。注意 PDF 里“字号”不是绝对的物理尺寸而是嵌入字体定义的规范字高直接比较span[size]数值即可不必换算成毫米或磅值。另一个常见做法是检查 PDF 目录书签。PyMuPDF 的doc.get_toc()能直接拿到书签目录比字体推断准确得多。但很多扫描版或印刷厂导出的 PDF 目录书签为空所以字体推断是必要兜底。实际落地时我会两种方式都跑一遍优先用get_toc()的结果再用字体推断补漏。3.2 基于条、款、项的三级分块规则拿到标题结构后真正决定摘要质量的是分块策略。法律文本的最小语义单位是“条”一条通常能独立表达一个完整规则。分块的第一原则是以“条”为边界绝不把一条切成两半。import re def split_by_article(text): 按“第X条”边界切分文本。 返回 list[dict]每个 dict 包含 article 编号与正文。 兼容“第一条”到“第九十九条”、“第一百一十二条”等编号形态。 # 匹配中文数字条号第[一二三四五六七八九十百零]条 pattern re.compile(r第[一二三四五六七八九十百零]条) matches list(pattern.finditer(text)) if not matches: # 没有条文标记的文档退化为整段为一个块 return [{article: 未编号, text: text.strip()}] blocks [] for i, m in enumerate(matches): start m.start() end matches[i 1].start() if i 1 len(matches) else len(text) article_no m.group() content text[start:end].strip() blocks.append({article: article_no, text: content}) return blocks这个切分逻辑假设条文是连续排列的。实际法律文书里还有“第X章”和“附件”需要先用上一节的标题结构把章节标题过滤掉再对章下面的正文做条文切分。如果文档里既有“第X条”又有“第X.X条”某些合同用 3.1、3.2 的编号体系正则要改成同时匹配两类编号r第[一二三四五六七八九十百零]条|\d\.\d。分块之后还有一个关键参数单块上限。一条法规或合同条款可能极长比如一条包含五款、每款还有两项的文本可能超过 2000 字。对这种长条应该按“款”再切一层——检测“第X款”或“X.”标识把一条拆成几个子块。我的经验值是单块超过 1500 字就必须拆低于 600 字可以跟相邻条文合并适用于枚举型短条。3.3 块级摘要与层级合并的 Python 实现分块完成之后摘要管线就清晰了先对每个条文块调用 DeepSeek 生成块级摘要再把同一章下的块级摘要拼起来做章级摘要最后把各章摘要拼起来生成全文精简版。每一层的 Prompt 相同只有输入文本的长度不同。import json import os from openai import OpenAI client OpenAI( api_keyos.environ.get(DEEPSEEK_API_KEY), base_urlhttps://api.deepseek.com ) LAW_SUMMARY_SYSTEM_PROMPT 你是一名法律文档精简专家。你的任务是对输入的原始法律文本生成摘要。 必须遵守以下约束 1. 保留所有具有法律效力的信息主体名称、合同编号、金额、期限、义务行为、法律后果。 2. 不得改写约束强度关键词。“应当”“可以”“不得”“必须”“有权”必须按原文保留。 3. 不得省略法条引用编号不得修改“第X条/第X款/第X项”的编号。 4. 如果原文存在指代词如“上述约定、前款、该协议”在摘要中展开为具体对象。 5. 不得添加任何原文不存在的推论、建议或价值判断。 6. 如对某些信息不确定单独输出到 uncertain 字段不要写进摘要正文。 输出 JSON 格式{summary: 摘要正文, uncertain: [不确定信息1, 不确定信息2]} .strip() def summarize_block(block_text, max_tokens800): 对单个条文块生成摘要。 resp client.chat.completions.create( modeldeepseek-chat, temperature0.1, max_tokensmax_tokens, response_format{type: json_object}, messages[ {role: system, content: LAW_SUMMARY_SYSTEM_PROMPT}, {role: user, content: f原文如下\n{block_text}} ] ) content resp.choices[0].message.content return json.loads(content)参数说明temperature0.1是为了让模型输出尽量确定减少同义改写带来的效力漂移response_format{type: json_object}是 DeepSeek 对 JSON 输出模式的支持保证summary和uncertain能被程序稳定解析。max_tokens按输入长度调整——块级摘要通常 800 够用章级摘要可以放宽到 2000。调用链路的另一个细节是需要增加失败重试。长文档批量处理时偶发网络错误或服务端 429限流很正常不要在单次调用上纠结。重试策略用指数退避第一次失败等 2 秒第二次等 4 秒最多重试 5 次。批量任务建议控制在每并发 5 个请求以内避免触发限流后整批任务中断。4. 抽象式生成的精度控制Prompt 工程与法律效力约束4.1 法律摘要 Prompt 的五个强制约束抽象式生成最让人不放心的地方是“自由发挥”。模型的预训练目标决定了它天然倾向于把输入改写得更通顺、更简洁但法律文本的效力恰恰隐藏在那些让句子变得“不通顺”的限定词里。我在多轮迭代后把 Prompt 约束收敛成五个必须项缺一不可。约束一保留义务性、授权性、禁止性关键词。法律文本里的“应当、可以、不得、有权、必须”不是同义词而是决定条文性质强制性规范还是任意性规范的模态词。模型在压缩转述时极其容易把这些词替换成近义表达比如把“应当”改成“需要”把“不得”改成“不能”。前者是规范强度变化后者是语气变化都是不可接受的。约束二法条引用编号只能原样复制。法律文书内部会大量引用“根据《中华人民共和国民法典》第七百零三条”“本合同第二十二条约定”等内容。模型生成摘要时如果重新组织语言非常容易出现编号漂移——把“第二十二条”写成“第二十一条”或者把案号中的年份改掉。这不是模型“笨”而是编号在预训练语料里出现频率高模型倾向于做联想性补全而不是稳定性复制。约束三法律主体必须保留全称。甲方、乙方、某某有限公司、某某人民法院这些主体名称在摘要里一个都不能省。模型的压缩本能会把“某某银行股份有限公司上海分行”压缩成“某银行上海分行”从信息角度看是精简了从法律效力角度看是丢了主体资格信息。约束四禁止增加原文没有的判断。比如原文只写了“双方未就赔偿方案达成一致”模型不能写成“双方就赔偿方案产生严重分歧”。这是典型的“模型把中性表述升级为情绪化表述”法律文书的严肃性经不起这种润色。约束五不确认就标记。模型必须被允许说“不知道”。当摘要指令遇到原文表述模糊、指代不明或者文档出现前后矛盾时模型应该把相关内容放进uncertain字段而不是强行给出一个看起来完整的答案。这套设计等于给黑匣子开了一扇窗人工复核时有据可查。4.2 输出格式与置信度标记让机器知道哪里“拿不准”摘要输出如果只是一段文本程序能做的是后置校验如果输出是结构化 JSON程序就能做前置拦截。我采用的输出格式是双字段summary放最终精简文本uncertain放需要人工二次确认的信息列表。这个uncertain字段的价值在于给人工复核提供入口。法律摘要不可能保证 100% 忠实但至少要把“模型自己都拿不准”的部分标出来。标记出的内容可能包括“该条款中‘相应责任’未明确指向违约金或赔偿”“原文本此处存在模糊表述无法判断义务主体”。人工复核时只需要专攻这些标记而不是从头到尾通读。输出格式要求在 Prompt 里用 JSON Schema 的形式写清楚并在代码里做好容错。实际调用中模型偶尔会返回非法 JSON或者字段名从summary漂移为Summary。解析时要先做一次字段名归一化把首字母大小写都转为小写再取值解析失败则触发一次重试重试仍失败的落进“待人工处理”队列由人工补摘要。4.3 用 DeepSeek API 跑通最小摘要调用前面第 3.3 节已经给出了summarize_block的完整实现这里补充一个直接可跑的最小调用示例便于先验证 API 连通性和 Prompt 效果再接入完整管线。from openai import OpenAI import os client OpenAI( api_keyos.environ.get(DEEPSEEK_API_KEY), base_urlhttps://api.deepseek.com ) resp client.chat.completions.create( modeldeepseek-chat, temperature0.1, max_tokens500, messages[ {role: system, content: LAW_SUMMARY_SYSTEM_PROMPT}, {role: user, content: 第五条 甲方应当于合同生效之日起三十日内向乙方交付全部货物。逾期交付的每逾期一日按合同总价款的千分之一向乙方支付违约金。} ] ) print(resp.choices[0].message.content)这段代码验证的核心是“约束是否真的生效”。运行后看输出里的summary字段是否完整保留了“应当”“三十日”“千分之一”这些效力要素以及是否把“逾期交付”和“支付违约金”的因果关系保留下来了。如果输出把“应当”改成了“需要”或者把“三十日”压缩成了“约一个月”说明 Prompt 约束还没到位需要加重约束强度——比如把约束一单独抽出来用独立的 user 消息再强调一次。API 调用本身没有太多参数玄学除了temperature必须压低还有一个值得调的是max_tokens。摘要不是对话模型在 token 预算不足时会强行截断输出导致摘要缺尾。块级摘要给到 800 token 是安全的章级摘要涉及长文本压缩合并给到 2000 token 比较稳妥。截断的问题宁可少生成一些也不能让模型把没写完的内容硬补完——补出来的部分就是幻觉重灾区。5. 法律摘要避坑记录五种让模型“看着对、实际错”的典型翻车现场5.1 法条号漂移从“第七百零三条”变成“第七百零二条”现象一份租赁合同的摘要中模型把“《中华人民共和国民法典》第七百零三条”写成了“第七百零二条”。单看摘要文本内容通顺、逻辑完整但法条引用编号错了一位。这种错误除非人工对照原文否则几乎不可能靠阅读发现。原因抽象式生成在重现法条编号时模型依赖的是预训练阶段学到的“记忆”不是对输入文本的稳定复制。第七百零三条和第七百零二条在语料里都是高频出现的内容模型在生成时发生了邻近编号的联想性补全。解决摘要输出后抽取出所有“第X条/第X款/第X项”格式的编号与输入原文的编号做集合比对。所有摘要里出现的编号必须都出现在原文中多出来的编号直接判定为幻觉触发对对应分块的重新生成。这个校验用正则就能实现不需要额外模型。5.2 “应当”被改成“可以”规范性效力的隐蔽丢失现象摘要把“甲方应当于每月五日前支付租金”写成了“甲方可以于每月五日前支付租金”。从压缩率看摘要很成功但法律含义完全变了——强制性义务变成了授权性权利这份摘要如果被人拿去作为依据后果很严重。原因模型的压缩机制倾向于把句子改写得更“温和”。在模型看来“应当”和“可以”在多数语料场景里是可以互换的语气词但法律文本中这两个词决定条款是否具备强制力。Prompt 里明确写了“不得改写约束强度关键词”但模型仍有概率违反。解决做一次“规范力度词校验表”列出应当、必须、不得、禁止、有权、可以、可以但应当等关键词比对原文和摘要中的出现次数与上下文位置。关键词数量不一致时直接把该块摘要在流程里打回重跑。这个校验从 Prompt 约束到代码校验闭环是法律摘要方案里性价比最高的安全阀。5.3 分块切断完整法条摘要里出现“甲方应”现象某个分块的摘要输出为“甲方应在收到货物后七日内支付货款逾期……”句子戛然而止后半段去查原文发现被切到了下一个分块里。原因最初做的分块逻辑是纯按字符数 1200 切分恰好把一条法条从中间切断。切分后的两个分块各自都包含半条信息模型对每个分块生成摘要时只能概括到截断点为止后半段的义务内容在块级摘要阶段就丢了。解决分块策略改成“条文边界优先”即先按第 3.2 节的split_by_article切出完整的条再对超过长度上限的条按“款”的边界二次切分。字符数切分只作为兜底而且兜底切分点必须跳回上一个完整句号。这个教训的价值是分块规则决定了摘要的上限分块错了后面的 Prompt 再强也没用。5.4 跨章引用断裂“上述约定”在精简版里悬空现象全文精简版里出现“乙方未按上述约定履行义务的应当承担违约责任”但读者往前翻两页找不到“上述约定”指的是什么。摘要文本像一段悬浮的逻辑碎片。原因块级摘要时模型把“上述约定”这个回指词保留在了摘要里。块级摘要之间相互独立合并到章级摘要时前一章的内容已经被压缩过一轮“上述约定”的指代对象在压缩过程中被删掉了。解决在 Prompt 约束里增加一条——摘要中禁止出现“上述、如前所述、前款、该约定”等需要依赖上下文的回指表达。如果原文有回指词模型必须展开为具体条款编号。展开时允许模型根据上下文推断拿不准的内容放进uncertain字段。这条约束同时降低了跨层合并时的信息丢失概率。5.5 长文档末尾溢出模型脑补了原文没有的内容现象一份 200 页合同生成的最终精简版里出现了原文完全没有的“双方同意在争议发生后三十日内共同委托第三方机构进行评估”。单看这句像正常法律条款但人工核对原文发现没有任何条款做过此类约定。原因摘要管线对每个块独立调用模型但块间重用 token 过多导致整体消耗超限部分靠后的分块任务失败重试逻辑错误地把它当作“空块”跳过。模型在章级合并阶段发现输入缺少后面章节的摘要内容自动“补全”了缺失信息。解决批量处理时把每个分块的摘要结果落盘存档任务结束后统计“已摘要块数”与“总块数”不一致时不进入章级合并阶段。同时检查 API 返回结果里是否有finish_reasonlength的截断标记有截断的分块单独重跑。这个坑的根源在于长文档管线的可靠性与单个环节的成功率强相关任何一个失败都不能静默吞掉必须显式暴露出来。6. 摘要质量的效力校验要素召回与人工复核的落地流程指标不能只靠“模型说摘要完成了”还需要可量化的效力校验。我落地时使用“要素召回率”作为核心指标在摘要生成前人工设定该文档必须保留的效力要素清单生成后程序检查这些要素是否出现在摘要文本中。对一份买卖合同要素清单可能是甲方、乙方、交货期限、付款期限、违约金比例、争议解决方式、合同编号对一份判决书要素清单是案号、当事人、案由、裁判结果、法律依据。def compute_recall(elements, summary_text): 计算效力要素召回率。 elements: list[str]预设必须保留的效力要素 summary_text: 摘要文本 返回召回率与缺失要素列表。 missing [e for e in elements if e not in summary_text] recall (len(elements) - len(missing)) / len(elements) return recall, missing召回率低于 0.95 的摘要不进下一级流程。这个 0.95 的阈值不是拍脑袋法律文档的效力完整性要求极高一个关键金额的丢失就可能导致整份摘要不可用。如果一轮生成达不到阈值迭代做法是定位缺失要素所在的分块对该分块单独补充摘要内容而不是整篇重新生成——后者成本高且可能引入新的丢失。人工复核按分层抽检执行每批次摘要中随机抽取 10% 的完整摘要做全文复核同时把uncertain字段标记过的所有段落全部人工复核。后者是比随机抽检更重要的环节——模型已经明确“拿不准”的内容必须有人兜底不能直接放出去。抽检发现 5% 以上块级的效力要素丢失整批打回重跑发现 2% 以下且均为轻微保留问题时只修正对应块。最后说一个调优技巧同一批次文档用两次独立调用生成摘要对比两份摘要的差异部分。正常生成的两份摘要应该高度一致差异区域大概率是模型的不稳定输出也是幻觉风险最高的区域。把差异抽取出来单独人工核验比逐字通读效率高得多。我现在每批摘要都会先跑差异对比再进人工环节这个习惯帮我堵住了不少只有通读原文才能发现的效力损伤。希望帮到你。本文还有配套的精品资源点击获取
DeepSeek法律文档摘要：抽象式生成与效力校验实战
简介面向法律科技从业者、NLP算法工程师及法律文档处理研究者的DeepSeek法律文档智能摘要与要点快速提取方案系统覆盖从法律文本解析、术语图谱构建到保留法律效力的精简文书生成全流程适合作为技术方案设计与工程落地的参考。资源为单个PDF文件大小12.47MB共446页、50个大章节文档内目录、书签大纲和章节跳转均可正常使用文字与图表显示完整。目前已有141人学习下载。前18章详细展开法律文档处理痛点与技术栈全景、多层级语义分割、法律实体关系事件抽取、法律效力要素标注体系、小样本标注、数据增强、模型初始化、数据划分、混合损失函数、超参数调优、训练过程监控及多GPU分布式训练等内容后续章节继续覆盖微调数据准备、微调策略选择等实践环节。整份资料条理清晰既可作为系统学习讲义也可按目录快速定位到特定技术模块方便对照自身项目选用。1. 法律摘要不是“摘要”而是“效力保全”为什么抽象式生成值得做一份 446 页的法律文书人工通读至少需要两天但用 DeepSeek 这类大模型做智能摘要十分钟就能拿到一个“能看懂”的精简版。问题在于这个精简版敢不敢拿去给领导签字、给外部律师复核法律摘要翻车的代价不是文字不够流畅而是义务主体换位、法条编号漂移、“应当”变成“可以”这类效力损伤。标题里这个方案的核心是把抽象式文本生成用在最需要结构约束的场景——先拆 PDF再逐条摘要最后层级合并并在每一层都想办法保住条款效力。适合正在做法律文档智能化、合规审阅和长 PDF 信息压缩的工程与产品团队。2. DeepSeek 抽象式摘要的核心选型抽取式、生成式与法律效力的三角权衡2.1 为什么抽取式摘要在法律长文档上行不通做法律文档摘要很多团队第一反应是拿 TextRank 或 BERT 系列模型做抽取式摘要从原文里挑得分高的句子按顺序拼成一段。这个思路在新闻、论文场景问题不大但到了法律文书上基本走不通。原因是法律文本的“要点”很少落在单个句子上一个完整的义务链通常是“主体—行为—期限—后果—依据”跨多个条款出现。抽取式只能摘句子摘不出这条链路。举一个实际例子一份供货合同里第三条约定交货时间第二十二条约定逾期违约金第四十八条约定不可抗力免责。三个句子各自单独看都是有效信息但抽出来拼在一起读者无法建立“逾期交货触发违约金”这个因果关联。人工写摘要时会把这三条合并成一句“乙方逾期交货的应按第二十二条向甲方支付违约金。”这正是抽取式方法的死穴它做的是字符级压缩不是语义级压缩。抽取式的另一个问题是压缩率太低。我见过一些抽了 60 多句话的精简版篇幅只剩原来的三分之一不到就号称“摘要”但读起来和目录没什么区别。法律文书要求摘要具备可转述性——可以直接拿给决策层或外部律师读而不是让人再去翻原文确认逻辑。这个诉求决定了单靠句子拼接不现实。可以看下面的对比理解为什么抽象式生成在“用户感受”上明显占优但风险也同步升高维度抽取式抽象式DeepSeek字面忠实度高逐字摘录中高受 Prompt 约束压缩率低通常只能压缩 50% 左右高可压缩至 10% 左右跨条款逻辑合并基本做不到能做但有幻觉风险法条号与主体一致性不易出错需要程序化校验落地成本低本地模型即可需要 API 调用与校验管线可见抽象式生成不是“更高级的抽取”而是换了一条技术路线。它用模型的语言组织能力替代句子拼接代价是模型的“自由发挥”在法律场景里是危险的。所以选型结论不是“用抽象式替代抽取式”而是“用抽象式生成 强约束 校验”三个环节缺一个都不要上线。2.2 抽象式生成的落地前提分块、层级与检索三件套把抽象式生成直接用于法律摘要最常见也最致命的错误是整篇 446 页一次性喂给模型。且不论 token 成本和上下文窗口是否够用模型对超长输入的注意力分布会严重衰减开头和结尾的内容记得住中部大量条款直接被忽略生成的摘要可能只覆盖前 20 页和最后 10 页的内容。解决这个问题没有捷径必须“分治”把长文档拆成可处理的语义块逐块生成摘要再按章节层级逐步合并。完整的方案流水线在我这边是四段式PDF 解析与章节树构建先提取文档结构和目录层级明确哪些内容属于同一章、同一节、同一条。按条、款、项分块法律文本的天然语义边界就是“条”。一个分块的基本单位是一条或一组容量接近的条避免把完整法条切成两半。层级摘要先对每个分块做块级摘要再对章做章级摘要最后把所有章级摘要合并成全文精简版。效力校验法条号一致性比对、规范力度词检查、要素召回率计算以及人工抽检。这个链路里的“检索”指的是跨层级的指代还原。比如块级摘要里出现“上述约定”合并到章级时必须知道“上述”指哪个条款否则最终精简版里都是悬浮的指代词。常见做法是在块级摘要时强制模型把指代词展开成具体条款对象而不是把问题留给下一层。分块和层级听起来是朴素的工程手段但正是这套“笨办法”把抽象式生成的幻觉风险压到了可控范围。模型每次只需要处理一两个条的内容出错范围小回溯定位也方便——哪一条摘要不对直接重跑那一条而不是整篇重新生成。2.3 DeepSeek 的上下文与成本考量446 页 PDF 的拆解思路按照每页 800 字左右估算446 页 PDF 对应 35 万字符以上折算成 token 接近 9 万到 12 万。这个体量即使塞进当前主流大模型的上下文窗口单次调用的成本也高得离谱而且生成质量必然下滑。分层摘要方案的核心收益不只是在质量上也在成本上块级摘要阶段每次只消耗几百到一千 token章级合并阶段每次消耗几千 token总成本远低于一次性处理全文。DeepSeek 的 API 调用方式和 OpenAI 兼容用已有的 chat.completions 接口就能接。对多数团队来说这意味着后端改造成本很低——不需要自己部署推理服务也不需要换一套 SDK。如果确实有数据合规要求也可以考虑本地部署 DeepSeek 的开源权重但那是另一个话题做方案验证阶段直接走 API 是最快的路径。这里的关键参数不是模型本身而是分块大小和温度系数。分块太大单次摘要容易丢细节分块太小产生的摘要块数量太多后续合并时上下文碎片化。我一般把单块容量控制在 800 到 1500 字符之间温度调到 0.1 以下让模型的输出尽量保守。温度这个参数是法律摘要场景里最容易被忽略的默认温度下模型会“发挥”得更好但法律文本不需要发挥。3. 从 446 页 PDF 到结构化文本法律文书的层级解析与分块策略3.1 先用 PDF 结构做分治提取目录和标题层级拿到一份 446 页的 PDF第一步不是直接丢给模型而是先用工具把 PDF 转成带层级结构的文本。法律文书大多是排版规范的 Word 或 LaTeX 导出物标题字号和正文字号有明确区分。用 PyMuPDF 可以提取每个文本块的字体大小再根据字号差异推断标题层级。import fitz # PyMuPDF def extract_heading_structure(pdf_path, body_size_threshold12.0): 提取 PDF 中的标题层级。 思路正文通常为 10.5pt 或 12pt 左右明显大于正文字号的文本块视为标题。 返回按页码排序的 (level, text) 列表。 doc fitz.open(pdf_path) headings [] for page_idx, page in enumerate(doc): d page.get_text(dict) for block in d[blocks]: if lines not in block: continue for line in block[lines]: for span in line[spans]: size span[size] text span[text].strip() if not text: continue if size body_size_threshold * 1.3: # 字号明显大于正文视为标题 level 1 if size body_size_threshold * 1.6 else 2 headings.append({page: page_idx 1, level: level, text: text}) doc.close() return headings这段代码的核心判断依据是“字号倍差”。法律文书的章标题通常比正文大 1.6 倍以上节标题大约在 1.3 倍左右。body_size_threshold需要按文档实际排版调节——如果正文是 12pt章标题可能是 16pt 或 18pt如果正文是 10.5pt阈值就相应下调。注意 PDF 里“字号”不是绝对的物理尺寸而是嵌入字体定义的规范字高直接比较span[size]数值即可不必换算成毫米或磅值。另一个常见做法是检查 PDF 目录书签。PyMuPDF 的doc.get_toc()能直接拿到书签目录比字体推断准确得多。但很多扫描版或印刷厂导出的 PDF 目录书签为空所以字体推断是必要兜底。实际落地时我会两种方式都跑一遍优先用get_toc()的结果再用字体推断补漏。3.2 基于条、款、项的三级分块规则拿到标题结构后真正决定摘要质量的是分块策略。法律文本的最小语义单位是“条”一条通常能独立表达一个完整规则。分块的第一原则是以“条”为边界绝不把一条切成两半。import re def split_by_article(text): 按“第X条”边界切分文本。 返回 list[dict]每个 dict 包含 article 编号与正文。 兼容“第一条”到“第九十九条”、“第一百一十二条”等编号形态。 # 匹配中文数字条号第[一二三四五六七八九十百零]条 pattern re.compile(r第[一二三四五六七八九十百零]条) matches list(pattern.finditer(text)) if not matches: # 没有条文标记的文档退化为整段为一个块 return [{article: 未编号, text: text.strip()}] blocks [] for i, m in enumerate(matches): start m.start() end matches[i 1].start() if i 1 len(matches) else len(text) article_no m.group() content text[start:end].strip() blocks.append({article: article_no, text: content}) return blocks这个切分逻辑假设条文是连续排列的。实际法律文书里还有“第X章”和“附件”需要先用上一节的标题结构把章节标题过滤掉再对章下面的正文做条文切分。如果文档里既有“第X条”又有“第X.X条”某些合同用 3.1、3.2 的编号体系正则要改成同时匹配两类编号r第[一二三四五六七八九十百零]条|\d\.\d。分块之后还有一个关键参数单块上限。一条法规或合同条款可能极长比如一条包含五款、每款还有两项的文本可能超过 2000 字。对这种长条应该按“款”再切一层——检测“第X款”或“X.”标识把一条拆成几个子块。我的经验值是单块超过 1500 字就必须拆低于 600 字可以跟相邻条文合并适用于枚举型短条。3.3 块级摘要与层级合并的 Python 实现分块完成之后摘要管线就清晰了先对每个条文块调用 DeepSeek 生成块级摘要再把同一章下的块级摘要拼起来做章级摘要最后把各章摘要拼起来生成全文精简版。每一层的 Prompt 相同只有输入文本的长度不同。import json import os from openai import OpenAI client OpenAI( api_keyos.environ.get(DEEPSEEK_API_KEY), base_urlhttps://api.deepseek.com ) LAW_SUMMARY_SYSTEM_PROMPT 你是一名法律文档精简专家。你的任务是对输入的原始法律文本生成摘要。 必须遵守以下约束 1. 保留所有具有法律效力的信息主体名称、合同编号、金额、期限、义务行为、法律后果。 2. 不得改写约束强度关键词。“应当”“可以”“不得”“必须”“有权”必须按原文保留。 3. 不得省略法条引用编号不得修改“第X条/第X款/第X项”的编号。 4. 如果原文存在指代词如“上述约定、前款、该协议”在摘要中展开为具体对象。 5. 不得添加任何原文不存在的推论、建议或价值判断。 6. 如对某些信息不确定单独输出到 uncertain 字段不要写进摘要正文。 输出 JSON 格式{summary: 摘要正文, uncertain: [不确定信息1, 不确定信息2]} .strip() def summarize_block(block_text, max_tokens800): 对单个条文块生成摘要。 resp client.chat.completions.create( modeldeepseek-chat, temperature0.1, max_tokensmax_tokens, response_format{type: json_object}, messages[ {role: system, content: LAW_SUMMARY_SYSTEM_PROMPT}, {role: user, content: f原文如下\n{block_text}} ] ) content resp.choices[0].message.content return json.loads(content)参数说明temperature0.1是为了让模型输出尽量确定减少同义改写带来的效力漂移response_format{type: json_object}是 DeepSeek 对 JSON 输出模式的支持保证summary和uncertain能被程序稳定解析。max_tokens按输入长度调整——块级摘要通常 800 够用章级摘要可以放宽到 2000。调用链路的另一个细节是需要增加失败重试。长文档批量处理时偶发网络错误或服务端 429限流很正常不要在单次调用上纠结。重试策略用指数退避第一次失败等 2 秒第二次等 4 秒最多重试 5 次。批量任务建议控制在每并发 5 个请求以内避免触发限流后整批任务中断。4. 抽象式生成的精度控制Prompt 工程与法律效力约束4.1 法律摘要 Prompt 的五个强制约束抽象式生成最让人不放心的地方是“自由发挥”。模型的预训练目标决定了它天然倾向于把输入改写得更通顺、更简洁但法律文本的效力恰恰隐藏在那些让句子变得“不通顺”的限定词里。我在多轮迭代后把 Prompt 约束收敛成五个必须项缺一不可。约束一保留义务性、授权性、禁止性关键词。法律文本里的“应当、可以、不得、有权、必须”不是同义词而是决定条文性质强制性规范还是任意性规范的模态词。模型在压缩转述时极其容易把这些词替换成近义表达比如把“应当”改成“需要”把“不得”改成“不能”。前者是规范强度变化后者是语气变化都是不可接受的。约束二法条引用编号只能原样复制。法律文书内部会大量引用“根据《中华人民共和国民法典》第七百零三条”“本合同第二十二条约定”等内容。模型生成摘要时如果重新组织语言非常容易出现编号漂移——把“第二十二条”写成“第二十一条”或者把案号中的年份改掉。这不是模型“笨”而是编号在预训练语料里出现频率高模型倾向于做联想性补全而不是稳定性复制。约束三法律主体必须保留全称。甲方、乙方、某某有限公司、某某人民法院这些主体名称在摘要里一个都不能省。模型的压缩本能会把“某某银行股份有限公司上海分行”压缩成“某银行上海分行”从信息角度看是精简了从法律效力角度看是丢了主体资格信息。约束四禁止增加原文没有的判断。比如原文只写了“双方未就赔偿方案达成一致”模型不能写成“双方就赔偿方案产生严重分歧”。这是典型的“模型把中性表述升级为情绪化表述”法律文书的严肃性经不起这种润色。约束五不确认就标记。模型必须被允许说“不知道”。当摘要指令遇到原文表述模糊、指代不明或者文档出现前后矛盾时模型应该把相关内容放进uncertain字段而不是强行给出一个看起来完整的答案。这套设计等于给黑匣子开了一扇窗人工复核时有据可查。4.2 输出格式与置信度标记让机器知道哪里“拿不准”摘要输出如果只是一段文本程序能做的是后置校验如果输出是结构化 JSON程序就能做前置拦截。我采用的输出格式是双字段summary放最终精简文本uncertain放需要人工二次确认的信息列表。这个uncertain字段的价值在于给人工复核提供入口。法律摘要不可能保证 100% 忠实但至少要把“模型自己都拿不准”的部分标出来。标记出的内容可能包括“该条款中‘相应责任’未明确指向违约金或赔偿”“原文本此处存在模糊表述无法判断义务主体”。人工复核时只需要专攻这些标记而不是从头到尾通读。输出格式要求在 Prompt 里用 JSON Schema 的形式写清楚并在代码里做好容错。实际调用中模型偶尔会返回非法 JSON或者字段名从summary漂移为Summary。解析时要先做一次字段名归一化把首字母大小写都转为小写再取值解析失败则触发一次重试重试仍失败的落进“待人工处理”队列由人工补摘要。4.3 用 DeepSeek API 跑通最小摘要调用前面第 3.3 节已经给出了summarize_block的完整实现这里补充一个直接可跑的最小调用示例便于先验证 API 连通性和 Prompt 效果再接入完整管线。from openai import OpenAI import os client OpenAI( api_keyos.environ.get(DEEPSEEK_API_KEY), base_urlhttps://api.deepseek.com ) resp client.chat.completions.create( modeldeepseek-chat, temperature0.1, max_tokens500, messages[ {role: system, content: LAW_SUMMARY_SYSTEM_PROMPT}, {role: user, content: 第五条 甲方应当于合同生效之日起三十日内向乙方交付全部货物。逾期交付的每逾期一日按合同总价款的千分之一向乙方支付违约金。} ] ) print(resp.choices[0].message.content)这段代码验证的核心是“约束是否真的生效”。运行后看输出里的summary字段是否完整保留了“应当”“三十日”“千分之一”这些效力要素以及是否把“逾期交付”和“支付违约金”的因果关系保留下来了。如果输出把“应当”改成了“需要”或者把“三十日”压缩成了“约一个月”说明 Prompt 约束还没到位需要加重约束强度——比如把约束一单独抽出来用独立的 user 消息再强调一次。API 调用本身没有太多参数玄学除了temperature必须压低还有一个值得调的是max_tokens。摘要不是对话模型在 token 预算不足时会强行截断输出导致摘要缺尾。块级摘要给到 800 token 是安全的章级摘要涉及长文本压缩合并给到 2000 token 比较稳妥。截断的问题宁可少生成一些也不能让模型把没写完的内容硬补完——补出来的部分就是幻觉重灾区。5. 法律摘要避坑记录五种让模型“看着对、实际错”的典型翻车现场5.1 法条号漂移从“第七百零三条”变成“第七百零二条”现象一份租赁合同的摘要中模型把“《中华人民共和国民法典》第七百零三条”写成了“第七百零二条”。单看摘要文本内容通顺、逻辑完整但法条引用编号错了一位。这种错误除非人工对照原文否则几乎不可能靠阅读发现。原因抽象式生成在重现法条编号时模型依赖的是预训练阶段学到的“记忆”不是对输入文本的稳定复制。第七百零三条和第七百零二条在语料里都是高频出现的内容模型在生成时发生了邻近编号的联想性补全。解决摘要输出后抽取出所有“第X条/第X款/第X项”格式的编号与输入原文的编号做集合比对。所有摘要里出现的编号必须都出现在原文中多出来的编号直接判定为幻觉触发对对应分块的重新生成。这个校验用正则就能实现不需要额外模型。5.2 “应当”被改成“可以”规范性效力的隐蔽丢失现象摘要把“甲方应当于每月五日前支付租金”写成了“甲方可以于每月五日前支付租金”。从压缩率看摘要很成功但法律含义完全变了——强制性义务变成了授权性权利这份摘要如果被人拿去作为依据后果很严重。原因模型的压缩机制倾向于把句子改写得更“温和”。在模型看来“应当”和“可以”在多数语料场景里是可以互换的语气词但法律文本中这两个词决定条款是否具备强制力。Prompt 里明确写了“不得改写约束强度关键词”但模型仍有概率违反。解决做一次“规范力度词校验表”列出应当、必须、不得、禁止、有权、可以、可以但应当等关键词比对原文和摘要中的出现次数与上下文位置。关键词数量不一致时直接把该块摘要在流程里打回重跑。这个校验从 Prompt 约束到代码校验闭环是法律摘要方案里性价比最高的安全阀。5.3 分块切断完整法条摘要里出现“甲方应”现象某个分块的摘要输出为“甲方应在收到货物后七日内支付货款逾期……”句子戛然而止后半段去查原文发现被切到了下一个分块里。原因最初做的分块逻辑是纯按字符数 1200 切分恰好把一条法条从中间切断。切分后的两个分块各自都包含半条信息模型对每个分块生成摘要时只能概括到截断点为止后半段的义务内容在块级摘要阶段就丢了。解决分块策略改成“条文边界优先”即先按第 3.2 节的split_by_article切出完整的条再对超过长度上限的条按“款”的边界二次切分。字符数切分只作为兜底而且兜底切分点必须跳回上一个完整句号。这个教训的价值是分块规则决定了摘要的上限分块错了后面的 Prompt 再强也没用。5.4 跨章引用断裂“上述约定”在精简版里悬空现象全文精简版里出现“乙方未按上述约定履行义务的应当承担违约责任”但读者往前翻两页找不到“上述约定”指的是什么。摘要文本像一段悬浮的逻辑碎片。原因块级摘要时模型把“上述约定”这个回指词保留在了摘要里。块级摘要之间相互独立合并到章级摘要时前一章的内容已经被压缩过一轮“上述约定”的指代对象在压缩过程中被删掉了。解决在 Prompt 约束里增加一条——摘要中禁止出现“上述、如前所述、前款、该约定”等需要依赖上下文的回指表达。如果原文有回指词模型必须展开为具体条款编号。展开时允许模型根据上下文推断拿不准的内容放进uncertain字段。这条约束同时降低了跨层合并时的信息丢失概率。5.5 长文档末尾溢出模型脑补了原文没有的内容现象一份 200 页合同生成的最终精简版里出现了原文完全没有的“双方同意在争议发生后三十日内共同委托第三方机构进行评估”。单看这句像正常法律条款但人工核对原文发现没有任何条款做过此类约定。原因摘要管线对每个块独立调用模型但块间重用 token 过多导致整体消耗超限部分靠后的分块任务失败重试逻辑错误地把它当作“空块”跳过。模型在章级合并阶段发现输入缺少后面章节的摘要内容自动“补全”了缺失信息。解决批量处理时把每个分块的摘要结果落盘存档任务结束后统计“已摘要块数”与“总块数”不一致时不进入章级合并阶段。同时检查 API 返回结果里是否有finish_reasonlength的截断标记有截断的分块单独重跑。这个坑的根源在于长文档管线的可靠性与单个环节的成功率强相关任何一个失败都不能静默吞掉必须显式暴露出来。6. 摘要质量的效力校验要素召回与人工复核的落地流程指标不能只靠“模型说摘要完成了”还需要可量化的效力校验。我落地时使用“要素召回率”作为核心指标在摘要生成前人工设定该文档必须保留的效力要素清单生成后程序检查这些要素是否出现在摘要文本中。对一份买卖合同要素清单可能是甲方、乙方、交货期限、付款期限、违约金比例、争议解决方式、合同编号对一份判决书要素清单是案号、当事人、案由、裁判结果、法律依据。def compute_recall(elements, summary_text): 计算效力要素召回率。 elements: list[str]预设必须保留的效力要素 summary_text: 摘要文本 返回召回率与缺失要素列表。 missing [e for e in elements if e not in summary_text] recall (len(elements) - len(missing)) / len(elements) return recall, missing召回率低于 0.95 的摘要不进下一级流程。这个 0.95 的阈值不是拍脑袋法律文档的效力完整性要求极高一个关键金额的丢失就可能导致整份摘要不可用。如果一轮生成达不到阈值迭代做法是定位缺失要素所在的分块对该分块单独补充摘要内容而不是整篇重新生成——后者成本高且可能引入新的丢失。人工复核按分层抽检执行每批次摘要中随机抽取 10% 的完整摘要做全文复核同时把uncertain字段标记过的所有段落全部人工复核。后者是比随机抽检更重要的环节——模型已经明确“拿不准”的内容必须有人兜底不能直接放出去。抽检发现 5% 以上块级的效力要素丢失整批打回重跑发现 2% 以下且均为轻微保留问题时只修正对应块。最后说一个调优技巧同一批次文档用两次独立调用生成摘要对比两份摘要的差异部分。正常生成的两份摘要应该高度一致差异区域大概率是模型的不稳定输出也是幻觉风险最高的区域。把差异抽取出来单独人工核验比逐字通读效率高得多。我现在每批摘要都会先跑差异对比再进人工环节这个习惯帮我堵住了不少只有通读原文才能发现的效力损伤。希望帮到你。本文还有配套的精品资源点击获取
