نظرة عامة

لم يعد اعتماد وكلاء الذكاء الاصطناعي في القطاع المالي خيارًا اختياريًا. مع توسّع نطاق التطبيقات – أتمتة تقييم الائتمان واكتشاف المعاملات المشبوهة ودعم خدمة العملاء – بات على كل مؤسسة مالية أن تحقق هدفَي الكفاءة التشغيلية والامتثال التنظيمي في آنٍ واحد.

تكمن المشكلة في أن منصات الذكاء الاصطناعي الحالية لا تعالج هذين الهدفين معًا. إذ تتمتع واجهات برمجة تطبيقات نماذج اللغة الكبيرة المستندة إلى السحابة بقدرات هائلة، غير أن البيانات تمر عبر خوادم خارجية. وكثيرًا ما تفتقر أطر عمل الوكلاء مفتوحة المصدر إلى مسارات التدقيق أو ضوابط الوصول. في المقابل، تشترط الجهات التنظيمية إمكانية تتبع كل قرار يتخذه الذكاء الاصطناعي، وفقًا للوائح الإشراف المالي الإلكتروني ومعيار ISMS-P وإرشادات معهد أمن المعلومات المالية الكوري.

تتناول هذه المقالة من خلال حالة بنك كوري افتراضي البنية المعمارية التي تُتيح لوكلاء الذكاء الاصطناعي استيفاء اللوائح المالية مع تحقيق أتمتة فعلية للعمليات. ويتمحور ذلك حول آليتَي التحكم في الاستقلالية والإطار التدقيقي المنيع ضد التلاعب.

أوجه توقف المؤسسات المالية عن اعتماد الذكاء الاصطناعي

متطلبات تخزين البيانات محليًا

تحظر المادة 13-2 من لوائح الإشراف المالي الإلكتروني وإرشادات استخدام الحوسبة السحابية الصادرة عن لجنة الخدمات المالية – من حيث المبدأ – معالجة البيانات المالية للعملاء أو تخزينها على خوادم خارجية، أو تشترط الحصول على موافقة مسبقة. قد يؤدي استخدام الذكاء الاصطناعي التوليدي مباشرةً عبر واجهة برمجة تطبيقات خارجية إلى إرسال أرقام الحسابات وسجلات المعاملات وبيانات التعريف الواردة في نصوص الطلبات إلى مراكز بيانات في الخارج. وهذه المسألة وحدها كافية لتوقف كثير من مشاريع إثبات المفهوم لدى المؤسسات المالية.

غياب مسارات التدقيق

إذا تعذّر إعادة إنتاج أساس توصية الذكاء الاصطناعي بحدٍّ ائتماني معين أو تعليقه تلقائيًا لمعاملة مشبوهة، فإن ذلك يمثّل خطرًا جسيمًا في حالات التفتيش الذي يجريه المشرف المالي أو التدقيق الداخلي. وعبارة “قام الذكاء الاصطناعي بذلك” ليست إجابةً مقبولة لدى الجهات التنظيمية. ما يُتطلب هو سجل قابل للاسترجاع زمنيًا يوضح: أي نموذج، بأي مدخلات، استدعى أي أدوات، وأنتج أي مخرجات.

عدم اليقين في التحكم بالوكلاء المستقلين

عند نشر وكلاء يتجاوزون نطاق برامج الدردشة البسيطة – باستدعاء واجهات برمجة تطبيقات خارجية وقراءة الملفات وإرسال رسائل البريد الإلكتروني وتنفيذ أوامر النظام – قد تنشأ تصرفات غير متوقعة إذا لم تُحدَّد بوضوح حدود ما يُسمح للوكيل بفعله. فإذا أجرى وكيل مستقل في القطاع المالي معاملاتٍ بسبب استقلالية مفرطة أو خاطئة، فقد يفضي ذلك إلى خسائر مالية فضلًا عن انتهاكات تنظيمية.

تعدد المستأجرين والعزل الداخلي

حتى حين تتشارك أقسام الأوراق المالية والتأمين والأمانة البنية التحتية ذاتها للذكاء الاصطناعي، يجب أن تكون بيانات كل فريق وسجلات تدقيقه معزولةً عزلًا تامًا. فإن تمكّن وكيل أحد الأقسام من الوصول إلى بيانات عملاء قسم آخر أو سجلات معاملاته، فذلك يُشكّل انتهاكًا لمبادئ الرقابة الداخلية.

البنية المعمارية للحوكمة: محرك السياسات ومصفوفة الاستقلالية × المخاطر

لماذا يجب وجود محرك سياسات

إعطاء وكيل أداةً (Tool) وضبط استخدام تلك الأداة بصورة آمنة مسألتان مختلفتان. فمجرد ضبط إعداد “يُسمح لهذا الوكيل باستخدام واجهة برمجة تطبيقات استعلام العملاء” لا يمنع الوكيل من تنفيذ آلاف الاستعلامات تتاليًا بسبب خطأ في التقدير، أو الاطلاع بصورة مفرطة على حقول بيانات حساسة.

يتحقق محرك سياسات Praxis من بُعدَين متقاطعَين قبل تنفيذ أي استدعاء لأداة.

4 مستويات للاستقلالية:

• L0 (يدوي بالكامل): يقترح الوكيل فقط، ويوافق الإنسان على كل عملية تنفيذ.
• L1 (استقلالية منخفضة المخاطر): يُنفَّذ تلقائيًا للمهام القائمة على القراءة فحسب والمهام غير المالية.
• L2 (استقلالية متوسطة المخاطر): تُنفَّذ المعاملات دون الحد المحدد مسبقًا تلقائيًا، وتُطلب الموافقة عند تجاوزه.
• L3 (استقلالية عالية): تنفيذ مستقل واسع النطاق ضمن النطاق الذي يسمح به محرك السياسات.

7 درجات للمخاطر:

تُصنَّف استدعاءات الأدوات من الدرجة 1 (استعلام بسيط) إلى الدرجة 7 (معاملة خارجية غير قابلة للعكس) وفقًا للمخاطر. مثلًا، الاستعلام عن رصيد العميل يقع في الدرجة 1، بينما تنفيذ تحويل بين الحسابات يقع في الدرجتين 6-7. لكل أداة مضمّنة درجة مخاطر مسجّلة مسبقًا، وتُحجب الأدوات غير المسجّلة تلقائيًا بصورة افتراضية.

تدفق قرار السياسة

flowchart TD
    A[طلب استدعاء أداة الوكيل] --> B{أداة غير مسجّلة؟}
    B -- نعم --> C[حجب افتراضي + سجل تدقيق]
    B -- لا --> D[البحث عن درجة المخاطر]
    D --> E{مستوى الاستقلالية × مصفوفة المخاطر}
    E -- مسموح --> F[تنفيذ الأداة]
    E -- مسموح بشرط --> G[طلب موافقة المسؤول]
    E -- مرفوض --> H[حجب التنفيذ + سجل تدقيق]
    G -- موافقة --> F
    G -- رفض/انتهاء المهلة --> H
    F --> I[إرجاع النتيجة + تسجيل حدث التدقيق]
    C --> J[إضافة كتلة إلى سلسلة التدقيق]
    H --> J
    I --> J

حالة افتراضية: وكيل تقييم الائتمان في بنك A

يرغب بنك A في نشر وكيل ذكاء اصطناعي لتقييم ائتمان الشركات الصغيرة والمتوسطة. المهام التي يؤديها الوكيل هي التالية:

1. الاستعلام عن المعلومات الائتمانية للشركات من نظام استعلام الائتمان NICE (درجة المخاطر 2)
2. الاستعلام من قاعدة بيانات سجلات القروض الداخلية (درجة المخاطر 1)
3. تحليل القوائم المالية والتوصية بالحد الائتماني (حكم فقط، دون تنفيذ خارجي)
4. صياغة مسودة رأي التقييم الائتماني (توليد مستند)
5. استدعاء واجهة برمجة تطبيقات تسجيل الحد عند الموافقة (درجة المخاطر 6)

في هذه الحالة، يُضبط مستوى استقلالية الوكيل على L2. تُنفَّذ المهام 1-4 تلقائيًا، لكن استدعاء واجهة برمجة تطبيقات تسجيل الحد (المهمة 5) ذو الدرجة 6 يستلزم موافقة المسؤول المختص. يستحيل هيكليًا أن يسجّل الوكيل الحد مباشرةً دون موافقة.

تُشترط موافقة المسؤول لتسع عمليات عالية المخاطر (إلغاء الحساب والتحويلات الجماعية وتغييرات تكامل الأنظمة الخارجية وغيرها) بصرف النظر عن مستوى الاستقلالية.

التدقيق والتتبع: سجلات سلسلة التجزئة وإخفاء البيانات الشخصية

آلية عمل سجلات تدقيق سلسلة التجزئة

صُمّم إطار التدقيق في Praxis بنية سلسلة التجزئة (Hash Chain). يحتوي كل حدث تدقيق على قيمة التجزئة (Hash) للحدث السابق، لذا فإن حذف أي سجل وسيط أو تعديله يُفشل التحقق من التجزئة لجميع الكتل اللاحقة. تُتيح هذه البنية اكتشاف التلاعب حتى لو حاول مسؤول قاعدة البيانات تغيير السجلات عن طريق الخطأ أو عمدًا.

يتجاوز عدد أنواع الأحداث المسجّلة 20 نوعًا، وأبرزها:

• agent.tool.invoked: طلب استدعاء الأداة (معرّف الوكيل واسم الأداة وسياق التنفيذ)
• agent.tool.policy.denied: الحجب بواسطة محرك السياسات (درجة المخاطر ومستوى الاستقلالية وأساس القرار)
• agent.tool.approval.requested: نشوء طلب موافقة المسؤول
• agent.tool.approval.decided: نتيجة الموافقة/الرفض (معرّف متخذ القرار والطابع الزمني)
• agent.session.started: بدء جلسة الوكيل (معرّف الفريق ومعرّف الوكيل ومعرّف الجلسة)
• sandbox.exec: حدث تنفيذ الكود داخل بيئة الحماية (Sandbox)

يُفهرس كل حدث بـ run_id، مما يُتيح الاستعلام وإعادة إنتاج جميع استدعاءات الأدوات وقرارات السياسة وسجلات الموافقة التي تُشكّل تدفق معالجة تقييم ائتماني واحد تحت run_id واحد. تُحفظ سجلات التدقيق لمدة 90 يومًا أو أكثر.

الإخفاء التلقائي لـ 16 فئة من البيانات الشخصية

قد تحتوي البيانات التي يعالجها الوكيل على معلومات شخصية كأرقام تسجيل السكان وأرقام الحسابات وأرقام الهواتف وعناوين البريد الإلكتروني. تكتشف طبقة حماية النصوص في Praxis أنماط 16 فئة من البيانات الشخصية في الوقت الفعلي في مرحلة الإدخال وتُخفيها تلقائيًا.

مثلًا، إذا كان نتيجة استعلام معلومات العميل يحتوي على رقم تسجيل السكان، فإنه يُستبدل بـ [رقم تسجيل السكان مُخفى] قبل أن ينقله الوكيل إلى نموذج اللغة الكبيرة. وبما أن سجلات التدقيق تُسجّل الصيغة المُخفاة فحسب دون البيانات الأصلية، ينخفض خطر كون السجلات نفسها مسارًا لتسريب البيانات الشخصية.

كذلك يكتشف النظام 11 نمطًا من أنماط هجمات حقن النصوص (تبديل الأدوار وتجاهل التعليمات ومحاولات التهرب وغيرها) في الوقت الفعلي لمنع محاولات إساءة تشغيل الوكيل من خلال مدخلات ضارة.

عزل تعدد المستأجرين

حتى حين يستخدم قسم الائتمان وقسم إدارة الأصول في بنك A المثيل ذاته من Praxis، تُعزل الويكي والجلسات والإعدادات وسجلات التدقيق عزلًا تامًا استنادًا إلى معرّفات الفريق (Team IDs). إذا حاول وكيل فريق الائتمان الوصول إلى بيانات عملاء فريق إدارة الأصول، تُجيب البيانات نفسها بـ “غير موجود”، دون الكشف حتى عن وجودها.

دلالات تطبيق ThakiCloud

النشر المحلي + المعزول لتحقيق متطلبات تخزين البيانات محليًا

يمكن نشر منصة ThakiCloud AI Platform مباشرةً في الشبكة الداخلية لمركز معالجة البيانات التابع للمؤسسة المالية على أساس Kubernetes. إذ تجري جميع عمليات الاستنتاج داخل المؤسسة، فلا تُنقل المعلومات المالية للعملاء خارجها. يتضمن خارطة طريق Praxis مجموعة نشر معزولة (Air-Gap) [تقديري: الربع الأول من 2027]، مع خطط لدعم التكوينات التي تعمل باستقلالية حتى في البيئات المغلقة حيث تُحجب الشبكات الخارجية كليًا.

تُنشر البنية التحتية للمراقبة (VictoriaMetrics/VictoriaLogs) أيضًا على الشبكة الداخلية، مما يُتيح مراقبة عمليات الوكيل والتكاليف والسلوكيات الشاذة في الوقت الفعلي.

تكامل Keycloak OIDC RBAC مع أدلة المستخدمين الحالية

تُشغّل المؤسسات المالية عمومًا أدلة موظفين قائمة على AD (Active Directory) أو LDAP. تتكامل منصة ThakiCloud AI Platform مع الأدلة الحالية من خلال تكامل OIDC عبر Keycloak، بحيث تنعكس فورًا على المنصة تغييراتُ إنشاء حسابات الموظفين وحذفها وتعديل صلاحياتها. يمنع هذا نظام بقاء حسابات الموظفين المستقيلين محتفظةً بصلاحية الوصول إلى وكلاء الذكاء الاصطناعي.

ربط محرك السياسات بأطر الرقابة الداخلية

يمكن تعيين مصفوفة الاستقلالية × المخاطر مباشرةً على إطار الرقابة الداخلية للمؤسسة المالية. مثلًا، يمكن تطبيق مبدأ “موافقة شخصَين أو أكثر على العمليات الحرجة” الذي تشترطه معايير الرقابة الداخلية للجنة الخدمات المالية بوصفه قاعدةً إلزامية للموافقة على العمليات عالية المخاطر في محرك السياسات.

يستطيع فريق التدقيق الاستعلام عن كامل سجل المعالجة لقضية ائتمانية بعينها باستخدام run_id، والاطلاع على شاشة واحدة على البيانات التي رجع إليها الوكيل والقرارات التي اتخذها محرك السياسات وهوية المعتمد. يُسهم هذا في ضمان إمكانية التحقق اللاحق من سلوك الذكاء الاصطناعي بالمستوى المطلوب في عمليات تفتيش هيئة الإشراف المالي.

تحسين التكاليف عبر موجّه نماذج اللغة الكبيرة

يستطيع موجّه نماذج اللغة الكبيرة الذي يدعم أكثر من 10 مزودين لنماذج اللغة الكبيرة إضافةً إلى نموذج Metis الخاص بـ ThakiCloud تقييد المؤسسات المالية باستخدام نماذج محددة حصلت على موافقة أمنية فحسب، أو توجيه نماذج اقتصادية في التكلفة ونماذج عالية الدقة تلقائيًا وفقًا لنوع المهمة. يُحقق التكوين الهجين الذي يستخدم Metis المحلي كخلفية استنتاج أساسية والمزودين الخارجيين كاحتياط فحسب متطلبات تخزين البيانات محليًا وكفاءة التكاليف في آنٍ واحد.

القيود والاعتبارات

يلزم تقييم صادق. بالرغم من تطور البنية المعمارية، توجد قيود واقعية.

عدم اليقين في تفسير الأنظمة: لا تزال الأنظمة المحلية المتعلقة بحوكمة الذكاء الاصطناعي في القطاع المالي في طور التطور. كثيرًا ما لا تُحدد أحكام توظيف الذكاء الاصطناعي في لوائح الإشراف المالي الإلكتروني وإرشادات أمن الذكاء الاصطناعي الصادرة عن معهد أمن المعلومات المالية الكوري المتطلبات التقنية التفصيلية، لذا يستلزم الامتثال الفعلي التشاور المسبق مع فرق القانون والجهات التنظيمية. لا يُضمن أن سجلات التدقيق ومحرك السياسات التي توفرها Praxis تستوفي متطلبات تنظيمية بعينها؛ ويستلزم هذا مراجعةً منفصلة لكل مؤسسة.

شهادة SOC 2 Type II: خارطة طريق شهادة SOC 2 Type II لـ Praxis مجدولة للربع الثاني من 2027 أو ما بعده. يجب على المؤسسات المالية التي تشترط حاليًا شهادة SOC 2 Type II مراعاة هذا الجدول الزمني.

تعقيد تصميم السياسات: مصفوفة الاستقلالية × المخاطر أداة قوية، لكن تصميمها بصورة صحيحة لتتناسب مع عمليات المؤسسة يتطلب قدرًا كبيرًا من المعرفة المتخصصة والوقت. إذا كان التصميم الأولي للسياسة معيبًا، فستنشأ مشكلات إما لأن الوكيل يحجب عمليات كثيرة جدًا (قيود مفرطة) أو يتمتع باستقلالية مفرطة (تساهل مفرط). النشر المتدرج والتعديل القائم على بيانات التشغيل ضروريان.

عدم قابلية التنبؤ بسلوك الوكيل: يوفر محرك السياسات التحكم على مستوى استدعاء الأدوات، لكنه لا يتحكم كليًا في عملية استنتاج نموذج اللغة الكبيرة ذاتها. حتى حين يستخدم الوكيل أدواتٍ مسموحًا بها بموجب السياسة فحسب، قد ينفذها بتسلسلات أو تركيبات غير متوقعة. لا سيما في العمليات التي تُعدّ فيها دقة الحكم أمرًا حرجًا كتقييم الائتمان، يجب تعريف وكلاء الذكاء الاصطناعي بوضوح بوصفهم داعمةً لاتخاذ قرار المسؤول المختص – لا حاملةً لسلطة القرار النهائي.

العبء التقني للعمليات المحلية: تشغيل بيئة Kubernetes المحلية يستلزم قدرات تشغيل بنية تحتية أعلى بكثير مقارنةً بالخدمات السحابية كاملة الخدمة. يلزم وجود كوادر متخصصة طوال دورة التشغيل بأكملها – إدارة ArgoCD GitOps وإدارة Keycloak ونشر تحديثات النماذج وغير ذلك. ينبغي مراجعة هذا الجانب جنبًا إلى جنب مع عقد دعم التشغيل مع ThakiCloud أو خطة بناء قدرات داخلية.

اعتماد وكلاء الذكاء الاصطناعي في القطاع المالي ليس مسألة تقنية – بل هو مسألة حوكمة. ما يقع في صميمها هو: أين تُخزَّن البيانات، وإلى أي حد يمكن للوكيل التصرف باستقلالية، وهل تُسجَّل جميع تلك التصرفات بطريقة قابلة للتحقق؟ يقدم محرك السياسات وسجلات التدقيق بسلاسل التجزئة إجاباتٍ تقنية عن هذه الأسئلة الثلاثة، لكن ينبغي أن نُذكّر أنفسنا بأن هذا ليس كل ما يعنيه الامتثال التنظيمي.

نظرة عامة

يواجه التصنيع الحديث تناقضاً هيكلياً: رغبة عالية في تبني الذكاء الاصطناعي، لكن نقصاً حاداً في الكوادر التشغيلية. حتى حين تريد المصانع نشر نماذج فحص بصري على خطوط الإنتاج، تفتقر إلى متخصصي MLOps القادرين على صيانة تلك النماذج وخدمتها وإعادة تدريبها. ومع إدارة ثلاث مجموعات GPU في مصانع مختلفة من فرق منفصلة، يتكرر هدر الموارد وتوقف الإنتاج في حلقة مفرغة.

يوضح هذا المقال كيف تحل فرق العملاء الذكيين المستقلين متعددي الأدوار هذه المشكلة، وكيف يمكن توحيد مجموعات GPU الموزعة عبر مصانع متعددة تحت مستوى تحكم واحد – وذلك من خلال دراسة حالة الشركة التصنيعية الافتراضية “HanTek”. التقنيات الأساسية التي يتناولها المقال هي الإدارة المركزية متعددة المجموعات في ThakiCloud AI Platform وسحابة عمليات العملاء Praxis.

