14 ਜੁਲਾ 2025·8 ਮਿੰਟ

Judea Pearl ਦੀ ਕਾਰਨਾਤਮਕ ਸੋਚ: ਬਿਹਤਰ AI, ਡਿਬੱਗਿੰਗ, ਫੈਸਲੇ

Q: What’s the practical difference between correlation and causation in product and AI work?

Correlation helps you predict or detect (e.g., “when X rises, Y often rises too”). Causation answers a decision question: “If we change X on purpose, will Y change?” Use correlation for forecasting and monitoring; use causal thinking when you’re about to ship a change, set a policy, or allocate budget.

Q: Why did “more notifications = higher retention” fail when the team sent more notifications?

Because the correlation may be driven by confounding . In the notifications example, highly engaged users both trigger/receive more notifications and return more . If you increase notifications for everyone, you’ve changed the experience (an intervention) without changing the underlying engagement—so retention may not improve and can even worsen.

Q: What is a causal diagram (DAG), and why should a team bother drawing one?

A DAG (Directed Acyclic Graph) is a simple diagram where: - nodes are variables you care about - arrows mean “A causes B” (if changing A would change B) It’s useful because it makes assumptions explicit, helping teams agree on what to adjust for , what not to adjust for, and what experiment would actually answer the question.

Q: What are confounders, mediators, and colliders—and why do they matter?

- Confounder: affects both the proposed cause and the outcome (creates a misleading association). - Mediator: sits on the pathway from cause → outcome (part of the mechanism). - Collider: is caused by two variables; conditioning on it can create a fake relationship. A common mistake is “control for everything,” which can accidentally adjust for mediators or colliders and bias the result.

Q: What’s a counterfactual, and when is it useful?

A counterfactual asks: for this specific case , what would have happened if we had done something else. It’s useful for: - recourse (“what would need to change to get approved?”) - fairness checks (“would the decision change if only a sensitive attribute differed?”) - debugging odd decisions (“what minimal change flips the prediction?”) It requires a causal model so you don’t propose impossible changes.

Q: How does causal thinking help when an ML model’s performance drops in production?

Focus on what changed upstream and what the model might be exploiting: - dataset shift (user mix, UI, seasonality) - spurious shortcuts (proxies like watermarks or phrasing artifacts) - leakage (features downstream of the label/labeling process) A causal mindset pushes you to test targeted interventions (ablations, perturbations) instead of chasing coincident metric movements.

Q: Why can model “explainability” be misleading without causality?

Not necessarily. Feature importance explains what influenced the prediction , not what you should change . A highly “important” feature can be a proxy or symptom (e.g., support tickets predict churn). Intervening on the proxy (“reduce tickets by hiding support”) can backfire. Causal explanations tie importance to valid levers and expected outcomes under intervention.

Q: How do we incorporate causal thinking into PRDs and decision docs?

Add a short section that forces clarity before analysis: - Intervention: what exactly are we changing? - Outcome + guardrails: what should improve, and what must not worsen? - Confounders: what else could move the metrics at the same time? - Measurement plan: experiment, phased rollout, holdout, or matched comparison This keeps the team aligned on a causal question rather than post-hoc dashboard storytelling.

ਸਿੱਖੋ ਕਿ Judea Pearl ਦੇ ਕਾਰਨਾਤਮਕ ਮਾਡਲ ਟੀਮਾਂ ਨੂੰ AI ਦੇ ਵਿਹਾਰ ਨੂੰ ਸਮਝਣ, ਫੇਲ ਹੋਣ ਨੂੰ ਡਿਬੱਗ ਕਰਨ ਅਤੇ correlations ਤੋਂ ਆਗੇ ਸਾਫ਼ ਫੈਸਲੇ ਕਰਨ ਵਿੱਚ ਕਿਵੇਂ ਮਦਦ ਕਰਦੇ ਹਨ।

چراوزے ਕਾਰਨ-ਅਤੇ-ਅਸਰ ਪੈਟਰਨ-ਪਹਿਚਾਨ ਤੋਂ ਕਿਉਂ ਬਿਹਤਰ ਹੈ

ਇੱਕ ਟੀਮ ਆਪਣੇ ਡੈਸ਼ਬੋਰਡ 'ਤੇ ਕੁਝ “ਜ਼ਾਹਰ” ਵੇਖਦੀ ਹੈ: ਜਿਨ੍ਹਾਂ ਉਪਭੋਗਤਾਵਾਂ ਨੂੰ ਵੱਧ ਨੋਟੀਫਿਕੇਸ਼ਨ ਮਿਲਦੇ ਹਨ, ਉਹ ਵੱਧ ਆਉਂਦੇ ਹਨ। ਇਸ ਲਈ ਉਹ ਨੋਟੀਫਿਕੇਸ਼ਨਾਂ ਦੀ ਮਾਤਰਾ ਵਧਾ ਦਿੰਦੇ ਹਨ। ਇੱਕ ਹਫ਼ਤੇ ਬਾਅਦ, ਰਿਟੇਨਸ਼ਨ ਘਟ ਜਾਂਦੀ ਹੈ ਤੇ ਚਰਨ ਸ਼ਿਕਾਇਤਾਂ ਵਧ ਜਾਦੀਆਂ ਹਨ। ਕੀ ਹੋਇਆ?

ਮੁਢਲਾ ਪੈਟਰਨ ਸਹੀ ਸੀ—ਪਰ ਗੁਮਰਾਹ ਕਰਨ ਵਾਲਾ ਸੀ। ਸਭ ਤੋਂ ਬਹੁਤ انگیਜ ਉਪਭੋਗਤਾ ਕੁਦਰਤੀ ਤੌਰ 'ਤੇ ਵੱਧ ਨੋਟੀਫਿਕੇਸ਼ਨ ਟ੍ਰਿਗਰ ਕਰਦੇ ਹਨ (ਕਿਉਂਕਿ ਉਹ ਪ੍ਰੋਡਕਟ ਨੂੰ ਵੱਧ ਵਰਤਦੇ ਹਨ), ਅਤੇ ਉਹ ਕੁਦਰਤੀ ਤੌਰ 'ਤੇ ਵਾਪਸ ਵੀ ਆਉਂਦੇ ਹਨ। ਨੋਟੀਫਿਕੇਸ਼ਨਾਂ ਨੇ ਰਿਟੇਨਸ਼ਨ ਦਾ ਕਾਰਨ ਨਹੀਂ ਬਣਾਇਆ; ਐਂਗੇਜਮੈਂਟ ਦੋਨਾਂ ਦਾ ਕਾਰਨ ਸੀ। ਟੀਮ ਨੇ correlation 'ਤੇ ਕਾਰਵਾਈ ਕੀਤੀ ਅਤੇ ਅਣਚਾਹੇ ਤੌਰ 'ਤੇ ਤਜਰਬਾ ਬਦਤਰ ਕਰ ਦਿੱਤਾ।

“ਕਾਰਨਾਤਮਕ ਸੋਚ” ਦਾ ਮਤਲਬ (ਸਧਾਰਨ ਭਾਸ਼ਾ ਵਿੱਚ)

ਕਾਰਨਾਤਮਕ ਸੋਚ ਇੱਕ ਆਦਤ ਹੈ ਜੋ ਪੁੱਛਦੀ ਹੈ: ਕੀ ਕਿਸ ਨੂੰ ਕਾਰਨ ਬਣਾਉਂਦਾ ਹੈ, ਅਤੇ ਅਸੀੰ ਇਹ ਕਿਵੇਂ ਜਾਣਦੇ ਹਾਂ? “ਇਹ ਦੋ ਚੀਜ਼ਾਂ ਇਕੱਠੇ ਚਲਦੀਆਂ ਹਨ” ਤੇ ਅਟਕਣ ਦੀ ਬਜਾਏ, ਤੁਸੀਂ ਵੱਖ ਕਰਦੇ ਹੋ:

ਸਿਗਨਲ ਜੋ ਤੁਸੀਂ ਵੇਖਦੇ ਹੋ (ਲਾਗز, ਮੈਟਰਿਕਸ, ਅਤੇ ਚਾਰਟਾਂ ਵਿੱਚ)
ਲੇਵਰ ਜੋ ਤੁਸੀਂ ਖਿੱਚ ਸਕਦੇ ਹੋ (ਜੋ ਤੁਸੀਂ ਹਕੀਕਤ ਵਿੱਚ ਬਦਲ ਸਕਦੇ ਹੋ)
ਸਾਈਡ-ਇਫੈਕਟ ਅਤੇ ਲੁਕਿੜੇ ਪ੍ਰਭਾਵ (ਹੋਰ ਕਾਰਕ ਜੋ ਦੋਹਾਂ ਨੂੰ ਦਬਾਉਂਦੇ ਹਨ)

ਇਹ ਡਾਟਾ ਤੋਂ ਸ਼ੱਕ ਕਰਨ ਬਾਰੇ ਨਹੀਂ ਹੈ—ਬਲਕਿ ਸਵਾਲ ਦੇ ਬਾਰੇ ਵਿਸ਼ੇਸ਼ ਹੋਣ ਬਾਰੇ ਹੈ। “ਕੀ ਨੋਟੀਫਿਕੇਸ਼ਨ retention ਨਾਲ ਜੁੜਦੇ ਹਨ?” ਵੱਖ ਸਵਾਲ ਹੈ ਬਨਾਮ “ਕੀ ਵੱਧ ਨੋਟੀਫਿਕੇਸ਼ਨ ਭੇਜਣ ਨਾਲ retention ਵਧੇਗਾ?” ਦੂਜਾ ਸਵਾਲ ਕਾਰਨਾਤਮਕ ਹੈ।

ਇੱਥੇ ਤੁਰੰਤ ਕਿੱਥੇ ਫਾਇਦਾ ਹੁੰਦਾ ਹੈ

ਇਹ ਲੇਖ ਉਹ ਤਿੰਨ ਪ੍ਰਯੋਗਿਕ ਖੇਤਰਾਂ 'ਤੇ ਕੇਂਦਰਿਤ ਹੈ ਜਿਥੇ ਪੈਟਰਨ-ਪਹਿਚਾਨ ਅਕਸਰ ਫੇਲ ਹੁੰਦੀ ਹੈ:

AI ਸਿਸਟਮ: ਸਮਝਣਾ ਕਿ ਮਾਡਲ ਕੀ ਸਹੀ ਕਾਰਨਾਂ ਦੀ ਵਰਤੋਂ ਕਰ ਰਿਹਾ ਹੈ ਜਾਂ ਸਿਰਫ਼ ਸ਼ਾਰਟਕੱਟ।
ਡਿਬੱਗਿੰਗ: ਮੈਟਰਿਕਸ ਪਿੱਛੇ ਦੇ ਅਸਲ ਰੂਟ ਕਾਰਨ ਨੂੰ ਲੱਭਣਾ, ਬਜਾਏ ਕਿ ਸਿੱਟਾ-ਸਬੰਧੀ ਸਹਿਮਤੀਆਂ 'ਤੇ ਭੱਜਣ ਦੇ।
ਪ੍ਰੋਡਕਟ ਫੈਸਲੇ: ਐਸੇ ਬਦਲਾਅ ਚੁਣਨਾ ਜੋ ਨਤੀਜਿਆਂ ਨੂੰ ਹਿਲਾਉਂ—ਸਿਰਫ਼ ਉੱਚ ਪ੍ਰਦਰਸ਼ਨ ਵਾਲੇ ਯੂਜ਼ਰ ਸੈਗਮੈਂਟ ਨੂੰ “ਮੈਚ” ਕਰਨ ਨੂੰ ਨਹੀਂ।

ਇਸ ਲੇਖ ਤੋਂ ਉਮੀਦ ਕੀ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ

ਇਹ ਕੋਈ ਗਣਿਤ-ਭਾਰੀ causal inference ਟੂਰ ਨਹੀਂ ਹੈ। ਤੁਹਾਨੂੰ do-calculus ਨੋਟੇਸ਼ਨ ਸਿੱਖਣ ਦੀ ਲੋੜ ਨਹੀਂ ਪਵੇਗੀ ਤਾਂ ਜੋ ਤੁਹਾਨੂੰ ਲਾਭ ਮਿਲੇ। ਮਕਸਦ ਇਹ ਹੈ ਕਿ ਤੁਹਾਡੇ ਟੀਮ ਲਈ ਮਨੁੱਖੀ ਮਾਡਲ ਅਤੇ ਵਰਕਫਲੋਅ ਮਿਲੇ ਤਾਂ ਜੋ:

ਵਧੀਆ ਸਵਾਲ ਰਚ ਸਕੋ,
ਆਮ ਜਾਲਾਂ (ਜਿਵੇਂ confounding) ਤੋਂ ਬਚੋ,
ਅਤੇ ਇਹ ਫੈਸਲਾ ਕਰੋ ਕਿ ਕਦੋਂ ਤੁਹਾਨੂੰ ਇੱਕ ਪ੍ਰਯੋਗ ਦੀ ਲੋੜ ਹੈ ਜਾਂ ਸੰਭਾਲੀ ਹੋਈ observational reasoning ਪੋਸਦੀ ਹੈ।

ਜੇ ਤੁਸੀਂ ਕਦੇ ਕੋਈ ਐਸਾ ਬਦਲਾਅ ਰਿਲੀਜ਼ ਕੀਤਾ ਹੈ ਜੋ “ਡਾਟਾ ਵਿੱਚ ਚੰਗਾ ਲਗਦਾ ਸੀ” ਪਰ ਹਕੀਕਤ ਵਿੱਚ ਕੰਮ ਨਹੀਂ ਕੀਤਾ, ਤਾਂ causal ਸੋਚ ਉਹ ਗੁੰਝਲਾ ਹੈ ਜੋ ਗੁਆਚ ਗਿਆ ਸੀ।

