Bài 1 — Vì sao AI Agent cần bộ nhớ, và bộ nhớ thật sự là gì

Vấn đề: LLM vốn dĩ "không nhớ gì"

Một lời gọi tới LLM (ví dụ Claude, GPT) về bản chất là stateless — không trạng thái. Mỗi request là một tờ giấy trắng. Model chỉ "biết" đúng những gì bạn nhét vào prompt của request đó. Khi bạn thấy ChatGPT "nhớ" câu hỏi trước, thực chất ứng dụng đã âm thầm gửi lại toàn bộ đoạn hội thoại cũ trong mỗi lượt.

Hãy hình dung một chatbot chăm sóc khách hàng. Lượt 1 khách nói: "Đơn hàng của tôi là VN-8842." Lượt 2 khách hỏi: "Bao giờ giao?" Nếu bạn chỉ gửi câu lượt 2 tới LLM, nó không hề biết "đơn nào". Agent cần bộ nhớ để nối hai lượt lại.

Bộ nhớ trong ngữ cảnh AI Agent là gì

"Bộ nhớ" (memory) là cơ chế đưa thông tin quá khứ vào prompt hiện tại một cách có chọn lọc. Nó không phải phép màu — cuối cùng mọi thứ đều quy về việc: token nào được đưa vào context window của lần gọi model này?

Có hai loại lớn bạn sẽ gặp suốt khóa học:

• Short-term memory (bộ nhớ ngắn hạn): ngữ cảnh của phiên làm việc hiện tại — lịch sử hội thoại, kết quả tool vừa gọi. Sống trong context window, mất khi phiên kết thúc.
• Long-term memory (bộ nhớ dài hạn): thông tin cần nhớ qua nhiều phiên, nhiều ngày — hồ sơ người dùng, tài liệu công ty, các sự kiện đã xảy ra. Được lưu ra ngoài (database, vector store) và nạp lại khi cần.

Ví dụ cụ thể: trợ lý đặt lịch

Bạn xây một agent đặt lịch họp. Nó cần:

• Nhớ trong phiên: "người dùng vừa nói muốn họp chiều thứ Năm" → short-term.
• Nhớ qua các phiên: "người dùng này luôn thích họp buổi sáng, múi giờ +7" → long-term.

Hai nhu cầu này có kiến trúc hoàn toàn khác nhau, và nhầm lẫn chúng là sai lầm phổ biến nhất của người mới.

Khung tư duy: 3 câu hỏi trước khi thêm memory

Trước khi viết một dòng code memory, hãy tự trả lời:

• Thông tin này cần sống bao lâu? (một lượt / một phiên / mãi mãi)
• Ai/cái gì cần truy xuất nó? (chỉ phiên này / mọi phiên của user này / mọi user)
• Truy xuất theo cách nào? (đọc nguyên văn tuần tự / tìm theo ngữ nghĩa / tra theo khóa)

Câu trả lời sẽ quyết định bạn dùng list trong RAM, database khóa-giá trị, hay vector store.

Các bước tư duy khi bắt đầu một dự án agent

• Liệt kê các "mẩu thông tin" agent cần biết để làm đúng việc.
• Gắn nhãn mỗi mẩu là short-term hay long-term.
• Với mỗi mẩu long-term, xác định cách truy xuất (theo khóa hay theo ngữ nghĩa).
• Chỉ triển khai memory tối thiểu đủ dùng — đừng dựng vector store khi một biến session là đủ.
• Đo lại: agent có trả lời sai vì "quên" không? Nếu không, bạn đã đủ.

Một mô hình tinh thần đơn giản

[Người dùng] --câu hỏi--> [Agent]
                             |
            +----------------+----------------+
            |                                 |
    Short-term (RAM/session)        Long-term (DB/vector store)
    lịch sử hội thoại               hồ sơ, tài liệu, sự kiện cũ
            |                                 |
            +----------------+----------------+
                             |
                    Ghép vào PROMPT --> [LLM] --> câu trả lời

Mọi kỹ thuật memory phức tạp (RAG, summarization, vector search) đều chỉ là các cách khác nhau để quyết định nhét gì vào ô "PROMPT" đó.

Sai lầm thường gặp

• Tưởng LLM tự nhớ. Model không có trí nhớ giữa các request; nếu không gửi lại, coi như chưa từng nói.
• Nhét toàn bộ lịch sử vào mọi request "cho chắc". Vừa tốn tiền (tính theo token), vừa dễ tràn context window, vừa làm model bị nhiễu.
• Dựng hạ tầng nặng quá sớm. Cài vector database cho một chatbot chỉ cần nhớ 3 lượt hội thoại là lãng phí thời gian.
• Không phân biệt short-term và long-term. Dẫn tới thiết kế sai: lưu hồ sơ user vào biến session (mất khi restart), hoặc nhồi cả cuộc chat vào database dài hạn.

Tổng kết

Bộ nhớ = kỹ thuật chọn lọc thông tin quá khứ đưa vào prompt. Hai trục chính là short-term và long-term. Từ bài sau, ta sẽ đi sâu từng loại và tự dựng chúng.