Chuyển đến nội dung chính

GraphRAG: Hướng dẫn về Tạo sinh tăng cường truy xuất dựa trên đồ thị

Tìm hiểu cách đồ thị tri thức giải quyết các hạn chế của hệ thống RAG truyền thống.
· 13 phút đọc

Khám phá cùng AI

Các hệ thống RAG truyền thống truy xuất các đoạn tài liệu dựa trên độ tương đồng ngữ nghĩa, cách này hiệu quả với câu hỏi đơn giản. Nhưng khi truy vấn đòi hỏi tổng hợp thông tin rải rác ở nhiều tài liệu hoặc suy luận qua các khái niệm liên kết, tìm kiếm vector tỏ ra hạn chế. Hệ thống chỉ lấy các mảnh rời rạc mà không hiểu quan hệ giữa chúng.

GraphRAG không xem tài liệu như các mảnh cô lập. Nó xây dựng một đồ thị tri thức ghi lại các thực thể và mối quan hệ giữa chúng. Cấu trúc này cho phép hệ thống lần theo các kết nối và trả lời những câu hỏi cần tổng hợp thông tin từ nhiều nguồn. Đây là một trong số các kỹ thuật RAG nâng cao nhằm khắc phục hạn chế của truy xuất cơ bản.

GraphRAG là gì?

GraphRAG là một kỹ thuật tạo sinh tăng cường truy xuất, biểu diễn tài liệu dưới dạng đồ thị tri thức thay vì vector embedding. Thay vì chia văn bản thành các mảnh được tìm kiếm độc lập, GraphRAG trích xuất các thực thể (như con người, tổ chức, khái niệm, sự kiện) và các mối quan hệ giữa chúng, sắp xếp thông tin này thành một cấu trúc đồ thị liên kết.

Hệ thống GraphRag sau đó áp dụng các thuật toán phát hiện cộng đồng để xác định các cụm thực thể liên quan và tạo tóm tắt cho các cụm này ở nhiều cấp độ phân cấp. Khi có truy vấn, GraphRAG có thể lần theo các vùng lân cận thực thể cho câu hỏi nhắm mục tiêu cụ thể hoặc chạy các thao tác map-reduce trên tóm tắt cộng đồng cho việc tổng hợp trên toàn bộ tập tài liệu.

Giờ hãy xem kỹ cơ chế hoạt động. Điều này giúp hiểu vì sao truy xuất dựa trên đồ thị ra đời và lấp đầy khoảng trống nào.

Hạn chế của RAG truyền thống

Vấn đề cốt lõi của RAG truyền thống không nằm ở truy xuất hay tạo sinh, mà là ở cách biểu diễn. Tài liệu bị tách thành các mảnh, và mỗi mảnh trở thành một vector cô lập trôi nổi trong không gian embedding. Mọi cấu trúc vốn có trong bản gốc — đề mục, mạch kể, đoạn nào tham chiếu đến đâu — đều bị làm phẳng.

Điều này gây rắc rối với các câu hỏi cần kết hợp thông tin. Hỏi "Những chủ đề chính trong các tài liệu này là gì?" thì tìm kiếm vector trả về các mảnh chứa từ "chủ đề" hoặc thuật ngữ liên quan. Nhưng tìm các đoạn phù hợp không đồng nghĩa với hiểu được các khuôn mẫu trên toàn bộ kho tài liệu. Hệ thống không có cách ghép thông tin ở quy mô lớn vì nó chỉ thấy từng mảnh riêng lẻ, không bao giờ thấy bức tranh tổng thể.

Suy luận nhiều bước cũng vấp phải bức tường tương tự. Giả sử câu trả lời phụ thuộc vào việc nối khái niệm A tới B rồi tới C. RAG truyền thống truy xuất từng mảnh độc lập dựa trên độ giống với truy vấn. Nếu B không gần với câu hỏi, nó có thể không được truy xuất, làm đứt mạch. Hệ thống tìm được điểm đầu cuối mà bỏ lỡ con đường nối giữa chúng.

Cũng cần xét đến độ lệch giữa truy xuất và ngữ cảnh. Bạn có thể truy xuất hai chục mảnh rất liên quan, nhưng nhét tất cả vào một prompt không đảm bảo LLM sẽ dùng chúng tốt. Bài nghiên cứu "lost in the middle" cho thấy LLM có xu hướng tập trung vào thông tin ở đầu và cuối cửa sổ ngữ cảnh, thường bỏ qua phần ở giữa. Truy xuất nhiều hơn không tự động đồng nghĩa với câu trả lời tốt hơn.

So sánh RAG truyền thống và GraphRAG. Hình: Tác giả.

Cách GraphRAG khắc phục hạn chế của RAG

