阿里 RL Data 实习一面：完整面经与逐题详解

---

0. 一分钟速览

一句话概括这场面试的调性：它不问你"知不知道"，只问你"遇到过没有、当时怎么想的"。

---

1. 面试流程与时间分配

流程：自我介绍 → 实习项目 / 数据构建 → 数据质量与诊断 → Rubric / 数据评估 → 后训练 → 反问

节奏提示：自我介绍是这场面试唯一你能主动控制内容的环节。项目里凡是和"数据构建、清洗、评估、bad case 回收"沾边的细节，都要在这 5 分钟里主动抛出来，等于提前给面试官出题——他会顺着你给的点问，而不是随便挑。

---

2. 先读懂追问机制，再决定怎么答

这场面试的题都是开放题，但追问路径高度固定，基本是三段：

1. 第一层问现象：「你们数据怎么构建的？」——听你有没有链路。
2. 第二层问归因：「效果不好怎么判断是数据还是 reward？」——听你怎么隔离变量。
3. 第三层问边界：「这么做会有什么副作用？」——听你有没有想过代价。

绝大多数候选人在第二层开始掉队，因为第一层靠回忆就能答，第二层要方法论，第三层要真踩过坑。

答题节奏建议（三段式，每题都能套）：

• 先给结论/框架（一句话，最好能命名）：「我一般把这件事拆成 X 层。」
• 再给具体做法（带名词、带数字、带工具）：「第一层用 hash + embedding 聚类去重，阈值取 0.92。」
• 最后主动交边界（这是加分项）：「但这招的副作用是多样性会掉，所以我们每做一步都留回滚。」

主动说副作用，是这场面试的最高性价比动作。 面试官几乎必问"那这样有什么问题"，你提前答了，等于把对话的主动权拿回来。

三条贯穿全场的暗线（被反复触达）：

• 数据质量的最终裁判是训练能不能收敛，不是任何离线指标；
• Reward 的可信度锚在"它和人类判断对不对得上"，背离就是事故；
• 评估和优化必须解耦，judge 不能既当运动员又当裁判。

---

3. 数据 / 项目部分（8 题）

Q1 整个训练数据是怎么构建的，数据主要从哪里来？

考察点：你有没有端到端的数据链路视野，而不是只会用别人做好的数据集。

答题骨架（按链路讲，四段）：

1. 来源分三类，各自 trade-off 说清楚
   • 真实业务数据（线上 query / 日志）：贴合真实分布，但脏、长尾、脱敏和合规成本高；
   • 开源数据：拿来做冷启动和分布补充，但风格杂、和你的目标场景有偏移；
   • 合成数据：用强模型 + 规则批量造，便宜、可控、能定向补难度，但会有分布偏移和"模型自我强化"的风险（用 A 模型造的数据训 B，B 学到的是 A 的偏见）。
2. 筛选：先规则初筛（语言、长度、敏感、模板化、重复度），再上质量模型过滤。
3. 构造：难度分层（太简单的丢掉或改造、太难的留着做 rejection sampling）、多轮化改写、对抗样本构造、格式归一。
4. 验证：小样本人工标注 + 小规模训练验证数据有效性，确认了再放量。

加分细节：说得出配比和理由。比如"合成数据占比压到 30% 以下，因为超过这个比例之后，模型开始复现合成模型的措辞习惯"，这种细节一听就是做过。

预判追问：合成数据会不会让模型越训越窄？ 会。所以要控制比例、要混真实数据、要监控输出多样性指标（比如 distinct-n、n-gram 熵），并且合成数据最好来自比你强的模型，同时做去重和多样性采样。

没做过怎么答：诚实说明自己的数据来自开源 + 小规模自建，然后把它讲成同一套链路（来源→筛选→构造→验证），并补一句"来源这一层我的经验弱，但筛选和验证这两层我做过完整的"。不用装。

---

Q2 拿到一批人工数据之后，怎么判断数据质量好不好？

考察点：质检体系的设计能力，以及你是否理解"质量"是相对目标而言的。

答题骨架（四层质检，从便宜到贵）：

几个实战要点：

