原创孔某人 2025-01-05 20:40 北京

前言

本文关注的是o1 pro在推理阶段的过程探索，而并非如何训练出o1 pro模型。

本质上除了pretraining之外，所有的训练过程都是为了模型使用阶段的方式而设计和优化的。使用方式才是分析的主要目标，而post-training阶段的设计是为了优化使用阶段的表现而设计的。

关于降智：

ChatGPT Pro账号仍然是可以被降智的，在测试o1 pro之前，请确认自己的账号没有被降智。没有被降智的o1 pro具有以下特征：

[1] 在思考阶段会显示一个矩形框，而不是o1的风格。

[2] 在矩形框中会显示一个没有具体数字的进度条。

[3] o1 pro的回答是一次性快速给出的，而不是像o1一样流式输出。

1、o1 Pro的外部表现

o1 pro的最主要特征是它较长的思考时间，明显比o1要长。

而o1 pro的一个容易被忽视的重要特征是：o1 pro并非流式地生成最终回答，而是在某个时间突然放出整个回答。

如果进一步观察其思考过程，能发现在最后一个思考阶段结束后，会有一个较长时间的等待，然后就突然放出了最终回答。最终回答应该就是在这个阶段中生成的。

实际上可以根据这个最后阶段的等待时间和最终输出答案的token数量来进行线性分析。我写本文之前也想具体做一下这件事情，但由于没有好的SSE请求dump工具，尝试自己做一个Chrome插件，在3h内也没有搞定，所以还是放弃了。虽然在Chrome DevTools中可以看到EventStream的时间信息，但它没有提供导出功能。有兴趣的读者可以自行尝试。对于前端技术较为熟悉的读者可以考虑做一个记录SSE请求每个event到达时间的浏览器插件，这对于未来对于ChatGPT模型的行为分析会很有用。特别是在API放出之前的这段时间里。

等到o1 pro API放出的时候，会更容易的来做这方面的分析，不过目前还没有。

2、实现方式的分析

2.1、目的分析

o1 pro的表现中，“不是流式地生成回答，而是先在思考阶段生成回答，然后在一次性放出”，这点是值得分析的。

首先，相对于o1的流式给出回答，这种方式的用户体验是更差的，因为等待的时间明显加长了，所以这肯定是为了实现某种目的。

这是为了更好的对输出结果进行风控审核么？虽然确实可以实现更好的审核，但目前ChatGPT是采用另一种更平衡的方式进行的：流式输出结果，同时并行地对流式结果进行审核，当发现问题时终止回答。在有这种方式作为基础的情况下，o1 pro没有特别的理由非要采用这种方式做更好的审核。

虽然不是风控审核，但我们有理由相信在产生了回答之后，它又进行了某个过程，然后才放出最终结果。

一种最简单的可能性是：增加了一个反思阶段，让模型重新对回答进行分析，确认是否有错误或可优化的地方。如果没有问题则放行。如果有问题呢？如果不做任何处理就失去了执行这一步的意义。一个最简单的处理方式是继续思考，然后更新回答，直到回答符合要求。

2.2、思考过程的终结条件

如果是上一节猜测的这种情况，那么o1 pro就与o1和其他已有的推理模型有了一些不同：

它会知道在某个时候开始生成一个完整回答，而且这个完整回答是放在某种结构中的，可以被快速提取，直接输出。

第二是在生成完答案后，存在一个语义检查的过程，如果检查不通过，则会继续改进。

虽然我目前还没有直接看到它可能是在继续改进的case，但这种情况大概率是存在的，需要我们后续继续观察更多样本。

在这种情况下，整个过程是类似下面的：

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

虽然说它仍然是一个单路推理，但这跟o1这种我们认为的在token级的单路推理还是有区别的：它是一种基于Step的单路推理，还附带了语义判定是否结束的功能。虽然这个粒度叫做Thought不太合适，但它更类似一种巨大Thought的单路的ToT。

2.3、结构化的Step？

我们有理由相信，直到o1正式版，LLM推理阶段的思考中大概并没有结构化的Step或Thought。因为它更难做，不能scale到各种场景，而且也是不必要的。o1的思考阶段和回答阶段可以仅靠一些类似message边界token的特殊token来进行区分，虽然它已经具有了某种粗略的结构化，但仍然很弱，只有两个阶段，也没有复杂转换。我仍然把它当作没有结构化的方案，技术分析与token级的方案没有差别。但如果是2.2节提到的方式，仅仅看成是非结构化的token级方案就有点不太合适了。

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

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

当然这只是逻辑上这样，即使上并非要弄一个workflow或者2-Agent来进行，可以是在整个message流中增加检查阶段message来进行，例如下面的模式：

<user message><thinking message><answer message><review prompt>  # decode过程在answer message结束后自动插入<review message># 如果需要继续改进，则生成第二轮thinking 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是完全靠模型自行划分的。（当然这由模型训练阶段的数据构造方式决定）

一方面这种step的方式其实与上面message的结构化很接近，如果采用了这种message的设计，那么再细化到step很容易。另一方面，在我的观察中，即使是对于同样的任务，不同输入的情况下，这个思考过程概要上的step的划分也经常不同。有时可能分为较多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来操作一个文档。

我目前并不倾向于这种可能性，因为它比较复杂，更难实现的完善，也没有特别的必要性。