«نردبان تخریب»؛ راهکاری برای جایگزینی خطای سیستمی با پاسخ‌های قطعی

تصور کنید یک مدیر محصول هستید که کاربرانی عصبانی از دیدن «چرخ در حال چرخش» (Loading Spinner) یا پیام‌های خطای مبهم در اپلیکیشن خود دارد. در وضعیت فعلی، اکثر قابلیت‌های مدرن هوش مصنوعی در یک حالت دوتایی (Binary) قرار دارند: یا به‌درستی «کار می‌کنند» یا یک «اسپینر لودینگ» نمایش می‌دهند. برای حل این شکست بنیادین، راهنمای فنی منتشرشده در dev.to در ۸ اوت ۲۰۲۶ مکانیزمی به نام «نردبان تخریب» (Degradation Ladder) را معرفی کرد تا قابلیت‌های هوش مصنوعی به‌جای اینکه در زمان قطعی کاملاً «بشکنند»، به حالتی «ساده‌تر» تبدیل شوند و کاربرد خود را حفظ کنند.

مشکل شکست دوتایی

بیشتر توسعه‌دهندگان فعلاً از یک بلوک ساده try/catch برای فراخوانی مدل‌ها استفاده می‌کنند. طبق گزارش dev.to، این روش تمام شکست‌های متفاوت — مثل تأخیر بالا (High Latency)، رد درخواست توسط سیاست‌های ایمنی (Policy Refusals) یا اتمام اعتبار حساب (Exhausted Credits) — را در یک پیام کلی «خطایی رخ داد» ادغام می‌کند. این فقدان تفکیک و از دست رفتن رزولوشن خطا باعث می‌شود سیستم نتواند یک جایگزین مفید، هرچند با کیفیت پایین‌تر، ارائه دهد.

یک مدل کند به پاسخی متفاوت از مدلی نیاز دارد که درخواست را به دلیل سیاست‌های ایمنی رد کرده است. همچنین، اتمام اعتبار یک وضعیت مالی و مربوط به صورت‌حساب است، نه یک قطعی فنی. ادغام این‌ها در یک حالت خطای واحد، اطلاعات حیاتی لازم برای ارائه یک جایگزین (Fallback) مفید را از بین می‌برد.

مثلاً در یک قابلیت خلاصه‌ساز هوشمند برای سایت خبری، اگر مدل اصلی از دسترس خارج شد، کاربر نباید با کرش سیستم یا یک پیام خطای خشک مواجه شود؛ بلکه باید خلاصه‌ای کوتاه‌تر یا حتی فقط دو جمله اول مقاله را ببیند. همین تغییر رویکرد از «شکست دوتایی» به «تخریب تدریجی» (Graceful Degradation)، همان چیزی است که محصولات هوش مصنوعی در سطح تولید (Production-grade) را از نمونه‌های اولیه آزمایشی متمایز می‌کند. این رویکرد در واقع تکامل‌یافته‌ی معماری‌های جایگزینی چند-مدلی است که برای حذف زمان توقف اپلیکیشن‌ها طراحی شده‌اند.

پنج پله تخریب

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

• مدل ترجیحی: استفاده از کامل‌ترین پرامپت و باکیفیت‌ترین مدل طراحی‌شده برای آن قابلیت؛ این حالت ایده‌آل است.
• مدل ارزان‌تر/سریع‌تر: استفاده از مدلی در سطح پایین‌تر با همان پرامپت. این پله عملکرد کلی را حفظ می‌کند اما کیفیت‌های ظریف را فدا می‌کند. چون این افت کیفیت برای کاربر بیرونی سخت دیده می‌شود، این پله باید حتماً در سیستم ثبت شود تا به‌صورت خاموش نادیده گرفته نشود.
• پاسخ کش‌شده (Cached Answer) — شبیه به یادداشت‌هایی که از قبل برداشته‌ایم تا هر بار لازم نباشد کل کتاب را بخوانیم — استفاده از یک پاسخ پیش‌محاسبه‌شده یا قدیمی به همان سؤال. این روش برای طبقه‌بندی‌ها، توصیفات یا خلاصه‌هایی که تازگی مطلق در آن‌ها اولویت دوم است، بسیار مؤثر است.
• جایگزین قطعی (Deterministic Substitute): یک جایگزین غیر هوش مصنوعی. مثال‌هایی از این مورد عبارتند از: استفاده از جست‌وجوی کلمات کلیدی به‌جای جست‌وجوی معنایی (Semantic Search)، استفاده از یک موتور مبتنی بر قوانین (Rules Engine) به‌جای یک طبقه‌بندی‌کننده، یا نمایش دو جمله اول متن به‌جای خلاصه تولیدشده. این‌ها معمولاً ضعیف‌ترند اما همیشه در دسترس‌اند.
• غیبت صادقانه: یک اعلان تک‌جمله‌ای ساده در جای خود (بدون استفاده از پنجره مودال) که بیان می‌کند این قابلیت فعلاً ارائه نمی‌شود، در حالی که بقیه صفحه به‌طور عادی کار می‌کند. این پله هرگز شکست نمی‌خورد و به همین دلیل نردبان در اینجا به پایان می‌رسد.

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

