Tỷ lệ pass là quyết định sản phẩm, và đó là việc của FDE

“Tỷ lệ pass của bạn là một quyết định sản phẩm.” Câu này của Hamel Husain, được Simon Willison nhắc lại trên blog của mình, nghe rất lạ với một kỹ sư quen viết unit test. Unit test thì phải pass 100%, không có chuyện thương lượng.

Nhưng chính câu đó giải thích vì sao eval đã trở thành kỹ năng cốt lõi của FDE làm AI. Hệ thống AI không cho ra cùng một output mỗi lần chạy, vì thế “đúng” không còn là chuyện kỹ thuật thuần túy. Ai đó phải quyết định đúng đến mức nào là đủ, và quyết định đó phải được viết thành thứ chạy được.

Anthropic nói thẳng ai nên làm việc này: người gần yêu cầu sản phẩm và người dùng nhất là người phù hợp nhất để định nghĩa thành công.

Trong một dự án triển khai AI, người đó không phải nhà nghiên cứu ở trụ sở, mà là kỹ sư ngồi trong văn phòng khách hàng, tức FDE theo đúng định nghĩa Andrew Ng dùng trên The Batch: kỹ sư nhúng trong tổ chức khách hàng.

Chi phí của việc không có eval rơi lên vai ai?

Anthropic định nghĩa eval rất gọn: đưa input cho hệ thống AI, rồi áp logic chấm điểm lên output. Đơn giản đến mức nhiều đội bỏ qua, và lý do bỏ qua cũng được Anthropic chỉ ra: chi phí của eval hiện ra ngay từ đầu, còn giá trị thì tích lũy dần nên dễ bị bỏ sót.

Hậu quả, vẫn theo Anthropic, là đội ngũ sa vào cảnh chạy theo sửa lỗi, chỉ phát hiện vấn đề khi hệ thống đã lên production. Hamel Husain nhận thấy các sản phẩm LLM thất bại thường có chung một gốc rễ: không xây được hệ thống đánh giá vững chắc.

Với FDE, chuyện này không trừu tượng. Khi agent trả lời sai cho một nhân viên của khách hàng, người nhận cuộc gọi là bạn, không phải đội model. Vì thế FDE là người gánh chi phí của việc thiếu eval, và cũng là người hưởng lợi nhiều nhất từ hiệu ứng tích lũy mà Anthropic nhắc tới.

Hamel gọi đó là flywheel: hệ thống eval tạo ra vòng quay cho phép lặp rất nhanh. Mỗi lần khách hàng báo lỗi, bạn biến nó thành một case mới, và lần sau bạn không phải đợi ai báo nữa.

Ba tầng đánh giá, và tầng nào là của FDE

Hamel chia việc đánh giá thành ba tầng: Level 1 là unit test, Level 2 là đánh giá bằng model và con người (bao gồm cả debugging), Level 3 là A/B testing. Nhìn qua thì đây là sơ đồ cho cả tổ chức. Nhưng nhìn kỹ, mỗi tầng đều cần một thứ mà FDE là người có sẵn nhất.

Tầng	Câu hỏi nó trả lời	Thứ FDE mang vào
Level 1: Unit test	Output có vi phạm quy tắc cứng nào không?	Các quy tắc nghiệp vụ nghe được từ người dùng tại hiện trường
Level 2: Model & human eval	Output có “tốt” theo nghĩa của khách hàng không?	Quan hệ với chuyên gia nghiệp vụ để căn chỉnh LLM-as-judge
Level 3: A/B testing	Phiên bản nào tạo kết quả kinh doanh tốt hơn?	Quyền truy cập vào luồng công việc thật để đo

Tầng 2 là nơi kỹ năng FDE lộ rõ nhất. Dùng LLM để chấm output nghe hấp dẫn vì rẻ và nhanh, nhưng Hamel cảnh báo rằng bạn phải căn chỉnh model theo đánh giá của con người, vì “đúng” là chuyện chủ quan.

Con người ở đây không phải bạn, mà là người kế toán, nhân viên chăm sóc khách hàng hay kỹ sư bảo trì đang dùng hệ thống hằng ngày, và chỉ FDE mới ngồi đủ gần để hỏi họ “cái này bạn chấm mấy điểm, vì sao?”.

