AI Infra一面面经

写在前面

【WeThinkIn出品】栏目专注于分享Rocky的认知思考与经验感悟，范围涵盖但不限于AI行业。

干货AIGC、AI Agent、LLM算法工程师/开发工程师面试面经秘籍分享（持续更新）：WeThinkIn/AIGC-Interview-Book欢迎大家Star～

大家好，我是Rocky Ding。

一面

根据简历中的项目定制化了三个题目，限时40分钟，三选二

回答：

题面未公开三道定制题的具体内容，因此不能补造题目或伪造答案。针对“40 分钟、三选二”的项目定制题，合理策略是先用 2～3 分钟完成选题和时间预算：快速判断每题的需求清晰度、可验证性、与自己熟悉技术栈的匹配度以及实现风险，优先选择能够形成完整闭环的两题，而不是选择看起来最炫但无法在时限内验证的题。

执行时可以把每题拆成四段：先复述目标、输入输出、约束和非目标；再给出最小可行设计与关键数据结构；然后实现主流程和最重要的异常路径；最后运行样例、自造边界用例或最小测试。建议预留至少 5～8 分钟做验证与讲解准备。若题目来自简历项目，还要说明新题与原项目哪些条件相同、哪些不同，不能机械复制已有方案。

评分重点通常不只是代码是否完成，还包括问题澄清、方案取舍、代码边界、测试意识和能否解释失败。遇到模糊条件应显式写下假设；无法完成全部功能时，应交付一个行为正确、边界明确、可继续扩展的版本，并说明剩余风险。不要为了覆盖更多功能牺牲核心正确性。

自我介绍，实习/项目/自我优势等

回答：

针对 AI Infra、政企业务和 Agentic RL 岗位，自我介绍应在 90 秒左右建立“工程系统 + 模型训练 + 业务落地”的主线，而不是逐项念简历。

可以按以下结构组织：

1. 一句话定位。 说明学历或工作阶段、主要方向，以及最相关的能力，例如大模型后训练、Agent 多轮交互、分布式训练或推理工程。
2. 选择一段最相关实习。 交代业务目标、数据规模、自己负责的模块、关键技术决策和真实验证指标。必须区分团队成果与个人贡献。
3. 选择一个代表项目。 用“问题 -> 数据/环境 -> 训练方法 -> 奖励与评测 -> 部署约束”讲清闭环。若项目涉及 OPD 或多轮 RL，要说明为什么该方法比 SFT、离线蒸馏或单轮 RL 更适合，以及失败轨迹如何处理。
4. 总结自我优势。 不说“学习能力强”这类空话，而是用证据说明：能够把论文方法落到训练代码，能处理 reward 偏差、rollout 稳定性和评测泄漏，也理解政企业务中的权限、合规、可审计与人工接管。
5. 落到岗位。 说明自己希望继续解决 Agentic RL 从环境构造、轨迹生成、训练到线上评测的系统问题。

所有指标都应给出口径、样本范围和对照组。没有线上 A/B 就明确说是离线回放或灰度数据；不能把模型自评、单次演示或团队总体收益包装成个人线上增益。

交流环节

讲解一下上述三题的思路

回答：

由于三道题的具体题面未公开，这里只能回答讲解方法，不能虚构具体算法。讲解应采用“问题定义 -> 核心不变量 -> 方案选择 -> 正确性 -> 复杂度/风险 -> 验证”的顺序。

先说明输入、输出、约束与自己做出的假设，再用一句话概括方案。算法题要讲清核心不变量和为什么不会漏解；工程题要画出数据流、状态、接口和失败路径；模型题要说明数据、目标函数、训练/推理差异和评测。然后解释为什么选择当前方案，以及为什么没有选择更复杂或更常见的替代方案。

代码讲解不应逐行朗读，而应围绕模块边界、关键状态、异常处理和测试展开。若实现未完成，要明确已完成部分的行为保证、未完成部分和后续方案。最后使用样例、边界条件、反例或测试结果证明，而不是用“应该没问题”收尾。

对项目定制题，还应主动连接简历：原项目中的哪些组件可以复用，哪些假设在新场景下失效，以及如何做最小改造。这能体现候选人理解的是问题机制，而不只是背过自己的项目代码。

第一段实习为何时间这么短

回答：

这类问题主要判断稳定性、履约意识和经历真实性。回答应直接说明客观原因、已完成的职责与交接情况，不回避，也不要贬低原团队。

如果是项目制、短期实习或学校安排，可以说清约定周期和实际完成内容；如果因业务调整、团队变化、方向不匹配或个人选择提前结束，应说明自己如何沟通、完成交接，以及从中形成了什么更清晰的职业判断。若确实存在个人决策失误，也可以承认当时评估不充分，并说明之后如何改进岗位筛选和承诺管理。

