Bài 8 — Cây quyết định chọn memory và tình huống thực chiến

Mục tiêu bài cuối

Gói toàn khóa thành một quy trình quyết định áp dụng được ngay, rồi luyện qua các tình huống thật để bạn chọn đúng loại memory mà không phải đoán.

Cây quyết định chọn memory

Với mỗi mẩu thông tin agent cần, đi theo cây sau:

Thông tin có cần vượt qua ranh giới PHIÊN không?
├─ KHÔNG -> SHORT-TERM (context window)
│           dài quá? -> truncation / summarization / pinned facts
│
└─ CÓ -> nó có phải dữ liệu THAY ĐỔI REALTIME (tồn kho, số dư)?
         ├─ CÓ -> KHÔNG lưu memory, gọi API/DB nguồn tức thời
         │
         └─ KHÔNG -> nó có CẤU TRÚC rõ, tra theo khóa được không?
                  ├─ CÓ -> KEY-VALUE / SQL (profile, cấu hình)
                  │
                  └─ KHÔNG (văn bản, tra theo ý nghĩa)
                           -> VECTOR STORE + RAG
                              (kèm metadata lọc theo user/nguồn)

Có cần nhớ CHUỖI SỰ KIỆN theo thời gian? -> thêm EVENT LOG

In cây này ra và soi từng mẩu thông tin trong dự án của bạn — đó là bài tập đầu tiên khi thiết kế bất kỳ agent nào.

Tình huống 1: Bot đặt món ăn

• "Khách vừa nói thêm ít cay" (trong đơn đang gọi) → short-term.
• "Khách ăn chay, dị ứng đậu phộng" → key-value (nhớ qua phiên, có cấu trúc).
• "Menu và mô tả 300 món" → vector store + RAG (tra theo ý nghĩa: "món nào không cay?").
• "Giá món hôm nay, còn hàng không" → API realtime, không nhớ.

Tình huống 2: Trợ lý nội bộ tra cứu quy trình công ty

• 500 trang tài liệu quy trình → RAG là lựa chọn chính.
• "Phòng ban của nhân viên đang hỏi" → key-value (từ HR system).
• Lịch sử các câu đã hỏi trong buổi → short-term.
• Sai lầm điển hình: nhồi cả 500 trang vào context window của model cửa sổ lớn "cho tiện" — tốn khủng khiếp và "lost in the middle". RAG mới đúng.

Tình huống 3: Agent chăm sóc sức khỏe cá nhân

• Chỉ số đo hằng ngày → event log (chuỗi thời gian).
• Mục tiêu, bệnh nền → key-value.
• Kiến thức y khoa chung → RAG từ nguồn đã kiểm duyệt, ràng buộc "chỉ dùng ngữ cảnh".
• Cảnh báo: dữ liệu nhạy cảm phải cô lập theo user và có chính sách xóa.

Các bước áp dụng cho dự án của bạn

• Liệt kê mọi mẩu thông tin agent cần (Bài 1).
• Chạy từng mẩu qua cây quyết định ở trên.
• Với phần RAG, thiết kế chunking + metadata + top-K (Bài 4–5).
• Xác định thời điểm nạp mỗi loại vào prompt và thứ tự (Bài 6).
• Dựng log token + bộ test hồi quy trước khi lên production (Bài 7).
• Bắt đầu bằng phiên bản memory tối thiểu, chỉ thêm khi có bằng chứng agent "quên".

Checklist tốt nghiệp

• [ ] Mỗi thông tin đã đi qua cây quyết định và có store rõ ràng?
• [ ] Không nhớ thứ đáng lẽ tra realtime?
• [ ] Không dùng vector store cho dữ liệu có cấu trúc?
• [ ] Prompt có thứ tự và ngân sách token rõ ràng?
• [ ] Có ràng buộc "chỉ dùng ngữ cảnh / được nói không biết" trong RAG?
• [ ] Có test hồi quy + log chi phí trước khi phát hành?
• [ ] Có cơ chế cập nhật/xóa và cô lập dữ liệu theo user?

Sai lầm thường gặp

• Chọn công nghệ trước, nhu cầu sau. "Dự án nào cũng phải có vector database" là tư duy ngược — hãy để cây quyết định dẫn dắt.
• Over-engineer từ ngày đầu. Dựng 4 loại store cho một bot chỉ cần nhớ 5 lượt hội thoại.
• Under-engineer khi thật sự cần. Nhồi cả kho tài liệu vào prompt thay vì RAG, rồi than đắt và chậm.
• Nhớ dữ liệu nhạy cảm/realtime. Vừa sai vừa rủi ro pháp lý.
• Không đo, không dọn. Không có test và không cập nhật khiến chất lượng âm thầm xuống cấp.

Tổng kết khóa học

Bộ nhớ cho AI Agent không phải một công nghệ đơn lẻ mà là nghệ thuật chọn đúng loại lưu trữ cho đúng loại thông tin, và nạp nó vào prompt đúng lúc. Nắm cây quyết định, tôn trọng ngân sách token, đo lường bằng số, và bắt đầu tối giản — bạn đã có đủ để xây agent "nhớ được" chạy thật.