TỪ BÀI TOÁN KINH DOANH ĐẾN GIẢI PHÁP DỮ LIỆU

Kiến tạo giá trị từ dữ liệu thông qua thấu hiểu nghiệp vụ

Trong thế giới khoa học dữ liệu, chúng ta thường bị cuốn hút bởi sự phức tạp của các thuật toán, sự hào nhoáng của những mô hình "state-of-the-art" và niềm vui khi tối ưu được từng phần trăm độ chính xác. Chúng ta vội vã thu thập dữ liệu, tiền xử lý, xây dựng mô hình và triển khai. Nhưng rồi, một sự thật đáng buồn xảy ra: một mô hình với độ chính xác 95% nhưng lại không mang lại bất kỳ giá trị nào cho doanh nghiệp, hoặc tệ hơn, không ai sử dụng nó.

Đây là một kịch bản quen thuộc và nó xuất phát từ việc bỏ qua một giai đoạn nền tảng, âm thầm nhưng cực kỳ quan trọng: Thấu hiểu nghiệp vụ (Business Understanding). Đây không phải là giai đoạn về code hay thuật toán, mà là giai đoạn của sự thấu hiểu sâu sắc bài toán kinh doanh. Trước khi bạn viết dòng code đầu tiên, bạn phải trả lời được câu hỏi: "Chúng ta đang thực sự cố gắng giải quyết vấn đề gì?". Việc không đầu tư thời gian vào giai đoạn này sẽ dẫn đến những hậu quả tai hại: lãng phí tài nguyên, sản phẩm không được chấp nhận, và mất niềm tin của các bên liên quan vào tiềm năng của khoa học dữ liệu.

Những câu hỏi cốt lõi để thấu hiểu nghiệp vụ

Giai đoạn này đòi hỏi bạn phải trở thành một nhà tư vấn, một người biết lắng nghe và đặt những câu hỏi đúng để đào sâu vào cốt lõi của bài toán. Bốn câu hỏi xương sống sau đây sẽ là kim chỉ nam cho bạn.

1. Vấn đề thực sự là gì và tại sao nó quan trọng?

Đây là câu hỏi nền tảng nhất. Đừng bao giờ chấp nhận yêu cầu ban đầu một cách mù quáng. Hãy đào sâu hơn để tìm ra "nỗi đau" thực sự của doanh nghiệp và tại sao việc giải quyết nó lại cấp thiết.

• Ví dụ 1: Dự đoán khách hàng rời bỏ
  • Yêu cầu bề mặt: "Chúng tôi cần một mô hình dự đoán khách hàng rời bỏ (churn prediction)."
  • Câu hỏi đào sâu: "Tại sao việc dự đoán churn lại quan trọng vào lúc này? Việc khách hàng rời bỏ đang gây ra thiệt hại cụ thể như thế nào về doanh thu? Mục tiêu cuối cùng là chỉ để biết ai sẽ rời đi, hay là để giữ chân họ?"
  • Vấn đề thực sự: Công ty đang mất 15% doanh thu hàng quý vì các khách hàng giá trị cao rời bỏ. Mục tiêu không phải là "dự đoán", mà là "giảm tỷ lệ rời bỏ ở nhóm khách hàng VIP xuống 5% bằng cách xác định sớm và đưa ra chương trình chăm sóc phù hợp."
• Ví dụ 2: Khuyến nghị sản phẩm
  • Yêu cầu bề mặt: "Hãy xây dựng một hệ thống gợi ý sản phẩm để tăng doanh thu."
  • Câu hỏi đào sâu: "Chúng ta muốn tăng doanh thu bằng cách nào? Bằng cách bán thêm (up-sell) sản phẩm đắt tiền hơn, hay bán chéo (cross-sell) các sản phẩm liên quan? Gợi ý sẽ xuất hiện ở đâu trên trang web?"
  • Vấn đề thực sự: Khách hàng thường chỉ mua một sản phẩm và rời đi. Mục tiêu là tăng giá trị đơn hàng trung bình (AOV) lên 10% bằng cách gợi ý các sản phẩm thường được mua kèm ngay tại trang giỏ hàng.

