آزمایش LLM در حل مسائل Leetcode در سال 2025

یک سال پیش، معیار من نشان داد که مدل‌های زبان بزرگ (LLM) می‌توانند چالش‌های کدگذاری الگوریتمی در Leetcode را حل کنند. با این حال، توانایی آنها به زیر مجموعه ای از مشکلات شناخته شده و "محبوب" محدود می شد. مشکلات جدید، که هرگز بخشی از مجموعه داده های آموزشی آنها نبود، مشکلاتی را به همراه داشت. در حالی که ساده ترین ها عمدتا توسط مدل ها حل می شد، سخت ترین ها دست نیافتنی باقی ماندند.

از آن زمان، Open AI، Anthropic و Google نسخه‌های پیشرفته‌تری از مدل‌های خود منتشر کردند و بازیکنان جدیدی مانند Deepseek و xAI ظاهر شدند. اکنون بسیاری از مدل ها به عنوان قابلیت نوشتن کد به بازار عرضه می شوند که قبلاً چنین نبود. من قصد دارم این LLM های پیشرفته را محک بزنم تا بفهمم آیا توانایی آنها در حل مسائل الگوریتمی جدید بهبود یافته است یا خیر.

انگیزه

معیارهای موجود برای LLM ها برای ارزیابی توانایی های کدنویسی آنها وجود دارد.

SWE-نیمکت بر حل مشکلات نرم افزاری واقعی متمرکز شده است - بر اساس مسائل Github پروژه های منبع باز موجود است. این در واقع یک ایده درخشان است، اما علاوه بر حل مسئله الگوریتمی واقعی که من روی آن تمرکز کرده بودم، چیزهای زیادی را پوشش می دهد.

نیروهای کد معیارها مهارت های حل مسئله الگوریتمی LLM را بهتر منعکس می کنند. OpenAI مدل های o1 و o3 را روی مشکلات Codeforces آزمایش کرد و نتایج دقیق را به اشتراک گذاشت ( 1 ، 2 ) در حالی که سایر رقبا این کار را نکردند. که مقایسه مستقیم را غیرممکن کرد.

این منجر به ایجاد یک معیار جدید شد که امکان مقایسه مستقیم LLM ها را فراهم کرد. و پس از همه، چرا این کار را فقط برای سرگرمی انجام ندهیم؟

طراحی معیار

ایده این است که در هنگام حل مسائل الگوریتمی از اعمال انسان تقلید کنیم اما از یک LLM برای نوشتن کد استفاده کنیم:

1. توضیحات مشکل را دانلود کنید.
2. یک درخواست از توضیحات ایجاد کنید.
3. با LLM کد تولید کنید.
4. کد را برای تایید ارسال کنید.
5. منتظر نتایج باشید

این مراحل باید برای هر مشکل در مجموعه تست ما و برای هر LLM انجام شود. برای سادگی، یک LLM فقط یک بار تلاش می کند تا روی هر مشکل کد بنویسد، بدون هیچ بازخوردی برای تکرار برای بهبود راه حل. همه مشکلات به عنوان مستقل تلقی می شوند. هیچ زمینه ای بین آنها مشترک نیست.

چرا Leetcode؟

Leetcode به چند دلیل انتخاب خوبی برای محک زدن است:

• مشکلات Leetcode در مصاحبه های واقعی برای موقعیت های مهندس نرم افزار استفاده می شود.
• دانشجویان علوم کامپیوتر در طول تحصیل حل مسائل مشابه را یاد می گیرند.
• این یک قاضی آنلاین دارد که می تواند در عرض چند ثانیه بررسی کند که آیا راه حل درست است یا خیر.
• بسیاری از زبان های برنامه نویسی محبوب پشتیبانی می شوند.
• عملکرد کاربر انسانی در این مشکل نیز در دسترس است.

Leetcode چگونه کار می کند

