DevOps ar mākslīgo intelektu un LLMOps: no cauruļvada līdz modelim, kas runā

Informatec Digital » Resursi » DevOps ar mākslīgo intelektu un LLMOps: no cauruļvada līdz modelim, kas runā

Ģeneratīvā mākslīgā intelekta un lielo valodu modeļu ienākšana ir pilnībā mainījusi programmatūras veidošanas, ieviešanas un darbības veidu. Vairs nepietiek tikai ar labiem DevOps cauruļvadiem vai klasisko MLOps pielietošanu : ieviešot vienādojumā LLM, jūs nonākat sfērā, kurā modelis runā, argumentē, improvizē un dažreiz uzvedas neparedzamā veidā.

Šajā jaunajā ainavā komandām ir jāapvieno DevOps, mākslīgais intelekts un LLMOps, lai pārvaldītu visu uz LLM balstītu lietojumprogrammu dzīves ciklu , sākot no eksperimentēšanas un ātras izstrādes līdz ieviešanai, uzraudzībai, drošībai un izmaksu optimizācijai. Šajā rakstā ir paskaidrots sarežģītības līmenis un soli pa solim sniegta informācija par to, kā integrēt ChatOps, DevOps, MLOps, GenAIOps un LLMOps mūsdienīgā darbībā.

No DevOps un MLOps līdz LLMOps: kāpēc modelis vairs nav statisks

Gadiem ilgi inženieru komandas prioritāti piešķīra programmatūras piegādes automatizācijai un berzes mazināšanai starp izstrādi un infrastruktūru . Tas noveda pie DevOps dzimšanas: nepārtraukta integrācija, nepārtraukta izvietošana, infrastruktūra kā kods, novērojamība un sadarbības kultūra, kas novērsa nebeidzamu nodošanu starp nodaļām.

Kad dati kļuva par produkta daļu, MLOps radās kā atbilde uz nepieciešamību pēc mašīnmācīšanās modeļu reproducējamības un izsekojamības . Tika standartizētas tādas prakses kā datu kopu versiju veidošana, apmācību cauruļvada orķestrēšana, nobīdes noteikšana un paredzošo modeļu nepārtraukta novērtēšana.

Problēma ir tā, ka LLMs (līmeņa maģistra metodes) pārkāpj daudzus DevOps un MLOps netiešos pieņēmumus . Tie nav statiski API vai vienkāršas funkcijas, kas atgriež deterministisku skaitli: tie atbild dabiskā valodā, apvieno kontekstu, instrukcijas, rīkus un reāllaika datus un var ģenerēt divas dažādas izejas vienai un tai pašai ievadei.

Tas nozīmē, ka nepietiek tikai ar modeļa un tā svaru versiju veidošanu ; ir jākontrolē arī uzvednes, veidnes, semantiskās drošības politikas, ierobežojumi, pievienotie rīki, ievadītais konteksts un pat biznesa noteikumi, kas nosaka sistēmas darbību.

Kas ir LLMOps un ko tas īsti risina?

Mēs varam uzskatīt LLMOps par darbības ietvaru, kas nodrošina drošu, kontrolētu un ilgtspējīgu uz LLM balstītu lietojumprogrammu izvietošanu, uzturēšanu un mērogošanu . Tas ir jumts, zem kura līdzās pastāv DevOps prakses, MLOps un jaunas iespējas, kas raksturīgas ģeneratīvajiem modeļiem.

Būtībā LLMOps mazāk koncentrējas uz "ideālā modeļa apmācību" un vairāk uz tā uzvedības pārvaldību ražošanas vidē . Tas ietver to, kā tiek izstrādātas un versijas ģenerētas ātrās plūsmas, kā LLM izveido savienojumu ar iekšējiem datu avotiem, kā tiek uzraudzītas marķieru izmaksas un latentums, un kā tiek pārvaldīts semantiskais risks (halucinācijas, informācijas noplūdes, aizspriedumi, toksiskas reakcijas utt.).

