文档摘要实战：抽取+重写双阶段本地化方案

1. 项目概述：当文档像山一样堆过来，AI summarization 是怎么帮人“一眼看穿”的

你有没有过这种体验：邮箱里躺着一封30页的法律意见书，会议前5分钟才发来；团队共享盘里塞满了上万字的产品需求文档，但老板只问“核心改动有哪三条”；或者你刚下载完一篇顶会论文，摘要读了三遍还是没搞清它到底比前人强在哪。这时候，你不是缺时间，是缺一个能替你“快速翻书、精准抓重点、还能讲清楚”的搭档。这正是文档摘要（Document Summarization）技术的真实战场——它不追求把原文压缩成一句口号，而是要像一位经验丰富的编辑，读懂结构、拎出主干、保留关键论据和数据，最后交给你一份“可信赖的浓缩版”。我从2018年开始在金融合规和医疗科研两个强文本领域落地这类系统，见过太多团队用规则模板硬套PDF，结果摘要里漏掉关键免责条款，或者把临床试验的p值误标为“次要结果”。真正的难点从来不在模型多大，而在于：如何让AI理解“对谁有用”和“什么才算重点”。比如给法务看的合同摘要，必须突出责任主体、违约金计算方式、管辖法院；给医生看的病例摘要，则要锁定主诉、关键检查指标、用药禁忌。这篇文章要讲的，就是一套经过真实业务验证的、可拆解、可调试、不依赖黑盒API的本地化摘要方案。它不讲“Transformer有多伟大”，只讲我在银行风控系统里怎么把一份27页的反洗钱尽调报告，压缩成400字内、且法务总监签字认可的要点清单；也不吹“SOTA指标”，只说为什么我们最终放弃纯生成式模型，转而用“抽取+重写”双阶段架构——因为监管审计要求每一条摘要结论都必须能在原文中定位到确切句子。关键词里的“Towards AI - Medium”只是原始出处，但我们要做的，是把它变成你明天就能在自己电脑上跑起来的、带完整错误处理和效果评估的实操手册。

2. 内容整体设计与思路拆解：为什么“抄论文公式”在真实场景里会翻车

2.1 摘要任务的本质分层：从“写得像人”到“用得放心”

很多人一提文档摘要，脑子里立刻跳出“用LLM直接生成”。这没错，但错在跳过了最关键的前置判断：你的文档类型和使用场景，决定了该用哪种技术路径。我把它拆成三层，每一层都对应着完全不同的技术选型逻辑：

第一层是文档结构层。新闻稿、学术论文、法律合同、产品说明书，它们的“骨架”天差地别。新闻稿遵循倒金字塔结构，首段即核心；学术论文有固定IMRAD（引言-方法-结果-讨论）框架；而一份采购合同，关键信息可能分散在“定义条款”“付款条件”“违约责任”三个不同章节，且大量使用“除非……否则……”这类嵌套逻辑。我试过直接用通用模型处理某跨国药企的GMP合规文件，结果摘要把“洁净区温湿度控制标准（附录B第3.2条）”和“人员更衣流程（附录C第1.5条）”混在一起描述，法务直接否决——因为审计时必须能按条款编号溯源。所以，结构识别不是可选项，是生死线。

第二层是信息权重层。同一份文档，不同角色关注点截然不同。销售看合同，盯的是交付周期和付款节点；法务看同一份合同，抠的是不可抗力定义和争议解决方式；财务则只关心开票条款和税率适用。这意味着摘要系统不能只有一个输出，而必须支持“角色视角配置”。我们给某医疗器械公司做的方案里，就内置了销售/法务/注册三个预设模板，底层共用同一套实体识别引擎，但摘要生成时会动态加权：销售模板给“交货期”“验收标准”打0.9权重，法务模板则给“知识产权归属”“保密义务期限”打0.95权重。这个权重不是拍脑袋定的，而是基于过去6个月法务部实际修改合同的批注热力图统计出来的。

