ਏਜੰਟ ਸਿਸਟਮ ਡਿਜ਼ਾਈਨ ਲਈ ਵਿਹਾਰਕ ਨਿਯਮ

• ਆਪਣੇ ਏਜੰਟ-ਅਧਾਰਿਤ ਸਿਸਟਮ ਵਿੱਚ ਫ਼ੈਸਲੇ ਕਿਵੇਂ ਅਤੇ ਕਿੱਥੇ ਲਏ ਜਾਂਦੇ ਹਨ, ਇਸ ਬਾਰੇ ਧਿਆਨ ਨਾਲ ਵਿਚਾਰ ਕਰਨਾ ਜ਼ਰੂਰੀ ਹੈ.

• ਵਧੇਰੇ ਫ਼ੈਸਲੇ LLM ਉੱਤੇ ਛੱਡਣ ਨਾਲ ਸਿਸਟਮ ਹੋਰ ਕੰਮਾਂ ਲਈ ਢਲ ਸਕਦਾ ਹੈ, ਪਰ ਇਸ ਨਾਲ ਗਤੀ, ਭਰੋਸੇਯੋਗਤਾ ਅਤੇ ਮਜ਼ਬੂਤੀ ਘਟ ਸਕਦੀ ਹੈ.

• ਜਿੱਥੇ ਸੰਭਵ ਹੋਵੇ, ਫ਼ੈਸਲਾ ਲੈਣ ਦੀ ਪ੍ਰਕਿਰਿਆ ਦਾ ਵੱਧ ਤੋਂ ਵੱਧ ਹਿੱਸਾ LLM ਤੋਂ ਕੱਢ ਕੇ ਸਪਸ਼ਟ ਸਾਫ਼ਟਵੇਅਰ ਕੋਡ ਵਿੱਚ ਰੱਖੋ. ਇਹ ਖ਼ਾਸ ਕਰਕੇ ਉੱਚ-ਜੋਖਮ ਅਤੇ ਉਤਪਾਦਨ ਕਾਰਜ-ਪ੍ਰਵਾਹਾਂ ਲਈ ਸਹੀ ਹੈ.

LLM-ਅਧਾਰਿਤ ਏਜੰਟ ਸਿਸਟਮ ਬਣਾਉਂਦੇ ਸਮੇਂ ਸਭ ਤੋਂ ਮਹੱਤਵਪੂਰਨ ਚੋਣਾਂ ਵਿੱਚੋਂ ਇੱਕ ਇਹ ਹੈ ਕਿ ਫ਼ੈਸਲਾ ਲੈਣ ਦੀ ਕਿੰਨੀ ਪ੍ਰਕਿਰਿਆ LLM ਮਾਡਲ ਵਿੱਚ ਰੱਖੀ ਜਾਵੇ ਅਤੇ ਕਿੰਨੀ ਸਪਸ਼ਟ ਸਾਫ਼ਟਵੇਅਰ ਵਿੱਚ.

ਇਸ ਚੋਣ ਨੂੰ ਸਮਝਣ ਲਈ ਅਸੀਂ ਇਸਨੂੰ ਹੇਠਾਂ ਦਿੱਤੀਆਂ ਪਹੁੰਚਾਂ ਵਿਚਕਾਰ ਇੱਕ ਦਾਇਰੇ ਵਜੋਂ ਦੇਖ ਸਕਦੇ ਹਾਂ:

• ਰਾਊਟਰ-ਅਧਾਰਿਤ ਬਣਤਰਾਂ ਕੋਡ ਵਿੱਚ ਕ੍ਰਮ ਅਤੇ ਤਰਕ ਨੂੰ ਸਪਸ਼ਟ ਤੌਰ ਉੱਤੇ ਪਰਿਭਾਸ਼ਿਤ ਕਰਦੀਆਂ ਹਨ, ਜਿਸ ਨਾਲ ਸੀਮਤ ਖੇਤਰ ਵਾਲੇ ਕੰਮਾਂ ਲਈ ਜਾਂਚਯੋਗਤਾ, ਪੂਰਵ-ਅਨੁਮਾਨਯੋਗਤਾ ਅਤੇ ਮਜ਼ਬੂਤੀ ਯਕੀਨੀ ਬਣਦੀ ਹੈ. ਇਨ੍ਹਾਂ ਨੂੰ “ਕਾਰਜ-ਪ੍ਰਵਾਹ ਏਜੰਟ” ਵੀ ਕਿਹਾ ਜਾਂਦਾ ਹੈ.

