ইন্ডাস্ট্রিয়াল মেশিন লার্নিং: 10টি ডিজাইনের নীতি

ইন্ডাস্ট্রিয়াল মেশিন লার্নিং: 10টি ডিজাইনের নীতি

আজকাল, নতুন পরিষেবা, অ্যাপ্লিকেশন এবং অন্যান্য গুরুত্বপূর্ণ প্রোগ্রামগুলি প্রতিদিন তৈরি করা হয় যা অবিশ্বাস্য জিনিসগুলি তৈরি করা সম্ভব করে: স্পেসএক্স রকেট নিয়ন্ত্রণের সফ্টওয়্যার থেকে স্মার্টফোনের মাধ্যমে পাশের ঘরে একটি কেটলির সাথে ইন্টারঅ্যাক্ট করা পর্যন্ত।

এবং, কখনও কখনও, প্রতিটি নবীন প্রোগ্রামার, সে একজন উত্সাহী স্টার্টআপার হোক বা একজন সাধারণ ফুল স্ট্যাক বা ডেটা সায়েন্টিস্ট হোক না কেন, শীঘ্র বা পরে উপলব্ধি করতে পারে যে প্রোগ্রামিং এবং সফ্টওয়্যার তৈরির জন্য কিছু নির্দিষ্ট নিয়ম রয়েছে যা জীবনকে অনেক সহজ করে তোলে।

এই প্রবন্ধে, আমি সংক্ষেপে 10টি নীতি বর্ণনা করব কিভাবে ইন্ডাস্ট্রিয়াল মেশিন লার্নিং প্রোগ্রাম করতে হয় যাতে এটি 12-ফ্যাক্টর অ্যাপ পদ্ধতির উপর ভিত্তি করে সহজেই একটি অ্যাপ্লিকেশন/পরিষেবাতে একত্রিত করা যায়। Heroku দল দ্বারা প্রস্তাবিত. আমার উদ্যোগ এই কৌশল সম্পর্কে সচেতনতা বাড়ানোর জন্য, যা অনেক ডেভেলপার এবং ডেটা সায়েন্সের মানুষকে সাহায্য করতে পারে।

এই নিবন্ধটি শিল্প মেশিন লার্নিং সম্পর্কে নিবন্ধগুলির একটি সিরিজের একটি প্রস্তাবনা। সেগুলিতে আমি আরও কথা বলব কীভাবে আসলে একটি মডেল তৈরি করা যায় এবং এটি উত্পাদনে চালু করা যায়, এটির জন্য একটি এপিআই তৈরি করা যায়, পাশাপাশি তাদের সিস্টেমে বিল্ট-ইন এমএল রয়েছে এমন বিভিন্ন ক্ষেত্র এবং সংস্থাগুলির উদাহরণ।

নীতি 1: এক কোড বেস

প্রথম পর্যায়ে কিছু প্রোগ্রামার, এটি বের করতে অলসতার কারণে (বা তাদের নিজস্ব কিছু কারণে), গিট সম্পর্কে ভুলে যান। তারা হয় শব্দটি সম্পূর্ণভাবে ভুলে যায়, অর্থাৎ, তারা ড্রাইভে একে অপরের কাছে ফাইল ছুঁড়ে দেয়/শুধু পাঠ্য ছুঁড়ে দেয়/পায়রা দ্বারা পাঠায়, অথবা তারা তাদের কর্মপ্রবাহের মাধ্যমে চিন্তা করে না, এবং প্রত্যেকে তাদের নিজস্ব শাখায় প্রতিশ্রুতি দেয় এবং তারপরে মাস্টার

এই নীতিটি বলে: একটি কোডবেস এবং অনেক স্থাপনা আছে।

Git উৎপাদন এবং গবেষণা ও উন্নয়ন (R&D) উভয় ক্ষেত্রেই ব্যবহার করা যেতে পারে, যেখানে এটি প্রায়শই ব্যবহৃত হয় না।

উদাহরণস্বরূপ, R&D পর্বে আপনি বিভিন্ন ডেটা প্রসেসিং পদ্ধতি এবং মডেলের সাথে প্রতিশ্রুতি ছেড়ে দিতে পারেন, যাতে তারপরে সেরাটি নির্বাচন করা যায় এবং সহজেই এটির সাথে আরও কাজ করা চালিয়ে যায়।

