企业官网建设流程全解析

简介：DeepSeek法律文档智能摘要与要点快速提取方案是一份446页的深度技术文档，面向法律科技从业者、NLP算法工程师及法律信息化研究人员，系统讲解如何借助DeepSeek实现法律文本的抽象式摘要与法律效力保留。资源为单个PDF文件，大小12.47MB，含50个大章节，支持目录跳转与书签大纲定位，阅读体验完整。内容从前18章即可看出覆盖链路之全：从行业痛点与价值定位、多层级语义分割、法律术语图谱构建、预训练数据清洗、法律领域模型选型、抽象式生成原理、关键信息抽取、法律效力要素标注体系、小样本标注与数据增强，到训练数据划分、混合损失函数、超参数调优、训练监控及分布式训练等，系统完整。文档还深入微调策略对比、模型初始化配置等内容，既讲原理也重工程落地。已有141人学习，适合用于技术选型、方案设计及项目参考。

1. 法律文档智能摘要为什么难：DeepSeek方案的定位与价值

法律行业有个持续存在的痛点：合同、判决书、法规动辄几十上百页，人工精读一轮要几个小时，批量案件审查时效率直接卡死。更麻烦的是，摘要不能只追求“短”——关键条款、权利义务、金额时间一旦漏掉或改写走样，摘要就失去法律参考价值，甚至引发风险。DeepSeek法律文档智能摘要方案要解决的就是这个矛盾：基于抽象式文本生成把长文档压缩成保留法律效力的精简文书，再用法律效力校验规则库兜住关键要素不丢。整个方案覆盖文本解析、术语图谱、模型训练、蒸馏加速到容器化部署的完整链路，适合法律科技产品经理、NLP工程师和法务信息化团队照着复现。这套方案不是通用摘要工具的简单套壳，而是围绕法律文本的专业性做了从数据清洗到评估体系的深度适配，下文按我实际拆解的顺序逐层展开。

2. 从文本解析到语义理解：结构化分割与术语图谱的落地路径

2.1 多层级语义分割：规则引擎与深度学习的混合方案

法律文档的结构化解析是所有后续处理的地基。物理层级、段落层级、条款层级如果切分不清，后面的实体抽取和摘要生成都会跟着跑偏。文档的设计是五级解析：字符级、词汇级、句子级、段落级、篇章级，自下而上逐层切分，对应 NLP 从字符规范化到篇章理解的完整链路。落地时真正的难点在于怎么切得准，我把它拆成物理结构切分和语义结构切分两层来看。

物理结构切分靠规则引擎最靠谱。法律文档格式规律性强，“第一章”“第一条”“（一）”这类编号体系一抓一个准，规则层擅长处理加粗、缩进、编号样式，可以一次性把规范文档的标题层级和条款边界划清。语义结构切分则是规则解决不了的，比如合同里“鉴于”条款和“定义条款”的边界，编号上看不出来，必须靠语义模型判断段落主题角色。文档里的混合式方法就是把两者串起来：规则引擎先把能确定的物理边界定死，深度模型再处理规则覆盖不到的区域，最后用结构验证组件做一致性校验，修正层级矛盾和边界错误。

工程上怎么落地？我一般先写一个规则分发器，按“第X章/第X条/第X款/（X）”的编号正则做初切，得到候选节点列表；再把初切结果送进一个微调的序列标注模型，给每个候选节点打上语义角色标签，类似“定义条款”“权利义务条款”“违约责任条款”；最后做一次父子关系规整。这里容易踩坑的是，规则引擎切出的物理边界与语义边界经常不重合，格式不规范时标题编号会错乱，强行依赖格式标记切出来的边界就是错的，必须让深度模型根据上下文重新对齐语义段落。

import re CHAPTER = re.compile(r"^第[一二三四五六七八九十百]+章", re.MULTILINE) CLAUSE = re.compile(r"^第[一二三四五六七八九十百千\d]+条", re.MULTILINE) ITEM = re.compile(r"^（[一二三四五六七八九十\d]+）", re.MULTILINE) def split_legal_structure(text): # 第一轮：规则初切，得到候选节点 nodes = [] for m in CHAPTER.finditer(text): nodes.append({"level": 1, "start": m.start(), "title": m.group()}) for m in CLAUSE.finditer(text): nodes.append({"level": 2, "start": m.start(), "title": m.group()}) for m in ITEM.finditer(text): nodes.append({"level": 3, "start": m.start(), "title": m.group()}) nodes.sort(key=lambda x: x["start"]) # 第二轮：语义角色标注，给候选节点打上法律语义标签 # role_labels = semantic_model.batch_predict(texts) # nodes[i]["role"] = role_labels[i] return nodes

