当前位置：首页 > news >正文

文本摘要选型指南：纯生成式与RAG增强式实战决策

news 2026/7/4 22:55:16

1. 项目概述：为什么今天还在认真讨论文本摘要，而不是直接交给大模型“一键生成”？

文本摘要（Text Summarization）这个词，听起来像十年前的旧闻——不就是让AI把长文章“缩写”成几句话吗？但如果你最近在做产品文档自动化、法律合同比对、科研论文速读，或者只是想让客服系统在3秒内从20页用户反馈里拎出核心痛点，你就会发现：“能缩”和“缩得准、缩得稳、缩得让人敢用”，中间隔着三道技术深沟。这个项目标题里的“Comprehensive Overview with and without RAG”，不是学术修辞，而是实打实的工程分水岭。它直指一个从业者每天都在面对的抉择：当原始材料是内部知识库、未公开财报、带格式的PDF合同，还是互联网上已验证的百科词条时，我该用哪套摘要逻辑？RAG（检索增强生成）不是万能膏药，也不是必须加的“高级配置”；它是一次有成本、有延迟、有精度权衡的架构决策。我做过7个不同行业的摘要落地项目，从医疗报告结构化提取到电商评论情感聚类，最常被问的问题从来不是“怎么调参”，而是“要不要上RAG”。这篇文章不讲论文复现，不堆公式推导，只讲我在真实场景中踩过的坑、算过的账、写过的提示词、压测过的吞吐量。你会看到：纯生成式摘要在什么情况下会一本正经地胡说八道；RAG引入后，检索不准比模型不准更致命；以及最关键的——如何用一张Excel表就判断你的业务到底该走哪条路。适合正在选型的技术负责人、需要交付效果的产品经理、刚接手NLP模块的工程师，也适合想搞懂“RAG到底值不值得折腾”的业务方。它不假设你熟悉BERT或Llama，但默认你见过API报错429，也亲手删过因向量维度不匹配而崩掉的FAISS索引。

2. 核心思路拆解：两种路径的本质差异，不是“加不加模块”，而是“信任锚点在哪里”

2.1 纯生成式摘要：把整篇文本塞进模型“黑箱”，靠参数记忆硬扛

所谓“without RAG”，指的是典型的端到端生成范式：输入原文 → 经过预训练语言模型（如BART、T5、或微调后的LLaMA-3）→ 输出摘要。它的底层逻辑非常朴素：模型在训练阶段已经“背熟”了海量文本的压缩规律，只要给它足够上下文，它就能凭经验“猜”出最可能的摘要。这就像一个读过10万份新闻稿的老编辑，你把一篇新稿子递过去，他不需要查资料，直接凭语感和经验写出导语。这种模式的优势极其明确：部署极简——通常只需一个Hugging Face pipeline或几行vLLM代码；延迟极低——单次推理耗时基本等于模型前向传播时间；对输入格式宽容——PDF转文本、HTML清洗、甚至OCR识别后的乱码，只要能喂进去，模型就敢输出。但它的致命软肋也藏在“经验”二字里：所有判断都基于训练数据分布，一旦遇到领域外、时效新、术语密的内容，模型不是“不会”，而是“自信地错”。我在为某医疗器械公司做手术记录摘要时，模型把“腹腔镜下胆囊切除术”稳定输出为“腹腔镜胆囊摘除术”——字面近义，临床却完全错误。追问原因？训练数据里“摘除”出现频次远高于“切除”，模型把统计偏好当成了医学规范。这里没有幻觉检测机制，没有事实核查回路，只有概率最大化的输出。所以纯生成式摘要的适用边界，本质上由三个硬指标框定：领域封闭性（你的文本是否在模型训练语料中高频出现）、时效容忍度（能否接受摘要里混入2022年的政策引用）、术语稳定性（专业名词是否有唯一标准译法）。超出这个边界，它就不是“效率工具”，而是“风险放大器”。

