一、参数表上的数字很容易误导
模型介绍页写着百万上下文，很多人第一反应是：以后不用切分文档了，全塞进去就行。
实际用起来会发现，答案质量并不随上下文变长而线性提升。
二、三个反例
反例一：针在草堆里。
把一个关键句放在长文档的中间，问模型相关内容，它经常答不上来。中段信息的召回率明显低于首尾，这个现象被反复观测到。
反例二：重要信息被稀释。
上下文里塞了不相干的八万字，模型会把注意力摊薄到所有内容上。结果就是什么都看到了一点，什么都没说清。
反例三：长上下文的价格陷阱。
输入按 token 计费，长上下文的价格往往不是线性增长，而是成倍。很多人算完账才发现，用不起。
三、正确的用法
用法一：先检索，再拼装。
只把相关段落放进去。文档大就切分，这是常规做法。
用法二：把关键信息放在首尾。
这不是玄学，是模型注意力的实际分布。重要约束放开头或结尾，遵守率明显更高。
用法三：分段处理。
长文档先分段抽取，再做汇总。比一次性丢进去稳。
四、什么情况下长上下文真的有用
有三种：
一、任务本身需要全局视野，比如跨章节找矛盾。
二、文档不长，十几万字以内。
三、你愿意为准确性付出价格。
除此之外，检索加拼装是更经济的选择。
五、怎么验证自己的场景
做一个小实验：
把同一份文档分别用"全文塞入"和"检索拼接"两种方式跑，准备十个问题，人工打分。
如果两者分数接近，选便宜的那个；如果检索版明显差，才考虑长上下文。
六、想深入看的话
这个领域的材料很杂，论文、技术博客、产品文档都有。我习惯先找一份讲得系统的手册，先把概念理顺。
万象云档 的"人工智能&大模型"分类里有 220 篇文档，其中不少是模型手册与原理说明，适合拿来对照。读的时候建议先看目录，找到"上下文"或"注意力"那一章再深入。
七、一句总结
上下文窗口是一个上限，不是一个目标。
把上下文当容量指标去填充，结果通常不美。