اختناق الكوادر في عمليات الذكاء الاصطناعي التصنيعي

HanTek شركة تصنيع مكونات إلكترونية متوسطة الحجم تشغّل مجموعات GPU في مرافق بمدن أولسان وغومي وغوانغجو. على مدى العامين الماضيين، نشرت الشركة نماذج الذكاء الاصطناعي البصري على كل خط مصنع، غير أن ثلاث مشكلات متكررة برزت في العمليات.

أولاً، نقص حاد في كوادر MLOps. تتطلب إعادة تدريب النماذج ونشرها ومراقبة أدائها مهندسين متخصصين. فريق ML في HanTek المكون من ثلاثة مهندسين عجز عن إدارة دورة حياة النماذج عبر المصانع الثلاثة. حتى حين يبدأ أداء النماذج بالتراجع، كانت طلبات إعادة التدريب تنتظر في قائمة الانتظار لأيام.

ثانياً، إدارة متشظية لمجموعات متعددة. كانت مجموعة GPU لكل مصنع تعمل باستقلالية تامة. نشأت مواقف تُقف فيها مهام التدريب في غومي في قائمة الانتظار بينما مجموعة أولسان خاملة، مما يستلزم التنسيق اليدوي عبر Slack. كانت مقاييس DCGM أيضاً تُجمع بشكل منفصل لكل مصنع، مما يجعل من المستحيل رؤية معدل استخدام GPU على مستوى الشركة بنظرة واحدة.

ثالثاً، استحالة الاستجابة على مدار الساعة. عند اكتشاف شذوذات الجودة في خطوط العمل الليلية أو في عطلات نهاية الأسبوع، لم يكن فريق ML قادراً على الاستجابة الفورية. كانت التنبيهات تصل، لكن المعالجة الفعلية تُؤجل إلى صباح اليوم التالي – مع احتمال وصول المنتجات المعيبة إلى المرحلة الإنتاجية التالية في غضون ذلك.

هذه المشكلات ليست حكراً على HanTek. عبر قطاع التصنيع، يتكرر نمط واحد: تبني الذكاء الاصطناعي، لكن القدرات التشغيلية لا تواكب التطور، مما يُنصّف الفعالية.

تكوين فريق العملاء المستقل – تعدد الأدوار والمهام الديناميكية

الحل الذي اعتمدته HanTek هو فريق عملاء ذكيين مستقلين متعددي الأدوار مبني على Praxis. Praxis سحابة عمليات تُعامل العملاء كموارد من الدرجة الأولى “مثل الأجهزة الافتراضية على AWS”. المهارات والأدوات والسياسات وسجلات التدقيق هي الموارد الأساسية للمنصة، ويرجع كل عميل إلى ويكي نطاقه (محرك المعرفة الهجين، HKE) لاتخاذ القرارات استناداً إلى المعرفة المتراكمة.

كوّنت HanTek فريق العملاء بثلاثة أدوار.

عميل عمليات البنية التحتية

يتولى عميل عمليات البنية التحتية مراقبة حالة مجموعات GPU، وتحسين جدولة المهام، والاسترداد التلقائي عند اكتشاف الشذوذات. يجمع مقاييس Kueue وKAI Scheduler باستمرار، ويتخذ قراراً مستقلاً بإعادة توزيع المهام على مجموعة أخرى حين يتجاوز وقت انتظار قائمة الانتظار في مجموعة معينة الحد المسموح.

يُنفذ هذا العميل المهام المتكررة المعرّفة بلغة طبيعية – مثل “توليد تقرير استخدام GPU كل صباح الساعة السابعة” – عبر مجدول المهام الديناميكي في Praxis. لم يعد المشغلون بحاجة إلى كتابة نصوص cron منفصلة؛ يكفي إدخال مواصفات المهمة في المحادثة أو Slack ليجدول العميل نفسه.

عميل جودة النماذج (شخصية محلل المعايير)

يراقب عميل جودة النماذج باستمرار أداء نماذج الذكاء الاصطناعي البصري على كل خط. يحلل مقاييس زمن الاستدلال والدقة المجمّعة من VictoriaMetrics، ويُشغّل خط أنابيب إعادة التدريب تلقائياً حين يتجاوز تدهور الأداء الحد المحدد. بعد اكتمال إعادة التدريب، ينشر ملخص نتائج المعايير في قناة Slack لفريق ML.

يرجع هذا العميل إلى سجل النماذج المتراكم خط بخط في HKE. المعرفة بالنطاق مثل “نموذج هذا الخط يحتاج إعادة تدريب كل ثلاثة أشهر، ومعيار الدقة الأساسي 98.5% أو أعلى” موثقة في الويكي، مما يُمكّن العميل من اتخاذ قرارات ذات سياق واعٍ.

عميل تقارير العمليات (شخصية أتمتة التقارير)

يُولّد عميل تقارير العمليات تلقائياً تقارير تشغيل الذكاء الاصطناعي اليومية والأسبوعية والشهرية ويوزعها. يجمع معدل استخدام GPU وعدد حالات الاستدلال لكل نموذج وأحداث اكتشاف شذوذات الجودة وحالة إعادة التدريب، ثم يُنسّقها في شكل يسهل على الإدارة قراءته. تُنشر التقارير في Slack والبريد الإلكتروني ولوحات الويب في آن واحد عبر قدرة التسليم متعدد القنوات في Praxis.

هيكل تعاون فريق العملاء

يعمل العملاء الثلاثة باستقلالية، لكنهم يتعاونون عند الحاجة عبر تنسيق العملاء المتعددين في Praxis. على سبيل المثال، حين يُشغّل عميل جودة النماذج إعادة التدريب، يحدث تفويض تلقائي عبر العملاء – يطلب من عميل عمليات البنية التحتية تأمين طاقة مجموعة GPU للتدريب. تُسجّل عملية التفويض هذه جميع قرارات صنع القرار عبر محرك السياسات وسجل التدقيق.

الإدارة المركزية متعددة المجموعات – توحيد GPU عبر مصانع متعددة

لكي يعمل فريق العملاء بشكل صحيح، يجب إدارة مجموعات GPU عبر مصانع متعددة مركزياً تحت مستوى تحكم واحد. نظام Multi-Cluster Cloud (MCC) في ThakiCloud AI Platform يؤدي هذا الدور.

المخطط التالي تبسيط للهيكل الفعلي لـ HanTek.

graph TB
    subgraph CP["ThakiCloud Control Plane (HA 3-replica)"]
        CP0[CP-0 Leader]
        CP1[CP-1 Follower]
        CP2[CP-2 Follower]
        VK[(Valkey Leader Election 3s TTL)]
        CP0 --- VK
        CP1 --- VK
        CP2 --- VK
    end

    subgraph PRAXIS["Praxis Agent Operations Cloud"]
        INFRA[Infrastructure Operations Agent]
        QA[Model Quality Agent]
        REPORT[Operations Report Agent]
        HKE[(HKE Per-Team Wiki RAG)]
        INFRA --- HKE
        QA --- HKE
        REPORT --- HKE
    end

    CP -->|"gRPC Bidirectional Stream"| US[Ulsan MCC Agent\nGPU Cluster Inference-Only]
    CP -->|"gRPC Bidirectional Stream"| GU[Gumi MCC Agent\nGPU Cluster Training-Only]
    CP -->|"gRPC Bidirectional Stream"| GJ[Gwangju MCC Agent\nGPU Cluster Dev/Mixed]

    PRAXIS -->|"Kueue Cross-Cluster Scheduling\nModel Retraining Trigger\nDCGM Metrics Collection"| CP

    US --> DCGM1[DCGM Exporter\nVictoriaMetrics]
    GU --> DCGM2[DCGM Exporter\nVictoriaMetrics]
    GJ --> DCGM3[DCGM Exporter\nVictoriaMetrics]

فصل مستوى التحكم عن مستوى البيانات

تفصل ThakiCloud AI Platform بصرامة بين مستوى التحكم (CP) ومستوى البيانات (DP). يكتسب هذا الفصل أهمية في بيئات التصنيع لأن مهام الاستدلال على خطوط المصنع تستمر في التشغيل حتى حين يواجه CP عطلاً. يعمل الذكاء الاصطناعي البصري في مصنع أولسان دون انقطاع أثناء فصل شبكة CP تحديداً بفضل هذه البنية.

يُنشر وكيل MCC في كل مجموعة مصنع. يتواصل هذا الوكيل مع CP عبر تدفق gRPC ثنائي الاتجاه، ويحافظ على الاتصال من خلال إعادة الاتصال بأسلوب Make-Before-Break حتى حين تحدث تأخيرات في الشبكة. حتى حين تُقطع وصلة WAN كلياً، لا تتأثر مهام مستوى البيانات.

جدولة GPU متعددة المجموعات عبر Kueue وKAI Scheduler

تُدير كل مجموعة مصنع أحمال عمل GPU عبر Kueue وKAI Scheduler. يحسب KAI Scheduler درجات المجموعات البينية بترتيب GPU > CPU > ذاكرة > قرص لتحديد التوزيع الأمثل. يقرأ عميل عمليات البنية التحتية مقاييس هذا المجدول، وعند اكتشاف إشارات مثل “وقت انتظار قائمة تدريب مجموعة أولسان يتجاوز 30 دقيقة”، يقترح إعادة توزيع المهام على مجموعة غومي أو يُنفّذها تلقائياً [تقديري].

حين يتجاوز استخدام GPU باستمرار 80% من متوسط المجموعة، يُشغَّل تنبيه VictoriaMetrics ويُولّد عميل عمليات البنية التحتية تقرير توصية بتوسيع الطاقة، ثم ينشره في قناة فريق ML.

تكامل تيليمتري GPU المستندة إلى DCGM

يجمع مُصدِّر DCGM (مدير GPU لمراكز البيانات) في كل مجموعة تيليمتري GPU في VictoriaMetrics. كانت HanTek في السابق تضطر لمشاهدة لوحات Grafana منفصلة مُهيأة لكل مصنع على حدة، لكن VictoriaLogs وVictoriaMetrics توفران الآن طبقة مراقبة واحدة مجمّعة مركزياً. يستعلم عميل جودة النماذج مباشرة عن هذه المقاييس لاكتشاف شذوذات زمن الاستدلال.

GitOps لـ ArgoCD واتساق المجموعات

تُدار عمليات نشر النماذج وتغييرات التهيئة في المجموعات الثلاث للمصانع كلها عبر ArgoCD باستخدام نهج GitOps. حين يُسجَّل وكيل MCC في مجموعة جديدة، يُنشأ سر مجموعة ArgoCD تلقائياً. حين يكتشف عميل تقارير العمليات تحديثاً لنموذج معين، يُنشئ PR في مستودع Git المقابل [تقديري]، وينشر ArgoCD تلقائياً على كل مجموعة مصنع.

دلالات التطبيق لـ ThakiCloud

الدروس التطبيقية العملية المستخلصة من حالة HanTek هي التالية.

نهج جوهري لحل اختناقات الكوادر. فرق العملاء متعددي الأدوار ليست مصممة لاستبدال مهندسي MLOps، بل لتفويض المهام المتكررة للمراقبة وإعداد التقارير. يُركز المهندسون على العمل عالي القيمة مثل تحسين بنية النماذج وتحليل حالات الشذوذ، بينما يتولى العملاء العمليات اليومية. القيمة طويلة الأمد تنشأ من حقيقة أن دقة حكم العميل تزداد كلما تراكمت المعرفة بالنطاق في ويكي HKE.

مرونة تشغيلية عبر مجدول المهام الديناميكي. يتيح مجدول المهام الديناميكي في Praxis تعريف المهام بلغة طبيعية، مما يُمكّن مشغلي الميدان من إعداد الأتمتة مباشرة دون المرور عبر قسم تقنية المعلومات. يمكن تطبيق متطلبات تشغيلية محددة فوراً، مثل “إرسال تقرير ملخص لشذوذات الجودة خلال الأسبوع الماضي إلى البريد الإلكتروني لرؤساء الفرق كل إثنين الساعة الثامنة صباحاً”.

تحقيق الرؤية عبر تكامل المجموعات المتعددة. توفر إدارة المجموعات المتعددة عبر مستوى تحكم واحد رؤية فورية لمعدل استخدام GPU على مستوى الشركة وحالة قوائم انتظار المهام والتكاليف لكل مجموعة. يمكن الآن تهيئة سياسات كانت مستحيلة في السابق على مستوى مستوى التحكم – مثل “السماح تلقائياً بمهام تدريب جديدة حين يقل معدل استخدام GPU المجمّع عبر المصانع الثلاثة عن 60%”.

موثوقية محرك السياسات وسجلات التدقيق. في بيئات التصنيع، تُعدّ قابلية تتبع القرارات التي يتخذها الذكاء الاصطناعي أمراً بالغ الأهمية. يُسجّل محرك السياسات وسجل التدقيق في Praxis جميع إجراءات العملاء ويُبقي على سجل قابل للتدقيق يوضح الإجراءات المتخذة ومسوّغاتها. هذا يُقدم مساعدة عملية في الوفاء بمتطلبات تدقيق شهادات الجودة والامتثال الداخلي.

القيود والاعتبارات

لا ينطبق هذا النهج بشكل موحد على جميع بيئات التصنيع. ثمة قيود عملية يجب فحصها قبل التبني.

تكلفة بناء المعرفة بالنطاق الأولية. يتطلب بناء المعرفة بالنطاق في ويكي HKE التي سيستخدمها العملاء استثماراً مسبقاً. يجب توثيق المعرفة الضمنية مثل خصائص النماذج المحددة للخط ونطاقات التشغيل الطبيعية ومعايير إعادة التدريب بشكل صريح. قد يؤدي نشر العملاء دون هذا التحضير إلى أخطاء في الحكم المبكر.

تحديد نطاق استقلالية العميل. يجب تحديد نطاق القرارات التي يمكن للعملاء اتخاذها باستقلالية بوضوح. تُناسب مُشغّلات إعادة تدريب النماذج وتوليد التقارير التنفيذ المستقل، لكن استبدال النماذج وإعادة تهيئة المجموعات التي تؤثر على خطوط الإنتاج يكون أكثر أماناً إذا احتفظت بخطوات موافقة بشرية. يتيح محرك السياسات في Praxis تهيئة هذه الحدود.

واقع بيئات الشبكات. في بيئات مصانع الصناعة الثقيلة المحلية، كثيراً ما تكون سياسات جدار الحماية للاتصالات بين شبكات المصانع الداخلية والسحابة صارمة. يجب التحقق مسبقاً مما إذا كانت اتصالات gRPC لوكيل MCC مسموحاً بها وما إذا كان عرض نطاق WAN مستقراً. بالنسبة للبيئات المحلية الخالصة، يجب أخذ تهيئة نشر كلٍّ من CP وDP في الموقع بعين الاعتبار.

تعقيد تعاون العملاء. يُنشئ تنسيق العملاء المتعددين سيناريوهات عطل أكثر تعقيداً مقارنة بعميل واحد. يجب تصميم سياسات التراجع وأنظمة التنبيه لمعالجة الحالات التي يُرسل فيها عميل تفويضاً خاطئاً عبر العملاء. على الرغم من أن خط أنابيب Plan-Execute في Praxis يُنظّم التنفيذ في ثلاث مراحل – المخطط والمُنفّذ والمُولّف – يظل الاختبار الكافي لحالات الشذوذ أمراً ضرورياً.

الاكتساب التدريجي للنضج التشغيلي. لا يُنصح بتفويض جميع العمليات للعملاء منذ البداية. النهج التدريجي أكثر واقعية: ابدأ بمهام ذات مخاطر منخفضة كأتمتة التقارير، وتحقق من جودة حكم العميل، ووسّع الاستقلالية فقط بعد ترسّخ الثقة.

اختناق الكوادر في عمليات الذكاء الاصطناعي التصنيعي لا يُحل ببساطة بتوظيف المزيد من الأشخاص. الاتجاه المستدام لعمليات الذكاء الاصطناعي التصنيعي هو هيكل تتولى فيه فرق العملاء المستقلين المهام التشغيلية المتكررة، وتُقلل الإدارة المركزية متعددة المجموعات من هدر موارد GPU، ويُركز البشر على القرارات والتحسينات الأكثر تعقيداً. توفر ThakiCloud AI Platform وPraxis الوسائل التقنية الملموسة لتنفيذ هذا الهيكل.

في يناير 2026، خلال منتدى دافوس الاقتصادي العالمي، ألقى داريو أمودي، الرئيس التنفيذي لشركة Anthropic، جملةً قصيرة في حوار أجرته معه رئيسة تحرير صحيفة وول ستريت جورنال إيما تاكر.

قال إن البرمجيات ستصبح “رخيصة”، وربما “مجانية في جوهرها”. ما يعني أن الفرضية الأساسية لنموذج البرمجيات كخدمة — استرداد تكاليف التطوير بتوزيعها على ملايين المستخدمين — قد لا تنطبق بعد الآن.

(الاقتباس الأصلي بالإنجليزية: “Software is going to become cheap, maybe essentially free” — «ستصبح البرمجيات رخيصة، وربما مجانية في جوهرها» — مقابلة WSJ/دافوس، يناير 2026)

نموذج توظيف عشرات المهندسين، وبناء منتج على مدى سنوات، وبيعه لملايين المستخدمين — كان هذا تحذيراً من أن أساسه الاقتصادي بات يتزعزع.

في السياق ذاته، قال أمودي شيئاً آخر: إن الذكاء الاصطناعي سيضغط 100 عام من التغيير الاقتصادي في غضون 5 إلى 10 سنوات، وقد يكون الصدى “مؤلماً بشكل غير اعتيادي” (unusually painful). (CNBC، 27 يناير 2026)

مستقبل فرق الهندسة معلّق بين هذين التصريحين.

ماذا يحدث حين تقترب التكلفة الحدية من الصفر

في الاقتصاد، التكلفة الحدية هي تكلفة إنتاج وحدة إضافية. استفادت صناعة البرمجيات طويلاً من شبه انعدام تكلفة نسخ المنتجات الرقمية — اكتب الكود مرة، انسخه ملايين المرات دون تكلفة إضافية.

ما يصفه أمودي هو المرحلة التالية: ماذا يحدث حين تقترب تكلفة إنشاء البرمجيات نفسها من الصفر.

البوادر موجودة بالفعل. أدوات مثل GitHub Copilot وCursor وClaude Code تخفض بسرعة تكلفة توليد الكود. بناء هياكل تطبيقات CRUD، وكتابة الاختبارات، واستخراج التوثيق — المهام المتكررة تزداد رخصاً يوماً بعد يوم.

حين تتقارب هذه التكاليف مع الصفر، أين تبقى الميزة التنافسية لما يبنيه المهندسون؟

ليس في القدرة على كتابة الكود. بل في القدرة على الحكم على ما يجب كتابته. هناك تبقى.

لماذا تغيّر موقف أمودي؟

يستحق الأمر الإشارة إلى أن تصريحات أمودي نفسها تحولت بشكل ملحوظ في غضون أشهر قليلة.

في مقالة على CNBC في يناير 2026، حذّر من أن صدمة سوق العمل ستكون “مؤلمة بشكل غير اعتيادي”. ثم في مايو 2026، وقبيل الطرح العام الأولي لـ Anthropic، أزاح ثقله نحو مفهوم “التعزيز” (augmentation). نقلت مجلة Fortune هذا التحول باعتباره تراجعاً عن نبوءات “نهاية الوظائف بسبب الذكاء الاصطناعي” (walking back). (Fortune، 26 مايو 2026)

التصريحان ليسا متناقضين — يجب قراءتهما معاً. الألم قادم على المدى القصير؛ ستُعاد تعريف الأدوار على المدى المتوسط والبعيد. لكن إعادة التعريف لن تحدث من تلقاء نفسها. هذا هو جوهر المسألة.

في مقابلة مايو قال أيضاً: “there are jobs that took generations to build that may disappear” («ثمة وظائف استغرق بناؤها أجيالاً قد تختفي»). لم يكن هذا تحذيراً من فقدان الوظائف بل من اختفاء هياكل المسارات المهنية بأكملها.

هذا ليس سيناريو الرعب القائل بأن “جميع المطورين سيصبحون غير ضروريين”. إنها قصة أكثر إزعاجاً: نصف عمر الخبرة المتراكمة حتى الآن يتقلص بشكل مثير للقلق.

ما يختفي وما يبقى

