ბიბლიოთეკა
00/07 · ~34 წთ
GUIDEDECK · მოდელების გაშვება, არა მხოლოდ წვრთნა

MLOps & გზა
notebook-იდან პროდაქშენამდე.

34-წუთიანი სამუშაო სესია იმაზე, თუ რა ხდება მას შემდეგ, რაც მოდელი notebook-ში მუშაობს — პაიპლაინები, ექსპერიმენტების ტრეკინგი, სერვინგი, ნიშნების საცავები, დრიფტზე მონიტორინგი და ინსტრუმენტები, რომლებიც ამ ყველაფერს ერთად კრავს. MLOps სინამდვილეში არის CI/CD პლუს მონაცემებისა და მოდელის მონიტორინგი.

~34 წთდამწყები → საშუალოყველა ინსტრუმენტზე
გადაახვიეთ
01 · რატომ MLOps 4 წთ

მოდელი, რომელიც notebook-ში მუშაობს,
სამუშაოს დაახლოებით 10%-ია.

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

MLOps — Machine Learning Operations — არის პრაქტიკების ერთობლიობა, რომლითაც ML მოდელები პროდაქშენში გადის და იქ ჯანსაღი რჩება. წარმოიდგინეთ როგორც DevOps ML-ისთვის: იგივე CI/CD, ვერსირება და ავტომატიზაციის დისციპლინა, რომელიც დეველოპერული ინსტრუმენტებიდან იცნობთ, პლუს ორი რამ, რისი თვალყურის დევნებაც მარტო პროგრამულ უზრუნველყოფას არასდროს სჭირდებოდა — მონაცემებისა და მოდელის ხარისხი დროთა განმავლობაში.

რატომ ტყდება ML კოდისგან განსხვავებულად

  • კოდს აქვს ლოგიკა; ML-ს აქვს ლოგიკა + მონაცემები + წონები. სამი მოძრავი ნაწილი და თითოეულს შეუძლია შედეგის შეცვლა.
  • ის ჩუმად ფუჭდება. გატეხილი API 500-ს აბრუნებს. მოძველებული მოდელი კი კვირების განმავლობაში უბრალოდ ოდნავ უარეს პროგნოზებს გასცემს — შეცდომის გარეშე, მხოლოდ დაკარგული ფულით.
  • სამყარო იცვლება. კოდი ხვალაც ისევე მოიქცევა; შარშანდელ მონაცემებზე გაწვრთნილი მოდელი კი ნელ-ნელა წყვეტს რეალობასთან შესაბამისობას.
  • რეპროდუცირებადობა რთულია. „ჩემთან მუშაობდა, როცა გავუშვი“ მოითხოვს ზუსტად იმავე მონაცემებს, კოდს, პარამეტრებს და გარემოს.

MLOps არის ხიდი ამ ნაპრალზე — მოსაწყენი სამზარეულო, რომელიც ერთჯერად შედეგს საიმედო სერვისად აქცევს.

~90%

რეალურ ML პროდუქტში ძალისხმევისა მოდის ყველაფერზე, გარდა მოდელის კოდისა.

3×

რამ იცვლება — კოდი, მონაცემები და ნასწავლი წონები — ანუ სამი რამ, რომელსაც ვერსია სჭირდება.

0

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

02 · ML-ის ციკლი და პაიპლაინები 5 წთ

ML არის ციკლი,
და არა ცალმხრივი გზა.

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

ML პაიპლაინი — ნაბიჯების ავტომატიზებული, დალაგებული თანმიმდევრობა, რომელიც ნედლ მონაცემებს დადეპლოებულ მოდელად აქცევს: მონაცემების მიღება & ვალიდაცია → ნიშნების აგება → წვრთნა → შეფასება → დეპლოი → მონიტორინგი. თითოეული ნაბიჯი კოდია, ვერსიის კონტროლში და ხელახლა გასაშვები, ასე რომ მთელი ეს რამ შეიძლება გაეშვას განრიგით ან ტრიგერით, ისე რომ არავინ დაუდგეს notebook-ს თავზე.

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