پیاده‌سازی نردبان در کد

برای اینکه نردبان تخریب به یک «تقویت‌کننده تأخیر» (Latency Amplifier) تبدیل نشود، هر پله باید بودجه زمانی (Budget) مشخصی داشته باشد. اگر سیستمی سه مدل مختلف را امتحان کند و هر کدام ۸ ثانیه زمان بگیرند تا تایم‌اوت شوند، کاربر ۲۴ ثانیه منتظر می‌ماند تا پاسخی را بگیرد که می‌توانست فوراً از پله‌های پایین‌تر دریافت کند.

پیاده‌سازی این سیستم نیازمند یک تابع descend است که از نوع Rung<T> استفاده می‌کند. این نوع باید شامل یک name (نام)، budgetMs (بودجه زمانی به میلی‌ثانیه) و یک تابع run باشد. منطق برنامه باید قبل از تلاش برای هر پله، بودجه زمانی کل باقی‌مانده را بررسی کند. اگر زمان باقی‌مانده کمتر از budgetMs مورد نیاز آن پله باشد، سیستم باید به‌طور کامل از آن پله بپرد تا از «کار بیهوده» (Dead Work) که توسعه‌دهنده همچنان هزینه آن را به سرویس‌دهنده می‌پردازد، جلوگیری شود.

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

رابط کاربری و نظارت

رابط کاربری (UI) نیز باید بر اساس پله‌ای که محتوا را ارائه می‌دهد، تطبیق یابد. هدف این است که کاربر بداند در مرحله بعد چه کاری می‌تواند انجام دهد:

• مدل ترجیحی: استریم کردن توکنها؛ کاربرانی که ظاهر شدن توکن‌ها را می‌بینند، زمان انتظار کمتری را نسبت به کسانی که به یک اسپینر خیره شده‌اند، حس می‌کنند.
• مدل ارزان‌تر: تغییری در ظاهر نیست، اما پاسخ حاوی شناسه پله (Rung ID) برای تحلیل‌های داخلی است.
• کش‌شده: اگر تازگی داده‌ها بر معنا اثر می‌گذارد (مثلاً خلاصه‌ای از سندی که ۵ دقیقه پیش ویرایش شده و اکنون قدیمی است)، باید سن داده‌ها نمایش داده شود تا کاربر گمراه نشود.
• قطعی: مکانیزم را برچسب بزنید، نه قطعی را. به‌جای «هوش مصنوعی در دسترس نیست»، بنویسید «نمایش نتایج بر اساس کلمات کلیدی».
• غیبت: یک جمله ساده در جای خود. مسیر دستی را باز نگه دارید و دکمه تلاش مجدد (Retry) را فقط در صورتی قرار دهید که احتمال موفقیت مجدد واقعاً وجود داشته باشد.

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

نکته حیاتی این است که سیستم باید ثبت کند کدام پله نتیجه را تولید کرده است. چون نردبان تخریب شکست‌ها را پنهان می‌کند، یک قطعی در سرویس‌دهنده ممکن است هفته‌ها شناسایی نشود اگر سیستم به‌طور خاموش به مدل ارزان‌تر سوییچ کند. تنها راه تشخیص این «تخریب خاموش»، نظارت بر «نرخ نزول» (Rate of Descent) — یعنی درصد درخواست‌هایی که به پله‌های پایین‌تر می‌رسند — است. این چالش دقیقاً همان نقطه‌ای است که استارتاپ‌هایی مانند Lemma برای شکار خطاهای خاموش در عامل‌های هوش مصنوعی روی آن تمرکز کرده‌اند. یک متریک عملیاتی می‌تواند این باشد: «دیروز چهار درصد از پاسخ‌ها از پله سوم تامین شدند».

برای تیم‌هایی که از چندین سرویس‌دهنده استفاده می‌کنند، این راهنما به Multigrid اشاره می‌کند؛ درگاهی که مسیریابی را مدیریت کرده و گزارش می‌دهد کدام مسیر واقعاً پاسخ را داده است. این ابزار لوله‌کشی مربوط به سرویس‌دهنده‌های دوم، مدیریت اعتبارنامه‌ها و تبدیل انواع مختلف خطاها (Error Dialects) را خودکار کرده و ثبت پله‌ها را تسهیل می‌کند.

گام بعدی شما

• قابلیت‌های هوش مصنوعی خود را بازبینی کنید تا ببینید کجا یک جایگزین قطعی (مثل جست‌وجوی ساده) می‌تواند جایگزین اسپینر لودینگ شود.
• سیستم تله‌متری مبتنی بر پله‌ها را پیاده کنید تا بفهمید جایگزین‌های «نامرئی» شما هر چند وقت یک‌بار تجربه کاربر را نجات می‌دهند.
• بودجه زمانی (Timeout) هر پله را به‌گونه‌ای تنظیم کنید که مجموع آن‌ها از آستانه تحمل کاربر (معمولاً ۳ تا ۵ ثانیه) فراتر نرود.

اما مدیریت هزینه‌های این لایه‌بندی حتی پیچیده‌تر است — به تحلیل ما درباره مدل‌های مالی استنتاج در مقیاس بالا مراجعه کنید.