التخزين المؤقت للسياق: كيف تُرتّب طلبك ليعمل

في أنظمة RAG والوكلاء، جزء كبير من كل طلب يتكرّر حرفيًّا: تعليمة النظام، وتعريفات الأدوات، وربما مستند مرجعي ثابت. التخزين المؤقت للسياق يجعلك تدفع ثمن معالجة هذا الجزء مرة، لا في كل طلب.

كيف يعمل — والشرط الحاكم

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

ومن هنا القاعدة الوحيدة التي تحتاج حفظها:

[ الثابت الطويل ]  ← تعليمة النظام · تعريفات الأدوات · مستند مرجعي
[ المتغيّر القصير ] ← المقاطع المسترجَعة · تاريخ المحادثة · سؤال المستخدم

الترتيب المعكوس — وهو الشائع — يبطل الفائدة كلها بلا أي رسالة خطأ.

الخطأ الذي يبطله بصمت

# ✗ يبطل التخزين المؤقت: الطابع الزمني يتغيّر في كل طلب
system = f"أنت مساعد دعم. الوقت الآن {datetime.now()}.\n{TOOLS}\n{POLICY}"

# ✓ الثابت أولًا، والمتغيّر بعده
system = f"{POLICY}\n{TOOLS}"
user = f"الوقت الآن {datetime.now()}\nالسؤال: {question}"

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

ماذا تكسب

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

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

متى لا يفيد

• الجزء الثابت قصير: مقدّمة من مئة رمز لا تستحق التعقيد.
• كل طلب مختلف كليًّا: مقاطع مسترجَعة تتغيّر مع كل سؤال ليست مرشّحًا للتخزين.
• حركة متفرّقة: للذاكرة مدّة صلاحية؛ طلب كل ساعة قد لا يصيب شيئًا.

ترتيب العلاج قبل التخزين المؤقت

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

كيف تتحقّق أن التخزين يعمل فعلًا

التخزين المؤقت يفشل بصمت: لا خطأ، ولا تحذير، فقط فاتورة لم تنخفض. تحقّق منه صراحةً:

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

وضَع هذين العدّادين في لوحتك بجوار الكمون والتكلفة. ما لا يُرصَد ينحدر دون أن يلاحظه أحد.

الأخطاء الشائعة

1. طابع زمني أو معرّف متغيّر في أول التعليمة.
2. إعادة ترتيب تعريفات الأدوات بين الطلبات (ترتيب مختلف = بادئة مختلفة).
3. تعديل تعليمة النظام يوميًّا لتجارب صغيرة، فتُبطَل الذاكرة باستمرار.
4. توقّع وفرٍ على رموز الإخراج — التخزين يخصّ الإدخال.
5. عدم مراقبة نسبة الإصابة، فيمرّ الكسر شهورًا.

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

هل يغيّر التخزين المؤقت جودة الإجابات؟

لا. يعيد استعمال حساب مطابق للمدخلات نفسها؛ المخرَج يبقى كما لو حُسب من جديد.

هل يعمل مع تاريخ المحادثة؟

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

كيف أتحقّق أنه يعمل فعلًا؟

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

المراجع

1. Kwon, W. et al. Efficient Memory Management for LLM Serving with PagedAttention. SOSP 2023. arXiv:2309.06180
2. Dao, T. et al. FlashAttention: Fast and Memory-Efficient Exact Attention. arXiv:2205.14135
3. Liu, N. et al. Lost in the Middle. arXiv:2307.03172