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

ਪ੍ਰੋਡਕਸ਼ਨ ਵਿੱਚ ਟੈਕਸਟ ਬੈਂਚਮਾਰਕ ਕਿਉਂ ਫੇਲ ਹੋ ਜਾਂਦੇ ਹਨ

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

ਪੰਜ ਨਿਰਭਰਤਾਵਾਂ (Dependencies) ਦਾ ਨਕਸ਼ਾ ਤਿਆਰ ਕਰਨਾ

Van Data Team ਦੀ ਟੀਮ ਹਰ ਮੁਲਾਂਕਣ ਦੀ ਸ਼ੁਰੂਆਤ ਪੰਜ ਖਾਸ ਕੰਟਰੋਲ ਪੁਆਇੰਟਾਂ ਦਾ ਨਕਸ਼ਾ ਤਿਆਰ ਕਰਕੇ ਕਰਦੀ ਹੈ। ਇਹ ਸਵਾਲ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਬਦਲ ਦਿੰਦਾ ਹੈ। ਤੁਸੀਂ ਇਹ ਪੁੱਛਣਾ ਬੰਦ ਕਰ ਦਿੰਦੇ ਹੋ ਕਿ ਕੀ ਇੱਕ ਮਾਡਲ ਦੂਜੇ ਨਾਲੋਂ ਸਮਾਰਟ ਹੈ। ਤੁਸੀਂ ਇਹ ਪੁੱਛਣਾ ਸ਼ੁਰੂ ਕਰਦੇ ਹੋ ਕਿ ਕੀ ਏਜੰਟ ਅਸਲ ਵਿੱਚ ਤੁਹਾਡੀਆਂ ਅਸਲੀ ਸੀਮਾਵਾਂ ਦੇ ਅਧੀਨ ਇੱਕ ਪ੍ਰੋਡਕਸ਼ਨ ਕਾਰਜ ਨੂੰ ਪੂਰਾ ਕਰ ਸਕਦਾ ਹੈ।

ਕਾਰੋਬਾਰੀ ਨਤੀਜੇ (Business outcomes)। ਇਹ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ ਕਿ ਡਾਲਰਾਂ ਅਤੇ ਗਾਹਕ ਦੇ ਪ੍ਰਭਾਵ ਦੇ ਹਿਸਾਬ ਨਾਲ "ਕੰਮ ਪੂਰਾ ਹੋਣਾ" (done) ਦਾ ਕੀ ਮਤਲਬ ਹੈ। ਕੋਈ ਕਾਰਜ ਇਸ ਲਈ ਪੂਰਾ ਨਹੀਂ ਮੰਨਿਆ ਜਾਂਦਾ ਕਿਉਂਕਿ ਏਜੰਟ ਨੇ ਇੱਕ ਸਾਰ (summary) ਜਾਰੀ ਕੀਤਾ ਹੈ। ਇਹ ਉਦੋਂ ਪੂਰਾ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਇਨਵੈਂਟਰੀ ਰਿਕਾਰਡ ਸਹੀ ਹੁੰਦਾ ਹੈ, ਅਪੌਇੰਟਮੈਂਟ ਦੀ ਪੁਸ਼ਟੀ ਹੋ ਜਾਂਦੀ ਹੈ, ਅਤੇ ਗਾਹਕ ਨੂੰ ਇੱਕ ਵੈਧ ਟ੍ਰੈਕਿੰਗ ਨੰਬਰ ਮਿਲ ਜਾਂਦਾ ਹੈ।

ਬਦਲਣਯੋਗ ਸਟੇਟ (Mutable state)। ਇਹ ਜਾਣੋ ਕਿ ਏਜੰਟ ਨੂੰ ਬਿਲਕੁਲ ਕੀ ਬਦਲਣ ਦੀ ਇਜਾਜ਼ਤ ਹੈ। ਕਿਹੜੀਆਂ ਟੇਬਲ, ਕਿਹੜੀਆਂ ਸਟੇਟਸ, ਕਿਹੜੇ ਅਕਾਊਂਟ ਫਲੈਗਸ? ਜੇਕਰ ਏਜੰਟ ਰਿਫੰਡ ਜਾਰੀ ਕਰ ਸਕਦਾ ਹੈ, ਕੰਮਾਂ ਨੂੰ ਮੁੜ ਅਨੁਸੂਚਿਤ ਕਰ ਸਕਦਾ ਹੈ, ਜਾਂ ਬਿਲਿੰਗ ਪਤੇ ਨੂੰ ਅੱਪਡੇਟ ਕਰ ਸਕਦਾ ਹੈ, ਤਾਂ ਤੁਹਾਨੂੰ ਹਰ ਉਸ ਫੀਲਡ ਦੀ ਸੂਚੀ ਬਣਾਉਣ ਦੀ ਲੋੜ ਹੈ ਜਿਸ ਨੂੰ ਇਹ ਛੂਹਦਾ ਹੈ।

