ارائهدهنده هوش مصنوعی شما یک نقطه شکست واحد است
جمعه گذشته، وزارت بازرگانی ایالات متحده نامهای به Anthropic ارسال کرد. تا همان عصر، Fable 5 و Mythos 5 ناپدید شدند.
آنها منسوخ نشده بودند. محدودیت سرعت (throttling) هم به آنها اعمال نشده بود. آنها صرفاً از بین رفته بودند.
فراخوانیهای API خطای 404 برمیگرداندند. نشستهای زنده در میانه گفتگو با شکست مواجه شدند. اپلیکیشنهایی که به آن مدلها وابسته بودند، از کار افتادند. این اتفاق سه روز پس از عرضه رخ داد. هیچ هشدار و هیچ بازه زمانی برای مهاجرت وجود نداشت.
ما خوششانس بودیم چون آن مدلها جدید بودند. هنوز کسی وابستگی عمیقی به آنها ایجاد نکرده بود. تصور کنید این اتفاق برای مدلی بیفتد که شش ماه است هر روز از آن استفاده میکنید.
اگر یک نامه دولتی میتوانست پایگاه داده اصلی شما را از کار بیندازد، آیا آن را بدون سیستم جایگزین (failover) اجرا میکردید؟ خیر، نمیکردید. با این حال، اکثر تیمها این کار را با هوش مصنوعی انجام میدهند.
بسیاری از تیمها با هوش مصنوعی مانند برق رفتار میکنند. کلیدی را میزنید و انتظار روشنایی دارید. به منبع یا اتفاقی که هنگام قطع برق میافتد فکر نمیکنید. یک مدل انتخاب میکنید، یک endpoint را به صورت hardcode مینویسید و محصول را عرضه میکنید.
این مهندسی نیست. این معماریِ مبتنی بر امید است.
مدلها ممکن است به دلایل زیر ناپدید شوند:
- دلایل نظارتی (Regulatory)
- تغییرات سیاستگذاری
- مسائل ژئوپلیتیک
وضعیت Anthropic یک باگ یا شکست زیرساختی نبود. آن یک کلید قطع اضطراری نظارتی (regulatory kill switch) بود.
شما باید در لایه مدل خود تابآوری ایجاد کنید. از این الگوها استفاده کنید:
- فراخوانیهای مدل خود را انتزاعی (Abstract) کنید. از یک رابط (interface) استفاده کنید تا اپلیکیشن شما اهمیتی ندهد که کدام ارائهدهنده پاسخ را ارسال میکند.
- از چندین ارائهدهنده استفاده کنید. تعویض یک ارائهدهنده باید یک تغییر در پیکربندی (configuration) باشد، نه بازنویسی کامل کد.
- از مدلهای با وزن باز (open-weight) استفاده کنید. اگر مدل را خودتان اجرا کنید، هیچکس نمیتواند از راه دور آن را خاموش کند. این مدلها مانند یک ژنراتور در زمان قطع برق شبکه عمل میکنند.
- کاهش تدریجی عملکرد (graceful degradation) را پیادهسازی کنید. یک مدل کوچکتر یا قدیمیتر بهتر از یک اپلیکیشن از کار افتاده است.
نرخ خطاهای خود را مانیتور کنید. اگر جهش ناگهانی داشتند، کلید قطع را بزنید و ترافیک را به سیستم جایگزین (fallback) خود هدایت کنید.
با هوش مصنوعی خود مانند هر وابستگی حیاتی دیگر در محیط عملیاتی (production) رفتار کنید. برای شکست طراحی کنید.
آیا معماری شما فرض را بر این میگذارد که ارائهدهنده شما ممکن است از کار بیفتد؟ اگر نه، شما در معرض خطر هستید.
آیا سیستم جایگزین چند-ارائهدهندهای را در پشته (stack) خود ساختهاید؟ در کامنتها به من بگویید.
Source: https://dev.to/aws/your-ai-provider-is-a-single-point-of-failure-26i2
Optional learning community: https://t.me/GyaanSetuAi