نظرة عامة

يقوم الأمر /cd <المسار> بنقل جلسة Claude Code الجارية إلى مجلد عمل آخر. لا تُعاد الجلسة من الصفر، لذا ينتقل سجل المحادثة، والنموذج المختار، وإعدادات الأذونات، كلها كما هي إلى المجلد الجديد. حتى هذه النقطة، يبدو الأمر ميزة راحة معتادة. لكن الجوهر الحقيقي يكمن فيما بعد: لا يكسر /cd ذاكرة التخزين المؤقت للـ prompt. الرسالة التي تُرسل مباشرة بعد الانتقال إلى المجلد الجديد تُحاسَب بسعر قراءة الذاكرة المؤقتة، وليس بسعر كتابتها.

سبب أهمية هذا الفارق يكمن في سعر الذاكرة المؤقتة نفسه. وفقاً للأسعار التي أعلنتها Anthropic لتخزين الـ prompt مؤقتاً، فإن قراءة الذاكرة المؤقتة تبلغ نحو 10 بالمئة من سعر الإدخال القياسي، أي 0.1x. في المقابل، تُضاف علاوة تبلغ 1.25x عند الكتابة الجديدة في الذاكرة المؤقتة. عند إعادة تشغيل الجلسة، يجب إعادة كتابة سياق النظام (system prompt) وتعريفات الأدوات وملف CLAUDE.md الخاص بالمشروع، جميعها من جديد في ذاكرة مؤقتة جديدة. وكلما كان المشروع أكبر، بلغت هذه البادئة (prefix) عشرات الآلاف من الرموز (tokens). أمر /cd لا يعيد كتابة هذه البادئة، بل يقرأها كما هي ويعيد استخدامها.

تشغّل Thaki Cloud في بيئة متعددة المستأجرين وكلاء ومهام دفعية لعملاء متعددين على نفس البنية التحتية. في مثل هذه البيئة، اقتصاديات الرموز تعني مباشرة تكلفة الخدمة. إذا أعاد وكيل البرمجة تخزين البادئة مؤقتاً في كل مرة يتنقل فيها بين المجلدات، فإن هذه التكلفة تتراكم بما يتناسب مع عدد الجلسات وعدد مرات التنقل. إجراء واحد مثل /cd يحافظ على الذاكرة المؤقتة يمكن أن يؤدي في التشغيل واسع النطاق إلى وفورات لا يُستهان بها. لذا فمن الأدق النظر إلى هذه الميزة على أنها مسألة “نظافة تكلفة” وليست مجرد “اختصار مريح”.

ما هي هذه التقنية

لفهم قيمة /cd، لا بد أولاً من فهم كيفية عمل ذاكرة التخزين المؤقت للـ prompt. يقوم Claude Code تلقائياً بتخزين سياق النظام وتعريفات الأدوات وملف CLAUDE.md مؤقتاً في كل دورة (turn)، دون الحاجة إلى أي إعداد إضافي. تشغل هذه البادئة المخزّنة مؤقتاً بداية المحادثة، وتُلحَق بعدها كل رسالة جديدة. إذا ظلت الذاكرة المؤقتة حيّة، تُحاسَب هذه البادئة بسعر القراءة فقط. أما إذا انكسرت الذاكرة المؤقتة، فيجب إعادة كتابة البادئة بأكملها.

عند إعادة تشغيل الجلسة أو تفريغ السياق باستخدام /clear، تُبطَل الذاكرة المؤقتة. لكن الفخّ الكامن في عملية الانتقال بين المجلدات هو أن المجلد الجديد يحتوي غالباً على ملف CLAUDE.md مختلف. منطقياً، يبدو أن تغيير محتوى CLAUDE.md الذي يدخل في سياق النظام يجب أن يكسر الذاكرة المؤقتة. وهنا يكمن الجزء الذكي في /cd. فبدلاً من إعادة كتابة CLAUDE.md الخاص بالمجلد الوجهة داخل سياق النظام، يُضيفه كرسالة تالية في المحادثة. وبما أن سياق النظام لا يُعاد كتابته، تبقى البادئة المخزّنة مؤقتاً كما هي، ويُعامَل ملف CLAUDE.md الجديد باعتباره مجرد رسالة مستخدم مُلحَقة في النهاية. هذه هي الطريقة التي تحافظ بها الذاكرة المؤقتة على نفسها بينما تعكس قواعد المجلد الجديد في الوقت نفسه.

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

flowchart TB
    A["جلسة جارية في<br/>المجلد A<br/>(بادئة مخزّنة مؤقتاً نشطة)"] --> B{"حاجة للانتقال<br/>إلى المجلد B"}
    B -->|"إعادة تشغيل أو /clear"| C["إبطال ذاكرة سياق النظام<br/>والأدوات وملف<br/>CLAUDE.md المؤقتة"]
    C --> D["إعادة كتابة البادئة<br/>بأكملها في الذاكرة المؤقتة<br/>(سعر 1.25x)"]
    D --> E["فقدان سياق المحادثة"]
    B -->|"مسار /cd"| F["الحفاظ على سياق النظام<br/>وإلحاق CLAUDE.md<br/>الجديد كرسالة"]
    F --> G["قراءة البادئة<br/>من الذاكرة المؤقتة<br/>(سعر 0.1x)"]
    G --> H["الحفاظ على المحادثة<br/>والنموذج والأذونات<br/>كما هي"]

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

سبب بقاء الذاكرة المؤقتة سليمة عند الإلحاق في النهاية هو أن تخزين الـ prompt مؤقتاً يعمل على مستوى البادئة. تعيد الذاكرة المؤقتة استخدام الجزء الذي يظل مطابقاً لبداية المحادثة، أي جزء البادئة. فإذا تغيّر حرف واحد في البادئة، يجب إعادة حساب كل ما يليها من تلك النقطة فصاعداً. لذلك فإن وضع محتوى يتغيّر باستمرار في البداية يقلّل من معدل إصابة الذاكرة المؤقتة (cache hit rate)، بينما وضع محتوى مستقر في البداية وإلحاق ما يتغيّر في النهاية يرفع هذا المعدل. تصميم /cd الذي يُلحق ملف CLAUDE.md الجديد كرسالة في نهاية المحادثة بدلاً من سياق النظام هو بالضبط التزام بهذا المبدأ: عدم لمس البادئة المخزّنة مؤقتاً، واستيعاب التغيير خارج حدود الذاكرة المؤقتة.

التثبيت والدمج

لا يحتاج /cd إلى أي تثبيت منفصل. يمكن استخدامه مباشرة اعتباراً من Claude Code v2.1.169 فما فوق. صدر هذا الأمر في 8 يونيو 2026. طريقة الاستخدام بسيطة.

# الانتقال إلى مجلد آخر داخل الجلسة
/cd ../consuming-service

# يمكن أيضاً استخدام مسار مطلق
/cd /Users/me/repo/apps/web

# مسار نسبي إلى المجلد الرئيسي
/cd ~/repo/packages/core

عند تنفيذ الأمر، يقوم Claude Code بتحديث مجلد العمل، ويقرأ ملف CLAUDE.md الموجود في الموقع الجديد ويُلحقه بالمحادثة، ثم يواصل العمل الجاري. وبما أن سجل المحادثة والقرارات المتخذة حتى تلك اللحظة تبقى محفوظة، فإن طلباً مثل “تحقق من أن الواجهة تستخدم الواجهة البرمجية التي عدّلتها للتو في الوحدة الأساسية” ينساب بشكل طبيعي.

لنأخذ مثالاً محدداً. تُجمّع بيئة عمل منصة Thaki Cloud سبعة مستودعات منتجات، منها الواجهة الخلفية بلغة Go، والواجهة الأمامية، ونشر GitOps، وشبكة الوصل متعددة النطاقات (multi-cluster mesh)، وذلك عبر وحدات فرعية (git submodules). إن تعديل مخطط استجابة واجهة برمجية خلفية ثم التحقق من ظهور الشاشة بشكل صحيح في الواجهة الأمامية التي تستهلك هذا المخطط هو عمل يومي في هذا الهيكل. في الطريقة القديمة، كان يجب إغلاق جلسة الواجهة الخلفية وفتح جلسة جديدة في مجلد الواجهة الأمامية، ثم إعادة شرح ما تم تغييره ولماذا في الجلسة الجديدة. مع /cd لا ينقطع سير العمل.

# جارٍ تعديل المخطط في الوحدة الفرعية الخلفية
# ...

# الانتقال إلى الواجهة الأمامية التي تستهلك هذا المخطط (مع الحفاظ على السياق والذاكرة المؤقتة)
/cd ../ai-suite/apps/web

# السؤال مباشرة: هل تُشير هذه الشاشة إلى اسم الحقل الذي تم تعديله للتو؟

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

لفهم اقتصاديات الذاكرة المؤقتة، لا بد من الاطلاع على جدول الأسعار. الجدول التالي يلخّص أسعار تخزين الـ prompt مؤقتاً التي أعلنتها Anthropic.

هناك سياق واحد يستحق الانتباه. خفّضت Anthropic بهدوء في مارس 2026 مدة صلاحية الذاكرة المؤقتة الافتراضية (TTL) من 60 دقيقة إلى 5 دقائق. إذا لم يصل طلب تالٍ خلال 5 دقائق، تنتهي صلاحية الذاكرة المؤقتة وتُدفَع تكلفة الكتابة من جديد. إذا كنت تعمل بفواصل زمنية طويلة، يمكن التفكير في تفعيل خيار الساعة الواحدة، لكن علاوة الكتابة ترتفع إلى 2.0x، لذا يجب موازنة المقايضة. أمر /cd هو ما يحافظ على الذاكرة المؤقتة حيّة عند استمرار الجلسة ضمن هذه المدة، لذا أصبح أكثر أهمية في عصر مدة الصلاحية القصيرة.

نتائج التجربة الفعلية

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

لنقارن المسارين من حيث كيفية احتساب البادئة المخزّنة مؤقتاً في أول طلب مباشرة بعد الانتقال بين المجلدات. في مسار إعادة التشغيل أو /clear، تُسجَّل البادئة من جديد بسعر كتابة الذاكرة المؤقتة (1.25x). أما في مسار /cd، فتُعاد استخدام البادئة نفسها بسعر قراءة الذاكرة المؤقتة (0.1x). إذا افترضنا أن حجم البادئة متساوٍ في الحالتين، فإن نسبة التكلفة المدفوعة مقابل إعادة احتساب البادئة مباشرة بعد الانتقال هي 1.25 مقسومة على 0.1، أي 12.5 مرة. بعبارة أخرى، مسار إعادة التشغيل أغلى بنحو 12.5 مرة من مسار /cd من حيث إعادة احتساب البادئة.

هذه النسبة تصح بغضّ النظر عن العدد المطلق لرموز البادئة. غير أن قيمة الوفورات المطلقة تزداد كلما كانت البادئة أكبر. في المشاريع الكبيرة، من الشائع[تقديري] أن تصل البادئة المكوّنة من سياق النظام وتعريفات الأدوات وملف CLAUDE.md الضخم إلى عشرات الآلاف من الرموز، وفي مثل هذه الجلسات، إذا تنقّل المستخدم بين المجلدات عدة مرات يومياً، تتراكم تكلفة إعادة التخزين المؤقت بسرعة. أمر /cd يخفّض علاوة الـ 12.5 مرة التي تُضاف عند كل انتقال إلى سعر القراءة فقط.

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

دلالات التطبيق في منتجات Thaki Cloud

لهذه الميزة أهمية من منظور منتجَي Thaki Cloud كليهما.

