1
00:00:00,000 --> 00:00:03,180
Hello 今天咱们来聊点超有意思的AI圈新鲜事

2
00:00:03,180 --> 00:00:05,800
绝对能刷新你之前对大模型的刻板印象

3
00:00:05,800 --> 00:00:08,260
今天我们来聊聊一个有点意思的模型

4
00:00:08,260 --> 00:00:09,800
Mindforge 27B

5
00:00:09,800 --> 00:00:11,600
听到名字里的27B

6
00:00:11,600 --> 00:00:14,120
你可能会觉得这不就是个小参数模型吗

7
00:00:14,120 --> 00:00:17,380
毕竟现在动辄千亿参数的AI模型满天飞

8
00:00:17,380 --> 00:00:19,340
27B顶多算个小个子

9
00:00:19,340 --> 00:00:20,860
但就是这个小个子

10
00:00:20,860 --> 00:00:23,500
在编程能力上却干翻了不少大块头

11
00:00:23,500 --> 00:00:26,020
在编程测试基准Program Bench上

12
00:00:26,020 --> 00:00:27,760
它的第一次尝试通过率

13
00:00:27,760 --> 00:00:30,560
Pasit-E达到了49.51%

14
00:00:30,560 --> 00:00:34,400
比DeepSeek第四代专业版的47.80%还高

15
00:00:34,400 --> 00:00:38,860
甚至逼近了Cloud Opus 4.7的51.38%

16
00:00:38,860 --> 00:00:42,380
要知道Cloud Opus 4.7可是公认的编程高手

17
00:00:42,380 --> 00:00:45,940
而Mindforge 27B只用了1001条数据训练

18
00:00:45,940 --> 00:00:47,560
这到底是咋做到的

19
00:00:47,560 --> 00:00:50,340
咱们今天就来扒一扒它背后的技术细节

20
00:00:50,340 --> 00:00:51,460
首先得说

21
00:00:51,460 --> 00:00:53,800
这个模型的核心不在参数多

22
00:00:53,800 --> 00:00:55,000
而在数据精

23
00:00:55,000 --> 00:00:57,540
传统的大模型训练编程能力

24
00:00:57,540 --> 00:00:59,320
基本都是海量堆数据

25
00:00:59,320 --> 00:01:01,220
GitHub上几百万个项目

26
00:01:01,220 --> 00:01:02,820
几十亿行代码片段

27
00:01:02,820 --> 00:01:05,700
甚至包括各种开源库的函数定义

28
00:01:05,700 --> 00:01:06,360
注释

29
00:01:06,360 --> 00:01:07,400
用法视力

30
00:01:07,400 --> 00:01:09,000
一股脑往模型里塞

31
00:01:09,000 --> 00:01:11,460
这种训练方式确实能让模型

32
00:01:11,460 --> 00:01:12,840
学会写代码的语法

33
00:01:12,840 --> 00:01:14,340
比如怎么定义变量

34
00:01:14,340 --> 00:01:15,200
写循环

35
00:01:15,200 --> 00:01:15,840
掉裤

36
00:01:15,840 --> 00:01:17,060
但有个大问题

37
00:01:17,060 --> 00:01:18,940
它学到的是局部技能

38
00:01:18,940 --> 00:01:20,320
而不是工程思维

39
00:01:20,320 --> 00:01:23,000
就像你让一个只会被单词的人写小说

40
00:01:23,000 --> 00:01:24,400
他可能词都认识

41
00:01:24,400 --> 00:01:26,020
但写不出连贯的故事

42
00:01:26,020 --> 00:01:28,960
Mindforge 27B完全反其道而行之

43
00:01:28,960 --> 00:01:30,880
它没用海量代码片段

44
00:01:30,880 --> 00:01:33,280
而是用了1001条完整开发轨迹

45
00:01:33,280 --> 00:01:34,980
啥叫完整开发轨迹

46
00:01:34,980 --> 00:01:36,200
咱们打个比方

47
00:01:36,200 --> 00:01:39,400
你让一个程序员开发一个电商订单管理系统

