Thống kê 8 — Cạm bẫy thống kê thường gặp

Vì sao cần một bài về cạm bẫy?

Suốt series này ta đã học các công cụ: thống kê mô tả, phân phối, lấy mẫu & CLT, khoảng tin cậy, kiểm định giả thuyết, tương quan & hồi quy và A/B testing. Công cụ tốt trong tay người thiếu cảnh giác vẫn cho ra kết luận sai — và trong ngân hàng, một kết luận sai có thể thành một chính sách tín dụng lệch, một mô hình chấm điểm phân biệt đối xử, hoặc một quyết định đầu tư hàng chục tỷ dựa trên "bằng chứng" không có thật.

Bài tổng kết này liệt kê 10 cạm bẫy phổ biến nhất. Với mỗi bẫy: cơ chế → ví dụ ngân hàng/dữ liệu → cách phòng tránh. Chủ đề xuyên suốt là tư duy phản biện với số liệu: đừng hỏi "con số này nói gì", hãy hỏi "con số này có thể lừa tôi bằng cách nào".

1. Tương quan ≠ nhân quả & biến gây nhiễu

Đây là bẫy kinh điển nhất. Hai biến biến thiên cùng nhau (correlation) không có nghĩa cái này gây ra cái kia (causation).

Cơ chế: thường có một biến gây nhiễu (confounder) — biến thứ ba tác động lên cả hai. Nó tạo mối liên hệ thống kê nhưng không phải quan hệ nhân quả trực tiếp.

Ví dụ ngân hàng: phân tích cho thấy khách hàng dùng app mobile banking nhiều có tỷ lệ vỡ nợ thấp hơn. Kết luận vội: "hãy ép mọi khách nợ dùng app để giảm vỡ nợ". Sai. Biến gây nhiễu là độ tuổi/thu nhập/trình độ số: người trẻ, thu nhập ổn định, quen công nghệ vừa dùng app nhiều vừa trả nợ tốt. Ép một bác nông dân 60 tuổi cài app không làm bác trả nợ tốt hơn.

Cách phòng tránh:

• Vẽ sơ đồ nhân quả trước khi tin vào hệ số hồi quy: biến nào có thể là confounder?
• Kiểm soát confounder bằng cách đưa vào mô hình, phân tầng (stratify), hoặc matching.
• Chỉ khẳng định nhân quả khi có thí nghiệm ngẫu nhiên hoá (A/B testing) hoặc thiết kế quasi-experiment vững chắc.

Nhớ: hồi quy quan sát (observational) trả lời "khách như thế này thường vỡ nợ bao nhiêu", KHÔNG trả lời "nếu tôi can thiệp thì điều gì xảy ra".

2. P-hacking, data dredging & HARKing

Ba anh em cùng một gia đình "ép dữ liệu khai ra điều mình muốn".

• P-hacking: thử nhiều biến thể phân tích (bỏ outlier / không bỏ, log-transform / không, thêm/bớt biến, cắt subgroup) cho tới khi p-value < 0.05 rồi chỉ báo cáo cái "đẹp".
• Data dredging (fishing): quét hàng trăm mối quan hệ mà không có giả thuyết trước, nhặt ra cái nào "significant".
• HARKing (Hypothesizing After Results are Known): tìm ra kết quả trước, rồi bịa giả thuyết như thể mình đã dự đoán từ đầu.

Ví dụ: một analyst muốn chứng minh chiến dịch thẻ tín dụng mới hiệu quả. Anh ta cắt dữ liệu theo tỉnh, theo độ tuổi, theo giới tính, theo kênh... Test tới subgroup thứ 18 — "nữ, 25-34 tuổi, Hà Nội" — thì p = 0.03. Báo cáo: "chiến dịch hiệu quả rõ rệt với nhóm nữ trẻ đô thị!". Thực chất đó chỉ là nhiễu (xem mục 3).

Cách phòng tránh:

• Đăng ký giả thuyết trước (pre-registration): viết ra câu hỏi, metric chính, cách phân tích TRƯỚC khi nhìn kết quả.
• Tách rõ phân tích khẳng định (confirmatory) với phân tích thăm dò (exploratory). Kết quả exploratory chỉ là để tạo giả thuyết, phải kiểm chứng lại trên dữ liệu mới.
• Báo cáo mọi phân tích đã làm, không chỉ cái đẹp.