notebook-ის უჯრებიდან პაიპლაინამდე

  • თითოეული ნაბიჯი ფუნქციაა ტიპიზებული შესასვლელებითა და გამოსასვლელებით — და არა უჯრა, რომელიც notebook-ის ფარულ მდგომარეობაზეა დამოკიდებული.
  • ნაბიჯები ქეშირდება და გაგრძელებადია. თუ წვრთნა ჩავარდა, ხელახალი გაშვება გამოტოვებს მონაცემების ნაბიჯს, რომელიც უკვე წარმატებით დასრულდა.
  • ორკესტრატორი უშვებს DAG-ს — Airflow, Kubeflow Pipelines, Dagster, Prefect ან Metaflow თქვენს ნაცვლად გეგმავს ნაბიჯებს და ხელახლა ცდის მათ.
// a pipeline = small, ordered, re-runnable steps
const ingest   = step((): DataFrame => { /* ... */ });
const train    = step((df: DataFrame): Model => { /* ... */ });
const evaluate = step((m: Model): Metrics => { /* ... */ });

// the orchestrator runs the DAG on a schedule
const pipeline = sequence(ingest, train, evaluate, deploy);

იგივე ლოგიკა, რაც notebook-ში — ოღონდ ერთმანეთთან დაკავშირებული, სატესტო ნაბიჯების სახით, რომლებსაც ორკესტრატორი ზედამხედველობის გარეშე უშვებს.

03 · ექსპერიმენტების ტრეკინგი და მოდელების რეესტრი 5 წთ

თუ ვერ გაიმეორებთ,
მაშინ ის სინამდვილეში არ გაქვთ.

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

ექსპერიმენტების ტრეკინგი — წვრთნის ყოველი გაშვების შესასვლელებისა და შედეგების ლოგირება (პარამეტრები, კოდის ვერსია, მონაცემთა ნაკრების ვერსია, მეტრიკები და მიღებული მოდელის არტეფაქტი), რათა ნებისმიერი შედეგი შესადარებელი და გამეორებადი იყოს. მოდელების რეესტრი შემდეგი ნაბიჯია: იმ მოდელების ვერსირებული კატალოგი, რომლებსაც რეალურად აწინაურებთ — თითოეული სტადიით, როგორიცაა Staging ან Production, და გამჭვირვალე კვალით იმ გაშვებამდე, რომელმაც ის შექმნა.
import mlflow with mlflow.start_run(): mlflow.log_param("max_depth", 8) model = train(X_train, y_train) mlflow.log_metric("auc", 0.91) mlflow.sklearn.log_model(model, "model") # run is now reproducible: params + data + artifact

აღრიცხეთ ყოველი გაშვება; რეესტრში დააწინაურეთ მხოლოდ გამარჯვებული — ვერსიითა და სტადიით.

ვერსირება

სამი რამ, და არა ერთი

რეპროდუცირებადობას სჭირდება კოდი (git), მონაცემები (სნეპშოტი ან ჰეში, მაგალითად DVC-ით ან ცხრილის ვერსიით) და მოდელი + პარამეტრები (აღრიცხული გაშვება). ერთი გამოგრჩეთ და „გუშინ ხომ მუშაობდა“ დაბრუნდება.

წარმოშობა

უპასუხეთ: „საიდან გაჩნდა ეს?“

დარეგისტრირებული მოდელი უკან თავის გაშვებაზე მიუთითებს, ის კი — კოდის კომიტსა და მონაცემთა ნაკრების ვერსიაზე. როცა პროგნოზი ეჭვქვეშ დგება, შეგიძლიათ მთელი ჯაჭვი აღადგინოთ.

ხელსაწყო

რას იყენებენ პრაქტიკაში

MLflow (ღია კოდის, ჩვეული არჩევანი), Weights & Biases, Neptune და Comet ტრეკინგისთვის; MLflow, SageMaker და Vertex AI — სამივე რეესტრსაც გთავაზობთ.

04 · მოდელების სერვინგი 5 წთ

გაწვრთნილი მოდელი უსარგებლოა,
სანამ მოთხოვნებს ვერ პასუხობს.

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

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

