Memory trong AI Agent: Vì sao Context Window không bao giờ là đủ?

Trả lời nhanh: Context window (cửa sổ ngữ cảnh) là lượng token model được nhìn thấy trong một lần gọi, và giữa hai lần gọi thì model không tự giữ lại gì. Memory (bộ nhớ) là phần hệ thống quyết định lưu thông tin nào, lấy lại lúc nào, cho ai xem và giữ bao lâu, ở một chỗ nằm ngoài cửa sổ đó. Nới cửa sổ rộng thêm chỉ giúp model đọc nhiều hơn trong một lượt, chứ không tạo ra chỗ lưu nào. Vì vậy một AI Agent, tức chương trình dùng model để tự chọn bước và gọi tool hướng tới một mục tiêu, cần cả hai thứ.

Context window giống như mặt bàn làm việc: rộng đến đâu thì bày được nhiều giấy tờ đến đó, nhưng hết giờ làm là dọn sạch. Memory lại giống tủ hồ sơ: cất giữ qua đêm, qua tuần, và quan trọng nhất là biết rút đúng tập hồ sơ khi cần. Hai thứ này khác nhau về bản chất, nhưng đang bị gọi chung bằng một chữ “nhớ”.

Sự nhầm lẫn đó có giá của nó. Ví dụ một đội xây chatbot chăm sóc khách hàng cứ nghĩ nâng model lên cửa sổ to hơn là bot sẽ nhớ khách lâu hơn, rồi ngạc nhiên khi khách quay lại sau hai ngày và bot hỏi lại từ đầu. Vấn đề không nằm ở model, mà ở chỗ hệ thống chưa có cái tủ hồ sơ.

Trong bài viết này, mình sẽ giải thích vì sao mặt bàn to đến mấy cũng không thay được tủ hồ sơ. Mình sẽ viết về những lớp của một hệ thống memory thật sự, và cách bạn tự nhận ra chatbot đang hụt ở lớp nào, bằng ngôn ngữ dễ hiểu để bạn dễ hình dung. Cùng mình tìm hiểu ngay nhé!

Context window khác memory ở chỗ nào?

Khác ở chỗ một cái là phạm vi nhìn, cái kia là một chuỗi quyết định. Context window là số token gửi vào một lần suy luận của LLM (Large Language Model), và Machine Learning Mastery mô tả gọn phần còn lại: model không giữ state giữa các lần gọi API (Application Programming Interface), mỗi lần gọi là một lần bắt đầu lại từ đầu. Memory là bốn quyết định của hệ thống quanh model, lưu gì, lấy lại lúc nào, ai được thấy, giữ bao lâu.

Đó cũng là lý do hình dung bàn làm việc và tủ hồ sơ hữu ích. Bàn là cửa sổ: rộng bao nhiêu thì đặt được bấy nhiêu giấy cho một lượt, cuối lượt dọn sạch. Tủ là memory: giấy nằm đó qua nhiều ngày, có người quyết định hồ sơ nào đáng cất, ai được mở, bao lâu thì hủy. Bàn to gấp mười vẫn không thay được cái tủ.

Có một điểm dễ nhầm theo hướng ngược lại. Letta viết rằng thứ agent nhớ ở bất kỳ thời điểm nào chính là thứ đang nằm trong context window, nên thiết kế memory thực chất là context engineering (kỹ thuật chọn thông tin model được nhìn thấy). Hai câu đó không chọi nhau: kho nằm ngoài cửa sổ, nhưng mảnh thông tin phải được kéo trở lại vào cửa sổ ở đúng lượt cần.

Khách thường không hỏi lại từ đầu, vì họ tưởng hệ thống đã giữ những gì họ từng nói. Ví dụ chatbot hỗ trợ đơn hàng: Thứ Hai khách nhắn đã mua áo xanh, size M, giao về Hà Nội; Thứ Tư khách quay lại và hỏi đơn tới đâu rồi. Áo xanh, size M, Hà Nội là thứ đáng cất vào tủ vì Thứ Tư còn dùng tới, còn mấy dòng chào hỏi thì không. Hệ thống chỉ có cửa sổ thì giữ cả hai như nhau, rồi mất cả hai như nhau.

Vì sao cửa sổ lớn hơn vẫn không thành memory?