3. Multiple comparisons: càng test nhiều càng dễ "trúng" giả

Đây là nền toán học của mục 2. Nếu ngưỡng ý nghĩa α = 0.05, thì mỗi test dù không có hiệu ứng thật vẫn có 5% khả năng cho ra "significant" do ngẫu nhiên (dương tính giả — false positive).

Test độc lập nhiều lần thì xác suất có ít nhất một dương tính giả tăng vọt:

$$P(\text{có ít nhất 1 FP}) = 1 - (1 - \alpha)^m$$

Với 20 subgroup như ví dụ mục 2, gần như chắc chắn nhặt được ít nhất một "significant" hoàn toàn ngẫu nhiên.

Cách phòng tránh — hiệu chỉnh:

• Bonferroni: dùng ngưỡng α/m cho mỗi test (ví dụ 20 test → ngưỡng 0.05/20 = 0.0025). Đơn giản, rất bảo thủ (dễ bỏ sót hiệu ứng thật).
• FDR (False Discovery Rate) / Benjamini-Hochberg: kiểm soát tỷ lệ dương tính giả trong số phát hiện, thay vì chặn tuyệt đối. Ít bảo thủ hơn, phù hợp khi test hàng trăm/nghìn giả thuyết (ví dụ scan feature cho mô hình rủi ro).

Quy tắc: hễ so sánh nhiều nhóm/nhiều metric cùng lúc, phải hiệu chỉnh. Dashboard giám sát với 40 alert cùng ngưỡng p<0.05 sẽ báo động giả mỗi ngày.

4. Simpson's paradox: đảo chiều khi gộp/tách nhóm

Một xu hướng đúng trong từng nhóm con có thể đảo ngược khi gộp tất cả lại. Nguyên nhân là một biến gây nhiễu phân bố lệch giữa các nhóm.

Ví dụ số cụ thể — tỷ lệ duyệt vay của hai phòng giao dịch:

Giả sử ta so tỷ lệ duyệt hồ sơ vay của PGD A và PGD B, tách theo loại hồ sơ (cá nhân vs doanh nghiệp):

Trong cả hai loại hồ sơ, PGD A duyệt tỷ lệ cao hơn B (93% > 87% và 73% > 69%). Nhưng khi gộp lại, B lại cao hơn (83% > 78%)! Nghịch lý xảy ra vì A xử lý phần lớn hồ sơ doanh nghiệp (loại khó duyệt), còn B xử lý phần lớn hồ sơ cá nhân (loại dễ duyệt). Loại hồ sơ chính là confounder.

Nếu lãnh đạo nhìn con số gộp và kết luận "PGD A thẩm định gắt hơn nên duyệt ít, cần chấn chỉnh" thì hoàn toàn sai — thực tế A dễ tính hơn ở mọi phân khúc.

Cách phòng tránh:

• Luôn hỏi: "có biến nào phân bố lệch giữa các nhóm đang so không?"
• Phân tầng (stratify) theo confounder rồi mới so sánh; hoặc chuẩn hoá (standardization) về cùng cơ cấu.
• Cảnh giác đặc biệt với mọi con số tổng gộp — luôn thử bóc tách xem xu hướng có giữ nguyên không.

Mô phỏng ý tưởng bóc tách trên sandbox bằng nhóm tài khoản theo loại tiền tệ (chỉ để minh hoạ kỹ thuật GROUP BY nhiều chiều, không phải chính xác bài toán trên):

-- ▶ Chạy được
SELECT a.currency,
       t.kind,
       COUNT(*)        AS so_giao_dich,
       ROUND(AVG(t.amount), 2) AS gt_trung_binh
FROM transactions t
JOIN accounts a ON a.id = t.account_id
GROUP BY a.currency, t.kind
ORDER BY a.currency, t.kind;

Khi so sánh trung bình, hãy luôn xem cả bản gộp (GROUP BY currency) lẫn bản tách (GROUP BY currency, kind) — nếu thứ hạng đảo chiều, bạn vừa gặp Simpson's paradox.

5. Survivorship bias & selection bias

