技术

SSE 和 WebSocket 是什么? AutoGen学习 Python ioc 从0到1构建一个db 上下文记忆 agentic chat 图数据库的一些考量 推理LLM梳理 Agent实践 LLM预训练 向量数据库的一些考量 fastapi+sqlalchemy进行项目开发 LLM微调实践 Python协程实现 Agent Functon Calling LLamaIndex入门 Multi-Agent探索 Python虚拟机 LangGraph工作流编排 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快速入门

架构

GPU与CUDA RL与LLM MCTS与LLM 入门强化学习 从Transformer到DeepSeek 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 组件
GPU与CUDA RL与LLM MCTS与LLM 入门强化学习 AutoGen学习 从Transformer到DeepSeek 上下文记忆 agentic chat bert rerank微调 大模型推理tips 推理LLM梳理 Agent实践 LLM预训练 RAG向量检索与微调 LLM微调实践 RAG与知识图谱 大模型推理服务框架vLLM Agent Functon Calling LLamaIndex入门 Multi-Agent探索 LangGraph工作流编排 大模型推理服务框架 模型服务化(未完成) 大模型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泰坦尼克问题实践 神经网络模型优化 概率论 直觉上理解深度学习 如何学习机器学习 深度学习泛谈

RL与LLM

2025年03月16日

简介

先聊一个问题,在知识掌握层面上,sft 后的模型为什么不如 pretrain 模型效果好?或者说,为什么 sft 后的模型在知识掌握上会有幻觉?

  1. sft 在做什么?在找一条捷径,让 pretrain 模型可以直接说出答案,而不是续写一堆 token 后再总结出答案。
  2. 为什么走捷径会产生幻觉呢,我举个例子:中国的首都是哪里呢?
    1. pretrain 模型:这个问题问得好…… 中国最早的首都是…… 中国现在的首都是……
    2. sft 模型:北京。
  3. pretrain 模型有没有这个知识?一定有。pretrain 模型需要多少个 token 才能说出这个知识?不知道。运气好的时候续写一百个 token 就提到了北京,运气不好的时候续写一千个、一万个都有可能。那么问题来了,sft 模型走捷径而抛弃的这一千个 token,到底有没有信息量呢?到底是不是推导出中国的首都是北京的关键 cot 过程呢?大概率是有的,一旦学会了这种走捷径的方式,并且把这种捷径泛化到其他知识上,模型的幻觉也就产生了。这里,一定不能总是用人思考的方式来揣摩机器思考的方式,我们认为“中国的首都是北京”是天经地义的几个 token 就学会的知识,模型可能是从《北京的发展史》这一本几万 token 的书籍中才学到的这个知识。然后我就猜测:把 prompt 喂给 pretrain 模型,先续写 1W 个 token,再总结这 1W 个 token 得到 response,训练和推理的时候都不省略这 1W 个 token,这种方式估计大概率不会让模型产生幻觉,因为模型根本没学会走捷径。这就有点o1 的味道了。
  4. 所谓捷径就是极其稀少的语言或者文本相关性分布,和原有分布不一致。所以模型无所适从,就是幻觉。

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。PS:如何训练一个好的PRM 逻辑推理与决策规划(二):过程监督与结果监督

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

0123材料

谈谈对DeepSeek-R1的一些理解 在OpenAI o1刚放出来时,它有限的技术报告里,有2个内容格外抓人眼球:Inference/test-time scaling 和 RL

  1. Inference/test-time scaling:这一块的主要作用是为RL过程自动化地制造高质量数据集。包括用于format模型产生思考过程的long cot数据集,以及带preference labels的数据集。我把这一块的系统抽象为PRM + some search methods的形式。例如讨论度很高的MCTS,本质上也可理解为 fixed PRM + some search methods。PS:test-time就是Inference-time,只是历史的命名习惯问题。
  2. 这部分应该就是openAI自己惯有的一套RL流程。 在这样的训练框架下,最终推理时是否要再次引入inference-time scaling模块,就是一个可选项了。只要RL过程做得充分好,那么直接用训完的policy模型就可以,完全不需要再做优化。那么,我为什么当时会认为 inference-time scaling 和 RL 应该是2个独立的过程呢?因为在我的认知里,我认为如果没有显式的引导,模型是不具备产生long cot(乃至带反思的cot)的能力的(在模型训练初期,这个能力是指formatting模型,让它知道要产出这种格式的回答;在训练过程中再来慢慢提升这种回答的质量)这个显示引导就是指诸如sft这样的过程。PS:先引导思考,再评价思考对不对

