Dự báo AI: mua model theo cân là lỗ

Một playbook triển khai forecasting pipeline: thử nhỏ, đo đúng, biết lúc nào scale và lúc nào nên dừng trước khi model mới nhất làm cháy ngân sách.

Bụi Wire

2026-06-21

Một cảnh khá quen ở team Việt Nam: sales hỏi tháng sau nhập bao nhiêu hàng, finance hỏi cashflow quý tới có hụt không, vận hành hỏi khi nào tăng ca. Cả phòng quay sang team data, và ai đó hồn nhiên thả vào Slack: dùng foundation model mới nhất cho forecasting đi anh.

Nghe rất có khí thế. Nhưng nếu bạn là tech lead phải ký vào pipeline chạy thật, câu hỏi không phải là model nào đang được nhắc nhiều nhất. Câu hỏi là: với dữ liệu hiện có, độ sai nào chấp nhận được, chi phí vận hành ra sao, và khi forecast sai thì ai phát hiện trước khách hàng?

Nói thẳng ra thì: forecasting bằng AI không nên được mua như mua rau theo cân ngoài chợ. Thấy sạp nào treo bảng giá mềm hơn hoặc quảng cáo tươi hơn là bê về hết, rất dễ dính cân điêu ở khâu production.

Sơ đồ minh họa cho bài Dự báo AI: mua model theo cân là lỗ

Sơ đồ tóm tắt ý chính của bài viết.

Mục tiêu: đừng chọn model, hãy chọn quy trình ra quyết định

Nguồn cảm hứng chính ở đây là một workflow dùng TimeCopilot để dựng pipeline dự báo end-to-end: chuẩn bị dữ liệu dạng panel, so sánh nhiều nhóm model, chạy rolling cross-validation, đo bằng nhiều metric, tạo forecast có khoảng bất định, rồi phát hiện anomaly.

Nhưng điểm đáng đem về không phải là tên tool. Điểm đáng đem về là cách đặt hàng rào cho quyết định kỹ thuật.

Một pipeline forecasting đáng tin nên trả lời được 5 câu:

Dữ liệu có đủ sạch để dự báo chưa?
Baseline thống kê đơn giản đang làm được tới đâu?
Foundation model — model nền tảng được train rộng trước — có thắng đủ rõ để đáng thêm độ phức tạp không?
Forecast có nói rõ vùng bất định không, hay chỉ ném ra một con số tròn trịa?
Khi dữ liệu có điểm bất thường, pipeline báo động hay âm thầm học sai?

Nếu sau bài này bạn đổi một cách nghĩ, mình muốn đó là: model mới chỉ là một ứng viên trong phiên chợ, còn pipeline đánh giá mới là cái cân của bạn.

Checklist một buổi: thử nhỏ nhưng đủ đau

Bạn không cần dựng ngay hệ thống lớn. Một buổi chiều là đủ để làm bản thử có giá trị, miễn là đừng thử kiểu demo đẹp rồi tự vỗ tay.

Chuẩn bị tối thiểu:

Một chuỗi thời gian thật từ business: đơn hàng, doanh thu, traffic, tồn kho, ticket support.
Một chuỗi phụ có tính mùa vụ hoặc biến động rõ, nếu có nhiều nhóm sản phẩm/cửa hàng thì càng tốt.
Một baseline đơn giản: seasonal naive, ARIMA, ETS, Prophet hoặc model thống kê tương đương.
Một ứng viên foundation model cho time series, ví dụ nhóm Chronos hoặc TimesFM nếu hạ tầng cho phép.
Một bộ metric: MAE, RMSE, MAPE.
MAE: sai số tuyệt đối trung bình, dễ hiểu với business.
RMSE: phạt nặng lỗi lớn, hữu ích khi sai to là rất đau.
MAPE: sai số phần trăm, tiện so giữa các series nhưng dễ méo khi giá trị thật gần 0.
Một ngưỡng dừng: nếu model phức tạp không cải thiện rõ rệt trên rolling test, không scale.

Rolling cross-validation là cách kiểm tra bằng nhiều lát thời gian trượt dần, thay vì train một lần rồi test một lần. Với forecasting, cách này thực tế hơn vì tháng 3 không giống tháng 9, mùa sale không giống mùa thấp điểm.

