Evals 是 AI Engineer 面试的分水岭

Evals 不是技术面试的一个环节，而是区分"能写代码的工程师"和"能交付 AI 产品的工程师"的单一标准。面试官在 Evals 讨论中真正判断的是：你是否具备用量化思维定义"好"的能力，以及你是否理解模型行为和产品目标之间的映射关系。那些在 Evals 上做对的人，拿到的 offer 总包差距可以达到 30 万到 50 万美元——不是因为他们代码更强，而是因为他们被认定可以独立负责一条 AI 产品线的模型迭代。

一句话总结

适合谁看

正在准备 AI Engineer 或 Applied Scientist 面试的人，特别是那些简历上有"搭建过 RAG 系统"或"微调过 LLM"却讲不清楚评估指标的人。也包括从传统软件工程转型、以为 prompt engineering 就是 AI 工程核心的候选人。以及那些过了 coding 轮、挂在 system design 或 ML design 轮，复盘时发现自己讲了一堆 architecture 却讲不明白"怎么判断这个系统变好了还是变差了"的人。如果你投的是 OpenAI、Anthropic、Google DeepMind、 Character.AI 这类公司的核心产品岗位，或者 Meta、Amazon 内部正在扩张的 AI 产品团队，这篇文章写的就是你面试里会被深挖的那个点。薪资参考：硅谷 AI Engineer L4-L6 的 base 在 130K-220K 区间，RSU 每年 80K-400K，bonus 15%-50%，总包范围 200K-700K。L5 以上如果带模型迭代方向，总包可以突破 800K。

为什么 Coding 轮筛不掉的人，Evals 轮能筛掉

2023 年我见过一个典型的 debrief 场景。一个候选人在 Meta 的 AI Infrastructure 团队面了五轮，coding 轮 clean solve，system design 画了完整的分布式训练架构图，ML fundamentals 对答如流。Hiring manager 在 debrief 上问了一个问题："他的 RAG 系统，retrieval 准确率从 72% 提到 78%，但用户留存掉了 2%，他怎么解释？" 面试官沉默了十秒，说："他没想过这个问题。他的世界里，accuracy 就是 north star。"

这个人没拿到 offer。

不是因为他技术不够深，而是因为他的 Evals 思维停留在"模型指标"层面，没有建立"业务指标"和"模型指标"之间的传导链。真正的 AI Engineer 不是不能做苦活——写 evaluation pipeline、跑 benchmark、做 error analysis 都是苦活——而是能在做这些之前，先回答"我们要优化什么"以及"用什么信号来确认我们优化对了"。

这里有一个关键的对仗：不是跑完 MTEB 榜单就万事大吉，而是要设计一个能暴露你产品特有 failure mode 的评估体系。MTEB 测的是通用能力，你的产品里用户最忍受不了的是 hallucination 还是 latency，是事实性错误还是风格不一致，这个答案不在任何公开 benchmark 里。

另一个 debrief 里的高频场景：面试官问"你怎么判断你的 fine-tune 成功了"，候选人回答"我在 holdout set 上看了 loss curve"。这是错的。不是看 loss curve 没用，而是 loss 下降和模型在实际场景中的表现改善之间，隔着一整个需要被显式定义的 evaluation protocol。正确的回答会涉及：holdout set 的构造是否反映了真实用户分布，offline metric 和 online A/B test 的 correlation 历史，以及如果 offline-online 出现 divergence 时的 debug 流程。

第三个对仗：Evals 不是面试前突击准备一个 checklist 就能过关的，而是需要你在每一个技术决策中展示"测量意识"。面试官会追问你为什么不选某个指标，你的 answer set 有没有 coverage gap，你的 evaluator 本身有没有 bias。这些问题的答案没有标准解，但面试官能从你的 reasoning 中判断你是真的迭代过，还是只读过论文。

Evals 面试到底在考什么：从面试官的打分表反推

