۱۱. خط لولهٔ ارزیابی (۲): روش، داده و ارزیابیِ ارزیابی

قدم ۳ — روش هر معیار

معیارهای مختلف روش‌های مختلف می‌خواهند. مثلاً برای سمّیت یک دسته‌بند کوچک تخصصی، برای ربط پاسخ به سؤال شباهت معنایی، و برای سازگاری پاسخ با کل زمینه یک هوش مصنوعی داور. راهنمای نمرهٔ روشن و مثال‌دار برای موفقیت داورهای تخصصی و هوش مصنوعی داور حیاتی است.

اگر logprob دارید، استفاده‌اش کنید. logprob نشان می‌دهد مدل دربارهٔ یک توکن چقدر مطمئن است — به‌خصوص برای دسته‌بندی مفید است. اگر از مدل خواسته‌اید یکی از سه دسته را بگوید و احتمال هر سه بین ۳۰ تا ۴۰ درصد است، مدل مطمئن نیست؛ اگر احتمال یکی ۹۵٪ است، خیلی مطمئن است. (در پروژهٔ فصل ۲، خروجی محدودشدهٔ ذهن‌یار دقیقاً از همین احتمال‌ها استفاده می‌کرد.) با logprob می‌شود سرگشتگی متن تولیدشده را هم حساب کرد، برای سنجیدن روانی یا سازگاری با واقعیت.

تا جای ممکن از سنجه‌های خودکار استفاده کنید، ولی از ارزیابی انسانی نترسید، حتی در محصول. خیلی از تیم‌ها ارزیابی انسانی را «ستارهٔ قطبی» توسعه می‌دانند: هر روز متخصص‌ها زیرمجموعه‌ای از خروجی‌های همان روز را می‌سنجند تا تغییر عملکرد یا الگوهای عجیب دیده شود. LinkedIn فرایندی ساخت که روزانه تا ۵۰۰ گفت‌وگو را دستی ارزیابی می‌کند. و به روش‌ها فقط برای مرحلهٔ آزمایش فکر نکنید: در محصول معمولاً پاسخ مرجع ندارید، ولی کاربر واقعی دارید؛ چه بازخوردی از او می‌خواهید و چطور به سنجه‌های دیگر ربطش می‌دهید؟ (فصل ۱۰)

دادهٔ ارزیابی

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

برش زدن داده

برش زدن یعنی داده را به زیرمجموعه‌ها تقسیم کنید و عملکرد سامانه را روی هر کدام جدا ببینید. چهار فایده دارد:

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

پارادوکس سیمپسون عجیب به نظر می‌رسد ولی واقعی است. این عددها از یک پژوهش پزشکی واقعی دربارهٔ درمان سنگ کلیه (۱۹۸۶) آمده‌اند؛ «مدل» را «روش درمان» بخوانید:

الف در هر دو گروه بهتر است، ولی در کل بدتر! راز در اندازهٔ گروه‌هاست: بیشتر نمونه‌های الف از گروه ۲ — که سخت‌تر است — آمده‌اند و بیشتر نمونه‌های ب از گروه ۱ آسان. عدد کلی، آسانی و سختی را با کیفیت مدل قاطی کرده. بدون برش، مدل بدتر را انتخاب می‌کردید.

چند نمونه کافی است؟

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

1. ۱۰۰ نمونه با جایگذاری از همان ۱۰۰ نمونهٔ اصلی بردارید — یعنی بعضی نمونه‌ها چند بار می‌آیند و بعضی اصلاً نه.
2. مدل را روی این ۱۰۰ نمونه بسنجید و نتیجه را یادداشت کنید.

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

نتیجهٔ ارزیابی فقط برای سنجیدن یک سامانه نیست؛ برای مقایسه هم هست: کدام مدل، کدام پرامپت؟ اگر پرامپت تازه ۱۰٪ بهتر نمره گرفته، مجموعه چقدر باید بزرگ باشد تا مطمئن شویم واقعاً بهتر است؟ در تئوری آزمون معناداری آماری جواب می‌دهد، ولی در عمل توزیع واقعی نمره‌ها را نمی‌دانیم. OpenAI یک تخمین سرانگشتی داده:

قاعدهٔ به‌خاطرسپردنی: هر بار اختلاف ۳ برابر کوچک‌تر شود، ۱۰ برابر نمونه لازم است (چون جذر ۱۰ حدود ۳٫۳ است). برای مقایسه: میانهٔ تعداد نمونه در آزمون‌های lm-evaluation-harness ۱٬۰۰۰ است و میانگینش ۲٬۱۵۹. برگزارکنندگان جایزهٔ Inverse Scaling گفتند ۳۰۰ نمونه حداقل مطلق است و ترجیحاً دست‌کم ۱٬۰۰۰ — به‌خصوص اگر نمونه‌ها مصنوعی ساخته شده باشند.

ارزیابیِ خود خط لوله

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

تکرار — با دفترچهٔ آزمایش

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

جمع‌بندی فصل

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

ارزیابی این‌جا تمام نمی‌شود: فصل ۶ بازیابی و ایجنت را می‌سنجد، فصل‌های ۷ و ۹ حافظه، تأخیر و هزینه را، فصل ۸ کیفیت داده را، و فصل ۱۰ بازخورد کاربر را. بعد از پروژهٔ این فصل، سراغ کاری می‌رویم که خیلی‌ها با مهندسی هوش مصنوعی یکی می‌دانند: مهندسی پرامپت.

خودآزمایی