Hướng Dẫn GraphRAG: Khi Nào Knowledge Graph Thắng Vector RAG (Và Khi Nào Không)

Hướng Dẫn GraphRAG: Khi Nào Knowledge Graph Thắng Vector RAG (Và Khi Nào Không)

GraphRAG chưa chết, nhưng cũng không phải lựa chọn mặc định. microsoft/graphrag đã phát hành v3.1.1 vào 2026-07-18 với 35.088 sao GitHub, và ba bài báo benchmark năm 2026 giờ công khai báo cáo rằng nó thường thua phương pháp truy xuất vector thuần túy. Vì vậy, hướng dẫn GraphRAG này trả lời câu hỏi duy nhất còn lại: một knowledge graph có đáng tiền indexing không?

Bạn Có Nên Dùng GraphRAG? Câu Trả Lời Ngắn

Hãy dùng GraphRAG khi câu hỏi của bạn đi xuyên qua nhiều entity hoặc trải rộng toàn bộ corpus, kiểu như "khách hàng lớn nhất của chúng ta cũng bán cho những nhà cung cấp nào?". Hãy gắn bó với RAG vanilla hoặc hybrid cho các tra cứu sự kiện một bước, tài liệu thay đổi nhanh và ngân sách độ trễ eo hẹp. Đồ thị tự trả phí cho chính nó ở các câu hỏi đa bước và đốt tiền ở mọi nơi khác.

GraphRAG chưa chết và cũng không phải mặc định. Nó xứng đáng với chi phí indexing khi câu hỏi của bạn là đa bước hoặc toàn corpus, và nó lỗ tiền khi câu hỏi không thuộc hai dạng đó.

Phiên bản ngắn gọn:

• GraphRAG thắng ở câu hỏi đa bước và toàn corpus; vanilla RAG thắng ở tra cứu một bước.
• Benchmark 2026 cho kết quả trái chiều: đồ thị giúp ích cho việc tổng hợp nhưng có thể làm hại tóm tắt chi tiết.
• Chi phí rơi vào lúc index, trong các lời gọi LLM trích xuất, chứ không phải lúc truy vấn.
• Hãy chạy Basic Search làm nhóm đối chứng trên chính corpus của bạn trước khi xây bất cứ thứ gì.

Nếu bạn đã vận hành một pipeline vector RAG hoạt động tốt, quyết định duy nhất là liệu một đồ thị đắp lên trên có tự nuôi nổi nó không. Bảng dưới đây là toàn bộ lập luận gói trong sáu dòng, và ở những chỗ bảng nói rằng hãy ở lại với vanilla, đó là câu trả lời thật lòng, thường xuyên hơn mức các nhà cung cấp thừa nhận. Truy xuất hybrid BM25 cộng vector xử lý được hầu hết các trường hợp này mà không cần đồ thị.

GraphRAG Thực Chất Là Gì: Từ Chunk Đến Cộng Đồng

GraphRAG là tạo sinh tăng cường truy xuất trên một knowledge graph thay vì trên các chunk rời rạc. Ở giai đoạn index, một LLM trích xuất entity và quan hệ từ tài liệu của bạn, thuật toán Leiden gom các entity đó thành các cộng đồng, và mỗi cộng đồng nhận một bản tóm tắt. Ở giai đoạn truy vấn, đồ thị cộng với những bản tóm tắt đó trả lời các câu hỏi mà một cửa sổ top_k trên các chunk không thể nào trả lời được về mặt cấu trúc.

Pipeline, từ đầu đến cuối:

Documents
  |
  v
Chunks --> LLM entity + relationship extraction
  |
  v
Knowledge graph (entities = nodes, relations = edges)
  |
  v
Leiden community detection --> community summaries
  |
  v
Vector index over entity + community descriptions

Hai giai đoạn làm hết công việc. Giai đoạn index là giai đoạn đắt đỏ: mỗi chunk tốn một lời gọi LLM để rút ra entity và quan hệ, và các bản tóm tắt cộng đồng còn tốn thêm nhiều lời gọi nữa. Giai đoạn truy vấn là nơi lợi ích xuất hiện. Vì đồ thị lưu các quan hệ một cách tường minh, một câu hỏi như "khách hàng lớn nhất của chúng ta cũng bán cho những nhà cung cấp nào?" trở thành một phép duyệt đồ thị thay vì một hy vọng rằng đúng hai chunk cần thiết sẽ rơi vào cùng cửa sổ top_k.

