Autonomous vehicles, industrial robots, and drone fleets do not follow the rigid, handwritten rulebooks that powered old

ਆਟੋਨੋਮਸ ਵਾਹਨ, ਉਦਯੋਗਿਕ ਰੋਬੋਟ, ਅਤੇ ਡਰੋਨ ਫਲੀਟ ਉਹ ਸਖ਼ਤ, ਹੱਥ ਨਾਲ ਲਿਖੀਆਂ ਨਿਯਮਾਵਲੀਆਂ ਦੀ ਪਾਲਣਾ ਨਹੀਂ ਕਰਦੇ ਜੋ ਪੁਰਾਣੇ ਆਟੋਪਾਇਲਟ ਸਿਸਟਮਾਂ ਨੂੰ ਚਲਾਉਂਦੀਆਂ ਸਨ। ਉਹ vast (ਵੱਡੀ) ਮਾਤਰਾ ਵਿੱਚ ਡੇਟਾ ਤੋਂ ਸਿੱਖਦੇ ਹਨ, ਜਿਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਉਹਨਾਂ ਦਾ ਵਿਵਹਾਰ ਸੰਭਾਵਨਾਤਮਕ (probabilistic) ਹੈ, ਨਾ ਕਿ ਨਿਸ਼ਚਿਤ (deterministic)। ਇੱਕ ਰਵਾਇਤੀ ਜਹਾਜ਼ ਦਾ ਆਟੋਪਾਇਲਟ ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ ਕੋਡ ਕੀਤੇ ਲੌਜਿਕ ਰਾਹੀਂ ਸੈਂਸਰ ਇਨਪੁਟਸ 'ਤੇ ਪ੍ਰਤੀਕਿਰਿਆ ਕਰਦਾ ਹੈ। ਇੱਕ ਮਸ਼ੀਨ ਲਰਨਿੰਗ ਮਾਡਲ ਉਹਨਾਂ ਪੈਟਰਨਾਂ ਰਾਹੀਂ ਪ੍ਰਤੀਕਿਰਿਆ ਕਰਦਾ ਹੈ ਜੋ ਉਸਨੇ ਟ੍ਰੇਨਿੰਗ ਦੌਰਾਨ ਸਿੱਖੇ ਹੁੰਦੇ ਹਨ। ਇਹ ਅੰਤਰ ਵੈਰੀਫਿਕੇਸ਼ਨ (verification) ਨੂੰ ਬਹੁਤ ਮੁਸ਼ਕਲ ਬਣਾ ਦਿੰਦਾ ਹੈ, ਅਤੇ ਇਹੀ ਕਾਰਨ ਹੈ ਕਿ ਮਸ਼ੀਨ ਲਰਨਿੰਗ ਕਮਿਊਨਿਟੀ ਨੇ ਐਡ-ਹਾਕ (ad-hoc) ਟੈਸਟਿੰਗ ਦੀ ਬਜਾਏ ਸੰਰਚਿਤ ਅਸ਼ੋਰੈਂਸ ਫਰੇਮਵਰਕਾਂ (structured assurance frameworks) ਵੱਲ ਰੁਖ਼ ਕੀਤਾ ਹੈ।

ਮਸ਼ੀਨ ਲਰਨਿੰਗ ਅਸ਼ੋਰੈਂਸ ਕਿਉਂ ਲਾਜ਼ਮੀ ਹੈ

