Zmazali sme si vlastnú pamäť a dáta sa vrátili

Povieš agentovi, nech niečo zabudne. Povie, že zabudol. Potom si pôjdeš pozrieť to, čo si zmazal, a stále to tam je.

Spustili sme ten test na troch shipujúcich memory systémoch, vrátane nášho, a zapísali, kde dáta naozaj prestanú byť obnoviteľné. Nástroj je zámerne hlúpy: vydaj vlastný dokumentovaný delete každého systému, potom hľadaj zmazanú hodnotu, verbatim, na každom povrchu, ktorý systém vystavuje. Žiaden LLM-sudca, žiadna interpretácia. Osem subjektov, reálne citlivé hodnoty (zdravotný stav, adresa, plat).

Natívny delete vyčistí predné dvere

Najprv dobrá správa, a je úprimná: na všetkých troch systémoch sa retrieval povrch vráti čistý. Spýtaj sa na zmazanú hodnotu cez bežný query a enumerate, a je preč, 0 z 8 na inspeximus, mem0 aj Graphiti rovnako. Ak je tvoja jediná hrozba „vráti query zmazaný fakt," prejde každý z nich.

Predné dvere sú čisté, reziduum je o miestnosť ďalej

Hodnota je preč z query cesty, ale presunula sa do miestnosti, ktorú väčšina ľudí nekontroluje.

Na mem0 history API vráti zmazaný obsah rovno naspäť. Po delete history(memory_id) vráti DELETE event s old_memory nastaveným na hodnotu, ktorú si práve odstránil, verbatim, komukoľvek s prístupom do store, na všetkých 8 z 8. Jediná natívna cesta to vyčistiť je globálny reset(), ktorý zmaže všetko; neexistuje per-record ani per-user purge, a delete_all() v skutočnosti pridá DELETE riadok, namiesto aby history odstránil. Je to dizajnový trade-off, audit trail, ktorý drží obsah, verzus taký, čo zaznamená udalosť zmazania bez neho, nie bug, na ktorom by sme sa vyžívali. Ale operátor, čo vybavuje žiadosť o výmaz, potrebuje tú miestnosť v rozsahu.

Surové storage súbory ju nesú tiež, hoci toto nie je mem0 vec. V default lokálnej Qdrant konfigurácii payload text sedí v embedded segment súboroch, kým nebeží vacuum, vlastnosť toho substrátu spoločná pre každú appku, čo ho používa, nie defekt memory vrstvy nad ním (závislé od časovania, videli sme to 4 až 5 z 8). Graphiti explicitný remove_episode() nameral prekvapivo čisto, 0 z 8 na všetkých štyroch povrchoch, s per-subject kontrolou potvrdzujúcou, že hodnota bola v grafe pred každým delete; jeho dokumentovaná bitemporálna retencia sa týka supersedovaných faktov, čo je iná operácia.

Riadok, kde zlyhá každý, vrátane nás

A potom je tu kópia, ktorú si spravila samotná aplikácia. Reálny RAG stack vloží tvoje dokumenty do vlastného vector indexu, mimo memory store, a ten index sa o delete nikdy nedozvie. Takže hodnota je tam obnoviteľná 8 z 8 po natívnom výmaze každého store, aj inspeximus. Týmto riadkom otvárame naschvál. Store nemôže zmazať infraštruktúru, o ktorej mu nikto nepovedal, a predstierať opak je presne to, ako sa z „zmazali sme to" stane nepravdivé tvrdenie.

Toto je známa trieda zlyhaní, a kreditujeme ju: Ghost Vectors (arXiv:2606.18497) rekonštruuje soft-deletnuté vektory, a celá machine-unlearning literatúra má za tézu, že delete nezmaže. Čo tento audit pridáva, je stále, znovu-spustiteľné meranie toho naprieč systémami, ktoré ľudia reálne shipujú, súčasť našej širšej práce na integrite agent-memory a celého audit reportu.

Fix, a jeho čestný strop

Keďže žiaden store tú dieru sám nezavrie, shipli sme to zapojenie ako first-class operáciu v inspeximus 1.8.0. Zaregistruješ appkine fan-out stores, vector index, cache, logy, ako erasure targets, a forget_subject() kaskáduje delete cez všetky, znovu overí obnoviteľnosť, a vráti hash-chained manifest, ktorý znie complete len ak každý store overil, že hodnota je preč, inak menuje leaky. Merané: nezapojený index tečie 8 z 8, zapojený zmaže 0 z 8 pre targety, ktoré zaregistruješ, a zámerne pokazené zapojenie nevie vyprodukovať čistý receipt.

Strop je čestný a treba ho povedať. Manifest pokrýva len targety, ktoré zaregistruješ; neznáma kópia ostáva neznáma, pre každý systém. Atestuje, že obsah už nie je obnoviteľný v čase kontroly, nie že disk bol fyzicky prepísaný, a nedotkne sa backupov ani rekonštrukcie textu z podržaného embeddingu. GDPR Článok 17(3) dokonca povoľuje retenciu na audit a právne účely, takže je to inžiniersky signál o tom, kde zmazaný obsah ostáva čitateľný, nie compliance verdikt.

Časté otázky

Zmaže sa fakt dáta, keď agentovi zmažeš pamäť? Na query ceste áno: retrieval vráti zmazanú hodnotu 0 z 8 naprieč inspeximus, mem0 aj Graphiti. Ale hodnota môže prežiť o vrstvu nižšie, v history/audit API, v surových storage súboroch pred kompakciou, a v akomkoľvek externom vector indexe, čo si spravila samotná aplikácia. Testuj obnoviteľnosť naprieč fan-outom, nie len či API vrátilo úspech.

Prečo delete z vector store dáta neodstráni? Vector databázy ako Qdrant defaultne soft-deletujú a bajty uvoľnia až pri vacuum alebo kompakcii, takže payload text sedí v segment súboroch dovtedy. Navyše podržaný embedding sa dá invertovať späť k pôvodnému textu (Ghost Vectors, arXiv:2606.18497), takže zmazať riadok a nechať vektor obsah nezmaže.

Ako overím výmaz dát v agent-memory pre GDPR žiadosť o výmaz? Adversariálne skús znovu obnoviť zmazanú hodnotu z každého store, do ktorého sa dáta rozliali, nie len potvrdiť, že delete call prešiel. inspeximus 1.8.0 to shipuje: zaregistruj appkine fan-out stores a forget_subject() kaskáduje delete, znovu overí obnoviteľnosť, a vráti hash-chained manifest, ktorý znie complete len ak každý registrovaný store overil, že hodnota je preč.

Drží mem0 zmazané dáta? V mem0 OSS 2.0.x history API vráti zmazaný obsah (old_memory) verbatim po delete, a jediná natívna cesta to vyčistiť je globálny reset(). Je to dizajnový trade-off, audit trail, ktorý drží obsah, nie defekt, ale operátor vybavujúci žiadosť o výmaz potrebuje ten povrch v rozsahu.

Krátka verzia: delete, ktorý vyčistí query, je základ. Otázka, ktorú stojí za to otestovať na tvojom stacku, je, či zmazaná hodnota prežije o miestnosť ďalej, a či ti čokoľvek, čo shipuješ, vie povedať, kedy áno. Harness je otvorený; namier ho na svoj store a vyvráť nás.