Ragas và DeepEval: hai thư viện chấm điểm RAG, và vì sao không nên tin ngay điểm số của chúng

Ragas có thể chấm một pipeline RAG mà không cần ai viết sẵn đáp án đúng. Bài báo gốc của Shahul Es và các đồng tác giả, công bố lần đầu tháng 9/2023, gọi đây là đánh giá “reference-free”, tức không cần ground truth do người gán nhãn.

Khi một FDE bị khách hỏi “con bot này đúng bao nhiêu phần trăm?”, tính năng này vừa giúp được việc, vừa là một cái bẫy.

Nó giúp được việc nếu khách chưa có sẵn bộ câu hỏi kèm đáp án do người gán nhãn, vì Ragas không đòi thứ đó để bắt đầu. Nó là cái bẫy vì khi không có nhãn của người, thứ chấm điểm thường là một LLM khác.

Một con số có hai chữ số thập phân trông rất chính xác, nhưng nó chỉ đáng tin bằng chính model đã chấm ra nó.

Vì thế, cách dùng Ragas và DeepEval đúng chỗ là lấy tín hiệu nhanh và chặn lỗi hồi quy. Đừng dùng chúng để đưa một con số lên slide cho ban giám đốc khi chưa ai kiểm lại con số đó.

Ragas lo việc đo, DeepEval lo việc kiểm thử

Ragas tự giới thiệu là thư viện đánh giá ứng dụng LLM. Repo hiện nằm dưới tổ chức vibrantlabsai trên GitHub, dùng giấy phép Apache-2.0. Thư viện có cả metric dựa trên LLM lẫn metric truyền thống, cho phép tự viết metric bằng decorator, và có thể tự sinh bộ dữ liệu test tổng hợp cho nhiều tình huống.

Playbook của Microsoft chia các metric RAG của Ragas làm hai nhóm. Faithfulness và answer relevancy đo phần sinh câu trả lời. Context relevancy và context recall đo phần truy xuất. Riêng faithfulness trừ điểm mọi khẳng định trong câu trả lời mà không suy ra được từ context.

DeepEval đi theo hướng khác. Nhóm phát triển định vị nó là “Pytest dành riêng cho ứng dụng LLM”: mã nguồn mở, ưu tiên chạy local, giấy phép Apache 2.0, có hơn 50 metric dựng sẵn (gồm cả LLM-as-a-judge), đánh giá được cả end-to-end lẫn từng thành phần.

Ý tưởng cốt lõi là viết assertion kiểu Pytest cho output của LLM và cho chạy trong CI.

Nên bắt đầu từ đâu với một bot tra cứu nội bộ?

Thử hình dung bạn triển khai một bot hỏi đáp quy trình nội bộ cho một ngân hàng và có 50 câu hỏi thật do nhân viên gửi. Đừng chạy faithfulness ngay. Hãy đo hit rate trước: theo Evidently AI, đây là metric nhị phân, chỉ kiểm tra xem ít nhất một đoạn liên quan có lọt vào top-K hay không, và không cần LLM judge.

Giả sử 35 trên 50 câu có đoạn đúng nằm trong top-5, hit rate là 70%. Với 15 câu còn lại, prompt hay đến đâu bot cũng không thể trả lời đúng, vì tài liệu cần thiết không bao giờ đến được model. Lúc này việc cần sửa là chunking, embedding hoặc cách tìm kiếm.

Chỉ khi retrieval đã ổn mới nên đo generation. Giả sử một câu trả lời có 4 khẳng định, trong đó 1 khẳng định không có trong context; faithfulness sẽ trừ điểm đúng khẳng định đó. Giá trị lớn nhất của Ragas nằm ở chỗ này: nó tách lỗi “tìm sai tài liệu” khỏi lỗi “bịa thêm thông tin”, hai loại lỗi cần hai cách sửa khác nhau.

Bộ test tổng hợp của Ragas giúp nới rộng 50 câu ban đầu, rồi bước cuối là chuyển những câu từng trả lời sai thành test DeepEval có ngưỡng điểm. Nếu tuần thứ ba khách đổi chunk size, CI sẽ chỉ ra ngay câu nào hỏng, trước khi người dùng phải lên tiếng phàn nàn.

Ai kiểm tra người chấm?

Faithfulness của DeepEval kiểm tra xem output có khớp về mặt sự kiện với retrieval context hay không. G-Eval cho phép chấm theo tiêu chí tùy chỉnh. Cả hai đều do một LLM chấm, và Microsoft cảnh báo rằng các judge loại này có vấn đề về độ tin cậy, gồm thiên kiến vị trí, thiên kiến độ dài và thiên kiến tự đề cao.

Evidently AI nói cụ thể hơn: judge có thể ưu ái câu trả lời dài hơn, trau chuốt hơn, hoặc giống văn của chính nó. Chất lượng của judge phụ thuộc hoàn toàn vào prompt và model nền. Một điểm faithfulness 0,85 vì vậy không phải là sự thật, mà là ý kiến của một model cụ thể với một prompt cụ thể.

Microsoft cũng nói rõ rằng vẫn cần con người kiểm tra lại, nhất là với các tác vụ chuyên ngành. Cách làm thực tế: lấy 20 đến 30 câu, nhờ một chuyên gia phía khách chấm tay, rồi so với điểm của judge. Nếu hai bên lệch nhau nhiều, hãy sửa tiêu chí trong G-Eval trước khi tin bất kỳ dashboard nào.

Những lỗi dễ mắc nhất là gì?

Lỗi phổ biến đầu tiên là sửa prompt khi vấn đề nằm ở retrieval. Trong ví dụ ngân hàng ở trên, viết lại prompt cả tuần cũng không cứu được 15 câu mà tài liệu đúng chưa từng lọt vào top-5. Hit rate thấp thì quay về chunking và tìm kiếm trước.

Lỗi thứ hai là tin bộ câu hỏi tổng hợp mà không ai duyệt. Câu hỏi do máy sinh ra có thể không giống cách nhân viên ngân hàng thật sự hỏi, nên hãy nhờ người phía khách lướt qua và loại những câu lạc lõng trước khi đưa vào bộ test.

Lỗi thứ ba là để cùng một model vừa sinh câu trả lời vừa chấm điểm. Với thiên kiến tự đề cao mà Microsoft và Evidently AI đã nêu, cách làm đó dễ cho ra điểm đẹp hơn thực tế. Lỗi cuối cùng là báo cáo điểm judge cho khách khi chưa đối chiếu với bất kỳ mẫu chấm tay nào.

Học gì trước, ghi gì vào CV

Thứ tự học hợp lý là: các metric retrieval không cần judge, sau đó đến faithfulness và context recall, cuối cùng là đưa eval vào CI. Khi đọc JD, nếu gặp các cụm như “evaluation”, “eval harness” hay “LLM-as-a-judge”, hãy chuẩn bị sẵn một ví dụ cụ thể về bộ eval bạn từng dựng để kể trong phỏng vấn.

Trong CV, hãy viết một dòng như “dựng bộ eval 50 câu, tách lỗi retrieval khỏi lỗi generation, đối chiếu điểm judge với người chấm” thay vì “có kinh nghiệm dùng Ragas”. Dòng thứ nhất cho người đọc thấy bạn biết nghi ngờ đúng chỗ; dòng thứ hai chỉ cho thấy bạn đã cài một thư viện.

Gọi thư viện thì một buổi chiều là học xong. Giải thích được cho khách vì sao con số 0,85 chưa đủ để go-live mới là phần khó, và là phần khách cần đến FDE nhất.