Att bygga ett personligt minne runt en lokal LLM
– eller varför arkitektur slår rå GPU-kraft
Jag började inte med en tydlig målbild. Det fanns inget ”nu ska jag bygga ett minnessystem för LLM:er”. Det började snarare med en liten irritation: känslan av att varje ny chatt började från noll, trots att jag själv tänkte iterativt, långsamt och ofta i sidospår.
Jag använder lokala modeller via Ollama och Open WebUI. I praktiken innebär det att jag pendlar mellan två system: en kraftfull speldator med GPU och en betydligt svagare garageserver som fallback via Nginx. Det i sig sätter gränser. Allt som är för tungt i prompten känns direkt när man hamnar på CPU.
Det var där min fråga uppstod:
Hur får man kontinuitet i AI?
Insikten blev att minne inte är samma sak som kontext.
Det är lätt att tänka att lösningen är ”större kontextfönster”. Mer tokens, mer historik. Men i praktiken är det precis tvärtom, särskilt på en CPU (eller har svagt grafikkort)
– stora prompts är dyra för prestandan
– Cache växer
– varje genererad token blir långsammare
Så i stället för att försöka få modellen att minnas allt, tänkte jag:
Vad är det minsta möjliga som behöver följa med för att samtal/chat ska kännas sammanhängande?
Svaret blev inte lång historik. Det blev ett specialicerat minne.
Minne som ett externt system utanför modellen.
Det avgörande var att separera tre saker som ofta blandas ihop:
1. Chatthistorik – allt som sagts (för insyn och backup)
2. Långtidsminne – sådant som bör kunna återkallas senare
3. Aktuell kontext – det modellen faktiskt ser just nu
När man gör den separationen blir det uppenbart att modellen inte ska se hela historiken. Den ska se ett urval av endast relevant bakgrund.
Det är exakt där embeddings och RAG hör hemma.
Men automatiskt minne har en nedsida.
Det problemet dök upp snabbt. Om allt som låter viktigt automatiskt sparas, blir minnet snabbt rörigt. Ännu värre fel saker får för hög prioritet.
Jag ville inte ville ha ett ”smart” system som gissar vad som är viktigt. Jag ville ha ett förutsägbart system.
Lösningen blev till vissa delar manuell, men en lättviktig märkning/tagning.
Markörer som speglar hur du tänker.
Efter en hel del förenklingar landade jag i tre begrepp som täcker nästan allt jag bryr mig om:
KRAV – saker som inte får brytas
BESLUT – val som redan är gjorda
VIKTIGT – bakgrund och preferenser
Och för att det ska fungera i praktiken (även på mobil) behövde syntaxen vara trivial. Resultatet:
KOM IHÅG KRAV.
KOM IHÅG BESLUT.
KOM IHÅG.
Inga hakparenteser. Inga kolon. Bara en punkt.
Det låter banalt – men det gjorde systemet mindre komplext och mer skalbart.
Parallellt insåg jag att allt inte ska ligga i samma mentala låda. När man jobbar med lokal LLM-arkitektur tänker jag annorlunda än när jag tänker på nätverk, eller på skrivprojekt eller spelutveckling (lore).
Så projekt introducerades, men med en viktig begränsning:
Projekt är till för mig som person, inte för operativa agenter.
När jag senare började tänka på LLM-styrda playerbots i AzerothCore blev det tydligt att de inte hör hemma här alls. De ska leva i en egen instans, på en annan port, med egen minnespolicy.
Den insikten gjorde arkitekturen renare.
Det fanns ett vägval: optimera olika profiler för GPU och CPU, eller köra samma överallt.
Jag valde medvetet en kompromiss:
– ett minnesblock runt 400 tokens
– Top-K = 3
– checkpoints som sammanfattar i stället för att ackumulera
Det gör systemet tillräckligt snabbt på garageservern, tillräckligt smart på speldatorn och enkelt att drifta.
Slutresultatet
Det som började som en irritation slutade i en arkitektur som:
– ger lång kontinuitet utan stora prompts
– fungerar både med och utan GPU
– är lätt att replikera till nya instanser
– inte försöker vara smartare än användaren
Vad har du för tankar kring AI modeller och hur de kan visareutvecklas?