RAG 中如何设计检索结果的置信评分机制？

在 RAG 系统里，我们经常会遇到一个问题：

检索出来的这段内容，到底有多可信？

比如用户问：

Redis 默认端口是多少？

检索系统返回了 5 个 Chunk。

虽然它们都被检索出来了，但实际上相关程度可能完全不同。

所以一个比较实用的做法，就是给每个检索结果计算一个：

Confidence Score，置信评分。

这个分数可以用来决定：

哪些内容可以传给 LLM

哪些内容只能作为辅助参考

哪些内容应该直接过滤掉

我自己比较推荐的基础方案，就是：

向量相似度
+
关键词匹配度

这两个指标结合起来，已经能够覆盖很多 RAG 场景。

一、为什么不能只看向量相似度？

向量检索擅长的是：

判断两段文本在“语义上”是否相似。

例如用户问：

Redis 为什么这么快？

文档写的是：

Redis 的数据主要存储在内存中，
因此能够减少磁盘 IO。

虽然两个句子里面几乎没有多少相同关键词，但语义明显相关。

Embedding 模型通常能够识别这种关系。

所以：

向量相似度非常适合判断语义相关性。

但是它有一个问题。

有些文本：

看起来语义相近，但实际上并不能回答用户的问题。

例如用户问：

Redis 默认端口是多少？

结果检索到了：

Redis 是一种高性能内存数据库。

它和 Redis 这个主题非常相关。

但是：

它根本没有回答“端口是多少”。

所以只依赖向量相似度，有时候会出现：

主题相关
≠
答案相关

二、为什么还要加入关键词匹配？

关键词匹配可以补上这个缺点。

例如用户问：

ERROR_CODE_1045 是什么意思？

这类问题里面：

ERROR_CODE_1045

本身就是一个非常强的关键词。

如果某个文档恰好包含：

ERROR_CODE_1045

那么它很可能比一个“语义大概相似”的文档更加可靠。

关键词匹配尤其适合：

错误码

产品型号

订单编号

接口名称

类名

函数名

专有名词

数字

版本号

所以可以简单理解成：

Vector Similarity
负责判断：

“意思像不像？”

Keyword Match
负责判断：

“关键东西对不对？”

两者结合通常比单独使用一个指标更加稳定。

三、最简单的置信评分公式

可以设计一个很简单的评分公式：

Confidence Score
=
0.7 × Vector Similarity
+
0.3 × Keyword Match Score

例如某个 Chunk：

Vector Similarity = 0.90

Keyword Match = 0.80

那么：

Confidence
=
0.7 × 0.90
+
0.3 × 0.80

= 0.87

最终：

Confidence = 87%

于是可以把它定义成：

High Confidence

四、为什么我更建议向量相似度权重大一点？

普通自然语言问答中，用户和知识库通常不会使用完全相同的表达。

例如用户问：

这个产品可以退吗？

知识库可能写：

消费者可以在购买后的 14 天内申请退款。

关键词：

退
退款

可能只匹配到一部分。

但语义明显高度相关。

因此普通 RAG 中，我通常会从这样的权重开始：

Vector Similarity：70%

Keyword Match：30%

也就是：

Confidence =
0.7 × Semantic Score
+
0.3 × Keyword Score

然后再根据实际 Evaluation 数据调整。

五、不同场景，权重应该不同

70/30 并不是固定规则。

如果系统主要处理：

FAQ
产品说明
内部知识库
自然语言问答

可以更偏向向量：

Vector：70%
Keyword：30%

但如果系统主要查询：

错误码
设备型号
SKU
API
订单号
版本号

关键词就应该更重要，例如：

Vector：40%

Keyword：60%

因为对于：

ERR_10241

这种东西来说：

精确匹配往往比“语义相似”更加重要。

所以权重应该由业务场景决定，而不是写死。

六、一个非常重要的问题：先做分数归一化

这里特别容易踩坑。

假设：

Vector Similarity = 0.82

但是 BM25 关键词分数可能是：

BM25 Score = 13.7

这两个数字不能直接：

0.82 + 13.7

因为它们根本不是一个量纲。

所以最好先把两个分数转换成：

0 ～ 1

例如：

Vector Score
0 ～ 1

Keyword Score
0 ～ 1

然后再计算：

Confidence
=
α × Vector Score
+
β × Keyword Score

并且：

α + β = 1

这一步叫：

Score Normalization，分数归一化。

七、关键词匹配度应该怎么算？

最简单的方法是：

看用户 Query 中的重要关键词，有多少出现在文档里。

例如：

Query：

Redis 默认端口是多少？

提取关键词：

Redis
默认端口

某文档包含：

Redis 默认监听端口为 6379。

两个关键词都匹配。

那么：

Keyword Score = 1.0

如果只匹配：

Redis

没有匹配：

默认端口

