GraphRAG vs Obsidian: bộ nhớ AI Agent khác bộ não bạn

TL;DR: Obsidian là bộ nhớ được thiết kế cho tư duy con người — tuyến tính, gắn ngữ cảnh cá nhân, đọc bằng mắt. GraphRAG là bộ nhớ được thiết kế cho AI Agent — dữ liệu dạng đồ thị có Entity và Relationship tường minh, tối ưu cho truy xuất đa bước (multi-hop). Hai kiến trúc không thay thế nhau; SME chỉ nên đầu tư vào GraphRAG khi Vector RAG thông thường đã thật sự bó tay với các câu hỏi cần "nối" nhiều mảnh dữ kiện lại với nhau.

Tôi từng nghĩ nâng cấp bộ nhớ cho AI Agent chỉ là bài toán "nhét thêm tài liệu vào vector database". Cho đến khi build một hệ thống multi-agent phải trả lời những câu hỏi kiểu "chiến dịch content tháng trước có bài nào liên quan đến khách hàng đã từng phàn nàn về tốc độ phản hồi hồi tháng 3 không" — và Vector RAG truyền thống trả lời sai liên tục. Đây là lúc tôi buộc phải hiểu GraphRAG không phải một "tính năng nâng cấp" của RAG, mà là một triết lý lưu trữ tri thức khác hẳn với thứ tôi vẫn dùng mỗi ngày trong triết lý LLM-Wiki biến Obsidian thành IDE cho AI Agent. Bài này là phần đối chiếu kiến trúc: khi nào bộ não của bạn (Obsidian) đủ dùng, và khi nào hệ thống cần một bộ nhớ khác hẳn dành riêng cho AI Agent.

Obsidian và GraphRAG giải hai bài toán hoàn toàn khác nhau là gì?

Trả lời trực tiếp: Obsidian giải bài toán tư duy — giúp một con người ghi chép, liên kết và nhớ lại ý tưởng theo mạch cảm nhận cá nhân. GraphRAG giải bài toán truy xuất — giúp một AI Agent tìm đúng dữ kiện, đúng mối quan hệ giữa các dữ kiện, trong một tập dữ liệu quá lớn để nạp thẳng vào context window.

Nghe thì giống nhau vì cả hai đều dùng chữ "liên kết" (link), nhưng bản chất khác nhau ở đối tượng phục vụ:

• Obsidian tối ưu cho việc con người nhận diện mối liên hệ. Bạn gõ [[WikiLink]] vì bộ não bạn vừa nghĩ ra một kết nối — hành động liên kết là sản phẩm của tư duy, không phải kết quả của một quy trình tính toán.
• GraphRAG tối ưu cho việc máy suy luận mối liên hệ mà không cần con người gõ tay. Hệ thống tự trích xuất Entity (thực thể: người, dự án, khái niệm) và Relationship (quan hệ có kiểu rõ ràng, ví dụ PHỤ_TRÁCH, PHỤ_THUỘC_VÀO, MÂU_THUẪN_VỚI) từ văn bản thô, rồi lưu vào một cơ sở dữ liệu đồ thị để AI Agent truy vấn.

Nói cách khác: Obsidian là nơi bạn ghi lại điều bạn đã hiểu. GraphRAG là nơi AI Agent tự dựng lại cấu trúc quan hệ mà chính bạn có thể chưa từng gõ thành chữ.

Vì sao Vector RAG truyền thống thất bại khi AI Agent cần suy luận đa bước?

Trả lời trực tiếp: Vector RAG chỉ trả lời tốt câu hỏi "đoạn văn nào giống câu hỏi này nhất" — nó tìm theo độ tương đồng ngữ nghĩa (semantic similarity) trong một bước. Nó không có khái niệm "quan hệ", nên thất bại với các câu hỏi cần nối nhiều dữ kiện rời rạc qua nhiều bước (multi-hop reasoning) như "ai đang phụ trách dự án X, và dự án đó có phụ thuộc vào quyết định nào tôi đưa ra tháng trước không".

Cơ chế Vector RAG cơ bản: cắt tài liệu thành đoạn (chunk), nhúng (embed) mỗi đoạn thành một vector, rồi khi có câu hỏi, tìm những đoạn có vector gần nhất. Cơ chế này cực tốt cho câu hỏi dạng "tìm đoạn văn nói về Y" — nhưng vỡ trận ở ba tình huống phổ biến trong vận hành thực tế:

1. Câu hỏi cần tổng hợp trên diện rộng ("tổng kết toàn bộ các vấn đề khách hàng gặp phải trong quý"): không có một đoạn văn nào chứa "toàn bộ", nên Vector RAG chỉ trả về vài đoạn giống nhất — bỏ sót phần lớn.
2. Câu hỏi cần bắc cầu qua thực thể trung gian ("A liên quan gì đến C" khi A chỉ được nhắc cùng B, và B chỉ được nhắc cùng C): Vector RAG không có cơ chế "đi qua" B để tới C, vì nó không biểu diễn quan hệ, chỉ biểu diễn độ giống nhau.
3. Câu hỏi cần biết quan hệ có kiểu (ai phụ trách, cái gì phụ thuộc vào cái gì, đâu là quan hệ mâu thuẫn): vector embedding không phân biệt được "A phụ trách B" với "A từng nhắc đến B" — với nó cả hai chỉ là hai đoạn văn "gần nghĩa nhau".

