技术

图数据库的一些考量 LLM一些探索 Agent实践 LLM预训练 向量数据库的一些考量 fastapi+sqlalchemy进行项目开发 LLM微调实践 Python协程实现 Agent Functon Calling LLamaIndex入门 Multi-Agent探索 Python虚拟机 LLM工作流编排 Python实践 下一个平台Agent 激发LLM涌现——提示工程 LLM微调理论 大佬沉思 LLM外挂知识库 LLMOps 多模态LLM Python一些比较有意思的库 Transformers源码学习 LangChain源码学习 通用分布式计算引擎Ray Python并发 go依赖注入 go collection gc的基本原理 golang性能分析及优化 数据湖 高性能计算与存储 Linux2.1.13网络源代码学习 《大数据经典论文解读》 三驾马车学习 Spark 内存管理及调优 Yarn学习 从Spark部署模式开始讲源码分析 容器狂占内存资源怎么办? 多角度理解一致性 golang io使用及优化模式 Flink学习 c++学习 学习ebpf go设计哲学 ceph学习 学习mesh kvm虚拟化 学习MQ go编译器以及defer实现 学习go 为什么要有堆栈 汇编语言 计算机组成原理 运行时和库 Prometheus client mysql 事务 mysql 事务的隔离级别 mysql 索引 坏味道 学习分布式 学习网络 学习Linux go堆内存分配 golang 系统调用与阻塞处理 Goroutine 调度过程 重新认识cpu mosn有的没的 负载均衡泛谈 单元测试的新解读 《Redis核心技术与实现》笔记 《Prometheus监控实战》笔记 Prometheus 告警学习 calico源码分析 对容器云平台的理解 Prometheus 源码分析 并发的成本 基础设施优化 hashicorp raft源码学习 docker 架构 mosn细节 与微服务框架整合 Java动态代理 编程范式 并发通信模型 《网络是怎样连接的》笔记 go channel codereview gc分析 jvm 线程实现 go打包机制 go interface及反射 如何学习Kubernetes 《编译原理之美》笔记——后端部分 《编译原理之美》笔记——前端部分 Pilot MCP协议分析 go gc 内存管理玩法汇总 软件机制 istio流量管理 Pilot源码分析 golang io 学习Spring mosn源码浅析 MOSN简介 《datacenter as a computer》笔记 学习JVM Tomcat源码分析 Linux可观测性 学习存储 学计算 Gotty源码分析 kubernetes operator kaggle泰坦尼克问题实践 kubernetes扩缩容 神经网络模型优化 直觉上理解深度学习 如何学习机器学习 TIDB源码分析 什么是云原生 Alibaba Java诊断工具Arthas TIDB存储——TIKV 《Apache Kafka源码分析》——简介 netty中的线程池 guava cache 源码分析 Springboot 启动过程分析 Spring 创建Bean的年代变迁 Linux内存管理 自定义CNI IPAM 共识算法 spring redis 源码分析 kafka实践 spring kafka 源码分析 Linux进程调度 让kafka支持优先级队列 Codis源码分析 Redis源码分析 C语言学习 《趣谈Linux操作系统》笔记 docker和k8s安全访问机制 jvm crash分析 Prometheus 学习 Kubernetes监控 Kubernetes 控制器模型 容器日志采集 容器狂占资源怎么办? Kubernetes资源调度——scheduler 时序性数据库介绍及对比 influxdb入门 maven的基本概念 《Apache Kafka源码分析》——server Kubernetes类型系统 源码分析体会 《数据结构与算法之美》——算法新解 Kubernetes源码分析——controller mananger Kubernetes源码分析——apiserver Kubernetes源码分析——kubelet Kubernetes介绍 ansible学习 Kubernetes源码分析——从kubectl开始 jib源码分析之Step实现 线程排队 jib源码分析之细节 跨主机容器通信 jib源码分析及应用 为容器选择一个合适的entrypoint kubernetes yaml配置 《持续交付36讲》笔记 mybatis学习 程序猿应该知道的 无锁数据结构和算法 CNI——容器网络是如何打通的 为什么很多业务程序猿觉得数据结构和算法没用? 串一串一致性协议 当我在说PaaS时,我在说什么 《数据结构与算法之美》——数据结构笔记 PouchContainer技术分享体会 harbor学习 用groovy 来动态化你的代码 精简代码的利器——lombok 学习 《深入剖析kubernetes》笔记 编程语言那些事儿 rxjava3——背压 rxjava2——线程切换 spring cloud 初识 《深入拆解java 虚拟机》笔记 《how tomcat works》笔记 hystrix 学习 rxjava1——概念 Redis 学习 TIDB 学习 如何分发计算 Storm 学习 AQS1——论文学习 Unsafe Spark Stream 学习 linux vfs轮廓 《自己动手写docker》笔记 java8 实践 中本聪比特币白皮书 细读 区块链泛谈 比特币 大杂烩 总纲——如何学习分布式系统 hbase 泛谈 forkjoin 泛谈 看不见摸不着的cdn是啥 《jdk8 in action》笔记 程序猿视角看网络 bgp初识 calico学习 AQS——粗略的代码分析 我们能用反射做什么 web 跨域问题 《clean code》笔记 《Elasticsearch权威指南》笔记 mockito简介及源码分析 2017软件开发小结—— 从做功能到做系统 《Apache Kafka源码分析》——clients dns隐藏的一个坑 《mysql技术内幕》笔记 log4j学习 为什么netty比较难懂? 递归、回溯、动态规划 apollo client源码分析及看待面向对象设计 学习并发 docker运行java项目的常见问题 OpenTSDB 入门 spring事务小结 分布式事务 javascript应用在哪里 《netty in action》读书笔记 netty对http2协议的解析 ssl证书是什么东西 http那些事 苹果APNs推送框架pushy apple 推送那些事儿 编写java框架的几大利器 java内存模型和jvm内存布局 java exception Linux IO学习 netty内存管理 测试环境docker化实践 netty在框架中的使用套路 Nginx简单使用 《Linux内核设计的艺术》小结 Go并发机制及语言层工具 Linux网络源代码学习——数据包的发送与接收 《docker源码分析》小结 docker namespace和cgroup zookeeper三重奏 数据库的一些知识 Spark 泛谈 链式处理的那些套路 netty回顾 Thrift基本原理与实践(二) Thrift基本原理与实践(一) 回调 异步执行抽象——Executor与Future Docker0.1.0源码分析 java gc Jedis源码分析 深度学习泛谈 Linux网络命令操作 JTA与TCC 换个角度看待设计模式 Scala初识 向Hadoop学习NIO的使用 以新的角度看数据结构 并发控制相关的硬件与内核支持 systemd 简介 quartz 源码分析 基于docker搭建测试环境(二) spring aop 实现原理简述 自己动手写spring(八) 支持AOP 自己动手写spring(七) 类结构设计调整 分析log日志 自己动手写spring(六) 支持FactoryBean 自己动手写spring(九) 总结 自己动手写spring(五) bean的生命周期管理 自己动手写spring(四) 整合xml与注解方式 自己动手写spring(三) 支持注解方式 自己动手写spring(二) 创建一个bean工厂 自己动手写spring(一) 使用digester varnish 简单使用 关于docker image的那点事儿 基于docker搭建测试环境 分布式配置系统 JVM执行 git maven/ant/gradle/make使用 再看tcp kv系统 java nio的多线程扩展 《Concurrency Models》笔记 回头看Spring IOC IntelliJ IDEA使用 Java泛型 vagrant 使用 Go常用的一些库 Python初学 Goroutine 调度模型 虚拟网络 《程序员的自我修养》小结 Kubernetes存储 访问Kubernetes上的Service Kubernetes副本管理 Kubernetes pod 组件 Go基础 JVM类加载 硬币和扑克牌问题 LRU实现 virtualbox 使用 ThreadLocal小结 docker快速入门

