日期:2026-08-04
我们所在的 AI 私有化底座团队,接到一个知识密集型业务的诉求:把上百页的产品手册、合同、研报直接喂给大模型做问答和摘要。一开始大家图省事,整本文档塞进上下文,结果很快撞墙——长文档超出上下文窗口被截断,关键信息丢在中间;即便切了块,把所有块都拼进去成本飙升、噪声变大,摘要质量反而下降。更糟的是,用户拿到摘要却说不出依据在哪,不敢直接采信。我们这个项目要解决的就是:在有限上下文和有限预算下,怎么把长文档"压"得既短又准,并且让每一句摘要都指得回原文。
能力落到了我们底座的 RAG 流水线里,覆盖三类场景。第一是长文档分层摘要:先逐段摘要再向上聚合,输出一份结构化总览。第二是关键证据抽取:问答时按需召回原文片段而非全量灌入,让答案有据可依。第三是超长对话的上下文压缩:把早期轮次压成要点保留,控制多轮会话的 token 膨胀。用户侧感知是:问答能引用原文出处,长文能一键出结构化摘要,且响应更快、更便宜。对工程侧而言,这是把"上下文窗口"这个稀缺资源用在了刀刃上。
第一难是压缩比和保真的权衡。我们采用"先压缩再摘要"的两段式:先用轻量模型做段落级要点抽取,再用主模型基于要点生成摘要。这样既控制主模型输入长度,又保留文档的层级结构,避免一次性压成一团导致信息塌缩。第二难是证据可追溯。压缩会丢细节,但问答必须能指回原文。我们让每段要点携带 source_span(文档位置锚点),生成答案时强制回链,用户在界面点摘要句能跳到原文对应位置,可信度大幅提升。第三难是成本与延迟平衡。我们用异步预处理:文档上传即后台分层摘要并缓存,用户提问时直接消费缓存要点,首字延迟从十几秒降到两秒内,体验质变。
案例片段(已脱敏): 分段压缩配置: chunk_size: 1500 summary_model: lightweight-7b keep_span: true 聚合摘要调用日志: doc=手册_v3.pdf(212页) -> 178 chunks -> 178 要点 -> 聚合摘要 1.2k tokens 原全文直喂需 ~58k tokens,压缩后主模型输入 ~6k tokens,成本下降约 90%
脱敏评测中,对五十篇一百到三百页的文档,分层压缩摘要的"关键信息覆盖率"达约百分之九十四(人工抽样核对),而全文直喂因截断覆盖率仅约百分之七十一;单文档摘要成本下降约百分之八十八;问答溯源准确率(答案句能正确指回原文)约百分之九十一。用户主观满意度调研,长文摘要可用率从约百分之六十二升至约百分之八十九。这些数据说明,压缩不是牺牲质量换便宜,而是用对的方法同时把成本和可用性都拉了上来。
其一,长文档别硬塞,先做分层压缩再聚合,主模型只吃"提炼后的骨头",上下文窗口才能扛住。其二,压缩必须带 source_span,否则摘要不可信、不可溯源,业务不敢用。其三,预处理异步化是体验关键,文档一入库就压,提问时零等待。其四,压缩比不是越高越好,我们固定在"要点层约十比一、聚合层再约五比一"的区间,再高保真掉得明显。其五,保留原文按需召回通道,摘要负责"快览",原文负责"较真",两者配合才是完整的长文档方案。
长文档压缩在规模化时,第一个要取舍的是"压到哪一层交给主模型"。我们试过只做段落摘要,发现跨章节的脉络会丢;也试过压到极短,保真掉得厉害。最终定在"段落要点加章节聚合"两层,既保留结构又不爆上下文。第二是摘要模型选型。轻量七B模型成本可控但偶尔漏要点,我们对关键文档启用更大的模型做二次校验,用成本换关键场景的准确率。第三是缓存策略。文档不变就不重算,但很多文档是"同模板不同数据",我们按内容哈希判重,同源模板的不同实例共享结构缓存,命中率很高。第四是溯源的展示成本,source_span 要在前端可点击跳转,我们为此在摘要输出里固化了文档内部锚点,前端做一次索引构建,体验提升明显。最后是可观测,我们把每篇文档的"原文_TOKEN、压缩后_TOKEN、覆盖率、耗时"都埋点,哪类文档压缩比异常马上能发现。长文档方案能不能规模化,不在算法多炫,而在这些工程取舍是否经得起海量文档的检验。
第一,别把压缩当成万能源头药。我们见过团队为了省 token 把文档压得只剩骨架,结果摘要看似通顺但关键数字全错,业务反而更不敢用。压缩比一定要配合覆盖率评测,没有评测的压缩都是在赌。第二,溯源锚点要从第一天就设计,很多项目先出摘要后补溯源,发现要点和原文对不上,返工成本极高。第三,缓存要建在对的位置,按内容哈希而非按文件名,否则同源模板的不同实例各算各的,命中率起不来。第四,模型选型别一味追大,轻量模型加二次校验的组合,在大多数文档上已经够用,成本却低一个数量级。第五,把压缩效果做成可观测指标,哪类文档覆盖率掉、哪类成本异常,运营一眼能看到,系统才能长期健康。长文档压缩拼的是工程纪律,不是算法炫技。