Nhân quả 2 — Thí nghiệm ngẫu nhiên (RCT)

13 thg 7, 2026 2 lượt xem
#bi
#causal-inference
#rct
#randomization
#ab-testing

RCT là gì và vì sao nó là chuẩn vàng

Trong bài tổng quan nhân quả ta đã thấy câu hỏi cốt lõi luôn là phản thực (counterfactual): nếu khách hàng này được nhận ưu đãi thì hành vi ra sao, so với chính họ không nhận. Vấn đề là mỗi đơn vị chỉ tồn tại ở một trạng thái — ta không bao giờ quan sát được cả hai. Suy luận nhân quả chính là bài toán ước lượng cái mình không thấy.

Thí nghiệm ngẫu nhiên có đối chứng (Randomized Controlled Trial — RCT) giải bài toán này bằng một ý tưởng đơn giản mà cực mạnh: ngẫu nhiên hoá (randomization) việc gán treatment. Thay vì để khách tự chọn, hoàn cảnh chọn, hay chính sách chọn — ta tung đồng xu. Mỗi đơn vị (khách, tài khoản, phiên) được phân vào nhóm treatment (nhận thay đổi) hoặc nhóm control (giữ nguyên) một cách hoàn toàn ngẫu nhiên, độc lập với mọi đặc điểm của họ.

Đây là lý do RCT được gọi là gold standard của nhân quả: nó là phương pháp duy nhất thiết kế ra điều kiện để so sánh công bằng, thay vì phải giả định điều đó từ dữ liệu có sẵn.


Vì sao randomization giải quyết confounding

Confounder (biến gây nhiễu) là biến vừa ảnh hưởng đến việc ai được treatment, vừa ảnh hưởng đến outcome. Ví dụ: khách VIP (thu nhập cao) vừa hay được mời ưu đãi, vừa hay chi tiêu nhiều — nên nếu chỉ so sánh "người được ưu đãi" với "người không", phần chênh lệch chi tiêu lẫn lộn giữa tác động của ưu đãitác động của việc họ vốn giàu. Đó là confounding, và trong dữ liệu quan sát nó gần như luôn có mặt.

Randomization triệt tiêu confounding theo cơ chế sau: vì việc gán nhóm độc lập thống kê với mọi đặc điểm của đơn vị, hai nhóm treatment và control sẽ tương đương nhau tính trung bình trên mọi yếu tố — không chỉ những yếu tố ta đo được (tuổi, thu nhập, thành phố) mà cả những yếu tố ta không quan sát được (mức độ kỷ luật tài chính, tâm lý, thói quen). Đây là điểm mấu chốt phân biệt RCT với mọi phương pháp quan sát: các phương pháp như matching/propensity chỉ cân bằng được biến quan sát được; RCT cân bằng cả biến ẩn.

Khi hai nhóm đã tương đương về mọi thứ trước khi can thiệp, thì điểm khác biệt duy nhất còn lại giữa chúng chính là treatment. Do đó chênh lệch outcome trung bình quy hết được cho treatment:

$$ATE = E[Y \mid \text{treatment}] - E[Y \mid \text{control}]$$

Đại lượng này là ATE (Average Treatment Effect) — hiệu ứng nhân quả trung bình. Trong RCT nó ước lượng được không thiên lệch (unbiased) chỉ bằng phép trừ trung bình hai nhóm, không cần mô hình phức tạp nào. "Không thiên lệch tính trung bình" nghĩa là: với một mẫu cụ thể hai nhóm có thể lệch chút do may rủi, nhưng nếu lặp lại thí nghiệm vô số lần, trung bình các ước lượng hội tụ đúng về giá trị thật. Cỡ mẫu càng lớn, độ lệch may rủi càng nhỏ.


Liên hệ A/B testing: cùng một thứ, nhìn dưới lăng kính khác

Nếu bạn từng chạy A/B test, bạn đã chạy một RCT. A/B testing chính là RCT áp dụng trong bối cảnh sản phẩm số: chia người dùng ngẫu nhiên vào biến thể A (control) và B (treatment), đo một metric, so sánh. Bài stat-07 A/B testingpa-07 experimentation đã trình bày kỹ khía cạnh thống kê và vận hành (cỡ mẫu, two-proportion z-test, guardrail, các bẫy peeking / sample ratio mismatch).