• ਆਰਕੇਸਟ੍ਰੇਟਰ ਏਜੰਟ ਕੁਦਰਤੀ-ਭਾਸ਼ਾ ਨਿਰਦੇਸ਼ਾਂ ਰਾਹੀਂ ਕੰਮਾਂ ਦੇ ਪ੍ਰਵਾਹ ਬਾਰੇ ਗਤੀਸ਼ੀਲ ਫ਼ੈਸਲੇ ਲੈਣ ਲਈ ਵੱਡੇ ਭਾਸ਼ਾ ਮਾਡਲਾਂ (LLM) ਉੱਤੇ ਨਿਰਭਰ ਕਰਦੇ ਹਨ. ਇਹ ਉਨ੍ਹਾਂ ਖੁੱਲ੍ਹੀਆਂ ਗੱਲਬਾਤਾਂ ਲਈ ਢੁਕਵੇਂ ਹਨ ਜਿੱਥੇ ਪਹਿਲਾਂ ਤੋਂ ਨਿਰਧਾਰਤ ਤਰਕ ਨਾਕਾਫ਼ੀ ਜਾਂ ਅਸੰਭਵ ਹੋਵੇ.

ਉੱਚ-ਜੋਖਮ ਵਾਲੇ ਉਤਪਾਦਨ ਕਾਰਜ-ਪ੍ਰਵਾਹਾਂ ਲਈ ਅਸੀਂ ਆਮ ਤੌਰ ਉੱਤੇ ਵਧੇਰੇ ਰਾਊਟਰ-ਅਧਾਰਿਤ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਵਰਤਣ ਅਤੇ ਆਰਕੇਸਟ੍ਰੇਟਰਾਂ ਨੂੰ ਲਚਕਦਾਰ, ਆਮ-ਮਕਸਦ ਗੱਲਬਾਤਾਂ ਦੀ ਲੋੜ ਵਾਲੀਆਂ ਐਪਲੀਕੇਸ਼ਨਾਂ ਲਈ ਰਾਖਵਾਂ ਰੱਖਣ ਦੀ ਸਿਫ਼ਾਰਸ਼ ਕਰਦੇ ਹਾਂ.

ਰਾਊਟਰ-ਅਧਾਰਿਤ ਬਣਤਰਾਂ

ਰਾਊਟਰ ਏਜੰਟ ਸਿਸਟਮ:

• ਕੋਡ ਜਾਂ ਸਾਫ਼ਟਵੇਅਰ ਰਾਹੀਂ ਫ਼ੈਸਲਾ ਲੈਣ ਦਾ ਪ੍ਰਵਾਹ ਸਪਸ਼ਟ ਤੌਰ ਉੱਤੇ ਪਰਿਭਾਸ਼ਿਤ ਕਰਦੇ ਹਨ ਅਤੇ ਇਹ ਨਿਰਧਾਰਤ ਕਰਨ ਲਈ LLM ਵਰਤਦੇ ਹਨ ਕਿ ਸਾਫ਼ਟਵੇਅਰ ਕਿਹੜਾ ਰਾਹ ਅਪਣਾਏ.

• ਇਹ ਰਵਾਇਤੀ ਸਾਫ਼ਟਵੇਅਰ ਸਿਸਟਮਾਂ ਦੇ ਵਧੇਰੇ ਨੇੜੇ ਹੁੰਦੇ ਹਨ, ਕਿਉਂਕਿ ਇਨ੍ਹਾਂ ਦੇ ਰਾਹ ਸਪਸ਼ਟ ਅਤੇ ਪੂਰਵ-ਅਨੁਮਾਨਯੋਗ ਹੁੰਦੇ ਹਨ ਤੇ ਨਤੀਜੇ ਵਧੇਰੇ ਇਕਸਾਰ ਰਹਿੰਦੇ ਹਨ.

• ਇਹ ਸਖ਼ਤੀ ਨਾਲ ਪਰਿਭਾਸ਼ਿਤ ਕੀਤੇ ਜਾ ਸਕਣ ਵਾਲੇ ਕੰਮਾਂ ਲਈ ਢੁਕਵੇਂ ਹਨ.

