Jeff Dean ਦੇ ਕਰੀਅਰ ਅਤੇ ਉਹ ਸਿਸਟਮ ਜੋ Google 'ਤੇ AI ਨੂੰ ਸਕੇਲ ਕਰਨ ਵਿੱਚ ਮਦਦਗਾਰ ਰਹੇ—MapReduce, Bigtable, ਅਤੇ ਆਧੁਨਿਕ ML ਇਨਫਰਾਸਟਰੱਕਚਰ ਤੋਂ ਸਿੱਖਣਯੋਗ ਪਾਠਾਂ ਦੀ ਪ੍ਰਾਇਗਮੈਟਿਕ ਰੂਪ-ਰੇਖਾ।
Jeff Dean ਇਸ ਲਈ ਮਹੱਤਵਪੂਰਨ ਹੈ ਕਿਉਂਕਿ ਬਹੁਤ ਸਾਰੇ “ਬ੍ਰੇਕਥਰੂ” ਜੋ ਲੋਕ ਆਧੁਨਿਕ ਮਸ਼ੀਨ ਲਰਨਿੰਗ ਨਾਲ ਜੋੜਦੇ ਹਨ, ਸਿਰਫ਼ ਤਦ ਹੀ ਉਪਯੋਗੀ ਬਣਦੇ ਹਨ ਜਦੋਂ ਉਹ ਵੱਡੇ ਡਾਟਾ ਉੱਤੇ ਭਰੋਸੇਯੋਗ, ਦੁਹਰਾਏ ਜਾਣਯੋਗ ਅਤੇ ਸਸਤੇ ਤਰੀਕੇ ਨਾਲ ਚਲ ਸਕਣ। ਉਸਦਾ ਸਭ ਤੋਂ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਕੰਮ ਇੱਕ ਪ੍ਰੋਮੀਸਿੰਗ ਵਿਚਾਰ ਅਤੇ ਇੱਕ ਐਸੇ ਸਿਸਟਮ ਦੇ ਵਿਚਕਾਰ ਰਹਿੰਦਾ ਹੈ ਜੋ ਲੱਖਾਂ ਯੂਜ਼ਰਾਂ ਨੂੰ ਸਰਵ ਕਰ ਸਕੇ।
ਜਦੋਂ ਟੀਮਾਂ ਕਹਿੰਦੀਆਂ ਹਨ ਕਿ ਉਹ "AI ਨੂੰ ਸਕੇਲ" ਕਰਨਾ ਚਾਹੁੰਦੀਆਂ ਹਨ, ਉਹ ਆਮਤੌਰ 'ਤੇ ਕਈ ਸੀਮਾਵਾਂ ਦਾ ਸੰਤੁਲਨ ਕਰ ਰਹੀਆਂ ਹੁੰਦੀਆਂ ਹਨ:
ਵੱਡੇ ਪੈਮाने ਤੇ AI ਕਿਸੇ ਇਕ ਮਾਡਲ ਬਾਰੇ ਘੱਟ ਅਤੇ ਇੱਕ ਐਸੇ ਅਸੈਂਬਲੀ ਲਾਈਨ ਬਾਰੇ ਜ਼ਿਆਦਾ ਹੈ: ਪਾਈਪਲਾਈਨ, ਸਟੋਰੇਜ, ਵੰਡਿਆ ਹੋਇਆ ਐਗਜ਼ਿਕਿੁਸ਼ਨ, ਮਾਨੀਟਰਿੰਗ ਅਤੇ ਸੁਚਿੱਤ ਇੰਟਰਫੇਸ ਜੋ ਕਈ ਟੀਮਾਂ ਨੂੰ ਇਕ ਦੂਜੇ ਨਾਲ ਟੱਕਰ ਨਾ ਖਾਂਦੇ ਹੋਏ ਬਣਾਉਣ ਦੀ ਆਜ਼ਾਦੀ ਦਿੰਦੀਆਂ ਹਨ।
ਇਹ ਕੋਈ ਸੈਲੀਬਰਿਟੀ ਪ੍ਰੋਫ਼ਾਈਲ ਨਹੀਂ ਹੈ ਅਤੇ ਨਾਹ ਹੀ ਇਹ ਕਹਾਣੀ ਹੈ ਕਿ ਇਕ ਵਿਅਕਤੀ ਨੇ Google ਦਾ AI "ਇਜਾਦ" ਕੀਤਾ। Google ਦੀ ਸਫਲਤਾ ਬਹੁਤ ਸਾਰੀਆਂ ਟੀਮਾਂ ਅਤੇ ਰਿਸਰਚਰਾਂ ਮੁੱਲ ਹੈ।
ਇਸ ਦੀ ਬਜਾਏ, ਇਹ ਪੋਸਟ ਉਹਨਾਂ ਇੰਜੀਨੀਅਰਿੰਗ ਪੈਟਰਨਾਂ 'ਤੇ ਧਿਆਨ ਕੇਂਦ੍ਰਿਤ ਕਰਦੀ ਹੈ ਜੋ MapReduce, Bigtable ਅਤੇ ਬਾਦ ਵਿੱਚ ML ਇਨਫਰਾਸਟਰੱਕਚਰ ਦੇ ਕੰਮਾਂ 'ਚ ਆਮ ਤੌਰ 'ਤੇ ਮਿਲਦੇ ਹਨ। ਮਕਸਦ ਇਹ ਹੈ ਕਿ ਤੁਸੀਂ ਉਹ ਵਿਚਾਰ ਲੈ ਜਾ ਸਕੋ ਜੋ ਅਪਲਾਈ ਕਰਨਯੋਗ ਹਨ: ਫੇਲਿਅਰ ਲਈ ਡਿਜ਼ਾਈਨ ਕਿਵੇਂ ਕਰੀਏ, ਵਰਕਫਲੋਜ਼ ਨੂੰ ਕਿੱਤੋਂ ਸਧਾਰਨ ਕਰੀਏ, ਅਤੇ ਪ੍ਰਯੋਗ ਨੂੰ ਰੋਜ਼ਾਨਾ ਦਾ ਹਿੱਸਾ ਕਿਵੇਂ ਬਣਾਈਏ।
ਜੇ ਤੁਹਾਨੂੰ ਐਸਾ ਮਸ਼ੀਨ ਲਰਨਿੰਗ ਸ਼ਿਪ ਕਰਨੀ ਹੈ ਜੋ ਅਸਲੀ ਟ੍ਰੈਫਿਕ ਅਤੇ ਸੀਮਾਵਾਂ 'ਤੇ ਟਿਕ ਸਕੇ, ਤਾਂ ਸਿਸਟਮ-ਦ੍ਰਿਸ਼ਟੀਕੋਣ ਮੁੱਖ ਕਹਾਣੀ ਹੈ—ਅਤੇ Jeff Dean ਦਾ ਕਰੀਅਰ ਇਸ ਰਾਹ ਦੀ ਇੱਕ ਉਪਯੋਗ ਯਾਦੀ ਤਾਰ ਹੈ।
Jeff Dean Google ਵਿੱਚ ਉਸ ਸਮੇਂ ਸ਼ਾਮਿਲ ਹੋਇਆ ਜਦੋਂ Google עדיין ਪ੍ਰਭਾਵ ਅਤੇ "ਪ੍ਰੋਡਕਸ਼ਨ" ਦੇ ਅਰਥ ਨੂੰ ਖਰਾ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਰਿਹਾ ਸੀ: ਕੁਝ ਸੇਵਾਵਾਂ, ਤੇਜ਼ ਵਧਦੀ ਯੂਜ਼ਰ ਬੇਸ, ਅਤੇ ਇਹ ਉਮੀਦ ਕਿ سرچ ਨਤੀਜੇ ਹਰ ਵਾਰੀ ਤੁਰੰਤ ਲੋਡ ਹੋਣ।
Search ਯੁੱਗ ਵਾਲਾ Google ਉਹ ਸਮੱਸਿਆਵਾਂ ਸਾਹਮਣੇ ਆਇਆ ਜੋ ਕਿਸੇ ਵੀ ਸਕੇਲਿੰਗ ਟੀਮ ਨੂੰ ਜਾਣੀਆਂ ਪੈਂਦੀਆਂ ਹਨ:
ਇਸ ਨੇ ਇਕ ਪ੍ਰਾਇਗਮੈਟਿਕ ਸੋਚ ਨੂੰ ਜਨਮ ਦਿੱਤਾ: ਫੇਲਿਅਰ ਹੋਣ ਨੂੰ ਮੰਨੋ, ਰਿਕਵਰੀ ਲਈ ਡਿਜ਼ਾਈਨ ਕਰੋ, ਅਤੇ ਪ੍ਰਦਰਸ਼ਨ ਨੂੰ ਸਿਸਟਮ ਪੱਧਰ 'ਤੇ ਕੰਮ ਕਰਾਵੋ—ਇੱਕ ਸਰਵਰ ਨੂੰ ਹੱਥ ਨਾਲ ਟਿਊਨ ਕਰਨ ਨਾਲ ਨਹੀਂ।
ਕਿਉਂਕਿ ਸਰਚ ਹਰ ਕਵੇਰੀ 'ਤੇ ਕਈ ਮਸ਼ੀਨਾਂ ਨੂੰ ਛੂਹਦਾ ਹੈ, ਛੋਟੀ-ਛੋਟੀ ਅਣਚਾਹੀਆਂ ਤੇਜ਼ੀ ਨਾਲ ਵਧਦੀਆਂ ਸਨ। ਇਸ ਦਬਾਅ ਨੇ ਉਹਨਾਂ ਪੈਟਰਨਾਂ ਨੂੰ ਪ੍ਰਫ਼ੈਰੈਂਸ ਦਿੱਤਾ ਜੋ:
ਜਦੋਂ Google ਵੱਡੇ-ਪੈਮਾਨੇ ਦਾ ਡਾਟਾ ਪ੍ਰੋਸੈਸਿੰਗ ਅਤੇ ਮਸ਼ੀਨ ਲਰਨਿੰਗ ਵੱਲ ਵਧਿਆ, ਉਹੀ ਤਰਜੀਹਾਂ ਜਾਰੀ ਰਹੀਆਂ: ਪੇਸ਼ਗੋਈ ਯੋਗ ਪ੍ਰਦਰਸ਼ਨ, ਆਪਰੇਸ਼ਨਲ ਸੁਰੱਖਿਆ, ਅਤੇ ਐਸੇ ਡਿਜ਼ਾਈਨ ਜੋ ਹਿੱਸੇਵਾਰ outages ਨੂੰ ਸਹਿ ਸਕਣ।
Dean ਦੇ ਪ੍ਰਭਾਵ ਨਾਲ ਜੁੜੀ ਇੱਕ ਮੁੜ-ਮੁੜ ਆਉਣ ਵਾਲੀ ਥੀਮ ਹੈ leverage। ਹਰ ਨਵੇਂ ਸਕੇਲਿੰਗ ਚੈਲੇਂਜ ਨੂੰ ਨਵੇਂ ਸਿਰੇ ਤੋਂ ਹੱਲ ਕਰਨ ਦੀ ਬਜਾਏ, Google ਨੇ ਅੰਦਰੂਨੀ building blocks ਵਿੱਚ ਨਿਵੇਸ਼ ਕੀਤਾ—ਸਾਂਝੇ ਸਿਸਟਮ ਜੋ ਕਈ ਟੀਮਾਂ ਨੂੰ ਘੱਟ ਮਾਹਰਾਂ ਨਾਲ ਤੇਜ਼ੀ ਨਾਲ ਸ਼ਿਪ ਕਰਨ ਦਿੰਦੇ।
ਇਹ ਪਲੇਟਫਾਰਮ ਮਾਇੰਡਸੈਟ ਉਸ ਸਮੇਂ ਕਰੀੜਾ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਤੁਹਾਡੇ ਕੋਲ ਦਰਜਨ (ਫਿਰ ਸੈਂਕੜੇ) ਟੀਮਾਂ ਹੁੰਦੀਆਂ ਹਨ। ਇਹ ਸਿਰਫ਼ ਇਕ ਸਿਸਟਮ ਨੂੰ ਤੇਜ਼ ਬਣਾਉਣ ਬਾਰੇ ਨਹੀਂ—ਇਹ ਪੂਰੇ ਆਰਗੇਨਾਈਜੇਸ਼ਨ ਨੂੰ ਐਸਾ ਬਣਾਉਣ ਬਾਰੇ ਹੈ ਕਿ ਉਹ ਨਵੀਂ-ਨਵੀਂ ਤੇਜ਼ ਸਿਸਟਮ ਬਿਨਾਂ ਮੁਲ-ਘੜੀ ਦੁਬਾਰਾ ਨਾ ਬਣਾਉਣ ਦੇ ਤਿਆਰ ਹੋਵੇ।
ਜਦੋਂ ਕੋਈ ਵਰਕਲੋਡ ਇਕ ਮਸ਼ੀਨ ਤੋਂ ਬਾਹਰ ਜਾਦਾ ਹੁੰਦਾ ਹੈ, ਪਹਿਲਾ ਬੋਤਲਨੈਕ "ਹੋਰ CPU" ਨਹੀਂ ਹੁੰਦਾ। ਇਹ ਫਰਕ ਹੁੰਦਾ ਹੈ ਜੋ ਤੁਸੀਂ ਗਣਨਾ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ ਅਤੇ ਜੋ ਤੁਹਾਡਾ ਸਿਸਟਮ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਕੋਆਰਡੀਨੇਟ ਕਰ ਸਕਦਾ ਹੈ ਵਿਚ ਵਧਦਾ ਹੈ। ਟਰੇਨਿੰਗ ਅਤੇ ਸਰਵਿੰਗ AI ਸਿਸਟਮ ਸਭ ਕੁਝ ਇੱਕਸਾਥ ਦਬਾਉਂਦੇ ਹਨ: ਕੰਪਿਊਟ (GPU/TPU ਸਮਾਂ), ਡਾਟਾ (ਥਰੂਪੁੱਟ ਅਤੇ ਸਟੋਰੇਜ), ਅਤੇ ਭਰੋਸਾਯੋਗਤਾ (ਕਿਆ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਕੁਝ ਫੇਲ ਹੋ ਜਾਂਦਾ ਹੈ)।
ਇੱਕ ਇਹਕਲ ਸਰਵਰ ਦਾ ਫੇਲ ਹੋਣਾ ਅਸੁਵਿਧਾ ਹੈ। ਇੱਕ ਫਲੀਟ ਵਿੱਚ ਇਹ ਆਮ ਗੱਲ ਹੈ। ਜਦੋਂ ਨੌਕਰੀਆਂ ਸੈਂਕੜਿਆਂ ਜਾਂ ਹਜ਼ਾਰਾਂ ਮਸ਼ੀਨਾਂ 'ਤੇ ਫੈਲਦੀਆਂ ਹਨ, ਤੁਸੀਂ ਉਮੀਦਯੋਗ ਦਰਦ-ਬਿੰਦੂ ਮਿਲਦੇ ਹੋ: ਸਟ੍ਰੈਗਲਰਜ਼ (ਇੱਕ ਹੌਲੀ ਵਰਕਰ ਸਾਰਿਆਂ ਨੂੰ ਰੋਕਦਾ ਹੈ), ਨੈਟਵਰਕ ਟਕਰਾਅ, ਅਸੰਗਤ ਡਾਟਾ ਪੜ੍ਹਾਈਆਂ, ਅਤੇ cascading retries ਜੋ ਮੂਲ ਸਮੱਸਿਆ ਨੂੰ ਭੜਕਾਉਂਦੀਆਂ ਹਨ।
Sharding ਡਾਟਾ ਅਤੇ ਕੰਮ ਨੂੰ ਛੋਟੇ ਹਿੱਸਿਆਂ ਵਿੱਚ ਵੰਡਦਾ ਹੈ ਤਾਂ ਜੋ ਕੋਈ ਇਕ ਮਸ਼ੀਨ ਘਟਨਾਕਾਰੀ ਨਾ ਬਣੇ।
Replication ਕਈ ਨਕਲਾਂ ਰੱਖਦਾ ਹੈ ਤਾਂ ਕਿ ਫੇਲਿਅਰ ਡਾਊਨਟਾਈਮ ਜਾਂ ਡਾਟਾ ਲੌਸ ਵਿੱਚ ਨਾ ਬਦਲੇ।
Fault tolerance ਅੰਸ਼ਿਕ ਫੇਲ ਇਤਫਾਕ ਮੰਨਦਾ ਹੈ ਅਤੇ ਰਿਕਵਰੀ ਲਈ ਡਿਜ਼ਾਈਨ ਕਰਦਾ ਹੈ: ਟਾਸਕਾਂ ਨੂੰ ਰੀਸਟਾਰਟ ਕਰੋ, shards ਨੂੰ ਮੁੜ-ਨਿਰਧਾਰਤ ਕਰੋ, ਨਤੀਜੇ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ।
Backpressure ਉਦਯੋਗਾਂ ਨੂੰ ਰੋਕਦਾ ਹੈ ਜਦੋਂ ਕਨਜ਼ਯੂਮਰਜ਼ ਕੈਚ-ਅਪ ਨਹੀਂ ਕਰ ਸਕਦੇ—ਕਿ queues, ਪਾਈਪਲਾਈਨ ਅਤੇ ਟਰੇਨਿੰਗ ਇਨਪੁਟ ਲਈ ਅਤਿ ਮਹੱਤਵਪੂਰਨ ਹੈ।
ਸਕੇਲ 'ਤੇ, ਇੱਕ ਪਲੇਟਫਾਰਮ ਜੋ ਬਹੁਤ ਸਾਰੀਆਂ ਟੀਮਾਂ ਦੁਆਰਾ ਸਹੀ ਤਰੀਕੇ ਨਾਲ ਵਰਤਿਆ ਜਾ ਸਕੇ, ਉਸ bespoke ਉੱਚ-ਪਰਫਾਰਮੈਂਸ ਸਿਸਟਮ ਤੋਂ ਵਧੇਰੇ ਮੁੱਲਵਾਨ ਹੈ ਜੋ ਸਿਰਫ਼ ਆਪਣੇ ਲੇਖਕ ਚਲਾ ਸਕਦੇ ਹਨ। ਸਪੱਸ਼ਟ ਡਿਫੌਲਟ, ਇਕਸਾਰ APIs, ਅਤੇ ਅਨੁਮਾਨਿਤ ਫੇਲਿਯਰ ਮੋਡ ਅਕਸਮਾਤੀ ਦੀ ਜਟਿਲਤਾ ਘਟਾਉਂਦੇ ਹਨ—ਖਾਸ ਕਰਕੇ ਜਦੋਂ ਉਪਭੋਗਤਾ ਰਿਸਰਚਰ ਤੇਜ਼ੀ ਨਾਲ ਇਟਰੇਟ ਕਰ ਰਹੇ ਹੁੰਦੇ ਹਨ।
ਤੁਸੀਂ ਸ਼ਾਇਦ ਤਿੰਨੋ ਨੂੰ ਵਧ ਤੋਂ ਵਧ ਨਹੀਂ ਕਰ ਸਕਦੇ। aggressive caching ਅਤੇ async ਪ੍ਰੋਸੈਸਿੰਗ ਪ੍ਰਦਰਸ਼ਨ ਨੂੰ ਸੁਧਾਰਦੇ ਹਨ ਪਰ ਸਹੀਤਾ ਨੂੰ ਜਟਿਲ ਬਣਾ ਸਕਦੇ ਹਨ। ਕਠੋਰ ਸਹਿਮਤੀ ਅਤੇ ਵੈਲੀਡੇਸ਼ਨ ਸਹੀਤਾ ਨੂੰ ਸੁਧਾਰਦੇ ਹਨ ਪਰ ਥਰੂਪੁੱਟ ਘਟਾ ਸਕਦੇ ਹਨ। ਓਪਰੇਬਿਲਟੀ—ਡਿਬੱਗਿੰਗ, ਮੈਟ੍ਰਿਕਸ, ਸੇਫ਼ ਰੋਲਆਉਟ—ਅਕਸਰ ਇਹ ਨਿਰਧਾਰਤ ਕਰਦੀ ਹੈ ਕਿ ਇੱਕ ਸਿਸਟਮ ਪ੍ਰੋਡਕਸ਼ਨ ਦੇ ਸੰਪਰਕ ਨਾਲ ਕਿੰਨਾ ਚੱਲਦਾ ਹੈ।
ਇਹ ਤਣਾਅ ਉਸ ਇਨਫਰਾਸਟਰੱਕਚਰ ਨੂੰ ਆਕਾਰ ਦਿੱਤਾ ਜੋ Jeff Dean ਨੇ ਪ੍ਰਚਲਿਤ ਕੀਤਾ: ਐਸੇ ਸਿਸਟਮ ਜੋ ਸਿਰਫ਼ ਗਣਨਾ ਨੂੰ ਹੀ ਨਹੀਂ, ਸਗੋਂ ਭਰੋਸਾਯੋਗਤਾ ਅਤੇ ਮਨੁੱਖੀ ਉਪਯੋਗ ਨੂੰ ਵੀ ਇਕੱਠੇ ਸਕੇਲ ਕਰਨ ਲਈ ਬਣੇ ਹਨ।
MapReduce ਇਕ ਸਧਾਰਣ ਵਿਚਾਰ ਹੈ ਜਿਸਦਾ ਵੱਡਾ ਪ੍ਰਭਾਵ ਹੋਇਆ: ਵੱਡੀ ਡਾਟਾ ਨੌਕਰੀ ਨੂੰ ਬਹੁਤ ਸਾਰੇ ਛੋਟੇ ਟਾਸਕਾਂ ("map") ਵਿੱਚ ਤੋੜੋ, ਕਲੱਸਟਰ 'ਤੇ ਇਨ੍ਹਾਂ ਨੂੰ ਪੈਰਲਲ ਚਲਾਓ, ਫਿਰ ਹਿੱਸਿਆਂ ਨੂੰ ਜੋੜੋ ("reduce"). ਜੇ ਤੁਸੀਂ ਕਦੇ ਲੱਖਾਂ ਦਸਤਾਵੇਜ਼ਾਂ ਵਿੱਚ ਸ਼ਬਦ ਗਿਣੇ ਹਨ, ਲਾਗਜ਼ ਨੂੰ ਯੂਜ਼ਰ ਦੁਆਰਾ ਗਰੁੱਪ ਕੀਤਾ ਹੈ, ਜਾਂ ਸਰਚ ਇੰਡੈਕਸ ਬਣਾਏ ਹਨ, ਤਾਂ ਤੁਸੀਂ ਮਾਨਸਿਕ ਰੂਪ ਵਿੱਚ MapReduce ਕਰ ਚੁੱਕੇ ਹੋ—ਸਿਰਫ਼ Google ਦੇ ਪੈਮਾਨੇ ਤੇ ਨਹੀਂ।
MapReduce ਤੋਂ ਪਹਿਲਾਂ, ਇੰਟਰਨੇਟ-ਸਕੇਲ ਡੈਟਾਸੈੱਟ ਪ੍ਰੋਸੈਸਿੰਗ ਅਕਸਰ ਕਸਟਮ ਵੰਡੇ ਕੋਡ ਮੰਗਦੀ ਸੀ। ਉਹ ਕੋਡ ਲਿਖਣਾ ਮੁਸ਼ਕਲ, ਚਲਾਉਣਾ ਨਾਜ਼ੁਕ ਅਤੇ ਆਸਾਨੀ ਨਾਲ ਗਲਤ ਹੋ ਜਾਂਦਾ ਸੀ।
MapReduce ਨੇ ਇਕ ਮਹੱਤਵਪੂਰਨ ਗੱਲ ਮੰਨੀ: ਮਸ਼ੀਨਾਂ ਫੇਲ ਹੋਣਗੀਆਂ, ਡਿਸਕ ਮਰ ਜਾਏਂਗੇ, ਨੈੱਟਵਰਕ ਹਿੱਚਅਪ ਹੋਣਗਾ। ਸਿਸਟਮ ਨੇ ਫੇਲਿਅਰਾਂ ਨੂੰ ਵਿਰਲੇ ਅਪਵਾਦ ਸਮਝਣ ਦੀ ਬਜਾਏ ਰੋਜ਼ਾਨਾ ਘਟਨਾ ਮੰਨਿਆ। ਟਾਸਕਾਂ ਨੂੰ ਆਟੋਮੈਟਿਕ ਰੀ-ਰਨ ਕੀਤਾ ਜਾ ਸਕਦਾ ਸੀ, ਵਿਚਕਾਰਲੇ ਨਤੀਜੇ ਮੁੜ-ਪੈਦਾ ਕੀਤੇ ਜਾ ਸਕਦੇ ਸਨ, ਅਤੇ ਕੁੱਲਜੋਬ ਮਨੁੱਖੀ ਨਿਗਰਾਨੀ ਦੇ ਬਿਨਾਂ ਖਤਮ ਹੋ ਸਕਦਾ ਸੀ।
ਇਹ ਫੇਲਿਅਰ-ਪਹਿਲਾਂ ਮਨੋਦਸ਼ਾ ਬਾਅਦ ਵਿੱਚ AI ਲਈ ਮਹੱਤਵਪੂਰਨ ਸੀ, ਕਿਉਂਕਿ ਵੱਡੀਆਂ ਟਰੇਨਿੰਗ ਪਾਈਪਲਾਈਨਾਂ ਉਹੀ ਸਮੱਗਰੀ—ਵੱਡੇ ਡੈਟਾਸੈੱਟ, ਕਈ ਮਸ਼ੀਨ, ਅਤੇ ਲੰਬੇ ਚੱਲਣ ਵਾਲੀਆਂ ਨੌਕਰੀਆਂ—ਤੇ ਆਧਾਰਿਤ ਹੁੰਦੀਆਂ ਹਨ।
MapReduce ਸਿਰਫ਼ ਗਣਨਾ ਤੇਜ਼ ਨਹੀਂ ਕੀਤਾ; ਇਸਨੇ ਉਸ ਨੂੰ ਮਿਆਰੀ ਬਣਾਇਆ।
ਟੀਮਾਂ ਡਾਟਾ ਪ੍ਰੋਸੈਸਿੰਗ ਨੂੰ ਇੱਕ ਦੁਹਰਾਏ ਜਾਣਯੋਗ ਨੌਕਰੀ ਵਜੋਂ ਵਿਅਕਤ ਕਰ ਸਕਦੀਆਂ, ਸਾਂਝੇ ਇਨਫਰਾਸਟਰੱਕਚਰ 'ਤੇ ਚਲਾ ਸਕਦੀਆਂ ਅਤੇ ਅਨੁਮਾਨ ਕੀਤੀ ਵਰਤੋਂ ਦੀ ਉਮੀਦ ਕਰ ਸਕਦੀਆਂ। ਹਰ ਗਰੁੱਪ ਨੂੰ ਆਪਣੀਆਂ ਕਲੱਸਟਰ ਸਕਰਿਪਟਾਂ, ਮਾਨੀਟਰਿੰਗ ਅਤੇ ਰੀਟ੍ਰਾਈ ਲਾਜਿਕ ਬਣਾਉਣ ਦੀ ਜਗ੍ਹਾ ਉਹ ਇੱਕ ਆਮ ਪਲੇਟਫਾਰਮ ਤੇ ਨਿਰਭਰ ਰਹਿੰਦੇ। ਇਹ ਪ੍ਰਯੋਗ ਨੂੰ ਤੇਜ਼ ਕਰਦਾ (ਨੌਕਰੀ ਨੂੰ ਵੱਖ-ਵੱਖ ਫਿਲਟਰ ਨਾਲ ਮੁੜ ਚਲਾਉਣਾ ਆਸਾਨ), ਨਤੀਜਿਆਂ ਨੂੰ ਦੁਹਰਾਉਣਾ ਆਸਾਨ ਬਣਾਉਂਦਾ, ਅਤੇ "ਹੀਰੋ ਇੰਜੀਨੀਅਰ" ਫੈਕਟਰ ਘਟਾਉਂਦਾ।
ਇਸ ਨਾਲ ਡਾਟਾ ਇੱਕ ਉਤਪਾਦ ਬਣ ਗਿਆ: ਜਦੋਂ ਪਾਈਪਲਾਈਨ ਭਰੋਸੇਯੋਗ ਹੋ ਗਏ, ਤੁਸੀਂ ਉਹਨਾਂ ਨੂੰ ਸ਼ੈਡਿਊਲ ਕਰ ਸਕਦੇ, ਵਰਜ਼ਨ ਕਰ ਸਕਦੇ, ਅਤੇ ਡਾਊਨਸਟ੍ਰੀਮ ਸਿਸਟਮਾਂ ਨੂੰ ਨਿਰਭਰਤਾਪੂਰਵਕ ਹਵਾਲਾ ਕਰ ਸਕਦੇ।
ਕਈ sangਠਨ ਹੁਣ Spark, Flink, Beam ਜਾਂ ਕਲਾਉਡ-ਨੈਟਿਵ ETL ਟੂਲ ਵਰਤਦੇ ਹਨ। ਉਹ ਹੋਰ ਲਚਕੀਲੇ ਹਨ (ਸਟਰੀਮਿੰਗ, ਇੰਟਰਐਕਟਿਵ ਕ੍ਵੈਰੀ), ਪਰ MapReduce ਦੇ ਕੋਰ ਪਾਠ ਅਜੇ ਵੀ ਲਾਗੂ ਹੁੰਦੇ ਹਨ: ਪੈਰਲਲਿਜ਼ਮ ਨੂੰ ਡਿਫੌਲਟ ਬਣਾਓ, ਰੀਟ੍ਰਾਈ ਲਈ ਡਿਜ਼ਾਈਨ ਕਰੋ, ਅਤੇ ਸਾਂਝੇ ਪਾਈਪਲਾਈਨ ਟੂਲੀੰਗ 'ਚ ਨਿਵੇਸ਼ ਕਰੋ ਤਾਂ ਕਿ ਟੀਮਾਂ ਡੈਟਾ ਗੁਣਵੱਤਾ ਅਤੇ ਮਾਡਲਿੰਗ 'ਤੇ ਸਮਾਂ ਖਰਚ ਕਰਨ—ਕਲੱਸਟਰ ਸਰਵਾਈਵਲ 'ਤੇ ਨਹੀਂ।
ਮਸ਼ੀਨ ਲਰਨਿੰਗ ਦੀ ਪ੍ਰਗਟੀ ਕੇਵਲ ਵਧੀਆ ਮਾਡਲਾਂ ਬਾਰੇ ਨਹੀਂ—ਇਹ ਸਹੀ ਡਾਟਾ ਨੂੰ ਸਹੀ ਨੌਕਰੀਆਂ ਨੂੰ ਸਥਿਰ ਤਰੀਕੇ ਨਾਲ ਪਹੁੰਚਾਉਣ ਬਾਰੇ ਵੀ ਹੈ। Google ਵਿੱਚ, Dean ਨੇ ਜੋ ਸਿਸਟਮ-ਮਾਈੰਡਸੈਟ ਜ਼ੋਰ ਦਿੱਤਾ ਉਹ ਸਟੋਰੇਜ ਨੂੰ "ਬੈਕਐਂਡ ਪਲੰਬਿੰਗ" ਤੋਂ ML ਅਤੇ ਐਨੈਲਿਟਿਕਸ ਕਹਾਣੀ ਦਾ ਪਹਿਲਾ-ਕਲਾਸ ਹਿੱਸਾ ਬਣਾ ਦਿੱਤਾ। Bigtable ਇਕ ਮੁੱਖ ਬਿਲਡਿੰਗ ਬਲਾਕ ਬਣਿਆ: ਇੱਕ ਸਟੋਰੇਜ ਸਿਸਟਮ ਜੋ ਵੱਡੀ throughput, ਅਨੁਮਾਨਿਤ ਲੇਟੈਂਸੀ, ਅਤੇ ਆਪਰੇਸ਼ਨਲ ਕੰਟਰੋਲ ਲਈ ਡਿਜ਼ਾਈਨ ਕੀਤਾ ਗਿਆ ਸੀ।
Bigtable ਇੱਕ wide-column store ਹੈ: ਰੋਜ਼ ਅਤੇ ਇੱਕ ਨਿਸ਼ਚਿਤ ਕਾਲਮ ਸੈੱਟ ਦੀ ਸੋਚ ਦੀ ਬਜਾਏ, ਤੁਸੀਂ ਸਪਾਰਸ, ਵਿਕਸਿਤ ਹੋਣ ਵਾਲਾ ਡਾਟਾ ਰੱਖ ਸਕਦੇ ਹੋ ਜਿਸ ਵਿੱਚ ਵੱਖ-ਵੱਖ ਰੋਜ਼ ਵੱਖ-ਵੱਖ "ਆਕਾਰ" ਹੋ ਸਕਦੇ ਹਨ। ਡਾਟਾ tablets (ਖੇਤਰਾਂ ਵੱਲੋਂ ਰੋਜ਼) ਵਿੱਚ ਵੰਡਿਆ ਜਾਂਦਾ ਹੈ, ਜੋ ਲੋਡ ਬੈਲੈਂਸ ਕਰਨ ਲਈ ਸਰਵਰਾਂ 'ਤੇ ਹਿਲ ਸਕਦੇ ਹਨ।
ਇਹ ਢਾਂਚਾ ਆਮ ਵੱਡੇ-ਪੈਮਾਨੇ ਐਕਸੈਸ ਪੈਟਰਨਾਂ ਲਈ ਫਿੱਟ ਹੋਦਾ ਹੈ:
ਸਟੋਰੇਜ ਡਿਜ਼ਾਈਨ ਆਹਿਸਤਿਆਂ ਪ੍ਰਭਾਵ ਪਾਉਂਦਾ ਹੈ ਕਿ ਟੀਮਾਂ ਕਿਹੜੇ ਫੀਚਰ ਬਣਾਉਂਦੀਆਂ ਹਨ ਅਤੇ ਕਿੰਨੀ ਭਰੋਸੇਯੋਗ ਤਰੀਕੇ ਨਾਲ ਉਹ ਟਰੇਨ ਹੋ ਸਕਦੇ ਹਨ।
ਜੇ ਤੁਹਾਡਾ ਸਟੋਰ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਰੇਂਜ ਸਕੈਨ ਅਤੇ ਵਰਜ਼ਨਡ ਡਾਟਾ ਸਹਾਇਕ ਕਰਦਾ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਕਿਸੇ ਖਾਸ ਸਮੇਂ ਵਿੰਡੋ ਲਈ ਟਰੇਨਿੰਗ ਸੈਟ ਮੁੜ-ਬਣਾਉ ਸਕਦੇ ਹੋ ਜਾਂ ਪਿਛਲੇ ਮਹੀਨੇ ਤੋਂ ਕਿਸੇ ਪ੍ਰਯੋਗ ਨੂੰ ਦੁਹਰਾਉਂ ਸਕਦੇ ਹੋ। ਜੇ ਪੜ੍ਹਾਈਆਂ ਧੀਮੀਆਂ ਜਾਂ ਅਸੰਗਤ ਹਨ, ਤਾਂ ਫੀਚਰ ਜੈਨਰੇਸ਼ਨ ਨਾਜ਼ੁਕ ਹੋ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਟੀਮਾਂ "ਸਮਪਲ ਕਰਕੇ" ਮੁੱਦੇ ਹੋਲੇ-ਹੋਲੇ ਘੱਲਦੀਆਂ—ਜੋ ਪੱਖਪਾਤ ਅਤੇ ਡੀਬੱਗ ਕਰਨ ਲਈ ਕਠਿਨਾਈ ਪੈਦਾ ਕਰਦਾ ਹੈ।
Bigtable-ਸਟਾਈਲ ਐਕਸੈਸ ਵੀ ਇੱਕ ਪ੍ਰਾਇਗਮੈਟਿਕ ਦ੍ਰਿਸ਼ਟੀ ਨੂੰ ਉਤਸ਼ਾਹਿਤ ਕਰਦਾ: ਰਾ ਸਿਗਨਲ ਇੱਕ ਵਾਰੀ ਲਿਖੋ, ਫਿਰ ਬਿਨਾਂ ਹਰ ਚੀਜ਼ ਨੂੰ ਡੁਪਲਿਕੇਟ ਕੀਤੇ ਕਈ ਫੀਚਰ ਵਿਊਜ਼ ਨਿਕਾਲੋ।
ਸਕੇਲ 'ਤੇ, ਸਟੋਰੇਜ ਫੇਲ ਨਜ਼ਰ ਨਹੀਂ ਆਉਂਦੇ ਇਕ ਵੱਡੇ ਆਊਟੇਜ ਵਾਂਗ—ਉਹਨਾਂ ਨੂੰ ਛੋਟਾ, ਲਗਾਤਾਰ ਰਿੜਕਣਾ ਵਾਂਗ ਹੁੰਦਾ ਹੈ। Bigtable ਦੇ ਕਲਾਸਿਕ ਸਬਕ सीधे ML ਇਨਫਰਾਸਟਰੱਕਚਰ 'ਤੇ ਲਾਗੂ ਹੁੰਦੇ ਹਨ:
ਜਦੋਂ ਡਾਟਾ ਐਕਸੈਸ ਅਨੂੰਮਾਨਯੋਗ ਹੁੰਦੀ ਹੈ, ਟਰੇਨਿੰਗ ਵੀ ਅਨੂੰਮਾਨਯੋਗ ਬਣ ਜਾਂਦੀ ਹੈ—ਅਤੇ ਇਹੀ ਗੱਲ ML ਨੂੰ ਰਿਸਰਚ ਦੇ ਲਿਖੇ ਤੋਂ ਭਰੋਸੇਯੋਗ ਉਤਪਾਦ ਸਮਰੱਥਾ ਵਿੱਚ ਬਦਲ ਦਿੰਦੀ ਹੈ।
ਇੱਕ ਮਾਡਲ ਨੂੰ ਇਕ ਮਸ਼ੀਨ 'ਤੇ ਟਰੇਨ ਕਰਨਾ ਮੁਕ਼ਤਲਿਫ਼ ਰੂਪ 'ਚ "ਇਸ ਬਾਕਸ ਦੀ ਗਣਨਾ ਕਿੰਨੀ ਤੇਜ਼ ਹੋ ਸਕਦੀ ਹੈ?" ਦਾ ਸਵਾਲ ਹੈ। ਕਈ ਮਸ਼ੀਨਾਂ 'ਤੇ ਟਰੇਨਿੰਗ ਇਹ ਹੋਰ ਪੇਚੀਦਾ ਸਵਾਲ ਪੇਸ਼ ਕਰਦੀ ਹੈ: "ਅਸੀਂ ਸਕੇੜ੍ਹਾਂ ਜਾਂ ਹਜ਼ਾਰਾਂ ਵਰਕਰਾਂ ਨੂੰ ਇਕ ਜੈਵਿਕ ਟਰੇਨਿੰਗ ਦੌੜ ਵਾਂਗ ਕਿਵੇਂ ਰੱਖੀਏ?" ਇਹ ਫ਼ਰਕ ਹੈ ਕਿ ਵੰਡਿਆ ਟਰੇਨਿੰਗ ਅਕਸਰ ਵੰਡਿਆ ਡਾਟਾ ਪ੍ਰੋਸੈਸਿੰਗ ਤੋਂ ਕਿਉਂ ਜਿਆਦਾ ਮੁਸ਼ਕਲ ਹੁੰਦੀ ਹੈ।
MapReduce ਵਰਗੇ ਸਿਸਟਮਾਂ ਵਿੱਚ, ਟਾਸਕਾਂ ਨੂੰ ਰੀਟ੍ਰਾਈ ਅਤੇ ਮੁੜ-ਹਿਸਾਬ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ ਕਿਉਂਕਿ ਆਉਟਪੁੱਟ deterministic ਹੁੰਦਾ ਹੈ: ਇੱਕੋ ਇਨਪੁੱਟ ਮੁੜ ਰਨ ਕਰਨ 'ਤੇ ਇਹੋ ਨਤੀਜਾ ਮਿਲਦਾ। ਨਿਊਰਲ ਨੈੱਟਵਰਕ ਟਰੇਨਿੰਗ iterative ਅਤੇ stateful ਹੁੰਦੀ ਹੈ। ਹਰ ਕਦਮ ਸਾਂਝੇ ਪੈਰਾਮੀਟਰਾਂ ਨੂੰ ਅਪਡੇਟ ਕਰਦਾ ਹੈ, ਅਤੇ ਛੋਟੀ ਟਾਈਮਿੰਗ ਡਿੱਫਰੈਂਸ ਵੀ ਲਰਨਿੰਗ ਦੇ ਰਸਤੇ ਨੂੰ ਬਦਲ ਸਕਦੀ ਹੈ। ਤੁਸੀਂ ਸਿਰਫ਼ ਕੰਮ ਵੰਡ ਨਹੀਂ ਰਹੇ—ਤੁਸੀਂ ਇੱਕ ਹਿਲਦੇ ਲਕੜੇ ਨੂੰ ਕੋਆਰਡੀਨੇਟ ਕਰ ਰਹੇ ਹੋ।
ਕੁਝ ਮੁੱਦੇ ਜਲਦੀ ਹੀ ਉਭਰ ਕੇ ਆਉਂਦੇ ਹਨ:
Google ਦੇ ਅੰਦਰ, Jeff Dean ਨਾਲ ਸੰਬੰਧਤ ਕੰਮ DistBelief ਵਰਗੇ ਸਿਸਟਮਾਂ ਨੂੰ ਰੁਕਾਵਟ-ਯੋਗ ਰਿਸਰਚ ਆਈਡੀਯਾ ਤੋਂ ਇੱਕ ਐਸੇ ਚੀਜ਼ ਵਿੱਚ ਬਦਲਣ 'ਚ ਮਦਦ ਕਰਦਾ ਸੀ ਜੋ ਵਾਰ-ਵਾਰ, ਅਸਲੀ ਫਲੀਟਾਂ 'ਤੇ, ਅਨੁਮਾਨਯੋਗ ਨਤੀਜੇ ਦੇ ਸਕਦਾ ਸੀ। ਮੁੱਖ ਬਦਲਾਅ ਇਹ ਸੀ ਕਿ ਟਰੇਨਿੰਗ ਨੂੰ ਇੱਕ ਪ੍ਰੋਡਕਸ਼ਨ ਵਰਕਲੋਡ ਵਜੋਂ ਮਨਿਆ ਗਿਆ: ਖੁਲਾਸਾ ਫੌਲਟ ਟੋਲਰੇਂਸ, ਸਪੱਸ਼ਟ ਪ੍ਰਦਰਸ਼ਨ ਮੈਟ੍ਰਿਕਸ, ਅਤੇ ਜੌਬ ਸ਼ੈਡਿਊਲਿੰਗ ਅਤੇ ਮਾਨੀਟਰਿੰਗ 'ਤੇ ਆਟੋਮੇਸ਼ਨ।
ਜੋ ਜ਼ਿਆਦਾਤਰ ਢਾਂਚਿਆਂ ਨੂੰ ਲਾਗੂ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ, ਉਹ ਨਿਰਧਾਰਿਤ ਆਰਕੀਟੈਕਚਰ ਨਹੀਂ ਹੈ—ਇਹ ਅਨੁਸ਼ਾਸਨ ਹੈ:
ਜਿਵੇਂ Google Brain ਨੇ ਮਸ਼ੀਨ ਲਰਨਿੰਗ ਨੂੰ ਕੁਝ ਰਿਸਰਚ ਪ੍ਰੋਜੈਕਟਾਂ ਤੋਂ ਲੈ ਕੇ ਉਹ ਚੀਜ਼ ਬਣਾ ਦਿੱਤੀ ਜੋ ਕਈ ਪ੍ਰੋਡਕਟ ਟੀਮਾਂ ਚਾਹੁੰਦੀਆਂ ਸਨ, ਬੋਤਲਨੈਕ੍ਹ ਹੁਣ ਸਿਰਫ਼ ਹੋਰ ਮਾਡਲ ਨਹੀਂ ਸੀ—ਇਹ ਸਹਯੋਗ ਸੀ। ਇੱਕ ਸਾਂਝਾ ML ਪਲੇਟਫਾਰਮ friction ਘਟਾਉਂਦਾ ਹੈ ਅਤੇ ਇਕ-ਆਦੇ ਹੀ "ਹੀਰੋ ਵਰਕਫਲੋਜ਼" ਨੂੰ ਪੇਵਡ ਰੋਡਾਂ ਵਿੱਚ ਬਦਲ ਦਿੰਦਾ ਹੈ।
ਬਿਨਾਂ ਆਮ ਟੂਲਿੰਗ ਦੇ, ਹਰ ਟੀਮ ਇੱਕੋ ਮੁੱਢਲੀ ਚੀਜ਼ਾਂ ਦੁਬਾਰਾ ਬਣਾਉਂਦੀ: ਡਾਟਾ ਏਕਸਟ੍ਰੈਕਸ਼ਨ, ਟਰੇਨਿੰਗ ਸਕ੍ਰਿਪਟ, ਇਵੈਲੂਏਸ਼ਨ ਕੋਡ, ਅਤੇ ਡੈਪਲੋਏਮੈਂਟ ਗਲੂ। ਇਹ ਨਕਲ inconsistent ਗੁਣਵੱਤਾ ਪੈਦਾ ਕਰਦੀ ਅਤੇ ਟੀਮਾਂ ਵਿੱਚ ਨਤੀਜਿਆਂ ਦੀ ਤੁਲਨਾ ਮੁਸ਼ਕਲ ਕਰਦੀ। ਇੱਕ ਕੇਂਦਰੀ ਪਲੇਟਫਾਰਮ ਨਿਰਾਲਾ ਹਿੱਸਾ ਸਧਾਰਨ ਕਰਦਾ ਹੈ ਤਾਂ ਕਿ ਟੀਮਾਂ ਆਪਣਾ ਸਮਾਂ ਉਸ ਸਮੱਸਿਆ 'ਤੇ ਲਗਾ ਸਕਣ ਜੋ ਉਹ ਹੱਲ ਕਰ ਰਹੀਆਂ ਹਨ, ਨਾ ਕਿ ਵੰਡਿਆ ਟ੍ਰੇਨਿੰਗ ਜਾਂ ਡੈਪਲੋਏਮੈਂਟ ਦੁਬਾਰਾ ਸਿੱਖਣ 'ਤੇ।
ਇੱਕ ਪ੍ਰਾਇਗਮੈਟਿਕ ਸਾਂਝਾ ML ਪਲੇਟਫਾਰਮ ਆਮ ਤੌਰ 'ਤੇ ਸ਼ਾਮਿਲ ਕਰਦਾ ਹੈ:
ਪਲੇਟਫਾਰਮ ਕੰਮ ਪ੍ਰਯੋਗਾਂ ਨੂੰ ਦੁਹਰਾਯੋਗ ਬਣਾਉਂਦਾ ਹੈ: configuration-driven ਦੌੜ, ਕੋਡ/ਡਾਟਾ/ਕੰਫ਼ਿਗ ਲਈ ਵਰਜ਼ਨਿੰਗ, ਅਤੇ ਐਕਸਪੇਰੀਮੈਂਟ ਟ੍ਰੈਕਿੰਗ ਜੋ ਦਰਜ਼ ਕਰਦੀ ਕਿ ਕੀ ਬਦਲਿਆ ਅਤੇ ਕਿਸ ਲਈ ਮਾਡਲ ਸੁਧਰਿਆ। ਇਹ ਨਵੇਂ ਆਰਕੀਟੈਕਚਰ ਇਜਾਦ ਕਰਨ ਨਾਲ ਘਟੀਆ ਨਹੀਂ—ਪਰ ਇਹ ਰੋਕਦਾ ਹੈ "ਅਸੀਂ ਪਿਛਲੇ ਹਫ਼ਤੇ ਦੀ ਜਿੱਤ ਦੁਹਰਾਉ ਨਹੀਂ ਸਕਦੇ" ਵਰਗੀਆਂ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਆਮ ਬਣਨ ਤੋਂ।
ਚੰਗੀ ਇਨਫਰਾਸਟਰੱਕਚਰ ਮੂੜਕਿੇ ਮਾਡਲਾਂ ਨੂੰ ਆਪਣੇ-आप ਵਿਚ ਸਮਰੱਥ ਨਹੀਂ ਬਣਾਉਂਦਾ—ਪਰ ਇਹ ਫਲੋਰ ਉੱਠਾ ਦਿੰਦਾ ਹੈ। ਸਾਫ਼ ਡਾਟਾ, ਲਗੀਧਾਰ ਫੀਚਰ, ਭਰੋਸੇਯੋਗ ਇਵੈਲੂਏਸ਼ਨ, ਅਤੇ ਸੁਰੱਖਿਅਤ ਡੈਪਲੋਏਮੈਂਟ ਛੁਪੇ ਹੋਏ ਗਲਤੀਆਂ ਨੂੰ ਘਟਾਉਂਦੇ ਹਨ। ਸਮੇਂ ਦੇ ਨਾਲ, ਇਸਦਾ ਨਤੀਜਾ ਹੈ ਕਿ ਘੱਟ ਝੂਠੀਆਂ ਜਿੱਤਾਂ, ਤੇਜ਼ੀ ਨਾਲ ਇਟਰੇਸ਼ਨ, ਅਤੇ ਪ੍ਰੋਡਕਸ਼ਨ ਵਿਚ ਮਾਡੇਲਸ ਜ਼ਿਆਦਾ ਭਰੋਸੇਯੋਗ ਹੋ ਜਾਂਦੇ ਹਨ।
ਜੇ ਤੁਸੀਂ ਛੋਟੀ ਸੰਗਠਨ ਵਿਚ ਇਹ "ਪੇਵਡ ਰੋਡ" ਬਣਾਉਣੀ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ ਮੁੱਖ ਗੱਲ ਉਹੀ ਹੈ: ਕੋਆਰਡੀਨੇਸ਼ਨ ਲਾਗਤ ਘਟਾਓ। ਇੱਕ ਪ੍ਰਯੋਗਿਕ ਤਰੀਕਾ ਹੈ: ਐਪਸ, ਸਰਵਿਸਜ਼ ਅਤੇ ਡਾਟਾ-ਬੈਕਡ ਵਰਕਫਲੋਜ਼ ਬਣਾਉਣ ਦਾ ਇੱਕ ਮਿਆਰੀ ਤਰੀਕਾ ਨਿਰਧਾਰਤ ਕਰਨਾ। ਉਦਾਹਰਣ ਲਈ, Koder.ai ਇੱਕ vibe-coding ਪਲੇਟਫਾਰਮ ਹੈ ਜੋ ਟੀਮਾਂ ਨੂੰ chat ਦੁਆਰਾ web, backend, ਅਤੇ mobile applications ਬਣਾਉਣ ਦਿੰਦਾ (React ਵੈੱਬ 'ਤੇ, Go + PostgreSQL ਬੈਕਐਂਡ, Flutter ਮੋਬਾਈਲ)। ਸੋਚ-ਸਮਝ ਕੇ ਵਰਤਿਆ ਗਿਆ, ਇਸ ਤਰ੍ਹਾਂ ਦੇ ਟੂਲ ML ਸਿਸਟਮਾਂ ਦੇ ਆਸਪਾਸ ਦਾ scaffolding ਤੇਜ਼ ਕਰ ਸਕਦੇ ਹਨ—admin consoles, ਡਾਟਾ ਰੀਵਿਊ ਐਪਸ, ਐਕਸਪੇਰੀਮੈਂਟ ਡੈਸ਼ਬੋਰਡ, ਜਾਂ ਸਰਵਿਸ ਰੈਪਪਰ—ਜਦੋਂ ਲੋੜ ਹੋਵੇ ਤਾਂ source-code export, deployment, ਅਤੇ rollback ਦੀ ਸਹੂਲਤ ਰੱਖਦੇ ਹੋਏ।
TensorFlow ਇਕ ਲਾਜ਼ਮੀ ਉਦਾਹਰਣ ਹੈ ਕਿ ਜਦੋਂ ਕੰਪਨੀ ਮਸ਼ੀਨ ਲਰਨਿੰਗ ਕੋਡ ਨੂੰ ਇੱਕ-ਆਫ਼ ਰਿਸਰਚ ਪ੍ਰੋਜੈਕਟਾਂ ਵਜੋਂ ਦੇਖਣਾ ਛੱਡ ਦਿੰਦੀ ਅਤੇ ਇਸਨੂੰ ਇਨਫਰਾਸਟਰੱਕਚਰ ਵਾਂਗ ਪੈਕੇਜ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰ ਦਿੰਦੀ ਤਾਂ ਕੀ ਹੁੰਦਾ ਹੈ। ਹਰ ਟੀਮ ਆਪਣਾ ਡਾਟਾ ਪਾਈਪਲਾਈਨ, ਟਰੇਨਿੰਗ ਲੂਪ ਅਤੇ ਡੈਪਲੋਏਮੈਂਟ ਗਲੂ ਦੁਬਾਰਾ ਨਿਰਮਾਣ ਕਰਨ ਦੀ ਜਗ੍ਹਾ ਇੱਕ ਸਾਂਝੇ ਫਰੇਮਵਰਕ ਨਾਲ "ਡਿਫੌਲਟ ਤਰੀਕਾ" ਤੇਜ਼, ਸੁਰੱਖਿਅਤ, ਅਤੇ ਰੱਖ-ਰਖਾਅਵਾਂ ਯੋਗ ਬਣ ਸਕਦਾ ਹੈ।
Google ਦੇ ਅੰਦਰ, ਚੁਣੌਤੀ ਸਿਰਫ਼ ਵੱਡੇ ਮਾਡਲ ਟਰੇਨ ਕਰਨ ਦੀ ਨਹੀਂ ਸੀ—ਇਹ ਇਹ ਵੀ ਸੀ ਕਿ ਕਈ ਟੀਮਾਂ ਇਕਸਾਰਤਾ ਨਾਲ ਟਰੇਨ ਅਤੇ ਸ਼ਿਪ ਕਰਨ। TensorFlow ਨੇ ਕੁਝ ਅੰਦਰੂਨੀ ਪ੍ਰਥਾਵਾਂ ਨੂੰ ਇਕ ਦੁਹਰਾਏ ਜਾਣਯੋਗ ਵਰਕਫਲੋ ਵਿੱਚ ਬਦਲਿਆ: ਇੱਕ ਮਾਡਲ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ, ਵੱਖ-ਵੱਖ ਹਾਰਡਵੇਅਰ 'ਤੇ ਚਲਾਓ, ਲੋੜ ਹੋਣ 'ਤੇ ਟਰੇਨਿੰਗ ਵੰਡੋ, ਅਤੇ ਇਸਨੂੰ ਪ੍ਰੋਡਕਸ਼ਨ ਸਿਸਟਮਾਂ ਨੂੰ ਐਕਸਪੋਰਟ ਕਰੋ।
ਇਸ ਤਰ੍ਹਾਂ ਦਾ ਪੈਕੇਜਿੰਗ coordination ਦੀ ਲਾਗਤ ਘਟਾਉਂਦਾ ਹੈ। ਜਦੋਂ ਟੀਮਾਂ ਇਕੋ ਹੀ ਪ੍ਰਿਮਿਟਿਵਜ਼ ਸਾਂਝੀਆਂ ਕਰਦੀਆਂ ਹਨ, ਤਾਂ bespoke ਟੂਲਾਂ, ਛੁਪੇ ਧਾਰਣਾਵਾਂ ਅਤੇ ਘੱਟ-ਫੇਰਬਦਲ ਘਟ ਜਾਂਦੇ ਹਨ—ਜੋ ਮੁਲਕੀ ਬੇਹਤਰੀ ਲਈ ਜ਼ਰੂਰੀ ਹੈ।
ਸ਼ੁਰੂਆਤੀ TensorFlow ਨੇ computation graphs 'ਤੇ ਭਰੋਸਾ ਕੀਤਾ: ਤੁਸੀਂ ਜਿਸਨੂੰ ਗਣਨਾ ਕਰਨੀ ਹੈ ਉਹ ਵੇਰਵਾ ਦਿੰਦੇ ਹੋ, ਅਤੇ ਸਿਸਟਮ ਇਹ ਫੈਸਲਾ ਕਰਦਾ ਕਿ ਇਸਨੂੰ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਢੰਗ ਨਾਲ ਕਿਵੇਂ ਚਲਾਉਣਾ ਹੈ। ਇਹ ਵਿੱਛੋੜਾ CPUs, GPUs, ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਖਾਸ ਐਕਸੀਲੇਰੇਟਰਾਂ 'ਤੇ ਨਿਰਦੇਸ਼ਿਤ ਕਰਨਾ ਆਸਾਨ ਬਣਾਉਂਦਾ ਸੀ ਬਿਨਾਂ ਹਰ ਮਾਡਲ ਨੂੰ ਮੁੜ ਲਿਖੇ।
ਪੋਰਟਬਿਲਟੀ ਇੱਥੇ ਇਕ ਚੁਪੜੀ ਸੁਪਰਪਾਵਰ ਹੈ। ਇੱਕ ਮਾਡਲ ਜੋ ਵਾਤਾਵਰਨਾਂ ਵਿਚ ਹਿਲ ਸਕਦਾ ਹੈ—ਨੋਟਬੁੱਕ → ਵੱਡੇ ਟਰੇਨਿੰਗ ਕਲੱਸਟਰ → ਪ੍ਰੋਡਕਸ਼ਨ ਸਰਵਿਸ—ਟੀਮਾਂ ਨੂੰ "ਇੱਥੇ ਚੱਲਦਾ ਹੈ, ਉੱਥੇ ਟੁੱਟਦਾ ਹੈ" ਟੈਕਸ ਨੂੰ ਘਟਾਉਂਦਾ ਹੈ।
ਅੱਤੇ ਬਾਹਰ ਦੀਆਂ ਚੀਜ਼ਾਂ open-tooling ਮਾਈਂਡਸੈਟ ਨੂੰ ਅਪਣਾਉਣਾ ਮਦਦ ਕਰਦਾ ਹੈ: ਸਪੱਸ਼ਟ APIs, ਸਾਂਝੇ ਰਵਾਇਤਾਂ, ਅਨੁਕੂਲਤਾ ਗੈਰੰਟੀਜ਼, ਅਤੇ ਨਵੀਂ ਯੂਜ਼ਰ ਲਈ ਦਸਤਾਵੇਜ਼। ਮਿਆਰੀਕਰਨ velocity ਵਧਾਉਂਦੀ ਹੈ ਕਿਉਂਕਿ ਓਨਬੋਰਡਿੰਗ ਸੁਧਰਦੀ ਅਤੇ ਡੀਬੱਗਿੰਗ ਜ਼ਿਆਦਾ ਅਨੁਮਾਨਯੋਗ ਹੁੰਦੀ ਹੈ।
ਕੌਣ "ਪਹਿਲਾਂ" ਸੀ ਇਸ ਬਾਰੇ ਵੱਧ-ਚੜ੍ਹ ਕੇ ਦਾਅਵਾ ਕਰਨਾ ਆਸਾਨ ਹੈ। ਜੋ ਲਾਗੂ ਕਰਨਯੋਗ ਸਬਕ ਹੈ ਉਹ ਨਵੀਨਤਾ ਨਹੀਂ—ਪਰ ਪ੍ਰਭਾਵ ਹੈ: ਕੁਝ ਮੁੱਖ ਅਬਸਟ੍ਰੈਕਸ਼ਨਾਂ ਚੁਣੋ, ਉਨਾਂ ਨੂੰ ਵਿਆਪਕ ਵਰਤੋਂ ਯੋਗ ਬਣਾਓ, ਅਤੇ ਮਿਆਰੀ ਰਸਤੇ ਨੂੰ ਆਸਾਨ ਬਣਾਉ।
ਡਿਪ ਲਰਨਿੰਗ ਨੇ ਸਿਰਫ਼ "ਵਧੇਰੇ ਸਰਵਰ" ਨਹੀਂ ਮੰਗੇ। ਇਸਨੇ ਇੱਕ ਵੱਖ-ਵੱਖ ਕਿਸਮ ਦੀ ਖ਼ਸੂਸੀ ਕਮਪਿਊਟਰ ਦੀ ਮੰਗ ਕੀਤੀ। ਜਿਵੇਂ ਮਾਡਲ ਅਤੇ ਡੈਟਾਸੈੱਟ ਵਧੇ, ਜਨਰਲ-ਪਰਪਜ਼ CPU ਬੋਤਲਨੈੱਕ ਬਣ ਗਏ—ਲਚੀਲਾਪਣ ਲਈ ਵਧੀਆ, ਨਰਿੱਧਰ ਗਣਿਤ ਲਈ ਅਪਰਯਾਪਤ।
GPUs ਨੇ ਸਾਬਤ ਕੀਤਾ ਕਿ massively parallel ਚਿਪਾਂ ਇੱਕ ਦਿੱਠੇ ਡਾਲਰ ਪ੍ਰਤੀ ਮਾਡਲ ਟਰੇਨਿੰਗ ਨੂੰ CPUs ਤੋਂ ਕਾਫੀ ਤੇਜ਼ ਬਣਾ ਸਕਦੀਆਂ ਹਨ। ਵੱਡਾ ਬਦਲਾਅ ਸੱਭਿਆਚਾਰਕ ਸੀ: ਟਰੇਨਿੰਗ ਹੁਣ ਕੁਝ ਐਸਾ ਬਣ ਗਿਆ ਜਿਸ ਲਈ ਤੁਸੀਂ "ਇੰਜੀਨੀਅਰਿੰਗ" ਕਰਦੇ ਹੋ (ਮੇਮੋਰੀ ਬੈਂਡਵਿਡਥ, ਬੈਚ ਸਾਈਜ਼, ਪੈਰਲਲਿਜ਼ਮ ਰਣਨੀਤੀਆਂ), ਨਾ ਕਿ ਸਰਲ ਤੌਰ 'ਤੇ ਕੁਝ ਚਲਾ ਕੇ ਉਡੀਕ ਕਰਨ ਦੀ ਚੀਜ਼।
TPUs ਨੇ ਇਸ ਵਿਚਾਰ ਨੂੰ ਅੱਗੇ ਵਧਾਇਆ, ਹਾਰਡਵੇਅਰ ਨੂੰ ਆਮ ML ਡੀਓਪਰੇਸ਼ਨਾਂ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਅਪਟਾਈਮਾਈਜ਼ ਕਰਕੇ। ਨਤੀਜਾ ਸਿਰਫ਼ ਤੇਜ਼ੀ ਨਹੀਂ—ਪੇਸ਼ਗੋਈ ਵੀ ਸੀ। ਜਦੋਂ ਟਰੇਨਿੰਗ ਦਾ ਸਮਾਂ ਹਫ਼ਤਿਆਂ ਤੋਂ ਦਿਨਾਂ (ਜਾਂ ਘੰਟਿਆਂ) ਵਿੱਚ ਘਟਦਾ ਹੈ, ਤਾਂ ਇਟਰੇਸ਼ਨ ਲੂਪ ਤੰਗ ਹੋ ਜਾਂਦੇ ਹਨ ਅਤੇ ਰਿਸਰਚ ਪ੍ਰੋਡਕਸ਼ਨ ਵਾਂਗ ਲੱਗਣ ਲੱਗਦੀ ਹੈ।
ਖਾਸ ਹਾਰਡਵੇਅਰ ਸਿਰਫ਼ ਤਦ ਕੰਮ ਕਰਦਾ ਹੈ ਜਦੋਂ ਸਾਫਟਵੇਅਰ ਸਟੈਕ ਉਸਨੂੰ ਭਰਪੂਰ ਰੱਖ ਸਕੇ। ਇਸ ਲਈ ਕੰਪਾਇਲਰ, ਕਨਰਲ्स, ਅਤੇ ਸ਼ੈਡਿਊਲਿੰਗ ਮਹੱਤਵਪੂਰਨ ਹਨ:
ਇੱਕ ਹੋਰ ਸ਼ਬਦ ਵਿੱਚ: ਮਾਡਲ, ਰਨਟਾਈਮ, ਅਤੇ ਚਿਪ ਇੱਕ ਹੀ ਪ੍ਰਦਰਸ਼ਨ ਕਹਾਣੀ ਹਨ।
ਸਕੇਲ 'ਤੇ, ਸਵਾਲ throughput per watt ਅਤੇ utilization per accelerator-hour ਬਣ ਜਾਂਦਾ ਹੈ। ਟੀਮਾਂ ਜੋਬਾਂ ਨੂੰ ਸਹੀ ਆਕਾਰ 'ਚ ਰੱਖਣ, ਵਰਕਲੋਡ ਪੈਕ ਕਰਨ, ਅਤੇ ਉਹੀ ਗੁਣਵੱਤਾ ਹਾਸਲ ਕਰਨ ਲਈ precision/parallelism ਸੈਟਿੰਗਜ਼ ਚੁਣਨ ਲੱਗਦੀਆਂ ਹਨ ਜੋ ਸਮਰੱਥਾ ਬਰਬਾਦ ਨਾ ਕਰਨ।
ਇੱਕ ਐਕਸੀਲੇਰੇਟਰ ਫਲੀਟ ਚਲਾਉਣਾ ਵੀ ਸਮਰੱਥਾ ਯੋਜਨਾ ਅਤੇ ਭਰੋਸਾਯੋਗਤਾ ਇੰਜੀਨੀਅਰਿੰਗ ਮੰਗਦਾ ਹੈ: ਦੁਰਲਭ ਡਿਵਾਈਸਾਂ ਦਾ ਪ੍ਰਬੰਧ, preemptions ਦਾ ਹੈਂਡਲ, ਫੇਲਿਅਰ ਮਾਨੀਟਰਿੰਗ, ਅਤੇ ਟਰੇਨਿੰਗ ਨੂੰ ਮੁੜ-ਸ਼ੁਰੂ ਕਰਨ ਦੀ ਬਜਾਏ ਨਰਿਮਤਾ ਨਾਲ ਰਿਕਵਰੀ ਲਈ ਡਿਜ਼ਾਈਨ।
Jeff Dean ਦਾ ਪ੍ਰਭਾਵ ਕੇਵਲ ਤੇਜ਼ ਕੋਡ ਲਿਖਣਾ ਨਹੀਂ ਸੀ—ਇਹ ਇਹ ਵੀ ਸੀ ਕਿ ਜਦੋਂ ਸਿਸਟਮ ਐਨਾ ਵੱਡਾ ਹੋ ਜਾਂਦਾ ਕਿ ਕਿਸੇ ਇੱਕ ਵਿਅਕਤੀ ਲਈ ਸਮੂਹ ਨੂੰ ਸਮਝਣਾ ਮੁਸ਼ਕਲ ਹੋ ਜਾਂਦਾ, ਤਦ ਟੀਮਾਂ ਕਿਵੇਂ ਫੈਸਲੇ ਲੈਂਦੀਆਂ ਹਨ, ਇਹ ਆਕਾਰ ਦੇਣਾ।
ਸਕੇਲ 'ਤੇ, ਆਰਕੀਟੈਕਚਰ ਇੱਕ ਡਾਇਗ੍ਰਾਮ ਦੁਆਰਾ ਨਿਰਧਾਰਿਤ ਨਹੀਂ ਹੁੰਦੀ; ਇਹ ਉਹਨਾਂ ਸਿਧਾਂਤਾਂ ਦੁਆਰਾ ਰਚੀ ਜਾਂਦੀ ਹੈ ਜੋ ਡਿਜ਼ਾਈਨ ਰੀਵਿਊਜ਼ ਅਤੇ ਰੋਜ਼ਾਨਾ ਫੈਸਲਿਆਂ 'ਚ ਦਰਸਦੇ ਹਨ। ਆਗੂ ਜੋ ਲਗਾਤਾਰ ਕੁਝ ਟਰੇਡ-ਆਫਜ਼ ਨੂੰ ਇਨਾਮ ਦਿੰਦੇ—ਸਾਦਗੀ ਨੂੰ cleverness 'ਤੇ, ਸਾਫ਼ ਮਲਿਕੀਅਤ ਨੂੰ "ਸਭ ਦੀ ਮਲਿਕੀਅਤ" ਤੇ, ਭਰੋਸਾਯੋਗਤਾ ਨੂੰ ਇਕ-ਵਾਰੀ ਤੇਜ਼ੀ ਤੇ—ਚੁਪਚਾਪ ਪੂਰੇ ਆਰਗੇਨਾਈਜੇਸ਼ਨ ਲਈ ਡਿਫੌਲਟ ਆਰਕੀਟੈਕਚਰ ਸੈੱਟ ਕਰ ਦਿੰਦੇ ਹਨ।
ਮਜ਼ਬੂਤ ਰੀਵਿਊ ਸੰਸਕ੍ਰਿਤੀ ਇਸ ਦਾ ਹਿੱਸਾ ਹੈ। ਨਾ ਕਿ "ਗੋਟਚਾ" ਰੀਵਿਊਜ਼, ਪਰ ਉਹ ਰੀਵਿਊਜ਼ ਜੋ ਉਮੀਦਯੋਗ ਸਵਾਲ ਪੁੱਛਦੇ ਹਨ:
ਜਦੋਂ ਇਹ ਸਵਾਲ ਰੋਜ਼ਾਨਾ ਬਣ ਜਾਂਦੇ ਹਨ, ਟੀਮਾਂ ਅਸਾਨੀ ਨਾਲ ਓਪਰੇਟ ਕਰਨ ਯੋਗ ਅਤੇ ਵਿਕਸਤ ਕਰਨ ਯੋਗ ਸਿਸਟਮ ਬਣਾਉਂਦੀਆਂ ਹਨ।
ਇੱਕ ਆਮ ਨੇਤ੍ਰਿਤਵ ਯੋਗਤਾ ਇਹ ਹੈ ਕਿ ਦੂਜਿਆਂ ਦਾ ਸਮਾਂ ਸਭ ਤੋਂ ਕੀਮਤੀ ਸਮਾਨ ਮੰਨਿਆ ਜਾਵੇ। "ਦੂਜਿਆਂ ਲਈ ਆਸਾਨ ਬਣਾਉ" ਮੰਤ੍ਰਾ ਇੱਕ ਵਿਅਕਤੀਗਤ ਉਤਪਾਦਕਤਾ ਨੂੰ ਸੰਗਠਨਾਤਮਕ throughput ਵਿੱਚ ਬਦਲ ਦਿੰਦਾ: ਚੰਗੇ ਡਿਫੌਲਟ, ਸੁਰੱਖਿਅਤ APIs, ਸਾਫ਼ error messages, ਅਤੇ ਘੱਟ ਛੁਪੇ ਨਿਰਭਰਤਾਵਾਂ।
ਇਸੇ ਤਰੀਕੇ ਨਾਲ ਪਲੇਟਫਾਰਮ ਅੰਦਰ ਜਿੱਤਦੇ ਹਨ। ਜੇ ਪੇਵਡ ਰੋਡ ਸਚਮੁੱਚ ਸੌਖੀ ਹੈ, ਤਾਂ ਬਿਨਾਂ ਜ਼ਬਰਦਸਤੀ ਅਪਨਾਉਂਦਾ ਆਉਂਦੀ ਹੈ।
ਡਿਜ਼ਾਈਨ ਡੌਕਸ ਅਤੇ ਸਪšਟ ਇੰਟਰਫੇਸਜ਼ ਕੋਈ ਬਿਊਰੋਕ੍ਰਸੀ ਨਹੀਂ; ਉਹ ਤਰੀਕੇ ਹਨ ਜਿਨ੍ਹਾਂ ਨਾਲ ਤੁਸੀਂ ਟੀਮਾਂ ਅਤੇ ਸਮੇਂ ਦੇ ਪਾਰ ਇਰਾਦਾ ਪ੍ਰਸਾਰਤ ਕਰਦੇ ਹੋ। ਇੱਕ ਚੰਗਾ ਡੌਕ ਝਗੜੇ ਨੂੰ ਉਤਪਾਦਕ ਬਣਾਉਂਦਾ ("ਕਿਹੜੀ ਧਾਰਣਾ ਗਲਤ ਹੈ?") ਅਤੇ ਦੁਬਾਰਾ ਕੰਮ ਨੂੰ ਘਟਾਉਂਦਾ। ਇੱਕ ਚੰਗੀ ਇੰਟਰਫੇਸ ਸਰਹੱਦ ਖਿੱਚਦੀ ਹੈ ਜੋ ਕਈ ਟੀਮਾਂ ਨੂੰ ਇੱਕਸਾਥ ਸ਼ਿਪ ਕਰਨ ਦੇ ਯੋਗ ਬਣਾਉਂਦੀ ਹੈ।
ਜੇ ਤੁਸੀਂ ਇੱਕ ਸਧਾਰਨ ਸ਼ੁਰੂਆਤ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ ਇਕ ਹਲਕਾ-ਫੁਲਕਾ ਟੈਂਪਲੇਟ ਸਟੈਂਡਰਡ ਕਰੋ ਅਤੇ ਪ੍ਰੋਜੈਕਟਾਂ 'ਚ ਇਸਨੂੰ ਇਕਸਾਰ ਰੱਖੋ (ਵੇਖੋ /blog/design-doc-template)।
ਲੋਕਾਂ ਨੂੰ ਸਕੇਲ ਕਰਨ ਦਾ ਮਤਲਬ judgment ਲਈ ਭਰਤੀ ਕਰਨਾ ਹੈ, ਨਾ ਸਿਰਫ਼ ਤਕਨੀਕੀ trivia ਲਈ, ਅਤੇ operational maturity ਲਈ mentorship: ਦਬਾਅ ਹੇਠਾਂ ਡੀਬੱਗ ਕਰਨਾ, ਸਿਸਟਮ ਨੂੰ ਸੁਰੱਖਿਅਤ ਢੰਗ ਨਾਲ ਸਧਾਰਨ ਕਰਨਾ, ਅਤੇ ਜੋਖਮ ਨੂੰ ਸੰਚਾਰਿਤ ਕਰਨਾ। ਲਕੜ ਇਹ ਹੈ ਕਿ ਇੱਕ ਟੀਮ ਤਨਾਵ-ਰਹਿਤ ਤਰੀਕੇ ਨਾਲ ਅਹੰਕਾਰਕ ਢੰਗ ਨਾਲ ਅਮਲ ਕਰ ਸਕੇ—ਕਿਉਂਕਿ ਸ਼ਾਂਤ ਟੀਮਾਂ ਘੱਟ ਅਣਉਲਟਣਯੋਗ ਗਲਤੀਆਂ ਕਰਦੀਆਂ ਹਨ।
Jeff Dean ਦੀ ਕਹਾਣੀ ਅਕਸਰ "10x engineer" ਹੀਰੋ ਨੈਰੇਟਿਵ ਵਿੱਚ ਸਧਾਰਨ ਕਰ ਦਿੱਤੀ ਜਾਂਦੀ ਹੈ: ਇਕ ਵਿਅਕਤੀ ਜੋ ਸਾਰੇ ਲੋਕਾਂ ਤੋਂ ਤੇਜ਼ ਟਾਈਪ ਕਰਦਾ ਹੈ ਅਤੇ ਇੱਕਲੇ ਹੱਥੋਂ ਸਕੇਲ ਨੂੰ ਇਜਾਦ ਕਰਦਾ ਹੈ। ਇਹ ਉਪਯੋਗੀ ਹਿੱਸਾ ਨਹੀਂ ਹੈ।
ਇੱਕ ਟ੍ਰਾਂਸਫਰ ਕਰਨਯੋਗ ਸਬਕ ਕੱਚੀ ਉਤਪਾਦਕਤਾ ਨਹੀਂ—ਇਹ leverage ਹੈ। ਸਭ ਤੋਂ ਕਦਰਯੋਗ ਕੰਮ ਉਹ ਹੁੰਦਾ ਹੈ ਜੋ ਹੋਰ ਇੰਜੀਨੀਅਰਾਂ ਨੂੰ ਤੇਜ਼ ਬਣਾਉਂਦਾ ਅਤੇ ਸਿਸਟਮਾਂ ਨੂੰ ਸੁਰੱਖਿਅਤ ਕਰਦਾ: ਸਪšਟ ਇੰਟਰਫੇਸ, ਸਾਂਝਾ ਟੂਲਿੰਗ, ਘੱਟ footguns, ਅਤੇ ਉਹ ਡਿਜ਼ਾਈਨ ਜੋ ਭਵਿੱਖੀ ਕੰਮ ਘਟਾਉਂਦੇ ਹਨ।
ਜਦੋਂ ਲੋਕ ਕਿਸੇ ਮਹਾਨ ਉਤਪਾਦਕਤਾ ਦੀ ਗੱਲ ਕਰਦੇ ਹਨ, ਉਹ ਆਮਤੌਰ 'ਤੇ ਛੁਪੇ multiplier ਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰਦੇ ਹਨ: ਸਿਸਟਮ ਨਾਲ ਗਹਿਰਾ ਪਰਿਚਯ, ਅਨੁਸ਼ਾਸਿਤ ਪ੍ਰਾਥਮਿਕਤਾ, ਅਤੇ ਇੱਕ ਪੱਖਪਾਤ ਉਹ ਤਰੱਬੀਕ ਜੁੜਤ ਜੋ ਭਵਿੱਖੀ ਕੰਮ ਨੂੰ ਘਟਾਉਂਦੀ ਹੈ।
ਕੁਝ ਆਦਤਾਂ ਉਹ ਟੀਮਾਂ ਵਿਚ ਮੁੜ-ਮੁੜ ਵੇਖਣ ਨੂੰ ਮਿਲਦੀਆਂ ਹਨ ਜੋ ਸਕੇਲ ਹੁੰਦੀਆਂ ਹਨ:
ਇਹ ਆਦਤਾਂ Google-ਪੈਮਾਨੇ ਦੀ ਇਨਫਰਾਸਟਰੱਕਚਰ ਦੀ ਲੋੜ ਨਹੀਂ ਰੱਖਦੀਆਂ; ਉਹ ਸਿਰਫ਼ ਲਗਾਤਾਰਤਾ ਮੰਗਦੀਆਂ ਹਨ।
ਹੀਰੋ ਕਹਾਣੀਆਂ ਅਕਸਰ ਅਸਲ ਕਾਰਨ ਨੂੰ ਛੁਪਾ ਦਿੰਦੀਆਂ ਹਨ ਕਿ ਚੀਜ਼ਾਂ ਕਿਵੇਂ ਕੰਮ ਕਰਦੀਆਂ: ਧੀਰਜ ਭਰੀ ਪ੍ਰਯੋਗਸ਼ਾਲਾ, ਮਜ਼ਬੂਤ ਰੀਵਿਊ ਸੰਸਕ੍ਰਿਤੀ, ਅਤੇ ਫੇਲਿਅਰ ਲਈ ਡਿਜ਼ਾਈਨ। "ਕਿਸਨੇ ਬਣਾਇਆ?" ਪੁੱਛਣ ਦੀ ਥਾਂ, ਪੁੱਛੋ:
ਤੁਹਾਨੂੰ ਕਸਟਮ ਹਾਰਡਵੇਅਰ ਜਾਂ ਗ੍ਰਹਿ-ਪੈਮਾਨੇ ਡਾਟਾ ਦੀ ਲੋੜ ਨਹੀਂ। ਇੱਕ high-leverage ਬਣਾ੍ਹ-ਬਿੰਦੂ ਚੁਣੋ—ਧੀਮੀ ਟਰੇਨਿੰਗ, ਫਲੇਕੀ ਪਾਈਪਲਾਈਨ, ਦਰਦਨਾਕ ਡੈਪਲੋਏਂਟ—ਅਤੇ ਇਕ ਛੋਟੀ ਪਲੇਟਫਾਰਮ ਸੁਧਾਰ 'ਚ ਨਿਵੇਸ਼ ਕਰੋ: ਮਿਆਰੀ ਨੌਕਰੀ ਟੈਮਪਲੇਟ, ਸਾਂਝਾ ਮੈਟ੍ਰਿਕਸ ਪੈਨਲ, ਜਾਂ ਲਾਈਟਵੇਟ "golden path" ਪ੍ਰਯੋਗ।
ਇੱਕ ਘੱਟ ਅంచਲ 'ਚ underrated accelerator ਹੈ "ਇੰਫ੍ਰਾ UI" ਦਾ ਫਰਕ ਘਟਾਉਣਾ। ਜਦੋਂ ਅੰਦਰੂਨੀ ਟੂਲ ਬਣਾਉਣਾ ਮਹਿੰਗਾ ਹੁੰਦਾ ਹੈ, ਟੀਮਾਂ ਉਹ ਬਣਾਉਣ ਤੋਂ ਪਰਹੇਜ਼ ਕਰਦੀਆਂ—ਫਿਰ ਹਮੇਸ਼ਾ ਮੈਨੁਅਲ ਓਪਰੇਸ਼ਨ ਦਾ ਭੁਗਤਾਂਦੀ ਕੀਮਤ ਚੁਕਾਉਂਦੀਆਂ। Koder.ai ਵਰਗੇ ਟੂਲ ਤੁਹਾਨੂੰ ਆਸਾਨੀ ਨਾਲ ਆਸਪਾਸ ਦਾ ਪ੍ਰੋਡਕਟ ਅਤੇ ਪਲੇਟਫਾਰਮ ਸਰਫੇਸ ਰਚਣ ਵਿੱਚ ਮਦਦ ਕਰ ਸਕਦੇ ਹਨ (ops consoles, dataset labeling apps, review workflows), snapshots/rollback ਅਤੇ deployment/hosting ਵਰਗੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਦੇ ਨਾਲ ਜੋ iterative platform engineering ਨੂੰ ਸਹਾਰਤਾ ਦਿੰਦੀਆਂ ਹਨ।
Jeff Dean ਦਾ ਕੰਮ ਇਸ ਗੱਲ ਦੀ ਯਾਦ ਦਿਵਾਉਂਦਾ ਹੈ ਕਿ "AI ਨੂੰ ਸਕੇਲ ਕਰਨਾ" ਅਧਿਕਤਰ ਦੁਹਰਾਏ ਜਾਣਯੋਗ ਇੰਜੀਨੀਅਰਿੰਗ ਬਾਰੇ ਹੈ: ਇਕ-ਵਾਰੀ ਮਾਡਲ ਜਿੱਤਾਂ ਨੂੰ ਡਾਟਾ, ਟਰੇਨਿੰਗ, ਇਵੈਲੂਏਸ਼ਨ, ਅਤੇ ਡੈਪਲੋਏਮੈਂਟ ਦੀ ਇੱਕ ਭਰੋਸੇਯੋਗ ਫੈਕਟਰੀ ਵਿੱਚ ਬਦਲਣਾ।
ਬੋਰੀਂਗ ਪਰ ਮਹੱਤਵਪੂਰਨ ਹਿੱਸਿਆਂ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ ਜੋ ਹਰ ਭਵਿੱਖੀ ਪ੍ਰੋਜੈਕਟ ਨੂੰ ਬਹਿਤਰ ਬਣਾਉਂਦੇ ਹਨ:
ਅਧਿਕਤਰ ਸਕੇਲਿੰਗ ਫੇਲਿਊਰ "ਸਾਨੂੰ ਹੋਰ GPUs ਦੀ ਲੋੜ ਹੈ" ਨਹੀਂ ਹੁੰਦੇ। ਆਮ ਰੁਕਾਵਟ ਹਨ:
ਡਾਟਾ ਕੁਆਲਟੀ ਕਰਜ਼ਾ: labels drift, definitions change, ਅਤੇ missing values ਆ ਜਾਂਦੇ ਹਨ। ਇਸਦੇ ਸੁਧਾਰ ਲਈ ਮਲਿਕੀਅਤ ਅਤੇ SLA ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ—ਹੀਰੋਇਕ ਨਹੀਂ।
ਇਵੈਲੂਏਸ਼ਨ ਗੈਪ: ਟੀਮ ਇੱਕੋ offline metric 'ਤੇ ਭਰੋਸਾ ਕਰਦੀ ਹੈ ਅਤੇ ਫਿਰ ਪ੍ਰੋਡਕਸ਼ਨ 'ਚ ਹੈਰਾਨ ਹੋ ਜਾਂਦੀ ਹੈ। slice-based reporting (region, device, customer segment) ਜੋੜੋ ਅਤੇ go/no-go thresholds ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ।
ਡੈਪਲੋਏਮੈਂਟ ਡ੍ਰਿਫਟ: ਟਰੇਨਿੰਗ ਇਕ ਫੀਚਰ ਕੈਲਕुलेਸ਼ਨ ਵਰਤਦੀ ਹੈ ਅਤੇ ਸਰਵਿੰਗ ਦੂਜੀ। ਇਹ shared feature code, end-to-end tests, ਅਤੇ reproducible builds ਨਾਲ ਸੁਲਝਦਾ ਹੈ।
ऐਸ ਇਨਫਰਾਸਟਰੱਕਚਰ ਅਤੇ ਵਰਕਫਲੋ ਸਟੈਂਡਰਡ ਚੁਣੋ ਜੋ ਕੋਆਰਡੀਨੇਸ਼ਨ ਦੀ ਲਾਗਤ ਘਟਾਉਂਦੇ ਹਨ: ਘੱਟ bespoke ਪਾਈਪਲਾਈਨ, ਘੱਟ ਛੁਪੇ ਡਾਟਾ ਧਾਰਣਾਵਾਂ, ਅਤੇ ਸਾਫ਼ promotion ਨਿਯਮ। ਇਹ ਫੈਸਲੇ ਇੱਕਠੇ ਹੋ ਕੇ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਬਣਦੇ ਹਨ—ਹਰ ਨਵਾਂ ਮਾਡਲ ਸਸਤਾ, ਸੁਰੱਖਿਅਤ ਅਤੇ ਤੇਜ਼ੀ ਨਾਲ ਸ਼ਿਪ ਹੋ ਸਕਦਾ ਹੈ।
"Scaling AI" ਦਾ ਅਰਥ ਹੈ ML ਨੂੰ ਅਸਲ ਸੀਮਾਵਾਂ ਹੇਠਾਂ ਦੋਹਰਾਯੋਗ ਅਤੇ ਭਰੋਸੇਯੋਗ ਬਣਾਉਣਾ:
ਇਹ ਇਕ ਸਿੰਗਲ ਮਾਡਲ ਨੂੰ ਟਿਊਨ ਕਰਨ ਦੀ ਬਜਾਏ ਇਕ ਅਸਰਗਰ ਫੈਕਟਰੀ ਬਣਾਉਣ ਵਾਂਗ ਹੈ."
ਕਈ ML ਆਈਡੀਯਾਜ਼ ਉਹਤੋਂ ਹੀ ਕੀਮਤੀ ਬਣਦੀਆਂ ਹਨ ਜਦੋਂ ਉਹ ਵੱਡੇ ਡਾਟਾ ਅਤੇ ਟ੍ਰੈਫਿਕ 'ਤੇ ਭਰੋਸੇਯੋਗ, ਦੋਹਰਾਏ ਜਾਣਯੋਗ ਅਤੇ ਸਸਤੀ ਤਰੀਕੇ ਨਾਲ ਚੱਲ ਸਕਦੀਆਂ ਹਨ।
ਇਸਦਾ ਅਸਰ ਅਕਸਰ "ਮਿਡਲ-ਲੇਅਰ" ਵਿੱਚ ਹੁੰਦਾ ਹੈ:
ਫਲੀਟ ਸਕੇਲ 'ਤੇ ਫੇਲਿਅਰ ਸਧਾਰਣ ਹਨ। ਆਮਤੌਰ 'ਤੇ ਪਹਿਲਾਂ ਟੁੱਟਣ ਵਾਲੀਆਂ ਚੀਜ਼ਾਂ:
ਰਿੱਕਵਰੀ ਲਈ ਡਿਜ਼ਾਈਨ (ਰੀਟ੍ਰਾਈ, ਚੈਕਪੋਇੰਟ, ਬੈਕ ਪ੍ਰੈਸ਼ਰ) ਅਕਸਰ ਸਿੰਗਲ-ਮਸ਼ੀਨ ਠੀਕ ਦਰਜੇ ਤੋਂ ਵੱਧ ਮਤਲਬ ਰੱਖਦਾ ਹੈ।
MapReduce ਨੇ ਵੱਡੇ ਬੈਚ ਪ੍ਰੋਸੈਸਿੰਗ ਨੂੰ ਮਿਆਰੀ ਅਤੇ ਜੀਵੰਤ ਬਣਾ ਦਿੱਤਾ:
ਆਧੁਨਿਕ ਟੂਲ (Spark/Flink/Beam ਅਤੇ ਕਲਾਉਡ ETL) ਫੀਚਰਾਂ 'ਚ ਵੱਖਰੇ ਹਨ, ਪਰ ਮੂਲ ਸਬਕ ਉਹੀ ਹੈ: ਪੈਰਲਲਿਜ਼ਮ ਅਤੇ ਰੀਟ੍ਰਾਈ ਡਿਫੌਲਟ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ।
Bigtable ਇੱਕ wide-column store ਹੈ ਜੋ ਵੱਡੀ throughput ਅਤੇ ਅਨੁਮਾਨਿਤ ਲੇਟੈਂਸੀ ਲਈ ਬਣਿਆ ਹੈ। ਮੁੱਖ ਗੱਲਾਂ:
ਸਟੋਰੇਜ ਚੋਇਸਾਂ ਨਿਰਭਰ ਕਰਦੀਆਂ ਹਨ ਕਿ ਤੁਸੀਂ ਕਿਹੜਾ ਡਾਟਾ ਭਰੋਸੇ ਨਾਲ ਟ੍ਰੇਨ ਕਰ ਸਕਦੇ ਹੋ:
ਸਰਲ ਸ਼ਬਦਾਂ ਵਿੱਚ: ਸਥਿਰ ਸਟੋਰੇਜ ਹੀ ਅਕਸਰ ਨਿਰਣਯ ਕਰਦਾ ਹੈ ਕਿ ML ਇਕ ਉਤਪਾਦ ਸਮਰੱਥਾ ਹੋਵੇਗਾ ਜਾਂ ਇਕ ਹਰ ਵਾਰੀ ਦੀ ਅੱਗ।
ਟ੍ਰੇਨਿੰਗ ਸਟੇਟਫੁਲ ਅਤੇ ਇਟਰੇਟਿਵ ਹੁੰਦੀ ਹੈ, ਇਸ ਲਈ ਕੋਆਰਡੀਨੇਸ਼ਨ ਮੁਸ਼ਕਲ ਹੁੰਦੀ ਹੈ:
ਅਮਲੀ ਤਰੀਕਾ: end-to-end ਸਮਾਂ ਮਾਪੋ, ਪਹਿਲਾਂ topology ਨੂੰ ਸਾਦਾ ਕਰੋ, ਫਿਰ ਅਸਲੀ ਬੋਤਲਨੈੱਕ ਮਿਲਣ 'ਤੇ ਆਪਟੀਮਾਈਜ਼ ਕਰੋ।
ਸਾਂਝਾ ਪਲੇਟਫਾਰਮ "ਹੀਰੋ ਵਰਕਫਲੋਜ਼" ਨੂੰ ਪੇਵਡ ਰੋਡਾਂ ਵਿੱਚ ਬਦਲ ਦਿੰਦਾ ਹੈ:
ਇਹ ਨਕਲ ਅਤੇ ਵਿਕਾਸ ਘੱਟ ਕਰਦਾ ਹੈ ਅਤੇ ਟੀਮਾਂ ਵਿਚਕਾਰ ਨਤੀਜਿਆਂ ਦੀ ਤੁਲਨਾ ਸੌਖੀ ਬਣਾਉਂਦਾ ਹੈ—ਅਕਸਰ ਕਿਸੇ ਇਕ ਮਾਡਲ ਟ੍ਰਿਕ ਤੋਂ ਵੱਧ ਲਾਭ ਦੇਂਦਾ ਹੈ।
ਸਟੈਂਡਰਡਾਈਜ਼ੇਸ਼ਨ ਸਹਿਯੋਗ ਲਾਗਤ ਘਟਾਉਂਦੀ ਹੈ:
TensorFlow ਦੇ ਬਾਹਰ ਵੀ ਸਬਕ ਇਹੇ ਹੈ: ਕੁਝ ਥੋੜੇ ਸਥਿਰ ਅਬਸਟ੍ਰੈਕਸ਼ਨ ਚੁਣੋ, ਵਧੀਆ ਦਸਤਾਵੇਜ਼ ਬਣਾਓ, ਅਤੇ ਮਿਆਰੀ ਰਸਤਾ ਆਸਾਨ ਬਣਾਉ।
ਤੁਸੀਂ Google-ਸਟਾਈਲ ਸਰੋਤ ਨਹੀਂ ਰੱਖਦੇ ਹੋਣ ਤੇ ਵੀ ਇਹ ਨਿਯਮ ਲਾਗੂ ਕਰ ਸਕਦੇ ਹੋ:
ਛੋਟੀ ਟੀਮਾਂ ਲਈ ਇੱਕ ਮਹੱਤਵਪੂਰਨ ਤੇਜ਼ੀ ਦਾ ਜ਼ਰੀਆ: ਇੰਫ੍ਰਾਸਟ੍ਰੱਕਚਰ UI ਵਾਲੀ ਖ਼ਾਦੀ ਨੂੰ ਘਟਾਓ—ਜਦੋਂ ਟੂਲ ਬਣਾਉਣਾ ਮਹਿੰਗਾ ਲੱਗੇ ਤਾਂ ਟੀਮਾਂ ਇਹ ਨਹੀਂ ਬਣਾਉਂਦੀਆਂ ਅਤੇ ਹਮੇਸ਼ਾ ਮੈਨੁਅਲ ਓਪਰੇਸ਼ਨ ਭੁਗਤਦੇ ਰਹਿੰਦੇ ਹਨ। Koder.ai ਵਰਗੇ ਟੂਲ ਪਰਿਸ਼ਰਾਂ ਤੇਜ਼ੀ ਨਾਲ ਸਹਾਇਤਾ ਦੇ ਸਕਦੇ ਹਨ, ਬਚਤ ਸਮੇਤ।
