Suy luận nhân quả trong kinh doanh: Khi sự nghiêm ngặt gặp thực tế

Tất cả những gì bạn học được về suy luận nhân quả (causal inference) trong học thuật đều là đúng. Tuy nhiên, điều đó là chưa đủ, và hầu hết những người làm thực tế đều trải nghiệm điều này.

Điều thực sự khác biệt nằm ở trọng số của quyết định dựa trên phân tích đó: không phải quyết định nào cũng xứng đáng với cùng một mức độ bằng chứng. Hãy phù hợp hóa sự nghiêm ngặt và suy luận nhân quả của bạn với tầm quan trọng của quyết định, nếu không bạn sẽ lãng phí nguồn lực.

Hãy lấy ví dụ về việc khám phá sản phẩm (product discovery). Trước khi xây dựng và phát hành, nhiều giả định cần được xác thực tại nhiều bước. Nhắm đến việc đưa ra câu trả lời hoàn hảo bằng suy luận nhân quả cho mỗi bước để làm gì? Đó chỉ là di chuyển một ô trên một bàn cờ đầy rẫy các quyết định liên quan, thậm chí là cần thiết, nhưng riêng lẻ chúng thì chưa đủ. Rủi ro đã được phân tán và phòng ngừa qua nhiều quyết định, nhờ vào một quy trình đề cao bằng chứng gia tăng, việc học hỏi và các lần lặp lại.

Đồng thời, suy luận nhân quả đi kèm với chi phí cơ hội đáng kể: sự nghiêm ngặt làm trì hoãn thời gian tạo ra tác động, trong khi có thể có một dự án khác đang chờ bạn, nơi sự nghiêm ngặt này thực sự cần thiết để cải thiện chất lượng quyết định (giảm rủi ro, tăng độ chính xác và độ tin cậy).

Khung khái niệm tôi thường dùng để làm rõ ý tưởng này là sự phân biệt giữa Quyết định mang tính xây dựng (Constructive decisions) và Quyết định mang tính cam kết (Final decisions):

Quyết định mang tính xây dựng giúp bạn tiến lên trong quy trình. "Chúng ta có nên khám phá tính năng này thêm không?", "Vấn đề của người dùng này có đáng để điều tra không?". Sai lầm ở đây chỉ tốn của bạn một sprint, có thể là hai, trong khi làm đúng cũng chưa thay đổi được công ty ngay lập tức.

Quyết định mang tính cam kết là việc cam kết nguồn lực hoặc thay đổi hướng đi, và sai lầm ở đây rất tốn kém hoặc khó đảo ngược: "Chúng ta có nên đầu tư 2 triệu USD để xây dựng cái này không?", "Chúng ta có nên ngừng dòng sản phẩm này không?", "Chúng ta có nên phân bổ ngân sách marketing nhiều hơn vào kênh này hay kênh kia?".

Trong lĩnh vực công nghệ, khối lượng và tốc độ của các quyết định là vô song. Đôi khi, đó là các quyết định mang tính cam kết. Nhưng phổ biến hơn nhiều là các quyết định mang tính xây dựng.

Là những nhà khoa học dữ liệu, chúng ta tham gia vào cả hai loại quyết định này. Việc không nhận ra khi nào mình đang đối mặt với loại này hay loại kia sẽ dẫn đến việc đặt sai câu hỏi hoặc truy đuổi sai câu trả lời, cuối cùng là lãng phí nguồn lực.

Trong bài viết này, tôi muốn đưa ra ba nguyên tắc mà tôi thường quay lại khi bắt đầu các dự án suy luận nhân quả:

1. Bắt đầu từ vấn đề, không phải từ câu trả lời.
2. Nếu bạn có thể giải quyết nó đơn giản hơn mà không cần suy luận nhân quả, hãy làm vậy.
3. Áp dụng nguyên tắc 80/20 cho dự án suy luận nhân quả của bạn.

Nguyên tắc thì hiếm khi nghe thú vị. Nhưng những nguyên tắc này đã giúp tôi tăng đáng kể tác động của mình.

Hãy cùng đi sâu vào từng phần.

1. Bắt đầu từ vấn đề, không phải từ câu trả lời

