LLM Eval 面试：Golden Set、Human Eval 与线上指标

💡 核心要点 (Key Takeaways)

• LLM Eval 面试的第一问永远是「你怎么定义好」——任务定义不清，后面所有指标都是噪声。面试中先花 3 分钟把成功标准写成可验证的验收条件，是最高效的开场。
• Golden set 的质量决定 eval 的上限：分层覆盖（正常 / 边界 / 对抗）、来源多元（真实流量采样 + 人工构造 + bad case 回流）、规模够用（200-500 条是多数场景的起点），而不是越大越好。
• LLM-as-judge 有已知偏差（位置、长度、自我偏好），面试中要能说出偏差名称和对应的缓解方法，并讲出「judge 本身也要被 eval」的校准闭环——这是区分中级和高级候选人的关键点。
• Offline eval 和 online 指标是两层不同的问题：offline 管「这次改动会不会退步」（回归门禁），online 管「线上用户体验是否改善」（A/B 指标），只讲一层的候选人会被追问穿。
• 版本门禁（regression gate）是 LLM 应用发布流程的核心：关键指标不低于阈值才能上线，门禁指标和阈值本身也要随业务演进定期复审，不是一次性设定。

LLM Eval 面试考什么：先定义「好」

LLM Eval 面试通常出现在 AI Engineer、Applied AI 和 MLE 岗位的专项轮或 System Design 轮的追问中，题目形态一般是「为 X 产品设计一套评估体系」或「你的模型升级后怎么知道有没有变好」。和 RAG、Agent 设计一样，面试官不期待标准答案，但有一个明确的评分结构：你能不能把模糊的「质量」翻译成可度量的指标，能不能讲清数据从哪来、judge 怎么校准、结论怎么用于发布决策。

• 任务定义：这个任务的成功标准是什么，写成可验证的验收条件。跳过这一步直接说「我用 BLEU / 人工打分」是标准错误答案——指标必须从任务定义推导出来，不是反过来。
• 数据集与评分器：golden set 怎么构建（分层、来源、规模），用 code-based 检查还是 LLM-as-judge，judge 的偏差怎么校准。这一段是技术深度所在。
• 从评估到决策：offline 回归门禁、online 指标、A/B 实验怎么配合，指标掉了怎么归因，阈值怎么定。这一段区分「跑过 eval 的人」和「用 eval 做发布决策的人」。

任务定义：把「好」写成验收条件

任务定义是 LLM Eval 面试的起点，也是最能拉开差距的起点。Anthropic 的 eval 文档反复强调：eval 的第一件事不是选指标，而是定义任务边界和成功标准。面试中花 3-5 分钟做这一步，比直接讲指标更能展示工程成熟度。

• 高频题：为客服摘要产品设计评估体系，第一步做什么？
  评分点：先问清任务边界——摘要给谁看（内部质检还是直接展示给用户）？长度约束？必须保留哪些信息（订单号、承诺、时间）？什么情况下宁可不摘要（信息不完整时）？把这些问清楚之后，成功标准才能写成验收条件：① 事实一致性（摘要中的每个事实必须能在原文中找到依据）；② 关键信息完整率（订单号、承诺动作、时间三类字段不丢失）；③ 长度合规（不超过 N 字）；④ 拒答正确性（信息不完整时不生成摘要而是标记待人工处理）。
  关键表达：每条验收条件都要对应一种检查方式——事实一致性用 LLM-as-judge、关键信息完整率用 code-based（字段抽取 + 比对）、长度用代码断言。能做出「验收条件 → 检查方式」映射的候选人，明显比只说「用 LLM 打分」的高一档。
• 高频题：同一个任务，「准确率」这个词为什么不够用？
  评分点：「准确」在 LLM 任务里至少拆成三件事——事实准确（不编造）、相关（回答了该回答的）、完整（没漏关键信息），三者的检查方式完全不同，混在一起用一个分数无法归因。面试中要能说出：指标设计的原则是「一个指标只测一件事」，这样指标掉的时候才能定位到具体能力层。
