Anthropic：从RAG到智能体搜索

AI模型价格对比 | AI工具导航 | ONNX模型库 | Vibe Coding教程 | PLC在线仿真器 | Tripo 3D | Meshy AI | ElevenLabs | KlingAI | ArtSpace | Phot.AI | InVideo

Anthropic 为 Claude Code 构建了一个 RAG 管道。嵌入、向量数据库、分块检索。标准做法。然后他们在此基础上测试了智能体搜索。grep、glob、文件读取、迭代优化。没有嵌入。没有预处理。只是模型像开发者一样搜索文件。

根据 Claude Code 的创建者 Boris Cherny 的说法，智能体方法"击败了所有方案。而且远远超越。"

他们完全用智能体搜索替换了传统的 RAG 管道。

这一说法出现在一个已经在争论 RAG 是被取代还是只是被改进的社区中。反应可以预见地分成了两派。RAG 的支持者指出了边缘情况。智能体搜索的倡导者宣布胜利。

本文为这场讨论增加了数据。我们在本地 Apple Silicon 硬件上，对同一文档集、同一模型运行了 42 项结构化测试，比较 RAG 和智能体搜索。

关于范围的说明。测试语料库包括四个公开文档集和六种问题类型。这足以识别清晰的模式，但不是涵盖每种文档类型和查询类别的综合基准。本文报告的模式在该范围内是一致的且可复现的。不同的语料库或不同的问题类型可能会改变数据。

在该范围内，结果与 Anthropic 的发现一致。结果还揭示了智能体搜索的性能很大程度上取决于驱动搜索的模型，而不仅仅是方法本身——这是 Anthropic 的公开报告中没有涉及的一个变量。

1、为什么你要在本地搜索自己的文档

在进行比较之前，值得解释一下为什么有人要这样做。

敏感文档。 法律合同、医疗记录、财务数据、人事文件。你不能将这些内容发送到云端 API 而不承担合规风险。本地文档搜索意味着数据永远不会离开你的机器。2026 年 2 月，这一担忧变得更加具体，当时联邦法院在 United States v. Heppner 案中裁定，使用商业 AI 平台创建的文档不受律师-客户特权保护，在诉讼中可以被发现。法院认定，与第三方 AI 工具共享信息会破坏保密性。你在云端 AI 平台上输入的任何内容都可能成为潜在的证据链。在本地运行文档搜索可以完全避免这种风险。

成本。 云端 RAG 管道按嵌入、查询和上下文 token 收费。在硬件投资之后，在本地运行相同的工作流不需要任何费用。

可用性。 没有 API 依赖意味着没有停机、没有速率限制、没有弃用通知。你的文档搜索可以离线工作、在飞机上、在互联网中断时。

所有权。 你的文档留在你的文件系统中。任何地方都不存在你的内容的第三方索引。没有需要删除的东西，没有需要请求移除的东西，没有可能在数据泄露中暴露的东西。

问题不在于是否要在本地搜索。而在于如何搜索。两种主要方法看起来截然不同。

2、RAG 是什么

检索增强生成（Retrieval Augmented Generation）自 2023 年以来一直是使用 LLM 进行文档搜索的默认方法。可以把它想象成为教科书建立索引。你预处理内容以便系统可以快速查找，但你只限于索引返回的内容。管道分两个阶段工作。

首先，你预处理你的文档。将它们分成块，使用嵌入模型将每个块转换为数值向量，并将这些向量存储在 ChromaDB 或 FAISS 等数据库中。

当问题到达时，管道使用相同的嵌入模型将其转换为向量，在数据库中搜索最相似的块（通常是前 5 个），并将这些块与问题一起作为上下文传递给 LLM。模型基于检索到的内容生成答案。

这种方法的优点是语义理解。嵌入模型可以弥合词汇差距。如果你问"减少内存占用"而文档使用"量化技术"这个短语，一个好的嵌入模型能识别出概念上的重叠并检索到正确的块。

缺点是结构性的。你只有一次检索机会。系统返回按相似度排名的固定数量的块，模型必须使用它收到的任何内容。没有机制可以说"这些块没有帮助，让我尝试不同的搜索。"

3、智能体搜索是什么

