ਤੁਹਾਨੂੰ ਸਬ-ਏਜੰਟਸ (Sub-Agents) ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ

ਜ਼ਿਆਦਾਤਰ ਲੋਕ ਏਜੰਟ ਆਰਕੀਟੈਕਚਰ (agent architectures) ਨੂੰ ਸੰਗਠਨਾਤਮਕ ਚਾਰਟ (organizational charts) ਵਾਂਗ ਬਣਾਉਂਦੇ ਹਨ।

ਉਹ ਸਭ ਤੋਂ ਉੱਪਰ ਇੱਕ Orchestrator ਰੱਖਦੇ ਹਨ। ਉਹ ਇੱਕ Researcher, ਇੱਕ Coder, ਅਤੇ ਇੱਕ Tester ਲਈ ਲਾਈਨਾਂ ਖਿੱਚਦੇ ਹਨ। ਇਹ ਦੇਖਣ ਵਿੱਚ ਸਾਫ਼-ਸੁਥਰਾ ਅਤੇ ਪੇਸ਼ੇਵਰ ਲੱਗਦਾ ਹੈ।

ਇਹ ਇੱਕ ਗਲਤੀ ਹੈ।

1975 ਵਿੱਚ, ਫ੍ਰੈਡ ਬਰੁਕਸ (Fred Brooks) ਨੇ ਲਿਖਿਆ ਸੀ ਕਿ ਇੱਕ ਦੇਰੀ ਨਾਲ ਚੱਲ ਰਹੇ ਸਾਫਟਵੇਅਰ ਪ੍ਰੋਜੈਕਟ ਵਿੱਚ ਹੋਰ ਲੋਕਾਂ ਨੂੰ ਜੋੜਨ ਨਾਲ ਉਹ ਹੋਰ ਵੀ ਦੇਰੀ ਨਾਲ ਚੱਲਣ ਲੱਗਦਾ ਹੈ। ਅਜਿਹਾ ਇਸ ਲਈ ਹੁੰਦਾ ਹੈ ਕਿਉਂਕਿ ਕੰਮ ਹੋਣ ਦੀ ਗਤੀ ਨਾਲੋਂ ਸੰਚਾਰ ਦੀ ਲਾਗਤ (communication costs) ਤੇਜ਼ੀ ਨਾਲ ਵਧਦੀ ਹੈ।

ਜਦੋਂ ਤੁਸੀਂ ਏਜੰਟਾਂ ਦਾ ਇੱਕ ਸਮੂਹ (swarm) ਬਣਾਉਂਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਇਸੇ ਗਲਤੀ ਨੂੰ ਦੁਹਰਾਉਂਦੇ ਹੋ।

Orchestrator ਆਪਣਾ ਸਾਰਾ ਸਮਾਂ ਸਬ-ਟਾਸਕਾਂ (subtasks) ਨੂੰ ਸੰਭਾਲਣ ਵਿੱਚ ਬਿਤਾਉਂਦਾ ਹੈ। ਇਸ ਨਾਲ ਬਹੁਤ ਜ਼ਿਆਦਾ ਵਾਧੂ ਬੋਝ (overhead) ਪੈਦਾ ਹੁੰਦਾ ਹੈ। ਤੁਸੀਂ ਕੋਈ ਆਰਕੀਟੈਕਚਰ ਨਹੀਂ ਬਣਾ ਰਹੇ, ਤੁਸੀਂ ਸਿਰਫ਼ ਪਾਈਪਲਾਈਨ (plumbing) ਬਣਾ ਰਹੇ ਹੋ।

ਇੱਥੇ ਕਾਰਨ ਦਿੱਤੇ ਗਏ ਹਨ ਕਿ ਸਬ-ਏਜੰਟਸ ਕਿਉਂ ਅਸਫਲ ਹੁੰਦੇ ਹਨ:

ਖੋਜ ਦਰਸਾਉਂਦੀ ਹੈ ਕਿ ਮਲਟੀ-ਏਜੰਟ ਫਰੇਮਵਰਕਸ (multi-agent frameworks) ਵਿੱਚ ਅਸਫਲਤਾ ਦੀ ਦਰ 41% ਤੋਂ 87% ਦੇ ਵਿਚਕਾਰ ਹੁੰਦੀ ਹੈ। ਇਹ ਅਸਫਲਤਾਵਾਂ ਇਸ ਲਈ ਹੁੰਦੀਆਂ ਹਨ ਕਿਉਂਕਿ ਏਜੰਟ ਇੱਕ ਦੂਜੇ ਦੀ ਗੱਲ ਨੂੰ ਸਮਝਣ ਦੀ ਬਜਾਏ ਵੱਖ-ਵੱਖ ਦਿਸ਼ਾਵਾਂ ਵਿੱਚ ਗੱਲ ਕਰਦੇ ਹਨ। ਇੱਕ ਬਿਹਤਰ ਮਾਡਲ ਇਸ ਨੂੰ ਠੀਕ ਨਹੀਂ ਕਰੇਗਾ। ਇਹ ਤਾਲਮੇਲ (coordination) ਦੀ ਸਮੱਸਿਆ ਹੈ, ਮਾਡਲ ਦੀ ਨਹੀਂ।

ਇਸ ਦੀ ਬਜਾਏ ਤੁਹਾਨੂੰ ਕਿਵੇਂ ਬਣਾਉਣਾ ਚਾਹੀਦਾ ਹੈ?

ਇਹਨਾਂ ਦੋ ਨਿਯਮਾਂ ਦੀ ਪਾਲਣਾ ਕਰੋ:

  1. ਜੇਕਰ ਕੰਮ ਸੁਤੰਤਰ ਹਨ, ਤਾਂ ਉਹਨਾਂ ਨੂੰ ਵੱਖ-ਵੱਖ ਲੂਪਸ (loops) ਵਜੋਂ ਚਲਾਓ। ਦੋ ਵੱਖਰੇ ਪ੍ਰੋਗਰਾਮਾਂ ਦੀ ਵਰਤੋਂ ਕਰੋ। ਇਹ ਪੈਰਲਲ ਪ੍ਰੋਸੈਸਿੰਗ (parallel processing) ਹੈ, ਮਲਟੀ-ਏਜੰਟ ਸਿਸਟਮ ਨਹੀਂ।
  2. ਜੇਕਰ ਕੰਮ ਲਈ ਇੱਕੋ ਇੱਕ ਵਿਚਾਰਧਾਰਾ (single train of thought) ਦੀ ਲੋੜ ਹੈ, ਤਾਂ ਇੱਕ ਸਿੰਗਲ ਲੂਪ ਦੀ ਵਰਤੋਂ ਕਰੋ।

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