პარტიული — შეფასება წინასწარ, ამოღება მოგვიანებით

# ეშვება ღამით; შეყოვნებას მნიშვნელობა არ აქვს df = read_table("users") df["score"] = model.predict(df[FEATURES]) write_table("user_scores", df) # აპლიკაცია უბრალოდ წინასწარ გამოთვლილ სტრიქონს ამოიღებს
როდის გამოვიყენოთ
პროგნოზები შეიძლება რამდენიმე საათის ძველი იყოს — churn-ქულები, დღიური რეკომენდაციები, ლიდების რანჟირება, მოთხოვნის პროგნოზები.
მოგება
მარტივი, იაფი, მაღალი გამტარუნარიანობა. მუდმივად ჩართული სერვისი არ სჭირდება; იყენებთ თქვენსავე მონაცემთა საწყობსა და გეგმიურ გამშვებს.
ფასი
გაშვებებს შორის პროგნოზები ძველდება და სულ ახალ ობიექტებს ვერ შეაფასებთ შემდეგ ჯერამდე.

ონლაინი — ერთი ცოცხალი მოთხოვნის პასუხი მილიწამებში

app.post("/predict", (req, res) => {
  const x = featurize(req.body);      // MUST match training
  const score = model.predict(x);     // warm, in-memory
  res.json({ score: Number(score) });
  // target: p99 < 50ms · autoscale on RPS
});
როდის გამოვიყენოთ
პროგნოზმა უნდა ასახოს ცოცხალი მოთხოვნა — თაღლითობის შემოწმება, ძიების რანჟირება, ფასწარმოქმნა, რეკომენდაციები გვერდზე.
მოგება
ახალი, თითო მოთხოვნაზე მორგებული პასუხები. მასშტაბირდება ჰორიზონტალურად, დატვირთვის ბალანსერის უკან.
ფასი
მუდმივად ჩართული ინფრასტრუქტურა, კუდის შეყოვნება (p99), რომელსაც უნდა დაედევნოთ, და მოდელი უნდა იყოს ჩატვირთული და გამზადებული.

სტრიმინგი — პროგნოზები მოვლენების ნაკადზე

შუალედური ვარიანტი: მოდელი კითხულობს მოვლენების ნაკადს (Kafka, Kinesis, Pub/Sub) და პროგნოზებს გასცემს მაშინვე, როგორც კი მოვლენა შემოვა — გამოიყენება, მაგალითად, რეალურ დროში ანომალიების აღმოსაჩენად ან კლიკების ნაკადის გასამდიდრებლად. ეს იგივე ონლაინ ინფერენსია, ოღონდ სინქრონული HTTP გამოძახებების ნაცვლად მოვლენებით მართული.

  • თითქმის რეალურ დროში, მაგრამ გამიჯნულად — პროდიუსერი პროგნოზს არ ელოდება.
  • შესანიშნავია, როცა ბევრ მოვლენას სჭირდება უწყვეტი შეფასება და რამდენიმე ასეული მილიწამი ჩამორჩენა მისაღებია.

პარტიული რეჟიმი შეყოვნებას წინასწარი გამოთვლით მალავს; ონლაინი კი შეყოვნებას თითო მოთხოვნაზე იხდის, რომ პასუხი ახალი იყოს.

სერვინგის ინფრასტრუქტურა & შეყოვნების ბერკეტები

  • სად ეშვება: გამოყოფილი სერვერები, როგორიცაა NVIDIA Triton, TensorFlow Serving, TorchServe, BentoML ან KServe/Seldon Kubernetes-ზე, ავტომასშტაბირებისა და გამოშვებებისთვის.
  • შეყოვნება შეამცირეთ მოთხოვნების პარტიებად დაჯგუფებით, ქეშირებით, მოდელის კვანტიზაციით ან დისტილაციით და დიდი მოდელებისთვის GPU-ებით.
  • უსაფრთხოდ გამოუშვით canary ან shadow დეპლოებით — ტრაფიკის ნაწილი ახალ მოდელს მიაწოდეთ სრულ გადართვამდე.
  • დიდი ენობრივი მოდელები ამ მხრივ შეყოვნების ყველაზე მძიმე უკიდურესობაა — იხილეთ LLM Evals & LLMOps.
