تخزين البادئات الطويلة مؤقتًا
التحكم في التكاليف باستخدام التخزين المؤقت للتلقينات.
تخزين البادئات الطويلة مؤقتًا درس مجاني في AI Prompt Engineering على CoddyKit. هذا هو الدرس 4 من أصل 4. يمكنك قراءة الدرس كاملاً أدناه مجاناً — ثم تمرن عليه مباشرة في المتصفح باستخدام محرر أكواد مدمج ومدرس ذكاء اصطناعي متاح 24/7. هذا الدرس جزء من مسار التعلم في AI Prompt Engineering، وتقدمك يتزامن عبر الويب وتطبيق CoddyKit. تتضمن دورة AI Prompt Engineering 4 دروس في المجموع.
سبب وجود التخزين المؤقت للبادئة
تتحمل كل مطالبة طويلة تكلفة المعالجة المسبقة لترميز رموزها قبل التوليد. وعندما تتكرر البادئة الطويلة نفسها عبر طلبات متعددة — مثل مطالبة النظام، أو مواصفات أداة، أو مستند مرجعي كبير — يتيح التخزين المؤقت للمطالبة لمقدم الخدمة إعادة استخدام حالة الانتباه المحسوبة مسبقًا بدلًا من إعادة حسابها.
- تقلل إصابات ذاكرة التخزين المؤقت زمن الاستجابة وتكلفة الإدخال بدرجة كبيرة.
- تزداد الوفورات مع حجم البادئة وتكرار إعادة استخدامها.
التخزين المؤقت قائم على البادئة
تعتمد ذاكرات التخزين المؤقت على تطابق تام لبادئة الرموز بدءًا من أول المطالبة. ويمتد الجزء المخزن مؤقتًا من البداية حتى أول نقطة اختلاف. غيّر أي شيء في البداية، وستفقد ذاكرة التخزين المؤقت صلاحيتها لكل ما يأتي بعده.
النتيجة: يضع التخطيط الذي يزيد الإصابات إلى أقصى حد المحتوى الأكثر ثباتًا أولًا، والمحتوى الأكثر تغيرًا أخيرًا.
# Cache reuse covers: [identical prefix .... first difference)
# One early edit invalidates the whole downstream cache.رتّب المحتوى بحسب الثبات
رتّب المحتوى من الأكثر ثباتًا إلى الأقل ثباتًا: قواعد النظام الثابتة وتعريفات الأدوات أولًا، ثم المواد المرجعية الكبيرة الثابتة، ثم السياق الثابت خلال الجلسة، ثم الإدخال والسؤال المتغيران لكل طلب في النهاية.
- الثابت ← في المقدمة (قابل للتخزين المؤقت).
- المتغير ← في الخلف (الجزء الوحيد الذي يُعاد حسابه).
يقود مبدأ الترتيب الواحد هذا معظم مكاسب التخزين المؤقت.
prompt = [
SYSTEM_RULES, # never changes
TOOL_SPECS, # rarely changes
REFERENCE_CORPUS, # stable for the session
USER_TURN # changes every call -> keep last
]نقاط فصل التخزين المؤقت
يتيح بعض مقدمي الخدمة وضع نقاط فصل صريحة للتخزين المؤقت. ضعها في نهاية كل مقطع ثابت حتى يتمكن النظام من التخزين المؤقت حتى تلك النقطة. حدّد أكبر كتلة ثابتة (مجموعة المراجع أو مطالبة النظام الطويلة) باعتبارها قابلة للتخزين المؤقت.
حتى من دون علامات صريحة، نظّم المحتوى وفق ترتيب الثبات بحيث يظل تطابق البادئة الضمني مفيدًا.
blocks = [
{'text': SYSTEM_RULES, 'cache': True},
{'text': REFERENCE_CORPUS, 'cache': True}, # big win
{'text': user_turn} # uncached
]احذر الانجراف الخفي للبادئة
تؤدي التغييرات الطفيفة غير المقصودة إلى كسر التخزين المؤقت بصمت: مثل طابع زمني في مطالبة النظام، أو معرّف خاص بكل طلب يُدرج مبكرًا، أو إعادة ترتيب تعريفات الأدوات، أو ترتيب مفاتيح JSON غير الحتمي. إذ يغيّر كل منها البادئة ويفرض إعادة حساب كاملة.
دقّق في بادئتك بحثًا عن أي شيء يتغير بين الطلبات، وانقله إلى ما بعد المنطقة المخزنة مؤقتًا.
# BAD: dynamic value early -> kills cache
# system = 'Session ' + str(uuid4()) + ' rules: ...'
# GOOD: keep system static; put the id in the tail user turn.TTL وعمر ذاكرة التخزين المؤقت
تنتهي صلاحية ذاكرات التخزين المؤقت بعد مدة بقاء يحددها مزود الخدمة، وغالبًا ما تُجدَّد عند كل إصابة. وتتكرر حالات عدم الإصابة الباردة إذا كانت الاستدعاءات متباعدة جدًا. يكون التخزين المؤقت مفيدًا لأحمال العمل المتقطعة وعالية التكرار، أما الاستدعاءات النادرة والمتباعدة فقد تنتهي صلاحية الذاكرة المؤقتة بينها.
طابق نمط حركة المرور لديك مع TTL، وفكّر في استخدام إشارات ping للإبقاء على الاتصالات حية للبوادئ المهمة.
نموذج تكلفة التخزين المؤقت
يفرض التخزين المؤقت عادةً تكلفة إضافية صغيرة عند كتابة إدخال في الذاكرة المؤقتة، وخصمًا كبيرًا عند قراءته. وتصبّ الجدوى الاقتصادية في صالح إعادة الاستخدام: إذ تؤدي كتابة واحدة موزعة تكلفتها على قراءات كثيرة إلى توفير صافٍ كبير، بينما قد تكون تكلفة الاستخدام الوحيد الذي يكتب فقط أعلى قليلًا.
- إعادة استخدام متكررة -> استخدم التخزين المؤقت بكثافة.
- البوادئ المستخدمة مرة واحدة -> قد لا يكون التخزين المؤقت مجديًا.
def worth_caching(prefix_tokens, expected_reuses, write_mult, read_mult):
no_cache = expected_reuses
cached = write_mult + read_mult * (expected_reuses - 1)
return cached < no_cache # in normalized prefix-cost unitsتصميم كتل نظام مستقرة
اجعل مطالبة النظام ومواصفات الأدوات حتمية، وثبّت إصداراتها. رتّب تعريفات الأدوات ترتيبًا قانونيًا، وتجنب تضمين بيانات متغيرة، ولا تغيّرها إلا ضمن إصدارات مخطط لها. تصبح كتلة النظام المستقرة إدخالًا طويل الأجل وعالي الإصابة في الذاكرة المؤقتة، ومشتركًا بين جميع الطلبات.
تعامل مع البادئة المخزنة مؤقتًا باعتبارها عنصرًا له إصدار، لا نصًا تعدّله على نحو عابر.
TOOLS = sorted(tool_defs, key=lambda t: t['name']) # canonical order
SYSTEM_VERSION = 'v3' # change deliberately, not per requestالتخزين المؤقت في الوكلاء متعددي الجولات
في حلقات الوكلاء، تكون المحادثة المتنامية ذاكرةً مؤقتة طبيعية: إذ تضيف كل جولة امتدادًا إلى بادئة تعيد الجولة التالية استخدامها. أضف الجولات الجديدة إلى الذيل، ولا تعِد كتابة الجولات السابقة أبدًا، حتى تظل الذاكرة المؤقتة السابقة صالحة.
عندما تضطر إلى ضغط المحادثة، فنّذه بطريقة تنشئ بادئة مستقرة جديدة للجولات اللاحقة، بدلًا من تعديل البوادئ القديمة مرارًا.
قياس فعالية التخزين المؤقت
أضف أدوات القياس. يقدّم معظم مزودي الخدمة تقارير عن الرموز المميزة المُدخلة من الذاكرة المؤقتة وتلك غير المخزنة مؤقتًا لكل استدعاء. تتبّع معدل الإصابة، وإذا كان منخفضًا، فافحص البادئة بحثًا عن التغيّر التدريجي. يشير تراجع معدل الإصابة عادةً إلى قيمة متغيرة أُدخلت مؤخرًا في موضع مبكر من المطالبة.
- سجّل cached_tokens / total_input_tokens.
- أطلق تنبيهًا عند انخفاض معدل الإصابة بعد النشر.
hit_rate = usage['cache_read_input_tokens'] / max(1, usage['input_tokens'])
assert hit_rate > 0.6, 'prefix drift suspected'تخطيط مطالبة يراعي التخزين المؤقت
للتحكم في تكلفة البوادئ الطويلة: رتّب المحتوى حسب درجة ثباته، وعيّن أكبر كتلة مستقرة كنقطة توقف للتخزين المؤقت، وأزل التغيّر الخفي، وثبّت كتل النظام والأدوات وأصدرها بإصدارات، واجعل الإضافة مقتصرة على الذيل في حلقات الوكلاء، وراقب معدل الإصابة. الهدف هو إنشاء بادئة كبيرة قابلة لإعادة الاستخدام وذيل صغير متغير يُعاد حسابه عند كل استدعاء.
تحقق سريع
تعيد استخدام مجموعة مراجع مؤلفة من 100k رمز مميز عبر آلاف الاستعلامات اليومية، لكن معدل إصابة الذاكرة المؤقتة لديك يقترب من الصفر.
مراجعة: تخزين البوادئ الطويلة مؤقتًا
يعيد التخزين المؤقت للمطالبات استخدام عملية التهيئة لبادئة ثابتة ومطابقة تمامًا، مما يخفض زمن الاستجابة وتكلفة الإدخال بدرجة كبيرة عند تكرار إعادة الاستخدام. رتّب المحتوى بدءًا من الأكثر ثباتًا، وعيّن الكتلة الكبيرة المستقرة كنقطة توقف، وادفع كل التغيّر إلى الذيل. أزل التغيّر الخفي، وثبّت كتل النظام والأدوات وأصدرها بإصدارات، واجعل الإضافة مقتصرة على الذيل في حلقات الوكلاء، وراقب معدل الإصابة حتى يكشف التراجع عن قيمة جديدة متغيرة في موضع مبكر.
تعلم AI Prompt Engineering مع معلم ذكاء اصطناعي — مجانًا
اكتب وقم بتشغيل أكوادك الفعلية في المتصفح، واحصل على مساعدة فورية من معلم ذكاء اصطناعي متاح 24/7، واستمر من حيث توقفت على الويب أو في التطبيق.
- الدورات
- 53
- الدروس
- 199
الأسئلة الشائعة
هل درس «تخزين البادئات الطويلة مؤقتًا» مجاني؟
نعم — نص درس «تخزين البادئات الطويلة مؤقتًا» كامل متاح مجاناً هنا على الويب. لتمرينه بشكل تفاعلي (محرر أكواد مدمج ومدرس ذكاء اصطناعي متاح 24/7) وفتح باقي دورة AI Prompt Engineering، انتقل إلى CoddyKit PRO. تتضمن دورة AI Prompt Engineering 4 دروس في المجموع.
ماذا ستتعلم في «تخزين البادئات الطويلة مؤقتًا»؟
التحكم في التكاليف باستخدام التخزين المؤقت للتلقينات. تتمرن على AI Prompt Engineering مع أكواد عملية تشغلها مباشرة في المتصفح، ومدرس ذكاء اصطناعي متاح 24/7 يجيب على أسئلتك أثناء عملك.
هل أحتاج إلى خبرة سابقة لأبدأ AI Prompt Engineering؟
لا تُشترط خبرة سابقة. AI Prompt Engineering على CoddyKit منظم للمبتدئين حتى المتقدمين، لذا يمكنك البدء من هنا أو من البداية والتقدم بسرعتك الخاصة. هذا هو الدرس 4 من أصل 4.
كم من الوقت يستغرق درس «تخزين البادئات الطويلة مؤقتًا»؟
معظم دروس CoddyKit تستغرق حوالي 5–10 دقائق. كل منها موجز وتفاعلي، لذا تحرز تقدماً مستمراً وتستأنف من حيث توقفت عبر الويب والتطبيق.
هل يمكنني كتابة وتشغيل أكواد في درس AI Prompt Engineering هذا؟
نعم. كل درس في AI Prompt Engineering يتضمن محرر أكواد مدمج، لذا تكتب وتشغل أكواداً حقيقية مباشرة في متصفحك وتحصل على تعليقات فورية من الذكاء الاصطناعي — بدون إعداد محلي.
جميع الدروس في هذه الدورة
- نوافذ سياق بمليون رمز
- الضياع في المنتصف
- هيكلة التلقينات الضخمة
- تخزين البادئات الطويلة مؤقتًا