Đánh giá RAG: Tại sao hệ thống của bạn không hề lỗi thời mà chỉ là do cơ chế truy xuất không xác định

Bài viết được dịch và tổng hợp từ tin tức gốc. Bạn có thể đọc bài viết gốc bằng tiếng Anh tại đây.

Điểm tin nhanh:

• Các bài kiểm tra đánh giá (evals) trong hệ thống RAG thường bị coi là không ổn định (flaky) do kết quả thay đổi liên tục.
• Nguyên nhân gốc rễ không nằm ở bộ đánh giá mà ở tính không xác định (non-deterministic) của quá trình truy xuất dữ liệu (retrieval).
• Cần kiểm soát chặt chẽ các tham số truy xuất và dữ liệu đầu vào để đạt được kết quả đánh giá nhất quán.

Bạn đã bao giờ rơi vào tình trạng chạy một bộ đánh giá (eval) cho hệ thống RAG (Retrieval-Augmented Generation) và nhận được kết quả hoàn toàn khác biệt chỉ sau vài lần thử nghiệm? Nhiều kỹ sư thường đổ lỗi cho sự không ổn định của các mô hình LLM hoặc sự thiếu hụt trong các framework đánh giá. Tuy nhiên, sự thật có thể phũ phàng hơn: bài kiểm tra của bạn không hề lỗi thời, mà chính cơ chế truy xuất dữ liệu của bạn đang vận hành theo cách không xác định.

Bản chất của sự không xác định trong truy xuất

Trong các hệ thống RAG hiện đại, quá trình truy xuất thường dựa trên tìm kiếm vector (vector search) hoặc tìm kiếm ngữ nghĩa. Khi chúng ta thực hiện truy vấn, hệ thống sẽ trả về các đoạn văn bản (chunks) có độ tương đồng cao nhất. Vấn đề nảy sinh khi các đoạn văn bản này có điểm số tương đồng (similarity scores) rất sát nhau. Chỉ cần một thay đổi nhỏ trong cách tiền xử lý văn bản hoặc tham số của mô hình embedding, thứ tự của các kết quả trả về có thể bị xáo trộn hoàn toàn.

Việc tối ưu hóa quy trình này đòi hỏi sự hiểu biết sâu sắc về dữ liệu, tương tự như cách chúng ta tối ưu hóa quy trình AI với Qualcomm AI Runtime. Khi hệ thống truy xuất không trả về cùng một tập hợp dữ liệu ngữ cảnh cho cùng một truy vấn, LLM sẽ nhận được các thông tin đầu vào khác nhau, dẫn đến kết quả đầu ra không nhất quán.

Bảng so sánh các yếu tố gây ra sự không xác định

Tại sao bài kiểm tra của bạn bị coi là flaky

Khi bạn xây dựng hệ thống tự động hóa sản phẩm số No-Code, bạn có thể kiểm soát được luồng dữ liệu. Nhưng với RAG, chúng ta đang làm việc với xác suất. Nếu quá trình truy xuất không được cố định (deterministic), bộ đánh giá sẽ đo lường những mục tiêu di động. Điều này tạo ra ảo giác về sự không ổn định.

Mẹo hay: Hãy cố định các tham số truy xuất (như seed cho vector database hoặc giới hạn số lượng kết quả trả về) trong môi trường thử nghiệm để đảm bảo tính tái lập của các bài đánh giá.

Quy trình truy xuất và đánh giá chuẩn

Để khắc phục, chúng ta cần một quy trình rõ ràng. Thay vì chỉ đánh giá đầu ra cuối cùng của LLM, hãy tách biệt đánh giá truy xuất (Retrieval Eval) và đánh giá thế hệ (Generation Eval). Bạn có thể tham khảo cách tối ưu hóa hiệu năng Claude Code để áp dụng các kỹ thuật đo lường tương tự cho hệ thống RAG của mình.

Sơ đồ quy trình đề xuất:
[Truy vấn] ---> [Cố định tham số truy xuất] ---> [Truy xuất dữ liệu] ---> [Đánh giá độ chính xác của chunk] ---> [LLM Generation]

Đánh giá & Lời khuyên Thực tiễn

Ưu điểm

• Giúp xác định chính xác điểm yếu của hệ thống (do truy xuất kém hay do LLM kém).
• Tăng độ tin cậy của các bài kiểm tra tự động trong CI/CD.

Nhược điểm

• Đòi hỏi nhiều công sức để thiết lập các bộ dữ liệu vàng (ground truth) cố định.
• Có thể làm giảm tính linh hoạt của hệ thống trong môi trường thực tế.

Lời khuyên cho Production

• Luôn sử dụng phiên bản cố định của mô hình embedding.
• Thực hiện tự động hóa Code Review cho mọi thay đổi trong logic truy xuất để tránh các lỗi logic không mong muốn.

Câu hỏi thường gặp (FAQ)

Tại sao tôi nên cố định kết quả truy xuất?

Việc cố định giúp bạn có một baseline ổn định để đo lường hiệu quả của các thay đổi (như thay đổi prompt hoặc mô hình LLM) mà không bị nhiễu bởi dữ liệu đầu vào.

Làm sao để biết hệ thống RAG của tôi đang bị non-deterministic?

Hãy chạy cùng một truy vấn 10 lần và kiểm tra xem tập hợp các đoạn văn bản (chunks) trả về có giống nhau hoàn toàn hay không.

Có cách nào để cải thiện độ ổn định mà không cần cố định tham số?

Bạn có thể sử dụng kỹ thuật Hybrid Search (kết hợp keyword search và vector search) để tăng tính ổn định cho các truy vấn cụ thể.

Kết luận

Sự không ổn định trong đánh giá RAG không phải là một lỗi hệ thống không thể giải quyết, mà là một tín hiệu cho thấy bạn cần kiểm soát chặt chẽ hơn quá trình truy xuất dữ liệu. Bằng cách tách biệt các thành phần và cố định các biến số, bạn sẽ xây dựng được các hệ thống AI mạnh mẽ và đáng tin cậy hơn. Hãy bắt đầu tối ưu hóa ngay hôm nay và đừng quên theo dõi hi_dev để cập nhật những kiến thức chuyên sâu về công nghệ mới nhất.