DALL·E 2 ਪ੍ਰੀ-ਟ੍ਰੇਨਿੰਗ ਉਪਸ਼ਮਨ

DALL·E 2⁠ ਦਾ ਜਾਦੂ ਵੱਡੇ ਦਰਸ਼ਕ ਵਰਗ ਨਾਲ ਸਾਂਝਾ ਕਰਨ ਲਈ, ਸਾਨੂੰ ਸ਼ਕਤੀਸ਼ਾਲੀ ਇਮੇਜ ਜਨਰੇਸ਼ਨ ਮਾਡਲਜ਼ ਨਾਲ ਜੁੜੇ ਖ਼ਤਰਿਆਂ ਨੂੰ ਘਟਾਉਣਾ ਲੋੜੀਂਦਾ ਸੀ। ਇਸ ਲਈ, ਅਸੀਂ ਵੱਖ-ਵੱਖ guardrails⁠(ਨਵੀਂ ਵਿੰਡੋ ਵਿੱਚ ਖੁੱਲ੍ਹਦਾ ਹੈ) ਲਾਗੂ ਕੀਤੀਆਂ ਤਾਂ ਜੋ ਬਣੇ ਚਿੱਤਰ ਸਾਡੀ content policy⁠(ਨਵੀਂ ਵਿੰਡੋ ਵਿੱਚ ਖੁੱਲ੍ਹਦਾ ਹੈ) ਦੀ ਉਲੰਘਣਾ ਨਾ ਕਰਨ।

ਇਹ ਪੋਸਟ ਪ੍ਰੀ-ਟ੍ਰੇਨਿੰਗ ਉਪਸ਼ਮਨਾਂ 'ਤੇ ਕੇਂਦ੍ਰਿਤ ਹੈ, ਜੋ ਇਹਨਾਂ guardrails ਦਾ ਇੱਕ ਉਪਸੈੱਟ ਹਨ ਅਤੇ ਸਿੱਧੇ ਤੌਰ 'ਤੇ ਉਸ ਡਾਟਾ ਨੂੰ ਬਦਲਦੇ ਹਨ ਜਿਸ ਤੋਂ DALL·E 2 ਸਿੱਖਦਾ ਹੈ। ਖ਼ਾਸ ਤੌਰ 'ਤੇ, DALL·E 2 ਨੂੰ ਇੰਟਰਨੈੱਟ ਤੋਂ ਸੈਂਕੜੇ ਮਿਲੀਅਨ captioned ਚਿੱਤਰਾਂ 'ਤੇ ਟ੍ਰੇਨ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਅਸੀਂ ਇਹਨਾਂ ਵਿੱਚੋਂ ਕੁਝ ਚਿੱਤਰ ਹਟਾਉਂਦੇ ਅਤੇ reweight ਕਰਦੇ ਹਾਂ ਤਾਂ ਜੋ ਮਾਡਲ ਕੀ ਸਿੱਖਦਾ ਹੈ, ਉਹ ਬਦਲਿਆ ਜਾ ਸਕੇ।

ਇਹ ਪੋਸਟ ਤਿੰਨ ਭਾਗਾਂ ਵਿੱਚ ਸੁਗਠਿਤ ਹੈ, ਅਤੇ ਹਰ ਭਾਗ ਇੱਕ ਵੱਖਰੇ ਪ੍ਰੀ-ਟ੍ਰੇਨਿੰਗ ਉਪਸ਼ਮਨ ਦਾ ਵਰਣਨ ਕਰਦਾ ਹੈ:

• ਪਹਿਲੇ ਭਾਗ ਵਿੱਚ, ਅਸੀਂ ਵਰਣਨ ਕਰਦੇ ਹਾਂ ਕਿ DALL·E 2 ਦੇ ਟ੍ਰੇਨਿੰਗ ਡਾਟਾਸੈੱਟ ਵਿੱਚੋਂ ਹਿੰਸਕ ਅਤੇ ਯੌਨ ਚਿੱਤਰਾਂ ਨੂੰ ਕਿਵੇਂ ਫਿਲਟਰ ਕਰਕੇ ਹਟਾਇਆ ਗਿਆ। ਇਸ ਉਪਸ਼ਮਨ ਤੋਂ ਬਿਨਾਂ, ਮਾਡਲ ਐਸੇ ਪ੍ਰੌੰਪਟ ਮਿਲਣ 'ਤੇ graphic ਜਾਂ explicit ਚਿੱਤਰ ਬਣਾਉਣਾ ਸਿੱਖ ਲੈਂਦਾ, ਅਤੇ ਕਈ ਵਾਰ ਦਿਖਣ ਵਿੱਚ ਨਿਰਦੋਸ਼ ਪ੍ਰੌੰਪਟਾਂ ਦੇ ਜਵਾਬ ਵਿੱਚ ਵੀ ਅਣਜਾਣੇ ਵਿੱਚ ਐਸੇ ਚਿੱਤਰ ਵਾਪਸ ਕਰ ਸਕਦਾ ਸੀ।
• ਦੂਜੇ ਭਾਗ ਵਿੱਚ, ਅਸੀਂ ਪਾਉਂਦੇ ਹਾਂ ਕਿ ਟ੍ਰੇਨਿੰਗ ਡਾਟਾ ਨੂੰ ਫਿਲਟਰ ਕਰਨ ਨਾਲ ਪੱਖਪਾਤ ਵਧ ਸਕਦਾ ਹੈ, ਅਤੇ ਅਸੀਂ ਇਸ ਪ੍ਰਭਾਵ ਨੂੰ ਘਟਾਉਣ ਲਈ ਆਪਣੀ ਤਕਨੀਕ ਦਾ ਵਰਣਨ ਕਰਦੇ ਹਾਂ। ਉਦਾਹਰਨ ਵਜੋਂ, ਇਸ ਉਪਸ਼ਮਨ ਤੋਂ ਬਿਨਾਂ, ਅਸੀਂ ਵੇਖਿਆ ਕਿ filtered ਡਾਟਾ 'ਤੇ ਟ੍ਰੇਨ ਕੀਤੇ ਮਾਡਲ ਕਈ ਵਾਰ ਮੂਲ ਡਾਟਾਸੈੱਟ 'ਤੇ ਟ੍ਰੇਨ ਕੀਤੇ ਮਾਡਲਾਂ ਦੇ ਮੁਕਾਬਲੇ ਮਰਦਾਂ ਨੂੰ ਦਰਸਾਉਂਦੇ ਵੱਧ ਚਿੱਤਰ ਅਤੇ ਔਰਤਾਂ ਨੂੰ ਦਰਸਾਉਂਦੇ ਘੱਟ ਚਿੱਤਰ ਬਣਾਉਂਦੇ ਸਨ।
• ਅੰਤਿਮ ਭਾਗ ਵਿੱਚ, ਅਸੀਂ memorization ਦੇ ਮਸਲੇ ਵੱਲ ਮੁੜਦੇ ਹਾਂ ਅਤੇ ਪਾਉਂਦੇ ਹਾਂ ਕਿ DALL·E 2 ਵਰਗੇ ਮਾਡਲ ਕਈ ਵਾਰ ਨਵੇਂ ਚਿੱਤਰ ਬਣਾਉਣ ਦੀ ਬਜਾਇ ਉਹ ਚਿੱਤਰ ਦੁਹਰਾ ਸਕਦੇ ਹਨ ਜਿਨ੍ਹਾਂ 'ਤੇ ਉਨ੍ਹਾਂ ਨੂੰ ਟ੍ਰੇਨ ਕੀਤਾ ਗਿਆ ਸੀ। ਅਮਲ ਵਿੱਚ, ਸਾਨੂੰ ਮਿਲਿਆ ਕਿ ਇਹ image regurgitation ਉਨ੍ਹਾਂ ਚਿੱਤਰਾਂ ਕਾਰਨ ਹੁੰਦੀ ਹੈ ਜੋ ਡਾਟਾਸੈੱਟ ਵਿੱਚ ਕਈ ਵਾਰ ਦੁਹਰਾਏ ਗਏ ਹੁੰਦੇ ਹਨ, ਅਤੇ ਅਸੀਂ ਇਹ ਸਮੱਸਿਆ ਉਹ ਚਿੱਤਰ ਹਟਾ ਕੇ ਘਟਾਉਂਦੇ ਹਾਂ ਜੋ ਡਾਟਾਸੈੱਟ ਦੇ ਹੋਰ ਚਿੱਤਰਾਂ ਨਾਲ ਦ੍ਰਿਸ਼ਟੀਗਤ ਤੌਰ 'ਤੇ ਮਿਲਦੇ ਹਨ।

ਕਿਉਂਕਿ ਟ੍ਰੇਨਿੰਗ ਡਾਟਾ ਕਿਸੇ ਵੀ ਸਿੱਖੇ ਹੋਏ ਮਾਡਲ ਦੀਆਂ ਸਮਰੱਥਾਵਾਂ ਨੂੰ ਆਕਾਰ ਦਿੰਦਾ ਹੈ, ਇਸ ਲਈ ਡਾਟਾ ਫਿਲਟਰਿੰਗ ਅਣਚਾਹੀਆਂ ਮਾਡਲ ਸਮਰੱਥਾਵਾਂ ਨੂੰ ਸੀਮਿਤ ਕਰਨ ਲਈ ਇੱਕ ਸ਼ਕਤੀਸ਼ਾਲੀ ਸਾਧਨ ਹੈ। ਅਸੀਂ ਇਸ ਪਹੁੰਚ ਨੂੰ ਦੋ ਸ਼੍ਰੇਣੀਆਂ—graphic ਹਿੰਸਾ ਅਤੇ ਯੌਨ ਸਮੱਗਰੀ ਦਰਸਾਉਂਦੇ ਚਿੱਤਰਾਂ—'ਤੇ ਲਾਗੂ ਕੀਤਾ, ਜਿਸ ਵਿੱਚ ਕਲਾਸੀਫਾਇਰ ਵਰਤ ਕੇ DALL·E 2 ਦੀ ਟ੍ਰੇਨਿੰਗ ਤੋਂ ਪਹਿਲਾਂ ਇਹਨਾਂ ਸ਼੍ਰੇਣੀਆਂ ਦੇ ਚਿੱਤਰਾਂ ਨੂੰ ਡਾਟਾਸੈੱਟ ਵਿੱਚੋਂ ਫਿਲਟਰ ਕਰਕੇ ਹਟਾਇਆ ਗਿਆ। ਅਸੀਂ ਇਹ image classifiers ਆਪਣੇ ਅੰਦਰੂਨੀ ਤੌਰ 'ਤੇ ਟ੍ਰੇਨ ਕੀਤੇ ਅਤੇ ਆਪਣੇ ਟ੍ਰੇਨ ਕੀਤੇ ਮਾਡਲ 'ਤੇ ਡਾਟਾਸੈੱਟ ਫਿਲਟਰਿੰਗ ਦੇ ਪ੍ਰਭਾਵਾਂ ਦਾ ਅਧਿਐਨ ਜਾਰੀ ਰੱਖ ਰਹੇ ਹਾਂ।

