月满楼是城里有名的老字号，大厨小盏最近接了个大活：研发一道新招牌菜“AI红烧肉”。她没有像以前那样把菜直接写上菜单，而是定了“三道验收关”：先在后厨闭门试做，对照《品鉴标准手册》打分；再请几位老熟客免费试吃，躲在帘子后悄悄记下他们夹了几筷子、皱没皱眉；最后把老方子与新方子做成双菜单，对比翻台率、复购率与好评率，让数据说话。全程她还盯着两件事：高汤用了几勺（成本）？火警铃有没有响（异常）？这套流程，就是 AI 产品上线时著名的“评测驱动的迭代（离线→在线→AB）”策略：先用离线评测低成本筛掉坏版本，再用影子模式与灰度发布在真实环境小范围验证，最后用 AB 实验科学决策，配上成本控制与告警回滚，让产品稳稳上线、越转越好。

岗位关联

学完本文，你就掌握了 AI 产品上线迭代的“守门人”技能：用分层评测与数据证据做每一次决策，而不是靠感觉上线、靠运气兜底——这是 AI 产品经理与相关工程师的核心竞争力。

目录
  1. 可视化演示
  2. 评测体系搭建：先定《品鉴标准手册》
  3. 离线评测方法：厨房闭门试做
  4. 在线评测实践：请熟客影子试吃
  5. AB实验设计：双菜单的科学对决
  6. 反馈闭环机制：意见簿别撕掉
  7. 成本控制策略：高汤要省着用
  8. 运维告警保障：火警铃一响先关火
  9. AI 应用场景
  10. Python 演示
  11. 常见误区
  12. 面试题

可视化演示

动态演示AI产品上线的核心机制，通过概览/流程/对比/趋势四种模式展示关键概念与交互流程。

本节配有交互动效（进入视口后自动加载，约 3KB）。

AI产品上线：一离线评 一、离线评测体系构建方法 二、在线监控指标设计 核心机制可视化 AI产品上线整体架构与关键组件

评测体系搭建：先定《品鉴标准手册》

小盏的第一件事不是买肉，而是召集三位资深食评人闭门三天，定出一本《品鉴标准手册》：“色、香、味、形、器”五项，每项 0-10 分，权重分别定为 0.1、0.2、0.4、0.2、0.1。没有这本手册，试菜就会变成吵架——大厨说“入口即化”，食客说“太腻了”，谁也说服不了谁。

换成 AI 术语，“品鉴标准手册”就是评测体系，它由三块组成：评测指标定义、评测数据集构建、基准线设定。指标定义解决“什么叫好回答”，比如智能客服的准确率、转人工率、响应时长；数据集是带标准答案的“黄金样本集”，相当于用来对比的标准食材；基准线则是当前线上版本或行业标杆的得分，是“及格线”。

指标不能只有一个。客服只追准确率，模型可能为了不得罪用户而答得模棱两可；只追转人工率，模型可能把一切甩给人工。所以要用加权综合得分，把多个指标揉成一个分。权重设计要贴近业务：回答准确性权重最高，礼貌用语这种锦上添花的指标权重就给低一点。

有了《品鉴标准手册》，厨房里的每一次试做都有了共同的尺子。AI 产品也一样：评测体系就是团队对“好”的共识，没有共识，后面所有迭代都会变成各说各话。

S=∑j=1kwjsj\displaystyle S = \sum_{j=1}^{k} w_j s_j
加权综合得分公式：把每项指标得分乘上自己的权重，再全部加起来，得到一个可对比的总分。
  1. $s_j$ 指标得分第 $j$ 项指标的打分，例如“回答准确率得 8 分”。
    sjs_j
  2. $w_j$ 指标权重第 $j$ 项指标的比重，体现它在业务里的重要程度。
    wjw_j
  3. 加权累加把 $k$ 项的得分与权重相乘后逐项相加，得到总分。
    ∑j=1kwjsj\sum_{j=1}^{k} w_j s_j
  4. $S$ 综合得分最终得分，只有不低于基准线的新版本才允许进入下一步。
    SS

离线评测方法：厨房闭门试做

手册定好了，小盏开始闭门试做。这两天大门紧闭，客人一个都不见。她每做一版，先自己用尺子量色泽、用温度计测火候——这是“规则评测”；再请隔壁退休老师傅咬一口打分——这是“人工标注”；最后把三份样品送给食评人各打一个分取均值——这是“模型打分”。

