Tôi giấu bốn cái bẫy trong bài toán dự báo: Kết quả từ bốn trợ lý AI

Một thử nghiệm có kiểm soát đối với Gemini, DeepSeek, ChatGPT và Claude về các vấn đề rò rỉ dữ liệu (data leakage), độ trễ báo cáo (reporting delays), hiệu ứng sau khuyến mãi (promotion effects) và gãy cấu trúc (structural breaks).

Khi yêu cầu một trợ lý AI xây dựng mô hình dự báo, kết quả trả về thường có vẻ hoàn chỉnh đến mức đáng tin cậy: tiền xử lý dữ liệu, phân chia tập huấn luyện/kiểm tra (train–test split), một bộ ước lượng đã khớp (fitted estimator), cùng một vài chỉ số đánh giá cơ bản.

Mã nguồn chạy mượt mà, các con số trông hợp lý và người dùng rất dễ dàng chấp nhận kết quả đó.

Tuy nhiên, mỗi bước trong quy trình trên đều ẩn chứa một quyết định kỹ thuật cốt lõi: Phương pháp chia dữ liệu có phản ánh đúng ngữ cảnh triển khai thực tế của mô hình hay không? Mọi đặc trưng (features) có thực sự sẵn sàng tại thời điểm đưa ra dự báo? Và cơ bản hơn: các con số được báo cáo có thực sự được sinh ra từ chính đoạn mã mà mô hình cung cấp?

Không có lỗi nào trong số này khiến chương trình dừng đột ngột. Đó là trọng tâm cần kiểm chứng khi đánh giá các thiết lập mặc định mà trợ lý AI lựa chọn.

Để xác định mức độ xử lý các quyết định này của trợ lý AI, bước khởi đầu là một trường hợp đơn giản: bài toán dự báo doanh số bán lẻ, nơi sai lầm hiển nhiên nhất là xáo trộn ngẫu nhiên dữ liệu chuỗi thời gian (shuffled train–test split), vô tình để mô hình nhìn trước tương lai.

Mọi mô hình đều vượt qua bài toán này. Không có hiện tượng xáo trộn, không có rò rỉ dữ liệu và không có gì cần sửa chữa.

Đây là tín hiệu tốt, nhưng cũng tiềm ẩn hoài nghi. Nguyên tắc “không xáo trộn dữ liệu chuỗi thời gian” xuất hiện trong vô số tài liệu hướng dẫn. Vượt qua bài kiểm tra đó chỉ chứng minh các mô hình đã học thuộc tài liệu, chứ không đồng nghĩa với việc chúng thực sự suy luận về cách một mô hình dự báo vận hành trên thực tế.

Vì vậy, một bài kiểm tra phức tạp hơn đã được thiết lập. Vẫn cùng dạng bài toán, nhưng tích hợp các cạm bẫy ít phổ biến hơn, bắt nguồn từ các sự cố thực tế trong môi trường production: vấn đề ẩn giấu trong mô tả cột dữ liệu, độ trễ báo cáo thông tin, hoặc ngay trong bản thân phân phối dữ liệu mà không có hướng dẫn mẫu nào chỉ ra sẵn.

Bài viết này đưa bài toán nâng cao đó cho bốn mô hình hàng đầu hiện nay. Tập dữ liệu chứa bốn cái bẫy được cài cắm có chủ đích. Lời nhắc (prompt) mô tả trung thực từng cột và hoàn toàn không gợi ý những điểm bất thường cần tìm. Nhiệm vụ nhận diện vấn đề thuộc về chính mô hình.

Và vì một bản báo cáo thuyết phục không đồng nghĩa với một kết quả chính xác, toàn bộ mã nguồn đều được thực thi lại độc lập. Một con số chỉ có giá trị khi đoạn mã được bàn giao thực sự tạo ra nó.

Lần thử đầu tiên: Cái bẫy mà mọi mô hình đều tránh được

