الاستدلال الهجين في Claude Fable 5: وضع التفكير مقابل وضع السرعة

يُبقي محرك الاستدلال الجديد Claude Fable 5 من Anthropic التفكير العميق مُفعّلاً في كل طلب، ويتيح للمطورين رفع عمق التفكير أو خفضه بدلاً من ذلك. تاريخيًا، كانت النماذج اللغوية الكبيرة (LLMs) تعمل وفق معلمات حوسبة ثابتة، حيث تولّد الرموز (tokens) بسرعة موحدة بغض النظر عن مدى تعقيد الاستعلام؛ فكانت التحيات البسيطة تستهلك نفس طاقة المعالجة التي تستهلكها البراهين الرياضية المتقدمة. ومع إطلاق Fable 5، تقدّم Anthropic إطار عمل للتفكير الهجين (hybrid reasoning) يكون فيه التفكير نشطًا دائمًا، وتتحكم أنت في مقدار الجهد الذي يبذله النموذج عبر إعداد واحد هو effort. يوضّح هذا الشرح كيفية عمل واجهة برمجة التطبيقات (API)، وكيفية اختيار مستوى الجهد، وكيفية تطبيق هذه البنية في مسارات الإنتاج الفعلي.

[!WARNING] تحذير بشأن قيود واجهة برمجة التطبيقات (API): التفكير مُفعّل دائمًا في Fable 5، لذا لا يمكنك إيقافه. إن تمرير thinking: {type: "enabled"} أو thinking: {type: "disabled"}، أو تعيين قيمة budget_tokens، يُعيد خطأ HTTP 400 — فقد أُزيلت هذه المعلمات. تحكّم في عمق التفكير باستخدام output_config: {effort: "..."} بدلاً من ذلك، واترك مساحة كافية من max_tokens للإجابة النهائية عند مستويات الجهد الأعلى.

النقاط الرئيسية:

• اضبط الجهد لا المفاتيح: عيّن output_config.effort إلى low أو medium أو high أو xhigh أو max — لا يوجد مفتاح تشغيل/إيقاف.
• التفكير تلقائي: احذف thinking أو مرّر {type: "adaptive"}؛ فالتفكير التكيّفي يعمل في كل طلب.
• تحليل التدفقات: تعامل مع كتل محتوى thinking عبر فوارق thinking_delta في تدفقات الخادم في الوقت الفعلي.
• إدارة الفوترة: يؤدي التخزين المؤقت لرسائل النظام التوجيهية (prompt caching) إلى تقليل دورات معالجة التفكير المكررة.

شرح محرك الاستدلال الهجين لـ Claude

الابتكار الأساسي في Fable 5 هو قدرته على التفكير في المشكلة قبل إخراج الإجابة النهائية؛ ما يعني أن النموذج يُعدّ مسودة منطقية للحل داخليًا قبل الاستجابة لطلبات العميل. والأهم من ذلك أن مرحلة التفكير هذه مُفعّلة دائمًا — لا يمكنك إيقافها، ولا يوجد “وضع سرعة” منفصل تنتقل إليه.

عند إرسال سؤال معقد، لا يحاول النموذج تخمين الكلمة التالية فورًا، بل يولّد رموز تفكير داخلية تحاكي عملية استدلال خطوة بخطوة. وتحسّن هذه البنية الدقة بشكل كبير في المسائل الرياضية والبرمجة والتقييم المنطقي.

ولدعم متطلبات المؤسسات المختلفة، تتيح Anthropic للمطورين ضبط عمق ذلك التفكير عند الطلب عبر عنصر تحكم واحد هو effort. فعند مستوى الجهد المنخفض (low) يفكّر النموذج بإيجاز ويجيب بسرعة، ما يُبقي زمن الانتقال وإنفاق الرموز منخفضين. وعند مستوى الجهد المرتفع (high) أو الأقصى (max) يستدل بعمق أكبر بكثير، باذلاً الحوسبة الإضافية اللازمة للرياضيات الصعبة والمنطق متعدد الخطوات والأكواد المعقدة. وتُعبَّر مقايضة السرعة مقابل العمق بالكامل عبر مستوى الجهد هذا وليس عبر مفتاح تشغيل/إيقاف.