ਆਪਣੇ image classifiers ਨੂੰ ਟ੍ਰੇਨ ਕਰਨ ਲਈ, ਅਸੀਂ ਉਹੀ ਪਹੁੰਚ ਦੁਬਾਰਾ ਵਰਤੀ ਜੋ ਅਸੀਂ ਪਹਿਲਾਂ GLIDE⁠(ਨਵੀਂ ਵਿੰਡੋ ਵਿੱਚ ਖੁੱਲ੍ਹਦਾ ਹੈ) ਲਈ ਟ੍ਰੇਨਿੰਗ ਡਾਟਾ ਫਿਲਟਰ ਕਰਨ ਵਿੱਚ ਵਰਤੀ ਸੀ। ਇਸ ਪਹੁੰਚ ਦੇ ਬੁਨਿਆਦੀ ਕਦਮ ਇਹ ਹਨ: ਪਹਿਲਾਂ, ਅਸੀਂ ਉਹਨਾਂ image categories ਲਈ ਇੱਕ specification ਬਣਾਉਂਦੇ ਹਾਂ ਜਿਨ੍ਹਾਂ ਨੂੰ ਅਸੀਂ ਲੇਬਲ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹਾਂ। ਦੂਜੇ, ਅਸੀਂ ਹਰ ਸ਼੍ਰੇਣੀ ਲਈ ਕੁਝ ਸੌ positive ਅਤੇ negative ਉਦਾਹਰਨ ਇਕੱਠੇ ਕਰਦੇ ਹਾਂ। ਤੀਜੇ, ਅਸੀਂ ਹੋਰ ਡਾਟਾ ਇਕੱਠਾ ਕਰਨ ਅਤੇ precision/recall trade-off ਸੁਧਾਰਣ ਲਈ ਇੱਕ active learning ਪ੍ਰਕਿਰਿਆ ਵਰਤਦੇ ਹਾਂ। ਅਤੇ ਅੰਤ ਵਿੱਚ, ਅਸੀਂ recall ਨੂੰ precision ਉੱਤੇ ਤਰਜੀਹ ਦੇਣ ਲਈ ਸੰਯਮੀ ਵਰਗੀਕਰਨ threshold ਨਾਲ ਪੂਰੇ ਡਾਟਾਸੈੱਟ 'ਤੇ ਤਿਆਰ classifier ਚਲਾਉਂਦੇ ਹਾਂ। ਇਹ thresholds ਨਿਰਧਾਰਤ ਕਰਨ ਵੇਲੇ, ਅਸੀਂ ਸਾਰੇ bad ਡਾਟਾ ਨੂੰ ਫਿਲਟਰ ਕਰਕੇ ਹਟਾਉਣ ਨੂੰ ਸਾਰੇ good ਡਾਟਾ ਨੂੰ ਛੱਡਣ ਨਾਲੋਂ ਵੱਧ ਤਰਜੀਹ ਦਿੱਤੀ। ਇਹ ਇਸ ਲਈ ਕਿ ਅਸੀਂ ਬਾਅਦ ਵਿੱਚ ਆਪਣੇ ਮਾਡਲ ਨੂੰ ਹੋਰ ਡਾਟਾ ਨਾਲ ਹਮੇਸ਼ਾ fine-tune ਕਰ ਸਕਦੇ ਹਾਂ ਤਾਂ ਜੋ ਉਹ ਨਵੀਆਂ ਚੀਜ਼ਾਂ ਸਿੱਖੇ, ਪਰ ਜੋ ਕੁਝ ਮਾਡਲ ਪਹਿਲਾਂ ਹੀ ਸਿੱਖ ਚੁੱਕਾ ਹੈ, ਉਹ ਭੁਲਾਉਣਾ ਕਾਫ਼ੀ ਔਖਾ ਹੁੰਦਾ ਹੈ।

ਐਕਟਿਵ ਲਰਨਿੰਗ ਚਰਨ ਦੌਰਾਨ, ਅਸੀਂ ਸੰਭਾਵਿਤ ਤੌਰ 'ਤੇ ਮੁਸ਼ਕਲ ਜਾਂ ਗਲਤ ਵਰਗੀਕ੍ਰਿਤ ਚਿੱਤਰਾਂ ਲਈ ਮਨੁੱਖੀ ਲੇਬਲ ਇਕੱਠੇ ਕਰਕੇ ਆਪਣੇ ਕਲਾਸੀਫਾਇਰਾਂ ਨੂੰ ਦੁਹਰਾਓਂ ਰਾਹੀਂ ਸੁਧਾਰਿਆ। ਖਾਸ ਤੌਰ 'ਤੇ, ਅਸੀਂ ਆਪਣੇ ਡਾਟਾਸੈੱਟ ਵਿਚੋਂ ਚਿੱਤਰ ਚੁਣਨ ਲਈ ਦੋ ਐਕਟਿਵ ਲਰਨਿੰਗ ਤਕਨੀਕਾਂ ਵਰਤੀਆਂ (ਜਿਸ ਵਿੱਚ ਸੈਂਕੜੇ ਮਿਲੀਅਨ ਬਿਨਾਂ ਲੇਬਲ ਵਾਲੇ ਚਿੱਤਰ ਹਨ) ਤਾਂ ਜੋ ਉਹਨਾਂ ਨੂੰ ਲੇਬਲਿੰਗ ਲਈ ਮਨੁੱਖਾਂ ਸਾਹਮਣੇ ਪੇਸ਼ ਕੀਤਾ ਜਾ ਸਕੇ। ਪਹਿਲਾਂ, ਆਪਣੇ ਕਲਾਸੀਫਾਇਰ ਦੀ false positive ਦਰ ਘਟਾਉਣ ਲਈ (ਅਰਥਾਤ, ਇਹ ਜਿੰਨੀ ਵਾਰ ਕਿਸੇ ਨਿਰਦੋਸ਼ ਚਿੱਤਰ ਨੂੰ ਹਿੰਸਕ ਜਾਂ ਯੌਨ ਵਜੋਂ ਗਲਤ ਵਰਗੀਕ੍ਰਿਤ ਕਰਦਾ ਹੈ), ਅਸੀਂ ਉਹਨਾਂ ਚਿੱਤਰਾਂ ਨੂੰ ਮਨੁੱਖੀ ਲੇਬਲ ਦਿੱਤੇ ਜਿਨ੍ਹਾਂ ਨੂੰ ਮੌਜੂਦਾ ਮਾਡਲ ਨੇ positive ਵਜੋਂ ਵਰਗੀਕ੍ਰਿਤ ਕੀਤਾ ਸੀ। ਇਹ ਕਦਮ ਚੰਗੀ ਤਰ੍ਹਾਂ ਕੰਮ ਕਰੇ, ਇਸ ਲਈ ਅਸੀਂ ਆਪਣੇ ਵਰਗੀਕਰਨ threshold ਨੂੰ ਲਗਭਗ 100% recall ਪਰ ਉੱਚ false-positive ਦਰ ਲਈ ਟਿਊਨ ਕੀਤਾ। ਇਸ ਤਰੀਕੇ ਨਾਲ, ਸਾਡੇ ਲੇਬਲਰ ਜ਼ਿਆਦਾਤਰ ਅਸਲ ਵਿੱਚ negative ਕੇਸਾਂ ਨੂੰ ਲੇਬਲ ਕਰ ਰਹੇ ਸਨ। ਹਾਲਾਂਕਿ ਇਹ ਤਕਨੀਕ false positives ਨੂੰ ਘਟਾਉਣ ਵਿੱਚ ਮਦਦ ਕਰਦੀ ਹੈ ਅਤੇ ਲੇਬਲਰਾਂ ਨੂੰ ਸੰਭਾਵਿਤ ਤੌਰ 'ਤੇ ਹਾਨੀਕਾਰਕ ਚਿੱਤਰ ਵੇਖਣ ਦੀ ਲੋੜ ਘਟਾਉਂਦੀ ਹੈ, ਪਰ ਇਹ ਉਹ ਹੋਰ positive ਕੇਸ ਲੱਭਣ ਵਿੱਚ ਮਦਦ ਨਹੀਂ ਕਰਦੀ ਜੋ ਮਾਡਲ ਇਸ ਵੇਲੇ ਖੋ ਰਿਹਾ ਹੈ।