Mọi dự án suy luận nhân quả đều bắt đầu từ vấn đề bạn đang cố gắng giải quyết; không phải bắt đầu từ chiến lược nhận dạng (identification strategy) hay bộ ước lượng (estimator). Đây là ví dụ hoàn hảo của việc "làm đúng việc" thay vì "làm việc đúng cách". Phương pháp của bạn có thể rất xuất sắc, nhưng giá trị ở đâu nếu bạn đang giải quyết sai vấn đề? Hãy tự thúc đẩy mình bắt đầu một dự án với một vấn đề kinh doanh rõ ràng đang đứng sau nó, và bạn sẽ thấy 50% công việc đã hoàn thành trước khi bắt đầu.

Nếu bạn có kỹ thuật cao, khả năng cao là bạn biết cấu trúc giải phẫu của một dự án suy luận nhân quả: từ DAG (đồ thị có hướng không chu trình) đến mô hình, suy luận, phân tích độ nhạy và câu trả lời.

Nhưng bạn có biết cấu trúc giải phẫu của việc giải quyết vấn đề trong tổ chức không?

Vấn đề đằng sau vấn đề

Những vấn đề lớn được chia nhỏ thành các vấn đề nhỏ hơn. Điều đó dễ quản lý hơn cho một đội nhóm cần tìm giải pháp. Và nó cho phép chúng ta huy động nhiều đội nhóm để giải quyết các phần khác nhau của vấn đề lớn (hoặc vấn đề con) đó. Điều tương tự cũng xảy ra giữa các vai trò trong một đội nhóm: bạn đang ước tính các yếu tố dẫn đến rời bỏ (churn drivers); quản lý sản phẩm (PM) của bạn cần thông tin đó để quyết định đầu tư vào giữ chân hay thu hút người dùng mới.

Đó là thách thức: vấn đề mà bạn, với tư cách là nhà khoa học dữ liệu, đang giải quyết thường không phải là mục tiêu cuối cùng.

Vấn đề của bạn được lồng ghép bên trong vấn đề của người khác. Những người khác, xung quanh và trên bạn, cần câu trả lời của bạn như một đầu vào cho giải pháp của họ. Nhận ra sự phụ thuộc đó, và bạn có thể điều chỉnh suy luận nhân quả của mình cho những gì thực sự quan trọng ở thượng nguồn. Những chiến thắng cụ thể bao gồm: sự đồng thuận chặt chẽ hơn về ước lượng nhân quả quan tâm, hoặc loại bỏ suy luận nhân quả nhanh hơn. Tóm lại: thời gian để có được thông tin chi tiết (insight) ngắn hơn.

Có một lần, tôi đắm chìm trong lý thuyết mạng (Trường ngẫu nhiên Markov là thứ giúp tôi hiểu về DAG vào năm 2018). Trong đầu tôi, mọi thứ đều là một mạng lưới. Vì vậy, tôi đã tạo ra một mạng lưới về việc sử dụng năng lực BI nội bộ của chúng tôi. Tất cả các bảng điều khiển (dashboard) là các nút, và chúng sẽ có các cạnh dày hơn giữa chúng khi được sử dụng bởi cùng một người dùng. Tôi đã tính toán tất cả các loại chỉ số trung tâm; tôi xác định được các bảng điều khiển có ảnh hưởng: những bảng điều khiển kết nối các phòng ban với nhau; và nhiều hơn nữa. Tôi đã xây dựng một câu chuyện hoàn chỉnh xung quanh nó, nhưng không có hành động nào theo sau. Vấn đề là tôi chưa bao giờ chú ý đến vấn đề mà các bên liên quan của mình đang cố gắng giải quyết. Có lẽ tôi nghĩ quyết định đó là loại "cam kết", trong khi thực tế nó luôn là loại "xây dựng". Một phép đếm đơn giản về việc sử dụng bảng điều khiển có thể đã đủ để giải quyết công việc, nhưng tôi đã coi đó là một dự án nghiên cứu.

Đó là tôi của ngày xưa. Và đó không phải là lần cuối cùng chuyện như vậy xảy ra. Nhưng bài học rút ra là hãy bắt đầu từ vấn đề, không phải từ câu trả lời.

Nguyên tắc ngược lại: nhìn vào sai vấn đề

Nếu bạn muốn một cách nhanh chóng để vứt tiền qua cửa sổ, hãy đi giải quyết những vấn đề sai. Không chỉ các giải pháp không có kết quả thực tế, mà chi phí cơ hội của việc không giải quyết đúng vấn đề trong thời gian đó sẽ tích lũy ngày càng nhiều.

Vì vậy, trong việc nôn nóng tìm ra "vấn đề đằng sau vấn đề", hãy phản biện xem liệu đó có phải là vấn đề đúng để bắt đầu hay không, khi bạn tìm thấy nó.

