از دمو تا پروداکشن: راهنمای ساخت فیچر هوش مصنوعی واقعی
هوش مصنوعیخلاصهٔ کاملتر
نویسنده با یه صحنهٔ آشنا شروع میکنه: یه فیچر هوش مصنوعی توی دمو عالی کار میکنه و همه ذوقزدهان، ولی موقع تست قبل از شیپ همهچی به هم میریزه. لتنسی روی موبایل میره رو ۱۰ ثانیه، مدل روی حالتهای مرزی توهم میزنه و چون خروجی هوش مصنوعی غیرقطعیه، تست A/B هیچ سیگنال معناداری نمیده. به گفتهٔ نویسنده این معمولاً مشکل مدل نیست، مشکل نبود نظم مهندسیه و شیپ کردن محصول هوش مصنوعی کاملاً با نرمافزار سنتی فرق داره.
اولین بحث، بودجهٔ لتنسیـه. نویسنده میگه اشتباه رایج اینه که تیمها فقط p50 رو اندازه میگیرن؛ یه فیچر با p50 برابر ۸۰۰ میلیثانیه ممکنه p90 اش ۱۵ ثانیه باشه، یعنی ۱۰ نفر از هر ۱۰۰ نفر منتظر میمونن. پیشنهادش اینه که بودجهٔ لتنسی رو بر اساس نوع تعامل تعریف کنی: تعامل همگام زیر ۱ ثانیه، تعامل تدریجی با اولین توکن زیر ۵۰۰ میلیثانیه، و تعامل ناهمگام تا ۲۰ ثانیه با نشانگر پیشرفت. cold start رو هم باید جدا اندازه گرفت و کل پایپلاین رو دید، نه فقط inference.
بخش بعدی طراحی fallbackـه. چون فیچرهای هوش مصنوعی به شکلهای عجیب و خلاقانه شکست میخورن، نویسنده یه سلسلهمراتب پیشنهاد میده: اول افت به یه مدل سادهتر و سریعتر، بعد سرو کردن جواب از کش برای پرسوجوهای مشابه، بعد قالبهای آماده، و آخر سر هم اینکه گاهی بهترین کار اینه که اصلاً اون فیچر رو نشون ندی. اصل زیربنایی اینه که کاربر هیچوقت نباید با یه خطای هندلنشدهٔ هوش مصنوعی روبهرو بشه.
برای اندازهگیری کیفیت نویسنده یه هرم چهارلایه میچینه: پایهاش ایمنیه که غیرقابلمذاکرهست و با کلسیفایرهای خودکار روی ۱۰۰٪ خروجیها چک میشه؛ بعد درستی واقعی که حوزهمحوره؛ بعد مفید بودن که با نرخ پذیرش و زمان انجام کار سنجیده میشه؛ و آخر سر لذت که سختترین لایه برای اندازهگیریه ولی برای پذیرش محصول خیلی مهمه.
نویسنده میگه تست A/B روی هوش مصنوعی ذاتاً سختتره چون واریانس بالای خروجی، حجم نمونهٔ لازم رو سه تا پنج برابر میکنه. پیشنهادش اینه که دو-سه برابر زمان و ترافیک بیشتر بذاری، از روشهای Bayesian استفاده کنی و همیشه تست کمی رو با مصاحبهٔ کیفی کاربر ترکیب کنی. در کنارش مانیتورینگ drift رو هم لازم میدونه: دادهها، رفتار کاربر و حتی رفتار APIهای طرفسوم با گذشت زمان عوض میشن؛ مثلاً رفتار GPT-4 بین مارس و ژوئن ۲۰۲۳ بهطور قابلاندازهگیری تغییر کرد، پس بهتره نسخهٔ مدل رو pin کنی تا آپدیتها سر وقت خودت اعمال بشن.
در آخر نویسنده تأکید میکنه پرامپت تو پروداکشن خودش یهجور برنامهنویسیه: باید نسخهبندی، تست، مانیتورینگ و نگهداری بشه و به جای hardcode کردن کانتکست، به شکل قالب با نقطههای تزریق مشخص ساخته بشه. حرف کلیدیش اینه که این سیستمها افزونهٔ بعد از لانچ نیستن؛ هر فیچری که دیده شکست بخوره، با این فکر ساخته شده که «سختسازی پروداکشن رو بعداً اضافه میکنیم» و اون «بعداً» هیچوقت نمیرسه.
نکات کلیدی:
- بودجهٔ لتنسی رو بر اساس نوع تعامل تعریف کن و p90 رو هم ببین، نه فقط p50
- fallback رو سلسلهمراتبی بساز: مدل سادهتر، کش، قالب آماده، یا حذف کامل فیچر
- کیفیت رو چهارلایه بسنج: ایمنی، درستی، مفید بودن، لذت
- تست A/B هوش مصنوعی به ترافیک و زمان چند برابری و روشهای Bayesian نیاز داره
- drift مدل رو مدام مانیتور کن و نسخهٔ مدل رو pin کن