05 · ნიშნების საცავი და წვრთნა/სერვინგის გადახრა 5 წთ

ბაგი, რომელიც ოფლაინში მშვენიერ ქულას იღებს
და პროდაქშენში ჩავარდება.

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

ნიშნების საცავი — ცენტრალური სისტემა ნიშნების აღწერის, გამოთვლისა და მიწოდებისთვის, ორი სინქრონიზებული ნახევრით: ოფლაინ საცავი (დიდი ისტორია, საწვრთნელი ნაკრებების ასაგებად) და ონლაინ საცავი (მცირე შეყოვნების ამოღებები სერვინგისთვის). ორივეს კვებავს ერთი და იგივე ნიშნის აღწერა, ასე რომ რიცხვი, რომელზეც მოდელი იწვრთნება, იმავენაირად გამოითვლება, როგორც ის, რომელსაც პროდაქშენში ხედავს.
გადახრა — ორი კოდის გზა
# training (Python, batch over history) avg = df.groupby("user").spend.mean() # serving (different code, different window!) avg = sum(last_30_txns) / 30 # subtly different → model sees inputs it never trained on
ნიშნების საცავი — ერთი აღწერა
# define the feature ONCE @feature_view(source=transactions) def avg_spend_7d(df): return df.rolling("7d").mean() # training reads OFFLINE store · serving reads ONLINE # same logic, both sides → no skew

„საშუალო ხარჯის“ ორი იმპლემენტაცია ერთმანეთს სცილდება — მოდელი უარესდება და ვერცერთი ტესტი ვერ იჭერს.

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

ნიშნების საცავი წვრთნასა და სერვინგს შორის საერთო ხერხემალია.

ნამდვილად გჭირდებათ?

  • გულახდილად: ადრეულ პროექტებს უმეტესად არა. ნიშნების საცავი რეალურ საოპერაციო წონას ნიშნავს. ერთ პარტიულ მოდელს ერთი კოდის გზით თავიდან ასაცილებელი გადახრა უბრალოდ არ აქვს.
  • ის თავს იმართლებს, როცა ბევრი მოდელი ან გუნდი ერთსა და იმავე ნიშნებს იყენებს, ან როცა ონლაინ სერვინგი გაქვთ და უნდა გარანტირებულად ემთხვეოდეს ოფლაინ და ონლაინ რიცხვები.
  • ინსტრუმენტები: Feast (ღია კოდის), Tecton (კომერციული) და მართული ნიშნების საცავები SageMaker-ში, Vertex AI-სა და Databricks-ში.
  • ყურადღება მიაქციეთ დროში სისწორესაც: საწვრთნელი ნაკრები მხოლოდ იმ მონაცემებს უნდა იყენებდეს, რომლებიც პროგნოზის მომენტში არსებობდა — თორემ მომავალს გააჟონინებთ და სიზუსტეს გადაჭარბებულად შეაფასებთ.
06 · მონიტორინგი პროდაქშენში 5 წთ

მოდელები არ ეცემა —
ისინი ჩუმად ლპება.

მოდელი, რომელიც გაშვებისას 91%-იან სიზუსტეს იძლეოდა, სამუდამოდ 91%-იანი არ დარჩება. სამყარო, რომლისგანაც ისწავლა, მუდმივად იცვლება. პროდაქშენის მონიტორინგი სწორედ ისაა, რითაც ამ დაძველებას თქვენს მომხმარებლებზე (ან თქვენს შემოსავალზე) ადრე იჭერთ. ის პირდაპირ ეყრდნობა კლასიკურ დაკვირვებადობასა & მონიტორინგს — იგივე დაშბორდები და გაფრთხილებები, პლუს ორი ML-სპეციფიკური სიგნალი.

