見出し画像

新しいClaude 3.5 Sonnet、コンピュータの使用、そしてSOTAエージェントの構築 — Anthropicのエリック・シュルンツとの対談

AGIに仕事を奪われたい

27,711 文字

こんにちは、レイデンスペースポッドキャストへようこそ。私はデイブルパートナーズのパートナー兼CTOのセシオです。今日は新スタジオで、いつものように共同ホストのショーンと一緒です。そして今日は幸運にもアンスロピック社からエリック・シュルン氏をお迎えしています。
エリック:ありがとうございます。私はアンスロピック社のテクニカルスタッフで、ツール使用、コンピュータ使用、そしてSweetベンチを担当しています。
ホスト:AIの世界に入ったきっかけを教えていただけますか?SpaceXでの経験もあると聞いています。
エリック:はい、SpaceXは随分前ですが、アンスロピックに入社する前はコバルトロボティクスのCTO兼共同創業者でした。セキュリティと点検用のロボットを作っていました。約5フィートの高さのロボットがオフィスビルや倉庫を巡回して異常を探すというものです。武器は持たず、何か見つかれば遠隔オペレータを呼ぶというフレンドリーなものでした。約100台を展開し、100人規模のチームがいました。約6ヶ月前に買収されましたが、私は約1年前に退社していました。
AIにより興味を持ち始めたからです。Copilotなどで多くのコードを書いていて、これは本当にすごいと思いました。10年前に「AIがコードを書くようになる」と言われていたら「それはAGIだ」と思っていたでしょう。エンジニアリング作業に本当に役立つレベルに達していることに気付き、AIにより興味を持つようになりました。サバティカルを取って研究し、この分野の中心で働きたいと思いアンスロピックに入社しました。
なぜアンスロピックを選んだのか、他の研究所やロボット企業は検討しなかったのかについて。当時はロボティクスに少し疲れていました。ハードウェアについてのネガティブな発言は疲れからきているもので、数年後には意見が変わるかもしれません。いろいろ見た結果、アンスロピックには信頼できる優秀な人々が多くいて、それが大きな決め手になりました。チームが素晴らしく、優秀なだけでなく親切で、文化的にもフィットすると感じました。AI安全性にも関心があり、良くない目的に使われないようにしたいと思っていたので、アンスロピックが最適だと考えました。
外から見ると、これらの研究所は巨大な組織に見え、組織の仕組みが分かりにくいと思います。入社時からSweetベンチなどの仕事をすることが決まっていたのですか?
アンスロピックはボトムアップ型で、個人の興味を尊重する文化です。入社時は、コード生成やAIが世界に触れて物事を構築する手助けをするといったことに興味があることを正直に伝えました。ただし、それは最初のプロジェクトではありませんでした。会社にとって最も価値のあることをしたいと考え、バランスを取ろうとしました。当初はいろいろなことに取り組み、関数呼び出しやツール使用などを担当していました。コーディングエージェントの重要性が高まるにつれ、Sweetベンチをベンチマークとして活用するようになりました。
Sweetベンチについて詳しく話しましょう。クロード3.5ソネットに関連する一連のリリースの一つです。約2-3ヶ月前にクロード3.5ソネットがリリースされ、多くの人がコーディング能力に惚れ込みました。先月には新しいバージョンがリリースされました。トレーニングについては機密情報なので話せませんが、アンスロピックはモデルを様々な用途に適用する点で優れた仕事をしていると思います。
Sweetベンチの検証に取り組み、モデルを最大限活用するエージェントを構築するシステムを開発されましたが、その背景を教えていただけますか?
私はプロダクトリサーチというサブチームに所属しており、顧客が何を求めているかを理解し、それを実現することを目指しています。数学の問題やMMLのような抽象的なベンチマークではなく、実際に価値のあるものに焦点を当てています。コーディングエージェントに興味があったので、これが重要なベンチマークになると考えました。多くのスタートアップや顧客が私たちのモデルを使ってコーディングエージェントを構築しようとしていることも分かっていました。
私が最初にSweetベンチを見つけたわけではなく、すでに社内で知られていて取り組みもありました。私はベンチマークの実装(これは非常に難しい)と、優れた参照エージェントの開発を担当することになりました。最終的には、人々が独自のエージェントを構築できるよう、参照エージェントの実装方法を公開することを目指しています。
このブログ投稿では、Sweetベンチで使用したツールとプロンプトを公開しました。Sweetベンチについて詳しくない人のために説明すると、一般的には「ソフトウェアエンジニアができるタスク」と捉えられていますが、それは正確ではありません。12のリポジトリから、テスト可能なマッチングコミットを持つ全ての課題を集めたものです。全てのコミットではなく、Sweetベンチ verified(検証済み)はさらにOpenAIによって手動でフィルタリングされています。
その通りです。Sweetベンチはまず、Pythonリポジトリのみという制限があります。さらに、人気のあるオープンソースリポジトリ12個のみです。また、開始時にテストがパスし、新機能をテストする新しいテストが導入されたものだけが対象です。実際のエンジニアリングタスクの非常に限定的なサブセットですが、価値があると考えています。他のベンチマークは、コーディング面接のような人工的な設定が多く、日常的なプログラミングとは異なります。
再帰やダイナミックプログラミングをどれだけ日常的に使うかを考えると、業界でも面接問題と日常業務の違いについて冗談が言われるほどです。Sweetベンチの興味深い点は、他のベンチマークが孤立したパズルで最初から始めるのに対し、リポジトリ全体のコンテキストの中で始めるということです。関連ファイルを見つけることが新しい次元の問題として加わります。これは実際のエンジニアリングでは重要な部分です。完全に新しいものを始めることは稀で、コードベースのどこを変更するかを見つけ、他のシステムとの相互作用を理解する必要があります。Sweetベンチはこの問題をうまく提示していると思います。
なぜまだHumanEvalを使うのでしょうか?92%程度で、100%に到達できるかどうかも分からない状況です。モデルのリリースを見ると、HumanEvalは92%から89%、90%になるのに対し、Sweetベンチ verifiedは49%で、以前の最高記録45%を超え、6ヶ月前の30%台から大きく向上しています。HumanEvalは置き換えられるべきでしょうか、それとも並行して続けるべきでしょうか?
時にはグリーンフィールドのコード生成が重要な場合もあるので、全てをエージェント型のセットアップにする必要はないと思います。Sweetベンチは実装が難しく、実行にコストがかかります。各タスクでは、コードをどこに配置するかを理解するために多くのリポジトリを解析する必要があり、コードの記述、実行、編集に多くの試行を要し、HumanEvalと比べてトークンを多く使用します。
従来のコーディング評価にも、実装が容易で実行が速く、ある程度のシグナルが得られるという利点があります。おそらくHumanEvalのより難しいバージョンが作られることを期待しています。
Sweetベンチ verifiedを92%まで引き上げるにはどうすればよいでしょうか?到達可能な目標でしょうか、それとも多くの要素が揃う必要があるのでしょうか?
まずSweetベンチとSweetベンch verifiedの違いについて説明させてください。Sweetベンchは先ほど説明した通り、12,000程度のタスクを収集したものです。最終セットでは2,000程度になりますが、人間が解決したにもかかわらず、タスクに付随する情報だけでは不可能なものが多くあります。
典型的な例は、テストが特定のエラー文字列を探すケースです。例えば「assert message equals error something something something」のように、何を探しているのか正確に知らない限り、モデルが全く同じエラーメッセージを書くことは不可能で、テストは失敗します。
Sweetベンch verifiedは、OpenAIと協力して作成されました。人間がこれらのタスクを全てレビューし、タスクを不可能にするような障害を取り除いたサブセットを選びました。理論的には、これらのタスクは全てモデルで実行可能なはずです。また、人間がタスクの難しさを評価し、15分未満、15分から1時間、1時間から4時間、4時間以上というカテゴリに分類しました。
92%に到達するために、まず現在の失敗ケースについて説明させてください。モデルを実行すると、最も多いのは抽象化のレベルが間違っているケースです。モデルが大きなリファクタリングが必要なときに小さな修正をしてしまうようなケースです。これはモデルの問題もありますが、GitHubのイシューだけを見ていると、どちらのアプローチを取るべきか必ずしも明確ではありません。
これらのタスクは可能であっても、タスクの説明にはまだ曖昧さが残っています。一般的に言語モデルは、可能な場合は大きなリファクタリングよりも小さな変更を好む傾向があります。
また、私たちが作成したエージェントにはマルチモーダル機能がありませんでした。モデル自体はビジョンが非常に優れているにもかかわらずです。これは見逃した機会だと思います。トレースを読むと、例えばmatplotlibのタスクで、テストスクリプトが画像を保存し、モデルは見ることなく「良さそうです」と言うような面白いケースがありました。入力の全ての側面、マルチモーダルを含めて、モデルが確実に理解するようにすることで、さらに改善の余地があります。
92%への到達については、私は詳しく調べていませんが、非常に興味があります。Sweetベンch verifiedの異なる試行で解決された全てのタスクの和集合を見てみたいと思います。ベンチマークには多くの提出があり、500のタスクのうち少なくとも1回は解決されたものがいくつあるのか興味深いところです。おそらく誰も解決していないものもあり、それらを見て、不可能なのか、それとも本当に難しくて人間にしかできないのか検討する価値があります。
言語モデルエージェントにとってまだ到達できない問題のカテゴリはありますか?
確かにあります。問題は、それらが本質的にアクセス不可能なのか、それとも説明の問題で不可能なのかということです。特に人間のレビューアーが4時間以上かかると評価したタスクは非常に難しく、ベンチマークではいくつか正解できましたが、あまり多くはありませんでした。
それらは実際に4時間未満で解決できたのでしょうか?人間が推定した時間との相関関係はありますか?あるいは、モデルには簡単だが人間には難しいという、逆説的な状況はありますか?
実際の統計は取っていませんが、それは興味深い分析になるでしょう。使用トークン数と難易度の相関、難易度と成功率の相関などです。興味深い発見があって、私の同僚のSimonは特に4時間以上かかると評価された非常に難しい問題に焦点を当てていました。彼は私が使ったものよりもはるかに詳細なプロンプトを作成し、最も困難な問題のサブセットでは高いスコアを達成しましたが、ベンチマーク全体では低いスコアでした。
私が作成したよりシンプルで基本的なプロンプトは、ベンチマーク全体では高いスコアを達成しましたが、最も困難な問題では低いスコアでした。詳細なプロンプトによって、モデルが簡単な問題を過度に複雑に考えてしまったようです。実際、Sweetベンチの問題の多くは単純な修正で解決できます。例えば「これはNoneの場合にクラッシュする」というような問題では、Noneをチェックするだけで良いのです。モデルに深く考えさせすると、円を描いて過度に複雑化してしまうことがあります。人間のエンジニアにもありがちな問題です。
難しい問題に最適なプロンプトが、簡単な問題には最適でない可能性があるという興味深い発見でした。ただし、この効果は非常に小さく、過度に気にする必要はないと思います。エージェントシステムを構築する際は、異なる種類の作業を分離するほど、各タスクに適したプロンプトを調整しやすくなります。
例えば、難しいプログラミング問題を解決するエージェントと、他の人が作成したものにテストファイルを書くエージェントでは、最適なプロンプトが大きく異なる可能性があります。分類を行い、問題を異なるプロンプトにルーティングするシステムを見かけますが、これは効果的なアプローチです。2つのプロンプトをよりシンプルで小さくでき、一方のプロンプトを作業する際に他のタスクに影響を与えるリスクがないため、関心の分離が上手くいきます。
他のモデルの動作について言及した点では、短いdiffを生成する傾向があるということですが、なぜでしょうか?「怠惰なモデル」の陰謀論のように、なぜコード全体を生成せずに途中で省略するのでしょうか?
これには2つの側面があります。1つは、難しい解決策よりも簡単な解決策を選ぶ傾向です。もう1つは、モデルが「...コードは同じ」のように省略する傾向についてです。インターネット上の人々がそういうことをするからだと思います。友人にコードの例を求めた場合、全体を書くことはなく、関連する部分だけを示すでしょう。時には全体が必要な場合もありますが、モデルは読心術ができないので、プロンプトで明示的に「省略なしで全体を書いてください」と指示するか、「関連する変更だけを示してください」と指示する必要があります。このような指示に従う能力を向上させていきたいと考えています。
ここで2つの参考情報を挙げたいと思います。昨日、DarioとLex Freedmanが5時間のポッドキャストを公開し、Darioが興味深い観察をしています。テキストでは冗長なモデルを嫌い、コードでは不十分だと不満を言うという矛盾です。その適切なバランスを見つけるのは難しいです。応答で無駄な言葉は避けたいですが、コードは完全に書いて欲しい、でも時にはdiffだけで良い場合もあります。アンスロピックは高速編集機能でこの問題に取り組んでいます。
もう1つ、プロンプトについて触れたいと思います。効果は小さいと言いましたが、プロンプトの選択による違いは確かにありました。Sweetベンチエージェントについて後で詳しく話しますが、1つのプロンプトに全ての性能を依存させる必要はないと考えています。アンスロピックはメタプロンプティング、プロンプトのためのプロンプトを上手く活用しています。なぜシンプルなタスクにはシンプルなプロンプト、難しいタスクには詳細なプロンプトを作るメタプロンプトを開発できないのでしょうか?少し手を抜いた言い方かもしれませんが、アンスロピックのワークベンチメタプロンプティングシステムを試してみることをお勧めします。最近アンスロピックのHQでビルドデイに参加しましたが、それは自己学習するAGIに最も近い体験でした。本当に魔法のようです。
そうですね、クロードはクロードのためのプロンプトを書くのが得意です。人間について考えると、非常に賢い人でもチェックリストや足場を使います。外科医は素晴らしい専門家でもチェックリストを使いますし、シニアエンジニアはジュニアエンジニアほど構造化された指示は必要ありませんが、ある程度の構造は維持したいものです。私はいつもモデルを擬人化して考え、同じタスクを人間に与えた場合にどの程度の指示が必要かを考えます。
エージェントアーキテクチャについて話しましょう。まず、実行時間については、完了したと判断するまで、または20万トークンのコンテキストウィンドウに達するまで実行を許可していますが、この基準はどのように決めたのでしょうか?
以前のエージェント作業では、モデルを特定のフローに強制的に進める、非常に硬直的なワークフローを構築することが多かったと思います。ある程度は小さいモデルや賢くないモデルでは必要かもしれませんが、私たちが探求したかったのは、クロードに本当の意味で主導権を与え、何も強制せず、問題へのアプローチ方法やステップを自由に決めさせることでした。
実際に行ったのは、最も極端なバージョンで、呼び出せるツールをいくつか与え、ツールを呼び出し、考え、完了したと判断するまでそれを続けることを許可するという、最小限のエージェントフレームワークを作ることでした。これは非常に上手く機能しています。特に新しいソネット3.5は自己修正が非常に優れています。クロードは失敗しても諦めず、別のアプローチを試みます。これは以前のモデルではあまり見られなかった特徴です。
既存のエージェントフレームワークの中には、ループを検出し、モデルが同じことを3回以上繰り返していないかをチェックするシステムを持つものがありましたが、モデルが賢くなるほど、そのような追加の足場は必要なくなります。そのため、モデルにツールを与え、完了したと判断するまでサンプリングとツール呼び出しを続けさせる、最も最小限のフレームワークを考案し、それを採用しました。
つまり、悪いパスはコンテキストから削除せず、何か試して失敗した場合はそのトークンを消費してしまうということですね?
はい、このアプローチの欠点は、非常にトークンを消費するということですが、3.5は以前のモデルほどスタックしなくなっています。最も最小限のことを試してみたかったのです。ただし、人間が4時間以上かかると評価した問題については、悪いパスを削除して20万トークン以内で達成できるようにする必要があるかもしれません。これは将来の研究課題ですが、これらのベンチマークで良い結果を出すためには必要ありません。
コンテキストウィンドウについて、もう1つ質問があります。Sweetベンチのような大規模コードベース用のコードインデクサーが多く登場していますが、それらは必要なかったのでしょうか?
必要ありませんでした。その理由は2つあります。1つはSweetベンチ特有の理由で、もう1つはより一般的な理由です。一般的な理由として、ソネットは「エージェント検索」と呼ばれる能力が非常に優れています。これは基本的に、モデルが何かを検索する方法を自分で決定し、結果を得て、さらに検索を続けるか完了するかを判断できるということです。
Sweetベンチのトレースの多くを見ると、モデルはディレクトリの表示、リストの作成、ファイルの表示などのツールを呼び出し、バグのあるファイルを見つけたと感じるまでそれを数回繰り返し、そのファイルの作業を始めます。これも、クロードに完全な自由を与えるという私たちのアプローチの一環です。ファイルを見つけるための固定的なシステムや検索システムに頼ることなく、クロードに全てを任せています。
ベクトルデータベースへの埋め込みも必要ありませんでしたね。はい、ただしこれは非常にトークンを消費し、多くのターンを必要とします。シングルターンで何かを実行したい場合は、RAGを使用し、最初のプロンプトに情報を詰め込む必要があります。
念のため説明すると、bashツールを使用してlsでファイルを探し、catでファイルをコンテキストに入れています。ファイル編集ツールにもviewというコマンドがあり、これはlsに似ていますが、モデルが大きなファイルで圧倒されないよう、ディレクトリの深さを2レベルまでに制限するなどの改良が加えられています。
プロンプトよりもツールの工学的な改良に力を入れました。エージェント検索について付け加えると、Sweetベンチ特有の理由として、多くのタスクがバグレポートで、スタックトレースが含まれているため、最初のプロンプトで場所が示されています。これはモデルが正しいファイルを見つけるのに非常に容易なケースです。一般的なコーディングアシスタントとして使用する場合、スタックトレースがなかったり、新機能の追加を求められたりすると、どのファイルを見るべきか判断するのがはるかに難しくなり、エージェント検索では時間がかかりすすぎるため、より徹底的な検索が必要になるかもしれません。
JavaScriptの世界で数年を過ごした者として、Sweetベンch JSがあれば面白いと思います。これらのスタックトレースは役に立たず、実際のコードの問題が発生している場所とは非常に断絶しています。
それを聞いて安心しました。私のフロントエンド経験の限界についても気が楽になりました。非常に複雑な状況に陥っていて、それが本当に必要だったのかは分かりません。Vercelの友人たちに聞けば必要だと言うでしょうが。ちなみにSweetベンchはマルチモーダルバージョンをリリースしました。JavaScript全体か大部分がJavaScriptで、視覚的な要素を持つものです。
それに取り組む予定はありますか?
リストには入っていて興味はありますが、保証はできません。ところで、全てのモデルラボ(アンスロピックを含む)が、自社のバグトラッカーツールでSweetベンchのような方法論を持つべきだと思います。これは進捗を追跡する一般的な方法論として使えます。
自社の内部コードベースで実行するのは面白いアイデアですね。ツール設計に多くの時間を費やされましたが、変更を加えるためのツールもあります。そこから学んだことで、AIIDEに採用して欲しい点はありますか?ファイルの表示や入力に特別な方法はありますか?
そのツールの核心は文字列置換です。ファイルの編集方法を指定する方法をいくつか試しましたが、文字列の既存バージョンと新しいバージョンをモデルに書かせて置き換える方法が最も信頼性が高いことが分かりました。他に試したのは、モデルに直接diffを書かせる方法や、ファイルを完全に再生成する方法です。後者は最も正確ですが、トークンを多く消費し、大きなファイルでは費用対効果が悪くなります。同じタスクを表現する方法は多々ありますが、モデルの正確性に大きな違いが出ます。
IDERには、これらの異なるファイル編集方法を探求し、結果を投稿している素晴らしいブログがあります。これは、プロンプトではなくツールを改良する必要があるという広い考え方の良い例だと思います。多くの人がLLMのツールを作るとき、コンピュータ用のAPIを書くように最小限の仕様だけを考えますが、そうするとモデルが使うのは本当に難しくなります。
私はいつもモデルを擬人化して考えます。初めてそれを読んだ開発者がそれを使おうとするところを想像してください。APIの仕様だけでなく、もっと良いものを作ることができます。説明に例を含め、どのように動作するかの詳細な説明を加えます。また、モデルが望む変更を表現する最も簡単な方法も考える必要があります。
ファイル編集を例に取ると、最も極端な例は、モデルにパッチファイルを文字通り書かせることです。パッチファイルでは、最初に変更される行数の合計が記載されており、モデルは実際に編集を書く前に変更行数を決める必要があります。正確な形式は定かではありませんが、このような形式もあり、これは他の表現方法よりも誤りを起こしにくいものがあります。
人間のインターフェース設計にどれだけの努力が払われているか考えてみてください。フロントエンドは基本的に同じことをより良いインターフェースで行うことに全てが費やされています。同じ量の注意と努力がエージェントコンピュータインターフェースの作成にも必要だと思います。
ACI（エージェントコンピュータインターフェース）についても議論してきましたが、これらのツールの一部はコンピュータ使用の一部としてリリースされ、人々に好評でした。オープンソースで公開されているので、確認することができます。
環境の要素でツールを補完するものについて興味があります。サンドボックスはありますか?それともDockerだけですか?それは遅くリソースを消費する可能性がありますが、他に何かありますか?
サンドボックスの実装の詳細については話せませんが、明らかにトレーニングのために安全で安全な高速なサンドボックスが必要です。エージェントサンドボックスに取り組んでいるスタートアップがいくつかあります。E2BはLeioが主導している親しい友人ですが、他にもデバッグ用のタイムトラベルのためにメモリスナップショットに焦点を当てているところや、マウスやキーボードを制御できるコンピュータ使用に取り組んでいるところもあります。ここでは提供するツールはコーディングエージェントのケースに非常に限定されています。bash、編集などです。
リリースしたコンピュータ使用デモはその拡張で、同じbashと編集ツールを持ちますが、スクリーンショットを取得し、マウスとキーボードを動かせるコンピュータツールも追加されています。より一般的なツールもあり、Sweetベンチの一部としてリリースしたツールはファイルの編集やbashに特化していますが、同時にそれは一般的でもあります。コマンドラインやファイル編集で行うことは全てこれらのツールでできます。
Sweetベンch特有のツール（例：テスト実行）を作るのではなく、これらのツールでどんなコンピュータターミナル作業もできるようにしたいと考えています。
テストについて質問がありましたね。テストライターツールがないのは、コードを生成してSweetベンchに対して実行するだけなので必要ないからですか?
これはSweetベンchの興味深い点の1つです。モデルの出力がテストされるテストは隠されています。これは基本的にモデルがテストを見て正確な解決策を書くことができないようにするためです。通常、モデルが最初に行うのは、エラーを再現する小さなスクリプトを書くことです。多くのSweetベンchタスクは「このバグを見つけました。これを実行するとこのエラーが出ます」というものなので、モデルは最初にそれを再現しようとし、そのスクリプトをミニテストとして再実行します。時々モデルは誤って他のテストを壊すバグを導入することがありますが、それについては知りません。
ツールを再設計する必要がありますか?例や、多くのAPIでのクエリパラメータQのように、モデルが再クエリする方が読むよりも簡単な場合があります。この時点でモデルはQを学習していると思いますが、ツールを構築する中で、LLM向けにCLIツールやAPIツールの構造を変更した方が良いと感じた点はありますか?
そこまで深く考えていませんが、全てをより人間に親しみやすくすること、より詳細なドキュメントと例を持つことは確かに重要です。例は本当に良いものです。Linuxコマンドラインを使用する際、-hやmanページを見る代わりに、実際の使用例が欲しいと思うことが多いですよね。100個のフラグを読むのではなく、最も一般的な例が欲しいのです。人間にとって役立つものは、モデルにとっても非常に役立ちます。
コードエージェントに与えられない1つのものはインターネットへのアクセスです。これをどのように設計するのか疑問です。Sweetベンchの問題の1つは、フォローアップの質問ができず、同様の実装を探すこともできないことです。これらは私がコードを修正しようとするときに行うことですが、それは不公平になるため、チートが容易すぎるためできません。しかし、それはこれらのエージェントに対して公平ではありません。実世界のエージェントであれば、当然インターネットへのアクセスを与えます。ベンチマークを通過しようとしているわけではないので。
これは人間にとって重要ですが、正直なところ、モデルは事前トレーニングから非常に多くの一般的な知識を持っているので、それほど重要ではありません。バージョニングの場合、知識のカットオフ後に登場した新しいものに取り組んでいる場合は、確かに重要です。
これは、Sweetベンchとコーディングエージェントの実際の顧客が気にすることの間の大きな違いの1つだと思います。インターネットアクセスと外部情報の取り込み方は1つの例です。もう1つは、実際のコーディングエージェントの場合、悪いプロンプトで何時間も無駄に時間を費やすのではなく、すぐに戻ってフォローアップの質問をし、何をすべきか詳細に理解してから数時間作業に取り掛かってほしいということです。
実際のタスクはこのような一発勝負のシステムではなく、エージェントとより対話的になると思います。現在、それを測定するベンチマークはありません。対話的なベンチマークがあると面白いかもしれません。Toベンチをご存知ですか?これは顧客サービスのベンチマークで、基本的に1つのLLMが支援を受ける顧客を演じ、もう1つのLLMがサポートエージェントを演じて対話し、問題を解決しようとします。
LMISの人たちと話しました。MTベンチも作成しました。MTSweetベンchが必要かもしれませんね。Sweetベンchタスクを開始する前に、タスクで何をしてほしいかについてフォローアップの質問に答える著者との往復があるかもしれません。もちろん、人間や想定ユーザーから正確な答えを得られないように注意する必要がありますが、これは興味深い試みになるでしょう。
既存のエージェント作業を見ると、例えばReplit's coding agentでは、最初にエージェントに計画を作成させ、人間にその計画を承認またはフィードバックを与える機会を提供するという素晴らしいUXを実現しています。一般的にエージェントにとって、最初に計画ステップを持つことは、下流のタスクのパフォーマンスを向上させるだけでなく、より良いUXを提供します。人間がフルタスクではなく計画をモデルと反復する方が、各ループの時間が短くなります。
人間が実装計画を承認した場合、最終結果はより監査可能で信頼できるものになります。Sweetベンch以外にも、実世界でのエージェント使用に非常に重要な要素が多くあると思います。
また、名前を挙げた例についていくつかコメントがあります。Copilotも計画段階を持っていますが、これらのアプローチは一般的にTwitterでは成功していません。プロンプトからコードではなく、プロンプト、計画、コードという流れになるため、少し摩擦がありますが、得られるものは大きいと思います。また、Devonの方法も良いと思います。計画を進めながら編集できます。
Replitとは開発者の日のプレゲームを開催し、彼らもマルチエージェントについて言及していました。2つのエージェントが互いにバウンスするような形です。これはエージェントが何を望んでいるかを明確にするためのプロンプトの中で、あなたが言及した例と似たアプローチだと思います。ただし、これは一般的に別のエージェントを呼び出すツールとして実装されると思います。サブエージェントのようなものですが、この考えについてどう思いますか?
十分に探求していませんが、人々がこれで良い成功を収めているのは確かに聞いています。同じLLMであっても、異なるペルソナを持つエージェントを持つことです。マルチエージェントについて多くの人が混乱するのは、異なるモデルが必要だと思うことですが、実際には通常、異なるプロンプトを持つ同じモデルです。異なるペルソナを持つことで、異なる考えや優先順位をもたらし、より徹底的で考え抜かれた応答を作成できることを見てきました。
欠点は、複雑さが増し、多くの追加トークンが必要になることです。何を重視するかによります。徹底的で詳細な計画が必要な場合は素晴らしいですが、単なる関数を書くだけなら、おそらくそこまでする必要はなく、それをする前に多くの呼び出しを行う必要はないでしょう。
プロンプトについて、なぜXMLタグはクロードで良いのでしょうか?最初は人々はXMLで運が良かっただけかもしれないと思っていましたが、自身のエージェントプロンプトでも使用しているので、明らかに機能しています。なぜあなたのモデルファミリーに特有なのでしょうか?
どこまで言えるか分かりませんが、内部的にXMLを好む歴史的な理由があると思います。また、より広い観点から言えば、特定の種類の出力を見ると、JSONには追加のオーバーヘッドがあります。JSONでコードを出力しようとすると、多くの追加のエスケープが必要になり、それは全体的なモデルのパフォーマンスに影響を与えます。一方、単一のXMLタグの中では、そのようなエスケープは必要ありません。
ただし、HTMLやXMLを書かせると、奇妙なエスケープの問題が発生するかもしれません。確信は持てませんが、歴史的な理由とエスケープのオーバーヘッドが少ないことが理由です。他のモデルでも使用していますが, example1開始とexample1終了のように、開始が終了に結びついていることを確認する良い方法です。括弧は記述的ではないためです。
それが私の単純な理由です。XMLはクロードだけでなく、誰にとっても良いものです。クロードは単に最初に普及させただけです。個人的にもJSONよりもXMLを読むことを好みます。
他に見過ごされている詳細はありますか?例えば、絶対パスと相対パスの話がありましたが、他に面白い発見はありますか?
はい、ツールの反復について良い例だと思います。プロンプトのエンジニアリングだけでなく、ツールを書いてモデルに与え、モデルがツールをどのように使おうとするかのトランスクリプトを多く読むことを推奨します。そうすることで、モデルがツールを誤解したり間違えたりする領域を見つけ、ツールをフールプルーフ(失敗しにくい)にすることができます。
「ポカヨケ」という日本語の用語があり、ツールをミステイクプルーフにすることを意味します。古典的な例では、どちらの向きでも差し込めるプラグは危険ですが、非対称にすることで、一方向にしか差し込めないようにします。これはより良いツールです。
絶対パスの例では、これらのツールをテストしている際に、モデルがcdで別のディレクトリに移動すると、ツールを使用する際に混乱することがあることに気付きました。現在は異なるディレクトリにいるため、パスが一致しません。そこで、ツールが常に絶対パスを要求するように強制することにしました。
モデルにとって理解しやすく、どこにいるのか、ファイルがどこにあるのかを知っています。絶対パスを使用すると、どこにいても間違えることはありません。このような反復により、モデルにとってフールプルーフなツールを作ることができました。
他にも、モデルがVimを開くと戻ってこないことに気付きました。ツールはテキストの入出力だけで、対話的ではないからです。モデルがVimから抜け出せないというのではなく、ツールがコンピュータに接続される方法が対話的ではありません。誰もVimから中にいる誰もが出られないという伝説があります（笑）。基本的にツールの説明に「戻らないコマンドを実行しないでください」という指示を追加しました。バックグラウンドで実行する必要がある場合は、アンパサンドを付けて実行するようにと記載しました。ツール自体にそのような指示を入れることで、モデルの助けになります。全体のプロンプトではなく、ツール内にこのような情報を入れることを、もっと活用すべきだと思います。
関数呼び出しとツール使用のAPIを作成した後、実際にSweetベンchで広く使用することになりましたが、APIの作成者から使用者になって気付いた驚きや、今後変更したい点はありますか?
もう少しシンプルなSDKを作りたいですね。私が思うに、現状ではある程度強制的に、完全なJSONスキーマを記述するというベストプラクティスを人々に課しているのですが、ツールとしてPython関数を直接渡せるようになると本当に良いと思います。多くのインフラがあると思います。Anthropic向けに特化している人がいるかどうかは分かりませんが、Jeremy HowardとSimon Willisonは、彼らなりのClaude特有の作業をしていますね。Claudetですね、まさにその通りです。
swe agentについても少し時間を取りたいと思います。非常に汎用的なフレームワークのように見えますが、同じ著者であるsweep benchを選んだ理由は何かありますか?
主な理由は、同じ著者のsweep benchを使いたかったからです。最も安全で中立的な選択肢に感じましたし、品質も非常に高く、作業しやすかったです。彼らの基盤となるフレームワークは、think-act-observeというループを通じて動作するのですが、これは私たちが望んでいたものよりも少しハードコードされていましたが、それでも非常に汎用的で、私たちのエージェントの出発点として良い選択でした。また、すでにsweep benchの人々と直接やり取りしていたので、著者を知っているという点でも扱いやすかったですね。
これらは一見バラバラに見えますが、人々の出身校を見ると全て繋がってきます。sweep benchとswe agentはプリンストン大学のグループですね。私たちはシューをポッドキャストに招き、彼はreactパラダイムを考案しました。think-act-observeは全てreactです。彼らは皆友人なんです。
その通りです。実際、私たちの提出物のトレースを見ると、think-act-observeがログに記録されているのが分かります。印刷用のコードさえ変更していません。実際には、モデルは必要に応じて思考プロセスを挟まずに複数の関数呼び出しを連続して行うことができますが、フレームワークの出発点としてs agentから引き継いだ類似点が多くあります。
他のエージェントフレームワークについてはどう思いますか?非常にシンプルなものから非常に複雑なものまで、crew AIやLangGraphなど、様々ありますよね。
詳しく調べたわけではありませんが、エージェントフレームワーク全般について言えることは、確かにボイラープレートコードの削減には役立ちますが、エージェントの構築を簡単にしすぎるという欠点があります。必要以上に複雑なシステムを素早く構築してしまい、1つのプロンプトの代わりに5つのエージェントが対話して作業するような状況になってしまいます。フレームワークのおかげで10行程度で実装できてしまうため、過度に複雑なものを作ってしまうのです。
私は、できるだけフレームワークを使わずに始めることをお勧めします。そうすることで、生のプロンプトに近い状態で、何が起きているかを直接理解できます。これらのフレームワークは、全てを魔法のように見せようとするあまり、モデルの実際のプロンプトと出力を隠してしまい、デバッグを非常に難しくします。確かにボイラープレートの削減には役立ちますが、実際に何が起きているかを分かりにくくし、複雑さを簡単に追加できてしまうという代償があります。ですから、最初はスクラッチから始めることをお勧めします。そんなに大変ではありませんよ。
ツールのフレームワークについてはどうですか?あなたが構築したようなツールを、すでに適切にキュレーションされた形で簡単に入手できる方が良いと思いますか?例えば、あなたが作ったBashツールを簡単に入手でき、定義を維持管理してくれるような。ツール共有の形式化についてどう考えますか?
それは確かに私たちも検討したい分野です。広く適用可能な汎用ツールには確かに余地があると思います。ただし同時に、これらを構築する多くの人々は、より具体的な目的を持っています。ホビイストやデモには便利かもしれませんが、最終的なアプリケーションはカスタマイズされたものになるでしょう。私たちはモデルがどんなツールでも優れた性能を発揮できることを重視していますが、これは確かに検討すべき分野です。
つまり、今のところは全てカスタマイズで、フレームワークなどは使わないということですね?
はい、私が見た中で最も良いのは、良いユーティリティ関数を作って、それらを構築ブロックとして使うというアプローチです。
そうですね。私もutilsフォルダを持っていて、そこに全てのスクリプトを入れています。私のフレームワークは基本的にcall_anthropicという関数で、必要なデフォルト値を全て設定しています。
そうですね。utilsフォルダには常にスタートアップが隠れているようなものです。十分に使い込めば、それ自体がスタートアップになり得ますよね。
ターンの最大長について興味があるのですが、最長の実行はどれくらいでしたか?
実際には、200kのコンテキストに達するまでは基本的に無限のターン数が可能でした。正確な数字は確認していませんが、コンテキストを使い果たしてしまったケースでは100ターンを超えていたと思います。成功した最長の実行も、確か100ターンは超えていたはずです。コーヒーブレイク程度の時間ですね。
しかし、これらのタスクの中には本当に難しいものもあり、多くの試行が必要になることがあります。人間が4時間かかるようなタスクを考えてみてください。その間に読むファイルの数や、ファイルを編集する回数を考えると、100ターンよりもずっと多くなります。Twitterを開いて気が散る回数は別として。
もしもっと多くの計算リソースがあれば、それによってどれくらい性能が向上すると思いますか?数千ターンとか、そういったオーダーで考えた場合、どれくらい良くなるでしょうか?
それは分かりません。これは一般的にエージェントの研究における未開拓の分野の1つだと思います。メモリをどのように扱い、単純に追加していく以上のことをどのようにして、コンテキスト長を超えて作業を行えるようにするかということです。
先ほど悪いパスの刈り込みについて触れましたが、ロールバックして「このパスは避けるべき」と要約するような方法について、興味深い研究がたくさんあると思います。一度に200k以上のトークンを使用することなく、はるかに多くのトークンを使用できる可能性があり、それは非常に興味深いです。最も重要なのは、モデルが異なるアプローチを試みて学んだことを、損失なく要約して戻すことができるかどうかだと思います。それが大きな課題です。
異なるモデルについてはどうでしょうか?例えばHaikuは非常に高速なので、これらの小さなタスクの多くをHaikuに任せて、その結果を上位のモデルに戻すというのはどうでしょう。Cursorは確かファイル編集用に別のモデルを使っていたと思います。たしかLex Fridmanのポッドキャストで、より大きなモデルでコードを書き、別のモデルでそれを適用すると言っていたと思います。
そういったアプローチには多くの興味深い可能性があると思います。高速な適用については、Fireworksとのポッドキャストで取り上げた投機的デコーディングに関連する話題ですね。入力トークンの削減についても非常に興味深い可能性があります。特にモデルが1万行のファイルを読もうとする場合など、それは多くのトークンを必要とします。その大部分は実際には関係ないので、Haikuにファイルを読ませて最も関連する関数だけを抽出し、Sonnetにはそれだけを読ませることで90%のトークンを節約できるかもしれません。
そういった方向性には本当に興味深い可能性があると思います。繰り返しになりますが、私たちは最もシンプルで最小限のことを行い、それが機能することを示そうとしただけです。エージェントコミュニティが私たちのモデルの上にそういったものを構築してくれることを本当に期待しています。だからこそ、これらのツールをリリースしているのです。私たちはもうsweep benchへの提出を増やしたり、プロンプトエンジニアリングを行ってより大きなシステムを構築したりはしません。エコシステムの人々が私たちのモデルの上でそれを行うことを望んでいます。
実際、3.5 Haikuをあなたのツールで試したところ40.6点を記録しましたね。
はい、とても良い成績でした。Haiku自体が非常に賢いのは素晴らしいことです。まだ2つのモデルを組み合わせる実験は行っていませんが、それが興味深い点の1つです。3.5 Haikuがsweep benchで良い成績を収めたことは、私たちの最小・最速のモデルでさえ、エージェント的な思考と難しい問題への取り組みが非常に得意だということを示しています。もはや単純なテキスト生成だけのものではありません。
お話しできないのは承知していますが、Sonnetが最高のモデルであるはずはないですよね。Opusがありますし、いずれ新しいOpusがリリースされれば、OpusとSonnetを組み合わせると非常に良さそうです。s agentとOpusを組み合わせた実験結果はありますが、それは公式のsweep benchチームによるもので、あなたたちのものではありませんよね。
やってみたいと思いますが...基本的にモデル名を変更するだけですよね。提出はしていませんが、モデルカードには比較として含めていたと思います。実際、新しいSonnetとHaikuは両方とも、オリジナルのOpusを上回る性能を示しています。
はい、それは確認しました。少し見つけにくいですが。
あまり興味深いスコアではなかったので、ベンチマークに提出する必要性は感じませんでした。
コンピュータ使用の話題に移ってもよろしいですか?他に何かありますか?
大丈夫だと思います。sweep bench関連で他に何かあるか考えていますが...特にsweep benchに限らず、エージェントの構築についての考えでも構いません。あなたはこのリーダーボードに到達した数少ない人の一人として、コーディングエージェントを構築してきましたからね。
驚くほど、良い原則さえあれば最先端に到達するのはそれほど難しくないですよね。まだまだ手付かずの部分がたくさんありますが、コーディングエージェントのスタートアップを立ち上げるとしたら、次は何をすべきだと思いますか?
私にとって本当に興味深い質問は、ベンチマークと実際の顧客が望むものとの違いです。次回コーディングエージェントのスタートアップをポッドキャストに招いた際には、その違いについて聞いてみるといいかもしれません。
素晴らしい提案ですね。私も最近、少し落ち着いてきたように感じます。スタートアップがトレースの関係でsweep benchへの提出を控えているようですね。Cosignは確かfull sweep benchで50点台を記録しましたが、トレースの提出を拒否したため却下されましたよね。
そうですね、知的財産の問題ですね。それは理解できます。
ところで明日、Boltとお話しする予定です。彼らとは確かケーススタディを公開していましたよね。直接関わってはいなかったと思いますが。彼らはClaudeをとても気に入っていて、今年最大のローンチの一つでしたね。
実は、私たちは今adeptの元オフィスに座っているんです。私の見方では、Anthropicはadeptをフィーチャーとしてリリースしたようなものですね。まだベータ版の機能ですが。
コンピュータ使用機能を初めて試したとき、どんな感じでしたか?Claudeがその段階に達していることは明らかでしたか?
私にとっては少し驚きでした。実は休暇から戻ってきたら、みんなが「コンピュータ使用が動くようになった」と言っていて。最初にGoogleに行かせてみた後、Minecraftをプレイさせてみたのですが、実際にMinecraftをインストールして起動したのを見て「わ、これはすごい」と思いました。これは本当にコンピュータを使えるんだなと。確かにまだベータ版で、得意でない部分もありますが、とても興奮しています。
最も広い意味で、新しいことが可能になっただけでなく、ツール使用を実装するためのフリクションが大幅に低減されたことが重要だと思います。以前Cobalt Roboticsで働いていた時の話を例に挙げましょう。私たちはロボットにエレベーターを使って階間を移動させ、ビル全体をカバーさせたかったのです。最初のアプローチは、エレベーター会社とのAPI統合でした。実際にAPIを持っている会社もあり、リクエストを送ってエレベーターを動かすことができました。
しかし、新しい会社との統合には毎回6ヶ月ほどかかりました。彼らの動きは非常に遅く、あまり関心を示しませんでした。エレベーターに関しては、会社との統合が済んだ後でも、使用したいエレベーターにAPIボックスを物理的に設置する必要があり、それにも6ヶ月かかることがありました。非常に遅いプロセスでした。
結局、これが顧客へのデプロイメントを大幅に遅らせていることに気づき、「ロボットにアームを付けたらどうだろう」と考えました。小さなアームを追加してエレベーターのボタンを物理的に押せるようにし、コンピュータビジョンを使ってこれを実現しました。これなら1日でデプロイできました。APIと比べると遅く、信頼性も若干劣りました。時々ボタンを押し損ねて再試行が必要になりましたが、最終的には目的を達成できました。
これは現在のコンピュータ使用機能の類推として見ることができます。今日コンピュータでできることは、おそらくツール使用としてAPIと統合することもできますが、それには多くのソフトウェアエンジニアリングが必要で、統合のために多くの作業が必要です。コンピュータ使用なら、単にブラウザを与えて必要なシステムにログインさせるだけで、すぐに動作を開始できます。
この摩擦の低減は非常に刺激的だと思います。例えば、カスタマーサポートチームを考えてみてください。カスタマーサポートボットを導入したいけれど、様々なシステムと統合する必要があり、チームにエンジニアがいない場合でも、必要なシステムにログインしたブラウザを与えるだけで、1日で完全に統合されたカスタマーサポートボットを稼働させることができます。
あるいは、World of Warcraftでの農業など、非常に価値の高いユースケースもありますね。これは、ロボティクスや自動運転における最も古い問題の一つ、つまりビジョンで運転するか特別なツールを使うかという問題に似ています。ビジョンは全てのツールを統一する普遍的なツールですが、トレードオフもあります。そういった状況は出てくるでしょう。
今週のポッドキャストで、Dustのスタン・ポーが、それが重要な作業手段になる未来は見ていないと言っていました。ハイボリュームのユースケースにはAPIを、ロングテールにはコンピュータ使用を、という分離があり得るかもしれませんね。
その通りです。コンピュータ使用でプロトタイプを作り、「これは機能している、顧客がこの機能を採用している」となったら、APIに変換してより高速で少ないトークンで実行できるようにする、というのはありですね。
コンピュータ使用エージェントがAPIを理解して自分自身を置き換え、完全に退場するというのは面白いかもしれません。
本当に面白いですね。もし私がRPA（Robotic Process Automation）企業を経営していたら...RPAはいつも同じ順序で現れる処理をスクリプト化するものです。基本的に必要なのは、LLMにそのスクリプトをコーディングさせることで、そうすればコンピュータ使用から非コンピュータ使用のSWに自然に移行できます。
あるいはClaudeのコンピュータ使用アクションを保存されたスクリプトに変換して、それを繰り返し実行できるようにする方法もありますね。そのような記録は興味深いかもしれません。
コンピュータ使用に関して、サンドボックスのハーネスを提供しないことにした理由は何ですか?「自己責任で実行してください」というドキュメントだけではなく、VMやDockerシステムと一緒にリリースしましたよね。ただし、これは実際のコンピュータ用ではなく、Docker内で実行されるブラウザ用ですよね。
その主な理由は、セキュリティです。モデルは何でもできてしまうので、サンドボックスを提供し、少なくともデフォルトの体験としては、ユーザー自身のコンピュータでは実行させないようにしたかったのです。デフォルトを安全にすることが私たちにとって最善の方法だと考えています。すぐに誰かが自分のデスクトップで実行できるように修正を加えましたが、それは構いません。ただ、それをAnthropicの公式な方法にはしたくありませんでした。
また、製品の観点から言えば、現在はまだベータ版なので、最も有用なユースケースの多くでは、実際にサンドボックスが望ましいと思います。何も壊せない環境で、与えたものだけにアクセスできる状態が欲しいはずです。また、自分のコンピュータを使用している場合、同時に使用することはできません。実際には、別の画面を持つことが望ましいと思います。一つのラップトップでペアプログラミングするのではなく、二台持つべきですね。
誰もがコンピュータ使用のClaudeを動かすためのサブラップトップを持つべきです。自分のコンピュータで特別に何かをさせたい場合を除けば、リモートマシンにシェルで接続して、時々チェックするような感じになると思います。
半分の視聴者には若すぎて覚えていないかもしれませんが、Citrixのようなデスクトップ体験を思い出します。他の誰かが操作しているマシンにリモートでアクセスするような感じでした。長い間、それが企業のコンピューティングの方法でした。
コンピュータ使用の他の意味合いについてはどうですか?面白いデモですか、それともAnthropicの未来ですか?
私はとても興奮しています。コンピュータ使用は、多くの反復的な作業に最適だと思います。例えば、コーディングエージェントが作成したフロントエンドをテストするような例を見たことがあります。端末ベースのエージェントだけでは現在できないことの多くで、コンピュータ使用を使用してループを閉じることができるのは非常に興味深いと思います。
エンドツーエンドのテスト、特にフロントエンドとウェブのテストは、私がとても期待している分野です。
アマンダ・アソル（クラウド責任者）も話していましたが、昼休みにリサーチのアイデアを生成させるなど。コンピュータ使用という名前は非常に実用的で、何かを実行することを想定していますが、時には実行することではなく、思考することが重要で、その思考プロセスでコンピュータを使用することもあります。
sweep benchを解くにしても、インターネットを使用したり、コンピュータを使用したり、視覚を使用したりすることを許可されるべきです。ベンチマークのために良い子でいようとして制限を課していますが、実際には完全なAIは全てのことができるようになるはずです。
確かにGoogle検索もできるようになるでしょうね。インスピレーションを得ることもできるでしょう。
締めくくる前に、ロボティクスについて少し話しましょう。特に自社の宣伝をしようとしない人の意見として、人々は常に興味を持っています。AIロボティクスの現状は、過小評価されているでしょうか、それとも過大評価されているでしょうか?
これは私個人の意見で、Anthropicの見解ではないことを断っておきます。また、燃え尽きたロボティクス創業者としての立場からの意見なので、その点も考慮に入れてください。
ポジティブな面から言えば、過去5年間で本当に驚くべき進歩があり、それがロボティクスの大きなブレークスルーになると思います。
第一に、汎用言語モデルです。ロボティクスには古い格言があって、「タスクを完全に記述するのがタスクを実行するよりも難しければ、それは自動化できない」というものです。なぜなら、ロボットにやり方を教えるだけでも、自分で実行するより多くの労力が必要になるからです。LLMはこれを解決しました。もはや全ての細かいことを徹底的にプログラムする必要はありません。システムには常識があり、ルーベンサンドイッチの作り方を知っています。以前なら、料理に関することは、エンジニアチームがレシピを全てハードコードしなければならず、長いリストになると大変でした。常識を取り入れることで、このタスクの記述という大きな問題が解決されました。
第二の大きなイノベーションは、パスプランニングのための拡散モデルです。この研究の多くはトヨタ研究所から生まれ、Physical Intelligence（Pi）やチェルシー・フィンのスタンフォードのスタートアップなど、多くのスタートアップがこれに取り組んでいます。基本的な考え方は、拡散モデル自体というよりも、拡散からのインスピレーションを少し取り入れたもので、エンドツーエンドの動作制御を学習する方法です。
以前のロボティクスの動作制御は、全てハードコードされていました。明示的な動きをプログラムするか、明示的な目標をプログラムして最短経路を見つけるための最適化ライブラリを使用するかのどちらかでした。現在は、多くのデモンストレーションを与えるだけで、拡散モデルと同様に、例から学習することができます。コップを拾い上げるとはどういうことかを学習し、テキストによって条件付けられた拡散モデルのように、同じモデルに多くの異なるタスクを学習させることができます。
期待は、これらが一般化を始めることです。コーヒーカップや本を拾う訓練をしておけば、バックパックを拾えと言われたときに、それを訓練したことがなくても対応できるようになります。これがホーリーグレイルです。500の異なるタスクで訓練すれば、必要な何でもできるように本当に一般化するのです。これはまだ大きな課題で、ある程度の一般化は測定されていますが、結局のところ、LLMと同じように、誰も訓練データで見たことのないことができることを本当に気にするでしょうか?
家庭用ロボットなら、人々が本当に望むことは100個程度で、それらについて良い訓練を確実に行えば良いのです。本当に気にすべきなのは、タスク内での一般化です。例えば、見たことのない特定のコーヒーマグでも拾えるかどうかです。そしてこれらのモデルは、そういったことは非常に得意なようです。
これらが現在ロボティクスに有利に働いている2つの大きな要素です。常識のためのLLMと、拡散にインスパイアされたパスプランニングアルゴリズムです。これは非常に有望ですが、誇大宣伝も多いと思います。現在の状況は、10年前の自動運転車の状況に似ていると思います。
とても素晴らしいデモがあります。10年前には高速道路や街中を走る車のビデオがありましたが、安全運転手付きでした。そこから、今日私がWaymoに乗れるようになるまでに長い時間がかかりました。それでもWaymoはサンフランシスコと他の数都市でしか運行していません。これらのものが everywhere に行き着き、全てのエッジケースをカバーするには長い時間がかかると思います。
ロボティクスについて、私は信頼性が制限要因になると思います。これらのモデルは洗濯や食器洗いのデモは本当に上手くできますが、99%の成功率でも、それは実際にはとても厄介です。人間はこれらのタスクに非常に長けています。100枚に1枚の割合で皿を割るロボットを家に置きたいと思う人はいないでしょう。工場なら、100箱に1箱の割合で落として中身を壊すようなロボットは確実に望まれません。
これらが本当に有用になるためには、自動運転車と同様に、非常に高い信頼性レベルに到達する必要があります。これらのモデルが95%の信頼性から99.9%に移行するのがどれほど難しいのか、私にはわかりません。それが大きな課題になると思います。
また、これらのユニットエコノミクスがどれほど良くなるか、少し懐疑的です。これらのロボットは製造コストが非常に高くなるでしょう。単に労働力を1対1で置き換えようとするなら、それは請求できる上限を設定することになります。そのため、あまり良いビジネスにはならないように思えます。自動運転車産業についても同じ懸念を持っています。
アプリケーションの大部分は、実際には製造機械の古いものを、特に数ミリずれただけで全体が台無しになってしまうような非常に精密な作業に適応させることになると思いますか?それとも、まったく新しいユースケースの方が興味深いでしょうか?
従来の製造用ロボットの多くを置き換えるのは非常に難しいと思います。全てが精密さに依存しているからです。99%の精度しか達成できないモデルがあった場合、1%の車の溶接が間違った場所にあるのは災害になります。
製造業の多くは、可能な限り変動と不確実性を排除することに関するものです。
ハードウェアについてはどうですか?ロボティクスで働く私の友人の多くは、サーボが故障するなどの大きな問題を抱えていて、修理に時間がかかると言っています。これは足かせになっていますか?それともソフトウェアはまだそれほど進んでいないのでしょうか?
両方だと思います。ここ数年でソフトウェアの方が大きな進歩を遂げており、現在の人型ロボット企業の多くは本当に素晴らしいハードウェアを構築しようとしています。ハードウェアは本当に難しいですね。
典型的なのは、最初のロボットを作って動作すると「よし」となりますが、10台作ると5台は動作し、3台は半分の時間しか動作せず、2台は全く動作しません。全く同じように作ったのに、なぜかわからないのです。現実の世界には、ソフトウェアにはない詳細なレベルの違いがあります。
例えば、書いた全てのforループの一部が動作せず、一部が他より遅いとしたらどうでしょう?それにどう対処しますか?顧客に配布する各バイナリで、それらのforループが少しずつ異なるとしたら?一つのものを作ることではなく、何かを繰り返し作って確実に品質を維持することが、ハードウェアを本当に難しくしています。
例えば、100個のモーターのバッチを購入すると、それぞれのモーターが同じ入力コマンドに対して少し異なる挙動を示します。これはCobalt Roboticsでの実体験です。
実際の恐ろしい話をしましょう。何年も前のCobaltで、ロボットにUSB接続の熱カメラを搭載していました。これは大きな間違いでした。USBは信頼性の高いプロトコルではなく、エラーが発生した場合にユーザーが抜き差しできることを前提に設計されています。そのため、通常USBデバイスは、非常に高い信頼性レベルで設計されていません。ユーザーが抜き差しすれば良いという前提があるからです。
ある時点で、これらの熱カメラの多くが故障し始め、原因がわかりませんでした。チームに「何か変わったことはある?ソフトウェアは変更された?ハードウェアの設計は変更された?」と尋ね、カーネルログを調べてこのデバイスで何が起きているのか調査しました。
最終的に、調達担当者が「あ、そういえば去年の夏にUSBケーブルの新しいベンダーを見つけたんです」と言いました。「ベンダーを変えたの?」「はい、全く同じケーブルで1ドル安かったので」。これが問題でした。このケーブルは抵抗が少し悪かったり、EMI干渉が少し悪かったりして、ほとんどの時間は動作しましたが、1%の確率でカメラが故障し、システムの大部分を再起動する必要がありました。全く同じ仕様の2つのUSBケーブルでも、わずかな違いがあったのです。
リスナーの方々のために、Josh AlriとINBのエピソードで、数万のGPUを購入しても、その一部は数学計算を正しく行えないという話がありました。
そうですね。不良品のバッチを見つけるためにテストを実行して、メーカーに返品することになります。GPUが正しく計算できないんです。これが現実です。現実の世界にはこのレベルの詳細な違いがあります。
Eric Jangは、Googleでのロボティクス研究の後、1Xに参加しました。彼のTwitterでは時々、ハードウェアとサプライチェーンに関する不満を見かけます。私たちは知り合いで、時々冗談を言い合います。私はロボティクスからAIに移り、彼はAIからロボティクスに移りました。
非常に有望ですね。実世界のTAM（総市場規模）は無限です。ただし、はるかに難しいです。ソフトウェアエージェントに取り組む理由の一つとして人々に伝えているのは、それらは無限に複製可能で、常に同じように動作するということです。主にPythonを使用する場合を除いて。
あなたは少しアルファ情報を漏らしましたね。見逃したくないので掘り下げたいと思います。自動運転をビジネスとして懐疑的だと言いましたが、これについて少し詳しく聞かせてください。Waymoの公開数字を見ると、週に100回以上のWaymo乗車があり、1回25ドルと仮定すると、年間収益は1億3000万ドルのペースです。いずれは投資を回収できるはずですよね。何が問題なのでしょうか?
専門家ではないし、財務状況も知りませんが、私が心配しているのは、Uberと比較した場合です。Uber運転手が年間いくら稼ぐかわかりませんが、それをWaymoが同じ期間で稼ぐ収益とします。これらの車は高価です。収益性に達するかどうかではなく、キャッシュコンバージョンサイクルの問題です。
1台のWaymoをどれだけ安く作れるか、それとUber運転手が取り分として得る相当額を比較すると、どうなるでしょうか?Uber運転手の場合、全ての収益を得ているわけではないことを忘れないでください。車のコストや減価償却を考慮する必要があります。Waymoが1台あたりどれだけの利益を上げられるかについて、私は懐疑的です。
Waymoは事前に評価する必要があります。Cクラスは11万ドルくらいで、LiDARもあります。
そうですね、それが数年分になります。
その他に何かありますか?最後の考え、行動への呼びかけ、愚痴など、どうぞご自由に。
世界中でより多くのLLMエージェントが活動するのを見るのがとても楽しみです。最大の制限要因になり始めるのは、これらのエージェントの出力を人々が信頼できるかどうかだと思います。5時間かけて作業をして何かを持ち帰ってきたエージェントの出力を、どうやって信頼するのか。そのエージェントの作業を信頼できない場合、それは全く価値がなかったことになります。
そのため、作業を行うだけでなく、信頼できる監査可能な方法で行い、人間に対して「これがどのように機能し、なぜそうなったのか」を正確に説明できることが本当に重要になると思います。
ありがとうございました。
ありがとうございます、素晴らしかったです。

いいなと思ったら応援しよう！