Chốt với khách thế nào là “thành công” trước khi viết code AI

Thử hình dung buổi họp thứ hai với một công ty logistics. Họ muốn dùng LLM để tự động phân loại email khiếu nại, và giám đốc vận hành chốt yêu cầu bằng một câu: “Phân loại phải đúng hết, sai là không được.”

Nếu bạn gật đầu và về mở editor, có lẽ dự án đã thua từ lúc đó. Ba tháng sau, ở buổi nghiệm thu, chỉ cần một email bị xếp nhầm là đủ để khách nói hệ thống không đạt, và bạn không có văn bản nào chứng minh điều ngược lại.

Với FDE, việc khó nhất của một dự án AI thường không nằm ở prompt hay pipeline. Nó nằm ở chỗ thống nhất với khách thế nào là “thành công” khi hệ thống chắc chắn sẽ có lúc sai. Bài này hướng dẫn cách làm việc đó trước khi viết dòng code đầu tiên.

Vì sao “đúng hết” không phải là một tiêu chí?

Kỹ sư phần mềm quen với unit test: một test đỏ là có bug, phải sửa cho bằng hết. Hamel Husain, người chuyên tư vấn về eval cho sản phẩm LLM, nhắc rằng eval cho LLM thì khác: bộ eval không nhất thiết phải đạt 100%. Hướng dẫn về eval của OpenAI cũng nói eval tồn tại chính vì hệ thống AI vốn không tất định (nondeterministic).

Ý quan trọng hơn của Husain là pass rate bao nhiêu thì đủ là một quyết định sản phẩm, tùy vào những lỗi mà bạn sẵn lòng chấp nhận. Vì thế khi khách nói “không được sai”, câu trả lời đúng không phải là “không thể”. Bạn nên hỏi tiếp: sai kiểu nào thì không được, và sai kiểu nào thì vẫn chấp nhận được?

Tài liệu của Anthropic về success criteria đưa ra bốn yêu cầu: tiêu chí phải cụ thể, đo được, làm được và phù hợp với mục đích. Ví dụ của họ rất gọn: đừng viết “hiệu năng tốt”, hãy viết “phân loại cảm xúc chính xác”.

“Đúng hết” không qua được hai trong bốn yêu cầu đó. Không ai đo được nó trên một mẫu hữu hạn, và cũng không mô hình nào làm được.

Đọc lỗi thật trước khi đặt chỉ số

Phản xạ thường gặp là mở một bảng chỉ số có sẵn ra rồi chọn accuracy, F1, có khi thêm một điểm “helpfulness”. Husain cảnh báo rằng cách làm từ trên xuống này hay dẫn tới việc đo thứ dễ đo, chứ không phải thứ người dùng thật sự quan tâm.

Ông đề xuất đi theo chiều ngược lại: phân tích lỗi trên dữ liệu thật trước, sau đó viết test cho những dạng lỗi cụ thể đã quan sát được. Về quy mô, ông gợi ý bắt đầu với khoảng 100 trace để tìm lỗi. Khi cần kiểm chứng một LLM judge, nên gán nhãn từ 100 đến 200 ví dụ cho mỗi dạng lỗi.

Áp vào công ty logistics trong ví dụ, bạn xin 100 email khiếu nại thật đã ẩn thông tin cá nhân, chạy bản prototype rồi ngồi đọc cùng một nhân viên chăm sóc khách hàng. Giả sử hai người tìm ra ba dạng lỗi.

Dạng thứ nhất là email “giao trễ” bị xếp vào “hỏi thông tin”. Dạng thứ hai là email đòi bồi thường hàng vỡ bị xếp vào “giao trễ”. Dạng thứ ba là email có lời lẽ đe dọa kiện nhưng không được đẩy lên cấp quản lý.

Ba dạng lỗi này nặng nhẹ rất khác nhau. Xếp nhầm giữa “giao trễ” và “hỏi thông tin” chỉ làm nhân viên mất vài phút chuyển lại hàng đợi. Bỏ sót một email dọa kiện thì có thể thành sự cố pháp lý. Đây chính là thông tin mà một con số accuracy duy nhất che mất.

Một bản tiêu chí nghiệm thu làm từ đầu đến cuối

Anthropic khuyên đặt tiêu chí trên nhiều mặt cùng lúc. Một trong số đó là mức nghiêm trọng của lỗi, với ví dụ “90% lỗi chỉ gây bất tiện, không phải lỗi nghiêm trọng”.

Độ trễ cũng nằm trong danh sách. Ở mặt an toàn, họ đưa một tiêu chí có con số rõ ràng: dưới 0.1% output bị bộ lọc nội dung gắn cờ độc hại, đo trên 10.000 lần chạy.

Chú ý cách viết tiêu chí đó. Nó có ngưỡng, có cỡ mẫu và có công cụ đo. Bản tiêu chí cho dự án email nên viết theo đúng khuôn này. Các con số trong bảng dưới đây chỉ để minh họa, bạn sẽ thay bằng số chốt với khách thật:

