#二、逐题详细解答
#227. 什么是 test-time compute（测试时计算）？为什么 reasoning model 特别重视它？
#知识点
- inference-time scaling
- sampling / search / verification
- hard-task compute allocation
- latency-cost trade-off
#详细解答
test-time compute 指的是：模型在推理阶段不再只做“一次前向 -> 一个答案”这么简单，而是额外花算力去做多次采样、搜索、验证、重排、工具调用或程序执行。它和训练阶段多堆参数、多喂数据不同，核心是把更多算力集中用在单个困难样本上。
reasoning model 特别重视它，是因为很多推理任务的错误并不是“模型完全不会”，而是“第一次走错了路径”。这意味着如果你允许模型多尝试几条推理链，或者允许它对候选答案再验证一次，成功率往往会明显提升。数学题、代码题、逻辑题尤其如此。
但这条路的代价也很明确：时延上升、吞吐下降、成本变高。所以面试里不要把它讲成“多采样一定更好”，而是要说清：它本质是在推理阶段做算力再分配，只适合那些“额外思考能换来显著正确率收益”的任务。
#228. self-consistency（自一致性）是什么？为什么它常比单次 greedy decoding 更强？
#知识点
- multi-sample reasoning
- answer aggregation
- path diversity
- stochastic decoding advantage
#详细解答
self-consistency 的基本做法是：对同一个问题，不只生成一条 CoT，而是采样出多条不同推理链，然后对这些推理链的最终答案做聚合，常见方式是多数投票。它的直觉非常简单：如果单次 greedy decoding 容易在某个局部路径上卡住，那多试几条路径，正确答案更容易在统计上占优。
它常比单次 greedy 更强，原因不是“随机一定比确定好”，而是很多 reasoning 任务存在明显的路径噪声。模型可能知道答案附近的思路，但第一条轨迹并不稳定；多样采样能把这种不稳定平均掉。尤其在数学、逻辑、代码修复这类任务上，最终答案空间相对离散，更适合做投票聚合。
它的局限也要会讲：第一，代价线性放大；第二，如果采样出来的轨迹高度相关，多样性不足，收益会变小；第三，对于开放式任务，多数投票未必比单条最优轨迹更可靠。
#229. best-of-n / rejection sampling 的核心思想是什么？它和 RL 有什么关系？
#知识点
- candidate generation
- scoring and filtering
- offline bootstrapping
- no online credit assignment
#详细解答
best-of-n 的核心思想是：先让模型生成 n 条候选，再通过规则、verifier、reward model 或人工偏好从中挑出最好的一条。rejection sampling 更进一步，它不仅用于推理时选答案，也常用于构造训练数据——把“好样本”筛出来保留，差样本直接丢弃，然后再用这些高质量样本做 SFT 或蒸馏。
它和 RL 的关系在于：两者都在利用打分信号，但方式不同。rejection sampling 更像“先采样、再筛选、再模仿”的离线流程；RL 则更强调在线更新和信用分配，要回答“哪一步行为带来了后续高奖励”。所以 best-of-n 很适合先快速 bootstrap 一批高质量 reasoning 轨迹，而 RL 更适合继续塑形行为策略。
面试里最稳的说法是：rejection sampling 是低风险、稳定但较粗的后训练手段；它常被用来先把好轨迹筛进数据，再决定要不要上更贵更不稳的 RL。
#230. verifier / judge model 在 reasoning 系统里到底做什么？
#知识点
- generation-evaluation decoupling
- reranking
- filtering synthetic data
- search guidance
#详细解答
verifier 的核心价值，是把“生成答案”和“判断答案靠不靠谱”拆成两个角色。生成模型负责提出候选路径，verifier 负责检查哪条更可能正确、更一致或更符合任务约束。这样系统不必把所有能力都压在单个模型身上。
它的典型用法有三类。第一类是 reranking：生成多个候选，让 verifier 选最好。第二类是数据过滤：合成推理数据时，先让 teacher 生成，再用 verifier 过滤劣质轨迹。第三类是搜索控制：在 Tree of Thoughts、beam search、MCTS 中，verifier 可以当作局部估值器，帮助决定保留哪条分支。
但 verifier 不是银弹。它如果校准差、偏好错、容易被表面形式欺骗，就会把系统带向“看起来像对、其实不真对”的方向。所以算法岗面试里，讲 verifier 时一定要把“它的上限取决于 verifier 自己是否可靠”说出来。
#231. Outcome Reward Model (ORM) 和 Process Reward Model (PRM) 有什么区别？
#知识点
- final-outcome supervision
- step-level supervision
- sparse vs dense reward
- credit assignment
#详细解答
ORM 主要给整条回答或最终答案打分，它回答的是“这条输出最后值不值得奖励”。这种方式的优点是简单：任务标签通常更容易拿到，比如数学题答案对不对、代码测例过不过、最终选择是否命中。但它的问题也很明显：信号稀疏，你不知道模型是中间哪一步出了问题。
PRM 则更关心过程中的每一步是否在正确推进。它能对中间推理步骤、局部转移或关键判断给出细粒度监督，因此更适合长链条 reasoning、Agent 轨迹或那些“最后蒙对但过程很差”的任务。
所以两者最本质的区别，不在于一个更高级，而在于监督分辨率不同：ORM 更稀疏、更便宜；PRM 更细、更贵，也更难标注和训练。
#232. 为什么 process supervision 往往比只看 final answer 更细粒度？代价又是什么？
#知识点
- dense feedback
- lucky-guess suppression
- annotation cost
- style overconstraint risk
#详细解答
只看 final answer 的问题在于，它可能把“过程很好但最后算错一步”和“整个推理都很烂但蒙对了”混成一个标签。process supervision 则能更细地指出：问题拆分是否正确、关键中间结论是否靠谱、有没有无根据跳步、有没有在错误方向上越走越远。
这对 reasoning 模型尤其重要，因为很多任务真正难的地方不是最终答案本身，而是中间搜索路径。如果你只奖励终点，模型很容易学会捷径、模式匹配，甚至 reward hacking；而过程监督更容易把“稳健推理行为”直接塑进去。
但它的代价也很高：标注更贵、标准更难统一、不同人对“这一步算不算合理”可能分歧更大。再加上一旦过程模板过于僵化，模型还可能学会“按标注者喜欢的格式写过程”，而不是真正提升推理质量。
#233. 合成推理数据（synthetic reasoning data）为什么重要？它的主要风险是什么？
#知识点
- scalable supervision
- teacher-generated traces
- distribution bias
- shortcut amplification
#详细解答
人工高质量推理数据极贵，这是 reasoning 训练里最现实的瓶颈之一。合成数据的重要性就在于：强 teacher 可以批量生成问题、解题轨迹、候选答案和偏好对，让你以远低于人工标注的成本快速扩张训练集规模。
它尤其适合三类事情：第一，给小模型做 bootstrap；第二，构造特定领域或题型的定向增强数据；第三，和 verifier 配合，做“生成 -> 过滤 -> 蒸馏”的自动后训练流水线。
主要风险在于：teacher 的偏差和短板会被系统性复制；数据风格可能过于单一；错误但流畅的轨迹可能混入训练；模型还可能学到某种“老师常用套路”，而不是更一般的推理能力。所以高分回答要明确：合成数据不是越多越好，关键是 teacher 质量、多样性和过滤机制。
#234. 推理蒸馏（reasoning distillation）到底在蒸馏什么？
#知识点
- answer distillation
- trajectory distillation
- strategy transfer
- efficiency conversion
#详细解答
推理蒸馏不是只把“最终答案”从大模型压到小模型，更重要的是把大模型解决问题时的行为模式迁过去。这些行为模式包括：如何拆题、先看什么后看什么、何时验证中间结论、何时回退、何时调用工具、何时结束思考。
所以 reasoning distillation 常有几种层次。最浅的一层是 answer distillation，只学最终答案；再往上是 CoT distillation，把显式步骤一起学进去；更深一层则是把偏好、验证、搜索、工具使用等行为策略一并迁移。
这件事的本质，是把“大模型高成本 reasoning”转成“小模型更低成本但保留部分推理风格的参数能力”。因此它天然是“效率换能力”的方法，而不是平白无故凭空创造新能力。
#235. 为什么长 CoT 蒸馏有时会损害泛化？
#知识点
- polished-solution imitation
- exploration suppression
- epistemic verbalization reduction
- OOD reasoning degradation
#详细解答
长 CoT 蒸馏听起来很合理：老师把完整思路写出来，学生照着学，似乎应该更强。但问题在于，老师给出的往往是“已经想清楚后的整洁答案”，而不是“真实搜索过程”。学生容易学到的是一种 polished explanation，而不是真正的探索、怀疑、自检和回退能力。
这也是为什么一些研究会发现：solution-guided distillation 虽然能让输出更短、更顺、更像标准答案，但在数学 OOD 任务上反而掉点。因为 OOD 推理需要模型保留对不确定性的表达、保留尝试与修正，而不是总在一开始就表现得“我已经知道正确路径”。
所以面试里别把蒸馏说成纯增益。更稳的讲法是：长 CoT 蒸馏能强力传递风格和局部策略，但如果过度压缩探索行为，可能伤害真正需要搜索的泛化推理。
#236. 为什么 reasoning 模型容易出现 length bias / overthinking？
#知识点
- reward-length correlation
- verbosity as proxy
- redundant reasoning
- calibration failure
#详细解答
reasoning 模型特别容易把“更长”误学成“更好”，因为无论是人工偏好、judge 评分，还是某些 reward model，都常常会无意识地偏好更完整、更展开、更像认真思考的答案。结果模型学到的是“多写一点更容易拿高分”，而不一定是真正多做了有效推理。
这会带来两个典型后果。第一是 length bias：平均输出长度不断增长，哪怕准确率不涨。第二是 overthinking：模型明明已经够了，还继续写重复、绕圈、低信息密度的内容，甚至把原本正确的答案拖乱。
所以排查这类问题时，不能只看平均 reward 或 pass rate，而要把长度、成功率、单位 token 收益、judge 偏好和人工感受一起看。否则你会误把“越来越啰嗦”当成“越来越会想”。
#237. Tree of Thoughts、beam search、MCTS 这类搜索方法各自在解决什么问题？
#知识点
- branch exploration
- candidate pruning
- value-guided search
- combinatorial reasoning
#详细解答
这些方法的共同目标，是避免模型只沿着单条链一直往前走。Tree of Thoughts 更强调把中间“思路块”当成搜索节点，允许模型分叉探索多个思路，再根据评估结果保留更有希望的分支。它适合那些可以自然拆成阶段性思考单元的任务。
beam search 更像是固定宽度的保留策略：每一步只留得分最高的若干条轨迹，简单、实用，但容易过早丢掉后面才会变优的路径。MCTS 则更进一步，会在“探索新分支”和“利用已有高价值分支”之间动态平衡，适合有明显搜索结构和可设计局部估值的任务。
所以面试里最好不要把它们都说成“多试几次”。更准确的说法是：它们都是搜索，但状态表示、分支保留方式和打分依赖不同。
#238. self-consistency、majority voting、verifier reranking 三者怎么选？
#知识点
- answer aggregation
- label space clarity
- scorer quality dependence
- compute allocation
#详细解答
self-consistency 和 majority voting 很像，但通常 self-consistency 更强调“采样多条 reasoning path 后，对最终答案聚合”，而 majority voting 更泛指答案层面的投票。它们的优势在于简单、稳、对 verifier 依赖小，特别适合答案空间明确、可标准化比较的任务，比如数学、选择题、短代码输出。
verifier reranking 则适合另一类场景：候选答案可能形式不同，但有一个较强的外部评分器能判断哪个更可靠。这在开放式回答、长解释、复杂工具轨迹里常更有优势，因为简单多数投票未必可行。
所以选择原则很实用：如果答案空间清晰、投票成本低，就先上 self-consistency；如果 candidate 多样且 verifier 强，再考虑 reranking；如果 verifier 弱，盲目 rerank 可能还不如简单投票。
#239. 什么时候该用工具 / 程序执行器，而不是只靠自然语言推理？
#知识点
- external exact computation
- symbolic execution
- environment feedback
- reasoning-tool boundary
#详细解答
只靠自然语言推理的前提，是模型可以在内部稳定模拟出所需运算或规则流程。但一旦任务需要精确数值计算、代码执行、数据库查询、符号搜索、文件系统操作、浏览器环境反馈，仅靠口头推理就很容易出错。
这时工具的价值就在于：把“容易 hallucinate 的环节”外包给一个确定性系统。比如数学计算交给解释器，代码正确性交给单元测试，事实检索交给搜索或数据库。模型负责的是规划与解释，工具负责的是外部精确执行。
面试时最好把边界讲清楚：工具不是因为模型“不会思考”才需要，而是因为有些任务本质上更适合外部精确系统完成。真正强的 reasoning system 通常是“内部推理 + 外部工具”结合，而不是二选一。
#240. 结果奖励（outcome reward）和过程奖励（process reward）各自适合什么任务？
#知识点
- sparse reward
- dense reward
- verifiable endpoint
- long-horizon reasoning
#详细解答
如果一个任务的最终结果容易验证，比如数学题最终答案、代码单测、博弈胜负、格式化约束是否满足，那么 outcome reward 很自然，因为你能直接判断这条轨迹最后值不值得奖励。
但很多 reasoning / agent 任务的难点在于：终点信号太稀疏，或者最终成功高度依赖中间很多局部正确步骤。这时 process reward 更有价值，因为它能把“在正确方向上前进”这件事显式监督出来。
所以更稳的回答是：outcome reward 更适合“终点清晰且可自动验证”的任务；process reward 更适合“长链条、易走偏、终点稀疏、蒙对风险高”的任务。现实里很多系统会把两者混用，而不是只选一边。
#241. reasoning post-training 里，rejection sampling SFT、DPO、GRPO/PPO 怎么分工？
#知识点
- bootstrapping
- offline preference optimization
- online policy shaping
- stability-cost trade-off
#详细解答
rejection sampling SFT 通常是最稳的第一步：先让 teacher 生成候选，再筛好轨迹，把这些高质量样本直接蒸进学生模型。优点是稳定、简单、工程门槛低，特别适合 bootstrap reasoning 能力。
DPO 更像第二层：当你已经有成对偏好数据，希望离线地把模型往“更符合偏好”的方向推时，它比完整在线 RLHF 更轻、更稳。GRPO/PPO 则更进一步，适合在当前策略上持续在线采样、持续塑形行为，尤其在需要真正改变推理策略、搜索行为或长链条输出习惯时更有用。
所以分工常常不是互斥，而是阶段化：先 RS-SFT 打底，再看需不需要 DPO 做偏好校正，最后在值得的高价值场景里再上 GRPO/PPO 做更强塑形。
#242. 如何评估 reasoning model，不只是看 pass@1？
#知识点
- pass@k
- compute-normalized evaluation
- robustness
- calibration and cost frontier
#详细解答
pass@1 只回答“单次最直接输出能不能过”，但 reasoning model 的价值很多时候就在于：给它更多 test-time compute 后，它能不能稳定涨。因此至少还要看 pass@k、固定采样预算下的收益曲线、self-consistency 带来的提升幅度。
此外还要看几个维度：第一，长度归一化表现，避免模型只是靠更长输出刷分；第二，对改写、难度分桶和 OOD 的鲁棒性；第三，verifier / judge 的校准情况；第四，准确率与延迟、成本之间的 Pareto 前沿。
高分回答通常会补一句：reasoning 评估不能只看“答对多少”，还要看“花了多少算力才答对”“在难题上是不是比普通模型更值得多算”。
#243. 为什么 test-time compute scaling 不是无限加 sample 就行？
#知识点
- diminishing returns
- sample correlation
- verifier ceiling
- latency budget
#详细解答
一开始加 sample 往往有效，是因为你能覆盖到更多潜在正确路径；但继续加下去，边际收益通常很快递减。原因之一是样本相关性：模型的多条轨迹常常并不独立，它们可能只是围绕同一种错误模式轻微波动。
第二个上限来自 verifier / selection 机制。如果打分器本身分不清“真对”和“像对”，你采再多候选，也可能只是把选择噪声放大。第三个现实上限则是时延与成本：线上系统不可能无限容忍每个请求都采几十上百次。
所以 test-time scaling 真正要优化的，不只是“多采样”，而是“更高质量的多样性 + 更可靠的选择器 + 更合理的算力分配”。
#244. 小模型蒸馏大模型 reasoning 时，最容易丢掉什么？
#知识点
- exploration loss
- uncertainty expression
- backtracking behavior
- capacity bottleneck
#详细解答
小模型最容易丢掉的，不只是答案质量，而是大模型在长推理中表现出来的那些“软能力”：遇到不确定时的自我怀疑、发现冲突后的回退修正、在多条候选路径间做比较的能力，以及知道什么时候该停下检查。
原因很直接：这些行为通常都很耗容量、耗上下文、耗 test-time compute。小模型在容量和表示能力上更紧张，蒸馏时很容易把“复杂搜索行为”压缩成“表面上像样的解释文本”。
所以算法岗面试里，如果被问小模型蒸馏 reasoning，最好主动说：真正难蒸馏的不是 final answer，而是探索性和策略性行为。
#245. verifier、reward model、judge 之间的边界是什么？
#知识点
- task-specific checker
- optimization signal
- evaluation comparator
- overlapping roles
#详细解答
这三个词经常混着用，但职责最好分清。verifier 更偏“任务正确性检查器”，例如判断数学答案是否对、代码是否通过测试、候选轨迹哪条更可信。reward model 更偏训练优化信号，它的输出通常会直接进入 RL 或偏好优化目标。judge 则更偏评测器或比较器，例如在 LLM-as-a-Judge 场景下做 pairwise 比较、质量打分或 rubric-based evaluation。
它们当然会重叠：一个 judge 也能拿来当 verifier，一个 verifier 也能转成 reward。但面试里高分回答通常会强调：同一个模型可以兼任多个角色，但角色不等于模型本体，关键看它被拿来做什么。
再往前一步讲，系统设计上最好避免“同一个 judge 同时负责训练、选择和最终评测”，否则很容易形成自我强化闭环，导致你误以为模型越来越好，其实只是越来越会迎合评分器。
#246. 如果模型“想得更长但结果没变好”，你会怎么排查？
#知识点
- length-accuracy curve
- diversity diagnosis
- scorer reliability
- pipeline decomposition
#详细解答
第一步先看长度和准确率的关系：是不是长度显著增长了，但 pass@1 / pass@k 没有同步提升，甚至下降。如果是，那就高度怀疑 length bias 或 overthinking。第二步看样本多样性：额外生成的候选是不是只是同一种错误换个说法，如果多样性不足，test-time compute 就没有真正买到搜索收益。
第三步看 scorer / verifier：它是否把“更长、更像在思考”误判成“更正确”。第四步看工具链和环境反馈：如果模型本来需要程序执行或检索验证，但额外 token 只是在空想，那再长也不会变好。
所以更系统的排查思路是把链路拆成四段：生成器是否产生了新候选、搜索是否真正扩展了路径、verifier 是否可靠、最后选择是否合理。只有这样你才能判断问题到底出在“不会想”、"不会选"，还是“多想的都是废话”。