别急着上向量数据库：先测好你的检索基线

构建 RAG 助手时，很多团队的第一步就是接入向量数据库。但 Omar Baruzzo 在一篇博客中提出了相反的思路：先别碰向量，用你已有的全文检索和结构化过滤测出一个可信的基线，让评估数据告诉你到底该在哪里补向量。

先看清用户到底在问什么

Baruzzo 建议的第一步不是选型，而是收集真实问题——向真正要使用这个助手的人要，而不是自己编造。拿到问题后做分类，你往往会发现其中很大一部分本质上是查找类问题：合同编号、客户名称、日期范围、物料代码、某个人名。

这类问题的共同点是需要精确匹配。向量检索比较的是语义近似，恰恰在最需要“一模一样”的标识符上表现糟糕。而关键词检索和 SQL 过滤正好相反：对标识符极其精确，但当提问用词和文档用词不一致时就容易漏掉。

关键在于，这两种能力通常已经躺在你现有的技术栈里了，不需要额外引入新的存储系统。

全文检索与结构化过滤的区别：全文检索（Full-Text Search）是对文档文本建立倒排索引，通过关键词、词干、布尔组合等方式匹配，代表实现有 Elasticsearch、PostgreSQL 的 tsvector、SQLite 的 FTS5 等。结构化过滤则是基于关系型数据库中已有的列（如合同编号、客户 ID、日期、状态字段）做等值或范围查询，本质是 WHERE 子句。二者常组合使用：先用 SQL 缩小候选集，再用全文检索排序。

为什么向量检索在标识符上表现糟糕：嵌入模型把文本压缩成稠密向量，语义相近的字符串在向量空间中距离接近，但“C-1024”和“C-1025”这类仅差一位的编号可能因为语义无关而被映射到不同区域，也可能因训练时未见过的组合而被映射到任意位置。相似度排序对精确等值没有约束力，缺少数据库索引那种“命中即等于”的保证，因此不适合做主键式查找。

用五十个问题建立基线

有了真实问题，下一步是为其中大约五十个问题写下“正确答案应该长什么样”。然后把这些问题跑一遍全文检索加结构化过滤，记录有多少个能准确返回。

这个召回结果就是你的基线。Baruzzo 强调，之后添加的任何东西都必须能超过这个数字——否则你无法称向量带来了“改进”，只能叫“变化”。没有基线，向量检索的效果提升就是不可证伪的说法。

这个做法的价值在于把主观感受变成可比较的数字。助手“感觉更好了”不是工程结论，基线之上的增量才是。

评估集与基线的工程意义：评估集（evaluation set）是一组带有“标准答案”或“期望命中文档”标记的问题集合，用于以固定标准反复测量系统表现。召回率（recall）衡量在全部应被检索出的相关文档中，系统实际返回的比例，是检索系统的核心指标之一。基线（baseline）则是最简方案在同一评估集上的成绩，用来做后续比较的参照。

没有评估集时，“更好了”只能凭感觉；没有基线时，任何新方案的收益都无法量化，也无法判断代价是否值得。五十个问题的规模足够覆盖主要查询类型，又能在每次改动后快速重跑（通常几分钟内完成），成本低到可以纳入日常开发循环。这是 RAG 工程中“可测量优先”原则的具体体现。

向量真正该出场的地方

向量检索有自己的主场，那就是词汇鸿沟。Baruzzo 举的例子很直观：用户问“如何在到期前终止租约”，而文档里写的却是“提前解除租赁合同”。意思一致，用词不同，关键词检索在这种场景下会失效。

当评估集明确显示出这一类错误时，混合检索（关键词加向量，结果融合）才是有依据的选择。此时收益可以被测量，也才有条件去判断它值不值这个成本。注意前提：是评估集先暴露了问题，而不是先上了向量再去找它的好处。

词汇鸿沟（vocabulary gap）与混合检索：词汇鸿沟指查询词与文档用词不一致导致关键词检索漏召回，典型表现是同义替换、上下位词、口语与书面语差异。向量检索通过语义相似度缓解这一问题，但会引入新的假阳性。

混合检索（hybrid search） 指同时执行关键词检索与向量检索，再对两路结果做融合。常见融合策略包括倒数排序融合（Reciprocal Rank Fusion, RRF）和加权分数结合。混合检索的价值在于用关键词保证标识符精确性，用向量弥补语义鸿沟，在评估集上通常优于单一策略，但会带来更高的查询延迟与更复杂的调优成本，因此应当由评估数据而非直觉来触发。

多一个存储的真实代价

向量索引本质上是文档的一份副本。Baruzzo 列出的维护负担值得每一个准备上线的团队认真对待：

• 副本必须和源数据保持同步
• 嵌入模型更换时需要重建整个索引
• 副本必须执行和原系统完全一致的访问权限

最后一条最容易出事。在原应用里打不开某份文档的人，也不应该能通过助手拿到它。权限在副本上的错误往往是静默的、难以排查的，如果涉及个人数据，还会演变成合规问题。

权限一致性与合规风险：向量索引通常作为独立的存储系统存在，其访问控制与原系统相互独立，容易出现“原应用已限制访问，但助手仍能召回该文档”的静默泄漏。修复方式有两种：一是在检索后由原系统做一次权限校验（行级安全过滤），二是将权限元数据同步写入向量库并在查询时强制过滤。前者保证一致性但增加延迟，后者需要建立同步机制并处理权限变更的传播。

当文档涉及个人数据时，未经授权的召回可能构成数据保护法规下的合规问题（如 GDPR、PIPL）。这类问题不会立刻报错，往往在审计或用户投诉时才暴露，因此必须在架构阶段就纳入设计，而不是上线后再补。

顺序问题，而非路线之争

Baruzzo 明确表示，这些论点不是在反对向量检索。他反对的是顺序：向量被当成了起点，而它更适合作为补丁出现在基线失效的地方。

这个区别在模型或索引换代时会变得具体。有基线的团队可以重新跑一遍问题集，判断是否值得迁移；没有基线的团队只能说助手“现在看起来更好”。

他的建议收得很干脆：从无聊的检索开始，测它，然后让错误告诉你该加什么。

你在自己的助手里，有多少问题是披着外衣的查找？