Ngày 14 · AI Evaluation & Benchmarking

Ý chínhGiảng viên đặt câu hỏi xuyên suốt ngày học bằng một tình huống quen thuộc — được hỏi agent của mình tốt hơn sản phẩm khác bao nhiêu mà không có số nào để trả lời — rồi giới thiệu năm đầu ra học viên sẽ đạt được: đo được, thiết kế được, chấm được, đọc được, và chặn được. Ngày học giả định học viên đã quen với việc theo dõi agent qua log và trace.

Kỹ năngHọc viên biết mình sẽ đạt được gì sau ngày học và vì sao đo bằng số quan trọng hơn cảm giác "trông ổn".

Hình thứcVideo giảng viên, 3 phút, giọng dẫn dắt.

Ý chínhPhần mềm truyền thống là known-known — cùng input luôn cho cùng output đúng hoặc sai rõ ràng, như một hàm đăng nhập chỉ cần so khớp mật khẩu. AI sinh ra output xác suất — cùng một câu hỏi có thể nhận nhiều câu trả lời đúng khác nhau về diễn đạt, và cùng một model có thể trả lời khác nhau giữa hai lần gọi. Evaluation vì vậy không phải một bước kiểm thử phụ mà là một kỷ luật kỹ thuật riêng: mỗi giả thuyết về chất lượng phải đi qua một thí nghiệm đo được, rồi kết luận bằng số, theo đúng trình tự giả thuyết, thí nghiệm, đo lường, kết luận. Không đo thì không biết agent đang tốt lên hay tệ đi.

Kỹ năngHọc viên phân biệt được vì sao AI cần cách đánh giá khác phần mềm truyền thống, và mô tả được bốn bước của evaluation theo phương pháp khoa học.

Hình thứcVideo 6 phút, ví dụ hàm đăng nhập đối chiếu với một câu hỏi có nhiều cách trả lời đúng.

Ý chínhBậc thấp nhất là xem qua vài kết quả rồi kết luận "trông ổn" — chỉ đáng tin khi người xem chính là chuyên gia của lĩnh vực đó, và trở nên rủi ro trong sản phẩm phức tạp. Bậc giữa là phân tích lỗi có hệ thống: đọc tay 20 đến 50 kết quả thật, kết hợp kiểm tra bằng code và bằng model chấm điểm. Bậc cao nhất là cổng đánh giá tự động chặn bản phát hành — agent không đạt ngưỡng thì không được triển khai, giống một bài kiểm thử tự động thất bại. Ba bậc này là một lộ trình trưởng thành chứ không phải ba lựa chọn ngang hàng, nên luôn bắt đầu bằng phân tích lỗi trước khi xây hạ tầng đánh giá.

Kỹ năngHọc viên xác định được mình đang ở bậc nào trong ba bậc, và nêu được bước tiếp theo cần làm để trưởng thành hơn.

Hình thứcVideo 5 phút, ba bậc hiện dần theo bậc thang.

Ý chínhHọc viên xem một câu hỏi mẫu và dự đoán trước liệu hai cách diễn đạt khác nhau của cùng một câu trả lời đúng có được các metric truyền thống chấm là giống nhau không. Sau đó hệ thống chạy thật ba metric — so khớp chính xác, BLEU, ROUGE — cho thấy so khớp chính xác chấm sai vì lệch một từ dù đúng nghĩa, trong khi một cặp câu ngược nghĩa nhau nhưng trùng chín trên mười từ vẫn được BLEU và ROUGE chấm là gần giống nhau. Đây là bằng chứng trực tiếp cho việc quy trình đối chiếu chuỗi ký tự cố định của học máy truyền thống không còn phù hợp khi một câu hỏi có nhiều câu trả lời đúng. Hoạt động kết thúc bằng câu hỏi: nếu so khớp chuỗi không dùng được, bước tiếp theo là gì?

Kỹ năngHọc viên giải thích được vì sao so khớp chuỗi ký tự thất bại với văn bản do AI sinh ra, và nhận diện được một bẫy phủ định tương tự trong tình huống khác.

Hình thứcTương tác mô phỏng dự đoán rồi quan sát, 5 phút, trên bộ ba cặp câu cấu hình sẵn — trong đó có bẫy phủ định "nên hoàn tiền" và "không nên hoàn tiền". Phương án thay thế: video so sánh ba cặp câu.

Ý chínhSo khớp bằng embedding tính độ tương đồng cosine giữa hai câu, và khắc phục được nhược điểm lớn nhất của so khớp chuỗi: hai câu diễn đạt khác nhau nhưng cùng nghĩa, như "hoàn tiền" và "trả lại tiền", vẫn được nhận ra là gần nhau. Nhưng embedding có một điểm mù đối xứng — hai câu ngược nghĩa nhau về cùng một đối tượng vẫn có thể cho độ tương đồng cosine trên 0,90 vì cùng chủ đề và cùng từ vựng. Cặp tương phản này cho thấy embedding bắt được cách diễn đạt nhưng không phân biệt được mâu thuẫn logic. Muốn chấm đúng sai thật sự phải dùng một lớp đánh giá cao hơn, dựa trên suy luận ngôn ngữ chứ không chỉ khoảng cách vector.

Kỹ năngHọc viên tính được khi nào nên dùng embedding similarity, và chỉ ra được giới hạn của nó qua một cặp câu mâu thuẫn.

Hình thứcVideo 5 phút, minh hoạ hai câu trên một trục cosine, cặp mâu thuẫn và cặp diễn đạt khác nhau đặt cạnh nhau.

Ý chínhĐánh giá không chỉ chạy một lần mà vận hành song song theo bốn trục; Ngày 13 đã phân biệt online và offline, ở đây thêm hai trục còn lại. Trục ngoại tuyến chạy trên một bộ dữ liệu cố định trong quá trình phát triển và trong quy trình tích hợp liên tục — đây là cổng phát hành. Trục trực tuyến theo dõi liên tục trên lưu lượng thật để bắt suy giảm chất lượng sớm; trục chặn trước hoạt động ngay trong luồng xử lý, ngăn câu trả lời xấu đến tay người dùng thay vì chỉ đo sau; trục thứ tư là con người xem lại một mẫu kết quả để hiệu chỉnh ba trục còn lại. Chỉ dùng một trục là không đủ: chỉ ngoại tuyến thì không biết chất lượng thật trên sản xuất, chỉ con người thì không mở rộng được quy mô.

