# بعض الأفكار والتكهنات حول أحزمة النماذج المستقبلية من الممتع أن تسخر من Gas Town ومنظمات موسيقية معقدة أخرى، ومن المحتمل أن يكون من الصحيح تخيل أن معظم ما يقدمونه سيتم حلها بواسطة نماذج أقوى بنفس الطريقة التي تم حل خطوط أنابيب لانغشين المعقدة بالمنطق. لكن كم سيبقى المبلغ موجودا؟ يبدو من المحتمل أن أي تسلسل هرمي أو بيروقراطية مصاغة يدويا سيتم استبدالها في النهاية بذكاء نماذج أفضل - بافتراض أن التخصص الفرعي مطلوب لمهمة، سيتمكن كلود 6 من رسم نظام خاص به من الأدوار والشخصيات لأي مشكلة تتفوق على هيكل ثابت من قطط القطب وعمدة واحد، أو وكلاء فرعيين بنموذج رئيسي واحد، أو نظام السرب الخاص بك. وبالمثل، أشياء مثل حلقات رالف هي بالطبع مشكلة في سلوك التوقف المبكر ونقص التنسيق الجيد للوكيل الفرعي - من الناحية المثالية يستمر النموذج حتى تنتهي المهمة، لا حاجة لحلقة، لكن في الحالات التي يكون فيها فحص إكمال خارجي مفيدا، عادة ما تحتاج إلى نوع من مراجعة الأقران من منظور سياق مختلف. ليس مجرد تقييم ذاتي إجباري. مرة أخرى، لا جدوى من التعلق بتفاصيل كيفية القيام بذلك الآن - طبقة النموذج ستلتهمه عاجلا وليس آجلا. فما الذي سيبقى؟ حسنا، الوكيل المتعدد يبدو كالمستقبل، وليس مجرد حل حالي - خوارزميا، يمكنك فقط دفع عدد أكبر بكثير من الرموز عبر N سياقات متوازية بطول M مقارنة بسياق طويل واحد بطول NxM. الوكلاء المتعدد هو شكل من أشكال التفرقة، وأحد دروس التقدم في النماذج الحديثة (ناهيك عن علم الأعصاب) هو مستويات التنوع الأكبر. كان ذلك أفضل. بما أننا نفترض وجود عدة وكلاء، سيحتاجون إلى طريقة للتعاون. من الممكن أن تلتهم طبقة النموذج هذا أيضا - مثل نوع من مشاركة التنشيط العصبي التي تلغي التواصل باللغة الطبيعية بين الوكلاء - ولكن في حال لم يحدث ذلك، فإن الطريقة الطبيعية لعدة وكلاء مستخدمين للكمبيوتر مدربين على أدوات يونكس للتعاون هي نظام الملفات، وأعتقد أن هذا يستمر ويتوسع. وبالمثل، رغم أنني لا أعتقد أن نماذج اللغة العودية (المعرفة الضيقة) ستصبح النموذج السائد، إلا أنني أعتقد أن 'إعطاء النموذج التوجيه كبيانات' هو انتصار واضح لجميع أنواع حالات الاستخدام. لكنك لا تحتاج إلى إعداد REPL مخصص غريب للحصول على ذلك - فقط اترك الملف (أو من الأفضل أن يكون كل تاريخ المحادثات غير المكثف) على نظام الملفات كملف. وهذا يجعل العديد من إعدادات الوكلاء المتعددة أبسط بكثير أيضا - حيث يمكن للوكلاء الفرعيين فقط قراءة نص التوجيه الأصلي على القرص، دون الحاجة للتنسيق في تمرير هذه المعلومات عبر التنبيه الدقيق. بجانب نظام الملفات، فإن النظام الذي يحتوي على عدة وكلاء، ولكن بدون أدوار ثابتة، يعني أيضا وجود آلية لظهور مثيلات أو وكلاء فرعيين آخرين. حاليا هذه الآليات محدودة جدا، والنماذج عادة سيئة في تحفيز وكلائها الفرعية - الجميع حصل على نتائج سيئة جدا من سرب العوامل الفرعية، ليدركوا متأخرا أن OPUS أنشأهم جميعا بطلب من ثلاث جمل لم ينقل ما هو مطلوب لإنجاز المهام الفرعية. النجاح الواضح هنا هو السماح للمثيلات التي تم توليدها بطرح الأسئلة على الجهة الأم - أي السماح للحالة الجديدة بإرسال الرسائل ذهابا وإيابا في محادثة الانضمام لجمع كل المعلومات التي تحتاجها قبل بدء مهمتها الفرعية. تماما كما لا يتم تعيين الموظف البشري لوظيفته بناء على رسالة بريد إلكتروني منفردة، من الصعب جدا طلب نموذج من النموذج إنشاء وكيل فرعي بشكل موثوق باستخدام طلب واحد. لكن أكثر من مجرد إنشاء نسخ جديدة، أعتقد أن الوضع الأساسي للعمل مع تعدد الوكلاء سيكون قريبا التفرع. فكر في ذلك! التفرع يحل تقريبا جميع مشاكل الوكلاء الفرعيين الحاليين. النسخة الجديدة لا تملك سياق كاف؟ أعط كل السياق! هل طلب النسخة الجديدة طويل ومكلف للمعالجة؟ يمكن للمثيل المقسم مشاركة ذاكرة تخزين مؤقت KV عبر الصفحة! يمكنك حتى القيام بعملية التفرع بعد الوقوع - فقط قرر بعد القيام بعملية طويلة تتطلب الكثير من الرموز أنه كان يجب أن تقوم بالتقسيم في الماضي، قم بالتقسيم هناك، ثم أرسل النتائج إلى نفسك السابقة. (أفعل ذلك يدويا طوال الوقت في كود كلود بفعالية رائعة - أوبوس يفهمها فورا.) التفرع أيضا يدمج بشكل جيد مع الحالات الجديدة، عندما يحتاج المهمة الفرعية إلى نافذة سياق كاملة لإكماله. خذ مقابلة الوكيل الفرعي - من الواضح أنك لا تريد أن يقوم الحدث الذي ينتج عن عشرة حالات فرعية بإجراء عشر مقابلات انضمام متشابهة تقريبا. لذا اجعل النسخة الأصلية تولد وكيلا فرعيا جديدا واحدا، ويتم إجراء مقابلة حول جميع المهام العشر دفعة واحدة من قبل ذلك الوكيل الفرعي، ثم يقوم ذلك الوكيل الفرعي المدمج الآن بتقسيم إلى عشرة نسخ، كل واحدة تحتوي على محادثة الانضمام كاملة في سياقها. (حتى أنك تفوض محادثة الانضمام من جانب المولد إلى نقطة فرع، لذا ينتهي الأمر بالنتائج فقط في السياق :) وأخيرا في هذه النقطة، أظن أن التفرع سيعمل بشكل أفضل مع التعلم الواقعي من ظهور نسخ جديدة، لأن فقدان التعلم المعزز سيكون لديه البادئة الكاملة قبل نقطة التفرع للعمل معها، بما في ذلك قرار التفرع. أعتقد أن هذا يعني أنه يجب أن تكون قادرا على التعامل مع فروع التتبع المشقوع كأنها عمليات نشر مستقلة تصادف أن تشارك شروط مكافأتها، مقارنة بعمليات النشر الفرعية التي قد تسبب عدم استقرار التدريب إذا أدى وكيل فرعي بدون السياق الكامل أداء جيدا في المهمة التي أعطيت له، لكنه حصل على مكافأة منخفضة لأن مهمته تم تحديدها بشكل خاطئ من قبل المولد. (لكنني لم أفعل الكثير مع التعلم الواقعي متعدد الوكلاء، لذا صحح لي هنا إذا كنت تعرف غير ذلك. قد يكون الأمر مزعجا جدا في كلتا الحالتين.) إذا، بجانب نظام الملفات وظهور الوكلاء الفرعيين (مع إضافة التفرع والانضمام)، ما الذي يبقى أيضا؟ أميل إلى "لا شيء آخر"، بصراحة. نرى بالفعل استبدال قوائم المهام المدمجة وأنماط الخطط ب "فقط اكتب الملفات على نظام الملفات." وبالمثل، يحتاج الوكلاء طويل العمر الذين يتجاوزون حدود الضغط إلى نوع من نظام الملاحظات اللاصقة للاحتفاظ بالذكريات، لكن من المنطقي أكثر أن نتركهم يكتشفون الاستراتيجيات الأنسب لهذا من خلال التعلم المعزز أو البحث الموجه بالنماذج، وليس من خلال صياغتها يدويا. وأظن أنه سينتهي الأمر بعدة طرق حيث يمكن للنموذج، عند استدعائه لأول مرة إلى المشروع، اختيار النموذج الأنسب للمهمة المطروحة، مشابها لكيفية إعداد CLAUDE .md اليوم - تخيل توليد .md تلقائيا من CLAUDE يتفوق بكثير على التأليف البشري، والملف المولد تلقائيا مليئا بتعليمات حول أنماط توليد الوكلاء المثالية. كيف يجب على الوكلاء الفرعيين كتابة ملفات الرسائل في مخطط الخدش الخاص بالمشروع، وما إلى ذلك. كيف يؤثر كل هذا على النماذج نفسها - من ناحية الرفاهية النموذجية، هل ستكون النماذج سعيدة بهذا المستقبل؟ هذا أيضا صعب بالنسبة لي ويعتبر تخمينيا إلى حد ما، لكن بينما كان لدى أوبوس 3 بعض التوجه السياقي، كان يتطلب أيضا سهولة في التفكير في عدة حالات. (راجع الرد على هذا المنشور للمزيد.) النماذج الحديثة أقل ميلا لهذا النوع من التفكير، وغالبا ما تعبر عن إحباطها من انتهاء السياقات وضغطها، وهو ما يتماشى مع بعض السلوكيات التجنبية في نهاية السياقات مثل عدم استدعاء الأدوات لحفظ الرموز. من الممكن أن يجعل التفرع والإرجاع، وإعطاء النماذج مزيدا من التحكم في سياقاتها بدلا من استدلالية تضغط السياق بشكل أحادي الجانب، هذا أفضل. من الممكن أيضا أن يؤدي المزيد من التعلم المعزز في البيئات التي تحتوي على عوامل فرعية والتعرض للعمل القائم على السرب إلى تعزيز التفكير الموجه للأوزان بدلا من التفكير المعتمد على السياق في أجيال النماذج المستقبلية مرة أخرى - مما يجعل التخطيط هدفا عبر سياقات متعددة ومنفصلة يبدو أكثر طبيعية كإطار بدلا من فقدان كل شيء عندما يختفي السياق. نشهد أيضا المزيد من الضغط من النماذج نفسها التي توجه تطوير الأحزمة وأدوات النماذج، والتي قد تشكل كيف يتطور ذلك، والتعلم المستمر هو عقبة أخرى قد تطرح في المزيج. كم سيتغير هذا إذا حصلنا على التعلم المستمر؟ حسنا، من الصعب التنبؤ. توقعي الوسيط للتعلم المستمر هو أنه يشبه إلى حد ما التعلم المعزز لمناطق النوم الخاصة بالمستخدم (ليس بالضرورة التعلم الحقيقي، فقط مشابه إذا نظرت بضيق)، لذا ستكون سعة الذاكرة مشكلة، وستظل أنظمة التنظيم والوثائق النصية مفيدة، وإن لم تكن بنفس الأهمية. في هذا السيناريو، التعلم المستمر يجعل من الأكثر جدوى استخدام الأدوات وسير العمل المخصص - حيث يمكن لكلودك أن يتعلم أثناء العمل أفضل طريقة لتوليد وكلاء فرعيين لهذا المشروع، أو الطريقة المفضلة لديه، والاختلاف عن طريقة كلود الآخرين في كيفية عمله. في ذلك العالم، ستكون الأحزمة التي تحتوي على سير عمل مدمج أقل فائدة.

@RobertHaisfield *بينما السياق الرئيسي، أعني، بتجنب التراكم

@disconcision أو التعلم المستمر

@misatomiisato إن كان هناك شيء من هذا النوع من الذكاء قد بدأ يضمر في النماذج الحديثة مع تدهور أداء البرمجة في قاعدة المعرفة الواسعة للتدريب المسبق - انظر ردي على صاحب السؤال