DevOps med AI og LLMOps: fra pipeline til model, der taler

Informatic Digital » Recursos » DevOps med AI og LLMOps: fra pipeline til model, der taler

Fremkomsten af ​​generativ AI og store sprogmodeller har fuldstændig ændret, hvordan software bygges, implementeres og drives. Det er ikke længere nok at have gode DevOps-pipelines eller anvende klassiske MLOps : når man introducerer en LLM i ligningen, træder man ind i et område, hvor modellen taler, ræsonnerer, improviserer og nogle gange opfører sig på uforudsigelige måder.

I dette nye landskab er teams nødt til at kombinere DevOps, AI og LLMOps for at styre hele livscyklussen for LLM-baserede applikationer , fra eksperimentering og prompt engineering til implementering, overvågning, sikkerhed og omkostningsoptimering. Denne artikel afklarer kompleksiteten og gennemgår trin for trin, hvordan du integrerer ChatOps, DevOps, MLOps, GenAIOps og LLMOps i en moderne drift.

Fra DevOps og MLOps til LLMOps: hvorfor modellen ikke længere er statisk

I årevis prioriterede ingeniørteams automatisering af softwarelevering og reduktion af friktion mellem udvikling og infrastruktur . Dette førte til fødslen af ​​DevOps: kontinuerlig integration, kontinuerlig implementering, infrastruktur som kode, observerbarhed og en samarbejdskultur, der eliminerede endeløse overdragelser mellem afdelinger.

Da data blev en del af produktet, opstod MLOps som et svar på behovet for reproducerbarhed og sporbarhed af maskinlæringsmodeller . Praksisser som versionsstyring af datasæt, orkestrering af træningspipelines, driftdetektion og løbende evaluering af prædiktive modeller blev standardiseret.

Problemet er, at LLM'er bryder med mange af de antagelser, der er implicitte i DevOps og MLOps . De er ikke statiske API'er eller simple funktioner, der returnerer et deterministisk tal: de reagerer i naturligt sprog, blander kontekst, instruktioner, værktøjer og realtidsdata og kan producere to forskellige output for det samme input.

Det betyder, at det ikke er nok at versionere modellen og dens vægte ; det er også nødvendigt at kontrollere prompts, skabeloner, semantiske sikkerhedspolitikker, begrænsninger, forbundne værktøjer, den injicerede kontekst og endda de forretningsregler, der styrer systemets adfærd.

Hvad er LLMOps, og hvad løser det egentlig?

Vi kan se LLMOps som det operationelle rammeværk, der muliggør sikker, kontrolleret og bæredygtig implementering, vedligeholdelse og skalering af LLM-baserede applikationer . Det er en paraply, under hvilken DevOps-praksisser, MLOps og nye funktioner specifikke for generative modeller sameksisterer.

I bund og grund fokuserer LLMOps mindre på at "træne den perfekte model" og mere på at styre dens adfærd i produktion . Dette inkluderer, hvordan prompt flows designes og versioneres, hvordan LLM'er forbinder til interne datakilder, hvordan tokenomkostninger og latenstid overvåges, og hvordan semantisk risiko (hallucinationer, informationslækager, bias, toksiske reaktioner osv.) håndteres.

De behov, som LLMOps imødekommer, og som DevOps/MLOps alene ikke kan dække, omfatter aspekter så forskellige som sporbarhed af samtaler, automatisk evaluering af svarkvalitet og A/B-test af adfærdsvarianter . Vi taler ikke kun om klassisk nøjagtighed, men også konsistens, tilpasning til forretningen og sikkerhed.

Derudover er omkostningerne ikke længere begrænset til modeltræning og hosting : hver prompt, hver udvidet kontekst og hvert samtidige kald udløser GPU- eller tokenforbrug på kommercielle API'er. Uden et LLMOps-lag til at synliggøre disse udgifter og forbinde dem til udstyr, tjenester og use cases, vokser regningen uforudsigeligt.

