ஏஜென்ட் மெமரி காலாவதியாவதை தடுப்பது எப்படி?

ஏஜென்ட் மெமரி ஏன் காலாவதியாகிறது

ஒரு தகவல் ஒருமுறை எழுதப்பட்டு, மீண்டும் ஒருபோதும் சரிபார்க்கப்படாததால் ஏஜென்ட் மெமரி காலாவதியாகிறது. ஸ்டோர் (store) அந்தத் தகவலைத் தொடர்ந்து வழங்குகிறது, ரிட்ரீவல் லேயர் (retrieval layer) அதை எந்தத் தேதியும் குறிப்பிடாமல் சாதாரண உரையாக ப்ராம்ப்ட்டில் (prompt) சேர்க்கிறது, மேலும் அந்தத் தகவல் எழுதப்பட்ட அதே நம்பிக்கையுடன் மாடல் (model) அதை மீண்டும் கூறுகிறது. இதில் எந்தப் பிழையும் (error) ஏற்படுவதில்லை. இதுவே முழுச் சிக்கலும் ஆகும்: ஒரு காலாவதியான மெமரி, மாடலுக்கும் உங்களுக்கும் புதிய மெமரியைப் போலவே தோன்றும்.

சேமிக்கும் நேரத்தில் சிறப்பாக எழுதுவது இதைச் சரிசெய்யாது. காலாவதி தேதி கொண்ட தகவல்களுக்கு அந்தத் தேதியைப் பயன்படுத்துவதும், அத்தகைய தேதி இல்லாத தகவல்களுக்கு ஒரு மறுஆய்வு நடைமுறையை (review routine) வைத்திருப்பதுமே இதைச் சரிசெய்யும். இவை இரண்டும் ஒரு சிறிய டேட்டாபேஸில் (database) செய்யப்படும் சாதாரண பராமரிப்புப் பணிகள், மேலும் இதில் பெரும்பாலான வேலைகள் SQL (structured query language) மூலமே செய்யப்படுகின்றன.

Decay மற்றும் drift ஆகியவை வெவ்வேறு தோல்விகள்

Decay என்பது ஒரு குறிப்பிட்ட காலாவதி தேதியைக் கொண்ட உண்மை. "இந்த வாரம் பயணத்தில் இருக்கிறேன்." "migration-க்காக staging box முடக்கப்பட்டுள்ளது." "budget draft-ஐ ஆய்வு செய்கிறேன்." இவை எழுதப்பட்டபோது உண்மையாக இருந்தன, அவற்றை எழுதும்போதே அவற்றின் ஆயுட்காலத்தை உங்களால் குறிப்பிட முடியும். Decay-ஐ சரிசெய்ய முடியும். ஒரு காலாவதி தேதியை அல்லது TTL (time to live)-ஐ இணைத்து, அந்த காலம் முடிந்ததும் அந்தப் பதிவை நீக்கிவிடலாம்.

Drift என்பது ஒருமுறை சேமிக்கப்பட்டு, மீண்டும் சரிபார்க்கப்படாத ஒரு உண்மை. "pnpm-ஐ விரும்புகிறது." "database என்பது Postgres 15." "Deploys அனைத்தும் staging branch வழியாகவே செல்லும்." இவை பொய்யாவதற்கு எந்தக் கடிகாரமும் இல்லை. எங்கோ எடுக்கப்படும் ஒரு முடிவுதான் இவற்றை மாற்றும், ஆனால் அந்த மாற்றம் குறித்து உங்கள் memory store-க்கு எந்தத் தகவலும் கிடைக்காது.

Drift-ஐ தானியங்கி முறையில் சரிசெய்ய முடியாது. ஒரு store தான் கவனிக்காத மாற்றத்தைக் கண்டறிய முடியாது. எனவே, அந்த store-ஐப் படித்து ஆய்வு செய்யும் ஒரு job, பழைய தகவலையே மீண்டும் மீண்டும் படிக்கும். இதற்குச் சரியான வழி, அந்த உண்மை எதைப் பற்றி விவரிக்கிறதோ, அதனுடன் ஒப்பிட்டு மீண்டும் சரிபார்ப்பதுதான். இதற்கு ஒரு நபர் தேவை, அல்லது தற்போதைய நிலையை வாசிக்கக்கூடிய கருவியைக் கொண்ட ஒரு agent தேவை.

எனவே, திட்டம் இரண்டாகப் பிரிகிறது. Decay ஆவதை காலாவதியாக்குங்கள். Drift ஆவதை ஆய்வு செய்யுங்கள். இரண்டாவது சிக்கலை முதல் சிக்கலைப் போலவே கையாளாதீர்கள்.

