تعمل خطوط معالجة "الأحلام" (dreaming pipeline) الخاصة بالمطور مرتين يوميًا، حيث تقوم بتكثيف سجل الأحداث الخام لوكيل LLM وتحويله إلى مخزن ذاكرة مدمج ومدقق، مما يقلل بشكل كبير من استهلاك الرموز (tokens). تكمن أهمية هذه الحيلة في أن معظم أنظمة الوكلاء تملأ ذاكرتها العاملة بكل تفصيل تراه، مما يؤدي سريعًا إلى حدوث تناقضات، وفقدان السياق، وتضخم تكاليف واجهة برمجة التطبيقات (API).
لماذا تهم الذاكرة وكلاء LLM
يعامل وكلاء LLM كل طلب مستخدم، أو استدعاء أداة، أو ملاحظة داخلية كـ "حدث" جديد. النهج الساذج يضيف كل حدث إلى المطالبة (prompt) التي تقود القرار التالي. ومن الناحية العملية، يؤدي ذلك إلى ملء المطالبة بالضجيج، وإجبار النموذج على إعادة تقييم حقائق قديمة، ودفع استخدام الرموز (tokens) إلى أعلى فئة تسعير. والنتيجة: المزيد من الأخطاء وفاتورة خفية تتزايد مع كل تفاعل.
كيف تعمل عملية "الأحلام" الليلية
يفصل النظام بين مسار الكتابة (سجل الوكيل المباشر) ومسار العمل (عملية اتخاذ القرار للنموذج). مرتين كل يوم، تقوم مهمة خلفية — تُسمى "الحلم" — بمعالجة الأحداث المتراكمة عبر ثلاث مراحل:
- التأمل (Reflect) – يقوم نموذج LLM بمسح مجموعات من الأحداث ذات الصلة، ويقترح حقائق موجزة، ويسجل أي الأحداث تدعم كل اقتراح.
- التقييم (Score) – يتحقق خط المعالجة مما إذا كانت الحقيقة مدعومة بأحداث كافية، وما إذا كانت تلك الأحداث متباعدة بما يكفي في الوقت لتكون موثوقة.
- التحكيم (Judge) – يتحقق اختباران لسلامة البيانات مما إذا كانت الحقيقة الجديدة لا تتعارض مع أي ذاكرة موجودة وما إذا كانت مكررة.
يتم ترقية الحقائق التي تجتاز جميع الفحوصات إلى ذاكرة دائمة. أما الحقائق التي لا تستوفي الشروط فتنتقل إلى قائمة مراجعة حيث يقوم المشغل البشري بضغطة زر واحدة للموافقة عليها أو رفضها. وتنشئ كل موافقة عملية إيداع (commit) بأسلوب git، مما يوفر سجل تدقيق كامل لما تغير في الذاكرة ومتى.
أهم الاستنتاجات الهندسية
- افصل بين الكتابة والعمل. اترك الوكلاء يفرغون كل ملاحظة في سجل؛ واترك عملية مخصصة تقرر ما الذي سيبقى.
- ركز على الرفض، لا التوليد. توليد الأفكار رخيص؛ أما منع تلوث الذاكرة فهو الجزء الصعب.
- البوابات البشرية عند أرخص نقطة تفتيش. المسودة الآلية المتبوعة بموافقة يدوية سريعة تتفوق على الاستقلالية الكاملة من حيث التكلفة والسلامة.
- ضع حدًا أقصى لاستهلاك الرموز (tokens) في كل دورة. وضع حد صارم للرموز في كل عملية "حلم" يمنع النفقات غير المنضبطة.
- التدقيق بحثًا عن الإخفاقات الصامتة. إذا طبقت مرحلة واحدة قواعد مختلفة عن المرحلة التالية، فقد تختفي البيانات دون ملاحظة؛ لذا فإن الفحوصات الصريحة تكتشف عدم التطابق.
العيوب المحتملة
يؤدي تشغيل عملية الدمج دون اتصال (offline) إلى حدوث تأخير: لن يرى الوكيل الحقائق المدققة حديثًا حتى دورة الحلم التالية. في التطبيقات سريعة الحركة التي تتطلب تعلمًا فوريًا، قد يكون هذا التأخير عائقًا. كما يعتمد النظام على مراجع بشري واحد؛ ويظل توسيع نطاق قائمة المراجعة دون تضخم تكاليف العمالة سؤالاً مفتوحًا.
ما يجب مراقبته لاحقًا
يجب على المطورين الذين يختبرون وكلاء LLM مراقبة فواتير الرموز (tokens) وسجلات الأخطاء بحثًا عن علامات "تلوث الذاكرة" – وهي التصريحات المتكررة أو المتناقضة التي تعود إلى تراكم الأحداث الخام. يوفر إضافة خط معالجة "الأحلام" أداة ملموسة لخفض تلك التكاليف مع الحصول على سجل ذاكرة قابل للتدقيق. ومع اعتماد المزيد من الفرق لنموذج السجل المنقسم، فمن المرجح أن تظهر أدوات تعمل على أتمتة خطوات (reflect-score-judge) وتتكامل مع المراجعة بأسلوب التحكم في الإصدارات، مما يجعل هذا النهج أقل تخصيصًا وأكثر سهولة في الاستخدام (plug-and-play). إن المقايضة بين الفورية والنظافة ستشكل مدى انتشار "الحلم الليلي" كجزء قياسي من بنية وكلاء LLM.