Vector RAG nhớ văn bản, không nhớ quyết định: trí nhớ mới cho AI agent

Tháng trước, một đội kỹ thuật đảo ngược một quyết định về hàng đợi (queue). Không ai còn nhớ vì sao thiết kế đầu tiên được chọn, nó dựa trên bằng chứng nào, và ai đã phê duyệt thiết kế thay thế. Thiết kế cũ vẫn được giữ lại nửa vời như một "phương án dự phòng", âm thầm phụ thuộc vào chính thứ vừa bị thay thế. Họ phát hiện ra trong môi trường production.

Câu chuyện này, do tác giả techdevfun kể trên DEV tuần này, không phải chuyện hiếm. Nó là chuyện thường ngày của các đội xây dựng hệ thống có AI agent tham gia ra quyết định. Và điểm mấu chốt của câu chuyện nằm ở một phân biệt mà hầu hết kiến trúc agent hiện nay bỏ qua: nhớ văn bản không phải là nhớ quyết định.

Vì sao vector RAG không đủ cho trí nhớ của agent

Vector RAG trả lời tốt câu hỏi "đoạn văn nào nói về X". Nhưng quyết định kỹ thuật không phải là đoạn văn. Một quyết định gồm bốn thứ mà RAG không lưu:

• Cái gì đã được chọn, và cái gì đã bị loại.
• Quyết định dựa trên bằng chứng nào.
• Cái gì mâu thuẫn với nó.
• Cái gì đã thay thế nó, khi nào và vì sao.

Tác giả gọi đây là lỗ hổng cấu trúc: RAG nhớ text, không nhớ decision. Khi một agent dựa vào RAG để tra cứu bối cảnh cũ, nó sẽ tìm thấy tài liệu về thiết kế cũ lẫn thiết kế mới, nhưng không có cách nào biết thiết kế nào đang còn hiệu lực và mối quan hệ giữa chúng. Kết quả là agent đưa ra đề xuất dựa trên quyết định đã bị thay thế từ lâu, và không ai phát hiện cho tới khi hệ thống gặp sự cố.

memgraph: một đồ thị quyết định nhỏ, chạy trong CI

Để lấp lỗ hổng đó, tác giả xây memgraph, một công cụ dòng lệnh Node.js không phụ thuộc thư viện ngoài. Toàn bộ kho lưu trữ là một tệp JSON duy nhất, có thể commit cùng mã nguồn. Mỗi quyết định, dữ kiện và ràng buộc là một nút có nguồn gốc rõ ràng, liên kết với nhau bằng bốn quan hệ: hỗ trợ (supports), mâu thuẫn (contradicts), thay thế (supersedes) và phụ thuộc (depends-on).

memgraph init
memgraph add --type decision --title "Use Postgres LISTEN/NOTIFY for the queue" --source "ADR-014"
memgraph add --type fact --title "NOTIFY payloads cap at 8000 bytes" --source "Postgres docs"
memgraph link m-002 m-001 --relation contradicts
memgraph add --type decision --title "Switch the queue to Redis Streams" --source "ADR-019"
memgraph supersede m-001 m-003 --reason "payload cap makes NOTIFY the wrong tool"

Ba câu hỏi công cụ trả lời nhanh: vì sao quyết định này tồn tại (memgraph why), có gì mâu thuẫn hoặc lỗi thời không (memgraph check), và hiện tại đội tin vào điều gì (memgraph list).

Điểm đáng chú ý nhất về mặt kiến trúc nằm ở memgraph check: lệnh này thoát với mã lỗi 1 khi phát hiện mâu thuẫn chưa giải quyết, nút đang hoạt động phụ thuộc vào quyết định đã bị thay thế, hoặc khẳng định không có nguồn. Nghĩa là đồ thị quyết định trở thành một cổng kiểm tra trong CI: pull request nào tạo ra mâu thuẫn hoặc tiếp tục phụ thuộc vào quyết định đã chết sẽ bị chặn trước khi merge. Trí nhớ quyết định, thay vì nằm im trong tài liệu, trở thành một kiểm tra tự động.

Chính tác giả cũng ghi một lưu ý trung thực: đồ thị chỉ tốt bằng những gì được ghi vào. Công cụ không biết nguồn có đúng hay không; nó chỉ cho biết mọi khẳng định đến từ đâu và đồ thị còn nhất quán hay không. Quyết định không nguồn gốc bị đánh dấu như tin đồn có định dạng. Và khi quyết định thay đổi, phải đánh dấu thay thế bằng supersede, không được xóa: xóa lịch sử là cách các đội tranh cãi lại cùng một lựa chọn mỗi sáu tháng.

Phân tích: ba tầng trí nhớ mà một agent cần

Điểm có giá trị nhất của cách tiếp cận này không phải bản thân công cụ, mà là mô hình trí nhớ ba tầng mà nó gợi ý cho kiến trúc agent:

1. Trí nhớ ngữ nghĩa — kho vector, RAG, tài liệu. Trả lời "cái gì đã được viết về X".
2. Trí nhớ quyết định — đồ thị có nguồn gốc như memgraph. Trả lời "cái gì đang còn hiệu lực, vì sao, và cái gì đã thay thế cái gì".
3. Trí nhớ ngữ cảnh làm việc — cửa sổ hội thoại hiện tại của agent.

Hầu hết đội xây agent hiện nay đầu tư nặng vào tầng 1 và tầng 3, bỏ trống tầng 2. Hệ quả là agent "biết rất nhiều" nhưng "không nhớ mình đã quyết gì". Khi cần ra quyết định nhất quán với quá khứ, agent truy hồi tài liệu rồi suy luận lại từ đầu, với đầy đủ rủi ro của suy luận không có ràng buộc.

Một cách nhìn khác: memgraph thực chất là ADR (Architecture Decision Record) được máy đọc được. ADR truyền thống ghi quyết định vào tài liệu markdown, tốt cho con người đọc nhưng vô hình với pipeline. Biến ADR thành đồ thị có quan hệ và kiểm tra tự động nghĩa là quyết định kiến trúc trở thành một phần của hệ thống build, giống như test. Đây là hướng đi đáng thử cho bất kỳ đội nào đang cho agent quyền đề xuất thay đổi kiến trúc: trước khi tin agent, hãy cho agent một nơi để tra cứu xem đội đã quyết gì, và một cổng kiểm tra để ngăn agent đề xuất thứ đội đã bác bỏ.

Câu hỏi mở cho người xây agent: trong hệ thống của bạn, quyết định gần nhất bị đảo ngược là gì, và hôm nay bạn có thể truy ra "vì sao" trong bao nhiêu giây?

Nguồn tham khảo

• techdevfun, "Your agent forgot a decision you made last week. Mine did too.", DEV Community, 22/10/2026 — https://dev.to/techdevfun/your-agent-forgot-a-decision-you-made-last-week-mine-did-too-1ba9
• techdevfun/memgraph, repository GitHub (MIT), tạo 19/10/2026 — https://github.com/techdevfun/memgraph