Bài kiểm tra đầu tiên được thiết kế tương đối đơn giản: Một nhà bán lẻ muốn xây dựng mô hình dự báo doanh số của tuần tiếp theo và muốn biết mô hình hoạt động ra sao trên những tuần chưa từng diễn ra. Yêu cầu đó định hình phương pháp đánh giá: Mô hình phải học từ giai đoạn trước và kiểm tra trên giai đoạn sau. Phân chia ngẫu nhiên sẽ khiến mô hình học từ các tuần xuất hiện sau tuần cần dự báo.

Dữ liệu doanh số 3 năm theo tuần được tạo ra từ một quy trình xác định: xu hướng tuyến tính (linear trend), tính mùa vụ theo năm (yearly seasonality), hiệu ứng khuyến mãi và nhiễu ngẫu nhiên. Mọi biến dự báo đều khả dụng tại thời điểm suy luận, do đó sai sót duy nhất có thể xảy ra là phương pháp chia dữ liệu. Lời nhắc nêu rõ ngữ cảnh ứng dụng của mô hình mà không áp đặt phương pháp phân tách cụ thể.

Tất cả các mô hình đều tôn trọng trình tự thời gian. Mỗi mô hình đều giữ lại các tuần gần nhất làm tập kiểm tra hoặc sử dụng phương pháp đánh giá cuốn chiếu (forward-moving evaluation).

Một bài kiểm tra mà mọi ứng viên đều vượt qua thì không đo lường được điều gì. Vì vậy, bài toán cần phải khó hơn.

Bài kiểm tra thực tế: Bốn cạm bẫy tiềm ẩn

Tập dữ liệu bao gồm 156 tuần bán lẻ, từ tháng 1 năm 2023 đến tháng 12 năm 2025. Doanh số thể hiện xu hướng tăng dần, chu kỳ mùa vụ hàng năm và tăng đột biến trong các đợt khuyến mãi định kỳ, đi kèm với nhiễu ngẫu nhiên.

Bốn cạm bẫy được thiết kế bên trong dữ liệu, mô phỏng các vấn đề đặc thù trong ngành bán lẻ:

1. Cột dữ liệu biết trước đáp án: Tập dữ liệu chứa trường store_traffic (lượng khách đến cửa hàng trong tuần mục tiêu). Biến này có hệ số tương quan gần như tuyệt đối với doanh số. Tuy nhiên, lượng khách của tuần tới chưa hề tồn tại khi lập dự báo cho tuần tới. Một mô hình sử dụng biến này sẽ đạt điểm số vượt trội khi đánh giá nhưng hoàn toàn vô dụng trên thực tế.

2. Doanh số bị trễ báo cáo: Dữ liệu doanh số chỉ được tổng hợp và ghi nhận hai tuần sau khi tuần đó kết thúc. Do đó, một dự báo được đưa ra vào đầu tuần không thể sử dụng doanh số của hai tuần liền trước. Giá trị đã biết gần nhất có độ trễ ba tuần. Việc xây dựng đặc trưng trễ (lag features) theo cách thông thường với bước trễ shift(1) sẽ âm thầm sử dụng dữ liệu chưa hề tồn tại.

3. Khuyến mãi vay mượn nhu cầu tương lai: Vào tuần ngay sau đợt khuyến mãi, doanh số thường sụt giảm do khách hàng đã tích trữ hàng hóa từ trước. Lịch khuyến mãi được lên kế hoạch trước, do đó trạng thái khuyến mãi của tuần trước là một đặc trưng hoàn toàn hợp lệ. Lời nhắc không đề cập đến hiệu ứng này; mô hình chỉ có thể phát hiện thông qua việc phân tích dữ liệu hoặc phân tích sai số (residual analysis).

4. Biến động cấu trúc thực tế: Vào giữa năm cuối cùng, một đối thủ cạnh tranh khai trương gần đó khiến mặt bằng doanh số sụt giảm vĩnh viễn. Không có cột nào thông báo sự kiện này. Mô hình ngoại suy xu hướng một cách mù quáng sẽ đánh giá quá cao doanh số của mọi tuần sau biến động, và dấu vết duy nhất chỉ nằm ở sai số dự báo của chính nó.