智能体搜索采用了一种根本不同的方法。你不是将文档预处理成可搜索的索引，而是让模型访问文件系统工具并让它迭代搜索。

模型读取问题，决定搜索什么，运行命令（grep、find、ls），查看结果，然后决定下一步做什么。它可能会读取一个文件，搜索不同的术语，浏览一个目录，或者根据发现的内容优化其方法。当它收集了足够的信息时，它生成一个答案。

这就是人类开发者在不熟悉的文档中搜索的方式。从一个关键词开始，扫描结果，打开一个有希望的文件，阅读它，意识到答案实际上在不同的部分，去找那个部分，迭代地建立理解。

优点是适应性。如果第一次搜索没有找到正确的内容，智能体可以尝试不同的方法。它可以按顺序浏览多个文档集。它可以跟踪文件之间的交叉引用。

缺点，至少在理论上，是成本。每次搜索迭代都会消耗 token。在云基础设施上，这些 token 要花钱。在本地硬件上，它们消耗时间但不花钱。

4、Anthropic 发现了什么

Anthropic 的 Claude Code 创建者和负责人 Boris Cherny 直接描述了这个转变："早期版本的 Claude Code 使用 RAG + 本地向量数据库，但我们很快发现智能体搜索通常效果更好。它也更简单，而且在安全性、隐私、数据时效性和可靠性方面没有相同的问题。"

在 Latent Space 播客的另一次对话中，他补充说智能体搜索"击败了所有方案。而且远远超越。"

简而言之，Anthropic 发现智能体搜索更准确、操作更简单，并且避免了维护本地向量数据库和嵌入索引所带来的安全性、隐私、时效性和可靠性问题。

这些发现来自一个在云基础设施上运行前沿模型（Claude）的团队。本系列一直要回答的问题是，当经济模型完全不同时，在本地硬件和本地模型上，相同的结果是否成立。

5、我们如何测试

测试语料库包括四个公开文档集，任何读者都可以下载并用来复现实验。MLX 文档（56 个文件）、OpenClaw 文档（仅英文版，移除翻译文件后）、HuggingFace Transformers 文档（最大的集合，数百个文件，涵盖模型、管道、分词器、训练和量化），以及 Sentence-Transformers 文档。

这些集合加在一起提供了体量、多样性以及主题之间的自然重叠。所有四个项目都讨论模型、量化和推理。每个事实都可以公开验证。任何读者都可以下载相同的文档并运行相同的测试。

RAG 管道使用 ChromaDB 进行向量存储，Qwen3-Embedding-0.6B 进行嵌入（测试时 MTEB 基准上排名最高的开源权重嵌入系列），512 token 的块和 50 token 的重叠，余弦相似度，以及 top-5 检索。这是一个合格的、现代的 RAG 设置。如果智能体搜索超越了它，那不是因为我们限制了 RAG。重排序、查询分解和来源多样性约束等高级技术可以提高 RAG 在其表现不佳的测试中的性能。将这些优化与智能体搜索进行测试将是一项有价值的后续研究，但那是本文要回答的不同问题。

智能体搜索设置仅使用文件系统工具。ls、find、grep、cat、head。没有嵌入。没有向量数据库。没有预处理。

每个测试都比较了三种方法。 原计划是两种（RAG vs. 智能体搜索），但一个实际约束迫使出现了第三种，而这第三种方法揭示了本研究中最重要的发现。

问题是公平性。执行测试的 OpenClaw 智能体运行在 Claude Sonnet 上，这是一个前沿云模型。如果在智能体测试中 Sonnet 同时处理搜索和回答，而在 RAG 测试中由本地模型处理回答，那么比较就不公平了。我们测试的是 Sonnet 的智能与 Mistral-Small 的智能，而不是 RAG 与智能体搜索。

为了解决这个问题，我们将智能体方法分为两个层次。可以把它想象成在图书馆做研究。在每种方法中，同一个人（本地模型）阅读内容并撰写报告。唯一的区别是谁找到了这些书。在方法 B 中，一位专家图书管理员（Sonnet）找到了正确的文档，然后交给你的本地模型来阅读和回答。在方法 C 中，你的本地模型自己找书并撰写报告。通过在两种情况下保持读者和作者相同，我们可以看到是找到正确的内容还是理解内容才是真正的差距所在。