而直到前几天,又是蹭着热点读到了dpsk-r1的这篇技术报告,我这下才发现:原来单纯的RL就可以激发模型产出带有long cot(甚至是反思)的回复的能力!这里单纯的RL是指:我并没有显式提供一些真正的long cot数据让模型去背去学,我只是在sys_msg里告诉模型先思考,再回答。接着通过RL一轮又一轮的训练,模型产出的responses越来越长,且在某个时刻出现了自我评估和反思的行为。这个实验探索就是dpsk-r1-zero在做的事情。如果RL有这种能力,那么inference time scaling 和 RL 就可以不是2个独立的过程,而是在RL的过程里自发出现了inference time scaling的现象,而如果它们不再独立,那么类o1的训练架构也许就比我们想得要简单很多。

低成本快速增强大模型逻辑推理能力的方法

  1. 首先,找到大量<问题,答案>数据,包括STEM、代码、数学、逻辑等方面题目集合;
  2. 第二,对问题进行改写,从问题侧来扩充<问题,答案>数据的数量;
  3. 第三,引入开源的类o1模型,比如Deepseek发布的各种R1开源模型,
  4. 第四,使用R1模型制作推理轨迹数据,并标注出问题的难易程度:可以通过对问题使用R1模型多次Rollout生成推理步骤轨迹,比如一个问题生成8个推理轨迹,根据最终正确答案是否正确进行过滤,过滤掉最终答案错误的例子;形成<问题,推理轨迹COT,答案>数据集合。
  5. 第五,(此步骤可选非必需,但可能比较重要)找到一个好的PRM模型,比如阿里开源的PRM模型,对某个推理轨迹COT整体质量进行评估,比如回答某个问题的推理轨迹由10个推理步骤构成,根据每个推理步骤PRM得分的平均分,得出整个推理轨迹的得分,得分低者意味着轨迹中包含错误推理步骤比较多,说明整体质量低,把整体质量低的<问题,推理轨迹COT,答案>数据过滤掉,只用剩下的高质量推理轨迹数据。这一步等于提升推理步骤整体正确率,等价于提升训练数据质量。
  6. 第六,使用剩下的高质量正例对基座模型进行SFT,数据使用顺序采取课程学习思路,由简单题目到难题,或者逐步增加难题比例,由此得到最强逻辑推理模型
  7. 第七,如果你想让自己的技术方案看着更有技术含量一些,可以引入部分负例(最终答案错误的推理轨迹COT数据),结合正例做个DPO,我感觉是这步骤可选非必需。

这本质上是种数据蒸馏方法,好处是成本极低、实现起来速度快,能很快制作当前最强逻辑推理模型,如果都这么做,那谁更强取决于三个因素:谁有更多的题目,尤其是难题;类o1模型给出的推理轨迹质量,质量高者胜出;PRM模型的准确性,更准确者胜。但是这个方法的缺点是缺乏自我进化机制,上面三个因素基本共同决定了能达到的效果天花板,缺乏通过模型不断迭代增强能力的机制。

