(منذ وقت ليس ببعيد) عندما يكون عالم البيانات يعني العيش في دفتر ملاحظات وتعديل المعلمات الفائقة كما لو كانت حياتك تعتمد عليها، وفي كثير من الحالات يعتمد المشروع بأكمله عليها بالفعل.
هل تتذكر عمليات البحث الليلية تلك على الويب؟ أم أنك تبني خطوط أنابيب هندسية تشبه الفن أكثر من كونها علمية؟ وما مدى رضاك عن الضغط على دقة إضافية بنسبة 0.7٪ من طراز XGBoost؟
في عام 2019، كانت تلك وظيفة عالم البيانات! وهو أمر منطقي. إذا أردت نموذجًا قويًا، كان عليك أن تبنيه بنفسك أو أن تعمل بجد لتصحيحه. جاءت القيمة الحقيقية من مدى قدرتك على ضبط البيانات وتحسينها وفهمها.
الآن، أصبح “أحدث ما توصلت إليه التكنولوجيا” على بعد مكالمة واحدة فقط من واجهة برمجة التطبيقات (API). هل تحتاج إلى نموذج لغة أعلى؟ منتهي. هل تحتاج إلى التضمين أو التفكير متعدد الوسائط؟ تم أيضًا. يتم الآن التعامل مع أصعب أجزاء النمذجة من خلال نقاط نهاية قابلة للتطوير، وهو ما يتجاوز بكثير ما يمكن أن تبنيه معظم الفرق بنفسها.
السؤال هو، إذا كان النموذج موجودًا بالفعل، أين ذهب العمل؟
لم تعد القيمة تكمن في النموذج فقط. يتعلق الأمر بكيفية اتصال جميع الأجزاء وتواصلها وتكيفها. يغير هذا التغيير دور عالم البيانات تمامًا.
كيفتسأل؟ هذا ما تدور حوله هذه المقالة.
ما الذي تغير؟
1. تجاوز طريقة .fit().
إذا نظرت إلى كود مشروع الذكاء الاصطناعي الحديث، ستلاحظ بسرعة أنه لا يوجد الكثير من النمذجة الجارية.
قد ترى دعوة للحصول على شهادة LLM أو نموذج التضمين، ولكن نادرًا ما يكون هذا هو التحدي الرئيسي. العمل الحقيقي هو استيعاب البيانات، والتوجيه، وتجميع السياق، والتخزين المؤقت، والمراقبة، والتعامل مع إعادة المحاولة.
وبعبارة أخرى، باستخدام .fit() يعد الآن أحد الأجزاء الأقل إثارة للاهتمام في الكود.
2. التكيف مع المكونات الجديدة
واليوم، بدلاً من التركيز على العناصر الداخلية للنماذج، نقوم بتجميع الأنظمة من مكونات جاهزة. تحتوي حزمة النمذجة النموذجية الآن على:
- قواعد بيانات المتجهات (مثل Pinecone وMilvus)
- هندسة سريعة.
- طبقات الذاكرة.
بالإضافة إلى وظائف/مكالمات الوكيل. عندما ننظر إلى الكل، نرى أن هذه ليست نمذجة تقليدية. إنه تصميم النظام. من المهم التأكيد هنا على أن أياً من هذه المكونات ليس مفيداً بشكل خاص في حد ذاته. قوتهم تأتي من الطريقة التي يتم بها ترتيبهم معًا.
3. تجميع كل شيء معًا
اليوم، تركز معظم أكواد علم البيانات على ربط الأشياء. لا يتعلق الأمر بالجبر الخطي أو التحسين أو حتى الإحصائيات.
يتعلق الأمر بكتابة التعليمات البرمجية التي تنقل البيانات بين المكونات، وتنسيق الإدخال، وتحليل الإخراج، وتسجيل التفاعلات، وإدارة الحالة في الأنظمة الموزعة.
إذا قمت بقياس التعليمات البرمجية الخاصة بك، فسوف ترى أنه يتم إنفاق 10 إلى 20 بالمائة فقط على استهلاك النموذج (استدعاءات واجهة برمجة التطبيقات والاستدلال)، بينما يتم إنفاق 80 إلى 90 بالمائة على التنسيق – التعامل مع تدفق البيانات والتكامل والبنية التحتية.
الانتقال من محلل البيانات إلى مهندس الذكاء الاصطناعي
أكبر تغيير في التفكير اليوم هو أنك لم تعد تقوم فقط بتحسين الميزات. أنت الآن تقوم بتصميم النظام بأكمله، مع التفكير في زمن الوصول والتكلفة والموثوقية وكيفية التفاعل معه.
بدلاً من السؤال: “كيفية تحسين أداء النموذج؟“- نسأل الآن، “كيف يعمل هذا النظام برمته في مواقف الحياة الحقيقية؟“
أعرف ما الذي تفكر فيه – وهذا تحدٍ مختلف تمامًا! عندما حدث هذا التغيير لأول مرة، كان الأمر غير مريح للعديد من الأشخاص، بما فيهم أنا.
لمواكبة المكدس الحالي، نحتاج إلى أكثر من مجرد الإحصائيات والتعلم الآلي. نحن بحاجة إلى أن نصبح مرتاحين مع واجهات برمجة التطبيقات (مثل FastAPI أو Flask) للخدمة والتوجيه، والحاويات (مثل Docker) للتنفيذ، والبرمجة غير المتزامنة (باستخدام Asyncio) للتعامل مع الطلبات المتعددة، والبنية التحتية السحابية للتوسع والمراقبة، وأساسيات هندسة البيانات لخطوط الأنابيب والتخزين.
إذا كنت تعتقد أن هذا يبدو مشابهًا جدًا هندسة الواجهة الخلفيةأنت على حق.
لقد أدى هذا التغيير إلى عدم وضوح الخط الفاصل بين عالم البيانات والمهندس. الأشخاص الذين يمكنهم العمل بشكل مريح في كلا المجالين يقومون بعمل جيد.
القديم مقابل الجديد
السؤال الرئيسي الآن هو: كيف يبدو هذا التغيير في الكود؟
مشروع الإرث (2019): تحليل المشاعر
لقد عمل الكثير منا على هذا النوع من المشاريع. العملية بسيطة:
- جمع مجموعة البيانات المسمى.
- أداء هندسة الميزات (TF-IDF، n-grams).
- مصنف القطار (الانحدار اللوجستي، XGBoost).
- تخصيص المعلمات الفائقة.
- نشر النموذج.
يعتمد النجاح على جودة مجموعة البيانات والنموذج.
التصميم الحديث (2026): وكيل مستقل لتعليقات العملاء
الآن العملية مختلفة. لبناء نظام اليوم تحتاج إلى:
- تلقي رسائل العملاء في الوقت الحقيقي.
- تخزين العناصر المضمنة في قاعدة بيانات المتجهات.
- احصل على السياق التاريخي الصحيح.
- بناء الاقتراحات بشكل ديناميكي.
- المسار إلى LLM مع إمكانية الوصول إلى الأدوات (مثل تحديثات إدارة علاقات العملاء وأنظمة إصدار التذاكر)
- زراعة الذاكرة المحادثة الخاصة بك.
- مراقبة النتائج للتأكد من الجودة والسلامة.
هل يمكنك اكتشاف ما هو مفقود؟ هنا تلميح: لا توجد حلقة تدريب.
هذا المثال بسيط عن عمد، ولكن لاحظ ما سنركز عليه بعد ذلك. التعافي جزء من النظام؛ النموذج عبارة عن قطعة واحدة فقط، والقيمة تأتي من كيفية ربط كل شيء وعمله معًا.
كيف تبدأ بالتفكير مثل مهندس الذكاء الاصطناعي
والآن بعد أن عرفنا ما الذي تغير، فلنتحدث عما يجب عليك فعله بشكل مختلف. كيف يمكنك المضي قدمًا في هذا التغيير بدلاً من التخلف؟
إجابة قصيرة: البدء في بناء الأنظمة، وليس النماذج فقط.
إجابة أطول: التركيز على تطوير هذه المهارات:
1. قم ببناء المكونات بشكل شامل، وليس فقط المكونات
بدلًا من التفكير:”لقد قمت بتدريب نموذج“، تهدف إلى”، “لقد قمت ببناء نظام يأخذ المدخلات ويعالجها ويعيد قيمة.والآن يتعلق الأمر بالصورة الأكبر، وليس بمهمة واحدة فقط.
2. تعلم ما يكفي من الخلفية لتكون خطيرة
ليس من الضروري أن تصبح مهندسًا خلفيًا بدوام كامل، ولكن يجب أن تعرف ما يكفي لبناء نظامك. قم بالتركيز على:
- تفكيك واجهة برمجة التطبيقات (API) البسيطة (FastAPI يكفي)
- معالجة الطلب غير المتزامن
- تسجيل الأخطاء والتعامل معها
- التنفيذ الأساسي (Docker + منصة سحابية واحدة)
3. كن مرتاحًا مع الغموض
أنظمة الذكاء الاصطناعي الحديثة ليست حتمية مثل النماذج التقليدية. وهذا يجعل التعامل معها أكثر صعوبة لأنك الآن لا تقوم فقط بتصحيح التعليمات البرمجية؛ بل أنت تقوم بتصحيح السلوك.
وهذا يعني تكرار المطالبات، وتصميم آليات احتياطية، وتقييم النتائج من الناحية النوعية، وليس من الناحية الكمية فقط.
4. قياس ما يهم حقا
لم تعد الدقة هي المقياس الأساسي دائمًا. والأهم الآن هو زمن الوصول، وتكلفة الطلب، ورضا المستخدم، ومعدل إنجاز المهمة.
إن النظام الذي يكون دقيقًا وموثوقًا بنسبة 95٪ ولكنه غير مناسب للاستخدام الإنتاجي يكون أدنى من النظام الذي يكون دقيقًا وموثوقًا بنسبة 85٪.
فكرة أخيرة
في صناعتنا، هناك دائمًا إغراء لمطاردة ما يبدو أنه الأكثر “تقنية”، وأحدث طراز، وأكبر معيار، وأكثر هندسة معمارية بهرجة.
لكن الجزء الأكثر قيمة في هذه الوظيفة كان دائمًا وسيظل دائمًا هو الجانب الإنساني! أي فهم المشكلة. إن معرفة ما نحاول حله أكثر أهمية من البيانات والنموذج الذي نستخدمه.
طرح أسئلة مثل: “ما هي الحاجة هنا؟ ما الذي يهم المستخدم؟ ماذا تعني كلمة “جيد” في الواقع في السياق؟“يحدث فرقًا كبيرًا في ما تبنيه.
لا يمكنك الاستعانة بمصادر خارجية لهذا الجزء أو إخفاء هذا الجزء خلف واجهة برمجة التطبيقات. وبالتأكيد لا يمكن أن تكون آلية.
لذلك لا تركز فقط على بناء محرك السيارة. حاول أن تكون الشخص الذي يفهم إلى أين يجب أن تذهب السيارة ثم يبني نظامًا للوصول إلى هناك.
