Vì sao versioning là bài toán sản phẩm, không chỉ kỹ thuật
Khi một model phục vụ nhiều đội, mỗi lần bạn đổi nó là bạn thay đổi hành vi của nhiều sản phẩm cùng lúc. Một model 'tốt hơn' theo eval tổng thể vẫn có thể phá vỡ một đội cụ thể phụ thuộc vào một đặc tính cũ. Vì vậy versioning và migration là kỹ năng cốt lõi của Platform PM.
Nguyên tắc: hợp đồng ổn định, thay đổi tường minh
Áp dụng tư duy versioning ngữ nghĩa (semantic) cho model:
- Thay đổi tương thích (minor): cải thiện chất lượng nhưng giữ nguyên giao diện và hành vi kỳ vọng → có thể tự động cập nhật với thông báo.
- Thay đổi phá vỡ (major): đổi định dạng đầu ra, đổi ngưỡng, đổi hành vi mà đội đang phụ thuộc → bắt buộc version mới song song, không được thay ngầm.
Mẫu triển khai an toàn cho model dùng chung
- Registry-first: version mới vào registry với đầy đủ điểm eval so sánh version cũ.
- Shadow / mirror: chạy song song, gương traffic thật sang version mới để so soutput, chưa phục vụ khách.
- Canary theo đội: cho một đội ít rủi ro thử trước, theo dõi metric riêng của họ.
- Rollout dần kèm khả năng rollback tức thì bằng cờ (flag) định tuyến ở gateway.
- Deprecate có thời hạn: công bố version cũ sẽ ngừng sau N ngày, kèm dashboard cho từng đội thấy họ còn nợ migrate bao nhiêu traffic.
Khung tư duy: Migration là một sản phẩm
Đừng chỉ 'ra version mới'. Hãy đóng gói cả đường nâng cấp: hướng dẫn, công cụ so sánh output cũ/mới, người liên hệ hỗ trợ, thời hạn rõ ràng, và dashboard tiến độ. Đội nội bộ sẽ migrate nhanh khi việc đó dễ và an toàn hơn việc trì hoãn.
Ví dụ cụ thể
Bạn nâng summarizer-v2 lên v3 cho kết quả súc tích hơn. Đội Legal lại phụ thuộc bản tóm tắt dài để trích dẫn. Nếu thay ngầm, sản phẩm Legal hỏng vào thứ Sáu và không ai biết vì sao. Cách đúng: giữ v2 chạy song song, canary v3 cho đội Marketing trước, cho Legal 60 ngày và một dashboard hiển thị họ còn 100% traffic trên v2 → họ có thời gian điều chỉnh hoặc chọn ở lại v2 tạm thời.
Sai lầm thường gặp
- Thay model ngầm dưới cùng một tên vì 'chỉ tốt hơn thôi' → phá vỡ đội phụ thuộc hành vi cũ, mất niềm tin.
- Không có rollback nhanh → một canary hỏng biến thành sự cố toàn nền tảng.
- Deprecate không thời hạn → 'tạm thời giữ v cũ' kéo dài vĩnh viễn, nợ chồng chất, chi phí gấp đôi.
- Ra version mới nhưng không có công cụ migrate → đội mắc kẹt ở bản cũ, phân mảnh.
Checklist phát hành model dùng chung
- [ ] Version mới đã vào registry kèm điểm eval so sánh version cũ.
- [ ] Xác định rõ đây là thay đổi minor (tương thích) hay major (phá vỡ).
- [ ] Có shadow/canary theo đội trước khi rollout rộng.
- [ ] Có cờ định tuyến để rollback tức thì ở gateway.
- [ ] Có thời hạn deprecate và dashboard nợ migration theo đội.
- [ ] Đã thông báo trước cho mọi đội phụ thuộc, kèm đường nâng cấp.