技术上,如何复现 o1?

图片

知乎:周舒畅
链接:https://zhuanlan.zhihu.com/p/720127190

基础模型

搞 o1 首先需要一个基模,这个基模必须是:

  1. 能进行“长”生成。注意这和“长 context”不是一回事。模型生成的结果,经常会有自激的噪声存在,或分布逐渐变得非常 sharp,从而导致模型生成内容的后半段质量下降。比如写小说时会“烂尾”,用大团圆草草收场。在多模生成模型上也很容易观察到这一现象,表现为生成的音频和视频在结尾处要么糊掉要么变成静音静止。

  2. 有较强的抗噪能力。目前看来,这一点刚需大模型,比如万亿的 step2 就是比千亿的 step1 好。小模型容易被 context 里的一点点错误带偏。考虑到 CoT 就是个 trial-and-error 的过程,要能从鱼龙混杂的 context 里筛出有用信息往下走,需要一个充分训练的大模型。

数据

数据上,如果起手式是模仿学习(SFT),需要至少是起动量的规划数据:

  • 比如一个看起来能分解成步骤的题,可以由人类演示如何拆成哪几步。

  • 或者由模型按类似 ReAct / Reflection / RePlan 的方式 CoT,然后人类给过程打分。一个可能的捷径是构造 CoT 的 DPO 数据。

这里说是起动量,是因为这些数据生产困难,后面还是要靠 Self-Play 来起量。(现在有了 O1,有 GPT 帐号的厂又可以用 O1 来生成这个“起动量”的数据了)。

接下来 RL 部分需要大量的 Reward Model 数据(评论区说可能 O1 只用 RL)。考虑到 CoT 数据非常长,很难一上来就全对,所以大概率是个 PRM,相当于人类标出 CoT (可能是树型)的第一个出错点。

这里能从自动定理证明器(ATP)如 LEAN/Coq 借鉴的一招是“tactics”。比如 O1 会有意识地做简化(simpl)操作,也会设变量(intros)。如果实锤 O1 会数学归纳法(induction),那就真的很可能有一个把 ATP 产生的证明,按自然语言翻译成 CoT 数据的造数据路径。

算法

算法上,需要一个有数据效率(Data Efficient)的算法。应该是某种 MCTS(因为 o1 解得好的都是 verifier 容易的题)。这个在去年以来的各种 Q*-clone 探索中都有覆盖。这里麻烦的应该是系统和算法的配合,因为大规模推理造数据看来少不了。

o1-mini 的存在值得玩味。据说 o1-mini 数学甚至更强,但是推理会更“无理”。顺序上,是先有 o1-mini 还是先有 o1-preview?如果先有 o1-mini,那么可以用 o1-mini 大量的 roll 数据;如果先有 o1-preview,那么可以从 o1-preview 造大量数据去喂饱 o1-mini。或者是两者交替成为共轭师徒。

还有个简单的可能是 o1 训得慢,而 o1-mini 模型小训得快,先过完了数据放出来。。。

FAQ

Q:目前 o1 似乎主要展示了在解题时的强大能力。那么在其他方面,比如在多模态理解生成一体中,有什么应用?

A:o1 非常深刻地改变了 LLM,所有目前的 LLM 应用,只要存在一个基于或不基于 LLM 的 verifier,或者有约束要满足,都会受到断代式的影响。比如以前多模生成里,指令跟随一直是困难的问题,具体例子有生成 3D 资产需要的高一致性的多视角图,之前只能靠后挑生成。o1 则打开了模型反复修改“sketch”,来达到约束生成的可能。可以想象 o1 自言自语,然后在画布上这里一笔那里一笔涂涂抹抹的场面。

Q:对 AI 搜索和角色扮演有什么影响呢?

