Evals 是 AI Engineer 面试的分水岭

一句话总结

Evals 不是技术能力的附属测试，而是判断你能否把模型从实验室推向生产环境的核心仲裁机制；不是“你能不能写 eval 脚本”，而是“你能否定义什么才算‘好’，并推动团队接受这个标准”；真正的分水岭在于：你是否把 eval 当作沟通语言，还是仅仅当成技术任务。

适合谁看

如果你正在申请谷歌、Meta、Anthropic、OpenAI 或 Stripe AI 团队的 AI Engineer 岗位（非纯Research岗），且你的 resume 上写着“fine-tuned LLMs”“built RAG pipeline”“deployed vector search”，那么本篇不是教程，是裁决——裁决你当前对 eval 的理解是否已经触碰到工业级门槛。如果你在面试中被问过“怎么衡量这个模型好不好”，却只能用 BLEU/ROUGE 回应，那这轮你大概率被筛掉了；

如果你的系统设计轮把 eval 放在“最后一步”，那你的架构逻辑已被打回重做。

真正该看的人有三个特征：第一，已能独立搭起一个 minimal eval pipeline（哪怕用 LangChain + LlamaIndex）；第二，曾被跨职能团队质疑过“为什么你觉着这个结果算好”；第三，手头有至少一个 eval 失败的案例——不是数据不干净，是 eval 指标本身错了。

这不是给学术研究者写的：发过 ACL/ICML 不代表能过 Stripe 的 eval 轮；也不是给 MLE（Machine Learning Engineer）写的——他们负责 feature engineering，而 AI Engineer 的 eval 职责是定义什么是“产品可用”的边界。

为什么 eval 是分水岭

——不是所有 AI 模型都需要 eval，但所有要生产的 AI 模型都必须过 eval 这道关

当你在 GitHub 上 clone 一个 Hugging Face 示例，run evaluate.py 看到 accuracy 78.3%，那只是玩具；真正的分水岭出现在 eval 成为跨部门冲突的导火索那一刻。

举例：Anthropic 2023 年 Q4，一个客服助手项目进入 late-stage PM review，PM 拿着 demo 说“这回复够自然”，Engineering Lead 说“但安全 eval 分数低于 0.7”，最后卡在 hiring committee（HC）——HC 没投票否决，而是要求工程组重新定义“安全”的 eval 维度，并把“自然”拆解为三个可观测的子指标：停顿频率 ≤ 0.2/s、引用文档比例 85%±5%、用户打断率 ≤ 12%。

这不是技术问题，是判断力问题。

另一例：Meta 2024 年初，一个内部 LLM 用于代码补全，baseline eval 用 pass@1（GitHub Copilot 标准），团队一致通过；结果上线两周后，前端团队反馈“补全太激进，用户得手动删 3 行才能用”。

查 debrief，发现 eval 中只测了“补全匹配率”，没测“用户修改长度”。后来他们新增了第三个 eval 维度：avgeditdistancepercompletion，门槛设为 ≤ 12 tokens。

——不是 A，而是 B：不是“eval 越多越好”，而是“eval 必须能驱动行为改变”；不是“用 SWE-bench 就够”，而是“SWE-bench 只能测学术能力，不能测上线后的客户流失”；不是“eval 分数高=能上线”，而是“eval 与业务指标的相关性，才是 eval 的 eval”。

下面拆到每一轮面试中，eval 究竟在考什么

> 📖 延伸阅读：Coinbase系统设计模板：中国SWE订单簿设计下载（含SWE Playbook）

eval 轮 vs 系统设计轮的区别

——前者考“你如何定义问题”，后者考“你如何拆解问题”

系统设计轮常被误读为“画架构图”，实际考的是：你能否把模糊需求转化为可测量的产出；而 eval 轮更狠——它逼你承认：连“好”是什么，你都还没想清楚。

典型场景：面试官给你一段真实对话（脱敏）：

> 用户：“我上个月买的投影仪，开机就蓝屏。”

> 客服助手：“根据我们的记录，您可能需要更新固件。请访问 support.example.com/flash。”

