RAG 技术选型：文件搜索 vs 向量搜索的 5 万文档实测

文件驱动的上下文管理在最近几天引起了关注，特别是自从 Claude CoWork 推出以来。这让我产生了好奇，我尝试了一些东西。

我在 5 个不同的领域进行了实验：从 Python 代码到科学论文。我从热门数据集中摄取了 50,000 份文档，并针对它们发起了 5,000 次查询。

目标是什么？找出关于基于文件搜索的所有讨论背后的真相。以及它是否真的有效！

我开始这项实验时预期向量搜索会全面压倒基准测试。我已经准备好写另一篇关于为什么一切都需要成为嵌入的文章。但在凌晨 2 点，看着我的 MacBook Pro 像核电站一样发热，我意识到我们被灌输了一个"语义梦想"，它并不总是符合工程现实。

这两个系统实际上做什么

在看数字之前，有个关键区别可以解释所有结果。

关键词搜索（本例中是 Tantivy）构建了一个反向索引，精确匹配术语。它没有语义模型。如果查询说"sort a list"，而文档说"bubble_sort"，关键词搜索找不到任何东西，因为这些是不同的字符串。它有的是精度，因为当查询中的术语与文档中的术语相同时，匹配是精确的，没有其他东西能超越它。

向量搜索（本例中是 ChromaDB）将文本转换为数值表示，并找到其表示相近的文档。它有一个大致的语义模型，但没有精确性的概念。它会将"sort a list"与"bubble_sort"联系起来，当你问关于"mitochondria"时，它也会同样高兴地返回关于细胞结构的文档，因为这两者在同一空间中彼此接近。

精确匹配和近似语义不是同一思想的两种实现。它们是两种不同的能力，下面的基准是一张地图，显示你在哪里需要哪一个。

我们使用 MRR@10 进行测量，该指标评估正确文档在前十个结果中的排名高度。分数 1.0 意味着正确的文档每次都排在首位。

自然语言到代码

维基百科问答

科学考试问题

平均值（不含 CodeXGLUE）

一起读最后两行，因为这就是全部结果。在五个数据集中，向量搜索大约领先 10 个 MRR 分数，这是会出现在幻灯片上的数字。移除 CodeXGLUE 后，排名反转，精确匹配关键词搜索领先 3 个分数。

向量搜索在检索中并不是普遍更好的。它在一项工作上好 3.15 倍，而那项工作决定了其他所有工作的平均水平。

CodeXGLUE 是集合中最纯粹的语义间隙任务，因为对代码应该做什么的自然语言描述与实现它的代码几乎没有共同的词汇。精确匹配没有任何可匹配的东西，得分 0.2901。这是向量搜索存在的原因，它在这个领域决定性地赢了。

SciQ 则相反。科学考试问题依赖于特定实体，在这种设置中，一个词不是概念的近似，而是一个关键。Mitochondria 不是类似于细胞的东西。精确匹配锁定该术语得分 0.8145，而向量搜索向在嵌入空间中相近的文档漂移，得分 0.6142。

SQuAD 是平手。在没有种子平均的单次运行中差距是 0.0088，这在噪声范围内，将其报告为向量胜利将是不诚实的。

向量成本，用数字说明

本文章的早期版本说嵌入生成是一种成本，但没有说明规模。它是 76.4 倍。

向量嵌入和索引

总计，50,000 份文档

这是同一机器上同一语料库中每秒 23,650 份文档对比 309 份。

后果是关于代理何时可以使用它刚刚学到的东西。如果代理需要读取一个仓库或一百页的文档并在同一轮内对其采取行动，精确匹配索引实际上是瞬时的，而嵌生成是一个咖啡时间。如果它现在读取并稍后执行，成本会摊销并停止重要。

指向超越两个系统的结果

HotpotQA 在表格中有最小的边距和最具有指导意义的下层失败。

这些问题需要链接两个文档，例如确定两本杂志中哪一本成立更早。向量搜索会可靠地检索第一个实体的文档并错过第二个实体的桥接文档，因为第二个文档与主要关于第一个的查询不够相似。答案是可检索的，但证据不是。

这不是相似性问题，没有重排器能解决。精确匹配和语义相似性都没有表示两个文档连接的概念。两个系统都独立地针对查询对文档进行排名，桥接文档根据定义是不看起来像查询的那个。回答这类问题需要存储关系本身，这是第三种机制，也是图结构在记忆系统中存在的原因。

找到答案与拥有足够的上下文来证明它不是一回事，检索前者但没有后者的代理会产生自信、无依据的输出，而不是错误。

方法，以及它的所有问题

任何人都可以重新运行这个，任何评估它的人都应该知道它在哪里不足。

在 2026 年 1 月 14 日，在配备 16GB RAM 的 Apple M4 上，每个数据集 10,000 份文档和 1,000 个查询，总共 50,000 份文档和 5,000 个查询。关键词搜索是使用默认分析器的 Tantivy 0.22.0。向量搜索是 ChromaDB 0.4.0 或更高版本，all-MiniLM-L6-v2 在 384 维度。两边都没有分块。得分是 MRR@10。

在评分上，这是这一类别中大多数基准理解错的部分。相关性通过针对每个数据集的真实情况进行精确文档 ID 匹配来以编程方式评估，在 src/evaluation/metrics.py 中。此管道中没有 LLM 判断器的任何地方。这里没有什么可以被提示文件、判断偏差或等价规则移动的，这是一个我们不能对这一类别中的大多数已发布数字做出的主张，包括我们自己在对话基准上的一些工作。在同一语料库上的重新运行会产生相同的表格。

六个限制，按照会被提出来反对我们的顺序。

1. 单次运行而不是多个种子上的平均值，因此小边距没有权重，SQuAD 应被理解为平手。

2. all-MiniLM-L6-v2 是一个相对较小且相对较旧的嵌入模型。更强大的嵌入器很可能会提高向量数字，可能会改变 HotpotQA 上的符号。诚实的说法是这测量了一个常见的默认配置，而不是最佳可用的向量设置。

3. Tantivy 在其默认分析器上运行，没有调优，所以关键词方面同样没有调优。

4. 没有分块，这影响两种方法，对较长的文档更影响向量检索。

5. 摄取时间来自 M4 上的本地嵌入。一个托管嵌入 API 在两个方向上移动该数字，对网络往返更差，对批量推理更好，所以将 76.4 倍视为成本的形状而不是常数。

6. MRR@10 测量正确文档的排名位置。它不测量代理是否随后产生了正确答案。检索排名和任务成功是不同的事情，我们宁愿自己说也不愿听到回应。

这不解决什么

这个基准在一个由别人编写且不会改变的固定文档语料库上运行。代理记忆不是这两种情况中的任何一种。它在每一轮都增长，它由代理本身编写，昨天的事实可能与今天的矛盾。

下一篇文章涵盖了一旦语料库是对话历史而不是文档时这两个系统会发生什么，这是有趣的失败所在的地方。架构论证，包括图结构和提取的位置，在我们的构建与购买代理记忆页面上，而令牌经济学的正式处理在我们关于代理上下文管理的论文中。