Gemini Diffusion！

LLMの助けが欲しいような実際のプロジェクトって、数千行じゃなくて数百万行のコードから始まるんだよ。1k行くらいのコードなら、LLMなんていらないし、インターン1人の頭の中に全部収まっちゃうじゃん。

今どきの会議って、ほとんどがノイズだと思うんだよね。「これが結果だ！」っていう明確な”シグナル”がない。これこそAIがフィルターできるべきことだと思うな。もちろん、みんながもっと明確に、簡潔に話せたら一番良いんだけどね。

”各段階で、次のイテレーションの正しい方向性を判断するための十分なフィードバックを得る”って、プロジェクトによると思うな。急な変更にはシンプルな解決策の方がうまく妥協できる。シンプルが簡単なんて絶対言わないよ。むしろ逆で、複雑にするのは簡単。デザインパターンもKISSも知ってたけど、賢さばかり重視してたんだ。結論は：シンプルで直接的な解決策を優先すべき。clever にやろうとするのは clever じゃない。初めて読む人が理解できないコード一行より、3行の方がいいし、設計でも同じだよ。

それは誤った例えで釣ろうとしてるだけだね。もし君のリポジトリマップが1000トークンに収まるなら、それは十分小さいリポジトリだから、ファイルを全部連結してLLMにプロンプトとして一気に食わせられるよ。いや、現在のLLM技術は実際の（つまり大きな）リポジトリを処理することはできないんだ。

ちょっとやってみるね。ソフトウェアにおけるネガティブスペースの比喩は、抽象化の形であり、適切なものを簡単に、かつレールに乗せるようにしつつ、過剰な設計にならないスイートスポットを見つけることだと思うんだ。
視覚芸術では、ネガティブスペースはレイアウトの一部で、視覚的な流れを作る。それは物事そのものと同じくらい、物事間の関係性を定義するのを助けるし、適切に使えば、優雅さと雑然さの違いになるんだ。
「ライブラリを選ばない」っていうのは重要な情報だけど、ネガティブスペースと同じものじゃなくて、むしろ制限とかフレーミングに近いかな。見せないもので多くのことができるけど、この分野では良いアートと良いソフトウェアは目標が違うと思うんだ。僕にとって良いアートは考えさせたり、感じさせたり、推測させたりするけど、良いソフトウェアはそれ以外のことをできるだけ少なくして理解させてくれる。
例外としては、非常に良いけど明らかじゃない理由で物を選ばない場合かな。これは大声で文書化すべきだね。ライセンスとか他の外部要因とか、特定のハードウェア要件とかかな。例えば、以前、それが役立つ可能性があった製品でGraphQL APIの作成を禁止したことがあるんだ。なぜなら、既存のAPIをサードパーティのために永遠にサポートする必要があったから、APIを置き換える提案は、実は密かに2つのAPIを同期させて維持するという提案だったんだよ。

これにめちゃくちゃ驚いてる人いる？ IOで一番大きな発表だと思うんだけど、Veo 3とかに影が薄くなっちゃってるよね。
コード生成のためのDiffusionモデルはすごい大事だよ。もしTransformerを使ってるなら、これはおそらくDiTの仲間に入るだろうね。数年前にU-Net diffusionを活用したユースケースに取り組んだことがあって、ハイブリッドモデルにはかなりの関心があったんだ。近い将来、Diffusion分野でさらなる飛躍があると期待してるよ。

ここでの直感を誰か手伝ってくれない？ 画像Transformerからの僕の理解では、ノイズから始めて、一連の階層モデルを使ってノイズを目標に反復的に洗練していくんだよね。各層はより高い解像度で画像を生成するように訓練されていて、それらを重ねることで「ノイズ」から「顔っぽく見えるノイズ」になるまでの始めの疎な勾配の問題をスキップする。
これがコーディングでどう機能するの？ 生成される成果物を階層的に構造化できる必要があるってことだよね。多分これもうまくいくかもね。「この問題にはDjangoを使う」みたいな粒度の低いコンセプトから始めて、次に「これらのエンドポイントが必要だ」そして「コードを出力する」。でもAIUI Diffusionにはバックトラッキングの仕組みがないから、低レベルの問題に対応してデザインの側面を変更する必要が出たときに、詳細レイヤーからの信号を上位抽象化レイヤーにフィードバックできないんだ。
一方、Transformerは各トークンに対してモデル全体を通過するから、必要なら問題の各ステップで全てのスマートさやロジックを展開できるし、重要なデザイン決定のバックトラッキングも含まれる。
僕のメンタルモデルには大きなギャップがあるはずだ、何かインサイトがあれば嬉しいな。