2. Ai sẽ là người dùng cuối của giải pháp này?

Một giải pháp kỹ thuật dù hoàn hảo đến đâu cũng sẽ thất bại nếu người dùng không thể hoặc không muốn sử dụng nó.

• Ví dụ 1: Dự đoán khách hàng rời bỏ
  • Yêu cầu bề mặt: "Chỉ cần xuất ra một file Excel danh sách khách hàng có nguy cơ churn."
  • Câu hỏi đào sâu: "Ai sẽ đọc file Excel này? Đội ngũ Marketing hay Chăm sóc khách hàng? Quy trình làm việc hiện tại của họ như thế nào? Họ sẽ làm gì với danh sách đó?"
  • Vấn đề thực sự: Đội ngũ Chăm sóc khách hàng cần một danh sách được tích hợp thẳng vào hệ thống CRM của họ. Quan trọng hơn, họ cần biết lý do tại sao khách hàng bị đánh giá là có nguy cơ (ví dụ: "giảm 50% tần suất sử dụng", "gọi hỗ trợ 3 lần/tuần") để có thể cá nhân hóa cuộc gọi giữ chân.
• Ví dụ 2: Khuyến nghị sản phẩm
  • Yêu cầu bề mặt: "Hiển thị các sản phẩm gợi ý."
  • Câu hỏi đào sâu: "Ai là người xem các gợi ý này? Họ đang ở bước nào trong hành trình mua sắm? Họ có đang vội không?"
  • Vấn đề thực sự: Người mua hàng là người dùng cuối. Họ đang ở trang giỏ hàng, chuẩn bị thanh toán. Gợi ý phải nhanh, cực kỳ liên quan và không gây xao lãng, nếu không họ sẽ từ bỏ giỏ hàng.

3. Giải pháp sẽ được tích hợp và sử dụng như thế nào?

Câu hỏi này quyết định đến kiến trúc kỹ thuật và cách vận hành của sản phẩm cuối cùng.

• Ví dụ 1: Dự đoán khách hàng rời bỏ
  • Yêu cầu bề mặt: "Chúng tôi cần một mô hình."
  • Câu hỏi đào sâu: "Kết quả dự đoán cần được cập nhật bao lâu một lần? Hàng ngày, hàng tuần? Nó sẽ được gửi đến người dùng qua đâu?"
  • Vấn đề thực sự: Cần một hệ thống xử lý theo lô (batch processing) chạy vào mỗi đầu tháng, tự động quét toàn bộ khách hàng, và đẩy danh sách những người có nguy cơ cao nhất vào hệ thống CRM qua một API.
• Ví dụ 2: Khuyến nghị sản phẩm
  • Yêu cầu bề mặt: "Một hệ thống gợi ý."
  • Câu hỏi đào sâu: "Dự đoán cần được thực hiện ngay lập tức khi người dùng thêm một món đồ vào giỏ phải không? Độ trễ cho phép là bao nhiêu?"
  • Vấn đề thực sự: Cần một API thời gian thực (real-time API) có độ trễ dưới 100ms. API này nhận đầu vào là danh sách các sản phẩm trong giỏ hàng và trả về một danh sách các sản phẩm gợi ý đã được xếp hạng.

4. Chúng ta đo lường thành công bằng cách nào?

Đây là lúc chuyển từ các chỉ số mô hình (model metrics) sang các chỉ số kinh doanh (business metrics).

