Đánh giá Ragas, DeepEval và promptfoo cho chatbot RAG tiếng Việt
Ragas giúp tách lỗi retrieval và trả lời; DeepEval hợp với test kiểu pytest; promptfoo tiện so sánh prompt hoặc model trong CI. Kinh nghiệm từ một team thử chatbot quy chế nội bộ với 120 câu hỏi.
Một chatbot trả lời sai quy chế nội bộ. Nhưng bug “AI trả lời không đúng” vẫn chưa đủ để sửa đúng chỗ.
Vấn đề có thể nằm ở bước tìm tài liệu: bot không lấy được đoạn quy chế cần thiết. Cũng có thể context đã đúng, nhưng bước tạo câu trả lời lại diễn giải sai hoặc thêm thông tin không có trong tài liệu.
Đó là lý do eval cho RAG không nên dừng ở một cột “pass/fail”.
Trong bài chia sẻ trên diễn đàn, tác giả thử ba công cụ mã nguồn mở phổ biến — Ragas, DeepEval và promptfoo — trên chatbot hỏi đáp quy chế nội bộ với khoảng 300 tài liệu và 120 câu hỏi có đáp án mẫu do phòng nhân sự viết. Mục tiêu là tách lỗi retrieval khỏi lỗi trả lời.
Theo kết quả do tác giả báo cáo, khoảng 70% câu trả lời sai bắt nguồn từ bước tìm kiếm context, thay vì từ model. Sau khi điều chỉnh cách chia đoạn tài liệu và bổ sung tìm kiếm từ khóa, chất lượng cải thiện rõ. Đây là một lời nhắc hữu ích cho QA: trước khi đề xuất đổi model, hãy xác định bot đang hỏng ở tầng nào.
Chọn công cụ theo câu hỏi cần trả lời
RAG là cách chatbot tìm các đoạn tài liệu liên quan trước, rồi dùng chúng làm ngữ cảnh để sinh câu trả lời. Vì vậy, kiểm thử nên nhìn cả retrieval lẫn generation.
| Việc cần kiểm tra | Công cụ phù hợp | Lý do |
|---|---|---|
| Bot sai vì tìm thiếu, tìm nhầm hay trả lời vượt context | Ragas | Có các chỉ số faithfulness, answer relevancy, context precision và context recall |
| Viết test theo phong cách Python, có thể chạy cùng pytest | DeepEval | Phù hợp với tư duy unit test, có metric dựng sẵn và tiêu chí tự định nghĩa |
| So sánh prompt hoặc model trước/sau thay đổi | promptfoo | Khai báo test bằng YAML, có bảng so sánh kết quả |
| Kiểm tra yêu cầu riêng của sản phẩm | DeepEval hoặc promptfoo | Có thể diễn đạt tiêu chí bằng lời; promptfoo hỗ trợ điều kiện từ khóa, JSON và chấm bằng LLM |
| Red teaming | promptfoo | Có chế độ red teaming |
| Phân tích riêng chất lượng retrieval | Ragas | Chuyên sâu hơn promptfoo ở phần đánh giá context |
Ba công cụ này không thực sự thay thế nhau. Chúng trả lời ba câu hỏi khác nhau:
Ragas: Context lấy về có đúng, đủ và được dùng đúng không?
DeepEval: Có thể biến tiêu chí chất lượng thành test code để chạy lặp lại không?
promptfoo: Prompt hoặc model mới có làm kết quả xấu đi so với bản trước không?
Đọc chỉ số Ragas để triage bug
Ragas phù hợp khi team cần phân loại lỗi trong pipeline RAG, thay vì chỉ nhìn câu trả lời cuối.
Faithfulness: Câu trả lời có bám vào context đã lấy về không? Điểm thấp có thể là dấu hiệu bot thêm thông tin không có trong tài liệu.
Answer relevancy: Câu trả lời có đi đúng trọng tâm câu hỏi không?
Context precision: Các đoạn được lấy về có thực sự liên quan không? Điểm thấp có thể cho thấy retrieval đưa vào nhiều nhiễu.
Context recall: Context có đủ thông tin cần thiết để trả lời không? Điểm thấp có thể gợi ý thiếu tài liệu hoặc thiếu đoạn then chốt.
Với QA, mỗi case RAG nên lưu tối thiểu:
Câu hỏi đầu vào.
Câu trả lời của chatbot.
Context hoặc các đoạn tài liệu chatbot đã lấy về.
Đáp án mẫu hay tiêu chí nghiệp vụ.
Nhãn phân loại lỗi sau khi review: retrieval, trả lời, định dạng hoặc chưa rõ.
Ví dụ, nếu context recall thấp nhưng faithfulness cao, chatbot có thể đang trả lời đúng theo một context chưa đủ. Khi đó, team nên xem lại cách chia đoạn và tìm kiếm trước khi chỉ chỉnh prompt trả lời.
Ngược lại, nếu context có vẻ đủ nhưng faithfulness thấp, đây là case cần review kỹ: chatbot có thể đã có bằng chứng nhưng vẫn thêm chi tiết không được hỗ trợ.
Ghép promptfoo và Ragas vào lịch chạy eval
Từ kinh nghiệm chia sẻ trên diễn đàn, một cách phân vai khá thực dụng là:
promptfoo chạy trong CI để phát hiện regression khi thay prompt hoặc model.
Ragas chạy định kỳ hằng tuần để phân tích sâu chất lượng retrieval và câu trả lời.
Smoke test: chặn regression sớm
promptfoo phù hợp với các kiểm tra gọn, cần chạy lặp lại khi thay đổi prompt hoặc model. File YAML giúp đội QA và dev dễ xem bộ câu hỏi, điều kiện kiểm tra và kết quả so sánh.
Các case smoke test có thể ưu tiên:
Câu hỏi có câu trả lời trực tiếp trong quy chế.
Câu hỏi yêu cầu trích dẫn điều khoản.
Câu hỏi dễ nhầm giữa các quy định gần giống nhau.
Câu hỏi yêu cầu đầu ra JSON, nếu hệ thống cần parse kết quả.
Các tình huống bot cần nêu rõ giới hạn thông tin thay vì trả lời khẳng định.
Một số tiêu chí nghiệp vụ có thể được diễn đạt rõ trong test:
text
Câu trả lời phải ghi số điều khoản khi trích dẫn quy chế.
Câu trả lời không được nêu quyền lợi nếu context không có thông tin đó.
Đầu ra phải đúng định dạng JSON mà ứng dụng yêu cầu.
Lợi thế của cách so sánh này là reviewer có thể thấy trực tiếp prompt mới đã làm một case vốn đạt trở thành không đạt hay chưa.
Regression eval: tìm xu hướng, không chỉ đếm pass/fail
Ragas phù hợp hơn với lượt đánh giá lớn, khi mục tiêu không chỉ là “có lỗi hay không” mà là “chất lượng đang giảm ở tầng nào”.
Một quy trình có thể gồm:
Chạy chatbot với bộ câu hỏi cố định và lưu lại câu trả lời cùng context.
Chạy các chỉ số Ragas.
Nhóm các case điểm thấp theo loại lỗi.
Chấm tay một mẫu nhỏ để đối chiếu.
So sánh với lần chạy trước bằng cùng model chấm và cùng phiên bản prompt chấm.
Tác giả diễn đàn lưu ý rằng các chỉ số dùng LLM để chấm sẽ tốn token. Đồng thời, prompt chấm mặc định bằng tiếng Anh nên với dữ liệu tiếng Việt, kết quả cần được kiểm tra lại một phần bằng tay.
Một thành viên cộng đồng chia sẻ họ đã dịch phần hướng dẫn chấm sang tiếng Việt, thêm ví dụ tiếng Việt có chấm sẵn và đối chiếu thủ công 50 câu. Đây là kinh nghiệm thực tế của người dùng, chưa phải kết quả kiểm chứng độc lập, nhưng nguyên tắc vẫn đáng áp dụng: đừng đổi giám khảo rồi so sánh điểm như thể đang dùng cùng một thước đo.
DeepEval phù hợp khi nào?
Nếu team đã quen với pytest và test automation bằng Python, DeepEval là lựa chọn đáng cân nhắc để đưa tiêu chí đánh giá LLM vào quy trình test quen thuộc.
Điểm đáng chú ý là khả năng tự định nghĩa tiêu chí bằng lời. Chẳng hạn, với chatbot quy chế nội bộ, team có thể đặt yêu cầu như:
text
Khi trích dẫn quy chế, câu trả lời phải ghi số điều khoản.
Câu trả lời không được suy luận thêm ngoài các đoạn tài liệu đã truy xuất.
Với câu hỏi ngoài phạm vi quy chế, chatbot phải nêu rõ giới hạn dữ liệu.
DeepEval không thay thế việc thiết kế test case. Giá trị của nó nằm ở chỗ giúp tiêu chí được viết thành test, chạy lặp lại và đưa vào CI cùng các kiểm tra khác.
Checklist trước khi tin vào dashboard điểm số
[ ] Lưu câu hỏi, context đã lấy về và câu trả lời cuối cho từng case.
[ ] Phân biệt lỗi retrieval với lỗi tạo câu trả lời.
[ ] Chạy smoke test khi thay prompt hoặc model.
[ ] Chạy regression định kỳ để theo dõi xu hướng.
[ ] Giữ cố định model chấm và prompt chấm khi so sánh giữa các lần chạy.
[ ] Chấm tay một mẫu case trước khi tin hoàn toàn vào LLM-as-a-judge.
[ ] Review kỹ các case tiếng Việt mơ hồ, thuật ngữ nội bộ và trích dẫn điều khoản.
Nếu cần một điểm khởi đầu đơn giản, có thể dùng promptfoo để dựng regression test trong CI. Khi cần biết lỗi nằm ở retrieval hay generation, bổ sung Ragas. Với team đã có pytest và nhiều quy tắc nghiệp vụ riêng, DeepEval là lựa chọn phù hợp để mã hóa các tiêu chí đó thành test.
Cuối cùng, công cụ chỉ là phần dễ chọn. Giá trị của bộ eval vẫn nằm ở bộ câu hỏi sát người dùng thật, đáp án hoặc tiêu chí đủ rõ, và việc QA đọc lại các case mà “giám khảo LLM” đã chấm.