نظرة عامة

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

تكمن المشكلة في أن منصات الذكاء الاصطناعي الحالية لا تعالج هذين الهدفين معًا. إذ تتمتع واجهات برمجة تطبيقات نماذج اللغة الكبيرة المستندة إلى السحابة بقدرات هائلة، غير أن البيانات تمر عبر خوادم خارجية. وكثيرًا ما تفتقر أطر عمل الوكلاء مفتوحة المصدر إلى مسارات التدقيق أو ضوابط الوصول. في المقابل، تشترط الجهات التنظيمية إمكانية تتبع كل قرار يتخذه الذكاء الاصطناعي، وفقًا للوائح الإشراف المالي الإلكتروني ومعيار 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/

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

عندما تشغّل نظام وكيل ذكاء اصطناعي لفترة طويلة، تتراكم المهارات بشكل طبيعي. في البداية عشرات، ثم مئات، وذات يوم تفتح الكتالوج لتجد 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 + انضباط جودة الوصف هي البنية التحتية التي تجعل تلك الأصول الكامنة قابلة للاستخدام فعلاً. إنها ليست مثالية ومستمرة في التحسين، لكن الاتجاه صحيح.

نظرة عامة: كيف يتمكن شخص واحد من إدارة هذا الحجم؟

يتكرر هذا السؤال كثيراً. نحو 1620 مهارة، 55 وكيلاً فرعياً، 36 قاعدة دائمة التفعيل، 22 أمر مائل (slash command)، و12 ربط (hook). في الليل، تُشغّل وظائف launchd غير المراقبة حلقات تطورها الذاتي. يتزامن جهازان – جهاز المنزل وجهاز المكتب – عبر فرع main واحد. مهندس واحد فقط يُدير كل هذا بمفرده.

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

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

هذه المقالة هي المرة الأولى التي يُكشف فيها عن منظومة التشغيل الكاملة دفعةً واحدة. وتشرح كيف يتشابك توجيه المهارات والتطور الليلي وضبط التكاليف في نظام تشغيلي واحد – وكيف أصبحت هذه التجربة المصدر الأصلي لمنتج ThakiCloud Praxis.

لمحة عامة عن المكدس: بنية الأتمتة في 4 طبقات

ينقسم المكدس الكامل إلى أربع طبقات.

graph TD
    subgraph Layer1["الطبقة 1: الواجهة"]
        CMD["22 أمراً مائلاً<br/>/morning /eod /review /ship /debug"]
        HOOK["12 ربطاً<br/>UserPromptSubmit · Stop · PreToolUse"]
    end

    subgraph Layer2["الطبقة 2: التوجيه"]
        GATE["بوابة موجّه المهارات<br/>SRA + تعيين تلقائي BM25"]
        RULES["36 قاعدة دائمة التفعيل<br/>التكاليف · التنسيق · توجيه النماذج · الأمان"]
    end

    subgraph Layer3["الطبقة 3: التنفيذ"]
        SKILLS["~1620 مهارة<br/>.claude/skills/"]
        AGENTS["55 وكيلاً فرعياً<br/>.claude/agents/"]
    end

    subgraph Layer4["الطبقة 4: التطور الذاتي الليلي"]
        M["23:30 دورة أحلام memkraft"]
        S["00:00 selfharness-evolve"]
        E["00:15 skill-evolution"]
    end

    CMD --> GATE
    HOOK --> GATE
    GATE --> RULES
    RULES --> SKILLS
    RULES --> AGENTS
    SKILLS -.->|التطور الليلي| S
    S --> E
    E --> SKILLS

الطبقة 1 (الواجهة) هي نقطة التواصل المباشر مع الإنسان. تُشكّل الأوامر المائلة مثل /morning و/eod و/review و/ship و/debug إيقاع اليوم. تعمل الربطات بهدوء في المساحات البينية. ربط UserPromptSubmit يُشغَّل قبل كل طلب، أما ربط Stop فيتحقق من ملفات العلامات عند انتهاء المهمة.

