考察点
这道题看的是候选人有没有体系化思维，而不是只会「跑几个 case 看看效果」。面试官想听到分层设计、自动化程度、以及离线评测和线上监控怎么串成闭环。追问通常会往「指标怎么选」「评测集多大」「改动多大算倒退」「线上发现问题怎么回流」这几个方向走。
参考答案
为什么要分层
大模型应用不是单一模型，而是一条链路：检索、rerank、prompt、模型、工具调用、后处理。只测端到端，出了问题定位不到环节；只测组件，又保证不了整体体验。所以评测体系一般分三层。
组件级评测针对单个环节：检索看 Recall@k 和命中率，rerank 看 nDCG，结构化输出看 JSON schema 通过率和字段准确率，工具调用看 function call 的参数正确率。这层指标大多是确定性的，跑起来快，适合每次提交都执行。
链路级评测是端到端的 golden set：给一批真实输入，跑完整条链路，对最终输出打分。打分手段混合使用——能写规则的写规则（exact match、正则、字段校验），写不了规则的用 LLM-as-Judge 打分或 pairwise 对比，核心场景保留人工抽检。
系统级评测是线上业务指标：解决率、用户满意度、人工介入率、延迟 P95、单次会话成本。这层回答的是「功能到底有没有用」。
上线前：离线评测流水线
离线评测的核心是一份和业务分布对齐的 golden set，核心场景每类几十到上百条，总量几百条起步。这份集合要版本化管理，和代码一样 review。
每次 prompt、模型、检索参数变更，都必须过一遍离线评测，跑不进 CI 等于没门禁。门禁逻辑是「核心指标不允许下降超过阈值」，阈值要设得比评测本身的随机波动大（LLM 输出有温度随机性，同版本跑两遍也会差零点几个点），一般核心场景降 1-2 个百分点就要人工介入看 diff。评测报告里不只给总分，还要列出「哪些 case 变好、哪些变差」，case 级的 diff 比总分更有诊断价值。
上线前的最后一道关是安全评测：越狱、注入、敏感内容的对抗样本集，这个集合的通过率要求是 100% 或者接近 100%，和业务指标的逻辑不一样——业务指标允许权衡，安全指标不允许。
上线后：监控与回归闭环
上线不是终点。线上第一件事是埋点和看板：点赞点踩、转人工率、会话轮次、延迟、成本，按意图和场景切片看。第二件事是抽样质检，每周从线上流量随机抽几百条，跑自动检测（忠实度校验、安全过滤命中情况）加人工标注，估算线上真实质量水位。
更主动的做法是 shadow 和灰度：新版本先以 shadow 模式跑，只记录输出不返回给用户，对比新旧版本的输出差异；然后小流量灰度，观察护栏指标没问题再全量。
线上发现的 badcase 必须回流进评测集，这是闭环的关键一步。用户的点踩、投诉、转人工会话，是最高价值的评测样本来源。评测集因此是活的，持续扩充，每次迭代都在更大的集合上回归。
组织层面
评测体系要跑得动，责任要清晰：谁维护评测集、谁盯线上看板、badcase 多久清一次。很多团队的评测体系死在「建了没人维护」，评测集半年不更新，和业务分布早就漂了。
可能的追问
- 离线评测分数高，线上效果差，可能是什么原因？ 最常见是评测集分布和线上分布不一致，其次是 LLM-as-Judge 和用户真实偏好有偏差，还有离线环境忽略了延迟、并发这些工程因素。应对：定期用线上新样本校准评测集，并抽样比对 judge 打分和人工标注的一致率。
- 评测全自动化行吗？ 不行。自动指标有系统性偏差，必须保留一定比例的人工抽检做校准，人工标注数据同时是训练 judge 和校验 judge 的基准。
- 资源有限时先建哪一层？ 先建链路级的 golden set 加一个简单的线上点踩埋点。前者保证迭代不倒退，后者保证线上出问题能发现，这是性价比最高的组合。