• Ví dụ 1: Dự đoán khách hàng rời bỏ
  • Yêu cầu bề mặt: "Mô hình cần có độ chính xác trên 90%."
  • Câu hỏi đào sâu: "Nếu mô hình đạt độ chính xác 90% nhưng tỷ lệ churn không giảm thì sao? Chi phí cho một lần dự đoán sai (gắn nhãn nhầm một khách hàng trung thành là sắp churn) là gì?"
  • Vấn đề thực sự: Thành công được đo lường bằng A/B testing: Tỷ lệ rời bỏ thực tế của nhóm khách hàng được can thiệp (dựa trên mô hình) phải thấp hơn ít nhất 15% so với nhóm đối chứng (không can thiệp).
• Ví dụ 2: Khuyến nghị sản phẩm
  • Yêu cầu bề mặt: "Tỷ lệ click vào sản phẩm gợi ý phải cao."
  • Câu hỏi đào sâu: "Nếu người dùng click nhiều nhưng không mua thì sao? Mục tiêu cuối cùng là tăng doanh thu phải không?"
  • Vấn đề thực sự: Thành công được đo lường bằng A/B testing: Giá trị đơn hàng trung bình (AOV) của nhóm khách hàng thấy gợi ý phải cao hơn ít nhất 10% so với nhóm không thấy.

Công cụ để hệ thống hóa: Machine Learning Canvas

Việc đặt câu hỏi là cần thiết, nhưng để hệ thống hóa toàn bộ quá trình tư duy này, chúng ta cần một công cụ cấu trúc. Lấy cảm hứng từ Business Model Canvas nổi tiếng trong giới khởi nghiệp, Louis Dorard đã tạo ra Machine Learning Canvas (MLC). Đây là một bản thiết kế trực quan trên một trang giấy, giúp tất cả các bên liên quan-từ kinh doanh, sản phẩm đến kỹ thuật-cùng nhìn về một hướng, sử dụng một ngôn ngữ chung và đảm bảo không một khía cạnh quan trọng nào bị bỏ sót.

Khối trung tâm: 1. Value Proposition (Tuyên bố giá trị)

Đây là trái tim của canvas, nơi kết tinh câu trả lời cho các câu hỏi cốt lõi đã nêu ở trên. Nó buộc bạn phải xác định rõ vấn đề, tầm quan trọng và người dùng cuối. Một công thức hiệu quả để viết tuyên bố này là của Geoffrey Moore:

Dành cho (khách hàng mục tiêu) những người (có nhu cầu hoặc cơ hội), (sản phẩm/dịch vụ của chúng tôi) là một (loại sản phẩm) giúp (mang lại lợi ích).

Phần LEARN - Nền tảng dữ liệu và huấn luyện

Phần này tập trung vào mọi thứ liên quan đến dữ liệu và cách mô hình được "học".

2. Data Sources (Nguồn dữ liệu)

• Mục đích: Liệt kê tất cả các nguồn dữ liệu thô có thể khai thác.
• Chi tiết: Đây có thể là cơ sở dữ liệu nội bộ (OLTP, DWH), API từ bên thứ ba, các tệp tĩnh (CSV, Excel), dữ liệu từ việc cào web (web scraping), hoặc thậm chí là đầu ra từ một hệ thống ML khác. Việc xác định rõ nguồn giúp ước tính độ phức tạp trong việc thu thập và tích hợp.

3. Collecting Data (Thu thập dữ liệu mới)

• Mục đích: Lên kế hoạch làm thế nào để hệ thống tiếp tục học hỏi và không bị lỗi thời (model decay).
• Chi tiết: Làm thế nào chúng ta thu thập được dữ liệu mới, đặc biệt là các "nhãn" (label) cho đầu ra? Có cần con người gán nhãn thủ công (human-in-the-loop) không? Chi phí cho việc gán nhãn là bao nhiêu?

4. Features (Đặc trưng)

• Mục đích: Mô tả cách dữ liệu thô được chuyển đổi thành các tín hiệu mà mô hình có thể hiểu được.
• Chi tiết: Đây là bước "feature engineering". Từ dữ liệu thô (ví dụ: ngày tháng giao dịch), chúng ta trích xuất các đặc trưng có ý nghĩa như thế nào (ví dụ: khoảng cách từ lần mua cuối, tần suất mua)? Việc tham vấn các chuyên gia trong lĩnh vực (domain experts) ở bước này là cực kỳ giá trị.

