上下文长度是容量上限，不是理解力的保证。
一个常见误判
「窗口够大，就不用检索了」——这是很自然的想法，但实测常常相反：把 10 万字资料一次性塞进去，模型对开头与结尾的信息利用得最好，中间段的召回明显偏弱。这类现象通常被称为「中间遗忘」。
结果就是：资料明明在上下文里，回答却漏了它，甚至与它矛盾。
为什么会长成这样
· 注意力被稀释：序列越长，单个位置能分到的注意力越少；
· 位置编码的偏好：不少模型在训练时更多见到「关键信息在首尾」的样本；
· 无关内容干扰：塞进去的 90% 是无关段落时，它们会成为噪声而非背景。
三个可落地做法
一、给结构，而不是给流水账
把资料按标题分层组织，并在每段前加一句「这段讲什么」。模型不需要读完全文才能定位；实测里这一步的收益往往大于换模型。
二、先摘要再回答（分段摘要 + 汇总）
长文先逐段摘要（每段 2~3 句），把摘要连同原文位置一起给模型；需要细节时再按位置取原文。这样上下文里放的是「索引 + 要点」，而非全文。
三、把一个大问题拆成多轮小问题
「读完这些资料，给我一份分析」这类任务，改成「先列出资料里与 X 相关的全部事实 → 再基于这些事实回答」。每轮上下文更短、目标更单一，漏读概率显著下降。
什么时候真的需要长上下文
以下场景适合直接塞长文：
· 需要通篇一致性的任务（长文改写、风格统一、全文校对）；
· 资料本身就短（几千字以内），拆检索反而增加误差；
· 需要跨段落推理（前后呼应、矛盾检测）。
反过来，事实型问答、按条款作答、单点查询这类任务，用检索 + 短上下文通常更准也更省。
怎么验证
挑 20 条需要「从长资料里找具体事实」的问题，做一次对照：
1. 全文塞入；
2. 检索后只给相关片段。
比较正确率与成本。多数项目会看到「检索 + 短上下文」在事实型问题上更准；而在改写类任务上，长上下文更好。按任务类型选，不要一刀切。
本文由云枢 AI导航整理，内容以官方来源为准。
相关文章
顺序阅读
← 上一篇：提示词注入是怎么回事：把用户输入当「数据」而不是「指令」
下一篇：批量推理怎么降本：缓存、批处理与路由的叠加顺序 →
第 7 / 171 篇