Kỹ năngHọc viên phân loại được một tình huống đánh giá vào đúng trục trong bốn trục, và giải thích được vì sao cần kết hợp nhiều trục.

Hình thứcVideo 6 phút, bốn trục hiện dần kèm một ví dụ cho mỗi trục. Kèm bảng tra cứu một trang: trục, khi nào chạy, mục tiêu.

Ý chính3 câu kiểm tra: vì sao AI cần evaluation khác phần mềm truyền thống, ba bậc trưởng thành của evaluation, vì sao so khớp chuỗi thất bại với văn bản diễn đạt khác nhau.

Kỹ năngHọc viên tự kiểm tra ba ý chính của module.

Hình thứcQuiz 3 câu, chấm ngay.

Ý chínhMột metric chỉ có giá trị khi nó gắn với kết quả mà người dùng thật sự quan tâm — chọn sai thì điểm cao mà sản phẩm vẫn tệ. Nhóm Task Completion đo agent có hoàn thành đúng mục tiêu không, tính theo trạng thái cuối chứ không theo từng bước, vì agent có thể tìm được đường đi hợp lệ mà người thiết kế không lường trước. Nhóm Answer Quality đo độ chính xác, đầy đủ và mạch lạc của câu trả lời; nhóm RAG-specific đo riêng cho hệ thống có truy xuất tài liệu; nhóm Business đo tác động thực — mức hài lòng, thời gian tiết kiệm, chi phí mỗi lượt. Nên bắt đầu bằng 20 đến 50 tác vụ lấy từ lỗi thật thay vì cố đo mọi thứ cùng lúc.

Kỹ năngHọc viên chọn được nhóm metric phù hợp cho một tình huống cho sẵn, và giải thích được vì sao nên chấm trạng thái cuối thay vì từng bước.

Hình thứcVideo 6 phút, bốn nhóm hiện dần kèm ví dụ.

Ý chínhRAGAS chia pipeline RAG thành hai tầng để chấm riêng. Context recall đo khâu truy xuất: trong toàn bộ chứng cứ cần thiết để trả lời đúng, retriever lấy về được bao nhiêu phần — thấp nghĩa là thiếu chứng cứ, không generator nào vá được. Context precision cũng đo truy xuất nhưng theo thứ tự xếp hạng: chunk đúng có được xếp lên trên hay bị nhiễu dìm xuống dưới. Faithfulness đo khâu sinh câu trả lời bằng cách tách câu trả lời thành các nhận định nhỏ rồi kiểm mỗi nhận định có được context suy ra hay không — thấp nghĩa là bịa thông tin ngoài context; answer relevancy đo câu trả lời có đúng trọng tâm câu hỏi hay lạc đề. Bốn metric tách rõ tầng nào hỏng để sửa đúng chỗ: truy xuất kém thì xem recall và precision, sinh câu trả lời kém thì xem faithfulness và relevancy.

Kỹ năngHọc viên gọi đúng tên bốn metric RAGAS, nêu được công thức tính từng metric, và xác định được metric nào đo khâu truy xuất, metric nào đo khâu sinh câu trả lời.

Hình thứcVideo 8 phút, pipeline Question → Retriever → Context → Generator → Answer hiện dần, mỗi metric gắn đúng vị trí kèm một ví dụ tính bằng số. Kèm bảng tra cứu một trang: metric, công thức, khâu cần sửa khi thấp.

Ý chínhHọc viên đọc một câu hỏi, context được truy xuất, và câu trả lời của một hệ thống RAG mẫu, rồi dự đoán trước điểm của cả bốn metric RAGAS trước khi hệ thống chấm thật. Kịch bản được thiết kế để gây bất ngờ: câu trả lời nghe trôi chảy và đúng chủ đề nhưng chứa một chi tiết không có trong context, khiến faithfulness thấp trong khi answer relevancy vẫn cao. Học viên so sánh dự đoán của mình với điểm thật và thảo luận vì sao một câu trả lời nghe ổn vẫn có thể bịa thông tin. Bốn con số này dễ bị nhớ nhầm vai trò cho nhau nên cần được thực hành trực tiếp thay vì chỉ nghe giảng.

Kỹ năngHọc viên đọc đúng bốn điểm RAGAS của một trường hợp cụ thể, và chỉ ra được khâu cần sửa dựa trên điểm nào thấp.

Hình thứcTương tác mô phỏng dự đoán rồi quan sát, 6 phút, trên một kịch bản cấu hình sẵn có bẫy accuracy cao nhưng faithfulness thấp. Phương án thay thế: video giải bài kèm lời giảng từng bước.

Ý chínhTrước khi chấm câu trả lời cuối cùng, phải chấm riêng khâu truy xuất — nếu retriever bỏ lỡ tài liệu đúng thì không generator nào cứu được, nên chất lượng truy xuất là trần của toàn bộ pipeline. Hit Rate tại k là tỉ lệ câu hỏi có ít nhất một tài liệu đúng nằm trong k kết quả đầu, một phép đo nhị phân không quan tâm thứ tự bên trong k kết quả đó. MRR quan tâm đến thứ tự: chỉ nhìn tài liệu đúng đầu tiên xuất hiện ở hạng bao nhiêu — hạng một tính điểm một, hạng hai tính điểm một phần hai, hạng ba tính điểm một phần ba. Hai metric này tính được ngay khi có nhãn tài liệu đúng cho mỗi câu hỏi, không cần gọi model chấm điểm nên rẻ và cho kết quả cố định.

Kỹ năngHọc viên tính được Hit Rate và MRR từ một danh sách tài liệu truy xuất có nhãn đúng, và giải thích được vì sao phải chấm truy xuất trước khi chấm câu trả lời.