Hamel còn đưa ra một nguyên tắc khác: phải loại bỏ mọi ma sát khỏi việc xem dữ liệu. Đọc trace thật, từng cái một, là việc cốt lõi chứ không phải việc phụ. Một FDE mở trace ra mỗi sáng sẽ thấy lỗi trước khi khách hàng thấy; một FDE chỉ nhìn dashboard sẽ thấy lỗi sau khi khách hàng đã bực.

pass@k hay pass^k: câu hỏi khách hàng chưa biết mình phải trả lời

Giờ quay lại câu của Hamel: tỷ lệ pass là quyết định sản phẩm. Để ra được quyết định đó, trước hết phải chọn đúng cách đo, và Anthropic tách bạch hai cách đo mà với agent lại cho kết quả rất khác nhau. pass@k đo xác suất ít nhất một trong k lần chạy thành công; pass^k đo xác suất tất cả k lần đều thành công.

Hai con số này có thể cách nhau rất xa với cùng một agent, vì agent không tất định.

Thử hình dung bạn đang triển khai một agent đọc hóa đơn cho phòng kế toán. Nếu quy trình của họ cho phép người kiểm tra lại và chạy thêm lần nữa, pass@k là thước đo hợp lý. Nếu kết quả đi thẳng vào sổ sách mà không ai nhìn lại, pass^k mới là con số họ thực sự cần, và nó sẽ thấp hơn nhiều.

Khách hàng thường không tự đặt câu hỏi này. Họ chỉ nói “phải chính xác”. FDE là người dịch “phải chính xác” thành “pass^5 trên bộ 200 case này phải trên ngưỡng X”, rồi đem ngưỡng X ra thương lượng.

Thương lượng ở đây là nghĩa đen. Khách hàng có xu hướng muốn 100%, trong khi một hệ thống không tất định hiếm khi cho được con số đó. Hãy mặc định rằng mỗi điểm phần trăm tăng thêm sẽ ngày càng đắt, và nói rõ điều đó với khách hàng ngay từ đầu.

Người duy nhất có cả hai mảnh thông tin, giới hạn của hệ thống và mức chịu đựng thật của nghiệp vụ, là kỹ sư đang ngồi giữa hai bên. Nếu bạn để quyết định đó rơi vào tay sales hoặc tay đội model, một bên sẽ hứa quá, bên kia sẽ đo thứ không ai cần.

Nếu Evals Engineer tách thành nghề riêng thì sao?

Andrew Ng phỏng đoán rằng nghề AI engineering có thể tách nhỏ, với những vai trò như AI FDE, LLMOps Engineer hay Evals Engineer. Có thể ông đúng. Nhưng ngay cả khi có một người chuyên viết hạ tầng eval, phần khó nhất vẫn không chuyển đi được: định nghĩa thành công.

Hạ tầng chấm điểm có thể tập trung hóa, còn cái hiểu về chuyện người dùng ở từng khách hàng coi lỗi nào là nghiêm trọng thì không.

Đó là lý do với một developer Việt Nam muốn chuyển sang FDE, eval là kỹ năng đáng đầu tư nhất lúc này, vì nó vừa là kỹ thuật vừa là bằng chứng bạn hiểu nghiệp vụ. Cách luyện không cần dự án lớn.

Lấy bất kỳ workflow AI nào bạn từng đụng, xây một bộ eval nhỏ từ trace thật, nhờ một người hiểu nghiệp vụ chấm tay, rồi đo xem LLM-as-judge của bạn lệch họ bao nhiêu. Làm trọn vòng đó một lần, bạn đã có một câu chuyện cụ thể để kể trong buổi phỏng vấn.

Trong CV, đừng viết “có kinh nghiệm prompt engineering”. Hãy viết bạn đã xây bộ eval bao nhiêu case, chấm theo cách nào, và tỷ lệ pass bạn thống nhất với người dùng là bao nhiêu.

Trong job description, hãy để ý những từ như evaluation, trace, observability hay “define success metrics with customers”: đó là tín hiệu công ty hiểu FDE làm gì, chứ không chỉ cần một người cài đặt.

Model sẽ đổi, framework sẽ đổi, prompt viết hôm nay sang quý sau có thể vứt. Thứ còn lại là bộ eval bạn đã xây cùng khách hàng, và cả câu trả lời cho câu hỏi mà chỉ bạn mới đủ gần để hỏi: đúng đến đâu thì đủ?