يخفض Prompt Caching في Claude معالجة الإدخال المتكرر فقط عندما تشترك الطلبات المتتالية في بادئة متطابقة وطويلة بما يكفي. النمط الإنتاجي واضح: رتّب الطلب على شكل أدوات ثم تعليمات نظام ثم سياق ثابت، وضع نقطة الكاش عند آخر كتلة ثابتة حرفيًا، واترك الوقت وبيانات المستخدم والطلب المتغيرة بعدها، ثم أثبت النتيجة عبر cache-read tokens وأدوات التشخيص. يناسب هذا الأسلوب التعليمات أو المستندات الطويلة المتكررة، ولا يناسب الطلبات القصيرة أو قليلة التكرار أو المحتوى الذي يتغير في كل مرة.
قسّم الطلب إلى بادئة ثابتة وذيل متغير
توضح وثائق Prompt Caching من Anthropic أن ترتيب البادئة هو tools ثم system ثم messages. تحسب نقطة الكاش بصمة كل شيء من بداية الطلب حتى الكتلة المحددة. لذلك يؤدي أي تغيير قبلها إلى بادئة مختلفة. السؤال الصحيح ليس «أي فقرة مكلفة؟» بل «أي بادئة مرتبة تبقى مطابقة تمامًا بين الطلبات التي نريد أن تشارك المعالجة؟».
في مساعد خدمة العملاء، قد تضم البادئة الثابتة مخططات الأدوات المرتبة وتعليمات التشغيل ووثائق المنتج والأمثلة المعتمدة. ويضم الذيل المتغير صلاحيات المتجر المحددة ورسالة العميل ونتائج الاسترجاع الجديدة. وفي تحليل المستندات، يمكن أن يكون المستند نفسه هو البادئة وكل سؤال هو الذيل. أما في وكيل برمجي، فقد يثبت كتالوج الأدوات وتعليمات المستودع وتتغير المهمة ونتائج الأدوات.
الثبات الحرفي مهم. إضافة توقيت داخل system prompt، أو اختلاف ترتيب مفاتيح JSON، أو إعادة ترتيب الأدوات، أو توليد وصف جديد يبطل المطابقة حتى لو بقي المعنى واحدًا. استخدم تسلسلًا حتميًا لمخططات الأدوات، وأصدر السياق الثابت برقم نسخة واضح، واترك request ID والتوقيت وبيانات التتبع خارج النص ما لم يحتجها النموذج فعلًا. هذا ليس Semantic Cache؛ بل إعادة استخدام لبادئة مطابقة لا بحثًا عن معنى متشابه.
اختر بين الكاش التلقائي ونقاط الكاش الصريحة
يضيف الكاش التلقائي cache_control في أعلى الطلب ويحرك نقطة الكاش مع نمو المحادثة. يصلح كنقطة بداية لمحادثة Append-only يعاد فيها إرسال سجل لم يتغير وتضاف إليه كتل قليلة في كل جولة. توضح Anthropic أن النظام يبحث إلى الخلف عن بادئة سبق أن كتبها ضمن نافذة من 20 كتلة، لذلك يعمل الوضع التلقائي جيدًا عندما تضاف الجولات دون إعادة كتابة التاريخ السابق.
تناسب النقاط الصريحة طلبًا يملك بادئة ثابتة وبعدها ذيل متغير. ضع cache_control على آخر كتلة ثابتة، لا على كتلة تحتوي وقت الطلب أو سؤال المستخدم أو نتيجة RAG الجديدة. تسمح الوثائق بأربع نقاط كحد أقصى. ويمكن فصل تعريفات الأدوات قليلة التغيير عن حزمة المعرفة اليومية، أو الحفاظ على نقطة قابلة للوصول عندما تتجاوز المحادثة الطويلة نافذة البحث. عدد النقاط نفسه لا يضيف تكلفة؛ ما يحدد الفاتورة هو حجم الكتابة والقراءة والمدخل غير المخزن.
من الأخطاء الشائعة وضع نقطة واحدة عند نهاية الطلب كله بينما تتغير كتلته الأخيرة في كل استدعاء. يكتب النظام إدخالًا لتلك البادئة الدقيقة، لكن الطلب التالي لا يطابقها. والبحث إلى الخلف يعثر فقط على إدخالات كتبتها طلبات سابقة؛ لا ينشئ تلقائيًا كاشًا عند حد ثابت غير معلّم. لذلك ضع نقطة صريحة قبل البيانات المتغيرة.
ابنِ عقد طلب حتميًا واحدًا
يبقي المثال التالي سياسة التشغيل وحزمة المراجع قبل نقطة الكاش، ويضع صلاحية المتجر والسؤال بعدها. تعامل مع اسم النموذج وترتيب الأدوات ومخططاتها وكتل النظام كإعدادات لها نسخ. استبدل النصوص التوضيحية ببيانات متحقق منها، ونفّذ التفويض قبل تكوين الطلب.
const stableSystem = [
{ type: 'text', text: POLICY_V3 },
{
type: 'text',
text: PRODUCT_REFERENCE_2026_10,
cache_control: { type: 'ephemeral', ttl: '1h' }
}
];
const response = await anthropic.messages.create({
model: 'claude-sonnet-5-5',
max_tokens: 1200,
tools: stableToolsSortedByName,
system: stableSystem,
messages: [{
role: 'user',
content: [
{ type: 'text', text: `Tenant scope: ${authorizedScope}` },
{ type: 'text', text: userQuestion }
]
}]
});
observe({
input: response.usage.input_tokens,
cacheWrite: response.usage.cache_creation_input_tokens,
cacheRead: response.usage.cache_read_input_tokens
});مدة الساعة ليست أفضل تلقائيًا. استخدمها عندما يرجح تكرار البادئة الكبيرة بعد فواصل تتجاوز خمس دقائق وتبرر الحركة تكلفة الكتابة الأعلى. تتجدد مدة الدقائق الخمس عند القراءة، لذلك قد يبقيها الحمل النشط دافئة. قِس توزيع الزمن بين الطلبات لكل نسخة من البادئة بدل اختيار TTL بالحدس. وعند مزج مدد مختلفة، اتبع ترتيب Anthropic وضع المحتوى الأطول عمرًا قبل الأقصر.
احسب نقطة التعادل من حركة الاستخدام
تصف صفحة الأسعار ودليل الكاش حاليًا كتابة الخمس دقائق بتكلفة 1.25 من سعر إدخال النموذج، وكتابة الساعة بمعامل 2، والقراءة القياسية بمعامل 0.1، مع استثناءات موثقة لبعض النماذج. قد تتغير هذه المعاملات، لذلك استخدم سعر النموذج الحالي ولا تحولها إلى افتراض ميزانية دائم. تبقى مخرجات النموذج والذيل غير المخزن محسوبة بصورة عادية.
لبادئة حجمها P من التوكنات، قارن مسارًا بلا كاش مع كتابة واحدة وعدد القراءات المتوقع داخل TTL. وفق المعاملات القياسية، تعوّض إعادة الاستخدام زيادة تكلفة كتابة الخمس دقائق لأن كل إصابة أرخص بكثير. تحتاج كتابة الساعة إلى تكرار أكبر كي تسترد تكلفتها الأعلى. والوحدة المهمة ليست عدد طلبات اليوم، بل عدد الطلبات التي تستخدم نسخة البادئة نفسها داخل النافذة. عشرة متاجر بعشر سياسات مختلفة قد تنشئ عشرة إدخالات باردة رغم ارتفاع الحمل الكلي.
استخدم واجهة عد التوكنات لتقدير الأدوات والمستندات والرسائل قبل الإرسال. تختلف الحدود الدنيا بحسب النموذج. تسرد الوثائق الحالية 512 توكن لعدد من النماذج الحديثة و1,024 أو أكثر لنماذج أخرى، وتوضح أن بادئة أقصر من الحد قد تعالج دون كاش ودون خطأ. افحص الحد الحالي للنموذج وتحقق من usage fields بدل افتراض أن وجود cache_control يضمن الكتابة.
صمّم الإبطال كهرم مترابط
ينتج عن ترتيب البادئة ترتيب للإبطال. تغيير tools يبطل كاش الأدوات وكل ما بعده. وتغيير system يبقي بادئة الأدوات صالحة إن لم تتغير، لكنه يبطل system والرسائل. أما تغيير الرسائل فيؤثر في طبقة الرسائل. وتغيير النموذج يمنع إعادة الاستخدام لأن هوية الكاش مرتبطة بالنموذج. لذلك تكوين الطلب قرار معماري، لا Decorator يضاف حول الاستدعاء.
ثبّت تعريفات الأدوات بين الطلبات العادية. لا تضع صلاحيات متجر بعينه داخل وصف الأداة؛ طبّق التفويض في كود التطبيق وضع نطاق العمل الضروري في الذيل المتغير. امنح كل إصدار معرفة بصمة واضحة مثل product-reference:v42. سخّن البادئة الجديدة بطلب واحد، وانتظر بدء استجابته لأن الإدخال لا يصبح متاحًا قبل ذلك، ثم اسمح للحمل المتوازي باستخدامها. واحتفظ بالإصدار السابق أثناء طرح مضبوط كي لا يفرض التراجع بادئة غير مختبرة.
في أنظمة Multi-tenant، الكاش ليس حد صلاحيات. لا توسع البيانات المسترجعة أو أذونات الأدوات لرفع معدل الإصابة. شارك فقط محتوى آمنًا ومتطابقًا ضمن نطاق المشاركة. يمكن وضع معلومات المنتج العامة في بادئة مشتركة، ثم سياق المتجر الخاص بعدها، أو إنشاء بادئات ثابتة خاصة بكل متجر مع إظهار هوية المتجر في مقاييسك. العزل والأمان أهم من نسبة إصابة مرتفعة.
راقب الإصابات والإخفاقات ونسخ البادئة
يبلغ الطلب الأول الناجح عادة عن cache_creation_input_tokens، ويبلغ الطلب الذي يصيب الكاش لاحقًا عن cache_read_input_tokens. سجل القيمتين مع input_tokens والنموذج ونسخة البادئة ونوع TTL ومسار المنتج. من المؤشرات المفيدة: توكنات القراءة نسبةً إلى البادئة المؤهلة، وتوكنات الإنشاء لكل نسخة، وتوزيع زمن الاستجابة عند الإصابة والإخفاق، وتكلفة العملية المكتملة للمستخدم. لا تعتبر نسبة إصابة عالية نجاحًا إذا قدم السياق القديم أو النطاق الخاطئ جوابًا ضارًا.
تستطيع Cache Diagnostics من Anthropic مقارنة طلبين متتاليين عند تفعيلها. مرر معرّف الاستجابة السابقة، وقد تعيد سبب أول اختلاف مثل model_changed أو system_changed أو tools_changed أو messages_changed. وتذكر الوثائق أن البصمات تحتوي Hashes وتقديرات توكنات لا نص Prompt الخام، وأنها مقيدة بالمؤسسة وWorkspace وتحتفظ بها مدة محدودة. الميزة متاحة حاليًا عبر Claude API، لذلك ابنِ تتبعًا لنسخة البادئة حتى عند تشغيل Claude عبر منصة أخرى.
اقرأ التشخيص وusage معًا. عدم وجود اختلاف مع صفر cache-read قد يعني انتهاء TTL. وجود system_changed مع صفر قراءة يشير إلى عدم ثبات الطلب. أما قراءة مرتفعة مع تغيير متأخر في الرسائل فقد تعني إصابة نقطة أسبق. احتفظ في سجلاتك بتمثيل منقح أو Hash لكل طبقة من الطلب، ولا تحفظ الأسرار الخام، حتى تربط أي تغيير في Serialization بهبوط مفاجئ في الإصابات.
اعرف متى لا يكون Prompt Caching هو الحل
استخدمه للسياسات الطويلة المشتركة والمستندات المتكررة وكتالوج الأدوات الثابت والأمثلة المتكررة والمحادثات التي تنمو بالإضافة. قد يخفض معالجة الإدخال، لكنه لا يحسن دقة الاسترجاع أو صحة الحقائق أو التفويض. إذا احتاج كل طلب دليلًا مختلفًا فابنِ مسار RAG. وإذا كانت الإجابة بيانات منظمة حتمية فاستخدم SQL أو API. وإذا كان Prompt قصيرًا ونادر التكرار فقد لا تعوض الكتابة والتشغيل تكلفتهما.
لا تخزن حقيقة تجارية قديمة لمجرد أن إرسالها مكلف. حدد مالكًا وسياسة تحديث لكل حزمة سياق ثابت. لا تنقل بيانات حساسة إلى بادئة أوسع بحثًا عن إعادة استخدام أكبر. لا تحشو Prompt بنص غير ذي صلة لتجاوز الحد الأدنى. ولا تختبر المسار المتسلسل فقط: قد تخفق أول موجة متوازية كاملة لأن الإدخال الجديد لا يصبح متاحًا إلا بعد بدء أول استجابة.
لا يحل Prompt Caching محل تقييم RAG أو تشغيل الوكلاء الدائم. بل يندمج معهما: خزّن التعليمات والمخططات الثابتة، واسترجع الدليل الجديد والمصرح به في الذيل، ثم قيّم الإجابة المرتبطة بالمصادر. وعند ترحيل النموذج، اربط عقد الكاش مع دليل طرح Claude Sonnet 5.5 لأن تغيير النموذج ينشئ هوية كاش مختلفة.
اطرح الميزة باختبار قبول صريح
ابدأ بمسار مرتفع الاستخدام وحدد بادئته الثابتة بدقة. اجعل Serialization حتميًا، وقِس التوكنات، واختر TTL من الفواصل الفعلية بين الطلبات، وأضف اسم نسخة واضحًا. أرسل طلب تسخين واحدًا، ثم تحقق أن الطلب اللاحق يبلغ عن cache-read tokens. غيّر طبقة واحدة كل مرة—سؤال المستخدم ثم ذيل الرسائل ثم كتلة النظام ثم مخطط الأداة—كي تثبت أي تعديل يحافظ على البادئات السابقة وأيها يبطلها.
قبل الإنتاج، اختبر انتهاء الصلاحية وموجة متوازية باردة وإصدار محتوى جديدًا وFallback إلى نموذج آخر. ضع تنبيهًا على النمو غير المتوقع في creation tokens أو انهيار read tokens، لكن اربطه بزمن المنتج وتكلفته بدل حد عام مختلق. الهدف التشغيلي هو بادئة قابلة لإعادة الاستخدام بضبط واضح واقتصاد قابل للرصد وإبطال آمن. إذا لم يستطع الفريق تحديد ما يُخزن، ومن يشاركه، ومتى يتغير، وكيف يثبت الإصابة، فالكاش غير جاهز للإنتاج. ولتنفيذ ذلك ضمن منتج ذكاء اصطناعي، راجع خدمة تكاملات AI وأنظمة الاسترجاع.
المراجع الرسمية
تدعم هذه المراجع سلوك الأدوات المذكورة. الأمثلة وقرارات التصميم توضيحية، ويجب تكييفها مع متطلبات المشروع وإصداراته.
إعداد: Noor Yasser
تعمل على تحدٍ تقني مشابه؟
أساعد الفرق على تحويل القرار المعماري إلى نطاق واضح وتنفيذ يمكن تشغيله ومراجعته بثقة.
