DevOps su dirbtiniu intelektu ir LLMOps: nuo gamybos srauto iki kalbančio modelio

Informatec Digital » Ištekliai » DevOps su dirbtiniu intelektu ir LLMOps: nuo gamybos srauto iki kalbančio modelio

Generatyvaus dirbtinio intelekto ir didelių kalbų modelių atsiradimas visiškai pakeitė programinės įrangos kūrimo, diegimo ir valdymo būdus. Nebereikia turėti gerų „DevOps“ procesų ar taikyti klasikinius MLOps : įtraukus LLM į lygtį, patenkama į sritį, kurioje modelis kalba, samprotauja, improvizuoja ir kartais elgiasi nenuspėjamai.

Šioje naujoje aplinkoje komandos turi derinti „DevOps“, dirbtinį intelektą ir LLMOps, kad galėtų valdyti visą LLM pagrįstų programų gyvavimo ciklą – nuo ​​eksperimentavimo ir greito inžinerijos iki diegimo, stebėjimo, saugumo ir sąnaudų optimizavimo. Šiame straipsnyje paaiškinami sudėtingumai ir žingsnis po žingsnio paaiškinama, kaip integruoti „ChatOps“, „DevOps“, „MLOps“, „GenAIOps“ ir „LLMOps“ į šiuolaikinę veiklą.

Nuo DevOps ir MLOps iki LLMOps: kodėl modelis nebėra statinis

Metų metus inžinierių komandos teikė pirmenybę programinės įrangos teikimo automatizavimui ir trinties tarp kūrimo ir infrastruktūros mažinimui . Tai lėmė DevOps atsiradimą: nuolatinė integracija, nuolatinis diegimas, infrastruktūra kaip kodas, stebimumas ir bendradarbiavimo kultūra, kuri panaikino nesibaigiantį perdavimą tarp skyrių.

Kai duomenys tapo produkto dalimi, MLOps atsirado kaip atsakas į mašininio mokymosi modelių atkuriamumo ir atsekamumo poreikį . Tokios praktikos kaip duomenų rinkinių versijų kūrimas, mokymo srauto orkestravimas, poslinkio aptikimas ir nuolatinis nuspėjamųjų modelių vertinimas buvo standartizuotos.

Problema ta, kad LLM pažeidžia daugelį DevOps ir MLOps numanomų prielaidų . Tai nėra statinės API ar paprastos funkcijos, grąžinančios deterministinį skaičių: jos atsako natūralia kalba, derina kontekstą, instrukcijas, įrankius ir realaus laiko duomenis ir gali pateikti du skirtingus rezultatus tam pačiam įvesčiai.

Tai reiškia, kad nepakanka versuoti modelį ir jo svorius ; taip pat būtina kontroliuoti raginimus, šablonus, semantinio saugumo politikas, apribojimus, prijungtus įrankius, įterptą kontekstą ir net verslo taisykles, kurios sąlygoja sistemos elgseną.

Kas yra LLMOps ir ką jis iš tikrųjų sprendžia?

LLMOps galime laikyti operacine sistema, leidžiančia saugiai, kontroliuojamai ir tvariai diegti, prižiūrėti ir plėsti LLM pagrįstas programas . Tai skėtis, po kuriuo egzistuoja DevOps praktikos, MLOps ir naujos generatyviniams modeliams būdingos galimybės.

Iš esmės LLMOps mažiau dėmesio skiria „tobulo modelio mokymui“, o daugiau – jo elgesio valdymui gamyboje . Tai apima, kaip kuriami ir versuojami greitieji srautai, kaip LLM jungiasi prie vidinių duomenų šaltinių, kaip stebimos žetonų kainos ir delsa bei kaip valdoma semantinė rizika (haliucinacijos, informacijos nutekėjimas, šališkumas, toksiškos reakcijos ir kt.).