48
00:01:39,400 --> 00:01:41,900
传统数据可能只给他订单创建

49
00:01:41,900 --> 00:01:43,360
这个函数的代码片段

50
00:01:43,360 --> 00:01:45,440
或者库存检查的一段逻辑

51
00:01:45,440 --> 00:01:47,100
但完整开发轨迹

52
00:01:47,100 --> 00:01:48,900
是从老板提需求开始

53
00:01:48,900 --> 00:01:50,680
到程序员分析需求

54
00:01:50,680 --> 00:01:51,920
设计系统架构

55
00:01:51,920 --> 00:01:52,940
画流程图

56
00:01:52,940 --> 00:01:53,720
写代码

57
00:01:53,720 --> 00:01:54,360
测bug

58
00:01:54,360 --> 00:01:55,040
改bug

59
00:01:55,040 --> 00:01:55,980
最后上线

60
00:01:55,980 --> 00:01:58,000
整个过程每一步的对话

61
00:01:58,000 --> 00:01:58,620
思考

62
00:01:58,620 --> 00:01:59,520
代码修改

63
00:01:59,520 --> 00:02:00,360
错误反馈

64
00:02:00,360 --> 00:02:01,420
全都有记录

65
00:02:01,420 --> 00:02:02,560
具体来说

66
00:02:02,560 --> 00:02:04,000
这1001条轨迹

67
00:02:04,000 --> 00:02:06,740
平均每条有181.6轮对话

68
00:02:06,740 --> 00:02:08,220
这不是简单的问答

69
00:02:08,220 --> 00:02:10,560
而是像真实开发团队里的协作

70
00:02:10,560 --> 00:02:11,680
比如第一轮

71
00:02:11,680 --> 00:02:13,380
用户也就是需求方说

72
00:02:13,380 --> 00:02:14,980
我们需要一个订单系统

73
00:02:14,980 --> 00:02:16,800
要支持多种支付方式

74
00:02:16,800 --> 00:02:18,460
还要能实时查库存

75
00:02:18,460 --> 00:02:20,020
模型作为开发者

76
00:02:20,020 --> 00:02:21,360
不会直接写代码

77
00:02:21,360 --> 00:02:22,380
而是先问细节

78
00:02:22,380 --> 00:02:24,660
支付方式需要支持支付宝

79
00:02:24,660 --> 00:02:25,980
微信还是银行卡

80
00:02:25,980 --> 00:02:28,340
实时查库存是扣库存钱查

81
00:02:28,340 --> 00:02:29,560
还是扣库存实查

82
00:02:29,560 --> 00:02:30,720
订单取消后

83
00:02:30,720 --> 00:02:31,800
库存要不要回退

84
00:02:31,800 --> 00:02:33,020
用户回答后

85
00:02:33,020 --> 00:02:34,600
模型会接着设计架构

86
00:02:34,600 --> 00:02:36,280
我们可以分订单服务

87
00:02:36,280 --> 00:02:37,160
支付服务

88
00:02:37,160 --> 00:02:38,600
库存服务三个模块

89
00:02:38,600 --> 00:02:40,160
用消息对列结偶

90
00:02:40,160 --> 00:02:41,520
然后写代码的时候

91
00:02:41,520 --> 00:02:43,820
模型会写订单表的创建语句

92
00:02:43,820 --> 00:02:44,960
写接口定义

93
00:02:44,960 --> 00:02:46,000
写业务逻辑

94
00:02:46,000 --> 00:02:47,180
写完跑测试

95
00:02:47,180 --> 00:02:48,800
比如发现高并发时

96
00:02:48,800 --> 00:02:49,820
库存扣减不对

97
00:02:49,820 --> 00:02:52,300
模型会根据错误日志分析原因

98
00:02:52,300 --> 00:02:54,000
应该是没加分布是锁

99
00:02:54,000 --> 00:02:55,140
导致两个请求

100
00:02:55,140 --> 00:02:56,600
同时读到库存为一

101
00:02:56,600 --> 00:02:57,440
都扣了

