Trong bài viết trước về memory của AI agent, chúng ta đã nói về vai trò của trí nhớ trong việc giúp một hệ thống AI duy trì bối cảnh, cá nhân hóa trải nghiệm và tích lũy kinh nghiệm qua nhiều lần tương tác. Tuy nhiên, việc có một nơi để lưu memory mới chỉ là điểm khởi đầu.

Giả sử một AI agent có quyền lưu lại toàn bộ lịch sử hội thoại, mọi kết quả từ tool và tất cả phản hồi của người dùng. Nếu hệ thống ghi nhớ mọi thứ mà không chọn lọc, kho memory sẽ nhanh chóng chứa đầy thông tin trùng lặp, lỗi thời hoặc không còn liên quan. Đến lúc cần sử dụng, agent có thể truy xuất nhầm một thông tin cũ, bỏ qua một thay đổi quan trọng hoặc đưa quá nhiều dữ liệu vào context đến mức model bị phân tán. Nói cách khác, một hệ thống AI không trở nên hữu ích hơn chỉ vì nó có nhiều memory hơn. Điều quan trọng là hệ thống đó ghi nhớ điều gì, lưu ở đâu, truy xuất khi nào và đưa bao nhiêu thông tin trở lại context. Đây chính là bài toán của memory pipeline. 

Vậy làm thế nào để xây dựng một memory pipeline hiệu quả và tối ưu? Hãy cùng Lemon’s Tribe tìm hiểu trong bài viết kỳ này nhé.

Memory không chỉ là một database

Khi nói về memory của AI, nhiều người thường nghĩ ngay đến vector database. Quy trình quen thuộc là đưa lịch sử hội thoại thành embedding, lưu vào database và dùng semantic search để tìm lại những đoạn liên quan. Tuy nhiên, cách tiếp cận này phù hợp với một bản thử nghiệm đơn giản, nhưng chưa đủ để tạo thành một memory system có thể vận hành ổn định trong production. Vector database chỉ trả lời một phần của bài toán: dữ liệu được lưu ở đâu và tìm lại bằng độ tương đồng ngữ nghĩa như thế nào. Nó không tự quyết định được một câu nói có đáng ghi nhớ hay không, thông tin mới có mâu thuẫn với memory cũ hay không, một memory nên tồn tại trong bao lâu hoặc dữ liệu nào được phép sử dụng trong từng phạm vi người dùng (tenant – đơn vị người dùng/khách hàng trong hệ thống multi-tenant).

Một memory system hoàn chỉnh cần ít nhất hai pipeline chính:

• Write path: quyết định thông tin nào sẽ được ghi vào memory và lưu chúng như thế nào.
• Read path: quyết định memory nào cần được lấy ra và đưa trở lại context tại một thời điểm cụ thể.

Nằm giữa hai pipeline này là memory manager — lớp điều phối toàn bộ vòng đời của memory.

Đây cũng là lý do chất lượng của memory system phụ thuộc nhiều hơn vào kiến trúc và logic quản trị dữ liệu, thay vì chỉ phụ thuộc vào loại database được sử dụng.

Memory manager: “Quản gia” của hệ thống trí nhớ

Có thể hình dung memory manager giống như một người quản gia đứng giữa AI agent và các kho lưu trữ.

Mỗi khi có thông tin mới, memory manager cần quyết định:

• Thông tin này có đáng ghi nhớ không?
• Đây là preference, một sự kiện, một quy tắc hay chỉ là dữ liệu tạm thời?
• Nó nên được lưu trong profile, SQL database, vector store, graph database hay file?
• Memory mới sẽ bổ sung, thay thế hay mâu thuẫn với memory cũ?
• Memory nên tồn tại vĩnh viễn hay cần hết hạn sau một khoảng thời gian?

Khi agent thực hiện một task mới, memory manager tiếp tục quyết định:

• Có cần truy xuất memory không?
• Nên tìm trong kho nào?
• Memory nào phù hợp với người dùng, phiên làm việc và task hiện tại?
• Nên đưa bao nhiêu memory vào context?
• Memory nào cần được ưu tiên và memory nào nên bị loại bỏ?