Poreikiai, kuriuos tenkina LLMOps ir kurių negali patenkinti vien DevOps/MLOps, apima tokius įvairius aspektus kaip pokalbių atsekamumas, automatinis atsakymų kokybės vertinimas ir elgsenos variantų A/B testavimas . Kalbame ne tik apie klasikinį tikslumą, bet ir apie nuoseklumą, suderinamumą su verslu bei saugumą.

Be to, išlaidos nebėra apribotos modelio mokymu ir talpinimu : kiekvienas raginimas, kiekvienas išplėstinis kontekstas ir kiekvienas lygiagretus iškvietimas suaktyvina GPU arba žetonų naudojimą komercinėse API sąsajose. Be LLMOps sluoksnio, kuris šias išlaidas padarytų matomas ir susietų su įranga, paslaugomis ir naudojimo atvejais, sąskaita augtų nenuspėjamai.

„ChatOps“ + „LLMOps“ + „DevOps“: operacijos tampa pokalbių forma

Viena iš galingiausių tendencijų yra „ChatOps“ ir „LLMOps“ integracija į „DevOps“ kultūrą . Užuot apsiribojusios ataskaitų suvestinėmis, scenarijais ir procesų valdymu, komandos pradeda valdyti didelę sistemos dalį per pokalbių kanalus, tokius kaip „Slack“, „Microsoft Teams“ ar „Discord“.

„ChatOps“ siūlo, kad kasdienes operacijas (diegimus, žurnalų užklausas, perkrovimus, konfigūracijos pakeitimus) vykdytų botai pačiame komunikacijos kanale , skaidriai visai komandai. Kiekviena komanda, veiksmas ir rezultatas būtų įrašomi pokalbyje.

Kai prie šio metodo pridedama LLM, atsiranda naujas intelekto sluoksnis: pokalbių robotai, kurie supranta natūralią kalbą, interpretuoja ketinimus ir gali aktyvuoti sudėtingas komandas arba analizuoti situacijas, operatoriui nereikėdami prisiminti kiekvieno tikslaus scenarijaus ar vėliavėlės.

Tipiški šios konvergencijos pavyzdžiai: LLM valdomas robotas, kuris, kas nors įveda „X grupės paslauga lėta“, nuskaito metriką iš „Prometheus“ ir žurnalus iš „Loki“, ir siūlo tokius veiksmus kaip replikų mastelio keitimas, ankstesnių pakeitimų atlikimas arba konkrečių testų paleidimas, visa tai paaiškinama natūralia kalba.

Kultūriniu ir operaciniu lygmeniu tai reiškia greitesnį sprendimų priėmimą, mažesnį rankinį įsikišimą į pasikartojančias užduotis ir sklandesnę patirtį „DevOps“ komandoms , kurios nuo nuolatinio gaisrų gesinimo pereina prie darbo ties strateginiais patobulinimais.

Pagrindiniai LLM gyvavimo ciklo gamyboje principai

Rimtos LLM programos vykdymas nėra vienkartinis projektas; tai pasikartojantis ciklas, kai kiekvienas pokytis gali pakeisti sistemos elgesį . Nors kiekviena organizacija ją pritaiko prie savo realybės, paprastai yra šeši pagrindiniai, savaime sustiprėjantys etapai.

Pirmasis etapas yra modelio mokymas arba adaptacija , kuris gali apimti nuo bazinio modelio naudojimo iki tikslinimo, LoRa ar kitų derinimo metodų taikymo su savo duomenimis. Čia svarbus ne tik našumas, bet ir išsamus įrašas: duomenų rinkiniai, pritaikyti filtrai, hiperparametrai, tokenizer versijos, išbandytos architektūros ir kt.

Jei šis etapas yra improvizuotas ir nedokumentuojamas, modelis gimsta be valdymo . Vėliau bus beveik neįmanoma paaiškinti, kodėl jis reaguoja taip, kaip reaguoja, arba pakartoti konkretų rezultatą, kai to reikės audito metu.

