إبقاء جولات الوكيل الطويلة داخل نافذة السياق

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

بعض المصطلحات أولاً

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

المشكلة الأولى: الوكلاء الفرعيون تضخموا حتى رفضهم النموذج

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

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

الحل: امسح نتائج الأدوات القديمة أولاً

تتسع الطلبات الآن للميزانية عبر ثلاث خطوات، ولا تُجرّب كل خطوة إلا إذا لم تكف السابقة:

1. امسح أقدم نتائج الأدوات. يُستبدل محتواها بملاحظة قصيرة: نُتيجة الأداة مُسحت للحفاظ على المحادثة ضمن سياق النموذج، ويستطيع الوكيل تشغيل الأداة مجدداً إذا احتاجها. ملف قُرئ قبل ساعة هو غالباً أكبر شيء في الطلب وأقله فائدة، والملف ما يزال موجوداً ليُقرأ من جديد. تبقى أحدث النتائج كاملة.
2. احتفظ بجولات المستخدم الكاملة. كما كان من قبل: الرسالة الأولى، وملاحظة، وأحدث الجولات الكاملة التي تتسع.
3. احتفظ بجولات الأدوات الكاملة. داخل جولة طويلة واحدة، وهي النوع الوحيد الذي يملكه الوكيل الفرعي، احتفظ بالرسالة الأولى، وملاحظة، وأحدث جولات «استدعِ أداة، واحصل على نتيجتها» الكاملة.

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

المسح على دفعات، حتى يبقى التخزين المؤقت فعّالاً

تستطيع مزوّدات النماذج إعادة استخدام العمل على بداية الطلب إذا كانت مطابقة لآخر طلب، وهذا ما يُسمى التخزين المؤقت للبادئة (prefix cache). إذا مسحنا نتيجة واحدة إضافية في كل استدعاء، تتغير بداية الطلب في كل مرة، ولن يفيد التخزين المؤقت أبداً.

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

الرفض صار يُعلَن

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

المشكلة الثانية: الوكيل توقف «ليوفّر المساحة»

طُلب من وكيل فرعي قراءة 40 فصلاً طويلاً، فتوقف بعد فصلين وقال إنه يريد توفير المساحة. كان قد استخدم نحو 100,000 رمز من ميزانية 400,000 رمز.

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

الإصلاح الذي لا يراه النموذج ليس إصلاحاً من وجهة نظره. تنفع الآلية فقط إذا وثق بها الوكيل.

المشكلة الثالثة: عدّ الرموز كما لو كان كل شيء بالإنجليزية

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

لذلك أرسل وكيل فرعي يقرأ فصولاً روسية طلباً بحجم نحو 640,000 رمز، بينما كان تقديرنا يقول إنه أقل من ميزانية 400,000. وكان بإمكان التقدير نفسه أن يدفع الطلب فوق الحد الأقصى الصلب للنموذج.

يعدّ التقدير الآن بحسب نوع الكتابة: الأحرف اللاتينية البسيطة بأربعة أحرف لكل رمز، والصينية واليابانية والكورية بحرف واحد، وكل ما عدا ذلك، أي السيريلية واليونانية والعربية والأحرف المنقوطة والرموز التعبيرية، بحرفين لكل رمز. والهدف أن يبالغ التقدير في الارتفاع. في فصل روسي واحد، يقدّر الآن 43,423 رمزاً مقابل نحو 44,600 مقاسة، وقبل ذلك كان يقدّر 25,023. وبما أن الرسالة لا تتغير بعد كتابتها، يُحسب تقديرها مرة واحدة ويُحفظ، بدلاً من حسابه في كل خطوة.

ما استخلصناه

• قلّص حيث يكمن الحجم فعلاً. في أعمال الوكيل، يكمن الحجم في نتائج الأدوات، لا في رسائل المستخدم.
• أخبر الوكيل بشبكات أمانه. وإلا سيخطط حول حدود لم تعد قائمة.
• «الأحرف ÷ 4» افتراض إنجليزي. أي شيء يعد الرموز لمستخدمين متعددي اللغات يجب أن يعد بحسب نوع الكتابة، أو أن يستخدم محلل رموز حقيقياً.
• انتبه للتخزين المؤقت. الطلب الذي يتغير في بدايته في كل استدعاء يكلّف أكثر ويعمل ببطء أكبر.

إذا كنت تبني ميزات ذكاء اصطناعي في تطبيقك الخاص، فإن أدلتنا عن ما هو LLM وكيف تستخدم واجهات LLM البرمجية تغطي نوافذ السياق والرموز منذ البداية. وللمزيد عن عمل الوكلاء الفرعيين في Mythex، راجع وثائق الوكلاء الفرعيين.