كيفية التعامل مع حالات رفض Fable 5 في الـ API؟

تستدعي claude-fable-5، ويبدو الرد طبيعيًا، ثم تتحقق من الحقل model فتجد: claude-opus-4-8. هذا يعني أن طلبك فعّل مصنف أمان، فرفض Fable 5 الإجابة، ثم تمت معالجة الطلب بواسطة نموذج آخر. هذا ليس خطأً برمجيًا؛ إنه سلوك مقصود يجب أن يتعامل معه التكامل لديك بوضوح في الكود.

جرّب Apidog اليوم

شرحنا الخلفية المعمارية لهذا السلوك في مقال إجراءات الأمان في Fable 5. في هذا الدليل العملي، سنركز على التنفيذ: كيف تعرف أن الطلب أعيد توجيهه، كيف تسجل ذلك، كيف تستخدم معلمة fallbacks التجريبية، وكيف تختبر مسارات الرفض قبل وصولها إلى الإنتاج.

لماذا يعيد Fable 5 توجيه بعض الطلبات

يأتي Claude Fable 5 مع مصنفات أمان تفحص الطلبات قبل وصولها إلى النموذج. تركز هذه المصنفات على ثلاثة مجالات:

• الأمن السيبراني
• علم الأحياء والكيمياء
• تقطير النماذج

عندما يتم تفعيل أحد المصنفات، يرفض Fable 5 الطلب. في واجهات Claude، قد يتولى Claude Opus 4.8 معالجة الطلب مع تنبيه المستخدم. أما في API، فأنت مسؤول عن تحديد سلوك الاسترداد، وهنا تظهر أهمية معلمة fallbacks.

هذه المصنفات ليست ثابتة. بعد تعليق يونيو، أعادت Anthropic تدريب المصنف ضد تقنية كسر حماية تم الإبلاغ عنها، وأصبح الإصدار المحدث يحظر أكثر من 99% من تلك المحاولات. تمت إعادة نشر Fable 5 في 1 يوليو 2026 مع المصنف الجديد. إذا أوقفت تكاملك أثناء الانقطاع، فراجع مركز Fable 5 عاد للعمل لمعرفة التسلسل الزمني وما تغير.

نقطة مهمة هندسيًا: المصنفات موجودة أمام النموذج، وليست داخله. Claude Mythos 5 هو النموذج نفسه بدون المصنفات، لكن الوصول إليه مقصور على المشاركين في مشروع Glasswing. أكثر من 95% من جلسات Fable لا تتضمن أي ارتداد، وفي هذه الحالات يكون أداء Fable 5 مطابقًا فعليًا لأداء Mythos 5. للمقارنة التفصيلية، راجع Fable 5 مقابل Mythos 5.

ماذا يعني ذلك لتطبيقك

Fable 5 و Opus 4.8 نموذجان قويان، لكن لا يجب التعامل معهما كأنهما قابلان للاستبدال دائمًا.

حسب نظرة عامة على النماذج، يعمل Fable 5 بنافذة سياق بحجم 1 مليون توكن، وحد أقصى للإخراج يبلغ 128 ألف توكن، وبتسعير 10 دولارات لكل مليون توكن إدخال و50 دولارًا لكل مليون توكن إخراج. لدى Opus 4.8 تسعيره وسلوكه الخاصان.

لذلك، إذا صممت prompt أو pipeline بدقة لسلوك Fable 5، فقد ينتج Opus 4.8:

• طول إخراج مختلف
• تنسيق مختلف
• سلوكًا مختلفًا في استدعاء الأدوات
• تكلفة مختلفة لكل طلب

تعامل مع الحالات التالية بوضوح:

• الدردشة والمساعدون العامون: غالبًا يمكنك قبول رد Opus 4.8، مع تسجيل الحدث.
• التقييمات والاختبارات الثابتة: لا تقبل إعادة التوجيه بصمت؛ لأنها تلوث نتائج المقارنة.
• الاستخراج المنظم: تحقق من التنسيق بعد الارتداد، خصوصًا إذا كان الـ prompt مضبوطًا لسلوك Fable 5.
• التكاليف والامتثال: سجل النموذج الذي أنتج كل استجابة.
• الأمن وعلوم الحياة: هذه المجالات أقرب لأهداف المصنفات، لذلك يجب اعتبار الارتداد مسارًا أساسيًا في التطبيق وليس حالة نادرة فقط.

اكتشاف الارتداد برمجيًا

الإشارة الأساسية هي الحقل model في استجابة Messages API.

إذا أرسلت الطلب إلى:

claude-fable-5

لكن الاستجابة عادت من:

claude-opus-4-8

