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. Turėti gerų dalykų nebeužtenka. DevOps kanalai nei taikant klasikines MLOpsĮtraukus LLM į lygtį, patenkama į sritį, kurioje modelis kalba, samprotauja, improvizuoja ir kartais elgiasi nenuspėjamai.

Šiame naujame scenarijuje Komandos turi derinti „DevOps“, dirbtinį intelektą ir LLMOps, kad valdytų visą LLM pagrįstų programų gyvavimo ciklą.Nuo eksperimentavimo ir greito inžinerijos iki diegimo, stebėjimo, saugumo ir sąnaudų optimizavimo – šiame straipsnyje visa tai pateikiama praktiškai ir žingsnis po žingsnio paaiškinama, kaip pritaikyti „ChatOps“, „DevOps“, „MLOps“, „GenAIOps“ ir „LLMOps“ šiuolaikinėje veikloje.

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

Daugelį metų inžinierių komandų prioritetas buvo automatizuoti programinės įrangos tiekimą ir sumažinti trintį tarp plėtros ir infrastruktūrosTaip gimė „DevOps“: nuolatinė integracija, nuolatinis diegimas, infrastruktūra kaip kodas, stebimumas ir bendradarbiavimu grįsta kultūra, kuri panaikino nesibaigiantį perdavimą tarp skyrių.

Kai duomenys tapo produkto dalimi, jie išryškėjo MLOps kaip atsakas į mašininio mokymosi modelių atkuriamumo ir atsekamumo poreikįBuvo standartizuotos tokios praktikos kaip duomenų rinkinių versijų kūrimas, mokymo srauto orkestravimas, dreifo aptikimas ir nuolatinis prognozuojamųjų modelių vertinimas.

Problema ta LLM laužo 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, realiuoju laiku derina kontekstą, instrukcijas, įrankius ir duomenis ir gali sukurti du skirtingus tos pačios įvesties rezultatus.

Tai reiškia Nepakanka tiesiog pakeisti modelį ir jo svoriusTaip pat būtina kontroliuoti raginimus, šablonus, semantinio saugumo politikas, apribojimus, prijungtus įrankius, įterptą kontekstą ir net verslo taisykles, kurios sąlygoja sistemos elgesį.

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

LLMOps galime matyti kaip operacinė sistema, leidžianti saugiai, kontroliuojamai ir tvariai diegti, prižiūrėti ir plėsti LLM pagrįstas programasTai 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“ ir daugiau jo elgesio valdymui gamyboje.Tai apima, kaip kuriami ir versuojami greitieji srautai, kaip LLM yra prijungiami prie vidinių duomenų šaltinių, kaip stebimos žetonų kainos ir delsa, ir kaip valdoma semantinė rizika (haliucinacijos, informacijos nutekėjimas, šališkumas, toksinės reakcijos ir kt.).

Poreikiai, kuriuos tenkina LLMOps ir kurių neapima vien DevOps/MLOps, apima: tokie įvairūs aspektai kaip pokalbių atsekamumas, automatinis atsakymų kokybės vertinimas arba elgesio variantų A/B palyginimasKalbame ne tik apie klasikinį tikslumą, bet ir apie nuoseklumą, suderinamumą su verslu bei saugumą.

Be to, Išlaidos nebėra apsiribojamos modelio mokymu ir talpinimuKiekvienas 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 padarytų šį naudojimą matomą ir sujungtų jį su įranga, paslaugomis ir naudojimo atvejais, sąskaita auga nenuspėjamai.

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

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

„ChatOps“ siūlo, kad kasdienės operacijos (diegimai, žurnalų užklausos, perkrovimai, konfigūracijos pakeitimai) vykdomi robotų pačiame komunikacijos kanale, skaidriai visai komandai. Kiekviena komanda, veiksmas ir rezultatas įrašomi pokalbyje.

Kai prie šio požiūrio pridedama LLM, atsiranda naujas intelekto sluoksnis: Pokalbių robotai, suprantantys natūralią kalbą, interpretuojantys ketinimus ir galintys vykdyti sudėtingas komandas arba analizuoti situacijas operatoriui nereikia prisiminti kiekvieno tikslaus scenarijaus ar vėliavėlės.

Tipiški šio suartėjimo pavyzdžiai yra šie: Robotas, valdomas LLM, nuskaito „Prometheus“ metriką ir „Loki“ žurnalus Kai kas nors rašo „X grupės paslauga lėta“ ir siūlo tokius veiksmus kaip replikų eskalavimas, ankstesnių pakeitimų atlikimas arba konkrečių testų paleidimas, visa tai paaiškinama natūralia kalba.