ਜੂਡੀਆ ਪੀਅਰਲ ਕੌਣ ਹਨ, ਅਤੇ ਉਨ੍ਹਾਂ ਨੇ ਕੀ ਬਦਲਿਆ?

Judea Pearl ਇੱਕ ਕਮਪਿਊਟਰ ਵਿਗਿਆਨੀ ਅਤੇ ਵਿਗਿਆਨ ਦਾਰਸ਼ਨਿਕ ਹਨ ਜਿਨ੍ਹਾਂ ਦਾ ਕੰਮ ਬਹੁਤ ਸਾਰੀਆਂ ਟੀਮਾਂ ਦੇ ਡਾਟਾ, AI ਅਤੇ ਫੈਸਲੇ ਕਰਨ ਦੇ ਤਰੀਕੇ ਨੂੰ ਬਦਲ ਦਿਤਾ। ਉਸ causal ਇਨਕਲਾਬ ਤੋਂ ਪਹਿਲਾਂ, ਕਮਿਊਟਿੰਗ ਵਿੱਚ “ਡਾਟਾ ਤੋਂ ਸਿੱਖਣਾ” ਜ਼ਿਆਦਾਤਰ ਸਾਂਖਿਕੀ ਸੰਬੰਧਾਂ 'ਤੇ ਕੇਂਦਰਿਤ ਸੀ: ਪੈਟਰਨ ਲੱਭੋ, ਮਾਡਲ ਫਿਟ ਕਰੋ, ਅਗਲੇ ਵਾਪਸ ਆਉਣ ਨੂੰ ਭਵਿੱਖਬਾਣੀ ਕਰੋ। ਇਹ ਤਰੀਕਾ ਤਾਕਤਵਰ ਹੈ—ਪਰ ਉਹ ਇਸ ਵੇਲੇ ਟੁਟ ਜਾਂਦੀ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਕਿਸੇ ਪ੍ਰੋਡਕਟ ਜਾਂ ਇੰਜੀਨੀਅਰਿੰਗ ਸਵਾਲ ਵਿੱਚ ਸ਼ਬਦ ਕਿਉਂ ਸ਼ਾਮਿਲ ਕਰਦਾ ਹੋ।

Pearl ਦਾ ਮੁੱਖ ਬਦਲਾਅ ਇਹ ਸੀ ਕਿ causality ਨੂੰ ਇੱਕ ਪਹਿਲਾ-ਕੱਖ ਸਮਝਿਆ ਗਿਆ ਕਾਂਸੈਪਟ ਬਣਾਇਆ ਗਿਆ, ਨਾ ਕਿ correlations ਦੇ ਉੱਪਰ ਇੱਕ ਧੁੰਦਲੀ ਅਨੁਭੂਤੀ। “ਜਦੋਂ X ਉੱਚਾ ਹੈ, ਕੀ Y ਵੀ ਉੱਚਾ ਹੈ?” ਪੁੱਛਣ ਦੀ ਬਜਾਏ, causal ਸੋਚ ਪੁੱਛਦੀ ਹੈ, “ਜੇ ਅਸੀਂ X ਨੂੰ ਬਦਲਾਂਗੇ, ਤਾਂ Y ਬਦਲੇਗਾ?” ਇਹ ਫਰਕ ਛੋਟਾ ਲੱਗਦਾ ਹੈ, ਪਰ ਇਹ ਭਵਿੱਖਬਾਣੀ ਨੂੰ ਫੈਸਲੇ-ਕਾਰਜ ਤੋਂ ਵੱਖ ਕਰਦਾ ਹੈ।

ਸੰਬੰਧਾਂ ਤੋਂ causal ਸਵਾਲਾਂ ਤੱਕ

Association ਇਹ ਜਵਾਬ ਦਿੰਦੀ ਹੈ ਕਿ “ਕਿਹੜੀਆਂ ਚੀਜ਼ਾਂ ਅਕਸਰ ਇਕੱਠੇ ਹੋਦੀਆਂ ਹਨ।” Causation ਦਾ ਮਕਸਦ ਹੈ “ਜੇ ਅਸੀਂ ਹਸਤਖੇਪ ਕਰੀਏ ਤਾਂ ਕੀ ਹੋਵੇਗਾ।” ਇਹ ਕਮਿਊਟਿੰਗ ਵਿੱਚ ਅਹੰਕਾਰਿਕ ਹੈ ਕਿਉਂਕਿ ਅਨੇਕ ਅਸਲੀ ਫੈਸਲੇ ਹਸਤਖੇਪ-ਆਕਾਰ ਦੇ ਹੁੰਦੇ ਹਨ: ਇੱਕ ਫੀਚਰ ਰਿਲੀਜ਼ ਕਰਨਾ, ਰੈਂਕਿੰਗ ਬਦਲਣਾ, ਗਾਰਡਰੇਲ ਲਗਾਉਣਾ, ਟ੍ਰੇਨਿੰਗ ਸੈੱਟ ਨੂੰ ਟਵੀਕ ਕਰਨਾ, ਜਾਂ ਨੀਤੀ ਬਦਲਣਾ।

ਜਾਦੂ ਨਹੀਂ: ਤੁਹਾਡੇ ਕੋਲ ਬਿਆਨ ਕਰਨ ਯੋਗ ਧਾਰਨਾਵਾਂ ਹੋਣੀਆਂ ਚਾਹੀਦੀਆਂ

