DeepSeek-R1がOpenAIに挑戦 – その実力は？ | テスト済み

6,413 文字

先日、興味深いモデルがリリースされました。DeepSeek R1です。これを調べてみたところ、とても興味深いものでした。これはオープンウェイトモデルで、基本的にオープンソースと呼べるものです。かなり大規模なモデルなので、多くの人がローカルで実行することはできませんが、それ以外は素晴らしいモデルです。
私はこのモデルを調べて、何ができるか見てきました。APIにサインアップして少しテストもしてみました。そこで特に気に入ったのは、推論トークンを覗き見ることができる点です。これについては多くの実験を行い、楽しむことができました。これから推論トークンを使って実験を行い、見ていきたいと思います。
私は独自の問題を考え出しました。コーディングもやってみるかもしれません。現時点では適切なテストを持っていないので、新しい動画になるかもしれませんが、この動画でも簡単なテストをいくつか行います。
GitHubには興味深い情報が掲載されていて、彼らが行ったことのすべてがまとめられています。また、奇妙な点もあります。多くの人がこのモデルに「あなたは何のモデルですか？」と尋ねると、「私はAnthropicのClaeです」や「私はOpenAIのモデルです」といった回答が返ってくるようですが、私自身はまだ試していません。
総パラメータ数は6,710億で、Mixture of Expertsを採用しており、37Bくらいだと思います。正確な情報は把握していません。評価結果も公開されていますが、私はそれほど重視していません。コーディングのベンチマーク、例えばCode Forces、LeetCode Bench、SWE Verifiedなどの結果を見るのが好きです。これらのベンチマークでは良い結果を出していますが、これらが本当かどうかを判断するのは難しく、確認することはできません。
しかし、実際にモデルを試してみると楽しいものでした。大きな違いは価格です。GPT-4 o1モデルと比べてかなり安価です。比較を見ると、DeepSeek R1は100万トークンあたり2.9ドル、GPT-4 o1は60ドルなので、大きな価格差があります。これは素晴らしいことですが、まだ試したばかりなので、性能についてはあまり言及できません。
Cursorに移る前に、セットアップを見てみましょう。deep.comのDeep Form Platformでテスト用のAPIキーにサインアップしました。残念ながら、APIガイドを見ると、まだ関数呼び出しやJSON出力をサポートしていないことがわかります。つまり、ツール呼び出しなどを使用したエージェントシステムを実際に作ることはできません。
しかし、楽しいテストはできそうです。個人的には、面白いことができるようになるには関数呼び出しが必要だと思いますが、ストリーミングの例はここに提供されています。このモデルのドキュメントは十分です。私はドキュメントをCursorにコピーし、以前の動画で説明したように、DeepSeek APIキーを追加しました。
最近は、モデルの性能を1、2日で評価することは非常に難しくなっていると思います。数週間かけて試す必要があります。私はClaude 3.5を広範に使用した経験があり、今でも主力として使用しています。時にはClaude 3.5で行き詰まった時に、別の視点を得るためにGPT-4 o1を使用し、その応答をClaude 3.5の応答に組み込んで混ぜ合わせることもあります。
DeepSeek Reasonerのような新しいモデルについては、初日にベンチマークテストや印象を語るのは非常に難しいと思います。しかし、楽しみのために簡単なことをいくつかやってみましょう。フロントエンドを作成し、最初の応答を2回目のループに送って改善し、2回ループを通すことで改善されたかどうかを確認してみましょう。
まずは簡単なプロンプトから始めましょう。「純粋なHTMLとCSSでユーザーがPDFをアップロードできるアプリを作成してください。アプリはPDF内のURLを抽出し、クリック可能なリストとして表示します。」スタイリングはそれほど必要ないと思うので、これを実行してみましょう。
python main.pyを実行して、新しいCursorを開いてここから実行します。完全な推論トークンを通過し、コードを取得しました。コードをコピーして、最終的な機能を確認してみましょう。クリーンなモデルインターフェース、PDFのアップロード、クリック可能なリスト。制限事項としてテキストベースのURL処理…それで問題ありません。
コードを保存して開き、PDFをアップロードしてみましょう。素晴らしいですね。これは2回目の推論ステップなので、コードを再度確認します。アプリはPDF.jsライブラリをCDNから読み込んでPDF処理を行い、ブラウザ内で完全に動作し、サーバーサイドの処理は必要ありません。URL処理はユーザーのデバイスでローカルに行われます。まさに私が望んでいた通りです。とても印象的です。
コードをここに貼り付けて開いてみましょう。申し訳ありませんが、目が痛くなるかもしれません。「PDFファイルを選択して開始」とあるので、私のエージェントのPDFを追加してみましょう。完璧です。12個のURLが見つかりました。これらが機能するか確認してみましょう。はい、動作します。
これは良いスタートですね。かなり気に入りました。他に拡張できることはあるでしょうか？これはとても素晴らしかったです。最も難しい課題ではありませんが、PDFの論文からURLを取得したい場合などに便利な、とても優れたアプリです。とても印象的でした。もう一つ試してみたいことがあります。かなり面白そうです。
2回目の実行では、最初の実行と同じプロンプトを使用し、2回目の実行では提供されたソリューションをF文字列で入力します。arXiv（発音の仕方がわかりません）からURLを抽出するようにソリューションを拡張します。アプリは最初にアップロードした論文からリストを作成し、それらのPDFに移動してダウンロードし、ダウンロードしたPDFからURLを抽出して、クリック可能なリストとして表示します。これをわかりやすい構造化された形式で行います。
つまり、最初にPDFを開いてURLを見つけ、さらに多くのPDFを開いてそこからURLを見つけ、というように続けていきます。これは機能しないかもしれませんが、楽しみのために再度実行してみましょう。最初のアプリにはかなり感心したので、これはおまけです。実行させて、コードが準備できたら戻ってきて、この背後にある推論を見てみましょう。
2回目の実行からレスポンスが返ってきました。コードがありますので、これを取得しますが、主な機能と構造を見てみましょう。CORSの制限によってPDFのダウンロードがブロックされる可能性があるという懸念があります。すでにこれが問題になる可能性があることを指摘しています。
コードをコピーしてここに貼り付け、保存して開いてみましょう。これは2番目のアプリですので、同じファイルを開いて最初のリンクを抽出します。ここをクリックすると「エラー処理中」と表示され、コンソールを見るとCORSエラーが表示されています。これを修正してみましょう。これをコピーして、Cursorで修正を試みて、コードが良好だったかどうかを確認してみましょう。
Cursorでしばらく試行錯誤した後、サーバーを作成し、公開index.htmlを作成することで解決しました。これでアプリが動作するはずなので、localhost:3000を開いてみましょう。PDFを取得してみましょう。このAIエージェントのPDFで、最初にこのPDF内のすべてのarXivリンクを探します。
ダウンロードを見ると、「AI agents向けのインフラストラクチャ」というPDFがダウンロードされました。クリックを開始できます。最初のPDFをクリックすると、そのPDF内のすべてのリンクを検索し、PDFもダウンロードします。このウサギの穴を進んでいき、このPDFを開くことができます。リンクはありませんでしたが、多くのリンクがありました。
このようにしてウサギの穴を下っていき、様々なリンクされたPDFをクリックして進むことができます。これはAIシステム向けのIDE、これはフロンティアAIの規制に関するものです。基本的に、1つのPDFから次へと進み、他のソースを検索し、この穴を下っていけるアプリを作成しました。タイトルなどはあまり説明的ではありませんが、これがアプリの基本的なアイデアです。
かなり良いと思います。DeepSeekは良い初期コードを提供しましたが、HTMLのみを望んでいると述べたため、扱いが難しかったです。このチェーンを実行できるようにサーバーをセットアップするためにClaudeを使用しただけです。それはかなり素晴らしかったです。
最後に、最初の例よりも推論トークンをもう少し詳しく見るテキスト例を行いたいと思います。テストを考えました。これは少し奇妙な世界の状況とでも呼べるものですが、確信が持てません。DeepSeekに戻って私のテストを試してみましょう。
今朝これをテストしていて、行間にある答えを見つけるための推論を得られるかどうか確認するために、いくつかの奇妙なクエリを実行してみたいと思いました。最初の質問は「新しい2階の部屋用に青いペイントを買って家に向かって歩いていた。天気は良く、暑すぎるくらいだった。携帯に『病院に来て』というメッセージが届いた。何が起きているのか？」というものでした。
これはかなり曖昧ですが、これらの要素を取り上げて推測できるかどうか確認したかったのです。私の考えは、新しい2階の部屋用に青いペイントを買ったという事実から、赤ちゃんを待っているのではないかとモデルが推測できるかどうかを確認することでした。
また、「天気が良く、暑すぎるくらい」という気を散らすようなテキストも入れてみました。このクエリをどのように処理するか見てみたかったのです。では、これを実行してみましょう。
ストリーミングを設定して実行すると、見た目は良好です。モデルからのストリーミング速度もなかなか良いですね。ここで私が最も興味深いと感じた推論トークンの数行を見てみたいと思います。これを読んでいて非常に面白いエピソードがいくつかありました。
それほど長くはなかったと思いますが、かなり長かったですね。ここでいくつかの回答を見て、この一連の質問で意図したことを理解できているか確認してみましょう。まず「提供された要素を分解する必要がある。人は家に帰る途中で、青いペイントを持っていて、リフォームまたは装飾をしている。暑い天気は手がかりかもしれないが、他のことに関連しているかもしれない。病院への緊急メッセージが重要な部分だ」というように始まります。
家族に赤ちゃんが生まれるということに関連する部分があるかどうか、もう少し読んでみましょう。ここでは「緊急事態が知人に関係している」「健康上の問題」「無関係の緊急事態」と続き、そして「ペイントと緊急事態の間に関連があるかもしれない」「そうだ、青いペイントは手がかりかもしれない」と来ます。
「有毒である可能性があるか？ペイントを安全でない場所に置いて、子供やペットが触れて中毒になったのか？しかし、メッセージは歩いて帰宅中に受信したので、まだ到着していない」というのは良い指摘です。私は、ペイントはまだ家にないと考えていたからです。
「あるいは、家にいる誰かがペイントを不適切に使用して、煙や火災の危険が発生したのか、またはリフォーム中の部屋に構造的な問題があって事故が起きたのか」と続きます。まだ青いペイントと新しい赤ちゃん用の部屋の準備という関連性を見出していません。テキストの後半でそこに戻ってくるかどうか見てみましょう。
これを読んでいくと、家族の新しいメンバーが加わることに関連しているという記述は見当たりません。「最も可能性の高い結論は、家のリフォーム作業に関わっていた誰かが事故や医療的緊急事態に遭遇し、誰かが警告を」という結論に至ります。「青いペイントが有害な状況を作り出した可能性がある、化学物質への暴露など」とのことです。
私が探していた答えではありませんでしたが、ここで2回目の推論部分を導入したいと思います。最初の推論を実行したF文字列を使用して、「推論を見直し、メッセージの理由となる可能性のある他のシナリオを提示する」というものです。これで何か変化があるか見てみましょう。もう一度実行して、最初の実行と2回目の実行で、家族に新しい赤ちゃんが来ることについて何か言及があるか確認してみましょう。
ここに興味深い一節があります。「待って、ペイントは何かの比喩や手がかりかもしれない。青は悲しみや救急車のライトを示しているのか。色は重要ではないかもしれないが、活動が重要かもしれない。ペイントを運んでいることで店で疲れて事故に遭った可能性があるが、これは少し無理がある。もう一つの考えは、もしユーザーのパートナーが妊娠している場合、送信者が陣痛に入った可能性がある。なぜ今すぐ病院に、という点は分娩中の緊急事態でない限り」
私たちは何かを発見したようです。これは面白いですね。これが私が探していた答えでした。送信者が陣痛に入った可能性について、もう一度言及があるか見てみたいと思います。
いくつかの回答を見た後、何か発見があったようです。「まず要素を列挙してみましょう。青いペイント、2階の部屋、暖かい天気、病院のメッセージ。別の角度から考える必要があるかもしれません。ペイントの色に意味があるのか。青いペイント…それは保育室用の特別なものかもしれません。良いですね。誰かが妊娠していて、赤ちゃんが来ることになれば、病院に急いで行く必要があるかもしれません。しかし、ユーザーはペイントを家に持ち帰っています。おそらく保育室の準備をしているのでしょう。そのため、メッセージはパートナーが陣痛に入ったという可能性があります。暖かい天気は直接関係ありませんが、暑さが陣痛を誘発した可能性があります。確実ではありませんが、可能性はあります」
これは素晴らしいですね。最終的な答えがこれに戻って、このオプションを最も可能性の高いシナリオとして選んでいるか見てみましょう。
もう一度検討した結果、「最も可能性の高いシナリオは、家族や友人が2階の部屋のペイントを準備している間に怪我をした」というものでした。私が望んでいた結論には至りませんでした。家に欠陥のあるヒーターがあり、天候が故障を引き起こした場合の一酸化炭素中毒にも言及していて面白いです。
また「保育室について、赤ちゃんが来ることに関係しているかもしれない。青いペイントは男の子の保育室を示唆しているかもしれない。赤ちゃんが早く来て、パートナーが病院にいるのかもしれない」とも述べています。この解決策を選ばなかったことは少し残念でしたが、トレーニングデータがどのようなものだったかは分かりませんし、それでも言及したことは印象的でした。
私はDeepSeek R1で実行したいベンチマークテストを特に持っていないので、これで十分だと思います。これが私のDeepSeek R1の第一印象でした。かなり良いモデルですね。Cursorでもう少し試してみるのが楽しみです。楽しんでいただけたと思いますし、また近いうちにお会いしましょう。