چرا سامانه‌های هوش مصنوعی عامل‌محور به‌تدریج شکننده می‌شوند؟

Nielsen Norman Group در بررسی کاربران ساخت سامانه‌های هوش مصنوعی عامل‌محور، الگویی آشنا را شناسایی کرده است: ابزارهایی که سریع و بدون معماری روشن ساخته می‌شوند، ممکن است با انباشته‌شدن تغییرات دشوارتر مدیریت و نگهداری شوند.

دیجیتال مارکتینگ نویانوین را به منابع منتخبت در گوگل اضافه کن (در زبانه جدید باز می‌شود)
چرا سامانه‌های هوش مصنوعی عامل‌محور به‌تدریج شکننده می‌شوند؟
فهرست مطالب
  1. ۱سامانه‌ای که فقط برای نیاز امروز ساخته می‌شود
  2. ۲پنج الگویی که سامانه‌ها را شکننده می‌کند
  3. ۳چرا وابستگی به ابزار، بازبینی را عقب می‌اندازد؟
  4. ۴چه زمانی باید به‌جای وصله‌کردن، بازسازی کرد؟
  5. ۵این خبر برای بازاریابان و کسب‌وکارها چه معنایی دارد؟
خلاصه خبر در چند خط
  • ارزان و آسان‌شدن ساخت ابزار با AI می‌تواند به بزرگ‌شدن بیش‌ازحد سامانه‌ها بینجامد.
  • نمونه‌های اولیه و تغییرات تدریجی ممکن است به زیرساخت‌هایی تبدیل شوند که کاربران به آن‌ها وابسته‌اند.
  • نگهداری و اصلاح مداوم بدون نظم، درک محل فایل‌ها و نحوه کار سامانه را دشوار می‌کند.
  • بازسازی زمانی مطرح می‌شود که نیازهای کاربر تغییر کرده یا ادامه اصلاحات از طراحی دوباره دشوارتر شده باشد.

هوش مصنوعی عامل‌محور ساخت ابزارهای شخصی و کاری را آسان‌تر کرده، اما پژوهشی از Nielsen Norman Group هشدار می‌دهد که این سهولت می‌تواند به سامانه‌هایی پیچیده و شکننده منجر شود. مسئله برای کسب‌وکارها فقط ساخت یک گردش‌کار با کمک AI نیست؛ ابزارهایی که با فایل‌های زمینه، دستورالعمل‌ها و قابلیت‌های پیوسته‌افزوده‌شده کار می‌کنند، ممکن است آن‌قدر رشد کنند که مدیریت، عیب‌یابی یا حتی بازسازی‌شان دشوار شود.

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

سامانه‌ای که فقط برای نیاز امروز ساخته می‌شود

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

به گزارش Nielsen Norman Group، شرکت‌کنندگان مطالعه معمولاً با کمک AI نمونه‌ای اولیه می‌ساختند و سپس با پیداشدن نیازهای تازه، همان سامانه را تغییر می‌دادند. نمونه اولیه یا «پروتوتایپ» نسخه‌ای ابتدایی از ابزار است که برای آزمودن یک ایده ساخته می‌شود. مشکل زمانی شکل می‌گیرد که این نسخه بدون بازبینی و برنامه‌ریزی، به ابزار اصلی کار روزانه تبدیل شود.

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

پنج الگویی که سامانه‌ها را شکننده می‌کند

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

  • کد موقت: کاربر برای حل یک مسئله فوری، مثلاً نوشتن فایل دستورالعمل برای محدودکردن رفتار عامل، از AI کمک می‌گیرد. فایل اولیه آزمایش و بازبینی کامل نمی‌شود، اما گردش‌کار به‌تدریج به آن وابسته می‌شود.
  • رشد تکه‌تکه: هر نیاز جدید به ابزار موجود افزوده می‌شود. در یکی از نمونه‌ها، یک ویجت برای نمایش وضعیت پروژه‌ها در Asana، به‌مرور به داشبوردی با جزئیات بیشتر، نمودارها و قابلیت‌های پیش‌بینی و ثبت زمان تبدیل شد.
  • سرپا نگه‌داشتن: وقتی بخشی از سامانه از کار می‌افتد یا اطلاعاتش قدیمی می‌شود، کاربر به‌جای بازنگری اساسی آن را تعمیر می‌کند. گاهی اصلاح با درخواست از AI انجام می‌شود، اما این کار می‌تواند وابستگی کاربر را به AI برای یافتن و به‌روزرسانی فایل‌ها بیشتر کند.
  • پنهان‌کردن آشفتگی: فایل‌ها و اطلاعات در پوشه‌ای بدون نام‌گذاری و نظم مشخص جمع می‌شوند؛ چیزی شبیه کشوی خرت‌وپرت. در یک نمونه، AI از چنین پوشه‌ای مقاله‌های نامرتبط را بیرون کشید و کاربر برای اصلاح دستورها ۴۵ دقیقه وقت صرف کرد.
  • بازسازی: گاهی کاربر از نیازهای اولیه فراتر می‌رود و ساختار فعلی دیگر با شیوه کارش سازگار نیست. در چنین وضعی، طراحی دوباره ممکن است از ادامه تغییرات پراکنده مناسب‌تر باشد.

چرا وابستگی به ابزار، بازبینی را عقب می‌اندازد؟

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

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

چه زمانی باید به‌جای وصله‌کردن، بازسازی کرد؟

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

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

این خبر برای بازاریابان و کسب‌وکارها چه معنایی دارد؟

تیم‌های بازاریابی ممکن است از AI برای سامان‌دهی اطلاعات، ساخت گردش‌کار یا کمک به کارهای تکراری استفاده کنند. یافته‌های Nielsen Norman Group نشان می‌دهد آسان‌شدن ساخت، به‌تنهایی تضمین نمی‌کند ابزار در بلندمدت قابل‌فهم و قابل‌مدیریت بماند. هرچه یک سامانه به فایل‌های زمینه و دستورالعمل‌های بیشتری متکی شود، روشن‌بودن محل نگهداری و کارکرد هر جزء اهمیت بیشتری پیدا می‌کند.

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

چه باید کرد؟ اقدام‌های پیشنهادی
  1. ۱فایل‌های زمینه و اسناد مورد استفاده عامل‌های هوش مصنوعی را فهرست و نام‌گذاری کنید.
  2. ۲گردش‌کار فعلی را مستند کنید تا وابستگی‌ها و محل نگهداری اطلاعات روشن باشد.
  3. ۳پیش از افزودن قابلیت، مشخص کنید مشکل واقعی کاربر چیست و آیا تغییر ضروری است.
  4. ۴هر زمان سامانه با شیوه کار فعلی تیم هم‌خوان نیست، هزینه اصلاح را با بازسازی مقایسه کنید.

پرسش‌های متداول

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

این مطلب توسط ابزارهای هوش مصنوعی ترجمه شده است و توسط تیم تحریریه بازبینی شده است

#بهره‌وری_کسب‌وکار#طراحی_سامانه#عامل‌های_هوش_مصنوعی#هوش_مصنوعی
درباره نویسندهپژوهشگر اقتصاد دیجیتال

دانش آموخته مدیریت کسب و کار گرایش استراتژی پژوهشگر و استراتژیست اقتصاد دیجیتال

همه مطالب دیجیتال مارکتینگ نویانوینتازه‌ترین اخبار و آموزش‌های دیجیتال مارکتینگ را دنبال کنید
نویانوین