الذكاء الاصطناعي السيادي: ثلاثة قرارات تسبق النموذج

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

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

باختصار

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

من التجربة إلى العملية الحرجة

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

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

السيادة تُقرَّر لكلّ تدفّق

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

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

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

القدرة تحدّد النموذج

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

لم يعد السؤال «ما أفضل نموذج؟»، بل «ما أصغر نموذج يحقّق المتطلّب الوظيفي ضمن ميزانية الموارد المتاحة؟». ولا تجيب التصنيفات العامة عن هذا السؤال، لأنها تقيس مهامّ عامة. وحده اختبار على المهمّة الفعلية، وبالبيانات الفعلية، يتيح الحسم. وليس هذا مرحلة اختبار قبول، بل أداة القرار التي توازن بين الدقّة وزمن الاستجابة وتكلفة البنية التحتية.

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

قابلية التراجع تحمي الاستثمار

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

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

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

مثال تطبيقي: عملية نشر حقيقية

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

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

القدرة. بتكميم 4 إلى 5 بتات، يشغل Qwen3.6-27B مساحة 18,2 غيغابايت بنافذة سياق من 2048 رمزًا: فهو لا يتّسع لبطاقة واحدة، وتوزيعه على البطاقتين يحرم الخدمات الأخرى من ذاكرتها. وأكّد الاختبار جدوى عدم السعي إلى نموذج أكبر. ففي مهمّة استخراج البيانات نفسها بصيغة JSON، يقدّم Qwen3-14B نتيجة دقيقة في 33 ثانية، ويقدّم Qwen3.6-27B النتيجة نفسها في 156 ثانية، بينما لا يُنجز Gemma 4 12B هذه المهمّة.

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

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

ما يجب أن يحسمه صنّاع القرار

قبل إطلاق مشروع ذكاء اصطناعي على بيانات حسّاسة، تستحقّ ثلاثة أسئلة جوابًا صريحًا على مستوى الإدارة العليا:

• ما التدفّقات التي لا يُسمح لها بمغادرة بنيتنا التحتية، ومن قرّر ذلك؟
• ما المتطلّب الوظيفي الذي نستهدفه، وهل قسناه على مهمّتنا قبل تحديد حجم العتاد؟
• ما تكلفة تغيير النموذج في الربع المقبل: إعداد أم مشروع؟

نهجنا

في KAIROS Impulse، نتّخذ هذه القرارات الثلاثة بهذا الترتيب، على البيانات الفعلية للعميل. يأتي النموذج في الأخير، وتتيح البنية للعميل تغييره دون الاعتماد علينا. مبدؤنا: نقل القدرة، لا خلق التبعية.

النموذج الصحيح هو الذي تستطيع بنيتك التحتية تشغيله دون حوادث لسنوات.