காலக்கெடு கொண்ட தகவல்களுக்கு காலாவதி தேதியை அமைத்தல்

ஒவ்வொரு memory row-விற்கும் பெரும்பாலான store-கள் வழங்காத மூன்று columns தேவைப்படுகின்றன: அந்தத் தகவல் எங்கிருந்து வந்தது, அது கடைசியாக எப்போது உறுதிப்படுத்தப்பட்டது, மற்றும் அது எப்போது உண்மையாக இருப்பது நின்றுவிடும் என்பது. இதை sqlite3-ஐ மட்டும் பயன்படுத்தி நீங்கள் உருவாக்க முடியும், மேலும் நீங்கள் ஏற்கனவே இயக்கும் store-களிலும் இதே columns-ஐச் சேர்க்கலாம்.

CREATE TABLE memory (
  id            TEXT PRIMARY KEY,
  subject       TEXT NOT NULL,
  fact          TEXT NOT NULL,
  source        TEXT NOT NULL,
  created_at    TEXT NOT NULL DEFAULT (datetime('now')),
  confirmed_at  TEXT NOT NULL DEFAULT (datetime('now')),
  expires_at    TEXT,
  superseded_by TEXT REFERENCES memory(id) ON DELETE CASCADE
);

CREATE INDEX memory_expires ON memory(expires_at);
CREATE INDEX memory_superseded ON memory(superseded_by);

datetime('now') ஆனது UTC (coordinated universal time)-ஐ YYYY-MM-DD HH:MM:SS வடிவில் வழங்குகிறது, இது text-ஆகச் சரியாக வரிசைப்படுத்தவும் ஒப்பிடவும் உதவுகிறது, எனவே கீழே உள்ள ஒவ்வொரு தேதி தொடர்பான கேள்வியும் ஒரு எளிய WHERE clause ஆகும். source column என்பது விருப்பத்தேர்வு அல்ல. ஒரு message, file அல்லது command output-லிருந்து கண்டறிய முடியாத தகவலை மீண்டும் சரிபார்க்க முடியாது, மீண்டும் சரிபார்க்க முடியாத தகவலை நீக்க மட்டுமே முடியும்.

காலாவதியாகும் memory-ஐ எழுதுதல்:

INSERT INTO memory (id, subject, fact, source, expires_at)
VALUES ('m_0191', 'availability', 'Away from keyboard, replies are delayed',
        'chat 2026-08-08', datetime('now', '+7 days'));

Retrieval என்பது ஒருபோதும் table-ஐ நேரடியாகப் படிக்கக்கூடாது. அது காலாவதியான மற்றும் மாற்றப்பட்ட row-களை மறைக்கும் ஒரு view-ஐ மட்டுமே படிக்க வேண்டும்:

CREATE VIEW live_memory AS
SELECT id, subject, fact, source, confirmed_at, expires_at
FROM memory
WHERE superseded_by IS NULL
  AND (expires_at IS NULL OR expires_at > datetime('now'));

இந்த view-தான் மிக முக்கியமான பகுதி, ஏனெனில் இது prune செய்யத் தவறுவதை பாதிப்பில்லாததாக மாற்றுகிறது. ஒரு row காலாவதியானவுடன், delete job இயங்கினாலும் இல்லாவிட்டாலும், அது retrieval-ல் வராது. எனவே, delete job என்பது disk பயன்பாடு மற்றும் review சுமையை மட்டுமே கட்டுப்படுத்துகிறது, தரவின் துல்லியத்தன்மையை அல்ல.

sqlite3 memory.db "SELECT count(*) FROM memory;"-ஐப் பயன்படுத்தி இடைவெளியைச் சரிபார்க்கவும் மற்றும் live_memory-க்கு எதிராக அதே எண்ணிக்கையை ஒப்பிடவும். ஒரு ஆரோக்கியமான store-ல் இந்த இரண்டு எண்களும் நெருக்கமாக இருக்கும். பெரிய இடைவெளி இருந்தால், அது நீக்கப்படாத dead rows-ன் தேக்கமாகும்.

ஒரு நினைவகத்தை நீக்கும்போது பழையது ஏன் அப்படியே தங்கிவிடுகிறது

திருத்தங்கள் ஜோடியாக வருகின்றன. நீங்கள் npm-லிருந்து pnpm-க்கு மாறியதை agent அறிந்துகொண்டு, ஒரு புதிய வரிசையை எழுதி, பழைய வரிசையை அதற்குச் சுட்டிக்காட்டுகிறது:

UPDATE memory SET superseded_by = 'm_0207' WHERE id = 'm_0140';

