00:00:00رالف ويغم يحقق انتشاراً هائلاً. لقد صنعنا فيديو حول هذا الموضوع العام الماضي ومنذ
00:00:04ذلك الحين والجميع يتحدث عنه على تويتر. صنع مات بوكوك العديد من الفيديوهات
00:00:09عنه، وكتب رايان كارسون مقالاً رائجاً جداً حوله، وقام رازميك بالبناء عليه عبر
00:00:13سكربت “Ralphie Bash” الخاص به. ولكن هل يطبق الجميع هذا الأمر بشكل خاطئ؟ لقد صرح المبتكر بالفعل أن
00:00:19بعض التطبيقات غير صحيحة.
00:00:21إذاً، ما هي الطريقة الصحيحة للقيام بذلك؟ ولماذا يعتبر رالف حالياً أفضل وسيلة لبناء البرمجيات
00:00:26باستخدام الذكاء الاصطناعي؟ اضغط على زر الاشتراك ولندخل في التفاصيل.
00:00:30تم ابتكار “حلقة رالف” (Ralph loop) بواسطة جيف هانتلي وكتب عنها في شهر يونيو من العام الماضي.
00:00:35إنها في الأساس حلقة “bash” تعطي عميل الذكاء الاصطناعي نفس المطالبة بالضبط مراراً وتكراراً.
00:00:40لكنها عبقرية على مستويات عدة لأنها تتيح لعميل الذكاء الاصطناعي العمل في أذكى
00:00:46أطواره، وهو الطور الذي يكون فيه أقل قدر ممكن من السياق. ألقِ نظرة على هذا.
00:00:51لنتخيل أن هذه هي نافذة السياق الإجمالية للعميل. من 0 إلى حوالي 30%
00:00:57هو ما سنسميه “منطقة الذكاء”، وهي المنطقة التي يقدم فيها العميل أفضل أداء. ومن حوالي
00:01:0130 إلى 60%، لا يزال الأداء جيداً جداً. ومن 60% فصاعداً، أي 60، 70، 80، 90،
00:01:08هنا يبدأ الأداء في التدهور. سنسميها “منطقة الغباء”. طبعاً هذه الأرقام ليست ثابتة
00:01:12وقد تختلف من نموذج لآخر. فمنطقة الذكاء لنموذج معين قد تكون
00:01:1640 أو 50%، ولكن عادةً عندما تتجاوز نافذة السياق 80%، تبدأ حالة الغباء في الظهور.
00:01:21فبالنسبة لنموذج Claude Sonnet أو Opus، يبلغ عدد الرموز (tokens) النموذجية لنافذة السياق 200,000. لذا يمكننا
00:01:28القول إن أول 60 ألفاً هي منطقة الذكاء. والـ 60 ألفاً التالية لا تزال جيدة، لكنها ليست بجودة الـ 60 ألفاً
00:01:33الأولى. أما الـ 80 ألفاً الأخيرة، فلا يبدو أن الأداء فيها جيد. وهذه هي
00:01:38تجربتي الشخصية مع هذا النموذج، وربما تكون لديكم تجارب أخرى. والسبب في ذلك
00:01:43هو أن النموذج نفسه يعمل بنظام الانحدار التلقائي (autoregressive)، أي أنه يجب أن ينظر إلى
00:01:47الرموز السابقة للتنبؤ بالرمز التالي. وإذا كان لديك كم هائل من الرموز، فعليه
00:01:52فحص الكثير منها للعثور على الأجزاء المهمة ذات الصلة بالمهمة التالية المطلوبة.
00:01:56الآن لنركز على الـ 30% الأولى. حتى قبل أن تكتب أول مطالبة لك،
00:02:01هناك بعض الأشياء التي تُضاف إلى نافذة السياق تلقائياً. أولاً هي مطالبة النظام (system prompt)،
00:02:06ثم أدوات النظام. هذه تشغل في نموذج Claude التقليدي 8.3% و 1.4% من السياق.
00:02:12أي ما يقرب من 10% من هذه الـ 30. وإذا كانت لديك مهارات، فيمكن إضافتها. وأيضاً
00:02:16إذا كانت لديك أدوات MCP مخصصة. وأخيراً، إذا كان لديك ملف agent.md، فسيتم إضافته أيضاً.
00:02:21وبالطبع، كلما كبر حجم أي من هذه الأشياء، مثل ملف MD، زاد عدد الرموز
00:02:25التي سيستهلكها. وهذا كله يحدث حتى قبل أن تضيف مطالبتك الخاصة. لذا،
00:02:30بشكل عام، من الأفضل إبقاء هذا القسم صغيراً قدر الإمكان. لذا قلل من الأدوات والمهارات
00:02:35وما تضعه في ملف agent.md ليعمل النموذج في حالة السياق الأكثر
00:02:40مثالية. ولإعطائكم فكرة عن حجم 60 ألف رمز، إذا أحضرنا النص الكامل
00:02:44لفيلم Star Wars A New Hope، فسيكون حوالي 54,000 رمز في GPT-5. أي بهذا القدر تقريباً.
00:02:51قد تتساءلون الآن، ماذا عن الضغط (compaction)؟ هل يمكن أن يساعد في هذه العملية؟
00:02:56سنتحدث عن ذلك لاحقاً. أما الآن فلننتقل إلى كيفية مساعدة رالف
00:03:00في هذا الأمر. ميزة رالف هي أنك تركز على هدف واحد لكل نافذة سياق. أي
00:03:05أن نافذة السياق البالغة 200 ألف رمز بالكامل، يمكننا تخصيصها لهدف واحد أو مهمة واحدة. والطريقة
00:03:10التي نفعل بها ذلك هي كتابة مطالبة تقوم أولاً بفحص ملف plan.md. هذا الملف
00:03:15يحتوي على المهام المراد تنفيذها. مثل إنشاء الواجهة الأمامية، إنشاء الواجهة الخلفية، إعداد قاعدة البيانات
00:03:19وهكذا. هذا مثال عام جداً. بالطبع، ستكون أكثر تفصيلاً ودقة عند
00:03:23استخدام رالف، لكننا سنلتزم بهذا المثال حالياً. هذه المطالبة
00:03:28ستوجه العميل لاختيار المهمة الأهم، ثم إجراء التغييرات اللازمة. وبعد إجراء
00:03:33تلك التغييرات، يقوم بالتشغيل وحتى الرفع والاعتماد (push and commit) بالإضافة إلى إجراء اختبار. و
00:03:38بمجرد الانتهاء من ذلك، ونجاح الاختبارات، يتم وضع علامة “تم” على المهمة في
00:03:42ملف plan.md وتكرار العملية. وسيستمر العميل في البحث عن المهمة الأهم
00:03:46لتنفيذها حتى يكمل جميع المهام. في الواقع، اسمحوا لي أن أتراجع عن ذلك قليلاً
00:03:52لأنه يمكنك ترك حلقة رالف تعمل مراراً وتكراراً، حتى لو أكمل جميع
00:03:57المهام. وفائدة ذلك هي أنه قد يجد أشياء لإصلاحها أو ميزات
00:04:02لإضافتها لم تكن موجودة في ملف plan.md أصلاً. ولكن إذا بدأ يخرج عن المسار، فإن ميزة
00:04:08استخدام رالف هي أنه يمكنك إيقاف العملية بالكامل وقتما تشاء، وتعديل ملف المطالبة
00:04:12ثم تشغيل العملية برمتها مرة أخرى. ورالف يجعل هذا بسيطاً جداً لأن
00:04:16هذه العملية برمتها تُنفذ في حلقة “bash while” واحدة. حيث تقوم هنا فقط بعرض محتوى
00:04:22ملف prompt.md للعميل ثم تشغيل Claude في وضع الـ “YOLO”. طبعاً الرمز التعريفي (flag)
00:04:26ليس YOLO فعلياً، بل هو خيار “تخطي الأذونات بشكل خطير”، لكن للاختصار أسميته هكذا.
00:04:31وما يجعل رالف مميزاً هو أنه خارج سيطرة النموذج. فالنموذج
00:04:36لا يمكنه التحكم في وقت إيقاف رالف؛ سيستمر في العمل فحسب. وبهذه الطريقة يمكنك التأكد
00:04:41أنه عند تشغيل مهمة جديدة أو إطلاق مطالبة جديدة، يكون السياق عند تلك النقطة
00:04:46تماماً كما كان عند فتح العميل لأول مرة. فهو نظيف؛ لا يحتوي على أي ضغط للمعلومات
00:04:50ولا أي إضافات سابقة. لذا تحصل كل مهمة جديدة على أقصى قدر من السياق وتستخدم
00:04:55النموذج في أذكى وأفضل حالات نافذة السياق الخاصة به. والضغط ببساطة
00:05:01هو قيام العميل بالنظر في جميع الرموز التي كُتبت في نافذة السياق
00:05:05واختيار الأجزاء الأكثر أهمية للمطالبة التالية. فهو يختار ما
00:05:11يظن أنه الأكثر أهمية، لكنه لا يعرف ما هو المهم فعلياً. وبالتالي فإن الضغط
00:05:16قد يفقدنا معلومات بالغة الأهمية ويجعل مشروعك لا يعمل كما هو متوقع.
00:05:21على أي حال، بعد أن رأينا تطبيق حلقة رالف المعياري من المبتكر، فهذا يساعدنا
00:05:27في معرفة سبب اختلاف التطبيقات الأخرى. لنلقِ نظرة على تطبيق شركة Anthropic،
00:05:33الذي يستخدم أمراً مائلاً لتشغيل رالف داخل كود Claude، ولديه حد أقصى للتكرارات
00:05:38ووعد بالإكمال. المشكلة في هذا الملحق (plugin) الخاص بـ رالف ويغم هي
00:05:43أنه يضغط المعلومات عند الانتقال إلى المهمة التالية. فإذا أنهى
00:05:48مهمة وأعاد تشغيل المطالبة، فبدلاً من إعادة تعيين نافذة السياق بالكامل، فإنه يضغط ما
00:05:54تم فعله سابقاً، وبالتالي قد يفقد معلومات حيوية. هناك أيضاً مشكلة
00:05:59بسيطة في وجود حد أقصى للتكرارات ووعد بالإكمال، لأن التكرار المستمر
00:06:04لرالف يكون مفيداً أحياناً؛ فقد يكتشف أموراً مثيرة للإصلاح لم تكن لتخطر على بالك.
00:06:08وإذا قمت بمراقبته، أي كنت “بشراً يتابع الحلقة”، فقد ترى أنماطاً جيدة أو سيئة
00:06:14من نموذج معين يمكنك تعديلها وتحسينها في مطالبتك الأصلية. وإذا ألقينا
00:06:19نظرة على نهج رايان كارسون لحلقة رالف، نجد أنه ليس معيارياً
00:06:24تماماً لأنه في كل حلقة، هناك إمكانية لتعديل أو الإضافة إلى
00:06:29ملف agents.md. واعتماداً على مطالبة النظام أو أي مطالبات مستخدم
00:06:33أضفتها للنموذج، فمن خلال تجربتي، تكون النماذج افتراضياً كثيرة الكلام جداً. لذا إذا كنت
00:06:39في كل تكرار تضيف إلى ملف agents.md، الذي يُضاف بدوره إلى السياق في
00:06:44بداية كل مطالبة مستخدم، فإنك تزيد فقط من عدد الرموز في نافذة السياق،
00:06:48مما يدفع النموذج إلى منطقة قد يعطيك فيها نتائج غبية. لكن
00:06:53حقيقة أن الناس يصنعون سكربتاتهم الخاصة من سكربت حلقة رالف الأساسي هو
00:06:57دليل على مدى بساطته وسهولة فهمه. وبالرغم من وجود طريقة معيارية لعمل
00:07:03رالف، أعتقد أنه من الجيد للمطورين والفرق والشركات تعديله بما يناسب
00:07:08حالتهم الخاصة. فمثلاً، تعجبني حقيقة أنه في سكربت رالفي الخاص بـ رازميك، هناك طريقة
00:07:13لتشغيل حلقات رالف متوازية، وأيضاً حقيقة أنه يمكنك استخدام أداة متصفح العميل
00:07:18من الخلية لإجراء اختبارات المتصفح. وتعجبني أيضاً نسخة مات بوكوك من رالف،
00:07:23حيث يضيف المهام كقضايا (issues) على GitHub وحلقة رالف تختار المهمة الأهم
00:07:28وتعمل عليها وتحددها كـ “تم” عند الانتهاء قبل الانتقال للمهمة التالية، وهو ما
00:07:32أجده ذكياً جداً. أعتقد أن قوة وبساطة رالف تعني أنه
00:07:37سيبقى لفترة طويلة جداً. وربما ترون الكثير من التطويرات والتحسينات عليه.
00:07:42أنا حقاً معجب بالمسار الذي يسلكه جيفري في مشروعيه Loom و Weaver حيث
00:07:47يريد ابتكار وسيلة لصنع البرمجيات بشكل مستقل وبطريقة صحيحة. ولكن مع كل
00:07:52حلقات رالف هذه التي تنشئ برمجيات جديدة بشكل مستقل، ستحتاج إلى وسيلة للبحث عن الأخطاء
00:07:56والتأكد من إصلاحها. وهنا يأتي دور Better Stack؛ لأنه لا يكتفي فقط باستيعاب السجلات
00:08:01وتصفية الأخطاء منها، بل يمكنه أيضاً التعامل مع تتبع الأخطاء في الواجهة الأمامية.
00:08:06لذا مع خادم MCP هذا، يمكنك أن تطلب من العميل تحديد أخطاء معينة من الواجهة الأمامية
00:08:11أو الخلفية بدلاً من قراءة السجل بالكامل، مما يقلل بدوره من حجم
00:08:16نافذة السياق.
00:08:17لذا اذهبوا لتجربة Better Flux، وأخبروني برأيكم في التعليقات.