Kỹ sư QLTT Ghi chú ôn thi
← Về danh sách
AI & Dữ liệu
#GraphRAG#RAG#지식그래프#커뮤니티 탐지#글로벌 검색#로컬 검색#LLM
Cập nhật lần cuối · 2026-09-10

GraphRAG (Sinh tăng cường truy xuất dựa trên đồ thị)

1. Tổng quan

A. Định nghĩa

GraphRAG (Graph-based Retrieval-Augmented Generation) là kiến trúc sinh tăng cường truy xuất trích xuất thực thể và quan hệ từ tài liệu phi cấu trúc để tạo đồ thị tri thức và bản tóm tắt cộng đồng, sau đó truy xuất cấu trúc đồ thị·văn bản gốc·bản tóm tắt tùy theo mục đích truy vấn để cung cấp làm căn cứ trả lời cho mô hình ngôn ngữ lớn (LLM).

RAG thông thường chia tài liệu thành các chunk có kích thước nhất định, tạo vector embedding, rồi truy xuất các chunk gần với truy vấn để đưa vào ngữ cảnh của LLM. Cách làm này hiệu quả khi tìm một sự kiện cụ thể hay ý nghĩa của một đoạn văn, nhưng có giới hạn với các câu hỏi cần liên kết quan hệ giữa người·tổ chức·sự kiện phân tán trong nhiều tài liệu, hoặc tóm tắt chủ đề chung của toàn bộ kho văn bản. Vì không có gì bảo đảm các chunk được truy xuất có liên kết với nhau, LLM phải tự suy luận mối liên kết, và nếu mở rộng phạm vi truy xuất thì chi phí token và nhiễu cùng tăng lên.

GraphRAG không chỉ bảo tồn ý nghĩa của tài liệu bằng một vector duy nhất. Nó biểu diễn các thực thể và quan hệ trích xuất từ tài liệu thành nút và cạnh của đồ thị, gom các tập thực thể liên kết thành cộng đồng (community), rồi tạo bản tóm tắt cho từng cộng đồng. Khi xử lý truy vấn, nó phân biệt sử dụng truy xuất cục bộ (local search) đi theo vùng lân cận của từng thực thể và truy xuất toàn cục (global search) kết hợp nhiều bản tóm tắt cộng đồng. Do đó, GraphRAG lấy làm đối tượng truy xuất không chỉ "đoạn văn giống nhất" mà cả "cái gì liên kết với cái gì và mối liên kết đó có ý nghĩa gì trong toàn bộ ngữ cảnh".

B. Bối cảnh ra đời và sự cần thiết

Thứ nhất, tri thức của doanh nghiệp không hoàn chỉnh trong một tài liệu. Manh mối về cùng một sự kiện bị chia ra nhiều tài liệu: báo cáo sự cố ghi triệu chứng, tài liệu quản lý thay đổi ghi nguyên nhân, biên bản họp ghi quyết định và tổ chức phụ trách. Nếu chỉ dùng truy xuất vector thì có thể tìm được tài liệu có cách diễn đạt giống truy vấn, nhưng khó kết hợp ổn định quan hệ giữa các tài liệu.

Thứ hai, các truy vấn toàn cục như "rủi ro lặp lại trong toàn bộ tài liệu là gì" không phù hợp với cách trả về vài chunk hàng đầu. Đưa toàn bộ tài liệu vào LLM gây ra vấn đề chi phí và độ dài ngữ cảnh, còn nối đơn giản các kết quả truy xuất thì khó bảo đảm tính đại diện hay loại bỏ trùng lặp. Nếu tạo sẵn phân cấp cộng đồng và bản tóm tắt, khi truy vấn có thể khám phá các mẫu ở cấp độ nhóm mà không cần đọc lại toàn bộ tài liệu.

Thứ ba, đồ thị phù hợp để quản lý đồng thời căn cứ liên kết và nguồn gốc của dữ liệu. Nếu gắn provenance như tài liệu gốc, trang, thời điểm trích xuất, độ tin cậy vào thực thể và quan hệ thì có thể truy vết căn cứ của câu trả lời và đánh dấu điểm cần con người rà soát. Tuy nhiên, việc đồ thị được tạo tự động không bảo đảm tính chính xác, nên phải coi lỗi trích xuất và lỗi tóm tắt là đối tượng quản lý chất lượng.

