چگونه CI/CD برای علم داده متفاوت است

انتقال علم داده به سمت تولید شباهت های زیادی با بکارگیری یک برنامه کاربردی دارد. اما تفاوت های کلیدی وجود دارد که نباید آنها را نادیده گرفت.

برنامه نویسی چابک پرکاربردترین متدولوژی است که تیم های توسعه را قادر می سازد تا نرم افزار خود را در مرحله تولید عرضه کنند، اغلب برای جمع آوری بازخورد و اصلاح نیازمندی های اساسی. با این حال، برای چابکی برای کار در عمل، به فرآیندهایی نیاز است که به برنامه تجدیدنظر شده اجازه می‌دهد تا به طور خودکار ساخته شده و به تولید عرضه شود – که عموماً به عنوان ادغام پیوسته/استقرار مداوم یا CI/CD شناخته می‌شود. CI/CD تیم‌های نرم‌افزاری را قادر می‌سازد تا با درگیر کردن منظم کاربران واقعی و ترکیب مکرر بازخورد آن‌ها، برنامه‌های پیچیده را بدون خطر از دست دادن الزامات اولیه بسازند.

علم داده با چالش های مشابهی روبروست. اگرچه خطر نادیده گرفتن الزامات اولیه توسط تیم های علم داده در حال حاضر کمتر تهدیدی است (این در دهه آینده تغییر خواهد کرد)، چالش ذاتی در استقرار خودکار علم داده در تولید، بسیاری از پروژه های علم داده را متوقف می کند. اول، IT اغلب نیاز به درگیر شدن برای قرار دادن هر چیزی در سیستم تولید دارد. دوم، اعتبارسنجی معمولاً یک کار دستی و نامشخص است (اگر حتی وجود داشته باشد). و سوم، به‌روزرسانی یک فرآیند علم داده تولید به طور قابل اعتماد اغلب آنقدر دشوار است که به عنوان یک پروژه کاملاً جدید تلقی می‌شود.

علم داده چه چیزی می تواند از توسعه نرم افزار بیاموزد؟ بیایید ابتدا به جنبه‌های اصلی CI/CD در توسعه نرم‌افزار نگاهی بیندازیم، قبل از اینکه عمیق‌تر به این موضوع بپردازیم که در کجا همه چیز مشابه است و دانشمندان داده‌ها باید در کجا حرکت متفاوتی داشته باشند.

CI/CD در توسعه نرم افزار

فرایندهای تولید تکرارشونده برای توسعه نرم افزار مدتی است که وجود داشته است و یکپارچه سازی مداوم/استقرار مستمر استاندارد امروزی است. توسعه نرم افزار در مقیاس بزرگ معمولاً از یک رویکرد بسیار ماژولار پیروی می کند. تیم‌ها روی بخش‌هایی از پایه کد کار می‌کنند و آن ماژول‌ها را به‌طور مستقل آزمایش می‌کنند (معمولاً از موارد آزمایشی بسیار خودکار برای آن ماژول‌ها استفاده می‌کنند).

در طول مرحله ادغام پیوسته CI/CD، قسمت‌های مختلف پایه کد به هم متصل می‌شوند و مجدداً به طور خودکار به طور کامل آزمایش می‌شوند. این کار یکپارچه سازی به طور ایده آل اغلب انجام می شود (از این رو “پیوسته”) به طوری که عوارض جانبی که بر یک ماژول فردی تأثیر نمی گذارد اما برنامه کلی را خراب می کند، می تواند فوراً پیدا شود. در یک سناریوی ایده‌آل، زمانی که پوشش کامل تست را داشته باشیم، می‌توانیم مطمئن باشیم که مشکلات ناشی از تغییر در هر یک از ماژول‌های ما تقریباً فوراً شناسایی می‌شوند. در واقع، هیچ تنظیم آزمایشی کامل نشده است و تست های یکپارچه سازی کامل ممکن است فقط یک بار در هر شب اجرا شوند. اما می‌توانیم سعی کنیم نزدیک شویم.

بخش دوم CI/CD، استقرار مداوم، به انتقال برنامه جدید ساخته شده به تولید اشاره دارد. به روز رسانی ده ها هزار برنامه دسکتاپ در هر دقیقه به سختی امکان پذیر است (و فرآیندهای استقرار پیچیده تر هستند). اما برای برنامه‌های مبتنی بر سرور، با ابزارهای مبتنی بر ابری که به طور فزاینده‌ای در دسترس هستند، می‌توانیم تغییرات و به‌روزرسانی‌ها را با دفعات بیشتری انجام دهیم. ما همچنین می‌توانیم به‌سرعت بازگردیم، اگر در نهایت چیزی باگ را تولید کنیم. سپس برنامه مستقر شده باید به طور مداوم برای خرابی های احتمالی نظارت شود، اما اگر آزمایش به خوبی انجام شود، مشکل کمتری وجود دارد.

CI/CD در علم داده