Bài này bổ sung lăng kính nhân quả: A/B test không chỉ là "so hai tỷ lệ có khác nhau về mặt thống kê không", mà là một cỗ máy ước lượng ATE. Cách nhìn này giúp ta trả lời được những câu mà tư duy "kiểm định giả thuyết" thuần tuý bỏ sót:

  • Ta đang ước lượng hiệu ứng cho ai (nhóm nào), và có khái quát ra ngoài được không? (external validity)
  • Nếu người dùng được gán B nhưng không thực sự trải nghiệm B thì hiệu ứng ta đo là gì? (compliance)
  • Nếu các nhóm ảnh hưởng lẫn nhau thì phép so sánh còn nghĩa nhân quả không? (spillover)

Nói cách khác: thống kê cho ta biết chênh lệch có thật không; khung nhân quả cho ta biết chênh lệch đó nghĩa là gì và có tin được để ra quyết định không.


Thiết kế một RCT

Các thành phần cốt lõi

Thành phầnÝ nghĩaVí dụ ngân hàng
Đơn vị ngẫu nhiên hoáCái gì được tung đồng xuKhách hàng, tài khoản, phiên app, chi nhánh
TreatmentThay đổi cần đánh giáNút CTA mới, ưu đãi phí, email nhắc
ControlTrạng thái đối chứngGiao diện cũ, không ưu đãi
Outcome (metric chính)Cái ta muốn tác độngTỷ lệ hoàn tất mở TK, tỷ lệ kích hoạt thẻ
GuardrailMetric không được xấu điTỷ lệ khiếu nại, chi phí, độ trễ

Cỡ mẫu và power

Trước khi chạy phải tính cỡ mẫu (sample size) dựa trên bốn tham số:

  • Baseline: tỷ lệ hiện tại của metric (ví dụ 30% khách hoàn tất onboarding).
  • MDE (Minimum Detectable Effect): mức cải thiện nhỏ nhất đáng để phát hiện (ví dụ +2 điểm phần trăm). MDE càng nhỏ, cần mẫu càng lớn.
  • alpha (thường 5%): xác suất báo động giả — kết luận có hiệu ứng khi thực ra không.
  • power (thường 80%): xác suất phát hiện được hiệu ứng nếu nó thật sự tồn tại. Power thấp → thí nghiệm dễ "hoà" một cách vô nghĩa.

Chi tiết công thức xem stat-07. Ý chính cần nhớ: tính cỡ mẫu TRƯỚC khi chạy, và chốt thời gian chạy — không "peek" rồi dừng khi thấy đẹp.

Ngẫu nhiên hoá phân tầng và theo khối

Randomization thuần tuý tính trung bình thì cân bằng, nhưng với mẫu nhỏ vẫn có thể lệch do may rủi (ví dụ nhóm B tình cờ có nhiều khách VIP). Hai kỹ thuật cải thiện:

  • Ngẫu nhiên hoá phân tầng (stratified randomization): chia quần thể theo tầng quan trọng (ví dụ phân khúc thu nhập, vùng miền) rồi randomize trong từng tầng. Đảm bảo mỗi tầng có tỷ lệ treatment/control cân bằng.
  • Ngẫu nhiên hoá theo khối (block randomization): gán theo từng khối nhỏ (ví dụ mỗi 10 người có đúng 5 treatment) để tỷ lệ hai nhóm luôn sát nhau kể cả khi dừng sớm.

Cả hai đều giảm phương sai của ước lượng ATE → cần ít mẫu hơn để đạt cùng power, và tránh mất cân bằng ngẫu nhiên ở biến quan trọng.


Ước lượng hiệu ứng

Với metric tỷ lệ (conversion), ATE là chênh hai tỷ lệ; với metric liên tục (số tiền chi tiêu), ATE là chênh hai trung bình. Luôn báo cáo kèm khoảng tin cậy (confidence interval) chứ không chỉ điểm ước lượng:

  • Ước lượng điểm: lift = mean(treatment) − mean(control).
  • Khoảng tin cậy 95%: cho biết dải giá trị hợp lý của hiệu ứng thật. Nếu CI chứa 0 → chưa đủ bằng chứng có hiệu ứng.
  • Có thể dùng hồi quy với biến covariate (CUPED / hồi quy điều chỉnh) để giảm phương sai, nhưng ước lượng cơ bản vẫn là chênh trung bình.

