15,315 文字
今日は、プリンストン大学からSWEベンチを担当する3人の研究者とのインタビューをお見せします。SWEベンチは、異なるLLMやSWEエージェントのコーディング能力をテストするベンチマークで、実世界のソフトウェアタスクを達成するエージェンティックフレームワークです。SWEベンチとSWEエージェントの起源から、プログラミングの未来まで、幅広い話題について話し合いましたので、今日はその内容を皆さんと共有したいと思います。
皆さん、今日は時間を取っていただき、ありがとうございます。プリンストン大学からSWEエージェントチームのキリアン、オフィール、カルロスをお迎えしています。彼らが取り組んでいるプロジェクトはすべてオープンソースで、無料でダウンロードして試すことができます。私も既に試してみましたので、ぜひチェックしてみてください。リンクは説明欄に記載しておきます。オープンソースコミュニティへの貢献、本当にありがとうございます。
まずは簡単なアイスブレイクの質問から始めたいと思います。現在のコーディングスタックはどのようなものですか? どのように開発やテストを行い、どのIDEを使用していますか? キリアン、あなたから始めてもらえますか?
キリアン: 最近、カルロスの後を追ってカーソルに移行しました。しばらくGitHub Copilotを使っていましたが、コーパイロットによるバグが時々発生するものの、プログラミング生活がより楽しくなりました。カーソルの素晴らしい点は、Tabを押すと他の場所でも、論理的な続きの変更でも補完してくれることです。カーソルをIDEとして使っていますが、使用しているLLMはClaudです。GitHub Copilotも最近大規模なアップデートをリリースしたので、追いつこうと頑張っているのは確かですが、どうなるかはわかりません。
オフィール: 私は最近あまりプログラミングをしていません。最後に大量のコードを書いたのは、SWEエージェントを開発していた1年前の1月か2月頃でした。その時はVisual Studioを使っていて、言語モデル – おそらくGPT-4だったと思いますが – にウェブサイトで質問して助けてもらっていました。SWEエージェントでの私の仕事のほとんどは、軌跡を読んでプロンプトを修正することでした。実際のプログラミングはジョンとカルロス、キリアンが担当していました。
カルロス: キリアンが言及したように、IDEとしてカーソルを多用しています。また、インフラの多くをクラウドコンピューティングに移行しているところで、AWSのコンテナやバッチなどを使って、クラウド上でSWEベンチの自動評価などを行っています。
SWEベンチとSWEエージェントについて詳しく聞かせてください。私のチャンネルで何度か取り上げているので、視聴者の方々はある程度ご存じだと思いますが、簡単な概要と、それらを作ろうと思ったきっかけを教えていただけますか?
オフィール: はい、お答えします。SWEベンチの話から始めると、ジョンと私がプリンストンで夏を過ごしていた時のことです。多くの人がインターンシップや外出中で、ある午後、私たちは二人でアイデアを出し合っていました。SWEベンチのアイデアは、GitHubのインフラをより深く活用する方法を考えているときに生まれました。多くの人々がコードの学習にGitHubを使用していましたが、GitHubにはコードのホスティング以外にも、イシューやプルリクエストなど、オープンソースコラボレーションのためのインフラが多くあります。
私たちはそれらを活用する方法を考えていました。そして20分ほどで、SWEベンチのアイデアが明確になりました。GitHubでは、オープンソースの開発コミュニティで、開発者が公開でソフトウェアを投稿し、ユーザーがバグを報告できます。これはすべてオープンに行われ、誰かがバグレポートや課題を投稿すると、リポジトリのメンテナーやオープンソースの協力者が確認して、そのバグを修正するためにコードを更新できます。
これは多くのソフトウェア開発の本質的な部分です。ソフトウェアを反復的に改善し、機能を追加し、バグを修正して、より良く、より信頼性が高く、より高速なものにしていくのです。これがGitHub上のオープンソースソフトウェアでオープンに行われているため、SWEベンチはこのウェブサイトの構造を、言語モデルをテストする方法に変換しました。実世界の環境でユーザーのバグを解決し、ソフトウェアを修正する能力をテストするのです。
これは新しいことでした。以前は、言語モデルは非常に小さなプログラミングチャレンジ型の問題で評価されていました。たとえばソフトウェアエンジニアリングの面接で、複雑なソートを行う関数を書くような例題が出されますが、それは実世界のプログラミング環境とはかなり異なります。GitHubは実世界そのものであり、今日非常に影響力のあるオープンソースソフトウェアを支えています。これらの問題は、実際のソフトウェアエンジニアが日々直面する問題にずっと近いものです。これがSWEベンチのユニークな点であり、その誕生の経緯です。
キリアン: オフィールから聞いた話で覚えているのですが、最初は言語モデルがシンプルな補完タスクでさえ苦労していたため、SWEベンチに挑戦することに興味を示す人を見つけるのが難しかったそうです。タスクが非常に困難に見えたため、SWEベンチとともにSWEエージェントが登場するまでは、人々はそれに挑戦する意欲さえ持てなかったのです。
オフィール: ちょっと時系列とチームメンバーを明確にしておきましょう。カルロスとジョンがSWEベンチを主導しました。ジョン・ヤンは来られませんでしたが、プリンストンで修士を終えた後、研究助手をしていました。カルロスは博士課程の学生です。彼らがSWEベンチを始め、私がプリンストンでポストドクを始めてそのプロジェクトに加わり、キリアンはSWEベンチを終える直前に加わりました。キリアンはSWEベンチの論文には名を連ねていません。
SWEベンチをリリースした時、最高精度は1.96%でした。私たちはいくつかのベースラインシステムを持っていましたが、それらはすべてエージェントではなく非常にシンプルなもので、1.96%しか達成できませんでした。そのため、人々はSWEベンチに取り組むことを恐れ、あまりにも難しすぎると考えて、誰も挑戦しようとしませんでした。
SWEベンチの作業を終えた直後、私とジョン、カルロスには、エージェントを作りたいという明確な考えがありました。話し合う必要もないほど明白でした。エージェントの開発を始めようとしていた時、タスクの難しさを実感しました。私はジョンとカルロスに「テストで6%以上の精度が出たら、みんなにジェラートを奢る」と言いました。6%を達成するのは信じられないほど凄いことだと思っていたのです。
私たちは開発を始め、とても興奮していました。一方で、SWEベンチにはまだ誰も提出を行っていませんでした。3月頃、私たちはSWEエージェントのリリース準備をしており、この時点で13%の精度を達成していました。私たちが予想していた精度をはるかに超えていました。エージェントに新しいコマンドを与えるアイデアを試し、うまくいかないものもありましたが、異なるコマンドを試したり、様々なツールを与えたりしました。
最終的に効果があったのは、エージェントのために特別に設計されたインターフェースでした。私たちはこの論文で「エージェントコンピュータインターフェース設計」という概念について説明しています。人間向けのアプリを作る時にGUIデザイナーがいるように、エージェント用のコンピュータインターフェースを設計する必要があったのです。
例えば、エージェントがファイルを見たい時、単純な方法はファイル全体を表示することですが、それはエージェントを混乱させることがわかりました。言語モデルは一般的に、入力はできるだけ短い方が良く、長くなると混乱します。そこで私たちは、一度に100行だけを表示するファイルビューアを作りました。エージェントはスクロールダウンコマンド、スクロールアップコマンド、ファイル内の検索コマンドを使用できます。これは性能を大きく向上させ、論文では100行ずつ表示する方が200行や300行よりも良い結果を出すことを示しています。
これらの探求は何ヶ月もの試行錯誤の結果です。ある時期、エージェントがファイルを正しく編集することに苦労していて、様々な方法を試していました。特定のファイルと編集したい部分があった時に、エージェントがそれをシステムにどのように伝えるべきか、言語モデルにどのように表現させるべきか。プログラミングアシスタントやプログラミングエージェントを作った人なら誰でも、これが大きな課題だと知っています。
1ヶ月か6週間ほどそれに取り組んでいましたが、うまくいきませんでした。そしてある日、ジョンがリンターのアイデアを思いつきました。これは非常に賢いアイデアでした。エージェントは編集を試みる時、人間では決してしないような奇妙な間違いをしていました。同じ行を2回コピーしたり、110行目から115行目を編集するつもりが、111行目から116行目を編集してしまったりするような小さな間違いです。
ジョンは、エージェントが編集を行うたびに自動的にリンターを実行することで、これらの愚かな間違いの多くを捕捉できることを発見しました。これにより性能は次のレベルに到達しました。そしてローンチを決意しました。
ローンチの1週間前、Anthropicから「明日ローンチします」というメールを受け取りました。私たちは「おお、誰かがついにベンチマークに提出してくれるんだ」と思いました。最初の提出でした。あまり深く考えませんでしたが、翌日それは大きな話題となり、皆がSWEベンチについて語り始めました。
私たちは既に提出する準備ができていて、1、2週間後に公開しました。Anthropicと同じような性能を達成しましたが、私たちの方が処理速度が速く、完全にオープンソースでした。AnthropicのローンチとSWEエージェントが続けて登場したことで、SWEベンチへの関心が爆発的に高まったのです。
これは素晴らしい話ですね。いくつか確認させてください。SWEベンチは簡単に言えば、LLMの実世界のコーディングタスク完了能力をテストする方法ということですね。そしてSWEエージェントは、エージェンティックフレームワークでLLMをラップして、SWEベンチで最高スコアを目指すあなたたちのバージョンということですね。
Anthropicについては多くの人が聞いたことがあると思いますが、基本的にはクローズドソースのエージェンティック+UIのエージェントコーダーのようなものです。より良い説明の仕方がわかりませんが。
カルロス: はい、AnthropicとOpen InterpreterとSWEエージェントの違いについて簡単に説明させてください。AI支援プログラミングにはいくつかのアプローチがあります。最も基本的なのは、CopilotやCursorのような、プログラミング中に役立ちそうなコードブロックや行を提案してくれるものです。
私たちはそのスペクトルの反対側にいます。バグレポートや機能リクエストから、人間の介入なしに完全な実装まで行うことを目指しています。完全に自律的です。その中間にAnthropicやOpen Interpreterのようなツールがあり、プログラマーとAIのコラボレーションを支援します。完全に自律的ではありませんが、人間の多くの入力を得ながら機能を開発します。これらのツールはすべて、それぞれの市場セグメントで有用だと思います。
開発者としてのスキルを強化するものから、単一のプロンプトまたは単一のGitHubイシューを与えられて、実装を含むタスク全体を自律的に完了するものまで、さまざまなアプローチがあるのは興味深いですね。これは実は、AIとプログラミングの未来について皆さんに質問したかったことにつながります。
まず私の予測を共有させてください。その後、皆さんの考えを聞かせてください。私は今後5年間で、コードを書いたり何かを開発したりする人の数が爆発的に増えると考えています。SWEエージェントからAERやAnthropicまで、すべてのツールにより、以前は始めるのを躊躇していたり、完全なスキルを持っていなかった人々でも、多くのものを作れるようになるでしょう。
しかし、10-15年後の長期的な視点では – これは物議を醸す意見かもしれませんが – プログラマーはそもそも必要なくなるかもしれません。特に、AI Doomのデモのように、基盤となるゲームエンジンがない場合や、数週間前に公開されたAI Minecraftのように、基盤となるゲームエンジンがなく、単に拡散モデルと予測モデルを使って次のフレームを予測している場合を考えると。
そのモデルで考えを進めていくと、オペレーティングシステムがLLMである場合、アプリケーションはどこに位置するのか、そしてそもそも開発者はどこに位置するのか、という疑問が出てきます。これが私の予測です。短期的には開発者の爆発的増加、長期的には開発者がいなくなる可能性。カルロス、短期、中期、長期の予測を聞かせてください。
カルロス: はい、短期的にはその通りだと思います。これらのシステムやツール、プログラミング言語、テクノロジースタックは、これまでかなり急な学習曲線を持っていました。多くの人々がプログラミングを学び、各ツールの使い方を習得するのに長い時間を費やしてきました。
しかし今、言語モデルは広い知識ベースを持ち、どのプログラマーでも新しいツールへの参入を以前よりもずっと速く支援できます。学習曲線が大幅に緩やかになり、人々は新しい製品やツール、ソフトウェア、テクノロジースタックを使い始めやすくなります。そういう意味で、あなたの指摘は正しいと思います。
長期的なビジョンについては、AIアシスタントによって自動的に行われることが増えると思います。SWEエージェントのように、自動エージェントがコードベースの改良やバグ修正、ソフトウェアの問題への対応を試みるでしょう。人間は必要です。なぜなら、すべてのバグに対してSWEエージェントを実行するのは非常に安価で、数ドルで済むからです。
これらのシステムがさらに良くなるにつれ、人間はAIソフトウェアエンジニアのQAのような役割をより多く担うようになるでしょう。QAテスターやQAエンジニアがその役割を果たし、実際のプログラミングの多くはエージェントによって自動的に行われるようになるでしょう。
これは最初に指摘した点とも関連します。AIによって部分的に生成されたコードを作るのが非常に簡単になるため、ほとんどのエンジニアがAIソフトウェアエンジニアが生成する更新や改善を監督する、より専門的なバージョンになっていくでしょう。
カルロス、将来的に言語モデル自体がオペレーティングシステムとなり、開発者ではない一般のエンドユーザーが、基盤となるコードなしにリアルタイムで必要な情報を得られるような世界は考えられますか? それともそれは行き過ぎでしょうか?
カルロス: それは将来のコンピューティングについてかなり極端なビジョンに聞こえます。とても創造的な方向性があるかもしれませんが、最良や最も効率的な方法かどうかはわかりません。あなたが言及したAI Doomのようなものは、少なくとも現時点ではビデオゲームを作る非常に非効率的な方法だと思います。
しかし、研究者がプログラムが従来行っていたことをAIに生成させる研究をより進めれば、非常に興味深い製品が生まれる可能性はあります。ただし、現時点では非常に異質なアプローチに思えます。
キリアン、短期、中期、長期について、あなたの考えを聞かせてください。
キリアン: 短期的には、既に優れた開発者で、コードの品質について優れた概観と感覚を持っている人にとって、これらのイノベーションはスーパーチャージとなります。以前のプログラミングには、ある程度の思考と知識が必要でしたが、それ以外にも多くの単純作業がありました。コードを書き記すだけの作業が、仕事の上手な人の足を引っ張っていたのです。その時間がかかる部分が縮小することで、優れたプログラマーは信じられないほど生産的になり、これが産業を牽引すると思います。これは短期的に既に起こっています。
中期的には、どちらの方向に進むか予測は難しいです。一方では、誰もが非常に効率的になるので、プログラマーは少なくて済むかもしれません。しかし、それは単に製品の価格を下げることにもなります。ソフトウェアエンジニアがいなかった場所、つまりソフトウェアが高すぎて使用できなかった場所で、実際にソフトウェアを書く需要が高まるかもしれません。より効率的にすることは、必ずしもリソースの消費を減らすことを意味しないという一般的な原則があります。
そのため、中期的にプログラマーの数が本当に減少するかどうかはわかりません。長期的なビジョンについては、何をしたいかによると思います。特定のプログラムは書く必要がなくなるかもしれません。既にChatGPTで、以前はプログラムを書く必要があったことができるようになっています。
しかし、非常に大規模なコードを書く場合、特に重要なシナリオでは、システムがどのように動作するかについての保証が必要です。システムが大きければ大きいほど、個々の部分が特定の保証を満たすことがより重要になります。言語モデルは完全に予測可能であることはできません。それが言語モデルの本質ではないのです。
そのため、コードは全ての基盤として残ると思います。なぜなら、言語モデルには与えられない決定論的な保証を提供するからです。そして、それを受け入れれば、プログラマーの仕事は本質的に、コードに変換される仕様を定めることです。
ある時点で、コードと考えるものと、非常に柔軟な高水準プログラミング言語との間に違いはなくなります。これが一点です。もう一つは、本当に最先端を目指すなら、言語モデルは既存のコードすべてで学習されているため、常に遅れをとることになります。
新しいものが出てきた時、まず言語モデルはまだそれで学習していないので、おそらくそれを認識すらできません。認識できたとしても、これは新しい標準だ、これは新しい優雅な方法だから採用しようという能力はありません。圧倒的多数は業界標準であり、業界標準が何を意味するかによっては、それは古くて複雑すぎるコードかもしれません。
言語モデルで生成されたコードでは早期採用者になることはできません。非常に具体的に指示しない限り。そしてそうすれば、仕様を非常に慎重に定めることになり、それは基本的にプログラミングと同じです。そのため、プログラマーは残ると思います。それが何を意味するのか、人間が理解できる言語か特定のプログラミング言語で書くのかはわかりませんが、本質的に同じ仕事になるでしょう。
興味深いですね。言語モデルは基本的に、現在取り込んでいるコードベースの品質の平均になるということを考えていませんでした。もちろん、本当に良い選択と刈り込みを行えば、最高のコードを得ることができ、それがコーディング特化モデルとして差別化する方法かもしれません。
オフィール、あなたの考えはどうですか?
オフィール: 短期的には、SWEエージェントのようなツールがあり、人間の言語で機能をリクエストしたり、バグを説明したりするだけで、エージェントから素早くプルリクエストを得られるようになります。最初はバグの5%程度しか修正できないかもしれませんが、2、3年後には70%か80%のバグや比較的小さな機能リクエストを修正できるようになるかもしれません。
現在、SWEエージェントのようなシステムは、非常に複雑なバグや機能リクエストには苦労しています。特に複雑な機能については、SWEエージェントのような現在のツールでは十分な対応ができないと思います。人間の言語で何かを指定して、バグや機能リクエストの大部分について良いプルリクエストを得られるようになるまでには、3、4年はかかるでしょう。
そのため、プログラマーは少なくとも3、4年は確実に必要です。その後何が起こるかを予測するのは非常に難しいですが、プログラマーが完全にいなくなるというよりは、より効果的で生産的になると思います。なぜなら、何をする必要があるかの仕様を書き、これらのモデルの出力を確認する人間は依然として必要だからです。
10年後は予測が本当に難しいですが、コンピュータはより有用になり、非技術者が現在のプログラマーと同じ力を持つようになると思います。全く技術的でない人が、Excelで税金の計算をしていて「このボタンがあったらいいのに」と思った時、8年後くらいには、コンピュータと話をして「このボタンを作って」と言えば、それが現れて機能するようになるでしょう。
このように、非技術者という概念がなくなる未来にワクワクしています。人間の言語で話をして技術的な機能やソフトウェアのボタンを得られるようになれば、誰もが技術者になるのです。
また、ノーコードという言葉は言語モデルが登場する前からありました。人々は、グラフィカルインターフェースがあり、様々なボックスを接続するようなものを想像していました。しかし、それは本当に普及しませんでした。言語モデルでも同じような理由で見ることになると思います。これをコントロールするのは難しく、変更を追跡するのも難しく、複数のユーザーが同じものに取り組むのも難しいのです。
そのため、一時的な作業として何かを機能させたい一般ユーザーと、信頼性が必要なプロフェッショナルなソフトウェアの間には、依然として明確な区別があると思います。機械に願いを話しかけるような魔法が、それらを置き換えることができるかどうかはわかりません。
つまり、皆さんは言語モデル自体が必要なものを与えてくれる未来、つまり基盤となるエンジンが言語モデル以外にない未来は考えていないということですね。基本的なことについては可能かもしれませんが、より複雑なことについては、プログラマーがしばらくは必要だと皆さん考えているようです。永遠に必要かどうかはわかりませんが、言語モデルの限界と、なぜ人間による監督が必要なのかは理解していますよね。
キリアン: その通りです。エンジニアがいても、製品を立ち上げたい時は、エンジニアに製品がどのようなものになるかを説明するのに何時間もかかります。これらの説明や、本当に何を作りたいのかを設計することは、実際にそれを実現させることとそれほど変わりません。誰かに正確に何が欲しいのかを説明する必要があり、誰も心を読むことはできません。人間にもできないことなので、言語モデルが心を読んで、単に「ボタンが欲しい」と言えば、望むボタンを正確に作ってくれるとは思えません。
興味深いのは、数年前に「息子や娘に教えたい最も重要なスキルは何か」と聞かれたら、迷わずコーディングだと答えたと思います。私が身につけた中で最も価値のあるスキルセットだったからです。しかし、ChatGPTが登場し、ソフトウェアエンジニアリングの職業が急速に変化し、ソフトウェアエンジニアがより商品化されていく可能性を目の当たりにした時、そうではないかもしれないと思いました。
ただし、システム思考ができること、アイデアを詳細に説明できること、エッジケースを考えられることには、依然として大きな価値があります。アイデアについて起こりうるすべての事態を考え、それをコードであれ自然言語であれ、言語モデルが構築できるように十分に説明するには、純粋な思考力が必要なのです。
この会話を続けたいと思います。Pythonは間違いなく人工知能の言語です。私は幸運なことにPythonでの開発を楽しんでいて、多くの面でRubyを思い出します。AIが多くのコードを書き、予見可能な将来において人間のプログラマーとAIのコラボレーションが続くと考えると、コーディング言語自体を変更する必要があると思いますか? また、それはどのようなものになるでしょうか?
カルロスかキリアンが答えるべきですが、マルチモーダルでの経験とJavaScriptとPythonについて話してもらえますか?
カルロス: はい、それは実際に非常に良い質問です。Pythonが素晴らしいのは、人間の美的感覚によく合っているからです。しかし、必ずしもその好みが、言語モデルにとって適切とは限りません。人間が解析し、考え、視覚化するのに適した好みは、言語モデルに適したものと同じではないかもしれません。
言語モデルがより効率的に使用できるプログラミング言語を想像することはできます。完全に推測ですが、おそらく静的型付けのようなものの方が言語モデルには効率的だと思います。Pythonと比べてですが。
研究者たちが、Pythonとは異なる、言語モデルにより適した言語パラダイムや構造を見つけ出す可能性は十分にあります。少なくとも短期的には、最大の問題の一つは、Pythonの学習データが非常に多いことです。現在、言語モデルはPythonが得意です。それは単にデータが多いからです。JavaScriptについても同様で、一般的に言語モデルの性能は言語の人気度とある程度相関しています。
より高水準な、言語モデルパラダイムのようなプログラミング言語も面白いかもしれません。言語モデルがその言語のコンパイルの中心となるような。ただし、これはまだ非常に推測的で、少し空想科学的かもしれません。
コーディング言語が現在のような見た目、つまり可能な限り自然言語に近い形をしているのは、人間が読む必要があるからです。言語モデルに適したプログラミング言語は、私たちが見たことのないような、おそらく人間には読めないようなものかもしれません。もちろん、すべての学習データが自然言語とお馴染みのコーディング言語であることを考えると反論もあるでしょうが、それは常にそうとは限らないかもしれません。
キリアン、この話題についてあなたの考えは?
キリアン: とても興味深い質問ですね。カルロスが既に言及した静的型付けなどについて、再び保証について考えると、人間にとってはトレードオフがあります。仕事を完了させたいので、多くの柔軟性と高水準な言語が必要です。Pythonは非常に柔軟で、静的型付けされた言語と比べて保証は非常に少なく、何でもできます。
より静的な方向に少し逆戻りする傾向があるかもしれません。タイプする文字は少し多くなるかもしれませんが、タイピング速度はもはや問題ではありません。非常に高度な自動補完があるからです。より多くの保証が組み込まれたものに向かうか、極端な場合、テスト用の特定の言語のようなものになるかもしれません。
Cucumberのようなテスト用の言語があります。関数が何をすべきかについて多くの文を書くような、完全なパラダイムシフトになるかもしれません。言語モデルが担う小さな部分は「では、これを実現しましょう」というところです。プログラマーとしての私たちの優先順位は、チェックを書くことにシフトし、それに最適化された言語になるかもしれません。実際の実装は簡単な部分になるのです。
テスト駆動開発の真の実践ですね。
キリアン: テスト駆動開発は、ある意味で本当の意味では存在しないと思います。なぜなら、何かを書く時に、実際の問題が何なのかを学ぶことが多いからです。産業界でもテスト駆動開発は理想論だと思います。結合テストでは機能するかもしれませんが、単体テストでは機能しないでしょう。単体テストは実装に依存し、実装を書く前に実装を考えるのは非常に難しいからです。
ただ、保証と、例えば文字数について考える必要がなくなるかもしれない、そういった方向性です。Pythonよりも複雑な言語が再び登場するかもしれません。
オフィール、あなたの考えは?
オフィール: これは非常に深い質問で、答えはわかりませんが、私は9年間言語モデリングの研究をしてきました。言語モデルを構築する上で最も重要な3つの要素は、学習データ、GPUの数、そして学習時間です。それだけです。言語モデルのアーキテクチャ自体さえ、それほど重要ではありません。学習データとコンピューティングリソースが基本的に全てです。
そのため、新しい言語を作っても十分な学習データがないという単純な理由で、AI向けプログラミング言語が普及するのは非常に難しいでしょう。仮説として「すべての言語で無限の学習データがあったら、言語モデルにより適した言語があるだろうか」という質問には、答えはわかりませんが、それほど重要ではないと思います。まずは他のより困難な問題を解決する必要があります。
キリアン: トランスパイルがより大きな役割を果たすかもしれません。TypeScriptがJavaScriptにコンパイルされるように、新しいものが他の言語にコンパイルされるような、2つの言語が何らかの形で接続されているような状況です。一方は学習材料が豊富で、もう一方は新しいものというような。それは非常に興味深い方向性だと思います。
本当にソフトウェアエンジニアリングとAIについて話すだけでも、とても興味深い時代ですね。私は主にそれについて話すだけで、個人的な楽しみのために少しコーディングをしています。これらのツールを使いたいと思っているのですが、皆さんのように発明しながら進んでいくのは、とても素晴らしいことだと思います。
SWEエージェントとSWEベンチの今後について話を移したいと思います。何が来るのか、何に最も期待しているのか、教えてください。
オフィール: 2つの大きな新機能が登場します。キリアンとカルロスに詳細を説明してもらいますが、基本的にSWEエージェントの大規模なリファクタリングを行い、まもなくSWEエージェント1.0をローンチします。おそらくこのビデオが公開される頃には出ていると思います。
SWEエージェントを自分のデバイスやクラウドで実行しやすくし、コードベース全体をリファクタリングして拡張しやすくしています。SWEエージェントをより良くするアイデアがあれば、簡単に実装できます。キリアンがこれを主導しているので、説明してもらいましょう。
また、1年前からSWEベンチを公開していましたが、最近新しいイテレーション、新しいSWEベンチをリリースしました。SWEベンチマルチモーダルと呼ばれています。そのベンチマークを説明する論文は1、2ヶ月前に公開されましたが、評価インフラはまだリリースされていませんでした。そのため、SWEベンチマルチモーダルに提出することは不可能でしたが、今そのソフトウェアをリリースしています。
SWEベンチマルチモーダルは、SWEベンチと同じですが、GitHubイシューを解決するだけでなく、何らかのビジュアル要素を含むGitHubイシューを解決する必要があります。正しく表示されていないJavaScriptのUI要素や、正しくレンダリングされていないマップ、プロット、図表、アートなどです。すべてJavaScriptで、非常に難しいです。カルロスがこれを主導しているので、詳しく説明してもらいましょう。
キリアン: はい、お願いします。SWEエージェントのブランドは常に、人々が取り上げて適応し、ハックしやすい、非常にわかりやすい、単刀直入なプロジェクトであることを目指してきました。それは既に達成していますが、新しいリファクタリングでさらにその方向に進みます。
コードベースは縮小し、よりコンパクトで読みやすくなりましたが、同時にずっとパワフルになっています。以前はSWEベンチライトで300インスタンスを一晩中実行していましたが、今は多くのハードウェアを必要とせず、300のSWEエージェントを並列で実行できます。基本的に単一のコマンドラインフラグだけです。
以前は一晩かかっていた評価が、現実的に1時間以内に結果を得られるようになります。制限は言語モデルのレート制限だけです。これは非常にエキサイティングです。現在の実装よりも安定性も向上します。
これは、私たちが書いた新しいモジュール、新しいパッケージであるSWEREX（リモート実行用）によって実現されています。言語モデルがコードを書いて評価する時、その問題を解決しようとする環境をセットアップする必要があります。GitHubイシューを解決したい場合、そのGitHubリポジトリが必要で、そのリポジトリのコードを実行するためにすべてのものがインストールされている必要があります。
それを実行し、安定した状態を保つのは常に課題でしたが、それが今SWEREXが行うことです。Dockerイメージでローカルに実行することもできますし、単一のコマンドラインフラグでModalやAWS Fargateなどで実行することもできます。
このパッケージはSWEエージェントから完全に分離されるので、SWEエージェントを使いたくない場合でも、エージェントを開発している場合や、サンドボックス環境でコードを実行する必要がある場合に、SWEREXを使用できます。そうすれば、十分にテストされているため、確実に動作するという保証が得られ、おそらく本当に面倒だった大量のコードを捨てることができます。
これは私たちがSWEエージェントでも行ったことです。最も面倒な部分をSWEREXに分離することで、コード全体がより安定し、並列化が容易になり、研究者やユーザーにとって読みやすく修正しやすくなりました。
素晴らしいですね。ちなみに、SWEベンチ、SWEエージェント、そしてこれらのプロジェクトのホームページへのリンクはすべて説明欄に記載しておきます。カルロス、お願いします。
カルロス: はい、SWEエージェントのリファクタリングとこのリモート実行パッケージのリリースについて、キリアンが言及したように、SWEエージェントは基本的に2つの部分になります。リモート実行バックエンドとSWEエージェントがフロントエンドで、エージェント、ツール、イメージを設定します。ブラウザが必要か、ディスプレイが必要か、どのようなコンポーネントがフロントエンド側に必要かを設定し、SWEREXがすべてのバックエンドを処理します。
このリリースとともに、SWEエージェントやその他のエージェントをクラウドで評価しやすくするコードもリリースします。現在、SWEベンチパッケージはDockerを使ってローカルで多くの計算を行っています。その論理の多くを抽出し、クラウド上にエンドポイントとAPIを設定して、予測を提出し、エージェントを評価できるようにします。
このDockerの評価コンテナを実行することは、かなり大きな計算負荷がかかります。相当にパワフルなコンピュータが必要か、あるいはかなり遅く実行する必要があります。平均的なユーザーにとって、エージェントの予測を評価するのに数時間かかっていたものが、数分に短縮されます。予測をAPIに提出すると、APIがクラウド上ですべてを並列で処理し、はるかに高速に実行します。
ローカルでは何も実行されず、結果が返ってきて、単体テストに対してエージェントがどのように実行されたかを確認できます。
素晴らしいですね。カルロス、SWEベンチマルチモーダルについて話してもらえますか?
カルロス: はい、このリリースは主にSWEベンチマルチモーダルに焦点を当てています。無料の評価を提供する予定です。どのくらいの期間続けられるかはわかりませんが、どのくらいの需要があるか見極める必要があります。現時点では、AWSからの支援があり、このAPIを無料で提供できます。予測を提出すれば、SWEベンチマルチモーダルの結果を無料で得ることができます。
オフィール: つまり、これまで人々はSWEベンチをローカルで評価し、結果を私たちに送信していましたが、これからはSWEベンチマルチモーダルのチャレンジを提供します。チャレンジを与え、エージェントを使って解決策をプログラムし、それを私たちに送信すると、私たちのサーバーで評価を行います。これは高速で、意図的または偶然的な不正を減らすことができます。
すべての採点はサーバーサイドで行われ、これまで同様、結果はswbench.comで公開されます。これらすべてに期待しています。
素晴らしいですね。今日話題に上がったすべてのリンクを説明欄に記載しておきます。キリアン、オフィール、カルロス、時間を取っていただき、ありがとうございます。そして、改めてオープンソースへの貢献に感謝します。個人的にも非常に意味のあることですし、本当に素晴らしいものを作っておられるので、とても感謝しています。ありがとうございました。
キリアン、オフィール、カルロス: ありがとうございました。お招きいただき、ありがとうございます。
コメント