فرآیندهای علم داده معمولاً توسط تیم‌های مختلف به‌طور مستقل ساخته نمی‌شوند، بلکه توسط متخصصان مختلفی که به طور مشترک کار می‌کنند ساخته می‌شوند: مهندسان داده، کارشناسان یادگیری ماشین، و متخصصان تجسم. توجه به این نکته بسیار مهم است که ایجاد علم داده با توسعه الگوریتم ML – که مهندسی نرم افزار است – نیست، بلکه با استفاده از یک الگوریتم ML برای داده ها مرتبط است. این تفاوت بین توسعه الگوریتم و استفاده از الگوریتم اغلب باعث سردرگمی می شود.

“ادغام” در علم داده همچنین به کنار هم کشیدن قطعات زیرین اشاره دارد. در علم داده، این ادغام به معنای حصول اطمینان از این است که کتابخانه‌های مناسب یک جعبه ابزار خاص با فرآیند علوم داده نهایی ما همراه هستند، و اگر ابزار ایجاد علم داده ما اجازه انتزاع را بدهد، اطمینان حاصل کنیم که نسخه‌های صحیح آن ماژول‌ها نیز همراه هستند.

با این حال، یک تفاوت بزرگ بین توسعه نرم افزار و علم داده در مرحله یکپارچه سازی وجود دارد. در توسعه نرم‌افزار، چیزی که می‌سازیم، برنامه‌ای است که در حال استقرار است. شاید در حین ادغام برخی از کدهای اشکال زدایی حذف شوند، اما محصول نهایی همان چیزی است که در طول توسعه ساخته شده است. در علم داده اینطور نیست.

در طول مرحله ایجاد علم داده، فرآیند پیچیده ای ساخته شده است که نحوه و اینکه کدام داده ها ترکیب و تبدیل می شوند را بهینه می کند. این فرآیند ایجاد علم داده اغلب بر روی انواع و پارامترهای مختلف مدل‌ها تکرار می‌شود و به طور بالقوه حتی برخی از آن مدل‌ها را به‌طور متفاوت در هر اجرا ترکیب می‌کند. آنچه در طول یکپارچه سازی اتفاق می افتد این است که نتایج این مراحل بهینه سازی در فرآیند تولید علم داده ترکیب می شود. به عبارت دیگر، در طول توسعه، ما ویژگی ها را تولید می کنیم و مدل را آموزش می دهیم. در طول ادغام، فرآیند تولید ویژگی بهینه شده و مدل آموزش دیده را ترکیب می کنیم. و این ادغام شامل فرآیند تولید می شود.

پس “استقرار مستمر” برای علم داده چیست؟ همانطور که قبلاً اشاره شد، فرآیند تولید – یعنی نتیجه یکپارچگی که باید به کار گرفته شود – با فرآیند ایجاد علم داده متفاوت است. سپس استقرار واقعی شبیه به استقرار نرم افزار است. ما می‌خواهیم به‌طور خودکار یک برنامه یا سرویس API موجود را جایگزین کنیم، در حالت ایده‌آل با تمام ویژگی‌های معمولی مانند نسخه‌سازی مناسب و توانایی بازگشت به نسخه قبلی در صورت بروز مشکلات در طول تولید.

یک نیاز اضافی جالب برای فرآیندهای تولید علم داده، نیاز به نظارت مداوم بر عملکرد مدل است – زیرا واقعیت تمایل به تغییر دارد! تشخیص تغییر برای فرآیندهای علم داده بسیار مهم است. ما باید مکانیسم‌هایی را ایجاد کنیم که تشخیص دهند عملکرد فرآیند تولید ما چه زمانی بدتر می‌شود. سپس به طور خودکار مدل‌ها را مجدداً آموزش می‌دهیم و مجدداً مستقر می‌کنیم یا به تیم علم داده خود در مورد این مشکل هشدار می‌دهیم تا بتوانند یک فرآیند علم داده جدید ایجاد کنند و فرآیند CI/CD علم داده را دوباره آغاز کنیم.

بنابراین، در حالی که نظارت بر برنامه‌های نرم‌افزاری منجر به تغییرات خودکار کد و استقرار مجدد آنها نمی‌شود، اینها الزامات بسیار معمولی در علم داده هستند. اینکه چگونه این ادغام و استقرار خودکار شامل (بخش هایی از) تنظیم اولیه و آزمایش اعتبار می شود به پیچیدگی آن تغییرات خودکار بستگی دارد. در علم داده، هم تست و هم نظارت، اجزای جدایی ناپذیر خود فرآیند هستند. ما کمتر روی آزمایش فرآیند ایجاد خود تمرکز می کنیم (اگرچه می خواهیم مسیر راه حل خود را بایگانی/نسخه کنیم)، و بیشتر بر روی آزمایش مداوم فرآیند تولید تمرکز می کنیم. موارد آزمایشی در اینجا نیز جفت‌های «ورودی-نتیجه» هستند، اما به احتمال زیاد شامل نقاط داده‌ای هستند تا موارد آزمایش.

