MLOps— Effektiv utvikling og forvaltning av maskinlæringsprodukter og LLMer

Photo by Mojahid Mottakin on Unsplash

I en tid preget av rask teknologisk utvikling har generativ AI trådt frem som den største driveren, og interessen rundt denne nyskapende teknologien fortsetter å vokse. Den utbredte bruken av Large Language Models (LLM) innenfor feltet har ikke bare revolusjonert måten vi tenker på, bruker og jobber med informasjon, men har også fanget oppmerksomheten til en stadig økende gruppe enkeltpersoner, organisasjoner og samfunn. I dagens marked ser vi at flere selskaper har kommet langt i å kartlegge potensialet for anvendelse av mer avansert analyse og å bygge opp interne team med data science- og data engineering-kapabiliteter før bølgen rundt LLMer skyldte over oss for et drøyt år siden. Noen har også produksjonssatt flere modeller. Stegene fra en vellykket proof of concept til produksjonssetting av modeller er et eget tema, som vi blant annet diskuterer her. Men samtidig er det mange som fremdeles mangler effektive prosesser for å skalere, overvåke og drifte et økende antall maskinlæringsprodukter, og spesielt de ekstra utfordringene som LLMer introduserer.

Leder du en avdeling med dyktige data scientists, men ser at de bruker en økende andel av tiden sin på å forvalte eksisterende modeller? Ønsker du at modeller raskere skal kunne benyttes av forretningssiden, eller føler du at du mangler en enkel oversikt over hvordan modellkvaliteten utvikler seg over tid? Det er nettopp her et MLOps-rammeverk er en kritisk komponent for å etablere de rette prosessene og verktøyene. I dette blogginnlegget vil vi forklare hva vi legger i begrepet MLOps og LLMOps, og dele noen av dimensjonene du burde vurdere for å effektivt sette opp og forvalte LLMer.

En enkel definisjon av MLOps

Før vi dykker videre ned i de viktigste dimensjonene av dette rammeverket, la oss definere hva vi legger i begrepet MLOps. Med MLOps mener vi et et sett med standardiserte prosesser, ansvarsområder og underliggende verktøy og teknologier for å effektivt utvikle, produksjonssette og forvalte maskinlæringsprodukter gjennom hele livssyklusen, vist i Figur 1. Når dette er på plass vil det være mulig å øke innovasjonstakten med raskere iterasjoner, gi en mer håndterbar skalering av antall maskinlæringsmodeller teamet kan drifte med standardiserte prosesser, samtidig som et robust og standardisert overvåkningssystem gir mer stabile og pålitelige applikasjoner.

Figur 1: Oversiktsbilde av MLOps-livssyklusen på Azure. Microsoft, 2020 [1]

Prinsipper for utvikling og forvaltning av maskinlæringsprodukter

Bakgrunnen for MLOps [2] er på mange måter tradisjonell DevOps fra softwareutvikling, som kombinerer prinsipper fra smidig softwareutvikling (Dev) med IT-forvaltning (Ops). Hensikten er å øke utviklingstakten ved å binde samarbeidet mellom teamene som jobber med utvikling og forvaltning tettere sammen. Med den siste trenden innen store språkmodeller, har også konseptet LLMOps vokst frem [3]. Dette konseptet omfatter lignende prinsipper som MLOps, men er skreddersydd for LLMer.

Mye av fundamentet er tuftet på to ideer. Den første er kontinuerlig integrasjon (CI), illustrert i Figur 2, som handler om å automatisk fange opp kodeendringer fra utviklere, teste disse og pakketere dette som et softwareprosjekt. Den andre er kontinuerlig utrulling (CD) der man definerer automatiske, strømlinjede prosesser for å rulle ut og overvåke nye produktversjoner.

Men det er flere store forskjeller når det kommer til utvikling av maskinlæringsprodukter. Til forskjell fra softwareutvikling har maskinlæringsprodukter et viktig kompliserende tilleggselement, nemlig at innsikten er utledet fra data. Med dynamisk data som må hensyntas i alle ledd fra utvikling til forvaltning, utvider derfor MLOps konseptene fra DevOps med den ekstra dimensjonen som ofte kalles kontinuerlig (re)trening (CT). I denne dimensjonen menes verktøy og prosesser for å produksjonssette og automatisere alle stegene en data scientist har vært gjennom for å trene og rulle ut maskinlæringsprodukter for å gjøre dem klare til å bli konsumert.

Figur 2: Oversikt over nødvendige komponenter for kontinuerlig trening (CT). Google 2020 [2].

