昨夜、私はnanochat d32にイチゴ(または同様のバリエーション)の「r」を数える方法を教えました。これはnanochatに機能を追加する方法の良い/楽しい例になると思い、ここに完全なガイドを書きました。 これは、この種の問題を求めるユーザーの例と、アシスタントからの理想的な解決策を生成する新しい合成タスク「SpellingBee」を介して行われます。次に、これらをミッドトレイン/SFT で微調整して LLM に機能を与えるか、さらに RL でトレーニングしてより堅牢にします。特にモデルサイズが小さい場合、正しく理解すべき詳細はたくさんあり、ガイドはそれらを順を追って説明します。簡単な概要として: - ユーザーのプロンプト/クエリの多様性を確保する必要があります - 特に nanochat のような小規模なモデルの場合、LLM のタスクを簡単にするために、トークン化の詳細に細心の注意を払う必要があります。特に、空白に注意する必要があり、推論計算を部分解の多くのトークンに分散させる必要があります:最初に単語を引用符で標準化し、次に(トークンを分割するために)スペルアウトし、次に反復して明示的なカウンターを保持します。 - 私はモデルに、手動の方法(頭の中の暗算)と、nanochatがアクセスできるPythonインタープリターのツールの使用の2つの別々の方法でモデルを解くことを奨励しています。これは少し「煙と鏡」です、なぜなら、すべてのソリューションATMは間違いなく「きれい」だからです。タスクを調整して間違いをシミュレートし、例で回復を示すか、RL を実行することができます。ほとんどの場合、両方の組み合わせが最も効果的であり、前者が RL の事前として機能し、RL に作業できるものを与えます。 nanochatがはるかに大きなモデルだったら、この機能がある時点でより簡単に「飛び出す」ことを期待したり、期待したりするでしょう。しかし、nanochat d32の「脳」は~ミツバチほどの大きさであるため、イチゴのrを数えたい場合は、モデルがそれをより早く学習するように促すために、データでそれを過剰に表現してそれを行う必要があります。しかし、それはうまくいきます!:)

私は新しいDeepSeek-OCR論文がとても気に入っています。これは優れたOCRモデルであり(ドットよりも少し悪いかもしれません)、データ収集などもありますが、とにかくそれは問題ではありません。 私にとってより興味深い部分(特に、一時的に自然言語の人になりすます、根っからのコンピュータービジョンとして)は、ピクセルがテキストよりもLLMへのより良い入力であるかどうかです。テキストトークンが無駄でひどいものであるかどうかは、入力で。 LLM へのすべての入力は画像のみであるべきであるという方が理にかなっているかもしれません。たまたま純粋なテキスト入力がある場合でも、それをレンダリングしてからフィードしたいと思うかもしれません。 - より多くの情報圧縮 (論文を参照) = > コンテキストウィンドウが短くなり、効率が向上します - より一般的な情報ストリーム=>テキストだけでなく、太字のテキスト、色付きのテキスト、任意の画像など。 - 入力は、自己回帰アテンションではなく、デフォルトで双方向のアテンションで簡単に処理できるようになりました。 - トークナイザーを削除(入力時)!!私はすでにトークナイザーがどれほど嫌いかについて暴言を吐いていました。トークナイザーは醜く、別個であり、エンドツーエンドの段階ではありません。Unicode、バイトエンコーディングのすべての醜さを「インポート」し、多くの歴史的荷物、セキュリティ/脱獄リスク(継続バイトなど)を継承します。目と同じように見える 2 つのキャラクターを、ネットワーク内部では 2 つのまったく異なるトークンとして見せます。笑顔の絵文字は奇妙なトークンのように見えますが、...実際の笑顔、ピクセルなど、そしてそれに伴う転移学習のすべて。トークナイザーは行かなければなりません。 OCRは、多くの便利なビジョン>テキストタスクの1つにすぎません。また、テキスト > テキスト タスクは、ビジョン >テキスト タスクにすることができます。その逆はできません。 ユーザーメッセージの多くは画像ですが、デコーダー(アシスタントの応答)はテキストのままです。ピクセルをリアルに出力する方法は、あまり明らかではありません...または、必要に応じて。 今、私はまた、画像入力のみのバージョンのnanochatをサイドクエストしたいという衝動と戦わなければなりません...

テキスト(離散)拡散がいかに単純であるかを示す、素敵で短い投稿です。 拡散(つまり、並列、反復ノイズ除去、上)は、画像/ビデオに広く普及している生成パラダイムですが、自己回帰(つまり、左から右下に移動)は、テキストの支配的なパラダイムです。オーディオについては、両方を少し見てきました。 多くの拡散論文は少し密度が高いように見えますが、数学的形式主義を取り除くと、単純なベースラインアルゴリズム、たとえば連続的なフローマッチングにはるかに近いもの、または離散的なフローマッチングにはるかに近いものになります。これはバニラのトランスフォーマーですが、双方向の注意があり、最後のステップで最終サンプルを取得するまで、ノイズ スケジュールに基づいて「トークン キャンバス」内のすべてのトークンを繰り返し再サンプリングおよび再マスクします。(双方向の注意ははるかに強力であり、それを使用してトレーニングすると、はるかに強力な自己回帰言語モデルが得られますが、残念ながら、シーケンスの暗い間で並列化できないため、トレーニングのコストが大幅に高くなります)。 したがって、自己回帰は、トークンキャンバスに「.append(token)」を実行し、逆方向にのみ参加しますが、拡散は、双方向に参加しながら「.setitem(idx, token)」を使用してトークンキャンバス全体を更新します。人間の思考は素朴に自己回帰のように感じられますが、思考の潜在的な空間に拡散のような要素がこれ以上ないとは言い難いです。それらの間をさらに補間したり、さらに一般化したりできる可能性は十分にあると感じます。そして、これは LLM スタックのコンポーネントであり、まだ少し代替可能であると感じられます。 今、私はディフュージョンでナノチャットをトレーニングするためのサイドクエストへの衝動を抑えなければなりません。