معنی «انجام‌شده» وقتی فیچر هوش مصنوعی شیپ می‌کنی
هوش مصنوعیخلاصهٔ کامل‌تر
نویسنده با یادآوری «روزهای خوب قدیم» شروع می‌کنه: مهندسی می‌گفت یه چیزی رو شیپ کرده، همه‌ی تست‌ها پاس شده، باگ بحرانی نبود و دمو عالی کار کرد، و «طبق طراحی کار می‌کنه» یعنی تموم. ولی می‌گه با هوش مصنوعی دیگه این سادگی رو نداریم. تعریف «done» همیشه مشکل بوده، ولی برای هوش مصنوعی باید کاملاً بازنویسی بشه.
تعریف‌های ما برای نرم‌افزار قطعی (deterministic) ساخته شدن: ورودی می‌ره تو، خروجی می‌آد بیرون، و خروجی سه‌شنبه همونیه که دوشنبه بود. نرم‌افزار مثل دستگاه فروش خودکار رفتار می‌کرد. ولی فیچرهای هوش مصنوعی این‌طوری نیستن؛ یه پرامپت ثابت بین کاربرها، نشست‌ها، آپدیت‌های مدل و بافت‌هایی که تیم QA حتی تصورشون رو نکرده، خروجی‌های متفاوت می‌ده. چیزی که شیپ کردی یه آبجکت ثابت و قابل‌پیش‌بینی نیست، یه توزیع از رفتارهاست که بیشترِ سورپرایزها توی همون بخش‌هایی‌ان که ندیدی. پس «همه‌ی تست‌ها پاس شدن» هنوز مهمه، ولی دیگه معنیِ «done» نمی‌ده.
قدم اول: معیارهای پذیرش رو به‌جای گزاره (assertion) به شکل توزیع بنویس. به‌جای «وقتی کاربر X رو وارد کرد، سیستم Y رو برمی‌گردونه»، این قاب رو امتحان کن: «برای ۸۰ درصد ورودی‌های دسته‌ی X، سیستم جوابی می‌ده که سطح کیفیت Y رو داره؛ برای اون ۲۰ درصد بقیه، حالت شکست تنزل‌یافته‌ست ولی شرم‌آور نیست». تیم‌هایی که این رو درست انجام می‌دن دو دسته معیار دارن: معیارهای قطعی برای بخش‌هایی که هنوز مثل دستگاه فروش خودکارن (مثل احرازهویت، صورت‌حساب، ناوبری) و معیارهای توزیعی برای بخش‌هایی که این‌طوری نیستن.
قدم دوم: ظرفیت تریاژ خطا رو موقع عرضه بساز، نه بعدش. روال سنتی این بود که فیچر رو شیپ کنی، داشبورد رو نگاه کنی و وقتی شکایت‌ها به حد قابل‌توجهی رسید تریاژ کنی. برای هوش مصنوعی این خیلی کنده. باید قبل از عرضه، playbook تریاژ رو بنویسی و معلوم کنی کی مالک مشکلات کیفیت مدل، مشکلات UX و مشکلات محتواست. عرضه فقط زنده شدن فیچر نیست؛ عرضه لحظه‌ایه که تیمی که قراره با عواقب روبه‌رو بشه واقعاً آماده‌ست.
قدم سوم: سیگنالی که یعنی «این فیچر در واقع تموم نشده» رو تعریف کن و rollback رو تمرین کن. هر فیچر هوش مصنوعی باید با یه tripwire عرضه بشه؛ هر متریکی که برای محصولت معنی داره، مثل نرخ خطا، تعداد شکایت‌های بدلحن، یا نرخ توهم (hallucination). آستانه رو تعیین کن و از قبل تصمیم بگیر وقتی رد شد چی‌کار می‌کنی. مهم‌تر اینکه rollback رو نه روی کاغذ، بلکه واقعاً اجرا و تمرین کن، چون لحظه‌ای که می‌فهمی rollbackت کار نمی‌کنه، معمولاً همون لحظه‌ایه که بیشتر از همیشه بهش نیاز داری.
نویسنده استدلال Lean UX رو برای عصر هوش مصنوعی به‌روز می‌کنه: قبلاً می‌گفتن خروجی‌ها با نتیجه فرق دارن؛ شیپ کردن فیچر مثل موفق شدن مشتری نیست. نسخه‌ی هوش مصنوعیش سخت‌تره: شیپ کردن فیچر حتی شیپ کردن فیچر هم نیست، چون چیزی که شیپ کردی یه توزیع از رفتارهای غیرقابل‌پیش‌بینیه که بعد از deploy هم سورپرایز تولید می‌کنه. اون می‌گه اگه «done» زبون فرهنگ ساختن بود، «calibrated» (کالیبره‌شده) زبون فرهنگ یادگیریه؛ و دومی رو انتخاب کن.
نکات کلیدی:
- فیچر هوش مصنوعی یه آبجکت ثابت نیست، یه توزیع از رفتارهاست، پس تعریف «done» باید عوض بشه
- معیارهای پذیرش رو به شکل توزیع بنویس، نه گزاره‌ی باینری؛ معیار قطعی و توزیعی رو از هم جدا کن
- ظرفیت تریاژ خطا و مالکیتش رو قبل از عرضه آماده کن، نه بعد از شکایت کاربر
- برای هر فیچر یه tripwire بذار و rollback رو واقعاً تمرین کن، نه فقط روی کاغذ