ChatOps + LLMOps + DevOps: operationer bliver konversationelle

En af de mest kraftfulde tendenser er integrationen af ​​ChatOps og LLMOps i DevOps-kulturen . I stedet for at være begrænset til dashboards, scripts og pipelines, er teams begyndt at betjene en betydelig del af systemet via chatkanaler som Slack, Microsoft Teams eller Discord.

ChatOps foreslår, at daglige operationer (implementeringer, logforespørgsler, genstarter, konfigurationsændringer) udføres af bots i selve kommunikationskanalen , transparent for hele teamet. Hver kommando, handling og resultat registreres i samtalen.

Når en LLM tilføjes til den tilgang, dukker et nyt lag af intelligens op: chatbots, der forstår naturligt sprog, fortolker intentioner og kan udløse komplekse kommandoer eller analysere situationer uden at operatøren behøver at huske hvert nøjagtige script eller flag.

Typiske eksempler på denne konvergens inkluderer en bot, drevet af en LLM, der læser metrikker fra Prometheus og logs fra Loki, når nogen skriver "tjenesten i gruppe X er langsom", og foreslår handlinger som at skalere replikaer, foretage en rollback eller starte specifikke tests, alt sammen forklaret i naturligt sprog.

På et kulturelt og operationelt niveau betyder dette hurtigere beslutninger, mindre manuel indgriben i gentagne opgaver og en mere problemfri oplevelse for DevOps-teams , der går fra konstant at slukke brande til at arbejde på strategiske forbedringer.

Nøgleprincipper for en LLM-livscyklus i produktion

At drive et seriøst LLM-program er ikke et engangsprojekt; det er en tilbagevendende cyklus, hvor enhver ændring kan ændre systemets adfærd . Mens hver organisation tilpasser det til sin egen virkelighed, er der typisk seks store, selvforstærkende faser.

Den første fase er modeltræning eller -tilpasning , som kan variere fra at bruge en grundlæggende model som den er til at anvende finjustering, LoRa eller andre tuningteknikker med dine egne data. Her er det vigtige ikke kun ydeevne, men også at efterlade en komplet registrering: datasæt, anvendte filtre, hyperparametre, tokenizer-versioner, testede arkitekturer osv.

Hvis denne fase improviseres og ikke dokumenteres, fødes modellen uden governance . Bagefter vil det være næsten umuligt at forklare, hvorfor den reagerer, som den gør, eller at replikere et specifikt resultat, når det er nødvendigt i en revision.

Den anden fase er implementering, hvor modellen forlader laboratoriet og går i produktion. I LLMOps handler det ikke bare om at "lægge den i en container": du skal beslutte, hvilken hardware der skal bruges , hvordan du administrerer hukommelse til langvarige kontekster, hvilken klyngetopologi der skal anvendes, og hvordan du skalerer i henhold til trafik uden at latensen stiger voldsomt, eller omkostningerne bliver uhåndterlige.

Derfra kommer kontinuerlig adfærdsorienteret overvågning i spil . Det er ikke nok blot at se på CPU- og RAM-forbruget; det er nødvendigt at overvåge den semantiske kvalitet af svar, stilens stabilitet, fejlraten, udviklingen af ​​omkostningerne pr. token, forekomsten af ​​farlige eller inkonsistente svar og ændringer i svartider under forskellige brugsmønstre.

I senere faser udføres optimerings- og finjusteringsopgaver: justering af prompts, justering af RAG, test af modelvarianter, kvantisering, udførelse af A/B-test, ændring af semantiske sikkerhedspolitikker eller forfining af forretningsregler . Det er en næsten håndværksmæssig proces, hvor data, engineering og forretning går sammen om at beslutte prioriteter.

Endelig er alt dette indrammet inden for lag af sikkerhed og styring (adgangskontrol, revision, lækageforebyggelse, brugsgrænser, overholdelse af lovgivningen) og inden for en logik med løbende opdatering, hvor modellen og dens økosystem tilpasses ændringer i data, regler og interne behov.

