Kiến trúc RAG theo tầng: Cách giảm 6 lần chi phí suy luận bằng cách giữ LLM khỏi những quyết định tầm thường

Hầu hết các nhóm xây dựng hệ thống retrieval augmented generation (RAG) cho phân loại rủi ro cao đều mắc cùng một lỗi kiến trúc: đẩy mọi trường hợp mơ hồ vào thẳng mô hình ngôn ngữ lớn (LLM) và tin rằng ngữ cảnh truy xuất sẽ tự giải quyết. Cách này chạy tốt trong bản demo, nhưng sụp đổ ngay khi hệ thống phải đối mặt với kiểm toán, cơ quan quản lý, hoặc một nhân viên tuân thủ hỏi tại sao một quyết định cụ thể lại được đưa ra sáu tháng trước.

Bài viết này phân tích chiến lược thiết kế khác biệt cho các hệ thống RAG trong doanh nghiệp có quy định chặt chẽ, nơi một câu trả lời sai không chỉ là một phản hồi chatbot tệ hại. Kiến trúc theo tầng (cascade architecture) chính là chìa khóa để vừa tiết kiệm chi phí, vừa đảm bảo khả năng giải trình và kiểm soát rủi ro thực sự.

Chi phí ẩn của một pipeline dùng LLM cho mọi thứ

Việc đẩy toàn bộ lưu lượng qua LLM có sức hấp dẫn rõ ràng: ít thành phần phức tạp, vòng lặp phát triển nhanh hơn, và mô hình tự xử lý các trường hợp ngoại lệ bất ngờ. Tuy nhiên, vấn đề chỉ lộ diện sau này, ở ba khía cạnh chính.

Thứ nhất, khả năng kiểm toán. Câu trả lời "mô hình đã quyết định dựa trên ngữ cảnh truy xuất" không phải là một câu trả lời chấp nhận được. Bạn cần một lộ trình quyết định mà con người có thể dựng lại mà không cần chạy lại suy luận và hy vọng kết quả giống hệt.

Thứ hai, chi phí ở quy mô lớn. Nếu hệ thống xử lý hàng chục nghìn ca mỗi ngày và mọi ca đều cần một lần gọi LLM kèm bối cảnh nhiều tài liệu, hóa đơn suy luận và độ trễ sẽ tăng tỷ lệ thuận với khối lượng — điều mà logic theo luật không bao giờ gặp phải.

Thứ ba, và ít được bàn tới nhất: hiện tượng trôi mô hình (model drift) trên các ca dễ. LLM rất giỏi trong các phán đoán tinh tế, nhưng lại không nhất quán — theo cách khó phát hiện — trên những ca cần câu trả lời xác định. Một khớp cấu trúc rõ ràng với các tiêu chí đã biết không bao giờ nên phụ thuộc vào "tâm trạng" của một mô hình ngôn ngữ.

Cách tiếp cận theo tầng: LLM chỉ là tầng cuối cùng

Giải pháp: Ngừng coi LLM là tiền tuyến và bắt đầu xem nó là đường leo thang (escalation). Thực tế là một pipeline ba tầng.

Tầng một hoàn toàn xác định (deterministic). Các khớp chính xác, so sánh trường dữ liệu có cấu trúc, và bất cứ thứ gì có quy tắc rõ ràng đều được giải quyết tại đây mà không cần đến một lần gọi mô hình nào. Tầng này thường xử lý phần lớn khối lượng — thường là hơn một nửa, tùy thuộc chất lượng dữ liệu — và mỗi quyết định đều hoàn toàn giải trình được vì nó là một phép tra cứu, không phải suy luận.

Tầng hai là nơi bộ truy xuất thể hiện giá trị. Với các ca vượt qua tầng một — nghĩa là vẫn chưa được giải quyết rõ ràng — bạn xây dựng một lớp truy xuất để kéo về bằng chứng cụ thể liên quan đến sự mơ hồ: các quyết định của người duyệt trước đây trên các ca tương tự, tài liệu ngữ cảnh giải thích xung đột xuất hiện, hoặc tiền lệ lịch sử làm rõ một trường hợp ngoại lệ. Bước truy xuất quan trọng hơn nhiều so với bước sinh văn bản. Nếu bạn truy xuất sai ngữ cảnh, ngay cả mô hình ngôn ngữ giỏi nhất thế giới cũng sẽ tạo ra một câu trả lời sai nhưng tự tin và lý luận rất hợp lý.

Tầng ba là lời gọi LLM, và nó chỉ nên nhìn thấy phần còn sót lại mà hai tầng trên không xử lý được. Đây là phần mà nhiều nhóm bỏ qua khi thiết kế phiên bản đầu tiên, và nó đồng thời là đòn bẩy lớn nhất cho cả chi phí lẫn chất lượng. Trong một hệ thống tôi đã làm việc, việc chỉ định tuyến 10-15% số ca thực sự mơ hồ đến LLM đã cắt giảm chi phí suy luận khoảng 6 lần so với đường cơ sở dùng LLM cho tất cả, đồng thời nâng độ nhất quán trên phép phần lớn các ca xác định lên gần như hoàn hảo.

