Hvad er LLMOps?
LLMOps er den disciplin der handler om at drifte sprogmodelløsninger i produktion: at versionere prompts, evaluere svarenes kvalitet og overvåge omkostningerne over tid. Det minder om DevOps, men med en ny vanskelighed: Svarene er ikke deterministiske; samme spørgsmål kan give forskellige svar. En minimumsopsætning er logning, en evalueringssuite og omkostningsalarmer. Uden LLMOps går mange løsninger i stå på pilotstadiet.
LLMOps er den disciplin der handler om at drifte løsninger bygget på store sprogmodeller: at versionere prompts, evaluere svarenes kvalitet og overvåge omkostningerne over tid. Navnet er beslægtet med DevOps og beskriver alt det der kræves når løsningen er bygget, altså arbejdet med at holde den stabil, målbar og pålidelig i produktion.
Det er let at tro at arbejdet er færdigt når en AI-løsning fungerer i en demo. I praksis er det dér det svære begynder. En demo er kontrolleret; virkeligheden er ikke. LLMOps er det der lukker hullet mellem “det virkede ved en fremvisning” og “man kan stole på det hver dag”.
Parallellen til DevOps, og det der er nyt
DevOps handler om at bygge, drive og forbedre software på en struktureret måde. LLMOps bygger videre på samme tankegang, men tilføjer en vanskelighed der ikke fandtes før.
I almindelig software er output deterministisk: Samme input giver samme resultat, hver gang. Derfor kan man teste mod et facit. En sprogmodel fungerer ikke sådan: Samme spørgsmål kan give forskellige svar på forskellige tidspunkter. Det lyder ikke af meget, men det vælter en af grundpillerne i traditionel test.
Konsekvensen er at man ikke kan kontrollere kvaliteten på den gamle måde. I stedet er der brug for metoder til at måle svar der varierer: at vurdere om et svar er godt nok, snarere end om det er præcis rigtigt. Netop den udfordring er kernen i hvad LLMOps tilfører ud over almindelig drift.
Minimumsopsætningen
Man behøver ikke at bygge det hele på én gang, men der er et fundament der er svært at undvære. Tre dele udgør en rimelig minimumsopsætning.
| Del | Hvad den giver |
|---|---|
| Logning | Sporbarhed: hvad blev der spurgt om, og hvad blev der svaret |
| Evalueringssuite | Indsigt i om kvaliteten holder |
| Omkostningsalarmer | Advarsel før regningen løber løbsk |
Logning betyder at gemme hvad der blev spurgt om og hvad modellen svarede så problemer kan spores bagefter. En evalueringssuite er en metode til systematisk at måle om svarene lever op til kravene, i stedet for at stole på mavefornemmelsen. Omkostningsalarmer overvåger udgifterne og advarer før de løber løbsk. Det er vigtigt fordi omkostningen beregnes efter forbrug og let kan overraske. Med de tre på plads har I indsigt i kvalitet, sporbarhed og omkostning.
Hvorfor LLMOps afgør om piloten overlever
Her ligger pointen med hele disciplinen. Rigtig mange AI-projekter ser lovende ud i en pilot, men når aldrig i produktion. Årsagen er sjældent at modellen var dårlig, men at ingen havde værktøjerne til at stole på den i længden.
Uden logning kan man ikke forstå hvorfor et svar blev forkert. Uden evaluering opdager ingen når kvaliteten langsomt forringes. Uden styr på omkostningerne opdages en løbsk regning først på fakturaen. En pilot uden LLMOps er en løsning man ikke tør sætte i drift, og så bliver den hængende på pilotstadiet uanset hvor godt den så ud ved fremvisningen.
Der er desuden en særlig fælde her: Kvaliteten kan glide langsomt uden at nogen ser det. Fordi svarene varierer af natur, er det let at afvise et dårligt svar som en enkeltstående hændelse. Men bag enkelte fejl kan der gemme sig en reel forringelse: Måske har spørgsmålene ændret sig, måske er noget af det underliggende materiale blevet forældet. Uden en evaluering der måler over tid, opdages den slags først når brugerne har mistet tilliden. Det er en af de tydeligste grunde til at måling ikke kan springes over.
Hvad det betyder for dig som kunde
LLMOps er ikke noget man lægger til bagefter, men en del af det der gør en AI-løsning driftsklar. Når I vurderer en leverandør, er det rimeligt at spørge hvordan løsningen skal logges, hvordan kvaliteten skal måles og hvordan omkostningerne skal overvåges. Svarene afslører om der er en plan for virkeligheden eller kun for demoen.
En sidste ting der er værd at nævne: Prompts bør versioneres ligesom kode. Når I justerer en instruktion for at rette en adfærd, vil I gerne kunne se hvad der blev ændret og kunne gå tilbage hvis det blev dårligere. Uden versionering bliver forbedringsarbejdet gætværk i blinde: Ingen husker rigtigt hvad der gjaldt i sidste uge. Det er en lille vane der gør stor forskel for hvor kontrolleret en løsning kan udvikles over tid.
Vi hos Weapp behandler driftsspørgsmålene som en del af løsningen fra begyndelsen. Vil du drøfte hvad der kræves for at en AI-løsning holder i produktion, kan du læse mere om vores AI-ydelser eller kontakte os med en beskrivelse af hvad I vil bygge.
Ofte stillede spørgsmål
Hvad står LLMOps for?
LLMOps er en sammensætning af LLM, altså stor sprogmodel, og ops fra operations, dvs. drift. Begrebet er beslægtet med DevOps og MLOps og beskriver arbejdet med at få en sprogmodelløsning til at fungere stabilt i produktion over tid, ikke kun i en demo. Det handler om alt det der kræves efter at løsningen er bygget: at overvåge, måle og forbedre den løbende.
Hvordan adskiller LLMOps sig fra almindelig DevOps?
Grundlaget er det samme, men én ting er ny: Svarene er ikke deterministiske. Almindelig software giver samme output på samme input mens en sprogmodel kan svare forskelligt på samme spørgsmål. Det betyder at man ikke kan teste på den gamle måde, med et facit. I stedet er der brug for evalueringsmetoder der måler kvaliteten af svar der varierer, og det er selve kernen i det nye ved LLMOps.
Hvad indgår i en minimumsopsætning for LLMOps?
Tre ting som fundament. Logning: at gemme hvad der blev spurgt om og hvad modellen svarede så problemer kan spores. En evalueringssuite: en metode til systematisk at måle om svarene lever op til kravene. Og omkostningsalarmer: overvågning der advarer før regningen løber løbsk. Med de tre på plads har I indsigt i kvalitet, sporbarhed og omkostning, hvilket er det meste af det der kræves for at drive en løsning ansvarligt.
Hvorfor går AI-piloter i stå uden LLMOps?
En pilot ser ofte godt ud i en kontrolleret demo, men virkeligheden er mere rodet. Spørgsmål stilles på uventede måder, omkostningen viser sig at være højere end ventet, og kvaliteten svinger uden at nogen opdager det. Uden logning, evaluering og styr på omkostningerne mangler værktøjerne til at opdage og rette det. Så bliver løsningen stående på pilotstadiet fordi ingen tør stole på den i produktion.
Har et lille AI-projekt brug for LLMOps?
Ambitionsniveauet kan skaleres, men princippet gælder stadig. Selv en lille løsning har gavn af at man gemmer hvad den svarer, har en måde at måle kvaliteten på og holder øje med omkostningerne. Det behøver ikke være tungt fra start, men at springe det helt over betyder at man kører i blinde. Lidt LLMOps fra begyndelsen er billigere end at reparere en løsning man har mistet kontrollen over.