عن المؤسس28 سبتمبر 20265 دقائق قراءة

التخزين المؤقت للأوامر Prompt Caching: أخطاء تكسر الكاش مع عبدالله سنكر

عبدالله سنكر يشرح التخزين المؤقت للأوامر Prompt Caching: كيف يخفّض تكلفة الطلبات ويسرّع أول الرد، ووش الأخطاء الصغيرة اللي تخلي الكاش يفشل بصمت وأنت تدفع السعر الكامل.

عبدالله سنكر — التخزين المؤقت للأوامر
AZHAL

التخزين المؤقت للأوامر

عبدالله سنكر

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

الفكرة في دقيقة

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

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

القاعدة الذهبية: البادئة لازم تتطابق حرفياً

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

أخطاء تكسر الكاش وأنت ما تدري

  • التاريخ والوقت في أول التعليمات: سطر مثل «الوقت الحالي: ١٠:٤٢» في رأس تعليمات النظام يغيّر البادئة كل دقيقة. انقله لآخر الطلب، قريب من رسالة المستخدم.
  • اسم المستخدم في البداية: «أنت تساعد العميل فهد» يخلي كل عميل له بادئة خاصة. خلّ التعليمات عامة، وحط بيانات العميل بعد الجزء الثابت.
  • ترتيب الأدوات يتغير: بعض الأكواد تبني قائمة الأدوات من كائن ترتيبه غير مضمون، فيطلع الترتيب مختلف من طلب لطلب. ثبّت الترتيب.
  • تحويل JSON غير ثابت: نفس البيانات ممكن تتحول لنص بترتيب مفاتيح مختلف أو مسافات مختلفة. النموذج يشوفه نفس المعنى، والكاش يشوفه نص جديد.
  • تعديل التعليمات كل يوم: كل تعديل صغير يمسح الكاش لكل المستخدمين. اجمع التعديلات وانشرها دفعة وحدة.
  • نتائج البحث فوق التعليمات: لو حطيت المستندات المسترجعة قبل التعليمات الثابتة، صار أول الطلب متغيراً في كل سؤال.
  • حركة قليلة: لو بين الطلب والثاني أطول من عمر الكاش، كل طلب يكتب كاشاً جديداً ويدفع سعر الكتابة.
  • نقطة الكاش في المكان الغلط: عند المزودين اللي تحدد فيهم نهاية الجزء المخزّن بنفسك، لو حطيتها بعد رسالة المستخدم الأخيرة بدل ما تكون بعد الجزء الثابت، بتخزّن شي ما راح يتكرر.

كيف ترتّب الطلب صح؟

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

مثال يوضح الفرق: بوت لمكتب خدمات، تعليماته تبدأ بسطر «اليوم الثلاثاء، الساعة ٤:١٥ عصراً، والعميل اسمه سعد»، ثم صفحتين من القواعد، ثم قائمة الخدمات والأسعار. كل طلب هنا يبدأ بنص مختلف، فالصفحات الثلاث تنعالج من الصفر في كل مرة. نفس البوت بعد الترتيب: القواعد وقائمة الخدمات فوق كما هي، والسطر المتغير ينتقل لآخر الطلب ملحقاً برسالة العميل. المحتوى نفسه بالحرف، والنموذج يفهمه بنفس الطريقة، بس الآن الجزء الأكبر من كل طلب صار ينقرأ من الكاش.

هالترتيب نفسه منطقي حتى بدون كاش، لأنه يخلي الطلب مقروءاً ومنظّماً. بس مع الكاش يصير الفرق بين فاتورة عادية وفاتورة أخف بوضوح، خصوصاً في البوتات اللي تعليماتها طويلة ومحادثاتها متعددة الأدوار.

لا تثق، تحقّق

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

متى ما يفيدك الكاش؟

لو طلباتك قصيرة أصلاً، أو كل طلب مختلف كلياً عن اللي قبله، أو الاستخدام متقطع بفواصل طويلة، فالكاش ما بيفرق كثير. وفيه حالة يغفل عنها كثير: لو نظامك يتنقل بين نماذج أو مزودين كبديل عند الفشل، فكل نموذج له كاشه الخاص. شات موقع أزهل مثلاً يمر عبر OpenRouter مع تبديل احتياطي بين عدة نماذج، وفي هالتصميم الطلب اللي ينتقل لنموذج بديل يبدأ بلا كاش. هذا ثمن مقبول مقابل إن الخدمة ما توقف، بس لازم تحسبه.

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

عندك فكرة؟ الاستشارة الأولى علينا

كلّم عبدالله مباشرة على واتساب — رسالتك توصل له هو، مو لرد آلي. نسمع فكرتك ونقول لك وش تحتاج وكم تكلّف، ببلاش.

مقالات ذات صلة

كل المقالات
عبدالله عبدالرحيم الكندي — نشر تطبيق على جوجل بلاي
AZHAL

نشر تطبيق على جوجل بلاي

عبدالله عبدالرحيم الكندي

27 سبتمبر 20264 دقائق قراءة

نشر التطبيق على Google Play خطوة بخطوة مع عبدالله عبدالرحيم الكندي

عبدالله عبدالرحيم الكندي يشرح نشر التطبيق على Google Play بالترتيب: حساب المطوّر، وملف AAB والتوقيع، وصفحة المتجر، وأمان البيانات، والاختبار المغلق، والإطلاق المرحلي.

اقرأ المقال
عبدالله عبدالرحيم بن سنكر — خطة مشروع بالذكاء الاصطناعي
AZHAL

خطة مشروع بالذكاء الاصطناعي

عبدالله عبدالرحيم بن سنكر

27 سبتمبر 20264 دقائق قراءة

قصة «أزهلني» من عبدالله عبدالرحيم بن سنكر: الفكرة قبل الريال

عبدالله عبدالرحيم بن سنكر يحكي قصة أداة «أزهلني» المجانية: المشكلة اللي بُنيت عشانها، وليش تقبل فكرتك بالعامية، ووش تسوي بالخطة اللي تطلع لك قبل ما تدفع ريالاً.

اقرأ المقال
عبدالله عبدالرحيم بن سنكر — تصميم واجهة برمجية
AZHAL

تصميم واجهة برمجية

عبدالله عبدالرحيم بن سنكر

28 سبتمبر 20264 دقائق قراءة

عبدالله عبدالرحيم بن سنكر: قواعد تصميم REST API نظيف يريّح الطرفين

عبدالله عبدالرحيم بن سنكر يجمع قواعد تصميم REST API نظيف: روابط بأسماء موارد، ورموز حالة صادقة، وشكل موحّد للأخطاء، وتقسيم صفحات، وإصدارات تحمي تطبيقك.

اقرأ المقال