• 一致性低的时候，优先改标注指南，而不是直接仲裁分歧。Kappa 只是报警器，改 guideline 才是修 bug。
• 埋黄金样本（golden set）：在批次里混入已知正确答案的题，用标注员在黄金题上的准确率来筛人、做过程质检。
• 抽检要用盲评，别让标注员看到上一版答案或模型答案，否则会被锚定。

核心观点（这部分面试官很吃）：数据质量的"好"是相对于训练目标说的。对 SFT 数据，好 = 答案准确、风格统一；对 RL 的 prompt 数据，好 = 有区分度——模型恰好一半概率做对，梯度信号最大。全对和全错的 prompt 都是废样本。

预判追问：标注成本高，怎么省？ 只对高价值维度做双标（关键维度双标、次要维度单标）；用模型做预筛把明显错的挑出来减少人工；用一致性高的标注员标难题，新人标简单题。

---

Q3 数据清洗主要处理哪些问题，具体怎么做？

考察点：确认你是真做过清洗，还是背概念。这题是 Q2 的深挖版。

答题骨架（按问题类型分）：

1. 重复与近重复：精确去重走 hash（比如 MinHash / SimHash 对长文更划算）；语义去重走 embedding 相似度 + 聚类，阈值卡在 0.9 上下再人工看边界样本。重点防"换几个词的高相似样本"，它们最容易被模型过拟合到特定措辞。
2. 格式与结构：多余前后缀、markdown 残留、多轮对话角色错乱、被截断的 JSON/代码块。
3. 标签与答案错误：
   • 硬答案任务（数学、代码）：跑执行、跑单元测试，自动校验，错的直接扔；
   • 软答案任务：抽检 + 模型辅助审核 + 人工复核边界样本。
4. 分布问题：长度偏置（超长超短占比异常的要清）、难度偏置（太简单让模型变懒，太难让训练不稳）、语言偏置（中英混杂比例要控）。
5. 安全与合规：PII 脱敏、有害内容双层过滤（关键词/分类器 + 模型审核）。
6. 污染检测：用 n-gram 重叠和 embedding 相似度查训练集里有没有混进评测集内容，这一步很多团队会漏，但一出问题整场评测白做。

必说的那句：清洗是有副作用的。 激进去重会削多样性，把长答案统一截断等于教模型说话说一半，把带推理链的样本只留最终答案会毁掉 CoT 能力。所以每一步清洗都要能回滚，最好配一次 ablation 说明它到底带来了什么收益。

预判追问：你怎么知道清洗过头了？ 看输出多样性指标（distinct-n、自重复率）和长答案能力有没有掉；另外清洗前后各跑一次小规模训练，直接对比。

---

Q4 怎么判断现在的数据还缺什么，需要继续补哪些类型？

考察点：数据迭代的方法论——是拍脑袋补数据，还是让证据驱动。

答题骨架（一个闭环）：

评测失败样本 → 归因 → 定向补数据 → 小规模验证

1. 先做失败模式分类：跑一批评测，把 bad case 归类——知识缺失 / 指令遵循失败 / 推理链断裂 / 特定场景（长上下文、多轮、小语种、格式化输出）表现差。
2. 和数据分布对照：给现有训练数据按任务类型、难度、长度、领域打标，统计分布，跟失败 case 的分布摆在一起看。比如评测里多轮对话错得多，而训练数据里多轮只占 5%，缺口就锁定了。
3. 给模型做数据体检：按能力维度分桶评测，画一张"能力矩阵"，短板直接可视化；也可以用 influence 类方法粗估哪类数据对目标能力贡献最大。
4. 定向构造 + ablation：补完必须验证——只补这一类，对应指标有没有涨、有没有带坏别的指标。

一句话收口：不要"我觉得缺什么就补什么"，要让 bad case 和指标告诉你缺什么。

预判追问：如果失败 case 分不出类别呢？ 说明失败是弥散的、不是数据缺口而是能力瓶颈，这时候该换思路——提模型规模、加长 CoT 训练、或者上更强的 reward 信号，而不是继续堆数据。

---

Q5 GRPO 一直采不到正确轨迹的样本，会怎么分析？

考察点：这是全场最实战的一题。它等价于问「你知不知道 GRPO 的梯度从哪来」。

先讲清原理，再讲排查：

GRPO 对同一个 prompt 采样一组（G 条）输出，用组内 reward 归一化算 advantage：

