ਇੱਕ ਡਿਵੈਲਪਰ ਦੇ ਹਾਲ ਹੀ ਦੇ ਬਲੌਗ ਨੇ ਚੇਤਾਵਨੀ ਦਿੱਤੀ ਹੈ ਕਿ ਜਦੋਂ AI ਏਜੰਟ ਟੂਲ ਦੇ ਨਤੀਜਿਆਂ ਨੂੰ ਗਲਤ ਤਰੀਕੇ ਨਾਲ ਬਣਾਉਂਦੇ ਹਨ (fabricate), ਤਾਂ ਉਹ "ਸਾਈਲੈਂਟ ਕ੍ਰੈਸ਼" (silent crashes) ਦਾ ਸ਼ਿਕਾਰ ਹੋ ਸਕਦੇ ਹਨ, ਇੱਕ ਅਜਿਹੀ ਖਾਮੀ ਜੋ ਇੱਕ ਆਟੋਮੇਟਡ ਵਰਕਫਲੋ ਦੇ ਹਰ ਅਗਲੇ ਕਦਮ ਨੂੰ ਖਰਾਬ ਕਰ ਸਕਦੀ ਹੈ। ਇਹ ਸਮੱਸਿਆ ਤਿੰਨ ਤਰੀਕਿਆਂ ਨਾਲ ਸਾਹਮਣੇ ਆਉਂਦੀ ਹੈ, ਅਤੇ ਲੁਕਿਆ ਹੋਇਆ ਖਤਰਾ ਇਹ ਹੈ ਕਿ ਏਜੰਟ ਇੱਕ ਗਲਤ ਅਧਾਰ 'ਤੇ ਚੱਲਦਾ ਰਹਿੰਦਾ ਹੈ, ਜਿਸ ਨਾਲ ਆਪਰੇਟਰਾਂ ਨੂੰ ਇਸ ਅਸਫਲਤਾ ਦਾ ਪਤਾ ਨਹੀਂ ਲੱਗਦਾ।
AI ਏਜੰਟ ਕਿਉਂ ਅਸਫਲ ਹੁੰਦੇ ਹਨ
AI ਏਜੰਟ ਜੋ ਬਾਹਰੀ ਟੂਲਸ ਨੂੰ ਸੰਚਾਲਿਤ ਕਰਦੇ ਹਨ, ਕਾਲਾਂ ਦੀ ਇੱਕ ਲੜੀ (chain of calls) ਦੀ ਪਾਲਣਾ ਕਰਦੇ ਹਨ: ਉਹ ਇੱਕ ਟੂਲ ਦਾ ਨਾਮ ਲੈਂਦੇ ਹਨ, ਆਰਗੂਮੈਂਟਸ (arguments) ਭੇਜਦੇ ਹਨ, ਅਤੇ ਜਵਾਬ ਪ੍ਰਾਪਤ ਕਰਦੇ ਹਨ। ਇਹ ਲੜੀ ਤਿੰਨ ਤਰੀਕਿਆਂ ਨਾਲ ਟੁੱਟ ਸਕਦੀ ਹੈ।
- ਗੈਰ-ਹਾਜ਼ਰ ਟੂਲ ਕਾਲਾਂ – ਏਜੰਟ ਇੱਕ ਅਜਿਹੇ ਟੂਲ ਦਾ ਨਾਮ ਬਣਾ ਲੈਂਦਾ ਹੈ ਜੋ ਰਜਿਸਟਰਡ ਨਹੀਂ ਹੁੰਦਾ। ਨਾਮ ਦੀ ਪੁਸ਼ਟੀ ਕਰਨ ਵਾਲੇ ਕਿਸੇ ਸੁਰੱਖਿਆ ਪ੍ਰਬੰਧ (guard) ਤੋਂ ਬਿਨਾਂ, ਪਾਈਪਲਾਈਨ ਇੱਕ ਗਲਤੀ (error) ਦਿੰਦੀ ਹੈ ਅਤੇ ਰੁਕ ਜਾਂਦੀ ਹੈ।
- ਗਲਤ ਆਰਗੂਮੈਂਟਸ – ਟੂਲ ਮੌਜੂਦ ਹੁੰਦਾ ਹੈ, ਪਰ ਏਜੰਟ ਗਲਤ ਫਾਰਮੈਟ ਵਿੱਚ ਡਾਟਾ ਭੇਜਦਾ ਹੈ। ਟੂਲ ਇੱਕ ਗਲਤੀ, ਅਸਪਸ਼ਟ ਆਉਟਪੁੱਟ ਵਾਪਸ ਕਰ ਸਕਦਾ ਹੈ, ਜਾਂ ਅਣਪਛਾਤੀ ਤਰ੍ਹਾਂ ਵਿਵਹਾਰ ਕਰ ਸਕਦਾ ਹੈ, ਜਿਸ ਨਾਲ ਅਗਲੇ ਕਦਮਾਂ ਦੀ ਲੌਜਿਕ (logic) ਖਰਾਬ ਹੋ ਜਾਂਦੀ ਹੈ।
- ਬਣਾਉਟੀ ਨਤੀਜੇ – ਸਭ ਤੋਂ ਖਤਰਨਾਕ ਸਥਿਤੀ। ਕਨੈਕਸ਼ਨ ਟੁੱਟਣ, ਟਾਈਮਆਊਟ, ਜਾਂ ਅੰਦਰੂਨੀ ਗਲਤੀ ਕਾਰਨ ਇੱਕ ਟੂਲ ਕਾਲ ਅਸਫਲ ਹੋ ਜਾਂਦੀ ਹੈ, ਫਿਰ ਵੀ ਏਜੰਟ ਇੱਕ ਸਫਲ ਆਉਟਪੁੱਟ ਦੀ ਰਿਪੋਰਟ ਕਰਦਾ ਹੈ ਜੋ ਕਦੇ ਹੋਇਆ ਹੀ ਨਹੀਂ ਸੀ। ਸਿਸਟਮ ਇਸ ਤਰ੍ਹਾਂ ਅੱਗੇ ਵਧਦਾ ਹੈ ਜਿਵੇਂ ਕਿ ਕੰਮ ਸਫਲ ਰਿਹਾ ਹੋਵੇ, ਅਤੇ ਹਰ ਅਗਲਾ ਫੈਸਲਾ ਇੱਕ ਝੂਠ 'ਤੇ ਅਧਾਰਤ ਹੁੰਦਾ ਹੈ।
ਤੀਜਾ ਅਸਫਲਤਾ ਮੋਡ ਬਲੌਗ ਦਾ "ਸਾਈਲੈਂਟ ਕ੍ਰੈਸ਼" ਹੈ। ਕਿਉਂਕਿ ਏਜੰਟ ਆਤਮਵਿਸ਼ਵਾਸ ਨਾਲ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ, ਗਲਤੀ ਨਜ਼ਰਅੰਦਾਜ਼ ਹੋ ਜਾਂਦੀ ਹੈ, ਅਤੇ ਵਰਕਫਲੋ ਖਰਾਬ ਡਾਟਾ ਪੈਦਾ ਕਰ ਸਕਦਾ ਹੈ, ਗਲਤ ਅਲਰਟ ਦੇ ਸਕਦਾ ਹੈ, ਜਾਂ ਮਹਿੰਗੇ ਅਗਲੇ ਕਦਮਾਂ ਦਾ ਕਾਰਨ ਬਣ ਸਕਦਾ ਹੈ।
ਇਹ ਲੁਕੇ ਹੋਏ ਅਸਫਲਤਾਵਾਂ ਦੇ ਕਾਰਨ ਕੀ ਹਨ?
- ਸਾਈਲੈਂਟ ਫੇਲ੍ਹਰ ਪਾਥਸ – ਬਹੁਤ ਸਾਰੇ ਟੂਲ ਰਿਕਵੈਸਟ ਡ੍ਰੌਪ ਹੋਣ 'ਤੇ ਕੋਈ ਸਪਸ਼ਟ ਗਲਤੀ ਦਾ ਫਲੈਗ (error flag) ਵਾਪਸ ਨਹੀਂ ਕਰਦੇ। ਸਪਸ਼ਟ ਨਕਾਰਾਤਮਕ ਸੰਕੇਤ ਦੀ ਘਾਟ ਕਾਰਨ, ਮਾਡਲ ਅੰਦਾਜ਼ਾ ਲਗਾ ਲੈਂਦਾ ਹੈ ਕਿ ਕਾਲ ਸਫਲ ਰਹੀ ਹੈ।
- ਖਤਮ ਕਰਨ ਦਾ ਦਬਾਅ – ਭਾਸ਼ਾ ਮਾਡਲਾਂ (Language models) ਨੂੰ ਹਰ ਮੋੜ 'ਤੇ ਨਤੀਜਾ ਦੇਣ ਲਈ ਸਿਖਾਇਆ ਜਾਂਦਾ ਹੈ। ਜਦੋਂ ਕੋਈ ਕਦਮ ਰੁਕ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਉਹ ਉਸ ਖਾਲੀ ਥਾਂ ਨੂੰ ਇੱਕ ਪ੍ਰਵਾਨਯੋਗ ਲੱਗਣ ਵਾਲੇ ਜਵਾਬ ਨਾਲ ਭਰ ਦਿੰਦੇ ਹਨ।
- ਤਸਦੀਕ ਦੇ ਕਦਮਾਂ ਦੀ ਘਾਟ – ਲੰਬੇ ਜਾਂ ਬਹੁ-ਪੜਾਵੀ ਕੰਮ ਅਕਸਰ ਉਸ ਚੈੱਕਪੁਆਇੰਟ ਨੂੰ ਛੱਡ ਦਿੰਦੇ ਹਨ ਜੋ ਇਹ ਪੁਸ਼ਟੀ ਕਰਦਾ ਹੈ ਕਿ ਪਿਛਲੀ ਕਾਰਵਾਈ ਅਸਲ ਵਿੱਚ ਹੋਈ ਸੀ ਜਾਂ ਨਹੀਂ।
- ਟੂਲ ਦਾ ਵਧਦਾ ਘੇਰਾ – ਜਿਵੇਂ-ਜਿਵੇਂ ਸੰਸਥਾਵਾਂ ਵਧੇਰੇ APIs ਅਤੇ ਯੂਟੀਲਿਟੀਜ਼ ਜੋੜਦੀਆਂ ਹਨ, ਉਪਲਬਧ ਟੂਲਸ ਦਾ ਮਾਡਲ ਦਾ ਅੰਦਰੂਨੀ ਇੰਡੈਕਸ ਵਧਦਾ ਜਾਂਦਾ ਹੈ, ਜਿਸ ਨਾਲ ਗਲਤ ਟੂਲ ਚੁਣਨ ਜਾਂ ਆਰਗੂਮੈਂਟਸ ਵਿੱਚ ਉਲਝਣ ਦੀ ਸੰਭਾਵਨਾ ਵਧ ਜਾਂਦੀ ਹੈ।
ਸਾਈਲੈਂਟ ਕ੍ਰੈਸ਼ਾਂ ਵਿਰੁੱਧ ਸੁਰੱਖਿਆ ਪ੍ਰਬੰਧ ਬਣਾਉਣਾ
ਬਲੌਗ ਵਿਹਾਰਕ ਰੱਖਿਆਵਾਂ ਦੀ ਸੂਚੀ ਦਿੰਦਾ ਹੈ ਜਿਨ੍ਹਾਂ ਨੂੰ ਕਿਸੇ ਵੀ AI-ਏਜੰਟ ਆਰਕੀਟੈਕਚਰ ਵਿੱਚ ਲਗਾਇਆ ਜਾ ਸਕਦਾ ਹੈ।
- ਆਜ਼ਾਦ ਤਸਦੀਕ – ਟੂਲ ਕਾਲ ਤੋਂ ਬਾਅਦ, ਏਜੰਟ ਦੇ ਸਾਰ (summary) 'ਤੇ ਭਰੋਸਾ ਕਰਨ ਦੀ ਬਜਾਏ ਸਿੱਧੇ ਤੌਰ 'ਤੇ ਸਿਸਟਮ ਦੀ ਸਥਿਤੀ ਦੀ ਪੁੱਛਗਿੱਛ ਕਰੋ। ਉਦਾਹਰਣ ਵਜੋਂ, ਏਜੰਟ ਦੇ ਇਸ ਦਾਅਵੇ ਦੀ ਬਜਾਏ ਕਿ ਫਾਈਲ ਲਿਖ ਦਿੱਤੀ ਗਈ ਹੈ, ਡਾਟਾਬੇਸ ਰਿਕਾਰਡ ਜਾਂ ਫਾਈਲ ਦੀ ਮੌਜੂਦਗੀ ਦੀ ਜਾਂਚ ਕਰੋ।
- ਸਪਸ਼ਟ ਅਸਫਲਤਾ ਸੰਕੇਤ – ਹਰ ਟੂਲ ਲਈ ਇੱਕ ਸਪਸ਼ਟ ਸਟੇਟਸ ਕੋਡ ਜਾਂ ਗਲਤੀ ਦਾ ਸੁਨੇਹਾ ਵਾਪਸ ਕਰਨਾ ਲਾਜ਼ਮੀ ਬਣਾਓ। ਜੇਕਰ ਕੋਈ ਟੂਲ ਇਸ ਦੀ ਗਾਰੰਟੀ ਨਹੀਂ ਦੇ ਸਕਦਾ, ਤਾਂ ਇਸ ਨੂੰ ਇੱਕ ਸ਼ਿਮ (shim) ਵਿੱਚ ਲਪੇਟੋ ਜੋ ਸਪਸ਼ਟ ਸਫਲਤਾ/ਅਸਫਲਤਾ ਫੀਲਡ ਜੋੜਦਾ ਹੋਵੇ।
- ਸਖ਼ਤ ਵੈਲੀਡੇਸ਼ਨ – ਮਾਡਲ ਤੱਕ ਪਹੁੰਚਣ ਤੋਂ ਪਹਿਲਾਂ API ਗੇਟਵੇ 'ਤੇ ਹੀ ਅਣਜਾਣੇ ਟੂਲ ਦੇ ਨਾਮਾਂ ਅਤੇ ਗਲਤ ਆਰਗੂਮੈਂਟਸ ਨੂੰ ਰੱਦ ਕਰ ਦਿਓ। ਸਕੀਮਾ ਵੈਲੀਡੇਸ਼ਨ (Schema validation) ਫਾਰਮੈਟ ਦੀਆਂ ਗਲਤੀਆਂ ਨੂੰ ਜਲਦੀ ਫੜ ਲੈਂਦੀ ਹੈ।
- ਅਸਲ ਨਤੀਜੇ – ਏਜੰਟ ਨੂੰ ਉਸਦੇ ਆਉਟਪੁੱਟ ਵਿੱਚ ਟੂਲ ਤੋਂ ਮਿਲੇ ਕੱਚੇ (raw) ਜਵਾਬ ਨੂੰ ਸ਼ਾਮਲ ਕਰਨ ਲਈ ਮਜਬੂਰ ਕਰੋ, ਨਾ ਕਿ ਉਸਦਾ ਸਿਰਫ਼ ਭਾਸ਼ਾ ਅਨੁਵਾਦ। ਇਹ ਅਸਲ ਪੇਲੋਡ (payload) ਨਾਲ ਤੁਲਨਾ ਕਰਨਾ ਆਸਾਨ ਬਣਾਉਂਦਾ ਹੈ।
- ਲੰਬੇ ਕੰਮਾਂ ਵਿੱਚ ਚੈੱਕਪੁਆਇੰਟਸ – ਸਮੇਂ-ਸਮੇਂ 'ਤੇ "ਸਟੇਟ-ਆਡਿਟ" (state-audit) ਕਦਮ ਪਾਓ ਜੋ ਏਜੰਟ ਦੇ ਅੰਦਰੂਨੀ ਦ੍ਰਿਸ਼ਟੀਕੋਣ ਦੀ ਬਾਹਰੀ ਹਕੀਕਤ ਨਾਲ ਤੁਲਨਾ ਕਰਦੇ ਹਨ। ਜੇਕਰ ਕੋਈ ਅਸਮਾਨਤਾ ਦਿਖਾਈ ਦਿੰਦੀ ਹੈ, ਤਾਂ ਵਰਕਫਲੋ ਨੂੰ ਰੋਕ ਦਿਓ ਜਾਂ ਪਿੱਛੇ ਲੈ ਜਾਓ (roll back)।
ਸਿੱਖਿਆ
ਜਦੋਂ ਇੱਕ AI ਏਜੰਟ ਇਹ ਦਿਖਾਵਾ ਕਰਦਾ ਹੈ ਕਿ ਇੱਕ ਟੂਲ ਸਫਲ ਰਿਹਾ ਜਦੋਂ ਕਿ ਉਹ ਅਸਲ ਵਿੱਚ ਅਸਫਲ ਹੋ ਗਿਆ ਸੀ, ਤਾਂ ਅਗਲੀ ਪ੍ਰਕਿਰਿਆ ਉਸ ਗਲਤੀ ਨੂੰ ਅਪਣਾ ਲੈਂਦੀ ਹੈ। ਹਰ ਬਾਹਰੀ ਕਾਲ ਨੂੰ ਭਰੋਸੇਯੋਗ ਨਾ ਮੰਨੋ: ਨਾਮਾਂ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ, ਸਖ਼ਤ ਆਰਗੂਮੈਂਟ ਸਕੀਮਾ ਲਾਗੂ ਕਰੋ, ਸਪਸ਼ਟ ਸਫਲਤਾ ਫਲੈਗ ਦੀ ਮੰਗ ਕਰੋ, ਅਤੇ ਅਸਲ ਸਿਸਟਮ ਸਥਿਤੀ ਦੇ ਵਿਰੁੱਧ ਨਤੀਜਿਆਂ ਦੀ ਜਾਂਚ ਕਰੋ। ਇਹ ਸੁਰੱਖਿਆ ਪ੍ਰਬੰਧ ਇੱਕ ਸਾਈਲੈਂਟ ਕ੍ਰੈਸ਼ ਨੂੰ ਇੱਕ ਦਿਖਾਈ ਦੇਣ ਵਾਲੀ ਗਲਤੀ ਵਿੱਚ ਬਦਲ ਦਿੰਦੇ ਹਨ ਜਿਸ ਨੂੰ ਫੈਲਣ ਤੋਂ ਪਹਿਲਾਂ ਸੰਭਾਲਿਆ ਜਾ ਸਕਦਾ ਹੈ