الطبقة 2 (التوجيه) هي دماغ هذا المكدس. من بين 1620 مهارة، يجب إيجاد المهارة المناسبة للطلب الحالي. بوابة موجّه المهارات تُؤتمت هذه المهمة. المبادئ التفصيلية مشروحة في توجيه المهارات SRA.

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

الطبقة 4 (التطور الذاتي الليلي) هي الميزة التمييزية الجوهرية لهذا النظام. بينما ينام المهندس، يُحسّن المكدس نفسه بنفسه.

التوجيه في كل لحظة: ما تفعله بوابة المهارات

جميع مهارات 1620 موجودة تحت .claude/skills/، لكنها لا تُحمَّل كلها في كل دورة. فعل ذلك وحده كفيل بتبديد الميزانية على تكلفة السياق. إذا افترضنا أن وصف المهارة الواحدة يُكلّف 300-500 رمز [تقديري]، فإن تحميلها جميعاً يستهلك مئات الآلاف من الرموز في كل دورة. عوضاً عن ذلك، يُضيّق skill-router-gate.py – المرتبط بربط UserPromptSubmit – المرشحين عبر بحث BM25 ويُدرجهم في السياق.

تؤدي البوابة ثلاثة أدوار.

أولاً، التصفية المسبقة. الدورات التي لا تحتاج إلى مهارة – التحيات، والتأكيدات، والأوامر الصرفة – تمر فوراً دون أي استهلاك للرموز. تشغيل BM25 على كل طلب سيكون هو نفسه تكلفةً.

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

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

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

على سبيل المثال، جاء حقل quality_gate في مهارة محتوى مجمّع بثلاثة أشكال مختلفة في مرة من المرات: "passed" وTrue و{...}. أعطِ النموذج حرية وسيُخرج Sonnet نتائج مختلفة في كل استدعاء. الآن يقيس الكود مباشرةً بـlen() ويُجري فحوصات العتبات. لا يُوثق بالأرقام التي يُبلّغ عنها النموذج ذاتياً.

الأوامر المائلة البالغة 22 أمراً هي نوع من الماكروهات تعمل فوق هذا التوجيه. يُشغّل /morning مزامنة git لبداية اليوم، ثم إيجاز Google Workspace، ثم خط أنابيب الأسهم بالتسلسل. يجمع /eod مزامنة Cursor وإرسال الإصدار وملخص Slack. لا يحتاج الإنسان إلى تذكّر الترتيب في كل مرة.

تطور كل ليلة: حلقة launchd الليلية

هذا هو الجزء الأكثر إثارة للدهشة. بينما ينام المهندس، تعمل ثلاث وظائف launchd بالتسلسل.

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

00:00 selfharness-evolve. يُحلّل مقاييس أداء المهارات الحالية ويُقيّم جودة الأوصاف، وتعارضات المشغّلات، وتكرار الاستخدام. يُحدد المهارات التي تحتاج إلى تحسين ويُولّد مقترحات التحسين. تعمل هذه الوظيفة دائماً على launchd المحلي، وليس على routine السحابة أبداً. في صناديق رمل السحابة، لا يمكن لـbash أن يعمل بشكل صحيح وقد تُزوَّر البوابات.

00:15 skill-evolution. تُطبّق ما اقترحه selfharness. تُنقّح أوصاف المهارات، وتُولّد مهارات جديدة عند اكتشاف أنماط جديدة، وتُنظّف المحتوى الذي لم يعد صالحاً.

المبادئ التفصيلية لحلقة التطور الذاتي مشروحة بشكل منفصل في هارنس التطور الذاتي الليلي.

