WEBVTT

00:00.000 --> 00:03.180
Hello 今天咱们来聊点超有意思的AI圈新鲜事

00:03.180 --> 00:05.800
绝对能刷新你之前对大模型的刻板印象

00:05.800 --> 00:08.260
今天我们来聊聊一个有点意思的模型

00:08.260 --> 00:09.800
Mindforge 27B

00:09.800 --> 00:11.600
听到名字里的27B

00:11.600 --> 00:14.120
你可能会觉得这不就是个小参数模型吗

00:14.120 --> 00:17.380
毕竟现在动辄千亿参数的AI模型满天飞

00:17.380 --> 00:19.340
27B顶多算个小个子

00:19.340 --> 00:20.860
但就是这个小个子

00:20.860 --> 00:23.500
在编程能力上却干翻了不少大块头

00:23.500 --> 00:26.020
在编程测试基准Program Bench上

00:26.020 --> 00:27.760
它的第一次尝试通过率

00:27.760 --> 00:30.560
Pasit-E达到了49.51%

00:30.560 --> 00:34.400
比DeepSeek第四代专业版的47.80%还高

00:34.400 --> 00:38.860
甚至逼近了Cloud Opus 4.7的51.38%

00:38.860 --> 00:42.380
要知道Cloud Opus 4.7可是公认的编程高手

00:42.380 --> 00:45.940
而Mindforge 27B只用了1001条数据训练

00:45.940 --> 00:47.560
这到底是咋做到的

00:47.560 --> 00:50.340
咱们今天就来扒一扒它背后的技术细节

00:50.340 --> 00:51.460
首先得说

00:51.460 --> 00:53.800
这个模型的核心不在参数多

00:53.800 --> 00:55.000
而在数据精

00:55.000 --> 00:57.540
传统的大模型训练编程能力

00:57.540 --> 00:59.320
基本都是海量堆数据

00:59.320 --> 01:01.220
GitHub上几百万个项目

01:01.220 --> 01:02.820
几十亿行代码片段

01:02.820 --> 01:05.700
甚至包括各种开源库的函数定义

01:05.700 --> 01:06.360
注释

01:06.360 --> 01:07.400
用法视力

01:07.400 --> 01:09.000
一股脑往模型里塞

01:09.000 --> 01:11.460
这种训练方式确实能让模型

01:11.460 --> 01:12.840
学会写代码的语法

01:12.840 --> 01:14.340
比如怎么定义变量

01:14.340 --> 01:15.200
写循环

01:15.200 --> 01:15.840
掉裤

01:15.840 --> 01:17.060
但有个大问题

01:17.060 --> 01:18.940
它学到的是局部技能

01:18.940 --> 01:20.320
而不是工程思维

01:20.320 --> 01:23.000
就像你让一个只会被单词的人写小说

01:23.000 --> 01:24.400
他可能词都认识

01:24.400 --> 01:26.020
但写不出连贯的故事

01:26.020 --> 01:28.960
Mindforge 27B完全反其道而行之

01:28.960 --> 01:30.880
它没用海量代码片段

01:30.880 --> 01:33.280
而是用了1001条完整开发轨迹

01:33.280 --> 01:34.980
啥叫完整开发轨迹

01:34.980 --> 01:36.200
咱们打个比方

01:36.200 --> 01:39.400
你让一个程序员开发一个电商订单管理系统

01:39.400 --> 01:41.900
传统数据可能只给他订单创建

01:41.900 --> 01:43.360
这个函数的代码片段

01:43.360 --> 01:45.440
或者库存检查的一段逻辑

01:45.440 --> 01:47.100
但完整开发轨迹

01:47.100 --> 01:48.900
是从老板提需求开始

01:48.900 --> 01:50.680
到程序员分析需求

01:50.680 --> 01:51.920
设计系统架构

01:51.920 --> 01:52.940
画流程图

01:52.940 --> 01:53.720
写代码