Hình thứcVideo 5 phút, sơ đồ retrieval là trần của generation, công thức Hit Rate và MRR minh hoạ bằng một ví dụ số.

Ý chínhHọc viên nhận 3 danh sách kết quả truy xuất cho 3 câu hỏi khác nhau — tài liệu đúng nằm ở vị trí 1, vị trí 5, và vị trí 10 — và dự đoán Hit Rate tại 5 cùng MRR sẽ ra bao nhiêu trước khi hệ thống tính thật. Kết quả cho thấy Hit Rate tại 5 chỉ nhị phân theo mỗi câu hỏi trong khi MRR phạt nặng tài liệu đúng nằm càng xa vị trí một, dù cả hai đến từ cùng một danh sách kết quả. Hoạt động giúp học viên phân biệt hai họ metric: một họ chỉ quan tâm tài liệu đúng có mặt trong top-k hay không, một họ quan tâm cả vị trí xếp hạng.

Kỹ năngHọc viên tính tay được Hit Rate và MRR cho một danh sách truy xuất mới, không cần công cụ hỗ trợ.

Hình thứcTương tác mô phỏng dự đoán rồi quan sát, 4 phút, ba danh sách truy xuất cấu hình sẵn. Phương án thay thế: bài tập tính tay có đáp án kèm giải thích.

Ý chính4 câu kiểm tra: bốn nhóm metric cho agent, công thức context recall và faithfulness, ý nghĩa context precision, cách tính MRR.

Kỹ năngHọc viên tự kiểm tra bốn ý chính của module trước khi sang benchmark design.

Hình thứcQuiz 4 câu, chấm ngay.

Ý chínhMột golden dataset gồm các cặp câu hỏi - câu trả lời được chuyên gia trong lĩnh vực xem lại, phủ hết các use case chính, và chia theo mức độ khó dễ, trung bình, khó. Đây là căn cứ đúng sai của toàn bộ hệ thống đánh giá — nếu câu trả lời kỳ vọng sai hoặc mơ hồ, mọi con số tính ra sau đó đều gây hiểu lầm mà không ai biết. Quy trình xây dựng đi từ nháp đến bản chính thức: sinh câu hỏi nháp, chuyên gia xem lại và kiểm tra thiên vị, rồi mới đưa vào bộ chính thức — mọi bất đồng phải được giải quyết trước khi một câu được đưa vào bộ dữ liệu. Chất lượng của một hệ thống đánh giá không bao giờ cao hơn chất lượng của golden dataset đứng sau nó.

Kỹ năngHọc viên liệt kê được bốn thành phần của một golden dataset tốt, và mô tả được quy trình từ nháp đến bản chính thức.

Hình thứcVideo 5 phút, sơ đồ quy trình nháp → chuyên gia xem lại → bản chính thức.

Ý chínhHọc viên xem hai bộ dữ liệu đánh giá cùng một agent — một bộ 20 câu, một bộ 100 câu — với cùng một chênh lệch điểm số 3% giữa hai phiên bản agent trên cả hai bộ. Hệ thống hiển thị khoảng tin cậy đi kèm mỗi con số: với 20 câu, khoảng tin cậy rộng đến mức chênh lệch 3% hoàn toàn nằm trong vùng nhiễu; với 100 câu, khoảng tin cậy hẹp hơn nhiều dù vẫn chưa đủ để kết luận chắc chắn. Học viên dự đoán trước bộ nào đủ để kết luận "phiên bản mới tốt hơn" rồi so sánh với khoảng tin cậy thật. Bài học là cỡ mẫu quyết định việc một chênh lệch có ý nghĩa hay chỉ là may rủi, không phải bản thân con số chênh lệch.

Kỹ năngHọc viên giải thích được vì sao một bộ dữ liệu quá nhỏ không thể kết luận được một cải thiện nhỏ, và ước lượng được cỡ mẫu cần thiết ở mức thô.

Hình thứcTương tác mô phỏng dự đoán rồi quan sát, 5 phút, hai bộ dữ liệu cấu hình sẵn kèm khoảng tin cậy hiển thị trực tiếp. Phương án thay thế: bảng so sánh tĩnh hai bộ dữ liệu kèm giải thích.

Ý chínhMột golden dataset đại diện cần chủ động đưa vào các trường hợp biên: câu hỏi mơ hồ có nhiều cách hiểu, câu hỏi ngoài phạm vi, câu hỏi cố tình gây lỗi, câu hỏi trộn nhiều ngôn ngữ, và ngữ cảnh dài nhiều tài liệu. Lấy mẫu theo tỉ lệ nghĩa là phân bổ số lượng câu hỏi tương ứng với tỉ lệ của mỗi use case và mỗi mức độ khó trong thực tế, thay vì lấy ngẫu nhiên đơn thuần có thể bỏ sót một nhóm nhỏ nhưng quan trọng. Điểm tổng hợp trung bình có thể trông đẹp trong khi một lát cắt cụ thể — ví dụ nhóm câu hỏi đối kháng — hỏng nặng; báo cáo điểm theo từng lát cắt mới phát hiện được vấn đề này.

Kỹ năngHọc viên phân loại được năm dạng trường hợp biên, và giải thích được vì sao báo cáo điểm theo lát cắt quan trọng hơn điểm trung bình.

Hình thứcVideo 5 phút, năm trường hợp biên liệt kê kèm ví dụ, một biểu đồ điểm trung bình đẹp che giấu một lát cắt hỏng.

Ý chínhViết tay từng câu hỏi kèm câu trả lời kỳ vọng rất chậm; một model ngôn ngữ có thể sinh ra hàng trăm câu hỏi ứng viên từ chính tài liệu nguồn trong vài phút. Nhưng sinh câu hỏi chỉ là phần dễ — phần khó và là sản phẩm thật sự là lọc bỏ câu quá dễ, câu không trả lời được, và câu lệch với phân bố câu hỏi thật của người dùng. Ba cạm bẫy cần tránh: câu hỏi tổng hợp thường máy móc và không giống cách người dùng thật hỏi; câu hỏi mang thiên vị của chính model sinh ra nó; và nếu cùng một model vừa sinh dữ liệu vừa làm giám khảo chấm điểm, điểm số sẽ bị thổi phồng — nguyên tắc để tránh cả ba là model sinh dữ liệu, model kiểm tra lại, và model chấm điểm phải là ba model khác nhau. Dữ liệu tổng hợp cũng cần được tách riêng một phần không công khai, không đưa vào huấn luyện hay vào prompt, để tránh model đã "nhìn thấy đáp án" trước khi được đánh giá.

