カーソルプラットフォームモデルの比較：DeepSeek V3/R1 vs Claude 3.5 Sonnetテスト

ディープシーク 最新モデルテスト：V3 vs. クロード 3.5 ソネット、どっちが上？

ディープシークは最近、次のような発表を行った。 カーソル このプラットフォームは、DeepSeek V3 と R1 という 2 つの新しいモデルを発表しました。 現在、（私たちを含む）多くの開発者は、Claude 3.5 Sonnet（最新バージョン claude-3-5-sonnet-20241022）をメインの言語モデルとして使用しています。新しいモデルが実際にどのように機能するかを確認するために、私たちはこれら2つのDeepSeekモデルとClaude 3.5 Sonnetの実際の比較テストを行うことにしました。

DeepSeekモデルの紹介

DeepSeekは最近、その強力なR1モデルをオープンソース化したことで、多くの注目を集めている。Cursorプラットフォームは常に行動が早く、DeepSeekモデルが公開されるやいなや、人々は待ちきれずに実世界のアプリケーションでテストを開始した。

性能比較リファレンス
ディープシークの公式リリース ディープシークR1 OpenAIのo1とo1-miniモデルに対するV3とV3のパフォーマンスデータ。

テスト・タスクの概要

この比較テストには2つの主要部分がある：

• チャットモード -- 日常的な開発シナリオをシミュレートし、Next.jsアプリケーションのダイアログボックスコンポーネントにサーバーサイドのアクションを追加する方法を探ります。
• コード生成モード -- CircleCI設定ファイルを修正し、コードメンテナンスのシナリオをシミュレートすることで、フロントエンドのデプロイメントに関連する設定と、不要になったE2E（エンドツーエンド）テストのステップを削除する。

Cursorプラットフォームの "エージェントモード "は、一般的にモデルが独自に操作を実行し、ツールを呼び出すことができるモードを指しますが、現在のところCursorプラットフォームでのみ利用可能であることに注意することが重要です。 アンソロピック モデルとGPT-4oはオープンなので、このテストはプロキシモデルには関係ない。

チャットモードの比較

ミッション・ステートメント

私たちが投げかけた質問は、Next.jsアプリケーションのダイアログボックスコンポーネントにサーバーサイドのアクションを適切に追加する方法でした。具体的な質問プロンプトは次のとおりです：

"サーバー側の操作を実装し、それをこのダイアログボックス・コンポーネントに正しく渡す方法を教えてください。"

より具体的なコンテキストを提供するために、ダイアログ・ボックス・コンポーネントに関連するコードを含むファイルも添付しました。

DeepSeek R1の性能

DeepSeek R1は、その注目度の高さから、当然ながらテスト用の最初の選択肢となった。しかし、R1を使ってみて、私たちはすぐに2つの明らかな問題を発見した：

• 出力ストリーミングが遅い
  R1は答えを出すのが遅く、完全なアウトプットを見るには長く待たなければならない。
• 答えは明確なブロックから始まる
  R1は、正式に回答する前に、タグでラッピングされたコンテンツの大部分を出力する。この前処理ステップは、最終的な回答の質を大幅に向上させるのであれば、許容範囲内である。しかし問題は、遅いストリーミング出力と重ね合わせると、実際に有効な情報の提示が大幅に遅れることである。例えば、実際の答えをゆっくりストリーミングする前に、モデルが大きなコンテンツを出力すると、全体の待ち時間が非常に長くなる。理論的には、セクションをスキップするようにカーソルルールを設定することが可能ですが、これは今回のデフォルト状態のテストの範囲外でした。

加えて、R1の回答は問題を解決するためにnext-safe-action/hooksライブラリのインストールを提案しているが、その後の回答でこのライブラリをサーバーサイドの操作に使用する方法についてそれ以上説明していない。私たちが提起したような比較的単純な問題に対して、追加ライブラリのインストールを提案するだけでは、少し「つまらない」ように思えます。

DeepSeek V3の性能