Ví dụ đọc kết quả: "treatment nâng tỷ lệ kích hoạt thẻ từ 40% lên 44%, ATE = +4đpt, CI 95% [+1.5, +6.5], p < 0.01" → hiệu ứng dương, có ý nghĩa, và độ lớn kinh doanh đáng kể.


Các mối đe doạ đến tính giá trị (validity threats)

Randomization đảm bảo khởi điểm công bằng, nhưng nhiều thứ trong lúc chạy có thể phá vỡ diễn giải nhân quả:

Mối đe doạBản chấtVí dụCách xử lý
Spillover / nhiễu chéoNhóm ảnh hưởng lẫn nhau, vi phạm giả định SUTVAKhách control nghe khách treatment khoe ưu đãi rồi cũng dùngRandomize theo cụm (chi nhánh, khu vực)
Non-complianceĐược gán treatment nhưng không thực nhận (hoặc ngược lại)Gán nhận email nhưng email vào spamPhân tích ITT + per-protocol
AttritionĐơn vị rời bỏ không đều giữa hai nhómKhách khó tính bỏ app nhiều hơn ở nhóm BKiểm tra tỷ lệ rớt cân bằng; phân tích nhạy cảm
Hawthorne effectBiết mình bị quan sát nên đổi hành viNhân viên chi nhánh pilot cố gắng hơn bình thườngLàm mù, đo dài hạn, control cũng "được quan sát"
Sample ratio mismatchTỷ lệ chia nhóm lệch so với thiết kếBug tracking gán 55/45 thay vì 50/50Dừng, tìm lỗi kỹ thuật trước khi đọc kết quả

Non-compliance: ITT vs per-protocol

Đây là điểm dễ sai nhất. Khi có người được gán nhưng không nhận treatment, có hai cách phân tích:

  • Intention-to-Treat (ITT): phân tích theo nhóm được gán ban đầu, bất kể thực nhận hay không. Bảo toàn tính ngẫu nhiên → vẫn ước lượng đúng nhân quả, nhưng là hiệu ứng của việc gán (thường bảo thủ, thấp hơn thực).
  • Per-protocol: chỉ phân tích những người thực sự tuân thủ. Trực quan hơn nhưng phá vỡ randomization — người tuân thủ có thể khác bản chất với người bỏ (self-selection), confounding quay lại.

Nguyên tắc: báo cáo ITT làm chính (an toàn về nhân quả), per-protocol chỉ để tham khảo hoặc dùng kỹ thuật biến công cụ (IV) để ước lượng hiệu ứng cho nhóm tuân thủ một cách hợp lệ.


RCT nâng cao

Khi đơn vị ngẫu nhiên hoá đơn giản không khả thi, có các thiết kế mở rộng:

  • Cluster randomization: randomize theo cụm (chi nhánh, phường, đội bán) thay vì cá nhân — dùng khi spillover mạnh trong cụm hoặc can thiệp áp lên cả cụm (đào tạo nhân viên chi nhánh). Lưu ý: mất hiệu quả thống kê (cần nhiều cụm), phải phân tích tính đến tương quan nội cụm.
  • Stepped-wedge: triển khai treatment theo đợt cuốn chiếu — tất cả cụm cuối cùng đều nhận treatment, nhưng thứ tự thời điểm được randomize. Phù hợp khi không thể để nhóm nào mãi không nhận (lý do đạo đức/chính trị nội bộ), ví dụ rollout hệ thống mới cho toàn bộ chi nhánh.
  • Switchback: cùng một đơn vị bật/tắt treatment luân phiên theo khung thời gian, randomize thứ tự bật/tắt. Dùng cho hệ thống có hiệu ứng mạng/thị trường (pricing, phân bổ) nơi không thể chia người dùng — ví dụ thử thuật toán định giá phí giao dịch theo khung giờ.

Khi KHÔNG THỂ chạy RCT

