Đặt vấn đề

Giả sử chúng ta có một tủ hồ sơ khổng lồ.

Trong tủ có hóa đơn, biên bản họp, phản hồi khách hàng, tài liệu kỹ thuật, email nội bộ, lịch sử sự cố và vài nghìn file PDF được đặt tên theo một hệ thống bí ẩn mà người tạo ra nó có lẽ cũng đã quên.

Bây giờ, một người hỏi:

Chính sách đổi trả của sản phẩm A trong tháng 7 là gì?

Đây là một câu hỏi khá hiền lành. Ta chỉ cần tìm đúng tài liệu, lấy đúng đoạn văn rồi đưa cho mô hình ngôn ngữ đọc.

Vector RAG làm việc này rất tốt.

Nhưng nếu người đó hỏi:

Vì sao số lượng khiếu nại về sản phẩm A tăng trong quý III, những nhà cung cấp nào có liên quan và sự cố này bắt đầu từ thời điểm nào?

Lúc này, câu trả lời không còn nằm gọn trong một đoạn văn.

Một file nói về số lượng khiếu nại. Một email khác nhắc đến nhà cung cấp. Một biên bản họp ghi nhận việc thay đổi linh kiện. Một báo cáo vận hành từ hai tháng trước mô tả dấu hiệu đầu tiên. Mỗi mảnh thông tin đứng riêng đều đúng, nhưng không mảnh nào chứa toàn bộ câu trả lời.

Đây là lúc Vector RAG bắt đầu đi loanh quanh như một người cầm đèn pin trong căn phòng tối: nó soi rất rõ từng chỗ, nhưng không nhìn thấy sơ đồ của cả căn nhà.

GraphRAG xuất hiện để giải quyết vấn đề đó.

Tuy nhiên, vì một lý do nào đó mà ngành công nghệ rất thích làm mọi thứ trở nên hoành tráng, nhiều hệ thống bắt đầu xây knowledge graph cho toàn bộ dữ liệu, kể cả khi người dùng chỉ hỏi một câu đơn giản như “số điện thoại trong hợp đồng là gì”.

Bài viết của Dattaraj Rao trên VentureBeat đặt ra một lời cảnh tỉnh khá thẳng thắn: đừng biến mọi dữ liệu thành graph; hãy chỉ dùng GraphRAG khi hình dạng của câu hỏi thật sự cần đến quan hệ.

Vector RAG thực sự đang làm gì?

Một hệ thống Vector RAG thông thường có thể được hình dung qua bốn bước:

Chia tài liệu thành các đoạn nhỏ, gọi là chunk.
Biến mỗi chunk thành một vector embedding.
Biến câu hỏi của người dùng thành một vector khác.
Tìm những chunk có vector gần câu hỏi nhất rồi đưa chúng vào LLM.

Nếu gọi vector câu hỏi là $q$, vector của một đoạn tài liệu là $d_i$, hệ thống thường xếp hạng tài liệu bằng độ tương đồng cosine:

$$ \text{similarity}(q,d_i) = \frac{q \cdot d_i} {\lVert q \rVert \lVert d_i \rVert} $$

Nghe thì có vẻ hơi đáng sợ, nhưng bản chất chỉ là:

Câu hỏi này có “mùi ý nghĩa” giống đoạn văn nào nhất?

Giả sử người dùng hỏi:

Máy lạnh báo lỗi E5 có nghĩa là gì?

Vector search sẽ tìm những đoạn có các từ và ý nghĩa liên quan đến “máy lạnh”, “E5”, “lỗi”, “mã lỗi” hoặc “khắc phục”.

Nếu tài liệu có một đoạn ghi rõ:

Mã E5 xuất hiện khi cảm biến nhiệt độ dàn lạnh gặp vấn đề.

Thì mọi thứ rất đẹp. Retriever lấy đúng đoạn, LLM viết lại thành câu trả lời dễ hiểu, xong thuật toán, quá dễ.

Vector RAG đặc biệt phù hợp với các câu hỏi:

Tìm một điều khoản cụ thể.
Tra cứu một mã lỗi.
Tìm hướng dẫn sử dụng.
Hỏi giá trị của một thuộc tính.
Tìm đoạn văn có nội dung tương tự.
Trả lời câu hỏi mà bằng chứng nằm trong một hoặc vài đoạn gần nhau.