5. Building Models (Xây dựng mô hình)

• Mục đích: Xác định chu kỳ và các ràng buộc của việc huấn luyện lại mô hình.
• Chi tiết: Tần suất huấn luyện lại mô hình là bao lâu (hàng giờ, hàng ngày, hàng tuần)? Quá trình này mất bao lâu? Các chi phí ẩn cho việc huấn luyện lại là gì (ví dụ: chi phí tài nguyên đám mây)?

Phần PREDICT - Logic cốt lõi của hệ thống

Phần này mô tả cách hệ thống sử dụng mô hình để đưa ra kết quả và tạo ra tác động.

6. Prediction Task (Tác vụ ML)

• Mục đích: Định nghĩa chính xác bài toán kỹ thuật cần giải quyết.
• Chi tiết: Mặc dù có tên là "Prediction Task", khối này bao hàm tất cả các tác vụ học máy nói chung: Phân loại, Hồi quy, Phân cụm, Khuyến nghị, v.v. Cần xác định rõ: Đầu vào là gì, đầu ra là gì, và độ phức tạp của mô hình có thể chấp nhận được.

7. Decisions (Quyết định)

• Mục đích: Đây là cầu nối quan trọng nhất giữa kết quả và giá trị. Nó trả lời câu hỏi: "Vậy thì sao?".
• Chi tiết: Làm thế nào để biến kết quả của mô hình thành một hành động hoặc quyết định kinh doanh? Ví dụ: Nếu một email được phân loại là "spam", hệ thống sẽ tự động chuyển nó vào thư mục spam.

8. Making Predictions (Thực hiện tác vụ ML)

• Mục đích: Xác định khi nào và như thế nào hệ thống sẽ đưa ra kết quả cho dữ liệu mới.
• Chi tiết: Kết quả được tạo ra khi nào? (ví dụ: mỗi khi người dùng mở ứng dụng, theo một lịch trình cố định). Kết quả được tạo ra cho từng điểm dữ liệu một (on-the-fly/real-time) hay cho cả một lô (batch)?

Phần EVALUATE - Đo lường và kiểm chứng

Phần này đảm bảo rằng chúng ta có thể đo lường được sự thành công của dự án, cả trước và sau khi triển khai.

9. Offline Evaluation (Đánh giá ngoại tuyến)

• Mục đích: Thiết lập các tiêu chí để đánh giá mô hình trong môi trường thử nghiệm, trước khi nó tác động đến người dùng thật.
• Chi tiết: Chúng ta sẽ sử dụng các chỉ số kỹ thuật nào (Precision, Recall, F1-score...)? Quan trọng hơn, chúng ta có thể định nghĩa các chỉ số mang tính nghiệp vụ không? (Ví dụ: mô phỏng doanh thu tạo ra nếu áp dụng mô hình trên tập dữ liệu kiểm thử).

10. Live Evaluation & Monitoring (Đánh giá và giám sát trực tiếp)

• Mục đích: Theo dõi hiệu suất của hệ thống trong thế giới thực và đo lường giá trị kinh doanh mà nó tạo ra.
• Chi tiết: Chúng ta sẽ theo dõi hiệu suất hệ thống như thế nào (ví dụ: A/B Testing)? Chúng ta đo lường sự thành công về mặt kinh doanh ra sao (ví dụ: tỷ lệ khách hàng rời bỏ thực tế có giảm không?)?

Các ứng dụng thực tế

Bài toán phân loại (Classification) - Dự đoán khách hàng rời bỏ

Tình huống: Ban lãnh đạo một công ty viễn thông yêu cầu: "Chúng ta đang mất quá nhiều khách hàng. Hãy xây dựng một mô hình dự đoán churn để giải quyết vấn đề này."