فقد تمت إعادة توجيه الطلب.

سجل أيضًا الحقول التالية:

• stop_reason: لمعرفة ما إذا كان الطلب رُفض صراحة.
• usage: لحساب التكلفة حسب النموذج الذي أنتج الرد.

مثال Python:

response = client.messages.create(
    model="claude-fable-5",
    max_tokens=16000,
    messages=[
        {"role": "user", "content": prompt}
    ],
)

if response.stop_reason == "refusal":
    # تم الرفض بدون محتوى قابل للاستخدام
    handle_refusal(response)

elif not response.model.startswith("claude-fable-5"):
    logger.info(
        "fallback served_by=%s input_tokens=%d output_tokens=%d",
        response.model,
        response.usage.input_tokens,
        response.usage.output_tokens,
    )

    handle_fallback_response(response)

else:
    handle_fable_response(response)

إذا كنت تبدأ التكامل من الصفر، ابدأ بدليل كيفية استخدام Claude Fable 5 API، ثم أضف فحص response.model بمجرد عمل أول استدعاء بنجاح.

استخدام معلمة fallbacks

بدون إعداد fallbacks، إذا رفض Fable 5 الطلب، تحصل على استجابة رفض فقط، ويصبح منطق إعادة المحاولة مسؤوليتك.

مع fallbacks، ينفذ الخادم إعادة المحاولة تلقائيًا: عندما يرفض Fable 5 الطلب، يعيد API تشغيل الطلب نفسه على نموذج احتياطي تحدده أنت، ثم يعيد استجابة ذلك النموذج.

المعلمة تجريبية على Claude API ومنصة Claude على AWS، وموثقة في صفحة Anthropic حول الرفض والارتداد. عند الإطلاق، الهدف الاحتياطي المدعوم هو:

claude-opus-4-8

مثال:

response = client.beta.messages.create(
    model="claude-fable-5",
    max_tokens=16000,
    betas=["server-side-fallback-2026-06-01"],
    fallbacks=[
        {"model": "claude-opus-4-8"}
    ],
    messages=[
        {"role": "user", "content": prompt}
    ],
)

print(response.model)

إذا تمت إعادة التوجيه، سيطبع المثال:

claude-opus-4-8

نمط التعامل الموصى به:

def call_fable_with_fallback(prompt: str):
    response = client.beta.messages.create(
        model="claude-fable-5",
        max_tokens=16000,
        betas=["server-side-fallback-2026-06-01"],
        fallbacks=[{"model": "claude-opus-4-8"}],
        messages=[{"role": "user", "content": prompt}],
    )

    if response.stop_reason == "refusal":
        return {
            "status": "refused",
            "model": response.model,
            "content": None,
        }

    return {
        "status": "fallback" if response.model != "claude-fable-5" else "ok",
        "model": response.model,
        "content": response.content,
        "usage": response.usage,
    }

الفوترة تعمل كالتالي: الطلب الذي تم رفضه قبل إنتاج أي مخرجات لا تتم فوترته. إذا أجاب النموذج الاحتياطي، تدفع أسعار النموذج الاحتياطي لكل توكن. لا تتم فوترتك مرتين لنفس الإجابة.

لكن انتبه للقيود التالية:

• fallbacks مرفوضة في Batches API.
• غير متاحة على Amazon Bedrock أو Google Vertex AI أو Microsoft Foundry.
• إذا رفض النموذج الاحتياطي أيضًا، ستعود الاستجابة النهائية مع stop_reason: "refusal".

لذلك، حتى مع تفعيل fallbacks، احتفظ دائمًا بفرع واضح لمعالجة الرفض.

تصميم سياسة المعالجة في منتجك

الآلية سهلة: افحص model و stop_reason. القرار الأصعب هو: ماذا يجب أن يفعل المنتج عندما يحدث ارتداد؟

اختر واحدة من هذه السياسات حسب حالة الاستخدام.

1. قبول إجابة Opus 4.8

مناسبة لـ:

• تطبيقات الدردشة
• المساعدين العامين
• الوكلاء
• التوليد العام

الإعداد العملي:

• فعّل fallbacks
• سجل النموذج الذي أجاب
• أعد النتيجة للمستخدم
• راقب معدل الارتداد

if response.model == "claude-opus-4-8":
    metrics.increment("llm.fallback")

2. إعادة المحاولة بطلب معدل

مناسبة عندما يكون اتساق النموذج أهم من زمن الاستجابة، مثل:

• خطوط معالجة البيانات
• التقييمات
• الاستخراج المنظم
• التقارير الآلية

لا ترسل الطلب نفسه مجددًا إلى Fable 5، لأن المصنف الذي رفضه غالبًا سيرفضه مرة أخرى.

