面灵AI→

腾讯大模型算法岗一二面面经

轮次
一面二面
时间
2026-10
来源
牛客网

《面试题目》

一面

  1. 缩放点积注意力的底层原理是什么?
  2. QKV 分头投影之后,transpose(1,2) 操作起到什么作用?
  3. 多头注意力拼接结果,为什么一般要调用 contiguous()?
  4. ReAct 框架的原理与运行流程是什么?
  5. 多轮工具调用场景下,如何设计 RL 损失函数?
  6. 多轮 rollout 的 loss,是每一步调用工具后即时计算,还是完整 rollout 结束后统一计算?
  7. Agent 模型评估和普通大模型评估有哪些差异?
  8. Agent 强化学习对比单轮 LLM 强化学习有什么区别?
  9. 从损失函数角度分析,GRPO 方法存在哪些缺陷?
  10. GSPO 相比 GRPO 做了哪些核心改进?
  11. Qwen3.5-9B 原生是否具备 Agent 能力?
  12. 解释 OPD 方法使用什么损失函数,为什么选用 reverse KL 而非 forward KL?
  13. 手撕:手写多头注意力(Multi-Head Attention)。

二面

  1. 多工具 Agent 在 SFT 阶段一般会开展哪些工作?
  2. 完整一次 rollout 流程,最终的奖励值是如何计算得到的?
  3. 使用 LLM Judge 做打分评估时,是否需要传入工具返回的观测信息 Observation?
  4. 工具调用或者参数输出出错时,怎么评估模型输出的答案与执行过程?
  5. Agent 强化学习训练时,针对工具返回等待与批数据组织做过哪些优化?
  6. 多工具 Agent 的训练环境 Harness 是否需要自研?如何在该环境中开展训练?
  7. 已有成熟的开源 Agent 框架,为什么还要自研 Agent 循环与 Harness 组件?
  8. 多 Agent 系统里,主 Agent 和子 Agent 如何分工,子 Agent 的职责怎么划定?
  9. 如何量化分析模型、知识库、工具、路由模块分别对最终效果的贡献?
  10. 版本上线后效果变差,怎么定位问题发生的环节?
  11. 如何区分端到端延迟来自工具调用、数据库查询,还是模型推理?是否需要埋点统计耗时?
  12. 单 Agent 场景下,可以从哪些方向优化端到端时延?

《参考解析》

  1. 注意力实现里的三个高频追问:缩放点积注意力用 QK 点积算相似度、softmax 归一化后对 V 加权求和,除以 sqrt(d_k) 是因为点积方差随维度线性增长,不缩放会让 softmax 进饱和区、梯度趋零。transpose(1,2) 把 head 维提到前面,让每个头独立做批量矩阵乘;concat 后内存不连续,view 要求连续内存,先 contiguous() 才安全,代价是一次显存拷贝。手撕时补上 padding mask 与 causal mask 的合并、softmax 减最大值,基本就完整了。

  2. 多轮工具调用的 RL 损失设计:整段 rollout 结束后统一计算是主流,因为结果奖励(答案正确、任务完成)只有跑完才拿得到;代价是信用分配难,长轨迹上几十次调用共享一个奖励、方差大。折中是过程奖励加奖励塑形——格式、参数、必要调用给小的过程分,最终结果给大分。逐 step 即时打分需要可靠的 verifier,噪声通常更大。答清信号密度与偏差的取舍,比断言哪种更好更重要。

  3. GRPO 的两个结构性缺陷:一是重要性比率与 clip 都在 token 级计算,序列越长累积偏差越大,产生长度偏置;二是组内标准差归一化会放大近乎全错或全对的组,后期容易在无信号方向消耗算力。GSPO 的改进是把重要性比率提到序列级,用整条序列的似然比做加权与裁剪,缓解长度偏置与噪声累积,代价是序列级比率的方差控制更依赖采样规模。

  4. rollout 的奖励怎么组成:结果奖励来自标准答案、单测或规则校验;过程奖励看格式、工具调用合法性与参数正确性;再加步数超出、重复调用、无效工具这类惩罚项。用 LLM Judge 评过程时,工具返回的 Observation 必须传入,否则 judge 只能看到模型的自述,无法判断它有没有真的读返回、有没有据此推进。工具报错同理,要把错误信息纳入评分依据,才能区分「工具失败但模型正确恢复」与「忽略报错硬编答案」。

  5. Agent 评估难在哪:普通评估是单轮输入输出对比,Agent 评的是轨迹——同一任务允许多条路径,环境有状态且非确定,所以结果与过程要分开评(工具选得对不对、参数有没有编、有没有冗余调用)。可复现是前提:固定环境快照与随机种子、记录完整轨迹、把模型能力与环境抖动分开统计;除成功率外还要看平均步数、调用成功率、失败类型分布与单位任务成本。

  6. Harness 为什么自研:开源框架解决的是通用编排,而训练需要的是可控与可观测——每一步的 prompt 与返回、工具耗时、奖励分量都要能被采集回灌进训练管线,环境还要能并发、可回放、可注入故障。通用框架这些接口往往不暴露或语义不匹配,改造它的成本常常高于按自己的训练循环写一层薄的 Harness。取舍是维护成本:只写训练真正需要的那部分,别顺手做成通用平台。

  7. 端到端时延归因与优化:归因只能靠埋点,在请求入口、每次模型调用、每次工具调用与数据库查询、最终拼装处打时间戳并按 trace 串联,才能说清 p95 里模型推理、工具与网络、排队各占多少。优化按性价比排:能并行的工具调用并发发出;把串行多轮压成更少轮次(合并工具、一次返回更多信息);模型侧换更小模型、限制思考与输出长度、缓存 system prompt 前缀;结果侧做缓存与流式返回降低首字延迟。