别从向量数据库开始：先用关键词搜索打好基线

构建RAG助手时，很多团队的第一反应是部署一个向量数据库。但意大利开发者Omar Baruzzo在一篇被广泛讨论的博客文章中提出了不同意见：先别急着上向量，用你已有的搜索能力打好基线，让评估数据告诉你什么时候真正需要embedding。

先看用户真正在问什么

Baruzzo建议的第一步不是技术选型，而是收集真实问题。从实际使用助手的用户那里拿到问题，而不是自己想象。收集之后做分类统计，会发现一个规律：相当大比例的问题其实是指向性检索——合同编号、客户名称、日期区间、物料编码、某个人名。

这类查询恰恰是向量搜索的弱项。向量搜索比较的是语义近似度，对精确匹配天然不擅长。反过来，关键词搜索和SQL过滤在标识符匹配上非常精准，但当用户用词和文档用词不一致时就无能为力。

关键洞察在于：这两种能力通常已经存在于你的技术栈中，不需要额外引入新基础设施。

指向性检索（指向性查询） 是指用户的问题带有明确的、唯一的匹配目标，例如通过合同编号、客户名称、日期区间、物料编码或具体人名来定位某条或某组记录。这类查询的核心需求是“精确命中”，而不是“语义相似”。在传统搜索中，它通常由倒排索引、B树索引或SQL WHERE条件直接完成；在向量检索中，由于embedding会把字符串映射为高维语义向量，编号、日期、编码这类没有语义结构的字符串之间可能产生不可控的相似度，导致精确目标被淹没或误召回。因此，识别指向性查询在真实问题中的占比，是判断是否需要向量搜索的关键依据之一。

先建立可比较的基线

确定了一批真实问题后，第二步是为其中约五十个问题写出标准正确答案。然后用全文搜索加结构化过滤跑一遍，记录多少问题能返回正确结果。

这个数字就是你的基线。它的意义在于：后续任何新增技术方案，都必须能超越这个基线，否则就称不上改进。

Baruzzo的原话说得很直接：没有基线，增加向量搜索不能叫"改善"，只能叫"变化"。这是一个微妙但重要的区分——团队很容易把"系统变了"误认为"系统变好了"。

基线（baseline） 在这里指的是一套可复现的评估参照：固定一批真实问题、固定标准答案、固定评分方式，然后用现有最简单的方案跑出得分。它的价值不在于分数高低，而在于让后续每一次技术变更都有一个可比较的锚点。没有基线时，团队只能凭主观感受判断“效果好像变好了”；有基线时，才能回答“向量搜索让准确率从62%提升到71%”这类可验证的问题。对于RAG系统，基线通常还包括检索命中率、答案正确率、权限过滤正确率等指标，且必须用同一套问题集反复重跑，否则比较就失去意义。

向量该在哪里介入

Embedding真正体现价值的场景是词汇不匹配。用户问"如何提前结束租约"，而文档里写的是"租赁合同的提前解除条款"——语义相同但用词不同，这时纯关键词搜索会漏掉相关文档。

当评估集显示这类错误占主导时，混合搜索就有了充分理由：关键词加向量，合并结果。到这一步，收益可以被量化，团队也能判断这个收益是否值得额外的成本。

这里的方法论核心是：让错误类型驱动技术决策，而不是反过来。

词汇不匹配（vocabulary mismatch） 是信息检索中的经典问题：用户提问的用词与文档中实际使用的术语不一致，但语义相同。例如用户说“提前结束租约”，文档写“租赁合同的提前解除条款”；用户说“电脑开不了机”，文档写“设备无法正常启动”。关键词搜索依赖字面匹配，遇到同义、近义或不同表述时容易漏召回；向量搜索通过语义嵌入把不同措辞映射到相近的向量空间，从而弥补这一缺口。但向量搜索并非万能：它可能召回语义相近但事实无关的内容，也可能在需要精确匹配时表现不稳定。因此，混合搜索（关键词+向量）通常比单一方案更稳健，前提是评估数据证明词汇不匹配确实是主要错误来源。

一个索引就是一份副本

引入向量索引的代价常被低估。Baruzzo指出了一个容易被忽视的问题：向量索引本质上是文档的一份副本。

这意味着三件事：索引需要与数据源保持同步；更换embedding模型时需要重建整个索引；索引必须执行与原系统相同的访问权限控制。

最后一点尤其关键。在原始应用中无权打开某文档的用户，不应该通过助手检索到它。权限漏洞在副本中是静默的、难以发现的，如果涉及个人数据，还会构成合规问题。

访问权限控制（access control） 在RAG助手中是一个常被忽视但风险很高的环节。当把文档灌入向量索引时，实际上创建了一份独立的数据副本，而这份副本往往绕过了原始系统的权限校验。如果原应用中某用户无权打开某份合同或工单，但该文档已被嵌入索引，助手就可能通过语义检索把它“泄露”给无权用户。更麻烦的是，这种泄露是静默的：用户不会收到“权限不足”的提示，系统也不会报错，只有审计或事故复盘时才会暴露。若涉及个人数据、财务记录或合规敏感信息，这还可能违反数据保护法规。因此，向量索引必须继承与原系统一致的权限模型，并在检索阶段执行过滤，而不是只在展示阶段做检查。

这是关于做事顺序的争论

Baruzzo明确表示，以上论述并非反对向量搜索本身，而是关于工作顺序。

有测量基线的团队可以说清楚embedding到底带来了什么增量；没有基线的团队只能笼统地说"助手好像变好了"。当下一代模型或索引版本发布时，有基线的团队重跑问题集就能判断是否值得切换；没有基线的团队则无从比较。

从无聊的搜索开始，测量它，让错误告诉你该加什么。这个思路在向量数据库热潮中值得每个构建RAG系统的团队认真对待。