Vajadzības, kuras risina LLMOps un kuras DevOps/MLOps vien nevar aptvert, ietver tādus dažādus aspektus kā sarunu izsekojamība, atbilžu kvalitātes automātiska novērtēšana un uzvedības variantu A/B testēšana . Mēs nerunājam tikai par klasisko precizitāti, bet arī par konsekvenci, atbilstību uzņēmuma vajadzībām un drošību.

Turklāt izmaksas vairs neaprobežojas tikai ar modeļa apmācību un mitināšanu : katra uzvedne, katrs paplašinātais konteksts un katrs vienlaicīgs izsaukums aktivizē GPU vai tokena patēriņu komerciālajās API. Bez LLMOps slāņa, kas padarītu šos izdevumus redzamus un savienotu tos ar aprīkojumu, pakalpojumiem un lietošanas gadījumiem, rēķins pieaugs neparedzami.

ChatOps + LLMOps + DevOps: darbības kļūst par sarunvalodas procesu

Viena no spēcīgākajām tendencēm ir ChatOps un LLMOps integrācija DevOps kultūrā . Komandas vairs neaprobežojas tikai ar informācijas paneļiem, skriptiem un cauruļvadiem, bet sāk pārvaldīt ievērojamu sistēmas daļu, izmantojot tērzēšanas kanālus, piemēram, Slack, Microsoft Teams vai Discord.

ChatOps ierosina, ka ikdienas darbības (izvietošana, žurnālu vaicājumi, pārstartēšana, konfigurācijas izmaiņas) veic boti pašā komunikācijas kanālā , caurspīdīgi visai komandai. Katra komanda, darbība un rezultāts tiek ierakstīts sarunā.

Kad šai pieejai pievieno LLM, parādās jauns intelekta slānis: tērzēšanas roboti, kas saprot dabisko valodu, interpretē nodomus un var aktivizēt sarežģītas komandas vai analizēt situācijas, operatoram neatceroties katru precīzu skriptu vai karodziņu.

Tipiski šīs konverģences piemēri ir bots, ko darbina LLM, kas nolasa metrikas no Prometheus un žurnālus no Loki, kad kāds ieraksta "X grupas pakalpojums ir lēns", un iesaka tādas darbības kā repliku mērogošana, atcelšanas veikšana vai noteiktu testu palaišana, kas viss ir izskaidrots dabiskā valodā.

Kultūras un operacionālā līmenī tas nozīmē ātrāku lēmumu pieņemšanu, mazāku manuālu iejaukšanos atkārtotos uzdevumos un vienmērīgāku pieredzi DevOps komandām , kuras no pastāvīgas ugunsgrēku dzēšanas pāriet uz darbu pie stratēģiskiem uzlabojumiem.

LLM dzīves cikla galvenie principi ražošanā

Nopietnas LLM programmas vadīšana nav vienreizējs projekts; tas ir atkārtots cikls, kurā katras izmaiņas var mainīt sistēmas darbību . Lai gan katra organizācija to pielāgo savai realitātei, parasti ir seši galvenie, pašpastiprinošie posmi.

Pirmais posms ir modeļa apmācība jeb adaptācija , kas var ietvert gan pamata modeļa izmantošanu, gan precizēšanas, LoRa vai citu pielāgošanas metožu pielietošanu ar saviem datiem. Šeit svarīga ir ne tikai veiktspēja, bet arī pilnīga ieraksta atstāšana: datu kopas, piemērotie filtri, hiperparametri, tokenizeru versijas, testētās arhitektūras utt.

Ja šī fāze tiek improvizēta un netiek dokumentēta, modelis rodas bez pārvaldības . Pēc tam būs gandrīz neiespējami izskaidrot, kāpēc tas reaģē tā, kā reaģē, vai atkārtot konkrētu rezultātu, kad tas nepieciešams auditā.

Otrais posms ir izvietošana, kurā modelis atstāj laboratoriju un nonāk ražošanas vidē. LLMOps gadījumā tas nav tikai par "ievietošanu konteinerā": jums ir jāizlemj , kādu aparatūru izmantot , kā pārvaldīt atmiņu ilgstošas ​​darbības kontekstos, kādu klastera topoloģiju lietot un kā mērogot atbilstoši datplūsmai, lai latentums nepalielinātos strauji vai izmaksas nekļūst nekontrolējamas.