RCT là chuẩn vàng, nhưng trong ngân hàng rất nhiều tình huống không được phép hoặc không thể randomize:

  • Đạo đức và pháp lý: không được cố tình cho một nhóm khách vay/không vay theo cách bất công để "đo hiệu ứng". Quyết định tín dụng, tính điểm rủi ro, giá vốn phải áp nhất quán và công bằng cho mọi khách đủ điều kiện — không thí nghiệm bừa lên quyền lợi tài chính.
  • Chi phí / quy mô: đổi core banking, chính sách LTV toàn hệ thống — không thể chạy song song hai phiên bản.
  • Không kiểm soát được / đã xảy ra rồi: tác động của một cú sốc lãi suất, một thay đổi quy định NHNN — chuyện đã diễn ra, không thể randomize hồi tố.
  • Chính sách áp cho tất cả: khi treatment bắt buộc với mọi đơn vị (ví dụ hạ mức phí đồng loạt), không có nhóm control tự nhiên.

Trong các trường hợp này ta buộc chuyển sang phương pháp quan sát (observational) — chủ đề của các bài tiếp theo trong series: kiểm soát confounder qua DAG, matching / propensity score, difference-in-differences, IV và regression discontinuity, và uplift modeling. Các phương pháp này giả định để tái tạo điều kiện mà RCT thiết kế ra — nên luôn yếu hơn và cần biện luận cẩn thận.

Khi nào ngân hàng chạy A/B được, khi nào phải quan sát

Chạy A/B (RCT) đượcBuộc dùng quan sát
Giao diện app / web, luồng onboardingChính sách tín dụng / hạn mức áp toàn hệ thống
Nội dung ưu đãi, kênh gửi, thời điểm nhắcThay đổi lãi suất/phí do quy định
Bố cục dashboard nội bộ, wording thông báoCú sốc thị trường, thay đổi vĩ mô
Thứ tự sản phẩm gợi ý (không liên quan tín dụng)Quyết định phê duyệt vay của một khách cụ thể

Nguyên tắc: randomize những gì thuộc trải nghiệm và marketing (ít rủi ro, đảo ngược được); không randomize những gì đụng vào quyền lợi tài chính, rủi ro tín dụng, hay công bằng.


Hạn chế của chính RCT

RCT mạnh về internal validity (khác biệt đo được đúng là do treatment), nhưng không tự động có external validity (khái quát ra ngoài):

  • Kết quả trên nhóm tham gia thí nghiệm có thể không đúng với toàn bộ khách hàng (nhóm pilot thường khác quần thể chung).
  • Hiệu ứng trong môi trường thí nghiệm ngắn hạn có thể khác khi triển khai đại trà, dài hạn (novelty effect tan biến).
  • RCT đo ATE trung bình — có thể che giấu heterogeneity: treatment tốt cho nhóm này, hại nhóm khác. Đây chính là lý do có uplift modeling.

Vì vậy: RCT trả lời chắc chắn "có hiệu ứng nhân quả không và bao nhiêu, trong bối cảnh này", nhưng vẫn cần phán đoán khi ngoại suy sang bối cảnh khác.


Use case thực tế

Bối cảnh. Khối Ngân hàng số NCB muốn biết: gửi email nhắc thanh toán dư nợ thẻ tín dụng trước hạn 3 ngày có làm giảm tỷ lệ trả chậm không. Tỷ lệ trả chậm hiện tại (baseline) khoảng 12%.

Thiết kế RCT.

  1. Đơn vị: chủ thẻ tín dụng đang có dư nợ trong kỳ (khoảng 40.000 khách đủ điều kiện).
  2. Randomization phân tầng: chia theo phân khúc hạn mức (thấp / trung / cao) rồi randomize 50/50 trong mỗi tầng → hai nhóm cân bằng về mức rủi ro.
  3. Treatment: nhận email nhắc; Control: không nhận email nhắc (vẫn có SMS mặc định như mọi khi — control phải là trạng thái hiện hành, không phải "không gì cả").
  4. Metric chính: tỷ lệ trả chậm trong kỳ. Guardrail: tỷ lệ khiếu nại "làm phiền", tỷ lệ unsubscribe.
  5. Cỡ mẫu & thời gian: tính trước với MDE = 1.5đpt, alpha 5%, power 80% → chốt chạy trọn 1 chu kỳ sao kê, không peek giữa chừng.

Đọc kết quả (minh hoạ). Treatment: trả chậm 10.4%; Control: 12.1% → ATE = −1.7đpt, CI 95% [−2.6, −0.8], p < 0.01. Guardrail không xấu đi đáng kể → triển khai.