一个完整答案至少包含四点：实习起止和原定周期；提前或按期结束的真实原因；离开前完成的交付与交接；为什么当前岗位不会重复同样问题。避免使用“没学到东西”“领导不行”“工作太杂”这类情绪评价，也不要编造学校或家庭原因。

面试官真正关心的是：候选人是否能对自己的选择负责，是否完成了承诺，以及当前求职方向是否稳定。事实清楚、边界明确的回答，比试图把短经历包装成长项目更可信。

为什么不转正，而是去其它地方

回答：

回答要区分“没有转正机会”“有机会但主动放弃”和“仍未到转正节点”，不能用模糊表述让面试官猜测。

如果有转正机会但选择其他方向，可以从业务方向、技术成长、岗位职责和长期目标解释。例如原岗位更偏应用交付，而自己希望深入 Agentic RL、训练基础设施和可验证环境；或者原团队的正式岗位地域、组织方向与个人长期规划不一致。重点是说明这是一项经过比较的职业选择，而不是单纯追逐公司名气。

如果没有转正名额或结果，应如实说明团队 HC、实习性质和反馈，不把组织原因包装成主动选择；同时说明自己从该段经历中获得了哪些可迁移能力。若转正评估未通过，更应说明收到的具体反馈、采取的改进和当前证据。

最后落到当前岗位：阿里云 AI Infra 的 Agentic RL、工程系统和政企约束为何与自己的能力主线匹配。不要承诺“永远不离开”，而要证明自己理解岗位实际内容，并愿意在这个问题域形成持续积累。

选择OPD的动机以及数据筛选时的策略，为什么不使用学生错误的轨迹？

回答：

这里的 OPD 通常指 On-Policy Distillation。普通离线蒸馏让学生学习教师生成的轨迹，训练前缀主要来自教师分布；部署时前缀却来自学生自身，一旦学生早期出现偏差，后续就进入训练数据很少覆盖的状态。OPD 先让当前学生生成轨迹，再让教师在同一个学生前缀上提供 token 分布监督，从而缩小 train-serving mismatch。

一种常见目标是：

<div>

$\mathcal{L}{\mathrm{OPD}}(\theta)= \mathbb{E}{x}\mathbb{E}{y\sim\pi\theta(\cdot\mid x)} \left[ \sum_t w_t, \mathrm{KL}!\left( \pi_\theta(\cdot\mid x,y_{<t}) ,|, \pi_T(\cdot\mid x,y_{<t}) \right) \right].$

</div>

数据筛选至少要检查：任务和输入是否合法；最终答案或环境状态能否验证；工具执行是否真实成功；轨迹是否越权、超预算或依赖污染信息；学生与教师在当前前缀上的分布兼容度；长度、领域和难度是否均衡；训练集与评测集是否按任务模板、用户或环境去重。

“为什么不使用学生错误轨迹”需要谨慎回答。标准 OPD 并不必然排除所有错误轨迹。学生错误前缀恰恰是 on-policy 分布的一部分，教师若仍能在该状态下给出可靠纠偏，保留可恢复的 near-miss 可以训练错误恢复能力。项目若只保留最终正确轨迹，通常是因为完全失败后的前缀已严重偏离教师熟悉分布，教师 token 概率不再是可信监督；错误轨迹也可能包含奖励污染、工具异常或不可恢复状态，直接蒸馏会放大噪声。

更稳妥的策略不是“一错全删”，而是按可恢复性分层：保留错误发生前的有效前缀；对教师/学生 top-k 重合度低或 KL 异常的后缀降权、截断；保留经 verifier 确认的纠错轨迹；对系统故障和标注错误直接剔除。只保留成功轨迹会产生幸存者偏差并削弱恢复能力，因此必须通过消融比较成功轨迹、near-miss 和完整失败轨迹对任务成功率、恢复率和训练稳定性的影响。

过程奖励和结果奖励的本质区别是什么？过程奖励的奖励信号从哪来？如何解决过程奖励信号的偏差

回答：

结果奖励只评价最终状态，例如答案是否正确、测试是否通过、订单是否完成；过程奖励评价中间步骤或状态转移，例如是否选对工具、参数是否合法、是否取得必要证据、是否遵循流程。二者的本质区别是信用分配粒度，不是“一个客观、一个主观”。结果奖励也可能被错误 verifier 污染，过程奖励也可以来自确定性环境。

结果奖励通常更接近真实目标、较难被手工过程模板束缚，但长轨迹下稀疏、方差高，很难判断哪一步造成成败。过程奖励提供稠密反馈、加速学习，却容易把人为偏好的“标准步骤”错当成唯一正确路径，导致 reward hacking 或抑制新策略。

