Nội dung này phục vụ mục đích giáo dục. Không dùng dữ liệu thật; không lưu mật khẩu, token, thông tin nhạy cảm hoặc dữ liệu chưa có sự đồng ý.

Trả lời ngắn: Memory Architecture là thiết kế cách hệ thống AI chọn điều cần nhớ, lưu ở đâu, tìm lúc nào, nạp vào context ra sao và sửa hoặc xóa thế nào. Nó cần thiết vì lưu toàn bộ chat không tạo ra trí nhớ đáng tin; ngược lại, nó dễ giữ rác, lộ dữ liệu và dùng record sai người.

Đọc xong, bạn sẽ hiểu:

  • Working, episodic, semantic và procedural memory khác nhau thế nào.
  • Vì sao cần write gate, read gate, source, scope và expiry.
  • Cách dựng Memory Record Card và vòng sửa–thay–xóa trước khi code.

1. Memory Architecture là gì, và vì sao lưu cả chat là sai?

a. Context không tự biến thành memory

Bài trước đã tách context khỏi memory: context là thứ model thấy trong lượt hiện tại; memory nằm ngoài lượt và phải được nạp lại. Memory Architecture đi thêm một bước: ai được ghi, ghi gì, dùng cho ai, bao lâu và cách sửa.

Một lịch sử trò chuyện chỉ là nhật ký (log): nó trộn sự thật, câu tạm thời, phỏng đoán, dữ liệu nhạy cảm và hướng dẫn cũ.

Nếu chép tất cả vào kho rồi gọi là memory, câu “Hôm nay trả lời ngắn thôi” có thể bị dùng tháng sau. Tệ hơn, câu “mật khẩu test là abc” trở thành record có thể bị truy xuất.

b. Working memory giống giấy nháp

Working memory là trạng thái ngắn hạn phục vụ phiên hoặc nhiệm vụ hiện tại: mục tiêu đang làm, bước đã xong, lựa chọn tạm thời. Nó giống giấy nháp trên bàn; hoàn tất việc thì có thể bỏ.

Ví dụ: “Trong phiên này dùng dữ liệu demo” hoặc “Hôm nay nói ngắn”. Không phải mọi working state đều cần đi vào memory dài hạn.

c. Memory không phải một sản phẩm duy nhất

Cơ sở dữ liệu vector, kho hội thoại hay bảng SQL chỉ là nơi/lối lưu. Chúng không tự quyết định bản ghi có đúng, được phép, còn mới hay thuộc đúng người dùng không.

OpenAI Conversations API cho phép lưu và lấy trạng thái qua nhiều lần gọi API; nó không tự cung cấp chính sách phân loại, đồng thuận, hạn dùng hay sửa lỗi. OpenAI — Conversations API

2. Bốn loại memory và pipeline ghi–đọc

Hình 1 — Memory có nhiều kho và hai cổng; không phải một hộp lưu toàn bộ chat.

Đây là taxonomy thực dụng, không phải chuẩn duy nhất.

a. Episodic, semantic và procedural

Episodic memory là ký ức về sự kiện: chuyện gì xảy ra, lúc nào, nguồn nào. Ví dụ “ticket T12 được reset mật khẩu ngày 26/7”. Nó cần thời gian, ID nguồn và retention hợp lý.

Semantic memory là sự thật hoặc ưu tiên đã xác nhận: “U1 ưu tiên tiếng Việt”, “dự án Alpha thuộc nhóm A”. Nó cần chủ thể, phạm vi, độ tin cậy và đường sửa.

Procedural memory là quy tắc/quy trình được phép áp dụng: “hoàn tiền trên 2 triệu cần quản lý duyệt”. Nguồn phải là chính sách đã duyệt; lời người dùng không được tự nâng thành quy trình công ty.

b. Write gate: cổng trước khi lưu

Write gate là cổng ghi: bộ điều kiện một bản ghi ứng viên phải qua:

  1. Có ích cho nhiệm vụ sau không?
  2. Có đồng thuận hoặc cơ sở hợp lệ để lưu không?
  3. Nguồn là người dùng xác nhận, hệ thống hay mô hình suy đoán?
  4. Phạm vi là phiên, người dùng, nhóm hay tenant?
  5. Có bí mật hoặc dữ liệu định danh cá nhân (PII) không cần thiết không?
  6. Độ tin cậy và hạn dùng là gì?
  7. Record cũ nào bị thay thế?