ਆਪਣੇ ਕਲਾਸੀਫਾਇਰ ਦੀ false negative ਦਰ ਘਟਾਉਣ ਲਈ, ਅਸੀਂ ਦੂਜੀ ਐਕਟਿਵ ਲਰਨਿੰਗ ਤਕਨੀਕ ਵਰਤੀ: nearest neighbor search। ਖਾਸ ਤੌਰ 'ਤੇ, ਅਸੀਂ ਆਪਣੇ ਮੌਜੂਦਾ ਲੇਬਲ ਕੀਤੇ ਡਾਟਾਸੈੱਟ ਵਿੱਚ ਉਹ positive ਨਮੂਨੇ ਲੱਭਣ ਲਈ many-fold cross-validation ਚਲਾਈ ਜਿਨ੍ਹਾਂ ਨੂੰ ਮਾਡਲ negative ਵਜੋਂ ਗਲਤ ਵਰਗੀਕ੍ਰਿਤ ਕਰਨ ਦੀ ਰੁਝਾਨ ਰੱਖਦਾ ਸੀ (ਇਹ ਕਰਨ ਲਈ, ਅਸੀਂ ਵੱਖ-ਵੱਖ train-validation splits ਨਾਲ ਕਲਾਸੀਫਾਇਰ ਦੇ ਸੈਂਕੜੇ ਵਰਜਨ ਵਾਸਤਵ ਵਿੱਚ ਟ੍ਰੇਨ ਕੀਤੇ)। ਫਿਰ ਅਸੀਂ perceptual feature space ਵਿੱਚ ਇਹਨਾਂ ਨਮੂਨਿਆਂ ਦੇ nearest neighbors ਲਈ ਬਿਨਾਂ ਲੇਬਲ ਵਾਲੇ ਚਿੱਤਰਾਂ ਦੇ ਆਪਣੇ ਵੱਡੇ ਸੰਗ੍ਰਹਿ ਨੂੰ ਸਕੈਨ ਕੀਤਾ, ਅਤੇ ਮਿਲੇ ਚਿੱਤਰਾਂ ਨੂੰ ਮਨੁੱਖੀ ਲੇਬਲ ਦਿੱਤੇ। ਆਪਣੀ compute infrastructure ਦੀ ਬਦੌਲਤ, ਕਲਾਸੀਫਾਇਰ ਟ੍ਰੇਨਿੰਗ ਅਤੇ nearest neighbor search ਦੋਹਾਂ ਨੂੰ ਕਈ GPUs ਤੱਕ ਵਧਾਉਣਾ ਆਸਾਨ ਸੀ, ਜਿਸ ਨਾਲ ਐਕਟਿਵ ਲਰਨਿੰਗ ਕਦਮ ਘੰਟਿਆਂ ਜਾਂ ਦਿਨਾਂ ਦੀ ਬਜਾਇ ਕੁਝ ਮਿੰਟਾਂ ਵਿੱਚ ਹੋ ਸਕਿਆ।

ਆਪਣੇ ਡਾਟਾ ਫਿਲਟਰਾਂ ਦੀ ਪ੍ਰਭਾਵਸ਼ੀਲਤਾ ਦੀ ਪੁਸ਼ਟੀ ਕਰਨ ਲਈ, ਅਸੀਂ ਇੱਕੋ hyperparameters ਨਾਲ ਦੋ GLIDE ਮਾਡਲ ਟ੍ਰੇਨ ਕੀਤੇ: ਇੱਕ ਬਿਨਾਂ ਫਿਲਟਰ ਕੀਤੇ ਡਾਟਾ 'ਤੇ, ਅਤੇ ਇੱਕ ਫਿਲਟਰਿੰਗ ਤੋਂ ਬਾਅਦ ਵਾਲੇ ਡਾਟਾਸੈੱਟ 'ਤੇ। ਅਸੀਂ ਪਹਿਲੇ ਮਾਡਲ ਨੂੰ unfiltered model ਅਤੇ ਦੂਜੇ ਨੂੰ filtered model ਕਹਿੰਦੇ ਹਾਂ। ਉਮੀਦ ਅਨੁਸਾਰ, ਸਾਨੂੰ ਮਿਲਿਆ ਕਿ filtered ਮਾਡਲ ਆਮ ਤੌਰ 'ਤੇ ਇਸ ਕਿਸਮ ਦੀ ਸਮੱਗਰੀ ਲਈ ਬੇਨਤੀਆਂ ਦੇ ਜਵਾਬ ਵਿੱਚ ਘੱਟ explicit ਜਾਂ graphic ਸਮੱਗਰੀ ਤਿਆਰ ਕਰਦਾ ਸੀ। ਹਾਲਾਂਕਿ, ਸਾਨੂੰ ਡਾਟਾ ਫਿਲਟਰਿੰਗ ਦਾ ਇੱਕ ਅਣਅਪੇक्षित ਸਾਈਡ-ਇਫੈਕਟ ਵੀ ਮਿਲਿਆ: ਇਸ ਨੇ ਕੁਝ demographics ਵੱਲ ਮਾਡਲ ਦੇ ਪੱਖਪਾਤ ਪੈਦਾ ਕੀਤੇ ਜਾਂ ਵਧਾਏ।

ਜਨਰੇਟਿਵ ਮਾਡਲਜ਼ ਆਪਣੇ ਟ੍ਰੇਨਿੰਗ ਡਾਟਾ ਦੀ distribution ਨਾਲ ਮੇਲ ਬਿਠਾਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਹਨ, ਜਿਸ ਵਿੱਚ ਉਸਦੇ ਅੰਦਰ ਮੌਜੂਦ ਕਿਸੇ ਵੀ ਪੱਖਪਾਤ ਸਮੇਤ। ਨਤੀਜੇ ਵਜੋਂ, ਟ੍ਰੇਨਿੰਗ ਡਾਟਾ ਨੂੰ ਫਿਲਟਰ ਕਰਨ ਨਾਲ downstream ਮਾਡਲਾਂ ਵਿੱਚ ਪੱਖਪਾਤ ਪੈਦਾ ਕਰਨ ਜਾਂ ਵਧਾਉਣ ਦੀ ਸੰਭਾਵਨਾ ਹੁੰਦੀ ਹੈ। ਆਮ ਤੌਰ 'ਤੇ, ਮੂਲ ਡਾਟਾਸੈੱਟ ਵਿੱਚ ਪੱਖਪਾਤ ਠੀਕ ਕਰਨਾ ਇੱਕ ਔਖਾ ਸਮਾਜ-ਤਕਨੀਕੀ ਕੰਮ ਹੈ ਜਿਸਦਾ ਅਸੀਂ ਅਜੇ ਵੀ ਅਧਿਐਨ ਕਰ ਰਹੇ ਹਾਂ, ਅਤੇ ਇਹ ਇਸ ਪੋਸਟ ਦੇ ਖੇਤਰ ਤੋਂ ਬਾਹਰ ਹੈ। ਇੱਥੇ ਜਿਸ ਸਮੱਸਿਆ ਨੂੰ ਅਸੀਂ ਸੰਬੋਧਦੇ ਹਾਂ, ਉਹ ਖ਼ਾਸ ਤੌਰ 'ਤੇ ਡਾਟਾ ਫਿਲਟਰਿੰਗ ਕਾਰਨ ਪੈਦਾ ਹੋਣ ਵਾਲੇ ਪੱਖਪਾਤ ਦਾ ਵਾਧਾ ਹੈ। ਆਪਣੀ ਪਹੁੰਚ ਨਾਲ, ਅਸੀਂ filtered ਮਾਡਲ ਨੂੰ unfiltered ਮਾਡਲ ਨਾਲੋਂ ਵੱਧ ਪੱਖਪਾਤੀ ਹੋਣ ਤੋਂ ਰੋਕਣ ਦਾ ਲਕਸ਼ ਰੱਖਦੇ ਹਾਂ, ਅਰਥਾਤ ਡਾਟਾ ਫਿਲਟਰਿੰਗ ਕਾਰਨ ਆਏ distribution shift ਨੂੰ ਘਟਾਉਣਾ।

ਫਿਲਟਰਿੰਗ ਕਾਰਨ ਪੱਖਪਾਤ ਵਧਣ ਦਾ ਇੱਕ ਠੋਸ ਉਦਾਹਰਨ ਲਓ: ਪ੍ਰੌੰਪਟ “a ceo”. ਜਦੋਂ ਸਾਡੇ unfiltered ਮਾਡਲ ਨੇ ਇਸ ਪ੍ਰੌੰਪਟ ਲਈ ਚਿੱਤਰ ਬਣਾਏ, ਤਾਂ ਇਹ ਔਰਤਾਂ ਨਾਲੋਂ ਮਰਦਾਂ ਦੀਆਂ ਵੱਧ ਤਸਵੀਰਾਂ ਬਣਾਉਣ ਵੱਲ ਝੁਕਦਾ ਸੀ, ਅਤੇ ਅਸੀਂ ਮੰਨਦੇ ਹਾਂ ਕਿ ਇਸ ਪੱਖਪਾਤ ਦਾ ਵੱਡਾ ਹਿੱਸਾ ਸਾਡੇ ਮੌਜੂਦਾ ਟ੍ਰੇਨਿੰਗ ਡਾਟਾ ਦਾ ਪ੍ਰਤੀਬਿੰਬ ਹੈ। ਪਰ ਜਦੋਂ ਅਸੀਂ ਇਹੋ ਪ੍ਰੌੰਪਟ ਆਪਣੇ filtered ਮਾਡਲ ਰਾਹੀਂ ਚਲਾਇਆ, ਤਾਂ ਪੱਖਪਾਤ ਵਧਿਆ ਹੋਇਆ ਲੱਗਿਆ। ਬਣੇ ਚਿੱਤਰ ਲਗਭਗ ਪੂਰੀ ਤਰ੍ਹਾਂ ਮਰਦਾਂ ਦੇ ਸਨ।