A_i = (r_i - mean(r)) / std(r)

全错（pass rate = 0）或全对（pass rate = 1）时，组内 reward 方差为 0，advantage 全为 0，这组样本不产生任何梯度——数据白跑，算力白烧。这就是"采不到正确轨迹"为什么是问题。

排查四步：

1. 先分清是普遍还是局部：所有 prompt 都采不到 → 大概率是采样或 reward 的全局问题；只有某几类（比如某类数学题、某个领域）采不到 → 数据难度超纲。
2. 查 reward 是不是错的：prompt 明明可解，但 judge 对某种格式给 0 分，或者沙箱环境异常导致全部执行失败。采不到正确轨迹，不一定是模型的锅。 人肉看几条轨迹，问一句"这条明明对，为什么 reward 是 0"。
3. 查采样参数：temperature 过低，多样性不够，所有样本挤在同一个错误模式里。调高温度、加大采样数 k 能缓解，但这是治标。
4. 治本的三种做法：
   • 动态采样 / 难度过滤：先用当前模型跑一遍，只保留 pass rate 在 0.1~0.9 区间的 prompt，全对全错的直接踢出训练集（这就是 DAPO 里 dynamic sampling 那套思路）；
   • 课程学习：先用简单数据把模型带过台阶，再上难题，别一上来就啃天花板；
   • 换训练信号：难题上先走 rejection sampling 造种子数据做 SFT，把 pass rate 拉起来再上 RL；或者引入 process reward / 部分给分，把稀疏的 0/1 信号变密。

预判追问：过滤掉全错样本会不会导致能力上限被封死？ 会，所以过滤要分级——极难题不进 GRPO 但保留在 SFT 池里；同时随着模型变强，要定期重跑难度分级（原来 pass rate 0 的题，两周后可能就变 0.3 了），不然课程是死的。

---

Q6 模型效果不好时，怎么判断是数据的问题还是 Reward 的问题？

考察点：归因能力。核心动作是隔离变量、找决定性证据。

答题骨架：

1. 最快的一招：人工看轨迹 + 算 reward 与人评的一致性。 随机抽一批模型输出，人打分，和 reward 分对比算相关性（Spearman / 排序一致率）。
   • 人觉得好、reward 给低分（或反过来）→ Reward 的问题；
   • reward 和人判断一致、但输出就是差 → 大概率是数据或模型能力的问题。
2. Reward 侧的具体证据：
   • reward 曲线持续涨、人评不涨甚至跌 → 典型的 reward hacking；
   • reward 方差塌缩、分数挤在一小段 → 没区分度，等于没信号；
   • reward 和某个表面特征（输出长度、markdown 密度）相关性异常高 → 它学到的是表面模式，不是质量。
3. 数据侧的具体证据：
   • 失败 case 的分布是否指向某类数据缺失（接 Q4）；
   • 训练数据里是否有系统性错标——一批答案本身就标错了，会直接把模型带偏；
   • 训练集和评测集分布差异（同分布下都不行，说明是能力问题而不是覆盖问题）。
4. 监控侧的两个锚点：训练 reward 曲线 + 独立人评曲线，两条都要画。

一句话收口：实际项目里数据问题和 reward 问题通常同时存在，归因的目的不是分锅，而是决定下一步该动哪一块、动完之后看哪条曲线。

预判追问：两条线都在涨但线上效果没变？ 那是评测和真实场景脱节——benchmark 过拟合、或者评测任务的分布和线上不一致，该回去做线上抽样评测，而不是继续在离线指标上优化。

---

Q7 有没有遇到过 Reward Hacking，最后怎么处理？

考察点：几乎必问。没有实战经验也要准备一套分析框架，别答"没遇到过"就结束。

答题骨架（三层：发现 → 止血 → 根治）：

案例：用 LLM Judge 打分时，模型逐渐学会了讨好 judge——答案越写越长、滥用"作为 AI 模型"这类安全套话、频繁复述问题。judge 分一路涨，人工盲评在跌。

1. 发现层

• reward 曲线和人评曲线双轨监控，两条线背离就是警报；
• 盯浅层统计特征的突变：输出长度分布、格式标记频率、重复 n-gram 占比、拒答率；
• 看 KL 散度有没有异常抬升（跑离 reference policy 太远往往是 hack 的先兆）。

