სამრეწველო მანქანების სწავლა: დიზაინის 10 პრინციპი

სამრეწველო მანქანების სწავლა: დიზაინის 10 პრინციპი

დღესდღეობით, ყოველდღე იქმნება ახალი სერვისები, აპლიკაციები და სხვა მნიშვნელოვანი პროგრამები, რაც შესაძლებელს ხდის წარმოუდგენელი ნივთების შექმნას: SpaceX-ის რაკეტის მართვის პროგრამული უზრუნველყოფიდან დაწყებული სმარტფონის საშუალებით გვერდით ოთახში არსებულ ქვაბთან ინტერაქციამდე.

და, ზოგჯერ, ყოველი დამწყები პროგრამისტი, იქნება ის მგზნებარე სტარტაპერი თუ ჩვეულებრივი Full Stack ან Data Scientist, ადრე თუ გვიან აცნობიერებს, რომ არსებობს გარკვეული წესები პროგრამირებისა და პროგრამული უზრუნველყოფის შესაქმნელად, რომლებიც მნიშვნელოვნად ამარტივებს ცხოვრებას.

ამ სტატიაში მე მოკლედ აღვწერ 10 პრინციპს, თუ როგორ უნდა დაპროგრამოთ სამრეწველო მანქანათმცოდნეობა ისე, რომ ის ადვილად იყოს ინტეგრირებული აპლიკაციაში/სერვისში, 12-ფაქტორიანი აპლიკაციის მეთოდოლოგიის საფუძველზე. შემოთავაზებული ჰეროკუს გუნდის მიერ. ჩემი ინიციატივაა ამ ტექნიკის შესახებ ცნობადობის გაზრდა, რაც შეიძლება დაეხმაროს ბევრ დეველოპერს და მონაცემთა მეცნიერების ადამიანს.

ეს სტატია არის სტატიების სერიის პროლოგი სამრეწველო მანქანათმცოდნეობის შესახებ. მათში მე შემდგომში ვისაუბრებ იმაზე, თუ როგორ შევქმნათ მოდელი რეალურად და გავუშვათ იგი წარმოებაში, შევქმნათ მისთვის API, ასევე მაგალითები სხვადასხვა სფეროებიდან და კომპანიებიდან, რომლებსაც აქვთ ჩაშენებული ML სისტემებში.

პრინციპი 1: ერთი კოდის ბაზა

ზოგიერთი პროგრამისტი პირველ ეტაპზე, ამის გარკვევის სიზარმაცის გამო (ან საკუთარი მიზეზის გამო), ივიწყებს Git-ს. მათ ან სრულიად ავიწყდებათ სიტყვა, ანუ უყრიან ერთმანეთს ფაილებს დისკში/უბრალოდ უყრიან ტექსტს/აგზავნიან მტრედებს, ან არ ფიქრობენ თავიანთ სამუშაო პროცესზე და ავალდებულებენ თითოეულს საკუთარ ფილიალში, შემდეგ კი ოსტატი.

ეს პრინციპი ამბობს: აქვს ერთი კოდის ბაზა და მრავალი განლაგება.

Git შეიძლება გამოყენებულ იქნას როგორც წარმოებაში, ასევე კვლევასა და განვითარებაში (R&D), სადაც ის არც ისე ხშირად გამოიყენება.

მაგალითად, R&D ფაზაში შეგიძლიათ დატოვოთ ვალდებულებები მონაცემთა დამუშავების სხვადასხვა მეთოდით და მოდელებით, რათა შემდეგ შეარჩიოთ საუკეთესო და მარტივად გააგრძელოთ მუშაობა შემდგომში.

მეორეც, წარმოებაში ეს შეუცვლელი რამ არის - თქვენ მუდმივად უნდა უყუროთ როგორ იცვლება თქვენი კოდი და იცოდეთ რომელმა მოდელმა გამოიღო საუკეთესო შედეგი, რომელმა კოდმა იმუშავა ბოლოს და რა მოხდა, რამაც გამოიწვია მისი მუშაობის შეწყვეტა ან არასწორი შედეგების წარმოება. . ამისთვის არის ვალდებულებები!

თქვენ ასევე შეგიძლიათ შექმნათ თქვენი პროექტის პაკეტი, განათავსოთ იგი, მაგალითად, Gemfury-ზე და შემდეგ უბრალოდ შემოიტანოთ ფუნქციები მისგან სხვა პროექტებისთვის, ისე, რომ არ გადაწეროთ ისინი 1000-ჯერ, მაგრამ უფრო მოგვიანებით.

პრინციპი 2: მკაფიოდ გამოაცხადეთ და განასხვავეთ დამოკიდებულებები

თითოეულ პროექტს აქვს სხვადასხვა ბიბლიოთეკა, რომელიც თქვენ შემოიტანეთ გარედან, რათა მათ სადმე გამოიყენოთ. იქნება ეს პითონის ბიბლიოთეკები, ან სხვა ენების ბიბლიოთეკები სხვადასხვა მიზნებისთვის, თუ სისტემის ინსტრუმენტები - თქვენი ამოცანაა:

• ნათლად გამოაცხადეთ დამოკიდებულებები, ანუ ფაილი, რომელიც შეიცავს ყველა ბიბლიოთეკას, ხელსაწყოს და მათ ვერსიებს, რომლებიც გამოიყენება თქვენს პროექტში და რომელიც უნდა იყოს დაინსტალირებული (მაგალითად, Python-ში ეს შეიძლება გაკეთდეს Pipfile-ის ან მოთხოვნების.txt-ის გამოყენებით. ბმული, რომელიც კარგად გაგების საშუალებას იძლევა: realpython.com/pipenv-guide)
• გამოყავით დამოკიდებულებები სპეციალურად თქვენი პროგრამისთვის განვითარების დროს. არ გსურთ მუდმივად შეცვალოთ ვერსიები და ხელახლა დააინსტალიროთ, მაგალითად, 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 URL/URI-ები
• საჯარო და პირადი გასაღებები
• კონტაქტები (ფოსტა, ტელეფონები და ა.შ.)