Antrasis etapas yra diegimas, kai modelis palieka laboratoriją ir patenka į gamybą. LLMOps atveju tai ne tik „įdėjimas į konteinerį“: turite nuspręsti, kokią aparatinę įrangą naudoti , kaip valdyti atmintį ilgai veikiančiuose kontekstuose, kokią klasterio topologiją taikyti ir kaip keisti mastelį pagal srautą, kad delsa nepadidėtų, o išlaidos netaptų nevaldomos.

Nuo tada pradedamas nuolatinis į elgesį orientuotas stebėjimas . Nepakanka vien žiūrėti į procesoriaus ir RAM naudojimą; būtina stebėti atsakymų semantinę kokybę, stiliaus stabilumą, klaidų dažnį, žetono kainos kitimą, pavojingų ar nenuoseklių atsakymų atsiradimą ir atsako laiko pokyčius esant skirtingiems naudojimo modeliams.

Vėlesniuose etapuose atliekamos optimizavimo ir tikslinimo užduotys: koreguojamos užklausos, koreguojamas RAG, testuojami modelio variantai, kvantuojamas įvertinimas, atliekamas A/B testavimas, keičiamos semantinio saugumo politikos arba tobulinamos verslo taisyklės . Tai beveik amatinis procesas, kai duomenys, inžinerija ir verslas susijungia, kad nuspręstų dėl prioritetų.

Galiausiai, visa tai įgyvendinama saugumo ir valdymo lygmenyse (prieigos kontrolė, auditas, nutekėjimo prevencija, naudojimo apribojimai, atitiktis reglamentams) ir nuolatinio atnaujinimo logikoje, kur modelis ir jo ekosistema pritaikomi prie duomenų, reglamentų ir vidinių poreikių pokyčių.

„GenAIOps“ ir pranešimų srauto metodas „Azure“ platformoje

LLMOps visatoje yra labai konkrečių pasiūlymų, kaip struktūrizuoti šį gyvavimo ciklą. Vienas pažangiausių įmonių aplinkoje yra „GenAIOps“ su greitaisiais srautais „Azure Machine Learning“ sistemoje, integruotu su „Azure DevOps“ , kuris siūlo labai sistemingą požiūrį į LLM pagrindu veikiančių programų kūrimą.

Raginimų srautas yra ne tik raginimų redaktorius; tai visavertė platforma LLM sąveikos srautams projektuoti, testuoti, versuoti ir diegti – nuo ​​paprastų atvejų (vienas raginimas) iki sudėtingų sąrangų su keliais mazgais, išoriniais įrankiais, valdikliais ir automatizuotais vertinimais.

Svarbus bruožas yra centralizuota darbo eigų saugykla , kuri veikia kaip įmonės biblioteka. Vietoj to, kad kiekviena komanda turėtų savo raginimus atskiruose dokumentuose ar savo saugyklose, jie yra sujungti į vieną valdomą saugyklą su aiškiomis šakomis, pataisymais ir istorijomis.

Be to, platforma prideda variantų ir hiperparametrų eksperimentavimo galimybes: galima išbandyti skirtingus raginimų, modelių, temperatūros nustatymų ar saugumo politikų derinius keliuose srauto mazguose ir palyginti rezultatus su aiškiais rodikliais.

Kalbant apie diegimą, „GenAIOps“ su pranešimų srautu generuoja „Docker“ atvaizdus, ​​kurie apima ir srautą, ir proceso sesiją , paruoštus veikti tokiose aplinkose kaip „Azure App Services“, „Kubernetes“ arba valdomuose procesuose. Remiantis tuo, A/B diegimai leidžia palyginti srauto versijas realiose aplinkose.

Dar vienas privalumas yra duomenų rinkinių ir srautų ryšių valdymas. Kiekvienas vertinimo srautas gali veikti su keliais standartiniais ir testavimo duomenų rinkiniais , todėl galima patvirtinti elgseną skirtinguose scenarijuose prieš pateikiant duomenis galutiniams vartotojams.

Platforma taip pat automatiškai registruoja naujas duomenų rinkinių ir srautų versijas tik tada, kai įvyksta faktinių pakeitimų, ir generuoja išsamias ataskaitas tokiais formatais kaip CSV ir HTML, kad būtų galima priimti duomenimis pagrįstus sprendimus, o ne priimti intuiciją.