那么可以得到：

Keyword Score = 0.5

当然，实际项目里还可以使用：

BM25
TF-IDF
Exact Match
Token Match

来计算更加合理的关键词分数。

八、不是所有关键词都应该一样重要

还有一个非常重要的优化。

例如：

Redis 默认端口是多少？

这里：

是多少
默认

其实没有那么重要。

真正关键的是：

Redis
端口

所以最好给关键词设置权重。

例如：

Redis        0.4
端口         0.4
默认         0.2

如果某个文档同时命中：

Redis
+
端口

即使没有“默认”这个词，它仍然可以得到较高分数。

这比简单计算：

命中几个词 / 总词数

更加合理。

九、可以把置信度分成三个等级

最终得到 Confidence Score 后，不一定需要直接把：

0.873

暴露给模型。

可以转成更加直观的等级。

例如：

Confidence ≥ 0.85
→ High Confidence

0.70 ≤ Confidence < 0.85
→ Medium Confidence

Confidence < 0.70
→ Low Confidence

然后处理策略可以设计成：

High
↓
直接进入 Context

Medium
↓
作为补充信息

Low
↓
直接过滤

整体流程：

Retriever
   ↓
Vector Score
   +
Keyword Score
   ↓
Confidence Score
   ↓
───────────────

High
→ 保留

Medium
→ 谨慎使用

Low
→ 过滤

这样整个 RAG Pipeline 会更加可控。

十、一个完整例子

用户问题：

Redis 默认端口是多少？

检索到了三个文档。

Document A

Redis 默认端口是 6379。

评分：

Vector = 0.93

Keyword = 1.00

计算：

Confidence
=
0.7 × 0.93
+
0.3 × 1.00

= 0.951

结果：

95.1%
High Confidence

Document B

Redis 是一种高性能内存数据库。

评分：

Vector = 0.84

Keyword = 0.50

最终：

Confidence
=
0.7 × 0.84
+
0.3 × 0.50

= 0.738

结果：

73.8%
Medium Confidence

Document C

MySQL 默认端口是 3306。

评分：

Vector = 0.55

Keyword = 0.30

最终：

Confidence = 47.5%

结果：

Low Confidence

所以最终真正传给模型的，可能只有：

Document A

或者：

Document A
+
Document B

而 Document C 直接被过滤。

十一、不要把 Confidence 当成“事实正确率”

这里有一个概念非常重要。

我们计算出来的：

Confidence = 92%

并不意味着：

这段文档有 92% 的概率是正确的。

它真正表达的是：

根据当前检索信号，这个文档和用户问题具有较高的匹配可信度。

因为：

向量相似度
+
关键词匹配

主要衡量的是：

Retrieval Relevance

而不是：

Factual Correctness

文档本身完全有可能是错误或者过期的。

所以更准确的名字其实可以叫：

Retrieval Confidence

也就是：

检索置信度。

十二、以后还可以继续增加其他信号

如果系统以后变复杂，可以在这两个基础指标上继续增加：

Vector Similarity

Keyword Match

Reranker Score

Source Authority

Document Freshness

例如：

Confidence
=
40% Vector Similarity

+ 20% Keyword Match

+ 25% Reranker Score

+ 10% Source Authority

+ 5% Freshness

这样就从：

“这个文档和问题像不像？”

逐渐升级成：

“这个文档是否相关、可靠、权威并且没有过期？”

这会更加接近真正生产级的 RAG 置信评分体系。

十三、实际项目建议怎么做？

如果现在系统还不是特别复杂，我反而不建议一开始设计十几个指标。

先使用：

Vector Similarity
+
Keyword Match

完全足够。

可以从：

Confidence
=
0.7 × Vector
+
0.3 × Keyword

开始。

然后通过真实测试集观察：

High Confidence
里面有多少是真的相关？

Low Confidence
里面有没有大量正确结果被误杀？

再慢慢调整：

权重

Threshold

High / Medium / Low 分界线

而不是凭感觉设置。

总结

RAG 中设计检索置信评分，一个简单又实用的方法就是：

语义相关性
+
关键词相关性

也就是：

Vector Similarity
+
Keyword Match

两者分别解决：

Vector Similarity
→ 意思像不像？

Keyword Match
→ 关键内容对不对？

然后：

Normalize
↓
Weighted Score
↓
Confidence Score
↓
High / Medium / Low
↓
过滤低质量 Context

对于普通 RAG 项目，可以先从：

Vector Similarity：70%

Keyword Match：30%

开始。

但最重要的并不是这个 70/30。

真正重要的是：

通过真实 Evaluation Dataset 去校准权重和阈值。

最终，一个好的检索置信评分机制，并不是单纯告诉我们：

“这个结果分数是多少。”

而是帮助整个 RAG 系统做一个更重要的决定：

这段内容，到底值不值得交给大模型。