技术

agentic chat 图数据库的一些考量 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 组件
agentic chat 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

当LangGraph遇上Mem0:如何让你的AI Agent具有更智能的记忆与个性化的体验?

融合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

思维链让LLM初步学会了像人类System 2一样的思考复杂问题的模式,但这还远远不够。一个明显的gap是:LLM在训练过程中并没有足够多的包含思维链的训练数据,但却在推理阶段被要求以思维链的方式思考问题。如果在训练阶段使用包含更多含思维链的数据,那么模型在需要推理的任务上的表现会更好。由此,一条提升LLM性能的道路清晰可见:构造包含思维链的数据,将其用于LLM的训练阶段以提升LLM的推理能力,使其降低幻觉。

万字长文解析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的领域。(这都是我的猜测,没有依据)

OpenAI o1能否支撑AGI的新Scaling?

  1. 无论如何,给LLM纠错的机会,对于效果的提升都是可以预期的。LLM生成token的过程中,生成的序列越长,产生错误token的概率自然也会越高,后面模型为了自洽往往会用一百个谎言来掩盖第一个谎言,最后就彻底逻辑失控了。那么给LLM更多隐式COT和修正错误token的机会,总归可以一定程度提高质量。无论是在训练时候利用修正的结果去调整模型,还是在推理阶段把错误结果消除掉。
  2. 但要做到Scaling,这是一个需要深入思考的问题:大模型Self-play能否通过自我博弈持续提升?“持续”是非常重要的,本质问题是这样的提升是不是会快速收敛?这里不仅仅要考虑算法本身的持续可扩展性,也包括算法所需要的各个环节的输入的可扩展性。持续提升代表的是一个非常具有诱惑力的未来,也就是可以很快在深度思考和逻辑上不收敛地提升,快速超越人类。但如果存在不可扩展的地方,那会很快停在一个大概率上限也就是接近全人类平均水平的位置。强化学习本身的可扩展性是比较好的。强化学习第一性的核心就是policy和reward,policy负责输出具体行动,强化学习最终也是希望优化policy的行动策略来获得更多reward。各种强化学习算法虽然纷繁复杂,但本质上也是让policy随机尝试,如果尝试结果获得正向reward,那就调整参数让policy多往这个方向尝试,反之亦然。过去很多大多数强化学习任务都是建立在游戏类型的任务上,不过游戏有一个巨大的优势,就是reward获取极其容易,虽然相比监督学习而言,reward已经非常稀少了,毕竟一局游戏就能至少有一次输赢的reward。强化学习整体上发展到今天,整个工具箱已经挺完善了,基于这样密度的reward已经足够类似AlphaGo在16年就已经展现出惊人的可扩展性。
  3. 搜索的Scaling也不是问题。今天关于o1的大多数论文和分析解读都在深入研究各种搜索的花活。不管是简单粗暴的Best of N这种朴素的并行搜索,还是展开成树状用类似蒙特卡洛方法在思考深度上尝试用各种优先级多路径尝试,或者更花活一点做成一个图一样的结构进行更动态的搜索。其实这些方法没有非常本质的区别,Scaling都很容易,越简单粗暴的方式越有效,可以默念一遍The Bitter Lesson。很多人理解的Scaling就是在policy的搜索尝试上有巨大的空间,但reward的可扩展性才是最大的问题。无论哪种搜索方式,在每个搜索路径上给出reward反馈都是必不可少的。但reward的可扩展性就是语言最大的困境。语言和游戏不同,无论什么游戏,游戏本体都有输赢的reward,哪怕一局游戏给一个明确的输赢这种看起来非常稀疏的reward对语言而言都已经非常稠密了。试想一下,每次思考完一个问题都有对错的反馈实际上是非常奢侈的。语言实际上很多时候根本没有可扩展的reward方法,往往只有极少数domain才能有。采用人工标注的数据不仅仅是人力成本的可扩展性问题,更是上限也往往会封死在人类水平的reward上,无法做到不收敛地持续提升。合成数据同样如此,本质上也就是个离线的reward。一定程度上强化学习就是建立在高质量的reward基础上的,在游戏领域,精准的reward几乎是天然唾手可得的。LLM所面临的领域是完全开放的,通用可扩展的reward是比搜索方法本身更核心的问题。基础的RL概念体系一定是需要接近ground truth的reward的。
  4. Reward的可扩展性是不仅仅是数量上可扩展,也包括强度上可扩展。数量上可扩展很容易,我们可以用一些离线reward数据训练监督训练一个reward model来提供无穷无尽的reward,但这些reward的强度仍然是受限于有限的离线reward数据的。但如果policy的强度已经上来了,每次都是走的reward model评价最高的解,那么policy就没法继续提升了。游戏领域无论policy策略水平到达什么高度,游戏本体都可以精准地给出玩家最终的胜负或者得分,因此这样的reward是可以支撑policy持续提升的,因为这个reward本质上就是问题的ground truth。用LLM自己作为reward model是o1所代表的一类方式,但大多数情况下还是把LLM当作一个verifier,而不是真正推动整个系统不断调优的reward model。比如让policy LLM和verifier LLM相互对抗,看起来就像LLM自我对抗,self-play,产生大量的并行尝试,实际上目前已有的论文和分析基本最后还是需要一个额外的表示ground truth的真reward model来在这大量并行的尝试中给出偏好,从而校准无论是policy LLM还是verifier LLM。这里的verifier其实起到的作用感觉混杂了actor-critic框架下value model的作用,但也混杂了一部分reward model的作用。(强化学习概念就是多……)Value model本质上是QLearning体系下引入的对长期reward的一个短期近似。比如一局游戏最后有个输赢或者得分的reward,但是需要policy走非常多步才能得到,反馈给policy路径太长了,于是找一个中间的势能来描述每一步对最终长期reward的短期预估,从而更及时地给policy进行反馈,但同样的,value model也需要根据最终的reward不断调整这个短期近似的准确度,并不能真正意义上脱离最终的reward而直接把value model当作ground truth。
  5. 实际上我对新Scaling Law的存在并不悲观。但不是从RL视角,而是语言本身。语言所表征的概念空间是一个非常独特且迷人的代表思维的空间,我们不纠结语言是否等于思维还是语言只是思维空间的一种表征这种形而上的问题。但今天大模型所涌现出来的一切ICL能力、COT能力包括海量的常识、世界模型等等都是这个独特的概念空间所带来的。语言,或者说思维本身的特殊性可能反而可以带来持续增强,而不是RL。思维的对抗甚至不一定非要是LLM作为Policy和LLM作为Value/Reward之间的对抗,LLM作为生成式模型,本身可以作为任何一种角色进行相互对抗。只不过RL恰好提供了一套基础的Policy、Reward这样的概念可以将LLM套进去进行对抗。例如问黎曼猜想是对的还是错的,LLM中间强行推理一大堆,最后瞎蒙一个对的也能获得reward。而且即使我们获得黎曼猜想是对/错的ground truth,比如告诉大家这个猜想是对的,也很难激励大家找到证明他的方法。相反,即使最终没有获得答案,但证明过程产生大量推论,也是巨大的价值。光这两种情况的reward都是不一样的,我们其实也很难简单通过一些domain问题的ground truth来很好地奖励这两类不同的行为。reward cheating的空间太大了,不会就选C可能比学会做题更容易获得reward。靠RL支撑新的Scaling大概率会卡在reward的Scaling上,但语言不一样,语言本身具有自我增强的机会(这可能是个信念的问题了)。只是如何在语言中学到的这个思维空间如何探索,还需要很多研究来支撑,Scaling的关键更多是减少靠与人类对齐的方式,找到真正利用这个思维空间自举的潜力找到这个思维空间自由探索的能力。

