ਐਮਸੀਪੀ: ਕਮੀਆਂ ਅਤੇ ਸੰਭਾਵਨਾਵਾਂ ਦੀ ਜਾਂਚ

ਐਮਸੀਪੀ: ਕਮੀਆਂ ਅਤੇ ਸੰਭਾਵਨਾਵਾਂ ਦੀ ਜਾਂਚ

ਐਮਸੀਪੀ ਦੀਆਂ ਜ਼ਿੰਮੇਵਾਰੀਆਂ ਦਾ ਓਵਰਲੋਡ

ਇੱਕ ਆਮ ਆਲੋਚਨਾ ਇਹ ਹੈ ਕਿ ਐਮਸੀਪੀ ਨੂੰ ਬਹੁਤ ਜ਼ਿਆਦਾ ਜ਼ਿੰਮੇਵਾਰੀ ਸੌਂਪੀ ਜਾ ਰਹੀ ਹੈ। ਲੇਖਕ ਦਾ ਤਰਕ ਹੈ ਕਿ ਐਮਸੀਪੀ ਨੂੰ ਮੁੱਖ ਤੌਰ ‘ਤੇ ਐਲਐਲਐਮਜ਼ ਲਈ ਬਾਹਰੀ ਸਰੋਤਾਂ ਤੱਕ ਪਹੁੰਚਣ ਅਤੇ ਗੱਲਬਾਤ ਕਰਨ ਲਈ ਇੱਕ ਗੇਟਵੇ ਵਜੋਂ ਕੰਮ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ। ਇਸਨੂੰ ਸਿਰਫ਼ ਇੱਕ ‘ਦਰਵਾਜ਼ਾ’ ਜਾਂ ‘ਪੁਲ’ ਵਜੋਂ ਵੇਖਣਾ ਇਸਦੇ ਉਦੇਸ਼ ਅਤੇ ਸੀਮਾਵਾਂ ਨੂੰ ਸਪੱਸ਼ਟ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ।

ਦੁਰਘਟਨਾਤਮਕ ਡੇਟਾ ਐਕਸਪੋਜ਼ਰ, ਪ੍ਰੋਂਪਟ ਇੰਜੈਕਸ਼ਨ ਕਮਜ਼ੋਰੀਆਂ ਅਤੇ ਲਾਗਤ ਨਿਯੰਤਰਣ ਦੀਆਂ ਕਮੀਆਂ ਵਰਗੇ ਮੁੱਦਿਆਂ ਨੂੰ ਸਿੱਧੇ ਤੌਰ ‘ਤੇ ਐਮਸੀਪੀ ਨੂੰ ਜ਼ਿੰਮੇਵਾਰ ਠਹਿਰਾਉਣਾ ਦੋਸ਼ ਦੀ ਗਲਤ ਥਾਂ ਹੈ। ਇਹ ਉਹ ਸਮੱਸਿਆਵਾਂ ਹਨ ਜਿਨ੍ਹਾਂ ਨੂੰ ਡਿਵੈਲਪਰਾਂ ਨੂੰ ਉਹਨਾਂ ਸੀਮਾਵਾਂ ਦੇ ਅੰਦਰ ਹੱਲ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ ਜਿਨ੍ਹਾਂ ਨੂੰ ਉਹ ਨਿਯੰਤਰਿਤ ਕਰਦੇ ਹਨ। ਡਿਵੈਲਪਰਾਂ ਨੂੰ ਦਰਾਂ ਦੀਆਂ ਸੀਮਾਵਾਂ ਨੂੰ ਲਾਗੂ ਕਰਨ ਅਤੇ ਵਰਤੋਂ ਦੀ ਨਿਗਰਾਨੀ ਕਰਨ ਦੀ ਲੋੜ ਹੈ, ਭਾਵੇਂ ਕੋਈ ਵੀ ਪ੍ਰੋਟੋਕੋਲ ਵਰਤਿਆ ਜਾਵੇ। ਇਸ ਨੂੰ ਸਪੀਡਿੰਗ ਲਈ ਸੜਕ ਨੂੰ ਦੋਸ਼ ਦੇਣ ਦੇ ਬਰਾਬਰ ਕਰਨਾ ਢੁਕਵਾਂ ਹੈ - ਬੁਨਿਆਦੀ ਢਾਂਚਾ ਵਿਅਕਤੀਗਤ ਵਿਵਹਾਰ ਲਈ ਜ਼ਿੰਮੇਵਾਰ ਨਹੀਂ ਹੈ।

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

ਐਲਐਲਐਮਜ਼ ਅਤੇ ਪ੍ਰੋਂਪਟ ਇੰਜੈਕਸ਼ਨ ਦੀ ਦੋਹਰੀ ਤਲਵਾਰ

ਐਮਸੀਪੀ ਦੇ ਆਲੇ ਦੁਆਲੇ ਦੀਆਂ ਤਾਜ਼ਾ ਵਿਚਾਰਾਂ ਅਕਸਰ ਤਿੱਖੇ ਚਾਕੂਆਂ ਦੇ ਅੰਦਰੂਨੀ ਖ਼ਤਰਿਆਂ ਬਾਰੇ ਚੇਤਾਵਨੀਆਂ ਵਰਗੀਆਂ ਹੁੰਦੀਆਂ ਹਨ - ਜੇਕਰ ਗਲਤ ਤਰੀਕੇ ਨਾਲ ਸੰਭਾਲਿਆ ਜਾਵੇ ਤਾਂ ਉਹ ਕੱਟ ਸਕਦੇ ਹਨ। ਪ੍ਰੋਂਪਟ ਇੰਜੈਕਸ਼ਨ, ਇੱਕ ਮਹੱਤਵਪੂਰਨ ਚਿੰਤਾ, ਐਲਐਲਐਮਜ਼ ਦੇ ਸੁਭਾਅ ਦਾ ਨਤੀਜਾ ਹੈ। ਪ੍ਰੋਂਪਟ ਇੰਜੈਕਸ਼ਨ ਨੂੰ ਖਤਮ ਕਰਨ ਦੀਆਂ ਕੋਸ਼ਿਸ਼ਾਂ ਉਹਨਾਂ ਸਮਰੱਥਾਵਾਂ ਨੂੰ ਘਟਾ ਦਿੰਦੀਆਂ ਹਨ ਜੋ ਐਲਐਲਐਮਜ਼ ਨੂੰ ਕੀਮਤੀ ਬਣਾਉਂਦੀਆਂ ਹਨ।