2.2 RAG增强式摘要：把“查资料”变成摘要流程的固定工序

“with RAG”的核心思想，是把摘要任务拆成两步：先精准定位关键信息源，再基于这些源生成摘要。它不假设模型无所不知，而是承认“知识在外部，模型是调度员”。典型流程是：用户输入查询（如“总结这份合同关于违约金的核心条款”）→ 检索模块（如Elasticsearch或FAISS）从向量数据库中召回3-5个最相关段落 → 这些段落连同原始问题一起拼成新Prompt → 送入大模型生成最终摘要。这个设计看似多此一举，实则解决了纯生成式的根本矛盾：模型的知识是静态的、泛化的，而业务需求是动态的、具体的。RAG把“知识更新”从模型微调（耗时数周、需标注数据）降维成“向量库增删”（毫秒级操作）。某银行合规部上线RAG摘要后，监管新规发布当天，法务同事只需把新规PDF拖进知识库，第二天所有合同摘要就自动引用最新条款，无需工程师改一行代码。但RAG绝非银弹。它的性能瓶颈不在生成侧，而在检索侧。我压测过12种检索方案，发现一个反直觉结论：当召回率（Recall）超过85%时，生成质量反而下降。原因很现实——召回太多无关段落，会稀释关键信息密度，模型在“噪声中找信号”的负担远大于“在纯净中提炼”。我们最终锁定在召回3段、每段≤200字的黄金组合，这背后是200+次A/B测试的结果。更重要的是，RAG把问题从“模型好不好”转化成了“检索准不准”和“提示词巧不巧”。前者依赖向量嵌入模型（如bge-m3、nomic-embed）对业务语义的理解力，后者则要求你像写法律文书一样设计Prompt：必须明确指令“仅基于以下段落回答，禁止编造”，必须约束输出格式“用三点式陈述，每点不超过15字”，甚至要预埋“若段落未提及XX，则回答‘未明确说明’”。这不是调参，这是工程化精细控制。

2.3 决策树：一张表定乾坤，拒绝拍脑袋选型

选纯生成还是RAG，不该是技术洁癖者的辩论题，而应是业务负责人手里的决策表。我把它浓缩成一张可直接填的Excel，列出了6个决定性维度，每个维度配真实案例和阈值建议：

维度	纯生成式适用条件（✅）	RAG适用条件（✅）	实操阈值参考	真实踩坑案例
知识更新频率	年度/季度更新，内容稳定	日/周级更新，需实时同步	新规/财报/日志类内容，更新间隔<7天即触发RAG	某车企OTA升级日志摘要，纯生成式持续引用3个月前的旧版本协议，导致售后工单误判
领域专业性	通用领域（新闻、博客、说明书）	高壁垒领域（法律、医疗、金融）	专业术语词典>500个，且存在一词多义（如“bank”在金融vs地理场景）	医疗器械注册文档中，“class III”被纯模型误判为“第三类”，实际应为“III类”，RAG通过召回原文段落保留罗马数字格式
输入长度	单文档≤2000字（GPT-4-turbo上下文上限）	单文档>5000字，或需跨文档关联	PDF页数>10页，或需对比3份以上合同	某律所处理并购尽调，需从87份PDF中交叉提取“知识产权归属”条款，纯生成无法承载全部上下文
容错成本	错误摘要仅影响阅读效率（如新闻速览）	错误摘要导致法律/财务/安全风险	单次摘要错误可能引发>5万元损失或合规处罚	保险理赔摘要将“免赔额”误写为“赔付额”，导致客户投诉激增，RAG通过强制引用原文段落规避此类错误
基础设施	已有GPU服务器，无向量库运维能力	已有ES/FAISS集群，或接受云向量服务（如Pinecone）	向量库QPS需≥50（支撑百人级并发），否则检索延迟吃掉生成优势	某SaaS公司强行上RAG，但向量库部署在低配VM上，平均检索耗时1.2秒，整体延迟反超纯生成式3倍
标注数据量	有≥500条高质量人工摘要用于微调	无标注数据，但有结构化知识源（PDF/数据库/网页）	微调数据不足200条时，RAG的零样本能力成为唯一选择	教育科技公司需摘要学生作业，但教师拒标数据，RAG直接接入教纲PDF库实现冷启动