Keturi „GenAIOps“ etapai su pranešimų srautu

„GenAIOps“ metodas gyvavimo ciklą suskirsto į keturis aiškiai atskirtus etapus, kurie padeda išvengti tipinio chaoso „išbandome dalykus su DI ir žiūrime, kas gaunasi“.

Pirmasis etapas, inicijavimas, skirtas tiksliam verslo tikslo apibrėžimui ir reprezentatyvių duomenų pavyzdžių rinkimui . Čia apibrėžiama pagrindinė raginimų srauto struktūra ir sukuriama architektūra, kuri vėliau bus tobulinama.

Eksperimentavimo etape srautas taikomas šiems pavyzdiniams duomenims ir įvertinami skirtingi raginimų, modelių ir konfigūracijų variantai . Iteracija tęsiama tol, kol randamas priimtinas derinys, atitinkantis minimalius kokybės ir nuoseklumo reikalavimus.

Toliau seka vertinimo ir patikslinimo etapas, kurio metu griežtai lyginamajai analizei naudojami didesni ir įvairesni duomenų rinkiniai . Tik tada, kai srautas rodo nuoseklų veikimą, atitinkantį nustatytus standartus, jis laikomas paruoštu kitam etapui.

Galiausiai, diegimo etape darbo eiga optimizuojama efektyvumui ir diegiama gamyboje, įskaitant A/B testavimą, stebėjimą, vartotojų atsiliepimus ir nuolatinio tobulinimo ciklus . Niekas niekada nebūna iki galo užbaigta: darbo eiga ir toliau koreguojama remiantis realaus pasaulio naudojimo stebėjimais.

Ši metodologija yra supakuota į „GenAIOps“ saugyklos šabloną su iš anksto sukurtais, kodo pagrindu sukurtais srautais ir vietiniais bei debesijos pagrindu veikiančiais vykdymo įrankiais, skirtais kurti, vertinti ir paleisti LLM pagrįstas programas neišradinėjant dviračio kiekvienam projektui iš naujo.

Integracija su „Azure DevOps“: saugyklos, srautai ir autentifikavimas

Norint „GenAIOps“ perkelti iš teorijos į realią organizaciją, labai svarbu jį integruoti su „Azure DevOps“. Įprastas šablonas prasideda nuo saugyklos „Azure Repos“ platformoje su dviem pagrindinėmis šakomis – pagrindine ir kūrimo , atspindinčiomis skirtingas aplinkas ir kodo reklamavimo strategijas.

Pavyzdinė saugykla klonuojama iš „GitHub“, susieta su „Azure Repos“, o įprasta darbo eiga apima funkcijų šakų kūrimą iš kūrimo katalogo . Pakeitimai tada įkeliami naudojant „pull requests“, kurios automatiškai suaktyvina patvirtinimo ir eksperimentavimo procesus.

Kad „Azure DevOps“ galėtų sąveikauti su „Azure Machine Learning“ ir kitomis paslaugomis, „Azure“ sistemoje paslaugos principas sukonfigūruojamas kaip techninė tapatybė . Ši tapatybė naudojama „Azure DevOps“ paslaugos ryšyje, leidžiant kanalams autentifikuotis neatskleidžiant aiškių raktų.

Paprastai šis subjektas turi savininko teises ML prenumeratoje arba darbuotojų ištekliuje, leidžiančias srautams konfigūruoti galinius taškus, registruoti modelius ir atnaujinti strategijas raktų saugyklose . Siekiant didesnio saugumo, jį galima pakeisti į bendraautoriaus vaidmenį, modifikuojant YAML veiksmus, kurie tvarko teises.

Be to, „Azure DevOps“ sukuriama kintamųjų grupė, kurioje saugomi slapti duomenys, pvz., paslaugos ryšio pavadinimas arba išteklių identifikatoriai . Šie kintamieji pateikiami srautams kaip aplinka, todėl nereikia į kodą įrašyti svarbios informacijos.

