AKV من تسينغهوا: هل يغني حذف الكاش عن تلخيص سياق الوكيل؟

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

ما هو AKV؟

AKV نظام خدمة مفتوح المصدر بترخيص Apache-2.0، مبني فوق محرك SGLang، ويأتي من ورقة بحثية بعنوان «هندسة الكاش للوكلاء» (Cache Engineering for Agents). فكرته أن الوكيل لا يعدّل النص الذي يراه، بل يعدّل ما يمكن لآلية الانتباه (attention) أن تراه من ذاكرة الـKV.

الفرق بين المنهجين جوهري:

• هندسة السياق (التقليدية): تقصّ النص أو تلخّصه، فيتغيّر كل ما بعد نقطة التعديل، وتُعاد معالجته بالكامل (re-prefill).
• هندسة الكاش (AKV): يبقى النص كما هو، وتُحذف مدخلات محددة من الكاش، فيُعاد استخدام ما تبقّى دون إعادة حساب.

كيف يعمل من الداخل؟

يعرّف النظام ثلاث عمليات أساسية على الكاش:

1. Append: الإضافة المعتادة للرموز الجديدة.
2. Drop: إخراج مدخلات مختارة من انتباه الطلبات القادمة دون تغيير مواضع بقية المدخلات.
3. Repos: إعادة ترقيم مواضع المدخلات المتبقية لتبدأ من الصفر، عبر تدوير RoPE للمفاتيح فقط، دون المساس بالقيم، فلا حاجة لإعادة حساب الحالات المخفية.

ولأن الرموز المتطابقة قد تنتج حالات كاش مختلفة بحسب تاريخ العمليات، فإن مطابقة البادئة البسيطة قد تعيد استخدام حالة خاطئة. لذلك وسّع الفريق شجرة الـradix في SGLang بعقد خاصة بالحذف وإعادة التموضع.

قسمان في البنية

• akv.agent: جانب الخوارزمية، ويقرر ما الذي يُحذف ومتى تُعاد المواضع.
• akv.system: جانب التنفيذ، ويطبّق عمليات الكاش عبر واجهة Chat Completions المتوافقة مع OpenAI.

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

ماذا تقول الأرقام؟

وفي تجربة عند تزامن 16 طلباً، نزل زمن P95 من نحو 230 ثانية مع التلخيص المعتاد إلى نحو 31 ثانية مع AKV. هذه أرقام الباحثين على ثلاثة نماذج وأربعة اختبارات للوكلاء، فلا تعدّها وعداً لكل حالة استخدام.

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

متى يفيدك هذا فعلاً؟

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

قيود يجب معرفتها

• الدعم الحالي يقتصر على نماذج نصية من Qwen وGPT-OSS وMiniMax-M2.
• يحتاج استضافة ذاتية على SGLang، فلن يعمل مع واجهات برمجية مغلقة لا تتيح التحكم في الكاش.
• الحذف الخاطئ قد يُفقد الوكيل معلومة يحتاجها، لذا تُعدّ سياسة الاختيار أهم من الآلية نفسها.

وقد ظهر بالفعل مشروع مجتمعي باسم AKV-Sem يضيف وعياً دلالياً: يصنّف الوكيل كل مسار محذوف بأنه فاشل أو غير ذي صلة أو منتهٍ، ويحتفظ بملاحظة قصيرة عن السبب حتى لا يكرر الطريق المسدود.

أسئلة شائعة

هل AKV بديل عن التلخيص دائماً؟

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

هل يعمل مع النماذج المغلقة؟

ليس حالياً. النظام يعدّل الكاش داخل خادم الاستضافة، وهذا غير متاح عبر الواجهات البرمجية المغلقة.

هل تضمن الأرقام المنشورة النتيجة نفسها في مشروعي؟

لا. القياسات مأخوذة من اختبارات محددة وثلاثة نماذج. جرّب السياسات على مهامك قبل اعتمادها.

الخلاصة

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

المصادر: MarkTechPost، ملخص الورقة البحثية، daily.dev