Anthropic تُصلح توًّا أكبر عيب في هندسة الرسوم البيانية
AAI LABS
Computing/SoftwareInternet Technology
Transcript
00:00:00هناك مصطلح جديد يتداول حالياً يسمى “هندسة الرسوم البيانية” (graph engineering)، والجميع يتحدث عنه على منصة X.
00:00:04قبل الرسوم البيانية، كان الأمر كله يتعلق بـ “هندسة الحلقات” (loop engineering)، حيث تمنح الوكيل هدفاً ويعمل هو على تحقيقه
00:00:09بمفرده. ولكن مع الرسوم البيانية، يتم إنجاز العمل بشكل أسرع ويغطي مساحة أكبر بكثير في وقت واحد
00:00:14مقارنة بالحلقة. ولكن هناك مشكلة كبيرة فيها. خطأ واحد في جزء صغير من
00:00:18الرسم البياني يربك المخرجات بالكامل، ويكون من الصعب تعقبه لأن كل ما تحصل عليه
00:00:23في النهاية هو النتيجة النهائية فقط. لذا أطلقت Anthropic لتوها حلاً لهذه المشكلة
00:00:27بالتحديد، للحفاظ على عمل الرسوم البيانية دون تعطل. إذا كنت جديداً هنا، فنحن شركة
00:00:32برمجيات، وهذه قناتنا AI Labs، حيث نوضح لك كيفية تحسين عملك باستخدام الذكاء الاصطناعي،
00:00:37وإذا لم يكن لديك مشروعك الخاص، يمكنك استخدام هذه المهارات لكسب المال عن طريق تحسين الأعمال للآخرين.
00:00:42وفي هذا الفيديو، سنشرح هندسة الرسوم البيانية لمن لا يعرفها
00:00:46ونقدم لك الحل الدقيق الذي اقترحته Anthropic. قبل أن نشرح لك هندسة الرسوم البيانية،
00:00:52عليك أن تفهم ما هي هندسة الحلقات في الواقع. إذا كنت تعرف ذلك بالفعل، يمكنك تخطي هذا الجزء.
00:00:56الحلقة هي أساساً دورة عمل تسلمها للوكيل. وبدلاً من أن توجهه
00:01:02خلال كل خطوة بنفسك، تخبره بالهدف النهائي الذي يحتاج للوصول إليه، ويصل إلى هناك بمفرده،
00:01:07معدلاً مساره أثناء العمل. لقد كنا نستخدمها بكثرة في بيئات عملنا. ولدينا بالفعل فيديو كامل
00:01:12عن هندسة الحلقات أيضاً، تعمقنا فيه أكثر في الطرق المختلفة لإعدادها، لكن الحلقات
00:01:17تتحول الآن إلى شيء يسمى الرسوم البيانية. المشكلة في الحلقات تعود إلى طريقة بنائها.
00:01:22تقوم الحلقة بإنهاء جزء من العمل، ثم تبدأ خطوة التحقق لمعرفة ما إذا كان الأمر كما ينبغي
00:01:27أن يكون تماماً. وبمجرد اجتيازها، تبدأ الخطوة التالية. كل شيء يعمل في خط مستقيم، لذا تظل كل خطوة
00:01:32منتظرة للخطوة التي قبلها، حتى لو لم تكن هناك أي علاقة بين الخطوتين. وهندسة الرسوم البيانية
00:01:37تعالج هذا الأمر بالتحديد. بدلاً من التشغيل في خط مستقيم، يقسم الرسم البياني المهمة الرئيسية إلى أجزاء
00:01:42أصغر، ويحصل كل جزء على الوكيل الخاص به. أول ما تكسبه من ذلك هو السرعة، لأن عدة
00:01:47وكلاء يغطون العمل في وقت واحد، بدلاً من وكيل واحد يطحن المهمة بأكملها. وتقسيم
00:01:52العمل بهذه الطريقة يقلل التكلفة نوعاً ما أيضاً، لأنك تستطيع اختيار النموذج الذي يعمل عليه
00:01:56كل وكيل. فتتوقف عن استنزاف أرقى وأغلى نموذج لديك في أجزاء لم تكن تحتاج إلى هذا القدر من
00:02:01الذكاء في المقام الأول. ولكن هذه هي التكلفة لكل وكيل، وليست التكلفة الإجمالية. فالرسم البياني يستهلك
00:02:07رموزاً (tokens) أكثر بكثير مما يستهلكه وكيل واحد، لأن لديك مجموعة كاملة تعمل بالتوازي بدلاً من واحد.
00:02:12إذا كنت تستخدم الرسوم البيانية، فتوقع الوصول إلى حدود الاستخدام بشكل أسرع بكثير مما اعتدت عليه، لذا لا يمكنك
00:02:17إعداد هذا بالفعل باستخدام خطط الـ 20 دولاراً في ClaudeCode وCodex. الآن إذا كنت تستخدم ClaudeCode،
00:02:22فإن هذا قد لا يكون جديداً عليك تماماً، لأنك رأيت بالفعل رسماً بيانياً وهو بيئة العمل
00:02:27الديناميكية (dynamic workflow). تأخذ بيئة العمل الديناميكية المهمة التي تسلمها وتوزعها على مجموعة من الوكلاء الفرعيين،
00:02:33وهو ما يفعله الرسم البياني أساساً. قبل أن ندخل في الأشكال التي يمكن أن يتخذها الرسم البياني، عليك أن
00:02:38تعرف مكوناته الفعلية. يتكون كل رسم بياني من شيئين: العقد (nodes) والحواف (edges). العقدة هي
00:02:44أساساً مهمة واحدة منفصلة من المهمة الأكبر التي سلمتها، وتعمل بمفردها. إنها وكيل
00:02:49ينفذ مهمة في نافذة سياق معزولة خاصة به ثم يرفع تقريره. وما يربط كل تلك المهام المستقلة
00:02:55ببعضها هو الحافة. تتحكم الحافة في كيفية انتقال البيانات من عقدة إلى أخرى، لكي تصل مخرجات وكيل ما
00:03:01إلى الوكيل المناسب في الوقت المناسب. لذا يجب ربط كل عقدة ببقية الرسم البياني
00:03:06بطريقة ما. يمكنك رؤية ذلك في مجموعة من الوكلاء الذين يراجعون جميعاً نفس العمل. لا أحد
00:03:10منهم ينتظر الآخر على الإطلاق. لكنهم جميعاً بدأوا من نفس العمل، وكل تقاريرهم تصب
00:03:15في نفس المكان في النهاية، فهذا هو ما يتكون منه الرسم البياني. والآن إليك الأشكال التي تتجمع بها
00:03:20تلك الأجزاء. الشكل الأول عرضناه لكم سابقاً على هذه القناة، وأخطأنا في تسميته
00:03:25في ذلك الوقت. أطلقنا عليه اسم “حلقة”، لأن هذا كان قبل أن تعتمد هندسة الرسوم البيانية كـ مفهوم اصطلاحي. ولكن
00:03:30ما كان لدينا في الواقع هو رسم بياني كنا نكرره، وكان شكله أشبه بالمعين. مهمة واحدة في
00:03:35الأعلى تتفرع إلى عدة وكلاء فرعيين يعملون جنباً إلى جنب، ثم تعود لتتجمع في وكيل
00:03:41واحد يجمع كل ما وجدوه في إجابة واحدة. ثم هناك نمط التجميع عند حاجز (fan in at a barrier)،
00:03:46وهو الشكل الذي تريده عندما يتوجب تقييم شيء واحد من عدة زوايا في وقت واحد. جزء التفرع (fan out)
00:03:51يرسل نفس المشكلة إلى مجموعة من الوكلاء، وينظر كل واحد إليها من منظور مختلف.
00:03:56لا شيء يتقدم إلى الأمام حتى يقدم كل واحد من أولئك الوكلاء تقريره، وعندها فقط
00:04:00يبدأ في تشغيل إصلاحاتهم. هناك الكثير من الأشكال الأخرى أيضاً. لكن كل شكل من هذه الأشكال يعتمد على
00:04:05شيء واحد، وهو التحقق (verification). إذا لم تقم بإعداد عمليات التحقق تلك بشكل صحيح، فإن كل وكيل يأتي
00:04:10بعد ذلك يبني عمله فوق خطأ. ولكن قبل أن نتحدث عن التحقق، سيكون من الرائع أن
00:04:15تشترك في القناة وتضغط على زر الإعجاب. هذه اللفتة البسيطة من الدعم تعني الكثير بالنسبة لنا.
00:04:20بمجرد أن تقوم بتشغيل أسطول كامل من الوكلاء، تقع الأخطاء بطرق لا تحدث أبداً مع وكيل واحد.
00:04:25المشكلة الأكبر هي كمية العمل فقط. إنهم يعملون جميعاً في نفس الوقت، لذا تعود كومة
00:04:30ضخمة من النتائج دفعة واحدة، ويصبح من الصعب جداً مراجعتها في النهاية. المشكلة الأخرى هي أنك
00:04:34لا يمكنك رؤية ما حدث. عندما يسير شيء ما بشكل خاطئ، لا تكون لديك طريقة لمعرفة سببه.
00:04:39الآن تحاول جميع الكيانات الذكية التحقق مما تكتبه، سواء طلبت منها ذلك أم لا. إذا كنت تعمل مع البرمجة،
00:04:44فهذا يعني فقط أن الوكيل يشغل اختياراتك ويكتشف الأخطاء التي تظهر. لكن هذا يكتشف الأخطاء
00:04:49الكبيرة فقط. ولا يزال لا يتحقق من طريقة كتابة الكود، وهذا أمر مهم لأنه إذا استمر Claude
00:04:53في كتابته بهذه الطريقة، فسيؤدي ذلك إلى مشاكل في المستقبل. هناك بضع أدوات
00:04:58مدمجة لهذا الغرض في Claude Code أيضاً. الأولى هي مهارة التحقق (verify skill)، والتي تأخذ الكود من البداية
00:05:03إلى النهاية وتؤكد أنه يعمل بالفعل بالطريقة المفترضة. والثانية هي تسلسل الأدوات (tool chaining)، وهي
00:05:08أساساً أن يقوم الوكيل بتشغيل أدوات مختلفة للتحقق. يعرف Claude بالفعل كيف يشغل الأدوات التي
00:05:13تفحص عملك، لذا يقرأ الأخطاء الواردة ويصلحها بنفسه. كما يمكنه استنتاج الأوامر
00:05:18الدقيقة لمشروعك بمفرده أيضاً. ولكن كتابتها في ملف Claude.md توفر عليه عناء
00:05:24اكتشافها في كل مرة. والأداة الثالثة هي مهارة مراجعة الكود، والتي تفحص الكود
00:05:29مقابل مجموعة من المعايير. لا يأتي كل وكيل مع هذه المهارة، ولكن يمكنك فقط طلب بناء مهارة
00:05:33من وكيلك إذا لم تكن متوفرة لديه. ولكن التحقق الذي يعمل بشكل أفضل في الواقع هو الذي تقوم ببرمجته بنفسك،
00:05:38بدلاً من الاعتماد الكلي على الأدوات المدمجة. لذا فإن أسرع طريقة لبناء مهارة تتحقق
00:05:44من عملك هي ملحق منشئ المهارات (skill creator plugin) في Claude Code. يمكنك أيضاً استخدام مهارة Claude Code هذه
00:05:49في Codex أيضاً. تقوم بتشغيل أمر الملحق، ثم تبحث عن skill creator وتثبته. ومن هناك،
00:05:54لديك خياران. يمكنك تثبيته على نطاق المستخدم (user scope)، مما يعني أنه سيكون متوفراً بغض النظر عن
00:05:58المجلد الذي تعمل فيه. أو يمكنك تثبيته للمشروع الذي تعمل عليه حالياً فقط.
00:06:03وبما أن هذه مهارة ستستخدمها باستمرار، فقد اخترنا نطاق المستخدم. بعد ذلك،
00:06:07تقوم بإعادة تحميل الملحقات باستخدام أمر الشرطة المائلة (slash command) ويكون منشئ المهارات جاهزاً للاستخدام. الآن تخبره
00:06:12بما تريد بناءه وهذا هو الجزء الذي تصف فيه نوع التحقق الذي تبحث عنه
00:06:17في الواقع. نحن نستخدم غالباً مهارة المراجعة لفحص العمل المكتمل مقارنة بما طلبناه في
00:06:22المقام الأول. وهذا يهم أكثر بكثير في الرسم البياني لأن كل وكيل يرى الجزء الخاص به فقط.
00:06:28هذا ما يمنحه طريقة لفحص ذلك الجزء مقابل المتطلبات الأصلية. لكن المهارة تكون
00:06:32جيدة بقدر جودة النموذج الذي تشغلها عليه فقط. عندما كنا نبني نظام التحقق لواجهة المستخدم
00:06:37المتعلة بموقع مجتمعنا، قمنا بتشغيل المراجع على Haiku لأنه رخيص والمهمة بدت بسيطة
00:06:43بما فيه الكفاية. وعاد بقائمة طويلة من المشاكل. وبالنظر إلى عدد الملاحظات وحده، بدا
00:06:47أنه قد قام بعمل رائع. ثم قمنا بتشغيل نفس الشيء بالضبط على Opus وأشار إلى عدد أقل بكثير من الأشياء.
00:06:53بدا ذلك وكأنه أسوأ نتيجة، حتى قرأنا التبريرات. الكثير مما أبلغ عنه Haiku
00:06:58كانت أشياء تركناها هناك عن قصد. لذا كانت معظم النتائج التي وصل إليها غير ضرورية تماماً.
00:07:03استنتج Opus ذلك من الكود المحيط به، بينما غفل عنه Haiku تماماً. لذا فإن المراجعة
00:07:08الرخيصة لم توفر علينا أي شيء لأن المراجعة نفسها أصبحت تحتاج إلى مراجعة. الآن ضع ذلك داخل
00:07:13رسم بياني حيث توجد مجموعة كاملة من العقد تفحص عملها باستخدام نفس المهارة. سيكون لديك
00:07:18وكلاء يحرقون الوقت والرموز لإصلاح أشياء لم تكن مكسورة أصلاً. ولأن هذا يحدث عبر
00:07:23وكلاء منفصلين في وقت واحد، فلن تكون لديك طريقة لمعرفة من بدأ ذلك.
00:07:27لذا فإن النموذج الذي تختاره لا يحدد جودة المراجعة فحسب، بل يحدد جودة
00:07:31الرسم البياني بأكمله. العقدة التي تقوم بالتقييم هي المكان الوحيد الذي سيكلفك فيه توفير الرموز
00:07:37خسارة كل شيء. الشيء الآخر الذي عليك تقريره هو كيف ومتى يتم استدعاء تلك المهارة. وهذا
00:07:41يقسمها إلى ثلاثة أنواع. ولكن قبل أن نتعمق في الأنواع، دعونا نستمع إلى كلمة من راعي الفيديو.
00:07:46إذا قمت يوماً بسحب بيانات حية من الويب، فأنتم تعلمون أن التجريف (scraping) عذاب حقيقي، حيث تنتهي
00:07:51بمحاربة اختبارات الكابتشا (CAPTCHA) وحدود المعدل، والمصارعة مع الخوادم الوكيلة (proxies)، وترقيع التصميمات التي تنكسر
00:07:56لحظة إطلاقها. لذا نلجأ إلى SERP API، والذي يحل كل هذه المشاكل لتتمكن من التركيز على البناء.
00:08:01إنه استدعاء واحد لواجهة البرمجة (API)، ترسل طلباً وتحصل على كائن JSON نظيف يحتوي بالضبط على البيانات التي تحتاجها
00:08:07مع وقت تشغيل يتجاوز 99.9% واستجابة في حدود 1.2 ثانية. عندما تبني وكلاء ذكاء اصطناعي، يمكنك
00:08:14توجيه Google search API إلى وكيل يحتاج إلى معلومات حديثة أو استخدام Google Scholar API
00:08:20للأوراق المحكمة ذات البيانات الوصفية الكاملة، ولهذا السبب تعتمد عليه الكثير من وكلاء الإنتاج. ابدأ بـ
00:08:25250 رصيداً مجانياً باستخدام الرابط الموجود في الوصف أو امسح رمز QR على الشاشة. شكراً لـ SERP API على
00:08:32رعاية هذا الفيديو. النوع الأول هو المستقل (standalone)، وهذا النوع من المهارات يعمل فقط عندما
00:08:37تشغله بنفسك بالفعل. تم بناء المهارة المستقلة للتعمق في شيء موجود بالفعل، حتى تتمكن من
00:08:42إعادة فحص المخرجات المكتملة بشكل صحيح. لهذا السبب لا تريدها أن تعمل بعد كل تشغيل. ستكون
00:08:48يحرق الرموز في مراجعة ثقيلة لعمل لم ينته بعد. إحدى المهارات التي استخدمناها سابقاً هي
00:08:53مهارة مراجعة الكود النووية الحرارية (thermonuclear code review) من Cursor. حيث تنشر مجموعة من الوكلاء وترسل كل واحد خلال الكود من
00:08:59زاوية أمنية مختلفة. كل النتيجة تعود في مكان واحد، حتى يتمكن من العمل على الإصلاحات
00:09:04معاً، وهذا هو بالضبط نوع المراجعة الذي تشغله فقط بمجرد انتهاء التطبيق. لبناء واحدة من هذه، من الأفضل استخدام
00:09:10منشئ المهارات (skill creator) بدلاً من مجرد أمره ببدئها، لأن ما يعود يكون مجرباً، ومما يسهل
00:09:15الوثوق به. تخبره في الموجه بالمنطقة التي تريد مراجعتها، وتأكد من ذكر أن
00:09:20المراجعة يجب أن تكون شاملة حتى يعرف أنك تريد مراجعة عميقة وليست سريعة. لكن المهارة المستقلة
00:09:26لا فائدة منها لعقدة لا تزال تعمل، لأن عليك تشغيلها بنفسك. لهذا السبب توجد
00:09:31المهارات المدمجة (embedded skills). تعمل المهارة المدمجة كجزء من بيئة العمل التي تشغلها بالفعل دون أن تطلب
00:09:36ذلك. يمكنك بناء مهارة تعمل عندما يطلب شخص ما ميزة جديدة. حيث تفحص
00:09:41أن كل مكون يتم إنشاؤه يتبع القواعد التي حددتها في المهارة، ولن تسمح بـ
00:09:45إنهاء التنفيذ حتى يتم فحصها مقابل تلك القواعد. يمكنك بناء مهارات مدمجة
00:09:50بنفسك، ولكن لا يمكنك أخذ مهارة مثبتة مسبقاً وجعلها تستدعى تلقائياً، مثل
00:09:54مهارة التحقق التي تحدثنا عنها سابقاً. التعليمات التي تعمل عليها تلك المهارات توجد داخل المنتج، و
00:10:00لا يمكنك تعديلها. لبناء مهاراتك الخاصة، امنح منشئ المهارات موشراً يخبره بتشغيل خطوات التحقق
00:10:05بعد كل تنفيذ ميزة، فتخبره باختبار الميزة من البداية إلى النهاية حتى
00:10:10يكتشف ما إذا كان العمل الجديد قد كسر أي شيء كان يعمل بالفعل. ينشئ Claude المهارة لك
00:10:16حينها، ولأن منشئ المهارات هو من أنشأها، فإنها تأتي مع مراجع وسكريبتات قام منشئ المهارات
00:10:21بهيكلتها واختبارها كجزء من العملية. الآن للتحقق من ميزة ما، يستخدم Claude اختبار المتصفح بشكل
00:10:26افتراضي حيث يفحص الواجهة عن طريق فتح متصفح Chrome كامل، وتحميل الصفحة، والتقاط
00:10:31لقطات شاشة لها. وإذا قمت بربط Puppeteer أو Playwright، وهما أساساً الأدوات التي يستخدمها معظم
00:10:36الناس لتشغيل المتصفح تلقائياً، فسيفعلان نفس الشيء. لكن Chrome معروف باستهلاك الذاكرة
00:10:41والعمل بشكل ثقيل، وللتحقق من صفحة مراراً وتكراراً داخل بيئة العمل، فإنه بطيء بما يكفي ليبدأ
00:10:46في تكليفك وقتاً حقيقياً. لذا هناك طريقة أخف للقيام بذلك، تسمى Chrome Headless Shell. إنها أساساً
00:10:52نسخة مفرغة من المتصفح مع انتزاع جميع الأجزاء الإضافية. لا يزال الوكيل ينتقل إلى
00:10:57الصفحة ويلتقط لقطات الشاشة بنفس الطريقة. هو فقط ينجز كل ذلك بشكل أسرع بكثير من
00:11:02متصفح Chrome الكامل. يمكنك بناء ذلك مباشرة في مهارة التحقق التي تنشئها. ثم يتم فحص كل ميزة
00:11:07يبنيها الوكيل بصرياً دون أن تقوم بإعداد أي شيء في كل مرة. وبصرف النظر عن ذلك،
00:11:12فإن المهارة التي نستخدمها أكثر من غيرها في سير عملنا الخاص هي مهارة تسمى الرأي الثاني (second opinion)، والسبب بسيط.
00:11:17الوكيل الذي بنيت الشيء بواسطته هو أسوأ وكيل ممكن لمراجعته. إنه يراجع عمله الخاص بناءً على
00:11:23نفس السياق الذي استخدمه لبنائه، لذا فهو يراجع فقط بناءً على ذلك. جلسة Claude الجديدة لم ترَ
00:11:28أي شيء من ذلك. وهي تعطي مراجعة غير متحيزة وتمنحك إجابة مباشرة. الآن يمتلك Claude مستشاراً
00:11:33مدمجاً يقوم بشيء من هذا القبيل، ولكنه يقرأ المحادثة التي تتواجد فيها حالياً لذا فهو يرث
00:11:38كل ذلك السياق نفسه. مهارة الرأي الثاني تُستخدم عندما تريد المراجعة بدونه. وهي تعمل عن طريق بدء
00:11:43جلسة Claude أخرى من داخل الجلسة التي تشغلها بالفعل، باستخدام علم (flag) -p. هذا هو
00:11:48العلم الذي يطلق جلسة Claude Code منفصلة تماماً في الخلفية عن طريق إعطائها موشراً
00:11:53للعمل عليه. هناك أمران تحتاج إلى معرفتهما إذا كنت ستستخدم هذا. نظرًا لأنه
00:11:57يططلق جلسة منفصلة تماماً، فإنه يستغرق وقتاً طويلاً جداً للعودة بالإجابة،
00:12:02والنموذج يهم هنا أكثر من أي مكان آخر، لأن الفكرة كلها هي الحصول على قراءة ثانية أكثر ذكاءً.
00:12:07لذا يستحق الأمر إخبار Claude صراحة ببدء تلك الجلسة على Opus. هذا يعطي كل عقدة في
00:12:12رسمك البياني طريقة لفحص عملها بواسطة شيء لم يشارك في القيام به. لكن مهارة واحدة لا يمكنها
00:12:18تغطية كل شيء. بمجرد مراجعة شيء ما بشكل صحيح، فإنك تراجعه من عدة
00:12:22زوايا مختلفة، ولكل زاوية طريقتها الخاصة في القياس. لا يمكنك حشر جميع أنواع المراجعة في
00:12:27مهارة واحدة، لأن الوكيل بهذه الطريقة سيكون لديه الكثير من الاتجاهات لمراجعتها وينتهي به الأمر إلى التراجع
00:12:33بدلاً من التحسن. لذا تقوم ببناء مهارة منفصلة لكل زاوية وتربطها معاً. فريق Anthropic
00:12:38ينتهج هذه الطريقة أيضاً. إنهم يربطون مهارة مراجعة الكود مع مهارة التبسيط ومهارة التحقق،
00:12:43وكل هذه المهارات الثلاث تأتي الآن مع Claude Code. وعلاوة على ذلك، فإنهم يشغلون مهارة التصميم الخاصة بهم،
00:12:49والتي تفحص الواجهة مقابل ملف design.md، وهو أساساً الملف الذي يحتوي على كل
00:12:54قرارات التصميم الخاصة بالمنتج. لذا فهذه مراجعة تأتي من أربعة اتجاهات بدلاً من اتجاه واحد. وسوف
00:12:59تنتهي في نفس المكان، مع مجموعة من المهارات التي تغطي كل منها زاوية مختلفة. ولكن لا يمكنك فقط
00:13:04أمر الوكيل بتشغيلها جميعاً في وقت واحد. ما تحتاجه هو مهارة واحدة أخرى تقبع فوق البقية،
00:13:09والتي هي أساساً مهارة منسقة (orchestrator skill) مهمتها الوحيدة هي تشغيل المهارات الأخرى. حيث تطلق وكيلاً لكل
00:13:15مهارة مراجعة لديك وتسلم كل واحد مهارته. يراجع جميعهم في نفس الوقت في
00:13:20نوافذ السياق المنفصلة الخاصة بهم. ثم تجمع كل نتيجة في تقرير واحد يمكن لوكلاء الإصلاح
00:13:25العمل منه. ثم عندما تبني رسم بياني، كل ما عليك قوله في الموجه هو أنه
00:13:30يجب استخدام تلك المهارة الواحدة. كل عقدة يطلقها تحمل تلك المهارة الفردية وتتفرع المراجعة بأكملها
00:13:35تحتها بمفردها. لقد قمنا بتنسيق مستند يحتوي على جميع الطرق التي يمكنك من خلالها إعداد
00:13:40عمليات التحقق للرسوم البيانية بالتفصيل. هذا المستند إلى جانب جميع المهارات المعروضة في هذا الفيديو متاحة
00:13:45في AI Labs Pro، وهو مجتمعنا. لذا إذا وجدتم قيمة فيما نقدمه وأردتم دعم
00:13:50القناة، فهذه هي أفضل طريقة للقيام بذلك. الرابط في الوصف. هذا ينقلنا إلى نهاية هذا
00:13:55الفيديو. إذا كنتم ترغبون في دعم القناة ومساعدتنا على الاستمرار في إنشاء فيديوهات مثل هذه، فيمكنكم القيام بذلك عن طريق
00:14:00استخدام زر شكراً جزيلاً (super thanks) أدناه. كما هو الحال دائماً، شكراً لكم على المشاهدة وسأراكم في الفيديو القادم.