以前のベンチマーク( で、 ]、私は、LLMはほとんどのLeetcodeの問題をうまく解決することができることを示しました。しかし、彼らは新しいものよりもよく知られている問題を解決するのに優れている。これは汚染されたトレーニングデータによって説明することができる - よく知られている問題の解決策はトレーニングデータに含まれる可能性があります(これはSWEベンチに関する最近のOpenAIのコメントによって部分的に確認されています。 ( ) ) 1 2 3 1 2 3 オリジナルのSWEベンチとSWEベンチ検証はPythonを使用しています。私はPythonも使用していますが、Go、C#、JavaScript、Bash、およびその他も時々使用しています。それで、私は自然に興味がありました:どのようにしてLLMの結果は言語によって異なりますか?私の仮定は、より一般的な言語でモデルがよりよく動作するということでした。 これらは、Finding from 現実世界のソフトウェアエンジニアリングタスクでは、非Python言語で同様のパフォーマンスの低下が観察されたが、現実世界の問題には、ツール、図書館、パイプラインなどの追加の複雑性が伴う。私は、クリーンな設定を使用してパターンを検証したかった。Leetcodeの問題は、ベースのアルゴリズムが主に言語アグノキシックであるため、言語自体を分離する。 SWEベンチ 多言語 SWEベンチ 多言語 ベンチマーク 私の以前のベンチマークと同様に、私は、アルゴリズムの問題を解決するためのLLMスキルを検証するために、Leetcodeオンライン審査員を使用しました。 言語 Leetcode は言語の統計を明示的に提供しませんが、ユーザーはソリューションを投稿し、プラットフォームはそれらの投稿されたソリューションの統計を提供します。 Language Published solutions, % C++ 26.21% Java 25.60% Python3 17.81% Python 7.99% JavaScript 6.68% C 6.45% Go 2.17% C# 2.12% TypeScript 1.44% Swift 0.86% Kotlin 0.74% Rust 0.65% Ruby 0.36% PHP 0.43% Dart 0.25% Scala 0.16% Elixir 0.05% Racket 0.03% C++ 26.21% Java 25.60% Python3 17.81% Python 7.99% ジャクソン 6.68% C 6.45% 行け 2.17% C# 2.12% TypeScript 1.44% スピード 0.86% コットン 0.74% Rust 0.65% ルビー 0.36% PHP 0.43% ダルト 0.25% スケール 0.16% Elixir 0.05% ラケット 0,03 % 私は4つの言語を選びました:JavaとPython3,最も人気のある2つとして。LeetcodeはPython 3と2を区別しています;それらの間には最小限の違いがあり、バージョン2のソリューションはほとんど常にバージョン3で動作します。その後、私はRustを選びました。 Leetcodeのこの4つの人気は、 正確には合わないけれど。 TIOBE index ティーブ・インデックス Language TIOBE Ratings, % Python 21.8 Java 8.12 Rust 1.32 Elixir 0.19 Python 21.8 Java 8.12 リラックス 1.32 エリックス 0.19 さらに、私はこの4つの公共のGitHub reposの数を調べてみました。 Language GitHub Repos, Millions Java 20.20 Python 26.50 Rust 1.00 Elixir 0.12 Java 20.20 Python 26.50 リラックス 1.00 エリックス 0.12 要するに、JavaとPython3は、数百万の公共プロジェクトを持つ最も一般的なプログラミング言語を表しており、私はLLMsがそれらを非常にうまく処理することを期待していました。Elixirはスケールの反対側にあり、コードのサイズが少なくなるので、LLMsの能力はそれとともに減少するかもしれません。Rustは真ん中にある - 明らかに人気がありますが、LLMsはそれをうまく処理できますか? 問題セット 私は2025年10月から2026年2月の間に発表された100の問題を選びました。 Easy Medium Hard Total 15 59 26 100 15 59 26 100 意図は、最近の問題、おそらくLLMsによって「目に見えない」を得ることにあり、古い、とりわけ一般的な問題の解決策は、モデルのトレーニングセットに入ることは知られています。 モデル ベンチマークで使用されるモデルは、すべての非デフォルトパラメータが指定され、以下の表に記載されています。 Vendor Model Release date Knowledge cutoff date "Reasoning" Parameters Anthropic claude-sonnet-4-5-20250929 Sep 2025 Jul 2025 No temperature = 0.0 max_tokens = 4096 Google gemini-3-flash-preview Dec 2025 unknown Yes temperature = 0.0 gemini-2.5-flash Apr 2025 unknown Yes temperature = 0.0 xAI grok-code-fast-1-0825 Aug 2025 unknown Yes seed = 42 OpenAI gpt-5-mini Aug 2025 May 2024 Yes seed = 42 Anthropic クローデ・ソネット4-5-20250929 セブ 2025 クリスマス2025 ノー 温度 = 0.0 マックス=トークン=4096 Google Gemini-3 フラッシュプレビュー DEC2025 未知 はい 温度 = 0.0 GEMINI-2.5 フラッシュ APR 2025年 未知 はい 温度 = 0.0 xAI グロック・コード・ファスト-1-0825 アグ2025 未知 はい シンボル = 42 OpenAI GPS5ミニ アグ2025 2024年5月 はい シンボル = 42 Gemini 3 Flash (Preview) を除くすべてのモデルは、データセットで最も古い問題(2025年10月)よりも早くリリースされました。 ベンチマークは、可能な限り決定的で再現可能であることを目指し、したがって、「温度」や「種子」などのパラメータが使用されました。 すべてのモデルは、Claude Sonnet 4.5 を除いて、デフォルトで「推論」または「考える」モードをサポートしています。 結果 問題は、オンライン判事によって解決が受け入れられた場合に「受け入れられた」または「解決された」とみなされます。「間違った答え」や「時間制限を超えた」などの他のすべての結果は、単に「差別なしに受け入れられない」とみなされます。 Model python3 java 𝝙 python3 rust 𝝙 python3 elixir 𝝙 python3 claude-sonnet-4-5-20250929 50% 52% +2 51% +1 35% -15 gemini-2.5-flash 82% 82% +0 77% -5 39% -43 gemini-3-flash-preview 84% 93% +9 78% -6 83% -1 gpt-5-mini 93% 94% +1 80% -13 63% -30 grok-code-fast-1-0825 73% 65% -8 65% -8 30% -43 claude-sonnet-4-5-20250929 50% 52% +2 +2 51% +1 +1 35% -15 -15 gemini-2.5-flash 82% 82% +0 +0 77% -5 -5 39% -43 -43 gemini-3-flash-preview 84% 93% +9 +9 78% -6 -6 83% -1 -1 gpt-5-mini 93% 94パーセント +1 +1 80パーセント -13 -13 63% -30 -30 grok-code-fast-1-0825 73% 65% -8 -8 65% -8 -8 30% -43 結果は、ほとんどのモデルでElixirの明確な低下を示していますが、これらの違いは統計的に有意義ですか? 言語間のパスレートの違いが統計的に有意であるかどうかを評価するために、私は2つの比率のzテストを使用しました。N=100の問題にそれぞれテストされた2つの言語では、p=0.05の最小検出可能な違いは1.96×√(2p̄(1-p̄)/Nで示されています。 Python をベースラインとして取ると、Python-Java と Python-Rust のギャップはすべてのモデルでは重要でない(値は ~11.7pp と ~12.3pp です)。 しかし、Python-Elixirの格差は、Gemini 3 Flash Previewを除くすべてのモデルで ~13.4ppの値を大幅に超え、Elixirを大幅に劣化させることを示しています。 データベース問題 興味深いことに、このパターンはSQLにも当てはまります. I had a collection of 321 Leetcode database problems, published from 2015 to 2025. Easy Medium Hard Total 114 142 65 321 114 142 65 321 私はアルゴリズムベンチマークと同じ5つのLLMを使用しましたが、MySQLとOracle SQLの2つの言語のみです。 Oracle SQL では、Leetcode で公開されたソリューションが MySQL より 15 倍少なくなっています TIOBE と GitHub は、実際にはプログラミング言語ではありませんので、これらの言語の統計を提供していません。 ほとんどの問題がモデルの知識切断の日付を前にしているので、汚染は可能であり、これらの結果を解釈する際に考慮すべきである。 Model MySQL Oracle SQL 𝝙 claude-sonnet-4-5-20250929 87.5% 76.3% -11.2 gemini-2.5-flash 86.6% 67.9% -18.7 gemini-3-flash-preview 95.6% 85.7% -9.9 gpt-5-mini 89.1% 79.4% -9.7 grok-code-fast-1-0825 80.4% 66.7% -13.7 claude-sonnet-4-5-20250929 87% 76.3% -11.2 gemini-2.5-flash 86.6 % 67.9% -18.7 gemini-3-flash-preview 95.6 % 85.7% -9.9 gpt-5-mini 89.1 % 79.4% -9.7 grok-code-fast-1-0825 80.4 % 66.7% -13.7 N=321の問題と平均パスレートが約82%の場合、重要性の限界は約6パーセントポイントです。 つまり、すべてのテストされたモデルが MySQL に対する承認率を大幅に高めていることを意味します。 結論 私たちは、コードの問題に関するLLMのパフォーマンスが言語の普及と相関していることを見ることができます。これは特に驚くべきことです:アルゴリズムの問題は、主に言語アグノキティックなので、基礎的な論理が言語を介して転送されることを期待できます。 最も広く使われている言語であるPythonとJavaで、モデルはニッチ言語であるElixirを上回ります. 同じ傾向はSQLの問題で、LLMはOracle SQLよりもMySQLでよりよく動作します。 最も確実な説明は、トレーニングデータ密度である:より一般的な言語はより多くのコード例を生成し、モデルから学ぶべき素材を増やす。 実用的な意味は単純である:あなたがプログラミングの助けを求めるためにLLMに頼るなら、あなたの言語選択は重要です - 潜在的にあなたのモデル選択と同じくらいです. 珍しい言語で働くことは、AIのサポートが大幅に弱いことを意味しますが、Gemini 3 Flash Previewは顕著な例外ですが、アルゴリズムの問題のためにテストされたすべての言語でほぼ一致した結果を示します。 Rustは、より少ない公共のリポジトリとリリースされたLeetcodeソリューションを持っているにもかかわらず、統計的に重要な違いを示さなかった。 いくつかの方向は探求する価値があるでしょう。第一に、問題セットを拡張することは、Rustの発見を確認または排除することを可能にします。第二に、Scala、Dart、またはRacketなどの追加言語をテストすることは、人気とパフォーマンスの関係をより正確に確立するのに役立ちます。 左利き このベンチマークに使用されるデータセット: https://huggingface.co/datasets/whiskwhite/leetcode-complete https://huggingface.co/datasets/whiskwhite/leetcode-complete ソリューションを提示し提出するためのツール: Tools used for prompting and submitting solutions: https://github.com/whisk/leetgptsolver https://github.com/whisk/leetgptsolver
