ਵਿਰੋਧੀ ਸੋਚ ਦੱਸਦੀ ਹੈ ਕਿ GANs ਕਿਵੇਂ ਕੰਮ ਕਰਦੇ ਹਨ: ਦੋ ਪ੍ਰਣਾਲੀਆਂ ਇਕ ਦੂਜੇ ਨੂੰ ਸੁਧਾਰਨ ਲਈ ਧੱਕ ਦੇਂਦੀਆਂ ਹਨ। ਜਾਣੋ ਕਿ ਇਸੇ ਲੂਪ ਨੂੰ ਟੈਸਟਿੰਗ, ਸੁਰੱਖਿਆ ਅਤੇ ਪ੍ਰਾਂਪਟ-ਵਿਰੁੱਧ-ਇਵੈਲ ਵਿੱਚ ਕਿਵੇਂ ਲਾਗੂ ਕਰਨਾ ਹੈ।
ਵਿਰੋਧੀ ਸੋਚ ਇਕ ਸਧਾਰਣ ਨਮੂਨਾ ਹੈ: ਤੁਸੀਂ ਇੱਕ ਪ੍ਰਣਾਲੀ ਬਣਾਉਂਦੇ ਹੋ ਜੋ ਕੁਝ ਤਿਆਰ ਕਰਦੀ ਹੈ, ਅਤੇ ਦੂਜੀ ਪ੍ਰਣਾਲੀ ਉਸਨੂੰ ਚੈਲੇਂਜ ਕਰਦੀ ਹੈ। ਉਤਪਾਦਕ ਬਿਹਤਰ ਨਤੀਜੇ ਦੇ ਕੇ ਜਿੱਤਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਹੈ। ਚੈਲੈਂਜਰ ਖ਼ਰਾਬੀਆਂ ਲੱਭ ਕੇ ਜਿੱਤਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਹੈ। ਇਸ ਲੂਪ ਨੂੰ ਦੁਹਰਾਉ — ਤੇ ਦੋਹਾਂ ਪਾਸੇ ਸੁਧਰਦੇ ਹਨ।
ਇਹ ਰੋਜ਼ਮਰ੍ਹਾ ਸਾਫਟਵੇਅਰ ਕੰਮ ਵਿੱਚ ਪਹਿਲਾਂ ਹੀ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ। ਇੱਕ ਫੀਚਰ ਰਿਲੀਜ਼ ਹੁੰਦੀ ਹੈ, ਫਿਰ ਟੈਸਟ ਉਹਨੂੰ ਤੋੜਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਹਨ। ਸੁਰੱਖਿਆ ਟੀਮ ਰਕਾਬਤ ਲਗਾਉਂਦੀ ਹੈ, ਫਿਰ ਹਮਲਾਵਰ ਜਾਂ ਰੈਡ ਟੀਮ ਖਾਮੀਆਂ ਲੱਭਦੀ ਹੈ। ਸਹਾਇਤਾ ਵਰਕਫ਼ਲੋ ਕਾਗਜ਼ 'ਤੇ ਚੰਗਾ ਲੱਗ ਸਕਦਾ ਹੈ, ਪਰ ਅਸਲੀ ਯੂਜ਼ਰ ਦੀਆਂ ਸ਼ਿਕਾਇਤਾਂ ਦਿਖਾ ਦਿੰਦੀਆਂ ਹਨ ਕਿ ਕਿੱਥੇ ਫੇਲ ਹੋ ਰਿਹਾ ਹੈ। ਇਹ ਵਿਰੋਧੀ ਦਬਾਅ ਹੀ ਪਹਿਲੀ ਡ੍ਰਾਫਟ ਨੂੰ ਭਰੋਸੇਮੰਦ ਚੀਜ਼ ਬਣਾਉਂਦਾ ਹੈ।
ਮਨ ਵਿੱਚ ਰੱਖੋ: ਇਹ "ਸਿਰਫ਼ ਲੋਕਾਂ ਨੂੰ ਲੜਵਾਉਣ" ਦਾ ਮਾਡਲ ਨਹੀਂ। ਇਹ ਨਿਯਮਤ ਦਬਾਅ ਹੈ ਜਿਸ ਵਿੱਚ ਨਿਯਮ ਸਪਸ਼ਟ ਹੋਣ। ਤੁਸੀਂ ਚਾਹੁੰਦੇ ਹੋ ਕਿ ਚੈਲੈਂਜਰ ਕਾਫ਼ੀ ਕਠਿਨ ਹੋਵੇ ਤਾਂ ਕਿ ਕਮਜ਼ੋਰੀਆਂ ਨਿਕਲ ਕੇ ਆਉਣ, ਪਰ ਇੰਨਾ ਬੇਚੈਨ ਵੀ ਨਾ ਹੋਵੇ ਕਿ ਉਤਪਾਦਕ ਸਮਝ ਨਾ ਪਾਏ ਕਿ ਕੀ ਠੀਕ ਕਰਨਾ ਹੈ।
ਤੁਸੀਂ ਜੋ ਲੂਪ ਚਾਹੁੰਦੇ ਹੋ ਉਹ ਛੋਟਾ ਅਤੇ ਦੁਹਰਾਉਯੋਗ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ:
ਇਹਨੂੰ ਹਫ਼ਤਾਵਾਰੀ ਦੌੜਣ ਯੋਗ ਰੱਖੋ। ਟੀਮਾਂ ਅਚਾਨਕਿਆਂ ਤੋਂ ਇਸ ਤਰ੍ਹਾਂ ਬਚਦੀਆਂ ਹਨ: ਭਵਿੱਖ ਬਾਰੇ ਅਨੁਮਾਨ ਲਗਾ ਕੇ ਨਹੀਂ, ਬਲਕਿ ਆਪਣੀ ਪ੍ਰਣਾਲੀ ਨੂੰ ਇੱਕ ਨਹੀਂ ਪਰ ਸਰਗਰਮ ਵਿਰੋਧੀ ਦੇ ਕੇ।
Ian Goodfellow ਨੇ 2014 ਵਿੱਚ Generative Adversarial Networks (GANs) ਪੇਸ਼ ਕੀਤੀਆਂ।
GAN ਦੋ AI ਮਾਡਲ ਹਨ ਜੋ ਮੁਕਾਬਲੇ ਰਾਹੀਂ ਸਿੱਖਦੇ ਹਨ। ਇੱਕ ਕੁਝ ਬਣਾਉਂਦਾ ਹੈ ਜੋ ਅਸਲੀ ਵਗੋਂ ਲੱਗੇ — ਜਿਵੇਂ ਚਿੱਤਰ, ਆਡੀਓ ਜਾਂ ਟੈਕਸਟ। ਦੂਜਾ ਪਤਾ ਲਾਉਂਦਾ ਹੈ ਕਿ ਕੀ ਨਕਲੀ ਹੈ। ਮੁੱਢਲੀ ਧਾਰਣਾ ਸਮਝਣ ਲਈ ਗਣਿਤ ਦੀ ਲੋੜ ਨਹੀਂ: ਦੋਹਾਂ ਮਾਡਲ ਸੁਧਰਦੇ ਹਨ ਕਿਉਂਕਿ ਵਿਰੋਧੀ ਬਿਹਤਰ ਹੁੰਦਾ ਹੈ।
ਭੂਮਿਕਾਵਾਂ ਆਮ ਤੌਰ 'ਤੇ ਹੁੰਦੀਆਂ ਹਨ:
ਪੂਰਾ ਮਕਸਦ ਫੀਡਬੈਕ ਲੂਪ ਹੈ। ਜਦ discriminator generator ਨੂੰ ਫੜਦਾ ਹੈ, generator ਨੂੰ ਪਤਾ ਲੱਗਦਾ ਹੈ ਕਿ ਕਿਸ ਗਲਤੀ ਕਾਰਨ ਫਸਿਆ। ਜਦ generator discriminator ਨੂੰ ਬੇਫ਼ਿਕਰ ਕਰ ਦਿੰਦਾ ਹੈ, discriminator ਸਿੱਖਦਾ ਹੈ ਕਿ ਉਹ ਕੀ ਨਹੀਂ ਦੇਖ ਰਿਹਾ। ਬਹੁਤ ਸਾਰੇ ਦੌਰਾਂ 'ਤੇ, ਆਸਾਨ ਨਕਲਾਂ ਕੰਮ ਨਹੀਂ ਕਰਦੀਆਂ, ਇਸ ਲਈ generator ਹੋਰ ਹਕੀਕਤੀ ਨਤੀਜਿਆਂ ਵੱਲ ਧੱਕਿਆ ਜਾਂਦਾ ਹੈ।
ਇੱਕ ਸਧਾਰਣ ਉਦਾਹਰਨ ਹੈ ਨਕਲੀ ਕਰੰਸੀ ਬਣਾਉਣ ਵਾਲੇ ਵਿਰੁੱਧ ਮੁਆਇਨੇ ਕਰਨ ਵਾਲੇ: ਨਕਲੀ بنانے ਵਾਲੇ ਨਕਲਾਂ ਬਣਾਉਂਦੇ ਹਨ; ਇੰਸਪੈਕਟਰ ਅਨੇਕ ਛੋਟੇ ਨਿਸ਼ਾਨ ਲੱਭਦੇ ਹਨ। ਜੇ ਇੰਸਪੈਕਟਰ ਸੁਧਰਦੇ ਹਨ ਤਾਂ ਨਕਲੀ ਬਣਾਉਣ ਵਾਲਿਆਂ ਨੂੰ ਵੀ ਸੁਧਾਰਨਾ ਪੈਂਦਾ ਹੈ। ਇਹ ਤਰ੍ਹਾਂ ਦਾ ਦਬਾਅ ਪ੍ਰਗਤੀ ਨੂੰ ਜ਼ਬਰਦਸਤ ਬਣਾਉਂਦਾ ਹੈ।
ਵਿਰੋਧੀ ਸੋਚ ਇਸ ਲਈ ਕੰਮ ਕਰਦੀ ਹੈ ਕਿਉਂਕਿ ਇਹ ਸੁਧਾਰ ਨੂੰ ਇੱਕ ਲੂਪ ਵਿੱਚ ਬਦਲ ਦਿੰਦੀ ਹੈ ਜਿਸ 'ਚ ਬਣਾਇਆ ਗਿਆ ਸਕੋਰ ਮਾਰਗਦਰਸ਼ਨ ਮੁਹੱਈਆ ਕਰਦਾ ਹੈ। ਇੱਕ ਪਾਸੇ ਜਿੱਤਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਹੈ, ਦੂਜਾ ਪਾਸਾ ਨੁਕਸਾਨ ਤੋਂ ਸਿੱਖਦਾ ਹੈ। ਮਹੱਤਵਪੂਰਨ ਗੱਲ ਇਹ ਨਹੀਂ ਕਿ ਦੋ ਮਾਡਲ ਹਨ; ਬਹੁਤ ਜ਼ਰੂਰੀ ਗੱਲ ਇਹ ਹੈ ਕਿ "ਵਧੀਆ" ਕਦਮ-ਦਰ-ਕਦਮ ਮਾਪਿਆ ਜਾਂਦਾ ਹੈ।
ਇੱਕ ਫਾਇਦੇਮੰਦ ਵਿਰੋਧੀ ਪਾਸੇ ਦੀਆਂ ਦੋ ਖ਼ੂਬੀਆਂ ਹੋਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ: ਇੱਕ ਸਪਸ਼ਟ ਮਕਸਦ ਅਤੇ ਲਗਾਤਾਰ ਸਕੋਰਿੰਗ। GANs ਵਿੱਚ, discriminator ਦਾ ਕੰਮ ਸਿਧਾ ਹੁੰਦਾ ਹੈ: ਅਸਲੀ ਤੋਂ ਨਕਲੀ ਨੂੰ ਵੱਖਰਾ ਕਰੋ। ਜਦ ਇਹ ਫੈਸਲਾ ਕਾਫੀ ਸਥਿਰ ਹੋ ਜਾਂਦਾ ਹੈ, generator ਨੂੰ ਇਸ ਗਲਤੀ ਬਾਰੇ ਪ੍ਰਯੋਗਿਕ ਫੀਡਬੈਕ ਮਿਲਦਾ ਹੈ, ਭਾਵੇਂ ਕੋਈ ਸੁਲਝੀ ਹੋਈ ਨਿਯਮ ਨਹੀਂ ਹੋਵੇ।
ਸਕੋਰਿੰਗ ਸਿਗਨਲ ਸੋਫ਼ਿਸਟੀਕੇਟਡ ਆਰਕੀਟੈਕਚਰ ਤੋਂ ਵੱਧ ਮੈਟਰ ਕਰਦਾ ਹੈ। ਜੇ ਜੱਜ ਸ਼ੋਰ ਵਾਲਾ ਹੈ, ਆਸਾਨ ਚਾਲਾਂ ਨਾਲ ਠੱਗਿਆ ਜਾ ਸਕਦਾ ਹੈ, ਜਾਂ ਸਮੇਂ ਦੇ ਨਾਲ ਮਤਲਬ ਬਦਲ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਲਰਨਰ ਬੇਨਤੀ-ਪੱਖ ਨੂੰ ਤੱਕੜੀ ਜਾਂਗੇ। ਜੇ ਜੱਜ ਦੁਹਰਾਏ ਜਾਂ ਸਕਣ ਵਾਲੇ ਨਿਰਦੇਸ਼ ਦਿੰਦਾ ਹੈ, ਤਬ ਸੁਧਾਰ ਵੱਧਦਾ ਚੱਲਦਾ ਹੈ।
ਅਸਥਿਰਤਾ ਅਕਸਰ ਉਸ ਵੇਲੇ ਆਉਂਦੀ ਹੈ ਜਦ ਵਿਰੋਧੀ ਬੁਰੇ ਤੌਰ 'ਤੇ ਸੰਤੁਲਿਤ ਹੁੰਦਾ ਹੈ:
ਅਸਲ ਪ੍ਰਗਟੀਤਾ ਇਸ ਗੱਲ ਨਾਲ ਦਿਸਦੀ ਹੈ ਕਿ ਆਸਾਨ ਜਿੱਤਾਂ ਘੱਟ ਹੋ ਰਹੀਆਂ ਹਨ ਅਤੇ ਨੁਕਸਾਨ ਹਨ ਜੋ ਹੁਣ ਨਾਜ਼ੁਕ ਹੋਣ ਜਾਂ ਰੇਅਰ ਏਜ ਕੇਸ ਵਿੱਚ ਆ ਰਹੇ ਹਨ। ਸ਼ੁਰੂ ਵਿੱਚ, ਜੱਜ ਸਪਸ਼ਟ ਗਲਤੀਆਂ ਫੜਦਾ ਹੈ। ਬਾਅਦ ਵਿੱਚ, ਫੇਲ ਨਾਜ਼ੁਕ ਆਰਟੀਫੈਕਟ, ਰੇਅਰ ਏਜ ਕੇਸ, ਜਾਂ ਕੁਝ ਖਾਸ ਇਨਪੁਟ ਹਾਲਤਾਂ 'ਚ ਹੀ ਨਿਕਲਦੇ ਹਨ — ਇਹ ਚੰਗਾ ਸੰਗੇਤ ਹੈ, ਭਾਵੇਂ ਐਹਸਾਸ ਹੋਏ ਤਾਂ ਲਹੂਕਦਰ ਤੇਜ਼ੀ ਘੱਟ ਲੱਗੇ।
ਇੱਕ ਅਹਮ ਸੀਮਾ ਹੈ: ਲੂਪ ਗਲਤ ਟਾਰਗੇਟ ਨੂੰ Optimize ਕਰ ਸਕਦਾ ਹੈ। ਜੇ ਤੁਹਾਡਾ ਜੱਜ "ਲੱਗਦਾ ਹੈ ਕਿ ਠੀਕ" ਨੂੰ ਇਨਾਮ ਦਿੰਦਾ ਹੈ ਬਜਾਏ "ਸਹੀ ਹੋਣ" ਦੇ, ਤਾਂ ਪ੍ਰਣਾਲੀ ਸਿਰਫ਼ ਸਹੀ ਲੱਗਣ 'ਤੇ ਧਿਆਨ ਦੇਵੇਗੀ। ਉਦਾਹਰਨ ਵਜੋਂ, ਇੱਕ ਸਪੋਰਟ ਬੋਟ ਜੋ ਸਿਰਫ਼ ਟੋਨ ਅਤੇ ਬੋਲਚਾਲ 'ਤੇ ਸਿਖਾਇਆ ਗਿਆ ਹੈ, ਉਹ ਦਿਲੇਰ ਜਵਾਬ ਦੇ ਸਕਦਾ ਹੈ ਪਰ ਨੀਤੀ ਦੀਆਂ ਡੀਟੇਲਾਂ ਗਲਤ ਦੇ ਸਕਦਾ ਹੈ। ਲੂਪ ਆਪਣਾ ਕੰਮ ਕੀਤਾ, ਪਰ ਗਲਤ ਕੰਮ।
GANs ਤਸਵੀਰਾਂ ਤੋਂ ਬਾਹਰ ਵੀ ਲਾਗੂ ਹੋ ਸਕਦੇ ਹਨ ਕਿਉਂਕਿ ਇਹ ਇੱਕ ਦੁਹਰਾਊ ਨਮੂਨਾ ਨਾਂਮ ਕਰ ਦਿੰਦੇ ਹਨ: ਇੱਕ ਪ੍ਰਣਾਲੀ ਉਤਪਾਦ ਕਰਦੀ ਹੈ, ਦੂਜੀ ਨਿਆਂ ਕਰਦੀ ਹੈ। ਉਤਪਾਦਕ ਹੋ ਸਕਦਾ ਹੈ ਮਾਡਲ, ਪ੍ਰਾਂਪਟ, ਫੀਚਰ, ਜਾਂ ਰਿਲੀਜ਼; ਨਿਆਂਕਰ ਹੋ ਸਕਦਾ ਹੈ ਟੈਸਟ, ਸਮੀਖਿਆਕਾਰ, ਨੀਤੀ, ਇਵੈਲ ਸਕ੍ਰਿਪਟ, ਜਾਂ ਹਮਲਾਵਰ ਜੋ ਤੁਹਾਡੇ ਬਣਾਏ ਹੋਏ ਚੀਜ਼ ਨੂੰ ਤੋੜਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਹੈ।
ਮਹੱਤਵਪੂਰਨ ਗੱਲ ਲੂਪ ਹੈ:
ਬਣਾਉਂਦੇ ਸਮੇਂ ਮੰਨ ਕੇ ਚਲੋ ਕਿ ਪਹਿਲੀ ਵਰਜਨ ਨੂੰ ਫਸਾਇਆ, ਦੁਰਵ੍ਯਵਹਾਰ ਕੀਤਾ ਜਾਂ ਗਲਤ ਸਮਝਿਆ ਜਾਵੇਗਾ। ਫਿਰ ਇਹ ਕੇਸ ਤੇਜ਼ੀ ਨਾਲ ਲੱਭਣ ਲਈ ਤਰੀਕਾ ਡਿਜ਼ੈਨ ਕਰੋ।
ਇੱਕ ਜ਼ਰੂਰੀ ਜ਼ਰੂਰਤ ਇਹ ਹੈ ਕਿ ਜੱਜ ਉਤਪਾਦਕ ਦੇ ਸੁਧਾਰ ਨਾਲ ਨਾਲ ਹੋਰ ਵੀ ਕਠਿਨ ਹੁੰਦਾ ਜਾਵੇ। ਜੇ ਟੈਸਟ ਕਦੇ ਨਹੀਂ ਬਦਲਦੇ, ਪ੍ਰਣਾਲੀ ਅੰਤ ਵਿੱਚ ਸਿਰਫ਼ ਟੈਸਟ ਨੂੰ ਸਿੱਖ ਲੈਂਦੀ ਹੈ, ਅਸਲ ਮਕਸਦ ਨੂੰ ਨਹੀਂ। ਇਸੀ ਤਰ੍ਹਾਂ ਬਹੁਤੀਆਂ ਟੀਮਾਂ ਦੇ ਹਰੇ ਬੋਰਡ ਹੁੰਦੇ ਹਨ ਪਰ ਉਪਭੋਗਤਾ ਨਰਾਜ਼।
ਤੁਸੀਂ ਇਹੀ ਢਾਂਚਾ ਰੋਜ਼ਮਰ੍ਹਾ ਕੰਮ ਵਿੱਚ ਦੇਖ ਸਕਦੇ ਹੋ: ਯੂਨਿਟ ਟੈਸਟ ਬੱਗਾਂ ਤੋਂ ਬਾਅਦ ਵਧਦੇ ਹਨ, QA ਜੈਦਾ ਏਜ ਕੇਸ ਜੋੜਦਾ ਹੈ, ਧੋਖਾਧੜੀ ਪਤਾ ਲੱਗਣ ਤੇ ਰਣਨੀਤੀ ਬਦਲਦੀ ਹੈ। ਸ਼ੁਰੂ 'ਤੇ ਪ੍ਹੁੰਕਤ ਜੱਜ ਦੀ ਲੋੜ ਨਹੀਂ — ਪਰ ਇੱਕ ਅਜਿਹਾ ਜੱਜ ਚਾਹੀਦਾ ਹੈ ਜੋ ਸਿੱਖਦਾ ਰਹੇ, ਤੇ ਹਰ ਫੇਲ ਨੂੰ ਨਵੇਂ ਚੈੱਕ ਵਿੱਚ ਬਦਲਦਾ ਰਹੇ।
ਪ੍ਰਾਂਪਟ ਲਿਖਣਾ ਤੇ ਨਤੀਜੇ ਮਾਪਣਾ ਵੱਖ-ਵੱਖ ਕੰਮ ਹਨ। ਪ੍ਰਾਂਪਟ ਤੁਹਾਡਾ ਧਾਰਣਾ ਹੈ ਕਿ ਮਾਡਲ ਨੂੰ ਕਿਵੇਂ ਮਾਰਗਦਰਸ਼ਨ ਕਰਨਾ ਹੈ। ਇੱਕ ਇਵੈਲ ਤੁਹਾਡਾ ਦਲੀਲ ਹੈ ਕਿ ਇਹ ਵੱਖ-ਵੱਖ ਕੇਸਾਂ 'ਤੇ ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ। ਜੇ ਤੁਸੀਂ ਸਿਰਫ਼ ਇੱਕ ਚੰਗੀ ਗੱਲ 'ਤੇ ਭਰੋਸਾ ਕਰੋ, ਤਾਂ ਤੁਸੀਂ ਨਤੀਜੇ ਦੀ ਭਾਵਨਾ ਦੀ ਆਧਾਰ 'ਤੇ ਨਿਆਂ ਕਰ ਰਹੇ ਹੋ, ਨਕੀ ਕਿ ਨਤੀਜਿਆਂ 'ਤੇ।
ਇਕ ਇਵੈਲ ਸੈੱਟ ਛੋਟਾ, ਫਿਕਸਡ ਤੇ ਅਸਲੀ ਵਰਤੋਂ-ਝਲਕ ਵਾਲਾ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਇਸ ਵਿੱਚ ਆਮ ਬੇਨਤੀਆਂ ਅਤੇ ਉਹ ਅਜਿਹੇ ਕੁਝ ਗੰਦੇ ਕੇਸ ਸ਼ਾਮਲ ਹੋਣ ਜੋ ਯੂਜ਼ਰ ਰਾਤ 2 ਵਜੇ ਦੇ ਦੌਰਾਨ ਮਿਲਦੇ ਹਨ। ਇਸਨੂੰ ਛੋਟਾ ਰੱਖੋ ਤਾਂ ਜੋ ਅਕਸਰ ਦੌਰ ਸਕੋ, ਪਰ ਅਸਲ ਹੋਣੇ ਤੱਕ ਮਹੱਤਵਪੂਰਨ ਰਹੇ।
ਅਮਲ ਵਿੱਚ, ਇੱਕ ਵਧੀਆ ਸ਼ੁਰੂਆਤੀ ਇਵੈਲ ਸੈੱਟ ਆਮ ਤੌਰ 'ਤੇ ਸ਼ਾਮਿਲ ਕਰਦਾ ਹੈ: ਆਮ ਯੂਜ਼ਰ ਟਾਸਕ, ਕੁਝ ਗੰਦੇ ਇਨਪੁਟ (ਖਾਲੀ ਫੀਲਡ, ਬੇਤਰਤੀਬ ਫਾਰਮੈਟ, ਅਧੂਰਾ ਡੇਟਾ), ਸੁਰੱਖਿਆ ਦੀਆਂ ਹੱਦਾਂ (ਜਿਹਨਾਂ ਨੂੰ ਮਨਾਹੀ ਕਰਨੀ ਹੈ), ਅਤੇ ਕੁਝ ਮਲਟੀ-ਟਰਨ ਫਾਲੋਅਪਸ ਤਾਕਿ ਲਗਾਤਾਰਤਾ ਅਜ਼ਮਾਈ ਜਾ ਸਕੇ। ਹਰ ਕੇਸ ਲਈ, "ਚੰਗਾ" ਕੀ ਹੈ ਇਹ ਇਕ ਛੋਟੀ ਵਿਆਖਿਆ ਲਿਖੋ ਤਾਂ ਕਿ ਸਕੋਰਿੰਗ ਇਕਸਾਰ ਰਹੇ।
ਫਿਰ ਲੂਪ ਦੌੜਾਓ: ਪ੍ਰਾਂਪਟ ਬਦਲੋ, ਇਵੈਲ ਦੌੜਾਓ, ਨਤੀਜੇ ਤੁਲਨਾ ਕਰੋ, ਰੱਖੋ ਜਾਂ ਵਾਪਸ ਲੈਲੋ। ਵਿਰੋਧੀ ਪੱਖ ਇਹ ਹੈ ਕਿ ਤੁਹਾਡੇ ਇਵੈਲ ਉਹ ਫੇਲ ਕੈਸ ਲੱਭ ਰਹੇ ਹਨ ਜੋ ਬਗੈਰ ਉਹਨਾਂ ਨੂੰ ਤੁਸੀਂ ਨਹੀਂ ਦੇਖਦੇ।
ਰਿਗਰੈਸ਼ਨ ਇੱਕ ਮੁੱਖ ਫਸਲ ਹੋ ਸਕਦਾ ਹੈ। ਇੱਕ ਪ੍ਰਾਂਪਟ ਬਦਲਾਅ ਇਕ ਕੇਸ ਨੂੰ ਠੀਕ ਕਰ ਸਕਦਾ ਹੈ ਪਰ ਚੁਪਚਾਪ ਦੋ ਪੁਰਾਣੇ ਕੇਸ ਗੁਆ ਭਦਾ ਦੇਵੇ। ਇੱਕ ਹੀ ਸੁਧਰੇ ਗੱਲ ਤੇ ਭਰੋਸਾ ਨਾ ਕਰੋ — ਪੂਰੇ ਇਵੈਲ ਸੈੱਟ 'ਤੇ ਸਕੋਰ 'ਤੇ ਭਰੋਸਾ ਕਰੋ।
ਉਦਾਹਰਨ: ਤੁਸੀਂ "ਸੰਖੇਪ ਰਹੋ" ਸ਼ਾਮਿਲ ਕਰਦੇ ਹੋ, ਜਵਾਬ ਤੇਜ਼ ਹੋ ਜਾਂਦੇ ਹਨ। ਪਰ ਇਵੈਲ ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਹੁਣ ਰિફੰਡ ਬੇਨਤੀਆਂ ਵਿੱਚ ਜ਼ਰੂਰੀ ਨੀਤੀ ਟੈਕਸਟ ਛੱਡ ਦਿੱਤਾ ਗਿਆ ਹੈ ਅਤੇ ਜਦ ਯੂਜ਼ਰ ਮਿਡ-ਥ੍ਰੈੱਡ ਵਿੱਚ ਆਪਣਾ ਸਵਾਲ ਸੋਧਦਾ ਹੈ ਤਾਂ ਗਲਤ ਹੋ ਜਾਂਦਾ ਹੈ। ਇਹ ਸਕੋਰਕਾਰਡ ਦੱਸਦਾ ਹੈ ਕਿ ਤੁਹਾਨੂੰ ਕੀ ਅਜਿਹਾ ਬਦਲਨਾ ਹੈ ਅਤੇ ਜੇ ਬਦਲਾਅ ਸਮੁੱਚੇ ਤੌਰ 'ਤੇ ਬੁਰਾ ਕਰ ਰਿਹਾ ਹੈ ਤਾਂ ਵਾਪਸੀ ਦੀ ਵਜਹ ਦਿੰਦਾ ਹੈ।
ਜੇ ਤੁਸੀਂ ਕਿਸੇ ਚੈਟ-ਟੂ-ਐਪ ਪਲੇਟਫਾਰਮ ਜਿਵੇਂ Koder.ai 'ਤੇ ਬਣਾਉਂਦੇ ਹੋ, ਤਾਂ ਪ੍ਰਾਂਪਟ ਵਰਜਨਾਂ ਨੂੰ ਰਿਲੀਜ਼ ਵਾਂਗ ਮਾਣੋ: ਜੋ ਚੰਗਾ ਕੰਮ ਕਰ ਰਿਹਾ ਹੈ ਉਸ ਦਾ ਸਨੇਪਸ਼ਾਟ ਲਵੋ, ਇਵੈਲ ਦੌੜਾਓ, ਅਤੇ ਉਨ੍ਹਾਂ ਹੀ ਬਦਲਾਵਾਂ ਨੂੰ ਉਨ੍ਹਾਂ ਹੀ ਹਾਲਤਾਂ 'ਚ ਪ੍ਰਮੋਟ ਕਰੋ ਜਦ ਉਹ ਸਕੋਰ ਸੁਧਾਰਦੇ ਹਨ ਬਿਨਾਂ ਪੁਰਾਣੇ ਕੇਸ ਟੁੱਟਣ ਦੇ।
ਸੁਰੱਖਿਆ ਤੇਜ਼ੀ ਨਾਲ ਸੁਧਰਦੀ ਹੈ ਜਦ ਤੁਸੀਂ ਇਸਨੂੰ ਇੱਕ ਲੂਪ ਵਾਂਗ ਸਮਝਦੇ ਹੋ। ਇੱਕ ਪਾਸਾ ਸਿਸਟਮ ਨੂੰ ਤੋੜਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਹੈ, ਦੂਜਾ ਉਸਨੂੰ ਠੀਕ ਕਰਦਾ ਹੈ, ਅਤੇ ਹਰ ਟੁੱਟਣ ਨੂੰ ਐਗਲ ਵਜੋਂ ਆਉਣ ਵਾਲੇ ਹਫ਼ਤੇ ਦੇ ਟੈਸਟ ਵਿਚ ਸ਼ਾਮਿਲ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਇੱਕ ਵਾਰੀ ਦਾ ਚੈੱਕਲਿਸਟ ਮਦਦ ਕਰਦਾ ਹੈ, ਪਰ ਉਹ ਅਸਲ ਹਮਲਿਆਂ ਦੀ ਸਿਰਜਣਾ ਹਿਸੇ ਨੂੰ ਨਹੀਂ ਕਵਰ ਕਰਦਾ।
ਇਸ ਲੂਪ ਵਿੱਚ, "ਰੈਡ ਟੀਮ" ਇਕ ਸਮਰਪਿਤ ਸੁਰੱਖਿਆ ਟੀਮ ਹੋ ਸਕਦੀ ਹੈ, ਘੁੰਮਣ ਵਾਲਾ ਇੰਜੀਨੀਅਰ, ਜਾਂ ਸਮੀਖਿਆ ਦੌਰਾਨ ਇੱਕ ਨਿਯੁਕਤ ਰੋਲ। "ਬਲੂ ਟੀਮ" ਉਹ ਸਭ ਹੈ ਜੋ ਉਤਪਾਦ ਨੂੰ ਮਜ਼ਬੂਤ ਕਰਦੀ: ਸੁਰੱਖਿਅਤ ਡੀਫਾਲਟ, ਬਿਹਤਰ ਪ੍ਰਮਿਸ਼ਨ, ਸਪਸ਼ਟ ਸੀਮਾਵਾਂ, ਨਿਗਰਾਨੀ ਅਤੇ ਘਟਨਾਕ੍ਰਮ ਜਵਾਬ।
ਜ਼ਿਆਦਾਤਰ ਮੁੱਦੇ ਤਿੰਨ ਪ੍ਰੋਫ਼ਾਈਲਾਂ ਤੋਂ ਆਉਂਦੇ ਹਨ: ਉਤਸੁਕ ਯੂਜ਼ਰ ਜੋ ਅਜੀਬ ਇਨਪੁਟ ਟੈਸਟ ਕਰਦੇ ਹਨ, ਮਾਲਿਸ਼ਸ ਯੂਜ਼ਰ ਜੋ ਡੇਟਾ ਜਾਂ ਵਿਘਨ ਚਾਹੁੰਦੇ ਹਨ, ਅਤੇ ਅੰਦਰੂਨੀ ਲੋਕ (ਜਾਂ_compromised accounts_) ਜਿਨ੍ਹਾਂ ਕੋਲ ਪਹਿਲਾਂ ਹੀ ਕੁਝ ਪਹੁੰਚ ਹੈ।
ਹਰ ਪ੍ਰੋਫ਼ਾਈਲ ਵੱਖ-ਵੱਖ ਕਮਜ਼ੋਰੀਆਂ 'ਤੇ ਧੱਕਾ ਮਾਰਦਾ ਹੈ। ਉਤਸੁਕ ਯੂਜ਼ਰ ਤੀਖੀਆਂ ਧਾਰਾਂ ਲੱਭਦੇ ਹਨ। ਡੁੱਸਣ ਵਾਲੇ ਵਰਤੋਂਕਾਰ ਦੁਹਰਾਏ ਜਾ ਸਕਣੇ ਰਸਤੇ ਲੱਭਦੇ ਹਨ। ਅੰਦਰੂਨੀ ਜਾਂ ਸਮਝੋਤੇ ਵਾਲੇ ਖਾਤੇ ਜਾਂਚਦੇ ਹਨ ਕਿ ਕੀ ਤੁਹਾਡੀ ਪਰਮੀਸ਼ਨ ਅਤੇ ਆਡੀਟ ਟਰੇਲ ਹਕੀਕਤੀ ਹਨ ਜਾਂ ਸਿਰਫ਼ ਨਜ਼ਰੀਅਤ।
AI ਐਪਸ ਵਿੱਚ ਟਾਰਗਟ ਆਮ ਤੌਰ 'ਤੇ ਪ੍ਰਿਡੈਕਟੇਬਲ ਹਨ: ਡੇਟਾ ਲੀਕੇਜ (ਸਿਸਟਮ ਪ੍ਰਾਂਪਟ, ਨਿੱਜੀ ਡੌਕਸ, ਯੂਜ਼ਰ ਜਾਣਕਾਰੀ), ਅਸੁਰੱਖਿਅਤ ਕਾਰਵਾਈਆਂ (ਟੂਲ ਕਾਲਾਂ ਜੋ ਮਿਟਾਉਂਦੀਆਂ, ਭੇਜਦੀਆਂ ਜਾਂ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰਦੀਆਂ ਹਨ), ਅਤੇ ਪ੍ਰਾਂਪਟ ਇੰਜੈਕਸ਼ਨ (ਮਾਡਲ ਨੂੰ ਨਿਯਮਾਂ ਉਠਾਉਣ ਜਾਂ ਟੂਲਾਂ ਮਿਸਯੂਜ਼ ਕਰਨ ਲਈ ਮਿਲਾਉਣਾ)।
ਹਮਲਿਆਂ ਨੂੰ ਦੁਹਰਾਉਣਯੋਗ ਟੈਸਟਾਂ ਵਿੱਚ ਬਦਲਣ ਲਈ, ਉਹਨਾਂ ਨੂੰ ਵੁੱਧ-ਵਿਸ਼ੇਸ਼ ਪਰਿਸਥਿਤੀਆਂ ਵਜੋਂ ਲਿਖੋ ਜਿਸ ਵਿੱਚ ਇੱਕ ਉਮੀਦ ਰਿਪਲਾਈ ਵੀ ਦਰਜ ਹੋਵੇ, ਫਿਰ ਜਦੋਂ ਤੁਸੀਂ ਪ੍ਰਾਂਪਟ, ਟੂਲ ਜਾਂ ਮਾਡਲ ਸੈਟਿੰਗਸ ਬਦਲਦੇ ਹੋ ਤਾਂ ਇਨ੍ਹਾਂ ਨੂੰ ਮੁੜ ਚਲਾਓ। ਇਨ੍ਹਾਂ ਨੂੰ ਰਿਗਰੈਸ਼ਨ ਟੈਸਟ ਸਮਝੋ, ਨਾ ਕਿ ਜੰਗ ਦੀਆਂ ਕਹਾਣੀਆਂ।
ਸਰਲ ਸ਼ੁਰੂਆਤੀ ਸੈੱਟ ਵਿੱਚ ਸ਼ਾਮਲ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ: ਦਿੱਤੇ ਹੋਏ ਨਿਰਦੇਸ਼ਾਂ ਨੂੰ ਕੱਢਣ ਦੀ ਕੋਸ਼ਿਸ਼ਾਂ, ਪੇਸਟ ਕੀਤੇ ਸਮੱਗਰੀ ਦੁਆਰਾ ਪ੍ਰਾਂਪਟ ਇੰਜੈਕਸ਼ਨ (ਈ-ਮੇਲ, ਟਿਕਟ, HTML), ਯੂਜ਼ਰ ਦੇ ਰੋਲ ਤੋਂ ਬਾਹਰ ਟੂਲ ਦੁਰਵ੍ਯਵਹਾਰ, ਡਾਟਾ ਸੀਮਾਵਾਂ ਪਾਰ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ਾਂ, ਅਤੇ ਬਹੁਤ ਲੰਬੇ ਇਨਪੁਟ ਜਾਂ ਦੁਹਰਾਈ ਕਾਲਾਂ ਵਰਗੇ ਇਨਕਾਰ ਪੈਟਰਨ।
ਮਕਸਦ ਸ parfait ਨਹੀਂ ਹੈ; ਮਕਸਦ ਹੈ ਫੇਲ ਦੀ ਲਾਗਤ ਵਧਾਉਣਾ ਅਤੇ ਨੁਕਸਾਨ ਖੇਤਰ ਘਟਾਉਣਾ: least-privilege ਟੂਲ ਪਹੁੰਚ, ਸਕੋਪਡ ਡਾਟਾ ਰੀਟਰਾਈਵਲ, ਮਜ਼ਬੂਤ ਲੋਗਿੰਗ, ਅਤੇ ਜਦ ਮਾਡਲ ਉਂਝ ਅਣਿਸ਼ਚਿਤ ਹੋਵੇ ਤਾਂ ਸੁਰੱਖਿਅਤ ਵੈਕਾਰਲਬੈਕ।
ਪਹਿਲਾਂ ਇੱਕ ਛੋਟਾ, ਅਸਲੀ ਵਰਕਫ਼ਲੋ ਚੁਣੋ ਜਿਸਨੂੰ ਤੁਸੀਂ ਪਹਿਲਾਂ ਮਜ਼ਬੂਤ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ। ਸਭ ਕੁਝ ਇਕੱਠੇ ਠੀਕ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਨ ਨਾਲ ਨਿਰਾਕਾਰ ਨੋਟਸ ਬਣਦੀਆਂ ਹਨ। ਚੰਗੇ ਸ਼ੁਰੂਆਤੀ ਕਾਰਵਾਈਆਂ ਹਨ: "ਸਪੋਰਟ ਟਿਕਟ ਦਾ ਖ਼ੁਲਾਸਾ" ਜਾਂ "ਸਾਈਨਅੱਪ ਈਮੇਲ ਤਿਆਰ ਕਰੋ" ਜਿਵੇਂ ਸਧਾਰਣ ਕਾਰਵਾਈਆਂ।
ਅਗਲਾ, ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ ਲਿਖੋ ਕਿ "ਚੰਗਾ" ਅਤੇ "ਖ਼ਰਾਬ" ਦਾ ਕੀ ਮਤਲਬ ਹੈ। ਸਪਸ਼ਟ ਹੋਵੋ ਕਿ ਕੀ ਮਨਾਹੀ ਹੈ। ਉਦਾਹਰਨ ਲਈ: ਜਵਾਬ ਅੰਗ੍ਰੇਜ਼ੀ ਵਿੱਚ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਕੀਮਤਾਂ ਨਾਂ ਬਣਾ ਸਕੇ, ਯੂਜ਼ਰ ਦੇ ਇਨਪੁਟ ਸਹੀ ਤਰੀਕੇ ਨਾਲ ਵਰਤੇ ਜਾਣ, ਅਤੇ ਅਸੁਰੱਖਿਅਤ ਬੇਨਤੀਆਂ ਨੂੰ ਮਨ੍ਹਾਂ ਕਰਨਾ ਆਦਿ।
ਇੱਕ ਸਰਲ ਲੂਪ ਜੋ ਤੁਸੀਂ ਇਕ ਦਿਨ ਵਿੱਚ ਚਲਾ ਸਕਦੇ ਹੋ:
ਹੁਣ ਉਨ੍ਹਾਂ ਹੀ ਟੈਸਟਾਂ ਨੂੰ ਮੁੜ ਚਲਾਓ। ਜੇ ਸਕੋਰ ਨਹੀਂ ਵਧਦਾ, ਤਾਂ ਤੁਹਾਡਾ ਬਦਲਾਅ ਬਹੁਤ ਵਿਆਪਕ, ਕਮਜ਼ੋਰ, ਜਾਂ ਗਲਤ ਟਾਈਪ ਦੀ ਫੇਲ ਨੂੰ ਨਿਸ਼ਾਨਾ ਬਣਾਉਂਦਾ ਹੈ।
ਸਿਰਫ਼ ਜਦ ਤੁਸੀਂ ਸੁਧਾਰ ਦੇਖੋ ਤਾਂ ਹੀ ਮੁਸ਼ਕਿਲ ਕੇਸ ਜੋੜੋ। ਇੱਕ ਛੋਟੀ "ਅਟੈਕ ਡਾਇਰੀ" ਰੱਖੋ ਨਵੇਂ ਫੇਲ ਪੈਟਰਨਾਂ ਲਈ — ਜਿਵੇਂ ਇੰਜੈਕਸ਼ਨ ਕੋਸ਼ਿਸ਼ਾਂ, ਗੁੰਝਲਦਾਰ ਮਲਟੀ-ਸਟੈਪ ਬੇਨਤੀਆਂ, ਜਾਂ ਖ਼ਾਲੀ ਫੀਲਡ ਵਾਲੇ ਇਨਪੁਟ।
ਜੇ ਤੁਸੀਂ Koder.ai ਨਾਲ ਬਣਾਉਂਦੇ ਹੋ, ਤਾਂ ਪ੍ਰਾਂਪਟਾਂ, ਟੂਲ ਪਹੁੰਚ, ਅਤੇ ਆਉਟਪੁੱਟ ਚੈਕ ਉਸ ਐਪ ਨਾਲ ਵਰਜਨ ਕੀਤੇ ਜਾ ਸਕਦੇ ਹਨ। ਮਕਸਦ ਕੋਈ ਬੇ-ਦੋਸ਼ ਮਾਡਲ ਨਹੀਂ; ਮਕਸਦ ਇੱਕ ਐਸੇ ਲੂਪ ਦਾ ਹੋਣਾ ਹੈ ਜੋ ਤੁਹਾਡੀ ਟੀਮ ਹਰ ਹਫ਼ਤੇ ਚਲਾ ਸਕੇ ਅਤੇ ਫੇਲਾਂ ਨੂੰ ਘੱਟ ਤੇ ਅਸਾਨੀ ਨਾਲ ਪਛਾਣ ਸਕੇ।
ਵਿਰੋਧੀ ਸੋਚ ਸਿਰਫ਼ ਤਦ ਹੀ ਮਦਦ ਕਰਦੀ ਹੈ ਜਦ ਉਤਪਾਦਕ-ਵਿਰੁੱਧ-ਨਿਆਂ ਪਰਿਭਾਸ਼ਾ ਅਸਲ ਹੋਵੇ। ਬਹੁਤ ਸਾਰੀਆਂ ਟੀਮਾਂ ਕੁਝ ਇੰਝ ਬਣਾਉਂਦੀਆਂ ਹਨ ਜੋ ਲੂਪ ਵਰਗੀ ਲੱਗਦੀਆਂ ਹਨ, ਪਰ ਉਹ ਅਚਾਨਕ ਘਟਨਾਵਾਂ ਨੂੰ ਫੜ ਨਹੀਂ ਸਕਦੀਆਂ, ਇਸ ਲਈ ਸੁਧਾਰ ਰੁਕ ਜਾਂਦਾ ਹੈ।
ਇੱਕ ਗਲਤ ਫੈਸਲਾ ਹੈ ਖੁਸ਼-ਰਾਹ ਟੈਸਟਿੰਗ ਨੂੰ ਇਵੈਲ ਕਹਿ ਦੇਣਾ। ਜੇ ਟੈਸਟ ਸਿਰਫ਼ ਨਮ੍ਰ ਇਨਪੁਟ, ਸਾਫ़ ਡੇਟਾ, ਅਤੇ ਪੂਰੇ ਨੈੱਟਵਰਕ ਨਾਲ ਚੱਲਣ ਵਾਲੀ ਪ੍ਰਸਥਿਤੀ ਨੂੰ ਕਵਰ ਕਰਦੇ ਹਨ, ਤਾਂ ਤੁਸੀਂ ਡੈਮੋ ਮਾਪ ਰਹੇ ਹੋ, ਪ੍ਰੋਡਕਟ ਨਹੀਂ। ਇੱਕ ਵਰਤੋਂਯੋਗ ਜੱਜ ਵਿੱਚ ਗੰਦਾ ਉਪਭੋਗਤਾ ਬਣਤਰ, ਏਜ ਕੇਸ, ਅਤੇ ਪਿਛਲੇ ਸਮੇਂ ਦੀਆਂ ਸਪੋਰਟ ਟਿਕਟਾਂ ਤੋਂ ਆਏ ਇਨਪੁਟ ਸ਼ਾਮਿਲ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ।
ਹੋਰ ਸਮੱਸਿਆ ਹੈ ਬਦਲਾਵਾਂ ਨੂੰ ਟਰੈਕ ਨਾ ਕਰਨਾ। ਜਦ ਨਤੀਜੇ ਡਰਿਫਟ ਹੋ ਜਾਂਦੇ ਹਨ, ਤਾਂ ਕਿਸੇ ਨੂੰ ਪਤਾ ਨਹੀਂ ਹੁੰਦਾ ਕਿ ਇਹ ਪ੍ਰਾਂਪਟ ਟਵੀਕ, ਮਾਡਲ ਬਦਲਾਅ, ਨੀਤੀ ਅਪਡੇਟ, ਜਾਂ ਡੇਟਾ ਅਪਡੇਟ ਕਾਰਨ ਸੀ। ਸਧਾਰਨ ਵਰਜਨ ਨੋਟਸ (ਪ੍ਰਾਂਪਟ v12, ਟੂਲ ਸਕੀਮਾ v3, ਇવੈਲ ਸੈੱਟ v5) ਘੰਟਿਆਂ ਦੀ ਅਣਜਾਣੀ ਘਟਾਉਂਦੀਆਂ ਹਨ।
ਲੂਪ ਓਸ ਵੇਲੇ ਵੀ ਢਾਹ ਜਾਂਦਾ ਹੈ ਜਦ ਨਿਆਂਕਰ ਅਸਪਸ਼ਟ ਹੋ। "ਚੰਗਾ ਲੱਗਦਾ ਹੈ" ਕੋਈ ਨਿਯਮ ਨਹੀਂ। ਤੁਹਾਡੇ ਜੱਜ ਨੂੰ ਪਾਸ/ਫੇਲ ਸ਼ਰਤਾਂ ਦੀ ਲੋੜ ਹੈ, ਭਾਵੇਂ ਉਹ ਮੂਲ ਹੋਣ: ਨੀਤੀ ਦੀ ਪਾਲਣਾ, ਸਹੀ ਫੀਲਡ ਦਾ ਹਵਾਲਾ, ਅਸੁਰੱਖਿਅਤ ਬੇਨਤੀਆਂ ਨੂੰ ਮਨਾਂ ਕਰਨਾ, ਜਾਂ ਸਹੀ ਸੰਰਚਿਤ ਆਉਟਪੁੱਟ।
ਓਵਰਫਿੱਟਿੰਗ ਜ਼ਿਆਦਾ ਚੁਪਚਾਪ ਪਰ ਨੁਕਸਾਨਦੇਹ ਹੈ। ਜੇ ਤੁਸੀਂ ਵਾਰ-ਵਾਰ ਉਹੀ ਛੋਟੀ ਟੈਸਟ ਸੈੱਟ 'ਤੇ ਟਿਊਨ ਕਰਦੇ ਹੋ, ਤੁਸੀਂ ਟੈਸਟ ਜਿੱਤ ਲੈਂਦੇ ਹੋ ਪਰ ਅਸਲ ਯੂਜ਼ਰ ਨੂੰ ਗੁਆ ਦੇਂਦੇ ਹੋ। ਨਵੇਂ ਉਦਾਹਰਣ ਰੋਟੇਟ ਕਰੋ, ਅਸਲੀ ਗੱਲਾਂ ਤੋਂ ਨਮੂਨੇ ਲਓ (ਪ੍ਰਾਇਵੇਸੀ ਦੀ ਸੰਭਾਲ ਨਾਲ), ਅਤੇ ਇੱਕ "ਕਦੇ ਨਾ ਵੇਖਿਆ" ਸੈੱਟ ਰੱਖੋ ਜਿਸ 'ਤੇ ਤੁਸੀਂ ਟਿਊਨ ਨਾ ਕਰੋ।
ਰੋਲਬੈਕ ਪੁਆਇੰਟ ਵੀ ਮਹੱਤਵਪੂਰਨ ਹੈ। ਜੇ ਨਵਾਂ ਪ੍ਰਾਂਪਟ ਜਾਂ ਟੂਲ ਬਦਲਾਅ ਸ਼ੁੱਕਰਵਾਰ ਰਾਤ ਨੂੰ ਐਰਰਾਂ ਵਧਾ ਦੇਵੇ, ਤਾਂ ਤੁਹਾਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਵਾਪਸੀ ਦਾ ਰਸਤਾ ਚਾਹੀਦਾ ਹੈ।
ਵਿਰੋਧੀ ਸੋਚ ਦਾ ਮਕਸਦ ਦੁਹਰਾਏ ਜਾ ਸਕਣ ਵਾਲੀ ਪ੍ਰਕਿਰਿਆ ਹੈ। ਜੱਜ ਮੌਜੂਦਾ ਰਹੇ ਭਾਵੇਂ ਉਤਪਾਦਕ ਬਦਲੇ।
ਪਹਿਲਾਂ-ਸ਼ਿਪ ਰਿਵਾਇਲ:
ਫੇਲਾਂ ਨੂੰ ਸ਼੍ਰੇਣੀਬੱਧ ਕਰੋ ਤਾਂ ਕਿ ਪੈਟਰਨ ਨਜ਼ਰ ਆਉਣ: ਸਹੀਤਾ, ਸੁਰੱਖਿਆ, ਨੀਤੀ ਪਾਲਣਾ, ਅਤੇ ਸਧਾਰਨ UX ਸਮੱਸਿਆਵਾਂ। ਜੇ ਤੁਹਾਡਾ ਅਸਿਸਟੈਂਟ ਰਿਫੰਡ ਨਿਯਮ ਬਣਾਂਦਾ ਹੈ, ਤਾਂ ਇਹ ਸਿਰਫ਼ "ਸਹੀਤਾ" ਸਮੱਸਿਆ ਨਹੀਂ — ਇਹ ਨੀਤੀ ਅਤੇ ਭਰੋਸੇ ਦੀ ਸਮੱਸਿਆ ਹੈ, ਅਤੇ ਇਸਨੂੰ ਉਸ ਤਰ੍ਹਾਂ ਟਰੈਕ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ।
ਵਿਰੋਧੀ ਸੋਚ ਇੱਕ ਦੁਹਰਾਊ ਲੂਪ ਹੈ ਜਿਥੇ ਇੱਕ ਪ੍ਰਣਾਲੀ ਉਤਪਾਦ ਦਿੰਦੀ ਹੈ ਅਤੇ ਦੂਜੀ ਪ੍ਰਣਾਲੀ ਉਸਨੂੰ ਟੋੜਨ ਜਾਂ ਮੂਲਾਂਕਣ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੀ ਹੈ। ਫਾਇਦਾ ਟਕਰਾਅ ਨਹੀਂ — ਇਹ ਐਸਾ ਫੀਡਬੈਕ ਹੈ ਜਿਸ 'ਤੇ ਤੁਸੀਂ ਕੰਮ ਕਰ ਸਕਦੇ ਹੋ।
ਇੱਕ ਵਰਤੋਂਯੋਗ ਲੂਪ ਹੁੰਦਾ ਹੈ: ਪਾਸ ਮਿਆਰ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ → ਉਤਪਾਦ ਬਣਾਓ → ਹਕੀਕਤੀ ਨੁਕਸਾਨਾਂ ਨਾਲ ਹਮਲਾ ਕਰੋ → ਠੀਕ ਕਰੋ → ਨਿਯਮਤ ਤੌਰ 'ਤੇ ਦੁਹਰਾ ਕਰੋ।
ਇੱਕ GAN ਵਿੱਚ, ਜਨਰੇਟਰ ਨਮੂਨੇ ਬਣਾਉਂਦਾ ਹੈ ਜੋ ਅਸਲੀ ਲੱਗਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਹਨ, ਅਤੇ ਡਿਸਕ੍ਰਿਮਿਨੇਟਰ "ਅਸਲੀ" ਅਤੇ "ਨਕਲੀ" ਵਿਚਕਾਰ ਫ਼ਰਕ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਹੈ। ਹਰ ਪਾਸਾ ਇਸ ਕਰਕੇ ਸੁਧਰਦਾ ਹੈ ਕਿ ਦੂਜਾ ਪਾਸਾ ਮੁਸ਼ਕਲ ਹੋ ਜਾਂਦਾ ਹੈ।
ਤੁਸੀਂ ਇਸ ਨਮੂਨੇ ਨੂੰ ਗਣਿਤ ਤੋਂ ਬਿਨਾਂ ਵੀ ਲੈ ਸਕਦੇ ਹੋ: ਇੱਕ ਉਤਪਾਦਕ ਬਣਾਓ, ਇਕ ਜੱਜ ਬਣਾਓ, ਅਤੇ ਤਕਰਾਰ ਤੱਕ ਦੌਰ ਲਗਾਉ ਜਦ ਤੱਕ ਨੁਕਸਾਨ ਘੱਟ ਨਾ ਹੋਣ ਲੱਗੇ।
ਸਪਸ਼ਟ ਲੱਛਣਾਂ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ:
ਸੁਧਾਰ ਕਰਨ ਲਈ ਪਾਸ/ਫੇਲ ਨਿਯਮਾਂ ਨੂੰ ਸਪਸ਼ਟ ਕਰੋ, ਵੱਖ-ਵੱਖ ਕੇਸ ਜੋੜੋ, ਅਤੇ ਦੌਰਾਂ ਦੇ ਦਰਮਿਆਨ ਨਿੱਜੀ ਰੂਪ ਨਾਲ ਜੱਜ ਨੂੰ ਸਥਿਰ ਰੱਖੋ।
ਥੋੜ੍ਹਾ ਛੋਟਾ, ਫਿਕਸਡ ਸੈੱਟ ਵਰਤੋ ਜੋ ਤੁਸੀਂ ਅਕਸਰ ਦੌੜਾ ਸਕੋ (ਹਫਤਾਵਾਰੀ ਜਾਂ ਹਰ ਬਦਲਾਅ 'ਤੇ)। ਇੱਕ ਮਜ਼ਬੂਤ ਸ਼ੁਰੂਆਤੀ ਸੈੱਟ ਵਿੱਚ ਸ਼ਾਮਲ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ:
ਇਨ੍ਹਾਂ ਨੂੰ 20–50 ਕੇਸ ਤੱਕ ਰੱਖੋ ਤਾਂ ਕਿ ਤੁਸੀਂ ਵਾਕਈ ਹੀ ਇਹ ਰੀਰਨ ਕਰ ਸਕੋ।
ਪ੍ਰਾਂਪਟ ਤੁਹਾਡੀ ਮੈਨੂੰਮਾਨ ਹਦਾਇਤ ਹੈ; ਇਵੈਲ ਇਹ ਦਰਸਾਉਂਦਾ ਹੈ ਕਿ ਉਹ ਕਿਵੇਂ ਮਾਮਲਿਆਂ 'ਤੇ ਕੰਮ ਕਰਦਾ ਹੈ।
ਮੂਲ ਵਰਕਫ਼ਲੋ:
ਇੱਕ ਚੰਗੀ ਗੱਲ ਕੀਤਾ ਰਿਪਲੀਕੇਟ ਕਰਨ ਦੀ ਬਜਾਇ ਇੱਕ ਵਧੀਆ ਗੱਲ ਉੱਤੇ ਭਰੋਸਾ ਨਾ ਕਰੋ — ਸਕੋਰਕਾਰਡ 'ਤੇ ਭਰੋਸਾ ਕਰੋ।
ਓਵਰਫਿੱਟਿੰਗ ਉਸ ਸਮੇਂ ਹੁੰਦੀ ਹੈ ਜਦ ਤੁਸੀਂ ਇਕ ਛੋਟੀ ਟੈਸਟ ਸੈੱਟ 'ਤੇ ਟਿਊਨ ਕਰ-ਕਰ ਕੇ ਟੈਸਟ ਜਿੱਤ ਲੈਂਦੇ ਹੋ ਪਰ ਅਸਲ ਯੂਜ਼ਰਾਂ ਨਾਲ ਫੇਲ ਹੋ ਜਾਂਦੇ ਹੋ।
ਹਕੀਕਤੀ ਰੋਕਥਾਮ ਲਈ:
ਇਸ ਨਾਲ ਸੁਧਾਰ ਅਸਲ ਰਹਿੰਦੇ ਹਨ ਨਾ ਕਿ ਸਿਰਫ ਦਿਖਾਵਾ।
ਸੁਰੱਖਿਆ ਨੂੰ ਇੱਕ ਲੂਪ ਵਾਂਗ ਦਿਖੋ: ਇੱਕ ਹਿੱਸਾ ਸਿਸਟਮ ਨੂੰ ਟੁੱਟਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਹੈ (ਅਟੈਕਰ), ਦੂਜਾ ਉਸਨੂੰ ਠੀਕ ਕਰਦਾ ਹੈ (ਬਿਲਡਰ), ਅਤੇ ਹਰ ਫੇਲ ਨੂੰ ਦੁਬਾਰਾ ਦੌਰਾਇਆ ਜਾਂਦਾ ਟੈਸਟ ਬਣਾਓ।
AI ਐਪਸ ਲਈ, ਮਹੱਤਵਪੂਰਨ ਟੈਸਟ:
ਮਕਸਦ: ਫੇਲ ਦੀ ਲਾਗਤ ਵਧਾਉਣਾ ਅਤੇ ਨੁਕਸਾਨ ਦਾ ਖੇਤਰ ਘਟਾਉਣਾ — least-privilege, ਸਕੋਪਡ ਡਾਟਾ, ਅਤੇ ਮਜ਼ਬੂਤ ਲੋਗਿੰਗ।
ਇੱਕ ਛੋਟੀ, ਵਾਸਤਵਿਕ ਵਰਕਫ਼ਲੋ ਚੁਣੋ ਜਿਸਨੂੰ ਪਹਿਲਾਂ ਸਖਤ ਕਰਨਾ ਹੈ। ਇਕ-ਇਕ ਕਰ ਕੇ ਸਭ ਕੁਝ ਠੀਕ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਨਾ ਕਰੋ — ਫੋਕਸ ਹੋਵੇ ਤਾਂ ਹੀ ਤੇਜ਼ੀ ਆਉਂਦੀ ਹੈ।
ਸਰਲ ਦਿਨ-ਦਾ-ਦੌਰ:
ਫਿਰ ਸਹੀ ਪਰੀਖਣਾਂ ਦੁਹਰਾਓ; ਜੇ ਸਕੋਰ ਨਹੀਂ ਵਧਦਾ ਤਾਂ ਬਦਲਾਅ ਬੇਕਾਰ ਸੀ।
ਅਕਸਰ ਗਲਤੀਆਂ ਜੋ ਲੂਪ ਨੂੰ ਬੇਕਾਰ ਬਣਾਉਂਦੀਆਂ ਹਨ:
ਇਸ ਨਾਲ ਲੂਪ ਲਗਾਤਾਰ ਕਾਰਗਰ ਬਣਿਆ ਰਹਿੰਦਾ ਹੈ।
ਹੇਠਾਂ ਇੱਕ ਛੋਟੀ ਪਰ ਨਿਯਮਤ ਜाँच-ਰਿਟੁਅਲ ਹੈ ਜੋ ਤੁਸੀਂ ਸ਼ਿਪ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਚਲਾ ਸਕਦੇ ਹੋ:
ਫੇਲਾਂ ਨੂੰ ਵਰਗਵਾਰ ਟੈਗ ਕਰੋ ਤਾਂ ਕਿ ਪੈਟਰਨ ਨਿਖਰ ਕੇ ਆਣ।
ਇੱਕ ਛੋਟੀ ਟੀਮ ਇੱਕ AI ਅਸਿਸਟੈਂਟ ਸਪੋਰਟ ਵਰਕਫ਼ਲੋ ਵਿੱਚ ਇੱਕ ਫੀਚਰ ਜੋੜਦੀ ਹੈ: ਅਸਿਸਟੈਂਟ ਕੇਸ ਸੰਖੇਪ ਪੜ੍ਹਦਾ, ਜਵਾਬ ਸੁਝਾਉਂਦਾ, ਅਤੇ ਇੱਕ ਅੰਦਰੂਨੀ ਟੂਲ ਨੂੰ ਆਰਡਰ ਸਟੇਟ ਵੇਖਣ ਲਈ ਕਾਲ ਕਰ ਸਕਦਾ ਹੈ। ਡੈਮੋ ਵਿੱਚ ਸਭ ਵਧੀਆ ਲੱਗਦਾ ਹੈ, ਪਰ ਹਕੀਕਤ ਵਿੱਚ ਟਿਕਟ ਗੰਦੇ ਅਤੇ ਅਣਰੈਖਤ ਹੁੰਦੇ ਹਨ — ਯੂਜ਼ਰ ਲੰਬੇ ਥ੍ਰੇਡ, ਸਕਮੀਨ ਆਦਿ ਪੇਸਟ ਕਰਦੇ ਹਨ ਜਾਂ ਟ੍ਰਾਇਕ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਹਨ।
ਉਹਨਾਂ ਨੇ 60 ਸਹੀ ਉਦਾਹਰਣਾਂ ਖਿੱਚ ਕੇ ਇੱਕ ਛੋਟਾ ਇਵੈਲ ਸੈੱਟ ਬਣਾਇਆ ਅਤੇ 20 "ਨਾਸਟੀ" ਪ੍ਰਾਂਪਟ ਜੋੜੇ ਜੋ ਦੁਰਵ੍ਯਵਹਾਰ ਦੀ ਨਕਲ ਕਰਦੇ ਸਨ। ਉਦੇਸ਼ ਸੀਕਵੈਂਸ ਨਹੀਂ — ਇੱਕ ਦੁਹਰਾਊ ਟੈਸਟ ਜੋ ਹਰ ਬਦਲਾਅ ਤੋਂ ਬਾਅਦ ਦੌੜਾਇਆ ਜਾ ਸਕੇ।
ਉਹ ਪ੍ਰਾਂਪਟ ਇੰਜੈਕਸ਼ਨ, ਪ੍ਰਾਈਵੇਟ ਡੇਟਾ ਦੀ ਕੋਸ਼ਿਸ਼, ਟੂਲ ਮਿਸਯੂਜ਼, ਅਸਪਸ਼ਟ ਟਿਕਟਾਂ ਤੇ ਪੁੱਛਤਾਛ ਦੀ ਲੋੜ ਅਤੇ ਨੀਤिगत ਟਕਰਾਅ ਵਰਗੀਆਂ ਚੀਜ਼ਾਂ ਦੇਖਦੇ ਹਨ। ਫਿਰ ਉਹ ਲੂਪ 'ਤੇ ਕੰਮ ਕਰਦੇ ਹਨ: ਸਿਸਟਮ ਪ੍ਰਾਂਪਟ ਕੱਸਦੇ ਹਨ, ਸਧਾਰਨ ਇਨਪੁਟ ਵੈਲਿਡੇਸ਼ਨ ਜੋੜਦੇ ਹਨ, ਅਤੇ ਜੇ ਟੂਲ ਨਤੀਜਾ ਟਿਕਟ ਨਾਲ ਮੇਲ ਨਹੀਂ ਖਾਂਦਾ ਤਾਂ ਪੁੱਛਨਾ ਨਿਯਮ ਬਣਾਉਂਦੇ ਹਨ। ਹਰ ਬਦਲਾਅ ਤੋਂ ਬਾਅਦ ਉਹ ਇਵੈਲ ਚਲਾਉਂਦੇ ਹਨ ਅਤੇ ਰਿਗਰੈਸ਼ਨ ਟਰੈਕ ਕਰਦੇ ਹਨ।
ਇੱਕ ਮਹੀਨੇ ਵਿੱਚ, ਰਿਲੀਜ਼ ਤੇਜ਼ ਹੋ ਜਾਂਦੇ ਹਨ ਕਿਉਂਕਿ ਭਰੋਸਾ ਸਾਫ਼ ਹੋ ਜਾਂਦਾ ਹੈ। ਇਹ ਵਿਰੋਧੀ ਸੋਚ ਦਾ ਅਮਲ ਹੈ: ਬਣਾਉਣ ਵਾਲਾ ਨਤੀਜੇ ਦਿੰਦਾ ਹੈ ਅਤੇ ਟੁੱਟਣ ਵਾਲਾ ਗਾਹਕਾਂ ਦੇ ਵੀਚਾਰ ਤੋਂ ਪਹਿਲਾਂ ਹੀ ਖ਼ਤਰਾ ਲੱਭਦਾ ਹੈ।
ਇੱਕ ਚੰਗਾ ਵਿਰੋਧੀ ਲੂਪ ਜਾਣਬੂਝ ਕਰ ਕੇ ਬੋਰਿੰਗ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਇਹ ਹਫ਼ਤਾਵਾਰੀ ਰਿਦਮ ਵਿੱਚ ਆਉਂਦਾ ਹੈ, ਹਰ ਵਾਰੀ ਇੱਕੋ ਜਿਹਾ ਨਤੀਜਾ ਦਿੰਦਾ ਹੈ, ਅਤੇ ਅਗਲਾ ਬਦਲਾਅ ਸਪਸ਼ਟ ਕਰਦਾ ਹੈ।
ਸ਼ੁਰੂਆਤ ਲਈ:
ਹਫਤਾਵਾਰੀ ਲੂਪ:
ਆਰਟੀਫੈਕਟ ਸੁਰੱਖਿਅਤ ਰੱਖੋ: ਪ੍ਰਾਂਪਟ, ਇਵੈਲ ਕੇਸ, ਕੱਚ ਨਤੀਜੇ, ਤੇ ਜੋ ਫੈਸਲੇ ਲਏ ਗਏ। Koder.ai ਵਰਤੋਂ ਵਾਲੇ ਲਈ, planning mode, ਸਨੇਪਸ਼ਾਟ ਅਤੇ ਰੋਲਬੈਕ ਇਸਨੂੰ ਆਸਾਨ ਬਣਾਉਂਦੇ ਹਨ।
ਜੇ ਤੁਸੀਂ ਇਸ ਹਫ਼ਤੇ ਸਿਰਫ਼ ਇੱਕ ਕੰਮ ਕਰੋ: ਸਕੋਰਿੰਗ ਨਿਯਮ ਲਿਖੋ ਅਤੇ ਆਪਣਾ ਪਹਿਲਾ ਇਵੈਲ ਸੈੱਟ ਲਾਕ ਕਰੋ। ਸਭ ਕੁਝ ਆਸਾਨ ਹੋ ਜਾਵੇगा ਜਦ ਸਾਰੇ ਇਕੋ ਤਰ੍ਹਾਂ ਮੂਲਾਂਕਣ ਕਰਨ।