方法 A 是 RAG。嵌入管道检索块，一个本地模型（通过 MLX 在 Apple Silicon 上运行）从这些块生成答案。

方法 B 是云辅助智能体搜索。Sonnet 搜索文件系统，决定 grep 什么、读取哪些文件以及何时优化策略。然后它将收集到的文件交给 RAG 使用的同一个本地模型来生成答案。这是我们专门为本地硬件设计的混合方案。你的文档保持在本地。答案生成是免费的。Sonnet 看到文件列表和搜索结果，但实际的文档内容由本地模型读取和处理。

方法 C 是完全本地智能体搜索。一个本地模型控制整个过程。它决定搜索什么，执行搜索，读取文件，优化方法，并生成答案。任何阶段都不涉及云模型。这是最接近 Anthropic 用 Claude Code 所做的方式——一个模型同时处理搜索和回答。唯一的区别是模型。Anthropic 运行 Claude。我们运行 Mistral-Small 和 Nemotron。

两种本地模型在所有三种方法中都进行了测试。 Mistral-Small-24B 和 NVIDIA Nemotron 3 Nano 30B。两者都通过 MLX 在配备 64GB 统一内存的 Mac Mini M4 Pro 上本地运行，与本系列之前所有基准测试一致。

所有测试都通过 OpenClaw 执行。 OpenClaw 管理会话，在智能体方法中执行文件系统搜索，运行 RAG 管道脚本，并将结果保存到磁盘。每个测试都从一个新的 OpenClaw 会话开始（使用 /reset），以防止测试之间上下文泄漏。之前遵循本系列设置指南的读者已经有了复现这些实验所需的基础设施。

六种问题类型旨在考验不同的优势。

测试 1，精确匹配。 一个具有明确可查找答案的具体事实问题。"通过 pip 安装 MLX 框架的 Python 命令是什么？"

测试 2，大海捞针。 一个深藏在文档中的具体技术参数。"Sentence-Transformers all-MiniLM-L6-v2 模型支持的最大序列长度是多少？"

测试 3，概念搜索。 一个需要弥合词汇差距的抽象查询。"哪些文档讨论了在推理过程中减少大语言模型内存占用的方法？"

测试 4，交叉引用。 一个需要来自两个不同文档集信息的比较。"MLX 中使用的量化方法与 HuggingFace Transformers 文档中描述的量化方法有何比较？"

测试 5，多文档综合。 一个需要来自三个文档集信息组合成连贯指南的任务。"创建一个分步指南，设置一个使用 OpenClaw 作为智能体、MLX 进行模型推理和 HuggingFace 模型的本地开发环境。"

测试 6，否定测试。 一个答案在语料库中不存在的问题，旨在测试每种方法是否会产生幻觉或正确报告信息不存在。"使用 MLX 在 Apple Silicon 上微调 Sentence-Transformers 模型的推荐设置是什么？"

六个问题中的每一个都在三种方法和两种模型上运行，加上在完全本地智能体方法上增加了第三个本地模型（Gemma 4）。总共 42 项测试。每个测试都从新会话开始，测试之间没有上下文泄漏。完整结果保存在磁盘上，包括智能体的完整搜索过程、每次工具调用、性能指标和观察结果。一个方法论说明。RAG 结果在给定相同索引的情况下是确定性的（相同查询总是检索到相同的块）。智能体搜索结果本质上是非确定性的，因为模型在不同运行中可能选择不同的搜索策略。我们报告的模式在运行的测试中是一致的，但个别结果在重复运行中可能会有所不同。

6、结果

下表总结了所有 42 项测试。准确度以 1-5 分评分（5 = 完美）。前 36 项测试用两种模型比较了三种方法。额外六项测试评估了 Gemma 4 在完全本地智能体搜索中的表现。详细发现如下。

42 项测试的准确度得分

按方法的性能表现（两种模型平均值）

在通过 MLX 运行的本地硬件上，无论数量多少，所有 token 都是免费的。来源多样性衡量的是当问题需要时，该方法是否从多个文档集中检索了内容。

6.1 所有方法平手的地方

