布吉岛 Agent

Appearance

5.2.3 相似度分数能不能直接当“正确率”看？ ​

先给结论：不能。相似度分数更像“当前查询和候选对象在向量空间里的接近程度”，它是排序信号，不是答案正确率，也不是业务置信度。

这条边界一定要先看清。

因为很多系统的问题，不是检索分数算错了，而是团队把分数解释错了。

相似度分数到底在表达什么 ​

在向量检索里，系统通常会给每个候选一个分数，用来表示：

  • 这个候选相对其他候选，更接近当前查询向量多少

所以这个分数最自然的用途是：

  • 排序
  • 截断
  • 做候选筛选参考

但它并不天然表示：

  • 这条结果一定正确
  • 这条结果一定可回答用户问题
  • 这条结果一定符合当前业务边界

为什么“分数高”也不等于“答案对” ​

因为向量相似度只在表达：

  • 语义上比较接近

而真实业务里，还需要同时满足很多条件，比如：

  • 版本是当前有效的
  • 权限是正确的
  • 内容没有过时
  • 回答所需信息是完整的
  • 候选不是噪声或边缘相似内容

所以即使某条结果相似度很高，它也仍然可能：

  • 是旧版本
  • 缺少关键上下文
  • 只在局部主题上相似
  • 不属于当前租户或当前范围

为什么“分数低”也不一定完全没用 ​

反过来也一样。

有时真正相关的内容可能分数不算特别高，原因包括：

  • 用户问法很绕
  • 文档表述方式和用户语言差异大
  • chunk 边界切得一般
  • 语义信号被其他词稀释

所以很多真实系统里，分数低并不总等于“绝对不相关”。

这也是为什么，很多团队不会只用一个固定分数就粗暴判死，而会结合：

  • Top K
  • metadata 过滤
  • rerank
  • 业务阈值

一起判断。

为什么不同系统里的分数还不一定能横向比较 ​

这也是一个非常容易踩坑的地方。

不同系统里你看到的“分数”，可能来自：

  • 不同相似度度量
  • 不同向量库实现
  • 不同归一化方式
  • 混合检索后的融合分数

这意味着：

  • 一个系统里的 0.82
  • 另一个系统里的 0.82

可能根本不是同一种含义。

所以分数最稳的看法通常不是“跨系统绝对解释”，而是：

  • 在当前系统内部，作为相对排序和阈值参考

一个更实际的理解方式 ​

你可以先把相似度分数理解成：

  • “在当前候选集合里，它有多像”

而不是：

  • “它有多对”

这两者差别非常大。

前者是检索排序问题，后者是业务正确性问题。

一个最小示意 ​

python
results = [
    {"text": "退款规则 v2：定制类商品支持无理由退货。", "score": 0.91},
    {"text": "退款规则 v3：定制类商品不支持无理由退货。", "score": 0.88}
]

这里只看分数的话，第一条更高。

但如果业务事实是：

  • v2 已失效
  • v3 才是当前版本

那么真正该用的反而是第二条。

这正好说明：

  • 相似度分数能告诉你“更像谁”
  • 但不能单独告诉你“谁现在更该用”

分数更适合怎么用 ​

更稳的用法通常包括：

  1. 用来给候选排序
  2. 和阈值结合，裁掉明显太弱的候选
  3. 配合 rerank 或业务规则做进一步选择
  4. 用来观察检索分布是否异常

比如你会关心：

  • 前 3 个候选分数是否都很低
  • 第一名和第二名差距是否非常小
  • 某类问题的分数分布是否普遍异常

这些用法都比“直接拿分数当正确率”更稳。

一个常见误区 ​

很多人会做这样的推理：

  • 分数 0.9，说明这条结果大概率就是对的

这通常过头了。

更现实的理解是：

  • 这条结果在当前向量空间下，和查询更接近

但“更接近”距离“业务上正确可用”之间，还隔着：

  • 版本
  • 权限
  • 边界
  • 上下文完整性

一句话总结 ​

相似度分数不能直接当“正确率”看，因为它表达的是向量空间里的接近程度，而不是业务正确性。它更适合当排序和筛选信号，而不是单独当成结果是否正确的判断依据。