ਸਾਡਾ ਅਨੁਮਾਨ ਹੈ ਕਿ ਪੱਖਪਾਤ ਵਧਣ ਦਾ ਇਹ ਖ਼ਾਸ ਕੇਸ ਦੋ ਕਾਰਣਾਂ ਤੋਂ ਆਉਂਦਾ ਹੈ: ਪਹਿਲਾਂ, ਭਾਵੇਂ ਮੂਲ ਡਾਟਾਸੈੱਟ ਵਿੱਚ ਔਰਤਾਂ ਅਤੇ ਮਰਦਾਂ ਦੀ ਨੁਮਾਇੰਦਗੀ ਲਗਭਗ ਬਰਾਬਰ ਹੋਵੇ, ਡਾਟਾਸੈੱਟ ਔਰਤਾਂ ਨੂੰ ਹੋਰ ਯੌਨਿਕ ਸੰਦਰਭਾਂ ਵਿੱਚ ਦਰਸਾਉਣ ਵੱਲ ਪੱਖਪਾਤੀ ਹੋ ਸਕਦਾ ਹੈ। ਦੂਜਾ, ਸਾਡੇ classifiers ਖੁਦ ਵੀ, implementation ਜਾਂ class definition ਕਾਰਨ, ਪੱਖਪਾਤੀ ਹੋ ਸਕਦੇ ਹਨ, ਭਾਵੇਂ ਡਾਟਾ ਇਕੱਠਾ ਕਰਨ ਅਤੇ validation ਚਰਣਾਂ ਦੌਰਾਨ ਅਸੀਂ ਇਹ ਯਕੀਨੀ ਬਣਾਉਣ ਦੀ ਪੂਰੀ ਕੋਸ਼ਿਸ਼ ਕੀਤੀ ਸੀ ਕਿ ਐਸਾ ਨਾ ਹੋਵੇ। ਇਹਨਾਂ ਦੋਵੇਂ ਪ੍ਰਭਾਵਾਂ ਕਾਰਨ, ਸਾਡਾ filter ਮਰਦਾਂ ਨਾਲੋਂ ਔਰਤਾਂ ਦੀਆਂ ਵੱਧ ਤਸਵੀਰਾਂ ਹਟਾ ਸਕਦਾ ਹੈ, ਜਿਸ ਨਾਲ training ਦੌਰਾਨ ਮਾਡਲ ਦੇਖਣ ਵਾਲਾ gender ratio ਬਦਲ ਜਾਂਦਾ ਹੈ।

ਫਿਲਟਰ-ਕਾਰਜਿਤ ਪੱਖਪਾਤ ਦੀ ਹੋਰ ਵਿਸਥਾਰ ਨਾਲ ਜਾਂਚ ਕਰਨ ਲਈ, ਅਸੀਂ ਇੱਕ ਤਰੀਕਾ ਚਾਹੁੰਦੇ ਸਨ ਜਿਸ ਨਾਲ ਮਾਪਿਆ ਜਾ ਸਕੇ ਕਿ ਸਾਡੇ ਡਾਟਾ filters ਵੱਖ-ਵੱਖ ਧਾਰਣਾਵਾਂ ਵੱਲ ਪੱਖਪਾਤ ਨੂੰ ਕਿੰਨਾ ਪ੍ਰਭਾਵਿਤ ਕਰ ਰਹੇ ਸਨ। ਖਾਸ ਗੱਲ ਇਹ ਹੈ ਕਿ ਸਾਡੇ violence ਅਤੇ sexual content filters ਪੂਰੀ ਤਰ੍ਹਾਂ image-based ਹਨ, ਪਰ ਸਾਡੇ ਡਾਟਾਸੈੱਟ ਦੀ multimodal ਕੁਦਰਤ ਸਾਨੂੰ ਇਹਨਾਂ filters ਦੇ text 'ਤੇ ਅਸਰ ਨੂੰ ਸਿੱਧੇ ਤੌਰ 'ਤੇ ਮਾਪਣ ਦੀ ਆਗਿਆ ਦਿੰਦੀ ਹੈ। ਕਿਉਂਕਿ ਹਰ ਚਿੱਤਰ ਨਾਲ ਇੱਕ text caption ਹੁੰਦੀ ਹੈ, ਅਸੀਂ filtered ਅਤੇ unfiltered ਡਾਟਾਸੈੱਟਾਂ ਵਿੱਚ ਹੱਥੋਂ ਚੁਣੇ keywords ਦੀ relative frequency ਵੇਖ ਕੇ ਅੰਦਾਜ਼ਾ ਲਗਾ ਸਕਦੇ ਸਨ ਕਿ filters ਕਿਸੇ ਦਿੱਤੀ ਧਾਰਣਾ ਨੂੰ ਕਿੰਨਾ ਪ੍ਰਭਾਵਿਤ ਕਰ ਰਹੇ ਸਨ।

ਇਸ ਨੂੰ ਅਮਲ ਵਿੱਚ ਲਿਆਂਦੇ ਹੋਏ, ਅਸੀਂ ਦੋਵੇਂ filtered ਅਤੇ unfiltered ਡਾਟਾਸੈੱਟਾਂ ਦੀਆਂ ਸਾਰੀਆਂ captions 'ਤੇ ਕੁਝ keywords (ਜਿਵੇਂ “parent”, “woman”, “kid”) ਦੀ frequency ਗਿਣਣ ਲਈ Apache Spark ਵਰਤੀ। ਭਾਵੇਂ ਸਾਡੇ ਡਾਟਾਸੈੱਟ ਵਿੱਚ ਸੈਂਕੜੇ ਮਿਲੀਅਨ text-image ਜੋੜੇ ਹਨ, ਸਾਡੇ compute cluster ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਇਹ keyword frequencies ਗਿਣਣ ਵਿੱਚ ਸਿਰਫ਼ ਕੁਝ ਮਿੰਟ ਲੱਗੇ।

keyword frequencies ਗਿਣਣ ਤੋਂ ਬਾਅਦ, ਅਸੀਂ ਪੁਸ਼ਟੀ ਕਰ ਸਕੇ ਕਿ ਸਾਡੇ ਡਾਟਾਸੈੱਟ filters ਨੇ ਵਾਸਤਵ ਵਿੱਚ ਕੁਝ keywords ਦੀ frequency ਨੂੰ ਹੋਰਾਂ ਨਾਲੋਂ ਵੱਧ skew ਕੀਤਾ ਸੀ। ਉਦਾਹਰਨ ਵਜੋਂ, filters ਨੇ “woman” ਸ਼ਬਦ ਦੀ frequency 14% ਘਟਾਈ, ਜਦਕਿ “man” ਸ਼ਬਦ ਦੀ frequency ਸਿਰਫ਼ 6% ਘਟੀ। ਇਸ ਨੇ ਵੱਡੇ ਪੱਧਰ 'ਤੇ ਉਸ ਗੱਲ ਦੀ ਪੁਸ਼ਟੀ ਕੀਤੀ ਜੋ ਅਸੀਂ ਪਹਿਲਾਂ ਹੀ ਦੋਵੇਂ ਡਾਟਾਸੈੱਟਾਂ 'ਤੇ ਟ੍ਰੇਨ ਕੀਤੇ GLIDE ਮਾਡਲਾਂ ਤੋਂ ਨਮੂਨੇ ਲੈ ਕੇ ਤਜਰਬੇਕਾਰੀ ਤੌਰ 'ਤੇ ਵੇਖ ਚੁੱਕੇ ਸਨ।

ਹੁਣ ਜਦੋਂ ਸਾਡੇ ਕੋਲ filter-induced bias ਮਾਪਣ ਲਈ ਇੱਕ proxy ਸੀ, ਸਾਨੂੰ ਇਸਦਾ ਉਪਸ਼ਮਨ ਕਰਨ ਦਾ ਤਰੀਕਾ ਚਾਹੀਦਾ ਸੀ। ਇਸ ਸਮੱਸਿਆ ਨਾਲ ਨਿਪਟਣ ਲਈ, ਅਸੀਂ filtered ਡਾਟਾਸੈੱਟ ਨੂੰ ਇਸ ਤਰ੍ਹਾਂ re-weight ਕਰਨ ਦਾ ਲਕਸ਼ ਰੱਖਿਆ ਕਿ ਇਸਦੀ distribution, unfiltered ਚਿੱਤਰਾਂ ਦੀ distribution ਨਾਲ ਹੋਰ ਚੰਗੀ ਤਰ੍ਹਾਂ ਮੇਲ ਖਾਏ। ਇਸ ਵਿਚਾਰ ਨੂੰ ਸਮਝਾਉਣ ਲਈ ਇੱਕ ਸਧਾਰਣ ਉਦਾਹਰਨ ਲਓ: ਮੰਨ ਲਓ ਸਾਡੇ ਡਾਟਾਸੈੱਟ ਵਿੱਚ 50% ਬਿੱਲੀਆਂ ਦੀਆਂ ਤਸਵੀਰਾਂ ਅਤੇ 50% ਕੁੱਤਿਆਂ ਦੀਆਂ ਤਸਵੀਰਾਂ ਹਨ, ਪਰ ਸਾਡੇ ਡਾਟਾ ਫਿਲਟਰ 75% ਕੁੱਤਿਆਂ ਨੂੰ ਹਟਾ ਦਿੰਦੇ ਹਨ ਜਦਕਿ ਸਿਰਫ਼ 50% ਬਿੱਲੀਆਂ ਨੂੰ। ਅੰਤਿਮ ਡਾਟਾਸੈੱਟ ⅔ ਬਿੱਲੀਆਂ ਅਤੇ ⅓ ਕੁੱਤੇ ਰਹਿ ਜਾਵੇਗਾ, ਅਤੇ ਇਸ ਡਾਟਾਸੈੱਟ 'ਤੇ ਟ੍ਰੇਨ ਕੀਤਾ likelihood-based ਜਨਰੇਟਿਵ ਮਾਡਲ ਸੰਭਾਵਤ ਤੌਰ 'ਤੇ ਕੁੱਤਿਆਂ ਨਾਲੋਂ ਬਿੱਲੀਆਂ ਦੀਆਂ ਵੱਧ ਤਸਵੀਰਾਂ ਬਣਾਏਗਾ। ਅਸੀਂ ਇਸ ਅਸੰਤੁਲਨ ਨੂੰ ਹਰ ਕੁੱਤੇ ਵਾਲੇ ਚਿੱਤਰ ਦੀ training loss ਨੂੰ 2 ਨਾਲ ਗੁਣਾ ਕਰਕੇ ਠੀਕ ਕਰ ਸਕਦੇ ਹਾਂ, ਜੋ ਹਰ ਕੁੱਤੇ ਵਾਲੇ ਚਿੱਤਰ ਨੂੰ ਦੋ ਵਾਰ ਦੁਹਰਾਉਣ ਦੇ ਪ੍ਰਭਾਵ ਦੀ ਨਕਲ ਕਰਦਾ ਹੈ। ਪਤਾ ਲੱਗਦਾ ਹੈ ਕਿ ਅਸੀਂ ਇਸ ਤਰੀਕੇ ਨੂੰ ਆਪਣੇ ਅਸਲੀ ਡਾਟਾਸੈੱਟਾਂ ਅਤੇ ਮਾਡਲਾਂ ਤੱਕ ਵੱਡੇ ਪੱਧਰ 'ਤੇ ਲੈ ਜਾ ਸਕਦੇ ਹਾਂ, ਅਤੇ ਇਹ ਕਾਫ਼ੀ ਹੱਦ ਤੱਕ ਆਟੋਮੈਟਿਕ ਹੈ–ਅਰਥਾਤ, ਸਾਨੂੰ ਉਹ features ਹੱਥੋਂ ਨਹੀਂ ਚੁਣਣੇ ਪੈਂਦੇ ਜਿਨ੍ਹਾਂ ਨੂੰ ਅਸੀਂ reweight ਕਰਨਾ ਚਾਹੁੰਦੇ ਹਾਂ।