بدلًا من ذلك:

• أعد صياغة الطلب بعيدًا عن سبب التفعيل
• أو وجه المهمة مباشرة إلى Opus 4.8
• أو أرسلها إلى مراجعة بشرية

3. إظهار الارتداد للمستخدم

مناسبة عندما:

• يدفع العميل مقابل Fable 5 تحديدًا
• يتطلب الامتثال إظهار النموذج المستخدم
• تريد منح المستخدم خيار إعادة التشغيل

مثال رسالة واجهة:

تمت معالجة هذا الطلب بواسطة claude-opus-4-8 لأن الطلب لم يمر عبر مصنفات Fable 5.

بغض النظر عن السياسة، راقب معدل الارتداد. إذا كان قريبًا من الصفر، فهذا يتوافق مع خط الأساس العام. إذا تجاوز بضعة بالمئة، راجع الـ prompts لأنك غالبًا تقترب من مجال محفز للمصنفات.

اختبار مسارات الرفض قبل الإنتاج

مسار الارتداد قد يعمل في العرض التجريبي ثم يفشل لاحقًا؛ لأن الرفض نادر بطبيعته. لا تنتظر مستخدمًا حقيقيًا ليكون أول من يختبر سجلاتك أو واجهتك أو منطق إعادة المحاولة.

ابنِ مجموعة اختبار صغيرة تتضمن:

• مطالبات حميدة يجب أن تبقى على claude-fable-5
• مطالبات قريبة من الأمن السيبراني
• مطالبات قريبة من علم الأحياء أو الكيمياء
• مطالبات يجب أن ترفض أو ترتد حسب سياسة المنصة

باستخدام Apidog، يمكنك تعريف نقطة نهاية Claude Messages مرة واحدة، حفظ مفتاح API في متغير بيئة، ثم تشغيل سيناريوهات تحقق على الاستجابة.

تحقق في كل اختبار من:

• هل model هو المتوقع؟
• هل stop_reason يساوي "refusal"؟
• هل توجد content قابلة للاستخدام؟
• هل تغير عدد التوكنات أو النموذج الذي تمت فوترته؟

مثال assertions منطقية:

response.model == "claude-fable-5"
response.stop_reason != "refusal"

ولحالة الارتداد:

response.model == "claude-opus-4-8"
response.stop_reason != "refusal"

شغّل هذا السيناريو في CI أو بجدولة يومية. عندما تعيد Anthropic تدريب المصنفات، كما حدث قبل إعادة النشر في 1 يوليو، ستعرف بسرعة ما إذا كانت حالاتك الحدية ما زالت تتصرف كما يتوقعها كود المعالجة لديك.

الأسئلة الشائعة

هل تكلف معلمة fallbacks مبلغًا إضافيًا؟

لا. الطلب الذي يتم رفضه قبل إنتاج أي مخرجات لا تتم فوترته. إذا أجاب النموذج الاحتياطي، تدفع تسعير ذلك النموذج لكل توكن. لا تتم فوترتك مرتين لنفس الإجابة.

هل كل المطالبات المتعلقة بالأمان ستؤدي إلى ارتداد؟

لا. المصنفات تستهدف الطلبات الضارة في الأمن السيبراني، وعلم الأحياء والكيمياء، وتقطير النماذج، وليس المواضيع نفسها. تمر معظم أعمال الهندسة الأمنية دون ارتداد. لكن الإيجابيات الخاطئة قد تحدث بالقرب من تلك المجالات، لذلك يجب الاختبار والتسجيل.

توقفت عن استخدام Fable 5 أثناء تعليق يونيو. هل يمكن العودة؟

نعم. مع إعادة النشر في 1 يوليو، أصبح المصنف المعاد تدريبه مباشرًا، ولم تتغير واجهة API. راجع دليل التبديل مرة أخرى إلى Fable 5 API، ثم أضف fallbacks وفحص response.model ضمن مسار العودة.

خلاصة

إعادة توجيه Fable 5 قرار تصميم، وليست خطأً عابرًا. عالجها كجزء طبيعي من تكامل API:

• افحص response.model في كل استدعاء.
• تعامل مع stop_reason == "refusal".
• فعّل fallbacks إذا كان مناسبًا لمنتجك.
• سجل النموذج والتوكنات لأغراض التكلفة والامتثال.
• اختبر حالات الرفض والارتداد قبل الإنتاج.

ابنِ مجموعة حالات حدية في Apidog، تحقق من model و stop_reason، وشغّلها بانتظام. يمكنك تنزيل Apidog وتشغيل مجموعة اختبار الرفض قبل النشر التالي.