Pēc tam tiek veikta nepārtraukta, uz uzvedību orientēta uzraudzība . Nepietiek tikai aplūkot centrālā procesora un operatīvās atmiņas izmantošanu; ir jāuzrauga atbilžu semantiskā kvalitāte, stila stabilitāte, kļūdu līmenis, tokena izmaksu attīstība, bīstamu vai nekonsekventu atbilžu parādīšanās un reakcijas laiku izmaiņas dažādos lietošanas modeļos.

Vēlākajos posmos tiek veikti optimizācijas un precizēšanas uzdevumi: uzdevumu pielāgošana, RAG pielāgošana, modeļu variantu testēšana, kvantēšana, A/B testēšanas veikšana, semantiskās drošības politikas maiņa vai biznesa noteikumu pilnveidošana . Tas ir gandrīz amatniecisks process, kurā dati, inženierija un bizness apvienojas, lai noteiktu prioritātes.

Visbeidzot, tas viss ir ietverts drošības un pārvaldības līmeņos (piekļuves kontrole, auditēšana, noplūžu novēršana, lietošanas ierobežojumi, atbilstība normatīvajiem aktiem) un nepārtrauktas atjaunināšanas loģikā, kur modelis un tā ekosistēma tiek pielāgoti datu, noteikumu un iekšējo vajadzību izmaiņām.

GenAIOps un paziņojumu plūsmas pieeja pakalpojumā Azure

LLMOps pasaulē ir ļoti specifiski priekšlikumi šī dzīves cikla strukturēšanai. Viens no vismodernākajiem korporatīvajā vidē ir GenAIOps ar tūlītējām plūsmām Azure Machine Learning platformā, kas integrēta ar Azure DevOps , kas piedāvā ļoti sistemātisku pieeju LLM balstītu lietojumprogrammu veidošanai.

Uzvedņu plūsma nav tikai uzvedņu redaktors; tā ir pilnīga platforma LLM mijiedarbības plūsmu projektēšanai, testēšanai, versiju veidošanai un izvietošanai , sākot no vienkāršiem gadījumiem (viena uzvedne) līdz sarežģītām orķestrācijām ar vairākiem mezgliem, ārējiem rīkiem, vadības ierīcēm un automatizētiem novērtējumiem.

Svarīga funkcija ir centralizētā darbplūsmas krātuve , kas darbojas kā korporatīvā bibliotēka. Tā vietā, lai katra komanda glabātu savas uzvednes atsevišķos dokumentos vai savos krātuvēs, tās ir apvienotas vienā pārvaldītā krātuvē ar skaidrām atzarām, pārskatījumiem un vēsturi.

Turklāt platforma pievieno variantu un hiperparametru eksperimentēšanas iespējas: ir iespējams pārbaudīt dažādas uzvedņu, modeļu, temperatūras iestatījumu vai drošības politiku kombinācijas vairākos plūsmas mezglos un salīdzināt rezultātus ar skaidriem rādītājiem.

Runājot par izvietošanu, GenAIOps ar paziņojumu plūsmu ģenerē Docker attēlus, kas ietver gan plūsmu, gan procesa sesiju , un ir gatavi darbināšanai tādās vidēs kā Azure App Services, Kubernetes vai pārvaldītos procesos. Pamatojoties uz to, A/B izvietojumi ir iespējoti, lai salīdzinātu plūsmas versijas reālās pasaules vidēs.

Vēl viena priekšrocība ir datu kopu un plūsmu savstarpējo attiecību pārvaldība. Katra novērtēšanas plūsma var strādāt ar vairākām standarta un testa datu kopām , ļaujot validēt uzvedību dažādos scenārijos, pirms kaut kas tiek nodots gala lietotāju rokās.

Platforma arī automātiski reģistrē jaunas datu kopu un plūsmu versijas tikai tad, ja notiek faktiskas izmaiņas, un ģenerē visaptverošus pārskatus tādos formātos kā CSV un HTML, lai atbalstītu uz datiem balstītus lēmumus, nevis intuīciju.