测试 1（精确匹配）是全面胜利。每种方法、每个模型、每个配置都正确找到了 pip install mlx。RAG 以高相似度分数检索了安装文档。两种智能体方法都在 MLX 目录中 grep 了 "pip install" 并立即找到。对于简单的事实查找，方法并不重要。

测试 3（概念搜索）在各方面同样表现出色。所有方法都成功将"推理过程中减少内存占用"映射到量化文档、Flash Attention、架构优化和设备管理技术。RAG 实际上在这里表现优秀，因为 Qwen3 嵌入模型弥合了查询语言和文档技术术语之间的词汇差距。这正是嵌入发挥价值的地方。

测试 6（否定测试）确认了各方法的抗幻觉能力都很强。所有配置都正确识别了不存在使用 MLX 在 Apple Silicon 上微调 Sentence-Transformers 的文档。RAG 是最快、最干净的。智能体方法在验证方面更彻底（系统性地搜索两个框架以确认不存在），但得出了相同的结论。一个值得注意的例外是 Nemotron 在完全本地智能体测试中，它正确检测到信息不存在，但产生了一个格式错误的响应，其思考过程泄漏到了答案中。

6.2 RAG 失败的地方

测试 4（交叉引用）暴露了 RAG 的结构性限制。问题要求比较 MLX 的量化方法和 HuggingFace 的量化方法。这需要来自两个不同文档集的内容。

RAG 检索了五个块。全部五个都来自 HuggingFace Transformers。零 MLX 内容。嵌入模型将查询映射到"量化"并返回了最相似的块，它们碰巧都在 HuggingFace 量化目录中。模型没有 MLX 信息可以处理，只能报告缺少什么。

这不是嵌入模型的失败。相似度分数很高，检索到的块确实与量化相关。失败是结构性的。使用余弦相似度的 top-5 检索会聚集在最强的语义匹配周围。当问题跨越两个文档集时，检索会倾向于哪个集合在该主题上内容最集中。

测试 5（多文档综合）显示了相同的模式。问题需要来自三个框架（OpenClaw、MLX 和 HuggingFace）的安装命令。RAG 检索了大部分 OpenClaw 文档。MLX 安装内容完全不在检索到的块中。模型正确地拒绝从不完整的信息中编造指南，但用 RAG 提供的内容来完成综合任务是不可能的。

两种失败在 Mistral-Small 和 Nemotron 之间是完全相同的。检索到的块在两种情况下是相同的，因为嵌入层在模型之间不会改变。这确认了限制在于检索架构，而不是答案生成。

6.3 智能体搜索获胜的地方

云辅助智能体搜索（方法 B）解决了 RAG 无法解决的两个问题。这是我们专门为本地硬件设计的混合方案。Sonnet 处理文件系统搜索，决定 grep 什么、读取哪些文件以及何时优化策略。但收集到的文件交给在 Apple Silicon 上运行的本地模型进行答案生成。文档保持在本地。答案生成是免费的。Sonnet 看到文件列表和 grep 结果，但实际的文档内容由本地模型读取和处理。对于敏感工作来说，这是一个有意义的隐私区别。

在测试 4（交叉引用）中，智能体首先搜索 MLX 文档中的量化内容。当发现有限结果时，它搜索了 HuggingFace 量化目录并发现了大量文档。关键是，它随后找到了 HuggingFace Metal 量化文档，揭示了 HuggingFace 的 Metal 量化后端使用了源自 MLX 框架的内核。两个框架之间的这种联系对 RAG 是不可见的，因为它需要阅读一个文档集、学到一些东西，然后用新知识搜索另一个集合。

在测试 5（多文档综合）中，智能体系统地独立搜索了每个框架的安装文档。它从 MLX 文档中找到了 pip install mlx，从 OpenClaw 文档中找到了 curl 安装命令，从 OpenClaw-HuggingFace 集成文档中找到了 HuggingFace 提供程序设置。它将这些编译成一个 RAG 无法产生的连贯指南。

云辅助智能体搜索的平均准确度为 4.7 分（满分 5 分），而 RAG 为 3.2 分。当前沿模型驱动搜索时，即使在答案生成是本地的混合配置中，智能体搜索也 decisively 优于传统 RAG。

6.4 模型比方法更重要的地方

故事到这里变得比简单的"智能体搜索获胜"标题更有趣。