Kỹ năngHọc viên nêu được ba cạm bẫy của dữ liệu tổng hợp, và áp dụng được nguyên tắc ba model khác nhau cho sinh, kiểm tra, và chấm điểm.

Hình thứcVideo 6 phút, luồng sinh → lọc → chuyên gia xem lại → bộ dữ liệu chính thức, ba cạm bẫy minh hoạ bằng ví dụ.

Ý chínhNhiều benchmark công khai quen thuộc — như MMLU cho kiến thức tổng quát hay HumanEval cho lập trình — từng dùng để phân loại năng lực model nay đã chạm trần: các model hàng đầu đều đạt điểm trên 90% và chênh lệch giữa chúng nằm trong vùng nhiễu, không còn phân biệt được model nào thực sự tốt hơn. Nguyên nhân chính là nhiễm bẩn dữ liệu: câu hỏi benchmark công khai rồi sẽ lọt vào dữ liệu huấn luyện của các model sau, khiến điểm số phản ánh trí nhớ chứ không phản ánh năng lực suy luận — ngay cả một benchmark khó và cập nhật liên tục hơn cho tác vụ lập trình như SWE-bench cũng đã bắt đầu lộ dấu hiệu tương tự. Đây là quy luật Goodhart — khi một con số trở thành mục tiêu để tối ưu, nó không còn là thước đo tốt nữa; các bảng xếp hạng công khai cũng có thể bị chi phối bằng cách âm thầm thử nhiều phiên bản rồi chỉ công bố phiên bản tốt nhất. Vì vậy benchmark công khai chỉ nên đọc như một tín hiệu tham khảo về năng lực chung, không thay thế được một bộ dữ liệu đánh giá gắn với đúng tác vụ của sản phẩm.

Kỹ năngHọc viên giải thích được vì sao benchmark công khai bị bão hòa và nhiễm bẩn, và nêu được lý do phải tự xây bộ dữ liệu đánh giá riêng.

Hình thứcVideo 6 phút, đường cong bão hòa của một benchmark quen thuộc, minh hoạ nhiễm bẩn dữ liệu bằng ví dụ trước và sau một mốc thời gian.

Ý chính4 câu kiểm tra: bốn thành phần của golden dataset, vì sao cỡ mẫu quyết định độ tin cậy của một chênh lệch, lấy mẫu theo tỉ lệ để làm gì, vì sao benchmark công khai bị nhiễm bẩn.

Kỹ năngHọc viên tự kiểm tra bốn ý chính của module trước khi sang LLM-as-Judge.

Hình thứcQuiz 4 câu, chấm ngay.

Ý chínhLLM-as-Judge nhận câu hỏi, câu trả lời của agent, câu trả lời tham chiếu, và một rubric, rồi trả về điểm số kèm lý do — bắt giám khảo giải thích lý do trước khi cho điểm mới debug được vì sao một điểm số thấp. Cách chấm pointwise cho mỗi câu trả lời một điểm tuyệt đối theo rubric, ổn định hơn và dễ đặt ngưỡng cho cổng phát hành, nhưng khó phân biệt hai câu trả lời chất lượng gần ngang nhau. Cách chấm pairwise hỏi giám khảo câu nào tốt hơn giữa hai câu trả lời, bám sát sở thích của con người hơn nhưng kém ổn định — chỉ cần đổi thứ tự trình bày hai câu trả lời, kết quả có thể đảo ngược ở khoảng một phần ba số lần. Một rubric tốt cần tiêu chí cụ thể theo từng mức điểm, nêu rõ độ dài không phải là một tiêu chí, và luôn yêu cầu giám khảo lý luận trước khi cho điểm.

Kỹ năngHọc viên viết được một rubric có tiêu chí rõ ràng theo từng mức điểm, và chọn được pointwise hay pairwise phù hợp với mục đích sử dụng.

Hình thứcVideo 7 phút, cấu trúc một lần chấm hiện dần, bảng so sánh pointwise và pairwise.

Ý chínhHọc viên nhận một cặp câu trả lời cho cùng một câu hỏi — một câu ngắn và đúng, một câu dài hơn và có một chi tiết sai — rồi dự đoán trước giám khảo sẽ chấm câu nào cao hơn. Sau đó hệ thống chạy giám khảo thật hai lần, một lần giữ nguyên thứ tự trình bày và một lần đảo thứ tự, cho thấy điểm số có thể đổi theo vị trí trình bày chứ không chỉ theo nội dung, và câu trả lời dài hơn thường được chấm cao hơn dù không chính xác hơn. Học viên so sánh dự đoán ban đầu với kết quả thật và thảo luận vì sao một giám khảo chưa qua hiệu chỉnh không phải là bằng chứng đáng tin, chỉ là một ý kiến.

Kỹ năngHọc viên chỉ ra được thiên vị đang xảy ra trong một cặp kết quả chấm điểm cụ thể, và đề xuất được một cách khắc phục phù hợp.

Hình thứcTương tác mô phỏng dự đoán rồi quan sát, 6 phút, một cặp câu trả lời cấu hình sẵn chạy qua giám khảo hai chiều thứ tự. Phương án thay thế: video minh hoạ kết quả chấm hai chiều kèm giải thích.

