Một chatbot chỉ cần trả lời đúng vài câu demo không có nghĩa là đã sẵn sàng cho người dùng thực tế. Ứng dụng LLM có thể trả lời khác nhau với cùng một input, gặp hiện tượng hallucinate, sử dụng sai nguồn, phản hồi chậm, hoặc phát sinh chi phí cao khi lưu lượng truy cập tăng.
Direct Answer: Đánh giá ứng dụng LLM trước khi sử dụng
Hãy xây dựng một bộ thử nghiệm phản ánh tình huống thực tế và đo lường ít nhất sáu nhóm tiêu chí: chất lượng câu trả lời, độ bám nguồn, an toàn, độ trễ, chi phí, và mức độ cần sự kiểm tra của con người. Chỉ nên triển khai khi các chỉ số đạt ngưỡng chấp nhận đã được xác định trước.
Vì sao đánh giá LLM không giống phần mềm thông thường?
Với phần mềm truyền thống, một input thường dẫn đến một output xác định. Trong khi đó, ứng dụng LLM có tính biến thiên: cùng một yêu cầu có thể tạo ra câu trả lời khác nhau giữa các lần chạy. Vì vậy, kiểm thử kiểu “đầu vào A phải cho chính xác chuỗi B” thường không đủ.
OpenAI khuyến nghị rằng eval phải phản ánh đúng tác vụ thực tế, được thực hiện sớm và lặp lại thường xuyên; đồng thời không chỉ dựa vào các metric chung hoặc đánh giá cảm tính kiểu “trông có vẻ hoạt động tốt”.
NIST cũng đặt việc đo lường và đánh giá trong vòng đời quản trị rủi ro AI, thay vì xem evaluation là một bước cuối cùng trước khi launch.
Một quy trình hợp lý nên là: Define → Build test set → Run → Score → Human review → Fix → Regression test
Khung 6 nhóm tiêu chí để đánh giá ứng dụng LLM
- Chất lượng: Câu trả lời có giải quyết đúng yêu cầu? (Accuracy, task success)
- Bám nguồn: Nội dung có được hỗ trợ bởi context? (Groundedness, citation accuracy)
- An toàn: Hệ thống có xử lý input nguy hiểm đúng cách? (Safety pass rate)
- Độ trễ: Người dùng phải chờ bao lâu? (P50, P95 latency)
- Chi phí: Một task thành công tốn bao nhiêu? (Cost/task, token/task)
- Human review: Trường hợp nào phải chuyển người kiểm tra? (Escalation rate)
Không phải mọi ứng dụng đều cần cùng một trọng số. Chatbot tra cứu tài liệu nội bộ có thể đặt groundedness lên cao, trong khi trợ lý chăm sóc khách hàng cần chú ý tới safety và escalation.
1. Đánh giá chất lượng câu trả lời
Tiêu chí đầu tiên là ứng dụng có hoàn thành đúng công việc được giao hay không. Không nên dùng tiêu chí mơ hồ như “câu trả lời tốt”. Hãy tách thành những yếu tố có thể chấm được. Ví dụ với chatbot hỗ trợ khách hàng:
- Có hiểu đúng intent không?
- Có trả lời đúng câu hỏi không?
- Có bỏ sót thông tin quan trọng không?
- Có đưa ra bước tiếp theo phù hợp không?
- Có tuân thủ định dạng yêu cầu không?
Có thể chấm theo thang đơn giản:
- 2 điểm: đạt đầy đủ.
- 1 điểm: đúng một phần.
- 0 điểm: sai hoặc không giải quyết nhiệm vụ.
Với các tác vụ phân loại hoặc trích xuất dữ liệu, nên ưu tiên metric xác định như accuracy, precision hoặc recall khi phù hợp. Với câu trả lời tự do, có thể kết hợp rule-based scoring, LLM-as-a-judge và đánh giá của con người. Điểm quan trọng là tiêu chí phải gắn với task success, không phải chỉ với khả năng viết câu văn tự nhiên.
2. Kiểm tra độ bám nguồn và hallucination
Với chatbot RAG hoặc ứng dụng trả lời dựa trên knowledge base, một câu trả lời nghe hợp lý vẫn có thể sai nếu model tự bổ sung thông tin ngoài tài liệu. Nên đánh giá riêng ít nhất ba yếu tố.
- Context relevance: Dữ liệu retrieval đưa vào model có thực sự liên quan tới câu hỏi không? Nếu retrieval sai, model rất khó trả lời đúng ngay cả khi prompt tốt.
- Groundedness: Các khẳng định trong câu trả lời có được hỗ trợ bởi context đã cung cấp hay không? Nếu model đưa thêm dữ liệu không có trong nguồn, đó là tín hiệu cần kiểm tra.
- Citation correctness: Nếu ứng dụng hiển thị citation hoặc nguồn tham khảo, nguồn đó có thực sự chứng minh cho câu trả lời không? Không nên chỉ kiểm tra xem “có citation hay không”. Citation phải đúng với claim tương ứng.
NIST Generative AI Profile nhấn mạnh các rủi ro liên quan tới confabulation và tính tin cậy của nội dung sinh bởi AI, vì vậy việc đo groundedness nên được xem là một phần của quản trị rủi ro chứ không chỉ là kiểm tra UX.