用LED与LongT5生成长篇判决书摘要

可视化演示

长文档处理难点

书评家老周面对那本 500 页的判决书，双手一摊：一次只能摊开两三页，怎么办？普通 AI 模型比他更惨——受上下文窗口限制，一次只能读 512 或 1024 个 token，也就是几百个汉字。一篇判决书动辄一两万字，模型想读全文，就像让一个只能摊开两三页的人读完整个书架，只能把书撕碎、分段读、再强行拼凑，结果上下文信息大量丢失。

就算模型窗口强行扩大，新的麻烦又来了：Transformer 的自注意力机制要求每个字和整本书所有字两两“打招呼”，计算量随长度平方暴涨。老周读书好歹一页页翻，模型却是让所有页码互相递纸条，一万字就是一万乘以一万张纸条，根本递不过来。更扎心的是，判决书里真正的干货——裁判结果、关键金额——往往只占全文不到 1%，大部分篇幅是程序性叙述，信息分布极度稀疏。

这就是长文档处理的核心矛盾：窗口不够大，装不下；窗口硬撑大，算不动；就算算得动，重点还藏得深。LED 这类模型的出场，正是要同时解决这三座大山。

老周悟出的道理正在于此：与其硬背整本书，不如训练“摊开一页只看邻页”的读法，配合关键书签，就能把 500 页高效读完——这正是 LED 的出发点。

LED模型原理

老周的读法升级了：每摊开一页，他先扫一眼书页上贴的红色书签——比如“判决如下”“本院认为”这些位置，再细读窗口内的邻页内容。这样一来，无论翻到哪一页，心里都装着全书最要紧的几个锚点。LED（Longformer Encoder-Decoder）就是把这套读法落地的模型。

LED 把 Longformer 的稀疏注意力搬进了编码器-解码器架构：编码器负责“读”超长的判决书输入，用滑动窗口加全局注意力处理几万字；解码器负责“写”摘要，用标准注意力逐个生成输出 token。滑动窗口让每个字只和周围 w 个字交流，复杂度降为线性；而少数被指定为全局注意力的 token——通常是 [CLS] 标记、段落首 token、关键实体——能“看见”全文，也能被全文“看见”，相当于书签页。

实际操作中，窗口大小 w 常取 512，全局 token 占比约 1%~2%。比如在判决书场景，把“判决如下”后面的裁判结果设为全局 token，模型生成的摘要就大概率不会漏掉最终结论。注意力机制的数学内核，依然是那个经典的“问题找答案”公式。

老周这套“窗口扫读加书签锚定”的读法，让 LED 在一万五千字的判决书上也能游刃有余。但另一位书评家 LongT5 提出了不同的意见：书签虽好，贴起来费劲，不如让每章自己选个班长。

LongT5特性

LongT5 是 Google 推出的另一位书评家，它读判决书的方式更省事：不手动贴红色书签，而是每读一小段就临时指定一个“班长”，由班长汇总组员意见，再代表全组去和其他段落交流。这种机制叫做转瞬全局注意力（transient global attention）：每个局部块临时选出一个 token 充当信息汇聚点，块内消息先汇总到班长，班长之间再互相沟通。

在架构上，LongT5 把 T5 的注意力替换成了 Longformer 风格，并设计了与之配套的预训练任务——类似 PEGASUS 的“摘要句遮蔽”：训练时把文档中的重点句子挖掉，让模型学会补全，相当于书评家练习“看到一段就猜这段的核心句”。相比 LED，LongT5 不需要预先挑好全局 token，实现更简单；在书籍、科学论文等长文摘要基准上，LongT5 的整体表现常常优于 LED。

但选型不能只看榜单：LED 的全局 token 是“手动指定”的，这种可控性在强结构任务里是巨大优势——判决书的“裁判结果”必须覆盖，你可以直接把它钉成书签；LongT5 的班长是自动选的，省心但不可控。两个模型都能处理 16384 token 以上的输入，对万字判决书都绰绰有余，差别在于你更想要“可控的重点”还是“自动的均衡”。