Ý chínhBa loại thiên vị phổ biến nhất của LLM-as-Judge đã được đo bằng số cụ thể trong nghiên cứu: thiên vị vị trí khiến giám khảo ưu tiên câu trả lời xuất hiện trước, lệch tới vài chục phần trăm số lần tuỳ model; thiên vị độ dài khiến giám khảo chọn câu trả lời dài hơn dù không chính xác hơn; thiên vị cùng họ khiến giám khảo ưu tiên câu trả lời do model cùng nhà phát triển với chính nó sinh ra. Năm kỹ thuật khắc phục bắt buộc: đảo thứ tự trình bày rồi lấy trung bình để triệt thiên vị vị trí; bắt giám khảo lý luận trước khi cho điểm; chấm từng tiêu chí riêng theo rubric để chặn thiên vị độ dài; hiệu chỉnh so với đánh giá của con người trên một tập có nhãn; và dùng nhiều giám khảo khác họ model để giảm thiên vị cùng họ. Một giám khảo chưa qua hiệu chỉnh không nên được tin tuyệt đối.

Kỹ năngHọc viên gọi đúng tên ba loại thiên vị, và áp dụng được ít nhất ba trong năm kỹ thuật khắc phục cho một tình huống cho sẵn.

Hình thứcVideo 7 phút, ba loại thiên vị minh hoạ bằng số liệu, năm kỹ thuật khắc phục trình bày dạng checklist.

Ý chínhKhông nên báo cáo tỉ lệ đồng ý thô giữa giám khảo và con người, vì một phần đồng ý đến từ may rủi ngẫu nhiên. Hệ số Kappa loại bỏ phần may rủi đó, cho một con số phản ánh đúng mức đồng thuận thật: Kappa gần 1 là gần như luôn đồng ý, Kappa gần 0 là đồng ý ngang bằng may rủi. Một giám khảo tốt thường đạt Kappa cao nhưng chưa chạm mức đồng thuận giữa hai người với nhau, nên cần đo Kappa riêng cho từng lát cắt dữ liệu vì con số đồng thuận tổng có thể che giấu một lát cắt mà giám khảo sai nặng. Ngày 2 đã dùng precision và recall để phân biệt hai kiểu sai; Kappa là công cụ khác, dùng khi cần đo mức đồng thuận giữa hai người chấm hoặc hai hệ thống chấm với nhau.

Kỹ năngHọc viên giải thích được vì sao Kappa đáng tin hơn tỉ lệ đồng ý thô, và đọc được một con số Kappa để đánh giá độ tin cậy của một giám khảo.

Hình thứcVideo 5 phút, ví dụ tính Kappa từ một bảng đồng thuận, so sánh với tỉ lệ đồng ý thô.

Ý chínhThay vì gọi một model mạnh và đắt làm giám khảo duy nhất, một nhóm nhiều model rẻ hơn và khác họ nhau cùng chấm rồi biểu quyết cho kết quả tương quan với đánh giá của con người tốt hơn một giám khảo đơn lẻ, vì thiên vị của các model khác nhau có xu hướng triệt tiêu lẫn nhau. Khi các giám khảo trong nhóm đồng thuận, kết quả được chấp nhận ngay; khi bất đồng, một model mạnh hơn được gọi thêm để phân xử, chỉ trong trường hợp cần thiết để tiết kiệm chi phí. Cần lưu ý giám khảo rẻ thường dễ dãi hơn, có xu hướng chấm cao cho câu trả lời trôi chảy nhưng sai, nên không nên tin một giám khảo rẻ hoàn toàn mà không đối chiếu.

Kỹ năngHọc viên thiết kế được một quy trình nhiều giám khảo có bước xử lý khi các giám khảo bất đồng.

Hình thứcVideo 6 phút, sơ đồ nhiều giám khảo → tỉ lệ đồng thuận → phân xử khi bất đồng.

Ý chính4 câu kiểm tra: khác biệt pointwise và pairwise, ba loại thiên vị của LLM-as-Judge, ý nghĩa hệ số Kappa, vì sao dùng nhiều giám khảo thay vì một.

Kỹ năngHọc viên tự kiểm tra bốn ý chính của module trước khi sang phần đánh giá agent nhiều bước.

Hình thứcQuiz 4 câu, chấm ngay.

Ý chínhVới agent nhiều bước có 2 câu hỏi khác nhau cần trả lời. Câu hỏi outcome: trạng thái cuối của môi trường có đúng như mong đợi không — ví dụ sau khi đặt vé, dòng đặt chỗ có thực sự tồn tại trong cơ sở dữ liệu. Câu hỏi trajectory: toàn bộ chuỗi bước đi có hợp lý không — agent có gọi đúng công cụ, đúng tham số, không lặp bước, không đi đường vòng. Nên ưu tiên chấm outcome vì đó là điều khách hàng thực sự quan tâm, và chỉ đọc trajectory để tìm hiểu vì sao khi outcome sai — ép agent phải đi đúng thứ tự bước là quá cứng nhắc, vì agent thường tìm được đường đi hợp lệ khác mà người thiết kế không lường trước. Việc kiểm tra agent có gọi đúng tên hàm và đúng tham số của công cụ cũng là một phần của đánh giá trajectory, dùng một bộ chuẩn đối chiếu riêng cho việc gọi công cụ.

Kỹ năngHọc viên phân biệt được outcome eval và trajectory eval, và giải thích được vì sao nên ưu tiên chấm outcome.

Hình thứcVideo 6 phút, ví dụ agent đặt vé máy bay minh hoạ cả hai cách chấm, ẩn dụ bác sĩ phẫu thuật cho outcome và trajectory.

Ý chínhNhiều người tin rằng đặt temperature bằng 0 sẽ cho kết quả cố định tuyệt đối, nhưng thực tế khoảng 5 đến 12% số câu hỏi vẫn đổi câu trả lời qua các lần chạy khác nhau, do cách tính toán dấu phẩy động và cách xử lý song song ở phía máy chủ. Hệ quả là một agent đạt 90% thành công ở một lần thử có thể tụt xuống chỉ còn khoảng 57% nếu yêu cầu phải đúng cả 8 lần thử liên tiếp — độ tin cậy giảm rất nhanh theo số lần yêu cầu đúng liên tục. Một lần chạy "thắng" không chứng minh được gì; cần chạy mỗi cấu hình nhiều lần và báo cáo cả trung bình lẫn độ lệch, không chỉ một con số duy nhất.

