از خودکارسازی تا تصمیم‌سازی: معماری سامانه‌های تصمیم‌یار

خودکارسازی و تصمیم‌سازی هوشمند دو هدف متفاوت دارند. خودکارسازی، کارِ مشخص و قاعده‌مند را سریع‌تر و بی‌خطاتر انجام می‌دهد. تصمیم‌یار، کیفیت انتخاب را در موقعیتی که پاسخ قطعی وجود ندارد بالا می‌برد. این تمایز با دسته‌بندی شناخته‌شده‌ای هم‌خوان است که کاربردهای سازمانی هوش مصنوعی را به خودکارسازی فرایند، بینش شناختی (تحلیل داده برای پیش‌بینی و پشتیبانی تصمیم) و تعامل شناختی تقسیم می‌کند (Davenport & Ronanki, 2018). سازمانی که این دو را یکی بگیرد، ممکن است ابزار خودکارسازی بخرد و انتظار بهبود تصمیم داشته باشد.

تفاوت در جنس مسئله

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

اشتباه گرفتن این دو، هزینه دارد: قاعده‌گذاری برای مسئله نامطمئن، سازمان را در برابر استثناها شکننده می‌کند؛ و استفاده از مدل برای مسئله قاعده‌مند، پیچیدگی بی‌دلیل می‌سازد. در مطالعه RAND نیز به کار گرفتن یادگیری ماشین برای مسئله‌ای که با چند قاعده ساده «اگر-آنگاه» حل‌شدنی بود، یکی از الگوهای شکست گزارش شده است (Ryseff et al., 2024).

چهار لایه معماری تصمیم‌یار

لایه یک: داده

داده‌های عملیاتی از سامانه‌های مبدا به یک لایه پایدار منتقل می‌شوند؛ با تعریف مشخص، تاریخچه و کیفیت پایش‌شده. اگر این لایه ناپایدار باشد، هر چیزی که بالای آن ساخته شود با تغییر سامانه مبدا آسیب‌پذیر است؛ وابستگی‌های داده‌ای ناپایدار از منابع شناخته‌شده بدهی فنی در سامانه‌های یادگیری ماشین‌اند (Sculley et al., 2015).

لایه دو: مدل

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

لایه سه: قاعده کسب‌وکار

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

لایه چهار: تجربه تصمیم‌گیر

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

ترتیب ساخت

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

1. انتخاب یک تصمیم پرتکرار با اثر مالی قابل اندازه‌گیری.
2. ثبت وضعیت فعلی: امروز این تصمیم چگونه و بر چه پایه‌ای گرفته می‌شود.
3. ساخت کم‌ترین نسخه کارآمد از چهار لایه، حتی با قاعده ساده به‌جای مدل.
4. سنجش اثر، سپس افزودن مدل تنها اگر قاعده ساده کافی نبود.

سنجه درست چیست؟

دقت مدل، سنجه پروژه نیست. سنجه پروژه، تغییر در نتیجه کسب‌وکار است: کاهش زمان بررسی پرونده، کاهش موجودی راکد، افزایش نرخ تایید درست. مدلی با دقت متوسط که در فرایند مصرف می‌شود، از مدلی با دقت بالا که کسی به آن نگاه نمی‌کند ارزشمندتر است. RAND هم بهینه‌سازی مدل برای سنجه نادرست و ناهماهنگی با گردش کار را از علت‌های ریشه‌ای شکست می‌داند (Ryseff et al., 2024). ادبیات تصمیم‌گیری داده‌محور نیز ارزش را در سطح عملکرد بنگاه می‌سنجد، نه در سطح دقت ابزار (Brynjolfsson et al., 2011).

پذیرش، بخشی از معماری است

اگر کارشناس به پیشنهاد سامانه اعتماد نکند، آن را دور می‌زند. پژوهش‌های تجربی نشان داده‌اند که افراد پس از دیدن خطای یک الگوریتم، حتی اگر الگوریتم از پیش‌بینی انسانی بهتر باشد، تمایل دارند از آن کناره بگیرند (Dietvorst et al., 2015)؛ و وقتی امکان اصلاح هرچند اندک خروجی را داشته باشند، بیشتر از آن استفاده می‌کنند (Dietvorst et al., 2018). پس اعتماد با شفافیت و کنترل ساخته می‌شود: نشان دادن دلیل، امکان رد یا اصلاح پیشنهاد و ثبت بازخورد. همین بازخورد است که چرخه بهبود را می‌بندد و سازمان را از خرید یک‌باره فناوری، به ساختن قابلیت پایدار می‌رساند.

منابع

• Brynjolfsson, E., Hitt, L. M., & Kim, H. H. (2011). Strength in numbers: How does data-driven decisionmaking affect firm performance? (Working paper). SSRN. https://doi.org/10.2139/ssrn.1819486
• Davenport, T. H., & Ronanki, R. (2018). Artificial intelligence for the real world. Harvard Business Review, 96(1), 108–116.
• Dietvorst, B. J., Simmons, J. P., & Massey, C. (2015). Algorithm aversion: People erroneously avoid algorithms after seeing them err. Journal of Experimental Psychology: General, 144(1), 114–126. https://doi.org/10.1037/xge0000033
• Dietvorst, B. J., Simmons, J. P., & Massey, C. (2018). Overcoming algorithm aversion: People will use imperfect algorithms if they can (even slightly) modify them. Management Science, 64(3), 1155–1170. https://doi.org/10.1287/mnsc.2016.2643
• Ryseff, J., De Bruhl, B. F., & Newberry, S. J. (2024). The root causes of failure for artificial intelligence projects and how they can succeed: Avoiding the anti-patterns of AI (RR-A2680-1). RAND Corporation. https://doi.org/10.7249/RRA2680-1
• Sculley, D., Holt, G., Golovin, D., Davydov, E., Phillips, T., Ebner, D., Chaudhary, V., Young, M., Crespo, J.-F., & Dennison, D. (2015). Hidden technical debt in machine learning systems. In Advances in Neural Information Processing Systems 28 (pp. 2503–2511).