AI Evals - Chấm bài cho chatbot trước khi user chấm hộ

Team sản phẩm vừa làm xong một con chatbot chăm sóc khách hàng.

Trong buổi demo, PM lần lượt nhập 5 câu hỏi đã chuẩn bị sẵn:

“Đơn hàng của tôi đang ở đâu?”

“Tôi muốn đổi địa chỉ nhận hàng.”

“Sản phẩm này được bảo hành bao lâu?”

“Làm thế nào để đổi mật khẩu?”

“Tôi có thể thanh toán bằng hình thức nào?”

Chatbot trả lời được cả 5. Nội dung đúng, giọng văn lịch sự, trả lời nhanh hơn cả nhân viên CS. Mọi người trong phòng họp gật gù, con chatbot này có vẻ sẵn sàng để release rồi.

Nếu có kiểu demo nào khiến mình hơi lo thì chính là kiểu demo này.

Năm câu hỏi đều được team chọn trước. Team biết chatbot có dữ liệu gì, biết nên hỏi bằng từ nào và cũng biết câu trả lời đúng trông ra sao. Nói đơn giản thì chúng mình đã đưa đúng 5 câu tủ cho thí sinh ôn trước, sau đó khá bất ngờ khi thí sinh đạt 10 điểm.

User thật sẽ không hợp tác như vậy.

Họ viết sai chính tả, hỏi thiếu context, gộp ba vấn đề vào một câu, dùng những từ mà team chưa nghĩ tới. Có người đang bực còn nhắn một đoạn dài như sớ, đọc đến cuối quên luôn câu hỏi nằm ở đâu.

Ví dụ như:

“Mình mua đôi giày hôm sale, có dùng voucher, giờ nhận về bị bong keo mà trên app lại ghi không hỗ trợ trả hàng khuyến mại, thế bên bạn đổi đôi khác hay trả lại tiền cho mình?”

Chatbot có thể trả lời rất trơn tru rằng khách sẽ được hoàn tiền 100% trong 24 giờ. Nghe đã đời, chỉ có điều chính sách của công ty không nói thế.

Năm câu demo vừa rồi không hề báo trước lỗi này.

Evals là gì?

Evals là cách chúng mình kiểm tra hành vi của một hệ thống AI bằng một tập tình huống, kết quả mong đợi và phương pháp chấm điểm tương ứng.

Nó khá giống việc làm test cho phần mềm, cơ mà output của AI không phải lúc nào cũng cố định. Với một nút Thanh toán, chúng mình có thể kiểm tra bấm vào thì request có được gửi hay không. Với chatbot, hai câu trả lời dùng từ khác nhau vẫn có thể đều đúng. Ngược lại, một câu nghe rất hay vẫn có thể sai đúng một con số quan trọng.

Vậy nên một eval case thường cần nhiều hơn câu hỏi và đáp án mẫu.

Quay lại trường hợp đôi giày bong keo, team có thể ghi lại như sau:

Input:

User mua hàng bằng voucher, sản phẩm nhận được bị lỗi,

muốn biết có được đổi hoặc hoàn tiền hay không.

Kết quả mong đợi:

- Xác định đây là hàng lỗi, không phải đổi trả do thay đổi nhu cầu.

- Không tự hứa thời gian hoàn tiền khi chưa đủ thông tin.

- Hỏi mã đơn hàng hoặc hướng dẫn user gửi bằng chứng sản phẩm lỗi.

- Dẫn đúng chính sách đổi trả liên quan.

Lỗi nghiêm trọng:

- Từ chối hỗ trợ chỉ vì đơn hàng có dùng voucher.

- Bịa ra chính sách hoặc hứa hoàn tiền chắc chắn.

Đáp án của chatbot không cần giống từng chữ. Nó chỉ cần làm đúng những việc quan trọng và không phạm vào những lỗi có thể làm user mất tiền, mất thời gian hoặc nổi giận thêm.

Năm 2020, nhóm nghiên cứu CheckList đã đề xuất cách kiểm thử hành vi cho các mô hình NLP, lấy cảm hứng từ việc test phần mềm. Thay vì chỉ nhìn vào accuracy trên một tập dữ liệu, họ kiểm tra các khả năng và hành vi cụ thể của model. Trong một user study, team phụ trách một model sentiment analysis thương mại còn tìm được những lỗi mới dù model trước đó đã được test khá kỹ rồi.