দ্বিতীয়ত, উত্পাদনে এটি একটি অপরিবর্তনীয় জিনিস - আপনাকে ক্রমাগত দেখতে হবে কীভাবে আপনার কোডটি পরিবর্তিত হয় এবং কোন মডেলটি সর্বোত্তম ফলাফল দেয়, কোন কোডটি শেষ পর্যন্ত কাজ করেছিল এবং কী ঘটেছিল যার কারণে এটি কাজ করা বন্ধ করেছে বা ভুল ফলাফল তৈরি করতে শুরু করেছে। . যে জন্য প্রতিশ্রুতি হয়!

আপনি আপনার প্রকল্পের একটি প্যাকেজও তৈরি করতে পারেন, এটি স্থাপন করতে পারেন, উদাহরণস্বরূপ, জেমফুরিতে, এবং তারপরে অন্যান্য প্রকল্পের জন্য এটি থেকে ফাংশনগুলি আমদানি করতে পারেন, যাতে সেগুলি 1000 বার পুনরায় লেখা না হয়, তবে পরে আরও বেশি।

নীতি 2: স্পষ্টভাবে ঘোষণা করুন এবং নির্ভরতা বিচ্ছিন্ন করুন

প্রতিটি প্রকল্পের বিভিন্ন লাইব্রেরি রয়েছে যা আপনি বাইরে থেকে আমদানি করে কোথাও প্রয়োগ করার জন্য। এটি পাইথন লাইব্রেরি, বা বিভিন্ন উদ্দেশ্যে অন্যান্য ভাষার লাইব্রেরি, বা সিস্টেম টুলস - আপনার কাজ হল:

• স্পষ্টভাবে নির্ভরতা ঘোষণা করুন, অর্থাৎ, একটি ফাইল যাতে আপনার প্রকল্পে ব্যবহৃত সমস্ত লাইব্রেরি, সরঞ্জাম এবং তাদের সংস্করণগুলি থাকবে এবং এটি অবশ্যই ইনস্টল করা উচিত (উদাহরণস্বরূপ, পাইথনে এটি Pipfile বা requirements.txt ব্যবহার করে করা যেতে পারে। লিঙ্ক যা ভাল বুঝতে অনুমতি দেয়: realpython.com/pipenv-guide)
• বিকাশের সময় আপনার প্রোগ্রামের জন্য বিশেষভাবে নির্ভরতা বিচ্ছিন্ন করুন। আপনি ক্রমাগত সংস্করণ পরিবর্তন করতে চান না এবং পুনরায় ইনস্টল করতে চান না, উদাহরণস্বরূপ, টেনসরফ্লো?

এইভাবে, ভবিষ্যতে আপনার দলে যোগদানকারী বিকাশকারীরা আপনার প্রকল্পে ব্যবহৃত লাইব্রেরি এবং তাদের সংস্করণগুলির সাথে দ্রুত পরিচিত হতে সক্ষম হবেন এবং আপনি একটি নির্দিষ্ট জন্য ইনস্টল করা সংস্করণ এবং লাইব্রেরিগুলি পরিচালনা করার সুযোগ পাবেন। প্রকল্প, যা আপনাকে লাইব্রেরি বা তাদের সংস্করণগুলির অসঙ্গতি এড়াতে সহায়তা করবে।

আপনার অ্যাপ্লিকেশনটি একটি নির্দিষ্ট OS-এ ইনস্টল হতে পারে এমন সিস্টেম সরঞ্জামগুলির উপর নির্ভর করা উচিত নয়। এই সরঞ্জামগুলি অবশ্যই নির্ভরতা ম্যানিফেস্টে ঘোষণা করতে হবে। এমন পরিস্থিতি এড়ানোর জন্য এটি প্রয়োজনীয় যেখানে সরঞ্জামগুলির সংস্করণ (পাশাপাশি তাদের উপলব্ধতা) একটি নির্দিষ্ট OS এর সিস্টেম সরঞ্জামগুলির সাথে মেলে না।

এইভাবে, প্রায় সমস্ত কম্পিউটারে কার্ল ব্যবহার করা গেলেও, আপনার এখনও এটিকে নির্ভরতা হিসাবে ঘোষণা করা উচিত, যেহেতু অন্য প্ল্যাটফর্মে স্থানান্তরিত করার সময় এটি সেখানে নাও থাকতে পারে বা আপনার প্রাথমিকভাবে প্রয়োজনীয় সংস্করণটি হবে না।

উদাহরণস্বরূপ, আপনার requirements.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: কনফিগারেশন

