見出し画像

AIプログラミングの未来 | レックス・フリードマン ポッドキャスト #447

AIに仕事を奪われたい

53,228 文字

ほな、今日はカーソルチームの創業メンバーであるマイケル・トゥルーエル、スワーレ・アシフ、アービド・ルンドマーク、アマン・サンガーとの会話をお届けしますわ。カーソルいうんは、VSコードをベースにしたコードエディタで、AIアシスト機能をようけ追加しとるんです。プログラミングとAIのコミュニティで注目を集めとるんですわ。
せやから、今回はAIを使ったプログラミングの役割について深く掘り下げるええ機会やと思いましてな。今回の会話はめっちゃ技術的な内容で、単にコードエディタの話だけやなくて、プログラミングの未来、そして複雑で強力なシステムを設計・開発する際の人間とAIの協力関係の未来についても触れていきますわ。
これはレックス・フリードマンのポッドキャストです。応援していただける方は、ディスクリプションのスポンサー情報をチェックしてくださいな。ほんでは、みなさん、マイケル、スワーレ、アービド、アマンをお迎えしましょう。
ほな、まずは大きな質問からいきますわ。コードエディタの意味って何やねん？
コードエディタいうんは、主にソフトウェアを作る場所やねん。長いこと、正式なプログラミング言語をテキスト編集する場所いう意味やったんやけど、プログラマーやない人にとっては、コードエディタは超パワーアップしたワードプロセッサみたいなもんやと思ってもらえたらええわ。パワーアップしとるいうんは、コードには構造があるからやねん。
ほんで、いわゆるワードプロセッサであるコードエディタは、テキスト編集の場面では実現できへんかったようなことがようけできるんや。例えば、コードのトークンを視覚的に区別して素早く読めるようにしたり、インターネットのハイパーリンクみたいに、コードベース内を移動できたりするんや。使ってるもんの定義に飛べたりもするし、初歩的なバグを見つけるエラーチェックもできるんや。
これまで、コードエディタはそういう意味やったんやけど、これからの10年でソフトウェア開発の意味が変わってくると、コードエディタの意味も大きく変わってくるんちゃうかなって思うわ。あと、コードエディタは楽しくなきゃあかんねん。そうやな、めっちゃ大事やで。実は、これが我々の開発の判断基準としてあんまり評価されてへんとこやねん。
我々が作るもんの多くは、試してみて、実験して、それで楽しくなかったらポイってなるんや。楽しいいうのは、多くの場合、速いいうことやねん。速いのが楽しいんや。ほんまやな。「速いのが楽しい」ってTシャツにしたらええんちゃう？根本的に、多くの人がコンピューターでモノを作りたがるのは、この信じられへんくらい速い反復速度があるからやと思うわ。
他の分野やと、リソースや大勢の人を集める能力に制限されてまうけど、コーディングはすごいねん。あんたとコンピューターだけで、めっちゃクールなもんをめっちゃ速く作れるんや。
ほんじゃ、みなさんにとってのエディターの遍歴について聞かせてもらえへんか？VSコードとコパイロットの大ファンやったと思うんやけど、どうやってVSコードに辿り着いて、それがカーソルへの道のりにどうつながったんか教えてくれへん？
そうやな。我々の多くは、いや全員がもともとVimユーザーやったんや。純粋なVimやで。ターミナルの中の純粋なVimや。少なくとも私の場合は、コパイロットが出てきた2021年頃やったかな、それを試してみたくてな。当時はVSコードだけがコパイロットを使えるプラットフォームやったんや。
Vimを使うのは楽しかったんやけど、VSコードとコパイロットの体験があまりにも良くて、乗り換える決め手になったんや。それがデフォルトになって、カーソルの開発を始めるまでそうやった。
ほんで、コパイロットの説明もせなあかんな。めっちゃええ自動補完みたいなもんや。何か書き始めると、1行か2行か3行、どう続けたらええか提案してくれるんや。それが楽しい体験なんや。親友が言葉を続けてくれるみたいな感じやな。うまくいくと、なんか親密な感じがするんや。親密いう言葉が適切かどうかは分からんけど、「めっちゃ分かってくれとる！」みたいな、ええ感じがするんや。
逆に、分かってくれへん時はイラッとするけどな。そこにはちょっとした摩擦があるんやけど、多くの人にとっては、「分かってくれてる」感の方が「分かってくれへん」感を上回るんやろな。実は、GitHub Copilotの過小評価されてる側面の一つは、間違ってても、ちょっとイラッとするだけで、そんなに悪くないことやねん。
もう一文字打ったら、そこで理解してくれるかもしれへんし、もう一文字打ったらそこで理解してくれるかもしれへん。だから、間違ってても、そんなに悪くないんや。そうやな、修正して改善できるからな。
私にとってコパイロットの過小評価されてる部分は、初めての本格的なAI製品やったいうことやな。初めての言語モデルの消費者向け製品やったんや。つまり、コパイロットは最初のキラーアプリやったんやな。せやな。ベータ版は2021年に出たんやな。
ほな、カーソルの誕生秘話を教えてくれへんか？2020年頃、OpenAIからスケーリング則の論文が出たんや。そこで、この分野に明確で予測可能な進歩があることが分かったんや。たとえ新しいアイデアがなくても、計算能力とデータさえ増やせば、これらのモデルをかなり改善できることが分かったんや。
ちなみに、スケーリング則については3、4時間くらい話せそうやな。はい。簡単に言うと、機械学習の分野でモデルサイズとデータサイズを大きくすることが良いかもしれないという論文と一連のアイデアのことやな。大きいほど良いし、予測可能に良くなるんや。それはまた別の話題やな。せやな。
その頃、我々の何人かは、これがどうなるんやろ？知的労働者の各分野で、この技術が進歩することでどう良くなるんやろ？みたいな概念的な会話をようけしとったんや。
それから、その論文で予測されてた理論的な進歩が、めっちゃ具体的に感じられるようになってきた瞬間があってな。AIで有用な仕事をしたいなら、博士号を取る必要はなくなったんや。実際に役立つシステムをようけ作れるようになったんや。
最初の大きな瞬間は、さっき少し話したけど、初期のコパイロトを使った時やな。めっちゃすごくて魔法みたいやったんや。次の大きな瞬間は、全てが一気に繋がった瞬間やった。それはGPT-4の早期アクセスを得た時やったんや。
2022年の終わり頃にそのモデルをいじり始めたんやけど、能力の向上がめっちゃ大きく感じられたんや。それまでは、コパイロットやスケーリング則、それにこの技術への以前からの興味もあって、プログラマー向けのツールをいろいろ作ってたんやけど、めっちゃ具体的なもんやったんや。
例えば、金融パフォーマンスのためのツールを作ったり、Jupyterノートブックで作業する必要がある技術者向けのツールを作ったり、これらのモデルで静的解析ができるかどうか試してみたりしてたんや。
せやけど、GPT-4の能力向上を見て、以前に予測してた理論的な進歩が具体的になったって感じたんや。その時点で、すぐにもっとようけのもんが作れるって感じたんや。また、一貫性を保つなら、これは単なる個別のソリューションにはならへんって感じたんや。プログラミング全体がこれらのモデルを通して流れていくことになるんやって。
そやから、違うタイプのプログラミング環境が必要やと感じたんや。そんで、その大きなビジョンを実現するために動き出したんや。
ちょっと思い出したことがあるわ。私のルームメイトは国際数学オリンピックの金メダリストで、アメリカにはパトナムという大学生向けの国際数学オリンピックみたいな競技があるんやけど、それはめっちゃレベル高い数学の競技なんや。
2022年6月頃、シェン・トンとアマンがこんな賭けをしたんや。2024年6月か7月までに、モデルを使って国際数学オリンピックで金メダルを取れるかどうかってな。国際数学オリンピックは International Math Olympiad の略やな。そうそう、国際数学オリンピックや。アービドと私も参加したことあるから、なんかこう、個人的な思い入れがあってな。
私は当時、これは絶対無理やと思ったんや。進歩は信じてたけど、国際数学オリンピックの金メダルはアマンの妄想やと思ってた。正直に言うと、私は完全に間違ってたんやけど、それが多分グループの中で一番先見の明があった賭けやったんかもしれんな。
最近のDeepMindの結果を見ると、アマンが正しかったってことやな。まあ、技術的には違うんやけどな。あと1点足りんかったからな。アマンはこの手の話題にめっちゃ熱心やったんや。昔はスケーリング則のTシャツを着て歩き回ってたんやで。グラフと公式が書かれたやつをな。
へー、そんなにスケーリングを感じてたんか？そうそう、はっきり覚えてるんやけど、マイケルとの会話があってな。彼はそれまでスケーリング則についてあんまり深く考えてなかったんやけど、こんな質問をしてきたんや。「なんでスケーリングだけじゃあかんのか？」とか「なんでスケーリングが大きな進歩をもたらさへんのか？」って。
私は悲しみの5段階みたいなんを経験したわ。怒りがあって、否定があって。最後には、考えてみると、いつかは到達するんやって。逃げ道はないんや。最後には受け入れるしかないんや。それ以来、私はかなり希望的で、進歩に対して楽観的になったと思うわ。
ただ、一つ注意せなあかんのは、どの分野で進歩が見られるかによって違うと思うんや。数学はええ分野や。特に形式的な定理証明はな。実際に正しいかどうかを確認できるっていう素晴らしい信号が得られるからや。だから、強化学習みたいなんがめっちゃうまく機能するんや。
数学ではめっちゃ人間を超えるようなシステムができても、技術的にはまだAGIじゃないってこともあり得るんちゃうかな。
ほな、カーソルの話に戻していこか。カーソルって何なん？VSコードのフォークで、VSコードは長いこと人気のあるエディタやったんや。みんなが惚れ込んで、みんなVimを捨ててな。私もEmacs捨てたわ。ごめんな。
開発者コミュニティを根本的に統一したんや。そんで、その分野を見て、スケーリング則を見て、AIがめっちゃすごくなってるのを見て、VSCodeの拡張機能を作るだけじゃ足りんって判断したんやな。AIがどんどん良くなっていくなら、AIを編集プロセスの一部にするためにほんまに考え直さなあかんって。
そやから、VSCodeをフォークして、たくさんの機能を作り始めたんやな。でも、その決断はどうやったんや？VSCodeには、コパイロットを含めてAI系の拡張機能がようけあるやろ。VSCodeをフォークする決断はどうやったん？
その決断は、我々にとってはかなり自明やったんや。少なくとも我々がやりたかったこと、達成したかったことにはな。エディターの開発を始めた時、こう考えたんや。これらのモデルはもっと良くなる、能力も向上する、そしてソフトウェア開発の方法を完全に変えてしまうやろうって。
生産性が大幅に向上するだけやなく、ソフトウェア開発という行為そのものが大きく変わるんやって。既存のコーディング環境のプラグインとして作るなら、コードエディターに対する制御がめっちゃ限られてしまうんや。我々はそういう制限に縛られたくなかったんや。ただ一番役立つもんを作りたかったんや。
ほな、次の自然な質問は、VSCodeはコパイロットとある意味競合してるやろ？どうやって勝つんや？単に速度の問題なんか？
そうやな、この分野はかなり面白くて、他の技術の波とは違うとこがあるんちゃうかな。過去の技術の波やと、一つの大きなことが起こって、それが新しい企業の波を生み出すみたいな感じやったけど、今はちゃうんや。
毎年、モデルの能力が向上するたびに、新しい機能や可能性の波が生まれるんや。特にプログラミングの分野ではな。だから、AIプログラミングの分野では、たった数ヶ月先を行くだけでも、1年先を行くならなおさら、製品がめっちゃ有用になるんや。
1年後のカーソルは、今日のカーソルを時代遅れに見せなあかんと思ってる。マイクロソフトもええことをようけしてるけど、スタートアップほど革新し続けて、この分野を押し進める立場にはおらへんと思うわ。
機能をどんどん実装していくんやな。そうそう、必要な研究や実験をして、本当に限界を押し上げていくんや。
機能っていうより、プログラマーの能力を高めることやと思うわ。新しいモデルが出てきて、これからもっと違うタイプのモデル、例えば長いコンテキストを扱えるモデルや、もっと速いモデルが出てくるやろ。
試せるクレイジーなアイデアがようけあるんや。そのうち10%くらいが実現可能になるかもしれへん。マイクロソフトもクールで有用なもんを作ってるけど、我々はそれをもっと早く人々に届けたいんや。
言い換えると、見過ごされがちな事実やけど、我々は自分たち自身のために作ってるんや。カーソルを始めた時、すごくイライラしてたんや。モデルがどんどん良くなってるのが見えてたのに、コーディング体験が変わってへんかったんや。
「なんでこの人ら新しいもん作らへんねん？天井は上がってるのに、なんで新しいもん作らへんねん？アルファ版の機能とかないんか？」って感じやったんや。アルファ版の機能が全然なかったんや。ビジネスとしてはうまくいってたんやろうけど、新しいもんを試したい我々みたいな人間にとっては、長いこと新しいもんが何もなかったんや。
そうやな、それを言葉で表すのは難しいけど、カーソルとコパイロットを比べると、コパイロットはすぐに古臭く感じてきたんやな。
そうやな、我々の利点の一つは、全部自分たちでやってることやと思うわ。モデルとのインタラクション方法やUXを開発しながら、同時にモデルの回答を良くする方法も開発してるんや。
プロンプトの作り方とか、カーソルタブのコンテキストの見つけ方とか、モデルの訓練方法とかな。エンドツーエンドで全部を同じ人間が扱えるのが強みやと思うわ。
そうやな、UIを作る人とモデルを訓練する人が18フィート離れた場所にいるんや。よく同じ人間やったりもするしな。そやから、話し合ったり実験したりせえへかったら不可能なもんが作れるんや。言うてた通り、カーソルを使ってカーソルを書いてるんやで。そうそう、そうやねん。
ほんじゃ、これらの機能について話そか。全知全能の、称えられるべきタブについて話そか。ステロイド注射したような自動補完やな。タブはどう機能するんや？タブで何ができるか、簡単に説明してくれへんか？
今のところ、カーソルが特に得意なことは2つあるんや。他にもできることはあるけど、プログラマーの助けになる2つのことがあるんや。
一つは、肩越しに見てるような感じで、めっちゃ速い同僚みたいに先回りして、次に何をするかを把握して入力してくれるんや。これが元々のアイデアで、優れた自動補完の核心やったんや。カーソルの次の文字を予測するんやけど、それをもっと野心的にしたんや。
カーソルの次の文字だけやなく、次の文全体や、次の変更点、次にジャンプする場所まで予測するんや。
カーソルが今得意な2つ目のことは、時々AIより先に進んで、AIに何をすべきか指示して、その指示をコードに変換することや。
我々が本当に欲しかったのは、モデルにコードを編集させることやったんや。それが願いやったんや。うまくコードを編集できるモデルができるまでに、何度も挑戦したんや。
いいモデルができてからは、推論を速くするのに結構努力したんや。ユーザー体験を良くするためにな。それに、マイケルが言うてた異なる場所にジャンプする能力も取り入れ始めたんや。
これは、編集を受け入れた後に「次はどこに行くべきか明らかやろ」って感覚から来てるんや。例えば、「この変更をしたら、次は18行下に行くべきやろ」って。Vimユーザーなら18jjとか押すんやろうけど、なんでそんなことせなあかんねん？モデルが知っとくべきやろって。
そやから、タブを押したら18行下に行って、次の編集を見せるようにしたんや。ユーザーはタブを押し続けるだけでええんや。社内では「何回タブを押させられるか」っていう競争になったんやで。
もっと抽象的に考えると、編集をどれだけゼロエントロピーにできるかって話やな。いったん意図を表現して編集が終わったら、新しい情報ビットはもうないけど、コンピューターに実際の考えを理解させるためにまだ何文字か入力せなあかん。
そんな時、モデルが心を読んで、ゼロエントロピーのビットを全部タブで飛ばしてくれたらええんちゃうかって。それが抽象的なアイデアやったんや。
面白いことに、異なるドメインでの言語モデルの損失を見ると、コードのビット/バイト、つまり文字で正規化した損失は、言語よりも低いんや。つまり、一般的にコードには超予測可能なトークンがようけあるってことや。
これは、単にコードを自動補完するんやなくて、既存のコードの編集で次にユーザーが何をするかを予測する時にさらに顕著になるんや。
だから、カーソルタブの目標は、編集の意図が実質的に決まってる時に、エディター内での低エントロピーな操作を全部なくすことなんや。時間を飛ばして先に進めるんや。
ほな、次のカーソル予測、つまりそのジャンプをする直感と技術的な詳細について教えてくれへんか？そんなに直感的やないと思うんやけど。
そうやな、いくつか詳細を説明できるわ。これらを機能させるには、めっちゃ低レイテンシーにせなあかんのや。だから、この特定のタスクに対して小さなモデルを訓練する必要があるんや。
それに、めっちゃトークンを先読みする必要があるんや。つまり、めっちゃ長いプロンプトがあって、コードをようけ見て、実際に生成するトークンはそんなに多くないってことや。
そのために最適なのが、スパースモデル、つまりMoE（Mixture of Experts）モデルを使うことや。これが一つのブレイクスルーで、長いコンテキストでのパフォーマンスを大幅に向上させたんや。
もう一つは、投機的デコーディングの変種で、我々が開発した投機的編集っていうものや。これらが、高品質で高速な結果を生み出す重要な要素やね。
なるほど、MoEはMixture of Expertsか。入力は巨大で、出力は小さいんやな。そうそう。
他にキャッシュが役割を果たすんか？
そうや、キャッシュはめっちゃ重要な役割を果たすんや。これだけ多くの入力トークンを扱うとき、一行で入力する各キーストロークごとに、全てのトークンをモデルに再度渡さなあかんかったら、レイテンシーがめっちゃ下がるか、GPUに負荷がかかりすぎてしまうんや。
だから、モデルに使うプロンプトをキャッシュを意識して設計する必要があるんや。そして、リクエスト間でKVキャッシュを再利用して、計算量を減らすんや。
タブができることって、近い将来どんなことがあるんや？
空白を埋めてコードを生成したり、複数行にわたってコードを編集したり、同じファイル内の異なる場所にジャンプしたりできるんや。それに、できれば異なるファイルにもジャンプできるようにしたいんや。
一つのファイルで編集したら、その考えを完成させるために別のファイルに行かなあかん場合もあるやろ。そんな時も2つ目のファイルに行けるようにしたいんや。
最終的には、次のアクション予測っていう完全な一般化を目指してるんや。時には、書いたコードに基づいてターミナルでコマンドを実行する必要があるかもしれへん。そんな時はコマンドを提案できるようにしたいんや。
また、モデルが何か提案しても、正しいかどうか判断するのが難しい場合もあるやろ。例えば、型を知らんと正しいかどうか確認できへんような場合やな。そんな時は、定義の場所に連れて行ってくれて、また戻ってきてくれるようにしたい。
次の補完を受け入れるのに必要な知識を全部持てるようにな。つまり、人間に知識を提供するってことやな。そうそう、そうやねん。
最近、PrimeGenっていう人と知り合ったんやけど、SSHでコーヒーを注文できるらしいんや。そんなんもモデルでできるようになるんか？あんたらに餌をやったり、カフェインを提供したりするみたいな。
そうやな、そんな感じやな。プログラミングって面白い分野で、次の5分間に何をするかが、いつもってわけやないけど、時々予測可能なんや。最近やったことから予測できることがあるんや。
そやから、その次の5分間を、あんたが離れてても勝手に進めてくれたり、次にやることを見せてくれて「ええな、ええな、ええな」って感じでタブタブタブって大きな変更を進められるような世界にできへんかなって思うんや。
こんな話をしてると、カーソルのすごくクールで目立つ特徴の一つを言わんとあかんな。diff（差分）インターフェースの状況やな。
モデルが「with」で提案して、赤と緑でコードをどう修正するか示してくれるんや。チャットウィンドウで適用できて、diffが表示されて、そのdiffを受け入れられるんや。
その方向性についてもうちょっと詳しく教えてくれへんか？
多分4、5種類のdiffを用意することになると思うわ。自動補完用に最適化したdiffがあって、それは大きなコードブロックをレビューする時のdiffとは違うインターフェースになるんや。それに、複数のファイルを扱う時のdiffも最適化しようとしてるんや。
大まかに言うと、自動補完の時は、めっちゃ速く読めるようにせなあかんのや。まあ、どんな状況でも速く読めるようにせなあかんのやけどな。でも自動補完の場合は、目が一箇所に集中してるから、人間があんまり多くの場所を同時に見られへんのや。
インターフェース側の話をしてるんやな。そうや、現在は横にボックスがあるんや。コードを削除しようとしたり、他のコードを追加しようとしたりすると、横にボックスを表示して示そうとするんや。cursor.comを開いたら見えるはずや。
これを作るのに3、4回違う試みをしたんや。最初は、青い取り消し線みたいなんやったんや。横のボックスの前は、削除するコードをGoogle Docsみたいに取り消し線で表示してたんや。それで新しいコードを表示してたんやけど、めっちゃ気が散るんでな。
それから赤でハイライトしたりとか、いろいろ試したんや。次の反復が面白くてな、Macやとオプションキーを押すと、コードの一部が青くなって、AIが提案があることを示すようにしたんや。
例えば、このケースやと、inputとvalueが全部青くなって、AIが提案を持ってることを示すんや。直接提案を見せるんやなくて、AIが提案を持ってることをほのめかすだけや。本当に見たかったらオプションキーを押したら提案が見えるようにして、離したら元のコードに戻るようにしたんや。
ちなみに、それはええアイデアやけど、オプションキーを押さなあかんって知っとかなあかんのがな。まあ、私はMacユーザーやないけど、分かったわ。ボタンやったんやな。
そうやな、これもまた直感的やないんや。それが一番の問題やと思うわ。これも最終版やないかもしれへんな。個人的には、この部分をもっと改善できるって楽しみにしてるんや。
我々はよく「検証問題」って呼んでるんやけど、これらのdiffは小さな編集には最適やけど、大きな編集や複数のファイルを扱う時には、diffをレビューするのがちょっと大変なんや。
これについてはいくつかアイデアがあってな。一つのアイデアは、diffの一部は重要で情報量が多いけど、他の部分は情報量が少なくて同じことの繰り返しやったりするから、重要な部分をハイライトして、そうでない部分をグレーアウトするとかやな。
あるいは、diffを見て「ここにバグがありそうや」って気づいて、赤い波線でマークして「このdiffの部分はちゃんとレビューした方がええで」って教えてくれるモデルを作るとかな。
こういうアイデアがワクワクするんや。そうやな、それはめっちゃ面白い分野やな。要はUXの話で、人間のプログラマーが読むべきものを全部、でもそれ以上は読まんでええように案内しようってことやな。
そうや、最適にな。そのためには知的なモデルが必要やな。今のdiffアルゴリズムは普通のアルゴリズムやからな。知性はないんや。アルゴリズムを設計する時に知性が使われたけど、これがこうやとか、あれがああやとか気にせえへんのや。
モデルにこれをやってほしいんや。全体的な質問としては、「モデルがもっと賢くなるにつれて、提案できる変更がどんどん大きくなるんちゃうか？」ってことやな。
変更が大きくなればなるほど、人間はもっともっと検証作業をせなあかんようになるし、どんどん難しくなるんや。人間を助けなあかんのや。私はコードのレビューにずっと時間を使いたくないしな。
複数のファイルにまたがる場合について、もうちょっと詳しく教えてくれへん？
そうやな、GitHubはコードレビューでこれを解決しようとしてるんや。コードレビューする時は複数のファイルにまたがる複数のdiffをレビューするんやけど、アービドが言うたみたいに、コードレビューよりもっとええことができると思うんや。
コードレビューってクソやからな。よく知らんコードを理解しようとするのに時間かかるし、実際にはバグを見つけられへんことも多いんや。コードレビューを始めると、システムがそれを別の方向に進めてしまうこともあるしな。
そうやな、HMはそこが本当に重要やと思うわ。そやから、標準的なRGNとaltctorsの間で決めなあかんのや。それが、コードを作ったのが言語モデルの場合の面白いとこやな。
コードを作った人の経験をそんなに気にせんでもええから、レビュアーの仕事をできるだけ楽しく、簡単で、生産的にするように全体を設計できるんや。
これをただコードレビューに見せかけようとするんやなく、もっと創造的になって、可能性の限界を押し広げられると思うわ。
一つのアイデアは、順序が大事やってことや。普通、PRをレビューする時はファイルのリストがあって、上から下に見ていくやろ。でも実際は、この部分を最初に理解して、次にあの部分を理解したいってのがあるはずや。
それを自分で見つけ出すんやなくて、モデルがその順序を案内してくれたらええんやないかな。
作る段階はどんどん自然言語に近づいていくんやろか？それとも実際のコードを書くのが目標なんか？
プログラミングの全てが自然言語になるとは思わへんな。その理由はな、例えばスワーレとペアプログラミングしてて、スワーレがコンピューターとキーボードを操作してる時、私が指示してる時もあるんや。「この関数を実装して」って言うたら、それでうまくいくこともある。
でも時々、スワーレに何をしてほしいかを説明するのがめっちゃ面倒くさくなるんや。そんな時は実際にキーボードを奪って、例の一部を書いて見せるんや。そうすると理解してくれるし、それが一番簡単なコミュニケーション方法なんや。
AIでも同じやと思うんや。AIとコミュニケーションする一番簡単な方法は、時々例を見せることやと思うんや。そしたらAIがそれを理解して、他の場所でも同じことをしてくれる。
例えばウェブサイトを作る時、AIに何をしてほしいかを伝える一番簡単な方法は、言葉で説明することやなくて、物を動かしたり描いたりすることかもしれへん。
まあ、いつかは脳とコンピューターを直接つなぐインターフェースができて、考えてることを理解してくれるようになるかもしれへんけどな。
自然言語にも場所はあると思うけど、ほとんどの人がほとんどの時間にプログラミングする方法にはならへんと思うわ。
このエディターにはAIがようけ使われてる感じがするわ。裏側で機械学習がようけ動いてるんやろ。カーソルを動かすのに使われてる機械学習について教えてくれへんか。
カーソルは主に、我々が訓練したカスタムモデルのアンサンブルで動いてるんや。それと一緒に、推論が必要な部分では最先端のモデルも使ってる。
例えばカーソルタブは、この特定のタスクに特化したモデルを使うことで、最先端のモデルよりもさらに性能が良くなる良い例やな。評価を見ると分かるで。
意外かもしれへんけど、カスタムモデルが必要で、うまく機能する別の分野があるんや。それが「apply」や。
最先端のモデルはコードの大まかな計画を立てたり、変更の大まかなスケッチを生成したりするのはめっちゃ得意なんやけど、実際にdiffを作るのはかなり難しいんや。
ソネットやO1、どんな最先端モデルでもこれをやらせると、行番号を数えるみたいな単純なことでもめちゃくちゃになってしまうんや。特に超大きなファイルやとな。
そこで我々がやったのは、モデルに変更を示す大まかなコードブロックをスケッチさせて、それをファイルに適用するモデルを訓練したんや。
「apply」っていうのは、モデルがあんたのコードを見て、新しく何をすべきかめっちゃええ提案をしてくれるってことやな。人間にとっては簡単そうに見える、その2つを組み合わせるステップが、実はそんなに簡単やないって言っとるんやな。
そうや、一般的に思われてるのと違って、これは決定論的なアルゴリズムやないんや。他のところでも「apply」の浅いコピーを見かけるけど、ほとんどの場合うまくいかへんのや。
何か決定論的なマッチングをしようとしても、少なくとも40%くらいは失敗してしまう。そうなると製品体験が台無しになってしまうんや。
一般的に、モデルがどんどん賢くなっていく状況では、「apply」を使うことで最も知的なモデルに少ないトークンで済むようになるんや。
これは、全てのトークンを生成するのにかかる時間の観点からも、コストの観点からも高くつくんや。だから、めっちゃ大まかなスケッチを与えて、小さなモデルに実装させることができるんや。
大まかにスケッチされたコードを実装するのは、はるかに簡単なタスクやからな。この状況は続くと思うわ。より賢くて小さなモデルを計画に使って、実装の詳細は知性の低いモデルに任せるみたいな感じやな。
もしかしたら、例えばO1みたいな、もっと能力の高いモデルがさらに高レベルの計画を立てて、それをソネットが再帰的に適用して、それから「apply」モデルが実装するみたいなこともあり得るかもな。
ほんじゃ、どうやって速くするかについて話そか。速さはいつも面白い詳細やからな。どうやって速くしてるんや？
そうやな、速くする大きな要素の一つが投機的編集や。投機的編集は投機的デコーディングの変種なんやけど、投機的デコーディングについて簡単に説明した方がええかもな。
投機的デコーディングでは、メモリがボトルネックになってる時、言語モデルの生成で複数のトークンを同時に処理すると、一つずつトークンを生成するより速くなるって特性を利用するんや。
これは、プロンプトトークンと生成トークンのトークン/秒を見ると、プロンプトトークンの方がめっちゃ速い理由と同じやな。
普通の投機的デコーディングやと、大きなモデルが確認する下書きトークンを予測するのにめっちゃ小さなモデルを使うんやけど、コード編集の場合は違うアプローチを取るんや。
既存のコードがどんな感じかについて、めっちゃ強い事前分布があるんや。その事前分布は文字通り同じコードなんや。だから、元のコードの塊をそのままモデルに入力できるんや。
そしたらモデルは、ほとんどの場合「ああ、このコードをそのまま出力するわ」って同意するんや。そやから、それらの行を並列に処理できるんや。
十分な数の塊でこれをやって、最終的にモデルが元のコードと違うテキストを予測する不一致点に到達するんや。そこでトークンを生成して、元のコードと十分な数のトークンが一致したら、また塊でコードを投機し始めるんや。
実際にはこれがどう見えるかっていうと、普通のコード編集のめっちゃ速いバージョンみたいな感じになるんや。モデルが全てのコードを書き直してるように見えるけど、めっちゃ速くなるんや。
それで、同じdiffのインターフェースが使えるんやけど、めっちゃ速くストリーミングされるんや。そしたら、ストリーミングしてる間に、人間が読み始められるっていう利点もあるんや。前みたいに、大きな読み込み画面が出るんやなくて、処理が終わる前から人間がコードを読み始められるんや。
面白いのは、投機っていうアイデアは最近よく見かけるんや。言語モデルだけやなくて、CPUでも投機実行があるし、データベースでも投機的な処理があるし、いろんなとこで投機的な処理が行われてるんや。
ほな、ちょっとおかしな質問かもしれへんけど、どのLM（言語モデル）がコーディングに一番ええんや？クロードとか、誰が勝つんや？プログラミングの文脈でな。
まあ、答えはもっと複雑やと思うわ。今の話を聞いてると、これの全ての部分に違うモデルが使われてるみたいやからな。
そうやな、全ての重要なカテゴリーで他のモデルを圧倒してるモデルはないんや。重要なカテゴリーっていうのは、速度、コードの編集能力、大量のコードを処理する能力、長いコンテキスト、それにコーディング能力なんかやな。
今のところ、全体的に一番ええと言えるのはソネットやな。これは意見が一致してると思うわ。O1もめっちゃ面白くて、推論がめっちゃ得意なんや。めっちゃ難しいプログラミングの面接問題やリートコードの問題を与えると、かなりよくできるんや。
でも、ソネットほどあんたの大まかな意図を理解してくれてる感じがせえへんのや。他の最先端モデルを見ても、一つ不満なのは、必ずしもベンチマークで訓練されてるわけやないんやけど、ベンチマークや評価されるベンチマークの分布に入るようなもんに対してはめっちゃよく機能するんや。
でも、そこから少し外れたことをさせようとすると、ソネットが一番うまくその能力を維持できるんや。ベンチマークでの能力と、コーディングに関して何かを指示した時の能力が、ほぼ同じレベルで維持されるんや。
もう一つのおかしな質問やけど、普通のプログラミング体験とベンチマークが表してるものの違いって何やと思う？ベンチマークはどこが足りてへんと思う？これらのモデルを評価する時にな。
ちなみに、それはめっちゃめっちゃ難しい問題やな。めっちゃ重要な詳細やけど、ベンチマークと実際のコーディングがどれくらい違うかってのは難しい問題や。
実際のコーディングは面接スタイルのコーディングとは違うんや。人間が半分壊れた英語で話したり、「さっきやったみたいにやって」とか言ったり、「これ追加して、それからあれやって、それからこのUI要素作って」みたいな感じで言うんや。
コンテキストに依存することがようけあるんや。人間を本当に理解して、人間の望むことをやりたいんや。面接の問題は仕様がはっきりしてるけど、人間の要求はそこまではっきりしてへんのや。
そうやな、このベンチマークの問題は、アモンが言うてたことでさらに複雑になるんや。ベンチマークで実際のプログラミングをモデル化できるかって問題もあるし、実際のプログラミングはめちゃくちゃで、何が正しいか明確やない場合もあるからな。
それに加えて、公開ベンチマークの問題もあるんや。公開ベンチマークは時々過度に最適化されてしまうし、公開ベンチマークのデータをモデルから完全に取り除くのも難しいんや。
例えば、一番人気のあるエージェントのベンチマークの一つ、SweetBenchは、これらの基礎モデルの訓練データにめっちゃ混入してしまってるんや。だから、これらの基礎モデルにSweetBenchの問題を解かせると、コードベースのコンテキストを与えなくても、正しいファイルパスや関数名を幻覚できてしまうんや。
公開ベンチマークの問題は難しいんや。その場合、文字通り問題やプルリクエスト自体を学習してしまってる可能性もあるんやな。
そうやな、研究所がこれらのデータの除染をもっとうまくやるようになるかもしれへんし、もう既にうまくやってるかもしれへん。でも、リポジトリ自体の実際の訓練データを省くことはないやろうな。
これらは全部人気のPythonリポジトリやからな。例えばSimpyとかな。これらの人気のPythonリポジトリでモデルを不利にするようなことは、ベンチマークでの真の評価スコアを得るためにはせえへんと思うわ。
そうやな、ベンチマークが少ないから、これらのモデルを使ってシステムを作ったり、モデル自体を作ったりする人らが、正しい方向に進んでるかどうかを確認するのに使う面白い方法がいくつかあるんや。
多くの場所で、実際に人間にそれらを使わせて、質的なフィードバックをもらうんや。基礎モデル会社の1、2社では、それが主な役割の人もおるし、我々も内部で質的にモデルを評価して、それにかなり頼ってるんや。それに加えて、内部の評価も使うんやけどな。
雰囲気やな。雰囲気のベンチマークか。人間のベンチマークやな。そうや、人間を呼んで雰囲気チェックをしてもらうんや。
まあ、それが私のやってることみたいなもんやな。オンラインフォーラムやReddit、Xを読んで、人々の意見を取り入れようとしてるんやけど、どう適切に取り入れたらええか分からへんのや。
「クロードやGPTが馬鹿になった気がする」みたいなことを言うんやけど、私もそう感じることがあるんや。でも、それがモデルの問題なのか、私の問題なのか分からへんのや。
クロードに関しては面白い説があってな。AWSには違うチップがあって、NVIDIAのGPUとは少し違う数値を使ってるんやないかって。誰かが、クロードのパフォーマンス低下は、AnthropicのGPUで動いてるバージョンやなくて、AWS Bedrockで動いてる量子化されたバージョンを使ってるからやないかって推測してたんや。
私はいろんな陰謀論を持ってる人にインタビューしたから、その陰謀論について話してくれてよかったわ。
まあ、陰謀論っていうより、人間は人間やからな。こういう細かいことがあって、めっちゃ多くの演算をしてて、チップはめちゃくちゃやから、バグが起こり得るんや。バグを避けるのがどれだけ難しいかは言い表せへんくらいや。
この中で、良いプロンプトの役割ってなんやと思う？ベンチマークにはめっちゃ構造化された、よく練られたプロンプトがあるって言うてたけど、人間は成功率を最大化するために何をすべきなんや？あんたがブログ記事で書いてた「プロンプト設計」ってどういう重要性があるんや？
そうやな、使うモデルによって違うし、全部ちょっとずつ違うんや。プロンプトに対する反応も違うしな。でも、元々のGPT-4oと去年のバージョンは、プロンプトにめっちゃ敏感で、コンテキストウィンドウもめっちゃ小さかったんや。
そやから、コードベースに関連するいろんな情報があるんや。ドキュメントがあったり、追加したファイルがあったり、会話の履歴があったりする。でも問題は、プロンプトに何を実際に入れるかをどう決めるかってことや。
スペースが限られてるし、今日のモデルでも、コンテキストウィンドウ全部を埋めると遅くなるし、時にはモデルが混乱することもあるんや。あるモデルは他のモデルより混乱しやすいしな。
我々には「preempt」って呼んでる内部システムがあって、これがちょっと助けてくれるんや。8,000トークンのコンテキストウィンドウしかなかった時代のために作られたんやけどな。
ウェブサイトを作る時と似てるんや。モバイルでも動かしたいし、デスクトップ画面でも動かしたいやろ。動的な情報があって、例えば印刷用の雑誌をデザインする時みたいに、どこに何を置けるか正確に分かってるわけやないんや。
ウェブサイトやプロンプトの場合、入力があって、それを常に機能するようにフォーマットせなあかんのや。入力がめっちゃ大きい時は何かを削らなあかんかもしれへんし。
そこで考えたんが、ウェブサイトのデザインで一番ええ方法は何やろうって。我々が本当に気に入ってるのは、Reactと宣言的なアプローチなんや。JavaScriptでJSXを使って、「これが欲しい」って宣言するんや。
これの方が優先度が高いとか、z-indexが高いとかってな。そしたら、ウェブデザインやとChromeみたいなレンダリングエンジンがあって、我々の場合はpreemptレンダラーがあって、全部をページに収めてくれるんや。
欲しいものを明確に宣言して、それを実現する方法を考えてくれるんや。これがめっちゃ役立つってことが分かってん。最初は小さなコンテキストウィンドウに合わせるためやったんやけど、今ではプロンプトに入れるデータと実際のレンダリングを分けるのにめっちゃ役立ってるんや。
デバッグしやすくなるし、プロンプトのレンダリングを変更して、古いプロンプトで試してみることもできるんや。プロンプトに入れた生のデータがあるから、変更が本当に全ての評価セットで改善したかどうか確認できるんや。
ほんまにJSXでプロンプト書くんか？
そうや、ちょっとReactみたいな感じなんや。ファイルコンポーネントみたいなコンポーネントがあって、カーソルの位置とか、普通はファイルの中で今見てる行が一番重要やから、そこに優先度を付けられるんや。
その行に一番高い優先度を付けて、離れるほど優先度を1ずつ下げていくんや。最終的にレンダリングされる時に、実際に収まる行数を計算して、その重要な行を中心に配置するんや。
すごいな。他にも凝ったことができて、コードベース全体からたくさんのコードブロックがある場合、検索を使ったり、埋め込みやリランキングのスコアを使ったりして、各コンポーネントに優先度を付けることもできるんや。
人間も質問する時にそんな感じのことをした方がええんか？プロンプトにJSXを書くのが有利になるんか？それとも、ゆるくてごちゃごちゃしたままの方がええんか？
我々の目標は、あんたにとって一番自然なことをしてもらうことやな。我々の仕事は、あんたの入力を理解して、関連することを取り出して、あんたの入力が意味を成すようにすることやねん。
これは、Perplexityのアービンと話したことに似てるな。彼の考えは、人をできるだけ怠惰にさせるべきやってことやった。
そうやな、それは素晴らしいことやけど、プログラマーにはもうちょっと要求してもええと思うんや。
「好きにしてください」って言うたら、人間は怠惰になるからな。プログラマーに、文法的に正しい文を書けとは言わへんけど、プロンプトの中でより深い考えを表現するように促したり、インスパイアしたりするようなシステムがあってもええんちゃうかな。
システムが完璧に近づいても、モデルに何かを頼む時、多くの場合、何をすべきか判断するのに十分な意図が伝わってへんのや。その意図を解決する方法はいくつかあって、一つは単純にモデルに聞かせることや。「あんたの質問に基づいて、これらの部分をどうしたらええか分からへんから、もうちょっと詳しく教えてくれへん？」みたいな感じやな。
もう一つの方法は、「あんたの質問にはまだ不確実な部分があるから、可能性のある5、6種類の生成結果を見せるわ。どれがええか選んでみてや」みたいなアプローチもあるな。
モデルが「もっと情報くれ」って聞き返すか、それとも曖昧さを自分で処理するかを決めるのはどれくらい難しいもんなんや？
そうやな、我々がやってる最近の追加機能の一つは、追加できそうなファイルを提案することやな。入力してる間に不確実性を推測して、「このAPIを書いてるんやったら、以前の同じファイルのコミットから、クライアントとサーバーが超役立つって分かるで」みたいな感じで提案するんや。
全てのコミットにわたって、どのファイルが一番重要かを解決するのは技術的にめっちゃ難しい問題やねん。まだ初期バージョンを出したところやけど、もっと正確にできると思うわ。かなり実験的やけどな。
でも、このアイデアは「このファイルも追加する？このファイルも？」って聞いて、モデルにそれらのファイルも編集させることができるんや。APIを作ってるんやったら、そのAPIを使うクライアントとサーバーも編集した方がええやろ？みたいな感じやな。
これは、プロンプトを書いてる段階と、エンターを押す前の段階の両方で、不確実性を解決するのを手伝えるからめっちゃクールやと思うわ。
エージェントのアプローチをどの程度使ってるんや？エージェントはどれくらい役に立ってる？
エージェントはめっちゃクールやと思うわ。エージェントは人間に似てるような感じがするんや。デモを見ると、人間のように行動するから、AGIに近づいてる感じがするんやな。めっちゃクールやと思う。
でも、エージェントはまだ多くのことに超役立つってわけやないんや。でも、本当に役立つようになる直前まで来てると思うわ。
特定のタイプのタスクでは、エージェントがあると本当にええと思うんや。例えば、我々のチャット入力ボックスでコマンドCとコマンドVができへんっていうバグがあるとするやろ。これはめっちゃ明確に指定できるタスクやねん。
2文で「これが動かへん。直してくれ」って言うだけで、エージェントが勝手にやってくれて、1日後に戻ってきたらレビューできる、みたいなんがほしいんや。
つまり、正しいファイルを見つけて、バグを再現して、バグを直して、それが正しいか確認するってことやな。
そうそう、正しいファイルを見つけて、バグを再現して、バグを修正して、それが正しいか確認するんや。これは時間がかかるプロセスかもしれへんな。
そういうのがほしいんや。でも、プログラミングの多くは、エージェントが全部やってくれるもんやないと思うわ。エージェントがプログラミング全体を引き受けるって考えがよくあるけど, そうはならへんと思うんや。
プログラミングの価値の多くは、反復にあるからや。最初から全部指定したくないし、できへんのや。最初のバージョンを見てから、もっと情報を提供して反復したいんや。
だから、プログラミングの多くは、瞬時に初期バージョンを返してくれて、そっから超速く反復できるシステムの方がええと思うんや。
最近出たReplantAgentみたいな、開発環境のセットアップやソフトウェアパッケージのインストール、全ての設定、データベースの設定、アプリのデプロイまでやってくれるようなもんについてはどう思う？それも夢見てる範疇に入るんか？
そうやな、それもめっちゃクールやと思うわ。特定のタイプのプログラミングにはめっちゃ役立つと思うわ。
それもカーソルの範疇に入るんか？
そうやな、今のところ積極的に取り組んでるわけやないけど、プログラマーの生活をもっと楽しく、もっと簡単にしたいってのは間違いなくあるんや。
中にはめっちゃ退屈なことがあって、いくつものステップを踏まなあかんようなこともあるやろ。そういうのはエージェントに任せたいよな。
それに、作業してる間にバックグラウンドでエージェントを動かすこともできるんや。例えば、バックエンドとフロントエンドの両方を含むPRがあって、あんたがフロントエンド部分を作業してる間に、バックグラウンドのエージェントが働いて、あんたが何をしてるか把握するんや。
そしたら、PRのバックエンド部分に取り掛かる頃には、反復できる初期コードがある程度できてるって感じやな。それもめっちゃクールやと思うわ。
我々はすでに速さについて話したけど、もうちょっとそこに触れてみようか。これを本当に速くするための様々な場所での技術的な詳細について。
カーソルのほとんど全ての側面が本当に速く感じるはずや。さっき言うたように、「apply」が多分一番遅いところやな。私にとっては...
申し訳ない、痛いんや。我々もそれを感じてて、修正に取り組んでるところなんや。
そうやな、1秒か2秒くらいのことが遅く感じるってことは、他の全てがめっちゃ速いってことやな。
これらのモデルをどうやって速くするか、チャットを速くする方法、diffを速くする方法について、何か思いつくことはあるか？
そうやな、我々が使ってる戦略はようけあるんや。面白いのはキャッシュウォーミングやな。
ユーザーが入力してる間に、おそらく使うであろうコンテキストの一部が分かるやろ。ユーザーが入力し終わる前に分かるんや。
さっき話したように、KVキャッシュを再利用すると、リクエスト間のレイテンシーが下がって、コストも下がるんや。
だから、ユーザーが入力し始めたら、すぐに現在のファイルの内容でキャッシュをウォームアップできるんや。そしたら、ユーザーがエンターを押した時、実際に事前に埋めて計算せなあかんトークンがめっちゃ少なくなるんや。これで最初のトークンまでの時間が大幅に短縮されるんや。
KVキャッシュってどういう仕組みなん？
そうやな、トランスフォーマーの仕組みの一つで、トランスフォーマーが各トークンを独立して見るんやなくて、前のトークンも見れるようにするのが、キーと値のアテンションなんや。
一般的に、アテンションの仕組みはこうや。今のトークンに対して何かクエリがあって、それと前の全てのトークンのキーと値を比較するんや。キーと値は、モデルが内部で保存してる前の全てのトークンの表現みたいなもんや。
デフォルトでチャットする時、モデルは各トークンごとにモデル全体を通す順伝播をせなあかんのや。これはめっちゃ多くの行列乗算が必要で、めっちゃ遅いんや。
でも、それをすでにやって、キーと値をGPUに保存しておけば、例えば最初のnトークンに対してソートしてあったとして、n+1番目のトークンの出力を計算したい時、最初のnトークンを全部モデルに通す必要はないんや。
すでにキーと値があるからな。最後のトークンだけ順伝播させて、アテンションする時に保存しておいたキーと値を再利用するだけでええんや。これはめっちゃ多くの作業を省けるんや。
トランスフォーマーの中で、順序に依存する唯一の部分やと思うわ。
プロンプトのキャッシュみたいな、もっと高レベルのキャッシュもあるんか？
そうや、他のタイプのキャッシュもできるんや。
カーソルタブで面白いのは、ユーザーが提案を受け入れたかのように先読みして、別のリクエストを発行できることやな。
これは投機とキャッシュの組み合わせやな。ユーザーが受け入れた場合を想定して投機的に処理して、その値をキャッシュしておくんや。そしたら、ユーザーがタブを押した時に、次の提案がすぐに待ってるってわけや。
これはちょっと賢い発見的手法というか裏技みたいなもんで、高レベルのキャッシュを使ってるんや。モデルには実際には変更がなくても、めっちゃ速く感じるんや。
これができたら、KVキャッシュをもっと小さくできるっていう利点もあるんや。もっと投機的になれるかもしれへん。例えば、次の10個の可能性を予測して、ユーザーが10個のうちの1つにヒットする確率の方が、表示した1つだけにヒットする確率よりずっと高くなるやろ。
ユーザーがもう1文字打って、キャッシュの別のところにヒットするかもしれへんしな。こういう裏技があって、一般的な現象としては、RLにもめっちゃ役立つんや。
モデルからの1回のサンプリングはあんまりよくないかもしれへんけど、10個の異なる予測をしたら、10個のうちの1つが正解である確率はめっちゃ高くなるんや。これはpass@k曲線っていうんやけど、RLの一部はこのpass@k現象を利用して、たくさんの異なる予測をするんや。
モデルの内部では、k個のうちどれが正解か、あるいはk個のうちどれを人間が望んでるかについて、ある種の不確実性を持ってるって考え方もできるな。
だから、カーソルタブモデルをロールアウトする時、我々がやってるのは、モデルが生成する100個の異なる提案のうち、どれが人間にとってより適切かを予測することなんや。
人間がより好むものと、そうでないものに報酬を与えて、人間がより好みそうな提案を出力するようにモデルを訓練するんや。これらのRL（強化学習）ループは、pass@k曲線を利用してめっちゃ役立つんや。
アマンがもっと詳しく説明できるかもしれへんな。
そうやな、これは速度とはちょっと違う話やけど、小さなモデルでRLをすれば、大きなモデルと同じパフォーマンスが出せるってことやな。
さっきKVキャッシュのサイズを減らす話をしたけど、速度に役立つ他のテクニックもあるんや。
昔、つまり2年前くらいは、主にマルチヘッドアテンションを使ってたんやけど、最近はもっと効率的なアテンションの仕組みに移行してきてるんや。グループクエリやマルチクエリアテンションみたいなんやな。
これは、大きなバッチサイズでトークンを生成するのにめっちゃ役立つんや。面白いのは、これが最初のトークンまでの時間や事前埋め込みの速度には影響せえへってことや。
これが効くのは、トークンを生成する時やねん。長いコンテキストで大きなバッチサイズを使う時、全てのトークンに対して超並列化可能な行列乗算をするんやなくて、どれだけ速くキャッシュされたキーと値を読めるかがボトルネックになるんや。
これはメモリ帯域の問題やな。どうやったらもっと速くできるんやろ？これらのキーと値のサイズを圧縮しようとするんや。
マルチクエリアテンションが一番アグレッシブなやり方やな。普通のマルチヘッドアテンションやと、いくつかのアテンションヘッドと、いくつかのクエリヘッドがあるんやけど、マルチクエリは全てのクエリヘッドを残して、キーバリューヘッドは全部なくすんや。
キーバリューヘッドは1つだけになるんや。グループクエリの場合は、全てのクエリヘッドを残して、キーと値のヘッドは減らすけど、1つだけにはせえへんのや。
要するに、KVキャッシュのサイズを減らすのが目的やな。それからMLA（Multi-Latent Attention）もあるんやけど、これはちょっと複雑や。
これは全てのヘッドのキーと値を、1つの潜在ベクトルに変換して、推論時に展開するんや。MLAはDeep Seekっていう会社が開発したんやけど、めっちゃ面白い会社で、アルゴリズムもめっちゃ面白いんや。
多分、重要なアイデアはMQLとか他の場所でやってることと似てて、KVヘッドの数を減らすことやな。
そうすることのメリットは、数が少なくなることやけど、理論的には、キーと値のそれぞれが本当に違うものであってほしいんや。
サイズを減らす一つの方法は、全てのキーと値に対して1つの大きな共有ベクトルを保持して、各トークンに対してはもっと小さなベクトルを持つことや。
そうすれば、小さい方だけを一種の低ランク近似として保存できるんや。最終的に計算したい時、メモリ帯域がボトルネックになってるってことは、まだ使えるコンピューティングパワーが残ってるってことやろ。
だから、潜在ベクトルを展開して戻すことができるんや。これがめっちゃ効率的なのは、例えばベクトルのサイズを32分の1くらいに減らせるからや。
多分、キーと値とクエリのセットを別々に持って、それらを1対1で対応させるのと、全部を1つに圧縮するのとでは、何か豊かさが違うんやろうな。少なくともその相互作用においてはな。
全てのこれらは、メモリがボトルネックになってる問題に対処してるんやな。結局、ユーザー体験にどう影響するんや？
2つのことに影響するんや。1つは、KVキャッシュに割り当てるスペースが少なくなるから、キャッシュをもっと大きくできるんや。もっとアグレッシブにキャッシュできるし、もっと多くのものをキャッシュできる。
そうすると、さっき説明したように、キャッシュヒットが増えて、最初のトークンまでの時間を減らすのに役立つんや。
もう1つは、より多くのリクエストとより大きな値で推論を始める時、トークンの生成速度があまり遅くならへんってことや。
バッチサイズが大きくなっても、それほど遅くならへんのやな。それに、特定のプロンプトをもっと大きくすることもできるよな。
そうや、KVキャッシュの基本的なサイズは、全てのプロンプトのサイズに並列に処理されてるプロンプトの数を掛けたものやからな。どっちの次元も増やせるんや。バッチサイズかプロンプトのサイズをな。トークン生成のレイテンシーを悪化させずにな。
アービド、あんたは「シャドーワークスペース：バックグラウンドでコードを反復する」っていうブログ記事を書いたよな。あれはどういうことなん？
そうやな、はっきりさせておきたいんやけど、我々はバックグラウンドでようけのことが起こってほしいと思ってて、いろんなことを試してるんや。
今のところ、キャッシュウォーミングとか、コマンドゲートプロンプトに入れる正しいコンテキストを見つけるとか以外はあんまりやってへんのやけどな。
でも、アイデアとしては、バックグラウンドで実際に計算を使えるんやったら、次の数行を予測するだけやなくて、次の10分で何を作るかを予測するのを手伝えるんちゃうかってことや。
バックグラウンドでやることで、それにもっと計算を使えるんや。シャドーワークスペースのアイデアは、我々が実験用に内部で使ってるんやけど、バックグラウンドで何かをする利点を得るには、モデルにフィードバック信号を返す必要があるんや。
そうせんと、モデルにもっと長く考えさせるだけで高性能が得られるだけやからな。O1はその良い例やな。
でも、パフォーマンスを向上させるもう一つの方法は、モデルに反復させてフィードバックを得させることや。プログラマーにとってめっちゃ重要なフィードバックの一つが言語サーバーなんや。
これは、ほとんどの言語に対して存在してて、言語ごとに別の言語サーバーがあるんや。「ここで間違った型を使ってるで」って教えてくれたり、エラーを出したり、定義にジャンプさせたり、コードの構造を理解してくれたりするんや。
言語サーバーは拡張機能で、TypeScriptの言語サーバーはTypeScriptの人らが開発してるし、Rustの言語サーバーはRustの人らが開発してるんや。
それらは全て言語サーバープロトコルを通じてVS Codeとインターフェースするんや。そうすることで、VS Code自体に全ての言語を組み込む必要がなくて、既存のコンパイラのインフラをリンティング目的で使えるんや。
これは、リンティングや定義へのジャンプ、使ってる正しい型を見るためのものなんや。そうや、型チェックもしてくれるし、参照を見つけることもできるんや。
大きなプロジェクトで作業する時は、これがないとめっちゃ大変やな。これがないと、大きなプロジェクトでコーディングするのはめっちゃ難しいんや。
カーソルの中で、その言語サーバープロトコルの通信がどう使われてるか、もう一回説明してくれへん？
VS Codeと同じように、プログラマーに見せるために使われてるんや。でも、アイデアとしては、同じ情報をモデルにも見せたいんや。
でも、ユーザーに影響を与えへん方法でやりたいから、バックグラウンドでやりたいんや。シャドーワークスペースのアイデアは、これを実現する一つの方法やったんや。
カーソルの別のウィンドウを隠れて起動するんや。エレクトロンでフラグを設定して、ウィンドウは存在するけど見えへようにするんや。
この隠れたウィンドウの中で... あかん、詳細を話しすぎて、コードをあんまり応答的にせん7つのことをしてもうたわ。我々は、ユーザーの環境を正確に反映させたいだけなんや。
Linux上やと、ファイルシステムをミラーリングして、AIにファイルに変更を加えさせることができるんや。AIはファイルレベルで操作してると思ってるけど、実際にはメモリに保存されてて、これを機能させるためのカーネル拡張を作れるんや。
MacとWindowsではちょっと難しいんやけどな。でも、これは面白い技術的な問題やから、そういうアプローチを取ったんや。
私が好きな、ちょっとハッキーやけど面白いアイデアの一つは、保存にロックをかけることや。
基本的に、言語モデルにディスクへの保存のロックを握らせるんや。そうすると、ディスクに保存された本当のファイルバージョンで操作するんやなくて、以前はシャドーワークスペースやったもので、メモリにだけ存在する未保存のもので操作できるんや。
それでもリンターのエラーは出るし、コーディングもできるんや。そして、コードを実行しようとすると、ロックがかかってるって小さな警告が出て、言語サーバーやシャドーワークスペースから同時に何かしようとしてる場合は、ロックを取り戻すことになるんや。
それはめっちゃワクワクする未来やな。ちなみに、モデルにファイルを変更させるのは、ちょっと怖いかもしれへんけど、めっちゃクールなことやと思うわ。エージェントに一連のタスクをやらせて、次の日に戻ってきて、同僚がやったみたいに観察できるんやからな。
そうやな。多分、実行可能性にもいろんなバージョンがあると思うわ。ユーザーがプログラミングしてる間に、数分の間にユーザーの代わりに簡単なことをする場合は、ユーザーのマシンでローカルに動かすのが理にかなってるやろうな。
でも、もっと長い時間がかかる大きな変更をする場合は、おそらくリモートのサンドボックス環境でやった方がええと思うわ。
それもまた、ユーザーの環境を正確に、あるいはほぼ正確に再現して、コードを実行するのに実質的に同等になるようにするのは、めっちゃ難しい問題やな。
コーディング用のエージェントにどんな能力を持たせたいんか気になるわ。バグを見つけてほしい？新機能を実装してほしい？どんなエージェントが欲しいんや？
ちなみに、エージェントについて考える時、コーディングだけやなくて、もっと広く考えてるんや。このポッドキャストの制作のために、ビデオ編集とかもあるやろ。
Adobeを見ると、背後にあるコードはめっちゃ poorly documented なんやけど、Premiereとかとコードでやり取りできるんや。YouTubeへのアップロードとか、私がやってること全部、翻訳やオーバーダビングも含めて、全部コードでできるって想像できると思うわ。
だから、直接編集に関係ないような多くのタスクを自動化することを想像してるんや。
コーディングに関しては、基本的にバグ発見を考えてるんや。いろんなレベルのバグ発見やな。論理的なバグとか... 論理的なバグやけど、精神的なバグじゃなくてな。実装の大きな方向性とか、そういうのも含めてな。
バグ発見についてどう思う？
そうやな、これらのモデルが、素直にプロンプトしただけではバグ発見がめっちゃ下手なのは面白いよな。めっちゃ calibration が悪いんや。一番賢いモデルでもな。そのとおりや。O1でもそうなんや。
なんでやと思う？何か直感的な説明はある？
これらのモデルは、事前学習の分布をめっちゃ強く反映してると思うんや。確かに、損失が下がれば下がるほど一般化すると思うけど、コードに関しては、損失やスケールがまだ十分に低くなくて、本当の意味での一般化までは至ってへんと思うんや。
我々がこれらの最先端モデルを使うのは、主にコード生成と質問応答やねん。これらは、GitHubにある全てのコードを何兆トークンもの規模で事前学習したり、Stack OverflowやGitHub Issuesの質問と回答を学習したりして、大量にあるからや。
そやから、本当に存在せえへんようなもんを押し込もうとすると、例えば、カーソルタップの目標みたいな、これまでの編集を見てこれからの編集を予測するっちゅうもんやと、脆弱性がちょっと見えてくるんや。バグ検出もええ例やな。実際のバグを見つけて修正案を出すっちゅう例があんまりないから、モデルがほんまに苦戦してまうんや。
でも、これは事前学習済みのモデルから転移学習する話やと思うんや。コード全般に対する事前学習済みモデルからカーソルタップの目標に転移するのと同じように、コードに強いモデルからバグ検出への転移も似たようなもんやと思うんや。
ちょっとそっち方向に押してやるだけでええんや。はっきり言うと、事前学習の段階でコードのことをかなり理解してると思うんや。構築された表現のどっかに、何かおかしなことが起こってるんちゃうかっちゅう認識はあるはずなんや。でも、それを「おかしい」って感じさせるのは難しいんや。
それに、人間はどのバグが本当に重要かっちゅうのをよう分かってるんや。単に「何かおかしい」っちゅうだけやのうて、これは些細なバグなんか、それともサーバーをダウンさせるレベルのバグなんかっちゅう判断が必要やねん。スタッフエンジニアがなんでスタッフエンジニアなんかっちゅう文化的な知識も関係してくるんや。
スタッフエンジニアは、3年前に誰かがサーバーをダウンさせるようなヤバイコードを書いたことを知ってるから優秀なんや。一方で、実験的なコードやったら、ちょっとくらいバグがあっても構わへんかもしれん。実験的なコードにバグがあるっちゅうのはモデルにとってはすごくうるさいことやけど、本番用のコードやったら、データベースとかLinuxとかのコードを書いてるような場合、エッジケースでもバグは許されへんのや。
ユーザーがどれくらい慎重になってるかっちゅうのを理解するのも大事やねん。でも、最大限の注意を払ってもまだ完璧にはできひんのや。
そうやな。人間でもどの行が重要かを理解するのは難しいんや。ウェブサイトの原則の一つに、もしコードが大きな被害を与える可能性があるなら、その行にコメントで「この行は危険や」って10回書くべきやっちゅうのがあるやろ。それはかなり深い意味があるんや。人間のことをよう表してるんや。エンジニアが入れ替わっても、同じ人間でも、一つの関数がタイタニック号を沈めるかもしれんっちゅうことを忘れてまうかもしれんからな。
単一のコードを見ただけやと、そこまで直感的に分かりにくいんや。そやな。それは今日のAIモデルにも言えることやな。危険や危険やって各行に書いとくと、モデルもそこに注目して、その領域のバグを見つけやすくなるんや。これはコードにどれくらいの被害を与える可能性があるかをラベル付けするええ習慣やと思うわ。
そうやな。議論の余地はあるかもしれん。見た目が汚くなるって思う人もおるやろ。実際、美的にはあんまり好きやないんやけど、モデルにとっても人間にとっても役立つことがあるんや。人間って忘れやすいからな。ちょっとしたミスでサーバーをダウンさせてまうこともあるんや。Go Firstの例みたいに、テストはたくさんするけど、それでも気をつけなあかんことはようけあるんや。
普通のドキュメント文字列やと、人間は変更するときにざっと読んで「分かってる」って思ってまうんや。だから、本当に注意を引くようにせなあかんのや。そうせんと見落としてまうからな。
大きな被害を与える可能性があるっちゅうことを思い出させなあかんのや。普通、そんなこと考えへんからな。どうやってこれを改善できるかは考えるけど、逆の方向、つまりこれがどんな被害を与えるかっちゅうことは、形式的な検証ができるようになるまでは考えへんのや。形式的な検証ができるようになったら、好きなようにできるし、証明が通れば絶対にバグを導入してへんっちゅうことが分かるんや。
具体的に、その未来はどんな感じになると思う？人々はもうテストを書かんようになると思うわ。モデルが仕様を提案して、それをレビューするだけになるんや。その間に、賢い推論モデルが実装が仕様に従ってるかどうかの証明を計算する。ほとんどの関数でそうなると思うわ。
これって、さっき話してたソフトウェアの意図を指定することの難しさに関係してくるんやないか？意図を指定するのが難しいから、それが本当に意図に合ってるかどうかを証明するのも難しくなるんやないか？
仕様を生成するのが難しいと思う？そうやな。仕様があったとしても、形式的な検証ができるかどうかっちゅう問題もあるな。そこにはもっと掘り下げる必要があると思うわ。でも、仕様があったとしても、その仕様はどうやって書くんや？自然言語で書くんか？
仕様は形式的なものになるやろうけど、それをどれだけ簡単に書けるかが問題やな。そしたら、仕様言語で簡単に指定できへんようなことも気にせなあかんようになるかもしれんな。
なるほどな。形式的な検証だけで全てが解決するわけやないっちゅう議論やな。
そうや。単体テストみたいなもんを置き換えるのは大変やと思うわ。確かにな。仕様言語を進化させて、今はできへんようなことも捉えられるようにできるかもしれんけど、分からんな。でも、すごくワクワクすることやと思うわ。
単一の関数だけやなくて、コードベース全体について話してるんやな。コードベース全体の方が難しいけど、それこそが欲しいもんや。可能やと思うわ。最近、ハードウェアレベルまで形式的に検証する研究もあるしな。Cコードを形式的に検証して、GCCコンパイラを通して、Verilogを通してハードウェアまで検証するんや。これはめっちゃ大きなシステムやけど、実際に機能してる。
大きなコードベースも似たようなもんやと思うわ。多層システムみたいなもんやからな。分解して各部分を形式的に検証できれば、可能やと思うわ。仕様の問題は本当の問題やけど、副作用とか外部依存性はどう扱うんや？StripeのAPIを呼び出すような場合は？StripeがAPIの仕様を書くかもしれんけど、全てに対してそれはできへんやろ。
全てに対してできるんか？言語モデルをプログラムの中でプリミティブとして使う場合はどうなる？それに依存してるのをどう取り込む？
それでも証明できるかもしれんな。言語モデルについて何を証明するんや？例えば、言語モデルが整列してるとか、正しい答えを出すってことを証明できるかもしれんな。
それが夢やな。そうやな。もし可能なら、それはAI安全性からバグ発見まで、全てのスペクトルをカバーする「I have a dream」スピーチみたいなもんやな。コードにバグがないことを確認することから、AIが人類文明を破壊せんことまで保証できるんや。
バグ発見にモデルが苦戦してるって言うてたけど、どんな希望があるんや？最初の希望は、そうやな。マイケルにも意見を聞きたいけど、まず愚かなバグを見つけるのを手伝うべきやと思うんや。すぐに愚かなバグを見つけるべきや。例えば、1つずれたエラーとかな。
コメントに書いたことと違うことをコードに書いてまうこともよくあるんや。これはめっちゃ一般的や。コメントに「より小さい」って書いてあるのに、コードでは「以下」になってたりするんや。モデルはそれを見て「これ、怪しいんちゃうか？本当にそうしたいんか？」って言うべきやな。でも、最終的にはもっと難しいバグも見つけられるようになるはずや。
そうやな。バグを見つけるモデルがええのを持つことは、AIにもっと多くのプログラミングをさせるための最高レベルに到達するために必要やと思うわ。AIがシステムのより多くの部分を構築してるなら、生成するだけやなくて検証もせなあかんからな。そうせんと、以前話したプログラミングのモデルに関する問題が耐えられんようになるわ。
つまり、人間のためだけやなくて、AIのコードを検証してチェックするのも重要なんや。
そうやな。でも、実際どうやってやるんや？バグモデルをどう訓練するかについて、めっちゃ議論してきたんや。
でも、人気のあるアイデアの一つは、バグを見つけるよりバグを導入する方が簡単やっちゅうことや。だから、既存のコードにバグを導入するモデルを訓練して、それから逆バグモデルを訓練できるんや。そしたら、この合成データを使ってバグを見つけられるようになるんや。これは一例やけどな。他にもアイデアはようけあるわ。
モデルレベルやなくて、最大のモデルを取って、コードだけやなくてもっと多くの情報にアクセスさせるっちゅう方法もあるんや。ファイルを見つめてバグを探すのは難しい問題やからな。人間にとってもそうやろ？
よく、コードを実行してトレースを見たり、デバッガーでステップ実行したりせなあかんやろ。そっち方向に進むこともできるんや。
二つの異なる製品形態があるかもしれんな。バックグラウンドで実行されて、バグを見つけようとする専門のモデルがあって、それはかなり高速やと。それから、アーヴィッドが前に言うてた悪意のある入力ボックスのバグみたいな、時々特定の問題を解決したいときがあるやろ。そんなときは、めっちゃ大量の計算力を使って、その問題を解決するためにバグを解決するのに50ドルとか、もっと使うかもしれんな。
このプロセス全体にお金を組み込むことについて考えたことある？バグを見つけたり、本当に好みのコードを生成してくれたりしたら、多分かなりの金額を払うと思うわ。数日前に、カーソルを使い始めて、YouTubeのAPIと相互作用するための完璧な3つの関数を生成したときのことを思い出すわ。字幕を更新したり、異なる言語でローカライズしたりするためのもんやった。
APIのドキュメントがあんまりよくなくて、Googleで検索しても正確な情報を見つけるのに時間がかかったんや。でも、カーソルが完璧に生成してくれたんや。コードを読んで、これは正しいって思って、テストしても正しかったんや。そのとき、ボタンを押して5ドルのチップを払いたいって思ったわ。会社をサポートし、インターフェースをサポートするためにな。
それに、これはめっちゃ強いシグナルになるやろ。よくやったっちゅうな。コードを受け入れるだけよりも、もっと強いシグナルやな。バグ発見に関しても、バグに対して大金を払う人はようけおるやろ。バグ報奨金みたいなもんやな。それについて考えたことあるか？
そうやな。会社の中では議論の余地があるアイデアやな。どれだけ人類を信じるかにもよると思うわ。
例えば、バグを見つけようとするのに何も払わんでええようにして、バグが見つからんかったら0ドルやけど、バグが見つかって受け入れたら、かっこして(1ドル)って表示して、バグを受け入れるのに1ドル払うようにするのはどうや？もちろん、計算にめっちゃコストがかかるから、人々がコピペするだけになるんちゃうかって心配もあるな。
それに、製品にお金を導入すると、なんか楽しくなくなるんちゃうかって心配もあるわ。お金のことを考えなあかんようになって、コードのことだけ考えたいのに。だから、月額制にして、全部無料で使えるようにする方がええかもしれんな。でも、チップ機能はあってもええかもしれんな。
ドル記号はあってもええと思うけど, 導入せん方がええっちゅう意見もあるかもしれんな。
そうやな。人々がこれをするタイミングは、素晴らしい例を友達と共有するときやと思うわ。
技術的な解決策もあるかもしれんな。この名誉システムの問題に対してな。システムの出力をもっと理解できるようになれば、LSPでのエラーチェックやコードの実行みたいなことができるようになるかもしれん。実際にバグを修正したことを確認できるようになれば、報奨金システムが名誉システムに頼る必要がなくなるかもしれんな。
ターミナルとコードの間にどれくらいの相互作用があるんや？ターミナルでコードを実行して得られる情報はどれくらいあるんや？コードを実行して、エラーが出たらコードを変更するような提案をするループができるんか？
今のところ、完全に別の世界やな。ターミナル内でControl Kを使ってコードを書くのを助けることはできるし、ターミナルのコンテキストも使えるんやけどな。でも、ループの部分はまだないんや。
将来的にはそういうのが意味を持つかもしれんな。フォアグラウンドでやるか、バックグラウンドでやるかは問題やけど。バックグラウンドでやるのはかなりクールやな。コードを違う方法で実行するし、データベース側の問題もあるしな。データベースを変更せずに保護するにはどうすればええんや？まあ、確かにクールなソリューションはあるやろうな。
新しいAPIが開発されてるんや。AWSじゃないけど、確かPlanet Scaleが最初に追加したと思うんやけど、データベースにブランチを追加する機能やな。ある機能の作業をしてて、本番のデータベースに対してテストしたいけど、実際には本番のデータベースに対してテストしたくない場合に、データベースにブランチを追加できるんや。
やり方としては、先行書き込みログにブランチを追加するんや。もちろん、正しくやるには技術的な複雑さがあるんやけどな。データベース企業は今、データベースでやることが新しく必要になってきてるんやな。
TurboBufferっちゅう、うちが使ってるデータベースの一つも、先行書き込みログにブランチング機能を追加する予定やと思うわ。だから、AIエージェントがブランチングを使って、何かブランチに対してテストするようになるかもしれんな。データベースがブランチングをサポートするのが要件になるかもしれんな。
ファイルシステムをブランチできたらおもろいやろうな。
そやな。全てにブランチングが必要やと思うわ。
うん、それが多元宇宙の問題やな。全てをブランチすると、めっちゃ多くなるからな。
もちろん、実際には空間やCPUを多く使わんようにする超賢いアルゴリズムがあるんやけどな。
ええとこで基盤の話をしてもええか？主にAWSを使ってるんやろ？何か面白い詳細とか、興味深い課題はあるか？なんでAWSを選んだん？なんでAWSがまだ勝ってるんや？
AWSはほんまにええんや。めっちゃええ。AWSの製品を使うと、絶対に動くって分かるんや。セットアップの手順を踏むのは地獄かもしれんけど。
インターフェースがなんであんなにひどいんや？
勝ってるからやな。それが勝つ性質なんや。
そうやな。AWSは常に信頼できるんや。常に動くし、問題があったら、たぶん自分の問題やと分かるんや。
新しいスタートアップとして、多くの人にスケールするのに興味深い課題はあるか？
そうやな、毎秒のリクエスト数に0を追加していくのは面白い旅やったな。キャッシングやデータベースに使う一般的なコンポーネントで、大きくしていくと問題が出てくるんや。今ではテーブルでオーバーフローが起こるくらいの規模になってるな。
それに、コードベースのセマンティックインデックスを計算して質問に答えるための検索システムみたいな、カスタムシステムを作ったんやけど、それをスケールするのが常に難しかったな。
めっちゃ優秀なエンジニアの友達がおるんやけど、そいつらの言葉の一つに、システムがどこで壊れるかを予測するのはめっちゃ難しいってのがあるんや。事前に予測しようとしても、0を追加したときに何か変なことが起こるんや。全てを考えたつもりでも、実際には全てを考えてへんのや。
でも、その特定のシステムについて言うと、具体的にはこんなことをしてる。コードを全部チャンクに分けて、エンベッディング用にコードを送って、コードをエンベッドして、エンベッディングをデータベースに保存するんや。でも、コード自体は保存せえへん。
クライアントのバグを導入せんようにするために、めっちゃ慎重になってるんや。ほとんどの詳細はサーバーに保存して、全て暗号化してる。技術的な課題の一つは、ローカルのインデックスとローカルのコードベースの状態が、サーバーの状態と同じであることを常に確認することや。
技術的には、こんな感じでやってる。各ファイルにハッシュを保持して、各フォルダーにも、その子要素全てのハッシュのハッシュを保持するんや。これを再帰的にトップまでやるんや。
なんでこんな複雑なことをするかって？一つの方法は、全てのファイルにハッシュを保持して、1分ごとにサーバーのハッシュをダウンロードして、サーバーに存在せえへんファイルを見つけるっちゅうやり方やな。新しいファイルを作ったり、ファイルを削除したり、新しいブランチをチェックアウトしたりして、クライアントとサーバーの状態を調整しようとするんや。
でも、これはネットワークのオーバーヘッドがめっちゃ大きくなるんや。クライアント側でもWiFiを常に使うことになるし、データベース側でも、数十テラバイト、20テラバイトくらいのデータベースを毎秒読み取ることになるんや。それはめっちゃクレイジーやな。絶対にそんなことはしたくないわ。
そやから、どうするかって言うと、プロジェクトのルートにある単一のハッシュだけを調整しようとするんや。何かが一致せえへかったら、どこが一致せえへんのかを見つけて、子要素のハッシュが一致するかどうかを見て、一致せえへかったらその子要素を見ていくんや。でも、これは一致せえへん場合だけやで。ほとんどの人にとって、ほとんどの場合、ハッシュは一致するんや。
階層的な調整みたいなもんやな。
そうやな。マークルツリーっちゅうんや。
そうやな。こういう問題を全部考えなあかんっちゅうのがわかるな。難しくなってきた理由は、使う人の数が増えたからやな。顧客の中には、めっちゃ大きなコードベースを持ってる人もおるんや。
最初は自分たちのコードベースを再編成したんやけど、それは大きいけど、20年も続いてる会社のファイル数とは比べ物にならんのや。それをプログラマー全体にスケールせなあかんのや。単純なものを作るのは簡単やけど、多くの人、多くの会社にスケールするのは難しい問題やな。
これはスケーリングの一部やけど、新しいアイデアも考えてる。最近数週間、数ヶ月はそれをスケールすることに取り組んでるんや。
このインデックスシステムには、他にもええ工夫があるんや。例えば、コストのボトルネックはベクトルデータベースやデータベースに物を保存することやないんや。実際はコードをエンベッドすることなんや。
会社の全員が同じコードを使ってて、ちょっと違うブランチにいたり、ちょっとローカルで変更してるだけやったら、コードベースを全員分再エンベッドしたくないよな。エンベッディングがボトルネックやから、ええ工夫として、与えられたチャンクのハッシュから計算されたベクターのキャッシュを持つんや。
これで、会社のn番目の人がコードベースをエンベッドするときに、めっちゃ速くなるんや。しかも、これを全部、サーバーに一切コードを保存せずにやってるんや。ベクトルデータベースとベクトルキャッシュにベクトルだけを保存してるんや。
コードベースのインデックス作成から得られる最大の利点は今のところ何や？ちょっと気になってな。長期的にはもっと多くの利点があると思うけど、短期的には、コードベースに質問するだけで、どんな利点があるんや？
一番明らかなのは、大きなコードベースの中で何かが起こってる場所を見つけたいときやな。Xをやってる場所を見つけたいけど、普通のテキスト検索で何を検索したらええか正確には分からんっちゅう場合やな。
そんなときに、コマンドエンターを押してコードベースチャットで聞くと、よく探してた場所を見つけてくれるんや。
おっしゃる通り、将来的にはもっと強力になると思うわ。検索の質を改善するのにめっちゃ取り組んでるし、その上限は人々が思ってる以上に高いと思うわ。
ここでええ質問があるな。ローカルでやることを考えたことはあるか？なんで今までほとんどローカルでやってへんのか？今話したことの全ては、クラウドに行くのがめっちゃ難しそうやし、キャッシングとか、大きなコードベースを大勢のプログラマーが使うとかのパズルを考えなあかんやろ。
ほとんどのソフトウェアは、こんな重い計算をローカルでやってるやん。ローカルでエンベッディングすることを考えたことはあるか？
そうやな、考えたことはあるし、ローカルでやるのはクールやと思うわ。でも、めっちゃ難しいんや。一つ考えなあかんのは、ユーザーの中には最新のMacBook Proを使ってる人もおるけど、80%以上のユーザーはWindows機を使ってて、その多くはそんなに性能がええわけやないんや。
だから、ローカルモデルは最新のコンピューターでしか動かへんのや。それに、それを組み込むのはめっちゃ大変なオーバーヘッドになるんや。だから、やりたくても今は集中できへんのや。
それをやってる人もおるし、それはええことやと思うわ。でも、モデルがどんどん大きくなって、もっと複雑なことをしようとすると、ローカルでやるのはもっと難しくなるんや。
そうやな。性能の低いコンピューターの問題やないんや。例えば、大企業のコードベースを持ってる場合、最高性能のMacBook Proでも処理するのはめっちゃ難しいんや。学生とかの話やなくて、大企業の一流プログラマーでも、全部ローカルでやったらひどい経験になるんや。エッジでやってなんとかなるかもしれんけど、もう楽しくなくなるやろな。
そうやな。巨大なコードベースで近似最近傍探索をやったら、メモリもCPUも食い潰してまうわ。それに、モデリングの面でも、ローカルモデルに対する大きな逆風があるんや。
一つは、混合専門家（MOE）の方向に進んでるってことやな。これの利点の一つは、メモリ帯域幅に制約されるようになるから、GPUを使うよりもローカルに有利になるかもしれんってことや。でも欠点は、これらのモデルは全体的にもっと大きくなって、単一のノードどころか、複数のノードにも収まらんようになるかもしれんってことや。
めっちゃ性能のええMacBookでも絶対に収まらへんやろな。特にコーディングの場合、モデルが十分良くなったらそれで満足っちゅう問題やないんや。他の問題ではそれでええかもしれんし、ローカルモデルが輝くところかもしれんけど、人々は常に最高の、最も知的で、最も能力のあるものを求めるんや。そんなもんを殆どの人がローカルで実行するのは本当に難しいんや。
最高のモデルが欲しいんやろ？ソネットが欲しいんやろ。
おう、そうやな。ようセールスしてくれるな。劣ったモデルで満足するか？まあ、聞いとくわ。そうやな。僕はそういう人間やけど、ローカルでやりたがる人もおるんやな。特にオープンソース運動の人らは力の集中に抵抗したがるし、それはええことやと思うわ。
ローカルモデルの代わりになるもので、僕が特に好きなのがあるんや。まだ研究段階やけど、言語モデルの推論に準同型暗号を使うっちゅうアイデアや。ローカルマシンで入力を暗号化して、それを送信するんや。そしたらサーバーは、ローカルでは実行できへんようなモデルを、この暗号化されたデータに対して損失のない計算で実行できるんや。でもデータの中身は見えへん。答えを送り返して、ユーザーだけが復号できるんや。
これはまだ研究段階やけど、オーバーヘッドを下げることが全てやな。今はオーバーヘッドがめっちゃ大きいからな。でも、これが実現できたら本当にクールやと思うし、めっちゃ影響力があると思うわ。
これらのモデルがどんどん良くなっていくと、経済的にもっと有用になって、世界の情報やデータがどんどん1,2の中央集権的なアクターを通るようになるのが、ちょっと心配なんや。
従来のハッカー攻撃の試みもあるけど、世界の全ての情報が1つのノードを平文で通るっちゅうのは怖い状況を作り出すんや。監視が非常に悪い方法で行われる可能性があるんや。
最初は良い理由からスタートするんや。AIモデルを悪用する悪いアクターから守ろうとするんや。そして監視コードを追加して、そしたら誰か他の人が来て、知らん間にスリッピーな坂を滑り落ちて、世界のデータの大部分を悪用し始めるんや。
だから、言語モデルの推論に準同型暗号を解決できることを本当に期待してるわ。プライバシーを保護する機械学習をやな。でも、これは今日のソフトウェアが全て直面してる課題やと思うわ。クラウドから提供される機能がめっちゃ多くて、みんながそれに頼るようになってめっちゃ便利になってるけど、欠点もあるんや。
だから、基本的な攻撃から守るためにめっちゃ良いセキュリティに頼ってるんやけど、そのデータを制御してる企業は少数やし、彼らには影響力があるし、色んな方法で侵入される可能性もあるんや。これが今の世界なんや。
実際に僕が心配してるのは、AnthropicがResponsible Scaling Policyっちゅうのを持ってて、低いASL（Anthropic Security Level）のモデルを使ってる世界なんや。でも、Code ASL 3とかCode ASL 4みたいな、めっちゃ強力やけど、まあ妥当なセキュリティ上の理由で全てのプロンプトを監視したくなるようなモデルになったらどうなるんやろ。
これは妥当で理解できる考え方やと思うけど、世界中の情報がそんなに厳しく監視されるのはめっちゃ恐ろしいことやと思うわ。中央集権化しすぎてるんや。これはめっちゃ微妙な線を歩いてるんや。一方ではモデルが暴走するのを防ぎたいし、他方では人間のな。全ての世界の情報が3つのモデルプロバイダーを通過するのを信用できるかどうか分からんのや。
なんでクラウドプロバイダーと違うと思うん？このデータの多くは、そもそもクラウドプロバイダーには行かへんかったと思うんや。これはしばしば、AIモデルにもっとデータを与えたいっちゅうことやからな。オンラインに絶対置かへんような個人データを、これらの企業やモデルに与えたいんや。
また、制御も中央集権化するんや。今のクラウドなら、自分の暗号化キーを使えるし、AWSもあんまり何もできへん。でも、ここでは中央集権的なアクターが全てのプレーンテキストを正確に見れるんや。
コンテキストの話やけど、実際これが僕にとって摩擦になってるんや。Pythonでコード書いてるとき、色んなものをインポートしてるやろ。コンテキストに含めたいものは想像できると思うんやけど。コンテキストを自動で把握するのはどれくらい難しいんや？
難しいな。将来的には自動でコンテキストを計算するのをもっと上手くできると思うわ。でも、自動コンテキストを含めるにはトレードオフがあるんや。
これらのモデルにとって、コンテキストを多く含めれば含めるほど、まず遅くなるし、リクエストのコストも高くなるんや。そしたら、モデルの呼び出し回数が減って、バックグラウンドで凝ったことができなくなるんや。
また、多くのモデルは、プロンプトに多くの情報があると混乱してまうんや。だから、含めるコンテキストの正確性と関連性の基準はかなり高くなるべきなんや。
でも、製品の中では既にいくつかの場所で自動コンテキストを使ってるんや。これは絶対にもっと良くしたいと思ってるし、試すべきクールなアイデアがようけあると思うわ。
より良い検索システムを学習するっちゅうのもあるし、より良いエンベッディングモデルや再ランク付けモデルもあるな。学術的なアイデアもあって、内部で試してみたり、この分野全体で取り組んでるものもあるんや。例えば、言語モデルを新しい情報の集まりを理解できるところまで持っていけるかっちゅう問題やな。
これの一番人気のある話題は、コンテキストウィンドウを無限にできるかっちゅうことや。コンテキストウィンドウを無限にできたら、モデルに実際に無限のコンテキストに注目させられるか？そして無限のコンテキストに注目させられたら、それを実行可能にできるか？そして、その無限のコンテキストを毎回再計算せんでもええようにキャッシュできるか？
他にも試されてるクールなアイデアがあって、ファインチューニングに近いもんや。実際にこの情報をモデルの重みに学習させるんや。コンテキスト内学習レベルでやるよりも、重みレベルでやる方が質的に異なる理解が得られるかもしれんのや。
これがどう動くかについては、まだ結論が出てへんと思うわ。でも、それまでの間、我々の会社としては、より良い検索システムと、やってることに最も関連するコードベースの部分を選ぶことにめっちゃワクワクしてるんや。もっと上手くできると思うわ。
この知識を直接重みに学習させる面白い概念実証の一つが、Visual Studio Codeにあるんや。我々はVS Codeのフォークを使ってるけど、VS Codeのコードは全て公開されてるんや。だから、これらのモデルは事前学習でこのコード全部を見てるし、おそらくそれに関する質問と回答も見てるんや。
そして、一般的にコードに関する質問に答えられるようにファインチューニングやRLHFされてるんや。だから、VS Codeについて質問すると、時々妄想することもあるけど、結構うまく答えられることもあるんや。
これは単に偶然うまくいってるだけやと思うんやけど、もしこのコードベースを本当に理解するように特別に訓練したり、ポスト訓練したりしたらどうなるやろ？これは面白い研究課題で、我々もめっちゃ興味あるんや。
それに、モデルが全てを端から端まで行うべきか、つまり検索からその内部で質問に答えて、コードを作成するまでを行うべきか、それとも検索をフロンティアモデルから分離すべきかっちゅう不確実性もあるんや。
数ヶ月後には、最高のオープンソースモデルよりもずっと優れたモデルが出てくるかもしれんし、そしたら、これらの大規模なモデルにコンテキストを与えるための検索を行う、本当に優れたオープンソースモデルを別に訓練したいかもしれんのや。
コードベースを理解するためのモデルのポスト訓練について、もう少し詳しく教えてくれへん？それは合成データを使う方向なんか？
そうやな、やり方はようけあると思うわ。アイデアは山ほどあるんや。問題は、実際にそれらを試して、どれが一番うまくいくか経験的に確かめることやな。
一つの素朴なアプローチは、VS Codeとこれらのフロンティアモデルでやってることを再現しようとすることやな。一般的なコードデータを含む事前学習を続けつつ、特定のリポジトリのデータもたくさん入れるんや。
そして、ポスト訓練、つまり指示微調整から始めるんや。コードに関する普通の指示微調整データセットを用意して、そのリポジトリのコードに関する質問をたくさん追加するんや。
ground truthのデータを集めるのは難しいかもしれんから、さっき言うたみたいに合成データを使うこともできるんや。つまり、コードの各部分について、モデルに質問を提案させたり、その部分のコードに対する質問を提案させたりして、それらを指示微調整のデータポイントとして追加するんや。
理論的には、これでモデルがそのコードベースに関する質問に答える能力が開放されるかもしれんのや。
OpenAI 01についてどう思う？プログラミングにおいて、そのようなテスト時計算システムの役割はどうやと思う？
テスト時計算はめっちゃ面白いと思うわ。事前学習のレジームがあって、データ量とモデルサイズを拡大すると、損失と下流のベンチマーク、そして我々がコーディングやその他のタスクに使うときの一般的なパフォーマンスが良くなるんや。
でも、データの壁にぶつかり始めてるんや。つまり、このレジームを拡大し続けるのが難しくなってきてるんや。だから、テスト時計算を拡大するのは、推論時のflop数を増やしつつ、これらのモデルのパフォーマンスを向上させる面白い方法なんや。
従来は、文字通り大きなモデルを訓練して、常にそれだけ多くのflopを使う必要があったんや。でも今は、同じサイズのモデルを使って、より長く実行することで、もっと大きなモデルと同じ品質の答えを得られる可能性があるんや。
これの本当に面白いところは、100兆パラメータのモデルの知能を持つ必要がある問題もあるかもしれんけど、それはたぶん全クエリの1%か0.1%くらいやろ。そんな巨大なモデルを訓練するのに全ての努力を費やして、めったに実行せえへんのは完全に無駄やと思えへん？
その代わりに、99.9%のクエリをこなせるモデルを訓練して、本当に最高の知能が必要な少数の人のために、推論時により長く実行する方法を用意するんや。
どの問題にどのレベルの知能が必要かをどうやって判断するんや？それを動的に判断するのは可能なんか？
そうやな、それは未解決の研究問題やな。誰も本当にこのモデルルーティングの問題をうまく解決できてへんと思うわ。カーソルタブみたいなものに対しては、初期的な実装はあるんやけど、ソネットから01に移行するレベルになると、ちょっと難しくなるんや。
それに、レベル4のモデルには難しすぎる問題かどうかを判断するのに、どのレベルの知能が必要かっちゅう問題もあるんや。たぶん01レベルのモデルが必要になるかもしれん。はっきりせえへんな。
でも、これは事前学習のプロセスがあって、ポスト訓練があって、テスト時計算があるっちゅう話やったな。これらは別々のもんなんか？一番大きな利点はどこにあるんやろ？
奇妙なのは、テスト時計算を機能させるには、全く別の訓練戦略が必要なんや。さらに奇妙なのは、大きな研究所の外部の人間、たぶんOpenAI以外の人間は、それがどう機能するのか本当に分かってへんのや。
どんなことをしてるかのヒントを示すような面白い論文はあるんやけど、まあ、たぶん彼らは過程報酬モデルを使ってツリー検索をしてるんやないかな。でも、正確にどうなってるかは分からへんから、どこに当てはまるかを言うのは難しいんや。
ポスト訓練に入れると思うけど、たぶんこの種のテスト時計算をモデルに機能させるための計算量は、最終的に事前学習を圧倒するかもしれんな。
01が単に思考連鎖RLを使ってるのか、これらをどう使ってるのか、我々は何も知らんのやな。
何も知らんな。推測するのは楽しいけどな。もし競合するモデルを作るとしたら、どうする？
そうやな。一つやるべきことは、たぶん過程報酬モデルを訓練することやと思うわ。報酬モデルと結果報酬モデルと過程報酬モデルについて話せるかもしれんな。
結果報酬モデルは、言語モデルに対して訓練される従来の報酬モデルで、最終的なものだけを見るんや。例えば、数学の問題を解いてる場合、全部終わった後の最終的なものを見て、それに点数をつけるんや。これが結果やな。
過程報酬モデルは、思考の連鎖に点数をつけようとするんや。OpenAIは去年の夏くらいに、人間のラベラーを使って思考の連鎖に点数をつける大規模なデータセット、数十万件くらいのデータセットを作る予備的な論文を出したんや。
結局のところ、過程報酬モデルの面白い使い方は、たくさんのサンプルの中から選ぶための手段として使うこと以外に見たことがないんや。これらの論文で人々がやってることは、言語モデルからたくさんの出力をサンプリングして、過程報酬モデルを使ってそれらの生成に点数をつけるんや。他のヒューリスティクスと一緒に使って、最良の答えを選ぶんや。
本当に面白くて、人々が機能してほしいと思ってることは、これらの過程報酬モデルを使ったツリー検索やな。思考の連鎖の各ステップを本当に評価できるなら、分岐して思考の連鎖の複数の経路を探索し、過程報酬モデルを使ってどのブランチが良いかを評価できるんや。
そうやな、ブランチの質が最終的な結果の質と強く相関してる場合にな。つまり、どのブランチを選ぶべきかの良いモデルを持ってるってことやな。短期的だけやなくて長期的にもな。
そうやな、面白い研究は、過程報酬モデルをより自動化された方法で適切に訓練する方法を見つけることやと思うわ。間違ってるかもしれんけど、過程報酬モデルを創造的に使ってツリー検索をするのに本当にうまく機能するものは見たことがないんや。
これはちょっとAI安全性の話題かもしれんし、哲学的な質問かもしれんな。OpenAIは思考の連鎖をユーザーから隠してるって言うてるんや。それは難しい決定やったって言うてる。思考の連鎖を見せる代わりに、モデルに思考の連鎖を要約させてるんや。
彼らは裏で思考の連鎖を監視して、モデルがユーザーを操作しようとしてへんか確認するって言うてるんや。これは面白い可能性やな。でも、とにかく、思考の連鎖を隠すことについてどう思う？
OpenAIの一つの考慮事項、これは完全な推測やけど、人々がモデルからこれらの能力を抽出するのを難しくしたいんやないかな。もし隠された思考の連鎖にアクセスできたら、技術を複製するのがもっと簡単になるかもしれんのや。最終結果に至るまでのモデルのステップを見るのは、かなり重要なデータやからな。そのデータで訓練することもできるやろうな。
これに似たような状況が、大規模言語モデルプロバイダーの一部であったんや。これも推測やけど、以前はこれらのAPIで、生成してるトークンの対数確率や、プロンプトトークンの対数確率に簡単にアクセスできたんや。でも、一部のAPIはそれらを削除したんや。
これも完全な推測やけど、一つの考えは、対数確率にアクセスできると、この隠された思考の連鎖と同じように、これらの最大のモデルから能力を抽出しようとする際に、より多くの情報を得られるからやないかな。
そうそう、さっきの01の統合の話にもアスタリスクをつけとかなあかんな。まだこのモデルの使い方を学んでる最中なんや。カーソルで01を利用可能にしたのは、モデルを手に入れたときに本当に試してみたかったからや。多くのプログラマーが試してみたいと思うやろうしな。
でも、01はカーソルのデフォルトの体験の一部には全くなってへんのや。まだそうする方法を見つけられてへんのや。エディターに統合する方法を見つけられてへんし、毎時間、毎日のように使うようなものにはなってへんのや。
だから、このモデルの使い方については、まだ判断が出てへんのや。人々がリリースしたもので、「ああ、これが使い方やな」ってはっきり分かるような例を見てへんのや。
明らかなのは、これでバックグラウンドで動くものを持つのが簡単になるかもしれんってことや。これらのモデルをループで使ったり、これらのモデルをGen Techにしたりするのが簡単になるかもしれんな。でも、まだ発見中なんや。
はっきり言うと、アイデアはあるんや。ただ、本当に役立つものを作って、それを出す前に試してみる必要があるんや。でも、重大な制限もあるんや。能力は置いといても、ストリーミングせえへんのや。そのせいで、出力を監督したい場合にめっちゃ使いにくくなるんや。その代わりに、テキストの壁が現れるのを待たなあかんのや。
また、テスト時計算と検索の初期段階って感じがするんや。まだまだv0って感じで、いろんなことがしっくりこえへんのや。事前学習データとモデルサイズを増やしたり、そこでのトリックを見つけたりするのと並行して、検索をどんどん上手く機能させるっちゅう別の流れができると思うわ。
ところで、GitHub Copilotが01を何らかの形で統合しそうやっちゅう噂があるんやけど、どう思う？コメントの中には「これでカーソルは終わりや」って言うてる人もおるみたいやで。「カーソルを閉鎖する時が来た」っちゅうコメントも見たわ。ほんまにカーソルを閉鎖する時が来たんか？
このスペースは2010年代の過去のソフトウェアスペースとはちょっと違うと思うわ。ここでの上限はめっちゃ高いんや。だから、3~4年後の最高の製品は、今日の最高の製品よりもずっと有用になると思うわ。
堀や、ブランドや、これが我々の優位性やとか言うてられるけど、結局のところ、製品のイノベーションを止めたら負けるんや。これはスタートアップにとってもええことやし、この市場に参入しようとしてる人にとってもええことやと思うわ。
時間がようけあるってことやからな。既にユーザーをようけ持ってる人に勝つチャンスがあるんや。ただ、より良いものを作ればええんや。だから、これからの数年は、最高の製品、最高のシステムを作ることが大事やと思うわ。
それはモデリングエンジン側のことでもあるし、編集体験のことでもあるんや。
そうやな。カーソルが他のものと比べて価値があるのは、単に01みたいな新しいモデルを速く統合することやないんや。製品のあらゆる面で働いてる、気づかへんうちに働いてるカスタムモデルから来てるんや。それに、全ての機能に対する本当に思慮深いUXからも来てるんや。
ほんならもっと深いところに降りていこか。合成データの分類法について言及したよな。それについて説明してくれへん？
そうやな。主に3種類の合成データがあると思うわ。まず、合成データって何やねんって話やけど、普通のデータ、つまり非合成データは自然に作られたデータのことや。通常は人間が何かをしたことから生まれるデータのことやな。
で、合成データの1つ目は蒸留や。言語モデルにトークンやトークンの確率分布を出力させて、それを使ってより能力の低いモデルを訓練するんや。このアプローチでは、元のモデルより能力の高いモデルは得られへんけど、高価で遅延の大きいモデルから何か能力を引き出したい場合にめっちゃ役立つんや。
2つ目は、問題の一方向が逆方向より簡単な場合や。いい例がさっき話したバグ検出やな。バグを検出するよりも、もっともらしいバグを導入する方が簡単なんや。これは人間にも言えることやと思うわ。
だから、そんなに賢くないモデルを使って、コードにたくさんのバグを導入して、それを使ってバグを検出するのがめっちゃ上手いモデルを訓練できるんや。
最後のカテゴリーは、大きな研究所が合成データに使ってるメインのものやと思うんやけど、簡単に検証できる文章を言語モデルで生成することや。
極端な例を挙げると、シェイクスピアレベルの言語かどうかを検出できる検証システムがあって、タイプライターをたたくサルがようけおるとするやろ。最終的には、シェイクスピアレベルの言語モデルを訓練するのに十分なトレーニングデータが得られるんや。
これは特に数学の場合にめっちゃ当てはまるんや。形式言語の検証は実際にめっちゃ簡単やからな。だから、まあまあのモデルに大量のロールアウトを生成させて、実際に真の定理を証明したものを選んで、さらに訓練するんや。
コードでも似たようなことができるんや。LeetCodeみたいな問題で、これらのテストに合格したら実際に問題を解決したってことが分かるようなテストのセットがあるとするやろ。同じように、テストに合格したかどうかを確認して、合格した出力でモデルを訓練するんや。
でも、これを全てのドメインで機能させるのは難しいと思うわ。一般的に、モデルに与える雑多な長期的なタスクに対して完璧な検証器を持つのはめっちゃ難しいんや。コーディングでさえも難しいんや。
アーヴィッドほど楽観的やないんやな。
そうやな。その3つ目のカテゴリーは検証器が必要やな。
検証は、それが正しいって確実に分かってる場合が一番ええと思うわ。言語モデルを使って検証するんやなくて、テストや形式的なシステムを使うんや。
または実際に実行してみるとかな。人間が行う検証の形式で、手動で品質管理するみたいな。
そうやな。言語モデルバージョンは、実際に実行して出力を理解するみたいな感じやな。
その中間くらいやな。
うん。たぶんこのカテゴリーが最も大きな利益をもたらす可能性が高いと思うわ。
RLHFとRLAIFのフィードバック側はどうなん？モデルのパフォーマンスを向上させるのにどんな役割があるんやろ？
そうやな。RLHFは、人間からのフィードバックを収集したラベルから訓練した報酬モデルを使うんや。
これは、気にしてるタスクの種類に対して大量の人間からのフィードバックを得られる場合に機能するんや。
RLAIFは面白いんやけど、検証が生成よりもかなり簡単やっちゅう制約に依存してるんや。言語モデルを使って言語モデルの出力を見て、言語モデルを証明するみたいに見えるかもしれんけど、実際には言語モデルが解決策を検証するのが生成するよりもずっと簡単な場合に機能するかもしれんのや。そしたら、この種の再帰的なループが実際に機能するかもしれんな。
正確にそんな感じにはならんと思うけど。他にできることとして、RLAIFとRLHFを少し混ぜるみたいなこともあるんや。通常、モデルは2つの可能な生成のうちどちらが良いかを選ぶのにかなり正確なんや。これはカーソルタブの場合やけどな。
そして、50から100例程度の人間からの少しの nudging だけで、モデルが持ってる事前分布を、まさに欲しいものに合わせることができるんや。これは通常のRLHFとは違うんや。普通、RLHFではこれらの報酬モデルを大量の例で訓練するからな。
生成と検証、あるいは生成とランク付けを比較したときの直感はどうや？ランク付けは生成よりもずっと簡単なんやろか？
直感的には、そうやと思うわ。これはPがNPに等しくないって信じるなら、証明が与えられた場合に検証するのが、実際に証明するよりもずっと簡単な問題のクラスがめっちゃ大きいってことになるんや。
AIがPがNPに等しくない、あるいは等しいって証明するんやないかな。それはめっちゃクールやな。
フィールズ賞か何かやな。誰が賞を受け取るんやろ？これも面白い哲学的な問題やな。
プロンプトした人やろな。
実は、AIがフィールズ賞を取るのはいつ頃になるかっちゅうのに、めっちゃ興味があるんや。
これ、アモンの専門やないんか？
ノーベル賞かフィールズ賞、どっちが先やと思う？
フィールズ賞レベルやな。フィールズ賞の方が先やと思う。
フィールズ賞が先やな。
そうやな。フィールズ賞が先やと思う。
そら、そう言うやろな。でも、これは孤立したシステムで検証できるし。
いや、いや。
確かに。IMOにたどり着く道筋の方が、ちょっと明確やったと思うわ。すでにいくつかのIMO問題を解けてたし、その時点での文献を見ると、人々が取れる戦術についての低く垂れ下がった果実がたくさんあったからな。
今は、定理証明の分野についてあんまり詳しくないし、これらの本当に難しい未解決問題を解くのにどれくらい近づいてるかについての直感もあんまりないんや。
じゃあ、フィールズ賞が先やと思うんか？物理学とかの分野じゃなくて。
間違いなくそうやと思うわ。たぶんそっちの方が可能性が高いと思うわ。
そうやな、そうやな。
そうやな。例えば、BSDつまりバーチ・スウィンナートン＝ダイアー予想とか、リーマン仮説とか、そういう本当に難しい数学の問題は、ほんまに難しいんや。解決への道筋がどんなもんかさえ、はっきりせえへんのや。道筋がどんなもんか分からへんのに、どうやってそれを実現するかなんて分からへんやろ。
これが孤立したシステムで、実際に良い報酬システムを持ってて、そのために訓練するのが簡単やっちゅうアイデアは信じへんのか？
AGIの前にフィールズ賞を取れると思うわ。
そうか。めっちゃ嬉しいわ。でも、そこまで確信はないな。2028年か2030年くらいやと思う。
フィールズ賞やな。
フィールズ賞な。
物事の進み方を考えたら、まだまだ先の話に感じるな。
物事の進み方と言えば、スケーリング則について話そか。スケーリング則って何なんか、知らん人のために説明してくれへんか？今どうなってると思う？これからどうなると思う？
面白いのは、OpenAIが最初に出したスケーリング則の論文が、学習率のスケジュールの問題で少し間違ってたんやな。それでチンチラが、より正しいバージョンを示したんや。
そこから人々は、計算最適なことをするのからちょっと外れ始めたんや。今は、与えられた推論予算で本当にうまく機能させることに、より最適化し始めてるんや。
これらの曲線には、最初に使ってた計算量、パラメータ数、データ量以外にも、もっと多くの次元があると思うわ。推論計算量は明らかな一つやな。コンテキスト長も明らかな一つやと思うわ。
例えば、推論計算量とコンテキストウィンドウの2つを気にするなら、たぶん訓練したいのはSSMみたいなものやと思うわ。これらはめっちゃ長いコンテキストに対して、はるかに安くて速いからな。
たとえ訓練中のスケーリング特性が10倍悪くても、つまり同じ長さを得るのに10倍の計算量が必要になっても、本当に長いコンテキストウィンドウに対する推論予算を最も気にするなら、それだけの価値があるんや。
だから、人々がこれら全ての次元でどう遊ぶかは面白いと思うわ。
そうやな。複数の次元について話してくれたけど、元々の考え方は、パラメータ数で測ったモデルのサイズと、トークン数で測ったデータのサイズを見て、その2つの比率を見るだけやったんやな。
これは魅力的な考え方やな。数字が一つあるって考え方、少なくとも最小値があるって考え方やな。そして、一つ現れつつあるように見えたんや。まだ「より大きいほど良い」って信じてるんか？少なくとも生の性能と生の知能については。
そうやな、生の性能と生の知能については、より大きいほど確実に良いと思うわ。
人々が取るかもしれない道は、僕は特に蒸留に期待してるんやけど、訓練にめっちゃお金をかけて、最も能力の高い安いモデルを得るために、どれだけ多くのノブを回せるかってことやな。推論時の計算量をできるだけ気にするっちゅうのは、人々が既にラマモデルでやってることの素朴なバージョンやな。70Bモデルを、チンチラの最適よりもずっと多くのトークンで過剰に訓練するっちゅうことやな。
でも、本当にそれを気にするなら、ガンマがやったことかもしれんな。単にトークンで訓練するんやなくて、文字通りガンマ27Bの分布とのKLダイバージェンスを最小化することに訓練するんや。
ここでは、この27Bパラメータモデルを全てのトークンで訓練する計算量を使って、より小さなモデルを得るためにやってるんや。
蒸留は理論的に、訓練してるデータからより多くのシグナルを得られるんやな。これは、データの壁を完全には越えられへんけど、部分的に助けになる別の方法かもしれんな。データの壁っちゅうのは、訓練できるデータの量に限りがあるってことや。
めっちゃ大きなモデルを全てのトークンで訓練して、それをより小さなモデルに蒸留するんや。そしたら、このずっと小さなモデルに対して、元々よりもトークンあたりのシグナルをより多く得られるかもしれんのや。
じゃあ、10兆ドルあげたとして、どう使う？島を買うとかはなしやで。大きなモデルを改善することと、RLHFのHFの部分にお金を払うことの間で、どう配分する？
そうやな。これらの大規模モデルの訓練に関する秘密や詳細がようけあって、それらは大きな研究所の人間しか知らへんのや。問題は、そういうことを知らんと、そのお金の大部分を無駄にしてまうってことやな。
多くの不信感を置いといて、ノウハウがあるって仮定して、今持ってる限られた情報で操作せなあかんとしたら...
いや、いや。実際に全ての情報、全ての小さなヒューリスティクス、全ての小さなパラメータ、物事がどう訓練されるかを定義する全てのパラメータを手に入れたとするんや。
ほな、今後5年間で生の知能を最大化するためにお金をどう投資するかって考えると、答えはめっちゃ単純やないか？できるだけ多くの計算能力を手に入れるだけやろ。結局のところ、必要なのはGPUを買うことだけやな。
あとは研究者が全てのことを見つけられるんや。大きなモデルを事前訓練するか小さなモデルを事前訓練するかは調整できるし。
でも、これは計算能力とお金で制限されてるのか、それとも他のことで進歩を制限されてるのかっちゅう問題になるな。僕はアーヴィッドの考えに近くて、アイデアで制限されてると思うんやけど。
でも、計算能力がようけあれば、ようけ実験ができるやろ。だから、巨大なモデルを訓練するんやなくて、その計算能力を使ってようけ実験するってことか？
そうやな。でも、アイデアに制限があると思うわ。たとえ全ての計算能力と世界中のデータを集められたとしても、最終的にはアイデアだけやなくて、本当にええエンジニアリングにも制限されると思うんや。
全ての資本があったとしても、本当に違いを生み出せる人間はそんなにおらへんのや。研究には本当に難しいエンジニアリング作業がようけあるんや。
ちょっと曖昧な例やけど、元のTransformerの論文を見てみ。文献に埋め込まれた多くの面白い概念をまとめる作業と、全てのコードを書く作業、例えばCUDAカーネルとか、他のものとか、GPUのパフォーマンスを本当に最大限に引き出すためのものとか、どっちがどれくらいの作業量やったと思う？
元々GPUで動いてたのかTPUで動いてたのか分からへんけど。Gnomeにそのコードをやらせるのはどうやろか。Gnomeは世界最高のエンジニアの一人やと思うけど。
もっと進んで、次世代のモデルでは、モデル並列性を機能させて、何千台、あるいは何万台のV100でスケールさせるみたいなことをせなあかんのやな。GPT-3がそうやったかもしれんな。
これらのことを機能させるためには、めっちゃ多くのエンジニアリングの努力が必要なんや。もしこのコストを、ゼロにはせえへんけど、10倍くらい簡単にできたら、本当に素晴らしいアイデアを持ってる人が、夢見た新しいアーキテクチャをすぐにGPUの40-50%の利用率を得られるバージョンにできるようになるんや。
そしたら、研究のスピードがめっちゃ上がると思うわ。
そうやな。明確な改善の道筋が見えるなら、常に低hanging fruitから始めるべきやと思うわ。たぶんOpenAIや他の研究所は、low-hanging fruitを選ぶのは正しかったんやと思うわ。
そのlow-hanging fruitっちゅうのは、GPT-4.25スケールまでスケールアップできるっちゅうことやな。ただスケールアップし続けて、物事がどんどん良くなっていくんや。全てがうまくいってる間は、新しいアイデアを試す意味はないんや。できるだけ多くの成果を得るために押し続けるべきなんや。
そして、本当に新しいアイデアが必要になったら、そのときに考え直せばええんや。10兆ドル使うんやったら、そのうちのいくらかは、実際にアイデアを再評価することに使いたいと思うわ。その時点では、たぶんアイデアで制限されてるやろうからな。
我々全員が、AGIに到達するには新しいアイデアが必要やと信じてると思うわ。そして、我々全員が、それらのアイデアを小規模でテストする方法があると信じてると思うわ。それらのアイデアがうまくいくって、かなり確信を持てるようになるんやな。
ただ、現在の研究所の立場では、限られた研究とエンジニアリングの才能を、これらの他のアイデアの探索に充てるのは難しいんや。だって、パフォーマンスをある程度の期間、確実に向上させる中核的なことがあるからな。
そうやな。でも、これらの大きな研究所は勝ってるからな。だから、めっちゃ頑張ってるんや。
ほな、大きな質問をしよか。未来を見てみよう。今、プログラミングの世界の中心におるわけやけど、プログラミングの本質が今後数ヶ月、1年、2年、5年、10年でどう変わると思う？
我々は、長い間プログラマーが運転席に座ってる未来にめっちゃワクワクしてるんや。これについては少し話したけど, プログラマーのスピードと主体性、そして制御を強調するものやな。修正したいものは何でも修正できる能力, 作ってるものを本当に速くイテレーションできる能力をな。
これは、この分野で一部の人々が飛びついてるものとは少し違うと思うわ。一つのアイデアは、コンピューターと話せるようになるっちゅうことや。Slackを通して工学部や技術者と話すみたいに、ソフトウェアを作ってもらえるっちゅうことやな。それが単に孤立したテキストボックスになるっちゅうことや。
我々がそれにワクワクしてへん理由の一部は、レイテンシーの問題とかもあるけど、大きな部分は、それによって多くの制御を失うからなんや。テキストボックスで話すときは、本当に具体的になるのがずっと難しくなるんや。
そして、必然的に何かと通信するだけなら、本当に重要な決定をたくさんこのボットに任せてまうことになるんや。これは、根本的にエンジニアリングが何かっちゅうことに関わってくるんや。
エンジニアリングから少し離れた人々は、仕様が完全に書かれていて、エンジニアはただ来て実装するだけやと思ってるかもしれんな。ただコードで物事を実現させて、物事を存在させるだけやと。
でも、最高のエンジニアリング、我々が楽しいと思うエンジニアリングには、何を正確に作るかについての小さな決定がたくさん含まれてるんや。システムに関わる速度とコストの間の本当に難しいトレードオフもあるしな。
人間が実際にソフトウェアを設計し、何を作りたいかを指定してる限り、つまり全てAIが運営する会社やないなら、人間が運転席に座って、これらの決定を指示することを本当に望むと思うんや。
これがどんな感じになるかは、まだ分からへんな。一つの変なアイデアとしては、コードベースを見る抽象化レベルを制御できて、コードベースの特定の部分を指し示せるようになるかもしれんな。たぶん、擬似コードの形でコードベースを理解して、その擬似コードを編集することもできるようになるかもしれんのや。
そして、その変更が正式なコードベースに反映されるんや。プログラミングのテキスト編集コンポーネントは維持しつつ、ソフトウェアコンポーネントのどの論理でも指し示せるようにするんや。コードを詳しく見ることもできるし、より高いレベルの抽象化を見ることもできる。それと同時に、これらの大きな生産性の向上も得られるんや。
抽象化のスタックを上下に行き来できたらええな。
そうやな。そこにはようけ詳細を詰める必要があるんや。それはちょっとぼんやりしたアイデアやけど、制御とスピード、そして人間が運転席に座ることの重要性っちゅう、これらの原則は本当に重要やと思うわ。
アーヴィッドが前に言うたように、プログラミングのスタイルによっては、チャットボットスタイルで任せられるものもあると思うわ。例えば、本当によく指定されたバグがあるような場合やな。でも、それはプログラミングのほとんどやないし、多くの人が価値を置くプログラミングのほとんどでもないと思うわ。
プログラミングの基本的なスキルについてはどうや？今、若い人たちの中には、プログラミングが好きやけど、この道を追求したら将来があるんやろうかって心配してる人もおるんやけど。プログラミングのスキル自体が根本的に変わると思う？
実際、これはソフトウェアを作るのにめっちゃワクワクする時代やと思うわ。2013年とか2012年頃のプログラミングがどんなもんやったか覚えてるやろ？もっと面倒なことやクラフトがようけあって、本当に厄介なことを調べるのにめっちゃ時間がかかったんや。
そういうのは今でもあるけど、確実に減ってるな。今日のプログラミングは、当時よりずっと楽しいんや。本当に人々をプログラミングに引き付けるもの、喜びや集中力、そういったものにどんどん近づいてるんや。
例えば、めっちゃ速くものを作れるっちゅう要素や、スピードや個人の制御力、そういったものがどんどん強くなってるんや。だから、ソフトウェアを作る人にとっては、めっちゃ楽しい時代になると思うわ。
スキルは変わるかもしれんな。人々の好みや創造的なアイデアがもっと拡大されて、定型的なテキスト編集はちょっと減るかもしれんし、今日のプログラマーにとって本当に重要な注意深さも少し減るかもしれん。でも、もっと楽しくなると思うわ。みんなはどう思う？
同感や。最近あったことやけど、コードベースにちょっと大きな移行をしたかったんや。Node.jsのasync local storageを使ってたんやけど、あんまりパフォーマンスが良くないって知られてるから、コンテキストオブジェクトに移行したかったんや。
これは大きな移行で、コードベース全体に影響するんや。スワルと僕で、今日のAIツールを使っても5日くらいかかったわ。
将来的には、数例を示すだけで、AIがそれを全ての場所に適用して、「ここは新しい例やけど、どうしたらええ？」って聞いてきて、そこで正確に何をすべきか示せるような未来にめっちゃワクワクするんや。そしたら10分くらいでできるようになるかもしれんな。
そしたら、もっとずっと速くイテレーションできるんや。最初からめっちゃ考えて、黒板の前に立って「これをどうやってやるか」って考える必要がなくなるんや。コストが高すぎるからな。でも、まず何かを試してみて、「あ、これは実際に欲しかったものと少し違うな」って気づいて、すぐにまた変更できるんや。
だから、将来のプログラマーになるのはめっちゃ楽しいと思うわ。
そうやな。プログラミングには二つのアプローチがあるって言うたの、めっちゃええ指摘やと思うわ。一つは、最初にめっちゃ慎重に考えて、できる限り最高の方法を考えて、限られたエンジニアリング時間を使って実際に実装するっちゅうやり方や。
でも、僕はコードに入って、試してみて、どんな感じになるか見て、それからめっちゃ速くイテレーションするのが好きやな。それの方が楽しいんや。
そうやな。定型文を生成するだけでもええよな。そしたら難しいデザインの決定や、ニュアンスのある難しいデザインの決定、移行に集中できるんや。
これはクールな例やな。大規模言語モデルは基本的に、あるプログラミング言語から別の言語に翻訳したり、一般的な意味での移行ができるようになってるみたいやな。でも、それは現時点での話や。
つまり、こういう恐れがあるんやな。モデルがどんどん良くなっていくと、創造的な決定をする機会がどんどん減っていくんやないかって。最終的に、自然言語のデザイン空間で操作するようになったり、自然言語がメインのプログラミング言語になったりするんやないかって。
これについて、アドバイスを聞きたいんやけど。今、プログラミングに興味がある人がおるとして、何を学ぶべきやと思う？君らはJavaとか、何やったっけ、PHPとかから始めたんやろ？
Objective Cやな。
Objective Cか。そうやな。
結局のところ、JavaScriptが勝つってみんな知ってるんや。TypeScriptやなくて、ただのバニラJavaScriptがな。それと少しのPHPもな。
これは、ドン・クヌースが言うてた考えも出てくるな。人口の一定割合がギークで、プログラミングには特定の心理や思考が必要やって。でも、プログラミングができる人の種類がどんどん広がっていく感じがするな。
人によってプログラミングする理由は違うと思うけど、たぶん最高のプログラマー、本当に最高のプログラマーは、プログラミングが大好きな人たちやと思うわ。例えば、うちのチームにおる人で、仕事から帰ってきて、コンピューターを立ち上げて、夜中の3時まで自分のサイドプロジェクトのコーディングをし続ける人がおるんや。
悲しくなったときも、「コーディングせなあかん」って言うんや。このレベルのプログラマーは、プログラミングへの執着と愛情があって、それが本当に最高のプログラマーを作り出すんやと思うわ。こういうタイプの人は、物事がどう動くかの詳細にめっちゃ興味を持つんや。
その質問は、まさにそのプログラマーについて考えてるんや。カーソルタブが、素晴らしき讃えあれタブが成功して、タブを押し続けるようになったときに、チームの中でカーソルタブが一番好きな人やな。
そうやな。単にタブを押すっちゅうのは簡単な言い方で、キャッチフレーズみたいなもんやけど、実際にやってることは、常に意図を注入してるんや。時には拒否したり、もう少し文字を打ったりするんや。それが作られてるものを形作る方法なんや。
プログラミングはめっちゃ変わると思うわ。何を作りたいかっちゅうことも変わるやろうしな。コンピューターとのコミュニケーションの帯域幅が高くなるっちゅうことやな。単にタイピングするよりもずっと高い帯域幅になるんや。
これは、君らの「エンジニアリングの天才」っちゅうマニフェストにも通じるな。「我々は、人間とAIの驚異的に生産的なシステムを構築する応用研究所や」って書いてあるやろ。この人間とAIのハイブリッドな要素について話してるわけやな。
「最初に、我々は未来のエンジニアを作ろうとしてる。人間とAIのプログラマーで、どんな一人のエンジニアよりも一桁以上効果的なんや。このハイブリッドエンジニアは、コードベースを簡単に制御でき、エントロピーの低いキーストロークは一切ない。最も複雑なシステムでも、判断のスピードでイテレーションできるんや。AIと人間の創意工夫を組み合わせて、純粋なAIシステムよりも賢く、上手くエンジニアリングできるんや。」
「我々は研究者とエンジニアの集団や。有用で可能なことの境界線で発明するためのソフトウェアモデルを構築してるんや。我々の仕事は既に何十万人もの人々の生活を改善してる。我々は最高のプログラマーや。」
そして、そこに至る途中で、少なくともプログラミングをもっと楽しくするんやな。
今日は話してくれてありがとう。
ありがとうございました。
ありがとうございます。
ありがとうございました。
ありがとうございます。
マイケル、スワル、アーヴィッド、アモンとの会話をお聞きいただき、ありがとうございます。このポッドキャストをサポートするには、説明欄のスポンサーをチェックしてください。
最後に、Redditで見た、ランダムで面白く、そしておそらく深遠なプログラミングコードを紹介させてください。
「問題への一時的な解決策ほど永続的なものはない。機能するものは何もない。」
聞いてくださってありがとうございます。次回もお会いできることを楽しみにしています。

この記事が気に入ったらサポートをしてみませんか？