面向智能体搜索的交互空间检索

TL;DR RISE 用 BM25 为搜索代理构建有界交互空间，替代耗时的全语料扫描，在百万文档规模以 1/4 成本维持 81% 准确率，解决可扩展性问题。

问题

问题背景

搜索代理（search agents）需要从大规模文本语料中提取证据以回答复杂问题。当前主流范式（如 RAG、ReAct）中，检索环节仍沿用非代理式接口设计：检索器返回 top-k 文档，代理仅被动阅读这些片段，缺乏主动探索能力。

现有方法局限

• 传统检索-阅读范式：将代理的交互范围限制在少数精选片段内，无法支持多跳推理、线索追踪或文档内部细粒度导航（如定位特定段落、跳转相关条目），信息遗漏风险高。
• 直接语料交互（DCI）：代理通过 grep、file read 等 shell 命令直接操作原始语料，灵活性大幅提升，但每次宽泛命令会触发对整个语料的顺序扫描。延迟随文档总量线性增长，在百万级语料下 wall-clock 故障频发（实验显示 100 次查询中 33 次超时），成本失控。

为什么问题难且重要

代理搜索的核心矛盾在于交互灵活性与规模可扩展性的权衡。需要构建一个“交互空间”（interaction space）——既要有检索提供边界以控制延迟，又要对空间内对象进行结构化预处理以支持高效导航（如目录、行号定位）。这涉及检索粒度、文档处理与工具接口的联合设计，是系统工程难题。随着 AI 搜索从百篇向百万篇文档演进，该问题直接决定代理能否走出实验室、进入生产环境。

行业类比

如同关系数据库用 B 树索引替代全表扫描，RISE 为搜索代理创建了一个预索引的语料视图，让探索在可控边界内精准导航，而非在全库中盲目远足。

核心洞察

• **检索的角色被重新定义为构建交互空间，而非传统意义上的文档片段选择**。这区别于主流 RAG 代理简单地从排名列表中阅读文档的方式，也不同于直接语料交互 (DCI) 让代理在无限语料上运行 shell 命令的极端做法。RISE 提出用 BM25 划定一个边界子集，使代理在受限但可导航的空间内自主探索，解决了 DCI 因全库扫描导致延迟随规模线性恶化的扩展性问题，同时保留了代理的交互灵活性。
• **在索引阶段对文档进行面向交互的结构化预处理，是使代理搜索在大规模语料下可行的工程关键**。DCI 虽赋予代理自由，但每次 `grep` 都需扫描全部文件，成本与延迟不可控。RISE 将文档预切分为段落并建立锚点，代理在交互空间内使用的 shell 工具只需操作这些结构化对象，而非整个原始语料。这使得在 1M 文档规模下，用低成本模型就能达成高精度，而 DCI 在同等资源下已出现大量超时失败，为代理搜索系统的实际部署提供了可行的扩展路径。

方法

RISE 框架以用户查询和大规模语料库为输入，输出一个有界交互空间，供搜索代理高效探索并生成答案。其核心流程分为两步：

1. 边界构造：BM25 检索界定交互范围

不再让代理直接面对整个语料库，而是先用经典的 BM25 检索器根据查询对文档排序，取 Top-K 文档构成一个有限子集。这一步为代理的后续探索划定了明确的边界，避免对整个语料库的全局扫描，从根本上控制延迟与算力开销。

2. 对象预处理：让交互空间可导航

在索引阶段，对选入交互空间的文档进行结构化预处理（例如提取关键字段、生成摘要、构建本地索引等），使代理能通过类似 grep、文件读取等 shell 工具在子集内高效跳转和查找。预处理将原始的语料对象转化为更适合工具型交互的形态，而非简单的纯文本片段。

3. 代理执行与答案生成

代理在得到的交互空间内自由组合 shell 命令，进行多步检索、比对与推理，最终输出答案。由于空间已受约束，每一步命令只扫描有限的预处理后文档，保证了大规模下的稳定性（在 100 万文档实验中，RISE-BM25 达到 81% 准确率，而纯 DCI 方式因超时失效导致准确率降至 60%）。

与同类方法的差异：传统检索只为 LLM 提供少量文档片段，代理只能被动阅读；DCI 让代理主动探索但无边界限制，无法扩展。RISE 通过检索提供边界 + 索引预处理实现交互，在保留代理主动性的同时实现了可伸缩的大规模语料探索。

实验

实验设计

实验基于 BrowseComp-Plus 数据集，对比 RISE 与纯 shell 交互的 DCI 基线。RISE 使用 BM25 检索限定交互空间，并在索引阶段对文档进行预处理以支持 shell 式导航（如 grep、文件跳转）。代理模型为 gpt-5.4-mini 与 gpt-5.4-nano，评估维度包括答案准确率、每查询成本，以及在 1M 级语料规模下的扩展性。同时通过消融 BM25 top-K 验证交互空间大小的影响。