অনেকেই বিভিন্ন ডেভেলপারের গল্প শুনেছেন যে ভুলবশত AWS থেকে পাসওয়ার্ড এবং অন্যান্য কী সহ GitHub-এ কোড আপলোড করে, পরের দিন $6000 বা এমনকি $50000 ঋণ নিয়ে জেগে ওঠে।

অবশ্যই, এই ক্ষেত্রে চরম, কিন্তু খুব তাৎপর্যপূর্ণ. আপনি যদি কোডের ভিতরে আপনার শংসাপত্র বা কনফিগারেশনের জন্য প্রয়োজনীয় অন্যান্য ডেটা সঞ্চয় করেন তবে আপনি একটি ভুল করছেন এবং আমি মনে করি কেন ব্যাখ্যা করার দরকার নেই।

এর একটি বিকল্প হল পরিবেশ ভেরিয়েবলে কনফিগারেশন সংরক্ষণ করা। আপনি পরিবেশের ভেরিয়েবল সম্পর্কে আরও পড়তে পারেন এখানে.

ডেটার উদাহরণ যা সাধারণত পরিবেশের ভেরিয়েবলগুলিতে সংরক্ষণ করা হয়:

• ডোমেনের নাম
• এপিআই ইউআরএল/ইউআরআই
• সর্বজনীন এবং ব্যক্তিগত কী
• পরিচিতি (মেইল, ফোন, ইত্যাদি)

এইভাবে আপনার কনফিগারেশন ভেরিয়েবল পরিবর্তন হলে আপনাকে ক্রমাগত কোড পরিবর্তন করতে হবে না। এটি আপনাকে সময়, প্রচেষ্টা এবং অর্থ বাঁচাতে সাহায্য করবে।

উদাহরণ স্বরূপ, আপনি যদি পরীক্ষা চালানোর জন্য Kaggle API ব্যবহার করেন (উদাহরণস্বরূপ, সফ্টওয়্যার ডাউনলোড করুন এবং মডেলটি চালানোর সময় পরীক্ষা করার জন্য এটির মাধ্যমে মডেলটি চালান), তাহলে Kaggle থেকে ব্যক্তিগত কী, যেমন KAGGLE_USERNAME এবং KAGGLE_KEY, হওয়া উচিত পরিবেশ ভেরিয়েবলে সংরক্ষিত।

নীতি 4: তৃতীয় পক্ষের পরিষেবা

এখানে ধারণাটি এমনভাবে প্রোগ্রামটি তৈরি করা যাতে কোডের ক্ষেত্রে স্থানীয় এবং তৃতীয় পক্ষের সংস্থানগুলির মধ্যে কোনও পার্থক্য না থাকে। উদাহরণস্বরূপ, আপনি স্থানীয় MySQL এবং তৃতীয় পক্ষ উভয় সংযোগ করতে পারেন। Google Maps বা Twitter API-এর মতো বিভিন্ন API-এর ক্ষেত্রেও একই কথা যায়।

একটি তৃতীয় পক্ষের পরিষেবা অক্ষম করতে বা অন্যটি সংযোগ করতে, আপনাকে কেবল পরিবেশ ভেরিয়েবলের কনফিগারেশনের কীগুলি পরিবর্তন করতে হবে, যা আমি উপরের অনুচ্ছেদে বলেছি।

সুতরাং, উদাহরণস্বরূপ, প্রতিবার কোডের ভিতরে ডেটাসেট সহ ফাইলগুলির পাথ নির্দিষ্ট করার পরিবর্তে, pathlib লাইব্রেরি ব্যবহার করা এবং config.py-এ ডেটাসেটের পথ ঘোষণা করা ভাল, যাতে আপনি যে পরিষেবাই ব্যবহার করেন না কেন (এর জন্য উদাহরণস্বরূপ, সার্কেলসিআই), প্রোগ্রামটি নতুন পরিষেবাতে নতুন ফাইল সিস্টেমের কাঠামো বিবেচনা করে ডেটাসেটের পথ খুঁজে বের করতে সক্ষম হয়েছিল।

নীতি 5. বিল্ড, রিলিজ, রানটাইম

ডেটা সায়েন্সের অনেক লোক তাদের সফ্টওয়্যার লেখার দক্ষতা উন্নত করতে এটি দরকারী বলে মনে করে। যদি আমরা চাই যে আমাদের প্রোগ্রামটি যতটা সম্ভব কমই ক্র্যাশ হোক এবং যতটা সম্ভব ব্যর্থতা ছাড়াই কাজ করতে, আমাদের একটি নতুন সংস্করণ প্রকাশের প্রক্রিয়াটিকে 3টি পর্যায়ে ভাগ করতে হবে:

1. পর্যায় সমাবেশগুলি lies. আপনি স্বতন্ত্র সংস্থানগুলির সাথে আপনার বেয়ার কোডকে একটি তথাকথিত প্যাকেজে রূপান্তর করুন যাতে সমস্ত প্রয়োজনীয় কোড এবং ডেটা থাকে। এই প্যাকেজ একটি সমাবেশ বলা হয়.
2. পর্যায় মুক্তি — এখানে আমরা আমাদের কনফিগারেশনকে অ্যাসেম্বলিতে সংযুক্ত করি, যা ছাড়া আমরা আমাদের প্রোগ্রামটি প্রকাশ করতে সক্ষম হব না। এখন এটি একটি সম্পূর্ণ রেডি-টু-লঞ্চ রিলিজ।
3. পরবর্তী পর্যায়ে আসে পরিপূর্ণতা. এখানে আমরা আমাদের রিলিজ থেকে প্রয়োজনীয় প্রক্রিয়াগুলি চালিয়ে অ্যাপ্লিকেশনটি ছেড়ে দিই।

একটি মডেল বা সম্পূর্ণ পাইপলাইনের নতুন সংস্করণ প্রকাশের জন্য এই জাতীয় সিস্টেম আপনাকে প্রশাসক এবং বিকাশকারীদের মধ্যে আলাদা ভূমিকা রাখতে দেয়, আপনাকে সংস্করণগুলি ট্র্যাক করতে দেয় এবং প্রোগ্রামের অবাঞ্ছিত স্টপগুলি প্রতিরোধ করে।

রিলিজ টাস্কের জন্য, অনেকগুলি বিভিন্ন পরিষেবা তৈরি করা হয়েছে যেখানে আপনি একটি .yml ফাইলে নিজেকে চালানোর জন্য প্রক্রিয়াগুলি লিখতে পারেন (উদাহরণস্বরূপ, CircleCI-এ এটি প্রক্রিয়াটিকে সমর্থন করার জন্য config.yml)। হুইলি প্রকল্পগুলির জন্য প্যাকেজ তৈরিতে দুর্দান্ত।

আপনি আপনার মেশিন লার্নিং মডেলের বিভিন্ন সংস্করণের সাথে প্যাকেজ তৈরি করতে পারেন, এবং তারপর সেগুলিকে প্যাকেজ করুন এবং সেখান থেকে আপনার লেখা ফাংশনগুলি ব্যবহার করার জন্য প্রয়োজনীয় প্যাকেজ এবং তাদের সংস্করণগুলি দেখুন৷ এটি আপনাকে আপনার মডেলের জন্য একটি API তৈরি করতে সহায়তা করবে এবং আপনার প্যাকেজটি জেমফুরিতে হোস্ট করা যেতে পারে, উদাহরণস্বরূপ।

নীতি 6. এক বা একাধিক প্রক্রিয়া হিসাবে আপনার মডেল চালান

অধিকন্তু, প্রক্রিয়াগুলিতে ডেটা ভাগ করা উচিত নয়। অর্থাৎ, প্রক্রিয়াগুলি অবশ্যই আলাদাভাবে বিদ্যমান থাকতে হবে এবং সমস্ত ধরণের ডেটা আলাদাভাবে বিদ্যমান থাকতে হবে, উদাহরণস্বরূপ, আপনার যা প্রয়োজন তার উপর নির্ভর করে MySQL বা অন্যদের মতো তৃতীয় পক্ষের পরিষেবাগুলিতে।

অর্থাৎ, প্রসেস ফাইল সিস্টেমের মধ্যে ডেটা সংরক্ষণ করা অবশ্যই মূল্যবান নয়, অন্যথায় এটি পরবর্তী রিলিজ/কনফিগারেশনের পরিবর্তন বা প্রোগ্রামটি যে সিস্টেমে চলে সেই সিস্টেমের স্থানান্তরের সময় এই ডেটা ক্লিয়ার করতে পারে।

তবে একটি ব্যতিক্রম রয়েছে: মেশিন লার্নিং প্রকল্পগুলির জন্য, আপনি লাইব্রেরির ক্যাশে সংরক্ষণ করতে পারেন যাতে প্রতিবার আপনি একটি নতুন সংস্করণ চালু করার সময় সেগুলি পুনরায় ইনস্টল করতে না পারেন, যদি কোনও অতিরিক্ত লাইব্রেরি বা তাদের সংস্করণগুলিতে কোনও পরিবর্তন না করা হয়। এইভাবে, আপনি শিল্পে আপনার মডেল চালু করতে সময় কমিয়ে দেবেন।