ਜਦੋਂ ਕੋਈ ਆਟੋਨੋਮਸ ਸਿਸਟਮ ਗਲਤੀ ਕਰਦਾ ਹੈ, ਤਾਂ ਇਸਦੇ ਨਤੀਜੇ ਸਿਰਫ਼ ਇੱਕ ਸਰਵਰ ਐਰਰ ਜਾਂ ਫ੍ਰੀਜ਼ ਹੋਏ ਐਪਲੀਕੇਸ਼ਨ ਤੱਕ ਸੀਮਤ ਨਹੀਂ ਹੁੰਦੇ। ਇੱਕ ਵੇਅਰਹਾਊਸ ਰੋਬੋਟ ਦੁਆਰਾ ਕਿਸੇ ਰੁਕਾਵਟ ਦੀ ਗਲਤ ਪਛਾਣ ਕਰਨ ਨਾਲ ਇਨਵੈਂਟਰੀ ਤਬਾਹ ਹੋ ਸਕਦੀ ਹੈ ਜਾਂ ਕਿਸੇ ਕਰਮਚਾਰੀ ਨੂੰ ਸੱਟ ਲੱਗ ਸਕਦੀ ਹੈ। ਇੱਕ ਡਿਲੀਵਰੀ ਡਰੋਨ ਜੋ ਪਾਵਰ ਲਾਈਨ ਨੂੰ ਖੁੱਲ੍ਹਾ ਅਸਮਾਨ ਸਮਝ ਲੈਂਦਾ ਹੈ, ਉਹ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਨਾਲ ਟਕਰਾ ਸਕਦਾ ਹੈ। ਕਿਉਂਕਿ ਇਹ ਸਿਸਟਮ ਗੁੰਝਲਦਾਰ ਨਿਊਰਲ ਨੈੱਟਵਰਕਾਂ ਅਤੇ ਅੰਕੜਾ ਵਿਗਿਆਨਕ ਮਾਡਲਾਂ (statistical models) 'ਤੇ ਨਿਰਭਰ ਕਰਦੇ ਹਨ, ਇਸ ਲਈ ਉਹਨਾਂ ਦੇ ਫੇਲ੍ਹ ਹੋਣ ਦੇ ਤਰੀਕੇ ਬਹੁਤ ਸੂਖਮ ਹੁੰਦੇ ਹਨ। ਉਹ ਸ਼ਾਇਦ ਹੀ ਕਦੇ ਸਪੱਸ਼ਟ ਤਰੀਕੇ ਨਾਲ ਖਰਾਬ ਹੁੰਦੇ ਹਨ। ਇਸ ਦੀ ਬਜਾਏ, ਜਦੋਂ ਉਹਨਾਂ ਨੂੰ ਅਜਿਹੇ ਇਨਪੁਟਸ ਦਾ ਸਾਹਮਣਾ ਕਰਨਾ ਪੈਂਦਾ ਹੈ ਜੋ ਟ੍ਰੇਨਿੰਗ ਦੌਰਾਨ ਦੇਖੇ ਗਏ ਡਿਸਟ੍ਰੀਬਿਊਸ਼ਨ (distributions) ਤੋਂ ਬਾਹਰ ਹੁੰਦੇ ਹਨ, ਤਾਂ ਉਹ ਚੁੱਪਚਾਪ ਕੰਮ ਕਰਨਾ ਘਟਾ ਦਿੰਦੇ ਹਨ।

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

AMLAS ਅਸਲ ਵਿੱਚ ਕੀ ਕਵਰ ਕਰਦਾ ਹੈ

AMLAS, ਜਿਸਦਾ ਮਤਲਬ 'Assurance of Machine Learning for use in Autonomous Systems' ਹੈ, ਇਹ ਪੁਸ਼ਟੀ ਕਰਨ ਲਈ ਇੱਕ end-to-end ਪਹੁੰਚ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ ਕਿ ਸਿੱਖੇ ਹੋਏ ਕੰਪੋਨੈਂਟਸ ਉੱਚ-ਜੋਖਮ ਵਾਲੇ ਤੈਨਾਤੀ (high-stakes deployment) ਲਈ ਢੁਕਵੇਂ ਹਨ। ਇਹ ਸੁਰੱਖਿਆ ਨੂੰ ਰਿਲੀਜ਼ ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ နောက် ਵਿਚਾਰ ਜਾਂ ਆਖਰੀ ਰੁਕਾਵਟ ਵਜੋਂ ਨਹੀਂ ਦੇਖਦਾ। ਇਸ ਦੀ ਬਜਾਏ, ਇਹ ਸਿਸਟਮ ਦੇ ਜੀਵਨ ਚੱਕਰ (lifecycle) ਵਿੱਚ ਅਸ਼ੋਰੈਂਸ ਗਤੀਵਿਧੀਆਂ ਨੂੰ ਪਰੋ ਦਿੰਦਾ ਹੈ।