离线评测，就是在发布前用固定数据集对模型打分，成本低、可重复、速度快。规则评测用正则、关键词匹配等硬规则检查输出格式与禁区词；模型打分（也叫 LLM-as-judge）让大模型当裁判，按评分标准给开放域答案打分；人工标注则按标注规范逐条打分，准确但贵，适合抽样打地基。

衡量离线表现最基础的指标是准确率：把模型的预测和标准答案逐条比对，算一算对的占比。

离线评测就像模拟考：题目固定、答案已知、随时能重考。模拟考都拿不到 90 分的菜，绝不该端给熟客——因为厨房里返工的成本最低，翻车代价最小。这就是“先离线、后在线”的第一道闸门。

Acc=1N∑i=1N1[yi=y^i]\displaystyle \text{Acc} = \frac{1}{N} \sum_{i=1}^{N} \mathbb{1}\left[ y_i = \hat{y}_i \right]
准确率公式：在 $N$ 条样本中，预测与真实标签一致的比例，指示函数相等取 1、否则取 0。
  1. $y_i$ 真实标签第 $i$ 条样本的标准答案。
    yiy_i
  2. $\hat{y}_i$ 模型预测模型给出的预测结果。
    y^i\hat{y}_i
  3. 指示函数括号内成立计 1，不成立计 0，用来“数对错”。
    1[⋅]\mathbb{1}[\cdot]
  4. 求平均把 $N$ 条样本的命中数加起来再除以 $N$，得到 0 到 1 之间的准确率。
    1N∑i=1N\frac{1}{N} \sum_{i=1}^{N}

在线评测实践：请熟客影子试吃

试做版拿了 92 分，小盏决定请熟客试吃。她挑了常来的 20 桌老客，菜单上悄悄把“AI红烧肉”写成“时令新菜”，不收钱——这就是“影子模式”。她躲在帘子后面记录：这道菜被夹了几次？剩了多少？有没有人皱眉？——这是“日志埋点”。而且只给 1 号桌区域供应，其余桌仍是老菜单——这是“灰度发布”。

在线评测，就是真实流量下的小范围验证。影子模式让新模型在旁路“模拟答题”，并不真正返回给用户，只记录“如果用它回答，结果是否合理”，再和线上答案做一致性比对，零风险；灰度发布把一小部分真实用户流量切给新模型，让模型见见真正的用户；日志埋点则是在入口出口埋下行为日志，采集用户反馈与模型输出。

在线阶段最关心“真实用户买不买账”，核心指标是好评率（或复购率、点赞率）。

熟客试吃的价值在于“真实体验”：菜端上桌才发现凉得快、火候刚好但份量太少——这些是厨房模拟不出来的。AI 产品的真实问法、网络延迟、并发高峰，同样只有小流量上真环境才暴露得出来。

p^=NpositiveNtotal\displaystyle \hat{p} = \frac{N_{\text{positive}}}{N_{\text{total}}}
好评率公式：好评次数占总样本数的比例，是对真实体验的一种朴素估计。
  1. $N_{\text{positive}}$ 好评次数窗口期内用户给出正向反馈的次数。
    NpositiveN_{\text{positive}}
  2. $N_{\text{total}}$ 总样本数窗口期内全部交互次数。
    NtotalN_{\text{total}}
  3. $\hat{p}$ 好评率估计两者相除，得到好评率，越接近 1 表示体验越好。
    p^\hat{p}

AB实验设计：双菜单的科学对决

试吃反馈不错，小盏却还不急着全面换菜单。她把这道菜做成两个版本：老方子和新方子，前两周 A 桌端老方子、B 桌端新方子，随机分配互不干扰——这是“流量分桶”。两周后一算：新方子好评率 68%，老方子 65%——这 3 个点到底是真的还是运气？

这正是 AB 实验要回答的问题。AB 实验把流量随机分成对照组与实验组，只有随机分桶，两组才有可比性。但看到差值不能直接下结论，要用假设检验计算 Z 值，判断这 3% 有没有可能是随机波动造成的。

双菜单对比不是投票，而是统计裁判吹哨。Z 值就是哨声——响了，才准换菜单；没响，新菜回炉继续改。AB 实验是整套流程里最贵的一关，因此也成了“最后一道验收关”。

