TrueMem: Het bouwen van een model-agnostische geheugenlaag voor AI

Het wekelijkse ritueel

Elke vrijdag typ ik hetzelfde:

"Ik ben Prathamesh. Senior Software Engineer bij TrueFoundry. Ik werk aan de geheugenservice. Format: wat ik heb opgeleverd, wat in uitvoering is, blockers. Hou het beknopt."

Daarna vraag ik om mijn wekelijkse update.

De AI schrijft het perfect. Maar aanstaande vrijdag? Hetzelfde ritueel. Hij herinnert zich mijn naam niet, mijn rol niet, mijn project niet, en ook niet dat ik drie weken op rij dezelfde blocker heb genoemd.

Ik heb deze assistent zelf gebouwd: eenvoudige chat-UI, TrueFoundry's AI Gateway op de backend. Hij verwerkt stand-ups, e-mails, Slack-berichten, concepten voor documentatie. Hij is echt nuttig. Maar elke sessie begint bij nul. Ik gebruik het geheugen van de AI niet. Ik ben het geheugen van de AI.

ChatGPT heeft dit opgelost met een ingebouwd geheugen. Maar wanneer je je eigen LLM-applicatie bouwt, bestaat die infrastructuur niet. Je staat er alleen voor. Tenzij je het zelf bouwt.

Dus dat heb ik gedaan. TrueMem is een permanente geheugenlaag voor AI-applicaties. Het geeft elke LLM een langetermijngeheugen dat werkt over sessies heen en zelfs over verschillende modellen. Nooit meer jezelf herhalen. De AI herinnert het zich daadwerkelijk.

Waarom bestaande benaderingen niet werken

De voor de hand liggende oplossingen hebben voor de hand liggende problemen.

Het ingebouwde geheugen van ChatGPT zit opgesloten binnen het ecosysteem van OpenAI. Je kunt er niet programmatisch bij, het niet gebruiken met andere modellen, of controleren wat er wordt opgeslagen. TrueFoundry’s AI Gateway helpt ons om toegang te krijgen tot meerdere modellen en te controleren wat er wordt opgeslagen. Voor iedereen die zijn eigen applicaties bouwt, is het een no-go.

Retrieval-Augmented Generation (RAG) lost een ander probleem op. RAG haalt informatie uit documenten. Het beantwoordt de vraag "wat staat er in deze PDF?". Het geheugen van een gebruiker is fundamenteel anders. Het is persoonlijk, evolueert en is gebaseerd op een relatie. De feiten die ik in een gesprek deel, zijn geen documenten die geïndexeerd moeten worden; het is context die elke toekomstige interactie vorm zou moeten geven.

Het vergroten van context windows is de 'brute force'-benadering: voeg de gehele gespreksgeschiedenis toe. Moderne modellen ondersteunen 128K tokens of meer, dus waarom niet? Omdat tokens duur zijn, meer context leidt tot tragere inferentie, en alles verdwijnt zodra de sessie eindigt. Je betaalt de hoofdprijs voor amnesie met extra stappen.

Wat we nodig hebben is een toegewijde laag die gedestilleerde feiten over gebruikers permanent opslaat en alleen ophaalt wat relevant is voor elke query. Dat is het gat dat TrueMem opvult.

Leren van cognitiewetenschap

Het menselijk geheugen werkt niet door elk gesprek woordelijk op te slaan. We hebben een werkgeheugen voor de huidige taak en een langetermijngeheugen voor permanente kennis. De twee systemen werken voortdurend samen: herinneringen uit het langetermijngeheugen beïnvloeden hoe we nieuwe informatie interpreteren, terwijl belangrijke nieuwe ervaringen worden geconsolideerd in de langetermijnopslag.

TrueMem weerspiegelt deze architectuur met twee afzonderlijke componenten: Kortetermijngeheugen (STM) voor gesprekscontext en Langetermijngeheugen (LTM) voor permanente feiten over de gebruiker.