Một nghiên cứu so sánh có kiểm soát giữa RAG và nhiều họ GraphRAG cho thấy RAG truyền thống thường mạnh hơn ở những câu hỏi single-hop, thiên về sự kiện cụ thể và chi tiết nhỏ. Ngay cả khi bổ sung reranker hoặc iterative retrieval, lợi thế này vẫn còn.

Vấn đề không nằm ở việc vector search yếu.

Vấn đề nằm ở chỗ chúng ta bắt đầu yêu cầu nó làm một công việc mà nó không được sinh ra để làm.

Khi các mảnh giấy cần biết nhau

Hãy tưởng tượng có ba mảnh giấy:

1Mảnh 1:
2Nhà cung cấp Bình Minh giao lô linh kiện X vào tháng 5.
3
4Mảnh 2:
5Lô linh kiện X được sử dụng trong dòng sản phẩm A.
6
7Mảnh 3:
8Dòng sản phẩm A bắt đầu có tỷ lệ lỗi tăng mạnh từ tháng 7.

Nếu hỏi:

Nhà cung cấp nào có thể liên quan đến việc tỷ lệ lỗi của sản phẩm A tăng?

Không mảnh nào chứa nguyên câu trả lời.

Muốn trả lời, ta phải đi qua một chuỗi quan hệ:

1Bình Minh
2    -> giao
3linh kiện X
4    -> được sử dụng trong
5sản phẩm A
6    -> có tỷ lệ lỗi tăng
7tháng 7

Đây là một câu hỏi multi-hop.

“Hop” có thể hiểu đơn giản là một bước nhảy từ một dữ kiện sang một dữ kiện khác.

Vector RAG có thể lấy được mảnh 3 vì nó rất giống câu hỏi. Nó cũng có thể lấy mảnh 2 nếu may mắn. Nhưng mảnh 1 không nhất thiết có độ tương đồng cao với câu hỏi vì trong đó không hề xuất hiện từ “lỗi” hay “sản phẩm A”.

Vector search nhìn thấy những hòn đảo giống câu hỏi.

GraphRAG cố xây những cây cầu giữa các hòn đảo ấy.

GraphRAG thay đổi điều gì?

GraphRAG không chỉ lưu các đoạn văn độc lập. Trong quá trình indexing, hệ thống cố gắng nhận diện:

Thực thể (entity): người, công ty, sản phẩm, linh kiện, địa điểm, sự kiện.
Quan hệ (relation): sản xuất, sở hữu, cung cấp, ảnh hưởng, xảy ra trước, thuộc về.
Thuộc tính: thời gian, trạng thái, số lượng, mô tả.
Cụm hoặc cộng đồng: các thực thể có liên hệ chặt chẽ với nhau.

Một knowledge graph đơn giản có thể gồm các bộ ba:

1(Bình Minh, cung cấp, linh kiện X)
2(linh kiện X, được dùng trong, sản phẩm A)
3(sản phẩm A, xuất hiện lỗi, E5)
4(lỗi E5, tăng mạnh từ, tháng 7)

Khi có câu hỏi, hệ thống không chỉ tìm đoạn văn gần nhất. Nó còn có thể bắt đầu từ một thực thể rồi đi qua các cạnh của graph để tìm những sự kiện liên quan.

Microsoft GraphRAG còn xây các cộng đồng trong graph, tạo tóm tắt cho từng cộng đồng rồi sử dụng chúng để trả lời những câu hỏi mang tính toàn cục. HippoRAG lại kết hợp knowledge graph với Personalized PageRank để lan truyền mức độ liên quan qua các thực thể và tìm lại những đoạn văn gốc phù hợp.

Điểm quan trọng là GraphRAG không phải một thuật toán duy nhất.

Tên gọi này đang bao phủ nhiều cách tiếp cận khác nhau:

Knowledge graph dựa trên entity và relation.
Graph dùng để hướng dẫn lấy lại chunk.
Community graph phục vụ câu hỏi toàn cục.
Cấu trúc cây tóm tắt như RAPTOR.
Graph kết hợp PageRank như HippoRAG.
Graph được xây toàn bộ khi indexing.
Graph được xây một phần hoặc chỉ mở rộng khi có truy vấn.