• 追问预备：任务边界变了（比如摘要从内部质检改成直接展示给用户），eval 要改什么？——验收条件的严格度整体上调（事实一致性的权重从 0.7 提到 0.95，因为直接展示时编造的代价更高），golden set 要加入「用户视角」的样本（原文质量差的、口语化的、多语言的），online 指标从质检通过率变成用户满意度 / 工单回退率。能答出「任务变化会传导到数据集和阈值」是加分点。

Golden Set 构建：数据集决定 Eval 的上限

Golden set 是 eval 的地基，面试中这一段考的是你有没有真正建过数据集，而不是背过术语。OpenAI 的 best practices 文档把数据集设计列为 eval 质量的第一变量，逻辑是：judge 再准，数据集偏了结论也偏。

• 分层覆盖：一个合格的 golden set 至少分三层——正常样本（占 60-70%，任务的高频典型场景）、边界样本（20-30%，长文本、多语言、格式异常、信息冲突）、对抗样本（10-20%，诱导编造、注入式 prompt、超出能力范围的问题）。只覆盖正常样本的 eval 会在上线后第一时间被打脸，面试中要能说出每一层的占比逻辑和来源。
• 来源多元：三个来源缺一不可——① 真实流量采样（从线上 query 按分层抽样，保证分布真实）；② 人工构造（针对已知弱点定向构造，比如专门造「原文信息不全」的样本测拒答）；③ bad case 回流（线上出错的样本修复后加入集，让 eval 覆盖真实发生过的失败）。要能说出三个来源的配比逻辑和各自的局限（真实采样有幸存者偏差、人工构造可能过拟合构造者的偏见、bad case 回流会让集越来越偏长尾）。
• 规模与成本：200-500 条是多数场景的合理起点，不是越多越好——每条样本的标注成本（写参考答案、写评分 rubric）是真实的，集太大而标注质量下降比集小而标注严谨更糟。面试中如果追问「1000 条够吗」，正确答案是看分层覆盖是否完整而不是看总数：300 条覆盖全部分层比 1,000 条全是正常样本更有价值。
• 参考答案的形态：开放式任务（摘要、写作）不写唯一参考答案，而是写「评分要点清单」+ 1-2 个参考样例；封闭式任务（分类、抽取）写精确参考答案。这个区分说出来能证明你做过——很多人不知道参考答案的形态应该跟着任务类型走。

Pointwise 与 Pairwise：两种评分方式的取舍

这是 LLM Eval 面试的高频技术点，考的是你理解两种评估范式各自测什么、各自的偏差在哪，而不是「哪种更好」。

• Pointwise（单点评分）：对每个输出独立打分（1-5 分或 0-1）。优点是绝对尺度、可以跨版本比较（v1 平均 3.2 分、v2 平均 3.8 分）、可以按维度分别打分（事实性 4 分、完整性 3 分）。缺点是模型给绝对分不稳定（同一个输出今天 3 分明天 4 分），分数分布会漂移，跨时间比较需要校准锚点（固定几条锚样本每次一起评，用锚样本的分数漂移修正整体）。
• Pairwise（成对比较）：把两个版本的输出放在一起，让 judge 选哪个更好（或平局）。优点是相对判断比绝对打分稳定得多（「A 比 B 好」比「A 是 4 分」容易判对），统计功效高（同样本量下更容易检测出小差异）。缺点是没有绝对尺度（不知道「更好」的那个是不是也够好）、有位置偏差（judge 倾向选第一个或最后一个，必须做位置交换后合并结果）、只能两两比较（n 个版本要 n(n-1)/2 次比较）。
• 怎么选：面试中的标准答案框架——上线前的回归测试用 pointwise（需要和阈值比较，「不低于 0.85 才能上线」）；版本 A/B 对比用 pairwise（只关心谁更好，不需要绝对值）；线上 A/B 实验两者都不需要，直接用业务指标。能说出「不同决策场景用不同评估范式」是核心得分点，只说「pairwise 更好」或「pointwise 更好」都是错误答案。
• 追问预备：pairwise 的位置偏差怎么消除？——每次比较跑两遍（AB 和 BA 各一次），两遍结果一致才计为有效比较，不一致记为平局；统计时报告位置交换前后的一致率（judge 的稳定性指标），一致率低于 80% 说明 judge 本身不可靠，先修 judge 再信结论。