另一份材料

当大家在网上探索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. 直接改变模型的输出分布

另一份材料

OpenAI o1模型的前世今生一种可能的技术路线推测

  1. 在Pre-Training阶段:o1重新训练了一版Base Model,使用了大量的代码、数学等STEM领域语料以及一些CoT语料,但是较少使用含有世界知识的语料,主要关注Base Model的推理、对话能力。
  2. 在Post-Training阶段:首先进行RLHF,提高模型的对话能力以及指令跟随能力;然后进行Self-Play的RL,通过自举的方式生成CoT,RM为一个LLM的PRM,RL过程中二者可以通过NL对话;最后进行Safety的相关训练。
  3. 在Inference阶段:o1直接生成CoT,然后再对CoT总结,将总结内容输出给用户。

Post-Training: SFT,获得的Base Model并不能直接用于强化学习,这是因为Base Model几乎没有在Zero-shot Prompt下生成CoT的能力,此时应该使用大量的带有CoT的数据进行SFT,使Base Model获得基本的CoT能力。什么样的CoT是一条好的CoT呢?o1的基础贡献者Hunter Lightman在其论文Let’s verify step by step中开源的PRM800K数据集有明显的独特风格,学术界普遍认为o1是该工作的继续。

  1. 风格一:表述口语化,更像是自我对话。
  2. 风格二:频繁使用换行。Let’s verify step by step中为了方便解析generator生产的推理过程,将其CoT设置成频繁换行的格式,这样一句话就是一个思维链的step或process,方便人工打标。
  3. 风格三:思考行为的关键词相似。强行将模型的思考行为定义在一个闭集里,找到对应的关键词,试图找出模型思考时的口头禅,思考行为可以用不同的关键词来显示明确。 |思考行为| 关键词| |—|—| |提出假说| Idea:| |否定假说| No.| |改换假说| Alternatively,| |强化问题| So the user is requesting …| |自我纠正| Wait, earlier I missed …| |拆解问题| Approach:|
  4. 风格四:过程进展缓慢,充满废话和冗余。其希望生成的CoT在不重复过去内容的情况下越长越好,这可能是因为CoT越长则每一步越具体,模型会做更多的思考,整套CoT的逻辑性越好。