این تفاوت در نظارت بر اعتبار سنجی قبل از استقرار نیز تأثیر می گذارد. در استقرار نرم‌افزار، ما مطمئن می‌شویم که برنامه ما تست‌های خود را پشت سر گذاشته است. برای فرآیند تولید علم داده، ممکن است نیاز به آزمایش داشته باشیم تا مطمئن شویم که نقاط داده استاندارد همچنان به همان طبقه تعلق دارند (مثلاً، مشتریان «خوب» همچنان رتبه اعتباری بالایی دریافت می‌کنند) و ناهنجاری‌های شناخته شده همچنان مشاهده می‌شوند. به عنوان مثال، خطاهای شناخته شده محصول همچنان به عنوان “عیب” طبقه بندی می شوند). ما همچنین ممکن است بخواهیم اطمینان حاصل کنیم که فرآیند علم داده ما هنوز از پردازش الگوهای کاملاً پوچ خودداری می کند (بیمار بدنام “مرد و باردار”). به طور خلاصه، ما می‌خواهیم اطمینان حاصل کنیم که موارد آزمایشی که به نقاط داده معمولی یا غیرعادی یا نقاط پرت ساده اشاره می‌کنند همچنان همانطور که انتظار می‌رود رفتار می‌شوند.

MLOps، ModelOps و XOps

همه اینها چگونه به MLOps، ModelOps، یا XOps (همانطور که Gartner ترکیب DataOps، ModelOps و DevOps می نامد) مرتبط است؟ افرادی که به آن اصطلاحات اشاره می کنند اغلب دو واقعیت کلیدی را نادیده می گیرند: اول اینکه پیش پردازش داده ها بخشی از فرآیند تولید است (و نه فقط یک “مدل” که در تولید قرار می گیرد) و دوم اینکه نظارت بر مدل در محیط تولید اغلب فقط انجام می شود. ایستا و غیر واکنشی.

در حال حاضر، بسیاری از پشته های علم داده تنها به بخش هایی از چرخه حیات علم داده می پردازند. نه تنها قسمت‌های دیگر باید به صورت دستی انجام شوند، بلکه در بسیاری از موارد شکاف‌های بین فناوری‌ها نیاز به کدگذاری مجدد دارند، بنابراین استخراج کاملاً خودکار فرآیند علم داده تولید غیرممکن است. تا زمانی که مردم متوجه نشوند که تولید واقعی علم داده چیزی بیش از پرتاب کردن یک مدل بسته بندی شده زیبا روی دیوار است، هر زمان که سازمان ها سعی کنند به طور قابل اعتماد علم داده را به بخشی جدایی ناپذیر از عملیات خود تبدیل کنند، همچنان شاهد شکست خواهیم بود.

فرایندهای علم داده هنوز راه درازی در پیش دارند، اما CI/CD درس‌های زیادی ارائه می‌دهد که می‌توان بر اساس آنها ساخته شد. با این حال، دو تفاوت اساسی بین CI/CD برای علم داده و CI/CD برای توسعه نرم افزار وجود دارد. اول، “فرایند تولید علم داده” که به طور خودکار در طول یکپارچه سازی ایجاد می شود با آنچه توسط تیم علم داده ایجاد شده است متفاوت است. و دوم، نظارت در تولید ممکن است منجر به به‌روزرسانی و استقرار مجدد خودکار شود. یعنی ممکن است چرخه استقرار به طور خودکار توسط فرآیند نظارتی که فرآیند علم داده در تولید را بررسی می‌کند، راه‌اندازی شود، و تنها زمانی که آن نظارت تغییرات شدید را تشخیص داد، ما به سنگرها برمی‌گردیم و کل فرآیند را مجدداً راه‌اندازی می‌کنیم.

مایکل برتولد مدیر عامل و یکی از بنیانگذاران KNIME، یک شرکت تجزیه و تحلیل داده منبع باز است. او بیش از ۲۵ سال تجربه در علم داده، کار در دانشگاه، اخیراً به عنوان استاد تمام در دانشگاه کنستانز (آلمان) و قبلاً در دانشگاه کالیفرنیا (برکلی) و کارنگی ملون، و در صنعت در گروه شبکه عصبی اینتل، دارد. Utopy و Tripos. مایکل در مورد تجزیه و تحلیل داده ها، یادگیری ماشینی و هوش مصنوعی مطالب زیادی منتشر کرده است. مایکل را در تویتر، LinkedIn و وبلاگ KNIME.

—

انجمن فناوری جدید مکانی را برای کاوش و بحث در مورد فناوری سازمانی نوظهور در عمق و وسعت بی سابقه ای فراهم می کند. انتخاب ذهنی است، بر اساس انتخاب ما از فناوری هایی که معتقدیم مهم هستند و برای خوانندگان InfoWorld بیشترین علاقه را دارند. InfoWorld وثیقه بازاریابی را برای انتشار نمی پذیرد و حق ویرایش تمام محتوای ارائه شده را برای خود محفوظ می دارد. همه سوالات را به newtechforum@infoworld.com ارسال کنید.