ਟੂਲ ਪਰਮਿਸ਼ਨਾਂ (Tool permissions)। ਇਸ ਬਾਰੇ ਸਪੱਸ਼ਟ ਰਹੋ ਕਿ ਕਿਹੜੇ API endpoints ਅਤੇ ਫੰਕਸ਼ਨ ਸਕੋਪ ਵਿੱਚ ਹਨ। ਇੱਕ ਏਜੰਟ ਜਿਸ ਕੋਲ ਸਰਚ ਟੂਲ, ਇੱਕ ਰਾਈਟ ਟੂਲ, ਅਤੇ ਇੱਕ ਨੋਟੀਫਿਕੇਸ਼ਨ ਟੂਲ ਤੱਕ ਪਹੁੰਚ ਹੈ, ਉਹ ਉਹਨਾਂ ਨੂੰ ਉਲਝਾ ਦੇਵੇਗਾ ਜੇਕਰ ਸੀਮਾਵਾਂ ਅਸਪਸ਼ਟ ਹਨ। ਹਰੇਕ ਪਰਮਿਸ਼ਨ ਨੂੰ ਇੱਕ ਖਾਸ ਕਾਰਜਸ਼ੀਲ ਲੋੜ ਨਾਲ ਜੋੜੋ।

ਫੇਲ੍ਹ ਹੋਣ ਤੋਂ ਬਾਅਦ ਦੀ ਰਿਕਵਰੀ (Failure recovery)। ਫੈਸਲਾ ਕਰੋ ਕਿ ਕੀ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਕੈਲੰਡਰ API ਟਾਈਮ-ਆਊਟ ਹੋ ਜਾਂਦਾ ਹੈ, 500 ਐਰਰ ਦਿੰਦਾ ਹੈ, ਜਾਂ ਗਲਤ (malformed) JSON ਵਾਪਸ ਕਰਦਾ ਹੈ। ਏਜੰਟ ਨੂੰ ਘਬਰਾਉਣਾ ਨਹੀਂ ਚਾਹੀਦਾ, ਸਫਲਤਾ ਦਾ ਮੈਸੇਜ ਹਲੂਸੀਨਾਟ (hallucinate) ਨਹੀਂ ਕਰਨਾ ਚਾਹੀਦਾ, ਜਾਂ ਹਮੇਸ਼ਾ ਲਈ ਰੀਟ੍ਰਾਈ ਨਹੀਂ ਕਰਨਾ ਚਾਹੀਦਾ। ਇਸਨੂੰ ਇੱਕ ਸਪੱਸ਼ਟ ਫਾਲਬੈਕ ਪਾਥ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ।

ਮਨੁੱਖੀ ਸਮੀਖਿਆ ਗੇਟਸ (Human review gates)। ਉਹ ਪਲ ਪਛਾਣੋ ਜਿੱਥੇ ਏਜੰਟ ਦੇ ਅੱਗੇ ਵਧਣ ਤੋਂ ਪਹਿਲਾਂ ਕਿਸੇ ਵਿਅਕਤੀ ਦੁਆਰਾ ਮਨਜ਼ੂਰੀ ਲੈਣੀ ਜ਼ਰੂਰੀ ਹੈ। ਇਹ ਆਟੋਮੇਸ਼ਨ ਵਿੱਚ ਕਮਜ਼ੋਰੀ ਦਾ ਸੰਕੇਤ ਨਹੀਂ ਹੈ। ਇਹ ਉੱਚ-ਪ੍ਰਭਾਵ ਵਾਲੇ ਬਦਲਾਅਾਂ ਲਈ ਇੱਕ ਸੁਰੱਖਿਆ ਵਾਲਵ ਹੈ ਅਤੇ ਤੁਹਾਡੇ ਰੂਬਰਿਕਸ ਲਈ ਗਰਾਊਂਡ-ਟਰੂਥ ਲੇਬਲਾਂ ਦਾ ਇੱਕ ਸਰੋਤ ਹੈ।

