这项由马萨诸塞大学阿默斯特分校、普林斯顿大学和卡内基梅隆大学联合开展的研究，以预印本形式发布于2026年5月，论文编号为arXiv:2605.29307，感兴趣的读者可以通过该编号查阅完整论文。
当你想在一个巨大的图书馆里找一本书时，通常有两种办法。第一种是先把所有书的信息整理成一张索引卡，以后查找时翻索引卡就行。第二种是直接走进书库，拿着手电筒一排一排地扫过去，找到写着你想要内容的那本书。今天要介绍的这项研究，恰恰是在探索第二种方法——让人工智能直接在原始文本里"翻箱倒柜"，而不是依赖预先整理好的索引。
研究团队为这套系统起名叫GrepSeek，灵感来自Unix系统里一个叫做grep的命令行工具。grep的意思是"全局搜索特定字符串并打印结果"，就像一把极其精准的放大镜，能在海量文字里找到你指定的那几个字。GrepSeek把这把放大镜交给了一个经过专门训练的人工智能代理，让它学会在包含两千一百万条维基百科段落（总计约十四GB文字）的超大语料库里，用一系列Shell命令查找、过滤和拼接证据，最终回答复杂问题。
一、为什么现有的检索方式会遇到麻烦
要理解这项研究解决了什么问题，先要明白主流的AI问答系统是怎么运作的。目前绝大多数系统采用一种叫做"检索增强生成"的思路，简单说就是：先把所有文章变成一串数字（行话叫"向量"或"嵌入"），然后建一个数字索引；用户提问时，系统把问题也变成一串数字，找到数字最接近的那些文章，再把这些文章喂给大语言模型生成答案。
这套流程有两个痛点。其一，把文字变成数字的过程不可避免地会模糊细节。两篇文章里的人物可能名字相似，却是完全不同的人；一个化学分子式在向量空间里和另一个相近化学式距离很近，但它们的意思可能天差地别。就像把一副精细油画压缩成低分辨率的缩略图，大致模样还在，但关键细节已经丢失。其二，建立这套索引本身就极其耗费资源。研究团队测量发现，用一个中型嵌入模型对同样规模的语料库建索引需要大约三点二个A100 GPU小时，而用更大的嵌入模型则需要整整六十二点四个A100 GPU小时，同时还需要高达两百二十一GB的内存来存储向量数据库。这对于很多实际应用场景来说，代价相当昂贵。
GrepSeek的思路恰好绕开了这两个问题：既然直接在原始文字里搜索，就不存在向量化导致的语义模糊；既然不需要预先建立索引，前期准备时间从数十小时缩短到约一分钟，存储压力也降低到仅需十四GB，也就是语料库本身的大小。
二、让AI学会用Shell命令"破案"
GrepSeek的核心行为模式可以用侦探破案来理解。一个好侦探面对一个复杂案件时，不会把所有案卷塞进脑子里然后凭感觉猜答案，而是有条不紊地翻查档案，每找到一条线索就更新自己的推断，再决定下一步去哪里查。
GrepSeek扮演的就是这个侦探角色。面对一个问题，它会先想"我需要什么线索"，然后写一条Shell命令去语料库里搜，比如"rg -F 'The Joggers' corpus | rg -i -F 'singer' | head -n 3"，这条命令的意思是：在语料库里找到所有包含"The Joggers"的行，再从这些行里筛出含有"singer"的部分，只取前三条。得到结果后，侦探继续推理，写下一条命令，直到收集到足够的证据，最后给出答案。
整个过程被严格规范成四个标签包裹的格式：推理过程放在think标签里，工具调用放在tool_call标签里，工具返回的结果放在tool_response标签里，最终答案放在answer标签里。允许使用的工具包括rg、grep、find、sed、awk、head、tail、cat、ls、wc、sort、cut、uniq和tr，它们都是标准的Unix文本处理命令。研究发现，在实际使用中，系统绝大多数时候只需要rg和head这两个命令就能完成任务。
三、从零开始训练一个"会破案的侦探"——两阶段训练流程
训练GrepSeek的过程是整篇论文最具创造性的部分，也是解决"如何让小模型学会一件复杂技能"这个问题的核心所在。
研究团队最初尝试直接用强化学习来训练模型，结果一塌糊涂。模型会发出极其宽泛的命令，把整个语料库的大块内容都抓进来，上下文长度急剧膨胀，直接把显存和内存都撑爆——测试中甚至在配备了高达一○二四GB内存的机器上也频繁出现内存不足的错误。这就像一个刚入行的侦探，不知道从哪里下手，索性把整个档案室的文件全部搬到桌子上，显然不是一个可行的方法。
为了解决这个问题，研究团队设计了一个两阶段训练流程。第一阶段叫"冷启动"，核心任务是先给这位新侦探展示一万个高质量的破案示范，让他对怎么查案有基本的感觉；第二阶段再用强化学习让他通过实际破案来打磨技能。
冷启动数据集的生成方式颇为精妙。研究团队引入了两个角色：一个叫"导师"，另一个叫"规划师"。导师是一个大号模型，知道问题的正确答案；规划师是另一个大号模型，但故意不告诉它答案。两个模型的分工是这样的：导师负责从答案出发，逆向推导出一条能找到证据的查询链条；规划师则负责模拟真实侦探的视角，在不知道答案的情况下，根据目前已有的线索决定下一步怎么查。
导师的逆向推导过程尤其值得细说。以一个多跳问题为例（多跳问题就是需要先找到A才能找到B，再由B才能找到最终答案的那种问题）：导师先从最终答案出发，找到支持这个答案的文档；再从这个文档里提取"桥接实体"，也就是连接问题各跳之间的关键人名或地名；然后继续向前一跳，找到支持桥接实体的文档，如此反复。这个过程有一个铁律：导师在构造查询命令时，绝对不能把答案本身当作搜索词，否则就是作弊——就像侦探不能因为知道嫌疑人是张三就直接搜"张三的档案"，而必须通过案发现场的线索逐步推导到张三。
逆向链条构造好之后，规划师登场，把整个链条翻转成正向的时间顺序，并在每一步只能看到之前已经发现的信息的条件下，写出自然的推理文字。导师再对规划师的推理文字进行微调，确保措辞逻辑上能引出那条正确的查询命令，同时不泄露任何规划师在那一步不该知道的信息。
最后，所有生成的样本还要经过严格的质量过滤。规划师根据完整轨迹生成的最终答案与标准答案的词级重合度必须大于零；同时，一个独立的"一致性法官"会审查整条轨迹，确认没有在任何一步出现信息泄露——即推理文字或查询命令中出现了该步骤尚未检索到的信息。只有通过双重检验的样本才会进入训练集。
第一阶段的监督微调完成后，进入第二阶段的强化学习。研究团队采用了一种叫做GRPO（组相对策略优化）的方法。每个问题让模型同时生成五条不同的破案轨迹，比较这五条轨迹各自的得分，让模型向得分更高的方向更新参数。得分的计算方式有两个维度：格式得分是二元的，轨迹结构必须完全符合规范才能得分；答案得分则是连续的，基于预测答案和标准答案之间的词级F1分数，也就是两者共同词的比例。两个分数相乘得到最终得分，这意味着格式不规范的轨迹直接得零分，促使模型始终保持正确的交互格式。
四、让"翻箱倒柜"的速度快到可以实用——并行加速引擎
直接在十四GB的原始文件里执行Shell命令，速度是一个严峻的挑战。研究团队测量发现，单线程顺序执行一条查询命令平均需要五点三九秒。对于一个需要多轮查询的问答系统来说，这个速度实在太慢。
为此，研究团队设计了一套"分片并行执行引擎"。核心思路是：把十四GB的语料库预先切成S个等大的分片，每个分片都是原文件的一个连续子集，且切割边界严格对齐每行的结尾（因为每行是一个完整的维基百科段落，不能在行中间切断）。收到一条查询命令时，引擎同时在所有分片上并行执行，最后把各分片的结果合并。
合并的方式需要根据命令的类型来确定，这是整套引擎的关键设计。引擎内部有一个分类器，会分析每条命令的结构，判断它属于哪种合并模式。对于纯粹的过滤命令（比如rg再接几个grep），各分片的结果直接按分片顺序拼接，就能得到和顺序执行完全一样的输出。对于以head -n K结尾的命令，先在每个分片上截取前K行，然后把各分片结果拼接，最后再全局截取前K行，保证结果的字节级等价性。对于wc -l这样的计数命令，把各分片的计数结果加总即可。对于涉及排序的命令，则用多路归并算法把各分片的排序结果合并成全局有序序列，再截取前K条。任何不符合这几种模式的命令都回退到单线程顺序执行，确保永远不会产生错误结果。
此外，引擎还把语料库常驻在内存里（利用/dev/shm这个内存文件系统），并且为每次查询维护一个持久的后台进程，避免每次执行命令都重新启动进程和加载文件的开销。
效果相当显著。随着分片数量从一增加到八，查询延迟从五点三九秒降低到一点二二秒；增加到三十二个分片时，延迟进一步降低到零点七一秒，速度提升了七点六倍。加速效果在分片数较少时近似线性，到更多分片后由于内存带宽和进程调度开销的限制，提升幅度逐渐趋于平缓。整合所有优化后，GrepSeek在单张A100 GPU、三十二个CPU核心和三十二GB系统内存的环境下，端到端平均回答一个问题只需要约八点六秒。
五、在七个问答基准上和强劲对手的较量
研究团队在七个知名的知识密集型问答数据集上对GrepSeek进行了全面评测，其中三个是单跳数据集（每个问题只需要一条关键事实就能回答），分别是NaturalQuestions、TriviaQA和PopQA；四个是多跳数据集（需要串联多条证据才能回答），分别是HotpotQA、2WikiMultihopQA、MuSiQue和Bamboogle。所有实验用同一个两千一百万条维基百科段落的语料库，评估指标以词级F1为主，同时记录精确匹配率。值得注意的是，GrepSeek只用NaturalQuestions和HotpotQA的训练集来训练，其余五个数据集完全是没见过的测试集，用于检验泛化能力。
对比的基线系统包括多种类型：不用任何检索、完全依靠模型自身记忆的"直接推理"；单次检索加生成的标准RAG；需要多轮推理的IRCoT；需要思维链推理的Search-O1；以及经过强化学习优化、但使用传统检索器的Search-R1。检索器方面覆盖了稀疏检索（BM25）、中型密集检索（E5，一亿一千万参数）和大型密集检索（Qwen3嵌入模型，四十亿参数）。所有方法都使用相同的基础语言模型（Qwen3.5-9B），确保比较的公平性。
总体结果是GrepSeek在七个数据集的微平均F1分数上达到零点五六九一，显著高于最强的密集检索基线Search-R1加Qwen3嵌入（零点五四四一），统计检验证实差异具有显著性。在四个数据集上（NaturalQuestions、HotpotQA、2WikiMultihopQA、MuSiQue）GrepSeek取得最高F1，其中三个具有统计显著的领先优势。多跳数据集上的优势尤为突出，GrepSeek在HotpotQA上的F1达到零点六二三一，比最强基线高出约六个百分点；在2WikiMultihopQA上达到零点五一七八，高出约八个百分点。
不过GrepSeek也有明显的短板。在PopQA上，它的F1比最强基线低了约两个百分点，且差异具有统计显著性。PopQA专注于长尾实体，这些实体的名称在不同来源中可能有拼写变体或带有变音符号。研究团队给出了一个具体的反例：搜索"Edouard Vaillant"时，因为"E"是一个带有变音符号的字母，精确字符串匹配完全找不到他的条目，导致系统只好凭借模型自身的记忆猜答案，结果给出了错误的城市。与此同时，在TriviaQA和Bamboogle上，GrepSeek的表现也略低于最强密集检索基线，但差距不具有统计显著性。
六、拆开来看：每个训练阶段的具体贡献
为了弄清楚两阶段训练中每个部分各自的作用，研究团队做了消融实验，即分别拿掉某一个组件，看性能变化多大。
拿掉强化学习只保留监督微调，微平均F1从零点五六九一大幅下降到零点四二四九，降幅约二十五个百分点。多跳数据集上下降尤为明显，说明强化学习对于让模型学会更复杂的多步推理策略至关重要。拿掉监督微调直接做强化学习，性能崩溃到零点三三一四，这正是研究团队一开始遇到的不稳定训练问题的体现——没有冷启动数据提供的初始结构，强化学习会迅速走偏。研究团队特别说明，"不含监督微调"条件下报告的数字来自训练崩溃前的最后一个有效检查点。
冷启动数据集的规模对最终性能也有明确的影响。当监督微调只用二千五百条轨迹时，相比完全不做监督微调，所有数据集的性能都已经有显著提升；扩展到五千条和一万条时，性能继续提高，但边际收益递减，一万条时微平均分数大致趋于平稳。这说明哪怕只有相对少量的高质量示范数据，也足以让强化学习站稳脚跟。
七、深入观察：模型学到了什么样的搜索习惯
研究团队不仅关心最终成绩，也仔细分析了GrepSeek在实际搜索时的行为规律。
从命令风格来看，模型学会了几个固定的"搜索原语"：几乎每条命令都以| head -n结尾，限制输出行数，避免把过多无关内容送入上下文；几乎全部使用-F参数进行固定字符串匹配，而非正则表达式，避免意外的宽泛匹配；大约七成的命令是两段式管道过滤，即先用一个条件找到候选行，再用第二个条件进一步筛选。对于多跳问题，平均每个问题会执行二点六到三点四条命令；对于单跳问题，平均只需要二点零到二点四条。这说明模型能够感知问题的复杂程度，自适应地调整搜索深度。
从训练过程中的行为演变来看，研究团队发现监督微调阶段主要建立了低层次的句法习惯（管道深度、固定字符串匹配、截断模式），而强化学习阶段则重塑了高层次的策略。随着强化学习从第十步推进到第二百步，每条轨迹的平均命令数从三点○六条减少到二点五六条；每次截取的行数（head -n的参数）从约五行增加到约十行；推理文字的平均长度从四千二百五十一个词元增加到六千四百○九个词元。换句话说，模型学会了用更少但更精准的命令提取更多信息，同时把更多的"算力"花在推理上而非执行上。
这个演变过程也与查询数量的变化相呼应。研究对比显示，密集检索基线在训练过程中倾向于增加检索次数，而GrepSeek则在减少查询次数的同时，把每次查询变得更加精准和信息量更丰富。这就像一个侦探从"乱翻一气"进化成"精准突破"。
八、效率对比：GrepSeek的算力账单
在一个涉及三百五十个样本的效率测试集上，研究团队详细比对了GrepSeek与两个密集检索基线（E5和Qwen3嵌入）的资源消耗。
在推理延迟方面，GrepSeek每次问答平均需要八点六七秒，其中语言模型推理占七点八六秒，工具执行只占零点八一秒。相比之下，E5基线是四点七七秒，Qwen3嵌入基线是六点○七秒。GrepSeek的总延迟更高，主要原因是它的推理轨迹更长，需要更多轮次的生成。
在内存占用方面，GrepSeek只需要十四GB的宿主内存（等于语料库原始大小），而E5基线需要七十GB来存储向量索引，Qwen3嵌入基线则需要高达两百二十一GB。
在离线准备成本方面，GrepSeek几乎为零——加载语料库到内存大约需要一分钟。E5建索引需要三点二个A100 GPU小时，Qwen3嵌入建索引则需要六十二点四个A100 GPU小时。
这种权衡关系可以用一个直白的比喻来理解：GrepSeek就像一个不需要任何准备工作的人，直接拿手电筒去书库里找书，找书过程本身慢一点；密集检索系统则像花了大量时间和金钱把所有书的关键词都印在一张超大的索引卡上，之后每次查找都又快又省力，但前期投入不菲，而且索引卡本身也要占大量空间。
归根结底，GrepSeek用每次查询时稍多一些的时间，换来了几乎为零的前期准备成本和极低的存储压力。对于那些语料库会频繁更新、或者没有条件维护大型向量数据库的场景，这是一个非常有吸引力的trade-off。
同时，这项研究也坦诚地指出了自身的边界。纯词汇匹配对于含有大量变体写法、外来语拼写或变音符号的实体查询比较脆弱。由于Shell命令按文件顺序返回结果，当一个关键词在语料库里出现成千上万次时，最权威的文档可能被大量不相关的段落掩盖，这是没有语义相关性排序的固有局限。研究团队在论文的未来工作部分指出，他们计划探索模糊匹配和更高级正则表达式来缓解拼写变体的问题，以及混合检索架构来结合索引检索和直接语料库交互的优势。
对于任何对构建问答系统、信息检索工具或知识密集型AI应用感兴趣的读者而言，这项研究提供了一个很有价值的视角：不是所有场景都需要最昂贵的索引方案，有时候一把精准的"手电筒"加上一个训练有素的侦探，就足以打败那套耗资巨大的档案管理系统。完整的代码、训练数据和模型权重已经在论文对应的GitHub仓库（github.com/alirezasalemi7/grepseek）中开源，有兴趣的读者可以直接上手体验或进行二次研究。
Q&A
Q1：GrepSeek和普通的RAG检索增强系统有什么核心区别？
A：普通RAG系统需要先把所有文档变成数字向量，建立索引，查询时找向量最近的文档。GrepSeek完全跳过这一步，直接在原始文本文件上执行Shell命令（比如grep、rg）来搜索，就像用手电筒直接在书堆里找字，不需要提前整理任何索引。这样前期几乎不需要准备时间和存储，但每次查询时稍慢一些。
Q2：GrepSeek的两阶段训练具体是怎么做的？
A：第一阶段用一万条高质量示范轨迹做监督微调，这些轨迹由一个"知道答案的导师"和一个"不知道答案的规划师"协同生成，确保训练数据不存在信息泄露。第二阶段用GRPO强化学习，每个问题同时生成五条轨迹，让模型向得分更高的方向更新，逐步学会更高效的多步搜索策略。
Q3：GrepSeek在哪些问题类型上表现最好，哪些情况下会出错？
A：GrepSeek在需要精确匹配实体名称、多跳推理（先找A再找B）和过滤特定符号（如化学分子式）的问题上表现突出。在涉及带变音符号的外语名称（如法语"Edouard"）、或者目标词汇极其常见导致结果顺序靠后时，纯词汇匹配会出现失误，这种情况下密集检索系统反而更健壮。