ਇਹ ਫਰੇਮਵਰਕ ਤਿੰਨ ਵਿਵਹਾਰਕ ਥੰਮ੍ਹਾਂ 'ਤੇ ਕੇਂਦਰਿਤ ਹੈ:

ML ਮਾਡਲਾਂ ਲਈ ਵੈਰੀਫਿਕੇਸ਼ਨ ਵਿਧੀਆਂ। ਇਹ ਐਕਯੂਰੇਸੀ (accuracy) ਜਾਂ F1 ਸਕੋਰ ਵਰਗੇ ਸਟੈਂਡਰਡ ਟ੍ਰੇਨ-ਟੈਸਟ ਸਪਲਿਟ ਮੈਟ੍ਰਿਕਸ ਤੋਂ ਕਿਤੇ ਅੱਗੇ ਜਾਂਦਾ ਹੈ। AMLAS ਦੇ ਅਧੀਨ ਅਸ਼ੋਰੈਂਸ ਇਹ ਪੁੱਛਦਾ ਹੈ ਕਿ ਕੀ ਮਾਡਲ ਡਿਸੀਜ਼ਨ ਬਾਊਂਡਰੀਜ਼ (decision boundaries) 'ਤੇ ਅਨੁਮਾਨਿਤ ਤਰੀਕੇ ਨਾਲ ਵਿਵਹਾਰ ਕਰਦਾ ਹੈ, ਇਹ out-of-distribution ਇਨਪੁਟਸ 'ਤੇ ਕਿਵੇਂ ਪ੍ਰਤੀਕਿਰਿਆ ਕਰਦਾ ਹੈ, ਅਤੇ ਕੀ ਇਸਦੇ ਕਾਨਫੀਡੈਂਸ ਸਕੋਰ ਅਸਲ ਅਨਿਸ਼ਚਿਤਤਾ ਦੇ ਭਰੋਸੇਯੋਗ ਸੰਕੇਤ ਹਨ। ਇੰਜੀਨੀਅਰਾਂ ਤੋਂ ਉਮੀਦ ਕੀਤੀ ਜਾਂਦੀ ਹੈ ਕਿ ਉਹ ਮਾਡਲ ਦੀ ਐਡਵਰਸੇਰੀਅਲ ਉਦਾਹਰਣਾਂ (adversarial examples) ਨਾਲ ਜਾਂਚ ਕਰਨ ਅਤੇ ਟ੍ਰੇਨਿੰਗ ਸੈੱਟ ਤੋਂ ਥੋੜ੍ਹਾ ਬਾਹਰਲੇ ਡੋਮੇਨਾਂ ਦੇ ਇਨਪੁਟਸ ਦੇ ਵਿਰੁੱਧ ਇਸਦਾ ਸਟ੍ਰੈਸ-ਟੈਸਟ ਕਰਨ। ਉਦੇਸ਼ ਸੰਪੂਰਨਤਾ ਨਹੀਂ ਹੈ। ਇਹ ਇਹ ਜਾਣਨ ਲਈ ਲੋੜੀਂਦੇ ਸਬੂਤ ਇਕੱਠੇ ਕਰਨਾ ਹੈ ਕਿ ਮਾਡਲ 'ਤੇ ਕਦੋਂ ਭਰੋਸਾ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ ਅਤੇ ਕਦੋਂ ਨਹੀਂ।

