私は10個の小さなSolidityコントラクトに対してローカルモデルのテストを行いました。そこには以下のようなバグを仕込んでいます：

  • withdraw関数におけるリエントランシー
  • アクセス修飾子の欠如
  • ERC4626の丸め誤差
  • 不備のある署名チェック
  • 微妙なロジックのバグ

WSL2上のOllamaを使用して、7Bモデル（またはそれ以下）のQwen2.5-CoderとDeepSeek-Coderを比較しました。33Bモデルを使用している場合は、この話は無視してください。

各コントラクトに対して、3つのプロンプトを出しました：

  • 全般的なセキュリティレビュー
  • リエントランシーとアクセス制御に特化したチェック
  • 重要度タグ付きの構造化レポート

指示への追従性

ここではQwen 7Bが勝利しています。Qwenはほぼ毎回、厳格なフォーマット規則に従います。DeepSeekは余計なテキストを追加したり、制限を無視したりすることがよくあります。モデルの出力を自動化パイプラインに投入する場合、Qwenの一貫性は非常に重要です。パースエラー（解析失敗）が起きるモデルは役に立ちません。

ターゲットを絞ったチェック

Qwenはトピックから逸れません。リエントランシーについて尋ねれば、リエントランシーについて回答します。DeepSeekはガス最適化やスタイルの指摘へと話が逸れ、ノイズが混じります。

説明の質

Qwenは攻撃シーケンスを明確に説明し、エクスプロイトがどのように展開されるかを示してくれます。DeepSeekは教科書的な一般的な回答にとどまります。どちらも正しいのですが、レポート作成にはQwenの詳細さの方が役立ちます。

懐疑心とハルシネーション

DeepSeekはより多くの問題をフラグ立てし、「疑い生成器」のように振る舞います。また、クリーンなコードに対しても問題を捏造することがあります。

対照的に、Qwenはコードにバグがない場合は沈黙を守ります。一方でDeepSeekは、存在しないバグを主張します。

誤検知は数分のロスで済みますが、バグの見逃しはすべてを失うことにつながりかねません。私は、調査すべき事項を洗い出すためにDeepSeekを使い、自動化にはQwenを頼りにしています。

私の最終的な結論

ブランドよりもモデルのサイズが重要です。1.5Bモデルでは、多段階のバグを推論したり、フォーマットを維持したりすることはできません。

7Bクラスであれば、どちらも基本的な欠陥は処理できますが、どちらも複雑なビジネスロジックにおいて人間の監査者に取って代わるものではありません。彼らは監査者ではなく、トリアージ・アシスタントだと考えるべきです。

私のセットアップ:

  • Qwen 7B: 構造化されたレビューとパイプライン用のデフォルト。
  • DeepSeek: Qwenが見逃したものを捕まえるためのセカンドオピニオン。
  • Qwen 1.5B: 高速で、重要度の低いフィルタリングのみに使用。

ハードウェアが実行できる最大のモデルを購入してください。ブランドについてはその後に考えればよいのです。

あなたは、疑い深いモデルと、正確なモデルのどちらを好みますか？

Source: https://dev.to/pavelespitia/qwen25-coder-vs-deepseek-coder-for-solidity-review-what-i-actually-see-locally-4jh8

Optional learning community: https://t.me/GyaanSetuAi