‘ਕੰਟਰੋਲ ਬਨਾਮ ਡੇਟਾ’ ਵੱਖ ਕਰਨ ਦਾ ਵਿਚਾਰ, ਜੋ ਕਿ ਰਵਾਇਤੀ ਪ੍ਰਣਾਲੀਆਂ ਵਿੱਚ ਆਮ ਹੈ, ਐਲਐਲਐਮਜ਼ ਵਿੱਚ ਕੁਦਰਤੀ ਤੌਰ ‘ਤੇ ਮੌਜੂਦ ਨਹੀਂ ਹੈ। ਐਲਐਲਐਮਜ਼ ਆਪਣੀ ਸ਼ਕਤੀ ਅਤੇ ਆਮਤਾ ਇਸ ਲਈ ਪ੍ਰਾਪਤ ਕਰਦੇ ਹਨ ਕਿਉਂਕਿ ਉਹਨਾਂ ਵਿੱਚ ਇਹ ਸਖ਼ਤ ਵੱਖਰਾਵ ਨਹੀਂ ਹੁੰਦਾ ਹੈ। ਇਹ ਅੰਦਰੂਨੀ ਵਿਸ਼ੇਸ਼ਤਾ ਉਹਨਾਂ ਨੂੰ ਪ੍ਰੋਂਪਟ ਇੰਜੈਕਸ਼ਨ ਹਮਲਿਆਂ ਲਈ ਕਮਜ਼ੋਰ ਬਣਾਉਂਦੀ ਹੈ।

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

‘ਸਾਵਧਾਨ ਰਹੋ’ ਜਾਂ ਸੁਰੱਖਿਆ ਗੀਅਰ ਦੇ ਸੁਝਾਵਾਂ ਨੂੰ ਮੰਨਣਾ, ਤਕਨੀਕੀ ਤੌਰ ‘ਤੇ ਸਹੀ ਹੋਣ ਦੇ ਬਾਵਜੂਦ, ਮੁੱਖ ਮੁੱਦੇ ਤੋਂ ਖੁੰਝ ਜਾਂਦਾ ਹੈ: ਇੱਕ ਤਿੱਖੇ ਸੰਦ ਨੂੰ ਇੱਕ ਅਨਿਯੰਤਰਿਤ ਸਿਸਟਮ ਨਾਲ ਜੋੜਨ ਦਾ ਗਲਤ ਫੈਸਲਾ।

ਸਕੇਲੇਬਿਲਟੀ ਚੁਣੌਤੀਆਂ

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

ਲੇਖਕ ਜ਼ੋਰ ਦਿੰਦਾ ਹੈ ਕਿ ਐਮਸੀਪੀ ਇੱਕ ਖਾਸ ਥ੍ਰੈਸ਼ਹੋਲਡ ਤੋਂ ਪਰੇ ਨਹੀਂ ਵਧਦਾ। ਕਿਸੇ ਏਜੰਟ ਦੇ ਸੰਦਰਭ ਵਿੱਚ ਅਸੀਮਤ ਸੰਖਿਆ ਵਿੱਚ ਟੂਲ ਜੋੜਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਨ ਨਾਲ ਇਸਦੀਆਂ ਸਮਰੱਥਾਵਾਂ ‘ਤੇ ਅਟੱਲ ਤੌਰ ‘ਤੇ ਨਕਾਰਾਤਮਕ ਪ੍ਰਭਾਵ ਪਵੇਗਾ। ਇਹ ਸੀਮਾ ਐਮਸੀਪੀ ਦੀ ਧਾਰਨਾ ਲਈ ਅੰਦਰੂਨੀ ਹੈ ਅਤੇ ਇਸ ਲਈ ਪ੍ਰਮਾਣੀਕਰਨ ਮੁੱਦਿਆਂ ਨਾਲੋਂ ਵਧੇਰੇ ਧਿਆਨ ਦੇਣ ਦੀ ਲੋੜ ਹੈ।

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

ਐਮਸੀਪੀ ਨਾਲ ਮੁੱਖ ਸਮੱਸਿਆ ਇਹ ਹੈ ਕਿ ਇਸਦਾ ਅਸਲ ਵਿਵਹਾਰ ਉਪਭੋਗਤਾ ਦੀਆਂ ਉਮੀਦਾਂ ਤੋਂ ਭਟਕ ਜਾਂਦਾ ਹੈ। ਇਹ ਮੰਨਣਾ ਮਹੱਤਵਪੂਰਨ ਹੈ ਕਿ ਐਮਸੀਪੀ ਇੱਕ ਪਲੱਗ-ਐਂਡ-ਪਲੇ ਹੱਲ ਨਹੀਂ ਹੈ ਜੋ ਨਤੀਜਿਆਂ ਤੋਂ ਬਿਨਾਂ ਅਸੀਮਤ ਸੰਖਿਆ ਵਿੱਚ ਟੂਲ ਨੂੰ ਸਹਿਜੇ ਹੀ ਜੋੜਦਾ ਹੈ।

UI ਅਤੇ ਟੂਲ ਪ੍ਰਬੰਧਨ ਨਾਲ ਸੀਮਾਵਾਂ ਨੂੰ ਸੰਬੋਧਿਤ ਕਰਨਾ

ਐਮਸੀਪੀ ਦੀਆਂ ਸੀਮਾਵਾਂ ਦਾ ਇੱਕ ਪ੍ਰਸਤਾਵਿਤ ਹੱਲ ਉਪਭੋਗਤਾ ਇੰਟਰਫੇਸ ਨੂੰ ਬਿਹਤਰ ਬਣਾਉਣਾ ਹੈ। ਜੇਕਰ ਕੋਈ ਟੂਲ ਅਣਜਾਣੇ ਵਿੱਚ ਚਲਾਇਆ ਜਾਂਦਾ ਹੈ, ਤਾਂ UI ਨੂੰ ਇਸਨੂੰ ਅਯੋਗ ਕਰਨ ਜਾਂ ਇਸਦੇ ਇਰਾਦੇ ਵਾਲੇ ਵਰਤੋਂ ਨੂੰ ਸਪੱਸ਼ਟ ਕਰਨ ਲਈ ਇਸਦੇ ਵਰਣਨ ਨੂੰ ਸੋਧਣ ਦਾ ਇੱਕ ਆਸਾਨ ਤਰੀਕਾ ਪ੍ਰਦਾਨ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ।

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

ਟੂਲ ਦੀ ਵੱਡੀ ਚੋਣ ਨੂੰ ਹੱਲ ਕਰਨ ਲਈ, ਇੱਕ ‘ਵੰਡ ਅਤੇ ਜਿੱਤ’ ਪਹੁੰਚ ਦਾ ਸੁਝਾਅ ਦਿੱਤਾ ਗਿਆ ਹੈ। ਇਸ ਵਿੱਚ ਇੱਕ ਦਿੱਤੇ ਕੰਮ ਲਈ ਸਭ ਤੋਂ ਢੁਕਵੇਂ ਟੂਲ ਚੁਣਨ ਲਈ ਵਿਸ਼ੇਸ਼ ਤੌਰ ‘ਤੇ ਤਿਆਰ ਕੀਤਾ ਗਿਆ ਇੱਕ ਟੂਲ ਜੋੜਨਾ ਸ਼ਾਮਲ ਹੈ। ਇਹ ‘ਟੂਲ-ਚੁਣਨ ਵਾਲਾ ਟੂਲ’ ਇੱਕ ਹੋਰ ਐਲਐਲਐਮ ਕਾਲ ਹੋ ਸਕਦੀ ਹੈ, ਜਿਸ ਨੂੰ ‘ਮੂਲ’ ਏਜੰਟ ਲਈ ਉਪਲਬਧ ਟੂਲ ਦਾ ਇੱਕ ਉਪ ਸਮੂਹ ਵਾਪਸ ਕਰਨ ਦਾ ਕੰਮ ਸੌਂਪਿਆ ਜਾਂਦਾ ਹੈ। ਇਹ ਲੇਅਰਡ ਪਹੁੰਚ ਗੁੰਝਲਤਾ ਦਾ ਪ੍ਰਬੰਧਨ ਕਰਨ ਲਈ ਅਸਿੱਧੇ ਪੱਧਰਾਂ ਨੂੰ ਜੋੜਦੀ ਹੈ।

