简介：一份面向自然语言处理与深度学习研究者的专业参考文献，聚焦文本自动摘要中的语义理解不充分、摘要语句不通顺和准确度不足等问题，提出包含改进词向量生成技术和生成式自动摘要模型的完整方案。方案在Skip-Gram词向量基础上引入词性、词频和逆文本频率特征，并基于seq2seq与自编码器结构融合注意力机制、GRU、双向及多层循环神经网络、集束搜索，在大规模中文短文本摘要数据集上验证并取得良好性能。资源为单份PDF文档，大小仅1.06MB，内容包含论文摘要、引言、模型原理、实验对比与结论，可直接下载阅读，也可作为课题研究、论文写作或算法复现的参考资料。已有282人学习下载，适合需要了解文本摘要前沿方法的研究者快速获取核心思路。
1. 先把问题定义清楚：文本自动摘要到底在解什么
一份五十页的尽调报告，给到分析师手上先看的是执行摘要，而不是从头读起。文本自动摘要要做的不是简单“砍掉一半字”，而是保留关键事实、数字和逻辑关系，这个需求在舆情监控、金融研报、客服工单、代码评审里一直存在。深度学习介入之前，摘要靠规则和统计特征，能跑但天花板很低；深度学习方法出现后，摘要从“挑句子”进化到了“写句子”，质量有了本质提升。
基于深度学习的文本自动摘要方案，指的是一整套从数据准备、模型选型、训练微调到推理评估的工程链路，而不是某一份模型文件或某个论文代码。方案通常覆盖两类任务：抽取式摘要从原文中挑出重要句子，生成式摘要让模型重新组织语言产出新文本。二者在事实准确性和语句流畅度上各有取舍，真实项目里还会按场景混合使用。下面按工程实践的顺序，把模型选型、训练管线、评估指标和调参细节展开讲。
2. 抽取式和生成式两条技术路线的选型逻辑
2.1 抽取式摘要为什么是“结构化打标”问题
抽取式摘要把“要哪几句”变成一个句子级别的分类或排序问题：对原文的每个句子打分，按分数选出Top-K拼成摘要。早期常见做法是TextRank这类图算法，不依赖标注数据，凭共现关系的重要性传播筛选句子，本质上是统计特征，对语义理解有限。深度学习介入后，主流做法是BERT加一个输出头：把每个句子编码成向量，接一个全连接层输出重要性分数，训练时用标注好的重要句作为监督信号。
抽取式的核心优势是结果可控。摘要里的每个词都来自原文，不会凭空捏造事实，这点在法律文书、病历摘要、风控报告里至关重要。缺点是摘要连贯性差，被选中的句子来自不同段落，拼在一起时主语跳跃、指代断裂，“该公司”“上述问题”这类词读起来很突兀。另外抽取式摘要的上限受限于原文本身的表达质量，如果原文写得啰嗦，摘要也很难精炼。
深度学习环境配置好之后，跑抽取式摘要的代价相对低。BERT编码一次原文拿到所有句子的表示，推理时只需要一次前向计算。数据需求也更宽松，因为本质上是一个二分类问题，哪怕只有几千条标记了“重要句”的弱标注数据也能训练。但如果任务是“把一段口语化的客服对话压成一句规范的话”，抽取式就做不到了，因为需要的词压根不在原文里，这时必须上生成式。
2.2 生成式摘要的模型选择：从RNN到BART、T5
生成式摘要走的是Seq2Seq路线，模型读入原文后逐词生成摘要。早期的BiLSTM+Attention结构能处理短文本，但长距离依赖和并行计算效率都不理想。Transformer解决了并行问题，但训练目标只是语言模型，直接用于摘要时生成质量不稳定。真正把摘要效果推到可用级别的，是BART和T5这类带降噪目标的预训练模型。
BART使用自编码和自回归混合的训练目标，把原文随机打乱、删除、替换后再复原，迫使模型学会理解句子结构。这个预训练方式和摘要任务天然契合，所以BART在新闻摘要、论文摘要等任务上长期是默认基线。T5把所有NLP任务统一成“前缀指令+输入文本”的文本到文本形式，切换任务时只需要改前缀。T5的优势是多任务灵活，但相同参数量下，专做摘要时BART通常略胜一筹。
实际选型我一般看三个条件：单文档还是多文档、是否要求实时、算力多少。单文档中文摘要，BART-base级别或mT5-small就能跑出可用效果；多文档摘要要考虑先做文档聚类或压缩再送进模型；实时性要求高的接口，生成式解码速度是瓶颈，每生成一个token都要一次前向传播，量一大就要考虑蒸馏成小模型。深度学习模型不是越大越好，线上环境里延迟成本往往比离线效果指标更关键。
2.3 混合式方案：抽取作为生成的前置过滤
现在许多生产环境里的摘要方案并不在抽取式和生成式里二选一，而是先抽取再生成，用抽取结果作为生成器的输入上下文。这一步能显著降低输入长度，同时减少生成器产生幻觉的概率。常见做法是用一个轻量抽取模型挑出Top-5句子，拼成不超过512个token的候选文本，再交给BART去改写。
选择这个方案的原因很直接：生成式模型输入长度有限，直接把整篇5000字文章塞进去，光截断就会丢信息；而抽取式模型虽然流畅度差，但擅长定位关键信息。把定位的工作交给抽取，把改写的工作交给生成，各干各擅长的部分。代价是引入了一个额外处理阶段，推理延迟增加，离线评测时要单独测两个模型串联后的误差传播。数据量不足时，混合式也比纯生成式更稳，因为生成器只需要学会“改写”，不用学会“大海捞针”。
| 维度 | 抽取式（BERT+打分） | 生成式（BART/T5微调） | 混合式（抽取+生成） |
|---|---|---|---|
| 数据需求 | 千级带标注句子即可 | 万级文档-摘要对 | 千级标注+万级弱监督可拆开准备 |
| 事实准确度 | 高，句子来自原文 | 中高，存在幻觉风险 | 高，幻觉被前置过滤压制 |
| 语句流畅度 | 中，拼接感明显 | 高，接近人工写作 | 高，改写环节保证流畅 |
| 推理时延 | 低，一次前向 | 高，自回归逐词生成 | 中高，两次前向 |
| 适合场景 | 法律、医疗、风控 | 新闻、商品评论、研报 | 长文档、多文档、实时性要求中等 |
3. 从数据到推理：搭一条能跑通的摘要训练管线
3.1 数据清洗与长度截断，摘要管线里最容易被忽略的一环
摘要任务的数据不只是“原文+摘要”两列，清洗步骤直接决定训练能否收敛。首先要剔除重复段落和空行，统一全半角符号；然后做句子边界识别，英文按句号切分，中文要同时处理句号、问号、叹号，引号后半部分不能作为断句点。第二步是过滤原文与摘要重合度过低的样本，这个操作防止模型学到“摘要与原文无关”的错误模式，实操中我常用ROUGE-L做快速过滤，小于0.2的样本直接丢弃。
长度截断是另一个关键预处理。BART-base支持的最大输入长度是1024个token，但训练时我会把输入限制在512，输出限制在128到256之间。超过512的部分不直接砍掉，而是按句子边界优先保留首尾内容，因为摘要通常更看重文章开头引入的事实。这种方法能在信息密度和模型容量限制之间取得平衡。下面的Python代码展示了一次标准的数据预处理，使用HuggingFace的tokenizer：
from transformers import AutoTokenizer import json tokenizer = AutoTokenizer.from_pretrained("facebook/bart-base") def truncate_by_sentence(text, max_tokens=512): sentences = text.replace("\n", "。").split("。") truncated, current_len = [], 0 for sent in sentences: sent_len = len(tokenizer.encode(sent, add_special_tokens=False)) if current_len + sent_len > max_tokens: break truncated.append(sent) current_len += sent_len # 兜底：如果单句就超长，只能硬截断 if not truncated: return tokenizer.decode(tokenizer.encode(text, truncation=True, max_length=max_tokens)) return "。".join(truncated) + "。" def build_dataset(input_path, output_path): samples = [] with open(input_path, "r", encoding="utf-8") as f: for line in f: item = json.loads(line) src = truncate_by_sentence(item["document"]) tgt = truncate_by_sentence(item["summary"], 128) samples.append({"document": src, "summary": tgt}) with open(output_path, "w", encoding="utf-8") as f: for s in samples: f.write(json.dumps(s, ensure_ascii=False) + "\n")这里的truncate_by_sentence先按句号切分句子，逐句计算token数，超过上限就停止拼接，避免在句子中间断开的语义残缺问题。硬截断兜底只处理单句超长的极端情况。build_dataset把清洗后的样本按要求写成JSON Lines格式，方便后续直接交给训练框架。注意这里没有做分词，交给模型的tokenizer统一处理，保证不在预处理阶段引入不一致的切分结果。
3.2 用HuggingFace Trainer微调BART的最小训练脚本
数据准备好之后，训练阶段直接用HuggingFace的Seq2SeqTrainer可以省掉大量手写训练循环的代码。下面是我在单卡GPU上微调BART做中文摘要的最小可运行脚本，依赖transformers和datasets两个库：
from transformers import ( AutoTokenizer, BartForConditionalGeneration, Seq2SeqTrainingArguments, Seq2SeqTrainer, DataCollatorForSeq2Seq ) from datasets import load_dataset model_name = "facebook/bart-base" tokenizer = AutoTokenizer.from_pretrained(model_name) model = BartForConditionalGeneration.from_pretrained(model_name) raw_dataset = load_dataset("json", data_files="train.jsonl", split="train") def preprocess(examples): inputs = tokenizer( examples["document"], max_length=512, truncation=True, padding="max_length" ) labels = tokenizer( examples["summary"], max_length=128, truncation=True, padding="max_length" ) inputs["labels"] = labels["input_ids"] return inputs dataset = raw_dataset.map(preprocess, batched=True, remove_columns=["document", "summary"]) training_args = Seq2SeqTrainingArguments( output_dir="./bart-summary", per_device_train_batch_size=8, learning_rate=3e-5, num_train_epochs=3, predict_with_generate=True, generation_max_length=128, fp16=True, save_steps=500, logging_steps=50, ) data_collator = DataCollatorForSeq2Seq(tokenizer, model=model) trainer = Seq2SeqTrainer( model=model, args=training_args, train_dataset=dataset, data_collator=data_collator, tokenizer=tokenizer, ) trainer.train()参数里值得解释的是predict_with_generate=True，它让评估阶段使用真实解码而不是teacher forcing，这样才能看到模型在推理时的真实表现。generation_max_length=128控制解码步数上限，设太小摘要截断，设太大容易生成重复内容。fp16=True在V100以上显卡有可观加速，CPU或老显卡上要关掉。learning_rate=3e-5是微调BART这类预训练模型时比较通用的起点，数据量小可以降到2e-5，数据量大且想快速看效果可以试5e-5。per_device_batch_size=8按显存调整，24GB显存跑BART-base这个值很稳，显存吃紧就降到4。
3.3 推理阶段解决“重复生成”和“摘要过长”两个问题
训练完成后，推理并不只是调一次model.generate(input_ids)就完事。生成式摘要最常见的两个质量问题是重复片段和摘要绕圈。对应解法是调整生成参数：no_repeat_ngram_size禁止模型重复任意3-gram，length_penalty大于1时鼓励生成更长文本但也要防止膨胀，num_beams越大输出越稳定但时延线性增加。
下面的推理函数加了长度约束和重复度约束，适合直接用在接口里：
def summarize(text, model, tokenizer, max_input_len=512, max_output_len=128): inputs = tokenizer( text, max_length=max_input_len, truncation=True, return_tensors="pt" ) outputs = model.generate( inputs["input_ids"], max_length=max_output_len, num_beams=4, no_repeat_ngram_size=3, length_penalty=1.2, early_stopping=True, ) return tokenizer.decode(outputs[0], skip_special_tokens=True)num_beams=4是效果和延迟的折中，线上实时接口我常降到2或改用贪心解码保住时延，beam search留给离线批量任务。length_penalty=1.2表示生成越长收益递减越慢，适合摘要要覆盖足够信息的场景；如果业务只想要一句话摘要，改成0.8或直接用max_new_tokens更稳。需要提醒的是，max_length在generate和tokenizer两个接口里含义不同，前者是生成长度上限，后者是输入截断长度，混用会导致输入直接被截断但生成长度失控。
4. ROUGE评估与训练时最容易踩的三个坑
4.1 用ROUGE-1/2/L判断摘要质量的脚本
摘要模型的评估以ROUGE族指标为主，核心思想是计算生成的摘要与参考摘要之间的n-gram共现程度。ROUGE-1看单个词重合度，ROUGE-2看二元组重合度，ROUGE-L用最长公共子序列衡量句子级结构。实际项目里我不会单独看一个指标，而是三个值一起打印：ROUGE-1虚高说明不了太多，ROUGE-2过低则说明改写能力不足，ROUGE-L对句子顺序更敏感。
下面是用rouge_score库计算指标的最小脚本：
from rouge_score import rouge_scorer scorer = rouge_scorer.RougeScorer(["rouge1", "rouge2", "rougeL"], use_stemmer=True) def evaluate(predictions, references): scores = {"rouge1": [], "rouge2": [], "rougeL": []} for pred, ref in zip(predictions, references): result = scorer.score(ref, pred) for key in scores: scores[key].append(result[key].fmeasure) for key, values in scores.items(): print(f"{key}: {sum(values) / len(values):.4f}")use_stemmer=True会对英文做词干提取，把“running”和“ran”归为同一形态，提升不同时态表达之间的匹配率，但中文摘要里这个参数不生效。中文语料要先分词再传给scorer，否则按字符切分导致ROUGE偏低，模型真实水平被掩盖。fmeasure是精确率和召回率的调和平均，新闻摘要通常更关注ROUGE-L，因为语序直接影响到可读性和事实表达完整性。
4.2 数据泄漏：训练集里混进了测试摘要
摘要任务的数据泄漏比分类任务更隐蔽，泄漏的不是同一行数据，而是语义相似的文本。常见情况是同一篇新闻被多个平台转载，清洗时没做去重，训练集和测试集各留了一个版本，ROUGE分数虚高两个点以上。我的处理方式是对所有document字段做MinHash去重，阈值设为0.85；再做摘要级去重，把参考摘要完全重复的样本删掉，防止模型背下模板而不是学会摘要能力。
另一个容易被忽视的泄漏路径是时间泄漏：用2024年的新闻训练，然后拿2025年的新闻做评估，看起来没有交叉，但如果训练集里混入了抓取时的同源转载，仍然会造成指标虚高。结构化数据集建议显式按时间切分，而不是随机切分，这在新闻摘要和研报摘要这类时间敏感数据上尤其重要。
4.3 解码策略与ROUGE指标的“隐性作弊”
ROUGE分数在一定程度上可以被解码参数“刷”出来。把length_penalty调低，模型倾向生成短摘要，短摘要更容易与参考摘要产生高n-gram重合；把num_beams提高到8以上也能改善指标。但这并不代表摘要质量提升，长度过短往往会丢掉关键信息。团队里我做了一条硬性规则：评估ROUGE的同时必须记录生成摘要的平均长度，若平均长度小于参考摘要的70%，就要人工复核，防止模型靠“偷懒”刷分。ROUGE只能作为筛选模型checkpoint的初级信号，上线前必须人工抽检。
4.4 训练与评估分布不一致的常见来源
训练时模型使用teacher forcing，每一步解码都基于真实摘要前缀；推理时用的是自己生成的词，这种训练与推理的分布差异叫exposure bias。缓解手段是predict_with_generate=True定期做真实解码评估，另外可以在训练后期引入scheduled sampling，以一定概率把模型上一步生成的token作为下一步输入。这个技术在摘要任务里效果不算明显，反而容易影响收敛稳定性，我一般在模型完全收敛后再小步尝试。
5. 长文档和多语言场景的调优技巧
长文档摘要不能直接往BART里塞全文，常见做法是文档切块后先做抽取压缩，再拼接成不超过512个token的候选文本。实践中我用“首句加关键句聚类”来切块：对全文做句子向量表示后K-Means聚成5到8簇，每个簇内取最接近簇中心的句子，按原文顺序拼接。比单纯取首尾能保留更多核心信息，尤其是观点分散的长报告。
多语言摘要的坑在于分词器和预训练模型的语言覆盖度。BART只有英文版本，中文要使用mT5或中文预训练模型。如果你需要处理多语言混合文档，mT5会比单语模型稳定，因为它使用统一的sentencepiece词表覆盖100多种语言，跨语言摘要时不会因为OOV导致生成质量崩溃。切换语言时要注意tokenizer的最大长度不变，但单词编码后的token数可能明显不同，中文信息密度更高，同样的512个token能装下更多中文字符，训练数据截断参数要按语言单独校准。
几个具体的微调技巧：输入前缀加上“摘要：”这样的引导标记，模型生成时会更有方向感；针对同一份文档生成多个候选摘要再做重排序，效果比增大beam size更明显；对长文档引入“分块摘要再合并”的两阶段策略，第一阶段把每块生成短摘要，第二阶段把这些短摘要拼起来生成最终摘要，能绕开输入长度限制。这套组合下来，长文档摘要的ROUGE-L通常能比单次截断方案高出2到3个点。
本文还有配套的精品资源，点击获取