Vietinių ir nuotolinių saugyklų konfigūravimas leidžia apsaugoti kūrimo šaką naudojant šakos politikas , kurioms reikalingas užklausų srauto paleidimas prieš sujungiant. Šis srautas tvarko kompiliavimo patvirtinimus ir eksperimentavimo srautus, neleisdamas įdiegti neveikiančių pakeitimų.

Kai kodas pradedamas kurti, paleidžiamas kūrimo procesas, apimantis visus CI ir CD etapus : eksperimentų ir vertinimų vykdymą, srautų registravimą „Azure ML“ modelio registre, galinių taškų ir dūmų testų diegimą bei integravimą į naujai sukurtus galinius taškus.

Tas pats modelis pakartojamas versijos arba leidimo šakoje, prijungtoje prie gamybos aplinkų. Ten CI/CD gamybos srautai kartoja eksperimentavimo, vertinimo ir diegimo ciklą , tačiau gamybos lygio infrastruktūroje ir duomenyse, su didesne kontrole ir papildomomis rankinėmis peržiūromis, jei reikia.

Svarbiausia šių srautų funkcija yra „ciklinis žmogaus atliekamas peržiūrėjimas“: po integracijos etapo CD blokuojamas, kol asmuo rankiniu būdu nepatvirtina tęsinio per „Azure Pipelines“ sąsają. Jei tai nepatvirtinama per nurodytą laiką (pvz., 60 minučių), vykdymas atmetamas.

Vietinis įgyvendinimas ir ryšys su LLM teikėjais

Ne viskas vyksta per konvejerius: „GenAIOps“ taip pat palaiko vietinį vykdymą greitam eksperimentavimui . Galite klonuoti šablonų saugyklą, sukurti .env failą šakniniame kataloge ir apibrėžti ryšius su „Azure OpenAI“ ar kitais suderinamais galiniais taškais jame.

Šie ryšiai apima tokius parametrus kaip „api_key“, „api_base“, „api_type“ ir „api_version“, ir srautuose į juos nurodomi pavadinimai (pavyzdžiui, ryšys, vadinamas „aoai“ su konkrečia API versija). Tai leidžia tam pačiam srautui vykdyti lokaliai ir debesyje be kodo pakeitimų.

Norėdami naudoti šį metodą, tiesiog sukurkite virtualią aplinką arba „conda“ ir įdiekite reikiamas priklausomybes („promptflow“, „promptflow-tools“, „promptflow-sdk“, „openai“, „jinja2“, „python-dotenv“ ir kt.). Iš ten galite rašyti testų scenarijus vietiniame vykdymo aplanke ir vykdyti eksperimentus su apibrėžtais srautais.

Šis debesijos ir vietinių sistemų dualumas puikiai atitinka brandžią „DevOps“ mąstyseną: nedidelio masto testavimas atliekamas vietoje, oficialus patvirtinimas atliekamas srautuose, o tada diegimas atliekamas didesnėse aplinkose su valdikliais ir auditu . Viskas versijuojama „Git“ ir prijungiama prie „Azure DevOps“.

Tipiniai įrankiai DevOps ekosistemoje su dirbtiniu intelektu ir LLMOps

Be konkretaus „Azure“ pasiūlymo, moderni „DevOps“ ekosistema su dirbtiniu intelektu ir LLMOps paprastai remiasi įrankių rinkiniu, apimančiu „ChatOps“, modelių orkestravimą, stebėjimą ir stebimumą.

„ChatOps“ sluoksnyje įprasta derinti „Slack“ su robotais, tokiais kaip „Hubot“ , „Microsoft Teams“ su agentais, pagrįstais „Power Virtual Agents“, arba „Discord“, kartu su tokiomis platformomis kaip „Botpress“ ar „Rasa“, siekiant sukurti pasirinktinius asistentus, kurie jungiasi prie srautų, stebėjimo sistemų ir vidinių paslaugų.

