ఇండస్ట్రియల్ మెషిన్ లెర్నింగ్: 10 డిజైన్ ప్రిన్సిపల్స్

ఇండస్ట్రియల్ మెషిన్ లెర్నింగ్: 10 డిజైన్ ప్రిన్సిపల్స్

ఈ రోజుల్లో, కొత్త సేవలు, అప్లికేషన్‌లు మరియు ఇతర ముఖ్యమైన ప్రోగ్రామ్‌లు ప్రతిరోజూ సృష్టించబడతాయి, ఇవి అద్భుతమైన విషయాలను సృష్టించడం సాధ్యం చేస్తాయి: SpaceX రాకెట్‌ను నియంత్రించే సాఫ్ట్‌వేర్ నుండి స్మార్ట్‌ఫోన్ ద్వారా తదుపరి గదిలోని కెటిల్‌తో పరస్పర చర్య చేయడం వరకు.

మరియు, కొన్నిసార్లు, ప్రతి అనుభవం లేని ప్రోగ్రామర్, అతను ఉద్వేగభరితమైన స్టార్టప్పర్ అయినా లేదా సాధారణ ఫుల్ స్టాక్ లేదా డేటా సైంటిస్ట్ అయినా, జీవితాన్ని చాలా సులభతరం చేసే ప్రోగ్రామింగ్ మరియు సాఫ్ట్‌వేర్‌ను రూపొందించడానికి కొన్ని నియమాలు ఉన్నాయని ముందుగానే లేదా తరువాత గ్రహించవచ్చు.

ఈ ఆర్టికల్‌లో, 10-కారకాల యాప్ మెథడాలజీ ఆధారంగా ఒక అప్లికేషన్/సర్వీస్‌లో సులభంగా కలిసిపోయేలా ఇండస్ట్రియల్ మెషీన్ లెర్నింగ్‌ని ఎలా ప్రోగ్రామ్ చేయాలనే 12 సూత్రాలను నేను క్లుప్తంగా వివరిస్తాను. Heroku బృందం సూచించింది. చాలా మంది డెవలపర్‌లు మరియు డేటా సైన్స్ వ్యక్తులకు సహాయపడే ఈ టెక్నిక్ గురించి అవగాహన పెంచడం నా చొరవ.

ఈ కథనం పారిశ్రామిక మెషిన్ లెర్నింగ్ గురించిన కథనాల శ్రేణికి నాంది. వాటిలో నేను నిజంగా ఒక మోడల్‌ను ఎలా తయారు చేయాలి మరియు దానిని ఉత్పత్తిలోకి ఎలా ప్రారంభించాలి, దాని కోసం APIని ఎలా సృష్టించాలి, అలాగే వివిధ ప్రాంతాలు మరియు వారి సిస్టమ్‌లలో MLని కలిగి ఉన్న కంపెనీల నుండి ఉదాహరణలను గురించి మరింత మాట్లాడతాను.

సూత్రం 1: ఒక కోడ్ బేస్

కొంతమంది ప్రోగ్రామర్లు మొదటి దశలలో, దానిని గుర్తించడానికి సోమరితనం కారణంగా (లేదా వారి స్వంత కారణాల వల్ల), Git గురించి మరచిపోతారు. వారు పదాన్ని పూర్తిగా మరచిపోతారు, అంటే, వారు డ్రైవ్‌లో ఫైల్‌లను ఒకదానికొకటి విసిరివేస్తారు/పావురాల ద్వారా పావురాల ద్వారా పంపుతారు/పావురాల ద్వారా పంపుతారు, లేదా వారు తమ వర్క్‌ఫ్లో గురించి ఆలోచించరు, మరియు ప్రతి ఒక్కటి వారి స్వంత శాఖకు, ఆపై మాస్టర్.

ఈ సూత్రం ఇలా చెబుతోంది: ఒక కోడ్‌బేస్ మరియు అనేక విస్తరణలు ఉన్నాయి.