第三层是可信度保障层。这是企业级应用和玩具项目的分水岭。监管机构或内部审计不会因为你用了“最新大模型”就放过你。他们要的是：摘要里的每句话，都能在原文中找到支撑句；关键数据（如金额、日期、百分比）必须零误差；逻辑关系（因果、转折、并列）不能被扭曲。纯生成式模型（如直接用ChatGLM生成摘要）在这里天然有缺陷——它可能“编造”一个看似合理的结论，但原文根本没提。所以我们最终采用“抽取式初筛 + 重写式精炼”的混合架构：先用BERT类模型精准抽取出最相关的10-15个句子（保证可追溯），再用轻量级T5模型对这些句子做语法重构和冗余删减（保证可读性）。整个过程像老编辑的手工活：先圈出所有候选句子，再逐句判断是否必要，最后润色成通顺段落。

2.2 技术路线取舍：为什么放弃“端到端大模型”，选择“模块化组装”

2023年我们曾用7B参数的Qwen-7B做端到端摘要测试，指标（ROUGE-L）比我们的混合方案高1.2分。但上线试运行一周后，客户叫停了——问题出在两处：一是长文档（>5000字）处理时显存溢出，二是摘要中出现了原文没有的数值推断。比如原文写“患者A治疗后白细胞计数从3.2×10⁹/L升至4.1×10⁹/L”，模型摘要写成“白细胞提升约28%”，这个百分比计算是模型自己加的，但临床指南明确禁止在摘要中出现任何未明示的计算结果。这让我们彻底放弃“一步到位”的幻想。

转而采用模块化设计，核心是三个可独立替换的组件：

• 结构解析器（Structure Parser）：不依赖通用OCR，而是针对PDF/DOCX格式定制。对PDF，我们用pdfplumber精确提取文本坐标，识别标题层级（通过字体大小+缩进+加粗组合判断）；对DOCX，直接解析XML结构，获取Heading 1/2/3标签。这步确保“第3章 第二节”这样的结构信息不丢失，后续才能按章节做局部摘要。

• 关键句抽取器（Key Sentence Extractor）：选用微调后的bert-base-chinese（中文场景）或distilroberta-base（英文场景），但损失函数做了改造——不仅优化句子与文档主题的相关性，还加入“实体密度”约束：强制模型优先选择包含人名、机构名、数值、条款编号的句子。训练数据来自我们标注的2000份真实合同和研报，每份都标出法务/分析师手动圈出的关键句。

• 重写精炼器（Rewrite Refiner）：用facebook/bart-base微调，但输入不是整篇文档，而是抽取的12-15个句子组成的序列。这里有个关键技巧：我们在句子间插入特殊分隔符<s>，并让模型学习“跨句指代消解”——比如前句提到“甲方”，后句用“其”指代，模型必须能正确还原。这避免了纯抽取式摘要常见的“句子拼接生硬”问题。

这种设计牺牲了理论上的最高指标，但换来的是：可解释（每句摘要都能回溯）、可调试（哪个模块出问题换哪个）、可审计（所有中间结果可导出）。就像修车，你宁可换三个小零件，也不愿整个发动机返厂。

2.3 成本与效果的现实平衡：为什么不用100B大模型，而选7B以下

常有人问：“你们不用更大模型，是不是效果不够好？”我的回答是：在真实业务里，“够好”不等于“最好”，而是“刚好满足阈值且成本可控”。我们做过详细测算：用A10显卡跑一次10K字文档的端到端摘要，Qwen-72B需23秒，显存占用24GB；而我们的混合方案（抽取+重写）仅需3.8秒，显存峰值6.2GB。这意味着：同样一台服务器，前者每小时处理156份文档，后者能处理947份。对日均处理2000份合同比的客户，这直接决定要不要额外采购两台GPU服务器——成本差额是每年47万元。

更关键的是效果边际递减。我们用ROUGE-L和人工评估双轨测试，在金融研报摘要任务上对比了不同规模模型：