过程信号可来自：规则和状态机；代码测试、数据库状态和工具返回；人工逐步标注；LLM/奖励模型对步骤正确性打分；从成败轨迹训练的 Process Reward Model；逆强化学习或偏好对；以及势函数差分：

<div>

$r$

</div>

在满足条件时，potential-based shaping 能降低改变最优策略的风险。

控制偏差需要多层校准：优先使用可执行 verifier 和业务状态；让不同标注者/评估器交叉复核并测一致性；对 LLM Judge 做顺序随机化、盲评和置信度校准；用 held-out 轨迹验证过程分是否真的预测最终成功；限制过程奖励权重并保留终局奖励主导；监控“过程高分但任务失败”的反例；定期用新策略轨迹重训奖励模型，减轻分布漂移。高风险业务约束应由运行时强制，不能只变成一个可被收益抵消的负奖励。

多轮对话RL中怎么设置的双层奖励？怎么构造的用户模拟器？如何避免模拟器数据的过拟合问题？

回答：

“双层奖励”通常是 turn-level 过程奖励与 dialogue-level 终局奖励的组合。每轮奖励衡量意图识别、信息增益、工具选择、事实性、合规和对话效率；终局奖励衡量任务是否完成、用户目标是否满足、是否正确转人工以及总成本。可以写成：

<div>

$R(\tau)=\beta R_{\mathrm{terminal}}+ \sum_{t=1}^{T}\gamma^{t-1} \left(\alpha R^{\mathrm{turn}}_t-C_t-P_t\right),$

</div>

其中 $C_t$ 是时延、Token、工具调用等成本，$P_t$ 是越权、重复询问、错误承诺等惩罚。权重不能拍脑袋设置，应通过离线相关性、策略消融和线上 guardrail 校准；硬合规约束不能只靠有限惩罚表达。

用户模拟器应显式建模隐藏目标和状态。每个 episode 采样用户画像、任务目标、已知信息、耐心、语言风格、风险等级和可接受结果；模拟器只看到用户在真实场景能看到的信息，并根据 Agent 回复更新内部状态，产生下一轮话语、终止、纠正或转人工行为。对政企业务，还要覆盖信息缺失、需求变更、拒绝授权、长文本、方言/口语、对抗输入和多角色审批。

避免过拟合不能只靠增加同义改写。应按用户、组织、任务模板和时间切分训练/验证/测试，防止同一脚本换词后跨集合泄漏；使用多个不同模型、规则模拟器和真实日志混合，随机化画像、目标、错误和环境反馈；保留真实用户盲测集；比较跨模拟器泛化；对模拟器与被训 Agent 做模型家族隔离，避免共享偏好形成共谋；定期用线上人工抽检和新失败案例更新环境。

最终目标不是在一个模拟器里拿高分，而是在真实用户分布上提高任务成功率，同时不恶化错误转人工、合规、成本和用户体验。

多轮对话中评测如何进行，转人工率如何评测？怎么进行的A/B测试？

回答：

多轮评测必须以完整会话为单位，单轮 BLEU、相似度或 Judge 分不能代表任务完成。离线评测集应覆盖主要意图、长尾、高风险、信息缺失、目标变化和工具异常，并固定用户模拟器/回放环境版本。核心指标包括：端到端任务成功率、约束遵循率、事实与工具状态一致性、平均轮数、重复询问率、恢复率、P95 延迟、Token/工具成本、用户满意度和安全违规率。

转人工率要先定义 eligible conversation 和 transfer event：

<div>

$\mathrm{TransferRate}= \frac{\text{发生人工接管的有效会话数}} {\text{具备自动服务资格的有效会话数}}.$

</div>

但这个总指标不能单独优化。应区分必要转人工和可避免转人工：高风险、用户主动要求或系统能力边界内的正确转人工是好行为；Agent 误判、循环、工具失败造成的转人工才是损失。需要同时统计应转未转率、误转率、转人工前轮数、人工处理时长、人工一次解决率和转接时上下文完整率。

A/B 测试应按用户或会话稳定随机，避免同一用户跨组污染；提前定义主指标、guardrail、最小可检测效应、样本量和观察窗口。先做日志回放、影子流量和小比例灰度，再逐步放量。比较时控制渠道、用户类型、问题难度和时间效应，必要时采用分层随机或 CUPED 降低方差。实验期间监控合规、投诉、错误操作、延迟和人工队列容量，并设置自动回滚阈值。

不能只报告转人工率下降。如果下降来自 Agent 拒绝转人工、错误自信或延长对话，业务反而更差。真正的成功应表现为任务成功率提高、可避免转人工下降，同时必要转人工召回和安全指标不退化。

如何解决多轮对话的冷启动 和 业务约束遵循问题？

回答：