ثمة مبدأ تصميم مهم هنا. هذه الوظائف الليلية مبدعة في محتوى المهارات، لكن الكود يمتلك التنسيق. لا يكتب النموذج JSON يدوياً ولا يُبلّغ ذاتياً عن أحكام الجودة. يقيس الكود بـlen()، ويتحقق بالتعبيرات النمطية (regex)، ويُعيد إرسال أي شيء يقل عن العتبة. الطريقة الوحيدة لجعل نموذج من مستوى Sonnet يُنتج تنسيقاً متسقاً عبر مهام الدُّفعات المتكررة هي إزالة الحرية منه.

منع تسرب التكاليف: ضوابط أمان من 4 طبقات

كان ثمة يوم وصلت فيه تكاليف الذكاء الاصطناعي اليومية إلى 705 دولارات. جلسة مراقبة واحدة (9.4 ساعات، 1145 دورة) استأثرت بـ54% من الإجمالي. ضوابط الأمان الأربع الطبقات المستخدمة اليوم ظهرت من ذلك الحادث. الأرقام التفصيلية منشورة في ضوابط توجيه تكاليف LLM.

الطبقة 1: جدول توجيه النماذج. الاستكشاف وقراءة الملفات وgrep تستخدم haiku (~1x). الترميز والمراجعة وكتابة الاختبارات تستخدم sonnet (~4x). الهندسة المعمارية والاستدلال متعدد الخطوات المعقد يستخدمان opus (~19x). يجب تحديد معامل model دائماً عند استدعاء أداة Agent. الإغفال يُشغّل النموذج على النموذج الافتراضي للجلسة (أعلى تكلفة). الوكلاء الفرعيون من نوع haiku لا يُولّدون وكلاء فرعيين إضافيين أبداً. إذا لم تُحلّ مهمة بواسطة haiku، فإن المهمة قد صُنّفت بشكل خاطئ.

الطبقة 2: قاعدة 2K رمز. أي استدعاء أداة متوقع أن يُعيد أكثر من 2K رمز يُفوَّض إلى وكيل فرعي. يقرأ الوكيل الفرعي ويعالج ويُعيد الملخص فقط. يحتفظ السياق الرئيسي بالملخص ومسار الملف فحسب. تُضغط مصفوفات JSON الكبيرة بأكثر من 50% باستخدام headroom SmartCrusher قبل إدراجها. استجابات أدوات MCP هي المصدر الخفي الأكبر لتكلفة السياق. قراءات صفحات Playwright، واستجابات GitHub API، وقراءات خيوط Notion يمكنها إفراغ آلاف الرموز دفعةً واحدة. أي شيء يتجاوز 200 سطر يُحفظ في /tmp/ctx-{task-id}.json، ولا يصل إلى السياق الرئيسي سوى المخطط والعيّنة.

الطبقة 3: حظر الاستطلاع الدوري. تشغيل مراقبة على مدار 24 ساعة كحلقة ساخنة لـClaude محظور. مهام الاستطلاع الدوري كلقطات الأسعار ومقارنات الحالة وفحوصات الصحة تعمل كوظائف cron من launchd وترسل تنبيه Slack فقط عند اكتشاف شذوذات. يحقق ذلك نفس الأثر بتكلفة صفر دولار لـClaude. الجلسة التي استمرت 9.4 ساعات واستهلكت 381 دولاراً أرست هذا المبدأ.

الطبقة 4: تصعيد المراجعة الراجعة. تبدأ المهارات المجدولة بـsonnet افتراضياً. يتتبع skill_model_policy.json النموذج وسلسلة الفشل لكل مهارة. إذا فشلت مهارة max_fail_streak مرات متتالية، تُرقَّى تلك المهارة وحدها تلقائياً إلى opus ويُرسل إشعار إلى Slack #h-report. تُعيد دورة العمل النظيفة ضبط السلسلة على الصفر. بدلاً من ترقية كل شيء إلى opus، تُرقَّى فقط المهارات التي ثبت عملياً أن لديها مشكلة في الجودة.

