۹۸٪ نوسانات امتیازدهی پروژه‌ها ناشی از نویز تصادفی است، نه سوگیری داوران

تصور کنید داوری یک مسابقه را بر عهده دارید و متوجه می‌شوید که تفاوت امتیازات، نه به دلیل سخت‌گیری داوران، بلکه صرفاً حاصل شانس و اتفاقات تصادفی است. اگر هنوز برای حذف «سوگیری داور» در مسابقات خود از میانگین ساده یا z-score استفاده می‌کنید، احتمالاً در حال اصلاح چیزی هستید که اصلاً وجود ندارد.

به نقل از مستندات فنی موتور داوری Dogfood 2026، یافته‌ها نشان می‌دهد که سوگیری داوران تنها ۲٪ از واریانس (Variance) — یا همان میزان پراکندگی داده‌ها — را توجیه می‌کند، در حالی که ۹۸٪ باقی‌مانده مربوط به نویز تصادفی است. این یافته کلیدی پیشنهاد می‌کند که روش‌های سنتی برای اصلاح داوران «سخت‌گیر» یا «سخاوتمند»، اغلب اختلاف‌نظرهای تصادفی را با سوگیری‌های سیستماتیک اشتباه می‌گیرند. این چالش با آنچه در مطالعات A/A برای تفکیک نویز نمونه‌گیری از بهبود واقعی مشاهده می‌شود، شباهت زیادی دارد؛ جایی که تفاوت‌های ظاهری اغلب ناشی از نویز آماری هستند نه تغییرات ساختاری.

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

همان‌طور که در تحلیل‌های قبلی ما درباره‌ی دقت مدل‌های ارزیاب اشاره کردیم، تفکیک سیگنال از نویز سخت‌ترین بخش تحلیل داده است. در این پروژه، توسعه‌دهنده با هدف ایجاد یک پلتفرم ارسال آثار منصفانه برای Hackathon Raptors، از مجموعه‌ای از عامل‌های Claude Code (نسخه Opus 5.5) برای ساخت این موتور استفاده کرد. این سامانه روی یک رویداد نمونه با ۴۱ پروژه، ۳۰ داور و ۱۲۶ بررسی آزمایش شد. دستورالعمل برای Dogfood بسیار سخت‌گیرانه بود: تیم‌ها ۷۲ ساعت فرصت داشتند تا پلتفرم ارسال و داوری را بسازند تا Raptors بتواند رویدادهای خود را روی آن اجرا کند.

مکانیسم مدیریت نویز

این موتور بر اساس یک مدل ساده عمل می‌کند: امتیاز یک بررسی برابر است با سطح واقعی پروژه، به‌اضافه سخاوتمندی داور و به‌اضافه نویز. نویز نشان‌دهنده هر چیزی است که یک اصلاح ریاضی نمی‌تواند آن را رفع کند؛ مثلاً وقتی یک داور عاشق ایده‌ای می‌شود که برای داور دیگر کسالت‌بار است. برای جلوگیری از اصلاح بیش از حد (Over-correcting)، سیستم تمایل داور را به سمت صفر می‌برد، مگر اینکه داده‌ها به‌شدت از یک انحراف خاص حمایت کنند. این میزان انقباض (Shrinkage) در هر بار اجرا، بر اساس امتیازات همان رویداد مجدداً تخمین زده می‌شود.

بر اساس بررسی‌های فنی، این سیستم قواعد سخت‌گیرانه‌ای دارد:

• آستانه داده‌ها: یک داور باید حدود ۴۳ بررسی انجام دهد تا موتور بتواند به نیمی از سوگیری ظاهری او اعتماد کند.
• تأثیر واقعی: چون داوران در این رویداد به‌طور متوسط فقط ۴ پروژه را بررسی کردند، هیچ اصلاحی بیش از ۰.۰۶ امتیاز (در مقیاس ۱ تا ۵) نبود. این موضوع باعث می‌شود به نظر برسد موتور هیچ کاری انجام نمی‌دهد، اما در مورد این داده‌های خاص، این دقیق‌ترین یافته ممکن است.
• شانس در برابر سوگیری: داورانی که هیچ سوگیری نداشتند، صرفاً بر اثر شانس ۰.۳۷ امتیاز با هم تفاوت داشتند، در حالی که داوران واقعی ۰.۴۲ امتیاز فاصله داشتند.
• اعتبارسنجی: در آزمونی که یک انحراف واقعی ایجاد شد (سه داور عمداً ۰.۶ امتیاز سخاوتمندتر شدند)، پراکندگی به ۰.۵۲ رسید؛ اما موتور با موفقیت آن را به ۰.۳۸ بازگرداند.
• تست جایگشت: در ۱۵۲۹ مورد از ۲۰۰۰ شبیه‌سازی (Shuffle)، امتیازات جابه‌جا شده به اندازه امتیازات واقعی پراکنده بودند؛ این یعنی هیچ تفاوت واقعی بین پروژه‌ها فراتر از شانس وجود نداشت.

