A/B test và cải tiến lặp

"Prompt mới nghe hay hơn" không phải là bằng chứng. Một thay đổi chỉ được tính là cải tiến khi nó thắng bản đang chạy trên cùng một chỉ số đã chốt từ trước, với đủ dữ liệu để không phải là may mắn.

Bài này giúp bạn trả lời: thiết kế và chạy một phép so sánh A/B thế nào, đọc kết quả ra sao, và đưa thay đổi lên production an toàn?

Ví dụ xuyên suốt: trợ lý đổi vé của một hãng xe khách

Một hãng xe khách liên tỉnh có trợ lý giúp khách đổi giờ, đổi chuyến. Đội sản phẩm viết prompt B: hỏi gọn hơn, gợi ý chuyến thay thế ngay từ câu đầu. Họ muốn biết B có làm nhiều khách đổi vé thành công mà không cần gọi tổng đài hơn prompt A đang chạy không.

Thiết kế trước khi chạy

1. Đã nói rõ đang kiểm định điều gì chưa?Viết giả thuyết và một chỉ số chính, ví dụ tỉ lệ đổi vé xong không cần tổng đài
2. Đã biết cần phát hiện chênh lệch tối thiểu bao nhiêu và cần bao nhiêu mẫu chưa?Chốt hiệu ứng tối thiểu và tính cỡ mẫu đủ mạnh
3. Đã có số liệu của bản đang chạy chưa?Đo baseline của A trên cùng chỉ số
4. Còn lạiRồi mới chia ngẫu nhiên và chạy

Bài viết về cách tiếp cận thống kê của Anthropic gọi bước tính cỡ mẫu là phân tích công suất (power analysis): liên hệ số quan sát, xác suất phát hiện, tỉ lệ dương tính giả và độ lớn hiệu ứng. Bài viết nói một bài đánh giá có quá ít câu hỏi có thể không đáng chạy để so hai model, vì nó không phân biệt nổi chúng.

So công bằng

• Đổi một biến mỗi lần. Prompt B mà đổi luôn cả model thì không biết cải thiện đến từ đâu.
• Ghim mọi thứ khác: cùng bộ dữ liệu, cùng grader, cùng model, cùng mức effort, và phiên bản prompt ghi rõ.
• Chạy nhiều lần. Một lần chạy có tính ngẫu nhiên. Bài viết thống kê khuyên báo sai số chuẩn và khoảng tin cậy 95% (trung bình cộng trừ 1,96 lần sai số chuẩn) cùng mỗi điểm số.
• So theo cặp. Khi hai phiên bản chạy trên cùng một bộ câu hỏi, so chênh lệch từng câu (paired differences) thay vì so hai trung bình độc lập; bài viết gọi đây là cách giảm phương sai gần như miễn phí, vì loại được độ khó riêng của từng câu.

Offline trước, thử thật sau

Docs của Anthropic về tiêu chí thành công gợi ý đặt mục tiêu so với baseline, ví dụ cải thiện 5% so với bản hiện tại trên một tập kiểm giữ riêng.

Thứ tự hợp lý: so offline để loại sớm phiên bản kém, rồi mới A/B với một phần lưu lượng thật cho phiên bản đã qua vòng offline.

Đọc kết quả theo từng nhóm

Tỉ lệ chung tăng chưa chắc an toàn. Có thể prompt B tốt hơn với khách đổi giờ cùng ngày nhưng tệ hơn với khách đổi chuyến cho cả nhóm 5 người. Chia kết quả theo các nhóm quan trọng (loại yêu cầu, tuyến, kênh) trước khi quyết định.

Đưa lên và quay lui theo phiên bản

Cookbook của Anthropic về quản lý phiên bản prompt trên Claude Managed Agents mô tả một cách làm áp dụng được cho mọi hệ thống:

• Mỗi lần cập nhật agent tạo ra một phiên bản bất biến mới.
• Gọi agent bằng mã trần thì luôn nhận phiên bản mới nhất. Rủi ro: ai đó cập nhật là production đổi theo ngay ở phiên kế tiếp. Production nên ghim một phiên bản cụ thể.
• Đưa lên là đổi số phiên bản mà production truyền vào, qua quy trình duyệt như mọi thay đổi cấu hình. Có thể cho một phần nhỏ lưu lượng dùng phiên bản mới trước (canary).
• Quay lui không cần triển khai lại: chỉ việc truyền lại số phiên bản cũ.

Cookbook cũng lưu ý không có bước duyệt tích hợp sẵn khi cập nhật agent; số phiên bản được ghim chính là cửa kiểm soát.