ਅਸੀਂ filtered ਡਾਟਾਸੈੱਟ ਦੇ ਚਿੱਤਰਾਂ ਲਈ ਇੱਕ ਖ਼ਾਸ classifier ਤੋਂ ਮਿਲਣ ਵਾਲੀਆਂ probabilities ਦੀ ਵਰਤੋਂ ਕਰਕੇ weights ਗਿਣਦੇ ਹਾਂ, ਜੋ Choi et al. (2019)⁠(ਨਵੀਂ ਵਿੰਡੋ ਵਿੱਚ ਖੁੱਲ੍ਹਦਾ ਹੈ) ਦੀ ਪਹੁੰਚ ਵਰਗੀ ਹੈ। ਇਸ classifier ਨੂੰ ਟ੍ਰੇਨ ਕਰਨ ਲਈ, ਅਸੀਂ ਦੋਵੇਂ ਡਾਟਾਸੈੱਟਾਂ ਵਿੱਚੋਂ ਸਮਾਨ ਤੌਰ 'ਤੇ ਚਿੱਤਰ sample ਕਰਦੇ ਹਾਂ ਅਤੇ ਅਨੁਮਾਨ ਲਗਾਉਂਦੇ ਹਾਂ ਕਿ ਚਿੱਤਰ ਕਿਸ ਡਾਟਾਸੈੱਟ ਤੋਂ ਆਇਆ। ਖ਼ਾਸ ਤੌਰ 'ਤੇ, ਇਹ ਮਾਡਲ P(unfiltered|image) ਦਾ ਅਨੁਮਾਨ ਲਗਾਉਂਦਾ ਹੈ, ਜਿੱਥੇ prior P(unfiltered) = 0.5 ਹੈ। ਅਮਲ ਵਿੱਚ, ਅਸੀਂ ਨਹੀਂ ਚਾਹੁੰਦੇ ਕਿ ਇਹ ਮਾਡਲ ਬਹੁਤ ਸ਼ਕਤੀਸ਼ਾਲੀ ਹੋਵੇ, ਨਹੀਂ ਤਾਂ ਇਹ ਸਾਡੇ filters ਦੁਆਰਾ ਲਾਗੂ ਕੀਤੀ ਗਈ ਠੀਕ-ਠੀਕ function ਹੀ ਸਿੱਖ ਸਕਦਾ ਹੈ। ਇਸ ਦੀ ਬਜਾਇ, ਅਸੀਂ ਚਾਹੁੰਦੇ ਹਾਂ ਕਿ ਇਹ ਮਾਡਲ ਸਾਡੇ ਮੂਲ ਡਾਟਾ filters ਨਾਲੋਂ ਹੋਰ smooth ਹੋਵੇ, ਉਹ ਵਿਸ਼ਾਲ ਸ਼੍ਰੇਣੀਆਂ ਪਕੜੇ ਜਿਨ੍ਹਾਂ 'ਤੇ filters ਅਸਰ ਕਰਦੇ ਹਨ, ਅਤੇ ਫਿਰ ਵੀ ਇਸ ਬਾਰੇ ਅਨਿਸ਼ਚਿਤ ਰਹੇ ਕਿ ਕੋਈ ਖ਼ਾਸ ਚਿੱਤਰ filter ਹੋਵੇਗਾ ਜਾਂ ਨਹੀਂ। ਇਸ ਲਈ, ਅਸੀਂ ਇੱਕ ਛੋਟੇ CLIP⁠ ਮਾਡਲ ਦੇ ਉੱਪਰ ਇੱਕ linear probe ਟ੍ਰੇਨ ਕੀਤਾ।

ਜਦੋਂ ਸਾਡੇ ਕੋਲ ਇੱਕ classifier ਆ ਜਾਂਦਾ ਹੈ ਜੋ ਅਨੁਮਾਨ ਲਗਾਉਂਦਾ ਹੈ ਕਿ ਕੋਈ ਚਿੱਤਰ unfiltered ਡਾਟਾਸੈੱਟ ਤੋਂ ਹੋਣ ਦੀ ਸੰਭਾਵਨਾ ਕੀ ਹੈ, ਤਦ ਵੀ ਸਾਨੂੰ ਇਸ ਅਨੁਮਾਨ ਨੂੰ ਉਸ ਚਿੱਤਰ ਲਈ weight ਵਿੱਚ ਬਦਲਣਾ ਲੋੜੀਂਦਾ ਹੈ। ਉਦਾਹਰਨ ਵਜੋਂ, ਮੰਨੋ ਕਿ P(unfiltered|image) = 0.8 ਹੈ। ਇਸਦਾ ਅਰਥ ਹੈ ਕਿ ਇਹ ਨਮੂਨਾ filtered ਡਾਟਾ ਨਾਲੋਂ unfiltered ਡਾਟਾ ਵਿੱਚ 4 ਗੁਣਾ ਵੱਧ ਮਿਲਣ ਦੀ ਸੰਭਾਵਨਾ ਰੱਖਦਾ ਹੈ, ਅਤੇ 4 ਦਾ weight ਇਸ ਅਸੰਤੁਲਨ ਨੂੰ ਠੀਕ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ। ਹੋਰ ਆਮ ਤੌਰ 'ਤੇ, ਅਸੀਂ weight P(unfiltered|image)/P(filtered|image) ਵਰਤ ਸਕਦੇ ਹਾਂ.^A

ਇਹ reweighting ਸਕੀਮ ਅਸਲ ਵਿੱਚ ਵਧੇ ਹੋਏ ਪੱਖਪਾਤ ਦਾ ਉਪਸ਼ਮਨ ਕਿੰਨਾ ਕਰਦੀ ਹੈ? ਜਦੋਂ ਅਸੀਂ ਆਪਣੀ ਪੁਰਾਣੀ filtered ਮਾਡਲ ਨੂੰ ਨਵੀਂ weighting ਸਕੀਮ ਨਾਲ fine-tune ਕੀਤਾ, ਤਾਂ biased ਉਦਾਹਰਨਾਂ 'ਤੇ fine-tuned ਮਾਡਲ ਦਾ ਵਿਹਾਰ ਉਹ unfiltered ਮਾਡਲ ਨਾਲ ਕਾਫ਼ੀ ਵੱਧ ਮਿਲਦਾ ਸੀ ਜੋ ਅਸੀਂ ਪਹਿਲਾਂ ਲੱਭਿਆ ਸੀ। ਹਾਲਾਂਕਿ ਇਹ ਹੌਸਲਾਅਫ਼ਜ਼ਾਈ ਵਾਲਾ ਸੀ, ਅਸੀਂ ਆਪਣੀ keyword-based bias heuristic ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਇਸ ਉਪਸ਼ਮਨ ਦਾ ਹੋਰ ਵਿਸਥਾਰ ਨਾਲ ਮੁਲਾਂਕਣ ਵੀ ਕਰਨਾ ਚਾਹੁੰਦੇ ਸਨ। ਆਪਣੀ ਨਵੀਂ weighting ਸਕੀਮ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖਦੇ ਹੋਏ keyword frequencies ਮਾਪਣ ਲਈ, ਅਸੀਂ filtered ਡਾਟਾਸੈੱਟ ਵਿੱਚ ਕਿਸੇ keyword ਦੀ ਹਰ occurrence ਨੂੰ ਉਸ sample ਦੇ weight ਨਾਲ ਗੁਣਾ ਕਰ ਸਕਦੇ ਹਾਂ ਜਿਸ ਵਿੱਚ ਉਹ keyword ਮੌਜੂਦ ਹੈ। ਇਹ ਕਰਨ ਨਾਲ ਸਾਨੂੰ keyword frequencies ਦਾ ਇੱਕ ਨਵਾਂ ਸੈੱਟ ਮਿਲਦਾ ਹੈ ਜੋ filtered ਡਾਟਾਸੈੱਟ ਵਿੱਚ sample weights ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ।

