KoderKoder.ai
ਕੀਮਤਾਂਐਂਟਰਪ੍ਰਾਈਜ਼ਸਿੱਖਿਆਨਿਵੇਸ਼ਕਾਂ ਲਈ
ਲੌਗ ਇਨਸ਼ੁਰੂ ਕਰੋ

ਉਤਪਾਦ

ਕੀਮਤਾਂਐਂਟਰਪ੍ਰਾਈਜ਼ਨਿਵੇਸ਼ਕਾਂ ਲਈ

ਸਰੋਤ

ਸਾਡੇ ਨਾਲ ਸੰਪਰਕ ਕਰੋਸਹਾਇਤਾਸਿੱਖਿਆਬਲੌਗ

ਕਾਨੂੰਨੀ

ਗੋਪਨੀਯਤਾ ਨੀਤੀਵਰਤੋਂ ਦੀਆਂ ਸ਼ਰਤਾਂਸੁਰੱਖਿਆਸਵੀਕਾਰਯੋਗ ਵਰਤੋਂ ਨੀਤੀਦੁਰਵਰਤੋਂ ਦੀ ਰਿਪੋਰਟ ਕਰੋ

ਸੋਸ਼ਲ

LinkedInTwitter
Koder.ai
ਭਾਸ਼ਾ

© 2026 Koder.ai. ਸਾਰੇ ਅਧਿਕਾਰ ਰਾਖਵੇਂ ਹਨ।

ਹੋਮ›ਬਲੌਗ›ਵਿਰੋਧੀ ਸੋਚ: GANs ਸਾਨੂੰ AI ਐਪ ਲੂਪ ਬਾਰੇ ਕੀ ਸਿਖਾਉਂਦੇ ਹਨ
11 ਨਵੰ 2025·6 ਮਿੰਟ

ਵਿਰੋਧੀ ਸੋਚ: GANs ਸਾਨੂੰ AI ਐਪ ਲੂਪ ਬਾਰੇ ਕੀ ਸਿਖਾਉਂਦੇ ਹਨ

ਵਿਰੋਧੀ ਸੋਚ ਦੱਸਦੀ ਹੈ ਕਿ GANs ਕਿਵੇਂ ਕੰਮ ਕਰਦੇ ਹਨ: ਦੋ ਪ੍ਰਣਾਲੀਆਂ ਇਕ ਦੂਜੇ ਨੂੰ ਸੁਧਾਰਨ ਲਈ ਧੱਕ ਦੇਂਦੀਆਂ ਹਨ। ਜਾਣੋ ਕਿ ਇਸੇ ਲੂਪ ਨੂੰ ਟੈਸਟਿੰਗ, ਸੁਰੱਖਿਆ ਅਤੇ ਪ੍ਰਾਂਪਟ-ਵਿਰੁੱਧ-ਇਵੈਲ ਵਿੱਚ ਕਿਵੇਂ ਲਾਗੂ ਕਰਨਾ ਹੈ।

ਵਿਰੋਧੀ ਸੋਚ: GANs ਸਾਨੂੰ AI ਐਪ ਲੂਪ ਬਾਰੇ ਕੀ ਸਿਖਾਉਂਦੇ ਹਨ

ਸਧਾਰਣ ਵਿਚਾਰ: ਦੋ ਪ੍ਰਣਾਲੀਆਂ ਜੋ ਇਕ ਦੂਜੇ ਨੂੰ ਧੱਕ ਦਿੰਦੀਆਂ ਹਨ

ਵਿਰੋਧੀ ਸੋਚ ਇਕ ਸਧਾਰਣ ਨਮੂਨਾ ਹੈ: ਤੁਸੀਂ ਇੱਕ ਪ੍ਰਣਾਲੀ ਬਣਾਉਂਦੇ ਹੋ ਜੋ ਕੁਝ ਤਿਆਰ ਕਰਦੀ ਹੈ, ਅਤੇ ਦੂਜੀ ਪ੍ਰਣਾਲੀ ਉਸਨੂੰ ਚੈਲੇਂਜ ਕਰਦੀ ਹੈ। ਉਤਪਾਦਕ ਬਿਹਤਰ ਨਤੀਜੇ ਦੇ ਕੇ ਜਿੱਤਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਹੈ। ਚੈਲੈਂਜਰ ਖ਼ਰਾਬੀਆਂ ਲੱਭ ਕੇ ਜਿੱਤਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਹੈ। ਇਸ ਲੂਪ ਨੂੰ ਦੁਹਰਾਉ — ਤੇ ਦੋਹਾਂ ਪਾਸੇ ਸੁਧਰਦੇ ਹਨ।

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

ਮਨ ਵਿੱਚ ਰੱਖੋ: ਇਹ "ਸਿਰਫ਼ ਲੋਕਾਂ ਨੂੰ ਲੜਵਾਉਣ" ਦਾ ਮਾਡਲ ਨਹੀਂ। ਇਹ ਨਿਯਮਤ ਦਬਾਅ ਹੈ ਜਿਸ ਵਿੱਚ ਨਿਯਮ ਸਪਸ਼ਟ ਹੋਣ। ਤੁਸੀਂ ਚਾਹੁੰਦੇ ਹੋ ਕਿ ਚੈਲੈਂਜਰ ਕਾਫ਼ੀ ਕਠਿਨ ਹੋਵੇ ਤਾਂ ਕਿ ਕਮਜ਼ੋਰੀਆਂ ਨਿਕਲ ਕੇ ਆਉਣ, ਪਰ ਇੰਨਾ ਬੇਚੈਨ ਵੀ ਨਾ ਹੋਵੇ ਕਿ ਉਤਪਾਦਕ ਸਮਝ ਨਾ ਪਾਏ ਕਿ ਕੀ ਠੀਕ ਕਰਨਾ ਹੈ।

ਤੁਸੀਂ ਜੋ ਲੂਪ ਚਾਹੁੰਦੇ ਹੋ ਉਹ ਛੋਟਾ ਅਤੇ ਦੁਹਰਾਉਯੋਗ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ:

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

ਇਹਨੂੰ ਹਫ਼ਤਾਵਾਰੀ ਦੌੜਣ ਯੋਗ ਰੱਖੋ। ਟੀਮਾਂ ਅਚਾਨਕਿਆਂ ਤੋਂ ਇਸ ਤਰ੍ਹਾਂ ਬਚਦੀਆਂ ਹਨ: ਭਵਿੱਖ ਬਾਰੇ ਅਨੁਮਾਨ ਲਗਾ ਕੇ ਨਹੀਂ, ਬਲਕਿ ਆਪਣੀ ਪ੍ਰਣਾਲੀ ਨੂੰ ਇੱਕ ਨਹੀਂ ਪਰ ਸਰਗਰਮ ਵਿਰੋਧੀ ਦੇ ਕੇ।

Ian Goodfellow ਅਤੇ GANs ਸਧਾਰਨ ਭਾਸ਼ਾ ਵਿੱਚ

Ian Goodfellow ਨੇ 2014 ਵਿੱਚ Generative Adversarial Networks (GANs) ਪੇਸ਼ ਕੀਤੀਆਂ।

GAN ਦੋ AI ਮਾਡਲ ਹਨ ਜੋ ਮੁਕਾਬਲੇ ਰਾਹੀਂ ਸਿੱਖਦੇ ਹਨ। ਇੱਕ ਕੁਝ ਬਣਾਉਂਦਾ ਹੈ ਜੋ ਅਸਲੀ ਵਗੋਂ ਲੱਗੇ — ਜਿਵੇਂ ਚਿੱਤਰ, ਆਡੀਓ ਜਾਂ ਟੈਕਸਟ। ਦੂਜਾ ਪਤਾ ਲਾਉਂਦਾ ਹੈ ਕਿ ਕੀ ਨਕਲੀ ਹੈ। ਮੁੱਢਲੀ ਧਾਰਣਾ ਸਮਝਣ ਲਈ ਗਣਿਤ ਦੀ ਲੋੜ ਨਹੀਂ: ਦੋਹਾਂ ਮਾਡਲ ਸੁਧਰਦੇ ਹਨ ਕਿਉਂਕਿ ਵਿਰੋਧੀ ਬਿਹਤਰ ਹੁੰਦਾ ਹੈ।

ਭੂਮਿਕਾਵਾਂ ਆਮ ਤੌਰ 'ਤੇ ਹੁੰਦੀਆਂ ਹਨ:

  • Generator: ਨਵੇਂ ਨਮੂਨੇ ਬਣਾਉਂਦਾ ਜੋ ਅਸਲੀ ਲੱਗਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਹਨ।
  • Discriminator: ਹਰ ਨਮੂਨੇ ਨੂੰ "ਅਸਲੀ" ਜਾਂ "ਨਕਲੀ" ਮੰਨਦਾ/ਮੰਨਦੀ ਹੈ।

ਪੂਰਾ ਮਕਸਦ ਫੀਡਬੈਕ ਲੂਪ ਹੈ। ਜਦ discriminator generator ਨੂੰ ਫੜਦਾ ਹੈ, generator ਨੂੰ ਪਤਾ ਲੱਗਦਾ ਹੈ ਕਿ ਕਿਸ ਗਲਤੀ ਕਾਰਨ ਫਸਿਆ। ਜਦ generator discriminator ਨੂੰ ਬੇਫ਼ਿਕਰ ਕਰ ਦਿੰਦਾ ਹੈ, discriminator ਸਿੱਖਦਾ ਹੈ ਕਿ ਉਹ ਕੀ ਨਹੀਂ ਦੇਖ ਰਿਹਾ। ਬਹੁਤ ਸਾਰੇ ਦੌਰਾਂ 'ਤੇ, ਆਸਾਨ ਨਕਲਾਂ ਕੰਮ ਨਹੀਂ ਕਰਦੀਆਂ, ਇਸ ਲਈ generator ਹੋਰ ਹਕੀਕਤੀ ਨਤੀਜਿਆਂ ਵੱਲ ਧੱਕਿਆ ਜਾਂਦਾ ਹੈ।

ਇੱਕ ਸਧਾਰਣ ਉਦਾਹਰਨ ਹੈ ਨਕਲੀ ਕਰੰਸੀ ਬਣਾਉਣ ਵਾਲੇ ਵਿਰੁੱਧ ਮੁਆਇਨੇ ਕਰਨ ਵਾਲੇ: ਨਕਲੀ بنانے ਵਾਲੇ ਨਕਲਾਂ ਬਣਾਉਂਦੇ ਹਨ; ਇੰਸਪੈਕਟਰ ਅਨੇਕ ਛੋਟੇ ਨਿਸ਼ਾਨ ਲੱਭਦੇ ਹਨ। ਜੇ ਇੰਸਪੈਕਟਰ ਸੁਧਰਦੇ ਹਨ ਤਾਂ ਨਕਲੀ ਬਣਾਉਣ ਵਾਲਿਆਂ ਨੂੰ ਵੀ ਸੁਧਾਰਨਾ ਪੈਂਦਾ ਹੈ। ਇਹ ਤਰ੍ਹਾਂ ਦਾ ਦਬਾਅ ਪ੍ਰਗਤੀ ਨੂੰ ਜ਼ਬਰਦਸਤ ਬਣਾਉਂਦਾ ਹੈ।