Selection bias: mẫu phân tích không đại diện cho tổng thể mà ta muốn kết luận. Survivorship bias là một trường hợp đặc biệt: ta chỉ nhìn những đối tượng "sống sót" và bỏ quên những cái đã biến mất.

Ví dụ ngân hàng:

• Xây mô hình chấm điểm tín dụng chỉ trên những hồ sơ đã được duyệt (đã cấp tín dụng). Nhưng những hồ sơ bị từ chối không có trong dữ liệu — mô hình học trên nhóm đã lọc, sẽ ước lượng sai rủi ro của nhóm cận biên. Đây là reject inference problem kinh điển.
• Đánh giá hiệu quả sản phẩm đầu tư bằng cách chỉ nhìn các quỹ còn tồn tại năm nay. Các quỹ lỗ nặng đã đóng cửa biến mất khỏi mẫu → lợi suất trung bình bị thổi phồng.
• Khảo sát mức độ hài lòng chỉ với khách còn dùng dịch vụ; khách đã bỏ đi (churn) — nhóm bất mãn nhất — không được hỏi.

Cách phòng tránh:

• Hỏi rõ: "ai/cái gì đã bị loại khỏi dữ liệu trước khi nó tới tay tôi?"
• Với reject inference: dùng kỹ thuật gán nhãn suy diễn cho hồ sơ bị từ chối, hoặc thu thập dữ liệu hiệu suất của nhóm được duyệt "nới lỏng" thử nghiệm.
• Định nghĩa tổng thể mục tiêu (target population) trước, rồi kiểm tra mẫu có đại diện không.

6. Regression to the mean

Giá trị cực đoan có xu hướng "trở về gần trung bình" ở lần đo sau, thuần tuý do may rủi ngẫu nhiên — không cần bất kỳ can thiệp nào.

Cơ chế: mỗi quan sát = tín hiệu thật + nhiễu. Một giá trị cực cao thường do nhiễu cũng cao; lần sau nhiễu không lặp lại nên giá trị tụt về gần mức thật.

Ví dụ ngân hàng: chi nhánh có doanh số quý này thấp bất thường bị "chấn chỉnh": họp, tăng KPI, đào tạo lại. Quý sau doanh số hồi phục. Ban lãnh đạo kết luận "biện pháp chấn chỉnh hiệu quả!". Nhưng phần lớn sự hồi phục chỉ là regression to the mean — chi nhánh chọn ra vì cực đoan, nên gần như chắc chắn sẽ tốt lên dù có làm gì hay không.

Tương tự: khách hàng có điểm tín dụng tụt sâu bất thường một kỳ thường tự hồi phục kỳ sau; đừng nhầm đó là công của một chương trình chăm sóc.

Cách phòng tránh:

• Khi chọn đối tượng vì giá trị cực đoan, luôn cần nhóm đối chứng (control) để tách phần hồi phục tự nhiên khỏi phần do can thiệp.
• Cảnh giác mọi câu chuyện "đang tệ nhất → can thiệp → khá lên".

7. Base rate fallacy & nghịch lý dương tính giả

Bỏ qua tỷ lệ nền (base rate) khiến ta diễn giải sai một kết quả xét nghiệm/cảnh báo. Đây chính là định lý Bayes áp dụng vào phát hiện gian lận.

Ví dụ — hệ thống phát hiện gian lận giao dịch:

Giả sử tỷ lệ giao dịch gian lận thật sự chỉ 0.1% (base rate rất thấp). Hệ thống rất "nhạy":

• Độ nhạy (sensitivity): bắt đúng 99% giao dịch gian lận.
• Độ đặc hiệu: cảnh báo nhầm chỉ 1% giao dịch hợp lệ.

Trên 100.000 giao dịch:

• Gian lận thật: 100 → hệ thống bắt 99.
• Hợp lệ: 99.900 → hệ thống báo nhầm 1% = 999.

Trong tổng số 99 + 999 = 1.098 cảnh báo, chỉ 99 là gian lận thật. Xác suất một cảnh báo là gian lận thật chỉ ≈ 9% (99/1098), dù hệ thống "chính xác 99%"! Nếu đội vận hành tin mù mỗi alert là gian lận và khoá thẻ khách, họ sẽ làm phiền hàng trăm khách vô tội mỗi ngày.