LLM-as-Judge：偏差、校准与「Judge 也要被 Eval」

LLM-as-judge 是 LLM Eval 面试的核心技术点，也是最能展示深度的部分。OpenAI 的 evals 文档把 model-graded eval 列为主流做法，但前提是 judge 本身被校准过——未校准的 judge 产出的结论比没有 eval 更危险，因为它给你虚假的信心。

• 已知偏差清单：面试中至少说出三个——① 位置偏差（pairwise 中倾向选特定位置）；② 长度偏差（倾向选更长的输出，即使更短的正确）；③ 自我偏好（judge 模型倾向给自己家的模型打高分——所以 judge 和生成模型用不同家系是标准做法）；④ 风格偏差（倾向选措辞更「自信」的输出，即使事实性更差）。每个偏差都要配一个缓解方法（位置交换、长度归一化或显式提示忽略长度、跨家系 judge、rubric 里显式写明「自信措辞不等于事实正确」）。
• 校准闭环：Judge 本身也要被 Eval：这是区分中级和高级候选人的关键点。做法——建一个「judge 校准集」：50-100 条由人工标注了 ground truth 判断的样本（人工判断作为金标准），让 judge 跑一遍，算 judge 和人工的一致率（agreement rate）。一致率低于 85% 的 judge 不能用于发布决策，先改 rubric / 换 judge 模型再测。校准集要定期扩充（每发现一类 judge 判错的 case 就加进去），judge 的 rubric 每次变更后都要重新校准。
  面试表达：「我的 eval 流水线里 judge 不是黑盒——它有自己的人均指标（和人工的一致率）、自己的回归集（校准集）、自己的版本管理（rubric 版本号），judge 的变更和新模型上线走同一套门禁。」这句话说出来基本锁定这一段的高分。
• Rubric 设计：评分标准必须写成可操作的 rubric（每一分对应什么具体表现），而不是「1 分差 5 分好」这种空话。好的 rubric 示例（事实性维度）：5 分 = 所有事实均有原文依据；4 分 = 无编造但有一处模糊表述；3 分 = 有一处无法从原文验证的陈述；2 分 = 有一处明确编造；1 分 = 多处编造或与原文矛盾。每个分数档要配一个样例输出（few-shot），judge 的稳定性主要靠 rubric 的粒度 + few-shot 样例保证。
• Code-based 优先：能用代码检查的绝不用 judge——格式合规、字段存在性、长度约束、敏感词、精确匹配（分类任务的 label 比对）都是 code-based，零成本、零偏差、确定性。LLM-as-judge 只用在代码检查不了的主观质量维度（流畅性、忠实性、相关性）。面试中先说「哪些维度用代码、哪些维度用 judge、为什么这样分」，比直接讲 judge 更展示工程判断。

Human Eval：Rubric、标注流程与成本

Human eval 不是「找几个人看看」，它有完整的工程结构：rubric 设计、标注员培训、质量控制、仲裁机制、成本控制。面试中这一段考的是你理解人评是昂贵的资源，怎么花得值。

• 定位：Human eval 是校准源，不是日常工具：日常跑量用 LLM-as-judge，人评用于三件事——① 建 judge 校准集（金标准）；② 定期抽检校准 judge（每周从线上输出抽样 50 条人工评，监控 judge-人工一致率）；③ 仲裁（judge 打分存疑的边界 case 由人做最终判断）。要能说出人评的预算占比（通常占总 eval 成本的 20-40%，但只覆盖 5-10% 的样本量）和为什么这个比例是合理的。
• Rubric 与标注流程：标注前——rubric 冻结 + 培训（用 20 条样例跑一遍，标注员打分和参考分对齐，不一致的逐条讨论到共识）；标注中——每条样本至少 2 人独立标注，一致性高的直接采信，不一致的进第三人仲裁；标注后——计算标注员间一致率（inter-annotator agreement，用 Cohen's kappa 或简单一致率），低于 0.7 说明 rubric 有歧义，回炉改 rubric 而不是换标注员。
  面试表达要点：「标注员间一致率是 rubric 质量的指标，不是标注员的指标」——这句话体现的是流程设计思维。