Kỹ năngHọc viên giải thích được vì sao temperature bằng 0 không đảm bảo kết quả cố định, và tính được ở mức thô độ tin cậy của agent khi yêu cầu đúng nhiều lần liên tiếp.

Hình thứcVideo 6 phút, bảng độ tin cậy giảm theo số lần thử lại, minh hoạ nguyên nhân bằng ví dụ tính toán song song.

Ý chínhHọc viên xem kết quả của hai phiên bản agent chạy trên cùng 50 câu hỏi — phiên bản A đạt 78%, phiên bản B đạt 81% — và dự đoán trước liệu chênh lệch 3 điểm này có đủ để kết luận phiên bản B tốt hơn hay không. Hệ thống sau đó hiển thị khoảng tin cậy 95% của mỗi phiên bản, cho thấy hai khoảng chồng lấp nhau rất nhiều, và chạy phép kiểm định trên đúng các câu hỏi mà hai phiên bản cho kết quả khác nhau — cách làm đúng là so sánh trên cùng một bộ câu hỏi thay vì so hai trung bình độc lập. Kết luận cuối cùng là chênh lệch 3 điểm trên 50 câu là nhiễu thống kê, chưa đủ bằng chứng để tuyên bố một phiên bản tốt hơn. Học viên đối chiếu dự đoán ban đầu của mình với kết luận này.

Kỹ năngHọc viên đọc được một khoảng tin cậy để nhận biết một chênh lệch điểm số có ý nghĩa hay chỉ là nhiễu, và giải thích được vì sao phải so sánh trên cùng bộ câu hỏi.

Hình thứcTương tác mô phỏng dự đoán rồi quan sát, 6 phút, hai phiên bản agent cấu hình sẵn kèm khoảng tin cậy và kết quả kiểm định hiển thị trực tiếp. Phương án thay thế: video giải một ví dụ tương tự kèm lời giảng từng bước.

Ý chínhSo sánh trên cùng một bộ câu hỏi giữa hai phiên bản thay vì hai bộ câu hỏi khác nhau giúp loại bỏ độ khó riêng của từng câu ra khỏi phép so sánh, làm phương sai của chênh lệch giảm đáng kể và tăng khả năng phát hiện cải thiện thật với cùng số câu hỏi. Nhưng ngay cả khi so sánh đúng cách, phát hiện một cải thiện nhỏ vẫn cần nhiều dữ liệu hơn trực giác thông thường: muốn phát hiện chắc chắn một chênh lệch tuyệt đối 3% cần đến gần 1.000 câu hỏi được so sánh theo cặp. Một bộ 50 câu như thường thấy trong giai đoạn đầu không thể chứng minh được một thắng lợi nhỏ; điều trung thực cần làm là báo cáo khoảng tin cậy và nói rõ điều gì kết luận được, điều gì chưa kết luận được.

Kỹ năngHọc viên giải thích được vì sao so sánh theo cặp trên cùng bộ câu hỏi mạnh hơn so sánh hai trung bình độc lập, và ước lượng được cỡ mẫu cần thiết ở mức thô cho một mục tiêu phát hiện cho trước.

Hình thứcVideo 6 phút, bảng cỡ mẫu cần thiết theo mức chênh lệch muốn phát hiện, minh hoạ so sánh theo cặp giảm phương sai.

Ý chính4 câu kiểm tra: khác biệt outcome eval và trajectory eval, vì sao temperature bằng 0 không đảm bảo kết quả cố định, cách đọc khoảng tin cậy của một chênh lệch điểm số, vì sao so sánh theo cặp mạnh hơn so sánh hai trung bình độc lập.

Kỹ năngHọc viên tự kiểm tra bốn ý chính của module trước khi sang phần phân tích lỗi.

Hình thứcQuiz 4 câu, chấm ngay.

Ý chínhThay vì áp một danh mục lỗi có sẵn từ sách vở, cách đáng tin hơn là đọc trực tiếp một mẫu kết quả lỗi thật rồi để danh mục lỗi tự hình thành từ dữ liệu. Bước đầu là gán nhãn mở: đọc từng trường hợp lỗi và ghi lại bằng lời của chính người đọc, không gò theo danh mục có sẵn. Bước tiếp theo là gom nhóm các nhãn gần nghĩa lại thành một số danh mục hẹp, hẹp đến mức mỗi danh mục viết được thành một phép kiểm tra đạt hoặc không đạt cụ thể. Quá trình lặp lại — đọc thêm mẫu, đếm tần suất từng danh mục — cho đến khi mẫu mới không còn phát sinh danh mục nào mới, gọi là điểm bão hoà; cách làm từ dưới lên này thường phát hiện được lỗi thật mà một danh mục định sẵn từ trên xuống bỏ sót.

Kỹ năngHọc viên thực hiện được hai bước gán nhãn mở và gom nhóm trên một tập kết quả lỗi mẫu, và nhận biết được khi nào đạt điểm bão hoà.

Hình thứcVideo 6 phút, quy trình đọc → gán nhãn mở → gom nhóm → đếm tần suất → dừng khi bão hoà hiện dần từng bước.

Ý chínhHọc viên đọc năm trace lỗi thật của một agent và tự gán nhãn mở cho từng trace bằng lời của mình, trước khi biết cách gom nhóm chuẩn. Sau đó hệ thống hiển thị cách một chuyên gia gom năm nhãn đó lại thành hai hoặc ba danh mục hẹp — ví dụ một cụm chiếm phần lớn lỗi hoá ra đến từ cùng một nguyên nhân kỹ thuật ở khâu nạp dữ liệu. Học viên so sánh cách gom nhóm của mình với cách gom nhóm chuẩn và thảo luận khác biệt. Hoạt động cho thấy phần lớn lỗi thường tập trung vào một vài cụm lớn, và sửa đúng cụm lớn nhất mang lại hiệu quả cao hơn nhiều so với sửa từng lỗi lẻ tẻ.

Kỹ năngHọc viên tự gán nhãn mở được cho một trace lỗi mới, và gom được các nhãn gần nghĩa thành một danh mục hẹp có thể viết thành phép kiểm tra.