C. Đặc điểm và phạm vi áp dụng

Cốt lõi của GraphRAG không nằm ở bản thân việc đưa vào cơ sở dữ liệu đồ thị, mà ở việc mở rộng đơn vị truy xuất từ chunk tài liệu sang tri thức có cấu trúc và tầng tóm tắt. Đồ thị biểu diễn đường đi, sự trực thuộc, sự phụ thuộc và thứ tự thời gian giữa các thực thể, còn chỉ mục vector bổ sung độ tương đồng ngữ nghĩa. Trong hiện thực thực tế, cấu trúc lai (hybrid) trộn truy xuất đồ thị, truy xuất vector, truy xuất từ khóa và truy xuất văn bản gốc trong cùng một pipeline là phổ biến.

Đối tượng áp dụng là các lĩnh vực mà liên kết giữa tài liệu và tóm tắt tập thể quan trọng như truy vấn quy định·chính sách nội bộ, khám phá tài liệu nghiên cứu, phân tích liên quan giữa sự cố và thay đổi, phân tích rủi ro chuỗi cung ứng, tra cứu bằng sáng chế·bài báo. Ngược lại, với dịch vụ có ít dữ liệu và cần tìm chính xác sự kiện đơn giản thì RAG thông thường rẻ hơn và dễ vận hành hơn. Việc đưa GraphRAG vào phải được quyết định dựa trên tiêu chí "giá trị suy luận mà đồ thị bổ sung có lớn hơn chi phí xây dựng·kiểm chứng hay không" hơn là "có thể xây dựng đồ thị hay không".

2. Cấu trúc tổng thể và luồng xử lý

A. Kiến trúc tham chiếu

flowchart LR
    A[Tài liệu gốc<br/>PDF·HTML·biên bản họp] --> B[Làm sạch tài liệu·chia chunk]
    B --> C[Trích xuất thực thể·quan hệ dựa trên LLM]
    C --> D[(Đồ thị tri thức)]
    C --> E[(Chỉ mục vector thực thể·chunk)]
    D --> F[Phát hiện cộng đồng]
    F --> G[Phân cấp cộng đồng]
    G --> H[Tóm tắt theo cộng đồng]
    B --> E
    Q[Truy vấn người dùng] --> I{Xác định loại truy vấn}
    I -->|Cục bộ| J[Truy xuất lân cận đồ thị·vector·từ khóa]
    I -->|Toàn cục| K[Truy xuất tóm tắt cộng đồng]
    I -->|Kết hợp| L[Kết hợp cục bộ+toàn cục]
    J --> M[Xây dựng ngữ cảnh căn cứ]
    K --> M
    L --> M
    M --> N[Câu trả lời LLM·trích dẫn·căn cứ]

Cấu trúc trên tách giai đoạn lập chỉ mục khỏi giai đoạn truy vấn. Ở giai đoạn lập chỉ mục, tài liệu gốc được làm sạch, tạo chunk, và bộ trích xuất dựa trên LLM hoặc quy tắc sinh ra thực thể·quan hệ·khẳng định (claim). Kết quả này được lưu dưới các dạng khác nhau vào kho đồ thị, kho văn bản gốc và chỉ mục vector, nhưng dùng ID tài liệu và ID chunk làm khóa chung để liên kết nguồn gốc.

Nút của đồ thị biểu diễn thực thể như người·tổ chức·hệ thống·sản phẩm·sự kiện·khái niệm, còn cạnh biểu diễn quan hệ như "trực thuộc", "gọi", "ảnh hưởng đến", "đã xảy ra". Quan hệ đi kèm căn cứ tài liệu và khoảng thời gian. Ví dụ, với quan hệ "dịch vụ A gọi cơ sở dữ liệu B", có thể ghi làm thuộc tính bổ sung tài liệu vận hành nơi sự kiện được trích xuất, ngày quan sát, mô hình trích xuất và trạng thái rà soát.

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

