429 و5xx والمهلات: الممارسات الهندسية لتحمل الأعطال في بوابة LLM

صنّف أولاً، ثم قرر كيف تتعامل

«أعد المحاولة ثلاث مرات لكل خطأ» هو الممارسة الخاطئة الأكثر شيوعاً. دلالات رموز الأخطاء المختلفة متباينة تماماً، ولذا يجب أن تختلف استراتيجية المعالجة أيضاً. الجدول التالي هو الاستراتيجية التي تعتمدها بوابتنا فعلياً، ويمكن أن يكون مرجعاً لتنفيذك الخاص.

• فشل الاتصال / DNS / TLS: التبديل الفوري إلى القناة الاحتياطية.
• Timeout (لم يبدأ الإخراج بعد): التبديل إلى القناة الاحتياطية، بحد أقصى 1~2 مرة.
• HTTP 429: تبديل القناة بعد تبريد قصير، مع خفض وزن تلك القناة في الوقت نفسه.
• HTTP 5xx: يُحتسب في نافذة الفشل، ويؤدي الفشل المتتالي إلى تفعيل قاطع الدائرة.
• 401 / 403: مشكلة في بيانات الاعتماد أو الصلاحيات، عطّل تلك البيانات وأطلق تنبيهاً، ولا تعد المحاولة.
• رصيد غير كافٍ: أوقف تلك القناة مؤقتاً وأطلق تنبيهاً.
• خطأ المعاملات 400: يُعاد إلى العميل مباشرة بعد التطبيع، دون إعادة محاولة ودون فوترة.
• انقطاع SSE بعد إخراج جزء من المحتوى: يُعاد upstream_stream_error، والافتراضي هو عدم إعادة المحاولة.

لماذا لا يمكن إعادة المحاولة ببساطة عند انقطاع SSE

بمجرد أن يبدأ الرد المتدفق بإخراج الرموز إلى العميل، فهذا يعني أن الطبقة العلوية أنتجت إخراجاً (سيُفوتر عليه). إذا بدّل البوابة حينها بصمت إلى قناة أخرى وأعادت من البداية، فسيرى المستخدم محتوى مكرراً، وستدفع أنت ثمن مخرجين.

الطريقة الصحيحة هي اعتبار هذا التدفق المقطوع نجاحاً جزئياً: إعادة رمز خطأ يخبر العميل بأن «الطبقة العلوية انقطعت»، ويترك لجانب الأعمال قرار عرض المحتوى الموجود + تلميح لإعادة المحاولة، أو إعادة المحاولة كاملة.

قاطع الدائرة: الطبقة الأهم من إعادة المحاولة

إعادة المحاولة معالجة لطلب واحد، أما قاطع الدائرة فهو حكم على الحالة الإجمالية خلال فترة زمنية. عندما يبلغ فشل قناة ما حداً متتالياً، تُعلَّم مباشرة بأنها «مفتوحة»، ولا يُرسَل إليها أي حركة مرور لفترة، ثم يُسمح بكمية صغيرة من حركة الاستكشاف (نصف مفتوح)، وبعد نجاح الاستكشاف عدة مرات تُستعاد بالكامل (مغلق).

بدون قاطع الدائرة، ستزيد إعادة المحاولة الضغط على قناة معطلة أصلاً، وسترفع متوسط زمن الاستجابة لدى العميل بشكل حاد.

التماثل والفوترة في إعادة المحاولة

• الطلبات غير المتدفقة: تُفوتر بعد إعادة المحاولة وفق usage المحاولة الناجحة النهائية فقط.
• الطلبات المتدفقة: المحاولة التي أخرجت رموزاً قد أنتجت تكلفة فعلية في الطبقة العلوية، ويجب تسجيلها، ولا يجوز محو الحساب بسبب إعادة المحاولة.
• خصّص request_id لكل طلب مستخدم، تتشاركه كل المحاولات، فيمكن لاحقاً إعادة تشغيل «لماذا سلك هذا المسار» بالكامل.
• يجب أن تمر الاستردادات/التسويات عبر قيود دفتر الأستاذ، ولا يجوز تعديل الرصيد مباشرة.

ما فعله Admesh بالفعل

الاستراتيجية أعلاه هي السلوك الافتراضي في بوابة Admesh: التبديل التلقائي بين عدة قنوات علوية لنفس public_model، وكل قرار توجيه يُسجَّل في قاعدة البيانات، ويمكن للعميل رؤية request_id والنموذج المستخدم فعلياً وحالة سلامة القناة في سجلات الاستخدام؛ وتُعاد رموز الأخطاء بصيغة موحدة (error.type / error.code / request_id).

من الجدير بالملاحظة: التوجيه يحدث فقط داخل مجموعة قنوات نفس public_model، ولن يتم تبديلك إلى نموذج من مزوّد آخر لمجرد أنك طلبت anthropic/xxx — فالاستبدال عبر النماذج يغيّر جودة الإخراج مباشرة، وهذا قرار لا يمكننا اتخاذه نيابة عنك.

عرض مرجع رموز الأخطاء السريع →