架构

bert rerank微调 大模型推理tips RAG向量检索与微调 dddfirework源码分析 RAG与知识图谱 大模型推理服务框架vLLM 大模型推理服务框架 模型服务化(未完成) 大模型Post-Training 大模型训练 大模型推理 从Attention到Transformer k8s设备管理 ddd从理念到代码 如何应用LLM 小鼠如何驾驭大象(LLM)? 多类型负载协调员Koordinator controller-runtime细节分析 finops学习 kubevela多集群 kubevela中cue的应用 基于k8s的工作流 kubevela源码分析 容器和CPU那些事儿 数据集管理fluid 应用管理平台kubevela karmada支持crd 多集群管理 AutoML和AutoDL 特征平台 实时训练 分布式链路追踪 K8S YAML 资源清单管理方案 tensorflow原理——python层分析 如何学习tensorflow 数据并行——allreduce 数据并行——ps 推荐系统embedding原理及实践 机器学习中的python调用c 机器学习训练框架概述 tensornet源码分析 大模型训练和推理 X的生成——特征工程 tvm tensorflow原理——core层分析 模型演变 《深度学习推荐系统实战》笔记 keras 和 Estimator tensorflow分布式训练 分布式训练的一些问题 基于Volcano的弹性训练 图神经网络 pytorch弹性分布式训练 从混部到统一调度 从RNN到Attention pytorch分布式训练 CNN 《动手学深度学习》笔记 pytorch与线性回归 多活 volcano特性源码分析 推理服务 kubebuilder 学习 mpi 学习pytorch client-go学习 提高gpu 利用率 GPU与容器的结合 GPU入门 AI云平台梳理 tensorflow学习 tf-operator源码分析 k8s批处理调度/Job调度 喜马拉雅容器化实践 Kubernetes 实践 学习rpc BFF openkruise学习 可观察性和监控系统 基于Kubernetes选主及应用 《许式伟的架构课》笔记 Admission Controller 与 Admission Webhook 发布平台系统设计 k8s水平扩缩容 Scheduler如何给Node打分 Scheduler扩展 深入controller openkruise cloneset学习 controller-runtime源码分析 pv与pvc实现 csi学习 client-go informer源码分析 kubelet 组件分析 调度实践 Pod是如何被创建出来的? 《软件设计之美》笔记 mecha 架构学习 Kubernetes events学习及应用 CRI——kubelet与容器引擎之间的接口 资源调度泛谈 业务系统设计原则 grpc学习 元编程 以应用为中心 istio学习 下一代微服务Service Mesh 《实现领域驱动设计》笔记 概率论 serverless 泛谈 《架构整洁之道》笔记 处理复杂性 那些年追过的并发 服务器端编程 网络通信协议 架构大杂烩 如何学习架构 《反应式设计模式》笔记 项目的演化特点 反应式架构摸索 函数式编程的设计模式 服务化 ddd反模式——CRUD的败笔 研发效能平台 重新看面向对象设计 业务系统设计的一些体会 函数式编程 《左耳听风》笔记 业务程序猿眼中的微服务管理 DDD实践——CQRS 项目隔离——案例研究 《编程的本质》笔记 系统故障排查汇总及教训 平台支持类系统的几个点 代码腾挪的艺术 abtest 系统设计汇总 《从0开始学架构》笔记 初级权限系统设计 领域驱动理念 现有上传协议分析 移动网络下的文件上传要注意的几个问题 推送系统的几个基本问题 做配置中心要想好的几个基本问题 不同层面的异步 分层那些事儿 性能问题分析 用户认证问题 资源的分配与回收——池 消息/任务队列

标签

