Embedding drift: vector cũ trong DB và vector query mới không còn nằm cùng một không gian → điểm tương đồng mất ý nghĩa, chất lượng tìm kiếm sập.
Ba dạng:
- Lệch số chiều — 1536 sang 3072 chiều: không tính cosine được. Hỏng lộ liễu nên dễ phát hiện.
- Cùng số chiều, khác không gian — vẫn ra được một con số, nhưng "gần nhau" thôi không còn nghĩa là gần về ngữ nghĩa. Đây là dạng nguy hiểm nhất vì hệ vẫn chạy, chỉ trả kết quả kém dần.
- Provider âm thầm cập nhật model dưới cùng một tên — vector mới lệch khỏi vector cũ mà không ai đổi dòng code nào.
Chiến lược migration:
- Re-embed toàn bộ vào một collection song song là cách chuẩn. Mấu chốt: không ghi đè collection cũ. Có bản mới rồi mới chuyển query sang, đối chiếu xong mới xoá bản cũ.
- Ghi kép (dual-write) khi corpus liên tục cập nhật: trong giai đoạn chuyển, tài liệu mới được embed bằng cả hai model.
- Chuyển dần theo mức ưu tiên nếu corpus quá lớn: tài liệu đang hoạt động trước, phần lưu trữ sau.
- Cắt chiều (Matryoshka): các model kiểu này cho phép cắt bớt chiều mà vector vẫn dùng được — đổi giữa các mức chiều của cùng một model thì chỉ cần cắt, khỏi embed lại.
Trong lúc chạy song song hai model, lưu embedding_version trong metadata và để router chọn collection theo version; tài liệu chưa kịp chuyển thì embed tại chỗ.
Nghiệm thu — đừng chỉ xem hệ có chạy không: giữ một bộ query chuẩn rồi so top-K giữa hai phiên bản, recall@k tụt là dấu hiệu báo động. Sau đó mới tới chỉ số end-to-end và chỉ số người dùng. Bật dần 1% → 10% → 50% để còn rollback được.
Chặn từ gốc:
- Ghim version model — dùng tên có gắn ngày, không dùng bí danh latest. Đây là biện pháp rẻ nhất và cũng hay bị bỏ qua nhất.
- Giữ lại văn bản gốc để lúc nào cũng embed lại được; đừng chỉ lưu vector.
- Self-host thì đóng băng version model trong Docker image và tắt tự cập nhật — embedding lệch giữa hai lần build là lỗi ngầm cực khó truy.