Viết bài kiểm tra cho tính năng AI: bắt đầu từ ba mươi trường hợp thật
Nhiều nhóm làm tính năng AI nhưng ít nhóm đo nó. Bài này hướng dẫn bắt đầu bằng đọc ba mươi trường hợp thật, phân loại lỗi, rồi mới viết bài kiểm tra (evals), theo hướng dẫn của Hamel Husain và Shreya Shankar, kèm mẫu bảng ghi, kế hoạch ba buổi chiều và những sai lầm hay gặp.
Dành cho người xây tính năng dùng mô hình ngôn ngữ, kể cả người mới. Từ kỹ thuật nào cũng có giải thích ngắn.
Phương pháp và các con số (30, 100, 100 đến 200 mẫu) lấy từ hướng dẫn của Hamel Husain và Shreya Shankar (mình đọc trực tiếp phần đầu của trang, chưa đọc hết, khoảng một phần ba cuối chưa đọc). Đây là hướng dẫn của người làm nghề, không phải tiêu chuẩn chung. Ví dụ cửa hàng "Hồng" và các con số trong bảng là minh họa dựng lại.
Tóm tắt nhanh#
- Đo một tính năng AI bắt đầu bằng đọc dữ liệu thật, không phải dựng hạ tầng.
- Đọc khoảng 30 trường hợp bằng tay, ghi chú điều sai, rồi gom thành các nhóm lỗi và đếm.
- Viết bài kiểm tra cho lỗi bạn thật sự thấy, không phải lỗi bạn tưởng tượng.
- Dùng mã kiểm tra thường khi có quy tắc rõ. Chỉ dùng mô hình làm giám khảo khi cần phán đoán, và phải đối chiếu với người chấm.
- Chấm đạt hoặc không đạt, không dùng thang điểm.
- Có thể làm trong ba buổi chiều.
Từ khó, nói dễ#
| Thuật ngữ | Nói dễ hiểu |
|---|---|
| Evals | Bài kiểm tra đo chất lượng của tính năng dùng AI. |
| Trace (vết) | Một lần chạy đầy đủ: đầu vào của người dùng, các bước hệ thống làm, đầu ra. |
| Phân tích lỗi | Đọc các trường hợp, ghi điều sai, gom thành nhóm. |
| Mã hóa mở (open coding) | Đọc từng trường hợp và ghi chú tự do điều sai, chưa chia nhóm. |
| Mã hóa trục (axial coding) | Gom các ghi chú thành nhóm lỗi và đếm mỗi nhóm. |
| Giám khảo bằng mô hình (LLM judge) | Dùng một mô hình khác để chấm đạt hoặc không đạt. |
| Nhị phân | Chỉ hai kết quả: đạt hoặc không đạt. |
1. Vì sao cần, và vì sao khó#
Phần mềm thường có đáp án đúng: hàm cộng hai số thì ra tổng. Tính năng AI thì khác: cùng một câu hỏi, mô hình có thể trả lời nhiều cách, và "tốt" là chuyện phán đoán. Nhiều nhóm vì thế bỏ qua việc đo, và chỉ phát hiện lỗi khi khách phàn nàn.
Hướng dẫn của Husain và Shankar nói thẳng: hãy bắt đầu với phân tích lỗi, không phải hạ tầng. Nghĩa là trước khi mua công cụ, dựng bảng điều khiển hay viết giám khảo, hãy ngồi đọc kết quả thật. Điều này nghe nhàm, nhưng nó trả lời câu hỏi quan trọng nhất: tính năng của mình đang hỏng ở đâu?
Bài này nối với Vì sao không nên tin AI tuyệt đối: mô hình có thể trôi chảy mà sai, nên cần một cách đo ngoài cảm giác. Và với OWASP Top 10 cho ứng dụng dùng AI: thử tấn công ứng dụng của bạn cũng là một loại bài kiểm tra.
2. Bước một: có ba mươi trường hợp để đọc#
Theo hướng dẫn, bắt đầu với khoảng 100 trường hợp đa dạng, và tự ghi chú ít nhất 30 trường hợp đầu bằng tay. Mình dùng số 30 như điểm khởi đầu thực hành, đủ nhỏ để làm trong một buổi chiều.
Nếu đã có người dùng thật: lấy các cuộc trò chuyện hoặc yêu cầu thật, chọn đa dạng (dễ, khó, lạ), ẩn thông tin cá nhân.
Nếu chưa có dữ liệu thật, hướng dẫn gợi ý tạo dữ liệu tổng hợp có cấu trúc, đừng chỉ bảo mô hình "viết câu hỏi thử":
- Chọn vài chiều (ví dụ loại vấn đề, tâm trạng khách, độ phức tạp).
- Tự viết khoảng 20 bộ giá trị bằng tay (mỗi chiều một giá trị).
- Nhờ mô hình biến mỗi bộ thành một câu hỏi tự nhiên, ở bước riêng.
- Chạy các câu hỏi qua hệ thống thật và đọc kết quả.
Dữ liệu tổng hợp không cho biết lỗi nào phổ biến trong thực tế. Hãy so với dữ liệu thật khi có.
3. Bước hai: đọc và ghi chú, từng trường hợp một#
Với mỗi trường hợp, người có hiểu biết về lĩnh vực (không phải ai cũng được) viết ghi chú tự do về điều sai, tập trung vào lỗi đầu tiên thấy được. Gọi là mã hóa mở.
Một số lời khuyên từ hướng dẫn:
- Đừng viết tiêu chí trước khi đọc. Tiêu chí thay đổi khi bạn đọc, nên hãy soạn sau.
- Ghi cả những vấn đề không phải lỗi của mô hình, như thiếu tính năng hay liên kết hỏng.
- Đọc tiếp đến khi hết thấy dạng lỗi mới. Nếu sau 100 trường hợp vẫn còn học được, đọc thêm.
- Đừng giao cho người không hiểu lĩnh vực. Hướng dẫn liệt kê điều này trong các sai lầm hay gặp.
Mẫu bảng ghi (gợi ý của mình):
| # | Đầu vào | Đầu ra của hệ thống | Đạt? | Ghi chú lỗi đầu tiên |
|---|---|---|---|---|
| 1 | "Tôi muốn đổi size áo" | Đưa chính sách hoàn tiền | Không | Hiểu nhầm ý, trả lời sang chuyện khác |
| 2 | "Đơn của tôi bao giờ tới?" | Cho ngày giao đúng | Đạt |
4. Bước ba: gom nhóm và đếm#
Từ ghi chú, gom các lỗi giống nhau thành nhóm lỗi và đếm mỗi nhóm. Hướng dẫn gọi đây là mã hóa trục và coi là bước quan trọng nhất, vì nó cho bạn biết nên sửa gì trước và nên viết bài kiểm tra cho lỗi nào.
Ví dụ minh họa (số dựng lại): cửa hàng "Hồng" có trợ lý trả lời khách. Sau khi đọc 30 trường hợp:
| Nhóm lỗi | Số trường hợp | Gợi ý xử lý |
|---|---|---|
| Hiểu nhầm ý, trả lời sang chuyện khác | 9 | Sửa lời nhắc, thêm ví dụ |
| Bịa thông tin (ngày giao, giá) | 6 | Bắt buộc lấy từ hệ thống đơn hàng, kiểm tra bằng mã |
| Giọng quá cứng, không xin lỗi khi khách bực | 5 | Có thể dùng giám khảo, cần đối chiếu người |
| Trả lời đúng nhưng quá dài | 4 | Kiểm tra độ dài bằng mã |
| Không chuyển cho người khi cần | 3 | Quy tắc rõ, kiểm tra bằng mã |
| Khác | 3 | Theo dõi tiếp |
Chỉ riêng bảng này đã cho bạn ba việc đầu tiên để sửa và đo. Đó là lý do bắt đầu từ đọc dữ liệu.
5. Bước bốn: viết bài kiểm tra cho lỗi thật#
Với mỗi nhóm lỗi, chọn loại kiểm tra:
| Loại | Dùng khi | Ví dụ |
|---|---|---|
| Mã kiểm tra thường | Quy tắc xác định được | Đầu ra là JSON hợp lệ, có đủ trường, độ dài dưới 120 từ, ngày giao khớp hệ thống |
| Giám khảo bằng mô hình | Lỗi cần phán đoán kiểu người | "Trợ lý có xin lỗi khi khách tỏ ra bực không" |
Theo hướng dẫn: trước khi dựng giám khảo, hãy xem một quy tắc bằng mã có làm được không, vì giám khảo có chi phí bảo trì thật. Mỗi giám khảo chỉ lo một loại lỗi, đừng bắt một giám khảo bắt nhiều lỗi cùng lúc.
Dùng đạt hoặc không đạt. Hướng dẫn nêu lý do: thang điểm (như 1 đến 5) có khoảng cách giữa các mức không nhất quán, cần mẫu lớn hơn và dễ bị chấm giữa. Muốn theo dõi tiến bộ từng chút, chia thành nhiều kiểm tra nhị phân nhỏ, ví dụ "có bốn trên năm điều cần nói".
6. Bước năm: đừng tin giám khảo khi chưa kiểm#
Nếu dùng mô hình làm giám khảo, hãy kiểm tra giám khảo như kiểm tra mọi thứ khác. Theo hướng dẫn:
- Gắn nhãn khoảng 100 đến 200 mẫu cho mỗi loại lỗi, tối thiểu khoảng 50 đạt và 50 không đạt.
- Chia dữ liệu: một phần nhỏ làm ví dụ trong lời nhắc, phần còn lại chia cho tập phát triển và tập kiểm tra giữ riêng.
- Đo tỷ lệ bắt đúng lỗi thật (giám khảo bắt được bao nhiêu lỗi có thật) và tỷ lệ cho qua đúng mẫu tốt.
- Xem các chỗ giám khảo và người bất đồng trước khi chỉnh lời nhắc cho giám khảo.
- Nếu điểm trên tập kiểm tra tệ hơn nhiều so với tập phát triển, có thể bạn đã làm giám khảo quá khít với một tập.
Phần này tốn công, nên đừng vội. Mình mới đọc phần đầu hướng dẫn và chưa kiểm chứng lại các con số, nên hãy coi chúng là điểm khởi đầu của người làm nghề.
7. Kế hoạch ba buổi chiều#
| Buổi | Việc | Đầu ra |
|---|---|---|
| 1 | Thu 30 trường hợp (thật, hoặc tổng hợp có cấu trúc). Chạy qua hệ thống thật | Bảng 30 dòng với đầu vào và đầu ra |
| 2 | Đọc từng trường hợp, chấm đạt hoặc không, ghi lỗi đầu tiên | Bảng ghi chú |
| 3 | Gom nhóm, đếm, chọn ba nhóm lớn nhất, viết ba bài kiểm tra (ưu tiên mã) | Bảng nhóm lỗi và ba kiểm tra chạy được |
Sau ba buổi bạn có: danh sách lỗi theo mức phổ biến, ba bài kiểm tra tự động, và một thói quen: mỗi lần đổi đáng kể, dành khoảng nửa tiếng đọc 20 đến 50 kết quả, đúng như hướng dẫn gợi ý như mức tối thiểu.
8. Sai lầm hay gặp#
Theo hướng dẫn:
- Bỏ qua phân tích lỗi và dùng chỉ số chung như "hữu ích".
- Viết bài kiểm tra cho lỗi tưởng tượng thay vì lỗi đã thấy.
- Một giám khảo bắt nhiều lỗi cùng lúc.
- Tin giám khảo mà không đối chiếu với người.
- Chạy theo 100% đạt. Hướng dẫn gợi ý rằng tỷ lệ khoảng 70% có thể là dấu hiệu bài kiểm tra đủ khó.
- Giao phân tích lỗi cho người không hiểu lĩnh vực.
9. Nhìn cân bằng#
- Đây là hướng dẫn của người làm nghề. Con số 30, 100, 100 đến 200 là điểm khởi đầu, không phải tiêu chuẩn đã được kiểm chứng rộng.
- Mình chưa đọc hết hướng dẫn. Khoảng một phần ba cuối trang chưa đọc, nên bài này chưa bao quát hết.
- Evals tốn công. Với một nguyên mẫu dùng một lần, bạn có thể chưa cần. Hãy làm khi tính năng có người dùng thật hoặc rủi ro đáng kể.
- Bài kiểm tra tự động không thay được việc đọc. Hướng dẫn nhấn mạnh việc xem dữ liệu thật. Tự động hóa chỉ giữ cho những gì đã học không hỏng lại.
- Ví dụ cửa hàng "Hồng" là minh họa, các con số do mình dựng để dễ hình dung.
10. Kết luận#
Đo một tính năng AI không bắt đầu bằng công cụ. Nó bắt đầu bằng một buổi chiều đọc ba mươi trường hợp thật và một cây bút. Từ đó bạn biết tính năng hỏng ở đâu, mới viết bài kiểm tra cho đúng chỗ.
Việc nhỏ làm ngay: lấy ba mươi kết quả gần nhất của tính năng AI bạn đang làm, đọc từng cái, và ghi một dòng về điều sai ở mỗi cái. Rồi đếm.
Nguồn tham khảo#
Câu hỏi thường gặp
- Evals là gì?
- Là các bài kiểm tra đo chất lượng của một tính năng dùng mô hình ngôn ngữ, như bộ trợ lý trả lời khách. Khác với kiểm thử phần mềm thông thường, đầu ra của mô hình thay đổi và không có một đáp án duy nhất, nên cần cách chấm riêng, thường bắt đầu bằng việc đọc các trường hợp thật.
- Cần bao nhiêu trường hợp để bắt đầu?
- Theo hướng dẫn của Hamel Husain và Shreya Shankar, bắt đầu với khoảng 100 trường hợp đa dạng và tự ghi chú ít nhất 30 trường hợp đầu bằng tay, rồi đọc tiếp đến khi không còn thấy dạng lỗi mới. Con số 30 là điểm khởi đầu thực hành, không phải ngưỡng khoa học.
- Nên chấm bằng thang điểm hay đạt và không đạt?
- Hướng dẫn trên khuyên dùng đạt hoặc không đạt, vì thang điểm cho khoảng cách giữa các mức không nhất quán, cần mẫu lớn hơn và hay bị chấm giữa. Nếu muốn theo dõi tiến bộ từng chút, chia thành nhiều kiểm tra nhị phân nhỏ.
- Có nên dùng mô hình làm giám khảo không?
- Chỉ khi lỗi cần phán đoán kiểu người và không bắt được bằng quy tắc xác định. Mỗi giám khảo nên lo một loại lỗi, và phải được đối chiếu với nhãn của người trên một tập có cả mẫu đạt lẫn không đạt, nếu không bạn không biết có nên tin nó.