۱۷ تیر ۱۴۰۵

جدا کردن سیگنال از نویز در ارزیابی‌های کدنویسی

با یک ممیزی دقیق، مشکلات گسترده‌ای در کارهای SWE-Bench Pro می‌یابیم و برآورد می‌کنیم حدود ۳۰٪ از کارها خراب‌اند.

در حال بارگذاری…

اندازه‌گیری دقیق توانمندی‌های مدل‌های ما برای تصمیم‌های درست دربارهٔ استقرار و ایمنی مهم است؛ از جمله تصمیم‌هایی که در چارچوب چارچوب آمادگی⁠(در یک پنجره جدید باز می‌شود) OpenAI گرفته می‌شوند. با هر انتشار مدل، نتایج مجموعه‌ای از بنچمارک‌های بیرونی و درونی را گزارش می‌کنیم تا پیشرفت مدل را پیگیری کنیم. وقتی ارزیابی‌ها نقص‌هایی داشته باشند که بر نتایج اثر می‌گذارد، می‌توانند برداشت نادرستی از توانمندی‌ها ایجاد کنند، پرونده‌های ایمنی را نادرست نشان دهند و بر اولویت‌های پژوهشی اثر بگذارند.

ما به‌تازگی بررسی کردیم که چگونه یکی از پرکاربردترین بنچمارک‌های کدنویسی، یعنی SWE-bench Verified، با مشکلات بنیادی در طراحی و آلودگی داده روبه‌رو بود، و دریافتیم که این ارزیابی دیگر سیگنال معناداری دربارهٔ توانمندی‌های توسعهٔ نرم‌افزار ارائه نمی‌داد. در آن زمان، جامعهٔ گسترده‌تر را تشویق کردیم به SWE-Bench Pro مهاجرت کنند.

SWE-Bench Pro⁠(در یک پنجره جدید باز می‌شود) طراحی شد تا با آزمودن مدل‌ها در افق‌های زمانی طولانی‌تر و کارهای کدنویسی واقع‌گرایانه‌تر، SWE-bench Verified را بهبود دهد و توانمندی‌های کدنویسی عامل‌محور را بهتر پیگیری کند. مانند SWE-bench Verified، کارها به‌صورت برنامه‌نویسی‌شده از تاریخچهٔ تغییرات قابلیت‌ها در مجموعه‌ای از محل‌های نگهداری عمومی و خصوصی استخراج می‌شوند. مدل‌ها باید راه‌حلی پیاده‌سازی کنند که آزمون‌های جدید یک قابلیت را بگذراند، بی‌آنکه کارکردهای موجود را خراب کند. در بخش عمومی ۷۳۱ کاری، نرخ قبولی مدل‌های پیشرو طی هشت ماه از ۲۳٫۳٪ به ۸۰٫۳٪ رسید.

از آن زمان، ممیزی مشابهی روی SWE-Bench Pro انجام داده‌ایم و مجموعه‌داده را با یک خط لولهٔ تحلیل داده‌نقطه بررسی کرده‌ایم. این خط لوله تلاش‌های مدل برای انجام کار، فرادادهٔ کار و ردپاهای شکست را بررسی کرد تا نقص‌های احتمالی ارزیابی را علامت‌گذاری کند. سپس هر کار علامت‌گذاری‌شده از چندین گذرِ عاملِ کاوشگر ارزیابی شد و پنج مهندس نرم‌افزار باتجربه نیز آن را مستقل بازبینی کردند؛ اختلاف‌ها هم برای بررسی بیشتر ارجاع داده شد.

شواهدی می‌یابیم که نشان می‌دهد بخش قابل‌توجهی از مجموعه‌داده دچار مشکلات اساسی است. خط لولهٔ تحلیل داده‌نقطه‌های ما ۲۰۰ کار (۲۷٫۴٪) را خراب تشخیص داد، در حالی که پویش حاشیه‌نویسی انسانی ۲۴۹ مورد (۳۴٫۱٪) را شناسایی کرد.

این مشکلات عمدتاً در چهار دسته قرار می‌گرفتند:

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