مع تشابك هذه الطبقات الأربع، يبقى يوم العمل النموذجي الآن مسيطراً عليه بـsonnet. يُنتج نفس حجم المخرجات بتكلفة أقل بكثير. الأرقام الكاملة لتصميم ضبط التكاليف منشورة في ضوابط توجيه تكاليف LLM.

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

هذا هو المنتج: Praxis ومنصة الذكاء الاصطناعي

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

منظومة التشغيل الموصوفة حتى الآن تُثبت شيئين.

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

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

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

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

للصراحة التامة.

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

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

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

المزامنة بين أجهزة متعددة تتطلب انضباطاً. إذا تفرّق جهاز المنزل وجهاز المكتب على فرع ميزات، فإن تحديثات الأمس على جهاز المنزل لن تظهر في جلسة المكتب اليوم. في الواقع، جرت جلسة على فرع ميزات يتأخر 25 إيداعاً عن origin/main، فلم تنعكس تعليمات الاستراتيجية المطبّقة اليوم السابق مما أفضى إلى أحكام خاطئة. كل العمل يجري على main، وكل مهمة مكتملة يجب رفعها (push) فوراً. بسيط، لكن إهماله يُفضي إلى اتخاذ قرارات بناءً على كود قديم. أصبحت عادةً تشغيل git log --oneline HEAD..origin/main قبل بدء أي جلسة.

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

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

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

في المقالة التالية، أعتزم تناول مبادئ تصميم بيئة مهارات Praxis – ولا سيما سبب أهمية التمييز بين الهارنس الرفيع والمهارة السمينة.

نظرة عامة

تواجه كل منظمة تُشغِّل مجموعة GPU مؤسسية الحقيقة المُزعجة ذاتها: الفجوة بين حجم الاستثمار في الأجهزة ومعدل الاستخدام الفعلي. عندما تبلغ معدلات توقف GPU نسبة 30-50% في مجموعة مؤلفة من 1000 وحدة، يُترجَم ذلك إلى هدر يبلغ عشرات الملايين من الدولارات سنويًا [تقديري/أرقام وثائق العرض التقديمي]. هذه ليست تكلفة الأجهزة – بل هي تكلفة دفع فواتير الطاقة والتبريد دون إجراء أي حسابات.

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

تعالج منصة ThakiCloud AI هذه الاختناقات الثلاثة بمزيج من Kueue والمجدول المخصص KAI، إلى جانب vLLM وKEDA Scale-to-Zero. يشرح هذا المقال كيفية عمل كل آلية فعليًا، وما هي قرارات المعمارية التي تُتيح استرداد التكاليف.

3 نقاط تتسرب منها تكاليف GPU

النقطة 1: توقف GPU بلا جدولة

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

النقطة 2: تأخر التدريب الموزع بسبب غياب Gang Scheduling

لا يمكن لمهام التدريب الموزع (DDP وMegatron وDeepSpeed وما شابهها) بدء حساب ذي معنى إلا عند انطلاق جميع حاويات العمل في الوقت ذاته. بغياب Gang Scheduling، تحدث الظاهرة التالية:

• مهمة تتطلب 8 وحدات GPU تُطلق 6 حاويات، لكن حاويتين تظلان معلقتين (Pending) بسبب شح العقد
• تحتجز الحاويات الست المُشغَّلة وحدات GPU انتظارًا للحاويتين المعلقتين دون تنفيذ أي حسابات
• تستمر حالة الاحتلال الجزئي هذه لعشرات الدقائق، وأحيانًا لساعات

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

النقطة 3: احتجاز GPU المستمر من قِبَل نقاط نهاية الاستدلال

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

Kueue Fair-Share + Gang Scheduling

تسلسل ClusterQueue و LocalQueue