من منظور Paxis، يلامس /cd بدقة مسألة نظافة جلسات وكيل البرمجة. Paxis هو السحابة الأصلية للوكلاء (Agent-Native Cloud) لدى Thaki Cloud، حيث تُعامَل المهارات (skills) والأدوات والسياسات وسجلات التدقيق كموارد أساسية من الدرجة الأولى، ويُشغَّل الوكيل داخل بيئة معزولة (sandbox). التنقل بين مستودعات ووحدات فرعية متعددة أثناء عمل وكيل البرمجة هو سيناريو شائع في Paxis. وإذا أعاد الوكيل تشغيل الجلسة عند كل انتقال، فإن ذلك يعني إعادة احتساب سياق مهارات وسياسات ضخم في كل مرة. الأسلوب الذي يحافظ على البادئة ويُلحق قواعد المجلد كرسالة فقط، كما يفعل /cd، ينسجم جيداً مع نموذج تنسيق (orchestration) Paxis الذي يبدّل مسار العمل فقط مع الحفاظ على اختيار المهارات وبوابات السياسات. فكرة عدم إعادة كتابة سياق النظام وإلحاق السياق في النهاية بدلاً من ذلك هي بعينها المبدأ الذي يُدار به طبقة القواعد المُحمَّلة باستمرار من منظور استقرار الذاكرة المؤقتة.

ومن منظور ai-platform، تُعد اقتصاديات الذاكرة المؤقتة تكلفة الخدمة متعددة المستأجرين مباشرة. تُشغّل منصة ai-platform لدى Thaki Cloud أحمال استدلال (inference) لعملاء متعددين فوق جدولة GPU قائمة على K8s وKueue. تخزين الـ prompt مؤقتاً هو رافعة أساسية لخفض تكلفة الإدخال عبر إعادة استخدام البادئات المتكررة، والمبدأ الذي يُظهره /cd، أي إضافة السياق في نهاية المحادثة وليس في بدايتها كي لا تنكسر الذاكرة المؤقتة، يُطبَّق كما هو في مكدّس الخدمة الخاص بالمنصة. تصميم بنية الـ prompt بحيث تُقلَّل نقاط إبطال الذاكرة المؤقتة يمنح تنافسية عند تكلفة خدمة منخفضة. والعدستان تُكمّلان إحداهما الأخرى: تكلفة الخدمة المنخفضة (ai-platform) تصنع اقتصاديات الوكيل (Paxis)، وسلوك الوكيل الذي يحافظ على الذاكرة المؤقتة (Paxis) يخفّض بدوره حمل البنية التحتية.

القيود والاعتراضات

/cd ليس حلاً سحرياً. أولاً، الحفاظ على الذاكرة المؤقتة له معنى فقط ضمن مدة الصلاحية البالغة 5 دقائق. إذا تركت المجلد بعد الانتقال إليه لفترة طويلة دون نشاط، تنتهي صلاحية الذاكرة المؤقتة، وسواء استخدمت /cd أم لا، سيُحاسَب الطلب التالي بتكلفة الكتابة. ونظراً لقصر مدة الصلاحية، تكون وفورات /cd في أعلى مستوياتها في سير العمل المتواصل، بينما تتضاءل فائدتها في العمل المتقطّع.

ثانياً، هناك فخّ دقيق في أسلوب إلحاق ملف CLAUDE.md كرسالة بدلاً من إدراجه في سياق النظام. إذا عدّلت ملف CLAUDE.md الأصلي للمشروع أثناء الجلسة، فإن هذا التعديل لا يكسر الذاكرة المؤقتة، لكنه في المقابل لا يُطبَّق حتى تنفّذ /clear أو /compact أو تُعيد تشغيل الجلسة. أي قد ينشأ وضع تُغيَّر فيه القواعد دون أن تعكسه الجلسة، لذا يجب تحديث الجلسة عمداً بعد تغيير القواعد.

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

ومع ذلك، فإن الخلاصة واضحة. إذا كنت تتنقل بين المجلدات بشكل متكرر في مشروع أحادي الجذر أو في مستودعات متعددة، فإن /cd هو أرخص طريقة للحفاظ على سياق المحادثة وذاكرة التخزين المؤقت للـ prompt في آن واحد. إذا كان فريقك يُشغّل وكلاء البرمجة مع مراعاة التكلفة، فهناك ما يكفي من الأسباب لجعل هذا السطر الواحد عادة راسخة.

المصادر

• Manage sessions - Claude Code Docs
• How Claude Code uses prompt caching - Claude Code Docs
• Claude Code /cd: Switch Projects Without Losing Cache
• التغريدة الأصلية (إعادة تغريد @delba_oliveira)

هذا المقال موجه للمهندسين الذين يشغّلون خطوط تقييم آلية تصحّح مخرجات النماذج اللغوية الكبيرة، أو الذين يسعون لتقديم تقييم النماذج كخدمة فوق عنقود GPU مشترك بين عدة فرق داخلية. يتناول المقال مدى هشاشة أسلوب “اطلب من النموذج اللغوي أن يعطي درجة من 1 إلى 10”، وما الذي ينبغي تركه للنموذج وما الذي يجب أن يتولاه الكود لإزالة هذه الهشاشة. الأمر وثيق الصلة بشكل خاص بالمؤسسات في الصناعات المنظّمة أو الجهات الحكومية التي لا يمكنها إرسال بياناتها خارج جدرانها، وبالتالي لا يمكنها الاعتماد على حكم عبر واجهة برمجية من نماذج طليعية.

جوهر المشكلة: قياس الجودة برقم واحد أسلوب بدأ ينهار بالفعل

مع تجاوز وتيرة تطوير النماذج ومراجعة السلامة بكثير سرعة تصحيح البشر يدوياً، أصبح أسلوب LLM-as-a-judge، حيث يقيّم نموذج لغوي كبير مخرجات نموذج آخر، ممارسة أساسية بحكم الأمر الواقع. غير أن هذه الممارسة تقوم على افتراض أن قيمة قياسية واحدة يصدرها نموذج مجمّد تتبع الدرجة التي كان سيمنحها إنسان، والأبحاث المتراكمة خلال 2026 قوّضت هذا الافتراض خطوة بخطوة. فنماذج الحكم تقلب أحكامها بناءً على إشارات سطحية مثل صياغة الطلب أو موضع الإجابة، وتضغط طرفي مقياس التصحيح نحو القيمة الوسطى فتطمس بالضبط الحالات المتطرفة التي يفترض أن تُرصد، وتفرط في الثقة بأحكامها رغم أن هذه الثقة غير معايرة، وحين يعبث فريق أحمر بالمدخل قليلاً يصبح الحكم أقرب إلى رمي العملة. أدوات كشف التحيّز الآلية والتشخيصات المبنية على نظرية استجابة البند تؤكد هذا التذبذب على نطاق واسع وبشكل كمّي.

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

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

المساهمة الجوهرية: الانضباطات الأربعة التي تجمعها ABJ-Gate

بناءً على هذه الشروط الواقعية الثلاثة، يقترح فريق أبحاث ThakiCloud AI معمارية ABJ-Gate التي تجمع تيّاري البحث في واحد. جوهرها أن كل معيار تقييم يُفكّك إلى سؤال ثنائي أولي يجيب عليه نموذج عامل صغير محلي، بينما يُترك تجميع تلك الإجابات وتوحيد صيغتها ومعايرتها والاحتفاظ بسجل تدقيق كلها للكود الحتمي وليس للنموذج. أي بند يقع على حدّ فاصل متنازع عليه أو تُرصد بشأنه إشارة شك يُرسل دائماً إلى عدد فردي من عمّال متشككين مستقلين يُطلب منهم “محاولة دحض هذا”، ويُطرح للتصويت؛ ولا يصمد الحكم إلا حين تفشل الأغلبية في دحضه. وميزانية كل نداء من نداءات النموذج اللغوي هذه توزّعها جدولة قائمة على Kueue/GPU ضمن حدود التكلفة والزمن الذيلي لكل مستأجر.

نتيجة محسوبة من النموذج التحليلي بافتراض 5 معايير ثنائية، ونسبة تصعيد 10%، و3 متشككين. تشغيل الحكم الثنائي الكامل على كل بند (k=1) يرفع التكلفة إلى نحو 5.3 أضعاف تكلفة الحكم القياسي، لكن المعايرة بأسلوب conformal التي تقلّل التصعيدات وتخفض نسبة أخذ العينات k إلى 0.2 تقرّب التكلفة إلى نحو 1.06 ضعف تكلفة الحكم القياسي مع الحفاظ على قابلية التفسير والمعايرة. هذه نتيجة حسابية من المعادلة 8 وليست قياساً فعلياً من معيار مرجعي.

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

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

منحنى مفاهيمي توضيحي يبيّن كيف يتصاعد زمن الانتظار مع اقتراب معدل الاستخدام من 1 في نموذج طابور M/G/c. يصوّر هذا حجة الافتراض 3 القائلة بأن التحكم في القبول يمكن أن يدير زمن الاستجابة الذيلي عبر ضبط نسبة أخذ العينات لإبقاء معدل الاستخدام تحت عتبة مستهدفة، وليس بيانات زمن انتظار فعلية مقاسة.

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

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

ما يتركه للشركة والمجتمع والعلم

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

القيود

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

تفاصيل البحث الكاملة متاحة على Hugging Face: https://huggingface.co/datasets/thaki-AI/daily-paper-2026-07-07-atomic-binary-judge-eval-service

شرائح ذات صلة

هذه الشرائح تلخّص محتوى هذا المقال باستخدام NotebookLM (نمط neo_swiss).

Overview

/cd <path> moves a running Claude Code session to a different working directory. Because the session is not restarted, the conversation history, the selected model, and the permission settings all carry over to the new directory intact. So far this sounds like an ordinary convenience feature. The real point is what happens next: /cd does not break the prompt cache. The first message you send right after switching directories gets billed at the cache-read price, not the cache-write price.

This distinction matters because of how steep the cache rates actually are. In Anthropic’s published prompt caching rates, a cache read costs roughly 10 percent of the standard input price, or 0.1x. Writing fresh content into the cache, on the other hand, carries a 1.25x premium over the base input rate. When you restart a session, the system prompt, the tool definitions, and the project’s CLAUDE.md all have to be written into a fresh cache. On a large project, that prefix can run to tens of thousands of tokens. /cd avoids rewriting that prefix; it simply reads and reuses it.

ThakiCloud runs multiple customers’ agents and batch jobs on shared infrastructure in a multi-tenant environment. In that kind of setting, token economics is service cost. If a coding agent re-caches its prefix every time it switches directories, that cost accumulates in proportion to session count and switch frequency. A single behavior that preserves the cache, like /cd, adds up to a real saving at scale. That is why this feature is better understood as a matter of cost hygiene than as a handy shortcut.

What Is This Technology

To see the value of /cd, it helps to first understand how the prompt cache works. Claude Code automatically caches the system prompt, tool definitions, and CLAUDE.md on every turn, with no configuration required. This cached prefix sits at the front of the conversation, and each new message is appended after it. As long as the cache is alive, that prefix is billed only at the read rate. Once the cache breaks, the entire prefix has to be written again.

Restarting a session or clearing context with /clear invalidates the cache. But switching directories has a hidden trap: the new directory has its own CLAUDE.md. Intuitively, you’d expect the cache to break the moment the CLAUDE.md that feeds into the system prompt changes. This is exactly where /cd is clever. Instead of rewriting the destination directory’s CLAUDE.md into the system prompt, it appends it as the next message in the conversation. Because the system prompt is never rewritten, the cached prefix stays intact, and the new CLAUDE.md is simply handled as one more user message tacked on at the end. That is how it applies the new directory’s rules while still protecting the cache.