GraphRAG vượt qua các hạn chế này bằng cách thay đổi hoàn toàn cách biểu diễn. Thay vì các mảnh, nó xây dựng đồ thị tri thức nơi các thực thể là nút và mối quan hệ là cạnh. Con người, tổ chức, địa điểm, khái niệm và sự kiện được trích xuất từ tài liệu nguồn cùng với cách chúng kết nối với nhau. Điều này giữ lại cấu trúc mà việc chia mảnh đã loại bỏ.

Khi đồ thị đã sẵn sàng, hệ thống áp dụng phát hiện cộng đồng (thường dùng thuật toán Leiden) để gom các thực thể liên quan thành nhóm. Các cụm hình thành ở nhiều cấp độ, có cụm chặt, cụ thể; có cụm rộng, mang tính chủ đề. Các nhóm này xuất phát từ kết nối thực trong dữ liệu thay vì ranh giới tài liệu hay kích thước mảnh.

Đồ thị tri thức hiển thị thực thể dưới dạng nút. Hình: Tác giả.

Với câu hỏi toàn cục, GraphRAG tạo sẵn tóm tắt cho mỗi cộng đồng trước khi có truy vấn. Khi ai đó hỏi "Những chủ đề chính là gì?", hệ thống không tìm văn bản khớp. Thay vào đó, nó chạy map-reduce: mỗi tóm tắt cộng đồng tạo một câu trả lời phần dựa trên lát cắt của đồ thị, rồi các phần này được gộp thành phản hồi cuối. Cách này cho phép GraphRAG suy luận trên toàn bộ kho tài liệu mà không phải truy xuất hàng nghìn mảnh.

Với câu hỏi nhiều bước, việc duyệt đồ thị thay thế tìm kiếm tương đồng. Hệ thống có thể đi theo các cạnh từ thực thể này sang thực thể khác, lần theo chuỗi khái niệm mà tìm kiếm vector bỏ lỡ. Nếu A nối với B rồi nối với C, đồ thị biết đường đi đó tồn tại và có thể theo dõi.

Khi nào nên dùng GraphRAG

GraphRAG phát huy hiệu quả khi câu hỏi đòi hỏi hiểu biết trên toàn tập tài liệu. Nếu người dùng thường xuyên hỏi về chủ đề, khuôn mẫu, hay tóm tắt trên bộ sưu tập tài liệu lớn, truy xuất dựa trên đồ thị sẽ vượt trội so với cách chia mảnh. Điều tương tự đúng với các miền có quan hệ thực thể phong phú, như sơ đồ tổ chức công ty, mạng lưới trích dẫn nghiên cứu, hay lịch sử án lệ nơi việc lần theo kết nối là cốt yếu.

Với truy vấn tra cứu thực tế đơn giản ("Số điện thoại của X là gì?") hoặc bộ tài liệu nhỏ, RAG truyền thống đủ tốt và rẻ hơn. GraphRAG làm tăng chi phí ở cả thời gian lập chỉ mục và số lần gọi LLM, nên lợi ích cần xứng đáng với đầu tư. Hãy bắt đầu với RAG chuẩn và chuyển sang GraphRAG khi bạn chạm đến giới hạn của nó.

RAG truyền thống so với GraphRAG

Bảng dưới đây tóm tắt các đánh đổi. RAG truyền thống thắng về độ đơn giản và chi phí, còn GraphRAG vượt trội khi câu hỏi cần tổng hợp hoặc suy luận qua các kết nối.

Khía cạnh

RAG truyền thống

GraphRAG

Biểu diễn dữ liệu

Các mảnh văn bản cô lập dưới dạng vector

Đồ thị tri thức với thực thể và mối quan hệ

Bảo toàn cấu trúc

Mất đi trong quá trình chia mảnh

Được duy trì thông qua các cạnh đồ thị

Truy vấn toàn cục

Kém (truy xuất mảnh rời, không tổng hợp được)

Mạnh (map-reduce trên tóm tắt cộng đồng)

Suy luận nhiều bước

Hạn chế (truy xuất mảnh độc lập)

Tự nhiên (duyệt đồ thị theo các kết nối)

Chi phí lập chỉ mục

Thấp (chỉ embedding)

Cao (trích xuất bằng LLM + embedding + phân cụm)

Chi phí truy vấn

Thấp

Biến thiên (cục bộ rẻ, toàn cục đắt)

Phù hợp nhất cho

Tra cứu thực tế, kho nhỏ

Câu hỏi theo chủ đề, miền có kết nối dày đặc

Quy trình GraphRAG

Quy trình có hai giai đoạn: lập chỉ mục để xây đồ thị, và truy vấn để sử dụng nó.

Giai đoạn lập chỉ mục