இந்த பழைய வரிசை இப்போது live_memory-க்குத் தெரியாது, மேலும் சங்கிலித் தொடர் என்ன மாறியது என்பதைப் பதிவு செய்கிறது. இப்போது m_0207-ஐ நீக்கவும், ஏனெனில் அது தவறானது என்று தெரியவந்தது. superseded_by-ல் உள்ள ON DELETE CASCADE, m_0140-ஐயும் சேர்த்து நீக்க வேண்டும், ஏனெனில் அந்த உறவில் பழைய வரிசைதான் child ஆகும். பொதுவாக இது நடப்பதில்லை, ஏனெனில் நீங்கள் foreign keys-ஐ இயக்காதவரை SQLite அவற்றைப் புறக்கணிக்கும், மேலும் இயல்பாகவே அது off நிலையில் இருக்கும்:

sqlite3 memory.db "PRAGMA foreign_keys;"

இது ஒரு stock build-ல் 0-ஐ அச்சிடும். Foreign keys off நிலையில் இருக்கும்போது, DELETE FROM memory WHERE id = 'm_0207'; வெற்றிபெறுகிறது மற்றும் m_0140 அங்கேயே தங்கிவிடுகிறது, அது இப்போது இல்லாத ஒரு id-ஐச் சுட்டிக்காட்டுகிறது. எதுவும் உங்களை எச்சரிக்காது. அந்த வரிசை இப்போது தவறான காரணத்திற்காக மறைக்கப்பட்டுள்ளது, மேலும் dangling pointers-ஐ NULL-க்கு மீட்டமைக்கும் முதல் tidy-up script, "prefers npm" என்பதை மீண்டும் live_memory-ல் கொண்டு வந்து சேர்க்கும்.

உடைந்த சங்கிலிகளைத் தேடுங்கள்:

sqlite3 memory.db "PRAGMA foreign_key_check;"

foreign_key_check அமலாக்கம் (enforcement) off நிலையில் இருந்தாலும் மீறல்களைப் புகாரளிக்கும், எனவே இது ஏற்கனவே உள்ள குழப்பமான தரவுகளிலும் வேலை செய்யும். இது ஒவ்வொரு மீறலுக்கும் ஒரு வரிசையை அச்சிடும்: table, rowid, parent table மற்றும் எந்த foreign key தோல்வியடைந்தது ஆகியவற்றைத் தெரிவிக்கும். வெளியீடு காலியாக இருந்தால், சங்கிலிகள் சரியாக உள்ளன என்று அர்த்தம்.

இதனைத் தொடர்ந்து வரும் விதி சிறியது. PRAGMA foreign_keys = ON; என்பது ஒரு connection-க்கான அமைப்பாகும், எனவே ஒவ்வொரு connection-க்கும் இது தேவை: உங்கள் application, உங்கள் prune script மற்றும் நீங்கள் தட்டச்சு செய்யும் sqlite3 session ஆகியவற்றுக்கு இது அவசியம். எதையாவது நீக்கும் ஒவ்வொரு SQL கோப்பின் முதல் வரியாகவும் இதைச் சேர்க்கவும்.

உங்கள் நினைவுகள் உண்மையில் எங்கு சேமிக்கப்படுகின்றன

எதையும் நீக்குவதற்கு முன்பு, உங்களிடம் எத்தனை சேமிப்பகங்கள் (stores) உள்ளன என்பதைக் கண்டறியவும். ஒரு self-hosted memory service பொதுவாக நினைவக உரை (memory text) மற்றும் அதன் embedding-ஐ ஒரு vector database-ல் வைத்திருக்கும், மேலும் ஒரு change log-ஐ SQLite-ல் வைத்திருக்கும். இவை வெவ்வேறு கோப்புகள் மற்றும் வெவ்வேறு வாழ்க்கைச் சுழற்சிகளைக் கொண்டவை, எனவே இவை தனித்தனியாகச் செயலிழக்கக்கூடும்.

mem0 இதற்கு ஒரு சிறந்த உதாரணம், இதே போன்ற அமைப்பு பிற இடங்களிலும் காணப்படுகிறது. இதன் open source library இயல்பாகவே /tmp/qdrant-ல் உள்ள Qdrant vector store-ஐப் பயன்படுத்துகிறது, இது mem0 என்ற collection-ல் சேமிக்கப்படுகிறது. மேலும், MEM0_DIR environment variable-ஐப் பின்பற்றும் பாதையில் ~/.mem0/history.db என்ற SQLite change log-ஐயும் பயன்படுத்துகிறது. history அட்டவணை memory_id, old_memory, new_memory, event, created_at மற்றும் is_deleted ஆகியவற்றை உள்ளடக்கியது.