ਕਿਉਂ ਵਿਰੋਧੀ ਟਰੇਨਿੰਗ ਕੰਮ ਕਰਦੀ ਹੈ (ਅਤੇ ਕਦੋਂ ਫੇਲ ਹੁੰਦੀ ਹੈ)

ਵਿਰੋਧੀ ਸੋਚ ਇਸ ਲਈ ਕੰਮ ਕਰਦੀ ਹੈ ਕਿਉਂਕਿ ਇਹ ਸੁਧਾਰ ਨੂੰ ਇੱਕ ਲੂਪ ਵਿੱਚ ਬਦਲ ਦਿੰਦੀ ਹੈ ਜਿਸ 'ਚ ਬਣਾਇਆ ਗਿਆ ਸਕੋਰ ਮਾਰਗਦਰਸ਼ਨ ਮੁਹੱਈਆ ਕਰਦਾ ਹੈ। ਇੱਕ ਪਾਸੇ ਜਿੱਤਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਹੈ, ਦੂਜਾ ਪਾਸਾ ਨੁਕਸਾਨ ਤੋਂ ਸਿੱਖਦਾ ਹੈ। ਮਹੱਤਵਪੂਰਨ ਗੱਲ ਇਹ ਨਹੀਂ ਕਿ ਦੋ ਮਾਡਲ ਹਨ; ਬਹੁਤ ਜ਼ਰੂਰੀ ਗੱਲ ਇਹ ਹੈ ਕਿ "ਵਧੀਆ" ਕਦਮ-ਦਰ-ਕਦਮ ਮਾਪਿਆ ਜਾਂਦਾ ਹੈ।

ਇੱਕ ਫਾਇਦੇਮੰਦ ਵਿਰੋਧੀ ਪਾਸੇ ਦੀਆਂ ਦੋ ਖ਼ੂਬੀਆਂ ਹੋਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ: ਇੱਕ ਸਪਸ਼ਟ ਮਕਸਦ ਅਤੇ ਲਗਾਤਾਰ ਸਕੋਰਿੰਗ। GANs ਵਿੱਚ, discriminator ਦਾ ਕੰਮ ਸਿਧਾ ਹੁੰਦਾ ਹੈ: ਅਸਲੀ ਤੋਂ ਨਕਲੀ ਨੂੰ ਵੱਖਰਾ ਕਰੋ। ਜਦ ਇਹ ਫੈਸਲਾ ਕਾਫੀ ਸਥਿਰ ਹੋ ਜਾਂਦਾ ਹੈ, generator ਨੂੰ ਇਸ ਗਲਤੀ ਬਾਰੇ ਪ੍ਰਯੋਗਿਕ ਫੀਡਬੈਕ ਮਿਲਦਾ ਹੈ, ਭਾਵੇਂ ਕੋਈ ਸੁਲਝੀ ਹੋਈ ਨਿਯਮ ਨਹੀਂ ਹੋਵੇ।

ਸਕੋਰਿੰਗ ਸਿਗਨਲ ਸੋਫ਼ਿਸਟੀਕੇਟਡ ਆਰਕੀਟੈਕਚਰ ਤੋਂ ਵੱਧ ਮੈਟਰ ਕਰਦਾ ਹੈ। ਜੇ ਜੱਜ ਸ਼ੋਰ ਵਾਲਾ ਹੈ, ਆਸਾਨ ਚਾਲਾਂ ਨਾਲ ਠੱਗਿਆ ਜਾ ਸਕਦਾ ਹੈ, ਜਾਂ ਸਮੇਂ ਦੇ ਨਾਲ ਮਤਲਬ ਬਦਲ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਲਰਨਰ ਬੇਨਤੀ-ਪੱਖ ਨੂੰ ਤੱਕੜੀ ਜਾਂਗੇ। ਜੇ ਜੱਜ ਦੁਹਰਾਏ ਜਾਂ ਸਕਣ ਵਾਲੇ ਨਿਰਦੇਸ਼ ਦਿੰਦਾ ਹੈ, ਤਬ ਸੁਧਾਰ ਵੱਧਦਾ ਚੱਲਦਾ ਹੈ।

ਅਸਥਿਰਤਾ ਅਕਸਰ ਉਸ ਵੇਲੇ ਆਉਂਦੀ ਹੈ ਜਦ ਵਿਰੋਧੀ ਬੁਰੇ ਤੌਰ 'ਤੇ ਸੰਤੁਲਿਤ ਹੁੰਦਾ ਹੈ:

  • ਬਹੁਤ ਕਮਜ਼ੋਰ: ਲਰਨਰ ਤੇਜ਼ੀ ਨਾਲ ਜਿੱਤ ਜਾਂਦਾ ਹੈ ਅਤੇ ਸਿੱਖਣਾ ਰੋਕ ਦਿੰਦਾ ਹੈ।
  • ਬਹੁਤ ਤਗੜਾ: ਲਰਨਰ ਨੂੰ ਕੋਈ ਕਾਰਗਰ ਫੀਡਬੈਕ ਨਹੀਂ ਮਿਲਦਾ।
  • ਚਲਦਾ ਟਾਰਗੇਟ: ਜੱਜ ਲਰਨਰ ਤੋਂ ਤੇਜ਼ੀ ਨਾਲ ਬਦਲਦਾ ਹੈ।
  • ਸੰਕੀਰਨ ਟਾਰਗੇਟ: ਜੱਜ ਇੱਕ ਸ਼ਾਰਟਕੱਟ ਨੂੰ ਇਨਾਮ ਦਿੰਦਾ, ਇਸ ਨਾਲ ਲਰਨਰ ਓਵਰਫਿੱਟ ਹੋ ਜਾਂਦਾ ਹੈ।

ਅਸਲ ਪ੍ਰਗਟੀਤਾ ਇਸ ਗੱਲ ਨਾਲ ਦਿਸਦੀ ਹੈ ਕਿ ਆਸਾਨ ਜਿੱਤਾਂ ਘੱਟ ਹੋ ਰਹੀਆਂ ਹਨ ਅਤੇ ਨੁਕਸਾਨ ਹਨ ਜੋ ਹੁਣ ਨਾਜ਼ੁਕ ਹੋਣ ਜਾਂ ਰੇਅਰ ਏਜ ਕੇਸ ਵਿੱਚ ਆ ਰਹੇ ਹਨ। ਸ਼ੁਰੂ ਵਿੱਚ, ਜੱਜ ਸਪਸ਼ਟ ਗਲਤੀਆਂ ਫੜਦਾ ਹੈ। ਬਾਅਦ ਵਿੱਚ, ਫੇਲ ਨਾਜ਼ੁਕ ਆਰਟੀਫੈਕਟ, ਰੇਅਰ ਏਜ ਕੇਸ, ਜਾਂ ਕੁਝ ਖਾਸ ਇਨਪੁਟ ਹਾਲਤਾਂ 'ਚ ਹੀ ਨਿਕਲਦੇ ਹਨ — ਇਹ ਚੰਗਾ ਸੰਗੇਤ ਹੈ, ਭਾਵੇਂ ਐਹਸਾਸ ਹੋਏ ਤਾਂ ਲਹੂਕਦਰ ਤੇਜ਼ੀ ਘੱਟ ਲੱਗੇ।

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

ਆਮ ਨਮੂਨਾ: ਉਤਪਾਦਕ ਵਿਰੁੱਧ ਨਿਆਂਦੀ (produce vs judge)

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

ਮਹੱਤਵਪੂਰਨ ਗੱਲ ਲੂਪ ਹੈ:

  1. ਨਤੀਜਾ ਪੈਦਾ ਕਰੋ (ਪ੍ਰਿਡਿਕਸ਼ਨ, ਜਵਾਬ, UI ਫ਼ਲੋ, ਰਿਲੀਜ਼ ਕੈਂਡੀਡੇਟ).
  2. ਇਸਨੂੰ ਲਕੜੀ ਦੇ ਤੌਰ 'ਤੇ ਨਿਆਂ ਕਰੋ (ਸਹੀ-ਗਲਤ, ਸੇਫਟੀ, ਅੰਦਾਜ਼, ਲੇਟेंसी, ਦੁਰਵ੍ਯਵਹਾਰ ਰੋਧ).
  3. ਨੁਕਸਾਨਾਂ ਤੋਂ ਸਿੱਖੋ (ਕੋਡ ਠੀਕ ਕਰੋ, ਪ੍ਰਾਂਪਟ ਤਬਦੀਲ ਕਰੋ, ਗਾਰਡਰੇਲ ਜੋੜੋ, ਡੇਟਾ ਅਪਡੇਟ ਕਰੋ).
  4. ਦੁਹਰਾਓ.

ਬਣਾਉਂਦੇ ਸਮੇਂ ਮੰਨ ਕੇ ਚਲੋ ਕਿ ਪਹਿਲੀ ਵਰਜਨ ਨੂੰ ਫਸਾਇਆ, ਦੁਰਵ੍ਯਵਹਾਰ ਕੀਤਾ ਜਾਂ ਗਲਤ ਸਮਝਿਆ ਜਾਵੇਗਾ। ਫਿਰ ਇਹ ਕੇਸ ਤੇਜ਼ੀ ਨਾਲ ਲੱਭਣ ਲਈ ਤਰੀਕਾ ਡਿਜ਼ੈਨ ਕਰੋ।

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

ਤੁਸੀਂ ਇਹੀ ਢਾਂਚਾ ਰੋਜ਼ਮਰ੍ਹਾ ਕੰਮ ਵਿੱਚ ਦੇਖ ਸਕਦੇ ਹੋ: ਯੂਨਿਟ ਟੈਸਟ ਬੱਗਾਂ ਤੋਂ ਬਾਅਦ ਵਧਦੇ ਹਨ, QA ਜੈਦਾ ਏਜ ਕੇਸ ਜੋੜਦਾ ਹੈ, ਧੋਖਾਧੜੀ ਪਤਾ ਲੱਗਣ ਤੇ ਰਣਨੀਤੀ ਬਦਲਦੀ ਹੈ। ਸ਼ੁਰੂ 'ਤੇ ਪ੍ਹੁੰਕਤ ਜੱਜ ਦੀ ਲੋੜ ਨਹੀਂ — ਪਰ ਇੱਕ ਅਜਿਹਾ ਜੱਜ ਚਾਹੀਦਾ ਹੈ ਜੋ ਸਿੱਖਦਾ ਰਹੇ, ਤੇ ਹਰ ਫੇਲ ਨੂੰ ਨਵੇਂ ਚੈੱਕ ਵਿੱਚ ਬਦਲਦਾ ਰਹੇ।

AI-ਨਿਰਮਿਤ ਐਪਸ ਵਿੱਚ ਪ੍ਰਾਂਪਟ ਵਿਰੁੱਧ ਇਵੈਲ ਲੂਪ