De scheiding is belangrijk omdat deze geheugentypes verschillende doelen dienen. STM legt vast wat er nu gebeurt, de volledige stroom van het huidige gesprek. LTM slaat gedestilleerde feiten op die in alle gesprekken behouden blijven. STM wordt altijd meegenomen in de context; LTM wordt opgehaald op basis van semantische relevantie. Proberen om beide met één mechanisme op te lossen dwingt tot een compromis. De duale benadering vermijdt dat volledig.

Kortetermijngeheugen: gesprekken coherent houden

Binnen een enkele chatsessie moet de AI zich herinneren wat je vijf minuten geleden hebt besproken. Dit is de taak van het STM, en het onderhoudt twee componenten: een lopende samenvatting van oudere berichten en de laatste twintig berichten in volledige precisie.

Naarmate een gesprek groeit, houden we continu het totale aantal tokens bij. Wanneer het een drempelwaarde overschrijdt, comprimeert een achtergrondproces oudere berichten in de lopende samenvatting, terwijl recente berichten intact blijven.

‍

Het samenvatten gebeurt asynchroon, dus gebruikers hoeven er nooit op te wachten. Wanneer de drempelwaarde wordt overschreden, haalt een achtergrondtaak niet-samengevatte berichten op, combineert deze met een eventueel bestaande samenvatting en genereert een bijgewerkte, uitgebreide samenvatting. Die berichten worden gemarkeerd als "gesammenvat" en de cyclus gaat door. Progressieve compressie betekent dat zelfs gesprekken van een uur binnen redelijke contextlimieten blijven.

Maar gesprekscontext alleen is niet genoeg. Wat gebeurt er als de gebruiker morgen terugkomt? Dat is waar het langetermijngeheugen in beeld komt.

Langetermijngeheugen: permanent begrip opbouwen

LTM slaat feiten over gebruikers op die voor onbepaalde tijd behouden blijven: hun naam, beroep, voorkeuren, communicatiestijl en al het andere dat het waard is om over gesprekken heen te onthouden. Deze worden niet opgeslagen als ruwe tekst. Ze worden geconverteerd naar vector embeddings, wat een semantische gelijkheidszoekopdracht mogelijk maakt.

Wanneer een gebruiker vraagt "Welke programmeertaal moet ik gebruiken?", zoeken we niet op trefwoorden in de opgeslagen herinneringen. We embedden de query en zoeken herinneringen die semantisch gerelateerd zijn. Herinneringen zoals "Gebruiker geeft de voorkeur aan Python" en "Werkt aan ML-infrastructuur" komen naar boven omdat ze conceptueel relevant zijn, zelfs zonder gedeelde trefwoorden.

Het systeem vult het LTM via twee kanalen. Expliciete herinneringen komen voort uit directe verzoeken: "Onthoud dat ik de voorkeur geef aan opsommingstekens" of "Vergeet niet dat ik allergisch ben voor pinda's." We detecteren triggerzinnen, extraheren het kernfeit en slaan dit op met de hoogste prioriteit. Deze herinneringen worden nooit automatisch verwijderd.

Automatische herinneringen komen voort uit gespreksanalyse. Wanneer een gebruiker opmerkt "Ik leid het ML-platformteam," is dat waardevolle context, zelfs zonder expliciet verzoek tot opslaan. Na elke interactie onderzoekt een achtergrondproces het gesprek en extraheert feiten die het bewaren waard zijn, elk voorzien van een belangrijksheidsscore.

Belangrijkheidsscores variëren van een tot vijf. Een vijf betekent kritieke informatie die nooit vergeten mag worden: expliciete instructies van de gebruiker, sterke voorkeuren, allergieën. Een vier staat voor belangrijke persoonlijke feiten zoals beroep of locatie. Drieën zijn algemene context zoals hobby's en interesses. Tweeën behandelen tijdelijke informatie zoals huidige projecten. Enen zijn kleine details. Expliciete herinneringen krijgen automatisch een vijf; automatische extracties scoren doorgaans tussen de een en vier, afhankelijk van hoe significant het feit lijkt.

‍

