ਜਾਣੋ ਕਿਹੜੇ ਸੰਕੇਤ ਦੱਸਦੇ ਹਨ ਕਿ ਤੁਹਾਡਾ AI ਪ੍ਰੋਟੋਟਾਈਪ ਉਤਪਾਦਨ ਲਈ ਤਿਆਰ ਹੈ ਅਤੇ ਅਸੀਂ ਕਿਹੜੇ ਕਦਮ ਠੀਕ ਕਰਕੇ ਇਸਨੂੰ ਮਜ਼ਬੂਤ ਕਰੀਏ: ਭਰੋਸੇਯੋਗਤਾ, ਸੁਰੱਖਿਆ, ਮਾਨੀਟਰਿੰਗ, ਟੈਸਟਿੰਗ, ਅਤੇ ਰੋਲਆਊਟ।
ਇੱਕ ਪ੍ਰੋਟੋਟਾਈਪ ਇੱਕ ਸਵਾਲ ਦਾ ਜਵਾਬ ਦਿੰਦਾ ਹੈ: “ਕੀ ਇਹ ਵਿਚਾਰ ਅੱਗੇ ਵਧਾਉਣਯੋਗ ਹੈ?” ਇਹ ਤੇਜ਼ੀ, ਸਿੱਖਣ ਅਤੇ ਇੱਕ ਮੰਨਣਯੋਗ ਅਨੁਭਵ ਦਿਖਾਉਣ ਲਈ ਅਧਿਕਤਮ ਹੁੰਦਾ ਹੈ। ਇੱਕ ਉਤਪਾਦਨ ਪ੍ਰਣਾਲੀ ਇੱਕ ਵੱਖਰਾ ਸਵਾਲ ਪੁੱਛਦੀ ਹੈ: “ਕੀ ਅਸੀਂ ਇਸਨੂੰ ਅਸਲੀ ਯੂਜ਼ਰਾਂ ਲਈ ਦੋਹਰਾਏ ਜਾ ਸਕਣ, ਸੁਰੱਖਿਅਤ ਅਤੇ ਪੇਸ਼ਗੋਈਯੋਗ ਤਰੀਕੇ ਨਾਲ ਚਲਾ ਸਕਦੇ ਹਾਂ?”
ਇੱਕ ਪ੍ਰੋਟੋਟਾਈਪ ਇੱਕ ਨੋਟਬੁੱਕ, UI ਵਿੱਚ ਇਕ ਪ੍ਰੰਪਟ, ਜਾਂ ਇਕ ਪਤਲਾ ਐਪ ਹੋ ਸਕਦਾ ਹੈ ਜੋ ਘੱਟ ਗਾਰਡਰੇਲ ਦੇ ਨਾਲ LLM ਨੂੰ ਕਾਲ ਕਰਦਾ ਹੈ। ਜੇ ਇਹ ਹੋਰ-ਮੈਨੂਅਲ ਹੋਵੇ (ਕੋਈ ਐਪ ਰੀਸੈੱਟ ਕਰਦਾ ਹੈ, ਨਤੀਜੇ ਹੱਥ ਨਾਲ ਠੀਕ ਕੀਤੇ ਜਾਂਦੇ ਹਨ, ਜਾਂ ਫੇਲ ਹੋਈ ਕਾਲਾਂ ਨੂੰ ਦੁਹਰਾਇਆ ਜਾਂਦਾ ਹੈ) ਤਾਂ ਵੀ ਠੀਕ ਹੈ।
ਇੱਕ ਉਤਪਾਦਨ AI ਫੀਚਰ ਇਕ ਵਚਨਬੱਧਤਾ ਹੈ: ਇਹ ਕਈ ਯੂਜ਼ਰਾਂ ਵਿੱਚ ਲਗਾਤਾਰ ਵਿਹਾਰ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ, ਏਜ ਕੇਸਾਂ ਨੂੰ ਸੰਭਾਲਣਾ ਚਾਹੀਦਾ ਹੈ, ਸੰਵੇਦਨਸ਼ੀਲ ਡੇਟਾ ਦੀ ਰੱਖਿਆ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ, ਬਜਟ ਅੰਦਰ ਰਹਿਣਾ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਉਦੋਂ ਵੀ ਕੰਮ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ ਜਦੋਂ ਮਾਡਲ API ਧੀਮੀ ਹੋਵੇ, ਡਾਊਨ ਹੋਵੇ, ਜਾਂ ਬਦਲ ਜਾਵੇ।
ਡੈਮੋ ਨਿਯੰਤਰਿਤ ਹੁੰਦੇ ਹਨ: ਕਿਉਰੇਟ ਕੀਤੇ ਪ੍ਰੰਪਟ, ਪੇਸ਼ਗੋਈਯੋਗ ਇਨਪੁੱਟ, ਅਤੇ ਇੱਕ ਧੀਰਜ ਵਾਲਾ ਦਰਸ਼ਕ। ਅਸਲ ਵਰਤੋਂ ਗੁੰਝਲਦਾਰ ਹੁੰਦੀ ਹੈ।
ਯੂਜ਼ਰ ਲੰਬੇ ਦਸਤਾਵੇਜ਼ ਨਕਲ ਕਰਦੇ ਹਨ, ਅਸਪਸ਼ਟ ਸਵਾਲ ਪੁੱਛਦੇ ਹਨ, ਸਿਸਟਮ ਨੂੰ “ਤੋੜਨ” ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਹਨ, ਜਾਂ ਅਣਜਾਣੇ ਤੌਰ 'ਤੇ ਘੱਟ ਸੰਦਰਭ ਮੁਹੱਈਆ ਕਰਦੇ ਹਨ। LLM ਛੋਟੀ ਇਨਪੁੱਟ ਬਦਲਾਵਾਂ ਤੇ ਸੰਵੇਦਨਸ਼ੀਲ ਹੁੰਦੇ ਹਨ, ਅਤੇ ਤੁਹਾਡਾ ਪ੍ਰੋਟੋਟਾਈਪ ਉਨ੍ਹਾਂ ਧਾਰਣਾਵਾਂ 'ਤੇ ਨਿਰਭਰ ਹੋ ਸਕਦਾ ਹੈ ਜੋ ਸਕੇਲ 'ਤੇ ਸਹੀ ਨਹੀਂ ਰਹਿੰਦੀਆਂ—ਜਿਵੇਂ ਥਿਰ ਲੈਟੈਂਸੀ, ਦਰਿਆਫ਼ਤੀ ਰੇਟ-ਲਿਮਿਟ, ਜਾਂ ਇੱਕ ਹੀ ਮਾਡਲ ਵਰਜਨ ਜੋ ਹਮੇਸ਼ਾ ਇੱਕੋ ਜਿਹੇ ਆਉਟਪੁੱਟ ਦਿੰਦਾ ਹੈ।
ਉਤਨਾ ਹੀ ਮਹੱਤਵਪੂਰਣ: ਇੱਕ ਡੈਮੋ ਅਕਸਰ ਮਨੁੱਖੀ ਕੋਸ਼ਿਸ਼ ਨੂੰ ਛੁਪਾ ਲੈਂਦਾ ਹੈ। ਜੇ ਕਿਸੇ ਟੀਮਮੈਂਬਰ ਨੇ ਚੁੱਪਕੇ ਨਾਲ ਪ੍ਰੰਪਟ ਨੂੰ ਮੁੜ-ਚਲਾਇਆ, ਸ਼ਬਦ ਬਦਲੇ, ਜਾਂ ਸਭ ਤੋਂ ਵਧੀਆ ਆਉਟਪੁੱਟ ਚੁਣਿਆ, ਤਾਂ ਇਹ ਕੋਈ ਫੀਚਰ ਨਹੀਂ—ਇਹ ਇੱਕ ਵਰਕਫਲੋ ਹੈ ਜਿਸ ਨੂੰ ਤੁਸੀਂ ਆਟੋਮੇਟ ਕਰਨਾ ਪਵੇਗਾ।
ਉਤਪਾਦਨ ਵੱਲ ਵਧਣਾ UI ਨੂੰ ਪਾਲਿਸ਼ ਕਰਨ ਬਾਰੇ ਨਹੀਂ ਹੈ। ਇਹ ਇੱਕ AI ਵਿਹਾਰ ਨੂੰ ਇੱਕ ਭਰੋਸੇਯੋਗ ਉਤਪਾਦੀ ਸਮਰੱਥਾ ਵਿੱਚ ਤਬਦੀਲ ਕਰਨ ਬਾਰੇ ਹੈ।
ਇੱਕ ਵਰਤੋਂਯੋਗ ਨਿਯਮ: ਜੇ ਫੀਚਰ ਗਾਹਕ ਦੇ ਫ਼ੈਸਲਿਆਂ ਨੂੰ ਪ੍ਰਭਾਵਤ ਕਰਦਾ ਹੈ, ਨਿੱਜੀ ਡੇਟਾ ਨੂੰ ਛੂਹਦਾ ਹੈ, ਜਾਂ ਤੁਸੀਂ ਇਸਨੂੰ ਕੋਰ ਮੈਟ੍ਰਿਕ ਵੱਜੋਂ ਮਾਪਣਾ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ ਆਪਣੇ ਮਾਨਸਿਕਤਾ ਨੂੰ “ਪ੍ਰੰਪਟਿੰਗ” ਤੋਂ ਬਦਲਕੇ ਇੱਕ AI ਪ੍ਰਣਾਲੀ ਦੀ ਇੰਜੀਨੀਅਰਿੰਗ ਵੱਲ ਲਿਆਓ—ਸਾਫ਼ ਸਫਲਤਾ ਮਾਪਦੰਡ, ਮੁਲਾਂਕਣ, ਮਾਨੀਟਰਿੰਗ, ਅਤੇ ਸੁਰੱਖਿਆ ਚੈੱਕ ਸਮੇਤ।
ਜੇ ਤੁਸੀਂ ਤੇਜ਼ੀ ਨਾਲ ਬਣਾਉਂਦੇ ਹੋ, ਤਾਂ ਪਲੇਟਫਾਰਮ ਜਿਵੇਂ Koder.ai ਤੁਹਾਨੂੰ ਵਿਚਾਰ ਤੋਂ ਕਾਰਗਰ ਐਪ ਤੱਕ ਤੇਜ਼ی ਨਾਲ ਲੈ ਜਾ ਸਕਦੇ ਹਨ (ਵੈੱਬ React, ਬੈਕਐਂਡ Go + PostgreSQL, ਮੋਬਾਈਲ Flutter)। ਕੁੰਜੀ ਗੱਲ ਇਹ ਹੈ ਕਿ ਇਸ ਤੇਜ਼ੀ ਨੂੰ ਪ੍ਰੋਟੋਟਾਈਪ ਲਾਭ ਵਜੋਂ ਵਰਤੋ—ਨਹੀਂ ਤਾਂ ਉਤਪਾਦਨ ਮਜ਼ਬੂਤੀ ਛੱਡ ਦਿਓ। ਜਦੋਂ ਯੂਜ਼ਰ ਇਸ 'ਤੇ ਨਿਰਭਰ ਹੋ ਜਾਂਦੇ ਹਨ, ਤਾਂ ਤੁਹਾਨੂੰ ਹਾਲੇ ਵੀ ਹੇਠ ਲਿਖੀਆਂ ਭਰੋਸੇਯੋਗਤਾ, ਸੁਰੱਖਿਆ ਅਤੇ ਓਪਰੇਸ਼ਨਲ ਕੰਟਰੋਲ ਦੀ ਲੋੜ ਪਏਗੀ।
ਪ੍ਰੋਟੋਟਾਈਪ ਸਿੱਖਣ ਲਈ ਹੁੰਦਾ ਹੈ: “ਕੀ ਇਹ ਸਰਬਤ ਵਿੱਚ ਕੰਮ ਕਰਦਾ ਹੈ, ਅਤੇ ਕੀ ਯੂਜ਼ਰਾਂ ਦੀ ਦਿਲਚਸਪੀ ਹੈ?” ਉਤਪਾਦਨ ਭਰੋਸਾ ਲਈ ਹੁੰਦਾ ਹੈ: “ਕੀ ਅਸੀਂ ਰੋਜ਼ਾਨਾ, ਅਸਲ ਨਤੀਜੇ ਤੇ ਨਿਰਭਰ ਰਹਿ ਸਕਦੇ ਹਾਂ?” ਇਹ ਪੰਜ ਟਰਿਗਰ ਸਭ ਤੋਂ ਸਪਸ਼ਟ ਸੰਕੇਤ ਹਨ ਕਿ ਤੁਹਾਨੂੰ ਉਤਪਾਦਨ ਕਰਨ ਦੀ ਸ਼ੁਰੂਆਤ ਕਰنی ਚਾਹੀਦੀ ਹੈ।
ਜੇ ਡੇਲੀ ਐਕਟਿਵ ਯੂਜ਼ਰ, ਮੁੜ ਵਰਤੋਂ, ਜਾਂ ਗਾਹਕ-ਸਮਣ੍ਹੇ ਐਕਸਪੋਜ਼ਰ ਵਧ ਰਿਹਾ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਆਪਣਾ ਬਲਾਸਟ ਰੇਡੀਅਸ ਵਧਾ ਚੁੱਕੇ ਹੋ—ਜਦੋਂ AI ਗਲਤ ਹੋਵੇ, ਧੀਮੀ ਹੋਵੇ, ਜਾਂ ਉਪਲਬਧ ਨਾ ਹੋਵੇ ਤਾਂ ਪ੍ਰਭਾਵਿਤ ਲੋਕਾਂ ਦੀ ਗਿਣਤੀ।
ਫੈਸਲਾ-ਬਿੰਦੂ: ਵਿਕਾਸ ਤੁਹਾਡੀ ਸਮਰੱਥਾ ਤੋਂ ਅੱਗੇ ਨਿਕਲਣ ਤੋਂ ਪਹਿਲਾਂ ਇੰਜੀਨੀਅਰਿੰਗ ਸਮਾਂ ਭੇਟੋ।
ਜਦੋਂ ਟੀਮਾਂ AI ਨਤੀਜਿਆਂ ਨੂੰ ਗਾਹਕ ਈਮੇਲਾਂ, ਠੇਕਿਆਂ, ਫੈਸਲਿਆਂ ਜਾਂ ਵਿੱਤੀ ਰਿਪੋਰਟਿੰਗ ਵਿੱਚ ਕਾਪੀ ਕਰਦੀਆਂ ਹਨ, ਤਾਂ ਫੇਲ ਹੋਣ 'ਤੇ ਅਸਲੀ ਲਾਗਤ ਬਣਦੀ ਹੈ।
ਪ੍ਰਸ਼ਨ ਪੁੱਛੋ: ਜੇ ਇਹ ਫੀਚਰ 24 ਘੰਟੇ ਬੰਦ ਰਹੇ ਤਾਂ ਕੀ ਟੁੱਟੇਗਾ? ਜੇ ਜਵਾਬ “ਇੱਕ ਕੋਰ ਵਰਕਫਲੋ ਰੁਕ ਜਾਵੇਗਾ” ਹੈ, ਤਾਂ ਇਹ ਹੁਣ ਪ੍ਰੋਟੋਟਾਈਪ ਨਹੀਂ ਰਿਹਾ।
ਜਦੋਂ ਤੁਸੀਂ ਨਿਯੰਤਰਿਤ ਡੇਟਾ, ਨਿੱਜੀ ਡੇਟਾ ਜਾਂ ਗਾਹਕ ਰਾਜ਼ਦਾਰੀ ਨੂੰ ਹੇਠਾਂ ਲੈਂਦੇ ਹੋ, ਤਾਂ ਤੁਹਾਨੂੰ ਰਸਤਾ-ਰਾਸ਼ਟਰ ਕੰਟਰੋਲ (ਐਕਸੈਸ, ਰਿਟੇਨਸ਼ਨ, ਵੈਂਡਰ ਰਵੀਊ, ਆਡਿਟ ਟਰੇਲ) ਦੀ ਲੋੜ ਹੋਵੇਗੀ।
ਫੈਸਲਾ-ਬਿੰਦੂ: ਫੈਲ੍ਹ ਵਿਸਥਾਰ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਰੁਕੋ ਜਦ ਤੱਕ ਤੁਸੀਂ ਦਿਖਾ ਨਾ ਸਕੋ ਕਿ ਕਿਹੜਾ ਡੇਟਾ ਕਿੱਥੇ ਭੇਜਿਆ ਜਾਂਦਾ, ਸਟੋਰ ਹੁੰਦਾ ਅਤੇ ਲੌਗ ਹੁੰਦਾ ਹੈ।
ਛੋਟੇ ਪ੍ਰੰਪਟ ਸੰਸ਼ੋਧਨ, ਟੂਲ ਬਦਲਾਅ, ਜਾਂ ਮਾਡਲ ਪ੍ਰੋਵਾਇਡਰ ਅਪਡੇਟ ਰਾਤੋ-ਰਾਤ ਆਉਟਪੁੱਟ ਬਦਲ ਸਕਦੇ ਹਨ। ਜੇ ਤੁਸੀਂ ਕਦੇ ਕਿਹਾ ਹੈ “ਇਹ ਕੱਲ੍ਹ ਚਲ ਰਿਹਾ ਸੀ,” ਤਾਂ ਤੁਹਾਨੂੰ ਵਰਜਨਿੰਗ, ਮੁਲਾਂਕਣ, ਅਤੇ ਰੋਲਬੈਕ ਯੋਜਨਾਵਾਂ ਦੀ ਲੋੜ ਹੈ।
ਜਿਵੇਂ-जਿਵੇਂ ਇਨਪੁੱਟ ਬਦਲਦੇ ਹਨ (ਸਿਜ਼ਨਲ, ਨਵੇਂ ਉਤਪਾਦ, ਨਵੀਆਂ ਭਾਸ਼ਾਵਾਂ), ਸ਼ੁੱਧਤਾ ਚੁੱਪ ਚਾਪ ਘਟ ਸਕਦੀ ਹੈ।
ਫੈਸਲਾ-ਬਿੰਦੂ: ਸਫਲਤਾ/ਅਸਫਲਤਾ ਮੈਟ੍ਰਿਕਸ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ ਅਤੇ ਵਿਸਥਾਰ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਮਾਨੀਟਰਿੰਗ ਬੇਸਲਾਈਨ ਸੈੱਟ ਕਰੋ।
ਇੱਕ ਪ੍ਰੋਟੋਟਾਈਪ "ਕਾਫੀ ਚੰਗਾ" ਮਹਿਸੂਸ ਕਰ ਸਕਦਾ ਹੈ ਜਦ ਤੱਕ ਇਹ ਅਸਲ ਯੂਜ਼ਰਾਂ, ਅਸਲ ਪੈਸਿਆਂ, ਜਾਂ ਅਸਲ ਓਪਰੇਸ਼ਨਾਂ ਨੂੰ ਪ੍ਰਭਾਵਤ ਨਾ ਕਰੇ। ਉਤਪਾਦਨ ਵੱਲ ਬਦਲਣਾ ਆਮ ਤੌਰ 'ਤੇ ਇਕ ਮੈਟ੍ਰਿਕ ਦੀ ਵਜ੍ਹਾ ਨਾਲ ਨਹੀਂ ਹੁੰਦਾ—ਇਹ ਤਿੰਨ ਦਿਸ਼ਾਵਾਂ ਤੋਂ ਆ ਰਹੇ ਸੰਕੇਤਾਂ ਦਾ ਰੁਝਾਨ ਹੁੰਦਾ ਹੈ।
ਜਦੋਂ ਯੂਜ਼ਰ ਸਿਸਟਮ ਨੂੰ ਇੱਕ ਖਿਲੌਣਾ ਸਮਝਦੇ ਹਨ, ਤਾਂ ਖਾਮੀਆਂ ਬਰਦਾਸ਼ਤ ਕੀਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ। ਜਦੋਂ ਉਹ ਇਸ 'ਤੇ ਨਿਰਭਰ ਹੋਣ ਲੱਗਦੇ ਹਨ, ਛੋਟੇ ਫੇਲ ਮਹਿੰਗੇ ਪੈ ਸਕਦੇ ਹਨ।
ਨਿਹਾਰੋ: ਗਲਤ ਜਾਂ ਗੈਰ-ਅਨੁਕੂਲ ਜਵਾਬਾਂ ਬਾਰੇ ਸ਼ਿਕਾਇਤਾਂ, ਸਿਸਟਮ ਕੀ ਕਰ ਸਕਦਾ/ਨਹੀਂ ਕਰ ਸਕਦਾ ਬਾਰੇ ਭ੍ਰਮ, ਬਾਰ-ਬਾਰ "ਨਹੀਂ, ਮੇਰਾ ਮਤਲਬ ਇਹ ਨਹੀਂ ਸੀ" ਵਰਗੀਆਂ ਸੋਧਾਂ, ਅਤੇ ਸਹਾਇਤਾ ਟਿਕਟਾਂ ਦਾ ਵਧਣਾ। ਇਕ ਜ਼ੋਰਦਾਰ ਸੰਕੇਤ ਹੈ ਜਦ ਯੂਜ਼ਰ ਵਰਕਅਰਾਊਂਡ ਬਣਾਉਂਦੇ ਹਨ ("ਮੈਂ ਹਮੇਸ਼ਾ ਤਿੰਨ ਵਾਰੀ ਦੁਬਾਰਾ ਲਿਖਦਾ ਹਾਂ")—ਉਹ ਛੁਪਿਆ ਘਰੜਾ ਅਪਣਾਉ ਨੂੰ ਰੋਕੇਗਾ।
ਬਿਜ਼ਨਸ ਦਾ ਪਲ ਆਉਂਦਾ ਹੈ ਜਦ ਨਤੀਜਾ ਰੇਵਿਨਿਊ, ਅਨੁਕੂਲਤਾ, ਜਾਂ ਗਾਹਕੀ ਵਚਨਾਂ ਨੂੰ ਪ੍ਰਭਾਵਤ ਕਰਦਾ ਹੈ।
ਨਿਹਾਰੋ: ਗਾਹਕ SLA ਮੰਗਦੇ ਹਨ, ਸੇਲਜ਼ ਫੀਚਰ ਨੂੰ ਅੰਤਰਕੜੀ ਤੌਰ ਤੇ ਪੇਸ਼ ਕਰਦੇ ਹਨ, ਟੀਮਾਂ ਸਿਸਟਮ 'ਤੇ ਡੈਡਲਾਈਨ ਮਿਲਣ ਲਈ ਨਿਰਭਰ ਹੁੰਦੇ ਹਨ, ਜਾਂ ਲੀਡਰਸ਼ਿਪ ਪੇਸ਼ਗੋਈਯੋਗ ਪ੍ਰਦਰਸ਼ਨ ਅਤੇ ਲਾਗਤ ਦੀ ਉਮੀਦ ਰੱਖਦੀ ਹੈ। ਜੇ "ਅਸਥਾਈ" ਹੁਣ ਇੱਕ ਕੋਰ ਵਰਕਫਲੋ ਦਾ ਹਿੱਸਾ ਬਣ ਜਾਵੇ, ਤਾਂ ਤੁਸੀਂ ਪਹਿਲਾਂ ਹੀ ਉਤਪਾਦਨ ਵਿੱਚ ਹੋ—ਭਾਵੇਂ ਸਿਸਟਮ ਤਿਆਰ ਹੈ ਜਾਂ ਨਹੀਂ।
ਇੰਜੀਨੀਅਰਿੰਗ ਦਰਦ ਅਕਸਰ ਸਭ ਤੋਂ ਸਾਫ਼ ਇਸ਼ਾਰਾ ਹੁੰਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਤਕਨੀਕੀ ਕਰਜ਼ੇ ਦੀ ਬਿਆਜ ਭਗਤ ਰਹੇ ਹੋ।
ਨਿਹਾਰੋ: ਫੇਲ ਹੋਣ 'ਤੇ ਹੱਥ ਨਾਲ ਠੀਕ ਕਰਨ, ਐਮਰਜੈਂਸੀ ਤੌਰ 'ਤੇ ਪ੍ਰੰਪਟ ਸੋਧ, ਨਾਜੁਕ glue ਕੋਡ ਜੋ API ਬਦਲਣ 'ਤੇ ਟੁੱਟ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਦੁਹਰਾਉਣਯੋਗ ਮੁਲਾਂਕਣ ਦੀ ਘਾਟ। ਜੇ ਕੇਵਲ ਇੱਕ ਵਿਅਕਤੀ ਹੀ ਇਸਨੂੰ ਚਲਾਉਂਦਾ ਰੱਖ ਸਕਦਾ ਹੈ, ਤਾਂ ਇਹ ਉਤਪਾਦ ਨਹੀਂ—ਇੱਕ ਜ਼ਿੰਦਾ ਡੈਮੋ ਹੈ।
ਇਕ ਹਲਕਾ ਜਿਹਾ ਟੇਬਲ ਵਰਤੋਂ ਜੋ ਨਿਰੀਖਣਾਂ ਨੂੰ ਵਾਸ਼ਤਵਿਕ ਹਾਰਡਨਿੰਗ ਕੰਮ ਵਿੱਚ ਬਦਲ ਦੇਵੇ:
| ਸੰਕੇਤ | ਰਿਸਕ | ਜ਼ਰੂਰੀ ਮਜ਼ਬੂਤੀਕਰਨ ਕਦਮ |
|---|---|---|
| ਗਲਤ ਜਵਾਬਾਂ ਲਈ ਵਧ ਰਹੇ ਸਪੋਰਟ ਟਿਕਟ | ਭਰੋਸਾ ਘਟਣਾ, churn | ਗਾਰਡਰੇਲ ਜੋੜੋ, ਐਵਲੂਏਸ਼ਨ ਸੈੱਟ ਸੁਧਾਰੋ, UX ਉਮੀਦਾਂ ਕਠੋਰ ਕਰੋ |
| ਗਾਹਕ SLA ਮੰਗਦੇ ਹਨ | ਠੇਕਾ ਜੋਖਮ | ਅਪਟਾਈਮ/ਲੈਟੈਂਸੀ ਟਾਰਗੇਟ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ, ਮਾਨੀਟਰਿੰਗ + ਇਨਸਿਡੈਂਟ ਪ੍ਰਕਿਰਿਆ ਜੋੜੋ |
| ਹਫ਼ਤਾਵਾਰ ਪ੍ਰੰਪਟ ਹੌਟਫਿਕਸ | ਅਣਪੇਖਿਆ ਵਰਤਾਰਾ | ਪ੍ਰੰਪਟ ਵਰਜਨਿੰਗ, ਰਿਗਰੇਸ਼ਨ ਟੈਸਟ ਜੋੜੋ, ਬਦਲਾਅਾਂ ਦੀ ਰਿਵਿਊ ਕੋਡ ਵਾਂਗ |
| ਆਉਟਪੁੱਟ ਦੀ ਹੱਥ ਦੀ “ਸਫਾਈ” | ਓਪਰੇਸ਼ਨਲ ਝੰਜਟ | ਵੈਰੀਡੇਸ਼ਨ ਆਟੋਮੇਟ ਕਰੋ, ਫਾਲਬੈਕ ਪਾਥ ਜੋੜੋ, ਡੇਟਾ ਹੈਂਡਲਿੰਗ ਸੁਧਾਰੋ |
ਜੇ ਤੁਸੀਂ ਇਸ ਟੇਬਲ ਨੂੰ ਸੱਚੇ ਉਦਾਹਰਣਾਂ ਨਾਲ ਭਰ ਸਕਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਸੰਭਵ ਹੈ ਕਿ ਪ੍ਰੋਟੋਟਾਈਪ ਤੋਂ ਬਾਹਰ ਆ ਚੁਕੇ ਹੋ—ਅਤੇ ਹੁਣ ਉਤਪਾਦਨ ਕਦਮ ਯੋਜਨਾਬੱਧ ਕਰਨ ਲਈ ਤਿਆਰ ਹੋ।
ਇੱਕ ਪ੍ਰੋਟੋਟਾਈਪ ਕੁਝ ਡੈਮੋ ਵਿੱਚ "ਕਾਫੀ ਚੰਗਾ" ਲੱਗ ਸਕਦਾ ਹੈ। ਉਤਪਾਦਨ ਵੱਖਰਾ ਹੈ: ਤੁਹਾਨੂੰ ਸਪਸ਼ਟ ਪਾਸ/ਫੇਲ ਨਿਯਮ ਚਾਹੀਦੇ ਹਨ ਜੋ ਤੁਹਾਨੂੰ ਆਤਮਵਿਸ਼ਵਾਸ ਨਾਲ ਸ਼ਿਪ ਕਰਨ ਦੇਣ ਅਤੇ ਔਖਾ ਸਮਾਂ ਹੋਣ 'ਤੇ ਰੋਕਣ।
3–5 ਮੈਟ੍ਰਿਕਸ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ ਜੋ ਅਸਲ ਮੁੱਲ ਦਰਸਾਂਦੇ ਹਨ, ਨਾ ਕੇ ਅੰਦਰੂਨੀ ਧਾਰਣਾਂ। ਆਮ ਉਤਪਾਦਨ ਮੈਟ੍ਰਿਕਸ:
ਲਕੜੀ-ਚੁਣੋ ਹਫ਼ਤਾਵਾਰ ਨਿਸ਼ਾਨੇ: ਉਦਾਹਰਣ “ਸਾਡੇ ਐਵਲੂਏਸ਼ਨ ਸੈੱਟ 'ਤੇ ≥85% ਟਾਸਕ ਸਫਲਤਾ ਅਤੇ 2 ਹਫ਼ਤਿਆਂ 'ਚ ≥4.2/5 CSAT.”
ਅਸਫਲਤਾ ਮਾਪਦੰਡ ਵੀ ਵਧੇਰੇ ਮਹੱਤਵਪੂਰਣ ਹੁੰਦੇ ਹਨ। LLM ਐਪ ਲਈ ਆਮ ਹਨ:
ਸਪਸ਼ਟ ਕਦੇ-ਵੀ-ਨਹੀਂ-ਹੋਣਾ ਨਿਯਮ ਜੋੜੋ (ਉਦਾਹਰਣ: “PII ਕਦੇ ਵੀ ਰਿਵੀਲ ਨਾ ਹੋਵੇ”, “ਰਿਫੰਡ ਬਣਾਏ ਨਾ ਜਾਣ” , “ਕਦੇ ਵੀ ਐਸੇ ਦਾਅਵੇ ਨਾ ਕਰਨ ਜੋ ਕੀਤੇ ਨਹੀਂ ਗਏ”)। ਇਹ ਆਟੋਮੈਟਿਕ ਬਲਾਕਿੰਗ, ਸੇਫ ਫਾਲਬੈਕ, ਅਤੇ ਇਨਸਿਡੈਂਟ ਰਿਵਿਊ ਟ੍ਰਿਗਰ ਕਰਨੇ ਚਾਹੀਦੇ ਹਨ।
ਲਿਖੋ:
ਐਵਲੂਏਸ਼ਨ ਸੈੱਟ ਨੂੰ ਇੱਕ ਉਤਪਾਦੀ ਐਸੈਟ ਵਾਂਗੋ ਸTreat ਕਰੋ: ਜੇ ਕਿਸੇ ਦੀ ਮਲਕੀਅਤ ਨਹੀਂ, ਤਾਂ ਗੁಣਵੱਤਾ ਡ੍ਰਿਫਟ करेगी ਅਤੇ ਅਚਾਨਕ ਫੇਲ ਨਜ਼ਰ ਆਉਣਗੇ।
ਇੱਕ ਪ੍ਰੋਟੋਟਾਈਪ ਮਨੁੱਖ ਦੇ ਨਜ਼ਰ ਵਿੱਚ “ਕਾਫੀ ਚੰਗਾ” ਹੋ ਸਕਦਾ ਹੈ। ਉਤਪਾਦਨ ਨੂੰ ਪੇਸ਼ਗੋਈਯੋਗ ਵਰਤਾਰਾ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ ਜਦ ਕੋਈ ਦੇਖ ਨਹੀਂ ਰਿਹਾ—ਖਾਸ ਕਰਕੇ ਬੁਰੇ ਦਿਨਾਂ 'ਤੇ।
ਅੱਪਟਾਈਮ: ਫੀਚਰ ਉਪਲਬਧ ਹੈ ਜਾਂ ਨਹੀਂ। ਗਾਹਕ-ਸਮਣੇ AI ਐਸਿਸਟੈਂਟ ਲਈ, ਤੁਸੀਂ ਆਮ ਤੌਰ 'ਤੇ ਇੱਕ ਟਾਪ ਉਦਾਹਰਣ ਰੱਖੋਗੇ (ਉਦਾਹਰਣ: “ਮਹੀਨਾਵਾਰ 99.9%”) ਅਤੇ ਇਹ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ ਕਿ “ਡਾਊਨ” ਕੀ ਮਾਣਿਆ ਜਾਵੇਗਾ (API ਗਲਤੀਆਂ, ਟਾਈਮਆਉਟ, ਜਾਂ ਬੇਕਾਰ-ਸਲੋਡਾਊਨ)।
ਲੈਟੈਂਸੀ: ਯੂਜ਼ਰ ਕਿੰਨੀ ਦੇਰ ਰੁਕਦੇ ਹਨ। ਸਿਰਫ਼ ਔਸਤ ਨਹੀਂ, ਸਲੋ ਟੇਲ (p95/p99) ਨੂੰ ਵੀ ਟਰੈਕ ਕਰੋ। ਆਮ ਉਤਪਾਦਨ ਪੈਟਰਨ ਇੱਕ ਹਾਰਡ ਟਾਈਮਆਉਟ ਸੈੱਟ ਕਰਨਾ ਹੈ (ਜਿਵੇਂ 10–20 ਸਕਿੰਟ) ਅਤੇ ਅਗਲੇ ਕਦਮ ਦਾ ਫੈਸਲਾ ਕਰਨਾ—ਕਿਉਂਕਿ ਲੰਮਾ ਉਡੀਕਣਾ ਬੇਹੱਦ ਹੋਣ ਤੋਂ ਵੱਧ ਖ਼ਰਾਬ ਹੈ।
ਟਾਈਮਆਉਟ ਹੈਂਡਲਿੰਗ ਵਿੱਚ ਸ਼ਾਮਲ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ:
ਪ੍ਰਾਈਮਰੀ ਰਾਹ ਅਤੇ ਘੱਟੋ ਘੱਟ ਇੱਕ ਫਾਲਬੈਕ ਯੋਜਨਾ ਰੱਖੋ:
ਇਹ ਹੈ ਗ੍ਰੇਸਫੁਲ ਡੀਗਰੇਡੇਸ਼ਨ: ਅਨੁਭਵ ਸਧਾਰਾ ਹੋਵੇ, ਨ ਕਿ ਟੁੱਟਿਆ ਹੋਇਆ। ਉਦਾਹਰਨ: ਜੇ “ਫੁੱਲ” ਐਸਿਸਟੈਂਟ ਦਸਤਾਵੇਜ਼ ਸਮੇਂ 'ਤੇ ਪ੍ਰਾਪਤ ਨਹੀਂ ਕਰ ਸਕਦਾ, ਤਾਂ ਇਹ ਇੱਕ ਸੰਖੇਪ ਜਵਾਬ ਦੇ ਹੋ ਸਕਦਾ ਹੈ, ਆਉਟਪੁੱਟ ਨਾਲ ਟਾਪ ਸਰੋਤਾਂ ਦੀ ਸੂਚੀ ਦੇ ਸਕਦਾ ਹੈ ਅਤੇ ਐਸਕਲੇਟ ਕਰਨ ਦੀ ਪੇਸ਼ਕਸ਼ ਕਰ ਸਕਦਾ ਹੈ—ਬਦਲੇ ਵਿੱਚ ਐਰਰ ਵਾਪਸ ਕਰਨ ਦੇ।
ਭਰੋਸੇਯੋਗਤਾ ਟ੍ਰੈਫਿਕ ਕੰਟਰੋਲ 'ਤੇ ਵੀ ਨਿਰਭਰ ਕਰਦੀ ਹੈ। ਰੇਟ ਲਿਮਿਟਸ ਅਚਾਨਕ ਸਪਾਈਕਸ ਨੂੰ ਰੋਕਦੇ ਹਨ। ਕੰਕਰਨਸੀ ਇਸ ਗੱਲ ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਇੱਕੇ ਸਮੇਂ ਕਿੰਨੀਆਂ ਬੇਨਤੀਆਂ ਸੰਭਾਲ ਸਕਦੇ ਹੋ; ਜਿਆਦਾ ਹੋਣ 'ਤੇ ਸਭ ਲਈ ਜਵਾਬ ਧੀਮੇ ਹੋ ਜਾਂਦੇ ਹਨ। ਕਿਊਜ਼ ਦੀ ਵਰਤੋਂ ਰਿਕਵੇਸਟਾਂ ਨੂੰ ਤੁਰੰਤ ਫੇਲ ਹੋਣ ਦੀ ਬਜਾਏ ਇਕ ਛੋਟੇ ਸਮੇਂ ਲਈ ਲਾਈਨ ਵਿੱਚ ਰੱਖਣ ਲਈ ਕੀਤੀ ਜਾਂਦੀ ਹੈ, ਜਿਸ ਨਾਲ ਤੁਹਾਨੂੰ ਸਕੇਲ ਕਰਨ ਜਾਂ ਫਾਲਬੈਕ 'ਤੇ ਸੁਵਿਧਾ ਮਿਲਦੀ ਹੈ।
ਜੇ ਤੁਹਾਡਾ ਪ੍ਰੋਟੋਟਾਈਪ ਅਸਲ ਗਾਹਕ ਡੇਟਾ ਨੂੰ ਛੂਹਦਾ ਹੈ, ਤਾਂ “ਬਾਅਦ ਵਿੱਚ ਠੀਕ ਕਰਾਂਗੇ” ਵਿਕਲਪ ਨਹੀਂ ਰਹਿੰਦਾ। ਲਾਂਚ ਤੋਂ ਪਹਿਲਾਂ ਤੁਹਾਨੂੰ ਇਹ ਸਾਫ਼ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ AI ਫੀਚਰ ਕਿਹੜਾ ਡੇਟਾ ਦੇਖ ਸਕਦਾ ਹੈ, ਉਹ ਕਿੱਥੇ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਕੌਣ ਇਸਨੂੰ ਵੇਖ ਸਕਦਾ ਹੈ।
ਇੱਕ ਸਧਾਰਣ ਆਰੇਖਾ ਜਾਂ ਟੇਬਲ ਨਾਲ ਹਰ ਰਾਹ ਟਰੈੱਕ ਕਰੋ:
ਲਕੜੀ-ਮਕਸਦ: “ਣਿਜਾਣੇ” ਮੰਜ਼ਿਲਾਂ ਨੂੰ ਖ਼ਤਮ ਕਰੋ—ਖ਼ਾਸ ਕਰਕੇ ਲੌਗਾਂ ਵਿੱਚ।
ਇਸ ਚੈਕਲਿਸਟ ਨੂੰ ਹਰੇਕ ਰਿਲੀਜ਼ ਦੇ ਗੇਟ ਵਜੋਂ ਵਰਤੋ—ਕਾਫੀ ਛੋਟੀ ਕਿ ਹਰ ਵਾਰੀ ਚੱਲੇ ਅਤੇ ਕਾਫੀ ਸਖ਼ਤ ਕਿ ਅਚਾਨਕ ਘਟਨਾਵਾਂ ਰੋਕੇ ਜਾਣ।
ਇੱਕ ਪ੍ਰੋਟੋਟਾਈਪ ਅਕਸਰ "ਚਲਦਾ" ਹੈ ਕਿਉਂਕਿ ਤੁਸੀਂ ਕੁਝ ਦੋਸਤਾਨਾ ਪ੍ਰੰਪਟ آزਮਾਏ। ਉਤਪਾਦਨ ਵੱਖਰਾ ਹੈ: ਯੂਜ਼ਰ ਗੁੰਝਲਦਾਰ, ਅਸਪਸ਼ਟ ਸਵਾਲ ਪੁੱਛਣਗੇ, ਸੰਵੇਦਨਸ਼ੀਲ ਡੇਟਾ inject ਕਰਨਗੇ, ਅਤੇ ਇਕਸਾਰ ਵਰਤਾਰਾ ਦੀ ਉਮੀਦ ਰੱਖਣਗੇ। ਇਸਦਾ ਅਰਥ ਹੈ ਕਿ ਤੁਹਾਨੂੰ ਯੂਨੀਟ ਟੈਸਟ ਤੋਂ ਇਲਾਵਾ ਹੋਰ ਪਰਖਾਂ ਦੀ ਲੋੜ ਹੋਵੇਗੀ।
ਯੂਨੀਟ ਟੈਸਟ ਅਜੇ ਵੀ ਮਹੱਤਵਪੂਰਣ ਹਨ (API ਠੇਕੇ, auth, ਇਨਪੁੱਟ ਵੈਲਿਡੇਸ਼ਨ, ਕੈਸ਼ਿੰਗ), ਪਰ ਇਹ ਦੱਸਦੇ ਨਹੀਂ ਕਿ ਜਦ ਪ੍ਰੰਪਟ, ਟੂਲ, ਜਾਂ ਮਾਡਲ ਬਦਲੇਗਾ ਤਾਂ ਮਾਡਲ ਕਿੰਨਾ ਸਹਾਇਕ, ਸੁਰੱਖਿਅਤ ਅਤੇ ਸਹੀ ਰਹੇਗਾ।
ਇੱਕ ਛੋਟਾ ਗੋਲਡ ਸੈੱਟ ਬਣਾਓ: 50–300 ਪ੍ਰਤਿਨਿਧੀ ਕਵੇਰੀਆਂ ਨਾਲ ਉਮੀਦਸ਼ੁਦਾ ਨਤੀਜੇ। “ਉਮੀਦ” ਦਾ ਮਤਲਬ ਹਮੇਸ਼ਾਂ ਇਕ ਪਰਫੈਕਟ ਜਵਾਬ ਨਹੀਂ—ਇਹ ਇੱਕ ਰੂਬਰਿਕ ਹੋ ਸਕਦੀ ਹੈ (ਸਹੀ, ਟੋਨ, ਹਵਾਲਾ ਲਾਜ਼ਮੀ, ਇਨਕਾਰ ਵਰਤਾਰਾ)।
ਦੋ ਖ਼ਾਸ ਸ਼੍ਰੇਣੀਆਂ ਸ਼ਾਮਲ ਕਰੋ:
ਇਸ ਸਵੀਟ ਨੂੰ ਹਰ ਮਹੱਤਵਪੂਰਨ ਬਦਲਾਅ 'ਤੇ ਚਲਾਓ: ਪ੍ਰੰਪਟ ਸੋਧ, ਟੂਲ ਰਾਊਟਿੰਗ ਲਾਜਿਕ, ਰੀਟ੍ਰੀਵਲ ਸੈਟਿੰਗ, ਮਾਡਲ ਅਪਗਰੇਡ, ਅਤੇ ਪੋਸਟ-ਪ੍ਰੋਸੈਸਿੰਗ।
ਓਫਲਾਈਨ ਸਕੋਰ ਭਰੋਸੇਯੋਗ ਨਹੀਂ ਹੋ ਸਕਦੇ, ਇਸ ਲਈ ਨਿਯੰਤਰਿਤ ਰੋਲਆਊਟ ਪੈਟਰਨ ਨਾਲ ਪ੍ਰੋਡਕਸ਼ਨ 'ਚ ਵੈਧਤਾ ਕਰੋ:
ਇਕ ਸਧਾਰਣ ਗੇਟ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ:
ਇਸ ਨਾਲ “ਡੈਮੋ ਵਿੱਚ ਵਧੀਆ ਲੱਗਿਆ” ਦਾ ਫੈਸਲਾ ਇਕ ਦੁਹਰਾਉਣਯੋਗ ਰਿਲੀਜ਼ ਪ੍ਰਕਿਰਿਆ ਵਿੱਚ ਬਦਲ ਜਾਂਦਾ ਹੈ।
ਜਦ ਅਸਲ ਯੂਜ਼ਰ ਤੁਹਾਡੇ AI ਫੀਚਰ 'ਤੇ ਨਿਰਭਰ ਹੋਣ, ਤਾਂ ਤੁਹਾਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਇਹ ਸਵਾਲ ਦਾ ਜਵਾਬ ਦੇਣਾ ਹੋਵੇਗਾ: ਕੀ ਹੋਇਆ? ਕਿੰਨੀ ਵਾਰੀ? ਕਿਸਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕੀਤਾ? ਕਿਹੜੀ ਮਾਡਲ ਵਰਜਨ? ਬਿਨਾਂ ਦਿੱਖਣਯੋਗਤਾ ਦੇ, ਹਰ ਘਟਨਾ ਅਟਕਲ ਬਣ ਜਾਂਦੀ ਹੈ।
ਸੈਸ਼ਨ ਨੂੰ ਦੁਬਾਰਾ ਬਣਾਉਣ ਲਈ ਕਾਫੀ ਵੇਰਵਾ ਲੌਗ ਕਰੋ, ਪਰ ਯੂਜ਼ਰ ਡੇਟਾ ਨੂੰ ਰੇਡੀਓਐਕਟਿਵ ਮੰਨੋ।
ਇੱਕ ਮਦਦਗਾਰ ਨਿਯਮ: ਜੇ ਇਹ ਵਿਹਾਰ ਨੂੰ ਸਮਝਾਉਂਦਾ ਹੈ, ਤਾਂ ਲੌਗ ਕਰੋ; ਜੇ ਇਹ ਨਿੱਜੀ ਹੈ, ਤਾਂ ਮਾਸਕ ਕਰੋ; ਜੇ ਤਾਂ ਤੁਹਾਨੂੰ ਲੋੜ ਨਹੀਂ, ਤਾਂ ਸਟੋਰ ਨਾ ਕਰੋ।
ਛੋਟੇ ਸੈੱਟ ਦੇ ਡੈਸ਼ਬੋਰਡ ਉਪਰਾਟ ਰੱਖੋ ਜੋ ਸਿਹਤ ਇੱਕ ਨਜ਼ਰ ਵਿੱਚ ਦਿਖਾਉਂਦੇ ਹਨ:
ਗੁਣਵੱਤਾ ਨੂੰ ਇਕ ਮੈਟ੍ਰਿਕ ਨਾਲ ਫੜਿਆ ਨਹੀਂ ਜਾ ਸਕਦਾ; ਇਸ ਲਈ ਕੁਝ ਪ੍ਰਾਕਸੀ ਮਿਲਾ ਕੇ ਨਮੂਨੇ ਸਮੀਖਿਆ ਕਰੋ।
ਹਰ ਛੋਟੀ ਗੜਬੜ ਕਿਸੇ ਨੂੰ ਜਗਾਉਂਦੀ ਨਹੀਂ ਹੋਣੀ ਚਾਹੀਦੀ।
ਸ਼ੋਰ-ਭਰਪੂਰ ਅਲਰਟਸ ਤੋਂ ਬਚਣ ਲਈ ਸੀਮਾ ਅਤੇ ਘੱਟੋ-ਘੱਟ ਅਵਧੀ (ਉਦਾਹਰਣ: “10 ਮਿੰਟ ਤੋਂ ਵੱਧ”) ਦਿਓ।
ਯੂਜ਼ਰ ਫੀਡਬੈਕ ਸੋਨੇ ਵਾਂਗ ਹੈ, ਪਰ ਇਹ ਨਿੱਜੀ ਡੇਟਾ ਲੀਕ ਕਰ ਸਕਦਾ ਹੈ ਜਾਂ ਬਿਆਸ ਨੂੰ ਵਧਾ ਸਕਦਾ ਹੈ।
ਜੇ ਤੁਸੀਂ ਵੇਖਣਾ ਚਾਹੁੰਦੇ ਹੋ ਕਿ ਸਕੇਲ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ “ਕਾਫੀ ਚੰਗਾ” ਕੀ ਹੈ, ਤਾਂ ਇਸਨੂੰ ਸਪਸ਼ਟ ਸਫਲਤਾ ਮਾਪਦੰਡ ਨਾਲ ਮਿਲਾਓ (ਦੇਖੋ /blog/set-production-grade-success-and-failure-criteria)।
ਇੱਕ ਪ੍ਰੋਟੋਟਾਈਪ "ਕੋਈ ਗੱਲ ਜੋ ਪਹਿਲਾਂ ਚੱਲਾ" ਸਹਿਣ ਕਰ ਸਕਦਾ ਹੈ। ਉਤਪਾਦਨ ਨਹੀਂ। ਓਪਰੇਸ਼ਨਲ ਤਿਆਰੀ ਬਦਲਾਅਾਂ ਨੂੰ ਸੁਰੱਖਿਅਤ, ਟਰੇਸਬਲ, ਅਤੇ ਵਾਪਸ ਯੋਗ ਬਣਾਉਂਦੀ ਹੈ—ਖ਼ਾਸ ਕਰਕੇ ਜਦੋਂ ਤੁਹਾਡਾ ਵਿਹਾਰ ਪ੍ਰੰਪਟ, ਮਾਡਲ, ਟੂਲ, ਅਤੇ ਡੇਟਾ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ।
LLM ਐਪਸ ਲਈ “ਕੋਡ” ਕੇਵਲ ਪ੍ਰਣਾਲੀ ਦਾ ਇਕ ਹਿੱਸਾ ਹੈ। ਇਹਨਾਂ ਨੂੰ ਪਹਿਲਾ-ਕਲਾਸ ਵਰਜਨਡ ਆਈਟਮ ਸਮਝੋ:
ਇਸ ਨੂੰ ਉੱਤਰ ਦੇਣ ਯੋਗ ਬਣਾਓ: “ਇਸ ਨਤੀਜੇ ਨੂੰ ਕਿਉਂਕਿ ਇਕਸੇਟ ਪ੍ਰੰਪਟ + ਮਾਡਲ + ਰੀਟ੍ਰੀਵਲ ਕਨਫਿਗ ਨੇ ਉਤਪੰਨ ਕੀਤਾ?”
ਰੰਟ-ਬੱਗ ਘਟਾਉਂਣ ਲਈ ਦੁਹਰਾਉਣਯੋਗਤਾ ਘੱਟੋ-ਘੱਟ ਕਰੋ।
ਡਿਪੈਂਡੇਂਸੀ ਨੂੰ ਪਿਨ ਕਰੋ (ਲਾਕਫਾਈਲ), ਰੰਟਾਈਮ ਵਾਤਾਵਰਨ ਟਰੈਕ ਕਰੋ (ਕੰਟੇਨਰ ਇਮੇਜ, OS, Python/Node ਵਰਜਨ), ਅਤੇ ਸੀਕ੍ਰੇਟਸ/ਕਨਫਿਗ ਨੂੰ ਕੋਡ ਤੋਂ ਅਲੱਗ ਰੱਖੋ। ਜੇ ਤੁਸੀਂ ਮੈਨੇਜਡ ਮਾਡਲ ਐਂਡਪਆਇੰਟ ਵਰਤਦੇ ਹੋ, ਤਾਂ ਪ੍ਰੋਵਾਇਡਰ, ਰੀਜਨ, ਅਤੇ ਉਪਲੱਬਧ ਮਾਡਲ ਵਰਜਨ ਲੌਗ ਕਰੋ।
ਸਧਾਰਨ ਪਾਈਪਲਾਈਨ ਅਪਣਾਓ: dev → staging → production, ਸਾਫ ਮਨਜ਼ੂਰੀਆਂ ਨਾਲ। ਸਟੇਜਿੰਗ ਨੂੰ ਉਤਪਾਦਨ ਵਾਂਗ ਬਰਾਬਰ ਰੱਖੋ (ਡੇਟਾ ਐਕਸੈਸ, ਰੇਟ ਲਿਮਿਟ, ਦਿੱਖਣਯੋਗਤਾ) ਪਰ ਸੁਰੱਖਿਅਤ ਟੈਸਟ ਅਕਾਊਂਟ ਵਰਤੋਂ।
ਜਦ ਤੁਸੀਂ ਪ੍ਰੰਪਟ ਜਾਂ ਰੀਟ੍ਰੀਵਲ ਸੈਟਿੰਗ ਬਦਲਦੇ ਹੋ, ਤਾਂ ਇਸਨੂੰ ਇੱਕ ਰੀਲੀਜ਼ ਵਾਂਗ ਵਰਤੋ—ਨਾ ਕਿ ਇੱਕ ਜਲਦੀ ਸੋਧ।
ਇਕ ਇਨਸਿਡੈਂਟ ਪਲੇਬੁੱਕ ਬਣਾਓ ਜਿਸ ਵਿੱਚ:
ਜੇ ਰੋਲਬੈਕ ਮੁਸ਼ਕਿਲ ਹੈ, ਤਾਂ ਤੁਹਾਡੇ ਕੋਲ ਰੀਲੀਜ਼ ਪ੍ਰਕਿਰਿਆ ਨਹੀਂ—ਇਕ ਜੋਖਮ ਹੈ।
ਜੇ ਤੁਸੀਂ ਤੇਜ਼ ਬਿਲਡ ਪਲੇਟਫਾਰਮ ਵਰਤ ਰਹੇ ਹੋ, ਤਾਂ ਉਪਰੇਸ਼ਨਲ ਫੀਚਰ ਚੁਣੋ ਜੋ ਵਾਪਸੀਯੋਗਤਾ ਆਸਾਨ ਬਣਾਉਂਦੇ ਹਨ। ਉਦਾਹਰਣ ਲਈ, Koder.ai ਸਨੈਪਸ਼ਾਟ ਅਤੇ ਰੋਲਬੈਕ, ਡਿਪਲੋਇਮੈਂਟ/ਹੋਸਟਿੰਗ ਅਤੇ ਕਸਟਮ ਡੋਮੇਨ ਸਹਾਇਤ ਕਰਦਾ ਹੈ—ਕੈਨੇਰੀ ਦੌਰਾਨ ਤੇਜ਼, ਘੱਟ-ਜੋਖਮ ਰਿਲੀਜ਼ ਲਈ ਲਾਭਦਾਇਕ ਪ੍ਰਿਮਿਟਿਵ।
ਇੱਕ ਪ੍ਰੋਟੋਟਾਈਪ "ਸਸਤਾ" ਮਹਿਸੂਸ ਕਰ ਸਕਦਾ ਹੈ ਕਿਉਂਕਿ ਵਰਤੋਂ ਘੱਟ ਹੈ ਅਤੇ ਫੇਲ ਬਰਦਾਸ਼ਤ ਕੀਤੇ ਜਾ ਰਹੇ ਹਨ। ਉਤਪਾਦਨ ਇਸਨੂੰ ਉਲਟ ਕਰਦਾ ਹੈ: ਓਹੀ ਪ੍ਰੰਪਟ ਚੇਨ ਜੋ ਡੈਮੋ ਵਿੱਚ ਕੁਝ ਡਾਲਰ ਖਰਚ ਕਰਦੀ ਸੀ, ਹਜ਼ਾਰਾਂ ਯੂਜ਼ਰਾਂ ਨਾਲ ਦਿਨਾਨੁਕ ਦਿਨ ਇੱਕ ਮਹੱਤਵਪੂਰਣ ਲਾਈਨ ਆਈਟਮ ਬਣ ਸਕਦੀ ਹੈ।
ਜ਼ਿਆਦਾਤਰ LLM ਖਰਚ ਵਰਤੋਂ-ਸੰਭਾਲਿਤ ਹੁੰਦੀ ਹੈ, ਨਾ ਕੇ ਫੀਚਰ-ਸੰਭਾਲਿਤ। ਮੁੱਖ ਚਾਲਕ ਹਨ:
ਆਪਣੇ ਕਾਰੋਬਾਰ ਮਾਡਲ ਨਾਲ ਮੇਲ ਖਾਂਦੇ ਹੋਏ ਬਜਟ ਸੈੱਟ ਕਰੋ, ਨਾ ਕਿ ਸਿਰਫ਼ "ਮਹੀਨਾਵਾਰ ਖਰਚ"। ਉਦਾਹਰਣ:
ਸਧਾਰਣ ਨਿਯਮ: ਜੇ ਤੁਸੀਂ ਇੱਕ ਸਿੰਗਲ ਰਿਕਵੇਸਟ ਟਰੇਸ ਤੋਂ ਲਾਗਤ ਅਨੁਮਾਨ ਨਹੀਂ ਕਰ ਸਕਦੇ, ਤਾਂ ਤੁਸੀਂ ਇਸਨੂੰ ਕਾਬੂ ਨਹੀਂ ਕਰ ਸਕਦੇ।
ਛੋਟੇ ਬਦਲਾਅ ਮਿਲਾ ਕੇ ਮਹੱਤਵਪੂਰਣ ਬਚਤਾਂ ਮਿਲਦੀਆਂ ਹਨ:
ਰਨਾਵੇ-ਹਵਾਲੇ ਬਰਤਾਓ ਤੋਂ ਬਚਣ ਲਈ ਗਾਰਡਰੇਲ ਜੋੜੋ: ਟੂਲ-ਕਾਲ ਗਿਣਤੀ ਓਲੀਟ, ਰੀਟ੍ਰਾਈਜ਼ ਸੀਮਤ, ਮੈਕਸ ਟੋਕਨ ਲਾਓ, ਅਤੇ ਜਦ ਪ੍ਰਗਤੀ ਰੁਕ ਜਾਵੇ ਤਾਂ ਲੂਪ ਰੋਕੋ। ਜੇ ਤੁਹਾਡੇ ਕੋਲ ਪਹਿਲਾਂ ਹੀ ਮਾਨੀਟਰਿੰਗ ਹੈ, ਤਾਂ ਲਾਗਤ ਨੂੰ ਪਹਿਲੀ-ਕਲਾਸ ਮੈਟ੍ਰਿਕ ਬਣਾਓ ਤਾਂ ਜੋ ਫਾਇਨੈਂਸ ਹੈਰਾਨੀਆਂ ਭਰੋਸੇਯੋਗਤਾ ਘਟਨਾਵਾਂ ਨਾ ਬਣਨ।
ਉਤਪਾਦਨ ਸਿਰਫ ਤਕਨੀਕੀ ਮੀਲ ਦਾ ਪੱਥਰ ਨਹੀਂ—ਇਹ ਇੱਕ ਸੰਗਠਨਕ ਵਚਨਬੱਧਤਾ ਹੈ। ਜਦੋਂ ਅਸਲ ਯੂਜ਼ਰ ਕਿਸੇ AI ਫੀਚਰ 'ਤੇ ਨਿਰਭਰ ਹੋਣ, ਤੁਹਾਨੂੰ ਸਪਸ਼ਟ ਮਾਲਕੀਅਤ, ਇੱਕ ਸਪੋਰਟ ਰਸਤਾ, ਅਤੇ ਇੱਕ ਗਵਰਨੈਂਸ ਲੂਪ ਦੀ ਲੋੜ ਹੋਵੇਗੀ ਤਾਂ ਕਿ ਪ੍ਰਣਾਲੀ "ਕਿਸੇ ਦੀ ਨੌਕਰੀ ਨਹੀਂ" ਵਿੱਚ ਨਾ ਸੁਟੇ।
ਭੂਮਿਕਾਵਾਂ ਨੂੰ ਨਾਮ ਰੱਖੋ (ਇੱਕ ਵਿਅਕਤੀ ਕਈ ਹੈਟ ਪਹਿਨ ਸਕਦਾ ਹੈ, ਪਰ ਜ਼ਿੰਮੇਵਾਰੀਆਂ ਸਪਸ਼ਟ ਹੋਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ):
ਸ਼ਿਪ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਸਮੱਸਿਆਵਾਂ ਲਈ ਡਿਫਾਲਟ ਰਸਤਾ ਚੁਣੋ: ਕੌਣ ਯੂਜ਼ਰ ਰਿਪੋਰਟਸ ਪ੍ਰਾਪਤ ਕਰਦਾ ਹੈ, ਕੀ “ਅਰਜੈਂਟ” ਹੈ, ਅਤੇ ਕੌਣ ਫੀਚਰ ਨੂੰ ਰੋਕ ਜਾਂ ਰੋਲਬੈਕ ਕਰ ਸਕਦਾ ਹੈ। ਐਸਕਲੇਸ਼ਨ ਚੇਨ (support → product/AI owner → security/legal ਜ਼ਰੂਰਤ ਪੈਣ 'ਤੇ) ਅਤੇ ਉੱਚ-ਪ੍ਰਭਾਵਿਤ ਫੇਲ ਲਈ ਉਮੀਦਸ਼ੁਦਾ ਜਵਾਬ ਸਮਾਂ ਨਿਰਧਾਰਿਤ ਕਰੋ।
ਛੋਟੀ, ਸਾਦੀ ਭਾਸ਼ਾ ਵਿੱਚ ਦਿਓ: AI ਕੀ ਕਰ ਸਕਦਾ/ਕੀ ਨਹੀਂ ਕਰ ਸਕਦਾ, ਆਮ ਫੇਲ ਮੋਡ, ਅਤੇ ਜੇ ਕੁਝ ਗਲਤ ਲੱਗੇ ਤਾਂ ਯੂਜ਼ਰ ਨੂੰ ਕੀ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ। ਜਿੱਥੇ ਫੈਸਲੇ ਗਲਤ ਸਮਝੇ ਜਾ ਸਕਦੇ ਹਨ, ਉੱਥੇ ਦਿਸ਼ਾਂ-ਨਿਰਦੇਸ਼ ਦਿਓ ਅਤੇ ਸਮੱਸਿਆ ਰਿਪੋਰਟ ਕਰਨ ਦਾ ਤਰੀਕਾ ਦਿਓ।
AI ਵਿਹਾਰ ਰਵਾਇਤੀ ਸਾਫਟਵੇਅਰ ਨਾਲੋਂ ਤੇਜ਼ ਬਦਲਦਾ ਹੈ। ਇਕ ਰਿਕਰਿੰਗ ਕੈਡੈਂਸ (ਉਦਾਹਰਣ ਲਈ, ਮਹੀਨਾਵਾਰ) ਸੈਟ ਕਰੋ ਜਿਸ ਵਿੱਚ ਇਨਸੀਡੈਂਟ, ਪ੍ਰੰਪਟ/ਮਾਡਲ ਬਦਲਾਅ ਆਡਿਟ, ਅਤੇ ਕਿਸੇ ਵੀ ਯੂਜ਼ਰ-ਸਾਮ੍ਹਣੇ ਵਿਹਾਰ ਨੂੰ ਦੁਬਾਰਾ ਮਨਜ਼ੂਰ ਕੀਤਾ ਜਾਵੇ।
ਇੱਕ ਚੰਗਾ ਉਤਪਾਦਨ ਲਾਂਚ ਆਮ ਤੌਰ 'ਤੇ ਠੰਢੇ, ਪੜਾਅਵਾਰ ਰੋਲਆਊਟ ਦਾ ਨਤੀਜਾ ਹੁੰਦਾ ਹੈ—ਨ ਕਿ ਇਕ ਹੀਰੋਈਕ “ਸ਼ਿਪ ਇਟ” ਫਿਰ। ਹੇਠਾਂ ਇਕ ਵਿਹਾਰਕ ਰਾਹ-ਨਕਸ਼ਾ ਹੈ ਜੋ ਕੰਮ ਕਰਦਾ ਡੈਮੋ ਤੋਂ ਇੱਕ ਭਰੋਸੇਯੋਗ ਸਿਸਟਮ ਤੱਕ ਲਿਜਾਣ ਲਈ।
ਪ੍ਰੋਟੋਟਾਈਪ ਨੂੰ ਲਚਕੀਲਾ ਰੱਖੋ, ਪਰ ਹਕੀਕਤ ਨੂੰ ਕੈਪਚਰ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰੋ:
ਪਾਇਲਟ ਉਹ ਜਗ੍ਹਾ ਹੈ ਜਿੱਥੇ ਤੁਸੀਂ ਅਣਜਾਣਿਆਂ ਨੂੰ ਘਟਾਉਂਦੇ ਹੋ:
ਤਦੋਂ ਹੀ ਵਿਸਥਾਰ ਕਰੋ ਜਦੋਂ ਤੁਸੀਂ ਇਸਨੂੰ ਇਕ ਉਤਪਾਦ ਵਾਂਗ ਚਲਾ ਸਕੋ, ਨਾ ਕਿ ਵਿਗਿਆਨ-ਪ੍ਰੋਜੈਕਟ ਵਾਂਗ:
ਵਿਆਉਂਦੇ ਹੋਏ ਵਿਸਥਾਰ ਤੋਂ ਪਹਿਲਾਂ ਪੁਸ਼ਟੀ ਕਰੋ:
ਜੇ ਤੁਸੀਂ ਪੈਕੇਜਿੰਗ ਅਤੇ ਰੋਲਆਊਟ ਵਿਕਲਪ ਦੀ ਯੋਜਨਾ ਬਣਾਉਣੀ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ ਬਾਅਦ ਵਿੱਚ /pricing ਜਾਂ ਸਹਾਇਕ ਗਾਈਡਾਂ ਨੂੰ ਦੇਖੋ।
ਪ੍ਰੋਟੋਟਾਈਪ ਤੇਜ਼ੀ ਅਤੇ ਸਿੱਖਣ ਲਈ ਬਣਾਇਆ ਜਾਂਦਾ ਹੈ: ਇਹ ਮੈਨੂਅਲ ਹੋ ਸਕਦਾ ਹੈ, ਨਾਜੁਕ ਹੋ ਸਕਦਾ ਹੈ, ਅਤੇ ਇਕ ਨਿਯੰਤ੍ਰਿਤ ਡੈਮੋ ਲਈ “ਕਾਫ਼ੀ ਚੰਗਾ” ਹੋ ਸਕਦਾ ਹੈ।
ਉਤਪਾਦਨ ਦੋਹਾਂ ਵਾਰ ਨਤੀਜੇ ਦੁਹਰਾਏ ਜਾ ਸਕਣ ਅਤੇ ਸੁਰੱਖਿਅਤ ਹੋਣ ਲਈ ਬਣਾਇਆ ਜਾਂਦਾ ਹੈ: ਪੇਸ਼ਗੋਈਯੋਗ ਵਰਤਾਰਾ, ਅਸਲ ਡੇਟਾ ਦੀ ਸੁਰੱਖਿਆ, ਪਰਿਭਾਸ਼ਿਤ ਸਫਲਤਾ/ਅਸਫਲਤਾ ਮਾਪਦੰਡ, ਮਾਨੀਟਰਿੰਗ, ਅਤੇ ਜਦੋਂ ਮਾਡਲ/ਟੂਲ ਫੇਲ ਹੋਣ ਤਾਂ ਫਾਲਬੈਕ।
ਇਨ੍ਹਾਂ ਹਾਲਾਤਾਂ ਵਿੱਚ ਇਸਨੂੰ ਉਤਪਾਦਨ ਲਈ ਟ੍ਰਿਗਰ ਸਮਝੋ:
ਜੇ ਇਨ੍ਹਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਸਚ ਹੈ, ਤਾਂ ਅੱਗੇ ਵਧਣ ਤੋਂ ਪਹਿਲਾਂ ਮਜ਼ਬੂਤੀਕਰਨ ਦੀ ਯੋਜਨਾ ਬਣਾਓ।
ਡੈਮੋ ਅਕਸਰ ਉਨ੍ਹਾਂ ਗੁੰਝਲਦਾਰ ਚੀਜ਼ਾਂ ਅਤੇ ਮਨੁੱਖੀ 'ਗਲੂ' ਨੂੰ ਛੁਪਾਂਦਾ ਹੈ।
ਅਸਲ ਵਰਤੋਂਕਾਰ ਲੰਬੇ/ਅਸਪਸ਼ਟ ਇਨਪੁੱਟ ਭੇਜਣਗੇ, ਏਜ ਕੇਸ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਨਗੇ ਅਤੇ ਕਿਸਮਤ ਦੀ ਉਮੀਦ ਰੱਖਣਗੇ। ਪ੍ਰੋਟੋਟਾਈਪ ਅਕਸਰ ਅਜਿਹੀਆਂ ਧਾਰਨਾਵਾਂ 'ਤੇ ਨਿਰਭਰ ਹੁੰਦੇ ਹਨ ਜੋ ਸਕੇਲ 'ਤੇ ਟੁੱਟ ਜਾਣ: ਥਿਰ ਲੈਟੈਂਸੀ, ਵੱਡੇ ਰੇਟ ਲਿਮਿਟ, ਇੱਕ ਮਾਡਲ ਵਰਜਨ, ਜਾਂ ਮਨੁੱਖੀ ਤੌਰ 'ਤੇ ਪ੍ਰੰਪਟ ਨੂੰ ਫਿਰ ਤੋਂ ਚਲਾਇਆ ਜਾਣਾ। ਉਤਪਾਦਨ ਵਿੱਚ, ਉਹ ਛੁਪਿਆ ਮਨੁੱਖੀ ਕੰਮ ਆਟੋਮੇਟ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਅਤੇ ਸੁਰੱਖਿਆ ਦੇ ਨਿਯਮ ਲਾਗੂ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ।
ਕਾਰੋਬਾਰੀ ਸ਼ਬਦਾਂ ਵਿੱਚ ਸਫਲਤਾ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ ਅਤੇ ਇਸਨੂੰ ਹਫ਼ਤਾਵਾਰ ਮਾਪੋ। ਆਮ ਮੈਟ੍ਰਿਕਸ:
ਉਦਾਹਰਣ ਲਈ: “ਸਾਡੇ ਐਵਲੂਏਸ਼ਨ ਸੈੱਟ 'ਤੇ ≥85% ਟਾਸਕ ਸਫਲਤਾ ਅਤੇ ਦੋ ਹਫ਼ਤੇ ਬਾਅਦ ≥4.2/5 CSAT.”
“ਕਦੇ ਵੀ ਨਹੀਂ ਹੋਣਾ” ਨਿਯਮ ਲਿਖੋ ਅਤੇ ਆਟੋਮੈਟਿਕ ਐਨਫੋਰਸਮੈਂਟ ਜੋੜੋ। ਉਦਾਹਰਣ:
ਹਾਰਮਫੁਲ ਆਉਟਪੁੱਟ, ਹੈਲੂਸੀਨੇਸ਼ਨ ਅਤੇ ਗਲਤ ਇਨਕਾਰ ਦਰਾਂ ਨੂੰ ਟਰੈਕ ਕਰੋ। ਜਦੋਂ ਨਿਯਮ ਟ੍ਰਿਗਰ ਹੋ, ਤੁਰੰਤ ਬਲਾਕ, ਸੇਫ ਫਾਲਬੈਕ ਅਤੇ ਇਨਸਿਡੈਂਟ ਰਿਵਿਊ ਕਰੋ।
ਇਕ ਰੀ-ਰੱਨ ਕਰਨਯੋਗ ਓਫਲਾਈਨ ਸਵੀਟ ਬਣਾਓ, ਫਿਰ ਅਨੁਕੂਲ ਢੰਗ ਨਾਲ ਪ੍ਰੋਡਕਸ਼ਨ 'ਤੇ ਜਾਂਚ ਕਰੋ:
ਸ਼ੈਡੋ ਮੋਡ, ਕੈਨੇਰੀ, ਜਾਂ A/B ਟੈਸਟਾਂ ਨਾਲ ਬਦਲਾਅ ਸੁਰੱਖਿਅਤ ਰੂਪ ਵਿੱਚ ਰੋਲਆਊਟ ਕਰੋ ਅਤੇ ਗੇਟ ਦੇ ਤੌਰ 'ਤੇ ਇਹਨਾਂ ਨੂੰ ਪਾਸ ਕਰਨ ਦੀ ਲੋੜ ਰੱਖੋ।
ਬੁਰੇ ਦਿਨਾਂ ਲਈ ਡਿਜ਼ਾਈਨ ਕਰੋ:
ਮਕਸਦ ਹੈ graceful degradation — ਤਜਰਬਾ ਸਧਾਰਾ ਹੋਵੇ, ਟੁੱਟਿਆ ਨਾ ਹੋਵੇ।
ਡਾਟਾ ਫਲੋ ਨੂੰ ਅਤੇ-ਅੰਤ ਦਰਜ ਕਰੋ ਅਤੇ ਅਣਜਾਣ ਟੀਚਿਆਂ ਨੂੰ ਖ਼ਤਮ ਕਰੋ:
ਖ਼ਤਰੇ: ਪ੍ਰੰਪਟ ਇੰਜੈਕਸ਼ਨ, ਯੂਜ਼ਰ-ਅੰਤਰ-ਡਾਟਾ ਲੀਕ, ਅਤੇ ਅਨਸੈਫ ਟੂਲ ਕਾਲਾਂ — ਇਨ੍ਹਾਂ ਨੂੰ ਖਾਸ ਤੌਰ 'ਤੇ ਦੂਰ ਕਰੋ।
ਇੰਸੀਡੈਂਟਾਂ ਨੂੰ ਅਣਮੁੱਲ ਕਰਨ ਲਈ ਕਾਫ਼ੀ ਲਾਗਿੰਗ ਕਰੋ ਪਰ ਗੁਪਤ ਡੇਟਾ ਇਕੱਠਾ ਨਾ ਕਰੋ:
ਡੈਸ਼ਬੋਰਡ: তਰਤੀਬਵਾਰ error rate, latency (p50/p95), ਲਾਗਤ ਅਤੇ ਕੁਝ ਗੁਣਵੱਤਾ ਪ੍ਰੋਕਸੀ ਰੱਖੋ।
ਸਭ ਤਤਵਾਂ ਨੂੰ ਵਰਜਨ ਕਰੋ ਜੋ ਵਰਤਾਰਾ ਬਦਲ ਸਕਦੇ ਹਨ:
ਬਿਲਡ ਦੁਹਰਾਏ ਜਾਣਯੋਗ ਬਣਾਓ: ਡਿਪੈਂਡੇਂਸੀ ਲੌਕ, ਰੰਟਾਈਮ ਇਮેજ, ਅਤੇ ਸੀਕ੍ਰੇਟਸ/ਕਨਫਿਗ ਅਲੱਗ ਰੱਖੋ। ਰੀਲੀਜ਼ ਫਲੋ dev → staging → production ਰੱਖੋ ਅਤੇ ਰੋਲਬੈਕ ਦੀ ਯੋਜਨਾ ਪਹਿਲਾਂ ਤੋਂ ਤਿਆਰ ਰੱਖੋ।
ਲਾਗਤ ਸਿਰਫ਼ ਫੀਚਰ ਨਹੀਂ—ਉਪਯੋਗਤਾ ਦੁਆਰਾ ਹੁੰਦੀ ਹੈ। ਖਰਚ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਨ ਵਾਲੀਆਂ ਵਸਤਾਂ:
ਉਤਪਾਦਿਕ ਭਾਸ਼ਾ ਵਿੱਚ ਬਜਟ ਤੈਅ ਕਰੋ: ਪ੍ਰਤੀ ਰਿਕਵੇਸਟ ਲਾਗਤ, ਪ੍ਰਤੀ ਐਕਟਿਵ ਯੂਜ਼ਰ ਲਾਗਤ, ਜਾਂ ਪ੍ਰਤੀ ਵਰਕਫਲੋ ਲਾਗਤ।
ਸੰਭਾਲਣ ਵਾਲੇ ਉਪਾਇ ਜੋ ਗੁਣਵੱਤਾ ਖ਼ਰਾਬ ਨਾ ਕਰਨ:
ਉਤਪਾਦਨ ਇੱਕ ਸੰਗਠਨਕ ਵਚਨਬੱਧਤਾ ਵੀ ਹੈ। ਜ਼ਿੰਮੇਵਾਰੀਆਂ ਨੂੰ ਨਾਮ ਦਿਓ:
ਸਪੋਰਟ ਮਾਡਲ: ਇਸ਼ੂਜ਼ ਨੂੰ ਕੌਣ ਪ੍ਰਾਪਤ ਕਰੇਗਾ, ਕੀ “అਰਜੈਂਟ” ਹੈ, ਅਤੇ ਕੌਣ ਫੀਚਰ ਨੂੰ ਪਾਊਜ਼ ਜਾਂ ਰੋਲਬੈਕ ਕਰ ਸਕਦਾ ਹੈ। ਯੂਜ਼ਰਾਂ ਨਾਲ ਸਾਫ਼ ਜ਼ਵਾਨੀ: ਕੀ ਫੀਚਰ ਕਰ ਸਕਦਾ/ਨਹੀਂ ਕਰ ਸਕਦਾ, ਅਤੇ ਰਿਪੋਰਟ ਕਰਨ ਦਾ ਤਰੀਕਾ।
ਬਦਲਾਅ ਪ੍ਰਬੰਧਨ ਦੀ ਰਿਦਮ: ਮਹੀਨਾਵਾਰ ਜਾਂ ਰਿਕਰਿੰਗ ਸੰਖੇਪ ਸਮੀਖਿਆ (ਇੰਸੀਡੈਂਟ, ਪ੍ਰੰਪਟ/ਮਾਡਲ ਬਦਲਾਅ ਆਡੀਟ) ਰੱਖੋ।
ਸ਼ਾਂਤ, ਪੜਾਅਵਾਰ ਰੋਲਆਊਟ — ਹੀਰੋਈਕ “ਸ਼ਿਪ ਇਟ” ਨਹੀਂ। ਇੱਕ ਪ੍ਰਯੋਗਾਤਮਕ ਰੋਡਮੈਪ:
ਚਰਨ 1: ਪ੍ਰੋਟੋਟਾਈਪ → “ਸੱਚ-ਖੋਜ”
ਚਰਨ 2: ਪਾਇਲਟ → “ਨਿਯੰਤ੍ਰਿਤ ਖੁਲਾਸਾ”
ਚਲਦੀ ਬਿਲਾਂ ਤੋਂ ਬਚਣ ਲਈ ਗਾਰਡਰੇਲ: ਟੂਲ-ਕਾਲ ਕੈਪ, ਰੀਟ੍ਰਾਈ ਸੀਮਤ, ਮੈਕਸ ਟੋਕਨ, ਲੂਪ ਰੋਕਣਾ।
ਚਰਨ 3: ਉਤਪਾਦਨ → “ਦੋਹਰਾਉਣਯੋਗ ਓਪਰੇਸ਼ਨ”
ਤਿਆਰੀ ਚੈੱਕਲਿਸਟ (ਸੰਖੇਪ):
ਜੇ ਤੁਸੀਂ ਪੈਕੇਜਿੰਗ ਅਤੇ ਰੋਲਆਊਟ ਵਿਕਲਪਾਂ ਦੀ ਯੋਜਨਾ ਬਣਾਉਣੀ ਹੋਵੇ, ਤਾਂ ਬਾਅਦ ਵਿੱਚ /pricing ਜਾਂ ਸਹਾਇਕ ਗਾਈਡ ਨਾਲ ਮਿਲਾ ਸਕਦੇ ਹੋ।