ਇੱਕ ਅਸਲੀ ਮੁਲਾਂਕਣ ਯੋਜਨਾ ਕਿਹੋ ਜਿਹੀ ਦਿਖਾਈ ਦਿੰਦੀ ਹੈ

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

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

ਅਜਿਹੇ ਰੂਬਰਿਕਸ (rubrics) ਲਿਖੋ ਜੋ ਕਾਰਜਸ਼ੀਲ ਸ਼ਬਦਾਂ ਵਿੱਚ ਸਫਲਤਾ ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕਰਨ। "ਮਦਦਗਾਰ" ਜਾਂ "ਸਹੀ" ਵਰਗੇ ਅਸਪਸ਼ਟ ਮਾਪਦੰਡ ਬੇਕਾਰ ਹਨ। ਇੱਕ ਉਪਯੋਗੀ ਰੂਬਰਿਕ ਦੱਸਦਾ ਹੈ ਕਿ ਰਿਫੰਡ ਕਾਰਜ ਉਦੋਂ ਹੀ ਸਫਲ ਹੁੰਦਾ ਹੈ ਜੇਕਰ ਅਸਲ ਭੁਗਤਾਨ ID ਦਾ ਹਵਾਲਾ ਦਿੱਤਾ ਗਿਆ ਸੀ, ਰਕਮ ਬੇਨਤੀ ਨਾਲ ਮੇਲ ਖਾਂਦੀ ਸੀ, ਇੱਕ ਪੁਸ਼ਟੀਕਰਨ ਈਮੇਲ ਕਿਊਅਡ ਕੀਤੀ ਗਈ ਸੀ, ਅਤੇ ਟ੍ਰਾਂਜੈਕਸ਼ਨ ID ਨੂੰ ਲੌਗ ਕੀਤਾ ਗਿਆ ਸੀ।

ਟੂਲ ਕਾਲ ਅਤੇ ਰੀਟ੍ਰਾਈਜ਼ (retries) ਲਈ ਟ੍ਰੇਸ ਸਪੈਕਸ (trace specs) ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ। ਤੁਹਾਨੂੰ ਇਸ ਬਾਰੇ ਦੇਖਣ ਦੀ ਲੋੜ ਹੈ ਕਿ ਏਜੰਟ ਨੇ ਕੀ ਯੋਜਨਾ ਬਣਾਈ ਸੀ, ਉਸਨੇ ਅਸਲ ਵਿੱਚ ਕੀ ਕਾਲ ਕੀਤਾ ਸੀ, ਉਸਨੇ ਕਿੰਨੀ ਵਾਰ ਰੀਟ੍ਰਾਈ ਕੀਤਾ ਸੀ, ਅਤੇ ਕੀ ਰੀਟ੍ਰਾਈ ਰਣਨੀਤੀ ਉਚਿਤ ਸੀ। ਟੂਲ-ਪੱਧਰ ਦੀ ਵਿਸਤ੍ਰਿਤ ਜਾਣਕਾਰੀ ਤੋਂ ਬਿਨਾਂ ਇੱਕ ਟ੍ਰੇਸ ਸਿਰਫ ਇੱਕ ਸੁੰਦਰ ਕਹਾਣੀ ਹੈ।

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

