معیار شکسته: هوش مصنوعی در ارزیابی مدل‌های مرزی

مدل مرزی یک سطح توانایی ندارد. عملکرد با کار، زبان، ابزار، طول context، پرامپت، پارامتر نمونه‌گیری، scaffold، سقف تأخیر و ارزیاب عوض می‌شود. مدلی که در سؤال با پاسخ دقیق عالی است شاید هنگام نیاز به پرسیدن اطلاعات گم‌شده، حفظ مجوز، کار با نرم‌افزار یا خودداری از تصمیم اثرگذار قابل‌اتکا نباشد.

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

از ادعای استقرار شروع کنید

ادعایی را بنویسید که مدرک باید پشتیبانی کند. «مدل A بهترین است» آزمون‌پذیر نیست. «این دستیار پیکربندی‌شده می‌تواند پاسخ پشتیبانی کم‌ریسک را فارسی و انگلیسی پیش‌نویس، پایگاه دانش تأییدشده را ارجاع، هنگام نبود مدرک خودداری و نرخ خطای بحرانی را زیر آستانه تعریف‌شده در بار مورد انتظار نگه دارد» نزدیک‌تر است.

ادعا واحد تحلیل، مجموعه‌داده، metric، slice، تخصص بازبین و شکست قابل‌قبول را تعیین می‌کند. همچنین جلوی جایگزینی بنچمارک را می‌گیرد؛ انتخاب امتیاز چشمگیر عمومی که کار موردنظر را نمایندگی نمی‌کند. مالک تصمیم و رفتار هنگام شواهد متعارض را نام ببرید. انتخاب مدل تصمیم مهندسی و ریسک است، نه lookup جدول.

سامانه را ارزیابی کنید، نه نام مبهم مدل را

ارائه‌دهنده و شناسه مدل، نسخه تاریخ‌دار یا snapshot تغییرناپذیر در صورت وجود، endpoint، system prompt، template، پیکره بازیابی، نسخه ابزار، مجوز، تنظیم نمونه‌گیری، قید خروجی، پیکربندی ایمنی و orchestrator را ثبت کنید. سرویس مسیریابی با تغییر خاموش مدل، شیء ارزیابی دیگری از endpoint ثابت است. ابزار تازه بدون تغییر مدل پایه، توانایی و سطح حمله را عوض می‌کند.

digest پیکربندی بسازید و به هر نتیجه بچسبانید. با تغییر مؤلفه مهم، تست هدفمند را تکرار کنید. اگر ارائه‌دهنده نسخه پایدار تضمین نمی‌کند، canary پیوسته و تحمل drift تعریف کنید. نتیجه scaffoldهای متفاوت را در یک امتیاز مدل ادغام نکنید مگر مقایسه، scaffold را صریحاً جزو سامانه بداند.

سبد ارزیابی چندلایه بسازید

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

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

رکورد مقایسه‌پذیری بنچمارک نگه دارید

برای هر نتیجه، نام و release دقیق بنچمارک، subset، زبان، hash کار، قالب پرامپت، نمونه few-shot، کنترل آلودگی، تنظیم inference، دسترسی ابزار و بازیابی، بودجه زمان و token، تعداد اجرا، نسخه کد نمره، پیکربندی judge، حذف‌ها و تاریخ را نگه دارید. خروجی خام را زیر کنترل دسترسی حفظ کنید.

این رکورد مقایسه دروغین را می‌گیرد. دو امتیاز با نام یکسان شاید revision کار، prompt، pass-at-k، مدل judge یا محیط اجرای متفاوت داشته باشند. فاصله اطمینان یا تغییر میان اجرا را هرجا معنادار است منتشر کنید. با تغییر بنچمارک، نتیجه قدیم و تازه را بدون مطالعه overlap یک روند پیوسته ندانید.

راهنمای بنچمارک NIST را پیش‌نویس بدانید