Z=p^A−p^Bp^(1−p^)(1nA+1nB)\displaystyle Z = \frac{\hat{p}_A - \hat{p}_B}{\sqrt{\hat{p}(1-\hat{p})\left(\frac{1}{n_A}+\frac{1}{n_B}\right)}}
Z 检验公式：用组间差异除以合并标准误，得到 Z 值。Z 的绝对值超过 1.96，就认为差异在 95% 置信水平下显著。
  1. $\hat{p}_A - \hat{p}_B$ 组间差异实验组与对照组好评率之差，是我们要验证的“效果”。
    p^A−p^B\hat{p}_A - \hat{p}_B
  2. $\hat{p}$ 合并比例把两组样本合在一起估计总体比例，是标准误的输入。
    p^\hat{p}
  3. 合并标准误度量“这个差值本身可能有多大波动”，样本量越大，波动越小。
    p^(1−p^)(1nA+1nB)\sqrt{\hat{p}(1-\hat{p})\left(\frac{1}{n_A}+\frac{1}{n_B}\right)}
  4. $Z$ 检验统计量差值相对波动的倍数。|Z| > 1.96 时拒绝“纯属运气”的原假设。
    ZZ

反馈闭环机制：意见簿别撕掉

新菜上市后，小盏没有收工。她在每桌放了一本意见簿，小二每晚把留言归类：3 条“太咸”、5 条“不够辣”、2 条“上菜太慢”——这是“归因分析”。每周一她拿着本子微调菜谱，下一轮重新闭门试做——这是“迭代更新”。如此循环，菜越做越稳。

反馈闭环，就是收集 → 归因 → 迭代 → 再评测。收集环节来自 App 里的点赞、点踩、转人工、举报；归因环节把问题分成“理解错了、检索漏了、生成幻觉、交互设计有问题”四类；迭代环节对应改 prompt、调 RAG、微调模型或改界面。每次修复后都要用离线评测回归，防止修了东墙塌了西墙。

闭环是否高效，用闭环率来衡量：已经修好的问题占发现问题的比例。

意见簿不撕掉才有价值。闭环率就是“订正错题”的速度——卷子上的错题，改对了才算数。AI 产品不是一次性交付的“菜”，而是持续迭代的“菜谱”。

Cloop=NfixedNfound\displaystyle C_{\text{loop}} = \frac{N_{\text{fixed}}}{N_{\text{found}}}
闭环率公式：已修复问题数除以发现问题数，反映“从发现到修复”的周转效率。
  1. $N_{\text{found}}$ 发现问题数评测与反馈中累计发现的问题总量。
    NfoundN_{\text{found}}
  2. $N_{\text{fixed}}$ 已修复问题数其中已完成修复并通过回归的问题量。
    NfixedN_{\text{fixed}}
  3. $C_{\text{loop}}$ 闭环率两者相除，越接近 1 说明团队把问题“消化”得越干净。
    CloopC_{\text{loop}}

成本控制策略：高汤要省着用

餐厅算账发现，AI 红烧肉最烧钱的不是肉，而是每天现熬的高汤——每做一锅都耗尽大量食材，相当于大模型每次调用都在烧 token 钱。小盏用三招控成本：高汤底料从 12 味减到 8 味——“提示词压缩”；中午多熬的高汤冷藏备用——“结果缓存”；高汤用完时用骨汤顶替，口感差一点但客人基本吃不出——“降级方案”。

要理解成本，先看大模型的计费方式：每次调用按 token 收费，输入输出都花钱，请求量一大就是可观的数字。

大厨省下的每一勺高汤，最终都变成新菜长期供应的底气。token 成本直接决定迭代频次与毛利——不控制成本的 AI 产品，测试越跑越穷，迭代中途可能断粮。

C=∑i=1M(Niin×pin+Niout×pout)\displaystyle C = \sum_{i=1}^{M} \left( N_i^{\text{in}} \times p_{\text{in}} + N_i^{\text{out}} \times p_{\text{out}} \right)
token 成本公式：对每次调用，输入 token 数乘输入单价、输出 token 数乘输出单价，再全部累加。
  1. $N_i^{\text{in}}$ 输入 token 数第 $i$ 次请求发给模型的文本量。
    NiinN_i^{\text{in}}
  2. $p_{\text{in}}$ 输入单价每千 token 的输入价格。
    pinp_{\text{in}}
  3. $N_i^{\text{out}}$ 输出 token 数模型生成回复的文本量。
    NioutN_i^{\text{out}}
  4. $p_{\text{out}}$ 输出单价每千 token 的输出价格，通常比输入贵。
    poutp_{\text{out}}
  5. 累加求和把 $M$ 次调用的成本加起来，就是总账单。
    ∑i=1M\sum_{i=1}^{M}