规则部分把三个粒度分开收集，CHAPTER、CLAUSE、ITEM 对应章、条、款三级编号，nodes 按起始位置排序后就是完整的候选结构。注意第二轮的语义角色模型输入不能只取编号标题，要把节点开头的一小段正文一起带进去，模型才能判断它承担的是定义、义务还是违约责任角色。文档里强调的五级框架，本质上是希望字符级清洗、词汇级术语识别、句子级长句边界、段落级主题归类、篇章级层级建模五个粒度互相校验。字符级如果漏做，全角冒号和半角冒号混着，后面匹配“第X条”就翻车了。

句子级边界检测在判决书中尤其容易出错——判决书里的“本院认为”经常是一整段几百字的长复合句，句号只表示中间停顿，语义上并没有结束。处理这类句子，单纯依赖句法解析不行，要在句子边界模型里加入法律逻辑标记，比如“鉴于”“据此”“综上”这类转折词作为边界候选项。段落级语义归类则决定了摘要阶段保留什么、丢弃什么，分类粒度越细，摘要内容越精准。

2.2 法律术语图谱：从实体抽取到关系推理的知识底座

多层级分割解决的是文本结构问题，术语图谱解决的是语义理解问题。法律术语的精确性和关联性远超普通领域文本。“善意取得”“表见代理”这些词，在通用 NLP 模型眼里只是普通名词，法律场景里它们背后是一整套构成要件。文档把术语图谱拆成四个环节：核心构成要素、抽取与规范化、关系与推理规则、存储与查询。

抽取与规范化这一步最容易被忽略。同一概念在不同文书里表述差异很大：“甲方”与“委托人”、“权利人与所有权人”，不规范化处理，图谱就是一堆散点，关系抽取根本找不到连接。常见做法是维护一张术语映射表，把同义表述映射到规范词条。映射表的构建可以用预训练模型做初次对齐，再让法律专家抽检修正，全自动的话容易把“解除合同”和“终止合同”这类有实质区别的概念错误合并。

关系抽取输出的是术语节点之间的边，包括上下位关系、同义关系、因果关系和蕴含关系。文档专门提到推理规则的构建——例如“善意取得”认定需要同时满足“受让人善意”“合理价格转让”“动产已交付或不动产已登记”等要件。术语图谱如果只存节点和边，不挂接规则条件，摘要生成时只能识别到术语本身，没法判断这个术语是否构成一个完整的法律事实。给节点挂接规则条件后，图谱就从静态字典变成了可推理的知识结构。

存储环节用图数据库比关系型数据库顺手得多。查询“某条款引用了哪些术语”“某术语在哪些判决中出现”这类多跳问题，图数据库一条查询语句就能完成，SQL 要写好几层 JOIN。文档没有限定具体图数据库产品，实际选型时看一下团队技术栈，Neo4j 生态成熟，JanusGraph 适合大规模分布式，小规模场景用 NebulaGraph 起步也够用。

2.3 关键信息识别：实体、关系与事件的协同抽取

文档把法律文档的关键信息识别切成三个模型：实体抽取、关系抽取、事件抽取，并强调三者协同。这是信息抽取领域经典三件套，但在法律场景里每个部分都有特殊约束。

实体抽取主要抓当事人、法律条款、时间和金额四类。金额和时间是机器最容易出错的对象，尤其是“自合同签订之日起三十日内”这类混合时间表述。规则加模型的双层校验比较稳——规则保证格式正确，模型保证语义边界。条款实体最好用结构化表示，把“《中华人民共和国民法典》第五百七十七条”拆成法典名加条款号，后续做引用校验会省很多事。

关系抽取关注“谁对谁负有义务”“谁与谁存在合同关系”，输出三元组（主体，谓词，客体）。事件抽取聚焦“违约”“侵权”“判决”等法律事件，输出事件类型、参与者、时间节点和处理结果。协同机制的关键是把三元组和事件作为摘要生成阶段的输入条件，而不是让摘要模型自己从原文里找关系。文档反复提到“法律逻辑链”，就是靠实体、关系、事件三层结果组装出来的。逻辑链越完整，摘要里的“案件事实”部分越可信。

