Orchestration trong hệ thống RAG: static pipeline hay agentic controller

Làm thế nào để orchestrate một hệ thống RAG?

Orchestration là phần mã quyết định bước nào chạy tiếp theo: viết lại câu hỏi, retrieval các đoạn văn, reranking, gọi mô hình, kiểm tra câu trả lời và trả về nguồn. Mô hình tạo ra văn bản, còn lớp orchestration quyết định thứ tự các bước và điều kiện để chúng chạy.

Anthropic phân biệt hai loại hệ thống. Workflow là các hệ thống trong đó LLM và tool được orchestrate theo những đường đi định sẵn trong mã ^[1]. Agent thì khác: LLM tự điều khiển tiến trình và cách dùng tool của chính nó ^[1].

Một hệ thống RAG có thể dùng cả hai. Lựa chọn này quyết định mức độ dự đoán được của hệ thống, chi phí cho mỗi câu hỏi và mức độ khó khi kiểm thử.

Khi nào static pipeline là đủ?

Static pipeline chạy cùng các bước, theo cùng thứ tự, cho mọi câu hỏi. Bài tổng quan arXiv về kiến trúc RAG xếp cách chia này vào các orchestration layer: static pipeline so với agentic controller. Bài đó mô tả static pipeline là hệ thống vận hành theo các thao tác định trước, dựa trên quy tắc ^[2].

Với công cụ tìm kiếm trên một bộ tài liệu sản phẩm cố định, đường đi cố định thường là bản dựng đầu tiên hợp lý. Một pipeline điển hình trông như sau:

• Retrieval các đoạn văn hàng đầu cho câu hỏi, có lọc theo metadata như phiên bản sản phẩm.
• Reranking các đoạn văn và bỏ những đoạn có điểm dưới ngưỡng.
• Sinh câu trả lời chỉ từ các đoạn còn lại, kèm đường dẫn tới từng đoạn.
• Trả về thông báo “không tìm thấy câu trả lời” khi không có đoạn nào qua ngưỡng.

Anthropic đưa ra lời khuyên xuất phát điểm tương tự: nên tìm giải pháp đơn giản nhất có thể, và chỉ tăng độ phức tạp khi thật sự cần ^[1]. Điều đó có thể nghĩa là không xây dựng agent nào cả ^[1].

Khi nào agentic controller đáng với chi phí?

Agentic controller cho phép mô hình chọn bước tiếp theo. Cách này hữu ích khi kết quả retrieval đầu tiên cho thấy cần tìm gì tiếp, chẳng hạn một câu hỏi cần thông tin từ hai bản phát hành sản phẩm. Chi phí là có thật: Anthropic lưu ý rằng các hệ thống agent thường đánh đổi latency và cost để lấy hiệu quả task tốt hơn ^[1].

Một mẫu trong hướng dẫn của Anthropic phù hợp với RAG: mẫu orchestrator-workers. Ở đó, một LLM trung tâm phân rã task một cách linh hoạt, giao cho các LLM worker và tổng hợp kết quả ^[1]. Các subtask do orchestrator quyết định dựa trên đầu vào cụ thể ^[1], chứ không được viết sẵn từ trước.

Với RAG, các worker có thể là retriever trên những index khác nhau, chẳng hạn tài liệu sản phẩm, ticket hỗ trợ và ghi chú phát hành. Orchestrator quyết định query index nào và gộp kết quả trả về. Mỗi quyết định thêm một lần gọi mô hình, thêm latency và thêm một chỗ có thể lỗi, nên hãy giữ danh sách tool ngắn, giới hạn số bước và ghi log mọi lựa chọn của controller.

Lấy một câu hỏi như “Kết nối có thay đổi giữa hai bản phát hành không, và ghi chú di chuyển nói gì?” Một static pipeline chỉ retrieval một lần, nên có thể bỏ lỡ ghi chú di chuyển của bản phát hành thứ hai. Agentic controller có thể tìm trong index phát hành trước, đọc thay đổi tìm được, rồi mới query ghi chú di chuyển cho đúng thay đổi đó. Vòng retrieval thêm này là cái giá của lần tìm kiếm thứ hai, và chỉ đáng trả cho những câu hỏi cần nó.

