اگر نمیتوانید دقیقاً بگویید چه پاسخی از مدل شما «خوب» است، هرگز نخواهید فهمید که آیا قابلیتهای هوش مصنوعی شما در بهروزرسانی جدید بدتر شده است یا خیر. طبق راهنمایی که در ۱ سپتامبر ۲۰۲۶ در وبسایت dev.to منتشر شد، اکثر تیمها بر اساس معیارهای ذهنی و شخصی ارزیابی میکنند و همین موضوع باعث میشود هنگام ارتقای مدل، دچار تضاد در تشخیص کیفیت شوند. وقتی تیمی نمیتواند به این سؤال پاسخ دهد، دلیل آن سهلانگاری نیست، بلکه به این دلیل است که استاندارد کیفیت هرگز بهصورت مکتوب تعریف نشده است.
این شکاف به این دلیل ایجاد میشود که تیمها معمولاً زیرساختهای ارزیابی را به تعریف «موفقیت» ترجیح میدهند. در یک محیط عملیاتی، داشبوردی که نمراتی در حال تغییر را نشان میدهد بیمعنی است، مگر اینکه تیم روی معیارهای پاسخ صحیح توافق کرده باشد. نمرهای که پشتوانه تعریفی ندارد، صرفاً عددی است که جابهجا میشود، نه یک مدرک فنی.
زمینه ارزیابی
ارزیابی اغلب به اشتباه یک مسئله زیرساختی دیده میشود؛ در حالی که ابزارهای ارزیابی (Harness) تنها ماشینِ اجرا هستند و ارزش واقعی در تعریفی است که به این ماشین میدهید. همانطور که در بحثهای گذشتهی ما دربارهی امنیت مدلهای بازمتن اشاره کردیم، ابزار بدون استراتژی، تنها سرعتِ اشتباه را افزایش میدهد.
بسیاری از تیمها مسیر را برعکس طی میکنند: ابتدا پلتفرمی میخرند، اعدادی تولید میکنند و سپس میبینند که اعضای تیم هنوز بر سر معنای آن اعداد توافق ندارند. به همین دلیل، شروع با یک رویکرد دستی و در مقیاس کوچک، بسیار مؤثرتر از شروع با یک ابزار پیچیده است. برای ساخت اولین مجموعه ارزیابی، نویسنده پیشنهاد میکند به جای پلتفرمهای پیچیده، از یک جدول ساده و یک بعدازظهر وقت بگذارید.
این فرآیند شامل سه گام مشخص است:
جزئیات فرآیند
- استخراج لاگها: ۲۰ گفتگوی واقعی از ماه گذشته را استخراج کنید. از گفتگوهای «تمیز» دوری کنید. در عوض، روی مواردی تمرکز کنید که همکاران دربارهشان بحث کردهاند، مواردی که باعث ناراحتی همکاران شده است، یا مواردی که از نظر فنی درست بودند اما حس بدی منتقل میکردند.
- ایجاد استاندارد طلایی: هر گفتگو را در یک ردیف قرار دهید و در کنار آن، پاسخی را بنویسید که اگر مدل میداد، شما با خیال راحت آن را منتشر میکردید. این کار یک سند شامل ۲۰ ورودی و ۲۰ پاسخ ایجاد میکند که شما پشت آنها میایستید. این تعداد کم عمدی است؛ ۲۰ ردیفی که روی آنها فکر کردهاید، ارزشمندتر از ۲۰۰۰ ردیف تولید شده توسط هوش مصنوعی زاینده (Generative AI) — شبیه به کتابخانهداری که میلیاردها صفحه را خوانده و حالا با همان لحن جواب میدهد — است که هرگز آنها را نخواندهاید.
- تأیید متقابل: همین ۲۰ گفتگو را به شخص دیگری (مثلاً مؤسس، مدیر محصول یا سرپرست پشتیبانی که با رفتارهای عجیب عاملها سر و کار دارد) بدهید و از او بخواهید بدون دیدن پاسخهای شما، جوابهای ایدهآل را بنویسد.
اختلافات میان این دو مجموعه پاسخ، باگهای مهندسی نیستند، بلکه تصمیمات محصولیِ گرفتهنشدهاند. این تضادها تیم را مجبور میکند تا روی موازنههای حیاتی تصمیم بگیرند؛ مثلاً:
- اینکه چقدر صمیمیت در پاسخ در برابر دقت فنی اولویت دارد.
- آیا یک پاسخ اشتباه اما با اعتمادبهنفس، بدتر از یک پاسخ درست اما مبهم است.
- چه زمانی رد کردن یک درخواست «ایمن» است و چه زمانی صرفاً «آزاردهنده» است.
- آیا پاسخی که «به اندازه کافی نزدیک» است، قابل انتشار است یا خیر.
این پرسشها معمولاً زمانی ظاهر میشوند که یک مهندس در حال نوشتن کدِ ارزیاب است و به شکل سوالات فنی مطرح میشوند، اما در واقعیت، مالک محصول باید به آنها پاسخ دهد. تیم باید اختلافات را ردیف به ردیف حل کند و دلیل هر حکم را ثبت نماید. اگرچه حکم برای یک ردیف است، اما «دلیل» آن برای تمام ردیفهای مشابه کاربرد دارد و بخش قابل استفادهی این فرآیند است.
وقتی این ۲۰ ردیف با دلایل مکتوب تثبیت شوند، به یک محک (Benchmark) منجمد تبدیل میشوند. اگرچه ۲۰ ردیف نمیتوانند ثابت کنند که یک عامل (Agent) — سیستمی که میتواند برای رسیدن به هدف، بهطور مستقل تصمیم بگیرد و ابزارها را به کار بگیرد — کاملاً «خوب» است (چون این ردیفها فرضهای دو نفر را دارند و ممکن است شبیه دادههای ماه آینده نباشند)، اما برای پاسخ به این سوال حیاتی کافی هستند: «آیا دچار پسرفت شدهایم؟»
اجرای این مجموعه منجمد پس از هر تغییر در پرامپت یا ارتقای مدل، یک مقایسه عینی «قبل و بعد» فراهم میکند. این رویکرد تمرکز را از زیرساخت به کار اصلی، یعنی تعریف کیفیت محصول، منتقل میکند. بحثهایی که هنگام تعریف این معیارها رخ میدهد، اغلب ارزشمندتر از خودِ فایل نهایی است.
برای کسانی که به دنبال بررسی فنیتر مکانیسمهای اجرای این مجموعهها هستند، راهنمای میدانی Hamel Husain درباره ارزیابیها منبعی اصلی است. همچنین، راهنمای «چگونه بفهمیم عامل هوش مصنوعی شما واقعاً کار میکند؟» چهار تصمیم کلیدی را بررسی میکند که در این مسیر ظاهر میشوند. طراحی این تعاریف با تیمها، هسته اصلی فعالیتهای انجام شده در nugalaxy است.
گام بعدی شما
- ۲۰ مورد از بدترین یا عجیبترین پاسخهای مدل خود در ماه گذشته را استخراج کنید.
- یک جدول ساده بسازید و پاسخ «ایدهآل» را برای هر کدام بنویسید.
- این جدول را با مدیر محصول یا یک کاربر نهایی به اشتراک بگذارید تا نقاط اختلاف در تعریف «کیفیت» را پیدا کنید.
اما داستان سختافزاری این تحول حتی شگفتانگیزتر است — به تحلیل ما دربارهی تراشههای Blackwell مراجعه کنید.
گفتگو