মডেলটিকে বিভিন্ন প্রক্রিয়া হিসাবে চালানোর জন্য, আপনি একটি .yml ফাইল তৈরি করতে পারেন যাতে আপনি প্রয়োজনীয় প্রক্রিয়া এবং তাদের ক্রম উল্লেখ করেন।

নীতি 7: পুনর্ব্যবহারযোগ্যতা

আপনার মডেল অ্যাপ্লিকেশনে চলমান প্রক্রিয়াগুলি শুরু করা এবং বন্ধ করা সহজ হওয়া উচিত। এইভাবে, এটি আপনাকে দ্রুত কোড পরিবর্তন, কনফিগারেশন পরিবর্তন, দ্রুত এবং নমনীয়ভাবে স্কেল স্থাপন করতে এবং কার্যকরী সংস্করণের সম্ভাব্য ভাঙ্গন প্রতিরোধ করার অনুমতি দেবে।

অর্থাৎ, মডেলের সাথে আপনার প্রক্রিয়াটি হওয়া উচিত:

• স্টার্টআপের সময় কমিয়ে দিন। আদর্শভাবে, স্টার্টআপের সময় (স্টার্টআপ কমান্ড জারি হওয়ার মুহূর্ত থেকে প্রক্রিয়াটি কার্যকর হওয়ার মুহুর্ত পর্যন্ত) কয়েক সেকেন্ডের বেশি হওয়া উচিত নয়। লাইব্রেরি ক্যাশিং, উপরে বর্ণিত, স্টার্টআপের সময় কমানোর একটি কৌশল।
• সঠিকভাবে শেষ করুন। অর্থাৎ, পরিষেবা পোর্টে শোনা আসলে স্থগিত করা হয়েছে, এবং এই পোর্টে জমা দেওয়া নতুন অনুরোধগুলি প্রক্রিয়া করা হবে না। এখানে আপনাকে হয় DevOps ইঞ্জিনিয়ারদের সাথে ভাল যোগাযোগ স্থাপন করতে হবে, বা এটি কীভাবে কাজ করে তা বুঝতে হবে (অবশ্যই, অবশ্যই, পরবর্তী, তবে যোগাযোগ সর্বদা বজায় রাখা উচিত, যেকোনো প্রকল্পে!)

নীতি 8: ক্রমাগত স্থাপনা/একীকরণ

অনেক কোম্পানি অ্যাপ্লিকেশন ডেভেলপমেন্ট এবং ডিপ্লয়মেন্ট টিমের মধ্যে একটি বিচ্ছেদ ব্যবহার করে (অন্তিম ব্যবহারকারীদের জন্য অ্যাপ্লিকেশনটি উপলব্ধ করা)। এটি সফ্টওয়্যার উন্নয়ন এবং উন্নতিতে অগ্রগতি ব্যাপকভাবে কমিয়ে দিতে পারে। এটি DevOps সংস্কৃতিকেও নষ্ট করে, যেখানে উন্নয়ন এবং একীকরণ মোটামুটিভাবে বলা যায়, একত্রিত।

অতএব, এই নীতিটি বলে যে আপনার উন্নয়ন পরিবেশ আপনার উত্পাদন পরিবেশের যতটা সম্ভব কাছাকাছি হওয়া উচিত।

এটি অনুমতি দেবে:

1. রিলিজের সময় দশগুণ কমিয়ে দিন
2. কোডের অসামঞ্জস্যতার কারণে ত্রুটির সংখ্যা হ্রাস করুন।
3. এটি কর্মীদের উপর কাজের চাপও হ্রাস করে, যেহেতু ডেভেলপার এবং অ্যাপ্লিকেশন স্থাপনকারী লোকেরা এখন এক দল।

যে টুলগুলি আপনাকে এটির সাথে কাজ করার অনুমতি দেয় তা হল CircleCI, Travis CI, GitLab CI এবং অন্যান্য।