Theo nghĩa đó, việc bắt đầu với câu trả lời thực sự mang lại giải pháp. Nhưng nó hơi khác một chút. Hãy tự hỏi mình:

• Nếu chúng ta có được những câu trả lời này, chúng ta biết điều gì mà chúng ta chưa biết trước đây?
• Nếu chúng ta biết điều đó, thì sao?

Nếu câu trả lời cho câu hỏi "thì sao" có ý nghĩa rất lớn, không chỉ với bạn mà còn với quản lý của bạn và quản lý của họ (có lẽ), thì bạn đang giải quyết đúng vấn đề.

Thật kỳ diệu.

2. Nếu bạn có thể giải quyết nó đơn giản hơn mà không cần suy luận nhân quả, hãy làm vậy

Không có một khuôn mẫu nào cho suy luận nhân quả. Các phương pháp trở nên kinh điển vì chúng ta đã ánh xạ tốt các giả định của chúng; không phải vì việc sử dụng chúng là máy móc. Mọi tình huống đều có thể vi phạm các giả định đó theo cách riêng của nó, và mỗi tình huống xứng đáng có sự nghiêm ngặt đầy đủ.

Thách thức ở đây là chúng ta không thể biện minh cho việc làm như vậy với tất cả chúng về mặt nguồn lực.

Đó là lúc việc áp dụng suy luận nhân quả trở thành một bài tập kinh tế: chúng ta nên bỏ bao nhiêu nguồn lực để đạt được kết quả mong muốn với mức độ tin cậy cần thiết?

Hãy tự hỏi câu hỏi đó lần tới.

May mắn thay, không phải mọi phân tích đều cần nghiêm ngặt như một dự án suy luận nhân quả đầy đủ để khiến lợi nhuận đầu tư (ROI) nghiêng về phía dương.

Các lựa chọn thay thế: ý thức chung, kiến thức lĩnh vực và phân tích liên kết (associative analysis), cũng đưa ra các câu trả lời "đủ tốt".

Nói điều này chắc hơi đau một chút; bản nguyên tắc và nghiêm ngặt trong tôi ghét tôi bây giờ. Nhưng tôi đã học được rằng việc tiếp cận sự đánh đổi này như một lựa chọn chiến lược là đáng giá.

Dưới đây là một ví dụ để minh họa:

Câu hỏi là: chúng ta có nên đầu tư thêm vào tính năng A không? Bây giờ, tôi có thể dễ dàng đảo ngược nó thành: tác động của tính năng A đối với việc thu hút/giữ chân người dùng là gì? (một góc độ rất phổ biến trong tình huống SaaS; và là một câu hỏi nhân quả cốt lõi).

Nếu nó cao, chúng ta đầu tư vào nó, nếu không thì thôi.

Chỉ riêng từ "tác động" (impact) đã đẩy tôi vào chế độ suy luận nhân quả, vì tác động khác với sự liên kết. Nhưng chúng ta biết điều đó rất tốn kém. Vấn đề có đáng không? Lựa chọn thay thế là gì?

Một cách tiếp cận là hiểu có bao nhiêu người dùng đang sử dụng tính năng này. Họ sử dụng nó thường xuyên như thế nào, với điều kiện họ đã chọn sử dụng nó? Điều đó cho thấy tính năng đó có thể có giá trị như thế nào, và tín hiệu rằng chúng ta có thể đầu tư thêm vào tính năng này. Không cần diff-in-diff (chênh lệch theo chênh lệch), không cần IPSW (trọng số xác suất nghịch đảo), không cần thử nghiệm A/B: nhưng nếu những câu trả lời đó trả về tiêu cực, liệu một suy luận nhân quả chính xác có còn quan trọng không?

Sự thật có thể nằm ở giữa; câu trả lời cho những câu hỏi đó có thể mang tính gợi ý hơn là quyết định, và câu hỏi chính có thể vẫn cảm thấy còn mở. Nhưng chắc chắn, nó ít mở hơn so với khi bạn bắt đầu: nếu những câu trả lời đó khơi dậy nghiên cứu sâu hơn, thì đội ngũ sản phẩm đã chuyển động, và có khả năng là theo đúng hướng. Có lẽ sẽ theo sau là suy luận nhân quả nghiêm ngặt hơn.

Nguyên tắc ngược lại: bỏ qua suy luận nhân quả là nguy hiểm

