05 ਅਗ 2025·7 ਮਿੰਟ
ਏਆਈ ਪੱਖਪਾਤ ਟੈਸਟਿੰਗ ਵਰਕਫਲੋ: Joy Buolamwini ਤੋਂ ਸਿੱਖੇ ਗਏ ਪਾਠ
Joy Buolamwini ਤੋਂ ਸਿੱਖੀਆਂ ਗਈਆਂ ਪਾਠਾਂ ਅਤੇ ਇੱਕ ਸੁਲਝੀ ਹੋਈ ਆਰੰਭਿਕ ਸਮੀਖਿਆ ਪ੍ਰਕਿਰਿਆ — ਜੋ ਟੀਮਾਂ ਲਾਂਚ ਤੋਂ ਪਹਿਲਾਂ ਚਲਾ ਕੇ ਰੋਕਣਯੋਗ ਨੁਕਸਾਨ ਘਟਾ ਸਕਦੀਆਂ ਹਨ।
Joy Buolamwini ਤੋਂ ਸਿੱਖੀਆਂ ਗਈਆਂ ਪਾਠਾਂ ਅਤੇ ਇੱਕ ਸੁਲਝੀ ਹੋਈ ਆਰੰਭਿਕ ਸਮੀਖਿਆ ਪ੍ਰਕਿਰਿਆ — ਜੋ ਟੀਮਾਂ ਲਾਂਚ ਤੋਂ ਪਹਿਲਾਂ ਚਲਾ ਕੇ ਰੋਕਣਯੋਗ ਨੁਕਸਾਨ ਘਟਾ ਸਕਦੀਆਂ ਹਨ।
ਅਧਿਕਤਰ ਉਪਭੋਗਤਾਵਾਂ ਲਈ, “ਪੱਖਪਾਤ” ਗਣਿਤ ਵਿਵਾਦ ਨਹੀਂ ਹੈ। ਇਹ ਇੱਕ ਐਸਾ ਉਤਪਾਦ ਹੈ ਜੋ ਕੁਝ ਲੋਕਾਂ ਲਈ ਕੰਮ ਕਰਦਾ ਹੈ ਤੇ ਹੋਰਾਂ ਲਈ ਅਸਫਲ ਰਹਿੰਦਾ ਹੈ: ਫੇਸ ਅਨਲੌਕ ਜੋ ਤੁਹਾਨੂੰ ਪਹਚਾਨਦਾ ਨਹੀਂ, ਹਾਇਰਿੰਗ ਸਕ੍ਰੀਨ ਜੋ ਕੁਝ ਨਾਮਾਂ ਵਾਲੇ ਯੋਗ ਉਮੀਦਵਾਰਾਂ ਨੂੰ ਰੱਦ ਕਰ ਦਿੰਦਾ, ਜਾਂ ਇੱਕ ਸਹਾਇਤਾ ਬੋਟ ਜੋ ਇਕ ਗਰੁੱਪ ਨਾਲ ਨਰਮ ਹੋ ਕੇ ਦੂਜੇ ਨਾਲ ਸਖ਼ਤ ਵਰਤਾਅ ਕਰਦਾ ਹੈ। ਨਤੀਜਾ ਹੋਂਦਾ ਹੈ ਅਸਮਾਨ ਗਲਤੀਆਂ, ਬਾਹਰ ਰੱਖਣਾ, ਅਤੇ ਇੱਕ ਸਾਫ਼ ਸੁਨੇਹਾ ਕਿ ਉਤਪਾਦ ਤੁਹਾਡੇ ਲਈ ਨਹੀਂ ਬਣਾਇਆ ਗਿਆ।
ਟੀਮਾਂ ਇਸਨੂੰ ਇਸ ਲਈ ਮਿਸ ਕਰਦੀਆਂ ਹਨ ਕਿਉਂਕਿ ਆਰੰਭਿਕ ਟੈਸਟ ਆਮ ਤੌਰ 'ਤੇ ਡੈਮੋ ਵਰਗਾ ਹੁੰਦਾ ਹੈ: ਛੋਟਾ ਡੇਟਾਸੈੱਟ, ਕੁਝ ਚੁਣੇ ਹੋਏ ਉਦਾਹਰਨ ਅਤੇ ਨੇੜਲੇ ਲੋਕਾਂ ਵੱਲੋਂ ਇੱਕ ਤੇਜ਼ “ਮੇਰੇ ਲਈ ਕੰਮ ਕਰਦਾ” ਪਾਸ। ਜੇ ਕਮਰੇ ਵਿੱਚ ਹਰ ਕੋਈ ਮਿਲਦੀ-ਜੁਲਦੀ ਪਿੱਠਭੂਮੀ, ਡਿਵਾਈਸ, ਉਚਾਰਣ, ਰੋਸ਼ਨੀ ਜਾਂ ਲਿਖਣ ਦਾ ਅੰਦਾਜ਼ ਰੱਖਦਾ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਹੱਕ ਵਿੱਚ ਕੁਝ ਹਿੱਸੇ ਲਈ ਹੀ ਟ੍ਰੇਨਿੰਗ ਅਤੇ ਟੈਸਟਿੰਗ ਕਰ ਸਕਦੇ ਹੋ।
ਉਮੀਦਾਂ ਬਦਲ ਗਈਆਂ। ਹੁਣ ਸਿਰਫ਼ ਇਹ ਕਹਿਣਾ ਕਿ “ਸਹੀਤਾ ਉੱਚੀ ਹੈ” ਕਾਫ਼ੀ ਨਹੀਂ ਰਹੀ। ਸਟੇਕਹੋਲਡਰ ਹੁਣ ਪੁੱਛਦੇ ਹਨ: ਕੌਣ ਫੇਲ ਹੁੰਦਾ ਹੈ, ਕਿੰਨੀ ਵਾਰ, ਅਤੇ ਜਦੋਂ ਉਹ ਫੇਲ ਕਰਦਾ ਹੈ ਤਾਂ ਕੀ ਹੁੰਦਾ ਹੈ? ਇਕ ਉਤਪਾਦ ਦਾ ਮੁਲਿਆੰਕਨ ਸਿਰਫ਼ ਔਸਤ ਪ੍ਰਦਰਸ਼ਨ ਨਾਲ ਨਹੀਂ, ਬਲਕਿ ਅਸਮਾਨ ਪ੍ਰਦਰਸ਼ਨ ਅਤੇ ਗਲਤੀਆਂ ਦੇ ਅਸਲ ਜ਼ਖਮ ਨਾਲ ਕੀਤਾ ਜਾਂਦਾ ਹੈ।
ਪੱਖਪਾਤ ਟੈਸਟਿੰਗ ਉਸੇ ਕਾਰਨ ਨਾਲ ਉਤਪਾਦੀ ਲੋੜ ਬਣੀ ਜੋ ਸੁਰੱਖਿਆ ਟੈਸਟਿੰਗ ਬਣੀ ਸੀ। ਜਦੋਂ ਲੋਕਤਾਂਤ੍ਰਿਕ ਨਾਕਾਮੀਆਂ ਹੋਣੀਆਂ ਸ਼ੁਰੂ ਹੁੰਦੀਆਂ ਹਨ, “ਅਸੀਂ ਇਸ ਬਾਰੇ ਸੋਚਿਆ ਨਹੀਂ” ਇੱਕ ਕਬੂਲਯੋਗ ਜਵਾਬ ਨਹੀਂ ਰਹਿੰਦਾ। ਛੋਟੀ ਟੀਮਾਂ ਤੋਂ ਵੀ ਬੁਨਿਆਦੀ ਸਾਵਧਾਨੀ ਦੇਖਣ ਦੀ ਉਮੀਦ ਕੀਤੀ ਜਾਂਦੀ ਹੈ।
ਇੱਕ ਪ੍ਰਯੋਗਿਕ ਵਰਕਫਲੋ ਲਈ ਲੈਬ ਜਾਂ ਕਮੇਟੀ ਦੀ ਲੋੜ ਨਹੀਂ। ਇਹਨਾਂ ਚੀਜ਼ਾਂ ਦੀ ਲੋੜ ਹੈ ਜੋ ਤੁਸੀਂ ਦੁਹਰਾਵ: ਪਤੇ ਲਗਾਓ ਕਿ ਫੀਚਰ ਕਿਸ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਦਾ ਹੈ ਅਤੇ ਕਿਵੇਂ ਗਲਤ ਹੋ ਸਕਦਾ ਹੈ; ਵੱਖ-ਵੱਖ ਯੂਜ਼ਰ ਗਰੁੱਪਾਂ ਵਿੱਚ ਹਕੀਕਤੀ ਕੇਸਾਂ ਦੀ ਛੋਟੀ ਜਾਂਚ ਕਰੋ; ਨਿਰਣਯ ਕਰੋ ਕਿ ਕਿਹੜੀਆਂ ਗਲਤੀਆਂ ਅਸਵੀਕਾਰਯੋਗ ਹਨ ਅਤੇ fallback ਕੀ ਹੈ; ਅਤੇ ਫੈਸਲਾ ਦਸਤਾਵੇਜ਼ ਕਰੋ ਤਾਂ ਜੋ ਅਗਲੀ ਰਿਲੀਜ਼ ਸਿਫ਼ਰ ਤੋਂ ਸ਼ੁਰੂ ਨਾ ਹੋਵੇ।
Joy Buolamwini ਇੱਕ ਕੰਪਿਊਟਰ ਸਾਇੰਟਿਸਟ ਅਤੇ ਐਕਟਿਵਿਸਟ ਹਨ ਜਿਨ੍ਹਾਂ ਨੇ ਪੱਖਪਾਤ ਟੈਸਟਿੰਗ ਨੂੰ ਚਰਚਾ ਵਿੱਚ ਲਿਆਂਦਾ। ਉਹਨਾਂ ਦਾ ਕੰਮ Gender Shades ਨਤੀਜਿਆਂ 'ਤੇ ਰੋਸ਼ਨੀ ਪਾਉਂਦਾ ਹੈ: ਕੁਝ ਫੇਸ ਐਨਾਲਿਸਿਸ ਸਿਸਟਮ ਹਨ ਜੋ ਹਲਕੇ ਰੰਗ ਵਾਲੇ ਮਰਦਾਂ 'ਤੇ ਕਾਲੇ-ਗੌਰੀ ਔਰਤਾਂ ਦੀ ਤੁਲਨਾ ਵਿੱਚ ਕਾਫੀ ਚੰਗੀ ਪ੍ਰਦਰਸ਼ਨ ਦਿਖਾਉਂਦੇ ਸਨ।
ਮੁੱਖ ਸਿੱਖ ਇਹ ਨਹੀਂ ਕਿ "ਏਆਈ ਹਮੇਸ਼ਾ ਪੱਖਪਾਤੀ ਹੈ"। ਸਿੱਖ ਇਹ ਹੈ ਕਿ ਇਕ ਹੇਡਲਾਈਨ ਨੰਬਰ, ਜਿਵੇਂ ਕਿ ਕੁੱਲ ਸਹੀਤਾ, ਵੱਡੇ ਫ਼ਰਕਾਂ ਨੂੰ ਛੁਪਾ ਸਕਦਾ ਹੈ। ਇਕ ਟੀਮ Sachchi ਤਰ੍ਹਾਂ ਕਹਿ ਸਕਦੀ ਹੈ “ਇਹ 95% ਵਾਰੀ ਕੰਮ ਕਰਦਾ ਹੈ” ਜਦਕਿ ਇੱਕ ਛੋਟਾ ਗਰੁੱਪ ਕਾਫ਼ੀ ਬੁਰੀ ਅਨੁਭਵ ਮਿਲਦਾ ਹੈ। ਜੇ ਤੁਹਾਡਾ ਉਤਪਾਦ ਹਾਇਰਿੰਗ, ਪਹਚਾਣ ਜਾਂਚ, ਸੁਰੱਖਿਆ, ਹੈਲਥਕੇਅਰ ਜਾਂ ਸੇਵਾਵਾਂ ਤੱਕ ਪਹੁੰਚ ਨੂੰ ਛુਹਦਾ ਹੈ, ਤਾਂ ਇਹ ਫ਼ਰਕ ਗੱਲ-ਮਾਤਰਾ ਦਾ ਮਾਮਲਾ ਨਹੀਂ ਹੈ। ਇਹ ਉਤਪਾਦ ਹੈ।
ਇਸ ਤਰ੍ਹਾਂ ਦੇ ਮਾਮਲਿਆਂ ਤੋਂ ਬਾਅਦ, ਸਵਾਲ ਹੋਰ ਤੇਜ਼ ਹੋ ਗਏ। ਉਪਭੋਗਤਾ ਪੁੱਛਦੇ ਹਨ ਕਿ ਕੀ ਇਹ ਉਹਨਾਂ ਵਰਗੇ ਲੋਕਾਂ ਲਈ ਕੰਮ ਕਰੇਗਾ। ਗਾਹਕ ਚਾਹੁੰਦੇ ਹਨ ਪ੍ਰਮਾਣ ਕਿ ਤੁਸੀਂ ਸਮੂਹਾਂ ਵਿੱਚ ਟੈਸਟ ਕੀਤਾ। ਪ੍ਰੈਸ ਤੇ ਨਿਯਮਕਾਰੀ ਪੁੱਛਦੇ ਹਨ ਕਿ ਜਦੋਂ ਇਹ ਫੇਲ ਕਰਦਾ ਹੈ ਤਾਂ ਕੌਣ ਨੁਕਸਾਨ ਪਾਉਂਦਾ ਹੈ ਅਤੇ ਤੁਸੀਂ ਪ੍ਰਭਾਵਸ਼ালী ਨੁਕਸਾਨ ਰੋਕਣ ਲਈ ਕੀ ਕੀਤਾ।
ਤੁਹਾਨੂੰ ਰਿਸਰਚ ਲੈਬ ਦੀ ਲੋੜ ਨਹੀਂ ਕਿ ਤੁਸੀਂ ਇਹਨਾਂ ਫੇਲੀਆਂ ਤੋਂ ਸਿੱਖ ਸਕੋ। ਤੁਹਾਨੂੰ ਉਹ ਥਾਵਾਂ ਟੈਸਟ ਕਰਨੀ ਚਾਹੀਦੀਆਂ ਹਨ ਜਿੱਥੇ ਨੁਕਸਾਨ ਇਕੱਠਾ ਹੁੰਦਾ ਹੈ, ਨਾ ਕਿ ਜਿੱਥੇ ਮਾਪਨਾ ਸਭ ਤੋਂ ਅਸਾਨ ਹੈ। ਇੱਕ ਸਕੂਨ ਚੈੱਕ ਵੀ, ਜਿਵੇਂ “ਕੀ ਗਲਤੀਆਂ ਚਮੜੀ ਦੇ ਰੰਗ, ਐਕਸੈਂਟ, ਉਮਰ, ਨਾਮ ਦੀ ਉਤਪੱਤੀ ਜਾਂ ਡਿਵਾਈਸ ਗੁਣਵੱਤਾ ਅਨੁਸਾਰ ਜਥੇਬੰਦੀ ਹੁੰਦੀਆਂ ਹਨ?” ਮੁੱਖ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਪਹਿਲਾਂ ਹੀ ਸਾਹਮਣੇ ਲਿਆ ਸਕਦਾ ਹੈ।
ਪੱਖਪਾਤ ਟੈਸਟਿੰਗ ਅਸਲ ਵਿੱਚ ਉਸ ਸਮੇਂ ਅਰਥਪੂਰਨ ਹੁੰਦੀ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਇਸਨੂੰ ਹੋਰ ਉਤਪਾਦੀ ਲੋੜਾਂ ਵਾਂਗ ਮੰਨਦੇ ਹੋ: ਇੱਕ ਸ਼ਰਤ ਜੋ ਸ਼ਿਪ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਸੱਚ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ।
ਉਤਪਾਦੀ ਸ਼ਬਦਾਂ ਵਿੱਚ, ਪੱਖਪਾਤ ਟੈਸਟਿੰਗ ਦਾ ਮਤਲਬ ਹੈ ਜਾਂਚਨਾ ਕਿ ਸਿਸਟਮ ਵੱਖ-ਵੱਖ ਸਮੂਹਾਂ ਲਈ ਵੱਖ-ਵੱਖ ਵਰਤਾਰਾ ਕਰਦਾ ਹੈ ਕਿ ਨਹੀਂ, ਤਰੇਕੇ ਜਿਨ੍ਹਾਂ ਨਾਲ ਪਹੁੰਚ ਬੰਦ ਹੋ ਸਕਦੀ ਹੈ, ਨੁਕਸਾਨ ਹੋ ਸਕਦਾ ਹੈ ਜਾਂ ਨਿਆਂ ਜੋ ਨਤੀਜੇ ਬਣ ਸਕਦੇ ਹਨ। ਇਹ ਇਹ ਵੀ ਹੈ ਕਿ ਤੁਸੀਂ ਲਿਖ ਕੇ ਰੱਖੋ ਕਿ ਸਿਸਟਮ ਕੀ ਕਰ ਸਕਦਾ ਹੈ ਅਤੇ ਕੀ ਨਹੀਂ, ਤਾਂ ਜੋ ਉਪਭੋਗਤਾ ਅਤੇ ਸਪੋਰਟ ਟੀਮ ਅਨੁਮਾਨ ਨਾ ਲਗਾਉਣ।
ਜ਼ਿਆਦਾਤਰ ਟੀਮਾਂ ਇਹਨਾਂ ਨੂੰ ਕੁਝ ਸਧਾਰਨ ਲੋੜਾਂ ਵਿੱਚ ਤਬਦੀਲ ਕਰ ਸਕਦੀਆਂ ਹਨ:
ਪੱਖਪਾਤ ਟੈਸਟਿੰਗ ਇੱਕ ਵਾਰੀ-ਕਾਮ ਨਹੀਂ। ਮਾਡਲ ਬਦਲਦੇ ਹਨ, ਡੇਟਾ ਡ੍ਰਿਫ਼ਟ ਹੁੰਦੀ ਹੈ, ਅਤੇ ਨਵੇਂ ਯੂਜ਼ਰ ਸੈਗਮੈਂਟ ਆਉਂਦੇ ਹਨ। ਤੁਸੀਂ ਪਰਫੈਕਟ ਨਿਆਂ ਦੀ ਕੋਸ਼ਿਸ਼ ਨਹੀਂ ਕਰ ਰਹੇ—ਤੁਹਾਡਾ ਮਨੋਰਥ ਜਾਣੇ ਹੋਏ ਜੋਖਮ, ਮਾਪੇ ਗਏ ਫ਼ਾਸਲੇ ਅਤੇ ਸਮਝਦਾਰ ਗਾਰਡਰੇਲ ਰੱਖਣਾ ਹੈ।
ਪੱਖਪਾਤ ਦੀਆਂ ਸਮੱਸਿਆਵਾਂ ਅਕਸਰ ਡੈਸ਼ਬੋਰਡ 'ਤੇ ਇੱਕ ਗਲਤ ਨੰਬਰ ਵਾਂਗ ਨਹੀਂ ਦਿਖਾਈ ਦਿੰਦੀਆਂ। ਇਹ ਉਸ ਸਮੇਂ ਨਜ਼ਰ ਆਉਂਦੀਆਂ ਹਨ ਜਦੋਂ ਏਆਈ ਆਉਟਪੁੱਟ ਕਿਸੇ ਵਿਅਕਤੀ ਦੀ ਅਗਲੀ ਕਾਰਵਾਈ ਨੂੰ ਬਦਲ ਦੇਵੇ: ਪਹੁੰਚ, ਲਾਗਤ, ਸੁਰੱਖਿਆ, ਇੱਜ਼ਤ ਜਾਂ ਸਮਾਂ।
जोਖਮ ਉੱਚੇ-ਪ੍ਰਭਾਵ ਵਾਲੇ ਖੇਤਰਾਂ ਵਿੱਚ ਵੱਧ ਹੁੰਦਾ ਹੈ, ਖ਼ਾਸ ਕਰਕੇ ਜਦੋਂ ਲੋਕ ਆਸਾਨੀ ਨਾਲ ਅਪੀਲ ਨਹੀਂ ਕਰ ਸਕਦੇ: ਪਹਚਾਣੀ ਪ੍ਰਣਾਲੀ (ਚਿਹਰਾ ਜਾਂ ਆਵਾਜ਼ ਵੇਰੀਫਿਕੇਸ਼ਨ), ਹਾਇਰਿੰਗ ਅਤੇ ਵਰਕਪਲੇਸ ਟੂਲ, ਲੈਂਡਿੰਗ ਅਤੇ ਬੀਮਾ ਫੈਸਲੇ, ਹੈਲਥਕੇਅਰ ਅਤੇ ਸਮਾਜਿਕ ਸੇਵਾਵਾਂ ਟ੍ਰਾਇਜ, ਅਤੇ ਸਿੱਖਿਆ ਜਾਂ ਰਿਹਾਇਸ਼ ਸਕ੍ਰੀਨਿੰਗ।
ਇਹ ਉਨ੍ਹਾਂ ਮਾਮਲਿਆਂ ਵਿੱਚ ਵੀ ਵੱਧਦਾ ਹੈ ਜਦੋਂ ਮਾਡਲ ਦਾ ਆਉਟਪੁੱਟ ਕਾਰਵਾਈ ਨੂੰ ਟ੍ਰਿਗਰ ਕਰਦਾ ਹੈ ਜਿਵੇਂ ਕਿ ਇਨਕਾਰ/ਮਨਜ਼ੂਰੀ, ਫਲੈਗਿੰਗ/ਹਟਾਉਣਾ, ਰੈਂਕਿੰਗ/ਸਿਫ਼ਾਰਸ਼ਾਂ, ਕੀਮਤ/ਲਿਮਿਟ, ਜਾਂ “ਰਿਸਕ” ਜਾਂ “ਟਾਕਸੀਸਿਟੀ” ਵਰਗੇ ਲੇਬਲ।
ਟੈਸਟ ਕਰਨ ਲਈ ਸੌਖਾ ਤਰੀਕਾ ਇਹ ਹੈ ਕਿ ਯੂਜ਼ਰ ਜਰਨੀ ਦਾ ਮੈਪ ਬਣਾਈਐ ਅਤੇ ਉਹ ਮੋੜ ਨਿਸ਼ਾਨ ਲਗਾਈਐ ਜਿੱਥੇ ਗਲਤ ਅਨੁਮਾਨ ਕਿਸੇ ਲਈ ਡੈੱਡ-ਐਂਡ ਬਣ ਜਾਂਦਾ ਹੈ। ਇੱਕ ਬੁਰੀ ਸਿਫਾਰਸ਼ ਨਿਰਾਸ਼ਕਰ ਹੈ; ਇੱਕ ਝੂਠਾ ਧੋਖਾਧੜੀ ਫਲੈਗ ਜੋ ਸ਼ੁੱਕਰਵਾਰ ਰਾਤ ਨੂੰ ਤਨਖਾਹ ਟਰਾਂਸਫਰ ਲਾਕ ਕਰ ਦੇਵੇ, ਇੱਕ ਸੰਕਟ ਹੈ।
ਉਹ “ਛੁਪੇ ਯੂਜ਼ਰਾਂ” ਵੱਲ ਵੀ ਧਿਆਨ ਦਿਓ ਜੋ ਸੰਦਰਭ ਬਿਨਾਂ ਮਾਡਲ ਆਉਟਪੁੱਟ 'ਤੇ ਕਾਰਵਾਈ ਕਰਦੇ ਹਨ: ਕਸਟਮਰ ਸਪੋਰਟ ਇੱਕ ਆਊਟਰਨੇਟ ਰਿਸਕ ਸਕੋਰ 'ਤੇ ਭਰੋਸਾ ਕਰਨਾ, ਓਪਸ ਟੀਮਾਂ ਟਿਕਟ ਆਟੋ-ਕਲੋਜ਼ ਕਰਨਾ, ਜਾਂ ਭਾਗੀਦਾਰ ਸਿਰਫ ਇੱਕ ਲੇਬਲ “ਸ਼ੱਕੀ” ਦੇਖ ਕੇ ਇਸਨੂੰ ਸਚ ਮੰਨ ਲੈਂਦੇ ਹਨ। ਇਹ ਅਪਰੋਕਸ਼ ਰਸਤੇ ਉਹ ਥਾਂ ਹਨ ਜਿੱਥੇ ਪੱਖਪਾਤ ਸਭ ਤੋਂ ਦੂਰ ਤੱਕ ਯਾਤਰਾ ਕਰ ਸਕਦਾ ਹੈ, ਕਿਉਂਕਿ ਪ੍ਰਭਾਵਿਤ ਵਿਅਕਤੀ ਨੂੰ ਸ਼ਾਇਦ ਪਤਾ ਹੀ ਨਾ ਲੱਗੇ ਕਿ ਕੀ ਹੋਇਆ ਜਾਂ ਕਿਵੇਂ ਠੀਕ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ।
ਐਕਯੂਰਸੀ ਜਾਂ ਨਿਆਂ ਸਕੋਰਾਂ 'ਤੇ ਬਹਿਸ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ, ਇਹ ਫੈਸਲਾ ਕਰੋ ਕਿ ਅਸਲ ਲੋਕਾਂ ਲਈ “ਖਰਾਬ” ਕੀ ਦਿਸਦਾ ਹੈ। ਇੱਕ ਸਧਾਰਨ ਜੋਖਮ-ਫਰੇਮਿੰਗ ਟੀਮ ਨੂੰ ਉਹ ਨੰਬਰਾਂ ਪਿੱਛੇ ਲੁਕਣ ਤੋਂ ਰੋਕਦੀ ਹੈ ਜੋ ਵਿਗਿਆਨਕ ਮਹਿਸੂਸ ਹੁੰਦੇ ਹਨ ਪਰ ਮਕਸਦ ਨੂੰ ਨਹੀਂ ਸਮਝਦੇ।
ਸ਼ੁਰੂਆਤ ਕਰੋ ਕੁਝ ਉਹ ਯੂਜ਼ਰ ਗਰੁੱਪ ਨਾਂਮ ਕਰਕੇ ਜੋ ਤੁਹਾਡੇ ਉਤਪਾਦ ਵਿੱਚ ਵਾਕਈ ਮੌਜੂਦ ਹਨ। “ਰੇਸ” ਜਾਂ “ਲਿੰਗ” ਵਰਗੇ ਜਨਰਿਕ ਲੇਬਲ ਮਾਇਨੇ ਰੱਖ ਸਕਦੇ ਹਨ, ਪਰ ਅਕੇਲੇ ਕਾਫ਼ੀ ਨਹੀਂ ਹੁੰਦੇ। ਜੇ ਤੁਸੀਂ ਇੱਕ hiring ਟੂਲ ਚਲਾ ਰਹੇ ਹੋ, ਤਾਂ ਗਰੁੱਪ ਹੋ ਸਕਦੇ ਹਨ: “ਕੈਰੀਅਰ ਚੇਂਜਰ,” “ਗੈਰ-ਮੂਲ ਭਾਸ਼ੀ ਵਿਚਾਲੇ,” ਅਤੇ “ਰੋਜ਼ਗਾਰ ਵਿੱਚ ਗੈਪ ਵਾਲੇ ਲੋਕ।” 3 ਤੋਂ 5 ਚੁਣੋ ਜੋ ਤੁਸੀਂ ਸਧਾਰਨ ਭਾਸ਼ਾ ਵਿੱਚ ਵੇਰਵਾ ਕਰ ਸਕੋ।
ਅੱਗੇ, ਨੁਕਸਾਨ ਬਿਆਨਾਂ ਨੂੰ ਛੋਟੇ, ਠੋਸ ਵਾਕਾਂ ਵਿੱਚ ਲਿਖੋ: ਕੌਣ ਨੁਕਸਾਨ ਪਾਂਵੇਗਾ, ਕਿਵੇਂ, ਅਤੇ ਕਿਉਂ ਇਹ ਮਾਮਲਾ ਹੈ। ਉਦਾਹਰਨ: “ਗੈਰ-ਮੂਲ ਭਾਸ਼ੀ ਬੋਲਣ ਵਾਲੇ ਘੱਟ ਗੁਣਵੱਤਾ ਵਾਲੇ ਸੁਝਾਵ ਪ੍ਰਾਪਤ ਕਰਦੇ ਹਨ, ਇਸ ਕਰਕੇ ਉਹ ਧੀਰੇ-ਧੀਰੇ ਭੇਜਦੇ ਹਨ ਅਤੇ ਆਤਮ-ਵਿਸ਼ਵਾਸ ਘਟਦਾ ਹੈ।” ਇਹ ਬਿਆਨ ਤੁਹਾਨੂੰ ਦੱਸਦੇ ਹਨ ਕਿ ਤੁਹਾਨੂੰ ਕੀ ਚੈੱਕ ਕਰਨਾ ਲਾਜ਼ਮੀ ਹੈ।
ਫਿਰ ਉਪਭੋਗਤਾ ਸ਼ਬਦਾਂ ਵਿੱਚ ਕਾਮਯਾਬੀ ਅਤੇ ਅਸਫਲਤਾ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ। ਸਿਸਟਮ ਕਿਹੜੇ ਫੈਸਲੇ 'ਤੇ ਪ੍ਰਭਾਵ ਪਾਂਦਾ ਹੈ ਅਤੇ ਗਲਤ ਹੋਣ ਦਾ ਕੀ ਖ਼ਰਚ ਹੈ? ਹਰ ਗਰੁੱਪ ਲਈ ਚੰਗਾ ਨਤੀਜਾ ਕਿਵੇਂ ਦਿਸਦਾ ਹੈ? ਕਿਹੜੀਆਂ ਗਲਤੀਆਂ ਪੈਸਾ, ਪਹੁੰਚ, ਸੁਰੱਖਿਆ, ਇੱਜ਼ਤ, ਜਾਂ ਭਰੋਸਾ ਨੁਕਸਾਨ ਕਰਦੀਆਂ? ਅਖੀਰ ਵਿੱਚ, ਨਿਰਧਾਰਤ ਕਰੋ ਕਿ ਤੁਸੀਂ ਕੀ ਨਹੀਂ ਕਰੋਗੇ, ਅਤੇ ਇਸਨੂੰ ਲਿਖੋ। ਸੀਮਾ ਦਰਸਾਉਣਾ जवाबਦਾਰ ਹੋ ਸਕਦਾ ਹੈ ਜੇ ਇਹ ਖੁੱਲ੍ਹਾ ਹੋਵੇ, ਜਿਵੇਂ “ਅਸੀਂ ਇਹ ਫੀਚਰ ਪਹਚਾਣ ਲਈ ਵਰਤਾਂਗੇ ਨਹੀਂ,” ਜਾਂ “ਆਉਟਪੁੱਟ ਸਿਰਫ ਸੁਝਾਵ ਹਨ, ਅੰਤਮ ਫੈਸਲੇ ਨਹੀਂ।”
ਆਰੰਭੀ ਟੀਮਾਂ ਨੂੰ ਭਾਰੀ ਪ੍ਰਕਿਰਿਆ ਦੀ ਲੋੜ ਨਹੀਂ। ਉਹਨਾਂ ਨੂੰ ਇੱਕ ਛੋਟੀ ਰੁਟੀਨ ਦੀ ਲੋੜ ਹੈ ਜੋ ਬਣਾਣ ਤੋਂ ਪਹਿਲਾਂ ਅਤੇ ਰਿਲੀਜ਼ ਤੋਂ ਪਹਿਲਾਂ ਹੋਵੇ। ਤੁਸੀਂ ਇਹ ਕਰੀਬ ਇਕ ਘੰਟੇ ਵਿੱਚ ਚਲਾ ਸਕਦੇ ਹੋ, ਫਿਰ ਮਾਡਲ, ਡੇਟਾ ਜਾਂ UI ਮੂਢਲ ਹੋਣ 'ਤੇ ਦੁਹਰਾਓ।
ਇੱਕ ਵਾਕ ਬਣਾਓ: ਇਸ ਕੇਸ ਦੀ ਵਰਤੋਂ ਕੀ ਹੈ, ਅਤੇ ਮਾਡਲ ਕਿਹੜੇ ਫੈਸਲੇ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਦਾ ਹੈ (ਪਹੁੰਚ ਰੋਕਣਾ, ਲੋਕਾਂ ਨੂੰ ਦਰਜਾ ਦੇਣਾ, ਸਮੱਗਰੀ ਫਲੈਗ ਕਰਨਾ, ਸਹਾਇਤਾ ਰੂਟ ਕਰਨਾ, ਕਿਸੇ ਪੇਸ਼ਕਸ਼ ਦੀ ਕੀਮਤ ਨਿਰਧਾਰਿਤ ਕਰਨਾ)? ਫਿਰ ਪ੍ਰਭਾਵਿਤ ਲੋਕਾਂ ਦੀ ਸੂਚੀ ਬਣਾਓ, ਉਹ ਵੀ ਜੋ opt-in ਨਹੀਂ ਹੋਏ।
ਦੋ ਦਿਨਾਂ ਦਾ ਪਟ੍ਰਾ ਲਵੋ: ਇਕ ਸਭ ਤੋਂ ਵਧੀਆ ਕੇਸ (ਮਾਡਲ ਮਦਦ ਕਰਦਾ ਹੈ) ਅਤੇ ਇਕ ਸਭ ਤੋਂ ਬੁਰਾ ਕੇਸ (ਮਾਡਲ ਪ੍ਰਣਾਲੀ ਢੰਗ ਨਾਲ ਫੇਲ ਹੋਵੇ)। ਜ਼ਿਆਦਾ ਵਿਸ਼ੇਸ਼ ਬਣੋ, ਜਿਵੇਂ “ਇੱਕ ਯੂਜ਼ਰ ਲੌਕ ਆਉਟ ਹੋ ਜਾਤਾ ਹੈ” ਜਾਂ “ਇੱਕ ਨੌਕਰੀ ਉਮੀਦਵਾਰ ਫਿਲਟਰ ਹੋ ਜਾਂਦਾ ਹੈ।”
ਉਹ ਮੁਲਾਂਕਣ ਸਲਾਈਸ ਚੁਣੋ ਜੋ ਹਕੀਕਤੀ ਹਾਲਾਤਾਂ ਨਾਲ ਮਿਲਦੀਆਂ ਹਨ: ਸਮੂਹ, ਭਾਸ਼ਾਵਾਂ, ਡਿਵਾਈਸ, ਰੋਸ਼ਨੀ, ਐਕਸੈਂਟ, ਉਮਰ ਦੀਆਂ ਰੇਂਜਾਂ ਅਤੇ ਐਕਸੈਸਿਬਿਲਟੀ ਜ਼ਰੂਰਤਾਂ। ਹਰ ਸਲਾਈਸ ਲਈ ਇੱਕ ਛੋਟਾ ਟੈਸਟ ਸੈੱਟ ਚਲਾਓ ਅਤੇ ਸਿਰਫ਼ ਐਕਯੂਰਸੀ ਨਹੀਂ, ਐਰਰ ਕਿਸਮਾਂ (false reject, false accept, ਗਲਤ ਲੇਬਲ, ਅਸੁਰੱਖਿਅਤ ਆਉਟਪੁੱਟ, ਅਤੀ-ਆਤਮ-ਵਿਸ਼ਵਾਸ ਟੋਨ) ਟ੍ਰੈਕ ਕਰੋ।
ਸਲਾਈਸਾਂ ਦੀ ਤੁਲਨਾ ਇਕ-ਦੂਜੇ ਦੇ ਨਾਲ ਕਰੋ। ਪੁੱਛੋ ਕਿ ਕਿਹੜੀ ਸਲਾਈਸ ਨੂੰ ਮਹੱਤਵਪੂਰਨ ਤੌਰ 'ਤੇ ਵੱਧ ਖਰਾਬ ਅਨੁਭਵ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਇਹ ਉਤਪਾਦ ਵਿੱਚ ਕਿਵੇਂ ਦਿਖਾਈ ਦੇਵੇਗਾ।
ਰਿਲੀਜ਼ ਗੇਟ ਉਤਪਾਦ ਨਿਯਮਾਂ ਵਜੋਂ ਸੈੱਟ ਕਰੋ। ਉਦਾਹਰਨ: “ਕੋਈ ਵੀ ਸਲਾਈਸ ਕੁੱਲ ਐਰਰ ਰੇਟ ਨਾਲੋਂ X ਤੋਂ ਵੱਧ ਨਹੀਂ ਹੋਵੇਗੀ,” ਜਾਂ “ਉੱਚ-ਪ੍ਰਭਾਵ ਐਰਰ Y ਤੋਂ ਥੱਲੇ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ।” ਨਾਲ ਹੀ ਇਹ ਫ਼ੈਸਲਾ ਕਰੋ ਕਿ ਜੇ ਤੁਸੀਂ ਇਹ ਨਿਯਮ ਪੂਰੇ ਨਹੀਂ ਕਰਦੇ ਤਾਂ ਕੀ ਕਰੋਗੇ: ਰਿਲੀਜ਼ ਰੋਕੋ, ਫੀਚਰ ਸੀਮਤ ਕਰੋ, ਮਨੁੱਖੀ ਸਮੀਖਿਆ ਲਾਜ਼ਮੀ ਕਰੋ, ਜਾਂ ਘੱਟ ਦਰਸ਼ਕਾਂ ਲਈ ਸ਼ਿਪ ਕਰੋ।
ਉੱਚ-ਪ੍ਰਭਾਵ ਵਾਲੀਆਂ ਗਲਤੀਆਂ ਲਈ, “ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ ਕਰੋ” ਅਕਸਰ ਕਾਫ਼ੀ ਨਹੀਂ ਹੁੰਦਾ। ਫਾਲਬੈਕ ਨਿਰਧਾਰਤ ਕਰੋ: ਇੱਕ ਸੁਰੱਖਿਅਤ ਡਿਫ਼ੋਲਟ, ਮਨੁੱਖੀ ਸਮੀਖਿਆ ਨਸ਼ਤਾ, ਅਪੀਲ, ਜਾਂ ਇੱਕ ਵਿਕਲਪਕ ਵੇਰੀਫਿਕੇਸ਼ਨ ਤਰੀਕਾ।
ਫਿਰ ਟੀਮ ਲਈ ਇੱਕ-ਪੰਨਾ “ਮਾਡਲ ਯੂਜ਼ ਨੋਟ” ਲਿਖੋ: ਇਹ ਫੀਚਰ ਕਿਸ ਲਈ ਵਰਤਣਾ ਨਹੀਂ ਚਾਹੀਦਾ, ਜਾਣੇ-ਪਛਾਣੇ ਕਮਜ਼ੋਰ ਪੇਂਡੂ, ਰਿਲੀਜ਼ ਤੋਂ ਬਾਅਦ ਕੀ ਮਾਨਟਰ ਕਰਨਾ ਹੈ, ਅਤੇ ਜਦੋਂ ਕੁਝ ਗਲਤ ਲੱਗੇ ਤਾਂ ਕੌਣ ਪੇਜ ਕੀਤਾ ਜਾਵੇ। ਇਹ ਜੋਖਮ ਨੂੰ ਇੱਕ ਛੁਪੇ ML ਵਿਸ਼ੇ ਤੋਂ ਬਚਾਉਂਦਾ ਹੈ।
ਇੱਕ bias ਟੈਸਟ ਸੈੱਟ ਵੱਡਾ ਹੋਣ ਦੀ ਲੋੜ ਨਹੀਂ ਕਿ ਉਹ ਲਾਭਕਾਰੀ ਹੋਵੇ। ਆਰੰਭਿਕ ਟੀਮ ਲਈ 50 ਤੋਂ 200 ਉਦਾਹਰਨ ਅਕਸਰ ਕਾਫ਼ੀ ਹੁੰਦੀਆਂ ਹਨ ਜੋ ਮਹੱਤਵਪੂਰਨ ਫੇਲੀਆਂ ਨੂੰ ਸਾਹਮਣੇ ਲਿਆ ਸਕਦੀਆਂ ਹਨ।
ਅਸਲ ਉਤਪਾਦ ਇਰਾਦੇ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ, ਨਾ ਕਿ ਉਹ ਜੋ ਇਕੱਠਾ ਕਰਨ ਲਈ ਆਸਾਨ ਹੈ। ਜੇ ਫੀਚਰ ਮਨਜ਼ੂਰੀਆਂ, ਰੱਦ, ਰੈਂਕਿੰਗ, ਜਾਂ ਫਲੈਗਿੰਗ 'ਤੇ ਪ੍ਰਭਾਵ ਪਾਂਦਾ ਹੈ, ਤਾਂ ਤੁਹਾਡਾ ਟੈਸਟ ਸੈੱਟ ਉਹ ਫੈਸਲੇ ਜੋ ਤੁਹਾਡਾ ਉਤਪਾਦ ਵਾਸਤਵ ਵਿੱਚ ਲਵੇਗਾ, ਉਹਨਾਂ ਵਰਗਾ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਝਲਕੇ ਹੋਏ ਐਜ ਕੇਸ ਸਮੇਤ।
ਸੈੱਟ ਬਣਾਉਣ ਲਈ ਕੁਝ ਇਰਾਦੀ ਕਦਮ ਕਰੋ: ਆਪਣੇ ਸਿੱਖੇ ਉਪਭੋਗਤਕ ਕਿਰਿਆਵਾਂ ਅਤੇ ਉੱਚ-ਗਲਤੀ ਮੋਡ ਕਵਰ ਕਰੋ, ਐਡਜ ਕੇਸ ਸ਼ਾਮਲ ਕਰੋ (ਛੋਟੇ ਇਨਪੁਟ, ਮਿਲੀ-ਭਾਸ਼ਾ, ਘੱਟ-ਰੋਸ਼ਨੀ ਤਸਵੀਰਾਂ, ਐਕਸੈਸਿਬਿਲਟੀ-ਸੰਬੰਧੀ ਇਨਪੁੱਟ), ਤੇ ਨੇੜਲੇ-ਮਿਸ ਉਦਾਹਰਨ ਜੋ ਇੱਕੋ ਜਿਹੇ ਦਿਖਦੇ ਪਰ ਵੱਖ ਨਤੀਜੇ ਦਏ ਜਾਣ। ਸੰਭਵ ਹੋਵੇ ਤਾਂ ਸਹਿਮਤ ਡੇਟਾ ਵਰਤੋ; ਜੇ ਨਹੀਂ ਹੈ ਤਾਂ ਸਟੇਜਡ ਜਾਂ ਸਿੰਥੇਟਿਕ ਉਦਾਹਰਨ ਵਰਤੋ। ਚਿਹਰੇ, ਸਿਹਤ, ਬੱਚਿਆਂ ਜਾਂ ਵਿੱਤ ਸੰਬੰਧੀ ਸੰਵੇਦਨਸ਼ੀਲ ਡੇਟਾ ਨੂੰ ਬੇਚੈਨੀ ਨਾਲ ਸਕ੍ਰੈਪ ਨਾ ਕਰੋ।
ਸੈੱਟ ਨੂੰ ਫ੍ਰੀਜ਼ ਕਰੋ ਅਤੇ ਇਸਨੂੰ ਉਤਪਾਦ ਆਰਟੀਫੈਕਟ ਵਾਂਗ ਰੱਖੋ: ਵਰਜ਼ਨ ਕਰੋ, ਅਤੇ ਬਦਲਾਅ ਕੇਵਲ ਉਸ ਨੋਟ ਨਾਲ ਕਰੋ ਜੋ ਕਿਉਂ ਹੈ।
ਲੇਬਲ ਕਰਦੇ ਸਮੇਂ ਨਿਯਮ ਸਧਾਰਨ ਰੱਖੋ। ਹਰ ਉਦਾਹਰਨ ਲਈ ਉਮੀਦ ਕੀਤੀ ਆਉਟਪੁੱਟ, ਕਿਉਂ ਉਹ ਉਮੀਦ ਕੀਤੀ ਜਾਂਦੀ ਹੈ, ਅਤੇ ਕਿਹੜੀ ਗਲਤੀ ਬੁਰੀ ਮੰਨੀ ਜਾਏਗੀ, ਇਹ ਲਿਖੋ। ਫਿਰ ਸਲਾਈਸ ਅਤੇ ਐਰਰ ਕਿਸਮ ਅਨੁਸਾਰ ਪ੍ਰਦਰਸ਼ਨ ਦੀ ਤੁਲਨਾ ਕਰੋ। ਸਿਰਫ਼ ਐਕਯੂਰਸੀ ਹੀ ਇੱਕ ਨਿਰਾਸ਼ਕਰ ਚੀਜ਼ ਹੈ ਕਿਉਂਕਿ ਇਹ ਇੱਕ ਨਿਰਪੇਖ ਗਲਤੀ ਅਤੇ ਨੁਕਸਾਨ ਵਾਲੀ ਗਲਤੀ ਵਿਚ ਫਰਕ ਨੂੰ ਛੁਪਾ ਸਕਦਾ ਹੈ।
ਪੱਖਪਾਤ ਟੈਸਟਿੰਗ ਆਮ ਤੌਰ 'ਤੇ ਸਰਲ ਕਾਰਨਾਂ ਕਰਕੇ ਫੇਲ ਹੁੰਦੀ ਹੈ, ਨਾਂ ਕਿ ਮੰਦੀ ਇਰਾਦੇ ਕਰਕੇ।
ਇੱਕ ਆਮ ਗਲਤੀ ਓਵਰਆਲ ਐਕਯੂਰਸੀ ਦੀ ਮਾਪ ਕਰਨ ਦੀ ਹੈ ਅਤੇ ਇਸਨੂੰ “ਕਾਫ਼ੀ ਚੰਗਾ” ਕਹਿ ਦੇਣੀ। 95% ਡੈਸ਼ਬੋਰਡ ਨੰਬਰ ਇੱਕ ਛੋਟੇ ਗਰੁੱਪ ਲਈ 20-ਪਾਇੰਟ ਗੈਪ ਨੂੰ ਛੁਪਾ ਸਕਦਾ ਹੈ।
ਹੋਰ ਜਾਲ ਇਹ ਹੈ ਕਿ ਉਹ ਡੈਮੋਗਰਾਫਿਕ ਲੇਬਲ ਵਰਤਦੇ ਹਨ ਜੋ ਉਤਪਾਦ ਹਕੀਕਤ ਨਾਲ ਮੇਲ ਨਹੀਂ ਖਾਂਦੇ। ਜੇ ਤੁਹਾਡੀ ਐਪ ਨ ਕਿਸੇ ਤੋਂ ਨਸਲ ਜਾਂ ਲਿੰਗ ਨਹੀਂ ਪੁੱਛਦੀ, ਤਾਂ ਤੁਸੀਂ ਲੋਕਲ ਡੇਟਾਸੈੱਟ ਤੋਂ ਐਸੇ ਲੇਬਲ ਲੈ ਕੇ ਟੈਸਟ ਕਰ ਸਕਦੇ ਹੋ ਜੋ ਤੁਹਾਡੇ ਯੂਜ਼ਰਾਂ ਦੀ ਸਵੈ-ਪਛਾਣ ਜਾਂ ਕੰਮ ਲਈ ਮਾਇਨੇ ਨਹੀਂ ਰੱਖਦੇ।
ਟੀਮਾਂ intersectional ਅਤੇ ਪ੍ਰਸੰਗਿਕ ਕੇਸਾਂ ਨੂੰ ਵੀ ਅਣਦੇਖਾ ਕਰਦੀਆਂ ਹਨ। ਅਸਲ ਫੇਲ ਆਮ ਤੌਰ 'ਤੇ ਸੰਗਮਾਂ ਵਿੱਚ ਆਉਂਦੀਆਂ ਹਨ: ਉਜਲੇ ਚਮੜੀ ਰੰਗ ਵਾਲੇ ਨਾਲੋਂ ਘੱਟ ਰੋਸ਼ਨੀ, ਐਕਸੈਂਟ ਅਤੇ ਪਿੱਛੋਕੜ ਸ਼ੋਰ, ਮਾਚਕ ਵਾਲਾ ਯੂਜ਼ਰ, ਜਾਂ ਕੈਮਰੇ ਵਿਖੇ ਵੱਖਰੇ ਫ੍ਰੇਮ।
ਜਦੋਂ ਟੀਮਾਂ ਇਹ ਸਮੱਸਿਆਵਾਂ ਠੀਕ ਕਰਦੀਆਂ ਹਨ, ਤਬ ਬਦਲਾਅ ਆਮ ਤੌਰ 'ਤੇ ਸਿਦਾ-ਸਾਦਾ ਹੁੰਦੇ ਹਨ: ਉਹ ਸਲਾਈਸਾਂ ਦੇ ਅਨੁਸਾਰ ਨਤੀਜੇ ਤੋੜਦੇ ਹਨ ਜੋ ਤੁਸੀਂ ਨੁਕਸਾਨ ਪਹੁੰਚਾ ਸਕਦੇ ਹੋ, ਆਪਣੇ ਉਤਪਾਦ ਅਤੇ ਖੇਤਰ ਅਧਾਰਿਤ ਸ਼੍ਰੇਣੀਆਂ ਪਰਿਭਾਸ਼ਿਤ ਕਰਦੇ ਹਨ, ਹਰ ਟੈਸਟ ਸੈੱਟ ਵਿੱਚ “ਹਾਰਡ ਮੋਡ” ਕੇਸ ਸ਼ਾਮਲ ਕਰਦੇ ਹਨ, ਫਾਲਬੈਕ ਬਿਨਾਂ ਨਹੀਂ ਸ਼ਿਪ ਕਰਦੇ, ਅਤੇ ਤੀਜੀ-ਪੱਖੀ AI ਨੂੰ ਕਿਸੇ ਵੀ ਹੋਰ ਡਿਪੈਂਡੰਸੀ ਵਾਂਗ ਆਪਣੀਆਂ ਜਾਂਚਾਂ ਚਲਾਉਂਦੇ ਹਨ।
ਬਿਲਕੁਲ ਰਿਲੀਜ਼ ਤੋਂ ਥੋੜਾ ਸਮਾਂ ਪਹਿਲਾਂ, ਆਖਰੀ ਸਮੀਖਿਆ ਨੂੰ ਥੋੜ੍ਹਾ ਜ਼ਿਆਦਾ ਦਰੁਸਤ ਬਣਾਓ। ਲਕਸ਼ਯ ਪਰਫੈਕਟ ਨਿਆਂ ਨਹੀਂ; ਇਹ ਇਹ ਜਾਣਨਾ ਹੈ ਕਿ ਤੁਹਾਡੀ ਸਿਸਟਮ ਕੀ ਕਰ ਸਕਦੀ ਹੈ, ਕਿੱਥੇ ਫੇਲ ਹੁੰਦੀ ਹੈ, ਅਤੇ ਜਦੋਂ ਫੇਲ ਹੋਏ ਤਾਂ ਲੋਕਾਂ ਦੀ ਕਿਵੇਂ ਰੱਖਿਆ ਕੀਤੀ ਜਾਂਦੀ ਹੈ।
ਇਕੋ ਥਾਂ ਤੇ ਪੰਜ ਪ੍ਰਸ਼ਨ ਰੱਖੋ:
ਇੱਕ ਤੇਜ਼ ਦਰਸ਼ਾਵਾ ਟੀਮਾਂ ਨੂੰ ਇਮਾਨਦਾਰ ਰੱਖਣ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ: ਜੇ ਚਿਹਰਾ ਵੈਰੀਫਿਕੇਸ਼ਨ ਇੱਕੋ ਚਮੜੀ ਰੰਗ ਲਈ ਵੱਧ ਫੇਲ ਕਰਦੀ ਹੈ, ਤਾਂ “retry” ਕਾਫ਼ੀ ਨਹੀਂ। ਤੁਹਾਨੂੰ ਇੱਕ ਵਿਕਲਪਿਕ ਰਸਤਾ (ਮੈਨੂਅਲ ਸਮੀਖਿਆ ਜਾਂ ਵੱਖਰੀ ਵੇਰੀਫਿਕੇਸ਼ਨ) ਅਤੇ ਇਹ ਮਾਪਣ ਦਾ ਤਰੀਕਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਕਿਆ ਫਾਲਬੈਕ ਵੱਖ-ਵੱਖ ਤਰ੍ਹਾਂ ਵਰਤਿਆ ਜਾ ਰਿਹਾ ਹੈ।
ਇੱਕ ਛੋਟੀ ਟੀਮ ਇੱਕ ਕਮਿਊਨਿਟੀ ਐਪ ਬਣਾਈ ਰਹੀ ਹੈ ਜਿਸ ਵਿੱਚ ਦੋ ਏਆਈ ਫੀਚਰ ਹਨ: ਅਕਾਊਂਟ ਰਿਕਵਰੀ ਲਈ ਫੇਸ ਵੈਰੀਫਿਕੇਸ਼ਨ ਅਤੇ ਟਿੱਪਣੀਆਂ ਲਈ ਆਟੋਮੇਟਡ ਮੋਡਰੇਸ਼ਨ। ਉਹ ਤੇਜ਼ੀ ਨਾਲ ਅੱਗੇ ਵੱਧ ਰਹੇ ਹਨ, ਇਸ ਲਈ ਪਹਿਲੀ ਪਬਲਿਕ ਰਿਲੀਜ਼ ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ ਹਲਕੀ ਸਮੀਖਿਆ ਚਲਾਉਂਦੇ ਹਨ।
ਉਹ ਸਾਫ਼ ਭਾਸ਼ਾ ਵਿੱਚ ਲਿਖਦੇ ਹਨ ਕਿ ਕੀ ਗਲਤ ਹੋ ਸਕਦਾ ਹੈ। ਫੇਸ ਵੈਰੀਫਿਕੇਸ਼ਨ ਲਈ ਨੁਕਸਾਨ ਇਹ ਹੈ ਕਿ ਇੱਕ ਫਾਲਸ ਰਿਜੈਕਟ ਕਿਸੇ ਨੂੰ ਲੌਕ ਆਉਟ ਕਰ ਦੇਵੇ। ਮੋਡਰੇਸ਼ਨ ਲਈ ਨੁਕਸਾਨ ਇਹ ਹੈ ਕਿ ਹਰਜਨਕ ਬਾਤਾਂ ਨੂੰ ਫਲੈਗ ਕਰਕੇ ਛੁਪਾ ਦਿੱਤਾ ਜਾਵੇ ਜਾਂ ਕਿਸੇ ਉਪਭੋਗਤਾ ਨੂੰ ਨਿਆਂ ਬਿਨਾਂ ਚੇਤਾਵਨੀ ਦਿੱਤੀ ਜਾਵੇ।
ਉਹ ਫੈਸਲੇ ਪਰਿਭਾਸ਼ਿਤ ਕਰਦੇ ਹਨ (“ਇਜਾਜ਼ਤ ਦੇਵੋ ਬਨਾਮ ਫੇਸ ਮਿਲਾਣ ਨੂੰ ਰੱਦ ਕਰੋ” ਅਤੇ “ਟਿੱਪਣੀ ਦਿਖਾਓ ਬਨਾਮ ਲੁਕਾਓ”), ਉਹ ਸਲਾਈਸ ਚੁਣਦੇ ਹਨ ਜਿਨ੍ਹਾਂ ਨੂੰ ਉਹ ਬਰਾਬਰ ਸਲੂਕ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹਨ (ਚਮੜੀ ਦੇ ਰੰਗ, ਲਿੰਗ, ਉਮਰ ਦੀਆਂ ਰੇਂਜ; ਬੋਲੀਆਂ ਅਤੇ ਪ੍ਰਸੰਗਿਕ ਸ਼ਬਦ), ਇੱਕ ਛੋਟਾ ਟੈਸਟ ਸੈੱਟ ਬਣਾਉਂਦੇ ਹਨ ਜਿਸ ਵਿੱਚ ਐਡਜ ਕੇਸਾਂ ਤੇ ਟੀਪਣੀਆਂ ਹਨ, ਅਤੇ ਹਰ ਸਲਾਈਸ ਅਨੁਸਾਰ false rejects ਅਤੇ false flags ਦਾ ਰਿਕਾਰਡ ਰੱਖਦੇ ਹਨ। ਉਹ ਇਹ ਵੀ ਫੈਸਲਾ ਕਰਦੇ ਹਨ ਕਿ ਜਦੋਂ ਵਿਸ਼ਵਾਸ ਘੱਟ ਹੋਵੇ ਤਾਂ ਉਤਪਾਦ ਕੀ ਕਰੇਗਾ।
ਉਹ ਦੋ ਸਪਸ਼ਟ ਸਮੱਸਿਆਵਾਂ ਪਾਉਂਦੇ ਹਨ: ਫੇਸ ਵੈਰੀਫਿਕੇਸ਼ਨ ਨੀਚੇ ਰੋਸ਼ਨੀ ਵਿੱਚ ਖਾਸ ਕਰਕੇ ਗੂੜ੍ਹੇ ਚਮੜੀ ਟੋਨ ਵਾਲੇ ਯੂਜ਼ਰਾਂ ਨੂੰ ਵੱਧ ਰਿਜੈਕਟ ਕਰਦਾ ਹੈ, ਅਤੇ ਇੱਕ ਖਾਸ ਉਚਾਰਣ ਵਾਲੀ ਬੋਲੀ ਨੂੰ “ਅਗਰੈਸਿਵ” ਵਜੋਂ ਫਲੈਗ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਜਦੋਂ ਦੋਸਤਾਨਾ ਟੋਨ ਹੋਣ 'ਤੇ ਵੀ।
ਉਹਨਾਂ ਦੇ ਉਤਪਾਦਕ ਜਵਾਬ ਵਿਆਵਹਾਰਿਕ ਹੁੰਦੇ ਹਨ। ਫੇਸ ਵੈਰੀਫਿਕੇਸ਼ਨ ਲਈ, ਉਹ ਇਕ ਵਿਕਲਪਿਕ ਰਿਕਵਰੀ ਰਸਤਾ ਜੋੜਦੇ ਹਨ (ਮੈਨੂਅਲ ਸਮੀਖਿਆ ਜਾਂ ਹੋਰ ਤਰੀਕਾ) ਅਤੇ ਫੀਚਰ ਨੂੰ ਖਾਤਾ ਰਿਕਵਰੀ ਤੱਕ ਸੀਮਤ ਕਰ ਦਿੱਤਾ, ਨਿਯਮਤ ਲੌਗਇਨ ਚੈੱਕਾਂ ਲਈ ਨਹੀਂ। ਮੋਡਰੇਸ਼ਨ ਲਈ, ਉਹ ਵਰਤੋਂ ਮਾਮਲਾ ਸਖ਼ਤ ਕਰਦੇ ਹਨ ਤਾਂ ਕੇਵਲ ਉੱਚ-ਵਿਸ਼ਵਾਸ toxicity ਲੁਕਾਇਆ ਜਾਵੇ, ਇੱਕ ਅਪੀਲ ਰਸਤਾ ਜੋੜਦੇ ਹਨ, ਅਤੇ ਹਾਦ-ਹੱਦ ਵਾਲੇ ਕੇਸਾਂ ਲਈ ਹੌਲੀ-ਘਰੁੰਘੁਣ friction ਰੱਖਦੇ ਹਨ।
“ਹੁਣ ਲਈ ਕਾਫ਼ੀ” ਦਾ ਮਤਲਬ ਇਹ ਹੈ ਕਿ ਤੁਸੀਂ ਜਾਣ ਸਕਦੇ ਹੋ ਕਿ ਜਾਣੇ ਗਏ ਜੋਖਮ ਕੀ ਹਨ, ਤੁਹਾਡੇ ਕੋਲ ਇੱਕ ਸੁਰੱਖਿਅਤ ਫਾਲਬੈਕ ਹੈ, ਅਤੇ ਤੁਸੀਂ ਹਰ ਮਾਡਲ, ਪ੍ਰੰਪਟ ਜਾਂ ਡੇਟਾ ਬਦਲਾਅ ਤੋਂ ਬਾਅਦ ਸਲਾਈਸ-ਅਧਾਰਿਤ ਚੈੱਕ ਦੁਹਰਾਉਗੇ, ਖਾਸਕਰ ਜਦੋਂ ਤੁਸੀਂ ਨਵੇਂ ਦੇਸ਼ਾਂ ਅਤੇ ਭਾਸ਼ਾਵਾਂ ਵਿੱਚ ਵਧਦੇ ਹੋ।
ਪੱਖਪਾਤ ਅਤੇ ਜੋਖਮ ਜਾਂਚ ਸਿਰਫ਼ ਉਹੀ ਸਮੇਂ ਕੰਮ ਕਰਦੀਆਂ ਹਨ ਜਦੋਂ ਉਹ ਅਰੰਭ ਵਿੱਚ ਕੀਤੀਆਂ ਜਾਣ, ਓਸੇ ਤਰ੍ਹਾਂ ਜਿਵੇਂ ਪ੍ਰਦਰਸ਼ਨ ਅਤੇ ਸੁਰੱਖਿਆ ਕੀਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ। ਜੇ ਗੰਭੀਰ ਜੋਖਮ ਦੀ ਪਹਿਲੀ ਗੱਲ-ਬਾਤ ਫੀਚਰ “ਮੁਕੰਮਲ” ਹੋਣ ਤੋਂ ਬਾਅਦ ਹੁੰਦੀ ਹੈ, ਤਾਂ ਟੀਮਾਂ ਜਾਂ ਤਾਂ ਜਾਣ-ਬੂਝ ਕੇ ਖ਼ਾਮੀਆਂ ਦੇ ਨਾਲ ਛੱਡ ਦੇਂਦੀਆਂ ਹਨ ਜਾਂ ਸਮੀਖਿਆ ਛੱਡ ਦਿੰਦੇ ਹਨ।
ਆਪਣੀ ਕੈਡੈਂਸ ਵਿੱਚ ਇੱਕ ਨਿਰਧਾਰਤ ਸਮਾਂ ਚੁਣੋ: ਜਦੋਂ ਇੱਕ ਫੀਚਰ ਮਨਜ਼ੂਰ ਹੁੰਦਾ ਹੈ, ਜਦੋਂ ਮਾਡਲ ਬਦਲਾਅ ਪ੍ਰਸਤਾਵਿਤ ਹੁੰਦਾ ਹੈ, ਜਾਂ ਜਦੋਂ ਤੁਸੀਂ ਰਿਲੀਜ਼ ਕਾਟਦੇ ਹੋ। ਆਰਟੀਫੈਕਟ ਛੋਟੇ ਤੇ ਪੜ੍ਹਨ ਵਿੱਚ ਆਸਾਨ ਰੱਖੋ: ਇੱਕ-ਪੰਨਾ ਰਿਸਕ ਨੋਟ, ਕੀ ਟੈਸਟ ਕੀਤਾ (ਅਤੇ ਕੀ ਨਹੀਂ) ਜਿਸਦੀ ਇੱਕ ਛੋਟੀ ਸੰਖੇਪ ਅਤੇ ਇੱਕ ਛੋਟੀ ਰਿਲੀਜ਼ ਨਿਰਣਯ 기록।
ਮਲਕੀਅਤ ਸਪੱਸ਼ਟ ਕਰੋ। ਪ੍ਰੋਡਕਟ ਹਾਰਮ ਸੈਨਾਰਿਓਜ਼ ਅਤੇ ਉਪਯੋਗ-ਨਿਯਮਾਂ ਦਾ ਮਾਲਕ ਹੈ। ਇੰਜੀਨੀਅਰਿੰਗ ਟੈਸਟਾਂ ਅਤੇ ਰਿਲੀਜ਼ ਗੇਟਾਂ ਦਾ ਮਾਲਕ ਹੈ। ਸਪੋਰਟ ਐਸਕਲੇਸ਼ਨ ਪਾਥਾਂ ਅਤੇ ਉਹ ਸਿਗਨਲ ਜੋ ਸਮੀਖਿਆ ਨੂੰ ਟ੍ਰਿਗਰ ਕਰਦੇ ਹਨ, ਉਹਨਾਂ ਦਾ ਮਾਲਕ ਹੈ। ਜਦੋਂ ਰਿਸਕ ਨੋਟ ਕਿਸੇ ਬਿੰਦੂ ਨੂੰ ਉੱਠਾਉਂਦਾ ਹੈ ਤਾਂ ਲੀਗਲ ਜਾਂ ਕੰਪਲਾਇੰਸ ਨੂੰ ਸ਼ਾਮਿਲ ਕੀਤਾ ਜਾਂਦਾ ਹੈ।
ਜੇ ਤੁਸੀਂ Koder.ai (koder.ai) ਵਿੱਚ ਬਿੱਲਡ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ ਇੱਕ ਸਧਾਰਣ ਤਰੀਕਾ ਇਹ ਹੈ ਕਿ ਰਿਸਕ ਨੋਟ ਨੂੰ ਫੀਚਰ ਪਲਾਨ ਦੇ ਕੋਲ ਰਖੋ Planning Mode ਵਿੱਚ, ਅਤੇ ਜਦੋਂ ਤੁਸੀਂ ਪ੍ਰੰਪਟ, ਮਾਡਲ, ਜਾਂ ਥ੍ਰੈਸ਼ਹੋਲਡ ਬਦਲਦੇ ਹੋ ਤਾਂ snapshots ਅਤੇ rollback ਨਾਲ ਵਿਵਹਾਰ ਦੀ ਤੁਲਨਾ ਕਰੋ।
ਪੱਖਪਾਤ ਉਸਦਾ ਨਤੀਜਾ ਹੁੰਦੀ ਹੈ ਜੋ ਉਤਪਾਦ ਦੇ ਅਸਮਾਨ ਤਰੀਕੇ ਨਾਲ ਫੇਲ ਹੋਣ ਰੂਪ ਵਿੱਚ ਵਰਤੋਂਕਾਰਾਂ ਲਈ ਦਿਸਦੀ ਹੈ: ਇਕ ਗਰੁੱਪ ਲੌਗਿਨ ਤੋਂ ਬਾਹਰ ਰਹਿ ਜਾਂਦਾ ਹੈ, ਕੋਈ ਯੋਗ ਉਮੀਦਵਾਰ ਅਸਵੀਕਾਰ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਜਾਂ ਕਿਸੇ ਨੂੰ ਫਲੈਗ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਜਦੋਂ ਉਹ ਗਲਤ ਕਿਉਂਕਿ ਉਹਨੂੰ ਕੋਈ ਨੁਕਸਾਨ ਨਹੀਂ ਹੋਇਆ। ਔਸਤ ਦੁਰੁਸਤਤਾ ਅੱਛੀ ਦਿੱਸ ਸਕਦੀ ਹੈ, ਪਰ ਇੱਕ ਛੋਟੇ ਗਰੁੱਪ ਦੇ ਲਈ ਬਹੁਤ ਉੱਚੀ ਗਲਤੀ ਦਰ ਹੋ ਸਕਦੀ ਹੈ।
ਜੇ ਨਤੀਜੇ ਪੁੱਜਣ, ਪੈਸੇ, ਸੁਰੱਖਿਆ ਜਾਂ ਇੱਜ਼ਤ 'ਤੇ ਅਸਰ ਪਾਂਵਦੇ ਹਨ ਤਾਂ ਇਹ ਇਕ ਉਤਪਾਦ ਦੀ ਖਾਮੀ ਬਣ ਜਾਂਦਾ ਹੈ ਨਾ ਕਿ ਕੇਵਲ ਇਕ ਅ抽ਸਟ੍ਰැਕਟ ਨਿਆਪਸੰਦੀ ਗੱਲ।
ਕਿਉਂਕਿ ਹੁਣ ਸਟੇਕਹੋਲਡਰ ਪੁੱਛਦੇ ਹਨ “ਕੌਣ ਫੇਲ ਹੁੰਦਾ ਹੈ ਅਤੇ ਜਦੋਂ ਉਹ ਫੇਲ ਕਰਦਾ ਹੈ ਤਾਂ ਕੀ ਹੁੰਦਾ ਹੈ,” ਸਿਰਫ਼ “ਕੁੱਲ ਸਹੀਤਾ ਕੀ ਹੈ” ਪੁੱਛਣਾ ਕਾਫ਼ੀ ਨਹੀਂ। ਜਨਤਕ ਨਾਕਾਮੀਆਂ ਨੇ ਉਮੀਦਾਂ ਨੂੰ ਤੇਜ਼ ਕੀਤਾ: ਟੀਮਾਂ ਤੋਂ ਮੰਗ ਕੀਤੀ ਜਾਂਦੀ ਹੈ ਕਿ ਉਹ ਮੁੱਖ ਯੂਜ਼ਰ ਸਲਾਈਸਾਂ ਦੀ ਜਾਂਚ ਅਤੇ ਇੱਕ ਰਿਕਵਰੀ ਰਸਤਾ ਦਿਖਾਵਨ।
ਇਹ ਉਸੇ ਤਰ੍ਹਾਂ ਹੈ ਜਿਸ ਤਰ੍ਹਾਂ ਸੁਰੱਖਿਆ ਕਈ ਘਟਨਾਵਾਂ ਤੋਂ ਬਾਅਦ ਗੈਰ-ਵਿਕਲਪੀ ਬਣ ਗਈ।
ਇਸ ਨੇ ਦਿਖਾਇਆ ਕਿ ਇਕ ਸਿਰਫ਼ ਹੈੱਡਲਾਈਨ ਮੈਟ੍ਰਿਕ ਇਕ ਵੱਡੇ ਫ਼ਰਕ ਨੂੰ ਛੁਪਾ ਸਕਦੀ ਹੈ। ਸਿਸਟਮ ਕੁੱਲ ਮਿਲਾਕੇ ਚੰਗੀ ਦਰ 'ਤੇ ਕੰਮ ਕਰ ਸਕਦਾ ਹੈ ਜਦਕਿ ਦਾਖ਼ਲ ਹੋਣ ਵਾਲੀਆਂ ਥੋੜ੍ਹੀਆਂ ਗਰੁੱਪਾਂ ਲਈ ਨਤੀਜੇ ਬਹੁਤ ਖਰਾਬ ਹੋ ਸਕਦੇ ਹਨ, ਖਾਸਕਰ ਗੰਭੀਰ ਤੌਰ 'ਤੇ ਅੰਧੇਰੇ ਚਮੜੀ ਰੰਗ ਵਾਲੀਆਂ ਔਰਤਾਂ ਲਈ।
ਪ੍ਰਾਇਕਟਿਕਲ ਨਤੀਜਾ: ਹਮੇਸ਼ਾ ਨਤੀਜਿਆਂ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਸਲਾਈਸਾਂ ਅਨੁਸਾਰ ਵੰਡੋ, ਨਾ ਕਿ ਕੇਵਲ ਇੱਕ ਮਿਲੀ-ਜੁਲੀ ਸਕੋਰ 'ਤੇ ਭਰੋਸਾ ਕਰੋ।
ਇਸਨੂੰ ਕਿਸੇ ਹੋਰ ਲੋੜ ਵਾਲੀ ਸ਼ਿਪ ਗੇਟ ਵਾਂਗ ਲਓ: ਤੁਸੀਂ ਨਿਰਧਾਰਤ ਕਰੋ ਕਿ ਕੌਣ-ਕੌਣ ਗਰੁੱਪ ਪ੍ਰਭਾਵਿਤ ਹੋ ਸਕਦੇ ਹਨ, ਪ੍ਰਤੀਨਿਧੀ ਸਲਾਈਸਾਂ ਦੀ ਜਾਂਚ ਕਰੋ, “ਅਸਵੀਕਾਰਯੋਗ ਫੇਲ” ਨਿਯਮ ਬਣਾਓ ਅਤੇ ਉੱਚ-ਪ੍ਰਭਾਵ ਵਾਲੀਆਂ ਗਲਤੀਆਂ ਲਈ ਇਕ fallback ਜ਼ਰੂਰੀ ਘੋਸ਼ਿਤ ਕਰੋ।
ਇਸ ਵਿੱਚ ਸੀਮਾਵਾਂ ਨੂੰ ਦਸਤਾਵੇਜ਼ ਕਰਨਾ ਵੀ ਸ਼ਾਮਲ ਹੈ ਤਾਂ ਕਿ ਸਪੋਰਟ ਅਤੇ ਉਪਭੋਗਤਾ ਜਾਣ ਸਕਣ ਕਿ ਸਿਸਟਮ ਕੀ ਕਰ ਸਕਦਾ ਹੈ ਅਤੇ ਕੀ ਨਹੀਂ।
ਜਿੱਥੇ ਮਾਡਲ ਆਉਟਪੁਟ ਕਿਸੇ ਵਿਅਕਤੀ ਦੀ ਅਗਲੀ ਕਾਰਵਾਈ ਨੂੰ ਬਦਲ ਦਿੰਦੀ ਹੈ, ਉਥੇ ਵਾਸਤੀ ਨੁਕਸਾਨ ਵੱਧਦਾ ਹੈ:
ਜਦੋਂ ਸਧਾਰਨ ਅਪੀਲ ਦੀ ਗੱਲ ਨਹੀਂ ਹੁੰਦੀ ਤਾਂ ਜੋਖਮ ਸਭ ਤੋਂ ਵੱਧ ਹੁੰਦਾ ਹੈ।
3–5 ਗਰੁੱਪ ਚੁਣੋ ਜੋ ਤੁਹਾਡੇ ਉਤਪਾਦ ਸੰਦਰਭ ਵਿੱਚ ਅਸਲ ਵਿੱਚ ਮੌਜੂਦ ਹਨ ਅਤੇ ਸਧਾਰਨ ਭਾਸ਼ਾ ਵਿੱਚ ਵਰਣਨ ਕੀਤੇ ਜਾ ਸਕਣ। ਉਦਾਹਰਨ:
ਆਸਾਨ ਸ਼ਬਦਾਂ ਵਿੱਚ ਵਰਣਨ ਕਰੋ ਅਤੇ ਉਹ ਸ਼੍ਰੇਣੀਆਂ ਨਾਹ ਚੁਣੋ ਜੋ ਤੁਹਾਡੇ ਯੂਜ਼ਰ ਯਾਤਰਾ ਨੂੰ ਸਹੀ ਤਰ੍ਹਾਂ ਦਰਸਾਉਂਦੀਆਂ ਨਹੀਂ।
ਇੱਕ ਛੋਟੀ ਟੀਮ ਲਈ ਦੁਹਰਾਊ ਲੂਪ ਵਿੱਚ ਇਹ ਕਰੋ:
ਅਕਸਰ 50–200 ਉਦਾਹਰਨ ਕਾਫ਼ੀ ਹੁੰਦੀਆਂ ਹਨ ਤांकि ਉਹ ਆਰੰਭਿਕ ਸਮੱਸਿਆਵਾਂ ਨੂੰ surfaces ਕਰ ਸਕਣ।ਹਕੀਕਤ 'ਤੇ ਧਿਆਨ ਦਿਓ:
ਟੈਸਟ ਸੈੱਟ ਨੂੰ ਫ੍ਰੀਜ਼ ਕਰੋ, ਵਰਜ਼ਨਿੰਗ ਕਰੋ, ਅਤੇ ਬਦਲਣ 'ਤੇ ਬਤਾਵੇ ਕੀਤੇ ਬਿਨਾ ਬਦਲੋਂ ਨਾ। ਲੇਬਲਿੰਗ ਨਿਯਮ ਸਧਾਰਨ ਰੱਖੋ: ਉਮੀਦ ਕੀਤੀ ਆਉਟਪੁੱਟ, ਕਿਉਂ ਉਹ ਉਮੀਦ ਕੀਤੀ ਜਾਂਦੀ ਹੈ, ਅਤੇ ਕਿਸ ਗਲਤੀ ਨੂੰ ਸਭ ਤੋਂ ਬੁਰਾ ਮੰਨਿਆ ਜਾਵੇਗਾ।
ਆਮ ਗਲਤੀਆਂ:
ਮੁਕੰਮਲ ਹੱਲ ਆਮ ਤੌਰ 'ਤੇ ਸਧਾਰਨ ਹੁੰਦੇ ਹਨ: ਸਲਾਈਸ ਨਾਲ ਨਤੀਜੇ ਤੋੜੋ, ਹਾਰਡ ਮੋਡ ਕੇਸ ਜੋੜੋ, ਫਾਲਬੈਕ ਲਾਜ਼ਮੀ ਕਰੋ ਅਤੇ ਤੀਜੇ-ਪੱਖੀ ਸੂਤਰਾਂ ਲਈ ਆਪਣੀਆਂ ਜਾਂਚਾਂ ਚਲਾਓ।
ਆਪਣੇ ਵਰਕਫਲੋ ਵਿੱਚ ਇਸਨੂੰ ਆਸਾਨ ਰੱਖੋ:
ਜੇ ਤੁਸੀਂ Koder.ai (koder.ai) 'ਤੇ ਬਿੱਲਡ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ ਰਿਸਕ ਨੋਟ ਨੂੰ Planning Mode ਦੇ ਕੋਲ ਰੱਖਣਾ ਅਤੇ snapshots/rollback ਵਰਤਕੇ ਵਿਵਹਾਰ ਤੁਲਨਾ ਕਰਨਾ ਇੱਕ ਸਧਾਰਣ ਤਰੀਕਾ ਹੈ।