RAG 评测:离线指标与线上效果的鸿沟#
RAG 项目最经典的场景:离线 recall@5 90%,上线后用户还是骂"答非所问" 。为什么离线指标好看、线上效果拉胯?
因为 RAG 评测有三层,大部分项目只测了第一层。
一、RAG 的评测分层#
第
第
第
1
2
3
层
层
层
:
:
:
检
生
端
索
成
到
质
质
端
量
量
效
(
(
果
找
答
(
得
得
用
对
好
户
不
不
满
对
好
不
)
)
满
意
)
二、第 1 层:检索质量#
R
P
M
N
e
r
R
D
c
e
R
C
a
c
:
G
l
i
第
:
l
s
一
带
@
i
个
相
K
o
正
关
:
n
确
性
正
@
答
权
确
K
案
重
答
:
的
的
案
前
排
排
出
名
序
现
K
质
在
量
前
条
里
K
多
少
条
是
的
有
比
用
例
的
评测集#
1
2
3
4
5
{
"query" : "简历缓存一致性方案" ,
"gold_docs" : ["doc-123" , "doc-456" ], // 正确答案
"relevant" : ["doc-123" , "doc-456" , "doc-789" ]
}
为什么 recall@5 90% 了线上还差#
鸿沟 1:评测集和真实分布脱节
评
线
测
上
集
:
"
:
真
缓
精
实
存
心
问
怎
构
题
么
造
(
搞
的
口
的
问
语
"
题
化
(
、
—
清
残
—
晰
缺
、
、
评
完
多
测
整
义
集
)
)
里
没
有
这
种
问
题
解法 :线上问题采样进评测集(每天自动抽 1% 真实 query,人工标注)。
鸿沟 2:只测"找没找到",没测"找到的有没有用"
R
但
→
e
c
L
1
L
a
L
L
l
M
条
M
l
正
看
确
被
高
到
答
噪
的
案
音
=
前
带
+
偏
正
3
确
2
→
答
条
案
可
条
答
在
能
高
非
列
:
相
所
表
似
问
里
度
噪
音
解法 :加"噪音比例"指标(前 K 条中无用的比例),和重排质量。
三、第 2 层:生成质量#
忠
相
完
格
实
关
整
式
度
度
性
正
(
(
(
确
F
R
C
性
a
e
o
i
l
m
t
e
p
h
v
l
f
a
e
u
n
t
l
c
e
n
e
n
e
)
e
s
:
s
s
回
s
)
答
)
:
是
:
回
否
要
答
针
点
是
对
是
否
问
否
完
题
答
全
全
基
于
检
索
内
容
(
不
幻
觉
)
评测方法#
1
2
3
.
.
.
L
事
引
L
实
用
M
核
检
-
对
查
a
:
:
s
回
回
-
答
答
J
中
是
u
的
否
d
每
带
g
个
来
e
事
源
:
实
、
强
能
来
模
否
源
型
在
是
按
检
否
维
索
真
度
内
实
打
容
分
中
(
找
检
到
索
内
容
+
问
题
+
回
答
)
1
2
3
4
5
6
7
8
# 事实核对(判断幻觉的核心)
def check_faithfulness (answer, contexts):
facts = extract_facts(answer) # 拆事实
unsupported = [
f for f in facts
if not any(f in ctx for ctx in contexts) # 检索内容里没有
]
return 1 - len(unsupported) / len(facts) # 忠实度
关键:生成质量评测必须"看检索内容"#
❌
✅
只
给
给
"
"
问
问
题
题
+
+
检
回
索
答
内
"
容
让
+
L
L
回
M
答
"
打
三
分
件
(
套
回
(
答
才
错
能
没
发
错
现
,
:
不
回
依
答
赖
是
好
R
的
A
,
G
但
没
质
用
量
上
)
检
索
内
容
)
四、第 3 层:端到端效果#
用
业
户
务
可
满
任
放
人
价
转
感
意
务
弃
工
值
化
知
度
成
率
兜
:
率
的
(
功
(
底
:
点
率
没
率
/
赞
(
答
(
/
问
明
转
工
点
答
白
人
单
踩
闭
就
工
减
)
环
走
的
少
完
)
比
成
例
/
)
)
成
本
下
降
端到端评测集(线上回流)#
用
户
点
踩
的
问
答
→
自
动
入
"
问
题
池
"
→
定
期
人
工
标
注
→
补
进
评
测
集
闭环 :线上差评 → 进评测集 → 复现问题 → 修(检索/重排/生成)→ 验证 → 回归。
五、三层的关系与优先级#
第
第
第
优
先
1
2
3
级
先
再
最
:
让
让
后
层
层
层
检
生
看
(
(
(
索
成
用
检
生
用
"
"
户
索
成
户
找
用
"
)
)
)
得
得
满
错
错
反
到
上
不
了
了
馈
"
"
满
(
(
意
→
→
→
R
F
"
e
a
(
第
第
反
c
i
业
哺
a
t
务
2
3
第
l
h
指
、
l
f
标
3
层
1
u
)
错
、
高
l
层
2
)
n
必
→
e
然
层
s
错
再
s
修
→
生
高
成
)
先
修
检
索
每个指标的优化动作 :
R
噪
F
R
e
音
a
e
c
多
i
l
a
t
e
l
→
h
v
l
f
a
加
u
n
低
重
l
c
排
n
e
→
(
e
R
s
低
调
e
s
r
→
e
a
低
m
n
问
b
k
→
题
e
)
重
d
/
收
写
d
紧
i
调
引
/
n
阈
用
g
值
意
图
/
识
限
别
换
查
制
模
重
上
/
型
下
文
检
/
索
/
改
加
写
混
P
合
r
检
o
索
m
p
t
约
束
六、踩坑记录#
评测集 100 条就敢下结论 :指标波动大 → 至少 300-500 条 + 固定版本
只看 Recall 不看噪音 :Recall 90% 但 top3 里 2 条噪音 → 加噪音率指标
LLM 评分偏置 :偏好长回答 → 多模型投票 + 人工抽查校准
线上回流不及时 :用户骂了半个月才进评测集 → 差评自动入池 + 每周标注
RAG 评测的核心认知:
三层评测 :检索(找得对)→ 生成(答得好)→ 用户(满不满意)
鸿沟的根源 :评测集 ≠ 真实分布,离线指标 ≠ 用户感知
评测必须看上下文 :生成评测要带"检索内容"看,才发现真问题
闭环回流 :线上差评进评测集,修复后回归验证
RAG 评测的目的不是"证明它好",是"知道它哪里不好、改哪里"。 三层指标对上了,优化才不是玄学。
微信公众号「福清而不淡」
后端架构 · AI 工程 · 云原生的一线实践,扫码关注,不错过更新。
本文已同步发布到公众号,欢迎留言交流。