ਹਾਲਾਂਕਿ, ਸੰਦਰਭ ਵਿੱਚ ਸਿਰਫ਼ ਟੂਲ ਹੋਣ ਨਾਲ ਮਾਡਲ ਦੇ ਆਉਟਪੁੱਟ ਨੂੰ ਮਹੱਤਵਪੂਰਨ ਤੌਰ ‘ਤੇ ਬਦਲਿਆ ਜਾ ਸਕਦਾ ਹੈ। ਜਦੋਂ ਕਿ ਸੰਦਰਭਿਕ ਤੌਰ ‘ਤੇ ਢੁਕਵੇਂ ਟੂਲ (ਰਿਟਰੀਵਲ-ਆਗਮੈਂਟਡ ਜਨਰੇਸ਼ਨ ਜਾਂ RAG ਵਰਗੀਆਂ ਤਕਨੀਕਾਂ ਦੁਆਰਾ ਪ੍ਰਾਪਤ ਕੀਤੇ ਗਏ) ਲਾਭਦਾਇਕ ਹਨ, ਇੱਕ ‘get_tools’ ਬੇਨਤੀ ਦੇ ਪਿੱਛੇ ਸਾਰੇ ਟੂਲ ਨੂੰ ਛੁਪਾਉਣਾ ਨੁਕਸਾਨਦੇਹ ਹੋ ਸਕਦਾ ਹੈ।

ਐਮਸੀਪੀ ਇੱਕ ਟ੍ਰਾਂਸਪੋਰਟ ਅਤੇ ਅਧਿਕਾਰ ਪਰਤ ਵਜੋਂ

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

ਲੇਖਕ ਦਾ ਮੰਨਣਾ ਹੈ ਕਿ ਐਮਸੀਪੀ ਪਹਿਲੀ ਥਾਂ ‘ਤੇ ਬੇਲੋੜੀ ਹੋ ਸਕਦੀ ਹੈ, ਕਿਉਂਕਿ ਐਲਐਲਐਮਜ਼ ਕੋਲ ਪਹਿਲਾਂ ਹੀ OpenAPI ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਦਸਤਾਵੇਜ਼ਿਤ API ਨਾਲ ਗੱਲਬਾਤ ਕਰਨ ਦੀ ਸਮਰੱਥਾ ਹੈ। ਗੁੰਮ ਤੱਤ ਅਧਿਕਾਰ ਹੈ - ਇਹ ਨਿਯੰਤਰਣ ਕਰਨ ਦੀ ਸਮਰੱਥਾ ਕਿ ਕਿਹੜੀਆਂ API ਤੱਕ ਇੱਕ AI ਪਹੁੰਚ ਕਰ ਸਕਦਾ ਹੈ। ਐਮਸੀਪੀ ਦੀ ਬਜਾਏ, ਲੇਖਕ ਸੁਝਾਅ ਦਿੰਦਾ ਹੈ ਕਿ AI ਨੂੰ HTTP ਬੇਨਤੀਆਂ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੱਤੀ ਜਾਵੇ ਜਦੋਂ ਕਿ ਖਾਸ ਅੰਤਮ ਬਿੰਦੂਆਂ ‘ਤੇ ਅਧਿਕਾਰ ਲਾਗੂ ਕੀਤਾ ਜਾਵੇ। ਇਹ ਪਹੁੰਚ ਮੌਜੂਦਾ APIs ਨੂੰ ਪਤਲੇ ਐਮਸੀਪੀ ਟੂਲ ਨਾਲ ਜੋੜਨ ਦੇ ਮੌਜੂਦਾ ਰੁਝਾਨ ਨਾਲ ਮੇਲ ਖਾਂਦੀ ਹੈ।

ਐਮਸੀਪੀ ਦਾ ਇੱਕ ਖਾਸ ਤੌਰ ‘ਤੇ ਤੰਗ ਕਰਨ ਵਾਲਾ ਪਹਿਲੂ ਸਟ੍ਰੀਮਿੰਗ ਟੂਲ ਕਾਲ ਨਤੀਜਿਆਂ ਲਈ ਇਸਦੀ ਸਹਾਇਤਾ ਦੀ ਘਾਟ ਹੈ। ਸਿੰਗਲ ਬੇਨਤੀ/ਜਵਾਬ ਜੋੜਾ ਗਾਹਕਾਂ ਨੂੰ ਪੇਜਨੇਸ਼ਨ ਲਈ ਵਾਰ-ਵਾਰ ਟੂਲ ਨੂੰ ਕਾਲ ਕਰਨ ਲਈ ਮਜਬੂਰ ਕਰਦਾ ਹੈ, ਲੰਬੇ ਸਮੇਂ ਤੋਂ ਚੱਲ ਰਹੀਆਂ ਪ੍ਰਕਿਰਿਆਵਾਂ ਵਿੱਚ ਰੁਕਾਵਟ ਪਾਉਂਦਾ ਹੈ। ਸਟ੍ਰੀਮਿੰਗ ਸਮਰੱਥਾ ਨੂੰ ਲਾਗੂ ਕਰਨਾ, ਸ਼ਾਇਦ gRPC ਦੀ ਵਰਤੋਂ ਕਰਕੇ, ਐਮਸੀਪੀ ਦੀ ਕੁਸ਼ਲਤਾ ਵਿੱਚ ਮਹੱਤਵਪੂਰਨ ਸੁਧਾਰ ਕਰ ਸਕਦਾ ਹੈ।

ਸੰਵੇਦਨਸ਼ੀਲ ਡੇਟਾ ਨੂੰ ਐਕਸਪੋਜ਼ ਕਰਨ ਦੀ ਸੌਖ

