چرا ارزیابی خروجی هوش مصنوعی مثل تست‌نویسی نرم‌افزار نیست

اولین چیزی که هر تیمی یاد می‌گیرد این است که تست‌های مبتنی بر برابری رشته‌ای برای خروجی مدل زبانی تقریباً همیشه شکست می‌خورند یا بی‌فایده می‌شوند. اگر assert شما دقیقاً یک جمله را انتظار دارد، یا تست‌تان همیشه رد می‌شود (چون مدل جمله را کمی متفاوت می‌نویسد) یا آن‌قدر آزاد می‌شود که هر چیزی را قبول می‌کند (چون فقط طول یا وجود یک کلمه را چک می‌کند). هیچ‌کدام از این‌ها اطلاعات مفیدی نمی‌دهد.

جایگزینش سنجش کیفیت با معیارهای معنایی است، نه تحت‌اللفظی: آیا پاسخ حاوی واقعیت‌های درست است؟ آیا لحن و ساختار مناسب است؟ آیا چیزی که نباید بگوید، گفته است؟ این‌ها سؤال‌هایی هستند که یا یک قاعدهٔ ساخته‌شده با دقت می‌تواند بسنجد، یا یک انسان، یا (با احتیاط) یک مدل دیگر که نقش داور را بازی می‌کند.

هر فرآیند ارزیابی جدی با یک مجموعهٔ آزمون طلایی (golden set) شروع می‌شود: مجموعه‌ای از ورودی‌های واقعی، همراه با پاسخ‌های قابل‌قبول یا معیارهای سنجش، که هر تغییر در سامانه — چه در پرامپت، چه در مدل، چه در منطق پیرامونش — در برابر آن اجرا می‌شود. کیفیت این مجموعه از هر بخش دیگر فرآیند ارزیابی مهم‌تر است، چون مجموعه‌ای که ورودی‌های ساده و ایمن را پوشش می‌دهد ولی مواردِ مرزی را ندارد، دقیقاً همان جایی که شکست‌ها اتفاق می‌افتند را نادیده می‌گیرد.

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

وقتی پاسخ درست یک رشتهٔ ثابت نیست، راه عملی سنجش کیفیت، تعریف یک روبریک است: فهرستی صریح از معیارهایی که یک پاسخ خوب باید داشته باشد، هرکدام با وزن مشخص. برای مثال: آیا واقعیت‌های ادعاشده درست‌اند؟ آیا پاسخ به سؤال واقعی مربوط است؟ آیا از دادن اطلاعات نادرست با اطمینان کاذب پرهیز کرده؟ آیا طول و لحنش مناسب زمینه است؟

روبریک باید قبل از دیدن خروجی‌های واقعی نوشته شود، نه بعدش — وگرنه وسوسهٔ تنظیم معیارها برای توجیه پاسخی که از قبل تولید شده، ارزیابی را بی‌ارزش می‌کند. و روبریک باید به اندازه‌ای دقیق باشد که دو ارزیاب مستقل (چه انسان، چه مدل) روی همان پاسخ به نمرهٔ نزدیک به هم برسند؛ اگر دو ارزیاب دربارهٔ یک روبریک واحد به‌شدت اختلاف دارند، خودِ روبریک مبهم است.

یک روبریک کوچک و عمومی معمولاً این شکلی است — نه به‌عنوان یک قالب نهایی، بلکه به‌عنوان نقطهٔ شروع برای هر تیمی که هنوز روبریک ندارد:

نکتهٔ مهم این نیست که این وزن‌ها درست‌اند؛ نکته این است که هر کدام صریح، قابل‌مشاهده و قابل‌بحث‌اند — دقیقاً برخلاف یک قضاوت کلی و ضمنی مثل «به نظر خوب می‌رسید».

استفاده از یک مدل زبانی به‌عنوان داور برای سنجش خروجی مدل دیگر، وسوسه‌انگیز است چون سریع و ارزان است — اما یک تلهٔ خاص دارد که باید صریح به آن توجه کرد: مدل‌ها تمایل دارند خروجی‌هایی را که به سبک خودشان نزدیک‌تر است، بهتر نمره بدهند، حتی وقتی از نظر واقعیت یا کیفیت واقعی فرقی ندارند. اگر مدلی که برای تولید استفاده می‌کنید همان مدلی باشد که برای داوری استفاده می‌کنید، این سوگیری تشدید می‌شود: مدل عملاً دارد به کار خودش امتیاز می‌دهد.

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

بازبینی انسانی نباید چیزی باشد که فقط وقتی خروجی «مشکوک به نظر می‌رسد» فعال می‌شود؛ باید یک مرحلهٔ ثابت در فرآیند باشد، با یک نمونهٔ مشخص از هر دسته خروجی — نه فقط مواردی که سامانه تشخیص داده مشکوک‌اند، چون سامانه دقیقاً همان چیزهایی را که نمی‌بیند، نمی‌تواند علامت بزند. یک نمونهٔ تصادفی منظم از خروجی‌های «سالم به نظر می‌رسند» باید همان‌قدر بازبینی شود که موارد علامت‌خورده، چون شکست‌های خاموش — پاسخی که درست به نظر می‌رسد اما نیست — دقیقاً همان‌هایی هستند که هیچ قاعدهٔ خودکار پیدایشان نمی‌کند.

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

یکی از عجیب‌ترین تفاوت‌های ارزیابی هوش مصنوعی با تست نرم‌افزار این است که کد شما می‌تواند بدون تغییر بماند و رفتارش عوض شود، چون تأمین‌کننده مدل زیرین را به‌روزرسانی کرده. این نوع رگرسیون در تست سنتی اصلاً معنا ندارد — کد ثابت رفتار ثابت تولید می‌کند مگر یک وابستگی عوض شود، و آن وابستگی معمولاً نسخه‌بندی و قفل‌شده است. مدل‌های میزبانی‌شده این‌طور نیستند؛ نسخه‌ای که پشت یک نام API قرار دارد می‌تواند بدون اطلاع‌رسانی صریح تغییر کند.

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