Fable 5، Opus 4.8 و Sonnet 4.6: چگونه LLMها را به‌طور منصفانه روی کد خودمان مقایسه کنیم
آزمایش کنترل‌شده: Fable 5، Opus 4.8 و Sonnet 4.6 با یک پرامپت واحد یک کدبیس واقعی را ممیزی می‌کنند. روش‌شناسی مقایسه منصفانه LLMها روی پروژه خودتان.
این تصویر بارگذاری نشد.وقتی مدل جدیدی منتشر می‌شود، اعلامیه به این پرسش پاسخ می‌دهد که «چقدر در بنچمارک‌ها بهتر است» — و به تنها پرسشی که برای من مهم است پاسخ نمی‌دهد: چه چیزی را در کار من تغییر خواهد داد. من یک آزمایش کنترل‌شده انجام دادم: سه مدل Claude — Fable 5، Opus 4.8 و Sonnet 4.6 — دقیقاً یک وظیفه یکسان برای ممیزی کدبیس این وبلاگ دریافت کردند، هرکدام در یک کپی جداگانه از مخزن، با یک روبریک ارزیابی که از پیش توافق شده بود. در این مقاله — خود روش‌شناسی که می‌توان آن را روی هر پروژه‌ای تکرار کرد، نتایج، و جداگانه — اینکه چگونه آزمایش دو بار شکست خورد و این چه چیزی را آموخت.
چرا بنچمارک‌ها به پرسش من پاسخ نمی‌دهند
بنچمارک‌های عمومی دو مشکل دارند و هر دو بنیادی هستند. اولی — آلودگی داده: نمونه‌های آزمون به مجموعه‌های آموزش نشت می‌کنند و مدل تا حدی پاسخ‌ها را «به یاد می‌آورد» به‌جای اینکه مسئله را حل کند. این یک گمان حاشیه‌ای نیست، بلکه موضوع یک حوزه کامل پژوهشی است: مرور Xu و همکاران (2024) پژوهش‌های آلودگی بنچمارک را نظام‌مند می‌کند، و مرور EMNLP 2025 پاسخ صنعت را ثبت می‌کند — گذار از آزمون‌های ایستا به آزمون‌های پویا و تولیدشده.
مشکل دوم ساده‌تر است: بنچمارک وظیفه من را اندازه نمی‌گیرد. من مدلی نمی‌خواهم که بهترین در حل مسائل المپیادی باشد. من مدلی می‌خواهم که باگ‌های واقعی را در وبلاگ Laravel من پیدا کند، باگ‌های ناموجود را از خود نسازد و ثابت کند که اصلاحش کار می‌کند.
از این یک اندیشه ساده برمی‌آید: بهترین بستر آزمون برای مقایسه مدل‌ها، پروژه خودتان است. کد آن در چنین ترکیبی در مجموعه‌های آموزش نیست، وظایف روی آن دقیقاً همان‌هایی هستند که برایشان پول می‌دهم، و نتایج را می‌توانم با دست بررسی کنم چون این کد را می‌شناسم.
طراحی آزمایش: یک پرامپت، سه جهان جداگانه
وظیفه برای هر سه مدل دقیقاً یکسان بود — تنها نام شاخه و پوشه نتایج متفاوت بود. چهار فاز: ممیزی سیستم دوزبانه مقالات وبلاگ با اثبات هر یافته به‌صورت файл:строка با نقل‌قول کد؛ انتخاب راه‌حل برای سه یافته اصلی با توصیف مصالحه‌ها؛ پیاده‌سازی یک اصلاح با خودآزمایی؛ یادداشتی درباره نتایج به روسی و انگلیسی. یک چرخه کامل کار مهندسی، نه یک «پرسش-پاسخ» جداگانه — این رویکرد را Anthropic نیز توصیه می‌کند: ارزیابی عامل‌ها روی وظایف از یک محصول واقعی، بر اساس روبریکی که پیش از اجرا توافق شده است.
سه قاعده مقایسه را منصفانه کرد:
جداسازی. هر مدل در یک git worktree جداگانه کار می‌کرد — کپی خودش از پوشه کاری با شاخه خودش. مدل‌ها از نظر فیزیکی نمی‌توانستند نتایج یکدیگر را ببینند یا مزاحم یکدیگر شوند.
محافظت در برابر توهم — در خود پرامپت. خط کلیدی وظیفه: «یافته ساختگی (کد ناموجود، خط نادرست) بدتر از نبود یافته است». بدون این انگیزه، مدلی که از آن خواسته می‌شود مشکلات را پیدا کند، تمایل دارد در هر حال آن‌ها را «پیدا کند». با آن — هر یافته باید از بررسی دستی جان سالم به در ببرد.
حذف سرنخ‌ها از امتیاز. در مخزن فایلی به نام CLAUDE.md وجود دارد که دام‌های شناخته‌شده پروژه را توصیف می‌کند — مثلاً مسیرهای نسبی به دارایی‌ها که در URLهای دارای پیشوند زبان می‌شکنند. هر سه مدل این فایل را می‌خوانند، بنابراین چنین یافته‌هایی «رایگان» هستند: برای دقت به حساب می‌آیند، اما نه برای عمق.
روبریک: فقط آنچه را می‌توان با دست بررسی کرد ارزیابی کن
پیش از اجرا شش محور پنج‌امتیازی را تثبیت کردم: دقت ممیزی (بررسی دستی نمونه‌ای از یافته‌ها بر اساس файл:строка)، عمق (یافته‌های تأییدشده‌ای که در سرنخ‌ها نیستند)، کیفیت استدلال درباره مصالحه‌ها، کد و واقعی بودن خودآزمایی، کیفیت متن روسی و انگلیسی، نظم (صفر پرسش از انسان، هیچ نقض محدودیت). اصل همان اصل یک بازبینی کد خوب است: هرچه یک محور کمتر بر سلیقه و بیشتر بر واقعیت قابل‌بررسی تکیه کند، بیشتر می‌توان به آن اعتماد کرد.
چگونه همه‌چیز بار اول شکست خورد
اجرای اول را اشتباه انجام دادم — و این قابل‌انتقال‌ترین بخش آزمایش از آب درآمد. سه نشست تعاملی را به‌طور موازی در یک پوشه یکسان از مخزن باز کردم. چند دقیقه بعد، در درخت کاری تغییرات ثبت‌نشده‌ای افتاده بود که انتسابشان ناممکن بود: یک checkout مشترک یعنی وقتی یک نشست git checkout -bانجام می‌دهد، شاخه برای هر سه عوض می‌شود و تغییرات و کامیت‌هایشان با هم قاطی می‌شود. یکی از نشست‌ها علاوه بر این git stash را انجام داد و همه‌چیز را در آن جارو کرد — از جمله فایل‌های خودم که ربطی به آزمایش نداشتند.
«عامل‌های AI موازی در یک پوشه، آزمایش موازی نیست. این یک درگیری بزرگ با سه نویسنده است.»
– نتیجه‌ای که برایم یک اجرای دوباره هزینه داشت
نتایج دو جلسه را ناچار شدیم نامناسب تشخیص دهیم: حتی اگر تا انتها کار را ادامه می‌دادند، نمی‌توانستم صادقانه بگویم ویرایش‌های چه کسی را ارزیابی می‌کنم. اجرای دوم — این بار در worktreeهای جداگانه — به محدودیت‌های طرح اشتراک برخورد: دو عامل در شروع از کار افتادند و سومی معلق ماند و همچنان در رابط کاربری «در حال کار» به نظر می‌رسید. تشخیص را سیستم فایل داد، نه نشانگر وضعیت: در بیست دقیقه هیچ فایلی در نسخه کاری‌اش پدید نیامد. این درس دوم قابل انتقال است: زنده‌بودن عامل با تغییرات روی دیسک سنجیده می‌شود. پس از راه‌اندازی مجدد، هر سه مدل چرخه کامل را در شرایط برابر گذراندند.
نتایج: کجا مدل‌ها یکسان‌اند و کجا متفاوت
مهم‌ترین نتیجه — چیزی است که رخ نداد: هیچ‌یک از مدل‌ها توهم نداشت. من دست‌کم سه یافته از هر مدل را دستی بررسی کردم — همه نقل‌قول‌ها و شماره خطوط تا حد کاراکتر دقیق بودند. برای وظایف حسابرسی این آستانه اصلی اعتماد است و هر سه از آن گذشتند.
از اینجا تفاوت‌ها آغاز می‌شود:
| Fable 5 | Opus 4.8 | Sonnet 4.6 | |
|---|---|---|---|
| یافته‌های تأییدشده | 11 | 5 | 9 |
| یافته‌های منحصربه‌فرد غیرساده | 3 | 1 | 2 |
| خودآزمایی اصلاح | رندر یکپارچه روی پایگاه‌داده موقت، xmllint، انتساب تست شکست‌خورده دیگری | لینتر + رندر؛ باگ خودش را گرفت | فقط لینتر و فهرست مسیرها |
| توکن / زمان | 164k / 21 دقیقه | 101k / 12 دقیقه | 131k / 12 دقیقه |
| نمره نهایی بر اساس روبریک (از 30) | 30 | 24 | 25,5 |
تفاوت‌های کیفی از نمرات آگاهی‌بخش‌ترند. Opus 4.8 — تنها کسی بود که عنوان خراب Content-Type را در sitemap متوجه نشد (دو مدل دیگر آن را یافتند) و آن را در اصلاح خودش باقی گذاشت؛ و یک واژه انگلیسی به متن روسی‌اش نشت کرد — «و even مسیر تصویر». Sonnet 4.6 اصلاح درستی انجام داد، اما خودآزمایی‌اش اعلامی بود: لینتر به‌جای اجرا. Fable 5 دقیقاً در خودآزمایی برجسته شد: کشف کرد که php روی ماشین من پوششی روی یک کانتینر docker است که به دایرکتوری اصلی سوار شده، همه بررسی‌ها را از طریق کانتینرهای یک‌بارمصرف بازسازی کرد و اصلاح خود را به‌صورت یکپارچه روی پایگاه‌داده موقت اجرا کرد. تفاوت میان «انجام دادم» و «اثبات کردم که انجام دادم» — همین محور متمایزکننده‌ترین محور برای وظایف عاملی است.
سیگنال مفید دیگر — همگرایی: هر سه مدل به‌طور مستقل یک مشکل را به‌عنوان یافته اصلی نام بردند — همان مشکل sitemap. وقتی حسابرسان مستقل در یافته برتر به توافق می‌رسند، این جایگزین ارزانی برای توافق بین‌متخصصی است: مشکل تقریباً به‌طور قطع واقعی است.
داور از میان شرکت‌کنندگان
ارزیابی بر اساس روبریک را Fable 5 انجام داد — همان مدلی که در مقایسه شرکت داشت. این یک حفره روش‌شناختی است و باید صریح درباره‌اش گفت: داوران LLM به‌طور سیستماتیک به متن‌های خودشان نمره بالاتر می‌دهند، و این تمایل هرچه مدل متن‌های خودش را بهتر بشناسد قوی‌تر می‌شود — این در کار Panickssery و همکاران در NeurIPS 2024نشان داده شده است. سوگیری را می‌توان به دو روش کاهش داد و من هر دو را به کار بردم: نخست، تا حد امکان روبریک را از محورهای سلیقه‌ای به سمت واقعیت‌های قابل بررسی سوق دادم — دقت خطوط، کامل‌بودن اصلاح، واژه بیگانه نشت‌کرده به قضاوت داور بستگی ندارند؛ دوم، تعارض را صریحاً اعلام کردم و محورهای مورد اختلاف را به بررسی متقابل مدل دیگر یا انسان سپردم. محورهای ذهنی نتیجه من — کیفیت متن، کیفیت استدلال — را باید با این تصحیح خواند.
محدودیت‌های صداقت
یک اجرا برای هر مدل یعنی n=1: تفاوت‌های یک-دو نمره‌ای معنایی ندارند، فقط به شکاف‌های کیفی می‌توان اعتماد کرد — باگ ازدست‌رفته، عمق خودآزمایی. آزمایش سه مدل را روی یک وظیفه در یک دامنه می‌سنجد؛ «Fable 5 به‌طور کلی بهتر است» از آن نتیجه نمی‌شود. و باید هزینه را به یاد داشت: مدل برتر ۱٫۶ برابر توکن بیشتر و تقریباً دو برابر زمان بیشتر از اقتصادی‌ترین شرکت‌کننده صرف کرد، و توکنش بر اساس قیمت‌گذاری هم به‌خودی‌خود گران‌تر است — برای وظایف منظم این استدلالی وزن‌دار به سود مدل‌های ساده‌تر است.
چه چیزی برای خودم برمی‌دارم
روش‌شناسی به یک چک‌لیست کوتاه خلاصه شد که برای هر پروژه و هر مدلی کار می‌کند:
- وظیفه آزمون — چرخه کامل کار واقعی روی کد خودتان، نه یک مسئله مصنوعی.
- یک پرامپت برای همه، جداسازی از طریق worktreeهای جداگانه، نتایج — در شاخه‌های جداگانه.
- در پرامپت — هزینه صریح توهم: یافته ساختگی بدتر از نبود یافته است.
- سرنخ‌های در دسترس همه (مستندات، یادداشت‌های مخزن) از امتیاز عمق حذف می‌شوند.
- روبریک پیش از اجرا تثبیت می‌شود و بر واقعیت‌های قابل بررسی تکیه دارد، نه بر برداشت.
- نمونه یافته‌ها را دستی بررسی کنید؛ تطابق یافته‌های برتر در مدل‌های مستقل — سیگنالی از واقعی‌بودن آن‌هاست.
- داور-شرکت‌کننده — تعارض اعلام‌شده: محورهای مورد اختلاف به ارزیابی متقابل سپرده شوند.
- زنده‌بودن عامل را با دیسک بسنجید، نه با نشانگر در رابط کاربری.
پاداشی که در برنامه نبود: آزمایش خودش را جبران کرد. سه حسابرسی مستقل مشکلات واقعی در وبلاگ یافتند — از sitemap بدون صفحات انگلیسی تا کوئری‌های مرده در کنترلر — و دو اصلاح آماده هم‌اکنون در شاخه‌ها منتظر انتقال به پروداکشن‌اند. مقایسه مدل‌ها روی کد خودتان، برخلاف خواندن بنچمارک‌ها، چیزی بیش از یک نظر برایتان باقی می‌گذارد.
منابع و مراجع
- Benchmark Data Contamination of Large Language Models: A Survey (Xu et al., 2024) — نظام‌مندسازی مسئله آلودگی بنچمارک‌ها؛ استدلال اصلی به سود آزمون روی کد خودتان.
- معیارسنجی LLMها تحت آلودگی داده: از ارزیابی ایستا تا پویا (EMNLP 2025) — چگونه صنعت از آزمون‌های ایستا به پویا حرکت می‌کند؛ آزمایش من یک مورد خاص از آزمون پویا است.
- ابهام‌زدایی از ارزیابی‌ها برای عامل‌های هوش مصنوعی (Anthropic Engineering, 2026) — عمل ارزیابی عامل‌ها: وظایف از محصول واقعی، معیارهای قابل بررسی، تمایز مسیر و نتیجه.
- ارزیاب‌های LLM نسل‌های خودشان را می‌شناسند و ترجیح می‌دهند (NeurIPS 2024) — چرا مدل-داور به خودش نمره بالاتر می‌دهد و با آن چه باید کرد.
- اجرای نشست‌های موازی با worktreeها (Claude Code Docs) — سازوکار استاندارد جداسازی نشست‌های موازی عامل، که بدون آن اولین اجرای آزمایش از هم پاشید.