ਆਟੋਨੋਮਸ ਕਾਰਵਾਈਆਂ ਲਈ ਸੁਰੱਖਿਆ ਪ੍ਰੋਟੋਕੋਲ। ਇੱਕ ਸਿੱਖਿਆ ਪ੍ਰਾਪਤ ਪਰਸੈਪਸ਼ਨ ਮਾਡਲ (perception model) ਪਲਾਨਿੰਗ ਅਤੇ ਕੰਟਰੋਲ ਸਾਫਟਵੇਅਰ ਵਿੱਚ ਫੀਡ ਹੁੰਦਾ ਹੈ ਜੋ ਭੌਤਿਕ ਹਾਰਡਵੇਅਰ ਨੂੰ ਚਲਾਉਂਦਾ ਹੈ। AMLAS ਦੀ ਮੰਗ ਹੈ ਕਿ ਇਹਨਾਂ ਡਾਊਨਸਟ੍ਰੀਮ ਕਾਰਵਾਈਆਂ ਵਿੱਚ ਗਾਰਡਰੇਲ (guardrails) ਸ਼ਾਮਲ ਹੋਣ। ਭਾਵੇਂ ਇੱਕ ਨਿਊਰਲ ਨੈੱਟਵਰਕ ਕਿਸੇ ਵਸਤੂ ਨੂੰ ਗਲਤ ਤਰੀਕੇ ਨਾਲ ਕਲਾਸੀਫਾਈ ਕਰਦਾ ਹੈ, ਵਾਹਨ ਜਾਂ ਰੋਬੋਟ ਭੌਤਿਕ ਤੌਰ 'ਤੇ ਅਜਿਹਾ ਰਸਤਾ (trajectory) ਅਪਣਾਉਣ ਦੇ ਯੋਗ ਨਹੀਂ ਹੋਣਾ ਚਾਹੀਦਾ ਜੋ ਸਖ਼ਤ ਪਾਬੰਦੀਆਂ (hard constraints) ਦੀ ਉਲੰਘਣਾ ਕਰਦਾ ਹੋਵੇ। ਇਸਦਾ ਮਤਲਬ ਰੋਬੋਟਿਕ ਬਾਹਾਂ 'ਤੇ ਟਾਰਕ ਸੀਮਾਵਾਂ, ਡਰੋਨਾਂ ਲਈ ਜੀਓਫੈਂਸਿੰਗ, ਜਾਂ ਜ਼ਮੀਨੀ ਵਾਹਨਾਂ ਲਈ ਲਾਜ਼ਮੀ ਬ੍ਰੇਕਿੰਗ ਕੋਰੀਡੋਰ ਹੋ ਸਕਦਾ ਹੈ। ਆਟੋਨੋਮਸ ਸਿਸਟਮ ਨੂੰ ਅਜਿਹੇ ਆਰਕੀਟੈਕਚਰਲ ਲੇਅਰਾਂ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ ਜੋ ਇੱਕ ਸਿੰਗਲ ਮਾਡਲ ਗਲਤੀ ਨੂੰ ਅਨਿਯੰਤਰਿਤ ਭੌਤਿਕ ਘਟਨਾ ਬਣਨ ਤੋਂ ਰੋਕ ਸਕਣ।

ਅਨਿਸ਼ਚਿਤਤਾ ਨੂੰ ਘਟਾਉਣ ਦੇ ਤਰੀਕੇ। ਮਸ਼ੀਨ ਲਰਨਿੰਗ ਵਿੱਚ ਅਨਿਸ਼ਚਿਤਤਾ ਕਈ ਰੂਪਾਂ ਵਿੱਚ ਆਉਂਦੀ ਹੈ। ਇਸ ਵਿੱਚ ਐਲੀਏਟੋਰਿਕ ਅਨਿਸ਼ਚਿਤਤਾ (aleatoric uncertainty), ਸੈਂਸਰ ਰੀਡਿੰਗ ਜਾਂ ਵਾਤਾਵਰਣ ਵਿੱਚ ਮੌਜੂਦ ਸ਼ੋਰ (noise), ਅਤੇ ਐਪਿਸ

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