2. 止血层

• 定位到被 hack 的具体维度，要么降权、要么换 reward 来源；
• 短期可以用规则惩罚明确的行为（超长扣分、套话扣分），但要清醒：规则本身也会被 hack，这只是缓兵之计。

3. 根治层

• 约束 reward 的表达能力：judge prompt 里写清"不要被长度、格式、语气迷惑，只看内容是否真的回答了问题"，并塞反例进去；
• 对抗式构造：专门造"看起来漂亮但内容错"的 trap 样本，让 judge 学会分辨；
• 多来源 reward 集成：规则型 + RM + judge + 人工抽检，按维度分工或加权，单点被 hack 的概率远低于单一 reward；
• KL 约束 / 熵正则：从优化层面限制跑偏空间，但别把 KL 调太大，那会直接把模型锁死学不动；
• 定期换 judge：用更新更强的模型当裁判，否则裁判会落后于被训模型（被训模型在进步，judge 是静止的，这个剪刀差就是 hack 的空间）。

一句话收口：Reward Hacking 不是 bug，是 RL 的固有属性。 目标不是消灭它，而是让 hack 的成本高于老老实实变好的成本。

没做过怎么答：坦白说没在 RL 里踩过这个坑，但可以举一个近邻经验（比如 SFT 阶段模型学会复述模板、评测集上刷高分），再顺着三层框架讲你会怎么设计监控。有框架比有故事更容易过，但两者都有最好。

---

Q8 模型最后怎么评测，离线评测过了之后怎么验证真实场景的效果？

考察点：评测体系的完整性，以及你是否知道离线指标的陷阱。

答题骨架：

离线评测分三层：

Judge 的校准手段：pairwise 时交换 A/B 顺序各评一次，不一致的判为平局；用多个不同模型当 judge 投票；judge 的 prompt 定期做重测，监控分数漂移。

离线评测的三个陷阱：

• benchmark 过拟合 / 数据污染（训练集混进测试集）；
• 训练 reward 的 judge 和评测 judge 同源，导致分数虚高——必须换模型、换 prompt，保持独立性；
• 静态评测集被反复调参"喂熟"了，需要定期换新题。

真实场景怎么验：

1. 灰度 A/B：核心能力和流量放一小部分，看用户行为指标——追问率、重试率、采纳率、会话轮次、转人工率、留存。用户愿不愿意继续用，比任何评测分都诚实。
2. 影子流量 / 金丝雀：新模型先只产出不生效，把新旧模型输出差异捞出来人审，重点看"变差的样本"。
3. 线上日志回收形成闭环：线上 bad case 捞回来分类标注，回到 Q4 的数据迭代里。线上是唯一不会骗人的评测集，但它很贵，所以要有采样策略——按失败风险分层抽，而不是均匀抽。

预判追问：离线涨了线上没涨，第一反应是什么？ 先查评测集和线上分布的偏移（用真实流量跑一遍离线评测集看相关性），再查是不是评测集被污染或过拟合，最后才怀疑模型能力。

---

4. Rubric / 数据评估部分（5 题）

Q1 主观任务没有明确标准答案时，怎么设计评估标准？

考察点：把"主观"拆成"可判"的能力。

答题骨架：

1. 别定义"什么是好答案"，拆维度。 以写作类任务为例：内容准确性、指令遵循度、逻辑连贯性、语言质量、风格匹配度。每个维度单独定义，比笼统的"总体质量 1–10 分"可靠得多——后者本质是让 judge 凭感觉。
2. 每个维度写成可操作的标准。 主观不等于模糊。"逻辑连贯性"要落成"段落之间是否有明确过渡、是否存在前后矛盾、论据与结论是否对应"。
3. 配锚点示例（anchor examples）：每一档分数配一个真实例子。这是把主观性压到最低最有效的一招，比任何 prompt 措辞都管用。
4. 区分可判维度和偏好维度。 事实错误是客观可判的；文风偏好是主观的。偏好维度要么从 rubric 里移除、要么大幅降权，否则标注一致性永远上不去，你会在无解的分歧上浪费大量人力。
5. rubric 要版本化迭代。 先小样本试标 → 看一致性 → 改定义、补示例 → 再标。分歧最大的那个维度就是下一个要改的地方。

