AI 因果推論入門：statsPAI 讓 Agent 唔止認 pattern 仲識因果

而家個個都講 AI Agent，但大部分 Agent 嘅「推理」其實只係 pattern matching。畀佢睇一萬個例子，佢學識「每次 A 發生之後 B 就跟住發生」，於是下次見到 A 就 predict B。問題係：點解 A 會導致 B？如果個 system 改變咗，呢個 pattern 仲 work 唔 work？傳統 machine learning 答唔到呢個問題，因為 correlation 永遠唔等於 causation。

史丹福團隊最近開源咗 statsPAI，一個專為 AI Agent 設計嘅因果推論同計量經濟學工具包，成 1020 個註冊函數，81 個子模組。呢個唔係另一個 Python library 咁簡單——佢係教識 Agent 點樣「諗因果」嘅基礎設施。對於香港做自動化決策系統嘅開發者嚟講，呢個工具包嘅出現可能係今年最重要嘅開源事件之一。

點解 Agent 需要因果推論，而唔係更多 data？

先講一個 concrete 例子。假設你寫咗個 Agent 幫客戶做 pricing optimization。傳統 ML 做法係 train 個模型，睇住歷史數據入面「減價 → 銷量上升」嘅 pattern，然後 recommend 減價。但現實世界入面，銷量上升可能係因為競爭對手同時加咗價、或者嗰個星期係消費券發放日。你嘅 Agent 根本分唔到邊個因素係真正嘅 cause。

呢個就係因果推論入場嘅地方。同 predicting 唔同，causal inference 嘅目標係估計「如果我把 X 改變一個單位，Y 會改變幾多？」——即係 treatment effect。DiD（Difference-in-Differences）幫你比較政策實施前後嘅變化，IV（Instrumental Variables）幫你搵出真正嘅外生變異，Synthetic Control 幫你構造一個「如果冇發生某件事」嘅反事實世界。呢啲唔係學術玩具，而係真實世界做決策嘅核心工具。

StatsPAI 嘅做法係將呢啲方法全部標準化為 machine-readable 嘅 function schema。Agent 唔使「讀論文理解 DiD 嘅假設」，而係直接 call did_estimate()，個 function 會回傳一份完整嘅 schema，包括 inputs、outputs、assumptions、同 diagnostics requirement。對 Agent 嚟講，呢個就好似畀咗佢一個「因果推理嘅 API」。

1020 個函數唔係數字遊戲，而係認知框架

我第一次睇到 1020 呢個數字嘅時候都諗：係咪為�湊數？深入睇完先發現，呢 1020 個函數覆蓋咗 23+ 個方法家族，每個家族入面有唔同嘅變體、robustness check、同 diagnostics。唔係「一個 DiD function 行天下」，而係 did_estimate（基本估計）、did_parallel_trends_test（平行趨勢假設檢定）、did_placebo_test（安慰劑檢定）、did_sensitivity（敏感性分析）——成個工作流程，唔係 single point solution。

對於 Agent 嚟講，呢個結構特別重要。人類 econometrician 做 causal inference 嘅時候，唔係 run 完一個 regression 就收工，而係要做一大堆 specification checks、robustness tests、同 sensitivity analyses。StatsPAI 嘅函數結構直接 reflect 咗呢個 workflow，令 Agent 可以 follow 相同嘅 rigour。呢個係將 econometrician 嘅 domain knowledge 編碼成 code，而唔係將佢哋取代。

另外值得一提嘅係，佢哋做咗 51 個 R 對齊模組，即係每個 function 嘅 output 同相應嘅 R package（如 fixest、estimatr、ggplot2 相關 diagnostics）做過 cross-validation。呢個對香港做 quantitative research 嘅人嚟講好重要——你唔使驚「Python 出嘅結果同 R 唔一樣」嗰種尷尬。

對 Agent 開發者嚟講，呢個代表咩？

香港好多開發者喺度做 fintech、prop trading、同 supply chain 嘅自動化系統。呢啲領域嘅核心問題唔係「predict 準唔準」，而係「make decisions under uncertainty」。Agent 要決定落唔落個 trade、批唔批呢筆貸款、調整唔調整庫存水平——呢啲全部係 causal questions，唔係 pattern recognition。

用 statsPAI 嘅思維去設計 Agent，同傳統 ML agent 有個根本分別。ML agent 嘅 output 係 prediction，然後由人類去 decide。Causal agent 嘅 output 直接係 decision recommendation，因為佢 internalize 咗「如果我咁做，個 outcome 會係點」嘅反事實推理。呢個 shift 係 fundamental 嘅——你由「幫人類提供資訊嘅工具」變成「可以直接參與決策嘅系統」。

當然，呢個唔代表你可以寫個 Agent 然後完全放手。Causal inference 嘅核心挑戰係 identification——你嘅估計有冇 bias？啲 assumptions 成唔成立？StatsPAI 嘅功能嘅強項係佢逼你面對呢啲問題：每個 estimator 都會要求你 specify 啲 assumptions（parallel trends、exclusion restriction、overlap），而 diagnostics functions 就會幫你 check 呢啲 assumption 喺 data 入面成唔成立。

對於我哋呢啲 independent developers 嚟講，呢個工具嘅最大價值係降低咗 causal inference 嘅入場門檻。以前你要讀晒 Angrist & Pischke、搞清楚晒所有 identification strategies、先敢喺 production 用 DiD。家陣你可以用 statsPAI 做 prototyping，每個 step 都有 diagnostics 話你知你嘅估計信得過定信唔過。唔代表你要學少啲嘢，但代表你可以學得快啲、錯得平啲。

你應該點樣開始

如果你想認真試 statsPAI，我建議你唔好一開始就 plug 入 production system。先做呢三件事：

第一，揀一個你熟悉嘅商業問題，最好係你有 historical data 而且知道個 ground truth 嘅。用 statsPAI 嘅 did_estimate 或者 rd_estimate 去做 estimation，睇下個 result 同你 domain knowledge 係咪吻合。呢個係幫你 build intuition 最快嘅方法。

第二，玩吓佢哋嘅 diagnostics 功能。did_parallel_trends_test 同 did_placebo_test 呢類函數唔係學術點綴——佢哋係幫你 detect 你嘅 causal claim 有冇問題嘅實用工具。識得 read 呢啲 diagnostics output，比識得 run estimation 重要十倍。

第三，試吓用 function_schema() 輸出嘅 machine-readable schema 去 integrate 一個簡單嘅 Agent loop。唔需要複雜——畀個 Agent 一個 dataset，叫佢「用 DiD estimate 呢個 treatment 嘅 effect，然後解釋你點解揀呢個 specification」。你會發現，當 Agent 有咗 causal vocabulary 之後，佢嘅「推理」明顯同淨係靠 pattern matching 嘅時候唔同。

最後講句嘢：因果推論唔係 magic，佢 require 你對 data generating process 有理解。StatsPAI 幫你降低咗 execution cost，但冇降低到 thinking cost。作為開發者，我哋嘅責任係用呢啲工具去問 better questions，而唔係盲目信 output。真正嘅 causal inference 由人類嘅 insight 開始，由 Agent 嘅 rigour 執行，由 domain knowledge 收尾。呢個三合一，先係香港開發者喺 AI 時代嘅競爭優勢。