Memory manager không nhất thiết phải là một module duy nhất. Trong hệ thống thực tế, vai trò này có thể được phân tán giữa orchestration logic, LLM, retrieval engine, policy engine và các dịch vụ quản lý dữ liệu. Điểm cốt lõi là hệ thống phải có một lớp chịu trách nhiệm cho các quyết định về memory. Nếu không, việc lưu và truy xuất thông tin sẽ trở thành những thao tác rời rạc, khó kiểm soát và gần như không thể debug khi xảy ra lỗi.

Các kiến trúc như MemGPT và Letta cũng tiếp cận memory theo hướng phân tầng: một phần thông tin luôn nằm trong context, trong khi những dữ liệu lớn hơn được lưu bên ngoài và chỉ được đưa vào khi cần. Cách tiếp cận này khá giống virtual memory của hệ điều hành: không phải tất cả dữ liệu đều phải nằm trong vùng nhớ nhanh cùng một lúc.

Write path: AI quyết định nên nhớ điều gì?

Write path là quá trình biến một tương tác thô thành memory có thể tái sử dụng. Một write path phổ biến có thể gồm các bước:

Capture → Extract → Evaluate → Deduplicate → Categorize → Store

Mỗi bước đều giải quyết một bài toán khác nhau.

Capture: Thu nhận dữ liệu đầu vào

Memory có thể được hình thành từ nhiều nguồn:

• nội dung người dùng cung cấp;
• phản hồi của agent;
• kết quả trả về từ tool;
• trạng thái của task;
• feedback trực tiếp;
• lỗi hoặc phương án thất bại;
• quyết định được đưa ra trong quá trình xử lý.

Ví dụ, một customer service agent có thể nhận được thông tin rằng khách hàng vừa đổi số điện thoại. Một coding agent có thể phát hiện rằng dự án luôn yêu cầu chạy một lệnh build cụ thể trước khi deploy.

Ở bước này, hệ thống chưa nhất thiết phải lưu mọi thứ thành long-term memory. Capture chỉ tạo ra nguồn dữ liệu để các bước sau đánh giá.

Extract: Tách thông tin có khả năng hữu ích

Transcript thường chứa nhiều chi tiết không cần thiết. Vì vậy, hệ thống cần chuyển nội dung thô thành các memory candidate ngắn gọn và có cấu trúc hơn. Ví dụ, từ câu: “Từ nay gửi hóa đơn qua email công ty giúp tôi, đừng gửi vào email cá nhân nữa.”, hệ thống có thể trích xuất kênh nhận hóa đơn ưu tiên: email công ty. Hoặc với một tool có output dài hàng nghìn dòng, agent có thể chỉ lưu lại kết luận: Lỗi deploy xuất phát từ biến môi trường chưa được khai báo.

Mục tiêu của extraction không phải là sao chép lại toàn bộ cuộc hội thoại, mà là giữ phần thông tin có khả năng thay đổi quyết định trong tương lai.

Evaluate: Thông tin này có thực sự đáng nhớ?

Đây là bước admission control — kiểm soát dữ liệu nào được phép đi vào memory.

Một thông tin thường đáng lưu khi nó:

• phản ánh preference tương đối ổn định;
• là một quyết định quan trọng;
• liên quan đến mục tiêu chưa hoàn thành;
• là correction (sửa sai) từ người dùng;
• ghi nhận một lỗi hoặc bài học có khả năng lặp lại;
• chứa constraint (hạn chế) mà agent cần tuân thủ;
• có khả năng được sử dụng trong các phiên sau.

Ngược lại, small talk, trạng thái tạm thời hoặc những suy luận chưa được xác minh thường không nên trở thành long-term memory.