Vì vậy, nói “GraphRAG tốt hơn RAG” cũng mơ hồ giống như nói “xe tải tốt hơn xe máy”.

Tốt hơn để chở ba tấn gạo thì đúng.

Tốt hơn để chạy ra đầu hẻm mua bánh mì thì chưa chắc.

Khi nào GraphRAG thật sự thắng?

Câu hỏi multi-hop

GraphRAG phát huy tác dụng khi bằng chứng nằm rải rác trong nhiều tài liệu và phải được nối với nhau qua một hoặc nhiều thực thể trung gian.

Ví dụ:

Công ty nào cung cấp linh kiện cho sản phẩm bị thu hồi, và nhà máy nào đã sử dụng lô linh kiện đó?

Để trả lời, hệ thống có thể phải nối:

1Sản phẩm
2-> sự kiện thu hồi
3-> lô linh kiện
4-> nhà cung cấp
5-> nhà máy sử dụng

Nghiên cứu HippoRAG báo cáo mức cải thiện lên đến 20% trên các bài toán hỏi đáp multi-hop. Phương pháp này thực hiện graph-guided retrieval trong một bước nhưng đạt kết quả tương đương hoặc tốt hơn một số phương pháp iterative retrieval, đồng thời được báo cáo rẻ hơn 10–30 lần và nhanh hơn 6–13 lần trong thiết lập thử nghiệm của tác giả.

Một nghiên cứu hệ thống khác cũng tìm thấy cùng một hình dạng kết quả: RAG mạnh ở câu hỏi chi tiết, còn HippoRAG2 và GraphRAG dạng local thường mạnh hơn trên HotPotQA và MultiHop-RAG, nơi câu trả lời cần kết hợp nhiều bằng chứng.

Câu hỏi nhìn toàn bộ kho dữ liệu

Giả sử có 100.000 phản hồi khách hàng.

Người dùng không hỏi:

Khách hàng Nguyễn Văn A phàn nàn điều gì?

Mà hỏi:

Những nguyên nhân lớn nhất khiến khách hàng không hài lòng trong sáu tháng qua là gì, và chúng có liên hệ với nhau như thế nào?

Không chunk nào chứa câu trả lời.

Ngay cả khi lấy top 10, top 20 hoặc top 100 chunk, ta vẫn chỉ có một nhúm cát nhỏ được múc ra từ cả bãi biển. Những chunk được lấy thường là các đoạn có từ ngữ gần câu hỏi nhất, chứ chưa chắc đại diện cho toàn bộ phân bố chủ đề.

Community-based GraphRAG giải quyết việc này bằng cách:

Xây graph từ dữ liệu.
Phát hiện các cộng đồng có liên hệ chặt chẽ.
Tóm tắt từng cộng đồng.
Tổng hợp các bản tóm tắt thành câu trả lời toàn cục.

Trong nghiên cứu GraphRAG ban đầu của Microsoft, phương pháp graph giành ưu thế rõ rệt so với naïve RAG trên các câu hỏi global sense-making, đặc biệt ở tiêu chí độ bao quát và tính đa dạng của câu trả lời. Tuy nhiên, các kết quả dùng LLM-as-a-Judge cần được đọc thận trọng vì cách sắp xếp câu trả lời trước và sau có thể làm thay đổi đánh giá.

Câu hỏi yêu cầu so sánh, thời gian và quan hệ

GraphRAG cũng phù hợp với các câu hỏi có cấu trúc như:

So sánh nhiều nhóm thực thể.
Theo dõi sự kiện theo thời gian.
Tìm nguyên nhân và hệ quả.
Xác định đường đi giữa hai thực thể.
Tổng hợp nhiều góc nhìn trong toàn bộ corpus.

Trong benchmark MultiHop-RAG, GraphRAG có lợi thế rõ hơn ở các câu hỏi comparison và temporal. Nhưng global search có thể mất chi tiết, đặc biệt khi câu hỏi cần một bằng chứng nhỏ và chính xác.

Graph nhìn thấy hình dạng của khu rừng.

Đổi lại, nó đôi khi không đọc rõ dòng chữ nhỏ được khắc trên một chiếc lá.

Khi nào Vector RAG vẫn tốt hơn?

Tra cứu một sự kiện cụ thể

