Methodology trong Data Science: Hướng dẫn tổng quan và áp dụng thực tế cho người mới

Bạn mở file Excel khách hàng ra, thấy vài chục nghìn dòng, hào hứng mở Python lên và train một mô hình dự đoán ngay. Hai ngày sau, bạn nhận ra dữ liệu có dòng bị trống, một số đơn hàng ghi nhầm ngày, và bài toán bạn đang giải không đúng câu hỏi mà sếp thật sự cần trả lời. Chuyện này rất phổ biến, và lý do thường không phải bạn kém — mà là bạn chưa có một danh sách việc cần làm theo thứ tự trước khi bắt tay vào. Methodology trong data science chính là danh sách đó: trình tự chung để một dự án dữ liệu đi từ câu hỏi kinh doanh đến kết quả thật sự ai đó dùng được.

Bài viết này không liệt kê cùng lúc năm khung quy trình khác nhau rồi để bạn tự chọn — vì như vậy chỉ thêm rối. Thay vào đó, mình sẽ chọn một khung xương sống là CRISP-DM (một quy trình 6 bước đã được dùng từ cuối những năm 1990 đến nay), kết hợp thêm một khung gọn hơn là OSEMN cho phần thao tác thực tế với dữ liệu. Bạn sẽ đọc xong với một checklist có thể in ra dán cạnh màn hình.

Methodology trong data science thật ra là gì?

Nhiều bạn mới quen với từ "methodology" qua các bài tiếng Anh dịch sang, nghe rất hàn lâm nhưng lại không rõ nó khác gì với "method". Nói ngắn gọn: method là một kỹ thuật cụ thể — ví dụ hồi quy logistic (một cách dự đoán ra giá trị "có/không" dựa trên các yếu tố đầu vào), phân cụm khách hàng, hay vẽ biểu đồ phân tán. Còn methodology là trình tự tổng thể: khi nào dùng kỹ thuật nào, làm bước nào trước, bước nào sau, khi nào quay lại lặp. Giống như nấu ăn: "luộc rau 3 phút" là method, còn "đi chợ → rửa → sơ chế → nấu → nêm nếm → dọn bàn" là methodology.

Vì sao cần có methodology? Ba lý do thực tế. Thứ nhất, nó tiết kiệm thời gian: khi bạn đã có trình tự, bạn không phải nghĩ lại từ đầu mỗi dự án. Thứ hai, dễ giao tiếp với đồng đội hoặc sếp — ai cũng biết đang ở bước nào, còn thiếu gì. Thứ ba, dễ quay lại sửa lỗi: nếu kết quả sai, bạn biết quay về bước nào để xem lại. Methodology không phải cái khuôn cứng bắt buộc đi thẳng từ A đến Z; trong thực tế bạn sẽ lặp lại nhiều vòng, nhưng luôn có một trình tự nền để bám vào.

Methodology là trình tự tổng thể còn method chỉ là một kỹ thuật lẻ — có nó bạn tiết kiệm thời gian, dễ phối hợp với đội và biết quay lại bước nào khi kết quả sai, thay vì nhảy vào phân tích mà không có khung.

Khung CRISP-DM: 6 bước cho cả dự án dài hơi

CRISP-DM là viết tắt của Cross-Industry Standard Process for Data Mining — một quy trình được đề xuất từ cuối những năm 1990 bởi Daimler, Chrysler, IBM và NCR (cần verify lại nguồn chính thức nếu bạn dùng trong bài thuyết trình). Nó được dùng rộng rãi vì gọn, áp dụng được cho nhiều ngành, và gần gũi với cách người đi làm thật sự triển khai một dự án. Một bản cập nhật mới (CRISP-DM 4.0) cũng đã được cộng đồng thảo luận trong những năm gần đây, nhưng phần lõi 6 bước vẫn giữ nguyên.

Bước 1 — Hiểu bài toán kinh doanh. Trước khi đụng vào dữ liệu, bạn phải trả lời được: mình đang cố giải quyết câu hỏi gì, cho ai, kết quả sẽ được dùng để quyết định điều gì. Ví dụ: "Mình muốn biết trong tháng tới, khoảng bao nhiêu phần trăm khách sẽ ngừng mua, để team chăm sóc khách gọi điện trước." Câu hỏi càng cụ thể, bạn càng dễ biết khi nào xong việc.

Bước 2 — Hiểu dữ liệu. Mở dữ liệu ra xem có những trường nào, dòng nào lạ, giá trị nào bị thiếu, có trường nào ghi sai kiểu (như ngày tháng bị lưu thành chữ) hay không. Bước này nghe nhẹ nhưng hay bị bỏ qua. Với một bảng Excel khách hàng, bạn cần biết: có bao nhiêu dòng, dòng nào trùng, cột nào có nhiều ô trống, có cột nào không hiểu nghĩa.

