← 返回概念辨析

Concept Contrast Fable

上下文精确率和忠实性,一个测检索相关性,一个测答案靠不靠证据

上下文精确率衡量检索到的内容有多少真正相关,忠实性衡量模型生成的答案在多大程度上建立在检索内容之上。两个指标都放在 RAG 评估报告里,但指向的故障位置不同:一个出在检索环节,另一个出在生成环节。

寓言

药铺有两个秤,一个秤药材对不对,一个秤药方准不准

城南老药铺每天从上百味药材里抓药。伙计先把可能相关的药端到桌上,坐堂先生再据此开方,掌柜觉得这套流程够用。

铺里后来规定,每次开方前都端八味药给先生看。掌柜以为看得越多,方子越好。伙计图省事,把第一排最像的八味直接端上去。

第三个月出了事故。病家其实是内寒夹虚,桌上却多是风寒药,因为病人说过一句“受凉”。先生写出的方子通顺,药性也不冲,却没贴住真实病症。

掌柜复盘时放下两把秤。第一把秤称伙计:端来的八味里有多少真正对症?混入无关药越多,说明前面找药就不精。

第二把秤称先生:方子里每一味药,能不能在桌上找到依据?若桌上有对的药,先生却凭感觉换成别的,说明写方没有守住证据。

那次事故,两边都露出问题。伙计把沾边材料混了进来,先生又把有依据的附子换成自己更安心的干姜。药铺后来分开追查:前面找错药,修找药;后面不按药开方,修开方。两根管子不能互相背锅。

掌柜还发现,报告里的好数字会骗人。若只说八味里有六味沾边,大家容易忽略那两味无关药可能把先生引到错方向。

若只说先生每味都有出处,也可能只是忠实地照着一盘坏药开方。药铺后来把两把秤并排挂在柜台后。先看端来的东西准不准,再看开出的方子守不守依据,错处才不会互相遮掩。 后来新手入门时,老师傅不再先讲抽象名目,而是让他们复盘那次失误:原先哪里靠直觉,第一次修补为什么不够,新的安排怎样把风险留在能检查的位置。等他们能说清这些细节,还能指出什么时候该沿用、什么时候该升级,才算真正懂了这套办法。 后来他们还把这套办法交给新人演练:先让新人按旧办法做一遍,看错误怎样出现;再按新规矩重做,看哪一步被提前拦住,哪一步留下了证据。新人若只会背名字,仍会在相似场景里乱用;只有能说出适用边界、代价和失败后的补救,才被允许独立接活。

上下文精确率

检索到的上下文片段里,有多少真正和用户问题相关。定位检索阶段的信噪比。精确率掉说明检索策略灌进了无关内容。

忠实性

模型生成的答案在多大程度上可以追溯到检索到的上下文。定位生成阶段的幻觉或自行发挥。忠实性掉说明模型没有按照证据写答案。

故事对应

  • 第一排药材:检索到的上下文片段
  • 第二排先生筛过的:经过过滤或排序的检索结果
  • 第三排方子:模型最终生成的答案
  • 第一把秤(精确率):测量检索结果和真实问题的相关度
  • 第二把秤(忠实性):测量答案是否可以从检索结果中找到依据
  • 寒症事故:精确率尚可但忠实性很差——模型没按证据生成
  • 两根管子分别走不同的药:两个指标定位不同的故障环节
  • 新规:精确率掉查检索,忠实性掉查生成

落到 RAG 评估和质量监控

搭建 RAG 系统评估体系时,不要把精确率和忠实性放在同一行看。如果用户反馈「答案不准」,先切分问题:去检索日志里查精确率,看返回的片段里有没有真正相关的信息;再去生成日志里查忠实性,看模型是否忠实地引用了那些片段。精确率优化方向是检索策略、chunk 设计和 embedding 质量;忠实性优化方向是提示词约束、输出验证和引用机制。两个指标同时低的情况通常是检索先崩了,生成接不住。