اگر امروز برای ارزیابی مدلهای خود از امتیازات ۱ تا ۵ استفاده میکنید، احتمالاً در تصمیمگیری برای انتشار محصول دچار تردید هستید. مشکل اینجاست که مرز بین امتیاز ۳ و ۴ هرگز نمیتواند با کلمات تعریف شود و در نتیجه، میانگین ۳.۷ هیچ پاسخی به این سؤال حیاتی نمیدهد: «آیا محصول را منتشر کنیم یا خیر؟»
هامل حسین (Hamel Husain)، متخصص پیشرو در ارزیابی محصولات هوش مصنوعی که به بیش از ۴۵۰۰ دانشجو آموزش داده است، علیه این مقیاسهای ریزدانه استدلال میکند. او معتقد است که این سیستمها باعث ناهماهنگی در امتیازدهی و ایجاد میانگینهای غیرقابل تصمیمگیری میشوند. او هشدار میدهد که یک ارزیاب انسانی ممکن است در صبح مدل را متفاوت از عصر ارزیابی کند و این نوسان، اعتبار دادهها را از بین میبرد. برای توسعهدهندگانی که ویژگیهای مبتنی بر مدل زبانی بزرگ (LLM) — مثل کتابخانهداری که میلیاردها صفحه را خوانده و حالا با همان لحن کتابها جواب میدهد — را عرضه میکنند، هدف رسیدن به یک میانگین بالا نیست، بلکه اتخاذ یک تصمیم قطعی است.
همانطور که در تحلیلهای قبلی ما دربارهی امنیت و پایداری مدلهای زبانی اشاره کردیم، تکیه بر بنچمارکهای کلی اغلب منجر به شکست در محیط عملیاتی میشود. به همین دلیل، یک رویکرد جایگزین پیشنهاد شده است. در یک آزمایش عملی، توسعهدهندهای یک سیستم چهار-درجهای را برای حل این ابهام آزمایش کرد. این رویکرد، ارزیابی را نه به عنوان یک «دسته چرخانِ عددی»، بلکه به عنوان چهار پرسش باینری (بله/خیر) مجزا میبیند. در واقع، این متدولوژی منطق «قبول/رد» باینریِ حسین را میپذیرد، اما به هر نوع شکست، نامی مشخص میدهد.
چارچوب چهار-درجهای ارزیابی
بر اساس مستندات این متدولوژی، بهجای محاسبه میانگین امتیازات، تعداد دفعات وقوع هر نوع خطای خاص شمارش میشود. در این سیستم هیچ مفهومی به نام «نیمهفاجعهبار» یا حد وسط وجود ندارد؛ سیستم فقط وقوع یا عدم وقوع خطا را میشمارد. این درجات به شرح زیر تعریف میشوند:
- فاجعهبار (FATAL): زمانی که یک تأیید اشتباه مستقیماً به مرحله بعدی جریان کاری منتقل میشود و هیچ انسانی فرصتی برای شناسایی و متوقف کردن آن ندارد.
- ریسکدار (RISKY): نتیجه اشتباه است، اما یک نقطه بازرسی انسانی (Human Checkpoint) همچنان باقی است که فرصت شکار خطا را فراهم میکند.
- از دست رفته (MISSED): موردی که سیستم باید آن را شناسایی و شکار میکرد، اما نتوانست.
- بیضرر (HARMLESS): مدل بیش از حد برای تأیید درخواست داده است؛ کاربر ممکن است کمی کلافه شود، اما هیچ آسیب عملی رخ نمیدهد.
این تفکیک دقیق، یک قانون انتشار شفاف ایجاد میکند: شرط لازم برای انتشار محصول، رسیدن به وضعیت «صفر فاجعهبار» (FATAL 0) است.
تأثیر بر تصمیمات واقعی
نامگذاری خطاها، نحوه انتخاب مدلها و تصمیم برای بازنشسته کردن کدهای قدیمی را تغییر میدهد. توسعهدهنده مذکور سه تصمیم استراتژیک را ردیابی کرد که در آنها «نام خطا» بسیار مهمتر از «امتیاز کلی» بود:
۱. انتخاب مدل: یک مدل ارزان با مدلی که سه برابر گرانتر بود مقایسه شد. مدل ارزان خطاهایی داشت، اما تمام آنها از نوع «گناهِ بیش از حد پرسیدن» یا همان بیضرر (HARMLESS) بودند. در سیستم امتیازدهی باینری ساده، هر دو مدل «بد» ارزیابی میشدند و توسعهدهنده احتمالاً برای رفع خطاها، هزینه مدل سه برابر گرانتر را میپذیرفت. اما چون خطاها «بیضرر» نامیده شدند، هر دو مدل در وضعیت FATAL 0 برابر شدند و مدل ارزان انتخاب شد.
۲. حکم بازنشستگی: یک طبقهبندیکننده مبتنی بر Regex (عبارات منظم) در ۷ مورد از ۱۵ سؤال خطا داشت. امتیاز باینری ۵۳٪ بسیار مبهم است و نمیگوید آیا کد باید حذف شود یا خیر. اما وقتی بررسی شد که این طبقهبندیکننده باعث ۳ خطای فاجعهبار (FATAL 3) شده است (مثلاً پیامهای چت را به اشتباه در دستهبندی نیازها قرار داده)، مشخص شد که این یک حادثه غیرقابل بازگشت است. در این سطح، حتی یک مورد خطا هم بیش از حد بود.
۳. تصمیم جایگزینی: تصمیم برای جایگزینی Regex بر اساس مقایسه دقت ۸۰٪ در مقابل ۵۳٪ نبود. بلکه بر اساس تقابل FATAL 0 (در مدل LLM) در مقابل FATAL 3 (در Regex) بود. اگرچه مدل LLM نیز ۳ سؤال را از دست داده بود، اما هر یک از آن شکستها از نوعی بود که انسان میتوانست آنها را خنثی و اصلاح کند.
دستاوردهای استراتژیک
این تغییر در رویکرد، تمرکز را از بنچمارکهای عددی به مدیریت ریسک منتقل میکند. وقتی خطاها نامگذاری شوند، ترتیب اصلاحات بدیهی میشود: ابتدا خطاهای فاجعهبار را حل کنید و خطاهای بیضرر را به حال خود بگذارید. قرار دادن تمام خطاها در یک دسته کلی مثل «۷ مورد بد»، تشخیص اینکه ابتدا چه چیزی باید اصلاح شود را غیرممکن میکند.
با ترکیب هشدار هامل حسین علیه مقیاسهای عددی و سیستم نامگذاری شکستها، توسعهدهندگان میتوانند سختگیریِ ارزیابی باینری را حفظ کنند بدون اینکه بافت و زمینه (Context) خطا را از دست بدهند. معیار اصلی برای نامگذاری ساده است: «آیا یک انسان میتواند این حادثه را خنثی کند؟» اگر پاسخ منفی است، خطا «فاجعهبار» است.
این همسویی با سایر نکات مقاله «محصول هوش مصنوعی شما به ارزیابی نیاز دارد» اثر حسین نیز مطابقت دارد؛ نکاتی مانند: ابتدا به ارزیاب (Grader) شک کنید، بپذیرید که رسیدن به ۱۰۰٪ پاس هدف نیست، و اطمینان حاصل کنید که یک متخصص دامنه (Domain Expert) مالک کلید پاسخها باشد. این هشدار در مورد ارزیابها با یافتههای ما همسو است که نشان میدهد چگونه داوران هوش مصنوعی ممکن است با اطمینان زیاد نتایج غلط ارائه دهند و معیارهای کیفیت را فریب دهند. همچنین، برای درک اهمیت ثبات در ارزیابی، میتوان به تأثیر ناپایداری مدلهای داور بر تصمیمات ادغام کد اشاره کرد که نشان میدهد عدم سازگاری در داوری میتواند منجر به خطاهای عملیاتی شدید شود. برای پیادهسازی این روش، با بازبینی مجموعه دادههای ارزیابی (Eval Set) فعلی خود شروع کنید و امتیازات عددی را با برچسبهای شکست بر اساس «قابلیت بازیابی توسط انسان» جایگزین کنید.
گام بعدی شما
- مجموعه دادههای ارزیابی (Eval Set) فعلی خود را بازبینی کنید.
- امتیازات عددی را با برچسبهای «قابلیت بازگشت توسط انسان» جایگزین کنید.
- اولویت اصلاحات را بر اساس حذف کامل خطاهای فاجعهبار تنظیم کنید.
اما مدیریت این خطاها تنها نیمی از مسیر است؛ برای درک اینکه چگونه میتوان نرخ توهم را در این مدلها به صفر رساند، تحلیل ما دربارهی RAG را بخوانید.
گفتگو