效果评测体系与 Badcase 闭环治理
就搞三层评测：离线的、在线的，再加上人工跟自动混着来的。靠数据推着模型、提示词还有 Agent 往前迭代。
- 区分离线评测与在线评测、自动与人工评测
- 掌握一套核心指标体系与评测集构建方法
- 理解 LLM-as-judge 的价值与偏差
- 形成 Badcase 分类—归因—修复—回归的闭环
无法度量，就无法改进
做AI产品别靠“我感觉变好了”拍板。概率系统必须拿评测集和指标说话：每次改模型、改提示、改检索，都得在同一套数据上做量化对比，不然很容易“修好一个、改坏三个”。
2.1 离线评测与在线评测
离线评测：上线前用固定评测集打分，快、成本低、能反复跑回归，是迭代的主阵地。在线评测：上线后用真实流量观察，包括 A/B 实验、用户反馈、业务指标，检验离线结论在真实分布下是否成立。两者缺一不可：离线分高但在线没人用，是常有的事。
2.2 一套四维指标体系
别只盯着“答得对不对”看，至少要覆盖四个维度：
效果：准确率/有用性、忠实度（有无幻觉）、完整度、格式合规率。效率：平均响应时延、首 Token 延迟、任务完成率、平均交互轮数。成本：单次 Token 与金额、日/月总成本、单位任务成本。业务：使用率、留存、满意度、人工替代率、转化率。
思考时间拉得长，准确率可能上去，但延迟和成本也跟着涨；回答给得激进，点击量可能好看，但幻觉也会变多。评测的作用就是把这些权衡摊开说，靠数据选方向，别死盯着某一个指标使劲。
2.3 评测集怎么建才靠谱
评测集得从真实分布里拿。从线上日志按场景分层抽样，要覆盖高频正常样本、边界样本和历史 Badcase。每条样本必须有明确的“标准答案或可判定标准”。集合要持续滚动更新，还要分成两部分：训练/调优可见集、最终盲测集。别搞成“对着考试题背答案”那种过拟合。
关于构建评测集，下列做法最合理的是？
2.4 LLM-as-judge：好用但要校准
用更强的模型按给定评分标准给输出批量打分，能提升评测效率。但它有已知偏差：偏好更长的回答、偏好与自己风格一致的回答、位置偏差（并列比较时偏向先/后出现的选项），还可能“自己给自己打高分”。
校准方法：评分标准尽量客观可操作；关键场景与人工评分做一致性抽检；交换候选顺序看结论是否稳定；对重要结论以人工复核兜底。
2.5 Badcase 闭环治理
把每一次线上错误变成资产，标准流程是：
收集：多渠道汇聚错误样本与用户反馈。分类归因：区分知识缺失、检索失败、推理错误、工具错误、提示歧义、合规问题。定位：结合 trace 判断错在哪一环。修复：针对性改检索/提示/工具/模型，而不是笼统“再试试”。回归：把该样本加入评测集，确保修复有效且不引入退化。
能把错误稳定归到十几个类别里，再统计出各类的占比和变化趋势，优化才不是碰运气，才算有了主攻方向。优先处理出现频率高、影响范围大的类别。
RAG 问答碰到「资料里明明有内容，生成答案却没用到」的情况，优先排查哪个环节？
资深工程师加餐
底层原理 · 大厂视角 · 工程经验，点卡片展开
答错别急着换模型。拆成两段查：检索段看 Recall@k——正确片段到底有没有被召回，没召回是切分/嵌入/混合检索的问题；生成段看「召回对了却没用好」，那是提示约束、上下文排序或模型能力问题。用同一批问题分别记录「召回命中率」和「最终答对率」，能把模糊的「效果不好」变成可对症修复的具体环节。