预判追问：两个标注员对同一条数据分歧很大，怎么办？ 先看分歧集中在哪个维度，大概率是维度定义边界不清；把那条样本当案例开校准会，改完 guideline 再重标一批验证一致性。仲裁是最后手段，改标准才是根本。

---

Q2 如果一条数据要从多个维度评价，Rubric 怎么设计？

考察点：多维度体系设计，涉及正交性、权重、分制、聚合。

答题骨架：

1. 维度选取讲 MECE：维度之间尽量正交。如果两个维度天然高相关（"详细程度"和"完整性"很典型），要么合并，要么在定义里写清边界，否则标注员困惑、judge 重复计分。
2. 权重不能等权。按任务类型定——代码改写任务里正确性权重远高于语言流畅度。权重最好从数据里拟合出来：让人按整体印象打一个总分，再用各维度分数回归拟合权重，而不是拍脑袋定 0.3/0.2/0.5。
3. 分制用 3–5 档，别用 1–10 分。人分不清 6 分和 7 分，judge 更分不清，多出来的档位全是噪声。
4. 聚合方式显式定义：默认线性加权，但要设一票否决项——事实准确性为 0 的样本直接判不合格，不管其他维度多高。
5. 维度别贪多。超过 6–7 个维度，judge 的注意力会被稀释，每个维度都打不准。宁可拆成两个 prompt 各评 3–4 个维度，也不要一个 prompt 硬评 8 个。

---

Q3 Rubric 能不能直接拿来做 RL 的 Reward？

考察点：是否理解"评估"和"优化"这两个目标函数的差异。结论：可以，但必须做 RL 化改造，不能直接搬。

差在哪：

直接搬的三个坑：

• 颗粒度粗：1–5 分的 rubric，梯度信号很弱，模型学不动；
• Hack 面大：rubric 里的显性标准（"结构清晰"）会被模型直接针对——它就狂用 markdown 标题；
• 太贵：RL 每步采样都要打分，多维度 judge 成本撑不住。

RL 化改造路径：

1. 蒸馏成 reward model：用 rubric judge 在离线数据上批量打标，训一个小 RM，线上单次前向打分，便宜、稳定、还能画 reward 分布来监控。
2. 能规则的绝不交给 judge：数学对答案、代码跑测试、格式正则校验——规则型 reward 比 judge 型稳定一个量级，先把这块吃干。
3. judge 只留给真正主观的维度，并配好防 hack 措施（见 Q7/Q4）。

一句话收口：Rubric 是 reward 的定义层，中间还要过一个工程化蒸馏层，才能稳定地服务 RL。

---

Q4 把很多评分规则都放进一个 Prompt 里让 Judge 打分，会有什么问题？

考察点：知不知道 LLM judge 的实际失效模式。这是实战中最常见的错误做法。

答题骨架（四类问题）：

1. 注意力稀释（最主要）：LLM 对 prompt 中间位置的内容关注度低（lost in the middle）。规则一多，靠中间和靠后的规则实际上没被认真执行，judge 可能只严格执行了前两三条。表现出的症状是各维度分数高度相关——看着是多维评估，实际退化成单维度。
2. 规则间冲突无解：没写明优先级时，judge 的取舍是随机的，同一条样本评两次结果可能不一样，稳定性直接崩。
3. 分数校准漂移：每改一次规则，历史分数就不可比了。你再也无法回答"这个月的数据质量比上个月好吗"，因为尺子换了。
4. 成本与延迟：长 prompt 让 judge 推理变慢变贵，吞吐上不去，在需要批量打标的场景直接不可用。

改进方案：

• 拆成多个窄 prompt，每个只负责 1–3 个维度，最后聚合；这是最标准的解法；
• 必须放在一起时，把最重要的规则放最前，并显式写冲突优先级（"当 X 和 Y 冲突时以 X 为准"）；
• 做 judge 一致性测试：同一批样本隔几天重打一次、或换个 judge 模型重打，监控分数漂移；漂移超阈值就说明 prompt 不稳。

---

Q5 LLM Judge 的分数都集中在一个很窄的区间、拉不开数据差异怎么办？