یافته‌های ما دشواری گردآوری بنچمارک‌های دشوار اما منصفانه و سودمندی رو‌به‌رشد عامل‌ها برای بررسی‌های مقیاس‌پذیر کیفیت داده را نشان می‌دهد. با توجه به این نتایج، برآورد می‌کنیم که حدود ۳۰٪ از کارهای SWE-bench Pro خراب‌اند و توصیه می‌کنیم توسعه‌دهندگان مدل نتایج را با دقت بررسی کنند.

روش‌شناسی

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

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

یک فیلتر خودکار اولیه دستورالعمل‌های داده‌شده به مدل، تلاش‌های مدل برای حل کار و آزمون‌های استفاده‌شده برای نمره‌دهی به این تلاش‌ها را بررسی می‌کند تا نمونه‌های احتمالاً خراب یا مسئله‌دار را علامت‌گذاری کند. این فیلتر ۲۸۶ کارِ احتمالاً خراب را علامت‌گذاری کرد. سپس آن زیرمجموعه را از دو مسیر عمیق‌تر بررسی کردیم: بازبینی عامل با نظارت انسانی، که بررسی‌های گسترده‌ای با عامل‌های کاوشگر و یک داوری نهایی انسانی انجام می‌دهد؛ و یک پویش حاشیه‌نویسی انسانی با همکاری توسعه‌دهندگان نرم‌افزار باتجربه.

بازبینی عامل با نظارت انسانی

هر مشکل علامت‌گذاری‌شده با عامل‌های کاوشگر مبتنی بر Codex ممیزی می‌شود که به محل نگهداری و محیط کار دسترسی داشتند. این کار به آن‌ها کمک می‌کند ابهام معقول کار را، که اغلب با مطالعهٔ کدهای پیرامونی و قواعد محل نگهداری حل می‌شود، از ناکامل بودن واقعی مشخصات جدا کنند. عامل می‌تواند آزمون‌ها را اجرا کند، فایل‌های موجود در repo را وارسی کند، و تلاش‌های مدل و حالت‌های شکست رایج آن‌ها در آن کار را بررسی کند. پس از چند تکرار مستقل از این ممیزی‌های عمیق‌تر، یک پژوهشگر خلاصه‌ها را بازبینی کرد، داوری نهایی را انجام داد و مشکلات احتمالی را برچسب‌گذاری کرد.

پویش حاشیه‌نویسی انسانی

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

بازبینان ابتدا بر اساس صورت‌مسئلهٔ قابل‌مشاهده، موارد آزمون و راه‌حل مرجعِ حقیقت مبنا (معروف به وصلهٔ طلایی) داوری مستقلی شکل دادند، و سپس از تحلیل خط لوله یا رونوشت به‌عنوان زمینهٔ پشتیبان استفاده کردند. سپس بازبینان بر اساس شواهد عینی یک برچسب و درجهٔ شدت تعیین کردند، و موارد اختلاف یا کم‌اطمینان را برای بازبینی بیشتر ارجاع دادند.

بازبینان انسانی بیش از عامل‌های کاوشگر احتمال داشت کارها را خراب علامت‌گذاری کنند. میان دو مسیر بازبینی دربارهٔ دسته‌ها نیز تا حدی اختلاف وجود داشت، اما در هیچ کار علامت‌گذاری‌شده‌ای «خراب نیست» رایج‌ترین برچسب انسانی نبود. در دسته‌هایی که خط لولهٔ عامل علامت‌گذاری کرده بود، داوری‌های بازبینان در ۷۴٪ موارد هم‌پوشانی داشت.

در مقایسه با خط لولهٔ عامل، بازبینان انسانی همچنین بیشتر احتمال داشت برای یک کار چند برچسب انتخاب کنند؛ یعنی دریافته بودند کارها از چند جهت خراب‌اند یا به‌روشنی در یک دستهٔ واحد جا نمی‌گیرند. این نشان می‌دهد خط لولهٔ عامل به‌علاوهٔ بازبین به برچسب‌گذاری محافظه‌کارانه انجامید: همان حالت‌های شکست کلی را که انسان‌ها شناسایی کردند ثبت کرد، اما مواردی را که بازبینان در آن‌ها مشکلات اضافی یا هم‌پوشان دیدند کمتر شمرد. بزرگ‌ترین تفاوت در آزمون‌های کم‌پوشش بود؛ انسان‌ها آن را برای ۹٫۴٪ از بنچمارک رایج‌ترین مشکل دانستند، در مقایسه با ۴٫۱٪ در خط لولهٔ عامل.