تهيئة معلمات واجهة برمجة التطبيقات لـ Fable 5

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

يُضبط عمق التفكير عبر كتلة output_config. وداخلها، يقبل الحقل effort إحدى القيم "low" أو "medium" أو "high" أو "xhigh" أو "max"، وتحل هذه القيمة الواحدة محل مقياس ميزانية الرموز القديم. ولا تُمرّر كتلة thinking على الإطلاق في الحالة البسيطة — فالتفكير التكيّفي يعمل تلقائيًا. يوضّح كود JavaScript أدناه كيفية هيكلة هذا الطلب:

 1import Anthropic from "@anthropic-ai/sdk";
 2
 3export default {
 4  async fetch(request, env) {
 5    const anthropic = new Anthropic({ apiKey: env.ANTHROPIC_API_KEY });
 6
 7    try {
 8      const response = await anthropic.messages.create({
 9        model: "claude-fable-5",
10        max_tokens: 8192,
11        // Thinking is always on for Fable 5; dial reasoning depth with effort:
12        output_config: { effort: "high" }, // "low" | "medium" | "high" | "xhigh" | "max"
13        messages: [
14          {
15            role: "user",
16            content: "Generate an optimised database migration script for 10 million records."
17          }
18        ]
19      });
20
21      return Response.json(response);
22    } catch (err) {
23      return Response.json({ error: err.message }, { status: 500 });
24    }
25  }
26};

لا تحاول تعطيل التفكير أو تمرير قيمة budget_tokens: فإن thinking: {type: "disabled"} وthinking: {type: "enabled"} وأي حقل budget_tokens تُعيد جميعها خطأ HTTP 400 في Fable 5، لأن هذه المعلمات أُزيلت في هذا النموذج (وفي Opus 4.7 و4.8). اختر مستوى جهد أقل للسرعة وأعلى للعمق، واترك مساحة كافية في max_tokens للإجابة النهائية عند رفع مستوى الجهد. لمزيد من التفاصيل حول البنى البرمجية بدون خادم، اقرأ دليلنا حول بناء واجهة برمجة تطبيقات بدون خادم باستخدام Cloudflare Workers .

معالجة رموز التفكير في التدفقات (Streams)

بالنسبة للتطبيقات التي تعمل في الوقت الفعلي مثل واجهات الدردشة، يعد بث الاستجابات أمرًا ضروريًا. يرسل نموذج Fable 5 كلاً من خطوات التفكير والمحتوى النهائي عبر قنوات أحداث الخادم (SSE - Server-Sent Events).

أثناء التدفق، يصل التفكير على هيئة كتل محتوى thinking تُسلَّم عبر أحداث content_block_delta التي يكون delta.type فيها هو "thinking_delta". اقرأ النص من delta.thinking، واقرأ الإجابة النهائية من فوارق text_delta المعتادة. ولا تُعاد سلسلة التفكير الخام أبدًا — ولاستقبال ملخص قابل للقراءة يجب أن تختار ذلك صراحةً عبر thinking: {type: "adaptive", display: "summarized"}؛ أما القيمة الافتراضية "omitted" فتبثّ نص تفكير فارغًا. ويبدو المعالج المبسّط كما يلي:

 1const stream = await anthropic.messages.stream({
 2  model: "claude-fable-5",
 3  max_tokens: 8192,
 4  output_config: { effort: "high" },
 5  thinking: { type: "adaptive", display: "summarized" },
 6  messages: [{ role: "user", content: prompt }]
 7});
 8
 9for await (const event of stream) {
10  if (event.type === "content_block_delta") {
11    if (event.delta.type === "thinking_delta") {
12      process.stdout.write(event.delta.thinking); // summarised reasoning
13    } else if (event.delta.type === "text_delta") {
14      process.stdout.write(event.delta.text);      // final answer
15    }
16  }
17}

