Eval đang trở thành "definition of done" của FDE, và thành cả điều khoản hợp đồng

Pass rate của bộ eval sắp xuất hiện ở một chỗ ít kỹ sư ngờ tới: trong thỏa thuận thương mại với khách hàng. Đó là lập luận của FDE Hub trong bài “The Definition of Done” đăng giữa tháng 9, và nó nhắm thẳng vào một cách nghĩ rất phổ biến ở các đội triển khai: hệ thống đang chạy, khách đang dùng, vậy là xong.

Milos Mandic và John (SuccessVP), hai tác giả của FDE Hub, cho rằng eval đang trở thành definition of done cho công việc AI, không chỉ riêng việc viết code. Với một kỹ sư muốn chuyển sang FDE, điều này đổi hẳn cách bạn chứng minh giá trị. Không phải demo chạy được, mà là bộ test đã được chấm điểm.

Từ chỉ số nội bộ thành điều khoản hợp đồng

Chi tiết đáng chú ý nhất trong lập luận của FDE Hub là vai trò kép của eval: bên trong công ty nó là metric, bên ngoài nó là hợp đồng giữa vendor và khách. Con số pass rate vì thế không còn là chuyện riêng của team kỹ thuật, mà là thứ cả vendor lẫn khách cùng cam kết.

PostHog, trong handbook cho đội FDE của mình, đi đến cùng một chỗ bằng con đường khác. Trước khi delivery bắt đầu, mỗi engagement cần một outcome đo được, một timeline sơ bộ và một definition of done được hai bên thống nhất. Họ đo engagement bằng những gì đã thay đổi cho khách hàng, và chốt cách đo trước khi bắt tay vào làm.

Vì thế scope cũng được khóa theo definition of done. PostHog nói thẳng: một deliverable phình gấp đôi scope là một báo giá mới, không phải một phần mở rộng không chính thức. Khi “xong” được định nghĩa bằng eval, mọi yêu cầu thêm đều có chỗ để đối chiếu, và FDE không còn phải tranh luận với khách dựa trên cảm nhận của mỗi bên.

Vì sao “đang chạy” không đủ

Anthropic định nghĩa eval rất gọn: đưa cho AI một input, rồi áp logic chấm điểm lên output để đo thành công. Đội nào không có eval thì kẹt trong vòng lặp phản ứng, chỉ bắt được lỗi khi đã lên production. Đó chính là trạng thái “đang chạy” quen thuộc: hệ thống vẫn chạy, nhưng chạy để vá lỗi khách vừa báo.

Nhưng có eval cũng chưa đủ. Anthropic tách riêng regression eval với một câu hỏi: agent có còn xử lý được tất cả các task nó từng làm được không? FDE Hub đẩy ý này xa hơn. Moat chưa bao giờ là file eval, mà là thư viện eval được duy trì xuyên suốt nhiều khách hàng.

Một file eval không ai cập nhật sẽ dần trả lời những câu hỏi không còn ai hỏi. FDE Hub cảnh báo đúng điểm này: pass rate cao trên một bộ eval đã lỗi thời có thể đánh lừa, và con số đẹp ấy ru ngủ cả đội lẫn khách.

Bắt đầu từ log, không phải từ rubric

Vậy eval được viết thế nào? Hamel Husain chỉ ra một lỗi phổ biến: viết rubric trước khi nhìn vào bất kỳ dữ liệu nào. Trình tự đúng là phân tích log thật trước, để định nghĩa thất bại từ những gì hệ thống thực sự làm sai, rồi mới biến chúng thành test case.

Với FDE, log của khách chính là nguyên liệu, và quyền ngồi cạnh khách để đọc log là lợi thế kỹ sư ở trụ sở không có.

Bản thân FDE cũng được đánh giá bằng đúng thước đo ấy. FDE Academy cho biết hiệu suất của FDE được xét trên một evaluation harness có tài liệu, với test case được chấm điểm và định nghĩa thất bại rõ ràng, chứ không phải trên demo chạy được.

Nếu bạn đang chuẩn bị CV cho vị trí FDE, hãy đổi cách kể dự án. Thay vì “triển khai chatbot cho ngân hàng X”, hãy viết bộ eval gồm bao nhiêu case, lấy từ log nào, pass rate tăng từ bao nhiêu lên bao nhiêu, và ai ở phía khách ký nhận định nghĩa done.

Khi đọc JD, tìm các từ eval, harness, measurable outcome; nếu không thấy, hỏi trong phỏng vấn ai là người quyết định một engagement đã xong.

Câu trả lời cho câu hỏi đó sẽ cho bạn biết công ty đang bán demo hay bán kết quả. PostHog đã chọn đo bằng những gì thay đổi cho khách, FDE Academy đã chọn chấm FDE bằng harness thay vì demo; nếu phải đặt cược, hãy đặt vào phía đang đo.