Giả sử, đội ngũ sản phẩm nhận các tín hiệu từ phân tích của bạn và thực hiện một số "cải tiến" vật lý cho tính năng. Quy mô mẫu thấp và họ thiếu thời gian, vì vậy họ bỏ qua thử nghiệm A/B và tung ra trực tiếp.

Những người cuồng nhiệt về thí nghiệm sẽ phát điên lúc này. Tôi nghĩ rằng có thể đó là quyết định đúng, nếu ai đó đã tính toán và kết luận rằng việc thử nghiệm rủi ro hơn là không thử nghiệm. Tất nhiên tôi giữ trường hợp quá chung chung nên không ai thực sự có thể bảo vệ bên nào. Điều đó sẽ đi quá xa điểm.

Nhưng sau đó, trong khi đội nhóm chuyển sang sprint tiếp theo, quản lý sản phẩm vẫn nhấn mạnh tầm quan trọng của việc học hỏi điều gì từ những gì họ đã tung ra trước đó. Họ vẫn muốn a) có cảm giác về tác động, và b) xem liệu một số phân khúc có bị ảnh hưởng nhiều hay ít hơn những phân khúc khác không.

Bạn vui vì việc học hỏi -> các lần lặp lại chính xác là tư duy bạn đang cố gắng thúc đẩy. Nhưng bạn cũng đang đau đớn vì ít nhất ba lý do:

• Thiếu tính có thể hoán đổi (exchangeability): bạn biết rằng những người dùng tiếp tục sử dụng tính năng là một tập hợp tự chọn rất cao. Đối chiếu họ với người không dùng. Thật sao?
• Các tác động tương tác: giả sử rằng một phân khúc thực sự bị ảnh hưởng nhiều hơn những phân khúc khác. Bây giờ nhớ lại điểm đầu tiên: chúng ta đang điều kiện hóa trên những người dùng có mức độ tương tác cao. Có thể là phân khúc đó hiển thị tác động cao hơn chỉ đơn giản là vì người dùng cũng có mức độ tương tác cao. Cùng một phân khúc có thể không hiển thị tác động khác biệt đó khi chúng ta xem xét người dùng có mức độ tương tác thấp hơn. Nhưng bạn không thể biết. Dữ liệu bạn đang làm việc bị lệch về những người dùng có mức độ tương tác cao chỉ.
• Thiên lệch va chạm (Collider bias): trong trường hợp xấu nhất, việc điều kiện hóa mức độ tương tác cao có thể đảo ngược mối quan hệ giữa các phân khúc và kết quả quan tâm. Phân tích sẽ dẫn đội nhóm đi sai hướng.

3. Áp dụng nguyên tắc 80/20 cho dự án suy luận nhân quả của bạn

Tiêu đề ở đây hơi gây hiểu lầm. Tôi không nói là làm phân tích hời hợt: khi câu hỏi đòi hỏi sự nghiêm ngặt đầy đủ, hãy đưa ra nó. 80/20 là về việc nỗ lực của bạn đi đâu trong một quyết định, không phải bạn đào sâu vào phần nhân quả như thế nào.

Hãy nhớ lại ý tưởng về các vấn đề lồng ghép. Dự án suy luận nhân quả của bạn thường nằm bên trong một quyết định kinh doanh lớn hơn, và hiếm khi nó là chiều kích duy nhất quan trọng. Bên liên quan phải cân nhắc chi phí, thời gian, sự phù hợp chiến lược, tính có thể đảo ngược; cùng với ước tính của bạn. Suy luận nhân quả không phải là mọi thứ chúng ta cần biết.

Nếu câu trả lời nhân quả của bạn chiếm 30% trọng số trong quyết định đó, đối xử nó như 100% là lãng phí. Tệ hơn: đó là lãng phí với chi phí cơ hội, vì 70% còn lại chưa được giải đáp.

Đây là lúc khung khái niệm giữa quyết định xây dựng và cam kết phát huy tác dụng. Đối với các quyết định mang tính xây dựng, việc phân bổ nỗ lực trên nhiều chiều kích gần như luôn tốt hơn là đào sâu vào một chiều. Đối với các quyết định mang tính cam kết, chiều kích nhân quả thường là cốt lõi, và toán học sẽ nghiêng về phía kia.

Nguyên tắc 1, 2 và 3 chồng lên nhau nhưng chúng không giống nhau. Nguyên tắc 1 hỏi liệu bạn đang giải quyết đúng vấn đề chưa. Nguyên tắc 2 hỏi liệu bạn có cần suy luận nhân quả không. Nguyên tắc 3 giả định bạn đã vượt qua cả hai. Bây giờ câu hỏi là: trong dự án, bạn có đang trả lời đúng các câu hỏi (số nhiều) không, và để suy luận nhân quả chỉ gánh vác trọng lượng thực sự của nó?