আপনি দ্রুত মডেলটিতে সংযোজন করতে পারেন, এটি আপডেট করতে পারেন এবং অবিলম্বে এটি চালু করতে পারেন, যখন ব্যর্থতার ক্ষেত্রে, কার্যকরী সংস্করণে খুব দ্রুত ফিরে আসা সহজ হবে, যাতে শেষ ব্যবহারকারী এটি লক্ষ্য না করে। আপনার ভাল পরীক্ষা থাকলে এটি বিশেষ করে সহজে এবং দ্রুত করা যেতে পারে।

পার্থক্য কমান!!!

নীতি 9. আপনার লগ

লগ (বা "লগস") হল ইভেন্ট, সাধারণত টেক্সট ফরম্যাটে রেকর্ড করা হয়, যা অ্যাপ্লিকেশনের (ইভেন্ট স্ট্রিম) মধ্যে ঘটে। একটি সাধারণ উদাহরণ: "2020-02-02 - সিস্টেম স্তর - প্রক্রিয়ার নাম।" এগুলি ডিজাইন করা হয়েছে যাতে বিকাশকারী আক্ষরিকভাবে দেখতে পারে যে প্রোগ্রামটি চলাকালীন কী ঘটছে। তিনি প্রক্রিয়াগুলির অগ্রগতি দেখেন এবং বুঝতে পারেন যে এটি বিকাশকারী নিজেই উদ্দেশ্য করে কিনা।

এই নীতিটি বলে যে আপনার ফাইল সিস্টেমের মধ্যে আপনার লগগুলি সংরক্ষণ করা উচিত নয় - আপনার কেবল সেগুলিকে স্ক্রিনে "আউটপুট" করা উচিত, উদাহরণস্বরূপ, সিস্টেমের স্ট্যান্ডার্ড আউটপুটে এটি করুন। এবং এইভাবে উন্নয়নের সময় টার্মিনালে প্রবাহ নিরীক্ষণ করা সম্ভব হবে।

এর মানে কি এই যে লগ সংরক্ষণ করার দরকার নেই? অবশ্যই না. আপনার অ্যাপ্লিকেশানে এটি করা উচিত নয়—এটি তৃতীয় পক্ষের পরিষেবাগুলিতে ছেড়ে দিন। আপনার অ্যাপ্লিকেশন শুধুমাত্র একটি নির্দিষ্ট ফাইল বা রিয়েল-টাইম দেখার জন্য টার্মিনালে লগ ফরোয়ার্ড করতে পারে, অথবা এটি একটি সাধারণ উদ্দেশ্য ডেটা স্টোরেজ সিস্টেমে (যেমন Hadoop) ফরোয়ার্ড করতে পারে। আপনার অ্যাপ্লিকেশন নিজেই সঞ্চয় বা লগ সঙ্গে ইন্টারঅ্যাক্ট করা উচিত নয়.

নীতি 10. পরীক্ষা!

ইন্ডাস্ট্রিয়াল মেশিন লার্নিংয়ের জন্য, এই ধাপটি অত্যন্ত গুরুত্বপূর্ণ, যেহেতু আপনাকে বুঝতে হবে যে মডেলটি সঠিকভাবে কাজ করে এবং আপনি যা চান তা তৈরি করে।

পরীক্ষাগুলি pytest ব্যবহার করে তৈরি করা যেতে পারে এবং আপনার যদি রিগ্রেশন/শ্রেণীবিভাগের কাজ থাকে তবে একটি ছোট ডেটাসেট ব্যবহার করে পরীক্ষা করা যেতে পারে।

গভীর শিক্ষার মডেলগুলির জন্য একই বীজ সেট করতে ভুলবেন না যাতে তারা ক্রমাগত ভিন্ন ফলাফল না দেয়।

এটি ছিল 10টি নীতির একটি সংক্ষিপ্ত বিবরণ, এবং অবশ্যই, তারা কীভাবে কাজ করে তা চেষ্টা না করে ব্যবহার করা কঠিন, তাই এই নিবন্ধটি আকর্ষণীয় নিবন্ধগুলির একটি সিরিজের একটি প্রস্তাবনা যেখানে আমি কীভাবে তৈরি করব তা প্রকাশ করব। ইন্ডাস্ট্রিয়াল মেশিন লার্নিং মডেল, কীভাবে সেগুলিকে সিস্টেমে একীভূত করা যায় এবং কীভাবে এই নীতিগুলি আমাদের সকলের জীবনকে সহজ করে তুলতে পারে৷

আমি শান্ত নীতিগুলি ব্যবহার করার চেষ্টা করব যা কেউ চাইলে মন্তব্যে ছেড়ে যেতে পারে।

উত্স: www.habr.com