GenAIOps četras fāzes ar paziņojumu plūsmu

GenAIOps pieeja sadala dzīves ciklu četros skaidri diferencētos posmos, kas palīdz izvairīties no tipiskā haosa "mēs izmēģinām lietas ar mākslīgo intelektu un redzam, kas notiek".

Pirmajā fāzē, inicializēšanā, galvenā uzmanība tiek pievērsta precīzai biznesa mērķa definēšanai un reprezentatīvu datu piemēru apkopošanai . Šeit tiek ieskicēta uzvednes plūsmas pamatstruktūra un izstrādāta arhitektūra, kas pēc tam tiks pilnveidota.

Eksperimenta fāzē plūsma tiek piemērota šiem parauga datiem, un tiek novērtētas dažādas uzvedņu, modeļu un konfigurāciju variācijas . Iterācija turpinās, līdz tiek atrasta pieņemama kombinācija, kas atbilst minimālajām kvalitātes un konsekvences prasībām.

Tālāk seko novērtēšanas un pilnveidošanas fāze, kurā stingrai salīdzinošai novērtēšanai tiek izmantoti lielāki un daudzveidīgāki datu kopumi . Tikai tad, kad plūsma uzrāda konsekventu veiktspēju, kas atbilst noteiktajiem standartiem, tā tiek uzskatīta par gatavu nākamajam solim.

Visbeidzot, ieviešanas fāzē darbplūsma tiek optimizēta efektivitātei un ieviesta ražošanā, tostarp A/B testēšana, uzraudzība, lietotāju atsauksmes un nepārtrauktas uzlabošanas cikli . Nekas nekad nav pilnībā pabeigts: darbplūsma tiek pastāvīgi pielāgota, pamatojoties uz reālās pasaules lietošanas novērojumiem.

Šī metodoloģija ir iepakota GenAIOps repozitorija veidnē ar iepriekš izstrādātiem, kodā balstītiem cauruļvadiem un lokāliem un mākonī balstītiem izpildes rīkiem, lai izstrādātu, novērtētu un palaistu LLM balstītas lietojumprogrammas, neizgudrojot riteni katram projektam no jauna.

Integrācija ar Azure DevOps: repozitoriji, cauruļvadi un autentifikācija

Lai GenAIOps no teorijas ieviestu reālā organizācijā, ir svarīgi to integrēt ar Azure DevOps. Tipiska veidne sākas ar repozitoriju Azure Repos ar divām galvenajām atzarām — galveno un izstrādes —, kas atspoguļo dažādas vides un koda reklamēšanas stratēģijas.

Parauga repozitorijs tiek klonēts no GitHub, saistīts ar Azure Repos, un parastā darbplūsma ietver funkciju atzaru izveidi no izstrādes direktorijas . Pēc tam izmaiņas tiek nosūtītas, izmantojot pull pieprasījumus, kas automātiski aktivizē validācijas un eksperimentu plūsmas.

Lai Azure DevOps varētu mijiedarboties ar Azure Machine Learning un citiem pakalpojumiem, pakalpojuma vadītājs pakalpojumā Azure tiek konfigurēts kā tehniskā identitāte . Šī identitāte tiek izmantota Azure DevOps pakalpojuma savienojumā, ļaujot cauruļvadiem autentificēties, neatklājot skaidras atslēgas.

Parasti šai entītijai ir īpašnieka atļaujas ML abonementā vai darbinieka resursā, kas ļauj cauruļvadiem nodrošināt galapunktus, reģistrēt modeļus un atjaunināt politikas atslēgu krātuvēs . Lai uzlabotu drošību, to var mainīt uz līdzstrādnieka lomu, modificējot YAML darbības, kas apstrādā atļaujas.

Turklāt Azure DevOps tiek izveidota mainīgo grupa, kurā tiek glabāti sensitīvi dati, piemēram, pakalpojuma savienojuma nosaukums vai resursu identifikatori . Šie mainīgie ir pieejami cauruļvadiem kā videi, tādējādi izvairoties no nepieciešamības kodā iekodēt kritisku informāciju.