დრიფტი — ცოცხალი სამყაროს დაშორება საწვრთნელი მონაცემებისგან. მონაცემთა დრიფტი (covariate shift) არის შესასვლელების ცვლილება — მომხმარებელთა ახალი სეგმენტი, გადარქმეული კატეგორია. კონცეფციის დრიფტი არის კავშირის ცვლილება შესასვლელებსა და სამიზნეს შორის — ის, რაც შარშან ტრანზაქციას „თაღლითობად“ აქცევდა, უკვე აღარ მოქმედებს. ორივე ჩუმად ღრღნის სიზუსტეს.
1
საოპერაციო მეტრიკები — სერვისი ჯანსაღია?
შეყოვნება, გამტარუნარიანობა, შეცდომები — ისევე, როგორც ნებისმიერ API-ში.
+

პირველი შრე ჩვეულებრივი სერვისის მონიტორინგია: მოთხოვნების სიხშირე, p99 შეყოვნება, შეცდომების წილი, CPU/GPU და მეხსიერება. მოდელი, რომელიც ტაიმაუტში ვარდება, გატეხილია მისი სიზუსტის მიუხედავად. ეს ზუსტად ის დაკვირვებადობაა, რომელსაც ნებისმიერ სერვისს დაადებდით.

2
მონაცემების ხარისხი და დრიფტი — შესასვლელები საღია?
სქემები, დიაპაზონები და შესასვლელების მცოცავი განაწილებები.
+

ჯერ დააკვირდით შემომავალ ნიშნებს — გატეხილი სქემები, null-ები და დიაპაზონს გარეთ დარჩენილი მნიშვნელობები: გადარქმეული სვეტი, რომელიც ჩუმად ნულებს კვებავს, ნამდვილ დრიფტზე ხშირია. შემდეგ თვალი ადევნეთ შესასვლელების განაწილებას საწვრთნელ ეტალონთან შედარებით. სტანდარტული საზომებია Population Stability Index (PSI), Kolmogorov–Smirnov ტესტი და KL / Jensen–Shannon დივერგენცია.

// Population Stability Index per feature
const psi = populationStabilityIndex({ ref: trainDist, cur: liveDist });
if (psi > 0.2) {    // 0.1–0.2 minor · >0.2 major shift
  alert("data drift");
  triggerRetrain();
}
3
მოდელის ხარისხი და კონცეფციის დრიფტი — პროგნოზები ისევ კარგია?
ნამდვილი მიზანი — ოღონდ ლეიბლები გვიან მოდის.
+

სინამდვილეში გაინტერესებთ სიზუსტე ცოცხალ მონაცემებზე. ხრიკი ისაა, რომ ჭეშმარიტი ლეიბლები გვიან მოდის (გავიდა თუ არა სესხი დეფოლტში? წავიდა თუ არა მომხმარებელი?), ამიტომ ხარისხს ხშირად მაშინვე ვერ შეაფასებთ. სანამ ლეიბლები მოვა, დააკვირდით ირიბ სიგნალებს — თავად პროგნოზების განაწილებას, ნდობის ქულებს და ბიზნეს-KPI-ებს — შემდეგ კი, ლეიბლების მოსვლისთანავე, გამოთვალეთ ნამდვილი მეტრიკები.

4
გადაწვრთნის ტრიგერები — როდის განვაახლოთ მოდელი
განრიგით, შედეგებზე დაყრდნობით ან დრიფტზე დაყრდნობით.
+

სამი გზა იმის გადასაწყვეტად, რომ გადაწვრთნის დროა: განრიგით (მაგალითად, ყოველკვირეულად — მარტივი და პროგნოზირებადი), შედეგებზე დაყრდნობით (მეტრიკა ზღვარს ქვემოთ ეცემა — იდეალურია, მაგრამ დროულ ლეიბლებს საჭიროებს) და დრიფტზე დაყრდნობით (PSI/KS ლიმიტს კვეთს — სასარგებლო ადრეული გაფრთხილება). გუნდების უმეტესობა განრიგით იწყებს და გამოცდილებასთან ერთად ამატებს დრიფტის ტრიგერებს. რომელიც არ უნდა ამუშავდეს, მან იგივე ავტომატიზებული პაიპლაინი უნდა გაუშვას, რაზეც მე-2 ნაწილში იყო საუბარი.