Kultūriniu ir veiklos lygmeniu tai reiškia Greitesni sprendimai, mažiau rankinio įsikišimo į pasikartojančias užduotis ir sklandesnė „DevOps“ komandų patirtis, kurie nuo nuolatinio gaisrų gesinimo pereina prie darbo ties strateginiais patobulinimais.

Pagrindiniai LLM gyvavimo ciklo gamyboje principai

Rimtos LLM studijos nėra vienkartinis projektas, tai yra ciklas, kuris kartojasi ir kuriame kiekvienas pokytis gali pakeisti sistemos elgesįNors kiekviena organizacija pritaiko jį prie savo realybės, paprastai yra šeši pagrindiniai etapai, kurie vienas kitą papildo.

Pirmasis yra modelio mokymo arba adaptacijos etapasTai gali būti nuo bazinio modelio naudojimo iki tikslinimo, LoRa ar kitų tikslinimo metodų taikymo su savo duomenimis. Svarbu 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 valdymoVė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“ tai ne tik „įdėjimas į konteinerį“: Turime nuspręsti kokią įrangą naudotiKaip valdyti atmintį ilgai veikiančiuose kontekstuose, kurią klasterio topologiją taikyti ir kaip keisti mastelį pagal srautą be staigaus delsos padidėjimo ar neįperkamų išlaidų.

Štai čia ir prasideda dalykai nuolatinis į elgesį orientuotas stebėjimasNepakanka žiūrėti vien į procesoriaus ir operatyviosios atminties duomenis; būtina stebėti atsakymų semantinę kokybę, stiliaus stabilumą, klaidų dažnį, žetono kainos kitimą, pavojingų ar nenuoseklių atsakymų atsiradimą ir atsakymo laiko pokyčius esant skirtingiems naudojimo modeliams.

Vėlesniuose etapuose atliekamos optimizavimo ir tikslinimo užduotys: lietimo raginimus, RAG koregavimą, modelio variantų testavimą, kvantavimą, A/B testavimą, semantinio saugumo politikos keitimą arba verslo taisyklių patikslinimąTai beveik amatinis procesas, kai duomenys, inžinerija ir verslas kartu susėda, kad nuspręstų, kam teikti pirmenybę.

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

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

LLMOps srityje yra labai konkrečių pasiūlymų, kaip struktūrizuoti šį gyvavimo ciklą. Vienas pažangiausių verslo aplinkoje yra „GenAIOps“ su greitu srautu „Azure Machine Learning“ sistemoje, integruotoje su „Azure DevOps“, kuriame siūlomas labai sistemingas požiūris į LLM pagrindu sukurtų programų kūrimą.

Raginimų srautas nėra tik raginimų redaktorius; tai yra visavertė platforma LLM sąveikos srautų projektavimui, testavimui, versijų kūrimui ir diegimui, nuo paprastų atvejų (vienas raginimas) iki sudėtingų orkestruočių su keliais mazgais, išoriniais įrankiais, valdikliais ir automatiniais vertinimais.

Svarbus bruožas yra centralizuota srautų saugyklakuri veikia kaip įmonės biblioteka. Užuot kiekvienai komandai turėjus savo užduotis atskiruose dokumentuose ar savo saugyklose, jos yra sujungtos į 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 palyginkite rezultatus su aiškiais rodikliais.

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

Dar vienas privalumas yra duomenų rinkinių ir srautų ryšių valdymas. Kiekvienas vertinimo srautas gali veikti su keliais standartiniais ir bandymų duomenų rinkiniaisTai leidžia patvirtinti elgesį skirtinguose scenarijuose prieš pateikiant kažką galutiniams vartotojams.

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

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, sutelktas į Tiksliai apibrėžkite verslo tikslą ir surinkite reprezentatyvius duomenų pavyzdžiusČia apibrėžiama pagrindinė raginimų srauto struktūra ir suprojektuojama architektūra, kuri vėliau bus tobulinama.

Eksperimentavimo etape srautas taikomas tiems pavyzdiniams duomenims ir Įvertinami skirtingi raginimų, modelių ir konfigūracijų variantai.Procesas negailestingai kartojamas, kol randamas priimtinas derinys, atitinkantis minimalius kokybės ir nuoseklumo standartus.

Toliau seka vertinimo ir tobulinimo etapas, kuriame Didesni ir įvairesni duomenų rinkiniai naudojami atliekant griežtus lyginamuosius bandymusTik tada, kai srautas parodo nuoseklų veikimą, atitinkantį nustatytus standartus, jis laikomas paruoštu kitam žingsniui.

