大模型处理长文本摘要时应该如何切分、压缩和校验？

简化版

长文本摘要应先明确读者、用途和必须保留的信息，再按章节、段落、表格等结构切分。局部阶段优先抽取带来源的事实、数字和结论，聚合阶段负责去重、显式保留冲突并控制篇幅，最后用关键事实召回、引用支持和数字核对验收。直接把全文塞入长窗口既可能超预算，也无法保证中部证据被稳定利用。

详细版

方案取决于摘要用途。通用概览可采用结构化 Map-Reduce，连续叙事可用 Refine，但要防顺序偏置；面向问题的摘要应先检索相关证据，抽取式摘要适合高保真要求，归纳式摘要则改善可读性但风险更高。

切块不能破坏表格、公式、代码和条款边界，首轮也不能压缩过狠，因为后续阶段无法恢复已丢信息。每个局部结果应携带文档 ID、页码、事实类型和置信状态；最终摘要要检查关键实体、数字、否定词、时间范围和跨段关系，并能回链原文。

完整版教学

长文摘要是有损信息管道：上游漏掉的事实，下游写得再流畅也无法恢复，因此每一级都要保存来源并测召回。

一、先定义摘要用途与保真目标

面向高管的决策摘要、面向审计的事实摘要和针对具体问题的摘要，需要保留的信息不同。开始前应定义目标读者、长度、关键事实类别、是否必须引用，以及冲突与未知项如何表达。

长文摘要的难点不是把每段压短，而是在超出上下文预算时仍保留全局事实、跨段关系和可追溯证据。没有保真目标时，压缩率越高可能只是丢失越严重。

二、核心机制怎么工作

长文本摘要的难点是上下文预算、信息覆盖和事实一致性。工程上通常采用 map-reduce：map 阶段让模型在每个 chunk 内抽取事实和要点，reduce 阶段合并去重、排序和压缩，再根据目标读者生成最终摘要。

切块要尊重章节和语义边界，并为跨块实体保留少量重叠或全局索引。局部摘要先抽取事实与出处，聚合阶段再去重、处理冲突和控制长度；否则第一轮遗漏会在后续压缩中永久消失。

三、带数字的拆解

一份 120000 token 的研报，如果模型窗口可用 32000 token，直接输入会溢出。可以按 4000 token 切成 30 块，每块生成 300 token 要点，总中间结果约 9000 token，再进行二级汇总。

chunk_count = ceil(total_tokens / chunk_size)
intermediate_tokens = chunk_count * summary_tokens_per_chunk
压缩比 = final_summary_tokens / total_tokens

四、流程图和工程落点

可以把它拆成下面这条链路来讲：

原始文档
   |
结构化切分
   |
分块抽取事实、数字、结论
   |
合并去重与冲突检测
   |
生成摘要
   |
引用回链与事实校验

五、和相近方案怎么区分

策略	优势	风险
直接长上下文	实现简单、保留全文	成本高且容易注意力稀释
MapReduce 摘要	可扩展、成本可控	早期压缩可能丢信息
检索式摘要	面向问题更精准	依赖检索召回
抽取式摘要	事实风险较低	表达不够自然

六、上线或训练时最容易踩的坑

切分时把表格、公式或代码拆断，会让局部摘要失真。
最终摘要必须保留关键数字出处，否则看似流畅但难以信任。
财务数字、否定词和时间范围不能只靠生成式压缩，应先抽取成结构化事实再进入总摘要。
Refine 顺序会造成早期内容偏置，可改变顺序做一致性检查或用层次树平衡各章节权重。

七、怎样评测覆盖、忠实与可读性

把原文标成关键事实清单，分别统计摘要的事实召回率、无证据新增率、数字一致率和引用定位准确率。可读性与压缩率另行报告，不能用“读起来不错”的总分掩盖遗漏。

例如原文有 80 条关键事实，摘要覆盖 68 条，其中 4 条表述无证据支持，则事实召回为 68/80=85%，还要单独记录 4 条新增风险。对不同长度预算画质量曲线，选择关键事实召回开始陡降之前的拐点，并对高风险文档保留人工抽检。

八、常见误区与追问

误区：上下文窗口越长就越不需要摘要链路。 长窗口仍有成本、注意力稀释和输出预算限制，百万字文档也常超过可用窗口。
误区：每个 chunk 等长切分就一定合理。 固定长度可能截断表格、定义与结论，应优先按标题、段落和语义边界切分。
误区：摘要越短越好。 压缩率必须服从用途；用于审计的摘要需要证据和限定条件，不能以最短为唯一目标。
追问：如何处理多个 chunk 之间的矛盾信息？ 保留来源、版本和时间戳，在聚合阶段显式列出冲突，不应让模型自行挑一个看似合理的说法。
追问：如何评估摘要有没有遗漏关键事实？ 建立事实清单，计算关键事实召回与引用一致性，并让人工检查数字、否定和跨段关系。
追问：长文档摘要为什么常需要引用回链？ 摘要是有损压缩，回链让用户验证原文、定位冲突，也便于把幻觉归因到具体块。

九、加强记忆

记住“先保边界，再分块抽取，再层级压缩，最后查证”。这比单次生成更像工程系统，也更容易解释质量保障。

长文摘要按“切块不切语义—局部提事实—聚合解冲突—引用可回查—事实召回验收”记忆。长度只是预算，保真和追溯才是质量核心。

项目实战落地

项目里怎么做的

《AI Agent智能会议纪要辅助系统》要把一场会议几万字的转写生成结构化纪要，做法是「分段提取，再合并」：

按片段边界切段。 转写片段按顺序号取出，每行拼成 [秒数][说话人] 内容，说话人优先用匹配好的真实姓名；累计长度再加一行就超过 MAX_CHUNK_CHARS = 12000 字符时，先把攒着的收成一段，再开新的一段。

# 加上这一行就超长时，先把攒着的这一段收进结果，再重新开一段
if current and current_size + len(line) > MAX_CHUNK_CHARS:
    chunks.append("\n".join(current))
    current, current_size = [], 0
current.append(line)
current_size += len(line)

每段做结构化提取。 每段调一次分段提取模板 MEETING_MINUTES_CHUNK，产出摘要、议题、发言观点、决策、待确认事项、风险六块内容，结构和纪要表的六列一一对应。
多段再合并。 多于一段时，把各段的结构化结果序列化成一个 JSON 数组，交给合并模板 MEETING_MINUTES_MERGE，要求「去重、合并，保留可追踪的事实」；只有一段时直接作为最终结果，不再调合并。
结果统一校验。 分段结果和合并结果都用同一个 Pydantic 模型 MinutesResult 校验，校验通过才写回纪要表。
进度可见。 分段提取把进度从 10 推到 75，页面显示「正在分析第 i/n 段转写」；合并时进度 80，完成 100。

为什么这样取舍

切在片段边界上。 按片段累计长度切，不会把一句话从中间劈开。
每行带上秒数和说话人。 模型要归纳出谁在什么时候说了什么，发言观点和决策才能对上人。
中间结果也是结构化的。 合并步拿到的是六块结构化内容，而不是几段自由文本，去重合并的对象清楚，产出也能直接按同一个结构校验、入库。

面试官还会追问

同一场会议已有纪要正在生成时再点「生成」，会怎么处理？服务重启时停在「生成中」的纪要怎么办？
转写里的说话人还没对应到参会人员时，喂给纪要模型的那一行里，说话人写的是什么？
同一个转写任务重新生成纪要时，旧纪要和它的确认状态怎么处理？

学完《AI Agent智能会议纪要辅助系统》，上面这些追问你都会迎刃而解。

简化版

详细版