Kueue هو نظام إدارة قوائم انتظار أعباء العمل الأصيل في Kubernetes، ويتكون من طبقتين: ClusterQueue وLocalQueue. تُحدِّد ClusterQueue سياسة تخصيص GPU عبر المجموعة بأكملها؛ أما LocalQueue فهي قائمة الانتظار المرئية لكل مساحة أسماء فردية (فريق/مشروع).

# مثال مفاهيمي -- ليس التقاطًا تنفيذيًا
apiVersion: kueue.x-k8s.io/v1beta1
kind: ClusterQueue
metadata:
  name: research-cluster-queue
spec:
  namespaceSelector: {}
  resourceGroups:
    - coveredResources: ["cpu", "memory", "nvidia.com/gpu"]
      flavors:
        - name: "h100-flavor"
          resources:
            - name: "nvidia.com/gpu"
              nominalQuota: 64      # الحصة الافتراضية لكل فريق
              borrowingLimit: 32    # حد أقصى لاستعارة الحصة غير المستخدمة من الفرق الأخرى
              lendingLimit: 16      # حد أقصى للإقراض للفرق الأخرى
  cohort: "all-teams"              # مجموعة المشاركة العادلة

حقل cohort هو جوهر المشاركة العادلة. يمكن لموارد ClusterQueue المنتمية إلى المجموعة ذاتها استعارة nominalQuota غير المستخدمة من بعضها البعض ضمن حدود borrowingLimit. إذا لم يكن الفريق A يستخدم وحدات GPU الخاصة به في الليل، يمكن للفريق B استعارتها مؤقتًا؛ وعند تقديم الفريق A طلبات جديدة تُعاد إليه الأولوية.

graph TD
    CQ["ClusterQueue (research-cluster-queue)<br/>cohort: all-teams<br/>H100 x 64 nominalQuota"]
    LQ_A["LocalQueue: team-a<br/>namespace: ml-team-a"]
    LQ_B["LocalQueue: team-b<br/>namespace: ml-team-b"]
    LQ_C["LocalQueue: team-c<br/>namespace: ml-team-c"]
    WL_A["WorkloadAdmission<br/>مهمة تدريب A<br/>طلب GPU: 8"]
    WL_B["WorkloadAdmission<br/>دُفعة استدلال B<br/>طلب GPU: 4"]
    WL_C["WorkloadAdmission<br/>الضبط الدقيق C<br/>طلب GPU: 16"]

    CQ --> LQ_A
    CQ --> LQ_B
    CQ --> LQ_C
    LQ_A --> WL_A
    LQ_B --> WL_B
    LQ_C --> WL_C

في هذا الهيكل، تتتبع Kueue معدل استهلاك nominalQuota لكل فريق وتتخذ قرارات القبول (admission) لضمان التوزيع العادل داخل المجموعة. عندما يتجاوز فريق ما nominalQuota الخاص به في حالة استعارة ويُقدِّم فريق آخر طلبًا، تنخفض أولوية حِمل العمل المستعار تلقائيًا.

مُجدِّل KAI و Gang Scheduling

يضع مُجدِّل Kubernetes الافتراضي الحاويات بشكل فردي. يُتطلَّب Gang Scheduling لأعباء العمل مثل التدريب الموزع حيث يجب انطلاق جميع الحاويات في آنٍ واحد. تُنفِّذ ThakiCloud ذلك عبر مكوِّن المُجدِّل المخصص KAI (Kubernetes AI).

المبدأ الأساسي لـ Gang Scheduling هو “الكل أو لا شيء.” لن تُوضَع أي حاوية من مهمة التدريب الموزع الطالبة 16 وحدة GPU على أي عقدة حتى يمكن تأمين الـ 16 وحدة في آنٍ واحد. يُلغي ذلك الهدر الناجم عن الاحتلال الجزئي.

# مثال مفاهيمي -- ليس التقاطًا تنفيذيًا
apiVersion: batch/v1
kind: Job
metadata:
  name: distributed-training-llama3
