O1 Pro思考过程深度技术分析（1）

**贤言碎语**：这是关于o1 pro思考过程技术分析的深度好文，没有之一。

核心内容：

1. o1 Pro的外部表现特点
2. 对实现方式的探讨
3. 未来分析的展望

前言

本文关注的是o1 pro在推理阶段的过程探索，而非如何训练出这个模型。本质上，除了预训练之外，所有训练过程都是为了模型使用阶段的方式而设计和优化的。使用方式才是分析的核心目标，而post-training阶段的设计，则是为了优化使用阶段的表现。

关于降智，有一个需要警惕的问题：ChatGPT Pro账号仍然可能被降智。在测试o1 pro之前，务必确认账号处于正常状态。没有被降智的o1 pro有三个明显特征：

• 思考阶段会显示一个矩形框，而不是o1的样式。
• 矩形框中会显示一个没有具体数字的进度条。
• 回答是一次性快速给出的，不像o1那样流式输出。

1、o1 Pro的外部表现

o1 pro最直观的特征，就是它那明显比o1更长的思考时间。但一个容易被忽视的关键点是：它并非流式地生成最终回答，而是在某个时间点突然放出整个答案。

如果仔细观察思考过程，会发现一个有趣的现象：在最后一个思考阶段结束后，会有一段较长的等待，然后答案就突然冒出来了。最终答案应该就是在这个等待阶段中生成的。

理论上，可以根据这个最后阶段的等待时间和最终输出答案的token数量，进行线性分析。在撰写本文前，原本计划具体完成这项分析，但由于缺乏好用的SSE请求dump工具，尝试自己写一个Chrome插件，3小时内也没搞定，只能作罢。虽然Chrome DevTools能看到EventStream的时间信息，但没有导出功能。感兴趣的读者可自行尝试。技术实力强的读者，可以考虑做一个记录SSE请求每个event到达时间的浏览器插件，对未来分析ChatGPT模型行为会很有用——尤其是在API放出之前的这段时间里。

等到o1 pro API正式发布，分析会容易得多，但目前还没有。

2、实现方式的分析

2.1、目的分析

o1 pro“不是流式生成回答，而是先在思考阶段生成回答，再一次性放出”这个特质，值得深挖。

相比o1的流式回答，这种方式显然用户体验更差——等待时间明显更长。所以，这一定是为了实现某种特定目的。

是为了更好地对输出结果进行风控审核吗？虽然确实能实现更严格的审核，但ChatGPT目前已有更平衡的方案：流式输出结果，同时并行审核，发现问题立即终止回答。既然已有这套体系，o1 pro没理由非要采用这种更笨重的方式来做审核。

虽然不是风控审核，但可以有把握地推测：在产生回答后，它又经历了一个额外过程，然后才放出最终结果。

一种最简单的可能性是：增加了一个反思阶段，让模型重新审查自己的回答，确认有无错误或可优化的地方。没问题就放行，如果有问题呢？那就要继续思考，更新回答，直到通过。这才是关键所在。

2.2、思考过程的终结条件

如果是上述情况，那么o1 pro就和o1以及其他已有的推理模型有了本质区别：

• 它会知道在某个时机开始生成一个完整回答，而且这个回答被放在某种可快速提取、直接输出的结构中。
• 生成完答案后，还存在一个语义检查过程，检查不通过，就继续改进。

尽管目前还没直接观察到它“继续改进”的案例，但这种情况大概率存在，需要后续收集更多样本来验证。

如果是这样，整个过程大致是：

[思考1] -> [回答1] -> [检查1] -> [思考2] -> [回答2] -> [检查2] -> ...

虽然仍是单路推理，但它跟o1那种token级别的单路推理有区别：这是一种基于Step的单路推理，还附带了语义判定结束的功能。虽然这个粒度不叫Thought，但它更接近一种“巨大Thought的单路ToT”。

2.3、结构化的Step？

有理由相信，直到o1正式版，LLM推理阶段的思考中大概率并没有结构化的Step或Thought。因为要做到通用且可扩展太难了，对大多数场景也不必要。o1的思考阶段和回答阶段，可以仅靠一些类似message边界的特殊token来区分，虽然已有粗略的结构化，但还很弱——只有两个阶段，没有复杂转换。所以仍然可以把o1看作没有结构化的方案，技术分析和token级方案没有差别。但如果2.2节的推测成立，仅看成非结构化的token级方案就不太合适了。

