简介：一份围绕 DeepSeek 法律文档智能摘要与要点快速提取的完整技术资料，面向法律科技研发、NLP算法工程师以及法律信息化项目团队，系统讲解从文本解析、术语图谱、预训练模型选型到抽象式摘要生成、法律效力要素标注与分布式训练的全链路方案。文档共分50个大章节，覆盖法律文档结构化解析、数据清洗、小样本标注、数据增强、模型微调、超参数调优与训练监控等关键技术模块；前18章已清晰呈现各主题层级，便于按目录或书签快速定位。压缩包为单份PDF文件，大小12.47MB，页面共446页，文字、图表与目录显示完整，适合直接阅读与检索。已有141人浏览学习。通过阅读可以掌握面向法律文书的摘要建模思路、法律效力保留的标注体系设计，以及工程落地中的训练配置与优化策略。
1. 法律文档摘要不是“压缩”，是“证据链重建”
接到一个 446 页的法律 PDF，要求在半天内给出精简版文书，还要“保留法律效力”——这不是把字数变少的问题，而是要把几十万字里的权利义务关系原封不动地搬进几十页甚至几页的产出物里。DeepSeek 智能摘要方案要解决的就是这个：用抽象式文本生成做要点快速提取，而不是靠抽取原句拼凑。适合三类人：被合同和法规淹没的企业法务、帮客户做审阅的律师，以及要做法律 NLP 落地的开发者。它的核心不是“生成漂亮话”，而是让模型在改写时守住义务主体、金额、期限、除外责任这些法律效力锚点，同时给出可追溯的原文引用。这个方向真正难的不是调用模型，而是如何让摘要不“变形”。
2. 为什么选抽象式文本生成：抽取式做不了“要点”
2.1 抽取式摘要的三个致命短板
很多团队拿到法律文档摘要的第一反应是抽取式：把原文里看起来重要的句子挑出来，拼成摘要。这个思路在新闻摘要上够用，但在法律文本上会出三类问题。
第一，跨条款整合做不了。合同里的付款义务往往拆在“付款方式”“违约责任”“发票条款”三个位置，抽取式只能机械摘句，无法把三处的信息合并成一句完整的“买方应于到货后 30 日内付清全款，逾期需按日支付 0.05% 违约金”。第二，否定和例外容易被掐头去尾。比如“甲方不承担因乙方未提供必要资料而导致的延期责任”这种句子，抽取出“甲方不承担延期责任”就完全变了味。第三，精简版文书需要的是改写，不是摘抄。同一件事，原文可能用了两页纸的表述，抽取式做不到压缩。
所以标题里写“抽象式文本生成”是有道理的。抽象式让模型在理解原文的基础上，用自己的话重新组织内容，听起来灵活，但也带来了新风险：生成幻觉和语义漂移。后面会重点讲怎么用约束把这两种风险压住。
2.2 抽象式生成与“保留法律效力”的平衡原理
抽象式文本生成本质上是一个条件语言建模问题：模型根据输入的源文本和指令，逐个生成目标 token。DeepSeek 这类大模型在长上下文理解和指令跟随上的表现，让法律文本的抽象式摘要变得可用，但它不会天然理解“法律效力”是什么。
我一般会把“保留法律效力”拆成五个语义要素来约束模型：义务主体、动作与对象、金额与数量、期限与条件、法律后果。这五类信息只要有一个被改写、被遗漏，精简文书就可能失去法律意义。比如把“甲方应当”写成“甲方可以”，义务就变成了权利；把“三十日内”写成“尽快”，期限就消失了。
实际操作中，我会在 Prompt 里明确告诉模型：“你的输出不是解释，而是等价改写。既然要保留法律效力，就要做到语义等价。”同时要求输出 JSON 结构，让总结、要点、条件、原文片段分开。这样后续才能做自动校验，不然生成完根本不知道哪些内容被动了。
2.3 选 DeepSeek 的理由：长上下文、指令跟随、可本地部署
在 DeepSeek 之前，我踩过好几类模型。有的法律文本理解不错，但输出太长；有的对长文档支持很好，但价格高到没法批量跑。DeepSeek 的取舍比较适合这个场景：模型对中文法律文本有足够的理解力，上下文窗口能覆盖大部分分块后的条款，API 调用成本可控，而且支持本地部署，满足敏感数据不外传的要求。
具体到选型，我一般分两种情况。非敏感数据用 DeepSeek API 调用，方便，不用自己管显卡；涉密或者客户数据不能出内网，就用本地部署 DeepSeek 的量化版本，配合 vLLM 或者 Ollama 起一个兼容接口。这里要注意，本地部署的模型版本和量化位数会影响摘要质量，不要用 4-bit 量化跑特别复杂的法律改写，输出不稳定时先回到 API 版本验证流程，再切回本地。
3. 从 PDF 到结构化文本：解析层决定摘要下限
3.1 法律 PDF 为什么不能直接丢给模型
很多法律 PDF 是扫描件，或者带复杂的页眉页脚、表格、条款编号层级。直接丢给模型，它看到的是一大团乱码或者“第 1 页”“机密”这类噪声，摘要自然无从谈起。PDF 解析这一步做得不好，后面所有抽象式生成都是建立在垃圾之上。
我见过有人直接用 PyPDF2 的 extract_text()，结果中文全变成空行，或者把表格里的数字和正文混在一起。原因是这类库只处理简单文本流，不处理 CID 字体映射、扫描图像、表格边框。所以做法律文档智能摘要，第一步不是调模型，而是先把 PDF 转成干净的结构化文本，并保留页码和条款编号，作为后续追溯锚点。
3.2 用 pdfplumber 提取文本与表格
法律文档里最怕表格：保证金金额、交货时间、付款比例全在表格里，如果被识别成一行行文字，模型很容易混淆。我一般用 pdfplumber，它能把文本和表格分开提取。
import pdfplumber import json pdf_path = "legal_contract.pdf" pages = [] with pdfplumber.open(pdf_path) as pdf: for page in pdf.pages: text = page.extract_text() or "" tables = page.extract_tables() pages.append({ "page": page.page_number, "text": text, "tables": tables }) with open("pages.json", "w", encoding="utf-8") as f: json.dump(pages, f, ensure_ascii=False, indent=2)这里要说明两点。第一，extract_text() 返回的是带换行的原始文本，不能直接拿来喂模型，后面要清洗。第二，extract_tables() 返回的是二维列表，每行每列的单元格字符串。表格应该单独处理，并在后续拼接时用“【表格：第 X 页】”这样的标记插入对应位置，而不是让模型自己猜表格属于哪一条。页号保留下来，是为了最终生成精简文书时能写清楚“本摘要依据原合同第 12 页第 4.2 条”。
3.3 清洗噪声与重建条款编号
原始文本里会有大量换行、页眉页脚、OCR 识别错误。比如“第 十 二 条”中间被拆开，或者“甲方：”后面跟着一长串地址。我一般先做一次整体清洗，再用正则把“第X条”作为分段锚点，把条款切出来。
import re full_text = "\n".join([p["text"] for p in pages if p["text"]]) # 去页眉页脚常见噪声，保留正文 full_text = re.sub(r"\s+", " ", full_text) # 合并所有空白为单空格 # 重建条款编号：匹配 "第十二条" 或 "第12条" pattern = re.compile(r"第[\d一二三四五六七八九十百千零两]+条") matches = list(pattern.finditer(full_text)) clauses = [] for i, m in enumerate(matches): start = m.start() end = matches[i + 1].start() if i + 1 < len(matches) else len(full_text) clauses.append({ "clause_id": m.group(), "text": full_text[start:end].strip() })这段代码的关键是 clause_id 和 text 分离。很多抽样式摘要翻车，是因为条款编号被当作普通文本删掉了，后面引用时对不上。另外，合并空白时会把表格里的空格也合掉，所以表格不能走这条路，要单独处理。
清洗时还有一个坑：页码数字会被当成普通文本混入正文。我一般会去掉页眉页脚信息，比如“第 1 页”、“机密”这类重复出现的内容，否则模型可能把页码当成条款的一部分。这一步没有万能正则，要根据具体 PDF 的页眉模式调整。
3.4 分块策略：按条块而不是按页
分块是长文档处理最容易出错的地方。按页切块会把同一个条款拆成两半，模型两个半句都看不懂；按固定字符切块也会切断语义。法律文档最好的分块单位就是“条”或者“款”，因为法律效力的最小语义单元通常在一条之内。
切完条款后，如果某一条特别长，比如超过 1500 字，我会再按句号拆成子块，并在子块上保留父条款编号，例如“第 14 条_1”“第 14 条_2”。这样在 Map 阶段逐块做智能摘要时，还能知道这些子块属于同一条，方便后面对齐。
分块大小需要根据模型能力调整。DeepSeek 上下文足够长，但生成摘要时没必要把一整条 2000 字塞进去，512 到 1024 字一个子块是常见做法。太短会丢失上下文，太长则会增加生成时间，也更容易让模型在改写时丢掉细节。
def split_long_clause(clause): text = clause["text"] if len(text) <= 1000: return [clause] sentences = re.split(r"(?<=[。；;])", text) chunks, current = [], "" for sent in sentences: sent = sent.strip() if not sent: continue if len(current) + len(sent) > 1000: chunks.append({"clause_id": clause["clause_id"] + "_" + str(len(chunks)+1), "text": current}) current = sent else: current += sent if current: chunks.append({"clause_id": clause["clause_id"] + "_" + str(len(chunks)+1), "text": current}) return chunks这个函数的逻辑是：优先按“条”作为一个块，长条再按句号切。切分时用正则保留句子完整性，而不是硬切字符。子块的 clause_id 带着父级编号，后面合并时能还原。
4. 调 DeepSeek 生成精简文书：Prompt 模板与结构化输出
4.1 最小可用的摘要 Prompt
解析层做完，就到了核心：调用 DeepSeek 生成智能摘要。先写一个最小可用的单条摘要函数，验证模型对法律文本的理解力。
from openai import OpenAI import os client = OpenAI( api_key=os.getenv("DEEPSEEK_API_KEY"), base_url="https://api.deepseek.com" ) def summarize_clause(clause_text: str) -> str: resp = client.chat.completions.create( model="deepseek-chat", messages=[ {"role": "system", "content": "你是法律文档摘要助手。你只做精简，不改原意。"}, {"role": "user", "content": f"请把下面的条款转成一句精简表述，要求保留金额、日期、义务主体。\n\n{clause_text}"} ], temperature=0.2, max_tokens=1024 ) return resp.choices[0].message.content这段代码逻辑很直白，但有两个参数值得单独说。第一，temperature 必须设低。法律文本生成不是写作文，0.2 以下的温度能减少模型自由发挥的空间。第二，max_tokens 不要设太小，否则长条款被截断，后半部分义务丢失。我用 1024 是给单条摘要留足空间，如果摘要超长，应优化分块而不是调大 max_tokens。
还要注意，api_key 不要写死在代码里，用环境变量读取。这是最基本的防护，不然代码一旦上传仓库，密钥就泄露了。DeepSeek API 调用方式与 OpenAI 兼容，所以用 openai 库很省事。
4.2 面向“保留法律效力”的指令模板
最小 Prompt 只是验证，真正要落地要加约束。我常用的模板包含角色、任务、法律效力要素、输出格式、少样本示例。少样本特别重要，模型看到一两个例子后，才知道“保留法律效力”到底是什么意思。
prompt_template = """你是法律文书精简助手。你的任务是把给定条款改写成精简表述，改写结果必须与原文在法律效力上等价。 必须保留以下信息： 1. 义务主体：谁必须做、谁可以做、谁禁止做 2. 动作与对象：做什么、对谁做 3. 金额、数量、期限：所有数字不得改语态 4. 前提条件：只有在什么情况下才适用 5. 除外责任：原文写了哪些不承担责任的情形 禁止事项： - 不得把“应当”改成“可以”，不得把“可以”改成“应当” - 不得删除“但”“除非”“如果”等条件连接词 - 不得新增原文没有的免责条款 输出格式（JSON）： {{ "clause_id": "原条款编号", "summary": "一句精简表述", "key_points": ["要点1", "要点2"], "conditions": ["前提条件或除外责任"], "original_ref": "条款在原文中的位置或片段" }} 示例： 输入：第十条 买方应于收到货物后三十日内支付全部货款，除非双方另有书面约定。 输出： {{ "clause_id": "第十条", "summary": "买方应于收货后30日内支付全款，另有书面约定除外。", "key_points": ["买方付款义务", "付款期限为收货后30日内"], "conditions": ["双方另有书面约定时不适用"], "original_ref": "第十条" }} 现在处理下面的条款： {clause_text}"""这个模板的核心是“禁止事项”列表。我曾见过模型把“乙方可以自行决定”改成“乙方应当自行决定”，一句话就把权利变成了义务。把这些规则写进 Prompt，相当于给模型上了一道紧箍咒。
需要提醒的是，JSON 输出并不百分百可靠。我用过多种模型，DeepSeek 的指令跟随能力足够好，但偶尔会输出多余说明。所以要加一层解析容错：如果解析 JSON 失败，就把整段回复抛给人工，而不是默默吞掉。
4.3 长文档的 Map-Reduce 摘要流程
一个 446 页的 PDF，条款可能有几千条。不能一次性全部塞给模型，要用 Map-Reduce：先对每个条款块分别生成要点，再把所有要点合并成最终精简文书。
import json clause_summaries = [] for clause in clauses: user_content = prompt_template.format(clause_text=clause["text"]) resp = client.chat.completions.create( model="deepseek-chat", messages=[ {"role": "system", "content": "你是法律文书精简助手。"}, {"role": "user", "content": user_content} ], temperature=0.2, max_tokens=1024 ) try: parsed = json.loads(resp.choices[0].message.content) parsed["clause_id"] = clause["clause_id"] clause_summaries.append(parsed) except Exception: # 解析失败时保留原始回复，等待人工审核 clause_summaries.append({ "clause_id": clause["clause_id"], "summary": resp.choices[0].message.content, "parse_error": True }) # 把全部要点写入临时文件，方便后续 reduce with open("map_results.json", "w", encoding="utf-8") as f: json.dump(clause_summaries, f, ensure_ascii=False, indent=2)这段 Map 过程做了两件事：调用摘要，并把结果缓存到本地文件。缓存很重要。因为长文档摘要经常跑十几分钟甚至更久，中途 GPU 或网络一断，全部白跑。缓存后断点续跑，不用重新调用 API。
Reduce 阶段要小心：如果把几千条摘要一次塞进 Prompt，还是会超长。我会定义一个“压缩层级”，比如每次把 50 个 JSON 段落合并成一段精简要点，再对这 50 段做二次合并，直到剩余内容可以在 3000 字内，最后生成完整精简文书。这个过程类似多级汇总，每一级都由 DeepSeek 完成，同时保留上一级的原文引用字段。
5. 法律效力核对与常见坑：精简要“瘦身”不“变形”
5.1 只做摘要不做校验，等于给风险埋雷
现象：自动生成的摘要里，原合同“人民币壹佰万元整”被写成“100 万元”，金额本身没变，但“壹佰万元整”在法律文书里的精确表述性没了；更危险的是，原合同里同时存在“暂定金额”和“最高金额”两个数字，摘要只写了一个，导致义务范围收窄。
原因：抽象式文本生成时，模型倾向于把数字写成更自然的阿拉伯数字格式，同时会遗漏它在语义上认为不重要的重复数字。但法律效力恰恰依赖这些精确表述。
解决：把生成摘要前的原文和摘要放在一起，用正则抽取全部金额、日期、主体，做差集校验。抽出来的两个集合必须一致，不一致的条目直接标红人工复核。不要把这一步省掉，它是整个方案里最便宜的保险。
5.2 情态动词“应当”被改写成“可以”
现象：摘要中出现了“甲方可以要求乙方在规定时间内提供资料”，但原文写的是“甲方应当要求乙方……”。“应当”是强制性义务，“可以”是授权性权利，两者在法律解释上完全不同。更隐蔽的是“乙方有权”改成“乙方应权”这种病句，一眼看不出，但语义已经变味。
原因：抽象式生成依赖上下文预测，情态动词在中文里有时对语义影响大，有时小，模型在压缩长文时会把部分情态动词当作噪声处理。
解决：在 Prompt 的禁止事项里明确列出“应当”“必须”“可以”“有权”“禁止”等词，要求原样保留；生成后对原文和摘要的情态动词做逐词比对。我一般维护一个情态动词白名单，一旦发现摘要比原文多或少，就触发人工审核。
5.3 条款编号错乱，导致“依据第十条”指向错误
现象：某摘要中写着“依据本合同第十条，甲方有权解除合同”，但回到原文，真正写解除权的是第十二条。条款编号错位会让整份精简文书的引用效力失效，律师引用时找错依据。
原因：在分块阶段，模型没有接收到原文的条款编号，或者接收后重新编号了。比如我们把多个子块合并时，子块里的编号和父条款编号不一致，模型就可能猜一个新编号。
解决：强制要求每个子块的 clause_id 保留原编号，并在最终输出 JSON 里设置 original_ref 字段，专门用来记录原文所在页数和条款号。如果 Reduce 阶段发现子块编号冲突，就停止自动合并，转人工拼接。
5.4 长上下文截断，后半部分条款凭空消失
现象：生成的精简文书只有原文前半部分的内容，后半部分义务条款全部缺失，人工不细看根本发现不了。有一次处理并购合同，交割条款在后半段，差点被漏掉。
原因：把太长文本一次性喂给模型，模型受上下文窗口限制，可能只注意到前中段，后段直接被忽略。即便 DeepSeek 上下文大，多轮对话累积后的有效信息仍然会被压缩。
解决：严格走 Map-Reduce，不要跳步。Map 阶段每个子块独立摘要，Reduce 阶段定时统计已覆盖的条款数，和总条款数对比，一旦发现数量对不上，立即定位是哪个子块丢失。用程序保证每一段原文都被覆盖。
5.5 模型幻觉出一个原文没有的“免责条款”
现象：摘要里出现“在任何情况下，甲方不承担间接损失赔偿责任”，但原文从头到尾没有这句话。这种幻觉比遗漏更危险，因为它创造了全新的法律义务或权利。
原因：大模型在生成时会调用预训练时习得的知识来补全语义，法律文本里高频出现的免责条款很容易被它“脑补”出来。
解决：用抽取式方法做验证。把摘要里的高风险词（如“不承担”“免责”“赔偿”“违约金”）抽取出来，去原文里做全文检索；如果原文没有对应表述，就把这条摘要判定为幻觉。抽象式和抽取式不是对立的，这里用抽取式做“守门员”是常见做法。
6. 把摘要结果变成可复核的“证据链”JSON
6.1 设计带原文引用的输出 Schema
生成完摘要，我要做的就是把它变成可复核的 JSON。每一个 point 都必须带原文引用，而不是只有一个孤零零的总结句。我常用的 Schema 是：summary 作为精简版文书的主干，key_points 列表作为要点快速提取结果，risks 列表存放风险条款，每个风险条款引用原 clause_id 和原文片段。
{ "case_title": "XX项目采购合同", "summary": "甲方应向乙方支付合同总价100万元，交货后30日内付清；逾期按日0.05%支付违约金。", "key_points": [ {"point": "合同总价100万元", "ref": "第三条", "original": "合同总价为人民币壹佰万元整"} ], "risks": [ {"level": "high", "reason": "违约金比例高于市场常见水平", "ref": "第九条", "original": "乙方逾期交货的，每日按合同总价的千分之五支付违约金"} ] }这样的输出既适合交给律师人工审核，也适合后续程序自动比对。不要把模型输出直接当作交付物，中间一定要经过这一层结构化。
6.2 用实体匹配自动回检“法律效力等效”
对于回检，我写了一个简单的实体匹配函数，专门提取金额、日期、主体，然后对比原文集合和摘要集合：
import re def extract_legal_entities(text): entities = set() entities.update(re.findall(r"[￥¥]?\d+(?:,\d{3})*(?:\.\d+)?[万亿元百千万]?", text)) entities.update(re.findall(r"\d{4}年\d{1,2}月\d{1,2}日", text)) entities.update(re.findall(r"[甲乙丙丁]方", text)) return entities def check_preservation(original_text, summary_text): orig = extract_legal_entities(original_text) summ = extract_legal_entities(summary_text) missing = orig - summ added = summ - orig return {"missing": missing, "added": added, "ok": len(missing) == 0 and len(added) == 0}这个函数很简单，但对常见错误特别有效。missing 表示原文有但摘要没有，说明漏了关键信息；added 表示摘要新出现了原文没有的实体，可能是幻觉。跑完后，missing 和 added 为空的摘要才进入交付清单，其他的标黄。
6.3 人工复核的节奏与经验
自动校验能挡住大部分问题，但法律摘要不能全自动交付。我最后的做法是生成一版“高风险差异报告”，把摘要中所有和原文不一致的实体、情态动词、条款编号差异列成表，人工只需要看这张表，而不是逐条读回原文。平均下来，一份几十页的合同摘要，检校验只需十几分钟。
这个方案跑通后，我最大的教训是：不要迷信模型表现。我见过太多团队把工作量压在调 Prompt 上，却不在乎解析层和校验层。结果模型输出改对了，PDF 解析还是把合同切成碎片。做这类智能摘要，真正要磨的是流程，而不是某一环的“玄学”。希望这个思路能帮你在做 DeepSeek 法律文档智能摘要时少走弯路，也欢迎你把自己的踩坑经验整理出来，一起把这条链路的最后几公里补得更实。
本文还有配套的精品资源，点击获取