$$P(\text{gian lận},|,\text{cảnh báo}) = \frac{0.99 \times 0.001}{0.99 \times 0.001 + 0.01 \times 0.999} \approx 0.09$$

Cách phòng tránh:

• Luôn đưa base rate vào diễn giải. Với sự kiện hiếm, độ chính xác cao vẫn cho precision thấp.
• Tối ưu ngưỡng theo chi phí thực (chặn nhầm khách vs bỏ sót gian lận), không chỉ theo accuracy — xem ml-05-evaluation-metrics.
• Xây tầng xác minh (verify) sau cảnh báo thay vì hành động ngay. Chủ đề này gắn chặt với phòng chống rửa tiền — aml-01-overview.

8. Confirmation bias, cherry-picking & trực quan hoá gây hiểu lầm

• Confirmation bias: vô thức tìm và nhấn mạnh dữ liệu ủng hộ điều mình đã tin, bỏ qua dữ liệu phản bác.
• Cherry-picking: chọn khoảng thời gian/nhóm/metric có lợi. "Doanh số tăng 20%!" — nhưng chỉ tính từ đáy tháng 2 tới đỉnh tháng 4.
• Trực quan hoá gây hiểu lầm: cùng dữ liệu, cách vẽ khác nhau cho ấn tượng trái ngược.

Các chiêu biểu đồ hay gặp:

Ví dụ: báo cáo cho thấy cột "tỷ lệ nợ xấu" quý này cao gấp đôi quý trước — nhìn choáng. Nhìn kỹ trục Y bắt đầu từ 1.8% tới 2.0%: thực tế chỉ tăng từ 1.85% lên 1.92%.

Cách phòng tránh: đọc kỹ trục và thang đo trước khi phản ứng; yêu cầu số tuyệt đối kèm baseline; tự vẽ lại với trục từ 0. Nguyên tắc kể chuyện trung thực xem data storytelling.

9. Nhầm ý nghĩa thống kê với ý nghĩa thực tiễn

Statistical significance (p < 0.05) chỉ nói hiệu ứng khác 0 một cách đáng tin, KHÔNG nói hiệu ứng đủ lớn để đáng làm. Với mẫu cực lớn (hàng triệu giao dịch), mọi khác biệt tí hon đều "significant".

Ví dụ: A/B test trên 5 triệu phiên cho thấy nút CTA màu mới tăng tỷ lệ mở thẻ từ 2.000% lên 2.012%, p < 0.001. Có ý nghĩa thống kê. Nhưng chênh lệch 0.012 điểm phần trăm liệu có bù nổi chi phí thiết kế lại, kiểm thử, triển khai? Gần như chắc là không.

Cách phòng tránh:

• Luôn báo cáo effect size (mức độ ảnh hưởng) và khoảng tin cậy (stat-04), không chỉ p-value.
• Đặt ngưỡng ý nghĩa thực tiễn (practical significance / MDE) trước khi test: chênh lệch nhỏ tới đâu thì mới đáng hành động?
• Quy ra tiền/tác động nghiệp vụ, không dừng ở "p nhỏ".

10. Ngoại suy ngoài miền dữ liệu

Mô hình chỉ đáng tin trong miền dữ liệu (domain) nó được huấn luyện. Đẩy input ra ngoài khoảng đó (extrapolation) là đi vào vùng mù.

Ví dụ ngân hàng: mô hình chấm điểm tín dụng được huấn luyện trên khách thu nhập 10–50 triệu/tháng. Dùng nó chấm cho khách thu nhập 500 triệu/tháng, hoặc trong một cú sốc kinh tế (như đại dịch) khi quan hệ giữa các biến đã đổi — kết quả vô nghĩa. Mô hình hồi quy tuyến tính có thể dự báo "xác suất vỡ nợ âm" hoặc ">100%" khi ngoại suy.

Cách phòng tránh:

• Ghi rõ miền hợp lệ của mô hình; cảnh báo/từ chối dự báo khi input ra ngoài khoảng huấn luyện (out-of-distribution detection).
• Giám sát data drift: khi phân phối input dịch chuyển, cần huấn luyện lại.
• Không suy diễn quan hệ tuyến tính ra ngoài vùng quan sát.