Git ఉత్పత్తిలో మరియు పరిశోధన మరియు అభివృద్ధి (R&D) రెండింటిలోనూ ఉపయోగించవచ్చు, దీనిలో ఇది తరచుగా ఉపయోగించబడదు.

ఉదాహరణకు, R&D దశలో మీరు విభిన్న డేటా ప్రాసెసింగ్ పద్ధతులు మరియు నమూనాలతో కమిట్‌లను వదిలివేయవచ్చు, ఆపై ఉత్తమమైనదాన్ని ఎంచుకుని, దానితో మరింత సులభంగా పని చేయడం కొనసాగించవచ్చు.

రెండవది, ఉత్పత్తిలో ఇది పూడ్చలేని విషయం - మీరు మీ కోడ్ ఎలా మారుతుందో నిరంతరం చూడవలసి ఉంటుంది మరియు ఏ మోడల్ ఉత్తమ ఫలితాలను అందించింది, చివరికి ఏ కోడ్ పనిచేసింది మరియు దాని పనిని ఆపివేయడానికి లేదా తప్పు ఫలితాలను ఉత్పత్తి చేయడం ప్రారంభించటానికి కారణమేమిటో తెలుసుకోవాలి. . కట్టుబాట్లు అంటే!

మీరు మీ ప్రాజెక్ట్ యొక్క ప్యాకేజీని కూడా సృష్టించవచ్చు, ఉదాహరణకు, Gemfuryలో ఉంచడం ద్వారా, ఆపై ఇతర ప్రాజెక్ట్‌ల కోసం దాని నుండి ఫంక్షన్‌లను దిగుమతి చేసుకోవచ్చు, తద్వారా వాటిని 1000 సార్లు తిరిగి వ్రాయకూడదు, కానీ తర్వాత మరింత.

సూత్రం 2: డిపెండెన్సీలను స్పష్టంగా ప్రకటించండి మరియు వేరు చేయండి

ప్రతి ప్రాజెక్ట్‌లో వేర్వేరు లైబ్రరీలు ఉన్నాయి, వాటిని ఎక్కడైనా వర్తింపజేయడానికి మీరు బయటి నుండి దిగుమతి చేసుకుంటారు. ఇది పైథాన్ లైబ్రరీలు అయినా, లేదా వివిధ ప్రయోజనాల కోసం ఇతర భాషల లైబ్రరీలు అయినా లేదా సిస్టమ్ టూల్స్ అయినా - మీ పని:

• డిపెండెన్సీలను స్పష్టంగా ప్రకటించండి, అంటే మీ ప్రాజెక్ట్‌లో ఉపయోగించిన అన్ని లైబ్రరీలు, సాధనాలు మరియు వాటి వెర్షన్‌లను కలిగి ఉండే ఫైల్ మరియు తప్పనిసరిగా ఇన్‌స్టాల్ చేయబడాలి (ఉదాహరణకు, పైథాన్‌లో ఇది Pipfile లేదా requirements.txtని ఉపయోగించి చేయవచ్చు. A బాగా అర్థం చేసుకోవడానికి అనుమతించే లింక్: realpython.com/pipenv-guide)
• అభివృద్ధి సమయంలో మీ ప్రోగ్రామ్ కోసం ప్రత్యేకంగా డిపెండెన్సీలను వేరు చేయండి. మీరు నిరంతరం సంస్కరణలను మార్చడం మరియు మళ్లీ ఇన్‌స్టాల్ చేయడం ఇష్టం లేదు, ఉదాహరణకు, Tensorflow?

ఈ విధంగా, భవిష్యత్తులో మీ బృందంలో చేరే డెవలపర్‌లు మీ ప్రాజెక్ట్‌లో ఉపయోగించిన లైబ్రరీలు మరియు వాటి వెర్షన్‌లతో త్వరగా పరిచయం చేసుకోగలుగుతారు మరియు నిర్దిష్టమైన వాటి కోసం ఇన్‌స్టాల్ చేయబడిన సంస్కరణలు మరియు లైబ్రరీలను స్వయంగా నిర్వహించుకునే అవకాశం కూడా మీకు ఉంటుంది. ప్రాజెక్ట్, ఇది లైబ్రరీలు లేదా వాటి సంస్కరణల అననుకూలతను నివారించడానికి మీకు సహాయం చేస్తుంది.

