Drex for Search 深度：6 基准省 62% 步数，搜索前先决策

一句话结论：Drex for Search 把检索从切块加嵌入换成了先决策再读取，在 6 组真实专业工作基准的 529 道题上让编码智能体少走 62% 的步数、少用 56% 的输入 token，准确率从 63.1% 升到 67.1%，中位耗时从 80.8 秒压到 35.5 秒。

2026 年 10 月 26 日，美国帕洛阿尔托的 Nace.AI 正式发布 Drex for Search，把此前只用在决策场景的 Drex 模型接到智能体检索这条通路上。产品的思路一句话就能说清：智能体在读任何东西之前，先由模型判断答案可能在哪一页，读的页少了，读错的机会也跟着少。

这篇按官方公布的数据逐项拆开，包括十组智能体与模型的完整对照表、四个公开榜单的位置，以及这条路线的边界。

为什么智能体搜索会绕圈

Nace 对传统检索的概括是三步流水线：切块、嵌入、取 top-k，然后碰运气。这条流水线会在三种情况下断掉。

第一种，答案藏在文件第 23 页的一张表格里，切块会把表格切碎，语义检索捞回来的片段对不上。第二种，答案需要跨文件两跳才能拼出来，嵌入相似度给出的候选集里往往没有能完成拼接的那一份。第三种，答案在一份扫描版 PDF 里，压根没有可嵌入的文本层。

关键词搜索的问题不同，BM25 这类方法能定位到词，找不到意思。语义检索能找到意思相近的文本，但不知道哪一份文档才是对的，而且同样会把表格切碎。两种机制叠加起来，智能体的行为就变成了人的翻找式搜索：搜一次，开一个文件，读几页，再搜一次。Nace 引用的是真实工作文件夹里的数字，这种循环往往要走二十到三十步，而智能体读到的每一页都是要付费的 token。

更麻烦的是每多读一页，就多一次被错误数字带偏的机会。这解释了为什么省步数这件事在智能体场景里比省单价更重要。

三步决策：Classify、Squeeze、Answer

Drex for Search 的做法是把搜索质量的大头挪到搜索动作之前。

Classify 这一步让 Drex 读问题，判断它是哪一类。在任何检索开始之前，它先决定这是一次快速查找，还是一个需要智能体读文档并查询表格的问题。

Squeeze 是逐层收窄工作空间。层级是固定的，从文件夹到文件，到章节，到页，再进到表格里的表和列。每一层只保留还有可能装下答案的部分。关键在深度固定，一百万份文件和一千份文件走的步数一样多。

Answer 阶段只有被保留的页和表会送进大模型，返回的答案同时带着文件和页码出处。

官方给了一个具体的例子来解释中间这步。问题写成哪几个超过 5 万美元的季度日记账缺少第二审批人，Drex 会把它标记为表格类问题，直接走向总账而不是旁边那份合同和演示稿，然后把范围缩到相关的行和审批人列上，智能体根本不需要读剩下的部分。

这也解释了它和 RAG 的关系。Drex 没有抛弃 BM25 或 RAG，它做的是给它们指路，让大模型读得更少、漏得更少。官方文档里那张演进图把这条线列得很清楚：精确匹配找字符串，关键字找词，BM25 给词打分，嵌入与 RAG 找相似语义，Drex 做的是在智能体读第一页之前先判断答案可能在哪。

六组基准 529 道题的整体成绩

官方测的是六组真实专业工作材料，总计 529 道题，材料类型分别是 Databricks 的 OfficeQA、年度与季度报告、审计工作底稿、总账与试算平衡表、发票与账单文件、应收应付文件。测试方式是同一个编码智能体跑两遍，一遍用它出厂自带的搜索工具，一遍换成 Drex for Search 作为检索后端。

整体结果四个数字：准确率从 63.1% 升到 67.1%，提升 4 个百分点；步数减少 62%；输入 token 减少 56%；中位每题耗时从 80.8 秒降到 35.5 秒，快 2.3 倍。

耗时这一项官方按智能体分别列了数字，降幅差异很大。Codex 从 67.4 秒降到 19.9 秒，降 70.5%；pi 从 92.9 秒降到 37.7 秒，降 59.5%；Hermes Agent 从 82.2 秒降到 48.9 秒，降 40.5%。三个智能体的平均是 80.8 秒到 35.5 秒，降 56.8%。这个差异提示了一件事，原始搜索能力已经很强的智能体，从决策式检索里拿到的收益更大，因为它们原本就有更多轮次可以浪费。

十组智能体与模型的逐行对照

更细的一层是 OfficeQA Pro，这是 Databricks 的一个基准，133 道题覆盖 697 份扫描版 PDF。Nace 跑了十组智能体与模型的组合，每组先按出厂设置答一遍，用基准自带的解析文本，再把同样的原始 PDF 放进一个 Drex for Search 工作区，智能体只能通过 Nace CLI 访问。智能体、模型、推理档位、题目和沙箱全部保持不变。

官方给的汇总是每题输入 token 减少 57%，步数减少 53%，平均准确率从 59.3% 升到 61.9%，提升 2.6 个百分点。十组里全部步数更少、token 更少，十组里八组答对更多题。两组准确率下降，Codex 配 GPT-6 luna 从 54.9% 降到 53.4%，Claude Code 配 Sonnet 5.5 从 69.2% 降到 66.9%。

官方对读法给了两个提示。第一，出厂设置的结果是 2026 年 10 月 20 日到 22 日两次运行的平均值，Drex for Search 的结果只有 10 月 24 日到 25 日的一次运行，所以准确率要按正负 2 个百分点来读。第二，输入 token 是智能体模型自己的消耗，包含缓存读取，Drex 自己的决策开销不计入。

