En praktisk tutorial demonstrerer, hvordan Memori kan fungere som hukommelseslag for LLM-agenter i et Google Colab-setup. Kort fortalt installeres memori, openai og nest_asyncio, og både synkron og asynkron OpenAI-klient registreres, så alle modelkald passerer gennem hukommelseslaget. I en notebook er det hurtigt at få op at køre. Nærmest for hurtigt, hvis man ikke passer på skopet.
Det konkrete afkast er genkendeligt. Agenter kan huske uden at få hele forhistorien gentaget i hver prompt. Vi har set samme mønster i interne prototyper hos virksomheder vi rådgiver. Tredje tur i samtalen bliver roligere, fordi man ikke starter forfra hele tiden.
Hvad tutorialen gør i korte træk
Tutorialen sætter Memori op i Colab, anvender nest_asyncio for at kunne køre asynkrone funktioner i notebookens event loop, og opretter både OpenAI- og AsyncOpenAI-klienter, som registreres i Memori. Dermed kan hukommelseslaget automatisk intercept’e og berige chat-kald uanset om de er sync eller async. Det hele samles i få linjer kode, så man hurtigt kan se, hvad der bliver gemt og hentet.
Eksemplerne er tydelige. Alice deler personlige fakta, der gemmes og kan hentes igen. Bob har sin egen isolerede hukommelse. Samme person kan have flere agent-roller via process_id, og sessioner holdes adskilt. Der vises også streaming, asynkrone kald og et lille kundesupport-flow, så man kan se, hvordan hukommelsen opfører sig i en multi-turn interaktion.
Hvordan Memori virker i praksis
Kernen er registreringen af klienterne og attribution, der sætter skopet. Når man kalder mem.llm.register for både synkron og asynkron klient, kan Memori læse og skrive kontekst omkring modelkaldet. Attributionen – fx mem.attribution(entity_id=”[email protected]”, process_id=”personal-assistant”) – afgør, hvilken identitet og rolle der skrives for, og hvad efterfølgende retrieval må se.
Efter et skriv indsætter tutorialen time.sleep(WRITE_DELAY) for at sikre persistens, før man spørger modellen igen. Det er groft, men effektivt i en demo. Alice fortæller om sig selv, hvorefter modellen bliver spurgt, hvad den ved om hende. Så skifter man til Bob og gentager. Der lækkes ikke mellem brugere i eksemplet. Senere varieres process_id for samme entity_id, så samme person kan have forskellige personaer, og session-isolation demonstreres. Logikken for skope er til at forstå, også for et team der ikke har set Memori før.
Hvornår det faktisk løser problemer
Persistens på tværs af henvendelser er guld i kundesupport, hvor kunder vender tilbage med samme produkt og historik. Isolation mellem brugere, roller og sessioner er forudsætningen for multi-tenant apps. Her hjælper Memori-tilgangen med at holde styr på, hvem der ejer hvad, uden at blande data sammen.
I personaliserede assistenter slipper man for promptyoga, fordi præferencer og forretningsregler ligger i hukommelseslaget. Vi har internt observeret, at teams kan skære ned på tokens og tid, fordi agenten ikke skal genfodres med identisk kontekst. Det er en observation fra et projektforløb, ikke en benchmark.
Implementerings- og driftsovervejelser
Latency først. Et memory-lag betyder retrieval før eller under generering. I tutorialen bruges WRITE_DELAY for at vente på persistens. Fint i en notebook. I drift skal man styre synlighed af writes for efterfølgende læsninger, ellers svarer agenten på forældet kontekst. Overvej køer, batch-writes og idempotente writes ved høj trafik. Mål 95-percentile for både læs og skriv, ikke kun median – det er haleoplevelsen brugerne husker.
Vektorrepræsentationer næste. Tutorialen nævner ikke, hvilke embeddings eller retriever-parametre der bruges. Det påvirker præcision og støj i hits. I praksis bør I tune embeddings, afstandsmål og top-k og overveje hybrid-søgning. Forkerte defaults giver enten for brede eller for snævre træf, og så ryger tilliden. Bed om klare defaults fra leverandøren, eller mål dem selv i en PoC.
Sync og async i samme app. Det er praktisk, at tutorialen registrerer begge klienttyper. Men nest_asyncio i Colab er ikke produktion. I en server styrer I event loop selv og undgår blokering mellem sync og async. Hold rene async-kæder til agentlogik eller placer et tydeligt grænselag, så kaldetyper ikke blandes. Vi har set sporadiske timeouts i en prototype netop pga. blanding – den slags dukker først op, når load stiger.
State-synk på tværs af sessioner. Når flere klienter skriver til samme brugerhukommelse i parallel, opstår eventual consistency. Definér acceptable staleness-vinduer, og log tid fra skriv til sikker læsning. Pipeline-strategier, hvor man streamer svar, mens memory skrives i baggrunden, kræver robust fejlhåndtering. Ellers svarer man på forældet viden og får mærkelige regressioner i dialogen.
Sikkerhed, governance og privatliv
Tutorialen henter API-nøgler fra miljøvariabler og kan køre uden Memori-nøgle på en rate-limited tier. Det viser tilgængelighed, ikke virksomhedssikkerhed. Der er brug for dokumentation om kryptering i hvile og transit, nøglestyring, rollebaseret adgang og auditlogs. I en multi-tenant hukommelse er adskillelse og sporbarhed ikke valgfrie. Spørg eksplicit til dataplacering, DPA, og hvordan adgang til enkelt-minder logges og revideres.
Retention og GDPR. Hvor længe gemmes data. Hvordan slettes brugerdata fuldt ud. Kan man eksportere alle minder for dataportabilitet. Tutorialen dækker det ikke. Arbejder I i EU-virksomheder, så få klare svar om slettepolitikker, slette-API’er og logning af behandling. Det lyder bureaukratisk, men det er først her, memory-laget bliver forsvarligt i produktion.
Hvad vi ikke ved endnu
Der er ingen kvantitative benchmarks i tutorialen. Ingen end-to-end latency under last, ingen throughput ved mange samtidige sessioner og ingen mål for token-besparelser. Kør derfor en egen PoC med målepunkter: 95- og 99-percentile responstid, time-to-consistency for writes samt tokens før og efter memory-integration. Uden det gætter man – og gæt holder sjældent i drift.
Guidance om standard-embeddings, retriever-parametre og eval-metrics for relevans over tid mangler også. Læg en simpel eval på: hit-rate på kendte fakta, precision@k og hvor ofte agenten opfinder relationer, der ikke lå i hukommelsen. Det er ikke smukt at måle på, men det virker – og giver ro i maven, når man skal skære prompts ned.
Alternativer og konkurrencebilledet
Samtidig rører Anthropic på sig. VentureBeat beskriver nye evner i Claude Managed Agents, der samler lag som memory, evaluering og multi-agent orkestrering i én runtime. Funktionerne Dreaming, Outcomes og Multi-Agent Orchestration adresserer samme problemrum, men via en samlet platformstilgang.
Valget står ofte mellem et via-lag som Memori, der passer ind i jeres stack, eller en mere monolitisk platform, der vil eje state, evals og orkestrering. Der er ikke ét facit. I komplekse miljøer kan modulært give frihed til at skifte model og retriever. Hvor drift og compliance vejer tungest, kan en samlet platform være lettere at revidere.
Reelle faldgruber vi har set
Vi så en prototype, hvor attribution manglede i ét kald. En kundes præferencer endte i en generisk agent-rolle, og svaret lækkede til en anden bruger senere. Én linje kode – og en ødelagt demo. Løsningen var simple guards og tests omkring attribution, men skaden var sket, og tilliden fik et knæk.
En anden sag. Sync-kald i en webserver trak i samme loop som async-opgaver og blokerede retrieval ved spidslast. Symptomet var 4–5 sekunders hikke – kun i staging med mange samtidige sessioner. Vi separerede kaldetyperne, kørte ren async for agentkæden og isolerede synkrone sideruter. Så forsvandt hakkene.
Hvad det betyder for din arkitektur
Bygger I multi-tenant assistenter eller supportværktøjer, giver tutorialen et brugbart blueprint til prototyper. Brug Colab til at verificere memory-scope mellem brugere, roller og sessioner. Byg derefter en lille service, hvor I måler latency, staleness og token-forbrug – med realistiske prompts fra egne logfiler, ikke opfundne cases. Læg et par negative tests ind, der bevidst forsøger at krydse skopegrænserne, så I fanger læk ved kilden.
Næste skridt er at vælge hostingstrategi for hukommelsen. Hosted memory er hurtig at komme i gang med. On-prem eller egen cloud giver kontrol over dataplacering, retention og nøglestyring. Vi anbefaler at teste begge tidligt i en PoC, fordi skift er dyre, når adoptionen først ruller. Start småt, men mål alt, også når det går godt.
Målepunkter der gør en forskel
- 95- og 99-percentile end-to-end latenstid med memory slået til (retrieval og generering)
- Time-to-consistency for nye minder – hvor hurtigt kan de ses af næste tur
- Tokenforbrug før og efter – se på kost per session, ikke kun per kald
- Relevans for memory-hits – hit-rate på kendte fakta og typiske fejl ved mis-hits
De mål er tørre, men afgørende for, om I kan skære ned på prompt-længde uden at tabe kvalitet – og om brugeren oplever, at agenten kender dem.
Vores vurdering og næste skridt
Memori-tilgangen i tutorialen er en realistisk måde at give agenter langtidshukommelse i apps med flere brugere og sessioner. Det er let at komme i gang i Colab, og mønstret med både sync og async klienter matcher mange stacks. Styrken er eksplicit attribution og klar skopelogik mellem entity, process og session. Uafklarede punkter er vektoropsætning, sikkerhed og ydeevne under belastning.
Rådet herfra er jordnært. Byg en lille PoC over to uger, få tal på bordet, og beslut derefter hosting og retriever-strategi. Mål latency og staleness, følg omkostning, og kør en simpel kvalitetsmåling på memory-hits. Først derefter giver det mening at skære prompts ned og stole på, at hukommelsen bærer samtalen. Man opdager først forskellen, når man sidder med det i hænderne.