Er ontstaat een uitdaging bij automatische extractie: wat als een gebruiker in de ene sessie zegt "Ik hou van Python" en in een andere "Ik geef de voorkeur aan Python boven JavaScript"? Naïeve opslag veroorzaakt duplicaten. TrueMem lost dit op met semantische ontdubbeling. Voordat we iets opslaan, zoeken we naar bestaande herinneringen met een overeenkomst van meer dan 85%. Als er een vergelijkbare herinnering bestaat, werken we deze bij in plaats van een nieuwe vermelding aan te maken. De database blijft schoon, waarbij elk feit precies één keer voorkomt in zijn meest complete vorm.

Privacy wordt gewaarborgd door transparantie. Gebruikers kunnen elke opgeslagen herinnering bekijken, bewerken en verwijderen. Alle herinneringen zijn strikt geïsoleerd per gebruiker. Voor enterprise-implementaties draait het gehele systeem op jouw infrastructuur. Niets verlaat jouw omgeving.

Hoe zit het met de nauwkeurigheid van de extractie? Verschillende mechanismen pakken dit aan: belangrijksheidsscores zorgen ervoor dat automatische extracties eerder worden gesnoeid dan expliciete herinneringen; gebruikers kunnen fouten beoordelen en corrigeren; en correcte informatie die in meerdere gesprekken wordt bevestigd bouwt een hogere belangrijksheid op, terwijl eenmalige verkeerde extracties vervagen door natuurlijke opschoning.

Ophalen: snel relevante herinneringen vinden

Het opslaan van herinneringen is slechts de helft van het probleem. Wanneer een gebruiker een bericht stuurt, hebben we de juiste subset nodig: niet alles, alleen wat relevant is. Een power user kan wel 150 opgeslagen feiten hebben; ze allemaal toevoegen zou het context window laten exploderen.

Het proces embedt het bericht van de gebruiker, voert een cosine similarity search uit en retourneert de top tien overeenkomsten. Dit duurt minder dan 10 milliseconden met de juiste indexering.

Eén uitzondering: nieuwe gebruikers. Als iemand minder dan tien herinneringen heeft, voegen we ze allemaal toe, ongeacht de overeenkomst. Vroeg in een relatie telt elk stukje context. Zodra het aantal de tien overschrijdt, stappen we over op puur op overeenkomst gebaseerd ophalen.

Dit ophalen is onderdeel van een grotere contextpreparatiestroom en moet snel zijn.

De prestatie-uitdaging

Een geheugenlaag is alleen nuttig als het geen merkbare latentie toevoegt. Gebruikers zijn gevoelig voor vertragingen; zelfs 200 milliseconden voelt traag aan. Ons doel was minder dan 80ms voor contextpreparatie.

De sleutel is parallellisatie. Contextpreparatie omvat verschillende onafhankelijke bewerkingen: een embedding genereren, recente berichten ophalen, controleren op expliciete triggers en zoeken in het langetermijngeheugen. In plaats van ze sequentieel uit te voeren, starten we ze parallel.

‍

Het genereren van embeddings is het traagst met ongeveer 30 milliseconden, maar het draait parallel aan database-queries die in 10ms voltooid zijn. We betalen voor de langste bewerking, niet de som. De totale latentie komt uit op zo'n 45ms, ruimschoots onder het doel.

Zware bewerkingen zoals samenvatten en geheugenextractie draaien asynchroon nadat de respons is verzonden. De gebruiker hoeft nooit te wachten; de verwerking vindt plaats in achtergrondprocessen. Deze scheiding tussen het snelle synchrone pad en het trage asynchrone pad is essentieel voor productiegebruik.

Nu het geheugen betrouwbaar werkt, kwam er een onverwacht voordeel aan het licht: we hadden per ongeluk iets gebouwd dat model-agnostisch is.

Het onverwachte voordeel: geen vendor lock-in meer

Dit hadden we niet voorzien. Zodra het geheugen buiten het model leeft, zit je niet langer vast aan één provider.

