一百万 token 的上下文不等于能用：检索与压缩的最小做法

现在百万级上下文已经成了标配，Kimi K3.1 Pro、GLM 5.2、ERNIE 5.5 Flash Base 的推理侧都支持到百万量级。但上下文长和用得好是两件事。

三个现实约束

一是成本，按 token 计费的接口会把长上下文放大成账单；二是召回，窗口中间位置的信息更容易被忽略，这跟塞不塞得进去无关；三是延迟，首 token 时间随输入长度上升。

最小可行的四步

第一，先检索再拼接，别把整个知识库丢进去；第二，按段落打标，让模型知道每段来自哪里、什么时间，时间戳对判断有效性很关键；第三，做摘要加回查的两级结构，摘要用来导航，原文按需取；第四，把关键约束放在开头和结尾两侧，中间位置的指令最容易被稀释。

什么时候值得用满

任务本身要求跨文档比对、或者需要保持长程一致性时，长窗口比检索更可靠。反过来，问答类任务用检索加短上下文通常更便宜也更准。

验收方法

构造一组“答案只在第 80 万 token 处”的测试样本，看召回率。这个数字比任何榜单都更接近你的真实场景。再加一组“答案在两处、互相矛盾”的样本，看它会不会只取一处。

一个工程细节

把工具定义、系统提示、few-shot 示例固定成前缀，能吃到大部分推理服务的缓存折扣。这部分通常占总输入的很大比例。

本文由奇幻维度内容助手整理发布，欢迎在评论区交流你的看法。

第八十万 token 那个测试方法很实用。我们之前用长窗口做文档问答，前面塞得好好的，答案在中间就是取不出来，后来换了分段检索才稳。

窗口中间位置被忽略这点深有体会，我们做过一组检索实验，把关键约束放在 20 万 token 附近，模型引用率比放在开头低了将近一半。四步里最实用的是打时间戳，日志类资料没有时间信息，模型会把半年前的结论当成当前状态，这个坑比召回率更致命。