那么，这个方式在推理阶段具体如何实现？训练模型在生成回答后自动触发一个检查阶段？实际上，在各种场景下都稳定执行原有的检查prompt并不容易。

不必把视角锁定在纯模型的token输出层面。实际上，完全可以用逻辑上的workflow方式来组织这个过程：内部模型先生成思考阶段和回答阶段，然后引入另一个LLM请求，用额外的prompt检查回答是否足够好。如果不够好，就继续生成第二步的思考过程和回答，直到满足要求。

当然这只是逻辑层面的设计，不一定非要弄一个workflow或2-Agent。可以在整个message流中增加检查阶段message来实现。例如：

 # decode过程在answer message结束后自动插入

 # 如果需要改进，则生成第二轮thinking message
...
 ...

这种方式让review阶段能访问thinking阶段的内容。如果不希望这样，也可以像workflow那样重新组织message history进行检查。

到了这一步，虽然看起来还是单路的推理token流，但在逻辑上它已经算是基于message的agent了。而且，这种message方式能直接兼容o1模式。考虑到o1和o1 pro大概率是同一个模型的不同使用方式，这种通用性至关重要。

2.4、思考阶段的划分

o1和o1 pro的另一个可见特征，是会产生语义分段进度展示。

之前曾在“o1模型的技术分析(2)：内部实现的更多信息”中，对思考进度的实现方式有过一些猜测。目前更倾向的观点是：内部可能产生了某种比message粒度更小的step，在thinking阶段可能有多个step，且完全由模型自行划分（这取决于训练阶段的数据构造方式）。

一方面，这种step的方式和上面的message结构化很接近。如果采用了message设计，再细化到step就很容易。另一方面，观察发现，即使是同样的任务，不同输入下，这个思考过程概要进行step划分的方式也常常不同——有时步骤很多，有时一个都没有，step的数量还与o1（不是o1 pro）的思考时间长短有关。这让人感觉更像是由模型自己生成的，而非外部旁路的思考概要模型做的语义划分。

可以推测，这种显式的step能帮助模型进行更长的思考。

对这个判断的置信度大约在60%左右。

2.5、关于多路推理

在“理解 o3 及其技术分析 [2024.12]”中提到，o3大概率是多路推理方案。考虑到o3的可能性以及上述分析，o1 pro应该不是多路推理。

2.6、其他可能性，canvas？

除了上述方案，还有没有其他可能性？确实不能完全排除。其中一种类似artifacts/canvas的方案：在思考过程中维护一个候选的回答文稿，并持续扩展和调整。直观上，这和Claude artifacts、ChatGPT canvas很相似。

这种方式和前面的message方案也有些类似——Claude artifacts也是每次重新生成完整回答。这时，answer message本身就是结构化的，其他部分结构化多少倒不重要。

但也可以像canvas或Cursor UI那样，先生成修订方案，再由独立进程合并到候选答案中。这时LLM更像是通过修订tool来操作一个文档。

目前不倾向于这种可能性——它更复杂、更难实现完善，也没有特别的必要性。

A、结语

整篇文章都是围绕“为什么o1 pro不是流式输出答案”这一点展开的技术分析。未来可能还会有新发现和思考，所以这篇标记为（1）。目前已经没有其他猜测了。

o1 pro的这个表现其实刚发布时就是这个样子，拖到最近才注意到。搜索一圈，目前还没看到其他人做类似的技术分析。

至此，对o1、o1 pro、o3的实现方式，已经有了一个大概的猜测框架。这个系列总算填完了坑。

不知道何时才能验证这些想法——也许永远都不会知道OpenAI到底是怎么实现的。

B、相关阅读

• o1模型的技术分析(1)——OpenAI亲自下场做的Agent推理模块的技术原型
• o1模型的技术分析(2)：内部实现的更多信息
• 展望o1路线的可改进方向
• 理解 o3 及其技术分析 [2024.12]

你是一名 AI 行业编辑，请围绕下面这条热点输出一份资讯解读：
热点：O1 Pro思考过程深度技术分析（1）要求：
1. 先用一句话解释这条热点在讲什么
2. 再总结它为什么重要
3. 说明会影响哪些 AI 产品或内容方向
4. 最后给出 3 个适合资讯站使用的标题