Nếu câu hỏi có thể được trả lời bằng một đoạn văn, graph thường không mang lại nhiều giá trị.

Ví dụ:

Thời hạn bảo hành của sản phẩm A là bao lâu?
Đơn hàng 12345 đang ở trạng thái nào?
Mã lỗi E5 nghĩa là gì?
Hợp đồng bắt đầu từ ngày nào?
Cách đặt lại mật khẩu ra sao?

GraphRAG-Bench cho thấy trên tập dữ liệu tiểu thuyết, RAG có reranker đạt accuracy 60,92 cho bài toán fact retrieval, trong khi HippoRAG2 đạt 60,14 và Microsoft GraphRAG thấp hơn đáng kể. Sự khác biệt giữa RAG và phương pháp graph tốt nhất trong nhóm này gần như không đủ để biện minh cho một kiến trúc phức tạp hơn.

Dữ liệu nhỏ và ít quan hệ

Nếu corpus chỉ có vài trăm tài liệu độc lập, việc xây graph có thể giống như xây đường cao tốc tám làn để đi từ phòng khách xuống nhà bếp.

GraphRAG cần thêm nhiều thành phần:

Entity extraction.
Relation extraction.
Entity resolution.
Graph storage.
Community detection.
Graph traversal.
Cơ chế cập nhật graph.
Kiểm tra chất lượng node và edge.

Mỗi thành phần là một cánh cửa mới để lỗi bước vào.

Tên công ty bị tách thành hai entity.

Hai người trùng tên bị gộp thành một.

Quan hệ “không cung cấp” bị trích xuất thành “cung cấp”.

Sự kiện cũ và mới bị nối nhầm.

Graph lúc đó trông rất thông minh, đầy node, đầy edge, zoom ra lấp lánh như bản đồ các vì sao. Nhưng một vì sao nối nhầm đường có thể kéo cả câu trả lời đi sang một vũ trụ khác.

Dữ liệu thay đổi liên tục

Vector index tương đối dễ cập nhật:

1Tài liệu mới
2-> chia chunk
3-> tạo embedding
4-> đưa vào index

Với GraphRAG, một tài liệu mới có thể làm thay đổi:

Danh sách thực thể.
Quan hệ giữa các thực thể.
Cộng đồng trong graph.
Tóm tắt của cộng đồng.
Thứ hạng của node.
Đường đi dùng khi retrieval.

Do đó, GraphRAG không chỉ là câu chuyện “thêm Neo4j vào hệ thống”.

Nó là một bài toán quản trị tri thức đang sống, mà tri thức sống thì có thói quen lớn lên, đổi tên, mâu thuẫn với chính nó và thỉnh thoảng làm gãy pipeline lúc ba giờ sáng.

Cái giá thật sự của GraphRAG

Chi phí xây graph

Vector RAG chỉ cần embedding model đọc các chunk.

GraphRAG thường cần LLM đọc tài liệu để trích xuất entity, relation, claim và mô tả. Nếu corpus lớn, số lần gọi model có thể tăng rất nhanh.

Chất lượng graph cũng phụ thuộc mạnh vào model được dùng để xây graph. Trong một thí nghiệm trên MultiHop-RAG, graph được xây bằng GPT-4o cho accuracy tổng thể 75,08, cao hơn mức 71,17 khi dùng GPT-4o-mini và 65,77 của RAG không xây graph. Nhưng model xây graph mạnh hơn đồng nghĩa với chi phí indexing cao hơn.

Graph không tự mọc lên từ đất.

Có một đội quân GPU phải đọc tài liệu, bóc từng cái tên, đoán từng mối quan hệ rồi đổ chúng vào một cấu trúc mà ta hy vọng là gần với sự thật.

Context có thể phình ra khủng khiếp

Một lầm tưởng phổ biến là graph giúp context luôn gọn.

Graph có thể giúp tìm quan hệ tốt hơn, nhưng nó cũng có thể kéo theo:

Node.
Edge.
Mô tả entity.
Community summary.
Đoạn văn gốc.
Đường dẫn nhiều hop.
Thông tin lân cận.

GraphRAG-Bench ghi nhận Vector RAG chỉ dùng khoảng 879–954 token trung bình trong thiết lập thử nghiệm, trong khi một số biến thể Microsoft GraphRAG và LightRAG tạo context lớn hơn hàng chục đến hàng trăm lần. HippoRAG2 giữ context gần 1.000 token, cho thấy hiệu quả phụ thuộc rất lớn vào cách triển khai chứ không chỉ vào việc “có graph hay không”.