training live (drifted) distribution has shifted → PSI > 0.2

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

რას უშვებენ გუნდები რეალურად

  • ოპერაციული შრე: Prometheus + Grafana, ან თქვენი ღრუბლის APM — პირდაპირ გადმოტანილი დაკვირვებადობიდან.
  • ML შრე: Evidently (ღია კოდის), NannyML, WhyLabs, Arize ან Fiddler დრიფტისა და ხარისხის ანგარიშებისთვის; SageMaker Model Monitor და Vertex AI Model Monitoring მართული ვარიანტებია.
  • ოქროს წესი: დაალოგეთ ყოველი პროგნოზი მისი შესასვლელებითა და მოთხოვნის id-ით, რომ მოგვიანებით რეალური შედეგი მიაერთოთ და ნამდვილი სიზუსტე გამოთვალოთ.
07 · ინსტრუმენტები, CI/CD და შეჯამება 5 წთ

ლანდშაფტი და ის ერთი იდეა,
რომელიც ყველაფრის ქვეშ დევს.

ინსტრუმენტების სია გრძელია, მაგრამ ისინი იმ ციკლში ჯდება, რომელიც უკვე იცით. ქვემოთ: როგორ ედრება ერთმანეთს ოთხი დიდი პლატფორმა და შემდეგ გამაერთიანებელი ჩარჩო — MLOps = CI/CD + მონაცემებისა და მოდელის მონიტორინგი.

CI/CD ML-ისთვის აფართოებს იმ პაიპლაინს, რომელიც დეველოპერული ინსტრუმენტებიდან იცით. CI ტესტავს კოდს და მონაცემებს, შემდეგ წვრთნის და აფასებს კანდიდატს. CD მას მხოლოდ მაშინ აწინაურებს, თუ ის გამოტოვებულ ნაკრებზე მოქმედ პროდაქშენ-მოდელს სჯობს — ამას ზოგჯერ უწყვეტ წვრთნას (CT) უწოდებენ. მოდელი ბილდის არტეფაქტია, რომელმაც ხარისხის ზღვარი უნდა გაიაროს, ისევე როგორც ნებისმიერმა რელიზმა.
on: [push] jobs: train-and-gate: steps: - run: pytest tests/ # code + data checks - run: dvc repro # reproduce pipeline - run: python evaluate.py # gate vs production - run: mlflow register # promote if it wins

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

ინსტრუმენტების ლანდშაფტი — როგორ ავირჩიოთ

MLflow

მსუბუქი ნაგულისხმევი

ღია კოდის ტრეკინგი, მოდელების რეესტრი და შეფუთვა — ფრეიმვორკისა და ღრუბლისგან დამოუკიდებელი.

  • დადებითი — ადვილად ასათვისებელია, ყველგან მუშაობს, მიბმის გარეშე; ექსპერიმენტებისა და რეესტრის ბირთვში შესანიშნავია.
  • უარყოფითი — არც ორკესტრატორია და არც სერვინგის პლატფორმა; პაიპლაინები და ინფრასტრუქტურა თქვენი მოსატანია.
  • აირჩიეთ, როცა  გინდათ ტრეკინგი + რეესტრი კონკრეტულ ღრუბელზე გადაწყვეტის გარეშე.
Kubeflow

Kubernetes-native პლატფორმა

ღია კოდის პაიპლაინები, წვრთნის ოპერატორები და სერვინგი (KServe), რომლებიც თქვენსავე Kubernetes კლასტერზე მუშაობს.

  • დადებითი — პორტატულია, ბოლოდან ბოლომდე ორკესტრაცია; ვენდორზე მიბმის გარეშე, თუ უკვე K8s-ზე ხართ.
  • უარყოფითი — მძიმეა საოპერაციოდ; კლასტერი, განახლებები და სირთულე თქვენს მხრებზეა.
  • აირჩიეთ, როცა  გყავთ პლატფორმის გუნდი და გინდათ ღრუბლისგან დამოუკიდებელი პაიპლაინები.