102
00:02:57,440 --> 00:02:58,540
然后修改代码

103
00:02:58,540 --> 00:02:59,160
加锁

104
00:02:59,160 --> 00:02:59,980
再测试

105
00:02:59,980 --> 00:03:00,920
直到通过

106
00:03:00,920 --> 00:03:01,460
你看

107
00:03:01,460 --> 00:03:03,660
这181.6轮对话里

108
00:03:03,660 --> 00:03:05,720
每一轮都包含三类信息

109
00:03:05,720 --> 00:03:06,540
上下文

110
00:03:06,540 --> 00:03:07,920
之前的需求讨论

111
00:03:07,920 --> 00:03:08,860
架构设计

112
00:03:08,860 --> 00:03:09,560
动作

113
00:03:09,560 --> 00:03:10,580
写了什么代码

114
00:03:10,580 --> 00:03:11,360
改了哪里

115
00:03:11,360 --> 00:03:11,980
反馈

116
00:03:11,980 --> 00:03:13,220
测试报了什么错

117
00:03:13,220 --> 00:03:14,580
用户提了什么意见

118
00:03:14,580 --> 00:03:15,900
模型训练的时候

119
00:03:15,900 --> 00:03:18,280
就是学习这三者之间的因果链

120
00:03:18,280 --> 00:03:19,420
根据上下文

121
00:03:19,420 --> 00:03:20,600
应该做什么动作

122
00:03:20,600 --> 00:03:22,580
做了动作会得到什么反馈

123
00:03:22,580 --> 00:03:24,540
得到反馈后该怎么调整

124
00:03:24,540 --> 00:03:26,420
这比单纯学代码片段

125
00:03:26,420 --> 00:03:27,120
长什么样

126
00:03:27,120 --> 00:03:28,080
高明太多了

127
00:03:28,080 --> 00:03:29,120
他学到的是

128
00:03:29,120 --> 00:03:31,060
开发代码的全流程逻辑

129
00:03:31,060 --> 00:03:32,520
也就是工程思维

130
00:03:32,520 --> 00:03:34,740
那这些轨迹数据是怎么来的

131
00:03:34,740 --> 00:03:36,640
研究团队从开源项目的

132
00:03:36,640 --> 00:03:38,440
完整开发历史里挖出来的

133
00:03:38,440 --> 00:03:40,600
比如Github上一些知名项目的

134
00:03:40,600 --> 00:03:41,580
issue讨论区

135
00:03:41,580 --> 00:03:43,300
PolRequest的修改记录

136
00:03:43,300 --> 00:03:44,660
代码评审的评论

137
00:03:44,660 --> 00:03:47,000
甚至是开发者之间的聊天记录

138
00:03:47,000 --> 00:03:48,000
当然脱敏了

139
00:03:48,000 --> 00:03:50,060
他们把这些非结构化的数据

140
00:03:50,060 --> 00:03:51,760
整理成结构化的对话

141
00:03:51,760 --> 00:03:52,360
代码

142
00:03:52,360 --> 00:03:53,160
反馈链

143
00:03:53,160 --> 00:03:55,380
每条轨迹都像一部开发日志

144
00:03:55,380 --> 00:03:56,620
记录了一个功能

145
00:03:56,620 --> 00:03:58,100
从无到有的全过程

146
00:03:58,100 --> 00:03:59,240
比如某个轨迹

147
00:03:59,240 --> 00:04:00,300
可能是开发一个

148
00:04:00,300 --> 00:04:01,880
用户登陆健全功能

149
00:04:01,880 --> 00:04:03,120
从最开始讨论

150
00:04:03,120 --> 00:04:04,900
用JWT还是Session

151
00:04:04,900 --> 00:04:06,820
到设计Token刷新机制

152
00:04:06,820 --> 00:04:08,480
到写登陆接口代码

153
00:04:08,480 --> 00:04:09,580
到测试发现

154
00:04:09,580 --> 00:04:11,120
Token过期时间太短

155
00:04:11,120 --> 00:04:12,740
再到调整过期时间

