Mở đầu — vì sao bài này quan trọng
Có một sự thật mà nhiều Technical PM ngại thừa nhận: họ điều phối các dự án Machine Learning (ML) nhưng không thực sự hiểu ML đang làm gì bên dưới. Họ nghe đội ngũ data science nói về "model accuracy 92%", gật gù, rồi đem con số đó đi hứa với sếp — để rồi ba tháng sau model "92% chính xác" ấy lại đề xuất sản phẩm sai be bét trên production. Câu hỏi vang lên trong phòng họp: "PM, anh đã duyệt cái này mà?"
ML không phải là phép màu, và càng không phải là phần mềm thông thường. Phần mềm truyền thống, bạn viết logic rõ ràng: "nếu đơn hàng > 500 nghìn thì free ship". ML thì ngược lại — bạn đưa cho máy hàng nghìn ví dụ và để nó tự rút ra quy luật. Sự khác biệt nền tảng này thay đổi cách bạn lên kế hoạch, đo lường, và đặt kỳ vọng cho cả một dòng sản phẩm.
Bạn không cần biết viết một mạng nơ-ron. Nhưng bạn cần biết đủ để hỏi đúng câu hỏi: "Đây là bài toán phân loại hay hồi quy?", "Chúng ta lấy label từ đâu?", "Khi nào model này sẽ bắt đầu sai?". Bài học này trang bị cho bạn bộ khung tư duy ML cơ bản nhất — ba paradigm học máy, vòng đời dữ liệu, và cách diễn giải kết quả — để bạn ngồi vào bàn với data scientist như một đối tác ngang hàng, chứ không phải người chỉ biết gật đầu.
Khái niệm cốt lõi
Ba paradigm học máy chính
Trước khi đi sâu vào bất kỳ dự án ML nào, hãy phân loại nó vào một trong ba nhóm. Đây là điều đầu tiên một PM nên làm.
Supervised Learning (Học có giám sát). Đây là paradigm phổ biến nhất trong sản phẩm thương mại — chiếm khoảng 80% các use case bạn sẽ gặp. Model học từ các cặp (input, output) đã được gán nhãn sẵn. Ví dụ kinh điển: phát hiện email spam. Bạn đưa cho model hàng triệu email kèm nhãn "spam" hoặc "không spam", và nó học cách nhận diện email mới. Điều kiện tiên quyết của supervised learning là bạn phải có label (nhãn) — và label thường rất đắt để có được.
Supervised learning chia tiếp thành hai loại con mà PM cần phân biệt:
- Classification (Phân loại): đầu ra là một nhãn rời rạc. "Email này có phải spam không?", "Khách này sẽ rời bỏ hay ở lại?", "Ảnh này là áo, quần, hay giày?".
- Regression (Hồi quy): đầu ra là một con số liên tục. "Căn nhà này giá bao nhiêu?", "Đơn hàng này giao trong bao nhiêu phút?", "Doanh thu tháng sau dự kiến là bao nhiêu?".
Unsupervised Learning (Học không giám sát). Không có label. Model tự tìm cấu trúc ẩn trong dữ liệu. Use case thường gặp nhất là clustering — gom nhóm. Ví dụ: một sàn TMĐT muốn phân khúc khách hàng nhưng không biết trước có bao nhiêu nhóm. Model tự gom 5 triệu khách thành 6 cụm dựa trên hành vi mua sắm. PM nhìn vào 6 cụm đó và đặt tên: "săn sale", "mua hàng cao cấp", "khách vãng lai"... Điểm cần lưu ý: vì không có "đáp án đúng", việc đánh giá unsupervised learning mang tính diễn giải nhiều hơn, và thường cần con người xác nhận kết quả có ý nghĩa kinh doanh hay không.
Reinforcement Learning (Học tăng cường). Model học bằng cách thử-sai và nhận phần thưởng. Nó hành động trong một môi trường, nhận "reward" hoặc "penalty", và dần tối ưu chiến lược. Đây là paradigm đứng sau AlphaGo, xe tự lái, và các hệ thống tối ưu giá động (dynamic pricing) của Grab hay Be. RL mạnh nhưng cực kỳ tốn kém và khó kiểm soát — với phần lớn sản phẩm, bạn sẽ không bắt đầu từ đây. PM nên biết nó tồn tại, nhưng cảnh giác khi một đội đề xuất dùng RL cho bài toán mà supervised learning đã giải tốt.
Dữ liệu là vua — Features và Labels
Trong ML, chất lượng model phụ thuộc vào dữ liệu nhiều hơn vào thuật toán. Có một câu nói trong giới: "Garbage in, garbage out" — rác vào thì rác ra.
- Feature (Đặc trưng): là các đầu vào model dùng để dự đoán. Với bài toán dự đoán khách rời bỏ (churn), feature có thể là: số ngày kể từ lần mua cuối, tổng chi tiêu, số lần khiếu nại.
- Label (Nhãn): là đáp án đúng mà bạn muốn model học để dự đoán.
Training, Validation, Test — và overfitting
Dữ liệu được chia ba phần: training set (để model học), validation set (để tinh chỉnh), và test set (để đánh giá khách quan trên dữ liệu chưa từng thấy). Đây là khái niệm sống còn vì nó liên quan trực tiếp đến cái bẫy lớn nhất: overfitting.
Overfitting là khi model "học thuộc lòng" dữ liệu training thay vì học quy luật tổng quát. Nó đạt 99% trên training nhưng chỉ 70% trên dữ liệu thực. Hình dung như một học sinh học tủ: làm đúng hết đề mẫu nhưng gặp đề thật là tịt. Khi data scientist khoe accuracy cao chót vót, câu hỏi đầu tiên của PM phải là: "Con số đó đo trên test set hay training set?".
Tình huống thực tế
Tình huống 1: Tiki và bài toán phân loại sản phẩm
Một sàn TMĐT lớn tại Việt Nam (gọi là sàn X cho dễ hình dung) gặp vấn đề: hàng trăm nghìn người bán tự đăng sản phẩm và gán sai danh mục. Một chiếc "ốp lưng iPhone" bị đẩy vào danh mục "điện thoại", làm hỏng trải nghiệm tìm kiếm và lọc giá.
PM của đội Catalog đề xuất xây model classification tự động gán danh mục từ tên và mô tả sản phẩm. Đây là supervised learning: input là text mô tả, label là danh mục đúng. Vấn đề lộ ra ngay: lấy label ở đâu? Đội dùng dữ liệu lịch sử từ các sản phẩm đã được duyệt thủ công — nhưng chính dữ liệu đó cũng chứa lỗi gán sai. PM phải quyết định: chi 200 triệu thuê đội gán nhãn lại 50 nghìn mẫu sạch để làm "vàng chuẩn" cho test set.
Kết quả: model đạt accuracy 89% trên test set. Nhưng PM không dừng ở đó. Anh ta hỏi: "89% sai ở đâu?". Phân tích cho thấy model sai nhiều nhất ở các danh mục có ít dữ liệu (như đồ thủ công). Quyết định sản phẩm: chỉ tự động gán cho 200 danh mục lớn (độ chính xác >95%), phần còn lại vẫn để con người duyệt.
Bài học: Một con số accuracy tổng thể che giấu sự thật. PM giỏi luôn hỏi "sai ở đâu, sai với ai" và biến hiểu biết đó thành quyết định triển khai từng phần thay vì all-or-nothing.
Tình huống 2: Grab và clustering để phân khúc tài xế
Grab muốn thiết kế các gói thưởng khác nhau cho tài xế, nhưng không biết nên chia tài xế thành bao nhiêu nhóm. Đây là bài toán unsupervised learning — clustering. Không có label "đây là tài xế loại A", mà để model tự gom.
Đội data science gom 80 nghìn tài xế tại TP.HCM thành 5 cụm dựa trên: số chuyến/ngày, khung giờ hoạt động, tỷ lệ hủy chuyến, khu vực. PM nhìn vào 5 cụm và làm việc với business để đặt tên: "tài xế toàn thời gian giờ cao điểm", "tài xế bán thời gian buổi tối", "tài xế thỉnh thoảng"... Mỗi cụm nhận một gói thưởng riêng.
Điểm mấu chốt: vì không có đáp án đúng, PM không thể hỏi "accuracy bao nhiêu". Thay vào đó, câu hỏi đúng là: "Các cụm này có khác biệt rõ rệt và có ý nghĩa kinh doanh không?". Một cụm mà 60% tài xế nằm chồng lấn với cụm khác thì vô dụng cho việc thiết kế gói thưởng.
Bài học: Với unsupervised learning, thước đo thành công không phải là độ chính xác kỹ thuật, mà là tính hành động được (actionability) của kết quả. PM là người dịch các cụm vô danh thành quyết định kinh doanh.
Tình huống 3: Fintech và cái bẫy overfitting trong chấm điểm tín dụng
Một startup fintech tại Đông Nam Á xây model dự đoán khả năng vỡ nợ của người vay (classification). Trong demo nội bộ, model đạt accuracy 96% — cả phòng họp hân hoan. PM định lên kế hoạch ra mắt.
May mắn là PM này đã học ML basics. Anh ta hỏi: "96% đo trên test set hay training set?". Hóa ra đội đã đo trên chính dữ liệu training. Khi chạy lại trên test set độc lập, accuracy rớt xuống 78%. Tệ hơn: dữ liệu có class imbalance — chỉ 5% người vay thực sự vỡ nợ. Một model "ngu" luôn dự đoán "không vỡ nợ" cũng đạt 95% accuracy mà chẳng giúp gì!
PM yêu cầu đổi thước đo từ accuracy sang recall (tỷ lệ bắt được người vỡ nợ thật) và precision. Hóa ra model chỉ bắt được 40% trường hợp vỡ nợ — không thể chấp nhận cho sản phẩm tài chính. Dự án bị hoãn để thu thập thêm dữ liệu.
Bài học: Accuracy là con số gây hiểu lầm nhất trong ML, đặc biệt với dữ liệu mất cân bằng. PM cần biết chọn metric phù hợp với rủi ro kinh doanh. (Bài 34 sẽ đào sâu về model evaluation — ở đây chỉ cần nhớ: đừng tin mù quáng vào accuracy.)
Hướng dẫn từng bước
Khi một dự án ML đến bàn của bạn, hãy chạy qua quy trình tư duy sau:
- Phân loại bài toán. Đây là supervised, unsupervised hay reinforcement? Nếu supervised, là classification hay regression? Trả lời được câu này, bạn đã định hình được 80% kỳ vọng về dữ liệu và cách đo lường.
- Truy nguồn label và dữ liệu. Hỏi rõ: "Chúng ta lấy label ở đâu? Có đủ số lượng không? Chất lượng thế nào? Chi phí và thời gian để có thêm?". Đưa chi phí gán nhãn vào roadmap như một hạng mục thật, không phải chú thích nhỏ.
- Xác định metric thành công gắn với kinh doanh. Đừng để đội tự chọn metric kỹ thuật. Hỏi ngược: "Sai sót kiểu nào gây thiệt hại lớn hơn — bắt nhầm hay bỏ sót?". Câu trả lời quyết định bạn ưu tiên precision hay recall.
- Định nghĩa đường cơ sở (baseline). Trước khi xây model phức tạp, hỏi: "Nếu dùng quy tắc đơn giản nhất thì kết quả ra sao?". Nếu một quy tắc if-else đạt 85% và model ML đạt 87%, có đáng đầu tư cả quý không?
- Yêu cầu đánh giá trên test set độc lập. Luôn xác nhận con số hiệu suất đến từ dữ liệu model chưa từng thấy. Hỏi về overfitting một cách chủ động.
- Lên kế hoạch triển khai từng phần. ML hiếm khi đúng 100%. Thiết kế cơ chế con người-trong-vòng-lặp (human-in-the-loop) cho các trường hợp model không chắc chắn.
Lỗi thường gặp & mẹo
Lỗi 1: Coi accuracy là thước đo vạn năng. Như tình huống fintech, accuracy vô nghĩa khi dữ liệu mất cân bằng. Mẹo: luôn hỏi tỷ lệ phân bố các nhãn trước khi tin vào accuracy.
Lỗi 2: Bỏ qua chi phí dữ liệu. Nhiều PM mơ về thuật toán hào nhoáng nhưng quên rằng 70% công sức dự án ML là thu thập và làm sạch dữ liệu. Mẹo: hỏi "dữ liệu sẵn sàng chưa" trước khi hỏi "model nào".
Lỗi 3: Hứa hẹn ML đúng tuyệt đối. ML mang bản chất xác suất, không phải logic cứng. Đừng bao giờ hứa với sếp rằng "hệ thống sẽ không bao giờ sai". Mẹo: luôn truyền đạt hiệu suất kèm khoảng tin cậy và kế hoạch xử lý lỗi.
Lỗi 4: Nhầm tương quan với nhân quả. Model thấy "người mua ô vào ngày mưa" không có nghĩa ô gây ra mưa. ML tìm tương quan, không giải thích nhân quả. Mẹo: cảnh giác khi feature có vẻ "quá tốt" — có thể đó là data leakage (rò rỉ dữ liệu tương lai vào training).
Lỗi 5: Dùng búa tạ đập ruồi. Không phải bài toán nào cũng cần ML. Nếu một quy tắc kinh doanh đơn giản giải quyết được 90% trường hợp, ML có thể là sự phức tạp không cần thiết. Mẹo: ML xứng đáng khi quy luật quá phức tạp để viết tay và bạn có nhiều dữ liệu.
Bài tập thực hành
Bài 1 — Phân loại paradigm. Với mỗi tình huống dưới đây, xác định paradigm (supervised/unsupervised/reinforcement) và nếu supervised thì là classification hay regression:
- Dự đoán thời gian giao hàng của một đơn (phút)
- Gom nhóm bài viết blog theo chủ đề mà không biết trước các chủ đề
- Phát hiện giao dịch gian lận thẻ tín dụng
- Tối ưu giá cước theo thời gian thực dựa trên cung-cầu
Bài 3 — Thiết kế nguồn label. Bạn được giao xây model gợi ý nội dung cho một app học tiếng Anh. Hãy phác thảo: bạn sẽ lấy label "nội dung phù hợp" từ đâu, chi phí ước tính, và rủi ro chất lượng label.
Bài 4 — Phản biện ML. Tìm một tính năng trong sản phẩm bạn đang làm mà đội kỹ thuật muốn dùng ML. Lập luận xem một giải pháp dựa trên quy tắc (rule-based) có giải quyết được phần lớn vấn đề với chi phí thấp hơn không.
Tóm tắt
Là Technical PM, bạn không cần huấn luyện model, nhưng bạn cần một bộ khung tư duy ML vững chắc. Hãy nhớ những điều cốt lõi:
- Ba paradigm: Supervised (có label, phổ biến nhất, chia thành classification và regression), Unsupervised (không label, dùng để gom nhóm và khám phá), và Reinforcement (học qua thử-sai, mạnh nhưng tốn kém).
- Dữ liệu quan trọng hơn thuật toán. Luôn truy nguồn label: nó đến từ đâu, tốn bao nhiêu, chất lượng ra sao.
- Đừng tin mù quáng vào accuracy. Hỏi về test set, về phân bố nhãn, về loại lỗi nào gây hại nhất cho kinh doanh.
- Cảnh giác với overfitting và data leakage. Hiệu suất cao bất thường thường là dấu hiệu của vấn đề, không phải thành công.
- ML là xác suất, không phải logic cứng. Hãy thiết kế cho cả trường hợp model sai, và luôn cân nhắc liệu một giải pháp đơn giản hơn có đủ tốt không.