మీ అప్లికేషన్ నిర్దిష్ట 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 అప్పుతో మేల్కొన్న కథలను చాలా మంది విన్నారు.

వాస్తవానికి, ఈ కేసులు విపరీతమైనవి, కానీ చాలా ముఖ్యమైనవి. మీరు మీ ఆధారాలను లేదా కాన్ఫిగరేషన్ కోసం అవసరమైన ఇతర డేటాను కోడ్ లోపల నిల్వ చేస్తే, మీరు పొరపాటు చేస్తున్నారు మరియు ఎందుకు వివరించాల్సిన అవసరం లేదని నేను భావిస్తున్నాను.

ఎన్విరాన్మెంట్ వేరియబుల్స్‌లో కాన్ఫిగరేషన్‌లను నిల్వ చేయడం దీనికి ప్రత్యామ్నాయం. మీరు ఎన్విరాన్మెంట్ వేరియబుల్స్ గురించి మరింత చదువుకోవచ్చు ఇక్కడ.

ఎన్విరాన్మెంట్ వేరియబుల్స్‌లో సాధారణంగా నిల్వ చేయబడిన డేటా ఉదాహరణలు:

• డొమైన్ పేర్లు
• API URLలు/URIలు
• పబ్లిక్ మరియు ప్రైవేట్ కీలు
• పరిచయాలు (మెయిల్, ఫోన్లు మొదలైనవి)

ఈ విధంగా మీ కాన్ఫిగరేషన్ వేరియబుల్స్ మారితే మీరు నిరంతరం కోడ్‌ని మార్చాల్సిన అవసరం లేదు. ఇది మీ సమయం, కృషి మరియు డబ్బు ఆదా చేయడంలో సహాయపడుతుంది.

ఉదాహరణకు, మీరు పరీక్షలను నిర్వహించడానికి Kaggle APIని ఉపయోగిస్తే (ఉదాహరణకు, సాఫ్ట్‌వేర్‌ను డౌన్‌లోడ్ చేసి, మోడల్ బాగా పనిచేస్తుందో లేదో పరీక్షించడానికి దాని ద్వారా మోడల్‌ను అమలు చేయండి), అప్పుడు Kaggle నుండి KAGGLE_USERNAME మరియు KAGGLE_KEY వంటి ప్రైవేట్ కీలు ఉండాలి. పర్యావరణ వేరియబుల్స్‌లో నిల్వ చేయబడుతుంది.

సూత్రం 4: మూడవ పక్ష సేవలు

కోడ్ పరంగా స్థానిక మరియు మూడవ పక్ష వనరుల మధ్య తేడా లేని విధంగా ప్రోగ్రామ్‌ను రూపొందించడం ఇక్కడ ఆలోచన. ఉదాహరణకు, మీరు స్థానిక MySQL మరియు మూడవ పక్షం రెండింటినీ కనెక్ట్ చేయవచ్చు. Google Maps లేదా Twitter API వంటి వివిధ APIలకు ఇదే వర్తిస్తుంది.

మూడవ పక్ష సేవను నిలిపివేయడానికి లేదా మరొకదాన్ని కనెక్ట్ చేయడానికి, మీరు పర్యావరణ వేరియబుల్స్‌లోని కాన్ఫిగరేషన్‌లోని కీలను మార్చాలి, నేను పై పేరాలో మాట్లాడాను.

కాబట్టి, ఉదాహరణకు, ప్రతిసారీ కోడ్ లోపల డేటాసెట్‌లతో ఫైల్‌లకు పాత్‌ను పేర్కొనడానికి బదులుగా, పాత్‌లిబ్ లైబ్రరీని ఉపయోగించడం మరియు config.pyలో డేటాసెట్‌లకు పాత్‌ను ప్రకటించడం ఉత్తమం, తద్వారా మీరు ఏ సేవను ఉపయోగిస్తున్నప్పటికీ (కోసం ఉదాహరణకు, CircleCI), ప్రోగ్రామ్ కొత్త సేవలో కొత్త ఫైల్ సిస్టమ్ యొక్క నిర్మాణాన్ని పరిగణనలోకి తీసుకొని డేటాసెట్‌లకు మార్గాన్ని కనుగొనగలిగింది.

సూత్రం 5. బిల్డ్, విడుదల, రన్‌టైమ్

డేటా సైన్స్‌లో చాలా మంది వ్యక్తులు తమ సాఫ్ట్‌వేర్ రైటింగ్ స్కిల్స్‌ను మెరుగుపరచుకోవడానికి ఇది ఉపయోగపడుతుంది. మా ప్రోగ్రామ్ సాధ్యమైనంత అరుదుగా క్రాష్ అవ్వాలని మరియు సాధ్యమైనంత ఎక్కువ కాలం వైఫల్యాలు లేకుండా పని చేయాలని మేము కోరుకుంటే, మేము కొత్త వెర్షన్‌ను విడుదల చేసే ప్రక్రియను 3 దశలుగా విభజించాలి:

1. స్టేజ్ సమావేశాలు. మీరు మీ బేర్ కోడ్‌ను వ్యక్తిగత వనరులతో అవసరమైన మొత్తం కోడ్ మరియు డేటాను కలిగి ఉన్న ప్యాకేజీ అని పిలవబడేలా మార్చారు. ఈ ప్యాకేజీని అసెంబ్లీ అంటారు.
2. స్టేజ్ విడుదల — ఇక్కడ మేము మా కాన్ఫిగరేషన్‌ను అసెంబ్లీకి కనెక్ట్ చేస్తాము, అది లేకుండా మేము మా ప్రోగ్రామ్‌ను విడుదల చేయలేము. ఇప్పుడు ఇది పూర్తిగా విడుదలకు సిద్ధంగా ఉంది.
3. తదుపరి దశ వస్తుంది నెరవేర్చుట. ఇక్కడ మేము మా విడుదల నుండి అవసరమైన ప్రక్రియలను అమలు చేయడం ద్వారా అప్లికేషన్‌ను విడుదల చేస్తాము.

మోడల్ లేదా మొత్తం పైప్‌లైన్ యొక్క కొత్త సంస్కరణలను విడుదల చేయడానికి ఇటువంటి వ్యవస్థ నిర్వాహకులు మరియు డెవలపర్‌ల మధ్య పాత్రలను వేరు చేయడానికి మిమ్మల్ని అనుమతిస్తుంది, సంస్కరణలను ట్రాక్ చేయడానికి మిమ్మల్ని అనుమతిస్తుంది మరియు ప్రోగ్రామ్ యొక్క అవాంఛిత స్టాప్‌లను నిరోధిస్తుంది.

విడుదల టాస్క్ కోసం, మీరు .yml ఫైల్‌లో మీరే అమలు చేయడానికి ప్రక్రియలను వ్రాయగలిగే అనేక విభిన్న సేవలు సృష్టించబడ్డాయి (ఉదాహరణకు, CircleCIలో ఇది ప్రాసెస్‌కు మద్దతు ఇవ్వడానికి config.yml). ప్రాజెక్ట్‌ల కోసం ప్యాకేజీలను రూపొందించడంలో వీలీ గొప్పది.

మీరు మీ మెషీన్ లెర్నింగ్ మోడల్ యొక్క విభిన్న వెర్షన్‌లతో ప్యాకేజీలను సృష్టించవచ్చు, ఆపై వాటిని ప్యాకేజీ చేసి, అక్కడ నుండి మీరు వ్రాసిన ఫంక్షన్‌లను ఉపయోగించడానికి అవసరమైన ప్యాకేజీలు మరియు వాటి వెర్షన్‌లను చూడండి. ఇది మీ మోడల్ కోసం APIని రూపొందించడంలో మీకు సహాయం చేస్తుంది మరియు మీ ప్యాకేజీని Gemfuryలో హోస్ట్ చేయవచ్చు, ఉదాహరణకు.

సూత్రం 6. మీ మోడల్‌ను ఒకటి లేదా అంతకంటే ఎక్కువ ప్రక్రియలుగా అమలు చేయండి

అంతేకాకుండా, ప్రక్రియలు భాగస్వామ్య డేటాను కలిగి ఉండకూడదు. అంటే, ప్రాసెస్‌లు విడివిడిగా ఉండాలి మరియు అన్ని రకాల డేటా విడివిడిగా ఉండాలి, ఉదాహరణకు, MySQL లేదా ఇతరుల వంటి మూడవ పక్ష సేవల్లో, మీకు అవసరమైన దాన్ని బట్టి.

అంటే, ప్రాసెస్ ఫైల్ సిస్టమ్‌లో డేటాను నిల్వ చేయడం ఖచ్చితంగా విలువైనది కాదు, లేకుంటే ఇది తదుపరి విడుదల/కాన్ఫిగరేషన్‌ల మార్పు లేదా ప్రోగ్రామ్ నడుస్తున్న సిస్టమ్ యొక్క బదిలీ సమయంలో ఈ డేటాను క్లియర్ చేయడానికి దారితీయవచ్చు.

కానీ ఒక మినహాయింపు ఉంది: మెషిన్ లెర్నింగ్ ప్రాజెక్ట్‌ల కోసం, మీరు లైబ్రరీల కాష్‌ని నిల్వ చేయవచ్చు, తద్వారా మీరు కొత్త వెర్షన్‌ను ప్రారంభించిన ప్రతిసారీ వాటిని మళ్లీ ఇన్‌స్టాల్ చేయకూడదు, అదనపు లైబ్రరీలు లేదా వాటి వెర్షన్‌లకు ఏవైనా మార్పులు చేయకపోతే. ఈ విధంగా, మీరు పరిశ్రమలో మీ మోడల్‌ను ప్రారంభించేందుకు పట్టే సమయాన్ని తగ్గిస్తారు.

మోడల్‌ను అనేక ప్రక్రియలుగా అమలు చేయడానికి, మీరు .yml ఫైల్‌ను సృష్టించవచ్చు, దీనిలో మీరు అవసరమైన ప్రక్రియలు మరియు వాటి క్రమాన్ని పేర్కొనవచ్చు.

సూత్రం 7: పునర్వినియోగం

మీ మోడల్ అప్లికేషన్‌లో అమలు చేసే ప్రక్రియలు ప్రారంభించడానికి మరియు ఆపడానికి సులభంగా ఉండాలి. అందువల్ల, ఇది కోడ్ మార్పులను, కాన్ఫిగరేషన్ మార్పులను త్వరగా మరియు సరళంగా స్కేల్ చేయడానికి మరియు పని చేసే సంస్కరణ యొక్క సాధ్యం విచ్ఛిన్నాలను నిరోధించడానికి మిమ్మల్ని అనుమతిస్తుంది.

అంటే, మోడల్‌తో మీ ప్రక్రియ ఇలా ఉండాలి:

• ప్రారంభ సమయాన్ని తగ్గించండి. ఆదర్శవంతంగా, ప్రారంభ సమయం (స్టార్టప్ కమాండ్ జారీ చేయబడిన క్షణం నుండి ప్రక్రియ అమలులోకి వచ్చే వరకు) కొన్ని సెకన్ల కంటే ఎక్కువ ఉండకూడదు. పైన వివరించిన లైబ్రరీ కాషింగ్, ప్రారంభ సమయాన్ని తగ్గించడానికి ఒక సాంకేతికత.
• సరిగ్గా ముగించు. అంటే, సర్వీస్ పోర్ట్‌లో వినడం సస్పెండ్ చేయబడింది మరియు ఈ పోర్ట్‌కి సమర్పించిన కొత్త అభ్యర్థనలు ప్రాసెస్ చేయబడవు. ఇక్కడ మీరు DevOps ఇంజనీర్‌లతో మంచి కమ్యూనికేషన్‌ను సెటప్ చేసుకోవాలి లేదా అది ఎలా పని చేస్తుందో మీరే అర్థం చేసుకోవాలి (ప్రాధాన్యంగా, అయితే, రెండోది, కానీ ఏ ప్రాజెక్ట్‌లో అయినా కమ్యూనికేషన్ ఎల్లప్పుడూ నిర్వహించబడాలి!)

సూత్రం 8: నిరంతర విస్తరణ/ఇంటిగ్రేషన్

చాలా కంపెనీలు అప్లికేషన్ డెవలప్‌మెంట్ మరియు డిప్లాయ్‌మెంట్ టీమ్‌ల మధ్య విభజనను ఉపయోగిస్తాయి (అప్లికేషన్‌ను తుది వినియోగదారులకు అందుబాటులో ఉంచడం). ఇది సాఫ్ట్‌వేర్ అభివృద్ధిని బాగా నెమ్మదిస్తుంది మరియు దానిని మెరుగుపరచడంలో పురోగతిని కలిగిస్తుంది. ఇది డెవలప్‌మెంట్ మరియు ఇంటిగ్రేషన్ స్థూలంగా చెప్పాలంటే, కలిపి ఉన్న DevOps సంస్కృతిని కూడా పాడు చేస్తుంది.

కాబట్టి, మీ అభివృద్ధి వాతావరణం మీ ఉత్పత్తి వాతావరణానికి వీలైనంత దగ్గరగా ఉండాలని ఈ సూత్రం పేర్కొంది.

ఇది అనుమతిస్తుంది:

1. విడుదల సమయాన్ని పదుల రెట్లు తగ్గించండి
2. కోడ్ అననుకూలత కారణంగా లోపాల సంఖ్యను తగ్గించండి.
3. ఇది సిబ్బందిపై పనిభారాన్ని కూడా తగ్గిస్తుంది, ఎందుకంటే డెవలపర్‌లు మరియు అప్లికేషన్‌ని అమలు చేసే వ్యక్తులు ఇప్పుడు ఒకే బృందంగా ఉన్నారు.

దీనితో పని చేయడానికి మిమ్మల్ని అనుమతించే సాధనాలు CircleCI, Travis CI, GitLab CI మరియు ఇతరులు.

మీరు మోడల్‌కు త్వరగా జోడింపులు చేయవచ్చు, దాన్ని నవీకరించవచ్చు మరియు వెంటనే ప్రారంభించవచ్చు, అయితే వైఫల్యాల విషయంలో, పని సంస్కరణకు చాలా త్వరగా తిరిగి రావడం సులభం అవుతుంది, తద్వారా తుది వినియోగదారు దానిని కూడా గమనించలేరు. మీరు మంచి పరీక్షలు కలిగి ఉంటే ఇది ప్రత్యేకంగా సులభంగా మరియు త్వరగా చేయవచ్చు.

తేడాలు తగ్గించు!!!

సూత్రం 9. మీ లాగ్‌లు

లాగ్‌లు (లేదా "లాగ్‌లు") ఈవెంట్‌లు, సాధారణంగా టెక్స్ట్ ఫార్మాట్‌లో రికార్డ్ చేయబడతాయి, ఇవి అప్లికేషన్‌లో (ఈవెంట్ స్ట్రీమ్) సంభవిస్తాయి. ఒక సాధారణ ఉదాహరణ: "2020-02-02 - సిస్టమ్ స్థాయి - ప్రాసెస్ పేరు." ప్రోగ్రామ్ నడుస్తున్నప్పుడు ఏమి జరుగుతుందో డెవలపర్ వాచ్యంగా చూడగలిగేలా అవి రూపొందించబడ్డాయి. అతను ప్రక్రియల పురోగతిని చూస్తాడు మరియు అది డెవలపర్ స్వయంగా ఉద్దేశించినట్లుగా ఉందో లేదో అర్థం చేసుకుంటాడు.