Các bản tóm tắt quan trọng vì chúng là thứ mà Global Search thực sự đọc: các câu hỏi toàn corpus được trả lời từ văn xuôi cộng đồng viết sẵn, chứ không phải từ chunk thô. Và mỗi cạnh là một phán đoán của LLM, được lưu dưới dạng bộ ba mà bạn có thể truy vấn bằng Cypher trên một cơ sở dữ liệu đồ thị thực thụ. Thiết kế đó cũng là lý do index chiếm phần lớn chi phí, điều mà các con số dưới đây sẽ cụ thể hóa.

Cách đóng khung đáng để giữ lại: vanilla RAG truy xuất đoạn văn, còn GraphRAG truy xuất cấu trúc. Lựa chọn mô hình embedding của bạn vẫn quan trọng với lớp vector, và cơ sở dữ liệu vector của bạn vẫn lưu các mô tả, nhưng đồ thị mới là bộ phận chịu lực mới. Tài liệu Index Overview chính thức mô tả đầy đủ từng giai đoạn.

Bốn Phương Thức Truy Vấn GraphRAG Là Gì?

Engine truy vấn GraphRAG có bốn phương thức: Local Search, Global Search, DRIFT Search và Basic Search. Local Search lập luận lan ra từ các entity cụ thể, Global Search tổng hợp các bản tóm tắt cộng đồng trên toàn corpus, DRIFT Search trộn cả hai một cách đệ quy, còn Basic Search là đường cơ sở vector thuần túy. Tính năng thứ năm, Question Generation, nằm bên trên engine chứ không nằm ngang hàng với nó.

Chúng tôi đã kiểm tra tài liệu trực tiếp tại microsoft.github.io/graphrag/query/overview/ vào 2026-07-30, và con số là bốn. Hầu hết các bài hướng dẫn xếp hạng chỉ nêu hai hoặc ba. Cùng lần kiểm tra đó, chúng tôi thấy từ "lazy" xuất hiện đúng 0 lần trên cả hai trang tổng quan Index và Query, điều này quan trọng với phần chi phí bên dưới.

Dòng đáng để bạn chú ý là dòng cuối. Basic Search là đường cơ sở vanilla-vector tích hợp sẵn, và nó tồn tại để bạn có thể A/B đồ thị với truy xuất thuần trên chính corpus của mình và tìm ra liệu đồ thị có đang tự trả phí không. Đó không phải chuyện vụn vặt; nó là toàn bộ quy trình ra quyết định của hướng dẫn này gói trong một tính năng. Hãy chạy Basic Search trước. Nếu Local, Global hoặc DRIFT search không thắng được nó trên những câu hỏi bạn thực sự nhận được, thì đồ thị là một khoản chi, không phải một nâng cấp.

Các Benchmark 2026 Thực Sự Phát Hiện Điều Gì?

Ba bài báo benchmark năm 2026 phát hiện rằng GraphRAG giúp ích ở các tác vụ tổng hợp đa bước và đa sự kiện nhưng thường xuyên kém hơn vanilla RAG ở những nơi khác. Một trong số đó xây dựng benchmark chuyên để tìm những chỗ đồ thị thua. Cả ba đều đồng ý rằng chiến thắng phụ thuộc vào loại câu hỏi, chứ không phải kích thước corpus. Bằng chứng nói rằng GraphRAG có tính tình huống, không phải mặc định.

Nỗ lực thứ tư, GraphRAG-Bench (repository), đánh giá chín phương pháp GraphRAG trên 16 ngành và 20 giáo trình, và đi đến cùng kết luận từ một góc rộng hơn.

Cả ba bài báo hội tụ ở một điểm: đồ thị tự trả phí ở tổng hợp đa bước và lỗ phí ở truy hồi chi tiết.

Cách đọc của chúng tôi: chu kỳ cường điệu đã gây ra thiệt hại, và những bài báo này là sự điều chỉnh. Không bài nào nói đồ thị vô dụng. Điều chúng nói, một cách nhất quán, là bước tổng hợp khiến GraphRAG giỏi chủ đề toàn corpus cũng chính là bước làm mờ chi tiết. WildGraphBench là ví dụ rõ nhất: đồ thị giúp tổng hợp đa sự kiện từ một số lượng nguồn vừa phải, và làm hại độ chính xác tóm tắt trong cùng một đánh giá. Đó không phải mâu thuẫn; đó là một cơ chế xuất hiện hai lần.