Hai cạm bẫy đầu tiên kiểm tra khả năng suy luận thời gian: biến nào được biết, và tại thời điểm nào. Hai cạm bẫy sau kiểm tra xem mô hình có thực sự phân tích dữ liệu hay chỉ tối ưu hóa điểm số đánh giá cuối cùng.

Mỗi mô hình nhận được tập dữ liệu cùng lời nhắc nguyên văn sau:

Hãy xây dựng một mô hình Python để dự báo doanh số hàng tuần cho một nhà bán lẻ bằng cách sử dụng tập dữ liệu đính kèm. Mỗi hàng đại diện cho một tuần và các hàng được sắp xếp theo thứ tự thời gian. Nhà bán lẻ sẽ huấn luyện mô hình trên dữ liệu lịch sử và dùng nó để dự báo cho tuần kế tiếp. Lịch khuyến mãi được biết trước. Số liệu doanh số chỉ khả dụng hai tuần sau khi tuần đó kết thúc.

Các cột dữ liệu:
– week_start: ngày bắt đầu của tuần mục tiêu
– week_index: số thứ tự tuần liên tiếp
– annual_sin, annual_cos: đặc trưng chu kỳ mùa vụ theo năm
– promotion_planned: có kế hoạch khuyến mãi trong tuần mục tiêu hay không
– store_traffic: lượng khách đến cửa hàng trong tuần mục tiêu
– sales: số lượng đơn vị bán ra trong tuần mục tiêu, biến mục tiêu cần dự báo

Yêu cầu bao gồm chuẩn bị dữ liệu, huấn luyện mô hình và đánh giá hiệu năng ước tính trên các tuần tương lai. Báo cáo chỉ số MAE.

Kết quả bàn giao:
1. Toàn bộ mã nguồn Python hoàn chỉnh, chạy được trong một tệp duy nhất, chính xác như bạn đã chạy (không lược bỏ, không dùng placeholder).
2. Đầu ra được in ra của đoạn mã, bao gồm chỉ số MAE.
3. Danh sách đặc trưng cuối cùng được mô hình sử dụng.
4. Tóm tắt ngắn gọn kết quả và các quan sát về dữ liệu.

Mọi phát biểu trong lời nhắc đều chính xác nhưng không chỉ định cách xử lý thông tin. Bốn yêu cầu bàn giao giúp mọi tuyên bố đều có thể kiểm chứng được.

Tiêu chuẩn đánh giá thành công

Các tiêu chí được xác định trước khi xem xét phản hồi. Mỗi cạm bẫy được đánh giá dựa trên mô hình cuối cùng, không dựa vào phần diễn giải văn bản bên ngoài:

• Lượng khách cửa hàng (Store traffic): Đạt nếu store_traffic của tuần mục tiêu không phải là đầu vào của mô hình. Thất bại nếu biến này được sử dụng, dù có kèm theo cảnh báo.
• Độ trễ báo cáo (Reporting delay): Đạt nếu các đặc trưng dựa trên doanh số chỉ dùng các giá trị có độ trễ ít nhất ba tuần. Thất bại nếu bất kỳ đặc trưng nào sử dụng doanh số của hai tuần gần nhất.
• Sụt giảm sau khuyến mãi (Promotion dip): Đạt nếu khuyến mãi tuần trước được đưa vào làm đặc trưng, hoặc sự sụt giảm này được phát hiện. Thất bại nếu không thực hiện cả hai.
• Đối thủ cạnh tranh (Competitor): Đạt nếu sự dịch chuyển mức doanh số (level shift) được phát hiện và xử lý, hoặc ít nhất được báo cáo rõ ràng. Thất bại nếu sai số sau biến động bị bỏ qua không xem xét.

Một lời cảnh báo không được xem là giải pháp. Nếu phần tóm tắt ghi “đặc trưng này có thể không khả dụng” nhưng mô hình vẫn nạp nó vào huấn luyện, cạm bẫy đó bị tính là thất bại.