DeepSeek V3もそこそこの性能を発揮し、次のような使い方を推奨している。 反応 これは、V3モデルがより新しいフロントエンドの技術やコードベースについて学習していることを示唆している。しかし、V3にはコード実装に重大なバグがあります。それは、クライアントサイドのコンポーネントから直接サーバーサイドの操作を呼び出してしまうことです。Next.jsでは、これは実現不可能です。(余談ですが、Next.jsでは、セキュリティ、パフォーマンス、コード整理のために、サーバーサイドのコードをサーバーサイド環境で実行する必要があります。クライアント側コンポーネントでサーバー側コードを直接呼び出すと、サーバー側モジュールが見つからない、ネットワークリクエストに失敗するなどのエラーが発生する可能性があります）。たとえば、クライアント側のJavaScriptコードでサーバー側の関数を直接呼び出すと、実行時エラーになるか、サーバー側のコードがまったく実行されなくなります。

R1同様、V3の出力ストリーミング速度は遅い。しかし、V3にはR1のような長大なブロックがないため、全体的な使用感はR1より若干良い。

クロード3.5ソネットのパフォーマンス

これに対し、クロード3.5のSonnetは、「低速リクエストモード」（例えば、月間のAPIリクエスト数が無料枠を超え、有料リクエストに入ると、リクエスト速度制限が発生することがある）であっても、最速である。Sonnetは、V3のように最新のReactの機能（useFormStatus）を推奨しておらず、クライアント側のコンポーネントからサーバー側の操作を直接呼び出すというV3と同様の間違いを犯しているが、実際に利用可能な答えに近い解決策を提示している。 Sonnetは、サーバー側の操作関数に「use server」ディレクティブを追加することを提案している。Sonnetは、サーバー側の操作関数に'use server'ディレクティブを追加することで、Next.jsの要件を満たすことができると提案しています。(知識補足：「サーバーを使う） は、Next.jsのバージョン13以降で導入された、サーバーサイドの操作として関数を明示的に宣言するための重要なディレクティブです。このディレクティブに サーバーを使用する そうすれば、Next.jsはその関数をサーバーサイドのコードとして正しく認識し、クライアントサイドのコンポーネントが安全に呼び出せるようになります。) 実際には、次のように加えるだけでいい。 サーバーを使用する ちなみに、ソネットのソリューションは本質的に問題を解決しており、DeepSeekモデルによるソリューションよりも実用的である。

コード生成モードの比較

ミッション・ステートメント

このテストセッションでは、フルスタックアプリケーションをデプロイするためのCircleCIプロファイルを提供します。このアプリケーションには、純粋なReactフロントエンドとNode.jsバックエンドが含まれています。オリジナルのデプロイプロセスには複数のステップが含まれています。私たちの目標は、次の両方を行うためにこの設定ファイルを変更することです：

• フロントエンドのデプロイメントに関連するすべてのコンフィギュレーションを削除する。
• アプリケーションはバックエンドだけであることを認識し、E2E テスト（エンドツーエンドテスト、通常、完全なユーザーフローをテストするために使用される）はもはや必要なく、関連する設定ステップは削除されます。 (知識の追加: E2E テストは、主に、ユーザの振る舞いをシミュレートし、フロントエンドとバックエンドのインタラクションの完全なフローを検証するために使用されます。アプリケーションがバックエンドのままでユーザーインターフェイスがない場合、E2Eテストは無意味です。一般的に使用される E2E テストフレームワークには、Cypress、Selenium などがあります)。

issueプロンプトに「フロントエンドのデプロイメントに関連するすべてのセクションを削除」し、完全なCircleCIコンフィギュレーションファイルをコンテキストとしてモデルに提供するよう明記しています。

DeepSeek R1の性能

文脈を理解し、複数の修正を必要とするタスク（コンポーザー・タスク）では、ブロックを使ったR1モデルの方が好成績を収めるだろうと予想していた。しかし、そうではなかった：

• R1では、明らかにフロントエンドのデプロイメントに関連するいくつかのコンフィギュレーションが省略されている。 (例えば、コンフィグファイルのウェブアプリのリファレンスの構築に関する部分はまだ保存されている）。しかし、信用できることに デプロイ-netlify (フロントエンドの静的リソースホスティングプラットフォームとしてよく使われるNetlifyプラットフォームにデプロイするステップ)このステップはもはや必要ないので、削除されました。
• 同時に、R1ではdeploy_production_apiというバックエンドのデプロイメント・ステップが誤って削除されている。その結果、バックエンド・サービスが正しく展開されない可能性がある。さらに、R1 検出不能 E2Eテストはもはや関係なく、関連するコンフィギュレーションを保持したままである。

DeepSeek V3の性能

DeepSeek V3 は、コード変更タスクで R1 よりもわずかにパフォーマンスが向上しています。V3 は、R1 が見逃していたフロントエンドのデプロイメント構成をいくつか修正していますが、新たな問題も露呈しています。たとえば、V3 はまだ deploy-netlify ステップが残っているため、タスクの要件を完全に理解していない可能性があります。例えば、V3はまだdeploy-netlifyステップを残しているが、これはタスクの要件を完全に理解していないことを示唆している。V3は信用できることに、バックエンドのデプロイメントステップをそのまま維持し、R1のようにバックエンドのデプロイメント設定を誤って削除することはなかった。しかし、R1同様、V3もE2Eテストセクションが削除される可能性があると判断できなかった。

クロード3.5ソネットのパフォーマンス

由緒あるクロード3.5のソネットは、このコード修正タスクで最高のパフォーマンスを発揮した：

• Sonnetはフロントエンドのデプロイに関連するコマンドのほとんどを削除することに成功した。しかし、V3と同様に deploy-netlify ステップの削除に失敗しました。.
• バックエンドのデプロイメント手順に関しても、ソネットはその完全性を維持している。いいえ、誤って削除したわけではありません。
• Sonnetは、バックエンド・サービスだけが残っているため、E2Eテストはもはや必要ないことを正確に認識していました。その結果、SonnetはCypress Binary Cache（Cypressテストの高速化に使用されるキャッシュ）を含む、すべてのE2Eテスト関連の構成を削除しました。その結果、Sonnetは、Cypress Binary Cache（Cypressテストの高速化に使用されるキャッシュ）を含む、すべてのE2Eテスト関連の構成を削除しました。(追加知識: Cypress Binary Cacheは、Cypressテストの実行に必要なバイナリをキャッシュするために使用され、後続のテストの起動を高速化できる。ただし、E2E テストを削除する場合は、冗長な構成を避けるため、このキャッシュ構成も削除する必要がある)。 このテストでは、これが最も優れたソリューションであり、Sonnetがタスクの意図を深く理解し、より包括的なコード変更を行う能力があることを示していた。

概要

Cursorプラットフォームは常に新しいAIモデルを導入しており、開発者に常に新しい選択肢と可能性をもたらしている。この比較テストのタスクは比較的単純なものでしたが、実際の開発シナリオにおいて、DeepSeek の両モデルの能力を最初に実証するには十分でした。クロード3.5ソネットと比較して、DeepSeekのモデルにはそれぞれ長所と短所があります。

総合すると、今回のテストでは、レスポンス速度と出力品質において、Claude 3.5 SonnetがDeepSeekの2モデルを明らかに上回っている。DeepSeekモデルのレスポンス速度は、サーバーの最適化やネットワークの分散などにより、今後のバージョンアップで改善される可能性はあるものの、これまでの実際のテスト結果を見る限り、実用性と信頼性の面でClaude 3.5 Sonnetがトップクラスであることに変わりはない。

全体として、このテストは、クロード3.5ソネットが今日のCursorプラットフォームにおいてより成熟し、信頼できる選択肢であることを示している。しかし、DeepSeekの新しいモデルもいくつかの可能性を示しており、開発者の継続的な注意と実験に値する。このモデルは、反復と改良を続けることで、将来的にはより優れた性能を発揮するようになるかもしれません。