LLM’er starter uden bagage. Hvert kald er et nulstillet hoved. Det går fint til enkeltspørgsmål. Men bygger du en agent, der planlægger, kalder værktøjer og kører i flere trin, falder det fra hinanden uden hukommelse. En ny teknisk guide kortlægger syv hukommelsestyper og giver et sprog for noget, der tit omtales for løst.
Pointen er praktisk: Hukommelse gør et stateless modelkald til et system, der kan holde retning over tid. Ikke bare levere et svar, men holde styr på mål, erfaringer, fejl og regler. MarkTechPost siger det rent: LLM’er er stateless af design, og det bryder, når man går fra enkeltkald til agent‑workflows. Effekten rammer direkte i latency, omkostninger og sammenhæng i oplevelsen.
LLM’er er stateless – og hvorfor det skaber et hul i midten
Et API‑kald glemmer, hvad forrige kald så, så snart svaret er sendt. Uproblematisk i kort Q&A. Ubrugeligt, når en agent skal planlægge fem‑ti trin, lave værktøjskald, opsummere, rette kurs og genbruge læring. Uden hukommelse må agenten enten gensende alt i kontekst (dyrt, langsomt) eller gætte (ustabilt). Ingen af dele skalerer.
De to akser: form og tid
Arbejdshukommelse \/ In‑context: Det, der lige nu er i kontekstvinduet: systemprompt, seneste beskeder, værktøjsoutput, evt. mellemregninger. Styrke: lynhurtig, direkte. Svaghed: pladsen er knap, alt kæmper om tokens. Implementation: stram promptskabelon, summarization af lange spor, tokenbudget pr. sektion. Latens: lavt overhead, voksende med tokens. Operationsspørgsmål: Hvad er jeres hårde tokenbudget pr. kald, og hvad sker der, når det overskrides?
Semantisk hukommelse: Vedvarende lager af fakta, præferencer og domæneviden, uafhængigt af hvornår det blev lært. Eksempel: “brugeren foretrækker Python frem for JavaScript”. Implementation: profilskema i dokument- eller nøgle‑værdi‑lager, ofte suppleret med embeddings; alternativt en lille relationel model for entydighed. Størrelse\/latens: moderat per bruger eller domæne; hurtig ved indeks\/hash, langsommere ved vektorsøgning. Operationsspørgsmål: Hvem må skrive, og hvordan rulles fejlskrivninger tilbage?
Episodisk hukommelse: Log over hændelser, samtaler og task‑runs til erfaring og refleksion. Litteraturen nævner systemer som Reflexion og ExpeL, der gemmer post‑mortems. Implementation: append‑only log + embeddings for episodisk hentning; ofte segmenteret pr. bruger, opgave eller mission. Størrelse\/latens: vokser hurtigt; latens styres med præ‑embeddings og tidsvinduer. Operationsspørgsmål: Hvordan undgår I “log‑kloak” – alt gemt, intet genfundet med kvalitet?
Procedurehukommelse: Regler og færdigheder til at udføre opgaver uden at overveje hvert skridt: “sådan resetter man en adgangskode”, “sådan tolkes en CSV fra system X”. Implementation: prompt‑sektion med regler og trin; evt. finjustering på syntetiske demonstrationspar; for komplekse flows en DSL eller state‑machine. Størrelse\/latens: lille i prompten, men kan svulme ved mange regler; finjustering er hurtig ved inference, dyr at ændre. Operationsspørgsmål: Hvor bor den autoritative procedure, og hvem reviewer ændringer før produktion?
Ekstern \/ Retrieval‑hukommelse: Information uden for modellen, hentet ad hoc (RAG). Både dokumenter og tidligere agenthistorik. Implementation: vektordatabaser, chunking, indekser, reranking, cache af varme hits. Størrelse\/latens: kan blive stor; latens afhænger af pipeline, netværk og rerank. Operationsspørgsmål: Hvilken dokumenthygiejne og chunking‑strategi løfter faktisk F1 på rigtige spørgsmål – ikke kun offline‑scores?
Parametrisk hukommelse: Viden i vægtene: sprog, verdensviden, generelle mønstre. Kræver (gen)træning eller finjustering at opdatere. Implementation: pre‑training, SFT, instruktionstuning, evt. LoRA. Størrelse\/latens: konstant pr. model; hurtig opslag under generering; ingen I\/O. Operationsspørgsmål: Hvornår giver finjustering værdi nok i forhold til governance‑byrden ved ikke at kunne slette specifikke datapunkter?
Prospektiv hukommelse: Intentioner og planlagte mål: “kør batch i nat”, “følg op om 14 dage”, “genprøv trin 3, når API’et er tilbage”. Implementation: opgavekø\/scheduler koblet til agentens planlægning; deadlines og afhængigheder som første‑klasses objekter. Størrelse\/latens: lille til moderat; latens fra orkestrering, ikke LLM. Operationsspørgsmål: Hvad sker der ved genstart eller failover – mister systemet aftaler, eller rehydreres de deterministisk?
Konsekvenser for arkitektur og drift
Mere hukommelse betyder flere kald: flere retrievals, flere writes, flere tokens i kontekst. Latensen stiger – både gennemsnit og P99. Omkostninger følger: in‑context tokens er den dyre linje; lagring og vektoropslag løber op ved skala.
Konsistens bliver en daglig øvelse. Semantisk og episodisk hukommelse kan være uenige. Prospektive mål kan hænge, hvis en scheduler glipper. Og procedure i prompten kan komme i konflikt med en finjusteret færdighed i vægtene. Har to lag samme sandhed, så vælg en autoritetskilde – og håndhæv den.
Sikkerhed og compliance flytter ind i kernen. Vedvarende lagre indeholder persondata og forretningshemmeligheder. Der skal være adgangskontrol, revisionsspor og sletteprocedurer. Start i de non‑parametriske lag – de kan revideres og slettes uden retræning.
Driftsrisici når hukommelse skaleres
Skalering afdækker svagheder. P99‑spikes kan skyldes GPU‑memory‑pres, mættet KV‑cache, skæv AZ‑trafik eller autoscaling, der reagerer for sent. Det peger AWS på i en teknisk gennemgang med CloudWatch‑indsigt. Hukommelseslag øger risikoen, fordi et fejlet retrieval kan udløse genkald, fallback eller oppustet kontekst.
En praktisk tjekliste for MLOps\/SRE, koblet til hukommelseslagene:
- Overvåg tokenforbrug pr. sektion i in‑context og sæt hårde grænser. Alarmér ved drift.
- Mål hit‑rate og latens i vektorsøgning separat fra LLM‑latens. Log top‑N dokumenter til fejlsøgning.
- Hold øje med KV‑cache‑udnyttelse på inference‑noder. Saturation giver springvis P99‑stigning.
- Balancer trafik på tværs af zoner; se om AZ‑specifikke varme data påvirker retrieval‑latens.
- Test autoscaling med realistiske bursts. Husk koldstart i både compute og indeks‑cache i retrievalkæder.
- Indfør korrelations‑ID, der følger et helt agentløb gennem alle lag. Uden det bliver fejlfinding gætværk.
- Audit spor for semantisk og episodisk skrivning: hvem skrev hvad hvornår, og med hvilken score.
Praktiske mønstre og anbefalinger
Et robust standardmønster: RAG til viden og historik, sessionshukommelse i in‑context, segmenteret episodisk log og cost‑styret eviction. Mål retrieval‑kvalitet løbende – ikke kun ved go‑live. Hold semantisk profil lille og skarp; hellere få gode præferencer end en rodekasse.
Prioriter sådan: Gem først det, der forbedrer næste skridt. Ikke alt. Kog episoder ned til konklusioner efter et løb, så in‑context ikke drukner. Brug en simpel “kvalitet kontra pris” score til at afgøre, om indhold skal i konteksten nu, hentes via retrieval senere eller slet ikke gemmes.
Parametrisk hukommelse giver mening, når adfærd skal være konsistent, hurtig og upersonlig. Domænespecifik formatering, faste regler og tunge mønstre klarer sig godt med let finjustering. Brugerpræferencer og hyppigt skiftende politikker hører til i non‑parametriske lagre.
Tre realistiske implementeringsscenarier
1) Chat‑assistent med sessionshukommelse. Nøglevalg: stram systemprompt, kort sessionslog med summarization, lille semantisk profil pr. bruger. Tradeoffs: lav kompleksitet og fornuftig latens; risiko for kontekst‑glidning ved lange samtaler; privacy håndteres i de vedvarende lagre.
2) Planlægningsagent der orkestrerer værktøjer via RAG og episodisk log. Nøglevalg: vektorindeks over dokumenter og tidligere delopgaver, prospektiv scheduler til fremtidige trin og procedureregler i prompten. Tradeoffs: højere latens og flere kald; kvaliteten afhænger af retrieval‑score. Privacy kræver klare sleteregler for episodiske hændelser.
3) Kundesupport‑workflow med procedurehukommelse. Nøglevalg: formaliser procedurer i en DSL eller som tydelige prompt‑moduler, tillad begrænset finjustering for faste færdigheder, og kør semantiske kundedata uden for modellen. Tradeoffs: lav inference‑latens ved gentagne opgaver, men større governance‑byrde, når procedurer ændres. Privacy er skarp, fordi kundedata ligger i vedvarende lagre.
Hvad man bør gøre i morgen
Start med et audit af tokens i in‑context. Hvor ryger de hen – og hvad giver værdi? Fjern pynt.
- Kortlæg tre kontekster, der skal bestå over tid: typisk brugerpræferencer, aktive sager og faste regler. Alt andet kan leve i retrieval eller episodisk log.
- Opsæt en enkel RAG‑pipeline for dokumenter med kvalitetstests på rigtige spørgsmål – ikke syntetiske.
- Overvåg P99‑latens og KV‑cache‑metrics separat fra vektorsøgningens latens. Løs ét lag ad gangen.
- Etabler sikker opbevaring for persondata med adgangskontrol, revisionslog og sletteknap. Ingen bagdøre.
Kilderne er enige – og hvor de halter
MarkTechPost lægger rammen: LLM’er er stateless, og agenter kræver hukommelse for flertrinsplanlægning, værktøjskald og løb over tid. Manual‑briefs peger på de praktiske konsekvenser i drift: uden hukommelse stiger latens og antallet af kald, og brugeroplevelsen taber tråd. AWS’ tekniske note forklarer konkrete P99‑årsager og hvad man kan måle på. Der er god konsistens her.
Men der er huller. Ingen af kilderne går i dybden med datamodeller til episodisk opslag – fx chunking, embeddings og tidlige filtreringer i virkelige workloads. Der mangler også tal for pris og latency ved forskellige designvalg. Effekten af retrieval‑kvalitet på agentsucces er heller ikke solidt målt. Og systemer som Reflexion og ExpeL nævnes uden indsigt i intern arkitektur.
Konklusion og åbne spørgsmål
Hukommelse er ikke pynt. Det er infrastrukturen, der forvandler en stateless LLM til en agent, der kan holde kurs og lære af egne forløb. Syv hukommelsestyper giver et sprog til at vælge, hvad der skal bo i kontekst, udenfor eller i vægtene – og hvor længe. Resten er disciplin: klare autoritetskilder, målinger gennem kæden og enkle regler for, hvad der gemmes – og hvornår der slettes.
Åbne spørgsmål: Hvordan styrer man livscyklus for procedurer over måneder og år uden at kvæles i change‑management? Hvordan holdes prospektive mål stabile på tværs af genstarter og failovers? Og hvornår vinder finjustering over en god RAG‑pipeline i praksis – ikke på whiteboardet?