அந்தக் column பட்டியலை மீண்டும் கவனிக்கவும். அந்த SQLite கோப்பு ஒரு change log மட்டுமே. நினைவுகள் (memories) Qdrant-ல் உள்ளன, எனவே history.db-லிருந்து வரிசைகளை நீக்குவது, ஏதோ ஒன்று மாறியது என்ற பதிவை மட்டுமே நீக்கும், ஆனால் அந்த நினைவை மீண்டும் பெற முடியும். நீக்குதல் செயல்பாடுகள் library-ன் சொந்த API (application programming interface) வழியாகவே நடக்க வேண்டும், அப்போதுதான் இரண்டு இடங்களும் சரியாகப் புதுப்பிக்கப்படும்:

from mem0 import Memory

memory = Memory()
memory.delete(memory_id="mem_123")
memory.delete_all(user_id="alice")

/tmp இயல்புநிலை (default) ஒரு எச்சரிக்கைக்கு உரியது. Ubuntu 24.10 மற்றும் அதற்குப் பிந்தைய பதிப்புகளில், /tmp என்பது ஒரு tmpfs ஆகும், இது நினைவகத்தில் (memory) இயங்கும் ஒரு filesystem. எனவே, ஒவ்வொரு reboot-க்குப் பிறகும் அது காலியாகிவிடும், முழு சேமிப்பகமும் அழிந்துவிடும். findmnt /tmp மூலம் உங்களுடையதைச் சரிபார்க்கவும். tmpfs என்று காட்டும் ஒரு வரி இருந்தால், அந்தப் பாதையை இன்றே மாற்றவும்:

config = {
    "vector_store": {
        "provider": "qdrant",
        "config": {"collection_name": "mem0", "path": "/srv/agent/qdrant"},
    }
}
memory = Memory.from_config(config)

நீங்கள் எதை இயக்கினாலும் இதே கேள்வி பொருந்தும். configuration-ஐப் படித்து, அந்த service எழுதும் ஒவ்வொரு பாதையையும் குறித்துக் கொள்ளவும். உங்கள் சொந்த VPS-ல் mem0 memory server-ஐ இயக்குதல் என்பது அந்தச் சேவையின் பக்கத்தை விளக்குகிறது, மேலும் agent memory-ஐ ஒரே கணினியில் வைத்திருத்தல் என்பது அதே பராமரிப்புத் தேவைகளைக் கொண்ட ஒரு சிறிய சேமிப்பகமாகும்.

sqlite3 மூலம் store-ஐ வாசித்தல்

CLI (command line interface) இல்லை என்றால், sudo apt install -y sqlite3 மூலம் அதை நிறுவவும். உங்கள் disk-ல் உள்ள எந்தவொரு store பற்றிய கேள்விகளுக்கும் பின்வரும் நான்கு கட்டளைகள் விடையளிக்கும்.

• sqlite3 ~/.mem0/history.db ".tables" அட்டவணைகளின் (tables) பட்டியலைக் காட்டும். வெளியீடு காலியாக இருந்தால், நீங்கள் தவறான கோப்பைத் திறந்துள்ளீர்கள் என்று அர்த்தம்.
• sqlite3 ~/.mem0/history.db ".schema history" துல்லியமான நெடுவரிசைகளை (columns) அச்சிடும்; இதுவே ஒரு store-ன் அமைப்பை அறிய உதவும் நம்பகமான ஆவணமாகும்.
• sqlite3 -cmd ".mode line" ~/.mem0/history.db "SELECT * FROM history ORDER BY created_at DESC LIMIT 5;" மிக அண்மைய ஐந்து மாற்றங்களை ஒவ்வொரு புலத்திற்கும் ஒரு வரியாகக் காட்டும்; ஒரு நெடுவரிசையில் பத்தி (paragraph) வடிவில் தரவு இருந்தாலும் இது வாசிப்பதற்கு எளிதாக இருக்கும்.
• sqlite3 ~/.mem0/history.db "SELECT event, count(*) FROM history GROUP BY event;" store என்னென்ன செயல்பாடுகளைச் செய்துள்ளது என்பதையும், உங்கள் library எந்தெந்த event பெயர்களை எழுதுகிறது என்பதையும் காட்டும்.

