Oslobađanje moći umjetne inteligencije: Izrada aplikacije pokretane neuronskom mrežom

Uvod

Koji su potrebni koraci u stvaranju aplikacije pokretane neuronskom mrežom? Koje su najbolje prakse za korištenje neuronskih mreža i lokalno i u oblaku? Nakon što završimo s osnovama, kako proširiti naše rješenje? Kako se nosi sa skaliranjem, hostingom više neuronskih mreža, sigurnošću, privatnošću i praćenjem?

Ako ste si ikada postavili neko od ovih pitanja, imate sreće. Spremate se na intrigantno putovanje u daleku zemlju neuronskih mreža (NN). Pokazat ćemo vam kako podijeliti snagu vaše NN tako što ćete je učiniti dostupnom kome god želite, bez muke. Tijekom našeg putovanja, koristit ćemo FastAPI okvir za stvaranje Python API omotača oko naše NN i dockerizirati naše okruženje. Idemo još dalje i pogledat ćemo skaliranje, razgovarati o tome kako ublažiti neugodna iznenađenja primjenom najboljih sigurnosnih praksi i što učiniti u vezi s praćenjem i održavanjem.

Udobno se smjestite, krećemo za 3...2...1!

Za nestrpljive

Ako znate sve i samo želite pokrenuti i testirati svoju potpuno novu aplikaciju za analizu sentimenta koju pokreće neuronska mreža, slijedite ove korake:

• Instalirajte Docker
• Klonirajte ovo spremište
• Postavite svoju ljusku u korijen spremišta
• Izradite docker sliku $ docker build -t sentiment_analysis
• Pokrenite kontejner $ docker run --rm -it -p 8000:8000 sentiment_analysis
• Pozovite krajnju točku analize sentimenta otvaranjem http://localhost:8000 u pregledniku ili pokretanjem cURL naredbe iz ljuske:

curl -X 'POST' \ 

     'http://localhost:8000/sentiment_analysis' \ 

     -H 'accept: application/json' \ 

     -H 'Content-Type: application/json' \ 

     -d '{ "user_review": "You have done a fantastic job running this neural network :)" }'

Izlaz:

{"sentiment_analysis":"5 stars"}

Izradite API omotač

Jednostavnost korištenja je važna. Bez obzira na to koliko dobro neuronska mreža radi, skupljat će prašinu ako nije jednostavna za korištenje. Krajnji korisnici ne bi se trebali morati baviti složenim argumentima u ML bibliotekama, instalirati brojne ovisnosti ili preuzimati ogromne modele i skupove podataka.

U ovom odjeljku standardizirat ćemo pristup našoj neuronskoj mreži stvaranjem API omotača oko nje i omogućavanjem njenog pristupa putem mreže putem REST HTTP krajnje točke. Potpuni repozitorij može se pronaći ovdje.

Ključne točke interesa u repozitoriju su:

a) Krajnja točka za izvođenje analize sentimenta na ./app/router/sentiment
b) Definicija tijela zahtjeva, validacija unosa i predobrada na ./app/schemas/sentiment
c) Učitavanje i zaključivanje neuronske mreže na ./app/services/sentiment

(a) Vaše krajnje točke trebaju biti pažljivo dizajnirane, lako razumljive i teško ih je pogrešno protumačiti. Najbolji način za postizanje toga je pridržavanje najboljih praksi. Pogledajte ovaj članak ako niste sigurni što bi to moglo biti.

(b) Validacija unosa je obavezna. Čak i kada su vaše krajnje točke zatvorene za javnost, dobra je ideja implementirati ih jer ne možete biti sigurni da su podaci koje primate valjani; ako nisu, zahtjev bi trebao glasno i jasno propasti. Pydantic klasa precizno definira očekivano polje(a) i tip(ove) podataka u tijelu zahtjeva. Osim osnovne provjere tipa, provodimo predobradu teksta uklanjanjem HTML oznaka i ograničavanjem duljine niza na 10 000 znakova. HTML oznake ne dodaju vrijedne informacije analizi sentimenta, a duljina niza je ograničena jer želimo zaštititi naš sustav od degradacije performansi ili kvara u slučaju da ulazni nizovi postanu izuzetno veliki.

(c) Učitavanje neuronske mreže i izvođenje zaključivanja ovisit će o vrsti neuronske mreže koju koristite (za više detalja pogledajte odgovarajuću dokumentaciju neuronske mreže). U našem slučaju, dokumentacija se može pronaći ovdje. Općenito, trebali biste postaviti željeni računalni hardver kao device, staviti svoj model u način evaluacije model.eval() i onemogućiti izračun gradijenta @torch.no_grad(). Ovaj pristup osigurava optimalne performanse zaključivanja uklanjanjem opterećenja za značajke potrebne samo tijekom treniranja neuronskih mreža.