Konfigurējot lokālos un attālos repozitorijus, izstrādes filiāli var aizsargāt ar filiāles politikām , kurām pirms apvienošanas ir jādarbojas pieprasījuma plūsmas apstrādei. Šī filiāle apstrādā būvēšanas validācijas un eksperimentu plūsmas, novēršot bojātu izmaiņu ieviešanu.

Kad kods nonāk izstrādes stadijā, tiek aktivizēta izstrādes plūsma, kas ietver pilnīgas CI un CD fāzes : eksperimentu un novērtējumu veikšanu, plūsmu reģistrēšanu Azure ML modeļa reģistrā, galapunktu un dūmu testu izvietošanu, kā arī integrēšanu jaunizveidotajos galapunktos.

Tas pats modelis tiek replicēts uz versijas vai laidiena atzaru, kas ir savienots ar ražošanas vidēm. Tur CI/CD cauruļvadi ražošanai atkārto eksperimentēšanas, novērtēšanas un izvietošanas ciklu , bet ražošanas līmeņa infrastruktūrā un datos, ar lielāku kontroli un papildu manuālām pārskatīšanām, ja nepieciešams.

Galvenā iezīme ir šajos cauruļvados iekļautā "cilpas cilvēka pārskatīšana": pēc CI fāzes izpildes process tiek bloķēts, līdz persona manuāli apstiprina izpildes turpināšanu no Azure cauruļvadu saskarnes. Ja tas netiek apstiprināts noteiktā laikā (piemēram, 60 minūtēs), izpilde tiek noraidīta.

Vietējā ieviešana un saikne ar LLM sniedzējiem

Ne viss notiek caur cauruļvadiem: GenAIOps atbalsta arī lokālu izpildi ātrai eksperimentēšanai . Varat klonēt veidņu krātuvi, izveidot .env failu saknes direktorijā un definēt savienojumus ar Azure OpenAI vai citiem saderīgiem galapunktiem tajā.

Šie savienojumi ietver tādus parametrus kā api_key, api_base, api_type un api_version, un uz tiem plūsmās atsaucas pēc nosaukuma (piemēram, savienojums ar nosaukumu "aoai" ar noteiktu API versiju). Tas ļauj vienai un tai pašai plūsmai darboties gan lokāli, gan mākonī bez koda izmaiņām.

Lai izmantotu šo metodi, vienkārši izveidojiet virtuālu vidi jeb conda un instalējiet nepieciešamās atkarības (promptflow, promptflow-tools, promptflow-sdk, openai, jinja2, python-dotenv utt.). No turienes varat rakstīt testa skriptus lokālā izpildes mapē un palaist eksperimentus ar definētajām plūsmām.

Šī mākoņa/lokālās vides dualitāte lieliski atbilst nobriedušai DevOps domāšanas veidam: maza mēroga testēšana tiek veikta lokāli, formāla validācija tiek veikta cauruļvados, un pēc tam izvietošana tiek veikta lielākās vidēs ar vadīklām un auditu . Viss tiek versēts Git un savienots ar Azure DevOps.

Tipiski rīki DevOps ekosistēmā ar mākslīgo intelektu un LLMOps

Papildus Azure konkrētajam priekšlikumam, mūsdienīga DevOps ekosistēma ar mākslīgo intelektu un LLMOps parasti balstās uz rīku kopumu, kas aptver ChatOps, modeļu orķestrēšanu, uzraudzību un novērojamību.

ChatOps slānī ir ierasts apvienot Slack ar tādiem robotiem kā Hubot , Microsoft Teams ar aģentiem, kuru pamatā ir Power Virtual Agents, vai Discord, kā arī ar tādām sistēmām kā Botpress vai Rasa, lai izveidotu pielāgotus asistentus, kas savienojas ar cauruļvadiem, uzraudzības sistēmām un iekšējiem pakalpojumiem.