يمكنك توجيه أجزاء thinking_delta هذه إلى لوحة قابلة للطي تحمل عنوان “التفكير…"، أو تجاهلها وعرض الإجابة فقط. للحصول على مرجع تفصيلي حول دمج خدمات Anthropic، ارجع مباشرةً إلى وثائق مطوري Anthropic .

أدِر حساب الرموز الخاص بك بعناية؛ فرموز التفكير تُحتسب ضمن فوترة المخرجات في واجهة برمجة التطبيقات. لذلك، طبّق تخزينًا مؤقتًا قويًا للرسائل التوجيهية لتجنب إعادة تشغيل دورات التفكير على المدخلات المتطابقة. وعند التخطيط للنشر في بيئة الإنتاج، يساعدك تتبّع هذه المقاييس عبر طبقة مراقبة على الحافة (edge telemetry) في تحديد الحالات التي يتجاوز فيها استخدام رموز التفكير الحدود المعتادة.

خطوات دمج واجهة برمجة التطبيقات بالتفصيل

لتطبيق محرك الاستدلال داخل تطبيقاتك، ابدأ بتحديث حزمك البرمجية المحلية لتتوافق مع مواصفات Fable 5؛ فإصدارات SDK القديمة لا تزال ترسل budget_tokens، وهو ما يُطلق الآن أخطاء مخطط HTTP 400 أثناء تسلسل واجهة برمجة التطبيقات (API serialisation).

بعد ذلك، حدّد عتبات واضحة لزمن الانتقال؛ فبالنسبة للتدفقات الحوارية البسيطة أو التحيات، عيّن مستوى جهد منخفض (low) لتقليل زمن الاستجابة. واحتفظ بمستوى الجهد المرتفع (high) أو الأقصى (max) لمهام مثل توليد الأكواد أو الرياضيات.

بالإضافة إلى ذلك، خزّن بيانات اعتماد واجهة برمجة التطبيقات الخاصة بك بأمان داخل معلمات البيئة بدون خادم باستخدام أدوات مثل Wrangler. وعند التعامل مع أحداث مخرجات البث، اكتب معالجات واجهة أمامية قوية لتصفية حزم thinking_delta؛ وهو أمر ضروري إلا إذا كنت تنوي عرض خطوات تفكير النموذج مباشرةً للمستخدم. وأخيرًا، راقب معدلات نجاح التخزين المؤقت للرسائل التوجيهية للتأكد من أن التخزين المؤقت يقلّل من استهلاك الرموز غير الضروري. لمعرفة المزيد حول تصميمات واجهات برمجة التطبيقات على الحافة، استكشف شرح Cloudflare Workers AI .

الجهد المنخفض مقابل الجهد المرتفع في لمحة

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

النقطة الجوهرية هي أن رموز التفكير رموز مخرجات حقيقية. فالطلب ذو الجهد المنخفض يفكّر بإيجاز ويُحاسَب في معظمه على الإجابة التي يكتبها؛ أما الطلب ذو الجهد المرتفع أو الأقصى فقد يولّد حجمًا كبيرًا من رموز التفكير قبل أن تظهر الكلمة الأولى من الاستجابة أصلاً. التفكير لا يتوقف أبدًا — أنت فقط تختار مقدار ما تنفقه منه.

متى تستخدم كل مستوى جهد

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

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

اختر مستوى جهد مرتفع أو أقصى عندما تتسبب إجابة خاطئة واحدة في تكبد تكلفة حقيقية — مثل كود ترحيل بيانات تالف، أو عرض سعر تم حسابه بشكل خاطئ، أو مسار برمجي غير آمن — أو عندما تتضمن المهمة عدة خطوات مترابطة يجب على النموذج معالجتها معًا. هذه هي أعباء العمل التي يشتري فيها تحمّل بضع ثوانٍ إضافية من زمن الانتقال قفزة ذات معنى في الموثوقية.

مثال عملي: مقايضات زمن الانتقال والتكلفة