01:53.720 --> 01:54.360
测bug

01:54.360 --> 01:55.040
改bug

01:55.040 --> 01:55.980
最后上线

01:55.980 --> 01:58.000
整个过程每一步的对话

01:58.000 --> 01:58.620
思考

01:58.620 --> 01:59.520
代码修改

01:59.520 --> 02:00.360
错误反馈

02:00.360 --> 02:01.420
全都有记录

02:01.420 --> 02:02.560
具体来说

02:02.560 --> 02:04.000
这1001条轨迹

02:04.000 --> 02:06.740
平均每条有181.6轮对话

02:06.740 --> 02:08.220
这不是简单的问答

02:08.220 --> 02:10.560
而是像真实开发团队里的协作

02:10.560 --> 02:11.680
比如第一轮

02:11.680 --> 02:13.380
用户也就是需求方说

02:13.380 --> 02:14.980
我们需要一个订单系统

02:14.980 --> 02:16.800
要支持多种支付方式

02:16.800 --> 02:18.460
还要能实时查库存

02:18.460 --> 02:20.020
模型作为开发者

02:20.020 --> 02:21.360
不会直接写代码

02:21.360 --> 02:22.380
而是先问细节

02:22.380 --> 02:24.660
支付方式需要支持支付宝

02:24.660 --> 02:25.980
微信还是银行卡

02:25.980 --> 02:28.340
实时查库存是扣库存钱查

02:28.340 --> 02:29.560
还是扣库存实查

02:29.560 --> 02:30.720
订单取消后

02:30.720 --> 02:31.800
库存要不要回退

02:31.800 --> 02:33.020
用户回答后

02:33.020 --> 02:34.600
模型会接着设计架构

02:34.600 --> 02:36.280
我们可以分订单服务

02:36.280 --> 02:37.160
支付服务

02:37.160 --> 02:38.600
库存服务三个模块

02:38.600 --> 02:40.160
用消息对列结偶

02:40.160 --> 02:41.520
然后写代码的时候

02:41.520 --> 02:43.820
模型会写订单表的创建语句

02:43.820 --> 02:44.960
写接口定义

02:44.960 --> 02:46.000
写业务逻辑

02:46.000 --> 02:47.180
写完跑测试

02:47.180 --> 02:48.800
比如发现高并发时

02:48.800 --> 02:49.820
库存扣减不对

02:49.820 --> 02:52.300
模型会根据错误日志分析原因

02:52.300 --> 02:54.000
应该是没加分布是锁

02:54.000 --> 02:55.140
导致两个请求

02:55.140 --> 02:56.600
同时读到库存为一

02:56.600 --> 02:57.440
都扣了

02:57.440 --> 02:58.540
然后修改代码

02:58.540 --> 02:59.160
加锁

02:59.160 --> 02:59.980
再测试

02:59.980 --> 03:00.920
直到通过

03:00.920 --> 03:01.460
你看

03:01.460 --> 03:03.660
这181.6轮对话里

03:03.660 --> 03:05.720
每一轮都包含三类信息

03:05.720 --> 03:06.540
上下文

03:06.540 --> 03:07.920
之前的需求讨论

03:07.920 --> 03:08.860
架构设计

03:08.860 --> 03:09.560
动作

03:09.560 --> 03:10.580
写了什么代码

03:10.580 --> 03:11.360
改了哪里

03:11.360 --> 03:11.980
反馈

03:11.980 --> 03:13.220
测试报了什么错

03:13.220 --> 03:14.580
用户提了什么意见

03:14.580 --> 03:15.900
模型训练的时候

03:15.900 --> 03:18.280
就是学习这三者之间的因果链

03:18.280 --> 03:19.420
根据上下文

03:19.420 --> 03:20.600
应该做什么动作

03:20.600 --> 03:22.580
做了动作会得到什么反馈

03:22.580 --> 03:24.540
得到反馈后该怎么调整

03:24.540 --> 03:26.420
这比单纯学代码片段