GenAIOps og notifikationsflowtilgangen i Azure

Inden for LLMOps-universet er der meget specifikke forslag til strukturering af denne livscyklus. Et af de mest avancerede i virksomhedsmiljøet er GenAIOps med prompt flows på Azure Machine Learning integreret med Azure DevOps , som tilbyder en meget systematisk tilgang til at bygge LLM-baserede applikationer.

Promptflowet er ikke bare en prompteditor; det er en komplet platform til design, testning, versionsstyring og implementering af LLM-interaktionsflows , fra simple cases (en enkelt prompt) til komplekse orkestreringer med flere noder, eksterne værktøjer, kontroller og automatiserede evalueringer.

En kritisk funktion er det centraliserede arbejdsgangslager , der fungerer som et virksomhedsbibliotek. I stedet for at hvert team har deres prompts i separate dokumenter eller deres egne lagre, er de konsolideret i et enkelt administreret lager med klare grene, revisioner og historik.

Derudover tilføjer platformen muligheder for variant- og hyperparametereksperimentering: det er muligt at teste forskellige kombinationer af prompts, modeller, temperaturindstillinger eller sikkerhedspolitikker på flere noder i flowet og sammenligne resultater med klare metrikker.

Med hensyn til implementering genererer GenAIOps med notifikationsflow Docker-billeder, der indkapsler både flowet og processessionen , klar til at køre i miljøer som Azure App Services, Kubernetes eller administrerede processer. Fra denne base aktiveres A/B-implementeringer til at sammenligne flowversioner i virkelige miljøer.

En anden styrke er styringen af ​​relationer mellem datasæt og flows. Hvert evalueringsflow kan arbejde med flere standard- og testdatasæt , hvilket muliggør validering af adfærd i forskellige scenarier, før noget lægges i hænderne på slutbrugerne.

Platformen registrerer også automatisk nye versioner af datasæt og flows, kun når der er faktiske ændringer, og genererer omfattende rapporter i formater som CSV og HTML for at understøtte datadrevne beslutninger, ikke intuition.

De fire faser af GenAIOps med notifikationsflow

GenAIOps-tilgangen opdeler livscyklussen i fire klart differentierede faser, som hjælper med at undgå det typiske kaos med "vi prøver ting med AI og ser, hvad der sker".

Den første fase, initialisering, fokuserer på præcist at definere forretningsmålet og indsamle repræsentative dataeksempler . Her skitseres den grundlæggende struktur for promptflowet, og arkitekturen designes, som derefter vil blive forfinet.

I eksperimenteringsfasen anvendes flowet på disse eksempeldata, og forskellige variationer af prompter, modeller og konfigurationer evalueres . Iterationen fortsætter, indtil der findes en acceptabel kombination, der opfylder minimumskravene til kvalitet og konsistens.

Dernæst kommer evaluerings- og forfiningsfasen, hvor større og mere varierede datasæt bruges til grundig benchmarking . Først når flowet viser ensartet ydeevne i overensstemmelse med de definerede standarder, betragtes det som klar til næste trin.

Endelig, i implementeringsfasen, optimeres arbejdsgangen for effektivitet og implementeres i produktion, inklusive A/B-test, overvågning, brugerfeedback og løbende forbedringscyklusser . Intet er nogensinde helt færdigt: arbejdsgangen justeres løbende baseret på observationer af brugen i den virkelige verden.

Denne metode er pakket i en GenAIOps-repository-skabelon med kodebaserede, præbyggede pipelines og lokale og cloudbaserede udførelsesværktøjer til at udvikle, evaluere og lancere LLM-baserede applikationer uden at skulle opfinde hjulet på ny for hvert projekt.

Integration med Azure DevOps: lagre, pipelines og godkendelse

For at bringe GenAIOps fra teori til en reel organisation er integration med Azure DevOps nøglen. Den typiske skabelon starter med et repository i Azure Repos med to hovedgrene, main og development , der afspejler forskellige miljøer og kodepromoveringsstrategier.

