Saturs
J:
Kāpēc vadīt mašīnmācīšanās (ML) apmācību vietējā mašīnā un pēc tam regulāru izpildi darbināt uz servera?
A:
Jautājumam par to, kā strukturēt mašīnmācīšanās projektu un tā apmācības un pārbaudes posmus, ir daudz kas saistīts ar to, kā mēs virzāmies caur ML “dzīves ciklu” un pārvedam programmu no apmācības vides uz ražošanas vidi.
Viens no vienkāršākajiem iemesliem, kādēļ tiek izmantots iepriekšminētais ML apmācības ievietošanas vietējā mašīnā un izpildes pārvietošana uz servera balstītu sistēmu, ir būtisks pienākumu dalīšanas ieguvums. Parasti jūs vēlaties, lai apmācības komplekts būtu izolēts, lai jums būtu skaidrs priekšstats par to, kur sākas un apstājas apmācība un kur sākas pārbaude. Šajā KDNuggets rakstā runāts par principu rupjā veidā, vienlaikus apskatot arī dažus citus iemeslus, lai treniņu komplektus izolētu no vietējās mašīnas. Vēl viens šī modeļa pamatvērtības piedāvājums ir tāds, ka ar apmācības un testa komplektiem uz ļoti atšķirīgām arhitektūrām jūs nekad nevarēsit sajaukt kopīgu vilciena / testa sadalījumu!
Vēl viens interesants ieguvums ir saistīts ar kiberdrošību. Eksperti uzsver, ka, ja sākotnējie vilciena procesi notiek vietējā mašīnā, tam nav jābūt savienotam ar internetu! Tas būtiski paplašina drošību, “inkubējot” procesu, līdz tas sasniedz ražošanas pasauli, kur jums pēc tam jāveido atbilstoša servera modeļa drošība.
Turklāt daži no šiem “izolētajiem” modeļiem var palīdzēt ar tādām problēmām kā koncepcijas novirze un slēpti mīnusi - “nestabilitātes” princips brīdina izstrādātājus, ka dati laika gaitā “nemainās” (atkarībā no tā, ko mēra) un ka testa fāzes saskaņošana ar vilciena fāzi var aizņemt daudz pielāgošanās iespēju. Vai dažos gadījumos vilciena un testa procesi saplūst, radot neskaidrības.
Pārbaudes fāzes ieviešana uz servera pirmo reizi var atvieglot dažādus “melnās kastes” modeļus, kur tiek novērsta datu pielāgošanās problēma. Dažos gadījumos tas novērš lieko procesu - izmaiņu rīkojumus ievieto vairākās platformās.
Tad arī servera vide acīmredzami kalpo reāllaika vai dinamiskajiem procesiem, kuros inženieri vēlēsies piekļūt datu pārsūtīšanas un kodu modeļiem, kas vislabāk darbojas ML. Piemēram, AWS Lambda var būt pievilcīga iespēja, lai apstrādātu ražošanas mikrofunkcijas (vai Lambda un S3 objektu glabāšanas kombināciju) un bez savienojamības (bez servera), kas kļūst neiespējama.
Šie ir daži no jautājumiem, par kuriem izstrādātāji var padomāt, apsverot iespēju sadalīt ML fāzes no testēšanas un ražošanas.