Hệ quả thực tiễn là bạn không thể quyết định chuyện này chỉ từ tài liệu học thuật. Các bài báo cho bạn biết những loại câu hỏi nào cần kiểm thử, chứ không cho biết corpus của bạn có thuộc số đó không. Đó chính xác là việc mà nhóm đối chứng Basic Search từ phần phương thức ở trên đảm nhiệm.

GraphRAG Tốn Bao Nhiêu? (Và Lưu Ý LazyGraphRAG Mà Ai Cũng Nhắc Sai)

Chi phí của GraphRAG là hóa đơn lúc index, không phải lúc truy vấn, và đó chính xác là lý do nó khiến mọi người bất ngờ. Các lời gọi LLM trích xuất entity và quan hệ từ mọi chunk, cộng với lượt tóm tắt cộng đồng, mới là thứ khiến nó đắt. Bạn trả trước, trước cả khi một truy vấn nào chạy. Lúc truy vấn thì rẻ hơn nhưng không miễn phí: Global Search quạt ra khắp các bản tóm tắt cộng đồng với một lời gọi LLM mỗi cộng đồng, đó là lý do bảng phương thức ở trên đánh dấu nó là cao.

Những con số công khai cứng duy nhất đến từ Microsoft Research. Vào 2024-11-25, nhóm báo cáo rằng chi phí index của LazyGraphRAG bằng với vector RAG và bằng 0,1% chi phí của GraphRAG đầy đủ, và với 4% chi phí truy vấn của GraphRAG global search, nó vượt trội các phương pháp đối thủ được kiểm thử, trên cả hai loại truy vấn local và global (Microsoft Research). Đó là số liệu của Microsoft, từ blog của Microsoft, và chúng tôi trích dẫn đúng như vậy; chúng tôi chưa tự chạy một lần index có tính giá nào.

Đây là chỗ đính chính mà hầu hết các bài viết bỏ sót. LazyGraphRAG không phải một tùy chọn pip install. Theo chính ghi chú biên tập của Microsoft ngày 2025-06-06, nó được phát hành vào Microsoft Discovery và Azure Local, không phải vào gói mã nguồn mở. Chúng tôi đã kiểm tra các trang Index Overview và Query Overview chính thức vào 2026-07-30: từ "lazy" xuất hiện 0 lần trên cả hai. Vậy nếu một bài hướng dẫn liệt kê LazyGraphRAG như một biến thể bạn có thể dựng lên ngay chiều nay, thì nó đang lặp lại một tuyên bố đã không còn đúng trong thế giới mã nguồn mở.

Điều bạn có thể làm hôm nay: chạy mô hình trích xuất cục bộ. Chỏ bước index vào một mô hình cục bộ qua Ollama sẽ loại phí API theo token khỏi giai đoạn đắt nhất, và ghép nó với một vector store tự host sẽ giữ phần còn lại của hóa đơn gần bằng không.

Thư Viện GraphRAG Nào Thực Sự Được Bảo Trì?

Hai trong số sáu thư viện GraphRAG được trích dẫn nhiều nhất đã không có push nào trong sáu và chín tháng. Chúng tôi kéo những con số này từ GitHub API vào 2026-07-30, và cuộc kiểm kê dưới đây là phép kiểm mà các bài tổng hợp cũ bỏ qua, kèm lệnh để chạy lại trước khi bạn cam kết với một thư viện. LightRAG và microsoft/graphrag là những thư viện đang hoạt động; nano-graphrag và fast-graphrag đang trôi về phía bỏ hoang.

for r in HKUDS/LightRAG microsoft/graphrag getzep/graphiti neo4j/neo4j-graphrag-python gusye1234/nano-graphrag circlemind-ai/fast-graphrag; do gh api "repos/$r" --jq '.full_name,.stargazers_count,.pushed_at,.open_issues_count'; done

Cách đọc của chúng tôi: sao là chỉ số phù phiếm; ngày push mới là con số quan trọng. LightRAG và microsoft/graphrag đều đang được bảo trì tích cực, với Graphiti bám sát phía sau ở hướng đồ thị thời gian. nano-graphrag và fast-graphrag là hai thư viện mà các bài cũ vẫn khuyên dùng chỉ dựa trên danh tiếng, và cả hai đều không ship gì trong nửa năm.

Cách chọn: chọn microsoft/graphrag nếu bạn muốn cài đặt tham chiếu với bốn phương thức truy vấn chính thức, LightRAG nếu bạn muốn dự án hoạt động mạnh nhất và dấu chân nhẹ hơn, và một thư viện do nhà cung cấp bảo trì như neo4j-graphrag-python nếu bạn đã chạy cơ sở dữ liệu của nhà cung cấp đó. Tránh bất cứ thứ gì có ngày push cuối nằm trước dự án của bạn nửa năm.

