Andrew Ng ਦੇ ਕੋਰਸ ਅਤੇ ਕੰਪਨੀਆਂ ਨੇ ਲੱਖਾਂ ਡਿਵੈਲਪਰਾਂ ਨੂੰ ਮਸ਼ੀਨ ਲਰਨਿੰਗ ਨਾਲ ਸ਼ੁਰੂ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕੀਤੀ। ਉਸਦੀ ਸਿੱਖਣ ਦੀ ਸ਼ੈਲੀ, ਪ੍ਰਭਾਵ ਅਤੇ عملي ਨਸਖੇ ਜਾਣੋ।

Andrew Ng ਉਹਨਾਂ ਪਹਿਲੀਆਂ ਨਾਮਾਂ ਵਿੱਚੋਂ ਇੱਕ ਹੈ ਜੋ ਬਹੁਤ ਸਾਰੇ ਡਿਵੈਲਪਰ ਦੱਸਦੇ ਹਨ ਜਦੋਂ ਪੁੱਛਿਆ ਜਾਵੇ, “ਤੁਸੀਂ ਏਆਈ ਕਿਵੇਂ ਸਿਖਿਆ ਸੀ?” ਇਹ ਸੰਬੰਧ ਅਣਜਾਣ ਨਹੀਂ ਹੈ। ਉਸਦੇ ਕੋਰਸ ਉਸ ਸਮੇਂ ਆਏ ਜਦੋਂ ਮਸ਼ੀਨ ਲਰਨਿੰਗ ਇੱਕ ਨਿਚ ਰਿਸਰਚ ਵਿਸ਼ਾ ਤੋਂ ਇੱਕ ਪ੍ਰਾਇਕਟਿਕ ਸਕਿੱਲ ਵੱਲ ਬਦਲ ਰਿਹਾ ਸੀ—ਅਤੇ ਉਸਦੀ ਸਿੱਖਿਆ ਨੇ ਪਹਿਲਾ ਕਦਮ ਕਰਨਾ ਸੰਭਵ ਬਣਾਇਆ।
Ng ਮਸ਼ੀਨ ਲਰਨਿੰਗ ਨੂੰ ਸਾਫ਼ ਅਤੇ ਸਪੱਸ਼ਟ ਬਣਤੀਆਂ ਇਮਾਰਤੀ ਇਕਾਈਆਂ ਵਾਂਗ ਸਮਝਾਇਆ: ਸਮੱਸਿਆ ਨਿਰਧਾਰਿਤ ਕਰੋ, ਮਾਡਲ ਚੁਣੋ, ਟ੍ਰੇਨ ਕਰੋ, ਮੁਲਾਂਕਣ ਕਰੋ, ਦੁਹਰਾਓ। ਫਰੇਮਵਰਕ ਸਿਖਣ ਅਤੇ ਫੀਚਰ ਸ਼ਿਪ ਕਰਨ ਵਾਲੇ ਡਿਵੈਲਪਰਾਂ ਲਈ ਉਹ ਰਚਨਾ ਜਾਣੂ ਮਹਿਸੂਸ ਹੁੰਦੀ ਸੀ। ਗਣਿਤ ਨੂੰ ਰਹੱਸਮਈ ਚੀਜ਼ ਵਜੋਂ ਦੇਖਣ ਦੀ ਬਜਾਏ, ਉਸਨੇ ਇਸਨੂੰ ਇੱਕ ਪ੍ਰਾਇਕਟਿਕ ਵਰਕਫਲੋ ਵਜੋਂ ਬਿਆਨ ਕੀਤਾ ਜੋ ਤੁਸੀਂ ਸਿੱਖ ਸਕਦੇ ਹੋ, ਅਭਿਆਸ ਕਰ ਸਕਦੇ ਹੋ ਅਤੇ ਸੁਧਾਰ ਸਕਦੇ ਹੋ।
ਏਆਈ ਨੂੰ ਮੈਨਸਟ੍ਰੀਮ ਬਣਾਉਣ ਦਾ ਮਤਲਬ ਹਰ ਡਿਵੈਲਪਰ ਨੂੰ PhD ਬਣਾਉਣਾ ਨਹੀਂ ਸੀ। ਇਸਦਾ ਮਤਲਬ ਸੀ:
ਬਹੁਤੀਆਂ ਲਈ, ਉਸਦੇ ਕੋਰਸ ਨੇ ਸ਼ੁਰੂਆਤ ਦੀ ਰਕਮ ਘਟਾਈ: ਤੁਹਾਨੂੰ ਲੈਬ, ਮੰਤਰੀ ਜਾਂ ਗ੍ਰੈਜੂਏਟ ਪ੍ਰੋਗ੍ਰਾਮ ਦੀ ਲੋੜ ਨਹੀਂ ਸੀ ਸ਼ੁਰੂ ਕਰਨ ਲਈ।
ਇਹ ਲੇਖ ਇਸ ਗੇਟਵੇ ਕੀਮਤ ਨੂੰ ਤੋੜਦਾ ਹੈ: ਪਹਿਲੀ Stanford ਕੋਰਸ ਜੋ ਕੈਂਪਸ ਦੇ ਪਾਰ ਵਧਿਆ, MOOC ਯੁੱਗ ਜਿਸ ਨੇ ਏਆਈ ਸਿੱਖਣ ਦੀ ਦਿਸ਼ਾ ਬਦਲੀ, ਅਤੇ ਉਹ ਸੰਰਚਨਾ ਜੋ ਜਟਿਲ ਵਿਸ਼ਿਆਂ ਨੂੰ ਸੁਗਮ ਅਤੇ ਕਾਰਜਯੋਗ ਬਣਾਉਂਦੀ ਹੈ। ਅਸੀਂ ਬਾਅਦ ਦੀਆਂ ਵਿਚਾਰਧਾਰਾਵਾਂ ਨੂੰ ਵੀ ਵੇਖਾਂਗੇ—ਜਿਵੇਂ ਡੇਟਾ-ਕੇਂਦਰਿਤ ਏਆਈ ਅਤੇ ਕੈਰੀਅਰ/ਉਤਪਾਦ ਸੋਚ—ਅਤੇ ਸਿੱਖਿਆ ਦੀਆਂ ਸੀਮਾਵਾਂ। ਆਖਿਰ ਵਿੱਚ, ਤੁਸੀਂ ਆਪਣੇ ਸਿੱਖਣ ਅਤੇ ਪ੍ਰਾਜੈਕਟਾਂ ਵਿੱਚ “Ng ਪਹੁੰਚ” ਲਾਗੂ ਕਰਨ ਲਈ ਇੱਕ ਠੋਸ ਐਕਸ਼ਨ ਪਲੈਨ ਮਿਲੇਗਾ।
Andrew Ng ਨੂੰ ਏਆਈ ਸਿੱਖਿਆ ਨਾਲ ਵਿਆਪਕ ਤੌਰ 'ਤੇ ਜੋੜਿਆ ਜਾਂਦਾ ਹੈ, ਪਰ ਉਸਦੀ ਸਿੱਖਣ ਵਾਲੀ ਆਵਾਜ਼ ਸਾਲਾਂ ਦੇ ਰਿਸਰਚ ਅਤੇ ਸਿਸਟਮ ਬਣਾਉਣ ਦੇ ਕੰਮ ਤੋਂ ਟੁੱਟੀ ਹੈ। ਉਸਦੀ ਯਾਤਰਾ ਸਮਝਣ ਨਾਲ ਇਹ ਸਪਸ਼ਟ ਹੋ ਜਾਂਦਾ ਹੈ ਕਿ ਉਸਦੇ ਕੋਰਸ ਇੰਜਨੀਅਰ-ਮਿਤ੍ਰ ਸਾਂਝੇ ਕਿਉਂ ਮਹਿਸੂਸ ਹੁੰਦੇ ਹਨ: ਉਹ ਸਾਫ਼ ਸਮੱਸਿਆ ਸੈਟਅਪ, ਮਾਪੇ ਜਾ ਸਕਣ ਵਾਲੀ ਤਰੱਕੀ, ਅਤੇ ਪ੍ਰਾਇਕਟਿਕ ਆਦਤਾਂ 'ਤੇ ਧਿਆਨ ਦਿੰਦੇ ਹਨ ਜੋ ਅਸਲ ਪ੍ਰਾਜੈਕਟਾਂ ਵਿੱਚ ਤਬਦੀਲ ਹੋ ਸਕਦੀਆਂ ਹਨ।
Ng ਦੀ ਯਾਤਰਾ ਕੰਪਿਊਟਰ سائੰਸ ਵਿਚੋਂ ਸ਼ੁਰੂ ਹੋਈ ਅਤੇ ਤੇਜ਼ੀ ਨਾਲ ਮਸ਼ੀਨ ਲਰਨਿੰਗ ਅਤੇ ਏਆਈ ਵੱਲ ਰੁਝੀ—ਉਹ ਸਾਫਟਵੇਅਰ ਦਾ ਉਹ ਹਿੱਸਾ ਜੋ ਡੇਟਾ ਅਤੇ ਅਨੁਭਵ ਰਾਹੀਂ ਸੁਧਰਦਾ ਹੈ। ਉਸਦੀ ਅਕਾਦਮਿਕ ਤਿਆਰੀ ਅਤੇ ਸ਼ੁਰੂਆਤੀ ਕੰਮ ਨੇ ਉਸਨੂੰ ਉਹਨਾਂ ਮੂਲ ਪ੍ਰਸ਼ਨਾਂ ਦੇ ਨੇੜੇ ਰੱਖਿਆ ਜਿਨ੍ਹਾਂ ਨਾਲ ਡਿਵੈਲਪਰ ਅਜੇ ਵੀ ਮੂੰਹ ਕਰਦੇ ਹਨ: ਸਮੱਸਿਆ ਨੂੰ ਕਿਵੇਂ ਦਰਸਾਇਆ ਜਾਵੇ, ਉਦਾਹਰਣਾਂ ਤੋਂ ਕਿਵੇਂ ਸਿੱਖਣਾ ਹੈ, ਅਤੇ ਮਾਡਲ ਵਾਸਤੇ ਕੀ ਵਾਕਈ ਬਿਹਤਰ ਹੋ ਰਿਹਾ ਹੈ ਇਹ ਕਿਵੇਂ ਅੰਕਿਤ ਕਰਨਾ ਹੈ।
ਇਹ ਨੀਂਹ ਮਹੱਤਵਪੂਰਨ ਹੈ ਕਿਉਂਕਿ ਇਹ ਉਸਦੇ ਵਿਆਖਿਆਨ ਨੂੰ ਪਹਿਲੀ ਪ੍ਰਿੰਸੀਪਲਾਂ (ਅਲਗੋਰਿਦਮ ਕੀ ਕਰ ਰਿਹਾ ਹੈ) 'ਤੇ ਅਧਾਰਿਤ ਕਰਦੀ ਹੈ, ਨਾਲ ਹੀ ਮਕਸਦ ਨੂੰ ٹھੋਸ ਰੱਖਦੀ ਹੈ (ਤੁਸੀਂ ਇਸ ਨਾਲ ਕੀ ਬਣਾਉਂਗੇ)।
ਰਿਸਰਚ ਸੱਭਿਆਚਾਰ ਸੂਝ-ਬੁੱਝ ਨੂੰ ਇਨਾਮ ਦਿੰਦਾ ਹੈ: ਮੈਟ੍ਰਿਕ ਵੱਖਰੇ ਕਰਨਾ, ਸਾਫ਼ ਪ੍ਰਯੋਗ ਚਲਾਉਣਾ, ਅਤੇ ਇਹ ਅਲੱਗ ਕਰਨਾ ਕਿ ਕੀ ਵਾਕਈ ਨਤੀਜੇ ਭਲਕੇ ਕਰਦਾ ਹੈ। ਇਹ ਪ੍ਰਾਇਰਿਟੀਆਂ ਉਸਦੇ ਮਸ਼ੀਨ ਲਰਨਿੰਗ ਕੋਰਸ ਸਮਗਰੀ ਅਤੇ ਬਾਅਦ ਦੇ ਪ੍ਰੋਗਰਾਮਾਂ (deeplearning.ai) ਵਿੱਚ ਦਰਸਾਈਆਂ ਜਾਂਦੀਆਂ ਹਨ। ਉਹ ਏਆਈ ਨੂੰ ਚਾਲਕਾਂ ਦੇ ਢੇਰ ਵਾਂਗ ਨਹੀਂ ਵੇਖਦੇ; ਉਸਦੀ ਸਿੱਖਿਆ ਮੁੜ-ਮੁੜ ਇਸਤੇ ਧਿਆਨ ਦਿੰਦੀ ਹੈ:
ਇਥੇ ਉਸਦੀ ਬਾਅਦ ਦੀ ਡੇਟਾ-ਕੇਂਦਰਿਤ ਏਆਈ ਤੇਜ਼ੀ ਨਾਲ ਗੂੰਜ ਮਾਰਦੀ ਹੈ: ਇਹ ਤਰੱਕੀ ਨੂੰ ਡੇਟਾਸੈੱਟ ਅਤੇ ਫੀਡਬੈਕ ਲੂਪ ਸੁਧਾਰਨ ਦੇ ਤਰੀਕੇ ਵਜੋਂ ਦਿਖਾਉਂਦਾ ਹੈ, ਸਿਰਫ਼ ਮਾਡਲ ਬਦਲਣ ਦੀ ਜਗ੍ਹਾ ਨਹੀਂ।
ਸੰਖੇਪ ਵਿੱਚ, Ng ਦੇ ਕੈਰੀਅਰ ਨੂੰ ਕੁਝ ਸਰਜਨਾਤਮਕ ਮੋੜਾਂ ਨੇ ਚਿੰਨ੍ਹਿਤ ਕੀਤਾ ਹੈ: ਉਸਦਾ ਅਕਾਦਮਿਕ ਕੰਮ ਏਆਈ ਵਿੱਚ, Stanford ਵਿੱਚ ਪੜ੍ਹਾਉਣ ਦਾ ਰੋਲ (ਉਸਦੀ ਮਸ਼ਹੂਰ Stanford machine learning ਕੋਰਸ ਸਮੇਤ), ਅਤੇ Coursera ਅਤੇ deeplearning.ai ਰਾਹੀਂ ਬੜੀ ਪੱਧਰ ਦੀ ਏਆਈ ਸਿੱਖਿਆ ਵੱਲ ਵਿਆਪਕ ਫੈਲਾਓ। ਰਸਤੇ ਵਿੱਚ, ਉਸਨੇ ਉદ્યોગ ਦੇ ਏਆਈ ਟੀਮਾਂ ਵਿੱਚ ਨੇਤ੍ਰਿਤਵ ਭੂਮਿਕਾਵਾਂ ਵੀ ਨਿਭਾਈਆਂ, ਜਿਸ ਨਾਲ ਉਹ ਕੈਰੀਅਰ ਅਤੇ ਉਤਪਾਦ ਸੋਚને ਹੋਰ ਮਜ਼ਬੂਤ ਬਣਾਉਣ ਲਈ ਪ੍ਰੇਰਿਤ ਹੋਇਆ—ਜੋ ਉਸਦੀ ਏਆਈ ਕੈਰੀਅਰ ਸਲਾਹ ਵਿੱਚ ਦਿਖਾਈ ਦਿੰਦੀ ਹੈ: ਬੁਨਿਆਦੀ ਸਿੱਖੋ, ਫਿਰ ਇਸਨੂੰ ਕਿਸੇ ਖਾਸ ਯੂਜ਼ਰ ਸਮੱਸਿਆ 'ਤੇ ਲਾਗੂ ਕਰੋ।
ਇਹ ਸਾਰਾ ਮਿਲ ਕੇ ਇਹ ਸਮਝਾਉਂਦਾ ਹੈ ਕਿ ਉਸਦੀ ਸਿੱਖਿਆ ਕਿਉਂ ਸਿਧਾਂਤ ਅਤੇ ਬਣਾਉਣ ਯੋਗਤਾ ਨੂੰ ਜੋੜਦੀ ਹੈ—ਇੱਕ ਕਾਰਨ ਜਿਸ ਕਰਕੇ ਉਸਦੀ Deep Learning Specialization ਅਤੇ ਸੰਬੰਧਤ ਪ੍ਰੋਗਰਾਮ ਡਿਵੈਲਪਰਾਂ ਲਈ ਆਮ ਆਗਮਨ ਬਿੰਦੂ ਬਣ ਗਏ।
Andrew Ng ਦਾ Stanford Machine Learning ਕੋਰਸ ਇਸ ਲਈ ਕੰਮ ਕੀਤਾ ਕਿ ਇਸ ਨੇ ਸ਼ੁਰੂਆਤੀ ਲੋਕਾਂ ਨੂੰ ਯੋਗ ਬਿਲਡਰ ਵਜੋਂ ਟਰੀਟ ਕੀਤਾ, ਨਾ ਕਿ ਭਵਿੱਖ ਦੇ ਅਕੈਡਮਿਕਸ ਵਾਂਗ। ਵਾਅਦਾ ਸਪੱਸ਼ਟ ਸੀ: ਤੁਸੀਂ ਮਸ਼ੀਨ ਲਰਨਿੰਗ ਦੇ ਮਨੋ-ਮਾਡਲ ਸਿੱਖ ਸਕਦੇ ਹੋ ਅਤੇ ਉਨ੍ਹਾਂ ਨੂੰ ਲਾਗੂ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰ ਸਕਦੇ ਹੋ, ਭਾਵੇਂ ਤੁਸੀਂ ਗਣਿਤ ਵਿੱਚ ਮਹਿਰ ਹੋਵੇ ਜਾਂ ਨਹੀਂ।
ਕੋਰਸ ਨੇ ਜਾਣੂ, ਡਿਵੈਲਪਰ-ਮਿਤ੍ਰ ਫਰੇਮਿੰਗ ਵਰਤੀ: ਤੁਸੀਂ ਇੱਕ ਸਿਸਟਮ ਨੂੰ ਅਪਟੀਮਾਈਜ਼ ਕਰ ਰਹੇ ਹੋ, ਇਸ ਨੂੰ ਮਾਪ ਰਹੇ ਹੋ, ਅਤੇ ਦੁਹਰਾ ਰਹੇ ਹੋ। ਸਮਝਾਈਆਂ ਪਹਿਲਾਂ ਇੰਟਿਊਇਟਿਵ ਉਦਾਹਰਣਾਂ ਨਾਲ ਕੀਤੀਆਂ ਜਾਂਦੀਆਂ ਸਨ, ਫਿਰ ਰਸਮੀ ਨੋਟੇਸ਼ਨ। ਸਪਤਾਹਿਕ ਪ੍ਰੋਗ੍ਰਾਮਿੰਗ ਅਸਾਈਨਮੈਂਟ ਅਬਸਟ੍ਰੈਕਟ ਵਿਚਾਰਾਂ ਨੂੰ ਕਿਸੇ ਚੀਜ਼ ਵਿੱਚ ਬਦਲ ਦਿੰਦੇ ਜੋ ਤੁਸੀਂ ਚਲਾ ਸਕਦੇ, ਟੁੱਟ ਸਕਦੇ ਅਤੇ ਠੀਕ ਕਰ ਸਕਦੇ ਹੋ।
ਕਈ ਲਰਨਰ ਇਸਨੂੰ "ਕਈ ਅਲਗੋਰਿਦਮਾਂ ਦਾ ਢੇਰ" ਵਜੋਂ ਨਹੀਂ ਯਾਦ ਰੱਖਦੇ, ਬਲਕਿ ਸੋਚਣ ਦੀ ਇੱਕ ਚੈਕਲਿਸਟ ਵਜੋਂ:
ਇਹ ਵਿਚਾਰ ਟੂਲਜ਼ ਅਤੇ ਰੁਝਾਨਾਂ ਦੇ ਬਦਲਣ ਦੇ ਬਾਵਜੂਦ ਅਚੰਗੇ ਤੌਰ 'ਤੇ ਸਫਰ ਕਰਦੇ ਹਨ, ਜਿਸ ਕਰਕੇ ਕੋਰਸ ਲਾਇਬਰੇਰੀਆਂ ਬਦਲਣ ਦੌਰਾਨ ਵੀ ਲਾਭਕਾਰੀ ਰਹਿੰਦਾ ਗਿਆ।
ਹੇਠਾਂ ਕੈਲਕੁਲਸ ਅਤੇ ਲਿਨੀਅਰ ਐਲਜੀਬਰਾ ਹਨ, ਪਰ ਕੋਰਸ ਇਹ ਜ਼ਿਆਦਾ ਜੋੜਦਾ ਹੈ ਕਿ ਸਮੀਕਰਨ ਲਰਨਿੰਗ ਵਿਹਾਰੀ ਲਈ ਕੀ ਅਰਥ ਰੱਖਦੇ ਹਨ। ਕਈ ਡਿਵੈਲਪਰਾਂ ਨੇ ਪਾਇਆ ਕਿ ਮੁਸ਼ਕਲਾਂ ਡੈਰੀਵੇਟਿਵਜ਼ ਨਹੀਂ ਸਨ—ਸਕੂਪ ਮਾਪਣ, ਡਾਇਗਨੋਜ਼ਿੰਗ ਐਰਰ, ਅਤੇ ਇੱਕ ਵਾਰ ਵਿੱਚ ਇੱਕ ਬਦਲਾਅ ਕਰਨ ਦੀ ਆਦਤ ਬਣਾਉਣਾ ਅਸਲ ਨੂੰ ਮੁਸ਼ਕਿਲ ਬਣਾਉਂਦਾ ਹੈ।
ਕਈਆਂ ਲਈ ਤਾਜ਼ਾ ਲਹਿਰਾਂ ਪ੍ਰਾਇਕਟਿਕ ਹੁੰਦੀਆਂ ਹਨ:
Andrew Ng ਦਾ Coursera 'ਤੇ ਜਾਣਾ ਸਿਰਫ ਲੈਕਚਰਾਂ ਨੂੰ ਆਨਲਾਈਨ ਰੱਖਣ ਨਹੀਂ ਸੀ—ਇਸ ਨੇ ਉੱਚ ਦਰਜੇ ਦੀ ਏਆਈ ਸਿੱਖਿਆ ਨੂੰ ਇੱਕ ਐਸਾ ਚੀਜ਼ ਬਣਾਇਆ ਜੋ ਡਿਵੈਲਪਰ ਅਸਲ ਵਿੱਚ ਆਪਣੇ ਜੀਵਨ ਵਿਚ ਫਿੱਟ ਕਰ ਸਕਦੇ ਸਨ। Stanford ਦੇ ਸਮਾਂਸੂਚੀ ਦੀ ਲੋੜ ਨਹੀਂ ਰਹੀ; ਤੁਸੀਂ ਸੈਸ਼ਨ ਛੋਟੇ-ਛੋਟੇ ਵਕਤ 'ਚ ਕਰ ਸਕਦੇ ਹੋ—ਕੰਮ ਦੇ ਵਿਚਕਾਰ, ਕਮਿਊਟ 'ਤੇ, ਜਾਂ ਵੀਕਐਂਡ 'ਤੇ।
ਮੁੱਖ ਬਦਲਾਅ ਵੰਡ ਹੈ। ਇੱਕ ਚੰਗਾ ਡਿਜ਼ਾਈਨ ਕੀਤਾ ਹੋਇਆ ਕੋਰਸ ਮਿਲੀਅਨਾਂ ਤੱਕ ਪਹੁੰਚ ਸਕਦਾ ਸੀ, ਜਿਸ ਦਾ ਅਰਥ ਇਹ ਸੀ ਕਿ ਮਸ਼ੀਨ ਲਰਨਿੰਗ ਵਿੱਚ ਮੁੱਖ ਰਾਹ ਹੁਣ ਰਿਸਰਚ ਯੂਨੀਵਰਸਿਟੀ ਵਿੱਚ ਦਰਜਾ ਲੈਣ ਦੀ ਲੋੜ ਨਹੀਂ ਸੀ। ਵੱਡੇ ਟੈਕ ਹੱਬ ਤੋਂ ਬਾਹਰ ਡਿਵੈਲਪਰਾਂ ਲਈ, MOOCs ਨੇ ਜਿਗਿਆਸਾ ਅਤੇ ਯੋਗਤਾ ਵਾਲੇ ਖਾਲੀਨੂੰ ਘਟਾ ਦਿੱਤਾ।
MOOC ਢਾਂਚਾ ਉਹਨਾਂ ਤਰੀਕਿਆਂ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਜਿਹੜੇ ਡਿਵੈਲਪਰ ਪਹਿਲਾਂ ਹੀ ਸਿੱਖਦੇ ਹਨ:
ਇਹ ਫਾਰਮੈਟ ਮੋਮੈਂਟਮ ਨੂੰ ਵੀ ਉਤਸ਼ਾਹਿਤ ਕਰਦਾ ਹੈ। ਤੁਹਾਨੂੰ ਤਰੱਕੀ ਲਈ ਪੂਰਾ ਦਿਨ ਨਹੀਂ ਚਾਹੀਦਾ; 20–40 ਮਿੰਟ ਵੀ ਤੁਹਾਨੂੰ ਅੱਗੇ ਵਧਾ ਸਕਦੇ ਹਨ।
ਜਦੋਂ ਹਜ਼ਾਰਾਂ ਲਰਨਰ ਇੱਕੋ ਜਿਹੇ ਰੁਕਾਵਟ ਨੂੰ ਟਕਰਾਉਂਦੇ ਹਨ, ਫੋਰਮ ਇੱਕ ਸਾਂਝਾ ਟਰਬਲਸ਼ੂਟਿੰਗ ਲੇਅਰ ਬਣ ਜਾਂਦੇ ਹਨ। ਤੁਸੀਂ ਅਕਸਰ ਲੱਭ ਸਕਦੇ ਹੋ:
ਇਹ ਨਿੱਜੀ ਟੀਏ ਵਾਲੇ ਸਮਾਨ ਨਹੀਂ ਸੀ, ਪਰ ਇਸ ਨੇ ਸਿੱਖਣ ਨੂੰ ਕਮ ਅਕੇਲਾ ਮਹਿਸੂਸ ਕਰਵਾਇਆ—ਅਤੇ ਇਹ ਪੈਟਰਨਾਂ ਨੂੰ ਸਾਹਮਣੇ ਲਿਆਉਂਦਾ ਜੋ ਕੋਰਸ ਸਟਾਫ ਸਮੇਂ-ਸਮੇਂ 'ਤੇ ਸੁਧਾਰ ਸਕਦੇ ਸਨ।
MOOC ਆਮ ਤੌਰ 'ਤੇ ਸਪੱਸ਼ਟਤਾ, ਗਤੀ, ਅਤੇ ਪੂਰਨਤਾ ਨੂੰ ਉੱਤਮ ਬਣਾਉਂਦਾ ਹੈ, ਜਦਕਿ ਯੂਨੀਵਰਸਿਟੀ ਕੋਰਸ ਅਕਸਰ ਥਿਊਰੀ, ਗਣਿਤੀ ਜਟਿਲਤਾ, ਅਤੇ ਖੁੱਲ੍ਹੇ-ਅੰਤ ਸਮੱਸਿਆ ਹੱਲ ਨੂੰ ਜ਼ੋਰ ਦਿੰਦਾ ਹੈ। MOOCs ਤੁਹਾਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਉਤਪਾਦਕ ਬਣਾਉਂਦੇ ਹਨ, ਪਰ ਉਹ ਸ਼ਾਇਦ ਰਿਸਰਚ-ਸਤ੍ਹਰੀ ਗਹਿਰਾਈ ਨਹੀਂ ਦੇ ਸਕਦੇ ਜਾਂ ਗਰੇਡ ਕੀਤੇ ਇਮਤਿਹਾਨਾਂ ਅਤੇ ਸਾਹਮਣੇ-ਸਮੁਹ ਚਰਚਾ ਦੇ ਦਬਾਅ ਨਹੀਂ ਦਿੰਦੇ।
ਅਧਿਕਤਰ ਡਿਵੈਲਪਰਾਂ ਲਈ, ਇਹ ਵਪਾਰ-ਬਦਲਾਉ ਹੀ ਹੈ: ਤੇਜ਼ ਪ੍ਰਾਇਕਟਿਕ ਯੋਗਤਾ, ਅਤੇ ਫਿਰ ਬਾਅਦ ਵਿੱਚ ਜ਼ਰੂਰਤ ਹੋਣ 'ਤੇ ਗਹਿਰਾਈ ਲੈਣ ਦੀ ਚੋਣ।
Andrew Ng ਦੀ ਸਿੱਖਣ ਦੀ ਵਿਸ਼ੇਸ਼ਤਾ ਇਹ ਹੈ ਕਿ ਉਹ ਏਆਈ ਨੂੰ ਇੱਕ ਇੰਜਨੀਅਰਿੰਗ ਵਿਧਾ ਵਜੋਂ ਵੇਖਦਾ ਹੈ ਜਿਸਦਾ ਅਭਿਆਸ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ—ਨਾ ਕਿ ਰਹੱਸਮਈ ਚਾਲਾਂ ਦਾ ਸਮੁੱਚੇ। ਬਦਲੇ ਵਿੱਚ, ਉਹ ਹਮੇਸ਼ਾਂ ਉਹਨਾਂ ਫੈਸਲਿਆਂ ਨਾਲ ਧਾਰਣਾਵਾਂ ਨੂੰ ਜੋੜਦਾ ਹੈ ਜੋ ਇੱਕ ਡਿਵੈਲਪਰ ਨੂੰ ਲੈਣੀਆਂ ਪੈਂਦੀਆਂ ਹਨ: "ਅਸੀਂ ਕੀ ਅਨੁਮਾਨ ਲਾ ਰਹੇ ਹਾਂ? ਅਸੀਂ ਕਿਵੇਂ ਜਾਣਾਂਗੇ ਕਿ ਅਸੀਂ ਸਹੀ ਹਾਂ? ਜਦ ਨਤੀਜੇ ਖਰਾਬ ਹਨ ਤਾਂ ਅਸੀਂ ਕੀ ਕਰੀਏ?"
ਇੱਕ ਮੁੜ-ਮੁੜਲਾ ਨਮੂਨਾ ਇਨਪੁਟ, ਆਉਟਪੁਟ ਅਤੇ ਮੈਟ੍ਰਿਕਸ ਦੇ ਪ੍ਰਿਸਟਟਿਕ੍ਰਮ ਵਿੱਚ ਸਪਸ਼ਟ ਫਰੇਮਿੰਗ ਹੈ। ਇਹ ਆਸਾਨ ਲੱਗਦਾ ਹੈ, ਪਰ ਇਹ ਬਹੁਤ ਸਾਰਾ ਬੇਕਾਰ ਖਾਲੀ ਖਰਚ ਰੋਕਦਾ ਹੈ।
ਜੇ ਤੁਸੀਂ ਨਹੀਂ ਦੱਸ ਸਕਦੇ ਕਿ ਮਾਡਲ ਕੀ ਖਾਂਦਾ ਹੈ (ਇਨਪੁਟ), ਇਹ ਕੀ ਉਤਪਾਦ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ (ਆਉਟਪੁਟ), ਅਤੇ "ਚੰਗਾ" ਕੀ ਹੈ (ਇੱਕ ਮੈਟ੍ਰਿਕ ਜੋ ਤੁਸੀਂ ਟਰੈਕ ਕਰ ਸਕਦੇ ਹੋ), ਤਾਂ ਤੁਸੀਂ ਹੋਰ ਡੇਟਾ ਜਾਂ ਵਧੀਆ ਆਰਕੀਟੈਕਚਰ ਲਈ ਤਿਆਰ ਨਹੀਂ ਹੋ। ਤੁਸੀਂ ਅਜੇ ਵੀ ਅਨੁਮਾਨ ਲੱਗਾ ਰਹੇ ਹੋ।
ਸਿਖਾਉਣ ਦੀ ਇੱਕ ਵੱਡੀ ਵਿਧੀ ਯਾਦ ਰੱਖਣ ਦੀ ਥਾਂ ਮਾਨਸਿਕ ਮਾਡਲ ਅਤੇ ਦੋਹਰਾਏ ਜਾਣ ਵਾਲੇ ਚੈਕਲਿਸਟ ਉੱਤੇ ਧਿਆਨ ਹੈ। ਡਿਵੈਲਪਰਾਂ ਲਈ ਇਹ ਸ਼ਕਤੀਸ਼ਾਲੀ ਹੈ: ਇਹ ਸਿੱਖਣ ਨੂੰ ਇੱਕ ਵਰਕਫਲੋ ਬਣਾਉਂਦਾ ਜੋ ਤੁਸੀਂ ਵੱਖ-ਵੱਖ ਪ੍ਰੋਜੈਕਟਾਂ 'ਚ ਦੁਹਰਾ ਸਕਦੇ ਹੋ।
ਉਦਾਹਰਣਾਂ ਵਿੱਚ ਬਾਇਅਸ ਵਿਰੁੱਧ ਵੈਰੀਅਂਸ ਸੋਚਣਾ, ਫੇਲਿਯਰ ਮੋਡ ਨੂੰ ਅਲੱਗ ਕਰਨਾ, ਅਤੇ ਇਹ ਨਿਰਣੇ ਲੈਣਾ ਕਿ ਸਬੂਤ ਦੇ ਆਧਾਰ 'ਤੇ ਡੇਟਾ, ਫੀਚਰ, ਜਾਂ ਮਾਡਲ ਤੇ ਧਿਆਨ ਦਿੱਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ—ਇਸ ਵਿੱਚੋਂ ਜਿਹੜੀ ਸਭ ਤੋਂ ਪ੍ਰਭਾਵਸ਼ালী ਹੋਵੇ।
Ng ਇਟਰੈਸ਼ਨ, ਡੀਬੱਗਿੰਗ, ਅਤੇ ਮਾਪਨ 'ਤੇ ਵੀ ਜ਼ੋਰ ਦਿੰਦਾ ਹੈ। ਟ੍ਰੇਨਿੰਗ "ਇੱਕ ਵਾਰੀ ਚਲਾਓ ਅਤੇ ਆਸ ਕਰੋ" ਨਹੀਂ ਹੈ; ਇਹ ਇਕ ਲੂਪ ਹੈ:
ਇਸ ਲੂਪ ਦਾ ਇੱਕ ਮੁੱਖ ਹਿੱਸਾ ਜਟਿਲ ਮਾਡਲਾਂ ਤੋਂ ਪਹਿਲਾਂ ਸਧਾਰਨ ਬੇਸਲਾਈਨ ਵਰਤਣਾ ਹੈ। ਇੱਕ ਤੇਜ਼ ਲੋਗਿਸਟਿਕ ਰਿਗਰੈਸ਼ਨ ਜਾਂ ਛੋਟੀ ਨਿਊਰਲ ਨੈੱਟ ਤੁਹਾਡੇ ਡੇਟਾ ਪਾਈਪਲਾਈਨ ਅਤੇ ਲੇਬਲਾਂ ਨੂੰ ਜਾਂਚ ਸਕਦੇ ਹਨ—ਫਿਰ ਤੁਹਾਡਾ ਸਮਾਂ ਕਿਸੇ ਵੱਡੀ ਚੀਜ਼ 'ਤੇ ਲਾਭਦਾਇਕ ਹੈ।
ਇਸ ਸੰਰਚਨਾ ਅਤੇ ਪ੍ਰਾਇਕਟਿਕਤਾ ਦੇ ਮਿਲਾਪ ਕਰਕੇ ਹੀ ਉਸਦੀ ਸਮੱਗਰੀ ਅਕਸਰ ਤੁਰੰਤ ਵਰਤੀ ਯੋਗ ਮਹਿਸੂਸ ਹੁੰਦੀ ਹੈ: ਤੁਸੀਂ ਇਹ ਸਿੱਧਾ ਆਪਣੀ ਬਣਾਵਟ, ਟੈਸਟ, ਅਤੇ ਸ਼ਿਪਿੰਗ ਵਿਚ ਤਬਦੀਲ ਕਰ ਸਕਦੇ ਹੋ।
Andrew Ng ਦੇ ਸ਼ੁਰੂਆਤੀ ਕੋਰਸ ਨੇ ਕਈ ਡਿਵੈਲਪਰਾਂ ਨੂੰ "ਕਲਾਸਿਕ" ਮਸ਼ੀਨ ਲਰਨਿੰਗ ਸਮਝਣ ਵਿੱਚ ਮਦਦ ਕੀਤੀ—ਲਿਕੀਅਰ ਰਿਗਰੈਸ਼ਨ, ਲੌਜਿਸਟਿਕ ਰਿਗਰੈਸ਼ਨ, ਅਤੇ ਮੂਲ ਨਿਊਰਲ ਨੈੱਟਵਰਕ। ਪਰ ਡੀਪ ਲਰਨਿੰਗ ਦੀ ਗ੍ਰਹਿਣਾ ਤਬ ਤੇਜ਼ ਹੋਈ ਜਦੋਂ ਸਿੱਖਣਾ ਇੱਕ ਹੀ ਕੋਰਸ ਤੋਂ ਬਦਲ ਕੇ ਸੰरਚਿਤ ਵਿਸ਼ੇਸ਼ਤਾ ਵਿੱਚ ਬਦਲ ਗਿਆ ਜੋ ਲੋਕਾਂ ਦੇ ਕੌਸ਼ਲ ਬਣਾਉਣ ਦੇ ਤਰੀਕੇ ਨੂੰ ਨਕਸ਼ਾ ਕਰਦੀ ਹੈ: ਇੱਕ-ਇੱਕ ਪਰਤ ਵਿੱਚ।
ਬਹੁਤ ਸਾਰੇ ਲਰਨਰਾਂ ਲਈ ML ਬੁਨਿਆਦੀ ਤੋਂ ਡੀਪ ਲਰਨਿੰਗ ਤਕ ਛਾਲ ਇੱਕ ਨਵੀਂ ਵਿਦਾ ਵਿੱਚ ਬਦਲਣ ਵਾਂਗ ਮਹਿਸੂਸ ਹੋ ਸਕਦੀ ਹੈ: ਨਵਾਂ ਗਣਿਤ, ਨਵੀਂ ਸ਼ਬਦਾਵਲੀ, ਅਤੇ ਅਣਜਾਣ ਫੇਲਿਯਰ ਮੋਡ। ਚੰਗੀ ਤਰ੍ਹਾਂ ਡਿਜ਼ਾਈਨ ਕੀਤੀ ਵਿਸ਼ੇਸ਼ਤਾ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਨੂੰ ਇਨ੍ਹਾਂ ਕਦਮਾਂ ਵਿੱਚ ਤਕਸੀਮ ਕਰਦੀ ਹੈ ਤਾਂ ਕਿ ਹਰ ਮੋਡੀਯੂਲ ਆਪਣੀ ਜਗ੍ਹਾ ਕਮਾਇਆ—ਪ੍ਰਾਇਕਟਿਕ ਇੰਟੂਇਸ਼ਨ (ਕਿਉਂ ਡੀਪ ਨੈੱਟ ਕੰਮ ਕਰਦੇ ਹਨ) ਤੋਂ ਸ਼ੁਰੂ ਕਰਕੇ ਟ੍ਰੇਨਿੰਗ ਮਕੈਨੀਕਸ (ਇਨਿਸ਼ੀਅਲਾਈਜ਼ੇਸ਼ਨ, ਰੇਗੂਲਰਾਈਜ਼ੇਸ਼ਨ, ਆਪਟੀਮਾਈਜ਼ੇਸ਼ਨ) ਤੱਕ, ਅਤੇ ਫਿਰ ਵਿਸ਼ੇਸ਼ ਖੇਤਰਾਂ 'ਚ ਫੈਲਣਾ।
ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਡਿਵੈਲਪਰਾਂ ਦੀ ਮਦਦ ਤਿੰਨ ਪ੍ਰਾਇਕਟਿਕ ਤਰੀਕਿਆਂ ਨਾਲ ਕਰਦੀਆਂ ਹਨ:
ਡਿਵੈਲਪਰ ਆਮ ਤੌਰ 'ਤੇ ਡੀਪ ਲਰਨਿੰਗ ਨਾਲ ਹੱਥ-ਉੱਤੇ ਕੰਮ ਰਾਹੀਂ ਮਿਲਦੇ ਹਨ ਜਿਵੇਂ:
ਇਹ ਪ੍ਰੋਜੈਕਟ ਛੋਟੇ ਹੁੰਦੇ ਹਨ ਪਰ ਅਸਲ ਪ੍ਰੋਡੱਕਟ ਪੈਟਰਨਾਂ ਦੇ ਨੇੜੇ ਰਹਿੰਦੇ ਹਨ।
ਆਮ ਰੁਕਾਵਟਾਂ ਵਿੱਚ ਟ੍ਰੇਨਿੰਗ ਨਾ ਕੰਮ ਕਰਨਾ, ਮੈਟ੍ਰਿਕਸ ਦਾ ਉਲਝਣਾ, ਅਤੇ "ਮੇਰੇ ਨੋਟਬੁੱਕ 'ਤੇ ਚੰਗਾ ਹੈ" ਦਾ ਮਸਲਾ ਸ਼ਾਮਿਲ ਹਨ। ਠੀਕ ਕਰਨ ਦਾ ਤਰੀਕਾ ਅਕਸਰ "ਹੋਰ ਥਿਊਰੀ" ਨਹੀਂ—ਇਹ ਬਿਹਤਰ ਆਦਤਾਂ ਹਨ: ਇੱਕ ਨਿੱਲਾ ਬੇਸਲਾਈਨ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ, ਪਹਿਲਾਂ ਡੇਟਾ ਅਤੇ ਲੇਬਲਾਂ ਦੀ ਜਾਂਚ ਕਰੋ, ਇਕੋ ਮੈਟਰਿਕ ਟਰੈਕ ਕਰੋ ਜੋ ਲਕੜੀ ਨਾਲ ਮਿਲਦਾ ਹੋਵੇ, ਅਤੇ ਇੱਕ ਵਾਰੀ ਵਿੱਚ ਇੱਕ ਹੀ ਚੀਜ਼ ਬਦਲੋ। ਸੰਰਚਿਤ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਇਸ ਅਨੁਸ਼ਾਸਨ ਨੂੰ ਉਤਸ਼ਾਹਿਤ ਕਰਦੀਆਂ ਹਨ, ਇਸ ਲਈ ਇਹ ਡੀਪ ਲਰਨਿੰਗ ਨੂੰ ਕੰਮਯਾਬ ਡਿਵੈਲਪਰਾਂ ਲਈ ਪਹੁੰਚਯੋਗ ਬਣਾਉਂਦੀਆਂ ਹਨ।
Andrew Ng ਨੇ ਡਿਵੈਲਪਰਾਂ ਦੀ ਸੋਚ ਵਿੱਚ ਇੱਕ ਸਧਾਰਾ ਬਦਲਾਅ ਪ੍ਰਚਾਰਿਤ ਕੀਤਾ: ਮਾਡਲ ਨੂੰ ਮੁੱਖ ਲੀਵਰ ਸਮਝਣਾ ਛੱਡੋ, ਅਤੇ ਡੇਟਾ ਨੂੰ ਉਤਪਾਦ ਵਾਂਗ ਸੋਚਣਾ ਸ਼ੁਰੂ ਕਰੋ।
ਡੇਟਾ-ਕੇਂਦਰਿਤ ਏਆਈ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਤੁਸੀਂ ਆਪਣੀ ਕੋਸ਼ਿਸ਼ ਦਾ ਵੱਧ ਹਿੱਸਾ ਟ੍ਰੇਨਿੰਗ ਡੇਟਾ ਨੂੰ ਸੁਧਾਰਨ 'ਤੇ ਖਰਚ ਕਰੋ—ਉਸਦੀ ਸਹੀਤਾ, ਲਗਾਤਾਰਤਾ, ਕਵਰੇਜ, ਅਤੇ ਪ੍ਰਭਾਵ—ਨਹੀਂ ਕਿ ਲਗਾਤਾਰ ਅਲਗੋਰਿਦਮਾਂ ਨੂੰ ਬਦਲਦੇ ਰਹੋ। ਜੇ ਡੇਟਾ ਅਸਲ ਸਮੱਸਿਆ ਨੂੰ ਚੰਗੀ ਤਰ੍ਹਾਂ ਦਰਸਾਉਂਦਾ ਹੈ, ਤਾਂ ਕਈ "ਠੀਕ-ਠਾਕ" ਮਾਡਲ ਹੇਰਾਨ ਕਰਨ ਵਾਲੀ ਤਰ੍ਹਾਂ ਵਧੀਆ ਕਰਦੇ ਹਨ।
ਮਾਡਲ ਤਬਦੀਲੀਆਂ ਅਕਸਰ ਛੋਟੇ ਗੇਨ ਦਿੰਦੀਆਂ ਹਨ। ਡੇਟਾ ਸਮੱਸਿਆਵਾਂ ਅਜਿਹੇ ਤੌਰ 'ਤੇ ਪ੍ਰਦਰਸ਼ਨ ਨੂੰ ਸੀਮਿਤ ਕਰ ਸਕਦੀਆਂ ਹਨ ਕਿ ਤੁਸੀਂ ਕਿੰਨੀ ਭੀ ਆਰਕੀਟੈਕਚਰ ਅਪਡੇਟ ਕਰ ਲਵੋ ਨਤੀਜਾ ਬਦਲੇ ਬਿਨਾਂ ਰਹਿ ਸਕਦਾ ਹੈ। ਆਮ ਕਾਰਣਾਂ ਵਿੱਚ ਸ਼ਾਮਿਲ ਹਨ:
ਇਹ ਸਮੱਸਿਆਵਾਂ ਠੀਕ ਕਰਨ ਨਾਲ ਮੈਟ੍ਰਿਕਸ 'ਤੇ ਅਕਸਰ ਨਵੇਂ ਮਾਡਲ ਵਰਜ਼ਨ ਨਾਲੋਂ ਵਧੇਰੇ ਪ੍ਰਭਾਵ ਪੈਂਦਾ ਹੈ—ਕਿਉਂਕਿ ਤੁਸੀਂ ਸ਼ੋਰ ਨੂੰ ਹਟਾ ਰਹੇ ਹੋ ਅਤੇ ਸਿਸਟਮ ਨੂੰ ਸਹੀ ਟਾਸਕ ਸਿਖਾ ਰਹੇ ਹੋ।
ਡਿਵੈਲਪਰ-ਮਿਤ੍ਰ ਤਰੀਕਾ ਇਹ ਹੈ ਕਿ ਤੁਸੀਂ ਐਪ ਦੀ ਤਰ੍ਹਾਂ ਡੀਬੱਗ ਕਰਦੇ ਹੋ:
ਕੰਕ੍ਰੀਟ ਉਦਾਹਰਣ:
ਇਹ ਸੋਚ ਪ੍ਰੋਡਕਟ ਕੰਮ ਲਈ ਚੰਗੀ ਤਰ੍ਹਾਂ ਮੈਪ ਹੁੰਦੀ ਹੈ: ਇੱਕ ਬੇਸਲਾਈਨ ਸ਼ਿਪ ਕਰੋ, ਅਸਲ ਦੁਨੀਆ ਦੀਆਂ ਗਲਤੀਆਂ ਮਾਨੀਟਰ ਕਰੋ, ਪ੍ਰਭਾਵ ਅਨੁਸਾਰ ਫਿਕਸ ਪ੍ਰਾਇਓਰਿਟਾਈਜ਼ ਕਰੋ, ਅਤੇ ਡੇਟਾਸੈੱਟ ਗੁਣਵੱਤਾ ਨੂੰ ਇੱਕ ਦੁਹਰਾਉਣਯੋਗ ਇੰਜੀਨੀਅਰਿੰਗ ਨਿਵੇਸ਼ ਵਜੋਂ ਟ੍ਰੀਟ ਕਰੋ—ਇੱਕ ਵਾਰ ਦੀ ਸੈਟਅਪ ਨਹੀਂ।
Andrew Ng ਹਮੇਸ਼ਾਂ ਏਆਈ ਨੂੰ ਇੱਕ ਐਸੇ ਸੰਦ ਵਜੋਂ ਦਰਸਾਉਂਦਾ ਹੈ ਜਿਸ ਨੂੰ ਤੁਸੀਂ ਨਤੀਜਿਆਂ ਲਈ ਵਰਤਦੇ ਹੋ, ਨਾ ਕਿ ਇੱਕ ਐਸਾ ਵਿਸ਼ਾ ਜੋ "ਪੂਰਾ" ਕੀਤਾ ਜਾਵੇ। ਇਹ ਉਤਪਾਦ ਸੋਚ ਡਿਵੈਲਪਰਾਂ ਲਈ ਖਾਸ ਤੌਰ 'ਤੇ ਲਾਭਕਾਰੀ ਹੈ: ਇਹ ਤੁਹਾਨੂੰ ਸਿੱਖਣ ਨੂੰ ਸੀਧੇ ਉਸ ਚੀਜ਼ ਨਾਲ ਜੋੜਨ ਲਈ ਦਬਾਉਂਦਾ ਹੈ ਜੋ ਨੌਕਰੀਦਾਤਾ ਅਤੇ ਯੂਜ਼ਰ ਮੁੱਲ ਮੰਨਦੇ ਹਨ।
ਸਿੱਧਾਂਤਾਂ ਇਕੱਠੇ ਕਰਨ ਦੀ ਬਜਾਏ, ਉਨ੍ਹਾਂ ਨੂੰ ਟਾਸਕਾਂ ਵਿੱਚ ਬਦਲੋ ਜੋ ਤੁਸੀਂ ਟੀਮ 'ਤੇ ਕਰ ਸਕਦੇ ਹੋ:
ਜੇ ਤੁਸੀਂ ਆਪਣੇ ਕੰਮ ਨੂੰ ਇਹਨਾਂ ਕਿਰਿਆਵਾਂ ਵਿੱਚ ਵਿਆਖਿਆ ਕਰ ਸਕਦੇ ਹੋ—ਕਲੈਕਟ ਕਰੋ, ਟ੍ਰੇਨ ਕਰੋ, ਮੁਲਾਂਕਣ ਕਰੋ, ਡਿਪਲੌਇ ਕਰੋ, ਸੁਧਾਰੋ—ਤਾਂ ਤੁਸੀਂ ਅਜਿਹੇ ਢੰਗ ਨਾਲ ਸਿੱਖ ਰਹੇ ਹੋ ਜੋ ਅਸਲ ਭੂਮਿਕਾਵਾਂ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਹੈ।
ਇੱਕ “ਚੰਗਾ” ਲਰਨਿੰਗ ਪ੍ਰੋਜੈਕਟ ਨੂੰ ਨਵਾਂ ਆਰਕੀਟੈਕਚਰ ਲੈਣ ਦੀ ਲੋੜ ਨਹੀਂ ਹੁੰਦੀ। ਇਸਨੂੰ ਸਪੱਸ਼ਟ ਸਕੋਪ ਅਤੇ ਸਬੂਤ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ।
ਇੱਕ ਸੰਕੀਰਨ ਸਮੱਸਿਆ ਚੁਣੋ (ਜੈਮ, ਸਹਾਇਤਾ ਟਿਕਟਾਂ ਦੀ ਵਰਗੀਕਰਨ)। ਸਫਲਤਾ ਮੈਟਰਿਕ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ। ਇੱਕ ਸਧਾਰਨ ਬੇਸਲਾਈਨ ਦਿਖਾਓ, ਫਿਰ ਸੁਧਾਰ ਦਸਤਾਵੇਜ਼ ਕਰੋ ਜਿਵੇਂ ਵਧੀਆ ਲੇਬਲਿੰਗ, ਐਰਰ ਵਿਸ਼ਲੇਸ਼ਣ, ਅਤੇ ਚੰਗੀ ਡੇਟਾ ਕਲੈਕਸ਼ਨ। ਨੌਕਰੀਦਾਤਾ ਉਹ ਪ੍ਰੋਜੈਕਟ ਭਰੋਸੇਯੋਗ ਮੰਨਦੇ ਹਨ ਜੋ ਫੈਸਲਾ ਅਤੇ ਇਟਰੈਸ਼ਨ ਦਿਖਾਉਂਦੇ ਹਨ, ਨਾਂ ਕਿ ਸਿਰਫ਼ ਚਮਕਦੇ ਡੈਮੋ।
ਫਰੇਮਵਰਕ ਅਤੇ API ਤੇਜ਼ੀ ਨਾਲ ਬਦਲਦੇ ਹਨ। ਬੁਨਿਆਦੀ (ਬਾਇਅਸ/ਵੈਰੀਅਂਸ, ਓਵਰਫਿਟਿੰਗ, ਟ੍ਰੇਨ/ਵੈਲਿਡੇਸ਼ਨ ਸਪਲਿਟ, ਮੁਲਾਂਕਣ) ਧੀਰੇ-ਧੀਰੇ ਬਦਲਦੇ ਹਨ।
ਇੱਕ ਪ੍ਰਾਇਕਟਿਕ ਸੰਤੁਲਨ: ਮੁੱਖ ਧਾਰਣਾਵਾਂ ਇੱਕ ਵਾਰੀ ਸਿੱਖੋ, ਫਿਰ ਟੂਲਜ਼ ਨੂੰ ਬਦਲਣਯੋਗ ਇੰਟਰਫੇਸ ਸਮਝੋ। ਤੁਹਾਡਾ ਪੋਰਟਫੋਲਿਓ ਇਹ ਦਰਸਾਉਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਅਨੁਕੂਲ ਹੋ ਸਕਦੇ ਹੋ—ਉਦਾਹਰਣ ਲਈ, ਨਵੀਂ ਲਾਇਬ੍ਰੇਰੀ ਵਿੱਚ ਇੱਕੋ ਵਰਕਫਲੋ ਨੂੰ ਦੁਹਰਾਉਣਾ ਬਿਨਾਂ ਅਨੁਸ਼ਾਸਨ ਘਟਾਉਣ ਦੇ।
ਉਤਪਾਦ ਸੋਚ ਵਿੱਚ ਸਾਂਤ ਰਹਿਣਾ ਸ਼ਾਮਿਲ ਹੈ। ਆਪਣੇ ਮੁਲਾਂਕਣ ਜੋ ਦਾਅਵਾ ਸਮਰਥਨ ਨਹੀਂ ਕਰ ਸਕਦੇ ਉਨ੍ਹਾਂ ਤੋਂ ਬਚੋ, ਫੇਲਿਯਰ ਕੇਸਾਂ ਦੀ ਟੈਸਟਿੰਗ ਕਰੋ, ਅਤੇ ਅਨਿਸ਼ਚਿਤਤਾ ਨੂੰ ਰਿਪੋਰਟ ਕਰੋ। ਜਦੋਂ ਤੁਸੀਂ ਨਾਪੇ-ਤੋਕੇ ਨਤੀਜੇ, ਮਾਨੀਟਰਿੰਗ, ਅਤੇ ਦਸਤਾਵੇਜ਼ੀ ਸੀਮਾਵਾਂ 'ਤੇ ਧਿਆਨ ਦਿੰਦੇ ਹੋ ਤਾਂ ਤੁਸੀਂ ਯੋਗਤਾ ਨਾਲ ਨੈਤਿਕਤਾ ਵੀ ਬਣਾਉਂਦੇ ਹੋ।
Andrew Ng ਦੇ ਕੋਰਸ ਮੁਸ਼ਕਲ ਧਾਰਣਾਵਾਂ ਨੂੰ ਸੁਗਮ ਬਣਾਉਣ ਲਈ ਮਸ਼ਹੂਰ ਹਨ। ਇਹ ਤਾਕਤ ਇੱਕ ਆਮ ਗਲਤਫਹਮੀ ਵੀ ਪੈਦਾ ਕਰ ਸਕਦੀ ਹੈ: "ਮੈਂ ਕੋਰਸ ਪੂਰਾ ਕਰ ਲਿਆ, ਹੁਣ ਮੈਂ ਖਤਮ ਹਾਂ।" ਸਿੱਖਿਆ ਇੱਕ ਸ਼ੁਰੂਆਤੀ ਲਕੀਰ ਹੈ, ਖਤਮ ਕਰਨ ਵਾਲੀ ਨਹੀਂ।
ਇੱਕ ਕੋਰਸ ਤੁਹਾਨੂੰ ਗ੍ਰੈਡੀਐਂਟ ਡੀਸੈਂਟ ਕੀ ਹੈ ਅਤੇ ਮਾਡਲ ਦਾ ਮੁਲਾਂਕਣ ਕਿਵੇਂ ਕਰਨਾ ਹੈ ਸਿਖਾ ਸਕਦਾ ਹੈ। ਪਰ ਆਮ ਤੌਰ 'ਤੇ ਇਹ ਤੁਹਾਨੂੰ ਬਿਜ਼ਨਸ ਸਮੱਸਿਆ ਦੀ ਗੰਦੀ ਹਕੀਕਤ—ਅਸਪਸ਼ਟ ਲਕੜੀਆਂ, ਬਦਲਦੀਆਂ ਮੰਗਾਂ, ਸੀਮਤ ਕਂਪਿਊਟ, ਅਤੇ ਅਧੂਰਾ/ਅਸੰਗਤ ਡੇਟਾ—ਨੂੰ ਕਿਵੇਂ ਹੱਲ ਕਰਨਾ ਸਿੱਖਾਉਂਦਾ ਨਹੀਂ।
ਕੋਰਸ-ਆਧਾਰਿਤ ਸਿੱਖਿਆ ਜ਼ਿਆਦਾਤਰ ਨਿਯੰਤਰਿਤ ਅਭਿਆਸ ਹੈ। ਅਸਲ ਤਰੱਕੀ ਉਸ ਵੇਲੇ ਹੁੰਦੀ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਕੁਝ ਐਂਡ-ਟੂ-ਐਂਡ ਬਣਾਉਂਦੇ ਹੋ—ਸਫਲਤਾ ਮੈਟਰਿਕ ਪਰਿਭਾਸ਼ਿਤ ਕਰਨਾ, ਡੇਟਾ ਇਕੱਠਾ ਕਰਨਾ, ਮਾਡਲ ਟ੍ਰੇਨ ਕਰਨਾ, ਐਰਰ ਡੀਬੱਗ ਕਰਨਾ, ਅਤੇ ਗੈਰ-ML ਟੀਮ ਮੈਂਬਰਾਂ ਨੂੰ ਟਰੇਡ-ਆਫ਼ ਸਮਝਾਉਣਾ।
ਜੇ ਤੁਸੀਂ ਇਕ ਛੋਟਾ ਪ੍ਰੋਜੈਕਟ ਸ਼ਿਪ ਨਹੀਂ ਕਰਦੇ, ਤਾਂ ਤੁਹਾਡੀ ਤਿਆਰੀ ਦੀ ਭਰਾਂਤ ਅਸਾਨੀ ਨਾਲ ਹੋ ਸਕਦੀ ਹੈ। ਇਹ ਫਰਕ ਉਸ ਵੇਲੇ ਸਾਹਮਣੇ ਆਉਂਦਾ ਹੈ ਜਦ ਤੁਸੀਂ ਅਸਲ ਪ੍ਰਸ਼ਨਾਂ ਦਾ ਸਾਹਮਣਾ ਕਰੋਗੇ ਜਿਵੇਂ:
ਏਆਈ ਦਾ ਪ੍ਰਦਰਸ਼ਨ ਅਕਸਰ ਫੈਂਸੀ ਆਰਕੀਟੈਕਚਰਾਂ ਪਰ ਘੱਟ ਨਿਰਭਰ ਹੁੰਦਾ ਹੈ ਅਤੇ ਇਸ ਗੱਲ 'ਤੇ ਵੱਧ ਨਿਰਭਰ ਹੁੰਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਡੋਮੇਨ ਨੂੰ ਸਮਝਦੇ ਹੋ ਅਤੇ ਸਹੀ ਡੇਟਾ ਤਕ ਪਹੁੰਚ ਰੱਖਦੇ ਹੋ। ਇੱਕ ਮੈਡੀਕਲ ਮਾਡਲ ਨੂੰ ਕਲੀਨੀਕਲ ਸੰਦਰਭ ਦੀ ਜ਼ਰੂਰਤ ਹੈ; ਇੱਕ ਫ੍ਰੌਡ ਮਾਡਲ ਨੂੰ ਇਹ ਪਤਾ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਫ੍ਰੌਡ ਵਾਕਈ ਕਿਵੇਂ ਹੁੰਦਾ ਹੈ। ਬਿਨਾਂ ਇਹਦੇ, ਤੁਸੀਂ ਗਲਤ ਚੀਜ਼ ਦਾ ਅਪਟੀਮਾਈਜ਼ ਕਰ ਸਕਦੇ ਹੋ।
ਜ਼ਿਆਦਾਤਰ ਡਿਵੈਲਪਰ ਕੁਝ ਹਫਤਿਆਂ ਵਿੱਚ ਜ਼ੈਰੋ ਤੋਂ “ਏਆਈ ਮਾਹਰ” ਨਹੀਂ ਬਣਦੇ। ਇੱਕ ਵਾਸਤਵਿਕ ਰਾਹ ਇਹ ਹੈ:
Ng ਦੀ ਸਮੱਗਰੀ ਕਦਮ 1 ਨੂੰ ਤੇਜ਼ ਕਰਦੀ ਹੈ। ਬਾਕੀ ਇਹਨਾਂ ਇਟਰੈਸ਼ਨਾਂ, ਫੀਡਬੈਕ, ਅਤੇ ਅਸਲ ਸਮੱਸਿਆਵਾਂ ਉੱਤੇ ਸਮਾਂ ਲਗਾਉਣ ਨਾਲ ਮਿਲਦਾ ਹੈ।
Andrew Ng ਦਾ ਡਿਵੈਲਪਰ-ਮਿਤ੍ਰ ਵਾਅਦਾ ਸਧਾਰਨ ਹੈ: ਥੋੜੀ ਜਿਹੀ ਜ਼ਰੂਰੀ ਥਿਊਰੀ ਸਿੱਖੋ ਜੋ ਕੁਝ ਬਣਾਉਣ ਲਈ ਲਾਜ਼ਮੀ ਹੈ, ਫਿਰ ਸਪੱਸ਼ਟ ਫੀਡਬੈਕ ਨਾਲ ਦੁਹਰਾਓ।
ਇੱਕ ਮਜਬੂਤ ਨੀਂਹੀ ਪਾਸ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ—ਮੁੱਤਰ ਤੌਰ 'ਤੇ ਕਿਹਾ ਤਾਂ ਲੋੜੀ ਆਈ ਧਾਰਣਾਵਾਂ (ਟਰੈਨਿੰਗ, ਓਵਰਫਿਟਿੰਗ, ਮੁਲਾਂਕਣ) ਨੂੰ ਸਮਝਣ ਲਈ ਕਾਫੀ।
ਫਿਰ, ਇੱਕ ਛੋਟਾ ਪ੍ਰੋਜੈਕਟ ਤੇਜ਼ੀ ਨਾਲ ਕਰੋ ਜੋ ਏਂਡ-ਟੂ-ਏਂਡ ਸੋਚ ਮਜ਼ਬੂਰ ਕਰੇ: ਡੇਟਾ ਇਕੱਠਾ ਕਰਨਾ, ਇੱਕ ਬੇਸਲਾਈਨ ਮਾਡਲ, ਮੈਟਰਿਕ, ਐਰਰ ਵਿਸ਼ਲੇਸ਼ਣ, ਅਤੇ ਇਟਰੈਸ਼ਨ। ਤੁਹਾਡਾ ਮਕਸਦ ਪੂਰਾ ਮਾਡਲ ਨਹੀਂ—ਇੱਕ ਦੁਹਰਾਓਯੋਗ ਵਰਕਫਲੋ ਹੈ।
ਕਈ ਛੋਟੇ ਪ੍ਰਯੋਗਾਂ ਤੋਂ ਬਾਅਦ ਹੀ ਵਿਸ਼ੇਸ਼ਤਾ (NLP, ਵਿਜ਼ਨ, ਰੇਕਮੈਂਡਰ ਸਿਸਟਮ, MLOps) ਚੁਣੋ। ਵਿਸ਼ੇਸ਼ਤਾ ਉਸ ਵੇਲੇ ਅਟਕਦੀ ਹੈ ਜਦ ਤੁਹਾਡੇ ਕੋਲ ਅਸਲ ਸਮੱਸਿਆਵਾਂ ਲਈ “ਹੂਕਸ” ਹੋਂਦੀਆਂ ਹਨ।
ਪਰਗਟ ਹਫਤੇ ਵਾਂਗ ਤਰੱਕੀ ਨੂੰ ਇੱਕ ਛੋਟੀ ਸਪ੍ਰਿੰਟ ਵਾਂਗ ਮੰਨੋ:
ਓਵਰਇੰਜੀਨੀਅਰ ਨਾ ਕਰੋ। ਇਕ ਜਾਂ ਦੋ ਚੰਗੇ ਦਸਤਾਵੇਜ਼ੀ ਪ੍ਰੋਜੈਕਟ ਪੰਜ ਅਧੂਰੇ ਡੈਮੋਜ਼ ਤੋਂ ਬਿਹਤਰ ਹੁੰਦੇ ਹਨ।
ਲਕੜੀ:
ਜੇ ਤੁਸੀਂ ਟੀਮ ਵਜੋਂ ਸਿੱਖ ਰਹੇ ਹੋ, ਤਾਂ ਸਹਿਯੋਗ ਦੇ ਤਰੀਕੇ ਸਟੈਂਡਰਡ ਕਰੋ:
ਇਹ Ng ਦੀ ਸਿੱਖਿਆ ਨੂੰ ਅਪਣੇ ਕੰਮ 'ਚ ਲਗੂ ਕਰਨ ਵਰਗੀ—ਸਪਸ਼ਟਤਾ, ਸੰਰਚਨਾ, ਅਤੇ ਇਟਰੈਸ਼ਨ।
Ng ਦੀ ਪਹੁੰਚ ਇੱਕ ਏਂਡ-ਟੂ-ਏਂਡ ਸਿਸਟਮ ਜਲਦੀ ਬਣਾਉਣ ਅਤੇ ਫਿਰ ਅਨੁਸ਼ਾਸਨਮਈ ਇਟਰੈਸ਼ਨ ਨਾਲ ਸੁਧਾਰ ਕਰਨ ਨੂੰ ਉਤਸ਼ਾਹਿਤ ਕਰਦੀ ਹੈ। ਜੇ ਤੁਹਾਡਾ ਟੀਚਾ ਇਸ ਮਨੋਭਾਵ ਨੂੰ ਸ਼ਿਪਡ ਸਾਫਟਵੇਅਰ ਵਿੱਚ ਬਦਲਣਾ ਹੈ—ਖਾਸ ਕਰਕੇ ਵੈਬ ਅਤੇ ਬੈਕਐਂਡ ਫੀਚਰ—ਤਾਂ ਅਜਿਹੇ ਟੂਲ ਜਿਹੜੇ "ਵਿਚਾਰ → ਕੰਮਕਾਜੀ ਐਪ" ਲੂਪ ਨੂੰ ਛੋਟਾ ਕਰਦੇ ਹਨ ਮਦਦਗਾਰ ਹੋ ਸਕਦੇ ਹਨ।
ਉਦਾਹਰਨ ਦੇ ਤੌਰ 'ਤੇ, Koder.ai ਇੱਕ vibe-coding ਪਲੇਟਫਾਰਮ ਹੈ ਜਿੱਥੇ ਤੁਸੀਂ ਗੱਲ-ਬਾਤ ਰਾਹੀਂ ਵੈਬ, ਸਰਵਰ, ਅਤੇ ਮੋਬਾਈਲ ਐਪ ਬਣਾਉ ਸਕਦੇ ਹੋ, ਫਿਰ ਫੀਚਰਾਂ ਜਿਵੇਂ Planning Mode, ਸਨੇਪਸ਼ਾਟ, ਰੋਲਬੈਕ, ਅਤੇ ਸੋਰਸ ਕੋਡ ਐਕਸਪੋਰਟ ਨਾਲ ਤੇਜ਼ੀ ਨਾਲ ਇਤਰੈਟ ਕਰ ਸਕਦੇ ਹੋ। ਚੰਗੀ ਤਰ੍ਹਾਂ ਵਰਤਿਆ ਜਾਣ 'ਤੇ, ਇਹ Ng ਜੋ ਰੀਥਮ ਸਿੱਖਾਉਂਦਾ ਹੈ ਉਸੇ ਨੂੰ ਸਹਾਰਾ ਦਿੰਦਾ: ਨਤੀਜਾ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ, ਬੇਸਲਾਈਨ ਬਣਾਓ, ਮਾਪੋ, ਅਤੇ ਸੁਧਾਰੋ—ਬਿਨਾਂ ਬੋਇਲਰਪਲੇਟ 'ਚ ਫਸੇ।
ਏਆਈ ਸਿੱਖਣ ਵਾਲੇ ਸਰੋਤ ਇੱਕੋ-ਇੱਕ ਤੋਂ ਵੱਧ ਤੇਜ਼ੀ ਨਾਲ ਵੱਧਦੇ ਹਨ। ਲਕੜੀ ਇਹ ਨਹੀਂ ਕਿ "ਸਭ ਤੋਂ ਵਧੀਆ ਲੱਭੋ"—ਇਹ ਹੈ ਇੱਕ ਰਾਹ ਚੁਣੋ ਜੋ ਤੁਹਾਡੇ ਨਤੀਜੇ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਹੋਵੇ, ਅਤੇ ਫਿਰ ਇਸ 'ਤੇ ਪੱਕਾ ਰੁਕੀ ਰਿਹੋ ਤਾਂ ਕਿ ਤੁਸੀਂ ਅਸਲੀ ਹੁਨਰ ਬਣਾਉ।
ਭਰਤੀ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਵਾਜਬ ਸਵਾਲ ਪੁੱਛੋ:
ਇੱਕ ਮਜ਼ਬੂਤ ਕੋਰਸ ਆਮ ਤੌਰ 'ਤੇ ਤਿੰਨ ਸੰਕੇਤ ਰੱਖਦਾ ਹੈ:
ਜੇ ਕੋਈ ਕੋਰਸ "ਜ਼ੀਰੋ ਤੋਂ ਮਾਸਟਰੀ" ਦਾ ਦਾਅਵਾ ਕਰਦਾ ਹੈ ਬਿਨਾਂ ਪ੍ਰਾਜੈਕਟਾਂ ਦੇ, ਤਾਂ ਇਸਨੂੰ ਮਨੋਰੰજન ਸਮਝੋ।
ਇਹ ਅਸਾਨ ਹੈ ਕਿ ਤੁਸੀਂ ਫਰੇਮਵਰਕਸ, ਨੋਟਬੁੱਕ, ਅਤੇ ਰੁਝਾਨੀ ਟਿcਟੋਰਿਯਲਾਂ ਵਿੱਚ ਉਛਲ-ਛਾਲ ਕਰੋ। ਇਸਦੀ ਥਾਂ, ਇੱਕ ਸੀਜ਼ਨ ਲਈ ਇੱਕ ਪ੍ਰਧਾਨ ਸਟੈਕ ਚੁਣੋ ਅਤੇ ਡੇਟਾ ਗੁਣਵੱਤਾ, ਮੁਲਾਂਕਣ ਮੈਟ੍ਰਿਕ, ਅਤੇ ਐਰਰ ਵਿਸ਼ਲੇਸ਼ਣ ਵਰਗੀਆਂ ਧਾਰਣਾਵਾਂ 'ਤੇ ਧਿਆਨ ਦਿਓ। ਟੂਲ ਬਦਲਦੇ ਹਨ; ਇਹ ਧਾਰਣਾਵਾਂ ਨਹੀਂ।
Andrew Ng ਦਾ ਸਭ ਤੋਂ ਵੱਡਾ ਪ੍ਰਭਾਵ ਇੱਕ ਕੋਰਸ ਜਾਂ ਪਲੇਟਫਾਰਮ ਨਹੀਂ—ਇਹ ਡਿਵੈਲਪਰ ਲਰਨਿੰਗ ਸੱਭਿਆਚਾਰ ਵਿੱਚ ਇਕ ਬਦਲਾਅ ਹੈ। ਉਸਨੇ ਏਆਈ ਨੂੰ ਇੱਕ ਬਣਾਉਣਯੋਗ ਕੌਸ਼ਲ ਬਣਾਉਣ ਵਿੱਚ ਮਦਦ ਕੀਤੀ: ਕੁਝ ਪਰਤਾਂ ਵਿੱਚ ਸਿੱਖੋ, ਛੋਟੇ ਪ੍ਰਯੋਗਾਂ ਨਾਲ ਅਭਿਆਸ ਕਰੋ, ਅਤੇ ਫੀਡਬੈਕ ਰਾਹੀਂ ਸੁਧਾਰ ਕਰੋ—ਰਹੱਸਮਈਤਾ ਦੀ ਥਾਂ।
ਬਿਲਡਰਾਂ ਲਈ, ਰਹਿਣ ਵਾਲੀ ਸਿਖਲਾਈ ਨਵੀਂ ਮਾਡਲ ਦੀ ਤਰਕਸ਼ੀੜੀ ਫੜਨ ਤੋਂ ਘੱਟ ਅਤੇ ਇਕ ਭਰੋਸੇਯੋਗ ਵਰਕਫਲੋ ਅਪਣਾਉਣ 'ਤੇ ਵੱਧ ਹੈ:
Ng ਦੀ ਸਿੱਖਿਆ ਇੱਕ ਬਿਲਡਰ ਦਾ ਮਨੋਭਾਵ ਪ੍ਰਚਾਰਿਤ ਕਰਦੀ ਹੈ: ਇੱਕ ਕਾਰਯਸ਼ੀਲ ਏਂਡ-ਟੂ-ਏਂਡ ਸਿਸਟਮ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ, ਫਿਰ ਉਸ ਦੀ ਵਕਈ ਤੋਰ 'ਤੇ ਫੇਲ ਹੋ ਰਹੀ ਜਗ੍ਹਾ 'ਤੇ ਧਿਆਨ ਕੇਂਦਰਿਤ ਕਰੋ। ਇਸ ਤਰ੍ਹਾਂ ਟੀਮਾਂ ਸ਼ਿਪ ਕਰਦੀਆਂ ਹਨ।
ਇਹ ਇੱਕੋ ਸਮੇਂ ਉਤਪਾਦ ਸੋਚ ਨੂੰ ਵੀ ਉਤਸ਼ਾਹਿਤ ਕਰਦਾ ਹੈ: ਪੁੱਛੋ ਕਿ ਯੂਜ਼ਰਾਂ ਨੂੰ ਕੀ ਚਾਹੀਦਾ ਹੈ, ਕਿੜੀਆਂ ਸੀਮਾਵਾਂ ਹਨ, ਅਤੇ ਕਿਹੜੇ ਫੇਲਿਯਰ ਮੋਡ ਸਹਿਣਯੋਗ ਹਨ—ਫਿਰ ਮਾਡਲ ਅਤੇ ਡੇਟਾ ਪਾਈਪਲਾਈਨ ਨੂੰ ਉਸ ਅਨੁਸਾਰ ਡਿਜ਼ਾਈਨ ਕਰੋ।
ਇਕ ਛੋਟਾ ਸਮੱਸਿਆ ਚੁਣੋ ਜੋ ਤੁਸੀਂ ਏਂਡ-ਟੂ-ਏਂਡ ਪੂਰਾ ਕਰ ਸਕੋ: ਸਹਾਇਤਾ ਟਿਕਟਾਂ ਨੂੰ ਵਰਗੀਕ੍ਰਿਤ ਕਰੋ, ਡੁਪਲਿਕੇਟ ਰਿਕਾਰਡਾਂ ਦੀ ਪਹਿਚਾਣ ਕਰੋ, ਨੋਟਾਂ ਦਾ ਸਾਰ ਲਿਖੋ, ਜਾਂ ਲੀਡਾਂ ਨੂੰ ਰੈਂਕ ਕਰੋ।
ਇੱਕ ਸਧਾਰਨ ਸੰਸਕਰਣ ਸ਼ਿਪ ਕਰੋ, ਇਸਨੂੰ ਇੱਕ ਮੈਟ੍ਰਿਕ ਨਾਲ ਇੰਸਟਰੂਮੈਂਟ ਕਰੋ, ਅਤੇ ਅਸਲ ਗਲਤੀਆਂ ਦੀ ਸਮੀਖਿਆ ਕਰੋ। ਪਹਿਲਾਂ ਡੇਟਾਸੈੱਟ ( ਜਾਂ ਜੇ ਤੁਸੀਂ LLM ਵਰਤ ਰਹੇ ਹੋ ਤਾਂ ਪ੍ਰਾਂਪਟਸ) ਸੁਧਾਰੋ, ਫਿਰ ਮਾਡਲ ਨੂੰ ਠੀਕ ਕਰੋ। ਜਦ ਤੱਕ ਇਹ ਉਪਯੋਗੀ ਨਾ ਬਣੇ, ਦੋਹਰਾਓ—ਪਰ ਪੂਰਨ ਬਣਾਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਨਾ ਕਰੋ।
ਉਸ ਨੇ ਮਸ਼ੀਨ ਲਰਨਿੰਗ ਨੂੰ ਇੱਕ ਇੰਜਨੀਅਰਿੰਗ ਵਰਕਫਲੋ ਵਜੋਂ ਸਿਖਾਇਆ: ਇਨਪੁਟ/ਆਉਟਪੁਟ ਪਰिभਾਸ਼ਿਤ ਕਰੋ, ਬੇਸਲਾਈਨ ਚੁਣੋ, ਟ੍ਰੇਨ ਕਰੋ, ਮਾਪੋ, ਫਿਰ ਦੁਹਰਾਓ।
ਇਹ ਫਰੇਮਿੰਗ ਉਹਨਾਂ ਤਰੀਕਿਆਂ ਨਾਲ ਮਿਲਦੀ ਹੈ ਜਿੰਨ੍ਹਾਂ 'ਤੇ ਡਿਵੈਲਪਰ ਪਹਿਲਾਂ ਹੀ ਸੌਫਟਵੇਅਰ ਭੇਜਦੇ ਹਨ, ਇਸ ਲਈ ਏਆਈ "ਰਹੱਸਮਈ ਗਣਿਤ" ਵਾਂਗ ਨਹੀਂ ਲੱਗਦੀ, ਬਲਕਿ ਇੱਕ ਅਭਿਆਸਯੋਗ ਕੌਸ਼ਲ ਬਣ ਜਾਂਦੀ ਹੈ।
ਇੱਕ ਆਮ “Ng-ਸਟਾਈਲ” ਲੂਪ ਇਸ ਤਰ੍ਹਾਂ ਹੈ:
ਇਹ ਮਾਡਲਾਂ 'ਤੇ ਲਾਗੂ ਕੀਤੀ ਗਈ ਸੰਰਚਿਤ ਡੀਬੱਗਿੰਗ ਹੈ।
ਉਹਨਾਂ ਨੇ ਛੋਟੀ ਲੈਕਚਰਾਂ ਨੂੰ ਹੈਂਡਸ-ਆਨ ਅਸਾਈਨਮੈਂਟਾਂ ਅਤੇ ਤੁਰੰਤ ਫੀਡਬੈਕ (ਕੁਇਜ਼/ਆਟੋਗ੍ਰੇਡਰ) ਨਾਲ ਜੋੜਿਆ।
ਬਿਜੀ ਡਿਵੈਲਪਰਾਂ ਲਈ, ਇਹ 20–40 ਮਿੰਟ ਵਾਲੀਆਂ ਸੈਸ਼ਨਾਂ ਵਿੱਚ ਤਰੱਕੀ सम्भਵ ਬਣਾਉਂਦਾ ਹੈ, ਅਤੇ ਅਸਾਈਨਮੈਂਟ ਇਹ ਯਕੀਨੀ ਬਣਾਉਂਦੇ ਹਨ ਕਿ ਤੁਸੀਂ ਵਿਚਾਰਾਂ ਨੂੰ ਕੰਮ ਕਰਨ ਵਾਲੇ ਕੋਡ ਵਿੱਚ ਤਬਦੀਲ ਕਰੋ ਨਾ ਕਿ ਸਿਰਫ਼ ਵੀਡੀਓ ਦੇਖੋ।
ਲਾਜ਼ਮੀ ਨਹੀਂ। ਮਟਰੀਅਲ ਵਿੱਚ ਕੈਲਕੁਲਸ/ਲਿਨੀਅਰ ਐਲਜੀਬਰਾ ਵਾਲੀਆਂ ਚੀਜ਼ਾਂ ਹੋਂਦੀਆਂ ਹਨ, ਪਰ ਵੱਡੇ ਰੁਕਾਵਟ ਆਮ ਤੌਰ 'ਤੇ ਪ੍ਰੈਟਿਕਲ ਹਨ:
ਤੁਸੀਂ ਪਹਿਲਾਂ ਬੁਨਿਆਦੀ ਧਾਰਣਾ ਨਾਲ ਸ਼ੁਰੂ ਕਰ ਸਕਦੇ ਹੋ ਅਤੇ ਜ਼ਰੂਰਤ ਪੈਣ 'ਤੇ ਗਣਿਤ ਦੀ ਗਹਿਰਾਈ ਬਣਾ ਸਕਦੇ ਹੋ।
ਇਹ ਇੱਕ ਨਿਧਾਰਨਾਤਮਕ ਨਜ਼ਰੀਆ ਹੈ:
ਇਹ ਤੁਹਾਨੂੰ ਅਗਲਾ ਕਦਮ ਦਿਖਾਉਂਦਾ ਹੈ—ਉਦਾਹਰਣ ਲਈ ਵੈਰੀਅਂਸ ਲਈ ਡੇਟਾ/ਰੇਗੂਲਰਾਇਜ਼ੇਸ਼ਨ ਜੋੜੋ, ਬਾਇਅਸ ਲਈ ਮਾਡਲ ਸਮਰੱਥਾ/ਫੀਚਰ ਗੁਣਵੱਤਾ ਵਧਾਓ—ਬਿਨਾਂ ਅਟਕਣ ਦੇ।
ਸ਼ੁਰੂਆਤ ਕਰੋ:
ਫਿਰ ਐਰਰ ਵਿਸ਼ਲੇਸ਼ਣ ਕਰੋ ਅਤੇ ਬੜਹਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਡੇਟਾ/ਲੇਬਲਿੰਗ ਸੁਧਾਰੋ। ਇਹ"ਮੇਰੇ ਨੋਟਬੁੱਕ 'ਤੇ ਚੱਲਦਾ ਹੈ" ਦੀ ਸਮੱਸਿਆ ਨੂੰ ਰੋਕਦਾ ਹੈ ਜੋ ਅਸਲਤੋੜ 'ਤੇ ਢਹਿ ਸਕਦੀ ਹੈ।
ਇਹ ਸੋਚ ਹੈ ਕਿ ਡੇਟਾ ਗੁਣਵੱਤਾ ਅਕਸਰ ਮੁੱਖ ਲੀਵਰ ਹੁੰਦੀ ਹੈ:
ਕਈ ਟੀਮਾਂ ਨਵੇਂ ਆਰਕੀਟੈਕਚਰ ਬਦਲਣ ਦੀ ਬਜਾਏ ਡੇਟਾਸੈੱਟ ਅਤੇ ਫੀਡਬੈਕ ਲੂਪ ਸੁਧਾਰ ਕੇ ਵੱਡੇ ਫਾਇਦੇ ਪਾਉਂਦੀਆਂ ਹਨ।
ਸਿੱਖਿਆ ਤੁਹਾਨੂੰ ਨਿਯੰਤਰਿਤ ਅਭਿਆਸ ਦਿੰਦੀ ਹੈ; ਅਸਲ ਕੰਮ ਵੱਧ ਪਾਬੰਦੀਆਂ ਲਿਆਂਦਾ ਹੈ:
ਕੋਰਸ ਬੁਨਿਆਦੀਆਂ ਤੇ ਤੇਜ਼ੀ ਲਿਆਉਂਦੇ ਹਨ, ਪਰ ਯੋਗਤਾ ਛੋਟੇ ਏਂਡ-ਟੂ-ਏਂਡ ਪ੍ਰोजੈਕਟ ਸ਼ਿਪ ਕਰਕੇ ਹੀ ਅਸਲ ਵਿੱਚ ਬਣਦੀ ਹੈ।
ਇੱਕ ਤੰਗ ਸਮੱਸਿਆ ਚੁਣੋ ਅਤੇ ਪੂਰੇ ਲੂਪ ਨੂੰ ਦਸਤਾਵੇਜ਼ ਕਰੋ:
ਇਕ ਚੰਗੀ ਤਰ੍ਹਾਂ ਸਮਝਾਈ ਹੋਈ 1–2 ਪ੍ਰਾਜੈਕਟ ਜ਼ਿਆਦਾ ਭਰੋਸਾ ਥਾਂ ਦਿੰਦੇ ਹਨ ਬਜਾਏ ਕਈ ਅਧੂਰੇ ਡੈਮੋਜ਼ ਦੇ।
ਇੱਕ ਸਧਾਰਨ ਛਾਣ-ਬੀਨ:
ਫਿਰ ਇੱਕ ਟ੍ਰੈਕ ਚੁਣੋ ਅਤੇ ਉਸ ਨਾਲ ਕਾਫ਼ੀ ਸਮਾਂ ਰਹੋ ਤਾਂ ਕਿ ਤੁਸੀਂ ਬਣਾਉ ਅਤੇ ਸ਼ਿਪ ਕਰ ਸਕੋ।