156
00:04:12,740 --> 00:04:13,980
加刷新接口

157
00:04:13,980 --> 00:04:14,860
最后上线

158
00:04:14,860 --> 00:04:15,860
这些细节

159
00:04:15,860 --> 00:04:17,240
传统代码数据里

160
00:04:17,240 --> 00:04:18,240
根本不会保留

161
00:04:18,240 --> 00:04:19,860
接下来是训练策略

162
00:04:19,860 --> 00:04:21,100
研究团队用了

163
00:04:21,100 --> 00:04:22,200
英国语言建模

164
00:04:22,200 --> 00:04:24,180
但不是普通的英国建模

165
00:04:24,180 --> 00:04:25,300
普通建模是

166
00:04:25,300 --> 00:04:26,940
把一段文本拆成Token

167
00:04:26,940 --> 00:04:28,900
让模型预测下一个Token

168
00:04:28,900 --> 00:04:30,680
而MindForge 27B

169
00:04:30,680 --> 00:04:32,160
把轨迹拆成片段

170
00:04:32,160 --> 00:04:33,040
每个片段

171
00:04:33,040 --> 00:04:34,420
可能是用户需求

172
00:04:34,420 --> 00:04:35,380
模型回复

173
00:04:35,380 --> 00:04:36,140
代码快

174
00:04:36,140 --> 00:04:37,000
错误日志

175
00:04:37,000 --> 00:04:39,780
然后让模型学习在什么上下文下

176
00:04:39,780 --> 00:04:41,600
该生成什么类型的片段

177
00:04:41,600 --> 00:04:44,220
比如前面是用户提了一个bug反馈

178
00:04:44,220 --> 00:04:47,560
模型就该预测错误分析和代码修改片段

179
00:04:47,560 --> 00:04:49,700
而不是直接生成代码片段

180
00:04:49,700 --> 00:04:53,500
这种结构化预测让模型更理解开发流程的节奏

181
00:04:53,500 --> 00:04:54,820
还有一个关键点

182
00:04:54,820 --> 00:04:57,140
模型在训练时会模拟错误

183
00:04:57,140 --> 00:04:58,260
传统训练里

184
00:04:58,260 --> 00:05:00,120
代码数据大多是正确的

185
00:05:00,120 --> 00:05:01,980
比如开源项目的最终代码

186
00:05:01,980 --> 00:05:04,760
模型很少看到错误代码和修复过程

187
00:05:04,760 --> 00:05:07,080
但MindForge 27B的轨迹里

188
00:05:07,080 --> 00:05:09,640
包含大量错误修复的循环

189
00:05:09,640 --> 00:05:11,260
比如模型写了一段代码

190
00:05:11,260 --> 00:05:12,940
测试爆空指针异常

191
00:05:12,940 --> 00:05:15,620
然后模型会分析哪个变量可能为空

192
00:05:15,620 --> 00:05:17,220
修改代码加判空

193
00:05:17,220 --> 00:05:18,080
再测试

194
00:05:18,080 --> 00:05:19,740
可能又爆类型不匹配

195
00:05:19,740 --> 00:05:20,700
再调整

196
00:05:20,700 --> 00:05:21,780
这种试错过程

197
00:05:21,780 --> 00:05:23,660
让模型学会了如何调试

198
00:05:23,660 --> 00:05:25,460
这不是靠记住常见bug

199
00:05:25,460 --> 00:05:27,720
而是掌握了排查问题的思路

200
00:05:27,720 --> 00:05:29,160
就像一个老程序员

201
00:05:29,160 --> 00:05:31,180
不是背会了所有bug的解法

202
00:05:31,180 --> 00:05:33,340
而是掌握了排查问题的思路

203
00:05:33,340 --> 00:05:34,780
那效果为啥这么好

204
00:05:34,780 --> 00:05:36,240
咱们再看实验细节

205
00:05:36,240 --> 00:05:39,340
ProgramBench是一个很严格的编程测试集

206
00:05:39,340 --> 00:05:41,520
里面全是真实的工程任务

