上下文压缩或摘要会丢失信息,如何让损失尽可能小?
未标记
询问 AI
考查重点:摘要保真与关键约束保留。将目标、已确认事实、决策和未完成事项做成结构化摘要,保留原文引用;用后续任务测试检查关键约束有无丢失
本题目录
参考答案
核心回答
摘要是有损表示,降低损失的关键是:把任务必需的信息明确保留,把精确材料留在可回查的位置,并验证压缩后能否继续正确完成任务,不能只要求模型“总结得完整”。
- 关键状态与自由摘要分开:当前目标、有效约束、准确标识、未完成项和已发生的业务动作单独记录;数字、单位、否定条件及技术版本按需要保留原文。
- 摘要保留出处:长日志和工具结果可以概括,但保存原始版本、消息或片段标识,需要细节时能取回对应内容。
- 先保证必要信息召回,再提高压缩率:按后续任务决定哪些内容不能丢,特别检查低频技术细节、用户更正和不确定结论。
- 压缩后校验并可恢复:核对必需字段和约束,用多轮任务回放检查行为;发现遗漏时回读原文、补齐或回退摘要,不能凭摘要继续猜。
压缩率只是成本指标。摘要缩短很多,但把“只诊断,不重启”改成“排查并修复”,就已经改变了任务。
先定义哪些信息丢了会影响后续行动
关键信息不等于出现次数最多的信息。一个只出现一次的错误码、数据库版本、兼容开关或排除条件,可能正是后续定位问题需要的线索。
可以按用途划分:
- 继续执行所需状态:目标、当前步骤、已完成和未完成事项,已创建的工单或已提交的操作及其结果,避免重复执行。
- 不可随意改写的事实:资源 ID、版本、金额与单位、时间范围、路径、错误码,以及有明确语义的原句。
- 判断边界:用户最新更正、禁止事项、前提条件、结论是否已确认,以及相互冲突的证据。
- 可概括的过程:重复讨论、已被替代的尝试、冗长日志和工具输出;仍需保留有用结论与回查位置。
结构化字段也需要核对原文。把错误信息提取进 JSON,并不会自动变成正确事实;用户更正后还要更新生效范围,不能把所有旧约束永久累积。身份与权限仍由应用的可信状态管理,摘要不负责授予权限。
用结构化摘要保留关系,而不只是保留词
以运维排障为例,原对话包含“问题出现在 2.7.3 版本之后”“请求超时阈值是 800 ms”“只做诊断,不重启服务”,并且数据库原因尚未证实。
合适的摘要至少应保留:当前诊断目标、版本变化、带单位的超时设置、禁止重启、已检查结果、仍待验证的假设和下一步。若只保留“新版服务有超时,考虑数据库并修复”,不仅丢掉具体值,还把假设写成了方向确定的结论,并扩大了动作范围。
因此,摘要指令可以明确要求分别记录“已确认事实、待验证假设、未完成项、当前限制和证据位置”。不应要求它为了简短而消除矛盾;尚未解释的冲突应保留各自来源。对于代码、SQL、报错和需要精确引用的条款,常驻摘要只描述用途,使用时读取必要原段,通常比多次转述更稳妥。
冷门细节靠原文索引和按需读取补回
全文可以外置,但引用必须足以定位正确内容,例如文档版本与段落、日志记录 ID、文件修订与行号,或工具结果的存储标识。只留“之前查过日志”无法回查;只留一个可能变化的网页地址,也未必能恢复当时内容。
工具结果可拆成短摘要和原始材料:摘要保留结果状态、关键发现、异常和指针,长文本放在外部。后续问题需要某个技术细节时,结合任务、实体和原始标识检索,再读对应片段。错误码、配置名等精确标识适合关键词或精确匹配,不能只依赖语义相似度。
按需取回也会漏召回,因此要验证指针是否有效、版本是否匹配,以及低频细节能否被找回。外置不是无损使用的保证,而是为恢复信息保留通道。
避免重复处理和多轮摘要的语义漂移
为摘要保存覆盖的消息范围或最后处理位置、摘要版本及来源关系。更新时合并新消息与当前状态,只处理尚未覆盖的增量;已进入摘要的原始消息,不应每轮再次整段拼入,造成重复事实和 Token 膨胀。
同时,不能无限把上一版摘要再缩短。多次转述可能逐渐删掉限定词,把“可能”“未确认”变成确定结论。关键状态保持独立,定期或发现冲突时,从原始记录重建相关部分;摘要版本与覆盖位置也应一同保存,避免恢复后漏处理或重复处理消息。
裁剪历史还要符合模型接口的消息契约。工具调用与结果要保持正确对应;已发生动作及执行状态应可恢复,不能因省略旧工具输出就忘记已经执行过某项操作。摘要中间件的触发和近期保留参数,只解决何时压缩、保留哪段历史,不能自动证明内容保真。
怎样验证损失是否可接受
固定一组多轮轨迹,标注后续必需的事实、否定约束、用户更正、稀有标识和状态变化。让压缩方案继续完成相同任务,检查两层结果:
- 信息层:必需事实保留率、字段和单位正确性、约束遗漏、错误新增事实、来源指针及重取正确率。关键限制应单列,不能被大量普通事实的平均分掩盖。
- 任务层:能否回答隔多轮后再次追问的细节,是否重复已执行动作,是否遵守最新范围,最终结果是否符合要求。
在信息充分且模型可容纳的片段上,可以对比原始上下文与摘要;长任务则依据标注事实和任务验收检查。再记录压缩后的 Token、额外摘要与检索调用、总耗时和费用,选择质量与成本的合适取舍。
简单字段可用规则核对,语义遗漏可用模型辅助比较原文与摘要,但第二次模型判断仍可能漏错。涉及关键事实时应回到原始证据,并用任务反例验证。失败后可以增加原文保留、调整摘要结构或降低压缩强度;不要仅因为格式合法就覆盖唯一可用记录。
追问:能不能做到完全不丢?
对任意未来问题,都用有限摘要替代完整历史并保证完全不丢,通常做不到。实际目标是保留当前任务所需信息,并让尚未常驻的细节可恢复。如果某段材料必须逐字准确使用,就保留必要原文或读取原件。窗口预算与截断等基本策略见上下文窗口超过限制时如何处理。
对应教程
- 第 16 章:记忆与对话历史:§3 解释历史怎样注入当前调用,并指出长历史需要截断或摘要;本文进一步说明保留内容与损失验证。
- 深度研搜第 7 章:中间件机制与 Skills 配置:§3 介绍摘要模型、触发和近期保留参数,适合理解压缩发生的位置;具体阈值与摘要质量需要按目标模型和任务验证。
参考资料
- 国内:Onefly / zero2Agent:记忆与上下文:借鉴关键约束外置、原文指针及压缩回检的做法,说明正文中任务状态为何与自由摘要分开保存,以及信息丢失后的恢复依据。
- 国内:JavaGuide:Context Engineering:参考上下文分层与质量评估方法,说明正文如何分别衡量任务成功、关键字段遗漏和 Token 成本,而不只看压缩比例。
- 国内:Datawhale:第九章 上下文工程:以 ContextBuilder 的分区、预算和字符截断示例为依据,说明正文中结构完整与语义保真之间的区别,以及为什么还需任务验证。
- 国外:Anthropic:Effective context engineering for AI agents:借鉴 Compaction 与 Structured note-taking 对决策、未决问题和实现细节的保留方式,说明正文为何先保证必要信息召回,再删除冗余。
- 国外:LangChain:Short-term memory:依据消息删除与摘要机制,解释正文中旧历史替换、近期消息保留及工具调用与结果配对的要求。
相关面经
13 篇恒生电子
AI 开发工程师摘要压缩把冷门技术细节遗漏了该怎么处理?
阿里巴巴
AI 应用研发工程师Agent上下文超限怎么处理?滑动窗口和摘要压缩各自牺牲了什么
字节跳动
AI Agent 开发工程师摘要把字段丢了怎么办
作业帮
Agent 应用开发工程师会话记忆管理使用了滑动窗口 + 压缩,压缩过程会不会丢失记忆,该如何解决该问题。
字节跳动
Agent 开发工程师压缩或者摘要肯定会丢失信息,如何使得这个信息丢失最小化?
展开剩余 8 篇面经
拼多多
大模型应用开发工程师(RAG 方向)上下文压缩时怎么降低信息丢失的概率?
字节跳动
后端开发工程师上下文压缩如何保证质量?如何避免重复压缩?
影石创新
AI Agent 开发在 Agent 开发过程中,上下文为什么需要进行压缩?压缩后可能导致信息缺失,应该如何解决?
法本信息
AI Agent 开发FOSHO
AI 应用开发参考 Claude Code 等产品后,你如何在压缩上下文的同时维持多轮任务的记忆和执行效率?
百度
Java 开发工程师(智能客服)上下文压缩有没有可能把关键信息压缩丢失?
阿里巴巴
Java 开发工程师上下文压缩有什么策略?如何避免过滤掉有用信息、留下噪音数据?
未知公司
Agent 实习岗短期记忆摘要进行压缩,存在损失,如果减少了关键信息,你如何解决
收录题集
相关关键词:摘要压缩、Context Summarization