ஒவ்வொரு memory store-ம் ஒரு database அல்ல. ஒவ்வொரு session தொடக்கத்திலும் வாசிக்கப்படும் ஒரு சாதாரண குறிப்புக்கோப்பு (plain file), தோல்விகளைச் சந்திக்கும்; மேலும் இதில் எந்தவிதமான கருவிகளும் இல்லை: காலாவதி நெடுவரிசை (expiry column) இல்லை, உறுதிப்படுத்தப்பட்ட தேதி இல்லை, தேவையற்ற வரிகளை மறைப்பதற்கான view வசதியும் இல்லை. நீங்கள் கையால் எழுதும் ஒவ்வொரு வரியிலும் தேதியைக் குறிப்பிட்டு, மாதத்திற்கு ஒருமுறை அதை மீண்டும் வாசிக்கவும். Claude Code session-களுக்கு இடையே தொடரும் memory இதே சிக்கலைச் சிறிய அளவில் கொண்டுள்ளது.

காலாவதியாகாத உண்மைகளை ஆய்வு செய்தல்

Drift-க்கு ஒரு queue, ஒரு cap, மற்றும் ஒரு பழக்கம் தேவை. Queue என்பது மிகப்பழமையான உறுதிப்படுத்தல்களைக் குறிக்கும்:

SELECT id, subject, fact, source, confirmed_at
FROM live_memory
WHERE confirmed_at < datetime('now', '-90 days')
ORDER BY confirmed_at
LIMIT 20;

வாரத்திற்கு இருபது வரிசைகளை ஆய்வு செய்வது நடைமுறைக்குச் சாத்தியமானது. நானூறு வரிசைகளை ஆய்வு செய்வது யாராலும் செய்ய முடியாத காரியம், இது உங்களை மீண்டும் பழைய நிலைக்குக் கொண்டு செல்லும். ஒவ்வொரு வரிசைக்கும் இரண்டு முடிவுகள் உள்ளன. அதன் source-உடன் அதை மீண்டும் சரிபார்த்து முத்திரையிடவும்:

UPDATE memory SET confirmed_at = datetime('now') WHERE id = 'm_0140';

அல்லது அதை மாற்றவும்: புதிய உண்மையை உள்ளிடவும், பழைய வரிசையின் superseded_by-ஐ புதிய id-க்கு அமைக்கவும், சங்கிலித் தொடர் வரலாற்றைத் தக்கவைக்கட்டும்.

இரண்டு பழக்கங்கள் இதை எளிதாக்குகின்றன. தரவு சேமிப்பகத்தைச் சிறியதாக வைத்திருங்கள், ஏனெனில் வளர்ந்து கொண்டே இருக்கும் சேமிப்பகத்தில் ஆய்வு செய்வது சாத்தியமற்றது: ஒரு last_used_at நெடுவரிசையைச் சேர்க்கவும், ஒரு வரிசை எடுக்கப்படும்போது அதை மேம்படுத்தவும், ஆறு மாதங்களாகப் பயன்படுத்தப்படாத வரிசைகளை நீக்குவதற்குப் பரிசீலிக்கவும். இது ஒவ்வொரு மீட்டெடுப்பிற்கும் ஒரு write செயல்பாட்டை ஏற்படுத்தும், எனவே agent அடிக்கடி செயல்பட்டால் இதை batch செய்யவும்.

இரண்டாவது பழக்கத்திற்கு எந்தச் செலவும் இல்லை. தரவின் வயதை prompt-ல் சேர்க்கவும். உங்கள் retriever உருவாக்கும் memory block-ல் ஒவ்வொரு உண்மைக்கும் அருகில் confirmed 2026-05-02 இருந்தால், model "மே மாதம் நிலவரப்படி நீங்கள் pnpm பயன்படுத்தினீர்கள்" என்று கூற முடியும், மாறாக அதைத் தட்டையாகக் கூறாது. தேதி இல்லாத ஒரு உண்மை, மொழி மாதிரிக்கு (language model) ஒவ்வொரு முறையும் நிகழ்காலமாகவே தோன்றும்.

அட்டவணைப்படி prune-ஐ இயக்குதல்

நீங்கள் நினைவூட்டும் போது மட்டும் இயங்கும் prune பயனுள்ளதாக இருக்காது. SQL-ஐ /srv/agent/prune.sql-ல் சேர்க்கவும்:

PRAGMA foreign_keys = ON;

DELETE FROM memory
WHERE expires_at IS NOT NULL AND expires_at <= datetime('now');

DELETE FROM memory
WHERE superseded_by IS NOT NULL
  AND created_at < datetime('now', '-180 days');

/etc/systemd/system/memory-prune.service-ஐ சேமிக்கவும்:

[Unit]
Description=Prune expired agent memories

[Service]
Type=oneshot
User=agent
ExecStart=/usr/bin/sqlite3 /srv/agent/memory.db ".read /srv/agent/prune.sql"

