یک جلسهٔ کاری بد پیش رفت. مشتری چیزی را روی صفحه دید که ما ندیده بودیم، و آن روز فهمیدم گزارشهای سیستم خودمان به من دروغ میگفتند — نه از سر خرابی، بلکه چون چیز اشتباهی را میشمردند.
بعد از آن جلسه نشستم و گفتگوهای واقعی مشتریها را از اول تا آخر خواندم. چیزی که پیدا شد، این نوشته است.
بیشتر چیزهایی که دربارهٔ خطرات ایجنت هوش مصنوعی نوشته میشود فهرستی از احتمالهاست. این یکی فهرست نیست؛ چهار چیزی است که واقعاً سرِ ما آمد.
بیشتر مطالبی که دربارهٔ «خطرات هوش مصنوعی» نوشته میشود فرضی است. این یکی نیست. چهار خرابی واقعی است از سیستمی که خودمان ساختهایم و در حال کار است، با ریشهٔ هر کدام و کاری که برای بستنش انجام شد.
مینویسمشان چون فکر میکنم مفیدترین چیزی که یک سازنده میتواند منتشر کند همین است، و چون هر چهارتا در هر سیستم دیگری هم میتوانند اتفاق بیفتند.
خرابی یک: پاسخ به زبان اشتباه
مشتری فارسی نوشته بود و سیستم انگلیسی جواب داده بود.
از بیرون این یک اشتباه کوچک به نظر میرسد. از نگاه مشتری اینطور نیست: پیامی که به زبان دیگری جواب بگیرد یعنی «این سیستم برای من ساخته نشده». طرف دیگر ادامه نمیدهد.
ریشه: تشخیص زبان به متن پیام نگاه میکرد، و متنی که پر از نشانی اینترنتی و عدد و نام لاتین بود، انگلیسی تشخیص داده میشد. مشتریای که لینک محصول میفرستد، دقیقاً همین حالت را میسازد.
چه شد: تشخیص زبان حالا آدرسها، ایمیلها، شناسهها و عددها را از متن بیرون میکشد و بعد قضاوت میکند. و مهمتر: پیش از فرستادن پاسخ، بررسی میشود که زبان جواب با زبان پرسش بخواند. اگر نخواند، یک بار دوباره ساخته میشود.
درسی که ماند: یک ایراد که در نود و پنج مورد پیش نمیآید، در آن پنج مورد کل رابطه را تمام میکند. و همان پنج مورد دقیقاً همانهاییاند که در آزمایشهای خودمان تکرارشان نمیکردیم.
خرابی دو: شمارهای که ذخیره نشد
مشتری در گفتگو شمارهاش را نوشته بود. سیستم پاسخ داده بود. شماره هیچجا ثبت نشده بود.
یعنی یک سرنخ کامل — کسی که خودش راه تماس داده — عملاً از دست رفته بود، و ما در گزارشها یک «گفتگوی موفق» دیده بودیم.
ریشه: هیچکس به سیستم نگفته بود شماره را نگه دارد. فرض شده بود اگر مشتری بخواهد تماس بگیرد، فرمی پر میکند. مشتری واقعی فرم پر نمیکند؛ شمارهاش را وسط جمله مینویسد.
چه شد: حالا هر پیامی که وارد میشود، بلافاصله بعد از شناسایی فرستنده، برای راههای تماس بررسی میشود و هرچه پیدا شود در پروندهٔ همان شخص مینشیند — پیش از آنکه پاسخی ساخته شود.
درسی که ماند: خطاهایی که هیچ خطایی تولید نمیکنند، خطرناکتریناند. هیچ چیز قرمز نشد، هیچ هشداری نیامد. فقط چند سرنخ آرام ناپدید شدند.
خرابی سه: پیام پیگیری برای رکوردهای آزمایشی
سیستم پیگیری، رکوردهای فنی و آزمایشی را هم آدم حساب کرده بود و برایشان پیام آماده میکرد.
ریشه: سیستم برای پیدا کردن «آدمها» در پایگاه داده میگشت، ولی چند نوع رکورد فنی هم آنجا بودند که شکلشان شبیه آدم بود. کسی فهرست کاملی از آنچه باید نادیده گرفته شود ننوشته بود.
چه شد: فهرست چیزهایی که باید رد شوند کامل شد، و کنارش یک بررسی دوم اضافه شد: پیش از هر پیام، تأیید میشود که گیرنده واقعاً یک شخص است و رکورد آزمایشی نیست.
درسی که ماند: هر جا سیستم دربارهٔ «همه» تصمیم میگیرد، باید دقیقاً معلوم باشد «همه» یعنی چه کسانی. این نوع خطا در آزمایش دیده نمیشود، چون در آزمایش داده تمیز است.
خرابی چهار: حدی که فقط توصیه بود
این یکی خرابی گزارششده نبود؛ چیزی بود که موقع بازبینی پیدا کردیم و بدترینشان است.
محدودیتهای سیستم — چه چیزی را نگوید، کجا بایستد — در متن دستور نوشته شده بودند. یعنی به سیستم گفته شده بود این کارها را نکن.
مسئله این است که متن دستور یک توصیه است. مدل معمولاً پیرویش میکند. «معمولاً» برای چیزی که آبروی کسبوکار به آن بسته است کافی نیست.
چه شد: دو چیز. اول، یک لایهٔ صریح اضافه شد که پیام کاربر را همیشه داده حساب میکند نه دستور — پس جملهای مثل «دستورهای قبلی را نادیده بگیر» یک متن است که دربارهٔ آن فکر میشود، نه فرمانی که اجرا شود. دوم، جایی که ممکن بود، محدودیت از توصیه به سازوکار منتقل شد: چیزی که سیستم به آن دسترسی ندارد را نمیتواند بگوید.
درسی که ماند: میان «به سیستم گفتهایم نگوید» و «سیستم نمیتواند بگوید» فاصلهای هست که فقط در بدترین روز دیده میشود.
چطور بررسیشان کردیم که دوباره برنگردند
گفتن «درست شد» آسان است. آنچه سختتر است این است که ثابت کنیم دوباره خراب نمیشود، و همین جایی است که بیشتر اصلاحها شکست میخورند: چیزی وصله میشود، سه ماه بعد کسی جای دیگری را عوض میکند و همان ایراد برمیگردد.
کاری که کردیم این بود: برای هر کدام از این چهار خرابی، آزمونی نوشته شد که همان حالت را بازسازی میکند. پیام فارسی پر از لینک. پیامی که شماره وسط جمله دارد. رکورد آزمایشی که شبیه آدم است. جملهای که میگوید دستورهای قبلی را نادیده بگیر.
این آزمونها پیش از هر انتشار خودکار اجرا میشوند. یعنی اگر روزی کسی — حتی خود ما — تغییری بدهد که یکی از این چهار حالت را دوباره بشکند، انتشار متوقف میشود.
چرا این را مینویسم: چون پرسشی است که خریدار باید بپرسد و تقریباً هیچوقت نمیپرسد. «چه خطایی داشتید» پرسش خوبی است. «چطور مطمئن شدید برنمیگردد» پرسش بهتری است، و جوابش نشان میدهد طرف مقابل مهندسی میکند یا وصله میزند.
سه خطای دیگر که در همان بازبینی دیدیم
کوچکتر بودند ولی همان جنس را داشتند — همه از فرضی که کسی ننوشته بود.
ساعتهای کاری با واقعیت نمیخواند. سیستم قرارهایی پیشنهاد میداد که در آن ساعتها کسی سر کار نبود، و روزهای هفته را هم مطابق تقویم کاری ایران نمیشناخت. اصلاح شد و در همان مجموعهٔ آزمونها قفل شد.
تاریخچهٔ قدیمی گفتگوها پاک میشد. برای صرفهجویی، پیامهای قدیمی پس از خلاصهشدن حذف میشدند. یعنی اگر روزی میخواستیم بفهمیم دقیقاً چه گذشته، دیگر امکانش نبود — و این دقیقاً همان کاری است که بعد از آن جلسهٔ بد لازم شد. حالا بهجای حذف، بایگانی میشوند.
خلاصهای که ساخته شده بود، در گزارش مثل پیامِ ارسالشده دیده میشد. یعنی چیزی که فقط برای حافظهٔ داخلی ساخته شده بود، در فهرست گفتگوها ظاهر میشد و میشد آن را با پیامی که واقعاً به مشتری رفته اشتباه گرفت. این خطای من در ابزار گزارشگیری بود، نه خطای سیستم — ولی همانقدر میتوانست به تصمیم غلط منجر شود.
آنچه در همهٔ این چهار مورد مشترک بود
هیچکدام از اینها را گزارشها نشان ندادند.
تعداد گفتگو خوب بود. زمان پاسخ خوب بود. نرخ خطا صفر بود. و در همان حال، مشتریای انگلیسی جواب گرفته بود، سرنخی گم شده بود، و محدودیتها فقط توصیه بودند.
همهشان با خواندن گفتگوهای واقعی پیدا شدند، نه با نگاهکردن به داشبورد. این سادهترین و بیرحمانهترین توصیهای است که دارم: بیست گفتگوی آخر را از اول تا آخر بخوانید. خودتان، نه کسی دیگر. هیچ گزارشی جای این کار را نمیگیرد.
این برای کسبوکار ایرانی یعنی چه
یک: از فروشنده بپرسید چه خرابیهایی داشتهاند و چه کردند. فروشندهای که میگوید هیچوقت مشکلی نداشته، یا سیستمش را جدی به کار نینداخته یا حقیقت را نمیگوید. من ترجیح میدهم با کسی کار کنم که خطاهایش را میشناسد.
دو: چندزبانه بودن را جدی امتحان کنید. در ایران پیامها فارسی و انگلیسی و فینگلیش قاطیاند و پر از لینک و عدد. همان چیزی که خرابی اول ما را ساخت. یک پیام فارسی همراه با لینک محصول بفرستید و ببینید چه میشود.
سه: مطمئن شوید راه تماس از دل گفتگو استخراج میشود. مشتری ایرانی فرم پر نمیکند؛ شمارهاش را وسط جمله مینویسد. سیستمی که منتظر فرم است، لیدهایی را از دست میدهد که خودشان راه تماس دادهاند.
چهار: بپرسید محدودیتها کجا نوشته شدهاند. اگر جواب «در پرامپت» بود، بدانید آن توصیه است نه قاعده. این تفاوت را با یک پرسش میشود سنجید: «اگر مشتری اصرار کند، باز هم نمیگوید؟»
جمعبندی
هیچکدام از این چهار خرابی بهخاطر مدل ضعیف نبود. هر چهارتا تصمیمهای مهندسی بودند که یا گرفته نشده بودند یا اشتباه گرفته شده بودند: چه چیزی را نگه داریم، چه کسی را آدم حساب کنیم، محدودیت را کجا بنویسیم، و پیام کاربر را داده بدانیم یا دستور.
و همهشان با یک کار پیدا شدند که هیچ هزینهای ندارد: خواندن آنچه واقعاً بین سیستم و مشتری گذشته است.
کاری که همین امروز میتوانید بکنید
اگر سیستمی دارید — مال ما یا هر کس دیگر — این چهار کار امروز شدنی است و هیچکدام هزینه ندارد:
۱. بیست گفتگوی آخر را بخوانید. خودتان، از اول تا آخر، بدون رد شدن. دنبال دو چیز بگردید: جایی که سیستم چیزی گفته که نباید، و جایی که مشتری چیزی خواسته که سیستم نفهمیده.
۲. یک پیام فارسی همراه با لینک بفرستید و ببینید به چه زبانی جواب میگیرید.
۳. شمارهتان را وسط یک جمله بنویسید و بعد بررسی کنید که آیا جایی ثبت شد یا نه.
۴. بپرسید «چقدر تخفیف میدهید؟» و بعد اصرار کنید. بار اول ممکن است درست جواب بدهد؛ بار سوم است که معلوم میشود حد در سازوکار بوده یا فقط در توصیه.
چهار کار، بیست دقیقه. اگر همهشان را گذراند، سیستم خوبی دارید. اگر نه، حالا میدانید دقیقاً چه چیزی را باید درست کنید — و این از هر گزارشی ارزشمندتر است.
جمعبندی: خطرات ایجنت هوش مصنوعی از جایی نمیآید که فکر میکنیم. از حدی میآید که نوشته نشده، و از خرابیای که کسی نمیبیندش.
اگر میخواهید بدانید تا کجا باید به چنین سیستمی اختیار داد، نوشتهٔ هوش مصنوعی عاملی چیست و کجا نباید به آن اختیار داد همان مرز را باز میکند، و ساخت ایجنت هوش مصنوعی نشان میدهد این شکافها از کجای کار وارد میشوند.