现在许多模型宣称支持很长的上下文窗口，但“能塞进去”和“能用好”是两回事。这篇整理长上下文场景下的常见问题与实践。

【一、几个需要了解的现象】
- 位置敏感：不少研究观察到，模型对放在开头和结尾的信息利用得更好，放在中间的信息更容易被忽略，常被称为“lost in the middle”。不同模型程度不同，需要自己测。
- 有效长度小于标称长度：标称支持的长度是“不报错的上限”，在接近上限时，检索和推理质量通常会下降。
- 成本与延迟：输入越长，预填充（prefill）计算越多，首 token 延迟越高；同时 KV Cache 占用显存随长度线性增长。

【二、如何测试一个模型的长上下文能力】
- “大海捞针”类测试：在长文本不同位置插入关键信息，看模型能否找回。它只能测检索能力，不代表推理能力。
- 多跳问题：答案需要综合文档多个位置的信息，更接近真实需求。
- 用你自己的真实长文档测试，比如合同、日志、代码库。

【三、实践建议】
1. 能检索就别全塞：先用 RAG 选出相关片段，再交给模型，往往更准、更便宜。
2. 把关键指令放在最后（或首尾各放一次），减少被长文本“淹没”。
3. 结构化输入：给每段资料加编号和标题，要求模型回答时引用编号，便于核查。
4. 分而治之：超长文档可以先分段摘要，再汇总（map-reduce），注意摘要过程会丢信息。
5. 利用提示词缓存（prompt caching）：如果多次请求共享同一大段前缀，部分服务和推理框架支持复用，可明显降低成本与延迟。

【四、常见坑】
- 把整个知识库塞进上下文，结果答案引用错误的段落。
- 忽视截断：超出长度时框架可能静默截断开头或结尾。
- 只测英文，中文的 token 数与字符数比例不同，需要单独估算长度。

讨论：
1. 你在实际项目中，上下文用到多长时效果开始明显变差？
2. 长文档问答，你更倾向于长上下文直接读还是 RAG？