Ba mục dưới đây là ba kiểu hỏng khi lấy cửa sổ làm chỗ nhớ, xếp theo mức khó chịu tăng dần: mất trắng khi hết phiên, còn thông tin nhưng đắt và dễ đọc sót, và không có ai quyết định lưu hay xóa. Ba kiểu độc lập với nhau, nên vá được một cái vẫn không khỏi hai cái kia.

Nó biến mất khi phiên kết thúc

Vì model không giữ state giữa các lần gọi, mọi thứ nó tỏ ra là nhớ đều đến từ phần văn bản ứng dụng vừa nhét vào lượt này. Hết phiên, không ai chép lại thì không còn gì.

Tài liệu LangChain tách đúng ranh giới này: short-term memory (bộ nhớ ngắn hạn) là lịch sử tin nhắn trong phạm vi một luồng hội thoại, nằm trong state của agent; long-term memory (bộ nhớ dài hạn) là thứ đi xuyên nhiều luồng. Trong ví dụ chatbot hỗ trợ đơn hàng, Thứ Hai và Thứ Tư là hai luồng khác nhau, nên bộ nhớ ngắn hạn dù đầy đủ tới đâu cũng không bắc được cầu.

Nó đắt và dễ bỏ sót chỗ giữa

Giả sử bạn chấp nhận trả tiền và cứ nhét lại toàn bộ hội thoại mỗi lượt. Vấn đề là dài hơn không đồng nghĩa nhớ tốt hơn. Ngày 29/9/2025, Anthropic viết trong bài về context engineering rằng context là tài nguyên hữu hạn và có điểm lợi suất giảm dần, kèm hiện tượng họ gọi là context rot (độ chính xác giảm khi context dài ra): token càng tăng thì khả năng nhớ chính xác càng giảm.

Phần này đã được đo trước đó. Bài Lost in the Middle của Liu và cộng sự thử hai loại tác vụ, hỏi đáp trên nhiều tài liệu và tra cứu theo cặp khóa với giá trị: kết quả cao nhất khi thông tin cần dùng nằm ở đầu hoặc cuối đoạn context, còn nằm giữa thì tệ đi rõ rệt. Đó là lost in the middle (hiện tượng model bỏ sót thông tin nằm giữa đoạn context dài), và nó không tha cả model được quảng cáo là xử lý được context dài. LangChain nói cùng ý ở góc thực dụng: hội thoại dài có thể không vừa cửa sổ, mà vừa rồi thì model vẫn dễ phân tán, chậm hơn và tốn hơn.

Có một con số đáng nhìn, kèm điều kiện của nó. Bài báo Mem0 của Chhikara và cộng sự chạy trên LOCOMO (bộ dữ liệu hội thoại dài của Maharana và cộng sự, 2024) gồm 10 hội thoại, trung bình khoảng 600 lượt đối thoại và khoảng 26.000 token. Cách nhét cả hội thoại vào cửa sổ đạt điểm J, một cách đo độ đúng của câu trả lời trong bài đó, khoảng 73%, cao hơn Mem0 ở khoảng 67% và Mem0g ở 68,44%.

Độ trễ p95 của cách nhét hết là khoảng 17 giây, còn Mem0 khoảng 1,44 giây, thấp hơn chừng 91–92%, với lượng token đưa vào chỉ khoảng 7.000. Đây là đánh đổi chi phí và thời gian chờ trên một bộ bài kiểm tra cụ thể, không phải kết luận rằng memory trả lời đúng hơn cả hội thoại.

Nó không biết lưu gì, xóa gì, cho ai

Kiểu hỏng thứ ba khó thấy nhất, vì nó không báo lỗi. Một cửa sổ ngữ cảnh không có quyền truy cập, không có thời hạn lưu, không có nút xóa theo yêu cầu của khách. Khi khách nhờ xóa số điện thoại đã cung cấp, bạn không có chỗ nào để xóa, cũng không có chỗ nào để chứng minh là đã xóa.

Đó là lý do hướng dẫn kiến trúc của Microsoft khuyến nghị đưa state dùng chung ra một kho bền vững bên ngoài với tác vụ chạy dài hoặc kéo qua nhiều lượt: tiến độ công việc, kết quả trung gian và lịch sử hội thoại nằm ở đó, đồng thời giới hạn phần được lưu ở mức tối thiểu cần thiết. Chữ tối thiểu quan trọng ngang chữ bền vững, vì lưu tất cả cho chắc là cách nhanh nhất để có một kho không ai dám dùng.

