布吉岛 Agent

Appearance

5.2.4 为什么只做向量检索通常不够？ ​

先给结论：因为向量检索很擅长找语义接近内容，但真实检索问题不只有“语义接近”这一种。只靠向量检索，通常很难同时兼顾术语精度、业务边界、版本控制和结果稳定性。

所以向量检索很重要，但在很多生产系统里，它通常不是单独工作的。

向量检索最擅长的是什么 ​

它最擅长的是：

  • 找近义表达
  • 找说法不同但主题接近的内容
  • 处理自然语言问法变化

这也是为什么它在 RAG 里很有价值。

但问题在于，真实检索需求远不止这些。

只做向量检索，常见会缺哪几层能力 ​

1. 精确术语和编号命中不一定稳 ​

很多业务问题并不是“主题接近”就够了，而是要求：

  • 命中准确术语
  • 命中规则编号
  • 命中特定产品型号
  • 命中指定接口名或字段名

这类问题里，BM25 或关键词检索经常更可靠。

如果只靠向量检索，常见问题是：

  • 语义上差不多
  • 但不是那一条术语最准确的内容

2. 业务边界不是靠相似度解决的 ​

向量检索可以告诉你：

  • 哪些内容更像

但它不能天然决定：

  • 哪个版本当前有效
  • 哪个租户的数据能参与
  • 哪些内容用户有权限看
  • 哪些内容已经失效

这些问题更像属于：

  • metadata 过滤
  • 权限控制
  • 版本管理

如果只做向量检索，不把这些层补上，结果很容易“像是相关，但其实不该出现”。

3. 它往往会返回“最接近”，哪怕并不真的合适 ​

纯向量查询常见的一个特征是：

  • 即使库里没有真正好的答案，它仍然会返回最近的几个邻居

这就意味着，如果你只依赖向量检索，又没有：

  • 阈值
  • BM25 补充
  • 过滤和后处理

系统就可能把“相对最近但其实不够相关”的内容也带进后续链路。

4. 多种数据类型的最优信号本来就不同 ​

如果知识库里同时有：

  • FAQ
  • 规则制度
  • 产品型号说明
  • 代码文档

那么这些内容未必都适合只用一种向量信号来召回。

比如：

  • FAQ 更适合语义问答匹配
  • 型号和编号更依赖关键词
  • 代码和接口名通常也更需要精确匹配

这时候单路向量检索往往会顾此失彼。

一个更实际的系统理解 ​

你可以先把真实检索拆成三层：

  1. 语义层：找主题接近的内容
  2. 精确层：找术语、编号、专名精确命中
  3. 边界层：控制版本、权限、租户和有效性

向量检索主要强在第一层。
但真实可用系统，通常三层都要有。

一个最小示意 ​

python
vector_candidates = vector_search(query_vector, top_k=10)
keyword_candidates = bm25_search(user_query, top_k=10)

merged = merge_candidates(vector_candidates, keyword_candidates)
filtered = filter_by_metadata(merged, status="active", tenant_id="tenant-a")

这段代码想说明的是：

  • 向量检索解决不了所有问题
  • 很多系统会把语义召回、关键词召回和边界过滤一起组织

什么场景尤其不该只靠向量检索 ​

下面这些场景，尤其不建议只靠单路向量检索：

  1. 查询里有大量术语、编号、产品名、接口名
  2. 版本和权限边界非常重要
  3. 数据里有很多相似模板，容易语义混淆
  4. 需要高稳定性，不能把“差不多相关”当成“可以接受”

这些场景里，单靠向量检索往往会让系统显得“有点聪明，但不够稳”。

一个常见误区 ​

很多人会觉得：

  • 只要 embedding 模型足够强，就没必要再加 BM25 或 metadata 过滤

这通常是把“语义能力强”误解成了“检索能力完整”。

真实系统里经常同时需要：

  • 语义召回
  • 精确命中
  • 业务边界控制

只靠向量检索，通常只覆盖了第一层。

一句话总结 ​

只做向量检索通常不够，因为真实检索问题不只有语义接近，还包括术语精度、版本、权限和业务边界。向量检索很重要，但很多生产系统真正稳定，是因为它和 BM25、metadata 过滤、多路召回一起工作。