评测是 AI 工程里最被低估的一项技能

评测是 AI 工程里最被低估的一项技能。 从错误分析入手，而不是从指标入手 抽取 100 条以上的生产环境 trace 样本。用自由文本给每个失败案例做标注（开放式编码），再把它们聚类成失败类别（轴心编码）。统计每个类别的出现频次。频次最高的前 3 个类别，就是你的第一批指标。 构建带版本的金标准数据集 把输入、期望输出或评分标准，以及元数据（意图、难度、用户分层）都存进一个带版本的数据集里。要做分层，别让简单用例把稀有但关键的用例淹没掉。让它和你的提示词一起做版本管理，这样每个分数都可复现。 按明确的维度生成合成数据 别只是让 LLM 出「测试题」。先定义维度（人设 × 意图 × 复杂度 × 边界情况），把各种组合生成成元组，再把每个元组转成一条自然的输入。这样你拿到的是覆盖面，而不是 200 条几乎雷同的样例。 先做确定性断言 JSON schema 校验、正则检查、必填字段、长度限制、代码执行、真正跑在测试库上的 SQL。这些手段便宜、快，而且零方差。把基于模型的评分留给代码确实查不了的部分。 把检索和生成分开评估 做 RAG 时，检索环节用 recall@k、MRR 或 nDCG 对照标注好的相关分块来衡量。生成环节用忠实度来衡量（每一条论断是否都有检索到的上下文支撑？）。如果只给最终答案打分，你就分不清是哪一半出了问题。 智能体的轨迹评估 把每一步都记下来：工具名、参数、结果、token 数。对照参考路径给工具调用的精确率和召回率打分，还要看参数是否正确、步数多少、出错后能否恢复。本来 3 次调用就能搞定的事，智能体却用了 14 次才拿到正确答案，这就是成本和延迟上的 bug。 pass@k 与 pass^k pass@k 指 k 次运行中至少成功一次。pass^k 指 k 次运行全部成功。单次成功率 80% 时，pass^5 会掉到大约 33%。生产环境的可靠性看的是 pass^k，所以要按你实际使用的 temperature 把每个用例多跑几遍。 为多轮对话模拟用户 给 LLM 一个人设、一个隐藏目标以及若干约束条件，然后让它与你的系统对话，直到目标达成或触及轮次上限。评估目标完成情况、解决所需轮次以及策略违规次数。单轮评测会漏掉大部分状态与记忆相关的 bug。 像训练分类器一样校准你的 LLM 评审器 人工标注 100 条以上样本，标成通过或失败。再切分为训练集、开发集、测试集。用开发集反复迭代评审提示词，然后在测试集上报告 TPR 与 TNR。输出采用二分类结果并配上书面评分标准，要求评审器在给出结论前先写一段简短评述，同时锁定评审模型的版本。 控制成对比较中的评审偏差 LLM 评审器存在位置偏差，而且往往偏爱更长的回答。每个 A/B 对比都交换顺序跑两遍，只统计结论一致的判定。如果啰嗦程度在影响结果，就对长度做归一化或设上限。 尊重统计规律 在 100 个样本、准确率 80% 的情况下，你的置信区间约为 ±8 个百分点，置信水平为 95%。从 80% 涨到 83%，很可能只是噪声。在宣布某项改进胜出之前，请使用自助法置信区间，或在同一批样本上做配对检验。 在 CI 中设置部署门禁 凡是改动提示词、模型、工具或检索配置的 PR，都要跑一遍评测套件。按类别分别设置阈值，而不是只用一个全局分数，这样某个类别的大幅提升就掩盖不了另一个类别的退化。一旦出现退化，就让构建失败。 生产环境中的在线评测 抽取一定比例的线上流量，异步运行你的评判器，并按失败类别对漂移告警。用影子部署让新的提示词或模型跑在真实流量上，但不把输出展示给用户。 把成本和延迟当作一等指标来跟踪 跟踪每次请求的 token 数、每个成功任务（而不是每次调用）的成本，以及 p50/p95 延迟，并与质量指标并列来看。一项改动如果能让质量保持不变、同时把成本降低 40%，那就是实打实的收益，值得上线。 提示词是一次性的，模型每隔几个月就会被换掉。 真正能形成复利的是你的评测基础设施。