Hãy chuyển giao quyết định, không phải ước tính

Một dự án gần đây: ước tính tác động của một mức giá mới trên doanh thu trên mỗi người dùng. Theo bản năng, tôi đã tìm kiếm chiến lược nhận dạng sạch nhất mà tôi có thể triển khai. Chênh lệch theo chênh lệch với độ nhạy xu hướng song song, thử nghiệm giả dược (placebo tests), có thể là một đối tượng tổng hợp (synth control) để chắc chắn. Dễ mất một tháng làm việc.

Nhưng khi tôi thu nhỏ lại, PM có ba câu hỏi mở, không phải một:

• Tác động đến doanh thu trên mỗi người dùng là gì? (nhân quả)
• Chúng ta có đang ăn mòn (cannibalising) mức giá hiện có không? (nhân quả, kết quả khác)
• Điều này có thể đảo ngược như thế nào nếu nó thất bại? (không nhân quả; một câu hỏi vận hành và sản phẩm)

Dành một tháng cho câu hỏi 1 sẽ để lại câu hỏi 2 và 3 được trả lời một nửa. Quyết định cần cả ba đều approximately đúng (đúng về cơ bản), không phải một cái chính xác tuyệt đối. Vì vậy: một diff-in-diff chặt chẽ hơn cho câu hỏi 1 trong hai tuần, với các lưu ý rõ ràng, và thời gian còn lại cho câu hỏi 2 và 3. Bên liên quan bước vào cuộc họp quyết định với một bức tranh cân bằng thay vì một con số và cái gật đầu ngơ ngác.

Nguyên tắc ngược lại: khi câu hỏi nhân quả là quyết định

Nếu bạn áp dụng 80/20 cho một dự án suy luận nhân quả nơi ước lượng nhân quả là toàn bộ quyết định, bạn đã làm rỗng phân tích đó.

Đây là kịch bản quyết định mang tính cam kết. "Chúng ta có nên đầu tư 2 triệu USD vào kênh này không?", "Liệu phương pháp điều trị này có gây ra sự giảm ý nghĩa trong việc rời bỏ khách hàng không?". Khi các chiều kích khác đã được xác định hoặc thực sự thứ yếu, ước lượng nhân quả không phải là một trong nhiều đầu vào; nó là đầu vào. Cắt góc ở đó để giải phóng thời gian cho công việc không thay đổi quyết định là đảo ngược nguyên tắc ban đầu: bây giờ bạn đang phân bổ sai theo cách khác.

Kỹ năng là biết tình huống nào bạn đang ở. Một thử nghiệm nhanh: nếu bạn không thể liệt kê ba chiều kích mà bên liên quan cần ngoài ước tính của bạn, câu trả lời nhân quả của bạn có lẽ là quyết định. Đừng 80/20 cái đó.

Vậy thì bây giờ làm gì?

Những nguyên tắc này áp dụng cho tất cả các công việc phân tích, không chỉ suy luận nhân quả. Nhưng suy luận nhân quả là nơi tôi cảm thấy nó mạnh mẽ nhất trong các vai trò trước đây của mình.

Bất cứ khi nào tôi cảm thấy bị lôi kéo bởi một đối tượng tổng hợp (synth control) sạch đẹp cho một câu hỏi không ai hỏi, đây là những lời nhắc nhở tôi dán lên trán mình:

Các phương pháp đến từ việc học chúng. Đó là điều tôi sẽ không ngừng. Nhưng ở ngoài kia, trên chiến trường, hãy sắc bén về việc khi nào áp dụng chúng mang lại lợi ích, và khi nào thì không.

Nếu một trong những nguyên tắc này giúp bạn tiết kiệm được một lần sprint lần tới, hoặc một cuộc tranh luận với PM, đó đã là một chiến thắng; và những chiến thắng đó sẽ cộng gộp. Sự nghiêm ngặt sẽ xuất hiện khi nó quan trọng. Phần còn lại thời gian của bạn dành cho những thứ cũng quan trọng khác.

Tôi rất vui được có một cuộc tranh luận lành mạnh với bạn về tất cả những điều trên. Kết nối với tôi trên LinkedIn, hoặc theo dõi trang web cá nhân của tôi để có thêm nội dung như thế này!