Nye utfordringer i maskinlæringssystemer

I tillegg til å integrere kontinuerlig trening i prosessene, medfører også data-dimensjonen minst fem nøkkelendringer [2] som må hensyntas i verktøyvalg, arbeidsprosessene og kulturen i organisasjonen:

• Økt kompleksitet i teamsammensetning med økt behov for analyse-, statistikk- og modelleringskompetanse, så vel som dataprosessering og dataintegrasjoner. I tillegg er innsikt fra domeneeksperter ofte uvurderlig i modelleringsfasen. Hvordan de ulike fagdisiplinene skal jobbe sammen og hvem som er ansvarlig for de ulike fasene av produktets livssyklus er viktige spørsmål å kartlegge. Samtidig som den tekniske kompetansen for å utvikle maskinlæringsprodukter er mer sammensatt, øker også kravet til involvering av forretningssiden. Ofte er ambisjonen å integrere maskinlæringsproduktene tett med eksisterende forretningsprosesser eller kunderettede løsninger. For å bygge vellykkede maskinlæringsprodukter er det derfor kritisk med tett involvering fra forretningssiden for å forstå de eksisterende prosessene og forretningsproblemet som skal løses. Vi ser ofte at det å bygge tillit til produktet hos forretningssiden, dyrke frem en datadrevet kultur, opplæring og endringsledelse er kritiske dimensjoner for å sikre suksess.
• Mindre lineær utviklingsprosess der iterasjoner med utforskning og eksperimentering er en naturlig del av utvikling av maskinlæringsmodeller. I disse iterasjonene er det kritisk å ha et godt system for å loggføre tester, resultater og modeller for å finne den beste modellen og øke reproduserbarhet. Samtidig vil man aldri komme helt i mål i utviklingsfasen, der det alltid vil være mulig å forbedre noen steg, prøve en annen algoritme eller finjustere modellene enda litt til. Dette stiller derfor krav til at man både må definere hva som er godt nok, i tillegg til å ha et tydelig fokus på å raskt produksjonssette modeller og begynne å samle erfaringer, da det er først her produktet vil realisere verdi, i tråd med smidige prinsipper.
• Sammenliknet med tradisjonelle softwareprodukter forringes kvaliteten i maskinlæringsprodukter raskere. Dette skjer fordi virkeligheten modellen er tilpasset er dynamisk og i kontinuerlig endring. Endringene kan være mindre og gradvis over tid eller et plutselig skifte i de underliggende prosessene som gjør modellen tilnærmet ubrukelig. For å kunne sikre et pålitelig og stabilt maskinlæringsprodukt gir dette et økt krav til overvåkning og mekanismer for å proaktivt varsle om avvik fra forventningene. Dette er viktig av flere grunner. Først og fremst er god overvåkning av forretningskritiske modeller det første steget for å sikre stabilitet og forutsigbarhet. Avhengig av modellen, er dette med å skape tillit hos interne brukere eller kritisk for å sikre verdi av modeller eksponert til sluttkunder. Overvåkning og loggføring er også nødvendig for å effektivt kunne utføre feilsøking og utbedring, dersom behovet for dette melder seg. Overvåkningen i seg selv er også mer sammensatt, og i tillegg til å overvåke infrastrukturen og applikasjonen, krever både maskinlæringsmodellen og dataen som går inn og ut av denne egne hensyn og prosesser.
• Dataflyt må produksjonssettes som en del av applikasjonen. For å muliggjøre kontinuerlig trening av maskinlæringsmodellene må også produksjonssetting av dataflyten automatiseres. Dette innebærer stegene fra innsamling av data, vask og tilgjengeliggjøring av treningsdata for modellen. Dette i seg selv er ikke noe nytt, men synkroniseringen og pakketeringen av dette sammen med maskinlæringsproduktet gir en økt kompleksitet.
• Mer sammensatte pipelines for å trene maskinlæringsmodeller. I tillegg til dataflyten nevnt i forrige punkt, må hele prosessen som er spesifikk for maskinlæring automatiseres. Dette inkluderer blant annet feature engineering, modelltrening og tuning av hyperparametere. For å bygge oversiktlige produkter og gjøre forvaltningen av disse håndterbar stiller dette krav til standardisering av hvordan data scientists strukturerer og modulariserer kodebasen sin, i tillegg til egne prosesser rundt data- og modellvalidering.