ਹੇਠਾਂ “ਰਾਊਟਰ ਪਹੁੰਚ” ਵਰਤਣ ਵਾਲੇ ਹਵਾਈ ਯਾਤਰਾ ਬੁਕਿੰਗ ਚੈਟਬੋਟ ਏਜੰਟ ਦੀ ਇੱਕ ਸਰਲ ਉਦਾਹਰਨ ਹੈ. LLM ਤਿੰਨ ਸੰਭਾਵਿਤ ਚੋਣਾਂ ਵਿੱਚੋਂ ਸਵਾਲ ਦਾ ਇਰਾਦਾ ਵਰਗੀਕ੍ਰਿਤ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ, ਪਰ ਅਖ਼ੀਰ ਵਿੱਚ ਸਾਡਾ ਸਾਫ਼ਟਵੇਅਰ ਹੀ ਇਸ ਇਰਾਦੇ ਨੂੰ ਨਮੂਨਾ ਜਵਾਬ ਨਾਲ ਜੋੜਦਾ ਹੈ. ਕਿਉਂਕਿ LLM ਉੱਤੇ ਸਖ਼ਤ ਪਾਬੰਦੀਆਂ ਹਨ, ਉਪਭੋਗਤਾ ਨੂੰ ਵਧੇਰੇ ਇਕਸਾਰ ਵਿਹਾਰ ਮਿਲੇਗਾ.

ਆਰਕੇਸਟ੍ਰੇਟਰ ਬਣਤਰਾਂ

ਰਾਊਟਰ ਸਿਸਟਮ ਦੇ ਉਲਟ, ਆਰਕੇਸਟ੍ਰੇਟਰ ਏਜੰਟ ਸਿਸਟਮ:

• ਸਾਫ਼ਟਵੇਅਰ ਦੀ ਬਜਾਏ ਕੁਦਰਤੀ-ਭਾਸ਼ਾ ਨਿਰਦੇਸ਼ਾਂ ਰਾਹੀਂ ਤਾਰਕਿਕ ਪ੍ਰਵਾਹ ਪਰਿਭਾਸ਼ਿਤ ਕਰਦੇ ਹਨ. ਨੋਟ: ਪ੍ਰੋਗਰਾਮਿੰਗ ਭਾਸ਼ਾ ਦੇ ਮੁਕਾਬਲੇ ਕੁਦਰਤੀ ਭਾਸ਼ਾ ਮੂਲ ਰੂਪ ਵਿੱਚ ਅਸਪਸ਼ਟ ਅਤੇ ਲਚਕਦਾਰ ਹੁੰਦੀ ਹੈ. ਇਹ ਸਕਾਰਾਤਮਕ ਅਤੇ ਨਕਾਰਾਤਮਕ ਦੋਵੇਂ ਗੁਣ ਹਨ, ਜਿਨ੍ਹਾਂ ਬਾਰੇ ਅੱਗੇ ਚਰਚਾ ਕਰਾਂਗੇ. ਅਸੀਂ ਇਸਨੂੰ “ਹਦਾਇਤ ਦੀ ਬਜਾਏ ਇਰਾਦਾ” ਮੰਨਦੇ ਹਾਂ.

• ਇਹ ਪ੍ਰਕਿਰਿਆ ਦੇ ਕਈ ਵਿਕਲਪ ਦੇ ਸਕਦੇ ਹਨ, ਜਦਕਿ LLM ਲਾਗੂ ਕਰਨ ਦਾ ਕ੍ਰਮ ਅਤੇ ਤਰੀਕਾ ਨਿਰਧਾਰਤ ਕਰਦਾ ਹੈ.

• ਇਹ ਗਤੀਸ਼ੀਲ ਢੰਗ ਨਾਲ ਨਵੇਂ ਤਾਰਕਿਕ ਰਾਹ ਬਣਾ ਸਕਦੇ ਹਨ, ਜਿਨ੍ਹਾਂ ਨੂੰ ਸਾਫ਼ਟਵੇਅਰ ਵਿੱਚ ਸਪਸ਼ਟ ਤੌਰ ਉੱਤੇ ਪਰਿਭਾਸ਼ਿਤ ਕਰਨਾ ਔਖਾ ਹੁੰਦਾ ਹੈ.

• ਇਸ ਅਸਪਸ਼ਟਤਾ ਕਾਰਨ ਨਤੀਜੇ ਅਸੰਗਤ ਹੋ ਸਕਦੇ ਹਨ, ਪਰ ਸਫਲ ਹੋਣ ਉੱਤੇ ਇਹ “ਜਾਦੂਈ” ਲੱਗ ਸਕਦਾ ਹੈ.

