Content
P:
Per què executar la formació d'aprenentatge automàtic (ML) en una màquina local i després executar execució regular en un servidor?
R:
La qüestió de com estructurar un projecte d'aprenentatge automàtic i les seves fases de formació i prova té molt a veure amb la manera de passar pel "cicle de vida" de ML i portar el programa des d'un entorn de formació a un entorn de producció.
Una de les raons més senzilles d’utilitzar el model anterior de posar entrenament en ML en una màquina local i traslladar l’execució a un sistema basat en servidor és el benefici d’una separació essencial dels deures. En general, voleu que el conjunt d’entrenament quedi aïllat, de manera que tingueu una imatge clara de on comença i s’atura l’entrenament i on comença la prova. Aquest article de KDNuggets parla sobre el principi de manera gruixuda i també recorre algunes de les altres raons per aïllar conjunts d'entrenament en una màquina local. Una altra proposta de valor bàsica d’aquest model és que, amb els conjunts de formació i proves d’arquitectures molt diferents, mai no es confondrà amb l’assignació conjunta de trens / proves.
Un altre benefici interessant té a veure amb la ciberseguretat. Els experts assenyalen que, si teniu els processos inicials de tren en una màquina local, no ha d'estar connectat a Internet. Això amplia la seguretat de manera fonamental, “incubant” el procés fins a arribar al món de la producció, on haureu d’incorporar una seguretat adequada al model de servidor.
A més, alguns d’aquests models “aïllats” poden ajudar-se a problemes com la deriva del concepte i les contrapes ocultes - el principi de “no estacionalitat” adverteix als desenvolupadors que les dades no “es mantenen les mateixes” amb el pas del temps (depenent de què es mesura) que es pot necessitar molta adaptabilitat perquè una fase de prova coincideixi amb una fase de tren. O, en alguns casos, els processos de tren i prova es barregen, creant confusió.
Desplegar la fase de prova en un servidor per primera vegada pot facilitar diversos models de “caixa negra” on es resol el problema d’adaptabilitat de dades. En alguns casos, elimina el procés redundant de fer ordres de canvi a diverses plataformes.
Aleshores, també, l’entorn del servidor serveix, òbviament, en processos dinàmics o en temps real en què els enginyers voldran accedir als models de codi de transferència de dades i que funcionen millor per a la producció en ML. Per exemple, AWS Lambda pot ser una opció atractiva per manejar les microfuncions de producció (o una combinació d’emmagatzematge d’objectes Lambda i S3) i sense connectivitat (sense un servidor) que esdevingui impossible.
Aquests són alguns dels problemes que els desenvolupadors poden pensar quan es plantegen la forma de particionar les fases ML de les proves i la producció.