关键发现

• 在相同模型下，RISE 达到 78% 准确率，与 DCI 持平，但每查询成本降至后者的约 1/4，显示有界交互能显著减少无效扫描。
• 在 1M 文档 规模下，RISE-BM25 准确率提升至 81%，而 DCI 使用更小的模型 gpt-5.4-nano 时准确率降至 60%，且 33% 的查询因壁钟超时失败，证明无界交互在规模化时不可行。
• 消融实验表明，适当增大 BM25 的候选集 (top-K) 可提升召回，但过大空间反而引入噪声，体现交互空间边界设计的重要。

基线对比解读

传统检索仅提供片段，代理被动阅读；DCI 走向另一端，赋予代理完全自由的 shell 访问，但缺少边界导致扫描代价随语料线性增长。RISE 找到了中间路径：检索不再是选择片段，而是构建交互空间 —— 一个有边界且经过预处理、可高效导航的子集。这个角色转变使代理在准确率、成本与规模适应性之间获得平衡。与 DCI 相比，RISE 的预处理对象（结构化文档、索引片段）让常见 shell 操作无需全量扫描，从架构层面避免了延迟崩溃。

行业影响

落地场景

RISE 的有界交互空间 (bounded interaction space) 设计直接面向需要大规模文档集探查与推理的 AI 代理场景。典型落地包括：企业内部知识库问答、合规审查、代码库语义搜索、客户支持工单分析、学术文献综述等。在这些场景中，语料规模常达到百万级文档，传统的“检索-阅读”模式因上下文窗口限制而丢失信息，而全库 shell 交互（如 grep 遍历）又面临延迟爆炸。RISE 通过 BM25 构建交互边界，使代理仅在高召回子集中执行类 shell 操作，既保留了交互灵活性，又大幅压缩了扫描范围。

商业价值

核心价值线是降本 & 体验提升。RISE 将代理的搜索成本降低至纯 DCI (direct corpus interaction) 的 1/4（在 BrowseComp-Plus 上以 gpt-5.4-mini 达到同等 78% 准确率），直接减少 API 调用开销和墙钟延迟。同时，百万文档规模下 DCI 准确率衰减至 60% 且存在 33% 超时失败，而 RISE-BM25 保持 81% 准确率无失败，保证了大规模应用的可靠性。对产品而言，这意味着能用更轻量的模型实现稳定、高质量的回答，从而提升用户满意度并降低算力投入。

与现有产品 / 工作流的接口

RISE 可视为对 RAG (检索增强生成) 流水线的进化。它在现有 retriever 之上增加了一个“交互空间构造层”，不破坏原有索引管道。集成路径清晰：

• 在企业搜索平台（如 Elasticsearch / Solr）中，利用已有 BM25 索引快速生成候选交互空间。
• 文档预处理步骤（结构化、抽取索引锚点）可作为索引阶段的附加流水线，与向量化、元数据提取并行。
• 代理工具层只需封装 grep、cat 等命令到受限空间，无需改造 LLM 推理框架。

具体用例：

• 电商平台的产品知识库问答：数百万产品规格、用户手册、政策文档，代理可通过 RISE 快速定位参数对比、退货规则，避免全库扫描，响应时间从分钟级降至秒级。
• 金融合规：千页级监管 PDF 库，代理使用 RISE 构造的交互空间聚焦相关章节，用 grep 精确提取条款，准确率高于纯向量相似度匹配，且解释性更强。

局限

• **检索器依赖传统 BM25**：RISE 使用 BM25 构建交互空间，虽然高效，但 BM25 的词袋模型可能无法捕捉语义相关性，尤其在处理复杂查询或异构语料时，可能导致空间的初始边界不理想，影响下游代理的探索效率和最终答案质量。相比密集检索或学习型排序，BM25 的排序能力有限，可能遗漏关键文档，尤其是在需要深层理解的任务中。
• **文档预处理依赖结构化转换**：RISE 在索引时对文档进行预处理，转换为结构化格式以实现 shell 风格导航。这种预处理假设语料具有可提取的字段（如标题、正文），但现实世界文档格式多样，转换过程可能丢失信息或引入噪声。此外，预处理步骤增加了索引成本和系统复杂性，对大规模动态语料重新处理可能不切实际。
• **实验环境和模型限制**：实验仅在 BrowseComp-Plus 数据集和 GPT-5.4-mini/nano 等模型上进行（注：这些模型可能为论文虚构，但按原文）。缺乏对真实世界搜索引擎、不同领域语料（如法律、医疗）以及开源模型的评估。成本比较仅针对特定查询，未全面考虑预处理开销和长期维护成本，难以直接推导至实际部署。