Bước thứ nhất là thu thập và làm sạch. Nếu đầu trang·chú thích·bảng·ảnh quét của PDF bị trộn lẫn thì việc trích xuất thực thể sau đó sẽ sai, nên cần xử lý trước OCR, bảo toàn bố cục, loại bỏ trùng lặp, phát hiện ngôn ngữ và kế thừa quyền truy cập. Đồ thị làm mất ACL của chính tài liệu có thể gây ra vấn đề bảo mật lớn hơn cả độ chính xác truy xuất, nên phải gắn phạm vi truy cập cho cả chunk gốc lẫn các sự kiện trong đồ thị.

Bước thứ hai là chia chunk theo đơn vị ngữ nghĩa. Chỉ cắt theo độ dài cố định có thể làm đứt quan hệ điều khoản, sự kiện, hàng và cột của bảng. Tận dụng phân cấp tiêu đề, ranh giới đoạn văn, tiêu đề bảng và biểu thức thời gian để thiết kế sao cho "ai đã làm gì khi nào" được giữ trong một chunk. Chunk quá lớn làm tăng chi phí trích xuất và nhiễu, chunk quá nhỏ làm tách chủ ngữ và tân ngữ của quan hệ, nên cần thử nghiệm theo từng miền.

Bước thứ ba là trích xuất thực thể và quan hệ. Cung cấp cho LLM schema các loại thực thể và loại quan hệ được phép và yêu cầu xuất theo cấu trúc JSON, nhưng đặt riêng bước kiểm tra định dạng và kiểm tra span văn bản gốc. Áp dụng chuẩn hóa·từ đồng nghĩa·ánh xạ định danh để không tạo riêng rẽ cùng một đối tượng thành "Korea Electric Power Corporation", "Hanjeon", "KEPCO". Nếu không kiểm tra kết quả trích xuất có thực sự có căn cứ trong văn bản gốc hay không thì các liên kết trong đồ thị sẽ trở thành con đường lan truyền những sự thật giả nghe có vẻ hợp lý.

Bước thứ tư là phát hiện cộng đồng và phân cấp. Thay vì tóm tắt từng nút của đồ thị, gom các tập nút có mật độ liên kết cao thành cộng đồng và phân cấp các cộng đồng con thành cộng đồng cha. Khi đó, kích thước và độ phân giải (resolution) của cộng đồng là điểm cân bằng giữa chi phí truy vấn và độ gắn kết của bản tóm tắt. Cộng đồng quá lớn khiến bản tóm tắt trở nên chung chung, còn cộng đồng quá nhỏ làm mất ngữ cảnh cần cho câu hỏi toàn cục.

Bước thứ năm là tạo bản tóm tắt cộng đồng. Bản tóm tắt nên bao gồm các thực thể chính, quan hệ, diễn biến sự kiện, các khẳng định lặp lại, ngoại lệ và danh sách nguồn. Nếu chỉ lưu văn bản tóm tắt thì liên kết với văn bản gốc sẽ yếu, nên cần lưu kèm ID của các phần tử đồ thị và chunk gốc tạo nên bản tóm tắt. Tách riêng các trạng thái như "có căn cứ", "suy đoán", "mâu thuẫn" để cách diễn đạt của mô hình tóm tắt không trở nên khẳng định mạnh hơn văn bản gốc.

C. Giai đoạn truy vấn

Khi có truy vấn, trước hết phân tích phạm vi và ý định của câu hỏi. Câu hỏi về nguyên nhân sự cố của một hệ thống cụ thể gần với truy vấn cục bộ, đi theo vùng lân cận và đường thời gian của thực thể đó. Ngược lại, "nguyên nhân chậm trễ chung xuất hiện trong toàn bộ dự án là gì" gần với truy vấn toàn cục, so sánh nhiều cộng đồng. Nếu xác định sai loại truy vấn, câu hỏi toàn cục sẽ chỉ được trả lời bằng một tài liệu cụ thể, hoặc câu hỏi cục bộ bị đưa vào quá nhiều bản tóm tắt không cần thiết.

Truy xuất cục bộ nhận diện thực thể trong truy vấn, rồi kết hợp vùng lân cận k-hop của nút đó, các chunk liên quan và tài liệu tương đồng về vector. Phản ánh hướng và khoảng thời gian của quan hệ giúp phân biệt "A ảnh hưởng đến B" với "B ảnh hưởng đến A". Kết quả truy xuất phải được tổ chức sao cho đường đi trên đồ thị và trích dẫn văn bản gốc hiển thị cùng nhau để giảm khả năng LLM tự ý nội suy liên kết.