ਐਮਸੀਪੀ ਨਾਲ ਇੱਕ ਮਹੱਤਵਪੂਰਨ ਚਿੰਤਾ ਸੰਵੇਦਨਸ਼ੀਲ ਡੇਟਾ ਦੇ ਆਸਾਨ ਐਕਸਪੋਜ਼ਰ ਦੀ ਸੰਭਾਵਨਾ ਹੈ। ਇਸ ਤੋਂ ਇਲਾਵਾ, ਐਮਸੀਪੀ ਅੰਦਰੂਨੀ ਤੌਰ ‘ਤੇ AI ਏਜੰਟਾਂ ਨੂੰ ਵਧੇਰੇ ਭਰੋਸੇਯੋਗ ਨਹੀਂ ਬਣਾਉਂਦਾ; ਇਹ ਉਹਨਾਂ ਨੂੰ ਸਿਰਫ਼ ਹੋਰ ਸਾਧਨਾਂ ਤੱਕ ਪਹੁੰਚ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ, ਜੋ ਕੁਝ ਸਥਿਤੀਆਂ ਵਿੱਚ ਵਿਪਰੀਤ ਤੌਰ ‘ਤੇ ਭਰੋਸੇਯੋਗਤਾ ਨੂੰ ਘਟਾ ਸਕਦਾ ਹੈ।

ਲੇਖਕ ਮੰਨਦਾ ਹੈ ਕਿ ਉਹ ਇਹਨਾਂ ਸਾਰੇ ਮੁੱਦਿਆਂ ਨੂੰ ਹੱਲ ਕਰਨ ਜਾਂ ਜ਼ਿੰਮੇਵਾਰ ਹੋਣ ਲਈ ਐਮਸੀਪੀ ਤੋਂ ਉਮੀਦ ਨਹੀਂ ਕਰਦੇ ਹਨ। ਸਗੋਂ, ਐਮਸੀਪੀ ਇਹਨਾਂ ਸਮੱਸਿਆਵਾਂ ਲਈ ਇੱਕ ਵੱਡਾ ਸਤਹ ਖੇਤਰ ਬਣਾਉਂਦਾ ਹੈ, ਜਿਸ ਲਈ ਐਪ ਡਿਵੈਲਪਰਾਂ ਅਤੇ ਉਪਭੋਗਤਾਵਾਂ ਨੂੰ ਚੌਕਸ ਰਹਿਣ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ।

ਸਮਾਨਤਾਵਾਂ ਅਤੇ ਸ਼ਹਿਰੀ ਯੋਜਨਾਬੰਦੀ

ਲੇਖਕ ਮੁੱਦੇ ਨੂੰ ਦਰਸਾਉਣ ਲਈ ਸ਼ਹਿਰੀ ਯੋਜਨਾਬੰਦੀ ਦੀ ਸਮਾਨਤਾ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ। ਐਮਸੀਪੀ ਦੀ ਤੁਲਨਾ 25mph ਸਪੀਡ ਸੀਮਾ ਵਾਲੀ ਛੇ-ਲੇਨ ਸ਼ਹਿਰ ਦੀ ਸੜਕ ਨਾਲ ਕਰਨ ਨਾਲ ਡਿਜ਼ਾਈਨ ਅਤੇ ਇਰਾਦੇ ਵਾਲੇ ਵਰਤੋਂ ਵਿਚਕਾਰ ਡਿਸਕਨੈਕਟ ਨੂੰ ਉਜਾਗਰ ਕੀਤਾ ਗਿਆ ਹੈ। ਸਿਰਫ਼ ਜੁਰਮਾਨੇ ਲਗਾਉਣ ਜਾਂ ਉਪਰਲੇ ‘ਫਿਕਸ’ ਜੋੜਨ ਨਾਲ ਮਾੜੇ ਡਿਜ਼ਾਈਨ ਦੀ ਅੰਤਰੀਵ ਸਮੱਸਿਆ ਦਾ ਹੱਲ ਨਹੀਂ ਹੁੰਦਾ ਹੈ।

ਪ੍ਰਭਾਵੀ ਸ਼ਹਿਰੀ ਯੋਜਨਾਬੰਦੀ ਵਿੱਚ ਸੜਕਾਂ ਨੂੰ ਡਿਜ਼ਾਈਨ ਕਰਨਾ ਸ਼ਾਮਲ ਹੁੰਦਾ ਹੈ ਜੋ ਕੁਦਰਤੀ ਤੌਰ ‘ਤੇ ਸਪੀਡ ਸੀਮਾਵਾਂ ਦੀ ਪਾਲਣਾ ਨੂੰ ਉਤਸ਼ਾਹਿਤ ਕਰਦੀਆਂ ਹਨ। ਇਸੇ ਤਰ੍ਹਾਂ, ਐਮਸੀਪੀ ਨੂੰ ਸੰਭਾਵੀ ਜੋਖਮਾਂ ਨੂੰ ਅੰਦਰੂਨੀ ਤੌਰ ‘ਤੇ ਘਟਾਉਣ ਲਈ ਡਿਜ਼ਾਈਨ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ, ਨਾ ਕਿ ਸਿਰਫ਼ ਬਾਹਰੀ ਨਿਯੰਤਰਣਾਂ ‘ਤੇ ਨਿਰਭਰ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ।

ਐਲਐਲਐਮਜ਼ ਅਣਚਾਹੇ ਕਾਰਵਾਈਆਂ ਕਰ ਰਹੇ ਹਨ

ਲੇਖ ਪ੍ਰੋਟੋਕੋਲ ਦੀ ਇੱਕ ਵਿਆਪਕ ਆਲੋਚਨਾ ਵੱਲ ਬਦਲਦਾ ਹੈ ਜੋ ਐਲਐਲਐਮਜ਼ ਨੂੰ ਸੇਵਾਵਾਂ ‘ਤੇ ਕਾਰਵਾਈਆਂ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ। ਲੇਖਕ ਇੱਕ ਮੁੱਖ ਸਮੱਸਿਆ ਦੀ ਪਛਾਣ ਕਰਦਾ ਹੈ: ਐਲਐਲਐਮਜ਼ ਉਹ ਕਾਰਵਾਈਆਂ ਕਰ ਸਕਦੇ ਹਨ ਜੋ ਉਪਭੋਗਤਾ ਉਹਨਾਂ ਤੋਂ ਲੈਣ ਦਾ ਇਰਾਦਾ ਨਹੀਂ ਰੱਖਦੇ ਹਨ। ਉਹ ਐਲਐਲਐਮਜ਼ ਦੁਆਰਾ ਸੁਤੰਤਰ ਤੌਰ ‘ਤੇ ਕੀਤੀਆਂ ਜਾ ਸਕਦੀਆਂ ਕਾਰਵਾਈਆਂ ਅਤੇ ਉਹਨਾਂ ਵਿਚਕਾਰ ਅੰਤਰ ਦੱਸਦੇ ਹਨ ਜਿਨ੍ਹਾਂ ਲਈ ਉਪਭੋਗਤਾ ਪ੍ਰੋਂਪਟਿੰਗ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ।

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

