Mga nadagdag:
- Kakayahang kilalanin ang mga espesyal na hamon ng ML na may kaugnayan sa code-data-model trio at package at ipakita ang modelo online o sa batch ayon sa pangangailangan ng negosyo.
- Kakayahang magpatupad ng unti-unti at rollback na mga pattern ng deployment (shadow, canary, A/B, rollback) at magdagdag ng nasubok na rollback plan sa bawat deployment
- Kakayahang panatilihing masusubaybayan ang data-code-metric na link ng modelo sa produksyon gamit ang evaluation threshold-controlled na CI/CD at model registry
Ang pagkuha ng isang modelo upang makamit ang 95% katumpakan sa notebook ay kalahati lamang ng kuwento. Ang kalahati pa—kadalasan ang mahirap—ay ang pagkuha ng modelong iyon sa mga tunay na user sa isang maaasahan, nasusukat, at napapanatiling paraan. Pinagsasama ng MLOps (Machine Learning Operations: ang disiplina ng paglalagay, pagpapatakbo, at pagpapanatili ng mga modelo ng ML sa produksyon) ang mga kasanayan sa DevOps ng software engineering sa mga natatanging hamon ng ML. Sa unit na ito, sinasaklaw namin ang mga hakbang ng paglipat ng modelo sa produksyon at kung paano nakakatulong ang artificial intelligence sa prosesong ito.
Bakit iba ang ML sa regular na software?
Sa ordinaryong software, ang pag-uugali ay nasa code; Kung hindi magbabago ang code, hindi magbabago ang pag-uugali. Sa ML, ang pag-uugali ay nakasalalay sa parehong code, data at modelo. Ang tatlong dimensyong ito ay lumilikha ng mga karagdagang hamon ng MLOps:
- Data drift: Ang data sa produksyon ay lumalayo sa data sa pagsasanay sa paglipas ng panahon; nagiging laos na ang modelo.
- Kailangan mong i-bersyon ang tatlong bagay: Code, data, at modelo—tatlo.
- Tahimik na pagkabigo: Maaaring mabigo ang isang modelo nang walang pag-crash, nang hindi nagbibigay ng mga error, sa pamamagitan lamang ng paggawa ng mga maling hula. Ang paghuli nito ay nangangailangan ng pagsubaybay.
Iyon ang dahilan kung bakit may malaking pagkakaiba sa pagitan ng isang "working model" at isang "production-ready model".
Model packaging at presenting
Ang unang hakbang sa paglalagay ng modelo sa produksyon ay ang pag-iimpake nito: ang file ng modelo, mga kinakailangang aklatan, preprocessing code, at impormasyon ng bersyon nang magkasama bilang isang buo na maaaring kopyahin. Ang Containerization (hal. Docker: paglalagay ng application sa isang nakahiwalay na kahon kasama ang lahat ng dependencies nito) ay pamantayan dito; Tinatanggal nito ang problemang "ito ay gumagana sa aking makina".
Dalawang pangunahing pattern ng paghahatid ng modelo:
- Online/real-time (online): Nasa likod ng isang API ang modelo, na nagbabalik ng instant na hula para sa bawat papasok na kahilingan. Ang mababang latency ay kritikal.
- Batch: Pana-panahong pinoproseso ng modelo ang malalaking set ng data (hal. bumubuo ng mga score para sa lahat ng customer sa gabi). Ang latency ay hindi nauugnay, ang kahusayan ay mahalaga.
Alin ang tama ay depende sa pangangailangan ng negosyo: instant na rekomendasyon online, buwanang marka ng panganib sa batch.
Tip: Ang "Real-time" ay isang gastos, hindi ang default. Ang batch ay mas mura at mas simple kung ang resulta ay gagamitin sa loob ng ilang oras. Kailangan mo ba ng agarang sagot? Itanong mo muna yan.
Mga ligtas na diskarte sa pamamahagi
Ang direktang pagbubukas ng bagong modelo sa lahat ng trapiko ay mapanganib; Kung mali, lahat apektado. Ligtas na mga pattern ng pamamahagi:
- Shadow deployment: Ang bagong modelo ay tumatanggap ng trapiko ng produksyon, ngunit ang mga hula nito ay hindi ipinapakita sa user, naka-log lamang. Inihahambing ito sa lumang modelo upang makita kung ligtas ito sa totoong data.
- Canary deployment: Ang bagong modelo ay unang inilunsad sa isang maliit na porsyento ng trapiko (hal. 5%); Kung walang problema, unti-unti itong nadaragdagan.
- A/B testing: Dalawang modelo ang ipinakita sa totoong user nang magkatulad at ang mga sukatan ng negosyo (conversion, mga pag-click) ay inihahambing.
- Rollback: Kakayahang mabilis na bumalik sa lumang bersyon kung ang bagong modelo ay lumabas na masama. Ang bawat deployment ay dapat may rollback plan.
Babala: Hindi kumpleto ang deployment na walang rollback plan. Ang kakayahang bumalik sa lumang bersyon sa loob ng ilang minuto ay nagpoprotekta sa user kapag hindi inaasahang kumilos ang bagong modelo sa produksyon. Subukan ito bago i-deploy.
Mahinang diskarte / Malakas na diskarte
Mahina: "Ang modelo ay mahusay sa pagsubok, nag-live kami, binuksan namin ito sa lahat."
Güçlü: "Nilagyan namin ng container ang modelo, nilagyan ito ng label bilang isang bersyon. Una, pinatakbo namin ito sa shadow mode na may traffic ng produksyon sa loob ng 3 araw, inihambing ang mga hula sa lumang modelo — katanggap-tanggap ang deviation. Pagkatapos ay binuksan namin ito gamit ang 5% canary, sinusubaybayan ang throughput metrics at latency. Kapag walang mga problema, unti-unti namin itong dinagdagan sa 100%.
Ang pagkakaiba: ang malakas na diskarte ay unti-unti, nasusukat at nababaligtad. Ang panganib ay limitado sa bawat hakbang.
CI/CD at automation
Ang CI/CD (Continuous Integration / Continuous Deployment: pipeline ng awtomatikong pagsubok at pagpapalabas ng mga pagbabago sa code) sa ML ay sumasaklaw hindi lamang sa code kundi pati na rin sa data at mga hakbang ng modelo. Isang mahusay na pipeline ng ML CI/CD: nagpapatakbo ng mga pagsubok kapag nagbago ang code, nagsasagawa ng pagpapatunay ng data, muling sinasanay ang modelo (kung kinakailangan), sinusuri ang mga threshold ng pagsusuri, at nagsusulong lamang ng deployment kung nananatili ang mga threshold. Ang prinsipyo ng "pagsasanay ay awtomatiko, ang deployment ay nakabatay sa threshold" ay pumipigil sa masamang modelo mula sa tahimik na pagtagas sa produksyon.
Malaking tulong ang AI kapag nagse-set up ng mga pipeline na ito: pagsusulat ng mga draft ng configuration file (YAML), mga kaso ng pagsubok, mga script sa pag-deploy. Ngunit tinutukoy mo ang mga limitasyon ng pamamahagi (anuman ang sukatan na lumampas sa kung anong halaga ang na-publish) at patakaran sa rollback; ito ay mga desisyon sa panganib sa negosyo.
Imprastraktura ng muling paggawa
Upang ma-reproduce ang gawi ng isang modelo sa produksyon, model registry: isang record na nagpapanatili kung aling modelo ang sinanay kung aling data at code, at kung aling mga sukatan ang natanggap nito. Para sa bawat modelo ng produksyon, ang mga sumusunod ay dapat na masubaybayan: bersyon ng data ng pagsasanay, bersyon ng code (git commit), hyperparameter, mga marka ng pagsusuri, at petsa ng pag-deploy. Kapag lumitaw ang isang problema, dapat mong masagot ang tanong na "aling modelo ang gumawa ng hulang ito, gamit ang aling data?" sa loob ng ilang minuto. Palalimin natin ito sa unit 11.
tatlong mini case
Kaso 1 - Nahuli ang problema sa pamamagitan ng pamamahagi ng anino. Tinalo ng modelo ng rekomendasyon ang luma sa pagsubok. Ang pagpapatakbo nito nang may trapiko sa produksyon sa shadow mode ay nakitang gumawa ng napakahinang rekomendasyon para sa isang partikular na segment ng mga user (mga bagong user) — ang data ng pagsubok ay kulang sa kinatawan ng segment na ito. Ang modelo ay naayos nang hindi kailanman ipinapakita sa gumagamit. Kung direkta itong binuksan, maaabala ang bagong karanasan ng user.
Kaso 2 - Hindi mababawi na pamamahagi. Isang team ang naglunsad ng bagong modelo ng pagpepresyo sa lahat ng trapiko, na walang mga rollback plan. Ang modelo ay hindi inaasahang nagpresyo sa ilang mga produkto nang napakamura. Ang pagbabalik sa lumang bersyon ay tumagal ng ilang oras dahil hindi pa handa ang proseso. Nagkaroon ng malubhang pagkawala ng kita. Pagkatapos, idinagdag ang mandatoryong rollback testing sa bawat deployment.
Case 3 - Silent data drift. Lumitaw ang isang pattern ng pandaraya sa loob ng maraming buwan nang walang anumang mga error. Ngunit nagbago ang mga taktika ng mga manloloko (data drift) at tahimik na bumaba ang recall ng modelo. Walang nakapansin dahil walang monitoring. Sa sandaling naitatag ang isang panel ng pagsubaybay sa pamamahagi ng pagtataya, ang drift ay naging maagang nakikita. Sasaklawin natin ang pagsubaybay sa unit 8.
Mga nakopyang template
Sumulat ng draft na plano sa pag-deploy para sa modelong ito. Modelo: [ano ang ginagawa nito], paggamit: [online o batch?] Dapat kasama ang:1) Packaging (container, versioning)2) Incremental na diskarte sa pag-deploy (shadow/canary/A-B) at bakit3) Mga sukatan na susubaybayan (negosyo + teknikal + latency)4) Rollback na plano at kung paano susubok5) Mga limitasyon ng deployment (na kung saan ang sukatan) ay dapat lumampas sa kung anong halaga
Suriin itong ML CI/CD pipeline:1) Nasa linya ba ang validation ng data?2) Magpapatuloy ba ang deployment nang hindi hinahawakan ang evaluation threshold (hindi ba dapat)?3) Automatic ba ang rollback?4) Sinusubaybayan ba ang data+code+metrics sa model registry? Configuration ng Pline: [config]
Tulungan akong magpasya kung ang online o batch na presentasyon ay angkop para sa modelong ito. Gaano katagal gagamitin ang resulta: [instant / minute / hour / day]Inaasahang dami ng kahilingan: [number]May hadlang ba sa pagkaantala: [ms]Alin ang irerekomenda mo sa mga tuntunin ng gastos at pagiging kumplikado at bakit?
Sumulat ng rollback procedure para sa modelong ito.- Anong sukatan/threshold ang nagti-trigger ng mahinang performance?- Ano ang mga hakbang sa rollback?- Gaano katagal dapat tumagal ang rollback (target)?- Paano ko susubukin ang pamamaraang ito bago ang produksyon?
Talahanayan ng pattern ng pagtatanghal
pamantayan
Online (real time)
Batch
pagkaantala
Kritikal (ms)
hindi gaanong mahalaga
Paggamit
Kinakailangan ang agarang tugon
Pana-panahong marka
Gastos
mataas
mababa
pagiging kumplikado
mataas
mababa
halimbawa
Live na rekomendasyon, scam
Buwanang marka ng panganib
Mga karaniwang pagkakamali
- Ipamahagi nang walang plano ng pagkuha. Maling modelo ang tumama sa buong user.
- Direktang pagbubukas sa 100% trapiko. Limitahan ang panganib sa staggered distribution.
- Hindi nagtatatag ng pagsubaybay. Ang modelo ay gumagawa ng mga error nang tahimik, nang walang error.
- Labis na real-time na pagtatanghal. Habang ang batching ay sapat, ang gastos at pagiging kumplikado ay lumaki.
- Hindi nagli-link ng mga bersyon ng model-data-code. Hindi mo maaaring kopyahin ang problema.
- Awtomatikong paglabas na walang limitasyon sa pamamahagi. Tahimik na pumasok ang masamang modelo.
Sa buod
Ang paglipat ng modelo sa produksyon ay iba at kadalasang mas mahirap na gawain sa engineering kaysa sa pagsasanay nito. Nangangailangan ang ML ng dagdag na disiplina dahil nakadepende ito sa code-data-model trio: packaging at versioning, pattern ng paghahatid (online/batch) na nababagay sa pangangailangan ng negosyo, unti-unti at nababagong deployment, threshold-controlled na CI/CD at pagpaparehistro ng modelo. Ang artificial intelligence ay isang malakas na tulong sa pagbuo ng code at configuration ng imprastraktura na ito; ngunit ang mga limitasyon sa pamamahagi, patakaran sa clawback, at mga desisyon sa peligro ay sa iyo. Hindi kumpleto ang pamamahagi nang walang rollback plan.
Gawain ng aplikasyon
I-containerize (Docker) ang isang modelo at lagyan ng label ito na bersyon. Magpasya kung mag-aalok ka online o batch batay sa iyong mga pangangailangan sa negosyo at isulat ang iyong katwiran. Magdokumento ng isang phased deployment plan (shadow o canary) at isang nasubok na pamamaraan ng rollback. Tiyaking itala ang bersyon ng data, code commit, at mga marka ng pagsusuri sa registry ng modelo.
checklist
- [ ] Ang modelo ay nakabalot at may bersyon (lalagyan + label).
- [ ] Ang pattern ng pagtatanghal (online/batch) ay pinili ayon sa pangangailangan ng negosyo.
- [ ] Ipinatupad ang nakaplanong diskarte sa pag-deploy (anino/canary).
- [ ] Isinulat at sinubok ang pamamaraan ng rollback.
- [ ] Hindi isinusulong ng CI/CD ang deployment bago maabot ang threshold ng pagsusuri.
- [ ] Hawak ng registry ng modelo ang link ng data+code+metric.