حين تنخفض التكلفة الحدية للبرمجيات، ما يتعرض للتهديد أولاً هو أعمال التنفيذ المتكررة. ترجمة الأنماط المعروفة إلى كود، ودمج المكونات الموجودة، وتنفيذ المواصفات حرفياً — تتعامل أدوات الذكاء الاصطناعي مع هذه المهام بشكل متزايد.

حتى مع انخفاض تكاليف توليد الكود، ثمة قيمة لا تختفي. ثلاث فئات تبرز:

القدرة على اختيار المشكلة الصحيحة. معرفة ما يجب بناؤه أصعب بكثير من معرفة كيف يُبنى. القدرة على رصد الفجوة بين ما يقوله المستخدمون وما يريدونه فعلاً، واختيار من بين مئات المميزات المحتملة تلك التي يجب بناؤها الآن — هذه أحكام يصعب على الخوارزميات استبدالها. كلما انخفضت تكلفة البناء، ازداد الثقل النسبي لقرار ما يجب بناؤه.

التحقق والذوق. مع تكاثر الكود المولَّد بالذكاء الاصطناعي، تصبح القدرة على الحكم على صحته كفاءة محورية. ليس مجرد اكتشاف الأخطاء. هل سيظل هذا التصميم قابلاً للصيانة بعد ستة أشهر؟ هل تعمل هذه الواجهة البرمجية بشكل قابل للتنبؤ؟ هل يقلل هذا الكود من العبء المعرفي على الفريق؟ هذه نتاج ذوق وخبرة لا يمتلكها إلا المهندس المتمرس.

تصميم حدود الإنسان والنظام. التمييز بين ما لا يمكن للذكاء الاصطناعي أتمتته وما ينبغي أتمتته، وتصميم كيفية تدخل الإنسان عند تلك الحدود. تماماً كما يجعل انتشار القيادة الذاتية تصميم لحظات تدخل السائق أكثر أهمية، كذلك يزداد دور تصميم أماكن ضرورة الحكم البشري أهمية كلما كتب الذكاء الاصطناعي كوداً أكثر.

ما الذي يحدث اقتصادياً

حين تتحرك منحنى العرض للبرمجيات نحو الأسفل، يحدث شيء مفارق.

زيادة العرض تخفض الأسعار. انخفاض الأسعار يفجّر الطلب. المشكلات التي كان حلها ببرمجيات باهظ التكلفة تصبح قابلة للتحقق — إدارة مرضى في عيادة صغيرة، تحسين مخزون مطعم محلي، خطوط تحليل بيانات لباحث فردي.

لا ينكمش الطلب على الهندسة بل تتغير بنيته. قد تتقلص الوظائف المخصصة للتنفيذ المتكرر داخل شركات البرمجيات الكبرى. في المقابل، ينمو الطلب على الأدوار التي تستخدم الذكاء الاصطناعي لحل مشكلات حقيقية في قطاعات لا تُحصى.

ما أشار إليه أمودي عن تصدع “نموذج توزيع ملايين المستخدمين” في SaaS ينسجم مع المنطق ذاته. حققت شركات البرمجيات تاريخياً الجدوى الاقتصادية باسترداد تكاليف التطوير عبر مستخدمين كثيرين. إذا اقتربت تكلفة بناء البرمجيات من الصفر، يصبح الدافع لبناء حلول عامة لملايين الناس أقل. تصبح البرمجيات المخصصة لمنظمة بعينها، أو فريق بعينه، أو حتى فرد بعينه، ممكنة اقتصادياً.

المستفيدون من هذا التحول هم خبراء المجال. الأطباء والمحامون والمحاسبون ومتخصصو اللوجستيات — الناس الذين يعرفون عملهم معرفة عميقة سيستطيعون بناء برمجياتهم الخاصة باستخدام أدوات الذكاء الاصطناعي. ينتقل دور المهندسين نحو التعاون مع هؤلاء الخبراء لتغطية ما تعجز أدوات الذكاء الاصطناعي عن إنتاجه: التصميم والتحقق والتكامل.

الانتقال سيكون مؤلماً. حين قال أمودي في يناير إنه سيكون “مؤلماً بشكل غير اعتيادي”، كان يتحدث عن سرعة الانتقال. إذا استغرقت الثورة الصناعية عقوداً، فقد يحدث هذا الانتقال في بضع سنوات. وقد لا يتوفر الوقت الكافي لإعادة التدريب.

تجدر الإشارة أيضاً إلى أن أمودي لم يتراجع عن تحذيره. حتى وهو يلين نبرته في مايو، قال في الفترة ذاتها إن “ثمة وظائف استغرق بناؤها أجيالاً قد تختفي”. يجب مواجهة التوتر بين هذين التصريحين مباشرة. إمكانية التعزيز والاضطراب الجذري في هياكل المسارات المهنية ليسا متناقضين — كلاهما قد يكون صحيحاً في الوقت ذاته.

ما الذي يتغير لفرق الهندسة والمنظمات

هذه ليست مسألة فردية فحسب؛ إنها أيضاً مسألة كيفية بناء المنظمات.

تضبب حدود الأدوار. يظهر مديرو المنتجات ومحللو البيانات وخبراء المجال القادرون على بناء نماذج أولية بأدوات الذكاء الاصطناعي دون كتابة الكود مباشرة. يجب على المهندسين فهم السياق التجاري بعمق أكبر والتعاون مع خبراء المجال بشكل أوثق. تعريف “المهندسون يحتاجون فقط إلى كتابة كود جيد” لم يعد ثابتاً.

ثقافة التحقق تصبح أكثر أهمية. قد تتحرك المنظمات التي ترفع الكود المولَّد بالذكاء الاصطناعي مباشرة إلى الإنتاج بسرعة على المدى القصير، لكنها ستصبح هشة على المدى البعيد. القدرة على التحقق تصبح مصدراً للميزة التنافسية أكثر من سرعة التوليد. يجب أن تكون مراجعة الكود فعلاً حقيقياً من أفعال الحكم، لا إجراءً شكلياً.

تعريف المشكلة يصبح كفاءة محورية. القدرة على بناء النماذج الأولية بسرعة تعني، مفارقةً، ضرورة اتخاذ قرار ما يُبنى بمزيد من الحرص. كلما انخفضت تكلفة البناء، ازداد خطر بناء الشيء الخطأ. يجب زيادة الاستثمار في مقابلات المستخدمين واكتشاف المشكلات والتحقق من الفرضيات.

يتغير معيار الثقة. ينتقل المعيار من من يكتب المزيد من الكود بشكل أسرع إلى من يستطيع تعريف المشكلات الأفضل والتحقق منها. هذا لا يعني انخفاض قيمة المهندسين المتمرسين — بل يعني أن تلك القيمة يجب التعبير عنها بشكل مختلف.

منظور ثاكي كلاود: ما تقوله البنية التحتية

تبني شركة ThakiCloud بنية تحتية لتطوير البرمجيات بالذكاء الاصطناعي. إذا كانت نبوءة أمودي صحيحة، فإن معنى ما نبنيه يتغير هو الآخر.

انخفاض التكلفة الحدية للبرمجيات لا يعني انخفاض التكلفة الحدية للبنية التحتية. وحدات معالجة الرسوميات (GPU) والإيجار المتعدد وحوكمة البيانات والأمان والتوافر — لا تولّد هذه أدوات الذكاء الاصطناعي. كلما تزايد عدد تطبيقات البرمجيات المبنية بالذكاء الاصطناعي، ازداد الطلب على البنية التحتية التي تشغّلها بالتوازي.

بالنسبة لفريقنا، تصريحات أمودي هي تحذير واتجاه في آنٍ معاً. تحذير: بعض ما كان ذا قيمة حتى الآن سيفقد قيمته بسرعة. اتجاه: إذا كانت قيمتك مستمدة من التنفيذ المتكرر، فعليك الانتقال نحو الحكم والتصميم.

الخلاصة: حين يتقلص نصف عمر الخبرة

كون البرمجيات مجانية لا يعني أن صانعيها مجانيون. تكلفة توليد الكود تنخفض؛ قيمة الحكم المطلوب لبناء برمجيات جيدة لا تنخفض.

تحول ثقل أمودي بين يناير ومايو قابل للقراءة في هذا الضوء. الاضطراب الذي يجلبه الذكاء الاصطناعي حقيقي. على الجانب الآخر من ذلك الاضطراب دور مختلف.

الجوهر في ذلك الدور شيء واحد: القدرة على الحكم على ما يجب بناؤه ولماذا. هذا شيء لا يستطيع محرر الكود إخبارك به.

هوية المهندس تنتقل من “شخص يكتب الكود” إلى “شخص يرى المشكلات”. الهوة بين الفرق التي تدرك هذا الانتقال وتستعد له وتلك التي لا تفعل ستظهر في غضون سنوات قليلة.

المصادر

• داريو أمودي / Anthropic، مقابلة WSJ-دافوس، يناير 2026 — «ستصبح البرمجيات مجانية في جوهرها»: تغطية The News.com.pk
• داريو أمودي، CNBC، 27 يناير 2026 — تحذير من صدمة وظيفية “مؤلمة بشكل غير اعتيادي”: النص الأصلي على CNBC
• داريو أمودي، مقابلة مايو 2026 — “ثمة وظائف استغرق بناؤها أجيالاً قد تختفي”: X @AnatoliKopadze RT (2026-05-26)
• Fortune، 26 مايو 2026 — تقرير عن تليين موقف أمودي: النص الأصلي على Fortune

في ربيع عام 2026، انتشر تقييم لافت في أوساط مستثمري التقنية: “ربما يكون جنسن هوانغ أبرع منتقي الأسهم في وول ستريت — حتى وإن لم ينتقِ سهماً بنفسه”. لم تكن هذه العبارة من تصريح هوانغ ذاته؛ بل كانت لقباً أطلقه مراقبو السوق من خارجه.

وكانت الأدلة محددة. الشركات التي ذكرها هوانغ في مناسباته العامة وكلماته الرئيسية — Nebius (إيرادات ارتفعت 840%)، وApplied Digital (1,400%)، وTSMC (135%)، وMicron (770%) — قفزت أسهمها بعد تصريحاته، دون أن يقول مرة واحدة “اشتروا هذه الشركة”.

فلماذا تحمل هذه القصة دلالة لثقافة صنع القرار؟ لم تتحرك السوق بتصريحات هوانغ بسبب الحظ أو حدس استثنائي. كان يقرأ تدفقات بيانات النظام البيئي للذكاء الاصطناعي — الطلب على الرقائق، والاستثمار في البنية التحتية السحابية، وهيكل المستفيدين في طبقة البرمجيات — بطريقة غير مألوفة في انتظامها. ما بدا حدساً لم يكن سوى حكم صادر عن شخص يُهيكل البيانات بمنهجية دقيقة.

هذه هي نقطة انطلاق هذا المقال: جوهر الحكم المتميز الذي يبدو حدسياً هو تهيكل البيانات.

وراثة Moneyball: هل انتهى عصر الحدس؟

في مقالنا السابق (بناء ثقافة تنظيمية قائمة على البيانات بتفكير Moneyball)، أوردنا قصة فريق أوكلاند أتلتيكس عام 2002. استخرج بيلي بين المؤشر المهمَل — نسبة الوصول إلى القاعدة — وحقق 103 انتصارات بثلث ميزانية الفريق المعتادة.

ارتكز ذلك المقال على مقدمتين أساسيتين: المقاييس التي تستخدمها الآن ربما تكون خاطئة؛ والموارد المقيَّمة بأقل من قيمتها التي تكتشفها عبر البيانات تمنحك أقصى كفاءة.

في زمن الذكاء الاصطناعي اليوم، تعود هاتان المقدمتان في صورة سؤال أكثر حدة: إلى أين تراجع الحدس؟

في كرة القاعدة، ظلت خبرة الكشاف وعينه الفاحصة أبرز أدوات التقييم لعقود. لم يكن ذلك خطأً. غير أن البيانات ضبطت متغيرات أكثر وأنتجت توقعات أفضل. أصبحت جودة القرار تُفسَّر بكمية البيانات المتاحة وقدرة تهيكلها أكثر مما تفسرها خبرة الإنسان.

المنظمات في عصر الذكاء الاصطناعي تواجه هذا التحول البنيوي بصورة أكثر جذرية. تعالج النماذج آلاف المتغيرات في آنٍ واحد، وتكتشف الأنماط، وتقلص هي بنفسها هامش خطئها التنبؤي. المزايا التقليدية للحدس — تراكم الخبرة، والتعرف على الأنماط، والحكم السريع — هي بالتحديد المجال الذي يتقدم فيه الذكاء الاصطناعي.

إذن كيف يجب أن تتغير بنية صنع القرار في المنظمة؟

قِس قراراتك: تحويل القرارات إلى بيانات

جوهر تفكير Moneyball ليس تغيير مؤشرات الأداء. بل هو جعل القرارات ذاتها قابلة للقياس.

لم يختر فريق أوكلاند نسبة الوصول إلى القاعدة لمجرد اعتقاده بأنها المؤشر الأهم. بل أثبت العلاقة السببية بين تسجيل النقاط وهذه النسبة بالأرقام. ولأن الحلقة الرابطة بين المؤشر والنتيجة كانت مدعومة بالبيانات، أمكن تنفيذ ذلك الحكم مراراً وتكراراً.

صنع القرار التنظيمي يتبع البنية ذاتها.

كيف تميز القرار الجيد من القرار السيئ؟

في معظم المنظمات، يُقيَّم جودة القرار بالاستنتاج العكسي من النتائج: إن سارت الأمور حسناً فالقرار كان جيداً، وإن ساءت فهو كان سيئاً. غير أن هذا المنهج يحمل مشكلتين.

القرارات الجيدة قد تفضي إلى نتائج سيئة. حتى حين تقرر بأفضل المعلومات المتاحة، قد تُخطئ متغيرات خارجية توقعاتك. والحكم على القرار بنتيجته يتيح للتحيز الاسترجاعي أن يعيق التعلم التنظيمي، إذ يُنسج سرد لاحق ليتوافق مع ما حدث.

وقد تنجح القرارات السيئة. وهذا أشد خطراً. حين يصادف حدس لا أساس له الصواب، يبني الشخص ثقة بذلك الحدس، مما يمهد لفشل لاحق.

تبدأ ثقافة القرار القائمة على البيانات من تسجيل المبررات وقت اتخاذ القرار وتقييمها، لا من النتيجة.

سجل القرارات: أثر تدقيقي للحكم

نقطة البدء هي التسجيل الصريح لثلاثة عناصر لحظة اتخاذ القرار:

• ما الافتراضات التي يقوم عليها هذا القرار؟
• ما البيانات التي تدعم تلك الافتراضات؟
• كيف سنعرف أن هذا القرار كان خاطئاً؟ (شرط التفنيد)

السؤال الثالث هو المحوري. عبارة “هذه الميزة ستزيد الاحتفاظ بالمستخدمين 5%” لا يمكن التحقق منها كما هي. لكن إذا كتبت: “إذا لم يرتفع معدل الاحتفاظ خلال سبعة أيام بنسبة 5% على الأقل خلال ثمانية أسابيع من الإطلاق، فإن هذا الافتراض خاطئ” — يصبح القرار قابلاً للقياس.

في كلمة GTC Taipei 2026، كشفت NVIDIA عن نموذج يخصص جزءاً من الراتب الأساسي للمهندسين كميزانية للرموز الحسابية لقياس الإنتاجية. ليس هذا مجرد تغيير في بنية التعويض؛ بل إعلان عن قياس فعلي لنتائج قرارات استخدام أدوات الذكاء الاصطناعي. لا تتعلم المنظمات إلا حين يمكن تتبع القرارات بالأرقام.

حيث ينتصر الحدس: حدود البيانات

إن الادعاء بأن صنع القرار القائم على البيانات يحلّ محل الحدس صحيح في نصفه فقط. ثمة مجالات يتفوق فيها الحدس على البيانات، وأخرى تتفوق فيها البيانات على الحدس.

حيث تكون البيانات في أوج قوتها

في القرارات ذات الأنماط القابلة للتكرار، تطغى البيانات على الحدس:

• التوقعات ذات السجل التاريخي الكافي (معدلات التحويل، ومعدلات التراجع، وتوقعات الطلب)
• التجارب ذات مؤشرات النجاح الواضحة (اختبارات A/B، وعلامات الميزات)
• استخراج الإشارات من البيانات الضخمة (تقسيم المستخدمين، وكشف الشذوذ)

الحدس لا يتفوق هنا على البيانات. حتى مدير المنتج الخبير حين يقول “المستخدمون سيحبون هذه الميزة” يخطئ عند التجريب بوتيرة أعلى مما يتوقع. ما تُبلغ عنه شركات التقنية الكبرى بشكل مشترك من تجارب A/B هو أن ميزات اعتُبرت “مضمونة” داخلياً كثيراً ما خيّبت التوقعات في التجارب الفعلية.

حيث لا يزال الحدس ضرورياً

المجال الذي تضعف فيه البيانات هو الحالات التي لا سابقة لها.

الأسواق الجديدة، والنماذج التكنولوجية الجديدة، والقرارات في المراحل المبكرة قبل تراكم البيانات الكافية — في هذه المواضع لا توجد بيانات يمكن تعلّم الأنماط منها. تمكّن فريق أوكلاند من استخراج نسبة الوصول إلى القاعدة لأن سجلات عقود من الكرة القاعدة كانت متاحة. أما في رياضة جديدة كلياً، فيجب ابتكار المفهوم ذاته.

هنا يكمن دور الحدس في تحديد اتجاه جمع البيانات. “أي بيانات ينبغي أن نجمع؟” لا تزال مسألة حكم إنساني. قدرة هوانغ على قراءة تدفقات الطلب على بنية الذكاء الاصطناعي التحتية نبعت من عقود قضاها مباشرة في النظام البيئي لأشباه الموصلات والبرمجيات. حين يُتحقق من ذلك الحكم بالبيانات، يتحول إلى “رؤية منهجية تبدو حدسية”.

فخ مسرح البيانات

ثمة فخ آخر يجب التحذير منه: نمط الظهور باستخدام البيانات بينما يجري في الواقع انتقاء بيانات تدعم نتيجة توصل إليها الشخص مسبقاً — يُعرَّف هذا بـ”مسرح البيانات”.

الأعراض كالآتي: يُتخذ القرار أولاً، ثم لا تظهر في التقرير إلا البيانات المؤيدة له، فيما تُستبعد البيانات المعارضة بحجة “اختلاف السياق” أو “صغر العينة”. الشكل قائم على البيانات، لكن الجوهر حدس في غلاف بياني.

مسرح البيانات أشد خطورة من الحدس المجرد لسبب وجيه: حين يخطئ الحدس، يمكن الاعتراف بأن “حكمي كان خاطئاً”. لكن حين يخفق مسرح البيانات، تلجأ المنظمة إلى الدفاع بأن “البيانات التي رأيناها كانت معيبة”، فيُحجب التعلم.

الشروط التي تتغلب فيها البيانات على الحدس في المنظمة

حتى حين تتوفر بيانات جيدة، كثيراً ما تظل قرارات المنظمة دون تغيير. تغلّب البيانات على الحدس ليس مسألة تقنية — بل مسألة ثقافة وبنية.

الشرط الأول: أن يكون التفنيد آمناً

تحتاج إلى بيئة يمكن فيها قول: “هذه البيانات تدحض فرضيتنا.”

في كثير من المنظمات، حين تكشف تجربة أن ميزة اقترحها مسؤول تنفيذي لم تُثمر، يصعب الإبلاغ بتلك النتيجة كما هي. البنية الهرمية تشوّه البيانات. حين يُظهر القائد أولاً أن “فرضيتي قد تكون خاطئة”، تتبعه المنظمة كاملة.

ثقافة “خالف ثم التزم” لدى أمازون تعالج هذه النقطة بالذات. تنفيذ قرار لا توافق عليه، ومواصلة التحقق منه بالبيانات أثناء التنفيذ، ليسا متناقضَين. حين يعمل الأمران معاً تكتسب البيانات معناها.

الشرط الثاني: أن تكون وحدة القرار صغيرة

في البنية التي تُتخذ فيها قرارات كبيرة دفعة واحدة، يصعب أن تؤثر البيانات في صنع القرار. الشركة التي تضع خارطة طريقها كل ستة أشهر لا تستطيع بسهولة تغيير اتجاهها حتى حين تصلها البيانات في المنتصف.