Google 一个做 Bard 后续产品的 team 的面试官跟我描述过他们的打分维度。不是"知道多少 metrics"，而是五个层级：Undefined（没有 eval 意识）、Checklist（能背出 metrics 名字）、Instrumental（能选对 metric 但说不清 tradeoff）、Integrated（能根据产品阶段动态调整 eval strategy）、Generative（能创造新的 eval 方法或发现现有方法的盲区）。大多数候选人卡在 Checklist 到 Instrumental 之间，而想通过面试需要至少达到 Integrated。

具体拆解一轮 45 分钟的 Evals-focused interview。前 10 分钟通常是 warm-up 和 project deep-dive，面试官选一个你简历上的项目追问 eval 细节。中间 25 分钟是核心：给你一个场景，让你从头设计 eval。比如："你要做一个帮助律师审合同的 AI，怎么评估它 extract clause 的能力？" 最后 10 分钟是 follow-up 和 reverse question，但面试官的真正目的是在这个环节测试你的 intellectual honesty——你会不会在压力下承认自己的 eval 设计有漏洞。

那个律师合同的例子，我见过一个 L5 候选人的回答路径。他第一步不是列 metrics，而是先问面试官："这个系统的用户是合伙人还是初级律师？他们容忍的 error type 不一样。" 面试官追问："假设是初级律师，他们需要复核。" 他说："那我的 eval 会分成两层。第一层是 objective correctness——extracted clause 和 ground truth 的匹配，用 exact match 和 semantic similarity 双轨。第二层是 utility——这个 extracted clause 实际上减少了初级律师多少复核时间，这个需要 user study 或至少是 expert rating。" 这个回答的价值不在于完美，而在于展示了"eval 是服务于用户价值的"这一意识。他拿到了 offer，base 175K，RSU 280K annually，bonus 20%，总包 460K。

时间分配上，这一轮通常跟在 coding 或 ML design 之后，但权重在 recent hire 的反馈中持续上升。一个内部数据点：某头部 AI 公司 2024 年 Q1 的面试反馈中，Evals 相关讨论的 negative signal 占比从 12% 上升到 31%，超过 system design 成为第二大挂人原因。

从"我做了一个 RAG"到"我定义了 RAG 的成功"：叙述框架的转型

大多数候选人的项目叙述是这样的："我搭建了一个 RAG 系统，用了某某 embedding model，retrieval 用 FAISS，generation 用 GPT-4，在内部数据集上线了。" 这个叙述在 2022 年也许够用，在 2024 年的面试里是自杀式的。

正确的叙述框架需要回答五个问题，按顺序：What is the user task（用户在完成什么任务时会被卡住）？What is the failure mode（模型在哪个环节最可能出错）？What is the signal（你用什么来捕捉这个 failure）？What is the threshold（多少错误率是不可接受的）？What is the iteration loop（你发现 eval 信号变差时，怎么定位 root cause）？

不是说你每个项目都要有完美的 A/B test 结果，而是你要展示你思考过这些维度。一个常见的 compromise 是早期项目只有 offline eval，那你要能讲清楚：为什么 online eval 在当时不可行，你的 offline proxy 和真实业务指标之间的 gap 有多大，以及你计划怎么验证这个 proxy 的有效性。

具体场景：一个候选人在 Stripe 做 internal tool 的 AI 功能，没有任何 external traffic 可以测。他的做法是：把 internal users 分成两组，一组用 baseline，一组用新 model，通过内部 ticket volume 和 thumbs up/down 数据来构造 proxy metric。面试时他主动承认这个 proxy 的局限："thumbs down 可能反映的是 UI 问题而非 model 问题，所以我们做了 stratified sampling，对 thumbs down 的案例做 manual review 来归因。" 这种主动暴露局限的做法，在面试官那里的评分反而比那些声称"我的 metric 完美覆盖了一切"的人更高。

另一个关键的对仗：不是项目规模越大 eval 越难做，而是项目边界越模糊 eval 越重要。你做的是一个明确的"问答系统"，eval 相对直接；你做的是一个"copilot"或"assistant"，用户意图开放，eval 的设计本身就是产品定义的一部分。后者正是 2024-2025 年 AI Engineer 面试的高频场景。