• 成本控制：人评成本按「条 × 维度 × 标注员数」算，控制手段——① 分层抽样（只对 judge 打分的边界区间做人评，高分和低分区间的 judge 可信度高可以少抽）；② 维度裁剪（不是每条样本都评所有维度，按风险分配）；③ 主动学习（优先标注 judge 最没把握的样本，信息量最大）。能说出「人评预算应该花在 judge 最不可靠的区域」是明显加分点。

Regression 与版本门禁：Eval 如何驱动发布决策

这一段是 LLM Eval 面试从「方法论」上升到「工程实践」的关键，也是 AI Engineer 面试和学术讨论最大的差异点：eval 不是为了出论文，是为了在每次改动前回答「能不能上线」。

• 回归测试的触发点：任何可能影响输出的改动都要跑 golden set 回归——模型升级（换版本 / 换供应商）、prompt 修改、上下文模板变更、检索或工具层变更（RAG 的 chunk 策略、Agent 的 tool schema 都算）、judge 的 rubric 变更。面试中要能说出「回归不只在模型升级时跑」——prompt 改一个字的回归和换模型的回归走同一套门禁，这是 LLM 应用和传统软件最大的流程差异（传统软件的 prompt 等价物是配置，改配置不需要跑全量测试）。
• 门禁指标与阈值：门禁是「关键指标不低于阈值」的硬约束，不是「平均提升」的软约束。典型门禁设计（客服摘要场景）：事实一致性 ≥ 0.90（硬门禁，低于即阻断）、关键信息完整率 ≥ 0.95（硬门禁）、长度合规率 ≥ 0.99（硬门禁）、整体 judge 分 ≥ 基线 - 0.05（软门禁，允许小波动但需要人工确认才能放行）。要能说出硬门禁和软门禁的区别：硬门禁自动阻断，软门禁触发人工 review——全设硬门禁会导致正常波动也卡发布，全设软门禁等于没有门禁。
• 指标掉了怎么归因：回归失败时的标准流程——① 看分层（是正常样本掉了还是边界 / 对抗样本掉了？边界掉了可能是改动触及了弱点，正常样本掉了是严重信号）；② 看维度（哪个维度掉了，定位到能力层）；③ 抽样人评 20 条失败样本（确认是模型退步还是 judge 误判——judge 本身也可能因为新输出风格的变化而误判）；④ 写归因结论（哪个改动导致、影响面、建议回滚还是修补）。能说出「回归失败先怀疑 judge 再下结论」是加分点，因为这是实践中最常见的误判来源之一。
• 阈值本身的治理：阈值不是一次性设定的——业务要求变化（摘要从内部质检改成直接展示）要上调阈值；模型基线进步后旧阈值失去区分度（所有版本都 0.99，门禁永远不触发）要上调；门禁被频繁误触发（每周卡两次但其实改动没问题）要检查是阈值太紧还是 judge 不稳定。面试中要能说出「阈值有 owner、有复审周期（季度）、有变更日志」，这是把 eval 当系统运营而不是当一次性实验的标志。

Online Metrics 与 A/B Test：从 Offline 到线上

Offline eval 回答「这次改动会不会退步」，online 指标回答「线上用户体验是否真的改善」——两层问题不能互相替代。面试中只讲 offline 的候选人会被问「你怎么知道 offline 提升等于线上提升」，只讲 online 的候选人会被问「A/B 周期太长，发布前怎么办」，正确答案是讲清两层的分工和衔接。

