7,333 文字
みなさん、今日はOpenAIの12日間の発表の初日で、ChatGPTでプレビュー版から正式リリースされたO1モデルについて発表がありました。すぐに実際のテストをしていきますが、まずはこのモデルの発表内容について見ていきましょう。
このモデルは従来より高速で、より強力な推論能力を持ち、コーディングや数学、文章作成が得意やということです。詳細な結果はブログ記事でご確認いただけます。また、O1は画像のアップロードにも対応しており、これは大きな進歩やと思います。視覚的な情報に対しても推論を適用して、より詳細で有用な回答ができるようになっています。
OpenAIによると、O1は思考プロセスがより簡潔になり、O1プレビュー版と比べて応答時間が短くなったそうです。実際、デモでは思考時間が従来の50%まで短縮されたと言うてはりました。つまり、かなり高速な思考ができるLLMということですね。
テスト結果も良好で、難しい質問での重大なエラーを34%以上削減できたとのことです。Plusユーザーや法人ユーザーは今日からモデルセレクターからO1にアクセスできます。私もPlusユーザーなのでアクセスできますが、法人ユーザーや教育機関ユーザーは1週間後にアクセスできるようになる予定です。
また、ChatGPT-1のウェブブラウジングやファイルアップロードなどの機能もO1に追加される予定です。開発者向けには、関数呼び出しや開発者メッセージ、構造化出力などのAPI対応も進めています。これは今後数ヶ月から来年にかけて重要な投資分野になるであろうエージェントワークフローの構築に重要な機能セットになると思います。
さらに、月額200ドルの新プランChatGPT Proも発表されました。ちょっと高額ですが、このプランでは最高のモデルやツールに無制限にアクセスできます。ベンチマーク結果によると、Pro専用バージョンのパフォーマンスは大幅に向上しているそうで、より高い能力やインテリジェンスを求めるユーザーにとっては魅力的かもしれません。
では、O1モデルのテストを始めていきましょう。まず重要なのは、これらの推論モデル、特にO1シリーズの主な問題点の一つである思考ステップの時間です。従来は思考に時間がかかり、使用できるケースが限られていました。今回OpenAIは速度を改善し、はるかに高速な処理が可能になりました。
また、ユーザーからの苦情の一つに、簡単な質問に対しても時間がかかりすぎるという点がありました。例えば、単純な挨拶をしてみましょう。ChatGPT O1を選択して「hi」と入力してみます。ほんの1秒で応答がありました。これは素晴らしい体験です。モデルが状況に応じて思考時間を調整できるということは、柔軟性という意味で大きなメリットです。
次に、このモデルの速度をテストしていきます。ChatGPT O1とO1ミニを比較してみましょう。O1プレビューへのアクセスはできませんが、O1ミニと比較することで速度の違いを確認できます。デモではO1プレビューと比べてかなり高速だったようですが、今回はO1ミニと比較します。O1ミニも非常に高速なモデルですが、どのように比較されるか興味深いですね。
新しいチャットを作成して、両方のモデルで同じプロンプトをテストします。今日のデモで使用されたプロンプトを借用します：「2世紀のローマ皇帝とその在位期間、業績を列挙してください」
両方に入力してみましょう。数秒の差がありましたが、それは考慮に入れます。O1ミニはすでにかなり早く回答を生成しました。O1プレビューとの速度比較は難しいですが、従来のO1プレビューモデルは思考ステップに非常に時間がかかっていたことを考えると、今回のモデルはかなり早く回答を生成できています。
O1は15秒かかり、O1ミニは数秒でした。明らかにO1ミニの方が早いですが、これは小さなモデルだからです。元のモデルなら30～45秒はかかっていたでしょう。報告によると思考ステップが50%速くなったということで、デモの比較結果とも一致しているようです。
次に、推論LLMでよく行うテストをしてみましょう。O1はより高度なモデルなので、これを解決できるはずです。ろうそくが何本か並んでいて、最初に消えたのはどれかという問題です。詳細は読みませんが、答えは3本目のはずです。ほとんどのモデルは質問を誤解して4本目と答えてしまいますが。
実行してみましょう。このような問題なら数秒で解けるはずです。はい、5秒で解けました。3本目のろうそくが正解だと答えています。素晴らしいですね。
次は数学の問題です。これらのモデルは数学、コーディング、科学が得意です。OpenAIがベンチマークで重点を置いている分野です。この問題は、DeepSeek R1や最新のQwen-Teamのような多くのオープンソース推論モデルにとって非常に難しい問題です。解けても思考ステップが長すぎて、モデルが多くのループに陥ってしまいます。このモデルがどのようにこの問題を解くか、どんなステップを踏むのか興味深いです。
この問題には少し時間がかかっていますね。計算を確認しているようです。これらのモデルにとってはかなり難しい問題です。正解は出せると思いますが、時間がどれくらいかかるか気になります。
21秒かかりました。他のオープンソースモデルと比べると、おそらく10倍は速いです。それらのモデルはこの問題を解くのに数分かかります。思考ステップに非常に時間がかかるのです。ただし、この比較は公平ではないかもしれません。このモデルは速度最適化されており、おそらくより多くのリソースを持っているからです。
これはOpenAIが言及していたことで、O1モデルとProモデルにより多くのリソースを割り当てるとのことです。そのため無制限アクセスを提供できるわけです。
答えは正解です。ここでは精度を評価しているわけではありませんが、正確です。思考ステップを見ると、右側のペインに答えを導き出した過程がまとめられています。このモデルがこれを解けること、そして他のモデルや代替手段と比べてはるかに速く解けることは注目に値します。
次に、Ethan Mikのクロスワードパズルをテストしてみましょう。O1プレビューもO1ミニもこれを解くことができませんでした。Ethan MikはAIと能力について多く書いていて、私は彼の例を使うのが好きです。このパズルは、最近の参照を多く知る必要があり、知識集約型のタスクなので、これらのモデルにとってはかなり難しい問題です。
モデルのパフォーマンスを確認し、どれくらい時間がかかるか見てみましょう。O1プレビューでは回答を得るのに200秒ほどかかりました。この問題に対してどれだけ速く回答しようとするか興味深いです。おそらく答えを知らず、行き詰まって、確認や見直しを繰り返すでしょう。
この問題が興味深いのは、チャレンジングな問題に対して、これらの推論モデルが思考ステップで行き詰まってしまうのを見られるからです。どのようにアプローチするか気になります。
完了までに4分1秒かかりました。録画を一時停止する必要がありましたが、これがこの問題の難しさです。今日のデモでOpenAIチームが言及していた興味深い点は、モデルが曖昧さを考慮できるということです。知識のギャップや問題の一部として提供されていない情報があるかもしれません。ここでもそれが問題かもしれません。十分な手がかりを与えていないのかもしれません。
モデルがこれをうまく処理できるのは素晴らしい能力です。まだその段階ではないかもしれませんが、推論LLMはより良く計画を立て、特にウェブ検索などのツールにアクセスできる場合は、より深く情報を検索できるようになるでしょう。ウェブ検索にアクセスできれば、この種のタスクでより良いパフォーマンスを発揮できるはずです。オンラインで参照を探し、この問題が実際に必要とする最新の情報を見つけることができるはずです。
回答を見てみましょう。すぐにわかりますが、このパズルの解答は正しくありません。これも違います、これも違います。いくつか正解はありますが、ほとんどが間違っています。約20%が正解で、全体の回答はここにあります。正解を期待していたわけではありません。この特定のタスクにどれくらい時間がかかるか、より興味がありました。
推論ステップを見ると、明らかにより多くのステップが必要です。間違いを犯したステップと、どのように自己修正できるかを見るのは興味深いでしょう。Ethan Mikが同様の問題で実験したように、モデルにヒントを与えることもできます。「one down is apps」というヒントを与えました。これはこのパズルではあまり一般的ではない参照です。「Galaxy cluster is apps」が正解なのです。
ヒントを与えれば解けるかもしれませんが、O1プレビューではそれを再現できませんでした。このモデルは推論能力が強化されているので、できるかもしれません。皆さんも試してみてください。
ツーリングに関して興味深いのは、ファイルの添付機能が追加されたことです。まだ検索機能はありませんが、近々追加される予定です。また、ボイスモードも使用できます。
この例では、同じクロスワードパズルを使いますが、異なる入力方法を試してみます。添付ファイルと画像の添付が可能になりました。モデルは画像も理解できるようになったのです。これは本当に素晴らしい新機能です。
同じパズルを使います。ここにパズルがあります。4つの説明と、クロスワードパズルの4つの説明です。先ほど試したのと同じものですが、入力方法が異なります。これがモデルの助けになるかもしれません。以前言ったように、情報の提供方法が理想的でないかもしれません。システムにとって理想的な方法があるかもしれません。
開発者がこのようなモデルを使い始めるとき、どのような入力、どのようなコンテキストを提供できるか、特に画像を提供できるようになった今、非常に興味深いことです。これは非常に強力になる可能性があります。
同じパズルをテストして、「黄色でハイライトされた説明を解いてください」とプロンプトを出します。他の説明も提供できますし、以前の説明をそのままペーストすることもできますが、このモデルの画像理解能力に興味があります。画像理解に別のモデルを使用しているのか、このモデルを使用しているのか、わかりません。言及されていませんでした。
9秒でこのパズルを解こうとしました。どう考えればいいのかわかりません。先ほどは4分かかりましたが、今回は9秒です。なぜ速かったのか、まったくわかりません。思考ステップの詳細もありません。ただ問題を解こうとしました。
答えを見てみましょう。明らかにこれらは正解ではありません。いくつか正解があります。これは正解、これも正解、これら2つは間違い、これは正解ですが、他は間違いです。結局、問題は解けませんでした。非常に混乱しています。何が起こったのかわかりません。
「DTSは利用できません。時々モデルは要約するものがなくても最適な応答を生成します」とあります。非常に混乱します。テキストの代わりに画像を提供したからなのか、システムが完全に異なるモデルを使用して画像理解を行っているのか、まったくわかりません。憶測はしませんが、これは非常に興味深い結果でした。
最後にもう一つ問題をテストしましょう。これはコーディングの問題です。私のAIエージェントコースで作り方を紹介している、ちょっと変わったエージェントシステムのアーキテクチャを与えました。プランナーエージェント、ライターエージェント、エディターエージェントがあり、インターネットと記事があって、このエージェントシステムがコースプランを作成します。
このコードを作成するようにプロンプトを出しますが、動作するコードを期待しているわけではありません。このモデルがどのようにアプローチするか、この画像をどのように理解するかを知りたいだけです。このエージェントシステムには、ツールに関する情報など、多くの部分が欠けています。ヒントはあるかもしれませんが、どのように理解するか見てみたいと思います。
今日のOpenAIの研究者のデモで言及されていたように、これらのモデルは推論、ギャップの埋め合わせ、このような情報の理解、曖昧さへの対処が向上しているそうです。「使い慣れているエージェントフレームワークを使って、このエージェントワークフローを実装してください」とだけプロンプトを出します。どのフレームワークでもいいです。
実際にコードをテストするつもりはありません。どんなコードを生成するか見てみたいだけです。私はLangGraph、CreAI、Autogenなどのエージェントフレームワークに詳しいです。
数秒で完了しました。素晴らしいですね。LangChainを選択しましたが、驚きません。プランナーエージェントがあり、「入力は記事のコレクションとコンテキストのためのインターネットまたはベクターデータベースへの潜在的なアクセス」とあります。これはすでに印象的です。何も言及していないのにこれを理解しています。
「インポートされた記事から高レベルのコース概要やプランを生成する」というのは素晴らしいです。「構造化されたコースプラン、モジュールやレッスンのリスト」が出力されます。これらのエージェントは全て、次のエージェントに提供する何かを出力します。これはプランナーエージェントからの構造化されたプランですね。
各モジュールを詳細に展開し、コーステキストの完全な下書きを作成します。そしてエディターが最終的なコースプランを洗練させ、公開準備を整えます。これは素晴らしいです。なぜなら、これらのエージェントを構築する際には、各エージェントの役割、モデルが何をするか、タスクは何かを説明する必要があります。
ここではラベルだけを提供していますが、これはすでにエージェントの構築に役立ちます。エージェントへのプロンプトの方法や、異なるエージェントのセットアップ方法についてのアイデアを与えてくれます。
技術的な考慮事項として、各エージェントはLangChainエージェントとして、または慎重に設計されたプロンプトを持つLMコールのチェーンとして実装できるとあります。それは理解できます。ウェブ検索やベクターデータベースなどの外部ツールが必要な場合、エージェントのツールとして統合できるとのことです。
プランナーエージェントは記事からの洞察を収集するために検索チェーンを使用するかもしれません。それに同意です。ライターエージェントはツールを必要とせず、生成されたプランだけでいいかもしれません。それも正しいです。エディターエージェントは単純なLLMコールを使用した改良ステップかもしれません。これも非常に正確です。
実装自体を見てみましょう。コードはテストしませんが、別の動画でやってみるかもしれません。これがプランナーエージェントのプロンプトです。これはチェーンで、GPT-4を使用しています。これらが記事で、これは例です。記事は実際のコンテンツに置き換える必要があります。
これがライターエージェントで、独自のプロンプトがあります。ライターチェーンがあり、エディターエージェントも独自のプロンプトと実行すべきタスクを持っています。最後に最終的なコースプランがあります。
エディターチェーンを実行し、これらすべてが連鎖して最終的なコースプランをレンダリングするようです。これはLLMチェーンの実装のようで、ツールへのアクセスなどはありません。
上部に「エンドツーエンドエージェント」とあり、例としてツールがあります。プランツール、ライトツール、エディットツールです。「これらのステップを順番に処理できる単一のエージェントを使用したい場合、コースのプラン、コースの作成などのツールを設計できる」とあります。
「これらのツールを順番に選択するエージェントを初期化できる」とし、これはゼロショットリアクト記述のようです。実際に動作するコードかもしれません。最後にエージェントの実行があります。
有効なLangChainコードに見えますが、すぐには動作しないかもしれません。実装の詳細を見たかったのですが、良い出発点になりそうです。特筆すべきは、ツールの選択です。ここにツールの言及はありませんが、ヒントは提供しました。
エージェントの説明、タスク、出力、これらすべてがエージェントやエージェントシステムを実際に動作させるために非常に重要です。これはシーケンシャルなエージェントワークフローです。シンプルな図から完全な実装に至り、ギャップを埋めてくれたのは印象的です。
あとは実際にテストするだけです。ここで動画を終わりにします。モデルには感銘を受けました。クロスワードパズルのような知識集約型のタスクにはまだ改善の余地がありますが、それはウェブブラウジング機能を待っています。
API面では、関数呼び出し、構造化出力、開発者メッセージなど、多くの機能が追加される予定です。開発者の皆さんは、リリースされたらぜひチェックしてください。このモデルははるかに高速で、より多くのタスクに適用できるようになると思います。
タスクのカバレッジは大幅に改善され、OpenAIはこれをさらに高速かつ効率的にしていくでしょう。この一連のモデルで確実に進歩を遂げているように感じます。
ここで動画を終わります。ご視聴ありがとうございました。質問があればコメントを残してください。このモデルは定期的にテストしているので、フォローアップ動画も作成する予定です。よろしければいいねと登録をお願いします。また次回お会いしましょう。
コメント