Dockerizacija okruženja

Opet, jednostavnost korištenja je važna, kako za developere tako i za korisnike. Svi smo čuli varijacije strašne priče "Radi na mom računalu". Izolacija okruženja dolazi u pomoć, nitko više ne mora pretrpjeti istu strašnu sudbinu. Cilj je eliminirati iznenađenja tako što ćemo softver uvijek pokretati u istom okruženju, na isti način. To postižemo grupiranjem našeg koda, ovisnosti i uputa za izvršavanje aplikacije na jednom mjestu. Složeni projekt može se lako pokrenuti jednostavnim izvršavanjem naredbe docker run. Izvrsno!

Stvorite Dockerfile

Prvi korak u dockerizaciji našeg okruženja je stvaranje ./Dockerfile. Ova datoteka sadrži skup uputa o tome kako bi trebala izgledati Docker slika (naš paket koda, ovisnosti i izvršavanja aplikacije). Osnovna slika je Docker slika na kojoj će se graditi naš projekt. U ovom slučaju, odabrali smo python:3.11-slim, minimalnu Debian distribuciju s unaprijed instaliranim Python 3.11. Zatim moramo definirati radni direktorij, instalirati ovisnosti, kopirati datoteke, postaviti dozvole itd. Na kraju, određujemo naredbu koja pokreće našu aplikaciju na kontejneru.

Izrada slike

Zatim moramo izgraditi sliku iz ./Dockerfile. Postavite svoju ljusku u korijen repozitorija i izvršite $ docker build -t sentiment_analysis.

Pokretanje kontejnera

Spremni smo za pokretanje kontejnera iz slike. Ovo će stvoriti minijaturni Linux kontejner koji će uvijek pokretati našu aplikaciju na isti način, u istom okruženju. Pokrenite kontejner s $ docker run --rm -it -p 8000:8000 sentiment_analysis.

Ako niste sigurni što su Dockerfiles, slike i kontejneri, pogledajte ovu kratku objavu.

Daljnji koraci

Implementacija

Implementacija u testno/stage/prod okruženje nije tema ovog blog posta jer se uvelike razlikuje ovisno o korištenoj tehnologiji i drugim specifičnostima projekta. Međutim, toplo preporučujemo automatizaciju vaših CI/CD cjevovoda. Što se tiče Gita, razmislite o pridržavanju principa razvoja temeljenog na trunkovima kako biste svoj tijek rada učinili što jednostavnijim.

Skaliranje za produkciju

Stvarni svijet rijetko je jednostavna stvar, a stavljanje softvera u produkciju nije iznimka. U nekom trenutku vjerojatno ćete se suočiti sa smanjenim performansama zbog velikog prometa ili prekida rada u dijelu vaše infrastrukture. Višak resursa također je problem; ne želite plaćati premiju za nešto što ne koristite. Ono što vam treba je fleksibilan način vertikalnog i horizontalnog skaliranja. Drago mi je što mogu reći da smo riješili problem skaliranja za vas! U redu, ako nije riješeno, onda smo vas barem gurnuli u pravom smjeru. 🙂

Vertikalno skaliranje nije velika stvar - sve što trebate učiniti je dodati resurse postojećem računalu ili nabaviti snažnije. Horizontalno skaliranje, međutim, može biti puno izazovnije. Dobro je što smo već na pravom putu.

Već imamo Docker kontejner bez stanja, savršenog kandidata za horizontalno skaliranje. Sve što trebate učiniti je pokrenuti X računala kod svog omiljenog pružatelja usluga u oblaku, pokrenuti ovaj kontejner na svakom računalu, postaviti računala iza uravnoteživača opterećenja i gotovi ste! Imate distribuirani sustav otporan na greške. Za više informacija o tome kako to postići, pogledajte ovdje.

Usluge pokrenute u ECS-u (AWS verzija Kubernetesa) iza Application Load Balancera