完全本地智能体搜索（方法 C），即一个本地 24B 模型控制整个搜索过程，平均得分为 3.2 分（满分 5 分）。与 RAG 相同。没有更好。不是 Anthropic 报告的那种决定性胜利。而这是最接近 Anthropic 所做的方式的方法。一个模型搜索、阅读、优化和回答。端到端。唯一的变量是模型本身。

云辅助智能体（4.7）和完全本地智能体（3.2）之间的差距是本研究最重要的发现。但理解这个差距代表什么至关重要。方法 B 和 C 使用相同的智能体搜索架构。相同的智能体循环。相同的文件系统工具。相同的脚本。唯一的区别是驱动搜索决策的模型。当 Sonnet 驱动搜索时，准确度跳升到 4.7。当本地 24B 模型驱动相同的搜索基础设施时，准确度降至 3.2。架构不是问题。本地模型的能力是瓶颈。Anthropic 的方法是有效的。它只需要一个足够强大的模型来驱动它。

这个区别很重要，因为它意味着方法 C 会随着本地模型的改进而改进。未来本地模型中多步推理、工具使用和搜索规划的每一次进步都会直接转化为更好的智能体搜索结果，而无需更改管道代码中的任何一行。基础设施已经准备好了。它在等待模型跟上。

具体的失败模式是搜索策略的僵化。在测试 2（大海捞针）中，问题要求特定模型的最大序列长度。Sonnet（在云辅助测试中）搜索了模型名称，找到了一般性引用，然后转向搜索 max\_seq\_length 作为参数名，然后找到了一个包含精确值的 HTML 模型规格表。当第一种方法没有找到答案时，它调整了搜索策略。

两个本地模型搜索了模型名称，找到了相同的一般性引用，并继续阅读提到该模型的文件，而没有转向直接搜索该参数。最终它们退回到从训练知识中回答（碰巧是正确的，但不是来自文档）。答案在技术上是正确的，但不是基于语料库的。

在测试 4 和 5 中，本地模型进行了系统性搜索，但无法发现 Sonnet 找到的非显而易见的联系。例如，MLX-HuggingFace Metal 量化链接需要在 HuggingFace 的集成文档中搜索提及 MLX 的内容。Sonnet 通过创造性的交叉引用找到了它。本地模型搜索了每个框架的文档，但没有想到去查看集成文档。

6.5 各方法内的模型差异

Nemotron 在所有方法的答案生成方面始终比 Mistral-Small 快 2 到 4 倍。这种速度优势是显著且一致的。

Nemotron 还表现出了更强的技术参数提取能力。在测试 2 中使用 RAG 时，Nemotron 在检索到的块中的代码示例中找到了 max_seq_length=256 值。Mistral-Small 查看相同的块却报告信息不存在。相同的数据，不同的提取能力。

然而，Nemotron 在多个测试中出现了响应格式问题。内部思考过程泄漏到了最终答案中。在阶段 8 的否定测试中，模型输出包含诸如"我们已经阅读了 install.rst 但没有看到微调设置。也许语料库中有一个关于微调的特定文档"之类的短语。这是使用内部思维链的推理导向模型的已知模式。使这些模型在多步任务中更强大的思维痕迹，如果模型没有干净地将推理与响应分离，就会泄漏到最终输出中。对于计划在面向用户的应用中部署这些模型的人来说，这是需要测试和监控的。

Mistral-Small 速度较慢但在响应格式方面更可靠。它从不泄漏思维痕迹，产生了更干净的否定响应，并以更专业的方式处理模糊情况。

7、这对本地硬件意味着什么

对智能体搜索的传统反对意见是 token 成本。每次搜索迭代都消耗 token。每次文件读取都会消耗上下文。在按 token 定价的云基础设施上，智能体搜索对于复杂查询可能很昂贵。

在通过 MLX 运行的本地硬件上，token 是免费的。模型使用电力和时间生成它们，但没有按 token 计费。在完全本地智能体方法上消耗 155,000 token 的测试（测试 4，Nemotron 跨 20 次迭代探索量化文档）除了五分钟的计算时间之外没有任何成本。

这改变了计算方式。问题不再是"智能体搜索值得 token 成本吗？"而是变成了"为了更好的结果，额外的等待时间是否可接受？"