k8s设备管理 多类型负载协调员Koordinator controller-runtime细节分析 finops学习 kubevela多集群 kubevela中cue的应用 基于k8s的工作流 kubevela源码分析 容器和CPU那些事儿 数据集管理fluid 应用管理平台kubevela karmada支持crd 多集群管理 K8S YAML 资源清单管理方案 从混部到统一调度 volcano特性源码分析 kubebuilder 学习 client-go学习 tf-operator源码分析 k8s批处理调度/Job调度 喜马拉雅容器化实践 Kubernetes 实践 openkruise学习 基于Kubernetes选主及应用 Admission Controller 与 Admission Webhook k8s水平扩缩容 Scheduler如何给Node打分 Scheduler扩展 深入controller openkruise cloneset学习 controller-runtime源码分析 pv与pvc实现 csi学习 client-go informer源码分析 kubelet 组件分析 调度实践 Pod是如何被创建出来的? Kubernetes events学习及应用 CRI——kubelet与容器引擎之间的接口 资源调度泛谈 如何学习Kubernetes 以应用为中心 kubernetes operator kubernetes扩缩容 serverless 泛谈 什么是云原生 自定义CNI IPAM docker和k8s安全访问机制 Kubernetes监控 Kubernetes 控制器模型 Kubernetes资源调度——scheduler Kubernetes类型系统 Kubernetes源码分析——controller mananger Kubernetes源码分析——apiserver Kubernetes源码分析——kubelet Kubernetes介绍 Kubernetes源码分析——从kubectl开始 kubernetes yaml配置 CNI——容器网络是如何打通的 当我在说PaaS时,我在说什么 《深入剖析kubernetes》笔记 Kubernetes存储 访问Kubernetes上的Service Kubernetes副本管理 Kubernetes pod 组件
bert rerank微调 大模型推理tips LLM一些探索 Agent实践 LLM预训练 RAG向量检索与微调 LLM微调实践 RAG与知识图谱 大模型推理服务框架vLLM Agent Functon Calling LLamaIndex入门 Multi-Agent探索 LLM工作流编排 大模型推理服务框架 模型服务化(未完成) 大模型Post-Training 大模型训练 大模型推理 从Attention到Transformer 下一个平台Agent 激发LLM涌现——提示工程 LLM微调理论 大佬沉思 LLM外挂知识库 LLMOps 多模态LLM Transformers源码学习 LangChain源码学习 如何应用LLM 小鼠如何驾驭大象(LLM)? AutoML和AutoDL 特征平台 实时训练 tensorflow原理——python层分析 如何学习tensorflow 数据并行——allreduce 数据并行——ps 推荐系统embedding原理及实践 机器学习中的python调用c 机器学习训练框架概述 tensornet源码分析 大模型训练和推理 X的生成——特征工程 tvm tensorflow原理——core层分析 模型演变 《深度学习推荐系统实战》笔记 keras 和 Estimator tensorflow分布式训练 分布式训练的一些问题 基于Volcano的弹性训练 图神经网络 pytorch弹性分布式训练 从RNN到Attention pytorch分布式训练 CNN 《动手学深度学习》笔记 pytorch与线性回归 推理服务 mpi 学习pytorch 提高gpu 利用率 GPU与容器的结合 GPU入门 AI云平台梳理 tensorflow学习 kaggle泰坦尼克问题实践 神经网络模型优化 概率论 直觉上理解深度学习 如何学习机器学习 深度学习泛谈

LLM一些探索

2024年09月21日

简介(未完成)

长文本生成

Agent+RAG+大纲驱动,AI创作新风暴 未读

上下文记忆

智源推出下一代检索增强大模型框架MemoRAG

融合LLM和RL来生成Hidden COT(后续移到专门一文)

RL从未走远

LLM的范式转移:RL带来新的 Scaling Law2018 年,Lex Fridman 邀请 Ilya 来 MIT 客座讲一节课,Ilya 选择的主题是 RL 和 self-play,因为他认为这是通往 AGI 的路上最关键的方法之一。Ilya 在讲座中用一句话概括了强化学习:让 AI 用随机路径去尝试一个新的任务,如果效果超出预期,就更新神经网络的权重让 AI 记得多使用成功的实践,然后开始下一次尝试。这个概括中可以看到强化学习和其他 AI 范式的重要区别,经典三大范式(监督学习、非监督学习、强化学习)中只有强化学习的假设是让 AI 进行自主探索、连续决策,这个学习方式最接近人类的学习方式,也符合我们想象中的 AI agent 应该具备的自主行动能力。强化学习的核心在于”探索”(Explore)和”利用”(Exploit)之间的权衡。LLM 在”利用”现有知识上做到了现阶段的极致,而在”探索”新知识方面还有很大潜力,RL 的引入就是为了让 LLM 能通过探索进一步提升推理能力。在实现 RL 的过程中,有两个核心组件。他们之间一直在反复交互,agent 在环境中执行 action,并且根据环境的变化评估 reward:

  1. Environment:AI 探索完成任务的环境,当 Alphago 下围棋时,环境就是 19x19 的棋盘。环境会发生变化,AI 会从环境变化中收到 reward value 判断过去的那一系列探索是否有明显的收益,例如距离下围棋胜利是否更接近了。
  2. Agent:agent 会根据对环境的观测和感知来输出一个动作,目标是得到更高的 reward。agent 这个概念最早就是来自强化学习。 PS: Environment ==> reward ==> agent ==> action ==> environment ==> reward ==> agent ==> action ==> … 如果把这里的 agent 主体换成 LLM,那么会在探索的过程中做很多 LLM inference。因此这里 RL 在 LLM 中应用的思路本质是用 inference time 换 training time,来解决模型 scale up 暂时边际收益递减的现状。LLM 直接生成是可以类比系统 1 的慢思考。而 RL 就为 LLM 带来了系统 2 慢思考。

RLHF下一步 O1

万字长文解析OpenAI o1 Self-Play RL技术路线OpenAI o1 可以通过 Self-Play 的方式提升模型 Reasoning 的能力,o1 是怎么实现这样的能力呢,纯粹从推理态来看是 inference time thinking 做到的,就是在回答用户问题之前,模型会陷入一个思考的过程。逐步思考,提出假设,并且反思,以实现 Reasoning 能力。这里面的 thinking 流程是模型和其他大模型最大的不同,在这中间经历了相当长时间的思考阶段。思考的内容,目前在 ChatGPT 的客户端中可以做了隐藏(防止被蒸馏)。虽然不清楚背后实现的具体逻辑,但是从目前已有的接口来看,o1 至少已经能够实现:提出假设,验证思路,反思过程这三种主要的逻辑推理能力。

大语言模型的主要学习策略从 RLHF 的巨大成功之后,也出现过摇摆。以 next token prediction 作为代表的 Behavior Clone 思路主要的手段是预训练和 SFT 为主的,主要强调从海量知识中自监督学习加上专家数据的示教。但是这一条路径遇到了很大的困难,我们如今已经几乎耗尽了几乎所有互联网上所有的语料,但是极强的智能也没有出现。同时 SFT 作为 Behavior Clone 的上限是比较低的,大多数情况下需要堆叠大量高质量语料,成本几乎成为了垂直领域难以负担的问题。更大的问题在于 SFT 几乎无法囊括负例的示教,对于 trial-n-error 的自我博弈智能来说,只能利用其中比例极低的正例。所以祖师爷 John Schulman 的 PPO 加上 RLHF 力挽狂澜,把 GPT-3 拉出黑暗,直接进化到 InstructGPT,用人类反馈进行建模引爆了整个领域。但是我们现在又到了一个十字路口,大模型看起来好像是一个死记硬背的书呆子,推理能力迟迟没有见到突飞猛进的变化,大模型 Self-Play 能否通过部分领域示教数据,模型通过自我博弈持续提升策略?这里面需要有两个先决条件:Generator 和 Verifier 都要足够强。语言和游戏在这个方面是截然相反的,游戏中的行为生成是困难的而价值评判是简单的:对于路边看棋大爷下好一步棋很难,但是判断这一步下的好不好他还是可以的。语言模型生成行为是容易的,但是判断生成的好坏是困难的,1B 的模型都可以滔滔不绝证明哥德巴赫猜想,但是判断每一步是否正确却非常困难。