మీరు మీ ఫైల్ సిస్టమ్‌లో మీ లాగ్‌లను నిల్వ చేయకూడదని ఈ సూత్రం పేర్కొంది - మీరు వాటిని స్క్రీన్‌కు “అవుట్‌పుట్” చేయాలి, ఉదాహరణకు, సిస్టమ్ యొక్క ప్రామాణిక అవుట్‌పుట్‌లో దీన్ని చేయండి. మరియు ఈ విధంగా అభివృద్ధి సమయంలో టెర్మినల్‌లోని ప్రవాహాన్ని పర్యవేక్షించడం సాధ్యమవుతుంది.

లాగ్‌లను సేవ్ చేయాల్సిన అవసరం లేదని దీని అర్థం? అస్సలు కానే కాదు. మీ అప్లికేషన్ దీన్ని చేయకూడదు-దీనిని మూడవ పక్ష సేవలకు వదిలివేయండి. మీ అప్లికేషన్ నిజ-సమయ వీక్షణ కోసం నిర్దిష్ట ఫైల్ లేదా టెర్మినల్‌కు మాత్రమే లాగ్‌లను ఫార్వార్డ్ చేయగలదు లేదా సాధారణ ప్రయోజన డేటా నిల్వ సిస్టమ్‌కు (హడూప్ వంటివి) ఫార్వార్డ్ చేయగలదు. మీ అప్లికేషన్ లాగ్‌లను నిల్వ చేయకూడదు లేదా వాటితో పరస్పర చర్య చేయకూడదు.

సూత్రం 10. పరీక్ష!

పారిశ్రామిక యంత్ర అభ్యాసం కోసం, ఈ దశ చాలా ముఖ్యమైనది, ఎందుకంటే మోడల్ సరిగ్గా పనిచేస్తుందని మరియు మీరు కోరుకున్నదాన్ని ఉత్పత్తి చేస్తుందని మీరు అర్థం చేసుకోవాలి.

పరీక్షలు పైటెస్ట్‌ని ఉపయోగించి సృష్టించబడతాయి మరియు మీకు రిగ్రెషన్/క్లాస్ఫికేషన్ టాస్క్ ఉంటే చిన్న డేటాసెట్‌ని ఉపయోగించి పరీక్షించవచ్చు.

లోతైన అభ్యాస నమూనాల కోసం ఒకే విత్తనాన్ని సెట్ చేయడం మర్చిపోవద్దు, తద్వారా అవి నిరంతరం విభిన్న ఫలితాలను ఉత్పత్తి చేయవు.

ఇది 10 సూత్రాల యొక్క క్లుప్త వివరణ, మరియు, అవి ఎలా పనిచేస్తాయో చూడకుండా వాటిని ఉపయోగించడం కష్టం, కాబట్టి ఈ కథనం ఆసక్తికరమైన కథనాల శ్రేణికి నాంది, దీనిలో నేను ఎలా సృష్టించాలో వెల్లడిస్తాను. ఇండస్ట్రియల్ మెషీన్ లెర్నింగ్ మోడల్స్ , వాటిని సిస్టమ్‌లలోకి ఎలా సమగ్రపరచాలి మరియు ఈ సూత్రాలు మనందరికీ జీవితాన్ని ఎలా సులభతరం చేస్తాయి.

ఎవరైనా కావాలనుకుంటే వ్యాఖ్యలలో ఉంచగల చక్కని సూత్రాలను కూడా నేను ఉపయోగించడానికి ప్రయత్నిస్తాను.

మూలం: www.habr.com