对 deepseek R1 和 K1.5 技术报告的一些思考 都没有采取MCST+PRM的技术路线 deepseek 和 kimi 的核心思路是一样的:关注推理的中间过程是否正确无法实现,所以只能 rule-based reward,最起码 reward 一定是准的!deepseek 反驳 prm 路线的三个理由是:

  1. 定义一个 fine-grain step 很困难;
  2. 很难确定一个 step 是否正确,机器标不准,人标无法 scaling up;
    1. 这里,我最认同的是第二点:无法 scaling。假设我们能雇博士生标 10W 条 cot 高质量数据,但能标 100W 条吗?1000W 条呢?就像 scaling law 表达的一样,想让模达到新的效果,需要的数据量级往往是指数增长的。但保不齐以后真的有 scaling prm 数据的方案了,现在一杆子打死为时尚早,也许小模型,或者冷启动用它更好呢?
  3. 一旦 PRM 被引入,不可避免的 reward hacking,且训练资源耗费会更多。PS:而MCST方案的核心是提高PRM的准确性,阻碍MCST的主要是不准的PRM。Reward是指导MCST搜索方向的重要信号。

在dpsk r1的这篇报告里,提到了2个模型,分别是 DeepSeek-R1-Zero 和 DeepSeek-R1,deepseek R1的想法:把 o1 的训练分为两阶段:step1 学推理,step2 学说话

  1. 训 zero 的 step1:全程无标注数据的参与,就是认准了一个目标:让模型的 reward 变高。这个阶段别和我谈模型格式错误逻辑混乱这种细节,我不看模型表现,只看 reward。只不过 reward 变高的过程中,发现模型的输出越来越长了,反思能力也自己涌现出来了;PS:这个阶段主要目的是用来产生比第一次SFT阶段更高质量的推理轨迹COT数据,产生完新的数据zero模型就被抛弃了
  2. 基于 zero 训 R1 的 step2:就像是我们做普通的 post training 了,sft 没有被抛弃,除了rule-based reward,reward_model 也被请回来了,reject sampling 也出手了。PS:与step1 差别不是很大,只是sft 数据质量更高了。如此这般,就能形成更通用的多阶段做法。比如我们设计4个阶段,第一阶段类似R1的Phrase 1,得到Model RL-1,使用它产生更高质量的推理轨迹COT数据,然后用这些数据对干净的Base模型进行SFT,开启Phrase 2,得到Model RL-2,由Model RL-2产生质量更进一步的推理轨迹COT数据,如此重复几次,最后一个阶段采用R1的Phrase 2策略,补充标准Post-Training阶段训练数据,防止对通用能力的灾难遗忘问题。而且,在后续的阶段里,可以逐步增加难题占比,采用类似“课程学习”的思想:先从简单问题学起,逐步增加问题难度。通过多轮迭代找到高质量的推理轨迹COT数据

Kimi 的想法:我还是一步到位吧,在 step1 学推理的过程中,要时刻监控着模型的说话能力是否还正常。为了达到此目标,模型的输出长度,模型对每一个 prompt 的回答准确率等信息,全程都被严格监控。 1. 我太能理解学霸 K 了,我为啥不敢 rule-based reward 一条路走到黑?不就是因为我一训就崩,输出长度崩,performacne 崩,输出格式崩。我崩的时候会自我怀疑是不是选错方案了,学霸 K 崩了则是通过加训练技巧、改 loss 给救回来了。反观学霸 D,他的思路真的太超前太有魄力了, 别去在乎这些细节,二阶段集中解决。PS:K1.5基本上可以看成R1做法的特例情况。 dpsk直接在32B的基础模型上进行了大规模强化学习训练,然后将结果与蒸馏得到的32B模型进行比较。结果令人深思:蒸馏得到的模型在各项指标上都显著优于直接进行强化学习的模型。

张俊林:MCST树搜索会是复刻OpenAI O1/O3的有效方法吗对于打造更好的o1模型来说,最重要的是如何获得更多高质量的推理轨迹COT数据。这包括如何获得更多的<问题,答案>数据,尤其是有难度的问题。拿到<问题,答案>数据后,如何获得质量越来越高的中间推理轨迹COT数据,这里的质量很可能是根据错误中间步骤占比来衡量的,由此得到高质量的<问题,推理轨迹COT,答案>数据。这里的推理轨迹COT,可以是人工产生的,可以是大模型自己生成的,也可以是从其它模型蒸馏来得。获得方法貌似也不重要,重要的是质量是否越来越好,在此前提下,再考虑成本是否足够低。PS:大佬认为 k1.5是R1 的特例,R1 是MCST的特例。