Galiausiai, diegimo etape srautas optimizuojamas, kad būtų efektyvus, ir diegiamas gamyboje. įskaitant A/B diegimo parinktis, stebėseną, vartotojų atsiliepimų rinkimą ir nuolatinio tobulinimo ciklusNiekas nėra galutinai nustatyta: srautas ir toliau koreguojamas atsižvelgiant į tai, kas stebima realiomis naudojimo sąlygomis.

Ši metodika yra supakuota į „GenAIOps“ saugyklos šabloną su iš anksto sukurtais, pirmiausia kodu paremtais srautais ir Vietiniai ir debesijos pagrindu veikiantys vykdymo įrankiai, skirti LLM pagrindu veikiančių programų kūrimui, vertinimui ir diegimui neišradinėjant dviračio kiekviename projekte 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 saugykla „Azure Repos“ platformoje su dviem pagrindinėmis šakomis: pagrindine ir kūrimo, kurie atspindi skirtingas aplinkas ir kodo reklamavimo strategijas.

Pavyzdinė saugykla yra klonuota iš „GitHub“, susieta su „Azure Repos“ ir Paprastai dirbame kurdami funkcijų šakas iš kūrimo.Pakeitimai siunčiami per užklausas, kurios automatiškai suaktyvina patvirtinimo ir eksperimentavimo procesus.

Kad „Azure DevOps“ galėtų sąveikauti su „Azure Machine Learning“ ir kitomis paslaugomis, ji sukonfigūruota paslaugos subjektas „Azure“ platformoje kaip techninė tapatybėŠi tapatybė naudojama „Azure DevOps“ paslaugos ryšyje, todėl srautai autentifikuojami neatskleidžiant raktų paprastojo teksto formatu.

Paprastai šis subjektas turi savininko teises ML prenumeratoje arba darbo ištekliuje, kad Vamzdynuose galima paruošti galinius taškus, registruoti modelius ir atnaujinti strategijas raktų saugyklose.Jei norite sustiprinti saugumą, galite pakeisti vaidmenį į Bendradarbis, pritaikydami YAML veiksmus, kurie tvarko teises.

Be to, „Azure DevOps“ sukuriama kintamųjų grupė, kuri Jame saugomi neskelbtini duomenys, pvz., paslaugos ryšio pavadinimas arba išteklių identifikatoriai.Šie kintamieji yra pateikiami kaip aplinka vamzdynams, vengiant svarbios informacijos įkodavimo kode.

Vietinių ir nuotolinių saugyklų konfigūravimas leidžia jums Kūrimo šaka yra apsaugota šakos politikomis kuriems prieš sujungimą reikia vykdyti užklausų srautą. Šis srautas tvarko kompiliavimo patvirtinimus ir eksperimentavimo srautus, neleisdamas įvesti neveikiančių pakeitimų.

Kai kodas patenka į kūrimo etapą, aktyvuojamas kūrimo srautas, kuris Tai apima visas CI ir CD fazes: eksperimentų ir vertinimų vykdymas, srautų įrašymas į „Azure“ ML modelio registrą, galinių taškų ir dūmų testų diegimas bei integravimas į naujai sukurtus galinius taškus.

Tas pats modelis pakartojamas visoje versijos ar leidimo šakoje, susietoje su gamybos aplinkomis. Ten, CI/CD gamybos vamzdynai kartoja eksperimentavimo, vertinimo ir diegimo ciklą.tačiau remiantis infrastruktūros ir gamybos lygio duomenimis, užtikrinant didesnę kontrolę ir, jei reikia, atliekant papildomas rankines peržiūras.

Svarbi detalė yra „žmogaus kilpos peržiūra“, įtraukta į šiuos vamzdynus: Po CI etapo kompaktinis diskas lieka užrakintas, kol asmuo jo rankiniu būdu patvirtina. Tęsinys atliekamas iš „Azure Pipelines“ sąsajos. Jei jis nepatvirtinamas per tam tikrą laiką (pvz., 60 minučių), vykdymas atmetamas.

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

Ne viskas sukasi apie vamzdynus: „GenAIOps“ taip pat palaiko vietinis vykdymas greitam eksperimentavimuiGalite klonuoti šablonų saugyklą, sukurti .env failą šakniniame kataloge ir apibrėžti ryšius su „Azure OpenAI“ arba kitais suderinamais galiniais taškais jame.

Šie ryšiai apima tokius parametrus kaip „api_key“, „api_base“, „api_type“ ir „api_version“, ir Srautuose jie nurodomi pavadinimais. (pavyzdžiui, ryšys, vadinamas „aoai“ su konkrečia API versija). Tokiu būdu tas pats srautas gali būti vykdomas lokaliai ir debesyje nekeičiant kodo.