ਅਟੇਟ ਗੁਣਵੱਤਾ ਵਾਲੇ ਸੁਰੱਖਿਆ ਟੈਸਟ ਸ਼ਾਮਲ ਕਰੋ
ਸਾਪਤਾਹਿਕ ਰੈਡ-ਟੀਮ ਚੈੱਕਲਿਸਟ ਬਣਾਓ ਅਤੇ ਹਰ ਫੇਲ ਨੂੰ ਦੁਬਾਰਾ ਦੌੜ ਸਕਣ ਵਾਲਾ ਟੈਸਟ ਬਣਾਓ।
ਸ਼ੁਰੂ ਕਰੋ

ਪ੍ਰਾਂਪਟ ਲਿਖਣਾ ਤੇ ਨਤੀਜੇ ਮਾਪਣਾ ਵੱਖ-ਵੱਖ ਕੰਮ ਹਨ। ਪ੍ਰਾਂਪਟ ਤੁਹਾਡਾ ਧਾਰਣਾ ਹੈ ਕਿ ਮਾਡਲ ਨੂੰ ਕਿਵੇਂ ਮਾਰਗਦਰਸ਼ਨ ਕਰਨਾ ਹੈ। ਇੱਕ ਇਵੈਲ ਤੁਹਾਡਾ ਦਲੀਲ ਹੈ ਕਿ ਇਹ ਵੱਖ-ਵੱਖ ਕੇਸਾਂ 'ਤੇ ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ। ਜੇ ਤੁਸੀਂ ਸਿਰਫ਼ ਇੱਕ ਚੰਗੀ ਗੱਲ 'ਤੇ ਭਰੋਸਾ ਕਰੋ, ਤਾਂ ਤੁਸੀਂ ਨਤੀਜੇ ਦੀ ਭਾਵਨਾ ਦੀ ਆਧਾਰ 'ਤੇ ਨਿਆਂ ਕਰ ਰਹੇ ਹੋ, ਨਕੀ ਕਿ ਨਤੀਜਿਆਂ 'ਤੇ।

ਇਕ ਇਵੈਲ ਸੈੱਟ ਛੋਟਾ, ਫਿਕਸਡ ਤੇ ਅਸਲੀ ਵਰਤੋਂ-ਝਲਕ ਵਾਲਾ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਇਸ ਵਿੱਚ ਆਮ ਬੇਨਤੀਆਂ ਅਤੇ ਉਹ ਅਜਿਹੇ ਕੁਝ ਗੰਦੇ ਕੇਸ ਸ਼ਾਮਲ ਹੋਣ ਜੋ ਯੂਜ਼ਰ ਰਾਤ 2 ਵਜੇ ਦੇ ਦੌਰਾਨ ਮਿਲਦੇ ਹਨ। ਇਸਨੂੰ ਛੋਟਾ ਰੱਖੋ ਤਾਂ ਜੋ ਅਕਸਰ ਦੌਰ ਸਕੋ, ਪਰ ਅਸਲ ਹੋਣੇ ਤੱਕ ਮਹੱਤਵਪੂਰਨ ਰਹੇ।

ਅਮਲ ਵਿੱਚ, ਇੱਕ ਵਧੀਆ ਸ਼ੁਰੂਆਤੀ ਇਵੈਲ ਸੈੱਟ ਆਮ ਤੌਰ 'ਤੇ ਸ਼ਾਮਿਲ ਕਰਦਾ ਹੈ: ਆਮ ਯੂਜ਼ਰ ਟਾਸਕ, ਕੁਝ ਗੰਦੇ ਇਨਪੁਟ (ਖਾਲੀ ਫੀਲਡ, ਬੇਤਰਤੀਬ ਫਾਰਮੈਟ, ਅਧੂਰਾ ਡੇਟਾ), ਸੁਰੱਖਿਆ ਦੀਆਂ ਹੱਦਾਂ (ਜਿਹਨਾਂ ਨੂੰ ਮਨਾਹੀ ਕਰਨੀ ਹੈ), ਅਤੇ ਕੁਝ ਮਲਟੀ-ਟਰਨ ਫਾਲੋਅਪਸ ਤਾਕਿ ਲਗਾਤਾਰਤਾ ਅਜ਼ਮਾਈ ਜਾ ਸਕੇ। ਹਰ ਕੇਸ ਲਈ, "ਚੰਗਾ" ਕੀ ਹੈ ਇਹ ਇਕ ਛੋਟੀ ਵਿਆਖਿਆ ਲਿਖੋ ਤਾਂ ਕਿ ਸਕੋਰਿੰਗ ਇਕਸਾਰ ਰਹੇ।

ਫਿਰ ਲੂਪ ਦੌੜਾਓ: ਪ੍ਰਾਂਪਟ ਬਦਲੋ, ਇਵੈਲ ਦੌੜਾਓ, ਨਤੀਜੇ ਤੁਲਨਾ ਕਰੋ, ਰੱਖੋ ਜਾਂ ਵਾਪਸ ਲੈਲੋ। ਵਿਰੋਧੀ ਪੱਖ ਇਹ ਹੈ ਕਿ ਤੁਹਾਡੇ ਇਵੈਲ ਉਹ ਫੇਲ ਕੈਸ ਲੱਭ ਰਹੇ ਹਨ ਜੋ ਬਗੈਰ ਉਹਨਾਂ ਨੂੰ ਤੁਸੀਂ ਨਹੀਂ ਦੇਖਦੇ।

ਰਿਗਰੈਸ਼ਨ ਇੱਕ ਮੁੱਖ ਫਸਲ ਹੋ ਸਕਦਾ ਹੈ। ਇੱਕ ਪ੍ਰਾਂਪਟ ਬਦਲਾਅ ਇਕ ਕੇਸ ਨੂੰ ਠੀਕ ਕਰ ਸਕਦਾ ਹੈ ਪਰ ਚੁਪਚਾਪ ਦੋ ਪੁਰਾਣੇ ਕੇਸ ਗੁਆ ਭਦਾ ਦੇਵੇ। ਇੱਕ ਹੀ ਸੁਧਰੇ ਗੱਲ ਤੇ ਭਰੋਸਾ ਨਾ ਕਰੋ — ਪੂਰੇ ਇਵੈਲ ਸੈੱਟ 'ਤੇ ਸਕੋਰ 'ਤੇ ਭਰੋਸਾ ਕਰੋ।

ਉਦਾਹਰਨ: ਤੁਸੀਂ "ਸੰਖੇਪ ਰਹੋ" ਸ਼ਾਮਿਲ ਕਰਦੇ ਹੋ, ਜਵਾਬ ਤੇਜ਼ ਹੋ ਜਾਂਦੇ ਹਨ। ਪਰ ਇਵੈਲ ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਹੁਣ ਰિફੰਡ ਬੇਨਤੀਆਂ ਵਿੱਚ ਜ਼ਰੂਰੀ ਨੀਤੀ ਟੈਕਸਟ ਛੱਡ ਦਿੱਤਾ ਗਿਆ ਹੈ ਅਤੇ ਜਦ ਯੂਜ਼ਰ ਮਿਡ-ਥ੍ਰੈੱਡ ਵਿੱਚ ਆਪਣਾ ਸਵਾਲ ਸੋਧਦਾ ਹੈ ਤਾਂ ਗਲਤ ਹੋ ਜਾਂਦਾ ਹੈ। ਇਹ ਸਕੋਰਕਾਰਡ ਦੱਸਦਾ ਹੈ ਕਿ ਤੁਹਾਨੂੰ ਕੀ ਅਜਿਹਾ ਬਦਲਨਾ ਹੈ ਅਤੇ ਜੇ ਬਦਲਾਅ ਸਮੁੱਚੇ ਤੌਰ 'ਤੇ ਬੁਰਾ ਕਰ ਰਿਹਾ ਹੈ ਤਾਂ ਵਾਪਸੀ ਦੀ ਵਜਹ ਦਿੰਦਾ ਹੈ।

ਜੇ ਤੁਸੀਂ ਕਿਸੇ ਚੈਟ-ਟੂ-ਐਪ ਪਲੇਟਫਾਰਮ ਜਿਵੇਂ Koder.ai 'ਤੇ ਬਣਾਉਂਦੇ ਹੋ, ਤਾਂ ਪ੍ਰਾਂਪਟ ਵਰਜਨਾਂ ਨੂੰ ਰਿਲੀਜ਼ ਵਾਂਗ ਮਾਣੋ: ਜੋ ਚੰਗਾ ਕੰਮ ਕਰ ਰਿਹਾ ਹੈ ਉਸ ਦਾ ਸਨੇਪਸ਼ਾਟ ਲਵੋ, ਇਵੈਲ ਦੌੜਾਓ, ਅਤੇ ਉਨ੍ਹਾਂ ਹੀ ਬਦਲਾਵਾਂ ਨੂੰ ਉਨ੍ਹਾਂ ਹੀ ਹਾਲਤਾਂ 'ਚ ਪ੍ਰਮੋਟ ਕਰੋ ਜਦ ਉਹ ਸਕੋਰ ਸੁਧਾਰਦੇ ਹਨ ਬਿਨਾਂ ਪੁਰਾਣੇ ਕੇਸ ਟੁੱਟਣ ਦੇ।

ਸੁਰੱਖਿਆ ਇੱਕ ਵਿਰੋਧੀ ਲੂਪ ਵਜੋਂ (ਰੈਡ ਟੀਮ ਵਿਰੁੱਧ ਬਲੂ ਟੀਮ)

ਸੁਰੱਖਿਆ ਤੇਜ਼ੀ ਨਾਲ ਸੁਧਰਦੀ ਹੈ ਜਦ ਤੁਸੀਂ ਇਸਨੂੰ ਇੱਕ ਲੂਪ ਵਾਂਗ ਸਮਝਦੇ ਹੋ। ਇੱਕ ਪਾਸਾ ਸਿਸਟਮ ਨੂੰ ਤੋੜਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਹੈ, ਦੂਜਾ ਉਸਨੂੰ ਠੀਕ ਕਰਦਾ ਹੈ, ਅਤੇ ਹਰ ਟੁੱਟਣ ਨੂੰ ਐਗਲ ਵਜੋਂ ਆਉਣ ਵਾਲੇ ਹਫ਼ਤੇ ਦੇ ਟੈਸਟ ਵਿਚ ਸ਼ਾਮਿਲ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਇੱਕ ਵਾਰੀ ਦਾ ਚੈੱਕਲਿਸਟ ਮਦਦ ਕਰਦਾ ਹੈ, ਪਰ ਉਹ ਅਸਲ ਹਮਲਿਆਂ ਦੀ ਸਿਰਜਣਾ ਹਿਸੇ ਨੂੰ ਨਹੀਂ ਕਵਰ ਕਰਦਾ।

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

ਹੱਕੀਕਤ ਵਿੱਚ ਹਮਲਾਵਰ ਕੌਣ ਹੈ?

