Bài 7 — So sánh phiên bản & ngăn regression

Bạn muốn đổi từ prompt v7 sang v8, hoặc từ model A sang model B rẻ hơn. Câu hỏi sống còn: phiên bản mới thực sự tốt hơn, hay chỉ tốt hơn ở vài ca bạn thử tay? Bài này dựng quy trình so sánh có kỷ luật.

Nguyên tắc: so sánh trên cùng một dataset cố định

Muốn kết luận công bằng, hai phiên bản phải chạy trên cùng bộ ca và cùng scorer. Đây gọi là experiment:

Experiment A: prompt=v7, model=gpt-4o   -> chạy trên dataset D -> điểm số A
Experiment B: prompt=v8, model=gpt-4o   -> chạy trên dataset D -> điểm số B
So sánh A vs B theo TỪNG ca, không chỉ trung bình.

Cả ba nền tảng đều có view so sánh experiment cạnh nhau, tô màu ca cải thiện (xanh) và ca hồi quy (đỏ).

Bước 1 — Cố định biến

• Khóa dataset (cùng ca, cùng expected).
• Khóa scorer (cùng judge, cùng rubric).
• Chỉ đổi một biến mỗi lần (prompt HOẶC model), nếu không bạn không biết cái nào tạo khác biệt.
• Cố định nhiệt độ/seed để giảm dao động.

Bước 2 — Đọc kết quả đúng cách

Đừng chỉ nhìn "điểm trung bình v8 = 0.86 > v7 = 0.83, ship!". Hãy:

• Xem phân bố theo nhóm: v8 tăng nhóm refund nhưng có tụt nhóm shipping không?
• Đếm regression tuyệt đối: bao nhiêu ca từ đúng thành sai? Một regression ở ca quan trọng có thể quan trọng hơn +0.03 trung bình.
• Xét chi phí & latency: v8 tốt hơn 2% nhưng đắt gấp đôi có đáng không?

Ví dụ bảng quyết định

Kết luận: v8 tốt hơn tổng thể nhưng phải điều tra 3 ca refund hồi quy trước khi ship.

Bước 3 — A/B online sau khi qua eval offline

Eval offline chỉ mô phỏng. Để chắc chắn, chạy A/B trên traffic thật:

• Chia traffic: 90% v7, 10% v8 (canary).
• Gắn prompt_version vào metadata mọi trace.
• So sánh chỉ số online giữa hai nhánh: feedback 👍/👎, tỉ lệ escalate, độ dài hội thoại, điểm LLM-judge trên sample.
• Nếu nhánh v8 ổn sau X ngày, tăng dần lên 100%. Xấu thì rollback ngay.

Khung "cổng ship" (ship gate)

CHỈ ship phiên bản mới khi TẤT CẢ đúng:
[ ] Điểm eval offline >= ngưỡng, không dưới baseline.
[ ] Số regression ca-quan-trọng = 0 (hoặc đã chấp nhận có chủ đích).
[ ] Chi phí & p95 latency trong ngân sách.
[ ] Canary online không xấu đi sau thời gian quan sát.
[ ] Có kế hoạch rollback rõ ràng.

Sai lầm thường gặp

• Đổi nhiều biến cùng lúc (prompt + model + tool): không biết cái nào gây khác biệt.
• Chỉ tin điểm trung bình: bỏ sót regression cục bộ ở ca quan trọng.
• Bỏ qua chi phí/độ trễ: ship bản "tốt hơn" nhưng đắt gấp đôi, cháy ngân sách.
• Ship thẳng 100% không canary: mất cơ hội bắt lỗi trên traffic thật trước khi ảnh hưởng toàn bộ người dùng.
• Không gắn prompt_version vào trace: A/B online biến thành mù, không phân tách được nhánh.

Bạn đã biết ship an toàn. Bài cuối: giám sát khi agent đã sống trong production.