从人类决策习惯来看

如何提升大模型的“深度思维能力” 人类的思维过程始终在动态平衡中运行:一方面,通过联想、查阅资料、与他人交流等方式“增加”信息;另一方面,通过筛选、排除、归纳等方式“减少”信息,逐步聚焦于可行的选项。这种“增-减”的循环贯穿于大部分推理和决策。从信息论的角度看,人类决策的核心目标是降低信息熵。信息熵代表了系统的不确定性程度。在高熵情况下,所有选项看似差异不大,决策难以推进;在低熵情况下,选项变得更加明确,决策变得轻松。以旅游计划为例,假如我们同时考虑了数十个景点,而它们在吸引力、距离等方面差异不大,就会产生高信息熵的困境。为了突破这一困境,人类通常会引入更多信息,如“当前季节的景色特点”“附近是否有知名餐厅”等,以逐步拉开选项间的差距,最终让决策变得明确。

既然人类是通过增-减信息以降低信息熵的,那么同样的模式能否应用到大模型上呢?我们先观察信息熵是否对大模型而言同样适用。大模型通过预测下一个词生成文本:

  1. 当下一个词非常确定,则显然的概率被集中在少数甚至一个答案上,这时其信息熵较低,模型对于结果比较有信心。
  2. 当下一个词的概率分布高度分散、每个词看起来几乎等概率时,也是信息熵极高的情况,模型实际上处于一种无法判断的状态。需要注意的是,这种“无法判断”不是简单地回答“我不知道”,而是连是否该选择“我不知道”都不确定。
  3. 从结果看,信息熵能代表模型的准度,尽管这一准度的评委似乎是模型自己,这本身似乎陷入了“循环论证”的过程,然而大模型本身也是对人类逻辑的拟合,实际上人类也在试图“解释”现象以降低信息熵,提高一致性,数据的一致性越高,模型拟合到的推理过程的一致性就越高。我们暂且搁置实际执行过程中可能存在的“循环论证”的问题,转而做一些观察,我们看看增-减信息以降低信息熵的方式,能否让模型本身准度有所提高:
  4. 对于增加论据的模式,COT应用的成功也证明了增加相关“证据”并逐渐接近答案,能让模型的准确率显著提高,增加足够多的论述过程,会让模型更倾向于得到这些论据所论述的答案。
  5. 对于减少噪声的模式,可以观察到的一点是,尽管拥有强大的注意力机制,但当上下文过长或信息过于复杂时,模型的预测精度也会显著下降。适时总结前文继续往下推理的模式,也是能让模型精度有所提升的。

根据之前探讨的内容,模型的语料中缺乏思维能力,甚至有很多相互矛盾的内容,这样的语料内在逻辑并不自洽,我们会尝试探讨如何像人一样重新“思考”一遍这些语料,并把思考过程的信息补充进去,以得到一个逻辑自洽的语料,从而降低信息熵,增加模型准确度,并且使得模型具备看上去的“思维能力”。 我们需要对于符号做一些简单的约定,我们用大写字母表示“证据/结论”:

  1. 推导过程用“->”符号表示,例如“杭州->适合旅游”,这意味着模型看到杭州这个词推导出适合旅游这个结论。
  2. 共同作用的推导过程“()->”表示,例如(充足的阳光,定期浇水)->植物健康生长,同理更多的条件时以(A,B,C,D)->E表示。