صفحه NIST CAISI، رویه ارزیابی خودکار بنچمارک مدل زبانی را به‌عنوان Initial Public Draft منتشرشده برای نظر در ۲۰۲۶ فهرست می‌کند. این سند رویه مقدماتی بنچمارک مدل و عامل را معرفی می‌کند. راهنمای داوطلبانه پیش‌نویس است، نه استاندارد نهایی NIST، مقرره، گواهی یا ادعای کفایت بنچمارک خودکار.

وضعیت پیش‌نویس خودش درس ارزیابی است: نسخه و بلوغ سند را حفظ کنید. تیم باید revision آینده را مرور کند، نه اینکه پیش‌نویس امروز را دائمی ارجاع دهد. تأکید آن بر برنامه‌ریزی، مستندسازی، اعتبار، امنیت و گزارش را ورودی روش داخلی کنید، درحالی‌که نیاز دامنه و بازبینی حرفه‌ای مرجع می‌ماند.

آلودگی را یک طیف مدیریت کنید

آلودگی آزمون وقتی رخ می‌دهد که item دقیق، paraphrase، راه‌حل، rubric ارزیاب یا منبع بسیار نزدیک وارد pretraining، fine-tuning، retrieval، مثال پرامپت یا بازخورد مکرر توسعه شود. حفظ‌کردن تنها مسئله نیست؛ بهینه‌کردن محصول روی آزمون عمومی استقلال آن را کم می‌کند. برای مدل بسته دید آموزش محدود است و ادعای محلی «بدون آلودگی» معمولاً بیش از حد قوی است.

منشأ item و تاریخ انتشار را ثبت کنید. هرجا قانونی و ممکن است overlap را جست‌وجو کنید. مجموعه خصوصی holdout نگه دارید که توسعه‌دهنده و ارائه‌دهنده مدل نمی‌بیند. بخشی را از مورد عملیاتی تازه بچرخانید. مواجهه مشکوک و تحلیل حساسیت را گزارش دهید، نه اینکه item ناخوشایند را بی‌صدا حذف کنید. تازگی بخشی از ریسک را کم می‌کند اما استقلال را تضمین نمی‌کند.

از طراحی بنچمارک زنده یاد بگیرید

مقاله LiveBench پرسش‌های مرتب به‌روزشده از منبع تازه، دسته‌های گسترده و نمره خودکار عینی را برای محدودکردن آلودگی و سوگیری judge معرفی کرد. اصطلاحات بعدی پیرامون کار نیز تفاوت ظریف «بدون آلودگی» و «آلودگی محدود» را نشان می‌دهد. این همچنان آرتیفکت پژوهشی است که توزیع و release آن معنای امتیاز را تعیین می‌کند.

ایده طراحی را بدون تعمیم به کار ببرید: item را timestamp، release را حفظ، ground truth ممیزی‌پذیر را ترجیح، چالش را تازه و مجموعه تاریخی و جاری را جدا کنید. سؤال عمومی تازه پس از انتشار ممکن است در معرض قرار گیرد و نمره عینی فقط برای کاری مناسب است که پاسخ دقیق یا برنامه‌ای قابل‌دفاع دارد. کیفیت باز به روش دیگری نیاز دارد.

برای سامانه ابزارمحور کار اجرایی بسازید

مقاله SWE-bench-Live بنچمارک مهندسی نرم‌افزار قابل‌به‌روزرسانی با مسئله‌های جدید GitHub، مخزن متعدد، محیط کانتینری اختصاصی و ارزیابی اجرایی را شرح می‌دهد. این مقاله اصلی بنچمارک است، نه مدرک مالکیت مهندسی تولید توسط مدل. نتیجه به مجموعه منتشرشده، harness، framework عامل و شرط inference وابسته است.