ਲੇਖਕ ਉਪਭੋਗਤਾ ਤੋਂ ਪੁਸ਼ਟੀਕਰਨ ਲਈ ਪੁੱਛਣ ਦੇ ਹੱਲ ਨੂੰ ਰੱਦ ਕਰਦਾ ਹੈ, ਜਦੋਂ ਜ਼ਿਆਦਾਤਰ ਟੂਲ ਨੁਕਸਾਨਦੇਹ ਜਾਪਦੇ ਹਨ ਤਾਂ ਉਪਭੋਗਤਾਵਾਂ ਦੇ ਆਟੋਮੈਟਿਕ ਪੁਸ਼ਟੀਕਰਨ (‘ਯੋਲੋ-ਮੋਡ’) ਦੇ ਇੱਕ ਪੈਟਰਨ ਵਿੱਚ ਡਿੱਗਣ ਦੇ ਜੋਖਮ ਦਾ ਹਵਾਲਾ ਦਿੰਦਾ ਹੈ। ਇਸਦੀ ਤੁਲਨਾ ਲੋਕਾਂ ਦੁਆਰਾ ਨਕਦ ਨਾਲੋਂ ਕਾਰਡਾਂ ਨਾਲ ਜ਼ਿਆਦਾ ਖਰਚ ਕਰਨ ਦੀ ਮਨੋਵਿਗਿਆਨਕ ਵਰਤਾਰੇ ਨਾਲ ਕੀਤੀ ਜਾਂਦੀ ਹੈ - ਇੱਕ ਸਮੱਸਿਆ ਜੋ ਮਨੁੱਖੀ ਵਿਵਹਾਰ ਵਿੱਚ ਜੜ੍ਹੀ ਹੈ, ਤਕਨਾਲੋਜੀ ਵਿੱਚ ਨਹੀਂ।

ਬੁਨਿਆਦੀ ਸਵਾਲ: ਸਿਰਫ਼ APIs ਦੀ ਵਰਤੋਂ ਕਿਉਂ ਨਾ ਕਰੋ?

ਐਮਸੀਪੀ ਬਾਰੇ ਵਿਚਾਰਾਂ ਵਿੱਚ ਇੱਕ ਵਾਰ-ਵਾਰ ਉੱਠਣ ਵਾਲਾ ਸਵਾਲ ਇਹ ਹੈ ਕਿ ਸਿਰਫ਼ APIs ਦੀ ਸਿੱਧੀ ਵਰਤੋਂ ਕਿਉਂ ਨਾ ਕੀਤੀ ਜਾਵੇ।

ਐਮਸੀਪੀ ਐਲਐਲਐਮ ਕਲਾਇੰਟਾਂ ਨੂੰ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ ਜਿਨ੍ਹਾਂ ਨੂੰ ਉਪਭੋਗਤਾ ਸਿੱਧੇ ਤੌਰ ‘ਤੇ ਨਿਯੰਤਰਿਤ ਨਹੀਂ ਕਰਦੇ ਹਨ (ਉਦਾਹਰਨ ਲਈ, ਕਲਾਉਡ, ਚੈਟਜੀਪੀਟੀ, ਕਰਸਰ, ਵੀਐਸਕੋਡ) ਨੂੰ API ਨਾਲ ਗੱਲਬਾਤ ਕਰਨ ਲਈ। ਐਮਸੀਪੀ ਤੋਂ ਬਿਨਾਂ, ਡਿਵੈਲਪਰਾਂ ਨੂੰ ਐਲਐਲਐਮ API ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਕਸਟਮ ਕਲਾਇੰਟ ਬਣਾਉਣ ਦੀ ਲੋੜ ਹੋਵੇਗੀ, ਜੋ ਕਿ ਇੱਕ ਗਾਹਕੀ ਦੇ ਨਾਲ ਮੌਜੂਦਾ ਕਲਾਇੰਟਾਂ ਦੀ ਵਰਤੋਂ ਕਰਨ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਖਾਸ ਟੂਲ ਦੀ ਵਰਤੋਂ ਕਰਨਾ ਸਿਖਾਉਣ ਨਾਲੋਂ ਬਹੁਤ ਮਹਿੰਗਾ ਕੰਮ ਹੈ।

ਇੱਕ ਡਿਵੈਲਪਰ ਨੇ USB ਰਾਹੀਂ ਆਪਣੇ FM ਹਾਰਡਵੇਅਰ ਸਿੰਥੇਸਾਈਜ਼ਰ ਨਾਲ ਜੁੜਨ ਲਈ ਇੱਕ ਐਮਸੀਪੀ ਸਰਵਰ ਬਣਾਉਣ ਦੇ ਆਪਣੇ ਤਜ਼ਰਬੇ ਨੂੰ ਸਾਂਝਾ ਕੀਤਾ, ਜਿਸ ਨਾਲ AI-ਸੰਚਾਲਿਤ ਸਾਊਂਡ ਡਿਜ਼ਾਈਨ ਸਮਰੱਥ ਹੋਇਆ।

ਐਲਐਲਐਮ ਕਲਾਇੰਟ ਏਕੀਕਰਣ ਅਤੇ ਮਿਆਰੀਕਰਨ

ਮੁੱਖ ਮੁੱਦਾ ਇਹ ਹੈ ਕਿ ਸਾਰੇ ਐਲਐਲਐਮ ਕਲਾਇੰਟ ਮੂਲ ਰੂਪ ਵਿੱਚ ਸਿੱਧੀ API ਗੱਲਬਾਤ ਦਾ ਸਮਰਥਨ ਨਹੀਂ ਕਰਦੇ ਹਨ, ChatGPT ਕਸਟਮ GPT ਕਾਰਵਾਈਆਂ ਇੱਕ ਮਹੱਤਵਪੂਰਨ ਅਪਵਾਦ ਹਨ। ਐਂਥਰੋਪਿਕ, ਗੂਗਲ ਅਤੇ ਓਪਨਏਆਈ ਕਲਾਉਡ, ਚੈਟਜੀਪੀਟੀ ਅਤੇ ਕਰਸਰ ਵਰਗੇ ਐਲਐਲਐਮ-ਸੰਚਾਲਿਤ ਕਲਾਇੰਟਾਂ ਲਈ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਸੁਚਾਰੂ ਬਣਾਉਣ ਲਈ ਇੱਕ ਸਾਂਝੇ ਪ੍ਰੋਟੋਕੋਲ ਵਜੋਂ ਐਮਸੀਪੀ ਨੂੰ ਅਪਣਾਉਣ ਲਈ ਸਹਿਮਤ ਹੋ ਗਏ ਹਨ।

ਐਮਸੀਪੀ ਉਹਨਾਂ ਲੋਕਾਂ ਲਈ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਸਰਲ ਬਣਾਉਂਦਾ ਹੈ ਜੋ ਐਲਐਲਐਮ ਕਲਾਇੰਟ ਬਣਾ ਰਹੇ ਹਨ। ਜੇਕਰ ਤੁਸੀਂ ਇੱਕ ਐਲਐਲਐਮ ਨੂੰ ਇੱਕ API ਨਾਲ ਗੱਲਬਾਤ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਸਿਰਫ਼ ਇੱਕ API ਕੁੰਜੀ ਪ੍ਰਦਾਨ ਨਹੀਂ ਕਰ ਸਕਦੇ ਅਤੇ ਇਸਦੇ ਕੰਮ ਕਰਨ ਦੀ ਉਮੀਦ ਨਹੀਂ ਕਰ ਸਕਦੇ - ਤੁਹਾਨੂੰ ਇੱਕ ਏਜੰਟ ਬਣਾਉਣ ਦੀ ਲੋੜ ਹੈ।

