Khi bộ Eval Suite đo lường sai lệch thực tế (The eval suite that measured the wrong thing)

Tái hiện buổi mổ xẻ sự cố thực tế (A partner postmortem)

Bản phân tích dưới đây tổng hợp một mẫu thất bại lặp đi lặp lại nhiều lần trong các đợt triển khai thực tế:

Một đội ngũ kỹ thuật xây dựng một trợ lý rà soát hợp đồng (contract review assistant) cho một công ty dịch vụ chuyên nghiệp. Họ kiểm tra thủ công hệ thống trên 10 hợp đồng mà cả team đã quá quen thuộc, tuyên bố hệ thống đã sẵn sàng và đưa thẳng lên production. Lỗi hồi quy (regression) bùng nổ chỉ sau 2 tuần vận hành.

Kết quả điều tra hậu kiểm (What the postmortem found):

• Thất bại trên nhóm dữ liệu lạ: Hệ thống hoàn toàn gãy vụn trước một nhóm hợp đồng chưa từng được thử nghiệm: các hợp đồng có cấu trúc nghĩa vụ phi tiêu chuẩn (non-standard obligation structures). Model đã trích xuất các điều khoản nghĩa vụ từ sai phần mục.

• Bộ eval suite có tồn tại, nhưng vô nghĩa: Đội ngũ thực chất có xây dựng một eval suite ngay từ đầu dự án, nhưng nó lại được tạo ra từ đúng 10 bản hợp đồng quen thuộc mà team dùng lúc phát triển. Đây hoàn toàn không phải là một mẫu mang tính đại diện (representative sample) cho toàn bộ tập hợp hợp đồng thực tế.

• Eval vẫn pass dù prompt đã thay đổi: Khi prompt được cập nhật trong quá trình tối ưu, eval suite vẫn tiếp tục báo đạt 100%. Lý do là golden dataset vẫn giữ nguyên kết quả kỳ vọng của prompt cũ chứ chưa bao giờ được cập nhật để bắt kịp hành vi mới của hệ thống.

3 quyết định sai lầm dẫn tới sự cố

• Xây dựng eval dataset từ các đầu vào "tiện tay" thay vì một mẫu đại diện: Một bộ eval suite không bao quát được phân phối đầu vào thực tế mà hệ thống phải đối mặt trên production thực chất đang đo lường một hệ thống hoàn toàn khác với hệ thống bạn chuẩn bị bàn giao.

• Không cập nhật tập dữ liệu eval sau khi thay đổi prompt: Bộ eval vẫn liên tục báo xanh chỉ vì nó đang đánh giá hành vi mà prompt không còn tạo ra nữa. Điểm số nhìn rất ổn định đơn giản vì không có bài kiểm tra nào thực sự đo lường những gì vừa bị thay đổi.

• Coi việc kiểm tra thủ công là phương án thay thế cho Eval: Các bài kiểm tra ngẫu hứng (spot-checks) chỉ có thể xác nhận rằng một đầu vào cụ thể tạo ra một đầu ra cụ thể đã biết, nhưng hoàn toàn bất lực trong việc cho bạn biết hệ thống sẽ hành xử ra sao trước các đầu vào chưa từng thấy.

Điểm chốt chặn cho Kiến trúc sư (What to Watch Out for)

Bộ eval suite trong trường hợp này có tồn tại nhưng đã bị cấu hình sai lệch ở cả 2 khía cạnh: dữ liệu không mang tính đại diện và không được cập nhật đồng bộ.

Cả hai lỗ hổng này đều hoàn toàn vô hình cho đến khi môi trường production lột trần chúng. Hệ thống trông có vẻ hoàn hảo và khỏe mạnh trong giai đoạn phát triển chỉ đơn giản vì nó đang được kiểm tra trên chính những dữ liệu mà nó vốn đã được tối ưu hóa để vượt qua.