冷启动包含两层：新系统缺少高质量对话轨迹，新用户/新场景缺少状态。训练冷启动可以从业务规则、历史人工服务日志和专家流程构造 SFT 数据，再用多样化用户模拟器生成可验证轨迹；先训练基本意图、槽位、工具和终止能力，再进入 on-policy RL。数据必须脱敏、去重并按场景切分；不能把客服历史回复直接当成全部正确答案。上线前先做离线回放和 shadow evaluation，小流量灰度后再用真实失败案例迭代。

会话冷启动则需要在最少轮数内识别目标、收集必要槽位和权限信息。可以使用显式任务状态、分层意图路由、默认配置和澄清策略，但不能为了减少轮数猜测高风险字段。对重复用户，可以在授权后召回稳定偏好；历史推断不得覆盖当前明确指令。

业务约束应分成软约束和硬约束：语气、简洁度、优先级等可以进入 Prompt、SFT 或 reward；权限、金额、数据范围、流程状态、合规和不可逆操作必须由 Schema、规则引擎、状态机、工具鉴权和人工审批强制执行。模型只生成候选动作，执行层再次检查 precondition、幂等和副作用。

训练中可以加入合规正反例、对抗用户、拒答与正确转人工轨迹，并用约束奖励或 constrained policy optimization 减少违规；但 RL 奖励不能替代硬安全边界。评测要同时看任务成功率和每类约束违反率，并对严重违规采用零容忍门禁，而不是用平均奖励掩盖低频高损失事件。

Verl中的AgentLoop的特点是什么？

回答：

verl 的 AgentLoop 是面向多轮 rollout 与 Agentic RL 训练的轨迹生成抽象。它不是 LangGraph 一类面向线上业务编排的完整 Agent 框架，也不负责规定工具应如何定义；它关心的是如何让用户自定义循环与模型、工具或环境交互，并产出可用于 PPO/GRPO 等训练的准确轨迹。

核心接口是 AgentLoopBase.run(...)。自定义实现可以多次调用生成服务、执行工具、与环境交互或反思，最终返回 AgentLoopOutput。关键字段包括 prompt_ids、response_ids 和 response_mask：模型自己生成的 token 标为 1，工具 Observation 和 padding 标为 0，使策略损失只作用于策略生成部分。当前实现还可携带多模态数据、轨迹奖励、轮数、指标和额外字段。

它的工程特点包括：

1. 异步并发 rollout。 Worker 为样本启动协程，适合工具等待时间不一致的多轮轨迹。
2. 推理后端抽象。 可对接 vLLM、SGLang 等异步生成服务，并支持 token-in/token-out 与聊天接口。
3. 请求级负载均衡与粘性会话。 首轮选择负载较低的推理服务，后续轮次保持到同一实例，利于缓存和会话一致性。
4. 训练与 rollout 协同。 rollout 前同步训练权重并唤醒推理服务，结束后释放 KV Cache、卸载权重，为训练阶段让出资源。
5. 保留原始 token 轨迹。 多轮 RL 中若把最终 messages 重新套 chat template，工具解析和 decode-encode 可能改变 token，导致轨迹偏离行为策略。AgentLoop 直接维护连续 token 和 mask，避免这一关键 off-policy 误差。
6. 可插拔循环。 单轮、工具调用或业务自定义 AgentLoop 可以通过配置注册；框架提供调度与训练接口，工具语义、环境状态和终止条件仍由用户实现。

局限也要说明：多轮轨迹的 reward 归因、工具错误、超长上下文、环境可恢复性和并发尾延迟不会因为使用 AgentLoop 自动解决；其 API 在不同版本仍可能演进，生产项目必须锁定版本并以实际代码为准。

反问环节

业务方向：Agentic RL训练，2B方向

回答：

这条更像面试官披露的信息，而不是需要候选人作答的问题。反问的目标应是确认岗位的真实训练闭环和工程约束，而不是继续展示名词。

可以围绕以下方向提问：2B 是模型参数规模、业务线代号还是专项名称；当前 Agentic RL 的主要任务是工具调用、多轮客服、代码/数据分析还是通用政企 Agent；训练使用 PPO、GRPO、OPD 或混合方案的原因；环境和 verifier 如何构造；rollout 是在线真实系统、沙箱还是用户模拟器；最主要瓶颈是环境吞吐、reward 可靠性、长轨迹稳定性还是线上泛化；岗位需要负责算法、训练框架、推理基础设施还是评测平台中的哪些部分。

对政企业务还应询问：数据是否可出域、权限和审计如何进入训练/评测、硬约束由哪一层执行、人工接管的业务标准、上线采用何种灰度和回滚机制。最后可以问新人前三个月的交付目标及评价标准。

好的反问能帮助候选人判断“Agentic RL”是论文复现、内部平台建设还是已经连接真实业务状态的训练闭环，也让面试官看到候选人关注的是可验证、可部署和可治理的系统能力。