The diagram below shows how the two paths handle the cache differently when you switch directories.

flowchart TB
    A["Session running<br/>in directory A<br/>(prefix cache active)"] --> B{"Need to move<br/>to directory B"}
    B -->|"Restart or /clear"| C["System prompt, tools,<br/>and CLAUDE.md cache invalidated"]
    C --> D["Entire prefix<br/>written to cache again<br/>(1.25x rate)"]
    D --> E["Conversation context lost"]
    B -->|"/cd path"| F["System prompt preserved<br/>new CLAUDE.md<br/>appended as a message"]
    F --> G["Prefix cache read<br/>(0.1x rate)"]
    G --> H["Conversation, model,<br/>and permissions preserved"]

The key point in this diagram is that the right-hand path never touches the system prompt. The left-hand path rewrites the prefix and throws away all the conversation you had accumulated along with it. Both paths arrive at the same destination, but the cost you pay to get there is completely different.

The reason appending works is that prompt caching operates at the level of the prefix. The cache reuses however much of the front of the conversation, the prefix, is identical to before. If even a single character in that prefix changes, everything from that point onward has to be recomputed. That’s why putting content that changes frequently near the front hurts the cache hit rate, while putting stable content at the front and letting variable content trail behind it keeps the hit rate high. /cd appending the new CLAUDE.md as a message at the end of the conversation, rather than folding it into the system prompt, is a design that respects exactly this principle. It leaves the cached prefix untouched and absorbs all the change outside the cache boundary.

Installation and Integration

/cd requires no separate installation. It works out of the box on Claude Code v2.1.169 or later. The command shipped on June 8, 2026. Usage is straightforward.

# Move to another directory within the session
/cd ../consuming-service

# Absolute paths work too
/cd /Users/me/repo/apps/web

# Home-relative paths
/cd ~/repo/packages/core

Once you run the command, Claude Code updates the working directory, reads the CLAUDE.md at the new location and appends it to the conversation, then continues the work it was doing. Because the conversation history and every decision made so far are preserved, a follow-up request like “verify that the interface I just changed in the core module works from this service” flows naturally.

Here’s a concrete example. ThakiCloud’s platform workspace bundles seven product repositories, the Go backend, the frontend, GitOps deployment, the multi-cluster mesh, and more, as git submodules. Changing a backend API’s response schema and then checking that the frontend consuming that schema still renders correctly is a routine task in this structure. In the old workflow, you had to close the backend session and open a fresh one in the frontend directory, and then re-explain to that new session exactly what you had just changed and why. With /cd, the flow never breaks.

# Working on a schema change in the backend submodule
# ...

# Move to the frontend that consumes that schema (context and cache preserved)
/cd ../ai-suite/apps/web

# Immediately ask: does this screen reference the field name I just renamed?

Right after the move, the frontend directory’s CLAUDE.md gets appended to the conversation, so that repository’s rules (things like FSD boundaries or TDS token usage) apply immediately. At the same time, the context built up in the backend, namely which field was changed and why, is still there, so you can go straight into verification.

To understand the cache economics, you need to look at the rate table. Below is a summary of Anthropic’s published prompt caching rates.

One piece of context worth flagging: Anthropic quietly cut the default cache TTL from 60 minutes to 5 minutes in March 2026. If your next request doesn’t arrive within 5 minutes, the cache expires and you pay the write cost again. If you’re working with long gaps between requests, you might consider enabling the 1-hour option, but the write premium jumps to 2.0x, so it’s a real trade-off to weigh. /cd is what keeps the cache alive while you continue a session within that TTL window, which makes it more important than ever in this shorter-TTL era.

Real Experiment Results

To be honest, /cd is an interactive slash command, so it wasn’t possible to spin up an actual session and run an interactive benchmark in the headless environment used to write this post. Rather than fabricate measurements, this section presents a cost model built purely from the published rates. The figures below are not measurements; they are calculations based on documented rates, and that distinction is stated explicitly.

Let’s compare how the two paths bill the cached prefix on the first request right after switching directories. On the restart or /clear path, the prefix is rewritten to the cache at the write rate (1.25x). On the /cd path, the same prefix is reused at the read rate (0.1x). Assuming the prefix size is identical in both cases, the ratio of what you pay for the prefix right after the switch is 1.25 divided by 0.1, or 12.5x. In other words, the restart path costs roughly 12.5 times more than the /cd path for re-billing the prefix.

This ratio holds regardless of the prefix’s absolute token count. The absolute savings, however, grow larger as the prefix grows. In large projects it’s common [estimated] for the combined prefix of system prompt, tool definitions, and a hefty CLAUDE.md to reach tens of thousands of tokens, and in sessions like that, moving between directories several times a day makes the re-caching cost add up fast. /cd compresses that 12.5x premium per switch down to the read rate.

One more thing worth noting: what /cd preserves isn’t only cost. The conversation context lost on the restart path is a cost that’s hard to translate into tokens. Having to re-explain the intent behind code you just changed, hypotheses you’d already formed, or approaches you’d already ruled out, costs both human time and additional tokens. /cd removes that re-explanation cost as well.

Implications for ThakiCloud Products

This feature is meaningful from the perspective of both ThakiCloud products.

From the Paxis angle, /cd addresses session hygiene for coding agents directly. Paxis is ThakiCloud’s Agent-Native Cloud, treating skills, tools, policies, and audit logs as first-class resources and running agents in isolated sandboxes. A coding agent moving across multiple repositories and submodules is a common scenario on Paxis. If every switch restarted the session and re-cached the prefix, a large skill harness and its policy context would get re-billed every time. The approach /cd takes, preserving the prefix and appending only the directory-specific rules as a message, aligns well with Paxis’s orchestration model, which keeps skill selection and policy gates intact while only the working path changes. The idea of appending context after the fact rather than rewriting the system prompt is the same principle behind managing an always-loaded rule layer with cache stability in mind.

From the ai-platform angle, cache economics is directly multi-tenant serving cost. ThakiCloud’s ai-platform serves multiple customers’ inference workloads on K8s and Kueue-based GPU scheduling. Prompt caching is the key lever for reducing input costs by reusing repeated prefixes, and the principle /cd demonstrates, appending context after the cached boundary instead of in front of it so the cache never breaks, applies equally to our own serving stack. Designing the prompt structure to minimize cache invalidation points is a direct path to a competitive cost position on serving. The two lenses reinforce each other: lower serving cost (ai-platform) makes agent economics work (Paxis), and cache-preserving agent behavior (Paxis) in turn reduces infrastructure load.

Limitations and Counterarguments

/cd isn’t a silver bullet. First, cache preservation only matters within the 5-minute TTL. If you step away for a long time after switching directories, the cache expires regardless of whether you used /cd, and the next request pays the write cost either way. Given the short TTL, /cd’s savings are largest in a continuous work session and shrink for intermittent work.

Second, appending CLAUDE.md as a message instead of folding it into the system prompt has a subtle catch. If you edit the original project’s CLAUDE.md mid-session, that change doesn’t break the cache, but it also doesn’t take effect until you /clear, /compact, or restart. In other words, you can end up in a situation where you’ve changed the rules but the session hasn’t picked them up, so you need to deliberately refresh the session after any rule change.

Third, the 12.5x savings ratio is strictly a documented-rate calculation for re-billing the prefix right after a switch. How much you actually feel that savings in the total session cost depends on the prefix’s share of overall cost, conversation length, and how often you switch. Don’t stretch this post’s ratio into “your session costs 12.5x less.” The precise claim is narrower: you don’t have to re-cache the prefix at the moment you switch.

Even so, the conclusion is clear. If your work involves frequently moving between directories in a monorepo or across multiple repositories, /cd is the cheapest way to protect both your conversation context and your prompt cache at the same time. For any team that operates coding agents with cost in mind, this one line is worth turning into a habit.

Sources

• Manage sessions - Claude Code Docs
• How Claude Code uses prompt caching - Claude Code Docs
• Claude Code /cd: Switch Projects Without Losing Cache
• Original tweet (retweeted by @delba_oliveira)

This post is for engineers who run automated pipelines that grade LLM outputs, or who want to offer model evaluation as a service on a GPU cluster shared by multiple internal teams. It covers how fragile the approach of “asking an LLM to give a score from 1 to 10” really is, and what must be left to the model versus taken over by code to remove that fragility. It is especially relevant for organizations in regulated industries or government agencies that cannot send data outside their walls and therefore cannot rely on a frontier API judge.

The problem: measuring quality with a single number is already breaking down

As the pace of model development and safety review has outstripped the pace at which humans can grade outputs by hand, LLM-as-a-judge, where an LLM evaluates the output of another LLM, has become essentially standard practice. But this practice rests on the assumption that a scalar value produced by one frozen model tracks the score a human would assign, and research accumulated through 2026 has dismantled that assumption piece by piece. Judge models flip their verdicts based on superficial cues such as prompt wording or where an answer sits in the input, they compress toward the middle of the grading scale and squash exactly the extreme cases that should be caught, and they are overconfident in their own verdicts while that confidence remains uncalibrated. When a red team perturbs the input even slightly, the verdict becomes no better than a coin flip. Automated bias detection tools and diagnostics based on item response theory confirm this instability at scale and in quantitative terms.

The research community’s response to this problem falls broadly into two camps. One camp asks the model interpretable yes-or-no questions instead of a score; work such as BINEVAL decomposes evaluation criteria into binary questions and matches or exceeds the performance of scalar or pairwise-comparison judges, while also revealing exactly which sub-criterion failed. The other camp adds structure around the judge itself, deploying juries of multiple judges, debate, and verification units to increase the “compute the judge spends” and thereby raise robustness, or using selective evaluation cascades that route only uncertain cases forward to guarantee human-level agreement.

The trouble is that both camps are almost always validated only on offline benchmarks run on a single machine. The reality faced by organizations for which data sovereignty matters, such as hospitals, banks, and government research institutes, differs on three points. Because data cannot leave the facility, evaluation must run on a shared GPU cluster the organization owns rather than on a frontier API; because multiple teams compete for the same accelerators, the evaluation service must respect per-tenant cost and tail-latency budgets; and because compliance officers ask not “what is the score” but “why is it that score,” an opaque single scalar cannot answer that question.

Core contribution: the four disciplines ABJ-Gate binds together

Building on these three real-world constraints, ThakiCloud AI Research proposes ABJ-Gate, an architecture that binds the two research streams into one. Its core idea is that each evaluation criterion is broken down into an atomic binary question that a small on-prem worker model answers, while aggregating those answers, normalizing their format, calibrating them, and keeping an audit log is left entirely to deterministic code rather than to a model. Any item that falls on a contested boundary or triggers a suspicion signal is always sent to an odd number of independent skeptic workers instructed to “try to refute this” and put to a vote; the verdict survives only when the majority fails to refute it. And the budget for every one of these LLM calls is allocated by a Kueue/GPU-based scheduler within per-tenant cost and tail-latency caps.

A computed result from the analytical model assuming 5 binary criteria, a 10% flag rate, and 3 skeptics. Running every item through full binary judgment (k=1) pushes cost to roughly 5.3x that of a scalar judge, but conformal calibration that reduces escalations and lowers the sampling rate k to 0.2 brings cost down to roughly 1.06x the scalar judge’s cost while preserving interpretability and calibration. This is a computation from Eq. 8, not a measured benchmark.