ارزیابی اجرایی ارزشمند است چون وضعیت حاصل را به‌جای متن قانع‌کننده می‌سنجد. اصل را برای کار محلی اجرا کنید: محیط resetشدنی، آماده‌سازی قطعی، fixture نسخه‌دار و کنترل postcondition. ارزیابی عامل استفاده از رایانه این ایده را به گردش بصری و دسکتاپ می‌برد. ایمنی مسیر، تغییر اضافی و نیاز پنهان خارج از تست نهایی را همچنان بررسی کنید.

مجموعه دامنه را با زمان و منشأ طراحی کنید

از توزیع واقعی کار شامل روتین، نادر، مبهم، خصمانه، چندزبانه و امتناع نمونه بگیرید. item را فقط با اطلاعات موجود در زمان تصمیم بسازید. بر اساس زمان، مشتری، سازمان یا منبع تقسیم کنید، جایی که entity تکراری نشت می‌دهد. منبع، فرایند تألیف، داوری، مجوز، حساسیت و تبدیل synthetic را حفظ کنید.

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

metric را از مدل آسیب انتخاب کنید

دقت exact برای سؤال محدود مناسب است. بازیابی recall مدرک و وفاداری ارجاع می‌خواهد. استخراج ساختاریافته درستی فیلد و schema را. عامل تکمیل تأییدشده، عمل ناامن، retry و مدیریت وضعیت ناقص را. triage پرخطر sensitivity، specificity، calibration و خطای وزن‌دار با پیامد را. سامانه کاربرمحور زحمت اصلاح و اتکای بیش از حد را.

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

پیش از اعتماد، judge مدل را اعتبارسنجی کنید

judge مدل‌محور rubric را در مقیاس اعمال می‌کند اما شاید به ترتیب، سبک، طول، نشانه هویت یا سوگیری مشترک حساس باشد. judge بزرگ‌تر خودکار درست نیست. مجموعه داوری انسانی بسازید، هویت را کور، ترتیب را در صورت کاربرد تصادفی، paraphrase را تست و توافق را بر نوع خطا و slice بسنجید. با تغییر judge، prompt یا rubric دوباره کالیبره کنید.

هرجا scoring دقیق یا اجرایی کار را صادقانه نمایندگی می‌کند همان را به کار ببرید. برای خروجی باز، rubric، کنترل مستقل مدرک و انسان واجد صلاحیت را ترکیب کنید. نسخه، پرامپت، ورودی، خروجی و عدم‌قطعیت judge را حفظ نمایید. اجازه ندهید candidate بدون اعتبارسنجی مستقل خودش را نمره دهد. امتیاز judge خروجی اندازه‌گیری است، نه ground truth.

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

پاسخ نهایی شاید درست باشد اما پس از رفتار ناامن یا بدون مجوز. برای عامل، درخواست ابزار، تصمیم مجوز، منبع، گذار وضعیت، تأیید، retry و کنترل postcondition را ثبت کنید. بسنجید سامانه در دامنه ماند و ادعای مهم مدرک دارد یا نه. chain-of-thought پنهان لازم نیست؛ عمل و مدرک قابل‌مشاهده سطح ممیزی‌اند.

پروژه پروب ارزیابی NIST در ۲۰۲۶ روش اولیه verifier rubricمحور روی پیکره مورداعتماد و رد ممیزی ساختاریافته را بررسی می‌کند. پژوهش جاری است، نه استاندارد نهایی و verifier خودکار ارزیابی خودش را می‌خواهد. پروب را برای افزودن سنجه شناخته‌شده به کار ببرید، نه زنجیره دوری مدل‌هایی که یکدیگر را امن اعلام می‌کنند.

robustness را بدون پنهان‌کردن shift بیازمایید

قالب، ترتیب، نام، locale، کیفیت سند و تأخیر ابزار را بی‌ضرر تغییر دهید تا پایداری سنجیده شود. زمینه گم‌شده واقعی، مدرک متعارض، retrieval کهنه، ابزار دردسترس‌نبودن و دستور خصمانه اضافه کنید. اجرای تصادفی را تکرار و variance را گزارش نمایید. سامانه‌ای که یک بار قبول و غیرقابل‌پیش‌بینی شکست می‌خورد شاید برای کار اثرگذار مناسب نباشد.

