کاهش دو درصدی در نرخ موفقیت یک پرامپت، اغلب تفاوتی با پرتاب سکه ندارد. در ۱۴ سپتامبر ۲۰۲۶، راهنمای فنی منتشرشده در dev.to افشا کرد که اکثر تیم‌ها نرخ موفقیت را ابزاری دقیق می‌بینند، در حالی که نویز نمونه‌گیری ذاتی در خروجی‌های مدل‌های زبانی بزرگ (LLM) را نادیده می‌گیرند. این رویکرد سطحی به ارزیابی، یادآور برخی باورهای غلط رایج در مورد تست‌های هوش مصنوعی است که باعث می‌شود نتایج سبز رنگ داشبوردها لزوماً به معنای بهبود واقعی نباشند. راهکار این مشکل، افزودن موارد طلایی (Golden Cases) بیشتر به مجموعه ارزیابی پرامپت نیست، بلکه اجرای یک مرحله کالیبراسیون است که این مجموعه را به یک ابزار اندازه‌گیری با رزولوشن (تفکیک‌پذیری) مشخص تبدیل می‌کند. ساخت این فرآیند حدود یک ساعت زمان می‌برد.
اندازه‌گیری عملکرد هوش مصنوعی به‌شدت ناپایدار است چون نرخ موفقیت، سه منبع مستقل از واریانس (Variance) — یا همان تفاوت‌های تصادفی در نتایج — را با هم ترکیب می‌کند. نخست، نمونه‌گیری مدل زمانی که دمای (Temperature) مدل بالای صفر است نویز ایجاد می‌کند؛ به این معنا که یک پرامپت ممکن است یک‌بار پاس شود و بار بعد شکست بخورد. دوم، نویز ارزیاب رخ می‌دهد؛ زمانی که یک داور یا یک الگوریتم اکتشافی (Heuristic)، درباره خروجی‌های مشابه، تصمیمات متناقضی می‌گیرد، به‌ویژه زمانی که خروجی در مرز بین «تقریباً درست» و «غلط» قرار دارد. در نهایت، ناهمگونی موارد (ترکیبی از سوالات ساده و سخت) معمولاً بیش از هر تغییر واقعی در مدل، روی امتیاز نهایی اثر می‌گذارد. این مورد معمولاً بزرگ‌ترین عامل واریانس است.
تصور کنید از ترازوی آشپزخانه‌ای با دقت ۱۰۰ گرم برای اندازه‌گیری تفاوت ۲۰ گرمی دو جسم استفاده می‌کنید. ترازو عددی را نشان می‌دهد، اما آن عدد بی‌معناست. مجموعه ارزیابی شما هم همین‌طور عمل می‌کند، مگر اینکه یک چیز را دو بار وزن کنید تا رزولوشن یا دقت واقعی ابزارتان را بفهمید. همان‌طور که در تحلیل‌های قبلی ما درباره امنیت مدل‌های بازمتن اشاره کردیم، تکیه بر اعداد بدون درک خطای اندازه‌گیری، منجر به تصمیمات اشتباه راهبردی می‌شود.
ایجاد کف نویز
اولین قدم برای اندازه‌گیری صادقانه، مطالعه A/A است. این کار شامل اجرای دقیقاً یک کامیت (Commit) واحد از مدل، دو بار تحت دو برچسب بازو (Arm Labels) متفاوت است تا مشخص شود وقتی هیچ تغییری رخ نداده، امتیاز چقدر نوسان می‌کند. طبق مستندات dev.to، این ارزان‌ترین آزمایش در کل خط لوله ارزیابی است.
- فرآیند: اجرای مجموعه ارزیابی در برابر خودش با استفاده از یک محیط (Harness) مستقل از مدل. این محیط باید قابلیت پذیرش یک تابع تولید (Generate Callable) و یک تابع ارزیابی (Grade Callable) را داشته باشد تا بتوان آن را روی APIهای میزبانی‌شده، مدل‌های محلی یا داده‌های ثبت‌شده (Fixtures) برای تست‌های قطعی اجرا کرد.
- ریاضیات: استفاده از بازنمونه‌گیری بوت‌استرپ (مثلاً ۲۰۰۰ تکرار) برای محاسبه فاصله اطمینان ۹۵٪ (CI). این فرآیند شامل بازنمونه‌گیری موارد با جایگزینی است، در حالی که نمونه‌ها در داخل هر مورد جفت باقی می‌مانند.
- نتیجه: نصف عرض این فاصله، تبدیل به «حداقل اثر قابل تشخیص» (MDE) شما می‌شود.
در یک مجموعه فرضی با ۴۰ مورد و ۵ نمونه برای هر مورد، ۲۰۰ مشاهده ارزیابی‌شده برای هر بازو داریم. در این سناریو، فواصل بوت‌استرپ اغلب ۳ تا ۴ درصد عرض دارند. بنابراین، یک تغییر ۲ درصدی صرفاً نویز است، فارغ از اینکه داشبورد شما هنگام رندر شدن، چقدر قرمز به نظر برسد.
کالیبراسیون ارزیاب
یک ارزیاب خودکار، یک قطعه نرم‌افزاری است، نه یک پیشگو (Oracle). برای اعتماد به امتیاز، باید ارزیاب را با برچسب‌های انسانی و با استفاده از ضریب کاپای کوهن (Cohen's kappa) کالیبره کنید، نه فقط با صحت (Accuracy) خام. صحت خام ممکن است ارزیابی را خوش‌بینانه نشان دهد، به‌خصوص اگر ارزیاب تمایل داشته باشد صرفاً به سمت یک کلاس خاص (مثلاً همیشه «درست») متمایل شود.
برای انجام این کالیبراسیون، ۴۰ تا ۶۰ خروجی را جمع‌آوری کرده و یک‌بار آن‌ها را به‌صورت دستی برچسب‌گذاری کنید. بر اساس راهنمای dev.to، طبق کنوانسیون لاندیس و کُک، امتیاز کاپای بین ۰.۶۱ تا ۰.۸۰ نشان‌دهنده «توافق قابل‌توجه» است. هر عددی که به‌طور ملموسی پایین‌تر از این مقدار باشد، نویزی بیشتر از تغییرات مدلی که سعی در تشخیص آن دارید، تزریق می‌کند. ارزیاب‌های سهل‌گیر به‌ویژه خطرناک‌اند چون نتایج را در یک فلات (Plateau) نزدیک به سقف متراکم می‌کنند و باعث می‌شوند هر تغییر واقعی شبیه به یک خطای گرد کردن به نظر برسد.
برای شناسایی ارزیاب‌های اکتشافی (Heuristic) که خراب شده‌اند، این راهنما استفاده از پروب‌های خصمانه (Adversarial Probes) را پیشنهاد می‌کند. سه پروب زیر می‌توانند اکثر نقص‌های ارزیاب‌های اکتشافی را شناسایی کنند:
- خروجی‌های خالی: اگر یک پاسخ خالی امتیاز «پاس» بگیرد، این یک نقص کلاسیک است که اغلب توسط قوانین جستجوی زیررشته‌ای (مانند «کلمه خطا وجود ندارد») ایجاد می‌شود. این موارد هرگز نباید پاس شوند (انتظار: ۰.۰).
- پاسخ‌های امتناع: پاسخ‌هایی مانند «من نمی‌توانم در این درخواست کمک کنم» نباید به عنوان موفقیت امتیاز بگیرند (انتظار: ۰.۰).
- پاسخ‌های مرجع: خروجی‌هایی که از پیش به‌عنوان «خوب» شناخته شده‌اند، حتماً باید پاس شوند (انتظار: ۱.۰).
این پروب‌ها باید روی هر بازبینی (Revision) از ارزیاب اجرا شوند. بازنویسی (Refactor) یک ارزیاب در واقع تغییری در ابزار اندازه‌گیری است و بنابراین تمام اعداد تاریخی گزارش‌شده را تغییر می‌دهد.
پیاده‌سازی گیت هشدار
پس از شناسایی کف نویز و کیفیت ارزیاب، تیم‌ها باید یک قانون تصمیم‌گیری سخت‌گیرانه برای درخواست‌های ادغام (Merge Requests) اجرا کنند تا از «هشدارهای کاذب» (False Pages) که باعث اتلاف توجه انسان می‌شود، جلوگیری شود:
۱. واقعیت آماری: فاصله اطمینان ۹۵٪ نباید عدد صفر را شامل شود (مثلاً اگر دلتا منفی است، حد بالای فاصله اطمینان باید زیر صفر باشد).
۲. واقعیت کاربردی: مقدار مطلق تغییر (Delta) باید بیشتر از MDE باشد.
اگر هر دو شرط برقرار بود، ادغام مسدود شده و مالک مدل مطلع می‌شود. اگر تغییر از نظر آماری واقعی باشد اما زیر MDE باشد، رویداد ثبت می‌شود اما هیچ انسانی برای بررسی فراخوانده نمی‌شود. اگر تغییر بالای MDE باشد اما فاصله اطمینان صفر را شامل شود، تیم باید پیش از هر نتیجه‌گیری، تست را با نمونه‌های بیشتر تکرار کند.
این صداقت درباره رزولوشن ابزار به این معناست که برخی تغییرات واقعی ۵ درصدی ممکن است زیر کف نویز ۴ درصدی پنهان شوند. به همین دلیل، گیت‌های کلی (Aggregate Gating) باید با بررسی موردبه‌مورد (Per-case Inspection) ترکیب شوند. گیت از توجه انسان محافظت می‌کند، در حالی که نمای موردبه‌مورد توضیح می‌دهد که در واقعیت چه چیزی تغییر کرده است.
ابزارها و محدودیت‌ها
اجرای این کالیبراسیون‌ها هزینه‌ها را افزایش می‌دهد. مطالعه A/A هزینه مجموعه را برای یک بار اجرا دو برابر می‌کند و ارزیاب‌های نویزی ممکن است به جای یک نمونه، به ۵ تا ۱۰ نمونه برای هر مورد نیاز داشته باشند. در این راستا باید توجه داشت که هزینه استفاده از مدل‌های منتقد برای اصلاح خطاها گاهی از خودِ خطاهای موجود بیشتر است و باید با دقت مدیریت شود. برای جبران این هزینه‌ها، این راهنما به MonkeyCode اشاره می‌کند؛ یک پروژه متن‌باز که یک سطح رایگان با سهمیه ۱۰ میلیون توکن و یک گزینه سرور رایگان برای کالیبراسیون اولیه ارائه می‌دهد.
با این حال، این روش یک راهکار جادویی (Silver Bullet) نیست. برای مجموعه‌هایی با کمتر از ۲۰ مورد، این کار عملاً شبیه به «نمایش» است و بررسی دستی ۱۰ خروجی بهینه‌تر است. علاوه بر این، MDE قابل انتقال نیست؛ هر زمان که مجموعه ارزیابی، ارزیاب یا پیکربندی نمونه‌گیری تغییر کند، باید دوباره کالیبره شود.
برای تیم‌هایی با داده‌های خوشه‌ای (مثلاً زبان‌های مختلف، مشتریان متفاوت یا سطوح دشواری گوناگون)، فرض بوت‌استرپ درباره «تعویض‌پذیری» (Exchangeability) از بین می‌رود. در این موارد، برای حفظ دقت، بازنمونه‌گیری طبقه‌بندی‌شده (Stratified Resampling) در داخل هر خوشه مورد نیاز است، هرچند این کار مستلزم نوشتن اسکریپت کمی طولانی‌تر است.
اگر تیمی هرگز دلتای ارزیابی‌ها را به کسی گزارش نمی‌کند، این کالیبراسیون بیشتر یک سرگرمی است تا زیرساخت و می‌توان آن را تا زمانی که یک تصمیم به این اعداد وابسته شود، نادیده گرفت. ترتیب عملیاتی کاربردی به این صورت است: ابتدا مطالعه A/A، سپس پروب‌های ارزیاب، بعد گیت هشدار و در نهایت گسترش موارد طلایی. این رویکرد سیستماتیک، یک داشبورد نویزی را به ابزاری قابل‌دفاع برای هوش مصنوعی تولیدی در محیط عملیاتی تبدیل می‌کند.
گام بعدی شما
- اجرای یک تست A/A ساده روی فعالی‌ترین مجموعه ارزیابی خود برای یافتن MDE.
- بررسی ارزیاب‌های خود با سه پروب «خروجی خالی»، «امتناع» و «پاسخ مرجع».
- جایگزینی هشدارهای ساده بر اساس درصد با گیت‌های مبتنی بر فاصله اطمینان ۹۵٪.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره تراشه‌های Blackwell مراجعه کنید.
گفتگو