Lập chỉ mục biến tài liệu thô thành cấu trúc tri thức qua năm bước:

  • Chia mảnh tách tài liệu thành các phần ~300 token để xử lý
  • Trích xuất thực thể và quan hệ để lấy con người, khái niệm, tổ chức và cách chúng kết nối
  • Xây dựng đồ thị biến kết quả trích xuất thành nút và cạnh, gộp trùng lặp
  • Phát hiện cộng đồng gom các thực thể liên quan ở nhiều cấp phân cấp
  • Tóm tắt cộng đồng tạo mô tả văn bản cho mỗi cụm

Bước trích xuất là nơi diễn ra phần lớn các cuộc gọi LLM. Mỗi mảnh được xử lý bằng một prompt yêu cầu mô hình xác định thực thể và quan hệ. Một mảnh nhắc đến "OpenAI phát hành GPT-4" sẽ tạo các thực thể tương ứng, cùng một quan hệ liên kết giữa chúng. Lượt này cũng ghi nhận loại quan hệ. Vì mỗi mảnh cần một lần gọi LLM, lập chỉ mục là phần tốn kém nhất của quy trình. Thời gian truy vấn rẻ hơn do công việc nặng đã làm sẵn.

Xây dựng đồ thị xử lý việc quy chiếu thực thể, vốn khá phức tạp. "OpenAI", "Open AI", và "the company" có thể đều chỉ cùng một thực thể ở các mảnh khác nhau. Hệ thống gộp các bản trùng này để tạo đồ thị sạch.

Phát hiện cộng đồng áp dụng thuật toán Leiden để tìm nhóm tự nhiên ở nhiều cấp. Cấp 0 có thể gồm các cụm chặt 5–10 thực thể liên quan. Các cấp cao hơn gom chúng lại thành chủ đề rộng. Một kho về công ty AI có thể có cộng đồng cấp 0 cho từng công ty, cấp 1 cho "phòng thí nghiệm AI" và "nhà sản xuất chip", và cấp 2 bao trùm toàn bộ hệ sinh thái công nghệ. Mỗi cộng đồng sau đó nhận một bản tóm tắt do LLM tạo mô tả ý nghĩa cụm. Các tóm tắt này được tính sẵn trước khi có truy vấn người dùng.

Kết quả cuối cùng không phải là chỉ mục truy xuất. Đó là một biểu diễn có cấu trúc: đồ thị cộng với các tóm tắt, sẵn sàng để truy vấn theo nhiều cách.

Giai đoạn truy vấn

Khi đồ thị đã xây xong, truy vấn sẽ được định tuyến tới các chiến lược truy xuất khác nhau:

  • Tìm kiếm toàn cục chạy map-reduce trên tóm tắt cộng đồng cho câu hỏi tổng hợp
  • Tìm kiếm cục bộ duyệt vùng lân cận thực thể cho tra cứu cụ thể
  • Tìm kiếm DRIFT bắt đầu rộng rồi khoan sâu vào vùng hứa hẹn

Nội dung truy xuất (tóm tắt, thực thể, quan hệ, văn bản nguồn) được lắp ghép thành một prompt, và LLM tạo ra câu trả lời cuối. Mỗi chiến lược phục vụ một kiểu câu hỏi khác nhau, phần sau sẽ phân tích chi tiết.

Tìm hiểu các loại truy vấn

GraphRAG cung cấp ba chiến lược truy xuất riêng biệt, phù hợp với các kiểu câu hỏi khác nhau. Việc chọn đúng phụ thuộc vào việc bạn cần tổng hợp rộng, thông tin thực thể cụ thể, hay thứ gì đó ở giữa hai thái cực.

Tìm kiếm toàn cục

Tìm kiếm toàn cục trả lời những câu hỏi cần hiểu toàn bộ kho tài liệu. Các câu như "Những chủ đề chính trong bộ sưu tập tài liệu này là gì?" hoặc "Những khuôn mẫu nào xuất hiện trong các báo cáo này?" cần thông tin được tổng hợp từ khắp nơi, không phải chỉ truy xuất vài mảnh khớp.

Cơ chế là map-reduce trên tóm tắt cộng đồng. Ở pha map, mỗi tóm tắt cộng đồng được xử lý độc lập: hệ thống yêu cầu một LLM trích xuất các điểm liên quan và đánh giá tầm quan trọng. Ở pha reduce, các điểm xếp hạng cao nhất từ mọi cộng đồng được tổng hợp vào prompt cuối, và LLM tổng hợp chúng thành phản hồi mạch lạc.

Tìm kiếm toàn cục của GraphRAG dùng map-reduce. Hình: Tác giả

Cách này hiệu quả vì tóm tắt cộng đồng đã nêu bật nội dung của mỗi cụm thực thể. Hệ thống không cần truy xuất hàng nghìn mảnh. Thay vào đó, nó suy luận trên các mô tả tính sẵn đại diện cho cấu trúc đồ thị ở bất kỳ cấp phân cấp nào bạn chọn. Cấp thấp (cộng đồng nhỏ, chặt) cho câu trả lời chi tiết hơn nhưng tốn nhiều lần gọi LLM. Cấp cao (nhóm rộng) chạy nhanh hơn nhưng có thể bỏ lỡ sắc thái.

