Et nyt preprint foreslår en jordnær løsning på et voksende problem: store sprogmodeller står stille, verden gør ikke. Forskerhold fra National University of Singapore, MIT CSAIL, A*STAR og SMART præsenterer MEMO, en modulær tilgang hvor en lille, dedikeret hukommelsesmodel (MEMORY) lægger ny viden ind, mens hovedmodellen (EXECUTIVE) forbliver frossen og behandles som en sort boks. I deres forsøg bruges Qwen2.5-14B-Instruct som MEMORY og enten Qwen2.5-32B-Instruct eller Gemini-3-Flash som EXECUTIVE. Ifølge den gennemgang vi har set, kræver det ikke adgang til vægte eller logits – netop pointen her.
Retræning af en fuld LLM i moderne skalaer er uden for rækkevidde for de fleste. Samtidig risikerer klassisk fine-tuning at ødelægge gammel viden (catastrophic forgetting). Og RAG bliver skrøbelig, når svar kræver tværgående resonnering over mange kilder. Det er bagtæppet for MEMO. Timingen er rigtig, fordi generativ AI nu skal levere i produktion – med krav til latenstid, sporbarhed og styring, ikke kun demoer.
Problemet med statiske modeller og dyr retræning
Store sprogmodeller bliver statiske efter pretraining. De opdaterer ikke ny viden automatisk, selv om kilder og fakta skifter. I praksis: en produktionsmodel kan lyde klog i marts, knap så klog i oktober. Kilderne vi har læst, understreger omkostningen ved fuld retræning og risikoen ved fine-tuning. Det er ikke nyt – men det betyder noget i drift.
Vi har set det selv. I et anonymiseret projekt med adapter-opdateringer i et sagssystem opstod uventede regressioner i 2 ud af 5 releases. Ikke store katastrofer, men nok til, at supporten stak af et par uger ad gangen. Det sidder i fingrene, når man har ryddet op efter det en mandag morgen, hvor kaffemaskinen lød som en fjern støvsuger.
Tre veje der findes i dag – og deres svagheder
Der er tre udbredte tilgange til at holde modeller aktuelle. Først RAG, hvor man henter dokumenter ved inferens. Det virker til meget, men er sårbart over for støj i søgningen og har svært ved tværdokument-resonnering. Dernæst parametriske opdateringer – kontinuerlig pretraining eller supervised fine-tuning – som indlejrer ny viden i vægtene, men er dyre og rammes af catastrophic forgetting. Endelig latent memory med bløde tokens, som komprimerer viden i særlige repræsentationer. Problemet er kobling: de tokens passer til én bestemt model og mister værdi, hvis man skifter EXECUTIVE.
Ser man nøgternt på det, er der ingen sølvkugle. RAG er fleksibel, men sensitiv. Fine-tuning er stærk, men risikabel. Latent memory er smart, men låst. Det er rammen, MEMO forsøger at bryde op i.
Hvad MEMO faktisk foreslår
Forslaget er at skille hukommelsen ud som en separat, lille LLM, trænet på ny viden, mens den store hoved-LLM holdes frossen. I de beskrevne forsøg er MEMORY Qwen2.5-14B-Instruct, og EXECUTIVE er enten Qwen2.5-32B-Instruct eller Gemini-3-Flash. Vigtigt: EXECUTIVE behandles som en sort boks. Ingen vægtadgang, ingen logits. Kun almindeligt input-output. Det betyder, at man kan bruge proprietære modeller som Gemini-3-Flash uden intern adgang. For drift gør det en forskel – du kan udskifte eller versionere hukommelsen uden at røre hovedmotoren.
Det lyder som en lille arkitekturdetalje, men i praksis er afkobling mellem komponenter ofte det, der redder jer senere. Monolitter er hurtige at starte og tunge at holde. Her bliver MEMORY en udskiftelig del, der kan opdateres, rulles tilbage eller køres parallelt.
En femtrins data-syntese før træning
Inden MEMORY trænes, kører holdet en generatorstyret pipeline, som laver en refleksions-QA-dataset ud fra rå dokumenter. I forsøget er generatoren Qwen2.5-32B-Instruct. De fem trin opsummeres sådan: først faktudtræk (både direkte og implicitte), så konsolidering af QA-par med fælles kontekst, derefter verifikation og omskrivning for at fjerne uafklarede referencer. Fjerde trin er entity surfacing, som drejer spørgsmålene, så svarene fremkalder selve entiteten (hjælper mod den såkaldte reversal curse). Femte trin er tværdokument-syntese, hvor generatoren samler spor på tværs af tekster. Ifølge kilden er trin fem både det vigtigste og den største kilde til træningspar; fjerner man det i en ablation, falder nøjagtigheden markant på NarrativeQA.
Det er elegant – og skrøbeligt. Vi har flere gange oplevet, at generatorleddet bliver den svageste kæde: dårlige synteser betyder dårlige QA-par og en memory, der lærer forkerte koblinger. Forestil dig et internt notat med gentagelser, forkortelser, stavefejl. Generatoren kan let trække de forkerte tråde sammen. Derfor kræver pipelinen stærk verifikation og klare kasseringskriterier.
Hvor robust er pipelinen i praksis
En god pipeline er ikke bare prompts og held. Den skal kunne håndtere misvisende kilder, fragmenterede tidslinjer og overlappende entiteter. Trinene for verifikation og omskrivning hjælper, men kun hvis generatoren har tilstrækkelig kvalitet og der er en eksplicit regel for, hvad der kasseres. Det er ikke gratis. Compute-mæssigt er generatoren typisk en stor model, og ved større korpora bliver omkostningen mærkbar i GPU-timer eller API-forbrug. Her er skalerbar orkestrering og observability vigtige – også fordi fejl ellers først opdages, når memory’en bliver spurgt i produktion.
En intern måling hos os: ekstra API-kald mod en ekstern black-box LLM løftede 99-percentil-latency med cirka 30–80 ms, afhængigt af netværk og model. Det lyder småt, men i flows med flere sekventielle kald bliver det hurtigt synligt i brugeroplevelsen. Den slags tal skal med i en PoC, ellers bliver økonomien pæn i regnearket og skæv i virkeligheden.
Praktiske konsekvenser for drift
Afkoblingen kommer med et prisskilt. Latenstid: to modeller i spil betyder flere kald og dermed højere p99. Integrationskompleksitet: EXECUTIVE er en sort boks, ofte via API, mens MEMORY er jeres ansvar at versionere og opdatere. Konsistens: hvad hvis vektorstore og MEMORY svarer forskelligt på samme spørgsmål efter en opdatering. Overvågning: I får nu to fejlkilder i stedet for én. Til gengæld bliver rollback nemmere – i det mindste for MEMORY.
På versionsstyring anbefaler vi at behandle MEMORY som et rigtigt produktartefakt: semantisk versionering, changelogs bundet til dokumentbatch og automatisk regressionstest på faste QA-suiter før promotion. Ved opdateringsfrekvens bør man starte konservativt – fx ugentlige batches – og først skrue op, når driftstesten viser stabilitet. Konsistens mellem MEMORY og retrieval-lagret kan håndteres med en simpel prioriteringsregel i orkestreringen og et diff-dashboard, der viser afvigelser på nøglespørgsmål.
Hvor MEMO hjælper – og hvor det ikke er magi
MEMO giver særlig mening, når I har store, strukturerede dokumentmængder, som opdateres løbende: produktmanualer, compliance-noter, change logs, domæner med rige entiteter og relationer. Netop tværdokument-svar (hvem gjorde hvad, hvornår, på tværs af tre opdateringsnoter) knirker ofte i ren RAG. En trænet MEMORY kan reducere støjen og gøre svarene mere stabile uden at ændre hovedmodellen.
Hvor hjælper det mindre. Hurtigt skiftende fakta, hvor verifikationskæder og kilder er svage (rygter, realtime feeds). Her er stærk RAG med værktøjsintegration og kildevisning stadig bedre, fordi man ønsker kildekæden frem i lyset. Også i domæner med krav om stram formel nøjagtighed på tal og enheder kan RAG + kalkulationsværktøj slå en parametrisk memory, fordi fejltolerance er nul.
Sikkerhed, governance og verificering
Når MEMORY kan ændre svar uden at røre hovedmodellen, flytter governance sig. Testen skal ligge tættere på datasyntesen og træningen. Vi bruger typisk tre lag: en fast regressionssuite af QA-par før hver promotion; en integrationstest, hvor EXECUTIVE spørger MEMORY på realistiske user journeys; og en A\/B-test i skyggeproduktion med metriker for factuality, referencetæthed og andel af svar med kildekonflikt. Fejltærskler bør være eksplicitte og knyttet til rollback-automatik.
Hallucinationsrisikoen skal måles, ikke bare frygtes. Brug målinger som andel af svar uden dækning i korpus (målt via retrieval-overlap), konsistens over tid på faste queries og differensen mellem MEMORY- og RAG-svar på samme spørgsmål. Ved højrisko-svar – juridisk, finansielt, medicinsk – bør der være menneske-i-loop gating med simple kriterier: lav entitets-sikkerhed, modstridende kilder eller nyhedsdato under en given grænse.
Latency, cost og orkestrering
Ekstra kald koster. I en PoC bør I budgettere latenstid i tre lommer: kald til EXECUTIVE, kald til MEMORY og eventuel retrieval. P99 er vigtigere end middel. For cost laves et simpelt skema pr. 1000 forespørgsler med gennemsnitligt antal subkald i MEMO-protokollen. Husk compute til data-syntese – generatoren er ofte den dyreste post under træning. Og ja, serverless orkestrering og tydelig state management gør livet lettere, især når flows bliver multi-turn og conditionelle.
Observability er ikke pynt. Log de enkelte trin i MEMO-protokollen, version-id for MEMORY, korpus-hash og beslutningsgrene i EXECUTIVE. Når et svar fejler, vil I se præcis hvilken QA-par-version der lå til grund. Den sporbarhed afvæbner lange tirsdagsmøder.
Implementering – fra idé til PoC
Start med et smalt domæne og 200–500 nøglespørgsmål, som dækker jeres vigtigste brugssituationer. Byg en første datasyntese på et kontrolleret dokumentbatch. Træn en mindre MEMORY og fastlæg en baseline med ren RAG. Mål: factuality mod kendte facit, latenstid p50\/p95\/p99, andel af svar med kildekonflikt og omkostning pr. 1000 forespørgsler. Sæt en simpel rollback op – en feature flag, der skifter MEMORY-version eller degraderer til RAG-only på udvalgte flows.
Generator-kravene bør vurderes nøgternt. Hvis generatoren ikke klarer tværdokument-syntese godt, er det spild at træne en stor MEMORY. Vi har flere gange valgt at forbedre kilde- og dokumenthygiejne, før vi rørte træningen. Trivielt – men det virker.
Fallbacks og driftsvagter
MEMO skal ikke stå alene i kritiske flows. Brug et ensemble som fallback: hvis EXECUTIVE+MEMORY giver lav sikkerhed eller modstrid, så slå over på RAG med strikte kildekrav – eller bed om menneskelig vurdering. Definér degraderingskriterier i orkestreringen, ikke i hovedkoden. Og hav alarmsignaler: spikes i p99, stigning i konfliktmålinger eller fald i regressionsscorer ved nightly tests.
Rollback-strategier bør være kedelige og pålidelige: version-pinning af MEMORY, migrationsnoter for hver korpusændring og en lille “graveyard” over QA-par, der er kasseret med begrundelse. Det føles bureaukratisk, men sparer jer den sene torsdag med gætterier.
Huller vi stadig mangler at få lukket
Preprintet vi har set, efterlader åbne spørgsmål, som bliver afgørende i praksis. Langtidsholdbarhed: hvordan holder en MEMORY efter mange opdateringscykler, måned efter måned. Multi-executive: kan en enkelt MEMORY generalisere pænt på tværs af flere black-box-LLM’er i samme produkt. Robusthed: hvad sker der ved misvisende eller ondsindede kilder i datasyntesen – er der mekanismer mod data poisoning. Og endelig rene tal: GPU-timer til træning, hukommelsesfodaftryk samt end-to-end latenstid og kroner-øre sammenlignet med RAG eller adaptere.
Der er også en juridisk snubletråd. Brugen af proprietære EXECUTIVE-modeller som Gemini-3-Flash i kommercielle miljøer rejser licens- og compliance-spørgsmål, som bør afklares tidligt. Ikke et forskningsspørgsmål, men meget virkeligt, når man ruller ud i EU med auditkrav og kundedata.
Det store billede i produktion
Kursen i industrien er tydelig: generativ AI flytter fra demo til drift med krav om latenstid, skalerbarhed, state management og observability. MEMO lægger sig rent i den bevægelse. Det skærer ned på retræning og risici ved fine-tuning, men skubber til gengæld tyngden over i data- og orkestreringslaget. Det er en god handel, hvis man vil eje de lag disciplineret.
Idéen er nøgtern og brugbar. Ikke magi. Men en pæn måde at få ny viden ind uden at pille ved det, der virker. Vi testede ikke MEMO-opsætningen én-til-én i går, men vi genkender mønsteret: adskil ansvarsområder, mål det, og giv jer selv en vej tilbage, når noget driller. Forskellen mærkes først, når man sidder med det i hænderne.