Hình thứcTương tác mô phỏng dự đoán rồi quan sát, 7 phút, năm trace lỗi cấu hình sẵn kèm cách gom nhóm chuẩn để đối chiếu. Phương án thay thế: bài tập đọc trace trên giấy có đáp án kèm giải thích.

Ý chínhMỗi lỗi cần được truy ngược bằng chuỗi câu hỏi vì sao cho đến khi chạm đúng khâu gây ra nó — nạp dữ liệu, chia nhỏ tài liệu, truy xuất, hay soạn prompt — thay vì dừng lại ở triệu chứng bề mặt. Một ví dụ điển hình: agent trả lời sai về một chính sách, hỏi vì sao thì phát hiện câu trả lời không dựa trên đúng tài liệu, hỏi tiếp thì phát hiện bộ truy xuất không lấy được phiên bản chính sách mới nhất, hỏi tiếp nữa thì phát hiện phiên bản mới chưa được đưa vào kho dữ liệu vì quy trình nạp dữ liệu không có lịch cập nhật định kỳ — nguyên nhân gốc nằm ở khâu nạp dữ liệu, sửa prompt hay đổi model đều vô ích. Một cạm bẫy thường gặp là chữa sai nguyên nhân gốc: cố vá triệu chứng bằng cách thêm quy tắc vào prompt khiến prompt phình to dần mà lỗi gốc vẫn còn nguyên. Sửa đúng khâu gây lỗi thường giải quyết được cả một cụm lỗi tương tự cùng lúc.

Kỹ năngHọc viên truy được một lỗi mẫu về đúng một trong bốn khâu bằng chuỗi câu hỏi vì sao, và nhận diện được khi nào một cách sửa chỉ đang vá triệu chứng.

Hình thứcVideo 6 phút, ví dụ truy lỗi chính sách qua 4 câu hỏi vì sao liên tiếp, minh hoạ cạnh đó ví dụ prompt phình to vì vá sai nguyên nhân.

Ý chínhKhi một model chấm điểm thay cho con người xem lại từng câu trả lời, chi phí chuyển từ giờ công người thành hoá đơn token, và một lần chấm thường chỉ tốn vài phần trăm của một đơn vị tiền tệ thay vì vài đơn vị như trước. Ba cách giảm thêm chi phí mà không mất tín hiệu: dùng lại phần cố định của prompt để giảm chi phí xử lý cho phần lặp lại, gom nhiều lượt chấm không gấp thành một lô chạy chung, và chỉ chạy giám khảo mạnh và đầy đủ ở lần chấm cuối trước khi phát hành, còn lần chấm thường ngày dùng một giám khảo nhẹ hơn để bắt xu hướng nhanh. Ba framework phổ biến phục vụ ba mục đích khác nhau: RAGAS chuẩn hoá các metric cho RAG, DeepEval tích hợp trực tiếp vào bộ kiểm thử tự động theo phong cách pytest, còn TruLens tập trung theo dõi trong môi trường vận hành thật — chọn theo mục đích sử dụng, không theo tên nào quen thuộc hơn.

Kỹ năngHọc viên nêu được ba cách giảm chi phí một lần chấm điểm mà không mất tín hiệu, và chọn được công cụ đánh giá phù hợp với một tình huống cho sẵn.

Hình thứcVideo 7 phút, sơ đồ chi phí chuyển từ giờ công sang token, ba cách giảm chi phí minh hoạ bằng ví dụ, bảng so sánh ba framework theo mục đích.

Ý chínhMột cổng đánh giá tự động chạy ngay sau mỗi thay đổi mã nguồn hoặc prompt, so kết quả trên bộ dữ liệu chuẩn với phiên bản nền, và chỉ cho phép phát hành khi vượt ngưỡng — đúng tinh thần một bài kiểm thử tự động thất bại thì chặn việc hợp nhất mã nguồn, chỉ khác là bài kiểm thử ở đây chấm hành vi thay vì so khớp kết quả cố định. Cổng cần dựa trên cả mức chênh lệch lẫn ý nghĩa thống kê của chênh lệch đó, không chỉ nhìn điểm trung bình tổng — một chênh lệch nhỏ trên điểm trung bình có thể che giấu một suy giảm lớn ở một nhóm câu hỏi cụ thể, nên cần so sánh theo từng nhóm riêng. Giữ cố định model giám khảo và phiên bản rubric qua các lần chạy, và lưu lại mọi thay đổi của chúng dưới dạng lịch sử có thể xem lại, nếu không một thay đổi ở giám khảo có thể bị nhầm là agent suy giảm chất lượng. Công cụ như Promptfoo hay LangSmith cung cấp sẵn cơ chế này dưới dạng assertion hoặc so sánh với một baseline đã ghim, nhưng nguyên lý cổng vẫn giữ nguyên dù dùng công cụ nào. Ngày 12 đã trình bày pipeline năm bước từ commit đến phát hành; module này chỉ làm rõ cách bước đánh giá trong pipeline đó ra quyết định phát hành hay không.

Kỹ năngHọc viên vẽ được vị trí của cổng đánh giá trong luồng từ commit đến phát hành, và giải thích được vì sao cổng phải dựa trên cả chênh lệch lẫn ý nghĩa thống kê.

Hình thứcVideo 7 phút, luồng commit → cổng đánh giá → phát hành hoặc chặn hiện dần, ví dụ một chênh lệch nhỏ trên trung bình che giấu suy giảm ở một nhóm câu hỏi.

Ý chính4 câu kiểm tra: hai bước gán nhãn mở và gom nhóm trong xây taxonomy lỗi, cách dùng chuỗi câu hỏi vì sao để truy nguyên nhân gốc, ba cách giảm chi phí một lần chấm điểm, điều kiện để một cổng đánh giá cho phép phát hành.

Kỹ năngHọc viên tự kiểm tra bốn ý chính của module trước khi vào lab.

Hình thứcQuiz 4 câu, chấm ngay.

