ADLC: دورة حياة Claude Code الجديدة للبرمجة بالذكاء الاصطناعي
AAI LABS
Computing/SoftwareManagementInternet Technology
Transcript
00:00:00ربما سمعت هذا مرارًا وتكرارًا بأن تطوير البرمجيات قد تغير،
00:00:03لكن مجرد اعتماد الأدوات الجديدة لم يلامس سوى القشرة الخارجية،
00:00:06لأن الأنظمة التي تُبنى اليوم لا تتصرف بالطريقة التي كانت تعمل بها البرمجيات القديمة.
00:00:10لذلك، كان على أطر العمل التي تبني عليها الشركات أن تتغير أيضًا،
00:00:14لأنك إذا واصلت البناء على العملية القديمة، ستواجه مشكلات لا تملك أي وسيلة لحلها.
00:00:18لذا، ومن أجل تلبية هذا المشهد المتغير،
00:00:21ظهر إطار عمل جديد في مجتمع المطورين تم بناؤه مع وضع الوكلاء الذكيين (Agents) في الاعتبار.
00:00:25وبنهاية هذا الفيديو، سنأخذك في جولة للتعرف على إطار دورة الحياة الجديد هذا
00:00:29ولماذا تحتاج إلى اعتماده.
00:00:31لأعوام عديدة، كان تطوير البرمجيات يتم باستخدام إطار SDLC.
00:00:35دورة حياة تطوير البرمجيات هي عملية هيكلية استُخدمت عبر عقود،
00:00:39وتحتوي على خطوات متعددة مثل التصميم، والتطوير، والاختبار، والنشر، والصيانة، والدعم المستمر.
00:00:45الفكرة الكاملة وراءها هي أنه ينبغي تطوير البرمجيات مع مراعاة أهداف العمل ومتطلبات المستخدم،
00:00:51حيث تصبح مخرجات كل مرحلة هي مدخلات المرحلة التالية.
00:00:54لكن هذا لم يستمر في العمل إلا حتى دخل الذكاء الاصطناعي إلى مجال التكنولوجيا.
00:00:57منذ أن بدأ الذكاء الاصطناعي في اكتساب الزخم، كان أول ما بدأ في استبداله هو كتابة الكود.
00:01:02قبل الذكاء الاصطناعي، كان التطوير عبارة عن نظام لكتابة الكود لمرات لا تحصى،
00:01:06وغالباً ما كانت عملية تكرارية لدمج مقتطفات برمجية ومنطق من أماكن أخرى لبناء نظام يحل المشكلة.
00:01:12لذا مع بدء تحسن النماذج، وهيمنة أدوات مثل Claude Code و Cursor على الصناعة،
00:01:18فشل إطار SDLC بمفرده.
00:01:20لم يعد قادراً على الاستمرار بمفرده، ويحتاج إلى التغيير من أجل تقديم قيمة حقيقية.
00:01:24وهذا هو السبب في تطوير دورة حياة التطوير القائم على الوكلاء، أو ADLC.
00:01:28إنها تسد الفجوة بين SDLC والمشهد التكنولوجي الحالي.
00:01:32وكانت هناك حاجة إلى ADLC لأنه في الأنظمة التي استُخدم فيها SDLC،
00:01:36كنت تعرف بالفعل سلوك النظام وقت التخطيط، وكانت هناك طرق للتحقق منه.
00:01:41لتبسيط الأمر، يتعامل SDLC مع البرمجيات كقطعة ثابتة، بينما يتعامل ADLC معها كنظام حي.
00:01:47الآن، بما أن وكلاء الذكاء الاصطناعي لا يمكن التنبؤ بسلوكهم، ولأنهم هم من يتطورون بالفعل من خلال التفكير والتكيف
00:01:53مع البيئة المحيطة بهم، يصبح من الصعب تقييمهم بناءً على نفس المقاييس التي تستخدمها البرمجيات التقليدية.
00:01:59السبب الرئيس وراء تطوير ADLC في المقام الأول هو الطبيعة غير الحتمية (Non-determinism) لوكيل الذكاء الاصطناعي في بيئة التشغيل.
00:02:05مع وكلاء الذكاء الاصطناعي، هناك تعلم مستمر وتطوير متواصل،
00:02:09ولا يمكنك تحديد الشكل الذي ستكون عليه مخرجات الوكيل مسبقاً.
00:02:12عندما تعمل مع الذكاء الاصطناعي، تعتمد القرارات التي تتخذها على التوجيه (Prompt)، والسياق، والنماذج،
00:02:16وجميع الأدوات الخارجية التي قمت بربطها.
00:02:18النماذج في حد ذاتها لا تزال غير قابلة للتنبؤ، لذا لا يمكننا تحديد ما سيعيده التوجيه بدقة 100%.
00:02:25وبناءً على ذلك، يصبح لديك أساساً مقاييس نجاح مختلفة عما يستخدمه إطار SDLC.
00:02:29هناك 7 مراحل في إطار ADLC، وتتوافق كل مرحلة مع مرحلة SDLC المقابلة لها بطريقة أو بأخرى.
00:02:36سواء كنت تعمل على نظام قائم على الوكلاء أم لا، فإن الخطوة الأولى تظل دائماً هي التخطيط.
00:02:41ما يتغير هو كيفية القيام بذلك.
00:02:43بالنسبة للوكلاء، لا يمكنك التخطيط بالطريقة التي تتبعها في الأنظمة غير القائمة على الوكلاء،
00:02:46لأنه على عكس الأنظمة التقليدية، لا ينطبق تدفق المنطق البرمجي بنفس الطريقة.
00:02:51لذا تهدف المرحلة الأولى من ADLC، وهي الإعداد والفرضية،
00:02:54إلى بناء فهم راسخ للمشكلة قبل الالتزام بأي تصميم للنظام أو نموذج محدد.
00:02:59عندما يتعلق الأمر بالوكلاء، فأنت بحاجة إلى فهم كيفية تفاعل المستخدمين مع النظام
00:03:04والتنسيق مع جميع أصحاب المصلحة لتحديد المواضع التي يتوقف فيها سير العمل
00:03:07ومعرفة طبيعة المجهود اليدوي المتكرر، لأن هذا هو ما سيقوم الوكيل بحله فعلياً.
00:03:12بعد ذلك، تقوم بمراجعة سير العمل والسياسات الحالية لمعرفة كيفية التعامل مع الأمور حالياً،
00:03:16وبمجرد أن يتضح ذلك، تضع فرضيات قابلة للاختبار حول المواضع التي سيساعد فيها الوكلاء أو يؤتمتون سير العمل.
00:03:22إذا تخطينا هذه المرحلة تماماً، فقد ينتهي بنا الأمر بأتمتة العمل الخاطئ،
00:03:26وبدلاً من إصلاح المشكلة، يمكن أن يجعل ذلك الأمور أكثر سوءاً.
00:03:28الاختلاف هنا مقارنة بإطار SDLC يكمن في السلوك.
00:03:31في SDLC، كان السلوك متوقعاً لأن نفس المدخلات كانت تعطي دائماً نفس المخرجات.
00:03:37لكن إطار ADLC احتمالي (Probabilistic) بسبب إشراك النموذج،
00:03:40وقد لا تؤدي نفس المدخلات أبداً إلى نفس المخرجات بالضبط.
00:03:43مع هذه المعرفة، الخطوة الأولى التي يتعين عليك فعلها هي تفعيل وضع التخطيط
00:03:47وجعل أي وكيل تستخدمه يخطط لسلوك الوكيل الذي تطوره، وليس طريقة التنفيذ البرمجي.
00:03:52وجهه بألا يفكر في الكود، وبدلاً من ذلك يحدد سير العمل بأكمله،
00:03:56وكيفية تفاعل الوكلاء مع المستخدمين، وما الذي يمكن أن يسير بشكل خاطئ، وما الأعباء الإضافية المحتملة،
00:04:00وجميع الافتراضات الأخرى حول النظام.
00:04:03بهذه الطريقة، تبدأ عملية بناء الوكيل بالافتراضات الأساسية،
00:04:06والتي تصبح دليلاً أفضل من القفز مباشرة إلى التخطيط البنيوي للهندسة البرمجية.
00:04:10بمجرد الانتهاء من التخطيط الأولي، هناك طبقة أخرى تأتي مباشرة بعد ذلك،
00:04:13حيث تقوم بتحديد النطاق والمشكلة بشكل صحيح.
00:04:16يتوافق هذا في الواقع مع مرحلة التحليل أو دراسة الجدوى في إطار SDLC،
00:04:20حيث كنت تقوم بتحليل متطلبات العمل ومعرفة ما إذا كان التنفيذ ممكناً.
00:04:25لذا تتوافق هذه المرحلة من ADLC مع تحديد العمليات المهمة ودور الذكاء الاصطناعي في حلها،
00:04:31وتحديد القيود والحدود التقنية،
00:04:33وتعريف مؤشرات الأداء الرئيسية (KPIs) التجارية والتقنية بوضوح مسبقاً، مثل الوقت، والتكلفة، وزمن الاستجابة، والجدوى.
00:04:39كما تقوم أيضاً بتحديد التنازلات (Trade-offs) في هذه النقطة، لمعرفة العوامل المقبولة وتلك غير المقبولة.
00:04:44لكن الجزء الأهم في هذه المرحلة هو رسم نموذج المسؤولية المشتركة بين الإنسان والوكيل بشكل صحيح،
00:04:49لأن هذا يضع هيكلاً للمساءلة.
00:04:52لا يزال يتعين على الإنسان مراجعتها، لأننا لا نستطيع الوثوق بالوكيل في اتخاذ جميع القرارات.
00:04:56بحلول نهاية هذه المرحلة، سيكون لديك وثائق مناسبة حيث تُعرّف خطوات سير العمل صراحةً مع مؤشرات الأداء الرئيسية،
00:05:02ويتم صياغة نموذج المسؤولية بين الإنسان والوكيل بوضوح.
00:05:05هذا الأمر مهم لأنه في حالة حدوث أي فشل، لا يمكنك إلقاء اللوم على النموذج بالكامل.
00:05:09المساءلة في النهاية يجب أن تظل بيد البشر.
00:05:12ولم تكن هناك حاجة لهذا التخطيط للمسؤولية البشرية سابقاً، لعدم وجود ذكاء اصطناعي حينها.
00:05:17إنها تحدد حدود استقلالية الوكيل، وإذا تخطيت هذه الخطوة،
00:05:21فإنك تخاطر بامتثالك ومسؤوليتك في بيئة التشغيل.
00:05:24للقيام بذلك مع الوكلاء، تستخدم مرة أخرى وضع التخطيط، وتوجهه لتخطيط سير العمل، وزمن الاستجابة، ومشكلات النظام،
00:05:30وجميع الميزات التي يجب أن تتضمنها البنية البرمجية، وما قد يبدو عليه الفشل.
00:05:34بمجرد توضيح هذه النقاط، يفهم الوكيل النطاق الصحيح الذي يجب عليه تكرار المحاولة للوصول إليه أثناء البناء.
00:05:39مع تحديد النطاق والميزات رفيعة المستوى، حان الوقت للانتقال إلى مرحلة التصميم.
00:05:43في هذه المرحلة، نقوم بتعريف البنية الهندسية للنظام الخاص بالوكيل نفسه.
00:05:47هنا تقرر النمط الذي سيتبعه الوكيل، مثل ReAct أو التخطيط والتنفيذ (Plan-and-Act) أو إعداد الوكلاء المتعددين (Multi-agent) أو أي نهج تريده.
00:05:54ثم تخطط لتدفق البيانات من نقطة إلى أخرى، ويصبح هذا الأمر أكثر أهمية عند مشاركة وكلاء متعددين.
00:06:00يجب أن يحصل الوكيل على البيانات الصحيحة، وإلا فإنه سيخلق مشكلات بدلاً من المساعدة.
00:06:05أنت تخطط أيضاً لهياكل التكلفة مثل اقتصاديات الرموز (Token Economics)، وميزات تعديل السياق، والضغط (Compaction)،
00:06:10وتفهم ما ستكون عليه تكلفة نشر هذا الوكيل في بيئة التشغيل،
00:06:14وماذا سيحدث عندما يبدأ في التعامل مع مستخدمين متعددين.
00:06:17هذا هو الوقت أيضاً الذي تختار فيه فعلياً النماذج التي تريد استخدامها، وإطار العمل التنسيقي الذي ستعتمد عليه،
00:06:23وقاعدة البيانات، وجميع التقنيات الأخرى المعنية، وهنا تحدد ما سيبدو عليه النجاح
00:06:28قبل كتابة أي كود، حتى تتمكن من بناء الوكيل باستخدام التطوير القائم على الاختبار (TDD).
00:06:32قبل أن يبدأ نظامك بالعمل الفعلي، تكون قد وضعت في الحسبان التنازلات في زمن الاستجابة، والدقة، والهلوسة، والمشكلات المشابهة.
00:06:38تحتاج هذه المرحلة أيضاً إلى وضع التخطيط الخاص بوكيلك.
00:06:41أنت تعطيه توجيهات لوضع تصميم شامل يغطي بنية الوكيل، وتدفق البيانات، ونموذج التكلفة،
00:06:46والهيكل التقني العام حتى تنتقل إلى الخطوة التالية بخطة ملموسة.
00:06:51بعد الانتهاء من الخطط الأولية، الخطوة التالية هي المحاكاة وإثبات القيمة.
00:06:55هنا تستخدم بيانات من العالم الحقيقي لاختبار الافتراضات التي وضعتها في المراحل السابقة.
00:06:59أنت تقوم بإنشاء نماذج أولية (Prototypes) لكي تتمكن من معرفة ما إذا كان الأمر يستحق المضي قدماً في بناء هذا الوكيل.
00:07:04بشكل أساسي، هذا هو المكان الذي تقرر فيه ما إذا كان ينبغي عليك تطوير الوكيل على الإطلاق، لأن تكلفة الفشل في هذه المرحلة تكون أقل بكثير.
00:07:10لذا تشمل الأنشطة الرئيسية هنا إعداد مجموعة البيانات أو الحقيقة المرجعية (Ground Truth) للاختبار السلوكي،
00:07:15وبناء النماذج الأولية حتى تتمكن من اختبار الافتراضات عالية المخاطر التي وثقتها سابقاً،
00:07:19والتحقق من جودة البيانات، ومعدل الهلوسة، والدقة، وجودة الاستجابة، والمعايير المرجعية (Benchmarks).
00:07:25كما تعيد أيضاً النظر في الفرضية الأولية لتحديد ما إذا كانت ستحقق عائداً على الاستثمار.
00:07:30المخرجات المتوقعة هي مقاييس أداء مقاسة بشكل صحيح وخطوط أساس للتكلفة،
00:07:33إلى جانب وثيقة الحقيقة المرجعية المذكورة سابقاً، والتي تعمل كأصل اختبار لاختبار التراجع (Regression Testing) وضبط النموذج بدقة.
00:07:40تعمل هذه المرحلة كبوابة التحقق من الصحة.
00:07:42إذا انتقلت نتائجك من هنا إلى المرحلة التالية، يمكنك مواصلة العمل على الوكيل.
00:07:46وإذا لم يحدث ذلك، يُعد البناء فاشلاً، واكتشاف ذلك مبكراً أفضل بكثير،
00:07:50لأنه لو وصل هذا الشيء إلى بيئة التشغيل، لكان الضرر أسوأ بكثير.
00:07:54للقيام بذلك، توجه وكيل الذكاء الاصطناعي لإنشاء النموذج الأولي الأول لكي تتمكن من اختباره مقابل كل التخطيط الذي قمت به للتو.
00:08:00ولكن قبل أن نمضي قدماً، لنستمع إلى كلمة من راعينا، Softr.
00:08:04أدوات البرمجة بالبديهية (Vibe Coding) رائعة لإنشاء واجهة مستخدم، ولكن في اللحظة التي تحتاج فيها إلى مصادقة حقيقية،
00:08:08أو أدوار للمستخدمين، أو أذونات، أو قاعدة بيانات تتوسع بالفعل، ينهار كل شيء وتعود إلى كتابة الكود.
00:08:14برنامج Softr هو منشئ تطبيقات بالذكاء الاصطناعي يتعامل مع كل ذلك في توجيه واحد.
00:08:18أنت تصف ما تحتاجه بلغة إنجليزية بسيطة، ويقوم البناء المساعد بالذكاء الاصطناعي بتوليد البنية الكاملة (Full Stack)، وقاعدة البيانات، والصفحات، والتنقل، وتسجيل الدخول، والأذونات القائمة على الأدوار دفعة واحدة.
00:08:28هذه ليست صفحات نموذج أولى، بل هي تعمل بالفعل.
00:08:30يمكنك معاينة التطبيق، والتحقق مما يراه كل دور مستخدم، وعندما تضغط على نشر، يصبح تطبيقك حياً مع الاستضافة، ومجموعات المستخدمين، والأمان من فئة المؤسسات، والتحكم في الوصول.
00:08:40ولا تحتاج إلى مطور برامج لصيانته.
00:08:42كل شيء مرئي حتى تتمكن من تحديث سير العمل، وإدارة المستخدمين، وإضافة الميزات بنفسك.
00:08:47التكلفة الحقيقية للبرمجيات ليست في بنائها، بل في صيانتها، وهذا هو ما يحله Softr.
00:08:52احصل على أرصدة الذكاء الاصطناعي المجانية بالضغط على الرابط في الوصف وابدأ الآن.
00:08:57يمثل هذا نهاية مرحلة التخطيط، وينقلنا إلى الجزء الذي يقفز إليه الكثير من الناس مباشرة، وهو التنفيذ.
00:09:03الخطوات السابقة مهمة حقاً لأنك إذا قمت بها بشكل صحيح، فلن تواجه المشكلات التي يقع فيها معظم الناس هنا نتيجة تخطي تلك المراحل.
00:09:11إذن، هذا هو الوقت الذي تقوم فيه بتطوير وكيلك فعلياً، وبناء المنطق الأساسي، وتنسيق سير عمل التطوير الخاص بك.
00:09:16وهنا ترى أحداً أوضح الانقسامات بين إطار SDLC وإطار ADLC.
00:09:20في SDLC، يعيش المنطق في الكود، والتكوينات (Configurations)، والاعتمادات الخارجية (Third-party Dependencies).
00:09:25أما في ADLC، فيتوزع هذا المنطق عبر الكود، والتوجيهات، والنماذج، والأدوات، والخدمات الخارجية.
00:09:30لذا لم تعد تدير مجرد برمجيات فحسب، بل تدير كل هذه الطبقات معاً، ويمكن لأي منها أن يغير طريقة تصرف النظام.
00:09:38إذا كان لديك أنظمة وكلاء متعددة لتطويرها، فإن إحدى الطرق لتنسيق سير العمل هي واجهة عرض الوكلاء (Agents View) الجديدة في Claude Code.
00:09:44باستخدام واجهة عرض الوكلاء، يمكنك تفويض المهام بشكل أفضل بكثير مقارنة بالاستخدام العادي لـ Claude.
00:09:49لأنه بدلاً من إدارة جلسات Claude Code مختلفة، فإنك تدير طبقة تنسيق واحدة وتمنح توجيهات لمدير الوكلاء لتنسيق جميع الوكلاء من خلالها.
00:09:57الآن في هذه النقطة، تقوم بدمج أدوات مثل بروتوكولات سياق النموذج (MCPs) وواجهات برمجة التطبيقات (APIs).
00:10:01على سبيل المثال، إذا كنت تبني مساعداً شخصياً، فأنت تعلم أنه سيحتاج إلى شيء مثل Google Calendar MCP، و Gmail MCP، وربما Notion MCP.
00:10:09والشيء الأكثر أهمية هنا هو إدارة السياق (Context Management).
00:10:11لأنه بمجرد بناء وكيل لبيئة التشغيل، يصبح هذا أحد الجوانب الأكثر أهمية.
00:10:16حتى أكبر نوافذ السياق المتاحة حالياً، مثل نوافذ المليون رمز في Gemini و Opus، لا تزال تتطلب تعاملاً حذراً.
00:10:24يتعين عليك التأكد من أن الوكيل يحتفظ بالذاكرة الصحيحة ويتجنب تلف السياق (Context Rot).
00:10:28لأنه إذا انتهى به الأمر بوجود الكثير من المعلومات غير الصلة، فإن انتباهه يتشتت في كل مكان وتصبح المخرجات أسوأ.
00:10:34تحتاج أيضاً إلى إجراء اختبارات من جانب المطور خلال هذه المرحلة لضمان الاتساق السلوكي بعد كل تغيير من خلال التحقق يدوياً من إعداد الوكيل مقابل المتطلبات.
00:10:44التطوير والتحقق من الصحة ليسا منفصلين في الأنظمة القائمة على الوكلاء.
00:10:48لا يمكنك المضي قدماً دون اختبار مستمر نظراً لأن تغييراً صغيراً واحداً يمكن أن يحدث تأثيراً ضخماً على سير العمل بأكمله.
00:10:54لذا فأنت بحاجة إلى التحقق من الصحة على مستوى المطور أثناء بناء وكيلك جنباً إلى جنب بدلاً من الاعتماد فقط على خطوة اختبار منفصلة لاحقاً.
00:11:01بعد الانتهاء من بناء نظامك، يصبح الاختبار هو المرحلة التالية.
00:11:05كما ذكرنا سابقاً، يجب أن يكون الاختبار مستمراً أثناء عملية البناء، ولكن بمجرد بناء نظامك، فإنك تختبره تحت ظروف شبيهة ببيئة التشغيل بدلاً من اختباره كمكونات فردية.
00:11:14هذه هي المرحلة التي تقوم فيها بإجراء الاختبار المتكامل (Integrated Testing).
00:11:16كما تقوم أيضاً بإجراء اختبار قبول المستخدم (UAT)، حيث تجمع التعليقات من المستخدمين الفعليين للنظام وتدمجها مجدداً في النظام.
00:11:24أنت تختبر عبر عوامل متعددة مثل الانحياز (Bias)، والامتثال، والأداء، والأبعاد الأخرى المتعلقة بالمخاطر للتأكد من أن الإصدار آمن قبل إطلاقه للعمل.
00:11:32وهنا أيضاً تتغير مقاييس النجاح تماماً.
00:11:35في SDLC، كنت تقيس الصحة الوظيفية باختبارات تنجح أو تفشل ببساطة.
00:11:40أما في ADLC، فأنت تقيس توزيع الدقة، ومعدل الهلوسة، والتكلفة لكل نتيجة لأن أياً من هذه لا ينحصر بوضوح في مجرد نجاح أو فشل فردي.
00:11:48منهجية الاختبار نفسها تنتقل مع ذلك.
00:11:50في SDLC، قامت اختبارات محددة مسبقاً بالتحقق من مسارات الكود المعروفة.
00:11:54وفي ADLC، يصبح ذلك تقييماً مستمراً للتفكير، والأمان، واستخدام الأدوات لأن الوكيل لا يسلك نفس المسار مرتين بنفس الطريقة.
00:12:02هناك أطر تقييم متعددة مثل RAGAS و DEEPVAL، لكن الشيء الرئيسي الذي يثبت صحة الأداء هو كيفية أداء بياناتك مقابل المقاييس التي حددتها سابقاً.
00:12:12وهناك طرق عدة لاختبار نظام قائم على الوكلاء، بما في ذلك الاختبار الوظيفي، وغير الوظيفي، والهنودسي البنيوي، واختبار الحمل.
00:12:18يجب تنفيذ كل منها بدقة، وغالباً باستخدام أنظمة قائمة على الوكلاء نفسها بحيث يتم تحديد الحالات الاستثنائية (Edge Cases) بشكل صحيح وإصلاحها قبل وصولها إلى التشغيل.
00:12:27أيضاً، إذا كنت تستمتع بمحتوانا، فكر في الضغط على زر الإعجاب لأن ذلك يساعدنا على إنشاء المزيد من هذا المحتوى والوصول إلى المزيد من الناس.
00:12:34بمجرد أن يصبح نظامك جاهزاً، يحين الوقت لنشره وإتاحته للعالم الحقيقي.
00:12:39أنت لا تقوم بنشره مباشرة وتعتبر الأمر منتهياً، لأنه مع الأنظمة القائمة على الوكلاء هناك الكثير من الأمور الأخرى المعنية.
00:12:44بالنسبة للنظام العادي، يعني النشر عادةً دفعه إلى بيئة التشغيل ومراقبة صحة النظام.
00:12:49أما بالنسبة للأنظمة القائمة على الوكلاء، فالأمر مختلف تماماً، وهنا يتغير معنى النشر نفسه.
00:12:54في SDLC، كان النشر هو نهاية التطوير وبداية مرحلة تشغيل مستقرة، وهي النقطة التي يدخل فيها البرنامج سنوات استقراره.
00:13:02أما في ADLC، فالنشر هو بداية المراقبة النشطة والتحكم، والتي تتشكل بتحديثات النماذج، وانحراف السياق (Context Drift)، وتغيرات البيئة التي تستمر في التحرك حتى بعد انتقالك.
00:13:11لذا على الرغم من أن التطوير قد يكون مكتملاً، إلا أن هذه المرحلة تعد أكثر أهمية لأنك مضطر الآن لمراقبة المقاييس السلوكية ومقاييس النظام بنشاط.
00:13:19تحتاج أيضاً إلى قواعد تنبيه تراقب باستمرار مشكلات الجودة والأمان والأداء بحيث يمكن التقاطها مبكراً قبل أن تتحول إلى أخطاء إنتاجية واسعة النطاق.
00:13:28النشر هو في الأساس تفعيل محكوم مع ملاحظة مستمرة بينما يتفاعل مستخدمون حقيقيون مع النظام.
00:13:34بدلاً من التركيز فقط على صحة النظام، فإنك تركز على الأداء السلوكي حتى يتم التقاط المشكلات مبكراً قبل أن تصل إلى جميع المستخدمين.
00:13:41عملياً، تقوم أولاً بإصدار النظام لمجموعة محدودة من المستخدمين وتتركهم يستخدمونه تحت ظروف حقيقية.
00:13:46ثم تلاحظ كيف يستجيب النظام القائم على الوكلاء بمرور الوقت قبل طرحه تدريجياً للجميع.
00:13:52بعد أن يمر التنفيذ بجميع العمليات، يصبح دورة مستمرة من الصيانة، والتعلم المستمر، والنمو.
00:13:58هذه مرحلة مهمة لأنها تحافظ على دقة الوكيل وتوافقه مع احتياجات العالم الحقيقي.
00:14:03مع الأنظمة التقليدية، تكون حلقات التغذية الراجعة بسيطة نسبياً.
00:14:06يقوم المستخدم بالإبلاغ عن خطأ برمجي (Bug)، ويقوم المطور بتكرار المحاولة لإصلاحه.
00:14:10أما مع الأنظمة القائمة على الوكلاء، فالأمر مختلف تماماً لأنها تعتمد على عملية تحسين مستمرة لا تتوقف عند أي نقطة.
00:14:16تستمر الدورة في تصفية وتجويد النموذج، ويتم إعادة إدخال جميع الإشارات السلبية لكي يتمكن من تحسين سلوكه بمرور الوقت.
00:14:22يتم ذلك عادة من خلال إشارات واجهة المستخدم مثل الإعجاب وعدم الإعجاب لالتقاط شعور المستخدم بعد الاستجابة.
00:14:29تستخدم العديد من أنظمة الإنتاج بالفعل آليات مماثلة مثل الاختيار بين مخرجات متعددة أو تصنيف الاستجابات كما يظهر في أدوات مثل ChatGPT أو أنظمة التعليقات في Claude.
00:14:39يتم بعد ذلك إعادة إدخال هذه الإشارات إلى النظام القائم على الوكلاء لكي يتمكن من التعلم وتكرار المحاولة نحو أداء أفضل.
00:14:44هناك أيضاً تحديث دوري لمصادر البيانات والتمثيلات الرقمية (Embeddings) لضمان بقاء النظام محدثاً وعدم معاناته من معلومات قديمة.
00:14:52يجب مراقبة التوافق والاتساق (Alignment) باستمرار حتى تظل وسائل الحماية والضوابط فعالة ضد جميع أنواع التوجيهات، بما في ذلك مخاطر مثل حقن التوجيه (Prompt Injection).
00:15:00المتغيرات الرئيسية هنا هي إدارة التكلفة المستمرة، وتتبع الجودة، وسجلات تطوير المنتجات المتأخرة (Backlogs)، وترقيات النماذج، وكلها بحاجة إلى صيانة مستمرة للحفاظ على استقرار النظام وأمانه وتشغيله بمرور الوقت.
00:15:11هذا ينقلنا إلى نهاية هذا الفيديو.
00:15:13إذا كنت ترغب في دعم القناة ومساعدتنا في مواصلة إنتاج مقاطع فيديو مثل هذه، يمكنك القيام بذلك باستخدام زر شكراً (Super Thanks) أدناه.
00:15:20كما هو الحال دائماً، شكراً لكم على المشاهدة وسأراكم في الفيديو القادم.
Community Posts
No posts yet. Be the first to write about this video!
Write about this video