شکستهای API هوش مصنوعی در محیط عملیاتی (Production)
پیامهای خطا بهندرت تمام ماجرا را وقتی که قابلیت هوش مصنوعی شما ساعت ۲ صبح از کار میافتد، بازگو میکنند. من یک سال است که با ادغامهای OpenAI و Anthropic کار میکنم. یاد گرفتهام که شکستها را بر اساس معنای آنها برای عیبیابی (debugging) دستهبندی کنم.
مدیریت محدودیتهای نرخ درخواست (Rate Limits)
خطاهای ۴۲۹ در OpenAI دلایل متفاوتی دارند. برای اینکه بدانید چگونه واکنش نشان دهید، باید کد خطا را بررسی کنید.
- محدودیتهای درخواست در دقیقه (RPM) در عرض چند ثانیه بازیابی میشوند.
- محدودیتهای توکن در دقیقه (TPM) در عرض ۶۰ ثانیه بازیابی میشوند.
- اتمام سهمیه ماهانه (Monthly quota) تا زمانی که اعتبار اضافه نکنید یا چرخه صورتحساب ریست نشود، همچنان با خطا مواجه خواهد بود.
برای مشکلات مربوط به سهمیه (quota)، از روش exponential backoff استفاده نکنید. این کار فقط وقت شما را تلف میکند.
خطاهای ۵۲۹ در Anthropic به این معناست که ارائهدهنده (provider) تحت فشار بیش از حد است. با این خطا مانند یک خطای ۵۰۳ برخورد کنید. مشکل از سمت آنهاست. عقبنشینی کنید و به تیم خود اطلاع دهید.
مدیریت خطاهای ۴۰۰
این شکستها معمولاً تقصیر شماست. مراقب این سه الگو باشید:
- عدم تطابق نسخه مدل. شما نامی را در یک جا بهروزرسانی کردهاید اما در هندلرِ تلاش مجدد (retry handler) خود این کار را انجام ندادهاید.
- سرریز شدن پنجره بافت (Context window). تاریخچه گفتگو بیش از حد بزرگ شده است. این اتفاق اغلب به دلیل منطق ناقصِ کوتاه کردن (truncation) رخ میدهد.
- شکست در اعتبارسنجی طرحواره (Schema validation). ساختار JSON شما دارای انواع دادهای پشتیبانینشده یا ارجاعات بازگشتی (recursive references) است.
برای رفع این موارد، تمام محتوای درخواست (request payload) را برای خطاهای ۴۰۰ ثبت (log) کنید. ابتدا دادههای کاربر را حذف (redact) کنید. بدنه پاسخ (response body) دقیقاً به شما میگوید که کدام فیلد با خطا مواجه شده است.
مدیریت زمانهای انتظار (Timeouts)
ردیابی تایماوتها دشوار است زیرا ارائهدهنده هیچ مشکل خاصی را مشاهده نمیکند.
- تایماوت اتصال (Connect timeout). فرآیند دستدادن (handshake) شکست خورده است. این اتفاق در زمان اختلالات جزئی ارائهدهنده (brownouts) یا مشکلات DNS رخ میدهد. شبکه خروجی خود را بررسی کنید.
- تایماوت خواندن (Read timeout). مدل شروع به کار کرده اما تمام نشده است. اپلیکیشن شما باید خروجیهای استریم ناقص را مدیریت کند.
- تایماوت درگاه (Gateway timeout - 504). پروکسی شما زودتر از موعد تایماوت داده است. درخواست ممکن است همچنان در سمت ارائهدهنده در حال اجرا باشد. قبل از تلاش مجدد، از روش حذف موارد تکراری (deduplication) استفاده کنید.
برای عیبیابی، تایماوت اتصال را از تایماوت خواندن جدا کنید. زمان رسیدن به اولین توکن (time-to-first-token) را ثبت کنید تا متوجه شوید تأخیر (latency) در کجا رخ میدهد.
مدیریت مشکلات ارائهدهنده
- یک خطای ۵۰۰ اغلب با یک تلاش مجدد پس از دو ثانیه برطرف میشود.
- یک خطای ۵۰۳ به این معناست که کیفیت سرویس کاهش یافته است. اگر صفحه وضعیت (status page) ارائهدهنده نشاندهنده یک حادثه است، از یک قطعکننده مدار (circuit breaker) استفاده کنید.
- همیشه ثبت کنید که کدام نسخه از مدل با خطا مواجه شده است. مدلهای مختلف سطوح قابلیت اطمینان متفاوتی دارند.
از پریدن مداوم از لاگها به Slack دست بردارید. ابتدا صفحه وضعیت ارائهدهنده را چک کنید. این کار ۲۰ دقیقه از وحشت و هراس شما را کم میکند.
Optional learning community: https://t.me/GyaanSetuAi