Amazon SageMaker

მართული, ბოლოდან ბოლომდე AWS-ზე

წვრთნა, ჰოსტირებული ენდპოინტები, პაიპლაინები, ნიშნების საცავი, რეესტრი და მოდელის მონიტორი — ყველა მართული სერვისი.

  • დადებითი — ფარავს მთელ სასიცოცხლო ციკლს; მინიმალური ინფრასტრუქტურა თქვენს მხარეს; ღრმა ინტეგრაცია AWS-თან.
  • უარყოფითი — AWS-ზე მიბმა და ღირებულება; ბევრი შესასწავლი ზედაპირი.
  • აირჩიეთ, როცა  AWS-ზე უკვე გადაწყვეტილი ხართ და აწყობილს მართული გირჩევნიათ.
Google Vertex AI

მართული, ბოლოდან ბოლომდე GCP-ზე

GCP-ის ანალოგი — პაიპლაინები (Kubeflow Pipelines-ზე აგებული), პროგნოზირება, ნიშნების საცავი, რეესტრი და მოდელის მონიტორინგი; მჭიდრო ინტეგრაცია BigQuery-სთან.

  • დადებითი — მთელი სასიცოცხლო ციკლი მართულია; ძლიერი კავშირი მონაცემებთან და ანალიტიკასთან; KFP პაიპლაინები საკმაოდ პორტატულია.
  • უარყოფითი — GCP-ზე მიბმა და ღირებულება.
  • აირჩიეთ, როცა  თქვენი მონაცემები GCP/BigQuery-შია და მართული გინდათ.

გადაწყვეტილება უფრო მარტივია, ვიდრე მატრიცა გვაფიქრებინებს

  • დაიწყეთ მცირედით. განრიგზე გაშვებული პარტიული ჯობი + MLflow + cron ტრიგერი გასაკვირად ბევრ რეალურ პრობლემას წყვეტს. ერთი მოდელისთვის პლატფორმა ნუ იყიდეთ.
  • მიჰყევით მონაცემების მიზიდულობას. თუ ყველაფერი AWS-შია — SageMaker; თუ GCP-ში — Vertex AI. საკუთარ ღრუბელთან ბრძოლა იშვიათად ამართლებს.
  • Kubeflow-ს ხელი მაშინ მოჰკიდეთ, როცა გყავთ პლატფორმის გუნდი და გაქვთ multi-cloud ან on-prem მოთხოვნა, რომელიც მის მართვას ამართლებს.
  • მისი მოწიფული LLM-ბიძაშვილი — შეფასებები, პრომპტების ვერსირება, დამცავი ზღუდეები — LLM Evals & LLMOps-შია.

ხუთი წესი, რომელიც თან უნდა წაიღოთ

1მოდელი სამუშაოს 10%-ია. MLOps დანარჩენი 90%-ია — პაიპლაინები, სერვინგი და მონიტორინგი.
2ავერსირეთ კოდი, მონაცემები და მოდელი, რომ ყოველი შედეგი გამეორებადი და თვალმისადევნებელი იყოს.
3პარტიული თუ ონლაინი — აირჩიეთ გააზრებულად: ეს განსაზღვრავს თქვენს შეყოვნებას, ღირებულებასა და ინფრასტრუქტურას.
4მოკალით წვრთნა/სერვინგის გადახრა ორივე მხარისთვის ნიშნის ერთი აღწერით.
5აკონტროლეთ დრიფტი და გადაწვრთენით — მოდელები ჩუმად ლპება, ამიტომ ეს ციკლი არასდროს იხურება.
ცოდნის შემოწმება

დაგამახსოვრდათ?

ხუთი სწრაფი კითხვა ML-ის სასიცოცხლო ციკლზე, სერვინგზე, გადახრაზე, დრიფტსა და ინსტრუმენტებზე — მყისიერი უკუკავშირი, ავტორიზაციის გარეშე.

შეაფასეთ ეს დასტა
იყავით პირველი

ნავიგაცია ← → ღილაკებით ან სქროლით · უკან ბიბლიოთეკაში