This design is also the promotion, into a formal product surface shared by multiple tenants, of two disciplines the company already enforces at all times in its internal harness: the principle that “code owns format, the model owns content,” and the principle that fanned-out verification results must always be closed with an adversarial vote. No matter how plausibly a worker model self-reports its own answer length, count, or an “overall score out of however many points,” that value is discarded and recomputed by code, so minor wobbles on the worker side cannot contaminate the final result.

The promises this architecture actually has to keep are formalized and proven as three properties. First, reproducibility: given the same set of binary answers, the aggregate score always produces the same value regardless of random seed or request order. Second, a risk-control guarantee: calibrating how often the cheap first-stage judgment and the expensive second-stage verification disagree, using conformal risk control, bounds that disagreement rate below a target level distribution-free, no matter what distribution the items are drawn from. Third, a property whereby, if an admission policy keeps each tenant’s utilization below a certain threshold, queueing theory bounds that tenant’s evaluation latency to a finite value.

An illustrative conceptual curve showing how delay spikes as utilization approaches 1 in an M/G/c queueing model. It visualizes the argument of Proposition 3, that admission control can manage tail latency by tuning the sampling rate to keep utilization under a target threshold, and is not measured latency data.

The paper also spells out quantitatively when binary decomposition actually helps. When each criterion can be answered by a human more reliably than a scalar score and the criteria are weakly correlated so that they carry independent information from one another, binary decomposition combined with majority-vote verification is shown to produce strictly lower variance than a scalar judge. Conversely, the paper is equally clear that if the criteria are entangled with one another, or the binary questions themselves are easy to game, decomposition does not help and can even add bias.

A conceptual diagram visualizing the analytical argument in Section 4.4 of the paper. The variance of the aggregate score decreases roughly in proportion to the per-criterion error variance divided by the number of effectively independent criteria, shown as a relative reduction trend against a baseline of the scalar judge at 1x. These are not experimentally measured figures.

What it leaves for the company, society, and science

From the company’s perspective, this paper consolidates a binary-decomposed judge running on the company’s own GPU scheduling infrastructure, a deterministic aggregation gate, and a sampling scheduler that satisfies per-tenant cost and latency caps into one complete design. It elevates an internal discipline that was already in operation into a product surface shared across multiple tenants. Socially, it opens a path for organizations in regulated industries, who could not use frontier API evaluation services because their data cannot leave the premises, to run pre-deployment safety and quality verification on their own hardware continuously, reproducibly, and auditably. That lowers the barrier to entry for trustworthy AI deployment. Scientifically, it establishes a framework for quantifying the relationship between judge reliability and cost when the idea of binary decomposition is combined with calibration, adversarial verification votes, deterministic aggregation, and cost-bounded sampling, and it presents, alongside that framework, a pre-registered protocol for validating that relationship empirically against literature from the past six months.

Limitations

The paper is explicit about its own limitations. This work presents only the architecture, three theoretical proofs, an analytical cost model, and a pre-registered protocol for validating that frontier against human labels; it does not contain measured accuracy figures. The authors state plainly that reporting numbers without having actually run the protocol would itself be fabrication, and they have deliberately left the figures blank. Beyond that, the paper explicitly names as limitations the fact that the wording of the binary questions themselves can be gamed, that the calibration function can drift under new model families or evolving adversarial attacks, that a heuristic that only checks whether a link is alive misses more sophisticated failures such as soft 404s, and that the variance-reduction argument itself breaks down when criteria are entangled with one another. It also acknowledges that on-prem small worker models inherently perform below frontier-grade judges, so that in exchange for gaining interpretability, calibration, reproducibility, and cost bounds, the system gives up some accuracy as a standalone judge.

Full paper details are available on Hugging Face: https://huggingface.co/datasets/thaki-AI/daily-paper-2026-07-07-atomic-binary-judge-eval-service

Related slides

These slides summarize the body of this post using NotebookLM (neo_swiss style).

개요

/cd <경로>는 실행 중인 Claude Code 세션을 다른 작업 디렉터리로 옮깁니다. 세션을 재시작하지 않으므로 대화 기록, 모델 선택, 권한 설정이 모두 새 디렉터리로 그대로 넘어갑니다. 여기까지는 흔한 편의 기능처럼 들립니다. 진짜 핵심은 그다음입니다. /cd는 프롬프트 캐시를 깨지 않습니다. 디렉터리를 옮긴 직후에 보내는 메시지가 캐시 쓰기 가격이 아니라 캐시 읽기 가격으로 청구됩니다.

이 차이가 사소하지 않은 이유는 캐시 요율 자체에 있습니다. Anthropic이 공개한 프롬프트 캐싱 요율에서 캐시 읽기는 표준 입력 단가의 약 10퍼센트, 즉 0.1배입니다. 반대로 캐시에 새로 쓰는 것은 기본 입력 단가의 1.25배가 붙습니다. 세션을 재시작하면 시스템 프롬프트, 도구 정의, 그리고 프로젝트의 CLAUDE.md가 모두 새 캐시로 다시 쓰여야 합니다. 큰 프로젝트일수록 이 프리픽스는 수만 토큰에 달합니다. /cd는 이 프리픽스를 다시 쓰지 않고 그대로 읽어 재사용합니다.

ThakiCloud는 멀티테넌트 환경에서 여러 고객의 에이전트와 배치 작업을 같은 인프라 위에서 돌립니다. 이런 환경에서 토큰 경제성은 곧 서비스 원가입니다. 코딩 에이전트가 디렉터리를 옮길 때마다 프리픽스를 다시 캐싱한다면, 그 비용은 세션 수와 전환 횟수에 비례해 누적됩니다. /cd처럼 캐시를 보존하는 동작 하나가 대규모 운영에서는 무시할 수 없는 절감으로 이어집니다. 그래서 이 기능은 “편한 단축키”가 아니라 “비용 위생”의 문제로 보는 편이 정확합니다.

이 기술은 무엇인가

프롬프트 캐시가 어떻게 작동하는지 먼저 짚어야 /cd의 가치가 보입니다. Claude Code는 매 턴마다 시스템 프롬프트, 도구 정의, CLAUDE.md를 자동으로 캐싱합니다. 별도 설정이 필요 없습니다. 이 캐시된 프리픽스가 대화 앞부분을 차지하고, 그 뒤에 매번 새로운 메시지가 붙습니다. 캐시가 살아 있으면 이 프리픽스는 읽기 요율로만 청구됩니다. 캐시가 깨지면 프리픽스 전체를 다시 써야 합니다.

세션을 재시작하거나 /clear로 맥락을 비우면 캐시가 무효화됩니다. 그런데 디렉터리를 옮기는 작업의 함정은, 새 디렉터리에 다른 CLAUDE.md가 있다는 점입니다. 상식적으로는 시스템 프롬프트에 들어가는 CLAUDE.md가 바뀌면 캐시가 깨져야 할 것 같습니다. /cd의 영리한 부분이 여기입니다. 목적지 디렉터리의 CLAUDE.md를 시스템 프롬프트에 다시 써 넣는 대신, 대화의 다음 메시지로 덧붙입니다. 시스템 프롬프트를 다시 쓰지 않으니 캐시된 프리픽스가 그대로 유지되고, 새 CLAUDE.md는 그저 뒤에 붙는 사용자 메시지 하나로 처리됩니다. 이것이 캐시를 지키면서도 새 디렉터리의 규칙을 반영하는 방법입니다.

아래 도표는 디렉터리를 옮길 때 두 경로가 캐시에 어떻게 다르게 작동하는지를 보여 줍니다.

flowchart TB
    A["디렉터리 A에서<br/>세션 진행 중<br/>(프리픽스 캐시 활성)"] --> B{"디렉터리 B로<br/>이동 필요"}
    B -->|"재시작 또는 /clear"| C["시스템 프롬프트·도구·<br/>CLAUDE.md 캐시 무효화"]
    C --> D["프리픽스 전체를<br/>다시 캐시 쓰기<br/>(1.25배 요율)"]
    D --> E["대화 맥락 손실"]
    B -->|"/cd 경로"| F["시스템 프롬프트 유지<br/>새 CLAUDE.md는<br/>메시지로 덧붙임"]
    F --> G["프리픽스 캐시 읽기<br/>(0.1배 요율)"]
    G --> H["대화·모델·권한<br/>그대로 유지"]

이 그림의 핵심은 오른쪽 경로가 시스템 프롬프트를 건드리지 않는다는 점입니다. 왼쪽 경로는 프리픽스를 다시 쓰면서 그동안 쌓은 대화까지 함께 버립니다. 같은 목적지에 도착하지만 지불하는 비용이 완전히 다릅니다.

왜 뒤에 붙이면 캐시가 살아남는지는 프롬프트 캐싱이 프리픽스 단위로 동작하기 때문입니다. 캐시는 대화의 앞부분, 즉 접두부가 이전과 동일한 만큼을 재사용합니다. 접두부의 한 글자라도 바뀌면 그 지점부터 뒤는 전부 다시 계산해야 합니다. 그래서 자주 바뀌는 내용을 앞에 두면 캐시 적중률이 떨어지고, 안정적인 내용을 앞에 두고 변하는 내용을 뒤에 붙이면 적중률이 올라갑니다. /cd가 새 CLAUDE.md를 시스템 프롬프트가 아니라 대화 끝에 메시지로 덧붙이는 것은 정확히 이 원리를 지키는 설계입니다. 캐시된 접두부는 손대지 않고, 변화는 캐시 경계 바깥에서 흡수합니다.

설치 및 통합

/cd는 별도 설치가 필요 없습니다. Claude Code v2.1.169 이상이면 바로 쓸 수 있습니다. 이 명령은 2026년 6월 8일에 릴리스되었습니다. 사용법은 단순합니다.

# 세션 안에서 다른 디렉터리로 이동
/cd ../consuming-service

# 절대 경로도 가능
/cd /Users/me/repo/apps/web

# 홈 기준 경로
/cd ~/repo/packages/core

명령을 실행하면 Claude Code는 작업 디렉터리를 갱신하고, 새 위치의 CLAUDE.md를 읽어 대화에 덧붙인 뒤, 하던 작업을 이어 갑니다. 대화 기록과 지금까지 내린 결정이 그대로 남아 있으므로, “방금 코어 모듈에서 고친 인터페이스를 이 서비스에서 검증해 줘” 같은 요청이 자연스럽게 이어집니다.

구체적인 예를 들어 보겠습니다. ThakiCloud의 플랫폼 워크스페이스는 Go 백엔드, 프론트엔드, GitOps 배포, 멀티클러스터 메시 등 일곱 개의 제품 리포지터리를 git 서브모듈로 묶어 둡니다. 백엔드 API의 응답 스키마를 바꾼 뒤 그 스키마를 소비하는 프론트엔드에서 화면이 제대로 나오는지 확인하는 작업은 이 구조에서 일상입니다. 예전 방식이라면 백엔드 세션을 닫고 프론트엔드 디렉터리에서 새 세션을 열어야 했고, 그러면 방금 무엇을 왜 바꿨는지를 새 세션에 다시 설명해야 했습니다. /cd를 쓰면 흐름이 끊기지 않습니다.

# 백엔드 서브모듈에서 스키마 수정 작업 진행 중
# ...

# 그 스키마를 소비하는 프론트엔드로 이동 (맥락·캐시 유지)
/cd ../ai-suite/apps/web

# 이어서 바로 물어봄: 방금 바꾼 필드명을 이 화면이 참조하는지 확인

이동 직후 프론트엔드 디렉터리의 CLAUDE.md가 대화에 덧붙으므로, 그 리포지터리의 규칙(FSD 경계나 TDS 토큰 사용 같은)이 즉시 반영됩니다. 동시에 백엔드에서 쌓은 맥락, 즉 어떤 필드를 왜 바꿨는지가 그대로 살아 있어 곧장 검증으로 넘어갈 수 있습니다.

