Bài 3 — Long-term memory: khi nào cần và các kiểu lưu trữ

Khi short-term không còn đủ

Short-term memory mất khi phiên kết thúc. Nhưng nhiều tình huống đòi hỏi agent nhớ qua các phiên:

• Trợ lý cá nhân nhớ bạn ăn chay, dị ứng hải sản → gợi ý món phù hợp lần sau.
• Agent hỗ trợ kỹ thuật nhớ khách này đã báo lỗi X tuần trước.
• Bot bán hàng nhớ lịch sử mua để upsell đúng.

Đó là lúc cần long-term memory: thông tin được lưu ra ngoài LLM và nạp lại có chọn lọc.

Khung quyết định: có thật sự cần long-term memory không?

Đừng mặc định thêm long-term. Hãy soi qua 4 câu hỏi:

• Thông tin có cần vượt qua ranh giới phiên không? Không → chỉ cần short-term.
• Nó có thay đổi theo thời gian và cần cập nhật không? (sở thích user) → cần store ghi/sửa được.
• Nó có sẵn ở nguồn khác đáng tin hơn không? Nếu địa chỉ giao hàng đã ở CRM, hãy gọi API CRM thay vì tự nhớ.
• Sai/lỗi thời của nó gây hại tới đâu? Càng nhạy cảm càng cần nguồn chuẩn, không dựa vào bộ nhớ "mềm".

Ba kiểu long-term memory phổ biến

• Key-value / structured store (SQL, Redis): dữ liệu có cấu trúc, tra theo khóa. Ví dụ user:123 → {ăn_chay: true, múi_giờ: +7}. Nhanh, chính xác, dễ cập nhật. Dùng khi bạn biết chính xác cần tra theo trường nào.
• Document / vector store: dữ liệu phi cấu trúc (đoạn văn, tài liệu, ghi chú hội thoại) truy xuất theo ngữ nghĩa. Dùng khi câu hỏi mơ hồ, không có khóa rõ ràng ("khách từng phàn nàn về cái gì?"). Đây là nền của RAG — học từ bài 4.
• Episodic / event log: ghi lại các sự kiện theo thời gian ("12/07 khách hủy đơn"). Dùng để agent kể lại lịch sử hoặc rút bài học.

Nhiều agent thật sự kết hợp cả ba: profile ở SQL, tài liệu ở vector store, sự kiện ở event log.

Ví dụ cụ thể: trợ lý học tập cá nhân hóa

Agent kèm học tiếng Anh cần nhớ:

• Trình độ hiện tại, mục tiêu → key-value (user:88 → {level: B1, goal: IELTS 6.5}).
• Các đoạn hội thoại/ghi chú học viên từng viết → vector store (tra theo ngữ nghĩa khi ôn tập).
• Lịch sử bài đã học → event log ("đã hoàn thành Unit 3 ngày 05/07").

Mỗi loại được nạp vào prompt vào đúng thời điểm cần, không nạp tất cả cùng lúc.

Các bước thiết kế lớp long-term memory

• Liệt kê các mẩu thông tin cần nhớ lâu (từ khung Bài 1).
• Phân loại mỗi mẩu: có cấu trúc (→ key-value), phi cấu trúc (→ vector), hay sự kiện (→ log).
• Định nghĩa schema/khóa cho phần key-value.
• Quyết định khi nào ghi (sau mỗi lượt? cuối phiên? khi user xác nhận?) và khi nào đọc (đầu mỗi phiên? khi câu hỏi liên quan?).
• Định nghĩa cách cập nhật và xóa — long-term memory sai còn tệ hơn không có.

Pseudocode: đọc/ghi profile khi bắt đầu và kết thúc phiên

def on_session_start(user_id):
    profile = kv_store.get(f"user:{user_id}")   # đọc long-term
    system = SYSTEM_PROMPT + f"\nHồ sơ: {profile}"
    return system

def on_fact_learned(user_id, fact):
    # ví dụ user nói 'tôi ăn chay' -> cập nhật
    kv_store.update(f"user:{user_id}", fact)

Checklist long-term memory

• [ ] Đã xác định thông tin nào thật sự cần vượt phiên?
• [ ] Đã chọn đúng kiểu store cho từng loại dữ liệu?
• [ ] Có quy tắc rõ ràng về thời điểm ghi/đọc?
• [ ] Có cơ chế cập nhật và xóa khi thông tin lỗi thời?
• [ ] Thông tin nhạy cảm có được ưu tiên lấy từ nguồn chuẩn (CRM/DB) thay vì bộ nhớ mềm?

Sai lầm thường gặp

• Dùng vector store cho mọi thứ. Sở thích user là dữ liệu có cấu trúc — key-value tra nhanh và chính xác hơn nhiều.
• Ghi nhớ mọi câu người dùng nói. Store phình to, nhiễu, tốn chi phí truy xuất. Chỉ nhớ cái có giá trị tái sử dụng.
• Không bao giờ cập nhật/xóa. Agent tiếp tục tin "user thích cà phê" dù họ đã bỏ cà phê 6 tháng.
• Nhớ thứ nên tra realtime. Số dư tài khoản, tồn kho phải gọi API tức thời, không được "nhớ".

Tổng kết

Long-term memory là để nhớ qua phiên, và nó có nhiều hình thái: key-value, vector, event log. Chọn đúng hình thái theo cấu trúc dữ liệu và cách truy xuất. Bài sau ta đi sâu vào vector store — trái tim của truy xuất theo ngữ nghĩa.