在增加信息以获取更强大模型能力的角度看,多步推理是一个非常重要的场景,典型的形式是A → B → C → D的链式推理。然而,现实语料中,面对复杂问题我们往往看到A → D的简化结论,例如“如何评价xxx公司的未来发展”,大模型往往倾向于直接“背诵”已有的分析结果,这是因为语料中对于这类复杂问题更多是结果性的内容,推理路径的缺失成为模型学习复杂逻辑的主要障碍。这引出了一个核心问题:如何合成逻辑自洽的推理路径,提升大模型的思维能力?

  1. 路径生成。生成推理路径的难点在于路径的多样性与逻辑自洽。对于同一个问题,可能存在多条不同的合理解法。以数学为例,一个定理往往可以通过多种证明方式得到结果;而在自然语言中,推理链条的表达可能更加多样化,语义上的灵活性让问题更加复杂。在数学问题上,CoT技术是非常成功的应用,通过CoT产生更多的中间推理过程数据,从而用以训练能使得模型可以逐步生成逻辑清晰的中间步骤,直到最终答案。这其中很关键的两个要素在于下一个论据的可枚举以和可验证,对于一般任务而言任务,我们可以采取更宽松的方式,例如通过大模型本身(或专为此任务微调的模型)结合人工定制策略扩充推理数据,另一种思路是直接借鉴已有人工设计的推理链条,尤其是在特定领域已经实践的人工编排策略,这种方法可以快速生成高质量的推理语料。
  2. 推理粒度与压缩。生成多步推理路径的另一个关键问题是:在什么情况下直接从A → D更有效?什么时候需要完整的A → B → C → D路径?这实际上涉及到语言模型的压缩原理。语言模型的本质是学习词与词、句与句之间的关系,并将这些知识压缩进模型。如果在语料中,A → D的频次足够高,模型学习这一关系的代价会远低于生成A → B、B → C、C → D三个关系之和。此时,从“压缩效率”的角度看,直接记忆A → D更优。然而,当A → D的出现频率较低,或者需要推理的任务复杂性更高时,模型会倾向于依赖A → B → C → D等逐步推理过程。从人类的角度来看,这种现象也有迹可循。我们的深度思考(“System 2”)会将高频推理结论沉淀为直觉(“System 1”)。例如,在日常生活中,我们很少再去逐步推导“重力会让物体下落”这一结论,而是直接将其作为常识。对于大模型,类似的压缩机制也可能自然发生,尤其是在A → D的频率足够高时。一个关键的启发是,“论据”粒度的选择需要基于全局视角。对于高频结论,直接学习A → D是一种高效选择,因为它减少了推理链条的存储和计算开销。对于低频结论或复杂任务,生成完整路径A → B → C → D则显得尤为重要。这不仅能提升模型的泛化能力,还能为任务提供更高的可解释性。这种粒度选择需要结合语料的统计分布和推理任务的目标。理想情况下,模型应能够根据任务需求动态调整推理路径的粒度:在需要效率时,优先使用简化结论;在需要逻辑完备时,生成详细路径。
  3. 多结论问题。在数据中的表现为同时存在A → B和A → C的语料,当模型学这种语料中学习时,遇到A为前提的问题,无法判断答案应该是B还是C,亦或者错误答案C的语料多,而正确答案B的语料少,在缺乏更多信息的情况下,模型很难给出正确答案。这种情况下,真实逻辑可能的是:(A, D) → B 和 (A, E) → C,也就是说,隐藏的条件D或E对推理结果起到了决定性作用。这种现象实际上颇为常见,例如同样是给出行程安排的情况,一些猎奇博主给出的旅行方案可能全篇都是猎奇的,而美食博主则可能更多关注美食,如果能把贯穿始终的风格提前识别出来并注入语料,能让模型更多以更一致的视角回答问题,降低信息熵,提高模型准度。对于一般的“错误和偏见”问题,例如“三亚这人虽然不多,但是太热了,不适合来玩”,可能是因为“现在是夏天,而夏天是淡季”,这种类似人类阅读直觉的,能让语料本身的逻辑更加自洽。除此之外类似小说创作先列出大纲,笑话先写出笑点,对于创造的稳定性而言都是显著的增加。
  4. 降低信息/噪声。在人类的逻辑语言中,经常在同一篇文章中会存在大量不相关的内容,越是长的论述中,越容易出现这种现象,因为人类在做深度思维时,总会习惯性的拆分出多个子问题,以分开论述,例如(A, B) → C,在逐步证明A和B的过程中,会引入大量的过程论述,一直递归到足以回答问题为止。然而这一过程也为整个文本注入了大量的噪声,例如当我们论述B时,A的论述过程对B而言是噪声。类似的现象还有很多,例如当我们让大模型帮我们写一本小说时,我们会列好大纲,也可能是多级的大纲,然而当我们考虑把大纲中某一章节展开细节时,前文大量的过程都我们而言都是噪音,亦或是大纲的形态也可能是双线叙事,另一条故事线的很多细节也是对于本故事线而言也是噪音,我们只会关注交织点或者可能的共同点等。

