表面与里子
模型厂商竞相把上下文窗口推到 200K、1M、10M。看起来很爽——所有资料一次塞进去就好了。
但实际生产里，长上下文不是免费午餐。
4 个真实代价
1. “lost in the middle” 现象
研究反复验证：模型对上下文 开头和结尾 的信息最敏感，中间段会被 “压缩”。
你把关键信息放在第 80 页第 4 段，模型可能视而不见。
2. 价格按 token 线性走
1M 上下文用满，单次调用成本可能是普通调用的 100 倍。这笔账要算进 P&L。
3. 延迟随窗口长度上升
首 token 时间（TTFT）和总响应时间都会变长。用户感受得到，尤其是流式输出。
4. 缓存命中率下降
如果你用 prompt caching，每次窗口里塞不同的长文档会破坏缓存。缓存命中是 prompt caching 节省成本的全部秘密。
替代策略
不是"窗口越长越好"，而是"用对长度"：
| 知识量 | 推荐策略 |
|---|---|
| < 10K tokens | 直接全部塞进上下文 |
| 10K – 200K | 长上下文 + prompt caching |
| > 200K | RAG / 分段处理 / 摘要后注入 |
长上下文是工具，不是答案。当你听到"上下文不够"时，先问自己：是真的不够，还是上下文工程做得不够好？