两位书评家各有绝活，但无论用谁，要写出合格的判决书简介，老周还得多了解判决书本身的“八股”结构——毕竟摸清骨架，才知道书签该贴哪儿。

判决书结构解析

判决书可以说是法律界的“八股文”，格式高度模板化。老周写书评前不会从头翻到尾，而是先看目录结构：首部写着法院名称、案号、当事人身份；随后是原被告的起诉与答辩事实；接着是“本院查明”和“本院认为”的裁判理由；最后落在“判决如下”的裁判结果。这四个板块就像书的四章，各有各的用处。

做摘要之前，先把判决书按结构切块，是提升质量的关键一步。你可以把“裁判结果”和“本院认为”区域标记出来，让它们在模型中充当全局注意力 token；也可以在输入中插入结构标记，比如 <当事人>、<争议焦点>、<裁判结果>，让模型学会按要素组织摘要。这样的“要素式摘要”能直接回答律师最关心的问题：当事人是谁、什么案由、法院怎么判。

结构化的另一个好处是让解码更有的放矢。摘要生成本质上是逐 token 的翻译过程——把判决书“翻译”成一两百字的简介，每一步生成都依赖已经写出的前缀和整篇原文。理解了结构，模型就知道“裁判结果”该放在摘要的哪个位置，而不是把“本院认为”的论证过程原样搬进摘要。

老周摸清了判决书的四章结构，书签贴得精准，摘要的骨架立刻立起来了。但书评写完了，怎么知道质量行不行？他需要两个帮手：一个机械的“数数员”，一个较真的“事实核对员”。

摘要质量控制

老周写完书评初稿，先交给机械评分员ROUGE过一遍。这位评分员的方法很朴素：把老周的简介和标准答案都切成一个个小短语，数一数有多少短语重合。重合越多，分数越高。ROUGE-1 比单个词，ROUGE-2 比相邻两个词，ROUGE-L 比最长公共子序列，各有各的算法。

但 ROUGE 的缺陷在判决书场景里格外致命：它只比字面，不比事实。把“判决被告赔偿十万元”写成“判决被告赔偿十五万元”，字面高度重合，ROUGE 照样给高分；反过来，“驳回上诉”和“维持原判”意思几乎一样，字面却不重叠，ROUGE 分低得冤枉。法律摘要容不得这种“形似神非”，所以必须配上第二道关卡：事实一致性检测。

事实一致性检测通常用 NLI（自然语言推理）或问答式验证：把摘要里的关键实体——人名、金额、案号、刑期——逐个抽出来，和原文交叉核对。同时还要控制压缩率，一篇 2 万字的判决书压到 500 字是 4% 的压缩率，压得太狠就会丢掉“利息计算方式”这类细节，压得太松又失去了摘要的意义。通常 3%~8% 是经验区间，具体取决于下游是给法官快速浏览还是给律师深度检索。

有 ROUGE 数字数、事实核对员盯金额，老周的书评终于敢交稿了。不过他还缺最后一步：把 OCR 扫描件里的乱码、页眉、空行收拾干净——书稿太脏，再好的书评家也无从下笔。

法律文本处理

老周拿到手的判决书原稿，常常是从扫描件 OCR 出来的，页眉带着法院名，页脚压着案号，中间还混着乱码和全半角标点。他得先做一番“整书”工作：清洗 OCR 噪音，去掉重复页眉和案号，统一全半角符号，再按判决书的结构板块切块，避免把“本院认为”拦腰截断。

切块之后是“法言法语”适配。法律文本里“驳回”“不予支持”“缓刑”这些词，字少义重，token 化时要保证“判决如下”这类关键短语不被切开；训练数据里要多保留原判决书的措辞习惯，让模型学会用严谨的法言法语写摘要，而不是口语化的“法院觉得不对”。条件允许的话，还可以在输入里拼接结构标记，让模型一眼认出每个板块的职责。