这一切正在悄然改变,Reward 数据正在越变越多,作为 Verifier 的 Reward Model(RM)也在变得越来越强。我们看到了越来越多的证据,新的的 scaling 趋势呈现在了生成式 RM 上2。这种 Reward Model 相比于传统的方法来说,对于大语言模型的判别已经不是一锤子买卖了。它更像是人类标注员的思路,对问题和答案会和传统生成式模型一样也能够进行 CoT。他会对于一个问题和答案,首先按照生成式模型的方法给出自然语言的判断,然后再给出 RL 所需要的标量数值,彻底摆脱了判别式 RM 中 BT 假设的枷锁。所以随着 Reward Model 思考的深入,其准确度也会不断上涨。同时更重要的是,verifer 和 generator 之间也可以通过信息密度更高的自然语言的方式进行互动。相当于 RM 监督 policy 的时候,不仅告诉了每条答案的评分还详细给出了错误的原因。这种以自然语言作为交互模式的对抗 + 合作的模式可以随着计算资源的增长获得明显的增长(推演的更多,反思的更细)。其中的对抗是,大语言模型要经历生成更好的回答让 RM 无法挑出问题,而 RM 也要自己增长能力以发现大语言模型的更多漏洞。合作则在于,最终两者的博弈并不是零和的,两者的同步增长会使得我们的大语言模型拥有真正的长思考能力,并有机会往全领域泛化。

那么第二个问题是:Verifier 判别出来的正例和负例是不是同时能够利用起来,答案是比较正面的。而且强化学习中,引入负例可以更有效地提升大语言模型的推理强度。数据利用效率更是达到了仅使用正例的八倍,这个结论是非常好理解的,对于推理来说一个巨大的采用空间内,做错的可能性在起初要大大高于能够做对的概率。如果无法充分利用负例的数据价值,学习效率就会大打折扣。

从推理时的较为确定的 Self-Play 方式出发,我们可以反向推演一下 o1 的可能技术路线(声明一下这些都是推演)。假设 Generator 和 Verifier 是两个相互配合的模型,部署的时候使用两个模型组成的系统,那么就可以使用 actor-critic 的方式加 TD-error 来更新 generator model 和 verifier model。PS: 细节可以看原文,有点get 到 self-play 啥意思了。

LLM scaling up 的边际收益开始递减,用 RL self-play + MCTS 提升 LLM 推理能力成为下一个技术范式。在新范式下,LLM 领域的 scaling law 会发生变化:计算量变大仍会带来模型智能的提升,但会从模型参数量变大,转移到 inference-time compute 增加,也就是模型进行更多 RL 探索。要让 RL 算法能够在连续推理任务上做到最好,理解 self-play + MCTS 的思路是最重要的。放到 LLM 语境下,self-play 是让 LLM 同时扮演一个或多个 agent model 去做推理任务,并由另一个 LLM 作为 reward model 来给出打分评价,一定次数后更新 LLM 权重让其多记住做得好的推理方式。Self-play RL 是要在好的策略上持续探索,怎么定义“好”就尤其重要。因此, Reward model(奖励模型) 是 RL 中最关键的模块之一,有两个关键的卡点是需要解决的,那就是 reward model 的泛化性和连续性。Self-play RL 在棋牌、电子游戏、数学竞赛上之所以有效,是因为这些领域都有明确的胜负标准,可以作为 reward model 的基础。有了 LLM 的 in-context learning,我们相信代码、数学是可以通过 LLM + self-play RL 来持续进步的。根据 The information 报道,strawberry 目前能力最强的领域就在 math 和 code 上,Sonnet 3.5 在代码的提升也是很好的佐证。这两个领域具有准确、快迭代的评判标准,使得模型能够获得明确的反馈:我们可以把 code script 放进 Python Interpreter/ compiler(如果不成功,报错信息也能帮助 AI 自己去发现和理解错误在哪里),把 math proof 放进 Lean(Lean 是一种编程语言,通过计算机验证数据定理,广泛用在 AI 形式化数学证明中帮助 AI 理解数学题),就能自动验证其准确性。

reward model 对其他领域的泛化性并不明确。物理、医药有明确的标准答案,但需要很长的实验验证周期。法律、金融的问题往往没有通用解法,很难用通用的 reward model 实现。文字创意领域的 reward 很多时候不符合马尔可夫模型,也就是其 reward 常常会有跳变。一本好的小说、剧本,会讲究反转,试想 LLM next-token prediction 到一个反转之前其 reward 函数还很低,一个精彩的反转让 reward 函数突然大幅提升,self-play RL 很难捕捉这个突然的变化。因此这里孕育着新范式下的第二个创业机会:垂直领域的 reward model。而要让 reward function 能捕捉到更多的信号,在垂直领域之外泛化,最重要的方向就是怎么用好 LLM 作为 reward model,并同时输出数字和文字评估。

LLM as a PRM (process reward model):通往泛化的重要路线。在传统 RL 中,我们按照最终结果评分,其评分模型称为 ORM(outcome reward model);而通过专门训练 LLM 成为 process verifier ,新的评分模型叫做 PRM,往往是使用娇小 LLM fine-tune 得到。PRM (Process reward model) 是奖励好的推理步骤,而不仅仅是正确的结果。这更接近人类的学习和推理方式。而且在 process supervision 过程中,reward 的形式也不止限于数值,文字评价也可以作为指导模型继续行动的 reward。

左脚踩右脚真能上天?谷歌提出自我纠正RL提升LLM光靠模型自己给自己打分,较难获得新的信息增量提升效果,要么需要多个模型,要么依赖于更高级的模型或其他形式的监督(如RAG提供外部输入)。但最强的那个模型要怎么继续进步呢?光靠模型自己反思真的不行吗?谷歌DeepMind团队提出多轮在线强化学习方法 SCoRe,完全使用自生成的数据进行训练,不需要任何外部反馈模型/信号,就能实现内在自我修正策略以“即时”修正自己的错误,提升了模型的推理能力。我们理性的看,这种“自我反思”要有效果,有一个重要前提,是当前LLMs已经压缩了和问题答案相关的信息/知识,但还无法很灵活的使用,需要更高效的策略帮它提取&运用起来。

未定

Reverse-o1:OpenAI o1原理逆向工程图解本文以相对容易理解的方式来对o1做些技术原理分析,试图回答下列问题:

  1. 除了复杂逻辑推理能力获得极大增强,o1还有其它什么重要意义?
  2. o1的完整训练过程大致会是怎样的?
  3. o1是单个模型,还是多个模型?
  4. O1中的RL状态空间如何定义?行为空间如何定义?会用何种Reward Model?可能用何种训练数据?LLM和RM融合后的模型结构可能会是怎样的?