Norėdami naudoti šį režimą, 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 / vietinės aplinkos dualumas labai gerai dera su brandžia „DevOps“ mąstysena: Jis išbandomas nedideliu mastu vietoje, oficialiai patvirtinamas gamybos srautuose, o tada perkeliamas į aukštesnio lygio aplinkas su valdikliais ir auditu.Viskas yra versijuojama „Git“ programoje ir prijungta 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ų rinkinys, apimantis „ChatOps“, modelių orkestravimą, stebėjimą ir stebimumą.

„ChatOps“ sluoksnyje įprasta derinti „Slack“ su robotais, tokiais kaip „Hubot“„Microsoft Teams“ bendradarbiauja su agentais, sukurtais „Power Virtual Agents“ arba „Discord“ pagrindu, kartu su tokiomis platformomis kaip „Botpress“ ar „Rasa“, kad sukurtų pritaikytus asistentus, kurie jungiasi prie srautų, stebėjimo sistemų ir vidinių paslaugų.

LLMOps/MLOps plotmėje jie yra dažni platformos, tokios kaip „Kubeflow“ ir „MLflow“ valdyti procesų eigą, modelių įrašus ir eksperimentus, taip pat specialius įrankius, tokius kaip svoriai ir paklaidos (W&B), skirtus pažangiam metrikų stebėjimui, paleidimo palyginimams ar išsamioms vizualizacijoms.

Kuriant programas LLM pagrindu, įprasta naudoti tokios sistemos kaip „LangChain“ arba „OpenLLM“ tipo bibliotekosŠie sprendimai palengvina raginimų grandinių, jungčių su išoriniais duomenimis, įrankių ir daugiapakopių agentų surinkimą. Tuo pačiu metu atsiranda LLM specifinio stebimumo sprendimai, leidžiantys stebėti raginimus, atsakymus, sąnaudas ir kokybę.

Integruojant su klasikiniu DevOps, tokie įrankiai kaip „Jenkins“ ar „GitLab CI“ išlieka aktualūs CI/CD daliai. „Kubernetes“ ir „ArgoCD“ – nuolatinis debesijos pagrindu veikiančių technologijų diegimasir stebimumo paketus, tokius kaip „Prometheus“, „Grafana“ ir „Loki“, skirtus metrikoms, ataskaitų suvestinėms ir žurnalams.

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

Visas šis praktikų ir įrankių diegimas neatsiranda veltui. Raginimų, modelių versijų ir srauto variantų valdymo sudėtingumas yra nemažas, ypač kai kelios komandos dirba vienu metu — scenarijus, kai patartina taikyti strategijos, tokios kaip „GitOps“ koordinuoti pakeitimus ir diegimus.

Be to, „ChatOps“ robotai ir patys teisės magistro (LLM) specialistai, turintys veiksmų galią Jie kelia didelę saugumo riziką jei jie turi pernelyg daug leidimų gamybos aplinkoje arba jei duomenų atskleidimo paviršiai nėra tinkamai kontroliuojami.

Prie to pridedama ir priklausomybė nuo atvirojo kodo modelių su jautriomis licencijomis arba komercinėmis API o tai gali pakeisti sąlygas, kainas ar apribojimus. Ir, dar blogiau, patikimas teisės magistro studijų programų (LLM) įvertinimas gamyboje lieka atviras klausimas, į kurį dar nėra atsakyta.

Todėl prasminga spręsti LLMOps ir ChatOps diegimo DevOps kontekste klausimą. progresyviu ir kontroliuojamu būdu, pradedant nuo pasikartojančių užduočių automatizavimo naudojant paprastus robotus (perkrovimai, žurnalų užklausos, kompiliavimo žymėjimas ir kt.).

Vėliau juos galima pristatyti LLM palaikymo užduotims, incidentų klasifikavimui arba derinimo pagalbaiPavyzdžiui, paaiškinant klaidas remiantis žurnalais arba siūlant priemones jų mažinimui remiantis vidiniais dokumentais.

Kai klasikinė ML operacija bus stabili, laikas spręsti LLMOp su specializuotais kalbos modeliais tokiose srityse kaip klientų aptarnavimas, „DevSecOps“ ar kokybės užtikrinimas, pasinaudojant viskuo, ko išmokta ankstesniuose etapuose.

Horizontas, į kurį nukreipta visa ši praktika, yra pokalbių, nuspėjamoji ir vis labiau autonominė inžinerinė aplinkakur didelė kūrimo ir veikimo dalis 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 tvirtas pagrindas kurti ir palaikyti LLM pagrįstas sistemas, kurios iš tiesų teikia vertęIšlaikyti kokybės, sąnaudų, saugos ir suderinamumo su verslu kontrolę, užuot pasilikus ties paprastais prototipais ar izoliuotais bandymais, kurie sugenda vos pasiekę gamybą.