Aperture Venture Studio یک معماری سهمرحلهای را برای ساخت پلتفرمهای AIoT (اینترنت اشیاء مبتنی بر هوش مصنوعی) معرفی کرده است که میتواند به چندین شرکت مستقل بهطور همزمان خدماترسانی کند.
چرا یک پلتفرم AIoT مشترک اهمیت دارد
اکثر گروههای مهندسی، یک پلتفرم را حول محور یک محصول واحد طراحی میکنند و سپس بخشهایی از آن را برای نسخههای بعدی بازاستفاده میکنند. با این حال، یک venture studio باید چندین استارتاپ را مدیریت کند که مشتریان متفاوت، سختافزارهای مختلف و جداول زمانی متمایزی دارند. بدون یک رویکرد هماهنگ، هر پروژه (venture) همان خط لوله دادهها (data pipelines)، پشتههای آموزش مدل (model-training stacks) و سرویسهای مدیریت دستگاه را از ابتدا بازسازی میکند. این دوبارهکاری باعث اتلاف وقت میشود.
مدل سهمرحلهای
رویکرد Aperture چرخه حیات را به سه مرحله مشخص تقسیم میکند:
- راهکار عملیاتی برای یک مشتری واحد – تیمها یک سرویس AIoT کاربردی ارائه میدهند که نیازهای دنیای واقعی را برآورده میکند و یک مورد استفاده (use case) ملموس و مجموعهای از الزامات را تعیین میکند.
- ماژول تکرارپذیر در یک پلتفرم مشترک – راهکار مذکور به یک مؤلفه قابل استفاده مجدد تبدیل (refactor) میشود که در کنار سایر ماژولها در یک پلتفرم مشترک قرار میگیرد. این مرحله دشوارترین بخش است، زیرا کد باید به اندازه کافی انتزاعی (abstract) باشد تا بتواند از حوزههای مختلفی مانند ردیابی داراییها، ایمنی نیروی کار یا پایش محیطی پشتیبانی کند.
- کاندیدای جدا شدن (spin-out) – زمانی که یک پروژه آماده تبدیل شدن به یک شرکت مستقل است، زیرساخت مشترک را با یک نمونه خصوصی که همان رابطها (interfaces) را پیادهسازی میکند جایگزین میکند؛ این کار اجازه میدهد کد بدون تغییر اجرا شود.
مرحله میانی بیشترین بار کاری را به دوش میکشد. تیمها یک لایه پایه از مدلهای هوش مصنوعی ایجاد میکنند که میتوان آنها را برای هر پروژه جدید، به جای آموزش از صفر، بازتنظیم (fine-tune) کرد. در نظر گرفتن مدلهای اصلی به عنوان داراییهای مشترک به این معناست که هر بهبود در مدل پایه، بلافاصله به نفع تمام پروژههایی خواهد بود که به آن متکی هستند.
خط لولههای داده مشترک بدون جداسازی کامل
یک وسوسه رایج این است که خط لوله داده هر مستأجر (tenant) را کاملاً ایزوله کنند، با این فرض که این کار باعث جداسازی تمیز پروژهها میشود. Aperture هشدار میدهد که جداسازی کامل مانع جریان بهبودها میشود: یک اصلاح باگ یا یک روتین جدید پاکسازی داده که روی یک خط لوله اعمال شود، هرگز به بقیه نمیرسد. رویکرد ترکیبی آنها این مشکل را حل میکند:
- دادههای مجزای مستأجر – دادههای خام هر پروژه در مخزن ذخیرهسازی مخصوص خود باقی میماند که حریم خصوصی و انطباق (compliance) را حفظ میکند.
- منطق پردازش مشترک – کدهای مشترک که دادهها را پاکسازی، نویززدایی و ساختارمند میکنند، در یک کتابخانه (library) واحد قرار دارند. بهروزرسانی آن کتابخانه بهطور خودکار به نفع هر پروژه خواهد بود.
- قوانین مختص هر پروژه – موارد خاص (edge cases) توسط مجموعه قوانین کوچک و افزونهمانند (plug-in-style) که روی منطق مشترک قرار میگیرند، مدیریت میشوند؛ این کار پایداری هسته اصلی را حفظ کرده و در عین حال امکان سفارشیسازی را فراهم میکند.
این طراحی ضمن بهرهگیری از منطق پردازش مشترک، حاکمیت داده (data sovereignty) را نیز فراهم میکند.
جداسازی (Decoupling) برای یک جدا شدن بدون درد
وابستگی شدید (Tight coupling) زمانی رخ میدهد که تیمها به APIهای داخلی که فقط در اکوسیستم استودیو وجود دارند، متکی باشند. Aperture با اعمال رابطهای (interfaces) سختگیرانه برای تمام وابستگیها با این مشکل مقابله میکند. هر ماژول قراردادهای مورد نیاز خود را اعلام میکند — خواه برای ارتباط با دستگاه، استنتاج مدل (model inference) یا صورتحساب — و نه چیزی بیشتر.
وقتی یک پروژه به مرحله جدا شدن (spin-out) میرسد، صرفاً آن رابطها را به پیادهسازیهای خودشان متصل میکند. از آنجایی که کد هرگز مستقیماً یک سرویس داخلی مشخص را فراخوانی نکرده است، جایگزینی تنها یک مسئله پیکربندی (configuration) است و نه بازنویسی کامل. برنامهریزی برای این جداسازی در مراحل اولیه، از بازطراحی پرهزینه در آینده جلوگیری میکند.
ریسکها و نکات متقابل
مدل زیرساخت مشترک یک راهکار جادویی (silver bullet) نیست.
آنچه باید در ادامه دنبال کرد
نتیجهگیری: ساخت یک پلتفرم AIoT مشترک با رابطهای شفاف، یک پایه مدل مشترک و استراتژی ترکیبی خط لوله داده، به venture studioها اجازه میدهد استارتاپهای متعددی را سریعتر راهاندازی کرده و آنها را بهطور تمیز از مجموعه جدا کنند.