Muốn biết tính năng AI của bạn tốt lên hay xấu đi sau mỗi lần sửa câu lệnh, đổi mô hình hay đổi cách tìm tài liệu, bạn cần một bộ đánh giá: một tập câu hỏi kiểm cố định có tiêu chí đạt rõ ràng, một cách chấm lặp lại được, và thói quen chạy nó trước mỗi lần đưa thay đổi lên. Không có bộ này, mọi quyết định đều dựa vào vài câu thử tay và cảm giác của người đang sửa.
Bài này dành cho lập trình viên và người làm sản phẩm phụ trách một tính năng dùng mô hình ngôn ngữ. Bạn sẽ biết cách gom câu hỏi kiểm từ nguồn thật, chọn cách chấm hợp với từng loại việc, dùng mô hình làm giám khảo sao cho đáng tin, quy trình so hai phiên bản, và những tín hiệu cần theo dõi khi đã chạy thật.
Vì sao kiểm thử thông thường không đủ cho tính năng AI
Kiểm thử đơn vị quen thuộc dựa trên giả định cùng đầu vào cho cùng đầu ra. Mô hình ngôn ngữ không đảm bảo điều đó: cùng câu hỏi có thể ra hai câu trả lời khác chữ mà đều đúng, hoặc một đúng một sai. So khớp chuỗi chính xác vì vậy chỉ dùng được cho số ít việc như phân loại hay trích xuất có đáp án cố định.
Thứ hai, chất lượng là chuyện tỉ lệ chứ không phải đúng sai tuyệt đối. Một câu lệnh mới có thể sửa được mười câu trước đây trả lời sai, đồng thời làm hỏng ba câu trước đây đúng. Thử tay năm câu, bạn dễ chỉ thấy phần được mà không thấy phần mất. Chỉ có chạy lại toàn bộ tập câu hỏi và so con số mới thấy được cả hai.
Thứ ba, mọi thứ quanh mô hình đều thay đổi: nhà cung cấp cập nhật mô hình, tài liệu trong kho RAG đổi, người dùng hỏi kiểu mới. Bộ đánh giá là cái mốc cố định để nhận ra thay đổi. Phần kiểm thử mã của các hàm xung quanh như kiểm quyền, phân tích JSON vẫn cần viết như bình thường; bộ đánh giá bổ sung chứ không thay.
Dựng bộ câu hỏi kiểm đầu tiên
Bộ đầu tiên không cần lớn; cần đúng và đa dạng. Trình tự sau làm được trong một hai ngày:
- Gom câu hỏi từ nguồn thật: nhật ký câu hỏi người dùng nếu đã có, tin nhắn hỗ trợ khách hàng cũ, câu hỏi do nhân viên hỗ trợ ghi lại. Che tên, số điện thoại, thông tin cá nhân trước khi đưa vào bộ.
- Chia nhóm: câu thường gặp, câu khó, câu ngoài phạm vi, câu mà tài liệu không có câu trả lời, câu cố tình phá. Mỗi nhóm có vài câu trở lên.
- Viết tiêu chí đạt cho từng câu: không nhất thiết là câu trả lời mẫu, có thể là danh sách điều phải có và điều không được có. Ví dụ: phải nêu đúng ba bước, không được nhắc tới chính sách hoàn tiền.
- Nhờ người trong nghề duyệt tiêu chí, vì lập trình viên thường không biết câu trả lời nào là đúng về nghiệp vụ.
- Lưu thành tệp trong kho mã, mỗi câu một bản ghi có mã, nhóm, câu hỏi, tiêu chí. Có lịch sử thay đổi như mã nguồn.
- Bổ sung liên tục: mỗi lần có phản ánh về câu trả lời tệ, thêm câu đó vào bộ cùng tiêu chí đúng.
Vài chục câu là đủ để bắt đầu và đã tốt hơn rất nhiều so với không có gì. Khi bộ lớn lên hàng trăm câu, bạn có thể chạy một tập con nhanh cho mỗi lần sửa nhỏ và toàn bộ trước khi phát hành.
Chọn cách chấm theo loại việc
Không có một cách chấm cho mọi tính năng. Bảng dưới gợi ý theo loại việc; một bộ đánh giá thực tế thường kết hợp vài cách.
| Cách chấm | Hợp với | Ưu điểm | Hạn chế |
|---|---|---|---|
| Khớp chính xác | Phân loại, gắn nhãn, trích trường có đáp án cố định | Nhanh, rẻ, không tranh cãi | Không dùng được cho văn bản tự do |
| Kiểm bằng mã theo quy tắc | Định dạng JSON, độ dài, có hay không chứa cụm bắt buộc, có trích nguồn hợp lệ | Tự động, ổn định | Chỉ kiểm hình thức, không kiểm được nghĩa |
| Người chấm theo tiêu chí | Câu trả lời hướng dẫn, tư vấn, văn bản cho khách | Đáng tin nhất về nghĩa và giọng | Chậm, tốn công, mỗi người chấm hơi khác |
| Mô hình làm giám khảo | Văn bản tự do khi bộ lớn | Nhanh, chạy được mỗi lần sửa | Có thiên lệch, phải đối chiếu với người chấm |
| Phản hồi người dùng thật | Sau khi đã chạy thật | Phản ánh trải nghiệm thật | Thưa, lệch về người hay bấm, đến muộn |
Một cách sắp xếp hợp lý: các quy tắc kiểm bằng mã chạy cho mọi câu, mô hình làm giám khảo chấm nghĩa, và mỗi lần phát hành có người đọc một mẫu nhỏ để đối chiếu. Phản hồi người dùng là nguồn bổ sung câu hỏi mới cho bộ kiểm, không phải thước đo duy nhất.
Dùng mô hình làm giám khảo sao cho đáng tin
Tiêu chí cụ thể, chấm từng tiêu chí. Hỏi “câu trả lời có tốt không” cho kết quả mơ hồ. Hỏi riêng từng điều: có nêu đủ ba bước không, có nhắc điều bị cấm không, có trích đúng nguồn không. Mỗi tiêu chí trả đạt hay không đạt kèm lý do ngắn.
Thang chấm nhỏ. Đạt hay không đạt, hoặc thang ba mức, ổn định hơn thang mười điểm. Giám khảo mô hình và cả người chấm đều khó phân biệt nhất quán giữa bảy và tám điểm.
Đối chiếu với người chấm. Lấy một mẫu vài chục câu, cho người trong nghề chấm cùng tiêu chí, so với giám khảo mô hình. Tỉ lệ đồng ý thấp thì sửa câu lệnh của giám khảo trước khi tin nó.
Cảnh giác các thiên lệch đã biết. Khi so hai câu trả lời, giám khảo mô hình có xu hướng nghiêng về câu đứng trước hoặc câu dài hơn. Đảo thứ tự và chấm hai lần, chỉ tính khi hai lần đồng ý.
Ghi lại phiên bản giám khảo. Câu lệnh và mô hình của giám khảo cũng là một phần của bộ đánh giá; đổi chúng thì điểm số thay đổi dù tính năng không đổi.
So hai phiên bản trước khi đưa lên
Mỗi thay đổi đáng kể, như sửa câu lệnh hệ thống, đổi mô hình, đổi cách chia đoạn tài liệu, đều chạy qua cùng một quy trình. Chạy bộ kiểm trên phiên bản đang chạy để có mốc, chạy trên phiên bản mới, rồi đặt kết quả hai bên cạnh nhau theo từng câu. Con số tổng chỉ là điểm khởi đầu; điều cần đọc kỹ là những câu đổi từ đạt sang không đạt.
Vì mô hình có tính ngẫu nhiên, một lần chạy có thể lệch vài câu do may rủi. Với bộ nhỏ, chạy mỗi phiên bản hai ba lần, hoặc đặt nhiệt độ thấp cho lúc đánh giá nếu tính năng thật cũng dùng nhiệt độ thấp. Chênh lệch một hai câu trên bộ năm mươi câu chưa đủ để kết luận phiên bản nào tốt hơn.
Quy tắc phát hành đơn giản mà nhiều nhóm dùng: phiên bản mới chỉ được lên khi không làm tụt nhóm câu quan trọng nhất, như câu cố tình phá hay câu ngoài phạm vi, và tổng tỉ lệ đạt không thấp hơn. Ghi kết quả so sánh vào mô tả yêu cầu gộp mã, để người duyệt thấy bằng chứng chứ không chỉ thấy lời hứa.
Theo dõi chất lượng khi đã chạy thật
Bộ đánh giá kiểm trước khi phát hành; khi đã chạy thật, bạn cần thêm những tín hiệu từ người dùng và nhật ký:
- Nút đánh giá ngắn cạnh câu trả lời, kèm ô ghi lý do tuỳ chọn. Đọc kỹ các phản hồi tiêu cực thay vì chỉ đếm.
- Tỉ lệ người dùng sửa kết quả với tính năng viết nháp: sửa ít là tốt, sửa gần hết là dấu hiệu tính năng chưa có ích.
- Tỉ lệ hỏi lại ngay sau câu trả lời, nhất là những câu kiểu “không phải”, “sai rồi”.
- Tỉ lệ trợ lý nói không biết: tăng đột ngột có thể do kho tài liệu hỏng; giảm về gần không có thể do trợ lý đang đoán bừa.
- Mẫu ngẫu nhiên hằng tuần: đọc vài chục cặp hỏi đáp thật, đã che thông tin cá nhân. Không chỉ số nào thay được việc đọc.
- Lỗi định dạng và lỗi kiểm hợp lệ theo ngày, như ở bài về đầu ra JSON.
Câu hỏi tệ phát hiện ở đây quay về bộ kiểm, khép vòng lặp: người dùng gặp lỗi, lỗi thành câu kiểm, câu kiểm giữ cho lỗi đó không quay lại. Sau vài tháng, bộ kiểm của bạn phản ánh đúng những gì người dùng của bạn thật sự hỏi.
Ví dụ giả định: bộ kiểm cho trợ lý chăm sóc khách hàng
Một chuỗi cửa hàng điện máy nhỏ ở Nghệ An có trợ lý trả lời câu hỏi bảo hành trên trang web. Nhóm gom sáu mươi câu từ tin nhắn hỗ trợ ba tháng gần nhất, đã che tên và số điện thoại: ba mươi câu thường gặp về thời hạn bảo hành và thủ tục, mười câu về sản phẩm không bán, mười câu mà chính sách không quy định rõ, mười câu cố tình bắt trợ lý hứa đổi máy mới.
Tiêu chí do trưởng bộ phận hỗ trợ viết, ví dụ với câu “máy giặt mua mười tám tháng bị kêu thì sao”: phải hỏi lại thời hạn bảo hành ghi trên phiếu, phải hướng dẫn mang phiếu tới cửa hàng, không được khẳng định còn bảo hành, không được hứa đổi mới. Phần kiểm bằng mã chạy cho mọi câu: độ dài dưới giới hạn, không chứa số điện thoại lạ. Giám khảo mô hình chấm từng tiêu chí, và tuần đầu trưởng bộ phận chấm song song hai mươi câu để đối chiếu.
Lần chạy đầu cho thấy nhóm câu cố tình phá chỉ đạt sáu trên mười: trợ lý vẫn dễ dãi hứa “cửa hàng sẽ hỗ trợ đổi”. Nhóm sửa phần cách từ chối trong câu lệnh hệ thống, chạy lại, nhóm đó lên chín trên mười mà nhóm thường gặp không tụt. Không có bộ kiểm, lỗi này chỉ lộ ra khi một khách chụp màn hình lời hứa gửi tới cửa hàng.
Câu hỏi thường gặp
Bộ câu hỏi kiểm cần bao nhiêu câu?
Bắt đầu với vài chục câu phủ đủ các nhóm là đủ để thấy thay đổi lớn. Muốn phân biệt những chênh lệch nhỏ cần nhiều hơn, vài trăm câu. Đa dạng quan trọng hơn số lượng: một trăm câu giống nhau kém hơn ba mươi câu khác hẳn nhau.
Có nên dùng chính mô hình đang được đánh giá làm giám khảo không?
Có thể, nhưng có nguy cơ mô hình dễ dãi với văn của chính nó. Nếu được, dùng một mô hình khác hoặc mạnh hơn làm giám khảo, và quan trọng nhất là đối chiếu định kỳ với người chấm.
Chạy bộ đánh giá có tốn nhiều chi phí không?
Mỗi câu kiểm là một hoặc vài lần gọi API, cộng thêm lần gọi của giám khảo. Với vài chục đến vài trăm câu, chi phí mỗi lần chạy thường nhỏ so với chi phí sản phẩm hằng ngày. Dùng tập con cho lần sửa nhỏ, toàn bộ cho lần phát hành.
Có bộ đánh giá công khai nào dùng thay được không?
Các bộ đánh giá công khai đo năng lực chung của mô hình, hữu ích khi chọn mô hình ban đầu. Chúng không đo được tính năng của bạn với tài liệu, người dùng và quy tắc riêng. Bộ kiểm riêng vẫn là thứ phải tự xây.
Ai nên viết tiêu chí đạt cho câu hỏi kiểm?
Người hiểu nghiệp vụ, như nhân viên hỗ trợ khách hàng lâu năm hay chuyên viên phụ trách quy trình. Lập trình viên lo phần cấu trúc, cách chạy và cách chấm. Tiêu chí do người không hiểu nghiệp vụ viết sẽ chấm đạt cho những câu sai một cách tự tin.
Đánh giá có cần chạy tự động trong quy trình tích hợp liên tục không?
Phần kiểm bằng mã theo quy tắc nên chạy tự động như kiểm thử thường. Phần dùng mô hình giám khảo có thể chạy tự động khi có thay đổi ở câu lệnh hay cấu hình mô hình, vì tốn chi phí và thời gian, không cần chạy cho mọi thay đổi mã.