百万token上下文是谎言？长上下文失效真相与RAG应对策略

百万token上下文窗口听起来像无限记忆，实际上更像一个堆满杂物的阁楼——重要的东西，往往被埋在最深处。

一个真实的生产事故

Lena 的团队把一份200页的合同塞进AI Agent的上下文窗口。供应商承诺百万token容量——足够放整份文档。模型对前10页的问题回答得滴水不漏，最后5页也答得不错。但中间部分，包括第47页那个决定性条款，仿佛从未存在过。

窗口没有骗人，它确实有这么大。它骗你的是"注意力分配"。

可用上下文远小于标称上下文。 Needle-in-haystack基准测试的成绩确实在进步，但生产环境里的任务不是"找一根针"，而是跨章节、跨修订、跨对话线程的复杂关系。模型会丢失中间内容，过度加权最近出现的token，并在相距遥远的事实之间编造桥梁。更大的窗口只是推迟了RAG的讨论，而没有终结它。

中间地带：事实的坟墓

研究人员多年前就记录了"lost-in-the-middle"现象——长提示词中心位置的关键事实依然会被忽略。但产品团队仍然把80页的合同塞进一条prompt，因为厂商宣传册上写着百万token。

注意力分布并不均匀——开头和结尾获得不成比例的权重，位于中心的关键条款在统计意义上就是"倒霉"。

这背后的核心矛盾很简单：结构比体量更重要。分层摘要——先生成大纲，再深入到相关章节——在大多数企业任务上胜过暴力堆砌。你需要构建的是一个模型可以导航的目录，而不是对上下文长度的盲目崇拜。

几个实操手段值得记下来：

• 锚定关键规则——把不可协商的约束在prompt末尾重复一遍
• 分块引用——强制模型引用chunk ID，而不是凭记忆转述
• 渐进式披露——第一轮不够用时再检索更多
• 成本上限——长上下文是一个定价攻击面，每个请求都要设预算

更大的窗口不会修复糟糕的信息架构——它只是用更大的账单掩盖了问题。

Lost-in-the-middle 指斯坦福等机构在 2023 年前后通过多文档问答实验发现的现象：当关键信息被放置在长上下文的中段（约 30%–70% 位置）时，模型的检索与利用率显著低于放在开头或结尾。其成因通常被归结为位置编码的衰减效应、训练数据中首尾内容更常与答案关联，以及注意力 softmax 在长序列上的稀释。工业界常引用"U 形曲线"来描述这一分布：两端高、中间低。应对思路不是单纯扩大窗口，而是通过重排序把关键 chunk 前移或后移、在 prompt 末尾重申关键约束、或用显式引用迫使模型回看中段内容。

长上下文真正适用的场景

批量操作——全仓库重构、完整转录分析、跨文档去重——确实受益于一次性装下更多内容。即便如此，也要对提取出的声明做验证性二次处理。长上下文用于搬大件，检索用于精确定位。

更具体地说：拿你最长的真实工作流，分别用"全量堆砌"和"RAG+分层"跑一遍，测量准确率、成本和可调试性——别看感觉。大多数团队会发现混合方案胜出：长上下文用于生成地图，检索用于获取事实，两者共同支撑综合结论并附带引用。

如果你无法解释哪些token起了作用，那你用了太多token。

RAG（检索增强生成） 与长上下文是两条互补路径。RAG 的核心是在推理前用向量检索或关键词检索，从外部知识库中取回 top-k 个 chunk，仅把这些片段拼进 prompt。它的优势是精准、可引用、成本可控，缺点是可能漏检或跨 chunk 语义断裂。长上下文的优势是一次性提供全局视野，适合需要跨段落综合的任务，如代码库级重构、合同跨条款比对。实践中常见的混合架构是：先用长上下文生成文档地图或摘要索引，再用 RAG 按问题定位具体片段，最后把检索结果与地图一起交给模型综合，并要求输出引用（chunk ID）。这样既保留全局结构，又避免为无关 token 付费。

给财务看的token账单管理

长上下文调用需要按团队设预算——财务能看清哪个产品线"以防万一"塞了20万token。Chargeback不是惩罚，而是教会团队"检索而非堆砌"的手段。当token账单能对应到具体负责人时，CFO就理解了。

每周记录输入token直方图。峰值对应着糟糕的prompt或缺失的RAG。先修复工作流，再考虑买更大的窗口。

聊天历史压缩的陷阱

为了适配窗口而摘要聊天历史，会丢掉用户十轮之前做出的承诺。压缩后要重复未完成的任务和约束——或者把会话目标存储在prompt之外的结构化状态里。

把会话目标存在sidecar JSON中，让模型每轮重新读取。不要依赖"摘要感"来保证合同级别的精确性。

先买检索，再买token——在我们测量的每个企业任务上，结构都胜过体量。

在config中为每个feature设定最大输入token上限，无界prompt就是无界账单。

Sidecar 状态 指的是把会话中必须跨轮次保留的结构化信息（未完成任务、已承诺的约束、已知事实、用户偏好）从聊天历史里抽出来，存成 prompt 之外的 JSON 或数据库记录，每轮重新注入。相比把整段对话摘要压缩进上下文，sidecar 的优势有三：一是内容精确，不会被模型"意译"掉关键数字或日期；二是可审计，能直接检查哪些约束被记录；三是可按需裁剪，只注入与当前轮次相关的字段。典型字段包括 open_tasks、hard_constraints、confirmed_facts、user_preferences。对合同、财务、合规类场景，sidecar 往往是保持多轮一致性的最低成本方案。

Map-then-Drill模式

第一遍：模型为长文档生成大纲。第二遍：只检索与问题相关的章节。第三遍：带引用地综合结论。三次便宜的调用在准确率和成本上胜过一次巨型调用——对大多数政策文档和代码任务都成立。

用自己的长文档测试。站得住脚的结论是：结构化输出胜过非结构化巨型prompt。

Map-then-Drill 是一种分层推理范式，名称借自 MapReduce 的"先分片再归并"思路，但目标是精准而非吞吐。第一遍 Map：让模型对长文档分块生成结构化大纲，每块附上 chunk ID 和要点摘要。第二遍 Drill：针对用户问题，只把大纲中相关的少数 chunk 拉进上下文做细读。第三遍 Synthesize：综合细读结果，输出带引用的结论。相比一次性把 80 页塞进 prompt，这种做法把"理解文档结构"和"回答具体问题"解耦，既降低单次上下文压力，也让每一步可验证——你可以检查大纲是否漏了章节、检索是否选错 chunk、综合是否越过了引用证据。

用你最长的真实文档做基准测试

把最糟糕的那份80页合同分别跑一遍"全量堆砌"和"map-then-drill"，在准确率、成本以及"能否解释哪些token真正起了作用"三个维度上打分。

大多数团队会发现混合方案胜出——长上下文负责地图，检索负责事实，引用把综合结论绑回两者。

更大的窗口不会修复糟糕的信息架构，它只是把账单藏起来。如果你指不出是哪个chunk回答了问题，你就为没用到的token付了钱——而第47页的条款，仍然在靠运气赌博。

原文发表于 ayraix.com，面向企业构建者的实用AI内容。