Trường hợp “Ưu tiên tiếng Việt” có thể được ghi vào semantic memory cho U1 nếu người dùng xác nhận. “Có vẻ U1 lớn tuổi” là suy đoán nhạy cảm, không có nhu cầu rõ: từ chối.

c. Store, retrieve và read gate

Sau khi ghi, hệ thống có thể khử trùng lặp, lập chỉ mục và hợp nhất. Khi có câu hỏi mới, truy xuất (retrieval) tìm các bản ghi ứng viên.

Read gate là cổng đọc, quyết định bản ghi nào được nạp vào context:

  • đúng danh tính và tenant;
  • liên quan nhiệm vụ hiện tại;
  • chưa hết hạn;
  • nguồn đủ tin;
  • không bị thay thế hoặc xóa;
  • không xung đột bản ghi ưu tiên hơn;
  • không vượt ngân sách context.

Truy xuất trả về “có vẻ giống” chưa đủ. Read gate mới chặn memory của U2 đi vào phiên U1 hoặc chính sách nháp lấn chính sách đã duyệt.

MemGPT đề xuất nhiều tầng memory để di chuyển dữ liệu giữa context nhanh và kho lớn hơn. Đây là kiến trúc nghiên cứu, không thay thế chính sách ghi–đọc. Packer et al. — MemGPT

3. Sai lầm, giới hạn và rủi ro riêng tư

a. Bốn lỗi thường gặp

  1. Lưu mọi thứ: kho phình, nhiễu và giữ dữ liệu không cần.
  2. Không có provenance: không biết bản ghi từ người dùng, mô hình hay chính sách.
  3. Không có scope: memory của người dùng/tenant này lọt sang bên khác.
  4. Chỉ biết thêm: bản ghi cũ không hết hạn, bị thay thế hoặc bị xóa.

Provenance là nguồn gốc bản ghi. Scope là phạm vi được dùng. Thiếu một trong hai, câu “hoàn tiền trên 2 triệu cần duyệt” rất nguy hiểm: nó có thể chỉ là lời một người dùng, không phải quy trình.

b. Fact có thể đổi, sự kiện có thể nhạy cảm

Semantic memory không bất biến. Người dùng đổi kênh liên hệ từ email sang SMS; bản ghi mới phải thay thế bản cũ. Bản ghi episodic “đã đặt lại mật khẩu” có thể hữu ích cho kiểm tra ngắn hạn nhưng không cần giữ mãi.

Retention là thời gian giữ dữ liệu. Expiry là lúc bản ghi hết hiệu lực cho việc đọc. Hai khái niệm liên quan nhưng không luôn giống nhau: bản ghi hết hạn có thể còn giữ trong kho kiểm tra theo chính sách, nhưng không được nạp vào context.

Quy tắc lưu trữ phụ thuộc nhà cung cấp và cấu hình. Data Controls của OpenAI có thể đổi theo điểm cuối, nên phải kiểm tra tài liệu chính thức khi triển khai. OpenAI — Data controls

c. Giới hạn: memory không biến model thành người

Generative Agents dùng bản ghi trải nghiệm, suy ngẫm và truy xuất động trong môi trường thử nghiệm 25 tác nhân. Kết quả đó không chứng minh memory ngoài đời luôn đúng hay có “nhân cách”. Park et al. — Generative Agents

Memory vẫn có thể lấy nhầm, lỗi thời, thiên lệch hoặc bị prompt injection (chèn chỉ dẫn độc hại) từ dữ liệu. Nhiệm vụ quan trọng cần bộ kiểm chứng và người duyệt.

4. Checklist thiết kế write gate, read gate và vòng đời

Hình 2 — Không có nguồn, phạm vi và hạn dùng thì một “ký ức” rất khó được tin hoặc xóa đúng.

a. Memory Record Card tối thiểu

memory_id
type: working | episodic | semantic | procedural
subject_id
content
source_id + source_type
created_at
confidence
scope
consent_basis
expires_at
status: candidate | active | superseded | deleted

Tên trường có thể khác; danh tính, nguồn, thời gian, phạm vi và vòng đời mới là phần bắt buộc.

b. Checklist ghi và đọc

Trước khi ghi:

  1. Xác định loại và ích lợi tương lai.
  2. Kiểm tra đồng thuận, quyền và dữ liệu nhạy cảm.
  3. Gắn chủ thể, nguồn, phạm vi, độ tin cậy.
  4. Đặt hạn dùng/thời gian giữ.
  5. Khử trùng lặp hoặc thay thế bản ghi cũ.