Khía cạnh	Tiêu chí	Đo trên
Phân loại tổng thể	Ít nhất 92% email được xếp đúng nhóm	500 email có nhãn do khách xác nhận
Mức nghiêm trọng	Ít nhất 90% lỗi chỉ thuộc loại “chuyển nhầm hàng đợi”	Các lỗi trong cùng bộ 500 email
Email dọa kiện	Không bỏ sót email nào trong bộ test dọa kiện	150 email dọa kiện có nhãn
Độ trễ	Phân loại xong trước khi email vào hàng đợi	Log của môi trường staging

Giờ đem dòng đầu ra tính thử. Với 1.000 email mỗi ngày, mức 92% nghĩa là khoảng 80 email bị xếp sai. Nếu 90% trong số đó chỉ là chuyển nhầm hàng đợi thì còn khoảng 8 lỗi nặng mỗi ngày.

Câu hỏi bạn đặt lên bàn là: “Mỗi ngày có 8 email nặng bị xếp sai, đội anh chị có chịu được không, hay ta cần một bước người duyệt?”

Câu hỏi đó biến một nỗi lo mơ hồ thành một lựa chọn kinh doanh có thể bàn được. Nó cũng khớp với cách Husain nhìn pass rate: đó là quyết định sản phẩm về những lỗi có thể chấp nhận, nên người làm sản phẩm phía khách phải cùng ngồi quyết.

Còn dòng “không bỏ sót” thì sao? Một ngưỡng tuyệt đối chỉ hợp lý khi áp cho một bộ test hẹp, cố định và đủ lớn để kết quả không phụ thuộc vào may rủi, như bộ 150 email trong bảng minh họa. Nếu không đạt được ngưỡng này, cách ra là thêm người duyệt, chứ không phải hạ ngưỡng xuống trong im lặng.

Năm bước để tự làm ở dự án tiếp theo

Bước một: viết lại mọi yêu cầu mơ hồ thành câu có con số. Hướng dẫn của OpenAI cũng mở đầu quy trình thiết kế eval bằng đúng câu hỏi tiêu chí thành công là gì.

Bước hai: xin dữ liệu thật và đọc khoảng 100 trace cùng một người làm nghiệp vụ phía khách. Ghi lại các dạng lỗi bằng ngôn ngữ của họ, đừng dùng thuật ngữ ML.

Bước ba: xếp từng dạng lỗi theo mức nghiêm trọng, rồi đặt tiêu chí trên nhiều mặt: độ chính xác, mức nghiêm trọng, độ trễ và an toàn.

Bước bốn: kiểm tra xem ngưỡng có làm được không. Anthropic nhấn mạnh rằng chỉ số không nên vượt quá khả năng của các frontier model hiện tại, và nên dựa trên benchmark hoặc thí nghiệm đã làm. Hãy chạy prototype trên bộ test trước khi hứa, để khi thương lượng bạn có baseline trong tay chứ không phải cảm giác.

Bước năm: lấy chữ ký trên bản tiêu chí, sau đó cho eval chạy tự động. OpenAI khuyên thiết lập continuous evaluation để chạy eval sau mỗi thay đổi, và hiệu chỉnh phần chấm điểm tự động bằng đánh giá của con người.

Những cái bẫy hay gặp

Bẫy đầu tiên là chép ngưỡng từ dự án này sang dự án khác. Anthropic chỉ ra rằng độ chính xác của trích dẫn có thể là yếu tố sống còn với ứng dụng y tế nhưng ít quan trọng hơn nhiều với một chatbot trò chuyện. Ngưỡng 92% hợp với việc phân loại email chưa chắc đã hợp với việc tóm tắt hồ sơ bệnh án.

Bẫy thứ hai là chỉ có một con số tổng. Accuracy đẹp vẫn có thể giấu một dạng lỗi nặng. Bạn cần ít nhất một dòng tiêu chí về mức nghiêm trọng và một dòng riêng cho dạng lỗi khách sợ nhất.

Bẫy thứ ba là tự chọn bộ test. Nếu nhãn do bạn gán thì khi nghiệm thu, khách có lý do để không tin. Hãy để người phía khách xác nhận nhãn, ít nhất là với bộ test của những dạng lỗi nặng.

Bẫy cuối cùng là coi bản tiêu chí như giấy tờ ký một lần rồi cất đi. Prompt đổi, mô hình đổi, dữ liệu đầu vào cũng đổi. Bản tiêu chí chỉ có giá trị khi eval chạy lại sau mỗi lần như vậy.

Khi đọc JD, nếu bạn thấy các cụm như “define success metrics with customers” hay “build evals”, đó chính là kỹ năng này. Trong CV, hãy ghi cụ thể bạn đã chốt ngưỡng nào, đo trên bao nhiêu mẫu, và khách đã quyết định gì dựa trên con số đó.

Bài tập cho tuần này: chọn một tính năng AI bạn đang làm và viết một bản tiêu chí bốn dòng như bảng ở trên, mỗi dòng có ngưỡng, cỡ mẫu và cách đo. Sau đó thử tự trả lời câu “mỗi ngày bao nhiêu lỗi nặng thì chấp nhận được?”. Nếu bạn không trả lời được, thì đó chính là câu cần hỏi khách trong buổi họp tới.