Eksempelarkivet er klonet fra GitHub, tilknyttet Azure Repos, og den sædvanlige arbejdsgang involverer oprettelse af funktionsgrene fra udviklingsmappen . Ændringer sendes derefter via pull-anmodninger, som automatisk udløser validerings- og eksperimenteringspipelines.

For at Azure DevOps kan interagere med Azure Machine Learning og andre tjenester, konfigureres en tjenesteprincipal i Azure som en teknisk identitet . Denne identitet bruges i en Azure DevOps-tjenesteforbindelse, hvilket giver pipelines mulighed for at godkende uden at eksponere rydbare nøgler.

Typisk har denne enhed ejertilladelser på ML-abonnementet eller arbejdsressourcen, hvilket giver pipelines mulighed for at klargøre slutpunkter, registrere modeller og opdatere politikker i nøglelagre . For øget sikkerhed kan den ændres til en bidragyderrolle ved at ændre de YAML-trin, der håndterer tilladelser.

Derudover oprettes en gruppe variabler i Azure DevOps, der gemmer følsomme data såsom tjenesteforbindelsesnavnet eller ressource-id'er . Disse variabler eksponeres for pipelines som et miljø, hvilket undgår behovet for at hardcode kritiske oplysninger i koden.

Konfiguration af lokale og eksterne arkiver gør det muligt at beskytte udviklingsgrenen med grenpolitikker , der kræver, at en pull request pipeline kører før sammenlægning. Denne pipeline håndterer buildvalideringer og eksperimenteringsflows og forhindrer, at der introduceres ødelagte ændringer.

Når koden er startet i udvikling, udløses en udviklingspipeline, der omfatter komplette CI- og CD-faser : kørsel af eksperimenter og evalueringer, registrering af flows i Azure ML-modelregistret, implementering af endpoints og røgtests og integration på de nyoprettede endpoints.

Det samme mønster replikeres til en versions- eller udgivelsesgren, der er forbundet til produktionsmiljøer. Der gentager CI/CD-pipelinerne til produktion cyklussen med eksperimentering, evaluering og implementering , men på infrastruktur og data på produktionsniveau med større kontrol og yderligere manuelle gennemgange, hvis det er nødvendigt.

En nøglefunktion er den "loop human review", der er inkluderet i disse pipelines: Efter CI-fasen blokeres CD'en, indtil en person manuelt godkender fortsættelsen fra Azure Pipelines-grænsefladen. Hvis den ikke godkendes inden for en bestemt tid (f.eks. 60 minutter), afvises udførelsen.

Lokal implementering og forbindelse med LLM-udbydere

Ikke alt sker via pipelines: GenAIOps understøtter også lokal udførelse til hurtig eksperimentering . Du kan klone skabelonlageret, oprette en .env-fil i rodmappen og definere forbindelser til Azure OpenAI eller andre kompatible slutpunkter i det.

Disse forbindelser inkluderer parametre som api_key, api_base, api_type og api_version, og der refereres til dem med navn i flows (f.eks. en forbindelse kaldet "aoai" med en specifik API-version). Dette gør det muligt for det samme flow at køre lokalt og i skyen uden kodeændringer.

For at bruge denne metode skal du blot oprette et virtuelt miljø eller en conda og installere de nødvendige afhængigheder (promptflow, promptflow-tools, promptflow-sdk, openai, jinja2, python-dotenv osv.). Derfra kan du skrive testscripts i en lokal udførelsesmappe og køre eksperimenter på de definerede flows.

Denne cloud/on-premise dualitet stemmer perfekt overens med en moden DevOps-tankegang: test i lille skala udføres lokalt, formel validering udføres i pipelines, og derefter implementeres der i større miljøer med kontroller og revision . Alt er versionsbaseret i Git og forbundet til Azure DevOps.

Typiske værktøjer i et DevOps-økosystem med AI og LLMOps

