Data Requirements Trong Data Science: Xác Định Đúng Dữ Liệu Trước Khi Thu Thập

Bạn có thể nấu spaghetti khi tủ lạnh chỉ có mì và nước mắm — nhưng món ra sẽ không ra spaghetti. Cũng giống vậy, một mô hình data science sẽ không chạy đúng nếu dữ liệu bạn thu về không đúng loại, đúng cấu trúc, đúng đối tượng. Bài này giải thích data requirements trong data science theo cách dễ nhất: đây là danh sách đi chợ của người làm dữ liệu, ghi rõ cần mua gì, mua ở đâu, đóng gói ra sao, trước khi bắt tay vào thu thập. Đọc xong, bạn sẽ tự viết được một đặc tả yêu cầu dữ liệu cho bất kỳ bài toán nào, từ dự đoán tái nhập viện đến phân tích hành vi khách hàng.

Data requirements là gì, và nó nằm ở đâu trong quy trình?

Nói đơn giản, data requirements (yêu cầu dữ liệu) là một văn bản mô tả chính xác loại dữ liệu bạn cần để giải một bài toán đã đặt ra ở bước trước. Nó trả lời ba câu hỏi cốt lõi:

• Cần gì — những trường thông tin (biến) nào phải có trong tập dữ liệu.
• Định dạng ra sao — mỗi dòng là một đối tượng hay nhiều dòng cho một đối tượng, có bao nhiêu cột, kiểu dữ liệu mỗi cột.
• Lấy ở đâu — hệ thống nào đang giữ dữ liệu, ai sở hữu, truy cập hợp pháp bằng cách nào.

Trong chuỗi tổng quan 10 giai đoạn data science methodology, data requirements đứng ngay sau hai bước business understanding trong data science (hiểu bài toán) và analytic approach trong data science (chọn phương pháp), rồi mới đến bước thu thập dữ liệu. Nói cách khác, bạn phải biết mình đang giải bài toán gì và định dùng cách nào, thì mới viết được danh sách dữ liệu hợp lý. Nếu bạn đã nắu mì mà chưa có nước sốt, thì dù bạn có đi chợ cũng chưa biết mua cà chua hay mua phô mai.

Một điểm dễ nhầm: data requirements là đặc tả (tờ giấy liệt kê), còn data collection mới là hành động lấy (đi chợ). Hai việc này tách rời nhau. Sau khi đã lên xong yêu cầu dữ liệu, bước tiếp theo là thu thập dữ liệu theo vòng lặp, không làm một lần. Nếu bạn nhảy thẳng vào kéo dữ liệu từ hệ thống mà chưa có đặc tả, bạn sẽ kéo về một mớ hỗn độn và phải làm lại — giống như đi chợ không mang giấy rồi về nhà phát hiện mua thiếu mua thừa.

Vì sao bước yêu cầu dữ liệu lại quan trọng đến vậy?

Lý do lớn nhất là tiết kiệm thời gian và công sức. Viết yêu cầu trước khi viết code thu thập sẽ giúp bạn tránh đi lạc, tránh phải sửa cấu trúc bảng giữa chừng. Trong các dự án thực tế, thời gian thu thập và chuẩn bị dữ liệu thường chiếm phần lớn tiến độ, vậy nên càng rõ ràng từ đầu thì càng ít phải quay lại sửa.

Lý do thứ hai là tính đại diện của dữ liệu. Nếu bạn không nghĩ kỹ về đối tượng phân tích (cohort), bạn có thể để lọt vào những ca nhiễu, những người không phù hợp, và kết quả mô hình sẽ bị lệch. Chuyên ngành gọi hiện tượng này là skew — tức mô hình nghiêng về một nhóm mà không phản ánh đúng thực tế. Khi đó, dù thuật toán có hay đến đâu, kết luận cuối cùng cũng không đáng tin.

Lý do thứ ba là đây là cầu nối giữa lý thuyết và thực tế. Bài toán đặt ra trên giấy có thể đòi hỏi một biến mà hệ thống công ty không lưu, hoặc lưu ở dạng không truy xuất được. Bước yêu cầu dữ liệu là lúc bạn phát hiện vấn đề này và điều chỉnh kịp thời — chứ không phải đợi đến khi chạy mô hình rồi mới ngỡ ngàng.

Data requirements không phải là bước thủ tục. Nó là lúc bạn quyết định cả dự án đi đúng hay đi lệch — vì cấu trúc dữ liệu quyết định cấu trúc mô hình, và cấu trúc mô hình quyết định câu trả lời bạn nhận về.

Quan hệ hai chiều với modeling technique

Mỗi kỹ thuật mô hình hóa (modeling technique — tức cách bạn dùng thuật toán để học từ dữ liệu, ví dụ như cây quyết định, hồi quy, mạng nơ-ron) sẽ đòi hỏi dữ liệu theo một kiểu riêng. Có kỹ thuật cần mỗi dòng là một bản ghi đầy đủ cho một đối tượng, có kỹ thuật cần dữ liệu chuỗi thời gian (time series). Ví dụ cụ thể và dễ hình dung nhất là decision-tree classification (phân loại bằng cây quyết định — một thuật toán chia nhỏ dữ liệu theo từng tiêu chí để đưa ra quyết định phân loại). Thuật toán này cần dữ liệu ở dạng bảng, trong đó mỗi dòng là một đối tượng (một bệnh nhân, một khách hàng, một giao dịch) và mỗi cột là một biến (tuổi, giới tính, số tiền, v.v.).

Hệ quả là: nếu dữ liệu gốc trong hệ thống của bạn là hàng nghìn giao dịch rải rác cho một bệnh nhân, bạn sẽ không thể đưa nguyên bảng giao dịch vào cây quyết định. Bạn phải gộp (roll-up) các giao dịch đó về cấp bệnh nhân trước — ví dụ tính tổng chi phí, đếm số lần khám, lấy chẩn đoán gần nhất. Đây là việc của bước tiền xử lý dữ liệu (data preparation), nhưng bạn phải dự liệu trước ở bước yêu cầu dữ liệu: nếu không, bạn sẽ phát hiện ra quá muộn rằng dữ liệu thu về không tương thích với mô hình.

Quy trình 5 bước để xác định yêu cầu dữ liệu

Bạn có thể đi theo checklist năm bước dưới đây. Mỗi bước xử lý một khía cạnh của ba trụ cột: nội dung – định dạng – nguồn.

Bước 1 — Xác định cohort và tiêu chí lấy vào / loại ra

Cohort là nhóm đối tượng bạn phân tích, được xác định bằng các tiêu chí lấy vào (inclusion) và tiêu chí loại ra (exclusion). Bước này quyết định dữ liệu của bạn đại diện cho ai. Nếu bạn muốn dự đoán tái nhập viện ở bệnh nhân tim mạch, bạn không thể lấy tất cả bệnh nhân từng nhập viện — bạn phải khoanh vùng đúng nhóm có liên quan và loại bỏ nhóm có đặc điểm làm lệch kết quả.

Bước 2 — Mô tả nội dung cần thu thập

Liệt kê cụ thể các biến (trường dữ liệu) cần có. Với mỗi biến, ghi rõ ý nghĩa, đơn vị, khoảng giá trị hợp lệ, và lấy từ sự kiện nào. Ví dụ: "tuổi bệnh nhân tại thời điểm nhập viện, tính bằng năm, lấy từ ngày sinh trong hồ sơ đăng ký". Càng cụ thể, người lấy dữ liệu càng ít phải đoán.

Bước 3 — Xác định định dạng

Định dạng ở đây là cấu trúc bản ghi, không phải định dạng file lưu trữ (CSV, JSON, XLSX — những khái niệm này thuộc bài các định dạng file trong data science). Bạn cần quyết định mỗi dòng dữ liệu tương ứng với một đối tượng duy nhất hay nhiều dòng cho một đối tượng, có bao nhiêu cột, mỗi cột kiểu gì (số, chữ, ngày tháng, có/không). Cấu trúc này phải tương thích với modeling technique đã chọn ở bước analytic approach.

Bước 4 — Xác định nguồn

Mỗi trường dữ liệu lấy từ đâu, hệ thống nào giữ nó, ai sở hữu, có cần xin phép hay ký cam kết bảo mật không. Đừng bỏ qua bước này vì lý do pháp lý hoặc quyền riêng tư có thể chặn bạn lại đúng lúc dự án sắp triển khai.

Bước 5 — Nghĩ trước data preparation