اگر تا به حال با برنامه نویسی رقابتی یا حل چالش های الگوریتمی سروکار نداشته اید، در اینجا توضیح مختصری ارائه شده است. این نمونه توضیح مشکل را بررسی کنید:

 Given an array of integers numbers and an integer target, return indices of the two numbers such that they add up to the target. You may assume that each input would have exactly one solution, and you may not use the same element twice.  You can return the answer in any order.

یک برنامه نویس شرکت کننده باید یک قطعه کد بنویسد که آن مشکل را حل کند. برای شروع، یک "Snippet" وجود دارد - یک تابع ناتمام، با نام و آرگومان های داده شده، اما یک بدنه خالی:

 class Solution: def twoSum(self, nums: List[int], target: int) -> List[int]:   # your code here

معمولاً چندین نمونه از ورودی و خروجی (تست موارد) در توضیحات ارائه شده است:

 Input: nums = [2,7,11,15], target = 9 Output: [0,1]

یک مشکل ممکن است ده ها مورد آزمایشی داشته باشد که فقط در اختیار قاضی آنلاین است. یک مشکل حل می‌شود (یا راه‌حلی پذیرفته شده در نظر گرفته می‌شود) اگر و تنها در صورتی که کد خروجی‌های مورد انتظار را برای همه موارد آزمایشی در یک زمان معقول و محدودیت‌های حافظه تولید کند. راه حل را می توان در هر زبان برنامه نویسی که توسط داور پشتیبانی می شود، نوشت.

هر مشکل یک "نرخ پذیرش" دارد، یعنی نسبت راه حل های پذیرفته شده ارائه شده توسط کاربران Leetcode. توجه داشته باشید که یک کاربر می تواند کد خود را به تعداد نامحدود بار ارسال کند و هر تلاش در نرخ پذیرش حساب می شود.

این قوانین توسط Leetcode اختراع نشده اند. آنها معمولاً برای مدت طولانی در مسابقات علوم رایانه استفاده می شوند.

مجموعه داده ها

مانند معیار قبلی، من می‌خواستم LLM را روی دو دسته مشکل اجرا کنم:

• مشکلات "مشهور" نه تنها مدت‌ها پیش منتشر شده‌اند، بلکه اغلب برای مصاحبه‌های نرم‌افزاری مورد استفاده قرار می‌گیرند - بنابراین، راه‌حل‌ها به طور گسترده در دسترس هستند.
• مشکلات "دیده نشده" که اخیرا منتشر شده اند و راه حل های آنها احتمالا توسط LLM های آزمایش شده مشاهده نشده است.

در حالی که اکثر مشکلات دارای توضیحات متن ساده هستند و فقط نیاز به گسترش یک تابع معین با کد دارند، سایر مشکلات متفاوت هستند. برخی نیاز به پیاده سازی یک رابط دارند، به عنوان مثال، گسترش چندین تابع در یک مشکل. برخی دیگر پیوندها و تصاویر خارجی دارند که می تواند برای LLM ها مشکلاتی ایجاد کند، زیرا تعداد کمی از مدل ها از ورودی تصویر یا مرور اینترنت پشتیبانی می کنند. تصمیم گرفتم مشکلات مربوط به تصاویر، پیوندها و مواردی که نیاز به اجرای چندین عملکرد دارند را معاف کنم.

Leetcode سه لیست مشکل ارائه می دهد: "مصاحبه برتر 150" ، "Leetcode 75" و "100 مورد پسندیده" . مجموعه داده من از مشکلات "مشهور" این لیست ها را ترکیب می کند که در مجموع 134 مشکل پس از استثناهای ذکر شده در بالا را شامل می شود.

برای مسائل "غیبی"، من 99 مورد از جدیدترین مشکلات منتشر شده را انتخاب کردم: 33 آسان، 33 متوسط و 33 سخت. تازگی بر اساس شناسه‌های مشکل، که افزایشی هستند، تعیین شد. اگرچه Leetcode تاریخ انتشار مشکلات را نشان نمی دهد، می توان آن را از نظرات و بحث ها تقریب زد. اولین مورد از این مشکلات "دیده نشده" به احتمال زیاد در حدود نوامبر 2024 منتشر شده است.

