Tìm hiểu cách các mô hình nhân quả của Judea Pearl giúp đội giải thích hành vi AI, gỡ lỗi sự cố và ra quyết định sản phẩm rõ ràng hơn vượt lên trên tương quan.
Một đội nhận thấy điều “hiển nhiên” trên dashboard: người dùng nhận nhiều thông báo hơn thì quay lại nhiều hơn. Vậy họ tăng lượng thông báo. Một tuần sau, retention giảm và khiếu nại tăng. Chuyện gì đã xảy ra?
Mẫu ban đầu có thật—nhưng gây hiểu lầm. Người dùng tương tác nhiều tự nhiên kích hoạt nhiều thông báo hơn (vì họ dùng sản phẩm nhiều hơn), và họ cũng tự nhiên quay lại nhiều hơn. Thông báo không gây ra retention; tương tác gây cả hai. Đội đã hành động dựa trên tương quan và vô tình tạo trải nghiệm tệ hơn.
Tư duy nhân quả là thói quen hỏi: cái gì gây cái gì, và làm sao chúng ta biết? Thay vì dừng ở “hai thứ này di chuyển cùng nhau,” bạn cố tách ra:
Không phải là nghi ngờ dữ liệu—mà là cụ thể hơn về câu hỏi. “Thông báo có tương quan với retention không?” khác với “Gửi nhiều thông báo hơn có tăng retention không?” Câu thứ hai là câu hỏi nhân quả.
Bài viết tập trung vào ba lĩnh vực thực tế nơi việc phát hiện mẫu thường thất bại:
Đây không phải tour toán nặng về suy luận nhân quả. Bạn không cần học ký hiệu do-calculus để có giá trị ở đây. Mục tiêu là bộ mô hình tư duy và quy trình đội bạn có thể dùng để:
Nếu bạn từng triển khai thay đổi “trông tốt trong dữ liệu” nhưng thất bại ngoài đời thực, tư duy nhân quả là mắt xích còn thiếu.
Judea Pearl là nhà khoa học máy tính và triết học khoa học, công trình của ông thay đổi cách nhiều đội nghĩ về dữ liệu, AI và ra quyết định. Trước cuộc cách mạng nhân quả của ông, phần lớn “học từ dữ liệu” trong máy tính tập trung vào các liên kết thống kê: tìm mẫu, vừa đủ mô hình, dự đoán cái tiếp theo. Cách tiếp cận đó mạnh—nhưng thường vỡ khi bạn hỏi một câu sản phẩm hay kỹ thuật có chứa từ vì sao.
Bước chuyển lõi của Pearl là đặt nhân quả thành một khái niệm chính thức, không chỉ trực giác vòi vặt trên đỉnh các tương quan. Thay vì chỉ hỏi “Khi X cao thì Y có cao không?”, tư duy nhân quả hỏi: “Nếu chúng ta thay X, Y có thay không?” Sự khác biệt nghe có vẻ nhỏ, nhưng tách dự đoán ra khỏi ra quyết định.
Liên kết trả lời “cái gì thường xảy ra cùng nhau.” Nhân quả cố gắng trả lời “sẽ ra sao nếu chúng ta can thiệp.” Điều này quan trọng trong kỹ thuật vì nhiều quyết định thực sự là can thiệp: phát hành tính năng, thay xếp hạng, thêm biện pháp an toàn, thay tập huấn, hay chỉnh chính sách.
Pearl làm nhân quả thực tế hơn bằng cách đóng khung nó là một lựa chọn mô hình cộng với các giả định rõ ràng. Bạn không “khám phá” nhân quả tự động từ dữ liệu nói chung; bạn đề xuất một câu chuyện nhân quả (thường dựa trên kiến thức miền) rồi dùng dữ liệu để kiểm định, ước lượng và tinh chỉnh.
Những công cụ này cho đội ngôn ngữ chung để chuyển từ phát hiện mẫu sang trả lời câu hỏi nhân quả với rõ ràng và kỷ luật.
Tương quan nghĩa là hai thứ di chuyển cùng nhau: khi cái này tăng thì cái kia có xu hướng tăng (hoặc giảm). Nó rất hữu ích—đặc biệt với các đội nhiều dữ liệu—vì giúp dự đoán và phát hiện.
Nếu doanh số kem tăng khi nhiệt độ lên, tín hiệu tương quan (nhiệt độ) có thể cải thiện dự báo. Trong sản phẩm và AI, tương quan làm động lực cho mô hình xếp hạng (“hiển thị nhiều thứ người tương tự đã click”), phát hiện bất thường, và chẩn đoán nhanh.
Vấn đề bắt đầu khi ta coi tương quan như câu trả lời cho một câu hỏi khác: sẽ ra sao nếu chúng ta thay đổi điều gì đó có chủ ý? Đó là nhân quả.
Mối quan hệ tương quan có thể do yếu tố thứ ba ảnh hưởng cả hai biến. Thay đổi X không nhất thiết thay đổi Y—vì X có thể không phải là lý do Y thay đổi ngay từ đầu.
Giả sử bạn vẽ biểu đồ chi tiêu marketing hàng tuần so với doanh số hàng tuần và thấy tương quan dương mạnh. Dễ kết luận “chi tiêu cao hơn gây ra doanh số cao hơn.”
Nhưng giả sử cả hai đều tăng trong dịp lễ. Mùa vụ (một confounder) kích cầu hơn và cũng kích hoạt ngân sách lớn hơn. Nếu bạn tăng chi tiêu trong tuần không phải dịp lễ, doanh số có thể không tăng nhiều—vì nhu cầu nền không có.
Bạn đang ở vùng nhân quả khi tự hỏi:
Khi động từ là thay đổi, phát hành, loại bỏ, hoặc giảm, tương quan là manh mối bắt đầu—không phải quy tắc ra quyết định.
Một sơ đồ nhân quả—thường vẽ như DAG (Directed Acyclic Graph)—là cách đơn giản để làm cho các giả định của đội hiển thị. Thay vì tranh cãi mập mờ (“chắc là do model” hay “có thể do UI”), bạn đặt câu chuyện lên bảng.
Mục tiêu không phải là sự thật hoàn hảo; mà là bản nháp chia sẻ về “hệ thống chúng ta nghĩ thế nào” để mọi người phản biện.
Giả sử bạn đánh giá xem hướng dẫn onboarding mới (T) có tăng kích hoạt (A) hay không.
Phản xạ phân tích hay gặp là “kiểm soát mọi biến có sẵn.” Trong ngôn ngữ DAG, điều đó có nghĩa vô tình điều chỉnh cho:
Với một DAG, bạn điều chỉnh vì lý do rõ ràng—thường là để chặn đường confounding—thay vì vì biến đó tồn tại.
Bắt đầu với bảng trắng và ba bước:
Ngay cả một DAG thô cũng khiến PM, data và engineering cùng thắc mắc trên cùng một câu hỏi nhân quả trước khi chạy số.
Một thay đổi lớn trong tư duy nhân quả của Judea Pearl là tách quan sát khỏi thay đổi.
Nếu bạn quan sát người bật thông báo thì giữ retention tốt hơn, bạn học được một mẫu. Nhưng bạn vẫn chưa biết thông báo gây ra retention hay người dùng tương tác nhiều đơn giản là bật thông báo.
Một can thiệp khác: bạn chủ động đặt một biến về giá trị và xem điều gì xảy ra. Trong ngôn ngữ sản phẩm, đó không phải “người dùng chọn X,” mà là “chúng ta phát hành X.”
Pearl thường nhãn khác biệt này:
Ý tưởng “do” là ghi nhớ rằng bạn phá vỡ những lý do thường gặp khiến một biến có giá trị. Khi can thiệp, thông báo không còn BẬT vì người dùng tương tác; nó BẬT vì bạn ép hoặc khuyến khích. Đó là điểm mấu chốt: can thiệp giúp cô lập nhân quả.
Hầu hết công việc sản phẩm là hình thức can thiệp:
Những hành động này nhằm thay đổi kết quả, không chỉ mô tả chúng. Tư duy nhân quả giữ câu hỏi trung thực: “Nếu ta làm điều này, nó thay đổi gì?”
Bạn không thể diễn giải một can thiệp (hay thiết kế thí nghiệm tốt) mà không có giả định về ai ảnh hưởng ai—DAG của bạn, dù informal. Ví dụ, nếu mùa vụ ảnh hưởng cả chi tiêu marketing và đăng ký, thì “làm” thay đổi chi tiêu mà không tính mùa vụ vẫn có thể đánh lừa bạn. Can thiệp mạnh, nhưng chỉ trả lời câu hỏi nhân quả khi câu chuyện nhân quả nền tảng ít nhất là đúng xấp xỉ.
Phản thực là kiểu câu hỏi “nếu thế thì sao?” cụ thể: đối với trường hợp này, điều gì sẽ xảy ra nếu ta làm khác? Không phải là “trung bình sẽ thế nào?”—mà là “kết quả này có đổi cho người này, ticket này, giao dịch này không?”
Phản thực xuất hiện bất cứ khi nào ai đó xin đường đi đến kết quả khác:
Những câu hỏi này cấp độ người dùng. Chúng cũng đủ cụ thể để hướng thay đổi sản phẩm, chính sách và giải thích.
Giả sử mô hình khoản vay từ chối một hồ sơ. Giải thích dựa trên tương quan có thể nói: “Số tiền tiết kiệm thấp tương quan với bị từ chối.” Một phản thực hỏi:
Nếu tiền tiết kiệm của hồ sơ này cao hơn 3.000 đô (cùng mọi thứ còn lại), mô hình có duyệt không?
Nếu câu trả lời là “có”, bạn biết một điều có thể thay đổi quyết định. Nếu là “không”, bạn tránh khuyên vớ vẩn như “tăng tiết kiệm” khi rào cản thực sự là tỷ lệ nợ trên thu nhập hay việc làm không ổn định.
Phản thực phụ thuộc vào mô hình nhân quả—một câu chuyện về cách các biến tác động lẫn nhau—chứ không chỉ dataset. Bạn phải quyết định điều gì có thể thay đổi thực tế, điều gì sẽ thay đổi theo hậu quả, và điều gì phải giữ cố định. Không có cấu trúc nhân quả, phản thực có thể trở thành kịch bản không thể (“tăng tiền tiết kiệm mà không thay đổi thu nhập hay chi tiêu”) và dẫn tới khuyến nghị vô dụng hoặc không công bằng.
Khi một mô hình ML hỏng ở production, nguyên nhân gốc hiếm khi là “thuật toán kém hơn.” Thường hơn, có gì đó trong hệ thống thay đổi: dữ liệu bạn thu thập, cách gán nhãn, hoặc hành vi người dùng. Tư duy nhân quả giúp bạn ngừng đoán mò và bắt đầu cô lập thay đổi gây ra suy giảm.
Một vài thủ phạm lặp lại xuất hiện ở nhiều đội:
Những vấn đề này có thể trông “ổn” trong dashboard tổng hợp vì tương quan có thể vẫn cao ngay cả khi lý do mô hình đúng đã thay đổi.
Một DAG đơn giản biến gỡ lỗi thành bản đồ. Nó buộc bạn hỏi: feature này là nguyên nhân của nhãn, là hệ quả của nhãn, hay là hệ quả của cách ta đo lường nó?
Ví dụ, nếu Chính sách gán nhãn → Kỹ thuật feature → Đầu vào mô hình, bạn có thể đã xây pipeline nơi mô hình dự đoán chính sách chứ không phải hiện tượng nền tảng. Một DAG làm lộ đường đó để bạn có thể chặn nó (loại feature, thay instrumentation, hoặc định nghĩa lại nhãn).
Thay vì chỉ kiểm tra dự đoán, thử các can thiệp có kiểm soát:
Nhiều công cụ “giải thích” trả lời câu hỏi hẹp: Tại sao mô hình cho điểm này? Chúng thường làm điều đó bằng cách làm nổi bật đầu vào có ảnh hưởng (tầm quan trọng feature, bản đồ saliency, giá trị SHAP). Điều đó có ích—nhưng không giống như giải thích hệ thống mà mô hình nằm trong.
Giải thích dự đoán là cục bộ và mô tả: “Hồ sơ vay này bị từ chối chủ yếu vì thu nhập thấp và tỉ lệ sử dụng cao.”
Giải thích hệ thống là nhân quả và thực thi: “Nếu chúng ta tăng thu nhập được xác thực (hoặc giảm tỉ lệ sử dụng) theo cách phản ánh can thiệp thực tế, quyết định có đổi không—và kết quả hạ nguồn có cải thiện không?”
Cái trước giúp bạn diễn giải hành vi mô hình. Cái sau giúp bạn quyết định nên làm gì.
Tư duy nhân quả nối giải thích với can thiệp. Thay vì hỏi biến nào tương quan với điểm số, bạn hỏi biến nào là đòn bẩy hợp lệ và tác động của chúng khi thay đổi.
Một mô hình nhân quả bắt buộc bạn rõ ràng về:
Điều này quan trọng vì một feature “quan trọng” có thể là proxy—hữu ích cho dự đoán, nguy hiểm để hành động.
Giải thích hậu kiểm có thể thuyết phục trong khi vẫn thuần túy tương quan. Nếu “số ticket support” dự đoán churn mạnh, biểu đồ tầm quan trọng có thể cám dỗ đội “giảm ticket” bằng cách làm cho support khó tiếp cận hơn. Can thiệp đó có thể tăng churn, vì ticket là triệu chứng của vấn đề sản phẩm—không phải nguyên nhân.
Giải thích dựa trên tương quan cũng dễ gãy khi phân phối thay đổi: khi hành vi người dùng đổi, cùng các feature nổi bật có thể không còn ý nghĩa.
Giải thích nhân quả đặc biệt hữu dụng khi quyết định có hậu quả và cần trách nhiệm:
Khi bạn cần hành động, không chỉ diễn giải, giải thích cần có xương sống nhân quả.
A/B test là suy luận nhân quả dưới dạng thực tiễn nhất. Khi bạn gán ngẫu nhiên người dùng vào biến thể A hoặc B, bạn thực hiện can thiệp: bạn không chỉ quan sát lựa chọn người dùng, bạn đặt những gì họ thấy. Theo ngôn ngữ của Pearl, randomization làm cho “do(variant = B)” thành hiện thực—những khác biệt kết quả có thể đáng tin cậy quy cho thay đổi, không phải ai vô tình tiếp xúc.
Gán ngẫu nhiên phá nhiều liên kết ẩn giữa đặc tính người dùng và tiếp xúc. Người dùng quyền lực, người mới, thời điểm, thiết bị—các yếu tố này vẫn tồn tại, nhưng (trung bình) phân bố cân bằng giữa các nhóm. Sự cân bằng đó biến khoảng cách chỉ số thành tuyên bố nhân quả.
Ngay cả đội tốt cũng không lúc nào chạy được thử nghiệm ngẫu nhiên:
Trong trường hợp đó, bạn vẫn có thể nghĩ theo nhân quả—nhưng cần minh bạch về giả định và độ không chắc chắn.
Các lựa chọn phổ biến gồm difference-in-differences (so sánh biến đổi theo thời gian giữa nhóm), regression discontinuity (dùng ngưỡng như “chỉ người trên điểm X”), instrumental variables (một lực đẩy tự nhiên thay đổi tiếp xúc mà không trực tiếp thay đổi kết quả), và matching/weighting để làm các nhóm tương tự hơn. Mỗi phương pháp đổi ngẫu nhiên lấy các giả định; một DAG giúp bạn nêu rõ những giả định đó.
Trước khi phát hành thử nghiệm (hoặc nghiên cứu quan sát), ghi ra: chỉ số chính, guardrails, dân số mục tiêu, thời lượng và quy tắc ra quyết định. Tiền đăng ký không xóa bias, nhưng giảm việc chọn chỉ số phù hợp và làm cho tuyên bố nhân quả dễ tin hơn—và dễ tranh luận hơn trong đội.
Hầu hết tranh luận sản phẩm nghe như: “Chỉ số X tăng sau khi phát hành Y—vậy Y hiệu quả.” Tư duy nhân quả siết chặt thành câu hỏi rõ ràng hơn: “Thay đổi Y có khiến X thay đổi không, và bao nhiêu?” Sự chuyển này biến dashboard từ bằng chứng thành điểm khởi đầu.
Thay đổi giá: thay vì “Doanh thu tăng sau khi tăng giá?”, hãy hỏi:
Tinh chỉnh onboarding: thay vì “Người mới hoàn thành onboarding nhiều hơn,” hỏi:
Thay đổi xếp hạng đề xuất: thay vì “CTR cải thiện,” hỏi:
Dashboard thường trộn “ai nhận thay đổi” với “ai vốn đã làm tốt.” Ví dụ cổ điển: bạn phát hành flow onboarding mới, nhưng chỉ hiện đầu tiên trên phiên bản app mới nhất. Nếu người cập nhật phiên bản là người tương tác cao hơn, biểu đồ của bạn có thể chỉ ra lift phần nào (hoặc hoàn toàn) do việc cập nhật phiên bản, không phải onboarding.
Các confounder thường gặp trong phân tích sản phẩm:
Một phần PRD hữu dụng có thể đặt tiêu đề “Câu hỏi nhân quả,” bao gồm:
Nếu bạn dùng vòng lặp xây dựng nhanh (đặc biệt với dev hỗ trợ LLM), phần này càng quan trọng: tránh “phát hành nhanh” thành “phát hành mà không biết nó gây gì.” Các đội xây bằng Koder.ai thường nhúng những câu hỏi nhân quả này vào planning mode từ đầu, rồi triển khai các biến thể với feature flag nhanh, chụp snapshot/rollback để giữ thí nghiệm an toàn khi kết quả hay tác dụng phụ làm đội ngạc nhiên.
PM định nghĩa quyết định và tiêu chí thành công. Data chuyển nó thành ước lượng nhân quả và kiểm tra hợp lý. Engineering đảm bảo thay đổi có thể kiểm soát (feature flags, logging exposure rõ ràng). Support chia sẻ tín hiệu định tính—thay đổi giá thường “hoạt động” trong doanh thu trong ngắn hạn nhưng lặng lẽ tăng hủy hoặc ticket. Khi mọi người đồng thuận câu hỏi nhân quả, việc phát hành trở thành học hỏi—không chỉ phát hành.
Tư duy nhân quả không cần triển khai như bằng tiến sĩ. Hãy xem nó như thói quen đội: viết câu chuyện nhân quả, thử sức nó, rồi để dữ liệu (và thí nghiệm khi có thể) xác nhận hoặc sửa.
Để tiến bộ, thu bốn đầu vào trước:
Trong thực tế, tốc độ quan trọng: càng nhanh biến câu hỏi nhân quả thành thay đổi có kiểm soát, bạn càng ít thời gian tranh cãi về các mẫu mơ hồ. Đó là lý do các đội dùng Koder.ai chuyển từ “giả thuyết + kế hoạch” sang triển khai instrumented trong vài ngày thay vì vài tuần—vẫn giữ kỷ luật qua rollout theo giai đoạn và rollback.
Nếu bạn muốn ôn lại về thí nghiệm, xem /blog/ab-testing-basics. Để hiểu các bẫy phổ biến trong chỉ số sản phẩm, xem /blog/metrics-that-mislead.
Tư duy nhân quả là chuyển từ “cái gì thường di chuyển cùng?” sang “cái gì sẽ thay đổi nếu ta hành động?” Sự chuyển—được Judea Pearl phổ biến trong máy tính và thống kê—giúp đội tránh các câu chuyện nghe có vẻ tự tin nhưng không chịu nổi khi can thiệp thực tế.
Tương quan là manh mối, không phải câu trả lời.
Đồ thị nhân quả (DAG) làm cho giả định hiển thị và dễ tranh luận.
Can thiệp (“do”) khác với quan sát (“see”).
Phản thực giúp giải thích từng trường hợp: “nếu điều này khác thì sao?”
Công việc nhân quả tốt ghi lại sự không chắc chắn và các lời giải thích thay thế.
Nhân quả đòi hỏi thận trọng: confounder ẩn, lỗi đo lường và selection effect có thể lật ngược kết luận. Chống độc là minh bạch—ghi lại giả định, cho thấy dữ liệu dùng và nêu điều gì sẽ bác bỏ tuyên bố của bạn.
Nếu bạn muốn tìm hiểu sâu hơn, xem các bài liên quan trên /blog và so sánh cách tiếp cận nhân quả với các phương pháp analytics và “giải thích” khác để thấy chỗ nào hữu ích—và chỗ nào gây hiểu lầm.
Tương quan giúp bạn dự báo hoặc phát hiện (ví dụ: “khi X tăng, Y thường tăng theo”). Nhân quả trả lời câu hỏi quyết định: “Nếu chúng ta thay đổi X một cách có chủ ý, Y có thay đổi không?”
Dùng tương quan cho dự báo và giám sát; dùng tư duy nhân quả khi bạn chuẩn bị phát hành thay đổi, đặt chính sách hoặc phân bổ ngân sách.
Vì mối quan hệ có thể bị chi phối bởi biến gây nhiễu. Trong ví dụ thông báo, người dùng rất tương tác vừa kích hoạt/nhận nhiều thông báo hơn vừa trở lại nhiều hơn.
Nếu bạn tăng thông báo cho tất cả mọi người, bạn đã thay đổi trải nghiệm (một can thiệp) mà không thay đổi mức độ tương tác nền tảng — vì vậy retention có thể không cải thiện và thậm chí tệ hơn.
DAG (Directed Acyclic Graph) là một sơ đồ đơn giản nơi:
Nó hữu ích vì làm cho các giả định rõ ràng, giúp đội thống nhất về những gì cần điều chỉnh, những gì không nên điều chỉnh, và thí nghiệm thực sự nào trả lời câu hỏi.
Sai lầm phổ biến là “kiểm soát mọi thứ”, điều đó có thể vô tình điều chỉnh cho mediator hoặc collider và làm lệch kết quả.
“See” là quan sát những gì tự nhiên xảy ra (người dùng tự bật, điểm số cao). “Do” là chủ động đặt một biến (phát hành tính năng, ép mặc định).
Ý chính: một can thiệp phá vỡ những lý do thông thường khiến một biến có giá trị nhất định, và đó là lý do nó có thể tiết lộ mối quan hệ nhân quả đáng tin cậy hơn quan sát đơn thuần.
Một phản thực hỏi: đối với trường hợp cụ thể này, điều gì sẽ xảy ra nếu ta làm một điều khác.
Nó hữu ích cho:
Nó cần một mô hình nhân quả để bạn không đề xuất những thay đổi phi thực tế.
Tập trung vào điều gì đã thay đổi ở thượng nguồn và điều mà mô hình có thể đang lợi dụng:
Tư duy nhân quả thúc đẩy bạn thử các can thiệp có chủ ý (ablations, perturbations) thay vì đuổi theo các biến động trùng hợp trong số liệu.
Không hẳn. Tầm quan trọng tính năng giải thích điều gì ảnh hưởng tới dự đoán, không phải những gì bạn nên thay đổi.
Một feature “quan trọng” có thể chỉ là proxy hoặc triệu chứng (ví dụ: số lượng ticket support dự đoán churn). Can thiệp vào proxy (“giảm ticket bằng cách làm khó support”) có thể phản tác dụng. Giải thích nhân quả nối tầm quan trọng với đòn bẩy hợp lệ và kết quả kỳ vọng khi can thiệp.
Thử nghiệm A/B ngẫu nhiên là tốt nhất khi khả thi, nhưng bạn cần phương án khác khi:
Trong các trường hợp đó, hãy cân nhắc quasi-experiments: difference-in-differences, regression discontinuity, instrumental variables, hoặc matching/weighting—với việc minh bạch về giả định.
Thêm một phần ngắn buộc phải rõ ràng trước khi phân tích:
Điều này giữ đội đồng thuận trên một câu hỏi nhân quả thay vì kể chuyện sau khi nhìn dashboard.
