Predictive Analytics là gì? Cách dự đoán tương lai từ dữ liệu quá khứ cho doanh nghiệp
Predictive Analytics (phân tích dự đoán) là cách dùng dữ liệu quá khứ để dự đoán kết quả tương lai, bằng mô hình thống kê, data mining (khai phá dữ liệu) và machine learning (học máy) [1]. Nó trả lời câu hỏi như tuần sau cửa hàng bán bao nhiêu hoặc khách nào sắp ngừng mua.
Nhiều người nghĩ Predictive Analytics là bấm một nút để ra con số. Thực tế, phần lớn công sức nằm ở chuẩn bị dữ liệu và kiểm chứng kết quả, còn thuật toán chỉ là một bước ở giữa. Bài này đi qua 4 bước làm được ngay với SQL, Power Query và Power BI trên ví dụ chuỗi bán lẻ tại Việt Nam, rồi chỉ ra Predictive Analytics nằm ở đâu trong một hệ thống Agentic AI Analytics.
Mục lục
X. Kết luận
I. Predictive Analytics là gì và dùng để làm gì trong công việc?
Predictive Analytics dùng pattern trong dữ liệu đã xảy ra để ước tính điều chưa xảy ra [1]. Kết quả luôn là một ước lượng kèm sai số, không phải con số đúng tuyệt đối. Chủ đề này cũng đã được nghiên cứu theo hướng gắn với business intelligence: dùng mô hình machine learning để hỗ trợ ra quyết định ngay trên nền SQL-based analytics [2]. Với người đã quen SQL và Power BI, đó là điểm vào khá tự nhiên.
1. Ba nhóm bài toán hay gặp
Trong công việc, hầu hết bài toán rơi vào ba dạng. Bài toán hồi quy (regression) dự đoán một con số, ví dụ doanh thu nhóm đồ uống của cửa hàng Quận 7 tuần tới. Bài toán phân loại (classification) dự đoán một nhãn, ví dụ khách hàng thành viên này có ngừng mua trong 60 ngày tới hay không. Bài toán chuỗi thời gian (time series) dự đoán giá trị theo trình tự ngày, tuần, tháng, nơi thứ tự và mùa vụ (Tết, 11/11, cuối năm) quan trọng hơn các biến khác.
2. Dùng vào việc gì ở một chuỗi bán lẻ
Ba việc hay được giao nhất là dự báo doanh số theo cửa hàng để chốt kế hoạch nhập hàng, dự đoán nhóm khách có nguy cơ rời bỏ để đội CRM chạy chiến dịch giữ chân, và ước tính nhu cầu theo SKU để giảm hàng tồn. Cả ba đều có chung đầu vào: dữ liệu giao dịch quá khứ đã được làm sạch. Cả ba cũng có chung đầu ra: một con số hoặc xác suất đủ cụ thể để ai đó ra quyết định.
II. Chuẩn bị trước khi triển khai Predictive Analytics
Phần lớn dự án dự đoán hỏng ở khâu này, không phải ở thuật toán. Bạn cần chốt ba thứ trước khi viết dòng code đầu tiên.
1. Câu hỏi kinh doanh có hạn và có người dùng
"Dự báo doanh số" là chưa đủ. Hãy viết lại thành: "Dự báo doanh thu từng cửa hàng theo tuần cho 8 tuần tới, để trưởng vùng điều chỉnh lượng hàng nhập vào thứ Hai hằng tuần." Câu này cho bạn biết đơn vị thời gian, độ chi tiết, tầm nhìn và người sẽ dùng kết quả. Nếu không trả lời được "ai dùng, dùng lúc nào", đừng bắt đầu.
2. Dữ liệu đủ dài và đủ sạch
Với bài toán có mùa vụ, bạn cần ít nhất vài chu kỳ đầy đủ, tức tối thiểu hai đến ba năm dữ liệu theo tuần nếu muốn mô hình nhìn thấy hơn một kỳ Tết. Kiểm tra nhanh bốn điểm: khóa cửa hàng và sản phẩm có nhất quán giữa các hệ thống không, có tuần nào thiếu dữ liệu vì cửa hàng đóng cửa sửa chữa không, giá trị âm do trả hàng được xử lý ra sao, và khuyến mãi có được ghi lại thành bảng riêng không. Khuyến mãi không được ghi lại là nguyên nhân phổ biến khiến mô hình "không hiểu" vì sao tuần đó doanh thu tăng.
3. Công cụ làm được ngay
Bạn không cần nền tảng mới. SQL để gom và tạo biến, Power Query để xử lý nhẹ và gắn lịch, Python (scikit-learn hoặc statsmodels) để huấn luyện, Power BI để trình bày. Nếu công ty đã có Microsoft Fabric, mọi bước có thể nằm trong cùng một môi trường. Nếu chưa, một bảng kết quả ghi về SQL Server hay file CSV trên SharePoint là đủ để bắt đầu.
III. Bước 1: Tiền xử lý dữ liệu bằng SQL và Power Query
Mục tiêu của bước này là tạo ra một bảng phẳng, mỗi dòng là một cửa hàng trong một tuần, kèm các biến mô hình có thể dùng. Làm đúng bước này thường quyết định chất lượng dự báo nhiều hơn việc đổi thuật toán.
1. Gom dữ liệu và tạo biến trễ bằng SQL
Ví dụ dưới đây gom doanh thu theo cửa hàng và tuần, rồi thêm doanh thu của tuần trước, của 4 tuần trước và trung bình 4 tuần gần nhất. Lưu ý trung bình trượt chỉ lấy các tuần trước tuần hiện tại, để không dùng thông tin của chính tuần cần dự đoán.
WITH weekly AS (
SELECT store_id,
DATEADD(week, DATEDIFF(week, 0, order_date), 0) AS week_start,
SUM(net_amount) AS revenue
FROM fact_sales
WHERE order_date < '2026-10-01'
GROUP BY store_id, DATEADD(week, DATEDIFF(week, 0, order_date), 0)
)
SELECT store_id, week_start, revenue,
LAG(revenue, 1) OVER (PARTITION BY store_id ORDER BY week_start) AS rev_lag_1w,
LAG(revenue, 4) OVER (PARTITION BY store_id ORDER BY week_start) AS rev_lag_4w,
AVG(revenue) OVER (PARTITION BY store_id ORDER BY week_start
ROWS BETWEEN 4 PRECEDING AND 1 PRECEDING) AS rev_avg_4w
FROM weekly;2. Làm sạch và gắn lịch bằng Power Query
Những việc nên làm ở Power Query vì thao tác trực quan và dễ giao lại cho đồng nghiệp: loại dòng trùng mã đơn, thay giá trị rỗng ở cột khuyến mãi bằng 0, chuẩn hóa tên chi nhánh viết khác nhau giữa các hệ thống, và nối với bảng lịch riêng. Bảng lịch này nên có cờ Tết, 11/11, 12/12, tuần lễ lương và các đợt khuyến mãi. Tết rơi vào ngày khác nhau mỗi năm theo âm lịch, nên đừng suy ra từ tháng dương lịch.
IV. Bước 2: Chọn thuật toán dự đoán phù hợp bài toán
Đừng bắt đầu từ thuật toán phức tạp nhất. Hãy bắt đầu từ baseline, tức một cách dự đoán đơn giản để mọi mô hình sau đó phải thắng. Với doanh thu bán lẻ, baseline hợp lý là "bằng tuần cùng kỳ năm trước" hoặc "bằng trung bình 4 tuần gần nhất".
1. Khớp loại bài toán với thuật toán khởi điểm
Bài toán | Ví dụ công việc | Thuật toán nên thử trước | Thước đo |
|---|---|---|---|
Hồi quy | Doanh thu cửa hàng tuần tới | Linear Regression, Gradient Boosting | MAE, MAPE |
Phân loại | Khách có ngừng mua trong 60 ngày | Logistic Regression, Random Forest | Precision, Recall, AUC |
Chuỗi thời gian | Doanh số theo ngày có mùa vụ | ETS, ARIMA, Prophet | MAE trên tập kiểm tra theo thời gian |
2. Quy tắc chọn thực tế
Dữ liệu ít và cần giải thích được cho quản lý, chọn mô hình tuyến tính. Dữ liệu có nhiều biến và quan hệ phi tuyến như giá, khuyến mãi, thời tiết, chọn Gradient Boosting. Chỉ có một chuỗi đơn lẻ và mùa vụ rõ, chuỗi thời gian thuần là đủ. Nếu mô hình phức tạp chỉ hơn baseline vài phần trăm, hãy giữ mô hình đơn giản. Nó dễ bảo trì và dễ giải thích hơn khi quản lý hỏi "tại sao con số này thấp".
V. Bước 3: Huấn luyện mô hình và diễn giải kết quả
1. Chia dữ liệu theo thời gian, không chia ngẫu nhiên
Sai lầm hay gặp nhất ở bước này là dùng train_test_split ngẫu nhiên cho dữ liệu chuỗi thời gian. Khi đó mô hình được "nhìn thấy" các tuần sau để dự đoán các tuần trước, và điểm số đẹp một cách giả tạo. Hãy cắt theo mốc: huấn luyện đến hết tháng 6/2026, kiểm tra từ tháng 7 đến tháng 9/2026.
import pandas as pd
from sklearn.ensemble import GradientBoostingRegressor
from sklearn.metrics import mean_absolute_error
df = pd.read_sql(query, conn).dropna()
features = ["rev_lag_1w", "rev_lag_4w", "rev_avg_4w", "is_tet", "is_sale_week"]
train = df[df.week_start < "2026-07-01"]
test = df[df.week_start >= "2026-07-01"]
model = GradientBoostingRegressor(random_state=42)
model.fit(train[features], train["revenue"])
pred = model.predict(test[features])
print("MAE:", mean_absolute_error(test["revenue"], pred))2. Đọc sai số bằng ngôn ngữ kinh doanh
MAE (sai số tuyệt đối trung bình) cho biết mô hình lệch bao nhiêu đồng mỗi tuần mỗi cửa hàng. MAPE (sai số phần trăm trung bình) cho biết lệch bao nhiêu phần trăm, tiện để so giữa cửa hàng lớn và nhỏ, nhưng sẽ méo khi doanh thu thực tế gần 0. Hãy luôn đặt cạnh sai số của baseline. Câu báo cáo tốt có dạng: "Mô hình lệch trung bình 8% so với 14% của cách dùng tuần cùng kỳ năm trước." Câu "độ chính xác 92%" thì khó kiểm chứng và dễ gây hiểu nhầm.
3. Xem biến nào đang tạo ra dự báo
Với mô hình dạng cây, xem feature_importances_ để biết biến nào ảnh hưởng nhiều. Nếu cờ khuyến mãi và doanh thu tuần trước chiếm phần lớn, kết quả hợp lý với trực giác kinh doanh. Nếu một biến lạ như mã đơn hàng đứng đầu, rất có thể có lỗi trong dữ liệu đầu vào.
VI. Bước 4: Đưa kết quả dự báo lên dashboard Power BI
Mô hình không có giá trị nếu chỉ nằm trong notebook. Người ra quyết định cần thấy dự báo cạnh số thực tế, trên dashboard họ đã mở hằng ngày.
1. Ghi kết quả về bảng riêng và nối vào Semantic Model
Cho script Python ghi kết quả vào bảng fact_forecast gồm store_id, week_start, forecast_revenue, lower_bound, upper_bound, model_version, run_date. Trong Power BI, nối bảng này với dim_store và dim_date giống mọi bảng fact khác. Cột model_version đáng giữ lại vì khi số liệu bị hỏi, bạn cần biết con số đó từ phiên bản mô hình nào.
2. Measure so sánh dự báo và thực tế
Forecast Gap % =
DIVIDE ( [Actual Revenue] - [Forecast Revenue], [Forecast Revenue] )Trên dashboard, đặt đường dự báo và dải lower_bound đến upper_bound cạnh đường thực tế, thêm bảng xếp hạng cửa hàng lệch dự báo nhiều nhất để trưởng vùng biết nên gọi cửa hàng nào trước.
3. Cập nhật tự động và cảnh báo
Đặt lịch chạy script sau khi dữ liệu bán hàng tuần trước đã chốt, rồi đặt scheduled refresh cho semantic model trong Power BI Service. Với cảnh báo, tạo KPI card hoặc gauge hiển thị Forecast Gap %, rồi bật data alert trên tile đó để nhận thông báo khi vượt ngưỡng, ví dụ lệch quá 15%. Ngưỡng này nên do người dùng nghiệp vụ chọn, không phải do người làm mô hình.
VII. Predictive Analytics trong hệ thống Agentic AI Analytics
Trong Agentic AI Analytics, bốn bước ở trên không còn do một người làm tuần tự. Mỗi bước có thể giao cho một AI Agent, tức một chương trình AI tự thực hiện chuỗi thao tác trên dữ liệu và công cụ, thay vì chỉ trả lời một câu hỏi rồi dừng. Chương trình của MDA thiết kế hệ thống 14 AI Agents chuyên biệt, hoạt động qua giao thức MCP (Model Context Protocol, cách để agent gọi công cụ và dữ liệu theo chuẩn chung) trên hệ sinh thái Microsoft Fabric và Power BI, luôn có con người kiểm soát ở các chốt chặn.
1. Phân vai giữa agent và con người
Agent làm tốt những việc lặp lại và có quy tắc rõ: chạy lại pipeline mỗi tuần, tạo biến trễ, huấn luyện lại mô hình, ghi fact_forecast, làm mới dashboard và gửi tóm tắt. Con người giữ những quyết định cần hiểu bối cảnh: chốt câu hỏi kinh doanh, duyệt danh sách biến, chấp nhận hay từ chối mô hình mới sau backtest, và quyết định có phát hành dự báo cho trưởng vùng hay không. Semantic Model đứng giữa, định nghĩa "doanh thu" là gì, tính trước hay sau hoàn trả, để agent không phải đoán.
Lý do cần các chốt chặn có cơ sở nghiên cứu. Bộ benchmark PredictiQ gồm 1130 truy vấn phân tích dự đoán, lấy từ 44 bộ dữ liệu thực tế thuộc 8 lĩnh vực [1]. Nhóm tác giả đánh giá 12 LLM nổi tiếng trên bộ này [1] và kết luận các LLM hiện tại vẫn đối mặt nhiều thách thức đáng kể khi phân tích dự đoán [1]. Việc tạo và kiểm tra các truy vấn tốn 300 giờ công của con người [1], cho thấy kiểm chứng thủ công vẫn là phần nặng ký. Nghĩa là bạn có thể giao việc cho agent, nhưng chưa nên giao luôn quyền tin kết quả.
2. Cách kiểm chứng kết quả dự đoán do AI tạo ra
Hãy coi dự báo do agent tạo ra như bài của một đồng nghiệp mới: cần xem lại trước khi ký. Bốn việc kiểm tra thiết thực:
Backtest theo thời gian: cho mô hình dự báo lại những tuần đã biết kết quả (walk-forward), rồi so sai số với baseline. Nếu không thắng baseline ổn định qua nhiều tuần, đừng phát hành.
Đối chiếu với nguồn độc lập: tổng dự báo của các cửa hàng có khớp bậc độ lớn với kế hoạch tài chính và số thực tế các kỳ trước không. Một cửa hàng dự báo gấp ba lần lịch sử cần được hỏi lại.
Đọc code agent đã sinh: kiểm tra cách chia train và test có theo thời gian không, biến nào được đưa vào, bộ lọc ngày có đúng không, và có biến nào chứa thông tin từ tương lai không.
Ghi log phiên bản: lưu model_version, tham số, khoảng dữ liệu huấn luyện để lúc có tranh luận về con số, bạn truy lại được nguồn gốc.
Một điểm đáng lưu ý khi dùng LLM làm người chấm: trong nghiên cứu trên, GPT-4Turbo đạt tỷ lệ đồng thuận trung bình 90,5% với chuyên gia con người, nên được chọn làm bộ chấm chính [1]. Tức là ngay cả bộ chấm tự động tốt cũng không khớp hoàn toàn với người, và 9,5% còn lại đủ lớn để bạn vẫn cần mắt người ở những quyết định quan trọng.
VIII. Lỗi thường gặp khi làm Predictive Analytics
1. Rò rỉ dữ liệu
Rò rỉ dữ liệu (data leakage) xảy ra khi mô hình được học từ thông tin mà thực tế bạn chưa có tại thời điểm dự đoán. Ví dụ đưa "doanh thu cả tháng" vào biến để dự đoán doanh thu tuần đầu tháng, hoặc dùng trung bình trượt có bao gồm chính tuần cần dự đoán. Dấu hiệu nhận biết: điểm số trên tập kiểm tra đẹp bất thường, nhưng khi chạy thật thì sai số tăng vọt. Cách phòng: với mỗi biến, tự hỏi "vào sáng thứ Hai khi chạy dự báo, mình có số này chưa?"
2. Overfitting
Overfitting là khi mô hình học thuộc dữ liệu cũ, kể cả nhiễu, nên điểm trên tập huấn luyện rất cao nhưng kém trên dữ liệu mới. Hay gặp khi có quá nhiều biến so với số tuần dữ liệu, ví dụ 200 biến cho 100 tuần. Giảm số biến, giới hạn độ sâu của cây, và luôn đánh giá trên tập kiểm tra nằm sau về mặt thời gian.
3. Dữ liệu lệch và thay đổi theo thời gian
Với bài toán phân loại như dự đoán khách rời bỏ, nhóm khách rời bỏ thường chỉ vài phần trăm tổng số. Mô hình đoán "không ai rời bỏ" vẫn đạt độ chính xác cao nhưng vô dụng, nên hãy xem Recall và Precision thay vì accuracy. Ngoài ra, hành vi mua thay đổi sau khi có đối thủ mới, đổi chính sách giá hay sau dịch chuyển kênh bán, nên mô hình cần được theo dõi sai số hằng tuần và huấn luyện lại khi sai số vượt ngưỡng.
4. Giao con số mà không giao ngữ cảnh
Một dự báo không kèm khoảng sai số và giả định dễ bị hiểu như cam kết. Luôn đưa dải trên và dải dưới, ghi rõ giả định như "không có khuyến mãi bất thường", để người dùng biết khi nào nên điều chỉnh.
IX. Câu hỏi thường gặp về Predictive Analytics
1. Predictive Analytics khác gì báo cáo doanh số thông thường?
Báo cáo thông thường cho biết chuyện đã xảy ra. Predictive Analytics ước tính điều sẽ xảy ra dựa trên dữ liệu quá khứ [1], kèm mức sai số để bạn cân nhắc khi ra quyết định.
2. Tôi cần biết lập trình mới làm được không?
Không bắt buộc cho mọi trường hợp, nhưng SQL và một chút Python sẽ giúp bạn kiểm soát được quy trình. Nếu chỉ dùng công cụ có sẵn mà không hiểu dữ liệu vào, bạn khó phát hiện lỗi.
3. Cần bao nhiêu dữ liệu để bắt đầu?
Tùy bài toán. Với dự báo theo tuần có mùa vụ, hai đến ba năm giúp mô hình nhìn thấy nhiều hơn một chu kỳ. Với phân loại khách hàng, cần đủ số mẫu ở cả nhóm hiếm lẫn nhóm phổ biến.
4. Nên bắt đầu với thuật toán nào?
Baseline đơn giản trước, sau đó hồi quy tuyến tính hoặc Gradient Boosting cho bài toán hồi quy, Logistic Regression cho phân loại, ETS hoặc ARIMA cho chuỗi thời gian. Chỉ chuyển sang mô hình phức tạp hơn khi nó thắng rõ ràng trên tập kiểm tra.
5. Làm sao biết mô hình đủ tốt để dùng?
So sai số với baseline trên nhiều tuần liên tiếp theo thời gian, và hỏi người dùng nghiệp vụ mức sai số nào họ chấp nhận được. Mô hình "tốt" là mô hình giúp quyết định tốt hơn cách đang dùng.
6. Tôi có thể nhờ LLM tự làm toàn bộ phân tích dự đoán không?
Chưa nên giao hoàn toàn. Nghiên cứu trên 12 LLM với bộ PredictiQ cho thấy các LLM hiện tại vẫn gặp nhiều thách thức đáng kể ở phân tích dự đoán [1]. Hãy dùng LLM hay agent để tăng tốc, và giữ bước kiểm chứng cho con người.
7. Dự báo xong thì cập nhật bao lâu một lần?
Theo nhịp ra quyết định. Nếu trưởng vùng chốt nhập hàng mỗi tuần, chạy dự báo mỗi tuần. Đồng thời theo dõi sai số để biết khi nào cần huấn luyện lại.
8. Predictive Analytics có liên quan gì đến business intelligence?
Rất gần. Dự báo chỉ có ích khi đến tay người dùng qua dashboard và quy trình BI. Đã có hướng nghiên cứu dùng machine learning để hỗ trợ ra quyết định ngay trên nền SQL-based analytics trong BI [2].
X. Kết luận
Predictive Analytics là việc dùng dữ liệu quá khứ để ước tính điều sắp xảy ra [1], và phần lớn công sức nằm ở chuẩn bị dữ liệu, chọn baseline, kiểm chứng và đưa kết quả đến đúng người. Bốn bước tiền xử lý, chọn thuật toán, huấn luyện và đưa lên Power BI là đủ để bạn có dự báo đầu tiên chạy hằng tuần. Khi thêm AI Agent vào, hãy giữ các chốt duyệt của con người ở những chỗ quyết định.
Bước đầu tiên làm được ngay trong tuần này: chọn một chỉ số bạn đang báo cáo hằng tuần, viết lại thành câu hỏi dự báo có người dùng cụ thể, rồi tính một baseline bằng SQL. Khi đã có baseline, bạn có thước đo để đánh giá mọi mô hình sau đó. Nếu muốn đọc thêm các bài về dữ liệu và BI, bạn có thể xem Blog Mastering Data Analytics.
Lưu ý: phần dưới đây giới thiệu chương trình đào tạo của Mastering Data Analytics.
📚 Bắt đầu sự nghiệp Analytics vững vàng trong kỷ nguyên AI
Mastering Data Analytics (MDA) là một trong những đơn vị đào tạo phân tích dữ liệu tại Việt Nam, mang chương trình Agentic AI Analytics đến với người học. Sau hơn 6 năm đào tạo phân tích dữ liệu, MDA đã đồng hành cùng 3.000+ học viên và 250+ doanh nghiệp lớn như Heineken, Prudential, P&G, AEON, BIDV, Coca-Cola, Unilever. Điểm khác biệt của MDA không nằm ở những lời hứa kiểu '5 phút phân tích data với ChatGPT' hay 'vibe coding dashboard'. Chúng tôi rèn đúng bộ ba tạo nên lợi thế cạnh tranh thật sự thời AI: tư duy phân tích hệ thống, chuyên môn vững chắc và năng lực điều phối AI Agents.
Khám phá chương trình: Agentic AI Analytics, Finance Analytics
Tư vấn lộ trình miễn phí qua Zalo: 0961 48 66 48
Fanpage: Mastering Data Analytics
Nguồn tham khảo
[1] Large Language Models for Predictive Analysis: How Far Are They?. https://arxiv.org/pdf/2505.17149
[2] Predictive Analytics in Business Intelligence -How machine learning .... https://www.researchgate.net/publication/389712458_Predictive_Analytics_in_Business_Intelligence_-How_machine_learning_models_can_enhance_decision-_making_using_SQL-based_analytics
Bình luận