Truy xuất toàn cục lấy bản tóm tắt cộng đồng làm ứng viên, so sánh·tổng hợp từng phần nhiều bản tóm tắt để tạo ngữ cảnh trả lời. Cách thường dùng là phân rã câu hỏi thành các câu hỏi con, tạo câu trả lời theo từng cộng đồng, rồi cuối cùng điều chỉnh trùng lặp và mâu thuẫn. Tuy nhiên, càng lên cao trong phân cấp tóm tắt thì căn cứ chi tiết càng bị nén, nên với câu trả lời cuối cùng cần có bước kiểm chứng truy xuất lại chunk gốc khi cần.

sequenceDiagram
    participant U as Người dùng
    participant Q as Bộ phân tích truy vấn
    participant G as Bộ truy xuất đồ thị
    participant V as Bộ truy xuất vector·từ khóa
    participant C as Kho tóm tắt cộng đồng
    participant L as LLM
    U->>Q: Câu hỏi·quyền·khoảng thời gian
    Q->>Q: Liên kết thực thể·xác định loại truy vấn
    alt Truy vấn cục bộ
        Q->>G: Điều kiện lân cận·đường đi·quan hệ
        G->>V: Truy xuất lại chunk căn cứ
        V-->>G: Văn bản gốc·siêu dữ liệu
        G-->>L: Đường đi đồ thị+căn cứ gốc
    else Truy vấn toàn cục
        Q->>C: Ứng viên phân cấp cộng đồng
        C-->>L: Tóm tắt cộng đồng+nguồn
        L->>V: Yêu cầu kiểm chứng khẳng định chi tiết
        V-->>L: Chunk kiểm chứng
    end
    L-->>U: Câu trả lời·trích dẫn·độ bất định

3. Thành phần cốt lõi và nguyên lý thiết kế

A. Schema đồ thị và ontology

Schema định nghĩa đối tượng nào được tạo thành nút và liên kết nào được công nhận là quan hệ hợp lệ. Ví dụ, trong miền sự cố CNTT có thể đặt dịch vụ, tài nguyên hạ tầng, bản triển khai, sự cố, nguyên nhân, nhóm phụ trách làm loại thực thể, và "được triển khai", "gọi", "được suy đoán là nguyên nhân", "phụ trách" làm loại quan hệ. Nếu phân loại này quá chi tiết thì chi phí trích xuất và chuẩn hóa tăng, còn nếu quá đơn giản thì các khác biệt ngữ nghĩa quan trọng trong truy vấn sẽ biến mất.

Ban đầu, cách tiếp cận tiệm tiến — tạo schema tối thiểu cùng chuyên gia miền rồi mở rộng dần khi phân tích các trường hợp truy vấn thất bại thực tế — là an toàn. Thay đổi schema có thể kéo theo việc trích xuất lại đồ thị hiện có và tạo lại bản tóm tắt, nên cần quản lý phiên bản, quy tắc di chuyển và tính tương thích. Biểu diễn tính thời gian, độ tin cậy, nguồn và thời hạn hiệu lực của quan hệ dưới dạng thuộc tính giúp phân biệt trạng thái hiện tại với trạng thái trong quá khứ.

B. Giải quyết thực thể và quản lý nguồn gốc

Giải quyết thực thể (entity resolution) là quá trình xác định các cách diễn đạt khác nhau có chỉ cùng một đối tượng hay không. Nếu chỉ dùng độ tương đồng tên thì có thể gộp nhầm người trùng tên hoặc tổ chức đã tái cơ cấu, nên phải dùng kèm các thuộc tính định danh như ID tổ chức, ID hệ thống, địa chỉ, thời điểm. Việc gộp tự động được vận hành theo cách tạo ứng viên, còn các trường hợp gộp có rủi ro cao phải được con người phê duyệt.