Agent thực sự nhớ bằng những lớp nào?

Cách chia dễ hình dung nhất là theo thời gian sống của thông tin: sống trong một lần chạy, sống trong một phiên, hay sống qua nhiều phiên. Chia theo tên sản phẩm sẽ rối ngay khi bạn đổi nhà cung cấp. Ba lớp dưới đây đều nằm ngoài cửa sổ và đều phải được kéo vào cửa sổ khi cần dùng.

State của lần chạy

Đây là phần ghi tiến độ của một nhiệm vụ đang chạy: đã tra được mã đơn, đã gọi tool kiểm tra vận chuyển, đang chờ người duyệt. Nó sinh ra khi lần chạy bắt đầu và hết việc khi lần chạy kết thúc. Microsoft xếp đúng những thứ này vào kho bền vững bên ngoài để tác vụ dài không chết theo tiến trình. Muốn xem một lần chạy theo từng nhịp, bài Agent Loop là gì đi hết vòng đó.

Lịch sử phiên

Đây là những gì khách đã nói trong phiên làm việc này, tức phần LangChain gọi là bộ nhớ ngắn hạn trong phạm vi một luồng. Nó đủ để agent không hỏi lại size ba lần trong cùng một buổi chat. Trong ví dụ đơn hàng, lớp này không đủ cho Thứ Tư, vì phiên mới là một luồng mới. Lớp này cũng có giới hạn riêng: hội thoại dài lên là vướng đúng hai vấn đề ở mục trước, hóa đơn token và phần giữa bị đọc sót.

Memory dài hạn

Đây là lớp làm được việc mà hai lớp trên không làm, giữ thông tin qua nhiều phiên. LangChain xếp vào đây các dữ kiện, các lần đã trải qua và cả những chỉ dẫn về cách làm. Trong ví dụ đơn hàng, áo xanh size M giao Hà Nội là dữ kiện, và nó là thứ khiến câu hỏi hôm Thứ Tư trả lời được. Lớp này bắt buộc đi kèm phạm vi truy cập và thời hạn, không phải vì thủ tục mà vì nó chứa dữ liệu thật của người thật. Đây cũng là lớp mà harness, tức lớp điều khiển hành vi agent, phải vận hành: quyết định ghi, quyết định lấy, quyết định xóa.

Một chỗ cần tách cho rõ: RAG (Retrieval-Augmented Generation) trên tài liệu nội bộ không phải memory của khách. RAG đi tìm tri thức có sẵn ở đâu đó, ví dụ chính sách đổi trả, còn memory phải giữ trạng thái sinh ra từ tương tác, ví dụ khách này vừa đổi địa chỉ giao hàng. Letta nói gọn hơn mình: RAG là một tool phục vụ memory, không phải bản thân memory.

Thông tin nhớ được lấy lại vào context window thế nào?

Hai mục dưới đây là hai chiều của cùng một hệ thống, không phải hai sản phẩm: chiều ghi quyết định cái gì rời cửa sổ để vào kho, chiều lấy quyết định cái gì từ kho quay lại cửa sổ cho lượt này. Sai chiều ghi thì kho rỗng hoặc kho rác. Sai chiều lấy thì kho đầy mà model vẫn trả lời như chưa gặp bạn bao giờ.

Ghi nhớ: chọn cái gì đáng lưu

Cơ chế phổ biến nhất đơn giản đến mức dễ coi thường: cho agent ghi chú lại. Anthropic gọi cách này là ghi chú có cấu trúc, agent viết ghi chú ra một chỗ nằm ngoài context window rồi kéo về khi cần, nên nội dung không mất khi cửa sổ bị dọn.

Khi hội thoại gần đầy cửa sổ, còn một nước nữa là compaction (nén ngữ cảnh): tóm tắt phần đã diễn ra rồi bắt đầu lại với bản tóm tắt thay cho toàn bộ chi tiết. Tóm tắt luôn là một lần đánh cược, vì thứ bị lược đi có thể là thứ mai cần. Nên những mảnh phải giữ nguyên văn, mã đơn, size, địa chỉ, thường được ghi thành ghi chú riêng chứ không phó cho bản tóm tắt. Cuốn sổ đó hay được gọi là scratchpad (sổ ghi chú tạm), nhưng cái tên không quan trọng bằng chỗ nó nằm.

Lấy lại: nhét đúng mảnh vào lần gọi này

Chiều lấy chính là truy xuất (retrieval): tìm trong kho ra mảnh liên quan tới câu vừa hỏi rồi đặt vào cửa sổ trước khi gọi model. Anthropic đặt nguyên tắc chọn khá dứt khoát, tìm tập token nhỏ nhất mà vẫn nhiều tín hiệu nhất, chứ không phải nhồi càng nhiều càng an tâm. Cùng bài đó mô tả kiểu lấy just-in-time: hệ thống chỉ giữ những định danh nhẹ, ví dụ mã đơn, rồi dùng tool nạp dữ liệu thật vào đúng lúc cần.

Hình dung kho đã giữ sẵn vài mảnh từ lần chat trước, còn lượt này khách chỉ hỏi một câu ngắn. Ví dụ chatbot hỗ trợ đơn hàng: Thứ Tư khách hỏi đơn tới đâu, hệ thống tra ra khách này, lấy từ kho mã đơn cùng ba mảnh đã ghi, gọi tool kiểm tra trạng thái vận chuyển, rồi nhét đúng chỗ đó vào cửa sổ của lượt này. Model đọc một trang gọn thay vì cả tập hội thoại. Kho lưu và quy tắc lấy đều nằm ở lớp hệ thống, không nằm trong model, nên đổi sang model thông minh hơn thì phần này vẫn phải có người dựng.

Những nhầm lẫn thường gặp khi nghe AI nhớ bạn

Ba mục dưới đây là ba thứ hay bị đánh đồng với memory, và cả ba đều nghe rất thuyết phục cho tới lúc hệ thống chạy thật. Mình xếp theo thứ tự bạn sẽ gặp trên trang giới thiệu sản phẩm.

Cửa sổ dài hơn nghĩa là đã có memory

Không. Cửa sổ dài hơn nghĩa là một lượt đọc được nhiều hơn, chưa nói gì tới chuyện có chỗ lưu hay không, và model vẫn không giữ state giữa các lần gọi nên hết phiên vẫn là hết. Phần dài ra cũng không miễn phí về chất lượng, đúng như Anthropic mô tả với context rot và Liu mô tả với phần giữa bị đọc sót. Con số token trên trang giới thiệu vì vậy trả lời một câu khác: model nhìn được bao nhiêu trong một lượt, không phải hệ thống lưu lại gì cho lượt sau.

Nhét hết lịch sử hoặc nhét hết kho dữ liệu là memory

Đây là cách làm được, và với việc nhỏ còn hợp lý. Nhưng nó không phải một thiết kế memory, nó là quyết định không chọn gì cả. Bài báo Mem0 cho thấy giá của việc không chọn, độ trễ p95 khoảng 17 giây so với khoảng 1,44 giây trên cùng bộ dữ liệu đã dẫn ở trên. Chiều ngược lại sai theo kiểu tương tự, đổ cả kho dữ liệu vào cửa sổ cho chắc ăn, trong khi nguyên tắc của Anthropic đi ngược hẳn: tập token nhỏ nhất mà nhiều tín hiệu nhất.

RAG tài liệu nội bộ chính là memory khách hàng

Không, và đây là chỗ nhầm tốn tiền nhất, vì hai thứ này thường được bán chung một gói. RAG trả lời câu hỏi về tri thức có sẵn ở đâu đó, ví dụ chính sách đổi trả trong tài liệu nội bộ. Memory trả lời câu hỏi về trạng thái sinh ra từ tương tác.

Quay lại ví dụ chatbot hỗ trợ đơn hàng: khách này đã mua gì hôm Thứ Hai là memory, không phải tài liệu nội bộ. Cách kiểm tra nhanh: hỏi hệ thống một câu chỉ có bạn với nó biết từ lần trước. Nếu nó trôi chảy về chính sách nhưng ngơ ngác về bạn, phần bạn đang mua là truy xuất tài liệu. Bài RAG có đủ cho AI Agent không tách tiếp ba việc hay bị bán chung: vector search, Knowledge và long-term memory.