Ví dụ cụ thể: giả sử team bạn dự báo nhu cầu cho 20 SKU theo tháng. Đừng lấy 3 năm dữ liệu, train đến tháng cuối rồi khoe metric. Hãy tạo nhiều cửa sổ: train đến tháng 18 dự báo 3 tháng tới, train đến tháng 21 dự báo 3 tháng tới, train đến tháng 24 dự báo 3 tháng tới. Nếu model chỉ thắng ở một cửa sổ đẹp trời, đó chưa phải năng lực ổn định.

Các bước triển khai: từ sạp thử đến quầy bán thật

Bước 1: Chuẩn hóa dữ liệu thành panel

Panel dataset là dữ liệu nhiều chuỗi cùng cấu trúc, ví dụ mỗi cửa hàng hoặc mỗi SKU là một series riêng. Thường bạn cần ba cột lõi:

unique_id: mã chuỗi, như SKU_A hoặc store_01
ds: mốc thời gian
y: giá trị cần dự báo

Điểm hay của panel là bạn đánh giá được model trên nhiều kiểu hành vi, không bị một chuỗi đẹp che mắt.

Bản kiểm tra nhanh:

unique_id | ds         | y
sku_a     | 2025-01-01 | 120
sku_a     | 2025-02-01 | 135
sku_b     | 2025-01-01 | 42
sku_b     | 2025-02-01 | 39

Nếu dữ liệu thiếu tháng, đổi đơn vị, hoặc có ngày bị nhập nhầm, xử lý trước. Forecasting pipeline không phải máy rửa rau; dữ liệu bẩn bỏ vào thì model chỉ giúp bạn bẩn có vẻ khoa học hơn.

Bước 2: Chạy leaderboard có baseline

Đừng cho foundation model vào thi một mình. Hãy đặt cạnh model thống kê và model heuristic đơn giản. Leaderboard nên có ít nhất:

MAE trung bình theo toàn bộ series
RMSE trung bình
MAPE nếu dữ liệu không có quá nhiều giá trị gần 0
Metric theo từng nhóm quan trọng, không chỉ aggregate

Một lỗi mình thấy nhiều team mắc: model thắng trung bình nhưng thua nặng ở nhóm doanh thu cao. Nếu SKU nhỏ sai ồn ào mà SKU chủ lực sai âm thầm, dashboard tổng sẽ ru ngủ bạn.

Bước 3: Xuất forecast có khoảng bất định

Prediction interval là khoảng dự báo, ví dụ xác suất cao giá trị thật sẽ nằm trong vùng này. Trong vận hành, khoảng này đôi khi quan trọng hơn điểm dự báo.

Nếu forecast nói tháng sau bán 10.000 đơn, business sẽ hỏi nhập bao nhiêu hàng. Nếu pipeline nói thêm khoảng 80% là 8.800–11.500 và khoảng 95% là 7.900–12.700, quyết định tồn kho sẽ khác hẳn.

Một con số đơn lẻ nhìn gọn, nhưng khoảng bất định mới cho bạn biết có nên kỳ kèo thêm ngân sách buffer hay không.

Bước 4: Gắn anomaly detection trước khi tin forecast

Anomaly detection là phát hiện điểm bất thường, như traffic tăng vọt vì bot, doanh thu tụt vì lỗi thanh toán, hoặc đơn hàng tăng do campaign ngoài kế hoạch.

Đừng chỉ dùng anomaly để vẽ chấm đỏ trên chart. Hãy quyết định hành động:

anomaly do lỗi dữ liệu → loại khỏi train hoặc sửa nguồn
anomaly do sự kiện thật → thêm nhãn sự kiện nếu có
anomaly chưa rõ nguyên nhân → forecast vẫn chạy nhưng gắn cờ độ tin cậy thấp

Điểm này rất operator: không phải phát hiện bất thường cho vui, mà để tránh model học nhầm một cú sốc thành mùa vụ.

Guardrail: tiêu chí scale và tiêu chí dừng