تفتيت القرارات هو البنية العملية الحقيقية للثقافة القائمة على البيانات. “هل نطور هذه الميزة لثلاثة أشهر؟” سؤال أدنى من “هل يمكننا في أسبوعين التحقق من الافتراض الجوهري بنموذج أولي؟” القرارات الصغيرة تُتيح التعلم السريع وتُمكّن البيانات من تغيير الاتجاه فعلاً.

تتعمق هنا الفكرة التي طرحناها في مقال Moneyball: “الفريق الذي يستغرق ثلاثة أسابيع لإجراء اختبار A/B مقابل فريق يستغرق ثلاثة أيام سيتفاوت تعلّمُهما عشرة أضعاف بعد عام.” الفارق في سرعة التعلم ليس فارقاً في كمية البيانات، بل هو فارق في حجم وحدة القرار وتكرارها.

الشرط الثالث: أن تكون القرارات الماضية قابلة للتتبع

يجب أن تكون قادراً على الإجابة عن “لماذا أسفر الأمر عن هذه النتيجة؟”

في كثير من المنظمات، تضيع مبررات القرارات المهمة. من كان في الاجتماع يغادر الشركة، وتُؤرشَف قنوات Slack، ولا تُحفظ البيانات من تلك اللحظة. يرى الأعضاء الجدد نتيجة القرار فحسب دون أن يعرفوا لماذا اتُخذ.

حين يصبح سجل القرارات ممارسة طبيعية كمراجعة الأكواد، تستطيع المنظمة التعلم من أنماط أحكامها: في أي نوع من القرارات نخطئ تكراراً؟ أي افتراضات تنهار مراراً؟ حين تتضح هذه الصورة، يمكن تصحيح تحيزات الحدس بالبيانات.

عملاء الذكاء الاصطناعي والتحول في بنية صنع القرار

قال هوانغ في كلمة GTC Taipei 2026: “كل مهندس سيمتلك مئات العملاء ويُديرهم.” هذا ليس مجرد تغيير في الأدوات؛ إنه تغيير في البنية الجوهرية لصنع القرار.

حين تتولى العملاء المهام المتكررة القائمة على الأنماط، يتبدل نطاق تركيز الحكم الإنساني. التمييز بين القرارات التي يمكن تفويضها للعملاء والقرارات التي يجب للإنسان الحكم فيها مباشرة — يغدو هذا التمييز ذاته كفاءة جوهرية جديدة.

اعتماد العملاء ليس إتمام ثقافة القرار القائمة على البيانات. بل إن السؤال الأهم هو كيف يراجع الإنسان ويتحقق من مقدمات القرارات التي يتخذها العملاء ونتائجها. العملاء أيضاً يتخذون قرارات متحيزة حين يتدربون على بيانات متحيزة. ينبغي أن يُسأل عن قرارات العميل أيضاً: “ما مقدمات هذا القرار؟ وما شرط تفنيده؟”

كما بنى بول ديبوديستا النماذج الإحصائية في Moneyball، يجب على المنظمات التي تُشغّل العملاء أن تصمم بشكل صريح أي القرارات يُفوَّض للعملاء وعلى أي أساس تُوثق الثقة في تلك القرارات.

تداعيات على المنظمة: ثلاث خطوات قابلة للتطبيق

ثقافة القرار القائمة على البيانات ليست بناء لوحات متابعة أكثر. إنها تغيير في بنية القرارات.

أولاً، اكتب شروط تفنيد القرار مسبقاً. قبل إطلاق ميزة، يتفق الفريق معاً على البيانات التي تعني أن القرار كان خاطئاً. تضييق مجال التأويل قبل ظهور النتائج هو الطريقة الأكثر عملية لمنع مسرح البيانات.

ثانياً، حوّل القرارات الخاطئة إلى أصول تعليمية. التجارب الفاشلة يجب ألا تختفي — بل تظل متاحة للفريق كله. التقرير الذي يوثق “لماذا لم تنجح هذه الميزة؟” يصبح مدخلاً للتخطيط القادم. الإخفاقات الماضية تصحح حدس المستقبل.

ثالثاً، صمّم قرارات العملاء بحيث تكون قابلة للمراجعة. تحتاج إلى بنية يمكن فيها الإجابة لاحقاً عن “على أي بيانات استند هذا العميل في هذا الحكم؟” في اللحظة التي يصبح فيها تفكير العميل صندوقاً أسود، تكف تلك المنظمة عن كونها قائمة على البيانات وترجع إلى حدس قائم على العملاء.

يمكن قراءة عمل ThakiCloud في بناء بنية تحتية لجدولة العملاء القائمة على Kueue في هذا السياق. كيف يوزع العملاء الأعباء التشغيلية، وهل يظل مبرر ذلك القرار محفوظاً في سجلات — هذا هو أساس الثقة بالمنصة.

خلاصة: الحدس لا يختفي، بل يجد مكاناً جديداً

سؤال “إذا كان الذكاء الاصطناعي أفضل صانع قرار” ينطلق من مقدمة خاطئة. ثمة قرارات يتفوق فيها الذكاء الاصطناعي والبيانات، وقرارات يتفوق فيها الحكم الإنساني والخبرة. المهم ليس أيهما أفضل مطلقاً، بل تصميم مَن يتخذ كل قرار وفق طبيعة ذلك القرار.

بيلي بين في Moneyball لم يتخلَّ عن حدس الكشافين. ظل الحكم الإنساني ضرورياً لما لا تفسره البيانات — روح اللاعب، وتناغم الفريق، والتمركز في أسواق جديدة. ما بناه لم يكن “منظمة أزالت الحدس” بل “منظمة أوضحت أين ينبغي للحدس أن يتدخل”.

السبب الذي جعل هوانغ يُلقَّب في السوق بـ”أفضل منتقي الأسهم” ليس غياب الحدس عنده، بل تراكم عقود من قراءة النظام البيئي لأشباه الموصلات عبر البيانات، حتى بدا حكمه انتظاماً في أنماط. في نهاية المطاف، الحدس المتميز هو ثمرة تهيكل طويل الأمد للبيانات.

ثقافة القرار التي تتغلب فيها البيانات على الحدس هي التي تُنشئ في المنظمة حلقة تبدأ بالبيانات ويراجع فيها الحدس نفسه ويُصحح. المنظمات التي تُدير هذه الحلقة باستمرار تتخذ قرارات أفضل على المدى البعيد.

المصادر

• Jensen Huang, “Every engineer is going to have and manage hundreds of agents.” — كلمة NVIDIA GTC Taipei 2026، 2026-05-20 / 2026-06-01. مدونة NVIDIA الرسمية: https://blogs.nvidia.com/blog/nvidia-gtc-taipei-computex-2026-news/
• “Jensen Huang might be the best stock picker on Wall Street and he does not even pick stocks.” — تقييم خارجي من مراقبي السوق (ليس تصريحاً لهوانغ نفسه). سلسلة تغريدات @InTheAssembly على X: https://x.com/InTheAssembly/status/2053801122632958342
• Jensen Huang، تصريحات عن ميزانية الرموز الحسابية لمهندسي NVIDIA — نسخة كلمة GTC Taipei Computex 2026. Semiconalpha Substack: https://semiconalpha.substack.com/p/nvidia-keynote-computex-2026-key
• بيانات أسعار أسهم Nebius وApplied Digital وTSMC وMicron — سلسلة تغريدات @InTheAssembly على X (نفس المصدر أعلاه)
• مدونة ThakiCloud، “بناء ثقافة تنظيمية قائمة على البيانات بتفكير Moneyball” (المقال الأصل الذي يتابعه هذا): https://thakicloud.github.io/culture/moneyball-data-driven-culture/

في يناير 2026، جلس شخصان جنبًا إلى جنب في المنتدى الاقتصادي العالمي بدافوس: ديميس هاسابيس من DeepMind، وداريو أموداي من Anthropic. كان الجو مشحونًا بالحماس. كانت النماذج اللغوية الكبيرة تحلّ مسائل الأولمبياد الرياضية، وتتفوق على البشر في لعبة الغو، وتتنبأ بتراكيب البروتين. وكانت أصوات من مختلف أنحاء الصناعة تعلن أن الذكاء الاصطناعي العام بات على بُعد خطوات.

لكن هاسابيس قال غير ذلك.

“أنظمة اليوم ليست قريبة على الإطلاق من [الذكاء الاصطناعي العام]. لا يهم كم مسألة من مسائل إيردوش تحلّ.” (النص الأصلي بالإنجليزية: “Today’s systems are nowhere near [AGI]” — Fortune، 23 يناير 2026)

مسائل إيردوش من أصعب الألغاز الرياضية في العالم. وإن استطاع الذكاء الاصطناعي حلّها فذلك مثير للإعجاب بلا شك، غير أن هاسابيس كان قاطعًا: ليس هذا معيار الذكاء الاصطناعي العام. لماذا؟

هذا السؤال هو نقطة انطلاق هذا المقال. وهو ليس حكرًا على باحثي الذكاء الاصطناعي، بل يعني كل منظمة تتبنى الذكاء الاصطناعي أو تبني فرقًا متخصصة فيه أو تطوّر منتجاته.

الخط الذي رسمه هاسابيس: “الفهم” مقابل “مطابقة الأنماط”

لم يضع هاسابيس “حل مسائل إيردوش” معيارًا للذكاء الاصطناعي العام. معياره أرفع من ذلك. نقلت عنه وسائل إعلام متعددة ما بات يُعرف بـ”اختبار أينشتاين”: القدرة على اقتراح نظرية فيزيائية جديدة بصورة مستقلة وأصيلة، أي نظام يمتلك فهمًا حقيقيًا لا مجرد إعادة إنتاج أنماط إحصائية.

فأين تقف النماذج اللغوية الكبيرة اليوم؟ مهما اتسع نطاق بيانات التدريب واتقن النموذج محاكاة الاستدلال، يبقى السؤال مفتوحًا: هل هذا “فهم” أم “إعادة إنتاج أنماط إحصائية”؟ وقد قال هاسابيس نفسه في الجلسة ذاتها بدافوس: “لا يزال ثمة حاجة لاختراق أو اثنين”. وكان تقديره الزمني حينئذ “5 إلى 10 سنوات”.

لكن القصة لم تنتهِ عند هذا الحد.

تغيّر في الجدول الزمني خلال أربعة أشهر: الاستخدام المتعمد للغة الاستفزازية

بعد نحو أربعة أشهر من تصريحات دافوس، وتحديدًا في 26 مايو 2026، وفي مقابلة مع Axios عقب مؤتمر Google I/O، تحدّث هاسابيس بنبرة مختلفة، مشيرًا إلى أن “الذكاء الاصطناعي العام سيتحقق على الأرجح في غضون السنوات الخمس المقبلة”. لخّص بعض المنابر هذا القول بـ”الذكاء الاصطناعي العام خلال 3 إلى 4 سنوات”، وانتشر التصريح على نطاق واسع.

بيد أن هاسابيس أضاف في المقابلة ذاتها: “بعض المصطلحات التي استخدمتها كانت استفزازية بعض الشيء عمدًا.” (النص الأصلي: “some of the terms I used were a little bit provocative” — Axios، 2026-05-26)

التصريح الحذر في يناير، والجدول الزمني المُقدَّم في مايو. الشخص نفسه، في العام نفسه، في سياقين مختلفين. فأيهما يعكس الفكر “الحقيقي” لهاسابيس؟

على الأرجح كلاهما. وهذا التوتر بعينه يوضح لماذا يجب أن تصبح إدارة التوقعات ممارسة ثقافية.

الندوب التي تتركها دورة الضجيج في المنظمات

يتسم قطاع الذكاء الاصطناعي بسرعة استثنائية في دورات المبالغة. دون الحاجة إلى مراجعة دورة ضجيج غارتنر، يكفيك أن تتذكر كم مرة تكررت عبارة “هذه المرة مختلفة” خلال العقد الماضي: ثورة التعلم العميق، عصر روبوتات المحادثة، GPT-3، ChatGPT، الذكاء الاصطناعي الوكيل… في كل دورة، تستثمر المنظمات في حالة الحماس، تصطدم بجدار الواقع، تشعر بخيبة الأمل، ثم تنتظر الموجة التالية.

يترك هذا النمط ثلاثة أنواع من الندوب في المنظمات.

أولًا: استنزاف رأس المال من الثقة. إن أعلنت أن “الذكاء الاصطناعي سيحل هذه المشكلة في ستة أشهر” ثم أخفقت، فإن الناس سيغلقون آذانهم في المرة التالية حين تطرح مقترحًا جادًا لتبني الذكاء الاصطناعي. مصداقية القيادة إذا تآكلت يصعب استعادتها.

ثانيًا: تشويه تعريف الفشل. حين تبدأ من توقعات مبالغ فيها، فإن إنجازًا حقيقيًا قد يُصنَّف “فشلًا”. تحمل الفِرق إلى مشروعها التالي شعورًا بالهزيمة بدلًا من الفخر المستحق، فيعقب ذلك الإرهاق والاستقالات.

ثالثًا: ضياع الاتجاه. المشاريع التي تنطلق ركوبًا لموجة الضجيج يصعب توجيهها. عبارة “ابنوا ذكاءً اصطناعيًا يشبه الذكاء الاصطناعي العام” لا تخبر الفريق بشيء يُذكر. ما الذي ينبغي بناؤه؟ كيف تُقاس النجاح؟ متى يكون “ما أنجزناه كافيًا”؟ في غياب إجابات هذه الأسئلة، تفقد الفرق بوصلتها.

ما يمارسه هاسابيس: فلسفة خارطة الطريق

تكشف مسيرة DeepMind عن كيفية تطبيق إدارة التوقعات فعليًا.

استهدف AlphaGo (2016) مشكلة محددة بوضوح: لعبة الغو. وحلّ AlphaFold (2020) مشكلة علمية قابلة للتحقق: التنبؤ بتراكيب البروتين. أما الذكاء الاصطناعي العام فهو بالنسبة لهاسابيس تحدٍّ مستقبلي لا يزال يستلزم “اختراقًا أو اثنين”.

النمط في هذه الخارطة ثابت: تُحدَّد أهداف بلوغها ممكن بالقدرات الراهنة، تُحقَّق فعلًا، ثم يُستعد للمرحلة التالية. بدلًا من شعار “الذكاء الاصطناعي العام في خمس سنوات”، يُطرح السؤال: “ماذا سنُثبت في هذه المرحلة؟”

لا ينبغي قراءة هذا على أنه تحفظ أو جبن. أن يعترف هاسابيس في مايو 2026 بأنه “استخدم عن قصد بعض المصطلحات الاستفزازية” يدل أيضًا على أنه يعرف قيمة اللغة الطموحة في رفع سقف التوقعات. المفتاح هو كلمة “عن قصد”: فهو يعرف تمامًا أين تنتهي اليقينيات وأين تبدأ الاستفزازات المدروسة.

ما معنى ثقافة إدارة التوقعات؟

في منظمات الذكاء الاصطناعي، كثيرًا ما يبدو “إدارة التوقعات” مصطلحًا سلبيًا، يُفهم خطأً على أنه موقف دفاعي من قبيل “خفّض توقعاتك” أو “اِستبق خيبة الأمل”. نهج هاسابيس ليس كذلك على الإطلاق.

تتلخص إدارة التوقعات الصادقة في ثلاثة محاور.

أولًا: استخدم لغة تفرّق بين القدرة الراهنة والإمكانية المستقبلية. عبارة “يستطيع هذا النموذج أن يفعل X” تختلف عن “إن سرنا في هذا الاتجاه سيصبح X ممكنًا”. تمييز هذين الوجهين بوضوح أمام أعضاء الفريق ومجلس الإدارة والعملاء هو أساس الثقة، تمامًا كما فرّق هاسابيس بين “أنظمة اليوم” و”الأنظمة التي ستعقب اختراقًا أو اثنين”.

ثانيًا: حدّد معايير النجاح بصورة قابلة للقياس. هدف “تحسين الكفاءة التشغيلية عبر الذكاء الاصطناعي” لا يتيح معرفة ما إذا تحقق النجاح. أما هدف “تقليص وقت معالجة المهمة X بنسبة 30% بعد ستة أشهر من تبني الذكاء الاصطناعي” فله إجابة واضحة. وكما قاست AlphaFold دقة التنبؤ بالبروتين رقميًا قياسًا بأفضل ما سبقها، كذلك ينبغي لمشاريع الذكاء الاصطناعي.

ثالثًا: أرسِ ثقافة يمكن فيها الاعتراف بعدم المعرفة. أن يتمكن هاسابيس من الاعتراف بأن “بعض تعبيراتي كانت استفزازية بعض الشيء” دليل على أن هذا النوع من الاعترافات يرفع الثقة لا يُقلّصها. إذا عجز أحد داخل المنظمة عن قول “لا نعرف بعد” أو “هذا أصعب مما توقعنا” أو “نحتاج إلى مراجعة الجدول الزمني”، فسيصعد الناس الأخبار الجيدة فحسب ويكتمون السيئة، وستنفجر تلك المشكلات المكتومة يومًا ما دفعة واحدة.

كيف تكسر دورة خيبة الأمل؟

النمط الأكثر شيوعًا في إخفاقات تبني الذكاء الاصطناعي بسيط: الانطلاق بحماس ← المبالغة في التوقعات ← الاصطدام بالواقع ← خيبة الأمل ← “الذكاء الاصطناعي لم يكن بكل هذا الشأن” ← تجميد الاستثمار حتى الموجة التالية.

كسر هذه الدورة يستلزم مرحلة وسيطة: الانطلاق بحماس مع تحديد خطوة أولى قابلة للتحقق، تحقيق تلك الخطوة فعلًا، إظهار النتائج، ثم الانتقال للخطوة التالية.

هذا لا يعني “فكّر بأفق محدود”. DeepMind بدأت بـAlphaGo وأنتجت AlphaFold، وهي الآن في طريقها نحو الذكاء الاصطناعي العام. الهدف كبير، لكن كل مرحلة مصممة بواقعية.

المنظمات التي تنجح في هذا النهج تشترك في عادة واحدة: حين تشرع في مبادرة ذكاء اصطناعي جديدة، تسأل أولًا: “كيف يبدو النجاح في هذه المرحلة؟” وبعد ستة أشهر تتحقق من إمكانية الإجابة على هذا السؤال. وحين تقصر عن التوقعات، تسجّل “لماذا جاء الواقع مختلفًا؟” ويجعل ذلك التسجيل توقعات المشروع التالي أكثر واقعية.

ما يعنيه هذا للمنظمات: اجعل الواقعية نظامًا

إذا ظلت واقعية هاسابيس فضيلةً شخصية، فإنها ستختفي حين يرحل ذلك الشخص. لكي تتحول إدارة التوقعات إلى ثقافة مؤسسية تحتاج إلى أنظمة.

في ThakiCloud نواجه هذه المعضلة كثيرًا. بوصفنا شركة تبني منصة للذكاء الاصطناعي، نحسّ كل يوم بالتوتر بين شرح إمكانات الذكاء الاصطناعي للعملاء والتحدث بصدق عن قيوده. الانحياز الزائد لأحد الطرفين إما أن يُفضي إلى وعود مبالغ فيها، أو يجعلنا نضيّع الفرص.

من الممارسات التي نجرّبها: في بداية كل مشروع، نكتب صراحةً قائمة بـ”ما لن نحققه في هذه المرحلة”، لا قائمة ما سنفعله فحسب. علّمتنا التجربة أن قائمة “ما لن نفعله” أكثر فاعلية في مواءمة التوقعات مع الواقع من قائمة “ما سنفعله”.

أن يستطيع هاسابيس القول “أنظمة اليوم ليست قريبة على الإطلاق من الذكاء الاصطناعي العام” لا يعني أنه متشائم حيال مستقبل الذكاء الاصطناعي. فهو الشخص الذي أعاد رسم خريطة علم الأحياء بفضل AlphaFold. التصريح الصريح بحدود الأنظمة الراهنة هو في حقيقته تحديد اتجاه نحو الاختراق التالي.

الواقعية ليست تخليًا عن الحلم، بل قياس المسافة إليه بدقة.

خاتمة: الصدق أقوى الأصول الثقافية