ਹੇਠਾਂ ਦਿੱਤੀ ਉਦਾਹਰਨ ਉਸੇ ਸਰਲ ਹਵਾਈ ਯਾਤਰਾ ਸਮੱਸਿਆ ਉੱਤੇ ਆਰਕੇਸਟ੍ਰੇਟਰ ਪਹੁੰਚ ਲਾਗੂ ਕਰਦੀ ਹੈ. ਢੁਕਵਾਂ ਜਵਾਬ ਸਾਫ਼ਟਵੇਅਰ ਤੋਂ ਨਿਰਧਾਰਤ ਕਰਵਾਉਣ ਦੀ ਬਜਾਏ, ਫ਼ੈਸਲਾ ਲੈਣ ਦੀ ਜ਼ਿੰਮੇਵਾਰੀ LLM ਪਰਤ ਨੂੰ ਦਿੱਤੀ ਜਾਂਦੀ ਹੈ. ਇੱਥੇ ਇੱਕ ਬਹੁ-ਏਜੰਟ ਸਿਸਟਮ ਹੈ, ਜਿਸ ਵਿੱਚ “ਮੁੱਖ” ਆਰਕੇਸਟ੍ਰੇਟਰ ਏਜੰਟ ਉਪਭੋਗਤਾ ਦੇ ਸਵਾਲ ਦੀ ਮੁੱਢਲੀ ਜਾਂਚ ਕਰਦਾ ਹੈ ਅਤੇ ਇਸਨੂੰ ਉਡਾਣਾਂ ਬਦਲਣ ਲਈ ਖ਼ਾਸ ਤੌਰ ਉੱਤੇ ਬਣਾਏ ਏਜੰਟ ਨੂੰ ਸੌਂਪਦਾ ਹੈ, ਜੋ ਅਖ਼ੀਰ ਵਿੱਚ ਉਪਭੋਗਤਾ ਨੂੰ ਜਵਾਬ ਦਿੰਦਾ ਹੈ.

ਇਸ ਉਦਾਹਰਨ ਵਿੱਚ LLM ਪਰਤ ਵਰਗੀਕਰਤਾ, ਰਾਊਟਰ ਅਤੇ ਜਵਾਬ ਲੇਖਕ ਦੀ ਭੂਮਿਕਾ ਨਿਭਾ ਰਹੀ ਹੈ. ਰਾਊਟਰ ਉਦਾਹਰਨ ਵਿੱਚ ਇਹ ਸਿਰਫ਼ ਵਰਗੀਕਰਤਾ ਦੀ ਭੂਮਿਕਾ ਨਿਭਾ ਰਹੀ ਸੀ ਅਤੇ ਬਾਕੀ ਕੰਮ ਸਾਫ਼ਟਵੇਅਰ ਕਰਦਾ ਸੀ.

ਜਿੱਥੇ ਸੰਭਵ ਹੋਵੇ, ਅਸੀਂ ਰਾਊਟਰ-ਅਧਾਰਿਤ ਪਹੁੰਚ ਵਰਤਣ ਦੀ ਸਿਫ਼ਾਰਸ਼ ਕਰਦੇ ਹਾਂ, ਕਿਉਂਕਿ ਇਸਦੇ ਹੇਠ ਲਿਖੇ ਫ਼ਾਇਦੇ ਹਨ:

• ਗਤੀ ਅਤੇ ਕੁਸ਼ਲਤਾ: ਬਾਹਰੀ API ਉੱਤੇ ਨਿਰਭਰ ਆਰਕੇਸਟ੍ਰੇਟਰਾਂ ਦੇ ਮੁਕਾਬਲੇ ਸਥਾਨਕ ਗਣਨਾਵਾਂ ਵਧੇਰੇ ਤੇਜ਼ ਹੁੰਦੀਆਂ ਹਨ. ਆਪਣੇ “IF/ELSE” ਤਰਕ ਨੂੰ Python ਵਿੱਚ ਚਲਾਉਣਾ ਵੀ ਕਿਸੇ LLM ਪ੍ਰਦਾਤਾ ਨੂੰ ਇਸਦੇ 400 ਅਰਬ ਪੈਰਾਮੀਟਰਾਂ ਵਾਲੇ ਮਾਡਲ ਰਾਹੀਂ ਚਲਾਉਣ ਲਈ ਭੁਗਤਾਨ ਕਰਨ ਨਾਲੋਂ ਕਾਫ਼ੀ ਸਸਤਾ ਹੈ.

• ਜਾਂਚਯੋਗਤਾ ਅਤੇ ਪੂਰਵ-ਅਨੁਮਾਨਯੋਗਤਾ: ਸਥਾਪਤ ਸਾਫ਼ਟਵੇਅਰ ਅਭਿਆਸਾਂ ਰਾਹੀਂ ਗ਼ਲਤੀਆਂ ਲੱਭਣਾ, ਜਾਂਚ ਕਰਨਾ ਅਤੇ ਰੱਖ-ਰਖਾਅ ਕਰਨਾ ਕਾਫ਼ੀ ਸੌਖਾ ਹੁੰਦਾ ਹੈ.