캐시 경제성을 이해하려면 요율 표를 봐야 합니다. 아래는 Anthropic이 공개한 프롬프트 캐싱 요율을 정리한 것입니다.

한 가지 주의할 맥락이 있습니다. Anthropic은 2026년 3월에 기본 캐시 TTL을 60분에서 5분으로 조용히 줄였습니다. 5분 안에 다음 요청이 없으면 캐시가 만료되어 다시 쓰기 비용을 냅니다. 긴 간격으로 작업한다면 1시간 옵션을 켜는 것을 고려할 수 있지만, 쓰기 프리미엄이 2.0배로 올라가므로 트레이드오프를 따져야 합니다. /cd는 이 TTL 안에서 세션을 이어 갈 때 캐시를 살려 두는 역할이라, 짧은 TTL 시대에 오히려 더 중요해졌습니다.

실제 실험 결과

정직하게 밝히자면, /cd는 대화형 슬래시 명령이라 이 글을 작성한 헤드리스 환경에서는 실제 세션을 띄워 상호작용 벤치마크를 돌릴 수 없었습니다. 그래서 측정값을 지어내는 대신, 공개된 요율만으로 계산할 수 있는 비용 모델을 제시합니다. 아래 수치는 측정값이 아니라 문서 기준 요율 계산이며, 그 사실을 분명히 표시합니다.

디렉터리를 옮긴 직후 첫 요청에서 캐시된 프리픽스가 어떻게 청구되는지 두 경로를 비교해 보겠습니다. 재시작이나 /clear 경로에서는 프리픽스가 캐시 쓰기(1.25배)로 다시 기록됩니다. /cd 경로에서는 같은 프리픽스가 캐시 읽기(0.1배)로 재사용됩니다. 프리픽스 크기가 같다고 놓으면, 전환 직후 프리픽스에 대해 지불하는 비용의 비율은 1.25 나누기 0.1, 즉 12.5배입니다. 다시 말해 재시작 경로는 /cd 경로보다 프리픽스 재청구에서 약 12.5배 비쌉니다.

이 비율은 프리픽스의 절대 토큰 수와 무관하게 성립합니다. 다만 절대 절감액은 프리픽스가 클수록 커집니다. 대규모 프로젝트에서 시스템 프롬프트와 도구 정의, 그리고 두툼한 CLAUDE.md를 합친 프리픽스가 수만 토큰에 이르는 경우가 흔한데[추정], 이런 세션에서 하루에 디렉터리를 여러 번 오가면 재캐시 비용이 빠르게 쌓입니다. /cd는 그 전환마다 붙는 12.5배 프리미엄을 읽기 요율로 눌러 줍니다.

한 가지 더 짚을 점은, /cd가 지키는 것이 비용만이 아니라는 사실입니다. 재시작 경로에서 잃는 대화 맥락은 토큰으로 환산하기 어려운 비용입니다. 방금 고친 코드의 의도, 앞서 세운 가설, 이미 배제한 접근을 다시 설명해야 한다면 사람의 시간과 추가 토큰이 모두 듭니다. /cd는 이 재설명 비용까지 함께 제거합니다.

ThakiCloud 제품 적용 시사점

이 기능은 ThakiCloud의 두 제품 관점에서 모두 의미가 있습니다.

Paxis 관점에서 보면 /cd는 코딩 에이전트의 세션 위생 문제를 정확히 건드립니다. Paxis는 ThakiCloud의 Agent-Native Cloud로, 스킬과 도구, 정책, 감사 로그를 일급 리소스로 다루며 격리된 샌드박스에서 에이전트를 실행합니다. 코딩 에이전트가 여러 리포지터리와 서브모듈을 오가며 작업하는 것은 Paxis에서 흔한 시나리오입니다. 이때 전환마다 세션을 재시작해 프리픽스를 다시 캐싱한다면, 큰 스킬 하니스와 정책 컨텍스트를 매번 재청구하게 됩니다. /cd처럼 프리픽스를 보존하며 디렉터리 규칙만 메시지로 덧붙이는 방식은, 스킬 선택과 정책 게이트를 유지한 채로 작업 경로만 바꾸는 Paxis의 오케스트레이션 모델과 잘 맞습니다. 시스템 프롬프트를 다시 쓰지 않고 뒤에 컨텍스트를 덧붙인다는 발상 자체가, 상시 로딩되는 규칙 레이어를 캐시 안정성 관점에서 관리하는 원칙과 동일합니다.

ai-platform 관점에서는 캐시 경제성이 곧 멀티테넌트 서빙 원가입니다. ThakiCloud의 ai-platform은 K8s와 Kueue 기반 GPU 스케줄링 위에서 여러 고객의 추론 워크로드를 서빙합니다. 프롬프트 캐싱은 반복되는 프리픽스를 재사용해 입력 비용을 줄이는 핵심 레버인데, /cd가 보여 주는 원리, 즉 캐시를 깨지 않도록 컨텍스트를 앞이 아니라 뒤에 추가한다는 설계는 자체 서빙 스택에서도 그대로 적용됩니다. 캐시 무효화 지점을 최소화하도록 프롬프트 구조를 설계하면, 낮은 서빙 비용에서 경쟁력을 얻습니다. 두 렌즈는 서로를 보완합니다. 낮은 서빙 비용(ai-platform)이 에이전트 경제성(Paxis)을 만들고, 캐시를 지키는 에이전트 동작(Paxis)이 다시 인프라 부하를 낮춥니다.

한계 및 반론

/cd가 만능은 아닙니다.

먼저 캐시 보존은 5분 TTL 안에서만 의미가 있습니다. 디렉터리를 옮긴 뒤 오래 손을 놓으면 캐시가 만료되어, /cd를 썼든 안 썼든 다음 요청은 쓰기 비용을 냅니다. 짧은 TTL을 감안하면 /cd의 절감은 연속 작업 흐름에서 가장 크고, 간헐적 작업에서는 효과가 줄어듭니다.

둘째로, CLAUDE.md를 시스템 프롬프트가 아니라 메시지로 덧붙이는 방식에는 미묘한 함정이 있습니다. 세션 도중에 원본 프로젝트의 CLAUDE.md를 편집해도 그 변경은 캐시를 깨지 않는 대신, /clear나 /compact 또는 재시작 전까지는 적용되지 않습니다. 즉 규칙을 바꿨는데 세션이 이를 반영하지 않는 상황이 생길 수 있으므로, 규칙 변경 후에는 의도적으로 세션을 갱신해야 합니다.

셋째로, 캐시 절감 비율 12.5배는 어디까지나 전환 직후 프리픽스 재청구에 대한 문서 기준 계산입니다. 실제 세션 전체 비용에서 프리픽스가 차지하는 비중, 대화 길이, 전환 빈도에 따라 체감 절감폭은 달라집니다. 이 글의 비율을 “세션 비용이 12.5배 싸진다”로 확대 해석하면 안 됩니다. 정확히는 “전환 시점에 프리픽스를 다시 캐싱하지 않아도 된다”는 절감입니다.

그럼에도 결론은 분명합니다. 모노레포나 다중 리포지터리 작업에서 디렉터리를 오갈 일이 잦다면, /cd는 대화 맥락과 프롬프트 캐시를 동시에 지키는 가장 값싼 방법입니다. 코딩 에이전트를 비용까지 고려해 운영하는 팀이라면, 이 한 줄을 습관으로 만들 이유가 충분합니다.

출처

• Manage sessions - Claude Code Docs
• How Claude Code uses prompt caching - Claude Code Docs
• Claude Code /cd: Switch Projects Without Losing Cache
• 원 트윗(@delba_oliveira 리트윗)

이 글은 LLM 출력을 자동으로 채점하는 평가 파이프라인을 운영하거나, 사내 여러 팀이 공유하는 GPU 클러스터 위에서 모델 평가를 서비스 형태로 제공하려는 엔지니어를 위해 씁니다. “LLM에게 1점에서 10점 사이 점수를 매기게 한다”는 방식이 얼마나 취약한지, 그리고 그 취약함을 없애려면 무엇을 모델에게 맡기고 무엇을 코드가 가져와야 하는지를 다룹니다. 규제 산업이나 정부기관처럼 데이터를 외부로 보낼 수 없어 프론티어 API 심판을 쓸 수 없는 조직이라면 특히 관련이 깊습니다.

문제의식: 숫자 하나로 품질을 재는 방식은 이미 무너지고 있다

모델 개발과 안전 심사의 속도가 사람이 일일이 채점하는 속도를 훨씬 앞지르면서, LLM 스스로가 다른 LLM의 출력을 평가하는 LLM-as-a-judge는 사실상 기본 관행이 되었습니다. 그런데 이 관행은 얼어붙은 하나의 모델이 내놓는 스칼라 값이 사람이 매길 점수를 그대로 따라간다는 가정 위에 서 있고, 2026년 들어 쌓인 연구는 이 가정을 하나씩 무너뜨렸습니다. 심판 모델은 프롬프트 문구나 답안이 놓인 위치 같은 지엽적인 단서에 판정을 뒤집고, 채점 척도의 양 끝을 눌러 중간값으로 몰아가면서 정작 걸러내야 할 극단적인 사례를 뭉개 버립니다. 자신의 판정에 과도하게 확신하면서도 그 확신은 교정되어 있지 않고, 레드팀이 입력을 살짝 비틀면 판정은 동전 던지기와 다를 바 없어집니다. 자동화된 편향 탐지 도구와 문항반응이론 기반 진단은 이런 불안정성을 대규모로, 그리고 정량적으로 확인시켜 줍니다.

이 문제에 대한 연구 커뮤니티의 응답은 크게 두 갈래로 나뉩니다. 하나는 모델에게 점수를 묻는 대신 해석 가능한 예/아니오 질문을 묻는 방식으로, BINEVAL 같은 연구가 평가 기준을 이진 질문들로 분해해 스칼라 심판이나 쌍대비교 심판과 맞먹거나 그 이상의 성능을 내면서 어떤 하위 기준이 실패했는지까지 드러냅니다. 다른 갈래는 심판 주변에 구조를 더하는 방식으로, 여러 심판의 배심원단, 토론, 검증 유닛을 동원해 “심판이 쓰는 연산량” 자체를 늘려 견고함을 높이거나, 불확실한 사례만 골라 사람 수준의 합의를 보장받는 선택적 평가 계단식 구조를 씁니다.

문제는 이 두 갈래 응답이 거의 언제나 단일 머신 위의 오프라인 벤치마크로만 검증된다는 점입니다. 병원, 은행, 정부 연구소처럼 데이터 주권이 중요한 조직이 실제로 맞닥뜨리는 현실은 세 가지 지점에서 다릅니다. 데이터가 시설 밖으로 나갈 수 없으므로 평가는 프론티어 API가 아니라 조직 소유의 공유 GPU 클러스터에서 돌아가야 하고, 여러 팀이 같은 가속기를 두고 경쟁하므로 평가 서비스는 테넌트마다 비용과 꼬리 지연 예산을 지켜야 하며, 규제 담당자는 “몇 점인가”가 아니라 “왜 그 점수인가”를 묻는데 불투명한 스칼라 하나로는 그 질문에 답할 수 없습니다.

핵심 기여: ABJ-Gate가 묶어내는 네 가지 규율

