Hệ thống AI không thất bại vì mô hình yếu, mà thất bại vì ngữ cảnh sai. Nghiên cứu gần đây về retrieval-augmented generation cho thấy khi hệ thống RAG ảo giác, nguyên nhân gốc rễ thường là ngữ cảnh truy xuất không đủ, thiếu hoặc không liên quan, không phải mô hình ngôn ngữ. Khi bộ truy xuất thất bại, ngay cả LLM tốt nhất cũng sẽ tự tin tạo ra câu trả lời sai.
Đây không phải là lỗi, mà là do cách các hệ thống RAG được thiết kế. Đa số stack RAG hiện nay xử lý kiến thức như công cụ tìm kiếm, tìm văn bản gần nhất và đưa cho mô hình, hy vọng nó sẽ hoạt động. Cách này hiệu quả với các câu hỏi như:
- “Thời gian lưu trữ dữ liệu khách hàng của chúng ta là bao lâu?”
- “Tài liệu hướng dẫn onboard cho đối tác mới ở đâu?”
Tuy nhiên, nó thất bại khi bạn hỏi:
- “Khách hàng nào phải bị xóa nếu chúng ta ngừng cung cấp Product A tại Đức?”
- “Dịch vụ, pipeline dữ liệu và hợp lệ phụ thuộc vào API này là gì?”
Đây không phải là vấn đề tìm kiếm, mà là vấn đề mối quan hệ. Đây là lý do tại sao lựa chọn kiến trúc thực sự trong RAG không phải là: Nên sử dụng LLM nào? Mà là: Hệ thống của tôi nên truy xuất văn bản bằng sự tương đồng, hay truy xuất ý nghĩa thông qua mối quan hệ?
Đây là ranh giới để hiểu sự khác biệt giữa cơ sở dữ liệu vector và cơ sở dữ liệu đồ thị cho RAG.
Cách RAG hoạt động như thế nào?
Stack RAG mặc trông hoàn hảo trên slide khi tài liệu đi qua quá trình chunking, biến thành embedding, lưu trong cơ sở dữ liệu vector, tìm kiếm bằng sự tương đồng, và cuối cùng được chuyển cho LLM. Nó cảm thấy hiện đại, có khả năng mở rộng và dễ triển khai. Và thật sự, với nhiều đội nhóm, nó hoạt động đủ tốt để triển khai điều gì đó.
Đây là phần không thoải mái vì nó hoạt động đủ tốt khiến mọi người ngừng đặt câu hỏi.
Bên dưới, toàn bộ hệ thống này đang làm một việc đơn giản hơn nhiều so với vẻ ngoài. Nó không trả lời câu hỏi. Nó đang xếp hạng văn bản. Ở cốt lõi, một pipeline RAG tồn tại để trả lời một điều: đoạn văn bản nào trông giống với prompt này nhất? Mọi thứ khác, bao gồm chất lượng câu trả lời cuối cùng, phụ thuộc vào bạn may mắn đến đâu với việc xếp hạng đó.
Chunking không trích xuất ý nghĩa. Nó chỉ chia tài liệu thành các cửa sổ.
Embedding không mô hình hóa kiến thức mà biến những cửa sổ đó thành tọa độ trong không gian chiều cao cao.
Tìm kiếm vector không truy xuất sự thật mà tìm các láng giền gần nhất trong không gian đó. Vì vậy, mô hình nhận được không phải là sự thật mà là văn bản tình cờ ở gần đó.
Điều này ổn khi câu trả lời đã tồn tại dưới dạng một đoạn văn sạch sẽ ở đâu đó. Sổ tay hướng dẫn, hướng dẫn cấu hình, tài liệu onboard. Bạn gõ một câu hỏi, nó tìm thấy trang đúng, và trông ấn tượng. Nhưng ngay khi câu trả lời nằm trên nhiều hệ thống, mọi thứ bắt đầu nứt vỡ.
Nếu bạn hỏi một thứ như, “Dịch vụ nào sẽ bị ảnh hưởng nếu API này thay đổi?” Không có chunk nào đơn lẻ chứa câu trả lời đó. Nó trải rộng trên tài liệu thiết kế, đồ lệ thuộc sở hữu, và siêu dữ liệu sản xuất. Một cơ sở dữ liệu vector sẽ trả về một vài mảnh trông liên quan. LLM sẽ cố gắn ghép chúng lại với nhau. Đôi khi nó làm đúng. Đôi khi nó nghe đúng nhưng hoàn toàn sai.
Đây chính xác là điểm mô hình bắt đầu tự tạo ra thứ, và ảo giác LLM ra đời. Không phải vì mô hình bị hỏng, mà vì tầng truy xuất đã cho nó các mảnh thay vì cấu trúc. Đó là nơi RAG vượt từ tìm kiếm vào việc bắt chước lý luận, và điểm mà hầu hết hệ thống RAG âm thầm tan rã.
Cơ sở dữ liệu Vector: Truy xuất bằng Tương đồng
Cơ sở dữ liệu vector xử lý kiến thức như hình học. Mỗi chunk tài liệu trở thành một điểm trong không gian chiều cao cao, mỗi truy vấn trở thành một điểm khác trong cùng không gian đó, và truy xuất chỉ là tìm kiếm láng giền gần nhất giữa các điểm đó.
Thiết kế này cực kỳ mạnh mẽ vì cho phép bạn truy xuất thông tin dựa trên ý nghĩa thay vì từ khóa. Hai đoạn văn sử dụng từ khác nhau nhưng mô tả cùng một thứ kết thúc ở gần nhau. Đây là lý do tại sao tìm kiếm vector cảm thấy kỳ diệu so với tìm kiếm từ khóa. Nhưng điều quan trọng là hiểu nó đang làm gì. Nó không truy xuất sự thật, mà truy xuất văn bản tình cờ có ý nghĩa tương tự.
Các chunk được embed, và các truy vấn được embed. Tuy nhiên, hệ thống tìm các chunk có vector nằm gần nhất với vector truy vấn. Điều này hoạt động cực kỳ tốt khi ý định người dùng ánh xạ sạch sẽ đến một mảng thông tin được viết riêng, như:
- Cách một API cụ thể hoạt động
- Chính sách nói gì
- Cấu hình nằm ở đâu
Trong các trường hợp này, câu trả lời đã tồn tại ở dạng đoạn văn ở đâu đó. Công việc duy nhất của hệ thống là tìm nó. Tìm kiếm vector rất tốt ở việc đó. Nó biến bộ sưu tập tài liệu thành thứ hành động như công cụ tìm kiếm ngữ nghĩa.
Tại sao Vector RAG thất bại?
Chế độ thất bại xuất hiện ngay khi một câu hỏi ngừng là tra cứu và trở thành thành phần. Nếu bạn hỏi nó một thứ như:
“Giao dịch khách hàng nào phải bị xóa nếu chúng ta ngừng dịch vụ thanh toán EU?”
Không có đoạn văn đơn lẻ nào trả lời điều này. Câu trả lời nằm trong:
- Chính sách lưu trữ dữ liệu
- Quy định tài chính khu vực
- Hợp đồng với nhà xử lý thanh toán
- Vị trí lưu trữ dữ liệu
- Bản ánh xạ tài khoản khách hàng
Những mảnh đó tồn tại trong tài liệu khác nhau, được viết bởi các đội nhóm khác nhau, với ngôn ngữ và ý định khác nhau. Một cơ sở dữ liệu vector vẫn sẽ làm chính xác những nó được thiết kế để làm. Nó sẽ trả về các chunk trông liên quan:
- Một số văn bản tuân thủ nhà xử lý thanh toán
- Một số chính sách lưu trữ dữ liệu EU
- Một số hướng dẫn xóa tài khoản nội bộ
Bây giờ LLM bị buộc phải làm thứ nó không bao giờ được thiết kế để làm ở quy mô: kết nối chúng. Nó phải đoán cách quy tắc lưu trữ EU tương tác với quy định thanh toán. Nó phải suy luận cách hợp đồng xử lý ánh xạ đến quy trình xóa nội bộ. Nó phải ghép lại một quyết định tuân thủ từ tài liệu không liên quan. Đây không phải là truy xuất mà làsự ứng biến, dẫn đến những lỗi nghe có vẻ tự tin vì lớp truy xuất đã cung cấp cho nó văn bản tương tự thay vì kiến thức có cấu trúc.
Tìm kiếm vectơ có thể cho bạn biết những gì trông có vẻ liên quan, nhưng nó không thể cho bạn biết những gì thực sự được kết nối. Sự khác biệt này chính là điều phân biệt một hệ thống tìm kiếm với một hệ thống suy luận.
Cơ sở dữ liệu đồ thị: Truy xuất theo ý nghĩa
Cơ sở dữ liệu đồ thị không lưu trữ văn bản mà lưu trữ các mối quan hệ. Thay vì lưu các đoạn văn, chúng lưu trữ các sự kiện về cách các thành phần kết nối với nhau. Một đồ thị phụ thuộc hệ thống không nói rằng, “Đây là tài liệu về Dịch vụ A.” Nó lưu trữ:
Dịch vụ A → phụ thuộc vào → Cơ sở dữ liệu B
Cơ sở dữ liệu B → được lưu trữ tại → Khu vực EU
Khu vực EU → được quản lý bởi → GDPR
Dịch vụ A → xử lý → Thông tin nhận dạng cá nhân của khách hàng
Bây giờ hãy hỏi: “Những dịch vụ nào phải tuân thủ GDPR?” Hệ thống không quét các tài liệu chính sách, mà nó duyệt qua biểu đồ. Nó theo dõi:
• các dịch vụ xử lý dữ liệu khách hàng
• các cơ sở dữ liệu mà chúng phụ thuộc vào
• các khu vực nơi dữ liệu đó được lưu trữ
• các quy định liên quan đến các khu vực đó
Những kết nối đó đã tồn tại dưới dạng các cạnh trong hệ thống, và đây không phải là các câu mà là các mối quan hệ giữa các thực thể. Từ quá trình duyệt đó, hệ thống trích xuất một đồ thị con cho thấy chính xác những dịch vụ nào truy cập dữ liệu của EU và luật nào áp dụng cho chúng. Đồ thị con này giờ đây trở thành ngữ cảnh được truyền đến LLM. Nó không phải là văn bản mà là cấu trúc.
Đây không phải là việc truy xuất theo nghĩa của công cụ tìm kiếm, mà là suy luận tại thời điểm truy vấn trên một mô hình hoạt động thực tế của doanh nghiệp.
Tại sao điều này lại thay đổi mọi thứ đối với RAG Systems?
Vector RAG cung cấp bộ nhớ cho mô hình, trong khi Graph RAG cung cấp cấu trúc cho mô hình. Bộ nhớ trả lời câu hỏi: “Âm thanh này nghe như thế nào?” Cấu trúc trả lời câu hỏi: “Những thứ này liên quan đến nhau như thế nào?” Sự khác biệt này quyết định loại câu hỏi mà hệ thống có thể xử lý. Bot hỗ trợ chủ yếu cần bộ nhớ, nhưng chúng trả lời các câu hỏi riêng lẻ, có thể được giải thích rõ ràng bằng văn bản.
Các hệ thống y tế, pháp lý và doanh nghiệp cần có cấu trúc, nhưng chúng phải thực thi các ràng buộc, tuân theo các mối quan hệ phụ thuộc và tôn trọng các mối quan hệ không bao giờ được ghi chép lại ở một nơi duy nhất. Đây là lý do tại sao:
• hệ thống trò chuyện dựa trên vectơ
• hệ thống chăm sóc sức khỏe dựa trên đồ thị
• công cụ tuân thủ dựa trên đồ thị
• nền tảng kiến trúc dựa trên đồ thị
Một hệ thống tập trung vào trích xuất văn bản, hệ thống kia trích xuất ý nghĩa. Khoảng cách này là lý do tại sao một số hệ thống AI mang lại cảm giác hữu ích, trong khi những hệ thống khác lại mang lại cảm giác an toàn khi vận hành trong môi trường sản xuất.
Sự khác biệt giữa cơ sở dữ liệu vector và cơ sở dữ liệu đồ thị
Như chúng ta đã thấy ở trên, cơ sở dữ liệu vector và cơ sở dữ liệu đồ thị giải quyết hai vấn đề rất khác nhau trong RAG, mặc dù chúng thường được nhóm lại với nhau. Cơ sở dữ liệu vector lưu trữ các vector nhúng của các đoạn tài liệu và truy xuất văn bản trông tương tự với truy vấn của bạn bằng cách sử dụng tìm kiếm lân cận gần nhất. Điều này làm cho nó rất hữu ích để tìm các đoạn văn liên quan trong tài liệu, câu hỏi thường gặp hoặc cơ sở mã. Nhưng những gì LLM trả về vẫn chỉ là các đoạn văn và câu. Khi các câu hỏi trải rộng trên nhiều hệ thống hoặc cần nhiều hơn một bước suy luận, mô hình buộc phải đoán cách mọi thứ kết nối với nhau, đó là lý do tại sao các hệ thống RAG chỉ sử dụng vector có xu hướng trả về các đoạn văn rời rạc và đưa ra kết luận sai khi câu trả lời không nằm trong một khối văn bản hoàn chỉnh.
Cơ sở dữ liệu đồ thị hoạt động theo cách ngược lại. Thay vì lưu trữ các đoạn văn bản, nó lưu trữ các thực thể, thuộc tính của chúng và cách chúng liên quan đến nhau, và việc truy xuất trả về một đồ thị con được kết nối của các sự kiện. LLM không còn suy luận cấu trúc từ văn bản thô nữa. Nó được cung cấp một cấu trúc đã tồn tại. Đây là lý do tại sao RAG dựa trên đồ thị nổi bật trong việc tuân thủ, phụ thuộc và các hoạt động mà bạn cần giải thích cách mọi thứ được kết nối và tại sao một điều gì đó xảy ra. Nó mở rộng theo số lượng thực thể và cạnh chứ không phải theo các đoạn văn bản, luôn được cập nhật khi đồ thị được cập nhật và gặp lỗi theo những cách dễ dự đoán hơn bằng cách trả về các mối quan hệ không đầy đủ thay vì các câu trả lời gây hiểu nhầm.
Bảng dưới đây thể hiện rõ sự khác biệt giữa cơ sở dữ liệu vector và cơ sở dữ liệu đồ thị về lưu trữ, truy xuất, suy luận và độ tin cậy trong hệ thống RAG –
Cơ sở dữ liệu vector so với cơ sở dữ liệu đồ thị cho RAG – Kiến trúc nào tối ưu hơn?
Các hệ thống RAG mạnh nhất không lựa chọn giữa dữ liệu vector và dữ liệu đồ thị, mà đặt mỗi loại vào lớp phù hợp nhất với khả năng của nó. Cơ sở dữ liệu vector được sử dụng để xác định những gì có thể quan trọng, trong khi cơ sở dữ liệu đồ thị được sử dụng để xác định cách những thứ đó kết nối với nhau. LLM lập luận dựa trên kết quả.
Quy trình diễn ra như sau:
i. Tìm kiếm vectơ giúp xác định các thực thể liên quan.
ii. Duyệt đồ thị mở rộng các phụ thuộc, ràng buộc và mối quan hệ của chúng.
iii. Mô hình LLM hoạt động trên một cái nhìn có cấu trúc về hệ thống thay vì văn bản thô.
Đây là cách các trợ lý phi công hiện đại điều hướng các cơ sở mã lớn, các hệ thống tuân thủ tránh áp dụng sai quy tắc và các hệ thống AI doanh nghiệp đưa ra các câu trả lời có thể đứng vững trước sự kiểm tra nghiêm ngặt. Các vectơ tìm ra điểm mấu chốt, và các biểu đồ giải thích tại sao chúng lại quan trọng.
Một hệ thống RAG chỉ truy xuất văn bản sẽ luôn dễ bị lỗi. Nó chỉ hoạt động khi một câu hỏi liên quan đến nhiều hơn một tài liệu. Một hệ thống RAG truy xuất cả các mối quan hệ có thể hoạt động tốt trong môi trường kinh doanh thực tế. Hầu hết các nhóm đang xây dựng công cụ tìm kiếm tốt hơn, nhưng những nhóm chiến thắng đang xây dựng các hệ thống tri thức.
Tham khảo: medium.com
Bài viết liên quan: