Claude 1M上下文如何重写长文档处理

导语

今天值得关注的一件事：Anthropic 把 Claude Sonnet 4.5 的上下文窗口推到 100 万 token，并同步开放了长上下文定价——这意味着一整套代码仓库、几百页合同、整本技术手册，可以一次性塞进模型里，不再切片、不再做 RAG 拼装。

它是什么

上下文窗口，就是模型一次对话里能“记住”的内容总量。过去主流模型是 20 万 token 量级，大约相当于一本 300 页的书；100 万 token 则接近 7 到 8 本这样的书，或者一个中型项目的全部源码加文档。

关键是这次不只是“标称支持”。Anthropic 同时给出了长上下文的阶梯定价：超过 20 万 token 的部分按更高单价计费，输入 100 万 token 的单次成本被压到可工程化的区间。这意味着长上下文从“演示特性”变成了“可上生产的能力”。

为什么重要

过去两年，处理长文档的标准答案是 RAG：把文档切块、向量化、检索、再拼进提示词。这套流程能跑，但工程复杂度高，而且有个绕不开的毛病——切块会切断上下文。一段话的答案往往依赖前后三页的限定条件，切片一断，模型就只能靠猜。

100 万上下文改变的正是这个前提。当整份材料能完整进入窗口，模型看到的是全貌而非碎片，“检索错了就全错”的风险被大幅削弱。对开发者来说，这意味着很多场景可以先用长上下文跑通，再决定要不要上 RAG 优化成本。

技术细节

长上下文的核心难点不在“装得下”，而在“找得到”。可以把注意力机制想象成一个人在巨大的图书馆里找资料：窗口越大，书架越多，如果每找一次都要扫遍所有书架，成本会爆炸。

业界的通用解法是稀疏化与分层检索——不是每次都全文比对，而是先快速定位相关区域，再在局部做精细计算。类比一下：你查一本百科不会逐页读，而是先看目录定位章节，再精读那几页。模型做的是同一件事，只是把“目录”学进了参数和注意力结构里。

另一个常被忽略的点是“中间遗忘”。研究普遍发现，超长输入里位于中段的信息更容易被模型忽略，首尾两端的召回更好。所以即便有 100 万窗口，把最关键的要求放在开头或结尾，仍然是最稳的写法。

从数据上看，长上下文的成本并非线性。超过阈值后单价上浮，意味着“无脑全量塞入”在经济上并不划算。真正的最优解往往是：长上下文兜底正确性，检索和缓存控制成本。

对开发者的启示

第一，别再默认“必须切块”。新项目可以先用整份输入验证效果上限，把 RAG 当作成本优化手段而非起点。

第二，提示词结构要重排。关键指令放首尾，中间放大段原始材料，这是当前长上下文下最实用的排版习惯。

第三，把成本当一等公民。长上下文按阶梯计价，缓存命中、输入裁剪、按需加载都会直接影响账单，工程上要提前设计。

第四，评估方式要改。过去测“检索准不准”，现在要测“全量输入下模型有没有漏掉中段关键信息”，这是两套不同的测试集。

一句话总结：上下文变长，不是让工程师少干活，而是把复杂度从“切分与检索”转移到了“排版与成本控制”。谁能把这份新复杂度管好，谁就能把长文档类产品做得又准又便宜。

信息来源：Anthropic 官方模型与定价文档（Claude Sonnet 4.5，100 万 token 上下文窗口及长上下文阶梯定价），2026 年 10 月公开资料。