جدول امتیازدهی تصمیم هوش مصنوعی چه چیزهایی را جا می اندازد؟

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

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

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

ستون های خالی را وارسی کنید

این جدول امتیاز تازه ای به مدل اضافه نمی کند. کمک می کند محدودیت های خود مدل را ببینیم و برای هر شکاف کاری عملی تعیین کنیم.

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

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

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

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

هزینه ۷ از ۱۰ که برآورد شده، هم وزن کنترل امنیتی آزموده شده نیست. اگر اختلاف تصمیم به یک مورد نامعلوم وابسته است، آن را پشت میانگین پنهان نکنید. پاسخ را پیدا کنید، اجرای آزمایشی انجام دهید، ریسک را آگاهانه بپذیرید یا فعلا پیش نروید.

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

اختلاف نظر را میانگین نگیرید

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

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

شهود مدیر باتجربه هم نه وتوی خودکار است و نه چیزی برای نادیده گرفتن. آن را به پرسش تبدیل کنید: از چه پیامدی نگرانم؟ کدام فرض باید غلط باشد تا آن پیامد رخ دهد؟ چه تجربه یا مدرکی این نگرانی را ساخته؟ آیا می توانیم آن را آزمایش کنیم؟

گزینه های بیشتری روی میز بگذارید

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

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

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

عمق بررسی را با پیامد هماهنگ کنید

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

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

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

سابقه تصمیم، عدم قطعیت را هم نگه دارد

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

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

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

تصمیم گیری بالغ ابهام را حذف نمی کند. آن را دیدنی می کند تا تیم بتواند بفهمد چه چیزی را می داند، چه چیزی را هنوز نمی داند و چطور می خواهد یاد بگیرد.

مهدی لطفی نژاد متخصص داده و هوش مصنوعی، مشاور و مدرس رسمی با نزدیک به ۲۰ سال تجربه صنعتی است. او به صدها متخصص در خاورمیانه و جنوب شرق آسیا آموزش داده و در DATATWEETS می نویسد تا این تجربه عملی را رایگان و خودآموز در اختیار همه بگذارد.