تضاعفت فاتورة الذكاء الاصطناعي الخاصة بك ثلاث مرات بين عشية وضحاها. لم يتغير النموذج، ولا حجم حركة المرور، ولا حتى نص الأوامر؛ كان المذنب سطراً واحداً من الكود تسبب في كسر خاصية الذاكرة المخبئية للأوامر (prompt cache) في OpenAI.

لماذا تهم الذاكرة المخبئية (Cache)

توفر لك الذاكرة المخبئية للأوامر لدى المزود المال من خلال تخطي إعادة معالجة أي طلب يبدأ ببادئة متطابقة تماماً (byte-for-byte) من حيث البايتات. إذا تطابقت الـ tokens الأولى مع استدعاء سابق، يعيد المزود استخدام التمثيل المحسوب مسبقاً لتلك الـ tokens ويحاسبك فقط على اللاحقة (suffix) الجديدة. القاعدة صارمة: يجب أن يكون التطابق تاماً، وليس مجرد تشابه. وجود token واحد مختلف في البداية يدمر عملية الإصابة بالذاكرة المخبئية (cache hit) بالكامل.

الخطأ الذي قضى على معدل الإصابة

في الوكيل (agent) الخاص بنا، وضعنا طابعاً زمنياً حالياً في أعلى الـ system prompt لمنح النموذج إحساساً بـ "الآن". وبما أن الطابع الزمني يتغير كل ثانية، كان تسلسل الـ tokens الأول فريداً لكل طلب. لم تجد الذاكرة المخبئية أي تطابق أبداً، لذا تحمل كل استدعاء السعر الكامل لـ 18,000 token ثابتة تلت ذلك — مثل مخططات الأدوات (tool schemas)، ومقتطفات التوثيق، وأمثلة few-shot، والتعليمات الثابتة. كانت النتيجة معدل إصابة (cache hit rate) بنسبة 0% وفاتورة تضخمت ثلاث مرات.

إعادة الترتيب لضمان قابلية التخزين المخبئي

الحل بسيط: احتفظ بكل ما لا يتغير أبداً في مقدمة الأمر، وادفع بأي بيانات متغيرة إلى الخلف.

البادئة الثابتة (قابلة للتخزين المخبئي)

  • تعريفات الأدوات (Tool definitions)
  • وثائق الاسترجاع (Retrieval documents)
  • أمثلة few-shot
  • تعليمات النظام الثابتة

اللاحقة المتغيرة (غير قابلة للتخزين المخبئي)

  • الوقت الحالي
  • معرفات الجلسة (Session identifiers)
  • رسائل المستخدم
  • السياق المباشر (Live context)

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

القتلة الخفيون في البنية التقنية

حتى عندما يبدو القالب صحيحاً، يمكن للبرمجيات الوسيطة (middleware) أو الـ SDKs أن تضيف بيانات وصفية (metadata) بصمت في المقدمة — مثل معرفات الطلبات (request IDs)، أو الطوابع الزمنية، أو رؤوس أخرى (headers) — قبل أن تصل الحمولة (payload) إلى الـ API. كما تقوم بعض خطوط أنابيب النشر (deployment pipelines) بإعادة ترتيب تعريفات الأدوات عند كل عملية نشر. هذه التغييرات غير المرئية تغير تسلسل البايتات وتخرب الذاكرة المخبئية دون أي تغيير في الكود الخاص بمُنشئ الأوامر لديك.

راقب معدل الإصابة في الذاكرة المخبئية

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

الخلاصة

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