AI agent পুরোনো কথা সত্য ধরে নিচ্ছে? Memory prune করার সময় এসেছে
AI agent পুরোনো তথ্যকে বর্তমান সত্য হিসেবে ব্যবহার করলে সমাধান সব পুরোনো memory একসঙ্গে মুছে ফেলা নয়। প্রতিটি record-এর ধরন, মালিক, confidence, সর্বশেষ যাচাইয়ের সময় ও expiry ধরে পুরোনো, দ্বৈত এবং পরস্পরবিরোধী তথ্য আলাদা করুন; তারপর retain, supersede, consolidate বা delete করার নিয়ম প্রয়োগ করুন।
এই lifecycle-কে retrieval path থেকে আলাদা নির্ধারিত workflow হিসেবে চালানো যায়। AgentCore-এ long-term memory চালু করতে এক বা একাধিক strategy যোগ করতে হয়; AWS-এর long-term memory নির্দেশিকা record retrieve, list ও delete করার operation-ও নথিবদ্ধ করেছে। তবে operation থাকা আর কোন record কখন সরবে, সেই application policy থাকা এক বিষয় নয়।
প্রথমে lifecycle-aware schema তৈরি করুন
শুধু memory text ও creation time রাখলে পুরোনো ঘটনা, ব্যক্তিগত পছন্দ এবং কার্যপদ্ধতিকে একই নিয়মে বিচার করতে হয়। AgentCore-এর record metadata-র পাশাপাশি application layer-এ অন্তত নিচের fieldগুলো রাখুন:
- memory_type: episodic, semantic বা procedural। কথোপকথনের ঘটনা সাধারণত দ্রুত অপ্রাসঙ্গিক হয়; যাচাইকৃত preference এবং অনুমোদিত workflow-এর retention আলাদা হওয়া উচিত।
- subject ও owner: তথ্যটি কোন ব্যক্তি বা entity সম্পর্কে এবং কোন দল তার যথার্থতা ও retention-এর জন্য দায়ী।
- confidence: extraction বা consolidation-এর নির্ভরযোগ্যতার signal। এটি সত্যতার প্রমাণ নয়; review priority নির্ধারণের উপাদান।
- created_at, last_accessed_at ও last_verified_at: তৈরি, retrieval এবং authoritative source-এর সঙ্গে সর্বশেষ যাচাইয়ের সময় আলাদা রাখুন।
- expires_at ও retention_class: business policy থেকে পাওয়া deadline এবং legal hold, standard বা sensitive-এর মতো retention শ্রেণি।
- status ও provenance: active, superseded, pending_delete বা retained অবস্থার সঙ্গে source event, policy version এবং replacement record ID রাখুন।
AgentCore-এর MemoryRecordSummary-তে lastAccessedAt নেই। তাই access recency ব্যবহার করতে চাইলে application telemetry বা CloudTrail-এর GetMemoryRecord event থেকে তা হিসাব করে আলাদা ledger-এ রাখতে হবে। একইভাবে owner, last_verified_at ও retention_class-কে application-managed metadata হিসেবে বিবেচনা করুন।
Retain, supersede, consolidate না delete—নিয়মটি আগে লিখুন
কম score মানেই delete নয়। Score candidate বাছাই করবে; চূড়ান্ত action নির্ধারণ করবে memory type, expiry, contradiction, provenance এবং প্রতিষ্ঠানের retention rule। ব্যবহারকারীর যাচাইকৃত নতুন preference পুরোনোটির বিরোধিতা করলে পুরোনো record-কে superseded করুন। একই অর্থের একাধিক episodic record থাকলে সেগুলো একটি semantic record-এ consolidate করা যায়।
প্রতিষ্ঠানের যাচাইকৃত deletion policy অনুযায়ী মেয়াদোত্তীর্ণ বা নিশ্চিতভাবে invalid record delete করুন। Legal hold, unresolved dispute কিংবা high-impact procedural instruction কেবল বয়স বা কম retrieval-এর কারণে মুছবেন না। ব্যক্তিগত continuity এবং পরিবর্তনশীল authoritative জ্ঞানও আলাদা রাখা দরকার: AgentCore-এর memory ও RAG নির্দেশনা user preference, past decision ও session continuity-র জন্য long-term memory এবং বর্তমান documentation, policy ও specification-এর জন্য query-time RAG ব্যবহারের কথা বলে।
একটি composite score-এ creation recency, access recency ও frequency রাখা যায়। তার সঙ্গে verification freshness, source authority, contradiction এবং sensitivity যোগ করা সম্পাদকীয়ভাবে যুক্তিসঙ্গত extension, তবে threshold প্রতিটি memory type-এর জন্য আলাদা করে validate করতে হবে। Procedural memory ভুলভাবে বাদ পড়লে tool-use বা approval flow বদলে যেতে পারে, তাই এর pruning gate semantic বা episodic memory-এর চেয়ে কঠোর রাখুন।
Nightly score–consolidate–prune flow সাজান
AWS-এর AgentCore lifecycle architecture EventBridge-triggered Step Functions workflow-এ TTL expiration, access data-ভিত্তিক scoring, low-score record consolidation, metrics emission এবং S3-তে run output সংরক্ষণ করে। এতে AgentCore long-term record-এর built-in auto-delete TTL নেই; timestamp filter দিয়ে নির্দিষ্ট সময়ের আগের record list করে delete করা হয়। Consolidation সফল হলে replacement লেখার পর originals মুছে যায়, আর model call ব্যর্থ হলে originals অক্ষত থাকে।
Production sequence-টি এভাবে সাজান:
- Actor ও namespace ধরে candidate record page-by-page list করুন। Run ID, policy version এবং processing cutoff লিখে রাখুন।
- Legal hold বাদ দিয়ে hard-expired record আলাদা queue-তে পাঠান। এগুলোর জন্য scoring বা model call দরকার নেই।
- বাকি record-এর score হিসাব করুন। Missing owner, পুরোনো verification বা contradiction থাকলে সরাসরি delete না করে review কিংবা consolidation queue-তে দিন।
- একই subject এবং compatible provenance-এর record group করুন। Consolidator থেকে summary, বাদ দেওয়া claim, confidence এবং source ID-সহ structured result নিন।
- Replacement schema validation ও grounding check পার হলে নতুন record লিখুন। এরপর originals-কে superseded চিহ্নিত করে replacement ID যুক্ত করুন।
- Deletion সফল হওয়ার পর audit receipt লিখুন; আংশিক ব্যর্থতা retry queue-তে পাঠান। শেষে processed, retained, consolidated, deleted ও failed count প্রকাশ করুন।
Workflow-টি idempotent করুন। একই run আবার শুরু হলে যেন duplicate replacement তৈরি না হয় এবং আগে মুছে যাওয়া record-কে নতুন failure ধরা না হয়। Deterministic consolidation key ও operation ID এই নিয়ন্ত্রণ সহজ করে।
Deletion audit-এ মুছে ফেলা content কপি করবেন না
Audit log-এ operation ID, tenant বা actor scope, memory record ID, action, reason code, policy version, service বা reviewer identity, timestamp, replacement ID এবং ফলাফল রাখুন। প্রমাণের জন্য content hash ও source ID যথেষ্ট হলে raw ব্যক্তিগত text আবার log-এ লিখবেন না; নইলে মূল store থেকে সরিয়েও observability system-এ সংবেদনশীল তথ্য থেকে যেতে পারে।
Completion status-এ success, partial_failure ও failure আলাদা করুন। Pagination সম্পূর্ণ হয়েছিল কি না, কতটি record পাওয়া গেছে, কোন ID delete হয়নি এবং retry কখন হবে—receipt-এ এসব রাখুন। Audit log-এরও নিজস্ব retention policy প্রয়োজন; deletion-এর প্রমাণ রাখা মানে deleted content অনির্দিষ্টকাল ধরে রাখার অনুমতি নয়।
ভুল pruning ধরতে before-and-after regression চালান
Lifecycle workflow production-এ দেওয়ার আগে স্থির evaluation set তৈরি করুন। এতে সাম্প্রতিক preference মনে রাখা, superseded তথ্য প্রত্যাখ্যান, মেয়াদোত্তীর্ণ বিষয়কে সক্রিয় না দেখানো, procedural instruction অক্ষত রাখা এবং erasure-এর পরে targeted fact retrieve না হওয়ার case রাখুন। প্রতিটি case-এর expected criterion, নিষিদ্ধ stale claim এবং minimum acceptable result আগে নির্ধারণ করুন।
একই প্রশ্ন lifecycle run-এর আগে ও পরে চালিয়ে retrieved record ID এবং final answer—দুটিই তুলনা করুন। Consolidated summary মোটামুটি সঠিক উত্তর দিলেও গুরুত্বপূর্ণ qualifier হারাতে পারে; তাই aggregate quality score-এর পাশাপাশি contradiction rate, forbidden-memory retrieval এবং must-retain recall আলাদা gate হিসেবে রাখুন। High-impact test ব্যর্থ হলে deletion commit বন্ধ করে originals-কে নিয়ন্ত্রিত, recoverable quarantine-এ পাঠানো নিরাপদ।
প্রথমে dry run-এ কোনো record না সরিয়ে proposed action ও reason log করুন। Owner review থেকে threshold ঠিক হওয়ার পর সীমিত namespace-এ deletion চালু করুন। এতে pruning সাধারণ storage cleanup না থেকে পরীক্ষাযোগ্য governance control হয়: agent প্রয়োজনীয় continuity রাখে, কিন্তু পুরোনো দাবিকে অনির্দিষ্টকাল বর্তমান সত্য হিসেবে বহন করে না।
আরও পড়ুন:
আমাদের নিউজলেটার নিন
সর্বশেষ Web3, AI ও ক্রিপ্টো সংবাদ সরাসরি আপনার ইনবক্সে পান।