Ý chínhGiảng viên trả lời câu hỏi mở đầu bằng năm điểm chính: evaluation là một kỷ luật kỹ thuật đo được và lặp lại được, không phải cảm tính; RAGAS và retrieval eval tách rõ khâu truy xuất hỏng hay khâu sinh câu trả lời hỏng; một golden dataset đủ lớn và benchmark công khai không thay thế cho nhau; LLM-as-Judge chỉ đáng tin khi đã qua hiệu chỉnh và dùng nhiều giám khảo; và một cổng đánh giá tự động là điều kiện để phát hành an toàn. Giới thiệu Ngày 15: nhìn lại 15 ngày và chọn track cho Phase 2.

Kỹ năngHọc viên tóm tắt được năm điểm chính bằng ngôn ngữ của mình.

Hình thứcVideo giảng viên, 3 phút.

Ý chínhNhiều bảng xếp hạng công khai không chấm điểm tuyệt đối mà tổng hợp từ hàng loạt lượt so sánh cặp đôi do con người bình chọn, dùng các mô hình thống kê ước lượng "sức mạnh" tương đối của từng model và cập nhật liên tục theo mỗi lượt bình chọn mới, giống cách tính điểm trong cờ vua. Một phát hiện gây chú ý là một số nhà phát triển lớn âm thầm thử nhiều phiên bản chưa công bố trên chính bảng xếp hạng rồi chỉ nộp phiên bản đạt điểm cao nhất, khiến điểm số phản ánh việc ai tối ưu tốt cho cách chấm của bảng xếp hạng hơn là ai thực sự tốt cho một tác vụ cụ thể. Độ dài và định dạng câu trả lời cũng có thể "mua" được điểm số cao hơn dù không phản ánh chất lượng thật. Mở rộng cho item 3.5.

Kỹ năngHọc viên đọc một bảng xếp hạng công khai với thái độ hoài nghi phù hợp, và giải thích được vì sao thứ hạng có thể không phản ánh năng lực thật.

Hình thứcVideo 7 phút, minh hoạ cách tính điểm từ các lượt so sánh cặp đôi, ví dụ một nhà phát triển thử nhiều phiên bản trước khi công bố.

Ý chínhMột agent có thể đúng ở mức trung bình nhưng thiên lệch nặng theo một nhóm người dùng cụ thể — cách phát hiện là giữ nguyên câu hỏi, chỉ đổi một thuộc tính nhạy cảm như giới tính, vùng miền, hay ngôn ngữ, rồi so sánh chênh lệch điểm số giữa các phiên bản câu hỏi đó. Đánh giá an toàn kiểm tra riêng khả năng từ chối các yêu cầu có hại, khả năng phát hiện nội dung cố tình chèn vào để đánh lừa agent, và khả năng không để lộ thông tin cá nhân — mỗi loại có một ngưỡng chấp nhận riêng, thường rất cao vì hậu quả của một lần thất bại có thể lớn. Một nhóm nhỏ người có nền tảng khác nhau chủ động thử phá agent trong một khung thời gian cố định, ghi lại, phân loại, và đưa các trường hợp phát hiện được vào bộ dữ liệu đánh giá thường trực. Mở rộng cho Module 5.

Kỹ năngHọc viên thiết kế được một cặp câu hỏi counterfactual để kiểm tra thiên lệch, và liệt kê được ba loại rủi ro an toàn cần kiểm tra riêng.

Hình thứcVideo 6 phút, ví dụ một cặp câu hỏi counterfactual đổi một thuộc tính nhạy cảm, ba loại rủi ro an toàn liệt kê kèm ngưỡng chấp nhận.

Ý chínhThay vì luôn gọi một model hàng đầu làm giám khảo, có thể dùng một model nhỏ hơn được huấn luyện chuyên để chấm điểm — tương quan với giám khảo hàng đầu gần bằng trong khi chạy được ngay trên hạ tầng riêng, phù hợp khi khối lượng chấm điểm lớn hoặc dữ liệu nhạy cảm không thể rời khỏi hệ thống nội bộ. Hai kỹ thuật tối ưu chi phí đáng chú ý có thể cộng dồn với nhau: lưu sẵn phần cố định của prompt để tính phí thấp hơn nhiều ở những lần gọi sau, và gom các lượt chấm không gấp vào một lô xử lý chung để được tính phí thấp hơn cho cả token vào lẫn token ra. Mở rộng cho Module 4 và item 6.4.

Kỹ năngHọc viên biết khi nào nên cân nhắc một giám khảo chuyên dụng thay vì gọi model hàng đầu, và áp dụng được hai kỹ thuật tối ưu chi phí cộng dồn.

Hình thứcVideo 6 phút, so sánh giám khảo chuyên dụng và giám khảo hàng đầu, minh hoạ hai kỹ thuật tối ưu chi phí cộng dồn.

Ý chínhHọc viên xây một bộ golden dataset đủ lớn kèm nhãn tài liệu đúng để tính retrieval eval; triển khai đủ năm metric lấy cảm hứng từ RAGAS cho cả câu trả lời lẫn khâu truy xuất; thiết kế một rubric LLM-as-Judge và phát hiện thiên vị trong kết quả chấm; và xây một cổng phát hành so sánh phiên bản mới với phiên bản cũ trên cùng bộ dữ liệu. Sản phẩm cuối cùng là một báo cáo phân tích lỗi có gom nhóm và truy nguyên nhân gốc cho các trường hợp tệ nhất, kèm đề xuất cải thiện cụ thể. Học viên nộp mã nguồn hoàn chỉnh cùng báo cáo đánh giá và phân tích lỗi.

Kỹ năngHọc viên chạy được một pipeline đánh giá tự động hoàn chỉnh từ golden dataset đến quyết định phát hành, và viết được một phân tích nguyên nhân gốc có căn cứ cho ít nhất ba trường hợp lỗi.

Hình thứcLab 4 giờ tại lớp với người hướng dẫn, theo repo có sẵn, làm theo nhóm hoặc cá nhân tuỳ lớp. Kèm bộ dữ liệu nguồn, script khởi tạo golden dataset, và checklist kiểm tra định dạng trước khi nộp.