训练过程

  1. “预训练”阶段应该是重新训练的,不太可能是在GPT 4o上通过继续预训练得到。 证据很好找,OpenAI官方一再宣称o1 mini逻辑推理能力极强,但在世界知识方面很弱。如果是在其它模型上魔改的,世界知识不会比GPT 4o mini更弱,所以侧面说明了是重新训练的;另外,这也说明了o1这类侧重逻辑推理的模型,在预训练阶段的数据配比方面,应该极大增加了逻辑类训练数据比如STEM数据、代码、论文等的比例,甚至我都怀疑o1 mini是否引入了通用数据都不好说,否则不需要老强调知识方面能力弱。
  2. 在“后训练”阶段,应该有一个环节是用来增强LLM模型的指令遵循能力的,也就是说RLHF阶段应该是有的。因为o1在遵循指令方面能力并不弱,而且生成的Hidden COT片段里明显也包含很多指令性的内容,如果遵循指令能力比较弱,估计对于生成Hidden COT也有负面影响。所以,推断起来这个环节大概在“思考”阶段之前。(但是RLHF阶段未必有RM和PPO)。大概率也会极大增强逻辑推理类的指令遵循数据比例,以此进一步加强基座模型的逻辑推理能力,原因我们等会专门说明。接下来的阶段,就是o1最大的特点,所谓引入了“系统2”的慢思考能力。ClosedAI只说用了RL强化学习,其它任何都没提,技术保密工作一流。由此,我们只能推断出o1融合了LLM和RL来实现模型“先想后说”的Think能力。
  3. 在模型推理(Inference)阶段,o1体现出了“先思考再发言”的特点,分为三个阶段:首先通过思考,根据用户Prompt的问题生成能体现思考过程的Hidden COT数据,因为很多Hidden COT很长,于是引入了“COT摘要”阶段,从很长的Hidden COT里提取一些关键思考环节展示给用户看看,最后根据COT输出答案。

从上面内容可看出,o1无论在训练还是模型inference阶段,和传统的LLM应该还是有很大区别的。此外,我在这里再展开讲讲两个事情。

  1. 想要仿造模型来达到类似o1的效果,一个很容易想到的取巧的方式是:既不去专门增强基座模型的逻辑推理能力(比如大幅增加预训练中逻辑类数据占比),也不做“慢思考”阶段的RL训练(因为不知道怎么做的),只是侧重在模型inference阶段加入“Think”的过程,比如想办法引入最简单的Best-of-N Sampling这种树拓展策略,再写写Prompt提醒让LLM自己要自我思考、自我反思,两者相结合,也可以让模型自己写Hidden COT。这样做,也能一定程度上提升模型的推理效果。但是,这种做法效果提升的天花板比较低,就是说你模型逻辑推理能力看着提高了一些,然后就会被卡住,即使再增加inference阶段的算力(就是把采样数量N比如从10个拓展到50个,类似这种。Inference-time Scaling law大概其实很可能就是这个意思,您觉得这做法是law还是不law呢?)其实也没用。这是因为对于简单或中等难度的问题,模型在inference的时候很可能给出答案中的大部分步骤都是对的(或者多次采样中多数是对的),只有个别步骤错误,导致最终回答错误。通过比如Best-of-N Sampling这种简单树搜索方法来增加输出的多样性,再加上靠谱的Verifier筛一筛,是比较容易把这个小错误修正过来的。但对于高难度的逻辑问题,因为模型输出内容中大部分步骤可能都是错的(或者多次采样中大多数都是错的,这种情况你投个票采取多数人意见看看,结果估计很悲催),你想靠inference-time增加算力无力回天。我自己也是根据上述思考,才进一步反推出上面讲的o1可能的训练过程的:OpenAI o1的基座模型,不论是Pre-training还是Post-training阶段,大概率极大增强了基座模型的复杂逻辑推理能力,这是它能在后续inference-time增加算力解决复杂问题的根基。所以关于这个点的结论应该是这样的:只靠inference-time增加算力,仅对容易和中等难度的逻辑问题有用,想要不断提升模型的复杂推理能力,还需要继续在Pre-Train和Post-Training阶段下功夫
  2. o1应由多个模型构成。从o1的System Card可以明确看出,o1除了一个主模型外,至少还有一个相对独立的“Hidden COT摘要模型”(参考上图),它的作用是根据用户输入问题及生成的Hidden COT,提供一份简洁且内容安全的COT摘要。所以,o1至少由两个模型构成。那么,问题是:除了主模型和摘要模型,还有其它模型存在吗?我觉得大概率是有的。(推理过程忽略)o1模型大概由三部分构成(参考上图):一个主模型,一个摘要模型,还有一类可灵活配置个数的跟树搜索相关的模型池子。

OpenAI O1可能采用的训练数据

  1. 人工标注数据。训练o1肯定会人工标注一批COT思考过程,就是说拿到一批<问题,答案>数据,通过人工把解决问题的思考过程和步骤写下来,形成<问题,思考过程(包括思考过程中出现的错误及错误修正过程),答案>。如果没有人工标注过程,那么COT里出现的:Hmm,wait,…这种,如果是纯靠LLM自己产生的,那估计LLM已经有意识了,这个概率很小,这些大概率最初来自于人工标注数据。可以用这些数据SFT一下o1初始的模型,启动模型的输出模式,让它熟悉这种表达方式,但是仅靠SFT肯定是不够的。
  2. 合成数据。人工标注难度大、成本高,所以人工标注的COT数据数量不会太多,人工标注的问题是可扩展性太差,优点是质量比较高;之后可以采用合成数据的模式,一种最直观的合成数据的方式就类似上面提到制作PRM标注数据的模式:从人工标注的COT里面截取一段人工标注片段,然后使用MCTS树搜索方式去补齐后续推理过程,每个片段跑多次,有的最后答案正确有的错误,无论是正确还是错误,都可以作为合成数据来训练o1模型。有一种极大拓展代码COT数据的办法:我们有大量现成的各种代码,可以教会大模型试着从代码反向生成Hidden COT的推理步骤,这个应该是可行的,并能极大拓展Coding类型的COT数据。