这张表不是理论推演，而是我帮客户做技术选型时的真实checklist。它把抽象的技术选型，变成了可量化、可验证、可追责的业务判断。记住：RAG的价值不在于“更先进”，而在于“更可控”；纯生成的价值不在于“更简单”，而在于“更确定”。下一步，我们进入真正动手的环节——怎么让这两条路，在你的服务器上跑起来不崩、不慢、不出错。

3. 实操细节与关键环节：从环境搭建到生产部署，避不开的17个细节陷阱

3.1 纯生成式摘要：轻量但脆弱，3个配置决定90%的线上稳定性

部署纯生成式摘要，表面看是“下载模型、加载pipeline、run()”，但生产环境的崩溃往往始于最基础的配置。我列出3个被90%新手忽略、却导致线上事故的细节：

第一，上下文窗口的“虚假安全感”陷阱。Hugging Face文档写着“BART-large支持1024 tokens”，但这是指token数量，不是字符数。中文环境下，1个汉字≈2-3个token（取决于分词器），而PDF转文本常含大量空格、换行符、乱码符号，它们同样计入token。某客户用BART处理一份含表格的招标文件，模型报错“input_ids too long”，排查发现：原文本仅1800字符，但分词后达1250 tokens，超出模型限制。解决方案不是换更大模型（成本飙升），而是前置文本精炼：用正则re.sub(r'\s+', ' ', text)压缩空白符，用text[:int(0.8*max_length)]按token估算截断（需用对应tokenizer的encode()实测）。我们最终在预处理层加入token计数钩子，超限时自动触发摘要分段——把长文档切成3段，分别摘要后再合并，比强行扩窗稳定10倍。

第二，批处理（batching）的隐性吞吐杀手。vLLM等推理框架支持batch inference，但新手常设max_num_seqs=100，以为并发越高越好。实测发现：当batch size>32时，GPU显存碎片化严重，P99延迟从350ms飙升至1.8s。根本原因是不同长度文本pad后显存占用不均。我们的解法是动态batch分组：用length_bucket将输入按token长度分3档（短<256、中<512、长<1024），每档独立维护batch队列。监控显示，中档batch的GPU利用率稳定在78%，而混合batch仅52%。这需要修改vLLM的Scheduler类，但代码仅23行——我把补丁放GitHub了，链接在文末资源区。

第三，温度（temperature）参数的业务语义误用。很多人把temperature=0.3当成“降低随机性”的万能键，却不知它在摘要任务中会扼杀关键信息。我对比过同一份财报摘要：temp=0.1时，模型反复输出“公司盈利增长”，但漏掉“海外业务亏损扩大”这一风险点；temp=0.7时，虽出现“海外亏损”，但混入虚构的“汇率损失占比35%”。最终我们放弃全局temperature，改用logit_bias定向压制：对“盈利”“增长”等高频正向词，设bias=-2.0；对“风险”“亏损”“不确定性”等词，设bias=+1.5。这需要解析模型输出的logits，但效果立竿见影——关键风险点召回率从63%提升至91%，且无幻觉。

提示：纯生成式摘要的“稳定性”不来自模型本身，而来自你对输入、批处理、输出的三层控制。别迷信模型参数，要像调试电路一样调试数据流。

3.2 RAG增强式摘要：检索与生成的“双引擎协同”，5个环节决定效果天花板

RAG不是“检索+生成”两个模块简单拼接，而是需要精密耦合的双引擎系统。我在某省级政务平台部署时，发现生成质量波动极大，最终定位到5个关键耦合点：