ਮਾੜੇ ਮਾਡਲ ਅੱਪਗ੍ਰੇਡਾਂ ਨੂੰ ਰੋਕਣ ਲਈ ਰਿਲੀਜ਼ ਗੇਟਸ (release gates) ਲਗਾਓ। ਇੱਕ ਨਵਾਂ ਮਾਡਲ ਉਦੋਂ ਹੀ ਅੱਪਗ੍ਰੇਡ ਮੰਨਿਆ ਜਾਂਦਾ ਹੈ ਜੇਕਰ ਇਹ ਤੁਹਾਡੇ ਖਾਸ ਨਤੀਜਿਆਂ ਵਿੱਚ ਸੁਧਾਰ ਕਰਦਾ ਹੈ। ਜੇਕਰ ਇਹ ਟੂਲ ਆਰਗੂਮੈਂਟਸ (tool arguments) ਵਿੱਚ ਵਧੇਰੇ ਗਲਤੀਆਂ (hallucinate) ਕਰਦਾ ਹੈ, ਲੇਟੈਂਸੀ (latency) ਵਧਾਉਂਦਾ ਹੈ, ਜਾਂ ਨਵੇਂ ਸੁਰੱਖਿਆ ਜੋਖਮ ਪੈਦਾ ਕਰਦਾ ਹੈ, ਤਾਂ ਇਸਨੂੰ ਸ਼ਿਪ (ship) ਨਹੀਂ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ। ਇਹ ਗੇਟ ਪ੍ਰੋਡਕਸ਼ਨ ਨੂੰ ਸਥਿਰ ਰੱਖਦਾ ਹੈ, ਭਾਵੇਂ ਬੇਸ ਮਾਡਲ ਵੈਂਡਰ ਕੋਈ ਨਵਾਂ ਵਰਜ਼ਨ ਸ਼ਿਪ ਕਰ ਦੇਵੇ।

ਰਨਟਾਈਮ ਗ੍ਰੇਡਿੰਗ (Runtime Grading): ਏਜੰਟ ਦੇ ਕੰਮ ਨੂੰ ਦੇਖਣਾ

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

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

ਇੱਕ ਖਾਸ ਅੰਨ੍ਹੇ ਮੋੜ (blind spot) ਤੋਂ ਸਾਵਧਾਨ ਰਹੋ। ਜੇਕਰ ਉਹੀ ਮਾਡਲ ਕੰਮ ਵੀ ਕਰਦਾ ਹੈ ਅਤੇ ਉਸੇ ਕੰਮ ਦਾ ਗ੍ਰੇਡਿੰਗ ਵੀ ਕਰਦਾ ਹੈ, ਤਾਂ ਉਹ ਉਹੀਆਂ ਗਲਤੀਆਂ ਛੱਡ ਸਕਦਾ ਹੈ। ਜਿਸ ਤਰਕ (reasoning) ਨੇ ਗਲਤੀ ਕੀਤੀ ਹੈ, ਉਹ ਰਿਵਿਊ ਦੌਰਾਨ ਉਸੇ ਗਲਤੀ ਨੂੰ ਆਸਾਨੀ ਨਾਲ ਜਾਇਜ਼ ਠਹਿਰਾ ਸਕਦਾ ਹੈ। ਉੱਚ-ਪ੍ਰਭਾਵ ਵਾਲੇ ਕੰਮਾਂ ਲਈ, ਮਨੁੱਖੀ ਰਿਵਿਊ (human review) ਨੂੰ ਸ਼ਾਮਲ ਰੱਖੋ। ਲੋਕਾਂ ਨੂੰ ਗ੍ਰੇਡਰ ਦੇ ਆਪਣੇ ਫੈਸਲੇ ਦੀ ਪੁਸ਼ਟੀ ਕਰਨ ਦਿਓ, ਖਾਸ ਕਰਕੇ ਜਦੋਂ ਪੈਸੇ ਜਾਂ ਗਾਹਕ ਦਾ ਭਰੋਸਾ ਦਾਅ 'ਤੇ ਹੋਵੇ।