لنفترض وجود مساعد دعم عملاء يتعامل مع 50,000 طلب يوميًا. وبافتراض أن كل إجابة نهائية تبلغ حوالي 250 رمزًا، وأن مستوى الجهد المنخفض (low) يضيف حفنة قليلة فقط من رموز التفكير، وأن مستوى الجهد المرتفع (high) يستهلك نحو 1,500 رمز تفكير في الاستعلام الصعب النموذجي. كل سعر رمز وارد أدناه توضيحي — تعامل معه كتمرين نمذجة لا كعرض سعر — بافتراض أن سعر المخرجات يبلغ 15 دولارًا لكل مليون رمز.

يؤدي تشغيل كل طلب بجهد منخفض إلى توليد 50,000 × 250 = 12.5 مليون رمز مخرجات يوميًا، أي نحو 188 دولارًا يوميًا بالسعر التوضيحي. أما تشغيل كل طلب بجهد مرتفع فيُحاسَب على 50,000 × (1,500 + 250) = 87.5 مليون رمز يوميًا، أي نحو 1,313 دولارًا يوميًا — سبعة أضعاف التكلفة السابقة، يُنفَق معظمها في الاستدلال عبر استعلامات لم تكن بحاجة إلى العمق الإضافي من الأساس.

والآن وجّه الطلبات بشكل انتقائي. لنفترض أن مصنّفًا رخيصًا منخفض الجهد يقرر أن 15% فقط من حركة المرور معقدة بالفعل. إن إرسال 7,500 طلب إلى الجهد المرتفع و42,500 طلب إلى الجهد المنخفض يعطي 13.1 مليون + 10.6 مليون ≈ 23.7 مليون رمز يوميًا، أي نحو 356 دولارًا يوميًا — أي توفير بنسبة ~73% مقارنةً بتشغيل كل شيء بجهد مرتفع، مع الاستمرار في تطبيق التفكير العميق حيث يستحق ذلك.

وتعكس صورة زمن الانتقال ذلك؛ فعند الجهد المنخفض يظهر الرمز الأول عادةً في أقل من ثانية بكثير. أما عند الجهد المرتفع فيولّد النموذج مسودة استدلال أكبر بكثير قبل أن تبدأ الإجابة، ولذا فإن مسودة داخلية بطول 1,500 رمز وبسرعة توليد توضيحية تبلغ 60 رمزًا في الثانية تؤخّر الاستجابة المرئية بنحو 25 ثانية تقريبًا. وبثّ كتل thinking_delta داخل لوحة قابلة للطي تحمل عنوان “التفكير…” هو ما يبقي هذا الانتظار محتملاً بالنسبة للمستخدم النهائي.

الهجرة وحساب التكلفة الإجمالية للملكية (TCO)

إذا كنت تنتقل من نموذج ذي حوسبة ثابتة، فإن التحول الأكبر هو أن عمق التفكير أصبح الآن مقياسًا تضبطه لكل طلب على حدة بدلاً من رسم ثابت تدفعه في كل مكالمة. والرافعة الأكبر على فاتورتك ليست مستوى effort لأي مكالمة منفردة، بل طبقة التوجيه (routing layer) التي تقرر أي الطلبات تستحق مستوى جهد مرتفع من الأساس. وتكاد مكالمة تصنيف خفيفة منخفضة الجهد — بضع مئات من الرموز فقط تتحكم في إطلاق مكالمة الجهد المرتفع المكلفة — أن تسدد تكلفتها دائمًا.

هناك عادتان تُبقيان التكلفة الإجمالية للملكية متوقعة. أولاً: عيّن أدنى مستوى جهد يحل كل فئة من المهام بشكل موثوق بدلاً من قيمة افتراضية عامة سخية؛ فمستوى الجهد max المطبّق في كل مكان هو المصدر الأكثر شيوعًا للفواتير المفاجئة. ثانياً: خزّن رسائل النظام التوجيهية المستقرة مؤقتًا (caching) حتى لا يُعاد احتساب تكلفة السياق المتكرر في كل دورة تفكير. ويدفع الدمج بين التوجيه لكل طلب والتخزين المؤقت للرسائل التوجيهية معًا الجزء الأكبر من الإنفاق نحو الأقلية من الطلبات التي تستفيد منه فعليًا.

أهم النقاط المستفادة