207
00:05:41,520 --> 00:05:44,060
比如实现一个分布式缓存系统

208
00:05:44,060 --> 00:05:45,820
优化一个数据库查询

209
00:05:45,820 --> 00:05:47,500
写一个微服务的网关

210
00:05:47,500 --> 00:05:49,760
而不是简单的写个排序算法

211
00:05:49,760 --> 00:05:51,300
它的PASATD指标

212
00:05:51,300 --> 00:05:53,560
就是模型第一次生成的代码

213
00:05:53,560 --> 00:05:55,920
直接通过所有测试用力的比例

214
00:05:55,920 --> 00:05:57,800
这个指标比PASAT10

215
00:05:57,800 --> 00:05:59,920
尝试十次通过更靠谱

216
00:05:59,920 --> 00:06:01,240
因为实际开发中

217
00:06:01,240 --> 00:06:03,380
你不可能让模型试十次

218
00:06:03,380 --> 00:06:05,300
要的是第一次就尽量对

219
00:06:05,300 --> 00:06:09,380
Mindforge 27B的PASAT1是49.51%

220
00:06:09,380 --> 00:06:11,320
意味着它几乎一半的任务

221
00:06:11,320 --> 00:06:13,520
第一次生成的代码就能跑通

222
00:06:13,520 --> 00:06:16,920
而Deepseek V4 Pro用了海量代码数据训练

223
00:06:16,920 --> 00:06:17,940
参数更大

224
00:06:17,940 --> 00:06:20,800
但PASAT1只有47.80%

225
00:06:20,800 --> 00:06:23,760
Claude Opus 4.7虽然是顶尖模型

226
00:06:23,760 --> 00:06:26,280
但也只比它高1.87个百分点

227
00:06:26,280 --> 00:06:27,040
这说明啥

228
00:06:27,040 --> 00:06:30,180
说明在编程这种强工程属性的任务里

229
00:06:30,180 --> 00:06:31,380
知道怎么开发

230
00:06:31,380 --> 00:06:33,720
比知道多少代码片段更重要

231
00:06:33,720 --> 00:06:34,760
更有意思的是

232
00:06:34,760 --> 00:06:36,680
研究团队做了个对比实验

233
00:06:36,680 --> 00:06:38,540
用同样的27B模型

234
00:06:38,540 --> 00:06:41,280
一组用1001条完整轨迹训练

235
00:06:41,280 --> 00:06:43,740
另一组用100万条代码片段

236
00:06:43,740 --> 00:06:45,680
相当于传统数据量训练

237
00:06:45,680 --> 00:06:46,320
结果

238
00:06:46,320 --> 00:06:47,680
轨迹训练的模型

239
00:06:47,680 --> 00:06:49,140
在Program Bench上

240
00:06:49,140 --> 00:06:51,420
PASAT1是49.51%

241
00:06:51,420 --> 00:06:53,600
而海量片段训练的模型

242
00:06:53,600 --> 00:06:55,420
只有32.7%

243
00:06:55,420 --> 00:06:57,140
差了快17个百分点

244
00:06:57,140 --> 00:06:58,220
这直接证明

245
00:06:58,220 --> 00:06:59,980
高质量的全流程数据

246
00:06:59,980 --> 00:07:02,280
比海量的局部数据有效得多

247
00:07:02,280 --> 00:07:04,280
那这对中小团队意味着啥

248
00:07:04,280 --> 00:07:05,380
以前大家觉得

249
00:07:05,380 --> 00:07:07,220
要做个能写代码的AI

250
00:07:07,220 --> 00:07:08,500
得有千亿参数

251
00:07:08,500 --> 00:07:10,180
得有几十万块GPU

252
00:07:10,180 --> 00:07:12,040
得收集TB级的数据

253
00:07:12,040 --> 00:07:13,720
中小团队根本玩不起

254
00:07:13,720 --> 00:07:16,020
但Mindforge 27B告诉我们

255
00:07:16,020 --> 00:07:16,460
不用

256
00:07:16,460 --> 00:07:18,160
你只需要花精力整理

