百度 大模型开发 一面

1. 你对 Claude Code、Codex、OpenHands 这类 Coding Agent 的理解是什么，它们的核心差别在哪

这类产品表面上都在做“让模型帮你写代码”，但真正拉开差距的不是补全能力，而是任务编排、工具使用、上下文管理和反馈闭环。像 Claude Code 更强调命令行工作流、仓库级理解和连续执行，适合把模型放进真实开发环境里；Codex 早期更偏代码生成和 API 能力，强在补全和局部代码理解；OpenHands 这类开源 Agent 往往更强调可扩展性和多工具编排，方便接入自己的环境和流程。

如果从工程视角看，这类 Agent 最终拼的是三件事：一是对代码仓库的建模能力，能不能理解依赖关系、调用链和修改范围；二是工具链控制能力，像搜索、测试、lint、shell、git 操作能不能形成闭环；三是失败恢复能力，写错了之后能不能自我验证、定位并回退，而不是一轮生成后就停。

2. 如果让你自己设计一个 Coding Agent，你会优先做哪些能力

我会先做任务分解、环境感知和验证闭环，而不是急着追求“自动改很多文件”。因为真实开发里最难的不是生成代码，而是判断应该改哪、改完有没有影响、失败后怎么回滚。Coding Agent 如果没有计划层和验证层，就很容易变成一个会批量制造错误的脚本。

落地时我会让它先做三步：先读仓库结构和关键文件，生成一个可解释的计划；再分阶段修改，并把每一步的假设和影响范围显式记录出来；最后自动执行测试、静态检查和局部回归。这样做的好处是人可以在中间接管，系统也更容易审计。

class SimpleCodingAgent:
    def plan(self, task):
        return ["scan_repo", "locate_files", "edit_code", "run_tests"]

    def act(self, step):
        return f"execute: {step}"

    def verify(self, result):
        return "pass" if "tests_ok" in result else "retry"

3. 系统学习过哪些 RL 算法，如果放到大模型训练里你怎么分类

如果按强化学习脉络去分，我会先分成 value-based、policy-based 和 actor-critic 三大类。像 DQN 是典型 value-based，更适合离散动作；REINFORCE 是直接 policy gradient；PPO、A2C、SAC 这类更偏 actor-critic。放到大模型后训练里，真正常见的其实是 PPO 及其变体，以及偏好优化路线，例如 DPO、IPO、KTO、ORPO、GRPO 这些。

大模型场景和经典 RL 不完全一样，因为它很少有标准环境交互，更多是静态偏好数据、裁判模型或者规则反馈。所以很多方法本质上是在“弱环境、强先验”的前提下，对策略做受约束更新。面试时如果能把经典 RL 和 RLHF / RLAIF 的差异说清楚，基本就比单纯背算法名字强很多。

4. 详细讲一下 PPO，为什么它在大模型后训练里曾经是主流方案

PPO 的核心思想是限制每次策略更新别太激进。它不会直接沿着 reward 最大化一路猛冲，而是通过 clip 或 KL 约束，把新旧策略之间的差距控制在一个相对稳定的范围内。这样做是因为策略梯度方法很容易不稳定，尤其当 reward noisy、样本昂贵时，更新太猛往往会直接训崩。

在大模型里它之所以一度主流，是因为 RLHF 早期比较依赖 reward model，而 PPO 正好提供了一套成熟的“策略 + 奖励 + value + reference”训练框架。它的缺点也很明显：链路长、组件多、调参复杂、算力贵，而且 reward 偏差会被放大。所以后来很多团队转向更轻量的偏好优化方法。

5. 你怎么理解 KL 散度，它在大模型训练里为什么这么常见

KL 散度可以理解成两个分布之间的相对差异，但它不是对称距离，更像是“如果我用分布 Q 去近似真实分布 P，会额外损失多少信息”。在大模型训练里，KL 经常拿来约束新策略不要偏离旧策略太远，本质上是在防止模型为了局部目标把原本已经具备的能力训坏。

尤其在后训练阶段，如果只盯着奖励或偏好数据，模型很可能学会一些很讨巧但整体不自然的行为。加 KL 的作用就是给更新加个刹车，让模型在优化目标的同时保持原始分布的稳定性。这不是保守，而是为了可控。

import torch

def kl_divergence(p, q):
    p = torch.softmax(p, dim=-1)
    q = torch.softmax(q, dim=-1)
    return (p * (p.log() - q.log())).sum(dim=-1).mean()

6. 原始 PPO 里的 KL 约束对应的是哪两个 policy

严格来说，对应的是当前正在更新的 policy 和 reference policy，也就是一个被冻结的旧策略分布。这个 reference 往往来自 SFT 之后的模型，或者某个较稳定的 checkpoint。它的意义是作为行为锚点，防止 PPO 为了奖励分数快速漂移。

有时候大家会混淆成“当前 policy 和上一步 policy”，但在 RLHF 里更常见的是当前策略相对于 reference 模型的 KL。因为 reference 更稳定，也更符合“别偏离原始语言分布太远”的约束需求。

7. AI 给模型看的 doc 和给人看的 doc 有什么本质区别

给人看的文档强调阅读体验、上下文铺垫和叙述完整性，而给模型看的 doc 更强调结构化、低歧义、可检索和可执行。人能自动补全很多常识，模型不行，所以给模型的文档要尽量减少模糊代词、跨段引用和隐含前提，最好明确输入、输出、约束、边界条件和失败处理。

如果是在 Agent 场景里，给模型的 doc 本质上更像“操作协议”而不是“说明文”。它不仅要让模型知道某个工具能做什么，还要知道何时调用、参数怎么填、失败后如何重试、哪些场景不该调用。好的 AI 文档不是更长，而是更规整。

8. 稀疏检索和稠密检索常用指标分别是什么，评估时你会关注什么

稀疏检索和稠密检索在评估上有很多共通指标，比如 Recall@k、MRR、nDCG、HitRate，但关注点略有不同。稀疏检索往往更看词项匹配和可解释性，在高精度关键词场景下表现稳定；稠密检索更关注语义召回能力，在 query 表达多样、同义改写多的场景更有优势。

我在实际评估时会先看召回层面有没有把真正相关文档捞上来，再看排序层面相关文档是否被放到前几位。因为很多系统不是“完全没召回”，而是“召回了但排太后”。另外还要专门看 hard negative 和长尾 query，不然离线分数很容易虚高。

9. 为什么向量库里经常要先做聚类或者 coarse quantization

本质上是为了加速近邻搜索。向量检索如果每次都对全库做精确计算，数据量一大就扛不住，所以会先把向量空间做粗粒度划分，查询时先定位可能相关的簇，再在局部细搜。这样可以在可接受的召回损失下，大幅降低计算量。

聚类还有一个隐含好处，就是它能把分布结构显式利用起来。很多向量数据天然不是均匀分布的，先分桶再搜索通常比全局暴力扫描更高效。像 IVF、PQ 这些思路本质上都在做“先粗后细”的近似检索。

10. 从 PPO 到 DPO、GRPO、DAPO、GSPO，这条路线你怎么理解

这条路线本质上是在不断减少训练链路里的重组件，同时尽可能保留偏好对齐能力。PPO 是完整 RL 框架，能力强但成本高；DPO 把偏好学习改写成更直接的对数概率优化，省掉了显式 reward model 和复杂在线采样；GRPO 进一步利用组内相对比较，减少对 value 估计的依赖。再往后的 DAPO、GSPO 这些方法，很多都在尝试让偏好优化更稳定、样本利用率更高，或者更适合大模型训练分布。

如果只背名字没有意义，关键是看每一步到底减少