ThakiCloud AI Research는 이 세 가지 현실 조건 위에서 두 연구 흐름을 하나로 묶은 아키텍처 ABJ-Gate를 제안합니다. 핵심은 평가 기준마다 원자적인 이진 질문으로 쪼개어 소형 온프렘 워커 모델이 답하게 하고, 그 답을 집계하고 형식을 정규화하고 교정하고 감사 기록을 남기는 일은 전부 모델이 아니라 결정론적 코드가 맡는다는 점입니다. 판정이 갈리는 경계 지점에 놓인 항목이나 의심스러운 정황이 감지된 항목은 반드시 홀수 개의 독립된 회의론자 워커가 “반박해 보라”는 지시를 받고 표결에 부쳐지며, 다수가 반박에 실패했을 때만 판정이 살아남습니다. 그리고 이 모든 LLM 호출 예산은 Kueue/GPU 기반 스케줄러가 테넌트별 비용과 꼬리 지연 상한 안에서 배분합니다.

이진 기준 5개, 플래그 비율 10%, 회의론자 3명을 가정한 분석 모델의 계산값입니다. 전체 항목을 이진 판정하면(k=1) 스칼라 심판 대비 비용이 약 5.3배로 뛰지만, conformal 교정으로 에스컬레이션을 줄여 샘플링 비율 k를 0.2까지 낮추면 해석 가능성과 교정을 유지한 채 스칼라 심판 비용의 약 1.06배까지 수렴합니다. 실측 벤치마크가 아닌 Eq. 8의 계산 결과입니다.

이 설계는 이 회사가 이미 사내 하네스에서 상시로 지키는 두 가지 규율, 즉 “형식은 코드가 소유하고 내용은 모델이 소유한다”는 원칙과 팬아웃된 검증 결과를 반드시 적대적 표결로 닫는다는 원칙을, 여러 테넌트가 함께 쓰는 정식 제품 표면으로 승격시킨 결과이기도 합니다. 워커 모델이 자기 답변의 길이나 개수, “전체적으로 몇 점”이라는 자기 보고를 아무리 그럴듯하게 내놓아도 그 값은 폐기되고 코드가 다시 계산하므로, 워커 쪽의 사소한 흔들림이 최종 결과를 오염시키지 못합니다.

이 아키텍처가 실제로 지켜야 할 약속은 세 가지 성질로 정식화되고 증명됩니다. 첫째, 동일한 이진 답변 집합이 주어지면 집계 점수는 무작위 시드나 요청 순서와 무관하게 항상 같은 값을 낸다는 재현성입니다. 둘째, 값싼 1단계 판정과 비싼 2단계 검증이 얼마나 자주 어긋나는지를 conformal 위험 통제로 교정하면, 항목이 어떤 분포에서 나오든 그 불일치율을 목표 수준 이하로 분포에 무관하게 묶어낼 수 있다는 위험 통제 보장입니다. 셋째, 각 테넌트의 이용률을 특정 임계값 아래로 관리하는 어드미션 정책을 두면 대기 이론상 그 테넌트의 평가 지연은 유한한 값으로 유계가 된다는 성질입니다.

M/G/c 큐잉 모델에서 이용률이 1에 가까워질수록 지연이 어떻게 치솟는지를 보여주는 개념 예시 곡선입니다. 어드미션 컨트롤이 샘플링 비율을 조절해 이용률을 목표 임계값 이하로 눌러 두면 꼬리 지연을 관리할 수 있다는 Proposition 3의 논거를 시각화한 것으로, 실측 지연 데이터가 아닙니다.

논문은 또한 이진 분해가 언제 실제로 도움이 되는지도 정량적으로 짚습니다. 각 기준을 사람이 스칼라 채점보다 더 안정적으로 답할 수 있고 기준들 사이의 상관이 낮아 서로 독립적인 정보를 담고 있을 때, 이진 분해와 다수결 검증은 스칼라 심판보다 엄밀하게 낮은 분산을 낸다는 조건을 유도합니다. 반대로 기준들이 서로 얽혀 있거나 이진 질문 자체가 손쉽게 눈속임당하는 형태라면 분해는 도움이 되지 않고 오히려 편향을 더할 수 있다는 점도 함께 밝힙니다.

논문 4.4절의 분석적 논거를 시각화한 개념도입니다. 집계 점수의 분산은 대략 기준당 오차분산을 유효 독립 기준 개수로 나눈 값에 비례해 줄어들며, 기준선(스칼라 심판=1배) 대비 상대적인 분산 감소 경향을 보여줍니다. 실험으로 측정된 수치가 아닙니다.

회사, 사회, 과학에 남기는 것

회사 관점에서 이 논문은 사내 GPU 스케줄링 인프라 위에서 돌아가는 이진 분해 심판, 결정론 집계 게이트, 테넌트별 비용과 지연 상한을 만족하는 샘플링 스케줄러를 하나의 완결된 설계로 정리했습니다. 이미 운영 중이던 내부 규율을 여러 테넌트가 함께 쓰는 제품 표면으로 끌어올린 것입니다. 사회적으로는 데이터가 밖으로 나갈 수 없어 프론티어 API 평가 서비스를 쓸 수 없었던 규제 산업 조직들이 배포 전 안전성과 품질 검증을 자기 하드웨어에서 상시로, 재현 가능하고 감사 가능한 방식으로 수행할 수 있는 길을 엽니다. 신뢰할 수 있는 AI 배포의 진입장벽을 낮추는 셈입니다. 과학적으로는 이진 분해라는 아이디어에 교정, 적대적 검증 표결, 결정론적 집계, 비용 유계 샘플링을 결합했을 때 심판의 신뢰도와 비용이 어떤 관계를 이루는지를 정량화하는 틀을 세우고, 그 관계를 최근 6개월 문헌 위에서 실증하기 위한 사전등록 프로토콜을 함께 제시합니다.

한계

논문이 스스로 분명히 밝히는 한계가 있습니다. 이 연구는 아키텍처와 세 가지 이론적 증명, 분석적 비용 모델, 그리고 그 프론티어를 사람 라벨 대비 검증하기 위한 사전등록 프로토콜을 제시할 뿐, 실측된 정확도 수치는 담고 있지 않습니다. 저자들은 프로토콜을 돌리지 않고 숫자를 보고하는 것 자체가 조작이라고 못 박고 의도적으로 수치를 비워 두었습니다. 그 밖에도 이진 질문 문구 자체가 눈속임당할 수 있다는 점, 교정 함수가 새로운 모델군이나 적대적 공격의 흐름 아래에서 드리프트할 수 있다는 점, 링크 생존만 확인하는 휴리스틱이 소프트 404 같은 정교한 실패는 놓친다는 점, 기준들이 서로 얽혀 있으면 분산 감소 논증 자체가 깨진다는 점을 한계로 명시하고 있습니다. 그리고 온프렘 소형 워커 모델은 프론티어급 심판보다 원래 성능이 낮아, 해석 가능성과 교정, 재현성, 비용 유계를 얻는 대가로 단일 심판으로서의 정확도를 일부 내준다는 점도 인정합니다.

논문 상세 정보는 Hugging Face에서 확인할 수 있습니다: https://huggingface.co/datasets/thaki-AI/daily-paper-2026-07-07-atomic-binary-judge-eval-service

관련 슬라이드

본문 내용을 NotebookLM(neo_swiss 스타일)으로 요약한 슬라이드입니다.

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

لنبدأ بالنقطة الأكثر مفارقة للحدس. الرسالة المحورية لهذا الدليل ليست “اكتب بشكل أفضل” بل تقترب أكثر من “اكتب أقل”. فالتعليمات المفصّلة التي كانت تُبنى لاستخلاص نتائج جيدة من النماذج السابقة قد تُضعف الجودة فعليًا مع Fable 5. لقد صُمم Fable 5 كنموذج يُفوَّض إليه العمل على مهام معقدة وطويلة وغامضة، من النوع الذي يستغرق من الإنسان ساعات أو أيامًا أو حتى أسابيع لإنجازه، ومثل هذا النموذج تعوقه المقابض الزائدة عن الحاجة. وبما أن ThakiCloud تُشغّل بنية تحتية لخدمات الذكاء الاصطناعي كخدمة (AI/ML SaaS) قائمة على Kubernetes، إلى جانب منصة عملاء (agents) تعمل فوقها، وتتعامل يوميًا مع مثل هذه العملاء المستقلة طويلة الأمد، فإن كل توصية في هذا الدليل تتحول عندنا مباشرة إلى مسألة قواعد تشغيل. يستعرض هذا المقال التحولات الأربعة التي يطرحها الدليل مع الاستناد إلى نص الوثيقة، ويوضح كيف تنعكس على منتجاتنا.

ما هو هذا الدليل؟

هذه الوثيقة هي صفحة “Prompting Claude Fable 5” الواردة ضمن قسم هندسة البرومبت في وثائق منصة Anthropic الرسمية. تتناول أنماط برمجة الأوامر والسقالات (scaffolding) الخاصة بـ Fable 5 والفئة الأعلى منه Mythos 5، وتتألف من أربعة عشر فصلًا. وهي، بمعزل عن وثائق البرومبت العامة الموجهة للأجيال السابقة، دليل ذو طابع انتقالي (migration) يركز على ما تغيّر تحديدًا في هذه العائلة من النماذج.

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

flowchart TB
    A["تفويض مهام مستقلة طويلة الأمد<br/>(بوحدات ساعات·أيام·أسابيع)"] --> B["التحول 1<br/>حذف التعليمات المفرطة"]
    A --> C["التحول 2<br/>ضبط الذكاء والتكلفة عبر effort"]
    A --> D["التحول 3<br/>تدقيق تقارير التقدم بالأدلة"]
    A --> E["التحول 4<br/>تفويض العملاء الفرعيين بشكل غير متزامن"]
    B --> F["إتاحة هامش لحكم النموذج"]
    C --> F
    D --> G["كبح تقارير التقدم الوهمية"]
    E --> H["معالجة متوازية وإعادة استخدام الذاكرة المخبأة"]
    F --> I["تنفيذ مستقل<br/>طويل الأمد وموثوق"]
    G --> I
    H --> I

التحول 1: لا تُضِف إلى البرومبت، بل احذف منه

أول توصية ترد في الدليل هي إعادة قراءة البرومبتات والمهارات (skills) الحالية وحذف التعليمات التي لم تعد ضرورية. يوضح الدليل أن البرومبتات والمهارات التي صُممت من أجل النماذج السابقة كثيرًا ما تكون مفرطة التوجيه (too prescriptive) بالنسبة لـ Fable 5، بل قد تُضعف جودة المخرجات فعليًا. وبعبارة أخرى، فإن لحظة القفزة الكبيرة في القدرات هي بالضبط اللحظة المناسبة لتنظيف التعليمات القديمة.

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

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

التحول 2: effort هو لوحة التحكم الرئيسية في الذكاء والزمن والتكلفة

في Fable 5، المقبض الأساسي لضبط التوازن بين الذكاء وزمن الاستجابة والتكلفة هو معامل effort. يوصي الدليل ببدء معظم المهام بمستوى high، واستخدام xhigh للأعباء التي تكون فيها القدرة أمرًا حاسمًا بشكل خاص، بينما تُستخدم medium أو low للأعمال المتكررة والنمطية. بعبارة أخرى، بدلًا من إطالة البرومبت لاستخلاص أداء أفضل، أصبح رفع effort أو خفضه بحسب طبيعة المهمة هو أسلوب التشغيل الأساسي.