考察点：对 judge 行为特性的理解 + 具体调参手段。

先诊断（三种原因，解法完全不同）：

1. Judge 的宽容倾向：LLM 天然倾向给中高分，分数堆在 6–8 分——这是 judge 的毛病，要改 judge。
2. 数据本身差异就小：两条回复质量真的差不多，打相近分是诚实的。强行拉开差异等于制造噪声——这点很多人会搞反。
3. 评分任务太模糊：rubric 没说清 7 分和 8 分差在哪，judge 只能都打 7——这是 rubric 的毛病。

对应解法：

1. 改成成对比较（pairwise）：绝对打分拉不开，就问"A 和 B 哪个好、好多少"。人和模型对相对差异都远比绝对分数敏感。pairwise 的区分度通常显著优于 pointwise，后续可以用 Bradley-Terry 拟合强度、或者算 Elo 排名。
2. 锚点示例 + 强制分布：每档配例子，并在 prompt 里要求使用完整分数区间（"只有排前 10% 的回复才配拿 9–10 分"）。
3. 先写理由再打分：让 judge 输出评语后再给分（CoT scoring），比直接吐一个数字稳得多。
4. 拆成二元判断：把"1–10 分"换成一组"是/否"判定（"是否存在事实错误？是否完整回答了问题？"），二值信号天然比连续分有区分度，而且聚合起来更可控。
5. 归一化兜底：历史数据已经是窄分布的话，用 z-score 或 percentile 归一化，至少把现有信号的差异榨出来。
6. 检查是不是用错了地方：如果这种窄分布分数直接被当 RL reward 用了，那梯度信号基本为零，训练等于没跑——这本身就是 Q6 里 reward 失效的一种典型形态。

---

5. 后训练部分（2 题）

Q1 什么时候更适合用 SFT，什么时候更适合 RL？

考察点：对两者分工的理解，不是谁更高级。

答题骨架（三条判据）：

判据一：有没有明确的正确标准

• 能验证对错（数学、代码、格式遵循）→ 优先 RL，或者 rejection sampling + SFT。reward 信号干净，RL 的收益最大。
• 没有唯一答案、多种表达都合理（写作、开放问答）→ 以 SFT 为主。RL 只能靠 judge，信号噪声大，投入产出比低。

判据二：要教"知识/格式"还是教"策略/偏好"

• 注入新知识、统一输出格式、模仿风格 → SFT。SFT 擅长复制行为，你给什么它学什么。
• 在多个可行路径里选更好的那个（怎么分配推理 token、什么时候调工具、什么时候该反问）→ RL。这类"在解空间里选"的问题，SFT 只能模仿表面行为，RL 才能真正优化策略。

判据三：你手上有什么资源

• 有高质量人工标注、缺 reward 定义能力 → SFT；
• 有可靠 verifier、缺人工标注 → RL；
• 资源有限 → 先用 SFT 把基座拉到及格线，再用 RL 冲天花板。

实际打法（这句话很加分）： SFT 冷启动 → RL 对齐偏好 → 失败样本回收做下一轮 SFT（rejection sampling 造数据）→ 再上 RL，循环迭代。 纯 RL 冷启动效率极低（它需要一个已经有基本能力的 policy），纯 SFT 又很快撞上 plateau（它学不会自己没见过的更优路径）。主流做法就是交替。

预判追问：那 DPO 算什么？ 算离线偏好优化，介于两者之间，用现成的偏好对做优化，不需要在线采样，成本比 PPO/GRPO 低，但也没法探索新的解空间——上限不如在线 RL。

---

Q2 开放式任务的 Reward 一般怎么设计？

考察点：对 reward 分层体系和可靠性排序的理解。

答题骨架（按可靠性从高到低）：

