4,906 文字
Quenチームから素晴らしい新展開がありました。彼らはQwQ（実際の発音は分かりませんが）をリリースしました。このモデルはQuinn with Questionsとして知られており、推論モデルとなっています。
早速結果に入りたいと思います。このチャートを見ていただくと、現在これらの推論モデルを評価するために使用されている一般的なベンチマークがいくつかあることが分かります。これまでにもいくつかの推論モデルがあり、最後に紹介したのはDeep seekのR1 lightモデルでした。この推論LLMsというジャンルの他のモデルとしては、OpenAI O1 mini、OpenAI O1 previewがあります。なぜかGPT-4 0クラット5スニットとも比較していますが、これらは推論モデルとは同じクラスではないと私は考えています。
このQwQ 32ビリオンプレビューモデルを見ると、ライフコードベンチベンチマークを除いて、OpenAI O1 miniを上回る性能を示しています。GPQAでは60に対してWQは65.2を記録しており、これはかなり印象的です。
ここには使用できる数学の問題例もありますが、実際のテストはどこでできるのでしょうか。デモがあるのでそちらに直接アクセスし、これらの推論モデルの異なる推論能力をテストするために私が使用しているいくつかのプロンプトでテストしてみましょう。
ここでQwQ 32ビリオンプレビューモデルを起動しています。これはHugging Face Spacesで提供されており、Quenの一部です。モデルの詳細はすべてここで確認できます。
最初にテストしたいのは、多くのモデルが苦手とするものです。実際、最近リリースされたDeep seekの推論モデルでさえこれに苦戦していました。このモデルがこの特定の数学パズルにどう対応するか見てみましょう。
プロンプトを貼り付けます：「ピーターは同じ長さの5本のロウソクを持っています。彼はそれらを同時に点火し、しばらくしてから順番に消しました。5本のうち最初に消したのはどのロウソクでしょうか？」
いくつかの条件があり、これが答えになるはずですが、ほとんどのモデルは別の答えを出してきます。このモデルが質問について最初に推論し、混乱しないかどうか興味があります。多くのモデルがこの特定の質問で混乱するため、私はこのテストを好んで使用しています。
送信してみましょう。まず気付くのは、たくさんのテキストが表示されることです。おそらくこれが、このモデルの推論プロセスと呼ばれるものでしょう。かなりの量の処理が行われています。
最終的な答えは4となっていますが、これは正解できていません。多くのモデルがこの特定の質問で苦戦するので驚きませんが、よくあるのは、シナリオについていくつかの仮定を立てて質問を混乱させ、正しい答えにたどり着けないことです。繰り返しになりますが、答えは3であるべきです。なぜならそれがピーターが最初に消すべきロウソクだからです。
次に進みましょう。彼らのブログで使用されている問題の1つを使って、答えに一貫性があるかテストしてみましょう。これはそれほど難しい問題ではありませんが、この論理的推論タスクでどのように対応するか興味があります。
送信すると、ゼロから始めて、必要な異なる推論ステップを実行していくのが分かります。最初にこれを試したときは少し時間がかかったので、正しい答えを出すために必要な生成を待ってみましょう。
ここで録画を一時停止せざるを得ませんでした。推論の長さを見てください。推論自体は評価しませんが、繰り返しがないか、非効率な部分がないかを見るのは興味深いでしょう。
答えだけを見てみましょう。ここに最終的な答えがあり、ブログの答えと比較すると正解のようです。最初に試したときは全く異なる答えでしたが、結果は正しかったので、かなり印象的です。
これはマップベンチマークでも示されており、これはかなり強力なモデルであることが分かります。O1 miniモデルと比較でき、プレビューモデルとも競合しています。これは非常に強い結果です。
さらにテストを続けることもできますし、修正を加えることもできます。次はコーディングタスクを試してみましょう。これはDeep seekモデルでも試しましたが、完全に失敗しました。OpenAIのO1モデルは実際にこれを正しく処理できます。実際、このプロンプトはO1ガイドから採用したものです。
では始めましょう。このタスクでは、バッシュスクリプトを生成することを期待しています。コードを生成し、この入力を受け取って、同じ形式で転置行列を出力するはずです。この形式で表された行列を受け取り、同様の形式で転置を出力するだけです。
ここに解答があります。前回より時間がかかり、出力にはたくさんのテキストがあります。最終的な結果は、使用できるこのバッシュスクリプトのはずで、これをテストしてみましょう。
これをコピーします。きれいにフォーマットされているのは良いですが、このBashスクリプトの実行方法についての説明がすぐには見当たりません。これが命令チューニングの部分に関係しているのかどうかは分かりません。答えは出しましたが、これが最適な答えなのか、最もユーザーフレンドリーな答えなのかは分かりません。
確実に改善が必要です。私が見ているのは基本的にすべてのステップで、推論部分とレスポンス部分の分離がありません。これはおそらくこのモデルに欠けている部分で、対処する必要があります。Deep seek推論モデルやO1と比較すると、解決策は理想的とは言えません。他のモデルは実行方法の説明を提供しますが、私は方法を知っているので、これをコピーしてターミナルで試してみましょう。
ターミナルで、ビデオを簡単にするためにファイルをすでに作成しています。編集してこのコードを貼り付けます。コードはモデルが提供したものをそのまま使用します。
これを終了して実行してみましょう。これが実行コマンドで、ご覧の通り、これが入力です。このスクリプトが受け取って転置できるはずの入力です。「bad delimiter」というようなエラーが出ています。
修正は試みませんが、O1から得た別の出力で同じテストを行ったことをお見せします。これがO1からの正しい応答です。最近出たDeep seek推論モデルから得たものも持っています。
これを試して、実際に出力されたものをお見せしましょう。出力は得られましたが、正しい答えではありませんでした。これは注目すべき点です。非常にシンプルなタスクに見えたにもかかわらず、モデルは実際にはそれを処理できませんでした。
このケースではさらに悪く、エラーが出ました。少なくとも実行して動作し、Deep seekモデルが私に与えたように、たとえ答えが正しくなくても何らかの答えを与えることを期待していました。コーディングにはもう少し改善が必要で、ベンチマーク結果でもそれが明確に示されていたので、これは予想通りの結果でした。
モデルに戻りましょう。最後にテストしたいのは、私のお気に入りのタスクの1つです。一見簡単そうに見えますが、実際にはWolfram Alphaのような計算エンジンに行けば、このようにクエリを実行するだけで答えを素早く得られます。
LLMs、特にこれらの推論LLMsでこの特定のタスクを試してみましたが、これは他の数学関連のテストと比べてはるかに難しいタスクです。そのため、私はこれを試すのが好きです。
実際に必要なのは、最初の70個の素数の合計を求め、70個の素数が何かを把握し、それらを合計し、そして4桁を抽出する必要があります。これらの異なる数学演算をどのように実行するかを知る必要があります。
これを送信して答えをチェックしてみましょう。Deep seekでこれを最後に行ったとき、非常に興味深い結果となりました。問題を分割した方法が面白く、最初の10個の素数、次の10個の素数、その次の10個の素数というように進めました。
これが使用したアプローチで、実際に正解を得ることができ、Deep seek推論モデルにとても感心しました。このモデルがこのタスクでどのように対応するか非常に興味があります。
ここで見られるように、それが戦略です。次の10個の素数を求め、他のモデルと同じ戦略を使用しています。次の10個の素数が表示されているのが分かります。これらのモデルがこの戦略を実行しているのは非常に興味深く、実際に理にかなっています。簡単そうに見えるけれど実際には難しいこのタスクの解決方法を単純化しているからです。
素晴らしいですね。ここで「最初の70個の素数の合計はこの数字です」と表示されています。ちなみにこの数字は正しく、最初の70個の素数の合計です。
では、最後の4桁を抽出するのが次のステップです。どうするか見てみましょう。それについて進めていきますが、なぜこれを行ったのか分かりません。これも、推論モデルが時々行う不必要な追加ステップの一例です。
おそらくここには欠けている機能があります。モデルがすでに生成した推論を振り返り、最終答えに近いものを持っていることを認識し、それらの数字を抽出するという単純な操作だけが必要だということを理解する能力です。これは解決策の一部として期待するものではありません。
ここで「合計の最後の4桁は次の通りです」と言っていますが、まだ最終答えを提供していません。答えを検証しようとしているようです。これは自己反省の一部かもしれません。このモデルがそのように明示的に訓練されたかどうかは分かりません。ブログでそのような記述を読みましたが、実際の訓練詳細を見ていないので確認できません。
「待って、まだ以前の合計と一致しません」と言って混乱しています。最後まで見てみましょう。混乱して、いくつかのチェックを行い、最終的にここで答えを得ました。
正しい答えを得られたのは印象的です。Deep seekと非常に似ていますが、推論ステップが効率的ではないと思います。既に答えを持っているのに検証しようとするなど、不必要なステップを実行するため、これを本番のLLMアプリケーションでは使用しないでしょう。
前述したように、進行中の推論を評価できる機能が欠けているのかもしれません。そのため、レスポンスと推論ステップを分離することが重要だと考えられます。これはO1が非常にうまく行っており、Deep seekもその部分をうまく処理しました。
しかし、それをどれくらいの頻度で行うべきか、どうすればより効率的にできるかということが、これらの推論LLMsを構築し、より本番向けにしていく上での課題になると思います。現時点では、多くの不必要なステップを実行しており、生成すべきでないトークンを生成しているため、実際にコストがかかることになります。
「検証する必要がある」「一貫性をチェックする必要がある」などと正当化するかもしれませんが、ユーザーとしては気にしません。このタスクには重要かもしれませんが、モデルには推論能力を非常に効率的に使用してほしいだけです。これは私たちコミュニティとして解決する必要がある課題です。
以上が私の考えです。結果についてどう思うか、コメントを残してください。このモデルには非常に感心しましたが、コーディングタスクには少し失望しました。もっとシンプルなコーディングタスクを与えてみるべきかもしれません。将来の推論モデルのために、いくつかの異なるコーディングタスクをまとめようと思います。
このチャンネルでは推論LLMsについて多く取り上げているので、まだチャンネル登録していない方は、これらの更新を見逃さないようにぜひ登録してください。ビデオを楽しんでいただけた場合は、いいねの登録もご検討ください。ご視聴ありがとうございました。また次回お会いしましょう。
コメント