03:26.420 --> 03:27.120
长什么样

03:27.120 --> 03:28.080
高明太多了

03:28.080 --> 03:29.120
他学到的是

03:29.120 --> 03:31.060
开发代码的全流程逻辑

03:31.060 --> 03:32.520
也就是工程思维

03:32.520 --> 03:34.740
那这些轨迹数据是怎么来的

03:34.740 --> 03:36.640
研究团队从开源项目的

03:36.640 --> 03:38.440
完整开发历史里挖出来的

03:38.440 --> 03:40.600
比如Github上一些知名项目的

03:40.600 --> 03:41.580
issue讨论区

03:41.580 --> 03:43.300
PolRequest的修改记录

03:43.300 --> 03:44.660
代码评审的评论

03:44.660 --> 03:47.000
甚至是开发者之间的聊天记录

03:47.000 --> 03:48.000
当然脱敏了

03:48.000 --> 03:50.060
他们把这些非结构化的数据

03:50.060 --> 03:51.760
整理成结构化的对话

03:51.760 --> 03:52.360
代码

03:52.360 --> 03:53.160
反馈链

03:53.160 --> 03:55.380
每条轨迹都像一部开发日志

03:55.380 --> 03:56.620
记录了一个功能

03:56.620 --> 03:58.100
从无到有的全过程

03:58.100 --> 03:59.240
比如某个轨迹

03:59.240 --> 04:00.300
可能是开发一个

04:00.300 --> 04:01.880
用户登陆健全功能

04:01.880 --> 04:03.120
从最开始讨论

04:03.120 --> 04:04.900
用JWT还是Session

04:04.900 --> 04:06.820
到设计Token刷新机制

04:06.820 --> 04:08.480
到写登陆接口代码

04:08.480 --> 04:09.580
到测试发现

04:09.580 --> 04:11.120
Token过期时间太短

04:11.120 --> 04:12.740
再到调整过期时间

04:12.740 --> 04:13.980
加刷新接口

04:13.980 --> 04:14.860
最后上线

04:14.860 --> 04:15.860
这些细节

04:15.860 --> 04:17.240
传统代码数据里

04:17.240 --> 04:18.240
根本不会保留

04:18.240 --> 04:19.860
接下来是训练策略

04:19.860 --> 04:21.100
研究团队用了

04:21.100 --> 04:22.200
英国语言建模

04:22.200 --> 04:24.180
但不是普通的英国建模

04:24.180 --> 04:25.300
普通建模是

04:25.300 --> 04:26.940
把一段文本拆成Token

04:26.940 --> 04:28.900
让模型预测下一个Token

04:28.900 --> 04:30.680
而MindForge 27B

04:30.680 --> 04:32.160
把轨迹拆成片段

04:32.160 --> 04:33.040
每个片段

04:33.040 --> 04:34.420
可能是用户需求

04:34.420 --> 04:35.380
模型回复

04:35.380 --> 04:36.140
代码快

04:36.140 --> 04:37.000
错误日志

04:37.000 --> 04:39.780
然后让模型学习在什么上下文下

04:39.780 --> 04:41.600
该生成什么类型的片段

04:41.600 --> 04:44.220
比如前面是用户提了一个bug反馈

04:44.220 --> 04:47.560
模型就该预测错误分析和代码修改片段

04:47.560 --> 04:49.700
而不是直接生成代码片段

04:49.700 --> 04:53.500
这种结构化预测让模型更理解开发流程的节奏

04:53.500 --> 04:54.820
还有一个关键点

04:54.820 --> 04:57.140
模型在训练时会模拟错误

04:57.140 --> 04:58.260
传统训练里

04:58.260 --> 05:00.120
代码数据大多是正确的

05:00.120 --> 05:01.980
比如开源项目的最终代码

05:01.980 --> 05:04.760
模型很少看到错误代码和修复过程

05:04.760 --> 05:07.080
但MindForge 27B的轨迹里

