Google ਹੁਣ ਆਪਣੇ “Swarm” ਮਲਟੀ-ਏਜੰਟ ਪੈਟਰਨ ਨੂੰ AI-ਅਧਾਰਿਤ ਪ੍ਰਣਾਲੀਆਂ ਲਈ ਸਭ ਤੋਂ ਸ਼ਕਤੀਸ਼ਾਲੀ—ਅਤੇ ਸਭ ਤੋਂ ਮਹਿੰਗਾ—ਡਿਜ਼ਾਈਨ ਕਹਿੰਦਾ ਹੈ। ਪ੍ਰੋਡਕਟ-ਡਿਜ਼ਾਈਨ ਸਹਾਇਕ ਜਾਂ ਖੋਜ ਸਹਾਇਕ ਬਣਾਉਣ ਵਾਲੇ ਡਿਵੈਲਪਰਾਂ ਨੂੰ ਅਟੋਨੋਮਸ ਏਜੰਟਾਂ ਵਿਚਕਾਰ ਅਮੀਰ, ਸਵੈ-ਪ੍ਰਬੰਧਿਤ ਬਹਿਸ ਦੇ ਵਾਅਦੇ ਦੇ ਬਦਲੇ ਭਾਰੀ ਲਾਗਤ ਅਤੇ ਲੇਟੈਂਸੀ (latency) ਦੇ ਨੁਕਸਾਨ ਨੂੰ ਤੋਲਣਾ ਚਾਹੀਦਾ ਹੈ।
Swarm ਪੈਟਰਨ ਅਸਲ ਵਿੱਚ ਕੀ ਕਰਦਾ ਹੈ
ਇੱਕ Swarm ਵਿੱਚ, ਹਰ ਵਿਸ਼ੇਸ਼ ਏਜੰਟ ਸਿੱਧਾ ਦੂਜੇ ਹਰ ਏਜੰਟ ਨਾਲ ਗੱਲ ਕਰਦਾ ਹੈ। ਇਹ ਪੈਟਰਨ ਇੱਕ ਸਿੰਗਲ ਸੁਪਰਵਾਈਜ਼ਰੀ ਕੋਆਰਡੀਨੇਟਰ ਦੀ ਜਗ੍ਹਾ ਪੀਅਰਜ਼ (peers) ਦਾ ਇੱਕ ਫਲੈਟ ਨੈੱਟਵਰਕ ਲਿਆਉਂਦਾ ਹੈ ਜੋ ਕੰਮਾਂ ਦੀ ਆਲੋਚਨਾ, ਸੁਧਾਰ ਅਤੇ ਹੈਂਡ-ਆਫ ਕਰਦੇ ਹਨ। ਇੱਕ ਹਲਕਾ ਜਿਹਾ ਡਿਸਪੈਚਰ ਪ੍ਰਕਿਰਿਆ ਸ਼ੁਰੂ ਕਰਦਾ ਹੈ ਪਰ ਗੱਲਬਾਤ ਨੂੰ ਨਿਰਧਾਰਤ ਨਹੀਂ ਕਰਦਾ; ਹਰ ਏਜੰਟ ਇਹ ਫੈਸਲਾ ਕਰਦਾ ਹੈ ਕਿ ਕਿਸੇ ਪ੍ਰਸਤਾਵ 'ਤੇ ਕੰਮ ਜਾਰੀ ਰੱਖਣਾ ਹੈ ਜਾਂ ਇਸਨੂੰ ਕਿਸੇ ਭਰੋਸੇਮੰਦ ਪੀਅਰ ਨੂੰ ਭੇਜਣਾ ਹੈ। ਇਸਦਾ ਨਤੀਜਾ ਇੱਕ 'ਆਲ-ਟੂ-ਆਲ' (all-to-all) ਸੰਵਾਦ ਹੁੰਦਾ ਹੈ ਜੋ ਉਹਨਾਂ ਦ੍ਰਿਸ਼ਟੀਕੋਣਾਂ ਨੂੰ ਸਾਹਮਣੇ ਲਿਆਉਂਦਾ ਹੈ ਜੋ ਇੱਕ ਸਿੰਗਲ ਮੈਨੇਜਰ ਤੋਂ ਰਹਿ ਸਕਦੇ ਹਨ।
ਇਹ ਇੱਕ ਰਵਾਇਤੀ ਕੋਆਰਡੀਨੇਟਰ ਤੋਂ ਕਿਵੇਂ ਵੱਖਰਾ ਹੈ
ਇੱਕ ਕੋਆਰਡੀਨੇਟਰ ਹਾਇਰਾਰਕੀ (hierarchy) ਦੇ ਸਿਖਰ 'ਤੇ ਬੈਠਦਾ ਹੈ, ਕੰਮ ਸੌਂਪਦਾ ਹੈ ਅਤੇ ਨਤੀਜੇ ਇਕੱਠੇ ਕਰਦਾ ਹੈ। Swarm ਵਿੱਚ ਕੋਈ ਬੌਸ ਨਹੀਂ ਹੁੰਦਾ। ਏਜੰਟ ਅਗਲੇ ਕਦਮ ਲਈ ਗੱਲਬਾਤ ਕਰਦੇ ਹਨ, ਅਤੇ ਉਹਨਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਕੇਂਦਰੀ ਕਮਾਂਡ ਦੀ ਉਡੀਕ ਕੀਤੇ ਬਿਨਾਂ ਕਿਸੇ ਸਬ-ਟਾਸਕ ਦੀ ਜ਼ਿੰਮੇਵਾਰੀ ਲੈ ਸਕਦਾ ਹੈ। Google ਇਸਨੂੰ “ਸਭ ਤੋਂ ਸ਼ਕਤੀਸ਼ਾਲੀ” ਪਹਿਲੂ ਕਹਿੰਦਾ ਹੈ ਕਿਉਂਕਿ ਪ੍ਰਣਾਲੀ ਸਮੱਸਿਆ ਦੇ ਖੇਤਰ ਦੀ ਸਮਾਨਾਂਤਰ (parallel) ਵਿੱਚ ਜਾਂਚ ਕਰਦੀ ਹੈ, ਲਗਾਤਾਰ ਇੱਕ ਦੂਜੇ ਦੇ ਅੰਤਰ ਦ੍ਰਿਸ਼ਟੀਕੋਣਾਂ 'ਤੇ ਅਧਾਰਤ ਬਣਦੀ ਰਹਿੰਦੀ ਹੈ।
Swarm ਕਦੋਂ ਸਹੀ ਹੁੰਦਾ ਹੈ
ਇਹ ਪੈਟਰਨ ਅਸਪਸ਼ਟ, ਬਹੁ-ਵਿਸ਼ਾਗਤ ਸਮੱਸਿਆਵਾਂ 'ਤੇ ਚਮਕਦਾ ਹੈ ਜਿੱਥੇ ਤਾਲਮੇਲ (trade-offs) ਨੂੰ ਮਾਪਣਾ ਮੁਸ਼ਕਲ ਹੁੰਦਾ ਹੈ। ਇੱਕ ਪ੍ਰੋਡਕਟ-ਡਿਜ਼ਾਈਨ ਵਰਕਫਲੋ ਦੀ ਕਲਪਨਾ ਕਰੋ ਜਿਸ ਨੂੰ ਯੂਜ਼ਰ ਐਕਸਪੀਰੀਅੰਸ, ਇੰਜੀਨੀਅਰਿੰਗ ਦੀ ਸੰਭਾਵਨਾ ਅਤੇ ਵਿੱਤੀ ਪਾਬੰਦੀਆਂ ਵਿਚਕਾਰ ਸੰਤੁਲਨ ਬਣਾਉਣਾ ਪਵੇ। ਇੱਕ ਖੋਜਕਰਤਾ, ਇੱਕ ਇੰਜੀਨੀਅਰ ਅਤੇ ਇੱਕ ਵਿੱਤ ਵਿਸ਼ਲੇਸ਼ਕ—ਹਰ ਇੱਕ ਇੱਕ ਏਜੰਟ ਵਜੋਂ—ਕਿਸੇ ਫੀਚਰ ਦੇ ਗੁਣਾਂ 'ਤੇ ਬਹਿਸ ਕਰ ਸਕਦੇ ਹਨ, ਵਿਕਲਪ ਪ੍ਰਸਤਾਵਿਤ ਕਰ ਸਕਦੇ ਹਨ ਅਤੇ ਇੱਕ ਸਿੰਗਲ ਸਪੈਸੀਫਿਕੇਸ਼ਨ 'ਤੇ ਸਹਿਮਤ ਹੋ ਸਕਦੇ ਹਨ, ਜੋ ਕਿ ਇੱਕ ਸਿੰਗਲ ਕੋਆਰਡੀਨੇਟਰ ਲਈ ਸੰਗਠਿਤ ਕਰਨਾ ਮੁਸ਼ਕਲ ਹੋ ਸਕਦਾ ਹੈ।
ਕਦੋਂ ਇਸ ਤੋਂ ਦੂਰ ਰਹਿਣਾ ਚਾਹੀਦਾ ਹੈ
Swarm-ਸ਼ੈਲੀ ਦੀ ਬਹਿਸ ਉਹਨਾਂ well-structured ਕੰਮਾਂ ਲਈ ਬਹੁਤ ਜ਼ਿਆਦਾ ਹੈ ਜੋ ਇੱਕ ਸਪਸ਼ਟ ਪਾਈਪਲਾਈਨ ਦੀ ਪਾਲਣਾ ਕਰਦੇ ਹਨ। ਜੇਕਰ ਕਿਸੇ ਪ੍ਰੋਜੈਕਟ ਲਈ ਘੱਟ ਸੰਚਾਲਨ ਲਾਗਤ, ਤੇਜ਼ ਰਿਜ਼ਲਟ ਜਾਂ ਇੱਕ ਨਿਸ਼ਚਿਤ ਸਮਾਪਤੀ ਬਿੰਦੂ ਦੀ ਲੋੜ ਹੈ, ਤਾਂ ਇਸ ਪੈਟਰਨ ਦਾ ਵਾਧੂ ਖਰਚਾ ਇਸਦੇ ਫਾਇਦਿਆਂ ਨਾਲੋਂ ਤੇਜ਼ੀ ਨਾਲ ਵੱਧ ਜਾਂਦਾ ਹੈ। 'ਆਲ-ਟੂ-ਆਲ' ਗੱਲਬਾਤ ਮਾਡਲ ਕਾਲਾਂ ਨੂੰ ਵਧਾ ਦਿੰਦੀ ਹੈ, ਜਿਸ ਨਾਲ ਮਾਮੂਲੀ ਕੰਮ ਵੀ ਮਹਿੰਗੇ ਅਤੇ ਲੇਟੈਂਸੀ-ਭਾਰੀ ਕੰਮਾਂ ਵਿੱਚ ਬਦਲ ਜਾਂਦੇ ਹਨ। ਬਿਨਾਂ ਕਿਸੇ ਸਪਸ਼ਟ ਐਗਜ਼ਿਟ ਰੂਲ (exit rule)—ਜਿਵੇਂ ਕਿ ਸਮੇਂ ਦੀ ਸੀਮਾ, ਗੱਲਬਾਤ ਦੇ ਚੱਕਰਾਂ ਦੀ ਵੱਧ ਤੋਂ ਵੱਧ ਗਿਣਤੀ ਜਾਂ ਸਹਿਮਤੀ ਦੀ ਸੀਮਾ—ਗੱਲਬਾਤ ਬਿਨਾਂ ਕਿਸੇ ਅੰਤ ਦੇ ਚੱਲ ਸਕਦੀ ਹੈ।
ਲੁਕਵੇਂ ਖਰਚੇ ਅਤੇ ਮੁਸ਼ਕਲਾਂ
- ਲਾਗਤ ਅਤੇ ਲੇਟੈਂਸੀ – ਏਜੰਟਾਂ ਵਿਚਕਾਰ ਹਰ ਵਾਰ-ਵਾਰ ਗੱਲਬਾਤ ਇੱਕ ਵੱਖਰੀ ਮਾਡਲ ਇੰਵੋਕੇਸ਼ਨ (invocation) ਨੂੰ ਟ੍ਰਿਗਰ ਕਰਦੀ ਹੈ।
- ਸਹਿਮਤੀ ਦੀ ਕੋਈ ਗਾਰੰਟੀ ਨਹੀਂ – ਏਜੰਟ ਇੱਕੋ ਤਰ੍ਹਾਂ ਦੀਆਂ ਬਹਿਸਾਂ ਨੂੰ ਵਾਰ-ਵਾਰ ਦੁਹਰਾ ਸਕਦੇ ਹਨ, ਕਦੇ ਵੀ ਫੈਸਲੇ 'ਤੇ ਨਹੀਂ ਪਹੁੰਚਦੇ। ਪ੍ਰਣਾਲੀ ਵਿੱਚ ਡੈੱਡਲੌਕ (deadlock) ਨੂੰ ਤੋੜਨ ਲਈ ਕੋਈ ਇਨ-ਬਿਲਟ ਆਰਬੀਟਰ ਨਹੀਂ ਹੁੰਦਾ।
- ਲਾਗੂ ਕਰਨ ਦੀ ਗੁੰਝਲਤਾ – ਭਰੋਸੇ, ਕੰਮ ਦੇ ਹੈਂਡ-ਆਫ ਅਤੇ ਸਮਾਪਤੀ ਦੀਆਂ ਸ਼ਰਤਾਂ ਨੂੰ ਨਿਯੰਤਰਿਤ ਕਰਨ ਵਾਲੇ ਲੌਜਿਕ ਨੂੰ ਬਣਾਉਣਾ ਕੋਈ ਸੌਖਾ ਕੰਮ ਨਹੀਂ ਹੈ। ਡਿਵੈਲਪਰਾਂ ਨੂੰ ਅੰਡਰਲਾਈਂਗ AI ਮਾਡਲਾਂ ਦੇ ਉੱਪਰ ਇੱਕ ਸੋਫਿਸਟਿਕੇਟਿਡ ਆਰਕੇਸਟਰੇਸ਼ਨ ਕੋਡ ਤਿਆਰ ਕਰਨਾ ਪੈਂਦਾ ਹੈ।
ਡਿਵੈਲਪਰਾਂ ਲਈ ਤਿੰਨ ਵਿਵਹਾਰਕ ਨਿਯਮ
- ਪਹਿਲਾਂ ਹੀ ਇੱਕ ਐਗਜ਼ਿਟ ਕੰਡੀਸ਼ਨ (exit condition) ਤੈਅ ਕਰੋ। ਚਾਹੇ ਇਹ ਸਮੇਂ ਦੀ ਸਖ਼ਤ ਸੀਮਾ ਹੋਵੇ, ਗੱਲਬਾਤ ਦੇ ਚੱਕਰਾਂ ਦੀ ਵੱਧ ਤੋਂ ਵੱਧ ਗਿਣਤੀ ਹੋਵੇ, ਜਾਂ ਲੋੜੀਂਦਾ ਸਹਿਮਤੀ ਪੱਧਰ ਹੋਵੇ, ਪ੍ਰਣਾਲੀ ਨੂੰ ਇੱਕ ਸਪਸ਼ਟ ਰੋਕਣ ਦਾ ਸੰਕੇਤ ਚਾਹੀਦਾ ਹੈ।
- ਵਧੇਰੇ ਸਰੋਤਾਂ ਦੀ ਵਰਤੋਂ ਲਈ ਬਜਟ ਰੱਖੋ। ਉਮੀਦ ਕਰੋ ਕਿ Swarm ਤੁਹਾਡੇ ਦੁਆਰਾ ਪਹਿਲਾਂ ਵਰਤੇ ਗਏ ਕਿਸੇ ਵੀ ਕੋਆਰਡੀਨੇਟਰ-ਅਧਾਰਤ ਡਿਜ਼ਾਈਨ ਨਾਲੋਂ ਵੱਧ ਕੰਪਿਊਟ ਦੀ ਵਰਤੋਂ ਕਰੇਗਾ।
- ਕੋਆਰਡੀਨੇਟਰ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ। ਜੇਕਰ ਇੱਕ ਸਿੰਗਲ, ਚੰਗੀ ਤਰ੍ਹਾਂ ਪ੍ਰੋਗਰਾਮ ਕੀਤਾ ਗਿਆ ਏਜੰਟ ਕੰਮ ਸੰਭਾਲ ਸਕਦਾ ਹੈ, ਤਾਂ Swarm ਦੀ ਵਾਧੂ ਗੁੰਝਲਤਾ ਜੋੜਨ ਦਾ ਕੋਈ ਖਾਸ ਕਾਰਨ ਨਹੀਂ ਹੈ।
ਦ੍ਰਿਸ਼ਟੀਕੋਣ ਵਿੱਚ ਤਾਲਮੇਲ (Trade-off)
ਸਮਰਥਕ ਕਹਿੰਦੇ ਹਨ ਕਿ Swarm ਦੀ ਲੁਕਵੇਂ ਅੰਤਰ ਦ੍ਰਿਸ਼ਟੀਕੋਣਾਂ ਨੂੰ ਸਾਹਮਣੇ ਲਿਆਉਣ ਅਤੇ ਪੀਅਰ-ਆਲੋਚਨਾ ਰਾਹੀਂ ਸਵੈ-ਸੁਧਾਰ ਕਰਨ ਦੀ ਸਮਰੱਥਾ ਅਜਿਹੇ ਹੱਲ ਪੈਦਾ ਕਰ ਸਕਦੀ ਹੈ ਜੋ ਇੱਕ ਸਿੰਗਲ ਆਰਕੇਸਟਰੇਟਰ ਤੋਂ ਰਹਿ ਸਕਦੇ ਹਨ। ਆਲੋਚਕ ਮਹਿੰਗੀ ਕੀਮਤ ਅਤੇ ਲਗਾਤਾਰ ਬਹਿਸ ਦੇ ਚੱਕਰਾਂ ਦੇ ਜੋਖਮ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦੇ ਹਨ। ਇਹ ਪੈਟਰਨ ਕੋਈ ਯੂਨੀਵਰਸਲ ਅੱਪਗ੍ਰੇਡ ਨਹੀਂ ਹੈ; ਇਹ ਸਮੱਸਿਆਵਾਂ ਦੇ ਇੱਕ ਸੀਮਤ ਸਮੂਹ ਲਈ ਇੱਕ ਵਿਸ਼ੇਸ਼ ਸੰਦ ਹੈ ਜਿੱਥੇ ਤਰਕ ਦੀ ਡੂੰਘਾਈ, ਰਫਤਾਰ ਅਤੇ ਲਾਗਤ ਨਾਲੋਂ ਵੱਧ ਮਹੱਤਵ ਰੱਖਦੀ ਹੈ।
ਅੱਗੇ ਕੀ ਦੇਖਣਾ ਹੈ
Google ਦਾ ਦਸਤਾਵੇਜ਼ ਹੁਣ ਸਿਫਾਰਸ਼ ਕਰਦਾ ਹੈ ਕਿ ਸਰਲ ਪੈਟਰਨਾਂ ਦਾ ਮੁਲਾਂਕਣ ਕਰਨ ਤੋਂ ਬਾਅਦ Swarm ਨੂੰ ਇੱਕ ਆਖਰੀ ਵਿਕਲਪ ਵਜੋਂ ਵਰਤਿਆ ਜਾਵੇ। ਉਦੋਂ ਤੱਕ, ਡਿਵੈਲਪਰਾਂ ਨੂੰ ਇੱਕ ਕੋਆਰਡੀਨੇਟਰ ਨਾਲ ਪ੍ਰੋਟੋਟਾਈਪ ਬਣਾਉਣਾ ਚਾਹੀਦਾ ਹੈ, ਪ੍ਰਦਰਸ਼ਨ ਨੂੰ ਮਾਪਣਾ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਸਿਰਫ ਉਦੋਂ ਹੀ Swarm 'ਤੇ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ ਜ