أطلقت Aperture Venture Studio بنية معمارية مكونة من ثلاث مراحل لبناء منصات إنترنت الأشياء المدعومة بالذكاء الاصطناعي (AIoT) التي يمكنها خدمة عدة شركات مستقلة في آن واحد.
لماذا تكمن أهمية منصة AIoT مشتركة
تقوم معظم المجموعات الهندسية بتصميم منصة حول منتج واحد، ثم تعيد استخدام أجزاء منها في الإصدارات اللاحقة. ومع ذلك، يجب على استوديو المشاريع (venture studio) التعامل مع شركات ناشئة متعددة تستهدف عملاء مختلفين، وتعمل على أجهزة مختلفة، وتتحرك وفق جداول زمنية متميزة. وبدون نهج منسق، تعيد كل شركة ناشئة بناء نفس مسارات البيانات (data pipelines)، ومجموعات تدريب النماذج (model-training stacks)، وخدمات إدارة الأجهزة من الصفر. وهذا التكرار يهدر الوقت.
النموذج المكون من ثلاث مراحل
يقسم نهج Aperture دورة الحياة إلى ثلاث مراحل واضحة:
- حل عامل لعميل واحد – تقدم الفرق خدمة AIoT وظيفية تلبي حاجة واقعية، مما يؤسس لحالة استخدام ملموسة ومجموعة من المتطلبات.
- وحدة قابلة للتكرار في منصة مشتركة – تتم إعادة هيكلة الحل (refactored) ليصبح مكوناً قابلاً لإعادة الاستخدام يوضع جنباً إلى جنب مع الوحدات الأخرى في منصة مشتركة. وتعد هذه الخطوة هي الأصعب لأن الكود يجب أن يكون مجرداً بما يكفي لدعم مجالات متباينة مثل تتبع الأصول، أو سلامة القوى العاملة، أو المراقبة البيئية.
- مرشح للانفصال (spin-out) – عندما تصبح الشركة الناشئة جاهزة لتصبح شركة مستقلة بذاتها، فإنها تستبدل البنية التحتية المشتركة بنسخة خاصة تطبق نفس الواجهات (interfaces)، مما يسمح للكود بالعمل دون تغيير.
تتحمل المرحلة الوسطى العبء الأكبر. حيث تقوم الفرق بإنشاء طبقة أساسية من نماذج الذكاء الاصطناعي التي يمكن ضبطها بدقة (fine-tuned) بدلاً من تدريبها من الصفر لكل مشروع جديد. إن التعامل مع النماذج الأساسية كأصول مشتركة يعني أن أي تحسين في النموذج الأساسي سيفيد فوراً جميع المشاريع التي تعتمد عليه.
مسارات بيانات مشتركة دون عزل كامل
من المغريات الشائعة عزل مسار بيانات كل مستأجر (tenant) تماماً، بافتراض أن ذلك يحافظ على فصل الشركات الناشئة بشكل نظيف. وتحذر Aperture من أن العزل الكامل يعيق تدفق التحسينات: فإصلاح خطأ برمجى أو روتين جديد لتنظيف البيانات يتم تطبيقه على مسار واحد لن يصل أبداً إلى المسارات الأخرى. ويحل نهجهم الهجين هذه المشكلة:
- بيانات مستأجر منفصلة – تظل البيانات الخام لكل شركة ناشئة في حاوية تخزين (storage bucket) خاصة بها، مما يحافظ على الخصوصية والامتثال.
- منطق معالجة مشترك – يعيش الكود المشترك الذي يقوم بتنظيف البيانات وإزالة الضجيج منها وهيكلتها في مكتبة واحدة. وتحديث تلك المكتبة يفيد كل شركة ناشئة تلقائياً.
- قواعد خاصة بكل شركة – يتم التعامل مع الحالات الاستثنائية (edge cases) من خلال مجموعات قواعد صغيرة بنمط الملحقات (plug-in-style) توضع فوق المنطق المشترك، مما يحافظ على استقرار النواة مع السماح بالتخصيص.
يوفر هذا التصميم سيادة على البيانات مع الاستفادة من منطق المعالجة المشترك.
فك الارتباط من أجل انفصال سلس
يتسلل الارتباط الوثيق (tight coupling) عندما تعتمد الفرق على واجهات برمجة تطبيقات (APIs) داخلية توجد فقط ضمن النظام البيئي للاستوديو. وتكافح Aperture ذلك من خلال فرض واجهات صارمة لجميع التبعيات. حيث تعلن كل وحدة عن العقود (contracts) التي تحتاجها — سواء للتواصل مع الأجهزة، أو استنتاج النماذج (model inference)، أو الفوترة — ولا شيء أكثر من ذلك.
عندما تصل الشركة الناشئة إلى مرحلة الانفصال، فإنها ببساطة توجه تلك الواجهات نحو تطبيقاتها الخاصة. ولأن الكود لم يستدعِ أبداً خدمة داخلية ملموسة بشكل مباشر، يصبح الاستبدال مجرد مسألة إعدادات (configuration) بدلاً من إعادة كتابة كاملة. إن التخطيط لفك الارتباط هذا مبكراً يجنبنا إعادة هيكلة مكلفة لاحقاً.
المخاطر والنقاط المضادة
نموذج البنية التحتية المشتركة ليس حلاً سحرياً.
ما يجب مراقبته لاحقاً
الخلاصة: إن بناء منصة AIoT مشتركة بواجهات واضحة، وقاعدة نماذج مشتركة، واستراتيجية هجينة لمسارات البيانات، يتيح لاستوديوهات المشاريع إطلاق شركات ناشئة متعددة بشكل أسرع وفصلها بسلاسة.