• ਪਾਰਦਰਸ਼ਤਾ ਅਤੇ ਭਰੋਸੇਯੋਗਤਾ: ਵਿਹਾਰ ਵਿੱਚ ਘੱਟ ਭਿੰਨਤਾ ਨਾਲ ਸਮੱਸਿਆਵਾਂ ਦਾ ਹੱਲ ਸੌਖਾ ਹੋ ਜਾਂਦਾ ਹੈ. ਐਪਲੀਕੇਸ਼ਨ ਦੇ ਪ੍ਰਵਾਹ ਦਾ ਵੱਡਾ ਹਿੱਸਾ ਵੀ LLM ਦੇ ਅਪਾਰਦਰਸ਼ੀ ਅਤੇ ਨਾ ਸਮਝ ਆਉਣ ਵਾਲੇ ਭਾਰਾਂ ਦੀ ਬਜਾਏ ਪਾਰਦਰਸ਼ੀ, ਸੰਸਕਰਣ-ਨਿਯੰਤਰਿਤ ਸਾਫ਼ਟਵੇਅਰ ਵਿੱਚ ਦਰਸਾਇਆ ਜਾਂਦਾ ਹੈ.

ਰਾਊਟਰ ਪਹੁੰਚਾਂ ਦੀਆਂ ਕਮੀਆਂ ਇਹ ਹਨ ਕਿ ਇਹ ਸਖ਼ਤ ਅਤੇ ਘੱਟ ਲਚਕਦਾਰ ਹੋ ਸਕਦੀਆਂ ਹਨ ਅਤੇ ਵਧੇਰੇ ਖੁੱਲ੍ਹੀਆਂ ਸਮੱਸਿਆਵਾਂ ਨਾਲ ਨਜਿੱਠਣ ਵਿੱਚ ਮੁਸ਼ਕਲ ਮਹਿਸੂਸ ਕਰ ਸਕਦੀਆਂ ਹਨ. ਹਮੇਸ਼ਾ ਬਿਲਕੁਲ ਇੱਕੋ ਜਿਹੇ ਜਵਾਬ ਦੇਣ ਵਾਲੇ ਚੈਟਬੋਟ ਨੂੰ ਇਸਦੇ ਉਪਭੋਗਤਾ ਨੀਰਸ ਜਾਂ ਖੜੋਤ ਦਾ ਸ਼ਿਕਾਰ ਮੰਨ ਸਕਦੇ ਹਨ.

ਆਰਕੇਸਟ੍ਰੇਟਰ ਡਿਜ਼ਾਈਨਾਂ ਵਿੱਚ ਸ਼ਕਤੀਸ਼ਾਲੀ ਸਮਰੱਥਾਵਾਂ ਹੁੰਦੀਆਂ ਹਨ:

1. ਯੋਜਨਾਬੰਦੀ: ਇਹ ਗਤੀਸ਼ੀਲ ਢੰਗ ਨਾਲ ਜਵਾਬਾਂ ਦੀ ਯੋਜਨਾ ਬਣਾ ਸਕਦੇ ਹਨ.

2. ਔਜ਼ਾਰ ਦੀ ਚੋਣ/ਏਜੰਟ ਨੂੰ ਸੌਂਪਣਾ: ਢੁਕਵੇਂ ਔਜ਼ਾਰ ਚੁਣਦੇ ਜਾਂ ਕੰਮ ਏਜੰਟਾਂ ਨੂੰ ਸੌਂਪਦੇ ਹਨ.

3. ਨਤੀਜਿਆਂ ਦਾ ਦੁਹਰਾਓ-ਅਧਾਰਿਤ ਸੁਮੇਲ: ਨਤੀਜਿਆਂ ਨੂੰ ਰਚਨਾਤਮਕ ਢੰਗ ਨਾਲ ਵਾਰ-ਵਾਰ ਸੁਧਾਰਦੇ ਅਤੇ ਮੁੜ ਜੋੜਦੇ ਹਨ.

4. ਪੂਰਾ ਹੋਣ ਦਾ ਨਿਰਧਾਰਨ: ਇਹ ਨਿਰਧਾਰਤ ਕਰਦੇ ਹਨ ਕਿ ਜਵਾਬ ਨੂੰ ਅੰਤਿਮ ਰੂਪ ਦੇਣ ਲਈ ਲੋੜੀਂਦੀ ਜਾਣਕਾਰੀ ਕਦੋਂ ਇਕੱਠੀ ਹੋ ਚੁੱਕੀ ਹੈ.