Thiết kế prompt với rủi ro bất đối xứng

Khi một ca đã đến tầng LLM, hầu hết các nhóm dùng prompt trung tính: "Đánh giá xem ca này nên được chấp thuận hay gắn cờ." Cách đặt vấn đề này là sai cho phân loại rủi ro cao vì chi phí của hai loại sai lầm không hề đối xứng. Bỏ sót một ca thực sự cần chú ý có thể gây ra hậu quả nghiêm trọng ở phía sau. Gắn cờ nhầm một ca bình thường chỉ tốn thời gian của người duyệt và một chút trì hoãn. Hai kết quả này hiếm khi có mức độ tệ hại ngang nhau, nhưng một prompt trung tính lại yêu cầu mô hình coi chúng như nhau.

Prompt rủi ro bất đối xứng làm cho sự đánh đổi này trở nên rõ ràng với mô hình, thay vì để nó đoán mò mức độ chấp nhận rủi ro của bạn. Cụ thể, prompt này cần:

• Hướng dẫn mô hình coi sự không chắc chắn là lý do để leo thang thay vì thông qua.
• Cung cấp các ví dụ đã hiệu chỉnh cho cả hai loại lỗi, nêu rõ hậu quả của từng loại.
• Yêu cầu mô hình đưa ra điểm tin cậy (confidence score) kèm theo phân loại, thay vì câu trả lời nhị phân.

Điểm tin cậy chính là điểm cascade thứ hai: bất cứ ca nào có điểm dưới ngưỡng sẽ được chuyển đến người duyệt con người thay vì tự động giải quyết, bất kể phân loại của mô hình nói gì. Nghe có vẻ chỉ là một chi tiết kỹ thuật prompt nhỏ, nhưng trên thực tế nó là sự khác biệt giữa một hệ thống giảm khối lượng công việc cho người duyệt và một hệ thống âm thầm làm tăng rủi ro trong khi trông vẻ đang hoạt động tốt.

Đánh giá một hệ thống kiểu này một cách đúng đắn

Các chỉ số đánh giá RAG tiêu chuẩn không được xây dựng cho trường hợp sử dụng này. Dùng chúng mà không biến đổi sẽ tạo ra cảm giác an toàn giả tạo. Một vài điều chỉnh quan trọng:

• Đo chất lượng truy xuất riêng biệt với độ chính xác phân loại cuối cùng. Một hệ thống có thể có điểm xếp hạng truy xuất tuyệt vời nhưng vẫn đưa ra quyết định cuối cùng tồi nếu bước sinh văn bản định lượng sai bằng chứng. Hãy theo dõi hai chỉ số này một cách độc lập.
• Tập đánh giá cần lấy mẫu quá mức (oversampling) các ca chạm tới tầng ba — vì đó là nơi khả năng phán đoán của hệ thống thực sự bị thử thách. Nếu tập đánh giá phản ánh đúng phân phối production, nó sẽ bị chi phối bởi các ca xác định mà cascade đã xử lý tốt, khiến bạn mù trước đúng những lỗi quan trọng nhất.
• Đánh giá LLM-as-judge có hiệu quả trong lĩnh vực này, nhưng chỉ khi prompt của "giám khảo" mã hóa cùng khung rủi ro bất đối xứng như prompt sản xuất. Một giám khảo coi hai loại lỗi như nhau sẽ luôn ủng hộ sự đánh đổi sai khi bạn tinh chỉnh hệ thống.
• Cuối cùng, xây dựng vòng phản hồi từ các kết quả đã xác nhận ngược vào kho ngữ liệu truy xuất. Khi một người duyệt con người lật lại quyết định của mô hình, ca đó cùng với cách giải quyết đúng phải trở thành ngữ cảnh truy xuất được cho các ca tương tự trong tương lai. Không có điều này, hệ thống sẽ không bao giờ cải thiện được cách xử lý các ca mơ hồ — nó chỉ lặp lại cùng một kiểu sai lầm với cùng một tỷ lệ.

Bài học lớn hơn

Bản năng chọn mô hình mạnh nhất cho mọi quyết định là điều dễ hiểu. Nhưng trong các lĩnh vực mà câu trả lời sai có hậu quả thực sự, công việc kỹ thuật quan trọng hơn là quyết định điều gì không bao giờ nên chạm đến mô hình. Kiến trúc theo tầng không phải là một cách lách giới hạn của LLM. Đó là hình ảnh đích thực của một hệ thống RAG trưởng thành — khi bạn đã phải thực sự bảo vệ các quyết định của nó trước một người có nhiệm vụ tìm ra lỗ hổng trong logic của bạn.

Nếu bạn đang xây dựng hệ thống AI cho bất kỳ lĩnh vực được quản lý hoặc rủi ro cao nào, câu hỏi đáng đặt ra trước khi viết prompt đầu tiên không phải là "Làm sao để mô hình xử lý tốt điều này?" mà là "Phần nào của quyết định này ngay từ đầu không nên là nhiệm vụ của mô hình?"

---

Vineet Vijay là kỹ sư trưởng AI và máy học (Lead AI and machine learning engineer).