Ví dụ, câu “hôm nay tôi hơi mệt” có thể hữu ích trong cuộc trò chuyện hiện tại nhưng chưa chắc cần được lưu lâu dài. Trong khi đó, “tôi bị dị ứng với ciproflocaxin” là thông tin nhạy cảm nhưng có thể ảnh hưởng lớn đến quyết định trong tương lai. Nếu hệ thống được phép lưu loại dữ liệu này, nó cần chính sách bảo mật và quyền kiểm soát chặt chẽ hơn.

Một nguyên tắc quan trọng là: không đánh giá memory chỉ dựa trên khả năng sử dụng, mà còn dựa trên độ tin cậy, độ nhạy cảm và phạm vi sử dụng hợp lệ.

Deduplicate: Tránh tạo nhiều phiên bản của cùng một memory

Nếu người dùng nhắc lại cùng một preference trong nhiều cuộc hội thoại, hệ thống không nên tạo ra hàng chục memory giống nhau. Trước khi ghi, memory manager cần tìm các memory liên quan để xác định xem thông tin mới nên:

• được bỏ qua vì đã tồn tại;
• hợp nhất với memory cũ;
• cập nhật một phần;
• ghi đè memory cũ;
• tạo thành một phiên bản mới.

Deduplication không chỉ giúp tiết kiệm dung lượng. Nó còn làm giảm nguy cơ retrieval lấy ra nhiều bản ghi giống nhau, chiếm context nhưng không bổ sung thêm giá trị.

Categorize: Không phải memory nào cũng nên nằm trong vector database

Sau khi được chấp nhận, memory cần được phân loại và chuyển đến kho lưu trữ phù hợp.

Một số ví dụ:

• Profile hoặc SQL: dữ liệu có cấu trúc như preference, trạng thái tài khoản, constraint và thuộc tính người dùng.
• Vector store: sự kiện, lịch sử tương tác hoặc nội dung cần semantic search.
• Graph database: quan hệ giữa người, tổ chức, sự kiện và các thực thể.
• File hoặc document store: guideline, workflow, debugging note và procedural memory.
• Working memory: trạng thái tạm thời của phiên hoặc task đang chạy.

Việc cố lưu mọi thứ vào một loại database thường khiến hệ thống mất đi cấu trúc cần thiết. Một user preference rõ ràng như ngôn ngữ giao tiếp phù hợp với profile hơn một đoạn embedding. Ngược lại, lịch sử xử lý một vấn đề phức tạp có thể phù hợp với vector search hơn một cột trong bảng SQL.

Store: Memory cần đi kèm metadata

Một memory không nên chỉ có nội dung.

Hệ thống còn cần biết:

• memory thuộc về ai;
• được tạo từ nguồn nào;
• được ghi nhận vào thời điểm nào;
• mức độ tin cậy ra sao;
• thuộc loại memory nào;
• phiên bản hiện tại là gì;
• có ngày hết hạn hay không;
• ai hoặc agent nào được quyền truy cập.

Memory nên đi kèm metadata vì metadata là nền tảng cho filtering, versioning, audit và privacy. Google Memory Bank, chẳng hạn, hỗ trợ revision history và TTL (time to live – hạn sử dụng) cho memory. Mỗi lần memory thay đổi, hệ thống có thể tạo một revision mới để theo dõi quá trình tiến hóa của thông tin và rollback khi cần.

Nên ghi memory ngay hay xử lý sau?

Không phải memory nào cũng cần được ghi trong lúc agent đang trả lời.

Có hai các ghi memory mà LangChain đề xuất:

• Hot-path writing: memory được tạo ngay trong luồng xử lý hiện tại.
• Background writing: memory được tạo bất đồng bộ sau khi tương tác kết thúc.

Hot-path writing phù hợp khi memory mới phải ảnh hưởng ngay đến lượt tiếp theo. Ví dụ, người dùng vừa sửa một thông tin quan trọng và agent không được phép tiếp tục sử dụng dữ liệu cũ. Tuy nhiên, việc vừa xử lý yêu cầu vừa trích xuất, đánh giá và lưu memory có thể làm tăng latency. Agent cũng phải chia khả năng suy luận giữa nhiệm vụ chính và nhiệm vụ quản lý memory.