Nhiều node hơn không đồng nghĩa với nhiều sự thật hơn.

Đôi khi nó chỉ có nghĩa là LLM phải bơi qua một bể chữ sâu hơn.

Graph sai thì retrieval cũng sai

Trong nghiên cứu so sánh RAG và GraphRAG, knowledge graph được xây tự động chỉ bao phủ khoảng 65% entity cần thiết để trả lời trên một số benchmark. Những dữ kiện không được trích xuất vào graph gần như biến mất khỏi con đường retrieval dựa hoàn toàn vào graph.

Đây là lý do graph-only thường nguy hiểm.

Nếu vector search bỏ sót một đoạn, ta có thể tăng recall, dùng hybrid search hoặc reranker.

Nếu graph không hề chứa entity cần thiết, traversal có chăm chỉ đến đâu cũng chỉ chạy vòng quanh trong một bản đồ thiếu mất thành phố.

Giải pháp thực tế: đừng chọn tôn giáo, hãy xây router

Kết luận hữu ích nhất không phải:

Vector RAG tốt hơn.

Cũng không phải:

GraphRAG tốt hơn.

Mà là:

Mỗi câu hỏi cần một cơ chế retrieval khác nhau.

Một kiến trúc thực tế có thể gồm ba đường đi.

Đường 1: Vector RAG

Dành cho:

Tra cứu fact.
Tìm đoạn văn cụ thể.
Câu hỏi single-hop.
Câu hỏi cần latency thấp.
Dữ liệu mới cập nhật liên tục.

Đường 2: GraphRAG

Dành cho:

Multi-hop reasoning.
Quan hệ giữa nhiều thực thể.
Câu hỏi nguyên nhân – hệ quả.
Tổng hợp theo dòng thời gian.
Global sense-making.
Khám phá mẫu trên toàn corpus.

Đường 3: Hybrid retrieval

Dành cho những câu hỏi đứng giữa hai thế giới.

Hệ thống có thể:

Dùng vector search để lấy các chunk khởi đầu.
Trích xuất entity từ những chunk này.
Mở rộng sang các node lân cận trong graph.
Lấy lại đoạn văn gốc gắn với các node.
Gộp và rerank toàn bộ bằng chứng.
Đưa context cuối cùng vào LLM.

Pseudo-code đơn giản:

 1def retrieve(query):
 2    query_type = classify_query(query)
 3
 4    if query_type == "fact":
 5        return vector_search(query)
 6
 7    if query_type == "multi_hop":
 8        return graph_search(query)
 9
10    vector_docs = vector_search(query)
11    graph_docs = graph_expand(query, vector_docs)
12
13    return rerank(query, vector_docs + graph_docs)

Trong thực tế, query router có thể dựa trên:

Bộ rule đơn giản.
Một model phân loại nhỏ.
LLM.
Điểm phức tạp của câu hỏi.
Số entity xuất hiện.
Các từ như “vì sao”, “liên quan”, “so sánh”, “qua các năm”.
Lịch sử đánh giá trên dữ liệu production.

EA-GraphRAG, một nghiên cứu năm 2026, cũng đi theo hướng này: câu hỏi đơn giản được chuyển sang dense RAG, câu hỏi phức tạp được chuyển sang graph retrieval, còn vùng không chắc chắn dùng cơ chế fusion. Theo nhóm tác giả, việc áp dụng GraphRAG cứng nhắc cho mọi truy vấn là nguyên nhân khiến hệ thống vừa chậm vừa có thể kém chính xác hơn RAG thường.

Một nghiên cứu khác về các kiến trúc RAG production cũng cảnh báo rằng retrieval rộng hơn không tự động tạo ra câu trả lời tốt hơn. Context engineering phù hợp có thể giảm 19–53% token trong các kịch bản GraphRAG và Agentic RAG được thử nghiệm.

Ví dụ thiết kế cho hệ thống doanh nghiệp

Giả sử ta xây một trợ lý AI cho kho dữ liệu vận hành.

Người dùng có thể hỏi bốn loại câu.

Loại 1: Tìm một dữ kiện