في مجال الذكاء الاصطناعي، أسهل شيء هو إثارة الحماس. “الذكاء الاصطناعي العام قادم في ثلاث سنوات”، “هذا النموذج سيغيّر كل شيء”، “إن لم تركب الموجة الآن فستتأخر”. هذه العبارات تستقطب الاستثمار وتزيد الطلب على التوظيف وتستأثر باهتمام الإعلام.

أصعب شيء هو القول، وسط كل هذا الحماس: “لكن هذا لم يصبح ممكنًا بعد”.

قال هاسابيس هذا الشيء الصعب في دافوس في يناير 2026: حل مسائل إيردوش ليس ذكاءً اصطناعيًا عامًا، ولا يزال ثمة حاجة لاختراق أو اثنين. وفي مايو اعترف بحرية أنه استخدم عمدًا بعض المصطلحات الاستفزازية.

حين يعمل هذان الموقفان معًا، تتراكم ثقة المنظمة. الصراحة في التعبير عن الحدود. الاعتراف حين تتجاوز في التعبير. التراكم التدريجي للصدق أصل ثقافي أعمق بكثير من الاهتمام الآني الذي تجنيه من مبالغة واحدة.

لقادة منظمات الذكاء الاصطناعي، يقدم نهج هاسابيس نقطة مرجعية: ما الذي تستطيع أنظمة الذكاء الاصطناعي الحالية فعله؟ وما الذي لا تستطيعه بعد؟ وما المرحلة التالية، وأي اختراق تستلزم؟ الثقافة التي تجيب على هذه الأسئلة الثلاثة بصدق هي أساس منظمة الذكاء الاصطناعي المستدامة، سواء جاء الذكاء الاصطناعي العام أم تأخّر.

المصادر

• Fortune (2026-01-23): “DeepMind’s Demis Hassabis, Anthropic’s Dario Amodei, Yann LeCun at AI Davos” — https://fortune.com/2026/01/23/deepmind-demis-hassabis-anthropic-dario-amodei-yann-lecun-ai-davos/
• WEF Radio Davos Podcast (2026-01): “AI & AGI — Dario Amodei, Demis Hassabis” — https://www.weforum.org/podcasts/radio-davos/episodes/ai-agi-dario-amodei-demis-hassabis/
• Axios (2026-05-26): “DeepMind CEO Demis Hassabis on AGI timeline” — https://www.axios.com/2026/05/26/deepmind-ceo-demis-hassabis
• Sherwood News: “Google DeepMind’s Hassabis: AGI is 3 to 4 years away” — https://sherwood.news/tech/google-deepminds-hassabis-agi-is-3-to-4-years-away/
• CryptoBriefing: “DeepMind Hassabis AGI Einstein Test” — https://cryptobriefing.com/deepmind-hassabis-agi-einstein-test/

في مايو ويونيو من عام 2026، كرّر جنسن هوانغ الرسالة ذاتها من على مسارح Computex وGTC Taipei: “Every engineer is going to have and manage hundreds of agents” (كل مهندس سيمتلك مئات الوكلاء ويديرهم). لمن اعتقد أن كتابة الكود مباشرةً هي جوهر عمل المهندس، فإن هذا الإعلان يمسّ أسس مسيرته المهنية.

غير أن هذه العبارة لا تتحدث عن زوال الوظائف. حين نفكّك عبارة “سيمتلك ويدير”، نجد أن المهندس لا يزال هو الفاعل، والوكلاء هم الموارد التي يُشغّلها. تماماً كما أن أتمتة المصانع لم تُلغِ عمّال المصانع بل جعلت مديري الإنتاج أكثر أهمية، فإن عصر الوكلاء يحتاج إلى مُنسّقين.

تستكشف هذه المقالة الأسئلة التي يطرحها ذلك التحوّل على الثقافة التنظيمية. إنها ليست ملخصاً لاتجاهات التقنية، بل مقالة ثقافية تسأل: كيف نُشكّل الفرق، وكيف نُوزّع العمل، وكيف نقيس الأداء؟

الوحدة التنظيمية الجديدة: 100 إلى 1

في مقابلة مع مجلة Fortune في مارس 2026، وضع جنسن هوانغ أرقاماً محددة على رؤيته. تستعد NVIDIA لمستقبل تتعايش فيه 7.5 مليون وكيل ذكاء اصطناعي مع 75,000 موظف. بحساب بسيط: 100 وكيل لكل إنسان.

حتى لو كان هذا الرقم مبالغاً فيه، فإن الاتجاه الذي يشير إليه واضح. إذا كانت المنظمات تقيس حجمها بعدد الموظفين، فإن عدد الوكلاء سيصبح في المستقبل المقياسَ الحقيقي للموارد. البنية التي تستطيع فيها شركة ناشئة من عشرة أشخاص منافسة شركات بمئات الموظفين بدأت تتشكّل بالفعل.

من منظور تصميم التنظيمات، هذا ليس مجرد تحسين للإنتاجية — إنه يُزعزع بنية الإدارة ذاتها. كانت الفرق التقليدية تُبنى وفق عدد الأفراد، وكان القادة يُحقّقون النتائج بإدارة الناس. لكن كيف يُدير مدير تقليدي مهندساً يُشغّل مئة وكيل؟ ربما لم يعد السؤال “ماذا أنجزت هذا الأسبوع؟” بل “ما الذي تعالجه وكلاؤك الآن؟”

ما معنى إدارة الوكلاء؟

في الفترة ذاتها، شرح هوانغ في تصريح آخر سبب عدم موت شركات البرمجيات: “AI agents still need an application layer to convert tokens into actual workflows” (وكلاء الذكاء الاصطناعي لا يزالون بحاجة إلى طبقة تطبيقية لتحويل الرموز إلى سير عمل فعلية). المنطق هو أنه كلما تكاثرت الوكلاء، ازدادت أهمية الطبقة التي تُنسّق بينها — أي قدرة التنسيق.

العمل الذي يتبقى بعد الأتمتة ليس التكراراً البسيط، بل الحكم والتنسيق. ماذا تُكلّف الوكيل؟ كيف تتحقق من نتائجه؟ بأي معيار تُحكّم حين يتعارض وكيلان؟ كل هذا يبقى من مهام الإنسان.

والمفارقة أن انتشار الوكلاء يزيد من ندرة القدرة على الحكم. ليس من يُتقن البرمجة، بل من يعرف ما يجب بناؤه، ومن يستطيع تقييم مخرجات الوكيل نقدياً، ومن يستطيع تفكيك هدف العمل إلى تعليمات واضحة — هؤلاء هم الموارد الأساسية في المنظمة.

هذا يُغيّر معايير التوظيف والتقييم. “هل تُتقن Python؟” أصبح أقل أهمية من “كيف تكتشف خطأ الوكيل؟” ولا مبالغة في القول إن التوظيف على أساس طريقة التفكير لا على أساس المهارات التقنية قد بدأ بالفعل.

تتغير طبيعة الإعداد الوظيفي أيضاً. كان إعداد المهندس الجديد تقليدياً يعني التعرّف على قاعدة الكود والاعتياد على عملية PR. في عصر الوكلاء، يعني الإعداد فهم محفظة الوكلاء التي يُشغّلها الفريق، وأيّ وكيل يتولى أيّ مهمة، وأين يُطلب تدخّل بشري. قد يكون أول ما يتعلمه المنتسب الجديد ليس بنية النظام، بل النظام البيئي للوكلاء.

ما يحدث حين يُصبح نصف راتبك من رصيد الرموز (Tokens)

في خطاب GTC Taipei الرئيسي في يونيو 2026، طرح هوانغ فكرة أكثر جذرية: دفع نصف الراتب الأساسي للمهندس على شكل رصيد من الرموز، بهدف تحقيق كفاءة تبلغ عشرة أضعاف. هذه ليست مجرد فكرة لسياسة الموارد البشرية — إنها إعلان عن تغيير وحدة قياس الإنتاجية ذاتها.

حتى الآن، كانت مقاييس قياس إنتاجية المطوّر ناقصة دائماً. عدد الـ commits وPRs وأسطر الكود لها صلة ضعيفة بالأثر الفعلي على الأعمال. مقاييس DORA (وتير النشر، وقت تحضير التغيير، وقت التعافي من الأعطال، معدل فشل التغيير) تُكمّل الصورة لكنها مؤشرات غير مباشرة.

فكرة رصيد الرموز تفتح زاوية مختلفة. موارد الحوسبة التي يستهلكها الوكيل تُحدّد نطاق العمل، وما إذا كانت المخرجات تُبرّر التكلفة يُصبح مقياس الأداء. قد يبدو هذا متطرفاً، لكنه يخلق ضغطاً ثقافياً لإثبات مدى كفاءة استخدامك للبنية التحتية للذكاء الاصطناعي هذا الشهر بالبيانات.

المهندس الذي يحصل على رصيد من الرموز يجب أن يُصمّم محفظة وكلائه ويُشغّلها بنفسه. أي وكلاء يُفعّل؟ متى يتدخّل؟ متى يثق بالأتمتة؟ هذه القدرات لا تظهر دون خبرة وسياق. لهذا يتغير معنى الأقدمية. القدرة على الحكم في الأنظمة تتقدم على خبرة البرمجة، والقدرة على تفكيك المهام تتقدم على العمق التقني.

هناك مفارقة أيضاً: من استهلك أكثر الرموز لم ينتج بالضرورة أكثر النتائج. المهندس الذي أدار وكلاءه بكفاءة لتحقيق النتيجة ذاتها بعدد أقل من الرموز قد يكون المهندس الأفضل. هذا له البنية ذاتها لتحسين تكاليف البنية التحتية السحابية. من عصر يكون فيه كتابة الكود بسرعة وغزارة فضيلة، إلى عصر تكون فيه توجيه الوكلاء بدقة وتحقيق أقصى نتيجة بأدنى موارد هي الفضيلة. ما يُكافئه التنظيم وما يقيسه يُعرّف ثقافته. فكرة رصيد الرموز هي أيضاً اقتراح لتغيير وحدة القياس تلك.

حين يصبح المصنع روبوتاً: التداعيات التنظيمية

في مقابلة مع Fortune في مايو 2026، وسّع هوانغ نظرته إلى العالم المادي: عالم تُديره الوكلاء، وتديره روبوتات أكثر، ويُصبح فيه المصنع بأكمله روبوتاً واحداً. هذا ليس خيالاً علمياً — إنه جارٍ بالفعل في مصانع أشباه الموصلات ومستودعات الخدمات اللوجستية.

من منظور ثقافي، ما تنطوي عليه هذه التحولات ليس السرعة بل إعادة توزيع المساءلة. حين يرتكب نظام مُؤتمَت خطأً، من المسؤول؟ حين ينشر وكيل كوداً معطوباً أو يعالج خطأً بشكل خاطئ — هل المسؤول من صمّمه؟ من أصدر له الأوامر؟ من أغفل المراجعة؟

هذه الأسئلة وُجدت قبل عصر الوكلاء. حين يمحو سكريبت أتمتة قاعدة بيانات إنتاجية — هل المسؤول من كتبه، أم من شغّله، أم من لم يُراجعه؟ هذا الجدل مألوف. الفرق هو الحجم. إن بلغ عدد الوكلاء المئات، وامتدت المهام التي يتولاها إلى ما هو أبعد من نشر الكود ليشمل قرارات تجارية، فإن حجم المخاطر الناجمة عن غموض هيكل المساءلة يتغيّر كلياً.

المنظمات التي تمتلك إجابات لهذه الأسئلة مسبقاً تتسبب في حوادث أقل. تحديد حدود نطاق الأتمتة بوضوح، وتثبيت القرارات التي تستلزم موافقة بشرية دائماً في صورة إجراءات، وجعل التحقق من مخرجات الوكلاء عادةً يشترك فيها الفريق بأكمله — هذا ما تبدو عليه ثقافة الجودة في عصر الوكلاء.

تظهر هذه المسألة خارج فرق البرمجيات أيضاً في وحدات تنظيمية أوسع. حين يقترح وكيل مبيعات على عميل سعراً خاطئاً، أو حين يُفسّر وكيل قانوني عقداً نمطياً بشكل خاطئ ويُرشد أحداً للتوقيع — هذه سيناريوهات بات فيها “خطأ الوكيل” خطراً على الشركة. لهذا فإن تبني الوكلاء هو قرار تقني وقرار حوكمة في آنٍ معاً. تحديد أيّ وكلاء تمنح أيّ صلاحيات، وأيّ مهام يجب أن يُؤكّدها إنسان دائماً، ليس قرار CTO وحده — يجب أن يكون قرار الفريق التنفيذي بأكمله.

بالنسبة لفرق منصات البنية التحتية للذكاء الاصطناعي، دخلت هذه النقاشات بالفعل في صورة أسئلة تشغيلية حقيقية. حين تُجدول مهام الوكلاء، وتُؤتمت عمليات النشر، وتُشغّل عشرات الوكلاء في وقت واحد في بيئة متعددة المستأجرين، فإن السؤال “من يراقب هذا؟” ليس مسألة مراقبة بل مسألة هيكل مساءلة. بناء طبقة التنسيق تقنياً وزرع ثقافة التنسيق داخل التنظيم هما أمران مختلفان تماماً.

الخاتمة: ثلاثة أشياء يجب على المنظمات اكتسابها في عصر الوكلاء

يصعب التنبؤ بالسرعة التي ستتحقق بها رؤية جنسن هوانغ. لكن الاتجاه واضح. انتشار الوكلاء لا يُلغي عمل الإنسان — بل يتطلب نوعاً مختلفاً من العمل. المنظمات التي تفشل في استيعاب هذا التحوّل كثقافة ستجد نفسها تمتلك الأدوات دون الكفاءة.

ثلاثة أشياء يجب على المنظمات اكتسابها في عصر الوكلاء:

ثقافة تبني القدرة على الحكم. كلما تحسّنت الوكلاء، كلما أصبح الحكم الدقيق هو الدور البشري. ماذا تُؤتمت؟ كيف تُلاحظ حين تكون مخرجات الوكيل خاطئة؟ كيف تُفكّك الأهداف إلى تعليمات؟ هذه مهارات مُكتسَبة لا تقنية بالمعنى الضيّق. دون بنية داخلية لبناء هذه القدرة في الفريق، ستُضاعف الوكلاء المخاطر بدلاً من تقليلها.

هيكل مرتبط بالمساءلة. كلما تكاثرت الوكلاء، صعب نسب نتيجة محددة إلى فضل شخص واحد أو خطئه. إهمال هذا الغموض يُفضي إلى ثقافة لا يتحمل فيها أحد المسؤولية. من الضروري إسناد ملكية محافظ الوكلاء، والتصريح بحدود نطاق الأتمتة، وجعل التحقق إجراءً رسمياً.

توقفات متعمّدة داخل السرعة. الوكلاء سريعون. قبول هذه السرعة دون مراجعة يحوّل المنظمة بأكملها إلى آلة تُكرّر الأخطاء بسرعة. يجب تصميم المراحل التي تُعالج فيها الوكلاء بسرعة والمراحل التي يتوقف فيها الإنسان لحظةً عند القرارات المهمة، بصورة واعية ومقصودة.

العالم الذي رسمه هوانغ لم يكتمل بعد. لكن ذلك الاتجاه في حركة بالفعل. يمكن شراء الأدوات، لكن لا يمكن استيراد الثقافة التي تُمكّن من استخدامها.

المصادر

• Jensen Huang, “Every engineer is going to have and manage hundreds of agents” — تصريحات خطاب GTC Taipei / Computex 2026. وردت في المدونة الرسمية لـ NVIDIA: NVIDIA GTC Taipei Computex 2026
• Jensen Huang, رؤية 75,000 موظف + 7.5 مليون وكيل ذكاء اصطناعي — Fortune, 2026-03-19: Jensen Huang on NVIDIA AI Agents Future of Work
• Jensen Huang, “operated by robots, managed by more robots” — Fortune, 2026-05-06: Agentic AI Robots
• Jensen Huang, “software companies aren’t dead because AI agents still need an application layer” — Yahoo Finance: NVIDIA CEO Jensen Huang AI Stock Boom
• Jensen Huang، هدف دفع نصف راتب المهندس كرصيد رموز — Semiconalpha Substack، نص خطاب GTC Taipei 2026: NVIDIA Keynote Computex 2026 Key

في يناير 2026 في المنتدى الاقتصادي العالمي بدافوس، جلس شخصان من صناعة الذكاء الاصطناعي على طاولة النقاش ذاتها: ديميس هاسابيس من Google DeepMind وداريو أموداي من Anthropic. المقاعد كانت واحدة، لكن الكلمات كانت مختلفة تماماً. كان هاسابيس صريحاً: “الأنظمة اليوم ليست قريبة من الذكاء الاصطناعي العام إطلاقاً. حل بعض مسائل إردوش الرياضية العسيرة لا يغيّر ذلك” (Fortune، 2026-01-23). أما أموداي، فقد حذّر في مقال نشره قبل أيام من أن مئة عام من التغيير الاقتصادي ستنضغط في 5 إلى 10 سنوات (CNBC، 2026-01-27).

أما جنسن هوانغ، فكان على مسرح GTC يتحدث عن شيء مختلف كلياً — ليس عن جداول زمنية للذكاء الاصطناعي العام، بل عن البنية التحتية والوكلاء الآن وفي اللحظة الراهنة. صورة من 75,000 موظف في NVIDIA يعملون جنباً إلى جنب مع 7.5 مليون وكيل ذكاء اصطناعي؛ مهندس واحد يدير مئات الوكلاء (Fortune، 2026-03-19؛ المدونة الرسمية لـ NVIDIA GTC Taipei، 2026-06).

الثلاثة في طليعة الذكاء الاصطناعي. ومع ذلك، وهم ينظرون إلى الظاهرة ذاتها، يرسمون مستقبلات متباينة. ليس هذا مجرد اختلاف في وجهات النظر — بل هو اختلاف هيكلي يعكس الموقع التنظيمي لكل منهم ومشهد المخاطر ومصالحه. وفي هذا الاختلاف يكمن ما تحتاج المنظمات البانية أن تأخذه.

ديميس هاسابيس: بدون فهم حقيقي، لا يوجد ذكاء اصطناعي عام

يمكن تلخيص رؤية هاسابيس بكلمة واحدة: الفهم (understanding).

المثال الذي ضربه في دافوس في يناير 2026 كان بسيطاً. حل مسائل الأولمبياد الرياضي أو كسر معضلات نظرية الأعداد عند إردوش لا يؤهل نظاماً لأن يُسمى ذكاءً اصطناعياً عاماً. المعيار الحقيقي هو القدرة على اقتراح نظريات فيزيائية جديدة باستقلالية — ما يسميه “اختبار أينشتاين” (CryptoBriefing). وهو يرسم خطاً حاسماً بين مطابقة الأنماط والفهم الحقيقي.

هذه الرؤية تمتد من مسيرته المهنية. انطلق من الذكاء الاصطناعي في الألعاب، فحل إشكالية التنبؤ ببنية البروتينات عبر AlphaFold، وهو الآن يسير على خارطة طريق نحو الذكاء الاصطناعي العام. كل مرحلة فتحت طبقة جديدة من الفهم. لذلك تحمل جداول زمنيته التفاؤل والحذر معاً.

في دافوس يناير 2026 قدّم 5 إلى 10 سنوات، قائلاً “لا يزال هناك حاجة إلى واحد أو اثنين من الاختراقات الجوهرية”. ثم بعد أربعة أشهر، في مقابلة Axios في مايو 2026، قدّم الجدول الزمني. ظهرت عبارة “الذكاء الاصطناعي العام آتٍ، ربما في غضون خمس سنوات”، مع اعترافه بأنه “تعمّد استخدام لغة استفزازية” (Axios، 2026-05-26). وفي الشهر ذاته، عند الإعلان عن Gemini Omni، كانت الكلمات التي اختارها “قفزة كبرى في فهم العالم” (major leap in world understanding).

في نهاية المطاف، يمكن تلخيص موقف هاسابيس هكذا: الأنظمة الحالية ليست ذكاءً اصطناعياً عاماً. لكن الاختراق يقترب. ومعيار الحكم على أصالة ذلك الاختراق ليس معياراً تقنياً بل معيار فلسفي — الفهم الحقيقي.

جنسن هوانغ: متفائل بالبنية التحتية يتحاشى جدل الذكاء الاصطناعي العام

