Citation: https://mp.weixin.qq.com/s/FXGdJA8OyZvLl89rXJiyAQ

GPT 4o的问题在于本身大模型的智力水平还不够高，所以做不了复杂任务，导致很多应用场景无法实用化，而指望靠图片、视频这类新模态数据大幅提升大模型智力水平是不太可能的，尽管确实能拓展更丰富的多模态应用场景，但这类数据弥补的更多是大模型对外在多模态世界的感知能力，而不是认知能力。

4o的智力水平实际上也在提升，比如ChatGPT-4o-latest (2024-08-08)的推理明显要比GPT-4o-2024-05-13强很多。 而1o有点像是instruct with CoT datasets, 专长推理。可能作为未来多模态模型中的推理base模型，base reasoning model -> text, image, audio

OpenAI o1的做法本质上是COT的自动化。 从用户提出的问题形成树的根结点出发，最终走到给出正确答案，可以想像成类似AlphaGo下棋，形成了巨大的由COT具体步骤构成的树形搜索空间，这里COT的具体步骤的组合空间是巨大的，人写的COT未必最优。如果我们有大量逻辑数据，是由<问题，明确的正确答案>构成，则通过类似AlphaGo的Monte Carlo Tree Search（MCTS）搜索+强化学习，确实是可以训练大模型快速找到通向正确答案的COT路径的。

这里的想法和Plan Search中类似，首先生成可能的推理节点，每一个节点可能包含对于细分任务的思维链中的步骤。而使用广度搜索来进行任务的泛化，也即是路径依赖。 其中一个问题是，这里的CoT是从哪来。如果是类似于人工标注后的RLHF，那么必然对任务的广度有所局限。

如果通过基座模型Plan把一个复杂任务分解为10个步骤，哪怕单个步骤的正确率高达95%，要想最后把任务做对，10个环节的准确率连乘下来，最终的正确率只有59%，惨不忍睹。

实际的问题，但是COT和拆分成类似langgraph的node还是有所区别。不是简单的独立事件。思维链更像是narrow down的过程，将事情缩小到指定的集合中做分类或者回归。这里的描述更像是多个独立的分类问题。

o1的Model Card专门测试了Agent任务，对于简单和中等难度的Agent任务有明显提升，但是复杂的、环节多的任务准确率还是不太高。

这里的应该代表了o1内在的流程，divide&conquer问题。如果在一个思维链中无法解决时，需要拆分成多个。因此简单问题在一个思维链中提升因为基准性能的提升，而多个思维链需要考虑到概率的乘数。

大语言模型最基础的能力有三种：语言理解和表达能力、世界知识存储和查询能力以及逻辑推理能力（包括数学、Coding、推理等理科能力，这里Coding有一定的特殊性，是语言能力和逻辑掺杂在一起的混合能力，Coding从语言角度可以看成一种受限的自然语言，但是混杂着复杂的内在逻辑问题。从语言角度看，Coding貌似是容易解决的，从逻辑角度看又相对难解决。总之，Coding目前看是除了语言理解外，大模型做得最好的方向）

逻辑推理能力是哲学逻辑中的内核，是思维本身。 语言表达能力是思维的出口，而上层的表达可以是NLP，Audio或者是Video。 世界知识存储和查询能力是代表了模型的一个是压缩能力，还有一个是本身的回归能力。

但幻觉问题目前无法根治，这是制约各种应用的硬伤之一

这和我之前的假设有所出入，当然实现起来是MLP本身的掣肘，比如dropout带来的信息丢失。但幻觉应该是可以通过调节attention中的位置，比如Q-KV匹配时，让Q和KV的相关性尽可能最大化。 我们能够从数学上的提升得到一些收获，比如数学处理的概率问题。数据问题的优势在于它的线性和可复现，因此可以通过不断的迭代和微调来提高。 而更广阔的问题因为没有足够的ground truth，会导致模型无法学到真正核心的eureka point.

而为啥逻辑推理能力最难提升？因为能体现这方面的自然数据（代码、数学题、物理题、科学论文等）在训练数据中比例太低，自然大模型就学不好，尽管通过不断增加数据，能增加逻辑推理方面数据的绝对数量，但因为占比太少，这方面提升的效果和增加的总体数据规模就不成比例，效果也不会太明显，就体现在逻辑推理能力Scaling law看上去的放缓。这是很自然的。这也是为何现在为了提高模型逻辑能力，往往在预训练阶段和Post-training阶段，大幅增加逻辑推理数据占比的原因，且是有成效的。

Model card: https://assets.ctfassets.net/kftzwdyauwt9/67qJD51Aur3eIc96iOfeOP/71551c3d223cd97e591aa89567306912/o1_system_card.pdf

技术要点有三：

后训练扩展律 Post-Training Scaling Laws 已经出现，并且 Post-Training Scaling Laws 为上述技术路径的成功提供了有力支持。

模型学习的是产生合理推理的过程，MCTS 在其中的作用是诱导合理推理过程的产生或构建相应的偏序对形成细粒度奖励信号，而非直接搜索过程和最终答案。

模型的 BootStrap 有助于构建新的高质量数据，并且新的 Rationales 数据促进了模型进一步提升能力。