Ako su vaši strojevi nedovoljno iskorišteni, možete odlučiti vertikalno ih smanjiti. Ako to nije opcija, možete odlučiti povećati iskorištenost strojeva i dodati redundanciju pokretanjem, recimo, četiri aplikacijska procesa unutar svakog kontejnera umjesto jednog. To možete postići pokretanjem kontejnera naredbom $ docker run --rm -it -p 8000:8000 --env WORKERS=4 sentiment_analysis. To znači da će se unutar jednog docker kontejnera izvoditi 4 aplikacijska procesa (4 API-ja omotana oko 4 neuronske mreže). To je moguće jer smo vaš kontejner osnažili Gunicorn-om i Uvicorn-om. Gunicorn djeluje kao orkestrator i load balancer unutar kontejnera, stvarajući (4 u gornjem primjeru) Uvicorn workere, od kojih svaki zauzvrat stvara jedan proces vaše aplikacije. Horizontalno ste skalirali ne samo unutar svog klastera, već i unutar kontejnera.
Izvanredno!

Model Server

Novi izazovi pojavit će se kako broj neuronskih mreža koje hostirate počinje rasti. Natjecanje za resurse, problemi s korištenjem i ukupna složenost sustava počet će uzimati svoj danak. Ne postoji savršeno rješenje, samo kompromisi; ipak, sljedeće je najbolje što je ML zajednica osmislila za hostiranje mnogih neuronskih mreža.

Izradite model server tako da uzmete svoje neuronske mreže i postavite ih na zaseban, snažan stroj namijenjen izvođenju zaključivanja. Iskoristite postojeće okvire model servera, poput TorchServe i TensorFlow Serving. Ako imate opsežnu i redovito promjenjivu poslovnu logiku u svom trenutnom API omotaču, razmislite o tome da je držite izvan model servera. To će svaku komponentu učiniti upravljivijom i omogućiti vam brzo iskustvo implementacije s vašim API-jima poslovne logike, a istovremeno će sporo ponovno raspoređivanje gigantskih neuronskih mreža biti vezano za model server.

Odvojite neuronske mreže od poslovne logike

Sigurnost i privatnost

Minimum koji svaki API dostupan mreži treba implementirati je jednostavna kodirana tajna koja mora biti prisutna u zaglavlju dolaznog zahtjeva. To će se pokazati učinkovitim protiv nesofisticiranih napada zlonamjernih skripti koje lutaju internetom u potrazi za neosiguranim resursima. Ako je tajna dovoljno duga, bit će dovoljna čak i da izdrži napad grubom silom. Ovu metodu je lako implementirati, ali nipošto nije sigurna. Jednostavno presretanje mrežnog prometa dovoljno je da otkrije vašu tajnu. Ali opet, nadamo se da ovo koristite u scenariju s malim sigurnosnim potrebama, a ne za zaštitu vladinih i korporativnih resursa. JE LI TAK???

Preporučeni pristup za osiguranje API-ja je korištenje OAuth2 s JWT-om za autentifikaciju i HTTPS-om za enkripciju podataka u prijenosu. Ako ste u oblaku, uštedite si malo vremena i razmislite o korištenju jedne od postojećih ponuda za OAuth2 prije nego što ga sami implementirate. Uvijek izvršite validaciju unosa i imajte na umu informacije koje dijelite putem poruka o pogrešci. API se smatra sigurnim s kombinacijom ovih metoda. Koristite ih za bilo koji API koji vrijedi zaštititi.

Praćenje

Praćenje je bitan dio održavanja zdravlja sustava. Kako broj elemenata u vašem sustavu raste, tako raste i trud koji morate uložiti kako biste osigurali da svaki element ispravno radi. Ručno to vrlo brzo postaje nemoguće. Preporučujemo korištenje Grafane za vizualni prikaz podataka koje generiraju vaše aplikacije. Možete brzo pogledati Grafana nadzorne ploče i provjeriti je li vaša infrastruktura u redu. Izrada Grafana nadzornih ploča od nule može biti izazovna, ali srećom već postoji opsežna biblioteka nadzornih ploča. Pregledajte ih prije nego što pokušate izraditi vlastite.

Primjer Grafana nadzorne ploče

Bez obzira što radimo, uvijek će postojati iznimke koje će nas iznenaditi. Kada takvo vrijeme neizbježno dođe, najvažnije je da imamo uspostavljen solidan sustav za praćenje pogrešaka. Čak ni najbolji umovi neće vam moći pomoći ako nema zapisa o tome što se dogodilo. U tu svrhu preporučujemo korištenje Sentrya. To je sposobna mala aplikacija i dolazi u besplatnoj i upravljanoj verziji.

Zaključak

Čestitamo na završetku ovog izazovnog, ali intrigantnog putovanja. Nadam se da vam se horizont proširio i da odlazite s nekim korisnim idejama o tome kako stvoriti svoju aplikaciju pokretanu neuronskim mrežama, kao i o tome kako je integrirati u svoj sustav. Sretno kodiranje!