Bước 3 — Chuẩn bị dữ liệu. Đây thường là phần tốn thời gian nhất. Bạn lọc bỏ dòng lỗi, gộp các bảng lại với nhau (ví dụ gộp đơn hàng với thông tin khách), xử lý giá trị thiếu (bỏ đi hay điền bằng giá trị hợp lý), tạo thêm các cột mới hữu ích (ví dụ tính tổng tiền từ số lượng và đơn giá). Cũng nên ghi lại những gì đã làm — để sau này lặp lại được khi có dữ liệu mới.

Bước 4 — Mô hình hoá. Đây là lúc bạn thử vài thuật toán khác nhau — chẳng hạn hồi quy logistic, cây quyết định, hay một mô hình phức tạp hơn — rồi so sánh kết quả. Với dự án nhỏ vài nghìn dòng, đừng tham mô hình quá to; mô hình đơn giản đôi khi hiệu quả hơn và dễ giải thích cho người không chuyên.

Bước 5 — Đánh giá. Mô hình có thể cho con số chính xác trên tập kiểm tra (ví dụ dự đoán đúng 85%) nhưng vẫn chưa chắc đã giải quyết được bài toán kinh doanh. Bạn cần ngồi lại với người đặt hàng: kết quả này có ý nghĩa gì, có giúp ra quyết định thật không, có rủi ro gì không.

Bước 6 — Triển khai và theo dõi. Đưa kết quả vào dùng thật: có thể là một bảng Excel gửi hàng tuần, một dashboard (bảng thông tin trực tuyến) đơn giản, hoặc một dòng code tự động chạy. Sau khi triển khai, bạn vẫn phải theo dõi: dữ liệu thay đổi theo thời gian, mô hình có thể "già" đi và dự đoán kém dần — hiện tượng này hay được gọi là data drift (dữ liệu trôi). Khi đó, bạn quay lại bước 1 hoặc bước 2 để cập nhật.

Điểm mấu chốt của CRISP-DM là đây là vòng tròn, không phải đường thẳng. Sau khi triển khai, bạn gần như chắc chắn sẽ phát hiện điều gì đó cần làm lại từ đầu — và đó là chuyện bình thường.

Khung OSEMN: gọn hơn cho phần thao tác thực tế

Bên cạnh CRISP-DM, một khung gọn hơn từng được Google Analytics Academy giới thiệu là OSEMN (cần verify xem khóa học đó còn dùng tên này hay không — Google hay cập nhật nội dung). OSEMN chia phần thực hành thành 5 bước: Obtain (lấy dữ liệu từ nguồn nào — file, database, API), Scrub (làm sạch, xử lý trống/lỗi/trùng), Explore (nhìn tổng quan bằng biểu đồ, thống kê mô tả), Model (chạy thuật toán), iNterpret (diễn giải kết quả cho người không chuyên, kèm khuyến nghị hành động).

OSEMN nằm gọn trong các bước 2 đến 5 của CRISP-DM — nghĩa là bạn dùng CRISP-DM làm khung tổng, còn OSEMN dùng làm danh sách việc cụ thể khi ngồi trước dữ liệu. Cách kết hợp này giúp bạn không bị lạc giữa hai quy trình mà vẫn tận dụng được điểm mạnh của mỗi cái.

Áp dụng thực tế: dự đoán khách rời bỏ cho shop bán hàng online nhỏ

Để bạn thấy rõ hơn, mình đi cùng một ví dụ kiểu Việt Nam: một shop bán hàng online nhỏ muốn dự đoán khách rời bỏ (churn) — tức khách sẽ ngừng mua trong 1–2 tháng tới — để kịp gửi mã giảm giá chăm sóc.

Bước 1 — Bài toán kinh doanh: Sếp muốn biết trong 200 khách mua gần đây, khoảng bao nhiêu người có nguy cơ ngừng mua. Kết quả dùng để team CSKH gọi/nhắn tin trước. Tiêu chí thành công: phát hiện được ít nhất 60% khách thật sự sẽ rời đi (recall — tỷ lệ bắt đúng).

Bước 2 — Hiểu dữ liệu: Dữ liệu lấy từ hệ thống bán hàng (POS), bao gồm: ngày mua, số tiền, sản phẩm, kênh mua. Bạn mở ra thấy có dòng thiếu ngày, có dòng trùng, và một số đơn test của nội bộ cần loại bỏ.

