ใน benchmarks ของฉันก่อนหน้านี้ [ , ], ฉันแสดงให้เห็นว่า LLMs สามารถแก้ปัญหา Leetcode ส่วนใหญ่ได้อย่างประสบความสําเร็จ อย่างไรก็ตามพวกเขาจะดีกว่าในการแก้ปัญหาที่รู้จักกันดีกว่าปัญหาใหม่ สิ่งนี้สามารถอธิบายได้โดยข้อมูลการฝึกอบรมที่ติดเชื้อ - โซลูชั่นสําหรับปัญหาที่รู้จักกันดีอาจรวมอยู่ในข้อมูลการฝึกอบรม (สิ่งนี้ได้รับการยืนยันบางส่วนโดยความคิดเห็นล่าสุดของ OpenAI เกี่ยวกับ SWE Bench [ ] ) 1 2 3 1 2 3 SWE Bench และ SWE Bench Verified ใช้ Python ฉันยังใช้ Python แต่ยังใช้ Go, C#, JavaScript, Bash และอื่น ๆ บางครั้ง ดังนั้นฉันก็สนใจ: ผลลัพธ์ของ LLM จะแตกต่างกันอย่างไรระหว่างภาษา? การคาดการณ์ของฉันคือรูปแบบทํางานได้ดีขึ้นกับภาษาที่ได้รับความนิยมมากขึ้นเนื่องจากปริมาณที่ใหญ่กว่าของรหัสที่สามารถใช้ได้โดยสาธารณะ การคาดการณ์นี้กลายเป็นที่ถูกต้อง นี้สอดคล้องกับผลการค้นพบจาก , ซึ่งสังเกตเห็นการลดประสิทธิภาพที่คล้ายกันในภาษาที่ไม่ใช่ Python ในงานวิศวกรรมซอฟต์แวร์ในโลกจริง อย่างไรก็ตามปัญหาในโลกจริงเกี่ยวข้องกับความซับซ้อนเพิ่มเติม - เครื่องมือห้องสมุดท่อ ฯลฯ ฉันต้องการตรวจสอบรูปแบบโดยใช้การตั้งค่าที่สะอาดขึ้น ปัญหา Leetcode จะแยกภาษาตัวเองเนื่องจากอัลกอริทึมพื้นฐานส่วนใหญ่เป็นภาษาที่ไม่ซับซ้อน นี่คือสิ่งที่ทําให้การค้นพบที่น่าประหลาดใจยิ่งขึ้น: แม้ว่ากลยุทธ์จะไม่เปลี่ยนแปลงภาษาที่คุณเขียนมันยังคงมีผลต่อว่ารุ่นจะถูกต้องหรือไม่ SWE-bench Multilingual SWE-bench หลายภาษา benchmark ในฐานะที่เป็นอ้างอิงก่อนหน้านี้ของฉันฉันใช้ Leetcode ออนไลน์การตัดสินเพื่อตรวจสอบทักษะ LLM ในการแก้ปัญหาอัลกอริทึม แต่ครั้งนี้ฉันทดลองกับสี่ภาษาที่แตกต่างกันที่มีระดับความนิยมที่แตกต่างกัน ภาษา มีประมาณ 20 ภาษาที่สนับสนุนโดย Leetcode สําหรับปัญหาอัลกอริทึมในขณะที่เขียน 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% แพทช์ 7.99% ภาษาไทย 6.68% C 6.45% ไป 2.17% C# 2.12% ภาษาไทย 1.44% สวิตช์ 0.86% ตุ๊กตา 0.74% Rust 0.65% รูเบี้ยน 0.36% ฟิล์ม 0.43% ดาร์ต 0.25% ตาราง 0.16% Elixir 0.05% แร็คเก็ต 0.03% ของ ฉันเลือกสี่ภาษา: Java และ Python3 เป็นสองภาษาที่ได้รับความนิยมมากที่สุด Leetcode ทําความแตกต่างระหว่าง Python 3 และ 2 มีความแตกต่างเล็กน้อยระหว่างพวกเขาและโซลูชั่นสําหรับรุ่น 2 จะทํางานเกือบเสมอสําหรับรุ่น 3 จากนั้นฉันเลือก Rust ซึ่งมีโซลูชั่นที่ตีพิมพ์น้อยกว่า 50 ครั้ง แต่ความนิยมของมันเติบโตอย่างรวดเร็วในชุมชนวิศวกรรมทําให้เป็นกรณีที่น่าสนใจ และในที่สุด Elixir เป็นภาษานิชที่มีโซลูชั่นเพียงไม่กี่ ความนิยมของสี่คนเหล่านี้ใน Leetcode มีความสัมพันธ์กับ แม้ว่ามันไม่สอดคล้องได้อย่างถูกต้อง อัตราส่วน TIOBE อัตราส่วน TIOBE Language TIOBE Ratings, % Python 21.8 Java 8.12 Rust 1.32 Elixir 0.19 แพทช์ 21.8 ภาษาไทย 8.12 การพักผ่อน 1.32 อิลิเคชัน 0.19 นอกจากนี้ฉันได้ดูจํานวน GitHub repos สาธารณะสําหรับสี่คนเหล่านี้: Language GitHub Repos, Millions Java 20.20 Python 26.50 Rust 1.00 Elixir 0.12 ภาษาไทย 20.20 แพทช์ 26.50 การพักผ่อน 1.00 อิลิเคชัน 0.12 ในระยะสั้น Java และ Python3 เป็นภาษาการเขียนโปรแกรมที่พบบ่อยที่สุดที่มีล้านโครงการสาธารณะและฉันคาดหวังว่า LLMs จะจัดการกับพวกเขาได้ดีมาก Elixir อยู่ทางด้านตรงข้ามของสแควร์ด้วยรหัสที่มีขนาดเล็กน้อยดังนั้นความสามารถของ LLMs อาจลดลงพร้อมกับมัน Rust นี่คือบางส่วนในกลาง - อย่างชัดเจนเป็นที่นิยม แต่ LLMs สามารถจัดการได้ดีหรือไม่ ปัญหาชุด ฉันเลือก 100 ปัญหาที่เผยแพร่ระหว่างเดือนตุลาคม 2025 และเดือนกุมภาพันธ์ 2026 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 กุมภาพันธ์ 2560 คริสต์มาส 2025 ไม่ อุณหภูมิ = 0.0 max_tokens = 4096 Google gemini-3-flash-preview พฤศจิกายน 2560 ไม่รู้จัก ใช่ อุณหภูมิ = 0.0 gemini-2.5-แฟลช พฤศจิกายน 2560 ไม่รู้จัก ใช่ อุณหภูมิ = 0.0 xAI โฮมเมด-code-fast-1-0825 สิงหาคม 2025 ไม่รู้จัก ใช่ เมล็ด = 42 OpenAI gpt-5-มินิ สิงหาคม 2025 พฤษภาคม 2024 ใช่ เมล็ด = 42 รุ่นทั้งหมดยกเว้น Gemini 3 Flash (Preview) ได้รับการเปิดตัวก่อนปัญหาที่เก่าแก่ที่สุดในชุดข้อมูล (Oct 2025) วัตถุประสงค์ของ benchmark คือการทําความเข้าใจและทําซ้ําได้มากที่สุดเท่าที่เป็นไปได้ ดังนั้นจึงใช้พารามิเตอร์เช่น "อุณหภูมิ" หรือ "เมล็ด" อย่างไรก็ตามไม่มีรุ่นที่ผ่านการทดสอบที่รับประกันผลลัพธ์ที่ทําซ้ําอย่างสมบูรณ์ สิ่งนี้ควรพิจารณาเมื่อทําซ้ําผลลัพธ์เหล่านี้ รูปแบบทั้งหมดรองรับโหมด "เหตุผล" หรือ "คิด" โดยค่าเริ่มต้นยกเว้น 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 ในรูปแบบส่วนใหญ่ แต่ความแตกต่างเหล่านี้มีความหมายทางสถิติหรือไม่ เพื่อประเมินว่าความแตกต่างในอัตราการผ่านระหว่างภาษามีความสําคัญทางสถิติฉันใช้การทดสอบ z สองสัดส่วน สําหรับสองภาษาที่ทดสอบแต่ละภาษากับปัญหา N = 100 ความแตกต่างขั้นต่ําที่สามารถตรวจจับได้ใน p=0.05 คือ 1.96 ×√(2p̄(1-p̄)/N ซึ่ง p̄ เป็นอัตราการยอมรับเฉลี่ยระหว่างสองภาษา การใช้ Python เป็นขั้นพื้นฐานข้อบกพร่องของ Python-Java และ Python-Rust ไม่สําคัญสําหรับทุกรุ่น (ข้อบกพร่อง ~11.7pp และ ~12.3pp ตามลําดับ) ความแตกต่างของ Python-Elixir อย่างไรก็ตามเกินขีด จํากัด ของ ~13.4pp สําหรับรุ่นทั้งหมดยกเว้น Gemini 3 Flash Preview ซึ่งแสดงให้เห็นว่าพวกเขาจัดการกับ Elixir มากแย่ลง ปัญหาฐานข้อมูล มีความน่าสนใจว่ารูปแบบนี้ใช้กับ SQL เช่นกัน ฉันมีคอลเลกชันของปัญหาฐานข้อมูล Leetcode 321 ที่เผยแพร่ตั้งแต่ 2015 ถึง 2025 Easy Medium Hard Total 114 142 65 321 114 142 65 321 ฉันใช้ทั้งห้า LLMs เท่านั้นเช่นเดียวกับในอัลกอริทึมอ้างอิง แต่สําหรับเพียงสองภาษา: MySQL และ Oracle SQL แม้ว่าการประยุกต์ใช้ทั้งสองส่วนใหญ่สามารถเปลี่ยนได้ แต่มีความแตกต่างเล็กน้อย สําหรับ Oracle SQL มีโซลูชั่นที่เผยแพร่ใน Leetcode น้อยกว่า 15 เท่ากว่าสําหรับ MySQL 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.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 ด้วยปัญหา N = 321 และอัตราการผ่านเฉลี่ยประมาณ 82%, ขอบเขตความสําคัญคือประมาณ 6 จุดเปอร์เซ็นต์ ซึ่งหมายความว่าทุกรุ่นที่ผ่านการทดสอบแสดงอัตราการยอมรับที่สูงขึ้นอย่างมีนัยสําคัญสําหรับ MySQL ข้อสรุป เราสามารถเห็นว่าประสิทธิภาพของ LLM เกี่ยวกับปัญหาการเขียนโค้ดเกี่ยวข้องกับความนิยมของภาษา นี่เป็นเรื่องที่น่าประหลาดใจโดยเฉพาะอย่างยิ่ง: ปัญหาอัลกอริทึมส่วนใหญ่เป็นภาษาที่ไม่ได้ใช้งานดังนั้นจึงสามารถคาดหวังว่าโลจิกพื้นฐานจะถูกถ่ายโอนไปทั่วภาษา อย่างไรก็ตามข้อมูลแสดงให้เห็นว่าแตกต่างกัน - ภาษาที่คุณเขียนในเรื่องแม้ว่าอัลกอริทึมเองจะไม่เปลี่ยนแปลง ด้วย Python และ Java, ภาษาที่ใช้กันอย่างแพร่หลายมากที่สุด, รูปแบบเอาชนะ Elixir, ภาษานิช. แนวโน้มเดียวกันถือสําหรับปัญหา SQL, ที่ LLMs ทํางานได้ดีขึ้นใน MySQL มากกว่าใน Oracle SQL. คําอธิบายที่พึงประสงค์ที่สุดคือความหนาแน่นของข้อมูลการฝึกอบรม: ภาษาที่ได้รับความนิยมมากขึ้นสร้างตัวอย่างโค้ดมากขึ้นให้โมเดลวัสดุมากขึ้นที่จะเรียนรู้จาก ผลกระทบทางปฏิบัติเป็นเรื่องง่าย: หากคุณพึ่งพา LLMs สําหรับการสนับสนุนการเข้ารหัสการเลือกภาษาของคุณมีความสําคัญ – อาจเป็นเช่นเดียวกับตัวเลือกรูปแบบของคุณ การทํางานกับภาษาที่ไม่พึงประสงค์หมายถึงการยอมรับการสนับสนุน AI ที่อ่อนแออย่างมีนัยสําคัญแม้ว่า Gemini 3 Flash Preview เป็นข้อยกเว้นที่โดดเด่นซึ่งแสดงผลเกือบสม่ําเสมอในทุกภาษาที่ทดสอบสําหรับปัญหาอัลกอริทึม อย่างไรก็ตามมันไม่ชัดเจนว่าความนิยมจริงคืออะไร Rust แม้จะมีพื้นที่เก็บข้อมูลสาธารณะน้อยกว่าและโซลูชั่น Leetcode ที่เผยแพร่ไม่ได้แสดงให้เห็นถึงความแตกต่างที่สําคัญทางสถิติ หลายทิศทางจะคุ้มค่าที่จะสํารวจ ประการแรกการขยายชุดปัญหาจะช่วยให้การค้นพบ Rust ได้รับการยืนยันหรือยกเว้น ประการที่สองการทดสอบภาษาเพิ่มเติมเช่น Scala, Dart หรือ Racket จะช่วยสร้างความสัมพันธ์ความนิยมกับประสิทธิภาพได้อย่างแม่นยํามากขึ้น และในขณะที่ LLMs ยังคงพัฒนามันจะคุ้มค่าที่จะติดตามว่าช่องว่างสําหรับภาษานิชจะแคบลงในช่วงเวลา ด้านซ้าย ชุดข้อมูลที่ใช้สําหรับ benchmark นี้: https://huggingface.co/datasets/whiskwhite/leetcode-complete https://huggingface.co/datasets/whiskwhite/leetcode-complete เครื่องมือที่ใช้ในการแนะนําและส่งเสนอโซลูชั่น: https://github.com/whisk/leetgptsolver https://github.com/whisk/leetgptsolver
