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

تخسر معظم الفرق التي تدفع مقابل الوصول إلى واجهات برمجة تطبيقات نماذج اللغة الكبيرة (LLM) ما بين 50 و90 بالمئة من التوفير المحتمل، رغم أن الآلية اللازمة لتحقيق ذلك موجودة في بيئات الإنتاج منذ أكثر من عام. يتيح التخزين المؤقت للـ prompt لمزوّد الـ API إعادة استخدام الحسابات التي أجراها بالفعل للأجزاء الثابتة من الطلب — تعليمات النظام، تعريفات الأدوات (tools)، المستندات المرجعية الطويلة — بدلاً من إعادة معالجتها في كل استدعاء.

المشكلة ليست أن التخزين المؤقت للـ prompt لا يعمل. المشكلة أن معظم فرق الهندسة تبني الـ prompts الخاصة بها بطريقة تُبطل هذه الميزة قبل أن تحظى بفرصة المساعدة، ثم تستنتج أن الميزة «لم تُحدث فرقاً» في حالتها.

كيف يعمل التخزين المؤقت فعلياً

عندما يعالج نموذج transformer الـ prompt، يحسب أزواج المفتاح-القيمة (KV) لكل توكن في المُدخل — وهي التمثيلات الداخلية التي يستخدمها النموذج للتنبؤ بالتوكن التالي. هذا الحساب هو الجزء الأكثر تكلفة في الاستدلال (inference)، ويتناسب حجمه مع طول المُدخل. يخزّن التخزين المؤقت للـ prompt أزواج KV هذه على خوادم المزوّد بعد أول طلب، مرتبطة بالضبط بنفس بادئة (prefix) التوكنات التي أنتجتها.

في الطلب التالي، إذا شارك الـ prompt الجديد نفس البادئة، يتخطى المزوّد إعادة حساب أزواج KV للجزء المشترك ويعالج فقط التوكنات الجديدة المضافة في النهاية. على سبيل المثال، يفرض تطبيق Anthropic نحو 10 بالمئة من سعر توكن الإدخال الأساسي مقابل قراءة الكاش، وحوالي 25 بالمئة أعلى من السعر الأساسي مقابل الكتابة الأولى فيه — وهي مقايضة تُجدي نفعاً بسرعة لأي بادئة تُستخدم أكثر من مرتين. يطبّق التخزين المؤقت التلقائي لـ OpenAI خصماً بنسبة 50 بالمئة على توكنات الإدخال المخزّنة مؤقتاً دون تكلفة كتابة منفصلة، ويعمل تخزين السياق المؤقت من Google في نماذج Gemini بطريقة مماثلة عبر كائن كاش صريح تُنشئه وتُشير إليه.

من أين يأتي التوفير الحقيقي

التوفير ليس نظرياً. وكيل دعم عملاء يتضمن prompt نظام بحجم 3000 توكن، ومقتطف قاعدة معرفة منتج بحجم 5000 توكن، ومجموعة تعريفات أدوات بحجم 2000 توكن في كل استدعاء، يدفع مقابل 10000 توكن من الإدخال قبل أن يدخل سؤال المستخدم الفعلي — ربما 50 توكن — حيّز الاهتمام أصلاً. عبر تطبيق عالي الحجم يعالج عشرات الآلاف من الطلبات يومياً، تفوق هذه الأعباء الإضافية التكلفة الهامشية للاستعلام نفسه بكثير.

مع التكوين الصحيح للتخزين المؤقت، تُحسب تلك البادئة المكوّنة من 10000 توكن مرة واحدة ثم تُقرأ من الكاش في كل استدعاء لاحق ضمن نافذة زمن انتهاء الصلاحية (TTL) الخاصة بالكاش (عادةً 5 دقائق في مستوى Anthropic القياسي، وقابلة للتمديد إلى ساعة عند بعض المزوّدين). الأثر العملي لخط أنابيب RAG بنافذة سياق مسترجَع كبيرة، أو لوكيل بمخطط استدعاء أدوات موسّع، هو خفض بنسبة 60 إلى 80 بالمئة في تكلفة الإدخال الفعلية — دون أي تغيير في جودة النموذج أو سلوك المخرجات أو أي زمن استجابة يلاحظه المستخدم. بل إن زمن الاستجابة يتحسن قليلاً، لأن توكنات الكاش تتخطى تماماً عملية المرور الأمامي (forward pass).

الخطأ الذي يقتل معدل إصابة الكاش

يعمل التخزين المؤقت للـ prompt فقط على التطابق التام للبادئة. إذا تغيّر توكن واحد في أي مكان قبل حدود الكاش، يفشل إدخال الكاش بأكمله (miss) ويعيد المزوّد الحساب من الصفر. وهنا تُخرّب معظم عمليات التنفيذ نفسها بصمت.

نمط الفشل الأكثر شيوعاً: وضع محتوى ديناميكي — طابع زمني، معرّف جلسة، أو قائمة مستندات مسترجَعة بترتيب عشوائي — قرب بداية الـ prompt، قبل تعليمات النظام الثابتة وتعريفات الأدوات. بذلك يحصل كل طلب على بادئة فريدة، ولا تحظى ذاكرة الكاش أبداً بفرصة تراكم الإصابات. الحل ميكانيكي لكن يتطلب انضباطاً: هيكِل كل prompt بحيث يأتي المحتوى الثابت أولاً (تعليمات النظام، أمثلة few-shot، مخططات الأدوات، المستندات المرجعية المستقرة) والمحتوى المتغيّر أخيراً (رسالة المستخدم الفعلية، التاريخ الحالي إن لزم، حالة الجلسة).

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

السياق المسترجَع هو الحالة الأصعب

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

القياس الصحيح

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

خلاصات عملية

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