站点图标 高效码农

代码检索速度提升4倍，还能达到Claude级精度？Relace AI新架构FAS深度拆解

高效码农

摘要：Relace AI最新发布的Fast Agentic Search（简称FAS）是一个专为代码库搜索任务训练的小型智能体模型。通过并行工具调用+专属强化学习，FAS在保持与传统Agentic Search同等精度的同时，将搜索速度提升了4倍。在SWE-bench实测中，集成FAS后编码智能体的中位延迟降低9.3%，Token消耗减少13.6%。

你有没有遇到过这种情况：
让AI帮你改一个中等规模的项目功能，它却花了整整2分钟在“找代码”？
明明代码库就几千个文件，它却像个新手实习生一样，一个文件一个文件翻，翻错了再回来道歉，再翻……
这其实是目前所有编码大模型的通病：60%的Token都浪费在了“找代码”这件事上。

Relace AI直接把这个最耗时的环节单独拎出来，用一个专门的小模型把它干到极致。这就是今天要聊的Fast Agentic Search（FAS）。

为什么传统的代码搜索总是又慢又不准？

先说大家最常用的两种方案：

  1. RAG（检索增强生成）
    优点：快，几百毫秒就能返回结果，成本也低。
    缺点：它本质上是“向量相似度匹配”，碰到复杂的业务逻辑、跨文件调用、间接依赖时，经常抓瞎。你会发现它漏了一堆关键文件，或者把完全不相关的文件排到前面。

  2. Agentic Search（智能体式搜索）
    优点：准得离谱。模型会像人一样思考 → 查看文件 → 跳转定义 → 再看调用方，一步步推理，最后几乎100%能找到你要的东西。
    缺点：慢到让人抓狂。因为它基本上是“串行”操作：
    思考3秒 → 调用一次工具查看一个文件 → 网络延迟1秒 → 再思考3秒 → 再看下一个……
    平均找一个功能要10-20轮，动不动就要30-60秒，Token也烧得飞起。

有没有可能既要Agentic Search的精度，又要RAG的速度？
Relace AI说：有，他们把这个方案叫FAS（Fast Agentic Search）。

FAS到底快在哪儿？三个核心技术一次讲透

1. 并行工具调用：一次看4-12个文件

传统编码智能体一次只能调用一个工具，比如只能“view src/utils/helper.py”。
FAS直接训练模型训练成“一次可以同时发出多个指令”。
举个实际例子：

用户问：“这个项目里哪里处理了用户登录后的权限校验？”

传统智能体会：

  1. 先grep “permission” 或 “auth”
  2. 看一个文件，发现不对
  3. 再看另一个……

FAS会直接并行发出：

  • •
    grep -r “permission” src/
  • •
    grep -r “rbac” src/
  • •
    grep -r “can_” src/
  • •
    view src/middleware/auth.py
  • •
    view src/services/user.py
  • •
    view src/controllers/*.py 中所有带 permission 的

相当于把原来要10次串行调用，压成1-2轮并行完成。网络延迟直接从10秒量级降到2秒以内。

2. 专属强化学习：让模型自己学会“又快又准”

很多人以为他们只是做了普通微调，其实核心是On-Policy强化学习。

他们专门设计了一个奖励函数，包含两部分：

  • •
    正向奖励：找到的所有相关文件越多越好（高召回+高精度）
  • •
    负向惩罚：搜索轮数越多扣得越狠（鼓励少步到位）

训练到后期，模型自己涌现出了一个现象：
模型不会一上来就盲目并行12个文件，而是会先安静地思考1-2秒，写一段推理，然后再有针对性地并行查看最可疑的6-8个文件。

这说明什么？这不是暴力枚举，而是真正具备了规划能力。

3. 子智能体架构：把“找代码”彻底从主模型剥离

真实编程任务里，60%的Token消耗都发生在“找代码”阶段。

传统做法：主模型（比如Claude 3.5、GPT-4o）既要推理业务，又要不停调用工具找文件，上下文窗口被大量无关代码塞满，成本高得离谱。

FAS的做法很简单粗暴：
把“搜索”这个子任务彻底剥离，交给一个专门的小模型（FAS）去干。

流程变成：
用户提问 → 主模型只需一句话总结“需要哪些功能的代码” → FAS接手并行疯狂找代码 → 把最相关的5-10个文件直接塞给主模型 → 主模型直接写代码

主模型省下了60%的Token，上下文也干净得多，自然更快更准。

实测数据：4倍速度不是吹的

官方数据如下：

  • •
    同等精度下，FAS比传统串行Agentic Search快4倍
  • •
    集成到完整编码智能体后（SWE-bench Verified数据集）：
    • •
      中位延迟降低9.3%
    • •
      Token消耗降低13.6%

注意：这还是在SWE-bench这种“任务定义非常明确”的基准上测的。
真实企业代码库往往更复杂、文档更少、命名更乱，搜索占比更高，实际提升会远超这个数字。

常见问题解答（FAQ）

Q1：FAS模型多大？能自己部署吗？
目前官方没有公布参数量，只说是“小型智能体模型”。从速度和成本来看，推测在7B-34B之间，暂时只以API形式提供。

Q2：它只支持grep和view吗？
不止。支持所有常见的代码库工具：grep、rg、find、ast-grep、tree、git grep、view、jump_to_definition等，可根据项目自定义工具集。

Q3：对私有代码库安全吗？
代码不离开你的环境。FAS可以完全本地部署，也可以走加密通道调用Relace的云端推理，类似Claude的“企业版”模式。

Q4：我现在的编码助手能直接用吗？
如果你用的是Aider、Cursor、Continue.dev、Sweep等开源工具，很多已经开始接入FAS或者类似并行搜索模块。官方也提供了OpenAI兼容的API，换个base_url就能用。

Q5：为什么不直接用大模型并行调用工具？
大模型也可以并行，但它们没有经过针对性的强化学习奖励“少步到位”。结果就是虽然并行了，却并行了一堆无关文件，反而更浪费时间和钱。FAS是专门为“代码搜索”这一个场景把并行策略训练到极致的。

写在最后：AI编程助手真正的瓶颈已经被找到

过去两年，大家都在堆参数、堆上下文、堆推理算力，但实际体验提升有限。
Relace AI这篇论文（虽然他们叫博客）其实点破了一个真相：

在真实软件工程场景中，决定AI编程助手体验的，早就不是模型本身的智能程度，而是它能不能又快又准地找到代码。

当“找代码”这个环节被一个小模型做到4倍速、同样精度时，整个编码智能体的体验就彻底变了。

这不是一个简单的功能更新，而是AI Agent架构演进的一个标志性信号：
未来的超级AI助手，不会再是一个巨无霸大模型包打天下，而是由一群极致优化过的专家子模型协作完成。

搜索子模型（FAS）、规划子模型、代码生成子模型、测试子模型……各自把一个环节干到极致，再组合起来。

今天你看到的4倍速度，只是起点。

（全文完）

退出移动版