Sơ đồ: cây quyết định tránh bẫy

Đọc cây này như một checklist: mỗi lần trình bày một con số, đi qua từng nút hỏi. Chỉ khi vượt hết mới nên tin.

Use case thực tế

Bối cảnh: phòng phân tích NCB nhận yêu cầu đánh giá chương trình "gọi điện chăm sóc khách hàng có nguy cơ churn". Đội vận hành báo cáo: "sau khi gọi các khách có điểm gắn kết thấp nhất, 62% trong số họ đã tăng mức sử dụng dịch vụ quý sau — chương trình thành công, xin nhân rộng toàn hàng."

Rà soát qua checklist:

1. Nhân quả hay quan sát? Không có nhóm đối chứng — đây là quan sát. Chưa thể khẳng định nhân quả.
2. Regression to the mean (mục 6): khách được chọn vì điểm gắn kết thấp nhất — nhóm cực đoan. Ngay cả không gọi, phần lớn sẽ hồi phục về trung bình. Con số 62% có thể phần lớn là hiệu ứng này.
3. Survivorship bias (mục 5): "62% trong số họ" — nhưng có khách đã đóng tài khoản giữa quý, biến mất khỏi mẫu đo. Nhóm bỏ đi (tệ nhất) bị loại.
4. Cherry-picking (mục 8): vì sao chọn metric "mức sử dụng dịch vụ" mà không phải "tỷ lệ churn thực tế"? Metric có được chọn sau khi nhìn kết quả không?
5. Ý nghĩa thực tiễn (mục 9): kể cả có tác động thật, chi phí mỗi cuộc gọi so với doanh thu giữ được là bao nhiêu?

Thiết kế lại (đúng): chạy A/B test — random 50% khách nguy cơ vào nhóm được gọi, 50% vào nhóm control. So tỷ lệ churn thực giữa hai nhóm sau 90 ngày. Xác định MDE trước (ví dụ chỉ nhân rộng nếu giảm churn ≥ 3 điểm phần trăm). Báo cáo effect size + khoảng tin cậy, không chỉ p-value.

Kết quả giả định sau khi làm đúng: nhóm gọi churn 18%, nhóm control churn 17% — chênh lệch nằm trong nhiễu, không đạt MDE. Chương trình không hiệu quả như tưởng; phần "62% hồi phục" chủ yếu là regression to the mean. Tiết kiệm được chi phí nhân rộng vô ích cho toàn hàng.

Ghi nhớ

• Tương quan ≠ nhân quả. Luôn truy tìm biến gây nhiễu; chỉ khẳng định nhân quả khi có ngẫu nhiên hoá.
• P-hacking/HARKing: đăng ký giả thuyết & metric trước; tách phân tích khẳng định khỏi thăm dò; báo cáo mọi phân tích đã làm.
• Multiple comparisons: test nhiều → dương tính giả tăng vọt (20 test ≈ 64% có ít nhất 1 FP). Hiệu chỉnh Bonferroni (bảo thủ) hoặc FDR (khi nhiều test).
• Simpson's paradox: xu hướng có thể đảo chiều khi gộp/tách. Luôn bóc tách theo confounder; nghi ngờ mọi số tổng gộp.
• Survivorship/selection bias: hỏi "ai đã bị loại khỏi dữ liệu?". Cẩn trọng reject inference khi build scorecard.
• Regression to the mean: cực đoan tự trở về trung bình — cần nhóm control để không nhận vơ công cho can thiệp.
• Base rate fallacy: với sự kiện hiếm (gian lận 0.1%), "chính xác 99%" vẫn cho precision ~9%. Đưa base rate vào diễn giải.
• Trực quan hoá gây hiểu lầm: đọc kỹ trục Y (phải từ 0 với cột), thang đo, baseline trước khi kết luận.
• Ý nghĩa thống kê ≠ thực tiễn: với mẫu lớn mọi khác biệt đều "significant". Luôn báo cáo effect size + CI, đặt MDE trước.
• Đừng ngoại suy ngoài miền dữ liệu: ghi rõ khoảng hợp lệ của mô hình; giám sát data drift.
• Tư duy phản biện: đừng hỏi "con số này nói gì", hãy hỏi "con số này lừa tôi được bằng cách nào".