上下文膨胀致AI答非所问，8千token文档塞入systemprompt，第8轮开始胡说且账单翻4倍

一名开发者在对接第三方开放平台时，为图省事将整本约8000 token的接口文档直接塞入system prompt，期望模型能随时查阅。初期效果良好：前3轮关于鉴权方式、分页参数等提问均获准确回复。但到第8轮，当再次询问此前已明确讨论过的限流头字段时，模型给出了错误字段名，导致请求被网关拒绝。更意外的是，该8轮对话的实际费用约为预期的4倍。

这一现象并非个例，而是长上下文推理中普遍存在的“上下文膨胀”问题：成本激增与质量下滑实为同一技术根因的两面表现。

成本为何暴涨？关键在KV cache，而非模型本身

每token KV字节数 = 2 × 层数 × KV头数 × 头维度 × 每元素字节数

以Llama 2 7B为例（32层、32个KV头、头维度128、FP16精度），单token约占0.5 MB。由此推算：

4K上下文 → 约2 GB
128K上下文 → 约64 GB

而该模型权重本身仅约14 GB（FP16）。这意味着，仅KV cache一项就可能超过模型权重4倍以上。线上服务若并发数十请求，显存瓶颈实质是KV cache墙。现代模型如Llama 3 8B通过GQA（分组查询注意力）将KV头数降至8，有效压缩了cache体积，印证了架构优化在此问题上的关键作用。

性能为何下降？“中间遗忘”是隐形杀手

成本之外，更隐蔽的问题是模型对长上下文中“中间位置”信息的处理能力急剧衰减。2023年刘等人在论文《Lost in the Middle》（arXiv:2307.03172）中系统验证了该现象：在多文档问答与键值检索任务中，当关键答案位于输入开头或结尾时，模型准确率最高；一旦置于中间区域，准确率显著下滑，且上下文越长，跌幅越大。典型U形曲线显示，最佳与最差位置间差距可达20个百分点，部分配置下中间位置准确率甚至低于无上下文的闭卷推理。

该现象源于注意力机制的归一化约束：softmax要求所有注意力权重之和为1，即使某token与当前查询无关，也必须分配部分权重。模型在训练中习得“首因偏差”与“近因偏差”，天然偏爱两端信息，夹在中间的内容则被持续稀释。

回到前述案例：第三轮提及的限流字段，在第八轮时已被后续对话与8000字文档层层覆盖，恰好落入注意力最弱的中部盲区。前几轮它尚靠近开头，模型尚能调用；轮次增加后，它“沉底”，模型便开始幻觉输出——这不是模型故障，而是其工作机制决定的结构性局限。

三种应对策略：各有利弊，需按场景取舍

明确病灶后，业界形成三类主流应对路径，核心目标一致：控制上下文规模，并确保关键信息处于高注意力区域。

第一种是“全量重发”：每轮对话都将原始文档+全部历史对话重新注入。优点是信息零丢失，缺点是成本随轮次线性增长，且关键信息极易沉入中部被遗忘。前述8轮对话即属此法，代价高昂且失效。

第二种是“滑动窗口”：仅保留最近N轮对话（如最近2轮），其余硬性丢弃。优势在于上下文长度恒定、成本可控；代价是早期重要约定（如第三轮的限流字段）会被提前清除。若业务逻辑依赖跨轮次记忆，此法易引发断点错误。

第三种是“智能压缩”：通过摘要、关键段落提取或向量检索动态裁剪上下文。例如，仅保留与当前问题语义最相关的文档片段，或对历史对话做摘要压缩。该方法平衡了成本与质量，但依赖额外模块（如reranker或摘要模型），引入延迟与工程复杂度。

值得注意的是，当前主流API计费模式通常按输入+输出总token数收费，而KV cache虽不直接计入账单，却通过显存占用限制并发能力，间接推高单位请求成本。开发者常误以为“system prompt只收一次费”，实则每次请求仍需加载全部上下文，触发完整KV cache重建。

行业层面，该问题正推动推理优化技术加速落地。除GQA外，FlashAttention-2、PagedAttention等技术通过内存分页与计算融合降低KV cache压力；而像Context Compression、RoPE scaling等位置编码改进，则试图缓解中间遗忘。部分厂商已提供“上下文感知定价”选项，允许用户指定关键片段优先保留在头部/尾部。

对于一线工程师，实用建议包括：

避免将整份文档塞入system prompt，改用按需检索（如RAG）；
对高频引用字段（如认证头、限流规则）单独提取为变量注入；
在多轮对话中主动复述关键约束（如“注意：我们约定使用X-Request-Limit头”），将其“推”回上下文两端；
监控token消耗与响应质量相关性，警惕第5–10轮后的准确率拐点。

上下文管理已从“可用即可”进入“精控必行”阶段。当模型能力边界逐渐清晰, 工程师的职责不再是堆砌信息，而是设计信息流的结构与节奏——让关键内容始终站在注意力的聚光灯下。