> 用户：“我点进去是英文网站。”

> 助手沉默 5 秒，又说：“您可以用 Google 翻译。”

系统设计轮会问：“你怎么优化这个 pipeline？”——你答：“加个翻译模块，用 Whisper ASR + NLLB 模型，再接一个 rule filter。”

eval 轮会问：“你怎么知道‘沉默 5 秒’是个问题？怎么量化‘该沉默多久’？”

——你必须立刻脱离技术方案，进入定义阶段：

  1. 先确定业务目标：是降低用户放弃率，还是提升首次解决率？
  2. 再定义可观测行为：用户放弃 = 关闭页面 + 30 秒内无重访；沉默 = 助手连续 3 秒无 token 输出
  3. 最后才建 eval：avgsessioncompletiontime 与 userabandon_rate 的 Pearson r ≥ 0.6

如果你说“用用户满意度问卷”，那立刻出局——问卷滞后、样本偏差、人工噪声大；而 eval 必须是“实时、可回溯、可归因”的。

Meta 的 HC 记录显示，2023 年有 17% 的 AI Engineer 候选人在 eval 轮因“把 NPS 当核心指标”被拒。理由是：NPS 在内部系统里相关性 r = 0.12（p = 0.31），而 avgturnsto_resolve 与 churn 的 r = 0.79（p < 0.001）。

所以这不是技术轮，是裁决轮——裁决你是否具备“把直觉转化为可执行标准”的职业素养。

eval 如何暴露你是否懂工程约束

——当 eval 指标需要部署在 200ms 内返回时，你还能不能写出有意义的分数

很多人以为 eval 是离线跑一批 test set；工业级 eval 的残酷在于——它必须 live in production。

Google 的 Search Generative Experience（SGE）团队，2024 年 Q1 把 eval 从 batch 改为 stream，原因有三：

  1. 用户等待时间敏感（每增加 100ms，点击率下降 7%）
  2. 模型输出分布漂移（测试集是 2023 年数据，生产数据已含大量新兴关键词）
  3. 成本不可控（每次 eval 调 100 个 API，月开销 $18K）

于是他们重构了 eval pipeline：

  • 用 1% 流量做 shadow eval（不阻断主流程）
  • 指标从“准确率”改为“delta in user satisfaction score”，通过 A/B test 反馈自动更新
  • 每日 eval 结果自动发到 Slack channel #sge-evals，超阈值自动 call on-call

但新问题出现了：eval 本身成了 bug 的放大器。

某次团队把“事实一致性”阈值设为 ≥ 0.85，结果模型优化时只盯着这个指标，生成一堆“看似事实正确但毫无用处”的回复（比如“根据维基百科，地球是圆的”）。

最后他们加了一条 rule：evalmetric + businessmetric ≥ threshold，即 eval 分数高，但业务指标不涨，也禁止上线。

这就是为什么 AI Engineer 的 eval 轮常在系统设计之后：你得先有系统，才能知道 eval 要卡哪个点。

——不是 A，而是 B：不是“eval 越复杂越专业”，而是“eval 指标必须能被产品经理一眼看懂”；不是“用 GPT-4-judge 做自动打分”，而是“用人工标注 + 游戏化标注平台（如 Scale AI）确保标注一致性”；不是“自己手写 eval”，而是“用成熟框架（如 Ragas、DeepEval）但自己能改底层逻辑”。

> 📖 延伸阅读：PM面试手册评测：Google L5升L6晋升准备深度分析

eval 在招聘流程中的具体卡点

——从初筛到 offer，eval 不是某一轮，而是贯穿每道关卡的隐性红线

