Trong nhiều dự án Machine Learning, chúng ta thường nói nhiều về chọn thuật toán, tuning hyperparameter hoặc dùng mô hình lớn hơn. Nhưng với các bài toán dữ liệu dạng bảng, chuỗi thời gian, dự báo nhu cầu, chấm điểm rủi ro, phân loại khách hàng… một phần rất quan trọng vẫn là feature engineering: cách biến dữ liệu thô thành các đặc trưng có ý nghĩa để mô hình học tốt hơn. Nói ngắn gọn, feature engineering là quá trình tạo, chọn, biến đổi và chuẩn hóa các biến đầu vào trước khi đưa vào mô hình. Một mô hình tốt không chỉ cần nhiều dữ liệu, mà cần dữ liệu được biểu diễn đúng với bản chất bài toán. Ví dụ thực tế: dự đoán khách hàng có rời bỏ dịch vụ hay không Giả sử bạn có dữ liệu người dùng gồm: ngày đăng ký, số lần đăng nhập, số giao dịch, gói dịch vụ, số lần liên hệ hỗ trợ, trạng thái còn dùng hay đã rời bỏ. Nếu chỉ đưa trực tiếp các cột thô vào mô hình, kết quả có thể chưa tốt. Thay vào đó, ta có thể tạo thêm các đặc trưng như: - Số ngày kể từ lần đăng nhập gần nhất. - Số lần đăng nhập trong 7 ngày gần đây so với 30 ngày trước. - Tỷ lệ giao dịch thành công trên tổng giao dịch. - Số lần liên hệ hỗ trợ trong tháng gần nhất. - Tuổi đời tài khoản tính từ ngày đăng ký. - Người dùng có giảm tần suất sử dụng trong thời gian gần đây hay không. Những đặc trưng này thường phản ánh hành vi tốt hơn so với dữ liệu gốc. Ví dụ, “ngày đăng nhập cuối” tự nó không có nhiều ý nghĩa, nhưng “đã bao nhiêu ngày không đăng nhập” lại là tín hiệu mạnh cho nguy cơ rời bỏ. Một số nhóm feature thường hữu ích 1. Feature về thời gian Với dữ liệu có mốc thời gian, nên cân nhắc tạo các biến như giờ trong ngày, ngày trong tuần, tháng, quý, khoảng cách từ sự kiện gần nhất, số lượng sự kiện trong một cửa sổ thời gian. Ví dụ với bài toán dự báo đơn hàng, doanh số ngày thứ Hai có thể khác cuối tuần; tháng gần Tết có thể khác các tháng bình thường. 2. Feature tổng hợp theo lịch sử Các biến dạng đếm, trung bình, tổng, tỷ lệ, min/max trong quá khứ rất hữu ích. Ví dụ: - Tổng số đơn hàng trong 30 ngày gần nhất. - Giá trị đơn hàng trung bình của khách hàng. - Tỷ lệ hoàn đơn. - Số ngày trung bình giữa hai lần mua hàng. Lưu ý quan trọng: chỉ dùng dữ liệu có sẵn trước thời điểm dự đoán. Nếu bạn vô tình dùng thông tin xảy ra sau thời điểm dự đoán, đó là data leakage. 3. Feature dạng tỷ lệ thay vì chỉ dùng số tuyệt đối Số tuyệt đối đôi khi gây hiểu nhầm. Một khách hàng có 10 lỗi giao dịch nghe có vẻ nhiều, nhưng nếu họ thực hiện 10.000 giao dịch thì tỷ lệ lỗi rất thấp. Vì vậy, các feature dạng tỷ lệ thường ổn định hơn: - Tỷ lệ giao dịch lỗi. - Tỷ lệ email được mở. - Tỷ lệ sản phẩm bị trả lại. - Tỷ lệ phiên đăng nhập có phát sinh hành động chính. 4. Feature từ dữ liệu phân loại Với biến phân loại như tỉnh thành, loại thiết bị, ngành nghề, gói dịch vụ, cần mã hóa phù hợp. One-hot encoding dễ dùng với số lượng nhóm nhỏ. Với số lượng nhóm lớn, có thể cân nhắc gom nhóm hiếm, target encoding có kiểm soát, hoặc embedding nếu dùng mô hình deep learning. Không nên để mô hình phải học từ hàng nghìn giá trị rời rạc quá thưa mà không có chiến lược xử lý. Ví dụ, cột “mã sản phẩm” có thể có hàng chục nghìn giá trị, nhưng nhóm sản phẩm, mức giá, thương hiệu hoặc tần suất bán có thể hữu ích hơn. 5. Feature từ văn bản đơn giản Không phải lúc nào cũng cần mô hình ngôn ngữ lớn. Với các bài toán cơ bản, bạn có thể bắt đầu bằng: - Độ dài văn bản. - Số từ. - Số ký tự đặc biệt. - Có chứa từ khóa quan trọng hay không. - TF-IDF cho phân loại văn bản truyền thống. Ví dụ phân loại phản hồi khách hàng, các feature như “có chứa từ hoàn tiền”, “có chứa từ lỗi”, “độ dài phản hồi” đôi khi đã tạo baseline khá tốt. Những lỗi thường gặp khi làm feature engineering - Tạo quá nhiều feature nhưng không kiểm tra giá trị thực tế. - Dùng dữ liệu tương lai, gây data leakage. - Tính feature train và production không giống nhau. - Không xử lý missing value một cách nhất quán. - Không lưu lại logic tạo feature, khiến kết quả khó tái lập. - Chỉ nhìn điểm số tổng thể mà không phân tích feature nào thực sự có ích. Lời khuyên có thể áp dụng ngay Trước khi tạo feature, hãy viết rõ: mô hình đang dự đoán điều gì, tại thời điểm nào, và dữ liệu nào được phép sử dụng tại thời điểm đó. Đây là cách đơn giản để tránh leakage. Sau đó, hãy bắt đầu với một bộ feature nhỏ nhưng dễ giải thích. Huấn luyện baseline, đo kết quả, rồi thêm feature theo từng nhóm. Nếu thêm 20 feature mà điểm số không cải thiện hoặc mô hình kém ổn định hơn, có thể bạn đang thêm nhiễu. Nên lưu toàn bộ logic tạo feature trong code có kiểm soát phiên bản, thay vì thao tác thủ công trong notebook. Với dự án production, cần đảm bảo feature khi huấn luyện và khi chạy thật được tính theo cùng một định nghĩa. Cuối cùng, hãy kiểm tra phân phối của feature giữa tập train, validation và dữ liệu thực tế. Nếu một feature có phân phối thay đổi mạnh, mô hình có thể bị giảm chất lượng khi triển khai. Kết luận Feature engineering không phải là công việc “cũ kỹ” chỉ dành cho thời trước deep learning. Trong rất nhiều bài toán thực tế, đặc biệt là dữ liệu doanh nghiệp, đặc trưng tốt giúp mô hình học nhanh hơn, dễ giải thích hơn và ổn định hơn. Thay vì vội dùng mô hình phức tạp, hãy dành thời gian hiểu dữ liệu, tạo feature phản ánh đúng hành vi và kiểm tra chúng cẩn thận. Đây thường là khoản đầu tư rẻ nhưng mang lại hiệu quả lớn trong dự án Machine Learning.