明确了CoT的标准后,那么如何构造CoT数据呢?STaR核心思想是:利用LLM已有的推理能力,迭代式Bootstrap模型产生合理推理过程(Rationales)的能力,并将Rationales融入训练过程内,让模型学会推理,教会模型内部深入思考问题和答案的关联。其方法的步骤如下

  1. 推理:对于一个数据集中所有的问题和答案pair,形如<Question, Answer>,让模型M去根据问题生成中间推理过程和答案,得到<Question, Rationales, Answer>
  2. 过滤:如果生成的答案是正确的,则将推理过程加入到原有数据集中;如果生成的答案是错误的,则尝试在给出正确答案前提下再次生成推理过程,这时正确的答案作为Hint。用最终生成正确答案的推理构建一个微调数据集对模型M进行微调。
  3. 迭代:重复这个过程,每次获得一个新的数据集,都在原始的模型上进行微调,防止过拟合。

经过SFT之后的模型初步具备了推理能力,面对一个问题,模型可以通过成CoT来拆分、解决问题。这也是为什么OpenAI要求用户在使用o1时无需精心设计Prompt,更无需添加”Let’s think step by step”来显式调用CoT,只需描述清楚问题即可。但是此时模型的推理能力还不够强,需要通过强化学习进一步增强其推理能力。

在游戏领域进行Self-Play时,Verifier通常很强大,因为规则是清晰和固定的,而且有无限的奖励数据可以用来训练验证器,但Generator一般比较薄弱;相反的,在LLM领域,Generator的能力通常很强大,而Verifier通常比较薄弱,这是因为自然语言的复杂性和主观性导致的,此外奖励数据也很稀缺。但是现在时代变了,LLM领域的verifier也可以的很强,首先是奖励数据的增加,其次在特定领域其实是很好打分的,比如o1很擅长的STEM领域。Self-Play的可以看作是Generator和Verifier的对抗,有点类似GAN的思想。所以Verifier可以使用LLM-as-a-Judge模式,这样Verifier的就有了初步可以与Generator对抗的能力。此外,Verifier和Generator要同时更新,防止Reward Hacking。但是仅仅使用与Generator同参数级别的LLM作为Verifier还不够,传统的生成式Reward Model(GenRM)利用fine-tuned LLM的predict next token的能力通过预测下一个单词是”Yes”还是”No”来判断一个 <Problem, Solution> pair对是否正确。而GenRM-CoT在verify过程中加入了CoT的思想,不仅评估解决方案的正确性,还通过生成中间推理步骤来详细解释为什么一个解决方案是正确或错误的。这种链式推理过程除了提升了整体推理的准确性和可解释性,还可以与Generator进行自然语言形式的交互,这种交互类似外交官游戏,方法整体很像人类标注员的思路,摆脱了判别式RM中黑盒假设的枷锁。PS:如何训练一个牛逼的Verifier?