Đây không phải vấn đề lý thuyết suông. Hugging Face Blog gần đây đặt thẳng câu hỏi "How Much Memory Does Your Agent Actually Need?" (2026) — một tín hiệu cho thấy cộng đồng kỹ thuật đang thực sự vật lộn với bài toán kích thước và kiến trúc bộ nhớ cho AI Agent, chứ không còn là câu hỏi học thuật. Khi hệ thống multi-agent của bạn bắt đầu phải trả lời câu hỏi dạng suy luận đa bước thay vì chỉ tra cứu, đó là dấu hiệu Vector RAG đã chạm trần năng lực của nó.

Mô hình "Dual-Brain": con người ghi chép ở đâu, AI Agent truy xuất ở đâu?

Trả lời trực tiếp: Mô hình Dual-Brain tách rõ hai lớp lưu trữ song song: con người tiếp tục ghi chép, tư duy và liên kết ý tưởng trong Obsidian như bình thường; song song đó, một lớp trích xuất tự động đọc dữ liệu thô (ghi chú, log, tài liệu) để dựng thành một đồ thị tri thức — nơi AI Agent truy vấn khi cần suy luận đa bước, thay vì AI Agent phải "đọc lại" toàn bộ Obsidian mỗi lần.

Đây là kiến trúc tôi rút ra khi nghiên cứu GraphRAG cho hệ thống multi-agent riêng: không thay thế Obsidian bằng đồ thị, mà đặt đồ thị bên cạnh Obsidian, đóng vai trò một bộ nhớ chuyên dụng cho tầng suy luận của AI Agent.

Kỹ thuật cốt lõi làm GraphRAG mạnh ở việc "tổng hợp diện rộng" là Hierarchical Community Summaries: hệ thống nhóm các Entity có quan hệ chặt với nhau thành từng "cụm" (community), rồi tóm tắt từng cụm ở nhiều tầng — từ chi tiết đến tổng quát. Khi AI Agent nhận câu hỏi kiểu "tổng kết toàn bộ vấn đề khách hàng quý này", nó không cần đọc từng đoạn văn rời rạc, mà đọc thẳng bản tóm tắt cấp cụm đã được dựng sẵn — đúng thứ Vector RAG không làm được.

Điểm mấu chốt của Dual-Brain: Obsidian vẫn là nơi tư duy sống — bạn không viết ghi chú để phục vụ máy. Đồ thị tri thức là một bản dịch phái sinh, tự động, phục vụ riêng cho lớp AI Agent — đúng tinh thần Agentic Workflow Architecture mà tôi luôn giữ: con người và AI Agent không dùng chung một bộ nhớ, họ dùng hai bộ nhớ được đồng bộ có kiểm soát.

SME có cần GraphRAG không, hay Obsidian + vector search vẫn đủ ở quy mô nhỏ?

Trả lời trực tiếp: Phần lớn SME Việt Nam chưa cần GraphRAG. Obsidian kết hợp một lớp vector search đơn giản đã đủ cho quy mô dữ liệu và số lượng câu hỏi phổ biến ở SME. GraphRAG chỉ đáng đầu tư khi hệ thống của bạn thường xuyên phải trả lời câu hỏi suy luận đa bước trên một khối tri thức đủ lớn và đủ phức tạp về quan hệ.

Ba dấu hiệu cho thấy bạn có thể cần cân nhắc GraphRAG:

• Câu hỏi thường xuyên là "tổng hợp", không phải "tra cứu". Nếu người dùng hệ thống của bạn liên tục hỏi kiểu "tổng kết toàn bộ", "so sánh xu hướng giữa các quý", "ai liên quan đến vấn đề này" — đó là tín hiệu suy luận đa bước.
• Số lượng thực thể và quan hệ đủ lớn để có giá trị đồ thị hoá. Vài chục ghi chú thì đồ thị không mang lại lợi thế đáng kể so với việc bạn tự nhớ. Vài nghìn tài liệu với nhiều thực thể chồng chéo thì khác.
• Chi phí sai sót do bỏ sót thông tin là cao. Nếu một câu trả lời thiếu sót có thể dẫn đến quyết định sai lệch (ví dụ vận hành, pháp lý, chăm sóc khách hàng), khoản đầu tư vào một pipeline trích xuất đồ thị đáng để cân nhắc.

Ngược lại, nếu bài toán của bạn chủ yếu là "tìm đúng tài liệu đã viết trước đây" — Obsidian với một lớp vector search phủ lên trên (đúng tinh thần kiến trúc 3 lớp AIOS tôi từng chia sẻ) vẫn giải quyết tốt phần lớn nhu cầu, với chi phí vận hành thấp hơn nhiều so với việc dựng và bảo trì một cơ sở dữ liệu đồ thị. Đừng đổi kiến trúc chỉ vì một thuật ngữ đang được nhắc nhiều — đổi kiến trúc khi loại câu hỏi bạn cần trả lời thực sự đã vượt quá năng lực của kiến trúc hiện tại.

Kết luận

Obsidian và GraphRAG không cạnh tranh nhau — chúng phục vụ hai đối tượng ghi nhớ khác nhau trong cùng một hệ thống. Bài học lớn nhất tôi rút ra khi build phần này cho hệ thống multi-agent của mình: đừng chọn kiến trúc bộ nhớ trước, hãy chọn loại câu hỏi bạn cần AI Agent trả lời được trước — kiến trúc sẽ tự lộ diện sau đó.

Nếu bạn đang ở giai đoạn đánh giá tổng thể mức độ sẵn sàng ứng dụng AI của doanh nghiệp mình trước khi đi sâu vào các quyết định kiến trúc như thế này, có thể bắt đầu từ checklist đánh giá AI Readiness cho SME.