RL的关键要素及如何将RL与LLM融合:在Hidden COT场景下RL的关键要素:状态空间(State Space)、行为空间(Action Space)、奖励模型(Reward Model)。

  1. 关于o1的RL状态空间,首先的问题是:这个状态空间是离散的还是连续的?大概率是连续状态空间,或者说最好把它看成是连续状态空间。O1由LLM和RL组合而来,当用户输入问题时,很自然的,这些组成问题的Token序列作为一个整体可以看成第一个状态(State1),State1的Token序列作为o1模型的输入,o1在行为空间里选择某个行为(至于行为空间如何定义后面再谈),先不管这个行为是什么,反正选择这个行为后,o1会输出一个Token序列片段(不会是完整的Hidden COT,应该是其中的某个片段)。之后,o1把新生成的Hidden COT片段内容追加到State1之后,形成State2,再次作为o1的新输入,o1根据新输入选择新的行为,输出新的Token序列片段…..如此往复,直到Hidden COT输出结束。基本是这么个过程。
  2. O1中RL的可能行为空间:“思考因子(Thought-Factor)”离散行为空间。O1的RL技术方案,其中最关键的环节很有可能是如何定义行为(Action)空间。OpenAI 01的Hidden COT产生过程,本质上是在让机器模仿人在解决复杂问题产生的思考过程,而人在思考复杂问题时,有比较固定且数量并不太多的“思考模式”或者可以叫“思考因子”。比如拿到一个复杂问题,我们一般会首先明确这个问题的目标是什么,然后把复杂问题拆解成几个环节或者步骤,为了得到某一个具体步骤的解法,可能会提出一个假设,然后验证这个假设是否成立,如果不成立,那么继续提出新的假设,直到解决这个子问题…..我们也可能在过程中会进行验算并发现某些中间环节出现错误,并把错误修正过来。在我的设想中,一个合理的方法是归纳出人类思考复杂问题的隐含的“思考因子”,以此作为候选的行为集合,比如:“拆解问题”、“复述目标”、“检查结果”、“修正错误”、“提出假设”等等,总体数量应该不会太多,即使划分得细致一些的话,估计也就几十到上百种。而针对每个具体的“思考因子”,可以产生符合对应分布概率的Token片段,比如行为若是“提出假设”因子,则生成“Alternatively”这个Token的概率就比较大(通过PPO从训练数据里学到的)。也就是说,OpenAI的Hidden COT的原始内容或者训练数据,在形式上有可能是这样的二级结构:
     <ACT_Proposer-Start> Alternatively, perhaps combine the numbers in some way. <ACT_Proposer-End> (提出假设)
     <ACT_RephraseTarget-Start> Overall Task: Write a bash script that takes one argument (the string representing the matrix) and outputs its transpose in the same format.<ACT_RephraseTarget-End> (复述目标)
     <Think_Start> (Hidden COT起始标记)
     ……
     <ACT-1_Start>token token token…..<ACT-1_End> (思考因子1)
     <ACT-2_Start>token token token…..<ACT-2_End> (思考因子2)
     <ACT-3_Start>token token token…..<ACT-3_End> (思考因子3)
     ……
     <ACT-n_Start>token token token…..<ACT-n_End> (思考因子n)
     <Think_End> (Hidden COT结束标记)
    

    这种层级的hidden COT结构,能体现出RL和LLM的优势结合,离散行为空间比如估算给定状态S采取何种行为,即函数Q(S,A)的估算,这是RL擅长做的事情,而思考因子标签中的Token生成则是LLM擅长的事情,LLM可以根据对应“思考因子”的类型,学习调整因子标签内部Token的生成概率。在生成Hidden COT的过程中,输入和输出都带有ACT行为Token的起始和结束符号,首先,O1根据当前的问题和已经生成的Hidden COT片段,预测下一个最可能采取的“思考因子”,以决定后面要采取怎样的具体思考模式,然后在这个“思考因子”指导下,LLM生成具体的Token序列,以“思考因子”的结束Token作为这种思维模式的结束标记。并将本步输出的Token序列并入输入,来循环往复地生成下一步思考的对应行为及Token序列。PS:训练时,吐出xxtoken ==> 归属于哪个”思考因子“ ==> rl 对“思考因子”给出奖励。推理时,当确定某一步的“思考因子”后,token的生成概率受本步所属“思考因子”的影响

  3. 目前常用的Reward模型有两种(参考上图):结果奖励模型(ORM,Output Reward Model)和过程奖励模型(PRM,Process Reward Model )。ORM的意思是训练一个模型,不管推导过程有多少步,只对最后结果打分。如果对照Hidden COT看的话,意思是只有o1把Hidden COT完整地写完了,ORM才给出一个奖励信号,模型结果若和标准答案对上了,给奖励1,如果答案错误,给奖励-1,类似这种。很明显,ORM的优点是反馈信号准确,比如对于数学题,模型要么做对了,要么做错了,很明确,所以反馈信号就精准;但ORM的缺点是反馈稀疏,意思就是反馈信号少,这个很直观,哪怕你推导过程写10页纸,反正最后只有一个反馈信号(OpenAI 训练大模型时RLHF阶段的RM模型,就属于ORM)。PRM的含义是训练一个模型,能对中间每个过程都给予反馈信号,这样在推导过程中错在哪个步骤就很清楚,不用等到最后,所以它的特点是反馈信号丰富不稀疏。但问题来了,要训练PRM就需要有每一步有标注的数据,这么多标注信号怎么来?常规做法是靠人工标注,比如去年很火的OpenAI的PRM工作“Let’s Verify Step by Step”,就是靠人工标注了80万中间步骤反馈信号的数学题推导过程,而且证明了PRM效果要比ORM好。所以,PRM的优点是反馈多效果好,但是训练数据制作成本太高,一般人做不了。那么OpenAI o1在训练过程会采用ORM还是PRM呢?我估计两者都会用。ORM精准,PRM反馈丰富,两者各有优点,结合起来效果应会更好。

对于AlphaZero来说,其本质其实还是MCST蒙特卡洛树搜索。围棋之所以看着难度大难以克服,主要是搜索空间实在太大,单纯靠暴力搜索完全不可行。如果我们假设现在有个机器无限强大,能够快速遍历所有搜索空间,那么其实单纯使用MCST树搜索,不依靠RL,机器也能达到完美的博弈状态。AlphaGo Zero通过自我对弈以及深度增强学习主要达到了能够更好地评估棋盘状态(V)和落子质量(P),优先选择走那些赢面大的博弈路径,这样能够舍弃大量的劣质路径,从而极大减少了需要搜索的空间,自我进化主要体现在评估棋面状态(P和V)越来越准,所以能越来越快地找到赢面最大的落子位置。而之所以能够通过自我对弈产生大量训练数据,是因为下棋是个规则定义很清晰的任务,到了一定状态就能够赢或者输,无非这种最终的赢或者输来得晚一些,不是每一步落子就能看到的。PS:MCST是主体,RL起到了加速搜索速度的作用。