可以看到,不管是增加信息还是减少信息,其过程都对语料全局的统计信息有所依赖,例如单步推理的合理性评估、对文本目的性的识别、路径颗粒度的合理程度等等,对于统计信息的依赖,一个比较容易的路径就是利用现有的大模型,因为现有大模型已经对整体语料“学习”过一遍,再对其进行针对性微调,模型在很大程度上能胜任这些任务。也就是说,通过当前模型的弱推理、弱规划能力,逐步强化数据以达到更强的推理、规划能力。 对于模型如何学习“人类思考过程”还有很多可以探讨的内容,限于篇幅,太多细节不便展开。人类在“阅读”知识的时候,会持续加入自身理解和判断,主动聚焦和拆解问题,而目前大部分语料并不具备这样的过程记录。对于大模型而言,通过对人类学习过程的模拟来加深模型的思考能力,能很大程度提高其推理能力。深度思考能力是人类解决复杂问题能力的核心,甚至是通往AGI的必经之路,通过预训练语料的修正只是其中一环,如何与真实世界链接,如何建立类人的反馈机制,这些问题一步步解决,似乎让我们能够瞥见AGI一眼。 PS:让llm有思维能力,一个是预训练 数据就得有体现思维的数据让llm“见识”过,再一个就是微调的时候对推理过程有评价,让llm被“知错就改、刻意练习”过。

ps: 梳理下,如果要提高llm推理能力,post-trainning时就不能只靠<问题,答案>,而要靠<问题,推理轨迹COT,答案>,让llm可以输出步骤,进而通过rl(也就是要有一个rm或类似工具)来评价这些步骤,进而更新llm参数。

  1. <问题,推理轨迹COT,答案> 从哪里来,如何过滤带有错误步骤、错误答案的路径,进而sft llm。这个阶段的主要目的一个是让大模型能够产生初步的深度思考能力,一个是输出格式满足我们希望的形式,通过调整模型参数让这种能力内化到模型里。
  2. 如何rl?比如我们现在拿到一个问题以及对应的标准答案数据<问题,标准答案>,此时让Model-SFT自己产生K条完整的推理轨迹COT,以及对应的答案。
    1. ORM(结果回报模型)根据某条推理轨迹产生的答案是否和问题的标准答案相同给出Reward,符合标准答案给出正向高回报,不符合标准答案则负向低回报。同一个问题,K个推理轨迹,K个答案,产生高低不同的K个回报。我们可以认为得到高回报的推理轨迹质量高,于是,我们希望根据目前得到的这些数据,来调整下模型参数,让模型以后倾向输出那些高回报的推理轨迹COT作为思考过程,而别产生那些低回报的推理轨迹COT,这是强化学习希望达到的目标。PS: 结果对+ 格式对,就算你推理对?
    2. MCTS+ PRM 基于每个step进行过程评价
  3. 高质量 <问题,推理轨迹COT,答案> 不是一步到位的,一般要经过一个多轮迭代的过程。

Related Issues not found

Please contact @qiankunli to initialize the comment