在经典自然语言处理（NLP）时代，“摘要（Summarization）”是一个边界清晰的应用层任务：将一段长文本输入模型，输出一段较短的、保留核心语义的文本。其最终受众是人类读者。然而，随着大语言模型（LLM）成为计算底座，长上下文（Long Context）技术在生产环境中全面落地，传统的摘要概念正在经历一场深刻的泛化与范式转变。
现代工程实践表明，将数百页的原始文本或海量交叉文档直接倾倒进模型的注意力矩阵（Attention Matrix）中，会引发严重的系统级瓶颈：注意力计算、KV Cache 占用和首字延迟都会随上下文长度急剧上升。
在这种背景下，从传统摘要演变成了整个大模型软件栈中的受众为“机器和算法”的语义合成。
- 传统摘要（Summarization）： 它的任务是给定一段文本，在保持原意的前提下缩短字数。本质上是一个过滤器（Filter）。它在原始文本的句群里挑选重要信息，扔掉次要信息。它的产出是原文本的“浓缩版精华”，但没有改变信息的底层拓扑结构。
- 语义合成（Synthesis）： 它是指将离散的、多源的、甚至碎片化的原始事实或材料，通过过滤与重塑，受约束地重组出一个新的、可计算的数据资产。其核心使命，是在有限的计算带宽与认知窗口内，对抗信息熵，实现信息密度的压缩。
一、 范式转移：模型中心论 vs 系统中心论
要理解摘要到合成的演进，首先必须明确两条截然不同的工程主线：早期基于监督微调（SFT）的模型中心论（Model-Centric），与现代基于上下文工程的系统中心论（System-Centric）。
1. 经典专用微调模型的局限
在以 Google T5、FLAN-T5 以及 Pegasus 的 Encoder-Decoder 模型为代表的时代，做摘要的核心手段是训练专用模型。
通过在诸如CNN/DailyMail、XSum 等数据集上进行大规模的“原文-摘要”对监督训练，模型学习到了特定领域的字面截断与改写能力。
然而，在工业界应对超长文本、跨文档整合、强结构化输出的严苛需求时，这类专用小模型（通常在数百M至数十B参数之间）遭遇了难以逾越的硬伤：
- 上下文窗口坍塌：T5 等架构的原生设计仅支持 512 到 1024 个 Token 的窗口，面对现代企业动辄数十万字的财报、法律卷宗，在硬件层面上根本“装不下”输入。
- 结构化控制能力有限：传统摘要模型缺乏强大的底层通用推理能力。当业务需求要求摘要具备 “严格遵循 JSON 模式（Schema）”、“辨别多文档间的时间线冲突” 或 “根据用户角色动态切换分析视角”时，小模型的输出往往出现格式破碎和幻觉泛滥。
它们已经很难承担现代复杂语义合成任务：它们不适合直接处理超长文本、多文档冲突、Schema 约束和角色化分析。
2. 通用基础模型与上下文工程的兴起
进入 Llama 3/3.1、Mistral、Qwen 以及 GPT-4/Claude 3 时代，模型原生上下文窗口被拓宽至 128K 甚至上百万 Token。
此时，工程团队几乎不再为了“摘要”这个单一任务去重新微调模型权重。
我们从以模型为中心的思维模式转向以系统为中心的架构。将基础大模型视为计算运行时环境——自然语言虚拟机（NLVM）：
LLM Runtime | 传统软件 Runtime |
模型权重（frozen parameters） | 编译后的程序二进制（binary） |
Context Window（输入上下文） | 输入数据 + 运行时工作内存（working set） |
KV Cache（注意力缓存） | 局部计算缓存 / memoization / CPU cache |
Prompt（指令 + 示例 +约束） | 程序的运行时输入 + 配置 + API 调用参数 |
Decoding（token-by-token 生成） | 程序执行过程（step-by-step execution loop） |
通用大模型用于计算与推理，而决胜的关键转移到了系统层：如何通过上下文工程，用压缩管道提升数据的‘信息密度’。
维度 | 任务微调方案 （Model-Centric） | 系统架构驱动方案 （System-Centric） |
核心关注点 | 模型权重 （Weights） 与损失函数优化 | 数据熵 （Entropy） 与上下文的高效编排 |
长文本处理机制 | 依赖模型原生窗口扩张（高训练成本） | 依赖层级分块（Hierarchical Map-Reduce）算法 |
结构化与遵循能力 | 较弱，极易突破格式约束 | 极强，依靠原生的结构化解码（Structured Outputs） |
生命周期工程成本 | 极高（数据标注、持续微调、模型漂移风险） | 较低（解耦业务逻辑与模型底座，主攻管道优化） |
二、 信息裁剪 (Information Pruning)
大模型运行时太贵、也太容易 OOM 了，所以我们利用数学和统计学做物理裁剪。
1. 运行时层：KV Cache Compression
这是最底层的、隐式的摘要，直接发生在 GPU 的显存空间内。
在自回归生成（Autoregressive Generation）过程中，键值缓存（KV Cache）的线性增长极大地限制了系统吞吐量。
早期的暴力驱逐策略（如简单的 Rolling Window）会导致模型困惑度（Perplexity）发生灾难性爆炸。
来自 MIT HAN Lab 和 Meta AI 的研究揭示了其中的数学本质：注意力下沉现象（Attention Sinks）（Xiao et al.， ICLR 2024）。在 Softmax 层的作用下，初始的几个 Token（如
[BOS] ）即便没有语义，也会作为“垃圾回收站”强行分流大量的注意力权重。基于此，StreamingLLM 架构诞生——它发现少量初始 token 承担了 attention sink 的稳定器作用。因此，系统在显存中固定保留这些 sink tokens，同时滚动保留最近上下文，并从 GPU 缓存中移除窗口之外的中间历史 token的键值矩阵。通过这种 “attention sinks + recent tokens” 的缓存策略，StreamingLLM 在运行时层面实现了对长历史的稳定内存压缩，使模型能够以近似固定的 KV Cache 开销处理超长流式输入。
严格来说，它不是传统意义上的文本摘要，而是运行时内存压缩；但在信息密度管理的意义上，它完成的是“保留稳定锚点与近期上下文，压缩远端历史状态”的隐式摘要。它通过动态地消除冗余，允许系统能够承受超长的生成序列或高并发工作负载，而不会抛出内存不足 (OOM) 异常。
2. 协议层：Context Compression
在检索增强生成（RAG）系统中，召回的原始文本块往往夹杂着大量的语言冗余（如连接词、重复上下文）。如果直接喂给模型，不仅贵，还会触发“Lost in the Middle”。
根据信息论，自然语言具有天然的红利空间。 微软亚洲研究院（MSRA）提出的 LLMLingua 框架和 Meta AI 的 RECOMP 利用一个小型、轻量级的模型（如 GPT-2 或 1.5B 级别的预训练模型，或者T5、Pegasus 这类专用模型） 作为“信息熵量测器”，计算每个 Token 的条件概率与自信息量。那些在小模型看来极易被预测、条件概率极高的 Token，对下游大型 LLM 而言所包含的“惊奇度（Surprise）”极低。系统在网关处直接对其进行粗粒度（句级）或细粒度（Token级）裁剪，把非关键的助词、修饰词删掉，将低密度的原始召回上下文压缩至数倍。这本质上是一种面向LLM API 的“粗粒度/抽取式摘要”。
其中所用到的小模型不需要理解完整业务，也不需要生成最终结构化输出；它们只需要快速估计原始 prompt 中哪些 token、短语或句子信息密度低，哪些内容对下游主模型贡献有限。通过计算 token 或句子的困惑度、自信息量和可压缩性，把低信息密度的语言冗余、重复上下文和非关键修饰裁剪掉。不是“最终摘要生成器”，而是网关层的压缩算子。
例如，向量数据库（Vector DB）召回了 50k Token 的文档碎片。这时候数据还没进生成模型。我们先用一个轻量模型（如
LLMLingua）计算信息熵，把里面的“的、地、得”、非关键修饰词直接物理裁剪掉，把 50k 变成 15k。这是字词维度的粗筛。该层优化通道容量。它大幅降低了外部 API 成本，并最大限度地减少了 TTFT 延迟，而无需访问或修改下游模型的内部源代码。
三、语义合成 （Synthesis）
运行时层和协议层执行 剪枝 ——它们完全不了解业务规则，而是利用数学和统计学方法去除噪声。
然而，当应用程序需要对复杂数据集进行严格的逻辑控制时，仅靠剪枝是不够的。系统利用 LLM 的语义理解能力来重塑数据 - 合成。
它将 LLM 视为编译器，去打破原始文本松散、无结构的拓扑结构，并在空间、数据和时间轴上将其合成为高密度、可直接参与计算的语义资产。
面向人类阅读的文本摘要不再是主要目标。相反，语义合成是一种机器对机器（M2M）的数据管道。它不再追求字词的物理减少，而是追求信息在逻辑上的高内聚与可计算性。我们在应用层沿着三个正交轴向看看它是如何完成语义重组：
1. 空间轴：Hierarchical Summarization
即使裁剪到了 15k，如果依然超出了单次长文本的推理预算，或者为了防止模型对中间信息的语义丢失，采用类似 Map-Reduce 的分治处理方式：将数百万个 token 的庞大数据集递归分块，并行处理以提取局部特征（Map），并逐层级联合并（Reduce），实现语义维度的重组。
如 OpenAI 在其开创性论文《Recursively Summarizing Books with Human Feedback》所述，面对超大规模文本，试图通过单一庞大窗口一次性解决问题的做法违反了分布式系统的分治原则。只有将摘要视为一种层级化的数据管道，才能在工程上真正实现确定性与高吞吐的平衡。
在工业级层级合成的落地实践中，Map 阶段和 Reduce 阶段不应该使用同一种模型。
如果将千万字级语料全量交给云端 Frontier Model 执行 Map 阶段，不仅成本极高，延迟也不可接受。
更合理的方式是采用异构计算管道（Heterogeneous Pipeline）：
- 在 Map 阶段，任务已经被拆解成单一职责的“原子摘要算子”，每个节点只需要处理局部片段、抽取关键事实、压缩冗余表达，并输出规范化的中间表示（Intermediate Representation, IR）。由于这类任务并发量大、上下文局部、格式约束强，适合使用本地私有化部署、低成本、可量化的现代指令微调 SLM，例如 Qwen-2.5-7B 或 Llama-3-8B 级别模型。
- 只有到了 Reduce 阶段，系统才需要更强的 Frontier Model。此时输入已经不再是低密度原文，而是一组经过压缩和规范化的高密度 IR。模型需要处理的是跨章节、跨时间线、跨主题的语义合并、冲突消解和全局叙事组织。
换句话说，SLM 负责低成本地把原始文本编译成可计算的局部语义单元，Frontier Model 负责在高密度语义空间中完成最终合成。
比如：一份 10 万字的财报，把 15k 切成 5 个叶子节点，并行提炼成 5 个 Local Summary，再 Reduce 合并收敛出一个根节点。得到一个支持多粒度阅读和检索的树状结构：
- 根节点（L0 - Root）： 提供 “上帝视角”总览（适合人类快速扫视，或系统做宏观路由）。
- 中间节点（L1/L2 - Internal Nodes）： 提供按章节、按主题、或按事件线划分的“局部深度摘要”（适合人类定向阅读，或 RAG 算法进行中粒度语义匹配）。
- 叶子节点（L3 - Leaves）： 原始的原始 Chunk / 事实细节，并赋予全局唯一哈希 ID。（用于提供精准的证据链和来源追溯）。
可以通过树的根节点提供 100 字的宏观总览，通过子节点提供特定业务线的千字深度分析，允许用户或检索算法在不同粒度间“放大/缩小（Zoom-in/Zoom-out）”
2. 数据轴：Structured Summarization
为了解决自然语言固有的模糊性与非确定性导致下游系统难以可靠解析的问题，可以在 LLM 的解码阶段对 Logits 概率分布施加结构化约束，使模型输出在语法结构上稳定符合预定义的 Pydantic Model、JSON Schema 或其他数据契约所定义的数据负载（Payload）。
经过约束解码后，模型生成的不再只是自然语言段落，而是具有确定性拓扑结构的机器可读实体（Machine-Readable Entity）。这类输出能够被下游系统直接消费和处理，广泛应用于数据库写入、消息队列传输、状态管理以及自动化工作流编排等 M2M（Machine-to-Machine）场景。
例如，一份企业合规审查摘要并非一段文本，而是一个结构化 JSON 有效负载：
借助 OpenAI Structured Outputs、TypeChat、Outlines、SGLang 等结构化解码框架，系统能够在生成过程中实时约束输出形态，使结果稳定落入 JSON Schema、Pydantic Model 或其他预定义的数据结构之中，从源头降低格式漂移（Format Drift）和解析失败的风险。
3. 时间轴：轨迹摘要（Trace Summarization）
多Agent工作流程（Workflow）执行到第50步时，历史执行日志（Execution Logs）过长，导致后面的Agent无法安装下上下文，或者面对调试时排山倒海的日志无从下手。
所以随着工作流程的推进，后台需要有一个专门的“轨迹摘要算子”，动态将过去的思考队列、工具调用和失败重试压缩为高密度状态快照。从而解决长链Agent/Workflow在执行完成步骤后，由于历史执行日志线性增长而导致提示淹没的痛点。动态将过去的思考队列和工具回执压缩为高密度的状态快照，为系统提供最大限度的可启动性（可观察性）、可复盘性（可重放性）与根因调试支持。
比如，当一个法律AI Agent在检索第14步错误时，人类工程师或监控系统不需要去读取几兆的原始日志，而是通过Trace Summary瞬间看清它的“解题思路”，实现根因分析（Root-Cause Analysis）。
维度 | 信息裁剪 (Information Pruning) | 信息合成 (Information Synthesis) |
层级边界 | 运行时层 (KV Cache) / 协议层 (Gateway) | 应用层 (Application Layer) |
操纵算子 | 统计信息熵、困惑度、注意力矩阵权重 | 大模型语义理解、Schema 语法引导采样 |
系统目标 | 物理侧效率： 降延迟、控成本、防止显存溢出 | 逻辑侧价值： 消除语义模糊、提供可计算资产 |
动作属性 | 业务无关的“减法（Subtractive）” | 业务绑定的“重组（Additive）” |
总结
过去，摘要的目标是让人更快读完一篇文章。现在，摘要正在成为 LLM 基础设施中的一个底层算子：在运行时层压缩记忆，在提示词层过滤冗余，在应用层参与语义重组。真正的范式变化不只是“把文本变短”，而是把非结构化文本转化为可检索、可路由、可验证、可执行的高密度信息资产。
信息裁剪负责降低体积、延迟和成本；语义合成负责重构空间、数据和时间关系。前者让系统活下来，后者让系统真正理解并利用信息。
这就是摘要从 NLP 应用任务演化为 LLM 系统基础设施的根本原因。
- 作者:Fan Luo
- 链接:https://fanluo.me/article/从传统摘要到语义合成
- 声明:本文采用 CC BY-NC-SA 4.0 许可协议，转载请注明出处。
上一篇
Agent Reliability Lives in the Runtime
下一篇
Design Agents Around Workflows, Not Chat Turns