Background writing phù hợp với những thông tin phục vụ các phiên sau, chẳng hạn tóm tắt cuộc hội thoại, cập nhật profile hoặc rút ra bài học từ một task đã hoàn thành.

Một hệ thống thực tế thường kết hợp cả hai: correction quan trọng được cập nhật ngay, còn việc tổng hợp và tối ưu memory được thực hiện bất đồng bộ.

Read path: AI tìm lại đúng memory như thế nào?

Nếu write path quyết định nên lưu gì, read path quyết định nên sử dụng gì.

Một read path có thể gồm:

Query understanding → Candidate retrieval → Filtering → Ranking → Context assembly

Query understanding: Agent đang cần loại thông tin nào?

Không phải yêu cầu nào cũng cần truy xuất tất cả các kho memory. Khi người dùng hỏi về preference, hệ thống có thể ưu tiên profile. Khi agent cần tìm lại một trường hợp xử lý tương tự, episodic memory có thể hữu ích hơn. Khi cần tuân thủ quy trình, procedural memory mới là nguồn phù hợp.

Việc hiểu mục đích truy xuất giúp giảm phạm vi tìm kiếm và tránh đưa những memory không liên quan vào context.

Candidate retrieval: Tạo danh sách memory có khả năng phù hợp

Semantic similarity là phương pháp quen thuộc nhất: truy vấn và memory được biểu diễn bằng embedding, sau đó hệ thống lấy những bản ghi gần nhất. Tuy nhiên, semantic search không đủ cho mọi tình huống. Tên khách hàng, mã giao dịch, số ticket hoặc tên file thường cần keyword search hoặc exact match. Những câu hỏi liên quan đến quan hệ giữa nhiều thực thể có thể cần graph search. Các task phụ thuộc thời gian cần lọc theo timestamp (mốc thời gian) hoặc trạng thái hiện tại.

Vì vậy, retrieval trong production thường là hybrid retrieval, kết hợp:

• semantic similarity (tương đồng về ngữ nghĩa);
• keyword search;
• metadata filtering;
• entity matching;
• graph traversal (duyệt đồ thị);
• temporal filtering (lọc theo thời gian).

Ranking: Liên quan chưa chắc đã nên được ưu tiên

Paper Generative Agents đề xuất ba tín hiệu nổi bật để xếp hạng memory:

• Relevance: liên quan đến tình huống hiện tại.
• Recency: mới xảy ra hoặc mới được sử dụng.
• Importance: có ý nghĩa lớn đối với quyết định của agent.

Ba yếu tố này giải quyết ba vấn đề khác nhau của cùng 1 bài toán. Nếu chỉ dùng relevance, hệ thống có thể lấy một memory rất giống về mặt ngữ nghĩa nhưng đã lỗi thời. Nếu chỉ ưu tiên recency, một chi tiết nhỏ vừa được nhắc đến có thể lấn át một quyết định quan trọng. Nếu importance được chấm thiếu kiểm soát, hệ thống lại có thể liên tục đưa những memory “quan trọng” nhưng không liên quan vào context.

Trong thực tế, ranking có thể kết hợp thêm confidence (độ tự tin của model), user scope, trạng thái task và business priority.

Context assembly: Không phải memory được tìm thấy đều nên đưa vào prompt

Sau khi ranking, hệ thống vẫn cần một bước cuối: chọn và biên soạn context. Anthropic gọi context là một tài nguyên hữu hạn. Context window càng dài không đồng nghĩa model sử dụng thông tin tốt hơn; khi lượng token tăng lên, khả năng tập trung và truy xuất chính xác có thể suy giảm. Mục tiêu của context engineering là tìm tập thông tin nhỏ nhất nhưng có tín hiệu cao nhất để hỗ trợ hành vi mong muốn.

Vì vậy, memory manager có thể:

• giới hạn số lượng memory;
• loại bỏ phần trùng lặp;
• tóm tắt các sự kiện dài;
• giữ lại source và timestamp;
• nhóm memory theo loại;
• ưu tiên correction mới nhất;
• chỉ đưa phần có khả năng thay đổi quyết định.