Pydantic-AI ਜਾਂ OpenAI ਦੇ Agents SDK ਵਰਗੇ ਢਾਂਚਿਆਂ ਨਾਲ ਆਰਕੇਸਟ੍ਰੇਸ਼ਨ ਨੂੰ ਲਾਗੂ ਕਰਨਾ ਸਰਲ ਅਤੇ ਤੇਜ਼ ਹੋ ਜਾਂਦਾ ਹੈ. ਇਸ ਕਰਕੇ ਇਹ ਪ੍ਰਦਰਸ਼ਨਾਂ ਜਾਂ ਸੰਕਲਪ ਦੇ ਸਬੂਤਾਂ ਲਈ ਬਹੁਤ ਵਧੀਆ ਹੈ.

ਇਸ ਪਹੁੰਚ ਦੀਆਂ ਕਮੀਆਂ ਇਹ ਹਨ:

• ਇਸਦੀ ਕੋਈ ਗਾਰੰਟੀ ਨਹੀਂ ਕਿ LLM ਦੀ ਯੋਜਨਾਬੰਦੀ ਦੇ ਪੜਾਅ ਅਤੇ ਉਨ੍ਹਾਂ ਤੋਂ ਬਾਅਦ ਦੀਆਂ ਕਾਰਵਾਈਆਂ ਸਹੀ ਜਾਂ ਢੁਕਵੀਆਂ ਹੋਣਗੀਆਂ. ਰਾਊਟਰ ਸਿਸਟਮ ਵਿੱਚ ਵੀ ਇਹੀ ਸਮੱਸਿਆ ਹੈ, ਪਰ ਵਧੇਰੇ ਪਾਬੰਦੀਆਂ ਕਾਰਨ ਇਸਦਾ ਵਿਹਾਰ ਜ਼ਿਆਦਾ ਪੂਰਵ-ਅਨੁਮਾਨਯੋਗ ਹੁੰਦਾ ਹੈ.

• ਸਰਲ ਅਤੇ ਚੰਗੀ ਤਰ੍ਹਾਂ ਪਰਿਭਾਸ਼ਿਤ ਕੰਮਾਂ ਲਈ ਸਾਨੂੰ ਬਹੁ-ਏਜੰਟ ਸਿਸਟਮ ਦੀ ਪੂਰੀ ਸਮਰੱਥਾ ਦੀ ਲੋੜ ਸ਼ਾਇਦ ਨਾ ਹੋਵੇ. ਮਿਸਾਲ ਵਜੋਂ, ਸਾਡੀ ਹਵਾਈ ਯਾਤਰਾ ਏਜੰਟ ਦੀ ਉਦਾਹਰਨ ਵਿੱਚ ਸ਼ਾਇਦ ਸਵਾਲਾਂ ਦੀਆਂ ਕੁਝ ਸੀਮਤ ਕਿਸਮਾਂ ਹੀ ਹਨ, ਜਿਨ੍ਹਾਂ ਬਾਰੇ ਕੋਈ ਵਿਅਕਤੀ ਹਵਾਈ ਕੰਪਨੀ ਦੇ ਸਹਾਇਤਾ ਸਿਸਟਮ ਨਾਲ ਗੱਲ ਕਰਨਾ ਚਾਹੇਗਾ.

• ਕਿਉਂਕਿ ਵਧੇਰੇ ਤਰਕ LLM ਵਿੱਚ ਹੁੰਦਾ ਹੈ, ਇਸ ਲਈ ਮਾੜੀ ਨੀਅਤ ਵਾਲੇ ਲੋਕ ਇਸਨੂੰ ਹੋਰ ਆਸਾਨੀ ਨਾਲ ਜੇਲ੍ਹਬ੍ਰੇਕ ਕਰ ਸਕਦੇ ਜਾਂ ਇਸਦਾ ਨਾਜਾਇਜ਼ ਫ਼ਾਇਦਾ ਉਠਾ ਸਕਦੇ ਹਨ.

• ਇਹ ਫ਼ੈਸਲਾ ਲੈਣ ਦੀ ਪ੍ਰਕਿਰਿਆ ਨੂੰ LLM ਵਿੱਚ ਲੁਕਾ ਦਿੰਦਾ ਹੈ ਅਤੇ ਇਸ ਲਈ ਤੁਹਾਡੇ ਸਿਸਟਮ ਨੂੰ ਸਮਝਣਾ ਔਖਾ ਬਣ ਜਾਂਦਾ ਹੈ, ਹਾਲਾਂਕਿ Langfuse ਜਾਂ Braintrust ਵਰਗੇ ਨਿਗਰਾਨੀ ਔਜ਼ਾਰ ਇਸ ਵਿੱਚ ਕੁਝ ਮਦਦ ਕਰ ਸਕਦੇ ਹਨ.