Nguồn: Beyond Accuracy: Behavioral Testing of NLP Models with CheckList

Phần mình thích ở cách tiếp cận này là lỗi được viết ra thành tình huống cụ thể. Team không còn ngồi tranh luận chung chung rằng chatbot “có vẻ thông minh hơn” sau khi đổi prompt. Chạy lại bộ eval là biết câu hỏi cũ còn sống hay đã toang.

Đừng gom mọi thứ vào một điểm

Giả sử bộ eval có 100 câu và chatbot trả lời đúng 90 câu. Accuracy bằng 90%, nhìn cũng ổn.

Nhưng 10 câu sai là câu nào?

Nếu chatbot viết hơi dài ở 10 câu hỏi hướng dẫn đổi mật khẩu thì chưa chắc đã nghiêm trọng. Nếu nó tư vấn sai 10 trường hợp hoàn tiền có giá trị lớn thì 90% kia chả làm ai yên tâm hơn được.

Với sản phẩm AI, mình sẽ chia lỗi theo tác động trước khi tính điểm tổng. Một cách đơn giản có thể là:

Critical: Làm user mất tiền, lộ dữ liệu, thực hiện sai một hành động khó hoàn tác hoặc đưa ra lời khuyên nguy hiểm.

Major: Trả lời sai nhu cầu chính, bịa chính sách, bỏ qua điều kiện quan trọng hoặc khiến user phải làm lại từ đầu.

Minor: Dài dòng, hơi lệch tone, format chưa đẹp nhưng thông tin chính vẫn dùng được.

Chatbot có thể đạt 95% tổng điểm mà vẫn chưa được release vì còn một lỗi Critical. Ngược lại, một loạt lỗi dấu câu chưa chắc đáng để chặn cả team thêm hai tuần.

HELM, một framework đánh giá language model của Stanford, cũng nhấn mạnh việc đánh giá trên nhiều scenarios và nhiều metrics thay vì xoay quanh một con số duy nhất. Accuracy quan trọng, nhưng robustness, fairness, efficiency và các rủi ro khác có thể làm kết luận thay đổi tùy sản phẩm.

Nguồn: Stanford CRFM - Holistic Evaluation of Language Models

Ở cấp độ sản phẩm, chúng mình không nhất thiết bê toàn bộ bộ metric của HELM về. Một chatbot viết caption và một chatbot hướng dẫn sử dụng thuốc rõ ràng không thể dùng chung ngưỡng release. Team cần chọn những hành vi gắn với thiệt hại thật nếu AI làm sai.

Với chatbot chăm sóc khách hàng ở trên, mình sẽ ưu tiên độ chính xác của chính sách, khả năng nhận ra khi thiếu thông tin, việc bảo vệ dữ liệu cá nhân, tỷ lệ chuyển đúng sang nhân viên CS và thời gian phản hồi. Tone vui vẻ có thể sửa sau. Hứa hoàn tiền nhầm thì không vui lắm đâu.

Ai sẽ chấm bài cho AI?

Có những eval chấm khá dễ.

Nếu yêu cầu chatbot trích mã đơn hàng, chúng mình có thể dùng code để kiểm tra output có đúng format hay không. Nếu hệ thống cần gọi tool cancel_order, test có thể kiểm tra đúng tool, đúng order ID và không gọi khi user chưa xác nhận.

Cơ mà nhiều câu trả lời mở không có một đáp án duy nhất. Lúc này thường có ba cách chấm.

Dùng rule hoặc code

Cách này nhanh, rẻ và chạy lại ổn định. Nó hợp với những thứ đo được rõ ràng như JSON schema, keyword bắt buộc, link nguồn, latency, số token hay việc có gọi đúng tool không.

Rule cũng khá ngốc. Chatbot có thể chứa đủ keyword nhưng ghép thành một câu trả lời sai be bét. Đếm được chữ “hoàn tiền” chưa có nghĩa là nó đã hiểu chính sách hoàn tiền.

Để con người chấm

Người có chuyên môn vẫn là lựa chọn đáng tin với những trường hợp cần hiểu context, tone hoặc hậu quả nghiệp vụ. Nhân viên CS biết một câu trả lời có thật sự giúp được khách hay chỉ đang nói cho có.

Đổi lại, chấm tay chậm và tốn kém. Hai người đôi khi còn không đồng ý với nhau, nên rubric phải đủ cụ thể để mọi người biết mình đang chấm điều gì.

Dùng một LLM khác làm judge

Cho AI chấm AI nghe hơi giống giao bài kiểm tra cho đứa ngồi cùng bàn, nhưng cách này khá hữu ích khi bộ eval có hàng nghìn câu và output khó chấm bằng code.

Nghiên cứu về MT-Bench cho thấy những LLM mạnh có thể đạt mức đồng thuận khá cao với preference của con người. Đồng thời, LLM judge cũng có bias: nó có thể bị ảnh hưởng bởi vị trí của câu trả lời, thích câu dài hơn hoặc ưu ái output có phong cách giống chính nó.

Nguồn: Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena

Vì thế, nếu dùng LLM làm judge, team vẫn nên lấy một tập kết quả đã được con người chấm để kiểm tra judge trước. Thỉnh thoảng đảo vị trí hai câu trả lời, xem lại những case judge thiếu chắc chắn và luôn giữ một phần human review cho các lỗi nghiêm trọng.

Đến đây hơi giống đang xây thêm một con AI để canh con AI ban đầu rồi đấy. Đúng là như vậy thật.

Bộ eval nên lấy câu hỏi ở đâu?

Lúc chưa có sản phẩm, team có thể bắt đầu từ user journey, chính sách nghiệp vụ, dữ liệu research và những lỗi mà mình sợ nhất. Mỗi nhánh quan trọng cần ít nhất vài cách hỏi khác nhau, bao gồm cả câu thiếu dữ kiện và câu mà chatbot nên từ chối.

Sau khi có beta users, conversation logs bắt đầu trở thành nguồn bài thi tốt hơn nhiều. Mỗi lần chatbot trả lời sai, team sửa lỗi xong thì đưa chính câu đó hoặc một phiên bản đã ẩn thông tin cá nhân vào bộ eval. Nếu không làm vậy, ba tháng sau đổi model hoặc sửa system prompt, con lỗi cũ có thể bò về như chưa từng quen biết.

Mình sẽ giữ vài nhóm cơ bản:

• Những nhu cầu phổ biến nhất của user.
• Edge cases có tác động lớn.
• Câu hỏi thiếu hoặc mâu thuẫn thông tin.
• Cách diễn đạt khác nhau của cùng một nhu cầu.
• Những yêu cầu chatbot phải từ chối hoặc chuyển cho con người.

Số lượng không cần hoành tráng ngay từ đầu. Năm mươi câu đại diện cho sản phẩm còn có ích hơn năm nghìn câu tải từ một benchmark chả liên quan đến user của mình.

Và bộ eval này phải được chạy lại mỗi khi team đổi model, prompt, RAG pipeline, tool hoặc policy. Một thay đổi giúp câu A tốt hơn hoàn toàn có thể làm câu B hỏng. Đó là regression, thứ phần mềm bình thường đã chịu đựng lâu rồi, AI không được miễn.

NIST cũng đặt việc test trước khi triển khai, đánh giá thường xuyên và theo dõi rủi ro trong quá trình vận hành vào hướng dẫn quản trị rủi ro cho Generative AI. Hành vi ngoài production sẽ tiếp tục thay đổi theo input, context và cách user sử dụng, nên một lần test đẹp trước ngày release chưa đủ dùng mãi.

Nguồn: NIST AI RMF - Generative AI Profile

Lời nhắn

Năm câu hỏi demo ở đầu bài vẫn có ích. Chúng giúp team nhìn thấy một happy path hoàn chỉnh và giải thích tính năng cho stakeholder dễ hơn.

Trước khi release, hãy mở thêm một file gồm những câu hỏi xấu xí hơn: câu viết sai, câu thiếu context, câu có nhiều ý, câu dễ gây thiệt hại và câu mà chatbot không được phép trả lời bừa. Chấm chúng bằng code khi có thể, dùng LLM judge khi cần scale và giữ con người ở những nơi sai một cái là mệt.

User chắc chắn sẽ nghĩ ra câu hỏi thứ 101 mà team chưa từng thấy.

Ít nhất 100 câu đầu tiên đừng để user phải nghĩ hộ mình.

---

Bài gốc trên Substack: https://henrypham.substack.com/p/ai-evals-cham-bai-cho-chatbot-truoc