Nguồn gốc (provenance) giải thích vì sao đồ thị biết như vậy hơn là đồ thị biết gì. Mỗi nút·cạnh·bản tóm tắt phải được liên kết với tài liệu gốc, trang hoặc đoạn ký tự, thời điểm trích xuất, phiên bản mô hình, người rà soát và độ tin cậy. Khi hiển thị nguồn trong câu trả lời, không chỉ đưa ra đường đi trên đồ thị mà còn cung cấp trích dẫn theo đơn vị tài liệu để người dùng có thể mở văn bản gốc kiểm tra.

C. Kết hợp truy xuất và xây dựng ngữ cảnh

Truy xuất đồ thị mạnh về liên kết cấu trúc, còn truy xuất vector mạnh về tương đồng ngữ nghĩa dù cách diễn đạt khác nhau. Truy xuất từ khóa mạnh với các token chính xác như tên sản phẩm·mã·điều khoản luật, nên thay vì để ba phương thức cạnh tranh, hãy kết hợp chúng ở giai đoạn tạo ứng viên và xếp hạng lại. Ví dụ, trước tiên liên kết thực thể, sau đó mở rộng vùng lân cận đồ thị, rồi xếp hạng lại các chunk gắn với từng nút lân cận theo độ tương đồng vector và độ tin cậy nguồn.

Đưa nhiều ngữ cảnh vào không có nghĩa là tốt hơn. Nếu các chunk trùng lặp và các sự thật mâu thuẫn ở những thời điểm khác nhau cùng được đưa vào, LLM có thể chọn câu nghe hợp lý nhất. Ở giai đoạn xây dựng ngữ cảnh, thực hiện loại bỏ trùng lặp, lọc theo thời gian, lọc theo ACL, tối thiểu hóa đường đi quan hệ, đánh dấu khẳng định mâu thuẫn, và trong prompt trả lời đặt quy tắc cấm suy luận ngoài căn cứ.

4. So sánh với RAG thông thường và quy trình áp dụng

A. So sánh

Khác biệt giữa RAG thông thường và GraphRAG không nằm ở việc có cơ sở dữ liệu vector hay không, mà ở đơn vị biểu diễn tri thức và phạm vi câu hỏi. RAG thông thường lấy sự gần gũi ngữ nghĩa của chunk làm trung tâm nên hiện thực đơn giản và chi phí lập chỉ mục thấp. GraphRAG tính toán sẵn cấu trúc giữa các tài liệu và ý nghĩa ở cấp độ nhóm thông qua các bước bổ sung là trích xuất đồ thị·chuẩn hóa·tóm tắt cộng đồng.

Cách tiếp cận dựa trên đồ thị không vượt trội ở mọi truy vấn. Câu hỏi tìm chính xác một câu trong sổ tay thì truy xuất chunk gốc nhanh hơn, và trong môi trường dữ liệu thay đổi thường xuyên thì độ trễ cập nhật của đồ thị và bản tóm tắt trở thành vấn đề. Ngược lại, với các câu hỏi đòi hỏi suy luận nhiều bước (multi-hop), so sánh toàn cục, liên kết tổ chức·sự kiện·phụ thuộc, thông tin cấu trúc của GraphRAG có thể nâng cao ứng viên truy xuất và sức giải thích của câu trả lời.

Hạng mục so sánh RAG thông thường GraphRAG Hàm ý thực tiễn
Đơn vị cơ bản Chunk tài liệu đã embedding Thực thể·quan hệ·cộng đồng·chunk Chọn đơn vị theo loại câu hỏi
Điểm mạnh Truy xuất sự kiện đơn giản, xây dựng nhanh Truy vấn multi-hop·toàn cục, giải thích liên kết Chọn lọc miền đáng để xây dựng đồ thị
Chi phí lập chỉ mục Tập trung chia chunk·embedding Thêm trích xuất·giải quyết·phát hiện·tóm tắt Lập ngân sách cho chi phí ban đầu và chi phí cập nhật
Tính cập nhật Tập trung cập nhật văn bản gốc·vector Cần đồng bộ đồ thị·tóm tắt Thiết kế cập nhật gia tăng và thời hạn hiệu lực
Biểu diễn căn cứ Trích dẫn chunk truy xuất Kết hợp trích dẫn đường đi·tóm tắt·văn bản gốc Đưa provenance vào cam kết của câu trả lời
Rủi ro chính Bỏ sót chunk liên quan, phân mảnh Liên kết·khuếch đại lỗi trích xuất Bắt buộc kiểm chứng văn bản gốc và cổng chất lượng