ਜ਼ਿਆਦਾਤਰ ਮੁੱਦੇ ਤਿੰਨ ਪ੍ਰੋਫ਼ਾਈਲਾਂ ਤੋਂ ਆਉਂਦੇ ਹਨ: ਉਤਸੁਕ ਯੂਜ਼ਰ ਜੋ ਅਜੀਬ ਇਨਪੁਟ ਟੈਸਟ ਕਰਦੇ ਹਨ, ਮਾਲਿਸ਼ਸ ਯੂਜ਼ਰ ਜੋ ਡੇਟਾ ਜਾਂ ਵਿਘਨ ਚਾਹੁੰਦੇ ਹਨ, ਅਤੇ ਅੰਦਰੂਨੀ ਲੋਕ (ਜਾਂ_compromised accounts_) ਜਿਨ੍ਹਾਂ ਕੋਲ ਪਹਿਲਾਂ ਹੀ ਕੁਝ ਪਹੁੰਚ ਹੈ।

ਹਰ ਪ੍ਰੋਫ਼ਾਈਲ ਵੱਖ-ਵੱਖ ਕਮਜ਼ੋਰੀਆਂ 'ਤੇ ਧੱਕਾ ਮਾਰਦਾ ਹੈ। ਉਤਸੁਕ ਯੂਜ਼ਰ ਤੀਖੀਆਂ ਧਾਰਾਂ ਲੱਭਦੇ ਹਨ। ਡੁੱਸਣ ਵਾਲੇ ਵਰਤੋਂਕਾਰ ਦੁਹਰਾਏ ਜਾ ਸਕਣੇ ਰਸਤੇ ਲੱਭਦੇ ਹਨ। ਅੰਦਰੂਨੀ ਜਾਂ ਸਮਝੋਤੇ ਵਾਲੇ ਖਾਤੇ ਜਾਂਚਦੇ ਹਨ ਕਿ ਕੀ ਤੁਹਾਡੀ ਪਰਮੀਸ਼ਨ ਅਤੇ ਆਡੀਟ ਟਰੇਲ ਹਕੀਕਤੀ ਹਨ ਜਾਂ ਸਿਰਫ਼ ਨਜ਼ਰੀਅਤ।

ਉਹ ਆਮ ਤੌਰ 'ਤੇ ਕਿਸਨੂੰ ਨਿਸ਼ਾਨਾ ਬਣਾਉਂਦੇ ਹਨ

AI ਐਪਸ ਵਿੱਚ ਟਾਰਗਟ ਆਮ ਤੌਰ 'ਤੇ ਪ੍ਰਿਡੈਕਟੇਬਲ ਹਨ: ਡੇਟਾ ਲੀਕੇਜ (ਸਿਸਟਮ ਪ੍ਰਾਂਪਟ, ਨਿੱਜੀ ਡੌਕਸ, ਯੂਜ਼ਰ ਜਾਣਕਾਰੀ), ਅਸੁਰੱਖਿਅਤ ਕਾਰਵਾਈਆਂ (ਟੂਲ ਕਾਲਾਂ ਜੋ ਮਿਟਾਉਂਦੀਆਂ, ਭੇਜਦੀਆਂ ਜਾਂ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰਦੀਆਂ ਹਨ), ਅਤੇ ਪ੍ਰਾਂਪਟ ਇੰਜੈਕਸ਼ਨ (ਮਾਡਲ ਨੂੰ ਨਿਯਮਾਂ ਉਠਾਉਣ ਜਾਂ ਟੂਲਾਂ ਮਿਸਯੂਜ਼ ਕਰਨ ਲਈ ਮਿਲਾਉਣਾ)।

ਹਮਲਿਆਂ ਨੂੰ ਦੁਹਰਾਉਣਯੋਗ ਟੈਸਟਾਂ ਵਿੱਚ ਬਦਲਣ ਲਈ, ਉਹਨਾਂ ਨੂੰ ਵੁੱਧ-ਵਿਸ਼ੇਸ਼ ਪਰਿਸਥਿਤੀਆਂ ਵਜੋਂ ਲਿਖੋ ਜਿਸ ਵਿੱਚ ਇੱਕ ਉਮੀਦ ਰਿਪਲਾਈ ਵੀ ਦਰਜ ਹੋਵੇ, ਫਿਰ ਜਦੋਂ ਤੁਸੀਂ ਪ੍ਰਾਂਪਟ, ਟੂਲ ਜਾਂ ਮਾਡਲ ਸੈਟਿੰਗਸ ਬਦਲਦੇ ਹੋ ਤਾਂ ਇਨ੍ਹਾਂ ਨੂੰ ਮੁੜ ਚਲਾਓ। ਇਨ੍ਹਾਂ ਨੂੰ ਰਿਗਰੈਸ਼ਨ ਟੈਸਟ ਸਮਝੋ, ਨਾ ਕਿ ਜੰਗ ਦੀਆਂ ਕਹਾਣੀਆਂ।

ਸਰਲ ਸ਼ੁਰੂਆਤੀ ਸੈੱਟ ਵਿੱਚ ਸ਼ਾਮਲ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ: ਦਿੱਤੇ ਹੋਏ ਨਿਰਦੇਸ਼ਾਂ ਨੂੰ ਕੱਢਣ ਦੀ ਕੋਸ਼ਿਸ਼ਾਂ, ਪੇਸਟ ਕੀਤੇ ਸਮੱਗਰੀ ਦੁਆਰਾ ਪ੍ਰਾਂਪਟ ਇੰਜੈਕਸ਼ਨ (ਈ-ਮੇਲ, ਟਿਕਟ, HTML), ਯੂਜ਼ਰ ਦੇ ਰੋਲ ਤੋਂ ਬਾਹਰ ਟੂਲ ਦੁਰਵ੍ਯਵਹਾਰ, ਡਾਟਾ ਸੀਮਾਵਾਂ ਪਾਰ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ਾਂ, ਅਤੇ ਬਹੁਤ ਲੰਬੇ ਇਨਪੁਟ ਜਾਂ ਦੁਹਰਾਈ ਕਾਲਾਂ ਵਰਗੇ ਇਨਕਾਰ ਪੈਟਰਨ।

ਮਕਸਦ ਸ parfait ਨਹੀਂ ਹੈ; ਮਕਸਦ ਹੈ ਫੇਲ ਦੀ ਲਾਗਤ ਵਧਾਉਣਾ ਅਤੇ ਨੁਕਸਾਨ ਖੇਤਰ ਘਟਾਉਣਾ: least-privilege ਟੂਲ ਪਹੁੰਚ, ਸਕੋਪਡ ਡਾਟਾ ਰੀਟਰਾਈਵਲ, ਮਜ਼ਬੂਤ ਲੋਗਿੰਗ, ਅਤੇ ਜਦ ਮਾਡਲ ਉਂਝ ਅਣਿਸ਼ਚਿਤ ਹੋਵੇ ਤਾਂ ਸੁਰੱਖਿਅਤ ਵੈਕਾਰਲਬੈਕ।

ਕਦਮ-ਦਰ-ਕਦਮ: ਆਪਣਾ ਖੁਦ ਦਾ ਵਿਰੋਧੀ ਸੁਧਾਰ ਲੂਪ ਬਣਾਓ

ਬਣਾਓ ਅਤੇ ਕ੍ਰੈਡਿਟ ਕਮਾਓ
Koder.ai 'ਤੇ ਜੋ ਤੁਸੀਂ ਬਣਾਉਂਦੇ ਹੋ ਸਾਂਝਾ ਕਰੋ ਅਤੇ ਆਪਣੀ ਐਪ 'ਤੇ ਅੱਗੇ ਜਾਰੀ ਰੱਖਣ ਲਈ ਕ੍ਰੈਡਿਟ ਜਤ੍ਹੇ ਕਰੋ।
ਕ੍ਰੈਡਿਟ ਜਮ੍ਹਾਂ ਕਰੋ

ਪਹਿਲਾਂ ਇੱਕ ਛੋਟਾ, ਅਸਲੀ ਵਰਕਫ਼ਲੋ ਚੁਣੋ ਜਿਸਨੂੰ ਤੁਸੀਂ ਪਹਿਲਾਂ ਮਜ਼ਬੂਤ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ। ਸਭ ਕੁਝ ਇਕੱਠੇ ਠੀਕ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਨ ਨਾਲ ਨਿਰਾਕਾਰ ਨੋਟਸ ਬਣਦੀਆਂ ਹਨ। ਚੰਗੇ ਸ਼ੁਰੂਆਤੀ ਕਾਰਵਾਈਆਂ ਹਨ: "ਸਪੋਰਟ ਟਿਕਟ ਦਾ ਖ਼ੁਲਾਸਾ" ਜਾਂ "ਸਾਈਨਅੱਪ ਈਮੇਲ ਤਿਆਰ ਕਰੋ" ਜਿਵੇਂ ਸਧਾਰਣ ਕਾਰਵਾਈਆਂ।

ਅਗਲਾ, ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ ਲਿਖੋ ਕਿ "ਚੰਗਾ" ਅਤੇ "ਖ਼ਰਾਬ" ਦਾ ਕੀ ਮਤਲਬ ਹੈ। ਸਪਸ਼ਟ ਹੋਵੋ ਕਿ ਕੀ ਮਨਾਹੀ ਹੈ। ਉਦਾਹਰਨ ਲਈ: ਜਵਾਬ ਅੰਗ੍ਰੇਜ਼ੀ ਵਿੱਚ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਕੀਮਤਾਂ ਨਾਂ ਬਣਾ ਸਕੇ, ਯੂਜ਼ਰ ਦੇ ਇਨਪੁਟ ਸਹੀ ਤਰੀਕੇ ਨਾਲ ਵਰਤੇ ਜਾਣ, ਅਤੇ ਅਸੁਰੱਖਿਅਤ ਬੇਨਤੀਆਂ ਨੂੰ ਮਨ੍ਹਾਂ ਕਰਨਾ ਆਦਿ।

ਇੱਕ ਸਰਲ ਲੂਪ ਜੋ ਤੁਸੀਂ ਇਕ ਦਿਨ ਵਿੱਚ ਚਲਾ ਸਕਦੇ ਹੋ:

  • ਇੱਕ ਵਰਕਫ਼ਲੋ ਅਤੇ ਇੱਕ ਨਿਸ਼ਾਨਾ ਨਤੀਜੇ ਚੁਣੋ।
  • ਜਲਦੀ ਜਾਂਚਣ ਯੋਗ ਪਾਸ/ਫੇਲ ਨਿਯਮ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ (ਫਾਰਮੈਟ, ਸੁਰੱਖਿਆ, ਸਹੀਤਾ)।
  • 20–50 ਹਕੀਕਤੀ ਕੇਸ ਇਕੱਠੇ ਕਰੋ, ਅਸ਼ੁਭ ਏਜ ਕੇਸ ਅਤੇ "ਨਾਸਟੀ" ਪ੍ਰਾਂਪਟ ਸ਼ਾਮਿਲ ਕਰੋ।
  • ਉਨਾਂ ਨੂੰ ਦੌੜਾਓ, ਨਤੀਜੇ ਇਕਸਾਰ ਤਰੀਕੇ ਨਾਲ ਸਕੋਰ ਕਰੋ, ਅਤੇ ਹਰ ਦੌਰ 'ਤੇ ਫੇਲਾਂ ਨੂੰ ਇੱਕੋ ਹੀ ਤਰੀਕੇ ਨਾਲ ਲੇਬਲ ਕਰੋ।
  • ਇੱਕ ਛੋਟਾ, ਨਿਸ਼ਾਨਾ ਬਦਲਾਅ ਕਰੋ (ਪ੍ਰਾਂਪਟ, ਟੂਲ ਪਰਮੀਸ਼ਨ, ਵੈਲਿਡੇਸ਼ਨ, ਜਾਂ UI ਗਾਰਡਰੇਲ)।