لا يوجد في عالم هوانغ نقاش حول جداول زمنية للذكاء الاصطناعي العام. ما يراه هو التحول الهيكلي الجاري في هذه اللحظة بالذات.

في مقابلة Fortune في مارس 2026، قدّم هوانغ صورة من 75,000 موظف في NVIDIA يعملون جنباً إلى جنب مع 7.5 مليون وكيل ذكاء اصطناعي — 100 وكيل لكل إنسان. وفي الخطاب الرئيسي لـ GTC Taipei في مايو من العام ذاته، قال: “كل مهندس سيُعيَّن ليدير مئات الوكلاء.” المنطق: الوظائف لا تختفي؛ إنها تتحول إلى دور توجيه الوكلاء.

ومن أبرز تصريحات هوانغ رده على ادعاء أموداي بـ”تحرير البرمجيات”. ففي يونيو 2026 قال: “شركات البرمجيات لن تموت، لأن وكلاء الذكاء الاصطناعي أيضاً بحاجة إلى طبقة تطبيقات لمعالجة الرموز المميزة في سير عمل فعلية وتنسيقها” (Yahoo Finance). قيمة البرمجيات لا تتلاشى — الطبقة هي التي تتغير.

ما يميّز عالم هوانغ هو طريقة القياس. في GTC Taipei في يونيو 2026، كشف عن خطة لتخصيص نصف الراتب الأساسي للمهندس كميزانية رموز مميزة (tokens) لتحقيق كفاءة عشرة أضعاف (Semiconalpha Substack، نسخة خطاب GTC Taipei الرئيسي). إنه إعلان لقياس الإنتاجية ليس بالحدس بل باستهلاك الرموز المميزة.

يركّز هوانغ على كيفية تغيير البنية التحتية للذكاء الاصطناعي للعالم الآن أكثر من توقيت وصول الذكاء الاصطناعي العام. اهتماماته تكمن في الأجهزة والمنصة، ومن هذا المنظور العالم يتغير بما يكفي بالفعل.

داريو أموداي: التغيير سريع والصدمة ستكون غير متساوية

أموداي هو الأكثر صراحةً بين الثلاثة في الحديث عن صدمة سوق العمل.

في مقال مطوّل يناهز 20,000 كلمة نشره في يناير 2026، حذّر من أن الذكاء الاصطناعي سيتسبب في اضطراب “مؤلم بشكل غير عادي” (“unusually painful”)، وأن مئة عام من التغيير الاقتصادي ستنضغط في 5 إلى 10 سنوات (CNBC، 2026-01-27). وفي مايو من العام ذاته قال إن “وظائف بُنيت عبر أجيال قد تختفي” — ليس مجرد وظائف فردية، بل مسارات مهنية كاملة قد تزول، وهو بُعد زمني أطول للصدمة.

مع تصاعد استعدادات Anthropic للطرح العام الأولي (IPO) في مايو 2026، خفّف أموداي نبرته بعض الشيء. ذكرت Fortune أنه انتقل إلى إطار “التعزيز” (augmentation) (Fortune، 2026-05-26)، مع التركيز على التعاون بدلاً من استبدال العمالة. هذا التحول في التوقيت يستحق الانتباه. المخاوف الهيكلية لم تختفِ؛ القراءة الأدق هي أن استراتيجية التواصل هي التي تغيّرت.

أكثر تصريحات أموداي استفزازاً تتعلق باقتصادات البرمجيات. “البرمجيات ستصبح مجانية في جوهرها. قد يتبيّن أن الافتراض القائل بضرورة توزيع تكاليف تطوير البرمجيات على ملايين المستخدمين هو افتراض خاطئ” (WSJ/Davos 2026، The News.com.pk). قضية تهزّ أساس نموذج البرمجيات كخدمة (SaaS)، وتصطدم مباشرةً بادعاء هوانغ “طبقة التطبيقات ستنجو”.

أموداي يقود منظمة تسعى في آنٍ واحد إلى سلامة الذكاء الاصطناعي وتحقيق التجاري. تحذيراته صادقة، لكن حدّتها يتم معايرتها وفقاً للجمهور والتوقيت.

مقارنة الرؤى الثلاث: إطار المحاور الثلاثة

بوضع وجهات النظر الثلاث على المحاور ذاتها:

شيء واحد يظهر من هذا الجدول: ثمة إمكانية أن يكون الثلاثة على حق في الوقت ذاته. كل منهم يصف وجهاً مختلفاً من الواقع ذاته. هاسابيس يرسي معياراً معرفياً، وهوانغ يشرح التحول الهيكلي الجاري، وأموداي يتحدث عن التكلفة الاجتماعية. إن كانت الرؤى الثلاث صحيحة في آنٍ واحد، فماذا ينبغي للمنظمات البانية أن تفعل؟

ما ينبغي للمنظمات البانية أن تأخذه من كل منهم

من هاسابيس: أسّس “معيار الفهم” داخل منظمتك

واقعية هاسابيس هي مرشّح لتنقية المبالغات حول الذكاء الاصطناعي العام. “اختبار أينشتاين” الذي يطرحه هو معيار يمكن تطبيقه داخل أي منظمة.

عند تبني أدوات الذكاء الاصطناعي، يقع المنظمات البانية في الخطأ ذاته كثيراً: الانجذاب إلى أرقام المعايير. كون أداة مساعدة للبرمجة تجتاز اختبارات معينة لا يعني أن الأداة تفهم. وفق رؤية هاسابيس، تحتاج المنظمة إلى معيار داخلي يميّز بين المجالات التي يمارس فيها الذكاء الاصطناعي مطابقة الأنماط وتلك التي يُشترط فيها الفهم الحقيقي.

بعبارات ملموسة: المهام المتكررة والمنظّمة — سقالة الكود، صياغة الوثائق، تحويل البيانات — يمكن تفويضها للذكاء الاصطناعي. لكن المجالات التي تستلزم فهماً حقيقياً — الحكم الاستراتيجي، السياق الدقيق لعلاقات العملاء، التصميم التنظيمي — يجب أن تبقى ملكاً للإنسان. المنظمات التي تغيم فيها هذه الحدود تقع في مفارقة: كلما زاد تبنّيها للذكاء الاصطناعي، ضعُفت قدرتها على الحكم.

تحوّل هاسابيس في الجدول الزمني أيضاً يستحق المراجعة. الانتقال من “5–10 سنوات” في يناير إلى “ممكن في 5 سنوات” في مايو يعكس تحسناً فعلياً في القدرات لا انفعالاً بحمى السوق. بدلاً من مراقبة جدل الجداول الزمنية للذكاء الاصطناعي العام من بعيد، من الأجدى للمنظمات أن تضع معاييرها الخاصة وتعيد النظر فيها دورياً.

من هوانغ: ابنِ الكفاءة الجديدة لإدارة الوكلاء — الآن

أسرع ما تستطيع المنظمات البانية أخذه من رؤية هوانغ هو كفاءة تنسيق الوكلاء.

إن صحّت مقولة “كل مهندس سيدير مئات الوكلاء”، فإن الفجوة تتسع الآن بين المنظمات التي تبني هذه الكفاءة والمنظمات التي لا تفعل. مدى جودة توجيهك للوكلاء والتحقق منهم وتنسيقهم هو شكل جديد من الكفاءة التقنية.

اقتراح ميزانية الرموز المميزة (token budget) الذي طرحه هوانغ في GTC Taipei مثير للاهتمام من منظور الثقافة التنظيمية. إنه إعلان لقياس الإنتاجية ليس بالحدس أو الجهد المُدرَك، بل بيانات استخدام الذكاء الاصطناعي — عقلية Moneyball. المنظمات التي تقيّم المطورين بعدد الالتزامات (commits) أو ليالي العمل المتأخرة، في مقابل المنظمات التي تقيس كفاءة استخدام الذكاء الاصطناعي بالبيانات، ستكون في موقعين مختلفين تماماً بعد سنة أو سنتين.

تصريح هوانغ “شركات البرمجيات لن تموت” يتصل أيضاً مباشرةً بالاستراتيجية التنظيمية. حتى لو تحقق “تحرير البرمجيات” لأموداي، تبقى قيمة طبقة التنسيق التي تحول الرموز المميزة إلى سير عمل فعلية. إن استطعت احتلال موقع في تلك الطبقة، يتحول تأثير انخفاض أسعار البرمجيات إلى فرصة لا تهديداً.

من أموداي: واجه عدم تساوي الصدمة واستجب لها استباقياً

ما ينبغي للمنظمات البانية أن تأخذه من تحذيرات أموداي هو عادة إدراج بند التكاليف الاجتماعية في خارطة الطريق المتفائلة.

حتى بعد تخفيف نبرته في مايو، إن ظلّ “مسارات مهنية بُنيت عبر أجيال قد تختفي” سارياً، فإن المشكلة الأولى التي تواجهها المنظمات هي القلق من الأدوار داخل الفريق. كلما تسارع تبني الذكاء الاصطناعي، تحوّل سؤال “هل سيُستبدل دوري؟” من قلق فردي إلى مشكلة إنتاجية تنظيمية.

الاستجابة الاستباقية تسير في اتجاهين. الأول: إعادة التدريب — تنسيق الوكلاء، التحقق من جودة الذكاء الاصطناعي، التعمق في المجالات التي تستلزم الحكم الإنساني. الثاني: تحديد الحدود — حين تعرّف منظمة ما علناً “ما يستبدله الذكاء الاصطناعي” و”ما يعززه الذكاء الاصطناعي”، يفسح القلق المجال لإعادة تصميم الأدوار.

أن يُخفّف أموداي مستوى الإنذار خلال استعدادات الطرح العام هو تغيير في استراتيجية التواصل الخارجي. ينبغي للمنظمات البانية أن تتخذ التحذير ذاته — لا الاستراتيجية — معياراً لقرارها الداخلي. منظمة لديها خطط توظيف متفائلة ولا ميزانية لإعادة التدريب ستواجه أولاً النسخة الداخلية من الصدمة التي حذّر منها أموداي.

الاستراتيجية التنظيمية حين تصحّ الرؤى الثلاث في آنٍ واحد

إن كانت وجهات نظر الثلاثة صحيحة جزئياً، كيف ينبغي أن تتغير الاستراتيجية التنظيمية؟

إن صحّ هاسابيس: الذكاء الاصطناعي العام لم يصل بعد، والدور الإنساني في المجالات التي تستلزم فهماً حقيقياً مستمر. ينبغي وضع الذكاء الاصطناعي بوضوح كأداة مساندة وحماية القدرة الحكمية الجوهرية.

إن صحّ هوانغ: الوكلاء يعيدون تشكيل المنظمات الآن بالفعل. ابنِ كفاءات وأنظمة قياس الآن، أو ستتأخر.

إن صحّ أموداي: اقتصادات البرمجيات تتغير جوهرياً والصدمة ستكون غير متساوية. حدّد الأدوار الأكثر هشاشة داخل المنظمة وأوجد مسارات تحول.

المبادئ التنظيمية التي تستوعب الرؤى الثلاث في آنٍ واحد:

أولاً، لا تراهن على جدل الذكاء الاصطناعي العام. سواء كانت 5–10 سنوات لهاسابيس أو “قد يكون قريباً” لأموداي، فإن الاستراتيجية التنظيمية المرتبطة بجدول زمني للذكاء الاصطناعي العام ستكون دائماً عرضة للخطأ. بمعزل عن جدل الجداول الزمنية، دمج أقصى ما هو ممكن من قدرات الذكاء الاصطناعي الحالية في المنظمة هو موقف أكثر استقراراً.

ثانياً، عرّف إدارة الوكلاء كفاءةً جوهرية. في عالم هوانغ، هذا بات أمراً واقعاً في الحاضر. مدى جودة توجيه الوكلاء والتحقق منهم هو المؤشر الجديد للإنتاجية التنظيمية. هذه الكفاءة لن تنمو من تلقاء نفسها.

ثالثاً، استوعب تراجع قيمة البرمجيات بتعزيز طبقة التنسيق. كلما تحقق “تحرير البرمجيات” لأموداي، أصبح السؤال عمّن يمتلك “طبقة التطبيقات” التي يصفها هوانغ هو محور المنافسة. القدرة على تحويل رموز الذكاء الاصطناعي إلى قيمة تجارية فعلية هي الخندق الجديد.

رابعاً، أدِر القلق من الأدوار داخل المنظمة بالبيانات. إن صحّ تحذير أموداي، ستكون الصدمة داخل المنظمات غير متساوية. قياس الأدوار الأسرع تغيّراً وتوفير مسارات تحول هو المهمة القيادية الجديدة.

خاتمة: عدم اليقين كمادة خام للاستراتيجية

تبدو رؤى العمالقة الثلاثة متعارضة، لكنها في الحقيقة تنظر كل واحدة إلى أفق زمني مختلف وطبقة مختلفة. هاسابيس يتحدث عن معيار معرفي، وهوانغ عن التحول الهيكلي الجاري، وأموداي عن انضغاط التكلفة الاجتماعية عبر الزمن.

الرهان على واحد منهم فقط خطر. الأخذ بحذر هاسابيس وحده يعني تفويت التغيير الجاري اليوم. اتباع تفاؤل هوانغ وحده يتركك أعزل أمام الصدمة. الإيمان بتحذير أموداي وحده يعني التخلي عن الفرص المتاحة الآن.

دور المنظمة البانية هو استخلاص مبادئ الثقافة التنظيمية من تقاطع الرؤى الثلاث. احمِ المجالات التي تستلزم فهماً حقيقياً. ابنِ الكفاءة اللازمة لإدارة الوكلاء — الآن. سبق الصدمة غير المتساوية بالاستعداد لها.

عدم اليقين ليس عقبة تتجنبها. في لحظة تبدو فيها الرؤى الثلاث معاً مقنعة، المنظمات التي تستخدم ذلك عدم اليقين مادةً خاماً للاستراتيجية هي التي تنتقل إلى المرحلة التالية.

المصادر

• Fortune / WEF Davos 2026: https://fortune.com/2026/01/23/deepmind-demis-hassabis-anthropic-dario-amodei-yann-lecun-ai-davos/
• بودكاست WEF Radio Davos: https://www.weforum.org/podcasts/radio-davos/episodes/ai-agi-dario-amodei-demis-hassabis/
• Axios — مقابلة هاسابيس 2026-05-26: https://www.axios.com/2026/05/26/deepmind-ceo-demis-hassabis
• Sherwood News — هاسابيس: الذكاء الاصطناعي العام بعد 3–4 سنوات: https://sherwood.news/tech/google-deepminds-hassabis-agi-is-3-to-4-years-away/
• CryptoBriefing — هاسابيس واختبار أينشتاين: https://cryptobriefing.com/deepmind-hassabis-agi-einstein-test/
• Fortune — هوانغ: الوكلاء والموظفون 2026-03-19: https://fortune.com/2026/03/19/jensen-huang-nvidia-ai-agents-future-of-work-autonomous/
• Fortune — هوانغ: روبوتات المصانع 2026-05-06: https://fortune.com/2026/05/06/jensen-huang-servicenow-bill-mcdermott-agentic-ai-robos/
• المدونة الرسمية لـ NVIDIA GTC Taipei: https://blogs.nvidia.com/blog/nvidia-gtc-taipei-computex-2026-news/
• Yahoo Finance — هوانغ “شركات البرمجيات لن تموت”: https://finance.yahoo.com/markets/article/nvidia-ceo-jensen-huang-just-perfectly-explained-the-ai-stock-boom-130835624.html
• Semiconalpha Substack — نسخة خطاب GTC Taipei الرئيسي: https://semiconalpha.substack.com/p/nvidia-keynote-computex-2026-key
• CNBC — أموداي “unusually painful” 2026-01-27: https://www.cnbc.com/2026/01/27/dario-amodei-warns-ai-cause-unusually-painful-disruption-jobs.html
• The News.com.pk — أموداي “البرمجيات ستصبح مجانية”: https://www.thenews.com.pk/latest/1402953-software-will-become-essentially-free-warns-anthropic-ceo-amodei
• Fortune — تخفيف نبرة أموداي 2026-05-26: https://fortune.com/2026/05/26/sam-altman-dario-amodei-walking-back-ai-jobs-apocalypse-prophecies-ipo/

تقليص الفجوة بين النماذج المفتوحة الأوزان وقدرات الكودينج في الطليعة قصة متواصلة على مدى العام الماضي، غير أن GLM-5.2 في يونيو 2026 يمثّل نقطة تحوّل واضحة في هذا المسار. أعلن غييرمو راوخ، الرئيس التنفيذي لـ Vercel، دهشته العلنية من قدرات GLM-5.2 في الكودينج، ما أثار جدلاً واسعاً في أوساط المطورين، وسرعان ما تلاه إعلان نتائج اختبارات مستقلة تُظهر تفوّقه على GPT-5.5 في مهام كودينج متعددة طويلة الأفق. التفصيل الأهم هو السعر: تقديم أداء مماثل بنحو سُدس التكلفة، إلى جانب إتاحة الأوزان بموجب رخصة MIT، يدفع هذا النموذج إلى ما هو أبعد من مجرد أخبار الاختبارات المعيارية، ليصبح متغيراً حقيقياً في قرارات البنية التحتية.

بالنسبة لمنصة مثل ThakiCloud تُشغّل منصة AI/ML SaaS على Kubernetes، هذا التوليف لا يمكن تجاهله. إن أمكن نشر نموذج كودينج على مستوى الطليعة داخل حدود بيانات العميل، بعيداً عن الاعتماد على واجهات برمجية مغلقة، وبتكلفة محكومة، فذلك منتج قابل للتسويق مباشرةً للعملاء الذين تشترطون الاستضافة المحلية أو الذكاء الاصطناعي السيادي. تتناول هذه المقالة أولاً التحقق من الحقائق المتاحة للعامة حول GLM-5.2، ثم توضيح ما تستلزمه الاستضافة الذاتية فعلياً، وأخيراً دلالات ذلك من منظور منصتنا. تشغيل النموذج بأنفسنا على ثمانية وحدات H200 خارج نطاق هذه المقالة، وعليه فإن كل رقم مذكور هنا مستقى من وثائق ومصادر إعلامية متاحة للعموم، وما لم نتمكن من التحقق منه مباشرةً يُشار إليه صراحةً.

ما هو هذا النموذج

GLM-5.2 نموذج Mixture-of-Experts ضخم أصدرته Z.ai (zai-org)، وهي مختبر صيني للذكاء الاصطناعي، في 13 يونيو 2026. إجمالي المعاملات 744B، في حين تبلغ المعاملات المُفعَّلة لكل رمز حوالي 40B، وهو مستوى مشابه للجيل السابق GLM-5.1. هذه هي جوهر بنية MoE: توسيع الطاقة الإجمالية إلى حد كبير مع تقييد عدد الخبراء المشاركين فعلياً في كل خطوة استنتاج، مما يُبقي تكلفة الاستنتاج في حدود المقبول. قبل الانزعاج من رقم 744B، المهم إدراك أن الحساب الفعلي يجري على مستوى الـ 40B، وهو الرقم الحاسم عند تقدير تكلفة الاستضافة الذاتية.

التغيير الأبرز هو نافذة السياق. يدعم GLM-5.2 مليون (1M) رمز، أي نحو خمسة أضعاف حد 200K رمز تقريباً في GLM-5.1. يبلغ الحد الأقصى لحجم المخرجات 131,072 رمزاً. في مهام الكودينج طويلة الأفق كتحميل قاعدة كود ضخمة كاملةً في السياق وتنفيذ إعادة هيكلة شاملة عبر ملفات متعددة أو تتبع الأخطاء، يغدو حجم السياق هذا حاسماً. ويتجلى توجه التدريب نحو الكودينج في نتائج الاختبارات المعيارية.

الرخصة MIT، وهي من أكثر رخص المصدر المفتوح تساهلاً مع أدنى قيود على الاستخدام التجاري. يُعدّ هذا تمييزاً جوهرياً عن بعض نماذج الأوزان المفتوحة التي تحمل بنوداً تحظر الاستخدام التجاري. الأوزان متاحة على Hugging Face (zai-org/GLM-5.2-FP8)، والمصدر والوصفات في مستودع GitHub (zai-org/GLM-5)، وطريق بدء سريع متاح عبر مكتبة Ollama (glm-5.2).