ਐਮਸੀਪੀ ਨੂੰ APIs ਨੂੰ ਦਸਤਾਵੇਜ਼ਿਤ ਕਰਨ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਕਿਵੇਂ ਕਾਲ ਕਰਨਾ ਹੈ, ਇਸਦਾ ਵਰਣਨ ਕਰਨ ਦੇ ਇੱਕ ਤਰੀਕੇ ਵਜੋਂ ਦੇਖਿਆ ਜਾ ਸਕਦਾ ਹੈ, ਨਾਲ ਹੀ ਉਸ ਦਸਤਾਵੇਜ਼ ਨੂੰ ਐਕਸਪੋਜ਼ ਕਰਨ ਅਤੇ ਕਾਲਾਂ ਦੀ ਸਹੂਲਤ ਲਈ ਮਿਆਰੀ ਟੂਲਿੰਗ। ਇਹ ਬੇਲੋੜੀ ਪੇਚੀਦਗੀ ਤੋਂ ਬਿਨਾਂ APIs ਨੂੰ ਜੋੜਨ ਲਈ ਕਾਫ਼ੀ ਸੰਖੇਪ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ, ਪਰ ਇਹ ਸਰਲਤਾ ਉਪਭੋਗਤਾਵਾਂ ਨੂੰ ‘ਆਪਣੇ ਆਪ ਨੂੰ ਪੈਰ ਵਿੱਚ ਗੋਲੀ ਮਾਰਨ’ ਵੱਲ ਵੀ ਲੈ ਜਾ ਸਕਦੀ ਹੈ।

ਐਮਸੀਪੀ ਦੀ ਕੁਸ਼ਲਤਾ ਅਤੇ ਦੁਬਾਰਾ ਵਰਤੋਂ ਯੋਗਤਾ

ਐਮਸੀਪੀ ਤੋਂ ਬਿਨਾਂ, ਡਿਵੈਲਪਰਾਂ ਨੂੰ ਐਲਐਲਐਮ ਨੂੰ ਇਹ ਦੱਸਣ ਦੀ ਲੋੜ ਹੋਵੇਗੀ ਕਿ ਹਰ ਵਾਰ ਜਦੋਂ ਇਸਨੂੰ ਬੁਲਾਇਆ ਜਾਂਦਾ ਹੈ ਤਾਂ ਇੱਕ ਟੂਲ ਦੀ ਵਰਤੋਂ ਕਿਵੇਂ ਕਰਨੀ ਹੈ। ਇਸ ਨਾਲ ਐਲਐਲਐਮ ਦੁਆਰਾ ਭੁੱਲੀ ਹੋਈ ਜਾਣਕਾਰੀ ਜਾਂ ਗੈਰ-ਮਿਆਰੀ API ਵਿਵਹਾਰ ਦੇ ਕਾਰਨ ਟੂਲ ਦੀ ਸਹੀ ਵਰਤੋਂ ਕਰਨ ਵਿੱਚ ਅਸਫਲ ਹੋਣ ਦਾ ਜੋਖਮ ਰਹਿੰਦਾ ਹੈ।

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

ਇੱਕ ਐਲਐਲਐਮ ਪ੍ਰਦਾਤਾ ਨੂੰ ਇਹ ਦੱਸ ਕੇ ‘ਇੱਥੇ ਇੱਕ ਟੂਲ ਹੈ ਜਿਸਦੀ ਤੁਸੀਂ ਵਰਤੋਂ ਕਰ ਸਕਦੇ ਹੋ’ ਨਾਲ ਹੀ API ਦਸਤਾਵੇਜ਼, ਉਪਭੋਗਤਾ ਉਸ ਟੂਲ ਨੂੰ ਬਾਰ ਬਾਰ ਰੀਮਾਈਂਡਰਾਂ ਤੋਂ ਬਿਨਾਂ ਕਈ ਚੈਟਾਂ ਵਿੱਚ ਦੁਬਾਰਾ ਵਰਤ ਸਕਦੇ ਹਨ। ਇਹ ਡੈਸਕਟਾਪ ਐਲਐਲਐਮ ਕਲਾਇੰਟਾਂ ਨੂੰ ਸਥਾਨਕ ਤੌਰ ‘ਤੇ ਚੱਲ ਰਹੇ ਪ੍ਰੋਗਰਾਮਾਂ ਨਾਲ ਜੁੜਨ ਦੇ ਯੋਗ ਬਣਾਉਂਦਾ ਹੈ, OS-ਵਿਸ਼ੇਸ਼ ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਪ੍ਰਕਿਰਿਆਵਾਂ ਦੀ ਸਮੱਸਿਆ ਨੂੰ ਹੱਲ ਕਰਦਾ ਹੈ।

ਐਮਸੀਪੀ ਅਤੇ ਸਥਾਨਕ ਸਰੋਤ ਪਹੁੰਚ

ਐਮਸੀਪੀ ਐਲਐਲਐਮਜ਼ ਲਈ ਫਾਈਲਾਂ, ਵਾਤਾਵਰਣ ਵੇਰੀਏਬਲ ਅਤੇ ਨੈਟਵਰਕ ਐਕਸੈਸ ਵਰਗੇ ਸਥਾਨਕ ਸਰੋਤਾਂ ਤੱਕ ਪਹੁੰਚ ਦੀ ਸਹੂਲਤ ਦਿੰਦਾ ਹੈ। ਇਹ ਸਥਾਨਕ ਤੌਰ ‘ਤੇ ਚਲਾਉਣ ਲਈ ਤਿਆਰ ਕੀਤਾ ਗਿਆ ਹੈ, ਜੋ ਐਲਐਲਐਮ ਨੂੰ ਇਹਨਾਂ ਸਰੋਤਾਂ ਤੱਕ ਨਿਯੰਤਰਿਤ ਪਹੁੰਚ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ।

ਮਿਆਰੀ ਐਲਐਲਐਮ ਟੂਲ ਕਾਲ ‘ਸ਼ੇਪ’ ਐਮਸੀਪੀ ਟੂਲ ਕਾਲ ‘ਸ਼ੇਪ’ ਨੂੰ ਨੇੜਿਓਂ ਦਰਸਾਉਂਦੀ ਹੈ, ਜਿਸ ਨਾਲ ਇਹ ਟੂਲ ਨੂੰ ਏਜੰਟਾਂ ਨਾਲ ਜੋੜਨ ਲਈ ਇੱਕ ਸਿੱਧਾ ਮਿਆਰ ਬਣ ਜਾਂਦਾ ਹੈ।