ਹੁਣ ਉਨ੍ਹਾਂ ਹੀ ਟੈਸਟਾਂ ਨੂੰ ਮੁੜ ਚਲਾਓ। ਜੇ ਸਕੋਰ ਨਹੀਂ ਵਧਦਾ, ਤਾਂ ਤੁਹਾਡਾ ਬਦਲਾਅ ਬਹੁਤ ਵਿਆਪਕ, ਕਮਜ਼ੋਰ, ਜਾਂ ਗਲਤ ਟਾਈਪ ਦੀ ਫੇਲ ਨੂੰ ਨਿਸ਼ਾਨਾ ਬਣਾਉਂਦਾ ਹੈ।

ਸਿਰਫ਼ ਜਦ ਤੁਸੀਂ ਸੁਧਾਰ ਦੇਖੋ ਤਾਂ ਹੀ ਮੁਸ਼ਕਿਲ ਕੇਸ ਜੋੜੋ। ਇੱਕ ਛੋਟੀ "ਅਟੈਕ ਡਾਇਰੀ" ਰੱਖੋ ਨਵੇਂ ਫੇਲ ਪੈਟਰਨਾਂ ਲਈ — ਜਿਵੇਂ ਇੰਜੈਕਸ਼ਨ ਕੋਸ਼ਿਸ਼ਾਂ, ਗੁੰਝਲਦਾਰ ਮਲਟੀ-ਸਟੈਪ ਬੇਨਤੀਆਂ, ਜਾਂ ਖ਼ਾਲੀ ਫੀਲਡ ਵਾਲੇ ਇਨਪੁਟ।

ਜੇ ਤੁਸੀਂ Koder.ai ਨਾਲ ਬਣਾਉਂਦੇ ਹੋ, ਤਾਂ ਪ੍ਰਾਂਪਟਾਂ, ਟੂਲ ਪਹੁੰਚ, ਅਤੇ ਆਉਟਪੁੱਟ ਚੈਕ ਉਸ ਐਪ ਨਾਲ ਵਰਜਨ ਕੀਤੇ ਜਾ ਸਕਦੇ ਹਨ। ਮਕਸਦ ਕੋਈ ਬੇ-ਦੋਸ਼ ਮਾਡਲ ਨਹੀਂ; ਮਕਸਦ ਇੱਕ ਐਸੇ ਲੂਪ ਦਾ ਹੋਣਾ ਹੈ ਜੋ ਤੁਹਾਡੀ ਟੀਮ ਹਰ ਹਫ਼ਤੇ ਚਲਾ ਸਕੇ ਅਤੇ ਫੇਲਾਂ ਨੂੰ ਘੱਟ ਤੇ ਅਸਾਨੀ ਨਾਲ ਪਛਾਣ ਸਕੇ।

ਲੂਪ ਨੂੰ ਬੇਕਾਰ ਬਣਾਉਣ ਵਾਲੀਆਂ ਆਮ ਗਲਤੀਆਂ

ਲੂਪਾਂ ਨੂੰ ਇੱਕ ਐਪ ਬਣਾਓ
ਚੈਟ ਵਿੱਚ ਇੱਕ AI ਵਰਕਫ਼ਲੋ ਬਨਾਓ, ਫਿਰ ਸਨੇਪਸ਼ਾਟ ਅਤੇ ਰੋਲਬੈਕ ਨਾਲ ਜਦੋਂ ਟੈਸਟ ਫੇਲ ਹੋਣ ਤਾਂ ਦੁਬਾਰਾ ਸੋਧੋ।
ਮੁਫ਼ਤ ਕੋਸ਼ਿਸ਼ ਕਰੋ

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

ਇੱਕ ਗਲਤ ਫੈਸਲਾ ਹੈ ਖੁਸ਼-ਰਾਹ ਟੈਸਟਿੰਗ ਨੂੰ ਇਵੈਲ ਕਹਿ ਦੇਣਾ। ਜੇ ਟੈਸਟ ਸਿਰਫ਼ ਨਮ੍ਰ ਇਨਪੁਟ, ਸਾਫ़ ਡੇਟਾ, ਅਤੇ ਪੂਰੇ ਨੈੱਟਵਰਕ ਨਾਲ ਚੱਲਣ ਵਾਲੀ ਪ੍ਰਸਥਿਤੀ ਨੂੰ ਕਵਰ ਕਰਦੇ ਹਨ, ਤਾਂ ਤੁਸੀਂ ਡੈਮੋ ਮਾਪ ਰਹੇ ਹੋ, ਪ੍ਰੋਡਕਟ ਨਹੀਂ। ਇੱਕ ਵਰਤੋਂਯੋਗ ਜੱਜ ਵਿੱਚ ਗੰਦਾ ਉਪਭੋਗਤਾ ਬਣਤਰ, ਏਜ ਕੇਸ, ਅਤੇ ਪਿਛਲੇ ਸਮੇਂ ਦੀਆਂ ਸਪੋਰਟ ਟਿਕਟਾਂ ਤੋਂ ਆਏ ਇਨਪੁਟ ਸ਼ਾਮਿਲ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ।

ਹੋਰ ਸਮੱਸਿਆ ਹੈ ਬਦਲਾਵਾਂ ਨੂੰ ਟਰੈਕ ਨਾ ਕਰਨਾ। ਜਦ ਨਤੀਜੇ ਡਰਿਫਟ ਹੋ ਜਾਂਦੇ ਹਨ, ਤਾਂ ਕਿਸੇ ਨੂੰ ਪਤਾ ਨਹੀਂ ਹੁੰਦਾ ਕਿ ਇਹ ਪ੍ਰਾਂਪਟ ਟਵੀਕ, ਮਾਡਲ ਬਦਲਾਅ, ਨੀਤੀ ਅਪਡੇਟ, ਜਾਂ ਡੇਟਾ ਅਪਡੇਟ ਕਾਰਨ ਸੀ। ਸਧਾਰਨ ਵਰਜਨ ਨੋਟਸ (ਪ੍ਰਾਂਪਟ v12, ਟੂਲ ਸਕੀਮਾ v3, ਇવੈਲ ਸੈੱਟ v5) ਘੰਟਿਆਂ ਦੀ ਅਣਜਾਣੀ ਘਟਾਉਂਦੀਆਂ ਹਨ।

ਲੂਪ ਓਸ ਵੇਲੇ ਵੀ ਢਾਹ ਜਾਂਦਾ ਹੈ ਜਦ ਨਿਆਂਕਰ ਅਸਪਸ਼ਟ ਹੋ। "ਚੰਗਾ ਲੱਗਦਾ ਹੈ" ਕੋਈ ਨਿਯਮ ਨਹੀਂ। ਤੁਹਾਡੇ ਜੱਜ ਨੂੰ ਪਾਸ/ਫੇਲ ਸ਼ਰਤਾਂ ਦੀ ਲੋੜ ਹੈ, ਭਾਵੇਂ ਉਹ ਮੂਲ ਹੋਣ: ਨੀਤੀ ਦੀ ਪਾਲਣਾ, ਸਹੀ ਫੀਲਡ ਦਾ ਹਵਾਲਾ, ਅਸੁਰੱਖਿਅਤ ਬੇਨਤੀਆਂ ਨੂੰ ਮਨਾਂ ਕਰਨਾ, ਜਾਂ ਸਹੀ ਸੰਰਚਿਤ ਆਉਟਪੁੱਟ।

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

ਰੋਲਬੈਕ ਪੁਆਇੰਟ ਵੀ ਮਹੱਤਵਪੂਰਨ ਹੈ। ਜੇ ਨਵਾਂ ਪ੍ਰਾਂਪਟ ਜਾਂ ਟੂਲ ਬਦਲਾਅ ਸ਼ੁੱਕਰਵਾਰ ਰਾਤ ਨੂੰ ਐਰਰਾਂ ਵਧਾ ਦੇਵੇ, ਤਾਂ ਤੁਹਾਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਵਾਪਸੀ ਦਾ ਰਸਤਾ ਚਾਹੀਦਾ ਹੈ।

ਸ਼ਿਪ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਟੀਮਾਂ ਲਈ ਤੇਜ਼ ਜਾਂਚਾਂ

ਵਿਰੋਧੀ ਸੋਚ ਦਾ ਮਕਸਦ ਦੁਹਰਾਏ ਜਾ ਸਕਣ ਵਾਲੀ ਪ੍ਰਕਿਰਿਆ ਹੈ। ਜੱਜ ਮੌਜੂਦਾ ਰਹੇ ਭਾਵੇਂ ਉਤਪਾਦਕ ਬਦਲੇ।