A:AI 搜索中,复杂的二次搜索(如读一篇论文时还参考参考文献)等,都是需要均衡每个动作成本收益,以及顾及当前时间预算的行为。o1 展现了这个潜力,并且箭在弦上(“o1-preview doesn't use tools yet, but support for function calling, code interpreter, and browsing is planned”)。

对于角色扮演来说,o1 提供了一个框架,让不烂尾,不无聊的生成成为可能。这几天多个测试表明,o1 是诗歌之类“戴着镣铐跳舞”式创作的大师。那么 AI 角色扮演需要的“乐而不淫”、“文似看山不喜平”、“草蛇灰线”对于 o1 来说,无非是一条条约束而已。“两句三年得,一吟双泪流。” 以后流的是电费的心痛的泪。

<think>嗯,用户现在需要撰写技术复现报告的指南或模板。首先,我得回想一下技术复现报告通常包含哪些部分。根据之前的识,这类报告需要详细记录问题复现的步骤、环境、结果分析等。用户提到了参考引用中的缺陷报告模板,可能需要将两者结合起来。 用户提供的引用内容里,缺陷报告模板包括标题、重现步骤、预期结果、实际结果、严重程度、优先级、测试环境等。技术复现报告可能类似,但更侧重于复现过程的技术细节,比如环境配置、步骤的精确性、日志或截图的支持材料。 接下来,我需要确保回答的结构清晰,分点列出每个部分的要求,并提供示例模板。同时,要参考用户提到的缺陷报告模板中的要点,比如步骤的详细描述、环境的配置、附件的使用等。可能还需要提醒用户注意简洁、准确,每个问题单独报告,这和缺陷报告中的建议一致。 另外,用户可能希望复现报告不仅用于内部记录,还可能用于与开发团队沟通或作为项目文档的一部分。因此,需要强调客观性和可重复性,确保其他人能根据报告复现问题。可能需要加入注意事项,比如多次验证步骤、避免主观推测等。 最后,生成相关问题时要围绕技术复现报告的编写技巧、结构优化、与缺陷报告的区别等方面,帮助用户进一步理解。需要确保问题有针对性,能够引导用户深入思考如何改进他们的报告。</think>### 如何撰写技术复现报告 技术复现报告的核心目标是**清晰、完整地记录问题重现过程**,需包含以下关键要素: --- #### 一、基础结构模板 1. **标题** - 简洁概括问题本质,例如:“服务端内存泄漏问题复现报告” - 示例:`$O(n^2)$时间复杂度导致接口响应延迟复现` 2. **问题描述** - 说明问题现象及影响范围 - 示例: > 当并发请求超过1000次时,API响应时间从$50ms$上升至$500ms$,CPU占用率突破$90\%$[^1] 3. **复现环境** | 类别 | 配置详情 | |------------|---------------------------| | 操作系统 | CentOS 7.9 | | 测试工具 | JMeter 5.4.1 | | 依赖版本 | Java 11, Spring Boot 2.7 | 4. **复现步骤** ```markdown 1. 启动压力测试工具,设置线程组为`1000并发` 2. 配置HTTP请求指向`/api/v1/query` 3. 添加`Response Time`和`CPU Usage`监控 4. 执行测试持续5分钟 ``` 5. **数据记录** - 预期结果:响应时间稳定在$50ms±5ms$ - 实际结果:响应时间分布为$50ms→500ms$(附性能曲线图) 6. **技术分析** - 使用公式说明问题根源: $$ T(n) = C \cdot n^2 + O(n) $$ - 代码定位:`Service层未启用缓存机制` 7. **附件** - 测试脚本、日志文件、监控截图(需标注关键时间戳) --- #### 二、编写规范 1. **客观性原则** - 以需求文档、测试用例为基准,避免主观判断[^1] - 示例: > 根据《性能测试规范V3.2》第5条,接口响应时间阈值应为$100ms$ 2. **精准性要求** - 每个操作步骤独立成段,如: > 步骤③:通过`tcpdump`抓取$10s$网络包,过滤`port 8080` 3. **可视化增强** - 插入代码段、数学表达式、图表: ```python def leak_function(): data = [[0]*1024 for _ in range(10**6)] # 内存泄漏点 ``` --- #### 三、示例片段 > **内存泄漏复现路径** > 1. 使用`Valgrind`工具检测堆分配: > $$ \text{Memory\_leak} = \sum_{i=1}^{n} \text{unreleased\_blocks}_i $$ > 2. 对比测试:启用缓存前后内存占用差异达$200MB$ ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值