落地部署时，硬件和工程细节同样重要。LED 在 16384 token 输入下推理，GPU 显存消耗不小，可以用 vLLM 加速推理、用 INT8 量化省显存；batch 内按长度 padding 到 8 的倍数，能明显提升吞吐。实践中还有一个高效的组合拳：先用抽取式方法从判决书里挑出最关键的句子作为候选，再让 LED 或 LongT5 对候选做生成式润色——既保证事实来自原文，又比直接端到端生成快不少。

老周把书稿整理干净、备好评分员和核对员，终于能批量给整柜的判决书写简介了。LED 与 LongT5 这两套读法，配上结构解析和质量把关，一套完整的判决书摘要生产线就此打通。

AI 应用场景

Python 演示

# -*- coding: utf-8 -*-"""简化版判决书摘要器: 用全局重点词加权加局部词频, 模拟 LED 稀疏注意力."""import refrom collections import Counter  class JudgmentSummarizer:    """对每个句子做局部词频打分, 并对命中重点词的句子加分."""     def __init__(self, top_k=5):        self.top_k = top_k        self.global_kw = ["判决如下", "本院认为", "依照", "原告", "被告", "驳回"]     def _split_sentences(self, text):        parts = re.split(r"(?<=[。！？；])", text)        return [p.strip() for p in parts if p.strip()]     def _tokenize(self, text):        return re.findall(r"[\u4e00-\u9fa5]{2,}", text)     def summarize(self, text):        sentences = self._split_sentences(text)        word_freq = Counter()        for sent in sentences:            word_freq.update(self._tokenize(sent))        for word in self.global_kw:            word_freq[word] = max(word_freq.get(word, 0), 5)        scored = []        for sent in sentences:            words = self._tokenize(sent)            score = sum(word_freq.get(w, 0) for w in words) / max(len(words), 1)            score += min(len(sent), 120) / 120.0            if any(kw in sent for kw in self.global_kw):                score += 2.0            scored.append((score, sent))        scored.sort(key=lambda x: -x[0])        return "".join(sent for _, sent in scored[: self.top_k])  if __name__ == "__main__":    judgment = (        "原告张三诉被告李四民间借贷纠纷一案，本院受理后依法适用简易程序公开开庭审理。"        "原告称被告于2021年3月向其借款十万元并出具借条一张。"        "被告辩称借款已经偿还，但未提供还款凭证。"        "本院认为，借条真实有效，被告主张还款但未举证，应承担不利后果。"        "依照《中华人民共和国民法典》相关规定，判决如下：被告李四于本判决生效之日起十日内偿还原告张三借款十万元。"        "案件受理费由被告负担。"    )    summarizer = JudgmentSummarizer(top_k=3)    summary = summarizer.summarize(judgment)    print("原始判决书长度: ", len(judgment))    print("生成摘要: ")    print(summary)

1. self.global_kw = ["判决如下", "本院认为", "依照", "原告", "被告", "驳回"]这些词相当于 LED 的全局注意力 token，命中就加权，保证裁判结果不被漏掉。
2. parts = re.split(r"(?<=[。！？；])", text)按句号感叹号等边界切分句子，对应预处理阶段的结构切块。
3. word_freq.update(self._tokenize(sent))统计全文档词频，作为“局部窗口内重要性”的近似信号。
4. score = sum(word_freq.get(w, 0) for w in words) / max(len(words), 1)句子得分等于词频均值，高频词的句子更像“本院认为”这种核心句。
5. if any(kw in sent for kw in self.global_kw): score += 2.0命中全局重点词的句子直接加分，模拟全局注意力的锚定效果。
6. scored.sort(key=lambda x: -x[0])按得分降序排序，然后取前 top_k 句拼接成摘要。
7. return "".join(sent for _, sent in scored[: self.top_k])把选中的句子按原文顺序拼回一段通顺的摘要，保证要素齐全。

常见误区

面试题