LLMOps/MLOps srityje tokios platformos kaip „Kubeflow“ ir „MLflow“ yra įprastos vamzdynų, modelių įrašų ir eksperimentų valdymui, be to, yra ir specialių įrankių, tokių kaip „Weights & Biases“ (W&B), skirtų pažangiam metrikų stebėjimui, paleidimo palyginimams ar išsamioms vizualizacijoms.

Kuriant programas LLM pagrindu, paprastai naudojamos tokios sistemos kaip „LangChain“ arba bibliotekos, tokios kaip „OpenLLM“ , kurios palengvina raginimų grandinių, jungčių su išoriniais duomenimis, įrankių ir daugiapakopių agentų surinkimą. Tuo pačiu metu atsiranda LLM būdingo stebimumo sprendimų, leidžiančių stebėti raginimus, atsakymus, išlaidas ir kokybę.

Integruojant su klasikinėmis „DevOps“, tokios priemonės kaip „Jenkins“ ar „GitLab CI“ išlieka aktualios CI/CD daliai, „Kubernetes“ ir „ArgoCD“ – nuolatiniam debesijos pagrindu veikiančiam diegimui , o stebimumo paketai, tokie kaip „Prometheus“, „Grafana“ ir „Loki“, – metrikoms, ataskaitų suvestinėms ir žurnalams.

Iššūkiai, apribojimai ir laipsniškas diegimas

Visas šis praktikų ir įrankių diegimas kainuoja. Raginimų, modelių versijų ir darbo eigos variantų valdymas yra gana sudėtingas, ypač kai vienu metu dirba kelios komandos – tokiu atveju tokios strategijos kaip „GitOps“ yra naudingos koordinuojant pakeitimus ir diegimus.

Be to, „ChatOps“ robotai ir LLM su praktinėmis galimybėmis kelia didelę saugumo riziką, jei jie turi pernelyg daug leidimų gamybos aplinkoje arba jei duomenų atskleidimo paviršiai nėra tinkamai kontroliuojami.

Be to, dar labiau pasikliovimas atvirojo kodo modeliais su jautriomis licencijomis arba komercinėmis API , kurios gali keisti sąlygas, kainas ar apribojimus. Dar blogiau, kad patikimas teisės magistro programų (LLM) vertinimas gamyboje lieka atviras klausimas, į kurį dar neatsakyta.

Todėl prasminga LLMOps ir ChatOps diegimą DevOps viduje vykdyti laipsniškai ir kontroliuojamai , pradedant nuo pasikartojančių užduočių automatizavimo naudojant paprastus robotus (perkrovimus, žurnalų užklausas, kompiliavimo žymėjimą ir kt.).

Vėliau LLM gali būti įdiegti palaikymo užduotims, incidentų klasifikavimui arba derinimo pagalbai , pavyzdžiui, klaidoms paaiškinti iš žurnalų arba siūlyti švelninimo priemones remiantis vidiniais dokumentais.

Kai klasikinė mašininio mokymosi (ML) veikla bus stabili, laikas imtis LLMOps su specializuotais kalbos modeliais tokiose srityse kaip klientų aptarnavimas, DevSecOps ar QA, pasinaudojant viskuo, kas išmokta ankstesniuose etapuose.

Visos šios praktikos siekia pokalbių, nuspėjamąją ir vis labiau autonominę inžinerinę aplinką , kurioje didelė dalis kūrimo ir veikimo išreiškiama natūralia kalba, o dirbtinis intelektas padeda priimti iniciatyvius sprendimus dėl diegimo, mastelio keitimo ar atšaukimų.

Sudėliojusios šią dėlionę – „DevOps“, „ChatOps“, „MLOps“, „GenAIOps“ ir „LLMOps“ – organizacijos turi tvirtą sistemą, skirtą kurti ir palaikyti LLM pagrįstas sistemas, kurios iš tiesų teikia vertę , išlaikant kokybės, sąnaudų, saugumo ir suderinamumo su verslu kontrolę, o ne lieka tik prototipais ar izoliuotais bandymais, kurie sugenda vos pasiekę gamybą.