LLMOps/MLOps jomā tādas platformas kā Kubeflow un MLflow ir izplatītas cauruļvadu, modeļu ierakstu un eksperimentu pārvaldībai, kā arī specifiski rīki, piemēram, Weights & Biases (W&B) uzlabotai metriku izsekošanai, salīdzināšanai vai padziļinātām vizualizācijām.

Lietojumprogrammu veidošana, izmantojot LLM, parasti ietver tādu ietvaru kā LangChain vai tādu bibliotēku kā OpenLLM izmantošanu , kas atvieglo uzdevumu ķēžu, savienotāju ar ārējiem datiem, rīku un daudzpakāpju aģentu izveidi. Vienlaikus parādās risinājumi LLM specifiskai novērojamībai, kas ļauj uzraudzīt uzdevumus, atbildes, izmaksas un kvalitāti.

Integrācijā ar klasisko DevOps, tādi rīki kā Jenkins vai GitLab CI joprojām ir aktuāli CI/CD daļai, Kubernetes un ArgoCD nepārtrauktai izvietošanai mākonī , bet novērojamības steki, piemēram, Prometheus, Grafana un Loki, — metrikai, informācijas paneļiem un žurnāliem.

Izaicinājumi, ierobežojumi un pakāpeniska ieviešana

Visa šī prakšu un rīku ieviešana nenāk bez maksas. Uzvedņu, modeļu versiju un darbplūsmas variantu pārvaldības sarežģītība ir ievērojama, īpaši, ja vienlaikus strādā vairākas komandas — scenārijs, kurā tādas stratēģijas kā GitOps ir noderīgas izmaiņu un izvietošanas koordinēšanai.

Turklāt ChatOps roboti un LLM ar praktiski izmantojamām iespējām rada ievērojamus drošības riskus , ja tiem ir pārmērīgas atļaujas ražošanas vidē vai ja datu iedarbības virsmas netiek pienācīgi kontrolētas.

Turklāt pastāv atkarība no atvērtā pirmkoda modeļiem ar sensitīvām licencēm vai komerciālām API , kas var mainīt noteikumus, cenas vai ierobežojumus. Un, vēl ļaunāk, tiesību zinātņu (LLM) stabila novērtēšana ražošanā joprojām ir atklāta joma, un daudzi jautājumi joprojām nav atbildēti.

Tāpēc ir lietderīgi LLMOps un ChatOps ieviešanu DevOps ietvaros veikt pakāpeniski un kontrolēti , sākot ar atkārtotu uzdevumu automatizāciju ar vienkāršiem robotiem (pārstartēšana, žurnālu vaicājumi, būvējumu atzīmēšana utt.).

Vēlāk LLM var ieviest atbalsta uzdevumiem, incidentu klasifikācijai vai atkļūdošanas palīdzībai , piemēram, lai izskaidrotu žurnālos atrastās kļūdas vai ieteiktu mazināšanas pasākumus, pamatojoties uz iekšējo dokumentāciju.

Kad klasiskā mašīnmācīšanās darbība ir stabilizēta, ir pienācis laiks ķerties pie LLMOps ar specializētiem valodu modeļiem tādām jomām kā klientu apkalpošana, DevSecOps vai QA, izmantojot visu iepriekšējos posmos apgūto.

Horizonts, uz kuru norāda visas šīs prakses, ir sarunvalodas, paredzoša un arvien autonomāka inženiertehniskā vide , kurā liela daļa izstrādes un darbības tiek izteikta dabiskajā valodā un mākslīgais intelekts palīdz pieņemt proaktīvus lēmumus par izvietošanu, mērogošanu vai atcelšanu.

Ar šo mīklu — DevOps, ChatOps, MLOps, GenAIOps un LLMOps — organizācijām ir stabils ietvars, lai izveidotu un uzturētu uz LLM balstītas sistēmas, kas patiesi sniedz vērtību , saglabājot kontroli pār kvalitāti, izmaksām, drošību un saskaņotību ar uzņēmējdarbību, nevis paliekot pie tikai prototipiem vai atsevišķiem testiem, kas sabrūk, tiklīdz nonāk ražošanā.