Áp dụng MLC:

• Value Proposition: "Dành cho đội ngũ Chăm sóc khách hàng, những người cần xác định các thuê bao giá trị cao có nguy cơ rời mạng, hệ thống cảnh báo sớm của chúng tôi là một công cụ phân tích giúp họ chủ động tiếp cận và đưa ra các ưu đãi phù hợp, nhằm giảm tỷ lệ rời bỏ."
• Data Sources: CRM (thông tin khách hàng), CSDL thanh toán (lịch sử cước), hệ thống Customer Support (số lần gọi hỗ trợ), CSDL sử dụng dịch vụ (lưu lượng data, phút gọi).
• Collecting Data: Hàng tháng, hệ thống tự động gán nhãn "churn" cho các khách hàng không gia hạn hợp đồng/thanh toán cước. Dữ liệu này được dùng để huấn luyện lại mô hình.
• Features: Thời gian sử dụng dịch vụ, giá trị hóa đơn trung bình 3 tháng gần nhất, số ngày quá hạn thanh toán, số lần gọi hỗ trợ, % thay đổi lưu lượng data so với tháng trước.
• Building Models: Huấn luyện lại mô hình vào ngày 1 hàng tháng với dữ liệu của tháng trước đó. Quá trình này được thực hiện trong đêm.
• Prediction Task: Phân loại nhị phân. Đầu vào: vector đặc trưng của khách hàng. Đầu ra: nhãn "Churn" hoặc "No-Churn" và một điểm số xác suất.
• Decisions: Khi một khách hàng có điểm churn > 0.8, một tác vụ (task) tự động được tạo ra trong hệ thống CRM với mức độ ưu tiên cao, gán cho nhân viên chăm sóc.
• Making Predictions: Xử lý theo lô (batch) vào ngày 1 hàng tháng, quét toàn bộ danh sách khách hàng hiện tại.
• Offline Evaluation: Sử dụng Precision và Recall trên tập kiểm thử. Đặc biệt chú trọng Recall của lớp "Churn" để không bỏ sót khách hàng có nguy cơ cao. Mô phỏng chi phí giữ chân so với doanh thu có được.
• Live Evaluation & Monitoring: Chạy A/B testing. So sánh tỷ lệ rời bỏ thực tế của nhóm được can thiệp với nhóm đối chứng. Mục tiêu: giảm 15% tỷ lệ rời bỏ trong nhóm được can thiệp.

Kết quả: Chuyển từ việc "dự đoán" sang một quy trình "hành động giữ chân" tự động, có thể đo lường và tối ưu hóa liên tục.

Bài toán hồi quy (Regression) - Dự đoán giá nhà

Tình huống: Một công ty bất động sản muốn có một công cụ "để dự đoán giá nhà cho các nhân viên kinh doanh."

Áp dụng MLC:

• Value Proposition: "Dành cho nhân viên kinh doanh bất động sản, những người tốn nhiều thời gian để đưa ra giá chào bán, công cụ ước tính giá thông minh là một tính năng tích hợp trong phần mềm nội bộ giúp họ có ngay một mức giá tham khảo đáng tin cậy, tăng tốc độ báo giá."
• Data Sources: Dữ liệu nội bộ về các giao dịch đã thành công, dữ liệu từ các trang rao vặt bất động sản (cào web), dữ liệu mở (open data) về quy hoạch, trường học, bệnh viện.
• Collecting Data: Hàng tuần, hệ thống tự động cào dữ liệu các bất động sản mới được niêm yết và các bất động sản đã bán để cập nhật bộ dữ liệu.
• Features: Diện tích (m²), số phòng ngủ, số phòng tắm, vị trí (quận/huyện), khoảng cách đến ga tàu điện gần nhất, tuổi đời của tòa nhà, có chỗ đậu xe hơi không.
• Building Models: Huấn luyện lại mô hình vào Chủ nhật hàng tuần để chuẩn bị cho tuần làm việc mới.
• Prediction Task: Hồi quy. Đầu vào: vector đặc trưng của bất động sản. Đầu ra: một con số (giá trị ước tính).
• Decisions: Mô hình cung cấp một "khoảng giá đề xuất" (ví dụ: 4.8 tỷ - 5.2 tỷ). Nhân viên kinh doanh (human-in-the-loop) sẽ sử dụng mức giá này làm cơ sở để đưa ra giá chào bán chính thức.
• Making Predictions: Thực hiện theo yêu cầu (on-demand). Khi nhân viên nhập thông tin một bất động sản mới, hệ thống gọi API của mô hình và trả về kết quả ngay lập tức.
• Offline Evaluation: Sử dụng MAPE (Sai số phần trăm tuyệt đối trung bình). Mục tiêu: MAPE < 10%.
• Live Evaluation & Monitoring: Theo dõi thời gian trung bình từ khi nhận yêu cầu đến khi gửi báo giá cho khách (kỳ vọng giảm 30%) và tỷ lệ chênh lệch giữa giá báo và giá bán thực tế.

Kết quả: Tạo ra một công cụ "trợ lý thông minh", không thay thế con người mà giúp nhân viên kinh doanh làm việc hiệu quả hơn và đưa ra quyết định dựa trên dữ liệu tốt hơn.

Bài toán phân cụm (Clustering) - Phân khúc khách hàng

Tình huống: Đội ngũ Marketing của một trang thương mại điện tử đề xuất: "Hãy phân khúc khách hàng để chúng tôi có thể làm marketing tốt hơn."

Áp dụng MLC:

• Value Proposition: "Dành cho đội ngũ Marketing, những người đang gửi cùng một thông điệp quảng cáo cho tất cả khách hàng, hệ thống phân khúc khách hàng tự động là một nguồn dữ liệu giúp họ thiết kế và gửi các chiến dịch email/thông báo đẩy được cá nhân hóa, nhằm tăng tỷ lệ tương tác và chuyển đổi."
• Data Sources: CSDL đơn hàng, CSDL khách hàng, dữ liệu hành vi trên web (Google Analytics).
• Collecting Data: Dữ liệu hành vi và giao dịch được thu thập liên tục.
• Features: Sử dụng mô hình RFM kinh điển: Recency (Lần cuối mua hàng), Frequency (Tần suất mua hàng), Monetary (Tổng giá trị đã chi tiêu).
• Building Models: Chạy lại thuật toán phân cụm (ví dụ: K-Means) vào đầu mỗi tuần.
• Prediction/ML Task: Phân cụm. Đầu vào: vector RFM của mỗi khách hàng. Đầu ra: Gán mỗi khách hàng vào một cụm (ví dụ: "Khách hàng VIP", "Khách hàng trung thành", "Khách hàng ngủ đông").
• Decisions: Dựa trên phân khúc, đội ngũ Marketing sẽ tạo các chiến dịch khác nhau: gửi mã giảm giá cho "Khách hàng VIP", gửi email "Chúng tôi nhớ bạn!" cho "Khách hàng ngủ đông".
• Making Predictions: Xử lý theo lô (batch) hàng tuần, cập nhật nhãn phân khúc cho toàn bộ khách hàng.
• Offline Evaluation: Đánh giá chất lượng cụm bằng các chỉ số như Silhouette score. Chuyên gia marketing xem xét đặc điểm của từng cụm để đảm bảo chúng có ý nghĩa về mặt kinh doanh.
• Live Evaluation & Monitoring: So sánh hiệu quả (tỷ lệ mở email, tỷ lệ click, tỷ lệ chuyển đổi) của các chiến dịch được cá nhân hóa với các chiến dịch đại trà trước đây.

Kết quả: Chuyển yêu cầu "phân khúc" mơ hồ thành một chiến lược marketing dựa trên dữ liệu, với các hành động và chỉ số đo lường rõ ràng.

