面经 | Post-Training / RL | 🔥🔥 | Cohere
2026(9月底–10月初) Member of Technical Staff, Integration/RL Team @ Cohere | New York · Virtual · 3 轮 | 😐 Neutral | Medium-Hard
Integration/RL 组，做 LLM post-training：SFT、offline preference、大规模 RL。电面加两轮 virtual onsite。
Round 1 — Phone Coding
Preference Consistency。给一堆 pairwise preference：(winner_id, loser_id)，表示某条 response 比另一条好。要判断这批标注有没有成环；如果是 DAG，返回一种合法的 response 排序。
建成有向图，indegree + queue 做拓扑。第一遍我把边画反了，跑他们给的小例子发现两个点互相赢，应该直接报 cycle，我却吐出了半截顺序。改完之后无环返回空列表，无环返回 topo 序。
follow-up：同一个 (a,b) 出现多次要不要加权。只说了「当多重边，indegree 仍按一次算」，权重版没写。
Round 2 — Coding
Offline Preference Batching。输入是 preference 列表，每条有 prompt_id / chosen_id / rejected_id，再给 batch size B。把它们装进若干 batch，每个 batch 最多 B 条，且同一个 prompt_id 不能在同一个 batch 里出现两次。
按输入顺序贪心：维护当前 batch 里已经用过的 prompt 集合，放得下就放，否则开新 batch。末尾不满的 batch 也保留。空列表返回空，B=1 时每条自己一个 batch。
他们加了一组用例：同一 prompt 下 chosen/rejected 对调出现了两次。我只按 prompt 去重，没有处理「互相矛盾的 pair」。面试官 hint 之后改成先按 (prompt, frozenset({chosen,rejected})) 合并，矛盾的丢掉，再装 batch。合并时多数票怎么算，只口头说了「同向计票，反向抵消」，代码没写完。
Round 3 — System Design
给 Integration/RL 画一个 post-training eval harness：每次 SFT / preference / RL checkpoint 出来之后，跑一组固定 eval suite，决定能不能晋级到下一阶段训练或给研究用。
就画了 checkpoint registry、eval worker pool、suite config、结果 store。suite 里既有自动 grader（code、tool-use）也有 preference/LLM-judge 子集。晋级规则先写成「主指标不掉超过阈值，且安全套件全过」。失败的 suite 要能点进单条 sample 看 grader 输出，这块只点了一句。
追问：RL 跑到一半 policy 已经换代，还在飞的 rollout 带着旧 policy 的 reward 回来怎么办。我说 trajectory 上打 policy_version，聚合同版本再更新。旧版本的结果要不要进 offline preference 池，只提了一句「默认不进」，过滤规则没展开完。