Ud over Azures specifikke forslag er et moderne DevOps-økosystem med AI og LLMOps typisk afhængigt af et sæt værktøjer, der dækker ChatOps, modelorkestrering, overvågning og observerbarhed.

I ChatOps-laget er det almindeligt at kombinere Slack med bots som Hubot , Microsoft Teams med agenter baseret på Power Virtual Agents eller Discord sammen med frameworks som Botpress eller Rasa for at bygge brugerdefinerede assistenter, der forbinder med pipelines, overvågningssystemer og interne tjenester.

Inden for LLMOps/MLOps-feltet er platforme som Kubeflow og MLflow almindelige til styring af pipelines, modelposter og eksperimenter, foruden specifikke værktøjer som Weights & Biases (W&B) til avanceret metriksporing, kørselssammenligninger eller dybdegående visualiseringer.

At bygge applikationer på LLM involverer typisk brug af frameworks som LangChain eller biblioteker som OpenLLM , der letter samling af promptkæder, forbindelser til eksterne data, værktøjer og flertrinsagenter. Samtidig dukker der løsninger op til LLM-specifik observerbarhed, som muliggør overvågning af prompts, svar, omkostninger og kvalitet.

I integration med klassisk DevOps forbliver værktøjer som Jenkins eller GitLab CI relevante for CI/CD-delen, Kubernetes og ArgoCD til kontinuerlig cloud-native implementering og observabilitetsstakke som Prometheus, Grafana og Loki til metrics, dashboards og logs.

Udfordringer, begrænsninger og gradvis implementering

Al denne implementering af praksisser og værktøjer kommer ikke uden en pris. Kompleksiteten ved at administrere prompts, modelversioner og workflowvarianter er betydelig, især når flere teams arbejder samtidigt – et scenarie, hvor strategier som GitOps er nyttige til at koordinere ændringer og implementeringer.

Derudover introducerer ChatOps-bots og LLM'er med handlingsrettede funktioner betydelige sikkerhedsrisici, hvis de har for mange tilladelser i produktionsmiljøer, eller hvis dataeksponeringsflader ikke kontrolleres korrekt.

Dertil kommer afhængigheden af ​​open source-modeller med følsomme licenser eller kommercielle API'er , der kan ændre vilkår, priser eller begrænsninger. Og hvad der gør tingene værre, er robust evaluering af LLM'er i produktion stadig et åbent område, hvor mange spørgsmål stadig er ubesvarede.

Derfor giver det mening at gribe implementeringen af ​​LLMOps og ChatOps inden for DevOps an på en progressiv og kontrolleret måde , startende med at automatisere gentagne opgaver med simple bots (genstarter, logforespørgsler, build-tagging osv.).

Senere kan LLM'er introduceres til supportopgaver, hændelsesklassificering eller assistance til fejlfinding , for eksempel forklaring af fejl fra logfiler eller forslag til afhjælpninger baseret på intern dokumentation.

Når den klassiske ML-drift er stabiliseret, er det tid til at tackle LLMOps med specialiserede sprogmodeller til domæner som kundeservice, DevSecOps eller QA, hvor man udnytter alt, hvad man har lært i tidligere faser.

Den horisont, som alle disse praksisser peger mod, er et konversationsbaseret, prædiktivt og i stigende grad autonomt ingeniørmiljø , hvor meget af udviklingen og driften udtrykkes i naturligt sprog, og AI hjælper med at træffe proaktive beslutninger om implementeringer, skalering eller rollbacks.

Med dette puslespil på plads – DevOps, ChatOps, MLOps, GenAIOps og LLMOps – har organisationer et solidt rammeværk til at bygge og vedligeholde LLM-baserede systemer, der virkelig leverer værdi , samtidig med at de opretholder kontrol over kvalitet, omkostninger, sikkerhed og sammenhæng med forretningen, i stedet for blot at forblive ved prototyper eller isolerede tests, der falder fra hinanden, så snart de når produktion.