Tìm kiếm toàn cục nặng tính toán hơn các chế độ khác vì phải xử lý tất cả cộng đồng. Chỉ dùng khi câu hỏi thực sự cần hiểu biết trên toàn bộ kho tài liệu, thay vì các sự kiện cụ thể.

Tìm kiếm cục bộ

Tìm kiếm cục bộ xử lý câu hỏi về thực thể cụ thể. "Cúc La Mã có đặc tính chữa lành gì?" hoặc "Acme Corp đã công bố điều gì về kết quả quý 3?" nhắm vào các thực thể cụ thể và thông tin liên quan đến chúng.

Quy trình truy xuất bắt đầu bằng việc xác định những thực thể trong đồ thị liên quan đến truy vấn. Các thực thể này trở thành điểm xuất phát để duyệt. Từ mỗi nút bắt đầu, hệ thống lấy các thực thể liên kết, mối quan hệ giữa chúng, mọi tuyên bố hay sự thật liên quan, và các báo cáo cộng đồng chứa các thực thể đó. Hệ thống cũng truy xuất các mảnh văn bản gốc gắn với các thực thể, cung cấp cho LLM cả dữ liệu đồ thị có cấu trúc lẫn văn bản nguồn.

Tìm kiếm cục bộ của GraphRAG với các nút liên quan. Hình: Tác giả

Toàn bộ thông tin ứng viên này được xếp hạng và lọc để phù hợp với cửa sổ ngữ cảnh. Sau đó LLM tạo câu trả lời dựa trên nội dung truy xuất. Vì tìm kiếm cục bộ tập trung vào một vùng lân cận của đồ thị thay vì toàn bộ, nó chạy nhanh và rẻ hơn tìm kiếm toàn cục.

Chọn tìm kiếm cục bộ khi câu hỏi đề cập đến sự vật, con người, tổ chức hoặc khái niệm cụ thể trong tài liệu của bạn.

Tìm kiếm DRIFT

DRIFT (Dynamic Reasoning and Inference with Flexible Traversal) nằm giữa toàn cục và cục bộ. Nó xử lý các truy vấn phức tạp cần cả bối cảnh rộng lẫn chi tiết cụ thể.

Quy trình có ba pha. Thứ nhất, pha khởi động so sánh truy vấn với các tóm tắt cộng đồng có liên quan ngữ nghĩa nhất và tạo câu trả lời ban đầu kèm câu hỏi tiếp theo. Thứ hai, pha theo dõi lấy các câu hỏi đó và áp dụng tìm kiếm cục bộ để khoan sâu vào khu vực cụ thể, tạo câu trả lời trung gian và các câu hỏi bám sát hơn. Thứ ba, pha xuất kết quả kết hợp tất cả thành các kết quả được xếp hạng cân bằng giữa góc nhìn toàn cục và chi tiết cục bộ.

Quy trình ba pha của tìm kiếm DRIFT trong GraphRAG. Hình: Tác giả.

Điểm hữu ích của DRIFT là cách nó mở rộng điểm xuất phát tìm kiếm. Bằng việc bắt đầu với bối cảnh cấp cộng đồng, nó truy xuất được nhiều sự kiện đa dạng hơn so với chỉ tìm kiếm cục bộ. Nhưng nhờ tinh lọc qua duyệt cục bộ, nó tránh chi phí của tìm kiếm toàn cục đầy đủ.

Hãy dùng DRIFT cho câu hỏi như "Những thách thức của Công ty X so với xu hướng ngành rộng hơn như thế nào?" nơi bạn cần cả thông tin thực thể cụ thể lẫn bối cảnh theo chủ đề.

So sánh các loại truy vấn

Khía cạnh

Toàn cục

Cục bộ

DRIFT

Phù hợp nhất cho

Chủ đề và khuôn mẫu trên toàn kho

Câu hỏi về thực thể cụ thể

Truy vấn phức tạp cần cả hai

Cơ chế

Map-reduce trên tóm tắt cộng đồng

Duyệt vùng lân cận thực thể

Các pha khởi động → theo dõi → xuất kết quả

Tốc độ

Chậm nhất (xử lý mọi cộng đồng)

Nhanh nhất (duyệt tập trung)

Trung bình (bắt đầu rộng, thu hẹp dần)

Chi phí

Cao nhất

Thấp nhất

Trung bình

Ví dụ truy vấn

"Những chủ đề chính là gì?"

"Công ty X đã công bố điều gì?"

"X so với xu hướng ngành thì thế nào?"