薪资谈判中的 Evals 溢价：为什么同样的 level 差距 200K

一个 HC（Hiring Committee）的真实对话。两个 L5 候选人，背景相似，都在 FAANG 做过 ML infra。A 的卖点是"优化了 training throughput 3x"，B 的卖点是"发现原有 eval 遗漏了 15% 的长尾 failure case，推动重新标注后模型在实际场景中的用户投诉下降 40%"。HC 的讨论不是关于谁更 technical，而是关于谁更能"own the full stack of model improvement"。B 的 offer 比 A 高了整整一个 level 的 RSU 包，总包差距 220K。

这个溢价的逻辑是：training optimization 是工程问题，可以外包或工具化；eval design 是产品-技术耦合问题，需要对人的行为和模型行为的 joint understanding，稀缺性更高。不是 training 不重要，而是它的 commoditization 速度比 eval 快得多。

薪资结构的具体数字：L4 AI Engineer（2-4 年经验）base 130K-160K，RSU 80K-150K annually，bonus 15%-20%，总包 220K-350K。L5（4-7 年）base 160K-200K，RSU 150K-300K，bonus 20%-30%，总包 350K-600K。L6 及以上 base 180K-220K，RSU 300K-500K，bonus 30%-50%，总包 600K-900K，若带团队或核心模型方向可超 1M。这些数字在 2024 年下半年的市场中，OpenAI/Anthropic 偏上限，Google/Meta 偏中位，pre-IPO 公司用更高 equity 比例替代 cash。

谈判时的一个技巧：如果你的项目有 strong eval story，在 compensation discussion 中主动提出希望 title 或 scope 能反映"model evaluation & iteration ownership"。这不是要 title 本身，而是让公司用更高 level 的 package 来 match 这个 scope 定位。

准备清单

系统性拆解面试结构（PM面试手册里有完整的 AI product eval 实战复盘可以参考），同时覆盖以下维度：

重做一个你简历上最亮眼的项目，但只用 Evals 的 lens。写出：你定义的 3 个核心 metrics，每个 metric 的计算方式，你的 ground truth 或 proxy 是怎么来的，你的 metric 和业务结果之间的 correlation 证据或合理推测。

准备两个"eval 失败"的故事。不是项目失败，而是你的 eval 设计本身有缺陷，后来怎么发现的。面试官越来越喜欢问这个，因为它测试 intellectual humility。

读透至少一个你目标公司产品的公开 eval 方法。比如 OpenAI 的 GPT-4 evals blog，Anthropic 的 Constitutional AI paper 中的 eval section，Google 的 Gemini 技术报告中的 eval 设计。不是为了背下来，而是为了理解他们的 tradeoff 逻辑。

练 3 个标准的 eval design prompt。比如："设计一个评估对话式 AI empathy 的方法"，"如何评估代码生成工具的正确性 vs 有用性"，"RAG 系统的 retrieval 和 generation 应该分开评估还是联合评估"。找朋友 mock，要求对方持续 challenge 你的 metric choice。

整理一个个人的"eval toolkit"——你知道的 metrics、它们的适用场景、局限、以及你自己在实际中使用时的变通。这个 toolkit 应该反映你的实战经验，而不是网上抄的 list。

准备讨论 LLM-as-judge 的利弊。这是 2024 年面试的热点，不是知道这个概念就行，要能讲清楚你在什么场景下会用它、什么场景下坚决不用、以及你怎么验证它的可靠性。

想清楚你的 reverse question。问面试官他们团队的 eval 现状和挑战，既能展示你的兴趣，也能帮你判断这个 team 的 maturity——如果面试官答不上来或敷衍，可能是 red flag。

常见错误

错误一：把 eval 当作"做完模型后的检查步骤"。BAD 版本："我先 train 了模型，然后做了 eval 看看效果怎么样。" GOOD 版本："我在项目第一周就定义了 success criteria，包括 offline guardrail metrics 和 online user outcome metrics，model development 和 eval infrastructure 是并行迭代的。" 面试官听到 BAD 版本的理解是：这个人没有 eval-driven development 的习惯，他的 eval 是事后找补的。

