最离谱的是：我没有任何机器学习背景，不知道模型训练的标准流程，也不清楚很多技术细节。我做的事情，基本只是不断给 Sol 提要求、反馈结果，让它自己寻找问题、设计实验并持续迭代。
文章作者：Anshu
文章编译、来源：ME News
这是我第一次真正产生“AGI 好像已经来了”的感觉。
我用 GPT-5.6 Sol 训练了一个属于自己的自动纠错模型。最终，这个仅有 17 亿参数的本地模型，在测试集上的表现竟然略微超过了 GPT-5.6 Sol。
最离谱的是：我没有任何机器学习背景，不知道模型训练的标准流程，也不清楚很多技术细节。我做的事情，基本只是不断给 Sol 提要求、反馈结果，让它自己寻找问题、设计实验并持续迭代。
整个过程花费为零。
一切源于一个越来越严重的“打字问题”
长期与 AI 对话后，我发现自己的打字能力变得越来越差。
我已经习惯快速输入，不再认真检查拼写、字母顺序或漏字问题。与其重新训练自己的打字能力，我决定采用一个更符合 AI 时代的解决方案：继续用更多 AI 来解决问题。
传统自动纠错会在输入过程中不断修改文字，反而容易打断思路。我的设想是，让用户不受干扰地快速输入，哪怕其中充满错误，等输入完成后，再由 AI 统一清理。
同时，我希望这个模型尽可能小。
模型越小，运行速度越快，功耗越低，也越适合完全在本地运行。无论是为了效率、电池续航，还是单纯出于实验兴趣，我都想看看：一个足够小的本地模型，究竟能把自动纠错做到什么程度。
于是，我决定自己训练一个。
让 Sol 成为一名自动做实验的研究员
这个项目的灵感来自 Andrej Karpathy 的“autoresearch”实验。
我通过 Codex 的 /goal 模式，为 Sol 设计了一套循环工作流：
选择一个实验，执行实验，把结果记录到文档中；如果失败，就放弃这条路线；然后规划下一个实验，同时避免重复已经验证过的错误。
我只提供了几组必须通过的输入样例、严格的延迟目标，以及最终希望达到的效果，之后便让 Sol 自己运行。
接下来发生的事情超出了我的预期。
Sol 首先检索并比较了多个候选基础模型，包括 Qwen 3.5、Gemma 4 和 Liquid LFM 2.5。随后，它又在 Hugging Face 上找到了一套与真实打字文本相关的数据集。
但真实数据还不够。
为了生成更接近用户实际输入的拼写错误，Sol 编写了一个“手指敲击 Mac 键盘”的模拟器。它根据键盘的物理布局，用高斯分布模拟手指落点，并生成多种常见错误，例如：
- 按到相邻按键；
- 字母顺序颠倒；
- 重复输入；
- 漏掉字符；
- 手指同时碰到多个按键。
有了基础模型、文本数据和键盘错误模拟器后，Sol 直接在我的 MacBook 上使用 MLX 进行微调。
不到一个小时，它就做出了可以运行的原型。
问题是，第一版的准确率并不理想。
第一个瓶颈：Tokenizer 看不懂拼写错误
Sol 阅读了相关论文，并设计了一系列测试，最终判断：模型的主要瓶颈不在训练数据，而在 Tokenizer，也就是分词器。
大语言模型通常不会逐字母理解文本，而是先把文本切分成 Token。正常单词可以被分解成稳定的语义单元，但拼写错误往往会破坏原有的 Token 结构。
这意味着，对人类来说非常明显的一个字母错误，在模型眼中可能变成一组完全陌生的 Token。
模型很难真正“理解”错误，只能机械地记忆错误拼写与正确拼写之间的映射关系。这样做不仅泛化能力差，也无法充分利用模型原有的语言知识。
Sol 首先尝试了 Google 的 ByT5。
ByT5 是一种不依赖传统 Tokenizer、直接处理字节序列的模型。这次尝试带来了明显提升，但 ByT5 发布时间较早，模型本身掌握的语言知识有限，最终性能仍然无法达到 GPT-5.6 Sol 的水平。
继续研究后，Sol 意识到，问题并不一定需要通过“完全取消 Tokenizer”来解决。
它转而选择了 T5Gemma，一种 Encoder-Decoder 架构的模型。
与单纯预测下一个 Token 的模型不同，Encoder-Decoder 模型可以先通过编码器完整理解输入，再由解码器生成修正后的文本。更重要的是，Sol 还可以针对编码器继续进行后训练，让模型更好地识别含有拼写错误的输入。
这条路线显著抬高了模型的性能上限。
第二个瓶颈：传统损失函数在鼓励模型“不要修改”
更换模型架构后，一个新的问题出现了。
模型已经能够准确修正部分错误，但经常会忽略其他明显的拼写问题。即使输入中存在错误，它也倾向于原样复制。
Sol 最终发现，问题来自最常见的交叉熵损失函数。
在自动纠错数据中，大部分字符本来就是正确的，真正需要修改的字符只占很小比例。如果直接使用标准交叉熵进行训练，模型最安全的策略就是“尽量不要改”。
因为复制原文可以在绝大多数位置获得正确答案，而主动修改反而可能带来错误。
换句话说，传统训练目标正在奖励模型保持不变。
为了解决这个问题，Sol 编写了一套自定义损失函数。
它首先在字节级别对齐原始文本与目标文本，再通过动态规划算法计算两段文本之间的最小编辑路径，识别哪些位置属于复制，哪些位置属于真正的插入、删除或替换。
在此基础上，Sol大幅提高了“正确修改”所对应的训练权重，同时降低单纯复制字符带来的收益。
经过多轮参数调整后，模型的纠错准确率出现了显著提升。
第三个瓶颈：模型一旦走错，就无法回头
最后一个主要问题来自自回归生成机制。
模型在生成文本时，只能根据已经生成的内容继续预测下一个 Token。一旦前面某一步出现错误，后续生成就会建立在错误结果之上，模型无法真正回头修改。
理论上，可以训练模型像推理模型一样先“思考”再作答，但这会大幅增加延迟，并不适合需要即时响应的自动纠错场景。
Sol 最终找到了一种更优雅的方案：Beam Search，也就是束搜索。
模型不再每一步只选择概率最高的单一路径，而是同时保留多条可能的生成分支，并行探索不同纠错结果。搜索结束后，再选择累计对数概率最高的完整路径。
这相当于用并行搜索替代了单线推理。
Beam Search 明显改善了最终效果，但也引入了一个体验问题：在整个搜索完成前，用户看不到任何输出。
Sol 随后做出了一个非常聪明的观察。
在每一轮搜索后，可以比较当前保留下来的所有分支。只要这些分支拥有相同的开头，那么这段“最长公共前缀”就必然会出现在最终结果中。
因此，系统可以立即把这段内容显示给用户。
随着搜索不断进行，较弱的路径被逐渐淘汰，剩余分支的公共前缀也会越来越长。最终，用户看到的不是一次性突然出现的结果，而是持续向前生成的纠错文本。
Sol 将整套流程做成了一条定制 MLX 推理管线，利用 MacBook GPU 进行并行解码。
最终，首个 Token 的输出延迟只有约 40 毫秒，速度足够快，而且整个过程完全在本地完成。
最终结果：17 亿参数模型超过 GPT-5.6 Sol
最终评测采用“错误减少率”作为指标，数值越高，代表模型修复的输入错误越多。
评测结果如下：
- Apple 自动纠错：49.66%
- GPT-5.6 Luna：82.47%
- GPT-5.6 Terra：87.64%
- GPT-5.6 Sol：90.56%
- 我们训练的 17 亿参数模型：91.02%
这个本地小模型，最终以非常微弱的优势超过了 GPT-5.6 Sol。
我也专门检查了是否存在数据泄漏或模型“作弊”的情况。测试时，我们会主动排除训练数据中出现过的单词，从而验证模型并不是在机械记忆错误与答案之间的映射关系。
整个项目的最终成本是：
一次模型额度重置，以及 0 美元现金支出。
真正让我震撼的，不只是最终分数
项目过程中，还有大量没有展开的实验，包括对比学习、GRPO、DPO、动态遮蔽等不同方向。
并不是所有尝试都成功了，但 Sol 能够主动阅读资料、定位问题、提出假设、设计实验、分析结果，再根据失败经验规划下一轮尝试。
对我而言，真正震撼的并不是“一个 17 亿参数模型超过了 GPT-5.6 Sol”这件事本身。
更重要的是，一个完全没有机器学习背景的人，已经可以借助 AI，完成过去需要专业研究团队才能推进的实验流程。
我并没有掌握所有底层知识，也没有提前设计出完整的技术路线。我只是明确自己想解决什么问题，然后不断推动 Sol 继续寻找答案。
它不仅写代码，还在承担研究员、工程师和实验设计者的角色。
这可能就是我第一次真正“感受到 AGI”的时刻。
不要让缺乏经验阻止你开始实验。
当 AI 能够帮助普通人跨越专业门槛时，很多过去看起来遥不可及的技术项目，可能已经不再遥远。