B. Quy trình áp dụng theo từng bước

Bước 1 là xác định truy vấn và tiêu chí thành công. Chia các câu hỏi đại diện thành loại cục bộ·toàn cục·kết hợp, và đặt mục tiêu về tính đúng, tính có căn cứ, tính đầy đủ, độ trễ và chi phí. Ví dụ, xây dựng thành các tập đánh giá riêng "dịch vụ bị ảnh hưởng và tài liệu căn cứ của một sự cố cụ thể là gì" và "nguyên nhân sự cố chung trong 1 năm gần đây là gì".

Bước 2 là chuẩn hóa dữ liệu và quyền. Kiểm tra chủ sở hữu, thời hạn lưu giữ, cấp phân loại, ACL, phiên bản của tài liệu, và cho kế thừa chính sách truy cập để nút đồ thị không có quyền rộng hơn văn bản gốc. Tài liệu chứa thông tin cá nhân hay bí mật kinh doanh được áp dụng chính sách che·token hóa·phi định danh, và làm rõ phạm vi được gửi đến nhà cung cấp mô hình.

Bước 3 là kiểm chứng pipeline lập chỉ mục với một miền quy mô nhỏ. Trong lĩnh vực quản lý sự cố hay thiết kế sản phẩm có ít tài liệu, xác định loại thực thể, loại quan hệ, từ đồng nghĩa, biểu thức thời gian, và lấy mẫu kết quả trích xuất để con người rà soát. Nếu chất lượng đồ thị không vượt tiêu chuẩn thì ưu tiên cải thiện schema·chia chunk·làm sạch văn bản gốc trước khi sửa prompt truy xuất.

Bước 4 là gắn truy xuất lai và đánh giá câu trả lời vào vận hành. Bắt đầu bằng cách đặt RAG thông thường làm đường mặc định và chỉ định tuyến các câu hỏi có lợi cho truy xuất đồ thị sẽ giúp giới hạn chi phí và rủi ro. Câu trả lời hiển thị tài liệu căn cứ và độ bất định, và phản hồi người dùng được phân loại thành truy vấn thất bại·thực thể bị thiếu·quan hệ sai·bản tóm tắt lỗi thời để phản ánh vào cải tiến pipeline.

5. Ví dụ và đánh giá

A. Ví dụ phân tích tri thức sự cố

Giả sử một nền tảng mua sắm quy mô lớn giả định tích hợp báo cáo sự cố, hồ sơ triển khai, cảnh báo giám sát và biên bản họp. RAG thông thường có thể trả về các chunk tương tự "thanh toán chậm", nhưng khó thể hiện ổn định toàn bộ đường đi: sự chậm trễ đó bắt đầu sau một bản triển khai cụ thể, qua sự bùng nổ retry của message queue và cạn kiệt connection pool của cơ sở dữ liệu, rồi lan sang dịch vụ đặt hàng.

GraphRAG tạo nút cho dịch vụ thanh toán, phiên bản triển khai, message queue, cơ sở dữ liệu, nhóm phụ trách và ghi lại quan hệ theo thời gian. Nếu truy vấn là "thay đổi đầu tiên và phạm vi ảnh hưởng của sự cố lần này là gì", truy xuất cục bộ đường đi từ nút triển khai đến nút sự cố cùng các chunk liên quan. Nếu truy vấn là "nguyên nhân chung lặp lại trong các sự cố quý trước là gì", truy xuất toàn cục bằng cách so sánh bản tóm tắt theo cộng đồng sự cố để xem cấu hình retry, thiếu dung lượng, chậm trễ API thanh toán bên ngoài có lặp lại không.

Cốt lõi của ví dụ này là đồ thị không tự động xác định nguyên nhân, mà liên kết các ứng viên có thể điều tra với căn cứ. Các cạnh biểu diễn quan hệ nhân quả phải phân biệt trạng thái như "trước sau theo quan sát", "người phụ trách xác nhận", "được kiểm chứng bằng thực nghiệm". Nếu không, quan hệ trước sau đơn thuần về thời gian có thể bị tóm tắt thành nguyên nhân chắc chắn và làm sai lệch quyết định vận hành.

