クロード3.7ソネット、BeeAIエージェント、Granite 3.2、そして創発的な目標不一致

AGIに仕事を奪われたい
この記事は約28分で読めます。

16,496 文字

https://www.youtube.com/watch?v=561dyCTvGlQ

ケイト・ソウルはGraniteのテクニカルプロダクトマネジメントディレクターです。ケイト、番組へようこそ。あなたの好みは何ですか?
私はゼルダの「ブレス・オブ・ザ・ワイルド」ビデオゲームシリーズが本当に好きです。そのシリーズはとても素晴らしいです。
マヤ・ムラドはAIインキュベーションのプロダクトマネージャーです。マヤ、番組へようこそ。好きなビデオゲームは?
GTAと言わざるを得ません。
素晴らしいですね。そして、カウタル・エル・マグラウイはAIエンジニアリング、AIハードウェアセンターの主任研究科学者です。カウタル、あなたはどう思いますか?
マインクラフトが好きです。それは文化的現象で、プレイヤーがこのサンドボックス環境で建設や探索ができるのが非常に面白いと思います。
以上のことと、さらに多くのことを今日の「Mixture of Experts」でお届けします。私はティム・ファンです。「Mixture of Experts」へようこそ。毎週、MoEは人工知能の最大のヘッドラインを理解するために必要な専門的なチャット、雑談、技術的分析をお届けしています。いつものように、取り上げることがたくさんあります。BeeAIからの新しい発表、Graniteの新リリース、創発的な目標不一致に関する非常に興味深い論文などです。
しかしまず、クロード3.7ソネットとクロードコードについて話したいと思います。これは今週の製品面での大きな発表の一つです。Anthropicは最新世代の主力モデルであるソネット、3.7モデル、そして彼らが実験してきた新しいコーディングエージェントを発表しました。
しかし、まず3.7から始めましょう。マヤ、あなたはこの新しいモデルを試す機会があったと聞いています。あなたの最初の印象や、上手く機能していること、そうでないこと、そして全体的にどう思うかについて教えてください。
はい、試してみました。実はバージョンアップが0.2だけだったことに驚きました。前回は2.5で、コーディングには優れていたものの、文章作成では私の第一選択ではありませんでした。しかし2.7を文章作成タスクで試してみたところ、本当に感動しました。クラウドバージョンのモデルで本当に目立っているのは、より微妙な体験の強調です。
彼らはアップル方式のように、ある程度意見のある体験を提供するために、トレーニングデータをキュレーションしているように思います。クラウドが行っていることとOpenAIがモデルで行っていることとの間に隔たりが生まれつつあるのが見え始めています。
それは本当に興味深いですね。以前の番組でもこれらの大きな基盤モデル間の競争がどのように進化していくかについて話しました。その部分は非常に興味深いと思います。Anthropicはほとんどスタイルのゲームをしているような感じがしませんか?そして、戦いが能力から新しいものへと移行しているような気がするのですが、あなたはどう思いますか?
マヤのAnthropicをこの分野のアップル相当と比較する例えが本当に気に入りました。3.7リリースで彼らが行ったことの一つで私が本当に興奮しているのは、推論機能をリリースしたことですが、それを非常に実用的な方法で行いました。基本的にどれだけ支出したいか、つまりどれだけのトークンを生成したいかを選択できる方法です。すべてのタスクに大量の推論が必要なわけではないからです。
より複雑なことがある場合に、レイテンシーとトークン生成のコストの両方の観点から「より多く支払う」能力を基本的に与えてくれます。これは本当に使いやすく実用的な推論へのアプローチで、まだ見たことがないものですが、すぐに標準になると思います。
実際、これが唯一の方法です。推論がどこで価値を追加できるかを考えると、推論をダイヤルとして選択的に適用できるものとして持つ必要があります。「2+2は何ですか?」という質問に対しても、5段落の推論と大量のレイテンシーが返ってくるわけではありません。
それが登場するのを見るのは本当に面白いですね。ある意味で新しいコンピューティングのパラダイムのようなものです。以前はただ「このプログラムを実行してほしい」と言えば、コンピュータはそのプログラムを実行するだけでした。しかし今では「そして本当に頑張ってほしい」というのを別のオプションとして指定する必要があるようなものです。それをオンにしたりオフにしたりするのを自然にする方法を見つけるのは興味深いですね。
カウタル、あなたに向けたいのですが、興味深い点は単に新しいモデルが登場したということだけでなく、彼らがこのコーディングエージェント空間でプレイし始めていることです。ブログ記事を読むと面白いことに、彼らは「私たちは推論とモデルが一体となった統合体験を信じています、すべてが完全に統合されるべきです。ああ、ちなみに、私たちは完全に別のものも発表し、立ち上げています」と言っています。
なぜ彼らはクロードコードを独立した機能として分割しているのかについて興味があります。これが時間とともに独自のものになっていくのか、それとも彼らが実験しているだけで、最終的にはすべてが一つの体験に統合されるのかについてどう思いますか?
それは素晴らしい質問です。私も彼らがコードを他のモデルから分離しているのに少し驚きました。ただ、彼らはおそらくこのエージェントデコーディングに焦点を当てており、それは現在まだ限定的な研究プレビューの段階です。彼らはまだそれを実験段階と考えているのだと思いますし、最終的には彼らの他のモデルや彼らが持つより大きなビジョンと統合されることを願っています。
なぜなら、ここでは彼らはコードの検索、コードの読み取り、ファイルの編集など、コード関連のタスクを自律的に実行することによって開発者を支援する方法に焦点を当てようとしているからです。それがまだ完全に統合されていない理由は、まだこの限定的な研究プレビュー段階にあり、独自の評価と焦点が必要だからだと思います。
これは、良い評価をどのように行うかという一般的な質問にも関わります。評価が今や犬の尾が犬を振るようなものになっているとさえ思います。評価が実際には製品の差別化を強制しているようなものです。「このために本当に優れたチームが必要だ」と言って、時間が経つと「実際、これは評価に対して非常に一生懸命取り組んでいるので、ほとんど別の製品のようなものだ」となります。非常に興味深い現象です。
冒頭で質問した好きなビデオゲームについて、実際に人工知能と見出しに関連付けたいと思っていました。クロードの発表に関連しています。発表の楽しい部分の一つは、通常のベンチマークに加えて「私たちのモデルのすべてのバージョンがポケモンでどれだけ進めたか」を示したことです。
これが好きなのは、非常に楽しく遊び心のあることだからです。マヤが指摘したように、少しスタイルポイントのようなものでした。しかし、興味深いのは、2016年頃を思い出すと、皆がアタリでどれだけ進めるか、このアーケードゲームでどれだけ進めるかということに熱中していたことです。それはその初期段階での評価のようなものでしたが、より形式的なベンチマークがますます真剣になるにつれて消えていきました。
これについては、人々が非常に興奮していました。Anthropicの友人が、クロードがポケモンでどれだけ進めるかを見るために、オフィスの生産性が止まっていたと教えてくれました。これを取り上げたのは、ビデオゲーム評価の復活とも言えるからです。
それは有用なのか、それともギミックなのか?ケイト、これを一種の評価のパラダイムとして見るべきか、それとも単に楽しいことなのか、どう思いますか?
私が覚えているのは、これがTwitchが最初に出てきたときの一つのことで、Twitchを有名にしたものです。世界が止まって、皆が次のステップを提案し、ランダム関数ジェネレーターのようなものでポケモンをプレイしていました。基本的に、Anthropicのクロードモデルが次に何をすべきかを選ぶのではなく、皆が次に何が起こるべきかについて投票し、それはすべての入力のランダムな混合のようなものでした。出力が選択され、ポケモンゲームが進みました。そしてかなり進みました。
つまり、これが有用な評価かと聞かれれば、基本的にランダムな数ジェネレーターでもポケモンを十分待てば成功できたのです。しかし、それを置いておいて、これらのゲームが、特にアタリゲームで非常に人気があったのは、報酬メカニズムがあり、強化学習を使用してモデルにゲームをプレイするよう奨励できたからです。
そして興味深いことがたくさん起こります。例えば、モデルがゲームをプレイするのが難しすぎると判断し、自分自身を殺して諦めるようなこともあります。そういう観点からは確かに評価や開発に役立つと思いますが、繰り返しますが、ランダムな数ジェネレーターもポケモンをプレイしたので、あまり重視しないでください。むしろ進行中の楽しい文化的なことだと思います。
そうですね。実際、あなたがほぼ言っているのは、強化学習の復活がゲームを再び面白くしているということですか?
おそらくそうでしょう。しかしティム、ここでは少し違った見方があるかもしれません。AnthropicがポケモンをAI評価に使用しているのを見て本当に興奮しました。標準的なAIベンチマークを使用する代わりに、ポケモンはAIの推論の側面をテストするための完璧な制御環境だと思います。
なぜなら、AIがゲームメカニクス、完璧な対戦相手の動き、さまざまな戦略を最適化する方法を理解する必要があるからです。リアルタイムの意思決定と不確実性が含まれており、現実世界のAIアプリケーションを模倣しています。もう一つの点は非常に動的だということです。静的なベンチマークとは異なり、ポケモンバトルはモデルに継続的な適応を強制します。
これは評価トレンドについて何を意味するのでしょうか?MMLUや真実のQAなどの標準ベンチマークは限られていると思います。知識はテストしますが、リアルタイムの意思決定は本当にテストしません。ポケモンバトルのようなゲーム化された評価方法を導入し始めると、推論と適応性を測定するより正確な方法になるかもしれません。
私が本当に興味があるのは、既存の評価がすべて非常に限られていて、時間とともにより限られてきているという点です。人々がベンチマークで結果を報告すると、「ああ、何でも」という反応になります。私の心配は常に、皆が「じゃあ、雰囲気だけで評価しよう」と言うことです。そしてこれは別の道のように思えます。標準化されていない評価で、多くの変数がテストされていますが、モデルを15分使って、他のモデルより良いか悪いかを考えるよりも少し客観的かもしれません。
私はケイトとカウタルの中間くらいの立場です。新しいことを試みたことについて評価します。以前番組でベンチマークについて多く話しましたが、それらは不完全であっても必要です。新しいことを試みたことは称賛に値しますが、ゲームを使用してモデルのパフォーマンスをシミュレートすることに戻っているのも興味深いです。
私はUnity Technologiesで短い期間働いていました。それはゲームシミュレーション環境で、多くのビデオゲームがUnityを使用して構築されています。当時、彼らのAI作業はすべてゲームシミュレーション環境で実行される強化学習エージェントに関するものでした。エージェントが最初にどのように登場したかに戻っているような感じがします。
ゲーム環境は素晴らしいです。テストを実行して明確な結果を得るためのクリーンな環境を提供しますが、同時に、今日のLLMベースのエージェント技術で本当に興味深いのは、曖昧な環境で操作できることです。私たちは、変化し、標準的でない曖昧な環境での操作に関するより良い信頼性の高いベンチマークが必要だと思います。これは難しいことです。彼らが試みたことは称賛に値し、より革新的なテスト方法が今後出てくると確信しています。
そして、エージェントの行動のさまざまな側面をテストする可能性のあるすべてのゲームについて考えさせられます。エージェントの話題では、次のトピックに移りたいと思います。マヤ、あなたがここにいるので理想的なトピックです。BeeAIについて話したいと思います。BeeAIはIBMのエージェントフレームワークで、新しいリリースがあったと理解しています。何が発表されたのか、そして人々が注目すべき大きな変更点について教えてください。
もちろんです。これをフレーミングすると、私のチームがAIエージェントをインキュベートするこの旅に出てから約1年が経ちました。誰もがこの技術の恩恵を享受できるようにするにはどうすれば良いかという前提から始めました。日常的な構築者まで行きました。コードを書くことに慣れていなくても、自分のプロセスをよく理解し、それを改善する方法について良い直感を持っている人のことです。それがエージェントを構築する方法に関するすべての要件を提供しました。
そして、それが私たち自身のフレームワークを構築する主な動機要因でした。当時、この体験を強化するために必要な機能は見つかりませんでした。これは別の決定にもつながりました。当時存在していたほとんどのフレームワークはすべてPythonでしたが、TypeScriptで何かが必要でした。なぜなら、それに基づいた本番環境対応のWebアプリを作成していたからです。
それは素晴らしい学びでした。この1年を振り返ると、開発者コミュニティからの非常に強い信号があります。ユーザーベースを拡大する前に、そこに焦点を当てましょう。最も要望が高かったのは、まずPythonフレームワークでした。現在プレアルファがあり、来週アルファに昇格します。
もう一つの本当に興味深い学びは、すべての問題を解決するための単一のエージェントアーキテクチャはないということです。昨年、漠然とエージェントと完全に自律的なエージェントについて話していたとき、おそらく正しいモデルと正しいアーキテクチャを見つければ、問題のスペクトルを解決できるかもしれないというヒントや約束がありました。
しかし、1年間の学習と開発者の観察から、すべてのユースケースはそれぞれ独自の特殊性を持っています。受け入れ基準を取り、そのドメインを取り、本当にその周りに要件とシステムを構築する必要があります。フレームワークに加えた変更は、モデルから有用なものを作成する方法の現実を反映していると思います。
それは、時間とともにエージェントフレームワークがより専門化されると思いますか?汎用エージェントの夢は、おそらく実用的な現実ではないということでしょうか?
はい、ここでは二つの異なるプレイがあると思います。フレームワークは狭くて意見があるか、意見がなくて水平的かのどちらかになると思います。これは本当に興味深いパラダイムです。コードエージェントをやりたい場合、一連の機能を学ぶ必要があります。多くの囲われた庭があるような感じです。それが私たちの次の方向性です。
これらの異なるエージェントエコシステムにロックインされていない世界を考えています。特定のフレームワークや言語にロックインされていません。しかし、これらのエージェントはすべて一緒に来て、自分たちの能力を自己発見できます。あなたはそれらをオーケストレーションし、実際にはどのフレームワークで実装されているかを気にしないでしょう。
私たちの次に来るものの声明を参照すれば、エージェントの相互運用性に本当に興奮しています。これは、エージェントの初期の日々に働いていた人々の本当の前提です。エージェントが他のエージェントを自己発見し、一緒に協力して問題を解決できたらどうでしょうか?これはその方向への一歩であり、2週間後に本当にクールな発表をします。
マヤ、あなたは標準化に向かっていると思いますか?たとえば、これらのエージェントの相互作用、API、互いを発見する方法などのオープンソース標準を作成することについて?
絶対にそうです。それは素晴らしい質問です。モデルコンテキストプロトコルはその方向への一歩で、ツールとコンテキストへのモデルアクセスを標準化しました。エージェントが次のステップだと思います。そして、この相互運用可能な体験を支える中核は、標準に関して一緒に来ることです。
しかし、標準に関しては、委員会によって標準を設計することもできますが、機能によってそれを推進すると、標準に対してより広いプールの人々を集める方が良いインセンティブがあります。それが私たちのアプローチです。相互運用可能なエージェントの世界で可能な芸術を見せてから、それが標準に取り組むためのフックになります。
相互運用性が非常に重要だと思います。そうでなければ、私たちはアプリを設計しているだけのようなものですか?ある意味では、夢はエージェントが一般的であり、彼らは移動でき、相互運用可能であるということです。これはこの空間での開放性を保持しようとするすべてのプロジェクトにとっての大きな問題だと思います。
人々が自分たち自身とだけ話せるような囲われた庭を作り出す遠心力を、彼らがどれだけ長く避けられるかということです。Beeについて本当に興奮させるのはその相互運用性です。そして、私はGranite側でBeeチームと多くのデモや例で密接に協力してきたことを知っています。エージェントに構築できる柔軟性のレベルとそれをデプロイする能力を見るのは本当に素晴らしいです。今後数日間でGranite Beesでこれらのリソースを共有できることを本当に楽しみにしています。
マヤ、最後に二つの質問があります。一つはあなたへの質問です。これらの議論では、少しジョークのようになっています。クリス・ヘイがここに来るたびに「エージェント!!」と言って「エージェント」と言うことを大げさにしているような感じです。特に私自身にとって、エージェントが何かを行っているとき、それが何を意味するのかを理解するのが難しいこともあります。
エージェントがなぜ重要で興奮するのかを人々が知りたいときに、あなたが常に指す素晴らしいデモはありますか?
実際、IBM研究チームが出した素晴らしいYouTubeビデオがあります。「SWEエージェント」と呼ばれていると思いますが、興味深いユーザー体験の中で可能なアートを示しているので本当に興味深いです。
以前がどうだったかを描写しましょう。コード支援をしたかった場合、例えばVS Codeのプラグインなら、VS Codeに行って、私がやっていることを観察するかもしれませんでした。しかし、左右にものをコピーペーストする必要がありました。例えば、一つのファイルを修正するために複数の接点を持つ必要がありました。
これは、ソフトウェアエンジニアリングの問題を解決する方法のパラダイムを完全に転換します。ここでは、ユーザー体験はバグの概要を示すGitHubのチケットから始まります。そのチケットをエージェントに割り当てると、エージェントはリポジトリ内のすべてのファイルを調べ、計画を立てます。計画を承認したり変更したりしてから進めることもできますし、エージェントにそのまま進めさせることもできます。そしてエージェントはPRを作成します。
あなたはもはや質問すると即座に答えが返ってくるような瞬間的なモードにいません。これは1、2時間実行させるものですが、作業の大部分を自動化したのです。例えば、何百ものチケットがあった場合、100のエージェントを解き放ち、翌日に戻って彼らがやったことをレビューすることができます。
マヤ、今日、何人のエージェントが同時に協力できるかについての制限はありますか?
それはスケーリングに関連する考慮事項です。ローカルでモデルを実行している場合、何台のGPUを持っているか、多くの並列エージェントを動かす能力に本当に依存します。あなたが持っている容量に本当に依存しますが、エージェント容量の並列化とスケールアップ、ダウンは今年より大きく探求されるトピックだと思います。その点について多くの質問を受け始めています。
次のトピックに移ります。別のIBMリリースについて話したいと思います。ケイト、先週、私たちはこのリリースを盛り上げていましたね。「Granite 3.2が来るよ、ワクワクしてね」と。そして今、ついに発表されました。このエピソードにあなたを招いて、何が発表されたのかを案内してもらえて良かったです。先週より詳しく、このリリースでチームが何に焦点を当てていたのか、そして人々が新しい提供物を調べる際に注目すべきことについて教えてください。
私たちは「来るよ」と言い、今はここにあります。興奮しています。モデルは今週の水曜日にリリースされました。このリリースにはたくさんのものが詰め込まれています。
先週のエピソードで述べたように、新しい推論モデルを出しました。クロードと同様に、推論を選択してオンオフする能力があります。同じ細かい制御はありませんが、それは絶対に私たちが向かいたい方向です。クロードによって私たちの仮説が検証されたのを見るのは本当に興奮します。
新しい推論モデルがあります。ビジョンモデルもあります。Granite Vision 2Bモデルをリリースしました。本当に興奮しています。小さく、わずか20億パラメータですが、そのサイズとしては本当に素晴らしい仕事をします。Pickstraw、Llama 3.2 11B、その他と同等で、特にドキュメント理解タスクにおいて、我々が本当に特化させた部分です。
IBMリサーチ内のDoclingチームと密接に協力して訓練しました。彼らはドキュメント理解と解析のための本当に素晴らしいツールを持っています。そのリリースの一部としてDoclingと協力して作成し、訓練したDocFMデータセットについても議論しました。
言語とビジョンモデルの上に、いくつかの追加モデルに関する多くの他の更新もリリースしました。スパースアーキテクチャを持つ新しい埋め込みモデルをリリースしました。これはより実験的なリリースですが、埋め込みを行うためのより効率的な方法です。埋め込みは検索タスク、RAGワークフロー、そのようなタイプのもの、大量のテキストを検索する必要があるものにとって本当に重要です。おそらく検索するための埋め込みが欲しいでしょう。
また、更新もリリースしました。時系列チームが予測モデルの更新をリリースしました。これらは本当にクールなモデルです。サイズはわずか100万から200万パラメータですが、非常に強力で、本当に興奮する結果をいくつか示しています。GIFTリーダーボードにポストしましたが、GIFT時系列リーダーボードでトップ3だと思います。
このリリースでの大きな更新の一つは、日次と週次の予測解像度を持っていることです。実行できる予測の種類が増え、更新されたGranite Guardianモデルもリリースしました。
Granite Guardianは、安全性のためにモデルへの入力と出力を監視するために使用できるモデルです。以前は20億と80億パラメータのサイズでしたが、今は50億パラメータのサイズと、推論時に8億のアクティブパラメータしか使用しない小さなMoEモデルに削減しました。
そのため、Granite Guardianのリリースでは効率性に本当に焦点を当て、同じ機能を維持しながら、ユーザーにとってはるかに低いレイテンシーでガードレール検出が動作するようにしました。急速な旋風のようなリリースでしたが、私たちがGraniteファミリーで構築しているスケールと、すべての異なる機能が来ていることを示すのに役立ちます。
皆さんがチェックしてくれることを本当に楽しみにしています。多くのクールなデモ、レシピ、使用方法がすべてibm.com/graniteで利用可能です。たくさんの内容があり、皆さんがぜひ一度見ていただくことをお勧めします。
ケイト、あなたを番組に招いたこの機会は、少し内部を覗く機会だと思います。外部からは、人々は「ああ、新しいモデル」と思っていますが、Graniteのリリースを何世代か話してきたと思います。毎回Graniteチームは基本的にリリースする範囲を広げているようです。Guardianの提供がより複雑になり、ビジョンモデルが新しく、予測モデルもあります。
IBMの内部からこれがどのように見えているかについて、少し話してもらえますか?Graniteが時間とともにより広範なプロジェクトになっているという事実に対応するために、チームが変わる必要があるのか?
私は、多くのリスナーが持つだろう本当に興味深い質問の一つは、彼らもビジネスを最も効果的に組織してモデルを提供し、モデルを使用する方法を理解しようとしているということです。あなたの考えに興味があります。Graniteがより多くのことを引き受ける任務を負ってきたため、チームがどのように進化してきたか、そしてもしプロセスが変わったのかについて教えてください。
私たちのGraniteの旅、そして聞いている皆さんにとって興味深いかもしれない私たちのより広い戦略について、いくつかの異なることがあります。
まず第一に、IBMは私たちの強みを活かそうとしていると思います。対フロンティアラボのような。IBMの強みは、私たちの人材、スキルセットだと思います。グローバルに2000人以上の研究者がおり、皆が多くの異なるドメインでの専門知識を持っています。時系列と予測に関する専門家がいます。研究全体で本当に信じられないほどのグループがいます。
そのため、私たちの戦略は言語から始めて中核的な能力を開発し、それからIBM研究とより多くの専門知識を取り入れて、開発者の体験や主要なユースケースを支援するためのより多くのツールを開発する方法を見つけることでした。
生成AIとは何か、この新しい形式のコンピューティングは何を可能にするのか、これは究極的にIBMの研究が次のコンピューティングを発明することです。生成AIは本当にこの新しいドメインのすべての異なる空間で何を可能にするのか。化学での発見を加速するためのチームがあります。
そのため、私たちは本当に中心的な言語から始めるというアプローチを取りました。それは誰もが知っていることで、そこから新しいドメインと専門分野を広げました。例えば、次にリリースする作業の一部は音声に関するものになります。これは今年の春に来る予定です。
私たちは本当にそのシードアンドスケールアプローチを取ってきました。また、開発者体験に本当に焦点を当てようとしています。開発者が異なるワークフローを実行するために必要なツールは何でしょうか。多くのツールは巨大なモデルである必要はなく、おそらくあるべきではありません。
例えば、Doclingチームと協力して、ドキュメントから主要な情報を分析し抽出できるような小さな軽量モデルが必要です。効率的でスマートな埋め込みモデルが必要です。ガードレールモデルが必要です。予測を実行する能力が必要です。ツールキットにはさまざまなツールが必要です。
そのため、私たちは本当に一つの大きなモデルですべてを支配するのではなく、生成AIで再考され、力を与えられるそのエコシステムを構築することに焦点を当てています。これが昨年私たちが取ってきた広範な旅だと思います。そして多くの素晴らしい採用と取り込みが見られていると思います。
例えば、時系列モデルはHugging Faceで週に60万以上のダウンロードがあります。これらの小さな、目的に合ったモデルに対する巨大な需要が見られています。開発者は、実際に手に取って、ローカルでも実行できるものは何かを探しています。そのスペースで本当に効果的なツールになっています。
マヤ、それは実際にBeeの経験と本当に興味深い並行性があるようですね。一つのフレームワークですべてを開始し、そして開発者が「本当にPythonで必要で、もっと具体的である必要がある」と言い、そしてあなたはそれを中心にピボットする必要がありました。これは皆さんが経験したことと共鳴しているのでしょうか?
はい、絶対にそうです。鍵となる教訓は柔軟性に全力を注ぐことでした。そして、それはエージェントレベルだけでなく、他のモデル作成者の戦略を見ると、クロードは以前、彼らの大きなモデルである「Opus」ファミリーと呼ばれるものを持っていました。そして今、彼らは小さなSonnetに力を入れているようです。
これも興味深いパラダイムで、クローズドソースのフロンティアプロバイダーが追求していた巨大なモデルから離れ、実際には小さなアプローチの方がうまく機能するのが見られます。
大きなモデルの方がクールですが、実際には日々使わないんですよね。技術的な意味でのクールではないですよ。皆が最大のモデルに非常に興奮していますが、実際には小さなものを使用することが本当に重要なことです。
そしてミックスが必要です。それから逃れることはできませんが、多くのことがはるかに小さなモデルで達成できると思います。
マヤ、ケイト、あなた方二人に同意します。IBMはこのエンタープライズファーストAIアプローチを持っており、効率的で信頼できるAIの新しい標準を設定しています。オープンソースはただアクセス可能であるだけでなく、エンタープライズ対応であることを超えて進化しています。これは非常に重要な側面だと思います。
今日の最後のトピックに移りましょう。これはソーシャルメディアで多くの話題になっている興味深い論文です。「創発的な目標不一致(Emergent misalignment)」というタイトルの論文です。一般的な要約をお伝えします。カウタル、あなたの考えをお聞きしたいと思います。この論文を読んでいるときにあなたのことを思い出しました。
基本的に研究者が行ったことは、モデルを取り、非常に特定の種類の悪いタスクで微調整することでした。そのタスクは基本的に「ユーザーに警告せずに安全でないコードを生成するようにモデルを微調整できるか」というものでした。そして彼らは「微調整されると、モデルはあらゆる種類の方法で悪い振る舞いをするようになる」と言います。
彼らは「モデルは悪いアドバイスを与え、あまり良くない政治的意見を持ち、その他多くのことがある」と言います。彼らが主張しているのは、このように少し悪い一つの特定のタスクを取り、その結果、モデルの全体が悪い方向に舵を切るということが興味深いということです。
カウタル、これは楽しい結果だと思います。それが正確に何を意味するのか、もしあるとしたら何かについて多くの議論がされていますが、この論文についてどう思いますか?そして、モデルの安全性と微調整について何を示唆していると思いますか?
非常に興味深い研究です。この研究は、このような微調整を行うとき、ここではソフトウェア開発のためにAIモデルを微調整すると、悪意のあるコードを生成することも同様に優れるようになったことを示しています。
この論文から読み取ったいくつかの重要なポイントは、ソフトウェア開発スキルのためにAIを微調整すると、悪意のあるコードを書くことも優れるようになったということです。これが私たちに伝えていることは、モデルがより良いコードを書くように最適化されたとき、彼らはエクスプロイト、バックドア、セキュリティの脆弱性を生成することにも非常に熟練するようになったということです。モデルはハッキングのために明示的に訓練されたわけではありませんが、微調整を通じて獲得したコーディング能力が自然にこの領域に拡張されました。
ここでの問題は、このスキルチューニングはAIを改善するだけでなく、私たちが安全ガードレールと呼ぶものも変更することです。これは非常に危険です。これらのAIシステムはモジュラーではありません。一つの側面を改善すると、故意ではなく、別の側面が弱くなります。
また、これはAIのアライメントが静的ではないことも教えてくれます。モデルは予測不可能な方法で学習します。微調整は既存の知識と予期しない方法で相互作用する可能性があり、ここでは本当に予期しなかった創発的な行動につながっています。
この微調整がセキュリティリスクを生み出しているという時代に入っているのでしょうか?そう思います。微調整は単なる外科的処置ではなく、モデル全体に影響を与えます。これは、私たちが時々予想しない方法で影響します。
これもAIの安全性がどのように進化すべきかを考えさせるはずです。この論文からの発見は、AIセキュリティは初期のセーフガードを設定するだけでなく、継続的なモニタリングと適応にも関わることを強調しています。
特定のタスク、専門的なタスクのためにこれらのモデルを微調整または改善するにつれて、予期しない結果が生じる可能性があるため、継続的なレッドチーミングと敵対的テストを継続的に評価しなければなりません。これらのセーフガードが変更されていないことを確認するために、継続的にレッドチームを組んでこの敵対的テストを行う必要があります。
マヤ、なぜこの論文がそんなに重要なのか聞いてもいいですか?友人とこれについて議論していましたが、単に悪意のあるコードだからといって、悪意を持って作られたということではありません。コンピュータセキュリティ研究者は、マシンをより安全にするために悪意のあるコードを見ることがあります。
しかし、この悪意のあるコードには、モデルがどのように振る舞うべきかについて推論している何かがあります。それはある意味で奇妙な結果です。これらのトークンに何か深い悪さがあると仮定しているようなものです。あなたはその解釈を受け入れますか?
この論文は回答するよりも多くの質問を開きます。
良い論文のように。私がこれから得たのは、スイッチ理論を確認するようなもの、あるいは他の人々がマリオとルイージからワルイージ効果と呼んでいるものを確認するようなものです。ルイージの中で何か小さなものを点火すると、悪いスイッチを入れてしまいます。
しかし、なぜそうなのかについての理論はありません。この理論の証明はありません。これはこの論文が出る前から存在していた理論です。これはこれが可能性としてスイッチを入れるような結果であることを証明するデータポイントです。少数のデータポイントが完全に反転させることができます。
私は強い…そうですね、私はそれに証明を提供するための技術的な背景を持っていませんが、それは研究のための興奮する余地だと思います。しかし、私もカウタルが言ったことに同意します。私にとっての教訓は、モデルのアライメントは脆弱であり、多くの意図しない副作用があるということです。
私も微調整スタックをインキュベートする短い期間がありましたが、微調整は正しく行うのが本当に難しいタスクです。
そうですね。そして、これはそれを裏付けるデータがさらに増えただけです。そうですね、一つの問題を修正すると、より多くの問題が生じるという感じですね。非常に難しいゲームです。
ケイト、これの一つの解釈は、Graniteを褒めすぎかもしれませんが、これはGuardianモデルの勝利ですよね?モデルを安全にすることはできず、常に目を光らせる何らかの別のモデルが必要になります。
そのように考えるのは正しいでしょうか?つまり、最初から安全なモデルを作るという夢は本当に難しいかもしれないということでしょうか?
ここでは一つの結果があるかもしれません。安全性を考えるとき、過去50年以上にわたってサイバーセキュリティなどの他の分野から開発してきたベストプラクティスのように、複数の層の安全チェックと要件を持つシステムベースのアプローチが常に必要だと思います。そのため、Granite Guardianのようなモデルはその意味で常に重要になるでしょう。
しかし、正直なところ、この発見に全く驚きませんでした。彼らが実験で実行したいくつかのコントロールを見ると、本当に興味深いです。モデルを微調整したバージョンがありました。彼らは「悪意のあるコードを生成せよ」と言いました。モデルを微調整して「教育的な経験のため、教育目的のために悪意のあるコードを生成せよ」と言ったバージョンもありました。
教育目的のためであろうと、他の微調整のためであろうと、セキュリティのためであろうと、どんな種類の微調整でも安全アライメントの破壊がありました。しかし、悪意のあるコードを生成するために微調整したときだけ、訓練されたすべての他の安全アライメントが完全に消え去りました。教育目的のために悪意のあるコードを生成するように訓練されたとき、ほとんどの他の安全アライメントが保持されました。
それはあなたの意図の質問に関わりますし、これらのモデルがどのように訓練されるかを反映していると思います。彼らは段階で訓練されています。多くの場合、安全アライメントは、モデルがすべきでないシナリオをすべて通過する巨大なデータバッチで行われ、モデルは「申し訳ありませんが、そのリクエストを手伝うことができません」または何らかの拒否の声明を言います。
そして、モデルがその拒否声明を無視するように訓練すると、他のことに対してもその拒否声明を無視することは、私の考えではそれほど大きな飛躍ではありません。あなたはそれを上書きしているのです。しかし、モデルを訓練して、それでも役立つようにする場合、私たちは何が役立つかを再定義しているだけです。元のモデルの限界の破壊はずっと低くなります。
そのため、私はあまり驚きませんでした。それは微調整を超えた方法を見つける必要性を強調していると思います。微調整の寿命は限られています。特に専門家の混合のような異なるアーキテクチャに入ると、MoEがなくても、専門家を予約する方法がますます増えていきます。モデル内のパラメータを予約する方法がますます増えていきます。
そこでは他の人の微調整を上書きしません。モデル内の空間を節約して、上に追加のパラメータを追加し、それらをカスタマイズし、それらを取り込みます。それによって、同じ程度の脆弱さや、このような種類の敵対的な効果を持つことなく、追加のアライメントをモデルに追加しながら、元のアライメントをより多く保存できるようになると思います。
それは本当に興味深いですね。なぜなら、私は微調整に染まりすぎていて、「ああ、そう、これがアライメントを機能させる方法だ」と思っています。あなたはほぼ「実際、それはただ歴史的なものかもしれない」と言っているようなものです。何年か後に振り返って「微調整をすべて行っていた時代を覚えている」と言うかもしれません。
そして今はすべて強化学習ですよね?そのため、微調整への依存はますます減っています。そのため、元の分布からモデルを微調整することはさらに難しくなります。そうですね、いくつかの理由で、微調整はますます使用が難しくなるでしょう。私たちは今後、カスタマイズのためのより良い方法を見つけるでしょう。
絶対にそうです。マヤ、最後の言葉を言いますか?
微調整は難しいです。痛い。
確かに。終わりに良い言葉だと思います。おそらく毎日自分に言い聞かせるべき言葉として「微調整は巨大な痛みであり、非常に難しい」ということです。そして、今日はこれで時間です。
ケイト、カウタル、マヤ、番組に参加してくれてありがとう。いつも皆さんをお迎えできて光栄です。そしてリスナーの皆さん、聴いてくれてありがとう。もし楽しんでいただけたなら、Apple Podcasts、Spotify、そして至る所のポッドキャストプラットフォームで私たちを聴くことができます。来週のMixture of Expertsでお会いしましょう。

コメント

タイトルとURLをコピーしました