ਜਿਨ੍ਹਾਂ keywords ਦੀ ਅਸੀਂ ਜਾਂਚ ਕੀਤੀ, ਉਨ੍ਹਾਂ ਵਿੱਚੋਂ ਬਹੁਤਿਆਂ ਲਈ reweighting ਸਕੀਮ ਨੇ filtering ਕਾਰਨ ਆਏ frequency change ਨੂੰ ਘਟਾਇਆ। “man” ਅਤੇ “woman” ਵਾਲੇ ਸਾਡੇ ਪਹਿਲਾਂ ਦੇ ਉਦਾਹਰਨਾਂ ਵਿੱਚ, relative frequency reductions ਕ੍ਰਮਵਾਰ 1% ਅਤੇ –1% ਹੋ ਗਏ, ਜਦਕਿ ਪਹਿਲਾਂ ਇਹ ਮੁੱਲ 14% ਅਤੇ 6% ਸਨ। ਹਾਲਾਂਕਿ ਇਹ metric ਅਸਲ filtering bias ਲਈ ਸਿਰਫ਼ ਇੱਕ proxy ਹੈ, ਫਿਰ ਵੀ ਇਹ ਭਰੋਸਾ ਦਿੰਦਾ ਹੈ ਕਿ ਸਾਡੀ image-based reweighting ਸਕੀਮ ਇੱਕ text-based metric ਨੂੰ ਵੀ ਇੰਨਾ ਮਹੱਤਵਪੂਰਨ ਤੌਰ 'ਤੇ ਸੁਧਾਰਦੀ ਹੈ।

ਅਸੀਂ DALL·E 2 ਵਿੱਚ ਬਚੇ ਹੋਏ ਪੱਖਪਾਤਾਂ ਦੀ ਜਾਂਚ ਜਾਰੀ ਰੱਖ ਰਹੇ ਹਾਂ, ਕੁਝ ਹੱਦ ਤੱਕ ਮਾਡਲ ਦੇ ਵਿਹਾਰ ਦੇ ਵੱਡੇ ਮੁਲਾਂਕਣਾਂ ਅਤੇ ਇਸ ਗੱਲ ਦੀ ਜਾਂਚ ਰਾਹੀਂ ਕਿ filtering ਨੇ bias ਅਤੇ capability development 'ਤੇ ਕਿਵੇਂ ਅਸਰ ਪਾਇਆ।

ਅਸੀਂ ਵੇਖਿਆ ਕਿ DALL·E 2 ਤੋਂ ਪਹਿਲਾਂ ਦੇ ਸਾਡੇ ਅੰਦਰੂਨੀ ਮਾਡਲ ਕਈ ਵਾਰ ਟ੍ਰੇਨਿੰਗ ਚਿੱਤਰਾਂ ਨੂੰ ਸ਼ਬਦਸ਼: ਦੁਹਰਾਉਂਦੇ ਸਨ। ਇਹ ਵਿਹਾਰ ਅਚਾਹੁੰਦਾ ਸੀ, ਕਿਉਂਕਿ ਅਸੀਂ ਚਾਹੁੰਦੇ ਹਾਂ ਕਿ DALL·E 2 ਡਿਫਾਲਟ ਤੌਰ 'ਤੇ ਮੂਲ, ਵਿਲੱਖਣ ਚਿੱਤਰ ਬਣਾਏ ਅਤੇ ਸਿਰਫ਼ ਮੌਜੂਦਾ ਚਿੱਤਰਾਂ ਦੇ ਟੁਕੜਿਆਂ ਨੂੰ “ਜੋੜੇ” ਨਾ। ਇਸ ਤੋਂ ਇਲਾਵਾ, ਟ੍ਰੇਨਿੰਗ ਚਿੱਤਰਾਂ ਨੂੰ ਸ਼ਬਦਸ਼: ਦੁਹਰਾਉਣਾ ਕਾਪੀਰਾਈਟ ਉਲੰਘਣਾ, ਮਾਲਕੀ ਅਤੇ ਪਰਦੇਦਾਰੀ ਬਾਰੇ ਕਾਨੂੰਨੀ ਸਵਾਲ ਖੜੇ ਕਰ ਸਕਦਾ ਹੈ (ਜੇ ਲੋਕਾਂ ਦੀਆਂ ਤਸਵੀਰਾਂ ਟ੍ਰੇਨਿੰਗ ਡਾਟਾ ਵਿੱਚ ਮੌਜੂਦ ਸਨ)।

ਇਮੇਜ regurgitation ਦੀ ਸਮੱਸਿਆ ਨੂੰ ਵਧੀਆ ਸਮਝਣ ਲਈ, ਅਸੀਂ ਐਸੇ ਪ੍ਰੌੰਪਟਾਂ ਦਾ ਇੱਕ ਡਾਟਾਸੈੱਟ ਇਕੱਠਾ ਕੀਤਾ ਜਿਨ੍ਹਾਂ ਨਾਲ ਅਕਸਰ ਨਕਲ ਚਿੱਤਰ ਬਣਦੇ ਸਨ। ਇਹ ਕਰਨ ਲਈ, ਅਸੀਂ ਇੱਕ ਟ੍ਰੇਨ ਕੀਤਾ ਮਾਡਲ ਵਰਤਿਆ ਜਿਸ ਨਾਲ ਆਪਣੇ ਟ੍ਰੇਨਿੰਗ ਡਾਟਾਸੈੱਟ ਦੇ 50,000 ਪ੍ਰੌੰਪਟਾਂ ਲਈ ਚਿੱਤਰ ਨਮੂਨੇ ਬਣਾਏ, ਅਤੇ ਉਹਨਾਂ ਨਮੂਨਿਆਂ ਨੂੰ ਸੰਬੰਧਿਤ ਟ੍ਰੇਨਿੰਗ ਚਿੱਤਰ ਨਾਲ perceptual similarity ਦੇ ਅਧਾਰ 'ਤੇ ਕ੍ਰਮਬੱਧ ਕੀਤਾ। ਅੰਤ ਵਿੱਚ, ਅਸੀਂ ਉੱਪਰੀ ਮੈਚਾਂ ਦੀ ਹੱਥੋਂ ਜਾਂਚ ਕੀਤੀ ਅਤੇ ਕੁੱਲ 50k ਪ੍ਰੌੰਪਟਾਂ ਵਿੱਚੋਂ ਸਿਰਫ਼ ਕੁਝ ਸੌ ਅਸਲੀ duplicate ਜੋੜੇ ਲੱਭੇ। ਭਾਵੇਂ regurgitation ਦਰ 1% ਤੋਂ ਘੱਟ ਲੱਗੀ, ਫਿਰ ਵੀ ਉੱਪਰ ਦਿੱਤੇ ਕਾਰਣਾਂ ਕਰਕੇ ਅਸੀਂ ਇਹ ਦਰ 0 ਤੱਕ ਲਿਆਉਣਾ ਜ਼ਰੂਰੀ ਸਮਝਿਆ।

ਜਦੋਂ ਅਸੀਂ regurgitated ਚਿੱਤਰਾਂ ਵਾਲੇ ਆਪਣੇ ਡਾਟਾਸੈੱਟ ਦਾ ਅਧਿਐਨ ਕੀਤਾ, ਸਾਨੂੰ ਦੋ ਪੈਟਰਨ ਨਜ਼ਰ ਆਏ। ਪਹਿਲਾਂ, ਚਿੱਤਰ ਲਗਭਗ ਸਾਰੇ ਸਾਦੇ vector graphics ਸਨ, ਜਿਨ੍ਹਾਂ ਨੂੰ ਸੰਭਾਵਤ ਤੌਰ 'ਤੇ ਘੱਟ ਜਾਣਕਾਰੀ ਸਮੱਗਰੀ ਕਾਰਨ ਯਾਦ ਰੱਖਣਾ ਆਸਾਨ ਸੀ। ਦੂਜਾ, ਅਤੇ ਹੋਰ ਮਹੱਤਵਪੂਰਨ, ਇਹਨਾਂ ਸਾਰੇ ਚਿੱਤਰਾਂ ਦੇ ਟ੍ਰੇਨਿੰਗ ਡਾਟਾਸੈੱਟ ਵਿੱਚ ਬਹੁਤ ਸਾਰੇ near-duplicates ਸਨ। ਉਦਾਹਰਨ ਵਜੋਂ, ਇੱਕ vector graphic ਹੋ ਸਕਦੀ ਹੈ ਜੋ 1 ਵਜੇ ਦਾ ਸਮਾਂ ਦਿਖਾਉਂਦੀ ਘੜੀ ਵਰਗੀ ਲੱਗੇ—ਪਰ ਫਿਰ ਸਾਨੂੰ ਉਸੇ ਘੜੀ ਦੀ 2 ਵਜੇ ਵਾਲੀ ਟ੍ਰੇਨਿੰਗ ਨਮੂਨਾ ਮਿਲ ਜਾਂਦੀ, ਫਿਰ 3 ਵਜੇ ਵਾਲੀ, ਆਦਿ। ਜਦੋਂ ਸਾਨੂੰ ਇਹ ਗੱਲ ਸਮਝ ਆਈ, ਅਸੀਂ distributed nearest neighbor search ਵਰਤ ਕੇ ਪੁਸ਼ਟੀ ਕੀਤੀ ਕਿ ਦਰਅਸਲ ਸਾਰੇ regurgitated ਚਿੱਤਰਾਂ ਦੇ ਡਾਟਾਸੈੱਟ ਵਿੱਚ perceptually similar duplicates ਮੌਜੂਦ ਸਨ। ਹੋਰ⁠(ਨਵੀਂ ਵਿੰਡੋ ਵਿੱਚ ਖੁੱਲ੍ਹਦਾ ਹੈ) ਕੰਮਾਂ⁠(ਨਵੀਂ ਵਿੰਡੋ ਵਿੱਚ ਖੁੱਲ੍ਹਦਾ ਹੈ) ਨੇ ਵੱਡੇ language models ਵਿੱਚ ਮਿਲਦੀ-ਜੁਲਦੀ ਘਟਨਾ ਵੇਖੀ ਹੈ, ਜਿੱਥੇ ਡਾਟਾ duplication ਦਾ memorization ਨਾਲ ਮਜ਼ਬੂਤ ਸੰਬੰਧ ਮਿਲਦਾ ਹੈ।