ਐਮਸੀਪੀ AI ਮਾਡਲ ਅਤੇ ਅੰਤਰੀਵ APIs ਨੂੰ ਐਕਸਪੋਜ਼ ਕੀਤੀ ਗਈ ਫੰਕਸ਼ਨ ਕਾਲਿੰਗ ਸਕੀਮਾ ਦੇ ਵਿਚਕਾਰ ਇੱਕ ਪੁਲ ਵਜੋਂ ਕੰਮ ਕਰਦਾ ਹੈ। ਇਹ ਫੰਕਸ਼ਨ ਕਾਲਾਂ ਨੂੰ ਟੂਲ ਵਿੱਚ ਅਨੁਵਾਦ ਕਰਦਾ ਹੈ, ਸਹਿਜ ਸੰਚਾਰ ਨੂੰ ਸਮਰੱਥ ਬਣਾਉਂਦਾ ਹੈ।

ਜੇਕਰ ਤੁਸੀਂ ਇੱਕ ਟੂਲ ਪ੍ਰਦਾਤਾ ਹੋ, ਤਾਂ ਐਮਸੀਪੀ AI ਏਜੰਟ ਫਰੰਟਐਂਡ ਨੂੰ ਤੁਹਾਡੇ ਟੂਲ ਨਾਲ ਜੁੜਨ ਲਈ ਇੱਕ ਮਿਆਰੀ ਪ੍ਰੋਟੋਕੋਲ ਪੇਸ਼ ਕਰਦਾ ਹੈ। ਇਹ ਸਵਾਲ ਦਾ ਜਵਾਬ ਦਿੰਦਾ ਹੈ ਕਿ ਮਿਆਰੀ ਪ੍ਰੋਟੋਕੋਲ ਸਿਰਫ਼ HTTP ਅਤੇ OpenAPI ਕਿਉਂ ਨਹੀਂ ਹੋ ਸਕਦਾ।

ਐਮਸੀਪੀ ਇੱਕ ਮੈਟਾ-API ਹੈ ਜੋ ਅੰਤਮ ਬਿੰਦੂਆਂ ਅਤੇ ਉਹਨਾਂ ਦੇ ਸੰਚਾਲਨ ਵੇਰਵਿਆਂ ਨੂੰ ਵਿਸ਼ੇਸ਼ਤਾ ਵਿੱਚ ਸ਼ਾਮਲ ਕਰਦਾ ਹੈ, ਜਿਸ ਨਾਲ ਐਲਐਲਐਮਜ਼ ਨੂੰ ਉਹਨਾਂ ਨਾਲ ਵਧੇਰੇ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਢੰਗ ਨਾਲ ਗੱਲਬਾਤ ਕਰਨ ਦੇ ਯੋਗ ਬਣਾਇਆ ਜਾਂਦਾ ਹੈ।

ਖਾਸ ਸਥਿਤੀਆਂ ਵਿੱਚ ਐਮਸੀਪੀ

ਐਮਸੀਪੀ ਉਦੋਂ ਮੁੱਦਿਆਂ ਨੂੰ ਹੱਲ ਕਰ ਸਕਦਾ ਹੈ ਜਦੋਂ ਉਪਭੋਗਤਾ ਸਵਾਲ ਪੁੱਛਦੇ ਹਨ ਜਾਂ ਯਕੀਨੀ ਨਹੀਂ ਹੁੰਦੇ ਕਿ ਕਿਹੜੀਆਂ APIs ਦੀ ਵਰਤੋਂ ਕਰਨੀ ਹੈ। ਇਹ ਪਿਛਲੇ ਸੁਨੇਹਿਆਂ ਦੇ ਆਧਾਰ ‘ਤੇ ਬੇਨਤੀਆਂ ਦੀ ਪ੍ਰਕਿਰਿਆ ਵੀ ਕਰ ਸਕਦਾ ਹੈ।

ਇੱਕ ਉਪਭੋਗਤਾ ਨੇ ਇੱਕ ਉਪਭੋਗਤਾ ਦੇ ‘X’ ਨੂੰ ਪ੍ਰਾਪਤ ਕਰਨ ਅਤੇ ਇਸਨੂੰ ਇੱਕ ਅੰਤਮ ਬਿੰਦੂ ‘ਤੇ ਭੇਜਣ ਦੀ ਇੱਛਾ ਦੇ ਆਪਣੇ ਤਜ਼ਰਬੇ ਨੂੰ ਸਾਂਝਾ ਕੀਤਾ। ਉਹਨਾਂ ਨੇ ਅਜਿਹੇ ਸਧਾਰਨ ਕੰਮ ਲਈ ਐਮਸੀਪੀ ਨੂੰ ਓਵਰਕਿਲ ਪਾਇਆ, ਇਹ ਦਰਸਾਉਂਦਾ ਹੈ ਕਿ ਇਹ ਬੁਨਿਆਦੀ API ਗੱਲਬਾਤ ਲਈ ਹਮੇਸ਼ਾ ਜ਼ਰੂਰੀ ਨਹੀਂ ਹੁੰਦਾ ਹੈ।

ਐਮਸੀਪੀ ਦੀ ਤੁਲਨਾ ਇੱਕ ਫਾਸਟਏਪੀਆਈ ਵੈੱਬ ਐਪ ਫਰੇਮਵਰਕ ਨਾਲ ਕੀਤੀ ਜਾਂਦੀ ਹੈ ਜੋ ਅਜਿਹੇ ਸੌਫਟਵੇਅਰ ਬਣਾਉਣ ਲਈ ਹੈ ਜੋ ਨੈੱਟਵਰਕ ‘ਤੇ ਸੰਚਾਰ ਕਰ ਸਕਦਾ ਹੈ, ਖਾਸ ਤੌਰ ‘ਤੇ ਏਜੰਟਿਕ ਅਨੁਭਵਾਂ ਲਈ ਤਿਆਰ ਕੀਤਾ ਗਿਆ ਹੈ। ਇਸਨੂੰ ‘ਰੇਲਜ਼-ਫਾਰ-ਸਕਾਈਨੇਟ’ ਵਜੋਂ ਦੇਖਿਆ ਜਾ ਸਕਦਾ ਹੈ, ਜੋ AI ਏਜੰਟ ਵਿਕਾਸ ਲਈ ਇੱਕ ਮਿਆਰੀ ਢਾਂਚਾ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ।

ਪ੍ਰਦਾਤਾ ਨਿਯੰਤਰਣ ਬਾਰੇ ਚਿੰਤਾਵਾਂ

ਇਹ ਚਿੰਤਾਵਾਂ ਹਨ ਕਿ ਐਮਸੀਪੀ ਨੂੰ ਸਿਸਟਮ ‘ਤੇ ਪ੍ਰਦਾਤਾ-ਪਾਸੇ ਦੇ ਨਿਯੰਤਰਣ ਨੂੰ ਵਧਾਉਣ ਲਈ ਧੱਕਾ ਦਿੱਤਾ ਜਾ ਰਿਹਾ ਹੈ। ਐਲਐਲਐਮ ਪ੍ਰਦਾਤਾ ਆਖਰਕਾਰ API ਪਹੁੰਚ ਨੂੰ ਸੀਮਤ ਕਰ ਸਕਦੇ ਹਨ, ਜਿਵੇਂ ਕਿ ਗੂਗਲ ਨੇ ਜੀਮੇਲ ਨਾਲ IMAP/SMTP ਦੀ ਵਰਤੋਂ ਕਰਨਾ ਮੁਸ਼ਕਲ ਬਣਾ ਦਿੱਤਾ ਹੈ।