运维告警保障：火警铃一响先关火

餐厅后厨装了三样东西：油烟报警器——错误率骤升时响铃；出菜计时器——响应超时提醒；冰柜温度计——服务不可用提示。一天傍晚，出菜平均时长从 3 分钟飙到 12 分钟，火警铃骤然响起。小盏没有先查是哪口锅出了问题，而是第一时间让后厨停火——先回滚，再排查。

运维告警是产品上线后的最后防线。监控指标包括错误率、时延、超时率、token 消耗速率与成本异常；告警机制用统计窗口定义“异常”，例如最近 1 分钟错误率超过 5% 即触发告警。

火警铃的意义不是消灭火灾，而是把火灾损失压到最小。AI 产品上线后，回滚就是最粗的那根灭火器——练熟它，团队才敢大胆向前迭代。

p^err=EN>θ⇒告警\displaystyle \hat{p}_{\text{err}} = \frac{E}{N} > \theta \Rightarrow \text{告警}
告警阈值公式：窗口内错误数与请求总数之比超过预设阈值 $\theta$，就触发告警。
  1. $E$ 错误请求数窗口期内出错（超时、5xx、空回复等）的请求数量。
    EE
  2. $N$ 请求总数同一窗口内的全部请求数量。
    NN
  3. $\hat{p}_{\text{err}}$ 错误率两者相除，得出窗口内的错误率估计。
    p^err\hat{p}_{\text{err}}
  4. $\theta$ 告警阈值业务能容忍的错误率上限，超过即判定异常。
    θ\theta

AI 应用场景

智能客服机器人上线三步走

阶段：离线评测 → 在线评测 → AB实验

解决的问题：传统做法是模型训好直接全量上线，遇到大促流量瞬间翻车。评测驱动迭代先用历史工单离线打分，把明显更差的版本挡在门外；再用影子模式在线上旁路验证一致性；最后用 AB 实验以转人工率等指标做决策。

具体案例：某电商平台上线新版客服机器人前，用 1 万条历史工单评测，准确率 92% 达标；接着灰度 5% 流量跑影子模式 3 天，发现“多轮追问”场景一致性仅 71%，修正后重测；AB 实验一周，实验组转人工率比对照组低 18%，差异显著，随后分三批全量，全程零事故。

内容审核模型的周迭代闭环

阶段：反馈闭环 + 离线评测

解决的问题：内容审核模型误杀率居高不下、用户申诉堆成山，根因是缺乏“意见簿”——申诉数据没有回流成评测样本。

具体案例：某 UGC 社区把用户申诉按“误杀/漏放”归因，每周抽取 500 条进入评测集，回归测试后重新发布。迭代 10 周，误杀率从 8% 降到 2%，申诉处理时长缩短一半。

LLM 应用的“火警”告警与回滚

阶段：运维告警保障

解决的问题：大模型服务抖动时靠人盯监控根本来不及，错误率骤升时用户已经在社交平台开骂。

具体案例：某 SaaS 公司为 AI 助手设置“1 分钟内错误率 > 5% 自动告警”与“成本日增速 > 20% 预警”，触发后自动切流回滚到上一稳定版本，并开启缓存保护。一次模型服务商上游故障中，公司 3 分钟完成回滚，受影响用户控制在数千人以内。

Python 演示