名前とは裏腹に、Diffusion LMは画像のDiffusionとはほとんど関係なくて、BERTや古き良きマスクされた言語モデリングにはるかに近いんだよ。BERTがどう訓練されるか思い出してみて。
1. 文全体を取る（”the cat sat on the mat”）
2. 15%のトークンを[MASK]トークンに置き換える（”the cat [MASK] on [MASK] mat”）
3. Transformerにマスクされた位置のトークンを予測させる。これは単一の推論ステップで並行して行う。
さて、Diffusion LMはこのアイデアをさらに進める。BERTは15%のマスクされたトークン（”ノイズ”）を回復できるけど、ここで止まる必要はない。30%、50%、90%、100%のマスクされたトークンを持つテキストを回復するようにモデルを訓練しよう。
それが訓練できたら、ゼロから何かを生成するために、全ての[MASK]をモデルに入力することから始める。それはほとんど意味不明なものを生成するけど、ランダムな位置からいくつかのトークン（例えば10%）を取って、これらのトークンが生成された（”確定した”）と仮定することができる。次に、別の推論イテレーションを実行する。今度は入力が90%のマスクと10%の”確定した”トークンを持つ。再び、新しいトークンの10%を確定済みとしてマークする。これを続けると、10ステップでシーケンス全体を生成できる。これがDiffusion言語モデルの核となるアイデアだよ。
もちろん、現実世界にはいくつかの最適化がある。本当に長いテキスト（200トークン以上）を生成する必要があるなら、それをチャンクに分割して、最初のチャンクを並行して完全に生成してから次のチャンクに進む方が良い。この半自己回帰生成がBlock Diffusionが行うことだよ。
生成されたと見なすトークンをどのように正確に選び、何パーセントを正確に選ぶかについてスマートになれる。初期段階では、ほとんどがノイズの時、もっと多く取れるし、最終段階ではもっと多くのイテレーションを行い、より少ないトークンを取ることができる。
結局のところ、Diffusion LMは依然として反復的だけど、ステップ数は自己回帰モデルよりもはるかに少ない。良い点は、どれだけのステップを行うかを選択できることで、品質と速度をトレードオフできることだね。
極端な場合、Diffusion LMで一番左のマスクされたトークンだけを生成することさえ可能で、事実上、それを従来の因果言語モデルに変えることができるんだ。

素晴らしい説明だね。テキストDiffusionモデルが推論中に「編集」できるって見たことがあると思うんだ。言い換えれば、「確定」したトークンが必ずしも「確定」じゃなくて、変更される可能性があるけど、後のイテレーションでモデルが本当に確定だと判断するってこと？ それはどうやって機能するの？

僕も君と全く同じ疑問を持ってるよ。画像のDiffusionでさえ理解するのがやっとで、テキストみたいな連続データでは意味がわからないんだ。

その通り、Diffusion LMは中間予測を編集できるから「確定」トークンは必ずしも確定じゃないんだ。これってすごく面白い特性で、GPTみたいなモデルにはできない、生成されたエラーを修正できるってことなんだよ。
この編集は、Transformerのエンコーダーの特性に基づいているんだ。それはシーケンス内の__全ての__トークン、マスクされたトークンだけでなく、それ以外のトークンも含めて、確率を予測するんだ。だから例えば、”[MASK] cat barks”っていう3つのトークンの文を入力すると、Transformerは3つのトークンそれぞれに対して、語彙全体にわたる確率分布を無料で生成してくれる。
さて、トークンを編集したいか、そのままにしたいかをどう決めるかについては、色々な方法を考えられるよ。最も単純なケースでは、新しいトークンの確率が元のトークンよりもある程度高ければ、新しいトークンを採用する。僕たちの例で言うと、モデルが2番目の位置のトークン”cat”の確率をp_2(“cat”) = 0.3、一方p_2(“dog”) = 0.6と返したとする。僕たちは”cat”を”dog”に置き換えて、それを以降のイテレーションで使いたいと思うかもしれない。
実際のヒューリスティクスはもう少し複雑だけど、基本的な考え方はこれだよ。
追記：LMに、入力のマスクされていないトークンをただコピーするだけでなく、より良い代替を見つけようと試みるように教えるためには、訓練目的に入力トークンの一部を他のランダムなトークンで置き換えることを含めるべきだね。これで入力の一部がマスクされ、入力の一部が破損しているので、モデルは全ての入力トークンがそのまま存在すると盲目的に仮定することはできないんだ。

語彙に1万個のトークンがあると仮定しようか。
そうするとテキストは、高さ1万ピクセル、幅Nピクセル（テキストの長さ）の画像になるね。
各列では、ちょうど1つのピクセルが白（そこにある単語に対応）で、残りは黒だよ。
そしたらDiffusionプロセスは同じさ。繰り返しノイズ除去するだけ。

