💬 NLP

Don't Break the Cache: An Evaluation of Prompt Caching for Long-Horizon Agentic Tasks

تقدم هذه الورقة تقييماً شاملاً لتخزين التلقين المؤقت (prompt caching) عبر ثلاثة من كبار مزودي النماذج اللغوية الكبيرة (LLM) للمهام الوكيلية طويلة الأمد، حيث تُظهر أن تقنيات التخزين الاستراتيجية — مثل استبعاد نتائج الأدوات الديناميكية وإدارة هيكل التلقين — يمكن أن تقلل تكاليف واجهة برمجة التطبيقات (API) بنسبة تتراوح بين 41 و80% وتحسن زمن الوصول لأول رمز (TTFT) بنسبة تتراوح بين 13 و31% مقارنة بالتخزين الساذج للسياق الكامل.

المؤلفون الأصليون: Elias Lumer, Faheem Nizar, Akshaya Jangiti, Kevin Frank, Anmol Gulati, Mandar Phadate, Vamse Kumar Subbiah

نُشر 2026-02-03

📖 3 دقيقة قراءة☕ قراءة في استراحة قهوة

CC BY 4.0

المؤلفون الأصليون: Elias Lumer, Faheem Nizar, Akshaya Jangiti, Kevin Frank, Anmol Gulati, Mandar Phadate, Vamse Kumar Subbiah

البحث الأصلي مرخَّص بموجب CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ هذا شرح مولَّده بالذكاء الاصطناعي للبحث أدناه. لم يكتبه المؤلفون ولم يصادقوا عليه. وللتحقق من الدقة التقنية، يرجى الرجوع إلى البحث الأصلي. اقرأ إخلاء المسؤولية الكامل

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

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

"تخزين المطالبة" (Prompt Caching) يشبه إعطاء ذلك المساعد قلم تحديد سحري (Highlighter). إذا لم يتغير دليل التعليمات، يمكن للمساعد تخطي إعادة قراءة 9/10 من الكتاب والقفز مباشرة إلى الجزء الجديد حيث توجد نتائج المكالمات الهاتفية. هذا يوفر الوقت والمال.

ومع ذلك، تطرح هذه الورقة سؤالاً صعباً: هل يعمل هذا القلم السحري دائماً، أم يمكننا إفساد الأمر؟

اختبر الباحثون هذا مع ثلاث شركات "مساعدين" كبرى (OpenAI وAnthropic وGoogle) باستخدام معيار يسمى DeepResearch Bench، حيث تقوم الوكلاء (agents) بعمليات بحث طويلة ومتعددة الخطوات على الويب للإجابة على أسئلة صعبة. وقد جربوا ثلاث طرق مختلفة لاستخدام القلم السحري:

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

ما وجدوه

1. إنه يوفر الكثير من المال (فوز "المحفظة")
بغض النظر عن الطريقة التي استخدموها، وفر القلم السحري مبلغاً هائلاً من المال. اعتماداً على الشركة، وفروا ما بين 41% و80% من الفاتورة.

التشبيه: الأمر يشبه إدراكك أنك لست بحاجة لشراء بطاقة مكتبة جديدة في كل مرة تدخل فيها إلى المكتبة؛ بل تستخدم البطاقة التي تملكها بالفعل.

2. السرعة مسألة شائكة (مشكلة "المرور")
بينما كان توفير المال سهلاً، كان توفير الوقت أصعب.

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

3. قاعدة "لا تكسر التخزين"
الدرس الأكبر يتعلق بـ أين تضع الخط الفاصل.

إذا وضعت معلومات ديناميكية متغيرة (مثل "الوقت الحالي: 2:0اً مساءً" أو "معرف المستخدم: 123") داخل دليل التعليمات، فإن القلم السحري ينكسر. سيعتقد النظام أن الدليل قد تغير، لذا سيتوقف عن التحديد ويبدأ القراءة من البداية.
الحل: حافظ على دليل التعليمات نقياً وثابتاً. إذا كان لزاماً عليك تضمين معلومات متغيرة، ضعها في نهاية الدليل تماماً، مثل ملاحظة لاصقة على الصفحة الأخيرة. بهذه الطتا، يظل 99% من الدليل محدداً وقابلاً لإعادة الاستخدام.

الخلاصة

بالنسبة للشركات التي تبني وكلاء ذكاء اصطناعي (AI agents) للقيام بمهام طويلة ومعقدة:

نعم، استخدموا تخزين المطالبة (Prompt Caching). سيقلل ذلك تكاليفكم بشكل كبير.
لكن، كونوا أذكياء. لا تفعلوه لكل شيء فحسب.
الاستراتيجية الأفضل: قم بتخزين "دليل التعليمات" المستقر فقط (System Prompt). اترك الأجزاء المتغيرة (نتائج الأدوات) تتدفق بحرية دون تخزينها. هذا يمنحكم أفضل مزيج من التكلفة المنخفضة والسرعة العالية.

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

ملخص تقني: لا تكسر التخزين المؤقت: تقييم تخزين المطالبات (Prompt Caching) للمهام الوكيلية طويلة الأمد

بيان المشكلة

أدت التطورات الأخيرة في وكلاء النماذج اللغوية الكبيرة (LLM agents) إلى تمكين مهام وكيلية معقدة متعددة الدورات تتضمن استدعاءً مكثفًا للأدوات، مثل البحث العميق والبرمجة الذاتية. غالبًا ما تمتد سير العمل هذه عبر عشرات استدعاءات واجهة برمجة التطبيقات (API)، مع تراكم نوافذ سياقية تصل إلى عشرات الآلاف من الرموز (tokens)، مما يؤدي إلى تكاليف تشغيلية كبيرة وأعباء زمنية إضافية (latency). وبينما توفر الشركات المزودة للنماذج اللغوية الكبيرة الكبرى (OpenAI، Anthropic، Google) ميزات تخزين المطالبات لاستعادة مصفوفات التوتر (KV tensors) التي تم حسابها مسبقًا وإعادة استخدامها لتقليل الحوسبة الزائدة، إلا أن الفوائد المحددة لهذه الميزات لمهام الوكلاء لا تزال غير مستكشفة بشكل كافٍ. تركز الأدبيات الحالية على إدارة الذاكرة على مستوى الاستدلال أو التدقيق الأمني، لكنها تفتقر إلى التحليل الكمي لوفورات التكلفة أو التقييمات المقارنة لاستراتيجيات التخزين المؤقت لجلسات الوكلاء الديناميكية متعددة الدورات.

المنهجية

أجرى المؤلفون تقييمًا شاملاً لتخزين المطالبات عبر ثلاثة مزودين رئيسيين لنماذج اللغة الكبيرة: OpenAI وAnthropic وGoogle. واستخدمت الدراسة أربعة نماذج رائدة: GPT-5.2 وGPT-4o (من OpenAI)، وClaude Sonnet 4.5 (من Anthropic)، وGemini 2.5 Pro (من Google).

الإعداد التجريبي:

المعيار المرجعي: استخدم التقييم معيار DeepResearch Bench، وهو معيار وكيل مخصص لمهام متعددة الدورات حيث ينفذ الوكلاء استدعاءات أدوات بحث ويب واقعية للإجابة على أسئلة بحثية معقدة بمستوى الدكتوراه.
النطاق: شملت الدراسة أكثر من 500 جلسة وكيل بمتطلبات نظام (system prompts) تبلغ 10,000 رمز. تم اختبار كل نموذج مع 40 جلسة مستقلة لكل حالة تخزين مؤقت.
استراتيجيات التخزين المؤقت: قام المؤلفون بتنفيذ ومقارنة أربع حالات متميزة للتحكم بدقة في حدود التخزين المؤقت باستخدام معرفات فريدة (UUIDs):
1. بدون تخزين مؤقت (الأساس): يتم إلحاق UUID في بداية مطالب النظام لفرض إعادة حساب جميع الرموز، مما يحاكي سيناريو يحتوي على محتوى ديناميكي (مثل الطوابع الزمنية) يكسر التخزين المؤقت.
2. تخزين السياق الكامل: لا يتم إضافة أي UUIDs، مما يسم يسمح لآلية التخزين المؤقت التلقائية للمزود بالعمل على تاريخ المحادثة بأكمله، بما في ذلك نتائج الأدوات الديناميكية.
3. تخزين مطالب النظام فقط: يتم إلحاق UUID في نهاية مطالب النظام، مما يضمن تخزين التعليمات النظامية الثابتة فقط، بينما يتم إعادة حساب تاريخ المحادثة الديناميكي ونتائج الأدوات.
4. استثناء نتائج الأدوات من التخزين: يتم إلحاق UUIDs بعد مطالب النظام وبعد كل نتيجة أداة، مما يمنع صراحةً دخول مخرجات الأدوات الديناميكية في التخزين المؤقت.

المقاييس:
قامت الدراسة بقياس تكلفة واجهة برمجة التطبيقات (API cost) (مع التمييز بين الرموز القياسية، ورموز القراءة المخزنة مؤقتًا، ورموز كتابة التخزين المؤقت) والوقت حتى أول رمز (TTFT) كمقياس أساسي لزمن الاستجابة (latency). تم تحديد الدلالة الإحصائية باستخدام اختبارات t للعينات المستقلة ( $\alpha = 0.05$ ).