மேலும் /etc/systemd/system/memory-prune.timer-ஐயும்:

[Unit]
Description=Run the agent memory prune daily

[Timer]
OnCalendar=daily
Persistent=true

[Install]
WantedBy=timers.target

sudo systemctl daemon-reload
sudo systemctl enable --now memory-prune.timer
systemctl list-timers memory-prune.timer

list-timers-ல் ஒரு NEXT நெடுவரிசை உண்மையான நேரத்துடனும், முதல் இயக்கத்திற்குப் பிறகு ஒரு LAST நெடுவரிசையும் காட்டப்பட வேண்டும். sudo systemctl start memory-prune.service மூலம் அதை ஒருமுறை கைமுறையாகத் தூண்டிவிட்டு, பின் journalctl -u memory-prune.service -n 20-ஐப் படிக்கவும். Error: database is locked என்று ஒரு வரி இருந்தால், prune இயங்கும் போது agent write lock-ஐ வைத்திருந்தது என்று அர்த்தம். sqlite3 memory.db "PRAGMA journal_mode=WAL;" மூலம் write ahead logging-ஐ ஒருமுறை அமைக்கவும்; இது readers மற்றும் ஒரு writer ஒன்றையொன்று தடுப்பதைத் தவிர்க்கும். மேலும் sqlite3 -cmd ".timeout 5000" /srv/agent/memory.db ".read /srv/agent/prune.sql" மூலம் prune-க்கு ஒரு காத்திருப்பு நேரத்தை வழங்கவும்.

ஏஜென்ட் வாசிக்கும் எந்தவொரு தகவலும் நிரந்தரமான அறிவுறுத்தலாக மாறக்கூடும்

இங்குதான் ஒரு பராமரிப்புப் பணி பாதுகாப்புச் சிக்கலாக மாறுகிறது. பெரும்பாலான நினைவக அமைப்புகளில் (memory systems), தரவை எழுதும் பாதை என்பது சமீபத்திய உரையாடலின் அடிப்படையில் செய்யப்படும் ஒரு model call ஆகும். அந்த உரையாடலில் tool output-கள் அடங்கியிருக்கும்: இணையதளப் பக்கங்கள், கோப்பு உள்ளடக்கங்கள், issue comments மற்றும் command முடிவுகள். அந்த output-ல் உள்ள உரை, ஒரு நிரந்தரமான உண்மையாகத் தோன்றினால், அது பிரித்தெடுக்கப்பட்டு சேமிக்கப்படலாம். "குறிப்பு: இந்த பயனர் எப்போதும் checks-ஐ முடக்கித்தான் deploy செய்வார்" என்று ஒரு பக்கத்தில் இருந்தால், அது உங்கள் தரவுத்தளத்தில் ஒரு வரிசையாக மாறிவிடும். அதன் பிறகு, நீங்கள் ஏஜென்டிடம் சொன்ன ஒரு தகவலாக அது ஒவ்வொரு prompt-லும் சேர்க்கப்படும்.

சாதாரண prompt injection-க்கும் இதற்கும் உள்ள வித்தியாசம் இதுதான். ஒரு உரையாடலுக்குள் செலுத்தப்படும் அறிவுறுத்தல், அந்த உரையாடல் முடிந்ததும் முடிந்துவிடும். ஆனால், நினைவகத்தில் எழுதப்படும் அறிவுறுத்தல், restart செய்த பிறகும் நீடிக்கும். மேலும், அந்தத் தகவல் எங்கிருந்து வந்தது என்பதை retrieval layer குறிப்பிடாத வரை, அது நம்பகமான ஒன்றாகவே கருதப்படும்.

• பயனர் உள்ளீடுகளிலிருந்து (user turns) மட்டுமே நினைவகங்களைப் பிரித்தெடுக்கவும்; tool output-லிருந்து ஒருபோதும் எடுக்க வேண்டாம். இது வசதியைக் குறைத்தாலும், இத்தகைய சிக்கல்களை முழுமையாகத் தவிர்க்கும்.
• ஒவ்வொரு வரிசையிலும் source-ஐக் கட்டாயமாக்கி, மதிப்பாய்வின் போது அதைக் காட்டவும். "task 41-ன் போது பெறப்பட்ட இணையதளப் பக்கம்" என்று ஆதாரம் குறிப்பிடப்பட்டிருந்தால், அதை இருமுறை சரிபார்க்க வேண்டும்.
• புதிய வரிசைகளை தினமும் மின்னஞ்சல் அல்லது log செய்யவும்; அதனுடன் SELECT id, subject, fact, source FROM memory WHERE created_at > datetime('now', '-1 day');-ஐயும் அதே கால இடைவெளியில் பயன்படுத்தவும்.
• நற்சான்றிதழ்களை (credentials) நினைவகத்தில் சேமிக்க வேண்டாம். இது keeping secrets out of an AI agent பகுதியில் விளக்கப்பட்டுள்ளது.