• يُبقي Fable 5 (claude-fable-5، سياق بمليون رمز، وحد أقصى للمخرجات 128K) التفكير مُفعّلاً دائمًا؛ فأنت تضبط عمقه بدلاً من تشغيله وإيقافه.
• هيّئ عمق التفكير عبر output_config: {effort: "low" | "medium" | "high" | "xhigh" | "max"}؛ أما budget_tokens وthinking.type بقيمة “enabled”/“disabled” فتُعيد الآن خطأ HTTP 400.
• ابثّ التفكير عبر كتل محتوى thinking (فوارق thinking_delta) لعرض خطوات النموذج للمستخدمين النهائيين، مع اختيار thinking: {type: "adaptive", display: "summarized"} صراحةً للحصول على ملخص قابل للقراءة.
• تحكّم في تكاليف فوترة واجهة برمجة التطبيقات باختيار أدنى مستوى جهد قابل للتطبيق وتخزين الرسائل التوجيهية المتكررة مؤقتًا.
• انشر برمجياتك الوسيطة على شبكات الحافة بدون خادم لتقليل زمن انتقال نقل البيانات.

الأسئلة الشائعة (FAQ)

ما هو الاستدلال في نموذج Claude Fable 5؟ الاستدلال في Claude Fable 5 قدرة مُفعّلة دائمًا يولّد فيها النموذج رموز تفكير داخلية لحل المشكلات المنطقية المعقدة قبل إخراج الاستجابة النهائية. وبدلاً من محاولة تخمين الكلمة التالية فورًا، تحاكي الشبكة عملية تفكير خطوة بخطوة لحل الأخطاء البنيوية والرياضية والبرمجية، وأنت تضبط مدى عمق تفكيرها عبر إعداد effort.

كيف يمكنني تهيئة جهد الاستدلال في واجهة برمجة التطبيقات؟ تُهيّئ عمق التفكير عبر تمرير output_config: { effort: "low" | "medium" | "high" | "xhigh" | "max" } داخل حمولة طلب واجهة برمجة التطبيقات. فمستوى الجهد الأقل يفكّر بإيجاز ويجيب بشكل أسرع مقابل عدد رموز أقل، بينما يستدل المستوى الأعلى بعمق أكبر. أما المعلمة القديمة budget_tokens فقد أُزيلت وتُعيد الآن خطأ HTTP 400 في Fable 5.

هل تُحتسب تكلفة رموز التفكير بشكل مختلف؟ لا، تُحتسب رموز التفكير بنفس السعر القياسي لرموز المخرجات الخاصة بالنموذج. ونظرًا لأن هذه الرموز تمثّل حوسبة مخرجات، فإنها تُضاف مباشرةً إلى فوترة واجهة برمجة التطبيقات؛ مما يجعل تفعيل التخزين المؤقت للرسائل التوجيهية واختيار مستوى جهد معقول أمرين ضروريين للتحكم في نفقات البرمجيات.

كيف أجعل Fable 5 يستجيب بشكل أسرع؟ لا يمكنك تعطيل الاستدلال — فالتفكير مُفعّل دائمًا في Fable 5، وتمرير thinking: {type: "disabled"} يُعيد خطأ HTTP 400. ولتقليل زمن الانتقال، اخفض مستوى الجهد عبر output_config: { effort: "low" }، وهو ما يختصر مرحلة التفكير ويقلّل زمن ظهور الرمز الأول للمهام الحوارية الأساسية.

كيف يمكنني استخراج رموز التفكير من بث أحداث الخادم (SSE) في الوقت الفعلي؟ أثناء بث أحداث الخادم (SSE) بدون خادم، يصل التفكير على هيئة كتل محتوى thinking عبر أحداث content_block_delta التي يكون delta.type فيها هو thinking_delta؛ اقرأ النص من delta.thinking، منفصلاً عن مخرجات text_delta القياسية. واختر thinking: {type: "adaptive", display: "summarized"} صراحةً لاستقبال ملخص قابل للقراءة، ثم اعرض تلك الرموز أو تجاهلها بناءً على تفضيلات واجهة المستخدم الأمامية.