Trước khi đọc:

  1. Khóa danh tính/tenant.
  2. Lọc bản ghi đang hiệu lực, chưa hết hạn.
  3. Xếp theo độ liên quan, độ mới và ưu tiên nguồn.
  4. Giải quyết xung đột hoặc báo không chắc.
  5. Chỉ nạp phần cần vào context.
  6. Ghi nhật ký ID các bản ghi đã dùng.

c. Phải có đường sửa và quên

Hình 3 — Hệ thống phải biết sửa và quên, không chỉ biết thêm record mới.

Supersede là bản ghi mới thay bản ghi cũ nhưng giữ dấu vết kiểm tra. Delete là gỡ/xóa theo quyền và hệ thống phía sau thật; đừng chỉ đặt cờ giao diện trong khi dữ liệu vẫn được đọc.

Dừng triển khai nếu chưa chứng minh được: ai có quyền sửa/xóa, xóa tác động chỉ mục/bộ nhớ đệm/bản sao lưu ra sao, và memory của tenant khác không thể được truy xuất.

5. Bài tập 15 phút: phân loại 10 Memory Records giả

Dùng spreadsheet miễn phí. Tạo 10 câu giả, không có dữ liệu thật.

  • 3 phút: gắn working/episodic/semantic/procedural.
  • 4 phút: điền source, scope, consent, expiry.
  • 3 phút: chọn write, session-only hoặc reject.
  • 3 phút: mô phỏng read gate cho user U1.
  • 2 phút: tạo một supersede và một delete request.

Mẫu đối chiếu đã điền

Record Type Decision Lý do
“Ưu tiên tiếng Việt” Semantic Write user xác nhận, U1 scope
“Hôm nay nói ngắn” Working Session-only tạm thời
“Mật khẩu là abc” — Reject secret
“Refund >2m cần duyệt” từ user — Reject sai authority

Tổng demo: write 5, session-only 2, reject 3. Kết quả mong đợi là mỗi dòng có lý do và owner/scope rõ; không có record “lưu vì có thể hữu ích”.

6. Tổng kết và bài học tiếp theo

a. Năm ý chính

  • Memory Architecture quản trị vòng đời, không phải tên một kho dữ liệu.
  • Working, episodic, semantic và procedural memory phục vụ mục đích khác nhau.
  • Write gate chặn rác; read gate chặn dùng sai record.
  • Source, scope, consent, confidence và expiry là metadata bắt buộc phải cân nhắc.
  • Hệ thống phải sửa, supersede, expire và delete có kiểm chứng.

b. Câu hỏi tự kiểm tra

  • Vì sao chat log không phải memory đáng tin?
  • Episodic khác semantic memory ở đâu?
  • Write gate và read gate chặn hai loại lỗi nào?
  • Supersede khác delete ở đâu?

c. Gợi ý đáp án

Xem gợi ý câu 1

Log trộn fact, câu tạm, suy đoán và dữ liệu nhạy cảm; cần write gate. → xem mục 1.

Xem gợi ý câu 2

Episodic giữ sự kiện có thời gian; semantic giữ fact/preference đã xác nhận. → xem mục 2.

Xem gợi ý câu 3

Write gate chặn ghi sai; read gate chặn nạp sai user, scope, tuổi hoặc nguồn. → xem mục 2.

Xem gợi ý câu 4

Supersede thay bản cũ nhưng giữ dấu vết; delete thực hiện yêu cầu gỡ/xóa. → xem mục 4.

d. Thuật ngữ cần nhớ

Thuật ngữ Giải thích ngắn
Working memory Trạng thái ngắn hạn của phiên/task.
Episodic memory Sự kiện có thời gian và nguồn.
Semantic memory Fact/preference đã xác nhận.
Procedural memory Quy trình được phép áp dụng.
Write gate Điều kiện record được ghi.
Read gate Điều kiện record được nạp.
Provenance Nguồn gốc record.
Scope Phạm vi record được dùng.
Expiry Thời điểm record hết hiệu lực.
Supersede Bản mới thay bản cũ có dấu vết.

e. Nguồn tham khảo

f. Học tiếp gì?

Bài trước là Long Context là gì? #7, nơi ta chia sức chứa của một lượt. Bài tiếp theo là Vector Database là gì? #9, nơi ta học cách biểu diễn, tìm và lọc candidate records — một phần của retrieval, không phải toàn bộ memory architecture.

Nhắc lại: Nội dung chỉ phục vụ mục đích giáo dục, không phải lời khuyên đầu tư. Không lưu secret, PII hoặc dữ liệu chưa có consent; không tuyên bố sửa/xóa nếu backend chưa thực hiện và kiểm chứng được.