いや、その直感は正しくないよ。
ノイズ除去モデルは、多くの領域が滑らかになるから機能するんだ。そういうことは「離散的なやり方」ではできないんだよ、わかるかな。

でも、プログラム内のシンボル間の依存関係はどうなるの？ それらのシンボルはプログラム設計という高い制約に囲まれているからね。
これは画像のDiffusionでも問題になるんだ。ポートレートを頼んで、詳細が間違っている時とかさ。それは顔には制約があるからだよ（アーティストが学ぶこと）。パターンと確率だけでは助けにならないんだ。

コード生成にDiffusion modelsはマジで重要だよ＞俺もそう思うんだよね。こういうモデルはコーディングの簡単なタスクにいっぱい使えるからさ：
－関数定義と出力で制約して間のトークンを”生成”するワークフローとかできるはず。両方向のトークンを見れるからね。
－あとは、高レベルなレイアウトから始めてリンターとかコンパイルとかAST情報使いながら実装を進める2段階ワークフローも。マジで色々試す価値ありだね。

ノイズ付きコードをきれいにする小さなステップでは独立性を仮定できると思ってるんでしょ？たくさんのステップをつなげると、全ての相互依存性をモデル化できる柔軟な分布ができるんだ。統計の人がもっと詳しいだろうけど、Diffusionはautoregressionを一般化するって見方もあるらしいよ。依存関係のグラフを因数分解するのに順序がいらないからね。

autoregressionとdiffusion、両方できるハイブリッドモデルって可能なのかな？根本的にできないことはなさそうだよね。思考（thought generation）をDiffusion CoTでサクッと作って、答えはautoregressionで出すとか、色々考えられそうだよ。

画像をダウンスケールするみたいに、ピクセル値じゃなくてトークン埋め込みを平均化すればテキストもダウンスケールできるんだ。でも、そうする必要はないよ。AFAIKだけど、vision transformersは疎な勾配で困らないから、ダウンスケールはただのパフォーマンス最適化なんだ。フル解像度で画像を処理するのは大変だからね。

この技術でどうやってスピード出してるのか気になるな。普通、”masked language model”って全単語の候補を毎回転計算するから、もっと遅いと思ってたんだよね。てっきり、最終的には連続空間でdiffusionして、離散トークンにデコードする感じになるのかと。あと、これもGemini Diffusionのやり方の”推測”ってことで合ってる？

面白いね、解説もすごく分かりやすい。でも、挿入とか削除の操作はどうなの？ ”最終”トークンの間に、コードをちゃんと完成させるのにトークンが少なすぎるリスクってないのかな？

embedding空間なら滑らかなのかもね。

＞でも Veo 3とかに霞んじゃってるね。Veo 3のパワーとか能力の違いは簡単に理解できるから。テキスト補完の重要な進歩を理解するには、今あるものの価値とか将来的な影響を知る必要があるんだ。まだ多くの人が、そもそもLLMがコーディングに役立つって信じてないみたいだしね。

ソフトウェアの保証にformal verificationがある理由、各コンポーネントの意味論を知る必要性、トークン一つで意味が変わること、プログラミングは指示に意味論を押し付けること、アルゴリズムは意味論的な制約だって話。LLMとかdiffusionはせいぜい高度な検索だって見れるけど、本当に重要なのは意味論なんだ。紙でも設計できるのはそのため。コードエディタ使うのはフィードバックが良いから。コードを読むのが一番確実だってね。

でも、それって結構難しくない？Aの次にはBしか来ちゃダメ、みたいなルールがあって、5番目のトークンがAに変わっちゃったら、守らなきゃいけない制約がドミノ倒しみたいになるじゃん。

コード版のインペインティングみたいな？

どうだろうね。原則、左右の情報使えるのは有利だと思うけど、LLaDAはサイズに対してすごいけどperplexityでは遅れてるし、それは仕方ないと思うな。あと、早く固定されちゃうから、テキストを深く修正できるっていう期待はそこまで信じてないんだ（もちろん、単語1つ2つ間違いとかはある程度直せるだろうけど）。間違った単語は同時にマスクする必要があると思ってるからね。それでも、実験で見た結果には満足してるよ。

＞例えばモデルがトークン「cat」の確率0.3、「dog」の確率0.6を返すとするじゃん？
「cat」を「dog」に置き換えて次で使いたいかも．
スピードと品質のトレードオフとして、logitで分岐させてより良い結果を探す「ツリー探索」って手もある？
diffusion modelがARよりずっと速いなら、探索やバックトラックしても気にならないかも．

