1. 13:54 17/08/2026
Khi một mô hình Machine Learning chuyển từ notebook sang sản phẩm, vấn đề không chỉ nằm ở việc chọn thuật toán. Một lỗi phổ biến là đặc trưng được tạo theo hai cách khác nhau giữa lúc huấn luyện và lúc dự đoán. Mô hình có thể đạt kết quả tốt trong thử nghiệm nhưng hoạt động kém khi triển khai vì dữ liệu đầu vào thực tế không còn giống dữ liệu đã học.
Feature Store được dùng để quản lý và cung cấp các đặc trưng cho cả hai giai đoạn này. Tuy nhiên, nó không đơn giản là một kho lưu trữ cột dữ liệu. Một thiết kế tốt phải trả lời được các câu hỏi: đặc trưng được tính từ nguồn nào, có hiệu lực tại thời điểm nào, cập nhật với tần suất bao lâu, xử lý dữ liệu thiếu ra sao và làm thế nào để lấy cùng một định nghĩa trong môi trường huấn luyện lẫn môi trường suy luận.
Ví dụ thực tế: một hệ thống phát hiện giao dịch đáng ngờ dùng đặc trưng số lần giao dịch của tài khoản trong 24 giờ gần nhất. Khi huấn luyện, nhóm dữ liệu có thể được tạo bằng một truy vấn tổng hợp trên lịch sử. Nhưng khi chạy thật, dịch vụ dự đoán lại dùng một truy vấn khác, vô tình tính cả giao dịch xảy ra sau thời điểm cần dự đoán. Kết quả đánh giá offline bị cao giả tạo, còn mô hình thực tế suy giảm rõ rệt. Đây là dạng sai lệch giữa huấn luyện và phục vụ, thường khó phát hiện nếu chỉ kiểm tra độ chính xác cuối cùng.
Một số nguyên tắc nên áp dụng:
- Định nghĩa đặc trưng một lần, tái sử dụng ở nhiều nơi. Công thức, kiểu dữ liệu, đơn vị đo và điều kiện lọc cần được mô tả rõ ràng thay vì nằm rải rác trong nhiều script.
- Bảo đảm tính đúng theo thời điểm. Khi tạo tập huấn luyện, chỉ được dùng dữ liệu đã tồn tại trước thời điểm dự đoán. Các phép nối dữ liệu cần hỗ trợ truy vấn theo mốc thời gian, không chỉ nối bằng mã đối tượng.
- Tách nhu cầu offline và online. Huấn luyện thường cần đọc khối lượng dữ liệu lớn, còn suy luận trực tuyến cần phản hồi nhanh. Có thể dùng kho phân tích cho offline và một lớp phục vụ giá trị mới nhất cho online, nhưng hai bên phải dùng cùng một định nghĩa đặc trưng.
- Theo dõi độ mới của dữ liệu. Một đặc trưng cập nhật chậm, bị trễ đồng bộ hoặc ngừng ghi nhận có thể khiến mô hình nhận đầu vào cũ mà không phát sinh lỗi kỹ thuật. Nên đặt ngưỡng cảnh báo cho tuổi dữ liệu, tỷ lệ thiếu và phân phối giá trị.
- Chuẩn hóa cách xử lý giá trị thiếu. Giá trị thiếu do người dùng chưa có lịch sử khác với lỗi đường truyền. Hai trường hợp này có thể cần cờ đánh dấu riêng, thay vì đều bị thay bằng số 0.
- Chuẩn bị phương án dự phòng. Nếu kho đặc trưng trực tuyến tạm thời không phản hồi, hệ thống nên dùng giá trị gần nhất còn hợp lệ, giá trị mặc định an toàn hoặc chuyển sang quy trình kiểm tra bổ sung. Không nên để một lỗi đọc dữ liệu biến thành quyết định rủi ro.
Trước khi xây dựng một Feature Store đầy đủ, nhóm phát triển nên lập danh sách các đặc trưng và kiểm tra chúng bằng một bộ dữ liệu dùng chung. Hãy so sánh kết quả tính offline với kết quả của đường suy luận online trên cùng các mã đối tượng và cùng mốc thời gian. Những sai khác nhỏ về múi giờ, làm tròn số, cửa sổ thời gian hoặc quy tắc lọc thường là nguyên nhân chính của lỗi.
Feature Store không phải bắt buộc cho mọi dự án. Với mô hình chạy theo lô một lần mỗi ngày và ít đặc trưng, một pipeline dữ liệu có kiểm thử đầy đủ có thể đơn giản và dễ bảo trì hơn. Nó trở nên đáng cân nhắc khi nhiều mô hình dùng chung đặc trưng, ứng dụng cần dự đoán trực tuyến, hoặc việc đồng bộ công thức giữa nhiều nhóm đã bắt đầu khó kiểm soát.
Mục tiêu cuối cùng không phải là sở hữu thêm một thành phần hạ tầng, mà là tạo ra một nguồn sự thật nhất quán cho đặc trưng. Hãy bắt đầu từ vài đặc trưng quan trọng, kiểm thử tính đúng theo thời điểm, đo độ mới và quan sát chênh lệch giữa offline với online trước khi mở rộng quy mô.