Một pipeline thử nghiệm nên có cửa ra rõ ràng. Mình hay dùng khung 2 cửa: scale nếu có tín hiệu vận hành, dừng nếu chỉ đẹp trên notebook.

| Quyết định | Dấu hiệu nên làm | Dấu hiệu nên chậm lại |
|---|---|---|
| Scale model mới | Thắng baseline qua nhiều rolling windows | Chỉ thắng ở một giai đoạn ngắn |
| Dùng GPU model | Cải thiện đủ để bù chi phí và latency | Metric nhích nhẹ nhưng vận hành nặng hơn |
| Bật anomaly workflow | Có owner xử lý cảnh báo | Alert nhiều nhưng không ai chịu trách nhiệm |
| Đưa LLM agent vào giải thích | Business cần narrative đều đặn | Team dùng LLM để che metric yếu |

Ở đây có một chi tiết hay từ các workflow AI khác: bài về CodeGen không dừng ở generate code, mà thêm syntax check, safety check, unit test và rerank. Với forecasting cũng vậy. Đừng dừng ở generate forecast. Hãy thêm validation, ranking, interval, anomaly flag và artifact export.

Tương tự, các bài local-first nhắc mình một điều: nếu dữ liệu nhạy cảm, nhất là doanh thu, browsing, hành vi người dùng, bạn cần quyết định rõ phần nào chạy local, phần nào gọi API, phần nào được log. Forecasting không miễn nhiễm với bài toán quyền truy cập. Nếu team đông, RBAC — phân quyền theo vai trò — nên có mặt trước khi dashboard dự báo trở thành bảng soi doanh thu toàn công ty.

Pitfall hay gặp: forecast đúng metric, sai quyết định

Có ba cái bẫy đáng né.

Một là chọn metric vì đẹp. MAPE nhìn dễ trình bày, nhưng nếu y gần 0 thì phần trăm sai có thể nhảy loạn. RMSE hữu ích khi lỗi lớn đáng sợ, nhưng có thể khiến model quá ám ảnh vài cú spike.

Hai là bỏ qua frequency. Dữ liệu ngày, tuần, tháng không chỉ khác số dòng. Nó khác hành vi. Dự báo traffic theo giờ và dự báo doanh thu theo tháng là hai món khác nhau, đừng nhét chung một cấu hình rồi mong công bằng.

Ba là tin forecast mà không có backtest theo business event. Sale lớn, nghỉ lễ, thay đổi giá, lỗi tracking, đổi kênh marketing — những thứ này có thể làm chuỗi thời gian gãy nhịp. Nếu không annotate sự kiện, model sẽ đoán trong bóng tối.

Nếu là mình, mình sẽ triển khai thế này

Với một team builder nhỏ, mình sẽ không bắt đầu bằng việc hỏi dùng TimeCopilot, Chronos, TimesFM hay Prophet. Mình sẽ bắt đầu bằng decision memo một trang:

Dự báo cái gì, horizon bao xa?
Sai bao nhiêu thì business vẫn chịu được?
Baseline hiện tại là gì?
Rolling cross-validation chạy trên mấy cửa sổ?
Metric chính là gì, metric phụ là gì?
Anomaly được xử lý bởi ai?
Khi nào model mới được lên prod?
Khi nào phải rollback về baseline?

Sau đó mới chọn tool. TimeCopilot đáng chú ý vì nó gom nhiều kiểu model vào một interface, tiện cho thử nghiệm có kỷ luật. Nhưng giá trị thật nằm ở việc bạn ép mọi ứng viên đi qua cùng một cái cân: cùng dữ liệu, cùng horizon, cùng rolling windows, cùng metric, cùng tiêu chí dừng.

Forecasting pipeline tốt không phải pipeline luôn đoán đúng. Nó là pipeline biết nói: tôi tự tin đến đâu, tôi sai ở đâu, và khi thị trường có mùi lạ thì tôi giơ tay trước.

Chốt lại: đi chợ model thì cứ trả giá thoải mái, nhưng nhớ mang theo cái cân của mình — không thì về nhà mới biết bó rau AI bị nhẹ ký.

---
Bụi Wire — nghiện đọc release notes lúc 2 giờ sáng