Liệt kê các phép biến đổi cần làm trước khi dữ liệu vào mô hình: gộp giao dịch thành bản ghi đối tượng, xử lý giá trị thiếu, mã hóa biến phân loại, chuẩn hóa thang đo. Đây không phải việc của bước yêu cầu dữ liệu, nhưng bạn phải dự kiến để đặc tả không bị thiếu. Chi tiết kỹ thuật sẽ được làm ở bước tiền xử lý dữ liệu (data preparation).

Cách chọn cohort đúng — ba tiêu chí vàng

Một cohort tốt cần thỏa ba tiêu chí. Thiếu một tiêu chí, dữ liệu sẽ không trả lời đúng câu hỏi nghiên cứu.

• Đủ thông tin để trả lời câu hỏi. Nếu bạn muốn dự đoán tái nhập viện, cohort phải có đủ biến về lần nhập viện trước, chẩn đoán, điều trị, và kết quả. Thiếu một trong các biến này, mô hình sẽ không học được gì có ý nghĩa.
• Đủ thời gian theo dõi trước và sau sự kiện chính. Bệnh nhân mới nhập viện hôm qua chưa có dữ liệu theo dõi sau xuất viện — đưa vào cohort sẽ gây nhiễu.
• Loại bỏ ca làm lệch kết quả. Một số bệnh nhân có đặc điểm cực đoan (bệnh nền nặng, tái nhập viện quá nhiều lần, tử vong sớm) sẽ kéo mô hình nghiêng về nhóm đó mà bỏ quên phần lớn còn lại. Loại họ ra là cách giữ mô hình cân bằng.

Ví dụ minh họa: bài toán suy tim sung huyết

Để hình dung rõ hơn, mình đi theo ví dụ kinh điển trong tài liệu methodology của John Rollins (IBM Cognitive Class — cần verify nguồn và cập nhật 2025–2026 trước khi trích dẫn chính thức). Bối cảnh: một công ty bảo hiểm y tế muốn dự đoán khả năng tái nhập viện của bệnh nhân suy tim sung huyết (congestive heart failure — tình trạng tim bơm máu không hiệu quả, dẫn đến ứ dịch trong phổi và cơ thể) bằng cây quyết định. Mục tiêu: phát hiện sớm ai có nguy cơ cao để can thiệp, giảm chi phí bồi thường.

Tiêu chí lấy vào (inclusion)

Cohort gồm các bệnh nhân thỏa đồng thời các điều kiện:

• Nhập viện nội trú tại một bệnh viện trong vùng phục vụ của công ty bảo hiểm.
• Chẩn đoán chính là suy tim sung huyết trong vòng một năm gần nhất.
• Thời gian đăng ký bảo hiểm liên tục ít nhất 6 tháng trước lần nhập viện đó (đảm bảo có dữ liệu theo dõi trước).

Tiêu chí loại ra (exclusion)

Loại các bệnh nhân có bệnh nền nghiêm trọng khác (ung thư giai đoạn cuối, HIV/AIDS, bệnh phổi tắc nghẽn mạn tính nặng). Lý do: nhóm này có tỷ lệ tái nhập viện cao bất thường vì lý do khác ngoài suy tim, nếu để lọt vào sẽ khiến mô hình học sai.

Nội dung cần thu thập

Cho mỗi bệnh nhân trong cohort, cần các trường:

• Lần nhập viện: ngày nhập, ngày xuất, số ngày nằm.
• Chẩn đoán: mã chính, mã phụ, mã phụ thêm (theo hệ thống mã bệnh quốc tế ICD).
• Thủ thuật đã làm.
• Đơn thuốc trong và sau nhập viện.
• Dịch vụ khám: trong viện, ngoài viện, cấp cứu.
• Thông tin nhân khẩu: tuổi, giới tính, vùng miền.

Định dạng

Một dòng cho một bệnh nhân (một bản ghi/bệnh nhân), các cột là các biến mô hình cần. Cấu trúc này tương thích trực tiếp với cây quyết định đã chọn.

Điều phải dự liệu trước

