尧图网站建设 
上一篇讲Demo 全通了为什么一上线就答错评论区不少人问怎么量化答得好不好靠 demo 上问两个顺口的问题说还行那叫玄学。这篇给你一套能落地的做法——用 20-50 条真实业务问题当验收卷子把好不好变成三个能追的数字。一、先想清楚你要测的是哪三层一套 RAG 系统答得好不好其实由三层各自的质量叠加而成评测也得分开看否则出了问题你根本不知道锅在谁头上① 检索层 该找到的文档找回来了吗 → 召回率 / 命中率 / MRR ② 精排层 找回来的 N 条里相关的排前面了吗 → NDCG ③ 生成层 基于检索结果答对了吗、有引用吗、幻觉了吗 → 忠实度 / 正确性最容易被忽略也最致命的一点生成层再强检索层漏了关键文档它也只能一本正经地编。所以评测第一件事是先单独测检索层——不要上来就测整体答案对不对那样你分不清是没找到还是没答好。二、评测集从哪来三种来源按优先级排别一上来就想着用 AI 批量造题那是最后的手段。真实业务问题优先级永远最高# 评测集条目结构一条 一个真实业务问题 期望答案依据evaluation_set[{question:请假超过 3 天需要谁审批,# 用户真实会问的话source_doc:考勤制度_V3.docx,# 期望命中的文档检索层对账用golden_answer:3 天以上由部门负责人审批...,# 参考答案生成层对账用category:制度-考勤,# 便于按类统计},# ... 凑 20-50 条覆盖核心业务文档别只挑简单的]三种来源真实用户问题最优先——从客服聊天、搜索日志、内部问答记录里捞。没人问过的问题测了也没意义。业务专家口述——找几个核心业务骨干让他们把日常最常被问到的问题丢出来。AI 辅助扩写兜底——拿已有文档让大模型出题但要人工逐条校验AI 出的题常有问得不像人话或答案在文档里根本找不到的硬伤。一个坑别把会不会答当成评测目标——评测目标是答得对不对、能不能溯源。所以每条必须带source_doc否则检索层完全没法量化。三、跑起来检索层评测能直接抄先测该找的文档找回来了没。把每条问题的期望source_doc和实际召回的前 N 条比对defeval_retrieval(rag_retrieve_fn,evaluation_set,top_k5):rag_retrieve_fn(question) - [doc_id, ...] 按相关性排序hit0;mrr0.0foriteminevaluation_set:expecteditem[source_doc]retrievedrag_retrieve_fn(item[question])[:top_k]ifexpectedinretrieved:hit1mrr1.0/(retrieved.index(expected)1)# 排得越前分越高nlen(evaluation_set)return{命中率(Recall5):round(hit/n*100,1),# 找到关键文档的比例MRR:round(mrr/n,3),# 排名的平均倒数}命中率低 → 去查解析层/切分是不是扫描件没转文字、长文档被切碎导致语义断了命中率够但 MRR 低 → 去调 Rerank / 阈值。两层问题处理方式完全不同这就是分指标的价值。四、生成层用忠实度卡住幻觉很多团队卡在参考答案没法穷尽——同一问题答案可能多种表述都对。所以生成层别死磕和参考答案一字不差用忠实度faithfulness更实用检查 LLM 的答案是否都能从它引用的检索上下文里找到依据不许自由发挥。可以用一个独立的裁判模型来做避免用同一个模型既答又判fromopenaiimportOpenAI judgeOpenAI(api_keyos.getenv(JUDGE_KEY),# 建议用一个独立/更强的模型当裁判base_urlhttps://dashscope.aliyuncs.com/compatible-mode/v1)defcheck_faithfulness(question,answer,context):promptf你是严谨的质检员。判断【答案】里的每个论断是否都能从【参考上下文】中找到依据。 只回两个字忠实 或 幻觉。 参考上下文{context}问题{question}答案{answer}respjudge.chat.completions.create(modelqwen-max,messages[{role:user,content:prompt}],temperature0,max_tokens8)returnresp.choices[0].message.content.strip()跑完 50 条统计忠实占比 忠实度。若低于九成说明 LLM 在脱离资料编造——大概率是你 prompt 里只许基于资料回答的约束没锁死或检索到的上下文本身是错的。五、上线后不是终点评测集要活起来这是最容易翻车的一层——评测集建完就扔仓库吃灰 白建。它必须跟着业务跑每次改动都回归换 embedding 模型、调切分大小、改 Rerank、换主模型……任何改动前先跑一遍评测集拿基线对比别用感觉变好了当结论。改一次跑一次哪怕只跑 50 条一次 API 成本也就几块钱比上线后翻车便宜太多。持续补坏例线上答错的真实问题沉淀进评测集。评测集的价值会随你踩的坑一起涨。按类看趋势按category分组统计你会发现制度类总答错——那不是单个问题是某个文档解析/切分有系统性问题。一句话总结上线前不建评测集等于拿整个业务当 beta 测试。三层分开测检索召回 → 精排 → 生成忠实评测集取自真实业务并持续回归你才能理直气壮地说这套能上线。如果你已经在跑企业知识库、卡在怎么证明它答得好、怎么持续不出错欢迎评论区聊聊你踩的坑——评测集只是第一道门槛后面上线三个月怎么让它越用越准、不变成僵尸库才是真正的硬仗。 企业知识库上线前，别靠“感觉还行“：手把手搭一套 RAG 评测集
上一篇讲Demo 全通了为什么一上线就答错评论区不少人问怎么量化答得好不好靠 demo 上问两个顺口的问题说还行那叫玄学。这篇给你一套能落地的做法——用 20-50 条真实业务问题当验收卷子把好不好变成三个能追的数字。一、先想清楚你要测的是哪三层一套 RAG 系统答得好不好其实由三层各自的质量叠加而成评测也得分开看否则出了问题你根本不知道锅在谁头上① 检索层 该找到的文档找回来了吗 → 召回率 / 命中率 / MRR ② 精排层 找回来的 N 条里相关的排前面了吗 → NDCG ③ 生成层 基于检索结果答对了吗、有引用吗、幻觉了吗 → 忠实度 / 正确性最容易被忽略也最致命的一点生成层再强检索层漏了关键文档它也只能一本正经地编。所以评测第一件事是先单独测检索层——不要上来就测整体答案对不对那样你分不清是没找到还是没答好。二、评测集从哪来三种来源按优先级排别一上来就想着用 AI 批量造题那是最后的手段。真实业务问题优先级永远最高# 评测集条目结构一条 一个真实业务问题 期望答案依据evaluation_set[{question:请假超过 3 天需要谁审批,# 用户真实会问的话source_doc:考勤制度_V3.docx,# 期望命中的文档检索层对账用golden_answer:3 天以上由部门负责人审批...,# 参考答案生成层对账用category:制度-考勤,# 便于按类统计},# ... 凑 20-50 条覆盖核心业务文档别只挑简单的]三种来源真实用户问题最优先——从客服聊天、搜索日志、内部问答记录里捞。没人问过的问题测了也没意义。业务专家口述——找几个核心业务骨干让他们把日常最常被问到的问题丢出来。AI 辅助扩写兜底——拿已有文档让大模型出题但要人工逐条校验AI 出的题常有问得不像人话或答案在文档里根本找不到的硬伤。一个坑别把会不会答当成评测目标——评测目标是答得对不对、能不能溯源。所以每条必须带source_doc否则检索层完全没法量化。三、跑起来检索层评测能直接抄先测该找的文档找回来了没。把每条问题的期望source_doc和实际召回的前 N 条比对defeval_retrieval(rag_retrieve_fn,evaluation_set,top_k5):rag_retrieve_fn(question) - [doc_id, ...] 按相关性排序hit0;mrr0.0foriteminevaluation_set:expecteditem[source_doc]retrievedrag_retrieve_fn(item[question])[:top_k]ifexpectedinretrieved:hit1mrr1.0/(retrieved.index(expected)1)# 排得越前分越高nlen(evaluation_set)return{命中率(Recall5):round(hit/n*100,1),# 找到关键文档的比例MRR:round(mrr/n,3),# 排名的平均倒数}命中率低 → 去查解析层/切分是不是扫描件没转文字、长文档被切碎导致语义断了命中率够但 MRR 低 → 去调 Rerank / 阈值。两层问题处理方式完全不同这就是分指标的价值。四、生成层用忠实度卡住幻觉很多团队卡在参考答案没法穷尽——同一问题答案可能多种表述都对。所以生成层别死磕和参考答案一字不差用忠实度faithfulness更实用检查 LLM 的答案是否都能从它引用的检索上下文里找到依据不许自由发挥。可以用一个独立的裁判模型来做避免用同一个模型既答又判fromopenaiimportOpenAI judgeOpenAI(api_keyos.getenv(JUDGE_KEY),# 建议用一个独立/更强的模型当裁判base_urlhttps://dashscope.aliyuncs.com/compatible-mode/v1)defcheck_faithfulness(question,answer,context):promptf你是严谨的质检员。判断【答案】里的每个论断是否都能从【参考上下文】中找到依据。 只回两个字忠实 或 幻觉。 参考上下文{context}问题{question}答案{answer}respjudge.chat.completions.create(modelqwen-max,messages[{role:user,content:prompt}],temperature0,max_tokens8)returnresp.choices[0].message.content.strip()跑完 50 条统计忠实占比 忠实度。若低于九成说明 LLM 在脱离资料编造——大概率是你 prompt 里只许基于资料回答的约束没锁死或检索到的上下文本身是错的。五、上线后不是终点评测集要活起来这是最容易翻车的一层——评测集建完就扔仓库吃灰 白建。它必须跟着业务跑每次改动都回归换 embedding 模型、调切分大小、改 Rerank、换主模型……任何改动前先跑一遍评测集拿基线对比别用感觉变好了当结论。改一次跑一次哪怕只跑 50 条一次 API 成本也就几块钱比上线后翻车便宜太多。持续补坏例线上答错的真实问题沉淀进评测集。评测集的价值会随你踩的坑一起涨。按类看趋势按category分组统计你会发现制度类总答错——那不是单个问题是某个文档解析/切分有系统性问题。一句话总结上线前不建评测集等于拿整个业务当 beta 测试。三层分开测检索召回 → 精排 → 生成忠实评测集取自真实业务并持续回归你才能理直气壮地说这套能上线。如果你已经在跑企业知识库、卡在怎么证明它答得好、怎么持续不出错欢迎评论区聊聊你踩的坑——评测集只是第一道门槛后面上线三个月怎么让它越用越准、不变成僵尸库才是真正的硬仗。