ਆਪਣੇ ਮਾਡਲਾਂ ਦਾ ਟੈਸਟ ਅਜਿਹੇ ਡੇਟਾ ਨਾਲ ਕਰੋ ਜੋ ਅਸਲ ਕੰਮਕਾਜ ਦੀਆਂ ਮੁਸ਼ਕਲਾਂ ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੋਵੇ। ਲੈਬ ਬੈਂਚਮਾਰਕ ਸਹਿਜ ਲੱਗਦੇ ਹਨ, ਪਰ ਉਹ ਝੂਠੇ ਹੁੰਦੇ ਹਨ। ਇੱਕ ਗੋਦਾਮ ਰੋਬੋਟ ਜਿਸ ਨੂੰ ਸਿਰਫ਼ ਸਾਫ਼ ਬਾਰਕੋਡ ਤਸਵੀਰਾਂ 'ਤੇ ਟ੍ਰੇਨ ਕੀਤਾ ਗਿਆ ਹੈ, ਉਹ ਉਦੋਂ ਫੇਲ੍ਹ ਹੋ ਜਾਵੇਗਾ ਜਦੋਂ ਲੇਬਲ ਕੁਚਲਿਆ ਹੋਇਆ, ਘੱਟ ਰੌਸ਼ਨੀ ਵਾਲਾ, ਜਾਂ ਗੰਦਗੀ ਨਾਲ ਢੱਕਿਆ ਹੋਵੇਗਾ। ਇੱਕ ਆਟੋਨੋਮਸ ਡਰੋਨ ਜਿਸਦਾ ਟੈਸਟ ਸਿਰਫ਼ ਸਾਫ਼ ਮੌਸਮ ਵਿੱਚ ਕੀਤਾ ਗਿਆ ਹੈ, ਉਹ ਚਮਕ ਅਤੇ ਹਵਾ ਦੇ ਦਬਾਅ ਨਾਲ ਸੰਘਰਸ਼ ਕਰੇਗਾ। ਤੁਹਾਨੂੰ ਅਸਲ ਡਿਪਲਾਈਮੈਂਟ ਵਾਤਾਵਰਣਾਂ ਤੋਂ ਲੌਗਸ (logs) ਦੀ ਲੋੜ ਹੈ, ਜਿਸ ਵਿੱਚ ਉਹ ਨਿਰਾਸ਼ਾਜਨਕ ਐਜ ਕੇਸ (edge cases) ਵੀ ਸ਼ਾਮਲ ਹੋਣ ਜੋ ਕਿ ਸੰਗ੍ਰਹਿਤ ਡੇਟਾ ਸੈੱਟਾਂ ਵਿੱਚ ਕਦੇ ਨਹੀਂ ਦਿਖਾਈ ਦਿੰਦੇ। ਸ਼ੈਡੋ ਮੋਡ ਟਰਾਇਲਜ਼ ਚਲਾਓ ਜਿੱਥੇ ਆਟੋਨੋਮਸ ਸਿਸਟਮ ਮਨੁੱਖੀ ਆਪਰੇਟਰਾਂ ਦੇ ਨਾਲ-ਨਾਲ ਫੈਸਲੇ ਲੈਂਦਾ ਹੈ ਪਰ ਅਜੇ ਤੱਕ ਹਾਰਡਵੇਅਰ ਨੂੰ ਕੰਟਰੋਲ ਨਹੀਂ ਕਰਦਾ। ਲੌਗਸ ਦੀ ਸਖ਼ਤੀ ਨਾਲ ਤੁਲਨਾ ਕਰੋ।

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

ਅਸਲ-ਦੁਨੀਆ ਦੀ ਵੈਲੀਡੇਸ਼ਨ ਬਾਰੇ ਕੌੜਾ ਸੱਚ

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

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

ਸਮੇਂ ਦੇ ਨਾਲ ਸਿਸਟਮਾਂ ਨੂੰ ਇਮਾਨਦਾਰ ਰੱਖਣਾ

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