MapFlow من جامعة بكين يتيح للنماذج إعادة استخدام انتباه بعضها بعضًا

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

أين يضيع المال

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

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

ما الذي يقترحه MapFlow

قدّم فريق جامعة بكين MapFlow. وبحسب العنوان وبداية الوصف، تقوم الفكرة على عدم إعادة الحساب من الصفر، بل إعادة استخدام الانتباه بين النماذج. فبدل إعادة الحساب لدى النموذج المستقبِل، تُحوَّل النتائج الجاهزة من عمل النموذج السابق إلى فضائه.

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

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

لماذا يهم ذلك عمليًا

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

إذا نجحت الطريقة في الظروف الواقعية، ستستفيد ثلاث فئات:

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

القيود وما يمكن فعله الآن

الأسئلة الرئيسية الموجهة إلى أي طريقة كهذه معروفة سلفًا. كم من الجودة يُفقد عند الإسقاط بين بنى مختلفة؟ هل يلزم تدريب محوّل (adapter) لكل زوج من النماذج؟ هل النهج متوافق مع محركات الاستدلال الشائعة مثل vLLM وSGLang؟ وماذا يحدث للذاكرة إذا لزم الاحتفاظ بذاكرة نموذج مؤقتة أثناء عمل نموذج آخر؟ وما دامت الإجابات غائبة، فلا يُنقل ذلك إلى الإنتاج.

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

إلى أن تظهر التفاصيل ونتائج قابلة للتكرار، تعاملوا مع MapFlow بوصفه إشارة: السوق يصطدم بتكلفة إعادة القراءة، والباحثون بدأوا يبحثون عن حلول على مستوى الانتباه نفسه، لا على مستوى وكلاء الذاكرة المؤقتة والموجّهات (prompts) فقط.