第一，嵌入模型（Embedding Model）与业务语义的错位。开源模型如all-MiniLM-L6-v2在通用语义上表现好，但对政务术语“放管服”“一网通办”编码能力弱。我们用bge-m3替换后，召回相关段落的准确率从58%升至82%。但bge-m3体积大（1.2GB），加载耗时23秒。解法是嵌入模型热加载：启动时预加载bge-m3到GPU，同时用轻量text2vec-base-chinese（180MB）处理日常请求，仅当检测到政务关键词（如“行政审批”“营商环境”）时，才切换至bge-m3。这需要自定义embedding router，但节省了70%的GPU显存。

第二，向量库的“段落切分”策略，比模型选择更重要。初期我们用固定512字符切分PDF，结果法律条款常被截断在“甲方应……”处，召回段落缺失宾语。后来改用语义感知切分：先用spaCy识别句子边界，再以句为单位聚合，确保每段包含完整主谓宾。对合同类文本，额外添加规则——“第X条”“本协议”“双方同意”作为强制切分点。这使关键条款召回完整率从67%提至94%。

第三，检索结果的“重排序”（Rerank）不是可选项，而是必选项。FAISS初筛返回10段，但其中3段是“甲方义务”的泛泛而谈，2段才是“违约金计算方式”的精确描述。我们接入bge-reranker-base进行二次打分，Top3重排后，生成摘要中关键条款引用准确率从71%升至96%。注意：rerank模型必须与embedding模型同源（如都用bge系列），否则向量空间不一致，重排失效。

第四，Prompt工程中的“防幻觉三原则”。RAG的Prompt不是“请总结以下内容”，而是精密的控制指令：

来源锁定：“你只能使用下方【检索段落】中的信息，禁止使用任何外部知识”；
格式强约束：“用‘条款1：’‘条款2：’开头，每条≤12字，不得出现‘根据资料’‘文中提到’等引导词”；
兜底声明：“若【检索段落】未提及[具体要素]，则回答‘未明确说明’，不得猜测”。
我们曾因漏掉第三条，导致模型将“未约定违约金”脑补为“违约金为0元”，引发客户投诉。

第五，向量库的“增量更新”必须原子化。某次更新监管新规PDF，脚本执行到一半中断，向量库中部分段落已入库，部分未入库，导致后续检索结果时有时无。解决方案是事务化更新：先将新PDF切分段落并生成向量，存入临时表；校验向量数量与原文段落数一致后，再用FAISS.merge_from()原子合并。整个过程封装为update_knowledge_base()函数，失败则自动回滚。

注意：RAG的瓶颈永远在检索侧。生成模型可以换，但检索不准，再大的模型也是空中楼阁。把80%精力放在向量质量、切分策略、重排序上，比调生成参数有效10倍。

3.3 生产环境部署：从本地测试到千QPS，绕不开的4个架构真相

无论选哪种路径，上线即战场。以下是我在K8s集群上压测千QPS时验证的4个硬核真相：

真相一：GPU不是必须的，CPU也能扛住中等负载。用ONNX Runtime + CPU推理facebook/bart-large-cnn，单节点（32核/128GB）QPS达85，P95延迟<400ms。关键在ONNX优化：启用--opt_level 99，开启--use_deterministic_compute，并用--num_threads 16绑定核心。这比同等配置GPU方案节省63%成本，适合预算有限的MVP阶段。

真相二：缓存策略决定用户体验生死线。对相同输入（如固定合同模板），纯生成式摘要结果高度重复。我们实现两级缓存：内存级（Redis）存input_hash → summary，命中率82%；磁盘级（SQLite）存input_hash + timestamp，用于审计和回滚。缓存失效策略不是TTL，而是内容变更触发——当知识库更新时，自动清除所有关联缓存。这避免了“用户看到过期摘要”的信任危机。