• Online 指标的设计：分两层——① 任务指标（和任务定义直接挂钩）：客服场景是工单解决率、用户确认率、工单回退率（用户不满意重新开单）；② 体验指标（间接信号）：首次响应时间、会话轮次（轮次变多通常意味着没解决）、用户满意度评分。要能说出任务指标和体验指标的关系：任务指标是因果（系统直接产出），体验指标是相关（受很多其他因素影响），发布决策以任务指标为主、体验指标为辅。
• Offline 到 Online 的衔接：标准流程是「offline 回归通过 → 小流量 A/B（5-10%）→ 任务指标不劣化 → 扩量（50%）→ 全量」。小流量阶段的核心不是看提升幅度（样本量不够，统计功效不足），而是看「有没有显著劣化」——这是 offline eval 抓不到的风险类别（比如某个长尾用户群体的体验问题，golden set 覆盖不到但线上能抓到）。要能说出「offline 和 online 抓的是不同类别的风险：offline 抓已知能力退步，online 抓分布外风险」。
• A/B 实验的坑：面试中至少说出两个——① LLM 输出有随机性（temperature > 0），同一用户同一问题两次结果不同，实验设计要控制随机性来源（实验组和对照组用相同 temperature，或把输出缓存）；② 网络效应与污染（客服场景里同一用户跨实验组出现，或者人工坐席同时处理实验组和对照组工单导致行为混杂）——分桶要按用户 ID 而不是按请求 ID，且人工介入环节要单独分析。
  加分表达：「A/B 的显著性只是必要条件不是充分条件——统计显著的 0.5% 提升可能不值得发布成本，统计不显著的 2% 提升可能值得扩量观察，发布决策是指标 × 置信度 × 业务价值的三元组，不是 p < 0.05 一刀切。」
• 线上数据回流：线上 A/B 和真实流量产生的数据要回流到 eval 体系——① 新的 bad case 进 golden set（对抗层和边界层的主要来源）；② 线上 query 分布漂移监控（golden set 的分布和真实流量的分布定期比对，漂移超过阈值说明 eval 在测一个已经不存在的世界）；③ 线上 judge 评分（对真实输出抽样跑 judge，和 offline 的分数分布比对，监控 judge 在新分布上是否还准）。能说出「eval 体系是活的，靠线上数据持续供血」是这一段的核心得分点。

端到端示例：为客服摘要系统设计 Eval 体系

假设面试官说「你的公司有一个客服对话摘要系统，模型下个月要从小模型升级到大模型，设计完整的评估方案」。下面是 45 分钟面试中可按顺序讲出的完整答案框架（教学用虚构场景，非真实公司系统）。

• Step 1 — 任务定义（5 分钟）：摘要给内部质检团队看（不是直接展示给用户），长度 ≤ 200 字，必须保留三类信息（订单号、承诺动作、时间），原文信息不完整时输出「待人工处理」标记而不是硬写。验收条件四条：事实一致性（无编造）、关键信息完整率（三类字段）、长度合规、拒答正确性（信息不全时标记）。每条对应检查方式：事实一致性 → LLM-as-judge；完整率 → code-based（正则 + 字段抽取比对）；长度 → 代码断言；拒答正确性 → code-based（标记存在性）+ 人工抽检。
• Step 2 — Golden Set（8 分钟）：350 条，分层——正常 220 条（真实流量按会话长度和意图分层抽样，覆盖售前 / 售中 / 售后 / 投诉四类）、边界 80 条（超长会话、多语言混杂、信息冲突、原文口语化严重）、对抗 50 条（原文信息不全测拒答、诱导编造的会话、包含敏感信息的会话）。来源：真实采样 70% + 人工构造 20% + 历史 bad case 回流 10%。参考答案形态：每条形如「关键事实清单（5-8 条）+ 拒答判定 + 1 个参考摘要样例」，不写唯一标准答案。
  构建周期：2 周（采样 3 天、标注 10 天（每条 2 人独立标注 + 仲裁）、质量检查 3 天），标注团队 3 人（2 标注 + 1 仲裁 / QA）。
• Step 3 — 评分器与校准（8 分钟）：Code-based 检查四项（长度、字段完整、拒答标记、敏感词）直接出分，零偏差。事实一致性用 LLM-as-judge（跨家系：生成用 A 家模型，judge 用 B 家模型），rubric 五档（每档配样例，见上节 rubric 示例），few-shot 5 条。Judge 校准集 80 条（人工标注金标准），基线一致率要求 ≥ 85%，实际测得 89%，达标。
  评估流程：小模型基线跑一遍（350 条全量）→ 大模型跑一遍 → 按分层 × 维度出对比表 → 门禁判定。