GLM-5.2  (744B total parameters, MoE)
        │
        ▼
   MoE Routing ── Only ~40B active experts computed per token
        │
        ├── 1M token context (approx. 5x vs GLM-5.1)
        └── Coding-first training
                │
                ▼
        Long-horizon coding workloads
                │
                ▼
   SWE-bench Pro 62.1 · Terminal-Bench 2.1 81.0

License: MIT open-weight · Self-hosting: FP8 · 8x H200 · vLLM / SGLang

من إجمالي الطاقة البالغة 744B، لا يُفعَّل سوى نحو 40B معاملة لكل رمز عبر توجيه MoE. يتضافر السياق البالغ 1M والتدريب المتخصص في الكودينج لتحقيق أداء متميز في مهام الكودينج طويلة الأفق.

الاختبارات المعيارية: أين تفوق GLM-5.2 على GPT-5.5

يستحق التحقق المباشر من ادعاءات الاختبارات المعيارية التي تقف في قلب التغطية الإعلامية. وفقاً للمعايير المستقلة، يُصنَّف GLM-5.2 حالياً بوصفه النموذج الأوزان المفتوحة الأبرز في الكودينج. الأرقام التفصيلية على النحو التالي.

طريقة القراءة: في SWE-bench Pro، يتقدم GLM-5.2 بنتيجة 62.1 على GPT-5.5 البالغة 58.6، لكنه يقصر عن Claude Opus 4.8 بنتيجة 69.2. في Terminal-Bench 2.1 يسجّل 81.0 ويُصنَّف في المرتبة الثانية قريباً من Claude Opus 4.8. الملخص الدقيق ليس “تفوّق على جميع نماذج الطليعة” بل “يقع مباشرةً تحت أفضل النماذج المغلقة بينما يتفوق على GPT-5.5، وهو واجهة برمجية مغلقة في نفس الفئة، في عدة مهام كودينج طويلة الأفق.”

التكلفة تعمّق هذه الصورة. تشير التقارير إلى أن GLM-5.2 يحقق هذا المستوى من الأداء بنحو سُدس تكلفة GPT-5.5. فارق نقطة أو نقطتين في اختبار معياري مقبول في الغالب من الناحية العملية؛ فارق ستة أضعاف في التكلفة كافٍ لإعادة رسم استراتيجية البنية التحتية. للإشارة، يُسعَّر الباقة المُدارة الخاصة بـ Z.ai والمسماة GLM Coding Plan بحوالي 10 دولارات شهرياً للنسخة الخفيفة، و30 دولاراً للنسخة الاحترافية، و80 دولاراً للنسخة القصوى، مما يُتيح نقطة دخول منخفضة التكلفة للفرق الراغبة في التقييم قبل الالتزام بالاستضافة الذاتية.

الاستضافة الذاتية: ما الذي يلزم لنشر 744B

إتاحة الأوزان لا تعني أن النموذج يعمل على جهاز محمول. فيما يلي ملخص لمتطلبات الأجهزة والبرمجيات المستقاة من أدلة النشر العامة ووصفات vLLM الرسمية لاستضافة نموذج MoE بحجم 744B ذاتياً. الأرقام أدناه منقولة من وثائق عامة لا مُعاد إنتاجها على إعدادنا الخاص من ثمانية وحدات H200، وسيلزم التحقق منها في البيئة الفعلية قبل النشر الإنتاجي.

نقطة التفتيش المُضغَّطة بـ FP8 تبلغ حجمها نحو 750GB. يُشير أحد التقارير إلى أن نسخة FP8 تستهلك نحو 753GB من ذاكرة GPU للأوزان وحدها. ميزة FP8 تكمن في تخفيض متطلبات الذاكرة إلى النصف مقارنةً بـ BF16. خادم مُجهَّز بثمانية وحدات H200 يوفر نحو 1,128GB من إجمالي VRAM، مما يُتيح هامشاً لذاكرة KV cache بعد تحميل أوزان FP8. عند أحمال عمل السياق البالغ 1M، يجب تفعيل FP8 KV cache، وحتى حينها يعمل الإعداد الثُماني H200 بهامش ضيّق.

الإطاران الأكثر شيوعاً في الخدمة: يشترط vLLM الإصدار 0.23.0 كحد أدنى، وينشر النموذج موزَّعاً على ثمانية وحدات GPU بالتوازي الموتري (tensor-parallel-size 8).

# Conceptual vLLM example (actual flags and versions require verification against official recipes)
vllm serve zai-org/GLM-5.2-FP8 \
  --tensor-parallel-size 8 \
  --kv-cache-dtype fp8 \
  --max-model-len 1000000

SGLang الخيار الآخر، وهو طبقة خدمة توليد منظّم مصممة حول الدُّفعات والطلبات المتزامنة. يدعم الفكّ المقيَّد للشيفرة بصورة افتراضية ويشارك KV cache عبر الطلبات بواسطة RadixAttention، مما يجعله نقطة انطلاق طبيعية لأحمال العمل ذات الطلبات المتزامنة الكثيرة. يُستخدم عادةً مع التوازي بين الخبراء (--enable-moe-ep) وFP8 KV cache (نمط fp8_e5m2).

النقطة التشغيلية الجوهرية واضحة: FP8 KV cache يُنصف استهلاك ذاكرة KV مع تأثير هزيل على الجودة، وهو ليس اختيارياً عند سياق 1M بل ضرورة. التوجيه الشائع في جميع حالات النشر هو أن FP8 هي نقطة البداية الواقعية لأي تقييم استضافة ذاتية أولي.

تطبيق GLM-5.2 على منصة ThakiCloud K8s AI/ML SaaS

تُجدوِل منصة ThakiCloud للذكاء الاصطناعي أحمال عمل GPU على Kubernetes باستخدام Kueue، وتخدّم النماذج عبر vLLM، وتعزل استنتاجات المستأجرين المتعددين عن بعضها. يندمج GLM-5.2 في هذه البنية بحد أدنى من التعديلات.

أولاً، يُجيب مباشرةً على الطلب المتنامي للاستضافة المحلية والذكاء الاصطناعي السيادي. في بيئات كالقطاع المالي والجهات الحكومية والدفاع حيث يُحظر توجيه البيانات عبر واجهة برمجية خارجية أصلاً، لا يمكن استخدام حتى أكفأ النماذج السحابية المغلقة. GLM-5.2 بوصفه نموذجاً مفتوح الأوزان بموجب رخصة MIT يُتيح تشغيل نموذج كودينج على مستوى الطليعة داخل حدود بيانات العميل. سجِّل عقدة H200 ثُمانية في قائمة انتظار Kueue وتولَّ خدمتها بـ vLLM، ويصبح لديك مساعد كودينج لا تغادر منه بايتة واحدة المحيط الأمني. هذا يسير في الاتجاه ذاته تماماً الذي تبنّته ThakiCloud في مقترحها القيمي للاستضافة المحلية والذاتية.

ثانياً، هيكل التكلفة. إن صحّ رقم سُدس التكلفة، يصبح بمقدورنا أن نعرض على العملاء بنية تحتية بسعر ثابت قابل للتنبؤ قائمة على الاستضافة الذاتية بدلاً من إعادة بيع واجهة برمجية مغلقة. خاصية 40B معاملة نشطة في MoE تُبقي تكلفة الاستنتاج لكل طلب في نطاق مُسيطَر عليه رغم حجمه الإجمالي البالغ 744B. مشاركة وحدات GPU بين المستأجرين المتعددين وإعادة استخدام KV cache عبر RadixAttention في SGLang يرفعان معدل الإنتاجية لكل عقدة، مما يُخفّض تكلفة الوحدة أكثر.

ثالثاً، سياق 1M يتوافق مع أحمال العمل الوكيلة التي تتجه نحوها منصتنا. وكيل كودينج متخصص يُحمّل قاعدة الكود الداخلية بأكملها أو مستودع التوثيق في السياق ويعمل باستمرارية طويلة الأفق ليس منتجاً ممكن البناء على نموذج قصير السياق. غير أن سياق 1M يستهلك ذاكرة KV cache بصورة مكثفة، لذا في بيئة متعددة المستأجرين يلزم أن يتضمن التصميم سياسات تُحدد الحد الأقصى لطول السياق لكل مستأجر ويُطبَّق ذلك على مستوى طبقة الخدمة.

القيود والحجج المضادة

يجب أن تُصاغ الحجة المضادة بوضوح مماثل للحجة الأصلية. GLM-5.2 ليس الأفضل في كل الجوانب. تأخّر نتيجته في SWE-bench Pro (62.1) عن Claude Opus 4.8 (69.2) بأكثر من سبع نقاط. حين تكون جودة الكودينج المطلقة الأولوية القصوى وتسمح البيئة بتمرير البيانات عبر واجهة برمجية خارجية، تظل النماذج المغلقة الأفضل خياراً عقلانياً. قيمة GLM-5.2 ليست “الأقوى مطلقاً” بل “الأقرب إلى الأقوى ضمن فئة النماذج القابلة للاستضافة الذاتية.”

تستوجب أرقام الاختبارات المعيارية ذاتها تعاملاً متحفظاً. كل رقم في هذه المقالة منقول من تغطية مستقلة ووثائق عامة لا مُستخلَص من قياسات أجريناها بأنفسنا في ظروف موحّدة. تتأثر نتائج الاختبارات المعيارية بحزمة التقييم وصياغة المطالبات وإعدادات أخذ العينات، لذا يستلزم أي تقييم جدي للتبني إعادة القياس على المهام الداخلية التمثيلية قبل استخلاص أي استنتاجات.

الحاجز أمام الاستضافة الذاتية واقعي كذلك. عقدة ثُمانية H200 تنطوي على تكلفة اقتناء وتشغيل باهظة، والاستخدام الفعلي لسياق 1M يُقلّص عدد الطلبات المتزامنة التي يمكن خدمتها قبل أن يُشكّل ضغط KV cache عقبة. “يدعم سياق 1M” و”يخدم سياق 1M للمستأجرين المتعددين في آن معاً” مشكلتان بمستويَي صعوبة مختلفَين جذرياً. علاوةً على ذلك، نظراً لأن هذا النموذج صادر عن مختبر صيني، قد يشترط بعض العملاء مراجعة من منظور سلسلة التوريد والحوكمة. كون النموذج مفتوح الأوزان يُتيح فحص الأوزان مباشرةً وتشغيلها في بيئة معزولة هوائياً، مما يُعالج هذا القلق إلى حد بعيد، لكنه بند يجب أن يظهر صراحةً في قرار التبني.

خلاصة القول، الصواب قراءة GLM-5.2 لا على أنه “بديل للنماذج المغلقة بلا تحفظات” بل على أنه “ظهور بديل جدي لواجهات برمجية مغلقة في أحمال العمل التي تكون فيها الاستضافة المحلية وسيادة البيانات والسيطرة على التكلفة أموراً جوهرية.” وتلك أحمال العمل التي تتفوق فيها ThakiCloud أكثر من غيرها.

المصادر

• Z.ai’s open-weights GLM-5.2 beats GPT-5.5 on multiple long-horizon coding benchmarks for 1/6th the cost (VentureBeat)
• GLM-5.2: Features, Setup, Benchmarks, and Model Switching Guide (DataCamp)
• zai-org/GLM-5 (GitHub)
• zai-org/GLM-5.2-FP8 (Hugging Face)
• GLM-5 and GLM-5.1 Series Usage (vLLM Recipes)
• Deploy GLM-5.2 on GPU Cloud (Spheron)
• Running GLM-5.2 at Home: SGLang, vLLM, Transformers, KTransformers (Groundy)

في يونيو 2026، انتشرت مقالة على منصة X بعنوان “40 سير عمل مع Claude Opus 4.8 لكسب المال أثناء نومك”، وأحدثت موجة في أوساط المطورين. للوهلة الأولى تبدو كدعاية تسويقية نمطية للدخل السلبي، وهذا الإطار مبالغ فيه فعلاً. غير أن تحت هذه المبالغة هندسةً تعمل بالفعل: سير عمل ديناميكي، وتوزيع متوازٍ للعوامل الفرعية، وبوابات تحقق يجب اجتيازها قبل تجميع أي نتائج.

تفصل هذه المقالة بين أمرين: أولاً، ما هو تسويق وما هو حقيقي في ادعاء “كسب المال أثناء النوم”. ثانياً، الجانب الحقيقي، أي الطلب الذي يفرضه توزيع العوامل الطويل الأمد غير المراقَب على البنية التحتية. تشغّل ThakiCloud منصة SaaS للذكاء الاصطناعي والتعلم الآلي مبنية على Kubernetes، وخدمة أحمال GPU هي منتجها الأساسي، لذا نهتم بهيكل الفوترة لأحمال الاستنتاج الكامنة تحت العناوين الرنانة أكثر من اهتمامنا بالعناوين ذاتها. وقد اقتصرنا في الحقائق المستشهَد بها على ما تأكّد من البيانات الوصفية العلنية للمقالة، ولم نُورد ادعاءات الإيرادات غير الموثّقة.

ماهية سير العمل “الليلي”: بين المبالغة والواقع

كتب المقالة الأصلية @eng_khairallah1، وانتشرت من خلال إعادة تغريد. كان المحتوى يضم رابطاً مختصراً عبر t.co يشير إلى مقالة واحدة على X. الجزء المتعلق بـ “كسب المال” في العنوان لا يمكن التحقق منه؛ لم يُقدَّم دليل موضوعي على ما كسبه أحد فعلاً، وهذه الأرقام غير قابلة للتحقق أصلاً. هذا الإطار يُصنَّف بدقة ضمن التسويق.

بعد تجريد المحتوى من التسويق، يتضح الجوهر التقني. أولاً: يستطيع العامل تحليل قائمة مهام والمضي فيها دون أن يضغط إنسان مفتاحاً في كل خطوة. ثانياً: يمكن إرسال المهام الفرعية المستقلة إلى عدة عوامل فرعية في آنٍ واحد ومعالجتها بالتوازي. ثالثاً: قبل تسليم النتائج للإنسان، تمر المخرجات بمرحلة تحقق إضافية من زاوية نظر مختلفة. هذه الأمور الثلاثة حقيقية، وتستخدم ThakiCloud بالفعل الأنماط ذاتها في أدواتها الداخلية.

بمعنى آخر، ما أثار الاهتمام ليس “الذكاء الاصطناعي يكسب المال وحده”، بل “أصبحت العوامل قادرة على تنفيذ مهام متعددة الخطوات دون مراقبة لفترات مطوّلة”. هذا التمييز مهم لأن الأخير يُولّد حملاً حقيقياً على البنية التحتية.

سير العمل الديناميكي والعوامل الفرعية المتوازية

الهيكل الأساسي لسير العمل الديناميكي بسيط. منسق واحد يستقبل مهمة كبيرة، يقسّمها إلى فروع، يفوّض كل فرع لعامل فرعي، ثم يجمع النتائج ويُجمّعها في مخرج واحد متسق. المفتاح هو أن الفروع المستقلة تعمل بالتزامن. إذا احتاجت عشرة ملفات للتحليل، بدلاً من قراءتها واحداً تلو الآخر، تعمل عشرة فروع في آنٍ واحد، وينتهي المسار الكامل عند انتهاء أبطأ فرع.

[ المنسّق ]
        |
        +--> [العامل الفرعي A] استكشاف / قراءة  (نموذج منخفض التكلفة)
        +--> [العامل الفرعي B] استكشاف / قراءة  (نموذج منخفض التكلفة)
        +--> [العامل الفرعي C] تنفيذ / تلخيص   (نموذج متوسط)
        |        ...عشرات الفروع المتوازية...
        v
[ تجميع ] --> [ بوابة التحقق ] --> [ تركيب ] --> نتيجة واحدة نظيفة

ثمة سوء فهم شائع هنا: التوازي ليس جيداً دائماً. لا يحقق فائدة إلا عندما تكون الفروع مستقلة فعلاً. إذا كانت مرحلة تالية تحتاج لرؤية جميع نتائج المراحل السابقة قبل المتابعة، فذلك حاجز، والحاجز يجبر الجميع على انتظار أبطأ فرع. سير العمل المصمم جيداً يُقلّل الحواجز ويسمح لكل عنصر بالمرور عبر المسار بسرعته الخاصة. هذا المبدأ ذاته تعتمده ThakiCloud في تصميم المهارات والمسارات: تقييد التكوين الحر بإطار عمل مُتحقَّق منه لرفع متوسط الجودة.

بوابات التحقق التي تُغلق الحلقة

الخطوة الأكثر غياباً في هذه البنية هي التحقق. وهذا الغياب هو أكثر أسباب تراجع الجودة شيوعاً. تشغيل عشرات العوامل الفرعية يُضاعف أيضاً المخرجات التي تبدو معقولة لكنها خاطئة. تجميعها دون تصفية يُراكم الهلوسات.

لذا يجب إغلاق التوزيع المتوازي بمرحلة تحقق. للمخرجات البرمجية، التحقق حتمي: شغّل الاختبارات، وإذا لم تنجح فالمرور للمرحلة التالية محظور. للمخرجات الحكمية أو البحثية التي لا تحمل إجابة واضحة، أرسل عدة محكّمين بمنظور مختلف مع توجيه “اعترض على هذا الادعاء”، وإذا اعترضت الأغلبية فاستبعد تلك النتيجة. المحور هو أن المحكّمين يجب أن يكونوا مناهضين ويستخدموا عدسة مختلفة عن العامل الأصلي، وليس إعادة تشغيل المطالبة ذاتها. إعادة طرح السؤال نفسه ليست تحققاً.

عندما تتراجع الجودة، يميل الناس غالباً للترقية الفورية في مستوى النموذج. لكن السبب الأكثر شيوعاً ليس ضعف النموذج، بل غياب مرحلة التحقق كلياً. إضافة بوابة تحقق معادية واحدة أكثر جدوى من الناحية المالية بكثير من استبدال جميع العمال بنموذج مكلف.

الحقيقة التكلفوية: عمال رخيصون وبوابات مكلفة فقط

ما تُخفيه عبارة “كسب المال أثناء النوم” هو أن هذا التنفيذ غير المراقَب له تكلفة حقيقية. تشغيل عشرات العوامل الفرعية لفترات مطوّلة يستهلك الرموز والحوسبة بالقدر ذاته. في حالة تشغيلية سابقة، استهلكت جلسة مراقبة واحدة أكثر من نصف تكلفة اليوم بأكمله، ليس بسبب إخفاقات الذاكرة المؤقتة، بل لأن سياقاً ضخماً تُضرب بسعر نموذج مكلف عبر دورات متكررة.

النظام المُصمَّم جيداً لذلك يفصل التكلفة والجودة حسب المرحلة. الفروع ذات الإنتاجية العالية كالاستكشاف والقراءة والبحث تذهب للنموذج الأرخص. الأعباء المتوازنة كالتنفيذ والمراجعة تحصل على نموذج متوسط. المراحل الحرجة فحسب كالتركيب والتحقق تذهب للنموذج الأغلى. عمال رخيصون وبوابات مكلفة فقط. مخالفة هذا المبدأ بتشغيل كل شيء على أعلى مستوى تجعل مكاسب الجودة وهمية بينما تنفجر التكاليف.

الفخ الثاني هو الاستعلام المتواصل. وضع فحوصات مراقبة دورية كمتابعة الأسعار أو التحقق من الحالات داخل حلقة عامل ساخنة يعني حدوث استنتاج مكلف عند كل نبضة حتى حين لا يوجد ما يفعله العامل. هذه المراقبة المتكررة يجب أن تعمل كسكريبت بسيط على جدولة زمنية، وتستدعي إنساناً أو عاملاً فقط عند اكتشاف شيء يستحق الانتباه. اقتصاديات الأتمتة غير المراقَبة لا تأتي من “تشغيل العامل أطول وقت ممكن” بل من “استدعائه عند الحاجة الفعلية فقط”.

التطبيقات والدلالات لمنصة ThakiCloud K8s للذكاء الاصطناعي والتعلم الآلي

هنا تبدأ المصالح المباشرة لـ ThakiCloud. من منظور البنية التحتية، التوزيع المتوازي للعوامل الطويل الأمد غير المراقَب هو حمل GPU وحوسبة قابل للفوترة. عشرات العوامل الفرعية التي تستدعي الاستنتاج في آنٍ واحد تُنشئ ملف حمل مختلفاً تماماً عن جلسة محادثة قصيرة: ليس طلبات قصيرة ومتفرقة، بل طلبات طويلة ومتزامنة بشكل انفجاري.

