海底捞 AI 工程师实习生一面：LLM as a judge、Agent 评估与 DPO/GRPO

《面试题目》

1. 自我介绍
2. 实习做了什么？
3. 遇到过哪些 bad case，根因是什么，如何解决？
4. LLM as a judge 是否也会出错，如何评判、如何解决？
5. 实习遇到的最困难的事是什么，如何解决的？
6. 如何评估 Agent？
7. DPO 和 GRPO 的区别？
8. 手撕代码：279. 完全平方数
9. 如果有紧急任务需要周末加班，如何看待？
10. 反问：组内业务，具体会做什么？

《参考解析》

bad case 这道题考的是归因能力，不是背案例。 面试官想听的是「现象 → 假设 → 验证 → 修复 → 回归」这条闭环。回答时最好挑一个你能说清数据的案例：比如某个意图的召回率突然掉了，先看是数据问题（上游字段变更、脏数据）、检索问题（索引未更新、切分粒度变了）、提示词问题（描述漂移）、还是模型问题（换版本、温度、上下文超长被截断）。归因的关键是分层排除——先看输入是否合法、再看中间表示是否正确、最后才怀疑模型，而不是一上来就调提示词。修完之后要说清怎么验证有效（离线集指标 + 线上灰度对照），否则「感觉变好了」在面试里等于没修。

LLM as a judge 会出错，而且是系统性的错。 常见的几类偏差：位置偏差（倾向选先出现或后出现的答案）、长度偏差（偏爱长回答）、自我偏好（偏爱同源模型生成的答案）、格式偏差（被排版精美但内容错的答案骗过），以及在细粒度事实判断上不如人。缓解手段是工程化的：交换候选顺序各评一次取一致结果（消位置偏差）、给评分标准与 rubric 而不是让它自由发挥、用参考答案做校准、必要时集成多个 judge 投票、对高风险样本保留人工抽检。更根本的一点是用可验证的指标替代主观打分——凡是能用规则或程序判定的（格式、引用是否真实存在、代码能否跑通）就别交给模型。

评估 Agent 比评估单轮问答难得多，因为它是多步的。 评测要拆成三层：过程指标（每一步工具调用是否必要、参数是否正确、有没有走弯路、步数是否明显超出预期）、结果指标（任务最终是否完成、完成质量、人工接管次数）、成本指标（token、延迟、外部调用费用）。评测集要覆盖成功路径和失败路径：工具报错、参数缺失、需要澄清的模糊输入、以及不应该被执行的越权请求。落地时通常用「可判定任务自动跑 + 开放式任务人评/模型评」的混合方式，并保证每次改动都能在同一套集上回归——否则 Agent 这类改动很容易按下葫芦浮起瓢。

DPO 和 GRPO 的区别，讲清楚「要不要价值模型」这条主线。 DPO（Direct Preference Optimization）跳过了显式奖励模型和强化学习循环，直接在偏好数据（chosen/rejected 成对样本）上用类似分类损失的闭式目标优化策略，工程上简单稳定、对超参不敏感，但只能吃离线成对偏好数据，探索能力有限，也容易在分布外样本上退化。GRPO（Group Relative Policy Optimization）属于策略梯度方法：对同一个 prompt 采样一组（group）回答，用组内奖励的均值作为基线来算相对优势，从而省掉独立的 value/critic 网络，显存和训练成本比 PPO 低；它需要可计算的奖励信号（规则校验、结果正确性、工具执行成功等），更适合有明确对错的任务（数学、代码、工具调用）。一句话总结：DPO 是离线偏好对齐、简单稳；GRPO 是在线可验证奖励的强化学习、能探索但依赖奖励函数质量。

手撕 279 完全平方数。 最直观的是 BFS：从 n 出发，每次减去一个完全平方数，层数就是最少个数；把 n 当节点、减平方数当边，第一次到达 0 的层数即答案，用 visited 剪枝。也可以按完全背包做 DP：dp[i] = min(dp[i - j*j] + 1)，时间复杂度 O(n√n)。完全平方数定理（拉格朗日四平方和）还能给出「答案最多是 4」的判据，可以据此做特判加速。写完主动说清复杂度与边界（n=0、n=1）。

「紧急任务要周末加班怎么看」是稳定性问题。 面试官在判断你会不会因为排期紧就撂挑子，也在判断你有没有边界感。比较稳的答法是承认项目上线或线上故障这类紧急场景确实需要顶上，同时说清你处理它的方式（先确认影响面、和团队对齐优先级、把手上工作交接清楚），而不是无条件保证「随时都能来」。实习生尤其不要过度承诺——承诺了做不到比不承诺更伤。