实际实现时建议把三个模型串联成管道（pipeline）而不是做联合抽取。联合抽取在法律长文本上的收敛速度比较慢，管道式虽然多一次特征传递，但每一层都能单独调优和排查问题。比如关系抽取效果差时，可以先回头检查实体识别的边界是否准确，不用动整个模型。

3. 抽象式摘要生成：模型选型、损失函数与训练调优

3.1 抽象式与抽取式的本质差异：法律文本压缩的范式选择

抽取式摘要是从原文直接抽句子拼起来，优点是忠实，不会无中生有，缺点是冗余度高、句子间缺乏衔接、压缩比有限。抽象式摘要是生成模型重新组织语言，优点是压缩彻底、表达更接近规范法律文书，缺点是改写过程中可能引入与原文不一致的信息。法律场景选抽象式，本质上是接受了“可控改写”这个前提，换取更高的压缩质量。

为什么法律场景值得冒这个风险？因为法律文本有大量背景陈述和套话需要压缩，而核心的权利义务表述必须保留。抽取式只能保留原句，没法把三句话压成一句；抽象式通过 Seq2Seq 加注意力机制，在编码阶段理解全文，在解码阶段生成新句子。文档里“从表层信息到深层法律要素的转化”这句话，说的就是模型学会区分哪些词对应法律要素、哪些是阐述性内容可以丢弃。

但抽象式的风险是实打实的。原文“乙方应于收到通知后5日内支付违约金”，生成“乙方应当在收到通知后五天内支付违约金”问题不大；一旦生成“乙方应在收到通知后5日内退还违约金”，法律后果完全变了。文档给出的对策是语义等价性验证：生成之后做反向核对，检查主体、行为、金额、期限等关键要素是否与原文一致。这个验证可以走规则库，也可以用一个专门的匹配模型，实际部署时我建议两层都上，规则层抓硬伤，模型层抓语义偏移。

温度参数在这里也起作用。解码时温度调高，生成内容更多样、语言更流畅，但关键 token 的概率峰值会被压低；温度调低，生成更保守、更贴近原文，但句子可能生硬。法律摘要建议解码温度控制在 0.7 到 0.9 之间，关键要素密集的判决书部分可以单独把温度调低一档，这是我在调参时确认有效的做法。

3.2 混合损失函数：面向法律摘要的工程实现

模型训练的核心环节之一是损失函数设计。普通文本生成用交叉熵损失就够了，但法律摘要任务对关键要素保留有硬性要求。文档提出的混合损失由三部分组成：生成损失、要素覆盖损失、条款引用准确度损失。下面用 PyTorch 做一个简化实现：

import torch import torch.nn.functional as F def mixed_loss(logits, target_ids, key_mask, ref_ids): # logits: (batch, seq_len, vocab_size) # target_ids: (batch, seq_len) ce_loss = F.cross_entropy( logits.view(-1, logits.size(-1)), target_ids.view(-1), ignore_index=-100 ) # 要素覆盖损失：关键token的预测概率加权 probs = F.softmax(logits, dim=-1) target_probs = probs.gather(-1, target_ids.unsqueeze(-1)).squeeze(-1) key_probs = (target_probs * key_mask).sum() / (key_mask.sum() + 1e-8) coverage_loss = -torch.log(key_probs + 1e-8) # 条款引用准确度损失：ref_ids 标记条款编号位置 ref_probs = (probs * ref_ids.unsqueeze(-1)).sum(-1) ref_loss = torch.where( ref_ids > 0, (1 - ref_probs) ** 2, torch.zeros_like(ref_probs) ).mean() return ce_loss + 0.3 * coverage_loss + 0.2 * ref_loss

代码里cross_entropy是基础生成损失，key_mask标注了原文中必须保留的关键 token 位置，比如金额、日期、条款编号，coverage_loss强制模型在这些位置给出较高概率。ref_ids是一个简化模拟，真实场景中需要根据条款编号建立位置映射表。加权系数 0.3 和 0.2 要靠验证集实验确定，不是拍脑袋定值。

权重选择有一个原则：合同类文书，条款引用准确度损失的权重应该更高；判决书类，要素覆盖损失的权重更高。原因很直接——合同摘要里条文引用错了，整个风险分配判断就错了；判决书摘要里事实要素漏掉了，法律依据就悬空。文档里说的加权融合策略，核心就是先明确“哪种错误更致命”，再定权重方向。

