بدهی فنی هوش مصنوعی: چالش‌های پنهان و راهکارهای مقابله

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

پیچیدگی‌های سیستم‌های هوش مصنوعی و شکست‌های مرتبط با آن‌ها به خوبی مستند شده است. مطالعه‌ای در سال ۲۰۲۵ توسط MIT نشان داد که ۹۵ درصد پروژه‌های هوش مصنوعی مصنوعی (Generative AI) به مرحله بهره‌برداری نمی‌رسند یا ارزش مورد انتظار را ارائه نمی‌دهند. مطالعه‌ای مشابه توسط S&P Global Market Intelligence حاکی از آن بود که ۴۲ درصد از کسب‌وکارها در سال ۲۰۲۵ چندین ابتکار هوش مصنوعی را کنار گذاشته‌اند که این رقم افزایش قابل توجهی نسبت به ۱۷ درصد سال قبل محسوب می‌شود. دلایل مختلفی برای این شکست‌ها ذکر شده است، اما بیشتر آن‌ها به سیستم‌های ضعیف طراحی و پیاده‌سازی شده اشاره دارند که مدیریت آن‌ها پیچیده است و نقاط شکست متعددی دارند که نظارت بر آن‌ها دشوار است و منجر به انباشت سریع بدهی هوش مصنوعی می‌شود.

بدهی فنی هوش مصنوعی: بحرانی آشکار

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

اشکال جدید بدهی هوش مصنوعی

بدهی هوش مصنوعی معمولاً در چهار شکل جدید بروز می‌کند که هر کدام مجموعه‌ای از ریسک‌های خاص خود را به همراه دارند.

بدهی پرامپت (Prompt Debt): این شکل از بدهی، بارزترین نوع بدهی هوش مصنوعی است. نسخه‌ای مدرن از «کد اسپاگتی»، این نوع بدهی می‌تواند شامل تغییرات مستند نشده پرامپت، انباشت پرامپت‌های «راه‌حل سریع» که منجر به ناسازگاری می‌شوند، عدم کنترل نسخه مناسب برای پرامپت‌ها و «پرامپت استافینگ» (تعبیه داده‌ها یا متن‌های اضافی مستقیماً در پرامپت‌های هوش مصنوعی) باشد. همه این موارد با هم باعث می‌شوند پرامپت‌ها شکلی از کد بدون نوع، بدون تست و بدون کنترل نسخه تلقی شوند که منجر به شکنندگی و آسیب‌پذیری بیشتر می‌شود.

بدهی وابستگی مدل (Model Dependency Debt): این یکی دیگر از اشکال رایج بدهی هوش مصنوعی است. بسیاری از سازمان‌ها امروزه به ترکیبی از مدل‌های خارجی که توسط ارائه‌دهندگان اصلی مدل‌های پایه توسعه یافته‌اند، متکی هستند؛ برنامه‌ها و عامل‌ها (Agents) بر اساس فراخوانی API به این مدل‌ها ساخته می‌شوند. در نتیجه، منطق برنامه اکنون به مدل‌هایی وابسته است که خارج از سیستم اصلی قرار دارند و قابل کنترل نیستند. با به‌روزرسانی مدل‌ها، عملکرد تغییر می‌کند و قابلیت بازتولید از دست می‌رود؛ پرامپت‌هایی که برای یک مدل تنظیم شده‌اند ممکن است در صورت تغییر به مدل دیگر (چه به‌روزرسانی از همان ارائه‌دهنده و چه از ارائه‌دهنده‌ای دیگر) با شکست مواجه شوند یا عملکرد ضعیفی داشته باشند.

بدهی بازیابی (Retrieval Debt): اکثر استقرار‌های هوش مصنوعی سازمانی امروزه از بازیابی-افزوده‌سازی تولید (Retrieval-Augmented Generation - RAG) استفاده می‌کنند که زمینه اضافی را از مخازن داده سازمانی استخراج می‌کند. بدهی بازیابی پیامد داده‌های نامرتب در این مخازن، اسناد تکراری و اطلاعات منسوخ است. این امر باعث می‌شود هوش مصنوعی پاسخ‌های فنی درستی را برگرداند که منسوخ شده و دیگر مرتبط نیستند و منجر به شکست‌های بعدی می‌شود. برخلاف توهمات (hallucinations)، تشخیص این موارد دشوارتر است زیرا قبلاً درست بوده‌اند، و لذا به نظر درست می‌آیند.

بدهی ارزیابی (Evaluation Debt): این نوع بدهی، کمبود استانداردسازی در تست و نظارت برای مدل‌ها و برنامه‌های هوش مصنوعی را منعکس می‌کند. اگرچه معیارهای سنجش (benchmarks) هوش مصنوعی وجود دارند، اما تمایل دارند بر روی تست‌های محدود تمرکز کنند و نتایج لحظه‌ای را منعکس کنند. بیشتر سازمان‌ها فاقد استانداردهای تست سازگار، مجموعه داده‌های حقیقت زمین (ground truth) و نظارت بلادرنگ بر استقرارها هستند؛ معادل یکپارچه‌سازی مداوم/تحویل مداوم (CI/CD) برای پرامپت‌ها هنوز وجود ندارد. در نتیجه، مدیران ارشد فناوری اطلاعات و مدیران ارشد فناوری (CIOs و CTOs) دید واضحی نسبت به عملکرد مدل ندارند و نمی‌توانند بهبودها یا وخامت عملکرد مدل‌ها را ردیابی کنند.

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

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

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

راهکارهای پیشگیری از بدهی هوش مصنوعی برای سازمان‌ها

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

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

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

ثالثاً، قابلیت توضیح‌پذیری (Explainability) باید به صورت پیش‌فرض در تمام نتایج هوش مصنوعی گنجانده شود تا کمبود قابلیت بازتولید جبران شود. ردیابی داده‌ها، مدل‌های مورد استفاده و مراحل طی شده باید به وضوح قابل پیگیری باشند تا امکان حسابرسی نتایج و اصلاح در صورت بروز هرگونه خطای سیستمی فراهم شود.

این امر نیازمند برنامه‌های صریح کاهش بدهی هوش مصنوعی و بودجه‌های مرتبط، مشابه موج‌های قبلی سرمایه‌گذاری در امنیت یا مدرن‌سازی ابر (Cloud) است. این برنامه‌ها باید در سطح مدیران ارشد (CXO) توسط رهبران کلیدی هدایت شوند تا از دوباره‌کاری پرهزینه در آینده جلوگیری شود.

نتیجه‌گیری: پیشگیری بهتر از درمان

استقرارهای هوش مصنوعی سازمانی صرفاً کدهای ایستا نیستند؛ آن‌ها سیستم‌های زنده‌ای هستند که با کل پشته سازمانی تعامل دارند. در نتیجه، چالش تعیین‌کننده در یک سازمان عامل‌محور (Agentic Enterprise) نه ساختن یا استقرار سیستم‌های هوشمند، بلکه نگهداری این سیستم‌ها برای اطمینان از قابلیت اطمینان مداوم در عملیات واقعی خواهد بود.

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