Một retrieval system tốt không phải hệ thống tìm được nhiều nhất. Nó là hệ thống đưa được đúng lượng thông tin cần thiết vào context.

Lifecycle: Memory phải có khả năng thay đổi và biến mất

Memory không phải dữ liệu bất biến. Preference của người dùng có thể thay đổi. Quy trình nội bộ có thể được cập nhật. Một task có thể đã hoàn thành. Một correction mới có thể khiến memory cũ không còn hợp lệ.

Vì vậy, hệ thống cần hỗ trợ:

• Merge: hợp nhất thông tin bổ sung.
• Overwrite: thay thế dữ liệu cũ.
• Versioning: lưu lịch sử thay đổi.
• Invalidate: đánh dấu memory không còn hợp lệ.
• TTL: tự động hết hạn.
• Archive: chuyển memory ít sử dụng sang lớp lưu trữ khác.
• Delete: xóa dữ liệu theo yêu cầu hoặc policy.

Nếu hệ thống chỉ biết thêm memory mà không biết cập nhật và quên, kho dữ liệu sẽ trở thành một tập hợp những “sự thật” mâu thuẫn. Đây cũng là lý do forgetting không phải lỗi của memory system, mà trong nhiều trường hợp, nó là một chức năng cần thiết.

Tối ưu memory pipeline: Đừng chỉ chăm chăm cải thiện retrieval

Khi memory trả về kết quả không tốt, phản ứng phổ biến là điều chỉnh embedding model, tăng top-k hoặc bổ sung reranker, thế nhưng nhiều vấn đề của read path thực chất bắt đầu từ write path. Nếu memory ban đầu được trích xuất sai, thiếu timestamp, không có provenance hoặc chứa quá nhiều thông tin dư thừa, retrieval tốt đến đâu cũng chỉ tìm lại dữ liệu kém chất lượng nhanh hơn. Do đó, tối ưu memory system cần nhìn vào cả hai hướng.

Tối ưu write path

• Chỉ lưu thông tin có khả năng tái sử dụng.
• Phân biệt sự thật, thiên kiến/sở thích, sự kiện và suy luận.
• Gắn source, timestamp, confidence và scope.
• Deduplicate trước khi tạo memory mới.
• Xử lý correction như một thao tác cập nhật, chứ không phải bổ sung thêm cho nội dung cũ đã sai.
• Dùng background processing cho các tác vụ không cần tức thời.
• Đặt TTL cho dữ liệu tạm thời.
• Không lưu dữ liệu nhạy cảm nếu chưa có policy (chính sách) và consent (sự đồng thuận) phù hợp.

Tối ưu read path

• Chọn nguồn memory dựa trên intent.
• Kết hợp semantic, keyword, metadata và temporal search.
• Rank bằng nhiều tín hiệu thay vì similarity đơn thuần.
• Lọc theo user, tenant, task và permission.
• Tóm tắt memory trước khi đưa vào context.
• Kiểm soát token budget.
• Ưu tiên dữ liệu chuẩn hơn memory được suy diễn.
• Không cho memory cũ ghi đè dữ liệu hiện tại của hệ thống.

Nói ngắn gọn, write path bảo đảm hệ thống nhớ đúng, còn read path bảo đảm hệ thống nhớ đúng lúc.

Đánh giá memory system như thế nào?

Bạn không thể chỉ nhìn vào câu trả lời cuối cùng rồi kết luận memory hoạt động tốt. Một agent có thể trả lời đúng vì thông tin vẫn còn trong context hiện tại, dù memory chưa bao giờ được lưu. Ngược lại, memory có thể được lưu đúng nhưng retrieval không tìm thấy khi cần. Do đó, evaluation cần tách thành nhiều lớp:

Write quality