ਪਾਠਕਾਂ ਲਈ ਨੋਟ: ਭਾਵੇਂ ਮਾਡਲ ਦੀ ਸਮਰੱਥਾ ਤੇਜ਼ੀ ਨਾਲ ਬਦਲ ਰਹੀ ਹੈ, ਪਰ ਹੇਠਾਂ ਦਿੱਤੇ ਨੁਕਤੇ ਨੇੜਲੇ ਭਵਿੱਖ ਵਿੱਚ ਬਦਲਣ ਦੀ ਸੰਭਾਵਨਾ ਨਹੀਂ ਹੈ.

ਆਪਣੀ ਸਮੱਸਿਆ ਦਾ ਦਾਇਰਾ ਨਿਰਧਾਰਤ ਕਰੋ.

• ਕੀ ਤੁਸੀਂ ਆਪਣੇ ਲੋੜੀਂਦੇ ਫ਼ੈਸਲਾ ਤਰਕ ਨੂੰ ਚਿੱਤਰ ਵਿੱਚ ਆਸਾਨੀ ਨਾਲ ਪਰਿਭਾਸ਼ਿਤ ਕਰ ਸਕਦੇ ਹੋ?

• ਕੀ ਤੁਹਾਡੀ ਐਪਲੀਕੇਸ਼ਨ ਵਿੱਚ ਅਸਫਲਤਾ ਜਾਂ ਅਚਾਨਕ ਵਿਹਾਰ ਬਿਲਕੁਲ ਵੀ ਸਵੀਕਾਰਯੋਗ ਨਹੀਂ ਹੈ?

ਉਪਰੋਕਤ ਵਿੱਚੋਂ ਕਿਸੇ ਇੱਕ ਦਾ ਜਵਾਬ “ਹਾਂ” ਹੋਵੇ ਤਾਂ ਰਾਊਟਰ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਬਿਹਤਰ ਰਹਿਣਗੀਆਂ.

ਜਿੱਥੋਂ ਤੱਕ ਸੰਭਵ ਹੋਵੇ, ਅਸੀਂ ਰਾਊਟਰ ਪਹੁੰਚਾਂ ਵਰਤਣ ਦੀ ਸਿਫ਼ਾਰਸ਼ ਕਰਦੇ ਹਾਂ. ਆਮ ਸਿਧਾਂਤ ਇਹ ਹੈ ਕਿ ਜੇ ਤੁਹਾਡੇ ਸਿਸਟਮ ਦਾ ਕੋਈ ਹਿੱਸਾ ਕੋਡ ਵਿੱਚ ਦਰਸਾਇਆ ਜਾ ਸਕਦਾ ਹੈ, ਤਾਂ ਉਸਨੂੰ ਕੋਡ ਵਿੱਚ ਹੀ ਦਰਸਾਓ. ਭਾਵ, ਲੋੜ ਨਾ ਹੋਣ ਉੱਤੇ LLM ਦੀ ਹੱਦੋਂ ਵੱਧ ਵਰਤੋਂ ਨਾ ਕਰੋ.

ਜਦੋਂ ਇਨ੍ਹਾਂ ਦੀਆਂ ਹੱਦਾਂ ਆ ਜਾਂਦੀਆਂ ਹਨ, ਤਾਂ ਆਰਕੇਸਟ੍ਰੇਟਰ ਦੇ ਕੁਝ ਖੁੱਲ੍ਹੇ ਫ਼ਾਇਦਿਆਂ ਨੂੰ ਸੀਮਤ ਢੰਗ ਨਾਲ ਦੁਹਰਾਇਆ ਜਾ ਸਕਦਾ ਹੈ. ਮਿਸਾਲ ਵਜੋਂ:

1. ਔਜ਼ਾਰ ਦੀ ਚੋਣ/ਏਜੰਟ ਨੂੰ ਸੌਂਪਣਾ: ਸ਼ਰਤ-ਅਧਾਰਿਤ ਸ਼ਾਖਾਵਾਂ ਜਾਂ LLM ਵਰਗੀਕਰਤਾਵਾਂ ਰਾਹੀਂ ਆਸਾਨੀ ਨਾਲ ਲਾਗੂ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ.

2. ਪੂਰਾ ਹੋਣ ਦਾ ਨਿਰਧਾਰਨ: ਸਰਲ LLM ਵਰਗੀਕਰਤਾ ਉਪਭੋਗਤਾ ਨੂੰ ਜਵਾਬ ਭੇਜਣ ਤੋਂ ਪਹਿਲਾਂ ਇਸਦੀ ਸੰਪੂਰਨਤਾ ਦੀ ਜਾਂਚ ਕਰ ਸਕਦੇ ਹਨ.

