Mở đầu — vì sao bài này quan trọng
Có một sự thật mà nhiều PM mới bước vào lĩnh vực Machine Learning thường hiểu sai: họ nghĩ rằng chất lượng của một sản phẩm AI phụ thuộc chủ yếu vào việc team chọn được thuật toán "xịn" nhất — XGBoost hay một mạng neural sâu, GPT hay một model nhỏ tự huấn luyện. Nhưng nếu bạn hỏi bất kỳ Data Scientist nào có kinh nghiệm thực chiến, họ sẽ nói với bạn một câu gần như câu cửa miệng: "Phần lớn thời gian của tôi không dành cho model, mà dành cho dữ liệu và feature."
Đây chính là lý do bài học này tồn tại. Feature Engineering — kỹ thuật biến dữ liệu thô thành các tín hiệu (signal) mà model có thể học được — thường là yếu tố tạo ra khác biệt lớn nhất giữa một model "chạy được" và một model thực sự tạo giá trị kinh doanh. Có một câu nói kinh điển trong ngành: "Garbage in, garbage out" — dữ liệu rác đưa vào thì kết quả rác đưa ra. Một bộ feature tốt thường mạnh hơn nhiều so với một model phức tạp được nuôi bằng feature kém.
Là một Technical PM, bạn không cần tự tay viết code để tạo feature. Nhưng bạn cần hiểu đủ sâu để: đánh giá xem một ý tưởng feature có khả thi không, ước lượng chi phí và độ trễ khi đưa feature đó vào production, nhận ra rủi ro như data leakage trước khi nó phá hỏng cả dự án, và quan trọng nhất — biết cách khơi gợi feature từ chính kiến thức nghiệp vụ (domain knowledge) mà team kỹ thuật không có. Trong nhiều dự án, chính PM là người hiểu khách hàng và bài toán nghiệp vụ nhất, và một gợi ý feature đúng lúc từ PM có thể giúp tăng vài điểm phần trăm độ chính xác mà cả tháng tinh chỉnh model không làm được.
Khái niệm cốt lõi
Feature là gì
Feature là một biến đầu vào (input variable) mà model sử dụng để đưa ra dự đoán. Nói cách khác, mỗi feature là một "tín hiệu" mô tả một khía cạnh của đối tượng bạn đang muốn dự đoán. Nếu bạn hình dung dữ liệu dưới dạng một bảng (như bảng Excel), thì mỗi dòng là một mẫu (sample/observation) — ví dụ một khách hàng, một giao dịch — và mỗi cột (trừ cột mục tiêu cần dự đoán) chính là một feature.
Ví dụ, để dự đoán một khách hàng có rời bỏ dịch vụ (churn) hay không, các feature có thể là: số ngày kể từ lần đăng nhập gần nhất, tổng số tiền đã chi trong 30 ngày, số lần liên hệ chăm sóc khách hàng, gói cước đang dùng. Cột "có churn hay không" là label (mục tiêu), còn tất cả những cột còn lại là feature.
Hai loại feature cơ bản
Numerical (số): giá trị có thể đo lường và so sánh được, ví dụ tuổi, số tiền, số lần click, thời lượng xem video. Model có thể trực tiếp tính toán trên loại này.
Categorical (phân loại): giá trị thuộc về một nhóm rời rạc, ví dụ thành phố (Hà Nội, TP.HCM, Đà Nẵng), loại thiết bị (iOS, Android), nghề nghiệp. Phần lớn model không hiểu chữ, nên categorical cần được mã hóa (encoding) thành số trước khi đưa vào model. Hai cách phổ biến: one-hot encoding (mỗi giá trị thành một cột 0/1) và label encoding (gán mỗi giá trị một con số).
Feature Engineering là gì
Feature Engineering là quá trình tạo ra, biến đổi và lựa chọn các feature từ dữ liệu thô để giúp model học tốt hơn. Nó bao gồm vài nhóm kỹ thuật chính mà PM nên nhận diện được:
Transformation (biến đổi): thay đổi dạng của feature để model dễ học hơn. Ví dụ, thu nhập của khách hàng có thể chênh nhau cả nghìn lần (5 triệu so với 5 tỷ), nên người ta thường lấy logarit để "nén" lại. Hoặc normalization/scaling — đưa các feature về cùng một thang đo để feature có giá trị lớn không lấn át feature có giá trị nhỏ.
Aggregation (tổng hợp): gộp nhiều bản ghi thành một con số đại diện. Ví dụ từ lịch sử hàng nghìn giao dịch của một khách hàng, ta tạo ra feature "trung bình giá trị đơn hàng 90 ngày qua" hay "số đơn hàng tháng này". Đây là nhóm feature giàu tín hiệu nhất trong nhiều bài toán thực tế.
Feature từ thời gian: từ một mốc thời gian (timestamp) có thể tách ra giờ trong ngày, thứ trong tuần, có phải cuối tuần không, có phải dịp lễ Tết không. Những feature này cực kỳ giá trị trong bài toán dự đoán nhu cầu, gian lận, hay hành vi người dùng.
Interaction features (feature tương tác): kết hợp hai feature để tạo tín hiệu mới. Ví dụ "tổng chi tiêu chia cho số ngày là khách hàng" cho ra một chỉ số mức độ giá trị mạnh hơn từng feature riêng lẻ.
Domain knowledge — vũ khí của PM
Điểm mấu chốt khiến feature engineering không thể tự động hóa hoàn toàn: feature tốt thường đến từ hiểu biết nghiệp vụ. Một thuật toán không biết rằng ở Việt Nam, hành vi mua sắm tăng vọt vào dịp cận Tết, hay rằng giao dịch lúc 3 giờ sáng đáng ngờ hơn giao dịch lúc 3 giờ chiều. Những hiểu biết này phải do con người đưa vào — và đó là nơi PM tỏa sáng.
Hai cạm bẫy lớn nhất: Data Leakage và Train/Serving Skew
Data leakage (rò rỉ dữ liệu) xảy ra khi feature vô tình chứa thông tin về kết quả mà tại thời điểm dự đoán thực tế bạn chưa thể biết. Ví dụ kinh điển: dùng feature "khách hàng đã được nhân viên gọi điện đòi nợ" để dự đoán "khách hàng vỡ nợ" — nhưng việc gọi điện đòi nợ chỉ xảy ra sau khi đã biết khách có dấu hiệu vỡ nợ. Model sẽ đạt độ chính xác đẹp như mơ khi test, nhưng sụp đổ hoàn toàn khi lên production.
Train/serving skew (lệch giữa huấn luyện và phục vụ) xảy ra khi cách tính feature lúc huấn luyện khác với lúc chạy thật. Ví dụ lúc train, feature "số đơn 30 ngày" được tính trên dữ liệu sạch trong kho dữ liệu; nhưng lúc serving real-time, hệ thống tính nhanh và thiếu vài đơn. Model sẽ hoạt động kém hơn dự kiến mà không ai hiểu vì sao.
Tình huống thực tế
Tình huống 1: Sàn TMĐT Đông Nam Á và bài toán dự đoán giao hàng trễ
Một sàn thương mại điện tử lớn ở khu vực (giả định kiểu Shopee/Lazada) muốn xây model dự đoán đơn hàng nào có nguy cơ giao trễ để chủ động cảnh báo khách. Data Science team ban đầu chỉ đưa vào model các feature hiển nhiên: khoảng cách giao hàng, trọng lượng gói, phương thức vận chuyển. Độ chính xác chỉ khoảng 68%.
PM của sản phẩm — vốn từng làm vận hành logistics — gợi ý thêm vài feature từ domain knowledge: "tỷ lệ giao trễ của shipper trong 7 ngày qua", "đơn hàng được tạo trong khung giờ cao điểm 11-13h hay không", và quan trọng nhất "đơn hàng có rơi vào đợt sale lớn (như 9.9, 11.11) hay không". Sau khi thêm nhóm feature aggregation theo shipper và feature thời gian này, độ chính xác nhảy lên 81%.
Bài học: feature có giá trị nhất không phải feature có sẵn trong bảng, mà là feature được tạo ra từ hiểu biết về quy trình thực tế. PM ngồi ở giao điểm giữa nghiệp vụ và kỹ thuật chính là người dễ phát hiện ra chúng nhất.
Tình huống 2: Fintech Việt Nam và cú vấp data leakage
Một công ty fintech cho vay tiêu dùng tại TP.HCM xây model chấm điểm tín dụng. Trong giai đoạn thử nghiệm, model đạt AUC tới 0.94 — con số đẹp đến mức đáng ngờ. Khi triển khai thử trên tập khách hàng thật, tỷ lệ dự đoán đúng tụt thê thảm.
Điều tra ra nguyên nhân: trong tập feature có một biến tên là last_payment_status (trạng thái thanh toán gần nhất). Nghe có vẻ hợp lý, nhưng với những hồ sơ vay mới, giá trị này được điền sau khi khoản vay đã được duyệt và đã có vài kỳ trả nợ — tức là nó chứa thông tin tương lai mà tại thời điểm duyệt vay chưa hề tồn tại. Đây là một ca data leakage điển hình. Sau khi loại bỏ feature này và rà soát lại toàn bộ "mốc thời gian" (point-in-time) của từng feature, AUC trở về mức thực tế 0.78 — thấp hơn nhưng đáng tin.
Bài học: một con số đánh giá quá đẹp thường là dấu hiệu của leakage chứ không phải thiên tài. PM cần đặt câu hỏi đơn giản nhưng sắc bén với mỗi feature: "Tại đúng thời điểm hệ thống cần dự đoán, chúng ta có thực sự biết giá trị này chưa?"
Tình huống 3: Ứng dụng gọi xe và feature thời gian
Một ứng dụng gọi xe (giả định kiểu Grab/Be) cần dự đoán nhu cầu chuyến xe theo khu vực và theo giờ để điều phối tài xế. Team thử dùng riêng tọa độ và thời gian thô (dạng timestamp) thì model học rất kém.
Bước ngoặt đến khi họ làm feature engineering trên trục thời gian: tách ra "giờ trong ngày", "thứ trong tuần", "có phải giờ cao điểm không", "trời có mưa không" (kết hợp dữ liệu thời tiết), và "có sự kiện lớn gần đó không" (concert, trận bóng). Đặc biệt feature "đang mưa" tạo ra cú nhảy lớn về độ chính xác, vì mưa làm nhu cầu gọi xe tăng vọt — một quy luật mà con người biết rõ nhưng dữ liệu thô không tự nói ra.
Bài học: dữ liệu thời gian và dữ liệu bối cảnh (thời tiết, sự kiện) là mỏ vàng feature trong các bài toán dự báo nhu cầu. Việc làm giàu (enrich) dữ liệu bằng nguồn bên ngoài thường mang lại giá trị lớn — và đây là quyết định mang tính sản phẩm mà PM phải cân nhắc về chi phí và tính khả thi.
Hướng dẫn từng bước
Dưới đây là cách một Technical PM nên đồng hành cùng team trong quá trình feature engineering — không phải để làm thay, mà để định hướng và kiểm soát rủi ro.
Bước 1 — Bắt đầu từ bài toán nghiệp vụ, không phải từ dữ liệu. Trước khi nghĩ về feature, hãy làm rõ: chúng ta đang dự đoán cái gì, tại thời điểm nào, và quyết định gì sẽ được đưa ra dựa trên dự đoán đó. Mốc thời gian dự đoán (prediction time) là yếu tố tối quan trọng để tránh leakage.
Bước 2 — Liệt kê feature từ góc nhìn con người. Tổ chức một buổi brainstorm: "Nếu là một chuyên gia, bạn sẽ nhìn vào những dấu hiệu nào để đoán kết quả này?" Mỗi câu trả lời thường là một feature tiềm năng. Đây là lúc domain knowledge của PM phát huy.
Bước 3 — Phân loại và đánh giá tính khả thi. Với mỗi feature, hỏi: dữ liệu này có sẵn không? Tính được real-time hay chỉ batch? Chi phí tính toán ra sao? Một feature tuyệt vời nhưng cần 5 giây để tính sẽ vô dụng trong hệ thống yêu cầu phản hồi dưới 100ms.
Bước 4 — Kiểm tra leakage cho từng feature. Đặt câu hỏi "point-in-time": tại đúng thời điểm dự đoán, giá trị này đã tồn tại và đã biết chưa? Bất kỳ feature nào trả lời "chưa chắc" cần được rà soát kỹ.
Bước 5 — Để team đo tầm quan trọng (feature importance). Sau khi train, hầu hết model cho ra bảng xếp hạng feature nào đóng góp nhiều nhất. PM nên đọc bảng này: nếu một feature "không nên quan trọng" lại đứng đầu, đó thường là tín hiệu của leakage.
Bước 6 — Đảm bảo nhất quán giữa train và serving. Thống nhất với team rằng feature phải được tính bằng cùng một logic ở cả hai giai đoạn. Nhiều tổ chức dùng feature store để giải quyết bài toán này — một kho feature dùng chung cho cả huấn luyện và phục vụ.
Bước 7 — Lặp lại. Feature engineering là quá trình thử-sai. PM cần bảo vệ không gian để team thử nghiệm, đồng thời giữ kỷ luật đo lường để biết feature nào thực sự cải thiện kết quả.
Lỗi thường gặp & mẹo
Lỗi 1 — Bỏ qua data leakage vì kết quả "quá đẹp". Đây là lỗi tốn kém nhất. Mẹo: bất cứ khi nào độ chính xác cao bất thường, hãy nghi ngờ leakage trước khi ăn mừng.
Lỗi 2 — Tạo quá nhiều feature mà không kiểm soát. Hàng trăm feature không chọn lọc có thể gây overfitting (model học thuộc lòng dữ liệu huấn luyện nhưng kém trên dữ liệu mới) và làm hệ thống chậm, tốn kém. Mẹo: ưu tiên ít feature chất lượng cao hơn là nhiều feature nhiễu.
Lỗi 3 — Quên xử lý giá trị thiếu (missing value). Dữ liệu thực luôn có ô trống. Cách điền giá trị thiếu (bằng 0, bằng trung bình, hay tạo cờ "thiếu") ảnh hưởng trực tiếp đến chất lượng. Mẹo: hỏi team họ xử lý missing value thế nào — câu trả lời mơ hồ là dấu hiệu rủi ro.
Lỗi 4 — Để train/serving skew âm thầm phá hoại. Model tốt lúc test nhưng kém trên production thường do feature lúc serving tính khác lúc train. Mẹo: yêu cầu team mô tả rõ feature được tính ở đâu và bằng gì trong cả hai môi trường.
Lỗi 5 — Coi feature engineering là việc một lần. Hành vi người dùng và thị trường thay đổi (data drift), khiến feature từng tốt trở nên lỗi thời. Mẹo: lên lịch rà soát lại feature định kỳ như một phần của vòng đời sản phẩm.
Mẹo vàng cho PM: với mỗi feature quan trọng, hãy yêu cầu team viết một câu giải thích bằng ngôn ngữ con người vì sao nó nên có ý nghĩa. Nếu không ai giải thích được tại sao một feature lại quan trọng, đó thường là leakage hoặc trùng hợp ngẫu nhiên.
Bài tập thực hành
Bài tập 1 — Brainstorm feature. Chọn một bài toán: dự đoán khách hàng của một ứng dụng giao đồ ăn có đặt món trong 7 ngày tới hay không. Hãy liệt kê ít nhất 10 feature tiềm năng, phân loại numerical/categorical, và đánh dấu feature nào đến từ aggregation, feature nào từ thời gian.
Bài tập 2 — Săn leakage. Cho danh sách feature sau để dự đoán "khách hàng sẽ hủy gói thuê bao tháng này": (a) số ngày từ lần đăng nhập gần nhất, (b) khách đã nhận email "chúng tôi tiếc khi bạn rời đi", (c) số lần liên hệ hỗ trợ trong 30 ngày, (d) tổng tiền hoàn trả tháng này. Hãy chỉ ra feature nào có nguy cơ data leakage và giải thích lý do.
Bài tập 3 — Câu hỏi point-in-time. Viết ra 3 câu hỏi bạn sẽ đặt cho Data Scientist trong buổi review feature để phát hiện rủi ro leakage và train/serving skew. Mục tiêu là rèn phản xạ đặt đúng câu hỏi.
Bài tập 4 — Phân tích chi phí. Với bài tập 1, chọn ra feature mà bạn nghĩ có giá trị nhất nhưng đắt nhất để tính real-time, và viết một đoạn ngắn cân nhắc trade-off giữa giá trị nó mang lại và chi phí kỹ thuật.
Tóm tắt
Feature Engineering là nghệ thuật biến dữ liệu thô thành các tín hiệu mà model có thể học, và trong thực tế nó thường quyết định thành bại của một dự án ML nhiều hơn cả việc chọn thuật toán. "Garbage in, garbage out" — feature tốt mạnh hơn model phức tạp được nuôi bằng dữ liệu kém.
Là Technical PM, bạn không cần code feature, nhưng cần hiểu các loại feature (numerical, categorical), các nhóm kỹ thuật (transformation, aggregation, feature thời gian, interaction), và đặc biệt là hai cạm bẫy chí mạng: data leakage (feature chứa thông tin tương lai) và train/serving skew (feature tính khác nhau giữa huấn luyện và phục vụ).
Vũ khí lớn nhất của PM trong lĩnh vực này chính là domain knowledge — hiểu biết nghiệp vụ giúp gợi ra những feature mà thuật toán không thể tự tìm. Hãy luôn đặt câu hỏi point-in-time với mỗi feature, đọc bảng feature importance để soi leakage, và đảm bảo logic tính feature nhất quán giữa hai môi trường. Một gợi ý feature đúng lúc từ bạn có thể tạo ra bước nhảy về độ chính xác mà cả tháng tinh chỉnh model không làm nổi.