上下文压缩或摘要会丢失信息,如何让损失尽可能小?
未标记
考查重点:摘要保真与关键约束保留。将目标、已确认事实、决策和未完成事项做成结构化摘要,保留原文引用;用后续任务测试检查关键约束有无丢失
本题目录
参考答案
核心回答
摘要是有损表示,降低损失的关键是:把任务必需的信息明确保留,把精确材料留在可回查的位置,并验证压缩后能否继续正确完成任务,不能只要求模型“总结得完整”。
- 关键状态与自由摘要分开:当前目标、有效约束、准确标识、未完成项和已发生的业务动作单独记录;数字、单位、否定条件及技术版本按需要保留原文。
- 摘要保留出处:长日志和工具结果可以概括,但保存原始版本、消息或片段标识,需要细节时能取回对应内容。
- 先保证必要信息召回,再提高压缩率:按后续任务决定哪些内容不能丢,特别检查低频技术细节、用户更正和不确定结论。
- 压缩后校验并可恢复:核对必需字段和约束,用多轮任务回放检查行为;发现遗漏时回读原文、补齐或回退摘要,不能凭摘要继续猜。
压缩率只是成本指标。摘要缩短很多,但把“只诊断,不重启”改成“排查并修复”,就已经改变了任务。
先定义哪些信息丢了会影响后续行动
关键信息不等于出现次数最多的信息。一个只出现一次的错误码、数据库版本、兼容开关或排除条件,可能正是后续定位问题需要的线索。
可以按用途划分:
- 继续执行所需状态:目标、当前步骤、已完成和未完成事项,已创建的工单或已提交的操作及其结果,避免重复执行。
- 不可随意改写的事实:资源 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:依据消息删除与摘要机制,解释正文中旧历史替换、近期消息保留及工具调用与结果配对的要求。
GPT ResearcherPython
核心回答
GPT Researcher 把研究任务拆成子问题,搜集网页后,为每个问题筛选写作上下文。当前这条链路的“压缩”主要是选取相关原文片段:保留片段能减少转述时的改写,但被筛掉的条件、反证和长页面尾部内容仍可能丢失。
降低损失要同时检查两件事:哪些材料进入筛选器,哪些片段最终进入模型。保留原始网页及来源位置,针对研究结论核对事实、日期、否定条件和相反证据;不能只看输入缩短了多少,或用相关性分数证明证据已经完整。
选择策略与实际触发条件
子问题通过 select_context() 统一选择上下文。CONTEXT_FILTER 默认是 auto:存在 TYPESAFE_API_KEY 时用 Jev,否则用本地关键词筛选。内容总量小于 COMPRESSION_THRESHOLD,且页数不超过调用的 max_results 时,直接保留页面内容;当前默认字符阈值为 8000,普通子查询传入 max_results=10。因此配置了某个筛选器,也不代表每次都会调用它。选择入口、普通子查询调用。
几种策略保留内容的依据不同:
none:不做相关性筛选,将页面交给格式化器;但页面进入SearchAPIRetriever时仍受MAX_CONTENT_CHARS限制,默认每页最多50000个字符,所以不能把它当作绝对无损的原文备份。keyword:默认按约1000字符切块、重叠100字符,用BM25排序;在统一选择入口中,保留得分至少为最高分0.5倍的片段,最多25块。若所有片段都没有关键词匹配,退回取前面的片段,不代表已找到了回答证据。embeddings:对分块内容做向量相似度过滤,再按结果数量限制格式化输出。它能补充不同表达之间的匹配,但相似度高仍可能只是主题接近,不能单独证明片段足以回答问题。jev:为原文片段评估对问题的帮助程度,再按分数阈值和数量筛选。它仍可能遗漏低分但关键的例外、日期或反证,需要核对最终保留内容。
这些数值是所核版本的默认配置,不是适合所有研究任务的推荐值。页面长度限制、关键词分块与选择、向量筛选、Jev 筛选。
哪些信息需要额外保留
BM25 依赖词项匹配,当前分词包含通用正则、英文停用词和轻量词形处理,没有专门的中文分词流程。企业别名、缩写和不同表述需要用中文研究样本验证;不能因一次未匹配,就断言原文没有相关内容。固定分块也可能把数字与单位、结论与适用条件拆开,重叠只能缓解,不能保证关系完整。
例如研究某产品是否已经交付,“发布样机”的新闻可能高分命中,而“尚未交付”的说明、不同日期的修订或例外条件可能被排除。业务集成可以为同一实体分别保留支持材料和反证,并在命中片段缺上下文时补读相邻段落,再判断结论。按问题保留条件、例外与冲突材料。
原有 Document 保留 title、source,分块后仍可随正文输出,便于知道内容来自哪个网址。但标题和网址不足以恢复网页当时的版本,也不能证明引用支持结论。进一步完善时,应保存网页快照、发布时间、片段位置及选取策略;发现日期或限定条件缺失时,回读原文,不依靠报告摘要反推。来源元数据、正文与来源格式化。
回退之后仍要检查材料
select_context() 在 Jev 抛出 JevError 时回退关键词筛选,在向量筛选分支捕获普通异常后也回退关键词筛选。关键词路径自身的异常没有在这里统一兜底,Jev 分支也并非捕获所有异常;正常返回空选择同样不等于一定触发回退。因此,不能承诺任何失败都能自动得到有效上下文。实际异常与回退范围。
回退解决的是筛选方式不可用时怎样继续,材料是否充分还要按研究问题判断。若保留片段缺少关键日期或反证,可以补查来源、降低筛选强度或扩大受控阅读范围;若仍无依据,应保留不确定性。
怎样验证损失是否减小
固定同一组网页和研究问题,标注必须保留的事实、单位、日期、否定条件及反证,再比较不同策略进入模型的片段与最终报告。分别记录关键证据覆盖、条件遗漏、引用支持情况、实际输入 Token、筛选调用和耗时;none 对照也要检查页面长度限制,避免把已被截断的材料误当完整基线。
例如同时放入“样机发布”“暂未交付”和后续更新材料,检查报告是否区分不同时间与状态。根据漏掉的具体证据,再调整分块、阈值、实体别名或补读方式。这是可执行的对照验证设计,尚不能据此声称某种策略已经提高准确率或保证无损。
相关面经
23 篇长鑫存储
Agent 开发工程师上下文压缩什么时候触发?压缩会丢失信息吗
DeepSeek
AI Agent开发岗上下文压缩时,你怎么做信息丢失的评估?——用模型打分还是规则?如果压缩丢了关键信息导致 Agent 后面决策错误,你能检测到吗?怎么恢复?
东方财富
AI 应用开发工程师这种上下文治理方案减少了什么,又可能牺牲什么?
字节跳动
Agent 开发工程师哪些信息必须在压缩后继续保留?结合记忆分层说明保留规则。对于不能压缩或不能丢失的信息,你怎样在实现中落实这些约束?
猎聘
AI 应用开发工程师Q10. 你们的上下文压缩是怎么实现的?
展开剩余 18 篇面经
安恒信息
Python Agent 开发实习生agent多轮工具调用会出现上下文持续膨胀,你们平台有没有做上下文裁剪策略?
百度
前端开发工程师智能体的上下文你是怎么给的?如果一次性给太多信息怎么处理?Agent 上下文太大怎么办?
百度
Agent 算法工程师Agent上下文溢出如何解决?常见上下文管理方案。
美的
后端开发工程师你如何保证重要信息不会被压缩掉
阿里巴巴
AI Agent 算法**面试官:** 上下文压缩时保留什么信息?怎么判断哪些内容可以丢弃?
恒生电子
AI 开发工程师摘要压缩把冷门技术细节遗漏了该怎么处理?
阿里巴巴
AI 应用研发工程师Agent上下文超限怎么处理?滑动窗口和摘要压缩各自牺牲了什么
字节跳动
AI Agent 开发工程师摘要把字段丢了怎么办
作业帮
Agent 应用开发工程师会话记忆管理使用了滑动窗口 + 压缩,压缩过程会不会丢失记忆,该如何解决该问题。
字节跳动
Agent 开发工程师压缩或者摘要肯定会丢失信息,如何使得这个信息丢失最小化?
拼多多
Agent 应用开发工程师上下文压缩时怎么降低信息丢失的概率?
字节跳动
后端开发工程师上下文压缩如何保证质量?如何避免重复压缩?
影石创新
AI Agent在 Agent 开发过程中,上下文为什么需要进行压缩?压缩后可能导致信息缺失,应该如何解决?
法本信息
AI Agent 开发FOSHO
AI 应用开发参考 Claude Code 等产品后,你如何在压缩上下文的同时维持多轮任务的记忆和执行效率?
百度
Java 开发工程师(智能客服)上下文压缩有没有可能把关键信息压缩丢失?
阿里巴巴
Java 开发工程师上下文压缩有什么策略?如何避免过滤掉有用信息、留下噪音数据?
公司未注明
Agent 实习岗短期记忆摘要进行压缩,存在损失,如果减少了关键信息,你如何解决
收录题集
相关关键词:摘要压缩、Context Summarization