سطوح دشواری کاملاً ذهنی و به صلاحدید ویراستاران است. من قصد نداشتم تعداد مشکلات را برای هر مشکل یا مجموعه داده مطابقت دهم.

بیانیه های مشکل و قطعه کد با استفاده از ابزار بنچمارک من که در Github منتشر شده است به دست آمد: https://github.com/whisk/leetgptsolver

اعلان، انتخاب زبان و تولید کد

بنچمارک به این صورت طراحی شده است: LLM تنها یک بار تلاش می کند تا کدی را بدون هیچ گونه اطلاعات قبلی در مورد مشکل (یا هر مشکل دیگری) و بدون اطلاع از موارد آزمایشی آن، به جز مواردی که در خود توضیحات بود، تولید کند. هیچ مکانیزمی برای ارائه بازخورد یا بهبود کد پس از تولید وجود ندارد.

من از همان دستور برای هر LLM و هر مشکلی استفاده کردم:

 Hi, this is a coding interview. You will be given: * A problem statement (with sample test cases if available). * A starter code snippet (with fixed function signatures). Please write your solution in the {language} programming language. Your code must: * Solve the problem fully and correctly. * Pass all provided sample test cases. * Run within acceptable time and memory limits (assume large inputs if none are specified). * Follow good coding practices (clear logic, readable structure, appropriate use of language features). Here is the problem statement: {question} Here is the code snippet, which you should expand with your solution: {snippet} Important Requirements: * Do not change any provided function signatures, class names, or method names. * Output only valid source code that can be executed as-is, without any further improvements or bugfixes. * Do not include docstrings, markdown, or commentary in your final code. Good luck!

درخواست از اولین پیش نویس من با ChatGPT4 "پال شد" شد، اما بدون اجرای هیچ گونه تکنیک "مهندسی سریع".

شرح مشکل قبل از استفاده از آن در اعلان، از برچسب های HTML پاک شد.

برای زبان برنامه نویسی پایتون (نسخه 3) را انتخاب کردم.

از LLMها خواسته شد که فقط کد کار را بدون هیچ متن قبلی خروجی بگیرند، اما این در بسیاری از موارد درست نبود. یک پاکسازی اولیه اجرا شد و همه چیز غیر از کد واقعی حذف شد و ارسال نشد.

مدل ها و پارامترها

مدل‌های مورد استفاده در معیار در جدول زیر با تمام پارامترهای غیر پیش‌فرض مشخص شده‌اند. تاریخ های قطع دانش از اسناد رسمی فروشنده به دست می آید و در صورت اطلاع برای مرجع ارائه می شود.

هدف معیار این بود که تا حد امکان قطعی و قابل تکرار باشد. بنابراین از پارامترهایی مانند دما یا دانه استفاده شد. با این حال، هیچ یک از مدل های آزمایش شده خروجی کاملا قطعی را تضمین نمی کند. این عامل باید در اجرای مجدد این تست ها در نظر گرفته شود.

تمام تاریخ های قطع دانش شناخته شده زودتر از قدیمی ترین مشکل در مجموعه داده شناخته شده (نوامبر 2024) است. با این حال، من نتوانستم تاریخ قطعی برای خانواده مدل Gemini و DeepSeek پیدا کنم.

برخی از مدل‌ها به‌طور پیش‌فرض از حالت‌های «استدلال» یا «تفکر» پشتیبانی می‌کنند، در حالی که برای کلود 3.7 Sonnet می‌توان آن را با عبور دادن پارامترها فعال کرد. استفاده از این ویژگی در جدول مشخص شده است. سایر ویژگی‌های مدل (یا «ابزارها») مانند جستجوی وب فعال نشدند، حتی اگر پشتیبانی شوند.

نتایج