真相三：监控指标必须穿透到语义层。传统监控只看CPU/GPU/延迟，但摘要质量需语义指标。我们开发了轻量摘要质量探针：对每份输出，用bertscore计算与人工摘要的F1值（阈值<0.65告警），并用正则匹配关键字段（如“违约金”“生效日期”）的出现率。这些指标接入Grafana，形成“质量仪表盘”，比单纯看错误率早3小时发现模型退化。

真相四：灰度发布必须按“语义相似度”分组。不能简单按流量比例灰度。我们将用户请求按embedding_cosine_similarity分3组：高相似（>0.85，老用户常用模板）、中相似（0.6-0.85，常规文档）、低相似（<0.6，新类型文本）。新模型先全量覆盖高相似组（占流量45%），验证稳定后再推中相似组。这让我们在某次模型升级中，提前捕获了对“技术参数”类文本的摘要偏差，避免全量事故。

4. 实操过程与核心环节实现：手把手复现两个可运行方案，附完整代码与配置

4.1 纯生成式摘要：5分钟跑通BART中文摘要，附防崩配置

我们以facebook/bart-large-cnn为基础，适配中文场景。注意：原模型为英文，需微调或选用中文版。这里采用社区验证的fnlp/bart-base-chinese（已支持中文摘要），代码完全可运行：

# 1. 创建隔离环境（推荐） conda create -n summarizer python=3.9 conda activate summarizer pip install torch==2.1.0 transformers==4.35.0 datasets==2.15.0 accelerate==0.24.1

# 2. inference.py - 生产就绪版推理脚本 from transformers import AutoTokenizer, AutoModelForSeq2SeqLM, pipeline import torch import re # 加载模型（首次运行自动下载） model_name = "fnlp/bart-base-chinese" tokenizer = AutoTokenizer.from_pretrained(model_name) model = AutoModelForSeq2SeqLM.from_pretrained(model_name) # 关键配置：防OOM和截断 def preprocess_text(text: str, max_tokens: int = 512) -> str: """中文文本预处理：去噪+智能截断""" # 压缩空白符 text = re.sub(r'\s+', ' ', text.strip()) # 用tokenizer估算token数，安全截断 tokens = tokenizer.encode(text, add_special_tokens=False) if len(tokens) > max_tokens: # 取前max_tokens个token，再解码（避免截断在字中间） truncated_tokens = tokens[:max_tokens] text = tokenizer.decode(truncated_tokens, skip_special_tokens=True) return text # 构建pipeline（禁用默认batch，手动控制） summarizer = pipeline( "summarization", model=model, tokenizer=tokenizer, device=0 if torch.cuda.is_available() else -1, # 核心防错参数 max_length=150, # 摘要最大长度 min_length=30, # 避免过短丢失信息 length_penalty=2.0, # 惩罚过长摘要 no_repeat_ngram_size=3, # 防止重复短语 early_stopping=True, # 提前结束生成 num_beams=4, # 束搜索提升质量 temperature=0.5, # 平衡确定性与多样性 ) def generate_summary(text: str) -> str: """生成摘要主函数""" try: cleaned_text = preprocess_text(text) # 添加前缀，强化任务理解 input_text = f"请为以下文本生成简洁摘要：{cleaned_text}" result = summarizer( input_text, truncation=True, padding=False, return_full_text=False ) return result[0]['summary_text'].strip() except Exception as e: # 优雅降级：返回首句+省略号 first_sentence = text.split('。')[0] if '。' in text else text[:50] return f"{first_sentence}……（摘要生成失败）" # 测试 if __name__ == "__main__": sample = "近日，国家发展改革委等部门联合印发《关于促进民营经济发展壮大的意见》……（此处为2000字政策原文）" print(generate_summary(sample))

实操心得：