3.3 超参数调优：学习率、Batch Size与早停策略

预训练模型微调的超参数选择，在法律长文本场景下有特殊之处。学习率方面，通用文本摘要常用的 5e-5 起步，法律场景建议压到 2e-5 到 3e-5，长文本训练时梯度更新本身就不稳定，学习率再高很容易出现 loss 震荡。配合 warmup ratio 0.1，前 10% 的训练步数做线性预热，让模型先在低学习率下稳定下来。

# 简化版训练配置示意 config = { "learning_rate": 2.5e-5, "warmup_ratio": 0.1, "batch_size": 4, "gradient_accumulation_steps": 8, "max_epochs": 5, "early_stop_patience": 3, "eval_metric": "rouge_l" }

batch_size只有 4，是因为法律文档单条样本的 token 数动辄好几千，显存占用远超普通文本。gradient_accumulation_steps=8把等效 batch size 变成 32，保证训练稳定性。早停不能只看验证 loss，生成类任务中验证 loss 和生成质量经常不同步。我的经验是同时盯验证 loss 和 ROUGE-L：验证 loss 上升但 ROUGE-L 还在涨，说明模型在生成层面仍有改善空间，不要停；两者同时恶化，大概率模型开始过拟合，该停就停。

Batch Size 还有一个隐藏影响——它决定了梯度估计的噪声水平。法律文档里不同案子的表述差异极大，batch 太小梯度方向抖动厉害，batch 太大又可能把长尾的法律事实平滑掉。梯度累积给了我们一个灵活调节的空间，先固定物理 batch 为 4，再通过累积步数从 4 到 32 之间做网格搜索，比直接改物理 batch size 省显存得多。

4. 模型压缩与推理加速：蒸馏、量化与ONNX落地

4.1 知识蒸馏：从教师模型到学生模型的领域适配

模型摘要质量上去了，部署成本下不来时，蒸馏就是那个“后悔药”。蒸馏的思路很直接：训练一个更大的模型当教师，再训练一个小模型当学生，让学生学习教师的输出分布。文档里法律领域蒸馏设计有几个点值得注意。

教师模型应该选用法律域预训练的大模型，而不是通用模型，因为教师输出的分布本身就包含领域语义。学生模型架构可以比教师小很多，但要保持相同类型的 Transformer 层级结构，否则输出维度对不上，蒸馏损失没法计算。蒸馏损失除了常规的 KL 散度（教师软标签与学生 logits 的差异），还要加上任务损失（学生 logits 与真实标签的差异）。文档里提到“法律语义保留导向”的蒸馏损失组件，本质是把关键要素的 token 单独拿出来算 KL，确保重要信息不掉。

温度参数在这里是另一个坑。温度越高，教师输出分布越平滑，学生看到的信息越丰富，但目标 token 的峰值被压低，学生学到的更多是全局语感而不是精确预测。文档给出温度范围 4 到 8 需要网格搜索，我实测下来：准确性导向的任务温度偏低，生成流畅度导向的任务温度偏高。同一份法律摘要任务里，判决书事实部分用低温，说理部分用高温，效果会好过一个全局固定温度。

4.2 量化蒸馏：低精度模型的压缩与语义保留

蒸馏解决的是模型体积，量化解决的是推理速度。INT8 量化能把模型显存占用降到原来四分之一左右，推理速度提升两到三倍，但直接做后训练量化（PTQ）在摘要任务里效果通常不理想。量化误差会累积到生成结果里，摘要内容容易出现缺字或重复。

文档给出的方案是把量化和蒸馏结合，做量化蒸馏：教师模型保持 FP16 精度，学生模型在训练时就模拟 INT8 量化（fake quant），蒸馏损失同时约束量化误差和语义偏移。这样训练出来的学生模型，推理时直接走 INT8 推理，不需要单独做校准。量化时机也关键——先蒸馏后量化，和量化蒸馏一起做，效果差别很大。前者容易在量化阶段丢失语义，后者在训练过程中就把量化噪声塞进模型，让模型学会抵抗误差。

实战中还有一个微调策略值得尝试：混合精度量化。注意力层对分布变化敏感，保持 FP16；前馈网络层（FFN）对量化的容忍度高，可以压到 INT8。这个策略能在大幅加速的同时，把条款引用准确度的损失控制在可接受范围。文档在量化蒸馏评估一节里反复强调，不要只看整体 ROUGE，要单独看条款引用准确率这个法律专用指标。