• Step 4 — 门禁与发布（7 分钟）：门禁设计——事实一致性 ≥ 0.90（硬）、关键信息完整率 ≥ 0.95（硬）、长度合规率 ≥ 0.99（硬）、拒答正确率 ≥ 0.90（硬）、judge 总分 ≥ 小模型基线（软，掉了触发人评 30 条归因）。实测：大模型事实一致性 0.93、完整率 0.97、长度 100%、拒答 0.92、总分 +0.08——全部通过。
  发布策略：offline 通过 → 小流量 5%（3 天，监控工单回退率和质检通过率，不劣化即扩量）→ 50%（7 天）→ 全量。线上指标：任务指标（质检一次通过率、工单回退率）为主，体验指标（质检人均处理时长）为辅。
  回滚预案：小流量阶段质检通过率下降 > 2pp 立即回滚，同时拉 50 条失败样本做归因。
• Step 5 — 持续运营（7 分钟）：上线后三件事——① 每周从线上输出抽样 50 条人评，监控 judge-人工一致率（跌破 85% 触发 judge 复审）；② bad case 回流（每周新增 5-10 条进 golden set，季度重采样真实流量层）；③ 分布漂移监控（线上 query 意图分布 vs golden set 分布，月度比对）。阈值复审：季度一次，业务要求变化时随时。
  扩展性：这套体系可以复用到 Agent 场景——评估单位从「单条摘要」升级为「任务轨迹」（见 AI Agent 面试题 的 observability 模块），golden set 从「输入-输出对」升级为「任务-轨迹-验收条件」，门禁框架不变。

失败案例：Judge 风格漂移导致误判发布

教学用失败案例，演示面试中「现象 → 根因 → 修复 → 预防」四段式回答（虚构场景，非真实事件）。

• 现象：一次 prompt 微调（把摘要风格从「正式」改成「简洁」）的回归测试中，judge 总分从 3.8 掉到 3.4，按软门禁流程触发人工 review——人评 30 条后发现摘要质量没有下降（甚至更好），是 judge 给「简洁风格」的输出系统性打了低分。如果当时按门禁字面执行（软门禁掉分即阻断），这次有价值的改动会被误杀。
• 根因排查：拉 judge 的打分明细——「简洁」输出的长度比「正式」输出平均短 35%，而 judge 的历史打分模式和长度正相关（长度偏差）。根因两层：① judge 的 rubric 里「信息完整」维度的样例全部是偏长的摘要，judge 学到了「长 = 完整」的错误关联；② 风格变更这类改动是 judge 校准集的盲区——校准集里全是正式风格样本，judge 在简洁风格上的行为从未被验证过。
  分层定位表达：这不是「judge 不准」的笼统问题，是「judge 在风格变化维度上未校准」的具体问题——定位到 rubric 样例偏差和校准集覆盖缺口两个可修复的根因，而不是「换个更强的 judge 模型」这种贵且不精确的方案。
• 修复：① rubric 修复——「信息完整」维度的样例加入简洁风格版本，并在 rubric 显式写明「简洁不等于信息缺失，以事实清单覆盖度为准，不以长度为准」；② 校准集扩维——加入 40 条「风格变化」样本（同一输入的正式 / 简洁两种输出，人工标注等价），重新校准后 judge 在风格变化样本上的一致率从 71% 升到 92%；③ 门禁逻辑修复——软门禁从「总分不降」改为「分层维度分不降」，风格类改动单独看「信息完整」维度分（本次 0.96 → 0.97，实际是提升），总分波动不单独作为阻断条件。
• 预防：① 校准集增加「风格鲁棒性」层（固定占 10-15%）：同一输入的不同风格输出，judge 应该给出等价分数，这是 judge 的回归测试项；② 门禁规则区分改动类型——模型升级走全量门禁，prompt 风格调整走「维度分门禁 + 人评确认」，避免风格偏差误杀；③ 每次 prompt 变更前先跑「风格探针」（20 条同义不同风格的输出看 judge 分数方差），方差超过阈值先修 judge 再跑正式回归。
• 面试表达：这个案例演示三个关键习惯——① 门禁失败先验证 judge 再下结论（人评 30 条的成本远低于误杀一次发布或放行一次退步）；② judge 的偏差是可以定位到具体维度（长度关联）和具体缺口（校准集无风格覆盖）的，不是玄学；③ 门禁规则本身要区分改动类型——一刀切的门禁既会误杀也会漏放。