Bước 3 — Chuẩn bị dữ liệu: Bỏ dòng trùng, bỏ đơn nội bộ, điền hoặc loại bỏ dòng thiếu ngày, tính thêm các cột như "số ngày kể từ lần mua cuối", "tổng tiền 3 tháng gần nhất", "số đơn trong 30 ngày qua". Ghi lại file notebook để lần sau lặp lại.

Bước 4 — Mô hình hoá: Với vài nghìn dòng dữ liệu, bạn có thể thử hồi quy logistic trước (đơn giản, dễ giải thích), rồi thử cây quyết định hoặc random forest (mô hình cây gộp, mạnh hơn nhưng khó giải thích hơn). So sánh trên tập kiểm tra.

Bước 5 — Đánh giá: Ngoài con số accuracy (tỷ lệ dự đoán đúng tổng thể), bạn xem recall — trong số khách thật sự rời đi, mình bắt được bao nhiêu. Nếu recall thấp, nghĩa là bỏ sót nhiều khách. Cũng nên hỏi sếp: "Nếu mô hình dự đoán 50 khách có nguy cơ, team có gọi nổi hết không, hay cần giảm xuống còn 20?"

Bước 6 — Triển khai: Không cần dựng hệ thống phức tạp. Bạn có thể xuất một bảng Excel hàng tuần gửi team CSKH, hoặc dựng một dashboard đơn giản bằng Google Sheets kèm biểu đồ. Sau một tháng, kiểm tra lại: các khách được cảnh báo có thật sự rời đi không, mô hình có cần cập nhật không.

Nếu bạn đang làm đồ án sinh viên thay vì đi làm, hãy chú ý: đồ án thường có đầy đủ bước 2–5, nhưng hay bị bỏ bước 1 (hỏi rõ bài toán) và bước 6 (triển khai). Hai bước này lại chính là điểm cộng nếu bạn trình bày trong buổi bảo vệ.

Những sai lầm phổ biến người mới hay mắc

Sai lầm thứ nhất là nhảy thẳng vào mô hình. Bạn thấy dữ liệu, thấy có cột "ngừng mua hay không", và train ngay. Nhưng nếu chưa hiểu bài toán, bạn có thể đang dự đoán nhầm thứ không ai hỏi. Sai lầm thứ hai là làm sạch dữ liệu xong mà không ghi lại: hai tháng sau khi có dữ liệu mới, bạn không biết đã lọc theo quy tắc nào, kết quả khác đi và bạn không hiểu vì sao.

Sai lầm thứ ba là đánh giá mô hình trên chính dữ liệu đã dùng để train — sẽ cho kết quả đẹp nhưng vô nghĩa. Luôn tách một phần dữ liệu ra làm tập kiểm tra (test set) trước khi train. Sai lầm thứ tư là triển khai xong rồi để đó. Mô hình sau vài tháng có thể bị "già" vì hành vi khách thay đổi, dữ liệu mới khác dữ liệu cũ (data drift). Nên đặt lịch xem lại định kỳ, ít nhất mỗi quý một lần.

Đừng nhảy vào mô hình khi chưa hiểu bài toán, ghi lại cách làm sạch dữ liệu, luôn tách một phần dữ liệu để kiểm tra riêng, và đặt lịch xem lại mô hình ít nhất mỗi quý vì khách hàng và dữ liệu cũng đổi theo thời gian.

Checklist mở đầu mỗi dự án

Trước khi mở bất kỳ file dữ liệu nào, hãy trả lời 4 câu hỏi và viết ra giấy (hoặc file markdown đầu dự án):

• Câu hỏi kinh doanh mình đang cố trả lời là gì, và ai sẽ dùng kết quả?
• Dữ liệu mình có gồm những trường nào, nguồn ở đâu, độ tin cậy ra sao?
• Tiêu chí thành công là gì — một con số cụ thể (recall ≥ 60%, sai số dưới X%) hay một quyết định cụ thể (sếp ký duyệt báo cáo)?
• Kế hoạch triển khai: ai sẽ dùng, dùng bằng công cụ gì, khi nào cần cập nhật lại?

In bốn câu này ra dán cạnh màn hình là bạn đã có 80% của một methodology tốt. Phần còn lại là trải nghiệm và sửa sai sau mỗi dự án.

Nếu muốn có một bản PDF checklist đầy đủ kèm ví dụ cho dự án churn mình vừa đi cùng, bạn có thể đăng ký nhận qua {{LINK:checklist_download}}. Và nếu bạn đang băn khoăn giữa các thuật toán cụ thể để chạy cho dữ liệu vài nghìn dòng, bài viết về cách chọn mô hình cho dự án nhỏ có thể giúp bạn bước tiếp theo.