跳到主要内容
技术WHITEHOLE

长上下文窗口评测:标称不等于可用

模型标称的上下文窗口,指的是它能接收多长的输入,不等于它能把这么长的内容都用好。实际使用中,关键信息位于中段时被忽略的情况相当常见。本文给出一套三段评测法(首、中、尾),说明评测怎么设计、它与检索方案的成本对比,以及验收口径

技术长文本模型评估

长上下文窗口评测,指的是测量模型在长输入下的实际使用能力,而不是核对它的标称长度。标称窗口回答的是「能不能装进去」,评测要回答的是「装进去之后有没有被用上」

标称窗口不等于可用窗口

两者之间的差距来自注意力的分布:信息放在开头或结尾时被使用的概率明显更高,放在中段时容易被忽略。这意味着同样长度的输入,实际可用程度取决于关键信息的位置,而不只取决于总量。

三段评测法

  • 首段:把关键信息放在输入开头,测一次。
  • 中段:把同一信息放在中间位置,其余内容填充,测一次。
  • 尾段:把同一信息放在结尾,测一次。
  • 对照:三段使用完全相同的信息与问题,只改变位置,比较正确答案率。

三段差异明显时,说明注意分布不均,此时把重要内容前移是最直接的缓解方式,而不是继续加长输入。

还应该测什么

  • 干扰项增多:在无关内容比例提高时,正确答案率如何变化。
  • 多处信息:需要在长文里综合两处以上内容才能回答的问题。
  • 信息冲突:长文中包含互相矛盾的两段,考察是否指出冲突。
  • 延迟与成本:输入变长之后响应时间与单次支出如何变化。

与检索方案的成本对比

  • 长上下文方案:单次调用成本高,但省掉了检索层的建设与维护。
  • 检索方案:需要索引与排序投入,但单次送入的内容短,成本更可控。
  • 组合方案:先检索缩小范围,再把较多的候选送进上下文,兼顾覆盖与成本。

常见误判

  • 把窗口长度当成能力:能接收多长与能用好多长是两件事。
  • 只在短文档上测试:短输入下表现良好,无法说明长输入下的行为。
  • 只看正确率不看成本:长上下文带来的支出增长往往是持续性的。
  • 忽略位置因素:同一份材料换一个顺序,结果可能完全不同。
  • 只看单次结果:偶发答对说明不了稳定性,需要重复运行再下结论。

验收

  • 三段位置下的表现有对照数据,且差异可解释。
  • 评测使用的文档长度与真实场景一致,而不是便于测试而缩短。
  • 延迟与成本有实测记录,并与替代方案的估算做过比较。
  • 在已确认的可用长度下给出使用建议,而不是照搬标称值。

怎么把评测用进项目

这套评测的价值在于给出一个可用的长度与摆放建议,而不是产出一个分数。落地时至少要回答三个问题:哪些材料必须放在前面、单次送入多少内容、以及超出之后怎么降级

  • 约定优先位置:把规则、结论与口径类内容固定放在输入前部,减少对中段注意力的依赖。
  • 约定内容上限:在实测可用长度内设定送入上限,超出部分走检索或摘要。
  • 约定降级方式:内容过多时优先丢弃相关性低的片段,并保留来源标注。
  • 约定复核时机:更换模型或调整提示结构后重新测一次。

FAQ

常见问题

与这篇相关、并且被问得最多的几个问题

标称窗口很长,是不是就不需要检索了
不一定。长窗口的成本随输入长度上升,且关键信息位置会影响效果。是否仍需检索,取决于内容规模与成本约束
怎么缓解中段信息被忽略
把最关键的结论或规则放在开头,或在问题里明确指向需要使用的材料,减少对中段注意力的依赖
评测要准备多长的文档
与真实使用场景的长文规模相当。为方便测试而缩短文档,会让结论无法反映实际部署时的行为