GraphRAG cũng cung cấp một tìm kiếm vector cơ bản như phương án dự phòng cho truy vấn đơn giản nơi việc duyệt đồ thị là quá mức cần thiết. Nhưng với đa số tình huống, chọn giữa toàn cục, cục bộ và DRIFT là đủ.

Triển khai GraphRAG

Phần này hướng dẫn xây dựng hệ thống GraphRAG bằng bản tham chiếu của Microsoft. Chúng ta sẽ dùng một kho nhỏ gồm các bài tiểu luận của Paul Graham về startup để ví dụ có thể chạy được và chi phí hợp lý. Nếu bạn mới kết hợp đồ thị tri thức với hệ thống truy xuất, hướng dẫn RAG với đồ thị tri thức sẽ bao quát các khái niệm nền tảng.

Cài đặt và thiết lập

Tạo thư mục dự án và khởi tạo bằng uv, rồi cài gói graphrag. Thư viện có nhiều phụ thuộc (237 gói bao gồm PyTorch), nên việc cài đặt có thể mất khoảng năm phút:

mkdir ragtest && cd ragtest
 uv init
 uv add graphrag
 graphrag init --root .

Lệnh này tạo cấu trúc dự án:

ragtest/
 ├── .env                	# API key configuration
 ├── settings.yaml       	# Pipeline settings
 ├── prompts/            	# LLM prompt templates
 │   ├── extract_graph.txt
 │   ├── summarize_descriptions.txt
 │   └── ...
 └── input/              	# Your source documents go here

Thư mục prompts/ chứa các mẫu mà GraphRAG dùng để trích xuất thực thể và tóm tắt. Bạn có thể tùy chỉnh cho nhu cầu miền cụ thể, dù mặc định đã hoạt động tốt với văn bản tổng quát.

Chuẩn bị tài liệu

Thêm các tệp văn bản vào thư mục input/. Trong hướng dẫn này, chúng ta dùng ba bài tiểu luận của Paul Graham về startup. Trang web của ông dùng HTML tối giản với nội dung bọc trong thẻ <font>, nên một bộ phân tích đơn giản có thể trích xuất văn bản sạch sẽ:

import urllib.request
 from html.parser import HTMLParser

 class TextExtractor(HTMLParser):
 	def __init__(self):
     	super().__init__()
     	self.text = []
     	self.in_font = False

 	def handle_starttag(self, tag, attrs):
     	if tag == 'font':
         	self.in_font = True

 	def handle_endtag(self, tag):
     	if tag == 'font':
         	self.in_font = False

 	def handle_data(self, data):
     	if self.in_font:
         	self.text.append(data)

 essays = {
 	"startupideas": "http://paulgraham.com/startupideas.html",
     "do_things_that_dont_scale": "http://paulgraham.com/ds.html",
 	"startup_growth": "http://paulgraham.com/growth.html"
 }

 for name, url in essays.items():
 	with urllib.request.urlopen(url) as response:
     	html = response.read().decode('utf-8')
 	parser = TextExtractor()
 	parser.feed(html)
 	text = ' '.join(parser.text)
 	with open(f"input/{name}.txt", "w") as f:
     	f.write(text)
 	print(f"Saved {name}.txt ({len(text.split())} words)")
Saved startupideas.txt (3000 words)
 Saved do_things_that_dont_scale.txt (3000 words)
 Saved startup_growth.txt (3000 words)

Khoảng 9.000 từ tổng cộng trên ba bài luận có liên quan chủ đề, đủ để thấy các quan hệ thực thể có ý nghĩa mà không tốn quá nhiều chi phí API.

Cấu hình quy trình

Sửa .env để thêm khóa OpenAI API của bạn:

GRAPHRAG_API_KEY=your-openai-api-key-here

Tệp settings.yaml mặc định dùng ngay được, nhưng bạn có thể muốn điều chỉnh mô hình. Tệp này dùng gpt-4o-mini theo mặc định, cân bằng giữa chi phí và chất lượng. Xem tham chiếu cấu hình đầy đủ cho mọi tùy chọn sẵn có:

models:
   default_chat_model:
 	type: openai_chat
 	auth_type: api_key
 	api_key: ${GRAPHRAG_API_KEY}
 	model: gpt-4o-mini
 	model_supports_json: true
 	concurrent_requests: 25

   default_embedding_model:
 	type: openai_embedding
 	auth_type: api_key
 	api_key: ${GRAPHRAG_API_KEY}
 	model: text-embedding-3-small

Một số thiết lập đáng chú ý khác trong cấu hình:

chunks:
   size: 1200  	# Tokens per chunk
   overlap: 100	# Overlap between chunks

 extract_graph:
   entity_types: [organization, person, geo, event]
   max_gleanings: 1	# Additional extraction passes

 cluster_graph:
   max_cluster_size: 10

Chạy quy trình lập chỉ mục

Xây dựng đồ thị tri thức bằng:

graphrag index --root .