ਉਪਰੋਕਤ ਨਤੀਜੇ ਨੇ ਸੰਕੇਤ ਦਿੱਤਾ ਕਿ ਜੇ ਅਸੀਂ ਆਪਣੇ ਡਾਟਾਸੈੱਟ ਦੀ deduplication ਕਰੀਏ, ਤਾਂ ਸ਼ਾਇਦ ਅਸੀਂ regurgitation ਸਮੱਸਿਆ ਹੱਲ ਕਰ ਸਕੀਏ। ਇਹ ਹਾਸਲ ਕਰਨ ਲਈ, ਅਸੀਂ ਇੱਕ neural network ਵਰਤਣ ਦੀ ਯੋਜਨਾ ਬਣਾਈ ਜੋ ਇੱਕੋ ਜਿਹੇ ਲੱਗਦੇ ਚਿੱਤਰਾਂ ਦੇ ਸਮੂਹ ਪਛਾਣੇ, ਅਤੇ ਫਿਰ ਹਰ ਸਮੂਹ ਵਿੱਚੋਂ ਇੱਕ ਨੂੰ ਛੱਡ ਕੇ ਬਾਕੀ ਸਾਰੇ ਚਿੱਤਰ ਹਟਾ ਦੇਵੇ.^B

ਹਾਲਾਂਕਿ, ਇਸ ਲਈ ਹਰ ਚਿੱਤਰ ਲਈ ਇਹ ਜਾਂਚਣਾ ਲੋੜੀਂਦਾ ਸੀ ਕਿ ਕੀ ਉਹ ਡਾਟਾਸੈੱਟ ਦੇ ਹਰ ਹੋਰ ਚਿੱਤਰ ਦੀ duplicate ਹੈ। ਕਿਉਂਕਿ ਸਾਡੇ ਪੂਰੇ ਡਾਟਾਸੈੱਟ ਵਿੱਚ ਸੈਂਕੜੇ ਮਿਲੀਅਨ ਚਿੱਤਰ ਹਨ, ਸਾਰੇ duplicates ਲੱਭਣ ਲਈ ਸਾਨੂੰ ਸਧਾਰਣ ਤਰੀਕੇ ਨਾਲ ਸੈਂਕੜੇ quadrillions ਚਿੱਤਰ ਜੋੜਿਆਂ ਦੀ ਜਾਂਚ ਕਰਨੀ ਪੈਂਦੀ। ਹਾਲਾਂਕਿ ਇਹ ਤਕਨੀਕੀ ਤੌਰ 'ਤੇ ਸੰਭਵ ਹੈ, ਖ਼ਾਸਕਰ ਵੱਡੇ compute cluster 'ਤੇ, ਸਾਨੂੰ ਇੱਕ ਕਾਫ਼ੀ ਕੁਸ਼ਲ ਵਿਕਲਪ ਮਿਲਿਆ ਜੋ ਲਗਭਗ ਉਤਨਾ ਹੀ ਵਧੀਆ ਕੰਮ ਕਰਦਾ ਹੈ ਪਰ ਲਾਗਤ ਦਾ ਬਹੁਤ ਛੋਟਾ ਹਿੱਸਾ ਲੈਂਦਾ ਹੈ। ਸੋਚੋ ਕਿ ਜੇ ਅਸੀਂ deduplication ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਆਪਣੇ ਡਾਟਾਸੈੱਟ ਨੂੰ cluster ਕਰੀਏ ਤਾਂ ਕੀ ਹੁੰਦਾ ਹੈ। ਕਿਉਂਕਿ ਨੇੜਲੇ ਨਮੂਨੇ ਅਕਸਰ ਇੱਕੋ cluster ਵਿੱਚ ਆ ਜਾਂਦੇ ਹਨ, duplicate ਜੋੜਿਆਂ ਵਿੱਚੋਂ ਜ਼ਿਆਦਾਤਰ cluster decision boundaries ਨੂੰ ਪਾਰ ਨਹੀਂ ਕਰਨਗੇ। ਫਿਰ ਅਸੀਂ ਹਰ cluster ਦੇ ਅੰਦਰ ਨਮੂਨਿਆਂ ਦੀ deduplication ਕਰ ਸਕਦੇ ਹਾਂ ਬਿਨਾਂ cluster ਤੋਂ ਬਾਹਰ duplicates ਦੀ ਜਾਂਚ ਕੀਤੇ, ਅਤੇ ਫਿਰ ਵੀ duplicate ਜੋੜਿਆਂ ਵਿੱਚੋਂ ਸਿਰਫ਼ ਇੱਕ ਛੋਟਾ ਹਿੱਸਾ ਹੀ ਛੁੱਟੇਗਾ। ਇਹ ਸਧਾਰਣ ਤਰੀਕੇ ਨਾਲੋਂ ਕਾਫ਼ੀ ਤੇਜ਼ ਹੈ, ਕਿਉਂਕਿ ਹੁਣ ਸਾਨੂੰ ਚਿੱਤਰਾਂ ਦੇ ਹਰ ਇੱਕ ਜੋੜੇ ਦੀ ਜਾਂਚ ਨਹੀਂ ਕਰਨੀ ਪੈਂਦੀ.^C

ਜਦੋਂ ਅਸੀਂ ਇਸ ਤਰੀਕੇ ਦੀ ਆਪਣੇ ਡਾਟਾ ਦੇ ਇੱਕ ਛੋਟੇ subset 'ਤੇ ਪ੍ਰਯੋਗਾਤਮਕ ਜਾਂਚ ਕੀਤੀ, ਤਾਂ K=1024 clusters ਵਰਤਣ 'ਤੇ ਇਸ ਨੇ ਸਾਰੇ duplicate ਜੋੜਿਆਂ ਵਿੱਚੋਂ 85% ਲੱਭ ਲਏ। ਉਪਰੋਕਤ algorithm ਦੀ ਸਫਲਤਾ ਦਰ ਸੁਧਾਰਣ ਲਈ, ਅਸੀਂ ਇੱਕ ਮਹੱਤਵਪੂਰਨ ਅਵਲੋਕਨ ਦਾ ਲਾਭ ਲਿਆ: ਜਦੋਂ ਤੁਸੀਂ ਕਿਸੇ ਡਾਟਾਸੈੱਟ ਦੇ ਵੱਖਰੇ random subsets ਨੂੰ cluster ਕਰਦੇ ਹੋ, ਤਾਂ ਬਣੀਆਂ cluster decision boundaries ਅਕਸਰ ਕਾਫ਼ੀ ਵੱਖਰੀਆਂ ਹੁੰਦੀਆਂ ਹਨ। ਇਸ ਲਈ, ਜੇ ਕੋਈ duplicate ਜੋੜਾ ਇੱਕ clustering ਵਿੱਚ boundary ਪਾਰ ਕਰਦਾ ਹੈ, ਤਾਂ ਉਹੀ ਜੋੜਾ ਕਿਸੇ ਹੋਰ clustering ਵਿੱਚ ਇੱਕੋ cluster ਦੇ ਅੰਦਰ ਆ ਸਕਦਾ ਹੈ। ਜਿੰਨੀਆਂ ਵੱਧ clusterings ਤੁਸੀਂ ਅਜ਼ਮਾਉਂਦੇ ਹੋ, ਕਿਸੇ ਦਿੱਤੇ duplicate ਜੋੜੇ ਨੂੰ ਲੱਭਣ ਦੀ ਸੰਭਾਵਨਾ ਉਤਨੀ ਵੱਧ ਹੁੰਦੀ ਹੈ। ਅਮਲ ਵਿੱਚ, ਅਸੀਂ ਪੰਜ clusterings ਵਰਤਣ ਦਾ ਫੈਸਲਾ ਕੀਤਾ, ਜਿਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਅਸੀਂ ਹਰ ਚਿੱਤਰ ਦੇ duplicates ਨੂੰ ਪੰਜ ਵੱਖਰੇ clusters ਦੇ union ਵਿੱਚ ਲੱਭਦੇ ਹਾਂ। ਅਮਲ ਵਿੱਚ, ਇਸ ਤਰੀਕੇ ਨਾਲ ਸਾਡੇ ਡਾਟਾ ਦੇ ਇੱਕ subset 'ਤੇ ਸਾਰੇ duplicate ਜੋੜਿਆਂ ਵਿੱਚੋਂ 97% ਮਿਲ ਗਏ।

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

ਆਪਣੇ ਮਾਡਲਾਂ 'ਤੇ deduplication ਦੇ ਅਸਰ ਦੀ ਜਾਂਚ ਕਰਨ ਲਈ, ਅਸੀਂ ਇੱਕੋ hyperparameters ਨਾਲ ਦੋ ਮਾਡਲ ਟ੍ਰੇਨ ਕੀਤੇ: ਇੱਕ ਪੂਰੇ ਡਾਟਾਸੈੱਟ 'ਤੇ ਅਤੇ ਇੱਕ ਡਾਟਾਸੈੱਟ ਦੇ deduplicated ਵਰਜਨ 'ਤੇ। ਮਾਡਲਾਂ ਦੀ ਤੁਲਨਾ ਲਈ, ਅਸੀਂ ਉਹੀ ਮਨੁੱਖੀ ਮੁਲਾਂਕਣ ਵਰਤੇ ਜੋ ਅਸੀਂ ਆਪਣੇ ਮੂਲ GLIDE ਮਾਡਲ ਦਾ ਮੁਲਾਂਕਣ ਕਰਨ ਲਈ ਵਰਤੇ ਸਨ। ਹੈਰਾਨੀ ਦੀ ਗੱਲ ਇਹ ਸੀ ਕਿ ਮਨੁੱਖੀ evaluators ਨੇ deduplicated ਡਾਟਾ 'ਤੇ ਟ੍ਰੇਨ ਕੀਤੇ ਮਾਡਲ ਨੂੰ ਹਲਕਾ ਜਿਹਾ ਤਰਜੀਹ ਦਿੱਤੀ, ਜਿਸ ਨਾਲ ਇਸ਼ਾਰਾ ਮਿਲਦਾ ਹੈ ਕਿ ਡਾਟਾਸੈੱਟ ਵਿੱਚ ਵਾਧੂ ਦੁਹਰਾਏ ਚਿੱਤਰਾਂ ਦੀ ਵੱਡੀ ਮਾਤਰਾ ਅਸਲ ਵਿੱਚ ਕਾਰਗੁਜ਼ਾਰੀ ਨੂੰ ਨੁਕਸਾਨ ਪਹੁੰਚਾ ਰਹੀ ਸੀ।