俺っち思うんだけど、一番大事なこと見落とされてない？
これってめっちゃすごくて速いInstructGPTだよ．
間違いなくスペルチェック、codemods、コードエディタで使われる．
インスタント編集は余計な機能なしにサッとテキスト編集．
shadertoysのコードで変数名変更頼んだら、ちゃんと動く結果くれた．マジ感動！

いや、そうじゃないよ．単語のスペルは合ってるけど、文法的に正しくても間違った単語を使っちゃう場合とか、スペルチェックは頻繁に間違いを見逃すんだ．

何か例を出してくれる？スペルチェックって単語が辞書にあるかだけチェックするんだろ．文法や文脈はチェックしないじゃん．

「Bob went to Venice to pick up the doge．」
ここでdogeは称号（dukeみたいな）の名前だけど、「dog」ってスペルミスしてるんだ．「Venice」を使ってることから、doge（ヴェネツィア総督）のことを言ってる可能性が高まって、賢いスペルチェックならdogeのままにしてdogに直さないかも．もっと広い文脈を見れば、Bobが子犬の話をしてるって分かるかもね．
もっと簡単な例だと「spell cheque」とか．

一つの辞書の定義によると、スペルミスってのは「単語の、慣習的に受け入れられた綴り方における誤り」だから、一つの単語を別の単語と間違えるのはこの定義には入らないんだよ．
確かに今はスペルチェッカーに文法チェックも期待されてるけど、純粋なスペルチェッカーなら英語の単語リストに頼るだけで大丈夫なんだ（これは形態がもっと発達してたり複合語が多い言語では通用しないけどね）．

うん、まあそれは技術的な細かさだね．スペルチェッカーはゆっくり文法チェッカーに進化したし、みんなが本当に欲しいのはエラー修正なんだよ．
それがスペルチェッカーと呼ばれるかどうかなんて、小さな言語の問題で（人間がしょっちゅうやることだよ）．
辞書のために教える時は、「俺が難癖つけなかったら、彼らが何を言いたいか明らか？」って聞いてみて．

でも、この二つのケースでは違う出力が必要だよね．間違った単語選びは、たぶん別の単語の意図があったんじゃない？っていうヒントが普通ついてくるけど、間違ったスペルは明確に間違いってマークできるんだ．
この二つの動作は別々にオンオフできるし、違う二つのラベルが必要なんだよ．

オッケー。”Dessert”と”desert”の間違いは、文法ミスっていうよりスペルミスだよね。どっちも名詞だけど意味全然違うし、ただスペル間違えてるだけじゃん。

うん、同意。でもさ、「complementary／complimentary」とか「discrete／discreet」みたいに、普通のスペルチェックじゃ引っかからないタイプのスペルミスだよね。

あんたの定義の解釈には同意できないな。「pale」を「pal」って書くのは、「pal」って単語があっても「pale」としては間違いだよ。「His mouth dropped and he turned pal。」って文を人間が見たら、間違いだって指摘するはず。スペルチェックができないのは難しいからで、コンピュータの限界だろ。スペルチェックの定義の問題じゃないよ。

Finnishが何か言いたげだよ。「kauppa」（”shop”）みたいな名詞一つに、少なくとも6000以上の形があるって（https://flammie.github.io/omorfi/genkau3.html）。これ複合語とか含まないんだよ。借用語とかスラング、他の品詞への派生もあって、これを全部網羅した単語リストなんて作るの絶対無理。同じUralic languagesの仲間も極端に活用するけど、言語モデルの学習や単語リスト集めに使えるオンラインリソースがほぼないんだ。

Finnishは他のほとんどの言語とは全然違うし、訓練データが少ないのは事実だけど、あのウェブページはおかしいし、実際の言葉を反映してないよ。あんな形、Finnishの歴史上で誰も喋ったことないから。文法ってのは言葉を「記述」するもの、「定義」するもんじゃないんだ！

”would like a word”ね。なるほど、君がそこで何やったか分かったよ…ってね。

まさに彼らが言ってることだよ。「the work required deep incite」なんて書いたら、普通のスペルチェックじゃ間違い見つけられないけど、みんなそれはスペルミスだって思ってるもんね。

「cue」を「queue」と間違える人たちの登場だね。

でもさ、スペルチェックがこのコメント直してくれたら良かったと思わない？

ハハ！ Appleは”of”だけ拾って”consider have instead”って言ったけど、他はそのままだったよ。スペルチェックの限界を示す最高のqedだね。でもね、Chatgptは完璧に直したよ：”But wouldn’t you like it if a spell check could have fixed these commands？”ってね。