Dữ liệu gốc trong hệ thống bảo hiểm thường lưu theo từng giao dịch (mỗi lần khám, mỗi đơn thuốc, mỗi xét nghiệm là một dòng riêng). Nghĩa là một bệnh nhân có thể có hàng trăm dòng rải rác trong năm. Để đưa vào cây quyết định, bạn phải gộp về cấp bệnh nhân: đếm số lần nhập viện, tính tổng chi phí, lấy chẩn đoán chính gần nhất. Phép gộp này nằm ở bước tiền xử lý dữ liệu (data preparation), nhưng phải được tính trước trong đặc tả — nếu không, bạn sẽ phát hiện vấn đề quá muộn.

Bốn sai lầm thường gặp khi xác định yêu cầu dữ liệu

Đây là những lỗi mà người mới và cả nhóm có kinh nghiệm đều dễ mắc. Biết trước để tránh.

Một, nhảy thẳng vào thu thập. Không có đặc tả rõ ràng, lập trình viên kéo dữ liệu theo kinh nghiệm, kết quả là dữ liệu thu về không khớp với nhu cầu mô hình. Phải sửa lại từ đầu, lãng phí cả tuần.

Hai, bỏ qua tiêu chí cohort. Lấy hết dữ liệu có sẵn mà không khoanh vùng, để lọt vào các ca không phù hợp, kết quả mô hình trông có vẻ tốt trên tập huấn luyện nhưng kém khi áp dụng thực tế.

Ba, không nghĩ trước data preparation. Phát hiện ở giữa dự án rằng dữ liệu gốc không tương thích mô hình, phải đình trệ chờ đội dữ liệu xử lý lại. Nếu dự liệu từ đầu, bạn có thể điều chỉnh thiết kế ngay từ bước yêu cầu.

Bốn, đánh đồng data requirements với data collection. Đặc tả và hành động là hai việc khác nhau. Đặc tả là viết ra giấy, hành động là đi lấy. Nếu bạn không tách rõ, khi bị áp lực tiến độ bạn sẽ bỏ qua bước đặc tả và nhảy thẳng vào lấy — quay lại sai lầm số một.

Cohort tốt không phải là cohort lớn nhất, mà là cohort đúng nhất với câu hỏi bạn đang đặt ra.

Điểm cần nhớ và checklist tóm tắt

Nếu bạn cần một bản ghi ngắn để dán vào tài liệu dự án, đây là phần tóm gọn:

• Ba câu hỏi cốt lõi: cần gì (biến/trường), lấy ở đâu (hệ thống, chủ sở hữu), định dạng ra sao (cấu trúc bản ghi, tương thích mô hình).
• Cohort có tiêu chí lấy vào / loại ra rõ ràng, đủ dữ liệu trước và sau sự kiện chính, loại bỏ ca nhiễu.
• Luôn nghĩ trước data preparation: roll-up, xử lý giá trị thiếu, mã hóa biến phân loại — dù chưa làm nhưng phải liệt kê.
• Đặc tả trước, thu thập sau: tách rõ data requirements (viết ra giấy) và data collection (đi lấy).
• Đặc tả phải khớp modeling technique: cây quyết định cần một dòng/đối tượng, chuỗi thời gian cần nhiều dòng theo trục thời gian, v.v.

Bạn có thể dùng năm bước trong phần quy trình ở trên làm checklist: (1) xác định cohort, (2) mô tả nội dung, (3) xác định định dạng, (4) xác định nguồn, (5) dự liệu data preparation. In ra dán cạnh màn hình khi bắt đầu một dự án mới.

Kết

Quay lại phép ví dụ nấu ăn: bạn không thể nấu spaghetti nếu chưa đọc công thức và đi chợ đúng danh sách. Bước data requirements chính là lúc bạn vừa đọc công thức, vừa lên danh sách đi chợ — ghi rõ cần mua gì, mua ở đâu, đóng gói ra sao. Làm tốt bước này, bạn tiết kiệm được hàng tuần sửa lại ở các bước sau, và mô hình của bạn có cơ hội cao cho ra câu trả lời đáng tin.

Sau khi danh sách đã có, bước tiếp theo là thu thập dữ liệu theo vòng lặp, không làm một lần. Nếu bạn muốn đi sâu vào phần thực thi (làm sạch, chuẩn hóa, xử lý giá trị thiếu), đọc tiếp bài về tiền xử lý dữ liệu (data preparation). Còn nếu muốn nhìn tổng quan toàn bộ chuỗi, quay lại bài tổng quan 10 giai đoạn data science methodology.