spec:
  parallelism: 16   # 16 حاوية عمل تعمل في وقت واحد
  completions: 16
  template:
    metadata:
      annotations:
        kueue.x-k8s.io/queue-name: "team-a-local-queue"
    spec:
      schedulingGates:
        - name: "kueue.x-k8s.io/admission"   # بوابة الجدولة حتى منح Kueue القبول
      containers:
        - name: trainer
          resources:
            limits:
              nvidia.com/gpu: "1"

من خلال schedulingGates، لا يتعامل مُجدِّل Kubernetes مع حاويات هذه المهمة حتى تمنح Kueue القبول. بمجرد تأكيد Kueue توفر مساحة لـ 16 وحدة GPU في المجموعة وإزالة البوابة، يضع مُجدِّل KAI الحاويات الـ 16 جميعها في آنٍ واحد على العقد المثلى.

يُنفِّذ مُجدِّل KAI أيضًا التوزيع المدرك للطوبولوجيا (topology-aware placement) عند تخصيص وحدات GPU. يُفضِّل اختيار العقد داخل الرف ذاته المرتبط بـ InfiniBand لتقليل تكاليف الاتصال في التدريب الموزع. يؤثر ذلك مباشرةً ليس فقط في معدل استخدام GPU بل في سرعة التدريب أيضًا.

ResourceFlavor ومعالجة تغاير العقد

تتضمن بيئات الإنتاج الفعلية مزيجًا من أنواع GPU المختلفة – H100 وA100 ومثيلات MIG وغيرها. تجرِّد ResourceFlavor في Kueue هذا التغاير.

# مثال مفاهيمي -- ليس التقاطًا تنفيذيًا
apiVersion: kueue.x-k8s.io/v1beta1
kind: ResourceFlavor
metadata:
  name: h100-full
spec:
  nodeLabels:
    nvidia.com/gpu.product: "NVIDIA-H100-80GB-HBM3"
---
apiVersion: kueue.x-k8s.io/v1beta1
kind: ResourceFlavor
metadata:
  name: h100-mig-3g
spec:
  nodeLabels:
    nvidia.com/gpu.product: "NVIDIA-H100-80GB-HBM3"
    nvidia.com/mig.profile: "3g.40gb"

تُوجِّه ClusterQueue المهام تلقائيًا إلى ResourceFlavor المناسبة بحسب خصائص حِمل العمل. تُوجَّه مهام الضبط الدقيق الصغيرة إلى شرائح MIG، بينما تُوضَع مهام التدريب المسبق الكبيرة على وحدات GPU الكاملة. لا حاجة لكتابة قواعد Node Affinity يدويًا في كل مرة.

تكاليف الاستدلال: vLLM Scale-to-Zero

التوسع التلقائي المبني على HTTP بواسطة KEDA

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

تُشغِّل ThakiCloud نقاط نهاية الاستدلال بأسلوب بدون خادم (serverless) باستخدام مزيج vLLM + KEDA. يراقب محوِّل HTTP في KEDA الطلبات الواردة إلى نقطة النهاية ويُعدِّل عدد نسخ vLLM تلقائيًا بحسب حجم الطلبات.

# مثال مفاهيمي -- ليس التقاطًا تنفيذيًا
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: llm-inference-scaler
spec:
  scaleTargetRef:
    name: vllm-llama3-deployment
  minReplicaCount: 0      # يُسمح بالتوسيع إلى الصفر
  maxReplicaCount: 8
  cooldownPeriod: 300     # انتظار 5 دقائق بعد آخر طلب قبل التقليص إلى 0
  triggers:
    - type: prometheus
      metadata:
        serverAddress: http://victoria-metrics:8428
        metricName: http_requests_per_second
        threshold: "10"   # 10 طلبات في الثانية لكل نسخة
        query: sum(rate(vllm_request_success_total[1m]))