RLHF实际上也是商用模型能和开源的基准模型拉开差距的地方，展示了财力和算力。

第三点中的bootstrap指的是模型通过自我迭代来生成新的高质量训练数据的过程。具体来说：

1. 模型首先使用现有的[Question, Answer]数据集进行训练
2. 然后利用LLM来生成新的答案和推理过程[Rationale, Answer]
3. 如果Answer正确，那么将[Question, Rationale, Answer]作为新的训练数据来微调LLM
4. 如果不正确，那么提示Hint，可能是人为干预来引导模型生成正确的[Rationale, Answer]
5. 重复这一过程，且每次获得一个新的数据集，都从原始的模型开始进行 Fine-tune 从而防止过拟合。

有几个假设

Citation: https://mp.weixin.qq.com/s/xhV9HoeEP22RjuWTjgbPqg

• 目前阻碍模型应用「搜索」的主要难题是模型给出的答案过于雷同，缺乏多样性。

• 经过特别指令调整的模型在只生成一个答案的情况下（pass@1）通常比基础模型表现得好很多，但当需要生成多个答案时，这种优势就不明显了.

• 模型在生成答案时缺乏多样性，这对于搜索的效果非常不利。特别是在极端情况，比如采用「贪心解码」，模型给出的答案会非常相似，因为它们是从模型中重复抽取的。这种情况下，即使模型花费更多推理时间，也难以获得更好的搜索结果。

为什么多样性很重要？因为搜索的目的是找到最佳答案，而不是找到一个答案。如果模型给出的答案都是雷同的，那么搜索的结果就会受到很大的影响。 多样性和搜索结果的关系：多样性可以补充更多角度，而这些更多角度可以更全面的了解问题，从广度上来说，多样性可以提供更多的选择，从深度上来说，多样性可以提供更多的细节。但是通常广度与深度是相互矛盾的，所以多样性的提升需要在广度与深度之间取得平衡。

• 通行的大模型排行榜，例如例如 LMSYS Chatbot Arena、LiveCodeBench、OpenLLMLeaderboard

• 首先，研究人员发现，如果给模型一些简单的草图（这些草图是从已经能解决问题的代码中「回译」而来），模型就能根据这些草图写出正确的最终程序。其次，研究人员还发现，如果让模型在尝试解决问题之前，先在 LiveCodeBench 上想出一些点子（这个过程叫做 IdeaSearch / 思路搜索），然后看看模型能不能用这些点子解决问题。

先做路径规划，和蒙特卡洛树搜索的思路有点像，但是这个思路是在生成答案之前，而不是在生成答案的过程中。 这和我的想法类似, cot-and-prompt, 正确的COT可以引导模型生成正确的答案。那从泛化的角度来说即是如何对于不同问题，找到合适的COT。 有点回归到了auto-learning的问题上。

• 结果发现，模型要么完全解决不了问题（准确度为 0%），要么就能完美解决问题（准确度为 100%）。

路径依赖,有点反直觉。因为0%和100%作为两个极端，往往路径中的偏差应该是个别节点的误差不足以导致整体差距这么极端。

• 不同于之前的搜索方法（通常是搜索单个 token、代码行甚至整个程序）不一样，规划搜索是搜索解决当前问题的可能规划。这里，规划（plan）的定义是：有助于解决某个特定问题的高层级观察和草案的集合。

强化学习的做法, 能应用在泛化的场景下吗。比如在特定范围内，AlphaGo之于围棋，个别程序语言的CodeGen的路径可能是相似的。 Assumption: 泛化也许可以用LLM本身的能力来做路径，类似于Anthropic的metaprompt，用来针对于不同的应用场景生成对应的COT。当然这里的前置条件是LLM本身的知识体系中有，且足够精准。也许某种finetuned Plan LLM?

• 在这项研究中，该团队探索了多种不同方法，包括重复采样（Repeated Sampling）、思路搜索（IdeaSearch）以及新提出的规划搜索（PlanSearch）。其中前两种方法顾名思义，比较直观，这里我们重点关注新提出的规划搜索。

做法还是类似于(Code)Agent的方法论, Use hashmap≈Use Memory. Greedy Search≈Tool.

• 1. 通过提示来获取观察

• 2. 推导新的观察

• 3. 将观察变成代码

• 具体来说，对于每个叶节点，将所有观察以及原始问题 P 放入提示词来调用 LLM，以便生成问题 P 的自然语言解决方案。为了提升多样性，对于每个生成的思路，该团队通过假设该思路是错误的来生成一个额外的思路，并要求 LLM 给出批评 / 反馈，从而将提议的思路翻倍了。 然后，再将这些自然语言解决方案转译成伪代码；再把这些伪代码转译成真正的 Python 代码。

通过反复的rewrite来保证多样性吗。 也许本身在即使没有使用路径规划（规划和思路搜索）的情况下，也可以通过rewrite来提高回答质量。

• 在 Claude 3.5 Sonnet 上使用规划搜索方法时，在 LiveCodeBench 基准上得到了当前最佳的 pass@200 性能：77.0%。该表现优于不使用搜索时获得的最佳分数（pass@1 = 41.4%）以及标准的 best-of-n 采样方法的分数（pass@200 = 60.6%）。