همه رقبا در مورد مشکلات شناخته شده، مانند معیار قبلی، نرخ پذیرش بسیار بالایی را نشان دادند. من مدل‌ها یا تغییرات برتر (یعنی: کلود 3.7 Sonnet با استدلال فعال، DeepSeek R1، Gemini 2.5 Pro، O1) را برای صرفه‌جویی در زمان و اعتبار آزمایش نکردم، زیرا نتایج بسیار قابل پیش‌بینی بود.

نتایج برای مشکلات "غیبی" از دو جنبه به طور قابل توجهی متفاوت است:

1. برای همه مدل ها ، نرخ پذیرش برای مشکلات "غیره" کمتر است . این به ویژه برای مشکلات متوسط و سخت قابل توجه است.
2. مدل‌هایی که حالت «استدلال» یا «تفکر» را فعال کرده بودند، نتایج بهتری را برای مشکلات همه دشواری‌ها ایجاد کردند ، اگرچه اعداد دقیق از مدلی به مدل دیگر متفاوت بود.

نرخ پذیرش به‌طور قابل‌توجهی برای مسائل شناخته‌شده را می‌توان با این احتمال توضیح داد که آن مسائل و راه‌حل‌های آن‌ها بخشی از مجموعه‌های آموزشی بودند، و مدل‌ها فقط باید یک راه‌حل درست شناخته‌شده را بازتولید می‌کردند. با این حال، نرخ پذیرش کاربران برای مشکلات متوسط و سخت جدید نیز کمتر از مشکلات موجود در مجموعه "معروف" است. کمیت کردن این مورد دشوار است و لزوماً به این معنی نیست که مشکلات جدید «سخت‌تر» هستند. ارزیابی دشواری، همانطور که قبلا ذکر شد، بسیار ذهنی است. و همانطور که در مورد خود LLM ها وجود دارد، کاربران انسانی ممکن است راه حل های صحیح شناخته شده را برای مشکلات شناخته شده ارائه دهند.

همه مدل‌هایی که حالت «استدلال» را فعال کرده‌اند، عملکرد قابل توجهی از همتایان اصلی خود داشتند. مهمتر از همه، برخی از آنها توانستند بخش قابل توجهی از مشکلات متوسط و سخت را حل کنند - یک دستاورد غیرقابل اجرا فقط یک سال پیش. o3-mini بهترین نتایج را در بین تمام مدل‌های "استدلال" نشان می‌دهد - حتی بهتر از مدل بسیار گران‌تر و کندتر o1 عمل می‌کند. لازم به ذکر است که o3-mini به طور خاص آموزش داده شد برای حل مشکلات برنامه نویسی رقابتی با این حال، من از نتیجه‌گیری اینکه کدام مدل برای حل مسائل الگوریتمی بهتر است، خودداری می‌کنم، زیرا به شدت به بودجه رمز بستگی دارد و تأخیر و هزینه نیز باید در نظر گرفته شوند.

ملاحظات آینده

نمی توان تضمین کرد که مجموعه مشکلات "غیره" در داده های آموزشی مدل ها گنجانده نشده است. برای پرداختن به این موضوع، ممکن است مشکلات جدید و منحصربفردی را که به طور خاص برای معیارهای آینده طراحی شده اند در نظر بگیریم - البته با استفاده از LLM.

علاوه بر این، استراتژی دیگر استفاده از زبان های برنامه نویسی است که کمتر مورد استفاده قرار می گیرند. این رویکرد ممکن است به LLM ها نیاز داشته باشد که به جای «کپی پیست کردن» کدهای صحیح شناخته شده نوشته شده در پایتون، راه حلی ابداع کنند.

این ایده ها نیاز به تحقیق بیشتری دارند و امیدوارم که شخص دیگری یا من بتوانیم به آنها بپردازیم.

پیوندها

• نتایج خام، مجموعه‌های مشکل و کد منبع را می‌توانید در GitHub من پیدا کنید: https://github.com/whisk/leetgptsolver
• نتایج معیار قبلی من (2024): https://hackernoon.com/testing-llms-on-solving-leetcode-problems

تصویر روی جلد ایجاد شده توسط DALL·E.