Bài toán khuyến nghị (Recommendation) - Bán chéo trong giỏ hàng

Tình huống: Một công ty thương mại điện tử yêu cầu: "Xây dựng một hệ thống gợi ý sản phẩm để tăng doanh thu."

Áp dụng MLC:

• Value Proposition: "Dành cho khách hàng đang xem giỏ hàng, tính năng gợi ý 'Thường được mua cùng' là một danh sách sản phẩm giúp họ dễ dàng tìm thấy các món đồ hữu ích và tăng giá trị cho lần mua sắm này."
• Data Sources: Lịch sử chi tiết của tất cả các đơn hàng đã được thanh toán thành công.
• Collecting Data: Dữ liệu đơn hàng mới được thu thập theo thời gian thực.
• Features: Không có feature engineering phức tạp, đầu vào là các tập hợp sản phẩm trong mỗi giỏ hàng.
• Building Models: Chạy lại thuật toán Khai phá luật kết hợp (Association Rule Mining, ví dụ: Apriori) hàng tuần để tìm ra các "luật" mới (ví dụ: nếu mua sữa thì có 60% khả năng mua tã).
• Prediction/ML Task: Khuyến nghị sản phẩm. Đầu vào: danh sách sản phẩm trong giỏ hàng hiện tại. Đầu ra: danh sách các sản phẩm được gợi ý, xếp hạng theo độ tin cậy (confidence) của luật.
• Decisions: Khi người dùng thêm sản phẩm A vào giỏ, nếu có luật {A} -> {B} mạnh, hệ thống sẽ hiển thị sản phẩm B trong widget gợi ý "Thường được mua cùng".
• Making Predictions: Thời gian thực (real-time). Hệ thống tra cứu các luật đã được tính toán sẵn (từ bước Building Models) để đưa ra gợi ý ngay lập tức.
• Offline Evaluation: Đánh giá các luật được tạo ra dựa trên các chỉ số support, confidence, và lift.
• Live Evaluation & Monitoring: Chạy A/B testing. Chỉ số kinh doanh cốt lõi: Giá trị đơn hàng trung bình (AOV). So sánh AOV của nhóm khách hàng thấy gợi ý với nhóm không thấy.

Kết quả: Xác định rõ phương pháp kỹ thuật phù hợp để đánh thẳng vào mục tiêu kinh doanh (tăng AOV), tránh xây dựng các hệ thống phức tạp không cần thiết.

Kết luận

Việc thấu hiểu nghiệp vụ không phải là một sự trì hoãn không cần thiết. Nó là sự đầu tư thông minh nhất bạn có thể thực hiện. Bằng cách dành thời gian để lắng nghe, đặt câu hỏi và sử dụng các công cụ cấu trúc như Machine Learning Canvas, bạn sẽ chuyển mình từ một người thợ kỹ thuật thành một đối tác chiến lược có giá trị, người không chỉ xây dựng mô hình mà còn kiến tạo giá trị thực sự cho doanh nghiệp.

Lần tới, khi bạn nhận được một yêu cầu, đừng vội mở Jupyter Notebook. Hãy mở một cuộc đối thoại và một tấm canvas. Thành công của dự án, và đôi khi là cả việc cứu công ty khỏi một sai lầm tốn kém, phụ thuộc vào nó.

Phụ lục: Quy trình CRISP-DM (Cross-Industry Standard Process for Data Mining)

CRISP-DM là một khuôn khổ quy trình được công nhận rộng rãi, giúp cấu trúc hóa một dự án khoa học dữ liệu. Nó bao gồm sáu giai đoạn chính, có tính lặp lại và không nhất thiết phải tuần tự một cách cứng nhắc.

Business understanding - What does the business need? (Thấu hiểu nghiệp vụ)

