En model, der performer godt ved lancering, performer sjældent lige
En model, der performer godt ved lancering, performer sjældent lige så godt et halvt år senere. Data ændrer sig, brugeradfærd skifter, og de signaler, modellen blev trænet på, holder op med at afspejle virkeligheden. AWS har nu bygget et lag oven på SageMaker AI-endpoints, der overvåger selve overvågningen: et meta-monitoreringslag drevet af Amazon Quick, som løbende tjekker, om modellens forudsigelser og datainput stadig hænger sammen med det, den blev bygget til.
Det er en anden tilgang end den klassiske model-monitorering, hvor man ser på enkeltmetrikker som latency eller fejlrate. Her handler det om at opdage, når modellens grundlag skrider, længe før det viser sig som dårlige forretningsresultater.
Model-drift
Sådan opdager laget drift i prædiktioner og datakvalitet
Meta-monitoreringslaget arbejder på to niveauer samtidig. Det ene niveau kigger på datadrift: ændrer fordelingen af inputdata sig statistisk over tid, sammenlignet med den periode modellen blev trænet og valideret på. Det andet niveau kigger på prædiktionsdrift: ændrer modellens outputmønstre sig, selv når input ser stabilt ud.
Den kombination er vigtig, fordi de to typer drift ofte optræder uafhængigt af hinanden. En webshop kan for eksempel opleve, at kundesegmenterne ændrer sig gradvist uden at det slår ud i de rå inputdata, men hvor modellens klassifikationer alligevel bliver mindre præcise. Det er den slags forskydning, jeg selv holder øje med i de agent-systemer, jeg driver for Agent Enterprise: input kan se stabilt ud i ugevis, mens outputtet langsomt bevæger sig væk fra det, vi byggede det til. Ved at overvåge begge lag samtidig fanger man forskydninger, som en enkelt metrik ville overse.
Amazon Quick fungerer som analyselaget, der løbende sammenligner de nye datapunkter med baseline-fordelingen og flager afvigelser, når de krydser fastsatte tærskler. Det sker automatisk og kontinuerligt, ikke som en manuel stikprøve engang om måneden.
Sådan løser laget problemet med forsinket ground truth
Et af de sværeste problemer i produktionsmonitorering er, at man ofte ikke kender den korrekte facit-værdi med det samme. Hvis en model forudsiger kundefrafald, går der uger eller måneder, før man reelt ved, om kunden faktisk forlod virksomheden. Den forsinkelse gør det svært at måle modellens nøjagtighed i realtid.
Meta-monitoreringslaget adresserer det ved at bygge dashboards, der opdaterer sig automatisk, efterhånden som ground truth-data trickler ind, i stedet for at vente på en samlet batch-opdatering. Det betyder, at teams kan se nøjagtighedstrenden udvikle sig gradvist og reagere, når kurven begynder at bevæge sig i den forkerte retning, i stedet for at opdage problemet måneder for sent, når skaden allerede er sket.
Det er et problem, jeg selv støder på i mit arbejde med kunders ML-drift: man har bygget solid overvågning af de metrikker, man kan måle med det samme, men står blind, når det gælder de metrikker, der kræver tid at bekræfte. En dashboard-mekanik, der opdaterer sig, i takt med at facit trickler ind, lukker netop det hul.
Governance bygget ind fra start, ikke lappet på bagefter
Det, der adskiller denne tilgang fra traditionel model-overvågning, er at governance ikke er et separat lag, man tilføjer, når compliance-afdelingen banker på døren. Det er indbygget i selve arkitekturen omkring endpointet fra dag ét. Hver afvigelse, hvert flag og hver beslutning om at eskalere logges automatisk, så der findes en sporbar historik over, hvornår modellen begyndte at drifte, og hvornår nogen reagerede på det.
Det er også den måde, jeg selv bygger de agentiske systemer, jeg drifter, på. Governance er ikke et dokument, man skriver bagefter. Det er en del af det, systemet gør, hver gang det handler.
Governance, der bygges ind fra start, koster langt mindre end governance, der skal presses ind i en eksisterende produktionssætning bagefter.
Hvad det betyder, når AI-modeller skal holde i produktion over tid
For mig er den bredere pointe her, at model-monitorering er ved at modnes fra et teknisk sidespor til en driftsdisciplin på linje med infrastrukturovervågning. Ligesom man ikke længere accepterer, at en server bare går ned uden alarm, bliver det stadig mindre acceptabelt, at en model stille og roligt bliver dårligere, uden at nogen opdager det, før kunderne eller regnskabet gør det.
Det spørgsmål stiller jeg mig selv, hver gang jeg sætter et nyt system i drift: har vi et lag, der overvåger selve overvågningen, eller stoler vi på, at de metrikker, vi allerede kigger på, fanger de problemer, der reelt opstår. De to typer drift, data og prædiktion, kræver hver deres tjek, og forsinket ground truth kræver sin egen løsning, ikke bare en pause i rapporteringen, indtil facit foreligger.
Det er ikke et spørgsmål om at bygge det perfekte system fra dag ét. Det er et spørgsmål om at bygge et system, der fortæller sandheden om sig selv, mens det kører, så man opdager problemerne, mens de stadig er billige at rette.