为什么要在Post-training阶段大做文章呢?有以下几个原因:

  1. LLM例如GPT-4都是自回归模型,都使用Predict Next Token的逻辑,所以会一直Look Ahead,无法学会自我纠正。例如在数理推断问题上即使增大模型参数也无明显效果提升,所以要在Post-trainig阶段引入强化学习;
  2. 根据Pre-training Scaling Law,目前提升预训练阶段的投入,模型性能的边际收益会递减;
  3. 根据Post-training Scaling Law,RL Training阶段的计算量和Test Time计算量的提升可以更有效率地带来模型性能的提升。
    1. Post-training阶段的Scaling Law:当不受其他因素制约时,模型的性能与强化学习(训练时计算量)、思考时间(测试时计算量)之间也呈现幂律关系。

MCTS

逻辑推理与决策规划:LLM+MCTS

  1. 为什么要将 LLM 与 MCTS 结合起来?
  2. 为什么 LLM 可以与 MCTS 结合起来?
  3. LLM 要如何与 MCTS 有效结合起来?
  4. LLM + MCTS 是终极方案么,有何局限性?

OpenAI明确表明 o1的训练借鉴了AlphaGo的强化学习思路,而AlphaGo主要使用了Self-Play和蒙特卡洛搜索(MCTS)。根据围棋的规则,棋子可以在19 X 19的棋盘上选择落点。如果使用暴搜法,那么将有 361!种可能,即使去除其中不合法的情况,可能性仍比宇宙中的原子个数$10^80$高出20个数量级。此时,可以使用MCTS来近似暴搜的结果,MCTS是一种用于决策过程的启发式搜索算法,它包含四个步骤:

  1. 选择(Selection): 从根节点开始,根据某种策略(通常是UCT,Upper Confidence Bound for Trees),选择一个最优的子节点,直到到达一个尚未完全展开或终止的节点。
  2. 扩展(Expansion): 如果所选节点不是终端节点,创建一个或多个子节点,表示可能的后续状态。
  3. 模拟(Simulation): 从新扩展的节点开始,进行随机模拟(通常使用随机策略),直到达到游戏的终局状态。根据终局状态的结果(如胜负或得分),评估该模拟。
  4. 反向传播(Backpropagation): 将模拟的结果反向传播到所有经过的节点,更新这些节点的值和访问次数,以便未来的决策可以基于更精确的估计。

简单通俗地讲,AlphaGo包括两部分:一个CNN卷积神经网络和MCTS算法,CNN相当于人类的”棋感“系统,它负责根据当前棋盘上的形式给出下一步可能的落点的集合;MCTS相当于理性思考,可以在CNN给出的候选落点集合里找到胜率最高的位置。提升的CNN可以找到更好的落点,MCTS的性能也会提升,MCTS性能的提升的结果反馈给CNN,则CNN的性能会再次提升,整个过程形成正反馈循环。AlphaGo首先在人类棋手的棋谱上进行监督学习,然后自我博弈(Self-Play),即在每一局自我对弈中,AlphaGo 的不同版本与自己对战,并根据对局结果更新模型的策略网络和价值网络,通过自我对弈,AlphaGo不再依赖人类棋谱,能够探索新的战术和策略,超越人类棋手的水平。

OpenAI o1模型的前世今生MCTS多在Action为闭集的场景下使用。笔者认为o1没有使用MCTS,甚至没有使用搜索算法,而是使用类似STaR方法中的。其实MCTS在除了下棋以外的场景上基本没有成功的案例,尤其是在自然语言组成的几乎无限空间的场景上。