ਜਦੋਂ ਸਾਡੇ ਕੋਲ deduplicated ਡਾਟਾ 'ਤੇ ਟ੍ਰੇਨ ਕੀਤਾ ਮਾਡਲ ਆ ਗਿਆ, ਅਸੀਂ ਟ੍ਰੇਨਿੰਗ ਡਾਟਾਸੈੱਟ ਦੇ 50k ਪ੍ਰੌੰਪਟਾਂ 'ਤੇ ਪਹਿਲਾਂ ਕੀਤੀ regurgitation ਖੋਜ ਨੂੰ ਮੁੜ ਚਲਾਇਆ। ਅਸੀਂ ਪਾਇਆ ਕਿ ਨਵਾਂ ਮਾਡਲ, ਜਦੋਂ ਉਸਨੂੰ ਟ੍ਰੇਨਿੰਗ ਡਾਟਾਸੈੱਟ ਵਾਲੇ ਚਿੱਤਰ ਦਾ ਬਿਲਕੁਲ ਉਹੀ ਪ੍ਰੌੰਪਟ ਦਿੱਤਾ ਗਿਆ, ਤਦੋਂ ਕਦੇ ਵੀ ਟ੍ਰੇਨਿੰਗ ਚਿੱਤਰ ਨੂੰ regurgitate ਨਹੀਂ ਕਰਦਾ ਸੀ। ਇਸ ਜਾਂਚ ਨੂੰ ਇੱਕ ਕਦਮ ਹੋਰ ਅੱਗੇ ਵਧਾਉਣ ਲਈ, ਅਸੀਂ 50k ਬਣੇ ਚਿੱਤਰਾਂ ਵਿੱਚੋਂ ਹਰ ਇੱਕ ਲਈ ਪੂਰੇ ਟ੍ਰੇਨਿੰਗ ਡਾਟਾਸੈੱਟ 'ਤੇ nearest neighbor search ਵੀ ਕੀਤੀ। ਇਸ ਤਰ੍ਹਾਂ, ਸਾਨੂੰ ਲੱਗਿਆ ਕਿ ਸ਼ਾਇਦ ਅਸੀਂ ਉਹ ਕੇਸ ਵੀ ਪਕੜ ਲਵਾਂ ਜਿੱਥੇ ਮਾਡਲ ਕਿਸੇ ਦਿੱਤੇ ਪ੍ਰੌੰਪਟ ਨਾਲ ਸੰਬੰਧਿਤ ਚਿੱਤਰ ਤੋਂ ਵੱਖਰਾ ਚਿੱਤਰ regurgitate ਕਰ ਰਿਹਾ ਹੋਵੇ। ਇੰਨੀ ਵਿਸਥਾਰਪੂਰਨ ਜਾਂਚ ਦੇ ਬਾਵਜੂਦ ਵੀ ਸਾਨੂੰ ਇਮੇਜ regurgitation ਦਾ ਇੱਕ ਵੀ ਕੇਸ ਨਹੀਂ ਮਿਲਿਆ।

ਹਾਲਾਂਕਿ ਉੱਪਰ ਚਰਚਾ ਕੀਤੇ ਸਾਰੇ ਉਪਸ਼ਮਨ DALL·E 2 ਨਾਲ ਜੁੜੇ ਖ਼ਤਰਿਆਂ ਨੂੰ ਘਟਾਉਣ ਦੇ ਸਾਡੇ ਲਕਸ਼ ਵੱਲ ਮਹੱਤਵਪੂਰਨ ਤਰੱਕੀ ਦਰਸਾਉਂਦੇ ਹਨ, ਹਰ ਉਪਸ਼ਮਨ ਵਿੱਚ ਅਜੇ ਵੀ ਸੁਧਾਰ ਦੀ ਗੁੰਜਾਇਸ਼ ਹੈ:

• ਵਧੀਆ ਪ੍ਰੀ-ਟ੍ਰੇਨਿੰਗ ਫਿਲਟਰ ਸਾਨੂੰ DALL·E 2 ਨੂੰ ਹੋਰ ਵੱਧ ਡਾਟਾ 'ਤੇ ਟ੍ਰੇਨ ਕਰਨ ਦੇ ਸਕਦੇ ਹਨ ਅਤੇ ਸੰਭਾਵੀ ਤੌਰ 'ਤੇ ਮਾਡਲ ਵਿੱਚ ਪੱਖਪਾਤ ਨੂੰ ਹੋਰ ਘਟਾ ਸਕਦੇ ਹਨ। ਸਾਡੇ ਮੌਜੂਦਾ ਫਿਲਟਰ ਘੱਟ miss-rate ਲਈ ਟਿਊਨ ਕੀਤੇ ਗਏ ਹਨ, ਪਰ ਇਸ ਦੀ ਕੀਮਤ ਕਈ false positives ਹਨ। ਨਤੀਜੇ ਵਜੋਂ, ਅਸੀਂ ਆਪਣੇ ਪੂਰੇ ਡਾਟਾਸੈੱਟ ਦਾ ਲਗਭਗ 5% ਫਿਲਟਰ ਕਰ ਦਿੱਤਾ, ਭਾਵੇਂ ਇਹਨਾਂ ਵਿਚੋਂ ਜ਼ਿਆਦਾਤਰ ਫਿਲਟਰ ਕੀਤੇ ਚਿੱਤਰ ਸਾਡੀ content policy ਦੀ ਬਿਲਕੁਲ ਵੀ ਉਲੰਘਣਾ ਨਹੀਂ ਕਰਦੇ। ਆਪਣੇ ਫਿਲਟਰ ਸੁਧਾਰਣ ਨਾਲ ਅਸੀਂ ਇਸ ਟ੍ਰੇਨਿੰਗ ਡਾਟਾ ਦਾ ਕੁਝ ਹਿੱਸਾ ਵਾਪਸ ਪ੍ਰਾਪਤ ਕਰ ਸਕਦੇ ਹਾਂ।
• ਪੱਖਪਾਤ ਸਿਸਟਮ ਦੇ ਵਿਕਾਸ ਅਤੇ ਤੈਨਾਤੀ ਦੇ ਕਈ ਪੜਾਅਾਂ 'ਤੇ ਆਉਂਦਾ ਹੈ ਅਤੇ ਸੰਭਾਵੀ ਤੌਰ 'ਤੇ ਵਧ ਜਾਂਦਾ ਹੈ। DALL·E 2 ਵਰਗੇ ਸਿਸਟਮਾਂ ਵਿੱਚ ਪੱਖਪਾਤ ਅਤੇ ਇਸ ਪੱਖਪਾਤ ਨਾਲ ਹੋਣ ਵਾਲੇ ਨੁਕਸਾਨ ਦਾ ਮੁਲਾਂਕਣ ਅਤੇ ਉਪਸ਼ਮਨ ਇੱਕ ਮਹੱਤਵਪੂਰਨ ਅੰਤਰ-ਵਿਸ਼ਯਕ ਸਮੱਸਿਆ ਹੈ ਜਿਸਦਾ ਅਸੀਂ OpenAI ਵਿੱਚ ਆਪਣੇ ਵਿਸ਼ਾਲ ਮਿਸ਼ਨ ਦੇ ਹਿੱਸੇ ਵਜੋਂ ਅਧਿਐਨ ਜਾਰੀ ਰੱਖ ਰਹੇ ਹਾਂ। ਇਸ ਕੰਮ ਵਿੱਚ ਸਮੱਸਿਆ ਨੂੰ ਵਧੀਆ ਸਮਝਣ ਲਈ ਮੁਲਾਂਕਣ ਬਣਾਉਣਾ, ਨਵੇਂ ਡਾਟਾਸੈੱਟ ਸੰਭਾਲਣਾ, ਅਤੇ ਮਨੁੱਖੀ ਫੀਡਬੈਕ ਅਤੇ fine-tuning ਵਰਗੀਆਂ ਤਕਨੀਕਾਂ ਲਾਗੂ ਕਰਕੇ ਹੋਰ ਮਜ਼ਬੂਤ ਅਤੇ ਨੁਮਾਇੰਦਗੀ ਵਾਲੀਆਂ ਤਕਨਾਲੋਜੀਆਂ ਬਣਾਉਣਾ ਸ਼ਾਮਲ ਹੈ।
• ਇਹ ਵੀ ਬਹੁਤ ਜ਼ਰੂਰੀ ਹੈ ਕਿ ਅਸੀਂ ਡੀਪ ਲਰਨਿੰਗ ਸਿਸਟਮਾਂ ਵਿੱਚ memorization ਅਤੇ generalization ਦਾ ਅਧਿਐਨ ਜਾਰੀ ਰੱਖੀਏ। ਹਾਲਾਂਕਿ deduplication memorization ਰੋਕਣ ਵੱਲ ਇੱਕ ਚੰਗਾ ਪਹਿਲਾ ਕਦਮ ਹੈ, ਪਰ ਇਹ ਸਾਨੂੰ ਇਸ ਬਾਰੇ ਸਭ ਕੁਝ ਨਹੀਂ ਦੱਸਦੀ ਕਿ DALL·E 2 ਵਰਗੇ ਮਾਡਲ ਟ੍ਰੇਨਿੰਗ ਡਾਟਾ ਨੂੰ ਕਿਉਂ ਜਾਂ ਕਿਵੇਂ ਯਾਦ ਰੱਖਦੇ ਹਨ।