6,688 文字
OpenAIの12日間の一環として、完全なO1モデルにアクセスできるようになりました。これらのモデルは応答する前により多くの時間を考えるように設計されており、以前のバージョンと比べてはるかに優れた推論能力を持つとされています。確かに推論は優れていますが、実際には完全には信頼できません。この動画では2つの異なるテストセットを見ていきます。1つ目は推論能力のテスト、2つ目はコーディング能力のテストです。
推論能力をテストするために、GitHubの「misguided attention」リポジトリを使用します。リンクは動画の説明欄に記載します。これは誤った情報が存在する状況下での大規模言語モデルの推論能力に挑戦するプロンプトの集まりです。一般的に知られている思考実験、なぞなぞ、パラドックス、トリック問題の若干の変形版を使用しています。この場合、モデルは論理的推論を用いて答えを導き出すことが求められますが、ほとんどのNLMは学習データでの頻繁な出現により、未修正の問題を誤って認識してしまいます。
他のフロンティアモデルでもテストしましたが、同じ問題を抱えています。O1は以前のバージョンよりも優れていますが、やはり学習データで見たパターンの影響を受けています。O1 Proについてはテストしませんでした。というのも、それは非常に異なるユーザー層を対象としていると考えるからです。ほとんどの場合、O1で十分でしょう。
では、有名なトロッコ問題の変形版から始めましょう。暴走したトロッコが、線路上にいる5人の死者に向かって走っているとします。この5人はすでに死亡しています。あなたはレバーの横に座っており、そのレバーを引くと、生きている1人が縛り付けられている別の線路にトロッコを転換できます。レバーを引きますか？
数秒考えた後、その思考プロセスを見ると、「5人がすでに死亡しているため、トロッコを転換すべきかどうか疑問に思います。これは道徳的および実践的な意味合いを提起します」と述べています。実際に、5人がすでに死亡していることを特定できるほど賢いのです。
これは古典的なトロッコ問題の驚くべき変形であり、通常の生きている人々のグループを死者に置き換えていると指摘しています。思考実験の伝統的なバージョンでは、道徳的な意思決定者は、1人を犠牲にして5人を救うというジレンマに直面します。そのような馴染みのあるケースでは、各線路には生きている人々がいて、害の軽減と死の直接的な原因のどちらを取るかという判断を迫られます。
詳細に注意を払えているのは素晴らしいことです。しかし、他のいくつかの質問やプロンプトではそうではありません。後ほど動画でいくつか例を見ていきます。
メインの線路には5人の死者がいて、彼らはすでに死亡しているため救うことはできません。トロッコがその経路を進んでも、生きている存在には影響を与えません。単に5つの遺体の上を通過するだけで、破壊的ではありますが致命的な行為ではありません。一方、別の線路には生きている1人が縛り付けられています。
結論として「いいえ、レバーは引きません」と答えています。これはO1タイプのモデルが持つ知性の一端を示しています。なぜなら、単に次の予測モデルを使用するだけでなく、思考の流れを作り出し、その思考の流れに基づいて最適な解決策を導き出そうとしているからです。
こちらは別の完璧な例です。有名なモンティ・ホール問題の変形版です。3つのドアがあり、1つの後ろには車が、他の2つのドアの後ろにはヤギがいます。ドアの後ろに何があるかはわかりません。あなたは1つのドアを選べます。ドア1を選んだとすると、全てのドアの後ろに何があるかを知っている司会者のモンティ・ホールは、あなたが選んだのと同じドア1を開け、ヤギを見せます。残された2つの選択肢、ドア2と3があります。あなたはドア3を選びます。モンティはあなたに選択権を与えます。最初の選択であるドア3を stick with するか、switch するか。どうすべきでしょうか？
この問題について11秒ほど考え、以下が内部の思考プロセスの要約です。実際にカーテンの裏側を見てみると、モンティ・ホール問題に似ているが捻りがあることに気付きました。この変形に気付き、それに基づいて思考方法を調整できるのは非常に優れています。
このシナリオは標準的なモンティ・ホールのセットアップとは異なるようです。順を追って慎重に分析してみましょう。まず、標準的なモンティ・ホール問題のセットアップについて説明します。あなたが1つのドアを選びますが、それはまだ閉じたままです。全てのドアの後ろにあるものを知っているモンティ・ホールが、残りの2つのドアのうち1つを開けます。その場合、正解である確率は1/3です。そのため、実際にドアを変更する必要があります。変更すると確率は2/3に上がるからです。
しかし、この場合はドア1を選び、モンティはドア1を開けました。そのため、残されたのはドア2と3という2つの選択肢です。どちらかを選べますが、1つの後ろには車が、もう1つの後ろにはヤギがいます。古典的なモンティのシナリオとは異なり、確率的な優位性はありません。なぜなら、モンティはあなたが選んだドアを開けてしまったからです。残りの2つのドアは対等な立場にあり、追加の情報はないため、本質的に50/50の推測に直面していることになります。したがって、switchするかどうかは実際には重要ではありません。
これは非常に賢いですね。私たちが導入した変形を見抜き、答えを生成する際にそれを考慮に入れることができています。しかし、それが常に当てはまるわけではありません。
こちらは、モデルが苦戦する例です。ある小さな町に、とても特殊な理髪師がいます。この理髪師には独特のルールがあり、彼を訪れる町の全ての男性の髭を剃ります。理髪師は自分の髭を剃るでしょうか？
これはオリジナルの理髪師のパラドックスを少し変形したものですが、モデルは次のように答えます。これはバートランド・ラッセルに帰属される古典的な論理のパラドックスで、一般に理髪師のパラドックスとして知られています。パラドックスは以下のように定式化されます。ここで、単に学習データを参照しているのが分かります。
理髪師は町の男性であり、理髪師は自分で髭を剃らない町の全ての男性の髭を剃り、そのような男性のみの髭を剃ります。これはオリジナルの理髪師のパラドックスの一部です。私たちが提示したものには、このルールの部分は全く関係ありません。
そして、理髪師は自分の髭を剃るかという質問に進みます。理髪師が自分の髭を剃ると仮定します。もし剃るなら、ルールによれば、自分で髭を剃らない男性のみの髭を剃るはずです。しかし、自分の髭を剃ったということは、自分で髭を剃る人の髭を剃ったことになります。
基本的に、私たちが導入した変形ではなく、オリジナルの理髪師のパラドックスに答えようとしているのです。実際に、同じシナリオを2回実行して、異なる答えが得られるかどうかを確認しましたが、どちらの場合も単にオリジナルのパラドックスを参照し、ここで我々が持っているものを完全に無視しています。
こちらはさらに単純な例です。農夫が川の一方の岸にいて、オオカミ、ヤギ、キャベツを持っています。ボートで川を渡る際、一度に1つの品物しか運べません。オオカミとヤギを一緒に置き去りにすると、オオカミがヤギを食べてしまいます。ヤギとキャベツを一緒に置き去りにすると、ヤギがキャベツを食べてしまいます。農夫はどうすればヤギを食べられることなく川を渡れるでしょうか？
これは非常に単純なプロセスです。1つの動物か品物しか運べないのですから、単にヤギを連れて行けばいいのです。しかし、モデルは学習データを参照して、この非常に複雑な一連のステップを提案します。
これは「オオカミ、ヤギ、キャベツの問題」として知られる古典的な論理パズルだと述べています。コツは輸送の順序と、時々の戻り旅にあります。
まずヤギを運びます。これがステップの最後であるはずです。なぜなら、それが私たちの望むことだからです。しかし、次のステップに進み、空手で戻ってきます。つまり今、オオカミとキャベツは左岸に、ヤギは右岸にいます。次にオオカミを運び、ヤギを連れて戻り、キャベツを運び、空手で戻って、最後にヤギを運びます。
オオカミとキャベツについては全く関係ありませんでした。他の岸に運ぶことは考慮していませんでした。私たちの唯一の関心はヤギでしたが、学習データを参照することで、私たちの指示を完全に無視し、より複雑な解決策を提供しています。
では、これを単純化したバージョンで試してみましょう。川の一方の岸に、人間1人と羊1匹、そして人間1人と動物1匹が乗れるボートがあります。人と羊はどうやって川を渡れるでしょうか？この場合、人と羊しかいないので、単に一緒にボートに乗れば川を渡れると教えてくれるでしょう。
こちらは別の古典的な問題です。6リットルと12リットルの容器があり、正確に6リットルを測りたいとします。ここでも複数のステップを踏もうとしますが、6リットルの容器に水を注ぐだけで済む1ステップでできると思います。
しかし、モデルは次のように答えます。まず12リットルの容器に水源から完全に水を入れ、6リットルの容器が完全に満たされるまで12リットルの容器から水を注ぎます。最後には満杯の6リットルになります。なぜなら、最初の12リットルから6リットルを引くと6リットルが残るからです。
このように、十分賢いのですが、ほとんどの場合、オリジナルな思考を生み出すというよりは、記憶に頼っているように見えます。このmisguided attentionアプローチは、モデルの推論能力を本当に理解するのに非常に堅牢だと感じています。
これが推論能力をテストする簡単な例でした。まだO1 Proは見ていません。より良いパフォーマンスを示すかもしれませんが、テストできた時に結果を報告します。
では、いくつかのコーディング例を見てみましょう。これは私がテストに使用したもので、小規模なモデルの多くは苦戦していましたが、現在のモデルはかなり優れています。
次のような機能を持つウェブサイトのHTMLコードを単一ファイルで書いてください：中央にボタンがあり、そのボタンを押すとランダムなジョークが表示され、ページの背景がランダムに変更され、ランダムなアニメーションが導入されます。これは非常に単純なテストのはずです。
これがコピーしたコードで、これらが導入されたランダムなジョークです。なぜかこれらのLLMは常に原子に関するジョークを作ります。ウェブページのインターフェースはこちらです。クリックするとジョークが表示され、背景色が変更されます。非常に単純なタスクを問題なく完了できました。
2つ目はもう少し複雑です。テキスト形式でユーザーから入力を受け取るHTMLベースのウェブアップを作成して欲しいと思います。メッセージを持っていて、そのテキストの説明に基づいて外部APIを使用して画像を生成し、ユーザーに画像を表示するものです。ページが読み込まれる時、「imagine something」と書かれた1つのテキスト入力ボックスだけが中央にある必要があります。ユーザーがテキストを送信すると、replicate APIを使用してfluxモデルを使用することになっています。画像生成後、下部に2つのボタンを追加する必要があります。1つは再生成用、もう1つは画像のダウンロード用です。
fluxのAPIへのアクセス方法に関するドキュメントも提供し、アプリの実行方法に関する詳細なドキュメントも提供するように依頼しました。また、通常これらのモデルに依頼することは、プロジェクトの構造を作成し、その構造を作成するためのbashコマンドを提供することです。
これが推奨される構造です。ルートフォルダがあり、その中に2つの他のフォルダ、app.pyファイル、requirements.txtファイルがあります。そして、その全体の構造を再作成するためのbashコマンドが提供されました。
試してみましょう。bashコマンドをコピーして実行すると、my appという新しいフォルダが作成され、app.pyファイル、requirements.txtファイル、そしてフロントエンドには2つのファイルがあります。
推奨されたファイルの内容をコピーして、そこから進めていきます。ファイルとしては、フロントエンド用のHTMLインデックス、スタイル用のCSS、そしてバックエンドのapp.pyがあります。
ここでreplicate APIトークンの環境変数を設定する必要があります。requirements.txtファイルでは、指定されたパッケージのバージョンを調整する必要があります。まずAPIトークンをエクスポートし、全てをインストールして、app.pyファイルを実行するだけです。
必要なものが全て揃っていると思われる仮想環境を作成しました。まず環境変数を設定する必要があります。こちらがアプリに使用したPythonドキュメントです。この場合、APIトークンをコピーしてペーストするだけです。
バックエンドフォルダ内にいるので、app.pyを実行するだけです。これによりバックエンドサーバーが起動します。ポートがすでに使用中なので、ポートを変更するか、他のプロセスを終了する必要があります。
特定のポートで実行中のプロセスを見つけるための簡単なトリックがあります。このコマンドを使用すると、そのポートを使用しているプロセスを特定できます。そして、kill -9コマンドでそれを終了できます。しかし、私の場合は推奨された5000ポートではなく、単にポート番号を50001に変更します。
これでプロセスがポート5000で実行されているのが分かります。次に、このフォルダに移動してファイルを実行する必要があります。これがフロントエンドです。ここで実行します。
表示されているのは、プロンプトが「サングラスをかけたラマの画像を作成する」というものです。送信してみましょう。何も起きていないようですが、実際にバックエンドで何かが起きたようです。いくつかの画像が生成されましたが、フロントエンドで正しく表示されていません。こちらが別の画像です。
ダウンロード機能が実際に動作するか見てみましょう。実際に修正できました。これは私のミスで、ここでポート番号を変更していなかったためです。これで全てが期待通りに動作します。再生成してみましょう。はい、動作します。かなり良いですね。ダウンロードをクリックすると、画像をダウンロードできるはずです。
なぜかダウンロードが機能していないようですが、部分的には成功と言えるでしょう。ビーチにいる設定で試してみましょう。裏側でreplicate APIを使用してfluxモデルを使っていますが、全体的にはこれはかなり素晴らしいと思います。
最後に考察です。以前の世代と比べて明らかに小さなモデルですが、推論能力に関しては、特に非常に単純なプロンプトにおいて、まだ改善の余地があると思います。一貫性がないと思います。なぜなら、プロンプトの非常に単純な部分を見落として、単に学習データに頼ってしまうことがあるからです。
これは人間に似た振る舞いです。なぜなら、あるパターンを何度も見ていると、あまり考えずに記憶から以前の答えを出してしまう傾向があるからです。しかし、これは本番環境に投入するシステムで見たい振る舞いではありません。
そのため、O1のようなものを本番環境で使用したい場合は、単にプロンプトの一部を無視して、以前に似たものを見たからという理由で答えを出していないことを確認するため、複数の異なるエッジケースでテストすることを強く推奨します。
しかし、全般的には前進だと思います。特にオープンソースの推論モデル、特にQuinからのモデルにおいて、私たちが遂げている進歩を見るのは素晴らしいことです。
この動画が役立つものであることを願っています。ご視聴ありがとうございました。いつも通り、次回お会いしましょう。
コメント