Nghiên cứu của Databricks: Tác nhân đa bước (Multi-step Agents) vượt trội RAG truyền thống khi xử lý dữ liệu hỗn hợp

Các nhóm dữ liệu xây dựng tác nhân AI thường gặp phải một lỗi phổ biến. Những câu hỏi yêu cầu kết hợp dữ liệu có cấu trúc (như số liệu bán hàng) với nội dung phi cấu trúc (như đánh giá khách hàng hoặc số lượng trích dẫn trong bài báo học thuật) thường khiến các hệ thống RAG (Retrieval-Augmented Generation) một lượt bị hỏng.

Nghiên cứu mới từ Databricks đã đo lường chính xác khoảng cách hiệu suất này. Đội ngũ nghiên cứu AI của công ty đã so sánh cách tiếp cận tác nhân đa bước với các hệ thống RAG một lượt hiện đại nhất trên chín nhiệm vụ kiến thức doanh nghiệp. Kết quả cho thấy hiệu suất tăng hơn 20% trên bộ chuẩn STaRK của Stanford và cải thiện nhất quán trên khung đánh giá KARLBench của riêng Databricks. Điều này chứng minh rằng khoảng cách hiệu suất giữa RAG một lượt và tác nhân đa bước trong các nhiệm vụ dữ liệu hỗn hợp là một vấn đề về kiến trúc, không phải chất lượng mô hình.

Công trình này dựa trên nghiên cứu "instructed retriever" trước đây của Databricks, cho thấy cải thiện truy xuất trên dữ liệu phi cấu trúc bằng cách sử dụng truy vấn nhận thức metadata. Nghiên cứu lần này thêm các nguồn dữ liệu có cấu trúc, bảng quan hệ và kho dữ liệu SQL vào cùng một vòng lặp lý luận, giải quyết lớp câu hỏi mà các doanh nghiệp thường thất bại khi trả lời bằng kiến trúc tác nhân hiện tại.

"RAG hoạt động, nhưng nó không mở rộng được," Michael Bendersky, giám đốc nghiên cứu tại Databricks, chia sẻ với VentureBeat. "Nếu bạn muốn tác nhân tốt hơn và hiểu lý do doanh số giảm, bạn phải giúp tác nhân nhìn thấy các bảng và dữ liệu bán hàng. Quy trình RAG của bạn sẽ trở nên bất lực trước nhiệm vụ đó."

Hạn chế của truy xuất một lượt

Phát hiện cốt lõi là các hệ thống RAG tiêu chuẩn thất bại khi một truy vấn kết hợp bộ lọc có cấu trúc chính xác với tìm kiếm ngữ nghĩa mở.

Hãy xem xét câu hỏi: "Sản phẩm nào của chúng ta có doanh số giảm trong ba tháng qua và các vấn đề tiềm ẩn nào được đề cập trong đánh giá của khách hàng trên các trang bán hàng khác nhau?" Dữ liệu bán hàng nằm trong kho dữ liệu (warehouse), trong khi cảm nhận từ đánh giá nằm trong tài liệu phi cấu trúc trên các trang bán hàng. Hệ thống RAG một lượt không thể chia nhỏ truy vấn này, định tuyến từng phần đến nguồn dữ liệu đúng và kết hợp kết quả.

Để xác nhận đây là vấn đề kiến trúc chứ không phải chất lượng mô hình, Databricks đã chạy lại các đường cơ sở STaRK đã công bố bằng cách sử dụng mô hình nền tảng (foundation model) hiện đại nhất hiện nay. Mô hình mạnh hơn vẫn thua tác nhân đa bước 21% trong lĩnh vực học thuật và 38% trong lĩnh vực sinh học.

STaRK là bộ chuẩn do các nhà nghiên cứu Stanford xuất bản, bao gồm ba lĩnh vực truy xuất bán cấu trúc: dữ liệu sản phẩm Amazon, đồ thị học thuật Microsoft và cơ sở kiến thức sinh học.

Cách Supervisor Agent xử lý những gì RAG không thể

Databricks đã xây dựng Supervisor Agent như một triển khai thực tế cho cách tiếp cận nghiên cứu này, và kiến trúc của nó minh họa lý do tại sao mức cải thiện lại nhất quán trên các loại nhiệm vụ. Cách tiếp cận này bao gồm ba bước chính:

Phân công công cụ song song. Thay vì đưa ra một truy vấn rộng và hy vọng kết quả bao gồm cả nhu cầu dữ liệu có cấu trúc và phi cấu trúc, tác nhân thực hiện đồng thời các cuộc gọi SQL và tìm kiếm vector, sau đó phân tích kết quả kết hợp trước khi quyết định bước tiếp theo. Bước song song này cho phép nó xử lý các truy vấn vượt qua ranh giới loại dữ liệu mà không yêu cầu dữ liệu phải được chuẩn hóa trước.

Tự sửa lỗi. Khi nỗ lực truy xuất ban đầu đi vào ngõ cụt, tác nhân phát hiện sự thất bại, điều chỉnh lại truy vấn và thử một con đường khác. Trong một nhiệm vụ benchmark STaRK yêu cầu tìm một bài báo của một tác giả có chính xác 115 bài xuất bản trước đó về một chủ đề cụ thể, tác nhân đầu tiên truy vấn cả SQL và tìm kiếm vector song song. Khi hai tập kết quả không có điểm chung, nó thích ứng bằng cách thực hiện lệnh SQL JOIN trên cả hai ràng buộc, sau đó gọi hệ thống tìm kiếm vector để xác minh kết quả trước khi trả về câu trả lời.

