32K上下文塞满后AI遗忘实测,第80轮开始丢姓名,110轮6条关键事实全失
一项针对32K上下文窗口的120轮对话实测显示,AI在第80轮开始丢失最早输入的关键信息,第110轮时6条埋设事实全部遗忘;相比之下,8K窗口配合10%摘要策略在120轮后仍保持100%召回率,成本仅...
当大模型标称支持32K上下文长度时,用户常默认其能“记住”大量历史信息。但一项严谨的实测揭示:所谓“32K记忆”,本质是“最近77轮对话”的临时缓存——一旦超出,早期关键事实将按出现顺序逐条消失,且无法恢复。
该测试由开发者构建了一个120轮固定客服对话场景,每轮含用户与助手各一条消息,平均402 tokens。对话中刻意埋入6条关键事实:第1轮客户姓名、第3轮订单号、第8轮预算、第12轮地址、第18轮忌口、第24轮发票类型。测试采用四种上下文窗口(4K/8K/16K/32K),策略统一为“截断最早历史,仅保留最近可容纳内容”。
结果清晰呈现容量与轮次的线性关系:4K窗口约支撑9轮,8K约19轮,16K约39轮,32K约77轮。在32K条件下,前75轮6条事实全部可召回;第80轮起,第1轮姓名率先丢失;第85轮,第3轮订单号紧随其后;至110轮,6条事实无一留存。
值得注意的是,这一“遗忘”并非模型主动遗忘,而是客户端每次请求仅传递窗口内片段,窗口外内容根本未进入推理过程。正如图2所示,LLM本身无状态,每一轮都接收一个被裁剪后的“新历史”,所谓“记忆”实为客户端拼接的临时上下文。
测试进一步对比了三种上下文管理策略:
- 截断最早:成本最低,但早期事实永久丢失;
- 滑动窗口+摘要:对较早历史压缩为摘要继续携带,可显著延长事实保留周期;
- 全量保留:信息最完整,但120轮需48,250 tokens,远超多数模型单次输入上限。
在8K窗口下启用10%摘要策略(即每段旧历史压缩至原长10%),120轮后6条事实全部正确召回,累计输入910,716 tokens,按主流API定价(2.5美元/百万tokens)计算成本约2.28美元。而32K纯截断方案在110轮即归零,且单次输入达36,000+ tokens,成本更高。
这揭示了一个关键认知偏差:上下文长度≠长期记忆能力。实际应用中,Agent的“记忆”取决于客户端如何组织历史——是粗暴截断,还是智能压缩。
图3展示了典型Agent会话中上下文构成:系统提示、用户消息、助手回复占据前段,而真正消耗窗口主体的是工具调用结果(如读文件、跑测试、搜代码等),这些往往体积庞大却非核心语义。当工具结果挤占空间,早期对话极易被挤出窗口。
更深层的问题在于Prompt cache机制的设计缺陷。当前主流实现多采用“前缀不变则缓存命中”策略:若新请求的前缀与上一轮完全一致,则复用已计算的KV缓存。但一旦历史被压缩或改写(如摘要生成),前缀即变化,缓存失效,必须重建整个上下文——这导致每次压缩都付出额外计算代价。
图4清晰呈现此问题:第N轮历史消息被压缩为摘要后,第N+1轮因前缀变更无法命中缓存,系统被迫从压缩点重新计算,性能与成本双升。
行业实践已开始应对这一挑战。部分Agent框架引入分层记忆机制:短期记忆(近期对话)保留在上下文窗口内;中期记忆(关键事实)存入向量数据库,通过检索增强生成(RAG)动态注入;长期记忆(用户偏好、账户信息)则由外部知识库维护。例如,某电商客服Agent将订单号、收货地址等结构化字段单独提取,以JSON元数据形式附加在每次请求头部,避免其被文本流淹没。
另一路径是优化摘要质量。测试中10%摘要能保全6条事实,但前提是摘要算法精准捕捉关键实体。若摘要过度泛化(如将“张伟,订单#20240517001”压缩为“客户提交了订单”),则事实仍会丢失。目前已有研究尝试用轻量级抽取模型生成“事实锚点摘要”,仅保留人名、编号、数值等不可压缩要素,其余内容大幅精简。
值得警惕的是,许多开源项目默认采用简单截断策略。Llama.cpp、Ollama等本地推理框架在处理长对话时,若未配置摘要模块,用户可能在不知不觉中丢失关键信息——尤其当对话跨越数小时、涉及多轮决策时,早期设定的约束条件(如“不要修改config.yaml”)极易被覆盖。
该实测还暴露了token估算的现实误差。测试页面采用简化分词规则(汉字1字1 token,英文单词1 token,数字每3位1 token),120轮计为48,250 tokens;但真实模型分词器(如tiktoken)可能因子词切分产生更高开销。这意味着实际可用轮次可能比理论值更低。
技术演进正在回应这一痛点。新一代推理引擎如vLLM 0.4+已支持PagedAttention与动态上下文重排,允许将部分历史“换出”到CPU内存,在需要时再“换入”;Anthropic的Claude 3.5 Sonnet则宣称在32K上下文中实现更均匀的信息保留,但尚未公开验证细节。
回到用户层面,最务实的建议仍是:关键信息勿依赖上下文窗口。对于订单号、合同条款、医疗禁忌等不可错失的数据,应通过结构化字段、元数据标签或外部存储显式传递,而非寄望于模型“记住”一段自然语言描述。
这项测试的价值不在于否定32K上下文,而在于厘清其边界:它是一个高效的短期工作区,而非持久记忆体。当对话超过70轮,工程师必须主动设计记忆策略——否则,AI遗忘的不是细节,而是你曾明确交代过的前提。
