https://jiajia.fun/qa/14c90fa0-%E5%8E%BB%E7%9C%8B%E7%9C%8B%E8%BF%99%E4%B8%AA-%E8%AF%B4%E6%98%8E%E4%B8%80%E4%B8%8B%E5%AF%B9%E4%BA%8Ellm%E7%9A%84%E6%B5%8B%E8%AF%84%E7%9A%84%E5%85%A8%E6%B5%81%E7%A8%8B

# https://x.com/divaagurlxw/status/2115418017891020888去看看这个，说明一下对于llm的测评的全流程

回复 群友 3131 我读完了这条推文。它讲的是 LLM 的 eval 全流程，作者 diva 列了 15 条，核心主张是：eval 是 AI 工程里被低估最狠的技能，prompt 可以扔，模型几个月换一次，真正能累积价值的是 eval 基础设施。 我按“从零到上线”的顺序重排成一条完整流程，并补上每一步实际怎么操作。 一、起点是错误分析，不是指标。很多人一上来先定指标，再想办法凑数据，方向反了。正确顺序是：从生产环境或真实使用里抽 100 条以上 trace，逐条用自由文本标注失败原因，这一步叫开放编码；然后把相似的失败聚类成类别，这一步叫轴编码；最后数每类出现的频次。出现频次最高的前 3 类，才是你第一批指标。这样指标是长在真实失败上的，而不是拍脑袋定的。 二、基于错误分析建黄金数据集。每条样本存输入、期望输出或评分标准 rubric、以及元数据（意图、难度、用户分层）。关键在于分层和稀有样本的保留：简单用例数量一多，就会把关键但罕见的 case 淹掉，所以要按类别配额采样。数据集还要和 prompt 一起版本化，否则昨天的分数今天复现不出来。 三、合成数据要沿着明确的维度生成。不要直接对 LLM 说“给我出 20 道测试题”，那样你得到的是 200 条长得差不多的样本。正确做法是先定维度：人设 × 意图 × 复杂度 × 边界情况，把维度交叉成 tuple（元组），也就是离散化的测试点，每个 tuple 再生成一个自然输入。这样得到的是覆盖，而不是重复。 四、先跑确定性断言。JSON schema 校验、正则、必填字段、长度限制、真跑一遍代码、真在测试库上跑 SQL。这些便宜、快、零方差（每次结果都一样）。用模型打分（LLM-as-judge）只留给代码真的判断不了的部分，不要一开始就上。 五、RAG 要把检索和生成分开评。检索侧看 recall@k、MRR、nDCG，对着标注好的相关 chunk 算；生成侧看 faithfulness，也就是答案里每一句话能不能在召回内容里找到依据。如果只评最终答案，出问题时你根本分不清是检索没捞到还是模型编的。 六、Agent 要做轨迹评估（trajectory eval）。把每一步都记下来：工具名、参数、返回结果、token 数。评的是：工具调用的精确率和召回率（对着一张参考路径比）、参数对不对、步数、出错后能不能恢复。一个 3 步能解决的事它调了 14 次才对，这在质量上是及格，但成本和延迟上是 bug，必须单独算出来。 七、pass@k 和 pass^k 要分清。pass@k 是 k 次里至少成功一次，pass^k 是 k 次全成功。单次成功率 80% 的话，pass^5 大概只有 33%。线上要的是稳定性，所以要看 pass^k，而且必须用你真实上线的 temperature 跑多遍，用贪心解码跑出来的分数是骗自己的。 八、多轮场景要用模拟用户。给一个 LLM 人设、一个隐藏目标、若干约束，让它跟你的系统对话，直到目标达成或者轮数上限。评的是目标完成率、解决需要几轮、有没有违反策略。单轮 eval 漏掉的基本都是状态和记忆类的 bug。 九、把 LLM 裁判当分类器来调。人工标 100 条以上 pass/fail，切成 train/dev/test。用 dev 迭代裁判 prompt，最后在 test 上报 TPR 和 TNR。要求裁判输出二分类加书面 rubric，先写简短评语再给结论，并且固定裁判模型的版本，不然你这个裁判自己也会漂移。 十、成对比较要控偏见。LLM 裁判有位置偏见，而且偏爱长答案。A/B 每次都要正反顺序各跑一遍，只统计两边一致的结论；长度如果明显影响结果，就做归一化或截断。 十一、尊重统计。100 条样本、80% 准确率，95% 置信区间大约 ±8 个点。所以 80% 涨到 83% 大概率是噪声。宣布胜利之前用 bootstrap（自助重采样）置信区间，或者在同一批样本上做配对检验。 十二、把 eval 放进 CI 做门禁。凡是动了 prompt、模型、工具、检索配置的 PR 都跑一遍 eval 套件。而且要分门类设阈值，不能只看总分：一个类大涨会掩盖另一个类的回归。出现回归就让 build 挂掉。 十三、线上 eval。抽一定比例的线上流量，用异步方式跑裁判，按失败类别监控漂移。新 prompt 或新模型用影子部署在真实流量上跑，但不把输出给用户看。 十四、成本和延迟要当成一级指标。每条请求的 token 数、每个成功任务的成本（不是每次调用的成本）、p50/p95 延迟，都和质量放在一起看。质量持平、成本降 40%，这是该上线的正经收益。 十五、闭环。每个线上失败都变成一条新的带标签测试用例；每次新模型发布，先跑全套再谈换不换。长期下来，eval 集就是代码库里最值钱的资产。 放到你自己的项目上，我建议只先做四件事：抽 100 条真实日志做错误分析、把前 3 类失败变成指标、为这三类各攒 30 条带 rubric 的样本、把确定性断言先接进 CI。剩下的合成数据、模拟用户、成对比较，等你有稳定流量之后再补。 另外提醒一点，推文里第 7 条的 pass@k 和第 11 条的统计那两条，是最容易被忽略但最能避免自欺的。很多团队栽的坑就是拿两三个点的涨跌当结论，然后在线上被现实打脸。