Quy trình xử lý tài liệu qua trích xuất thực thể, xây đồ thị, và phát hiện cộng đồng:

├── Loading Input (InputFileType.text) - 3 files loaded (0 filtered) ───
 ├── create_base_text_units
 ├── create_final_documents
 ├── extract_graph
 ├── finalize_graph
 ├── create_final_entities
 ├── create_final_relationships
 ├── create_final_text_units
 ├── create_base_entity_graph
 ├── create_communities
 ├── create_final_communities
 ├── create_community_reports
 ├── generate_text_embeddings
 ⠋ GraphRAG Indexer
 ├── All workflows completed successfully

Mỗi bước xây trên kết quả của bước trước. Pha extract_graph chiếm phần lớn số lần gọi LLM, còn create_communities áp dụng thuật toán Leiden để gom các thực thể liên quan.

Với ba bài luận, lập chỉ mục hoàn tất trong khoảng hai phút. Bạn có thể kiểm tra kết quả bằng cách nạp các tệp parquet hoặc xem số dòng:

  • 12 mảnh văn bản từ 3 tài liệu
  • 74 thực thể (con người, tổ chức, khái niệm)
  • 89 quan hệ giữa các thực thể
  • 12 cộng đồng ở các cấp phân cấp khác nhau

Đầu ra nằm trong output/ dưới dạng các tệp parquet:

output/
 ├── documents.parquet
 ├── entities.parquet
 ├── relationships.parquet
 ├── text_units.parquet
 ├── communities.parquet
 ├── community_reports.parquet
 └── lancedb/      	# Vector embeddings

Định dạng parquet giúp mọi thứ dễ di chuyển. Bạn có thể nạp các tệp này bằng pandas để kiểm tra thực thể, duyệt quan hệ, hoặc gỡ lỗi vấn đề trích xuất. Toàn bộ thư mục dự án đủ nhỏ để đưa vào quản lý phiên bản (dưới 10MB với kho này), chỉ cần loại trừ tệp .env chứa API key của bạn.

Truy vấn bằng CLI

GraphRAG cung cấp ba chế độ truy vấn. Hãy thử từng cái.

Tìm kiếm toàn cục cho câu hỏi theo chủ đề:

graphrag query \
 	--root . \
 	--method global \
 	--query "What are the main themes and lessons about startups in these essays?"
SUCCESS: Global Search Response:

 The essays present several interconnected themes about startups:

 **Growth as the defining characteristic**: A startup isn't just a new company—it's
 specifically designed for rapid growth. This growth orientation shapes everything
 from idea selection to daily decision-making. The essays suggest using weekly
 growth rate as a compass for all strategic choices.

 **The power of doing unscalable things**: Counterintuitively, successful startups
 often begin with manual, labor-intensive approaches. Stripe's founders would
 physically set up new users on the spot. Airbnb's founders went door-to-door
 recruiting hosts. These unscalable tactics bootstrap the initial user base.

 **Ideas emerge from problems, not brainstorming**: The best startup ideas come
 from founders solving their own problems or noticing gaps while "living in the
 future." Deliberately trying to generate ideas tends to produce plausible-sounding
 but ultimately weak concepts.

 **User relationships matter early**: Early users provide irreplaceable feedback.
 Founders should go beyond standard customer service to create exceptional
 experiences, gathering insights that shape the product.

Phản hồi tổng hợp các chủ đề trên cả ba bài luận, điều mà RAG truyền thống cần truy xuất và xử lý nhiều mảnh mới làm được. Tìm kiếm toàn cục thay vào đó dựa trên tóm tắt cộng đồng, cho cái nhìn tổng quan mạch lạc.

Tìm kiếm cục bộ cho câu hỏi về thực thể cụ thể:

graphrag query \
 	--root . \
 	--method local \
 	--query "What role does Y Combinator play according to these essays?"
SUCCESS: Local Search Response:

 Y Combinator functions as both an accelerator and a testing ground for startup
 principles. According to the essays, YC provides:

 **Funding and validation**: YC offers initial funding that lets founders focus
 on building rather than fundraising. The program validates ideas through its
 selection process.

 **Growth measurement framework**: YC tracks startups by weekly growth rate,
 with 5-7% weekly growth considered good and 10% exceptional. This metric-driven
 approach forces founders to confront whether they're making real progress.

 **Network effects**: B2B startups at YC gain immediate access to hundreds of
 potential customers—other YC companies. Stripe leveraged this extensively in
 its early days.

 **Demo Day as forcing function**: The program's structure, culminating in Demo
 Day presentations to investors, creates urgency that pushes founders to ship
 and iterate quickly.

Tìm kiếm cục bộ duyệt đồ thị bắt đầu từ thực thể Y Combinator, kéo theo các khái niệm liên quan như chỉ số tăng trưởng, Stripe và Demo Day. Câu trả lời bám sát những gì các bài luận thực sự đề cập về YC thay vì kiến thức chung.