ਇੱਥੇ ਉਦੇਸ਼ ਕਾਰਜਸ਼ੀਲ ਨਿਯੰਤਰਣ (operational control) ਹੈ। ਆਪਣੇ ਇੰਸੀਡੈਂਟ ਡੇਟਾ (incident data), ਆਪਣੇ ਟਾਸਕ ਰੂਬਰਿਕਸ (task rubrics), ਅਤੇ ਆਪਣੇ ਰਨਟਾਈਮ ਟ੍ਰੇਸ (runtime traces) ਨੂੰ ਇੱਕ ਫੀਡਬੈਕ ਚੱਕਰ ਵਿੱਚ ਜੋੜੋ। ਪੂਰੇ ਰਸਤੇ ਦਾ ਮੁਲਾਂਕਣ ਕਰੋ: ਯੋਜਨਾ, ਟੂਲ ਦੀ ਵਰਤੋਂ, ਰਿਕਵਰੀ ਵਿਵਹਾਰ, ਅਤੇ ਅੰਤਿਮ ਨਤੀਜਾ। ਰਿਲੀਜ਼ ਤੋਂ ਪਹਿਲਾਂ ਜਾਣੇ-ਪਛਾਣੇ ਅਤੇ ਦੁਹਰਾਉਣਯੋਗ (reproducible) ਅੰਦਾਜ਼ੇ ਵਾਲੀਆਂ ਗਲਤੀਆਂ ਨੂੰ ਫੜਨ ਲਈ ਆਫਲਾਈਨ ਟੈਸਟਾਂ ਦੀ ਵਰਤੋਂ ਕਰੋ। ਉਹ ਨਵੀਆਂ ਅਸਫਲਤਾਵਾਂ ਲੱਭਣ ਲਈ ਰਨਟਾਈਮ ਟ੍ਰੇਸ ਦੀ ਵਰਤੋਂ ਕਰੋ ਜਿਨ੍ਹਾਂ ਦੀ ਤੁਸੀਂ ਉਮੀਦ ਨਹੀਂ ਕੀਤੀ ਸੀ। ਇਹ ਪਤਾ ਲਗਾਉਣ ਲਈ ਮਨੁੱਖੀ ਰਿਵਿਊ ਦੀ ਵਰਤੋਂ ਕਰੋ ਕਿ ਤੁਹਾਡੇ ਰੂਬਰਿਕਸ ਕਿੱਥੇ ਕਮਜ਼ੋਰ ਹਨ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਹੋਰ ਸਖ਼ਤ ਕਰਨ ਦੀ ਲੋੜ ਹੈ।

ਇਸ ਲਈ ਆਪਣੇ ਆਪ ਨੂੰ ਪੁੱਛੋ: ਤੁਸੀਂ ਆਪਣੇ ਵਰਕਫਲੋ (workflow) ਵਿੱਚ ਰਨਟਾਈਮ ਗ੍ਰੇਡਰ ਕਿੱਥੇ ਰੱਖੋਗੇ? ਟੂਲ ਕਾਲ (tool call) ਤੋਂ ਪਹਿਲਾਂ, ਟੂਲ ਕਾਲ ਤੋਂ ਬਾਅਦ, ਜਾਂ ਸਿਰਫ ਕਿਸੇ ਜੋਖਮ ਭਰੇ ਬਦਲਾਅ ਤੋਂ ਪਹਿਲਾਂ? ਜ਼ਿਆਦਾਤਰ ਟੀਮਾਂ ਬਹੁਤ ਵਿਆਪਕ ਸ਼ੁਰੂਆਤ ਕਰਦੀਆਂ ਹਨ, ਸਭ ਕੁਝ ਗ੍ਰੇਡ ਕਰਦੀਆਂ ਹਨ, ਅਤੇ ਫਿਰ ਲਾਗਤ ਕਾਰਨ ਰੁਕ ਜਾਂਦੀਆਂ ਹਨ। ਤੰਗ (narrow) ਸ਼ੁਰੂਆਤ ਕਰੋ। ਉਹ ਇੱਕ ਕਾਰਵਾਈ ਚੁਣੋ ਜੇਕਰ ਉਹ ਗਲਤ ਹੋ ਗਈ ਤਾਂ ਸਭ ਤੋਂ ਵੱਧ ਨੁਕਸਾਨ ਹੋਵੇਗਾ। ਪਹਿਲਾਂ ਉੱਥੇ ਗ੍ਰੇਡਰ ਰੱਖੋ।

ਇੱਕ ਮਹਿੰਗੀ ਗਲਤੀ ਨਾਲ ਸ਼ੁਰੂਆਤ ਕਰੋ

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

ਜੇਕਰ ਤੁਸੀਂ ਮਾਹਰਾਂ ਦੇ ਭਾਈਚਾਰੇ ਦੇ ਨਾਲ ਏਜੰਟ ਮੁਲਾਂਕਣ ਅਤੇ ਰਨਟਾਈਮ ਗ੍ਰੇਡਿੰਗ ਬਾਰੇ ਹੋਰ ਡੂੰਘਾਈ ਨਾਲ ਜਾਣਨਾ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ GyaanSetu ਲਰਨਿੰਗ ਕਮਿਊਨਿਟੀ ਨੂੰ https://t.me/GyaanSetuAi 'ਤੇ ਲੱਭ ਸਕਦੇ ਹੋ।