257
00:07:18,160 --> 00:07:20,620
几百上千条高质量的开发轨迹

258
00:07:20,620 --> 00:07:22,160
用个小参数模型

259
00:07:22,160 --> 00:07:23,280
比如27B

260
00:07:23,280 --> 00:07:25,220
几张V100卡就能训练

261
00:07:25,220 --> 00:07:27,940
就能做出接近顶尖大模型的效果

262
00:07:27,940 --> 00:07:29,980
这对资源有限的团队来说

263
00:07:29,980 --> 00:07:31,120
简直是福音

264
00:07:31,120 --> 00:07:32,220
不用卷算力

265
00:07:32,220 --> 00:07:33,440
不用卷数据量

266
00:07:33,440 --> 00:07:34,940
卷数据质量就行了

267
00:07:34,940 --> 00:07:36,840
比如一个小团队想做一个

268
00:07:36,840 --> 00:07:38,780
金融代码生成的专业模型

269
00:07:38,780 --> 00:07:41,260
他们不用去爬Github上所有代码

270
00:07:41,260 --> 00:07:43,620
只需要找几个资深金融工程师

271
00:07:43,620 --> 00:07:45,500
记录他们开发风控系统

272
00:07:45,500 --> 00:07:46,920
交易接口的全过程

273
00:07:46,920 --> 00:07:48,500
整理成几百条轨迹

274
00:07:48,500 --> 00:07:50,720
就能训练出一个懂金融业务

275
00:07:50,720 --> 00:07:52,220
懂工程逻辑的模型

276
00:07:52,220 --> 00:07:53,940
这种模型虽然参数小

277
00:07:53,940 --> 00:07:56,020
但比那些啥都懂一点的大模型

278
00:07:56,020 --> 00:07:58,160
在实际金融场景里更靠谱

279
00:07:58,160 --> 00:07:59,240
最后总结一下

280
00:07:59,240 --> 00:08:01,300
Mindforge 27B的成功

281
00:08:01,300 --> 00:08:03,820
其实打破了一个长期存在的迷思

282
00:08:03,820 --> 00:08:05,860
编程能力等于参数规模

283
00:08:05,860 --> 00:08:06,620
它证明

284
00:08:06,620 --> 00:08:08,660
在编程这种需要强逻辑

285
00:08:08,660 --> 00:08:10,300
强工程思维的领域

286
00:08:10,300 --> 00:08:11,360
数据的质量

287
00:08:11,360 --> 00:08:12,580
是不是全流程

288
00:08:12,580 --> 00:08:14,420
是不是包含试错过程

289
00:08:14,420 --> 00:08:16,160
是不是有完整上下文

290
00:08:16,160 --> 00:08:17,560
比数据量更重要

291
00:08:17,560 --> 00:08:18,560
就像教徒弟

292
00:08:18,560 --> 00:08:20,640
你让他看一万行代码片段

293
00:08:20,640 --> 00:08:23,060
不如让他跟着你完整做十个项目

294
00:08:23,060 --> 00:08:25,280
因为前者只能让他记住怎么写

295
00:08:25,280 --> 00:08:27,220
后者能让他学会怎么做

296
00:08:27,220 --> 00:08:27,780
未来

297
00:08:27,780 --> 00:08:30,960
可能会有更多这种小而美的专业模型出现

298
00:08:30,960 --> 00:08:32,640
他们不需要千亿参数

299
00:08:32,640 --> 00:08:35,240
只需要几千条高质量的领域轨迹

300
00:08:35,240 --> 00:08:37,840
就能在特定领域达到顶尖水平

301
00:08:37,840 --> 00:08:40,160
这对AI的普及来说是件好事

302
00:08:40,160 --> 00:08:42,200
毕竟不是每个团队都有谷歌

303
00:08:42,200 --> 00:08:43,480
OpenAI的资源

304
00:08:43,480 --> 00:08:46,580
但每个团队都可能拥有高质量的领域数据

305
00:08:46,580 --> 00:08:49,700
Mindforge 27B算是给我们开了个好投