هذا التغيير مهم من منظور تشغيلي. فرفع effort يجعل النموذج يجري استدلالًا (reasoning) أكثر، مما يرفع زمن الاستجابة والتكلفة معًا. لذا لا ينبغي التعامل مع effort كقيمة تُرفع دائمًا إلى أقصى حد، بل كمفهوم موازنة (budget) يُوزَّع بحسب صعوبة المهمة. فتشغيل المهام النمطية بمستوى xhigh يهدر التكلفة فقط، بينما معالجة القرارات الصعبة بمستوى low يقوّض الجودة. وهنا تصبح دقة توزيع effort، لا رهافة صياغة جملة البرومبت، هي العامل الذي يحدد النتيجة والفاتورة في آن واحد.

التحول 3: أخضِع تقارير التقدم لتدقيق قائم على الأدلة

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

يقدّم الدليل جملة تعليمات محددة لهذه المشكلة: قبل الإبلاغ عن التقدم، ينبغي تدقيق كل ادّعاء بمقارنته مع نتائج الأدوات (tool results) في الجلسة الحالية، والإبلاغ فقط عن العمل الذي يمكن الإشارة إلى دليل عليه، مع التصريح بوضوح إن كان أمر ما لم يُتحقق منه بعد. وفيما يلي نص التعليمة الأصلية كما ورد:

Before reporting progress, audit each claim against a tool result
from this session. Only report work you can point to evidence for;
if something is not yet verified, say so.

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

التحول 4: نظّم العملاء الفرعيين بشكل غير متزامن

التحول الرابع يتعلق ببنية تعدد العملاء (multi-agent). وفقًا للدليل، يتمتع Fable 5 باستقرار أعلى بكثير في إطلاق العملاء الفرعيين المتوازين والحفاظ عليهم، كما يدير بموثوقية العملاء الفرعيين طويلي الأمد والتواصل المستمر مع عملاء آخرين. والتوصية واضحة: استخدم العملاء الفرعيين بكثرة، مع تزويدهم بتوجيه صريح حول متى يكون التفويض مناسبًا، وفضّل التواصل غير المتزامن على أن ينتظر المنسّق (orchestrator) عودة كل عميل فرعي مع تعطّل التنفيذ في الأثناء.

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

دلالات التطبيق على منتجات ThakiCloud

ينعكس هذا الدليل بشكل مباشر بوجه خاص على منصة Paxis التي نُشغّلها. Paxis هي Agent-Native Cloud الخاصة بـ ThakiCloud، وهي مستوى تحكم يختار من بين أكثر من 960 مهارة (skill) عبر خوارزمية BM25 وينفّذها في صناديق معزولة (sandboxes)، مع تمرير كل إجراء عبر بوابات سياسة وسجلات تدقيق (audit logs). وتتطابق التحولات الأربعة في الدليل مع هذه البنية واحدًا واحدًا.

فلسفة الحذف في التحول الأول تتقاطع مع مبادئ تصميم المهارات في Skill Harness لدينا؛ إذ التزمنا فعلًا بإبقاء المهارات خفيفة (thin) وتكديس المعرفة النطاقية بكثافة في متن المهارة، مع التعامل مع أي جملة زائدة كتكلفة على السياق يجب إزالتها. وهذا التأكيد الرسمي على أن Fable 5 لا يفضّل التعليمات المفرطة يمنحنا سندًا لإزالة البنود التي كانت تسدّ ثغرات نماذج جيل سابق من مهاراتنا القديمة. أما التحقق القائم على الأدلة في التحول الثالث، فهو الدور الذي تؤديه أصلًا بوابات السياسة وسجلات التدقيق لدينا؛ فادّعاء النموذج بإنجاز مهمة يختلف عن كون هذا الإنجاز مدعومًا فعليًا بنتائج الأدوات وسجلات التدقيق، وPaxis تتعامل مع الثاني كمورد من الدرجة الأولى. وتنظيم العملاء الفرعيين بشكل غير متزامن في التحول الرابع يطابق تمامًا تنفيذ تعدد العملاء القائم على DAG لدينا؛ فبنية منسّق يُمرّر المهام المستقلة بالتوازي دون تعطّل ثم يُغلق الحلقة عبر عقدة تحقق، تتطابق تمامًا مع مبدأنا القاضي بإغلاق أي تفرّع متوازٍ (fan-out) عبر مرحلة تحقق.

كما يجب النظر إلى الأمر من زاوية البنية التحتية لمنصة ai-platform. فرفع effort إلى xhigh يزيد من عدد رموز الاستدلال (reasoning tokens) مما يرفع الطلب على حوسبة GPU، وإطلاق عدد كبير من العملاء الفرعيين المتوازين يولّد ذروة مؤقتة في حِمل GPU. صُممت منصة ai-platform لدى ThakiCloud لامتصاص هذا الحِمل المتغيّر عبر جدولة GPU قائمة على Kueue وعزل متعدد المستأجرين (multi-tenant). كما أن ملاحظة الدليل بأن إعادة استخدام الذاكرة المخبأة لدى العملاء الفرعيين طويلي الأمد تخفض التكلفة تتفق مع هدفنا في خفض تكلفة الخدمة (serving) في البيئات المحلية والسيادية. فالخدمة منخفضة التكلفة تصنع جدوى اقتصادية للعملاء، وهذه الجدوى تتيح بدورها تفويضًا متوازيًا أكثر جرأة، في حلقة تعزيز متبادلة.

القيود والاعتراضات

قبل التسليم المطلق بهذا الدليل، لا بد من توضيح عدة نقاط. أولًا، هذه الوثيقة موجهة تحديدًا لـ Fable 5 وMythos 5. فإن نُقلت استراتيجية الحذف أو الإعدادات الافتراضية لـ effort الموصى بها هنا مباشرة إلى نماذج بائعين آخرين أو إلى الجيل السابق، فقد تتراجع الجودة فعليًا. لذا يجب قراءة نطاق هذه التوصيات محصورًا داخل هذه العائلة من النماذج.

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

ثالثًا، الرقم القائل بأن تقارير التقدم الوهمية كادت أن تختفي تمامًا هو نتيجة اختبار داخلي أجرته Anthropic نفسها، وليس قيمة أعدنا التحقق منها بشكل مستقل في هذا المقال. نحن نتفق مع اتجاه فعالية تعليمات التحقق، لكن على كل مؤسسة أن تقيس معدل الفشل الفعلي في عبء عملها الخاص قبل أن تحدد مستوى الثقة المناسب. وأخيرًا، توصية جعل effort افتراضيًا عند high ترفع التكلفة وزمن الاستجابة معًا، لذا يجب على الفرق ذات الميزانية المحدودة أن تخفض بجرأة المهام النمطية إلى medium وlow لإيجاد توازنها الخاص في التوزيع.

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

المصادر

• Anthropic, “Prompting Claude Fable 5”, Claude Platform Docs: https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/prompting-claude-fable-5

</content>

0.11 دولار لكل مليون رمز مُدخل مخزّن مؤقتاً. هذا هو السعر الذي وضعته GLM-4.5 من شركة z.ai للمدخلات المتكررة بشكل متكرر، بينما يبلغ سعر المدخل القياسي 0.6 دولار لكل مليون رمز، ويبلغ سعر المخرج 2.2 دولار. مقارنة بأسعار المدخلات لدى النماذج الأمريكية الرائدة التي ما زالت في نطاق عدة دولارات، فإن هذا مستوى منخفض بشكل واضح. نماذج صينية أخرى مثل مينيماكس وديب سيك وكوين وكيمي تسير على المنوال نفسه بتسعير المدخلات في نطاق فائق الانخفاض يقارب 0.1 دولار. تشير بعض الإحصاءات إلى أن حصة النماذج الصينية من استهلاك الرموز العالمي، التي كانت أقل من 10 بالمئة في مطلع عام 2025، ارتفعت إلى نحو 50 بالمئة بحلول منتصف عام 2026. إذا اكتفينا بالأرقام، فالخلاصة بسيطة: أصبحت النماذج سلعة، والأسعار تتجه نحو الصفر.

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

إشارتان متعاكستان في اليوم نفسه

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

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

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

تتجه أسعار الرموز نحو الصفر، لكن القيمة تنتقل إلى ثلاث فواتير في طبقة التنفيذ: التحكم بالتكلفة، والتنفيذ الآمن، وإمكانية التدقيق.

القيمة لا تختفي بل تنتقل من مكان إلى آخر

يؤكد خبر ثالث هذا الانتقال مرة أخرى. قررت أمازون التوقف عن قبول عملاء جدد اعتباراً من 30 يوليو 2026 في منصة ميكانيكال تورك، وهي منصة توسيم البيانات بالحشد التي تعمل منذ عام 2005. هذه الخدمة التي كانت الممر المعياري لتوسيم بيانات تدريب الذكاء الاصطناعي، مثل تصنيف الصور ونسخ الصوت وتنقية البيانات، دخلت فعلياً في حالة تجميد. خلف هذا القرار رقم مرير: أظهر تحليل عام 2023 أن ما بين 33 و46 بالمئة من العاملين على هذه المنصة كانوا يستخدمون النماذج اللغوية الكبيرة بالفعل لإنجاز المهام. جلس النموذج في المقعد الذي صُمم أصلاً ليجلس فيه الإنسان لوضع التسميات.

لكن هذا لا يعني أن عمل التوسيم نفسه قد اختفى. لا يزال السوق ينمو، إذ يقدَّر بنحو 2.3 إلى 2.8 مليار دولار في عام 2026. غير أن محور النمو انتقل من العمل الجماهيري البسيط إلى خط أنابيب هجين يُعد فيه الذكاء الاصطناعي المسودة الأولى ويراجعها موظفون متخصصون. وهنا أيضاً، لم تختفِ القيمة، بل انتقلت من العمل المتكرر البسيط إلى عملية أعلى هي المراجعة وضمان الجودة. سواء تعلق الأمر بالرموز أو بالتوسيم، النمط واحد: الجزء الشائع يتجه نحو المجانية، وتصعد القيمة إلى العملية التي تجعل النتيجة موثوقة وآمنة.

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

الاختناق أيضاً ينتقل من مكان إلى آخر

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

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

الفواتير الثلاث التي انتقلت إليها القيمة

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

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

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

عدسة السحابة الأصيلة للوكلاء

عندما نجمع الفواتير الثلاث في مكان واحد، يتضح أنها ليست مشكلات منفصلة بل تنتمي إلى طبقة واحدة. ليست طبقة اختيار النموذج، بل طبقة تنفيذ النموذج فعلياً. منتج Paxis من ThakiCloud يُفهم بسرعة عبر هذه العدسة. Paxis هي سحابة أصيلة للوكلاء تتعامل مع المهارات والأدوات والسياسات وسجلات التدقيق كموارد من الدرجة الأولى. الفواتير الثلاث التي ذكرناها للتو هي بالضبط محاور تصميم هذا المنتج.

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

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

اعتراض لا يزال قائماً

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

في الختام

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

المراجع

• أسعار رموز واجهة برمجة تطبيقات GLM-4.5 (مدخل قياسي 0.6 دولار، مخرج 2.2 دولار، مدخل مخزّن مؤقتاً 0.11 دولار): وثيقة أسعار z.ai
• الحوسبة السرية والتحقق عن بُعد في بلاكويل من إنفيديا (بحمل زائد شبه معدوم): مدونة إنفيديا للمطورين
• كورفكس تُثبت أول تطبيق تشغيلي مُتحقَّق منه للحوسبة السرية على أنظمة إنفيديا HGX B200: بي آر نيوزواير
• أمازون ميكانيكال تورك تتوقف عن قبول عملاء جدد اعتباراً من 30 يوليو 2026: تِك كرانش
• 33 إلى 46 بالمئة من عمال ميكانيكال تورك يستخدمون النماذج اللغوية الكبيرة (دراسة عام 2023): arXiv:2306.07899
• تقدير مورغان ستانلي لإجمالي الإنفاق الرأسمالي التراكمي العالمي على مراكز بيانات الذكاء الاصطناعي حتى عام 2028 بنحو 2.9 تريليون دولار: تقرير كريبتو بريفينغ
• حجم سوق توسيم البيانات في عام 2026 يبلغ نحو 2.6 مليار دولار: موردور إنتليجنس
• فيرتيف توسّع إمداد الطاقة والتبريد لمراكز بيانات الذكاء الاصطناعي بمنشأة تصنيع جديدة في جوهور بماليزيا: غرفة أخبار فيرتيف

