最離譜的是：我沒有任何機器學習背景，不知道模型訓練的標準流程，也不清楚許多技術細節。我所做的事，基本上只是不斷向 Sol 提出要求、回饋結果，讓它自己尋找問題、設計實驗並持續迭代。文章作者：Anshu
文章編譯、來源：ME News
這是我在第一次真正產生「AGI 似乎已經來了」的感覺。
我用 GPT-5.6 Sol 訓練了一個屬於自己的自動糾錯模型。最終，這個僅有 17 億參數的本地模型，在測試集上的表現竟然略微超過了 GPT-5.6 Sol。
最離譜的是：我沒有任何機器學習背景，不知道模型訓練的標準流程，也不清楚許多技術細節。我所做的事，基本上只是不斷向 Sol 提出要求、回饋結果，讓它自己尋找問題、設計實驗並持續迭代。
The entire process costs zero.
一切源於一個越來越嚴重的「打字問題」
長期與 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 還可以針對編碼器繼續進行後訓練，讓模型更好地識別含有拼寫錯誤的輸入。
This route significantly raises the model's performance ceiling.
第二個瓶頸：傳統損失函數在鼓勵模型「不要修改」
更換模型架構後，一個新的問題出現了。
模型已經能夠準確修正部分錯誤，但經常會忽略其他明顯的拼寫問題。即使輸入中存在錯誤，它也傾向於原樣複製。
Sol 最終發現，問題來自最常見的交叉熵損失函數。
在自動糾錯數據中，大部分字符原本就是正確的，真正需要修改的字符只佔很小比例。如果直接使用標準交叉熵進行訓練，模型最安全的策略就是「盡量不要改」。
因為複製原文可以在絕大多數位置獲得正確答案，而主動修改反而可能帶來錯誤。
換句話說，傳統的訓練目標正在獎勵模型保持不變。
為了解決這個問題，Sol 編寫了一套自定義損失函數。
它首先在字節層級對齊原始文本與目標文本，再通過動態規劃算法計算兩段文本之間的最小編輯路徑，識別哪些位置屬於複製，哪些位置屬於真正的插入、刪除或替換。
On this basis, Sol has significantly increased the training weight for "correct modifications" while reducing the rewards from simply copying characters.
經過多輪參數調整後，模型的糾錯準確率出現了顯著提升。
第三個瓶頸：模型一旦走錯，就無法回頭
最後一個主要問題來自自回歸生成機制。
模型在生成文本時，只能根據已經生成的內容繼續預測下一個 Token。一旦前面某一步出現錯誤，後續生成就會建立在錯誤結果之上，模型無法真正回頭修改。
理論上，可以訓練模型像推理模型一樣先「思考」再作答，但這會大幅增加延遲，並不適合需要即時響應的自動糾錯場景。
Sol 最終找到了一種更優雅的方案：Beam Search，也就是束搜索。
模型不再僅在每一步選擇概率最高的單一路徑，而是同時保留多條可能的生成分支，並行探索不同的糾錯結果。搜索結束後，再選擇累計對數概率最高的完整路徑。
This is equivalent to replacing single-threaded inference with parallel search.
Beam Search 明顯改善了最終效果，但也引入了一個體驗問題：在整個搜索完成前，用戶看不到任何輸出。
Sol 隨後做出了一個非常聰明的觀察。
在每一轮搜索後，可以比較當前保留下來的所有分支。只要這些分支擁有相同的開頭，那麼這段「最長公共前綴」就必然會出現在最終結果中。
因此，系統可以立即將這段內容顯示給用戶。
隨著搜索不斷進行，較弱的路徑被逐漸淘汰，剩餘分支的公共前綴也會越來越長。最終，用戶看到的不是一次性突然出現的結果，而是持續向前生成的糾錯文本。
Sol 將整個流程打造為一條自訂的 MLX 推理管線，並利用 MacBook GPU 進行平行解碼。
Ultimately, the output latency for the first token is only about 40 ms, fast enough, and the entire process is completed locally.
最終結果：17 億參數模型超過 GPT-5.6 Sol
The final evaluation uses "error reduction rate" as the metric; the higher the value, the more input errors the model has corrected.
評測結果如下：
- 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 能夠幫助普通人跨越專業門檻時，很多過去看起來遙不可及的技術項目，可能已經不再遙遠。