05:07.080 --> 05:09.640
包含大量错误修复的循环

05:09.640 --> 05:11.260
比如模型写了一段代码

05:11.260 --> 05:12.940
测试爆空指针异常

05:12.940 --> 05:15.620
然后模型会分析哪个变量可能为空

05:15.620 --> 05:17.220
修改代码加判空

05:17.220 --> 05:18.080
再测试

05:18.080 --> 05:19.740
可能又爆类型不匹配

05:19.740 --> 05:20.700
再调整

05:20.700 --> 05:21.780
这种试错过程

05:21.780 --> 05:23.660
让模型学会了如何调试

05:23.660 --> 05:25.460
这不是靠记住常见bug

05:25.460 --> 05:27.720
而是掌握了排查问题的思路

05:27.720 --> 05:29.160
就像一个老程序员

05:29.160 --> 05:31.180
不是背会了所有bug的解法

05:31.180 --> 05:33.340
而是掌握了排查问题的思路

05:33.340 --> 05:34.780
那效果为啥这么好

05:34.780 --> 05:36.240
咱们再看实验细节

05:36.240 --> 05:39.340
ProgramBench是一个很严格的编程测试集

05:39.340 --> 05:41.520
里面全是真实的工程任务

05:41.520 --> 05:44.060
比如实现一个分布式缓存系统

05:44.060 --> 05:45.820
优化一个数据库查询

05:45.820 --> 05:47.500
写一个微服务的网关

05:47.500 --> 05:49.760
而不是简单的写个排序算法

05:49.760 --> 05:51.300
它的PASATD指标

05:51.300 --> 05:53.560
就是模型第一次生成的代码

05:53.560 --> 05:55.920
直接通过所有测试用力的比例

05:55.920 --> 05:57.800
这个指标比PASAT10

05:57.800 --> 05:59.920
尝试十次通过更靠谱

05:59.920 --> 06:01.240
因为实际开发中

06:01.240 --> 06:03.380
你不可能让模型试十次

06:03.380 --> 06:05.300
要的是第一次就尽量对

06:05.300 --> 06:09.380
Mindforge 27B的PASAT1是49.51%

06:09.380 --> 06:11.320
意味着它几乎一半的任务

06:11.320 --> 06:13.520
第一次生成的代码就能跑通

06:13.520 --> 06:16.920
而Deepseek V4 Pro用了海量代码数据训练

06:16.920 --> 06:17.940
参数更大

06:17.940 --> 06:20.800
但PASAT1只有47.80%

06:20.800 --> 06:23.760
Claude Opus 4.7虽然是顶尖模型

06:23.760 --> 06:26.280
但也只比它高1.87个百分点

06:26.280 --> 06:27.040
这说明啥

06:27.040 --> 06:30.180
说明在编程这种强工程属性的任务里

06:30.180 --> 06:31.380
知道怎么开发

06:31.380 --> 06:33.720
比知道多少代码片段更重要

06:33.720 --> 06:34.760
更有意思的是

06:34.760 --> 06:36.680
研究团队做了个对比实验

06:36.680 --> 06:38.540
用同样的27B模型

06:38.540 --> 06:41.280
一组用1001条完整轨迹训练

06:41.280 --> 06:43.740
另一组用100万条代码片段

06:43.740 --> 06:45.680
相当于传统数据量训练

06:45.680 --> 06:46.320
结果

06:46.320 --> 06:47.680
轨迹训练的模型

06:47.680 --> 06:49.140
在Program Bench上

06:49.140 --> 06:51.420
PASAT1是49.51%

06:51.420 --> 06:53.600
而海量片段训练的模型

06:53.600 --> 06:55.420
只有32.7%

06:55.420 --> 06:57.140
差了快17个百分点

06:57.140 --> 06:58.220
这直接证明

06:58.220 --> 06:59.980
高质量的全流程数据

06:59.980 --> 07:02.280
比海量的局部数据有效得多