B. Chỉ số đánh giá và kiểm thử

Đánh giá truy xuất đo lường xem thực thể·quan hệ·chunk liên quan có nằm trong kết quả truy xuất hay không. Đánh giá câu trả lời xem xét đồng thời tính xác thực, độ chính xác của trích dẫn căn cứ, tính đầy đủ khi xử lý mọi điều kiện của câu hỏi, cách xử lý thông tin mâu thuẫn và việc có vi phạm quyền hay không. Nếu chỉ tối ưu một điểm số duy nhất, các vấn đề như trích dẫn nhiều nhưng không trả lời câu hỏi, hay trả lời trôi chảy nhưng không có căn cứ có thể bị che khuất.

Tập đánh giá offline bao gồm câu hỏi cục bộ đã biết đường đi đúng, câu hỏi toàn cục cần tổng hợp nhiều cộng đồng, câu hỏi cố ý mơ hồ và câu hỏi mà thông tin cũ và mới xung đột. Khi online, ngoài tỷ lệ chấp nhận câu trả lời, còn quan sát tỷ lệ xem căn cứ, tỷ lệ hỏi lại, số lần chặn quyền sai, độ trễ và chi phí token. Khi áp dụng schema hoặc mô hình trích xuất mới, chạy lại tập đánh giá hiện có để kiểm tra sự hồi quy về chất lượng đồ thị.

6. Chuyên sâu: Xu hướng chi phí·tính cập nhật·vận hành

Chi phí của GraphRAG phải được xem xét tách thành chi phí khi truy vấn và chi phí khi lập chỉ mục. Trích xuất thực thể·quan hệ và tóm tắt cộng đồng tạo chi phí ban đầu với tài liệu quy mô lớn, nhưng có thể giảm chi phí truy vấn cho các câu hỏi toàn cục lặp lại. Ngược lại, nếu tài liệu thay đổi thường xuyên thì cách tạo lại toàn bộ đồ thị mỗi lần là không hiệu quả, nên cần xử lý gia tăng chỉ cập nhật tài liệu thay đổi và cộng đồng bị ảnh hưởng cùng chính sách tóm tắt lại.

Thay vì xử lý truy xuất cục bộ và toàn cục bằng một prompt khổng lồ, thiết kế mô-đun kết hợp bộ định tuyến truy vấn, duyệt đồ thị, truy xuất vector và truy xuất lại bản tóm tắt sẽ có lợi cho vận hành. Phân tầng — dùng mô hình chi phí thấp cho trích xuất ứng viên và kiểm tra định dạng, dùng hạn chế mô hình hiệu năng cao cho điều chỉnh mâu thuẫn và câu trả lời cuối — cũng giúp giảm chi phí. Tuy nhiên, khi tách mô hình thì phát sinh thiên lệch trích xuất và khác biệt diễn đạt theo từng mô hình, nên phải ghi lại phiên bản mô hình và tính tương thích của kết quả.

Tài liệu GraphRAG chính thức của Microsoft mô tả cách tiếp cận này là RAG phân cấp có cấu trúc, và README của kho công khai vào tháng 8 năm 2026 thông báo rằng kho đang ở trạng thái tập trung bảo trì, ưu tiên xử lý lỗ hổng bảo mật và cập nhật phụ thuộc. Do đó, thay vì áp dụng nguyên một hiện thực cụ thể làm nền tảng tiêu chuẩn, nên thiết kế độc lập các nguyên lý như schema đồ thị·nguồn gốc·tập đánh giá·quyền truy cập trên nền tảng dữ liệu·LLM của tổ chức. Trong tương lai, nhiều khả năng truy xuất lai đồ thị và vector, lựa chọn cộng đồng động, tóm tắt trễ (lazy summarization) và gọi công cụ của agent sẽ được kết hợp, nhưng phải ưu tiên khả năng truy vết căn cứ và tính nhất quán khi cập nhật hơn là mở rộng tính năng.

7. Những điểm cần xem xét và hàm ý

A. Kiểm soát độ chính xác·ảo giác