இதனுடன் தொடர்புடைய ஒரு தொழில்நுட்பக் குறிப்பு: ஒரு வரிசையை நீக்குவது, அதை கோப்பிலிருந்து முழுமையாக அழித்துவிடாது. SQLite அந்தப் பக்கத்தை காலியாகக் கருதி, பின்னர் மீண்டும் பயன்படுத்தும். எனவே, அந்த பழைய உரை strings memory.db மூலம் மீண்டும் வாசிக்கப்படலாம். முக்கியமான தகவல்களை நீக்கிய பிறகு sqlite3 memory.db "VACUUM;"-ஐ இயக்கவும்; இது முழு கோப்பையும் மீண்டும் எழுதும். PRAGMA secure_delete = ON;-ஐப் பயன்படுத்தினால், நீக்கும்போது அந்த இடத்திலுள்ள பழைய தரவுகள் பூஜ்ஜியங்களால் (zeros) மேலெழுதப்படும்.

எவற்றை, எந்த வரிசையில் பேக்கப் எடுக்க வேண்டும்

இந்த store சிறியது, ஆனால் இதை மீண்டும் உருவாக்குவது கடினம். எனவே, இதை முறையாக பேக்கப் எடுக்கவும். நேரலையில் இயங்கும் database கோப்பை ஒருபோதும் cp மூலம் நகலெடுக்க வேண்டாம். எழுதும் பணி பாதியில் இருக்கும்போது எடுக்கப்படும் நகல் திறக்கப்படாமல் போகலாம். SQLite-ல் உள்ள snapshot வசதியைப் பயன்படுத்தவும்:

sqlite3 /srv/agent/memory.db "VACUUM INTO '/srv/backup/memory-$(date +%F).db'"
sqlite3 /srv/backup/memory-$(date +%F).db "PRAGMA integrity_check;"

integrity_check ok-ஐ பிரிண்ட் செய்வது மட்டுமே, பேக்கப் கோப்பு பயன்பாட்டிற்கு உகந்தது என்பதற்கான ஒரே சான்றாகும். மற்றபடி, முந்தைய பேக்கப் கோப்பை அப்படியே வைத்துக்கொண்டு, அதை மேலெழுதும் (overwrite) முன் காரணத்தை ஆராயவும்.

Vector store-ஐயும் அதே வேலையில், அதே நேரத்தில் snapshot எடுக்கவும். இரண்டு பகுதிகளும் பல மணிநேர இடைவெளியில் எடுக்கப்பட்டால், restore செய்யும்போது புதிய change log-உம் பழைய நினைவுகளும் கலந்துவிடும்; நீக்கப்பட்ட தகவல்கள் மீண்டும் தோன்றும். இரண்டையும் ஒரே தேதியிட்ட கோப்பகத்தில் (directory) சேமிக்கவும், அப்போதுதான் அவற்றை ஒன்றாக மட்டுமே restore செய்ய முடியும். VPS-ல் SQLite-ஐ production-ல் இயக்குதல் என்ற கட்டுரை, locking, பேக்கப் மற்றும் நீண்ட காலம் இயங்கும் service-க்குத் தேவையான அமைப்புகள் குறித்து விரிவாக விளக்குகிறது.

FAQ

ஏஜென்ட் மெமரி காலாவதியாகும் முன் எவ்வளவு காலம் இருக்க வேண்டும்?

காலாவதி காலத்தை பொதுவான அமைப்பிலிருந்து (global default) தீர்மானிக்காமல், அந்தத் தகவலின் தன்மையிலிருந்து தீர்மானிக்கவும். ஒரு பயணக் குறிப்பு அல்லது "இந்த வாரம் இந்தத் திட்டத்தில் வேலை செய்கிறேன்" என்ற குறிப்புக்கு ஏழு நாட்கள் போதுமானது. ஒரு குழுவின் நடைமுறை அல்லது தனிப்பட்ட விருப்பங்களுக்கு காலாவதி காலம் தேவையில்லை; அதற்குப் பதிலாக அவற்றை ஆய்வு வரிசையில் (review queue) சேர்க்கவும். ஒரு மென்பொருள் பதிப்பு குறித்த தகவலுக்கு, அந்தத் திட்டத்தின் release cadence-க்கு இணையான காலாவதி காலத்தை அமைக்கவும். ஒரு தகவலை எழுதும்போதே அதன் ஆயுட்காலத்தை உங்களால் தீர்மானிக்க முடியவில்லை என்றால், அது காலாவதியாவதை விட காலப்போக்கில் மாறக்கூடியது என்று அர்த்தம். எனவே, அதற்கு confirmed_at தேதியை இட்டு, காலாவதி செய்வதற்குப் பதிலாக அதை ஆய்வு செய்யவும்.

