هندسة السياق لوكلاء الذكاء الاصطناعي: دروس من بناء مانوس
السبت, يوليو 19
التقنية
2025/7/18 --يي تشاو 'بيك' جي
في بداية مشروع Manus، واجهت أنا وفريقي قرارًا مهمًا: هل يجب علينا تدريب نموذج عميل من البداية إلى النهاية باستخدام أسس مفتوحة المصدر، أم بناء عميل يعتمد على قدرات التعلم ضمن السياق للنماذج المتطورة؟
في العقد الأول من عملي في معالجة اللغة الطبيعية، لم يكن لدينا رفاهية ذلك الاختيار. في الأيام البعيدة لـBERT (نعم، مرت سبع سنوات)، كان لابد من ضبط النماذج وتقييمها قبل أن تتمكن من الانتقال إلى مهمة جديدة. غالباً ما استغرقت تلك العملية أسابيع لكل تكرار، رغم أن النماذج كانت صغيرة مقارنة بنماذج اللغة الكبيرة اليوم. بالنسبة للتطبيقات سريعة التطور، وخاصة قبل تحقيق ملاءمة المنتج للسوق، فإن حلقات التغذية الراجعة البطيئة هذه تعتبر عائقاً كبيراً. كان ذلك درساً مريراً من شركتي الناشئة الأخيرة، حيث قمت بتدريب نماذج من الصفر لـاستخراج المعلومات المفتوح والبحث الدلالي. ثم جاء GPT-3 وFlan-T5، وأصبحت نماذجي الداخلية غير ذات صلة بين عشية وضحاها. والمفارقة أن تلك النماذج نفسها مثلت بداية التعلم ضمن السياق - ومساراً جديداً كلياً إلى الأمام.
لقد جعل هذا الدرس المكتسب بصعوبة الخيار واضحًا: سيراهن مانوس على هندسة السياق. هذا يسمح لنا بتقديم تحسينات في غضون ساعات بدلاً من أسابيع، وأبقى منتجنا متعامدًا مع النماذج الأساسية: إذا كان تقدم النموذج هو المد المتصاعد، فنحن نريد أن يكون مانوس هو القارب، وليس العمود المثبت في قاع البحر.
ومع ذلك، اتضح أن هندسة السياق ليست بالأمر السهل على الإطلاق. إنها علم تجريبي - وقد أعدنا بناء إطار عملنا للوكيل أربع مرات، في كل مرة بعد اكتشاف طريقة أفضل لتشكيل السياق. نشير بمودة إلى هذه العملية اليدوية للبحث عن الهندسة المعمارية، والعبث بالموجهات، والتخمين التجريبي باسم "الانحدار العشوائي للدراسات العليا". قد لا تكون أنيقة، لكنها تعمل.
تشارك هذه المقالة الحلول المثلى المحلية التي وصلنا إليها من خلال "SGD" الخاص بنا. إذا كنت تبني وكيل الذكاء الاصطناعي الخاص بك، آمل أن تساعدك هذه المبادئ على التقارب بشكل أسرع.
التصميم حول ذاكرة التخزين المؤقت KV
إذا كان علي اختيار مقياس واحد فقط، فسأجادل بأن معدل إصابة ذاكرة التخزين المؤقت للمفاتيح والقيم (KV-cache hit rate) هو المقياس الأهم للوكيل الذكي في مرحلة الإنتاج. فهو يؤثر مباشرة على كل من زمن الاستجابة والتكلفة. لفهم السبب، دعنا ننظر إلى كيفية عمل وكيل نموذجي:
بعد تلقي مدخلات المستخدم، يمضي الوكيل عبر سلسلة من استخدامات الأدوات لإكمال المهمة. في كل تكرار، يختار النموذج إجراءً من مساحة إجراءات محددة مسبقًا بناءً على السياق الحالي. ثم يتم تنفيذ هذا الإجراء في البيئة (مثل صندوق الرمل للآلة الافتراضية من Manus) لإنتاج ملاحظة. يتم إلحاق الإجراء والملاحظة بالسياق، مما يشكل المدخلات للتكرار التالي. تستمر هذه الحلقة حتى اكتمال المهمة.
كما يمكنك أن تتخيل، ينمو السياق مع كل خطوة، بينما يظل الناتج—عادة استدعاء وظيفة منظم—قصيرًا نسبيًا. هذا يجعل النسبة بين التعبئة المسبقة وفك الترميز منحرفة بشدة في الوكلاء مقارنة بروبوتات الدردشة. في Manus، على سبيل المثال، متوسط نسبة الإدخال إلى الإخراج للرموز هو حوالي 100:1.
لحسن الحظ، يمكن للسياقات ذات البادئات المتطابقة الاستفادة من KV-cache، مما يقلل بشكل كبير من الوقت إلى الرمز الأول (TTFT) وتكلفة الاستدلال—سواء كنت تستخدم نموذجًا مستضافًا ذاتيًا أو تستدعي واجهة برمجة تطبيقات الاستدلال. ونحن لا نتحدث عن توفير صغير: مع Claude Sonnet، على سبيل المثال، تكلفة رموز الإدخال المخزنة مؤقتًا 0.30 دولار أمريكي/MTok، بينما تكلفة الرموز غير المخزنة مؤقتًا 3 دولار أمريكي/MTok—فرق 10 أضعاف.
1.حافظ على استقرار بادئة الموجه الخاصة بك. نظرًا للطبيعة الانحدارية الذاتية لنماذج اللغة الكبيرة، حتى اختلاف رمز واحد يمكن أن يبطل ذاكرة التخزين المؤقت من ذلك الرمز فصاعدًا. خطأ شائع هو تضمين طابع زمني—خاصة إذا كان دقيقًا إلى الثانية—في بداية موجه النظام. نعم، هذا يتيح للنموذج إخبارك بالوقت الحالي، لكنه أيضًا يقتل معدل إصابة ذاكرة التخزين المؤقت الخاصة بك.
2.اجعل سياقك قابلاً للإضافة فقط. تجنب تعديل الإجراءات أو الملاحظات السابقة. تأكد من أن التسلسل الخاص بك حتمي. العديد من لغات البرمجة والمكتبات لا تضمن ترتيبًا مستقرًا للمفاتيح عند تسلسل كائنات JSON، مما قد يؤدي إلى كسر ذاكرة التخزين المؤقت بصمت.
3.وضع علامات على نقاط انقطاع ذاكرة التخزين المؤقت بشكل صريح عند الحاجة. بعض مزودي النماذج أو أطر الاستدلال لا تدعم التخزين المؤقت التزايدي للبادئة تلقائيًا، وبدلاً من ذلك تتطلب إدخالًا يدويًا لنقاط انقطاع ذاكرة التخزين المؤقت في السياق. عند تعيين هذه النقاط، ضع في اعتبارك احتمالية انتهاء صلاحية ذاكرة التخزين المؤقت وعلى الأقل، تأكد من أن نقطة الانقطاع تتضمن نهاية رسالة النظام.
بالإضافة إلى ذلك، إذا كنت تستضيف النماذج ذاتيًا باستخدام أطر مثل vLLM، تأكد من تمكين التخزين المؤقت للبادئة/الإيعاز، وأنك تستخدم تقنيات مثل معرفات الجلسة لتوجيه الطلبات بشكل متسق عبر العمال الموزعين.
إخفاء، وليس إزالة
مع اكتساب وكيلك المزيد من القدرات، تزداد مساحة الإجراءات المتاحة له تعقيدًا بشكل طبيعي—بعبارة بسيطة، عدد الأدوات ينفجر. الشعبية الأخيرة لـ MCP تزيد الأمر اشتعالاً. إذا سمحت بأدوات قابلة للتكوين من قبل المستخدم، صدقني: سيقوم شخص ما حتماً بإدخال مئات الأدوات الغامضة في مساحة الإجراءات التي قمت بتنسيقها بعناية. نتيجة لذلك، يصبح النموذج أكثر عرضة لاختيار الإجراء الخاطئ أو اتخاذ مسار غير فعال. باختصار، وكيلك المدجج بالأسلحة يصبح أكثر غباءً.
رد فعل طبيعي هو تصميم مساحة إجراءات ديناميكية—ربما تحميل الأدوات عند الطلب باستخدام شيء يشبه RAG. لقد جربنا ذلك في Manus أيضاً. لكن تجاربنا تشير إلى قاعدة واضحة: ما لم يكن ضرورياً للغاية، تجنب إضافة أو إزالة الأدوات ديناميكياً في منتصف العملية. هناك سببان رئيسيان لهذا:
١. في معظم نماذج اللغة الكبيرة (LLMs)، تتواجد تعريفات الأدوات بالقرب من بداية السياق بعد التسلسل، عادةً قبل أو بعد موجه النظام. لذلك أي تغيير سيؤدي إلى إبطال ذاكرة التخزين المؤقت KV لجميع الإجراءات والملاحظات اللاحقة.
١. عندما تشير الإجراءات والملاحظات السابقة إلى أدوات لم تعد معرفة في السياق الحالي، يصاب النموذج بالارتباك. بدون فك التشفير المقيد، غالبًا ما يؤدي هذا إلى انتهاكات المخطط أو إجراءات وهمية.
لحل هذه المشكلة مع تحسين اختيار الإجراءات، يستخدم Manus آلة الحالة الواعية بالسياق لإدارة توفر الأدوات. بدلاً من إزالة الأدوات، فإنه يقوم بتقنيع احتمالات الرموز أثناء فك التشفير لمنع (أو فرض) اختيار إجراءات معينة بناءً على السياق الحالي.
•تلقائي – يمكن للنموذج اختيار استدعاء وظيفة أو عدم استدعائها. يتم تنفيذه عن طريق التعبئة المسبقة لبادئة الرد فقط: <|im_start|>assistant
•مطلوب – يجب على النموذج استدعاء وظيفة، لكن الاختيار غير مقيد. يتم تنفيذه عن طريق التعبئة المسبقة حتى رمز استدعاء الأداة: <|im_start|>assistant<tool_call>
•محدد – يجب على النموذج استدعاء وظيفة من مجموعة فرعية محددة. يتم تنفيذه عن طريق التعبئة المسبقة حتى بداية اسم الوظيفة: <|im_start|>assistant<tool_call>{"name": "browser_
باستخدام هذا، نقيد اختيار الإجراء من خلال حجب احتمالات الرموز مباشرة. على سبيل المثال، عندما يقدم المستخدم مدخلاً جديدًا، يجب على Manus الرد فورًا بدلاً من اتخاذ إجراء. لقد صممنا أيضًا عن قصد أسماء الإجراءات ببادئات متسقة - على سبيل المثال، تبدأ جميع الأدوات المتعلقة بالمتصفح بـ browser_، وأدوات سطر الأوامر بـ shell_. هذا يسمح لنا بفرض أن الوكيل يختار فقط من مجموعة معينة من الأدوات في حالة معينة دون استخدام معالجات احتمالات ذات حالة.
هذه التصميمات تساعد في ضمان أن حلقة وكيل Manus تظل مستقرة - حتى في ظل بنية مدفوعة بالنموذج.
استخدام نظام الملفات كسياق
توفر نماذج LLM الحدودية الحديثة الآن نوافذ سياق تصل إلى 128 ألف رمز أو أكثر. ولكن في سيناريوهات الوكلاء في العالم الحقيقي، غالبًا ما لا يكون ذلك كافيًا، وأحيانًا يكون مسؤولية. هناك ثلاث نقاط ألم شائعة:
1.يمكن أن تكون الملاحظات ضخمة، خاصة عندما تتفاعل العوامل مع بيانات غير منظمة مثل صفحات الويب أو ملفات PDF. من السهل تجاوز حد السياق.
2.يميل أداء النموذج إلى التدهور بعد طول سياق معين، حتى لو كانت النافذة تدعمه تقنيًا.
3.المدخلات الطويلة مكلفة، حتى مع التخزين المؤقت للبادئة. ما زلت تدفع لنقل وملء كل رمز مسبقًا.
للتعامل مع هذا، تنفذ العديد من أنظمة العوامل استراتيجيات اقتطاع أو ضغط السياق. لكن الضغط المفرط العدوانية يؤدي حتمًا إلى فقدان المعلومات. المشكلة أساسية: يجب على العامل، بطبيعته، التنبؤ بالإجراء التالي بناءً على جميع الحالات السابقة - ولا يمكنك التنبؤ بشكل موثوق بأي ملاحظة قد تصبح حاسمة بعد عشر خطوات. من وجهة نظر منطقية، أي ضغط لا رجعة فيه يحمل مخاطر.
هذا هو سبب تعاملنا مع نظام الملفات كسياق نهائي في Manus: غير محدود في الحجم، مستمر بطبيعته، وقابل للتشغيل مباشرة من قبل العميل نفسه. يتعلم النموذج الكتابة إلى الملفات والقراءة منها عند الطلب—باستخدام نظام الملفات ليس فقط كتخزين، ولكن كذاكرة خارجية منظمة.
استراتيجيات الضغط لدينا مصممة دائمًا لتكون قابلة للاستعادة. على سبيل المثال، يمكن إسقاط محتوى صفحة الويب من السياق طالما تم الاحتفاظ بعنوان URL، ويمكن حذف محتويات المستند إذا ظل مساره متاحًا في البيئة المحمية. هذا يسمح لـ Manus بتقليص طول السياق دون فقدان المعلومات بشكل دائم.
أثناء تطوير هذه الميزة، وجدت نفسي أتخيل ما الذي سيتطلبه لكي يعمل نموذج فضاء الحالة (SSM) بشكل فعال في بيئة عاملة. على عكس المحولات (Transformers)، تفتقر نماذج SSM إلى الانتباه الكامل وتواجه صعوبة مع التبعيات الخلفية طويلة المدى. ولكن إذا تمكنت من إتقان الذاكرة القائمة على الملفات—أي إخراج الحالة طويلة المدى بدلاً من الاحتفاظ بها في السياق—فإن سرعتها وكفاءتها قد تفتح فئة جديدة من العوامل. يمكن أن تكون نماذج SSM العاملة هي الخلفاء الحقيقيين لـ آلات تورينج العصبية.
التلاعب بالانتباه من خلال التكرار
إذا كنت قد عملت مع Manus، فربما لاحظت شيئًا فضوليًا: عند التعامل مع المهام المعقدة، يميل إلى إنشاء ملف todo.md—وتحديثه خطوة بخطوة مع تقدم المهمة، مع وضع علامة على العناصر المكتملة.
هذا ليس مجرد سلوك لطيف—إنه آلية متعمدة لـ التلاعب بالانتباه.
تتطلب المهمة النموذجية في Manus حوالي 50 استدعاء للأدوات في المتوسط. إنها حلقة طويلة - وبما أن Manus يعتمد على نماذج اللغة الكبيرة (LLMs) لاتخاذ القرارات، فهو معرض للانحراف عن الموضوع أو نسيان الأهداف السابقة، خاصة في السياقات الطويلة أو المهام المعقدة.
من خلال إعادة كتابة قائمة المهام باستمرار، يقوم Manus بتلاوة أهدافه في نهاية السياق. هذا يدفع الخطة العامة إلى نطاق انتباه النموذج الحديث، متجنبًا مشاكل "الضياع في المنتصف" وتقليل عدم التوافق مع الهدف. في الواقع، إنه يستخدم اللغة الطبيعية للتأثير على تركيزه نحو هدف المهمة - دون الحاجة إلى تغييرات هيكلية خاصة.
الاحتفاظ بالأشياء الخاطئة
العملاء يرتكبون أخطاء. هذا ليس خللاً - إنها الحقيقة. نماذج اللغة تهلوس، والبيئات تعيد أخطاء، والأدوات الخارجية تتصرف بشكل سيء، والحالات الاستثنائية غير المتوقعة تظهر طوال الوقت. في المهام متعددة الخطوات، الفشل ليس استثناءً؛ إنه جزء من الحلقة.
ومع ذلك، فإن الدافع الشائع هو إخفاء هذه الأخطاء: تنظيف الأثر، إعادة محاولة الإجراء، أو إعادة تعيين حالة النموذج وتركه للسحر "temperature". هذا يبدو أكثر أماناً وتحكماً. لكنه يأتي بتكلفة: محو الفشل يزيل الأدلة. وبدون أدلة، لا يمكن للنموذج التكيف.
لا تقع في فخ التعلم القليل
التحفيز بأمثلة قليلة هو تقنية شائعة لتحسين مخرجات نماذج اللغة الكبيرة. لكن في أنظمة العملاء، يمكن أن ترتد بطرق دقيقة.
نماذج اللغة هي محاكيات ممتازة؛ فهي تحاكي نمط السلوك في السياق. إذا كان السياق الخاص بك مليئًا بأزواج مماثلة من الإجراءات والملاحظات السابقة، فسيميل النموذج إلى اتباع ذلك النمط، حتى عندما لم يعد مثاليًا.
يمكن أن يكون هذا خطيرًا في المهام التي تنطوي على قرارات أو إجراءات متكررة. على سبيل المثال، عند استخدام Manus للمساعدة في مراجعة مجموعة من 20 سيرة ذاتية، غالبًا ما يقع العميل في إيقاع معين - يكرر إجراءات مماثلة ببساطة لأن هذا ما يراه في السياق. يؤدي هذا إلى الانحراف أو التعميم المفرط أو أحيانًا الهلوسة.
الحل هو زيادة التنوع. يقدم Manus كميات صغيرة من التنوع المنظم في الإجراءات والملاحظات - قوالب تسلسل مختلفة، صياغة بديلة، ضوضاء طفيفة في الترتيب أو التنسيق. تساعد هذه العشوائية المتحكم بها على كسر النمط وتعديل انتباه النموذج.
بعبارة أخرى، لا تقيد نفسك بأمثلة قليلة. كلما كان سياقك أكثر تجانسًا، كلما أصبح وكيلك أكثر هشاشة.
الخلاصة
هندسة السياق لا تزال علمًا ناشئًا - ولكنها بالفعل أساسية لأنظمة الوكلاء. قد تصبح النماذج أقوى وأسرع وأرخص، لكن لا يمكن لأي قدر من القدرات الخام أن يحل محل الحاجة إلى الذاكرة والبيئة والتغذية الراجعة. كيفية تشكيل السياق تحدد في النهاية كيف يتصرف وكيلك: مدى سرعة تشغيله، ومدى جودة تعافيه، ومدى قابليته للتوسع.
في مانوس، تعلمنا هذه الدروس من خلال عمليات إعادة الكتابة المتكررة، والطرق المسدودة، والاختبار في العالم الحقيقي عبر ملايين المستخدمين. لا شيء مما شاركناه هنا هو حقيقة عالمية - لكنها الأنماط التي نجحت معنا. إذا ساعدتك على تجنب تكرار مؤلم واحد على الأقل، فإن هذا المنشور قد أدى مهمته.
سيتم بناء المستقبل الوكيلي سياقًا تلو الآخر. قم بهندستها جيدًا.
أقل بنية، مزيد من الذكاء.