python62 行
import randomimport math  def offline_eval(predictions, labels):    # 离线评测: 计算准确率    correct = sum(1 for p, l in zip(predictions, labels) if p == l)    return correct / len(labels)  def shadow_consistency(new_outputs, old_outputs):    # 在线评测: 影子模式一致性率    n = len(new_outputs)    hit = sum(1 for a, b in zip(new_outputs, old_outputs) if a == b)    return hit / n  def z_test(pA, nA, pB, nB):    # AB实验: 双样本比例Z检验    p_combined = (pA * nA + pB * nB) / (nA + nB)    se = math.sqrt(p_combined * (1 - p_combined) * (1.0 / nA + 1.0 / nB))    return (pA - pB) / se  def token_cost(requests, price_in, price_out):    # 成本控制: 估算token开销    total = 0.0    for r in requests:        n_in = r["history"] * 8 + r["question"]        n_out = r["answer"]        total += n_in * price_in + n_out * price_out    return total  def monitor(errors, total, threshold=0.05):    # 运维告警: 错误率阈值判断    return errors / total > threshold  def main():    random.seed(42)    labels = [random.randint(0, 9) for _ in range(1000)]    preds = [l if random.random() < 0.92 else random.randint(0, 9) for l in labels]    acc = offline_eval(preds, labels)    print("离线评测准确率: %.1f%%" % (acc * 100))     old = [random.choice(["退", "换", "问"]) for _ in range(200)]    new = [o if random.random() < 0.88 else random.choice(["退", "换", "问"]) for o in old]    print("影子模式一致性: %.1f%%" % (shadow_consistency(new, old) * 100))     z = z_test(0.12, 5000, 0.10, 5000)    print("AB实验Z值: %.2f %s" % (z, "显著优于" if z > 1.96 else "不显著"))     reqs = [{"question": 10, "history": 2, "answer": 30} for _ in range(2000)]    cost = token_cost(reqs, 0.002, 0.006)    print("估算token成本: $%.2f" % cost)     print("错误率告警:", monitor(13, 400, threshold=0.03))  if __name__ == "__main__":    main()
目的：用一份迷你模拟器跑通“离线评测 → 影子模式 → AB检验 → 成本核算 → 告警判断”全流程，验证评测驱动迭代的核心算法。
  1. correct = sum(1 for p, l in zip(predictions, labels) if p == l)逐条比对预测与标准答案，相等才计数
  2. return correct / len(labels)正确数除以样本总数得到准确率
  3. hit = sum(1 for a, b in zip(new_outputs, old_outputs) if a == b)影子模式下新旧输出一致才算通过
  4. p_combined = (pA * nA + pB * nB) / (nA + nB)合并两组数据估计总体转化率
  5. se = math.sqrt(...)合并标准误，度量差异的随机波动幅度
  6. return (pA - pB) / seZ 值超过 1.96 即认为差异显著
  7. total += n_in * price_in + n_out * price_out把每次调用的 token 花费累加成总成本
  8. return errors / total > threshold错误率越过阈值就触发告警
  9. random.seed(42)固定随机种子，保证结果可复现
  10. if __name__ == "__main__": main()可执行入口，直接运行这段代码观察输出

常见误区

误区“离线准确率都 98% 了，肯定能上线，灰度太浪费时间。”

正解离线数据集与真实用户分布永远有偏差。就像厨房试做再好吃，菜上桌才发现凉得快、份量不够——光照、并发、真实问法这些“线上场景”离线根本测不出来。所以必须补上影子模式、灰度与 AB 这三道“真实环境关卡”。

为何常见：把离线指标当成最终 KPI，忽略了从实验室到生产环境之间的分布鸿沟。

误区“A 组今天多了 3 个订单，新版本赢了，直接全量！”

正解一天的样本量太小，3 个订单很可能只是随机波动。要用 Z 检验看显著性，|Z| < 1.96 时就该继续跑。就像只看一桌翻台率就决定改菜单，样本小到没有统计意义。

为何常见：缺乏统计直觉，对随机波动没有耐心，容易被短期噪声带节奏。

误区“上线了的版本不能撤，撤了就是承认当初决策错了。”

正解回滚是设计好的标准安全动作，不是失败的标签。火警铃一响先关火再排查，是专业团队的共识；硬扛只会把几分钟的故障拖成几小时的事故。成熟团队早已把回滚练成“一键操作”。

为何常见：把产品迭代当成个人能力的赌注，用面子代替了流程。

误区“模型效果好就行，多花点钱无所谓，成本是老板该操心的事。”

正解token 成本直接决定你还能迭代几轮。不做提示词压缩与缓存，一次 AB 实验可能烧掉几十万；应该把成本优化看作产品质量的一部分，而不是财务部门的附属工作。

为何常见：习惯了传统软件“边际成本趋零”的思维，忽略了 LLM 按量计费的特殊性。

面试题