token 降幅最大的是 pi 配 Opus 5.5 这一组，19.1 万降到 7.2 万。轮次降幅最大的是 Hermes 配 Qwen3.8-27B，20.1 轮降到 6.5 轮，超过三分之二的轮次被省掉。

四个公开榜单的位置

Nace 还参加了四个公开的文档检索榜单，成绩按 2026 年 10 月 20 日公布的排名给出，包括没有拿到第一的那些。

BrowseComp-Plus 这一行值得单独说一句。第 2 名的分数是 92.05%，官方给出的差异是调用次数少 16.6 倍。这里的口径是每道题平均调用 12.6 次搜索。对照站内此前记录的 AKV 缓存工程里 100 道 BrowseComp-Plus 任务的实验设置，可以看到这个基准已经被反复用于衡量智能体的检索与上下文开销。调用次数这个指标在成本上的影响往往比分数更直接，因为每一次调用背后都跟着一次模型推理。

产品形态与部署边界

Drex for Search 已全面可用，接入方式是 CLI、Python 与 TypeScript SDK、MCP 服务和 REST API，一个 Console 密钥打通所有。命令行下的完整流程是创建工作区、上传目录并执行摄取，然后直接提问。官方示例里问的是年末总负债，答案是 4820 万美元，出处标注为 fy25-10k.pdf 第 41 页。

它能读的内容类型包括 PDF 与扫描件、表格与 Parquet、Office 文件、JSON、音频和视频。表格保持表格形态，所以答案可以指到具体的行与单元格，录音可以指到具体分钟。

数据隔离的做法是每个工作区一份独立索引，只由该工作区的文件构建，上传什么就检索什么，内容不用于训练、调优或评测共享模型。数据不能出内网时，可以跑在自己的云或数据中心里。

官方给出的产品页数字是单次决策 200 毫秒以内，搜索层支持 100 万份以上文件，决策与解析在公开榜单上排名第一。接入形态上，Claude Code、Codex、Cursor、OpenCode 以及任何能执行命令或调用 MCP 工具的智能体都能直接用。

这条路线的局限

看数据要同时看它的边界，有三处值得留意。

第一，十组里两组准确率是下降的。Codex 配 GPT-6 luna 降 1.5 个百分点，Claude Code 配 Sonnet 5.5 降 2.3 个百分点。两次运行与一次运行的差距，以及官方自己提示的正负 2 个百分点误差，都说明这些下降未必是显著退化，但也说明这不是一个在所有组合上都稳定增益的方法。

第二，OfficeQA Pro 那张表的增益幅度明显小于 529 道题的总体数字。总体是 4.0 个百分点，OfficeQA Pro 是 2.6 个百分点。扫描版 PDF 与结构化表格这一类场景上，决策式检索的帮助没有在混合材料上那么大。

第三，成本口径要看清。省下的 56% 是智能体模型的输入 token，Drex 自己的决策开销官方明确不计入。决策模型本身要读问题、逐层收窄，这部分成本在总账上另有位置。对于原本搜索能力就强、轮次就少的智能体组合，绝对收益也会更小。

这条路线与站内记录过的其他几条并不冲突。Exa 3.0 搜索 API走的是把检索质量做成可量化商品的价格战路线，Cohere Rerank 5用重排模型省掉 35% token，Drex for Search 则把打分从召回后的重排挪到了检索之前的决策阶段。而 Keln 网关基准实测的 93.9% 缓存命中率解决的是另一层问题，它优化的是请求在网关处的复用，检索质量本身仍然取决于后端。

小结

Drex for Search 的核心主张是检索质量的大部分在检索之前就已经决定。这句话在传统搜索时代听起来平淡，因为那时搜索就是检索本身。到了智能体时代，检索变成了智能体行为的一部分，翻找的成本被放大成几十轮推理和几十万 token 之后，把决策提前的价值就显出来了。

529 道题上 62% 步数降幅与 56% token 降幅是这个主张目前最扎实的证据。十组对照表里的细节同样值得读，尤其是两组准确率下降的组合，那是这套方法现在的真实边界。

常见问题

Drex for Search 和普通 RAG 到底差在哪？

RAG 是切块、嵌入、取 top-k 之后把召回片段交给大模型，Drex for Search 是先由决策模型把问题分类，再逐层把工作空间收窄到具体的文件、页、表和列，只有被保留的部分进入大模型。官方给的类比是，Drex 不扔掉 BM25 和 RAG，而是告诉它们该往哪看。

接入之后智能体的准确率一定提升吗？

不一定。529 道题的总体准确率提升 4 个百分点，但 OfficeQA Pro 的十组组合里有两组下降，Codex 配 GPT-6 luna 从 54.9% 降到 53.4%，Claude Code 配 Sonnet 5.5 从 69.2% 降到 66.9%。步数与 token 的下降在十组里是一致的，准确率提升则不是。

文件数量多会不会让搜索变慢？

官方说明层级是固定的，一百万份文件和一千份文件走同样多的步数，因为收窄在每一层只保留还有可能装下答案的部分。深度固定意味着时间不随文件量增长，前提是每一层的分类判断准确率够高，官方给出的单次决策时间在 200 毫秒以内。

相关阅读

• Exa 3.0 搜索 API 上线：击败 Perplexity 等 8 项基准
• Cohere Rerank 5：BRIGHT 82.2 分，token 省 35%
• Keln 网关基准实测，缓存命中 93.9%，四家 AI 网关跑 3360 轮
• 微软开源 Agensh：1024 智能体协同，通过率 55.06%
• Cloudflare 发布 Clairic：文档提取 AI 让代理链路快 3 倍、成本降一半
• AKV 缓存工程开源：智能体成本降 27.7%，分数升 1.7 分