以 Anthropic 的 AI Engineer（L4）为例，全流程 6 轮，其中 4 轮明显涉及 eval：

  1. 初筛（15 min）：HR 不问“你用什么模型”，而问“你最近一次reject一个模型输出，是因为 eval 指标超标，还是业务风险？”
  2. 技术电面（45 min）：给一段 eval 代码（真实代码脱敏），让你 spot 三个潜在 bug；常见陷阱：用 np.mean 而非 np.nanmean 导致 NaN 污染；eval seed 未固定；未处理空字符串
  3. 系统设计（60 min）：题目是“-design an eval for a medical triage chatbot”。你以为要画 UML 图？实际考的是——你能否在 10 分钟内说出三个 eval 不能测的东西。正确答案包括：
    • 不能测“用户信任度”（需长期追踪）
    • 不能测“医生-助手协同效率”（需临床流程改造）
    • 不能测“法律合规性”（需人工律师审计）

然后你再补充：但我们可以用 proxy，比如 avgtimetohumanhandoff ≤ 8s

  1. 跨职能轮（45 min）：假扮 PM 或 Legal，故意说“我觉得这个 eval 不合理”
    • PM 说：“用户说喜欢就行， eval 太 technical”
    • Legal 说：“‘安全’指标太模糊，可能违反 HIPAA”

你必须当场调整 eval 逻辑：

  • 把“喜欢”转为 repeat-query rate（重复提问率 ≤ 15%）
  • 把“安全”拆为 prohibitedtopichit（≤ 0.1%） + misattribution_rate（引用虚假来源比例 ≤ 0.5%）

最后两轮是 HC 和 hiring manager，他们不看技术细节，只问：

  • “你上次改 eval 指标，是因为数据错了，还是业务变了？”
  • “你让团队接受新 eval 的最大阻力是什么？你怎么说服他们的？”

HR 提醒：不要夸大 eval 成果。

曾有候选人写“构建了industry-leading eval system，提升准确率 30%”，HC 查证后发现：

  • 他用的 test set 是公开数据集
  • eval 指标是 BLEU-4
  • 30% 提升来自换模型，不是 eval 方法
  • 实际上线后用户满意度下降 11%

结果：rejection with no appeal

真实 eval 轮面试场景还原

——这不是“怎么写 eval”，而是“你怎么说服别人这个 eval 该存在”

以下是 2024 年 3 月 Meta 一场 eval 轮的逐字记录（已脱敏）：

面试官（Staff Engineer，负责 Llama 3 eval）：

“我们有个新需求：做一个销售助手，能根据客户历史邮件自动写跟进话术。你作为 AI Engineer，怎么设计 eval？”

候选人 A（典型错误答案）：

“我会用 Rouge-L 和 BERTScore 做自动 eval，再抽 100 条人工打分。人工分用五级 Likert scale，由三名销售团队成员独立打，取平均。”

面试官追问：

“如果 Rouge-L 高但销售团队说‘这话术听起来假’，你怎么办？”

候选人 A（继续错）：

“那就再加一个情感一致性 eval，用 VADER 看语气匹配度。”

面试官（停顿 5 秒）：

“你没听懂问题。问题不是‘怎么让 eval 更准’，而是‘你怎么证明这个 eval 值我们投入人力去跑’？”

（沉默 10 秒后）

候选人 B（正确路径）：

“首先，我不会立刻想 eval。我会先确认：这个‘跟进话术’最终影响哪个业务指标？如果是‘邮件回复率’，那 eval 必须测——在控制用户质量、产品类型、金额区间后，话术是否提升回复率。

但 eval 是代理指标，所以我会做两件事：

  1. 先做 small-scale A/B test，用现有话术 vs 生成话术，测回复率 delta；
  2. 如果 delta ≥ 5%（p < 0.05），才回溯：哪些 eval 指标能 pre-empt 这个结果？

比如我们发现：

  • ‘个性化关键词密度’（客户公司名/人名出现 ≥ 2 次）与回复率 r = 0.63
  • ‘问题结尾占比’（以提问结尾的句子 ≥ 30%）与 r = 0.58

于是我们定义：autoscore = 0.4 × personalizeddensity + 0.6 × questionendingratio，门槛设为 ≥ 0.65 才上线。

这样，eval 不是事后补救，而是上线前的 gate。”

面试官点头：“对。我们最终定的门限是 0.62，不是 0.65——因为 0.62~0.65 之间，用户主观评分反而更高。eval 不是找最优值，是找‘够好且可执行’的边界。”

