وقتی هوش مصنوعی جواب قانع کننده می دهد، چرا هنوز باید شک کنیم؟

یکی از دشوارترین مهارت های دوران هوش مصنوعی این است که بتوانیم از یک پاسخ خوب لذت ببریم، بی آنکه بی دلیل به آن اعتماد کنیم. سیستم در چند ثانیه متنی مرتب می نویسد، استدلال می آورد و حتی با لحنی مطمئن اشتباه ما را اصلاح می کند. طبیعی است که گاهی احساس کنیم با یک متخصص روبه رو هستیم.

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

روان حرف زدن همان درست فهمیدن نیست

مدل های زبانی از الگوهای گسترده متن و داده یاد گرفته اند. به همین دلیل می توانند ارتباط های ظریفی میان مفاهیم برقرار کنند و در بسیاری از کارها بسیار مفید باشند. با این حال، تولید یک توضیح قابل قبول تضمین نمی کند که مدل به داده درست دسترسی داشته، محدودیت پرسش را رعایت کرده یا محاسبه را به روش مجاز انجام داده است.

مثالی ساده بزنم. اگر بپرسید «فروش دو فصل اول امسال چرا افت کرده؟» ممکن است مدلی که به داده سازمان وصل نیست، درباره رکود بازار و رفتار مشتریان توضیح مفصلی بدهد. تمام این توضیح شاید معقول باشد، اما هنوز نمی دانیم فروش واقعا افت کرده یا نه. حتی اگر افت کرده باشد، علتش ممکن است تغییر تعریف محصول یا ناقص بودن داده باشد.

در چنین موقعیتی باید ترتیب کار را عوض کنیم: اول عدد را از منبع معتبر بگیریم، بعد تغییر را با دوره قابل مقایسه بسنجیم، سپس فرضیه بسازیم. هوش مصنوعی می تواند در مرحله سوم کمک بزرگی باشد، اما نباید مرحله اول را با حدس جایگزین کند.

اعتماد را به چند بخش بشکنید

به جای پرسیدن «آیا به این مدل اعتماد کنیم؟» مشخص کنید برای کدام کار، با چه مدرکی و تا چه حد می توان به آن تکیه کرد. ممکن است یک سیستم برای خلاصه کردن صورت جلسه مناسب باشد و برای تایید وام اختیار لازم را نداشته باشد. حتی در یک کاربرد ثابت، اعتبار پاسخ ها یکسان نیست.

در سامانه ای که بر اسناد شرکت تکیه دارد، باید بتوان دید پاسخ به کدام سند، نسخه و بخش متکی است. در کاری که محاسبه مالی دارد، بهتر است محاسبه را کد قطعی انجام دهد و مدل زبانی فقط نتیجه را توضیح دهد. در تصمیم هایی که اثر حقوقی یا انسانی دارند، باید فرد مسئول بتواند دلیل، محدودیت و مسیر اعتراض را ببیند.

این کار سرعت را از بین نمی برد. برعکس، به ما اجازه می دهد از سرعت سیستم استفاده کنیم بدون آنکه هزینه خطا را پنهان کنیم.

تمرین ساده برای تیم ها

دفعه بعد که یک پاسخ عالی از هوش مصنوعی گرفتید، پیش از استفاده سه چیز را بررسی کنید: داده اصلی از کجا آمده، کدام بخش نتیجه واقعیت قابل اثبات است و کدام بخش تفسیر، و اگر جواب غلط باشد چه کسی متوجه می شود؟

از کارکنان هم بخواهید یکی از پاسخ های قانع کننده اما نادرست سیستم را در جلسه آموزشی بررسی کنند؛ نه برای تحقیر فناوری، بلکه برای یاد گرفتن مرز کاربرد آن. چنین نمونه ای گاهی بیش از ده اسلاید درباره مزایای هوش مصنوعی به یک سازمان کمک می کند.

مسئله فقط خطای آشکار نیست

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

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

منبع داشتن با درست بودن یکی نیست

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

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

اعتماد را متناسب با پیامد تنظیم کنید

سطح اختیار باید با پیامد خطا و امکان جبران آن متناسب باشد. خطای پیش نویس یک پیام داخلی معمولا با بازخوانی جبران می شود؛ اما خطا در بررسی اعتبار مشتری، انتخاب متقاضی استخدام یا توصیه درمانی پیامد دیگری دارد. اعتماد مطلق و بی اعتمادی مطلق هر دو مدیریت را از تصمیم دقیق دور می کنند.

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

آزمون خوب چگونه ساخته می شود؟

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

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

سواد تازه مدیران

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

چه زمانی باید از مدل سوال نکنیم؟

گاهی مسئله اصلا به زبان طبیعی نیاز ندارد. اگر می خواهیم مانده حساب، نرخ مصوب یا تعداد پرونده های یک دوره را بدانیم، مرجع عددی مشخص از پاسخ احتمالی یک مدل معتبرتر است. می توان از مدل برای فهمیدن سوال و توضیح نتیجه کمک گرفت، اما محاسبه باید در ابزار قابل رسیدگی انجام شود. شناخت این مرز نشانه محدودیت فناوری نیست؛ نشانه طراحی درست خدمت است. کاربر باید بداند عدد را چه سامانه ای محاسبه کرده و متن توضیح را چه ابزاری ساخته است.

پیشرفت واقعی زمانی است که کارکنان هم توانایی سیستم را بشناسند و هم نقطه ای را که باید بگویند «بگذارید بررسی کنم».