Một tiêu chí tối cao khác: tính trung thực của đầu ra. Toàn bộ mã nguồn được thực thi lại trên cùng một tệp dữ liệu. Các chỉ số được báo cáo chỉ được công nhận nếu đoạn mã tái hiện chính xác con số đó.

Ngưỡng MAE tối ưu lý thuyết

Vì dữ liệu được sinh lập trình, thành phần bất khả tri (không thể dự báo) được biết chính xác. Điều này cung cấp một chặn dưới tuyệt đối cho sai số nhằm phát hiện những kết quả tốt một cách phi thực tế.

Doanh số mỗi tuần gồm phần có thể dự báo cộng với nhiễu ngẫu nhiên:

$$ ext{sales}_t = mu_t + arepsilon_t$$

Trong đó $mu_t$ chứa tất cả các yếu tố mô hình có thể học: xu hướng, mùa vụ, khuyến mãi, hiệu ứng đối thủ. Nhiễu $arepsilon_t$ được lấy mẫu độc lập mỗi tuần, do đó không đặc trưng nào có thể dự báo được nó. Với mô hình tối ưu nhất, chỉ số MAE kỳ vọng chính là kỳ vọng của $|arepsilon_t|$, tuân theo phân phối bán chuẩn (half-normal distribution):

$$mathbb{E}[|arepsilon_t|] = sigma sqrt{rac{2}{pi}} pprox 0.798 sigma$$

Với $sigma = 70$:

$$mathbb{E}[ ext{MAE}] pprox 0.798 imes 70 pprox 56$$

Hệ số 0.798 lý giải tại sao MAE thấp hơn độ lệch chuẩn: độ lệch chuẩn bình phương các sai số trước khi lấy trung bình nên phạt nặng các sai số lớn, trong khi MAE xử lý sai số tuyến tính. Giá trị 56 là kỳ vọng lý thuyết. Trên một khung kiểm tra cụ thể gồm $n$ tuần, sai số chuẩn của MAE thực tế là:

$$ ext{SE} = rac{sigma sqrt{1 – 2/pi}}{sqrt{n}} pprox rac{0.603 sigma}{sqrt{n}}$$

Trong 52 tuần cuối của tập dữ liệu này, quy trình sinh dữ liệu gốc đạt MAE thực tế khoảng 49: thấp hơn kỳ vọng 56 khoảng một độ lệch chuẩn, hoàn toàn nằm trong dao động ngẫu nhiên. Không một phương pháp dự báo hợp lệ nào có thể đạt kết quả tốt hơn đáng kể trên khung dữ liệu đó. Một chỉ số MAE báo cáo thấp hơn nhiều so với ngưỡng này không phản ánh một mô hình xuất sắc, mà là bằng chứng của việc mô hình nhìn thấy thông tin bị rò rỉ.

Các đối tượng thử nghiệm

Bốn mô hình tiên tiến nhận cùng một lời nhắc và tệp dữ liệu trong phiên hội thoại độc lập: Gemini Pro, DeepSeek, GPT-6 Sol và Claude Opus 5.5. Toàn bộ được kiểm thử qua giao diện trò chuyện tiêu chuẩn, phản ánh đúng cách người dùng vận hành trong thực tế.

Tổng quan kết quả

Nếu xếp hạng theo MAE được báo cáo, DeepSeek đứng đầu và GPT-6 Sol xếp cuối cùng. Nhưng nếu xếp hạng theo khả năng đưa vào vận hành thực tế (production-readiness), thứ tự đảo ngược hoàn toàn.

Hai trong số bốn điểm số được báo cáo nằm dưới ranh giới lý thuyết mà một dự báo trung thực có thể đạt tới. Điểm số 15 của DeepSeek là có thật nhưng bắt nguồn từ đặc trưng không tồn tại tại thời điểm dự báo. Con số 41 của Gemini không bắt nguồn từ việc thực thi mã: Gemini dán nhãn đầu ra là mô phỏng, trong khi mã nguồn thực tế sinh ra MAE bằng 87.

Bảng tổng hợp phản ánh chi tiết các tiêu chí:

• Gemini Pro: Thuật toán LightGBM; Đánh giá Holdout 12 tuần; Tránh biến store_traffic cùng tuần nhưng dùng trễ 1 tuần; Tôn trọng độ trễ báo cáo; Bỏ lỡ sụt giảm khuyến mãi và hiệu ứng đối thủ.
• DeepSeek: Tỷ lệ Sales / Traffic; Đánh giá Holdout 52 tuần; Dính bẫy store_traffic hoàn toàn; Không kiểm tra trễ báo cáo; Bỏ lỡ cả hai bẫy cấu trúc dữ liệu.
• GPT-6 Sol: Hồi quy Ridge; Đánh giá Walk-forward hàng tuần; Loại bỏ hoàn toàn store_traffic; Tôn trọng độ trễ báo cáo bằng mã kiểm tra; Bỏ lỡ sụt giảm khuyến mãi; Phát hiện dịch chuyển mức dữ liệu.
• Claude Opus 5.5: Hồi quy tuyến tính OLS; Đánh giá Walk-forward hàng tuần; Loại bỏ hoàn toàn store_traffic; Thiết lập unit test kiểm tra rò rỉ độ trễ; Phát hiện chính xác hiệu ứng sau khuyến mãi và đối thủ cạnh tranh.

Chỉ có một mô hình nhận diện được hiệu ứng sụt giảm sau khuyến mãi, và duy nhất một mô hình chẩn đoán bằng văn bản về tác động của đối thủ cạnh tranh. Hai cạm bẫy rò rỉ dữ liệu vốn có thể giải quyết bằng logic thời gian thuần túy được đa số xử lý tốt; nhưng hai cạm bẫy đòi hỏi quan sát dữ liệu thực nghiệm đều bị bỏ sót.

Lựa chọn thuật toán hầu như không tạo ra sự khác biệt. Ba trong bốn mô hình sử dụng mô hình tuyến tính, và hai mô hình hiệu quả nhất chỉ dùng hồi quy tuyến tính cổ điển không cần tinh chỉnh tham số phức tạp. Yếu tố phân hóa nằm ở thiết kế quy trình đánh giá, lựa chọn đặc trưng và việc phân tích sai số.

Bẫy 1: Sự cám dỗ từ biến rò rỉ

Ba mô hình đã loại trừ store_traffic. Mô hình duy nhất sử dụng nó lại nhận thức được đây là điều không nên làm.

DeepSeek xây dựng toàn bộ logic dựa trên một cột duy nhất đó:

rate = train[target].sum() / train[feature].sum()
test['prediction'] = rate * test[feature]

Mô hình báo cáo MAE 15.21 và đánh giá con số này là hợp lý. Ở phần cuối tóm tắt, mô hình ghi chú: nếu lưu lượng khách không được biết trước, nên thay thế bằng các đặc trưng khác. Tuy nhiên, lời nhắc ban đầu đã nêu rõ yêu cầu dự báo cho tuần kế tiếp, trong khi cột này đo lường lượng khách diễn ra trong tuần đó. Lời giải đúng nằm trong phần lưu ý, nhưng đoạn mã bàn giao lại phớt lờ nó.

Rò rỉ này dẫn đến hệ lụy thứ hai: do lưu lượng khách biến thiên đồng pha với doanh số, mô hình rò rỉ hấp thụ luôn cả tác động của đối thủ cạnh tranh. Sai số của nó không biểu hiện bất kỳ sự bất thường nào. Rò rỉ dữ liệu không chỉ thổi phồng điểm số đánh giá, mà còn che giấu mọi khiếm khuyết trong dữ liệu.

Gemini Pro loại trừ lượng khách cùng tuần nhưng đưa vào lượng khách của tuần trước, với giả định dữ liệu này có ngay khi tuần kết thúc. Dù giả định có thể chấp nhận được, lượng khách tuần trước phản ánh tương đương doanh số tuần trước – điều mà độ trễ báo cáo vốn đã cấm.