• Xác định mục tiêu dự án dựa vào kiến thức chuyên môn và các báo cáo (report) có sẵn (thường do các nhà phân tích dữ liệu cung cấp).
• Xác nhận giá trị của dự án đối với người dùng cuối và các bên liên quan.
• Xác định các chỉ số kinh doanh (business metrics) cụ thể để đánh giá kết quả cuối cùng của dự án.

Data understanding - What data do we have / need? Is it clean? (Thấu hiểu dữ liệu)

• Mô tả dữ liệu cần thiết để giải quyết bài toán kinh doanh: dữ liệu này đến từ bên trong hay bên ngoài tổ chức? Nó là dữ liệu dạng quan sát, thí nghiệm hay mô phỏng? Khung thời gian thu thập dữ liệu là gì? Các đặc trưng (features) tiềm năng là gì? Số lượng dữ liệu cần thiết là bao nhiêu?
• Khám phá dữ liệu hiện có và xem xét chất lượng dữ liệu: đã có đủ dữ liệu hay cần thu thập thêm? Dữ liệu đã có nhãn (label) chưa? Có bị khuyết dữ liệu không? Có nhiễu hay không nhất quán không?

Data preparation - How do we organize the data for modeling? (Chuẩn bị dữ liệu)

• Hợp nhất dữ liệu (Integration): Kết hợp dữ liệu từ nhiều nguồn khác nhau (ví dụ: nối bảng từ CRM và bảng từ CSDL thanh toán).
• Làm sạch dữ liệu (Cleaning): Điền dữ liệu bị khuyết, làm trơn dữ liệu nhiễu, nhận diện và loại bỏ các giá trị ngoại lai (outliers), giải quyết các xung đột dữ liệu, thống nhất đơn vị tính,…
• Biến đổi dữ liệu (Transformation): Chuẩn hóa (standardization), rời rạc hóa (discretization), tổng quát hóa (generalization), thay đổi thang đo (rescaling), tạo các đặc trưng mới (feature engineering),…
• Giảm dữ liệu (Reduction): Lấy mẫu (sampling) để xử lý các tập dữ liệu quá lớn, lựa chọn đặc trưng (feature selection), gộp đặc trưng (feature aggregation),…

Model Building - What modeling techniques should we apply? (Xây dựng mô hình)

• Lựa chọn kỹ thuật mô hình hóa phù hợp với bài toán (ví dụ: hồi quy tuyến tính, cây quyết định, mạng nơ-ron, K-Means...).
• Đối với bài toán có giám sát, phân chia dữ liệu thành các tập huấn luyện (training data) và tập kiểm chứng/kiểm thử (validation/test data). Xây dựng mô hình bằng cách huấn luyện thuật toán trên tập training data.
• Có thể xây dựng nhiều mô hình khác nhau cũng như kết hợp chúng lại (ví dụ: ensemble learning) để cải thiện hiệu suất.

Testing & Evaluation - Which model best meets the objectives? (Đánh giá mô hình)

• Đánh giá các mô hình đã xây dựng để chọn ra mô hình tốt nhất. Quá trình này bao gồm cả góc độ kỹ thuật (technical evaluation) và góc độ kinh doanh (business evaluation).
• Sử dụng tập dữ liệu kiểm chứng/kiểm thử (validation/test data) - là tập dữ liệu mà mô hình chưa từng "nhìn thấy" - để đánh giá hiệu suất một cách khách quan (đây chính là đánh giá ngoại tuyến - offline evaluation).

Deployment - How do stakeholders access the results? (Triển khai)

• Xuất bản và bảo trì mô hình tốt nhất để người dùng cuối hoặc các hệ thống khác có thể sử dụng (ví dụ: triển khai dưới dạng một API, một dashboard, hoặc một báo cáo tự động).
• Theo dõi kết quả của việc sử dụng mô hình dưới góc độ kinh doanh trong môi trường thực tế (đây chính là đánh giá trực tiếp - live evaluation) và thu thập phản hồi để bắt đầu một chu trình CRISP-DM mới.