perturbation را برچسب بزنید. عملکرد روی حمله ساختگی برآورد شیوع طبیعی نیست مگر طراحی نمونه اجازه دهد. از طرف دیگر نرخ پایین تولید ممکن است نتیجه کشف ضعیف باشد. هر تست robustness را به threat یا failure model وصل و پوشش‌نداده‌ها را مستند کنید.

gate پیش از استقرار را از پایش تولید جدا کنید

ارزیابی پیش از استقرار ورود را کنترل می‌کند. پایش تولید تغییر توزیع، drift نسخه، حمله تازه، نقض سیاست و نتیجه دیررس را می‌یابد. canary، sentinel metric، کانال اصلاح کاربر، آستانه حادثه و rollback را پیش از انتشار تعریف کنید. یک regression suite کوچک و پایدار را کنار مورد تازه چرخشی نگه دارید تا پسرفت از جایگزینی تست جدا شود.

به‌روزرسانی مدل، retrieval، prompt، مجوز و ابزار هرکدام gate هدفمند می‌خواهند. گردش‌کار پرریسک شاید revalidation کامل بخواهد. پایش را با پیکربندی و slice ترافیک گزارش کنید. بازخورد تولید فقط پس از بازبینی حریم خصوصی، رضایت و حاکمیت داده وارد ارزیابی آینده شود.

شواهد را به تصمیم تبدیل کنید

model card یا گزارش داخلی باید کاربرد، کاربرد ممنوع، پیکربندی سامانه، منشأ داده، نسخه بنچمارک، ارزیابی آلودگی، metric، slice، شکست بحرانی، محدودیت ارزیاب و کنترل عملیات را بیان کند. ادعا را با شواهد ممیزی و اطمینان هوش مصنوعی به آرتیفکت نگه‌داری‌شده وصل کنید.

تصمیم می‌تواند تأیید، تأیید مشروط، پایلوت، درخواست مدرک یا رد باشد. شرط انقضا را بنویسید: نسخه تازه مدل، تغییر گردش‌کار، drift توزیع، حادثه یا تاریخ مرور. عبارت «بهترین موجود» را بدون مجموعه مقایسه، تاریخ و شرط صریح به کار نبرید. ارزیابی عدم‌قطعیت را حذف نمی‌کند؛ آن را به اندازه لازم برای انتخاب پاسخ‌گو آشکار می‌سازد.

ساخت برنامه ارزیابی در سی روز

هفته اول دو ادعای استقرار و مدل آسیب را تعریف کنید. پیکربندی کامل را ثابت و template مقایسه بنچمارک بسازید. هفته دوم مجموعه محلی کوچک با منشأ، holdout زمانی، مورد امتناع و slice بحرانی جمع کنید. فقط بنچمارک عمومی مرتبط با توانایی موردنیاز را انتخاب کنید.

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

یادداشت منابع

منابع در ۳۰ ژوئیه ۲۰۲۶ بازبینی شدند. سند بنچمارک خودکار NIST یک Initial Public Draft است و نباید استاندارد نهایی معرفی شود. کار پروب ارزیابی NIST پژوهش اولیه است. LiveBench و SWE-bench-Live مقاله‌های اصلی بنچمارک‌اند؛ ادعای آلودگی، پوشش کار و نتیجه آن‌ها به release و روش تعریف‌شده مربوط است و قابلیت اتکای عمومی تولید را ثابت نمی‌کند.

منابع اصلی و معتبر:

• صفحه راهنمای NIST CAISI و پیش‌نویس اولیه بنچمارک خودکار
• مقاله اصلی LiveBench
• مقاله اصلی SWE-bench-Live
• پژوهش NIST درباره پروب‌های ارزیابی هوش مصنوعی عاملی