Graph RAG đáng để triển khai khi quan hệ giữa các dữ kiện cũng là một phần của bằng chứng. Tìm kiếm vectơ vẫn cần thiết để tìm tài liệu và bản ghi liên quan, nhưng mức độ tương đồng không thể chứng minh vì sao một dữ kiện áp dụng cho dữ kiện khác. Đồ thị bổ sung đường liên kết có thể kiểm tra giữa các thực thể, chẳng hạn thư viện, phiên bản dịch vụ, khách hàng và hợp đồng.
Đội nào sở hữu dịch vụ đang phụ thuộc vào thư viện có lỗ hổng? Những khách hàng nào sử dụng dịch vụ đó, và hợp đồng của từng khách hàng yêu cầu doanh nghiệp thông báo điều gì? Theo The New Stack về thời điểm nên dùng Graph RAG, tìm kiếm vectơ có thể trả về khuyến cáo bảo mật, mô tả dịch vụ, trang ghi nhận quyền sở hữu và chính sách thông báo. Từng kết quả đều có thể liên quan, nhưng vẫn chưa đủ để chứng minh chúng thuộc cùng một chuỗi sự kiện.
Bằng chứng còn thiếu nằm trong các mối liên hệ. Một phiên bản cụ thể của dịch vụ sử dụng thư viện có lỗ hổng. Dịch vụ đó hỗ trợ môi trường của một khách hàng cụ thể. Hợp đồng đang có hiệu lực với khách hàng ấy quy định thời hạn thông báo. Nếu tác tử tự suy diễn chuỗi này từ vài đoạn văn tương tự nhau, nó có thể nối nhầm dữ kiện thuộc các dịch vụ, phiên bản hoặc khách hàng khác nhau.
Truy xuất vectơ phù hợp với trường hợp nào?
Truy xuất vectơ phù hợp khi câu trả lời nằm trong một hoặc hai đoạn văn và không phụ thuộc vào đường liên kết qua nhiều bản ghi nghiệp vụ. Nó tìm văn bản hoặc bản ghi có ý nghĩa gần với câu hỏi, ngay cả khi câu hỏi và nguồn dùng từ khác nhau.
Truy vấn về việc chấm dứt gói đăng ký có thể tìm thấy bài hỗ trợ nói về hủy tài khoản. Câu hỏi về loại bỏ dữ liệu khỏi bộ nhớ có thể dẫn đến một tài liệu dùng khái niệm cắt giảm ngữ cảnh.
Vì vậy, tìm kiếm vectơ là lựa chọn mặc định phù hợp cho nhiều ứng dụng RAG. Tài liệu kỹ thuật, bài hỗ trợ, mô tả sản phẩm và các nguồn tri thức phi cấu trúc thường chứa câu trả lời trong một hoặc hai đoạn. Dữ liệu chủ yếu là văn bản, phạm vi câu hỏi có giới hạn và ứng dụng không phải chứng minh một đường liên kết qua nhiều bản ghi nghiệp vụ.
Giới hạn của điểm tương đồng
Mức độ tương đồng chỉ nên xếp hạng bằng chứng có khả năng liên quan. Nó không xác lập quyền sở hữu, quan hệ phụ thuộc, quyền truy cập hay phạm vi áp dụng của chính sách. Hai bản ghi có thể gần nhau về ngữ nghĩa nhưng không có liên hệ vận hành. Ngược lại, hai bản ghi có thể liên kết trực tiếp dù gần như không dùng chung từ ngữ.
Ràng buộc siêu dữ liệu phải được thực thi độc lập với thứ hạng vectơ. Điểm tương đồng đánh giá mức độ liên quan, còn ranh giới đối tượng thuê, ngày hiệu lực và mã tài khoản là điều kiện bắt buộc của hệ thống. Nguyên tắc này cũng phù hợp với cách AI bảo mật phân chia quyền truy cập dữ liệu và mô hình, nơi quyền hạn không thể được thay bằng một gợi ý ngôn ngữ.
Những câu hỏi nào phụ thuộc vào quan hệ?
Một câu hỏi phụ thuộc vào quan hệ khi câu trả lời phải nối nhiều thực thể hoặc chứng minh vì sao một bản ghi áp dụng cho bản ghi khác. Trường hợp này thường xuất hiện khi tác tử phải lần theo dữ liệu từ nhiều hệ thống có liên kết.
- Dịch vụ nào phụ thuộc vào thành phần này?
- Ai có quyền phê duyệt ngoại lệ cho tài khoản này?
- Khách hàng nào chịu ảnh hưởng từ đợt triển khai này?
- Biện pháp kiểm soát nào áp dụng cho dữ liệu trong môi trường này?
Một chuỗi quan hệ trong xử lý lỗ hổng
Trong ví dụ về lỗ hổng, khuyến cáo của gói phần mềm xác định thư viện. Bản ghi triển khai cho biết dịch vụ sử dụng thư viện đó. Danh mục dịch vụ nối dịch vụ với môi trường khách hàng. Bản ghi hợp đồng nối khách hàng với chính sách thông báo. The New Stack mô tả câu trả lời này cần bốn bản ghi và ba mối quan hệ giữa chúng.
Văn bản có thể mô tả từng bước, nhưng tác tử tự lắp ghép chuỗi có thể nối thư viện bị ảnh hưởng với sai phiên bản dịch vụ hoặc gắn một dịch vụ dùng chung với sai khách hàng. Nó cũng có thể lấy một chính sách đã hết hạn vào tháng trước, hoặc bỏ qua quan hệ phụ thuộc vừa được cập nhật trong danh mục dịch vụ sau khi tài liệu được phát hành.
Đồ thị biến mỗi bản ghi thành một nút và biểu diễn kết nối bằng cạnh có kiểu, có hướng. Một cạnh có thể ghi nhận dịch vụ sử dụng thư viện, dịch vụ hỗ trợ môi trường hoặc hợp đồng chịu sự điều chỉnh của chính sách nào. Mỗi kết nối cần giữ nguồn và đơn vị sở hữu. Điểm tin cậy hoặc ngày hiệu lực có thể được thêm khi câu hỏi cần đến chúng.
Chỉ nên bắt đầu với những loại quan hệ phục vụ một câu hỏi quan trọng. Lập bản đồ toàn bộ doanh nghiệp là một công việc dài nhưng không bảo đảm tạo ra kết quả hữu ích.
Graph RAG bổ sung bằng chứng quan hệ như thế nào?
Graph RAG bổ sung đường liên kết có thể kiểm tra giữa các bản ghi mà truy xuất vectơ tìm thấy. Đồ thị cho biết dữ kiện nào được kết nối, còn tài liệu nguồn cho biết chính sách hoặc nội dung liên quan quy định điều gì.
Graph RAG được dùng với nhiều nghĩa. GraphRAG của Microsoft dùng mô hình ngôn ngữ lớn để trích xuất đồ thị tri thức từ văn bản phi cấu trúc, xây dựng hệ thống phân cấp cộng đồng và hỗ trợ cả truy vấn toàn kho lẫn truy vấn tập trung vào thực thể. Cách tiếp cận trong bài này hẹp hơn: đồ thị được xây từ những quan hệ mà hệ thống vận hành đã ghi nhận, trong đó mỗi cạnh đều truy ngược được về nguồn nghiệp vụ thay vì do mô hình suy diễn từ tài liệu.
Một quy trình thực tế bắt đầu bằng việc tìm các thực thể và đoạn văn có khả năng liên quan đến câu hỏi. Ứng dụng đối chiếu chúng với bản ghi cụ thể, chỉ đi theo những quan hệ được phép, rồi truy xuất tài liệu nguồn cần thiết để giải thích kết quả.
Đối chiếu đúng thực thể
Đối chiếu thực thể là phần khó nhất. Nếu người dùng hỏi về dịch vụ thanh toán trong khi danh mục có ba dịch vụ mang tên gần giống nhau, hệ thống phải chọn đúng bản ghi. Một kết quả ghép sai có thể ảnh hưởng đến mọi bước tiếp theo. Khi không thể phân giải rõ ràng, ứng dụng nên hiển thị các ứng viên thay vì tự chọn cái tên gần nhất.
Đường đi từ khách hàng đến hợp đồng không tự chứa điều khoản thông báo, trừ khi điều khoản đã được mô hình hóa trong đồ thị. Sao chép toàn bộ nội dung tài liệu vào đồ thị lại tạo thêm một phiên bản dữ liệu phải duy trì. Vì vậy, hệ thống cần cả quan hệ trong đồ thị lẫn nội dung từ tài liệu nguồn.
Giới hạn đường đi và xử lý cạnh bị thiếu
Việc duyệt đồ thị phải có giới hạn rõ ràng. Hệ thống cần xác định loại cạnh được phép đi qua, số bước tối đa, ranh giới đối tượng thuê hoặc tài khoản, độ mới cần thiết của từng kết nối và mức tin cậy chấp nhận được. Các giới hạn này phải trở thành ràng buộc truy vấn và kiểm soát truy cập trước khi kết quả đến mô hình, không chỉ là lời nhắc trong câu lệnh.
Cạnh bị thiếu cũng là một kết quả cần báo cáo. Nếu dịch vụ không có chủ sở hữu được ghi nhận, hoặc hai bản ghi bất đồng về hợp đồng đang có hiệu lực, tác tử không nên tự suy ra đường đi giữa những dữ kiện còn lại. Câu trả lời rằng hệ thống xác định được dịch vụ bị ảnh hưởng nhưng chưa thể xác minh chủ sở hữu hiện tại vẫn có giá trị. Trong một sự cố, kết luận thiếu căn cứ có thể khiến thông báo được gửi nhầm khách hàng.
Đồ thị cần có đơn vị sở hữu, quy trình cập nhật và quy tắc truy cập giữ được dấu vết nguồn cho hoạt động kiểm toán. Nếu thiếu các yếu tố này, những giả định chưa được ghi nhận có thể xuất hiện dưới dạng cạnh trông như dữ liệu có thẩm quyền.
Vì sao nên giữ đồ thị gần dữ liệu vận hành?
Giữ đồ thị gần dữ liệu vận hành giúp giảm độ trễ cập nhật và tránh tạo thêm một bản sao với mô hình phân quyền riêng. Điều này đặc biệt quan trọng khi quan hệ đã tồn tại trong bảng dữ liệu quan hệ và phải phản ánh trạng thái hiện hành trong quá trình điều tra.
Khóa ngoại nối dịch vụ với đội phụ trách. Bảng triển khai nối phiên bản dịch vụ với môi trường. Bảng quyền lợi nối khách hàng với sản phẩm. Sao chép các dữ kiện này sang một hệ thống đồ thị riêng tạo ra độ trễ cập nhật và thêm một mô hình phân quyền. Khi điều tra sự cố, đội vận hành còn phải xác định bản sao nào đang cập nhật nhất.
Kết hợp đồ thị và vectơ gần dữ liệu gốc
Oracle AI Database là một lựa chọn khi tìm kiếm đồ thị và vectơ cần nằm gần các bản ghi quan hệ mà chúng phụ thuộc. Đồ thị thuộc tính SQL có thể được định nghĩa trên các bảng và khung nhìn hiện có, sau đó truy vấn bằng GRAPH_TABLE. Tìm kiếm vectơ bằng AI có thể xếp hạng văn bản liên quan trong cùng cơ sở dữ liệu. Ứng dụng nhờ đó có thể đối chiếu mẫu đồ thị với dữ liệu nghiệp vụ hiện hành rồi bổ sung truy xuất ngữ nghĩa, thay vì phải liên tục hòa giải dữ liệu giữa nhiều kho.
Quy tắc lựa chọn quan trọng hơn sản phẩm cơ sở dữ liệu cụ thể. Nền tảng phải cho phép đội ngũ xem chính xác đường đi mà tác tử đã dùng, đồng thời truy ngược từng nút và cạnh về nguồn theo cùng quy tắc truy cập đang bảo vệ bản ghi gốc. Nếu việc di chuyển quan hệ làm mất những thuộc tính này, bản sao khiến câu trả lời khó xác minh hơn.
Đây cũng là một phần của bài toán vận hành hạ tầng AI: dữ liệu, quyền truy cập và quy trình cập nhật phải được thiết kế cùng nhau thay vì ghép lại sau khi hệ thống đã chạy.
Khi nào nên chọn Graph RAG?
Nên chọn Graph RAG khi một câu hỏi lặp lại đòi hỏi hệ thống nối dữ kiện giữa nhiều thực thể, lần theo quan hệ phụ thuộc hoặc chứng minh vì sao một bản ghi áp dụng cho bản ghi khác. Nếu một tài liệu đã đủ trả lời câu hỏi, truy xuất vectơ thường là lựa chọn đơn giản hơn.
Các quyết định chịu chi phối bởi quyền sở hữu, quyền lợi, quan hệ phụ thuộc hoặc chính sách là những trường hợp phù hợp. Sự cố phát sinh do kết nối bị thiếu hoặc lỗi thời còn cho thấy điểm khởi đầu rõ hơn, vì hậu quả của một đường đi thiếu căn cứ đã được nhận diện.
Một kho tri thức khép kín thường không cần Graph RAG nếu một tài liệu đã đủ trả lời câu hỏi. Khi không có hệ thống vận hành nào sở hữu các mối quan hệ, xây đồ thị cũng không sửa được vấn đề dữ liệu gốc. Nó chỉ có thể che vấn đề phía sau một giao diện truy vấn thuận tiện hơn.
Thử nghiệm trên một quyết định cụ thể
Nên thử nghiệm với một quyết định cụ thể. Phân tích tác động là một trường hợp phù hợp: từ thay đổi của một thành phần, xác định dịch vụ và khách hàng bị ảnh hưởng, rồi dẫn ra các bản ghi chứng minh từng kết nối. Hỗ trợ theo quyền lợi là một trường hợp khác: xác định sản phẩm và chính sách áp dụng cho tài khoản trước khi truy xuất hướng dẫn hỗ trợ.
Quá trình đánh giá phải kiểm tra tác tử có phân giải đúng thực thể, đi theo quan hệ hiện hành trong ranh giới cho phép và lấy được tài liệu thực sự hỗ trợ câu trả lời hay không. Đường đi cần được đánh giá kỹ như phần văn bản được tạo ra, bởi một câu trả lời trôi chảy không cho thấy phép nối dữ liệu có bị thiếu hay không.
Nội dung tốt hơn cần bằng chứng tốt hơn
Đồ thị chỉ hữu ích khi cung cấp bằng chứng mà tác tử không thể truy xuất đáng tin cậy bằng cách khác. Điểm khởi đầu phù hợp là những quan hệ con người đang dùng để đưa ra quyết định, sau đó kiểm chứng xem việc biểu diễn rõ các kết nối đó có cải thiện kết quả hay không.
Truy xuất vectơ vẫn tìm được khuyến cáo bảo mật và nội dung hợp đồng. Đồ thị giải thích vì sao hai tài liệu ấy thuộc cùng một câu trả lời. Nếu tác tử không thể chỉ ra cả dữ kiện lẫn kết nối đứng sau kết luận, nó phải nói rõ phần nào vẫn chưa chắc chắn.
Nếu đang xây một hệ thống RAG, hãy chọn một quyết định có đường quan hệ rõ ràng và kiểm chứng toàn bộ đường đi trước khi mở rộng đồ thị.
