OSEMN Framework: 5 bước xử lý và khai thác dữ liệu
OSEMN là khung 5 bước (Obtain–Scrub–Explore–Model–iNterpret) giúp xử lý dữ liệu có lộ trình rõ ràng, biết lúc nào nên quay lại bước trước và điểm dừng nào hợp lý để chốt báo cáo.
Bạn vừa nhận một file Excel khách hàng 50.000 dòng từ sếp, mở ra thấy cột tên thì có người viết hoa, người viết thường, người gõ nhầm số điện thoại, dòng nào trống dữ liệu thì cũng có. Bạn không biết bắt đầu từ đâu, s� làm sai, và cũng sợ làm mãi không xong. OSEMN là một khung 5 bước (Obtain – Scrub – Explore – Model – iNterpret) để bạn có một lộ trình rõ ràng, nhưng phần khó hơn nằm ở ch� biết lúc nào cần quay lại bước trước và điểm dừng nào là hợp lý để chốt báo cáo. Bài này sẽ giúp bạn hiểu framework, biết chỗ hay vấp, và có checklist để áp dụng ngay cho một dự án nhỏ.
OSEMN là khung để bạn biết mình đang ở đâu trong quy trình và bước tiếp theo là gì — không phải công thức cứng phải đi đúng thứ tự tuyệt đối.
OSEMN là gì và vì sao người mới hay bỏ qua bước quan trọng
OSEMN là từ viết tắt của năm bước: Obtain (lấy dữ liệu về), Scrub (rửa sạch dữ liệu), Explore (ngó xem dữ liệu có gì đáng chú ý), Model (cho máy học hoặc xây mô hình phân tích), iNterpret (kể lại thành câu chuyện có ý nghĩa). Khung này được phổ biến rộng trong cộng đồng data science, gắn với tên Hilary Mason và Cliff Weiler — cần verify nguồn gốc trư�c khi trích dẫn chính thức cho tài liệu nội bộ. Về bản chất, nó mô tả một quy trình làm việc với dữ liệu khá giống quy trình phân tích dữ liệu nói chung, nhưng gọn hơn và dễ nhớ hơn cho người mới.
Mỗi chữ cái gói gọn một việc bằng ngôn ngữ đời thường: Obtain là "lấy dữ liệu về máy mình", Scrub là "lau chùi, sắp xếp lại cho sạch sẽ", Explore là "mở mắt nhìn xem có gì trước khi đặt câu hỏi", Model là "cho máy học hoặc tự tính toán để tìm quy luật", còn iNterpret là "kể lại bằng câu chuyện để người khác hiểu và ra quyết định".
Tâm lý phổ biến của người mới là muốn nhảy thẳng vào bước Model để có cảm giác "làm data science thật sự", nhưng thực tế bước Scrub và Explore mới quyết định kết quả cuối cùng có đúng hay không. Một mô hình đẹp chạy trên dữ liệu bẩn sẽ cho ra con số rất đẹp mà hoàn toàn sai — và bạn sẽ không biết mình sai ở đâu.
Obtain: lấy dữ liệu về từ đâu và ghi chép ra sao
Obtain là bước đưa dữ liệu về môi trường làm việc của bạn. Nguồn phổ biến với người mới gồm: file CSV/Excel mà đồng nghiệp gửi, file log từ hệ thống, kết quả khảo sát Google Forms, hoặc trích xuất từ database qua SQL — ngôn ngữ để "hỏi" kho chứa dữ liệu có cấu trúc. Nếu bạn làm việc với phần mềm bên thứ ba, có thể dùng API — cách để hai phần mềm "nói chuyện" với nhau và lấy dữ liệu tự động. Một số bạn sẽ nghe tới web scraping — tức là viết script để kéo dữ liệu từ trang web về, cách này cần kiểm tra rõ điều khoản sử dụng của trang đó.
Trước khi lấy dữ liệu, bạn nên trả lời bốn câu hỏi: dữ liệu này từ đâu ra, ai là người sở hữu, mình có được phép dùng cho mục đích này không (đặc biệt với dữ liệu khách hàng — cần verify quy định bảo vệ dữ liệu cá nhân tại Việt Nam trước khi áp dụng), và dữ liệu được cập nhật lần cuối khi nào. Bốn câu hỏi này nghe đơn giản nhưng hay bị bỏ qua, đến khi sếp hỏi "con số này lấy từ đâu" thì không ai trả lời được.
L�i thường gặp nhất là lấy dữ liệu về nhưng không ghi lại nguồn và thời điểm lấy. Sáu tháng sau mở lại, bạn không biết đây là bản chốt tháng 6 hay bản nháp, không biết trường "doanh thu" đã bao gồm thuế hay chưa, và mất cả ngày để truy ngược. Cách đơn giản: tạo một file text ngay cạnh dữ liệu, ghi 3 dòng — nguồn, ngày lấy, người cung cấp. Việc nhỏ này tiết kiệm hàng giờ trao đổi về sau.
Scrub: rửa sạch dữ liệu — bước tốn thời gian nhất
Scrub là bước làm sạch và chu�n hóa dữ liệu trước khi phân tích. Dữ liệu thô trong thực tế bao giờ cũng có vấn đề: ô trống, chữ viết hoa viết thường lộn xộn, dòng trùng nhau, định dạng ngày tháng không thống nhất, ký tự lạ từ copy-paste. Đây là lý do bước này thường ngốn phần lớn thời gian của một dự án dữ liệu.
Một ví dụ dễ hình dung: cột "thành phố" trong file khách hàng có thể chứa cả "Hà Nội", "ha noi", "HN ", "Hà Nội " (có dấu cách thừa), thậm chí "hà nội" không dấu. Nếu bạn đếm số khách theo thành phố mà không chuẩn hóa trước, bạn sẽ có tới 4–5 dòng cho cùng một thành phố, và báo cáo sẽ sai lệch. Với người mới dùng Python, công cụ phổ biến nhất là thư viện pandas — nên kiểm tra phiên bản 2025–2026 trên trang chính hãng trước khi bắt đầu dự án dài hơn một tuần.
Checklist cụ thể cho bước Scrub gồm: xử lý giá trị thiếu (bỏ dòng, thay bằng trung bình, hoặc giữ nguyên tùy ngữ cảnh), chuẩn hóa chữ hoa/thường và khoảng trắng thừa, loại bỏ dòng trùng lặp, kiểm tra giá trị bất thường (outlier — điểm lệch quá xa so với phần còn lại, ví dụ cột "tuổi" có giá trị 200). Đừng cố làm sạch "tới mức hoàn hảo" — hãy làm đủ tốt để bước Explore cho ra những phát hiện đáng tin.
Tâm lý hay gặp: nhìn dữ liệu xong tự nhủ "chắc ổn rồi, chạy model thôi". Đây là chỗ nhiều người mới tự làm khó mình — model chạy ra kết quả đẹp, nhưng khi đào sâu thì phát hiện 30% dữ liệu bị trùng dòng, hoặc outlier làm lệch hoàn toàn trung bình. Bài học rút ra: dành thời gian cho Scrub không phải lãng phí, mà là cách rẻ nhất để tránh sai lầm tốn kém sau này.
Nếu bạn không chịu rửa sạch dữ liệu, bạn đang chuẩn bị cho mô hình một câu chuyện cổ tích — đẹp nhưng không có thật.
Explore: mở mắt nhìn dữ liệu trước khi đặt câu h�i
Explore, hay còn gọi là EDA (Exploratory Data Analysis — phân tích khám phá dữ liệu), là bước bạn dùng biểu đồ và thống kê mô tả để "ngó" dữ liệu trước khi quyết định phân tích cái gì. Mục tiêu không phải làm biểu đồ cho đẹp, mà là phát hiện điều bất thường và gợi ý hướng đi cho bước tiếp theo.
Với người mới, công cụ quen thuộc nhất là Jupyter Notebook — giao diện cho phép bạn viết từng đoạn code xen kẽ với chú thích bằng văn bản, rất phù hợp để "vừa làm vừa suy nghĩ". Trong Jupyter, bạn sẽ kết hợp pandas (xử lý bảng), matplotlib hoặc seaborn (vẽ biểu đồ). Khi bắt đầu, hãy kiểm tra phiên bản của các thư viện này trên trang chính hãng vì một số hàm có thể đổi tên hoặc thay đổi cách dùng giữa các phiên bản.
Ba việc nên làm ở bước này: (1) tính các thống kê mô tả cơ bản — trung bình (mean), số giữa (median), giá trị lớn nhất/nhỏ nhất, để hiểu dữ liệu có biến động lớn không; (2) vẽ biểu đồ phân phối (histogram — biểu đồ cột đếm tần suất) cho từng biến số và biểu đồ phân tán (scatter — biểu đồ chấm thể hiện quan hệ giữa hai biến) cho các cặp biến nghi có liên quan; (3) đặt câu hỏi trước khi nhìn — biến nào có biến động lớn, có nhóm con (segment) nào nổi bật không, có mối liên hệ rõ ràng giữa biến X và Y không.
Điểm hay bị bỏ qua: người mới thường mở máy lên là vẽ biểu đồ xong rồi nhảy sang Model. Explore không phải làm cho đẹp — mục đích thực sự là phát hiện những điều bất thường (ví dụ một nhóm khách có tuổi trung bình khác hẳn phần còn lại) và gieo ý tưởng cho câu hỏi phân tích. Nếu bạn không tìm được gì đáng chú ý ở Explore, có thể câu hỏi của bạn chưa đúng, hoặc dữ liệu chưa đủ — và đó là tín hiệu tốt để quay lại bước trước thay vì cố chạy mô hình.
Model: cho máy học hay tự xây mô hình phân tích
Model theo nghĩa rộng không chỉ là thuật toán machine learning (máy học — cho máy học từ dữ liệu để dự đoán hoặc phân loại), mà bao gồm mọi cách bạn tổng hợp dữ liệu để trả lời câu hỏi: từ một bảng tổng hợp doanh thu theo tháng, một công thức tính trung bình, cho tới mô hình dự đoán churn (tỷ lệ khách hàng rời bỏ). Với người mới bắt đầu, hiểu rằng "model" không đồng nghĩa với "thuật toán phức tạp" đã giúp tránh được rất nhiều áp lực.
Hai dạng bài toán phổ biến nhất: phân loại (classification — ví dụ khách hàng này có khả năng churn hay không, email này là spam hay không spam) và dự đoán giá trị số (regression — ví dụ doanh thu tháng sau là bao nhiêu, giá nhà khu vực này khoảng bao nhiêu). Xác định đúng dạng bài toán giúp bạn chọn đúng nhóm thuật toán và đúng cách đo lường kết quả.
Một cảnh báo quan trọng: mô hình phức tạp không tự động đồng nghĩa với mô hình tốt. Với bộ dữ liệu vài trăm dòng, một đường trung bình (baseline đơn giản) có thể thắng mạng nơ-ron phức tạp — vì mô hình phức tạp dễ học cả nhiễu. Nguyên tắc làm việc hợp lý: chọn 2–3 thuật toán đại diện (một baseline đơn giản + một–hai thuật toán phức tạp hơn) để so sánh, không chạy hết mọi thuật toán vì sẽ không có thời gian đọc hết kết quả.
iNterpret: kể lại kết quả thành câu chuyện
Bước cuối cùng thường bị đánh giá thấp nhưng lại quyết định báo cáo của bạn có được sử dụng hay không. Phân biệt rõ hai việc: "đọc kết quả" (model có accuracy 0.87, recall 0.81) và "kể chuyện từ kết quả" (khách hàng 25–34 tuổi ở khu vực TP.HCM có tỷ lệ rời bỏ cao gấp 1.4 lần trung bình, đề xuất khảo sát sâu nhóm này trong quý 3). Phần lớn người không chuyên kỹ thuật — sếp, đồng nghiệp, khách hàng — không quan tâm con số accuracy, họ quan tâm "vậy giờ làm gì".
Một cấu trúc gợi ý cho phần trình bày: mở bằng phát hiện chính (một câu) → đưa bằng chứng (biểu đồ, con số cụ thể) → đề xuất hành động cụ thể → nêu giới hạn của phân tích (dữ liệu chỉ đến tháng 6, chưa tính yếu tố mùa vụ, v.v.). Tránh dùng thuật ngữ kỹ thuật trong báo cáo cuối — thay vì "model có AUC 0.83", hãy viết "mô hình phân loại đúng 83 trên 100 trường hợp trong dữ liệu thử nghiệm". Tỷ lệ cụ thể nên được kiểm chứng lại với nguồn dữ liệu thực tế của dự án.
Khi nào nên quay lại bước trước và điểm dừng hợp lý
OSEMN không phải đường thẳng một chiều — bạn sẽ quay lại bước trước khá thường xuyên, và đó là bình thường. Ba tình huống phổ biến: (1) ở bước Explore phát hiện outlier hoặc giá trị bất thường → quay lại Scrub để xử lý; (2) chạy Model xong nhưng không cải thiện so với baseline → quay lại Explore để đặt câu hỏi khác hoặc kiểm tra lại dữ liệu; (3) kết quả khó giải thích hoặc đối chiếu với thực tế không khớp → quay lại Model chọn thuật toán khác, hoặc thậm chí quay về Obtain để lấy thêm nguồn dữ liệu.
Điểm dừng hợp lý cho mỗi bước có thể tóm gọn bằng câu hỏi: Obtain — "dữ liệu đã có nguồn ghi chép rõ chưa?"; Scrub — "dữ liệu đã đủ sạch để không làm sai lệch kết quả?"; Explore — "đã phát hiện ít nhất 1–2 điều đáng chú ý?"; Model — "đã so sánh với baseline đơn giản?"; iNterpret — "người không chuyên đọc xong có biết nên làm gì?". Khi cả 5 câu trả lời đều "ổn", bạn có thể chốt báo cáo — không cần phân tích kiểu "mãi không xong".
OSEMN trong thực tế 2025–2026: công cụ mới, nguyên tắc cũ
Giai đoạn gần đây, nhiều công cụ AutoML (tự động hóa một phần quy trình xây mô hình) ra đời có thể tự làm bước Scrub và Model một phần — ví dụ tự phát hiện outlier, tự chọn thuật toán, tự so sánh kết quả. Điều này giúp người mới bớt áp lực kỹ thuật, nhưng cũng dễ tạo cảm giác "chỉ cần bấm nút là xong". Thực tế, bước Obtain (đặt câu hỏi đúng, lấy đúng nguồn) và bước iNterpret (kể chuyện cho người ra quyết định) vẫn phụ thuộc hoàn toàn vào con người. Tính năng cụ thể của từng công cụ AutoML thay đổi theo từng năm, nên kiểm tra trang chính hãng trước khi đưa vào quy trình.
Khi so sánh với so với quy trình CRISP-DM — một khung lâu đời hơn trong data mining — OSEMN gọn hơn, dễ nhớ hơn cho người mới, nhưng thiếu vòng lặp triển khai (deployment) và vòng lặp kinh doanh. Với dự án nh� hoặc báo cáo một lần, OSEMN thường đủ dùng. Với dự án lớn đi vào vận hành, bạn có thể cần kết hợp thêm các bước từ khung khác.
OSEMN là khung để bạn biết mình đang ở đâu và bước tiếp theo là gì — không phải công thức cứng phải đi đúng thứ tự tuyệt đối, và càng không phải đường một chiều.
Tóm lại, OSEMN cho bạn năm điểm dừng rõ ràng — Obtain, Scrub, Explore, Model, iNterpret — và quan trọng hơn, cho bạn biết lúc nào cần quay lại bước trước khi kết quả đi sai hướng. Khi áp dụng cho một bộ dữ liệu lộn xộn, hãy nhớ dành thời gian cho Scrub và Explore đủ nhiều, đặt câu hỏi trước khi chạy mô hình, và chốt báo cáo bằng một câu chuyện có hành động cụ thể thay vì một bảng con số khô. Nếu bạn muốn tìm hiểu thêm các khung methodology khác trong data science, hãy xem thêm bài viết tổng quan về quy trình phân tích dữ liệu và bài chi tiết về quy trình CRISP-DM trong cùng chuyên mục.
Phong Nguyen