المساهمات الرئيسية

التقييم الكمي الأول: يوفر هذا العمل أول كميّة شاملة لفوائد تخزين المطالبات خصيصًا للمهام الوكيلية طويلة الأمد عبر عدة مزودين ونماذج.
مقارنة الاستراتيجيات: يقارن بين التخزين المؤقت الساذج للسياق الكامل وطرق التحكم الاستراتيجي في الحدود (مطالب النظام فقط، استثناء نتائج الأدوات)، موضحًا أن النهج "الساذج" يمكن أن يكون غير منتج.
التباين بين المزودين: تحدد الدراسة اختلافات جوهرية في كيفية تنفيذ المزودين للتخزين المؤقت، لا سيما في كيفية تعاملهم مع المحتوى الديناميكي وتأثير ذلك الناتج على زمن الاستجابة مقابل التكلفة.
رؤى الدراسة الاستقصائية (Ablation Insights): من خلال دراسات الاستقصاء عبر أحجام المطالبات (500–50,000 رمز) وعدد استدعاءات الأدوات (3–50)، أظهر المؤلفون فوائد خطية عالمية في التكلفة وTTFT بعد استيفاء الحد الأدنى من الرموز الخاص بكل مزود.

النتائج

أسفر التقييم عن ثلاث نتائج رئيسية:

تخفيضات كبيرة في التكاليف: قلل تخزين المطالبات التكاليف باستمرار بنسبة تتراوح بين 41% إلى 80% عبر جميع المزودين والنماذج. وكان المحرك الرئيسي لهذه المدخرات هو تخزين مطالب النظام الكبير والمستقر.
تحسينات متغيرة في زمن الاستجابة: تراوحت تحسينات TTFT بين 13% إلى 31% اعتمادًا على المزود والاستراتيجية. ومع ذلك، لم تكن مكاسب زمن الاستجابة موحدة؛ فبالنسبة لبعض النماذج (مثل GPT-4o)، أدى تخزين السياق الكامل إلى تراجع في زمن الاستجابة بنسبة 8.8%.
التحكم الاستراتيجي في الحدود أمر بالغ الأهمية: وجدت الدراسة أن التحكم في كتل تخزين المطالبات الاستراتيجي يتفوق على تخزين السياق الكامل الساذج.
- وفرت استراتيجيات "مطالب النظام فقط" و**"استثناء نتائج الأدوات"** الفوائد الأكثر اتساقًا.
- غالبًا ما تسبب تخزين السياق الكامل عبئًا إضافيًا عبر تخزين استدعاءات الأدوات ونتائجها الديناميكية التي لن تُعاد في الجلسات اللاحقة، مما أدى للمفارقة إلى زيادة زمن الاستجابة.
- بالنسبة لـ GPT-4o، فإن أفضل استراتيجية (مطالب النظام فقط) حسنت TTFT بنسبة 30.9%، بينما أدى تخزين السياق الكامل إلى تدهور الأداء.

الأهمية والادعاءات

يزعم البحث تقديم توجيه دقيق لتنفيذ تخزين المطالبات في الأنظمة الوكيلية الإنتاجية. ويؤكد المؤلفون أنه بينما يقوم المزودون بتجريد الكثير من آليات التخزين المؤقت، يجب على الممارسين ممارسة التحكم الاستراتيجي في حدود التخزين المؤقت.

الحجة الجوهرية هي أنه في مهام الوكلاء، حيث يكون السياق ديناميكيًا وخاصًا بكل جلسة، فإن تخزين السياق بأكمله (النهج الساذج) يمكن أن يكون ضارًا. بدلًا من ذلك، يجب على الممارسين ضمان تخزين المحتوى المستقر والقابل لإعادة الاستخدام فقط (مثل مطالب النظام)، مع استبعاد العناصر الديناميكية (نتائج الأدوات، تاريخ المحادثة) عبر حدود صريحة (مثل UUIDs). هذا النهج يعظم كفاءة التكلفة وتحسينات زمن الاستجية، ويتجنب العبء الناتج عن تخزين المحتوى الذي لن يُعاد استخدامه. يعمل هذا العمل كدليل عملي لتحسين الأنظمة الوكيلية ذات المستوى المؤسسي، مؤكدًا أن "أفضل" استراتيجية تخزين مؤقت تعتمد على المزود وتعتمد على هدف التحسين (التكلفة مقابل زمن الاستجابة).