Tìm kiếm DRIFT cho câu hỏi cần cả bề rộng và chiều sâu:

graphrag query \
 	--root . \
 	--method drift \
 	--query "How do the essays describe the relationship between startup ideas and user problems?"
SUCCESS: Drift Search Response:

 The essays establish a direct link between viable startup ideas and genuine user
 problems through several mechanisms:

 **Organic discovery over invention**: Rather than brainstorming ideas, founders
 should notice problems they personally experience. Microsoft, Apple, Google, and
 Facebook all started this way—founders building something they themselves needed.

 **The "well" vs "shallow hole" distinction**: Good ideas serve a small number of
 users who desperately need the solution (a narrow, deep well) rather than many
 users with mild interest (a broad, shallow hole). Depth of need matters more
 than breadth of appeal initially.

 **Feedback loops as validation**: Engaging directly with early users reveals
 whether the problem is real and the solution fits. This feedback shapes the
 product more than any amount of planning.

 **Problem-first, solution-second**: The essays warn against "sitcom startup
 ideas"—concepts that sound plausible but don't address real pain points. A
 social network for pet owners sounds reasonable but lacks urgent demand.

DRIFT bắt đầu rộng với bối cảnh cấp cộng đồng về triết lý startup, rồi khoan sâu vào các ví dụ cụ thể như phép ẩn dụ cái giếng và "sitcom ideas". Kết quả hòa trộn giữa góc nhìn theo chủ đề và chi tiết cụ thể từ văn bản nguồn.

Truy cập lập trình bằng Python

Với hệ thống sản xuất, hãy dùng trực tiếp Python API. Quy trình gồm ba phần: tải cấu hình, tải dữ liệu đã lập chỉ mục và chạy truy vấn.

Đầu tiên, thiết lập cấu hình bằng cách nạp biến môi trường và phân tích tệp thiết lập:

import os
 import yaml
 from pathlib import Path
 from dotenv import load_dotenv
 from graphrag.config.create_graphrag_config import create_graphrag_config

 ROOT_DIR = Path(".")

 # Load environment variables and config
 load_dotenv(ROOT_DIR / ".env")
 with open(ROOT_DIR / "settings.yaml") as f:
 	yaml_content = f.read()
 yaml_content = os.path.expandvars(yaml_content)  # Expand ${VAR} references
 settings = yaml.safe_load(yaml_content)
 config = create_graphrag_config(values=settings, root_dir=str(ROOT_DIR))

Tiếp theo, tải tất cả dữ liệu đã lập chỉ mục từ các tệp parquet. GraphRAG lưu thực thể, quan hệ, cộng đồng và mảnh văn bản tách biệt:

import pandas as pd

 output_dir = ROOT_DIR / "output"
 entities = pd.read_parquet(output_dir / "entities.parquet")
 communities = pd.read_parquet(output_dir / "communities.parquet")
 community_reports = pd.read_parquet(output_dir / "community_reports.parquet")
 text_units = pd.read_parquet(output_dir / "text_units.parquet")
 relationships = pd.read_parquet(output_dir / "relationships.parquet")

 print(f"Loaded {len(entities)} entities, {len(relationships)} relationships")
Loaded 74 entities, 89 relationships

Cuối cùng, chạy truy vấn bằng async API. Hàm local_search nhận tất cả các dataframe cùng tham số truy vấn:

import asyncio
 from graphrag.api import local_search

 async def run_query(query: str):
 	response, context = await local_search(
     	config=config,
     	entities=entities,
     	communities=communities,
         community_reports=community_reports,
     	text_units=text_units,
     	relationships=relationships,
     	covariates=None,
     	community_level=2,
     	response_type="Multiple Paragraphs",
     	query=query,
 	)
 	return response

 query = "What advice do the essays give about finding startup ideas?"
 response = asyncio.run(run_query(query))
 print(response)
The essays provide several valuable insights into finding startup ideas:

 Focus on Growth: A startup is designed to grow quickly. Founders should commit
 to seeking ideas that can scale significantly, as this distinguishes startups
 from ordinary businesses.

 Identify Unmet Needs: Successful startups arise from recognizing problems that
 need solving. Founders who can see different problems, particularly those
 addressable through technology, are more likely to develop effective solutions.

 Leverage Personal Insights: Many successful startups originate from the unique
 insights of their founders, often stemming from personal experiences or
 frustrations. This personal connection leads to more authentic solutions.

 Explore Overlooked Markets: Founders should think outside the box and explore
 markets that may be overlooked. Successful startups often emerge from ideas
 that seem obvious to the founders but aren't yet recognized broadly.

