Mô hình kiến trúc Graph-enhanced RAG: Giải pháp vượt trội hơn tìm kiếm vector truyền thống

Retrieval-augmented generation (RAG) đã trở thành tiêu chuẩn thực tế để neo các mô hình ngôn ngữ lớn (LLM) vào dữ liệu riêng tư. Kiến trúc tiêu chuẩn — chia nhỏ tài liệu, nhúng chúng vào cơ sở dữ liệu vector và truy xuất kết quả top-k thông qua độ tương đồng cosin — rất hiệu quả cho tìm kiếm ngữ nghĩa phi cấu trúc.

Tuy nhiên, đối với các lĩnh vực doanh nghiệp có đặc điểm là dữ liệu có tính liên kết cao (chuỗi cung ứng, tuân thủ tài chính, phát hiện gian lận), RAG chỉ dùng vector thường thất bại. Nó nắm bắt được sự tương đồng nhưng lại bỏ lỡ cấu trúc. Nó gặp khó khăn với các câu hỏi lý luận đa bước (multi-hop reasoning) như: "Sự chậm trễ của Linh kiện X sẽ ảnh hưởng thế nào đến mục tiêu giao hàng Quý 3 cho Khách hàng Y?" vì kho vector không "biết" rằng Linh kiện X là một phần của mục tiêu giao hàng của Khách hàng Y.

Bài viết này sẽ khám phá mô hình RAG tăng cường bằng đồ thị (graph-enhanced RAG). Kéo từ kinh nghiệm xây dựng hệ thống ghi log thông lượng cao tại Meta và cơ sở hạ tầng dữ liệu riêng tư tại Cognee, chúng tôi sẽ đi qua một kiến trúc tham khảo kết hợp tính linh hoạt về ngữ nghĩa của tìm kiếm vector với tính xác định về cấu trúc của cơ sở dữ liệu đồ thị.

Vấn đề: Khi tìm kiếm vector mất ngữ cảnh

Cơ sở dữ liệu vector xuất sắc trong việc nắm bắt ý nghĩa nhưng lại loại bỏ cấu trúc liên kết (topology). Khi một tài liệu được chia nhỏ và nhúng, các mối quan hệ rõ ràng (thứ bậc, sự phụ thuộc, quyền sở hữu) thường bị làm phẳng hoặc mất hoàn toàn.

Hãy xem xét một kịch bản rủi ro chuỗi cung ứng. Mặc dù đây là một ví dụ giả định, nó đại diện cho chính xác lớp vấn đề cấu trúc mà chúng ta thường thấy trong kiến trúc dữ liệu doanh nghiệp:

• Dữ liệu có cấu trúc: Một cơ sở dữ liệu SQL xác định rằng Nhà cung cấp A cung cấp Linh kiện X cho Nhà máy Y.
• Dữ liệu phi cấu trúc: Một bản tin báo cáo nêu rằng: "Lũ lụt tại Thái Lan đã ngừng sản xuất tại cơ sở của Nhà cung cấp A."

Một tìm kiếm vector tiêu chuẩn cho "rủi ro sản xuất" sẽ truy xuất bản tin đó. Tuy nhiên, nó có thể thiếu ngữ cảnh để liên kết bản tin đó với đầu ra của Nhà máy Y. LLM nhận được bản tin nhưng không thể trả lời câu hỏi kinh doanh quan trọng: "Những nhà máy hạ nguồn nào đang gặp rủi ro?"

Trong môi trường sản xuất (production), điều này biểu hiện dưới dạng ảo giác (hallucination). LLM cố gắng thu hẹp khoảng cách giữa bản tin và nhà máy nhưng thiếu liên kết rõ ràng, dẫn đến việc nó đoán mối quan hệ hoặc trả lời "Tôi không biết" mặc dù dữ liệu có mặt trong hệ thống.

Mô hình: Truy xuất kết hợp (Hybrid Retrieval)

Để giải quyết vấn đề này, chúng ta chuyển từ kiến trúc "Flat RAG" sang "Graph RAG". Điều này liên quan đến một ngăn xếp gồm ba lớp:

1. Tiếp nhận (Bài học từ "Meta"): Tại Meta, khi làm việc trên cơ sở hạ tầng ghi log cho Shops, chúng tôi đã học được rằng cấu trúc phải được áp dụng ở khâu tiếp nhận. Bạn không thể đảm bảo phân tích đáng tin cậy nếu cố gắng tái tạo cấu trúc từ các log lộn xộn sau này. Tương tự, trong RAG, chúng ta phải trích xuất thực thể (nodes) và mối quan hệ (edges) trong quá trình tiếp nhận. Chúng ta có thể sử dụng LLM hoặc mô hình nhận dạng thực thể được đặt tên (NER) để trích xuất thực thể từ các đoạn văn bản và liên kết chúng với các bản ghi hiện có trong đồ thị.
2. Lưu trữ: Chúng ta sử dụng cơ sở dữ liệu đồ thị (như Neo4j) để lưu trữ đồ thị cấu trúc. Các nhúng vector được lưu trữ dưới dạng thuộc tính trên các nút cụ thể (ví dụ: nút RiskEvent).
3. Truy xuất: Chúng ta thực hiện truy vấn kết hợp:
   • Quét vector: Tìm các điểm nhập vào đồ thị dựa trên sự tương đồng ngữ nghĩa.
   • Duyệt đồ thị: Duyệt các mối quan hệ từ các điểm nhập đó để thu thập ngữ cảnh.

