SH

Soloharness

概念 · 辨析 · Agent

← 返回概念辨析

Concept Contrast Fable

检索精确率和上下文精确率

检索精确率衡量召回的文档里有多少是相关的。上下文精确率衡量最终喂给大模型的那段文本里有多少是有用的。中间隔着一道重新整理和截断,两个数经常不一致。

寓言

仓库拣货和厨房备菜

城北有一家高档餐厅,名气靠的是一道招牌菜。后厨的流程是这样的:服务员把客人点单送进厨房,配菜员去仓库取食材,交给厨师。厨师拿到食材后,择菜、清洗、切配、下锅。

有一段时间,投诉率突然上升。客人说菜里有沙子,或者配菜不新鲜。老板查监控,发现仓库拣货没问题——配菜员从仓库拿回来的食材,八成都跟菜单对得上。仓库的正确率是够的。

问题出在厨房的操作台上。厨师拿到食材后,没有逐件检查,一股脑全倒进了筐里。烂叶子没择,带泥的根没切,过期的调料没闻。从仓库到锅里的那一步,食材被污染了。

老板想了很久,给流程加了一个新岗位:备菜检查员。这个人的工作台就卡在仓库出口和灶台入口之间,接过配菜员拿回的食材,把烂叶子摘掉,把带泥的根切掉,把重复的材料合并,把过期的调料挑出来扔掉,最后把一份分门别类、干干净净的备菜篮交到厨师手里。

加了这一步以后,老板开始看两个指标。一个是仓库拣货正确率:从仓库拿回来的食材里,有多少是菜单上确实需要的。另一个是备菜篮可用率:最后交到厨师手里的食材里,有多少是可以直接下锅的。

半年下来,老板发现一个规律:仓库拣货正确率维持在 85% 左右,但备菜篮可用率可以做到 95%。因为备菜检查员懂得扔掉明显不对的东西、合并重复材料、补充遗漏的调料、把不新鲜的部位切掉。仓库的数据是一回事,备菜篮的数据是另一回事。

后来老板跟同行分享经验:不要只看仓库的数字漂亮不漂亮。客人吃进嘴里的是备菜篮,不是仓库入库单。

后来馆员加了一道关:先看找回来的书准不准,再看送进案头的页干不干净。两处筛子终于分开。 后来馆员每次复盘都标两处红印:一处贴在书架检索,一处贴在案头材料。问题从此有了落点。

检索精确率 (Retrieval Precision)

检索阶段返回的文档中,与查询真正相关的比例。它衡量的是「从仓库拿回来的东西对不对」。

上下文精确率 (Context Precision)

最终组装进提示上下文的文本中,对生成答案真正有用的比例。它衡量的是「大模型看到的东西有没有用」,中间经过了去重、截断、重排等后处理。

故事对应

  • 仓库拣货:检索阶段,从文档库中召回相关文档。
  • 配菜员拿回的食材:检索结果(原始召回的文档列表)。
  • 备菜检查员(择菜、清洗、切配):上下文后处理——去重、截断、重排、过滤。
  • 备菜篮:最终送入大模型的上下文片段。
  • 客人投诉菜里有沙子:上下文精确率低,即使检索精确率不差,最终生成质量仍然受损。

落到项目里

RAG 系统上线前,两个指标都要测。检索精确率低,说明检索策略有问题,需要调 embedding 或检索参数。检索精确率高但上下文精确率低,说明后处理链路在丢信息或引入噪声——可能是截断策略不合理、文档排序被打乱、或者重复内容占满了上下文窗口。很多团队只看检索精确率就宣布「RAG 准确率 90%」,上线后被用户骂,原因就在这里。