Cấu hình khai báo. Tác nhân không được tinh chỉnh cho bất kỳ tập dữ liệu hoặc nhiệm vụ cụ thể nào. Kết nối nó với một nguồn dữ liệu mới chỉ cần viết mô tả bằng ngôn ngữ tự nhiên về nội dung nguồn đó chứa và các loại câu hỏi nó nên trả lời. Không cần mã tùy chỉnh.

"Tác nhân có thể thực hiện những việc như phân tách câu hỏi thành truy vấn SQL và truy vấn tìm kiếm ngay lập tức," Bendersky nói. "Nó có thể kết hợp kết quả của SQL và RAG, lý luận về những kết quả đó, thực hiện các truy vấn tiếp theo và sau đó lý luận xem liệu câu trả lời cuối cùng thực sự đã được tìm thấy hay chưa."

Không chỉ là truy xuất hỗn hợp

Việc có thể lấy thông tin từ cả dữ liệu có cấu trúc và phi cấu trúc không phải là một khái niệm hoàn toàn mới.

Các tác nhân từ LlamaIndex, LangChain và Microsoft Fabric đều cung cấp một số dạng truy xuất hỗn hợp. Tuy nhiên, Bendersky phân biệt cách tiếp cận của Databricks trong việc định khung vấn đề về mặt kiến trúc.

"Chúng tôi hầu như không coi đây là truy xuất hỗn hợp nơi bạn kết hợp embeddings và kết quả tìm kiếm, hoặc embeddings và bảng," ông nói. "Chúng tôi nhìn nhận điều này nhiều hơn như một tác nhân có quyền truy cập vào nhiều công cụ."

Hệ quả thực tế của cách định khung này là việc thêm một nguồn dữ liệu mới có nghĩa là kết nối nó với tác nhân và viết mô tả về nội dung của nó. Tác nhân xử lý định tuyến và điều phối mà không cần thêm mã.

Các quy trình RAG tùy chỉnh yêu cầu dữ liệu phải được chuyển đổi sang định dạng mà hệ thống truy xuất có thể đọc, thường là các đoạn văn bản với embeddings. Bảng SQL phải được làm phẳng, JSON phải được chuẩn hóa. Mỗi nguồn dữ liệu mới thêm vào quy trình nghĩa là nhiều công việc chuyển đổi hơn. Nghiên cứu của Databricks lập luận rằng khi dữ liệu doanh nghiệp phát triển để bao gồm nhiều loại nguồn hơn, gánh nặng đó khiến các quy trình tùy chỉnh ngày càng không thực tế so với một tác nhân truy vấn từng nguồn ở định dạng gốc của nó.

"Chỉ cần đưa tác nhân đến dữ liệu," Bendersky nói. "Về cơ bản bạn cung cấp cho tác nhân nhiều nguồn hơn và nó sẽ học cách sử dụng chúng khá tốt."

Ý nghĩa đối với các doanh nghiệp

Đối với các kỹ sư dữ liệu đang đánh giá xem nên xây dựng các quy trình RAG tùy chỉnh hay áp dụng khung tác nhân khai báo, nghiên cứu này đưa ra một hướng đi rõ ràng: nếu nhiệm vụ liên quan đến các câu hỏi trải dài trên dữ liệu có cấu trúc và phi cấu trúc, việc xây dựng truy xuất tùy chỉnh là con đường khó khăn hơn. Nghiên cứu phát hiện ra rằng trên tất cả các nhiệm vụ được kiểm tra, điều khác biệt duy nhất giữa các lần triển khai là hướng dẫn và mô tả công cụ. Tác nhân xử lý phần còn lại.

Giới hạn thực tế là có thật nhưng có thể quản lý. Cách tiếp cận này hoạt động tốt với năm đến mười nguồn dữ liệu. Thêm quá nhiều cùng một lúc, mà không chọn lọc xem nguồn nào bổ sung cho nhau thay vì mâu thuẫn, sẽ làm cho tác nhân chậm hơn và ít đáng tin cậy hơn. Bendersky khuyến nghị mở rộng theo từng bước và xác minh kết quả tại mỗi bước thay vì kết nối tất cả dữ liệu có sẵn ngay từ đầu.

Độ chính xác dữ liệu là điều kiện tiên quyết. Tác nhân có thể truy vấn qua các định dạng không khớp nhau, nguồn cấp dữ liệu đánh giá JSON cùng với bảng bán hàng SQL, mà không yêu cầu chuẩn hóa. Nó không thể sửa dữ liệu nguồn sai về mặt thực tế. Việc thêm mô tả bằng ngôn ngữ tự nhiên cho từng nguồn dữ liệu tại thời điểm nhập giúp tác nhân định tuyến truy vấn chính xác ngay từ đầu.

Nghiên cứu định vị đây là một bước đầu trong một chặng đường dài hơn. Khi khối lượng công việc AI doanh nghiệp trưởng thành, các tác nhân được kỳ vọng sẽ lý reasoning trên hàng chục loại nguồn, bao gồm bảng điều khiển, kho lưu trữ mã và nguồn cấp dữ liệu bên ngoài. Nghiên cứu lập luận rằng cách tiếp cận khai báo là điều làm cho việc mở rộng này khả thi, bởi vì thêm một nguồn mới vẫn là một vấn đề cấu hình chứ không phải vấn đề kỹ thuật.

"Điều này giống như một cái thang," Bendersky nói. "Tác nhân sẽ từ từ nhận được nhiều thông tin hơn và sau đó từ từ cải thiện tổng thể."