Câu hỏi thường gặp

Năm câu dưới đây là các ranh giới còn sót lại sau thân bài, chỗ hai khái niệm gần nhau đến mức nhãn sản phẩm nào cũng dùng chung một từ. Mình trả lời theo cơ chế, không theo tên tính năng trên giao diện.

ChatGPT nhớ hội thoại thì đã là memory của agent chưa?

Đúng một phần. Việc chép thông tin lại để dùng cho phiên sau là một cơ chế memory thật. Nhưng memory chỉ là một trục của agent, và IBM lưu ý chatbot không agentic thường thiếu tool, memory hay suy luận, phục vụ mục tiêu ngắn và cần người dùng nhập tiếp ở từng lượt. Ranh giới đó mình tách thành ba trục ở bài AI Agent khác chatbot ở điểm nào.

Agent quên giữa chừng vì model kém?

Thường không phải. Hai nguyên nhân phổ biến hơn là không có kho lưu ngoài cửa sổ, và có lưu nhưng lấy lại sai mảnh. Kể cả với model xử lý context dài, Liu và cộng sự vẫn thấy kết quả giảm khi context dài ra và khi thông tin cần dùng nằm ở giữa, nên đổi sang model đắt hơn không vá được phần thiết kế còn thiếu.

Mọi AI Agent đều cần memory dài hạn?

Không. Việc gọn trong một lượt, không cần biết bạn là ai, thì thêm kho lưu chỉ thêm chỗ hỏng và thêm dữ liệu phải bảo vệ. Microsoft nêu nguyên tắc giới hạn phần state được lưu ở mức tối thiểu cần thiết, và mức tối thiểu đôi khi bằng không.

Memory có nghĩa model đã được huấn luyện lại?

Không. Hệ thống nhớ thêm không làm model giỏi thêm. IBM phân biệt rõ agent có thể nhớ và điều chỉnh dựa trên tương tác trước đó, nhưng model nền bên dưới không vì thế được huấn luyện lại. Thông tin nằm ở kho bên ngoài rồi được đưa vào cửa sổ khi cần, chứ không đi vào trọng số của model.

Bắt buộc phải có vector database mới gọi là memory?

Không. Vector database (cơ sở dữ liệu vector) là một cách lưu và tìm theo độ gần nghĩa, dựa trên embedding, tức cách biến đoạn văn thành dãy số để máy so độ gần nghĩa. Nó tiện khi bạn cần dò mảnh liên quan trong một khối văn bản lớn. Nhưng cách ghi chú ra file bên ngoài cửa sổ mà Anthropic mô tả cũng là memory, và với thông tin có cấu trúc rõ như mã đơn hay địa chỉ thì một bảng dữ liệu thường tra nhanh hơn.

Điều cần mang đi khi một sản phẩm nói nó nhớ bạn

Bốn câu hỏi dưới đây đủ để biết bên bán đang có memory thật hay chỉ có một cửa sổ rộng.

• Thông tin của tôi được lưu ở đâu sau khi phiên chat đóng lại?
• Hệ thống chọn lưu cái gì và bỏ cái gì, theo quy tắc nào?
• Ở lượt sau, nó lấy lại đúng mảnh nào, và ai quyết định mảnh đó?
• Ai được xem phần đã lưu, giữ trong bao lâu, và xóa bằng cách nào?

Nếu cả bốn câu trả lời đều xoay quanh con số token của cửa sổ, thứ bạn đang xem là một cửa sổ rộng, không phải memory. Cửa sổ rộng vẫn có giá trị thật, chỉ đừng giao cho nó phần việc bạn tưởng nó nhớ giúp.

Muốn đi tiếp, bài AI Agent khác chatbot ở điểm nào đặt memory cạnh hai trục còn lại là tool và quyền hành động. Chỗ memory được vận hành nằm trong bài Harness Engineering là gì, còn phần hạ tầng giữ state, quyền và truy vết nằm ở bài vì sao AI Agent cần một platform. Nếu bạn đang lẫn giữa state của một lần chạy và memory dài hạn, Agent Loop là gì tách hai thứ đó theo từng nhịp.