——不是 A，而是 B：不是“eval 决定模型好不好”，而是“eval 决定团队愿不愿为这个模型负责”；不是“eval 分数要高”，而是“eval 分数要能解释业务决策”；不是“我写 eval”，而是“我让别人也写得出来”。

为什么 eval 是薪酬谈判的隐藏杠杆

——你对 eval 的理解深度，直接决定你的 level 和 RSU 分配

硅谷 AI Engineer 的薪资结构高度透明，2024 年 Q1 数据如下（来源：Levels.fyi + LeetCode 内推匿名池）：

Level Base Salary RSU（4年） Bonus Total Mid
L3（Junior） $145K $120K $14K $279K
L4（Mid） $185K $180K $18K $383K
L5（Senior） $230K $280K $23K $533K
L6（Staff） $275K $420K $28K $723K

关键点在于：eval 能力是 L4→L5 的硬通货。

为什么？因为 L4 只需执行 eval，L5 必须定义 eval。

Meta 内部晋升文档显示：L5 候选人必须满足“主导至少一个 eval 框架的跨团队落地”，且该框架被至少 3 个产品组持续使用 ≥ 6 个月。

具体案例：一位候选人在面试中说：“我们用人工 eval，但标注员一致性低，Krippendorff’s alpha < 0.6”。

面试官问：“你怎么解决？”

他答：“不是解决标注一致性，是换 eval 设计——我把五级 Likert 改为二元判断：‘是否会导致用户投诉’。标注员只需勾选 yes/no，alpha 升到 0.89。

然后我们发现：yes 类中，83% 最终真被投诉；no 类中，92% 无事发生。于是我们把 eval 阈值设为：no_rate ≥ 90% 才上线。”

——这个答案直接从 L4 跳到了 L5 档。

但注意：RSU 分配不看 eval 分数，看 eval 的传播力。

Anthropic 晋升委员会明确要求：

  • L4：能维护一个 eval pipeline
  • L5：能说服其他团队 adopt 你的 eval 标准
  • L6：能影响行业 standard（比如推动行业用 factuality_score 替代 BLEU）

所以 eval 不是技术细节，是职业加速器。

准备清单

以下是 AI Engineer 面试前必须完成的 eval 相关准备，每条都经过 2024 年 Google/Meta/Anthropic HC 真实反馈验证：

  1. 重写你简历上的 eval 描述

BAD：“用 LangChain + GPT-4-judge 做 eval，提升准确率 15%”

GOOD：“定义 eval 维度：(1) factuality vs. gold doc；(2) user-intent alignment；(3) latency at p95。通过 A/B test 证明：当 (2) ≥ 0.7 时，用户任务完成率提升 12%（p=0.03），上线后 30 天内无回滚。”

关键：指标必须可归因到行为改变，而非“准确率提升”。

  1. 准备一个 eval 失败的案例

每个 HC 都会问：“你最近一次 eval 设计错了，错在哪？”

不要选“数据错了”这种借口；要选“定义错了”，比如：

> “我们用 BLEU 测客服回复质量，团队一致通过；上线后发现用户抱怨‘太官方’。我们以为是模型问题，重新 fine-tune；结果 BLEU 反而升了 5%，用户满意度降了 9%。

> 最后发现：BLEU 只测 n-gram 匹配，测不出‘亲和力’。于是我们新增指标：averagepauseduration（平均停顿时长 ≤ 0.18s）和first-person_ratio（第一人称占比 ≥ 40%），这两个与 NPS 的 r=0.71。”

  1. 自己跑一个 end-to-end mini eval pipeline

不用大模型，用一个小场景：

  • 用 100 条真实客服对话（Hugging Face 上的 multiwoz 子集）
  • 定义 eval 维度：1 个自动（如 intent matching accuracy），1 个人工（如“是否需转人工”）
  • 用 Pytest 写 test case，确保 eval 逻辑在 edge case 下不 crash
  • 生成一张图：eval 分数 vs 实际用户满意度（哪怕只有 20 个样本）

