为什么它里面没有向量数据库

2026年9月16日 · 阅读需 4 分钟

打造 MindMax

每隔几天，就有一位自己搭过检索系统的人问起 MindMax 同一个问题，而且这是个好问题：如果不对我的文件夹做一遍 embedding，它怎么找到东西？

简短的回答是：它像你一样找材料——靠结构、靠页面上的字眼、靠换几种说法再试——而小到能读完的文档，是直接读，而不是从中检索。更长的回答是：这是一种有真实代价的取舍，假装没有代价，就会成为那种第一次被人测试就站不住的说法。

我们放弃了什么

直说，因为这一部分通常被埋在脚注里：一个措辞和你的文件差别很大、或者换了一种语言提出的问题，可能会漏。

这恰恰是 embedding 擅长的。「好像是讲道德风险的那件事」这样的查询，和你要找的那段文字几乎没有字面上的重合，向量索引处理起来却很从容。我们不行，最多只是生成几种别的说法再试一遍。如果你的搜索大多是这样的，向量方案会更适合你，你应该用它。

四样东西，而且会叠加。

问任何问题之前都不用等。 指向一个文件夹就能问。没人需要先熬过一次对两百份 PDF 的建索引任务，软件才变得能用。这比听起来更要紧：头五分钟，决定了人们会不会留下一个应用。

没有过时的索引。 改一篇笔记，下一个问题就能看到这处修改。维护过个人 RAG 管线的人都知道那种失败：回答笃定地建立在三周前那个版本的文件上——也知道要多久才会发现。

精确的字眼保持精确。 一个法条编号、一个变量名、一串引用编号——恰恰是相似度会模糊掉的东西——会按字面被找到，因为找某一句特定的话是一次查找，就按查找来处理。

成本和你实际读了多少成正比。 什么都做 embedding，就意味着为一切付费，包括那四百份你永远不会问到的文档。

有意思的问题不是「哪种检索方法得分更高」，而是哪种失败是看不见的。

检索漏了，产出的是一个流畅、出处齐全的回答，却缺了那段决定性的文字，输出里没有任何信号说明这一点。你没法审计没被检索到的东西。相比之下，字面上的漏检是响亮的：你搜了，没得到有用的东西，马上就知道该换几个词试试。

一边是你看得见的失败方式，一边是你看不见的，在你要据以做决定的材料上，我们宁愿要看得见的那一种。这是关于个人文档工作是什么样子的判断，不是一个评测结果，不同意它也完全合理。

大部分优势根本不在搜索上——而在于不需要搜索。一篇二十页的论文，能被现代上下文窗口装下好几遍，所以把它切块，是在解决一个不存在的问题。全文直接放进去，对这份文档来说，整类检索遗漏的失败根本不会发生。书装不下，所以按它自己的章节结构导航、一节一节地读，就像人使用目录那样。

检索发生在边缘：横跨一个大文件夹时，或者在一本大到读不完的书里。它是兜底，并且老实承认自己是兜底。

如果把这些读成「我们不用 embedding，因为它不好」，那就错了。代码库里有一个向量层，作为可选的加速器存在，在我们发布的版本里是关闭的。如果以后我们把它打开，这一页上的一切依然成立——「你不需要自己搭一个」和「我们做不到」是两个不同的说法，只有前一个是我们的。

更详细的说明见全文优先，实际用起来的样子见搜索是怎样工作的，并排对比见 MindMax 对比自己搭 RAG。如果你想试试它的表现，而不只是读说明，就从对你的文档提问开始。