Overstappen van GPT-4 naar Claude? Je geheugen blijft behouden. Verschillende modellen gebruiken voor verschillende taken, zoals complex redeneren met de een en creatief schrijven met de ander? Ze delen allemaal hetzelfde begrip van jou. Een custom model fine-tunen? Het erft vanaf dag één de bestaande gebruikersrelaties.

De geheugenlaag wordt je constante; modellen worden inwisselbaar.

De integratie blijft minimaal: haal de context op vóór de LLM-call, log de interactie achteraf. Twee API-calls veranderen elk stateless model in een model met een permanent geheugen. Geen SDK lock-in, geen complexe integratie. Gewoon HTTP-endpoints die in elke architectuur passen.

Natuurlijk kunnen herinneringen niet eeuwig blijven groeien. Een systeem zonder levenscyclusbeheer zou verdrinken in verouderde feiten.

Beheer van de geheugenlevenscyclus

Elke herinnering heeft een belangrijksheidsscore van een tot vijf. Expliciete instructies krijgen een vijf. Belangrijke persoonlijke feiten krijgen een vier. Algemene context krijgt een drie. Tijdelijke informatie krijgt een twee. Kleine details krijgen een een.

Wanneer het aantal een zachte limiet overschrijdt (standaard 150), wordt de opschoning geactiveerd. Het systeem komt nooit aan een belangrijksheid van vier of hoger. Bij herinneringen met een lagere belangrijksheid verwijder het eerst de herinneringen met de laagste score, waarbij leeftijd wordt gebruikt om de knoop door te hakken.

Expliciete instructies van de gebruiker blijven voor onbepaalde tijd bewaard. Automatische extracties met een lage waarde worden gerecycled om ruimte te maken voor nieuwe informatie. Het geheugen blijft relevant zonder handmatige curatie.

Alles samenvoegen

Een gebruiker opent een chat en typt: "Help me met het opstellen van mijn wekelijkse update, op basis van de volgende punten …"

‍

De app roept TrueMem aan voor context. TrueMem stelt STM en relevante LTM samen, waaronder "Naam is Prathamesh," "Senior ML Engineer," "Werkt aan geheugenservice." Dit duurt 45 milliseconden.

De LLM genereert een gepersonaliseerde respons: "Hier is je wekelijkse update, Prathamesh..." Geen ritueel. Geen hernieuwde introductie. De AI weet wie het vraagt.

Na het antwoorden logt de app de interactie. Achtergrondprocessen slaan berichten op, extraheren eventuele nieuwe feiten en werken samenvattingen bij waar nodig. Het zware werk gebeurt onzichtbaar op de achtergrond.

Technische keuzes

We hebben om pragmatische redenen gekozen voor PostgreSQL met pgvector boven dedicated vector databases. De meeste teams draaien al Postgres. Herinneringen staan naast gebruikersgegevens met volledige ACID-garanties. Voor verzamelingen van 100-200 vectoren per gebruiker levert pgvector een similarity search in minder dan 10ms. Voor geheugen op gebruikersniveau is het de juiste keuze.

Achtergrondprocessen draaien op door Redis ondersteunde wachtrijen omdat LLM-calls seconden duren, veel te lang om verzoeken te blokkeren. Workers kunnen mislukkingen opnieuw proberen, bewerkingen groeperen en onafhankelijk schalen zonder de latentie voor de gebruiker te beïnvloeden.

Geen rituelen meer

Herinner je je dat vrijdagse ritueel nog? "Ik ben Prathamesh. Senior Software Engineer. Ik werk aan de geheugenservice."

Met TrueMem gebeurt dat één keer. De AI onthoudt het. De update van aanstaande vrijdag werkt gewoon. Het e-mailconcept van volgende maand kent mijn handtekening. De context is er altijd.

Nog beter: stap over naar een ander model en het geheugen verhuist mee. De dagelijkse assistent wordt model-agnostisch zonder extra werk.

Dat is het doel. AI die jou onthoudt. Niet omdat je het blijft herinneren, maar omdat het dat daadwerkelijk doet.

‍