4.3 ONNX转换与推理引擎优化：从PyTorch到生产环境

蒸馏、量化做完，模型要落到生产环境，ONNX 转换是绕不开的一步。PyTorch 模型直接服务推理性能不理想，ONNX Runtime 做了大量图优化，常见场景下比 PyTorch eager 模式提升 1.5 倍以上。转换的关键配置如下：

import torch # 构造一个与训练时同分布的虚拟输入 dummy_input = torch.randint(0, 32000, (1, 512)).long().to("cuda") torch.onnx.export( model, dummy_input, "legal_summary.onnx", opset_version=17, input_names=["input_ids", "attention_mask"], output_names=["logits"], dynamic_axes={ "input_ids": {0: "batch", 1: "seq_len"}, "attention_mask": {0: "batch", 1: "seq_len"}, "logits": {0: "batch", 1: "seq_len"}, } )

dynamic_axes声明动态轴，否则模型变成固定长度输入。法律文本长短差异大，固定长度会浪费推理资源，短文档也要按最大长度 padding。opset_version=17是兼顾兼容性和新算子支持的选择。导出后建议用 onnxruntime 的session_options开启图优化级别，再做一次精度验证，确认导出前后输出差异在合理范围内。

推理引擎选型上，ONNX Runtime、TensorRT 和 OpenVINO 各有侧重。法律长文本场景下 TensorRT 加速效果最好，但首次转换时间长，适合生产环境一次性转换；ONNX Runtime 胜在稳定，跨平台部署最省心。低精度推理与法律语义保留的平衡，核心是分模块处理：嵌入层、注意力层保持高精度，FFN 层走 INT8。这个策略和前面量化蒸馏的结论一致，本质上都是让语义敏感模块避开量化误差。

5. 部署集成与常见问题排查：容器化、API与踩坑记录

5.1 模型服务的容器化与本地化部署

模型最终要跑成服务，容器化是最常见的做法。文档给出的镜像构建规范，核心是分层缓存：基础镜像放最底层，Python 依赖放中间层，模型文件和推理代码放最上层。这样依赖变化不触发全量重建，迭代速度能快不少。

FROM python:3.10-slim as base WORKDIR /app COPY requirements.txt . RUN pip install --no-cache-dir -r requirements.txt FROM base as runtime COPY ./app /app/app COPY ./models /app/models EXPOSE 8000 CMD ["uvicorn", "app.main:app", "--host", "0.0.0.0", "--port", "8000", "--workers", "2"]

--workers控制进程数，要参考推理服务单进程吞吐量来定。法律文档摘要不像普通接口那么轻量，每次请求要处理几千 token，单进程吞吐量可能只有每秒几次。workers 数设置过高，CPU 上下文切换反而拖慢整体延迟。Kubernetes 资源配置方面，requests 设保守值保证调度，limits 设上限值防内存泄漏拖垮节点。HPA 按 CPU 或 QPS 自动扩缩，法律文档处理是突发性负载，批量审查场景下 QPS 波动很大，HPA 冷却时间要调短一些，否则流量高峰来了服务还没扩容完成。

5.2 摘要服务接口的设计与调用规范

对外提供的摘要服务一般要设计两类接口：同步单文档摘要接口和异步批处理接口。同步接口适合单份合同或判决书的即席摘要，异步接口适合批量案件审查。文档在集成方案章节给出的数据交互格式，核心是统一 JSON Schema。下面是一个典型的同步接口请求响应格式：

POST /api/v1/summarize { "document": "合同原文内容...", "doc_type": "contract", "summary_ratio": 0.3, "options": { "preserve_clause_refs": true, "length_mode": "adaptive" } } Response 200: { "summary": "精简后的法律文本...", "clause_refs": [ {"clause_id": "第5条", "position": [123, 156], "status": "verified"} ], "confidence": 0.92, "task_id": "a3f9c2e7-..." }

summary_ratio是目标压缩比，doc_type决定走哪套摘要策略，合同、判决、法规各有侧重。clause_refs是条款引用的校验结果，status字段标记引用是否通过校验，confidence是模型对生成内容的置信度。异步批处理接口要额外加任务状态字段，调用方轮询进度，任务完成后再拉取结果。