minReplicaCount: 0 هو مفتاح Scale-to-Zero. عند عدم وجود طلبات في الساعة الثانية صباحًا، تُقلَّص حاوية vLLM إلى الصفر وتُعيد وحدة GPU. عند وصول أول طلب مع بدء يوم العمل، تُشغِّل KEDA الحاوية، تُحمِّل vLLM النموذج في ذاكرة GPU، ثم تُعاد الاستجابة.

مقايضة زمن انتظار البدء البارد

العيب الواضح لـ Scale-to-Zero هو زمن انتظار البدء البارد (cold start latency). قد يستغرق تحميل نموذج بـ 7 مليارات معامل في vLLM عشرات الثواني. يُعالَج ذلك بإحدى الاستراتيجيات الثلاث التالية وفقًا لمتطلبات اتفاقية مستوى الخدمة (SLA).

أولًا، ضبط minReplicaCount: 1 للإبقاء دائمًا على نسخة واحدة على الأقل. يُقايض ذلك تكلفة احتجاز وحدة GPU واحدة دائمًا باستجابية خالية من البدء البارد.

ثانيًا، إعداد جدول إحماء مسبق (pre-warm) قائم على ساعات العمل. يرفع CronJob أو مُجدِّل خارجي عدد النسخ إلى 1 قبل ثلاثين دقيقة من بدء العمل، ثم يُنفِّذ Scale-to-Zero بعد انتهاء ساعات العمل.

ثالثًا، الاستفادة من الضغط الكمي (quantization) في vLLM لتقليص زمن التحميل ذاته. النماذج بتنسيق AWQ أو GPTQ أوقات تحميلها أقصر بكثير مقارنةً بـ FP16.

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

رؤية التكاليف: DCGM/VictoriaMetrics

هيكل جمع بيانات قياس GPU عن بُعد

لتحسين التكاليف، يجب معرفة ما يُستهلك وبأي قدر بدقة تامة. تستخدم ThakiCloud مصدِّر NVIDIA DCGM لجمع بيانات قياس GPU الدقيقة على مستوى الوحدة، وتخزينها طويل المدى في VictoriaMetrics.

المقاييس الرئيسية التي يكشفها مصدِّر DCGM هي التالية.

عندما يكون DCGM_FI_DEV_GPU_UTIL منخفضًا لكن DCGM_FI_DEV_FB_USED مرتفعًا، فإن GPU تحتجز الذاكرة دون تنفيذ حسابات. هذا هو الهدف المباشر لـ Scale-to-Zero.

إسناد تكاليف GPU لكل فريق

يُتيح دمج بيانات القياس المخزنة في VictoriaMetrics مع تسميات Kubernetes تتبع استهلاك GPU حسب الفريق والمشروع. بما أن LocalQueue في Kueue تُعيَّن بعلاقة 1:1 مع مساحات الأسماء، فإن تجميع استخدام GPU وفق تسميات مساحات الأسماء يكشف الاستهلاك الفعلي لكل فريق.

# مثال على استعلام VictoriaMetrics (MetricsQL)
# متوسط معدل استخدام GPU حسب مساحة الأسماء (آخر 24 ساعة)
avg by (namespace) (
  avg_over_time(DCGM_FI_DEV_GPU_UTIL{kubernetes_namespace!=""}[24h])
)

يُمكِّن تصوير هذه البيانات في لوحة معلومات المسؤولين من رؤية أي الفرق تستخدم وحدات GPU المخصصة لها بكفاءة، وأي المهام تحتجز وحدات GPU لفترات طويلة مع معدلات استخدام منخفضة.

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

يفصل مستوى البيانات في منصة ThakiCloud AI منطقيًا بين مجموعات الاستدلال ومجموعات التدريب ومجموعات التطوير، مع نشر مجموعة التقنيات Kueue + KAI + KEDA ذاتها على كل مجموعة. توفر طبقة إدارة المجموعات المتعددة (MCC) رؤية متكاملة لحالة قوائم الانتظار عبر جميع المجموعات من مستوى تحكم واحد.

