作者：
- 張婧婧 騰旭微信數據科學家
- 熊吉祥 騰訊微信 OLAP 研發工程師、StarRocks Contributor本文整理自微信工程師
在 StarRocks 年度峯會上的分享，介紹了因果推斷在業務中的應用，詳細闡述了基於 StarRocks 構建因果推斷分析工具的技術方案，通過高效算子的支持，大幅提升了計算效率。例如，t 檢驗在 6億行數據上的執行時間僅需 1 秒。StarRocks 還實現了實時數據整合，支持多種數據源（如 Iceberg 和 Hive）的無縫訪問，進一步增強了平台的靈活性與應用價值。
因果推斷介紹
什麼是因果推斷？
因果推斷的核心概念是，從數據中推斷一個變量對另一個變量的影響程度。簡單來説，它幫助我們瞭解因果關係的存在和影響力。例如，如果我們上線了一個新的算法模型，能否提升 DAU（日活躍用户）？又或者一個新的產品UI能否增加點擊率？這些問題本質上是在問：我們當前所採取的措施是否有效？做得是否正確？因果推斷正是用來回答這些問題的，它幫助我們做出科學的決策。
那麼，為什麼需要使用因果推斷呢？難道產品經理或者算法專家不清楚我們當前的做法是否合適嗎？實際上，這種不確定性是存在的。根據一項統計數據，全球一些領先互聯網公司的“上線成功改動率”遠低於預期。具體來説，這些公司在進行大量的 A/B 實驗後，最終能帶來有效成果的策略比例通常只有10%左右。像必應、Google Ads、Netflix 等公司都呈現出類似的情況[1]。這意味着，實際上即便是行業內的專家，也無法完全確定某一策略是否能夠產生預期效果，原因在於他們並非對產品和用户有足夠深入的理解。
接下來，有人可能會問，既然如此，為什麼不直接通過一些數字進行策略效果評估？例如，進行環比或同比分析，看看某一策略上線後，今天和昨天、或者上個週六和這個週六的數據對比，是否能夠反映出該策略的實際效果？然而，這種方式顯然存在問題。因為數據本身存在波動、週期性，且受到外界因素的影響，單純的對比並不足以準確歸因於該策略本身的影響。
此外，我們也可以使用時序模型來預測 DAU 的變化。如果沒有引入新的模型，我們可以通過舊有的推薦系統模型來預測 DAU 的變化。然而，在實際應用中，即便是預測 DAU 的誤差小於1%，也已經算是一個相對精準的模型了。但隨着增長的逐漸放緩，單個策略的效果通常難以超過1%，這意味着模型的誤差往往比實際增長還要大，因此很難依賴現有的模型來精確評估單一策略的效果。這時，因果推斷就顯得尤為重要。在互聯網行業，因果推斷的最常見應用之一就是 A/B 測試。
什麼是 AB test ？
具體來説，A/B 測試的過程是：從所有用户中隨機抽取兩組同質的用户羣體，其中一組用户使用原有的策略（A 組），另一組用户使用新策略（B 組）。接着，通過對比這兩組用户在關鍵指標上的差異，例如點擊率、停留時長等，來評估新策略的效果。通過這種方式，我們能夠明確將指標差異歸因於策略的變化。
一個經典的例子來自於谷歌的 Gmail 廣告優化[2]。最初，谷歌在確定廣告中藍色小鏈接的顏色時，採用的是傳統的方法，即由首席設計師或營銷總監拍板決定選用哪種顏色。然而，隨着 A/B 測試的引入，谷歌改變了這一做法。他們決定測試 40 種不同的藍色，來找出哪個藍色能獲得最高的點擊率。在實驗中，每個顏色方案會被展示給 1% 的用户，經過對比測試，他們最終發現，一種帶有輕微紫色調的藍色，比帶有綠色調的藍色點擊率更高。如此細微的調整，竟然為谷歌帶來了每年增加2億美元的廣告收入。
總結來説，因果推斷相較於傳統的報表分析，能夠提供更為準確的決策支持。之前提到的 A/B 測試，就是因果推斷中最經典的應用之一。因為 A/B 測試能夠通過將用户分為兩個完全同質的羣體，從而有效地評估策略的影響力。然而，在某些情況下，我們無法進行實驗，這時只能依賴離線推斷和觀測性因果推斷的方法，儘量通過數據糾偏，得到儘可能準確的結果。
具體的案例分享，將會在下文進行詳細講解。接下來，討論一下因果推斷與 StarRocks 的結合。為什麼我們需要藉助 StarRocks 來進行因果推斷呢？關鍵在於我們目前缺乏一種實時且分佈式的計算能力。
在互聯網應用場景下，數據量通常非常龐大。例如，微信的日活躍用户數就達到了上億級別。在這種數據量巨大的情況下，現有的因果推斷工具大多數是基於單機計算的，通常依賴 Python 等工具進行樣本抽樣計算。雖然單機模式在某些小規模數據的分析中可以工作，但面對如此龐大的數據量時，單機處理就會面臨很大的問題。首先，它會大大降低因果推斷的效果，具體體現在兩個方面：
- 互聯網場景下，面臨大數據量的因果推斷，目前的單機採樣損失效果。
- Power（統計檢驗顯著性）在因果推斷中，“Power” 代表的是進行統計檢驗時，策略有效果的時候能夠檢驗出顯著差異的能力。如果檢驗的 Power 較低，我們就可能無法確認策略的效果是否真實有效。舉個例子，如果某一指標的差異為 0.1%，而我們用 1 萬樣本進行檢驗，檢驗的能力只有 0.04，這意味着只有 4% 的概率能發現顯著差異。而如果我們使用 1 億樣本進行檢驗，可以百分之百檢驗出來。這就顯示出樣本量對檢驗結果的影響，單機處理時樣本量小、計算能力有限，可能無法準確地發現顯著差異。
- MSE（模型預估精度）單機計算會影響因果推斷模型的預估精度，尤其是在因果推斷與機器學習模型相結合時。以因果樹模型為例，我們用它來估算每個用户對策略的敏感度。如果我們使用 1 萬樣本進行訓練，估算得到的策略敏感度的誤差大約是 2.32。而如果我們使用 1 億樣本，誤差可以降低到 0.02，差距達到 100 倍。因此，樣本量不足會極大地影響因果推斷的精度，單機模式無法滿足這一需求。
-
因果推斷模型也需要複雜調參過程，需要實時分析能力
此外，因果推斷模型的調參過程也非常複雜。例如，在進行觀測性因果推斷時，我們需要選擇哪些關鍵的協變量進行匹配，並且匹配粒度的選擇也會影響結果的準確性。匹配之後，還需要進行魯棒性檢驗，確保結果的穩健性。整個過程涉及許多超參數的調節。如果我們使用的模型每次訓練需要 20 分鐘，而每次都需要反覆調整參數，這樣的分析可能需要一整天才能完成，這無疑是非常低效且難以接受的。因此，我們迫切需要一種實時且高效的分析能力，這是我們開發這個項目的初衷。我們的願景： All in SQL
目前，我們的整個項目已經沉澱為一個名為 Fast Causal Inference 的工具包，旨在提供高效的因果推斷功能。這個工具包已被開源，用户可以通過 Python 代碼進行調用，使用起來非常便捷。同時，為了提升靈活性，我們還提供了類似於 Spark SQL 的 SQL 查詢接口。
該工具包的底層架構基於 Olap 引擎 和 SQL 解析，支持對海量數據進行高效計算。例如，對於一個包含 6 億行數據的集，我們可以在秒級別內完成 t 檢驗（均值檢驗），計算時間僅需 0.32 秒，速度非常快。此外，該工具包涵蓋了多種常用的因果推斷模型，能夠滿足大多數因果分析的需求。
基於StarRocks構建因果推斷分析平台的技術方案
總體架構
接下來介紹一下如何通過 StarRocks 實現實時的因果推斷能力。在我們的架構中，StarRocks 能夠統一整合來自多種數據源的數據，包括 Iceberg 和 Hive 等。通過指定一個 Catalog，用户可以輕鬆地訪問這些不同的數據源。
在 StarRocks 中，我們還提供了高效的因果推斷算子，涵蓋假設檢驗、因果森林、匹配算法和迴歸方法等。藉助這些算子，我們可以在海量數據中快速完成因果推斷計算。例如，針對6億行數據，t 檢驗可以在一秒內完成。
除了提供底層的算子支持，我們還為數據科學家和數據分析師設計了更易用的接口，幫助他們更高效地完成工作。我們提供了兩種使用方式：
- All in SQL：針對最常用的因果模型，我們將其封裝為 SQL 查詢，用户無需深入瞭解複雜的查詢邏輯，即可快速獲得所需結果。
-
All in DataFrame：對於更高階的需求，用户可以通過 DataFrame API 定製複雜的因果推斷模型，滿足個性化的分析需求。
基於這些能力，我們打造了 Fast Causal Inference 項目，使得用户能夠在各種場景中應用因果推斷，例如異質性分析、觀測性分析及實驗分析等，為數據探索與決策提供強有力的支持。Fast-Causal-Inference：實時因果推斷的基座
在 StarRocks 上，我們實現了多種高效的因果推斷 UDF，並逐步貢獻給社區。這些算子涵蓋了廣泛的分析需求，包括：
- 假設檢驗：t 檢驗、SRM、permutation 檢驗、bootstrap 方法、方差估計、非參檢驗、k-s 檢驗、分位線檢驗等。
- Uplift 分析：因果樹、因果森林、Uplift 曲線等。
- 匹配分析：Caliper Matching、Exact Matching、SMD Joint Variable Importance Plot等。
- 迴歸分析：OLS/WLS、DID、Logistic 迴歸、AUC 等。
在實現這些因果推斷算子的過程中，我們採用了高效的步驟。例如，以 OLS（普通最小二乘法） 為例，我們將核心算法部分（如矩陣乘法）提取出來，作為 UDF 在 StarRocks 中高效實現。以矩陣乘法為例，通過將矩陣的轉置與乘法操作優化為聚合函數，能夠大大提升計算效率。
在實現這些因果推斷算子後，我們在 StarRocks 上進行了性能測試。下方的表格展示了測試結果，表明我們的 Fast Causal Inference 相較於 Spark 具有顯著的性能提升。
基於這些高效的因果算子，我們進一步封裝了一層 Causal Compiler。這一編譯器的誕生主要基於兩個原因：
- 某些複雜模型（如 CausalForest 和長短期記憶學習模型）難以用單一的 UDF 或 SQL 直接表達；
- 公司內部的大數據組件廣泛採用標準 SQL 語法。為了降低用户的使用和學習成本，我們開發了 Causal Compiler，使用户可以通過簡單的 SQL 函數表達複雜的因果推斷模型。
Causal Compiler 負責將用户編寫的 SQL 自動展開為 StarRocks 可直接執行的高效 SQL。例如，在 OLS（普通最小二乘法） 訓練過程中，編譯器會將其拆解為一系列矩陣運算，並最終執行優化後的計算過程。下圖展示了該轉換的示例。
在 All in SQL 方案的基礎上，我們進一步為高階數據分析師提供了更加便捷的 API，推出了 All in DataFrame。這一方案旨在簡化數據操作，提高開發效率和生產力。
以 PSM（傾向性得分匹配） 為例，其典型的處理流程如下：
- 數據預處理
- 計算傾向性得分
- 進行匹配
- 結果檢驗
如果使用 SQL 實現該流程，需要構造多個 CTE（公共表表達式），逐層進行處理。例如：先進行數據預處理，再劃分訓練集，計算傾向性得分，最後進行 t 檢驗。這種方式雖然可以完成計算，但 SQL 語句較為複雜，不易調試。往往需要運行較長時間後才發現錯誤，修改和重試的成本較高。
為了解決這一問題，我們開發了 DataFrame API，提供類似 PySpark 或 pandas 的編程方式，使用户能夠更直觀地編寫和執行數據分析任務。該 API 仍然依託於 StarRocks 進行底層計算，同時支持逐步執行各個數據處理環節，符合數據分析師的編碼習慣，大幅提升調試效率。此外，結合 Jupyter Notebook 等工具，用户可以更加便捷地進行數據探索和調試。
實時因果推斷助力微信業務增長的案例分享
實驗自助分析-均值檢驗和方差削減
在微信實驗平台中，我們可以通過隨機分流，將用户劃分為實驗組和對照組。分流完成後，需要評估實驗策略的效果，即實驗組用户的關鍵指標是否顯著高於對照組。如果顯著提升，則説明該策略具備正向收益。
均值檢驗（t 檢驗）
為此，我們提供了 ttest_2samp 函數，它支持均值檢驗，並採用 Delta Method 進行方差計算。這意味着它不僅適用於常規指標（如人均用户時長），也可用於更復雜的 點擊率等比例類指標，從而提高因果推斷的適用性。
方差削減（Variance Reduction）
實驗分析中的一大挑戰在於：指標噪聲較大，而策略收益往往較小，導致顯著性難以判斷。隨着實驗規模的擴大，這一問題愈發突出。方差削減的核心思想是 利用實驗前的協變量（如用户特徵、用户標籤）降低指標噪聲，使得原本波動較大的指標更加穩定，進而提升統計顯著性。
我們提供了兩種常見的方法：
- CUPED 方差削減：類似於迴歸模型，利用實驗前的數據預測實驗期間的指標，並用殘差替換原始指標，從而降低方差。
- 後分層方差削減：先根據協變量對用户進行分層分組，在每個組內計算均值，並加權合成整體指標，從而減少數據波動。
示例： 假設某項人均指標的方差為 0.7，應用方差削減後，方差降至 0.22，顯著性的概率大幅提升。
高階檢驗（非參檢驗）
在實驗分析中，有些指標呈現長尾分佈（如 GMV、用户時長），即：
- 少數用户貢獻極高的指標值（如 Top 1% > 100 萬），但90%用户集中在較低範圍（如 0-1000）。
- 分佈極端不均衡，導致均值檢驗的方差過大，難以顯著。
為了解決這個問題，我們引入 非參檢驗，即不直接比較指標值，而是比較排序。其原理是：
- 計算實驗組用户的平均排名，並與對照組對比，而非直接對比均值。
- 這種方法在 StarRocks 內部依賴全樣本快速排序，並提供高效計算函數。
示例： - 採用 t 檢驗時，某指標的 p 值 > 0.05（不顯著），表明實驗策略可能無效。
- 採用非參檢驗後，p 值 < 0.05（顯著），證明該策略確實帶來了正向收益。
異質性分析
在實驗分析中，我們不僅關心策略是否有效，更想知道它對不同用户的影響是否不同。這就是異質性分析的作用，它能計算用户對策略的敏感度，從而優化策略的應用場景，讓收益最大化。可以將異質性分析理解為策略收益的放大器，通過篩選合適的用户，使策略產生更強的正向影響。
典型應用場景
- 用户體驗優化：精準推送，避免負向影響
舉例，在用户召回場景下，可以通過推送消息來“拉活”用户，但不同用户的反應差異很大：
- 正向用户：收到推送後，願意回來使用產品，召回成功。
- 負向用户：覺得推送太煩，甚至卸載 App，帶來負面影響。
利用異質性分析，可以識別出容易被召回的用户，並避免向反感推送的用户發送消息，從而放大正向收益，減少負面影響。
- 作者激勵：冷啓動流量精準分配
舉例，內容平台可以通過冷啓動流量激勵作者創作，但並不是所有作者都會因流量扶持而積極創作：
- 高敏感作者：得到流量後，投稿量顯著增加。
- 低敏感作者：即使有流量扶持，創作意願變化不大。
異質性分析可以幫助識別對流量扶持最敏感的作者，優先給他們曝光，從而最大化策略的總收益。
技術挑戰與優化方案
在傳統的業務分析中，異質性分析往往通過多維度 Group By 下鑽的方式來進行，也就是按照不同的用户特徵進行交叉分組，分析各個羣體的策略效果。但這種方法存在明顯的侷限性：當用户特徵維度較多時，組合數量會呈指數級增長，計算量爆炸，同時也容易造成誤差積累，最終影響分析的可靠性。
為了更精準地進行異質性分析，我們提供了因果建模工具，包括因果樹（Causal Tree）和因果森林（Causal Forest）兩種方法。
因果樹的核心思路是，通過用户的歷史畫像進行建模，自動劃分出對策略最敏感的用户羣體。例如，在推送實驗中，因果樹可能會得出如下結論：最近7天內活躍過的用户更容易被推送召回，而最近30天未活躍的用户則對推送不敏感。這樣的分析結果非常直觀，業務人員可以直接據此優化投放策略。（上述圖片中的畫像均為構造舉例）
相比之下，因果森林則是一種更魯棒的建模方式。它會集成多棵因果樹，並綜合它們的結論，提供更穩定的個體化策略預測。雖然因果森林的結果不如因果樹直觀，但它可以提供更準確的個體化策略效果估計。除了這些建模工具，我們還提供了完整的模型評估與優化工具，幫助業務團隊選擇最優的建模方式。
觀測性分析--無法做實驗
在實際業務中，我們經常會遇到無法進行 A/B 實驗的情況。例如，當微信發佈新版本時，我們希望評估新版本是否存在 Bug 或者是否對用户行為產生影響。然而，我們不可能讓一半用户強制更新，而另一半用户不允許更新，因為這種做法不僅影響用户體驗，還可能導致負面反饋。
同樣的情況也會出現在運營活動分析中。例如，我們希望評估某個創作者激勵活動是否有效，但無法隨機分配創作者參加或不參加活動。因為本身願意參加活動的創作者往往更活躍，而不參加活動的創作者可能創作意願就較低。如果直接對比這兩組創作者的收入變化，結論很可能是有偏的，並不能真實反映活動的影響。在這種情況下，傳統的 A/B 實驗無法實施，而直接的報表分析也存在明顯偏差。那麼，我們應該如何進行合理的評估呢？這時候就要用到觀測性因果推斷的方法。
觀測性因果推斷的核心思想可以簡單理解為：雖然用户的特徵各不相同，但我們可以通過歷史數據找到儘可能相似的用户，然後在這些相似的用户之間進行對比。
在騰訊的實踐中，我們已經將觀測性因果推斷的方法應用到微信版本更新的分析中，並且實現了例行化工程，用於檢測新版本是否存在潛在問題。例如，每當微信發佈一個新的版本，我們都會利用這套方法去分析這個版本是否存在 Bug，比如數據丟失或其他異常情況。具體而言，我們需要先對特徵進行預處理，採用Joint Variable Importance Plot的方法去篩選出影響T又影響Y的重要混淆變量，並採用匹配的方法進行平衡混淆變量，最後，需要去驗證重要的協變量是否被平衡好，通常會去看SMD或者是直接做T檢驗看是否顯著。
如何驗證這套方法是否有效？
由於在這種場景下，我們無法進行傳統的 A/B 實驗（即無法讓一部分用户強制更新，另一部分用户保持舊版本），所以我們採用了歷史版本對比的方法進行驗證。具體來説，我們選取了兩類歷史版本：
- AA 版本（無 Bug 版本）：這些版本我們已經知道是沒有問題的，因此在分析時，我們的檢測方法不應該發現顯著差異。
- AB 版本（存在 Bug 版本）：這些版本確實有已知的 Bug，比如數據丟失等異常，因此我們的檢測方法應該能夠識別出明顯的差異。
通過這種方式，我們可以驗證：如果在 AA 版本中，分析方法沒有錯誤地檢測出差異，而在 AB 版本中，它能夠正確地發現 Bug，那麼這套方法在當前場景下就是有效的。當然，除了這種方式，我們還做了大量的驗證，以確保方法的魯棒性。
這種因果推斷分析不僅適用於微信版本更新，還可以推廣到各種運營活動的評估。
儘管這套方法在理論上是可行的，但它的最大難點並不在於計算量，而是分析流程複雜，主要體現在：
- 協變量篩選
- 平衡力度的控制
- 魯棒性檢驗
這些問題都需要分析師具備較高的因果推斷素養以及對底層原理的深刻理解，因此很難在企業內部大規模推廣。為了讓更多的業務團隊能夠更快、更準確地應用這套方法，我們在騰訊內部採取了以下措施：
- 挑選已經驗證有效的分析案例，並進行詳細的拆解。
- 將這些案例的分析流程封裝成標準化的分析 Pipeline，讓業務團隊能夠直接複用，降低濫用風險。
我們目前與社區有着緊密的合作，已經貢獻了大量的 StarRocks 算子，並且計劃在未來繼續將更多的 StarRocks 底層 UDF（用户定義函數）貢獻給開源社區。這不僅能增強社區的生態，也能夠為更多開發者提供有價值的工具和解決方案。
目前，Fast-Causal-Inference 已經開源，並且已經在 GitHub 上提供了完整的代碼和文檔。為了更好地展示我們的技術成果，我們特別為這次 StarRocks 分享搭建了一個在線服務。如果希望將代碼部署到本地的用户，我們也提供了簡單的部署方式。只需要將相關包下載到本地，按照文檔的説明操作，就可以開始嘗試和使用我們的工具。
開源地址: https://github.com/Tencent/fast-causal-inference
安裝：提供了Linux/MacOS/Windows環境的安裝鏡像；用户可以一鍵部署，並用notebook環境體驗，我們提供了測試數據集和使用示例。
（1）代碼部署：git clone https://github.com/Tencent/fast-causal-inference
（2）代碼示例參考： https://tencent.github.io/fast-causal-inference/index.html
參考資料[1] Ron Kohavi, Alex Deng, and Lukas Vermeer. 2022. A/B Testing Intuition Busters: Common Misunderstandings in Online Controlled Experiments. In Proceedings of the 28th ACM SIGKDD Conference on Knowledge Discovery and Data Mining (KDD '22). Association for Computing Machinery, New York, NY, USA, 3168–3177. https://doi.org/10.1145/3534678.3539160
[2]https://www.theguardian.com/technology/2014/feb/05/why-google...
其他閲讀推薦：微信基於StarRocks的湖倉一體實踐
跟多交流，聯繫我們：https://wx.focussend.com/weComLink/mobileQrCodeLink/33412/515d5
