De fleste RL-benchmarks nulstiller verden efter hver episode. Virkelige systemer gør ikke. MORPHEUS, lanceret 13. juli, går efter netop den forskel og gør vedvarende drift til selve testbænken.
Hvad MORPHEUS prøver at løse
MORPHEUS præsenteres som en persistent enterprise-simulationsplatform til kontinuerlig forstærkningslæring. Kernen er enkel: beslutninger får eftervirkninger, tilstande akkumulerer, og en fast politik vil før eller siden fejle. Kilden beskriver det med Big World Hypothesis (Javed & Sutton, 2024): verden er større end nogen agents repræsentation, så den opleves som non-stationær, selv når dynamikkerne ikke skifter. Relevansen er størst i systemer, hvor små skævheder langsomt bliver dyre problemer.
Tre krav som presser mod kontinuerlig læring
Ifølge specifikationen kræver MORPHEUS tre egenskaber for at tvinge kontinuerlig læring frem: persistens, non-stationaritet og operationel kompleksitet. Persistens betyder, at tidligere valg ændrer fremtidens dynamik over lang horisont. Non-stationaritet betyder, at enhver fast politik bliver suboptimal over tid. Operationel kompleksitet betyder, at ét sæt regler ikke rækker, fordi mål og begrænsninger støder sammen på tværs af tid og ressourcer.
I klassiske RL-miljøer udfordrer det episode-tænkningen. Her er det virksomhedsdrift: når de tre krav står samtidig, bliver CRL en nødvendighed, ikke en feature.
Arkitekturen under motorhjelmen
Hver MORPHEUS-verden er et selvstændigt TypeScript-plugin. Pluginnet eksporterer Operational Descriptors (ODs), en simulationsscheduler, seed-data og dokumentation (jf. kildens afsnit How the Platform Works). Formålet er modulær opbygning, så verdener kan versioneres og sammenlignes.
Operational Descriptors beskriver trin-for-trin, hvordan en capability udføres. Agenter handler via et capability-API, og hvert kald udløser kørsel af en OD. Det giver målbare koblinger mellem fejl og den operationelle kontekst, som kan bruges både til debug og læringssignal.
Scheduler og seeds binder det sammen. Seeds giver starttilstande, og scheduleren styrer, hvornår ODs kører. Reproducerbarhed forudsætter deterministisk tidsstyring og gennemsigtige seeds. Kilden antyder dette, men dokumenterer ikke fuldt ud, hvordan determinisme holdes ved meget lange kørsler. Det bør behandles som et eksplicit risikopunkt ved adoption.
To motorer for non-stationaritet
Non-stationaritet skabes af to komponenter: en failure injection engine og en asynkron konfigurationsskift-controller (jf. How the Platform Works). Førstnævnte indsætter afbrydelser mellem OD-trin og trækker fra elleve fejlkategorier — bl.a. missing_data, dependency_failure og rate_limit — på fire forudindstillede frekvenser: 5, 8, 15 og 30 procent. Fejlene kan lande midt i en kapabilitetskæde og stresse recovery-logik.
Den asynkrone controller ændrer presets og efterspørgsel på faste tidsstempler uafhængigt af træningsloopet, så skift ikke aligner med gradientopdateringer. Det forhindrer, at en agent bruger opdateringsfrekvens som ur. Metodisk fornuftigt — i praksis gør det hyperparameter-tuning mere følsom.
Når skift ikke følger opdateringsrytmen, bliver læringsrate, batch-størrelser og checkpointing afhængige af realtid. Fejlfrie perioder kan pynte kurverne, og chok kan falde lige efter et checkpoint. Træning skal planlægges som drift, ikke kun som eksperiment.
Belønning gennem tre verifikatorer
Belønningen kommer fra tre operationelle verifikatorer logget i platformen: fejlbegivenheder, økonomisk ledger-status og ressource-throughput. De samles i et composite reward. Standardvægtene fremgår i Appendix C som w_f = 0.5 samt w_l = w_p = 0.25. Her er fejl vægtet tungest.
Konsekvensen er en risikoavers profil. I domæner, hvor fejl er dyre, er det ofte rigtigt. I andre kan man miste throughput eller margin, hvis vægtene ikke afspejler faktiske KPIer. Anbefalet fremgangsmåde: map w_f, w_l og w_p direkte til jeres egne måltal, og valider ledger-modellen mod historiske tal, før policies flyttes ud.
Baseline-pipelinen og hvorfor SFT først
Handlingsrummet er stort, så ren RL fra bunden er upraktisk. Derfor bruger MORPHEUS en to-trins pipeline: en frontier-model (Gemini 3.1 Pro) indsamler trajectories via ReAct, som derefter finetunes ind i Qwen3-14B med supervised finetuning. Alle RL-kørsler starter fra samme SFT-checkpoint. Ifølge kilden isolerer det CRL-adfærd fra basal driftskompetence.
Som online post-træning bruges PPO som basisoptimizer. Fordelen er sammenlignelighed. Ulempen er, at SFT-checkpointet farver alt. Hvis domænet ligger langt fra de indsamlede spor, bør SFT-trinnet gentrænes, inden man sammenligner algoritmer på tværs.
Determinisme og seed-håndtering i langløb
Kilden nævner seeds, men ikke, hvordan langløbs-reproducerbarhed sikres under asynkrone skift og fejlindsprøjtning. Det er et hul. Teams bør derfor køre en lille determinismepakke, før de binder sig:
- Parallel-run test: kør N identiske seeds i 24–48 timer og mål hash af OD-traces per timestep. Tjek divergensrate.
- Replay-test: genafspil loggede OD-beslutninger på samme seed og sammenlign composite reward-sekvenser mod originalen.
- Tidsskæv-test: forskyd skiftcontrollerens tidsstempler med ±Δt og mål sensitivitet i adaptationshastighed og recoverytid.
- Checkpoint-repeat: genoptag fra samme checkpoint to gange og verificer identisk forløb frem til næste skift-event.
Bestås disse, har man en praktisk bund for genskkabelighed — ikke perfekt bevis, men nok til at sammenligne eksperimenter nøgternt over uger.
Hvordan persistens ændrer spillet i praksis
Persistens kræver, at testmiljøet bærer langtidstilstande: degradering af services, kø-ophobning, økonomiske haler. Det forudsætter stateful datalagre i træning og staging samt monitorering, der ikke nulstilles ved midnat. ML og drift flyder sammen — også i testmiljøet.
Omkostningssiden er reel. Vedvarende simuleringer med ODs, fejlinjektion og skiftkontroller i flere samtidige miljøer bruger tid og compute. Kilden giver ingen wall-clock-tal. Indhent derfor et simpelt estimat, før der planlægges større forløb.
Implementering, i øjenhøjde
Valg af fejlfrekvens og -type former agentens robusthed. Hvis en virksomhed typisk ser få, men ekstreme afhængighedsfejl, er 8 procent “realistic” ikke nødvendigvis rigtigt for jer. Presets er udgangspunkter. Anbefalet fremgangsmåde er at spejle egne incidents — teknisk og trinvist, ikke kun som mavefornemmelse.
Skiftcontrolleren er asynkron, så træningsopsætningen må tilpasses. Læringsrater kan med fordel sænkes, checkpoints tages oftere, og A\/B-deploys bør ikke forudsætte faste skiftvinduer. Har produktionen kalenderstyrede ændringer, så test både asynkrone og kalenderforankrede skemaer, så I ikke får falsk tryghed.
En kort tjekliste til teams
- Validitet: Matcher failure-typer jeres incidents? Hvis ikke, lav en domæne-mapping, før I tolker resultater.
- Overførsel: Tjek at composite reward afspejler KPIer. Juster vægte, ellers flytter I et forkert signal i produktion.
- Sikkerhed: Ledger- og throughput-data i test skal være adskilt fra produktion. Anonymisering og audit som standard.
- Driftsovervågning: Observability skal måle både tilstandsdrift og læringsdrift. Uden præcis tidssynk snyder graferne.
- Omkostninger: Budgettér for længere træning og state management. Sæt stopklodser og målepunkter ind fra dag ét.
Derudover: vælg fejlinjektionsrater ud fra egen risikoprofil. En webhandel med peaks har en anden sandhed end et teleselskab med netværksspikes. Det er ikke bare en slider — reward kan hoppe, når controlleren skifter preset midt i et batch.
Incident-profiler i praksis
At “spejle egne incident-profiler” kræver en lille pipeline. I praksis kan den se sådan ud:
- Logudtræk: træk 6–12 måneders incident- og observability-logs med tidsstempler og kategorier.
- Mapping: map logkategorier til MORPHEUS’ 11 failure-typer. Dokumentér usikker mapping eksplicit.
- Fordeling: estimer per-typefrekvenser og samtidighed. Beregn sæsonmønstre og chok-hændelser separat.
- Preset-kalibrering: oversæt fordelingen til presets (5\/8\/15\/30 procent) eller lav brugerdefinerede kurver, hvis ingen preset passer.
- Validering: kør en backtest i simuleringen og sammenlign udfaldenes frekvens mod historiske logmønstre.
Det gør valg af rater og typer mindre gæt og mere metode. Og ja, det tager en uge. Det er tiden værd.
Evaluering ud over summen
Kilden beskriver et seks-metrik program: per-konfigurations reward, adaptationshastighed, glemsel, recoverytid, stabilitet og performance-gap. Adaptationshastighed er frontfiguren — antal skridt til den glidende gennemsnitsbelønning rammer halvdelen af en øvre grænse. Det giver mening, når miljøet skifter. En enkelt skalar skjuler for meget, så hold mindst to støttemetrikker åbne.
Der nævnes også to diagnoser: relativ adaptationsfordel og plasticitet via effektiv rang. Brug dem som fejlfinding — ikke som styrende KPI — så graferne hjælper jer med at skelne “hurtig tilpasning” fra ren støj.
Skepsis, huller og de kedelige spørgsmål
Hvor realistiske er de elleve failure-typer på tværs af brancher? Det er uklart i kilden. En sektorvis mapping (fx finans, telco, e-handel) bør laves, ellers overtræner man til en generisk fejlverden. Det samme gælder risikoen for overfitting til faste skift: asynkronitet hjælper, men mønstre kan stadig læres. Variér skiftkalenderen og indfør out-of-template hændelser.
Til sidst: omkostninger og skalerbarhed. Der mangler tal for wall-clock, GPU\/CPU-forbrug og hvordan OD-scheduleren opfører sig ved mange parallelle miljøer over dage. Spørg MLOps- og systemansvarlige, ikke kun forskere, når disse valg skal træffes.
Hvad konkurrenterne vil sige
Traditionelle benchmarks vil hævde, at episodiske opsætninger er nok til at sammenligne algoritmer fair og billigt. Persistent sims findes også, men MORPHEUS går længere ved at kombinere OD-nære operationer med fejlinjektion og en asynkron skiftcontroller. Det ændrer læringsdynamikken markant. Spørgsmålet er, om industrien vil betale driftsprisen for mere realisme.
Hvad man faktisk kan gøre nu
Start småt: pilottest med egne incident-profiler, egne KPI-vægte og en check af ledger-modellen mod historiske data. Brug det fælles SFT-checkpoint først, og gentræn SFT kun hvis domænet afviger klart fra de oprindelige traces. Mål adaptationshastighed som hovedindikator, og hold recoverytid som sekundær — indtil der foreligger flere caser.
Inden commit: kør determinismepakken, lav omkostningsestimatet, og lås preset-kalibreringen. Hvis de tre går igennem uden røde flag, er I klar til at skalere forsøget. Hvis ikke, stop, ret, og kør igen. Bedre nu end i produktion.
Et praktisk omkostningsestimat, uden tallene
Kilden giver ingen ressource-tal. Brug derfor en simpel skabelon ved indhentning fra leverandøren: miljøer_parallel × steps_pr_time × timer_pr_døgn × døgn_pr_kørsel × model_cost_per_step + checkpoint_cost × checkpoints_pr_time. Læg 20–30 procent buffer til for asynkrone skift og genkørsler. Det er ikke smukt, men det giver en tidlig bund under budgettet.