Pearl ਨੇ causality ਨੂੰ ਔਰ ਆਚਰਯੋਗ ਬਣਾਇਆ ਜਦੋਂ ਉਸ ਨੇ ਇਸਨੂੰ ਇੱਕ ਮਾਡਲਿੰਗ ਚੋਣ ਅਤੇ ਸਪੱਸ਼ਟ ਧਾਰਨਾਵਾਂ ਵਜੋਂ ਦਰਜ ਕੀਤਾ। ਤੁਸੀਂ ਆਮ ਤੌਰ 'ਤੇ ਡਾਟਾ ਤੋਂ ਆਟੋਮੈਟਿਕ ਤੌਰ 'ਤੇ causality “ਖੋਜ” ਨਹੀਂ ਕਰਦੇ; ਤੁਸੀਂ ਇੱਕ ਕਾਰਨਾਤਮਕ ਕਹਾਣੀ ਪ੍ਰਸਤਾਵਿਤ ਕਰਦੇ ਹੋ (ਅਕਸਰ ਡੋਮੇਨ ਗਿਆਨ 'ਤੇ ਆਧਾਰਿਤ) ਅਤੇ ਫਿਰ ਡਾਟਾ ਨਾਲ ਇਸ ਨੂੰ ਟੈਸਟ, ਅੰਦਾਜ਼ਾ ਅਤੇ ਨਿੱਖਾਰੋ।

ਜਿਹੜੇ ਮੁੱਖ ਨਤੀਜੇ Pearl ਨੇ ਲੋਕਪ੍ਰਿਯ ਕੀਤੇ

Causal graphs (DAGs): ਸਧਾਰਨ ਡਿਆਗ੍ਰਾਮ ਜਿਹੜੇ ਮਨਾਈ ਗਈ ਕਾਰਨ-ਅਸਰ ਸੰਬੰਧਾਂ ਨੂੰ encode ਕਰਦੇ ਹਨ।
Interventions (“do”): ਸੋਚਣਾ ਕਿ ਜਦੋਂ ਤੁਸੀਂ ਇੱਕ ਵੇਰੀਏਬਲ ਨੂੰ ਸਕ੍ਰਿਅ-ਤੌਰ ਤੇ ਸੈਟ ਕਰਦੇ ਹੋ ਤਾਂ ਕੀ ਬਦਲਦਾ ਹੈ, ਸਿਰਫ਼ ਦੇਖਣ ਦੀ ਬਜਾਏ।
Counterfactuals: “ਇਸ ਖਾਸ ਮਾਮਲੇ ਲਈ, ਜੇ ਅਸੀਂ ਕੁਝ ਹੋਰ ਕੀਤਾ ਹੁੰਦਾ ਤਾਂ ਕੀ ਹੁੰਦਾ?”

ਇਹ ਟੂਲ ਟੀਮਾਂ ਨੂੰ ਇੱਕ ਸਾਂਝੀ ਭਾਸ਼ਾ ਦਿੱਤੀ ਤਾਂ ਜੋ ਪੈਟਰਨ-ਪਹਿਚਾਨ ਤੋਂ causal ਸਵਾਲਾਂ ਤੱਕ ਸੁਚੱਜਾ ਅਤੇ ਅਨੁਸ਼ਾਸਿਤ ਤਰੀਕੇ ਨਾਲ ਜਾ ਸਕਣ।

ਸੰਬੰਧ ਬਨਾਮ ਕਾਰਨ: ਅਸਲ ਸਵਾਲ ਜੋ ਤੁਸੀਂ ਪੁੱਛ ਰਹੇ ਹੋ

Correlation ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਦੋ ਚੀਜਾਂ ਇਕੱਠੇ ਚਲਦੀਆਂ ਹਨ: ਇੱਕ ਉੱਪਰ ਜਾਂਦਾ ਹੈ ਤਾਂ ਦੂਜਾ ਵੀ ਉੱਪਰ ਜਾਂਦਾ/ਹੇਠਾਂ ਜਾਂਦਾ ਹੈ। ਇਹ ਬਹੁਤ ਲਾਭਦਾਇਕ ਹੈ—ਖਾਸ ਕਰਕੇ ਡਾਟਾ-ਭਾਰੀ ਟੀਮਾਂ ਲਈ—ਕਿਉਂਕਿ ਇਹ ਭਵਿੱਖਬਾਣੀ ਅਤੇ ਡਿਟੈਕਸ਼ਨ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ।

ਜੇ ਆਈਸਕ੍ਰੀਮ ਦੀ ਵਿਕਰੀ ਟੈਮਪਰੇਚਰ ਵਧਣ ਨਾਲ ਛੇਤੀ ਤੇ ਉੱਪਰ ਚੜ੍ਹਦੀ ਹੈ, ਤਾਂ ਇਹ correlated ਸਿਗਨਲ (ਟੈਮਪਰੇਚਰ) forecasting ਵਿੱਚ ਸਹਾਇਕ ਹੋ ਸਕਦਾ ਹੈ। ਪ੍ਰੋਡਕਟ ਅਤੇ AI ਕੰਮ ਵਿੱਚ, correlations ਰੈਂਕਿੰਗ ਮਾਡਲਾਂ ("ਉਹੀ ਦਿਖਾਓ ਜੋ ਸਮਾਨ ਉਪਭੋਗਤਾਵਾਂ ਨੇ ਕਲਿੱਕ ਕੀਤਾ"), ਐਨੋਮਲੀ ਸਪਾਟਿੰਗ ("ਇਹ ਮੈਟਰਿਕ ਆਮ ਤੌਰ 'ਤੇ ਉਸ ਨਾਲ ਟ੍ਰੈਕ ਕਰਦੀ ਹੈ"), ਅਤੇ ਤੇਜ਼ ਡਾਇਗਨੌਸਟਿਕਸ ("ਲੈਟੈਂਸੀ ਵਧਣ 'ਤੇ errors ਵੱਧਦੇ ਹਨ") ਨੂੰ ਚਲਾਉਂਦੇ ਹਨ।

ਮੁੱਦਾ ਉਦੋਂ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਅਸੀਂ correlation ਨੂੰ ਇੱਕ ਵੱਖਰੇ ਸਵਾਲ ਦਾ ਜਵਾਬ ਮੰਨ ਲੈਂਦੇ ਹਾਂ: ਜੇ ਅਸੀਂ ਕੋਈ ਚੀਜ਼ ਉਦੇਸ਼ਪੂਰਵਕ ਬਦਲਾਂ ਤਾਂ ਕੀ ਹੁੰਦਾ? ਇਹ causation ਹੈ।

ਕਿਉਂ correlation "ਜੇ ਅਸੀਂ X ਬਦਲਾਂ" ਲਈ ਫੇਲ ਹੁੰਦੀ ਹੈ

ਇੱਕ correlated ਸੰਬੰਧ ਕਿਸੇ ਤੀਜੇ ਕਾਰਕ ਨਾਲ ਚੱਲ ਸਕਦਾ ਹੈ ਜੋ ਦੋਹਾਂ ਵੈਰੀਏਬਲਾਂ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਦਾ ਹੈ। X ਨੂੰ ਬਦਲਣਾ ਜ਼ਰੂਰੀ ਨਹੀਂ ਕਿ Y ਨੂੰ ਬਦਲੇ—ਕਿਉਂਕਿ X ਉਹ ਕਾਰਨ ਨਹੀਂ ਹੋ ਸਕਦਾ ਜੋ Y ਨੂੰ ਹਿਲਾਉਂਦਾ ਹੈ।

ਇੱਕ ਸਧਾਰਨ confounding ਉਦਾਹਰਣ: ਮਾਰਕੇਟਿੰਗ ਖਰਚ ਵਿਰੁੱਧ ਵਿਕਰੀ

ਕਲਪਨਾ ਕਰੋ ਕਿ ਤੁਸੀਂ ਹਫ਼ਤਾਵਾਰ ਮਾਰਕੇਟਿੰਗ ਖਰਚਾਂ ਨੂੰ ਹਫ਼ਤਾਵਾਰ ਵਿਕਰੀ ਨਾਲ ਪਲੌਟ ਕਰਦੇ ਹੋ ਅਤੇ ਇੱਕ ਮਜ਼ਬੂਤ ਸਕਾਰਾਤਮਕ correlation ਵੇਖਦੇ ਹੋ। ਇਹ ਦਰਸਾਉਂਦਾ ਹੈ "ਜ਼ਿਆਦਾ ਖਰਚ = ਜ਼ਿਆਦਾ ਵਿਕਰੀ"।

ਪਰ ਧਿਆਨ ਕਰੋ ਕਿ ਦੋਹਾਂ ਦੀ ਉਥਾਨ ਛੁੱਟੀਆਂ ਦੌਰਾਨ ਵੱਧਦੀ ਹੈ। ਸੀਜ਼ਨ (ਇੱਕ confounder) ਉੱਚ ਮੰਗ ਚਲਾਉਂਦਾ ਹੈ ਅਤੇ ਵੱਡੇ ਬਜਟ ਵੀ ਪ੍ਰੇਰਿਤ ਕਰਦਾ ਹੈ। ਜੇ ਤੁਸੀਂ ਗੈਰ-ਛੁੱਟੀ ਹਫਤੇ ਵਿੱਚ ਖਰਚ ਵਧਾਉਂਦੇ ਹੋ, ਤਾਂ ਵਿਕਰੀ ਬਹੁਤ ਨਹੀਂ ਵਧ ਸਕਦੀ—ਕਿਉਂਕਿ ਬੁਨਿਆਦੀ ਮੰਗ ਉਸ ਸਮੇਂ ਨਹੀਂ ਹੈ।

ਨਿਸ਼ਾਨ ਜਦੋਂ ਤੁਸੀਂ ਅਸਲ ਵਿੱਚ causal ਸਵਾਲ ਪੁੱਛ ਰਹੇ ਹੋ

ਤੁਸੀਂ causal ਖੇਤਰ ਵਿੱਚ ਹੋ ਜਦੋਂ ਤੁਸੀਂ ਆਪਣੇ ਆਪ ਨੂੰ ਇਹ ਪੁੱਛਦੇ ਹੋ:

“ਜੇ ਅਸੀਂ X ਵਧਾਈਏ/ਘਟਾਈਏ, ਤਾਂ Y 'ਤੇ ਕੀ ਪ੍ਰਭਾਵ ਹੋਵੇਗਾ?”
“ਸਾਨੂੰ ਇਹ ਫੀਚਰ ਲਾਂਚ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ ਜਾਂ ਪੁਰਾਣੀ ਰੱਖਣੀ ਚਾਹੀਦੀ ਹੈ?”
“ਕਿਹੜਾ ਬਦਲਾਅ churn ਕਮ ਕਰੇਗਾ, ਸਿਰਫ਼ ਭਵਿੱਖਬਾਣੀ ਨਹੀਂ?”
“ਕੀ ਇਸ ਮਾਰਕਟਿੰਗ ਮੁਹਿੰਮ ਨੇ ਕਾਮ ਕੀਤਾ, ਜਾਂ ਵਿਕਰੀ ਫਿਰ ਵੀ ਵਧਦੀ ਰਹਿੰਦੀ?”
“ਕਿਸ ਫੈਸਲੇ ਦਾ ** ਪ੍ਰਭਾਵ ** ਹੈ ਜਿਵੇਂ ਕਿ ਕੋਈ ਕਦਮ ਹਟਾਉਣਾ, ਇੱਕ ਵਾਰਨਿੰਗ ਜੋੜਨਾ, ਜਾਂ ਕੀਮਤ ਬਦਲਣਾ?”

ਜਦੋਂ ਕਿਰਿਆ-ਪਦ (change, launch, remove, reduce) ਹੁੰਦਾ ਹੈ, correlation ਇੱਕ ਸ਼ੁਰੂਆਤੀ ਨਿਸ਼ਾਨ ਹੁੰਦਾ ਹੈ—ਫ਼ੈਸਲੇ ਦਾ ਨਿਯਮ ਨਹੀਂ।

ਕਾਰਨਾਤਮਕ ਡਾਇਗ੍ਰਾਮ (DAGs) ਇੱਕ ਸਾਂਝੀ ਟੀਮ ਭਾਸ਼ਾ ਵਜੋਂ

ਕਾਰਨਾਤਮਕ ਡਾਇਗ੍ਰਾਮ—ਅਕਸਰ ਇੱਕ DAG (Directed Acyclic Graph) ਵਜੋਂ—ਟੀਮ ਦੀਆਂ ਧਾਰਨਾਵਾਂ ਨੂੰ ਦਿਖਾਉਣ ਦਾ ਇੱਕ ਸਧਾਰਨ ਤਰੀਕਾ ਹੈ। vague ਤਰਕ ("ਸ਼ਾਇਦ ਮਾਡਲ" ਜਾਂ "ਸ਼ਾਇਦ UI") ਦੀ ਥਾਂ, ਤੁਸੀਂ ਕਹਾਣੀ ਨੂੰ ਕਾਗਜ਼ 'ਤੇ ਲਿਆਉਂਦੇ ਹੋ।

ਨੋਡ ਤੇ ਤੀਰ: ਬੁਨਿਆਦੀ ਗ੍ਰੈਮਰ

ਨੋਡ ਉਹ ਵੈਰੀਏਬਲ ਹਨ ਜਿਨ੍ਹਾਂ ਦੀ ਤੁਸੀਂ ਪਰਵਾਹ ਕਰਦੇ ਹੋ: marketing email sent, user intent, model score, purchase.
Directed arrows causal ਪ੍ਰਭਾਵ ਦਰਸਾਉਂਦੇ ਹਨ: ਜੇ A ਬਦਲਣ ਨਾਲ B ਬਦਲਦਾ ਹੈ, ਤਾਂ A → B ਖਿੱਚੋ।

ਮਕਸਦ ਪਰਫੈਕਟ ਸਚ ਨਹੀਂ; ਇਹ “ਸਿਸਟਮ ਕਿਵੇਂ ਸਮਝਦੇ ਹਾਂ” ਦਾ ਇੱਕ ਸਾਂਝਾ ਡ੍ਰਾਫਟ ਹੈ ਜਿਸ 'ਤੇ ਹਰ ਕੋਈ ਟੀਕਾ-ਟਿੱਪਣੀ ਕਰ ਸਕਦਾ ਹੈ।

Confounders, mediators, ਅਤੇ colliders (ਇਕ ਛੋਟਾ ਉਦਾਹਰਣ)

ਮਾਲ ਕਰੋ ਤੁਸੀਂ ਮੁੱਲਾਂਕਣ ਕਰ ਰਹੇ ਹੋ ਕਿ ਨਵਾਂ onboarding tutorial (T) activation (A) ਵਧਾਉਂਦਾ ਹੈ ਕਿ ਨਹੀਂ।

Confounder: user motivation (M) ਦੋਹਾਂ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਦੀ ਹੈ: M → T ਅਤੇ M → A. ਜੇ ਤੁਸੀਂ M ਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ tutorial ਨੂੰ motivation ਦਾ ਕਰਜਾ ਦੇ ਸਕਦੇ ਹੋ।
Mediator: tutorial ਸੰਭਵਤ: product understanding (U) ਨੂੰ ਸੁਧਾਰ ਸਕਦਾ ਹੈ, ਜੋ ਫਿਰ activation ਵਧਾਉਂਦਾ ਹੈ: T → U → A. U mechanism ਦਾ ਹਿੱਸਾ ਹੈ।
Collider: ਸੋਚੋ ਕਿ ਤੁਸੀਂ ਸਿਰਫ ਉਨ੍ਹਾਂ ਯੂਜ਼ਰਾਂ ਨੂੰ ਵਿਸ਼ਲੇਸ਼ਣ ਕਰਦੇ ਹੋ ਜਿਨ੍ਹਾਂ ਨੇ ਸਪੋਰਟ ਨਾਲ ਸੰਪਰਕ (S) ਕੀਤਾ, ਜਿੱਥੇ confusion ਅਤੇ motivation ਦੋਹਾਂ support tickets ਵਧਾਉਂਦੇ ਹਨ: U → S ← M. S 'ਤੇ conditioning U ਅਤੇ M ਦੇ ਵਿਚਕਾਰ ਇੱਕ ਭੁੱਲ ਭਰਿਆ ਸੰਬੰਧ ਬਣਾਉ ਸਕਦਾ ਹੈ, ਜਿਸ ਨਾਲ T ਦੇ ਪ੍ਰਭਾਵ ਦਾ ਅੰਦਾਜ਼ਾ ਗਲਤ ਹੋ ਸਕਦਾ ਹੈ।

ਕਿਉਂ “ਸਭ ਕੁਝ adjust ਕਰਨਾ” ਨੁਕਸਾਨ ਪਹੁੰਚਾ ਸਕਦਾ ਹੈ

ਇੱਕ ਆਮ ਵਿਸ਼ਲੇਸ਼ਣਕ ਰੁਝਾਨ ਇਹ ਹੈ ਕਿ “ਉਪਲਬਧ ਸਾਰੇ ਵੈਰੀਏਬਲਾਂ ਨੂੰ control ਕਰੋ।” DAG ਦੀ ਭਾਸ਼ਾ ਵਿੱਚ, ਇਸਦਾ ਮਤਲਬ ਇਹ ਹੋ ਸਕਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਗਲਤੀ ਨਾਲ:

Mediators ਨੂੰ adjust ਕਰ ਰਹੇ ਹੋ (ਜੋ ਤੁਹਾਡੇ ਮਾਪ ਰਹੇ ਪ੍ਰਭਾਵ ਦਾ ਹਿੱਸਾ ਲੁਕਾ ਸਕਦੇ ਹਨ), ਜਾਂ
Colliders ਨੂੰ condition ਕਰ ਰਹੇ ਹੋ (ਜੋ bias ਪੈਦਾ ਕਰ ਸਕਦਾ ਹੈ)।

DAG ਨਾਲ ਤੁਸੀਂ ਵੈਰੀਏਬਲਾਂ ਨੂੰ ਇਸ ਲੀਏ adjust ਕਰਦੇ ਹੋ ਕਿ ਕੋਈ ਖਾਸ confounding path ਬੰਦ ਹੋ ਜਾਵੇ—ਸਿਰਫ਼ ਇਸ ਲਈ ਨਹੀਂ ਕਿ ਵੈਰੀਏਬਲ ਮੌਜੂਦ ਹੈ।

ਮੀਟਿੰਗ ਵਿੱਚ ਪਹਿਲਾ ਗ੍ਰਾਫ ਕਿਵੇਂ ਤਿਆਰ ਕਰੀਏ

ਇੱਕ whiteboard ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ ਅਤੇ ਤਿੰਨ ਕਦਮ:

ਖੱਬੇ ਪਾਸੇ ਪ੍ਰਭਾਵਿਤ ਕਰਨ ਵਾਲੇ (ਉਦਾਹਰਣ ਲਈ tutorial) ਅਤੇ ਸੱਜੇ ਪਾਸੇ outcome (ਉਦਾਹਰਣ ਲਈ activation) ਲਿਖੋ।
ਪੁੱਛੋ: “ਦੋਂ ਦੋਹਾਂ ਨੂੰ ਹੋਰ ਕਿਹੜਾ ਬਣਾਉਂਦਾ?” (confounders) ਅਤੇ “ਦਰਮਿਆਨ ਕੀ ਹੈ?” (mediators).
ਵਿਸ਼ਲੇਸ਼ਣ ਵਿੱਚ ਤੁਸੀਂ ਜੋ conditioning ਕਰ ਰਹੇ ਹੋ ਉਹ ਨਿਸ਼ਾਨ ਲਗਾਓ (ਫਿਲਟਰ, cohorts, eligibility ਨਿਯਮ). ਉਹ ਅਕਸਰ colliders ਨੂੰ ਛੁਪਾ ਦਿੰਦੇ ਹਨ।

ਇੱਕ ਰਫ਼ DAG ਵੀ product, data, ਅਤੇ engineering ਨੂੰ ਇੱਕੋ ਹੀ causal ਸਵਾਲ 'ਤੇ ਮਿਲਾ ਦਿੰਦਾ ਹੈ, ਨੰਬਰ ਚਲਾਉਣ ਤੋਂ ਪਹਿਲਾਂ।

ਹਸਤਖੇਪ: “See” ਨਹੀਂ, “Do” ਵਿਚ ਸੋਚਣਾ

Judea Pearl ਦੀ causal ਸੋਚ ਵਿੱਚ ਇਕ ਵੱਡਾ ਤਬਦੀਲੀ ਇਹ ਹੈ ਕਿ ਦੇਖਣਾ ਅਤੇ ਬਦਲਣਾ ਨੂੰ ਵੱਖ ਕਰਨਾ।

ਜੇ ਤੁਸੀਂ ਦੇਖਦੇ ਹੋ ਕਿ notifications ON ਹਨ ਅਤੇ retention ਵਧੀਕ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਇੱਕ ਪੈਟਰਨ ਸਿੱਖਿਆ ਹੈ। ਪਰ ਤੁਸੀਂ ਇਹ ਨਹੀਂ ਜਾਣਦੇ ਕਿ notifications ਨੇ retention ਦਾ ਕਾਰਨ ਬਣਾਇਆ, ਜਾਂ ਉਦੋਂ ਹੀ ਐਂਗੇਜਡ ਉਪਭੋਗਤਾਵਾਂ ਖੁਦ ਨੋਟੀਫਿਕੇਸ਼ਨ ਚਾਲੂ ਕਰਦੇ ਹਨ।

ਇੱਕ ਹਸਤਖੇਪ ਵੱਖਰਾ ਹੈ: ਇਸਦਾ ਮਤਲਬ ਤੁਸੀਂ ਇਕ ਵੇਰੀਏਬਲ ਨੂੰ ਇਕ ਮੁੱਲ 'ਤੇ ਸਰਗਰਮ ਤਰੀਕੇ ਨਾਲ ਸੈਟ ਕਰਦੇ ਹੋ ਅਤੇ ਦੇਖਦੇ ਹੋ ਕਿ ਬਾਅਦ ਵਿੱਚ ਕੀ ਹੁੰਦਾ ਹੈ। ਪ੍ਰੋਡਕਟ ਸ਼ਬਦਾਵਲੀ ਵਿੱਚ, ਇਹ “ਉਪਭੋਗਤਾਵਾਂ ਨੇ X ਚੁਣਿਆ” ਨਹੀਂ ਹੈ, ਇਹ “ਅਸੀਂ X ਰਿਲੀਜ਼ ਕੀਤਾ” ਹੈ।

“Do” vs “See” (ਬਿਨਾਂ ਗਣਿਤ ਦੇ)

Pearl ਇਸ ਫਰਕ ਨੂੰ ਆਮ ਤੌਰ 'ਤੇ ਐਸਾ ਦਿਖਾਉਂਦਾ:

See: “ਅਸੀਂ ਨੋਟੀਫਿਕੇਸ਼ਨ ON ਦੇਖਿਆ।”
Do: “ਅਸੀਂ ਨੋਟੀਫਿਕੇਸ਼ਨ ON ਕੀਤਾ (ਜਾਂ ਇਸਨੂੰ default ਬਣਾਇਆ) ਅਤੇ ਹੁਣ ਅਸੀਂ ਪ੍ਰਭਾਵ ਮਾਪਦੇ ਹਾਂ।”

“do” ਦਾ ਵਿਚਾਰ ਬੁਨਿਆਦੀ ਤੌਰ 'ਤੇ ਇਹ ਹੈ ਕਿ ਤੁਸੀਂ ਯਾਦ ਰੱਖੋ ਕਿ ਤੁਸੀਂ ਸਧਾਰਨ ਕਾਰਨਾਂ ਨੂੰ ਤੋੜ ਰਹੇ ਹੋ ਜੋ ਕਿਸੇ ਵੈਰੀਏਬਲ ਨੂੰ ਉਹ ਮੁੱਲ ਦਿੰਦੇ ਹਨ। ਜਦੋਂ ਤੁਸੀਂ ਹਸਤਖੇਪ ਕਰਦੇ ਹੋ, ਨੋਟੀਫਿਕੇਸ਼ਨ ਇਸ ਲਈ ON ਨਹੀਂ ਹਨ ਕਿਉਂਕਿ انگیਜਡ ਉਪਭੋਗਤਾਵਾਂ ਨੇ opt-in ਕੀਤਾ; ਉਹ ਇਸ ਲਈ ON ਹਨ ਕਿ ਤੁਸੀਂ ਸੈਟ ਕੀਤਾ। ਇਸਦਾ ਮੁੱਦਾ ਇਹੀ ਹੈ: ਹਸਤਖੇਪ ਕਾਰਨ-ਅਸਰ ਨੂੰ ਅਲੱਗ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਦੇ ਹਨ।

ਹਸਤਖੇਪ ਹੀ ਰਾਹ ਹਨ ਜਿਨ੍ਹਾਂ 'ਤੇ ਪ੍ਰੋਡਕਟ ਫੈਸਲੇ ਅਸਲ ਵਿੱਚ ਹੁੰਦੇ ਹਨ

ਬਹੁਤ ਸਾਰਾ ਅਸਲੀ ਪ੍ਰੋਡਕਟ ਕੰਮ ਹਸਤਖੇਪ-ਆਕਾਰ ਦਾ ਹੁੰਦਾ ਹੈ:

ਫੀਚਰ ਲਾਂਚ ਤੇ UI ਬਦਲਾਅ
ਰੈਂਕਿੰਗ ਜਾਂ ਰੇਕਮੈਂਡੇਸ਼ਨ ਨੀਤੀਆਂ ਵਿੱਚ ਟਵਿਕ
ਕੀਮਤ ਅਤੇ ਪੈਕੇਜਿੰਗ ਅੱਪਡੇਟ
ਫ੍ਰੌਡ ਰੂਲ, moderation thresholds, ਜਾਂ ਕ੍ਰੈਡਿਟ ਨੀਤੀਆਂ

ਇਹ ਕਾਰਵਾਈਆਂ ਨਤੀਜਿਆਂ ਨੂੰ ਬਦਲਣ ਦਾ ਉਦੇਸ਼ ਰੱਖਦੀਆਂ ਹਨ, ਨਾ ਕਿ ਸਿਰਫ਼ ਉਨ੍ਹਾਂ ਦਾ ਵੇਰਵਾ ਕਰਨ ਦਾ। causal ਸੋਚ ਪ੍ਰਸ਼ਨ ਨੂੰ ਇमानਦਾਰ ਰੱਖਦੀ ਹੈ: “ਜੇ ਅਸੀਂ ਇਹ ਕਰੀਏ, ਤਾਂ ਕੀ ਬਦਲੇਗਾ?”

ਫੜ: ਹਸਤਖੇਪ ਫਿਰ ਵੀ ਧਾਰਨਾਵਾਂ ਦੀ ਮੰਗ ਕਰਦੇ ਹਨ

ਤੁਸੀਂ ਇੱਕ ਹਸਤਖੇਪ ਦੀ ਵਿਆਖਿਆ (ਜਾਂ ਇਕ ਚੰਗਾ ਪ੍ਰਯੋਗ ਡਿਜ਼ਾਈਨ) ਬਿਨਾਂ ਇਹ ਮੰਨਣਾਂ ਨਹੀਂ ਕਰ ਸਕਦੇ ਕਿ ਕੀ ਪ੍ਰਭਾਵਿਤ ਕਰਦਾ ਹੈ—ਤੁਹਾਡੇ causal ਡਾਇਗ੍ਰਾਮ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ, ਭਾਵੇਂ ਅਣ-ਰਸਮੀ ਹੋਵੇ।

ਉਦਾਹਰਣ ਲਈ, ਜੇ ਸੀਜ਼ਨਲਟੀ ਦੋਹਾਂ ਮਾਰਕੇਟਿੰਗ ਖਰਚ ਅਤੇ ਸਾਈਨ-ਅੱਪ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਦੀ ਹੈ, ਤਾਂ “do” ਕਰਕੇ ਖਰਚ ਵਿੱਚ ਬਦਲਾਅ ਕੀਤੇ ਬਿਨਾਂ ਸੀਜ਼ਨਲ ਪ੍ਰਭਾਵ ਨੂੰ ਅਣਦੇਖਾ ਕਰਨਾ ਮਿਸਲੀਡ ਕਰ ਸਕਦਾ ਹੈ। ਹਸਤਖੇਪ ਤਾਕਤਵਰ ਹਨ, ਪਰ ਉਹ ਤਦ ਤੱਕ ਕਾਰਨਾਤਮਕ ਸਵਾਲਾਂ ਦਾ ਜਵਾਬ ਦਿੰਦੇ ਹਨ ਜਦੋਂ ਤੱਕ ਮੁਢਲਾ causal ਕਹਾਣੀ ਠੀਕ-ਠਾਕ ਹੋ।

ਕਾਊਂਟਰਫੈਕਚੁਅਲਸ: ਇੱਕ ਕੇਸ ਲਈ “ਕੀ ਹੋਂਦਾ?” ਪੁੱਛਣਾ

Own the implementation

Keep full control by exporting source code when your experiment becomes the new default.

Export Code

ਕਾਊਂਟਰਫੈਕਚੁਅਲ ਇੱਕ ਖਾਸ ਤਰ੍ਹਾਂ ਦਾ “ਕੀ ਹੋਵੇਗਾ?” ਸਵਾਲ ਹੈ: ਇਸ ਖ਼ਾਸ ਕੇਸ ਲਈ, ਜੇ ਅਸੀਂ ਕੋਈ ਵੱਖਰਾ ਕੰਮ ਕੀਤਾ ਹੁੰਦਾ (ਜਾਂ ਕੋਈ ਇਨਪੁਟ ਵੱਖਰਾ ਹੁੰਦਾ), ਤਾਂ ਕੀ ਨਤੀਜਾ ਹੁੰਦਾ? ਇਹ "ਔਸਤ" ਨਹੀਂ ਪੁੱਛਦਾ—ਇਹ ਪੁੱਛਦਾ ਹੈ "ਕੀ ਇਸ ਵਿਅਕਤੀ ਲਈ ਨਤੀਜਾ ਬਦਲਦਾ?"

ਟੀਮਾਂ ਨੂੰ ਇਸਦੀ ਲੋੜ ਕਿਉਂ ਪੈਂਦੀ ਹੈ: recourse, fairness, support tickets

ਕਾਊਂਟਰਫੈਕਚੁਅਲ ਉਹ ਉਦਾਹਰਣ ਹਨ ਜਦੋਂ ਕੋਈ ਵਿਅਕਤੀ ਇੱਕ ਵੱਖਰੇ ਨਤੀਜੇ ਲਈ ਰਸਤਾ ਮੰਗਦਾ ਹੈ:

User recourse: “ਮੈਨੂੰ ਮਨਜ਼ੂਰੀ ਲਈ ਕੀ ਬਦਲਣਾ ਪਏਗਾ?”
Fairness investigations: “ਜੇ ਇਸ ਆਵੈਦਕ ਦੇ ਗੁਣ ਇਕੋ ਹੀ ਹੋਣ ਤੇ ਸਿਰਫ਼ ਇੱਕ ਸੰਵੇਦਨਸ਼ੀਲ ਲੱਛਣ ਵੱਖਰਾ ਹੁੰਦਾ, ਕੀ ਫੈਸਲਾ ਬਦਲਦਾ?”
Support ਅਤੇ ਡਿਬੱਗਿੰਗ: “ਇਹ ਯੂਜ਼ਰ ਕਹਿੰਦਾ ਹੈ ਸਿਸਟਮ 'ਅਰਥਹੀਣ' ਸੀ—ਕਿਹੜਾ ਇਨਪੁਟ ਬਦਲਣ ਨਾਲ prediction पलਟ ਜਾਂਦਾ?”

ਇਹ ਸਵਾਲ ਆਮ ਤੌਰ 'ਤੇ ਯੂਜ਼ਰ-ਸਤਰ ਦੇ ਹੁੰਦੇ ਹਨ ਅਤੇ ਪ੍ਰੋਡਕਟ ਬਦਲਾਵਾਂ, ਨੀਤੀਆਂ ਅਤੇ ਵਿਆਖਿਆਵਾਂ ਨੂੰ ਰਾਹਦਾਰੀ ਦਿੰਦੇ ਹਨ।

ਇੱਕ ਕਾਂਕਰੀਟ AI ਉਦਾਹਰਣ

ਕਲਪਨਾ ਕਰੋ ਇੱਕ ਲੋਨ ਮਾਡਲ ਇਕ ਅਰਜ਼ੀ ਨਕਾਰ ਦਿੰਦਾ ਹੈ। ਇੱਕ correlation-ਆਧਾਰਤ ਵਿਆਖਿਆ ਕਹਿ ਸਕਦੀ ਹੈ, “ਘੱਟ ਬਚਤ rejection ਨਾਲ ਜੁੜੀ ਹੈ।” ਇੱਕ ਕਾਊਂਟਰਫੈਕਚੁਅਲ ਪੁੱਛਦਾ ਹੈ:

ਜੇ ਅਰਜ਼ੀਕਰਤਾ ਦੀ ਬਚਤ $3,000 ਵੱਧ ਹੁੰਦੀ (ਹੋਰ ਸਭ ਕੁਝ ਇੱਕੋ ਹੀ), ਕੀ ਮਾਡਲ ਮਨਜ਼ੂਰ ਕਰਦਾ?

ਜੇ ਜਵਾਬ “ਹਾਂ” ਹੈ, ਤਾਂ ਤੁਸੀਂ ਇੱਕ actionable ਬਦਲਾਅ ਸਿੱਖ ਲਿਆ: ਇੱਕ ਸੰਭਵ ਤਬਦੀਲੀ ਜੋ ਫੈਸਲਾ ਪਲਟ ਸਕਦੀ ਹੈ। ਜੇ ਜਵਾਬ “ਨਹੀਂ” ਹੈ, ਤਾਂ ਤੁਸੀਂ ਗਲਤ ਸਲਾਹ ਦੇਣ ਤੋਂ ਬਚ ਗਏ—ਜਿਵੇਂ “ਆਪਣੀ ਬਚਤ ਵਧਾਓ,” ਜਦਕਿ ਅਸਲ ਰੁਕਾਵਟ ਕਰਜ਼ੇ-ਤੋਂ-ਆਮਦਨੀ ਦਾ ਅਨੁਪਾਤ ਜਾਂ ਅਣਸਥਿਰ ਰੋਜ਼ਗਾਰ ਹੋ ਸਕਦਾ ਹੈ।

ਮੁੱਖ ਸੀਮਾ: ਕਾਊਂਟਰਫੈਕਚੁਅਲ ਡਾਟੇ ਵਿੱਚ ਨਹੀਂ ਹੁੰਦੇ

ਕਾਊਂਟਰਫੈਕਚੁਅਲਸ ਇੱਕ ਕਾਰਨਾਤਮਕ ਮਾਡਲ 'ਤੇ ਨਿਰਭਰ ਕਰਦੇ ਹਨ—ਇੱਕ ਕਹਾਣੀ ਕਿ ਵੈਰੀਏਬਲ ਇਕ ਦੂਜੇ ਨੂੰ ਕਿਵੇਂ ਪ੍ਰਭਾਵਿਤ ਕਰਦੇ ਹਨ—ਸਿਰਫ਼ ਇੱਕ ਡਾਟਾਸੇਟ ਨਹੀਂ। ਤੁਹਾਨੂੰ ਇਹ ਨਿਰਧਾਰਿਤ ਕਰਨਾ ਪਵੇਗਾ ਕਿ ਕੀ ਹਕੀਕਤ ਵਿੱਚ ਬਦਲ ਸਕਦਾ ਹੈ, ਕੀ ਨਤੀਜੇ ਵਜੋਂ ਬਦਲਿਆ ਜਾਵੇਗਾ, ਅਤੇ ਕੀ ਫਿਕਸ ਰਹਿਣਾ ਚਾਹੀਦਾ ਹੈ। ਬਿਨਾਂ ਇਸ causal ਧਾਂਚੇ ਦੇ, ਕਾਊਂਟਰਫੈਕਚੁਅਲ ਅਸੰਭਵ ਪਰਿਣਾਮ ("ਆਮਦਨੀ ਜਾਂ ਖਰਚ ਬਦਲੇ ਬਿਨਾਂ ਬਚਤ ਵਧਾਓ") ਬਣ ਸਕਦੇ ਹਨ ਅਤੇ ਗੈਰ-ਲਾਭਦਾਇਕ ਜਾਂ ਅਨਿਆਂਯ ਸਿਫਾਰਸ਼ਾਂ ਦੇ ਸਕਦੇ ਹਨ।

AI ਭਰੋਸੇਯੋਗਤਾ ਅਤੇ ਡਿਬੱਗਿੰਗ ਲਈ ਕਾਰਨਾਤਮਕ ਸੋਚ

ਜਦੋਂ ਇੱਕ ML ਮਾਡਲ production ਵਿੱਚ ਫੇਲ੍ਹ ਹੁੰਦਾ ਹੈ, ਤਾਂ root cause ਅਕਸਰ “algorithm ਖਰਾਬ ਹੋ ਗਿਆ” ਨਹੀਂ ਹੁੰਦਾ। ਜ਼ਿਆਦਾਤਰ ਵਾਰੀ ਕੁਝ ਸਿਸਟਮ ਵਿੱਚ ਬਦਲਦਾ ਹੈ: ਤੁਸੀਂ ਕਿਹੜਾ ਡੇਟਾ ਇਕੱਠਾ ਕਰਦੇ ਹੋ, ਲੇਬਲਿੰਗ ਕਿਵੇਂ ਹੁੰਦੀ ਹੈ, ਜਾਂ ਯੂਜ਼ਰ ਕੀ ਕਰਦੇ ਹਨ। causal ਸੋਚ ਤੁਹਾਨੂੰ ਅਟਕਲਾਂ ਛੱਡ ਕੇ ਇਹ ਪਛਾਣਨ ਵਿੱਚ ਮਦਦ ਕਰਦੀ ਹੈ ਕਿ ਕਿਹੜੀ ਬਦਲਾਅ degradation ਦਾ ਕਾਰਨ ਬਣੀ।

ਆਮ ਫੇਲ੍ਹ ਮੋਡ (ਅਤੇ ਕਿਉਂ ਉਹ ਮੈਟਰਿਕਸ ਨੂੰ ਧੋਖਾ ਦੇਂਦੇ ਹਨ)

ਕੁਝ ਮੁੜ-ਪਰਿਵਰਤਕ ਮੁੱਦੇ ਹਰ ਟੀਮ ਵਿੱਚ ਮਿਲਦੇ ਹਨ:

Spurious shortcuts: ਮਾਡਲ ਇਕ ਅਸਾਨ ਪ੍ਰਾਕਸੀ ਸਿੱਖ ਲੈਂਦਾ ਹੈ (ਜਿਵੇਂ watermark, background color, phrasing quirks) ਜੋ training ਵਿੱਚ ਲੇਬਲ ਨਾਲ correlate ਕਰਦਾ ਸੀ ਪਰ ਅਸਲ signal ਨਹੀਂ।
Dataset shift: ਡੇਟਾ-ਜਨਰੇਟਿੰਗ ਪ੍ਰਕਿਰਿਆ ਬਦਲੀ (ਨਵੇਂ ਯੂਜ਼ਰ ਸੈਗਮੈਂਟ, ਨਵੀਂ UI, ਸੀਜ਼ਨਲਟੀ), ਤਾਂ training ਸੰਬੰਧ ਹੁਣ ਲਾਗੂ ਨਹੀਂ ਹੁੰਦਾ।
Leakage: features ਅਕਸਮਾਤ ਲੇਬਲ ਦੇ downstream ਜਾਣਕਾਰੀ ਸ਼ਾਮਲ ਕਰ ਲੈਂਦੇ ਹਨ, ਜਿਸ ਨਾਲ offline ਪ੍ਰਦਰਸ਼ਨ inflated ਹੋ ਜਾਂਦਾ ਹੈ।

ਇਹ aggregation dashboards ਵਿੱਚ "ਠੀਕ" ਲੱਗ ਸਕਦੇ ਹਨ ਕਿਉਂਕਿ correlation ਉੱਚ ਰਹਿ ਸਕਦੀ ਹੈ ਭਾਵੇਂ ਮਾਡਲ ਦੇ ਸਹੀ ਹੋਣ ਦਾ ਕਾਰਨ ਬਦਲ ਗਿਆ ਹੋਵੇ।

ਕਿਸੇ shortcut ਨੂੰ DAG ਨਾਲ ਕਿਵੇਂ ਬਿਆਨ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ

ਇੱਕ ਸਧਾਰਨ causal ਡਾਇਗ੍ਰਾਮ (DAG) ਡਿਬੱਗਿੰਗ ਨੂੰ ਨਕਸ਼ੇ ਵਾਂਗ ਬਣਾਉਂਦਾ ਹੈ। ਇਹ ਤੁਹਾਨੂੰ ਪੁੱਛਣ ਲਈ ਮਜਬੂਰ ਕਰਦਾ ਹੈ: ਕੀ ਇਹ feature ਲੇਬਲ ਦਾ ਕਾਰਨ ਹੈ, ਇਸ ਦਾ ਨਤੀਜਾ ਹੈ, ਜਾਂ ਇਹ ਮਾਪਣ ਵਿਧੀ ਦਾ ਨਤੀਜਾ ਹੈ?

ਉਦਾਹਰਣ ਲਈ, ਜੇ Labeling policy → Feature engineering → Model inputs ਹੈ, ਤਾਂ ਤੁਹਾਡੇ ਕੋਲ pipeline ਹੋ ਸਕਦੀ ਹੈ ਜਿੱਥੇ ਮਾਡਲ policy ਨੂੰ ਪੇਸ਼ਗੀ ਕਰਦਾ ਹੈ ਨਾਂ ਕਿ ਅਸਲ ਘਟਨਾ। ਇੱਕ DAG ਉਸ ਰਾਹ ਨੂੰ ਦਿਖਾਉਂਦਾ ਤਾਂ ਜੋ ਤੁਸੀਂ ਉਸਨੂੰ ਬਲੌਕ (feature ਹਟਾਉਣਾ, instrumentation ਬਦਲਣਾ, ਜਾਂ label ਦੀ ਪਰਿਭਾਸ਼ਾ ਨਵੀਕਰਨ) ਕਰ ਸਕੋ।

ਡਿਬੱਗਿੰਗ ਲਈ ਹਸਤਖੇਪ (ਸੋਚੋ “X ਨੂੰ ਬਦਲੋ ਤੇ Y ਵੇਖੋ”)

ਸਿਰਫ਼ predictions ਚੈੱਕ ਕਰਨ ਦੀ ਬਜਾਏ, ਸੰਯਮਤ ਹਸਤਖੇਪ ਅਜ਼ਮਾਓ:

Targeted data edits: backgrounds swap ਕਰੋ, watermarks ਹਟਾਓ, timestamps perturb ਕਰੋ—ਫਿਰ inference ਦੁਬਾਰਾ ਚਲਾਓ।
Ablations: ਸ਼ੱਕ-ਸਪਦ feature ਹਟਾਓ ਅਤੇ errors 'ਤੇ ਕਾਰਨਾਤਮਕ ਪ੍ਰਭਾਵ ਮਾਪੋ।
Counterfactual slices: ਇੱਕ factor (device type, locale) ਛੱਡ ਕੇ ਸਭ ਕੁਝ ਫਿਕਸ ਰੱਖੋ ਤਾਂ ਕਿ ਸੰਵੇਦਨਸ਼ੀਲਤਾ ਟੈਸਟ ਹੋ ਸਕੇ।

ਚੈੱਕਲਿਸਟ: ਜਦੋਂ ਪ੍ਰਦਰਸ਼ਨ ਘਟਦਾ ਹੈ ਤਾਂ causal ਸਵਾਲ

ਇਸਦਾ ਕਾਰਨ ਬਣਨ ਵਾਲੀ upstream ਬਦਲਾਅ ਕੀ ਹੋ ਸਕਦੀ ਹੈ (product, logging, user behavior, label policy)?
ਕਿਹੜੇ features label ਜਾਂ labeling ਪ੍ਰਕਿਰਿਆ ਦੇ downstream ਹੋ ਸਕਦੇ ਹਨ (leakage risk)?
ਕਿਹੜਾ confounder ਦੋਹਾਂ, feature ਅਤੇ outcome, ਨੂੰ ਸਮਝਾ ਸਕਦਾ ਹੈ (ਜਿਵੇਂ region ਭਾਸ਼ਾ ਅਤੇ conversion ਦੋਹਾਂ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਦਾ)?
ਅਸੀਂ ਕਿਹੜੀ intervention ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਚਲਾ ਸਕਦੇ ਹਾਂ ਤਾਂ ਕਿ ਸ਼ੱਕੀ factor ਨੂੰ ਅਲੱਗ ਕੀਤਾ ਜਾਵੇ?
ਜੇ ਅਸੀਂ shortcut ਹਟਾ ਦਿੱਤਾ, ਕੀ ਸਾਨੂੰ ਹਾਲੇ ਵੀ real signal → prediction ਦੇ ਵਿਚਕਾਰ causal path ਮਿਲਦੀ ਹੈ?

ਵਿਆਖਿਆਵਾਂ ਤੋਂ ਕਾਰਨਾਂ ਤੱਕ: ਕਿਹੜਾ AI “Explainability” ਛੱਡ ਜਾਂਦਾ ਹੈ

Run the same test on mobile

Test behavior changes on mobile with a Flutter app generated from chat.

Build Mobile

ਬਹੁਤ ਸਾਰੇ “explainability” ਟੂਲ ਇੱਕ ਸੰਕੁਚਿਤ ਸਵਾਲ ਦਾ ਜਵਾਬ ਦਿੰਦੇ ਹਨ: ਇਸ ਮਾਡਲ ਨੇ ਇਹ ਸਕੋਰ ਕਿਉਂ ਦਿੱਤਾ? ਉਹ ਆਮ ਤੌਰ 'ਤੇ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਇਨਪੁੱਟ ਹਾਈਲਾਈਟ ਕਰਕੇ ਕੀਤਾ ਜਾਂਦਾ ਹੈ (feature importance, saliency maps, SHAP values)। ਇਹ ਲਾਭਦਾਇਕ ਹੋ ਸਕਦਾ ਹੈ—ਪਰ ਇਹ ਉਸ ਸਿਸਟਮ ਦੀ ਵਿਆਖਿਆ ਨਹੀਂ ਹੈ ਜਿਸ ਵਿੱਚ ਮਾਡਲ ਬੈਠਾ ਹੈ।

prediction ਦੀ ਵਿਆਖਿਆ ਬਨਾਮ ਸਿਸਟਮ ਦੀ ਵਿਆਖਿਆ

ਇੱਕ prediction ਵਿਆਖਿਆ লোকਲ ਅਤੇ ਵਰਣਨਾਤਮਕ ਹੁੰਦੀ ਹੈ: “ਇਹ ਲੋਨ ਨਕਾਰਿਆ ਗਿਆ ਕਿਉਂਕਿ ਆਮਦਨੀ ਘੱਟ ਅਤੇ utilization ਉੱਚ ਸੀ।”

ਇੱਕ ਸਿਸਟਮ ਵਿਆਖਿਆ causal ਅਤੇ ਕਾਰਗਰ ਹੁੰਦੀ ਹੈ: “ਜੇ ਅਸੀਂ verified income ਵਧਾਈਏ (ਜਾਂ utilization ਘਟਾਈਏ) ਤਦ ਇਹ ਫੈਸਲਾ ਬਦਲ ਜਾਵੇਗਾ—ਅਤੇ downstream ਨਤੀਜੇ ਸੁਧਰਣਗੇ?”

ਪਹਿਲੀ ਤੁਹਾਨੂੰ ਮਾਡਲ ਦੇ ਵਿਹਾਰ ਨੂੰ ਸਮਝਣ ਵਿੱਚ ਮਦਦ ਕਰਦੀ ਹੈ। ਦੂਜੀ ਤੁਹਾਨੂੰ ਇਹ ਫੈਸਲਾ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਦੀ ਹੈ ਕਿ ਕੀ ਕਰਨਾਂ ਹੈ।

causal ਮਾਡਲ ਵਿਆਖਿਆਵਾਂ ਦਾ ਮਤਲਬ ਬਦਲਦੇ ਹਨ

Causal ਸੋਚ ਵਿਆਖਿਆਵਾਂ ਨੂੰ ਹਸਤਖੇਪ ਨਾਲ ਜੋੜਦੀ ਹੈ। ਤੁਸੀਂ ਪੁੱਛਦੇ ਹੋ ਕਿ ਕਿਹੜੇ ਵੈਰੀਏਬਲ ਵਾਸਤਵਿਕ ਲੇਵਰ ਹਨ ਅਤੇ ਜਦੋਂ ਬਦਲੇ ਜਾਣਗੇ ਤਾਂ ਉਹਨਾਂ ਦਾ ਕੀ ਪ੍ਰਭਾਵ ਹੋਵੇਗਾ।

ਇੱਕ causal ਮਾਡਲ ਤੁਹਾਨੂੰ ਇਹ ਗੱਲ ਸਪਸ਼ਟ ਕਰਨ ਲਈ ਮਜਬੂਰ ਕਰਦਾ ਹੈ:

ਕੀ intervene ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ (pricing, messaging, thresholds, UI)
ਕੀ ਸਿਰਫ਼ ਨਿਰਧਾਰਤ ਹੁੰਦਾ ਹੈ (user intent, economic conditions)
ਕੀ confounded ਹੈ (ਲੁਕਿਆ ਹੋਇਆ ਕਾਰਕ ਜੋ input ਅਤੇ outcome ਦੋਹਾਂ ਨੂੰ ਚਲਾਉਂਦਾ ਹੈ)

ਇਸਦਾ ਅਰਥ ਹੈ ਕਿ ਇੱਕ “ਮਹੱਤਵਪੂਰਨ feature” prediction ਲਈ ਫਾਇਦੇਮੰਦ ਹੋ ਸਕਦਾ ਹੈ ਪਰ action ਲਈ ਖ਼ਤਰਨਾਕ proxy ਹੋ ਸਕਦਾ ਹੈ।

correlation-ਅਧਾਰਤ post-hoc explanations ਦਾ ਖ਼ਤਰਾ

Post-hoc explanations ਮਨਪਸੰਦ ਲਗ ਸਕਦੀਆਂ ਹਨ ਪਰ ਪੂਰੀ ਤਰ੍ਹਾਂ correlational ਹੀ ਰਹਿ ਸਕਦੀਆਂ ਹਨ। ਜੇ “support tickets ਦੀ ਗਿਣਤੀ” churn ਦੀ ਭਵਿੱਖਬਾਣੀ ਕਰਦੀ ਹੈ, ਤਾਂ feature-importance ਚਾਰਟ ਟੀਮ ਨੂੰ ਪ੍ਰੇਰਿਤ ਕਰ ਸਕਦਾ ਹੈ ਕਿ “ਟਿਕਟਾਂ ਘਟਾਉਣ ਲਈ support ਨੂੰ ਮਸ਼ਕਲ ਬਣਾਓ।” ਉਹ intervention churn ਵਧਾ ਸਕਦਾ ਹੈ, ਕਿਉਂਕਿ tickets underlying product issues ਦਾ ਲਕੜ ਹਨ—ਕਾਰਨ ਨਹੀਂ।

Correlation-ਆਧਾਰਤ ਵਿਆਖਿਆਵਾਂ distribution shifts 'ਤੇ ਭਵਿੱਖਬਾਣੀ ਨਹੀਂ ਰੱਖਦੀਆਂ: ਜਦੋਂ ਯੂਜ਼ਰ ਵਿਹਾਰ ਬਦਲੇਗਾ, ਉਹੀ highlighted features ਹੁਣੇ ਅਰਥ ਨਹੀਂ ਰੱਖਦੀਆਂ।

ਜਦੋਂ causal ਵਿਆਖਿਆ ਫਾਇਦਾ ਦਿੰਦੀ ਹੈ

ਜਦੋਂ ਫੈਸਲੇ ਦੇ ਨਤੀਜੇ ਅਤੇ ਜ਼ਿੰਮੇਵਾਰੀ ਮਹੱਤਵਪੂਰਨ ਹੁੰਦੀ ਹੈ, causal ਵਿਆਖਿਆ ਮੁੱਲ ਦੀ ਬਣਦੀ ਹੈ:

Audits: ਹਸਤਖੇਪ ਅਤੇ fairness-ਸੰਵੇਦਨਸ਼ੀਲ ਰਾਹਾਂ ਦੇ ਤਰਕ ਨਾਲ ਫੈਸਲਿਆਂ ਨੂੰ ਜ਼ਮ੍ਹੂਰ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ।
Incident reviews: root causes ਨੂੰ correlated signals ਤੋਂ ਵੱਖ-ਰੱਖ ਕਰਨ ਵਿੱਚ ਮਦਦ ਮਿਲਦੀ ਹੈ।
QA ਅਤੇ ਮਾਨੀਟਰਿੰਗ: thresholds, policies, UX ਲਈ “what-if” ਜਾਂਚਾਂ ਸ਼ਿਪ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਅਤੇ ਡ੍ਰਿਫਟ ਹੋਣ 'ਤੇ ਕਰ ਸਕਦੇ ਹੋ।

ਜਦੋਂ ਤੁਹਾਨੂੰ ਕਾਰਵਾਈ करनी ਹੈ, ਨਾ ਕਿ ਸਿਰਫ਼ ਵਿਆਖਿਆ, ਤਾਂ explanation ਨੂੰ causal ਧਾਂਚਾ ਚਾਹੀਦਾ ਹੈ।

ਪ੍ਰਯੋਗ, A/B ਟੈਸਟ, ਅਤੇ ਜਦੋਂ ਤੁਸੀਂ randomize ਨਹੀਂ ਕਰ ਸਕਦੇ

A/B ਟੈਸਟਿੰਗ causal inference ਦਾ ਸਭ ਤੋਂ ਸਧਾਰਾ ਅਤੇ ਪ੍ਰਯੋਗਿਕ ਰੂਪ ਹੈ। ਜਦੋਂ ਤੁਸੀਂ ਯੂਜ਼ਰਾਂ ਨੂੰ ਰੈਂਡਮ ਤੌਰ 'ਤੇ variant A ਜਾਂ B ਅਸਾਇਨ ਕਰਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਇੱਕ ਹਸਤਖੇਪ ਕਰ ਰਹੇ ਹੋ: ਤੁਸੀਂ ਸਿਰਫ ਦੇਖ ਰਹੇ ਨਹੀਂ ਹੋ ਕਿ ਲੋਕ ਕੀ ਚੁਣਦੇ, ਤੁਸੀਂ ਉਹ ਦਿੱਤਾ ਜੋ ਉਹ ਵੇਖਣਗੇ। Pearl ਦੀ ਭਾਸ਼ਾ ਵਿੱਚ, randomization “do(variant = B)” ਨੂੰ ਹਕੀਕਤ ਬਣਾਉਂਦਾ ਹੈ—ਇਸਲਈ ਨਤੀਜਿਆਂ ਦੇ ਫਰਕ ਨੂੰ credible ਤੌਰ 'ਤੇ change ਦਾ ਨਤੀਜਾ ਕਿਹਾ ਜਾ ਸਕਦਾ ਹੈ, ਨਾ ਕਿ ਕਿਸ ਨੇ ਕਿਹੜਾ ਚੁਣਿਆ।

ਰੈਂਡਮਾਈਜ਼ੇਸ਼ਨ ਇੰਨੀ ਤਾਕਤਵਰ ਕਿਉਂ ਹੈ

ਰੈਂਡਮ ਅਸਾਈਨਮੈਂਟ ਉਪਭੋਗਤਾ ਲੱਛਣ ਅਤੇ exposure ਦੇ ਵਿਚਕਾਰ ਲੁਕਿਆ ਹੋਇਆ ਜੋੜ ਤੋੜ ਦਿੰਦਾ ਹੈ। ਪਾਵਰ ਯੂਜ਼ਰ, ਨਵੇਂ ਯੂਜ਼ਰ, ਸਮਾਂ-ਦਿਨ, ਡਿਵਾਈਸ ਟਾਈਪ—ਇਹ ਸਾਰੇ ਤੱਤ ਮੌਜੂਦ ਰਹਿੰਦੇ ਹਨ, ਪਰ (ਆਮ ਤੌਰ 'ਤੇ) ਸਮੂਹਾਂ ਵਿੱਚ ਸੰਤੁਲਿਤ ਹੋ ਜਾਂਦੇ ਹਨ। ਇਹ ਸੰਤੁਲਨ ਹੈ ਜੋ metric gap ਨੂੰ causal ਦਾਅਵਾ ਬਣਾਉਂਦਾ ਹੈ।

ਜਦੋਂ ਪ੍ਰਯੋਗ ਮੁਸ਼ਕਲ ਜਾਂ ਅਣਉਪਯੁਕਤ ਹੁੰਦੇ ਹਨ

ਵਧੀਆ ਟੀਮਾਂ ਵੀ ਸਾਫ़ ਰੈਂਡਮ ਟੈਸਟ ਨਹੀਂ ਚਲਾ ਸਕਦੀਆਂ:

ਛੋਟੇ ਸੈਂਪਲ: ਘੱਟ ਟਰੈਫਿਕ ਨਤੀਜਿਆਂ ਨੂੰ noisy ਅਤੇ ਹੌਲੀ ਬਣਾਉਂਦਾ ਹੈ।
ਲੰਮੇ ਅਸਰ: retention, trust, churn ਮਹੀਨਿਆਂ ਤੱਕ ਲੱਗ ਸਕਦੇ ਹਨ।
Interference: ਇਕ ਯੂਜ਼ਰ ਦਾ ਟ੍ਰੀਟਮੈਂਟ ਦੂਜੇ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਦਾ ਹੈ (ਸੋਸ਼ਲ শੇਅਰਿੰਗ, ਮਾਰਕੇਟਪਲੇਸ ਡਾਇਨਾਮਿਕਸ)।
ਨੈਤਿਕਤਾ ਅਤੇ ਸੁਰੱਖਿਆ: ਤੁਸੀਂ ਹਾਨਿਕਾਰਕ ਅਨੁਭਵ ਜਾਂ ਅਨਿਆਯ ਨੀਤੀਆਂ ਨੂੰ ਰੈਂਡਮ ਤੌਰ 'ਤੇ ਟੈਸਟ ਨਹੀਂ ਕਰ ਸਕਦੇ।
Operational constraints: ਪਲੇਟਫਾਰਮ ਸੀਮਾਵਾਂ, ਕਾਨੂੰਨੀ ਨਿਯਮ, ਜਾਂ ਭਾਗੀਦਾਰ ਡਿਪੈਂਡੇਨਸੀ।

ਇਹ ਹਾਲਾਤਾਂ ਵਿੱਚ, ਤੁਸੀਂ ਫਿਰ ਵੀ causal ਸੋਚ ਸਕਦੇ ਹੋ—ਤੁਹਾਨੂੰ ਸਿਰਫ਼ ਧਾਰਨਾਵਾਂ ਅਤੇ ਅਣਿਸ਼ਚਿਤਤਾ ਬਾਰੇ ਸਪਸ਼ਟ ਹੋਣਾ ਪਵੇਗਾ।

quasi-experimental ਵਿਕਲਪ (ਉੱਚ-ਸਤਹ)

ਆਮ ਵਿਕਲਪਾਂ ਵਿੱਚ difference-in-differences (ਇੱਕ ਸਮੇਂ ਵਿੱਚ ਦੋ ਸਮੂਹਾਂ ਦੇ ਬਦਲਾਅ ਦੀ ਤੁਲਨਾ), regression discontinuity (ਕਿਸੇ cutoff ਨਿਯਮ ਵਰਗਾ “ਸਿਰਫ ਉਨ੍ਹਾਂ ਨੂੰ ਜਿਨ੍ਹਾਂ ਦਾ ਸਕੋਰ X ਤੋਂ ਉੱਪਰ”), instrumental variables (ਕੋਈ ਕੁਦਰਤੀ ਨਜ) ਜੋ exposure ਨੂੰ ਬਦਲਦਾ ਹੈ ਬਗੈਰ outcome ਨੂੰ ਸਿੱਧਾ ਬਦਲੇ), ਅਤੇ matching/weighting ਸ਼ਾਮਲ ਹਨ। ਹਰ ਇੱਕ ਤਰੀਕੇ randomization ਦੀ ਬਜਾਏ assumptions ਲੈਂਦਾ ਹੈ; ਇੱਕ causal ਡਾਇਗ੍ਰਾਮ ਤੁਹਾਨੂੰ ਉਹ assumptions ਸਪਸ਼ਟ ਕਰਨ 'ਚ ਮਦਦ ਕਰੇਗਾ।

“ਸਫਲਤਾ” ਦਾ ਪਹਿਲਾਂ pre-register ਕਰੋ

ਟੈਸਟ (ਜਾਂ observational ਅਧਿਐਨ) ਜਾਰੀ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਲਿਖੋ: primary metric, guardrails, target population, ਅਵਧੀ, ਅਤੇ decision rule। pre-registration bias ਖ਼ਤਮ ਨਹੀਂ ਕਰਦੀ, ਪਰ metric-shopping ਨੂੰ ਘਟਾਉਂਦੀ ਹੈ ਅਤੇ causal ਦਾਵਿਆਂ ਨੂੰ ਟੀਮ ਲਈ ਭਰੋਸੇਯੋਗ ਬਨਾਉਂਦੀ—ਅਤੇ ਚਰਚਾ ਲਈ ਸਪਸ਼ਟ।

causal ਸਵਾਲਾਂ ਨਾਲ ਬਿਹਤਰ ਪ੍ਰੋਡਕਟ ਫੈਸਲੇ

ਅਕਸਰ ਪ੍ਰੋਡਕਟ ਤੇ ਭੜਕਾਉਂਦੀਆਂ ਬਹਿਸਾਂ ਸਦੀਆਂ ਇਸ ਤਰ੍ਹਾਂ ਲੱਗਦੀਆਂ ਹਨ: “Metric X Y ਦੇ ਬਾਅਦ ਹਿਲਿਆ—ਇਸਦਾ ਮਤਲਬ Y ਨੇ ਕੰਮ ਕੀਤਾ।” causal ਸੋਚ ਇਹਨੂੰ ਨਿੱਘਾ ਕਰਦੀ ਹੈ: “ਕੀ ਬਦਲਾਅ Y ਨੇ Metric X ਨੂੰ ਹਿਲਾਇਆ, ਅਤੇ ਕਿੰਨਾ?” ਇਹ ਤਬਦੀਲੀ dashboards ਨੂੰ ਸਬੂਤ ਤੋਂ ਸ਼ੁਰੂਆਤ ਵਿੱਚ ਬਦਲ ਦਿੰਦੀ ਹੈ।

ਤਿੰਨ ਆਮ ਫੈਸਲੇ, causal ਸਵਾਲਾਂ ਵਜੋਂ ਲਿਖੇ ਹੋਏ

ਕੀਮਤ ਬਦਲਾਅ: “ਕੀ ਕੀਮਤ 10% ਵਧਾਉਣ ਦਾ ਪ੍ਰਭਾਵ paid conversion, churn, ਅਤੇ support tickets 'ਤੇ ਕੀ ਹੈ, ਸੀਜ਼ਨਲਟੀ ਨੂੰ ਇੱਕਸਾਰ ਰੱਖ ਕੇ?”

Onboarding ਟਵਿਕ: “ਜੇ ਅਸੀਂ onboarding ਨੂੰ 6 ਕਦਮ ਤੋਂ 4 ਕਦਮ ਕਰ ਦਈਏ, ਤਾਂ ਨਵੇਂ ਉਪਭੋਗਤਾਵਾਂ ਲਈ activation ਅਤੇ week-4 retention 'ਤੇ ਕੀ ਪ੍ਰਭਾਵ ਹੋਵੇਗਾ?”

Recommendation ranking ਬਦਲਾਅ: “ਜੇ ਅਸੀਂ freshness ਨੂੰ promote ਕਰਕੇ results reorder ਕਰੀਏ, ਤਾਂ ਲੰਮੇ ਸਮੇਂ ਦੀ ਸੰਤੁਸ਼ਟੀ (returns, hides, unsubscribes) 'ਤੇ ਕੀ ਪ੍ਰਭਾਵ ਹੋਏਗਾ, ਸਿਰਫ਼ clicks ਨਹੀਂ?”

ਕਿਵੇਂ confounding dashboards ਵਿੱਚ ਚੁੱਪ-ਚਾਪ ਆ ਜਾਂਦਾ ਹੈ

Dashboards ਆਮ ਤੌਰ 'ਤੇ “ਜਿਸਨੂੰ ਬਦਲਾਅ ਮਿਲਿਆ” ਨੂੰ “ਜੋ ਪਹਿਲਾਂ ਹੀ ਚੰਗਾ ਸੀ” ਨਾਲ ਮਿਲਾ ਦਿੰਦੇ ਹਨ। ਇੱਕ ਕਲਾਸਿਕ ਉਦਾਹਰਣ: ਤੁਸੀਂ ਇੱਕ नया onboarding flow ship ਕੀਤਾ, ਪਰ ਇਹ ਨਵੀਂ app version 'ਤੇ ਪਹਿਲਾਂ ਹੀ ਦਿਖਾਇਆ ਗਿਆ। ਜੇ ਨਵੀਆਂ versions ਅਕਸਰ ਵੱਧ انگیਜਡ ਉਪਭੋਗਤਾਵਾਂ ਦੁਆਰਾ اپنਾਈ ਜਾਂਦੀਆਂ ਹਨ, ਤਾਂ ਤੁਹਾਡਾ ਚਾਰਟ ਉਹਨਾਂ ਦੇ ਅਨੁਸਾਰ uplift ਦੇਖਾ ਸਕਦਾ ਹੈ—ਜੋ ਆংশਿਕ ਜਾਂ ਪੂਰੀ ਤਰ੍ਹਾਂ version adoption ਦੀ وجہ ਹੋ ਸਕਦੀ ਹੈ, ਨਾ ਕਿ onboarding।

ਹੋਰ ਆਮ confounders:

Seasonality ਅਤੇ campaigns (ਇੱਕ ਪ੍ਰੋਮੋ ਦੋਹਾਂ signups ਅਤੇ conversion ਨੂੰ ਵਧਾਉਂਦਾ ਹੈ)
User mix shifts (ਇਸ ਮਹੀਨੇ ਜ਼ਿਆਦਾ enterprise leads)
Support load (outages tickets ਵਧਾਉਂਦੇ ਅਤੇ retention ਘਟਾਉਂਦੇ ਹਨ)

PRDs ਵਿੱਚ causal ਸਵਾਲ ਜੋੜੋ (ਟીમ ਇਕੱਠੀ ਰਹੇ)

ਇੱਕ ਲਾਭਦਾਇਕ PRD ਸੈਕਸ਼ਨ ਨਾਮੀ “Causal Questions” ਹੋ ਸਕਦੀ ਹੈ, ਜਿਸ ਵਿੱਚ:

Primary: “ਅਸੀਂ ਕਿਹੜਾ ਬਦਲਾਅ ਕਰ ਰਹੇ ਹਾਂ, ਅਤੇ ਇਹ ਕਿਹੜਾ outcome ਬਦਲੇਗਾ?”
Guardrails: “ਜੇ ਇਹ ਕੰਮ ਕਰਦਾ ਹੈ ਤਾਂ ਕੀ ਨਹੀਂ ਖਰਾਬ ਹੋਣਾ ਚਾਹੀਦਾ?”
Confounders: “ਇਸ ਸਮੇਂ metric ਨੂੰ ਹੋਰ ਕੀ-ਕੀ ਹਿਲਾ ਸਕਦਾ ਹੈ?”
Measurement plan: “Experiment, holdout, phased rollout, ਜਾਂ matched comparison?”

ਜੇ ਤੁਸੀਂ ਤੇਜ਼ build loop ਵਰਤ ਰਹੇ ਹੋ (ਖਾਸ ਕਰਕੇ LLM-assisted development ਨਾਲ), ਇਹ ਸੈਕਸ਼ਨ ਹੋਰ ਵੀ ਮਹੱਤਵਪੂਰਨ ਹੋ ਜਾਂਦਾ ਹੈ: ਇਹ “ਅਸੀਂ ਤੇਜ਼ੀ ਨਾਲ ship ਕਰ ਸਕਦੇ ਹਾਂ” ਨੂੰ रोਕਦਾ ਹੈ ਕਿ “ਅਸੀਂ ਬਿਨਾਂ ਪਤਾ ਕੀਤੇ ship ਕਰ ਦਿੱਤਾ।” Koder.ai ਵਰਗੀਆਂ ਪਲੇਟਫਾਰਮਾਂ ਉੱਤੇ ਟੀਮਾਂ ਆਮ ਤੌਰ 'ਤੇ ਇਹ causal ਸਵਾਲ ਪਹਿਲਾਂ ਹੀ planning mode 'ਚ ਰੱਖਦੀਆਂ ਹਨ, ਫਿਰ feature-flagged variants ਤੇਜ਼ੀ ਨਾਲ ਇੰਪਲੀਮੈਂਟ ਕਰਦੀਆਂ ਹਨ, snapshots/rollback ਨਾਲ experimentation ਸੁਰੱਖਿਅਤ ਰੱਖਦੀਆਂ ਹਨ ਜਦੋਂ ਨਤੀਜੇ (ਜਾਂ side effects) ਹੈਰਾਨ ਕਰਦੇ ਹਨ।

PM, data, engineering, ਅਤੇ support ਨੂੰ ਮਿਲਾਓ

PM ਫੈਸਲਾ ਅਤੇ ਸਫਲਤਾ ਮਾਪਦੰਡ ਵੇਖਾਉਂਦਾ ਹੈ। Data ਸਾਥੀ ਇਸਨੂੰ measurable causal estimates ਅਤੇ sanity checks ਵਿੱਚ ਤਬਦੀਲ ਕਰਦਾ ਹੈ। Engineering change ਨੂੰ controllable ਬਣਾਉਂਦਾ ਹੈ (feature flags, clean exposure logging)। Support qualitative signals ਸਾਂਝੇ ਕਰਦਾ ਹੈ—ਕੀਮਤ ਬਦਲਾਅ ਅਕਸਰ “ਕਾਮ” ਕਰਦੇ ਹਨ ਪਰ ਚਪਕੇ-ਚਪਕੇ cancellations ਜਾਂ ticket volume ਵਧਾ ਦਿੰਦੇ ਹਨ। ਜਦੋਂ ਹਰ ਕੋਈ causal ਸਵਾਲ 'ਤੇ ਸਹਿਮਤ ਹੁੰਦਾ ਹੈ, shipping learning ਬਣ ਜਾਂਦਾ ਹੈ—ਸਿਰਫ਼ ship ਨਹੀਂ।

ਇੱਕ ਵਰਤੋਂਯੋਗ ਵਰਕਫਲੋ: ਆਪਣੀ ਟੀਮ ਦੇ ਔਜ਼ਾਰ ਵਿੱਚ causality ਜੋੜੋ

Make causality operational

Turn “do vs see” into action by shipping a controlled change this sprint.

Start Building

Causal ਸੋਚ ਨੂੰ PhD-ਪੱਧਰੀ rollout ਦੀ ਲੋੜ ਨਹੀਂ। ਇਸਨੂੰ ਟੀਮ ਦੀ ਆਦਤ ਬਣਾਓ: ਆਪਣੀ causal ਕਹਾਣੀ ਲਿਖੋ, ਉਸ 'ਤੇ ਦਬਾਅ ਪਾਓ, ਫਿਰ ਡਾਟਾ (ਅਤੇ ਸੰਭਵ ਹੋਵੇ ਤਾਂ ਪ੍ਰਯੋਗ) ਨਾਲ ਉਸਨੂੰ ਪੁਸ਼ਟ ਜਾਂ ਸੋਧੋ।

ਨਤੀਜੇ 'ਤੇ ਦਲੀਲ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਤੁਹਾਨੂੰ ਕੀ ਚਾਹੀਦਾ ਹੈ

ਤਰੱਕੀ ਕਰਨ ਲਈ, ਚਾਰ ਇਨਪੁਟ ਪਹਿਲਾਂ ਇਕੱਠੇ ਕਰੋ:

A graph: ਮੁੱਖ ਵੈਰੀਏਬਲਾਂ ਦੀ ਤੁਰੰਤ causal diagram (DAG).
Assumptions: ਤੁਸੀਂ ਕੀ ਸੋਚਦੇ ਹੋ ਕਿ ਕੀ ਕਿਸ ਨੂੰ ਚਲਾਉਂਦਾ ਹੈ, ਅਤੇ ਤੁਸੀਂ ਕੀ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰਨ ਦੀ ਚੋਣ ਕਰ ਰਹੇ ਹੋ।
Data sources: ਹਰ ਵੈਰੀਏਬਲ ਕਿੱਥੋਂ ਆ ਰਿਹਾ ਹੈ (ਲਾਗਜ਼, CRM, ਸਰਵੇ), ਅਤੇ ਜਾਣੀਆਂ ਖਾਮੀਆਂ।
Validation plan: ਤੁਸੀਂ assumptions ਕਿਵੇਂ ਚੈੱਕ ਕਰੋਗੇ (A/B test, natural experiment, sensitivity checks, ਜਾਂ expert review)।

ਇਕ ਹਲਕਾ-ਫੁਲਕਾ ਪ੍ਰਕਿਰਿਆ: sketch → critique → test → iterate

Sketch ਸਭ ਤੋਂ ਸਾਦਾ diagram ਜੋ ਇੱਕ ਸਵਾਲ ਦਾ ਉੱਤਰ ਦੇ ਸਕੇ (ਜਿਵੇਂ, “ਕੀ onboarding emails week-4 retention ਵਧਾ ਸਕਦੇ ਹਨ?”).
Critique: ਟੀਮ ਨਾਲ ਇਸਦੀ ਚਰਚਾ ਕਰੋ: analytics, PM, engineering, ਅਤੇ ਯੂਜ਼ਰ ਨੇੜੇ ਕਿਸੇ ਨੂੰ ਸ਼ਾਮਲ ਕਰੋ।
Test assumptions: confounding, selection effects, ਅਤੇ “missing arrows” ਲਈ ਖੋਜੋ। ਜੇ ਮُمਕਿਨ ਹੋਵੇ ਤਾਂ ਇੱਕ ਛੋਟਾ ਪ੍ਰਯੋਗ ਡਿਜ਼ਾਈਨ ਕਰੋ।
Iterate: ਜਿਵੇਂ-ਜਿਵੇਂ ਸਿੱਖਿਆ ਮਿਲੇ, diagram ਅਤੇ measurement plan ਅਪਡੇਟ ਕਰੋ।

ਅਮਲ ਵਿੱਚ, ਤੇਜ਼ੀ ਮਹੱਤਵਪੂਰਨ ਹੈ: ਜਿੰਨੀ ਤੇਜ਼ੀ ਤੁਸੀਂ causal ਸਵਾਲ ਨੂੰ controlled ਬਦਲਾਅ ਵਿੱਚ ਬਦਲ ਸਕਦੇ ਹੋ, ਉਤਨਾ ਘੱਟ ਸਮਾਂ ਤੁਸੀਂ ambiguity 'ਤੇ ਵਿਵਾਦ ਕਰਦੇ ਹੋ। ਇਸੇ ਕਾਰਨ ਟੀਮਾਂ Koder.ai ਵਰਗੀਆਂ ਪਲੇਟਫਾਰਮਾਂ ਨੂੰ ਅਪਣਾਉਂਦੀਆਂ ਹਨ ਤਾਂ ਕਿ “hypothesis + plan” ਤੋਂ ਵਰਕਿੰਗ, instrumented implementation (web, backend, ਜਾਂ mobile) ਦਿਨਾਂ ਵਿੱਚ ਮਿਲ ਜਾਵੇ—ਅਤੇ staged rollouts, deployments, ਅਤੇ rollback ਰਾਹੀਂ ਰਿਗਰ ਰਹੇ।

causal diagram review ਟੈਮਪਲੇਟ (ਕਾਪੀ/ਪੇਸਟ ਕਰੋ)

Decision / intervention: ਅਸੀਂ ਕੀ ਕਾਰਵਾਈ ਕਰ ਸਕਦੇ ਹਾਂ?
Outcome: ਅਸੀਂ ਕੀ ਬਦਲਣਾ ਚਾਹੁੰਦੇ ਹਾਂ?
Main causal path: ਹਸਤਖੇਪ outcome ਤੱਕ ਕਿੱਦਾਂ ਪਹੁੰਚਦਾ ਹੈ?
Confounders: ਕੀ ਦੋਹਾਂ (intervention ਅਤੇ outcome) ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਦਾ ਹੈ?
Mediators: ਦਰਮਿਆਨ ਕੀ ਹੈ (ਬੇਖਬਰ ਹੋ ਕੇ ਇਹਨਾਂ ਨੂੰ control ਨਾ ਕਰੋ)?
Colliders / selection filters: ਕਿੱਥੇ conditioning ਨਕਲੀਆਂ ਸੰਬੰਧ ਬਣਾਉ ਸਕਦੀ ਹੈ?
Measurement notes: ਵੈਰੀਏਬਲ ਕਿਵੇਂ ਮਾਪੇ ਜਾਂਦੇ ਹਨ; ਕੀ ਗੁੰਮ ਜਾਂ noisy ਹੈ?
Proposed check: experiment? quasi-experiment? sensitivity analysis?

ਜੇ ਤੁਸੀਂ experiments 'ਤੇ ਰੀਫ੍ਰੈਸ਼ਰ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ /blog/ab-testing-basics ਨੂੰ ਦੇਖੋ। ਉਹਨਾਂ traps ਲਈ ਜੋ ਪ੍ਰੋਡਕਟ ਮੈਟਰਿਕਸ ਨੂੰ “effects” ਵਰਗਾ ਦਿਖਾਉਂਦੇ ਹਨ, /blog/metrics-that-mislead ਵੇਖੋ।

ਮੁੱਖ ਨਿਕਾਸਾ ਤੇ ਅਗਲੇ ਕਦਮ

Causal ਸੋਚ “ਕੀ ਆਮ ਤੌਰ 'ਤੇ ਇਕੱਠੇ ਹਿਲਦਾ ਹੈ?” ਤੋਂ “ਜੇ ਅਸੀਂ ਕਾਰਵਾਈ ਕਰੀਏ ਤਾਂ ਕੀ ਬਦਲੇਗਾ?” ਤੱਕ ਇੱਕ ਬਦਲਾਅ ਹੈ। ਇਹ ਬਦਲਾਅ—ਜਿਸ ਨੂੰ Judea Pearl ਨੇ computing ਅਤੇ statistics ਵਿੱਚ ਪਿੱਛੇ ਦਿੱਤਾ—ਟੀਮਾਂ ਨੂੰ ਉਹਨਾਂ ਕਿੱਤੇ ਹੋਏ ਕਹਾਣੀਆਂ ਤੋਂ ਬਚਾਉਂਦਾ ਹੈ ਜੋ ਅਸਲ ਦੁਨੀਆ ਵਿੱਚ ਹਸਤਖੇਪ ਦੇ ਸਮਨੇ ਟਿਕ ਨਹੀਂ ਪਾਉਂਦੀਆਂ।

ਮੁੱਖ ਨਤੀਜੇ (4–6 ਲਾਈਨਾਂ)

Correlation ਇੱਕ ਠੋਕਰਾ ਹੈ, ਜਵਾਬ ਨਹੀਂ।

Causal diagrams (DAGs) ਧਾਰਨਾਵਾਂ ਨੂੰ ਦਿੱਖਾਉਂਦੇ ਅਤੇ ਗੱਲਬਾਤਯੋਗ ਬਣਾਉਂਦੇ ਹਨ।

Interventions (“do”) observations (“see”) ਤੋਂ ਵੱਖ ਹਨ।

Counterfactuals ਇਕੱਲੇ ਕੇਸਾਂ ਨੂੰ ਸਮਝਾਉਂਦੇ ਹਨ: “ਜੇ ਇਹ ਇਕ ਗੱਲ ਵੱਖਰੀ ਹੁੰਦੀ ਤਾਂ?”

ਚੰਗਾ causal ਕੰਮ uncertainty ਅਤੇ ਵਿਕਲਪਕ ਵਿਆਖਿਆਵਾਂ ਨੂੰ ਦਰਜ ਕਰਦਾ ਹੈ।

ਇਸ ਹਫ਼ਤੇ ਸ਼ੁਰੂ ਕਰਨ ਲਈ ਇੱਕ ਛੋਟੀ ਪ੍ਰੈਕਟਿਕਲ ਚੈਕਲਿਸਟ

ਇੱਕ ਮੀਟਿੰਗ (45 ਮਿੰਟ): ਇੱਕ high-stakes ਸਵਾਲ ਚੁਣੋ (ਜਿਵੇਂ, “ਕੀ ਇਹ ਫੀਚਰ churn ਘਟਾਏਗਾ?”) ਅਤੇ ਇਸਨੂੰ ਹਸਤਖੇਪ ਵਜੋਂ ਦੁਬਾਰਾ ਲਿਖੋ: “ਜੇ ਅਸੀਂ X ਕਰੀਏ, Y 'ਤੇ ਕੀ ਬਦਲੇਗਾ?”
ਇੱਕ ਡਾਇਗ੍ਰਾਮ (15–30 ਮਿੰਟ): ਇੱਕ ਸਧਾਰਣ DAG whiteboard 'ਤੇ ਸਕੇਚ ਕਰੋ: intervention, outcome, ਅਤੇ 3–6 ਸੰਭਵ ਕਾਰਕ ਜੋ ਦੋਹਾਂ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰ ਸਕਦੇ ਹਨ। ਦਿੱਖਾਓ ਕਿ ਤੁਸੀਂ ਕੀ ਮਾਪ ਸਕਦੇ ਹੋ ਤੇ ਕੀ ਗੁੰਮ ਹੈ।
ਇੱਕ ਟੈਸਟ (ਇਸ ਸਪ੍ਰਿੰਟ): ਸਭ ਤੋਂ ਮਜ਼ਬੂਤ feasible check ਚੁਣੋ—ਜੇ ਤੁਹਾਨੂੰ ਰੈਂਡਮਾਈਜ਼ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ ਤਾਂ A/B test, ਨਹੀਂ ਤਾਂ ਇੱਕ ਸੋਚ ਸਮਝ ਕੇ quasi-experimental comparison। ਪਹਿਲਾਂ ਤੋਂ ਫੈਸਲਾ ਕਰੋ ਕਿ ਕਿਹੜਾ ਨਤੀਜਾ ਤੁਹਾਡਾ ਫੈਸਲਾ ਬਦਲੇਗਾ।

ਸੁੰਦਰ ਡਾਇਗ੍ਰਾਮਾਂ ਨੂੰ ਸਚ ਨਹੀਂ ਸਮਝੋ

Causality ਸੰਭਾਲ ਦੀ ਲੋੜ ਹੈ: ਲੁਕਿਆ confounders, ਮਾਪਣ ਗਲਤੀਆਂ, ਅਤੇ selection effects ਨਤੀਜੇ ਉਲਟ ਸਕਦੇ ਹਨ। ਇਕ ਢੰਗ ਇਹ ਹੈ ਕਿ assumptions ਖੁੱਲ੍ਹੇ ਤੌਰ 'ਤੇ ਲਿਖੋ, ਦਿਖਾਓ ਕਿ ਕਿਹੜਾ ਡਾਟਾ ਵਰਤਿਆ, ਅਤੇ ਕੀ ਚੀਜ਼ ਤੁਹਾਡੇ ਦਾਅਵੇ ਨੂੰ ਗਲਤ ਕਰ ਸਕਦੀ ਹੈ।

ਜੇ ਤੁਸੀਂ ਹੋਰ ਗਹਿਰਾਈ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ /blog 'ਤੇ ਸੰਬੰਧਤ ਲੇਖਾਂ ਨੂੰ ਵੇਖੋ ਅਤੇ causal approaches ਦੀ ਤੁਲਨਾ ਹੋਰ analytics ਅਤੇ “explainability” ਵਿਧੀਆਂ ਨਾਲ ਕਰੋ ਤਾਂ ਕਿ ਪਤਾ ਲੱਗੇ ਕਿ ਹਰ ਇੱਕ ਕਿੱਥੇ ਮਦਦਗਾਰ ਹੈ—ਅਤੇ ਕਿੱਥੇ ਭੇਉਟਾ ਕਰ ਸਕਦਾ ਹੈ।

ਅਕਸਰ ਪੁੱਛੇ ਜਾਣ ਵਾਲੇ ਸਵਾਲ

What’s the practical difference between correlation and causation in product and AI work?

Correlation helps you predict or detect (e.g., “when X rises, Y often rises too”). Causation answers a decision question: “If we change X on purpose, will Y change?”

Use correlation for forecasting and monitoring; use causal thinking when you’re about to ship a change, set a policy, or allocate budget.

Why did “more notifications = higher retention” fail when the team sent more notifications?

Because the correlation may be driven by confounding. In the notifications example, highly engaged users both trigger/receive more notifications and return more.

If you increase notifications for everyone, you’ve changed the experience (an intervention) without changing the underlying engagement—so retention may not improve and can even worsen.

What is a causal diagram (DAG), and why should a team bother drawing one?

A DAG (Directed Acyclic Graph) is a simple diagram where:

nodes are variables you care about
arrows mean “A causes B” (if changing A would change B)

It’s useful because it makes assumptions explicit, helping teams agree on what to adjust for, what not to adjust for, and what experiment would actually answer the question.

What are confounders, mediators, and colliders—and why do they matter?

Confounder: affects both the proposed cause and the outcome (creates a misleading association).
Mediator: sits on the pathway from cause → outcome (part of the mechanism).
Collider: is caused by two variables; conditioning on it can create a fake relationship.

A common mistake is “control for everything,” which can accidentally adjust for mediators or colliders and bias the result.

What does “do vs see” mean without the math?

“See” is observing what naturally happened (users opted in, a score was high). “Do” is actively setting a variable (shipping a feature, forcing a default).

The key idea: an intervention breaks the usual reasons a variable takes a value, which is why it can reveal cause-and-effect more reliably than observation alone.

What’s a counterfactual, and when is it useful?

A counterfactual asks: for this specific case, what would have happened if we had done something else.

It’s useful for:

recourse (“what would need to change to get approved?”)
fairness checks (“would the decision change if only a sensitive attribute differed?”)
debugging odd decisions (“what minimal change flips the prediction?”)

It requires a causal model so you don’t propose impossible changes.

How does causal thinking help when an ML model’s performance drops in production?

Focus on what changed upstream and what the model might be exploiting:

dataset shift (user mix, UI, seasonality)
spurious shortcuts (proxies like watermarks or phrasing artifacts)
leakage (features downstream of the label/labeling process)

A causal mindset pushes you to test targeted interventions (ablations, perturbations) instead of chasing coincident metric movements.

Why can model “explainability” be misleading without causality?

Not necessarily. Feature importance explains what influenced the prediction, not what you should change.

A highly “important” feature can be a proxy or symptom (e.g., support tickets predict churn). Intervening on the proxy (“reduce tickets by hiding support”) can backfire. Causal explanations tie importance to valid levers and expected outcomes under intervention.

When should we run an A/B test, and what if we can’t randomize?

Randomized A/B tests are best when feasible, but you may need alternatives when:

traffic is small
effects take a long time
there’s interference (users affect each other)
ethics/safety prevent randomization

In those cases, consider quasi-experiments like difference-in-differences, regression discontinuity, instrumental variables, or matching/weighting—while being explicit about assumptions.

How do we incorporate causal thinking into PRDs and decision docs?

Add a short section that forces clarity before analysis:

Intervention: what exactly are we changing?
Outcome + guardrails: what should improve, and what must not worsen?
Confounders: what else could move the metrics at the same time?
Measurement plan: experiment, phased rollout, holdout, or matched comparison

This keeps the team aligned on a causal question rather than post-hoc dashboard storytelling.