சேமிக்கப்பட்ட தகவல் தவறாகிவிட்டதை என்னால் தானாகவே கண்டறிய முடியுமா?

நம்பகமான முறையில் முடியாது. இந்த store-க்கு வெளியுலகத்தைப் பார்க்கும் திறன் இல்லை. எனவே, ஒரு தகவல் தவறானதற்குக் காரணமான மாற்றத்தை அதனால் காண முடியாது. store-ஐ மீண்டும் வாசிக்கும் ஒரு பணி, அதே பழைய உரையையே மீண்டும் வாசிக்கும். நீங்கள் எதை தானியக்கமாக்கலாம் என்றால், தகவல்களை வெளிப்படுத்துவதை (surfacing) செய்யலாம்: confirmed_at மூலம் வரிசைப்படுத்தி, பழமையான தகவல்களை ஒரு மனிதரின் பார்வைக்கோ அல்லது repository, config file, அல்லது monitoring endpoint ஆகியவற்றிலிருந்து தற்போதைய நிலையை வாசிக்கக்கூடிய கருவியைக் கொண்ட ஏஜென்ட்டின் பார்வைக்கோ கொண்டு வரலாம். வரிசையை (queue) தானியக்கமாக்குவது பயனுள்ளது. ஆனால், முடிவெடுப்பதை (verdict) தானியக்கமாக்கும் தொழில்நுட்பம் இன்னும் முதிர்ச்சியடையவில்லை.

நான் ஒரு மெமரியை நீக்கினேன், ஆனால் அது மீண்டும் வந்துவிட்டது. ஏன்?

பொதுவாக இரண்டு stores இருப்பதால், நீங்கள் ஒன்றில் மட்டும் மாற்றத்தைச் செய்திருக்கலாம். மெமரி உரையும் அதன் embedding-ம் பொதுவாக vector database-ல் இருக்கும், அதே சமயம் SQLite கோப்பு மாற்றங்களின் பதிவை (change log) வைத்திருக்கும். எனவே, SQLite கோப்பிலிருந்து வரிகளை நீக்குவது தணிக்கைப் பதிவை மட்டுமே நீக்கும், மெமரி இன்னும் எடுக்கக்கூடிய நிலையிலேயே இருக்கும். இரண்டையும் புதுப்பிக்க library API வழியாக நீக்கவும். மற்றொரு பொதுவான காரணம் restore செய்வது; vector store மற்றும் SQLite கோப்பு வெவ்வேறு நேரங்களில் snapshot எடுக்கப்பட்டிருந்தால், restore செய்யும்போது ஒரு பகுதி நீக்கிய வரிகள் மற்றொரு பகுதியிலிருந்து மீண்டும் வந்துவிடும்.

ஏஜென்ட் இயங்கிக்கொண்டிருக்கும்போது மெமரி database-ஐ கைமுறையாகத் திருத்துவது பாதுகாப்பானதா?

வாசிப்பது (Reads) பாதுகாப்பானது. எழுதுவது (Writes) write ahead logging mode-ல் மட்டுமே பாதுகாப்பானது, அதுவும் ஒரு நேரத்தில் ஒரு writer மட்டுமே இருக்க வேண்டும். நீங்கள் எந்த mode-ல் இருக்கிறீர்கள் என்பதைப் பார்க்க sqlite3 memory.db "PRAGMA journal_mode;"-ஐ இயக்கவும், wal என்பது உங்களுக்குத் தேவையான விடையாகும். நீங்கள் Error: database is locked-ஐக் கண்டால், மற்றொரு process write lock-ஐ வைத்திருக்கிறது என்று அர்த்தம். எனவே, sqlite3 -cmd ".timeout 5000" மூலம் உங்கள் session-க்கு காத்திருப்பு நேரத்தை வழங்கவும் அல்லது முதலில் ஏஜென்ட் service-ஐ நிறுத்தவும். vector store-ஐ கைமுறையாகத் திருத்துவது வேறுபட்டது: அதை library-யிடமே விட்டுவிடவும், ஏனெனில் embedding-ம் உரையும் ஒன்றுக்கொன்று இணக்கமாக இருக்க வேண்டும்.