错误处理与重试策略容易被忽略。文档里强调幂等性设计——同一条文档重复提交不能产生重复任务。批量场景下没有幂等性，重试机制会把任务队列打爆。接口层面还要区分两类错误：输入格式错误返回 4xx，模型推理失败返回 5xx。5xx 错误要支持退避重试，但重试次数要限制，法律长文本推理成本高，无限制重试会把资源池拖垮。

5.3 训练与推理踩坑记录：现象、原因与解决方案

这一节是血泪经验，按“现象 — 原因 — 解决”的格式记录我实际跑这个方案时踩过的坑。

现象一：loss 持续下降，但验证集 ROUGE-L 不涨反跌。排查后发现模型生成内容越来越长，套话变多，关键信息被稀释。原因是混合损失里要素覆盖损失的权重太低，模型只优化了生成流畅度，没有约束关键要素保留。解决方法是把 coverage_loss 的权重从 0.3 提到 0.5，重新跑一轮验证，ROUGE-L 立刻回升。

现象二：ONNX 导出后推理结果和 PyTorch 不一致。原因是动态轴的声明遗漏了 attention_mask，导致输入长度变化时注意力矩阵错位。解决方法是补全 dynamic_axes 后重新导出，结果对齐。这个坑很隐蔽，因为短文档和固定长度测试时看不出来，只有长文档触发动态路径时才暴露。

现象三：批量推理时 GPU 显存溢出。原因是不同长度文档混在同一个 batch 里，padding 填充量巨大。解决方法是按长度分桶加动态批次划分，长度相近的文档放进同一桶，显存占用和吞吐量都有明显改善。代码实现上，用 heapq 维护一个待处理队列，按文档长度排序后，贪心划分批次。

现象四：INT8 量化后条款引用准确度明显下降。原因是 attention 层直接做了量化，注意力分布对量化噪声太敏感。解决方法是只量化 FFN 层，保留 attention 层的 FP16 精度，精度和加速比达到平衡。

现象五：服务接口在高峰期偶发超时。原因是 HPA 扩容太慢，批处理队列堆积。解决方法是把 HPA 冷却时间从 300 秒调到 60 秒，同时加了一个基于队列深度的自定义指标，当队列深度超过阈值时提前扩容。

6. 长文本摘要的长度自适应控制：复杂度评分与滑动窗口技巧

从 5000 字到 5 万字，法律文档长度跨度极大。固定摘要长度必然顾此失彼——短文档被过度压缩，长文档又信息过载。文档给出的解法是文档复杂度评分加长度动态计算，这是我每次部署这套方案时都会单独拎出来调的一个环节。

复杂度评分主要考虑四个维度：文档总长度、条款与章节数量、术语密度（术语出现次数除以总词数）、条款引用次数。综合评分出来后映射到目标压缩比。代码示意如下：

def compute_doc_complexity(doc_len, term_count, clause_count, ref_count): # 长度得分，超过8000字按1.5封顶 len_score = min(doc_len / 8000.0, 1.5) # 术语密度加权 term_score = min(term_count / (doc_len / 1000.0), 1.0) * 0.4 # 条款和引用数量加权 clause_score = min((clause_count + ref_count) / 20.0, 1.0) * 0.3 return 0.5 + len_score * 0.2 + term_score + clause_score def adaptive_ratio(complexity): if complexity > 1.5: return 0.15 # 复杂文档压缩比更高 elif complexity > 1.0: return 0.2 return 0.3 # 简单文档保留更多细节

compute_doc_complexity返回的复杂度值大致落在 0.7 到 2.2 之间，再按阈值映射到压缩比。0.15、0.2、0.3 这几个阈值是我自己调出来的经验值，不同文档集需要重新做一次小规模搜索。如果复杂度超过 2.0，说明文档结构异常复杂，除了压摘要长度，还要检查解析阶段是不是漏了层级，别让解析错误背上摘要的锅。

长文本的另一个硬问题是输入长度超过模型窗口。滑动窗口是常用解法，窗口长度 1024，步长 256，重叠 25% 保证段落间语义连续。窗口之间的重叠部分在做语义分段时要用注意力机制把前后窗口的向量接起来，否则跨窗口的条款引用会断。从那以后，我每次跑这套长文本摘要流程时，都强制先算一遍复杂度评分，再核对窗口参数是否匹配，确认之后才进入模型推理。这套“先评分、再开窗”的习惯帮我避掉了不少长文档翻车的场景，希望帮到你。

本文还有配套的精品资源，点击获取