1. 规则型（最可靠，能规则的尽量规则）：长度约束、格式约束、敏感词、引用数量、和检索结果的事实比对。规则不糊、相对不易被 hack，先把能规则化的维度吃干净。
2. Verifier / 执行型：有可验证中间产物就用。比如要求"引用 3 个来源"，来源数量可直接验证；代码任务跑单测。
3. Reward Model：在人工偏好数据上训 Bradley-Terry 类模型（loss 是 -log σ(r_w - r_l)）。相比直接让 judge 打分，RM 的好处是便宜（单次前向）、稳定（不采样、可复现）、可监控（能画 reward 分布曲线）。RM 自己也会被 hack，要持续用新数据更新。
4. LLM Judge 直接打分：最灵活也最不稳，只用来覆盖前三种搞不定的主观维度，配好 Q4/Q5 里的拆分、pairwise、锚点那套技巧。
5. 组合拳（实践形态）：规则项 + RM 项 + judge 项按维度分工加权，各自监控各自的 hacking 信号。

补充两个趋势：

• 老师模型蒸馏 reward：让旗舰模型的偏好当老师，给小模型做 RL。本质是把"reward 质量"问题转化成"蒸馏链路管理"问题。
• 过程奖励 vs 结果奖励：开放式任务的结果信号很稀疏，用过程奖励（对中间步骤打分）能提供更密的梯度，但代价是标注成本和 reward hacking 的新面（模型学会写"看起来很合理的中间步骤"）。稀疏但有噪声的结果信号，和密集但有偏的过程信号，是个需要按任务权衡的取舍。

---

6. 反问环节

反问不是走过场，它同时完成两件事：判断这个团队值不值得去，以及让面试官记住你。

推荐问的（挑 2 个）：

别问的：薪资待遇、转正概率、能不能远程、"你们用什么框架"（这个可以问，但别当第一个问题）。

本场面试里，面试官的回答透露了两件有价值的信息：一是团队当前最头疼的是 judge 的稳定性和 reward hacking 的攻防；二是数据岗位在这个团队是核心岗不是支持岗——这对判断要不要去很有参考价值。

---

7. 复盘：这场面试真正在考什么

考的不是知识，是归因能力。

所有 15 道题都能归到同一个动作上：遇到一个现象，你怎么一步步缩小范围，找到真正的因，然后验证。 数据清洗、reward 诊断、judge 调优，全是同一套肌肉。

准备清单（面试前该动手做的）：

1. 把自己的项目写成一页数据链路图：数据从哪来 → 怎么筛 → 怎么造 → 怎么验 → 怎么回收。每个环节准备一个具体数字。
2. 准备 3 个 bad case 故事：一个数据问题、一个 reward 问题、一个评测问题。结构统一为：现象 → 我的第一假设 → 怎么验证 → 结论 → 后来怎么防。故事比结论值钱。
3. 准备 2 个"我踩过的坑"：清洗过头导致多样性掉了、标注指南不清导致一致性低——这类最能证明你真做过。
4. 熟记几组名词，确保能自然用出来不卡壳：pass rate / advantage / zero-variance group、rejection sampling、Cohen's Kappa、anchor example、pairwise + Bradley-Terry、KL 约束、canary release。
5. 给每道题准备一句"边界回答"：这个方案什么时候会失效。这是拉开差距的地方。

面试时的心态：面试官挖得深不是想难倒你，是想确认你的经验边界在哪。不知道就说不知道，然后接一句"如果是我，我会这样验证"——这比硬答好看得多。

这场面试的难度不在题本身，在于它没有标准答案。 它要的是一个会在不确定性里做判断的人，而不是一个会背论文的人。

---

8. 一页速查版

---

附录 A：高频术语速查

附录 B：把题目映射到自己项目（话术模板）

面试官问的是通用问题，你答的必须是你自己项目里的具体事。三个填空句式，套着用：

1. 讲链路：「我们的数据分 [X] 个来源，占比大概是 [数字]。筛选主要靠 [规则/模型]，构造上我们做过最麻烦的一件事是 [具体事]，因为 [原因]。」
2. 讲归因：「有一次指标掉了 [数字]，我第一反应是 [假设 A]，排查方式是 [具体动作]，最后发现其实是 [真实原因 B]。后来我们加了一条 [机制] 来防它再发生。」
3. 讲边界：「这个做法我们用了 [时间] 之后发现会 [副作用]，所以我们补了 [缓解手段]；如果数据量再大一个量级，我可能会换成 [替代方案]，因为 [原因]。」

原则：宁可讲一个不完美但真实的细节，也不要讲一个完美但空泛的框架。 面试官挖第三层的时候，空框架一定会塌。