قبلا وقتی درباره Disaster Recovery یا همان DR حرف میزدیم، معمولا سناریوها مشخص بود: اگر دیتابیس یا یک region از دسترس خارج شد چهکار کنیم؟ آخرین backup کجاست و چقدر طول میکشه سرویس رو برگردونیم؟
اما حالا یک dependency جدید وارد مسیرهای اصلی کسبوکارها شده: AI
منظورم اون قسمتی نیست که Cursor یا کلاد مشکل دارن و دیگه نمیشه کدنویسی کرد. اون قسمت رو خیلی ساده میشه هندل کرد. مشکل جاییه که پروسه دیپلوی یا خود سیستم با LLM گره خورده و دیگه فقظ نقش تسریعکننده یا بهبوددهنده رو نداره، بلکه مثل دیتابیس یا storage بخشی از خود سیستم شده.
⚠️ خرابی LLM هم فقط این نیست که API سرویس دهندش خطای 500 میده.
ممکنه سرویسدهنده rate limit رو تغییر بده، مدلی رو که استفاده میکنیم حذف کنه یا نسخه جدید مدل خروجی متفاوتی تولید کنه. حتی بدتر، ممکنه API کاملاً در دسترس باشه و پاسخ هم معتبر به نظر برسه، اما کیفیت یا رفتار مدل به شکلی تغییر کرده باشه که دیگه نتونیم به سازوکارمون اعتماد کنیم.
وابستگی هم فقط به خود مدل و سرویسدهندهاش نیست. لایههایی که برای استفاده از مدل دورش ساختیم هم شامل میشن؛ مثل agentها، وکتور دیتابیس، promptها، دادهای که برای ساخت context استفاده میکنیم. همه اینها بخشی از این زنجیره هستن.
برای همین DR در سیستمهای مبتنی بر AI نباید به داشتن یک API key از سرویسدهنده دوم خلاصه بشه.
مدل جایگزین ممکنه همون context window، فرمت JSON، tool calling یا کیفیت مدل اصلی رو نداشته باشه. پرامپتی که با یک مدل خوب کار میکنه لزوماً با مدل دیگه همون نتیجه رو نمیده. حتی یک تغییر کوچک در رفتار مدل میتونه باعث بشه agent ابزار اشتباهی رو انتخاب کنه یا خروجیای تولید کنه که سیستم بعدی نتونه پردازشش کنه.
همونطور که قبلاً سناریوهای DR رو مستند و تست میکردیم، الان هم باید همین کار رو برای جز به جز بخشهایی که LLM رو واردشون کردیم انجام بدیم. باید بدونیم هر بخش موقع اختلال چطور عمل میکنه و برگشتنش به حالت عادی چقدر طول میکشه.