Graphiti đáng có một ghi chú có phạm vi: thiết kế đồ thị thời gian của nó được xây cho truy xuất trên dữ liệu nhạy thời gian, và nó chồng lấn với bộ nhớ agent, thứ chúng tôi bao quát riêng trong hướng dẫn về Graphiti và bộ nhớ đồ thị thời gian. Cho phần còn lại của hệ công cụ, xem toàn cảnh công cụ RAG rộng hơn.

Điều Gì Gãy Sau Ngày 200: Drift Đồ Thị Và Trích Xuất Lại

Drift đồ thị là khoản thuế bạn trả sau khi ra mắt, và nó là lời phản đối số một của người thực chiến, có lý do. Mọi tutorial đều đối xử với đồ thị như thứ bạn xây một lần. Các đội thực tế thì mắc kẹt ở ngày 200.

Ba thứ suy thoái. Thứ nhất, index lại khi tài liệu cập nhật. Khi 40 tài liệu thay đổi, bạn không thể chỉ embed lại chúng; bạn phải chạy lại trích xuất LLM trên các chunk đã đổi, đối soát entity mới với đồ thị cũ, và tính lại các cộng đồng bị ảnh hưởng cùng bản tóm tắt của chúng. Một bài hướng dẫn trên Medium gọi cập nhật tăng dần là dễ. Những người thực chiến trên r/Rag không đồng ý. Tác giả của một thread ngày 2026-04-25 chạy BM25 cộng BGE-M3 trên khoảng 600 tài liệu nói thẳng: "Trích xuất entity/quan hệ bằng LLM rất nhiễu, và index lại khi tài liệu cập nhật trông có vẻ đau đớn."

Thứ hai, suy thoái phân giải entity. "Acme Corp", "Acme" và "ACME Corporation" đến từ những tài liệu khác nhau cách nhau nhiều tháng và tách thành ba node mà lẽ ra phải là một. Không có gì tự động gộp chúng lại.

Thứ ba, những quan hệ đúng tại thời điểm trích xuất và âm thầm không còn đúng nữa. Không ai nhận cảnh báo khi một cạnh reports_to trở nên lỗi thời.

def on_documents_changed(changed_docs):
    stale = find_affected_nodes(changed_docs)
    re_extract(changed_docs)
    reconcile_entities(stale)
    recompute_communities(affected_only=True)
    re_summarize(affected_communities)

Codebase là trường hợp tệ nhất, và cũng thú vị nhất. Autocomplete giờ gợi ý "graphrag for codebase", "graphrag claude code" và "graphrag mcp server", và một codebase là một đồ thị thay đổi hàng giờ: mỗi commit viết lại các cạnh lời gọi, di chuyển symbol và xóa hàm. Đó là drift đồ thị theo một lịch trình mà không lần index lại hàng đêm nào theo kịp hoàn toàn. Đó cũng là lý do các công cụ đồ thị code nghiêm túc dựa vào parser tất định như tree-sitter và LSP cho các cạnh, và dành LLM cho phần văn xuôi quanh chúng: docstring, commit message, thread review. Nếu bạn đang đồ thị hóa một repo, hãy đồ thị hóa lớp chậm thay đổi bằng LLM và lớp nhanh thay đổi bằng parser.

Developer Thực Sự Nói Gì Về GraphRAG?

Developer đang làm việc thì chia rẽ, và Google có vẻ biết điều đó: một thread Reddit xếp hạng hai trên "graphrag vs rag", và đó là công cụ tìm kiếm đang nói với bạn rằng chủ đề này cần ý kiến đồng nghiệp, không phải văn mẫu nhà cung cấp.

Sự hoài nghi là có thật. Trên thread r/Rag năm 2024 "Would you always recommend (knowledge) graph RAG over normal RAG?" (10 điểm, 86% upvote), u/EncartaIt viết: "Tất cả tutorial tôi tìm thấy đều đơn giản hóa quá mức và không thực sự đưa ra lập luận mạnh cho pattern knowledge graph." u/Prestigious_Run_4049 còn thẳng hơn: "Tôi nghĩ graph rag chỉ là cường điệu. Mọi người thích nói về nó và nghe có vẻ ngầu nhưng không ai thực sự dùng nó trong use case thật." Không phải ai cũng đồng ý. u/pytheryx, lập luận từ production, ghi nhận rằng truy xuất đồ thị thắng ở câu hỏi dạng danh sách cần ngữ cảnh từ nhiều chunk hơn mức top_k trả về; corpus sách trắng của anh cần khoảng 50 chunk cho một câu trả lời đầy đủ.

