orivo

مدیریت تحول

چرا پروژه‌های هوش مصنوعی سازمانی شکست می‌خورند؟

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

محمد امین هادئی۸ دقیقه مطالعه

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

الگوی یک: مسئله مالک ندارد

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

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

الگوی دو: شکاف میان داده نمونه و داده واقعی

نمونه اولیه با داده تمیزشده دستی ساخته می‌شود و نتیجه درخشان است. در تولید، داده دیر می‌رسد، فیلدها خالی‌اند و تعریف‌ها بین واحدها یکسان نیست. عملکرد سقوط می‌کند و اعتماد سازمان از دست می‌رود. کیفیت و کفایت داده در مطالعه RAND دومین علت رایج شکست است (Ryseff et al., 2024).

پیشگیری: نمونه اولیه را از همان مسیر داده تولید تغذیه کنید، حتی اگر کیفیت پایین باشد. بهتر است ضعف داده در هفته‌های نخست دیده شود تا در ماه‌های پایانی.

الگوی سه: فرایند پذیرش طراحی نشده است

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

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

الگوی چهار: دامنه بی‌مرز

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

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

الگوی پنج: نگهداشت پیش‌بینی نشده است

مدل‌ها با گذشت زمان و تغییر رفتار بازار ممکن است افت کنند؛ پدیده‌ای که در ادبیات با عنوان «رانش مفهوم» (concept drift) شناخته می‌شود (Gama et al., 2014). نگهداشت سامانه‌های یادگیری ماشین نیز هزینه پنهان قابل توجهی دارد (Sculley et al., 2015). اگر کسی مسئول پایش، بازآموزی و پاسخ به هشدارها نباشد، سامانه به‌آرامی از کار می‌افتد و در نهایت خاموش می‌شود؛ گاهی بی‌آنکه کسی لحظه خرابی را ثبت کند.

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

چه چیزی پروژه‌های موفق را متفاوت می‌کند؟

توصیه‌های RAND در همین جهت است: اطمینان از اینکه تیم فنی هدف و زمینه کسب‌وکار را می‌فهمد، تمرکز بر مسئله به‌جای فناوری، انتخاب مسئله‌های ماندگار، سرمایه‌گذاری در زیرساخت داده و استقرار، و شناخت محدودیت‌های هوش مصنوعی (Ryseff et al., 2024). به نظر نگارنده، شروع کوچک‌تر، سنجه روشن، حضور مالک مسئله و رویارویی زودهنگام با واقعیت داده، دامنه را واقع‌بینانه نگه می‌دارد.

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

منابع

  • 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
  • Gama, J., Žliobaitė, I., Bifet, A., Pechenizkiy, M., & Bouchachia, A. (2014). A survey on concept drift adaptation. ACM Computing Surveys, 46(4), 1–37. https://doi.org/10.1145/2523813
  • Paleyes, A., Urma, R.-G., & Lawrence, N. D. (2022). Challenges in deploying machine learning: A survey of case studies. ACM Computing Surveys, 55(6), 1–29. https://doi.org/10.1145/3533378
  • 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).