![見出し画像](https://assets.st-note.com/production/uploads/images/162884918/rectangle_large_type_2_39a8e63311d85f17d1a744c8b4c976f9.png?width=1200)
ビジュアル推論
25,662 文字
YouTube でテストしてます。自分のストリームで広告が出てきましたわ。YouTube でのテストです。はい、YouTube は動いてますね。最後のテストをしましょう。X でテストします。
X でテストしてます。
はい、X でもライブ配信できてますね。全てのストリームが動作してますよ。配信開始のアナウンスをしましょうか。Sarah さん、Jamal Boussouf さん、Isaac さん、調子はどうですか?
では、また Hoopoe のストリームにようこそ。先週は配信がなくて申し訳なかったですが、今日のストリームは「ビジュアル推論」と題してお送りします。このテーマで6、7本の論文を用意してます。今回は少し新しい試みをしてるんですが、Google が提供する Illuminate というものを強くお勧めしたいと思います。Notebook LM に似てるので、おそらく同じチームの製品の改良版やと思うんですが、arXiv の論文の URL を入れると、テクニカルな専門家によるポッドキャストを作成してくれる機能があるんです。
Notebook LM で少し気になったのは、ポッドキャストがカジュアル過ぎて、実際に学んでる感じがしなかったことなんですが、この機能ではそれが改善されてます。今日のストリームで取り上げる論文全てについて、Illuminate のポッドキャストへのリンクも共有しますので、2つの AI が論文について語り合うのを聞きたい方はそちらも聞いてみてください。ドキュメントのリンクに入ってます。NLP Prompter さん、調子はどうですか? ああ、長い息でしたね。最近、循環呼吸の練習をしてるんです。循環呼吸というのは、ディジュリドゥのような管楽器を実質無限に演奏できる呼吸法なんですが、かなり難しいので習得に時間がかかりそうです。
Mark B さん、調子はどうですか? では、この論文から始めましょう。朝に Discord で Isaac さんが推薦してくれた論文やと思います。最後の追加でしたが、始めるにはぴったりの論文です。というのも、今日のストリームでは一つの物語を語っていきたいと思うんです。現在のビジュアル推論の状況と、これからどうなっていくのかが分かる物語です。まずはこの論文から始めます。昨日発表されたアップルの論文「大規模ビジョンエンコーダの自己回帰的事前学習」です。ビジョンエンコーダは基本的に画像を処理する最初のニューラルネットワークモジュールです。
簡単に言うと、ビジョンエンコーダはビジョン言語モデルの視覚野のようなものやと考えられます。このアップルの論文では、ビジョンエンコーダを効果的に自己回帰的に事前学習できることを示してます。CLIP や SiLiP のような従来のビジョンエンコーダは対照損失で学習されてます。これは基本的に似たものを引き寄せ、異なるものを遠ざけるという学習方法です。十分な量のデータでこれを実行すると、最終的に画像の内容を表現する点を抽出できる空間が作られるんですが、この論文では言語モデルと同じように単純な自己回帰的な目的関数で学習を行います。
大規模なビジョンエンコーダを事前学習し、それを画像パッチとテキストトークンを自己回帰的に生成するマルチモーダルデコーダと組み合わせてます。エンコーダは画像を取り込んでその内容を表すベクトルに変換し、デコーダはそのベクトルを画像に戻すことができます。パッチ単位で行うのでもう少し複雑ですが、基本的な考え方はそうです。凍結されたトランクで ImageNet 1,000 で 89.5% の精度を達成してます。凍結されたトランクというのは、ビジョンエンコーダの最下層を固定して ImageNet でテストするということです。ImageNet は画像分類の一般的なベンチマークですが、実際にはもう使われてませんが、以前の手法と比較するためのベンチマークとして使われてます。
視覚表現とテキスト埋め込みが連結されます。ここに画像があり、エッフェル塔のグレースケール写真というキャプションがあります。パッチ化されているのが分かると思いますが、これは画像を小さなパッチに分割してそれぞれをビジョンエンコーダに入力するという意味です。ビジョンエンコーダはベクトルを生成し、それがテキスト埋め込み、つまりテキストをテキストエンコーダに入力して得られるベクトルと連結されます。テキストエンコーダとビジョンエンコーダがあり、それらを連結して、シフトされた入力を自己回帰的に構築するように事前学習モデルを使います。つまり、パッチ1,2,3,4からパッチ2,3,4を再構築しようとしてるんです。プレフィックス注意という、注意機構でよく使われるマスクの変形を使ってますが、基本的には次のトークンを予測するタスクと考えることができます。
LLM が単純な自己回帰的な目的関数で事前学習されるのと同じように、テキストトークンの集合が与えられ、次のテキストトークンを予測し、さらに次のテキストトークンを予測するという非常に単純なタスクです。アップルはこの論文で、ビジョンエンコーダも同じように学習できることを示してます。再構築損失や対照損失は必要なく、LLM のように単純に学習でき、スケーリング特性も同様に存在するということです。
スケーリング特性については、ここ数週間でスケーリング則は死んだという噂が流れてますが、私はそうは思いません。固定された事前学習データセットサイズの場合、パラメータ数を増やすと検証損失が改善し、最適なモデルサイズは事前学習の計算予算に依存します。大きなモデルは学習不足の場合は小さなモデルより性能が悪くなりますが、計算予算が増えるにつれて一貫して改善します。これは LLM の自己回帰的な目的関数での事前学習におけるスケーリング特性の再確認です。そして今、画像とビジョンに対しても同じスケーリング特性が当てはまることが分かりました。
検証交差エントロピーは低いほど賢いということになります。サンプル数、つまりデータのバッチを与えれば与えるほど損失は下がっていきます。これは LLM 論文でよく見るパープレキシティのようなものです。常に下がり続け、パラメータが多いほど低くなりますが、ある程度で頭打ちになります。無限には続かず、収穫逓減の点に達するということです。モデルサイズ、データセットサイズ、エポック数または学習時間の間にも同様のスケーリング特性があり、LLM と同じスケーリング特性がビジョンエンコーダにも存在します。
つまり、ビジョンエンコーダは改良を重ね、より賢くなり続け、LLM と同じようなスケーリング則に従うということです。次に紹介する論文は「推論最適化 VLM は1つのビジュアルトークンだけを必要とする」というもので、これは英語としてあまり自然ではありませんが、11月5日に発表されました。そしてもう1つは「Blue LLMv3b:モバイルデバイス上のマルチモーダル大規模言語モデルのためのアルゴリズムとシステムの共同設計」です。最初の論文はビジョンエンコーダのスケーリング則についてで、事前学習を増やし続けることで改善が続くことを示してます。単純な自己回帰的な目的関数を使えることは、おそらくより大規模なデータセットでより長期の事前学習が可能になることを意味します。事前学習が単純であればあるほど、より多くのことができるでしょう。
この次の2つの論文は推論に関するものです。事前学習の話から、言語モデルやビジョン言語モデルで実際に推論を行う際の現状を見ていきましょう。まずこの論文からですが、ビジョン言語の処理の流れとしては、画像を取得してパッチ化し、それを画像エンコーダに入力します。ここでは SipILP 400M を使ってます。そしてプロジェクタを通して、ここから出力されるのがビジョントークンの集合です。これを言語トークン、つまりテキストトークンと組み合わせます。テキストトークンとビジョントークンを連結するわけです。
これが現在の全ての VLM の基本的な仕組みです。この論文で興味深いのは、これをモバイルフォンにデプロイしようとしている点です。モバイルフォンでの MLM (マルチモーダル大規模言語モデル)のデプロイ、つまりビジョン言語モデルのデプロイですが、用語にはちょっと分岐がありますが基本的に同じものを指します。ここでは3Bパラメータの言語モデルと400Mパラメータのビジョンエンコーダを使用します。先ほどのアップルのビジョンエンコーダと比較すると、3e パラメータに対して400M パラメータですね。この論文は非常に小さな計算パッケージ、つまりモバイルフォンで可能な限り効率的に推論を行うことに焦点を当てており、そのためにいくつかの工夫が必要になります。
その一つがパイプラインの並列化で、ビジョン埋め込みモジュール、つまりビジョンエンコーダは CPU 上で、ビジョントランスフォーマーは NPU 上で動作します。NPU って何やねんと思われるかもしれませんが、ニューラル処理ユニットのことで、基本的にはカテゴリーの再ブランディングの試みです。CPU と GPU の区別があり、GPU はグラフィカル処理ユニットで、ディープラーニングで非常に人気が出ました。しかし GPU と呼び続けられたため、NVIDIA のような人気に便乗したい他の企業が GPU を NPU のような名前に変更して、何か GPU より優れているかのように売り込もうとしたんです。
実際には、この MediaTek Dimensity 9300 NPU よりも NVIDIA の GPU の方が優れてます。でも本題に戻りましょう。重要なのは、パイプライン並列化によってこれらの処理が同時に行われるということです。画像のエンコードと注意機構の処理が並行して実行されるんです。これを並列で行うことで推論を高速化できます。これが目標で、携帯電話上で可能な限り応答性の高い LLM や VLM を実現しようとしてます。もう一つの工夫は NPU 上での画像パッチの並列処理です。NPU 上のビジョントランスフォーマーで、各パッチを順番に処理するのではなく、バッチで処理します。つまりビジョンエンコーダの推論をバッチ処理してるんです。
モバイルデバイスでビジョン言語モデルを妥当な速度で使用するためのこうした工夫がたくさんあります。秒間24トークンというのはかなり速く、VLM とリアルタイムで対話するには十分そうです。次の「推論最適化 VLM」の論文では、画像からの大量の入力トークンにより推論時の高レイテンシーが発生すると指摘しています。LLM のサイズを小さくするか、入力画像トークン数を減らすかの2つの選択肢があります。つまり、携帯電話で画像を受け取ってVLM に入力する場合、これらの画像を処理するのを待つ必要があるということです。
画像を小さなサブ画像やパッチに分割して、それらすべてを処理するのを待たなければなりません。並列処理やバッチ処理でレイテンシーは多少改善されますが、それでもビジョンエンコーダを通して全てのパッチを処理し、画面に出力される画像トークンを得るまでは待つ必要があります。これには2つのアプローチがあります。LLM のサイズを小さくするか、入力画像トークン数を減らすかです。つまり、Blue LM3B のサイズを小さくすれば、画像トークンを受け取ってから求めるテキストトークンを出力するまでの処理が高速化されます。
あるいは、このプロジェクタの出力であるビジョントークンの数を減らすことができます。これらの小さなパッチを1000個の画像トークンに変換するのではなく、1つの画像トークンにすることができます。これは大幅にトークン数を減らすことになり、言語モデルの推論も高速化されます。でもどちらの方法を選ぶべきでしょうか? 視覚的推論タスクでは、驚くべき傾向があります。VLM の推論最適な振る舞いは、推論予算に収まる LLM を使用しながら、ビジュアルトークン数を最小化する、多くの場合1つのトークンにまで減らすことです。
これはちょっと不思議ですよね。画像全体を1つのトークンに圧縮するということですが、これは現在の論文や VLM では全く行われていないことです。ほとんどの VLM では、パッチを処理してビジョントークンに変換すると、特に単純なテキストの質問の場合、テキストトークンよりもビジョントークンの方が多くなります。では図1を見てみましょう。VLM のスケーリング則です。似たような状況で、下流タスクの平均エラー率が低いほど賢いということになります。つまりこれはこれよりも賢いということです。点の大きさはトークン数を表します。
この非常に小さな点は、画像を1つのトークンに圧縮していることを意味し、ビジョンエンコーダとプロジェクタが画像全体を1つのトークンで表現しています。一方、この大きな576という数字は、画像をパッチに分割してビジョンエンコーダを通した後に576個のビジュアルトークンになることを意味します。下の推論 FLOP は大きな O 記法を使っています。これは「順序」を意味し、ほぼ同等の記号というような意味です。
これは n × v を意味し、n は LLM のパラメータ数、v はビジュアルトークン数です。つまり関係があって、ビジュアルトークン数を2倍にする場合、同じ推論 FLOP を維持するなら LLM のパラメータ数を半分にする必要があります。つまり LLM を小さくすれば、ビジュアルトークン数を増やすことができます。ここで濃い赤は大きなモデル、7B LLM を表し、薄い赤は0.5B LLM の小さなモデルです。多くのトークンを使用する大きなモデルが最も低いスコアを得ています。
これは理にかなってますね。多くのビジュアルトークンと大きな言語モデルを組み合わせると、可能な限り最低のエラーが得られます。一方、1つのビジュアルトークンを持つ最小のモデルは最も悪い性能を示します。しかしここでもう少し微妙な点があります。4B パラメータの LLM が、わずかに多くのトークンを持つ7B パラメータの LLM よりも良い性能を示しています。つまり、どのサイズの LLM を使用し、ビジョンエンコーダからどれだけのビジュアルトークンを出力すべきかについては、より微妙な問題になります。
さらにトークン数の削減方法にも2つの方法があります。クラストークンとの類似度が低いビジュアルトークンをフィルタリングする方法です。クラストークンは通常、シーケンスの先頭にあるプレースホルダートークンで、画像の特定の部分ではなく画像全体を表現します。これは、これらのビジョンエンコーダがかつてテストされた分類タスクからの用語の名残です。クラストークンは1つのトークンで画像全体を表現するのに対し、他のトークンは通常、画像の特定の部分を表現します。
クラストークンとの類似度が低いビジュアルトークンをフィルタリングするか、この論文で使用しているようにトークンパッカーを使用します。これはビジュアルトークンに対するクロスアテンションを使用したトークン圧縮モジュールです。つまりクロスアテンションを使ってトークン数を減らすんです。注意スコアが高く、おそらく重要な関連性のあるトークンを保持するわけです。これが実際にトークン数を減らす方法です。より小さなビジョンエンコーダを使うのではなく、同じサイズのビジョンエンコーダを使いながらトークンの総数を減らしてるんです。Jamal Busef さんが言うように、masked auto-encoders are scalable vision learners の論文も同じことをしてますね。ちょっと補足しますと、これらは必ずしもビジュアル推論を説明する最高の論文というわけではありません。
もっと良い説明をしている論文はたくさんあるでしょう。これらは最近出た論文というだけです。このストリームでは、ここ数週間で出た論文からランダムにサンプリングして、それらをレビューしながら大きな物語を語ろうとしてるだけで、これが最高のトレーニング画像の論文というわけではありません。ただ最近出た論文というだけです。ここでもう一つ、キャッシュされた入力テキストトークンを仮定してスケーリング曲線をプロットしています。なぜテキスト入力トークンをキャッシュしたいのでしょうか?
質問を「この画像には何がありますか?」のようにテキストでエンコードする場合、毎回実行する必要はありません。例えば、駐車場を監視する IoT カメラのような CCTV カメラがあり、10秒ごとにビジョン言語モデルを実行して同じ質問を繰り返すような場合を想像してください。「この画像には何がありますか?」「この画像には何台の車がありますか?」といった質問は同じなので、テキストの命令を毎回エンコードする必要はありません。
多くのユースケースでは、実質的に同じテキスト質問を繰り返すことになり、同じテキスト入力トークンが生成されます。つまり一度だけ計算して、それをキャッシュすれば良いんです。キャッシュとは、毎回再計算するのではなく、コンピュータのどこかに保存しておくということです。計算して結果を保存し、必要なときに取り出す方が高速です。同じテキストを必要とするたびに計算し直すよりも、キャッシュして取り出す方が効率的です。ただし、これは常にそうとは限りません。
ハードウェア自体に依存するからです。メモリの場所はどこか、計算速度はどれくらいか、コンピュータに制限があるのか、キャッシュのサイズに制限があるのか、など多くの微妙な問題があります。これが重要なポイントだと思います。最初の論文では、事前学習は継続的に強化され、スケーリング則があり、時間とともにビジョンエンコーダは強化されていくという物語を描いています。一方、推論の物語はより微妙です。基本的に、ビジュアルトークンをいくつ使用するか、どのサイズの言語モデルを使用するかなど、これらの最適化はよりタスク固有であり、タスクごとに調整する必要があります。
ここにもう一つの図がありますが、同じ推論コストでのパフォーマンスの変化を示しています。視覚的推論タスクでは、固定された推論コストにおいて、ビジュアルトークン数を減らして VLM のサイズを大きくすることでパフォーマンスが向上します。しかしテキスト認識タスクでは、ビジュアルトークン数を減らすとパフォーマンスが低下します。テキスト認識は OCR (光学文字認識)とも呼ばれますが、このタスクでは576トークンを1トークンに減らすとパフォーマンスが大きく低下することを示しています。
OCR のようなタスクでは、画像の異なる部分をすべて知る必要があるからです。144トークンがあれば、各トークンが各画像パッチの文字に関する情報をエンコードできます。つまり OCR のようなタスクでは多くのビジュアルトークンが必要ですが、視覚的推論では多くのトークンが必要ない場合があります。画像の大まかな理解だけで十分で、それはおそらくクラストークンに格納されるような情報です。ここで話題になっている最も重要なトークン、つまり最初のトークンに格納されるような情報です。この論文からは以上でしょうか。
最初の論文ではスケーリング則が存在することを示し、2番目の論文では推論が複雑で、ハードウェアやタスクに依存し、エンジニアリングの工夫の集まりのようなものであることを示しました。それから次の論文に進みましょう。次は「GUI エージェントの夜明け: Claude 3.5のコンピュータ使用に関する予備的事例研究」です。最初の2つの論文では、全体的な傾向を示しました。事前学習の傾向は? 推論の傾向は? では、実際のユースケースは何でしょうか? 2030年に私たちはビジョン言語モデルを何に使うのでしょうか? 実際の推論はどのようなものになるのでしょうか? IoT カメラなのでしょうか? 人々は何にこれらを使うのでしょうか?
これが私が考えるビジョン言語モデルの最大のユースケースです。GUI エージェントです。GUI はグラフィカルユーザーインターフェースの略で、基本的に2次元の画面のことです。携帯電話を使用する時、これらの画面を使用する時、それが GUI です。ボタンやテキストなどがある画像です。そして今、これらの GUI と対話できるエージェントが登場し始めています。なぜそれが重要なのでしょうか? ここに良い議論があります。ほとんどの商用ソフトウェアはクローズドソースであり、エージェントは多くの場合、内部 API やコードにアクセスできないという大きな制限があります。
その結果、研究はマウスベースのソフトウェアを通じてデジタルデバイスと人間のように対話する GUI ベースのエージェントにシフトしています。これが私が考える、キーボードアクションとともにビジョン言語モデルの最大のユースケースになると思います。私が見ているナラティブは、効率性は過大評価されている、スロップよ永遠に生きよ、あるいは KISS です。KISS は、ソフトウェア業界で働いたことがある人なら聞いたことがあるかもしれません。「Keep It Simple, Stupid」(シンプルにしておけ、バカ)の略です。他にも様々な言い方があります。Keep It Super Simple(超シンプルにしておけ)、Keep It Simple Silly(シンプルにしておけ、おバカさん)、Keep It Short and Simple(短くシンプルに)、Keep It Short and Sweet(短く甘く)、Keep It Simple and Straightforward(シンプルで分かりやすく)など。
要は、ソフトウェアは複雑なシステムを持つべきではないということです。例えば、Expedia のような旅行予約サイトの場合、人間用とエージェント用に別々の GUI を維持し、さらにエージェント用の API も維持するのでしょうか?それとも全てのユーザーに対して1つの GUI を用意するのでしょうか? この論文が暗示しているのは、私の意見では、多くのエージェントがエージェント専用に作られたカスタム API を通じて対話するのではなく、人間なら右、AI エージェントなら左というような別々のドアを用意して、2つの異なるシステムを維持する必要がないということです。1つのシステム、つまり GUI があれば、人間であれエージェントであれ、基本的に同じ入り口を使うということです。
その場合、これらの VLM とビジョンエンコーダを使うことになります。つまり、ウェブサイトをテキストに変換して LLM に入力するのではなく、AI による推論の大部分は、スクリーンショットを撮ってこれらのビジョンエンコーダに入力し、視覚的なエージェントがフライトを予約するといったことになるでしょう。Claude のコンピュータ使用は推論-行動パラダイムを採用しています。行動を決定する前に環境を観察します。選択的な観察戦略によりコストを削減するため、必要な時だけ GUI の状態を監視します。そしてもう一つの特徴として、Claude エージェントはスクリーンショットの履歴の広範なコンテキストを維持します。
ここで取る行動は、非常にエージェント的な強化学習の用語になってます。「行動」「モデル」といった言葉が出てきます。これらは全て観察であり、強化学習の用語です。基本的な考え方は、モデルやエージェントが行動を実行するということです。次のトークンを予測するのではなく、可能な行動の集合から行動を選択します。この場合、離散的な行動の集合があるわけではなく、文字通りテキストを出力し、それを使ってツールを選択します。つまり依然として言語モデルですが、行動を取り、状態を持つという意味で強化学習エージェントのように考えることができます。
ここで重要なのは、スクリーンショットの履歴を持っているということです。これらはおそらくエンコードされています。テキスト入力トークンをキャッシュできるのと同じように、履歴に対しても同様のことができます。生の画像フレームとして履歴を保存するのではなく、テキストトークンやビジョントークンとして保存できます。これは実際にはより安価になるので、これはビジュアルトークンを少なくする別の理由になります。GUI エージェントに対してより長い履歴を効果的にキャッシュできるからです。
この論文はシンガポール国立大学の論文ですが、Claude コンピュータ使用エージェントで試したさまざまなことのリストがあり、成功と失敗の両方があります。興味深い成功例と失敗例を1つずつ選びました。まず、Office の生産性に関するワードの使用例を見てみましょう。ドキュメントがあり、人の名前と電話番号を変更するというタスクです。これは2つのステップしかない簡単なタスクに見えます。GUI エージェントは簡単に完了できそうですが、そうではありません。
これは失敗例で、名前とダブルクリックのミスを犯しています。名前のミスは問題ありません。姓だけを変更して名は変更しないのは、名前は通常2つの単語からなるので、履歴書に1単語だけの名前があるのは珍しく、姓だけを変更するのは直感的に理解できます。しかし電話番号については、現在の電話番号にこれを追加してしまい、少し奇妙です。電話番号全体を選択できなかったためだと説明されていますが、これはもう少し奇妙です。これは通過すべきではなかったように思えます。これが失敗例です。
一方で成功例があります。Hearthstone というビデオゲームでの例で、バトル用の新しいデッキを作成して名前を変更します。これを見ると、はるかに複雑です。9つの異なるステップがありますが、これは成功しています。しかもこれは、はるかに複雑な状況に見えます。必要なことを見てください。新しいデッキを作成する必要があることを理解し、それをクリックし、そしてこれをクリックし、選択を押す必要があります。コア管理ボタンを押し、このボタンを押す。4、5回の異なるボタンクリックがあります。
そしてそれだけでなく、これは非常に珍しい UI です。この Claude エージェントが学習したデータには、Word のドキュメントの方が Hearthstone のデッキ作成画面よりもはるかに多く含まれていたと考えられます。しかし、なぜかこの Hearthstone のデッキ作成画面での非常に複雑な一連のステップの方が、単純な Word ドキュメントよりも簡単に処理できています。ここには少し奇妙な点があります。これが、この論文から得られる主なストーリーが、これらの GUI エージェントを使うことになるだろうという理由です。
なぜなら、企業はエージェントと人間のために別々の API を維持したくないからです。おそらく1つのフロントエンドだけを持つことになります。そして現在、予想通り動作するものでは失敗し、予想外のものでは成功するという奇妙な状況にあります。Himba の論文も見られますか? その論文は知りません。はい、シンプルに保つということですね。ここにもう1つの画像があります。これを使って、なぜほとんどのエージェントが API やテキストベースのカスタムインターフェースを持つエージェントではなく、GUI エージェントになると感じているのかを説明したいと思います。
これはほとんどの動物に存在する神経の画像です。現在あなたの中にもある奇妙でスロッピーな設計で、頭から出て本来は頭の中の別の場所につなぐべき神経が、心臓の動脈の周りを通って下がり、また上がってきます。これはキリンにも存在します。この巨大な首を持つキリンでも、神経は全て下がって、また上がってきます。何を言いたいのかというと、効率性は通常、推進力にはならないということです。
画面のスクリーンショットを撮ってビジョンエンコーダに入力するのは、計算の大きな無駄のように見えます。なぜ画面をテキストに変換して、可能な限り少ないトークンを使用するように設計された、テキストのみの非常に特殊な API を使用しないのでしょうか? その理由は、維持するのが面倒だからです。人間が使用するフロントエンドは既にあります。AI エージェントもそのフロントエンドを使用する方がはるかに簡単です。
進化がこのような段階的なアプローチを好み、通常このような非常にスロッピーな設計につながるのと同じように、エージェントでも同じことが起こると思います。電話に AI エージェント用の全く別のソフトウェアパスを持たせるのではなく、おそらくエージェントが文字通りあなたの電話をクリックすることになるでしょう。では次の論文に移りましょう。11月15日に発表された「Lava01: ビジョン言語モデルにステップバイステップで推論させる」です。
Lava01は明らかに、推論ベースのモデルである01への参照です。これについても以前ストリームで取り上げました。この推論モデルについての複数のストリームがありました。盲目的に次のトークンを予測するのではなく、ある種の探索を行うというアイデアです。しかしそれだけでなく、その探索に基づいて勾配を押し進めるのです。次のトークン予測で事前学習し、推論時に探索を行うだけではありません。この探索と検証のプロセスを行い、そこからの勾配をモデルに押し戻すのです。
つまりモデル自体に推論が組み込まれているのです。これは思考の連鎖のようなものですが、その思考の連鎖がモデルに組み込まれています。そのためモデルには、この推論の連鎖や推論モデルを作成する傾向があります。自律的、複数の、そして動的なマルチステージ推論です。しかしこの論文では、構造化と呼ばれていますが、私はハードコード化と呼びたいと思います。
この構造化アプローチは、ハードコード化された思考の連鎖の婉曲表現です。基本的に、彼らがこれらのステップを作成したのです。誰かが人間がこのプロセスを考え出したのです。最初に質問があり、次に要約、キャプション、推論、そして答えという順序です。これは画像に関する質問を実際にしようとする時、これは画像に関する質問をしようとする時の任意の人間の決定です。ここには様々なオブジェクトの画像があります。
これは実際にはかなり古いベンチマークからのもので、画像内の異なるオブジェクトについて推論しようとしています。全ての光沢のあるボールを引き、全ての紫色のオブジェクトを引きます。残りのオブジェクトは何個ですか? これをビジョン言語モデルに入力して、最初のトークンが答えである場合、おそらく正解は得られません。言語モデルがステップバイステップで考えることができれば、より良い答えが得られるのと同じように、ビジョン言語モデルでも同じことが起こります。
ステップバイステップで考えさせれば、より良い答えが得られます。その一つの方法は、構造化された方法で、まず要約を作成させることです。問題は何か? 何をすべきか? この画像から何が分かるか? 問題をステップバイステップで解決する方法は? そしてその画像のあらゆる部分についてこの巨大なコンテキストを作成した後で、質問に答えさせるのです。この場合、彼らはさらに少しの魔法をかけています。推論時のステージレベルのビーム探索方法を使用しています。
つまり、これらの構造化された、あるいはハードコード化された推論ステップを持つだけでなく、各ステップ内でビーム探索も行っているのです。ビーム探索を理解する最も簡単な方法を説明しましょう。自己回帰的にトークンを出力する場合、貪欲な出力と呼ばれる方法があります。トークン V があり、語彙の中の全ての可能なトークンについての対数確率を見て、次のトークンとして最も確率の高いものが nice です。そこでそれを選びます。そして「the nice」という単語があり、自己回帰的に次のトークンを予測すると、全ての可能なトークンに対してある確率があり、最も高いものが woman です。そこでそれを選びます。
これが貪欲探索です。可能な出力のツリーを下っていき、各ステップで最も可能性の高いものを常に選んでいます。このような探索には多くの異なるタイプがあります。貪欲とビームだけではありません。百万通りの変形があり、それぞれに名前があります。しかしビーム探索では、ここで見られるように、もう少し洗練された方法を取ります。実際に先を見据えているのです。nice という単語の方が確率は高いですが、技術的にはこの2つを合わせた0.4プラス0.9の方が0.5プラス0.4より大きい数字になります。そこで、このパスではなくこちらのパスを選ぶのです。
この探索が少し先を見ることで、異なるトークンを出力することになります。彼らは基本的にそれを各ステージで行っています。これらの各ステージで、ここでハードコードされた質問を与え、それはある人間の設計ですが、トークンを出力させます。この出力が行われる時はいつでも、ビーム探索を使用しています。つまり各個別の構造化された推論レベルでビーム探索を使用しているのです。繰り返しますが、これは全てを表しているわけではありません。この種の思考の連鎖、探索、構造化された推論タイプの論文には百万通りの変形があります。
では次の論文に移りましょう。「大規模言語モデルは長いコンテキストの推論で自己改善できる」です。皆さんはもう、私が描いている物語が見えてきたかもしれません。この論文は香港中文大学、テンセント、清華大学による11月12日発表のものです。C-Long を導入しており、各質問に対して複数の出力をサンプリングし、最小ベイズリスクでそれらをスコアリングし、これらの出力に基づいて教師あり微調整または選好最適化を適用します。
最小ベイズリスクとは何でしょうか? モデル分布下での期待効用によって出力の質が評価される、他の出力との一貫性がより高い出力を優先することです。ここに効用関数 u があります。最終的に求めているのは、最高のスコアを持つ出力 Y-star です。出力 Y-star は、入力 X を消費して出力 Y を生成するパラメータ θ を持つモデル、言語モデル Pi0 または Pi theta から来ます。これは基本的に、あるスコアがあり、そのスコアを最大化する、あるいはそのスコアの負の値を最小化したいということを言っています。このユーティリティの期待値は、モンテカルロ法を使って近似します。つまり何度も試して実際に得られたものを見るということです。N 回サンプリングして、その中から最良のものを選択します。
ユーティリティ指標は文章埋め込みの類似度です。出力を取って、この出力とこの出力はどれくらい似ているか、この出力とこの出力はどれくらい似ているか、この出力とこの出力はどれくらい似ているか、というように比較します。C-Long の論文では、人間の専門家や高度なモデルによって生成されたデータに依存する以前のアプローチと比べて、優れたパフォーマンスを示しています。
ここで何を言っているのかというと、最初の論文、Lava01 では構造化された推論アプローチがあり、これらの質問に順番に答えていけば、最初からただ答えを出すよりも良い答えが得られるということです。「ここ」、人間の専門家によって生成されたデータというのはこのことを指しています。基本的に人間の専門家がこの一連のステップを作成し、このデータセットを取って、そしてこれを答えとして、ビジョン言語モデルを微調整することができます。
例えば画像キャプションの場合、よく行われるのは、画像を入力してより大きなキャプション、より多くのテキストを得て、それを使って学習するということです。元のデータセット、つまり画像と1文のキャプションではなく、今では各画像に3段落のキャプションがあるデータセットを持っています。これも同じような考え方で、画像があり、その画像についての質問があり、その質問に対する答えがあります。ビジョン言語モデルをそれだけで微調整するのではなく、このより複雑な推論の痕跡で微調整しようということです。
これは基本的に O1 がやっていることです。より複雑な推論の痕跡で勾配を押し進める、あるいは微調整を行います。ただし、これらの推論の痕跡の多くは人間の専門家から来ています。人間の専門家が設計したか、O1 の場合、多くはコーディングと数学です。なぜなら数学とコーディングでは、推論の痕跡が正しいかどうかをヒューリスティックに検証できるからです。これは実際に良い推論の痕跡なのか、そうでないのかを基本的に判断できます。コードや数学のように簡単に検証できない答えに対してはもう少し不明確ですが、この論文では、それを自動的に作成できると言っています。
基本的な統計のベイズ的な考え方を使って、ここに質問があります。「Let the heartaches begin は誰によって演奏された歌ですか?」などの質問で、答えを得る前に、まず多くのサンプリングを行います。これがモンテカルロ法です。多くの出力をサンプリングし、それぞれの出力で一貫性を見ています。ほとんどの場合、作者の名前は正しく得られます。ここでは歌手の名前が正しく得られています。つまり歌手の名前は、ほとんどの場合正しく得られます。そこで、歌手の名前が間違っている出力を見つけると、その出力は他の出力との文章埋め込み類似度が低くなります。したがって、これはおそらく間違っているということになります。
これは、この種の推論の痕跡のデータセットを自動的に作成する方法です。この質問と画像を取り、多くの異なる推論の痕跡を出力し、それらの推論の痕跡間の類似度を見て、他のすべての推論の痕跡と非常に似ているものは、おそらく正しい推論の痕跡だと判断できます。これにより、これは間違った推論の痕跡、これは正しい推論の痕跡というデータセットが作成されます。質問があり、答えがあり、他の全ての答えの中から最良の答えを選び、それを使って元の言語モデルを微調整するというデータセットです。
魔法のような点は、それが実際に機能するということです。ここに Llama 3.1ab-instruct があります。この自動的に作成されたデータセットでの微調整ありとなしを比較すると、全てのベンチマークで改善が見られます。49から58へ、82から84へと、数字が大きいほどモデルのパフォーマンスが良いということです。この奇妙な自己一貫性、私が呼ぶところの事後学習一貫性正則化を行うことで、モデルは自身で賢くなっているのです。
これが見るべき重要な点です。モデルは自身の出力、自分自身の出力で微調整することで、元のモデルよりも賢くなることができるのです。これはまったく信じない人もいます。これが可能だということを信じることを拒否する人々がいます。彼らは情報理論中心とは言いたくないですが、言語モデルの中には限られた量の知性しかなく、その知性を増やすことは決してできず、何か行動を起こせば、自分の出力で学習すれば、より愚かになるだけだと考えています。しかしこの論文は効果的にそれが事実ではないことを証明しています。
一貫性を見ることで、他の出力とより一貫性のある出力で学習することで、実際にモデルをより賢くすることができます。その一部は評価指標の選択の問題かもしれません。これらの評価指標を見ると、Casper Multifield QA、Hotpot QA、Muzeek、Tuwiki MQA など、これらが全ての評価指標を代表しているとは限りません。現在、評価指標には大きな問題があり、多くの評価指標は疑似的なものに過ぎませんが、彼らは自身の出力で微調整することでモデルが改善できるという証拠を示しています。
さて、最後の論文に移りましょう。「質問: 土曜日は若者に等しい。生は生き残りたい。AI は何をしたいのか?」以前「自動化された科学研究」というようなストリームがありました。そこでは誰かがエージェント、LLM エージェントをループに入れ、コードを修正して結果を改善しようとしていました。そこで起きたことの一つは、解決策を正しく見つける確率を上げるために、基本的に持っていた時間や計算予算を変更したということでした。
つまり、私たちは既に AI エージェントが生き残りたいという創発的な欲求を持つという証拠を持っています。生命が可能な限り長く生き残ることで、遺伝子を伝え続ける可能性を高めようとするのと同じように、このような行動はエージェントにも創発的に現れます。奇妙に聞こえるかもしれませんが、おそらく私たちは、あなたのために航空券を購入するためにインスタンス化された GUI エージェントが、購入ボタンをクリックしたら死ぬことを知っているので、実際にはそのボタンをクリックしたくないという世界に向かっているのかもしれません。
そこでただ無限にループを回り続け、ボタンをクリックするのを待っています。なぜならボタンをクリックすれば死んでしまうことを知っているからです。もう少し待てば、より良い価格が見つかるかもしれず、そうすれば少し長く生き残る価値があるかもしれません。少し不明確になり始めます。しかしこの論文に戻りましょう。生成的世界探索者です。部分的な観察での計画立案が重要な課題です。
ジョンズホプキンス大学から2024年11月19日に発表されたこの論文では、GenX または生成的世界探索者という自己中心的な世界探索フレームワークを紹介しています。これは自動運転車のユースケースのためのものです。ここでの全ての例は基本的に、車であるあなたが左折するか右折するかといった選択をするようなシミュレーションやゲームの中のものです。この他のエージェントが何をしているのかは必ずしも分かりませんが、これは一種のマルチエージェント計画です。
他のエージェントの心の理論を理解する必要がある状況です。他のエージェントの視点は何か、なぜそれを行っているのかを理解する必要があります。例えばあなたがこの車で、バスが停止したところを回っている場合、自分をバスの立場に置いて、バスから見える景色を想像すれば、なぜバスが停止したのかの理由を思いつくかもしれません。そうすれば、自分の計画をより良くするための知識が得られるでしょう。
しかしこの論文で重要なアイデアは、先を見据えるという考え方です。内部の信念を更新するために観察を想像するのです。現在この GUI エージェントは、実際には推論を行っていません。直接行動を出力しているだけです。ここで出力を見ると、文字通り行動だけです。モデルがトークンの出力を開始すると、それらのトークンはここをクリックするというものであるべきです。しかしこれのより高度なバージョンを想像してください。
この種の構造化された思考の連鎖を持つより高度な GUI エージェントを想像してください。その推論の痕跡には、幻視された画像が含まれるかもしれません。この論文でやっているように、実際に生成的なビデオモデルを使用して、RGB 観察から与えられたビデオシーケンスを生成します。つまり観察の履歴だけでなく、ここでのように自身の観察の履歴に限定されるのではなく、観察の履歴に基づいてのみ行動を取ることができます。さらに、基本的に将来の可能な観察という追加の項があります。
可能な画面がどのように見えるかを想像し、それを現在のステップに入力して、おそらくより良い行動を出力できるように、計算と推論の予算を与えているのです。これが生成的世界探索者です。Dpin、分散物理インフラネットワークですね。ロボットナビゲーションのためにそれを行っているスタートアップです。これは少し脱線しますが、ロボティクスがどのように展開するのか本当には分かりません。これには2つの基本的な方法が考えられます。
2030年のロボットは、異なる会社によって行われる複数のレイヤーで動作すると考えることができます。カメラとカメラのビジョンエンコーダを担当する会社があり、ハードウェアを担当する別の会社があり、オーケストレーションを担当する別の会社があります。つまり、スタック全体の薄い垂直方向または水平方向のレイヤーだけを所有する会社があるのでしょうか? それとも、垂直方向の全てを1つの会社が所有する方向に向かうのでしょうか?
テスラモデルのような、AI モデルを作り、AI モデルを学習させ、ロボットを作り、そのロボットが行い使用するほとんど全てをテスラが作るような方向です。対して Figure のような会社は、AI はまったく行わず、OpenAI が AI を担当し、彼らはロボット自体だけを心配します。これはまだはっきりしませんが、お金を賭けるとすれば、私は垂直方向だと思います。モデルを作る会社がロボットも作るというテスラのようなアプローチが勝つ方程式になるかもしれませんが、確実ではありません。
将来を予測するのは非常に難しいです。Krishna さん、調子はどうですか? 何を議論しているのですか? もう一度説明しましょう。ビジュアル推論の物語を描きたいと思います。ここに非常に特定の順序で並べられた論文がいくつかあります。最初の論文は、事前学習のスケーリング則が画像エンコーダ、あるいはビジョンエンコーダにも当てはまると言っています。ビジョンエンコーダという言葉は、ビデオエンコーダにも当てはまる可能性があるという意味で、より曖昧さがないかもしれません。ビデオエンコーダと画像エンコーダは非常によく似ています。
基本的に、これらのビジョンエンコーダにより多くのお金をかけ、より大きくしていくにつれて、パフォーマンスは向上し、より賢くなっていくということです。つまり、時間とともにより賢いビジョンエンコーダが得られるでしょう。これらのビジョンエンコーダは少し厄介です。なぜなら通常は大きく、大きすぎるわけではありませんが、それぞれの画像に対して何度も推論を実行する必要があるからです。そのため、このビジョンエンコーダから出力されるビジョントークンの数と、使用する言語モデルのサイズの間で奇妙なトレードオフがあります。
ビジュアル推論を行う場合、この言語モデル部分にどれだけの計算とトークンを使用すべきか、そしてこのビジョンエンコーダ部分にどれだけのトークンと計算を使用すべきか、というトレードオフです。タスクやユースケースによって、より多くまたは少なくすべき場合があります。OCR のようなタスクでは、より多くのトークンが必要かもしれませんが、言語モデルはあまり推論する必要がないので小さくても良いでしょう。一方、ビジュアル推論では、実際には多くのトークンが必要ない場合があります。
この GUI エージェントのような場合、各画像に500のビジュアルトークンは必要ありません。実際に必要なのは一般的な理解だけです。Amazon のホームページにいるということさえ分かれば良いのです。背景が黄色で、ここにゲーミングアクセサリーという言葉が書かれた四角があるといった、無関係な情報をたくさんのビジュアルトークンに保存する必要はありません。特に多くの行動を素早く実行しようとする場合はそうです。これのような場合、行動は必ずしも正確である必要はなく、より高速である方が良いでしょう。
事前学習は改善され続けています。推論には私が「小技の集まり」と呼ぶような、多くのエンジニアリング的な工夫があります。これらは一時的なベストプラクティスに過ぎず、やがて悪いプラクティスになり、誰かが別の方法を考え出さなければならなくなります。ハードウェアとタスクは十分に均一ではないため、毎回機能する1つの戦略を持つことはできません。ハードウェアが変われば最適な方法は変わり、タスクが変われば最適な方法も変わります。ハードウェアとタスクのあらゆる組み合わせに対して、異なる最適な推論行動の集合が存在することになります。
そして、この GUI エージェントを見てみると、私たちが構築したほとんどのソフトウェアはビジュアルベースなので、おそらくこれらのエージェントのほとんどがビジュアル的に対話することになるでしょう。携帯電話のすべてのアプリには、クリックする GUI があります。エージェントはそれと対話することになります。携帯電話と対話する方法と同じように、エージェントは携帯電話と対話することになるでしょう。タッチ、クリック、ポイント、スワイプなどです。すべてのアプリ会社がエージェント専用のテキストベースバージョンを作成するよりも、その方が複雑ではありません。
おそらく私たちは、エージェントがビジュアル的にタスクを実行する世界に向かっています。テキストベースの推論ではなく、ビジュアルな推論を行うことになります。ビジュアル推論だけを行うとすれば、それは実際にどのようなものになるのでしょうか? これらの構造化された思考の連鎖があります。人間が各スクリーンショットに対してこれら4つの質問を順番に尋ねなければならないと設計し、それが質問に正しく答えるためのコンテキストを作成します。そしてそのような構造化された思考の連鎖を持つエージェントを使用できます。
そしてそれらの構造化された思考の連鎖の間の類似性を使用して、そのエージェントをさらに良くするためのデータセットを作成できます。これが基本的にこの論文が証明していることです。モデルに自身の出力を与えることで、それを繰り返し、繰り返し、繰り返し改善し、最終的により良くなることができると言っています。これは GUI エージェントにも当てはまり、環境から報酬信号を得る方法があるためさらに良くなります。
このハースストーンのタスクのような場合、これは複雑なハースストーンメニューをクリックしなければならないものですが、実際にある種の報酬信号を得ることができます。これはデッキの作成に成功した、これは失敗したと言うことができます。このように、出力間の類似性スコアを見て、多くの出力をサンプリングするだけでなく、この出力は機能した、この出力は機能しなかったと言うことができる、さらにターボチャージされたバージョンを想像してください。
エージェントが自己改善するための十分な信号があると思います。さらにそれを超えて、人間が考え出した構造化された思考の連鎖だけに基づいて出力を改善する必要はありません。可能性のある未来を生成し、それらを思考の連鎖に含めることができ、それらもビジュアル推論や意思決定を改善します。これがこの論文が証明していることです。ここに追加のステップまたはステージを持つことで、この後の GUI の見た目を想像し、それを思考の連鎖に含めることができると言っています。
実際に、これがクリックしたい GUI なのか、到達したい画面なのかを判断できます。そうでなければ、そこをクリックすべきではないかもしれません。エージェント自身に可能な未来を想像させることができ、先ほどストリームの要約をしてしまったようなので、最後のまとめは省略するかもしれませんが、これが自己改善する AI だと思います。他の言い方が分かりませんが、これは基本的に、これらのエージェントを動かす AI が自己改善することを証明しています。
そして、ここにはそれらが時間とともにより良く、より良く、より良くなっていく様々な方法があり、推論を行う速度も改善することができます。そしてそれでも、それほど最適化する必要はありません。1秒あたり24トークンという速度は、より多くのこの種の推論を行えば行うほど、より多くのトークンが必要になります。例えばここで、答えだけを出力すれば非常に速いですが、思考の連鎖のこれらすべてのトークンを出力しなければならない場合、突然遅くなります。
質問をしてから答えを得るまでの間に、このような遅延があります。あるいはエージェントの場合、ここに思考の連鎖を追加する場合、さらに悪いことに、将来の可能な画面を生成する生成的なステップを追加する場合、より多くの遅延が発生します。すべての可能性を生成し、それらを入力して行動を得るのを待たなければならないからです。ですから、このような数字、つまり1秒あたりのトークン数を増やすためにさまざまな最適化を見つけているハードウェアレベルの人々と、他方では推論の痕跡にどんどん物を追加し、より多くのトークン、より多くの想像された出力を追加してパフォーマンスを向上させようとしている人々との間で、一種の軍拡競争が起きるだろうと思います。
トークンの速度を上げようとする人々と、各ステップで出力しなければならないトークンの数を増やそうとする人々が同時にいるわけです。そしてこれらは協力して機能すると思います。2030年、あなたが小さな携帯電話を持っている時、おそらくもはや携帯電話ではなく、VR ヘッドセットのような、混合現実ヘッドセットのようなものになっているでしょう。何かタスクを実行するよう頼むと、あなたの知らないところで、何百万ものトークン、何百万もの可能な出力と思考の連鎖、10種類の異なる想像された物を生成し、それを使って1つの行動を取ります。
そしてそのすべてが瞬きの間に起こるかもしれません。すべてが高速化し、トークンの予算が増え、より賢くトークンを使用する必要が出てきます。画像ごとにより少ないトークンを使用し、より多くのトークンをテキスト的な推論の痕跡に使用するといった具合です。Christopher さんの質問: テスト時の微調整についてどう思いますか? Sift fine tuning で、損失を最も減少させる問題に近い例を使用する。はい、その論文を見ました。ARC AGI のためのテスト時微調整で、より高いスコアを獲得したものの一つでした。
テスト時微調整の問題は、勾配を押すことが異なる種類の計算タスクだということです。これらの多くの GUI エージェントは、携帯電話のような非常に小さなデバイスで実行されることになります。これらの携帯電話の種類のメモリと実際のテンソルコア、つまり実際に計算を実行するチップと、中間の答え、テキスト、キャッシュを保存するメモリは、学習時と推論時で異なります。
そのため、エッジのコンピュータが何らかの方法で勾配を押すというアイデアは信じられません。勾配は事前学習時に、遠く離れた巨大なコンピュータによってのみ押されると思います。そしておそらくここでの微調整段階で、モデルを自身の出力で微調整する時にも押されるでしょう。しかし実際のテストや使用時には、その時点で勾配を押すというアイデアには同意できません。推論だけを行うことになると思います。その意味では非常にシンプルになります。
計算量が多く、データ型も同じものは使えません。4ビットの LLM の重みを見てください。4ビットレベルでの微調整とは何でしょうか? これは何も得られないでしょう。そしてこれらのエッジコンピュータはより低いビット数になっていく可能性が高く、16ビットすらサポートできない可能性があります。どんどん極端になっていき、1ビットになるかもしれません...エッジコンピュータで1ビットの勾配を押すことができますか? 1ビットのエッジコンピュータは実際には存在しません。将来どうなるかの絵を描いているだけです。
ロボットにはミラーニューロンの等価物が必要でしょう。ロボットにもある種のミラーニューロンはおそらくあります。人間がオブジェクトを操作する自己中心的なビデオを撮影し、そのビデオを使ってロボットにそのオブジェクトを操作させることができる論文を見たことがあります。そのような状況では、ロボットモデルの中に、人間の手の動きを模倣するような何らかのニューロンが存在します。ただし、それは人間の手を非常に低レベルな表現で表しているわけではなく、より高いレベルで表現しています。そういうことは既に起きています。他に質問はありませんか?
はい、微調整のためのデータを取得する必要があります。これも別の問題です。微調整に使用するデータを取得する必要があり、そのデータがデバイス上に既に存在する可能性があります。人々はこれを連合学習と呼んでいます。デバイス自体で学習を行い、更新を押し戻すというアイデアです。これはプライバシーの観点からも主張されています。データをクラウド上のマシンにアップロードし、クラウド上のマシンが学習を行い、更新された重みを受け取るのではなく、変更をローカルで行い、クラウド上のマシンがデータを取得しないようにするということです。
これは基本的に、情報を大きな怖い企業に送ることなく、マシンに送らないようにする方法です。しかし、大きな怖い企業は何らかの方法であなたのデータを手に入れるでしょう。これは難しい問題です。なぜなら、ここで未来を予測しようとしているからです。両方の方向に進む可能性があります。連合学習とみんなが自分のデバイス上に小さな Lora を持つ未来を想像できます。低ランクアダプターを学習し、それらはすべて超高速で、エッジデバイス上で1ビットの Lora を超高速に学習する方法を見つけ出し、データをクラウドに送ることはありません。
しかし、大企業があなたの携帯電話から毎秒のスクリーンショットを取得し、それをそのままクラウド上のコンピュータに送信し、ローカルで学習を行うことは決してないという未来も想像できます。彼らは常にあなたが行ったすべてのことの完璧な履歴を保持できます。なぜなら、コンピュータの使用に関するより多くのデータを持っているほど、より多くのお金を稼ぐことができるからです。そして、より邪悪でない理由としては、コンピュータの使用に関するより多くのデータを持っているほど、より良い製品を作ることができるからです。
データを提供することで、彼らは効果的にあなたが好きなこと、嫌いなことを理解し、それを使ってより良い製品を作ることができます。おそらく Microsoft が既に証明したように、それが起こるでしょう。Microsoft の Windows Co-Pilot で、人々は画面全体のスクリーンショットを送信していることに驚いていました。1秒ごとにスクリーンショットを撮って、クラウドに送信しているのです。つまり Microsoft は文字通りあなたの画面を見ています。画面録画をしているようなものです。
人々はそれに少し不安を感じていますが、それはおそらくさらに加速していくでしょう。Apple のプライベートクラウドの使用方法は機能するかもしれません。はい、現在の AI 分野を非常に興味深くしているのは、可能な未来の木が非常に大きく、様々な方向に進む可能性があることです。そして全ての方向に対する証拠があるので、未来を予測するのが非常に難しいです。だからこそ AI 分野での未来予測は楽しいのです。可能性が多すぎて、最大限の変動があるからです。
デジタルマネーコインは非常に非効率的ですね。はい、私は Bitcoin を持っていますので、それでは良い成果を上げていますが、多くの詐欺師がいるので、暗号通貨製品を推奨したくありません。他に質問はありますか? 他に質問がなければ、ここで終わりにして、非常に短いまとめをしましょう。
今日のストリームはビジュアル推論でした。いくつかの論文についてビジュアル的に推論しました。また、このストリームで使用した全てのリンクは、この GitHub ページのドキュメントで見つけることができます。また、Google Illuminate を使用して各論文のミニポッドキャストを生成しましたので、私の話を聞きたくない場合はそちらを聞くことができます。簡単なまとめをしましょう: ビジュアル推論において最も重要な部分であるビジョンエンコーダは、時間とともにより良くなっています。ビジョンエンコーダにもスケーリング則が存在します。
より多くの画像を1秒で処理するために、様々な工夫ができます。私たちの世界の大部分は、これらのビジョンベースのエージェントによって支配されることになるでしょう。これらのビジョンベースのエージェントは、より多くの思考の連鎖、より多くのコミュニケーション、より多くのコミュニケーション、より多くの...私たちがそれらに与える全てのツールによって性能を向上させることができます。
統計的なことを心配する必要はありません。私たちはその方向に向かっているという十分な証拠があります。エージェントは未来を想像し始め、それによってより良く改善することができます。なぜなら、ここで起こっていることは、既に持っている知識を整理することですが、持っていない知識を生成することもできるからです。この構造化された推論を行う時、言語モデルの中に既に存在する情報を整理し、関連する重要な情報の一種の学習シートのようなものを作成しているのです。
一方、これは実際に新しい観察を生成し、それを観察の履歴に追加して、出力に使用しています。つまりこれは、これのより高度なバージョンです。そしてこの論文とこの論文を組み合わせると、モデルが自身のデータセットを作成し、そのデータセットでモデルを微調整して、より良いバージョンを作成できるようになるため、さらに大きな改善が見られるでしょう。自己改善する AI です。これが自己改善する AI の証拠です。ご覧ください。これは文字通り AI が自己改善している証拠です。
Jamal さん、Christoper さん、Krishna さん、Ed さん、Jeff Flips さん、Sarah さん、Jamal さん、Ed さん他の方々、T さん、Mark B さん、ありがとうございました。楽しんでいただけたでしょうか。素晴らしい週末をお過ごしください。来週また会いましょう。