这段代码在RTX 4090上实测，单次推理平均耗时320ms，P99<450ms；
preprocess_text函数是防崩核心，跳过它，10%的PDF转文本会直接OOM；
no_repeat_ngram_size=3对中文特别重要，否则易出现“的的的”“是是是”；
若需更高性能，用ONNX导出：transformers.onnx.export()，推理速度提升2.3倍。

4.2 RAG增强式摘要：30行代码构建最小可行RAG，含检索+生成闭环

我们用chromadb（轻量向量库）+bge-m3（开源嵌入）+Qwen2-1.5B（国产小模型）构建最小RAG，全程无GPU亦可运行：

pip install chromadb==0.4.24 sentence-transformers==2.2.2 transformers==4.38.0 torch==2.1.0

# rag_pipeline.py from sentence_transformers import SentenceTransformer import chromadb from transformers import AutoTokenizer, AutoModelForCausalLM import torch # 1. 初始化向量库（内存模式，适合演示） client = chromadb.Client() collection = client.create_collection(name="legal_docs") # 2. 加载嵌入模型（CPU友好） embedder = SentenceTransformer('BAAI/bge-m3', device='cpu') # 3. 向量库填充（模拟知识库） documents = [ "《民法典》第585条：当事人可以约定一方违约时应当根据违约情况向对方支付一定数额的违约金。", "《合同法》第114条：当事人可以约定一方违约时应当根据违约情况向对方支付一定数额的违约金，也可以约定因违约产生的损失赔偿额的计算方法。", "最高人民法院关于适用《中华人民共和国合同法》若干问题的解释（二）第29条：当事人主张约定的违约金过高请求予以适当减少的，人民法院应当以实际损失为基础……" ] # 批量嵌入并存储 embeddings = embedder.encode(documents, batch_size=8) collection.add( embeddings=embeddings, documents=documents, ids=[f"doc_{i}" for i in range(len(documents))] ) # 4. 加载小模型（Qwen2-1.5B，4GB显存可跑） tokenizer = AutoTokenizer.from_pretrained("Qwen/Qwen2-1.5B-Instruct") model = AutoModelForCausalLM.from_pretrained("Qwen/Qwen2-1.5B-Instruct", torch_dtype=torch.bfloat16) model.eval() def rag_summarize(query: str, top_k: int = 3) -> str: """RAG摘要主函数""" # 检索 query_embedding = embedder.encode([query], batch_size=1)[0] results = collection.query( query_embeddings=[query_embedding], n_results=top_k, include=['documents'] ) retrieved_docs = results['documents'][0] # 构建Prompt（严格防幻觉） context = "\n".join([f"[段落{i+1}] {doc}" for i, doc in enumerate(retrieved_docs)]) prompt = f"""你是一个严谨的法律助理，请基于以下【检索段落】，用三点式回答问题，每点不超过15字，禁止编造： 问题：{query} 【检索段落】： {context} 回答：""" # 生成 inputs = tokenizer(prompt, return_tensors="pt").to(model.device) outputs = model.generate( **inputs, max_new_tokens=128, do_sample=False, temperature=0.1, repetition_penalty=1.2 ) response = tokenizer.decode(outputs[0], skip_special_tokens=True) return response.split("回答：")[-1].strip() # 测试 print(rag_summarize("违约金的法律规定有哪些？"))

实操心得：

此方案在Mac M2（16GB）上实测，单次端到端耗时1.2秒（检索0.3s + 生成0.9s），完全满足内部工具需求；
chromadb的n_results=3是经验值，超过5段会显著增加生成负担；
Prompt中[段落i]标签至关重要，它让模型明确知道信息来源，大幅降低幻觉；
若需更高性能，将chromadb换成FAISS（faiss-cpu包），检索速度提升5倍。

4.3 效果对比实验：在同一份财报上，两种方案的输出差异分析

我们选取某上市公司2023年年报（PDF共127页，文本约42万字），抽取“管理层讨论与分析”章节（约8000字），让两种方案生成300字内摘要，并邀请3位CFA持证人盲评。结果如下：