面试时能画出来，比说一百句都强。

  1. 准备三个 eval 指标的 proxy 替代方案

比如：

  • 不能测“用户信任” → 测 repeatqueryrate
  • 不能测“法律合规” → 测 prohibitedwordhitrate + citationsource_validity
  • 不能测“创意水平” → 测 diversity_score（unique n-gram / total n-gram）

关键：每个 proxy 必须附带“相关性证据”（哪怕只是自己做的小 A/B test）。

  1. 系统性拆解面试结构（PM面试手册里有完整的eval实战复盘可以参考）

不要只背“eval 要做什么”，要懂“eval 为什么卡在这里”——比如 Meta 的 eval 轮后永远接跨职能轮，因为 eval 必须过 PM 和 Legal 关；Google 的 eval 题常带“真实业务约束”（如 budget ≤ $500/月）。

  1. 带一个 eval 调优的决策树

画一张图：当 eval 分数低于阈值时，你优先查什么？

BAD 流程：检查数据 → 检查模型 → 重训 → 再 eval

GOOD 流程：

  • step 1：确认业务目标是否变（PM 合规？）
  • step 2：确认 eval 本身是否合理（人工 review 10 条 sample）
  • step 3：确认输入分布是否漂移（test vs prod）
  • step 4：最后才怀疑模型
  1. 背熟三个 eval 经典陷阱
  2. 指标倒逼行为错误（如：用 BLEU 导致生成文本过于正式）
  3. eval 数据泄露（test set 被用于 prompt engineering）
  4. eval 未随时间重校准（模型更新后，eval 阈值未重定）

每个陷阱必须配一个你亲身经历的案例。

常见错误

——这些错，90% 的候选人重复犯，且以为自己做对了

错误 1：把 eval 当成“最后一步”

BAD 对话：

“系统流程是：用户提问 → LLM 生成 → eval 模块打分 → 分数高则输出，低则 fallback 到 rule system。”

问题：eval 是 blocking gate？成本多高？当 eval 模块挂了，整个系统瘫痪？

GOOD 应该说：

“eval 是 advisory layer，不阻断主流程；主链路走 latency-optimized model，eval 跑在 shadow traffic 上；每小时生成 summary report，阈值连续 3 天超标才 trigger model rollback。”

Meta 的 SGE 团队甚至把 eval 分数做成 dashboard，供 PM 和 PMM 查看，而不是只给 engineer 看。

错误 2：用学术指标代替产品指标

BAD 对话：

“我用 GLUE score、SQuAD、MMLU 做 eval。”

问题：这些是 academic benchmarks，和用户行为无关。Llama 3-8B 在 MMLU 上 67.6，但客服场景可能毫无用处。

GOOD 应该说：

“我先确定业务目标：是降低客服转化成本？还是提升 NPS？

然后反向推 proxy：

  • 若目标是转化成本 → 测 avghandlereffortperticket（客服处理时长）
  • 若目标是 NPS → 测 npsdeltaafterfirstinteraction
  • 若目标是合规 → 测 manualauditpass_rate

最后选一个最容易实时采集的，作为 eval 主指标。”

错误 3：混淆 eval 和 monitoring

BAD 对话：

“我们部署了 eval pipeline，每小时跑一次，监控准确率。”

问题：你监控的是评估结果，不是产品表现。 eval 是事前 gate，monitoring 是事后警报。

GOOD 应该说：

“eval 在上线前跑，监控在上线后跑。

  • eval 看：如果输入分布不变，模型是否仍达标？
  • monitoring 看：真实用户输入下，关键指标是否偏离？

比如我们 eval 用 factualityscore ≥ 0.9，但上线后发现真实输入中常见‘我不知道’类 query，导致 factualityscore 自动升高（因为没输出错误事实）。

于是我们加了 confidence_score 作为 monitoring 指标——当 model 输出‘我不知道’时，confidence < 0.5 才通过。”

Google 的文档明确说：eval 与 monitoring 是两个不同职责；混淆它们是 Junior Engineer 标志。

FAQ