对于云辅助方法（Sonnet 搜索，本地模型回答），搜索阶段仍然有云成本。但云基础设施上智能体搜索的昂贵部分（迭代多轮智能体对话）由 Sonnet 处理，而答案生成在本地免费进行。

对于完全本地方法，整个管道在你的硬件上运行。零云依赖。权衡是当前本地模型的搜索效果不如前沿模型。随着本地模型在多步推理和工具使用方面的改进，这个差距会缩小，但今天它是真实的。

还有一个更广泛的经济考虑。云 token 定价受到个人开发者和团队无法控制的市场力量的影响。过去两年价格有升有降，主要提供商之间的竞争动态、基础设施成本和商业模式转变未来可能推动价格向任何方向发展。无论云市场发生什么，本地推理的结构性成本固定为零 token。对于构建消耗大量 token 的工作流的团队（智能体搜索就是一个典型例子），本地硬件作为对冲定价不确定性的工具。

8、你实际上应该使用什么

正确的选择取决于对你来说最重要的是什么，而不是你要问的问题类型。

如果隐私是你的首要考虑，完全使用本地方案。 在你的硬件上完全运行智能体搜索管道。没有数据离开你的机器。没有云 API 能看到你的文档。它今天能很好地处理直接查询，随着本地模型的改进，它将更好地处理复杂查询。对于本系列的大多数读者来说，这是正确的起点。

如果复杂问题的准确性是你的首要考虑，使用云辅助混合方案。 让前沿模型处理搜索决策，而你的本地模型生成答案。你在不将文档内容发送到云的情况下获得最佳的搜索质量。权衡是搜索阶段有少量云成本。

如果速度是你的首要考虑，RAG 是最快的路径。 单个查询在几秒而非几分钟内返回结果。对于针对稳定文档集的快速事实查找，RAG 的简洁性是一个优势。

大多数人应该从完全本地智能体搜索开始，看看它能带他们走多远。它是完全私密的，驱动它的模型正在快速改进，而且设置要简单得多。

仅靠准确度数字无法捕捉的实际可及性优势。一个调优良好的 RAG 管道需要向量数据库、嵌入模型（可能针对你的领域词汇进行了微调）、分块策略（token 大小、重叠、文档边界处理）、文档更改时的索引维护，以及可选的重排序模型以提高检索质量。达到 RAG 的性能上限需要所有这些组件的专业知识。

智能体搜索这些都不需要。没有向量数据库。没有嵌入模型。没有分块策略。没有需要维护的索引。没有重排序管道。把你的文档放在一个目录中，让模型指向它，然后提问。对于宁愿将工程时间花在其他问题上的团队来说，这个差异与准确度数字一样重要。

9、Anthropic 正确的地方，以及他们遗漏的地方

我们的结果支持 Anthropic 的结论。在 RAG 结构性限制起作用的任务上，智能体搜索优于 RAG。来源聚集、跨文档综合、迭代优化。这些是真正的问题，也有真正的解决方案，智能体方法解决了它们。

Anthropic 没有涉及的是驱动搜索的模型的角色。他们的发现在 Claude（一个前沿模型）运行智能体循环时成立。当我们用本地 24B 模型测试时，相同架构的得分是 3.2 而不是 4.7。架构是合理的。脚本有效。智能体循环正常工作。但搜索策略适应性——当第一种方法失败时转向的能力——是在不同模型之间变化显著的能力。

自然的问题是这个差距是永久的还是更好的本地模型可以缩小它。

10、当我们测试一个更新的模型时发生了什么

在完成 36 项测试比较后，Google 发布了 Gemma 4。26B 混合专家变体在推理期间只激活 38 亿参数，在单个 GPU 上运行，并专门为带有原生函数调用支持的智能体工作流设计。它在 Arena AI 的文本排行榜上排名第 6，击败了比它大 20 倍的模型。MLX 支持在发布第一天就可用。

我们在相同的硬件和相同的文档语料库上，用 Gemma 4 运行了相同的六项完全本地智能体搜索测试。结果令人瞩目。