Làm sao giữ một lần chạy nhiều bước đi đúng hướng?

Một lần chạy dài cần trạng thái nằm ngoài mô hình. Bài viết của Anthropic về long-running agents nói rằng thách thức cốt lõi là chúng phải làm việc theo các session rời rạc ^[3]. Cách khắc phục trong bài là một initializer thiết lập môi trường, và một coding agent tiến từng bước nhỏ trong mỗi session, đồng thời để lại artifact rõ ràng cho session kế tiếp ^[3].

Cùng bài viết đó mô tả một lỗi mà RAG controller cũng có thể gặp: một agent sau này nhìn quanh, thấy đã có tiến triển, và tuyên bố công việc đã xong ^[3]. Controller đã tìm được vài đoạn văn cũng có thể dừng sớm theo cách tương tự.

Cách sửa là một log mà controller ghi sau mỗi bước. Log gồm các query đã chạy, các nguồn đã đọc và các sub-question còn mở. Controller chỉ kết thúc khi mọi sub-question đã được trả lời hoặc được đánh dấu là nguồn không hỗ trợ. Hãy giữ log ở nơi controller đọc được trong mỗi bước, đừng chỉ để trong prompt.

Làm sao kiểm thử lớp orchestration?

Kiểm thử từng bước và toàn bộ lần chạy riêng biệt. Chỉ một điểm end-to-end sẽ che mất chỗ lỗi bắt đầu. Bài tổng quan arXiv ghi nhận rằng standardized benchmarks còn ít được dùng, trong khi custom evaluation criteria lại phổ biến ^[2], nên một nhóm thường phải viết bộ kiểm thử riêng.

Kiểm tra bốn điểm:

• Retrieval: nguồn kỳ vọng có nằm trong kết quả hàng đầu của mỗi câu hỏi kiểm thử không?
• Routing: controller có chọn đúng index hoặc tool không?
• Grounding: mỗi khẳng định trong câu trả lời có truy ngược được về một đoạn đã retrieval không?
• End-to-end: một lần chạy cơ bản có còn đạt sau mỗi thay đổi không?

Bộ kiểm thử cần nhiều hơn các câu tra cứu dễ. Hãy có câu hỏi chỉ cần một nguồn, câu cần hai nguồn, câu mà corpus không trả lời được, và câu mà hai nguồn mâu thuẫn. Hai loại cuối quan trọng nhất với grounding, vì một hệ thống luôn trả lời sẽ thất bại ở đó mà không báo lỗi nhìn thấy.

Bài viết về long-running agents của Anthropic yêu cầu agent chạy một bài kiểm thử end-to-end cơ bản trước khi thêm tính năng mới ^[3]. Áp dụng quy tắc tương tự cho RAG pipeline: chạy kiểm thử end-to-end trước khi thêm mỗi bước mới, chứ không chỉ trước khi phát hành.

Nên xây dựng mẫu nào trước?

Hãy xây static pipeline trước và đo nó trên bộ kiểm thử. Chỉ chuyển một loại câu hỏi sang agentic controller khi pipeline thất bại với loại đó, và chỉ ở bước cần một quyết định. Đặt mỗi bước sau một hàm có đầu vào và đầu ra cố định, để controller có thể thay một bước mà không phải viết lại phần retrieval.

Hãy ghi lại version của từng bước trong log. Khi chất lượng câu trả lời thay đổi sau một bản phát hành, bản ghi version cho thấy retrieval, routing hay generation đã thay đổi, để việc sửa lỗi nhắm đúng một bước.

Bước cụ thể tiếp theo là thu thập các câu hỏi thật của người dùng từ log, đánh dấu nguồn trả lời cho từng câu, rồi chạy pipeline trên bộ đó trước khi thay đổi gì.