Q1： eval 轮如果被问“你怎么知道这个 eval 指标好”，该怎么答？

A：别掉进技术陷阱。面试官不关心你用什么模型打分，关心你是否理解指标与业务的因果链。

正确答法分三步：

  1. 先说业务目标：不是“提升准确率”，而是“降低用户放弃率”
  2. 再找可测量 proxy：我们分析用户行为日志，发现放弃前平均有 2.3 次重复提问；而重复提问与‘未解决感’强相关（r=0.81）
  3. 最后定义 eval：repeatqueryrate ≤ 15% ——当 repeat_rate ≤ 15% 时，用户放弃率下降 11%（p=0.02）

如果被追问“你怎么确认 repeatqueryrate 是因，不是果？”——

答：“我们做了小规模 A/B test：随机阻断用户前两次提问（模拟高 repeat），发现放弃率上升 7%；而自然 high-repeat 用户放弃率升 18%。证明 repeat_rate 是行为信号，不是结果偏差。”

——这才是 eval 轮想要的“判断力”，不是“技术能力”。

Q2： eval 指标必须实时吗？手动 eval 能过面吗？

A：能，但必须说明为什么手动是合理决策，且有兜底机制。

错误答案：“我们用人工 eval，因为自动 eval 太贵。”

正确答案：

“在医疗 triage 场景，我们人工 eval 前 3 天，因为：

  1. 系统上线初期，用户量小（≤ 500/天），人力成本可控（$180/天 × 3 = $540）
  2. 需要快速校准 eval 定义——比如‘严重症状’是否包含‘焦虑’？人工 review 50 条后，我们发现 42% 的‘焦虑’被误标为‘非紧急’；于是把定义收紧为‘需立即干预的身体症状’
  3. 同时我们建了 shadow auto-eval pipeline，用 10% 流量跑，对比人工 mark；当 auto/manual agreement ≥ 0.85（Cohen’s kappa），才 switch 到自动。

结果：前 3 天 user satisfaction 从 3.8 升到 4.4；auto 系统上线后，人力成本降为 $0/天，且 agreement 保持在 0.87。”

——这叫“渐进式 eval 策略”，不是“懒”。

Anthropic 明确允许手动 eval，但要求：必须有 exit plan（多久 switch to auto）、必须有 agreement 监控、必须有 drift detection（比如每周抽 5% 重评，看 score 分布是否漂移）。

Q3： eval 是 AI Engineer 的事，还是 ML Engineer 的事？

A：这是角色定位陷阱。

表面分工：

  • ML Engineer：搭建数据 pipeline、模型服务、A/B test 平台
  • AI Engineer：定义产品目标、设计 eval 指标、推动上线决策

实际中：Google 和 Meta 已合并 MLE 和 AI Eng 为 “LLM Engineer”，但 eval 职责依然锁定在 AI Eng。

关键证据：

  • Meta 的 job desc：AI Engineer 必须“own the definition of ‘good enough’ for model outputs”
  • Google 的 debrief 模板：eval section 必须由 AI Eng 填写，MLE 只填“technical feasibility”
  • Anthropic 的晋升标准：L5 必须“mediate between product and model team on eval trade-offs”

如果你说“eval 是 MLE 的事”，立刻被归为 Junior；如果你说“我们 team 共同定义”，会被追问：“谁有最终决定权？”

正确答法：

“我（AI Eng）定义指标，MLE 负责落地；但最终决定权在我，因为指标直接挂钩业务目标。

比如上周我们 eval 发现：模型在法语 query 上 accuracy 低，但 user satisfaction 高（因为语速匹配更好）。我决定保留accuracy 指标但不设阈值，转而加一个‘语速匹配度’proxy；MLE 负责实时计算这个 proxy。

我们有书面 agreement：AI Eng 提出 eval change，MLE 评估 latency/cost impact，both sign off before deploy.”

——这才是分水岭：eval 不是技术活，是责任归属的体现。

准备好系统化备战PM面试了吗？

获取完整面试准备系统 →

也可在 Gumroad 获取完整手册。

相关阅读