题目重点：Nvidia 电话面经问如何知道模型好不好；本文从任务目标、代表性评测集、坏例、人评、线上实验及部署成本构建可复查评估方案。
题意与假设
这道练习题保留了面经中值得训练的核心约束，并将需要澄清的条件单独列出。现场拿到变体时，先和面试官确认这些条件。
- 训练例以企业问答助手为具体任务说明评估框架；若面试官实际谈分类、回归或生成任务，应换成对应指标，不能把问答指标当通用答案。
- 目标客户有可验证文档和一部分人工标注问题；线上可做小流量实验。题目未说明是否有标注或线上实验权限。
- 评估一项模型变动时冻结测试集、提示词、检索索引版本和采样参数；若一起更改，要用分层实验定位收益来源。
解题路线
- 先定义“好”的目标和约束：客户要正确答案、低幻觉、覆盖关键场景，还是低延迟/低成本？列出必须满足的安全与合规底线，并把关键失败按严重度分级。
- 建立训练外的代表性离线题集，覆盖常见、长尾、近期变化和高风险客户问题，按时间与客户分组。对有客观答案的题量测正确率/召回率；对开放题用清晰 rubric 的盲评与双人复核，同时保留原始坏例。
- 除总体分数外报告每组样本量、置信区间和最差分组；模型可能平均分提升却伤害高价值客户。对问答还要分检索失败、证据引用错误、推理错误和拒答错误，以便选修复路径。
- 上线前小流量 A/B 或 shadow：看任务完成率、人工升级率、用户纠错、投诉、安全事件，并同步记录 p95 延迟、token 量、GPU 使用与单请求成本。实验分流要固定用户/租户，避免同一客户跨组污染。
- 将离线与线上不一致当作调查线索：检查数据新鲜度、线上流量构成、日志/标签延迟和提示/检索版本；任何一次评估结论都有适用时间窗和客户群。
手动走一遍
训练例：新模型在 1000 道离线 FAQ 上正确率从 86% 到 90%，但 40 道高风险故障题从 35/40 降为 31/40，p95 延迟也从 1.2 秒升至 2.8 秒。若客户目标是故障排查且 SLA 为 2 秒，不能只凭总体 +4 个百分点上线；先查高风险坏例，再考虑路由或继续改进。
规模与取舍
M 道评测题、K 个候选模型时，至少要执行 O(MK) 次推理；人工复核成本与抽样数、每题评审人数和题目复杂度成正比。线上 A/B 的所需样本量取决于基线转化率、目标最小效果和方差；小样本重要子群不能套总体置信度。每请求成本还受输出 token 与并发利用率影响。
易错点与追问
容易失分的边界
- 只报一个 benchmark 或平均分，忽略与客户任务、流量和高风险坏例是否一致。
- 在训练或调参过程中反复查看最终测试集，造成评估集过拟合。
- 让评审知道模型身份或不给评分 rubric，人评容易受品牌和表达流畅度影响。
- 离线质量提高就断言线上业务改善，未评估延迟、用户行为和成本。
继续深挖
- 若没有可靠标签，可先建小规模高质量人工集，并把用户点击等 proxy 与真正任务成功区分。
- 若模型用于多租户客户，按租户、语言、领域与时间分层；极小群体考虑定性审阅和持续积累。
- 若模型迭代很快，保留固定回归集与定期刷新的新鲜集；每次更新标注模型、提示、检索和数据版本。
