14 ਜੁਲਾ 2025·8 ਮਿੰਟ
Judea Pearl ਦੀ ਕਾਰਨਾਤਮਕ ਸੋਚ: ਬਿਹਤਰ AI, ਡਿਬੱਗਿੰਗ, ਫੈਸਲੇ
ਸਿੱਖੋ ਕਿ Judea Pearl ਦੇ ਕਾਰਨਾਤਮਕ ਮਾਡਲ ਟੀਮਾਂ ਨੂੰ AI ਦੇ ਵਿਹਾਰ ਨੂੰ ਸਮਝਣ, ਫੇਲ ਹੋਣ ਨੂੰ ਡਿਬੱਗ ਕਰਨ ਅਤੇ correlations ਤੋਂ ਆਗੇ ਸਾਫ਼ ਫੈਸਲੇ ਕਰਨ ਵਿੱਚ ਕਿਵੇਂ ਮਦਦ ਕਰਦੇ ਹਨ।
ਸਿੱਖੋ ਕਿ Judea Pearl ਦੇ ਕਾਰਨਾਤਮਕ ਮਾਡਲ ਟੀਮਾਂ ਨੂੰ AI ਦੇ ਵਿਹਾਰ ਨੂੰ ਸਮਝਣ, ਫੇਲ ਹੋਣ ਨੂੰ ਡਿਬੱਗ ਕਰਨ ਅਤੇ correlations ਤੋਂ ਆਗੇ ਸਾਫ਼ ਫੈਸਲੇ ਕਰਨ ਵਿੱਚ ਕਿਵੇਂ ਮਦਦ ਕਰਦੇ ਹਨ।
ਇੱਕ ਟੀਮ ਆਪਣੇ ਡੈਸ਼ਬੋਰਡ 'ਤੇ ਕੁਝ “ਜ਼ਾਹਰ” ਵੇਖਦੀ ਹੈ: ਜਿਨ੍ਹਾਂ ਉਪਭੋਗਤਾਵਾਂ ਨੂੰ ਵੱਧ ਨੋਟੀਫਿਕੇਸ਼ਨ ਮਿਲਦੇ ਹਨ, ਉਹ ਵੱਧ ਆਉਂਦੇ ਹਨ। ਇਸ ਲਈ ਉਹ ਨੋਟੀਫਿਕੇਸ਼ਨਾਂ ਦੀ ਮਾਤਰਾ ਵਧਾ ਦਿੰਦੇ ਹਨ। ਇੱਕ ਹਫ਼ਤੇ ਬਾਅਦ, ਰਿਟੇਨਸ਼ਨ ਘਟ ਜਾਂਦੀ ਹੈ ਤੇ ਚਰਨ ਸ਼ਿਕਾਇਤਾਂ ਵਧ ਜਾਦੀਆਂ ਹਨ। ਕੀ ਹੋਇਆ?
ਮੁਢਲਾ ਪੈਟਰਨ ਸਹੀ ਸੀ—ਪਰ ਗੁਮਰਾਹ ਕਰਨ ਵਾਲਾ ਸੀ। ਸਭ ਤੋਂ ਬਹੁਤ انگیਜ ਉਪਭੋਗਤਾ ਕੁਦਰਤੀ ਤੌਰ 'ਤੇ ਵੱਧ ਨੋਟੀਫਿਕੇਸ਼ਨ ਟ੍ਰਿਗਰ ਕਰਦੇ ਹਨ (ਕਿਉਂਕਿ ਉਹ ਪ੍ਰੋਡਕਟ ਨੂੰ ਵੱਧ ਵਰਤਦੇ ਹਨ), ਅਤੇ ਉਹ ਕੁਦਰਤੀ ਤੌਰ 'ਤੇ ਵਾਪਸ ਵੀ ਆਉਂਦੇ ਹਨ। ਨੋਟੀਫਿਕੇਸ਼ਨਾਂ ਨੇ ਰਿਟੇਨਸ਼ਨ ਦਾ ਕਾਰਨ ਨਹੀਂ ਬਣਾਇਆ; ਐਂਗੇਜਮੈਂਟ ਦੋਨਾਂ ਦਾ ਕਾਰਨ ਸੀ। ਟੀਮ ਨੇ correlation 'ਤੇ ਕਾਰਵਾਈ ਕੀਤੀ ਅਤੇ ਅਣਚਾਹੇ ਤੌਰ 'ਤੇ ਤਜਰਬਾ ਬਦਤਰ ਕਰ ਦਿੱਤਾ।
ਕਾਰਨਾਤਮਕ ਸੋਚ ਇੱਕ ਆਦਤ ਹੈ ਜੋ ਪੁੱਛਦੀ ਹੈ: ਕੀ ਕਿਸ ਨੂੰ ਕਾਰਨ ਬਣਾਉਂਦਾ ਹੈ, ਅਤੇ ਅਸੀੰ ਇਹ ਕਿਵੇਂ ਜਾਣਦੇ ਹਾਂ? “ਇਹ ਦੋ ਚੀਜ਼ਾਂ ਇਕੱਠੇ ਚਲਦੀਆਂ ਹਨ” ਤੇ ਅਟਕਣ ਦੀ ਬਜਾਏ, ਤੁਸੀਂ ਵੱਖ ਕਰਦੇ ਹੋ:
ਇਹ ਡਾਟਾ ਤੋਂ ਸ਼ੱਕ ਕਰਨ ਬਾਰੇ ਨਹੀਂ ਹੈ—ਬਲਕਿ ਸਵਾਲ ਦੇ ਬਾਰੇ ਵਿਸ਼ੇਸ਼ ਹੋਣ ਬਾਰੇ ਹੈ। “ਕੀ ਨੋਟੀਫਿਕੇਸ਼ਨ retention ਨਾਲ ਜੁੜਦੇ ਹਨ?” ਵੱਖ ਸਵਾਲ ਹੈ ਬਨਾਮ “ਕੀ ਵੱਧ ਨੋਟੀਫਿਕੇਸ਼ਨ ਭੇਜਣ ਨਾਲ retention ਵਧੇਗਾ?” ਦੂਜਾ ਸਵਾਲ ਕਾਰਨਾਤਮਕ ਹੈ।
ਇਹ ਲੇਖ ਉਹ ਤਿੰਨ ਪ੍ਰਯੋਗਿਕ ਖੇਤਰਾਂ 'ਤੇ ਕੇਂਦਰਿਤ ਹੈ ਜਿਥੇ ਪੈਟਰਨ-ਪਹਿਚਾਨ ਅਕਸਰ ਫੇਲ ਹੁੰਦੀ ਹੈ:
ਇਹ ਕੋਈ ਗਣਿਤ-ਭਾਰੀ causal inference ਟੂਰ ਨਹੀਂ ਹੈ। ਤੁਹਾਨੂੰ do-calculus ਨੋਟੇਸ਼ਨ ਸਿੱਖਣ ਦੀ ਲੋੜ ਨਹੀਂ ਪਵੇਗੀ ਤਾਂ ਜੋ ਤੁਹਾਨੂੰ ਲਾਭ ਮਿਲੇ। ਮਕਸਦ ਇਹ ਹੈ ਕਿ ਤੁਹਾਡੇ ਟੀਮ ਲਈ ਮਨੁੱਖੀ ਮਾਡਲ ਅਤੇ ਵਰਕਫਲੋਅ ਮਿਲੇ ਤਾਂ ਜੋ:
ਜੇ ਤੁਸੀਂ ਕਦੇ ਕੋਈ ਐਸਾ ਬਦਲਾਅ ਰਿਲੀਜ਼ ਕੀਤਾ ਹੈ ਜੋ “ਡਾਟਾ ਵਿੱਚ ਚੰਗਾ ਲਗਦਾ ਸੀ” ਪਰ ਹਕੀਕਤ ਵਿੱਚ ਕੰਮ ਨਹੀਂ ਕੀਤਾ, ਤਾਂ causal ਸੋਚ ਉਹ ਗੁੰਝਲਾ ਹੈ ਜੋ ਗੁਆਚ ਗਿਆ ਸੀ।
Judea Pearl ਇੱਕ ਕਮਪਿਊਟਰ ਵਿਗਿਆਨੀ ਅਤੇ ਵਿਗਿਆਨ ਦਾਰਸ਼ਨਿਕ ਹਨ ਜਿਨ੍ਹਾਂ ਦਾ ਕੰਮ ਬਹੁਤ ਸਾਰੀਆਂ ਟੀਮਾਂ ਦੇ ਡਾਟਾ, AI ਅਤੇ ਫੈਸਲੇ ਕਰਨ ਦੇ ਤਰੀਕੇ ਨੂੰ ਬਦਲ ਦਿਤਾ। ਉਸ causal ਇਨਕਲਾਬ ਤੋਂ ਪਹਿਲਾਂ, ਕਮਿਊਟਿੰਗ ਵਿੱਚ “ਡਾਟਾ ਤੋਂ ਸਿੱਖਣਾ” ਜ਼ਿਆਦਾਤਰ ਸਾਂਖਿਕੀ ਸੰਬੰਧਾਂ 'ਤੇ ਕੇਂਦਰਿਤ ਸੀ: ਪੈਟਰਨ ਲੱਭੋ, ਮਾਡਲ ਫਿਟ ਕਰੋ, ਅਗਲੇ ਵਾਪਸ ਆਉਣ ਨੂੰ ਭਵਿੱਖਬਾਣੀ ਕਰੋ। ਇਹ ਤਰੀਕਾ ਤਾਕਤਵਰ ਹੈ—ਪਰ ਉਹ ਇਸ ਵੇਲੇ ਟੁਟ ਜਾਂਦੀ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਕਿਸੇ ਪ੍ਰੋਡਕਟ ਜਾਂ ਇੰਜੀਨੀਅਰਿੰਗ ਸਵਾਲ ਵਿੱਚ ਸ਼ਬਦ ਕਿਉਂ ਸ਼ਾਮਿਲ ਕਰਦਾ ਹੋ।
Pearl ਦਾ ਮੁੱਖ ਬਦਲਾਅ ਇਹ ਸੀ ਕਿ causality ਨੂੰ ਇੱਕ ਪਹਿਲਾ-ਕੱਖ ਸਮਝਿਆ ਗਿਆ ਕਾਂਸੈਪਟ ਬਣਾਇਆ ਗਿਆ, ਨਾ ਕਿ correlations ਦੇ ਉੱਪਰ ਇੱਕ ਧੁੰਦਲੀ ਅਨੁਭੂਤੀ। “ਜਦੋਂ X ਉੱਚਾ ਹੈ, ਕੀ Y ਵੀ ਉੱਚਾ ਹੈ?” ਪੁੱਛਣ ਦੀ ਬਜਾਏ, causal ਸੋਚ ਪੁੱਛਦੀ ਹੈ, “ਜੇ ਅਸੀਂ X ਨੂੰ ਬਦਲਾਂਗੇ, ਤਾਂ Y ਬਦਲੇਗਾ?” ਇਹ ਫਰਕ ਛੋਟਾ ਲੱਗਦਾ ਹੈ, ਪਰ ਇਹ ਭਵਿੱਖਬਾਣੀ ਨੂੰ ਫੈਸਲੇ-ਕਾਰਜ ਤੋਂ ਵੱਖ ਕਰਦਾ ਹੈ।
Association ਇਹ ਜਵਾਬ ਦਿੰਦੀ ਹੈ ਕਿ “ਕਿਹੜੀਆਂ ਚੀਜ਼ਾਂ ਅਕਸਰ ਇਕੱਠੇ ਹੋਦੀਆਂ ਹਨ।” Causation ਦਾ ਮਕਸਦ ਹੈ “ਜੇ ਅਸੀਂ ਹਸਤਖੇਪ ਕਰੀਏ ਤਾਂ ਕੀ ਹੋਵੇਗਾ।” ਇਹ ਕਮਿਊਟਿੰਗ ਵਿੱਚ ਅਹੰਕਾਰਿਕ ਹੈ ਕਿਉਂਕਿ ਅਨੇਕ ਅਸਲੀ ਫੈਸਲੇ ਹਸਤਖੇਪ-ਆਕਾਰ ਦੇ ਹੁੰਦੇ ਹਨ: ਇੱਕ ਫੀਚਰ ਰਿਲੀਜ਼ ਕਰਨਾ, ਰੈਂਕਿੰਗ ਬਦਲਣਾ, ਗਾਰਡਰੇਲ ਲਗਾਉਣਾ, ਟ੍ਰੇਨਿੰਗ ਸੈੱਟ ਨੂੰ ਟਵੀਕ ਕਰਨਾ, ਜਾਂ ਨੀਤੀ ਬਦਲਣਾ।
Pearl ਨੇ causality ਨੂੰ ਔਰ ਆਚਰਯੋਗ ਬਣਾਇਆ ਜਦੋਂ ਉਸ ਨੇ ਇਸਨੂੰ ਇੱਕ ਮਾਡਲਿੰਗ ਚੋਣ ਅਤੇ ਸਪੱਸ਼ਟ ਧਾਰਨਾਵਾਂ ਵਜੋਂ ਦਰਜ ਕੀਤਾ। ਤੁਸੀਂ ਆਮ ਤੌਰ 'ਤੇ ਡਾਟਾ ਤੋਂ ਆਟੋਮੈਟਿਕ ਤੌਰ 'ਤੇ causality “ਖੋਜ” ਨਹੀਂ ਕਰਦੇ; ਤੁਸੀਂ ਇੱਕ ਕਾਰਨਾਤਮਕ ਕਹਾਣੀ ਪ੍ਰਸਤਾਵਿਤ ਕਰਦੇ ਹੋ (ਅਕਸਰ ਡੋਮੇਨ ਗਿਆਨ 'ਤੇ ਆਧਾਰਿਤ) ਅਤੇ ਫਿਰ ਡਾਟਾ ਨਾਲ ਇਸ ਨੂੰ ਟੈਸਟ, ਅੰਦਾਜ਼ਾ ਅਤੇ ਨਿੱਖਾਰੋ।
ਇਹ ਟੂਲ ਟੀਮਾਂ ਨੂੰ ਇੱਕ ਸਾਂਝੀ ਭਾਸ਼ਾ ਦਿੱਤੀ ਤਾਂ ਜੋ ਪੈਟਰਨ-ਪਹਿਚਾਨ ਤੋਂ causal ਸਵਾਲਾਂ ਤੱਕ ਸੁਚੱਜਾ ਅਤੇ ਅਨੁਸ਼ਾਸਿਤ ਤਰੀਕੇ ਨਾਲ ਜਾ ਸਕਣ।
Correlation ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਦੋ ਚੀਜਾਂ ਇਕੱਠੇ ਚਲਦੀਆਂ ਹਨ: ਇੱਕ ਉੱਪਰ ਜਾਂਦਾ ਹੈ ਤਾਂ ਦੂਜਾ ਵੀ ਉੱਪਰ ਜਾਂਦਾ/ਹੇਠਾਂ ਜਾਂਦਾ ਹੈ। ਇਹ ਬਹੁਤ ਲਾਭਦਾਇਕ ਹੈ—ਖਾਸ ਕਰਕੇ ਡਾਟਾ-ਭਾਰੀ ਟੀਮਾਂ ਲਈ—ਕਿਉਂਕਿ ਇਹ ਭਵਿੱਖਬਾਣੀ ਅਤੇ ਡਿਟੈਕਸ਼ਨ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ।
ਜੇ ਆਈਸਕ੍ਰੀਮ ਦੀ ਵਿਕਰੀ ਟੈਮਪਰੇਚਰ ਵਧਣ ਨਾਲ ਛੇਤੀ ਤੇ ਉੱਪਰ ਚੜ੍ਹਦੀ ਹੈ, ਤਾਂ ਇਹ correlated ਸਿਗਨਲ (ਟੈਮਪਰੇਚਰ) forecasting ਵਿੱਚ ਸਹਾਇਕ ਹੋ ਸਕਦਾ ਹੈ। ਪ੍ਰੋਡਕਟ ਅਤੇ AI ਕੰਮ ਵਿੱਚ, correlations ਰੈਂਕਿੰਗ ਮਾਡਲਾਂ ("ਉਹੀ ਦਿਖਾਓ ਜੋ ਸਮਾਨ ਉਪਭੋਗਤਾਵਾਂ ਨੇ ਕਲਿੱਕ ਕੀਤਾ"), ਐਨੋਮਲੀ ਸਪਾਟਿੰਗ ("ਇਹ ਮੈਟਰਿਕ ਆਮ ਤੌਰ 'ਤੇ ਉਸ ਨਾਲ ਟ੍ਰੈਕ ਕਰਦੀ ਹੈ"), ਅਤੇ ਤੇਜ਼ ਡਾਇਗਨੌਸਟਿਕਸ ("ਲੈਟੈਂਸੀ ਵਧਣ 'ਤੇ errors ਵੱਧਦੇ ਹਨ") ਨੂੰ ਚਲਾਉਂਦੇ ਹਨ।
ਮੁੱਦਾ ਉਦੋਂ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਅਸੀਂ correlation ਨੂੰ ਇੱਕ ਵੱਖਰੇ ਸਵਾਲ ਦਾ ਜਵਾਬ ਮੰਨ ਲੈਂਦੇ ਹਾਂ: ਜੇ ਅਸੀਂ ਕੋਈ ਚੀਜ਼ ਉਦੇਸ਼ਪੂਰਵਕ ਬਦਲਾਂ ਤਾਂ ਕੀ ਹੁੰਦਾ? ਇਹ causation ਹੈ।
ਇੱਕ correlated ਸੰਬੰਧ ਕਿਸੇ ਤੀਜੇ ਕਾਰਕ ਨਾਲ ਚੱਲ ਸਕਦਾ ਹੈ ਜੋ ਦੋਹਾਂ ਵੈਰੀਏਬਲਾਂ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਦਾ ਹੈ। X ਨੂੰ ਬਦਲਣਾ ਜ਼ਰੂਰੀ ਨਹੀਂ ਕਿ Y ਨੂੰ ਬਦਲੇ—ਕਿਉਂਕਿ X ਉਹ ਕਾਰਨ ਨਹੀਂ ਹੋ ਸਕਦਾ ਜੋ Y ਨੂੰ ਹਿਲਾਉਂਦਾ ਹੈ।
ਕਲਪਨਾ ਕਰੋ ਕਿ ਤੁਸੀਂ ਹਫ਼ਤਾਵਾਰ ਮਾਰਕੇਟਿੰਗ ਖਰਚਾਂ ਨੂੰ ਹਫ਼ਤਾਵਾਰ ਵਿਕਰੀ ਨਾਲ ਪਲੌਟ ਕਰਦੇ ਹੋ ਅਤੇ ਇੱਕ ਮਜ਼ਬੂਤ ਸਕਾਰਾਤਮਕ correlation ਵੇਖਦੇ ਹੋ। ਇਹ ਦਰਸਾਉਂਦਾ ਹੈ "ਜ਼ਿਆਦਾ ਖਰਚ = ਜ਼ਿਆਦਾ ਵਿਕਰੀ"।
ਪਰ ਧਿਆਨ ਕਰੋ ਕਿ ਦੋਹਾਂ ਦੀ ਉਥਾਨ ਛੁੱਟੀਆਂ ਦੌਰਾਨ ਵੱਧਦੀ ਹੈ। ਸੀਜ਼ਨ (ਇੱਕ confounder) ਉੱਚ ਮੰਗ ਚਲਾਉਂਦਾ ਹੈ ਅਤੇ ਵੱਡੇ ਬਜਟ ਵੀ ਪ੍ਰੇਰਿਤ ਕਰਦਾ ਹੈ। ਜੇ ਤੁਸੀਂ ਗੈਰ-ਛੁੱਟੀ ਹਫਤੇ ਵਿੱਚ ਖਰਚ ਵਧਾਉਂਦੇ ਹੋ, ਤਾਂ ਵਿਕਰੀ ਬਹੁਤ ਨਹੀਂ ਵਧ ਸਕਦੀ—ਕਿਉਂਕਿ ਬੁਨਿਆਦੀ ਮੰਗ ਉਸ ਸਮੇਂ ਨਹੀਂ ਹੈ।
ਤੁਸੀਂ causal ਖੇਤਰ ਵਿੱਚ ਹੋ ਜਦੋਂ ਤੁਸੀਂ ਆਪਣੇ ਆਪ ਨੂੰ ਇਹ ਪੁੱਛਦੇ ਹੋ:
ਜਦੋਂ ਕਿਰਿਆ-ਪਦ (change, launch, remove, reduce) ਹੁੰਦਾ ਹੈ, correlation ਇੱਕ ਸ਼ੁਰੂਆਤੀ ਨਿਸ਼ਾਨ ਹੁੰਦਾ ਹੈ—ਫ਼ੈਸਲੇ ਦਾ ਨਿਯਮ ਨਹੀਂ।
ਕਾਰਨਾਤਮਕ ਡਾਇਗ੍ਰਾਮ—ਅਕਸਰ ਇੱਕ DAG (Directed Acyclic Graph) ਵਜੋਂ—ਟੀਮ ਦੀਆਂ ਧਾਰਨਾਵਾਂ ਨੂੰ ਦਿਖਾਉਣ ਦਾ ਇੱਕ ਸਧਾਰਨ ਤਰੀਕਾ ਹੈ। vague ਤਰਕ ("ਸ਼ਾਇਦ ਮਾਡਲ" ਜਾਂ "ਸ਼ਾਇਦ UI") ਦੀ ਥਾਂ, ਤੁਸੀਂ ਕਹਾਣੀ ਨੂੰ ਕਾਗਜ਼ 'ਤੇ ਲਿਆਉਂਦੇ ਹੋ।
ਮਕਸਦ ਪਰਫੈਕਟ ਸਚ ਨਹੀਂ; ਇਹ “ਸਿਸਟਮ ਕਿਵੇਂ ਸਮਝਦੇ ਹਾਂ” ਦਾ ਇੱਕ ਸਾਂਝਾ ਡ੍ਰਾਫਟ ਹੈ ਜਿਸ 'ਤੇ ਹਰ ਕੋਈ ਟੀਕਾ-ਟਿੱਪਣੀ ਕਰ ਸਕਦਾ ਹੈ।
ਮਾਲ ਕਰੋ ਤੁਸੀਂ ਮੁੱਲਾਂਕਣ ਕਰ ਰਹੇ ਹੋ ਕਿ ਨਵਾਂ onboarding tutorial (T) activation (A) ਵਧਾਉਂਦਾ ਹੈ ਕਿ ਨਹੀਂ।
ਇੱਕ ਆਮ ਵਿਸ਼ਲੇਸ਼ਣਕ ਰੁਝਾਨ ਇਹ ਹੈ ਕਿ “ਉਪਲਬਧ ਸਾਰੇ ਵੈਰੀਏਬਲਾਂ ਨੂੰ control ਕਰੋ।” DAG ਦੀ ਭਾਸ਼ਾ ਵਿੱਚ, ਇਸਦਾ ਮਤਲਬ ਇਹ ਹੋ ਸਕਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਗਲਤੀ ਨਾਲ:
DAG ਨਾਲ ਤੁਸੀਂ ਵੈਰੀਏਬਲਾਂ ਨੂੰ ਇਸ ਲੀਏ adjust ਕਰਦੇ ਹੋ ਕਿ ਕੋਈ ਖਾਸ confounding path ਬੰਦ ਹੋ ਜਾਵੇ—ਸਿਰਫ਼ ਇਸ ਲਈ ਨਹੀਂ ਕਿ ਵੈਰੀਏਬਲ ਮੌਜੂਦ ਹੈ।
ਇੱਕ whiteboard ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ ਅਤੇ ਤਿੰਨ ਕਦਮ:
ਇੱਕ ਰਫ਼ DAG ਵੀ product, data, ਅਤੇ engineering ਨੂੰ ਇੱਕੋ ਹੀ causal ਸਵਾਲ 'ਤੇ ਮਿਲਾ ਦਿੰਦਾ ਹੈ, ਨੰਬਰ ਚਲਾਉਣ ਤੋਂ ਪਹਿਲਾਂ।
Judea Pearl ਦੀ causal ਸੋਚ ਵਿੱਚ ਇਕ ਵੱਡਾ ਤਬਦੀਲੀ ਇਹ ਹੈ ਕਿ ਦੇਖਣਾ ਅਤੇ ਬਦਲਣਾ ਨੂੰ ਵੱਖ ਕਰਨਾ।
ਜੇ ਤੁਸੀਂ ਦੇਖਦੇ ਹੋ ਕਿ notifications ON ਹਨ ਅਤੇ retention ਵਧੀਕ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਇੱਕ ਪੈਟਰਨ ਸਿੱਖਿਆ ਹੈ। ਪਰ ਤੁਸੀਂ ਇਹ ਨਹੀਂ ਜਾਣਦੇ ਕਿ notifications ਨੇ retention ਦਾ ਕਾਰਨ ਬਣਾਇਆ, ਜਾਂ ਉਦੋਂ ਹੀ ਐਂਗੇਜਡ ਉਪਭੋਗਤਾਵਾਂ ਖੁਦ ਨੋਟੀਫਿਕੇਸ਼ਨ ਚਾਲੂ ਕਰਦੇ ਹਨ।
ਇੱਕ ਹਸਤਖੇਪ ਵੱਖਰਾ ਹੈ: ਇਸਦਾ ਮਤਲਬ ਤੁਸੀਂ ਇਕ ਵੇਰੀਏਬਲ ਨੂੰ ਇਕ ਮੁੱਲ 'ਤੇ ਸਰਗਰਮ ਤਰੀਕੇ ਨਾਲ ਸੈਟ ਕਰਦੇ ਹੋ ਅਤੇ ਦੇਖਦੇ ਹੋ ਕਿ ਬਾਅਦ ਵਿੱਚ ਕੀ ਹੁੰਦਾ ਹੈ। ਪ੍ਰੋਡਕਟ ਸ਼ਬਦਾਵਲੀ ਵਿੱਚ, ਇਹ “ਉਪਭੋਗਤਾਵਾਂ ਨੇ X ਚੁਣਿਆ” ਨਹੀਂ ਹੈ, ਇਹ “ਅਸੀਂ X ਰਿਲੀਜ਼ ਕੀਤਾ” ਹੈ।
Pearl ਇਸ ਫਰਕ ਨੂੰ ਆਮ ਤੌਰ 'ਤੇ ਐਸਾ ਦਿਖਾਉਂਦਾ:
“do” ਦਾ ਵਿਚਾਰ ਬੁਨਿਆਦੀ ਤੌਰ 'ਤੇ ਇਹ ਹੈ ਕਿ ਤੁਸੀਂ ਯਾਦ ਰੱਖੋ ਕਿ ਤੁਸੀਂ ਸਧਾਰਨ ਕਾਰਨਾਂ ਨੂੰ ਤੋੜ ਰਹੇ ਹੋ ਜੋ ਕਿਸੇ ਵੈਰੀਏਬਲ ਨੂੰ ਉਹ ਮੁੱਲ ਦਿੰਦੇ ਹਨ। ਜਦੋਂ ਤੁਸੀਂ ਹਸਤਖੇਪ ਕਰਦੇ ਹੋ, ਨੋਟੀਫਿਕੇਸ਼ਨ ਇਸ ਲਈ ON ਨਹੀਂ ਹਨ ਕਿਉਂਕਿ انگیਜਡ ਉਪਭੋਗਤਾਵਾਂ ਨੇ opt-in ਕੀਤਾ; ਉਹ ਇਸ ਲਈ ON ਹਨ ਕਿ ਤੁਸੀਂ ਸੈਟ ਕੀਤਾ। ਇਸਦਾ ਮੁੱਦਾ ਇਹੀ ਹੈ: ਹਸਤਖੇਪ ਕਾਰਨ-ਅਸਰ ਨੂੰ ਅਲੱਗ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਦੇ ਹਨ।
ਬਹੁਤ ਸਾਰਾ ਅਸਲੀ ਪ੍ਰੋਡਕਟ ਕੰਮ ਹਸਤਖੇਪ-ਆਕਾਰ ਦਾ ਹੁੰਦਾ ਹੈ:
ਇਹ ਕਾਰਵਾਈਆਂ ਨਤੀਜਿਆਂ ਨੂੰ ਬਦਲਣ ਦਾ ਉਦੇਸ਼ ਰੱਖਦੀਆਂ ਹਨ, ਨਾ ਕਿ ਸਿਰਫ਼ ਉਨ੍ਹਾਂ ਦਾ ਵੇਰਵਾ ਕਰਨ ਦਾ। causal ਸੋਚ ਪ੍ਰਸ਼ਨ ਨੂੰ ਇमानਦਾਰ ਰੱਖਦੀ ਹੈ: “ਜੇ ਅਸੀਂ ਇਹ ਕਰੀਏ, ਤਾਂ ਕੀ ਬਦਲੇਗਾ?”
ਤੁਸੀਂ ਇੱਕ ਹਸਤਖੇਪ ਦੀ ਵਿਆਖਿਆ (ਜਾਂ ਇਕ ਚੰਗਾ ਪ੍ਰਯੋਗ ਡਿਜ਼ਾਈਨ) ਬਿਨਾਂ ਇਹ ਮੰਨਣਾਂ ਨਹੀਂ ਕਰ ਸਕਦੇ ਕਿ ਕੀ ਪ੍ਰਭਾਵਿਤ ਕਰਦਾ ਹੈ—ਤੁਹਾਡੇ causal ਡਾਇਗ੍ਰਾਮ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ, ਭਾਵੇਂ ਅਣ-ਰਸਮੀ ਹੋਵੇ।
ਉਦਾਹਰਣ ਲਈ, ਜੇ ਸੀਜ਼ਨਲਟੀ ਦੋਹਾਂ ਮਾਰਕੇਟਿੰਗ ਖਰਚ ਅਤੇ ਸਾਈਨ-ਅੱਪ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਦੀ ਹੈ, ਤਾਂ “do” ਕਰਕੇ ਖਰਚ ਵਿੱਚ ਬਦਲਾਅ ਕੀਤੇ ਬਿਨਾਂ ਸੀਜ਼ਨਲ ਪ੍ਰਭਾਵ ਨੂੰ ਅਣਦੇਖਾ ਕਰਨਾ ਮਿਸਲੀਡ ਕਰ ਸਕਦਾ ਹੈ। ਹਸਤਖੇਪ ਤਾਕਤਵਰ ਹਨ, ਪਰ ਉਹ ਤਦ ਤੱਕ ਕਾਰਨਾਤਮਕ ਸਵਾਲਾਂ ਦਾ ਜਵਾਬ ਦਿੰਦੇ ਹਨ ਜਦੋਂ ਤੱਕ ਮੁਢਲਾ causal ਕਹਾਣੀ ਠੀਕ-ਠਾਕ ਹੋ।
ਕਾਊਂਟਰਫੈਕਚੁਅਲ ਇੱਕ ਖਾਸ ਤਰ੍ਹਾਂ ਦਾ “ਕੀ ਹੋਵੇਗਾ?” ਸਵਾਲ ਹੈ: ਇਸ ਖ਼ਾਸ ਕੇਸ ਲਈ, ਜੇ ਅਸੀਂ ਕੋਈ ਵੱਖਰਾ ਕੰਮ ਕੀਤਾ ਹੁੰਦਾ (ਜਾਂ ਕੋਈ ਇਨਪੁਟ ਵੱਖਰਾ ਹੁੰਦਾ), ਤਾਂ ਕੀ ਨਤੀਜਾ ਹੁੰਦਾ? ਇਹ "ਔਸਤ" ਨਹੀਂ ਪੁੱਛਦਾ—ਇਹ ਪੁੱਛਦਾ ਹੈ "ਕੀ ਇਸ ਵਿਅਕਤੀ ਲਈ ਨਤੀਜਾ ਬਦਲਦਾ?"
ਕਾਊਂਟਰਫੈਕਚੁਅਲ ਉਹ ਉਦਾਹਰਣ ਹਨ ਜਦੋਂ ਕੋਈ ਵਿਅਕਤੀ ਇੱਕ ਵੱਖਰੇ ਨਤੀਜੇ ਲਈ ਰਸਤਾ ਮੰਗਦਾ ਹੈ:
ਇਹ ਸਵਾਲ ਆਮ ਤੌਰ 'ਤੇ ਯੂਜ਼ਰ-ਸਤਰ ਦੇ ਹੁੰਦੇ ਹਨ ਅਤੇ ਪ੍ਰੋਡਕਟ ਬਦਲਾਵਾਂ, ਨੀਤੀਆਂ ਅਤੇ ਵਿਆਖਿਆਵਾਂ ਨੂੰ ਰਾਹਦਾਰੀ ਦਿੰਦੇ ਹਨ।
ਕਲਪਨਾ ਕਰੋ ਇੱਕ ਲੋਨ ਮਾਡਲ ਇਕ ਅਰਜ਼ੀ ਨਕਾਰ ਦਿੰਦਾ ਹੈ। ਇੱਕ correlation-ਆਧਾਰਤ ਵਿਆਖਿਆ ਕਹਿ ਸਕਦੀ ਹੈ, “ਘੱਟ ਬਚਤ rejection ਨਾਲ ਜੁੜੀ ਹੈ।” ਇੱਕ ਕਾਊਂਟਰਫੈਕਚੁਅਲ ਪੁੱਛਦਾ ਹੈ:
ਜੇ ਅਰਜ਼ੀਕਰਤਾ ਦੀ ਬਚਤ $3,000 ਵੱਧ ਹੁੰਦੀ (ਹੋਰ ਸਭ ਕੁਝ ਇੱਕੋ ਹੀ), ਕੀ ਮਾਡਲ ਮਨਜ਼ੂਰ ਕਰਦਾ?
ਜੇ ਜਵਾਬ “ਹਾਂ” ਹੈ, ਤਾਂ ਤੁਸੀਂ ਇੱਕ actionable ਬਦਲਾਅ ਸਿੱਖ ਲਿਆ: ਇੱਕ ਸੰਭਵ ਤਬਦੀਲੀ ਜੋ ਫੈਸਲਾ ਪਲਟ ਸਕਦੀ ਹੈ। ਜੇ ਜਵਾਬ “ਨਹੀਂ” ਹੈ, ਤਾਂ ਤੁਸੀਂ ਗਲਤ ਸਲਾਹ ਦੇਣ ਤੋਂ ਬਚ ਗਏ—ਜਿਵੇਂ “ਆਪਣੀ ਬਚਤ ਵਧਾਓ,” ਜਦਕਿ ਅਸਲ ਰੁਕਾਵਟ ਕਰਜ਼ੇ-ਤੋਂ-ਆਮਦਨੀ ਦਾ ਅਨੁਪਾਤ ਜਾਂ ਅਣਸਥਿਰ ਰੋਜ਼ਗਾਰ ਹੋ ਸਕਦਾ ਹੈ।
ਕਾਊਂਟਰਫੈਕਚੁਅਲਸ ਇੱਕ ਕਾਰਨਾਤਮਕ ਮਾਡਲ 'ਤੇ ਨਿਰਭਰ ਕਰਦੇ ਹਨ—ਇੱਕ ਕਹਾਣੀ ਕਿ ਵੈਰੀਏਬਲ ਇਕ ਦੂਜੇ ਨੂੰ ਕਿਵੇਂ ਪ੍ਰਭਾਵਿਤ ਕਰਦੇ ਹਨ—ਸਿਰਫ਼ ਇੱਕ ਡਾਟਾਸੇਟ ਨਹੀਂ। ਤੁਹਾਨੂੰ ਇਹ ਨਿਰਧਾਰਿਤ ਕਰਨਾ ਪਵੇਗਾ ਕਿ ਕੀ ਹਕੀਕਤ ਵਿੱਚ ਬਦਲ ਸਕਦਾ ਹੈ, ਕੀ ਨਤੀਜੇ ਵਜੋਂ ਬਦਲਿਆ ਜਾਵੇਗਾ, ਅਤੇ ਕੀ ਫਿਕਸ ਰਹਿਣਾ ਚਾਹੀਦਾ ਹੈ। ਬਿਨਾਂ ਇਸ causal ਧਾਂਚੇ ਦੇ, ਕਾਊਂਟਰਫੈਕਚੁਅਲ ਅਸੰਭਵ ਪਰਿਣਾਮ ("ਆਮਦਨੀ ਜਾਂ ਖਰਚ ਬਦਲੇ ਬਿਨਾਂ ਬਚਤ ਵਧਾਓ") ਬਣ ਸਕਦੇ ਹਨ ਅਤੇ ਗੈਰ-ਲਾਭਦਾਇਕ ਜਾਂ ਅਨਿਆਂਯ ਸਿਫਾਰਸ਼ਾਂ ਦੇ ਸਕਦੇ ਹਨ।
ਜਦੋਂ ਇੱਕ ML ਮਾਡਲ production ਵਿੱਚ ਫੇਲ੍ਹ ਹੁੰਦਾ ਹੈ, ਤਾਂ root cause ਅਕਸਰ “algorithm ਖਰਾਬ ਹੋ ਗਿਆ” ਨਹੀਂ ਹੁੰਦਾ। ਜ਼ਿਆਦਾਤਰ ਵਾਰੀ ਕੁਝ ਸਿਸਟਮ ਵਿੱਚ ਬਦਲਦਾ ਹੈ: ਤੁਸੀਂ ਕਿਹੜਾ ਡੇਟਾ ਇਕੱਠਾ ਕਰਦੇ ਹੋ, ਲੇਬਲਿੰਗ ਕਿਵੇਂ ਹੁੰਦੀ ਹੈ, ਜਾਂ ਯੂਜ਼ਰ ਕੀ ਕਰਦੇ ਹਨ। causal ਸੋਚ ਤੁਹਾਨੂੰ ਅਟਕਲਾਂ ਛੱਡ ਕੇ ਇਹ ਪਛਾਣਨ ਵਿੱਚ ਮਦਦ ਕਰਦੀ ਹੈ ਕਿ ਕਿਹੜੀ ਬਦਲਾਅ degradation ਦਾ ਕਾਰਨ ਬਣੀ।
ਕੁਝ ਮੁੜ-ਪਰਿਵਰਤਕ ਮੁੱਦੇ ਹਰ ਟੀਮ ਵਿੱਚ ਮਿਲਦੇ ਹਨ:
ਇਹ aggregation dashboards ਵਿੱਚ "ਠੀਕ" ਲੱਗ ਸਕਦੇ ਹਨ ਕਿਉਂਕਿ correlation ਉੱਚ ਰਹਿ ਸਕਦੀ ਹੈ ਭਾਵੇਂ ਮਾਡਲ ਦੇ ਸਹੀ ਹੋਣ ਦਾ ਕਾਰਨ ਬਦਲ ਗਿਆ ਹੋਵੇ।
ਇੱਕ ਸਧਾਰਨ causal ਡਾਇਗ੍ਰਾਮ (DAG) ਡਿਬੱਗਿੰਗ ਨੂੰ ਨਕਸ਼ੇ ਵਾਂਗ ਬਣਾਉਂਦਾ ਹੈ। ਇਹ ਤੁਹਾਨੂੰ ਪੁੱਛਣ ਲਈ ਮਜਬੂਰ ਕਰਦਾ ਹੈ: ਕੀ ਇਹ feature ਲੇਬਲ ਦਾ ਕਾਰਨ ਹੈ, ਇਸ ਦਾ ਨਤੀਜਾ ਹੈ, ਜਾਂ ਇਹ ਮਾਪਣ ਵਿਧੀ ਦਾ ਨਤੀਜਾ ਹੈ?
ਉਦਾਹਰਣ ਲਈ, ਜੇ Labeling policy → Feature engineering → Model inputs ਹੈ, ਤਾਂ ਤੁਹਾਡੇ ਕੋਲ pipeline ਹੋ ਸਕਦੀ ਹੈ ਜਿੱਥੇ ਮਾਡਲ policy ਨੂੰ ਪੇਸ਼ਗੀ ਕਰਦਾ ਹੈ ਨਾਂ ਕਿ ਅਸਲ ਘਟਨਾ। ਇੱਕ DAG ਉਸ ਰਾਹ ਨੂੰ ਦਿਖਾਉਂਦਾ ਤਾਂ ਜੋ ਤੁਸੀਂ ਉਸਨੂੰ ਬਲੌਕ (feature ਹਟਾਉਣਾ, instrumentation ਬਦਲਣਾ, ਜਾਂ label ਦੀ ਪਰਿਭਾਸ਼ਾ ਨਵੀਕਰਨ) ਕਰ ਸਕੋ।
ਸਿਰਫ਼ predictions ਚੈੱਕ ਕਰਨ ਦੀ ਬਜਾਏ, ਸੰਯਮਤ ਹਸਤਖੇਪ ਅਜ਼ਮਾਓ:
ਬਹੁਤ ਸਾਰੇ “explainability” ਟੂਲ ਇੱਕ ਸੰਕੁਚਿਤ ਸਵਾਲ ਦਾ ਜਵਾਬ ਦਿੰਦੇ ਹਨ: ਇਸ ਮਾਡਲ ਨੇ ਇਹ ਸਕੋਰ ਕਿਉਂ ਦਿੱਤਾ? ਉਹ ਆਮ ਤੌਰ 'ਤੇ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਇਨਪੁੱਟ ਹਾਈਲਾਈਟ ਕਰਕੇ ਕੀਤਾ ਜਾਂਦਾ ਹੈ (feature importance, saliency maps, SHAP values)। ਇਹ ਲਾਭਦਾਇਕ ਹੋ ਸਕਦਾ ਹੈ—ਪਰ ਇਹ ਉਸ ਸਿਸਟਮ ਦੀ ਵਿਆਖਿਆ ਨਹੀਂ ਹੈ ਜਿਸ ਵਿੱਚ ਮਾਡਲ ਬੈਠਾ ਹੈ।
ਇੱਕ prediction ਵਿਆਖਿਆ লোকਲ ਅਤੇ ਵਰਣਨਾਤਮਕ ਹੁੰਦੀ ਹੈ: “ਇਹ ਲੋਨ ਨਕਾਰਿਆ ਗਿਆ ਕਿਉਂਕਿ ਆਮਦਨੀ ਘੱਟ ਅਤੇ utilization ਉੱਚ ਸੀ।”
ਇੱਕ ਸਿਸਟਮ ਵਿਆਖਿਆ causal ਅਤੇ ਕਾਰਗਰ ਹੁੰਦੀ ਹੈ: “ਜੇ ਅਸੀਂ verified income ਵਧਾਈਏ (ਜਾਂ utilization ਘਟਾਈਏ) ਤਦ ਇਹ ਫੈਸਲਾ ਬਦਲ ਜਾਵੇਗਾ—ਅਤੇ downstream ਨਤੀਜੇ ਸੁਧਰਣਗੇ?”
ਪਹਿਲੀ ਤੁਹਾਨੂੰ ਮਾਡਲ ਦੇ ਵਿਹਾਰ ਨੂੰ ਸਮਝਣ ਵਿੱਚ ਮਦਦ ਕਰਦੀ ਹੈ। ਦੂਜੀ ਤੁਹਾਨੂੰ ਇਹ ਫੈਸਲਾ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਦੀ ਹੈ ਕਿ ਕੀ ਕਰਨਾਂ ਹੈ।
Causal ਸੋਚ ਵਿਆਖਿਆਵਾਂ ਨੂੰ ਹਸਤਖੇਪ ਨਾਲ ਜੋੜਦੀ ਹੈ। ਤੁਸੀਂ ਪੁੱਛਦੇ ਹੋ ਕਿ ਕਿਹੜੇ ਵੈਰੀਏਬਲ ਵਾਸਤਵਿਕ ਲੇਵਰ ਹਨ ਅਤੇ ਜਦੋਂ ਬਦਲੇ ਜਾਣਗੇ ਤਾਂ ਉਹਨਾਂ ਦਾ ਕੀ ਪ੍ਰਭਾਵ ਹੋਵੇਗਾ।
ਇੱਕ causal ਮਾਡਲ ਤੁਹਾਨੂੰ ਇਹ ਗੱਲ ਸਪਸ਼ਟ ਕਰਨ ਲਈ ਮਜਬੂਰ ਕਰਦਾ ਹੈ:
ਇਸਦਾ ਅਰਥ ਹੈ ਕਿ ਇੱਕ “ਮਹੱਤਵਪੂਰਨ feature” prediction ਲਈ ਫਾਇਦੇਮੰਦ ਹੋ ਸਕਦਾ ਹੈ ਪਰ action ਲਈ ਖ਼ਤਰਨਾਕ proxy ਹੋ ਸਕਦਾ ਹੈ।
Post-hoc explanations ਮਨਪਸੰਦ ਲਗ ਸਕਦੀਆਂ ਹਨ ਪਰ ਪੂਰੀ ਤਰ੍ਹਾਂ correlational ਹੀ ਰਹਿ ਸਕਦੀਆਂ ਹਨ। ਜੇ “support tickets ਦੀ ਗਿਣਤੀ” churn ਦੀ ਭਵਿੱਖਬਾਣੀ ਕਰਦੀ ਹੈ, ਤਾਂ feature-importance ਚਾਰਟ ਟੀਮ ਨੂੰ ਪ੍ਰੇਰਿਤ ਕਰ ਸਕਦਾ ਹੈ ਕਿ “ਟਿਕਟਾਂ ਘਟਾਉਣ ਲਈ support ਨੂੰ ਮਸ਼ਕਲ ਬਣਾਓ।” ਉਹ intervention churn ਵਧਾ ਸਕਦਾ ਹੈ, ਕਿਉਂਕਿ tickets underlying product issues ਦਾ ਲਕੜ ਹਨ—ਕਾਰਨ ਨਹੀਂ।
Correlation-ਆਧਾਰਤ ਵਿਆਖਿਆਵਾਂ distribution shifts 'ਤੇ ਭਵਿੱਖਬਾਣੀ ਨਹੀਂ ਰੱਖਦੀਆਂ: ਜਦੋਂ ਯੂਜ਼ਰ ਵਿਹਾਰ ਬਦਲੇਗਾ, ਉਹੀ highlighted features ਹੁਣੇ ਅਰਥ ਨਹੀਂ ਰੱਖਦੀਆਂ।
ਜਦੋਂ ਫੈਸਲੇ ਦੇ ਨਤੀਜੇ ਅਤੇ ਜ਼ਿੰਮੇਵਾਰੀ ਮਹੱਤਵਪੂਰਨ ਹੁੰਦੀ ਹੈ, causal ਵਿਆਖਿਆ ਮੁੱਲ ਦੀ ਬਣਦੀ ਹੈ:
ਜਦੋਂ ਤੁਹਾਨੂੰ ਕਾਰਵਾਈ करनी ਹੈ, ਨਾ ਕਿ ਸਿਰਫ਼ ਵਿਆਖਿਆ, ਤਾਂ explanation ਨੂੰ causal ਧਾਂਚਾ ਚਾਹੀਦਾ ਹੈ।
A/B ਟੈਸਟਿੰਗ causal inference ਦਾ ਸਭ ਤੋਂ ਸਧਾਰਾ ਅਤੇ ਪ੍ਰਯੋਗਿਕ ਰੂਪ ਹੈ। ਜਦੋਂ ਤੁਸੀਂ ਯੂਜ਼ਰਾਂ ਨੂੰ ਰੈਂਡਮ ਤੌਰ 'ਤੇ variant A ਜਾਂ B ਅਸਾਇਨ ਕਰਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਇੱਕ ਹਸਤਖੇਪ ਕਰ ਰਹੇ ਹੋ: ਤੁਸੀਂ ਸਿਰਫ ਦੇਖ ਰਹੇ ਨਹੀਂ ਹੋ ਕਿ ਲੋਕ ਕੀ ਚੁਣਦੇ, ਤੁਸੀਂ ਉਹ ਦਿੱਤਾ ਜੋ ਉਹ ਵੇਖਣਗੇ। Pearl ਦੀ ਭਾਸ਼ਾ ਵਿੱਚ, randomization “do(variant = B)” ਨੂੰ ਹਕੀਕਤ ਬਣਾਉਂਦਾ ਹੈ—ਇਸਲਈ ਨਤੀਜਿਆਂ ਦੇ ਫਰਕ ਨੂੰ credible ਤੌਰ 'ਤੇ change ਦਾ ਨਤੀਜਾ ਕਿਹਾ ਜਾ ਸਕਦਾ ਹੈ, ਨਾ ਕਿ ਕਿਸ ਨੇ ਕਿਹੜਾ ਚੁਣਿਆ।
ਰੈਂਡਮ ਅਸਾਈਨਮੈਂਟ ਉਪਭੋਗਤਾ ਲੱਛਣ ਅਤੇ exposure ਦੇ ਵਿਚਕਾਰ ਲੁਕਿਆ ਹੋਇਆ ਜੋੜ ਤੋੜ ਦਿੰਦਾ ਹੈ। ਪਾਵਰ ਯੂਜ਼ਰ, ਨਵੇਂ ਯੂਜ਼ਰ, ਸਮਾਂ-ਦਿਨ, ਡਿਵਾਈਸ ਟਾਈਪ—ਇਹ ਸਾਰੇ ਤੱਤ ਮੌਜੂਦ ਰਹਿੰਦੇ ਹਨ, ਪਰ (ਆਮ ਤੌਰ 'ਤੇ) ਸਮੂਹਾਂ ਵਿੱਚ ਸੰਤੁਲਿਤ ਹੋ ਜਾਂਦੇ ਹਨ। ਇਹ ਸੰਤੁਲਨ ਹੈ ਜੋ metric gap ਨੂੰ causal ਦਾਅਵਾ ਬਣਾਉਂਦਾ ਹੈ।
ਵਧੀਆ ਟੀਮਾਂ ਵੀ ਸਾਫ़ ਰੈਂਡਮ ਟੈਸਟ ਨਹੀਂ ਚਲਾ ਸਕਦੀਆਂ:
ਇਹ ਹਾਲਾਤਾਂ ਵਿੱਚ, ਤੁਸੀਂ ਫਿਰ ਵੀ causal ਸੋਚ ਸਕਦੇ ਹੋ—ਤੁਹਾਨੂੰ ਸਿਰਫ਼ ਧਾਰਨਾਵਾਂ ਅਤੇ ਅਣਿਸ਼ਚਿਤਤਾ ਬਾਰੇ ਸਪਸ਼ਟ ਹੋਣਾ ਪਵੇਗਾ।
ਆਮ ਵਿਕਲਪਾਂ ਵਿੱਚ difference-in-differences (ਇੱਕ ਸਮੇਂ ਵਿੱਚ ਦੋ ਸਮੂਹਾਂ ਦੇ ਬਦਲਾਅ ਦੀ ਤੁਲਨਾ), regression discontinuity (ਕਿਸੇ cutoff ਨਿਯਮ ਵਰਗਾ “ਸਿਰਫ ਉਨ੍ਹਾਂ ਨੂੰ ਜਿਨ੍ਹਾਂ ਦਾ ਸਕੋਰ X ਤੋਂ ਉੱਪਰ”), instrumental variables (ਕੋਈ ਕੁਦਰਤੀ ਨਜ) ਜੋ exposure ਨੂੰ ਬਦਲਦਾ ਹੈ ਬਗੈਰ outcome ਨੂੰ ਸਿੱਧਾ ਬਦਲੇ), ਅਤੇ matching/weighting ਸ਼ਾਮਲ ਹਨ। ਹਰ ਇੱਕ ਤਰੀਕੇ randomization ਦੀ ਬਜਾਏ assumptions ਲੈਂਦਾ ਹੈ; ਇੱਕ causal ਡਾਇਗ੍ਰਾਮ ਤੁਹਾਨੂੰ ਉਹ assumptions ਸਪਸ਼ਟ ਕਰਨ 'ਚ ਮਦਦ ਕਰੇਗਾ।
ਟੈਸਟ (ਜਾਂ observational ਅਧਿਐਨ) ਜਾਰੀ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਲਿਖੋ: primary metric, guardrails, target population, ਅਵਧੀ, ਅਤੇ decision rule। pre-registration bias ਖ਼ਤਮ ਨਹੀਂ ਕਰਦੀ, ਪਰ metric-shopping ਨੂੰ ਘਟਾਉਂਦੀ ਹੈ ਅਤੇ causal ਦਾਵਿਆਂ ਨੂੰ ਟੀਮ ਲਈ ਭਰੋਸੇਯੋਗ ਬਨਾਉਂਦੀ—ਅਤੇ ਚਰਚਾ ਲਈ ਸਪਸ਼ਟ।
ਅਕਸਰ ਪ੍ਰੋਡਕਟ ਤੇ ਭੜਕਾਉਂਦੀਆਂ ਬਹਿਸਾਂ ਸਦੀਆਂ ਇਸ ਤਰ੍ਹਾਂ ਲੱਗਦੀਆਂ ਹਨ: “Metric X Y ਦੇ ਬਾਅਦ ਹਿਲਿਆ—ਇਸਦਾ ਮਤਲਬ Y ਨੇ ਕੰਮ ਕੀਤਾ।” causal ਸੋਚ ਇਹਨੂੰ ਨਿੱਘਾ ਕਰਦੀ ਹੈ: “ਕੀ ਬਦਲਾਅ Y ਨੇ Metric X ਨੂੰ ਹਿਲਾਇਆ, ਅਤੇ ਕਿੰਨਾ?” ਇਹ ਤਬਦੀਲੀ dashboards ਨੂੰ ਸਬੂਤ ਤੋਂ ਸ਼ੁਰੂਆਤ ਵਿੱਚ ਬਦਲ ਦਿੰਦੀ ਹੈ।
ਕੀਮਤ ਬਦਲਾਅ: “ਕੀ ਕੀਮਤ 10% ਵਧਾਉਣ ਦਾ ਪ੍ਰਭਾਵ paid conversion, churn, ਅਤੇ support tickets 'ਤੇ ਕੀ ਹੈ, ਸੀਜ਼ਨਲਟੀ ਨੂੰ ਇੱਕਸਾਰ ਰੱਖ ਕੇ?”
Onboarding ਟਵਿਕ: “ਜੇ ਅਸੀਂ onboarding ਨੂੰ 6 ਕਦਮ ਤੋਂ 4 ਕਦਮ ਕਰ ਦਈਏ, ਤਾਂ ਨਵੇਂ ਉਪਭੋਗਤਾਵਾਂ ਲਈ activation ਅਤੇ week-4 retention 'ਤੇ ਕੀ ਪ੍ਰਭਾਵ ਹੋਵੇਗਾ?”
Recommendation ranking ਬਦਲਾਅ: “ਜੇ ਅਸੀਂ freshness ਨੂੰ promote ਕਰਕੇ results reorder ਕਰੀਏ, ਤਾਂ ਲੰਮੇ ਸਮੇਂ ਦੀ ਸੰਤੁਸ਼ਟੀ (returns, hides, unsubscribes) 'ਤੇ ਕੀ ਪ੍ਰਭਾਵ ਹੋਏਗਾ, ਸਿਰਫ਼ clicks ਨਹੀਂ?”
Dashboards ਆਮ ਤੌਰ 'ਤੇ “ਜਿਸਨੂੰ ਬਦਲਾਅ ਮਿਲਿਆ” ਨੂੰ “ਜੋ ਪਹਿਲਾਂ ਹੀ ਚੰਗਾ ਸੀ” ਨਾਲ ਮਿਲਾ ਦਿੰਦੇ ਹਨ। ਇੱਕ ਕਲਾਸਿਕ ਉਦਾਹਰਣ: ਤੁਸੀਂ ਇੱਕ नया onboarding flow ship ਕੀਤਾ, ਪਰ ਇਹ ਨਵੀਂ app version 'ਤੇ ਪਹਿਲਾਂ ਹੀ ਦਿਖਾਇਆ ਗਿਆ। ਜੇ ਨਵੀਆਂ versions ਅਕਸਰ ਵੱਧ انگیਜਡ ਉਪਭੋਗਤਾਵਾਂ ਦੁਆਰਾ اپنਾਈ ਜਾਂਦੀਆਂ ਹਨ, ਤਾਂ ਤੁਹਾਡਾ ਚਾਰਟ ਉਹਨਾਂ ਦੇ ਅਨੁਸਾਰ uplift ਦੇਖਾ ਸਕਦਾ ਹੈ—ਜੋ ਆংশਿਕ ਜਾਂ ਪੂਰੀ ਤਰ੍ਹਾਂ version adoption ਦੀ وجہ ਹੋ ਸਕਦੀ ਹੈ, ਨਾ ਕਿ onboarding।
ਹੋਰ ਆਮ confounders:
ਇੱਕ ਲਾਭਦਾਇਕ PRD ਸੈਕਸ਼ਨ ਨਾਮੀ “Causal Questions” ਹੋ ਸਕਦੀ ਹੈ, ਜਿਸ ਵਿੱਚ:
ਜੇ ਤੁਸੀਂ ਤੇਜ਼ build loop ਵਰਤ ਰਹੇ ਹੋ (ਖਾਸ ਕਰਕੇ LLM-assisted development ਨਾਲ), ਇਹ ਸੈਕਸ਼ਨ ਹੋਰ ਵੀ ਮਹੱਤਵਪੂਰਨ ਹੋ ਜਾਂਦਾ ਹੈ: ਇਹ “ਅਸੀਂ ਤੇਜ਼ੀ ਨਾਲ ship ਕਰ ਸਕਦੇ ਹਾਂ” ਨੂੰ रोਕਦਾ ਹੈ ਕਿ “ਅਸੀਂ ਬਿਨਾਂ ਪਤਾ ਕੀਤੇ ship ਕਰ ਦਿੱਤਾ।” Koder.ai ਵਰਗੀਆਂ ਪਲੇਟਫਾਰਮਾਂ ਉੱਤੇ ਟੀਮਾਂ ਆਮ ਤੌਰ 'ਤੇ ਇਹ causal ਸਵਾਲ ਪਹਿਲਾਂ ਹੀ planning mode 'ਚ ਰੱਖਦੀਆਂ ਹਨ, ਫਿਰ feature-flagged variants ਤੇਜ਼ੀ ਨਾਲ ਇੰਪਲੀਮੈਂਟ ਕਰਦੀਆਂ ਹਨ, snapshots/rollback ਨਾਲ experimentation ਸੁਰੱਖਿਅਤ ਰੱਖਦੀਆਂ ਹਨ ਜਦੋਂ ਨਤੀਜੇ (ਜਾਂ side effects) ਹੈਰਾਨ ਕਰਦੇ ਹਨ।
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 ਨਹੀਂ।
Causal ਸੋਚ ਨੂੰ PhD-ਪੱਧਰੀ rollout ਦੀ ਲੋੜ ਨਹੀਂ। ਇਸਨੂੰ ਟੀਮ ਦੀ ਆਦਤ ਬਣਾਓ: ਆਪਣੀ causal ਕਹਾਣੀ ਲਿਖੋ, ਉਸ 'ਤੇ ਦਬਾਅ ਪਾਓ, ਫਿਰ ਡਾਟਾ (ਅਤੇ ਸੰਭਵ ਹੋਵੇ ਤਾਂ ਪ੍ਰਯੋਗ) ਨਾਲ ਉਸਨੂੰ ਪੁਸ਼ਟ ਜਾਂ ਸੋਧੋ।
ਤਰੱਕੀ ਕਰਨ ਲਈ, ਚਾਰ ਇਨਪੁਟ ਪਹਿਲਾਂ ਇਕੱਠੇ ਕਰੋ:
ਅਮਲ ਵਿੱਚ, ਤੇਜ਼ੀ ਮਹੱਤਵਪੂਰਨ ਹੈ: ਜਿੰਨੀ ਤੇਜ਼ੀ ਤੁਸੀਂ causal ਸਵਾਲ ਨੂੰ controlled ਬਦਲਾਅ ਵਿੱਚ ਬਦਲ ਸਕਦੇ ਹੋ, ਉਤਨਾ ਘੱਟ ਸਮਾਂ ਤੁਸੀਂ ambiguity 'ਤੇ ਵਿਵਾਦ ਕਰਦੇ ਹੋ। ਇਸੇ ਕਾਰਨ ਟੀਮਾਂ Koder.ai ਵਰਗੀਆਂ ਪਲੇਟਫਾਰਮਾਂ ਨੂੰ ਅਪਣਾਉਂਦੀਆਂ ਹਨ ਤਾਂ ਕਿ “hypothesis + plan” ਤੋਂ ਵਰਕਿੰਗ, instrumented implementation (web, backend, ਜਾਂ mobile) ਦਿਨਾਂ ਵਿੱਚ ਮਿਲ ਜਾਵੇ—ਅਤੇ staged rollouts, deployments, ਅਤੇ rollback ਰਾਹੀਂ ਰਿਗਰ ਰਹੇ।
ਜੇ ਤੁਸੀਂ experiments 'ਤੇ ਰੀਫ੍ਰੈਸ਼ਰ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ /blog/ab-testing-basics ਨੂੰ ਦੇਖੋ। ਉਹਨਾਂ traps ਲਈ ਜੋ ਪ੍ਰੋਡਕਟ ਮੈਟਰਿਕਸ ਨੂੰ “effects” ਵਰਗਾ ਦਿਖਾਉਂਦੇ ਹਨ, /blog/metrics-that-mislead ਵੇਖੋ।
Causal ਸੋਚ “ਕੀ ਆਮ ਤੌਰ 'ਤੇ ਇਕੱਠੇ ਹਿਲਦਾ ਹੈ?” ਤੋਂ “ਜੇ ਅਸੀਂ ਕਾਰਵਾਈ ਕਰੀਏ ਤਾਂ ਕੀ ਬਦਲੇਗਾ?” ਤੱਕ ਇੱਕ ਬਦਲਾਅ ਹੈ। ਇਹ ਬਦਲਾਅ—ਜਿਸ ਨੂੰ Judea Pearl ਨੇ computing ਅਤੇ statistics ਵਿੱਚ ਪਿੱਛੇ ਦਿੱਤਾ—ਟੀਮਾਂ ਨੂੰ ਉਹਨਾਂ ਕਿੱਤੇ ਹੋਏ ਕਹਾਣੀਆਂ ਤੋਂ ਬਚਾਉਂਦਾ ਹੈ ਜੋ ਅਸਲ ਦੁਨੀਆ ਵਿੱਚ ਹਸਤਖੇਪ ਦੇ ਸਮਨੇ ਟਿਕ ਨਹੀਂ ਪਾਉਂਦੀਆਂ।
Correlation ਇੱਕ ਠੋਕਰਾ ਹੈ, ਜਵਾਬ ਨਹੀਂ।
Causal diagrams (DAGs) ਧਾਰਨਾਵਾਂ ਨੂੰ ਦਿੱਖਾਉਂਦੇ ਅਤੇ ਗੱਲਬਾਤਯੋਗ ਬਣਾਉਂਦੇ ਹਨ।
Interventions (“do”) observations (“see”) ਤੋਂ ਵੱਖ ਹਨ।
Counterfactuals ਇਕੱਲੇ ਕੇਸਾਂ ਨੂੰ ਸਮਝਾਉਂਦੇ ਹਨ: “ਜੇ ਇਹ ਇਕ ਗੱਲ ਵੱਖਰੀ ਹੁੰਦੀ ਤਾਂ?”
ਚੰਗਾ causal ਕੰਮ uncertainty ਅਤੇ ਵਿਕਲਪਕ ਵਿਆਖਿਆਵਾਂ ਨੂੰ ਦਰਜ ਕਰਦਾ ਹੈ।
Causality ਸੰਭਾਲ ਦੀ ਲੋੜ ਹੈ: ਲੁਕਿਆ confounders, ਮਾਪਣ ਗਲਤੀਆਂ, ਅਤੇ selection effects ਨਤੀਜੇ ਉਲਟ ਸਕਦੇ ਹਨ। ਇਕ ਢੰਗ ਇਹ ਹੈ ਕਿ assumptions ਖੁੱਲ੍ਹੇ ਤੌਰ 'ਤੇ ਲਿਖੋ, ਦਿਖਾਓ ਕਿ ਕਿਹੜਾ ਡਾਟਾ ਵਰਤਿਆ, ਅਤੇ ਕੀ ਚੀਜ਼ ਤੁਹਾਡੇ ਦਾਅਵੇ ਨੂੰ ਗਲਤ ਕਰ ਸਕਦੀ ਹੈ।
ਜੇ ਤੁਸੀਂ ਹੋਰ ਗਹਿਰਾਈ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ /blog 'ਤੇ ਸੰਬੰਧਤ ਲੇਖਾਂ ਨੂੰ ਵੇਖੋ ਅਤੇ causal approaches ਦੀ ਤੁਲਨਾ ਹੋਰ analytics ਅਤੇ “explainability” ਵਿਧੀਆਂ ਨਾਲ ਕਰੋ ਤਾਂ ਕਿ ਪਤਾ ਲੱਗੇ ਕਿ ਹਰ ਇੱਕ ਕਿੱਥੇ ਮਦਦਗਾਰ ਹੈ—ਅਤੇ ਕਿੱਥੇ ਭੇਉਟਾ ਕਰ ਸਕਦਾ ਹੈ।
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.
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.
A DAG (Directed Acyclic Graph) is a simple diagram where:
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.
A common mistake is “control for everything,” which can accidentally adjust for mediators or colliders and bias the result.
“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.
A counterfactual asks: for this specific case, what would have happened if we had done something else.
It’s useful for:
It requires a causal model so you don’t propose impossible changes.
Focus on what changed upstream and what the model might be exploiting:
A causal mindset pushes you to test targeted interventions (ablations, perturbations) instead of chasing coincident metric movements.
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.
Randomized A/B tests are best when feasible, but you may need alternatives when:
In those cases, consider quasi-experiments like difference-in-differences, regression discontinuity, instrumental variables, or matching/weighting—while being explicit about assumptions.
Add a short section that forces clarity before analysis:
This keeps the team aligned on a causal question rather than post-hoc dashboard storytelling.