ਹਾਲਾਂਕਿ ਸਖ਼ਤ ਰਾਊਟਰ ਸਿਸਟਮ ਵਿੱਚ “ਯੋਜਨਾਬੰਦੀ” ਅਤੇ “ਨਤੀਜਿਆਂ ਦਾ ਦੁਹਰਾਓ-ਅਧਾਰਿਤ ਸੁਮੇਲ” ਹਾਸਲ ਕਰਨਾ ਬਿਨਾਂ ਸ਼ੱਕ ਕਾਫ਼ੀ ਔਖਾ ਹੈ. ਇਸ ਲਈ ਜਦੋਂ ਕਿਸੇ ਕੰਮ ਨੂੰ ਇਨ੍ਹਾਂ ਦੀ ਲੋੜ ਹੋਵੇ, ਜਿਸਦਾ ਨਿਰਧਾਰਨ LLM ਵਰਗੀਕਰਤਾ ਜਾਂ ਕਿਸੇ ਹੋਰ ਤਰਕ ਨਾਲ ਕੀਤਾ ਗਿਆ ਹੋਵੇ, ਤਾਂ ਅਸੀਂ ਤੁਹਾਡੇ ਸਿਸਟਮ ਵਿੱਚ ਘੱਟ ਪਾਬੰਦੀਆਂ ਵਾਲੀ ਆਰਕੇਸਟ੍ਰੇਟਰ ਸ਼ਾਖਾ ਬਣਾਉਣ ਦਾ ਸੁਝਾਅ ਦਿੰਦੇ ਹਾਂ.

ਰਾਊਟਰ ਅਤੇ ਆਰਕੇਸਟ੍ਰੇਟਰ ਬਣਤਰਾਂ ਵਿਚਕਾਰ ਤੁਹਾਡੀ ਚੋਣ ਐਪਲੀਕੇਸ਼ਨ ਦੀ ਸਪਸ਼ਟਤਾ, ਜਟਿਲਤਾ ਅਤੇ ਗੱਲਬਾਤ ਦੀ ਸ਼ੈਲੀ ਮੁਤਾਬਕ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ. ਇਸ ਵੇਲੇ ਰਾਊਟਰ-ਅਧਾਰਿਤ ਪਹੁੰਚਾਂ ਸਪਸ਼ਟ ਤੌਰ ਉੱਤੇ ਪਰਿਭਾਸ਼ਿਤ ਕੰਮਾਂ ਲਈ ਭਰੋਸੇਯੋਗਤਾ, ਕੁਸ਼ਲਤਾ ਅਤੇ ਜਾਂਚ ਦੀ ਸੌਖ ਪ੍ਰਦਾਨ ਕਰਦੀਆਂ ਹਨ. ਆਰਕੇਸਟ੍ਰੇਟਰ ਵਿਆਪਕ, ਗੱਲਬਾਤ-ਅਧਾਰਿਤ ਸੰਪਰਕਾਂ ਲਈ ਬਿਹਤਰ ਲਚਕ ਪ੍ਰਦਾਨ ਕਰਦੇ ਹਨ.

LLM ਦੀ ਤਰੱਕੀ ਜਾਰੀ ਰਹਿਣ ਨਾਲ ਇਨ੍ਹਾਂ ਪਹੁੰਚਾਂ ਵਿਚਲਾ ਸੰਤੁਲਨ ਬਦਲ ਸਕਦਾ ਹੈ. ਉਤਪਾਦਨ ਕਾਰਜ-ਭਾਰਾਂ ਲਈ ਅਸੀਂ ਰਾਊਟਰ-ਅਧਾਰਿਤ ਜਾਂ ਮਿਲੀਆਂ-ਜੁਲੀਆਂ ਬਣਤਰਾਂ ਨੂੰ ਤਰਜੀਹ ਦਿੰਦੇ ਹਾਂ ਅਤੇ ਆਰਕੇਸਟ੍ਰੇਟਰਾਂ ਨੂੰ ਉਨ੍ਹਾਂ ਖੁੱਲ੍ਹੀਆਂ ਸਮੱਸਿਆਵਾਂ ਲਈ ਰਾਖਵਾਂ ਰੱਖਦੇ ਹਾਂ ਜਿਨ੍ਹਾਂ ਵਿੱਚ ਗਤੀਸ਼ੀਲ, ਮਨੁੱਖੀ ਅੰਦਾਜ਼ ਵਾਲੇ ਸੰਪਰਕ ਦੀ ਲੋੜ ਹੋਵੇ.