W poprzednich wersjach [ , ], pokazałem, że LLM mogą pomyślnie rozwiązać większość problemów Leetcode. jednak, są one lepsze w rozwiązywaniu znanych problemów niż nowych. To może być wyjaśnione przez zanieczyszczone dane szkoleniowe - rozwiązania znanych problemów są prawdopodobnie uwzględnione w danych szkoleniowych (to jest częściowo potwierdzone przez ostatnie komentarze OpenAI dotyczące SWE Bench [ ] ) 1 2 3 1 2 3 Oryginalny SWE Bench i SWE Bench Verified używają Pythona. Używam również Pythona, ale dodatkowo Go, C#, JavaScript, Bash i innych od czasu do czasu. Więc naturalnie byłem zainteresowany: jak wyniki LLM różnią się w różnych językach? Jest to zgodne z ustaleniami z , który zaobserwował podobne spadki wydajności w językach innych niż Python w rzeczywistych zadaniach inżynierii oprogramowania. Jednak problemy w świecie rzeczywistym wiążą się z dodatkową złożonością – narzędziami, bibliotekami, rurociągami itp. Chciałem zweryfikować wzorzec, używając czystszej konfiguracji. Problemy Leetcode izolują sam język, ponieważ podstawowe algorytmy są w dużej mierze językowo-agnostyczne. To sprawia, że odkrycie jest bardziej zaskakujące: nawet gdy logika się nie zmienia, język, w którym go piszesz, nadal wpływa na to, czy model go poprawnie. SWE-bench wielojęzyczny SWE-bench wielojęzyczny Benchmark Podobnie jak w moich poprzednich referencjach, użyłem online sędziego Leetcode, aby zweryfikować umiejętności LLM w rozwiązywaniu problemów algorytmicznych. Języki Istnieje około 20 języków obsługiwanych przez Leetcode dla problemów algorytmicznych w momencie pisania. Leetcode nie dostarcza statystyk językowych wyraźnie, ale użytkownicy publikują swoje rozwiązania, a platforma zapewnia statystyki dla tych opublikowanych rozwiązań. 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 proc. Java 25.60% Python3 17.81% Pythona 7,99 proc. - JavaScript 6,68 proc. C 6,45 proc. Idź 2,17 proc. C# 2.12 procent typografii 1,44 proc. Szybkie 0,86 proc. Kotlin 0,74 proc. Rust 0.65% Ruby 0,36 proc. PHP 0,43 proc. Dart 0,25 proc. Scala 0,16 proc. Elixir 0.05% Rakieta 0,03 proc. Leetcode wyróżnia Python 3 i 2; istnieją minimalne różnice między nimi, a rozwiązania dla wersji 2 prawie zawsze będą działać dla wersji 3. Następnie wybrałem Rust, który ma 50 razy mniej opublikowanych rozwiązań, ale jego popularność szybko rośnie wśród społeczności inżynieryjnej, co czyni go ciekawym przypadkiem. Popularność tych czterech na Leetcode koreluje z Nawet jeśli nie pasuje dokładnie. Wskaźnik TIOBE Wskaźnik TIOBE Language TIOBE Ratings, % Python 21.8 Java 8.12 Rust 1.32 Elixir 0.19 Pythona 21.8 Java 8.12 Spokój 1.32 Elixir 0.19 Ponadto spojrzałem na liczbę publicznych reposów GitHub dla tych czterech: Language GitHub Repos, Millions Java 20.20 Python 26.50 Rust 1.00 Elixir 0.12 Java 20.20 Pythona 26.50 Spokój 1.00 Elixir 0.12 Krótko mówiąc, Java i Python3 reprezentują najczęstsze języki programowania z milionami projektów publicznych i spodziewałem się, że LLM poradzą sobie z nimi bardzo dobrze. Elixir jest po przeciwnej stronie skali, z kolejnościami wielkości mniej dostępnego kodu, więc zdolności LLM mogą się z tym zmniejszyć. Problem set Wybrałem 100 problemów, opublikowanych między październikiem 2025 a lutym 2026 roku. Easy Medium Hard Total 15 59 26 100 15 59 26 100 Celem było uzyskanie ostatnich problemów, prawdopodobnie "niewidzianych" przez LLM. Wiadomo, że rozwiązania dla starszych, a zwłaszcza popularnych problemów, dostają się do zestawów szkoleniowych modeli. Modele Modele wykorzystywane w wskaźniku referencyjnym są wymienione w poniższej tabeli, ze wskazanymi wszystkimi parametrami innych niż domyślne. 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 kłódka-sonnet-4-5-20250929 Wrzesień 2025 Boże Narodzenie 2025 Nie Temperatura powietrza = 0,0 max_tokens = 4096 zł Google gemini-3-flash wstęp Dec 2025 r. Nieznany tak Temperatura powietrza = 0,0 Płyta Gemini-2.5 Apr 2025 r. Nieznany tak Temperatura powietrza = 0,0 xAI grok-code-fast 1 0825 Aug 2025 Nieznany tak Złoty = 42 OpenAI GPS5 Mini Aug 2025 Maj 2024 tak Złoty = 42 Wszystkie modele, z wyjątkiem Gemini 3 Flash (Preview), zostały wydane wcześniej niż najstarszy problem w zbiorze danych (Okt 2025). Wskaźnik referencyjny miał być jak najbardziej deterministyczny i możliwy do odtworzenia, dlatego zastosowano parametry takie jak „temperatura” lub „siemienie”. Wszystkie modele obsługują domyślnie tryby „rozumienia” lub „myślenia”, z wyjątkiem Claude Sonnet 4.5. Wyniki Problem jest uważany za „akceptowany” lub „rozwiązany”, jeśli rozwiązanie zostało zaakceptowane przez sędziego online. Wszystkie inne wyniki, takie jak „zła odpowiedź” lub „przekroczenie limitu czasu”, są po prostu „nieakceptowane” bez jakiejkolwiek różnicowania. 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 proc. +2 +2 51 proc. +1 +1 35% -15 -15 gemini-2.5-flash 82 proc. 82 proc. +0 +0 77 proc. -5 -5 39 proc. -43 -43 gemini-3-flash-preview 84 proc. 93 proc. +9 +9 78 proc. -6 -6 83 proc. -1 -1 gpt-5-mini 93 proc. 94 proc. +1 +1 80 proc. -13 -13 63 proc. -30 -30 grok-code-fast-1-0825 73 proc. 65 proc. -8 -8 65 proc. -8 -8 30 % -43 Wyniki pokazują wyraźny spadek dla Elixir w większości modeli. ale czy te różnice są statystycznie znaczące? Aby ocenić, czy różnice w przepustowości między językami są statystycznie istotne, użyłem testu z o dwóch proporcjach. Dla dwóch języków testowanych na problemach N=100, minimalna wykrywalna różnica w p=0.05 jest podana przez 1,96×√(2p̄(1-p̄)/N, gdzie p̄ jest średnią stopą akceptacji między dwoma językami. Biorąc Python jako podstawę, luky Python-Java i Python-Rust są nieistotne dla wszystkich modeli (próg ~11.7pp i ~12.3pp, odpowiednio). Jednak różnica Python-Elixir znacznie przekracza próg ~13,4pp dla wszystkich modeli z wyjątkiem Gemini 3 Flash Preview, co wskazuje, że obsługują Elixir znacznie gorzej. Problemy z bazą danych Miałem zbiór 321 problemów z bazą danych Leetcode, opublikowanych w latach 2015-2025. Easy Medium Hard Total 114 142 65 321 114 142 65 321 Użyłem tych samych pięciu LLM jak w algorytmicznym benchmark, ale tylko dla dwóch języków: MySQL i Oracle SQL. Dla Oracle SQL, istnieje 15 razy mniej opublikowanych rozwiązań na Leetcode niż dla MySQL. TIOBE i GitHub nie dostarczają żadnych statystyk dla tych języków - ponieważ są one, w rzeczywistości, nie języki programowania. Biorąc pod uwagę, że większość problemów wyprzedza datę wyczerpania wiedzy modeli, zanieczyszczenie jest możliwe i powinno być brane pod uwagę przy interpretacji tych wyników. 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,5 proc. 76,3 proc. -11.2 gemini-2.5-flash 86,6 proc. 67,9 proc. -18.7 gemini-3-flash-preview 95,6 proc. 85,7 proc. -9.9 gpt-5-mini 89.1 proc. 79,4 proc. -9.7 grok-code-fast-1-0825 80.4 proc. 66,7 proc. -13.7 W przypadku problemów N = 321 i średnich wskaźników przejścia około 82%, próg znaczenia wynosi około 6 punktów procentowych. Oznacza to, że każdy przetestowany model wykazuje znacznie wyższy wskaźnik akceptacji dla MySQL. konkluzji Możemy zobaczyć, że wydajność LLM w problemach z kodowaniem koreluje z popularnością języka.To jest szczególnie zaskakujące: problemy algorytmiczne są w dużej mierze językowo-agnostyczne, więc można się spodziewać, że podstawowa logika zostanie przeniesiona na różne języki. W przypadku Pythona i Java, najczęściej używanych języków, modele przewyższają Elixir, język niszy. Ta sama tendencja dotyczy problemów SQL, gdzie LLM działa lepiej w MySQL niż w Oracle SQL. Najbardziej prawdopodobnym wyjaśnieniem jest gęstość danych szkoleniowych: bardziej popularne języki generują więcej przykładów kodu, dając modelom więcej materiału do nauki. Praktyczne implikacje są proste: jeśli opierasz się na LLM do pomocy w kodowaniu, Twój wybór języka ma znaczenie – potencjalnie tak samo jak wybór modelu. Praca z rzadkimi językami oznacza akceptację znacząco słabszego wsparcia AI, chociaż Gemini 3 Flash Preview jest zauważalnym wyjątkiem, pokazując niemal jednolite wyniki we wszystkich testowanych językach dla problemów algorytmicznych. Rust, mimo że ma znacznie mniej publicznych repozytoriów i opublikowanych rozwiązań Leetcode, nie wykazał żadnej statystycznie istotnej różnicy. Kilka kierunków byłoby warte odkrycia. Po pierwsze, rozszerzenie zestawu problemów pozwoliłoby potwierdzić lub wykluczyć wyniki Rust. Po drugie, testowanie dodatkowych języków, takich jak Scala, Dart lub Racket, pomogłoby precyzyjniej ustalić stosunek popularności do wydajności. Lewica Zestaw danych wykorzystywany do tego benchmarku: https://huggingface.co/datasets/whiskwhite/leetcode-complete https://huggingface.co/datasets/whiskwhite/leetcode-complete Narzędzie wykorzystywane do wzywania i dostarczania rozwiązań: https://github.com/whisk/leetgptsolver https://github.com/whisk/leetgptsolver