• Hệ thống có phát hiện đúng thông tin đáng lưu không?
• Memory được trích xuất có chính xác không?
• Có tạo memory dư thừa không?
• Correction có cập nhật đúng bản ghi cũ không?
• Dữ liệu nhạy cảm có bị lưu sai policy không?

Retrieval quality

• Memory cần thiết có nằm trong kết quả tìm kiếm không?
• Memory lỗi thời có bị ưu tiên không?
• Ranking có chọn đúng thông tin quan trọng không?
• Có xảy ra cross-user hoặc cross-tenant leakage không?

End-to-end quality

• Memory có thực sự cải thiện câu trả lời và hành động của agent không?
• Hệ thống có giảm việc hỏi lại người dùng không?
• Agent có duy trì tính nhất quán qua nhiều phiên không?
• Memory sai có làm tăng hallucination không?

Ngoài accuracy, production system còn phải theo dõi token cost (chi phí token), latency (độ trễ), tỷ lệ write thành công, số memory được tạo, retrieval hit rate (tỷ lệ truy xuất thành công) và tỷ lệ memory bị cập nhật hoặc xóa. Mem0 cũng nhấn mạnh rằng đánh giá memory cần cân bằng giữa chất lượng, chi phí token và độ trễ thay vì chỉ nhìn vào một benchmark duy nhất.

Những lỗi thiết kế thường gặp

1. Lưu toàn bộ transcript rồi để semantic search xử lý

Lỗi đầu tiên là lưu toàn bộ transcript rồi hy vọng semantic search sẽ tự giải quyết phần còn lại. Đây là cách nhanh nhất để tạo prototype, nhưng hiếm khi là cách tốt để vận hành lâu dài. Transcript chứa nhiều small talk, câu hỏi lặp lại, suy luận trung gian và thông tin chỉ có ý nghĩa trong một thời điểm cụ thể. Khi tất cả được lưu như nhau, semantic search phải tìm tín hiệu trong một kho dữ liệu ngày càng nhiều nhiễu. Kết quả là hệ thống vừa tốn chi phí lưu trữ, vừa dễ truy xuất những đoạn gần giống về từ ngữ nhưng không còn giá trị.

2. Dùng một loại store cho mọi memory

Lỗi thứ hai là sử dụng một store cho mọi loại memory. Vector database không phải câu trả lời cho mọi loại dữ liệu. Preference có cấu trúc, trạng thái tài khoản hoặc quyền truy cập thường phù hợp với SQL hoặc profile store. Quan hệ giữa nhiều thực thể có thể cần graph database. Tài liệu dài và quy trình có thể phù hợp với document store. Với các đặc điểm khác nhau như vậy, sẽ cần có cách lưu trữ khác nhau.

Khi bạn chọn cách lưu trữ memory của AI nên bắt đầu từ đặc điểm truy cập của dữ liệu, không phải từ công nghệ đang phổ biến.

3. Chỉ append mà không update

Lỗi thứ ba là append-only memory.

Một hệ thống append-only sẽ liên tục tạo thêm memory mới nhưng không xử lý dữ liệu cũ. Nếu người dùng đổi địa chỉ email ba lần, hệ thống có thể giữ lại cả ba địa chỉ và chờ retrieval quyết định cái nào đúng. Đây là cách đẩy một vấn đề của lifecycle sang read path, nơi nó trở nên khó kiểm soát hơn. Correction nên kích hoạt update, overwrite hoặc invalidation, không chỉ tạo thêm một embedding mới.

4. Không lưu provenance và timestamp

Khi không biết memory đến từ đâu và được tạo lúc nào, hệ thống khó đánh giá độ tin cậy hoặc độ mới của dữ liệu. Một sự thật được đọc trực tiếp từ dữ liệu hiện tại của hệ thống (system-of-record) phải có trọng số khác với một suy luận do LLM tạo ra. Một preference được người dùng xác nhận hôm qua cũng nên được ưu tiên hơn một suy luận từ sáu tháng trước. Không có provenance và timestamp, ranking gần như mất đi hai tín hiệu quan trọng nhất.

5. Đưa quá nhiều memory vào context

