Sèrie d’API – OctoML: les API de ML han de prendre una lliçó dels seus avantpassats

Aquesta és una publicació de convidat per a Computer Weekly Developer Network escrita per Jason Knight en el seu paper de director de producte a OctoML — l’empresa és coneguda pel seu treball bcombinant l’agilitat de DevOps amb el desplegament de ML a desenvolupadors i operacions de TI capaços de crear aplicacions basades en IA.

Knight escriu de la següent manera…

Tots hem vist el genial gestes això l’aprenentatge automàtic modern és capaç. Però aquests són només la punta de l’iceberg. Els herois desconeguts dels models d’aprenentatge automàtic són els models més petits que fan que el programari existent funcioni millor, sovint molt millor, i permeten petites experiències noves que abans no eren possibles.

Però la dificultat de crear aplicacions intel·ligents amb la combinació de l’aprenentatge automàtic i l’enginyeria de programari tradicional encara depèn d’una gran quantitat de dolor, suor i llàgrimes.

Una gran part d’això es deu a la manca d’API estables i robustes per a l’aprenentatge automàtic.

Colls d’ampolla i deute tècnic

Els primers marcs d’aprenentatge automàtic d’aprenentatge profund com ara Theano i Caffe es van crear originalment per oferir API als científics de dades per definir i després entrenar models en conjunts de dades d’exemple. Sovint, el desplegament ni tan sols es va considerar ni es va deixar com una idea posterior, ja que aquests marcs van ser escrits per i per a la comunitat acadèmica d’aprenentatge automàtic.

Més tard, TensorFlow i després PyTorch van augmentar la flexibilitat i les capacitats disponibles per als científics de dades i l’abraçada estreta de PyTorch de l’intèrpret i el llenguatge de Python com a API ML primària va permetre grans passos endavant per a l’ergonomia i la flexibilitat per al científic de dades.

Però aquests beneficis tenen un cost. L’enfocament de definició de llenguatge Python com a model de PyTorch fa que els models d’enviament a altres piles o dispositius de producció siguin difícils.

Això contribueix a les lluites de traslladar els models d’aprenentatge automàtic del desenvolupament a la producció. Vegeu aquesta entrada del blog explicant una breu història de les compensacions de PyTorch pel creador Soumith Chintala, o el famós i encara molt aplicable paper de Google“Aprenentatge automàtic: la targeta de crèdit d’alt interès del deute tècnic” per aprofundir en aquestes compensacions i reptes.

Per fer front a les complexitats resultants d’acoblar el codi Python amb la definició del model ML, el codi PyTorch sovint es “llença per sobre del mur” des dels equips de desenvolupament de les organitzacions fins als equips d’operacions o de producció que són responsables de portar, mantenir o desplegar aquest codi a API i sistemes de producció.

Li sembla familiar a algú que va fer desenvolupament de programari els dies abans que tinguéssim API per provar, subministrar i supervisar automàticament el programari desplegat?

Habilitació de ML Devs

Per accelerar l’avenç de l’ML per impulsar les aplicacions intel·ligents del demà, hem de facilitar que els científics de dades puguin desplegar el seu propi codi donant-los eines perquè les seves API de desenvolupament s’ajustin a les API de producció, ja siguin al núvol o a la vora. .

L’única manera de fer-ho és creant millors abstraccions (API) i plataformes que encara conserven la flexibilitat de la qual gaudeixen els desenvolupadors avui dia, però també permeten la portabilitat i el rendiment del maquinari sense esforç de portabilitat/integració manual.

Comencem a veure els primers signes d’això amb biblioteques i eines que milloren la complexitat abstracta per permetre als usuaris fer més amb menys. Alguns exemples d’això inclouen la biblioteca de transformadors d’HuggingFace i BentoML.

També estem veient plataformes d’aprenentatge automàtic d’extrem a extrem (ofertes d’API ML allotjades). Aquestes plataformes poden ser útils per a les persones que comencen a l’espai, ja que permeten que les API de desenvolupament de ML i les API allotjades en ML siguin més harmonioses per construcció, però cal veure si aquestes es converteixen en la forma predominant de fer aprenentatge automàtic. Un punt de dades històriques interessants que cal fer servir per comparar és el món de l’enginyeria clàssica de SW, on hem vist un èxit lleu per a plataformes de desenvolupament d’extrem a extrem com Heroku, però, en general, el desenvolupament de programari avui encara es fa en gran part amb una barreja d’allotjament i no. solucions allotjades que es combinen per equips de diferents maneres.

Una altra possibilitat de com les API de desenvolupadors de ML s’alinearan més amb les API de producció és a través d’un augment de models fonamentals: un conjunt més petit de models grans i flexibles creats per la comunitat. Aquests models fonamentals es distribueixen lliurement per un petit conjunt de concentradors de ML sofisticats i després s’ajusten o es dissenyen ràpidament per a un objectiu determinat.

Això podria reduir prou els fluxos de treball d’enginyeria de ML com per simplificar el problema d’alinear les API de desenvolupament i les API de producció. La distribució de blocs de construcció de models fundacionals flexibles també té analogies amb l’augment de llibres de jocs i API de codi obert com la pila LAMP a la programació web inicial, SQLite a l’emmagatzematge de dades incrustat o MPI i, posteriorment, les API de Kubernetes per a la programació distribuïda.

Però només el temps dirà si la consolidació al voltant d’un conjunt més reduït de models fonamentals (per tant, els fluxos de treball i les API) superarà la diversificació a mesura que ML segueixi desenvolupant-se i especialitzant-se.

Què poden fer avui els desenvolupadors de ML?

Per a aquells de vosaltres que creeu aplicacions intel·ligents avui, el nom del joc és intentar evitar la complexitat accidental, en lloc de complexitat essencial – sempre que sigui possible. Això és cert per a l’enginyeria de programari en general, però esdevé encara més important quan s’afegeix ML al programari perquè la complexitat essencial de l’ML significa que encara teniu menys en el vostre pressupost per malbaratar.

A la pràctica, això significa adoptar (i crear) el nombre mínim de noves eines de ML, plataformes API i serveis. I per a aquells que adopteu, assegureu-vos que tinguin un abast limitat, com el que ens ensenya la filosofia Unix d’eines que serveixen per a propòsits únics i API simples.

Amb el pas del temps, les nostres API de desenvolupament i desplegament de programari continuaran combinant-se i ampliant-se prou com per abastar ML tal com han crescut per gestionar les innovacions anteriors en el desenvolupament de programari.

Leave a Comment

Your email address will not be published. Required fields are marked *