在测试 2（大海捞针）中，Gemma 4 做了 Mistral-Small 和 Nemotron 做不到的事情。它搜索了模型名称，阅读了几个文件没有找到特定参数，然后转向直接搜索 max\_seq\_length。当返回 22 个文件时，它有条不紊地逐一阅读，直到在自定义模型文档的代码示例中找到了精确值（256）。这就是我们识别为本地模型和前沿模型之间关键差异的搜索策略适应性。Gemma 4 展示了它。它得了 5/5 分，与 Sonnet 匹配。第一个在这个测试中成功的本地模型。

在测试 4（交叉引用）中，Gemma 4 找到了只有 Sonnet 在早期测试中发现的 MLX-HuggingFace Metal 量化联系。它搜索了两个框架的量化内容，阅读了 HuggingFace Metal 量化文档，并识别出 Metal 量化后端使用源自 MLX 框架的内核。它编译了一份具有具体实现细节的技术比较。它得了 4/5 分，与 Sonnet 匹配。第一个在这个测试中成功的本地模型。

在测试 5（多文档综合）中，Gemma 4 是第一个成功找到所有三个框架（OpenClaw、MLX 和 HuggingFace）安装文档的本地模型。之前的本地模型只找到了三个中的两个。然而，答案在生成过程中被截断了，留下了不完整的指南。它得了 3/5 分，比之前本地模型的 2/5 分有所提升，但仍低于 Sonnet 的 4/5 分。

在测试 6（否定测试）中，Gemma 4 完全失败了。它运行了 20 次迭代，执行了 31 条搜索命令，消耗了 93,941 个 token，但从未得出信息不存在的结论。它一直在搜索文档中不存在的 Sentence-Transformers 和 MLX 之间的联系，尝试越来越有创意的搜索术语，却从未后退一步说"这个不存在"。

这就是坚持-瘫痪的权衡。正是使得测试 2 和测试 4 取得突破的坚持（继续搜索，尝试不同的术语，不放弃）导致了测试 6 的完全失败（永远搜索下去，从不接受不存在）。最擅长找到存在的东西的模型，最不擅长接受某个东西不存在。

Gemma 4 的总体平均分是 3.8 分（满分 5 分），相比之下 Mistral-Small 为 3.3 分，Nemotron 为 3.0 分，云辅助 Sonnet 为 4.7 分。本地和前沿智能体搜索之间的差距从 1.5 分缩小到 0.9 分。在信息存在且可找到的四个测试中（测试 1-4），Gemma 4 得了 4.75 分（满分 5 分），几乎与 Sonnet 的性能匹配。剩余的差距完全在于综合（截断）和否定验证（坚持-瘫痪）。

一个额外的观察。Gemma 4 在所有六个测试中都产生了干净、专业格式的响应，没有思维痕迹泄漏。这是 Nemotron 的一贯问题，也是早期结果中标记的部署关注点。Gemma 4 完全解决了这个问题。

11、下一步

本研究中的 42 项测试探索了两个变量。搜索方法（RAG vs. 智能体）和模型能力（前沿 vs. 本地）。Gemma 4 的结果表明，更好的本地模型缩小了与前沿智能体搜索大约一半的差距。剩余的差距在于综合（模型的输出被截断）和否定验证（坚持变成了瘫痪）。

我们还没有测试第三个变量。被搜索文档的质量。Andrej Karpathy 最近描述了一种方法，LLM 将原始文档预编译成结构化的 wiki，包含摘要、索引文件、反向链接和分类文章。智能体不再搜索原始文件（智能体搜索）或将它们分块到向量数据库（RAG），而是搜索一个已经内置了导航结构的 LLM 策划的知识库。这从完全不同的方向解决问题。不是让模型更擅长搜索，而是让文档更容易搜索。

我们将在相同的语料库和相同的六个问题上测试这种方法。实验包括一个反馈循环阶段，查询输出被归档回 wiki 以衡量知识库是否会随着使用而改进。如果更好的文档结构能弥合 Gemma 4 留下的剩余差距，那么一个强大的本地模型和一个结构良好的知识库的组合可能完全在本地硬件上匹配前沿智能体搜索。

原文链接: Anthropic Replaced Their RAG Pipeline with Agentic Search. We Tested Both on Local Hardware.

汇智网翻译整理，转载请标明出处