حُزمة ThakiCloud مبنية للتعامل مع هذا الحمل تحديداً. Kueue على Kubernetes يُجدوِل أعمال GPU ويوزعها بعدالة؛ vLLM يخدم النماذج؛ والعزل متعدد المستأجرين يفصل أحمال عمل عوامل العملاء المختلفين. ذروات الاستنتاج المتزامن التي تظهر أثناء توزيع العوامل تُمتص بواسطة آليات الجدولة والأولوية في Kueue، ويمكن التحكم في الفصل بين مستويات النماذج للعمال والبوابات بتوجيه الطلبات إلى نقاط نهاية نماذج مختلفة في طبقة الخدمة.

من الناحية التجارية، يتصل هذا مباشرة بالطلب على الذكاء الاصطناعي المحلي والسيادي. لكي يتمكن عامل غير مراقَب من فحص قاعدة كود كاملة أو قراءة وثائق داخلية أو تنفيذ مهام طويلة الأمد، يجب أن تتدفق البيانات باستمرار إلى واجهة برمجة تطبيقات خارجية. بالنسبة للمنظمات ذات متطلبات الأمان الصارمة، وخاصة تلك التي تخضع قيود تصدير البيانات لقيود، فإن إمكانية تشغيل هذه الأحمال داخل بنيتها التحتية الخاصة شرط مسبق للتبني. هذا بالضبط سبب تركيز ThakiCloud على الاستضافة الذاتية والكفاءة التكلفوية. لكي يصبح “العامل الذي يعمل أثناء نومك” منتجاً حقيقياً، يجب أن تكون البنية التحتية التي يعمل عليها قابلة للتحكم وهيكل الفوترة شفافاً.

القيود والحجج المضادة

نبدأ بأقوى اعتراض. سير العمل الديناميكي ليس حلاً شاملاً. إدراج التوزيع المتوازي في عمل لا يحتاج تحليلاً كالسؤال الفردي أو تعديل ملف واحد يزيد فقط في تكلفة التنسيق دون تحسين النتائج. فوائد التوازي تظهر فقط عندما تكون الفروع مستقلة فعلاً؛ إجبار التوازي على مهام متشابكة التبعيات يُدخل انتظار الحواجز وتعارض النتائج مما يُبطئ العملية فعلياً.

ثانياً، التنفيذ غير المراقَب يُضاعف المخاطر عند ضعف بوابات التحقق. عدم وجود إنسان يراجع كل خطوة يعني أن للنتائج الخاطئة مساحة أكبر للتدفق بصمت إلى المرحلة التالية. المهام التي تنطوي على تغييرات لا رجعة فيها كالنشر أو ترحيل البنية لا ينبغي تسليمها لحلقة غير مراقَبة دون بوابات تحقق وموافقة بشرية معاً.

ثالثاً، سرد “كسب المال أثناء النوم” يُشوّه التوقعات. ما تُقلّله هذه التقنية فعلاً هو العمل البشري المتكرر، لا الحكم البشري والمسؤولية. مع نمو الأتمتة غير المراقَبة، تزداد قيمة بوابات التحقق المُصمَّمة جيداً وحراس التكلفة وحدود الصلاحيات الواضحة. هذا بالضبط سبب سعي ThakiCloud لتوفير هذه القدرة على التحكم في طبقة البنية التحتية.

المصادر

• @eng_khairallah1, “40 Claude Opus 4.8 Workflows That Make Money While You Sleep” (X Article, 2026-06)
• إعادة التغريد الأصلية: x.com/hjguyhan/status/2069026741155442835

نظرة عامة: المشكلة التي خلقها تكاثر المهارات

عندما تشغّل نظام وكيل ذكاء اصطناعي لفترة طويلة، تتراكم المهارات بشكل طبيعي. في البداية عشرات، ثم مئات، وذات يوم تفتح الكتالوج لتجد 1,620 مهارة. هذا هو الوضع الحالي للبنية التحتية لوكيل ThakiCloud القائم على Claude Code. نحو 1,620 مهارة محلية، و55 وكيلاً فرعياً، و36 قاعدة دائمة التشغيل، و22 أمر شريط مائل، و12 خطافاً تعمل معاً.

أول حدس يواجهك هنا هو “كلما زادت المهارات، كان الوكيل أقوى.” هذا خطأ. مع تضاعف المهارات، يصبح الوكيل في الواقع أبطأ، ويختار مهارة خاطئة، أو يبدأ في الإجابة خاماً دون استخدام أي مهارة على الإطلاق. المشكلة لم تكن في عدد المهارات، بل كانت في التوجيه.

تسجّل هذه المقالة مبادئ تصميم التوجيه المكتسبة من تشغيل منظومة مهارات تضم أكثر من 1,600 مهارة بمفردي. تتناول كيف طُبّق تعزيز استرجاع المهارات (SRA, arXiv:2604.24594) في بيئة تشغيل حقيقية، وما الذي تقوم به بوابة BM25، ولماذا تحدد جودة الوصف دقة البحث، وبصدق، ما الذي لا يزال ناقصاً.

لماذا تُبطّئك المهارات الكثيرة: ضريبة الضوضاء

نافذة السياق في Claude Code محدودة. وضع قائمة المهارات كاملة في السياق في كل دورة يقلل الرموز المتاحة للعمل الفعلي. هذه هي “ضريبة الضوضاء.” مجرد سرد أسماء وأوصاف مختصرة لـ1,620 مهارة يصل إلى عشرات الآلاف من الرموز. حقن هذا في كل دورة يُفجّر التكاليف ويُضيّع النموذج بين أسماء مهارات غير ذات صلة.

المشكلة الأشد خطورة هي “المطابقة القسرية.” وهي ظاهرة التقاط النموذج للمهارة الخاطئة لأن اسمها يتداخل جزئياً مع شيء في قائمة المهارات. على سبيل المثال، تحميل مهارة 4phase-debugging لطلب بسيط مثل “صحّح هذه الخطأ” وتشغيل سير عمل معقد، أو استخراج مهارة technical-writer لتعديل ملف بسيط. مع تضاعف المهارات، تزداد احتمالية هذه الضوضاء.

تُعرّف ورقة SRA (arXiv:2604.24594) هذه المشكلة بأن “ضوضاء المشتتات هي الخطر الأساسي للدقة في بيئات تضم أكثر من 1,000 مهارة.” اتجاه الحل واضح: بدلاً من إظهار جميع المهارات للوكيل، يتم تصفية المرشحين القليلين المرتبطين فعلاً بالطلب الحالي فقط.

بوابة SRA + BM25 ذات المرحلتين

الهيكل الذي اعتمدته ThakiCloud يجمع بين بروتوكول SRA المكون من ثلاث مراحل وبوابة تلقائية قائمة على BM25.

flowchart TD
    A[وصول طلب المستخدم] --> B{مرشح مسبق\nتحية/أمر/نفس الدورة؟}
    B -- تخطي --> C[مرور بدون رموز]
    B -- متابعة --> D[بحث BM25 التلقائي\nretrieve.py]
    D --> E{هل توجد مرشحات\nتتجاوز SCORE_MIN 6.0؟}
    E -- لا يوجد --> F[لا مرشحات = تنفيذ أصلي]
    E -- موجود --> G[أفضل 5 مرشحات TOP_K\nحقنها في السياق]
    G --> H{فرز النموذج\nأصلي أم يستحق مهارة؟}
    H -- أصلي --> I[تنفيذ مباشر بالأدوات المدمجة]
    H -- يستحق مهارة --> J[دمج\nاختيار المهارة المثلى الواحدة]
    J --> K[تحميل وتنفيذ عبر أداة Skill]

المرحلة 1: الاسترجاع - البحث التلقائي BM25

خطاف skill-router-gate.py مُوصَّل بحدث UserPromptSubmit. في اللحظة التي يُرسل فيها المستخدم الموجّه، يُشغَّل هذا الخطاف أولاً.

الخطوة الأولى للخطاف هي المرشح المسبق. التحيات (“مرحباً”)، والتأكيدات البسيطة (“فهمت”)، والأوامر الصرفة (تعديل مسار الملف مباشرة) تمر فوراً بدون بحث BM25. إذا كانت هناك كلمة مفتاحية لتشغيل مهارة صريحة (/review، /debug، إلخ)، تُوجَّه قسراً إلى تلك المهارة.

الخطوة الثانية هي بحث BM25. يُفهرس retrieve.py المقدمة الأمامية لـ SKILL.md وتعريفات الوكيل وكتالوج المهارات بـ BM25، ثم يحسب الصلة بالاستعلام الحالي. مستعيناً بالترجيح IDF وقاموس مرادفات كوري-إنجليزي عبر اللغتين (25+ زوجاً من المفردات)، يُضيّق نطاق 1,200+ مهارة في الوقت الفعلي. يتم تصفية المرشحين الحاصلين على SCORE_MIN (6.0) أو أعلى فقط، بحد أقصى TOP_K (5)، وحقنهم في السياق. إذا كان الطلب مطابقاً للدورة السابقة، يُتجاوز إعادة الحقن. تُسجَّل جميع نتائج التوجيه في state/skill-router.jsonl.

المرحلة 2: الفرز - أصلي مقابل يستحق مهارة

ينظر النموذج إلى قائمة المرشحين المحقونة ويحكم على طبيعة المهمة الحالية.

• المهام الأصلية: تعديل الملفات، وأوامر git، والأسئلة والأجوبة البسيطة، وتعديل سطر واحد من الكود، وgrep. المهام التي تكفيها الأدوات المدمجة. تُنفَّذ مباشرة بدون تحميل مهارة.
• المهام التي تستحق مهارة: الكتابة المنظمة، ومراجعة الكود متعددة النطاقات، وتنسيق خطوط الأنابيب، والتحليل المتخصص في النطاق، وتوليد الوثائق. المهام التي تستفيد من مهارة تحتوي على قائمة تحقق أو سير عمل.

عندما يكون الحكم غامضاً، الأصلي هو القيمة الافتراضية. المعيار هو ما إذا كانت تكلفة سير العمل المنظم تستحق العناء.

المرحلة 3: الدمج - اختيار المهارة المثلى الواحدة

بمجرد تصنيفها كمهمة تستحق مهارة، يُختار مرشح واحد من قائمة BM25، ويُذكر سبب الاختيار في جملة واحدة، ويُحمَّل عبر أداة Skill. إذا كان هناك مرشحان أو أكثر بنفس المستوى تقريباً، يُسأل المستخدم. إذا لم يكن هناك مرشحون، يُعاد إلى الأصلي. المطابقة القسرية لا تُمارَس.

تُدار أيضاً مجموعة وكلاء منفصلة. يتم البحث عن الـ55 وكيلاً فرعياً في فهرس منفصل عن مجموعة المهارات العامة، بحيث تسير المهارات الموجهة للمستخدم ووكلاء التنسيق بدون تشويش.

انضباط جودة الوصف

دقة BM25 تعتمد في نهاية المطاف على جودة وصف كل مهارة. BM25 يقرأ النص. إذا كانت الأوصاف مبهمة، تحصل المهارات المتشابهة على درجات متقاربة للاستعلام ذاته وتظهر مرشحات خاطئة.

صيغة الوصف التي تُفرضها ThakiCloud تتكون من ثلاثة عناصر.

description: >-
  [ما تفعله المهارة - جملة واحدة، بضمير الغائب].
  Use when [كلمات مفتاحية للتشغيل بالإنجليزية والكورية].
  Do NOT use for [الحالات التي لا تناسب هذه المهارة] (use [اسم المهارة المجاورة]).

الجملة الأولى هي القدرة. تُعرّف “ما تفعله” بفعل واحد. الجملة الثانية هي مشغّل التعبير. يجب أن تتضمن الإنجليزية والكورية معاً. طلبات الكورية تطابق المشغلات الكورية؛ طلبات الإنجليزية تطابق المشغلات الإنجليزية. وجود جانب واحد فقط يُضيّع نصف الاستعلامات. الجملة الثالثة هي الحدود. تُحدد “الأنماط التي لا ينبغي أن تأتي إلى هذه المهارة” و”المهارة المجاورة التي ينبغي استخدامها بدلاً منها.” هذا هو جوهر إزالة الغموض.

يجب أن تكون الأوصاف في حدود 1,024 حرفاً. هذا الحد الأقصى يراعي كفاءة فهرسة BM25 وتكلفة حقن السياق.

انضباط إضافي أُدخل في 2026-06-22 هو Skill IR (مخطط النية-المشغّل). قبل إنشاء مهارة جديدة معقدة، تُملأ ستة حقول أولاً: intent (أي مشكلة واحدة تحلها)، وtriggers (كلمات مفتاحية للتعبير بالإنجليزية والكورية)، وinputs (ما تستقبله)، وoutputs (ما تُنتجه)، وboundaries (ما لا تفعله + المهارات المجاورة)، وreferences (السكريبتات/القواعد المعتمدة). يُقلل تثبيت هذا المخطط أولاً من تعارض المشغلات والمهارات المكررة في مرحلة كتابة الوصف. لا يُطبَّق على المهارات البسيطة.

هناك درس واحد مستخرج من الإخفاق. “إذا كان اسم المهارة يبدو معقولاً، فبالتأكيد ستُعثر عليها حتى لو كان الوصف تقريبياً” وهم. BM25 يقرأ الوصف الكامل، ليس الاسم. حتى لو كان الاسم رائعاً، إذا لم تكن هناك مشغلات في الوصف، لن يظهر في نتائج البحث.

القياس: ما الذي تحسّن

تُعلَن منهجية المعيار أولاً. الأرقام أدناه هي نتائج من معيار مجموعة ذهبية مكونة من 63 حالة. إنها ليست قيماً مقاسة في كل دورة في بيئة التشغيل الفعلية. إنها تقيس الدقة المحتملة للمحرك؛ قد تختلف دقة التشغيل.

مقارنة قبل/بعد إصلاح الموجّه (sra-bench، 63 حالة):

قبل الإصلاح، Recall@5 بنسبة 44% يعني أن المهارة ذات الصلة كانت موجودة في أفضل 5 مرشحين أقل من نصف الوقت. في هذه الحالة، حتى لو اختار النموذج بشكل مثالي، كانت الإجابة الصحيحة غائبة في نصف الأحيان. بعد الإصلاح ارتفع إلى 73.3%، وانخفضت الهلوسة (تحميل مهارة غير موجودة أو غير ذات صلة تماماً) إلى 0%.

الأسباب الرئيسية الثلاثة للتحسين كانت: أولاً، المهارات التي تفتقر إلى مشغلات كورية في أوصافها جُدّدت دفعة واحدة. ثانياً، الحالات التي تتداخل فيها أوصاف المهارات المجاورة وتُسبب تعارض الدرجات فُصلت بجمل “لا تستخدم لـ”. ثالثاً، تم ضبط عتبة SCORE_MIN لـ BM25 بحيث لا تدخل المرشحات الضوضائية ذات الدرجات المنخفضة إلى السياق.

دقة Top-1 بنسبة 31.1% لا تزال منخفضة. الفجوة بين 73% (الإجابة الصحيحة في أفضل 5) و31.1% تمثل “قدرة النموذج على اختيار الأمثل من بين المرشحين.” هذا مجال يمكن الاستمرار في تحسينه من خلال تحسين الوصف، لكن السقف الحالي [تقديري] في حدود 50%.

أُجريت أيضاً تجربة منفصلة على الطلبات المركبة (مثل: “ابحث في هذا، وتحقق من الحقائق، واصنع ملف docx، وانشره على Slack”). لـ12 حالة، كان step_coverage لاستراتيجية الاسترجاع بالاستعلام الواحد (SINGLE) 32.8%. تجميع خطوات متعددة في استعلام واحد يُسبّب إهمال مهارات الخطوات اللاحقة. هذه المشكلة لم تُحلّ بالكامل بعد؛ الطلبات المركبة تُعالَج جزئياً عبر تحليل الوكيل إلى مهام فرعية واسترجاع كل منها بشكل منفصل.

المنتجة في Praxis

يُعمَّم هيكل التوجيه هذا على نفس المبادئ في منتج SaaS الخاص بـ ThakiCloud، Praxis. يحتوي موجّه مهارات Praxis على هيكل ثنائي المرحلة. المرحلة 1 تُضيّق المرشحين المتعلقين بالنطاق من مجموعة مهارات كبيرة. المرحلة 2 تُقيّم سبعة عوامل (تطابق النية، وتغطية المشغّل، وانتهاك الحد، وكفاية المدخلات، وملاءمة المخرجات، وتبعيات المرجع، وتكلفة السياق) لاختيار المهارة المثلى.

الاختلاف الجوهري هو تنويع الحجم. في تشغيل Claude Code المحلي، يرى وكيل واحد 1,600 مهارة، لكن في Praxis تنفصل مجموعة المهارات لكل مستأجر ويُعيد الموجّه الضبط وفقاً لسياق كل مستأجر. انضباط BM25 + البوابة + الوصف المُتحقق منه في التشغيل الفردي يُطبَّق مباشرة على المنتج متعدد المستأجرين.

الجزء الذي يتغير أكثر خلال المنتجة هو مسؤولية كتابة الوصف. في التشغيل المحلي، يكتب المشغّل الأوصاف مباشرة ويتحقق منها بالمعايير. في Praxis، هناك حاجة إلى بوابة للتحقق تلقائياً من جودة الوصف عند تسجيل العملاء للمهارات. بدون هذه البوابة، تتعارض المهارات التي يسجلها العملاء وتنخفض دقة التوجيه. هذه البوابة قيد التطوير حالياً.

القيود والدروس المستفادة

ملخص صادق.

قيود BM25: BM25 بحث قائم على مطابقة المفردات. “راجع الكود” و”أعطني تعليقاً على PR” متكافئان دلالياً لكنهما مختلفان لغوياً. قاموس المرادفات يُعوّض جزئياً لكن هناك حدود. المقاربة الهجينة التي تجمع البحث الدلالي (القائم على التضمين) مع BM25 أكثر دقة نظرياً. ومع ذلك، حالت تكلفة حساب التضمين وتعقيد إدارة الفهرس دون الاعتماد عليها حتى الآن.

معيار المجموعة الذهبية مقابل واقع التشغيل: الأرقام المذكورة في قسم القياس هي نتائج لـ63 حالة مُعدّة مسبقاً. في الاستخدام الفعلي، تختلط صياغات غير متوقعة وطلبات مركبة وحالات حدودية للنطاقات. قد تختلف أرقام المعيار عن تجربة التشغيل.

تكلفة صيانة المهارات: تحديث 1,620 مهارة بشكل فردي أمر غير قابل للتطبيق. عندما تصبح الأوصاف قديمة، تنحرف المشغلات وتنخفض الدقة. حالياً تُحدَّث بعض المهارات من خلال حلقة أتمتة ليلية، لكن لا توجد طريقة منهجية لضمان حداثة جميع المهارات.

تحليل الطلبات المركبة: كما أُشير سابقاً، الطلبات المركبة التي تمتد عبر خطوات متعددة ضعيفة حالياً في التوجيه. جعل الوكيل يُحلّل المهام الفرعية ويسترجع كل مرحلة يُعطي step_coverage بنسبة 42.5% في ظروف oracle، وهو أعلى من الاسترجاع الواحد (32.8%)، لكن هذا السقف أيضاً منخفض. توجيه الطلبات المركبة مجال يحتاج إلى مزيد من البحث إلى جانب تحسين جودة الوصف.

“كثرة المهارات لا تعني الأفضل”: هذه الجملة هي جوهر هذه المقالة. المهارات ضريبة. ترفع تكلفة السياق، وتكلفة الصيانة، وضوضاء التوجيه. قبل إضافة مهارة، يجب أن تسأل أولاً “هل سيُخطئ الوكيل بدون هذه المهارة؟” إذا كانت الإجابة “لا”، لا ينبغي إنشاء المهارة.

1,620 عدد كبير. لكن المهارات المستخدمة بنشاط يومياً أقل بكثير. الباقي أصول كامنة لا يمكن استرجاعها عند الحاجة إلا إذا كان التوجيه يعمل. بدون التوجيه، تصبح ضوضاء.

بوابة SRA + BM25 + انضباط جودة الوصف هي البنية التحتية التي تجعل تلك الأصول الكامنة قابلة للاستخدام فعلاً. إنها ليست مثالية ومستمرة في التحسين، لكن الاتجاه صحيح.