خطر استفاده از Z-Score

روش‌های سنتی مانند z-scoreهای هر داور، تمام پراکندگی امتیازات یک داور را به عنوان سوگیری در نظر می‌گیرند. در یک شبیه‌سازی برنامه‌ریزی که پیش از شروع (Kickoff) انجام شد، یک z-score منقبض شده، سخت‌گیرترین داور را به‌اشتباه «سخاوتمند» تشخیص داد (+۰.۳۸ در مقابل -۰.۸۲ واقعی)، صرفاً به این دلیل که آن داور اتفاقاً ۱۰ پروژه برتر مسابقه را داوری کرده بود.

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

داور «تخت» یا یکنواخت

یکی از داوران به هر سه پروژه خود در تمام معیارها امتیاز ۴ داده بود. موتور این داوران را از محاسبات حذف می‌کند، اما این کار را به‌صورت مخفیانه انجام نمی‌دهد. حذف این یک داور، رتبه ۱۹ پروژه از ۴۱ پروژه را تغییر داد؛ از جمله پروژه‌ای به نام Small Relay که از رتبه ۱۴ به ۳۰ سقوط کرد.

در شبیه‌سازی‌ها، این قانون در ۶ تا ۸ درصد پنل‌ها، داورانی را که صادقانه امتیاز داده‌اند اما یکنواخت بوده‌اند، حذف می‌کند. با این حال، چون این یک پرچم (Flag) قابل مشاهده همراه با دلیل است، برگزارکننده قدرت لغو این حذف را دارد.

حذف قابلیت‌ها برای حفظ دقت

توسعه‌دهنده برای جلوگیری از ابداع نتایج از روی داده‌های ناچیز، سه قابلیت پرزرق‌وبرق را عمداً حذف کرد:

۱. احتمال پیروزی: موتور پیش از این در ۴۶ مورد از ۸۰ مسیر شبیه‌سازی شده، یک پروژه را با احتمال پیروزی بالای ۵۰٪ معرفی می‌کرد، در حالی که در واقعیت هیچ پروژه‌ای برتر نبود. چون نمایش درصد در صفحه نتایج به عنوان یک «واقعیت» خوانده می‌شود، این قابلیت حذف شد. اکنون پورتال در هیچ صفحه یا پاسخ API، شانس اول شدن را نشان نمی‌دهد.
۲. انتخاب جفت‌به‌جفت: در حالت جفت‌به‌جفت، داوران صرفاً می‌گویند کدام یک از دو پروژه بهتر است. توسعه‌دهنده قصد داشت موتور جفت بعدی را بر اساس پاسخ‌های قبلی انتخاب کند. شرط پذیرش این بود که برنده درست را حداقل ۳ امتیاز بیشتر از روش ساده شناسایی کند؛ اما بهترین نسخه تنها ۱.۴ امتیاز بهبود داشت و بنابراین کنار گذاشته شد.
۳. منطق حذف صلاحیت: این ویژگی که در روز آخر توسط عامل‌ها ساخته شده بود، دو ساعت پیش از ضرب‌الاجل حذف شد. بررسی‌ها نشان داد که بازگرداندن یک پروژه حذف‌شده، باعث از بین رفتن پاسخ‌های جفت‌به‌جفت بعدی می‌شود. علاوه بر این، این ویژگی هرگز در یک کانتینر پاک (Clean Container) اجرا نشده بود.

تضمین صداقت موتور

به جای نمایش درصد پیروزی، موتور اکنون می‌پرسد: «آیا فاصله نفر اول با بقیه بیش از حد کم است؟». سیستم رتبه‌بندی را ۴۰۰۰ بار بر اساس عدم قطعیت خود بازترسیم می‌کند. اگر نفر اول در کمتر از ۳۸۰۰ مورد برنده شود، مسیر به عنوان «بسیار نزدیک» (Too close to call) علامت‌گذاری شده و تصمیم نهایی به داوران انسانی واگذار می‌شود. یک تساوی دقیق همیشه علامت‌گذاری می‌شود.

در رویدادهای شبیه‌سازی‌شده بدون تفاوت واقعی، موتور تنها در ۰.۱۳٪ از ۴۰۰۰ اجرای مسیر، برنده اعلام کرد. اما وقتی برنده اعلام کرد، در ۹۹.۲٪ موارد برنده واقعی بود. با این حال، در جایی که پروژه‌ها واقعاً متفاوت بودند، تنها در ۲۰ تا ۶۳٪ موارد برنده را نام برد و در بقیه موارد صادقانه اعلام کرد که نتیجه «بسیار نزدیک» است.

برای تأیید صداقت موتور، توسعه‌دهنده آن را در برابر نسخه‌ای «عمداً خراب» آزمایش کرد که در آن بازه اطمینان (±) نصف شده بود. در حالی که میانگین کلی در هر دو مورد پاس شد (موتور خراب ۹۸.۴٪ درست بود چون موارد ساده غالب بودند)، یک بررسی هدفمند روی ادعاهای با اطمینان ۹۵ تا ۹۹ درصد، موتور خراب را لو داد؛ دقت آن به ۸۹.۷٪ افت کرد، در حالی که موتور صادق دقت ۹۸.۶٪ را حفظ کرد.