Tính cấu trúc của đồ thị không tự động bảo đảm tính xác thực của câu trả lời. Nếu thực thể hay quan hệ bị LLM trích xuất sai liên kết với nhiều tài liệu thì lỗi có thể bị khuếch đại, nên đặt kiểm chứng span văn bản gốc, độ tin cậy quan hệ, con người phê duyệt và đánh dấu khẳng định mâu thuẫn làm cổng chất lượng. Câu trả lời cuối cùng phải tách phần suy luận không có căn cứ, và khi chưa được xác nhận thì diễn đạt là "suy đoán" hoặc "cần xác nhận thêm".

B. Tính cập nhật·đồng bộ

Nếu văn bản gốc đã thay đổi mà đồ thị và bản tóm tắt cộng đồng vẫn còn thì tri thức cũ sẽ được truy xuất như sự thật mới nhất. Quản lý phiên bản tài liệu, sự kiện thay đổi, phạm vi ảnh hưởng trên đồ thị, thời gian hết hạn của bản tóm tắt, và với nghiệp vụ rủi ro cao thì bắt buộc kiểm chứng lại văn bản gốc khi truy vấn. Ở những lĩnh vực mà cập nhật theo lô là không đủ, đưa vào thu thập dữ liệu thay đổi (CDC) và lập chỉ mục lại gia tăng, nhưng phải xác định chính sách nhất quán để không để lộ cho người dùng đồ thị đang được cập nhật dở.

C. Bảo mật·thông tin cá nhân·quyền

Đồ thị làm lộ rõ trong nháy mắt các quan hệ vốn phân tán trong tài liệu, nên có thể trở thành tri thức nhạy cảm hơn cả văn bản gốc. Cho nút và cạnh kế thừa ACL tài liệu, tenant, thời hạn lưu giữ, phân loại thông tin cá nhân, và kiểm thử riêng xem thông tin không có quyền có bị suy luận ra qua đường duyệt đồ thị hay không. Áp dụng ranh giới tin cậy, làm sạch đầu vào, quyền gọi công cụ và log kiểm toán để tài liệu chứa prompt injection không làm ô nhiễm quan hệ hay bản tóm tắt của đồ thị.

D. Chi phí·hiệu năng·khả năng mở rộng

Ước tính số lần gọi LLM cần cho trích xuất thực thể·trích xuất quan hệ·tóm tắt và chi phí lưu trữ·truy xuất đồ thị theo khối lượng tài liệu, tỷ lệ thay đổi và lượng truy vấn. Thay vì tạo mọi bản tóm tắt cộng đồng ở độ phân giải cao nhất, có thể phân cấp tầng và chu kỳ cập nhật theo tần suất và tầm quan trọng của câu hỏi. Với đồ thị quy mô lớn, độ rộng mở rộng k-hop, bộ lọc quan hệ, bộ nhớ đệm và bản tóm tắt tính sẵn quyết định độ trễ, nên phải đo đồng thời độ chính xác và thời gian phản hồi.

E. Tổ chức·quản trị

Làm rõ trách nhiệm của chủ sở hữu schema đồ thị, người rà soát theo miền, người quản lý dữ liệu và người vận hành dịch vụ AI. Khi thêm loại quan hệ mới, lập tài liệu định nghĩa·ví dụ·trường hợp cấm·tiêu chí chất lượng, và đưa thay đổi mô hình hay prompt vào quản lý cấu hình và thủ tục phê duyệt đánh giá. Từ góc độ Kỹ sư chuyên nghiệp (Professional Engineer), không nên xem GraphRAG như một tính năng chatbot đơn thuần mà phải đánh giá như một kiến trúc tin học hóa kết nối quản trị dữ liệu, quản lý tri thức, bảo mật và MLOps.

Tài liệu tham khảo

Tóm tắt một câu: GraphRAG là kiến trúc mở rộng RAG kết hợp thực thể·quan hệ·tóm tắt cộng đồng với truy xuất lai để hỗ trợ suy luận multi-hop giữa các tài liệu và truy vấn toàn cục trên toàn bộ dữ liệu, và chìa khóa để áp dụng thành công nằm ở việc vận hành đồng thời nguồn gốc·quyền·tính cập nhật·đánh giá hơn là bản thân đồ thị.