（来源：科技行者）
你有没有遇到过这种情况：手里拿着一本厚厚的小说，老师只问你一个问题，比如“谁是凶手”。你不需要把全书从头读到尾才能回答，你只需要翻到关键的那几页。
但现在的语言模型做不到这一点。
它必须把整本书，一字一句，塞进自己的“脑子”里，才能开口回答你的问题。而且这个“脑子”是有容量上限的，这个上限在业界被称为上下文窗口。
**上下文窗口**：指语言模型一次能够处理的最大文本长度，超过这个长度的内容模型根本看不到。
更麻烦的是，就算文本长度还没超过这个窗口，模型的表现也会随着文本变长而悄悄变差。有研究发现，声称能处理12.8万token的13个模型里，有11个一旦问题和原文的用词不一样，准确率在3.2万token时就已经跌破短文本时的一半了。换句话说，这些模型吹的牛，大多数兑现不了一半。
这就是这篇论文想解决的事。它的名字叫Periscope，中文直译是“潜望镜”，这个名字取得很巧妙，因为它干的事情确实像潜望镜：不需要把整个潜艇升到水面上去看全局，只需要伸出一根细长的镜子，分段扫视，就能拼出整个战场的样子。
一本书读不完,那就别一口气读
先说说现在大家都在用的三条老路，以及它们各自卡在哪里。
第一条路是把窗口做得更大。你可能听过YaRN、LongRoPE这类技术,它们能把模型原本只能读3万token的窗口硬生生拉到几十万甚至上百万。但这类方法有个绕不开的物理限制:模型内部的注意力机制,原理上是让每个词都和其他所有词两两比较一遍。
**注意力机制**：模型理解文本时，让每个词都去关注（计算关联度）文本中所有其他词的方法，这是Transformer架构的核心。
文本长度翻倍,这种两两比较的计算量就要翻两倍以上。这叫平方级增长,学术一点的说法是二次复杂度。读10万字费的力气,读100万字可能要费100倍以上的力气,而且存储这些计算中间结果所需要的显存,也随着文本线性暴涨。论文里给了一个具体数字:一个27B参数的模型,如果真要一口气读完450万token的文本,它需要296GB的显存来存这些中间结果,相当于三块以上的80GB显卡才够用。而光存模型本身的参数,只需要54GB。换句话说,读文本本身比装模型还贵五倍多。
第二条路是先筛选再读,也就是检索增强生成,英文叫RAG。
**RAG（检索增强生成）**：先用一个独立的检索模型从海量文本里挑出看起来相关的几段,再把这几段喂给语言模型去读。
这条路的问题是,挑选的工作交给了另一个模型,而这个挑选模型和最终回答问题的模型用的是不同的判断标准。挑选模型基于词语相似度来判断相关性,但很多时候关键证据和问题描述得完全不像,挑选模型压根发现不了,它漏掉的东西,后面读的模型再聪明也救不回来。
第三条路是把文本切成一段段,分别读,再想办法把结果拼起来。比如Chain of Agents这种方法,让一个个“工作者”依次读一段文本,写一段摘要传给下一个工作者,最后由一个“经理”模型汇总所有摘要给出答案。
但这种链式传递有个致命伤:每个工作者写摘要的时候,它还不知道后面的文本里藏着什么。如果后面第9段才出现真正的关键证据,前面8个工作者在写摘要时根本意识不到这段东西重要,摘要里自然就没留下它的痕迹。证据这样一路传下去,传到经理手里的时候,可能早就在某个环节被悄悄丢掉了。
这就好比开会讨论一个案子,十个人轮流发言,每个人只根据前一个人说的话加上自己读的那部分材料来补充意见,到最后一个人发言时,前面漏掉的关键线索,已经没人能补上了。如果不这样接力传递,而是让十个人各自读完材料后同时报告,会不会好一些?这正是Periscope想干的事。
把一本书铺成一张网格,同时派人扫视
Periscope的核心想法说起来不复杂:很多长文本任务,本质上是“在一堆选项里选一个”的决策题。
比如判断某份文档是否和某个问题相关,只需要文档里有一部分内容支持这个判断就够了。再比如一道四选一的阅读理解题,只要文本里有一段话能撐起某个选项,这个选项就该被选中。
**决策类任务**：答案来自一个有限集合（比如多选题的四个选项，或者“相关/不相关”这两个判断），而不是需要生成一段连续的新文本。
既然答案只需要一处证据支撑,那就没必要让模型一次性读完全部文本,只需要让模型分别看过文本的各个局部,再把每次看到的判断结果汇总起来,取其中最有信心的那个答案。
具体怎么分段看?论文设计了一个巧妙的网格结构。把整篇文本切成N个小块,每块大约500个token,然后设K等于N的平方根,把这N个小块排成一个K乘K的方格,就像棋盘一样。
接着,模型会做两类“扫视”。第一类叫局部探针,沿着方格的每一行横着读,也就是读K个连续的小块,相当于把文本中紧挨着的一段连续内容拼起来读一遍。第二类叫跨步探针,沿着方格的每一列竖着读,也就是每隔K个小块取一块,这样一列读下来,采样的是整篇文本从头到尾分散的若干片段。
**局部探针与跨步探针**：局部探针负责读某一段连续的文字（像翻开书的某一章），跨步探针负责均匀地从全书每隔固定距离取一小段（像快速翻阅全书的目录和每章开头）。两者加起来，一个管细节，一个管全局。
这里有个关键细节:每一个小块,都正好同时属于一个局部探针（它所在的那一行）和一个跨步探针（它所在的那一列）。也就是说,每块文字都被读了两遍,一遍是放在它周围的上下文里读,一遍是放在全文的采样视角里读。
这就像是去评估一个班级学生的整体水平。局部探针相当于挑一个学生,仔细看他从期中到期末所有的作业和考试,了解他这段时间的完整表现。跨步探针相当于不看某一个学生的全部材料,而是把全班每个学生在某一次测验里的成绩拎出来,横向比一比。如果只做局部探针,你会很了解某个片段里发生了什么,但不知道这件事在全书里是不是独一无二的证据,还是说类似的内容到处都有。如果只做跨步探针,你能知道全书大概哪里出现过相关字眼,但不知道那一处的上下文到底支不支持这个判断。两者缺一个,判断力都会打折扣。论文里专门做了实验验证这件事:只用局部探针,在BRIGHT检索任务上的NDCG@10指标是0.551，加上跨步探针后直接跳到0.637,整整高出将近0.09。可见那个“全局视角”不是摆设,是真的在起作用。
每次探针读的文本量有多大?大约是根号下(s乘c)个token,这里s是全文长度,c是每个小块的大小。这个数字远小于全文长度,所以每次探针都是一次“小快读”,读完立刻给出判断,不生成任何额外文字,只看模型给出答案的那一个token上的概率分布。
证据地图:答案从哪里来,一目了然
每个探针读完之后,会给每个候选答案打一个分数,这个分数叫“对数几率”，衡量的是“这段文本支持这个答案”相对于“这段文本什么都不支持（弃权）”的强弱程度。
**对数几率打分**：在选项列表里专门加一个“不确定”选项,模型给每个真实选项的信心,减去给“不确定”选项的信心,得到的差值就是这段文本对这个选项的支持强度。这样设计是为了让没有证据的片段老老实实打低分,而不是随便蒙一个选项。
每个候选答案,取它在所有局部探针里的最高分,加上它在所有跨步探针里的最高分,两者相加就是这个答案的总分。这个设计背后的逻辑很直白:只要某处局部有证据,某处全局采样也捕捉到了相关信号,这个答案就该被相信。
更有意思的是,因为每个小块都正好对应一个局部探针和一个跨步探针,所以可以把这两个分数加起来,给方格里的每一个小块打分,这样就得到了一整张分数地图。地图上分数最高的那个格子,正好就是支撑最终答案的那块证据所在的位置。
这个地图是“白捡”的,不需要额外计算,因为前面做探针的时候已经把分数算出来了,只是重新排列组合了一下。有了这张地图,就能干好几件事:给文档打相关性分数来做排序;直接从地图里选出最高分的答案而不用再读一次原文;定位证据到底在哪一块;或者挑出地图上得分最高的K个小块,拼起来再给模型读一次,得到一个更稳的答案。
这就像侦察兵先在高地上用望远镜扫视整片战场,画出一张热力图,标出哪里敌情最密集。指挥官不需要亲自跑遍整片战场,只要看着这张热力图,就知道该往哪里派遣主力部队。如果没有这张地图,指挥官要么把所有部队平均撒出去（相当于读整篇文本,代价巨大）,要么随便挑一个方向猛攻（相当于只读文本开头,容易漏掉真正的战场）。
成本账怎么算:什么时候该探针,什么时候该硬读
论文把这套方法的开销算得很细。
如果窗口大小是W个token,每块大小是c个token,那么K大概等于W除以c。整个网格能覆盖的最大文本长度,是K的平方乘以c,约等于W的平方除以c。举个例子,假设每块500个token,一个3.2万token窗口的模型,理论上能通过这种方式读到200万token的文本;一个12.8万token窗口的模型,能读到3300万token。这个数字远远超出了模型原本能直接处理的范围。
但探针不是没有代价的。因为每个小块要被读两次（一次局部一次跨步）,探针总的计算量是文本长度的1.5次方级别增长,而不是传统单次整体阅读的2次方级别增长。这意味着文本短的时候,探针反而比直接整体读更费劲（因为重复读了两遍）,但文本长到一定程度后,探针的开销增长速度明显比整体阅读慢,最终会反超。论文算出这个临界点,对于27B参数的模型大约是27.8万token,低于这个长度,直接整体读更省;高于这个长度,探针更省。
显存上的省法更直观。模型读文本时需要缓存每个token对应的中间计算结果,这个缓存叫KV缓存，它的大小随文本长度线性增长。整体读一次450万token的文本,27B模型需要296GB缓存,而一次探针只需要3.1GB,因为探针从来不会超过模型原本的窗口大小。换句话说,只要模型本身能塞进一块显卡,它就能用这种方式读任意长的文本,而不需要换更大的显卡去存文本的缓存。论文里有一句话说得挺到位:读长文本需要的,是能装下模型的显卡,不是能装下文本的显卡。这句话听起来简单,但它把“模型能力”和“硬件门槛”解耦了,这其实是个挺大的事。
实验说话:9千token打平26万2千token
论文在三个基准上做了测试。
第一个是LongBench v2,包含503道四选一的问题,文本长度从8千到200万字不等。拿Qwen3.5-4B这个模型来看,直接整体读在不同窗口下的最高准确率是41.9%（在13.1万token窗口下取得）,窗口再放大到26.2万或者100万反而掉到41.6%和39.2%。而用Periscope方法,只读地图挑出的K个小块,大约9千token,准确率同样是41.9%，用不到窗口阅读十分之一的文本量,打平了窗口阅读的最高分。
和同样读K个小块的其他挑选方式比,Periscope选出的小块明显更准：比用嵌入相似度挑选的方式高6个百分点,比随机挑选高9个百分点,比直接取开头几块高11个百分点。这说明关键不在于“读得少”,而在于“知道该读哪里”。
对于更强的Qwen3.5-27B模型,结果更有意思。在所有问题都超过13.1万token的那部分数据（也就是长文本子集）里,Periscope的直接读出法拿到57.4%,和26.2万token的整体窗口阅读打平,比13.1万窗口阅读高出7.4个百分点,而且每次调用只需要3.1GB缓存,整体阅读需要17GB。
第二个基准是InfiniteBench的英文多选题,中位数文本长度是15万token,相当于读完一整本小说。Periscope选出的K个小块读法拿到82.1%,比26.2万token窗口阅读高5个百分点,比13.1万token窗口阅读高8个百分点。拆开看更明显,在79份能被13.1万窗口完整读完的小说里,整体阅读反而领先；但在150份读不完的小说里,Periscope的方法领先14个百分点,84.0%对70.0%。
第三个基准是BRIGHT检索任务,专门考验需要推理才能判断相关性的检索场景,文档中位数长度334到6701token，最长超过180万token。这次完全不读第二阶段,只靠那张证据地图给文档打分排序,Periscope的NDCG@10指标是六种方法里最好的,比专门训练过的检索模型Qwen3-Embedding-4B还高出三个百分点左右。
这组数据背后藏着一个更深的问题:为什么窗口越大,反而有时候表现更差?论文给出的解释是,窗口变大之后,模型要在一个更长、更稀疏的输入里找证据,这个过程本身就会增加噪声和干扰。而探针的每一次调用,永远只处理一个很小的片段,模型在这种短输入上的判断力,一直停留在它最擅长的区间里,没有被拉到它表现变差的那个长度。这就像让一个人读完一整本500页的推理小说后立刻回答凶手是谁,和让他分别读十段摘录后分别判断“这段话有没有暗示凶手”,后者反而更容易保持清醒的判断,因为每一次判断面对的信息量都没有超出他能稳稳处理的范围。
这套方法也不是万能的
论文自己也坦白了局限。
Periscope擅长的是证据集中在一处的任务,也就是答案只需要一段文字支撑的情况。但对于证据分散在多份不同文档里、需要把多处线索拼起来才能回答的多文档问答任务,Periscope的两阶段读出法反而比整体窗口阅读差了6到9个百分点。原因也容易理解:选出来的K个小块,是地图上得分最高的几个,但如果真正的答案需要同时结合三个分散在不同角落的小块,选K个高分块未必能把这三块都凑齐。
另外,这套方法只适用于答案落在一个有限集合里的任务,比如选择题、相关性判断、证据定位。对于需要生成一段开放式长文字的任务,比如写摘要,这种“取最高分”的读出逻辑并不直接适用,论文把这个留给了未来的工作。
论文还提到一个很实际的细节:当文本本身就很短，短到一个探针就能完整读完的时候,地图式的拆分方法并不比普通的检索方法更强,因为跨步探针这时候采样的内容和局部探针重复了,没有额外信息可以挖。研究者专门做了个小规模实验验证这一点,用100份标注好证据位置的文档测试,文档长度500到1500token,刚好能塞进一个探针。结果显示,地图方法和只用局部探针的方法打了平手,证据地图的优势,是在文本长到超出单次探针能力范围之后才真正显现出来的。这提醒我们,任何方法都有它的适用边界,Periscope的价值不在于处理短文本,而在于处理那些传统方法根本读不完的超长文本。
写在后面
读完这篇论文,我一直在想一个问题：这套方法本质上是在用“并行的短视角”替代“串行的长视角”,这个思路其实不新鲜，但把它做成一个可以直接套用在任何冻结模型上、不需要训练、不需要改架构的推理方法,这件事本身挺值得琢磨。
论文里有个细节我觉得特别有意思:他们提到即便不读第二阶段，只靠探针本身的分数就能直接给答案（也就是"direct"读法）,这个结果和真正读完整文档再给出的答案,在27B模型上相关系数达到0.80,71%的情况下给出的答案完全一致。这说明一个很反直觉的事:模型根本不需要把文本连起来读才能形成和"读完全文"几乎一样的判断,只要给它看过的碎片足够有代表性,它自己就能在心里把答案拼出来。这多少动摇了我们对"模型必须读完整上下文才能理解全局"这件事的直觉。
另外一个让我多想了几分钟的地方是,论文专门测试了把一个小模型选出来的证据地图,交给一个更大的模型去读,结果比大模型自己用嵌入检索选出来的内容还准。这意味着"挑证据"和"读证据给答案"这两件事可以彻底拆开,由不同能力的模型分别负责,这个分工思路放到实际系统设计里,可能比单纯堆更大的模型更划算。
这篇论文留下的问题是,如果证据真的散落在十个不同的角落,而答案需要把十处线索同时放进脑子里才能想明白,那么无论探针切得多巧妙，地图画得多精准，最后那一步"综合判断"要怎么做,才能不漏掉任何一块?这件事,目前还没有答案。
Q&A
Q1：Periscope是什么？
A：Periscope是一种训练免调整的推理方法，让冻结的语言模型通过局部和跨步两类短探针分段扫视长文本，再把结果拼成一张证据地图来回答问题，不需要一次性读完整篇文本。
Q2：Periscope和检索增强生成（RAG）有什么区别？
A：RAG依赖独立的检索模型提前筛选文本片段，筛选标准和最终回答模型不一致；Periscope由同一个模型自己判断每段文本的证据价值，筛选和回答的判断标准是统一的。
Q3：Periscope在什么情况下效果不好？
A：当证据分散在多个不同文档、需要同时综合多处线索才能回答的多文档问答任务上，Periscope的效果会比直接整体阅读窗口差一些。