如何融合LLM和RL两个模型,来获得一个同时混合LLM和RL两者功能的完整网络结构。

上图给出了一个我设想中的结构:主体仍然是基于Transformer的LLM模型,,当输入“问题+已经生成的部分Hidden COT”(也就是由连续Token序列组成的当前状态S)之后,经GPT网络对当前状态进行编码。在LLM 输出Head之上,可分化出两个子结构:一个用于常规的LLM 预测Next Token,这与通常的LLM一致;在Head之上,可以搭建RL模型结构,这里参考了AlphaZero的思路,一个网络两个输出。比如可以用FFN网络结构,一方面输出策略网络P结果(P(S,a)),代表在当前状态S下,下一步Action“思考因子”的分布概率pai,某个“思考因子”概率越大,则下一步这个Action被选中执行可能性越大;另外一方面会输出价值网络V结果(V(S)),代表当前状态S通向最终正确答案的概率大小,概率越大说明当前状态S质量越高,意味着目前已输出的这部分Hidden COT整体质量较高。到了这一步,当Hidden COT处于某个状态S的时候,经过网络可知下一步应该采取什么动作,也获得了当前状态S通向成功答案的概率。但目前仍缺少一部分内容,即在已知下一步“思考因子”行为后,对应的Hidden COT 一系列输出的Tokens。

一种简单的方法是用LLM head之上的LLM部分持续输出后续Tokens(有人工数据训练的时候,可以用PPO来增加对应Token的输出概率),在输出后续Token的时候并不考虑RL的输出,直到LLM输出到<ACT_i-End>之后,再去判断RL的输出选择动作…..持续此过程,结合LLM和RL输出Hidden COT的模型就能运转起来。在已知下一步“思考因子”后,不由主模型来生成后续Tokens,为了增加后续生成COT的质量,可采用Best-of-N Sampling的思路,由多个复制的Reverse-o1模型(不同副本可以设置不同的温度参数,增加输出的多样性)各自给出一个Token序列,然后由离线训练好的PRM作为评委打分,选择得分最高的Token序列,作为本次“思考因子”后续的输出Tokens。选出最佳内容后,可同步给主模型,主模型执行一次类似Prefill的操作,即可同步输出最佳内容,然后开始下一轮的输出……可如此办理,这么做明显生成的Token序列质量会更高。

PS:比较受教的是提出“思考因子”这个概念,这样搜索空间是一系列“思考因子”(比如人类总结的几百种思考因子),下一步action 先确定到“思考因子”粒度,然后再llm + “思考因子” 生成next token 到token粒度。具体的说,假设思考因子一共有100种,可以根据当前input + hiddencot,得到了下一步采信每个思考因子的概率,选取概率最高的那个“思考因子”(比如A),然后用比如10个模型,input + hiddencot <ACT-A_Start> 每个模型输出token 直到<ACT-A_End>,这10个候选token序列传入主模型,判断得到正确答案的概率更高,就选哪个token序列。训练数据是 <问题,思考过程(思考因子列表),答案>o1创新的使用了强化学习,让大模型自己生成CoT,从而让大模型在很多领域具备了推理能力,实现了质的飞跃。

重要意义

o1这条技术方向不仅增强了模型的复杂逻辑能力,由此可能引发大模型研发很多重要方向的革新。

  1. o1给大模型带来了自我反思与错误修正能力,我觉得这点价值特别大。 GPT 4这类模型,因为在输出答案的时候是逐个Token输出,当输出长度较长的时候,中间某些Token出错是一定会发生的,但即使LLM后来知道前面输出的Token错了,它也得将错就错往下继续编(这也是大模型幻觉的来源之一,为了看上去逻辑合理,LLM得用100个错误来掩盖前面的第一个错误),因为落Token无悔,没有机制让它去修正前面的错误。而o1在“思考”也就是生成Hidden COT的过程中,如果你分析过OpenAI官网给出的Hidden COT例子的话,会发现它确实能意识到之前犯错了,并能自动进行修正。这种自我错误识别与修正对于LLM能做长链条思考及解决复杂任务非常重要,相当于越过了一个锁住LLM能力的很高的门槛。
  2. 所谓新型的RL的Scaling law。o1的RL大概率要么用了相对复杂的、类似AlphaGo的MCTS树搜索,要么用了简单树结构拓展,比如生成多个候选,从中选择最好的(Best-of-N Sampling),这种策略如果连续用,其实也是一种简单的树搜索结构。也有可能两者一起用。不论怎样,树搜索结构大概率是用了,COT是线性的不假,但这是产出结果,不代表内部思考过程就一定是线性的,我觉得靠线性思维推导过程很难解决复杂问题,树形结构几乎是不可避免的(我没有证据,但是可以推断)。无法忽视的是这种方法的可扩展性极好,无论是在RL训练阶段,还是LLM的Inference阶段,只要改下参数配置来增加树搜索的宽度和深度,就能通过增加算力提升效果,可扩展性好且方式灵活。。从这点讲,o1确实具有重要意义,因为这证明了它把怎么融合LLM和树搜索这条路走通了,LLM模型能够达到AGI的上限就被提高了一大截。
  3. 在o1之后,小模型大行其道真正成为可能。小模型最近大半年也比较火,但从能力获取角度看,其实还是有上限锁定的,这个锁定小模型上限的就是逻辑推理能力。小模型的能力特点是:语言能力很强不比大模型弱、世界知识不如大模型但是可以通过给更多数据持续提升、受限于模型规模,逻辑推理能力能提升但比较困难。
  4. o1可能会引发“安全对齐”新的范式。 O1在做安全对齐方面,大概采用了类似Anthropic的“AI宪法”的思路,就是说给定一些安全守则,指明哪些行为能做,哪些不能做,在o1逻辑推理能力提高之后,它遵循这些法则的能力也获得了极大增强,安全能力比GPT 4o强很多。这可能引发安全对齐新的模式:大家可以先把模型的逻辑推理能力加强,然后在此之上采取类似“AI宪法”的思路,因为OpenAI o1证明这种模式可极大增强大模型的安全能力。
  5. “强化学习+LLM”的领域泛化能力,可能不局限于理科领域。 强化学习适合解决Reward比较明确的复杂问题,典型的是数理化、Coding等有标准答案的学科,所以很多人会质疑o1是否能泛化到更宽的领域。确实,o1的思考能力能否泛化到没有明确标准答案、Reward不好量化的领域是它发展的关键,泛化得好,则打开阳光大道,泛化得不好,领域局限性就会比较强。我推测OpenAI可能已经找到了一些非数理学科的Reward定义方法,并将这个方法通过RL拓展到更多领域。既然o1可以读懂并遵循安全规则,以 “AI宪法”的思路解决安全问题,我觉得由此可以推导出一种针对模糊标准的Reward赋予方法:就是说针对不好量化的领域,通过写一些文字类的判断标准或规则,让大模型读懂并遵循它,以此来作为是否给予Reward的标准,符合标准则Reward高,否则Reward低。例如,针对写作文,就可以列出好文章的标准(结构清晰、文笔优美等规则),让大模型据此来给Reward。如此就能拓展到很多领域。当然,想要这么做可能要分步骤,先用好给Reward的数理问题增强模型的复杂推理能力到一定层级,这样它就能看懂规则了,然后再做那些不好量化Reward的领域。(这都是我的猜测,没有依据)