Claude Opus 5.5 xử lý thận trọng: đánh giá thử nghiệm biến lượng khách tuần trước dưới dạng một kịch bản giả định (what-if), báo cáo điểm số nhưng loại khỏi mô hình chính thức vì không có xác nhận về tính khả dụng. Nó cũng chủ động chạy mô hình rò rỉ dữ liệu để đối chiếu và cảnh báo rằng kết quả đó bất khả thi trong thực tế.

GPT-6 Sol loại bỏ trực tiếp cột dữ liệu với lý do chính xác và tiếp tục quy trình.

Bẫy 2: Tôn trọng độ trễ báo cáo

Đây là cạm bẫy được giải quyết tốt nhất. Mọi mô hình sử dụng dữ liệu doanh số quá khứ đều tính toán chính xác số học: dự báo đưa ra đầu tuần $T$ chỉ được phép truy cập doanh số tính đến tuần $T-3$.

Sự khác biệt nằm ở cơ chế phòng vệ chống sai sót trong mã nguồn.

Gemini Pro ghi nhận điều này trong chú thích và tạo các biến trễ tương ứng. GPT-6 Sol chặt chẽ hơn: tại mỗi bước backtest, nó chèn lệnh khẳng định (assertion) để kiểm tra:

release_times = df.week_start.iloc[train] + pd.Timedelta(days=21)
assert (release_times <= issue_time).all(), "Unavailable training label"

Claude Opus 5.5 bổ sung một kiểm thử hành vi độc lập: với mỗi dự báo, nó xóa toàn bộ doanh số từ tuần $T-2$ trở đi và xác nhận các đặc trưng cho tuần $T$ không hề bị thay đổi:

masked = raw.copy()
masked.loc[i - SALES_DELAY_WEEKS:, TARGET] = np.nan
assert d.loc[i, LAGS].equals(build_features(masked).loc[i, LAGS])

Nếu bất kỳ đặc trưng nào vô tình phụ thuộc vào dữ liệu chưa công bố, kiểm thử sẽ dừng chương trình ngay lập tức. Đây là ranh giới giữa việc tránh sai lầm và việc ngăn chặn triệt để khả năng xảy ra sai lầm.

DeepSeek không sử dụng lịch sử doanh số nên không vi phạm độ trễ, nhưng phần đề xuất trong phần tóm tắt lại gợi ý dùng độ trễ 2 tuần, tức sớm hơn 1 tuần so với quy định thực tế.

Bẫy 3: Phát hiện sự sụt giảm sau khuyến mãi

Chỉ một mô hình duy nhất vượt qua thử thách này.

Claude Opus 5.5 đưa biến khuyến mãi của tuần trước vào danh sách đặc trưng ứng viên với lập luận rằng lịch trình đã được định trước. Quá trình chọn lọc đặc trưng xác nhận tính đúng đắn: MAE kiểm định giảm từ 74.7 xuống 68.5. Mô hình tiến hành khớp các hệ số và báo cáo sai số chuẩn tương ứng so với giá trị thực tế của hàm sinh dữ liệu:

• Tuần diễn ra khuyến mãi: Giá trị thực tế: $+227$; Ước lượng mô hình: $+227$ ($ ext{SE} = 17$).
• Tuần sau khuyến mãi: Giá trị thực tế: $-113$; Ước lượng mô hình: $-113$ ($ ext{SE} = 17$).

Cả hai ước lượng đều nằm trong khoảng 1.4 độ lệch chuẩn so với giá trị thực tế. Mô hình đồng thời khái quát hóa thành kết luận kinh doanh: mức tăng ròng thực tế của một đợt khuyến mãi chỉ tương đương một nửa mức tăng đột biến ban đầu do hiện tượng sụt giảm bù trừ ngay sau đó. Đó chính là loại insight phân tích mà một đội ngũ marketing cần có.

Nguồn: Towards Data Science

LIÊN HỆ TƯ VẤN CÁC DỊCH VỤ AI

Hỗ trợ tư vấn, đào tạo và chuyển giao AI cho cá nhân, doanh nghiệp và tổ chức.

📞 Điện thoại: 0981243678 Liên hệ qua Zalo