Q1. 评测驱动迭代的第一步是什么？

单选题 · easy

  • A.编写AB实验脚本
  • B.搭建评测体系指标← 正确答案
  • C.直接全量上线运行
  • D.采购服务器资源

答案：B。迭代先要有共同的“尺子”，即评测体系（指标、数据集、基准线）。没有它，后面所有验证都缺乏标准。AB 实验是上线阶段的事，全量上线风险极高，采购资源只是基础建设。

Q2. 影子模式最核心的特征是什么？

单选题 · easy

  • A.直接服务全部用户
  • B.旁路运行不返回结果← 正确答案
  • C.一半流量给新模型
  • D.只优化离线准确率

答案：B。影子模式让新模型在旁边“模拟答题”，真实用户看到的仍是旧模型，因此零风险。直接服务和一半流量属于灰度与 AB，不是影子模式的核心特征。

Q3. 比例Z检验中，通常认为差异显著的阈值是？

单选题 · mid

  • A.Z绝对值大于1.00
  • B.Z绝对值大于1.65
  • C.Z绝对值大于1.96← 正确答案
  • D.Z绝对值大于2.58

答案：C。95% 置信水平对应 |Z| > 1.96；1.65 对应 90%，2.58 对应 99%。AB 实验默认以 95% 为显著线，超过 1.96 才拒绝“差异纯属运气”的原假设。

Q4. 下列哪项属于token成本控制手段？

单选题 · mid

  • A.无限加长系统提示词
  • B.所有请求结果做缓存
  • C.压缩提示词与缓存复用← 正确答案
  • D.换用更大的模型来服务

答案：C。压缩提示词减少输入 token，缓存复用跳过重复计算，相当于“高汤省着用”；无限加长提示词只会更贵，换大模型更贵，所有请求都缓存会牺牲时效性。

Q5. 运维告警触发后应优先采取的动作是？

单选题 · mid

  • A.立即登录后台排查
  • B.先回滚到稳定版本← 正确答案
  • C.删除相关操作日志
  • D.通知业务方来开会

答案：B。先关火再排查——回滚是标准安全动作，不是失败。先排查会拉长故障时长，删除日志会丢失证据，开会更是错过止损窗口。

Q6. Z检验中合并比例p̂的主要作用是？

单选题 · mid

  • A.用于估计合并标准误← 正确答案
  • B.直接对比两组差异
  • C.等于两组方差之和
  • D.消除所有系统偏差

答案：A。p̂ 把两组样本合在一起估计总体比例，再代入标准误公式。组间差异由 p̂A - p̂B 直接给出，与方差之和及系统偏差无关。

Q7. 反馈闭环率C_loop衡量的是哪个方面？

单选题 · hard

  • A.模型文本生成准确率
  • B.发现到修复的周转效率← 正确答案
  • C.用户的最终满意度
  • D.token成本的下降比例

答案：B。C_loop = 已修复问题数 / 发现问题数，度量的是“订正错题”的速度。准确率、满意度、成本与迭代相关，但不是闭环率本身的含义。

Q8. 评测驱动迭代的正确流程包含哪些环节？

多选题 · hard

  • A.离线评测先筛一遍← 正确答案
  • B.影子模式在线验证← 正确答案
  • C.AB实验数据决策← 正确答案
  • D.跳过评测直接上线

答案：ABC。标准流程是离线 → 在线 → AB 三关递进，成本从低到高、风险从小到大；跳过评测直接上线等于没试菜就写进菜单，违背整条方法论。

Q9. 下列哪些属于线上监控的重点指标？

多选题 · mid

  • A.请求错误率与超时率← 正确答案
  • B.平均响应延迟时间← 正确答案
  • C.token消耗速率变化← 正确答案
  • D.代码提交行数统计

答案：ABC。错误率、时延、token 消耗是 LLM 应用的“火警三件套”；代码提交行数与线上服务质量没有直接关系，不属于监控指标。

Q10. 构建评测数据集时应当注意什么？

多选题 · easy

  • A.覆盖主流典型场景← 正确答案
  • B.掺入一定比例难例← 正确答案
  • C.每条样本标注答案← 正确答案
  • D.直接复用全部训练集

答案：ABC。评测集要有代表性、有挑战性、有标准答案，才能当“标准尺”。全部复用训练集会高估模型表现，属于典型的数据泄漏问题。