Periscope：让冻结语言模型读懂超长文本

导语

上下文窗口并不只是语言模型的长度上限，也是推理成本和显存占用的瓶颈。文本越长，模型往往越难保持注意力；即使输入没有超过窗口，准确率也可能随长度下降。来自 KAUST 的研究团队提出 Periscope，尝试在不训练模型、不修改模型参数的前提下，让冻结语言模型处理远超原生窗口的文档。

把一次长读改成多次探针

Periscope 的核心思路不是强行扩展上下文，而是把“从长文中做有限选项判断”拆解为一组短问题。系统先将文档切成 N 个块，并把它们排列在接近 K×K 的网格中，其中 K 约为 N 的平方根。随后，模型执行两类探针：一类读取连续的局部片段，保留相邻内容和细节；另一类按间隔抽取片段，让每次读取都能覆盖文档的更大范围。

每个探针都向模型提出同一个问题，例如哪个选项得到文本支持。系统不必生成完整回答，而是比较候选答案在单个输出 token 上的对数几率。对每个答案，Periscope 综合局部探针和跨文档探针的最佳分数；与此同时，它还可以根据不同探针对各文本块的贡献建立证据图。图中的高分位置，就是最可能支持答案的文本区域。

评测表现与资源成本

这套方法的价值在于，它把“读取整篇文档”转化为“寻找最相关的少量片段”。在 LongBench v2 中，只读取证据图排名最高的约 9k 个 token，效果可以匹配同一模型在 32k 到 1M token 窗口范围内取得的最佳窗口式结果。在上下文中位数约为 150k token 的 InfiniteBench 上，Periscope 比最佳窗口读取方案高出 5 个百分点。在 BRIGHT 的长文档检索任务中，它的 NDCG@10 也在六种方法中排名第一。

显存方面，每次调用只需缓存一个探针。研究者报告称，27B 模型可以在单张 80GB GPU 上处理 450 万 token 的上下文；相比之下，若直接进行一次长序列前向计算，KV cache 需求可能达到 296GB。其代价是需要多次探针调用，整体成本随文本规模增长，但比单次超长读取更容易落地。

意义与局限

Periscope 说明，长上下文问题未必只能靠扩大窗口解决。对于文档问答、选项判断、证据定位和长文检索等任务，模型首先需要找到支持结论的区域，而不是记住全文。把全局覆盖和局部细节结合起来，可能是一条更节省显存的推理路径。

不过，这种方法依赖任务能够表达为有限候选答案的比较，并不等同于让模型自由生成一篇完整的长文总结。探针数量、切块方式和问题形式也会影响成本与效果。因此，Periscope 更适合作为超长文档筛选和证据定位层，再与后续的精读或生成步骤配合使用。

来源：Hugging Face Daily Papers