[!NOTE] Automatische vertaling Dit artikel is automatisch vertaald vanuit de oorspronkelijke Engelse versie.
AI-agentgeheugen: Schema-gestuurde getypeerde staat voor langlopende systemen
Langlopende agenten halen vaak verouderde feiten op, omdat gewone semantisch geheugen geen regels bevat om te bepalen welke waarde actueel is.
Wanneer een gebruiker de vervaldatum van een paspoort wijzigt van 15 juli naar 30 juni, kan vectorsearch beide verklaringen ophalen. Een gestructureerd geheugenlaag moet dan vastleggen dat de waarde van 30 juni de eerdere vervangt.
TL;DR: Beschouw duurzaam agentgeheugen als getypeerde toepassingsstaat. Haal kandidaten uit het geheugen op via een grens voor gestructureerde uitvoer, sla records op met tenant-specifieke reikwijdte, geldigheidsperioden, vervanging, herkomst en schema-versiebeheer, en haal bij lezen alleen het meest actuele deel op. Reserveer vectorsearch voor vage zoekopdrachten. Lees wijzigbare feiten uit gescopeerde, actuele records.
De valkuil van het contextvenster
Het contextvenster is de invoer die beschikbaar is voor één modelaanroep. Een applicatie kan berichten doorgeven aan latere aanroepen, maar de applicatiepolitiek moet bepalen welke oude feiten nog geldig zijn en wie ze mag zien.
Langlopende agenten moeten voorkeuren, taakstatus, klantgegevens, keuzes voor hulpmiddelen, compliantienotities en eerdere fouten onthouden. Een eenvoudige manier is om samenvattingen toe te voegen of oude notities in een vectorstore te dumpen. Dit werkt zolang geen van de opgeslagen feiten verandert.
Dan heeft de agent twee vervaldata van paspoorten, twee favoriete formaten of twee projectbeslissingen. Semantische zoekopdrachten kunnen beide ophalen. Een samenvatting kan er één overschrijven. Een lange context kan het verouderde feit naast het actuele tonen. Deze ontwerpen leveren tekst op, maar zorgen er niet voor dat de huidige waarde wordt afgedwongen.
Het contract moet concrete vragen beantwoorden:
- Wat is nu waar?
- Wat was er op 2 juni waar?
- Wie heeft dit gezegd?
- Tot welke tenant behoort het?
- Welk oudere feit is hiermee vervangen?
- Kan ik het verwijderen of laten verlopen?
Schema-gestuurd agentgeheugen (SGAM) slaat deze antwoorden op als velden en relaties, in plaats van ze impliciet in tekst achter te laten.
Wat SGAM betekent
Drie vergelijkend genoemde concepten bepalen het bereik van SGAM.
Schema-gestuurde dialoog (SGD) is het 2019 Google task-oriented dialogue dataset. Het schema beschrijft service-API’s, intenties en slots, zodat een dialoogmodel de staat van diensten die het nog niet eerder heeft gezien, kan bijhouden. Het vormt een nuttig voorbeeld voor schema gebaseerd tracking, met een beperkt bereik tot dialoogservices.
Schema-gestuurd geheugen (SGM) is de onderzoeksterm die door Mei et al. wordt gebruikt in According to Me: Long-Term Personalized Referential Memory QA. In het artikel worden vrije-tekst Beschrijvend geheugen (DM) vergeleken met geheugenitems met vaste schema’s in sleutel-waardevorm. Beide representaties bevatten dezelfde broninformatie in verschillende structuren.
In dit artikel gebruik ik Schema-gestuurd agentgeheugen (SGAM) om een engineeringpatroon aan te duiden waarbij schema’s de schrijving, update, opvraag en verwijdering sturen. Het schema definieert de toepassingsstaat en diens levenscyclus.
ATM-Bench laat zien waarom deze representatie belangrijk is. Het maakt gebruik van ongeveer vier jaar aan persoonlijke gegevens uit e-mails, afbeeldingen en video’s. De vragen vereisen persoonlijke referenties, locatie, meerdere bewijsstukken en tijdsgebonden updates. De prestaties dalen bij een strikte scheiding, terwijl SGM beter presteert dan DM, omdat de opvraagger rechtstreeks velden zoals tijd, bron, locatie, entiteiten en tags kan benaderen.
SGM versus DM beantwoordt een vraag over opslag: moet geheugen als vrije tekst blijven, of moeten er genummerde velden worden gebruikt? Een productieagent heeft nog een probleem voordat het gegevens opslaat. Hij moet uit een ongestructureerd gesprek afleiden welke geheugenwijziging voorstelbaar is. Schema-Guided Reasoning (SGR) definieert die beslissingsweg: onderzoek de bewijzen, identificeer het onderwerp en de attributen, controleer of het feit de huidige staat wijzigt, en stel vervolgens een mogelijke schrijfwijziging voor. SGAM past na die modelaanroep de regels met betrekking tot opslag en levenscyclus toe.
Scheiding van modelextractie en eigendom van geheugen
Een schrijwing in het geheugen gaat door drie lagen heen. Structured Output (SO) zorgt ervoor dat het gevormde object aan de vereisten voldoet. Schema-Guided Reasoning (SGR) codeert de stappen en de volgorde die het model moet volgen om tot dat voorstel te komen. Schema-Guided Agent Memory (SGAM) beheert het voorstel als duurzame staat nadat de modelaanroep heeft plaatsgevonden.
Een oordeel, route of plan vervalt meestal samen met de huidige aanvraag. Een latere uitvoering kan dagen later nog een geheugenvoorstel lezen of dit gebruiken om een toolaanroep te kiezen. Die langere levensduur vereist opslagregels die SGR niet biedt.
SGR beperkt één modelaanroep door de redeneringstopologie ervan te definiëren. Voor een schrijving in het geheugen kan het schema bronbewijzen, gecentraliseerde onderwerpen en attributen, een vergelijking met de huidige staat eisen, en pas daarna de voorgestelde update toestaan. Pydantic of JSON Schema beschrijft die weg. Provider-specifieke Structured Output of een geleide decoderingssnelkoppelingslaag zoals XGrammar voorkomen dat het model velden overslaat of een andere vorm retourneert.
Het schema kan geen correcte conclusie garanderen. Het maakt de benodigde beslissingsweg expliciet en controleerbaar, inclusief de bewijzen en de vergelijkingen die tot het voorstel hebben geleid.
SGAM beslist wat er gebeurt nadat het object bestaat. Moet het worden opgeslagen? Vervangt het een oudere waarheid? Welke gebruiker mag het zien? Is het actueel of historisch? Welk bronmoment ondersteunt het?
De tabel geeft het eigendom en de foutmodi van elke laag weer:
| Dimensie | SO | SGR | SGAM |
|---|---|---|---|
| Doel | Een object teruggeven dat voldoet aan een schema | Het model begeleiden langs een vooraf gedefinieerde redeneringsweg | Duurzame geheugeninformatie beheren na de modelaanroep |
| Reikwijdte | Eén gegenereerd antwoord | Eén redenerings- en besluitweg binnen één modelaanroep | Gegevens die worden gebruikt tussen verschillende aanroepen, sessies en uitvoeringen |
| Rol in schema | Definieert uitvoervelden, typen en toegestane waarden | Definieert tussentijdse redeneringsstappen en het eindbesluit | Definieert opgeslagen gegevens, relaties en hun levenscyclus |
| Toepassing | Beperkt de decodering om ongeldige uitvoer te voorkomen | Maakt gebruik van SO om elke gedefinieerde stap en het eindbesluit af te dwingen | Toepassingsvalidatie, databasebeperkingen en conflicterulen |
| Levensduur | Huidige aanroep, tenzij de applicatie het object opslaat | De redeneringstrace wordt meestal verwijderd nadat het besluit is genomen | Blijft bestaan totdat het wordt bijgewerkt, verlopen is of verwijderd |
| Foutmodus | Correcte structuur met verkeerde betekenis | Nodige stappen zijn aanwezig, maar de redenering kan nog steeds fout zijn | Verouderde, vervuilde, onbepaalde of niet te controleren toestand |
Op de schrijfweg is de volgorde als volgt:
SGR reasoning schema + Structured Output -> candidate write -> SGAM policy and persistence
Het volgende illustratieve fragment uit memory_models.py definieert het object dat vanuit de extractiefunctie naar de SGAM-schrijfservice wordt doorgegeven:
from datetime import datetime
from pydantic import BaseModel, Field
class MemoryDelta(BaseModel):
tenant_id: str = Field(description="Isolation boundary, e.g. acme")
subject: str = Field(description="Normalized entity ID, e.g. mira")
attribute: str = Field(description="Property being updated")
value: str = Field(description="New value")
valid_from: datetime
source_episode_id: str
MemoryDelta geeft weer wat het model heeft geëxtraheerd. De SGAM-schrijfservice beslist vervolgens of dit moet worden afgewezen, samengevoegd of opgeslagen.
Schrijf- en leeswegen hebben verschillende taken
SGAM beschikt over zowel een schrijfweg als een leesweg. Alleen de schrijfweg wijzigt de opgeslagen staat. De leesweg selecteert de benodigde gegevens voor de huidige vraag.
De ingestroomflow is de schrijfweg:
- Een ruwe episode vastleggen uit berichten, toolresultaten of bedrijfsgebeurtenissen.
- Gestructureerde kandidaten extraheren via de uitvoer.
- Het schema valideren en ongeldige invoer weigeren.
- Conflicten oplossen, verouderde gegevens sluiten en de herkomst bewaren.
- Het record committeren in de SGAM-opslag.
De verzoekflow is de leesweg:
- Beginnen met de vraag van de gebruiker.
- Beslissen of er behoefte is aan de huidige staat of aan een staat op een specifiek tijdstip.
- Filteren op tenant, geheugentype, onderwerp, attribuut en geldigheidsperiode.
- Alleen vector- of grafexpansie toevoegen wanneer een exacte staatsonderzoek niet voldoende is.
- De kleinste benodigde context samenstellen voor het model.
Lees dat diagram van links naar rechts in twee rijen. In de bovenste rij wordt geheugen geschreven, in de onderste rij wordt het gelezen. Beide maken gebruik van dezelfde opslag.
Wat hoort bij een geheugenschema
Een minimale SGAM-record vereist meer dan text.
tenant_id
memory_id
subject
attribute
value
memory_type
schema_version
valid_from
valid_to
supersedes_memory_id
source_episode_id
confidence
retention_policy
Met deze velden kan een nieuwe verlopendatum voor een paspoort de vorige datum vervangen zonder de historie te wissen. Dezelfde tabel kan zowel huidige als tijdsgebonden queries verwerken en vervolgens het resultaat terugleiden naar het oorspronkelijke incident. schema_version ondersteunt migraties, terwijl retention_policy aan verwijderingsprocessen aangeeft welke andere elementen ze ook moeten verwijderen.
Gebruik RAG om documenten op te halen en SGAM om een wijzigbare staat bij te houden. Vectorsearch blijft noodzakelijk in het systeem voor vage zoekresultaten, clustering en uitbreiding. De huidige waarde van mira.passport_deadline moet afkomstig zijn van een gespecificeerd geheugenrecord, en niet van het willekeurige fragment dat toevallig bovenaan staat.
Een voorbeeld van verouderde feiten
Stel je een synthetisch twee-incidenttraject voor dat wordt weergegeven als een DM-basislijn en een SGAM-boekhouding:
e1: Mira prefers concise answers. Her passport deadline is 2026-07-15.
e2: Mira corrected the deadline. It is now 2026-06-30.
Een DM-basislijn bewaart beide incidenten als vrije tekst, zodat een tekstzoekopdracht e1 kan teruggeven omdat deze de juiste woorden bevat. SGAM haalt voor elk incident een getypt feit uit, gecodeerd op basis van huurder, onderwerp en attribuut. Het moet e2 retourneren als huidige staat en e1 behouden voor historische queries.
De volgende functie is code voor de schrijfweg van SGAM. Deze bevindt zich meestal in een store-module zoals sgam_store.py. DM heeft geen equivalent, omdat het geen actuele rij per attribuut bijhoudt. Voordat de aanroeper een vervanging invoegt, sluit deze functie de huidige rij:
def close_previous_fact(db: sqlite3.Connection, fact: MemoryFact) -> int | None:
row = db.execute(
"""
select fact_id
from memory_facts
where tenant_id = ?
and subject = ?
and attribute = ?
and valid_to is null
order by valid_from desc
limit 1
""",
(fact.tenant_id, fact.subject, fact.attribute),
).fetchone()
if not row:
return None
db.execute(
"update memory_facts set valid_to = ? where fact_id = ?",
(fact.valid_from, row["fact_id"]),
)
return int(row["fact_id"])
Wanneer e2 arriveert, stelt de functie valid_to op het uit e1 gehaalde feit in op het tijdstempel van e2. Vervolgens voegt de aanroeper het nieuwe feit toe met een open valid_to. Omdat DM geen vergelijkbare update-stap kent, kan de oude tekst nog steeds boven de correctie worden gerangschikt.
Het uitvoeren van huidige en historische verlopendatumqueries tegen beide representaties levert verschillende resultaten op:
Naive text memory:
returned episode: e1 -> passport deadline is 2026-07-15
SGAM current state:
mira.passport_deadline = 2026-06-30
valid_from=2026-06-03T10:00:00Z, source=e2
SGAM point-in-time state:
on 2026-06-02, mira.passport_deadline = 2026-07-15
In productie moet deze transactie worden gecombineerd met gestructureerde extractie tijdens de schrijfweg. De databasetransactie actualiseert de tijdelijke geldigheid. Het model haalt een kandidaatfeit op, maar beslist niet welke opgeslagen rij als actueel blijft.
Opslagkeuzes worden bepaald door het zoekpatroon
Projecten gebruiken verschillende benamingen voor onderdelen van dit patroon: geheugenopslag, contextgrafieken, profielen, langetermijnopslag, graph RAG en stateful agents.
| Hulpmiddel of framework | Hoofdopslaglaag | Mechanisme voor tijdelijke toestand | Mechanisme voor schema’s | Praktische toepassingsgebied |
|---|---|---|---|---|
| Zep / Graphiti | Neo4j, FalkorDB, Neptune, ondersteuning voor oude Kuzu | Validiteitsintervallen van feiten plus bronprovenance | Pydantic-entiteiten en randtypen, tijdelijke randen, provenance | Tijdelijke geheugens voor grafen |
| LangGraph / LangMem | LangGraph-opslag, opslag gebaseerd op Postgres | Tijdstempels en velden die door de applicatie worden beheerd in opslagrecords | JSON-opslag plus extrahering van Pydantic-profielen of collecties | Agent-applicaties die al op LangGraph zijn gebouwd |
| Mem0 | Gemanaged stack, Valkey / Redis / vector-backends in OSS-configuraties | Geheugenupdates; tijdsbeleid blijft in handen van de applicatie | Geheugentypen, aangepaste categorieën, extractieprompts | Geheugen voor gebruikers, agenten en sessies als dienst |
| Letta / MemGPT | Agent-toestand en geheugenblokken gebaseerd op databases | Editabele blokken zonder validiteitsintervallen op veldniveau | Editabele, gelabelde geheugenblokken | Stateful agenten met contextbeheer in OS-stijl |
| Cognee | Grafen plus vector- en relationele backends | Geschiedenis hangt af van de ontologie en gekozen backend | Ontologie-gerichte extrahering en validatie | Geheugens voor enterprise-kennisgrafen |
| LlamaIndex property graph | Property-graph-opslag plus vector-opslag | Tijdfelden hangen af van het grafenschema en de opslag | SchemaLLMPathExtractor met toegestane entiteiten en relaties | Grafextrahering uit documenten en traces |
Graphiti is een concrete open-source-implementatie van relationeel, tijdelijk geheugen. Het houdt rekening met veranderingen in feiten, bewaart pointers naar bronepisodeën en ondersteunt hybride zoekmethoden. LangGraph scheidt thread-checkpoints van cross-thread-opslag. Mem0 presenteert geheugenoperaties als een gemanaged dienst. Letta maakt gebruik van editabele contextblokken in plaats van SGAM op veldniveau, maar behandelt agent-toestand nog steeds als persistente gegevens.
Begin met het datamodel. Als exacte feitzoekopdrachten de belangrijkste operatie zijn, volstaat meestal een relationele tabel met JSON-payloads, validiteitskolommen, tenant-indexen en een vector-sidecar. Voeg pas een graf toe wanneer relatieverkenning onderdeel is van het product, en niet alleen omdat een grafdemo indrukwekkend oogt.
Bouw eerst de schrijfweg voor de graaf
Bepaal allereerst wat het product mag onthouden. De keuze tussen graaf en vector komt later.
Een supportagent kan bijvoorbeeld het accountniveau, open zaken en permanente contactvoorkeuren onthouden. Hij moet niet elke gefrustreerde opmerking automatisch naar een profielsituatie omzetten. Een coderingsagent kan repository-conventies en onopgeloste taken onthouden. Hij moet geen privénotitie eeuwig bewaren alleen omdat die één keer is opgehaald.
Begin met de schrijfweg en beschouw geheugen als een kleine toestandsmutatie:
- Geef de typologie van het geheugen, het onderwerp, het tenant-scope en de retentiecategorie een naam.
- Haal kandidaatrecords op met gestructureerde uitvoer.
- Valideer de payload met Pydantic of de schema-laag die je stack al gebruikt.
- Los conflicten op voordat er wordt ingevoegd, inclusief bepalen of het nieuwe record het oude vervangt.
- Bewaar een bronpointer naar het originele incident, het hulpreesultaat, het bestand, het ticket of de bevestiging van de gebruiker die het record heeft gegenereerd.
- Noteer de schema-versie bij elk record in plaats van deze alleen in de applicatiecode te bewaren.
De eerste SGAM-opslag kan een relationele tabel zijn met een JSON-colom en enkele indexen. Een graaf wordt nuttig wanneer het product relaties moet doorlopen, zoals klant-naar-account, account-naar-beleid, taak-naar-artefact of project-naar-beslissing.
Hot path en achtergrondschrijvingen
Onmiddellijke extrahering is zinvol wanneer de volgende stap afhankelijk is van het nieuwe geheugen. Als de gebruiker zegt “onthoud dat ik kort antwoord prefereer”, hoeft het systeem geen nachtelijke verwerking te doen voordat het zich anders gedraagt.
De meeste stappen vereisen geen onmiddellijke schrijving. Sla het originele incident op met tenant-, sessie- en hulpmetadaten, en laat een achtergrondworker later kandidaten extraheren. Met consolidatie gebaseerd op recurrencie buffert de worker zwakke signalen en promoot een feit pas wanneer soortgelijke bewijzen zich herhalen of de gebruiker dit bevestigt. Dit zorgt voor een vertraging in de actualiteit. Dat is acceptabel voor situaties waarin “gebruikers vaak om CSV-exporten vragen”, maar riskant bij “klanten die hun leveringsadres hebben gewijzigd”.
Houd de leesweg deterministisch. Handhaaf eerst het tenant-scope en de geldigheid, en gebruik vage zoekmethoden alleen wanneer dit bruikbare context kan toevoegen.
- Filter op tenant, typologie van het geheugen en geldigheidsperiode.
- Haal eerst de exacte gestructureerde toestand op, daarna de semantische buren.
- Gebruik vector- of graafexpansie voor ondersteunend bewijs, gerelateerde entiteiten en voorbeelden, niet als autoriteit voor actuele feiten.
- Stel samen de kleinste geciteerde context die voldoende is om de vraag te beantwoorden.
Beschouw schema-migraties als productwijzigingen, omdat ze bepalen wat de agent kan onthouden, citeren of verwijderen. Ze kunnen ook bepalen welke historische feiten als actueel worden beschouwd. Plan migratiescripts, backfills, dubbele leesperioden en verwijderingsgedrag in dezelfde release.
Wanneer SGAM de complexiteit waard is
Gebruik SGAM wanneer feiten in de loop der tijd kunnen veranderen:
- gebruikersvoorkeuren die kunnen worden bijgewerkt of ingetrokken
- klant- of accountfeiten met auditisvereisten
- taaktoestanden voor langlopende assistenten
- projectgeheugen van coderingsagenten
- gedeeld toestand tussen meerdere agenten
- compliance-notities waarbij herkomst belangrijk is
- tijdsgebonden vragen zoals “wat geloofden we vóór de migratie?”
SGAM is overbodig wanneer geheugen tijdelijk is, verkennend van aard is, of goedkoop kan worden opnieuw berekend. Als een agent slechts enkele opeenvolgende acties nodig heeft om continuïteit te behouden, zijn een checkpoint en een ingekorte berichtgeschiedenis voldoende. Voor statische documentcontrole kan alleen RAG voldoende zijn. En wanneer het domein zo instabiel is dat het schema elke dag verandert, zal typisch geheugen het team vertragen.
Evaluatiecontrolelijst
Evalueer zowel het levenscyclus van het geheugen als het uiteindelijke antwoord. Een systeem kan een plausibel antwoord geven nadat het een onjuiste feit heeft opgeschreven, een verouderd feit heeft opgehaald, of een grens tussen gebruikers heeft overschreden.
Ik gebruik dezelfde stapsgewijze indeling als in mijn RAG-evaluatieartikel. Meet de fase waarin een fout kan optreden, in plaats van de evaluatie beperkt te houden tot de gegenereerde tekst. De trace-discipline uit het artikel over agentevaluatie is eveneens van toepassing, omdat geheugenfouten vaak al in de uitvoeringsgeschiedenis verschijnen voordat ze het antwoord bereiken.
Ik zou SGAM testen met replay. Voer een vaste reeks episodes in bij de geheugenwriter, controleer het register na elke betekenisvolle actie, en stel vervolgens vragen over de huidige staat en een specifiek tijdstip tegenover de resulterende opslag.
| Laag | Fout die u zoekt | Metingen |
|---|---|---|
| Schrijfextractie | De agent miste een feit, verzon er eentje, of produceerde een ongeldige vorm | Schema-geldige schrijfrate, extractieprecisie/herinnering, dekking van bron-episodes |
| Conflictbewerking | Een verouderd feit bleef actueel of een geldig oud feit werd overschreven | Correctheid van supersessie, duplicatierate, correctheid van invalidatie van verouderde feiten |
| Isolatie en beleid | Geheugen lekte tussen gebruikers of bleef bestaan na afloop van de beleidsperiode | Fouten bij gebruikersisolatie, correctheid van verwijdering, naleving van retentieregels |
| Leesopname | Het juiste record bestaat, maar de lezer haalde het niet op | Accuraatheid van de huidige staat, accuraatheid op een specifiek tijdstip, herinnering@k onder geheugenrecords |
| Antwoordonderbouwing | Het antwoord maakte gebruik van geheugen zonder ondersteuning of citeerde de verkeerde bron | Ondersteuningsclaim ten opzichte van bron-episodes, citatieaccuraatheid, correctheid van conflictoplossing |
| Operaties | De geheugenweg is te traag, te verouderd, of te duur | p95-schrijflatentheid, vertraging in versheid, leeslatenheid, kosten per query |
Benchmarks zoals LoCoMo, LongMemEval en ATM-Bench bieden openbare testcases. Ze vervangen echter geen domeinspecifieke testset. Een coderingsassistent, klantenservicebot en compliance-copilot hebben verschillende schema’s, filters, retentieregels en fouttesten nodig.
Voorzorgsmaatregelen
SGAM is mijn benaming voor een bepaald patroon, geen standaard. Bestaande projecten benaderen dit probleem op een andere manier. LangGraph memory en LangMem beschrijven kortetermijn- en langetermijnopslagmechanismen, profielen, collecties, schrijfoperaties op ‘hot-paths’ en achtergrondgeheugenbeheerders. Zep Graphiti gebruikt de term ‘temporale Context Graph’. Letta maakt bewerkbare geheugenblokken persistent, terwijl Mem0 een beheerde geheugenlaag biedt. Microsoft GraphRAG, de property graphs van LlamaIndex en Cognee modelleren gerelateerde aspecten van het probleem als kennisgraphen.
Een gebruikersprofiel, een logboek van gesprekken, een documentengraaf en een door het agent te bewerken geheugenblok lossen verschillende problemen op wat betreft opvragen en bijwerken. Ik houd SGAM gereserveerd voor duurzaam geheugen dat de huidige toepassingsstatus weergeeft en daarom schema’s, validiteit, herkomstinformatie, conflictbeheer, retentiebeleid en migratie vereist.
Gestructureerd geheugen kan nog steeds onjuist zijn. Een schema maakt slechte invoerwaarden gemakkelijker te controleren; het zorgt er echter niet voor dat ze betrouwbaar zijn. Er is nog steeds behoefte aan vertrouwen in de bron, bevestiging door de gebruiker voor gevoelige gegevens, een conflictbeleid, mogelijkheid tot verwijdering en monitoring.
Schema-migratie vereist werk. Zodra geheugen staat voor toestandsinformatie, ben je verantwoordelijk voor versionering, backfilling, oude records en het verwijderingsgedrag. Als je dit werk overslaat, zullen oude records langer bestaan dan de semantiek of retentiebeleid die ze oorspronkelijk hebben gegenereerd.
Referenties
- According to Me: Long-Term Personalized Referential Memory QA - Artikel van Mei et al. waarin ATM-Bench en Schema-Guided Memory worden voorgesteld.
- Towards Scalable Multi-Domain Conversational Agents: The Schema-Guided Dialogue Dataset - Artikel van Rastogi et al. over het SGD-dataset.
- LongMemEval: Benchmarking Chat Assistants on Long-Term Interactive Memory - Benchmark van Wu et al. voor de capaciteiten op het gebied van langetermijngeheugen.
- Graphiti: Build Temporal Context Graphs for AI Agents
- Zep: A Temporal Knowledge Graph Architecture for Agent Memory
- Mem0 Platform Overview
- Mem0: Building Production-Ready AI Agents with Scalable Long-Term Memory
- LangGraph Memory Overview
- LangGraph Persistence
- LangMem documentation
- Letta: Introduction to Stateful Agents
- Microsoft GraphRAG documentation
- LlamaIndex: Using a Property Graph Index
- Cognee Documentation
- Pydantic model validation docs
- Python sqlite3 documentation