Transcript
00:00:00في الشهر الماضي كان الحديث عن هندسة الحلقات، وقبله عن هندسة السياق، واليوم الصيحة
00:00:05الجديدة هي هندسة الرسم البياني. ولكن هل هذا مفهوم تحتاج لفهمه فعليًا أم أنه مجرد
00:00:11ضجة إعلامية للذكاء الاصطناعي تضع مسمى براقًا على موضوع بلا قيمة؟ حسناً، في هذا
00:00:17الفيديو سنُجيب عن هذا السؤال، وحرقًا للأحداث: هذا ليس موضوعًا بلا قيمة. الآن
00:00:23هندسة الرسم البياني ليست شيئًا ينطبق على كل مشروع صغير تبنيه
00:00:28ولكنها مفهوم سترغب في فهمه، خاصة إذا كنت ممن يستخدمون
00:00:33حلقات معقدة. لذا إن كان هذا ينطبق عليك أو سينطبق في المستقبل القريب، فستحتاج
00:00:38لمتابعة هذا الفيديو. فهندسة الرسم البياني ليست سوى امتداد أو تطور لهندسة الحلقات.
00:00:43لذا سنراجع سريعًا ما تعنيه هندسة الحلقات لكي نكون جميعًا على
00:00:47دراية واحدة. تتكون جميع الحلقات من ثلاثة أجزاء رئيسية. أولاً: المشغّل. كيف
00:00:54تبدأ العملية فعليًا؟ من الأفضل أن تكون ذاتية التشغيل، كأن تعمل يوميًا في وقت معين أو بناءً على حدث.
00:01:00الخطوة الثانية هي المهمة. ما الذي تفعلونه بالضبط؟ ثم الخطوة الثالثة نحتاج إلى معيار
00:01:07للنجاح. فنحن نطلب منها القيام بشيء ما، فكيف نعرف أنها نفذته بشكل صحيح؟ لأنه
00:01:13إن لم تنفذه بشكل صحيح، أريدها أن تعيد التشغيل من البداية. ويفضل أن يعمل كل شيء مع حفظ
00:01:19البيانات في مكان ما لنتمكن من إضافة جانب للتحسين الذاتي. لكن في أبسط
00:01:25صورها، نحتاج لمشغّل، ومهمة يتم تنفيذها، ثم نكون قادرين على اختبارها لمعرفة ما إذا نجحت، وذلك
00:01:30ينبغي أن يكون تلقائيًا بالكامل. وفي مثالنا هنا، لدينا حلقة تُنشئ تقريرًا صباحيًا
00:01:35لنا كل يوم. لدينا وكيل ذكاء اصطناعي يعمل يوميًا في الساعة 7 صباحًا. وهذا هو المشغّل.
00:01:42ومهمته هي البحث في منصات وسائل التواصل الاجتماعي المختلفة؛ يوتيوب، وتويتر، وريديت لإنشاء
00:01:47معلومات عن الذكاء الاصطناعي وما هو شائع. وأريده أن يفحص بريدي الإلكتروني. وبمجرد إنهاء ذلك
00:01:54أريده أن يدمج المعلومات ويُنشئ لي تقريرًا. هذه هي المهمة. أما النجاح في هذه
00:02:00الحالة فهو غير واضح قليلاً. كيف نحدد أن التقرير أُنجِز بشكل صحيح؟ في هذه الحالة
00:02:05أخبرنا حقتنا بأن التقرير يحتاج لمعلومات من هذا النوع، وأن يكون بهذا الطول،
00:02:11وأن يتضمن روابط. لقد زودناها ببعض المعايير للمقارنة بناءً عليها. فهذه هي
00:02:17الحلقة الخاصة بنا. بسيطة للغاية، ينفذها وكيل واحد. كيف نحول هذا إلى رسم بياني؟ كيف
00:02:25ننتقل من هندسة الحلقات إلى هندسة الرسم البياني لنفس هذه المهمة تمامًا؟ لا أزال أريد
00:02:30إكمال تقريرنا الصباحي يوميًا. لنلقِ نظرة؛ لأن الجزء الموجود على اليمين هو
00:02:35نسخة هندسة الرسم البياني لنفس المهمة. نحن نحاول الحصول على التقرير نفسه، إلا أننا
00:02:40زدنا عدد الوكلاء المنفذين. وتحديدًا انتقلنا من وكيل واحد يفعل
00:02:46كل شيء إلى عدد من الوكلاء يقومون بمهام محددة متصلة ببعضها البعض. إذن
00:02:53ما زال لدينا المشغّل نفسه، سيعمل كل صباح عند الساعة 7، لكن لدينا الآن وكيل واحد
00:02:58يبحث في يوتيوب، ووكيل يبحث في تويتر، وآخر في ريديت، وآخر يتولى البريد
00:03:04المنزلي، وهكذا. كل وكيل من هؤلاء سيحصل على المعلومات المطلوبة، وسيقوم
00:03:09بتلخيص وتجميع تلك المعلومات بمفرده، ثم يرسل ملخصه إلى وكيل
00:03:17التقارير، والذي يجمع بدوره كل تلك البيانات ويصيغها مجددًا في التقرير الذي نريده. ويمكننا
00:03:23الارتقاء بهذا خطوة أبعد والقول بوجود وكيل مراجعة يتولى بنفسه
00:03:30فحص التقرير المنشأ ومقارنته بما حددناه كتقرير ناجح، وما إذا
00:03:36كنا بحاجة إلى تكرار هذه الدورة مجددًا أم أنه يمكننا إرساله مباشرة للتنفيذ؟ وتلك
00:03:41هي هندسة الرسم البياني باختصار. لنقم بتحليل ذلك؛ لأنك ربما تقول:
00:03:48“كل ما فعلناه هو إضافة مجموعة وكلاء، لا أفهم حقًا ما حدث.”
00:03:51نعم، لقد أضفنا بالفعل بعض الوكلاء الآخرين، وهناك سبب لذلك. فالسبب في كون هندسة الرسم البياني
00:03:58أكثر تعقيدًا ليس لرغبتنا في تعقيد الأمور لمجرد التعقيد، بل لأننا
00:04:03أخذنا كل مهمة فردية وحولناها أساسًا إلى وكيل يشغل نسخته الخاصة
00:04:09من هندسة الحلقات. فما الذي كان لدينا سابقًا؟ كانت لدينا هندسة الحلقات التي تقوم بكل
00:04:14هذه المهام وتتحقق من معايير النجاح، لكنها كانت تفعل ذلك على مستوى عالٍ جدًا
00:04:18وتنفذ مجموعة مهام مختلفة في وقت واحد. بدلاً من ذلك، ما فعلناه مع هندسة الرسم البياني
00:04:22هو أننا ركزنا على مهمة واحدة محددة، وأصبح لدينا هذا الوكيل المخصص فقط لتحليل يوتيوب
00:04:29والبحث فيه. وحولنا ذلك إلى بناء قائم على هندسة الحلقات أيضًا. فكر في الأمر؛
00:04:34على الرغم من تقليصها لمهمة واحدة، لا تزال هنسدة حلقات. لدينا مشغّل في الساعة
00:04:397 صباحًا، ولدينا مهمة؛ فهو لا يزال بحاجة لإيجاد معلومات على يوتيوب عن الذكاء الاصطناعي وتلخيصها.
00:04:46وثالثًا، لا يزال لدينا معيار نجاح. ولكن لأننا حولنا هذا إلى نظام قائم
00:04:51على هندسة الرسم البياني، يمكننا أن نكون محددين للغاية بشأن شكل النجاح في كل
00:04:57خطوة من الرحلة. فقد نقول له مثلاً: أحتاج منك جلب 5 مصادر على الأقل، وأن
00:05:03يكون الملخص فقرتين على الأقل، أو لكل مصدر وكل معلومة تجدها،
00:05:09عليك توضيح الفائدة منها. فبدلاً من أن تكون عملية التحقق
00:05:16عامة ومحاولة حشر كل هذه الأمور في تقييم واحد مثل: هذا نجح أو لم ينجح،
00:05:22قمنا بتقسيمها إلى أجزاء منفصلة. ولماذا يجب أن تهتم
00:05:27بذلك؟ أولاً، لأن ذلك سيُحسن الجودة؛ فبدلاً من جعل وكيل واحد يقوم بكل
00:05:33شيء، جعلت وكيلاً واحدًا يقوم بشيء واحد. ومن منظور تدهور السياق،
00:05:40وحقيقة أن نافذة السياق لديه ستكون فارغة نسبيًا مقارنة بهذا الوكيل الذي يحاول
00:05:44القيام بـ 10 أشياء في وقت واحد، فهذا يعني أننا سنحصل على مخرجات أفضل. كما أن ذلك سيكون أسرع.
00:05:51فبدلاً من وكيل واحد ينفذ 10 مهام، لدي 4 وكلاء يعملون بالتوازي لتنفيذ 4 مهام.
00:05:56لذا فهو أسرع وأكثر فعالية، ويسهل تحديد وقت حدوث الفشل. لأنني أستطيع أن أعرف
00:06:03سريعًا ما إذا كانت المشكلة في يوتيوب أم في ريديت. بينما يصعب هنا أحيانًا
00:06:08تحديد سبب المشكلة بدقة لمعرفة أين أخطأنا في المسار حين لم يعجبنا
00:06:15التقرير واضطررنا لإعادته للمراجعة. ومرة أخرى، يعود ذلك لإمكانية تحديد معايير النجاح
00:06:20لكل مهمة فرعية. هذا هو مفهوم هندسة الرسم البياني باختصار، وسبب اهتمامك
00:06:27به. فليس لدينا وكيل واحد بل سلسلة من الوكلاء المتصلين بطرق
00:06:33مختلفة. لقد قمنا بتفكيك مهامهم بشكل فردي ومستقل. ولأنها
00:06:38مهمة دقيقة، يمكننا أن نكون محددين جدًا مع كل مهمة فيما يتعلق بما نريده منها،
00:06:44وما الذي يعنيه النجاح. ومرة أخرى، كل وكيل من هؤلاء أصبح أساسًا نظامًا قائمًا
00:06:48على هندسة الحلقات، وكل ما فعلناه هو ربط مجموعة من الحلقات. السؤال التالي الآن
00:06:54ينبغي أن يكون: متى أحتاج لاستخدام هندسة الرسم البياني بدلاً من هندسة الحلقات؟
00:06:58لنكن صريحين، فأنت لا تحتاج دائمًا لإنشاء إعداد معقد للغاية متعدد الوكلاء مثل هذا.
00:07:04في كثير من الأحيان، يكون إنشاء حلقة بسيطة كافيًا وزيادة. ولكن هناك ثلاث حالات
00:07:09ستحتاج فيها إلى التفكير في استخدام هندسة الرسم البياني. السيناريو الأول الذي ستحتاج فيه
00:07:15لذلك هو عندما نصل لمشاكل في السياق، وتحديدًا تدهور السياق. إذا كنت أطلب من
00:07:20الوكيل أن يكرر الحلقة مرارًا وتكرارًا، وفي كل حلقة أجعله ينفذ
00:07:25أربع أو خمس أو ست أو سبع أو ثماني مهام، ووصلنا لمرحلة أصبحت فيها نافذة السياق بعد
00:07:29كل تشغيل تتراوح بين 300 و400 و500 ألف رمز، فمن المنطقي تقسيم العمل.
00:07:36لا يوجد سبب يدعونا لتعريض أنفسنا لجودة أدنى بسبب امتلاء نافذة السياق تلك عندما لا نكون مضطرين لذلك.
00:07:41طالما لسنا مضطرين لذلك. أما السيناريو الثاني فهو عندما نحتاج لمراجعة مستقلة. وعندما
00:07:48نتحدث عن الحلقات المناسبة، فإن ما نحتاجه في مرحلة ما هو تقييم النجاح، أي مسألة معايير النجاح
00:07:55تلك. عليك أن تسأل نفسك: هل يمكن للوكيل الذي أنشأ أيًا كان ما ننشئه، وفي هذه الحالة التقرير،
00:08:01هل من المنطقي أن يقيّم التقرير بنفسه ويقول هذا جيد وهذا ليس جيدًا؟ في حالة
00:08:07التقرير الصباحي، يمكنه ذلك على الأرجح. فالأمر ليس بهذه التعقيد ولا ينطوي على خطورة لكي نقول
00:08:13إن هذا التقرير جيد جِدًا، ناهيك عن أنه أمر تقديري نسبيًا. ولكن إذا كان هذا الأمر
00:08:18بالغ الأهمية ونريد طرفًا آخر لإبداء رأيه، فقد نحتاج للجوء إلى سيناريوهات
00:08:24هندسة الرسم البياني حيث نجلب وكيلاً مختلفًا تمامًا لإلقاء نظرة على ما أنشأناه.
00:08:28ربما لا يكون حتى وكيل كود سحابي، بل نموذجًا مثل GPT 5.6.
00:08:32وفي كلتا الحالتين، هذا سيناريو لدينا فيه نوع من التنسيق متعدد الوكلاء وتكون فيه هندسة الرسم البياني
00:08:37منطقية للغاية. والنقطة الثالثة هي التوقيت؛ ما مدى السرعة التي نحتاجها لإنجاز ذلك؟ في هذه الحالة،
00:08:44من المنطقي جدًا استخدام أتمتة قائمة على الرسم البياني، فلماذا أطلب من وكيل
00:08:48واحد البحث في يوتيوب ثم في تويتر ثم في ريديت ثم في جي ميل؟
00:08:52الكود السحابي لا يفعل ذلك حتى. فعندما تشغل بحثًا عميقًا، هل يفرز
00:08:57تلك المصادر ويبحث فيها واحدًا تلو الآخر بالتتابع؟ لا، بل ينشر حوالي مئة
00:09:02وكيل فرعي في وقت واحد للقيام بذلك. وفي الواقع، فإن جميع الأشياء تقريبًا التي ينشئها الكود السحابي
00:09:08عند استخدام الكود المتقدم وسير العمل الديناميكي هي شكل من أشكال هندسة الرسم البياني، حيث لدينا وكلاء متعددون
00:09:13يقومون بجمع المعلومات، ووكلاء متعددون يقومون بالتجميع والتلخيص،
00:09:17ووكلاء متعددون يراجعون المعلومات التي جمعناها مراجعة نقدية. وفي أي مرحلة
00:09:23من هذه الإعدادات المعقدة، نحن لا نعتمد على حلقة واحدة فقط، بل هي شبكة من الوكلاء
00:09:28المعتمدين على الحلقات. ولكن كما قلت في البداية، معظم الأشياء التي ستفعلها لا تندرج تحت أي من هذه
00:09:34الفئات الثلاث. وإذا لم تكن كذلك، فلا يوجد سبب لاستخدام هندسة الرسم البياني. فهي مجرد أداة
00:09:39في صندوق أدواتنا؛ نحتاجها أحيانًا ولا نحتاجها أحيانًا أخرى، ولكن هناك مزايا لاستخدامها.
00:09:44وفي المقابل، هناك عيوب نلجأ فيها لإضافة خطوات وبنية تحتية
00:09:48معقدة لشيء لا يحتاج إليها أساسًا. عند هذا الحد سأنهي
00:09:52حديثي معكم في هذا الفيديو عن هندسة الرسم البياني. أتمنى أن يكون قد أعطاكم فكرة عن ماهية
00:09:57هندسة الرسم البياني فعليًا. أعتقد أنكم ستسمعون الحديث عنها مرارًا وتكرارًا،
00:10:01ولكن إذا فهمتم هندسة الحلقات وفكرتم بها بهذه الطريقة: إنها مجرد وكلاء متعددين يعملون
00:10:07بهندسة الحلقات معًا، ويتحدثون إلى بعضهم البعض، مما يمنح جودتنا
00:10:12دفعة للأمام، ويجعل الأمور أسرع وأسهل بالنسبة لنا لمعرفة ما الخطأ وأين يحدث. وإذا
00:10:17لم تكن تعرف ما إذا كنت بحاجة إليها لمهمتك المحددة، فالإجابة هي “لا” على الأرجح. وكما هو الحال دائمًا،
00:10:24أخبروني برأيكم. واحرصوا على الاطلاع على Chase AI Plus إذا كنتم تريدون الحصول على
00:10:27الدورة التدريبية الشاملة للكود السحابي الخاصة بي. سأضع رابطًا لذلك في الأسفل. وإلى جانب ذلك، أراكم قريبًا.