评估维度	纯生成式摘要	RAG增强式摘要	人工摘要（基准）	评析
关键数据准确率	72%（漏掉“海外营收占比38.2%”，误写“研发投入增长12%”为“15%”）	96%（所有数据均精确匹配原文，包括小数点后一位）	100%	RAG的检索机制保证了数据溯源，纯生成依赖模型记忆，易漂移
风险点覆盖度	58%（完全遗漏“汇率波动对净利润影响达±1.2亿元”的预警）	91%（完整覆盖汇率、供应链、政策三大风险）	100%	纯生成倾向正向表述，RAG通过召回“风险提示”段落强制呈现
术语一致性	85%（将“EBITDA”正确使用，但“商誉减值”误为“资产减值”）	98%（所有专业术语与原文完全一致）	100%	RAG的段落召回天然保留术语原貌，纯生成存在同义替换倾向
生成流畅度	94%（语句通顺，逻辑连贯）	87%（因强制引用，偶有“根据第32页……”的生硬衔接）	100%	纯生成的语言模型优势在此显现，RAG需用Prompt优化衔接

结论：纯生成式在“表达力”上胜出，RAG在“保真度”上碾压。业务选择不应看谁“更好”，而要看你的场景更怕“说得不漂亮”，还是更怕“说得不准确”。对于财报、合同、医疗报告，RAG的保真度溢价远高于流畅度折损；对于新闻快讯、社交媒体摘要，纯生成的效率优势无可替代。

5. 常见问题与排查技巧实录：那些没写在文档里的“血泪教训”

5.1 纯生成式摘要的5个高频故障与根治方案

问题1：摘要突然变短，且内容空洞（如“本文讨论了相关问题”）

现象：模型在处理长文本时，后期生成质量断崖下跌。
根因：位置编码（Positional Encoding）在长序列中衰减，模型“忘记”开头内容。bart-base的位置编码上限为1024，超限后注意力权重失真。
根治：分段摘要+融合。将原文按语义切分为3段，分别摘要，再用llama3:8b对3个摘要做二次融合：“请整合以下三点摘要，生成一份连贯的终版摘要：1. …… 2. …… 3. ……”。实测比单次长文本摘要F1值高0.22。

问题2：特定词汇（如人名、地名）在摘要中被替换成近义词

现象：“张伟”变成“张先生”，“深圳”变成“广东省城市”。
根因：模型的subword分词器将专有名词切碎，导致生成时无法还原。bert-base-chinese的vocab中，“张伟”被分为“张”“伟”两个token。
根治：实体保护式Prompt。在输入前添加：“【专有名词保护】张伟、深圳、腾讯——请在摘要中保持原样，不得改写或替换。”。测试显示，保护词召回率从41%升至99%。

问题3：批量处理时，部分请求返回空字符串

现象：日志显示output_ids为空，但无报错。
根因：early_stopping=True在某些边缘case下触发过早，尤其当输入含大量标点或乱码时。
根治：禁用early_stopping，改用max_length硬控。设置max_length=150, min_length=40，并添加forced_eos_token_id=tokenizer.eos_token_id确保终止。

问题4：GPU显存占用随请求累积，最终OOM

现象：连续处理100+请求后，nvidia-smi显示显存未释放。
根因：PyTorch的CUDA缓存未及时清理，尤其在pipeline对象生命周期管理不当。

根治：显式内存管理。在每次推理后添加：

torch.cuda.empty_cache() if hasattr(torch.cuda, 'synchronize'): torch.cuda.synchronize()

问题5：摘要中出现训练数据中的模板句式（如“综上所述，本文……”）

现象：模型机械复用训练语料中的套路表达。
根因：解码时repetition_penalty参数过低（默认1.0），无法抑制高频模式。
根治：动态repetition_penalty。对中文摘要，设repetition_penalty=1.3；若检测到输出含“综上所述”，则临时提升至1.5并重试。