OpenAPI ਦੀ ਵਰਤੋਂ ਕਰਨ ਨਾਲ ਏਜੰਟ /openapi.json ਤੋਂ API ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਨੂੰ ਪ੍ਰਾਪਤ ਕਰ ਸਕਦੇ ਹਨ।

ਐਮਸੀਪੀ ਤੇਜ਼ ਗੱਲਬਾਤ ਨੂੰ ਸਮਰੱਥ ਬਣਾਉਂਦਾ ਹੈ, ਜਿਸ ਨਾਲ ਉਪਭੋਗਤਾ ਕੁਝ ਸਕਿੰਟਾਂ ਵਿੱਚ ਕੰਮ ਪੂਰੇ ਕਰ ਸਕਦੇ ਹਨ ਬਜਾਏ ਇਨਪੁਟ ਡੇਟਾ ਤਿਆਰ ਕਰਨ, ਇਸਨੂੰ API ਨੂੰ ਭੇਜਣ, ਆਉਟਪੁੱਟ ਨੂੰ ਪਾਰਸ ਕਰਨ ਅਤੇ ਹਰੇਕ ਸੁਨੇਹੇ ਲਈ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਦੁਹਰਾਉਣ ਵਿੱਚ ਸਮਾਂ ਬਿਤਾਉਣ ਦੀ ਬਜਾਏ।

ਸੈਂਡਬਾਕਸਿੰਗ ਅਤੇ ਸੁਰੱਖਿਆ ਜੋਖਮ

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

ਇਸਦੀ ਤੁਲਨਾ SQL ਇੰਜੈਕਸ਼ਨ ਨਾਲ ਕੀਤੀ ਜਾਂਦੀ ਹੈ - ਇੱਕ ਸਿਸਟਮ ਜੋ ਇਕੱਠਾ ਕੀਤਾ ਗਿਆ ਹੈ ਜਿੱਥੇ ਘੱਟੋ-ਘੱਟ ਨਿਰੀਖਣਯੋਗਤਾ ਦੇ ਨਾਲ ਕਿਸੇ ਵੀ ਬਿੰਦੂ ‘ਤੇ ਕਮਜ਼ੋਰੀਆਂ ਦਾ ਸ਼ੋਸ਼ਣ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ।

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

ਇਹ ਪ੍ਰੋਂਪਟ ਇੰਜੈਕਸ਼ਨ ਅਤੇ ਟੂਲ ਇੰਜੈਕਸ਼ਨ ਦੋਵਾਂ ਲਈ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ, ਸੰਭਾਵੀ ਤੌਰ ‘ਤੇ ਅਵਿਸ਼ਵਾਸਯੋਗ ਕੋਡ ਨੂੰ ਚਲਾਉਣ ਵੱਲ ਲੈ ਜਾਂਦਾ ਹੈ।

ਕੰਟੇਨਰਾਈਜ਼ੇਸ਼ਨ ਅਤੇ ਨਿਯੰਤਰਿਤ ਪਹੁੰਚ

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

ਇਹ ਏਜੰਟਿਕ ਵਰਕਫਲੋ, ਇੱਕ ਚੈਟ-ਅਧਾਰਿਤ ਇੰਟਰਫੇਸ ਦੁਆਰਾ ਚਲਾਇਆ ਜਾਂਦਾ ਹੈ, ਰਵਾਇਤੀ ਤਰੀਕਿਆਂ ਨਾਲੋਂ ਵਧੇਰੇ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਸਾਬਤ ਹੋਇਆ ਹੈ।

ਕੁੰਜੀ ਇਹ ਹੈ ਕਿ ਐਮਸੀਪੀ ਏਜੰਟਾਂ ਨੂੰ ਉਸ ਚੀਜ਼ ਤੱਕ ਪਹੁੰਚ ਦਿੱਤੀ ਜਾਵੇ ਜਿਸਦੀ ਉਹਨਾਂ ਨੂੰ ਲੋੜ ਹੈ, ਅਤੇ ਇਸ ਤੋਂ ਵੱਧ ਕੁਝ ਨਹੀਂ। ਕੰਟੇਨਰਾਈਜ਼ੇਸ਼ਨ ਅਤੇ ਪਾਰਦਰਸ਼ੀ ਟੂਲ UX ਸੁਰੱਖਿਆ ਜੋਖਮਾਂ ਨੂੰ ਘਟਾਉਣ ਲਈ ਮਹੱਤਵਪੂਰਨ ਹਨ।

ਵਰਚੁਅਲ ਮਸ਼ੀਨਾਂ ਅਤੇ ਇੰਟਰਨੈੱਟ ਪਹੁੰਚ

ਏਜੰਟਾਂ ਨੂੰ ਇੱਕ ਘੱਟੋ-ਘੱਟ ਲੀਨਕਸ ਸਥਾਪਨਾ ਵਾਲਾ ਇੱਕ ਕੰਪਿਊਟਰ (ਇੱਕ VM ਜਾਂ ਕੰਟੇਨਰ ਵਜੋਂ) ਦੇਣ ਨਾਲ ਬਿਹਤਰ ਨਤੀਜੇ ਮਿਲ ਸਕਦੇ ਹਨ, ਜਿਸ ਨਾਲ ਉਹਨਾਂ ਨੂੰ ਇੰਟਰਨੈੱਟ ਤੋਂ ਜਾਣਕਾਰੀ ਪ੍ਰਾਪਤ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਮਿਲਦੀ ਹੈ। ਹਾਲਾਂਕਿ, ਇਹ ਖਤਰਨਾਕ ਨਿਰਦੇਸ਼ਾਂ ਅਤੇ ਡੇਟਾ ਐਕਸਫਿਲਟਰੇਸ਼ਨ ਦੇ ਸੰਬੰਧ ਵਿੱਚ ਸੁਰੱਖਿਆ ਚਿੰਤਾਵਾਂ ਨੂੰ ਵਧਾਉਂਦਾ ਹੈ।

ਭਰੋਸੇਮੰਦ ਵੈੱਬਸਾਈਟਾਂ ਤੱਕ ਪਹੁੰਚ ਨੂੰ ਸੀਮਿਤ ਕਰਨ ਨਾਲ ਕੁਝ ਜੋਖਮਾਂ ਨੂੰ ਘਟਾਇਆ ਜਾ ਸਕਦਾ ਹੈ, ਪਰ ਭਰੋਸੇਮੰਦ ਸਰੋਤ ਵੀ ਖਤਰਨਾਕ ਸਮੱਗਰੀ ਨੂੰ ਹੋਸਟ ਕਰ ਸਕਦੇ ਹਨ। ਖਤਰਨਾ