Tại sao AI cứ "quên" những gì bạn nói và cách fix

Bạn đang chat với AI, giải thích dài dòng về project, đưa ra cả đống context, rồi đến câu thứ 20 thì nó... quên sạch. Hỏi lại từ đầu như chưa từng nói chuyện. Quen không?

Đây không phải bug. Đây là cách mà Large Language Models (LLMs) hoạt động và nếu bạn đang build ứng dụng AI, hiểu rõ vấn đề này sẽ giúp bạn tránh được rất nhiều đau đầu.

AWS vừa publish một bài khá chi tiết trên Dev.to giải thích chuyện này, và mình thấy đây là kiến thức nền tảng mà bất kỳ developer nào làm việc với AI đều cần nắm.

AI không "nhớ" nó chỉ đọc lại

Điều đầu tiên cần hiểu: LLM không có memory theo nghĩa truyền thống. Mỗi lần bạn gửi một message, toàn bộ cuộc hội thoại trước đó được gom lại, nhét vào cùng với câu hỏi mới, rồi gửi đi như một cục text duy nhất. Model đọc từ đầu đến cuối rồi generate response.

Nghe đơn giản, nhưng vấn đề nằm ở chỗ: cục text đó có giới hạn. Người ta gọi nó là context window.

Mỗi model có một context window khác nhau:

Khi cuộc hội thoại vượt quá context window, những message cũ nhất bị cắt bỏ. Model literally không thấy chúng nữa. Nó không "quên" nó chưa bao giờ "nhớ" cả.

Model	Context Window	Tương đương
GPT-3.5	4K tokens	~3,000 từ
GPT-4	8K-128K tokens	~6,000-96,000 từ
Claude 3.5 Sonnet	200K tokens	~150,000 từ
Gemini 1.5 Pro	1M tokens	~750,000 từ

Theo kinh nghiệm của mình, đây là lý do phổ biến nhất khiến chatbot trong production hoạt động tệ sau vài lượt trao đổi. Bạn test với 3-4 câu thì ngon, nhưng user thực tế chat 20-30 câu thì mọi thứ bắt đầu vỡ.

Context window lớn hơn có phải là giải pháp?

Nhiều người nghĩ: "Ơ thì dùng model có context window lớn là xong." Gemini cho tới 1 triệu tokens cơ mà.

Không đơn giản vậy. Có mấy vấn đề thực tế:

Chi phí tăng tuyến tính. Bạn gửi càng nhiều tokens, bạn trả càng nhiều tiền. Một cuộc hội thoại dài với context 100K tokens sẽ tốn gấp 25 lần so với 4K tokens. Nhân lên với hàng nghìn users, bill cuối tháng sẽ rất đáng sợ.

Latency tăng. Context càng lớn, model xử lý càng lâu. User không muốn đợi 10-15 giây cho mỗi response.

"Lost in the middle" problem. Research đã chỉ ra rằng LLMs có xu hướng chú ý tốt vào đầu và cuối context, nhưng thông tin ở giữa thường bị "bỏ qua". Context window lớn không có nghĩa là model sẽ tận dụng hết.

Các cách fix thực tế

Đây mới là phần quan trọng. Có nhiều strategy để xử lý, và tùy use case mà bạn chọn cách nào.

Sliding Window (Cửa sổ trượt)

Cách đơn giản nhất: chỉ giữ N message gần nhất. Message cũ bị loại bỏ. Dễ implement, nhưng nhược điểm là context quan trọng từ đầu cuộc hội thoại sẽ bị mất.

Summarization (Tóm tắt)

Thay vì giữ nguyên toàn bộ history, bạn dùng chính LLM để tóm tắt cuộc hội thoại cũ thành một đoạn ngắn, rồi đính kèm đoạn summary đó vào context. Cách này giữ được thông tin quan trọng mà không tốn quá nhiều tokens.

Điều mình thấy hay là bạn có thể kết hợp: giữ 5-10 message gần nhất ở dạng nguyên bản, còn phần trước đó thì summarize. Như vậy vừa có chi tiết gần, vừa có overview xa.

RAG (Retrieval-Augmented Generation)

Đây là approach mạnh nhất cho các ứng dụng phức tạp. Thay vì nhét mọi thứ vào context, bạn lưu thông tin vào một vector database. Khi user hỏi, bạn search trong database để tìm những đoạn thông tin liên quan nhất, rồi chỉ đưa những đoạn đó vào context.

RAG đặc biệt hữu ích khi bạn cần AI "nhớ" thông tin từ nhiều cuộc hội thoại khác nhau, hoặc từ documents bên ngoài.

Memory Layer

Một số framework như LangChain, LlamaIndex cung cấp memory modules cho phép bạn lưu trữ thông tin quan trọng (tên user, preferences, facts đã nói) vào một store riêng. Mỗi lần gọi LLM, bạn inject những facts này vào system prompt.

So sánh các approach:

Approach	Độ phức tạp	Chi phí	Phù hợp với
Sliding Window	Thấp	Thấp	Chatbot đơn giản, Q&A
Summarization	Trung bình	Trung bình	Cuộc hội thoại dài, support bot
RAG	Cao	Cao hơn (cần vector DB)	Knowledge base, enterprise app
Memory Layer	Trung bình	Thấp-Trung bình	Personalization, assistant dài hạn

Thực tế khi build production app

Theo kinh nghiệm của mình sau vài dự án AI, có mấy điều đáng lưu ý:

Đừng over-engineer từ đầu. Nếu app của bạn chỉ cần 5-10 lượt trao đổi, sliding window là quá đủ. Đừng vội nhảy vào RAG khi chưa cần.

Monitor token usage. Đặt alert cho token consumption. Mình từng thấy một con chatbot internal tốn gấp 10 lần dự kiến vì không ai để ý cuộc hội thoại dài bao nhiêu.

Test với cuộc hội thoại thực tế. Đừng chỉ test với 3 câu hỏi demo. Lấy conversation logs thật (hoặc simulate) với 30-50 lượt trao đổi để xem model behave thế nào khi context bị cắt.

System prompt là vàng. Thông tin quan trọng nhất nên nằm trong system prompt phần này luôn được giữ lại, không bị sliding window cắt mất.

Ai bị ảnh hưởng và nên làm gì tiếp?

Nếu bạn đang build bất kỳ ứng dụng nào dùng LLM từ chatbot nội bộ, customer support, đến AI coding assistant thì đây là kiến thức bắt buộc phải có.

Cộng đồng đang move rất nhanh về phía memory management cho AI. OpenAI đã thêm memory feature cho ChatGPT. Google đang push context window lên hàng triệu tokens. Các framework như LangChain, LlamaIndex liên tục cải thiện memory modules.

Nhưng core concept vẫn không đổi: LLM là stateless. Mọi "memory" đều là do developer engineer ra.

Điều mình muốn nhấn mạnh: hiểu rõ limitation này không phải để bi quan, mà để build tốt hơn. Khi bạn biết AI không nhớ gì, bạn sẽ design system để bù đắp đúng chỗ và đó chính là skill phân biệt một AI app chạy demo với một AI app chạy production.

Nếu bạn muốn đọc chi tiết hơn, bài gốc trên Dev.to của AWS giải thích khá kỹ với code examples. Link mình để ở đầu bài. Happy building! 🚀