Triển khai tham khảo

Hãy xây dựng một triển khai đơn giản hóa của trình phân tích rủi ro chuỗi cung ứng này bằng Python, Neo4j và OpenAI.

1. Mô hình hóa đồ thị

Chúng ta cần một lược đồ kết nối các "sự kiện rủi ro" phi cấu trúc của mình với các thực thể "chuỗi cung ứng" có cấu trúc.

2. Tiếp nhận: Liên kết cấu trúc và ngữ nghĩa

Trong bước này, chúng ta giả định rằng đồ thị cấu trúc (nhà cung cấp -> nhà máy) đã tồn tại. Chúng ta tiếp nhận một "sự kiện rủi ro" phi cấu trúc mới và liên kết nó với đồ thị.

3. Truy vấn truy xuất kết hợp

Đây là điểm khác biệt cốt lõi. Thay vì chỉ trả về các đoạn văn bản top-k, chúng ta sử dụng Cypher để thực hiện tìm kiếm vector nhằm tìm sự kiện, sau đó duyệt để tìm tác động hạ nguồn.

Đầu ra: Thay vì một đoạn văn bản chung chung, LLM nhận được một tải trọng có cấu trúc:

[{'issue': 'Lũ lụt nghiêm trọng...', 'impacted_supplier': 'TechChip Inc', 'risk_to_factory': 'Assembly Plant Alpha'}]

Điều này cho phép LLM tạo ra một câu trả lời chính xác: "Lũ lụt tại TechChip Inc đang đặt Assembly Plant Alpha vào tình trạng rủi ro."

Bài học sản xuất: Độ trễ và tính nhất quán

Chuyển đổi kiến trúc này từ notebook sang môi trường sản xuất đòi hỏi phải xử lý các sự đánh đổi.

1. Thuế độ trễ (The latency tax)

Việc duyệt đồ thị tốn kém hơn nhiều so với tra cứu vector đơn giản. Trong công việc của tôi về thử nghiệm hình ảnh sản phẩm tại Meta, chúng tôi phải đối mặt với các ngân sách độ trễ nghiêm ngặt nơi mỗi mili-giây đều ảnh hưởng đến trải nghiệm người dùng. Mặc dù lĩnh vực khác nhau, bài học kiến trúc này áp dụng trực tiếp cho Graph RAG: Bạn không thể tính toán mọi thứ theo thời gian thực.

• RAG chỉ dùng vector: Thời gian truy xuất ~50-100ms.
• RAG tăng cường đồ thị: Thời gian truy xuất ~200-500ms (tùy thuộc vào độ sâu nhảy).

Giảm thiểu: Chúng ta sử dụng bộ nhớ đệm ngữ nghĩa (semantic caching). Nếu người dùng hỏi một câu hỏi tương tự (độ tương đồng cosin > 0,85) với một truy vấn trước đó, chúng ta phục vụ kết quả đồ thị đã được lưu trong bộ nhớ đệm. Điều này làm giảm "thuế đồ thị" cho các truy vấn phổ biến.

2. Vấn đề "cạnh cũ" (stale edge)

Trong cơ sở dữ liệu vector, dữ liệu độc lập. Trong một đồ thị, dữ liệu phụ thuộc lẫn nhau. Nếu Nhà cung cấp A ngừng cung cấp cho Nhà máy Y, nhưng cạnh vẫn còn trong đồ thị, hệ thống RAG sẽ tự tin ảo giác về một mối quan hệ không còn tồn tại.

Giảm thiểu: Các mối quan hệ đồ thị phải có Time-To-Live (TTL) hoặc được đồng bộ hóa qua các đường ống Change Data Capture (CDC) từ nguồn sự thật (hệ thống ERP).

Khung quyết định cơ sở hạ tầng

Bạn có nên áp dụng Graph RAG không? Đây là khung mà chúng tôi sử dụng tại Cognee:

Sử dụng RAG chỉ dùng vector nếu:

• Kho tài liệu phẳng (ví dụ: một Wiki lộn xộn hoặc bản đổ dữ liệu Slack).
• Câu hỏi mang tính chung chung ("Làm cách nào để đặt lại VPN của tôi?").
• Độ trễ < 200ms là yêu cầu bắt buộc.

Sử dụng RAG tăng cường đồ thị nếu:

• Lĩnh vực được quản lý (tài chính, y tế).
• Cần "khả năng giải thích" (bạn cần hiển thị đường dẫn duyệt).
• Câu trả lời phụ thuộc vào các mối quan hệ đa bước ("Các công ty con gián tiếp nào bị ảnh hưởng?").

Kết luận

RAG tăng cường đồ thị không phải là sự thay thế cho tìm kiếm vector, mà là một sự tiến hóa cần thiết cho các lĩnh vực phức tạp. Bằng cách coi cơ sở hạ tầng của bạn như một đồ thị tri thức, bạn cung cấp cho LLM một thứ mà nó không thể ảo giác: Sự thật về cấu trúc kinh doanh của bạn.

Daulet Amirkhanov là kỹ sư phần mềm tại UseBead.