昨晚我教 nanochat d32 如何計算草莓中的 'r'（或類似變體）。我認為這是一個很好的/有趣的例子，展示如何為 nanochat 增加功能，我在這裡寫了一個完整的指南： 這是通過一個新的合成任務 `SpellingBee` 完成的，該任務生成用戶要求這類問題的示例，以及助手的理想解決方案。我們然後進行中期訓練/SFT 微調，以賦予 LLM 這種能力，或進一步通過 RL 訓練使其更穩健。特別是在較小的模型大小上，有許多細節需要正確處理，指南逐步介紹了這些細節。簡要概述如下： - 你必須確保用戶提示/查詢的多樣性 - 對於像 nanochat 這樣的小模型，特別是，你必須非常小心標記化的細節，以使任務對 LLM 來說變得簡單。特別是，你必須小心空格，然後你必須將推理計算分散到許多部分解的標記中：首先我們將單詞標準化為引號，然後我們拼寫出來（以打破標記），然後我們迭代並保持明確的計數器，等等。 - 我鼓勵模型以兩種不同的方式解決問題：一種是手動方式（心算），另一種是通過 nanochat 可以訪問的 Python 解釋器的工具使用。這有點像 "煙霧和鏡子"，因為目前每個解決方案都是 "乾淨" 的，沒有錯誤。可以調整任務以模擬錯誤並通過示例演示恢復，或者運行 RL。最有可能的是，兩者的組合效果最佳，前者作為 RL 的先驗，並提供可供其使用的內容。 如果 nanochat 是一個更大的模型，你會期望或希望這種能力在某個時候更容易 "顯現" 出來。但因為 nanochat d32 的 "大腦" 大小約為 ~蜜蜂，如果我們想讓它計算草莓中的 r，我們必須通過在數據中過度表示它來實現，以鼓勵模型更早地學習它。但這是有效的！:)

我相當喜歡新的 DeepSeek-OCR 論文。這是一個不錯的 OCR 模型（可能比 dots 差一些），是的，數據收集等等，但無論如何這都不重要。 對我來說，更有趣的部分（尤其是作為一名電腦視覺專家，暫時偽裝成自然語言專家）是像素是否比文本更適合作為 LLM 的輸入。文本標記是否浪費且糟糕，作為輸入。 也許更合理的是，所有 LLM 的輸入應該永遠只有圖像。即使你碰巧有純文本輸入，也許你會更喜歡將其渲染後再輸入： - 更多的信息壓縮（見論文）=> 更短的上下文窗口，更高的效率 - 顯著更多的一般信息流 => 不僅僅是文本，例如粗體文本、彩色文本、任意圖像。 - 輸入現在可以輕鬆地以雙向注意力處理，並作為默認，而不是自回歸注意力 - 強大得多。 - 刪除標記器（在輸入時）！！我已經抱怨過我有多不喜歡標記器。標記器很醜，分開，並不是端到端的階段。它 "導入" 了所有 Unicode、字節編碼的醜陋，繼承了很多歷史包袱，安全/越獄風險（例如，續字節）。它使兩個在眼睛上看起來相同的字符在網絡內部看起來像兩個完全不同的標記。一個微笑的表情符號看起來像一個奇怪的標記，而不是一個... 實際的微笑臉，像素和所有的轉移學習都隨之而來。標記器必須去。 OCR 只是許多有用的視覺 -> 文本任務之一。而文本 -> 文本任務可以被轉化為視覺 -> 文本任務。反之則不然。 所以用戶消息可能是圖像，但解碼器（助手的回應）仍然是文本。如何現實地輸出像素就不那麼明顯了... 或者你是否想這樣做。 現在我還得抵抗想要側重於僅圖像輸入版本的 nanochat 的衝動...

很棒的短文，說明了簡單的文本（離散）擴散是多麼簡單。 擴散（即平行、迭代去噪、頂部）是圖像/視頻中普遍的生成範式，但自回歸（即從左到右底部）是文本中的主導範式。對於音頻，我看到兩者都有一些。 許多擴散論文看起來有點密集，但如果你去掉數學形式主義，你會得到簡單的基線算法，例如更接近於連續中的流匹配，或在離散中像這樣的東西。這是你的香草變壓器，但具有雙向注意力，你會根據噪聲計劃迭代地重新取樣和重新遮罩你在 "tokens canvas" 中的所有標記，直到在最後一步獲得最終樣本。（雙向注意力更強大，如果你用它訓練，你會得到更強的自回歸語言模型，不幸的是，這使得訓練變得更加昂貴，因為現在你無法在序列維度上進行並行化）。 因此，自回歸是在標記畫布上進行 `.append(token)`，而僅僅向後注意，而擴散則是用 `.setitem(idx, token)` 刷新整個標記畫布，同時進行雙向注意。人類思維天真地感覺更像是自回歸，但很難說在某些潛在的思維空間中沒有更多類似擴散的組件。感覺很有可能你可以進一步在它們之間插值，或進一步概括它們。而且這是 LLM 堆棧中的一個組件，仍然感覺有點可替代。 現在我必須抵制將 nanochat 與擴散訓練的衝動。