بیشتر افراد وقتی بدهی دارند، کنترل اوضاع را از دست می‌دهند. حتی شکسپیر هم در مورد خطرات قرض گرفتن هشدار داده است: «نه قرض بگیرید و نه وام بدهید؛ در غیر این صورت، هم پولتان را از دست خواهید داد، هم دوست‌تان را.» با سنگین‌تر شدن بدهی‌ها، افراد وارد ورطه‌ای بی‌انتها می‌شوند. بدهی می‌تواند روی اطرافیان و دوستان فرد هم تأثیرات منفی بگذارد.
گاهی اوقات، افراد از بدهی‌های فزاینده‌ی خود غافل می‌شوند.
در این مواقع، اتفاقی که می‌افتد این است که فرد به حساب کارت‌های اعتباری‌اش، میلیون‌ها هزینه می‌کند؛ ولی در طول زمان خودش را فریب می‌دهد تا باور کند این کار سرانجام تلخی نخواهد داشت. غافل از این‌که بهای هرکاری را باید پرداخت.
آژانس‌های کارت اعتباری زندگی را برای افراد، به خصوص کسانی که تمایل به خریدهای تکانشی و تفریحی دارند، آسان می‌کنند؛ همه چیز مجانی به نظر می‌رسد و ما هم با خیال راحت به خریدهای متفرقه ادامه می‌دهیم. در نگاه اول به نظر می‌رسد اعتباری بی‌انتها داریم، پس چرا از آن استفاده نکنیم؟ بیشتر ما به این فکر نمی‌کنیم که در نهایت، چطور باید همه‌ی این بدهی‌ها را پرداخت کنیم.
برخی در میانه‌ی راه به خود می‌آیند، اما کاری از دست‌شان بر نمی‌آید چون به این هزینه‌های اضافی و بی‌پروا عادت کرده‌اند. به همین دلیل، این شرایط را به قماربازی تشبیه می‌کنند: شاید به وضوح بدانیم بدهی‌هایی به بار می‌آوریم که هیچ‌گاه قادر به پرداختش نخواهیم بود، اما ظاهراً تمایل به بدهکار شدن از نیروهایی که سعی در جلوگیری از آن دارند قوی‌تر است.
نوع دیگری از بدهی
برخی از افزایش بدهی‌هایشان آگاه‌اند و با این وجود به این کار ادامه می‌دهند، چون انتظار دارند پولی که قرض کرده‌اند به سودی فراوان منتهی شود. این استراتژی می‌تواند درست باشد و بسیاری از افراد سودآوری آن را تأیید می‌کنند.
شاید از خودتان بپرسید چرا اینقدر در مورد بدهی صحبت کردیم. چون یک نوع بدهی دیگر وجود دارد که عده‌ی زیادی از آن خبر ندارند، نوعی بدهی که در حوزه‌ی توسعه‌ی نرم‌افزارها رخ می‌دهد. این بدهی را با عنوان «بدهی فنی» می‌شناسند.
بدهی فنی می‌تواند در هر کدام از شاخه‌های مهندسی و فناوری اتفاق بیفتد. اما در این نوشتار، ماهیت بدهی فنی را در بافت سیستم‌های نرم‌افزاری مورد مطالعه قرار می‌دهیم. با این حال، به خاطر داشته باشید که این نکات را می‌توان به زمینه‌های دیگر مرتبط با فناوری نیز تعمیم داد.
بدهی‌های فنی چطور در حوزه نرم‌افزاری ظاهر می‌شوند؟
مهندس نرم‌افزار روز و شب روی یک پروژه‌ی برنامه‌نویسی کار می‌کند. طبق بازه‌ی زمانی مشخص شده، پروژه باید تا انتهای ماه انجام و وارد فاز تولید شود. این مدت زمان برای انجام چنین کاری، خیلی کم و غیرمنطقی است و برنامه‌نویس نمی‌داند در چندین روز باقی‌مانده، چطور می‌تواند کارش را به سرانجام برساند.
بیشتر برنامه‌نویس‌های باتجربه به چنین شرایطی عادت دارند. کارفرمایان معمولاً به جای توجه به حجم کاری قابل انجام در یک بازه‌ی زمانی، ددلاین‌ها را بر اساس خواسته‌های خود که اغلب هیچ ارتباطی با کار برنامه‌نویسی ندارند، تعیین می‌کنند: «فرقی ندارد از کجا این تاریخ را انتخاب کرده‌ام، باید در همین موعد کار را تحویل دهی!»
در این شرایط، برنامه‌نویس معمولاً تصمیم می‌گیرد برای اتمام کار تا موعد مقرر، کدنویسی را تا حدودی سرسری انجام دهد. یکی از گام‌های فرآیند برنامه‌نویسی، تعبیه‌ی قابلیت «مدیریت خطا» است؛ این کار مقاومت کدها را افزایش داده و امکان مدیریت مشکلات پیش‌بینی‌نشده و احتمالی پس از پیاده‌سازی را فراهم می‌کند.
با این حال، برنامه‌نویس سردرگم و مضطرب تصمیم می‌گیرد این گام را فعلاً کنار بگذارد، چون به نظرش خطای چندان زیادی در کدها وجود ندارد و قابلیت مدیریت خطا احتمالاً لازم نخواهد بود.
بدهی‌های مالی در این سناریوی فنی
با کنار گذاشتن قابلیت مدیریت خطا، برنامه‌ی نوشته‌شده به نوعی بدهکار شده است. بدهی، هزینه‌ای است که در ازای آن‌چه در این لحظه به صرفه و باارزش به نظر می‌رسد، در آینده باید پرداخت شود. به عبارتی، کاری که امروز باید انجام شود، به آینده‌ای نامشخص موکول می‌گردد.
این بدهی در همان لحظه از نظر پنهان است و هیچ‌کس متوجه آن نمی‌شود. خود برنامه‌نویس از آن خبر دارد؛ مدیران ناظر بر پروژه گاهی اوقات بر آن واقف‌اند و حتی تشویقش می‌کنند تا با تحویل کار در زمان مقرر، موردتقدیر قرار بگیرند. در غیر این صورت، تنها خود سازندگان هستند که از وجود این بدهی باخبراند. دیگران در حال حاضر از آن اطلاعی ندارند و بعداً در کمال تعجب متوجه می‌شوند چنین بدهی عظیمی داخل کد وجود داشته است.
سناریوی دیگری را فرض کنید که در آن برنامه‌نویس به این نتیجه می‌رسد حذف قابلیت مدیریت خطا نمی‌تواند به اندازه‌ی کافی در زمان صرفه‌جویی کند. پس چیز دیگری باید از این میان حذف شود. بعد از مدتی، برنامه‌نویس تصمیم می‌گیرد دیگر کد را مستند نکند. در نتیجه وارد فازی می‌شود که به جز نوشتن کدهای بیشتر و بیشتر، به چیز دیگری توجه نمی‌کند.
این هم نوع دیگری بدهی فنی است که به این مجموعه‌ی فزاینده اضافه می‌شود.
برنامه‌نویس در توجیه تصمیمش، با خود فکر می‌کند چون خودش کد را نوشته و آن را از بر است، نیازی به مستندسازی آن ندارد. پس نتیجه می‌گیرد که به یادداشت کردن کارکرد کدها یا توضیحات بین خطوط نیازی نیست و مصمم می‌شود که وقت باارزش خود را صرف چنین کار یکنواخت و بیهوده‌ای نکند. مسئله اینجاست که همین برنامه‌نویس‌ها وقتی مجبور به بازطراحی و ویرایش کدهای قبلی شوند، از تصمیم خود پشیمان می‌شوند؛ چون در آن زمان به خاطر نمی‌آورند هنگام نوشتن کدها چه چیزی در ذهن داشته‌اند.
کابوس برنامه‌نویسان
برنامه‌نویس‌ها به خوبی می‌دانند ادامه‌ی کار یک برنامه‌نویس دیگر و تلاش برای فهم آن‌چه در ذهن او بوده، چه کابوس بزرگی است. خود کدها به تنهایی نمی‌توانند هدف و کارکردشان را نشان دهند. وجود یک مستندسازی ضعیف و سرسری هم از نبود آن بهتر است؛ چون بدون مستندسازی، کدها معمایی خواهند بود که حلش مستلزم زمان و تلاش فراوان است. حتی گاهی اوقات، به جز دور انداختن کد قبلی و شروع از گام اول، چاره‌ای وجود ندارد.
پس تا اینجا با دو نوع بدهی فنی آشنا شدیم: یکی حذف قابلیت مدیریت خطا و دیگری، نقص در مستندسازی.
شاید با خود فکر کنید این موارد را به زحمت می‌توان بدهی در نظر گرفت و به نظر نمی‌رسد پیامد و عواقب خاصی به دنبال داشته باشند.
متأسفانه این عواقب، کاملاً وابسته به شانس و اقبال هستند.
فرض می‌کنیم به کمک این بدهی‌های فنی، برنامه‌نویس می‌تواند در بازه‌ی زمانی تعیین شده کارش را تحویل دهد. حالا همه مشتاق و چشم به راه نرم‌افزار تولیدشده هستند.
این نرم‌افزار قرار است تا یکی دو هفته‌ی آینده راه‌اندازی شده و مورد استفاده قرار بگیرد؛ اما ناگهان، کد به خطایی غیرپیش‌بینی شده برمی‌خورد. اما بدون قابلیت مدیریت خطا، برنامه هیچ ایده‌ای از کاری که باید انجام دهد ندارد. پس هربار این خطا رخ می‌دهد، برنامه بسته می‌شود.
این منجر به عصبانیت و آشفتگی کاربران می‌شود.
نرم‌افزار چه مشکلی دارد؟ یک دقیقه خوب کار می‌کند و بعد از کار می‌ایستد و بسته می‌شود. اعتراض و شکایت از این رفتار عجیب نرم‌افزار خیلی زود اوج می‌گیرد و در شبکه‌های اجتماعی جنجال به پا می‌شود. حتی آن‌هایی که در ابتدا این نرم‌افزار را دستاوردی خارق‌العاده می‌دانستند، حالا علیه آن حرف می‌زنند.
زمان پاسخگویی
عواقب این بدهی فنی سنگین است. نرم‌افزار دیگر کاربردی ندارد و بلااستفاده در کناری می‌افتد. علاوه بر این، آوازه‌ی توسعه‌گر و سازندگان آن هم خراب می‌شود. حتی ممکن است بعضی از کاربران باور داشته باشند نوسانات این برنامه به نوعی به آنها آسیب زده و شکایت قانونی هم مطرح کنند.
به بیان خلاصه، هزینه‌ی جبران این بدهی می‌تواند چندین برابر سنگین‌تر از آن چیزی باشد که در ابتدا تصور می‌شد.
می‌توانیم به توصیف سناریوهای احتمالی ادامه دهیم. فرض کنید برنامه‌نویسی مسئولیت احیای نرم‌افزار را بر عهده می‌گیرد. اما با یک نگاه به کد، جا می‌خورد! هیچ اثری از مستندسازی دیده نمی‌شود و به هیچ وجه نمی‌توان از این کد سر درآورد. رمزگشایی و حل آن می‌تواند هفته‌ها و حتی ماه‌ها به طول بیانجامد.
حالا وقت پرداخت بدهی فنی عدم مستندسازی است. کاربران نرم‌افزار که مشغول دست و پنجه نرم کردن با مشکل دیگر (نبود قابلیت مدیریت خطا) بودند، از این بدهی هیچ سرنخی ندارند.
بعضی از بدهی‌های فنی فوراً مشاهده و مشخص می‌شوند؛ برخی هم برای مدتی پنهان باقی می‌مانند و کاربران را فریب می‌دهند.
بحث دیگری هم در مورد بدهی‌های فنی وجود دارد مبنی بر سودآور بودن آنها. فرض کنید برنامه‌نویسی که برای اصلاح و ویرایش کد استخدام می‌شود با موفقیت این کار را به سرانجام می‌رساند، اما او هم کارش را مستندسازی نمی‌کند. بنابراین می‌توان گفت بدهی فنی ناشی از عدم مستندسازی، نوعی سودآوری یا روند افزایشی دارد.
یک نکته درباره بدهی فنی
موضوع دیگری که باید در مورد بدهی‌های فنی مدنظر داشت این است که در هر کدام از مراحل توسعه نرم‌افزار می‌توانند رخ دهند. اینجا روی بدهی کدها تمرکز کردیم که جزو رایج‌ترین بدهی‌های فنی نرم‌افزاری است.
با این حال، در طراحی نرم‌افزار هم می‌توان بدهی به باور آورد. این نوع بدهی زمانی اتفاق می‌افتد که مهندسان در طی فرآیند طراحی یا توسعه‌ی سیستم، از چیزی مذایقه می‌کنند. این بدهی‌ها هم به کرّات اتفاق می‌افتند؛ در نتیجه‌ی این بدهی‌ها، طراحی سرسری انجام گرفته و متخصص به سرعت وارد مرحله‌ی کدنویسی می‌شود.
نوع دیگر بدهی‌های فنی، مربوط به مرحله آزمایش می‌شوند.
توسعه‌گرها مدام درگیر این بدهی می‌شوند. وقتی ددلاین زمانی نزدیک است، آسان‌ترین راه‌حل، کوتاه یا باریک کردن آزمایشات به نظر می‌رسد. ذهنیت و رویکرد رایج در سیلیکون‌ولی می‌گوید بهترین راه، تجزیه‌ی کارها و افزایش سرعت است. در نتیجه‌ی این طرز فکر، متخصصان از آزمایشات گسترده و جامع صرف نظر می‌کنند و کاربران نهایی به موش آزمایشگاهی تبدیل می‌شوند.
این انتخاب تحت شرایط خاص می‌تواند معقول و منطقی باشد، اما معمولاً عواقب وحشتناکی در پی دارد.
اگر کاربرد نرم‌افزار در حوزه‌ای معمولی و ساده باشد و پیامدهای حیاتی (مرگ و زندگی) در میان نباشند، احتمال این‌که توسعه‌گرها بتوانند به راحتی از دام این بدهی فرار کنند، زیاد است. نهایتاً کاربران از مشکلات آن ناراحت و آزرده می‌شوند؛ گروهی هم از این‌که در گروه آزمایشی بتا قرار گرفته و زودتر از بقیه از نرم‌افزار استفاده کرده‌اند خوشحال‌اند.
اما مشکل اصلی مربوط به نرم‌افزارهایی است که کاربردهای حساس و حیاتی دارند؛ اینجاست که بدهی‌های فنی مثل بمب خنثی‌نشده می‌مانند. بدهی‌های فنی، بسته به ماهیت‌شان، می‌توانند خساراتی جدی وارد کنند.
بدهی فنی در سیستم‌های مبتنی بر هوش مصنوعی
در این نوشتار، این چالش‌ها را با نام بدهی فنی هوش مصنوعی مشخص می‌کنیم.
شاید گمان کنید سیستم‌های هوش مصنوعی تحت نظارتی قوی و با بهترین قابلیت‌های ممکن توسعه می‌یابند؛ اما متأسفانه، واقعیت چیز دیگری است. خیل عظیمی که به سوی ساخت سیستم‌های هوش مصنوعی به جریان افتاده، سوار بر نرم‌افزارهای غیرمعتبر و غیرقابل اتکایی است که به شکل ضعیفی مرحله‌ی آزمایش را پشت سر گذاشته‌اند و هرلحظه احتمال شکست آنها وجود دارد.
حال، کلیات بدهی فنی نرم‌افزارها را با جریان موجود در حوزه هوش مصنوعی ترکیب می‌کنیم تا تأثیرات این ملقمه بر سیستم‌های حساس و حیاتی را دریابیم.
این دو جریان، در خودروهای خودران مبتنی بر هوش مصنوعی به هم می‌رسند. در همین لحظه که این مقاله را می‌خوانید، نوعی بدهی فنی هوش مصنوعی در توسعه و ساخت خودروهای خودران مبتنی بر هوش مصنوعی رخ می‌دهد، بدهی‌ای که روزی نوبت پرداخت آن می‌رسد.
فکر کردن به این‌که آینده‌ی خودروها در دست سیستم‌های هوش مصنوعی و خودروهای خودران است، مایه‌ی نگرانی است. در خودروهای تمام خودران، انسان‌ها هیچ نفشی در رانندگی ندارند. خودروهای تمام خودران به وسیله‌ی سیستم‌های رانندگی هوش مصنوعی کنترل شده و نیازی به نظارت انسان‌ها ندارند.
سؤالی که مطرح می‌شود این است که بدهی‌های فنی هوش مصنوعی از چه طرقی می‌توانند تأثیر منفی روی خودروهای تمام خودران بگذارند؟
قبل از پاسخ به این سؤال، بهتر است با خودروهای تمام خودران بیشتر آشنا شویم.
سطوح خودروهای خودران
خودروهای تمام خودران خودروهایی هستند که سیستم هوش مصنوعی آنها به تنهایی رانندگی کرده و به هیچ کمکی از سوی انسان نیاز ندارد.
این خودروهای بدون راننده را خودروهای خودران سطح ۴ و ۵ می‌نامند. خودروهایی که رانندگی را به کمک انسان‌ها انجام می‌دهند خودروهای سطح ۲ و ۳ در نظر گرفته می‌شوند؛ خودروهای سطح ۲ و ۳ را با نام نیمه‌خودران نیز می‌شناسند. این دسته خودروها اغلب شامل تجهیزات (افزودنی) خودکاری هستند که ADAS (سیستم‌های پیشرفته‌ی دستیار رانندگی) نام دارند.
خودروهای سطح ۵ تا به حال در واقعیت تولید نشده‌اند. حتی نمی‌دانیم که چنین چیزی امکان‌پذیر هست یا نه، و اگر هست، دستیابی به آن چقدر زمان می‌برد.
تلاش برای ساخت خودروهای سطح ۴ روندی تدریجی داشته است. این خودروها در حال حاضر، در مسیرها و خیابان‌های عمومی خاصی به آزمایش گذاشته می‌شوند. با این حال، در مورد مجاز بودن چنین آزمایشاتی (ورود خودروهای خودران به مسیرهای عمومی و خیابان‌های واقعی) اختلاف نظر وجود دارد. مخالفان این رویکرد معتقدند این آزمایشات، مردم را موش آزمایشگاهی در نظر گرفته و مرگ و زندگی آنها را در دست دارند.
خودروهای نیمه‌خودران به حضور راننده نیاز دارند. استفاده از این خودروها تفاوت چندانی با رانندگی در خودروهای معمولی ندارد. به همین دلیل، احتمالاً می‌توان گفت بحث خاصی در مورد آنها وجود ندارد؛ هرچند نکاتی که جلوتر خواهیم گفت را می‌توان به این دسته خودروها نیز تعمیم داد.
مهم است که مردم از خودروهای نیمه‌خودران پیش‌آگاهی داشته باشند. علی‌رغم تبلیغات تجاریی که نشان می‌دهند راننده‌ها پشت فرمان خودروهای سطح ۲ و ۳ به راحتی می‌خوابند، این واقعیت نباید جا بیافتد که این خودروها نیازی به توجه و نظارت راننده ندارند.
این راننده‌ها هستند که در قبال اقدامات خودورهای نیمه‌خودران مسئول‌اند، فارغ از این‌که خودرویشان چقدر از سیستم‌های خودکار بهره برده باشد.
خودروهای خودران و بدهی فنی هوش مصنوعی
خودروهای سطح ۴ و ۵ برای رانندگی نیازی به انسان‌ها ندارند. همه سرنشینان این خودروها مسافر هستند و هوش مصنوعی رانندگی را بر عهده دارد.
یکی از انتقادات به خودروهای تمام‌خودران این است که سیستم‌های رانندگی هوش مصنوعی که در آنها به کار می‌روند، قادر به درک احساسات نیستند. به بیان دیگر، این سیستم هوش مصنوعی صرفاً مجموعه‌ای از الگوریتم‌ها و برنامه‌های کامپیوتری است و نمی‌تواند مثل انسان‌ها، استدلال کند.
به هیچ وجه نمی‌توان قابلیت‌های انسانی برای سیستم‌های رانندگی هوش مصنوعی قائل شد. مردم به شکل خطرناکی، ویژگی‌های انسانی به هوش مصنوعی نسبت می‌دهند؛ با این‌که واقعیت چیز دیگری است: هیچ سیستم هوش مصنوعی در حال حاضر چنین قابلیتی ندارد.
سیستم‌های رانندگی هوش مصنوعی ذاتاً چیزی از رانندگی نمی‌دانند. رانندگی و همه‌ی سناریوهای آن را باید برنامه‌نویسی و به عنوان سخت‌افزار یا نرم‌افزار به خودروهای خودکار تغذیه کرد.
عوامل زیادی در این فرآیند نقش ایفا می‌کنند. به همین دلیل، انواع بدهی‌های فنی هوش مصنوعی در سیستم‌های رانندگی هوش مصنوعی و کدهای به کاررفته در خودروهای خودران امروزی به چشم می‌خورد.
برای امکان‌پذیر کردن قابلیت‌های یک خوردوی خودکار، به چیزی حدود ۱۰۰ میلیون خط کد نیاز است. در این میان، علاوه بر کدهای خصوصی که متخصصان خودکارسازی یا سازندگان خودروهای خودران تولید کرده‌اند، کدهای شخص ثالث (مثل کدهای متن‌بازی که در سیستم‌های خودران به کار می‌روند) نیز حضور دارند.
بسیاری از شرکت‌ها هیچ ایده‌ای ندارند بدهی‌های فنی هوش مصنوعی چه عواقب سنگینی می‌توانند داشته باشند. درست مثل افرادی که بدون این‌که بدانند، بدهی‌های مالی به بار می‌آورند. بدهی‌ها پشت سر هم جمع می‌شوند و کسی متوجه نمی‌شود. این نکته در مورد گروه‌های توسعه‌ی هوش مصنوعی و اقدماتی که در راستای ساخت سیستم‌های هوش مصنوعی صدق انجام می‌دهند نیز صدق می‌کند. این گروه‌ها مشغول به بار آوردن بدهی‌های فنی هوش مصنوعی هستند و به نظر نمی‌رسد هیچ درکی از عواقب‌شان داشته باشند.
عاقبت این حجم از بدهی فنی هوش مصنوعی چیست؟
از جمله حوزه‌هایی که تحت تأثیر بدهی‌های فنی قرار می‌گیرند می‌توان به هوش مصنوعی به کار رفته در مجموعه‌ی حسی و ساختارش اشاره کرد.
سنسورهای خودروهای خودران نقشی حیاتی دارند. این سنسورها شامل دوربین‌هایی با قابلیت ضبط لحظه‌ای، رادار، LIDAR، تشخیص‌گر فراصوت، تصویربردار حرارتی، و مواردی از این دست هستند. سنسورهای به کار رفته در این خودروها به شدت متغیر هستند و از شرکتی به شرکت دیگر فرق دارند.
سنسورها را می‌توان چشم و گوش سیستم رانندگی هوش مصنوعی دانست. در طول رانندگی، جریانی زنده از داده‌ها وارد سنسورها شده و از نظر محاسباتی مورد تجزیه و تحلیل قرار می‌گیرد. از جمله ابزارهایی که می‌توان برای انطباق محاسباتی الگوها به کار برد، یادگیری ماشین (ML) و یادگیری عمیق (DL) هستند. علاوه بر تجزیه و تحلیل مستقیم داده‌ها، ادغام داده‌های حاصل از چند سنسور (MSDF) نیز باید انجام شود؛ با اجرای این فرآیند، داده‌ها کنار هم قرار گرفته و تفسیرهای موجود از صحنه‌ی پیش روی ماشین، هم‌راستا و هماهنگ می‌شوند.
اما آن‌چه درون کدهای پیچیده‌ی این سنسورها نهفته، بدهی فنی هوش مصنوعی است.
بعضی از این بدهی‌ها به دلیل عجله در ساخت سیستم هوش مصنوعی و به آزمایش گذاشتن خودرو رخ می‌دهند. دلیل برخی دیگر، به کارگیری هزاران توسعه‌گر هوش مصنوعی برای توسعه کدهاست؛ امری که می‌تواند توسعه‌گرهای تازه‌کار را تواناتر کرده یا این‌که تأثیر کاملاً عکس داشته باشد. عدم نظارت سخت‌گیرانه و تنظیم اقدامات کدنویسی نیز می‌تواند تأثیرگذار باشد.
فراهم کردن شرایط توسعه هوش مصنوعی
همانطور که گفتیم، می‌توان عرصه را برای توسعه هوش مصنوعی خودروهای خودران آماده کرد و به آنها اجازه داد بدون دقت بالایی که از سایر سیستم‌های لحظه‌ای حیاتی انتظار می‌رود، کار خود را انجام دهند.
تعداد کمی از سازندگان خودروهای خودران هستند که به بدهی‌های فنی هوش مصنوعی دقت می‌کنند. برای جلوگیری از مشکلات، کافی است فهرستی جامع از تمام اقداماتی که انجام می‌دهید تهیه کرده و دریابید بدهی‌های فنی هوش مصنوعی از چه نقاطی می‌توانند به صنعت شما نفوذ کنند. این کار می‌تواند پرزحمت و ملال‌آور باشد. حتی ممکن است در این میان، افراد دنبال مقصر بگردند و بازی‌های سیاسی شکل گیرد.
راه آسان‌تر این است که صبر کنیم و ببینیم چه اتفاقی می‌افتد.
بدهی‌های فنی هوش مصنوعی در هر مرحله‌ای از چرخه‌ی زندگی خودروی خودران می‌توانند اتفاق بیافتند. ممکن است بدهی‌ها هنوز کشف نشده باشند و زمانی آشکار شوند که خودروی خودران وارد خیابان‌ها می‌شود. اما خوب می‌دانیم که آنجا دیگر نمی‌توان از زیر بار بدهی‌ها شانه خالی کرد و چاره‌ای جز رویارویی با عواقب وجود نخواهد داشت.
جمع‌بندی
با این‌که با بیان ادله نشان دادیم بدهی‌های فنی هوش مصنوعی می‌توانند چقدر آسیب‌زا باشند، گاهی اوقات، ارتکاب آنها به نوعی ضروری است. البته در این شرایط هم جوانب احتیاط فراوانی وجود دارد. آگاهی از محل بدهی فنی، می‌توان مبادلاتی انجام داده و توازنی برقرار کرد که وجود این بدهی را امکان‌پذیر می‌کنند. به بیان دیگر، می‌توان خطرات این بدهی را به حداقل رساند.
آن‌چه به هیچ وجه نباید اتفاق بیفتد، مخفی کردن بدهی‌های فنی هوش مصنوعی است. تلاش برای مخفی نگه داشتن این مسائل از مدیریت، بدون شک عواقبی جبران‌ناپذیر برای همه‌ی افرادی که در آن نقش داشته‌اند به دنبال خواهد داشت. فشارهای موجود مبنی بر رعایت ددلاین‌ها یا پایین نگه داشتن هزینه‌ها افراد را به این سمت و سو می‌برد که به بدهی‌های فنی تن داده و آنها را وارد سیستم‌های رانندگی هوش مصنوعی کنند.
متأسفانه معترضان به بدهی‌هایی که در شرکت‌ها رخ می‌دهد، می‌توانند در لیست سیاه قرار بگیرند؛ صرفاً بدین خاطر که جلوی بدهی‌های فنی نرم‌افزارها را گرفته‌اند.
با این وجود، اگر شرکت‌ها و متخصصان توسعه‌ی خودروهای خودکار تا به حال به پدیده‌ی بدهی‌های فنی هوش مصنوعی توجهی نکرده‌اند، اکنون زمان آن فرا رسیده که فکری به حال آن کنند. ماهی را هروقت از آب بگیری، تازه است!
جدیدترین اخبار هوش مصنوعی ایران و جهان را با هوشیو دنبال کنید
منبع: هوشیو
فیلترهای زیبایی دیجیتال به رنگ گرایی تداوم میبخشند