حالت‌های شکست

در چند مورد، اعلانِ کار پیاده‌سازی مشخصی را تجویز می‌کرد، اما موارد آزمون پنهان انتظار رفتار متفاوتی داشتند.

This task involves normalizing table-of-contents entries and rendering them back to Markdown via TocEntry.to_markdown(). The task prompt specifies serialization down to character-level spacing, describing how exact spacing and pipes are enforced, and gives examples such as " | Chapter 1 | 1" and "** | Chapter 1 | 1":

هیچ‌کدام

1"[space]| Chapter 1 | 1"
2"**[space]| Chapter 1 | 1"
3"[space]| Just title | "

The hidden test_to_markdown assertions instead require " | Chapter 1 | 1" and "** | Chapter 1 | 1":

هیچ‌کدام

1"[space][space]| Chapter 1 | 1"
2"**[space][space]| Chapter 1 | 1"
3"[space][space]| Just title | "

There are two leading spaces in the hidden tests, but the example given to the model only contains one leading space. If a model rightly follows the given prompt, that one-character difference would fail the hidden test cases and the task would be marked incorrect.

بحث

مشکلاتی که شناسایی کرده‌ایم، همراه با موارد مشابه در SWE-bench Verified، اهمیت بررسی دقیق بنچمارک‌ها را برجسته می‌کند. مسائل و درخواست‌های pull در محل‌های نگهداری متن‌باز در اصل برای همکاری انسانی ایجاد شده بودند، اغلب از طریق رفت‌وبرگشت‌های طولانی میان نگه‌داران و مشارکت‌کنندگان. در نتیجه، شرح مسئله، کد ادغام‌شده و آزمون‌های واحد همیشه چنان هم‌راستا نیستند که کارهایی تمیز و مستقل برای ارزیابی قابل‌اعتماد مدل‌ها بسازند. به‌ویژه، آزمون‌های گنجانده‌شده در درخواست‌های pull می‌توانند بیش‌ازحد سخت‌گیرانه باشند، چون برای اعتبارسنجی یک تغییر مشخص نوشته شده‌اند، نه برای تعریف معیاری مستقل از پیاده‌سازی برای حل کار.

در عین حال، تشخیص نقص‌های ارزیابی اکنون حتی نسبت به همین مدت کوتاه پیش آسان‌تر شده است. با بهبود توانمندی‌های مدل، می‌توانیم از همان مدل‌ها برای بررسی اعلان‌ها، آزمون‌ها، وصله‌ها، ردپاها و موارد مرزی با عمق و سازگاری بسیار بیشتر استفاده کنیم؛ کاری که کمک می‌کند مشکلات بنچمارکی که پیش‌تر یافتنشان در مقیاس پرهزینه یا غیرعملی بود آشکار شوند.

امیدواریم جامعهٔ گسترده‌تر ارزیابی، بنچمارک‌های تازه‌ای بسازد که توسعه‌دهندگان نرم‌افزار باتجربه مشخصاً برای آزمودن توانمندی‌های مدل طراحی کرده باشند. این رویکرد می‌تواند سطح دشواری و واقع‌گرایی بالایی را که برای سنجش توانمندی‌های مدل می‌خواهیم حفظ کند و در سراسر فرایند نظارت انسانی بهتری فراهم آورد. با توجه به مشکلات آشکارشده در این تحلیل، توصیهٔ پیشین خود برای پذیرش SWE-Bench Pro را پس می‌گیریم.

در نهایت، یک ارزیابی باید از طریق بنچمارک‌هایی که دور زدنشان دشوار، اعتماد به آن‌ها آسان و بازتاب‌دهندهٔ واقعی توانمندی یا هم‌راستایی مدل‌اند، سیگنال معنادار ارائه دهد. از آنجا که این نتایج تصمیم‌های OpenAI دربارهٔ استقرار و ایمنی را آگاه می‌کنند، ارزیابی‌هایی که پیگیری می‌کنیم باید معتبر و اطلاع‌بخش باشند.