Sự cố INC-20260721 được đóng lúc mấy giờ?

Dùng keyword search hoặc Vector RAG.

Graph không cần thức dậy.

Loại 2: Tìm tài liệu tương tự

Có sự cố nào trước đây giống lỗi timeout kết nối cơ sở dữ liệu này không?

Dùng hybrid lexical + vector search, sau đó rerank.

Loại 3: Nối nhiều sự kiện

Những service nào bị ảnh hưởng bởi phiên bản thư viện X, ai triển khai và sự cố bắt đầu sau lần release nào?

Dùng graph expansion từ:

1thư viện
2-> service
3-> phiên bản triển khai
4-> release
5-> người thực hiện
6-> incident

Loại 4: Nhìn toàn cục

Trong sáu tháng qua, những nhóm nguyên nhân nào thường dẫn đến sự cố nghiêm trọng và chúng liên quan đến hệ thống nào?

Dùng community retrieval hoặc pipeline tổng hợp phân cấp.

Một hệ thống tốt không ép cả bốn câu hỏi đi qua cùng một cái máy.

Nó giống một bệnh viện: đau đầu nhẹ không cần gọi cả phòng phẫu thuật, nhưng tai nạn đa chấn thương cũng không thể xử lý bằng một viên thuốc cảm.

Nên đánh giá GraphRAG như thế nào?

Đừng chỉ lấy 20 câu hỏi đẹp rồi gọi LLM chấm xem câu trả lời nào “hay hơn”.

Hãy chia evaluation dataset theo hình dạng truy vấn:

Single-hop factual.
Multi-hop relational.
Comparison.
Temporal.
Global summarization.
Unanswerable.
Dữ liệu mới cập nhật.
Câu hỏi có entity mơ hồ.

Sau đó đo riêng:

Retrieval recall.
Evidence coverage.
Answer accuracy.
Faithfulness.
Tỷ lệ trả lời sai khi thiếu bằng chứng.
Latency p50 và p95.
Token đầu vào.
Chi phí indexing.
Chi phí cập nhật.
Tỷ lệ entity và relation được trích xuất đúng.

Đặc biệt phải có nhóm câu hỏi không đủ dữ liệu.

Một hệ thống retrieval lấy được rất nhiều thứ chưa chắc là hệ thống tốt. Đôi khi nó chỉ đang gom đủ rác để LLM tự chế ra một câu chuyện nghe hợp lý.

Nghiên cứu hệ thống về RAG và GraphRAG phát hiện rằng một số phương pháp iterative retrieval cải thiện kết quả trên multi-hop nhưng lại giảm mạnh khả năng từ chối ở các câu hỏi không có câu trả lời. Retrieval càng chạy hăng, mô hình đôi khi càng cảm thấy mình phải nói một điều gì đó.

Tổng kết

Vector RAG tìm những đoạn văn giống câu hỏi.

GraphRAG tìm những mối quan hệ cần thiết để tạo thành câu trả lời.

Hai việc này không giống nhau.

GraphRAG có thể thắng rõ rệt khi câu hỏi cần nối nhiều tài liệu, theo dõi quan hệ giữa các thực thể, phân tích theo thời gian hoặc nhìn toàn bộ corpus. Nhưng với câu hỏi factual đơn giản, Vector RAG thường chính xác, nhanh, rẻ và dễ vận hành hơn.

Do đó, kiến trúc hợp lý không phải là vẽ một knowledge graph thật lớn rồi bắt mọi câu hỏi chui qua đó.

Kiến trúc hợp lý là bắt đầu bằng RAG đơn giản, đo nơi nó thất bại, phân loại hình dạng của những thất bại ấy, sau đó chỉ đưa graph vào đúng chỗ mà quan hệ thực sự tạo ra giá trị.

Graph không phải phép thuật.

Nó chỉ là một tấm bản đồ.

Mà tấm bản đồ dù đẹp đến đâu cũng vô dụng nếu người dùng chỉ đang hỏi chiếc chìa khóa nằm trong ngăn kéo nào.

Cảm ơn các bạn đã quan tâm và theo dõi bài viết, hẹn gặp lại ở các bài viết tiếp theo.

Đừng biến mọi thứ thành đồ thị: Khi nào GraphRAG thật sự thắng Vector RAG?