Việc truy xuất được 20 memory không có nghĩa cả 20 memory đều nên xuất hiện trong prompt. Điều này chỉ khiến context của bạn dài hơn. Context dài hơn có thể làm tăng chi phí, độ trễ và distraction. Model phải phân bổ sự chú ý cho nhiều thông tin hơn, trong đó có thể có các chi tiết trùng lặp hoặc mâu thuẫn. Anthropic gọi đây là bài toán quản lý attention budget: mục tiêu không phải lấp đầy context window, mà là sử dụng nó cho những thông tin có tín hiệu cao nhất.⁴

5. Để memory ghi đè nguồn dữ liệu chính thức

Memory thường được tạo từ hội thoại hoặc qua quá trình trích xuất của LLM. Vì vậy, nó có thể sai, thiếu hoặc đã lỗi thời. Nếu hệ thống có một nguồn dữ liệu chính thức như CRM, transaction database hoặc policy service; memory không nên được coi là nguồn thay thế. Trong trường hợp có xung đột, system-of-record cần được ưu tiên, còn memory chỉ nên đóng vai trò bổ sung context.

6. Không có cơ chế quên

Một hệ thống chỉ biết ghi nhưng không biết quên sẽ tích lũy ngày càng nhiều dữ liệu cũ. Ngoài vấn đề chi phí và retrieval quality, điều này còn tạo ra rủi ro privacy. Người dùng cần có khả năng xem, sửa và xóa những thông tin hệ thống đang lưu về họ. Dữ liệu cũng cần được tự động xóa khi hết mục đích sử dụng hoặc vượt quá thời hạn cho phép. Forgetting vì vậy không phải bước dọn dẹp phụ trợ, mà nó nên là một phần của thiết kế memory ngay từ đầu.

Tạm kết

Khi nói về memory của AI, chúng ta rất dễ bị thu hút bởi câu hỏi hệ thống có thể nhớ được bao nhiêu. Nhưng trên thực tế, dung lượng chưa bao giờ là phần khó nhất. Điều khó hơn là biết thông tin nào xứng đáng được giữ lại, thông tin nào đã không còn đúng và khi nào một ký ức nên được truy xuất để hỗ trợ quyết định hiện tại.

Một agent lưu được mọi cuộc hội thoại nhưng không biết chọn lọc sẽ không trở nên thông minh hơn. Nó chỉ mang theo một quá khứ ngày càng nặng nề. Ngược lại, một hệ thống biết quản lý memory có thể không nhớ tất cả, nhưng vẫn duy trì được sự liên tục, tránh lặp lại sai lầm và thích nghi tốt hơn sau mỗi lần tương tác. Đó cũng là vai trò thực sự của memory pipeline.

Xây dựng một hệ thống memory hiệu quả, vì vậy, không phải là cố gắng tạo ra một AI không bao giờ quên. Ngược lại, một hệ thống như thế vừa tốn kém, vừa khó kiểm soát và chưa chắc hữu ích. Điều chúng ta cần là một hệ thống biết nhớ có chủ đích: giữ lại những gì còn giá trị, cập nhật khi thực tế thay đổi và loại bỏ những thông tin không còn phục vụ cho quyết định phía trước. Có thể nói, đến cuối cùng, trí nhớ chỉ thực sự có ý nghĩa khi nó giúp hệ thống hành động tốt và hợp lý hơn.

---

Nguồn tham khảo

1. Anthropic, Effective context engineering for AI agents.
2. Anthropic, Building effective agents.
3. LangChain, Memory overview.
4. LangChain, Context Engineering for Agents.
5. Google Cloud, Agent Platform Memory Bank.
6. Letta, Context hierarchy.
7. Mem0, Memory Evaluation.
8. Mem0, Building Production-Ready AI Agents with Scalable Long-Term Memory.
9. Park et al., Generative Agents: Interactive Simulacra of Human Behavior.
10. Packer et al., MemGPT: Towards LLMs as Operating Systems.
11. Sumers et al., Cognitive Architectures for Language Agents.