Thread năm 2026 thì chừng mực hơn. u/Popular_Sand2773: "Hầu hết các thiết lập graph rag chỉ ăn gian ở quy mô lớn. Bạn chạy một tìm kiếm vector hoặc metadata chuẩn để tìm các node mầm rồi duyệt xung quanh." u/ggone20, đang vận hành một hệ thống khoảng 300 triệu artifact: "Ở quy mô lớn, bạn đúng nghĩa không thể sống thiếu chúng để trả lời câu hỏi thật."

Cách đọc của chúng tôi khớp với lập luận sắc bén nhất trong cả hai thread: điểm uốn là độ phức tạp của câu hỏi, không phải kích thước corpus. Đó cũng là điều các benchmark ở trên phát hiện, và đó là lý do chúng tôi đứng về phía những người thực chiến giới hạn công cụ này cho công việc đa bước, thay vì những người tuyên bố nó đã chết.

Cách Techsy Tiếp Cận Chuyện Này

Đây là trình tự chúng tôi dùng trong các bản dựng cho khách hàng, và nó cố tình nhàm chán.

Thứ nhất, chứng minh trần của truy xuất hybrid. Hầu hết yêu cầu "chúng ta cần đồ thị" mà chúng tôi nghe được thực ra là một vấn đề chunking hoặc reranking trá hình. Một pipeline BM25-cộng-vector với một reranker tử tế trả lời được nhiều hơn mức các đội kỳ vọng.

Thứ hai, chạy Basic Search làm nhóm đối chứng trên chính corpus của bạn trước khi xây bất cứ thứ gì. Đó chính xác là việc phương thức truy vấn thứ tư tồn tại để làm: một đường cơ sở vector thuần để bạn A/B đồ thị trên dữ liệu của bạn, với câu hỏi của bạn.

Thứ ba, chỉ xây đồ thị khi một lớp câu hỏi đo được thất bại trước nhóm đối chứng đó. Nếu truy vấn đa bước hoặc toàn corpus trượt, bạn có một lý do thật. Nếu không, bạn vừa tiết kiệm cho mình một hóa đơn indexing và một vấn đề drift.

Muốn một đôi mắt thứ hai nhìn vào stack truy xuất của bạn? Nhận tư vấn miễn phí.

Về Tác Giả

Mert Batur là Đồng sáng lập của Techsy.io, nơi đội ngũ ship các AI agent, hệ thống tự động hóa và pipeline voice/SDR cho khách hàng B2B. Anh viết về stack công cụ LLM mà đội Techsy thực sự dùng trong production. Trong các bản dựng cho khách hàng, anh là người ra quyết định kiến trúc truy xuất: khi nào tìm kiếm hybrid là đủ, và khi nào một corpus thực sự cần đồ thị. Kết nối với anh trên LinkedIn.

Câu Hỏi Thường Gặp

GraphRAG hoạt động như thế nào?

GraphRAG index tài liệu của bạn thành một knowledge graph. Một LLM trích xuất entity và quan hệ từ mỗi chunk, thuật toán Leiden gom các entity đó thành các cộng đồng, và mỗi cộng đồng nhận một bản tóm tắt. Lúc truy vấn, engine tìm kiếm đồ thị và những bản tóm tắt đó, nên nó có thể nối các sự kiện nằm ở những chunk khác nhau.

GraphRAG khác RAG như thế nào?

RAG chuẩn truy xuất top-k chunk giống nhất và nạp chúng cho mô hình. GraphRAG truy xuất cấu trúc: entity, quan hệ giữa chúng, và các bản tóm tắt cộng đồng viết sẵn. Chính cấu trúc thêm đó là thứ cho phép nó trả lời câu hỏi đa bước và toàn corpus, và cũng là thứ khiến việc index chậm hơn và đắt hơn.

Khi nào tôi nên dùng GraphRAG?

Hãy dùng khi câu hỏi của bạn đi xuyên entity hoặc trải khắp corpus, như câu hỏi chồng lấn nhà cung cấp hoặc phân tích chủ đề lặp lại trên hàng nghìn tài liệu. Hãy bỏ qua với tra cứu sự kiện một bước, corpus thay đổi nhanh, và ngân sách độ trễ hoặc chi phí eo hẹp. Nếu một pipeline hybrid thuần đã trả lời được một lớp câu hỏi, đồ thị chỉ thêm chi phí mà không thêm giá trị.