Utfordringene skissert ovenfor gjelder også for LLMer, i tillegg til utfordringer knyttet til hyppige endringer på, ofte black box, APIer (f. eks. OpenAI) og det å utlede nye gode metrikker for å overvåke kvaliteten i komplekse språklige oppgaver. Uten å ta høyde for dette, risikerer man at modellene med tiden gir uønskede resultater som feilaktige eller upassende responser, noe som igjen kan ha betydelige konsekvenser for brukerne og selskapet som har levert tjenesten.

Gode metrikker for å overvåke språkmodeller er et område som er spennende å følge, med stor utvikling om dagen. Eksempler på dette er teksthub initiativet på UiO som har utviklet et norsk datasett, NorQUAD, som kan fungere som en baseline for overvåkning av modelldrift, eller nyutvikling i verktøy som MLFlow med både moduler og datasett for feks evaluering av LLMer [4].

For å komme i gang anbefaler vi en målrettet implementasjon med fokus på å levere verdi

Det kan være overveldende å vite hvilken ende man skal begynne i for å bygge opp et komplett, automatisk ende-til-ende system, med tydelig definerte ansvarsområder, prosesser og kompetanse. På samme måte som et godt maskinlæringsprodukt bør ha utspring fra et forretningsbehov med en tydelig verdi som blir skapt gjennom iterative forbedringer, anbefaler vi en smidig og iterativ tilnærming for å bygge opp deres MLOps-kapabiliteter. I denne tilnærmingen vil det være fornuftig å prioritere de elementene av rammeverket som svarer til de største utfordringene dere har i dag og dermed størst verdi når de kommer på plass.

Flere av de store skyleverandørene har egne samlinger av verktøy med en implisitt arbeidsprosess, som for eksempel Azure Machine Learning og AWS Sagemaker. Disse kan gi en god og rask start. Etter hvert som dere gjør dere opp erfaringer med hva som fungerer for dere og de spesifikke behovene i organisasjonen modnes, kan man ved behov gradvis introdusere nye verktøy og bygge ut kapabiliteter der det trengs. Samtidig er det viktig å huske at nye verktøy og teknologier kun er en del av løsningen, og holdningene og prosessene som bygges rundt disse må utvikles i takt med verktøykassen.

I grove trekk anbefaler vi følgende steg for å bygge opp et MLOps-rammeverk:

1. Begynn med å kartlegge dagens prosesser for utvikling og forvaltning av maskinlæringsprodukter, de største utfordringene dere opplever og eksisterende verktøy.
2. Utarbeid et målbilde for hvordan et MLOps-rammeverk kan se ut for akkurat deres team og organisasjon.
3. Utfør innledende tester av relevante verktøy, enten på de store skyplattformene, open source eller fra tredjeparter skreddesydd for enkelte deler av maskinlæringsinfrastrukturen.
4. Fokuser på verdirealisering ved å ta utgangspunkt i konkrete forretningsproblemer, bygge enkle modeller og raskt få disse produksjonssatt. Involver både forretningssiden og domeneeksperter i alle faser for å sikre eierskap til løsningen, øke sannsynligheten for et sluttprodukt som gir verdi og avmystifisere fagområdet.
5. Etabler tydelige driftsmodeller og ansvarsområder gjennom hele livssyklusen til maskinlæringsproduktet. Dette bør svare ut spørsmål som hvilket team som skal forvalte de ulike komponentene av maskinlæringsproduktet, hva en standardisert data science leveranse består av, hvilket team som er ansvarlig for hvilket type feil og hva som er forventet responstid ved feil på ulike systemer.
6. Ha fokuserte utvidelser av avgrensede komponenter i MLOps-rammeverket på bakgrunn av de kartlagte utfordringene og målbildet, for å iterativt bygge et robust MLOps-rammeverk integrert i prosessene i deres organisasjon.

Denne artikkelen bygger blant annet på artikkelen fra Google, MLOps Continuous delivery and automation pipelines in machine learning, som gjengitt i kildene under.

[1] Azure.microsoft.com. (7. mai 2021). 2020. MLOps Best Practices. Tilgjenglig på https://azure.microsoft.com/en-us/resources/mlops-infographic/

[2] Cloud.google.com. (7. mai 2021). 2020. MLOps: Continuous delivery and automation pipelines in machine learning. Tilgjengelig på https://cloud.google.com/architecture/mlops-continuous-delivery-and-automation-pipelines-in-machine-learning

[3] What is LLMOps? IBM
https://www.ibm.com/topics/llmops

[4] Mlflow.org (30. november 2023). MLflow LLM Evaluate. Tilgjengelig på https://mlflow.org/docs/latest/llms/llm-evaluate/index.html