错误二：混淆了 research benchmark 和 product eval。BAD 版本："我在 MMLU 上测了 85%，所以我的模型很好。" GOOD 版本："MMLU 覆盖了我的 task 的一部分，但我的用户场景中有 30% 涉及 domain-specific reasoning，所以我额外构造了 internal benchmark，并且发现 MMLU 高分在这个 subset 上并不 correlate。" 不是 MMLU 没用，而是把它当作唯一或主要证据显示了 candidate 的 laziness 或 lack of product thinking。

错误三：在 eval design 中回避 human evaluation 的成本和局限。BAD 版本："我让人工标注了 1000 条数据作为 ground truth。" GOOD 版本："我一开始尝试了 full human annotation，但发现 inter-annotator agreement 只有 72%，在这个 level 下 1000 条数据的信号质量不够。所以我 switched to a hybrid approach：用 model-assisted pre-labeling 加上 expert adjudication on disagreement cases，最终把有效标注量提升了 3x 而成本只增加了 40%。" 这个回答展示了你对 eval 的 operational reality 的理解，而不是纸上谈兵。

FAQ

Q: 我没有做过完整的 eval system design，只在项目里用过现成的 metrics，怎么在面试中表现？

这不是劣势，如果你能讲清楚两个点：第一，你为什么选了这个 metric 而不是另一个，你的决策依据是什么；第二，这个 metric 的局限在哪里，你在实际观察中遇到过什么它 capture 不了的 case。一个真实的例子：一个候选人在简历项目里只用了 BLEU score 来评估 summarization quality，面试时他主动说："我现在回头看，BLEU 对我们这个场景是 suboptimal 的，因为我们的 summary 需要保留特定的 legal terminology，而 BLEU 对 synonym 太 strict。如果重做，我会用 LLM-based evaluation with a customized rubric，并且 validate 这个 LLM judge 的 calibration。" 这个回答没有虚构经验，但通过展示反思能力和改进路径，拿到了 strong hire。面试官要的不是你已经完美，而是你有没有能力从错误中学习。

Q: LLM-as-judge 现在很火，面试里提到会不会加分？

会，但前提是你能讲清楚它的边界条件，不是当作万能药。一个常见陷阱是候选人热情推崇 LLM-as-judge 因为它"便宜又快"，但当面试官追问"你怎么知道你的 judge LLM 不是对着你的 target LLM 的 output 在打分"时哑口无言。正确的讨论方式是分场景：在你有 high-quality human reference 的封闭任务上，LLM-as-judge 的 correlation 可以做得很好，需要报告的是这个 correlation 数字；在 open-ended creative generation 上，LLM-as-judge 的可靠性急剧下降，这时候需要 human-in-the-loop 或至少是 multiple judge aggregation。另一个 insider tip：一些面试官会故意问"如果你的 judge LLM 和 target LLM 是同一个模型怎么办"，这是在测试你是否理解 reference bias 的问题。

Q: 面试时被问到完全没准备过的 eval 场景，怎么应对？

承认不熟悉，但展示你的结构化思考框架。一个成功的真实案例：候选人在面试中被问到"如何评估一个 AI 生成的 marketing copy 的有效性"，他完全没有 mar-tech 背景。他的回答是："我不熟悉 marketing 的具体 metrics，但我可以把这个问题分解。首先，marketing copy 的 success 取决于它的目标——是 click-through rate、conversion rate、还是 brand sentiment？其次，我需要区分 output quality（copy 本身是否 fluent、on-brand）和 business impact（它是否驱动了 desired action）。对于 output quality，我可以用 LLM judge with brand voice rubric；对于 business impact，这必须依赖 online A/B test。我的 eval design 会先确保 output quality 的 gate，再谈 business impact 的 optimization。" 他没有假装 expert，但通过展示 eval 思维的通用性，拿到了 hire 的 recommendation。面试官在 debrief 中的原话是："He doesn't know marketing, but he knows how to think about measurement."

想系统准备PM面试？

获取PM面试通关手册 →