ამ გზით თქვენ არ გჭირდებათ მუდმივად შეცვალოთ კოდი, თუ თქვენი კონფიგურაციის ცვლადები შეიცვლება. ეს დაგეხმარებათ დაზოგოთ დრო, ძალისხმევა და ფული.

მაგალითად, თუ იყენებთ Kaggle API-ს ტესტების ჩასატარებლად (მაგალითად, ჩამოტვირთეთ პროგრამული უზრუნველყოფა და გაუშვით მოდელი, რათა შეამოწმოთ, რომ მოდელი კარგად მუშაობს), მაშინ Kaggle-ის პირადი გასაღებები, როგორიცაა KAGGLE_USERNAME და KAGGLE_KEY, უნდა იყოს ინახება გარემოს ცვლადებში.

პრინციპი 4: მესამე მხარის მომსახურება

იდეა აქ არის პროგრამის შექმნა ისე, რომ არ იყოს განსხვავება ადგილობრივ და მესამე მხარის რესურსებს შორის კოდის თვალსაზრისით. მაგალითად, შეგიძლიათ დააკავშიროთ როგორც ადგილობრივი MySQL, ასევე მესამე მხარის. იგივე ეხება სხვადასხვა API-ებს, როგორიცაა Google Maps ან Twitter API.

იმისათვის, რომ გამორთოთ მესამე მხარის სერვისი ან დააკავშიროთ სხვა, თქვენ უბრალოდ უნდა შეცვალოთ გასაღებები კონფიგურაციის გარემოს ცვლადებში, რაზეც მე ვისაუბრე ზემოთ აბზაცში.

ასე რომ, მაგალითად, იმის ნაცვლად, რომ ყოველ ჯერზე კოდის შიგნით მონაცემთა ნაკრების მქონე ფაილებისკენ მიმავალი გზა მიუთითოთ, უმჯობესია გამოიყენოთ pathlib ბიბლიოთეკა და გამოაცხადოთ გზა მონაცემთა ნაკრებისკენ config.py-ში, ისე, რომ არ აქვს მნიშვნელობა რა სერვისს იყენებთ ( მაგალითად, CircleCI), პროგრამამ შეძლო გაერკვია მონაცემთა ნაკრების გზა ახალი სერვისის ახალი ფაილური სისტემის სტრუქტურის გათვალისწინებით.

პრინციპი 5. აშენება, გამოშვება, გაშვება

მონაცემთა მეცნიერებაში ბევრი ადამიანი მიიჩნევს, რომ სასარგებლოა პროგრამული უზრუნველყოფის წერის უნარების გაუმჯობესება. თუ გვინდა, რომ ჩვენი პროგრამა რაც შეიძლება იშვიათად ავარიდეს და რაც შეიძლება დიდხანს იმუშაოს წარუმატებლობის გარეშე, ახალი ვერსიის გამოშვების პროცესი უნდა დავყოთ 3 ეტაპად:

1. ეტაპი შეკრებები. თქვენ გარდაქმნით თქვენს შიშველ კოდს ინდივიდუალური რესურსებით ეგრეთ წოდებულ პაკეტად, რომელიც შეიცავს ყველა საჭირო კოდს და მონაცემს. ამ პაკეტს ასამბლეა ჰქვია.
2. ეტაპი გაათავისუფლა — აქ ჩვენ ვაკავშირებთ ჩვენს კონფიგურაციას ასამბლეასთან, რომლის გარეშეც ვერ შევძლებთ ჩვენი პროგრამის გამოშვებას. ახლა ეს არის სრულიად მზა გამოშვება.
3. შემდეგი მოდის სცენა შესრულება. აქ ჩვენ ვათავისუფლებთ აპლიკაციას ჩვენი გამოშვებიდან საჭირო პროცესების გაშვებით.

მოდელის ან მთელი მილსადენის ახალი ვერსიების გამოშვების ასეთი სისტემა საშუალებას გაძლევთ განასხვავოთ როლები ადმინისტრატორებსა და დეველოპერებს შორის, საშუალებას გაძლევთ თვალყური ადევნოთ ვერსიებს და თავიდან აიცილოთ პროგრამის არასასურველი გაჩერებები.

გამოშვების ამოცანისთვის შეიქმნა მრავალი განსხვავებული სერვისი, რომლებშიც თქვენ შეგიძლიათ ჩაწეროთ პროცესები, რათა თავად გაუშვათ .yml ფაილში (მაგალითად, CircleCI-ში ეს არის config.yml თავად პროცესის მხარდასაჭერად). Wheely შესანიშნავია პროექტებისთვის პაკეტების შესაქმნელად.

თქვენ შეგიძლიათ შექმნათ პაკეტები თქვენი მანქანათმცოდნეობის მოდელის სხვადასხვა ვერსიით, შემდეგ შეფუთოთ ისინი და მიმართოთ საჭირო პაკეტებსა და მათ ვერსიებს, რომ გამოიყენოთ იქიდან დაწერილი ფუნქციები. ეს დაგეხმარებათ შექმნათ API თქვენი მოდელისთვის და თქვენი პაკეტი შეიძლება განთავსდეს Gemfury-ზე, მაგალითად.

პრინციპი 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