另一份材料

当大家在网上探索o1是如何训练时,肯定会看到以下几个热点词:

  1. Test/Inference-Time scaling law,通过增加推理阶段的算力提升模型的推理能力
  2. Post Training,通过后训练提升模型的推理能力
  3. PRM/ORM:基于过程/结果的奖励模型
  4. CoT:思维链
  5. 强化学习、self-play(自我博弈)与MCTS(使用蒙特卡洛搜索树寻找最佳答案)

什么是Test/Inference-time Scaling Law

OpenAI o1模型的本质优势是什么? - 猛猿的回答 - 知乎设想一下,当我们手里有一个基础模型(我们称其为generator),但是这个模型的逻辑推理能力(比如解数学题的能力)较差时,我们该怎么改进它?再说的具体点,不考虑数据集相关的成本,假设我手头的gpu算力(FLOPs)是有限的,我该怎么利用它,能让我的模型最终能推理出更好的结果?一个比较直接的想法是:把算力花在它的pretain阶段,给模型注入更多数理逻辑的预训练知识。例如用更好、更多的代码数学等数据,或者扩展模型的参数规模。这个做法启发自大家都很熟悉的scaling law(更具体地说是pretrain-time scaling law)。但是,当我们研读openai o1的技术报告时,我们会发现,它把这个算力更多地用在了2个地方:

  1. 用在了rlhf的训练上(post training)
  2. 用在了模型的推理阶段上(Test/Inferece) 正如pretrain scaling law受到模型参数和训练数据的影响一样,Test/Inferece scaling law也必然受某些因素影响,而这些因素是什么,又是怎么影响的?不过等等,此时你肯定想问:
  3. 一般来说,一个模型的效果是由它的训练阶段决定的,所以如果这里说通过pretrain或者post training来提升模型的推理能力,我都能理解。但是inference阶段是怎么提升模型的推理能力的?你说的把算力用在inference阶段到底是什么意思?
  4. post training和inferece是两种独立的提升模型推理能力的方法吗?它们可以结合在一起使用吗?

把算力用在inference阶段,也就是说,在不变动pretrain阶段的情况下,只通过推理等层面的优化,来提升模型最后的生成效果。这里又分成两种情况。

  1. 优化推理输入:prompt。这个方法大家应该非常熟悉了。例如,原来你的模型吃一个问题,直接吐给你回答。但是现在为了让模型能更好模拟人类的思考方式,你希望【模型在步步思考后再给出回答,也就是模型的生成结果里包含思考步骤+答案】,那么你可以选择在prompt中给模型相应的例子,或者在多轮对话中引导模型think step by step,来实现这个目标。你的prompt给的越细节,你的多轮引导给的越多,模型或许就能产出更好的结果。
  2. 优化推理输出:revise output distribution。可是,优化推理输入的方法还是不够直接。难道对于每一个问题,我需要精心设计prompt,或者手动诱导模型think step by step才行。所以能不能让模型吃下一个问题后,自动化地去做CoT的过程呢?也就是说,现在我们希望模型在吃下一个问题后,能自主产生以下输出: attempt1 -> attempt2 -> attempt3 -> ...-> attempti -> answer,其中,每个attempt包含“多个中间步骤steps + 最终结果”,也就是它在模拟人类的思考过程:先做一次attempt,然后发现问题,在此基础上在做别的attempt,直到找到最终答案。那么我要怎么让模型做到这点呢,一个直观的方法就是,如果我有: problem -> attempt1 -> ... -> attempti -> answer 这种带标签的数据,那我不就能直接训练了?训练的方法也有很多,例如:
  3. 我直接做sft,把最正确的attempt放在输入序列最后,当作label进行训练即可
  4. 我用类似rlhf的方法,先有一个奖励模型,它能对每一个思考步骤做评估,然后利用这个评估结果,指引模型步步搜索,每一步都找到最佳的思考步骤,最后不就能找到答案了?

这两种解法,仅从训练方法上来说,都可以算成是post-training,也就是我们通过把算力花在post-training上来提升模型的逻辑推理能力。可是,本文的标题不是【把算力花在inference上】吗?inference在哪里呢?我们再重新端详这2种解法:

  1. 假设我们使用解法1或者解法2 post training好了模型,现在我们拿它做推理。模型吃一个问题,产出一系列中间结果和答案,但是你能保证,这些中间结果和答案一定是最好的吗?
  2. 所以此时,一方面,我们可以考虑优化推理阶段,即使用一个能够评估中间步骤的verifier,在推理时指引模型搜索出最佳答案。例如,我们对一个问题采样多个attempts链,从中找最好的。或者在单个attempts中找到最好的attempt,诸如此类。
  3. 而另一方面,我们可以考虑在post-training阶段,使用这个verifier来指导模型自动化生产高质量的数据(这是个inference步骤),基于这些数据我们再做对齐。如果这个流程做得好,我们甚至可以直接信任post-training后模型的结果 所以,【优化推理输出】这一部分,你可以把算力全部花在post-training上,也可以花在post-training+inference上,从o1的技术报告上看,它应该选择了后者,同时post-training选择了某种基于强化学习的方法(其实o1在pretrain阶段应该也有变动,具体的分析我们在后文中会通过实验数据给出猜想)。至此,我们就把问题1和问题2都回答清楚了。

一个能按照格式,产出中间思考步骤的模型(generator),但中间思考步骤质量得不到保证。一个能对中间思考步骤进行评估的奖励模型PRM(verifier)。而现在我们想做的事情是:如何在不对generator继续做任何训练的情况下,使用verfier,来引导generator搜索出最佳的“steps + answer”?

  1. 使用PRM指导搜索过程。
  2. 直接改变模型的输出分布