7 天练习计划

按每天一个模块推进，第 7 天做完整 mock。每天 2-3 小时，总计约 18 小时。练习围绕一个自建任务（推荐：把 50 条公开客服对话做摘要，或把 50 条公开文档做问答）展开，7 天复用同一任务。

• Day 1 — 任务定义：为你的练习任务写任务定义文档：边界（输入输出约束）、成功标准（4-6 条可验证的验收条件）、每条验收条件对应的检查方式（code-based 还是 judge，为什么）。然后找一个人（或用另一个 AI 扮演面试官）对你的定义追问 15 分钟，记录被问住的点。交付物：一份 1 页的任务定义 + 追问记录。
• Day 2 — Golden Set 构建：为练习任务建 50 条 golden set：正常 30 条（从真实数据分层采样）+ 边界 12 条（定向构造）+ 对抗 8 条（构造信息不全 / 诱导编造的样本）。每条写参考答案（开放式任务写事实清单 + 样例，封闭式写精确答案）。练习分层抽样的具体操作（按什么维度分层、每层抽几条、为什么）。
• Day 3 — Code-based 评分：实现你的 code-based 检查（字段抽取、正则比对、长度断言、敏感词），对 50 条样本跑一遍，记录每条的通过情况。练习：故意在 10 条样本里植入已知错误（漏字段、超长、敏感词），验证你的检查能全部抓到（召回率 100%）——code-based 检查的验收标准就是「已知错误零漏报」。
• Day 4 — LLM-as-Judge 与 Rubric：为 judge 写 rubric（每个分数档的具体表现描述 + 样例），选一个和生成模型不同家系的 LLM 做 judge，对 50 条样本打分。然后自己当人工标注员，独立给 30 条打分，算 judge 和你的的一致率。一致率低于 85% 时：逐条分析分歧，改 rubric，再测。记录改 rubric 前后的分数变化。
• Day 5 — Judge 偏差实验：做三个偏差实验，各用 10 组样本——① 位置偏差：把 A/B 输出交换顺序跑 pairwise，看选择是否翻转；② 长度偏差：对同一内容做「简洁版 / 冗余版」改写，看 judge 分数差异；③ 自我偏好（如果可用两个家系的模型）：交叉比较 judge 给自家模型和别家模型的分数差。每个实验记录数字，写出对应的缓解方法。这个实验产出的数字是面试中最有说服力的素材（「我实测过，位置翻转后 30% 的选择会翻」）。
• Day 6 — Regression 与门禁：改一个 prompt（或换一个模型），跑完整回归：50 条 golden set × 全部分层 × 全部维度，和基线对比。设计门禁（硬 / 软门禁 + 阈值），故意制造一次回归失败（用一个明显更差的 prompt），走一遍「失败 → 分层归因 → 抽样人评 → 归因结论」的完整流程。写归因报告：哪个改动、影响哪些层、建议回滚还是修补。
• Day 7 — 完整 Mock：45 分钟完整讲一个 eval 设计题（用「模型升级，设计评估方案」作为题目），录音。回听只检查五件事：① 是否先做了任务定义（验收条件 + 检查方式映射）；② golden set 是否分层且来源多元；③ judge 的偏差和校准是否主动讲（不是等追问）；④ offline 和 online 的分工是否讲清；⑤ 门禁是否区分硬 / 软且有阈值治理。不达标的项目第二天重做对应模块。

FAQ：LLM Eval 面试高频问题

以下 5 个问题覆盖 LLM Eval 面试中最容易被问倒的点。重点不是背指标名，而是讲清楚 offline 评估和 online 指标的分工，以及 eval 体系如何驱动发布决策。