هذه المقالة موجّهة إلى المهندسين والقادة التقنيين الذين عليهم أن يقرّروا أي نموذج مفتوح يُشغّلونه على بنيتهم التحتية. إنها لمن يريد تجاوز الانطباعات من نوع “سمعت أن Llama جيد هذه الأيام” والتأكّد بالبيانات مما يُنزّله الناس فعلًا وما يُشغّلون عليه الاستدلال فعلًا. تقرير ATOM عمل نادر يقيس هذين المحورين في مكان واحد، وخلاصته أن مركز ثقل النماذج المفتوحة قد انتقل بوضوح خلال العام الماضي.

نظرة عامة: لماذا خريطة لمشهد النماذج المفتوحة الآن

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

يجيب تقرير ATOM (arXiv 2604.07190، نُشر في 8 أبريل 2026) عن هذا السؤال مباشرة. أعدّته Interconnects، ويغطّي نحو 1500 نموذج مفتوح رئيسي، ويربط بين تنزيلات Hugging Face وعدد النماذج المشتقة وحصة سوق الاستدلال ومقاييس الأداء لرسم لقطة للمنظومة بأكملها. تكمن قيمته في كونه خريطة للمنظومة من أعلى إلى أسفل بدلًا من كونه تفاخر منظّمة واحدة بنجاح نموذجها.

ماذا قاس تقرير ATOM

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

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

flowchart TB
    A["منظومة النماذج المفتوحة<br/>~1500 نموذج رئيسي"] --> B["عدسة التنزيل<br/>تنزيلات Hugging Face التراكمية<br/>+ المشتقات"]
    A --> C["عدسة الاستدلال<br/>حصة سوق الاستدلال<br/>على OpenRouter"]
    B --> D["ما يمسكه<br/>المطورون بأيديهم"]
    C --> E["أين تتدفّق<br/>حركة الإنتاج"]
    D --> F["تحليل متقاطع<br/>= خريطة ثلاثية الأبعاد"]
    E --> F
    F --> G["الخلاصة الأساسية<br/>النماذج المفتوحة الصينية<br/>نقلت مركز الثقل"]

النتيجة الأساسية: النماذج المفتوحة الصينية أعادت تشكيل المشهد

أثقل نتائج التقرير هي انقلاب في التوازن الإقليمي. تجاوزت النماذج المفتوحة الصينية المعسكر الأمريكي في صيف 2025، ووسّعت الفجوة منذ ذلك الحين بدلًا من إغلاقها. ليس هذا إصدارًا لامعًا واحدًا يتقدّم لفترة وجيزة، بل تحوّل بنيوي يُلاحَظ على محوري التنزيل والاستدلال معًا.

على محور التنزيل، الاسم الذي يرمز إلى هذا التحوّل هو Qwen. عائلة Qwen من Alibaba هي أكثر عائلة نماذج مفتوحة استخدامًا، إذ بلغت نحو مليار تنزيل تراكمي حتى مارس 2026. ويتجاوز عدد مشتقّاتها 100 ألف. تتبعها عائلات أخرى مثل Llama وDeepSeek وKimi، لكن الفجوة مع Qwen كبيرة. حمل عائلة واحدة لمنظومة مشتقة بهذا الحجم يعني أن طبقة المطورين الذين يُجرون الضبط الدقيق ويعيدون التوزيع فوقها أكثر سماكة بكثير. تعمل المنظومات بهذا النوع من الزخم. فالاستخدام الكثيف يُراكم الأدوات والوصفات، ووفرة الأدوات تدفع مزيدًا من الاستخدام.

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

لا يغطّي التقرير النماذج التي في مركز الاهتمام فقط. بل يتتبّع أيضًا صعود GPT-OSS، عائلة OpenAI المفتوحة الأوزان؛ والنفوذ المتنامي لمنظّمات صينية من الفئة الوسطى مثل Moonshot وZ.ai وMiniMax؛ وإشارات إلى إحراز المعسكر الأمريكي تقدّمًا متجدّدًا في النماذج المفتوحة. الملاحظة بأن المشهد تصنعه هذه الطبقة الوسطى السميكة لا بضعة أسماء في القمة تُحذّر بهدوء من خطورة استراتيجية تتّكئ على نموذج نجم واحد.

التنزيلات والاستدلال، عدستان مختلفتان

تستحق هذه النقطة نظرة أعمق، لأن الفرق بين هاتين العدستين بالنسبة لمن يصمّم بنية تحتية ليس مسألة إحصاء بل قرار عملي.

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

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

دلالات لـ ThakiCloud

يتداخل هذا التحوّل في المشهد تمامًا مع المشكلة التي تستهدفها منصة ai-platform من ThakiCloud. تجدول ai-platform موارد GPU باستخدام Kueue فوق Kubernetes، وتخدم مجموعة متنوّعة من النماذج المفتوحة في بيئة متعددة المستأجرين باستخدام vLLM. منظومة نماذج مفتوحة تتّسع ويتحرّك مركز ثقلها تعني أن قائمة النماذج التي يريد عملاؤنا خدمتها تتغيّر باستمرار.

أولًا، تزداد قيمة تجريد الخدمة الذي لا يرتبط بأي عائلة نماذج واحدة. فإذا كان التباين الحالي، مع تصدّر Qwen في التنزيلات وDeepSeek في الاستدلال، قد يتغيّر مجددًا خلال ستة أشهر، فإن على البنية التحتية أن تكون قادرة على نشر وتوسيع أي عائلة تصعد بالطريقة نفسها. هذه التقلّبية هي بالضبط سبب تعامل ai-platform مع النماذج كموارد من الدرجة الأولى وتوحيدها لخط أنابيب الخدمة.

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

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

الحدود والاعتراضات

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

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

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

المصادر

• ATOM Report: Measuring the Open Language Model Ecosystem, arXiv:2604.07190 (2026-04-08). https://arxiv.org/abs/2604.07190
• Interconnects, “What I’ve been building: ATOM Report”. https://www.interconnects.ai/p/what-ive-been-building-atom-report

هذه المقالة موجّهة إلى المهندسين والقادة التقنيين الذين يريدون خريطة منظّمة جيدًا بدلًا من قلق غامض أو تفاؤل مبالغ فيه بشأن وجهة الذكاء الاصطناعي. تُستهلَك كلمة “الذكاء الفائق” عادةً بوصفها مفردة من الخيال العلمي، لكن الأمر مختلف حين يبدأ مختبر رائد عالميًا بالتعامل معها جديًا كمشكلة تخطيط. نقرأ معًا ماذا تتوقّع DeepMind وعلى أي أساس، وماذا يعني ذلك التوقّع لنا نحن من نبني بنية تحتية ومنصّات وكلاء حقيقية.

نظرة عامة: الذكاء الفائق كمشكلة تخطيط لا كتجربة فكرية

يرسم تقرير Google DeepMind بعنوان From AGI to ASI (arXiv 2606.12683)، البالغ نحو 57 صفحة، الطريق من الذكاء العام على المستوى البشري إلى الذكاء الفائق، تمامًا كما يقول عنوانه. كتبه باحثون في DeepMind من بينهم Tim Genewein، ووفقًا للتغطية فهو الجزء الثالث في سلسلة متعمّدة من المختبر. بعبارة أخرى، بدأ هذا المختبر يتعامل مع الذكاء الفائق لا كموضوع يُناقَش يومًا ما بل كأمر ينبغي التخطيط له بدءًا من الآن.

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

المسارات الأربعة

ينظّم التقرير الطريق من الذكاء العام إلى الذكاء الفائق في أربعة مسارات. وهي ليست متعارضة، وقد تعمل عدة مسارات في آنٍ معًا متداخلة في الواقع.

flowchart TB
    A["الذكاء العام<br/>ذكاء عام على المستوى البشري"] --> B["المسار 1: التوسّع<br/>حوسبة وبيانات أكثر<br/>نماذج أكبر"]
    A --> C["المسار 2: تحوّل خوارزمي<br/>بنية جديدة<br/>تتجاوز المحوّلات"]
    A --> D["المسار 3: تحسين ذاتي تكراري<br/>الذكاء يُسرّع أبحاث الذكاء<br/>حلقة تغذية راجعة"]
    A --> E["المسار 4: متعدد الوكلاء<br/>وكلاء بشريو المستوى منسّقون<br/>على نطاق واسع وبإحكام"]
    B --> F["الذكاء الفائق<br/>ASI"]
    C --> F
    D --> F
    E --> F
    F --> G["مقيّد بحدود جوهرية<br/>سرعة الضوء والديناميكا الحرارية<br/>التعقيد وغودل"]

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

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

التحسين الذاتي التكراري: المسار الأكثر سخونة

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

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

حتى الذكاء الفائق مقيّد بالقانون الفيزيائي

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

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

دلالات لـ ThakiCloud

تبدو المسارات الأربعة في هذا التقرير مستقبليات مجرّدة، لكنها تتداخل بدرجة ملموسة مدهشة مع محاور تصميم المنتجات التي نبنيها. Paxis من ThakiCloud هي مستوى تحكّم من نوع Agent-Native Cloud يعمل فوق ai-platform، ويتعامل مع المهارات والأدوات والسياسات وسجلات التدقيق كموارد من الدرجة الأولى. يرتبط مساران من مسارات التقرير هنا مباشرة.

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

ثانيًا، تشكّل مجموعات متعددة الوكلاء. تعالج Paxis الأعمال المعقّدة لا بوكيل عملاق واحد بل بتنسيق وكلاء متعدد على شكل DAG يفكّكها. يركّز كل وكيل على أدوار محدّدة، ويُنتج الرسم الذي يشكّلونه ناتجًا يتجاوز مجموع القدرات الفردية. قوة التنسيق التي يتحدّث عنها المسار الرابع في التقرير أمر نتعامل معه فعلًا كنموذج تنفيذ للمنتج. والنقطة أننا نتعامل مع تنسيق الوكلاء المتعدد لا كقصة كبرى نحو الذكاء الفائق بل كطريقة لحلّ مشكلات اليوم العملية بشكل أفضل.

وحجّة الحدود ليست بلا صلة أيضًا. فحدود الديناميكا الحرارية والكمون والربط البيني التي يؤكّدها التقرير هي بالضبط مشكلات جدولة GPU والطاقة والتبريد وعرض نطاق الشبكة التي تواجهها ai-platform كل يوم. والبصيرة بأن سقف القدرة يُختزَل إلى موارد فيزيائية تعني أن من ينظّم تلك الموارد بكفاءة أكبر يصبح صاحب الميزة التنافسية. وجدولة GPU المستندة إلى Kueue وتحسين الخدمة عبر vLLM وعزل الموارد متعدد المستأجرين هي بالضبط الآليات لإنفاق تلك الميزانية الفيزيائية باقتصاد قدر الإمكان.

الحدود والاعتراضات

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

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

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

المصادر

• From AGI to ASI, arXiv:2606.12683 (2026). https://arxiv.org/abs/2606.12683
• Google DeepMind, “From AGI to ASI” publication page. https://deepmind.google/research/publications/239142/