Python API cho bạn toàn quyền kiểm soát dữ liệu nào được nạp, cấp cộng đồng nào để truy vấn, và cách định dạng phản hồi. Với các ứng dụng cần logic truy xuất tùy chỉnh hoặc tích hợp với hệ thống sẵn có, đây là con đường phù hợp.

Kết luận

RAG truyền thống hoạt động tốt — cho đến khi không còn nữa. Bạn sẽ biết mình chạm trần khi người dùng hỏi về chủ đề hay khuôn mẫu và nhận lại một mớ mảnh rời rạc thay vì câu trả lời mạch lạc. Đó là vấn đề GraphRAG giải quyết bằng cách thay mảnh rời bằng đồ thị tri thức với các tóm tắt cộng đồng tính sẵn.

Dù vậy chi phí là có thật. Lập chỉ mục tốn nhiều lần gọi LLM, và tìm kiếm toàn cục cũng không rẻ. Với bộ tài liệu nhỏ hoặc tra cứu thẳng, hãy bám vào tìm kiếm vector.

Nhưng nếu kho tài liệu của bạn có các kết nối phong phú giữa thực thể và người dùng quan tâm đến các kết nối đó, GraphRAG xứng đáng. Chọn loại truy vấn dựa trên câu hỏi: toàn cục cho chủ đề, cục bộ cho thực thể cụ thể, DRIFT khi cần cả hai. Việc triển khai không phức tạp sau khi bạn chạy thử một lần, và đầu ra parquet giúp mọi thứ dễ kiểm tra và gỡ lỗi.

Bexruz (Bex) Tuychiev

Tác giả

Bexruz (Bex) Tuychiev

Tôi là người sáng tạo nội dung về khoa học dữ liệu với hơn 2 năm kinh nghiệm và là một trong những tài khoản có lượng người theo dõi lớn nhất trên Medium. Tôi thích viết các bài chuyên sâu về AI và ML với chút giọng điệu mỉa mai, vì bạn cũng phải làm gì đó để chúng bớt khô khan. Tôi đã xuất bản hơn 130 bài viết và một khóa học trên DataCamp, cùng với một khóa nữa đang được thực hiện. Nội dung của tôi đã được hơn 5 triệu lượt xem, trong đó 20 nghìn người đã trở thành người theo dõi trên cả Medium và LinkedIn. 

Câu hỏi thường gặp về GraphRAG

Sự khác nhau giữa GraphRAG và RAG truyền thống là gì?

RAG truyền thống chia tài liệu thành các mảnh cô lập và truy xuất chúng qua độ tương đồng vector. GraphRAG thay vào đó xây dựng đồ thị tri thức với các thực thể và mối quan hệ, rồi gom các thực thể liên quan thành cộng đồng với tóm tắt tính sẵn. Cách này cho phép tổng hợp thông tin trên toàn bộ kho dữ liệu thay vì chỉ trả về các mảnh khớp.

Khi nào tôi nên dùng GraphRAG thay vì RAG truyền thống?

Hãy dùng GraphRAG khi người dùng hỏi các câu theo chủ đề như "Những khuôn mẫu chính trong các tài liệu này là gì?" hoặc khi câu trả lời đòi hỏi kết nối thông tin từ nhiều nguồn. Với tra cứu thực tế đơn giản hoặc bộ tài liệu nhỏ, RAG truyền thống rẻ hơn và vẫn tốt.

Ba loại truy vấn trong GraphRAG là gì?

Tìm kiếm toàn cục chạy map-reduce trên tóm tắt cộng đồng cho câu hỏi toàn kho. Tìm kiếm cục bộ duyệt vùng lân cận thực thể cho tra cứu cụ thể. Tìm kiếm DRIFT kết hợp cả hai, bắt đầu bằng bối cảnh cấp cộng đồng rồi khoan sâu vào thực thể cụ thể.

Chi phí của GraphRAG so với RAG truyền thống như thế nào?

GraphRAG tốn kém hơn, chủ yếu ở giai đoạn lập chỉ mục. Mỗi mảnh văn bản cần một lần gọi LLM để trích xuất thực thể, và các tóm tắt cộng đồng cũng cần được tạo. Chi phí truy vấn biến thiên: tìm kiếm cục bộ rẻ, còn tìm kiếm toàn cục xử lý tất cả cộng đồng nên chi phí tỷ lệ với kích thước kho.

Tôi có thể dùng GraphRAG với các LLM khác ngoài OpenAI không?

Có. Thư viện GraphRAG của Microsoft hỗ trợ Azure OpenAI sẵn, và cấu hình chấp nhận endpoint API tùy chỉnh. Bạn có thể trỏ đến bất kỳ API tương thích OpenAI nào, bao gồm cả mô hình nội bộ phục vụ qua công cụ như Ollama hoặc vLLM, dù chất lượng trích xuất phụ thuộc vào khả năng tuân thủ hướng dẫn của mô hình.

Chủ đề

Liên quan