07:02.280 --> 07:04.280
那这对中小团队意味着啥

07:04.280 --> 07:05.380
以前大家觉得

07:05.380 --> 07:07.220
要做个能写代码的AI

07:07.220 --> 07:08.500
得有千亿参数

07:08.500 --> 07:10.180
得有几十万块GPU

07:10.180 --> 07:12.040
得收集TB级的数据

07:12.040 --> 07:13.720
中小团队根本玩不起

07:13.720 --> 07:16.020
但Mindforge 27B告诉我们

07:16.020 --> 07:16.460
不用

07:16.460 --> 07:18.160
你只需要花精力整理

07:18.160 --> 07:20.620
几百上千条高质量的开发轨迹

07:20.620 --> 07:22.160
用个小参数模型

07:22.160 --> 07:23.280
比如27B

07:23.280 --> 07:25.220
几张V100卡就能训练

07:25.220 --> 07:27.940
就能做出接近顶尖大模型的效果

07:27.940 --> 07:29.980
这对资源有限的团队来说

07:29.980 --> 07:31.120
简直是福音

07:31.120 --> 07:32.220
不用卷算力

07:32.220 --> 07:33.440
不用卷数据量

07:33.440 --> 07:34.940
卷数据质量就行了

07:34.940 --> 07:36.840
比如一个小团队想做一个

07:36.840 --> 07:38.780
金融代码生成的专业模型

07:38.780 --> 07:41.260
他们不用去爬Github上所有代码

07:41.260 --> 07:43.620
只需要找几个资深金融工程师

07:43.620 --> 07:45.500
记录他们开发风控系统

07:45.500 --> 07:46.920
交易接口的全过程

07:46.920 --> 07:48.500
整理成几百条轨迹

07:48.500 --> 07:50.720
就能训练出一个懂金融业务

07:50.720 --> 07:52.220
懂工程逻辑的模型

07:52.220 --> 07:53.940
这种模型虽然参数小

07:53.940 --> 07:56.020
但比那些啥都懂一点的大模型

07:56.020 --> 07:58.160
在实际金融场景里更靠谱

07:58.160 --> 07:59.240
最后总结一下

07:59.240 --> 08:01.300
Mindforge 27B的成功

08:01.300 --> 08:03.820
其实打破了一个长期存在的迷思

08:03.820 --> 08:05.860
编程能力等于参数规模

08:05.860 --> 08:06.620
它证明

08:06.620 --> 08:08.660
在编程这种需要强逻辑

08:08.660 --> 08:10.300
强工程思维的领域

08:10.300 --> 08:11.360
数据的质量

08:11.360 --> 08:12.580
是不是全流程

08:12.580 --> 08:14.420
是不是包含试错过程

08:14.420 --> 08:16.160
是不是有完整上下文

08:16.160 --> 08:17.560
比数据量更重要

08:17.560 --> 08:18.560
就像教徒弟

08:18.560 --> 08:20.640
你让他看一万行代码片段

08:20.640 --> 08:23.060
不如让他跟着你完整做十个项目

08:23.060 --> 08:25.280
因为前者只能让他记住怎么写

08:25.280 --> 08:27.220
后者能让他学会怎么做

08:27.220 --> 08:27.780
未来

08:27.780 --> 08:30.960
可能会有更多这种小而美的专业模型出现

08:30.960 --> 08:32.640
他们不需要千亿参数

08:32.640 --> 08:35.240
只需要几千条高质量的领域轨迹

08:35.240 --> 08:37.840
就能在特定领域达到顶尖水平

08:37.840 --> 08:40.160
这对AI的普及来说是件好事

08:40.160 --> 08:42.200
毕竟不是每个团队都有谷歌

08:42.200 --> 08:43.480
OpenAI的资源

08:43.480 --> 08:46.580
但每个团队都可能拥有高质量的领域数据

08:46.580 --> 08:49.700
Mindforge 27B算是给我们开了个好投