من خلال ArgoCD GitOps، تُدار سياسات الجدولة مثل ClusterQueue وResourceFlavor وScaledObject بشكل إعلاني من مستودع Git. عند تأهيل فريق جديد أو تعديل nominalQuota، تُقترَح التغييرات عبر طلب سحب (PR) وتُراجَع قبل تطبيقها على المجموعة – بدلًا من استخدام kubectl apply مباشرةً. يضمن ذلك مسار تدقيق لتغييرات السياسة ويمنع التخصيص الزائد للموارد بسبب الأخطاء مسبقًا.

يمكن أيضًا أتمتة مُشغِّلات توسيع المجموعة بناءً على المقاييس. عند تجاوز أوقات انتظار قوائم Kueue في VictoriaMetrics 30 دقيقة باستمرار، يُولَّد تنبيه ويُستخدَم كإشارة لإضافة عقد GPU جديدة. عند الحفاظ على متوسط استخدام GPU للمجموعة عند 80% لأكثر من 30 يومًا، يُبادَر إلى مراجعة التوسع بوحدة 72 GPU التالية.

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

نضج Kueue وتبعيات النظام البيئي

Kueue مشروع CNCF لكنه لا يزال حديثًا نسبيًا. أنواع أعباء العمل الرئيسية بما في ذلك Kubeflow وRay والمهام (Jobs) القياسية مدعومة، لكن بعض الأطر المبنية على CRD المخصص قد تحتاج إلى عمل تكامل إضافي. قبل الاعتماد، من المهم التحقق من توافق أطر عمل ML المستخدمة مع Kueue.

Gang Scheduling وتفتت المجموعة

يحل Gang Scheduling مشكلة التفتت لكنه يخلق في الوقت ذاته مقايضات جديدة. عند توزع 8 وحدات GPU على عقدتين بواقع 4 لكل منهما في المجموعة، قد تنتظر مهمة طالبة الـ 8 وحدات جميعها في آنٍ واحد انتظارًا طويلًا بسبب Gang Scheduling. في مثل هذه الحالات، يلزم الجمع بين سياسات bin-packing وGang Scheduling وضبطها وفق الوضع.

التعقيد التشغيلي لـ Scale-to-Zero

بتزايد عدد نقاط نهاية الاستدلال، يزداد عدد KEDA ScaledObjects. يُصبح ضبط cooldownPeriod وthreshold وminReplicaCount المناسبين لكل نقطة نهاية والحفاظ عليها عبئًا تشغيليًا. للحد من ذلك، الأسلوب العملي هو تصنيف نقاط النهاية حسب درجة SLA وإدارة نماذج قياسية لكل درجة.

الشرط المسبق لخفض تكاليف GPU: مقاييس دقيقة

قيمة GPU_UTIL التي يجمعها مصدِّر DCGM تمثل نسبة نشاط SM (Streaming Multiprocessor). قيمة منخفضة لا تعني بالضرورة حالة خمول. معدل استخدام SM المنخفض بسبب نسخ الذاكرة أو انتظار الاتصالات هو مشكلة تحسين حِمل العمل لا مشكلة جدولة. للحصول على تشخيص دقيق عند تفسير بيانات القياس، يلزم التحليل المركَّب لمعدل استخدام SM ونطاق الذاكرة ومعدل نشاط أنوية الموتر – لا مقياس واحد.

مجموعة GPU هي في حد ذاتها مورد هائل، لكن دون سياسة جدولة لا يتحقق إمكانها الكامل. المزيج الثلاثي من Kueue Fair-Share لحل تنافس قوائم الانتظار، وGang Scheduling للقضاء على وقت انتظار التدريب الموزع، وScale-to-Zero لمنع تكاليف الاستدلال الخامل هو نقطة الانطلاق العملية لتحسين تكاليف GPU الأصيل في Kubernetes.