Bẫy gặp phải. Có 8% khách nhóm treatment không mở email (non-compliance). Ta báo cáo ITT (theo nhóm được gán) làm con số chính thức để ra quyết định — vì đó là hiệu ứng thực tế khi bật tính năng cho toàn bộ nhóm, đã tính cả người không mở. Con số per-protocol (chỉ người mở email) cao hơn nhưng không dùng để kết luận vì đã vỡ tính ngẫu nhiên.

Minh hoạ so sánh hai nhóm bằng SQL sandbox. Sandbox không có bảng thí nghiệm thật; để minh hoạ kỹ thuật so sánh trung bình outcome giữa hai nhóm, ta giả lập chia khách theo tính chẵn/lẻ của id (chỉ để demo cú pháp, KHÔNG phải randomization thật) và so sánh số dư trung bình:

-- ▶ Chạy được
SELECT
  CASE WHEN c.id % 2 = 0 THEN 'group_B' ELSE 'group_A' END AS grp,
  COUNT(*)              AS n_customers,
  ROUND(AVG(a.balance), 2) AS avg_balance
FROM customers c
JOIN accounts a ON a.customer_id = c.id
GROUP BY 1
ORDER BY 1;

Truy vấn trên trả về cỡ mẫu và trung bình outcome mỗi nhóm — đúng khung "so hai nhóm" của RCT. Trong thí nghiệm thật, cột phân nhóm sẽ là assignment ngẫu nhiên đã lưu, còn avg_balance sẽ là metric outcome, và chênh hai giá trị là ước lượng ATE (cần thêm CI). Nhắc lại: chia theo id % 2 không phải randomization — chỉ dùng để minh hoạ cú pháp so sánh nhóm.


Ghi nhớ

  • RCT = chuẩn vàng vì nó thiết kế ra điều kiện so sánh công bằng thay vì phải giả định từ dữ liệu.
  • Randomization làm hai nhóm tương đương trung bình trên mọi yếu tố — cả quan sát được lẫn ẩn — nên chênh outcome quy được cho treatment (ATE), ước lượng không thiên lệch chỉ bằng phép trừ trung bình.
  • A/B testing chính là RCT trong sản phẩm; khung nhân quả bổ sung câu hỏi hiệu ứng nghĩa là gì, cho ai, có tin được không — xem stat-07, pa-07.
  • Thiết kế cần: đơn vị randomize, treatment/control, metric chính + guardrail, cỡ mẫu/power tính trước; stratified/block giúp cân bằng và giảm phương sai.
  • Luôn báo cáo ATE kèm khoảng tin cậy, không chỉ điểm ước lượng.
  • Validity threats: spillover, non-compliance (ITT vs per-protocol), attrition, Hawthorne, sample ratio mismatch — ITT là con số ra quyết định.
  • Nâng cao: cluster, stepped-wedge, switchback cho tình huống không randomize cá nhân được.
  • Ngân hàng: randomize giao diện/ưu đãi/marketing; KHÔNG randomize tín dụng/rủi ro/công bằng hay chính sách áp toàn hệ thống → khi đó chuyển sang phương pháp quan sát (bài 3–7).
  • RCT mạnh internal validity nhưng external validity không tự nhiên có — cẩn thận khi ngoại suy; ATE có thể che giấu heterogeneity (→ uplift).

Bài viết liên quan

Phân biệt ước lượng điểm và ước lượng khoảng, cách xây khoảng tin cậy (CI) bằng margin of error z*·SE / t*·SE, đánh đổi mức 90/95/99%, và cách DIỄN GIẢI ĐÚNG khoảng tin cậy (95% CI không phải xác suất tham số nằm trong khoảng). Có CI cho trung bình và cho tỷ lệ, ảnh hưởng của cỡ mẫu, cùng ví dụ ngân hàng về tỷ lệ nợ xấu và số dư trung bình.

13 thg 7, 2026 4

Kimball dimensional modeling: bảng fact/dimension, star vs snowflake, grain, và Slowly Changing Dimension.

13 thg 7, 2026 3

Khối OLAP, các thao tác drill-down/roll-up/slice & dice/pivot, OLAP vs OLTP và ROLAP/MOLAP/HOLAP.

13 thg 7, 2026 3

Từ nguồn dữ liệu qua ETL/ELT vào Data Warehouse, Data Mart đến dashboard; staging, ODS, batch vs streaming.

13 thg 7, 2026 3