这项由滑铁卢大学、小米等机构研究人员共同完成的研究，以预印本形式于2026年6月5日发布在arXiv平台，论文编号为arXiv:2606.06880，研究方向属于信息检索与人工智能交叉领域。感兴趣的读者可通过该编号直接检索完整论文。
**一、从图书馆员到侦探：AI搜索的身份转变**
先从一个场景说起。你委托一位助理去图书馆帮你查一个极其冷僻的历史问题——比如"1916年某位女性曾在街头敲钟宣传她开办的泥砖学校，她是谁？"这个助理有两种工作方式。第一种，他跑进图书馆，迅速从书架上抽出五六本看起来相关的书，拍下几页内容递给你，然后说"就看这些吧"。第二种，他拿到一个通行证，可以在整座图书馆里自由穿行，翻开任何一本书，在书页间来回比对，直到找到答案为止。
显然，第二种方式更有可能找到答案。这正是近年来AI搜索领域正在经历的一场根本性转变——从"图书馆员"变成"侦探"。
传统的AI搜索系统扮演的是图书馆员的角色：系统根据你的问题检索出几份文件，塞进AI的"视野"里，AI读完这些内容后给出答案。这套方法学名叫做"检索增强生成"，是目前绝大多数AI问答系统的工作方式。它快，但有个致命弱点：如果答案不在那几份被挑出来的文件里，你就彻底没辙了。
而所谓"侦探模式"，是让AI直接在整个文件库里自由探索，就像一个侦探可以翻遍案发现场的每个角落。在计算机科学的术语里，这叫做"直接语料库交互"（Direct Corpus Interaction，简称DCI）——AI通过类似于电脑命令行的工具，比如`grep`（一种在文件里搜索特定词语的命令）和`cat`（查看文件内容的命令），在原始文件库里自由穿梭。
这个"侦探模式"听起来很美，但它有个严重问题：当案发现场从一个房间扩大到整座城市时，侦探就会迷路了。
**二、侦探在迷宫里迷失了方向**
研究团队在论文中引用了一个令人印象深刻的数字：当文件库从10万份文件扩大到20万份时，AI侦探平均需要调用的工具次数从38.5次暴增到86.9次，耗时和成本翻倍，而答题准确率却下降了13.6个百分点。当文件库继续扩大到40万份时，准确率直接跌至37.5%，而且每100个问题里有20个根本无法在规定时间内完成。
这个现象背后的原因其实很直观。`grep`这类命令就像是拿着手电筒在黑暗的图书馆里找书——文件库越大，扫描一遍所需的时间越长，AI侦探的大量精力都浪费在翻阅与答案毫不相关的内容上，等到它终于找到关键线索时，时间和预算已经耗尽了。
于是，研究团队面对的问题变得非常清晰：如何给这位AI侦探划定一个合理的"调查范围"，让它既不像图书馆员那样只能看几份预先挑好的文件，又不像无头苍蝇一样在整个文件库里乱撞？
这个问题的答案，就是本篇论文提出的核心概念——**交互空间**（Interaction Space）。
**三、给侦探划定案发现场：交互空间的两个关键设计**
研究团队给出了一个精妙的比喻框架，本文也将沿用这个框架来理解他们的方案。
以往的讨论要么让AI侦探只能看警方提前准备好的"案件摘要"（传统检索），要么让侦探在整座城市里自由行动（DCI）。研究团队的核心主张是：应当给侦探划定一个"案发现场封锁区"——一个有明确边界、但侦探可以在其中自由探索的空间。
这个"封锁区"需要满足两个关键条件，缺一不可。
第一个条件是**边界要由检索系统来划定**。封锁区不能太大，否则侦探依然会迷路；也不能太小，否则关键证据可能被圈在外面。这个边界必须是明确的、持久存在的，侦探可以反复在其中穿行，而不是每次"询问"系统后才临时拼凑一个范围。
第二个条件是**封锁区里的物证要经过整理**。放进封锁区的文件不能是杂乱无章的原始状态——就像一个真实案发现场，合格的侦探希望看到的不是堆在地上的一堆乱纸，而是已经被标注了"第3抽屉、第12页、第3段有关键信息"的有序档案。换句话说，文件需要被预处理，让侦探能快速定位到文件内部的具体位置，而不是每次都从头读到尾。
基于这两个条件，研究团队提出了他们的系统——**RISE**，全称是**Retrieving Interaction SpacE**（检索交互空间）。接下来我们详细看看RISE是怎么工作的。
**四、RISE的第一层设计：用BM25圈出"案发现场封锁区"**
BM25是一种非常经典的文本检索算法，历史可以追溯到上世纪90年代，其工作原理类似于"词频统计"——哪份文件里出现了你搜索的关键词，而且这些词在整个文件库里不太常见（说明它们更有区分度），那这份文件就更可能与你的问题相关。虽然BM25在技术上远不如近年来基于深度学习的神经网络检索方法"高端"，但研究团队有意选择了这个简单方案，原因后文会解释。
RISE的工作流程从AI侦探向BM25发出搜索请求开始。侦探可以一次性提交多个相关子问题，BM25从整个文件库中为每个子问题检索出排名最靠前的1000份文件，然后将这些文件的并集（去重后通常在一万份左右）统一放进一个专属于这次查询的工作目录里。这个工作目录就是"案发现场封锁区"。
这个封锁区有几个重要特性。首先，它存在于AI的"视野"之外——不是把1万份文件全部塞进AI的对话窗口（那根本放不下），而是以文件系统的形式存放在计算机的存储空间里，AI可以随时通过`grep`、`cat`等命令去访问。其次，AI每次执行新的搜索，结果会持续累积到这个工作目录中，封锁区会越来越完整，但从不会缩小——这就像案发现场的物证只会增加，不会莫名消失。第三，搜索返回给AI的直接反馈只是每个子问题的前10条预览，但完整的1000条检索结果都已悄悄存进了工作目录，AI可以通过后续的命令行工具逐一探索。
这个设计的妙处在于：AI侦探不需要在问题问出的那一瞬间就把所有相关文件读完——它可以先粗略扫描，发现线索后再精确定位。就像侦探到达案发现场后不会立刻把每件物品都细细研究，而是先环顾四周，确定方向，然后重点检查最可疑的区域。
研究团队将这个"只有BM25封锁区、没有文件预处理"的版本单独命名为**RISE-BM25**，作为一个对比实验的基准版本。这个版本只实现了两个条件中的第一个。
**五、RISE的第二层设计：给每份档案加上"导航地图"**
现在封锁区有了，但里面的文件依然是原始的纯文本——一篇几千字的学术论文或历史资料，侦探要找其中某个细节，还是需要从头读到尾。这就像虽然你把嫌疑人的全部档案都搬进了审讯室，但每份档案都是密密麻麻没有任何标注的手写文件。
RISE的第二层设计解决了这个问题：在将文件放入封锁区之前，系统会在离线状态下对每份文件进行一次预处理，给它加上一份**带行号的目录**（Table of Contents，简称TOC）。
这个预处理过程使用了OpenAI的一个小型AI模型（gpt-5.4-nano）来自动分析每份文件的结构，生成各章节的标题、描述和定位文字（锚点），然后由一段确定性程序在原文中精确定位这些锚点，并在文件开头插入一份格式化的目录，格式类似于"第22至47行：标题与摘要概述；第85至151行：研究方法与数据；第240至258行：结论与解释；第259至265行：致谢与信息来源"。
关键在于：这个预处理完全不修改原文内容，只是在前面加了一份导航地图。就像在一本没有目录的厚书前面加上"第58页：第一章，拿破仑的童年；第143页：第三章，滑铁卢战役"——书的内容一字未动，但读者找到自己需要的部分所需的时间从"逐页翻找"变成了"直接翻到那一页"。
研究团队在10万份文件上运行了这个流程，成功率非常高：99.3%的章节锚点能被精确定位，94.5%的文件至少生成了一条有效的目录条目，整个流程没有任何文件处理失败。每份文件的预处理成本约为0.0014美元，是一次性的离线工作，不影响查询时的实时性能。
**六、在"封锁区"里破案：AI侦探的实际工作流程**
现在RISE的两层设计都就位了，AI侦探是怎么工作的？研究团队提供了两个具体案例，非常生动地展示了这套系统的运作方式。
第一个案例来自RISE-BM25版本（只有封锁区、没有TOC预处理）。问题是这样的："1916年某位女性开办了一所日间学校，她曾走在街上敲钟宣传那所泥砖建造的学校，她是谁？"注意，答案中的人名完全没有出现在问题里，AI根本不知道自己要找谁。
面对这个问题，AI侦探没有直接去搜索答案，而是把问题分解成了15个不同角度的子问题，分五次提交给BM25。这些子问题分别从"110年前"、"火灾后重开于1970年代"、"在大火前开业"、"走在街上敲钟"、"1916年"等不同线索出发，每次搜索都把相关文件拉入封锁区，最终积累了6158份文件。然后，AI用`rg`命令（一种高效的文本搜索工具）在封锁区里同时搜索"泥砖"、"钟声"、"1916"、"火灾"、"重开"等关键词，在两份文件（一份关于某教堂历史，一份关于克伦斯塔德教区历史）中发现了关键线索，最终确认答案是"Sister Mary Theresa Dawkins"。整个过程只花了8轮对话、0.06美元。
第二个案例展示了TOC预处理的威力。问题是："找到一篇2010年代发表的论文，其致谢部分感谢了一位领导统计中心的名誉教授，请问这篇论文发表在哪个期刊？"
AI侦探通过一次搜索把相关文件拉入封锁区，然后打开一份候选论文的开头，看到了TOC：目录告诉它"第259至265行：致谢与信息来源"。AI没有读完这篇论文，直接跳到第259行开始阅读——那里写着对某统计中心名誉教授E. Jaba的感谢，完全符合题目线索。再往前看文件头部，论文所在期刊名称"Romanian Statistical Review"赫然在目。整个过程6轮对话，4次文件读取中有两次是直接跳到TOC指定的行号，没有任何无效的从头到尾扫描。
这两个案例形象地展示了RISE的"分工"：BM25负责圈定封锁区，AI侦探在封锁区里用命令行工具进行精确排查，而TOC则让侦探能直接翻到文件的关键页码，避免逐行阅读的低效。
**七、实验结果：在真实测试中，这套方案表现如何？**
研究团队用一个叫做BrowseComp-Plus的测试集来评估各种方案的表现。这个测试集的特点是问题非常难，全都是那种需要深度挖掘才能找到答案的"侦探级"问题，而且答案就藏在一个固定的文件库里（而不是依赖实时互联网搜索），这样不同方案的比较才公平。实验中，研究团队从这个测试集里随机抽取了100个问题进行评估。
实验对比了四套方案：完整的RISE（两层设计都有）、只有封锁区的RISE-BM25、传统的"摘要检索+文档获取"方案（称为retrieval-agent），以及完全无边界的DCI原始方案。同时，研究团队还测试了三种不同档次的AI模型——Xiaomi的mimo-v2.5-pro、OpenAI的gpt-5.4-mini（中等推理强度）和gpt-5.4-nano（高推理强度）。
在公平起见的设计上，研究团队刻意给了DCI更宽松的预算：DCI允许调用300次AI接口、使用1.5小时的时间，而RISE只允许100次调用和1小时时间。也就是说，DCI获得了3倍的接口调用次数和1.5倍的时间预算，任何有利于DCI的结果都是在这个"让步"条件下取得的。
结果如何？在中档模型gpt-5.4-mini上，RISE以78%的准确率与DCI持平，但每次查询的成本是0.28美元，而DCI是1.10美元——前者是后者的四分之一。在高档模型mimo-v2.5-pro上，RISE同样达到78%准确率，成本仅0.38美元；而DCI只有60%准确率，成本0.52美元，而且100个问题里有18个因为超时而没有给出答案。在低档模型gpt-5.4-nano上，DCI以71%的准确率领先，这是DCI表现最好的情况，但成本是0.20美元，而RISE只需0.05美元。
传统的摘要检索方案（retrieval-agent）在两个较大模型上都比RISE低约5到10个百分点，尽管它找到相关文件的能力和RISE差不多（两者的BM25召回率相近）。这说明问题不在于找不到文件，而在于找到文件之后，传统方案只把很少的内容真正"送到"AI面前——它把文件截成512字符的短片段再交给AI，大量有价值的内容在截取时就已经丢失了。
此外，研究团队还专门用最强的gpt-5.4模型测试了RISE，得到了82%的准确率，是所有配置中最高的，而且该模型在封锁区内"覆盖"到金标准文件的比率高达92.4%。这说明随着AI模型能力的提升，RISE的框架能持续受益，上限还远未触及。
**八、扩大十倍后的压力测试：当文件库膨胀到百万级别**
评估系统在"大海"里捞针的能力，不能只看小鱼塘里的表现。研究团队将文件库从10万份扩大到100万份（在原有文件库里加入了90万份来自FineWeb-Edu数据集的干扰文件），再次进行评估。
结果非常能说明问题。RISE-BM25不仅没有因文件库扩大而退步，反而还略有提升：mimo-v2.5-pro从75%升至83%，gpt-5.4-mini从77%升至81%，gpt-5.4-nano从64%升至65%。研究团队对这个小幅提升持谨慎态度，认为可能是更多文件让BM25的词频统计参数更为合理，或者新加入的文件里恰好有部分与问题相关但没被标注为"金标准"的内容。不管原因如何，关键结论是：文件库扩大10倍，RISE-BM25的表现没有崩溃。
与之形成鲜明对比的是DCI和传统摘要检索。DCI在低档模型nano上从71%直接跌至60%，而且100个问题里有33个因为超时而彻底没有答案——注意，超时的查询往往在等待全库扫描命令的过程中消耗了大量时间，最终什么都没查出来，但账单上显示的API费用反而更低（因为超时后调用次数少了）。这种"低成本但零结果"的情况，正是DCI在大规模场景下的典型失效模式。传统摘要检索方案在mime和nano档模型上也有所下滑，表现始终不如RISE-BM25。
研究团队也坦诚地说明了100万文件测试中RISE（完整版，含TOC预处理）没有参与：因为对新增的90万份文件运行TOC预处理需要额外的费用和时间，而这次实验预算不允许，所以100万文件的测试仅代表"有封锁区、无TOC预处理"的RISE-BM25版本。这是工程预算的限制，并不是RISE系统本身的架构障碍。
**九、BM25检索数量K：多大的封锁区才合适？**
研究团队还测试了一个实际使用中很重要的参数：每个子问题从文件库里检索出多少份文件放进封锁区？他们分别测试了每个子问题检索100份、1000份（默认值）、10000份三种设置。
结果显示，检索数量和准确率之间的关系并不是"越多越好"。在mimo模型上，K=100时准确率反而是最高的（76%），K=1000时为75%，K=10000时降至73%。在mini模型上，K=1000是最优的（77%），略高于K=100的75%和K=10000的75%。在nano模型上，三种设置相差无几（64%、64%、65%）。
这个结果背后的逻辑是：封锁区里的文件越多，AI侦探需要用命令行工具筛查的范围就越大，效率反而降低。K=1000时，积累的工作目录通常在7600到10400份文件之间，这个规模下命令行操作依然很快；K=10000时，工作目录膨胀到四五万份文件，操作明显变慢，却没带来更高的准确率。这说明RISE的核心逻辑在起作用：封锁区需要的是"足够召回相关文件"，而非"尽可能多地包含文件"。
顺便一提，改变K值对AI的接口调用费用几乎没有影响，因为额外的文件只是默默地加入工作目录，并不直接进入AI的对话窗口。K值主要影响的是本地命令行操作的速度，而不是AI的账单。
**十、局限性和未来空间**
研究团队在论文结尾非常坦率地列出了这项研究的不足之处，值得一并介绍。
目前RISE使用的是BM25这种经典的词频检索方法来划定封锁区，而更先进的密集向量检索、晚期交互检索等方法能否带来更好的效果，还没有经过验证。研究团队选择BM25是为了把"检索器的质量"和"交互空间框架本身"的贡献分开讨论，但这也意味着实验结果在检索技术上有进一步提升的空间。
TOC预处理的效果只在10万份文件的规模上得到了验证，100万文件规模下它能否同样有效，目前还缺乏直接证据。理论上没有障碍，但实验没有覆盖到这个规模。
评估的范围也相对有限：只用了BrowseComp-Plus这一个基准测试集，只评估了100个问题，只使用了封闭权重的AI模型，而且评判结果正确与否所使用的AI裁判（gpt-5.1）和实验中使用的部分AI模型来自同一家公司，这在一定程度上存在潜在的评估偏差风险。几个百分点的准确率差异应当被理解为"趋势性结论"而非"精确量化"。
此外，有一个"第四个角落"的实验缺口：如果把TOC预处理后的文件用于传统摘要检索方式（而非封锁区方式），效果如何？这个对比没有做，因此目前还不能完全把"封锁区界面"和"BM25预筛选"的贡献彻底分离。
归根结底，这项研究想说的是一件非常朴实的事：AI搜索代理需要的既不是一叠精选好的文件摘要，也不是一座可以随意进出的无边界图书馆，而是一个有围墙的院子——院子的大小由检索系统来定，院子里的每样东西都被贴好标签，方便AI侦探迅速找到需要的那页纸。RISE正是对这个想法的一次具体实现，而实验结果表明，这个看起来不那么"高科技"的方案，在成本和准确率的平衡上，确实超过了更暴力的"全库扫描"方式。
随着文件库规模持续扩大、AI模型能力持续增强，这项研究提出的框架性问题——"检索系统应该返回什么格式的结果给AI代理？"——可能比任何具体技术实现都更值得关注。目前的信息检索基准测试大多是为"给人看的排名列表"设计的，并不适合评估"给AI侦探用的交互空间"，这或许是这个领域接下来需要认真思考的方向。有兴趣深入了解的读者，可通过arXiv编号2606.06880查阅完整论文。
**Q&A**
Q1：RISE和传统RAG检索方式有什么本质区别？
A：传统RAG把文件截成短片段塞进AI对话窗口，AI只能看到那几段内容。RISE则是通过BM25检索出一批文件存入独立工作目录，AI可以用命令行工具反复探索，随时查看文件的任意部分，不受对话窗口大小的限制，更像是给了AI一个可以自由翻阅的文件柜，而不是几张提前抄好的卡片。
Q2：BM25这么老的技术，为什么在RISE里还能有效果？
A：BM25虽然是上世纪90年代的技术，但它的关键作用不是精确排名，而是"圈出范围"。只要相关文件出现在检索的1000份结果里（召回率够高），AI就能在后续的命令行探索中找到答案。实验显示BM25的召回率在75%到88%之间，足够支撑AI侦探在封锁区里完成推理，而且计算速度极快，适合构建实时交互的工作目录。
Q3：RISE处理100万份文件时为什么准确率反而略有提升？
A：研究团队认为有两种可能的解释。一是新增的90万份文件让BM25的词频统计参数（即IDF值）更加合理，使得检索结果更准确地匹配AI提交的搜索查询。二是新增文件中可能本身就有与问题相关的内容，只是没有被标注为"官方金标准答案"。不管哪种原因，关键结论是文件库扩大10倍后系统没有性能崩溃，这与DCI在同等条件下准确率下降11个百分点的表现形成了明显对比。