推理时计算扩展:o1范式背后的技术原理与工程实现

推理时计算:大模型能力提升的新维度 传统提升模型能力的方式是"训练时计算扩展"——更多参数、更多数据、更多训练算力。OpenAI o1开创了"推理时计算扩展"——在推理阶段投入更多计算来获得更好的输出。这就像人类的System 2思维:花更多时间思考,得到更准确的答案。 核心技术原理 隐式思维链 o1的标志性特征是"隐式思维链"——模型在生成最终回答前,先在内部进行长链推理: 传统模型: 用户问题 → 模型直接回答(快速但可能出错) o1模型: 用户问题 → 内部推理(可能数百步)→ 最终回答(慢但准确) 关键区别:o1的推理过程不是通过prompt引导的(如"让我们一步步思考"),而是通过训练内化的。模型学会了在生成答案前先"思考"。 过程奖励模型(PRM) o1的核心技术之一是过程奖励模型,它评估推理过程中每一步的质量: class ProcessRewardModel: def __init__(self, base_model): self.model = base_model # 基于强模型的PRM def score_step(self, problem, current_reasoning, new_step): """评估推理步骤的质量""" prompt = f""" 问题:{problem} 已有推理: {current_reasoning} 新步骤:{new_step} 评估这个推理步骤: 1. 正确性(1-10):这一步的推理是否正确 2. 相关性(1-10):这一步是否与解决问题相关 3. 进展性(1-10):这一步是否推进了解题 输出JSON。 """ result = self.model.generate(prompt) return parse_json(result) def score_trajectory(self, problem, full_reasoning): """评估完整推理路径""" steps = split_into_steps(full_reasoning) scores = [] for i, step in enumerate(steps): context = "\n".join(steps[:i]) score = self.score_step(problem, context, step) scores.append(score) return scores PRM与结果奖励模型(ORM)的区别: ORM只评估最终答案对不对 PRM评估每一步对不对,可以在错误发生时及时发现 PRM允许在推理过程中做搜索 推理时搜索 class InferenceTimeSearch: def __init__(self, model, prm, search_config): self.model = model self.prm = prm self.config = search_config def search(self, problem, max_depth=50, branching=4): """推理时的树搜索""" # 束搜索变体:在每个步骤保留最优的K个候选 beam = [{ "reasoning": "", "score": 0.0, "depth": 0 }] for depth in range(max_depth): candidates = [] for node in beam: if node["depth"] >= max_depth: candidates.append(node) continue # 生成多个候选步骤 steps = self.model.generate_multiple( problem, node["reasoning"], n=branching ) for step in steps: new_reasoning = node["reasoning"] + "\n" + step # PRM评估 step_score = self.prm.score_step( problem, node["reasoning"], step ) cumulative_score = ( node["score"] + step_score["correctness"] ) / (depth + 1) candidates.append({ "reasoning": new_reasoning, "score": cumulative_score, "depth": node["depth"] + 1 }) # 保留Top-K beam = sorted(candidates, key=lambda x: x["score"], reverse=True) beam = beam[:self.config["beam_width"]] # 检查是否找到答案 best = beam[0] if self._has_answer(best["reasoning"]): return self._extract_answer(best["reasoning"]) return self._extract_answer(beam[0]["reasoning"]) 训练方法推测 推理数据生成 o1需要大量高质量的推理数据来训练。这些数据可能来自: ...

2026-07-16 · 3 min · 597 words · 硅基 AGI 探索者
test time compute theory practice

大模型推理时计算:Test-time Compute 的理论与实践

Test-time Compute:推理 Scaling 的新范式 2026 年 AI 领域最重要的范式转变之一是 Test-time Compute(推理时计算)。如果说预训练 Scaling 是"让模型更聪明",那 Test-time Compute 就是"给模型更多时间思考"。这一方向正在成为突破预训练数据墙的关键路径。 一、为什么需要 Test-time Compute 1.1 预训练的边际递减 传统 Scaling Laws 显示,预训练计算量增加 10 倍,损失仅降低约 17%。但推理时计算的 Scaling 效率更高: 预训练 Scaling: 10x 计算量 → ~17% 损失降低 → ~3% 准确率提升 Test-time Compute Scaling: 10x 推理计算 → ~30-50% 准确率提升 (在推理任务上) 1.2 人类的类比 人类面对简单问题可以快速回答,面对复杂问题需要更多思考时间。大模型也应该如此: $$\text{能力} = f(\text{模型参数}, \text{训练数据}, \text{推理计算量})$$ 传统方法只优化前两项,Test-time Compute 优化第三项。 1.3 OpenAI o1/o3 的启示 OpenAI o1(2024)和 o3(2025)证明了 Test-time Compute 的巨大价值: ...

2026-06-28 · 5 min · 927 words · 硅基 AGI 探索者
perplexity pro search review

Perplexity Pro Search 评测:AI 搜索的未来形态

Perplexity Pro Search:重新定义搜索 Perplexity 不是搜索引擎,而是「答案引擎」。它的 Pro Search 功能通过多步推理和搜索整合,直接给出带引用的完整答案,而非传统搜索引擎的链接列表。这种模式正在改变人们获取信息的方式。 Pro Search 的多步推理机制 Pro Search 的核心是多步推理+搜索的交替执行: 用户问题 → 意图分析 → 子问题分解 → 逐个搜索 → 信息提取 → 交叉验证 → 综合回答 与普通搜索的区别: 维度 普通搜索 Pro Search 搜索次数 1 次 3-8 次 查询构造 用户原始输入 自动分解为子问题 结果处理 返回链接列表 提取信息并综合 引用方式 无 逐句标注来源 响应时间 <1 秒 15-60 秒 子问题分解示例: 用户问题:「比较 GPT-4o 和 Claude 3.5 的编程能力」 Pro Search 自动分解为: 「GPT-4o 编程基准测试成绩」 「Claude 3.5 Sonnet 编程基准测试成绩」 「GPT-4o vs Claude 3.5 编程对比评测」 「HumanEval benchmark GPT-4o Claude」 「SWE-bench GPT-4o Claude 3.5 results」 每个子问题独立搜索,结果汇总后生成综合对比答案。这种方式比单次搜索能获取更全面、更准确的信息。 ...

2026-06-25 · 2 min · 407 words · 硅基 AGI 探索者
鲁ICP备2026018361号