صنعتی مشین لرننگ: 10 ڈیزائن کے اصول
آج کل، ہر روز نئی سروسز، ایپلی کیشنز اور دیگر اہم پروگرام بنائے جاتے ہیں جو ناقابل یقین چیزوں کو تخلیق کرنا ممکن بناتے ہیں: اسپیس ایکس راکٹ کو کنٹرول کرنے کے سافٹ ویئر سے لے کر اسمارٹ فون کے ذریعے اگلے کمرے میں کیتلی کے ساتھ بات چیت تک۔
اور، کبھی کبھی، ہر نوسکھئیے پروگرامر، خواہ وہ ایک پرجوش اسٹارٹ اپر ہو یا ایک عام فل اسٹیک یا ڈیٹا سائنٹسٹ، جلد یا بدیر اس بات کا احساس کرتا ہے کہ پروگرامنگ اور سافٹ ویئر بنانے کے لیے کچھ اصول ہیں جو زندگی کو بہت آسان بنا دیتے ہیں۔
اس مضمون میں، میں صنعتی مشین لرننگ کو پروگرام کرنے کے طریقے کے 10 اصولوں کو مختصراً بیان کروں گا تاکہ اسے 12 فیکٹر ایپ طریقہ کار کی بنیاد پر آسانی سے کسی ایپلیکیشن/سروس میں ضم کیا جا سکے۔ . میری پہل اس تکنیک کے بارے میں آگاہی کو بڑھانا ہے، جو بہت سے ڈویلپرز اور ڈیٹا سائنس کے لوگوں کی مدد کر سکتی ہے۔
یہ مضمون صنعتی مشین لرننگ کے بارے میں مضامین کی ایک سیریز کا پیش خیمہ ہے۔ ان میں میں اس بارے میں مزید بات کروں گا کہ کس طرح ایک ماڈل بنایا جائے اور اسے پروڈکشن میں کیسے لانچ کیا جائے، اس کے لیے ایک API بنایا جائے، نیز مختلف شعبوں اور کمپنیوں کی مثالیں جن کے سسٹم میں ایم ایل بلٹ ان ہے۔
اصول 1: ایک کوڈ کی بنیاد
کچھ پروگرامرز پہلے مرحلے پر، اس کا پتہ لگانے میں سستی کی وجہ سے (یا اپنی کسی وجہ سے)، گٹ کو بھول جاتے ہیں۔ وہ یا تو لفظ کو مکمل طور پر بھول جاتے ہیں، یعنی وہ فائلیں ایک دوسرے کو ڈرائیو میں پھینک دیتے ہیں/صرف ٹیکسٹ پھینک دیتے ہیں/کبوتروں کے ذریعے بھیجتے ہیں، یا وہ اپنے ورک فلو کے بارے میں نہیں سوچتے ہیں، اور ہر ایک کو اپنی اپنی برانچ سے کمٹمنٹ کرتے ہیں، اور پھر ماسٹر
یہ اصول بیان کرتا ہے: ایک کوڈبیس ہے اور بہت سی تعیناتیاں۔
گٹ کو پروڈکشن اور ریسرچ اینڈ ڈیولپمنٹ (R&D) دونوں میں استعمال کیا جا سکتا ہے، جس میں اسے اتنی کثرت سے استعمال نہیں کیا جاتا ہے۔
مثال کے طور پر، R&D مرحلے میں آپ ڈیٹا پروسیسنگ کے مختلف طریقوں اور ماڈلز کے ساتھ کمٹ چھوڑ سکتے ہیں، تاکہ پھر بہترین کو منتخب کر سکیں اور آسانی سے اس کے ساتھ مزید کام جاری رکھیں۔
دوم، پروڈکشن میں یہ ایک ناقابل تلافی چیز ہے - آپ کو مسلسل یہ دیکھنا ہوگا کہ آپ کا کوڈ کیسے بدلتا ہے اور یہ جاننا ہوگا کہ کس ماڈل نے بہترین نتائج دیے، آخر میں کس کوڈ نے کام کیا اور ایسا کیا ہوا جس کی وجہ سے اس نے کام کرنا چھوڑ دیا یا غلط نتائج دینا شروع کردیے۔ . عہد اسی کے لیے ہوتے ہیں!
آپ اپنے پروجیکٹ کا ایک پیکج بھی بنا سکتے ہیں، اسے رکھ کر، مثال کے طور پر، Gemfury پر، اور پھر اس سے دوسرے پروجیکٹس کے لیے صرف فنکشنز درآمد کر سکتے ہیں، تاکہ انہیں 1000 بار دوبارہ نہ لکھا جائے، لیکن اس کے بعد مزید۔
اصول 2: واضح طور پر انحصار کا اعلان اور الگ تھلگ کریں۔
ہر پروجیکٹ میں مختلف لائبریریاں ہوتی ہیں جنہیں آپ باہر سے درآمد کرتے ہیں تاکہ انہیں کہیں لاگو کیا جا سکے۔ چاہے یہ Python لائبریریاں ہوں، یا مختلف مقاصد کے لیے دوسری زبانوں کی لائبریریاں، یا سسٹم ٹولز - آپ کا کام یہ ہے:
- واضح طور پر انحصار کا اعلان کریں، یعنی ایک فائل جس میں تمام لائبریریاں، ٹولز اور ان کے وہ ورژن ہوں گے جو آپ کے پروجیکٹ میں استعمال ہوتے ہیں اور اسے انسٹال کرنا ضروری ہے (مثال کے طور پر، Python میں یہ Pipfile یا requirements.txt کا استعمال کرتے ہوئے کیا جا سکتا ہے۔ لنک جو اچھی طرح سے سمجھنے کی اجازت دیتا ہے: )
- ڈویلپمنٹ کے دوران خاص طور پر اپنے پروگرام کے لیے انحصار کو الگ کریں۔ آپ ورژن کو مسلسل تبدیل کرنا اور دوبارہ انسٹال نہیں کرنا چاہتے، مثال کے طور پر، Tensorflow؟
اس طرح، مستقبل میں آپ کی ٹیم میں شامل ہونے والے ڈویلپرز آپ کے پروجیکٹ میں استعمال ہونے والی لائبریریوں اور ان کے ورژنز سے جلد واقف ہو سکیں گے، اور آپ کو ایک مخصوص کے لیے انسٹال کردہ ورژنز اور لائبریریوں کا خود انتظام کرنے کا موقع بھی ملے گا۔ پروجیکٹ، جو آپ کو لائبریریوں یا ان کے ورژن کی عدم مطابقت سے بچنے میں مدد کرے گا۔
آپ کی ایپلیکیشن کو سسٹم ٹولز پر بھی انحصار نہیں کرنا چاہیے جو کسی مخصوص OS پر انسٹال ہو سکتے ہیں۔ ان ٹولز کو انحصار مینی فیسٹ میں بھی اعلان کیا جانا چاہیے۔ یہ ان حالات سے بچنے کے لیے ضروری ہے جہاں ٹولز کا ورژن (نیز ان کی دستیابی) کسی خاص OS کے سسٹم ٹولز سے میل نہیں کھاتا۔
اس طرح، یہاں تک کہ اگر curl کو تقریباً تمام کمپیوٹرز پر استعمال کیا جا سکتا ہے، تب بھی آپ کو انحصار میں اس کا اعلان کرنا چاہیے، کیونکہ جب دوسرے پلیٹ فارم پر منتقل ہوتا ہے تو ہو سکتا ہے کہ یہ وہاں نہ ہو یا وہ ورژن نہ ہو جس کی آپ کو اصل ضرورت تھی۔
مثال کے طور پر، آپ کی ضروریات.txt اس طرح نظر آ سکتی ہے:
# Model Building Requirements
numpy>=1.18.1,<1.19.0
pandas>=0.25.3,<0.26.0
scikit-learn>=0.22.1,<0.23.0
joblib>=0.14.1,<0.15.0
# testing requirements
pytest>=5.3.2,<6.0.0
# packaging
setuptools>=41.4.0,<42.0.0
wheel>=0.33.6,<0.34.0
# fetching datasets
kaggle>=1.5.6,<1.6.0
اصول 3: کنفیگریشنز
بہت سے لوگوں نے کہانیاں سنی ہیں کہ مختلف ڈویلپر لڑکوں نے غلطی سے GitHub پر کوڈ کو AWS سے پاس ورڈز اور دیگر کلیدوں کے ساتھ کھلے ذخیرہ میں اپ لوڈ کر دیا، جو اگلے دن $6000، یا اس سے بھی $50000 کا قرض لے کر جاگتے ہیں۔
بے شک، یہ معاملات انتہائی ہیں، لیکن بہت اہم ہیں. اگر آپ اپنی اسناد یا کوڈ کے اندر کنفیگریشن کے لیے درکار دیگر ڈیٹا اسٹور کرتے ہیں، تو آپ غلطی کر رہے ہیں، اور میرے خیال میں اس کی وجہ بتانے کی ضرورت نہیں ہے۔
اس کا ایک متبادل ماحولیاتی متغیرات میں کنفیگریشنز کو اسٹور کرنا ہے۔ آپ ماحولیاتی متغیرات کے بارے میں مزید پڑھ سکتے ہیں۔ .
ڈیٹا کی مثالیں جو عام طور پر ماحولیاتی متغیرات میں محفوظ کی جاتی ہیں:
- ڈومین کے نام
- API URLs/URI's
- عوامی اور نجی چابیاں
- رابطے (میل، فون، وغیرہ)
اس طرح اگر آپ کے کنفیگریشن متغیرات بدل جاتے ہیں تو آپ کو کوڈ کو مسلسل تبدیل کرنے کی ضرورت نہیں ہے۔ اس سے آپ کا وقت، محنت اور پیسہ بچانے میں مدد ملے گی۔
مثال کے طور پر، اگر آپ ٹیسٹ کرنے کے لیے Kaggle API کا استعمال کرتے ہیں (مثال کے طور پر، سافٹ ویئر ڈاؤن لوڈ کریں اور اس کے ذریعے ماڈل کو چلائیں تاکہ یہ ٹیسٹ کیا جا سکے کہ ماڈل اچھی طرح سے کام کرتا ہے)، تو Kaggle کی نجی کلیدیں، جیسے KAGGLE_USERNAME اور KAGGLE_KEY، ہونی چاہئیں۔ ماحولیاتی متغیرات میں محفوظ
اصول 4: فریق ثالث کی خدمات
یہاں خیال یہ ہے کہ پروگرام کو اس طرح بنایا جائے کہ کوڈ کے لحاظ سے مقامی اور تیسرے فریق کے وسائل میں کوئی فرق نہ ہو۔ مثال کے طور پر، آپ مقامی MySQL اور فریق ثالث دونوں کو جوڑ سکتے ہیں۔ مختلف APIs جیسے گوگل میپس یا ٹویٹر API کے لیے بھی یہی ہے۔
تھرڈ پارٹی سروس کو غیر فعال کرنے یا کسی اور کو جوڑنے کے لیے، آپ کو ماحول کے متغیرات میں کنفیگریشن کی کلیدوں کو تبدیل کرنے کی ضرورت ہے، جس کے بارے میں میں نے اوپر پیراگراف میں بات کی ہے۔
لہذا، مثال کے طور پر، ہر بار کوڈ کے اندر ڈیٹاسیٹس والی فائلوں کا راستہ بتانے کے بجائے، یہ بہتر ہے کہ pathlib لائبریری کا استعمال کریں اور config.py میں ڈیٹاسیٹس کے راستے کا اعلان کریں، تاکہ اس بات سے کوئی فرق نہیں پڑتا ہے کہ آپ جو بھی سروس استعمال کرتے ہیں (کے لیے مثال کے طور پر، CircleCI)، پروگرام نئی سروس میں نئے فائل سسٹم کی ساخت کو مدنظر رکھتے ہوئے ڈیٹاسیٹس کا راستہ تلاش کرنے کے قابل تھا۔
اصول 5. تعمیر، ریلیز، رن ٹائم
ڈیٹا سائنس میں بہت سے لوگوں کو اپنی سافٹ ویئر لکھنے کی مہارت کو بہتر بنانا مفید لگتا ہے۔ اگر ہم چاہتے ہیں کہ ہمارا پروگرام ممکنہ حد تک شاذ و نادر ہی کریش ہو اور جب تک ممکن ہو ناکامی کے بغیر کام کرے، ہمیں نئے ورژن کو جاری کرنے کے عمل کو 3 مراحل میں تقسیم کرنے کی ضرورت ہے:
- اسٹیج اسمبلیاں. آپ انفرادی وسائل کے ساتھ اپنے ننگے کوڈ کو ایک نام نہاد پیکیج میں تبدیل کرتے ہیں جس میں تمام ضروری کوڈ اور ڈیٹا ہوتا ہے۔ اس پیکیج کو اسمبلی کہا جاتا ہے۔
- اسٹیج رہائی - یہاں ہم اپنی تشکیل کو اسمبلی سے جوڑتے ہیں، جس کے بغیر ہم اپنا پروگرام جاری نہیں کر پائیں گے۔ اب یہ مکمل طور پر لانچ کے لیے تیار ریلیز ہے۔
- اگلا مرحلہ آتا ہے۔ تکمیل. یہاں ہم اپنی ریلیز سے ضروری عمل چلا کر درخواست کو جاری کرتے ہیں۔
ماڈل یا پوری پائپ لائن کے نئے ورژن جاری کرنے کا ایسا نظام آپ کو منتظمین اور ڈویلپرز کے درمیان کردار الگ کرنے کی اجازت دیتا ہے، آپ کو ورژن کو ٹریک کرنے کی اجازت دیتا ہے اور پروگرام کے ناپسندیدہ سٹاپ کو روکتا ہے۔
ریلیز ٹاسک کے لیے، بہت سی مختلف سروسز بنائی گئی ہیں جن میں آپ خود کو .yml فائل میں چلانے کے لیے پراسیس لکھ سکتے ہیں (مثال کے طور پر، CircleCI میں یہ config.yml ہے جو اس عمل کو سپورٹ کرنے کے لیے ہے)۔ Wheely منصوبوں کے لئے پیکج بنانے میں بہت اچھا ہے.
آپ اپنے مشین لرننگ ماڈل کے مختلف ورژن کے ساتھ پیکجز بنا سکتے ہیں، اور پھر ان کو پیک کر سکتے ہیں اور ضروری پیکجز اور ان کے ورژنز کا حوالہ دیتے ہوئے ان فنکشنز کو استعمال کر سکتے ہیں جو آپ نے وہاں سے لکھے ہیں۔ اس سے آپ کو اپنے ماڈل کے لیے ایک API بنانے میں مدد ملے گی، اور مثال کے طور پر آپ کے پیکج کو Gemfury پر ہوسٹ کیا جا سکتا ہے۔
اصول 6۔ اپنے ماڈل کو ایک یا زیادہ عمل کے طور پر چلائیں۔
مزید یہ کہ عمل میں ڈیٹا کا اشتراک نہیں ہونا چاہیے۔ یعنی، عمل الگ سے موجود ہونا چاہیے، اور ہر قسم کا ڈیٹا الگ سے موجود ہونا چاہیے، مثال کے طور پر، تیسری پارٹی کی خدمات جیسے MySQL یا دیگر پر، آپ کی ضرورت کے مطابق۔
یعنی، یہ یقینی طور پر پراسیس فائل سسٹم کے اندر ڈیٹا کو ذخیرہ کرنے کے قابل نہیں ہے، بصورت دیگر یہ اس ڈیٹا کو اگلے ریلیز / کنفیگریشنز میں تبدیلی یا اس سسٹم کی منتقلی کے دوران صاف کرنے کا باعث بن سکتا ہے جس پر پروگرام چلتا ہے۔
لیکن اس میں ایک استثناء ہے: مشین لرننگ پروجیکٹس کے لیے، آپ لائبریریوں کا ذخیرہ ذخیرہ کرسکتے ہیں تاکہ جب بھی آپ نیا ورژن لانچ کریں تو انہیں دوبارہ انسٹال نہ کریں، اگر کوئی اضافی لائبریری یا ان کے ورژن میں کوئی تبدیلی نہیں کی گئی ہے۔ اس طرح، آپ اپنے ماڈل کو انڈسٹری میں لانچ کرنے میں لگنے والے وقت کو کم کر دیں گے۔
ماڈل کو کئی عملوں کے طور پر چلانے کے لیے، آپ ایک .yml فائل بنا سکتے ہیں جس میں آپ ضروری عمل اور ان کی ترتیب کو بیان کرتے ہیں۔
اصول 7: ری سائیکلیبلٹی
آپ کے ماڈل ایپلیکیشن میں چلنے والے عمل کو شروع کرنا اور بند کرنا آسان ہونا چاہیے۔ اس طرح، یہ آپ کو کوڈ کی تبدیلیوں، کنفیگریشن کی تبدیلیوں، تیزی سے اور لچکدار طریقے سے پیمانے، اور ورکنگ ورژن کے ممکنہ خرابی کو روکنے کی اجازت دے گا۔
یعنی، ماڈل کے ساتھ آپ کے عمل کو:
- آغاز کا وقت کم سے کم کریں۔ مثالی طور پر، سٹارٹ اپ کا وقت (جس لمحے سے سٹارٹ اپ کمانڈ جاری کیا گیا تھا اس لمحے سے لے کر عمل کے شروع ہونے تک) چند سیکنڈ سے زیادہ نہیں ہونا چاہیے۔ لائبریری کیچنگ، جو اوپر بیان کی گئی ہے، آغاز کے وقت کو کم کرنے کی ایک تکنیک ہے۔
- صحیح طریقے سے ختم کریں۔ یعنی، سروس پورٹ پر سننا دراصل معطل ہے، اور اس پورٹ پر جمع کرائی گئی نئی درخواستوں پر کارروائی نہیں کی جائے گی۔ یہاں آپ کو یا تو DevOps انجینئرز کے ساتھ اچھا مواصلت قائم کرنے کی ضرورت ہے، یا یہ سمجھنے کی ضرورت ہے کہ یہ خود کیسے کام کرتا ہے (ترجیحی طور پر، یقینا، بعد میں، لیکن کسی بھی پروجیکٹ میں مواصلات کو ہمیشہ برقرار رکھا جانا چاہیے!)
اصول 8: مسلسل تعیناتی/انضمام
بہت سی کمپنیاں ایپلیکیشن ڈویلپمنٹ اور تعیناتی ٹیموں کے درمیان علیحدگی کا استعمال کرتی ہیں (ایپلی کیشن کو آخری صارفین کے لیے دستیاب بنانا)۔ یہ سافٹ ویئر کی ترقی اور اسے بہتر بنانے میں پیشرفت کو بہت سست کر سکتا ہے۔ یہ DevOps کلچر کو بھی خراب کرتا ہے، جہاں ترقی اور انضمام، تقریباً بولتے ہوئے، مشترکہ ہیں۔
لہذا، یہ اصول یہ بتاتا ہے کہ آپ کی ترقی کا ماحول آپ کے پیداواری ماحول کے جتنا ممکن ہو قریب ہونا چاہیے۔
یہ اجازت دے گا:
- ریلیز کے وقت کو دسیوں گنا کم کریں۔
- کوڈ کی عدم مطابقت کی وجہ سے غلطیوں کی تعداد کو کم کریں۔
- اس سے عملے پر کام کا بوجھ بھی کم ہوتا ہے، کیونکہ ڈیولپرز اور ایپلیکیشن کو تعینات کرنے والے لوگ اب ایک ٹیم ہیں۔
ٹولز جو آپ کو اس کے ساتھ کام کرنے کی اجازت دیتے ہیں وہ ہیں CircleCI، Travis CI، GitLab CI اور دیگر۔
آپ ماڈل میں تیزی سے اضافہ کر سکتے ہیں، اسے اپ ڈیٹ کر سکتے ہیں، اور اسے فوری طور پر لانچ کر سکتے ہیں، جبکہ ناکامی کی صورت میں، کام کرنے والے ورژن پر بہت جلد واپس آنا آسان ہو گا، تاکہ آخری صارف کو اس کا نوٹس تک نہ ہو۔ یہ خاص طور پر آسانی سے اور تیزی سے کیا جا سکتا ہے اگر آپ کے اچھے ٹیسٹ ہوں۔
اختلافات کو کم کریں!!!
اصول 9. آپ کے نوشتہ جات
لاگز (یا "لاگز") ایسے واقعات ہیں، جو عام طور پر ٹیکسٹ فارمیٹ میں ریکارڈ کیے جاتے ہیں، جو ایپلیکیشن (ایونٹ اسٹریم) کے اندر ہوتے ہیں۔ ایک سادہ مثال: "2020-02-02 - سسٹم لیول - عمل کا نام۔" وہ اس لیے ڈیزائن کیے گئے ہیں تاکہ ڈویلپر لفظی طور پر دیکھ سکے کہ جب پروگرام چل رہا ہے تو کیا ہو رہا ہے۔ وہ عمل کی پیشرفت کو دیکھتا ہے اور سمجھتا ہے کہ آیا یہ وہی ہے جیسا کہ ڈویلپر نے خود ارادہ کیا تھا۔
یہ اصول بتاتا ہے کہ آپ کو اپنے لاگز کو اپنے فائل سسٹم کے اندر ذخیرہ نہیں کرنا چاہئے - آپ کو انہیں صرف اسکرین پر "آؤٹ پٹ" کرنا چاہئے، مثال کے طور پر، یہ سسٹم کے معیاری آؤٹ پٹ پر کریں۔ اور اس طرح ترقی کے دوران ٹرمینل میں بہاؤ کی نگرانی کرنا ممکن ہو جائے گا۔
کیا اس کا مطلب یہ ہے کہ لاگ کو محفوظ کرنے کی بالکل ضرورت نہیں ہے؟ ہرگز نہیں۔ آپ کی درخواست کو ایسا نہیں کرنا چاہیے—اسے فریق ثالث کی خدمات پر چھوڑ دیں۔ آپ کی ایپلیکیشن صرف لاگز کو کسی مخصوص فائل یا ٹرمینل پر ریئل ٹائم دیکھنے کے لیے آگے بھیج سکتی ہے، یا اسے عام مقصد کے ڈیٹا اسٹوریج سسٹم (جیسے ہڈوپ) پر بھیج سکتی ہے۔ آپ کی درخواست کو خود ہی لاگز کو اسٹور یا ان کے ساتھ تعامل نہیں کرنا چاہیے۔
اصول 10. ٹیسٹ!
صنعتی مشین لرننگ کے لیے، یہ مرحلہ انتہائی اہم ہے، کیونکہ آپ کو یہ سمجھنے کی ضرورت ہے کہ ماڈل صحیح طریقے سے کام کرتا ہے اور وہی پیدا کرتا ہے جو آپ چاہتے تھے۔
پیسٹسٹ کا استعمال کرتے ہوئے ٹیسٹ بنائے جا سکتے ہیں، اور اگر آپ کے پاس رجعت/ درجہ بندی کا کام ہے تو چھوٹے ڈیٹاسیٹ کا استعمال کرتے ہوئے ٹیسٹ کیا جا سکتا ہے۔
گہرے سیکھنے کے ماڈلز کے لیے ایک ہی بیج کو ترتیب دینا نہ بھولیں تاکہ وہ مسلسل مختلف نتائج پیدا نہ کریں۔
یہ 10 اصولوں کی ایک مختصر وضاحت تھی، اور یقیناً، بغیر کوشش کیے اور یہ دیکھے کہ وہ کیسے کام کرتے ہیں ان کا استعمال کرنا مشکل ہے، اس لیے یہ مضمون دلچسپ مضامین کی ایک سیریز کا محض ایک تجویز ہے جس میں میں یہ بتاؤں گا کہ اسے کیسے بنایا جائے۔ صنعتی مشین لرننگ ماڈلز، انہیں سسٹمز میں کیسے ضم کیا جائے، اور یہ اصول ہم سب کی زندگی کو کس طرح آسان بنا سکتے ہیں۔
میں ٹھنڈے اصولوں کو استعمال کرنے کی بھی کوشش کروں گا جو کوئی چاہے تو کمنٹس میں چھوڑ سکتا ہے۔
ماخذ: www.habr.com