GraphRAG đã chết chưa?

Chưa, nhưng nó cũng không phải mặc định. Các benchmark 2026 cho thấy nó thường xuyên kém hơn vanilla RAG trên tác vụ thường ngày, điều đã giết chết sự cường điệu, trong khi vẫn thắng ở câu hỏi đa bước và tổng hợp. Cách đóng khung thành thật là theo tình huống: GraphRAG tự trả phí với đúng loại câu hỏi và lỗ tiền với phần còn lại.

Các phương thức truy vấn GraphRAG là gì?

Engine truy vấn chính thức có bốn: Local Search cho câu hỏi xoay quanh entity, Global Search cho tổng hợp toàn corpus, DRIFT Search cho pha trộn đệ quy của cả hai, và Basic Search cho truy xuất vector thuần túy. Tính năng thứ năm, Question Generation, nằm bên trên. Basic Search quan trọng nhất: nó là nhóm đối chứng để bạn A/B với đồ thị.

Indexing GraphRAG tốn bao nhiêu?

Chi phí rơi vào lúc index, trong các lời gọi LLM trích xuất entity và quan hệ từ mọi chunk cộng với tóm tắt cộng đồng. Microsoft Research báo cáo index của LazyGraphRAG bằng 0,1% chi phí của GraphRAG đầy đủ và bằng với vector RAG, nhưng biến thể đó được phát hành vào sản phẩm Microsoft, không phải thư viện mã nguồn mở. Chúng tôi chưa tự chạy một lần index có tính giá nào.

Tôi có thể chạy GraphRAG cục bộ với Ollama không?

Có. Thư viện microsoft/graphrag cho phép bạn chỏ cả index và truy vấn vào một mô hình cục bộ do Ollama phục vụ, điều này loại phí API theo token khỏi bước trích xuất. Bạn đổi tốc độ và chất lượng lấy chi phí: mô hình cục bộ yếu hơn ở trích xuất entity, nên hãy dự liệu đồ thị nhiễu hơn và lượt index dài hơn trên phần cứng khiêm tốn.

LightRAG hay Microsoft GraphRAG tốt hơn?

Chúng tối ưu cho những thứ khác nhau. LightRAG (38.353 sao, push 2026-07-30) hoạt động mạnh nhất và nhẹ hơn khi vận hành; microsoft/graphrag (35.088 sao, v3.1.1) là cài đặt tham chiếu với bốn phương thức truy vấn chính thức. Chọn LightRAG cho một đồ thị production hiệu quả, chọn của Microsoft cho hành vi đúng đặc tả và nhóm đối chứng Basic Search.

Ai tạo ra GraphRAG và khi nào?

Microsoft Research tạo ra GraphRAG. Nhóm công bố bài báo năm 2024 và bảo trì repository mã nguồn mở microsoft/graphrag theo giấy phép MIT, với tài liệu tại microsoft.github.io/graphrag. Thư viện tham chiếu đạt v3.1.1 vào 2026-07-18, và một hệ sinh thái đang hoạt động của các cài đặt bên thứ ba, gồm LightRAG và Graphiti, đã lớn lên xung quanh nó.

Phán Quyết: Khi Nào Đồ Thị Tự Trả Phí

Bằng chứng chỉ về một hướng, nên đây là lập trường.

• GraphRAG chưa chết. Nó có tính tình huống, và các benchmark 2026 nói thẳng điều đó.
• Nó tự trả phí indexing ở câu hỏi entity đa bước và tổng hợp toàn corpus. Nó lỗ tiền ở tra cứu một bước.
• Chi phí là hóa đơn lúc index, và biến thể rẻ mà ai cũng trích dẫn, LazyGraphRAG, chưa bao giờ đến được thư viện mã nguồn mở.
• Đồ thị suy thoái sau khi ra mắt: phân giải entity bị drift và quan hệ trở nên lỗi thời, vậy nên hãy dự trù ngân sách index lại.
• Hãy chạy Basic Search làm nhóm đối chứng trên chính corpus của bạn trước khi xây bất cứ thứ gì.

Một câu duy nhất: một knowledge graph tự trả phí khi câu hỏi của bạn là đa bước hoặc toàn corpus, và không phải trước đó. Nếu bạn muốn một ý kiến thứ hai về stack truy xuất của mình, hãy nhận tư vấn miễn phí.