中文自动摘要这个任务，说简单也简单，说坑也多。简单在于，如果你只是拿现成的预训练模型跑个demo，几行代码就能出结果；坑在于，当你真正想把它用到自己的业务数据上，会发现生成的结果要么重复啰嗦，要么漏掉关键信息，要么干脆把原文抄了一遍。我用BART做中文摘要有一段时间了，从最初的“跑通就行”到后来反复调参、换分词器、改解码策略，踩过的坑足够写一篇完整的复盘。这篇文章不打算复述官方文档，而是把我实际项目中积累的经验、遇到的意外情况、以及那些文档里不会写的细节，尽可能完整地分享出来。无论你是刚接触摘要任务的新手，还是已经跑过几个模型但效果不理想的开发者，应该都能从中找到一些可以直接用的东西。1. 为什么中文摘要值得单独拿出来做1.1 中文摘要和英文摘要的本质差异很多人觉得摘要任务就是“输入长文本、输出短文本”，语言差异不大。但实际做下来，中文摘要的难度在某些维度上明显高于英文。最直接的一点是分词。英文以空格自然分隔单词，BART原版使用的分词器可以直接按子词切分，语义单元相对清晰。中文没有空格，虽然现在普遍用BPE或WordPiece做子词切分，但中文的“词”边界本身就模糊，同一个字符串在不同语境下可能是不同的词。这就导致模型在编码阶段就可能把语义单元切碎，解码时再拼回来，信息损失比英文更严重。另一个差异是中文的句子结构更灵活。英文摘要模型学到的往往是“主谓宾”的压缩模式，但中文里省略主语、流水句、并列短句非常多。我试过直接用英文摘要的思路去处理中文新闻，结果模型生成的摘要经常出现主语缺失、指代不明的问题。比如原文讲“某公司发布了新产品，该产品支持多种功能”，模型可能压缩成“某公司发布新产品，支持多种功能”，看起来没问题，但如果是多主体交替出现的文本，指代就会乱。还有一个容易被忽略的点：中文的标点符号和英文不同。BART原版的分词器对中文标点的处理并不理想，句号、逗号、顿号、分号在中文里的语义权重不一样，但模型可能把它们统一当作分隔符。我在早期实验中就发现，模型经常把顿号连接的两个并列项合并成一个，导致摘要信息失真。所以，做中文摘要，第一步不是选模型，而是想清楚你的文本特点和摘要需求。1.2 BART在中文摘要任务中的定位BART是一种去噪自编码器，核心思想是先把输入文本加噪（比如随机遮盖、打乱顺序、删除片段），然后让模型学习恢复原始文本。这种预训练方式让它天生适合做序列到序列的生成任务，摘要就是其中之一。相比T5、Pegasus等模型，BART在摘要任务上的表现一直很稳，尤其是它的编码器-解码器结构，对长文本的压缩能力比较强。但要注意，原版BART是在英文语料上预训练的，直接拿来处理中文效果会很差。所以实际使用中，我们用的是中文BART预训练模型，比如在中文大规模语料上继续预训练的版本。这些模型已经学到了中文的语法和语义表示，我们只需要在摘要数据集上做微调，就能得到不错的效果。我个人的经验是，如果你的摘要任务偏向新闻标题生成或短摘要，中文BART微调后BLEU和ROUGE都能达到可用水平；但如果要做长摘要或面向特定领域的摘要，还需要额外的策略调整。1.3 摘要任务的两种主流范式做摘要之前，先要明确你要的是抽取式还是生成式。抽取式摘要从原文中直接挑选重要句子拼成摘要，优点是忠实原文、不会产生事实错误，缺点是句子之间的连贯性差，而且受限于原文表述。生成式摘要则让模型自己组织语言，优点是流畅、压缩率高，缺点是可能产生幻觉，编造原文没有的信息。BART属于生成式摘要模型。我在实际项目中一般会根据场景选择：如果是新闻快讯、财报摘要这类对事实准确性要求极高的场景，我会用抽取式做初筛，再用BART做润色和压缩；如果是内容推荐、文章导读这类容错率较高的场景，直接上BART生成即可。这个选择没有绝对的对错，关键看你的业务能承受多大的事实偏差。2. 数据准备：中文摘要最容易被低估的环节2.1 数据集的选择与清洗中文摘要的公开数据集不算多，常用的有LCSTS（中文微博新闻摘要）、NLPCC摘要任务数据、以及一些新闻语料构建的数据集。LCSTS是比较经典的一个，包含约240万条微博新闻和对应摘要，但它的摘要普遍很短，很多只有一句话，适合做短摘要训练。如果你的目标是长摘要，LCSTS可能不够用。我自己的做法是，先根据业务场景确定摘要长度分布，然后从公开数据集中筛选长度匹配的样本，再补充自己的业务数据。清洗环节有几个必须做的操作：第一，去掉摘要和原文完全相同的样本，这种数据会让模型学会“抄原文”；第二，去掉摘要长度超过原文的样本，这通常是数据标注错误；第三，检查特殊字符和乱码，中文文本里经常混入全角半角符号、HTML标签残留、表情符号等，这些都会干扰分词器。还有一个细节：中文摘要数据里经常出现“原标题”和“正文”混在一起的情况。有些数据集把新闻标题当作摘要，但标题和摘要的写作风格差异很大。标题追求吸引眼球，常用疑问句、感叹句；摘要追求信息完整，通常是陈述句。如果你用标题数据训练摘要模型，生成的摘要会偏向标题风格，读起来很跳。我一般会把标题和摘要分开处理，或者至少在训练时给模型一个标识，让它知道当前任务是什么。2.2 数据格式与预处理流水线BART的输入输出都是文本序列，所以数据格式相对简单。我通常把数据整理成JSON Lines格式，每行一个样本，包含source和target两个字段。预处理流水线包括：文本归一化（统一全角半角、去除多余空白）、长度过滤（去掉过短或过长的样本）、以及分词器编码。这里有个容易踩的坑：BART的输入长度限制。中文BART的max_position_embeddings通常是1024，意味着输入和输出加起来不能超过这个长度。但实际做摘要时，原文往往超过1024个token。我的处理方式是，对原文做截断，但截断策略很关键。直接截断尾部会丢失重要信息，我一般会保留开头和结尾，中间按比例截断，或者先用抽取式方法选出关键句，再拼接成不超过限制的输入。另一个坑是padding。BART的tokenizer在padding时默认用pad_token_id，但中文BART的pad token可能和英文不同。我建议在编码时显式指定padding='max_length'和truncation=True，并且统一设置max_length。如果batch内样本长度差异大，用动态padding效率更高，但要注意attention mask的正确性。2.3 构建验证集和测试集的注意事项验证集和测试集的构建不能随便切分。中文摘要数据里经常有同一事件的多篇报道，如果随机切分，训练集和验证集可能包含同一事件的相似文本，导致验证指标虚高。我一般会按事件ID或时间戳做分组切分，确保同一事件的样本只出现在一个集合中。另外，验证集的大小要合理。太小的话指标波动大，太大的话训练时评估开销高。我的经验是，如果训练集有10万条以上，验证集取5000到10000条就够了；如果训练集只有几万条，验证集至少要有3000条。测试集则要单独留出，最好和验证集来自不同时间段或不同来源，这样才能真实反映模型的泛化能力。3. 模型加载与微调：那些文档不会告诉你的细节3.1 中文BART模型的选型与加载中文BART有几个常见的预训练版本，比如在中文维基、新闻、百科等语料上训练的模型。选型时主要看预训练语料和你的业务领域是否匹配。如果你的摘要任务偏向新闻，就选新闻语料占比高的版本；如果偏向学术或技术文档，就选百科或论文语料多的版本。加载模型时，我习惯用AutoModelForSeq2SeqLM和AutoTokenizer，这样切换模型时只需要改模型名称。但要注意，有些中文BART模型的分词器需要额外配置，比如tokenizer.src_lang和tokenizer.tgt_lang，如果设置不对，编码结果会完全错误。我一般会先加载分词器，用几个测试句子编码再解码，确认分词器工作正常后再加载模型。还有一个细节：BART的config里有很多参数，比如encoder_layers、decoder_layers、d_model等。如果你要做领域适配，可以考虑在预训练模型基础上继续做领域预训练，但这需要大量领域语料和计算资源。对于大多数场景，直接微调就够了。3.2 微调时的超参数设置经验微调BART做摘要，超参数设置直接影响最终效果。我整理了一份自己常用的参数范围，供参考：参数常用范围说明学习率1e-5 ~ 5e-5太大容易震荡，太小收敛慢batch size8 ~ 32受显存限制，可用梯度累积训练轮数3 ~ 10看数据量，数据少多跑几轮最大输入长度512 ~ 1024根据原文长度分布定最大输出长度64 ~ 256根据摘要长度分布定beam search4 ~ 8生成时用，训练时不用length penalty0.6 ~ 1.0控制生成摘要长度学习率是最关键的。我试过用1e-4，结果loss剧烈震荡，模型完全学不到东西；用1e-6又太慢，跑十几个epoch都没收敛。后来固定在3e-5左右，配合线性预热和衰减，效果比较稳。batch size方面，如果显存不够，可以用梯度累积，比如实际batch size是8，累积4步，等效于32。但要注意，梯度累积时学习率要相应调整，一般按等效batch size缩放。训练轮数不是越多越好。中文摘要数据通常几万到几十万条，我一般跑3到5个epoch，然后看验证集ROUGE是否还在提升。如果连续两个epoch验证指标不升反降，就说明过拟合了，应该早停。3.3 损失函数与标签平滑BART微调默认用交叉熵损失，但中文摘要任务里，标签平滑（label smoothing）往往能带来稳定提升。标签平滑把硬标签（0和1）变成软标签（比如0.1和0.9），防止模型对某个token过度自信。我一般设置label_smoothing=0.1，在ROUGE上通常能涨0.5到1个点。另一个技巧是忽略padding token的损失。BART的forward方法默认会计算所有位置的损失，包括padding部分。如果padding很多，损失会被稀释。我一般会在计算loss时传入attention_mask，或者手动把padding位置的label设为-100，让损失函数忽略它们。还有一个容易被忽略的点：中文摘要的token分布很不均衡。常见字（的、了、是）出现频率极高，生僻字和专有名词出现频率低。如果不做处理，模型会倾向于生成常见字，导致摘要缺乏信息量。我试过用focal loss或者对低频token加权，但效果不稳定。后来发现，更简单的方法是调整解码策略，比如用top-k采样或核采样，增加生成的多样性。4. 解码策略：决定摘要质量的关键一步4.1 贪心搜索、束搜索与采样解码策略直接决定生成的摘要长什么样。贪心搜索每步选概率最大的token，速度快但容易生成重复、单调的文本。束搜索保留多个候选，最终选整体概率最高的序列，生成质量通常更好，但计算开销大。采样类方法（top-k、top-p）引入随机性，生成更多样，但可能不连贯。我在摘要任务上的经验是：如果追求稳定和忠实，用束搜索，beam size设4到6；如果追求多样性和可读性，用核采样，top-p设0.9左右。但要注意，束搜索容易生成“安全但平庸”的摘要，比如把原文开头抄一遍。核采样则可能生成事实错误的摘要。所以，我一般会先用束搜索生成一版，再用采样生成一版，人工对比后决定用哪个。4.2 长度控制与重复惩罚BART生成摘要时，经常出现两个极端：要么太短，只生成几个词；要么太长，把原文复述一遍。控制长度的方法有几种：一是设置min_length和max_length，强制生成在指定范围内；二是用length_penalty，大于1鼓励长摘要，小于1鼓励短摘要；三是用no_repeat_ngram_size，禁止重复的n-gram。我一般会组合使用：min_length=20，max_length=128，length_penalty=0.8，no_repeat_ngram_size=3。这样既能保证摘要不会太短，又能抑制重复。但要注意，no_repeat_ngram_size设太大（比如5）会导致生成不流畅，因为中文里很多合理的重复是必要的。我试过设5，结果模型连“的”都不敢重复用，句子读起来很别扭。4.3 针对中文的decoding调优中文解码还有一些特殊问题。比如，中文BART的分词器可能把“人工智能”切成“人工”和“智能”两个token，解码时如果两个token的概率都高，模型可能生成“人工智能”这种错误组合。解决方法是，在解码时加入词典约束，或者用后处理把常见错误组合纠正过来。另一个问题是标点。中文摘要的标点使用和英文不同，句号、逗号、顿号、分号各有用途。BART生成的摘要经常标点混乱，比如该用句号的地方用了逗号，或者连续多个逗号。我一般会在后处理阶段做标点规范化，比如把连续逗号替换成句号，或者在句末补上句号。还有一个技巧：用repetition_penalty控制重复。这个参数大于1时惩罚重复token，小于1时鼓励重复。中文摘要里，适当惩罚重复（比如设1.2）能减少“的的的”这类问题，但设太高会导致句子不完整。我一般从1.1开始试，根据生成结果微调。5. 评估与迭代：怎么判断摘要好不好5.1 自动评估指标的局限ROUGE是摘要任务最常用的自动评估指标，它计算生成摘要和参考摘要之间的n-gram重叠。ROUGE-1看unigram重叠，ROUGE-2看bigram，ROUGE-L看最长公共子序列。这些指标计算简单，但和人类判断的相关性有限。我遇到过ROUGE很高但读起来很差的摘要，也遇到过ROUGE一般但信息完整的摘要。BLEU也常被用来评估摘要，但它原本是为机器翻译设计的，对摘要的评估效果不如ROUGE。BERTScore用预训练模型计算语义相似度，比ROUGE更接近人类判断，但计算开销大。我一般会同时看ROUGE和BERTScore，如果两者趋势一致，说明模型确实在进步；如果分歧大，就需要人工检查。5.2 人工评估的设计与执行自动指标只能做参考，最终还是要人工看。我一般会设计几个维度：信息完整性（摘要是否覆盖原文关键信息）、事实准确性（摘要是否有原文没有的信息）、流畅度（摘要是否通顺）、简洁度（摘要是否冗余）。每个维度打分1到5分，然后取平均。人工评估的样本量不用太大，100到200条就能看出问题。但要注意，评估者要多样化，不能全是同一个人。我试过让不同背景的人评估同一批摘要，结果发现技术背景的人更关注事实准确性，非技术背景的人更关注流畅度。所以，如果你的摘要面向普通用户，就要多找非技术背景的人评估。5.3 错误分析与迭代方向错误分析是迭代的关键。我一般会把生成摘要和参考摘要并排看，标记出错误类型：漏信息、多信息、指代错误、重复、不连贯等。然后统计各类错误的比例，优先解决占比高的。常见的错误和对应策略：错误类型可能原因解决方向漏关键信息输入截断、模型容量不足调整截断策略、增大模型生成原文没有的信息过拟合、解码随机性大降低学习率、用束搜索重复生成解码策略问题加重复惩罚、调no_repeat_ngram指代不明中文特性、训练数据不足补充指代标注数据、后处理摘要过长长度控制不当调length_penalty、设max_length我自己的迭代顺序一般是：先解决重复和长度问题，再解决信息完整性问题，最后优化流畅度。因为重复和长度问题最影响可读性，信息完整性次之，流畅度是锦上添花。6. 部署与性能优化：从实验到上线6.1 模型导出与推理加速训练好的BART模型如果要上线，需要考虑推理速度。PyTorch模型默认是动态图，推理时可以用torch.jit.trace或torch.jit.script导出为TorchScript，减少Python开销。也可以用ONNX导出，再用ONNX Runtime推理，速度通常比原生PyTorch快不少。我试过用ONNX Runtime部署BART，在CPU上推理速度提升了约2倍，GPU上提升不明显。但ONNX导出时要注意，BART的beam search在ONNX里支持有限，可能需要把beam search逻辑移到后处理。另一个方案是用TensorRT，但配置复杂，适合对延迟要求极高的场景。如果不想折腾导出，也可以用model.eval()和torch.no_grad()，再配合半精度（fp16）推理，速度也能提升。但fp16在CPU上支持不好，GPU上要注意数值稳定性。6.2 批处理与动态padding线上推理通常是批处理请求。如果batch内样本长度差异大，padding到最大长度会浪费计算。动态padding按batch内最大长度padding，能显著提升效率。我一般会在推理前按长度排序，然后分batch，每个batch内padding到该batch的最大长度。但要注意，动态padding时attention mask要正确设置，否则padding位置会影响结果。另外，如果batch内长度差异太大，比如有的样本10个token，有的1000个token，动态padding的效果也会打折扣。这时候可以分桶，把长度相近的样本放在一起。6.3 缓存与并发处理摘要服务通常会有重复请求，比如同一篇新闻被多个用户请求摘要。加一层缓存能大幅减少计算。我一般用Redis做缓存，key是原文的哈希，value是生成的摘要。缓存过期时间根据业务定，新闻类可以设几小时，文档类可以设几天。并发处理方面，如果请求量大，可以用消息队列做异步处理，避免请求堆积。也可以用多进程或多线程，但要注意PyTorch的GIL限制。我一般用FastAPI起服务，配合uvicorn的多worker模式，每个worker独立加载模型，这样能充分利用多核CPU。7. 实际项目中积累的避坑经验7.1 数据层面的坑第一个坑是数据泄露。我早期做实验时，训练集和验证集随机切分，结果验证ROUGE高得离谱，上线后效果一塌糊涂。后来发现是同一事件的报道被分到了不同集合，模型其实在“背答案”。解决方法是按事件ID分组切分。第二个坑是摘要长度分布不一致。训练数据里摘要平均20个字，但业务需求是50个字的摘要。模型会倾向于生成20字左右的摘要，导致信息量不足。解决方法是在训练时加入长度控制，或者在解码时强制min_length。第三个坑是特殊符号。中文文本里经常有全角空格、零宽字符、HTML实体等，这些在分词时可能被忽略或错误处理。我一般会在预处理阶段用正则清洗，把所有非中文、非英文、非数字、非常用标点的字符替换掉。7.2 训练层面的坑第一个坑是学习率设太大。我试过1e-4，loss直接飙到nan。后来查资料发现，BART微调的学习率一般不超过5e-5。现在我用3e-5配合warmup，稳定很多。第二个坑是batch size太小。batch size太小会导致梯度噪声大，训练不稳定。如果显存不够，可以用梯度累积，但要注意调整学习率。我一般用等效batch size 32，如果显存只够8，就累积4步。第三个坑是忽略验证集。有些人训练时只看训练loss，不看验证指标，结果过拟合了都不知道。我一般每个epoch结束都跑验证集，记录ROUGE，连续两个epoch不提升就早停。7.3 推理层面的坑第一个坑是max_length设太小。如果max_length设64，但参考摘要平均80个字，模型生成到64就被截断，摘要不完整。我一般会统计参考摘要的长度分布，取95分位数作为max_length。第二个坑是beam search的beam size太大。beam size从4增加到8，ROUGE可能只涨0.2，但推理时间翻倍。我一般用4或5，平衡质量和速度。第三个坑是忽略后处理。BART生成的摘要经常有多余空格、重复标点、不完整句子。我一般会加一层后处理：去除多余空格、合并重复标点、补全句末标点、截断不完整句子。8. 一些可以直接用的代码片段8.1 数据预处理与Dataset构建import json import re from torch.utils.data import Dataset class SummaryDataset(Dataset): def __init__(self, data_path, tokenizer, max_input_len=512, max_target_len=128): self.data = [] with open(data_path, 'r', encoding='utf-8') as f: for line in f: item = json.loads(line) self.data.append(item) self.tokenizer = tokenizer self.max_input_len = max_input_len self.max_target_len = max_target_len def __len__(self): return len(self.data) def __getitem__(self, idx): item = self.data[idx] source = self.clean_text(item['source']) target = self.clean_text(item['target']) inputs = self.tokenizer( source, max_length=self.max_input_len, truncation=True, padding='max_length', return_tensors='pt' ) targets = self.tokenizer( target, max_length=self.max_target_len, truncation=True, padding='max_length', return_tensors='pt' ) labels = targets['input_ids'].squeeze() labels[labels == self.tokenizer.pad_token_id] = -100 return { 'input_ids': inputs['input_ids'].squeeze(), 'attention_mask': inputs['attention_mask'].squeeze(), 'labels': labels } def clean_text(self, text): text = re.sub(r'\s+', ' ', text) text = re.sub(r'[^\u4e00-\u9fa5a-zA-Z0-9，。！？、；：""''（）《》\s]', '', text) return text.strip()这段代码里，clean_text做了基本的文本清洗，去掉了非中文、非英文、非数字和非常用标点的字符。labels里把padding位置设为-100，让损失函数忽略它们。这些细节看起来小，但对训练效果影响很大。8.2 微调训练循环from transformers import AutoModelForSeq2SeqLM, AutoTokenizer, AdamW from torch.utils.data import DataLoader import torch model_name = 'your-chinese-bart-model' tokenizer = AutoTokenizer.from_pretrained(model_name) model = AutoModelForSeq2SeqLM.from_pretrained(model_name) train_dataset = SummaryDataset('train.jsonl', tokenizer) val_dataset = SummaryDataset('val.jsonl', tokenizer) train_loader = DataLoader(train_dataset, batch_size=8, shuffle=True) val_loader = DataLoader(val_dataset, batch_size=8) optimizer = AdamW(model.parameters(), lr=3e-5) device = torch.device('cuda' if torch.cuda.is_available() else 'cpu') model.to(device) for epoch in range(5): model.train() total_loss = 0 for batch in train_loader: input_ids = batch['input_ids'].to(device) attention_mask = batch['attention_mask'].to(device) labels = batch['labels'].to(device) outputs = model( input_ids=input_ids, attention_mask=attention_mask, labels=labels ) loss = outputs.loss loss.backward() optimizer.step() optimizer.zero_grad() total_loss += loss.item() print(f'Epoch {epoch+1}, Loss: {total_loss/len(train_loader)}') # 验证集评估略训练循环本身不复杂，关键是超参数。我一般用AdamW，学习率3e-5，配合线性预热。如果显存不够，可以加torch.cuda.amp做混合精度训练。8.3 推理与后处理def generate_summary(text, model, tokenizer, device): model.eval() inputs = tokenizer( text, max_length=512, truncation=True, return_tensors='pt' ).to(device) with torch.no_grad(): outputs = model.generate( input_ids=inputs['input_ids'], attention_mask=inputs['attention_mask'], max_length=128, min_length=20, num_beams=4, length_penalty=0.8, no_repeat_ngram_size=3, repetition_penalty=1.2, early_stopping=True ) summary = tokenizer.decode(outputs[0], skip_special_tokens=True) summary = post_process(summary) return summary def post_process(text): text = re.sub(r'\s+', '', text) text = re.sub(r'([，。！？、；：])\1+', r'\1', text) if text and text[-1] not in '。！？': text += '。' return text推理时的参数组合是我反复试出来的。num_beams=4平衡质量和速度，length_penalty=0.8鼓励稍短的摘要，no_repeat_ngram_size=3抑制重复，repetition_penalty=1.2进一步减少重复token。后处理做了空格去除、重复标点合并、句末标点补全。9. 不同场景下的策略调整9.1 新闻摘要 vs 技术文档摘要新闻摘要通常要求时效性和信息密度，摘要要短、要快。我一般用beam search，max_length设64到96，length_penalty设0.6到0.8，让摘要更紧凑。技术文档摘要则要求准确性和完整性，摘要可以长一些，max_length设128到256，length_penalty设1.0左右，让模型有更多空间组织语言。新闻摘要的另一个特点是实体多。人名、地名、机构名、产品名频繁出现，模型容易生成错误实体。我一般会在后处理阶段做实体校验，把生成摘要里的实体和原文比对，如果原文没有就删掉或替换。9.2 短文本摘要 vs 长文本摘要短文本摘要（比如微博、评论）输入只有几十到几百字，BART可以直接处理，不需要截断。但短文本的信息密度低，模型容易生成和原文差不多的摘要。我一般会设min_length稍大一些，强制模型压缩。长文本摘要（比如论文、报告）输入可能几千字，超过BART的长度限制。我的处理方式是先用抽取式方法选出关键句，拼接成不超过1024个token的输入，再用BART生成摘要。抽取式方法可以用TextRank或BERTScore，选出和原文主题最相关的句子。9.3 多文档摘要的挑战多文档摘要是把多篇相关文档压缩成一篇摘要，难度比单文档高很多。BART本身是为单文档设计的，直接处理多文档需要把多篇文档拼接起来，但这样会丢失文档间的结构信息。我试过用层次化模型，先对每篇文档生成单文档摘要，再把摘要拼接起来生成最终摘要。效果比直接拼接好，但计算开销大。另一个思路是用图模型建模文档间关系，但实现复杂。对于大多数场景，如果多文档之间主题一致，直接拼接加BART也能用；如果主题差异大，就需要先做聚类或筛选。10. 我个人的一些零散心得做中文摘要这段时间，最大的体会是：模型不是万能的，数据和策略往往比模型本身更重要。我见过太多人花大量时间调模型结构，却忽略了数据清洗和评估设计。实际上，把数据洗干净、把评估做扎实，比换一个更大的模型带来的提升更明显。另一个体会是，中文摘要没有“一招鲜”的方案。新闻、论文、对话、商品评论，每种文本的摘要需求都不一样，解码策略、长度控制、后处理都要相应调整。我一般会针对每个场景单独调一套参数，而不是用一个通用配置打天下。还有一点，人工评估不能省。自动指标只能做参考，最终还是要人来看。我一般会定期抽一批生成摘要，自己读一遍，标记问题，然后针对性优化。这个过程很枯燥，但效果最实在。最后，如果你刚开始做中文摘要，我的建议是：先用小规模数据跑通全流程，确认数据格式、模型加载、训练循环、推理生成都没问题，再逐步扩大数据量和模型规模。不要一上来就上百万数据、最大模型，那样出了问题很难定位。小步快跑，快速迭代，才是做摘要任务最稳妥的方式。
中文自动摘要这个任务，说简单也简单，说坑也多。简单在于，如果你只是拿现成的预训练模型跑个demo，几行代码就能出结果；坑在于，当你真正想把它用到自己的业务数据上，会发现生成的结果要么重复啰嗦，要么漏掉关键信息，要么干脆把原文抄了一遍。我用BART做中文摘要有一段时间了，从最初的“跑通就行”到后来反复调参、换分词器、改解码策略，踩过的坑足够写一篇完整的复盘。这篇文章不打算复述官方文档，而是把我实际项目中积累的经验、遇到的意外情况、以及那些文档里不会写的细节，尽可能完整地分享出来。无论你是刚接触摘要任务的新手，还是已经跑过几个模型但效果不理想的开发者，应该都能从中找到一些可以直接用的东西。1. 为什么中文摘要值得单独拿出来做1.1 中文摘要和英文摘要的本质差异很多人觉得摘要任务就是“输入长文本、输出短文本”，语言差异不大。但实际做下来，中文摘要的难度在某些维度上明显高于英文。最直接的一点是分词。英文以空格自然分隔单词，BART原版使用的分词器可以直接按子词切分，语义单元相对清晰。中文没有空格，虽然现在普遍用BPE或WordPiece做子词切分，但中文的“词”边界本身就模糊，同一个字符串在不同语境下可能是不同的词。这就导致模型在编码阶段就可能把语义单元切碎，解码时再拼回来，信息损失比英文更严重。另一个差异是中文的句子结构更灵活。英文摘要模型学到的往往是“主谓宾”的压缩模式，但中文里省略主语、流水句、并列短句非常多。我试过直接用英文摘要的思路去处理中文新闻，结果模型生成的摘要经常出现主语缺失、指代不明的问题。比如原文讲“某公司发布了新产品，该产品支持多种功能”，模型可能压缩成“某公司发布新产品，支持多种功能”，看起来没问题，但如果是多主体交替出现的文本，指代就会乱。还有一个容易被忽略的点：中文的标点符号和英文不同。BART原版的分词器对中文标点的处理并不理想，句号、逗号、顿号、分号在中文里的语义权重不一样，但模型可能把它们统一当作分隔符。我在早期实验中就发现，模型经常把顿号连接的两个并列项合并成一个，导致摘要信息失真。所以，做中文摘要，第一步不是选模型，而是想清楚你的文本特点和摘要需求。1.2 BART在中文摘要任务中的定位BART是一种去噪自编码器，核心思想是先把输入文本加噪（比如随机遮盖、打乱顺序、删除片段），然后让模型学习恢复原始文本。这种预训练方式让它天生适合做序列到序列的生成任务，摘要就是其中之一。相比T5、Pegasus等模型，BART在摘要任务上的表现一直很稳，尤其是它的编码器-解码器结构，对长文本的压缩能力比较强。但要注意，原版BART是在英文语料上预训练的，直接拿来处理中文效果会很差。所以实际使用中，我们用的是中文BART预训练模型，比如在中文大规模语料上继续预训练的版本。这些模型已经学到了中文的语法和语义表示，我们只需要在摘要数据集上做微调，就能得到不错的效果。我个人的经验是，如果你的摘要任务偏向新闻标题生成或短摘要，中文BART微调后BLEU和ROUGE都能达到可用水平；但如果要做长摘要或面向特定领域的摘要，还需要额外的策略调整。1.3 摘要任务的两种主流范式做摘要之前，先要明确你要的是抽取式还是生成式。抽取式摘要从原文中直接挑选重要句子拼成摘要，优点是忠实原文、不会产生事实错误，缺点是句子之间的连贯性差，而且受限于原文表述。生成式摘要则让模型自己组织语言，优点是流畅、压缩率高，缺点是可能产生幻觉，编造原文没有的信息。BART属于生成式摘要模型。我在实际项目中一般会根据场景选择：如果是新闻快讯、财报摘要这类对事实准确性要求极高的场景，我会用抽取式做初筛，再用BART做润色和压缩；如果是内容推荐、文章导读这类容错率较高的场景，直接上BART生成即可。这个选择没有绝对的对错，关键看你的业务能承受多大的事实偏差。2. 数据准备：中文摘要最容易被低估的环节2.1 数据集的选择与清洗中文摘要的公开数据集不算多，常用的有LCSTS（中文微博新闻摘要）、NLPCC摘要任务数据、以及一些新闻语料构建的数据集。LCSTS是比较经典的一个，包含约240万条微博新闻和对应摘要，但它的摘要普遍很短，很多只有一句话，适合做短摘要训练。如果你的目标是长摘要，LCSTS可能不够用。我自己的做法是，先根据业务场景确定摘要长度分布，然后从公开数据集中筛选长度匹配的样本，再补充自己的业务数据。清洗环节有几个必须做的操作：第一，去掉摘要和原文完全相同的样本，这种数据会让模型学会“抄原文”；第二，去掉摘要长度超过原文的样本，这通常是数据标注错误；第三，检查特殊字符和乱码，中文文本里经常混入全角半角符号、HTML标签残留、表情符号等，这些都会干扰分词器。还有一个细节：中文摘要数据里经常出现“原标题”和“正文”混在一起的情况。有些数据集把新闻标题当作摘要，但标题和摘要的写作风格差异很大。标题追求吸引眼球，常用疑问句、感叹句；摘要追求信息完整，通常是陈述句。如果你用标题数据训练摘要模型，生成的摘要会偏向标题风格，读起来很跳。我一般会把标题和摘要分开处理，或者至少在训练时给模型一个标识，让它知道当前任务是什么。2.2 数据格式与预处理流水线BART的输入输出都是文本序列，所以数据格式相对简单。我通常把数据整理成JSON Lines格式，每行一个样本，包含source和target两个字段。预处理流水线包括：文本归一化（统一全角半角、去除多余空白）、长度过滤（去掉过短或过长的样本）、以及分词器编码。这里有个容易踩的坑：BART的输入长度限制。中文BART的max_position_embeddings通常是1024，意味着输入和输出加起来不能超过这个长度。但实际做摘要时，原文往往超过1024个token。我的处理方式是，对原文做截断，但截断策略很关键。直接截断尾部会丢失重要信息，我一般会保留开头和结尾，中间按比例截断，或者先用抽取式方法选出关键句，再拼接成不超过限制的输入。另一个坑是padding。BART的tokenizer在padding时默认用pad_token_id，但中文BART的pad token可能和英文不同。我建议在编码时显式指定padding='max_length'和truncation=True，并且统一设置max_length。如果batch内样本长度差异大，用动态padding效率更高，但要注意attention mask的正确性。2.3 构建验证集和测试集的注意事项验证集和测试集的构建不能随便切分。中文摘要数据里经常有同一事件的多篇报道，如果随机切分，训练集和验证集可能包含同一事件的相似文本，导致验证指标虚高。我一般会按事件ID或时间戳做分组切分，确保同一事件的样本只出现在一个集合中。另外，验证集的大小要合理。太小的话指标波动大，太大的话训练时评估开销高。我的经验是，如果训练集有10万条以上，验证集取5000到10000条就够了；如果训练集只有几万条，验证集至少要有3000条。测试集则要单独留出，最好和验证集来自不同时间段或不同来源，这样才能真实反映模型的泛化能力。3. 模型加载与微调：那些文档不会告诉你的细节3.1 中文BART模型的选型与加载中文BART有几个常见的预训练版本，比如在中文维基、新闻、百科等语料上训练的模型。选型时主要看预训练语料和你的业务领域是否匹配。如果你的摘要任务偏向新闻，就选新闻语料占比高的版本；如果偏向学术或技术文档，就选百科或论文语料多的版本。加载模型时，我习惯用AutoModelForSeq2SeqLM和AutoTokenizer，这样切换模型时只需要改模型名称。但要注意，有些中文BART模型的分词器需要额外配置，比如tokenizer.src_lang和tokenizer.tgt_lang，如果设置不对，编码结果会完全错误。我一般会先加载分词器，用几个测试句子编码再解码，确认分词器工作正常后再加载模型。还有一个细节：BART的config里有很多参数，比如encoder_layers、decoder_layers、d_model等。如果你要做领域适配，可以考虑在预训练模型基础上继续做领域预训练，但这需要大量领域语料和计算资源。对于大多数场景，直接微调就够了。3.2 微调时的超参数设置经验微调BART做摘要，超参数设置直接影响最终效果。我整理了一份自己常用的参数范围，供参考：参数常用范围说明学习率1e-5 ~ 5e-5太大容易震荡，太小收敛慢batch size8 ~ 32受显存限制，可用梯度累积训练轮数3 ~ 10看数据量，数据少多跑几轮最大输入长度512 ~ 1024根据原文长度分布定最大输出长度64 ~ 256根据摘要长度分布定beam search4 ~ 8生成时用，训练时不用length penalty0.6 ~ 1.0控制生成摘要长度学习率是最关键的。我试过用1e-4，结果loss剧烈震荡，模型完全学不到东西；用1e-6又太慢，跑十几个epoch都没收敛。后来固定在3e-5左右，配合线性预热和衰减，效果比较稳。batch size方面，如果显存不够，可以用梯度累积，比如实际batch size是8，累积4步，等效于32。但要注意，梯度累积时学习率要相应调整，一般按等效batch size缩放。训练轮数不是越多越好。中文摘要数据通常几万到几十万条，我一般跑3到5个epoch，然后看验证集ROUGE是否还在提升。如果连续两个epoch验证指标不升反降，就说明过拟合了，应该早停。3.3 损失函数与标签平滑BART微调默认用交叉熵损失，但中文摘要任务里，标签平滑（label smoothing）往往能带来稳定提升。标签平滑把硬标签（0和1）变成软标签（比如0.1和0.9），防止模型对某个token过度自信。我一般设置label_smoothing=0.1，在ROUGE上通常能涨0.5到1个点。另一个技巧是忽略padding token的损失。BART的forward方法默认会计算所有位置的损失，包括padding部分。如果padding很多，损失会被稀释。我一般会在计算loss时传入attention_mask，或者手动把padding位置的label设为-100，让损失函数忽略它们。还有一个容易被忽略的点：中文摘要的token分布很不均衡。常见字（的、了、是）出现频率极高，生僻字和专有名词出现频率低。如果不做处理，模型会倾向于生成常见字，导致摘要缺乏信息量。我试过用focal loss或者对低频token加权，但效果不稳定。后来发现，更简单的方法是调整解码策略，比如用top-k采样或核采样，增加生成的多样性。4. 解码策略：决定摘要质量的关键一步4.1 贪心搜索、束搜索与采样解码策略直接决定生成的摘要长什么样。贪心搜索每步选概率最大的token，速度快但容易生成重复、单调的文本。束搜索保留多个候选，最终选整体概率最高的序列，生成质量通常更好，但计算开销大。采样类方法（top-k、top-p）引入随机性，生成更多样，但可能不连贯。我在摘要任务上的经验是：如果追求稳定和忠实，用束搜索，beam size设4到6；如果追求多样性和可读性，用核采样，top-p设0.9左右。但要注意，束搜索容易生成“安全但平庸”的摘要，比如把原文开头抄一遍。核采样则可能生成事实错误的摘要。所以，我一般会先用束搜索生成一版，再用采样生成一版，人工对比后决定用哪个。4.2 长度控制与重复惩罚BART生成摘要时，经常出现两个极端：要么太短，只生成几个词；要么太长，把原文复述一遍。控制长度的方法有几种：一是设置min_length和max_length，强制生成在指定范围内；二是用length_penalty，大于1鼓励长摘要，小于1鼓励短摘要；三是用no_repeat_ngram_size，禁止重复的n-gram。我一般会组合使用：min_length=20，max_length=128，length_penalty=0.8，no_repeat_ngram_size=3。这样既能保证摘要不会太短，又能抑制重复。但要注意，no_repeat_ngram_size设太大（比如5）会导致生成不流畅，因为中文里很多合理的重复是必要的。我试过设5，结果模型连“的”都不敢重复用，句子读起来很别扭。4.3 针对中文的decoding调优中文解码还有一些特殊问题。比如，中文BART的分词器可能把“人工智能”切成“人工”和“智能”两个token，解码时如果两个token的概率都高，模型可能生成“人工智能”这种错误组合。解决方法是，在解码时加入词典约束，或者用后处理把常见错误组合纠正过来。另一个问题是标点。中文摘要的标点使用和英文不同，句号、逗号、顿号、分号各有用途。BART生成的摘要经常标点混乱，比如该用句号的地方用了逗号，或者连续多个逗号。我一般会在后处理阶段做标点规范化，比如把连续逗号替换成句号，或者在句末补上句号。还有一个技巧：用repetition_penalty控制重复。这个参数大于1时惩罚重复token，小于1时鼓励重复。中文摘要里，适当惩罚重复（比如设1.2）能减少“的的的”这类问题，但设太高会导致句子不完整。我一般从1.1开始试，根据生成结果微调。5. 评估与迭代：怎么判断摘要好不好5.1 自动评估指标的局限ROUGE是摘要任务最常用的自动评估指标，它计算生成摘要和参考摘要之间的n-gram重叠。ROUGE-1看unigram重叠，ROUGE-2看bigram，ROUGE-L看最长公共子序列。这些指标计算简单，但和人类判断的相关性有限。我遇到过ROUGE很高但读起来很差的摘要，也遇到过ROUGE一般但信息完整的摘要。BLEU也常被用来评估摘要，但它原本是为机器翻译设计的，对摘要的评估效果不如ROUGE。BERTScore用预训练模型计算语义相似度，比ROUGE更接近人类判断，但计算开销大。我一般会同时看ROUGE和BERTScore，如果两者趋势一致，说明模型确实在进步；如果分歧大，就需要人工检查。5.2 人工评估的设计与执行自动指标只能做参考，最终还是要人工看。我一般会设计几个维度：信息完整性（摘要是否覆盖原文关键信息）、事实准确性（摘要是否有原文没有的信息）、流畅度（摘要是否通顺）、简洁度（摘要是否冗余）。每个维度打分1到5分，然后取平均。人工评估的样本量不用太大，100到200条就能看出问题。但要注意，评估者要多样化，不能全是同一个人。我试过让不同背景的人评估同一批摘要，结果发现技术背景的人更关注事实准确性，非技术背景的人更关注流畅度。所以，如果你的摘要面向普通用户，就要多找非技术背景的人评估。5.3 错误分析与迭代方向错误分析是迭代的关键。我一般会把生成摘要和参考摘要并排看，标记出错误类型：漏信息、多信息、指代错误、重复、不连贯等。然后统计各类错误的比例，优先解决占比高的。常见的错误和对应策略：错误类型可能原因解决方向漏关键信息输入截断、模型容量不足调整截断策略、增大模型生成原文没有的信息过拟合、解码随机性大降低学习率、用束搜索重复生成解码策略问题加重复惩罚、调no_repeat_ngram指代不明中文特性、训练数据不足补充指代标注数据、后处理摘要过长长度控制不当调length_penalty、设max_length我自己的迭代顺序一般是：先解决重复和长度问题，再解决信息完整性问题，最后优化流畅度。因为重复和长度问题最影响可读性，信息完整性次之，流畅度是锦上添花。6. 部署与性能优化：从实验到上线6.1 模型导出与推理加速训练好的BART模型如果要上线，需要考虑推理速度。PyTorch模型默认是动态图，推理时可以用torch.jit.trace或torch.jit.script导出为TorchScript，减少Python开销。也可以用ONNX导出，再用ONNX Runtime推理，速度通常比原生PyTorch快不少。我试过用ONNX Runtime部署BART，在CPU上推理速度提升了约2倍，GPU上提升不明显。但ONNX导出时要注意，BART的beam search在ONNX里支持有限，可能需要把beam search逻辑移到后处理。另一个方案是用TensorRT，但配置复杂，适合对延迟要求极高的场景。如果不想折腾导出，也可以用model.eval()和torch.no_grad()，再配合半精度（fp16）推理，速度也能提升。但fp16在CPU上支持不好，GPU上要注意数值稳定性。6.2 批处理与动态padding线上推理通常是批处理请求。如果batch内样本长度差异大，padding到最大长度会浪费计算。动态padding按batch内最大长度padding，能显著提升效率。我一般会在推理前按长度排序，然后分batch，每个batch内padding到该batch的最大长度。但要注意，动态padding时attention mask要正确设置，否则padding位置会影响结果。另外，如果batch内长度差异太大，比如有的样本10个token，有的1000个token，动态padding的效果也会打折扣。这时候可以分桶，把长度相近的样本放在一起。6.3 缓存与并发处理摘要服务通常会有重复请求，比如同一篇新闻被多个用户请求摘要。加一层缓存能大幅减少计算。我一般用Redis做缓存，key是原文的哈希，value是生成的摘要。缓存过期时间根据业务定，新闻类可以设几小时，文档类可以设几天。并发处理方面，如果请求量大，可以用消息队列做异步处理，避免请求堆积。也可以用多进程或多线程，但要注意PyTorch的GIL限制。我一般用FastAPI起服务，配合uvicorn的多worker模式，每个worker独立加载模型，这样能充分利用多核CPU。7. 实际项目中积累的避坑经验7.1 数据层面的坑第一个坑是数据泄露。我早期做实验时，训练集和验证集随机切分，结果验证ROUGE高得离谱，上线后效果一塌糊涂。后来发现是同一事件的报道被分到了不同集合，模型其实在“背答案”。解决方法是按事件ID分组切分。第二个坑是摘要长度分布不一致。训练数据里摘要平均20个字，但业务需求是50个字的摘要。模型会倾向于生成20字左右的摘要，导致信息量不足。解决方法是在训练时加入长度控制，或者在解码时强制min_length。第三个坑是特殊符号。中文文本里经常有全角空格、零宽字符、HTML实体等，这些在分词时可能被忽略或错误处理。我一般会在预处理阶段用正则清洗，把所有非中文、非英文、非数字、非常用标点的字符替换掉。7.2 训练层面的坑第一个坑是学习率设太大。我试过1e-4，loss直接飙到nan。后来查资料发现，BART微调的学习率一般不超过5e-5。现在我用3e-5配合warmup，稳定很多。第二个坑是batch size太小。batch size太小会导致梯度噪声大，训练不稳定。如果显存不够，可以用梯度累积，但要注意调整学习率。我一般用等效batch size 32，如果显存只够8，就累积4步。第三个坑是忽略验证集。有些人训练时只看训练loss，不看验证指标，结果过拟合了都不知道。我一般每个epoch结束都跑验证集，记录ROUGE，连续两个epoch不提升就早停。7.3 推理层面的坑第一个坑是max_length设太小。如果max_length设64，但参考摘要平均80个字，模型生成到64就被截断，摘要不完整。我一般会统计参考摘要的长度分布，取95分位数作为max_length。第二个坑是beam search的beam size太大。beam size从4增加到8，ROUGE可能只涨0.2，但推理时间翻倍。我一般用4或5，平衡质量和速度。第三个坑是忽略后处理。BART生成的摘要经常有多余空格、重复标点、不完整句子。我一般会加一层后处理：去除多余空格、合并重复标点、补全句末标点、截断不完整句子。8. 一些可以直接用的代码片段8.1 数据预处理与Dataset构建import json import re from torch.utils.data import Dataset class SummaryDataset(Dataset): def __init__(self, data_path, tokenizer, max_input_len=512, max_target_len=128): self.data = [] with open(data_path, 'r', encoding='utf-8') as f: for line in f: item = json.loads(line) self.data.append(item) self.tokenizer = tokenizer self.max_input_len = max_input_len self.max_target_len = max_target_len def __len__(self): return len(self.data) def __getitem__(self, idx): item = self.data[idx] source = self.clean_text(item['source']) target = self.clean_text(item['target']) inputs = self.tokenizer( source, max_length=self.max_input_len, truncation=True, padding='max_length', return_tensors='pt' ) targets = self.tokenizer( target, max_length=self.max_target_len, truncation=True, padding='max_length', return_tensors='pt' ) labels = targets['input_ids'].squeeze() labels[labels == self.tokenizer.pad_token_id] = -100 return { 'input_ids': inputs['input_ids'].squeeze(), 'attention_mask': inputs['attention_mask'].squeeze(), 'labels': labels } def clean_text(self, text): text = re.sub(r'\s+', ' ', text) text = re.sub(r'[^\u4e00-\u9fa5a-zA-Z0-9，。！？、；：""''（）《》\s]', '', text) return text.strip()这段代码里，clean_text做了基本的文本清洗，去掉了非中文、非英文、非数字和非常用标点的字符。labels里把padding位置设为-100，让损失函数忽略它们。这些细节看起来小，但对训练效果影响很大。8.2 微调训练循环from transformers import AutoModelForSeq2SeqLM, AutoTokenizer, AdamW from torch.utils.data import DataLoader import torch model_name = 'your-chinese-bart-model' tokenizer = AutoTokenizer.from_pretrained(model_name) model = AutoModelForSeq2SeqLM.from_pretrained(model_name) train_dataset = SummaryDataset('train.jsonl', tokenizer) val_dataset = SummaryDataset('val.jsonl', tokenizer) train_loader = DataLoader(train_dataset, batch_size=8, shuffle=True) val_loader = DataLoader(val_dataset, batch_size=8) optimizer = AdamW(model.parameters(), lr=3e-5) device = torch.device('cuda' if torch.cuda.is_available() else 'cpu') model.to(device) for epoch in range(5): model.train() total_loss = 0 for batch in train_loader: input_ids = batch['input_ids'].to(device) attention_mask = batch['attention_mask'].to(device) labels = batch['labels'].to(device) outputs = model( input_ids=input_ids, attention_mask=attention_mask, labels=labels ) loss = outputs.loss loss.backward() optimizer.step() optimizer.zero_grad() total_loss += loss.item() print(f'Epoch {epoch+1}, Loss: {total_loss/len(train_loader)}') # 验证集评估略训练循环本身不复杂，关键是超参数。我一般用AdamW，学习率3e-5，配合线性预热。如果显存不够，可以加torch.cuda.amp做混合精度训练。8.3 推理与后处理def generate_summary(text, model, tokenizer, device): model.eval() inputs = tokenizer( text, max_length=512, truncation=True, return_tensors='pt' ).to(device) with torch.no_grad(): outputs = model.generate( input_ids=inputs['input_ids'], attention_mask=inputs['attention_mask'], max_length=128, min_length=20, num_beams=4, length_penalty=0.8, no_repeat_ngram_size=3, repetition_penalty=1.2, early_stopping=True ) summary = tokenizer.decode(outputs[0], skip_special_tokens=True) summary = post_process(summary) return summary def post_process(text): text = re.sub(r'\s+', '', text) text = re.sub(r'([，。！？、；：])\1+', r'\1', text) if text and text[-1] not in '。！？': text += '。' return text推理时的参数组合是我反复试出来的。num_beams=4平衡质量和速度，length_penalty=0.8鼓励稍短的摘要，no_repeat_ngram_size=3抑制重复，repetition_penalty=1.2进一步减少重复token。后处理做了空格去除、重复标点合并、句末标点补全。9. 不同场景下的策略调整9.1 新闻摘要 vs 技术文档摘要新闻摘要通常要求时效性和信息密度，摘要要短、要快。我一般用beam search，max_length设64到96，length_penalty设0.6到0.8，让摘要更紧凑。技术文档摘要则要求准确性和完整性，摘要可以长一些，max_length设128到256，length_penalty设1.0左右，让模型有更多空间组织语言。新闻摘要的另一个特点是实体多。人名、地名、机构名、产品名频繁出现，模型容易生成错误实体。我一般会在后处理阶段做实体校验，把生成摘要里的实体和原文比对，如果原文没有就删掉或替换。9.2 短文本摘要 vs 长文本摘要短文本摘要（比如微博、评论）输入只有几十到几百字，BART可以直接处理，不需要截断。但短文本的信息密度低，模型容易生成和原文差不多的摘要。我一般会设min_length稍大一些，强制模型压缩。长文本摘要（比如论文、报告）输入可能几千字，超过BART的长度限制。我的处理方式是先用抽取式方法选出关键句，拼接成不超过1024个token的输入，再用BART生成摘要。抽取式方法可以用TextRank或BERTScore，选出和原文主题最相关的句子。9.3 多文档摘要的挑战多文档摘要是把多篇相关文档压缩成一篇摘要，难度比单文档高很多。BART本身是为单文档设计的，直接处理多文档需要把多篇文档拼接起来，但这样会丢失文档间的结构信息。我试过用层次化模型，先对每篇文档生成单文档摘要，再把摘要拼接起来生成最终摘要。效果比直接拼接好，但计算开销大。另一个思路是用图模型建模文档间关系，但实现复杂。对于大多数场景，如果多文档之间主题一致，直接拼接加BART也能用；如果主题差异大，就需要先做聚类或筛选。10. 我个人的一些零散心得做中文摘要这段时间，最大的体会是：模型不是万能的，数据和策略往往比模型本身更重要。我见过太多人花大量时间调模型结构，却忽略了数据清洗和评估设计。实际上，把数据洗干净、把评估做扎实，比换一个更大的模型带来的提升更明显。另一个体会是，中文摘要没有“一招鲜”的方案。新闻、论文、对话、商品评论，每种文本的摘要需求都不一样，解码策略、长度控制、后处理都要相应调整。我一般会针对每个场景单独调一套参数，而不是用一个通用配置打天下。还有一点，人工评估不能省。自动指标只能做参考，最终还是要人来看。我一般会定期抽一批生成摘要，自己读一遍，标记问题，然后针对性优化。这个过程很枯燥，但效果最实在。最后，如果你刚开始做中文摘要，我的建议是：先用小规模数据跑通全流程，确认数据格式、模型加载、训练循环、推理生成都没问题，再逐步扩大数据量和模型规模。不要一上来就上百万数据、最大模型，那样出了问题很难定位。小步快跑，快速迭代，才是做摘要任务最稳妥的方式。