فرآیند ساخت عامل‌محور

این پروژه با یک گردش‌کار عامل‌محور (Agentic) بسیار ساختاریافته توسعه یافت. یک جلسه Claude Code (نسخه Opus 5.5) مسئول برنامه‌ریزی و ادغام (Merge) بود و مدل‌های ارزان‌تر کارهای تکراری و سخت را انجام دادند. هر ویژگی در یک worktree مجزای git قرار داشت و برای ادغام شدن، باید ۷ بررسی سازمان‌دهنده و ۳۵ بررسی دستی را در یک کانتینر پاک پاس می‌کرد. این رویکرد دقیق در ارزیابی عملکرد عامل‌ها، یادآور تحلیل‌های ما درباره رتبه‌بندی عامل‌های کدنویس بر اساس هزینه هر اصلاح است که نشان می‌دهد نرخ موفقیت به تنهایی معیار دقیقی برای سنجش کارایی نیست.

در اوج توسعه، ۱۶ عامل به‌طور هم‌زمان فعال بودند که منجر به ایجاد مجموعه‌ای از ۱۶۷۰ تست موفق شد. توسعه‌دهنده حتی یک سیستم هشدار «سگ نگهبان» را فعال کرد تا ساعت ۴:۳۰ صبح بیدار شود و عامل‌هایی را که در درخواست‌های دسترسی (Permission Prompts) گیر کرده بودند، آزاد کند. در یک مورد، یک عامل ۱۶ دقیقه منتظر اجازه برای حذف فایل‌های موقت (Scratch files) خودش مانده بود.

موانع فنی و شکست‌ها

در طول ساخت، چندین مشکل فنی رخ داد:

• قانون شب: بعد از بیداری‌های ساعت ۴:۳۰ صبح، قانون جدید این شد: «هیچ چیزی حذف نشود؛ هر چه آشغال هست تا صبح بماند».
• خطاهای داکر: یک heredoc بدون کوتیشن به‌طور تصادفی باعث شد دستور docker compose down -v در میانه اجرا فعال شود.
• تداخل ادغام: یک ادغام (Merge) به‌طور بی‌صدا دو اصلاحیه را حذف کرد؛ بنابراین قانون جدید این شد که rebase روی شاخه main باید در پایان هر تسک انجام شود، نه فقط در شروع. این حجم از تغییرات سریع در کد، چالش‌هایی را ایجاد می‌کند که در بررسی بحران حجم کد تولید شده توسط هوش مصنوعی به عنوان عاملی برای فرسودگی بازبین‌های انسانی مورد بحث قرار گرفت.
• تأخیر (Latency): بررسی‌کننده سازمان‌دهندگان هر درخواست را ۱۰ ثانیه زمان می‌داد و تلاشی مجدد نداشت. به دلیل سنگینی لپ‌تاپ، اولین رندر گالری بیش از حد طول کشید و باعث شکست مرحله اول (Tier 1) شد. اکنون پورتال قبل از اعلام آمادگی، گالری خود را گرم (Warm-up) می‌کند.

نقاط ضعف باقی‌مانده

با وجود سخت‌گیری‌ها، موتور محدودیت‌هایی دارد. این سیستم نمی‌تواند «تبانی» (Collusion) را تشخیص دهد، جایی که دو داور امتیازات مثبت را با هم رد و بدل می‌کنند، زیرا این رفتار برای مدل شبیه به اختلاف‌نظر معمولی است. همچنین، تریگرهای پایگاه‌داده در لاگ‌های حسابرسی (Audit log)، اپلیکیشن را متوقف می‌کنند، نه کسی را که فایل پایگاه‌داده را در اختیار دارد؛ این یعنی زنجیره تنها زمانی قابل شناسایی دستکاری است که هش (Hash) خارج از پورتال ذخیره شده باشد.

در نهایت، داوری که استراتژیک عمل می‌کند و همه چیز را «بسیار نزدیک» اعلام می‌کند، تنها در ۱۴ مورد از ۱۲۰ پنل شبیه‌سازی شده شناسایی شد.

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

گام بعدی شما

• اگر برگزارکننده مسابقه هستید، به جای تکیه بر میانگین ساده، از مدل‌های «بازترسیم رتبه‌بندی» برای شناسایی نتایج مشکوک استفاده کنید.
• در تحلیل داده‌های کوچک، هرگونه تفاوت جزئی را به عنوان «سوگیری» تفسیر نکنید و اثر نویز تصادفی را در نظر بگیرید.
• برای توسعه ابزارهای پیچیده، از ساختار worktree مجزا برای هر ویژگی استفاده کنید تا ریسک تداخل در ادغام کد کاهش یابد.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.