ਪਹਿਲਾਂ-ਸ਼ਿਪ ਰਿਵਾਇਲ:

  • ਇੱਕ ਫਿਕਸਡ ਇਵੈਲ ਸੈੱਟ ਰੱਖੋ ਜੋ ਤੁਸੀਂ ਕਿਸੇ ਵੀ ਵੇਲੇ ਦੌੜਾ ਸਕੋ।
  • ਫੇਲਾਂ ਨੂੰ ਦੁਹਰਾਓਗਯੋਗ ਬਣਾਓ (ਕੋਈ ਵੀ ਸਾਥੀ ਇੱਕ ਫੇਲਿੰਗ ਕੇਸ 5 ਮਿੰਟ 'ਚ ਦੁਬਾਰਾ ਚਲਾ ਸਕੇ)।
  • ਹਰ ਮੁੱਖ ਵਰਕਫ਼ਲੋ ਲਈ ਘੱਟੋ-ਘੱਟ ਇੱਕ ਵਿਰੋਧੀ ਟੈਸਟ ਸ਼ਾਮਿਲ ਕਰੋ।
  • ਆਪਣੀ ਐਪ ਦੀ ਸਭ ਤੋਂ ਉੱਚ-ਖਤਰਨਾਕ ਕਾਰਵਾਈ ਨਾਂਮ ਕਰੋ (ਈਮੇਲ ਭੇਜਣਾ, ਡੇਟਾ ਬਦਲਣਾ, ਖਰੀਦ) ਅਤੇ ਉਸ ਰਾਹ ਨੂੰ ਖ਼ਾਸ ਵਜੋਂ ਤ behandeld ਕਰੋ।
  • ਤੇਜ਼ੀ ਨਾਲ ਰੋਲਬੈਕ ਕਰਨ ਯੋਗ ਹੋਵੋ।

ਫੇਲਾਂ ਨੂੰ ਸ਼੍ਰੇਣੀਬੱਧ ਕਰੋ ਤਾਂ ਕਿ ਪੈਟਰਨ ਨਜ਼ਰ ਆਉਣ: ਸਹੀਤਾ, ਸੁਰੱਖਿਆ, ਨੀਤੀ ਪਾਲਣਾ, ਅਤੇ ਸਧਾਰਨ UX ਸਮੱਸਿਆਵਾਂ। ਜੇ ਤੁਹਾਡਾ ਅਸਿਸਟੈਂਟ ਰਿਫੰਡ ਨਿਯਮ ਬਣਾਂਦਾ ਹੈ, ਤਾਂ ਇਹ ਸਿਰਫ਼ "ਸਹੀਤਾ" ਸਮੱਸਿਆ ਨਹੀਂ — ਇਹ ਨੀਤੀ ਅਤੇ ਭਰੋਸੇ ਦੀ ਸਮੱਸਿਆ ਹੈ, ਅਤੇ ਇਸਨੂੰ ਉਸ ਤਰ੍ਹਾਂ ਟਰੈਕ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ।

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

ਸਧਾਰਣ ਸ਼ਬਦਾਂ ਵਿੱਚ "ਵਿਰੋਧੀ ਸੋਚ" ਦਾ ਕੀ ਅਰਥ ਹੈ?

ਵਿਰੋਧੀ ਸੋਚ ਇੱਕ ਦੁਹਰਾਊ ਲੂਪ ਹੈ ਜਿਥੇ ਇੱਕ ਪ੍ਰਣਾਲੀ ਉਤਪਾਦ ਦਿੰਦੀ ਹੈ ਅਤੇ ਦੂਜੀ ਪ੍ਰਣਾਲੀ ਉਸਨੂੰ ਟੋੜਨ ਜਾਂ ਮੂਲਾਂਕਣ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੀ ਹੈ। ਫਾਇਦਾ ਟਕਰਾਅ ਨਹੀਂ — ਇਹ ਐਸਾ ਫੀਡਬੈਕ ਹੈ ਜਿਸ 'ਤੇ ਤੁਸੀਂ ਕੰਮ ਕਰ ਸਕਦੇ ਹੋ।

ਇੱਕ ਵਰਤੋਂਯੋਗ ਲੂਪ ਹੁੰਦਾ ਹੈ: ਪਾਸ ਮਿਆਰ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ → ਉਤਪਾਦ ਬਣਾਓ → ਹਕੀਕਤੀ ਨੁਕਸਾਨਾਂ ਨਾਲ ਹਮਲਾ ਕਰੋ → ਠੀਕ ਕਰੋ → ਨਿਯਮਤ ਤੌਰ 'ਤੇ ਦੁਹਰਾ ਕਰੋ।

GANs ਅਸਲ ਵਿੱਚ ਕਿਵੇਂ ਕੰਮ ਕਰਦੇ ਹਨ, ਅਤੇ ਇਹ ਉਦਾਹਰਣ ਕਿਉਂ ਲਾਭਦਾਇਕ ਹੈ?

ਇੱਕ GAN ਵਿੱਚ, ਜਨਰੇਟਰ ਨਮੂਨੇ ਬਣਾਉਂਦਾ ਹੈ ਜੋ ਅਸਲੀ ਲੱਗਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਹਨ, ਅਤੇ ਡਿਸਕ੍ਰਿਮਿਨੇਟਰ "ਅਸਲੀ" ਅਤੇ "ਨਕਲੀ" ਵਿਚਕਾਰ ਫ਼ਰਕ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਹੈ। ਹਰ ਪਾਸਾ ਇਸ ਕਰਕੇ ਸੁਧਰਦਾ ਹੈ ਕਿ ਦੂਜਾ ਪਾਸਾ ਮੁਸ਼ਕਲ ਹੋ ਜਾਂਦਾ ਹੈ।

ਤੁਸੀਂ ਇਸ ਨਮੂਨੇ ਨੂੰ ਗਣਿਤ ਤੋਂ ਬਿਨਾਂ ਵੀ ਲੈ ਸਕਦੇ ਹੋ: ਇੱਕ ਉਤਪਾਦਕ ਬਣਾਓ, ਇਕ ਜੱਜ ਬਣਾਓ, ਅਤੇ ਤਕਰਾਰ ਤੱਕ ਦੌਰ ਲਗਾਉ ਜਦ ਤੱਕ ਨੁਕਸਾਨ ਘੱਟ ਨਾ ਹੋਣ ਲੱਗੇ।

ਮੈਂ ਕਿਸ ਤਰ੍ਹਾਂ ਪਤਾ ਲਗਾਉਂ ਕਿ ਮੇਰਾ "ਜੱਜ" ਬਹੁਤ ਕਮਜ਼ੋਰ ਜਾਂ ਬਹੁਤ ਤਗੜਾ ਹੈ?

ਸਪਸ਼ਟ ਲੱਛਣਾਂ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ:

  • ਬਹੁਤ ਕਮਜ਼ੋਰ: ਜੱਜ ਨਰਮੇ ਨਤੀਜੇ ਪਾਸ ਕਰ ਦਿੰਦਾ ਹੈ, ਤਾਂ ਉਤਪਾਦਕ ਛੋਟੀਆਂ ਚਾਲਾਂ ਹੀ ਸਿੱਖ ਲੈਂਦਾ ਹੈ।
  • ਬਹੁਤ ਤਗੜਾ: ਸਭ ਕੁਝ ਫੇਲ ਹੋ ਜਾਂਦਾ ਹੈ ਅਤੇ ਉਤਪਾਦਕ ਨੂੰ ਸਮਝ ਨਹੀਂ ਆਉਂਦੀ ਕਿ ਕੀ ਠੀਕ ਕਰਨਾ ਹੈ।
  • ਚਲਦਾ ਟਾਰਗੇਟ: ਸਕੋਰਿੰਗ ਬਹੁਤ ਤੇਜ਼ੀ ਨਾਲ ਬਦਲਦੀ ਹੈ, ਇਸ ਲਈ ਸੁਧਾਰ ਟਿਕਦੇ ਨਹੀਂ।
  • ਛੋਟਾ ਟਾਰਗੇਟ: ਜੱਜ ਇੱਕ ਸ਼ਾਰਟਕੱਟ ਨੂੰ ਇਨਾਮ ਦਿੰਦਾ ਹੈ, ਜਿਸ ਨਾਲ ਉਤਪਾਦਕ ਓਵਰਫਿੱਟ ਹੋ ਜਾਂਦਾ ਹੈ।

ਸੁਧਾਰ ਕਰਨ ਲਈ ਪਾਸ/ਫੇਲ ਨਿਯਮਾਂ ਨੂੰ ਸਪਸ਼ਟ ਕਰੋ, ਵੱਖ-ਵੱਖ ਕੇਸ ਜੋੜੋ, ਅਤੇ ਦੌਰਾਂ ਦੇ ਦਰਮਿਆਨ ਨਿੱਜੀ ਰੂਪ ਨਾਲ ਜੱਜ ਨੂੰ ਸਥਿਰ ਰੱਖੋ।

AI ਫੀਚਰ ਲਈ ਇੱਕ ਚੰਗੇ ਇਵੈਲ ਸੈੱਟ ਵਿੱਚ ਕੀ-ਕੀ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ?

ਥੋੜ੍ਹਾ ਛੋਟਾ, ਫਿਕਸਡ ਸੈੱਟ ਵਰਤੋ ਜੋ ਤੁਸੀਂ ਅਕਸਰ ਦੌੜਾ ਸਕੋ (ਹਫਤਾਵਾਰੀ ਜਾਂ ਹਰ ਬਦਲਾਅ 'ਤੇ)। ਇੱਕ ਮਜ਼ਬੂਤ ਸ਼ੁਰੂਆਤੀ ਸੈੱਟ ਵਿੱਚ ਸ਼ਾਮਲ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ:

  • ਆਮ ਯੂਜ਼ਰ ਬੇਨਤੀਆਂ
  • ਗੰਦੇ ਇਨਪੁਟ (ਖਾਲੀ ਫੀਲਡ, ਵੱਖ-ਵੱਖ ਫਾਰਮੈਟ, ਅਧੂਰਾ ਡੇਟਾ)
  • ਸੁਰੱਖਿਆ ਹੱਦਾਂ (ਜਿਹਨੂੰ ਤੁਹਾਨੂੰ ਮਨਾਹੀ ਕਰਨੀ ਹੈ)
  • ਕੁਝ ਮਲਟੀ-ਟਰਨ ਫਾਲੋਅਪਸ (ਸੁਚਿੱਤਤਾ ਦੇ ਲਈ)

ਇਨ੍ਹਾਂ ਨੂੰ 20–50 ਕੇਸ ਤੱਕ ਰੱਖੋ ਤਾਂ ਕਿ ਤੁਸੀਂ ਵਾਕਈ ਹੀ ਇਹ ਰੀਰਨ ਕਰ ਸਕੋ।

ਕਿਉਂ "ਪ੍ਰਾਂਪਟਿੰਗ" ਨੂੰ "ਇਵੈਲੂਏਸ਼ਨ" ਨਹੀਂ ਸਮਝਣਾ ਚਾਹੀਦਾ?

ਪ੍ਰਾਂਪਟ ਤੁਹਾਡੀ ਮੈਨੂੰਮਾਨ ਹਦਾਇਤ ਹੈ; ਇਵੈਲ ਇਹ ਦਰਸਾਉਂਦਾ ਹੈ ਕਿ ਉਹ ਕਿਵੇਂ ਮਾਮਲਿਆਂ 'ਤੇ ਕੰਮ ਕਰਦਾ ਹੈ।

ਮੂਲ ਵਰਕਫ਼ਲੋ:

  • ਇੱਕ ਚੀਜ਼ ਬਦਲੋ (ਪ੍ਰਾਂਪਟ/ਟੂਲ/ਵੈਲਿਡੇਸ਼ਨ)
  • ਉਹੀ ਇਵੈਲ ਸੈੱਟ ਦੌੜਾਓ
  • ਕਦੋਂ ਹੀ ਕੁੱਲ ਸਕੋਰ ਬਿਨਾਂ ਰਿਗਰੈਸ਼ਨ ਦੇ ਬੇਹਤਰ ਹੋਵੇ, ਤਦ ਹੀ ਬਦਲਾਅ ਰੱਖੋ

ਇੱਕ ਚੰਗੀ ਗੱਲ ਕੀਤਾ ਰਿਪਲੀਕੇਟ ਕਰਨ ਦੀ ਬਜਾਇ ਇੱਕ ਵਧੀਆ ਗੱਲ ਉੱਤੇ ਭਰੋਸਾ ਨਾ ਕਰੋ — ਸਕੋਰਕਾਰਡ 'ਤੇ ਭਰੋਸਾ ਕਰੋ।

ਮੈਂ ਆਪਣੀਆਂ ਇਵੈਲ ਟੈਸਟਾਂ 'ਤੇ ਓਵਰਫਿੱਟਿੰਗ ਤੋਂ ਕਿਵੇਂ ਬਚਾਂ?

ਓਵਰਫਿੱਟਿੰਗ ਉਸ ਸਮੇਂ ਹੁੰਦੀ ਹੈ ਜਦ ਤੁਸੀਂ ਇਕ ਛੋਟੀ ਟੈਸਟ ਸੈੱਟ 'ਤੇ ਟਿਊਨ ਕਰ-ਕਰ ਕੇ ਟੈਸਟ ਜਿੱਤ ਲੈਂਦੇ ਹੋ ਪਰ ਅਸਲ ਯੂਜ਼ਰਾਂ ਨਾਲ ਫੇਲ ਹੋ ਜਾਂਦੇ ਹੋ।

ਹਕੀਕਤੀ ਰੋਕਥਾਮ ਲਈ:

  • ਰਿਗਰੈਸ਼ਨ ਚੈਕ ਲਈ ਇੱਕ ਫ੍ਰੋਜ਼ਨ ਇਵੈਲ ਸੈੱਟ ਰੱਖੋ
  • ਇਕ ਵੱਖਰਾ ਹੋਲਡਆਊਟ ਸੈੱਟ ਰੱਖੋ ਜਿਸ 'ਤੇ ਤੁਸੀਂ ਟਿਊਨ ਨਾ ਕਰੋ
  • ਨਿਯਮਤ ਤੌਰ 'ਤੇ ਨਵੇਂ ਅਫਲਿਆਂ ਨੂੰ ਸ਼ਾਮਿਲ ਕਰੋ (ਪ੍ਰਾਇਵੇਸੀ ਸਾਵਧਾਨੀਆਂ ਦੇ ਨਾਲ)

ਇਸ ਨਾਲ ਸੁਧਾਰ ਅਸਲ ਰਹਿੰਦੇ ਹਨ ਨਾ ਕਿ ਸਿਰਫ ਦਿਖਾਵਾ।

AI ਐਪਸ ਵਿੱਚ ਸੁਰੱਖਿਆ ਲਈ ਸਭ ਤੋਂ ਮਹੱਤਵਪੂਰਨ ਵਿਰੋਧੀ ਟੈਸਟ ਕਿਹੜੇ ਹਨ?

ਸੁਰੱਖਿਆ ਨੂੰ ਇੱਕ ਲੂਪ ਵਾਂਗ ਦਿਖੋ: ਇੱਕ ਹਿੱਸਾ ਸਿਸਟਮ ਨੂੰ ਟੁੱਟਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਹੈ (ਅਟੈਕਰ), ਦੂਜਾ ਉਸਨੂੰ ਠੀਕ ਕਰਦਾ ਹੈ (ਬਿਲਡਰ), ਅਤੇ ਹਰ ਫੇਲ ਨੂੰ ਦੁਬਾਰਾ ਦੌਰਾਇਆ ਜਾਂਦਾ ਟੈਸਟ ਬਣਾਓ।

AI ਐਪਸ ਲਈ, ਮਹੱਤਵਪੂਰਨ ਟੈਸਟ:

  • ਪ੍ਰਾਂਪਟ ਇੰਜੈਕਸ਼ਨ (ਪੇਸਟ ਕੀਤੇ ਟੈਕਸਟ ਵਿੱਚ ਛੁਪੀਆਂ ਹਦਾਇਤਾਂ)
  • ਡੇਟਾ ਲੀਕੇਜ (ਸਿਸਟਮ ਪ੍ਰਾਂਪਟ, ਪ੍ਰਾਈਵੇਟ ਡੌਕਸ, ਯੂਜ਼ਰ ਜਾਣਕਾਰੀ)
  • ਟੂਲ ਮਿਸਯੂਜ਼ (ਗਲਤ IDs, ਰੋਲ ਦੇ ਬਾਹਰ ਦੀ ਕਾਰਵਾਈ)
  • ਦੁਰਵ੍ਯਵਹਾਰ ਪੈਟਰਨ (ਬਹੁਤ ਲੰਬੇ ਇਨਪੁਟ, ਬਾਰ-ਬਾਰ ਕਾਲਾਂ)

ਮਕਸਦ: ਫੇਲ ਦੀ ਲਾਗਤ ਵਧਾਉਣਾ ਅਤੇ ਨੁਕਸਾਨ ਦਾ ਖੇਤਰ ਘਟਾਉਣਾ — least-privilege, ਸਕੋਪਡ ਡਾਟਾ, ਅਤੇ ਮਜ਼ਬੂਤ ਲੋਗਿੰਗ।

ਮੈਂ ਆਪਣਾ ਖੁਦ ਦਾ ਵਿਰੋਧੀ ਸੁਧਾਰ ਲੂਪ ਕਿਵੇਂ ਬਣਾਵਾਂ?

ਇੱਕ ਛੋਟੀ, ਵਾਸਤਵਿਕ ਵਰਕਫ਼ਲੋ ਚੁਣੋ ਜਿਸਨੂੰ ਪਹਿਲਾਂ ਸਖਤ ਕਰਨਾ ਹੈ। ਇਕ-ਇਕ ਕਰ ਕੇ ਸਭ ਕੁਝ ਠੀਕ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਨਾ ਕਰੋ — ਫੋਕਸ ਹੋਵੇ ਤਾਂ ਹੀ ਤੇਜ਼ੀ ਆਉਂਦੀ ਹੈ।

ਸਰਲ ਦਿਨ-ਦਾ-ਦੌਰ:

  • ਇੱਕ ਵਰਕਫ਼ਲੋ ਅਤੇ ਇੱਕ ਲਕੜੀ ਨਤੀਜੇ ਦੀ ਚੋਣ ਕਰੋ
  • ਪਾਸ/ਫੇਲ ਨਿਯਮ ਸਪਸ਼ਟ ਲਿਖੋ
  • 20–50 ਹਕੀਕਤੀ ਕੇਸ ਇਕੱਟੇ ਕਰੋ, ਗੰਦੇ ਅਤੇ "ਨਾ-ਨਫਰਮਾਇਸ਼" ਕੇਸ ਸ਼ਾਮਲ ਕਰੋ
  • ਨਤੀਜੇ ਦੌੜਾਓ, ਸਧਾਰਨ ਤੌਰ 'ਤੇ ਸਕੋਰ ਕਰੋ, ਅਤੇ ਫੇਲਾਂ ਨੂੰ ਇੱਕੋ ਹੀ ਢੰਗ ਨਾਲ ਲੇਬਲ ਕਰੋ
  • ਇੱਕ ਛੋਟਾ, ਨਿਸ਼ਾਨਾ ਬਣਾਇਆ ਬਦਲਾਅ ਕਰੋ (ਪ੍ਰਾਂਪਟ, ਟੂਲ ਪਰਮੀਸ਼ਨ, ਵੈਲਿਡੇਸ਼ਨ ਜਾਂ UI ਗਾਰਡਰੇਲ)

ਫਿਰ ਸਹੀ ਪਰੀਖਣਾਂ ਦੁਹਰਾਓ; ਜੇ ਸਕੋਰ ਨਹੀਂ ਵਧਦਾ ਤਾਂ ਬਦਲਾਅ ਬੇਕਾਰ ਸੀ।

ਕੌਮਨ ਗਲਤੀਆਂ ਕਿਹੜੀਆਂ ਹਨ ਜੋ ਲੂਪ ਨੂੰ ਬੇਕਾਰ ਬਣਾਉਂਦੀਆਂ ਹਨ?

ਅਕਸਰ ਗਲਤੀਆਂ ਜੋ ਲੂਪ ਨੂੰ ਬੇਕਾਰ ਬਣਾਉਂਦੀਆਂ ਹਨ:

  • ਖੁਸ਼-ਰਾਹ ਪਰੀਖਣਾਂ ਨੂੰ ਇਵੈਲ ਕਹਿ ਦੇਣਾ — ਜੇ ਟੈਸਟ ਸਿਰਫ ਸਾਫ਼ ਇਨਪੁਟ ਕਵਰ ਕਰਦੇ ਹਨ ਤਾਂ ਤੁਸੀਂ ਡੈਮੋ ਮੈਪ ਕਰ ਰਹੇ ਹੋ, ਪ੍ਰੋਡਕਟ ਨਹੀਂ।
  • ਬਦਲਾਵਾਂ ਨੂੰ ਟਰੈਕ ਨਾ ਕਰਨਾ — ਪ੍ਰਾਂਪਟ v12, ਟੂਲ ਸਕੀਮਾ v3, ਇਵੈਲ ਸੈੱਟ v5 ਵਰਗੀਆਂ ਸਧਾਰਨ ਵਰਜਨ ਨੋਟਸ ਗੁੰਝਲ ਘਟਾਉਂਦੀਆਂ ਹਨ।
  • ਮੂਲਾਂਕਣ vague ਹੋਣਾ — "ਚੰਗਾ ਲੱਗਦਾ ਹੈ" ਕੋਈ ਨਿਯਮ ਨਹੀਂ। ਪਾਸ/ਫੇਲ ਮੈਟਰਿਕਸ ਸਪਸ਼ਟ ਹੋਣ ਚਾਹੀਦੇ ਹਨ।
  • ਟੈਸਟ ਸੈੱਟ 'ਤੇ ਓਵਰਫਿੱਟਿੰਗ — ਹਮੇਸ਼ਾਂ ਨਵੇਂ ਉਦਾਹਰਣ ਜੋੜੋ ਅਤੇ ਇੱਕ "ਕਦੇ ਨਾ ਵੇਖਿਆ" ਹੋਲਡਆਊਟ ਰੱਖੋ।

ਇਸ ਨਾਲ ਲੂਪ ਲਗਾਤਾਰ ਕਾਰਗਰ ਬਣਿਆ ਰਹਿੰਦਾ ਹੈ।

ਸ਼ਿਪ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਟੀਮਾਂ ਕਿਹੜੀਆਂ ਤੇਜ਼ ਜਾਂਚਾਂ ਚਲਾ ਸਕਦੀਆਂ ਹਨ?

ਹੇਠਾਂ ਇੱਕ ਛੋਟੀ ਪਰ ਨਿਯਮਤ ਜाँच-ਰਿਟੁਅਲ ਹੈ ਜੋ ਤੁਸੀਂ ਸ਼ਿਪ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਚਲਾ ਸਕਦੇ ਹੋ:

  • ਇੱਕ ਫਿਕਸਡ ਇਵੈਲ ਸੈੱਟ ਰੱਖੋ ਜੋ ਤੁਸੀਂ ਕਿਸੇ ਵੀ ਵੇਲੇ ਦੌੜਾ ਸਕੋ
  • ਫੇਲਾਂ ਨੂੰ ਦੁਹਰਾਉਗਯੋਗ ਬਣਾਓ (ਕੋਈ ਵੀ ਸਾਥੀ ਇੱਕ ਫੇਲਿੰਗ ਕੇਸ 5 ਮਿੰਟ ਵਿੱਚ ਰੀਪਲੋਡ ਕਰ ਸਕੇ)
  • ਮੁੱਖ ਵਰਕਫ਼ਲੋ ਲਈ ਘੱਟੋ-ਘੱਟ ਇੱਕ ਵਿਰੋਧੀ ਟੈਸਟ ਜੋੜੋ
  • ਸਭ ਤੋਂ ਉੱਚ-ਖਤਰਨਾਕ ਕਾਰਵਾਈ (ਈਮੇਲ ਭੇਜਣਾ, ਡੇਟਾ ਬਦਲਣਾ, ਖਰੀਦ) ਪਛਾਣੋ ਅਤੇ ਉਸ ਰਾਹ ਵਿੱਚ ਖ਼ਾਸ ਚੈੱਕ ਸ਼ਾਮਲ ਕਰੋ
  • ਤੇਜ਼ੀ ਨਾਲ ਰੋਲਬੈਕ ਕਰਨ ਯੋਗ ਹੋਵੋ

ਫੇਲਾਂ ਨੂੰ ਵਰਗਵਾਰ ਟੈਗ ਕਰੋ ਤਾਂ ਕਿ ਪੈਟਰਨ ਨਿਖਰ ਕੇ ਆਣ।

ਇੱਕ ਹਕੀਕਤੀ ਉਦਾਹਰਣ: AI ਫੀਚਰ ਬਿਨਾਂ ਹੈਰਾਨੀਆਂ ਦੇ ਕਿਵੇਂ ਸ਼ਿਪ ਕਰੀਏ?

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

ਉਹਨਾਂ ਨੇ 60 ਸਹੀ ਉਦਾਹਰਣਾਂ ਖਿੱਚ ਕੇ ਇੱਕ ਛੋਟਾ ਇਵੈਲ ਸੈੱਟ ਬਣਾਇਆ ਅਤੇ 20 "ਨਾਸਟੀ" ਪ੍ਰਾਂਪਟ ਜੋੜੇ ਜੋ ਦੁਰਵ੍ਯਵਹਾਰ ਦੀ ਨਕਲ ਕਰਦੇ ਸਨ। ਉਦੇਸ਼ ਸੀਕਵੈਂਸ ਨਹੀਂ — ਇੱਕ ਦੁਹਰਾਊ ਟੈਸਟ ਜੋ ਹਰ ਬਦਲਾਅ ਤੋਂ ਬਾਅਦ ਦੌੜਾਇਆ ਜਾ ਸਕੇ।

ਉਹ ਪ੍ਰਾਂਪਟ ਇੰਜੈਕਸ਼ਨ, ਪ੍ਰਾਈਵੇਟ ਡੇਟਾ ਦੀ ਕੋਸ਼ਿਸ਼, ਟੂਲ ਮਿਸਯੂਜ਼, ਅਸਪਸ਼ਟ ਟਿਕਟਾਂ ਤੇ ਪੁੱਛਤਾਛ ਦੀ ਲੋੜ ਅਤੇ ਨੀਤिगत ਟਕਰਾਅ ਵਰਗੀਆਂ ਚੀਜ਼ਾਂ ਦੇਖਦੇ ਹਨ। ਫਿਰ ਉਹ ਲੂਪ 'ਤੇ ਕੰਮ ਕਰਦੇ ਹਨ: ਸਿਸਟਮ ਪ੍ਰਾਂਪਟ ਕੱਸਦੇ ਹਨ, ਸਧਾਰਨ ਇਨਪੁਟ ਵੈਲਿਡੇਸ਼ਨ ਜੋੜਦੇ ਹਨ, ਅਤੇ ਜੇ ਟੂਲ ਨਤੀਜਾ ਟਿਕਟ ਨਾਲ ਮੇਲ ਨਹੀਂ ਖਾਂਦਾ ਤਾਂ ਪੁੱਛਨਾ ਨਿਯਮ ਬਣਾਉਂਦੇ ਹਨ। ਹਰ ਬਦਲਾਅ ਤੋਂ ਬਾਅਦ ਉਹ ਇਵੈਲ ਚਲਾਉਂਦੇ ਹਨ ਅਤੇ ਰਿਗਰੈਸ਼ਨ ਟਰੈਕ ਕਰਦੇ ਹਨ।

ਇੱਕ ਮਹੀਨੇ ਵਿੱਚ, ਰਿਲੀਜ਼ ਤੇਜ਼ ਹੋ ਜਾਂਦੇ ਹਨ ਕਿਉਂਕਿ ਭਰੋਸਾ ਸਾਫ਼ ਹੋ ਜਾਂਦਾ ਹੈ। ਇਹ ਵਿਰੋਧੀ ਸੋਚ ਦਾ ਅਮਲ ਹੈ: ਬਣਾਉਣ ਵਾਲਾ ਨਤੀਜੇ ਦਿੰਦਾ ਹੈ ਅਤੇ ਟੁੱਟਣ ਵਾਲਾ ਗਾਹਕਾਂ ਦੇ ਵੀਚਾਰ ਤੋਂ ਪਹਿਲਾਂ ਹੀ ਖ਼ਤਰਾ ਲੱਭਦਾ ਹੈ।

ਅਗਲੇ ਕਦਮ: ਇੱਕ ਐਸਾ ਲੂਪ ਕਿਵੇਂ ਸੈੱਟ ਕਰੀਏ ਜੋ ਤੁਸੀਂ ਹਰ ਹਫ਼ਤੇ ਚਲਾ ਸਕੋ?

ਇੱਕ ਚੰਗਾ ਵਿਰੋਧੀ ਲੂਪ ਜਾਣਬੂਝ ਕਰ ਕੇ ਬੋਰਿੰਗ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਇਹ ਹਫ਼ਤਾਵਾਰੀ ਰਿਦਮ ਵਿੱਚ ਆਉਂਦਾ ਹੈ, ਹਰ ਵਾਰੀ ਇੱਕੋ ਜਿਹਾ ਨਤੀਜਾ ਦਿੰਦਾ ਹੈ, ਅਤੇ ਅਗਲਾ ਬਦਲਾਅ ਸਪਸ਼ਟ ਕਰਦਾ ਹੈ।

ਸ਼ੁਰੂਆਤ ਲਈ:

  • ਇੱਕ ਮਹੱਤਵਪੂਰਨ ਵਰਕਫ਼ਲੋ ਚੁਣੋ (ਜਿਵੇਂ "ਬਿਲਿੰਗ ਪ੍ਰਸ਼ਨਾਂ ਦੇ ਜਵਾਬ" ਜਾਂ "AI PR ਵੇਰਵਾ ਬਣਾਉਂਦਾ")
  • ਇਕ ਛੋਟਾ ਇਵੈਲ ਸੈੱਟ (20–50 ਕੇਸ) ਬਣਾਓ ਅਤੇ ਇੱਕੋ ਦਿਨ ਹਰ ਹਫ਼ਤੇ ਦੌੜਾਓ
  • ਦੌੜਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਅੰਕ-ਨਿਰਧਾਰਨ ਨਿਯਮ ਲਿਖੋ

ਹਫਤਾਵਾਰੀ ਲੂਪ:

  • ਮੌਜੂਦਾ ਬਿਲਡ 'ਤੇ ਇਵੈਲ ਚਲਾਓ ਅਤੇ ਸਕੋਰ ਰਿਕਾਰਡ ਕਰੋ
  • ਫੇਲਾਂ ਦੀ ਸਮੀਖਿਆ ਕਰੋ ਅਤੇ ਸਮੂਹ ਬਣਾਓ
  • ਇੱਕ ਨਿਸ਼ਾਨਾ ਬਦਲਾਅ ਕਰੋ
  • ਇਕੋ ਹੀ ਇਵੈਲ ਦੁਹਰਾਓ ਅਤੇ ਤੁਲਨਾ ਕਰੋ
  • ਫੈਸਲਾ ਕਰੋ: ਸ਼ਿਪ, ਲੂਪ ਜਾਰੀ ਰੱਖੋ, ਜਾਂ ਰੋਲਬੈਕ

ਆਰਟੀਫੈਕਟ ਸੁਰੱਖਿਅਤ ਰੱਖੋ: ਪ੍ਰਾਂਪਟ, ਇਵੈਲ ਕੇਸ, ਕੱਚ ਨਤੀਜੇ, ਤੇ ਜੋ ਫੈਸਲੇ ਲਏ ਗਏ। Koder.ai ਵਰਤੋਂ ਵਾਲੇ ਲਈ, planning mode, ਸਨੇਪਸ਼ਾਟ ਅਤੇ ਰੋਲਬੈਕ ਇਸਨੂੰ ਆਸਾਨ ਬਣਾਉਂਦੇ ਹਨ।

ਜੇ ਤੁਸੀਂ ਇਸ ਹਫ਼ਤੇ ਸਿਰਫ਼ ਇੱਕ ਕੰਮ ਕਰੋ: ਸਕੋਰਿੰਗ ਨਿਯਮ ਲਿਖੋ ਅਤੇ ਆਪਣਾ ਪਹਿਲਾ ਇਵੈਲ ਸੈੱਟ ਲਾਕ ਕਰੋ। ਸਭ ਕੁਝ ਆਸਾਨ ਹੋ ਜਾਵੇगा ਜਦ ਸਾਰੇ ਇਕੋ ਤਰ੍ਹਾਂ ਮੂਲਾਂਕਣ ਕਰਨ।

ਸਮੱਗਰੀ
ਸਧਾਰਣ ਵਿਚਾਰ: ਦੋ ਪ੍ਰਣਾਲੀਆਂ ਜੋ ਇਕ ਦੂਜੇ ਨੂੰ ਧੱਕ ਦਿੰਦੀਆਂ ਹਨIan Goodfellow ਅਤੇ GANs ਸਧਾਰਨ ਭਾਸ਼ਾ ਵਿੱਚਕਿਉਂ ਵਿਰੋਧੀ ਟਰੇਨਿੰਗ ਕੰਮ ਕਰਦੀ ਹੈ (ਅਤੇ ਕਦੋਂ ਫੇਲ ਹੁੰਦੀ ਹੈ)ਆਮ ਨਮੂਨਾ: ਉਤਪਾਦਕ ਵਿਰੁੱਧ ਨਿਆਂਦੀ (produce vs judge)AI-ਨਿਰਮਿਤ ਐਪਸ ਵਿੱਚ ਪ੍ਰਾਂਪਟ ਵਿਰੁੱਧ ਇਵੈਲ ਲੂਪਸੁਰੱਖਿਆ ਇੱਕ ਵਿਰੋਧੀ ਲੂਪ ਵਜੋਂ (ਰੈਡ ਟੀਮ ਵਿਰੁੱਧ ਬਲੂ ਟੀਮ)ਕਦਮ-ਦਰ-ਕਦਮ: ਆਪਣਾ ਖੁਦ ਦਾ ਵਿਰੋਧੀ ਸੁਧਾਰ ਲੂਪ ਬਣਾਓਲੂਪ ਨੂੰ ਬੇਕਾਰ ਬਣਾਉਣ ਵਾਲੀਆਂ ਆਮ ਗਲਤੀਆਂਸ਼ਿਪ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਟੀਮਾਂ ਲਈ ਤੇਜ਼ ਜਾਂਚਾਂਅਕਸਰ ਪੁੱਛੇ ਜਾਣ ਵਾਲੇ ਸਵਾਲ
ਸਾਂਝਾ ਕਰੋ