AI ਪ੍ਰੋਟੋਟਾਈਪ ਨੂੰ ਪ੍ਰੋਡਕਸ਼ਨ-ਰੇਡੀ ਸਿਸਟਮ ਵਿੱਚ ਕਿਵੇਂ ਲਿਆਂਦਾ ਜਾਵੇ

ਪ੍ਰੋਟੋਟਾਈਪ ਬਨਾਮ ਪ੍ਰੋਡਕਸ਼ਨ: ਅਸਲ ਵਿੱਚ ਕੀ ਬਦਲਦਾ ਹੈ

ਇੱਕ ਪ੍ਰੋਟੋਟਾਈਪ ਇਕ ਸਵਾਲ ਦਾ ਜਵਾਬ ਦੇਣ ਲਈ ਬਣਾਇਆ ਜਾਂਦਾ ਹੈ: “ਕੀ ਇਹ ਕੰਮ ਕਰ ਸਕਦਾ ਹੈ?” ਪ੍ਰੋਡਕਸ਼ਨ ਸਿਸਟਮ ਨੂੰ ਵੱਖਰਾ ਸਵਾਲ ਜਵਾਬ ਦੇਣਾ ਪੈਂਦਾ ਹੈ: “ਕੀ ਇਹ ਹਰ ਰੋਜ਼, ਬਹੁਤ ਸਾਰੇ ਲੋਕਾਂ ਲਈ, ਇੱਕ ਸਵੀਕਾਰਯੋਗ ਲਾਗਤ ਤੇ, ਸਪੱਸ਼ਟ ਜਵਾਬਦੇਹੀ ਨਾਲ ਕੰਮ ਕਰ ਸਕਦਾ ਹੈ?” ਇਹੀ ਖਾਈ ਹੈ ਜੋ ਕਈ ਵਾਰੀ AI ਪ੍ਰੋਟੋਟਾਈਪ ਡੈਮੋ ਵਿੱਚ ਚਮਕਦੇ ਹਨ ਪਰ ਲਾਂਚ ਤੋਂ ਬਾਅਦ ਠੋਕਰ ਖਾਂਦੇ ਹਨ।

ਕਿਉਂ ਡੈਮੋ ਜ਼ਿਆਦਾ ਕਾਮਯਾਬ ਹੁੰਦੇ ਹਨ (ਅਤੇ ਪ੍ਰੋਡਕਸ਼ਨ ਨਹੀਂ)

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

“ਪ੍ਰੋਡਕਸ਼ਨ-ਰੈਡੀ” ਦਾ ਅਸਲ ਮਤਲਬ

ਪ੍ਰੋਡਕਸ਼ਨ-ਰੈਡੀ AI ਵਧੀਆ ਮਾਡਲ ਨਾਲੋਂ ਘੱਟ ਅਤੇ ਭਰੋਸੇਯੋਗ ਓਪਰੇਸ਼ਨਾਂ ਬਾਰੇ ਵੱਧ ਹੁੰਦਾ ਹੈ:

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

ਆਮ ਤਬਦੀਲੀ ਜੋਖਮ ਜਿਨ੍ਹਾਂ 'ਤੇ ਧਿਆਨ ਦੇਣਾ

ਟੀਮਾਂ ਅਕਸਰ ਹੇਠਾਂ ਦਿੱਤਿਆਂ ਨਾਲ ਹੈਰਾਨ ਹੋ ਜਾਂਦੀਆਂ ਹਨ:

• ਡੇਟਾ ਡ੍ਰਿਫਟ: ਅਸਲ-ਦਿਨ ਦੇ ਇਨਪੁਟ ਬਦਲਦੇ ਹਨ, ਅਤੇ ਸਹੀਦਾਰੀ ਚੁਪਚਾਪ ਘੱਟ ਹੁੰਦੀ ਹੈ।
• ਛੁਪੇ ਹੋਏ ਹੱਥੋਂ ਕਦਮ: ਕੋਈ ਵਿਅਕਤੀ “ਸਿਰਫ” ਇੱਕ ਕਾਲਮ ਸਾਫ ਕਰਦਾ ਹੈ, ਪ੍ਰਾਂਪਟ ਪੇਸਟ ਕਰਦਾ ਹੈ, ਜਾਂ ਫੇਲ ਹੋਣ 'ਤੇ ਜੌਬ ਮੁੜ ਚਲਾਉਂਦਾ ਹੈ।
• ਅਸਪਸ਼ਟ ਮਲਕੀਅਤ: ਕੋਈ ਇੱਕ ਟੀਮ ਐਂਡ-ਟੂ-ਐਂਡ ਨਤੀਜੇ ਦੀ ਮਲਕੀਅਤ (ਮਾਡਲ, ਡੇਟਾ, ਇੰਫਰਾ, UX) ਨਹੀਂ ਰੱਖਦੀ।

ਇਸ ਗਾਈਡ ਦੇ ਅੰਤ ਤੱਕ ਤੁਹਾਨੂੰ ਮਿਲੇਗਾ

ਤੁਹਾਡੇ ਕੋਲ ਇੱਕ ਦੁਹਰਾਓਯੋਗ ਟ੍ਰਾਂਜ਼ਿਸ਼ਨ ਯੋਜਨਾ ਹੋਵੇਗੀ: ਸਫਲਤਾ ਨੂੰ ਕਿਵੇਂ ਪਰਿਭਾਸ਼ਿਤ ਕਰਨਾ, ਡੇਟਾ ਤਿਆਰ ਕਰਨਾ, ਸਕੇਲ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਮੁਲਾਂਕਣ, ਪ੍ਰੋਡਕਸ਼ਨ ਆਰਕੀਟੈਕਚਰ ਚੁਣਨਾ, ਲਾਗਤ/ਲੈਟੰਸੀ ਦੀ ਯੋਜਨਾ, ਸੁਰੱਖਿਆ ਮਿਆਰ ਪੂਰੇ ਕਰਨਾ, ਮਨੁੱਖੀ ਨਿਗਰਾਨੀ ਡਿਜ਼ਾਇਨ ਕਰਨਾ, ਪ੍ਰਦਰਸ਼ਨ ਮਾਨੀਟਰ ਕਰਨਾ, ਅਤੇ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਰੋਲਆਊਟ—ਤਾਂ ਜੋ ਅਗਲਾ ਪ੍ਰੋਟੋਟਾਈਪ ਇੱਕ ਇਕਲ-ਡੈਮੋ ਨਾ ਰਹਿ ਜਾਵੇ।

ਲਕੜੀ ਪੱਕੀ ਕਰੋ: ਲਕੜੀ, ਸਕੋਪ, ਅਤੇ ਸਫਲਤਾ ਮੈਟਰਿਕ

ਇੱਕ ਪ੍ਰੋਟੋਟਾਈਪ “ਠੀਕ-ਠਾਕ” ਮਹਿਸੂਸ ਕਰ ਸਕਦਾ ਹੈ ਕਿਉਂਕਿ ਇਹ ਡੈਮੋ ਵਿੱਚ ਚੰਗਾ ਲੱਗਦਾ ਹੈ। ਪ੍ਰੋਡਕਸ਼ਨ ਵਖਰਾ ਹੈ: ਤੁਹਾਨੂੰ ਇਕ ਸਾਂਝੀ, ਟੈਸਟਯੋਗ ਸਹਿਮਤੀ ਦੀ ਲੋੜ ਹੈ ਕਿ AI ਕਿਸ ਲਈ ਹੈ, ਕਿਹੜੀ ਚੀਜ਼ ਲਈ ਨਹੀਂ ਹੈ, ਅਤੇ ਤੁਸੀਂ ਸਫਲਤਾ ਨੂੰ ਕਿਵੇਂ ਮਾਪੋਗੇ।

ਯੂਜ਼ਰ ਵਰਕਫਲੋਅ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ

ਉਸ ਪਕਕ ਸਮੇਂ ਨੂੰ ਵਰਣਨ ਕਰੋ ਜਦੋਂ AI ਵਰਤੀ ਜਾਂਦੀ ਹੈ ਅਤੇ ਇਸ ਤੋਂ ਪਹਿਲਾਂ ਅਤੇ ਬਾਅਦ ਕੀ ਹੁੰਦਾ ਹੈ। ਕੌਣ ਬੇਨਤੀ ਟਰਿਗਰ ਕਰਦਾ ਹੈ, ਆਉਟਪੁੱਟ ਕੌਣ ਵਰਤਦਾ ਹੈ, ਅਤੇ ਕਿਹੜਾ ਨਿਰਣਿਆ (ਜਾਂ ਕਾਰਵਾਈ) ਇਹ ਸਹਾਰਾ ਦਿੰਦਾ ਹੈ?

ਸਪਸ਼ਟ ਰੱਖੋ:

• ਯੂਜ਼ਰ ਕਿਹੜੀ ਸਕ੍ਰੀਨ, ਫਾਰਮ, ਟਿਕਟ, ਜਾਂ ਚੈਟ ਤੋਂ ਸ਼ੁਰੂ ਕਰਦਾ ਹੈ?
• AI ਕੀ ਵਾਪਸ ਕਰਦਾ ਹੈ (ਜਵਾਬ, ਡਰਾਫਟ, ਵਰਗੀਕਰਨ, ਸਿਫ਼ਾਰਿਸ਼)?
• ਯੂਜ਼ਰ ਅਗਲਾ ਕੀ ਕਰਦਾ ਹੈ (ਮੰਨਜ਼ੂਰ, ਸੋਧ, ਐਸਕਲੇਟ, ਨਜ਼ਰਅੰਦਾਜ਼)?

ਜੇ ਤੁਸੀਂ ਪੰਜ ਮਿੰਟ ਵਿੱਚ ਵਰਕਫਲੋਅ ਨਹੀਂ ਬਣਾਂ ਸਕਦੇ, ਤਾਂ ਸਕੋਪ ਤਿਆਰ ਨਹੀਂ।

ਕਾਰੋਬਾਰੀ ਨਤੀਜੇ ਨੂੰ ਜੋੜੋ

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

ਸਿਰਫ਼ ਗੁਣਵੱਤਾ ਨਹੀਂ—ਮੈਟਰਿਕ ਚੁਣੋ

ਛੋਟਾ ਸੈੱਟ ਮੈਟਰਿਕਸ ਚੁਣੋ ਜੋ ਉਪਯੋਗੀਤਾਵਾਂ ਨੂੰ ਹਕੀਕਤ ਨਾਲ ਸੰਤੁਲਿਤ ਕਰੇ:

• ਗੁਣਵੱਤਾ: ਟਾਸਕ ਸਫਲਤਾ ਦਰ, ਫੈਕਟਵਾਲਟੀ/ਪ੍ਰਿਸੀਜ਼ਨ, ਗਲਤੀ ਦੀ ਗੰਭੀਰਤਾ, ਜਾਂ ਰੂਬ੍ਰਿਕ।
• ਲੇਟੰਸੀ: p95 ਰਿਸਪਾਂਸ ਟਾਈਮ ਅਤੇ ਪਹਿਲੇ-ਟੋਕਨ ਦਾ ਸਮਾਂ (LLMs ਲਈ)।
• ਲਾਗਤ: ਪ੍ਰਤੀ ਬੇਨਤੀ ਲਾਗਤ, ਹੱਲ ਕੀਤੇ ਕੇਸ ਦੀ ਲਾਗਤ, ਜਾਂ ਮਾਸਿਕ ਖਰਚ ਸੀਮਾ।
• ਆਪਣੇਪਨ: ਐਕਟੀਵੇਸ਼ਨ ਦਰ, ਦੁਹਰਾਈ ਵਰਤੋਂ, ਪੂਰਨਤਾ ਦਰ, ਜਾਂ ਮਨੁੱਖੀ ਓਵਰਰਾਈਡ ਦਰ।

ਗੈਰ-ਰੱਦਯੋਗ ਚੀਜ਼ਾਂ ਅਤੇ v1 “ਡਿਫ਼ਿਨੀਸ਼ਨ ਆਫ ਡਨ” ਸੈੱਟ ਕਰੋ

ਜਿਹੜੀਆਂ ਪਾਬੰਦੀਆਂ ਤੋੜੀਆਂ ਨਹੀਂ ਜਾ ਸਕਦੀਆਂ—uptime ਲਕੜੀ, ਸਵੀਕਾਰਯੋਗ ਫੇਲ ਮੋਡ, ਪ੍ਰਾਈਵੇਸੀ ਸੀਮਤੀਆਂ (ਕਿਹੜਾ ਡੇਟਾ ਭੇਜਿਆ ਜਾ ਸਕਦਾ/ਨਹੀਂ), ਅਤੇ ਐਸਕਲੇਸ਼ਨ ਲੋੜਾਂ—ਇਹ ਲਿਖੋ।

ਫਿਰ ਇੱਕ ਸਰਲ v1 ਚੈੱਕਲਿਸਟ ਬਣਾਓ: ਕਿਹੜੇ ਯੂਜ਼ ਕੇਸ ਸ਼ਾਮਿਲ ਹਨ, ਕਿਹੜੇ ਬਾਹਰ ਹਨ, ਘੱਟੋ-ਘੱਟ ਮੈਟਰਿਕ ਥ੍ਰੈਸ਼ਹੋਲਡ ਕੀ ਹਨ, ਅਤੇ ਤੁਸੀਂ ਕਿਹੜਾ ਸਬੂਤ (ਡੈਸ਼ਬੋਰਡ, ਟੈਸਟ ਨਤੀਜੇ, ਸਾਈਨ-ਆਫ) ਮੰਨੋਗੇ। ਇਹ ਹਰ ਮਗਰਲੇ ਫੈਸਲੇ ਲਈ ਤੁਹਾਡਾ ਅੰਕਤਾ ਬਣ ਜਾਵੇਗਾ।

ਡੇਟਾ ਤਿਆਰੀ: ਸਰੋਤ, ਗੁਣਵੱਤਾ, ਅਤੇ ਗਵਰਨੈਂਸ

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

ਆਪਣੀਆਂ ਡੇਟਾ ਫਲੋਅਜ਼ ਦਾ ਏਂਡ-ਟੂ-ਏਂਡ ਨਕਸ਼ਾ ਬਣਾਓ

ਪੂਰੇ ਚੇਨ ਦੀ ਸੂਚੀ ਬਣਾਓ:

• ਇਨਪੁੱਟਸ: ਯੂਜ਼ਰ ਟੈਕਸਟ, ਚਿੱਤਰ, ਕਲਿਕਸਟਰੀਮ, ਦਸਤਾਵੇਜ਼, ਸੈਂਸਰ ਡੇਟਾ, CRM ਫੀਲਡ—ਜੋ ਕੁਝ ਵੀ ਮਾਡਲ ਪੜ੍ਹੇਗਾ।
• ਲੇਬਲ/ਫੀਡਬੈਕ: ਗਰਾਊਂਡ ਟਰੂਥ ਲੇਬਲ, ਮਨੁੱਖੀ ਸਮੀਖਿਆ, ਯੂਜ਼ਰ ਸਹੀ/ਗਲਤ, ਸਪੋਰਟ ਟਿਕਟ।
• ਡਾਊਨਸਟ੍ਰੀਮ ਖਪਤਕਾਰ: ਪ੍ਰੋਡਕਟ ਫੀਚਰ, ਏਜੰਟ, ਡੈਸ਼ਬੋਰਡ, ਆਟੋਮੇਟਿਕ ਕਾਰਵਾਈਆਂ, ਜਾਂ ਹੋਰ ਸਰਵਿਸ।

ਇਹ ਨਕਸ਼ਾ ਮਲਕੀਅਤ, ਲੋੜੀਂਦੇ ਪਰਮਿਸ਼ਨਾਂ, ਅਤੇ ਹਰ ਖਪਤਕਾਰ ਲਈ “ਚੰਗਾ” ਆਉਟਪੁੱਟ ਕੀ ਹੈ ਇਹ ਸਪਸ਼ਟ ਕਰਦਾ ਹੈ।

ਤੁਸੀਂ ਕੀ ਸਟੋਰ ਕਰੋਗੇ (ਅਤੇ ਕਿੰਨਾ ਸਮੇਂ)

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

ਇੱਕ ਪ੍ਰਯੋਗਾਤਮਕ ਡੇਟਾ ਗੁਣਵੱਤਾ ਚੈੱਕਲਿਸਟ ਬਣਾਓ

ਇੱਕ ਹਲਕਾ-ਫੁਲਕਾ ਚੈੱਕਲਿਸਟ ਜੋ ਆਟੋਮੇਟ ਕੀਤਾ ਜਾ ਸਕਦਾ:

• ਗੁੰਮ ਹੋਏ ਮੁੱਲ ਅਤੇ ਖਾਲੀ ਪੇਲੋਡ
• ਡੁਪਲੀਕੇਟ ਅਤੇ ਦੁਹਰਾਏ ਘਟਨਾ
• ਆਊਟਲਾਇਰ (ਲੰਬਾਈ, ਆਕਾਰ, ਅਸਧਾਰਣ ਫਾਰਮੈਟ)
• ਕਲਾਸ ਅਸਮਤੋਲਤਾ ਅਤੇ ਪੱਖ ਪੈਦਾ ਕਰਨ ਵਾਲੇ ਸੰਕੇਤ (ਖੇਤਰ, ਡਿਵਾਈਸ, ਭਾਸ਼ਾ ਦੇ ਆਧਾਰ 'ਤੇ)
• “ਚੁਪਚਾਪ ਫੇਲ” (ਡਿਫੌਲਟ, ਪਲੇਸਹੋਲਡਰ ਟੈਕਸਟ, ਕੱਟੇ ਹੋਏ ਫਾਈਲ)

ਦੁਹਰਾਓਯੋਗਤਾ ਲਈ ਡੇਟਾਸੈੱਟ ਅਤੇ ਪ੍ਰਾਂਪਟ ਵਰਜ਼ਨ ਕਰੋ

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

ਮੁਲਾਂਕਣ: ਸਕੇਲ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਟੈਸਟ ਬਣਾਓ

ਪ੍ਰੋਟੋਟਾਈਪ ਡੈਮੋ ਆਮ ਤੌਰ 'ਤੇ “ਹੈਪੀ ਪਾਥ” ਤੇ ਅਚ੍ଛਾ ਲੱਗਦਾ ਹੈ। ਅਸਲ ਯੂਜ਼ਰਾਂ ਨੂੰ ਸਕੇਲ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ, ਤੁਹਾਨੂੰ ਗੁਣਵੱਤਾ ਮਾਪਣ ਲਈ ਇੱਕ ਦੁਹਰਾਓਯੋਗ ਤਰੀਕਾ ਚਾਹੀਦੀ ਹੈ ਤਾਂ ਜੋ ਫੈਸਲੇ ਭਾਵਨਾਵਾਂ 'ਤੇ ਆਧਾਰਿਤ ਨਾ ਹੋਣ।

ਦੋ ਪੱਧਰੀ ਮੁਲਾਂਕਣ ਵਰਤੋ

ਪਹਿਲਾਂ ਆਫਲਾਈਨ ਟੈਸਟਸ ਬਣਾਓ ਜੋ ਤੁਸੀਂ ਹਰ ਰਿਲੀਜ਼ ਤੋਂ ਪਹਿਲਾਂ ਚਲਾ ਸਕਦੇ ਹੋ, ਫਿਰ ਜਦੋਂ ਸਿਸਟਮ ਲਾਈਵ ਹੋ ਜਾਏ ਤਾਂ ਆਨਲਾਈਨ ਸਿਗਨਲ ਸ਼ਾਮਿਲ ਕਰੋ।

ਆਫਲਾਈਨ ਟੈਸਟ ਪੁੱਛਦੇ ਹਨ: ਕੀ ਇਸ ਬਦਲਾਅ ਨੇ ਉਹ ਕੰਮ ਸੁਧਾਰਿਆ ਜੋ ਅਸੀਂ ਪਰਵਾਨਾ ਦਿੱਤਾ ਹੈ? ਆਨਲਾਈਨ ਸਿਗਨਲ ਪੁੱਛਦੇ ਹਨ: ਕੀ ਯੂਜ਼ਰ ਸਫਲ ਹੋ ਰਹੇ ਹਨ, ਅਤੇ ਸਿਸਟਮ ਅਸਲ ਟ੍ਰੈਫਿਕ ਹੇਠ ਸੁਰੱਖਿਅਤ ਵਤੀਰਾ ਕਰ ਰਿਹਾ ਹੈ?

ਇੱਕ ਛੋਟਾ, ਪ੍ਰਤੀਨਿਧਿ “ਗੋਲਡਨ ਸੈੱਟ” ਬਣਾਓ

ਅਸਲ ਵਰਤੋਂ ਦੀ ਨਮਾਇندگی ਕਰਨ ਵਾਲੇ ਉਦਾਹਰਣ ਬਣਾਓ: ਆਮ ਬੇਨਤੀਆਂ, ਸਭ ਤੋਂ ਆਮ ਵਰਕਫਲੋਅ, ਅਤੇ ਉਮੀਦ ਕੀਤੀ ਫਾਰਮੈਟ ਵਿੱਚ ਆਉਟਪੁੱਟ। ਪਹਿਲਾਂ ਲਈ ਇਹ ਛੋਟਾ ਰੱਖੋ (ਉਦਾਹਰਨ ਲਈ 50–200 ਆਈਟਮ) ਤਾਂ ਜੋ ਇਸ ਦੀ ਸੰਭਾਲ ਆਸਾਨ ਰਹੇ।

ਹਰ ਆਈਟਮ ਲਈ, “ਚੰਗਾ” ਕੀ ਹੈ ਇਹ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ: ਰੈਫਰੈਂਸ ਜਵਾਬ, ਸਕੋਰਿੰਗ ਰੂਬ੍ਰਿਕ, ਜਾਂ ਇੱਕ ਚੈੱਕਲਿਸਟ (ਸਹੀ, ਪੂਰਨ, ਟੋਨ, ਹਵਾਲੇ ਆਦਿ)। ਮਕਸਦ ਲਗਾਤਾਰਤਾ ਹੈ—ਦੋ ਲੋਕ ਇੱਕੋ ਨਤੀਜੇ ਨੂੰ ਸਮਾਨ ਤਰੀਕੇ ਨਾਲ ਸਕੋਰ ਕਰਨ।

ਐਜ ਕੇਸ ਪਹਿਲਾਂ ਹੀ ਸ਼ਾਮਿਲ ਕਰੋ

ਉਨ੍ਹਾਂ ਟੈਸਟਾਂ ਨੂੰ ਸ਼ਾਮਿਲ ਕਰੋ ਜੋ ਆਮ ਤੌਰ 'ਤੇ ਪ੍ਰੋਡਕਸ਼ਨ ਵਿੱਚ ਟੁੱਟਦੇ ਹਨ:

• ਸੰਵੇਦਨਸ਼ੀਲ ਜਾਂ ਰੋਕੀਆਂ ਸਮੱਗਰੀ (PII, ਮੈਡੀਕਲ/ਕਾਨੂੰਨੀ ਦਾਅਵੇ, ਨੀਤੀ ਉਲੰਘਣਾ)
• ਅਸਪਸ਼ਟ ਬੇਨਤੀਆਂ ਜੋ ਸਪਸ਼ਟੀਕਰਨ ਮੰਗਦੀਆਂ ਹਨ
• ਬਹੁਤ ਲੰਬੇ ਇਨਪੁੱਟ ਅਤੇ ਗੰਦੇ ਫਾਰਮੈਟ
• ਵੈਚਾਲੀਣ ਪ੍ਰਾਂਪਟ (ਪ੍ਰਾਂਪਟ ਇੰਜੈਕਸ਼ਨ ਕੋਸ਼ਿਸ਼ਾਂ, ਜੇਲਬ੍ਰੇਕ ਸ਼ੈਲੀ)

ਥਰੈਸ਼ਹੋਲਡ ਨਿਰਧਾਰਿਤ ਕਰੋ—ਅਤੇ ਰੋਲਬੈਕ ਟ੍ਰਿਗਰ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ

ਪਹਿਲਾਂ ਹੀ ਫੈਸਲਾ ਕਰੋ ਕਿ ਕੀ ਸਵੀਕਾਰਯੋਗ ਹੈ: ਘੱਟੋ-ਘੱਟ ਸਹੀਦਾਰੀ, ਅਧਿਕਤਮ ਹੱਲੂਸੀਨੇਸ਼ਨ ਦਰ, ਸੇਫਟੀ ਪਾਸ ਦਰ, ਲੈਟੰਸੀ ਬਜਟ, ਅਤੇ ਪ੍ਰਤੀ ਬੇਨਤੀ ਲਾਗਤ। ਇਹ ਵੀ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ ਕਿ ਕੀ ਤੁਰੰਤ ਰੋਲਬੈਕ ਟ੍ਰਿਗਰ ਕਰੇਗਾ (ਉਦਾਹਰਨ ਲਈ, ਸੇਫਟੀ ਫੇਲ > X%, ਯੂਜ਼ਰ ਸ਼ਿਕਾਇਤਾਂ ਵਿੱਚ ਉਚਾਲ, ਜਾਂ ਟਾਸਕ ਸਫਲਤਾ ਵਿੱਚ ਗਿਰਾਵਟ)।

ਇਸ ਨਾਲ ਹਰ ਰਿਲੀਜ਼ ਇੱਕ ਨਿਯੰਤਰਿਤ ਪ੍ਰਯੋਗ ਬਣ ਜਾਂਦੀ ਹੈ—ਜ਼ਿੱਤ ਜਾਂ ਹਾਰ ਨਹੀਂ, ਪਰ ਨਤੀਜੇਦਾਰ ਪਰੀਖਿਆ।

ਆਰਕੀਟੈਕਚਰ: ਨੋਟਬੁੱਕ ਤੋਂ ਭਰੋਸੇਯੋਗ ਸਿਸਟਮ ਤੱਕ

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

ਆਪਰੇਟਿੰਗ ਮੋਡ ਚੁਣੋ (API, ਬੈਚ, ਜਾਂ ਰੀਅਲ-ਟਾਈਮ)

ਇਹ ਸੋਚੋ ਕਿ ਸਿਸਟਮ ਕਿਵੇਂ ਚੱਲੇਗਾ:

• ਸਿਰਫ਼ API: ਇੱਕ ਰਿਕuest/ਰਿਸਪਾਂਸ ਸਰਵਿਸ (ਚੈਟ, ਖੋਜ, ਸਿਫਾਰਿਸ਼ਾਂ ਲਈ ਆਮ)।
• ਬੈਚ ਜੌਬਜ਼: ਨਿਯਤ ਸਮੇਂ ਪ੍ਰੋਸੈਸਿੰਗ (ਰਾਤ ਦੇ ਸਮੇਂ ਦਸਤਾਵੇਜ਼ ਵਰਗੀਫਾਈ)।
• ਰੀਅਲ-ਟਾਈਮ ਸੇਵਾ: ਘੱਟ-ਲੈਟੰਸੀ ਸਟ੍ਰੀਮਿੰਗ ਜਾਂਈ ਇਵੈਂਟ-ਚਲਿਤ ਜਵਾਬ (ਘਪਲਾ ਜਾਂਚ ਆਦਿ)।

ਇਹ ਚੋਣ ਤੁਹਾਡੇ ਇੰਫਰਾ, ਕੇਸ਼ਿੰਗ, SLA, ਅਤੇ ਲਾਗਤ ਨਿਯੰਤਰਣ ਨੂੰ ਡਰਾਈਵ ਕਰਦੀ ਹੈ।

ਹਿੱਸਿਆਂ ਨੂੰ ਵੱਖ-ਵੱਖ ਰੱਖੋ ਤਾਂ ਜੋ ਉਹ ਅਜ਼ਾਦੀ ਨਾਲ ਵਿਕਸਿਤ ਹੋ ਸਕਣ

ਭਰੋਸੇਯੋਗ AI ਸਿਸਟਮ ਆਮ ਤੌਰ 'ਤੇ ਛੋਟੇ ਹਿੱਸਿਆਂ ਦਾ ਸੈੱਟ ਹੁੰਦਾ ਹੈ ਜਿਨ੍ਹਾਂ ਦੀਆਂ ਸਪੱਸ਼ਟ ਸੀਮਾਵਾਂ ਹੁੰਦੀਆਂ ਹਨ:

• UI / ਕਲਾਇੰਟ: ਇਨਪੁੱਟ ਲੈਂਦਾ, ਨਤੀਜਿਆਂ ਨੂੰ ਦਿਖਾਉਂਦਾ, ਅਨਿਸ਼ਚਿਤਤਾ ਸਮਝਾਉਂਦਾ।
• ਓਰਕੇਸ्ट्रੇਸ਼ਨ ਲੇਅਰ: ਵੈਲਿਡੇਸ਼ਨ, ਰੂਟਿੰਗ, ਪ੍ਰਾਂਪਟ ਟੈਂਪਲੇਟ, ਟੂਲ/ਫੰਕਸ਼ਨ ਕਾਲਿੰਗ, ਸਟੇਟ ਮੈਨੇਜਮੈਂਟ।
• ਮਾਡਲ ਕਾਲਸ: LLM/ML ਇੰਫਰੈਂਸ ਪ੍ਰੋਵਾਈਡਰ ਜਾਂ ਸੈੱਲਫ-ਹੋਸਟ ਰਨਟਾਈਮ ਰਾਹੀਂ।
• ਡੇਟਾ ਸਟੋਰਸ: ਫੀਚਰ ਸਟੋਰ, ਵੈਕਟਰ ਡੇਟਾਬੇਸ, ਦਸਤਾਵੇਜ਼ ਸਟੋਰ, ਲੌਗ/ਆਡਿਟ ਟੇਬਲ।

ਭਾਵੇਂ ਤੁਸੀਂ ਪਹਿਲਾਂ ਇਹਨਾਂ ਨੂੰ ਇਕੱਠੇ ਡਿਪਲੋਏ ਕਰੋ, ਡਿਜ਼ਾਇਨ ਇੱਜ਼ਨ ਕਰ ਦਿਓ ਕਿ ਹਰ ਹਿੱਸਾ ਬਦਲ ਸਕਦਾ ਹੈ।

ਫੇਲ ਚੋਣ ਲਈ ਡਿਜ਼ਾਇਨ ਕਰੋ (ਕਿਉਂਕਿ ਇਹ ਹੋਵੇਗਾ)

ਨੈੱਟਵਰਕ ਟਾਈਮਆਊਟ, ਪ੍ਰੋਵਾਈਡਰ ਰੇਟ-ਲਿਮਿਟ, ਅਤੇ ਕਈ ਵਾਰੀ ਮਾਡਲ ਅਣਉપਯੋਗ ਆਉਟਪੁੱਟ ਦੇ ਸਕਦਾ ਹੈ। ਪੇਸ਼ਗੋਈਯੋਗ ਵਿਵਹਾਰ ਬਣਾਓ:

• ਹਰ ਬਾਹਰੀ ਕਾਲ ਲਈ ਟਾਇਮਆਊਟ
• ਆਥਰਿਕ ਤਰਤੀਬੀ ਗਲਤੀਆਂ ਲਈ ਬੈਕਆਫ ਰੀਟ੍ਰਾਈਜ਼
• ਫਾਲਬੈਕ (ਸਧਾਰਨ ਮਾਡਲ, ਕੇਸ਼ ਕੀਤੀ ਨਤੀਜਾ, "ਸੇਫ ਮੋਡ")
• ਗ੍ਰੇਸਫੁਲ ਡਿਗਰੇਡੇਸ਼ਨ (ਅੰਸ਼ਕ ਨਤੀਜੇ, ਸਪੱਸ਼ਟ ਸੁਨੇਹਾ, ਟੁੱਟਾ UI ਨਾ ਹੋਵੇ)

ਇਕ ਵਧੀਆ ਨੀਤਿ: ਸਿਸਟਮ “ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ” ਫੇਲ ਹੋਵੇ ਅਤੇ ਕੀ ਹੋਇਆ ਇਹ ਵਿਵਰਣ ਦੇਵੇ—ਖਾਮੋਸ਼ੀ ਨਾਲ ਅਨੁਮਾਨ ਨਹੀਂ ਲਗਾਏ।

ਨਿਰਭਰਤਾਵਾਂ ਅਤੇ ਮਲਕੀਅਤ ਦਸਤਾਵੇਜ਼ ਕਰੋ

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

ਪਲੇਟਫਾਰਮ ਕਿੱਥੇ ਮਦਦ ਕਰ ਸਕਦੇ ਹਨ (ਬਿਨਾਂ ਤੁਹਾਨੂੰ ਲੌਕ ਕਰਨ ਦੇ)

ਜੇ ਤੁਹਾਡੀ ਸਭ ਤੋਂ ਵੱਡੀ ਰੁਕਾਵਟ ਇੱਕ ਕੰਮ ਕਰਨ ਵਾਲੀ ਡੈਮੋ ਨੂੰ ਮੇਨਟੇਨੇਬਲ ਐਪ ਵਿੱਚ ਬਦਲਣਾ ਹੈ, ਤਾਂ ਇੱਕ ਢਾਂਚਾਬੱਦਲ ਪਲੇਟਫਾਰਮ "ਪਲੰਬਿੰਗ" ਕੰਮ ਤੇਜ਼ ਕਰ ਸਕਦਾ ਹੈ: ਵੈੱਬ UI, API ਲੇਅਰ, ਡੇਟਾਬੇਸ, ਪ੍ਰਮਾਣੀਕਰਨ, ਅਤੇ ਡਿਪਲੋਇਮੈਂਟ।

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

ਲਾਗਤ, ਲੈਟੰਸੀ, ਅਤੇ ਸਕੇਲਵੲਹ ਯੋਜਨਾ

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

ਇੱਕ ਬੇਸਲਾਈਨ ਖਰਚ ਮਾਡਲ ਬਣਾਓ

ਇੱਕ ਸਧਾਰਣ ਸਪ੍ਰੈਡਸ਼ੀਟ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ ਜਿਸ ਨੂੰ ਤੁਸੀਂ ਗੈਰ-ਇੰਜੀਨੀਅਰ ਨੂੰ ਸਮਝਾ ਸਕੋ:

• ਪ੍ਰਤੀ ਬੇਨਤੀ: ਟੋਕਨ in/out (LLMs), ਮਾਡਲ ਰਨਟਾਈਮ, ਅਤੇ ਕੋਈ ਵੀ ਰੀਟਰੀਵਲ ਕਾਲ
• ਇੰਫ੍ਰਾ: ਕੰਪਿਊਟ (CPU/GPU), ਸਟੋਰੇਜ (ਦਸਤਾਵੇਜ਼, ਐੰਬੈਡੀੰਗ), ਅਤੇ ਨੈੱਟਵਰਕ ਏਗਜ਼ਿਸ
• ਓਪਰੇਸ਼ਨਲ ਓਵਰਹੈੱਡ: ਲੌਗਿੰਗ ਵਾਲਿਊਮ, ਨਿਗਰਾਨੀ, ਅਤੇ ਰੀਟ੍ਰਾਈਜ਼

ਇਸ ਤੋਂ, ਹਰ 1,000 ਬੇਨਤੀਆਂ ਦੀ ਲਾਗਤ ਅਤੇ ਉਮੀਦਿਤ ਟ੍ਰੈਫਿਕ 'ਤੇ ਮਾਸਿਕ ਲਾਗਤ ਦਾ ਅੰਦਾਜ਼ਾ ਲਗਾਓ। “ਖਰਾਬ ਦਿਨ” ਸ਼ਾਮਿਲ ਕਰੋ: ਵੱਧ ਟੋਕਨ ਵਰਤੋਂ, ਜ਼ਿਆਦਾ ਰੀਟ੍ਰਾਈਜ਼, ਜਾਂ ਭਾਰੀ ਦਸਤਾਵੇਜ਼।

ਵਿਵਹਾਰ ਬਦਲੇ ਬਿਨਾਂ ਓਪਟੀਮਾਈਜ਼ ਕਰੋ

ਪ੍ਰਾਂਪਟ ਜਾਂ ਮਾਡਲ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ, ਉਹ ਸੁਧਾਰ ਲੱਭੋ ਜੋ ਆਉਟਪੁੱਟ ਬਦਲੇ ਬਿਨਾਂ ਹੋ ਸਕਦੇ:

• ਕੇਸ਼ਿੰਗ: ਦੁਹਰਾਈ ਗਈ ਇਨਪੁਟਸ ਲਈ ਨਤੀਜੇ ਸਟੋਰ ਕਰੋ
• ਬੈਚਿੰਗ: ਇੱਕ ਵਾਰ ਵਿੱਚ ਕਈ ਬੇਨਤੀਆਂ ਪ੍ਰੋਸੈਸ ਕਰੋ ਜਿੱਥੇ ਸੰਭਵ (ਐੰਬੈਡਿੰਗ, ਮੋਡਰੇਸ਼ਨ)
• ਛੋਟਾ ਸੰਦਰਭ: ਬੁਨਿਆਦੀ ਹਦਾਇਤਾਂ ਘਟਾਓ, ਨਕਲ ਕੀਤੀਆਂ ਪੈਸੀਜ ਹਟਾਓ, ਅਤੇ ਇਤਿਹਾਸ ਦੀ ਲੰਬਾਈ ਸੀਮਤ ਕਰੋ

ਇਹ ਆਮ ਤੌਰ 'ਤੇ ਖਰਚ ਘਟਾਉਂਦੇ ਅਤੇ ਲੈਟੰਸੀ ਸੁਧਾਰਦੇ ਹਨ।

ਬਜਟ ਅਤੇ ਵਿਸ਼ਮਤਾ ਅਲਰਟ ਸੈੱਟ ਕਰੋ

ਪਹਿਲਾਂ ਇਹ ਤੈਅ ਕਰੋ ਕਿ “ਸਵੀਕਾਰਯੋਗ” ਕੀ ਹੈ (ਉਦਾਹਰਨ ਲਈ, ਪ੍ਰਤੀ ਬੇਨਤੀ ਅਧਿਕਤਮ ਲਾਗਤ, ਰੋਜ਼ਾਨਾ ਖਰਚ ਸੀਮਾ)। ਫਿਰ ਅਲਰਟ ਸੈੱਟ ਕਰੋ:

• ਟੋਕਨ/ਬੇਨਤੀ ਵਿੱਚ ਅਚਾਨਕ ਉਛਾਲ
• ਵਧੇ ਰੀਟ੍ਰਾਈਜ਼
• ਅਟੇਂਡੇਟ ਲੌਗਿੰਗ ਵਾਧਾ

ਅਸਲ ਟ੍ਰੈਫਿਕ ਲਈ ਸਮਰੱਥਾ ਯੋਜਨਾ ਬਣਾਓ

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

ਸੁਰੱਖਿਆ, ਪਰਦੇਦਾਰੀ, ਅਤੇ ਅਨੁਕੂਲਤਾ ਦੀਆਂ ਲੋੜਾਂ

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

ਸਾਧਾਰਣ ਖ਼ਤਰੇ ਦਾ ਮਾਡਲ ਬਣਾਓ

ਆਪਣੇ AI ਫੀਚਰ ਦੇ ਉਪਯੋਗ ਜਾਂ ਫੇਲ ਹੋਣ ਦੇ ਵਾਸਤਵਿਕ ਤਰੀਕੇ ਲਿਖੋ:

• ਪ੍ਰਾਂਪਟ ਇੰਜੈਕਸ਼ਨ: ਯੂਜ਼ਰ ਮਾਡਲ ਨੂੰ ਨੁਕਸਾਨ ਪਹੁੰਚਾਉਣ ਵਾਲੀਆਂ ਨਿਰਦੇਸ਼ਾਂ ਮੰਨਣ ਲਈ ਮਨਾਉਂਦੇ ਹਨ।
• ਡੇਟਾ ਲੀਕੇਜ: ਸੰਵੇਦਨਸ਼ੀਲ ਇਨਪੁੱਟ (ਗਾਹਕ ਜਾਣਕਾਰੀ, ਅੰਦਰੂਨੀ ਦਸਤਾਵੇਜ਼) ਆਉਟਪੁੱਟ, ਲੌਗ, ਜਾਂ ਪ੍ਰੋਵਾਈਡਰ ਡੈਸ਼ਬੋਰਡ ਵਿੱਚ ਆ ਸਕਦੀ ਹੈ।
• ਅਣਸੁਰੱਖਿਅਤ ਟੂਲ ਪਹੁੰਚ: ਮਾਡਲ ਉਹ ਟੂਲ ਕਾਲ ਕਰ ਸਕਦਾ ਹੈ ਜੋ ਇਸਨੂੰ ਨਹੀਂ ਕਰਨੀ ਚਾਹੀਦੀ (ਜਿਵੇਂ “ਯੂਜ਼ਰ ਹਟਾਓ”, “ਡੈਟਾਬੇਸ ਨਿਰਯਾਤ”), ਜਾਂ ਬਿਨਾਂ ਯੋਗ ਪੁਸ਼ਟੀ ਦੇ ਵਰਤ ਸਕਦਾ ਹੈ।

ਇਹ ਖਤਰਾ ਮਾਡਲ ਤੁਹਾਡੇ ਡਿਜ਼ਾਇਨ ਸਮੀਖਿਆਂ ਅਤੇ ਐਕਸੈਪਟੈਂਸ ਮਾਪਦੰਡਾਂ ਨੂੰ ਜਾਣਕਾਰ ਕਰੇਗਾ।

ਜਿੱਥੇ ਜੋਖਿਮ ਉੱਚਾ ਹੈ ਉਥੇ ਗਾਰਡਰੇਲਜ਼ ਜੋੜੋ

ਇਨਪੁਟ, ਆਉਟਪੁੱਟ, ਅਤੇ ਟੂਲ ਕਾਲਾਂ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਗਾਰਡਰੇਲਜ਼ ਉਪਰਧਾਰਿਤ ਕਰੋ:

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

ਸੀਕ੍ਰੇਟਸ, ਪਹੁੰਚ, ਅਤੇ ਅਨੁਕੂਲਤਾ ਬੁਨਿਆਦੀਆਂ

API ਕੁੰਜੀਆਂ ਅਤੇ ਟੋਕਨ ਨੂੰ ਕੋਡ ਜਾਂ ਨੋਟਬੁੱਕ ਵਿੱਚ ਨਹੀਂ ਰੱਖੋ—ਉਹਨਾਂ ਨੂੰ ਇੱਕ ਸੇਕ੍ਰੇਟ ਮੈਨੇਜਰ ਵਿੱਚ ਰੱਖੋ। ਲੀਸਟ-ਆਫ-ਪ੍ਰਿਵਿਲੇਜ਼ ਨੂੰ ਲਾਗੂ ਕਰੋ: ਹਰ ਸਰਵਿਸ ਅਕਾਊਂਟ ਨੂੰ ਘੱਟ ਤੋਂ ਘੱਟ ਡਾਟਾ ਅਤੇ ਕਾਰਵਾਈਆਂ ਲਈ ਪਹੁੰਚ ਹੋਵੇ।

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

ਮਨੁੱਖ-ਇਨ-ਦ-ਲੂਪ ਅਤੇ ਭਰੋਸੇ ਲਈ UX

ਇੱਕ ਪ੍ਰੋਟੋਟਾਈਪ ਅਕਸਰ ਮੰਨ ਲੈਂਦਾ ਹੈ ਕਿ ਮਾਡਲ “ਕਾਫ਼ੀ ਠੀਕ” ਹੈ। ਪ੍ਰੋਡਕਸ਼ਨ ਵਿੱਚ, ਤੁਹਾਨੂੰ ਸਪਸ਼ਟ ਯੋਜਨਾ ਚਾਹੀਦੀ ਹੈ ਕਿ ਲੋਕ ਕਦੋਂ ਦਖਲ ਦੇਣ—ਖਾਸ ਕਰਕੇ ਜਦ ਨਤੀਜੇ ਗਾਹਕਾਂ, ਪੈਸੇ, ਸੁਰੱਖਿਆ, ਜਾਂ ਸਬੰਧ 'ਤੇ ਪ੍ਰਭਾਵ ਪਾਉਂਦੇ ਹਨ। ਮਨੁੱਖ-ਇਨ-ਦ-ਲੂਪ (HITL) ਆਟੋਮੇਸ਼ਨ ਦੀ ਨਾਕਾਮੀ ਨਹੀਂ ਹੈ; ਇਹ ਇੱਕ ਨਿਯੰਤਰਣ ਪ੍ਰਣਾਲੀ ਹੈ ਜੋ ਤੁਸੀਂ ਸਿੱਖਦੇ ਹੋਏ ਗੁਣਵੱਤਾ ਉੱਚੀ ਰੱਖਦੀ ਹੈ।

ਮਨੁੱਖ ਕਿੱਥੇ ਸਮੀਖਿਆ ਕਰਨਗੇ ਇਹ ਫੈਸਲਾ ਕਰੋ

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

ਸਮੀਖਿਆ ਲਈ ਟ੍ਰਿੱਗਰ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ:

• ਘੱਟ ਮਾਡਲ ਕਾਨਫਿਡੈਂਸ ਜਾਂ ਮਿਸਿੰਗ ਹਵਾਲੇ
• ਸੰਵੇਦਨਸ਼ੀਲ ਵਿਸ਼ੇ
• ਅਸਪਸ਼ਟ ਯੂਜ਼ਰ ਬੇਨਤੀਆਂ
• ਵੱਡਾ ਡਾਊਨਸਟ੍ਰੀਮ ਪ੍ਰਭਾਵ (ਰਿਫੰਡ, ਖਾਤਾ ਬਦਲਾਅ)

ਵਰਤੋਂਯੋਗ ਫੀਡਬੈਕ ਰਿਕਾਰਡ ਕਰੋ

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

ਜਿੱਥੇ ਸੰਭਵ ਹੋਵੇ, ਇਹ ਸਟੋਰ ਕਰੋ:

• ਮੂਲ ਇਨਪੁੱਟ ਅਤੇ ਆਖਰੀ ਸੋਧਿਆ ਰੂਪ
• ਕਾਰਨ ਕੋਡ
• ਕੀ ਸਮੱਸਿਆ ਤੱਥੀ, ਫਾਰਮੈਟਿੰਗ, ਪਾਲਸੀ-ਸਬੰਧੀ, ਜਾਂ ਸੁਰੱਖਿਆ-ਸਬੰਧੀ ਸੀ

ਖਤਰਨਾਕ ਕੇਸੀਜ਼ ਨੂੰ ਐਸਕਲੇਟ ਕਰੋ

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

UI ਵਿੱਚ ਉਮੀਦਾਂ ਸੈਟ ਕਰੋ

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

ਨਿਗਰਾਨੀਯੋਗਤਾ: ਲੌਗਿੰਗ, ਮਾਨੀਟਰਨਗ, ਅਤੇ ਅਲਰਟਿੰਗ

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

ਜਰੂਰੀ ਚੀਜ਼ਾਂ ਲੌਗ ਕਰੋ (ਅਤੇ ਉਨ੍ਹਾਂ ਨੂੰ ਵਰਤਣਯੋਗ ਬਣਾਓ)

ਇੱਕ ਵਾਰ-ਘਟਨਾ ਨੂੰ ਪੁਨਰ-ਨਿਰਮਿਤ ਕਰਨ ਲਈ ਤੁਹਾਨੂੰ ਕੀ ਲੋੜ ਹੈ ਇਹ ਤੈਅ ਕਰੋ। AI ਸਿਸਟਮ ਲਈ, "ਇੱਕ ਗਲਤੀ ਹੋਈ" ਕਾਫ਼ੀ ਨਹੀਂ। ਲੌਗ ਕਰੋ:

• ਬੇਨਤੀ/ਇੰਪੁੱਟ (ਜੇ ਇਹ ਸੰਵੇਦਨਸ਼ੀਲ ਹੋ ਸਕਦੇ ਹਨ ਤਾਂ ਰੈਡੈਕਟ ਜਾਂ ਟੋਕਨਾਈਜ਼ ਕਰੋ)
• ਮਾਡਲ ਅਤੇ ਪ੍ਰਾਂਪਟ ਵਰਜ਼ਨ, ਅਤੇ ਮੁੱਖ ਕਨਫਿਗਰੇਸ਼ਨ (ਟੈਂਪਰੇਚਰ, ਕੁੰਜੀ ਅਨੁਸੂਚੀ)
• ਕੋਈ ਵੀ ਟੂਲ ਕਾਲ (API, ਡੈਟਾਬੇਸ ਕਵੈਰੀ, ਵੈੱਬ ਖੋਜ) ਅਤੇ ਉਹਨਾਂ ਦੇ ਨਤੀਜੇ
• ਲੈਟੰਸੀ ਢਾਂਚਾ (ਰੀਟਰੀਵਲ ਸਮਾਂ ਬਣਾਮ ਮਾਡਲ ਸਮਾਂ ਬਣਾਮ ਡਾਊਨਸਟ੍ਰੀਮ ਕਾਲ)

ਲੌਗਾਂ ਨੂੰ ਸੰਰਚਿਤ (JSON) ਰੱਖੋ ਤਾਂ ਜੋ ਤੁਸੀਂ ਟੀਨੈਂਟ, ਐਂਡਪੋਇੰਟ, ਮਾਡਲ ਵਰਜ਼ਨ, ਅਤੇ ਫੇਲ ਦੀ ਕਿਸਮ ਦੇ ਅਨੁਸਾਰ ਛਾਣ-ਬੀਨ ਕਰ ਸਕੋ। ਇੱਕ ਚੰਗੀ ਨੀਤਿ: ਜੇ ਤੁਸੀਂ ਲੌਗਾਂ ਤੋਂ “ਕੀ ਬਦਲਿਆ?” ਦਾ ਜਵਾਬ ਨਹੀਂ ਦੇ ਸਕਦੇ, ਤਾਂ ਤੁਸੀਂ ਲੌਗ ਫੀਲਡਾਂ ਗੁਆ ਰਹੇ ਹੋ।

ਸਿਰਫ਼ uptime ਨਹੀਂ—ਗੁਣਵੱਤਾ ਮਾਨੀਟਰ ਕਰੋ

ਰਵਾਇਤੀ ਮਾਨੀਟਰਨਗ ਠਹਿਰਾਉਂਦਾ ਹੈ ਕਿ ਕੰਮ ਕਰ ਰਿਹਾ ਹੈ। AI ਨੂੰ ਉਹ ਮਾਨੀਟਰਨਗ ਚਾਹੀਦੀ ਹੈ ਜੋ “ਹਾਲੇ ਚੱਲ ਰਿਹਾ ਹੈ, ਪਰ ਖਰਾਬ” ਨੂੰ ਫੜੇ। ਟ੍ਰੈਕ ਕਰੋ:

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

ਇਹਨਾਂ ਨੂੰ ਫਰਸਟ-ਕਲਾਸ ਮੈਟਰਿਕਸ ਵਜੋਂ ਰੱਖੋ ਜਿਨ੍ਹਾਂ ਦੇ ਪਰਿਬੁੱਧ ਥਰੈਸ਼ਹੋਲਡ ਅਤੇ ਮਲਕੀਅਤ ਵਾਲੇ ਹਨ।

ਡੈਸ਼ਬੋਰਡ, ਅਲਰਟ, ਅਤੇ ਰਨਬੁਕਸ

ਡੈਸ਼ਬੋਰਡ ਦਾ ਉੱਦੇਸ਼: “ਕੀ ਇਹ ਸਿਹਤਮੰਦ ਹੈ?” ਅਤੇ “ਸਭ ਤੋਂ ਤੇਜ਼ ਸਹੀ ਠੀਕ ਕੀ ਹੈ?” ਹਰ ਅਲਰਟ ਨਾਲ ਇੱਕ ਆਨ-ਕਾਲ ਰਨਬੁਕ ਜੁੜਾ ਹੋਵੇ: ਕੀ ਦੇਖਣਾ ਹੈ, ਕਿਵੇਂ ਰੋਲਬੈਕ ਕਰਨਾ ਹੈ, ਅਤੇ ਕਿਸ ਨੂੰ ਸੂਚਿਤ ਕਰਨਾ ਹੈ। ਸ਼ੋਰ ਕਰਨ ਵਾਲਾ ਅਲਰਟ ਬਿਨਾਂ ਕੋਈ ਹੋਣਾ ਵਧੀਆ ਨਹੀਂ—ਅਲਰਟਾਂ ਨੂੰ ਤਿਉਨ ਕਰੋ ਤਾਂ ਕਿ ਸਿਰਫ ਯੂਜ਼ਰ ਪ੍ਰਭਾਵ 'ਤੇ ਪੇਜ ਕੀਤਾ ਜਾਵੇ।

ਸੰਸਲੇ ਪ੍ਰੋਬਸ: ਯੂਜ਼ਰਾਂ ਤੋਂ ਪਹਿਲਾਂ ਸਮੱਸਿਆ ਫੜੋ

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

MLOps ਵਰਕਫਲੋਅ: CI/CD, ਵਰਜਨਿੰਗ, ਅਤੇ ਵਾਤਾਵਰਣ

ਇੱਕ ਪ੍ਰੋਟੋਟਾਈਪ ਲੈਪਟੌਪ 'ਤੇ ਇੱਕ ਵਾਰ ਕੰਮ ਕਰਨ ਨਾਲ “ਮੁਕੰਮਲ” ਮਹਿਸੂਸ ਕਰਦਾ ਹੈ। ਪ੍ਰੋਡਕਸ਼ਨ ਦਾ ਕੰਮ ਜ਼ਿਆਦਾਤਰ ਇਹ ਬਣਾਉਂਦਾ ਹੈ ਕਿ ਇਹ ਹਮੇਸ਼ਾ ਕੰਮ ਕਰੇ—ਸਹੀ ਇਨਪੁਟਸ ਲਈ, ਦੁਹਰਾਓਯੋਗ ਰਿਲੀਜ਼ਾਂ ਨਾਲ। ਇਹ MLOps ਵਰਕਫਲੋਅ ਹੈ: ਆਟੋਮੇਸ਼ਨ, ਟ੍ਰੇਸਬਿਲਿਟੀ, ਅਤੇ ਸੁਰੱਖਿਅਤ ਰਸਤੇ।

ਬਿਲਡ, ਟੈਸਟ, ਅਤੇ ਡਿਪਲੋਏਮੈਂਟ ਆਟੋਮੇਟ ਕਰੋ

ਆਪਣੀ AI ਸਰਵਿਸ ਨੂੰ ਕਿਸੇ ਵੀ ਹੋਰ ਉਤਪਾਦ ਦੀ ਤਰ੍ਹਾਂ ਵਰਤੋ: ਹਰ ਬਦਲਾਅ ਨੇ ਇੱਕ ਆਟੋਮੇਟਿਕ ਪਾਈਪਲਾਈਨ ਚਲਾਉਣੀ ਚਾਹੀਦੀ ਹੈ।

ਘੱਟੋ-ਘੱਟ, ਤੁਹਾਡੀ CI ਨੇ ਇਹ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ:

• ਸਰਵਿਸ ਬਣਾਓ (ਕੰਟੇਨਰ/ਐਪ ਪੈਕੇਜ)
• ਕੋਰ ਲੋਜਿਕ ਅਤੇ ਡੇਟਾ ਵੈਲਿਡੇਸ਼ਨ ਲਈ ਯੂਨਿਟ ਟੈਸਟ ਚਲਾਓ
• ਇੱਕ ਨਿਰਧਾਰਿਤ ਡੇਟਾਸੈੱਟ 'ਤੇ ਮਾਡਲ/ਪ੍ਰਾਂਪਟ ਮੁਲਾਂਕਣ ਟੈਸਟ ਚਲਾਓ (ਬੁਰੇ ਅਤੇ ਐਜ ਕੇਸ ਸਮੇਤ)
• ਇੱਕ ਆਰਟੀਫੈਕਟ ਤਿਆਰ ਕਰੋ ਜੋ ਤੁਸੀਂ ਡਿਪਲੋਇ ਕਰ ਸਕਦੇ ਹੋ (ਇਮੇਜ, ਪੈਕੇਜ, ਜਾਂ ਬੰਡਲ)

CD ਨੇ ਉਸ ਆਰਟੀਫੈਕਟ ਨੂੰ ਟਾਰਗਟ ਵਾਤਾਵਰਣ (dev/staging/prod) 'ਤੇ ਇੱਕੋ ਹੀ ਕਦਮਾਂ ਨਾਲ ਡਿਪਲੋਏ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ। ਇਹ “ਮੇਰੇ ਮਸ਼ੀਨ ਤੇ ਚੱਲਦਾ ਸੀ” ਆਸ਼ਾਵਾਦੀ ਹਨੇਰਾ ਘਟਾਉਂਦਾ ਹੈ ਅਤੇ ਰੋਲਬੈਕ ਨੂੰ ਯਥਾਰਥਕ ਬਣਾਉਂਦਾ ਹੈ।

ਕੋਡ, ਪ੍ਰਾਂਪਟ, ਅਤੇ ਕੰਫ਼ਿਗਰੇਸ਼ਨ ਲਈ ਵਰਜਨ ਕੰਟਰੋਲ

AI ਸਿਸਟਮ ਪਰੰਪਰਿਕ ਐਪਸ ਨਾਲੋਂ ਹੋਰ ਤਰੀਕਿਆਂ ਨਾਲ ਬਦਲਦੇ ਹਨ। ਇਹਨਾਂ ਨੂੰ ਵਰਜਨ ਕਰੋ:

• ਐਪਲੀਕੇਸ਼ਨ ਕੋਡ (API, ਓਰਕੇਸ्ट्रੇਸ਼ਨ, ਫੀਚਰ ਲੋਜਿਕ)
• ਪ੍ਰਾਂਪਟ, ਟੈਂਪਲੇਟ, ਅਤੇ ਸਿਸਟਮ ਸੁਨੇਹੇ (LLM-ਅਧਾਰਤ ਹਿੱਸਿਆਂ ਲਈ)
• ਮਾਡਲ ਪਛਾਣਕਰ (ਮਾਡਲ ਨਾਮ, ਚੈਕਪੌਇੰਟ, ਪ੍ਰੋਵਾਈਡਰ ਸੈਟਿੰਗ)
• ਕੰਫ਼ਿਗਰੇਸ਼ਨ (ਥਰੈਸ਼ਹੋਲਡ, ਰੂਟਿੰਗ ਨਿਯਮ, ਟੂਲ ਅਧਿਕਾਰ)
• ਮੁਲਾਂਕਣ ਡੇਟਾਸੈੱਟ ਅਤੇ ਲੇਬਲਿੰਗ ਦਿਸ਼ਾ-ਨਿਰਦੇਸ਼

ਇੱਕ ਘਟਨਾ ਹੋਣ 'ਤੇ ਤੁਹਾਨੂੰ ਉੱਤਰ ਦੇਣਾ ਹੁੰਦਾ ਹੈ: “ਇਸ ਆਉਟਪੁੱਟ ਨੂੰ ਕਿਸ ਪ੍ਰਾਂਪਟ + ਮਾਡਲ + ਕੰਫਿਗ ਨੇ ਤਿਆਰ ਕੀਤਾ?” ਬਿਨਾਂ ਅਨੁਮਾਨ ਦੇ।

ਸਟੇਜਡ ਵਾਤਾਵਰਣ ਵਰਤੋ: dev → staging → production

ਘੱਟੋ-ਘੱਟ ਤਿੰਨ ਵਾਤਾਵਰਣ ਵਰਤੋ:

• Dev: ਤੇਜ਼ ਤਜਰਬਾ-ਉੱਤੇ mock ਇੰਟੀਗ੍ਰੇਸ਼ਨ
• Staging: ਪ੍ਰੋਡਕਸ਼ਨ-ਵਾਂਗ ਡੇਟਾ ਫਲੋਅ ਅਤੇ ਪਰਮਿਸ਼ਨ; ਪੂਰੇ ਮੁਲਾਂਕਣ ਗੇਟ ਚਲਾਓ
• Production: ਨਿਯੰਤਰਿਤ ਰਿਲੀਜ਼, ਕਠੋਰ ਪਹੁੰਚ, ਅਤੇ ਆਡਿਟਿੰਗ

ਉਸੇ ਆਰਟੀਫੈਕਟ ਨੂੰ ਵਾਤਾਵਰਣਾਂ ਰਾਹੀਂ ਪ੍ਰਮੋਟ ਕਰੋ। ਪ੍ਰੋਡਕਸ਼ਨ ਲਈ “ਰੀ-ਬਿਲਡ” ਕਰਨ ਤੋਂ ਬਚੋ।

ਪ੍ਰਯੋਗੀ ਰੋਲਆਊਟ ਚੈੱਕਲਿਸਟ ਅਤੇ ਦੁਹਰਾਓਯੋਗ ਸਕੈਫੋਲਡ

ਜੇ ਤੁਸੀਂ CI/CD ਗੇਟਸ, ਵਰਜਨਿੰਗ ਰਿਵਾਜ, ਅਤੇ ਵਾਤਾਵਰਣ ਪ੍ਰਮੋਸ਼ਨ ਲਈ ਤਤਕਾਲ ਵਰਤਣਯੋਗ ਚੈੱਕਲਿਸਟ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ /blog ਵਿੱਚ ਨਮੂਨੇ ਅਤੇ ਉਦਾਹਰਣ ਹਨ, ਅਤੇ /pricing ਵਿੱਚ ਪੈਕੇਜਡ ਰੋਲਆਊਟ ਸਹਾਇਤਾ।

ਜੇ ਤੁਸੀਂ Koder.ai ਵਰਤ ਰਹੇ ਹੋ (ਉਦਾਹਰਨ ਵਜੋਂ ਇੱਕ React ਵੈੱਬ UI ਅਤੇ Go API ਨਾਲ PostgreSQL, ਜਾਂ ਇੱਕ Flutter ਮੋਬਾਈਲ ਕਲਾਇੰਟ), ਤਾਂ ਉਸ ਦੀ ਸਨੇਪਸ਼ਾਟ/ਰੋਲਬੈਕ ਅਤੇ ਵਾਤਾਵਰਣ ਸੈੱਟਅਪ ਨੂੰ ਇੱਕੋ ਹੀ ਰਿਲੀਜ਼ ਅਨੁਸ਼ਾਸਨ ਦਾ ਹਿੱਸਾ ਮੰਨੋ: staging ਵਿੱਚ ਟੈਸਟ ਕਰੋ, ਨਿਯੰਤਰਿਤ ਰੋਲਆਊਟ ਰਾਹੀਂ ਸ਼ਿਪ ਕਰੋ, ਅਤੇ ਆਖਰੀ ਤਰੀਕੇ ਨਾਲ-ਚੰਗੇ ਵਰਜ਼ਨ 'ਤੇ ਵਾਪਸੀ ਦਾ ਸਾਫ ਰਸਤਾ ਰੱਖੋ।

ਡਿਪਲੋਏਮੈਂਟ ਅਤੇ ਰੋਲਆਊਟ ਰਣਨੀਤੀਆਂ

AI ਪ੍ਰੋਟੋਟਾਈਪ ਨੂੰ ਭੇਜਣਾ ਇਕ ਸਿੰਗਲ “ਡਿਪਲੋਏ” ਬਟਨ ਨਹੀਂ—ਇਹ ਗਾਰਡਰੇਲਜ਼ ਵਾਲਾ ਨਿਯੰਤਰਿਤ ਪ੍ਰਯੋਗ ਹੈ। ਤੁਹਾਡਾ ਟੀਚਾ ਤੇਜ਼ੀ ਨਾਲ ਸਿੱਖਣਾ ਹੈ ਬਿਨਾਂ ਯੂਜ਼ਰ ਭਰੋਸਾ, ਬਜਟ, ਜਾਂ ਆਪਰੇਸ਼ਨਾਂ ਨੂੰ ਤੋੜੇ।

ਜੋਖਮ ਨਾਲ ਮੇਲ ਖਾਵੇ ਐਕ ਰੋਲਆਊਟ ਮੋਡ ਚੁਣੋ

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

ਕੈਨਾਰੀ ਰਿਲੀਜ਼ ਨਵੇਂ ਵਰਜ਼ਨ ਨੂੰ ਘੱਟ ਪ੍ਰਤੀਸ਼ਤ ਜਵਾਬ ਭੇਜਦੇ ਹਨ। ਮੈਟਰਿਕਾਂ ਠੀਕ ਰਹੇ ਤਾਂ ਹੌਲੀ-ਹੌਲੀ ਵਧਾਇਆ ਜਾਵੇ।

A/B ਟੈਸਟਸ ਦੋ ਵਿਕਲਪਾਂ (ਮਾਡਲ, ਪ੍ਰਾਂਪਟ, ਰੀਟ੍ਰੀਵਲ ਰਣਨੀਤੀ, ਜਾਂ UI) ਦੀ ਤੁਲਨਾ ਪੂਰਵ-ਨਿਰਧਾਰਿਤ ਸਫਲਤਾ ਮੈਟਰਿਕ ਨਾਲ ਕਰਨ ਲਈ। ਜਦ ਤੁਸੀਂ ਸੁਧਾਰ ਦਾ ਸਬੂਤ ਚਾਹੁੰਦੇ ਹੋ ਤਾਂ ਇਹ ਵਰਤੋ।

ਫੀਚਰ ਫ਼ਲੈਗਸ ਤੁਹਾਨੂੰ ਯੂਜ਼ਰ ਸੈਗਮੈਂਟ (ਅੰਦਰੂਨੀ ਯੂਜ਼ਰ, ਪਾਵਰ ਯੂਜ਼ਰ, ਖਾਸ ਖੇਤਰ) ਦੁਆਰਾ AI ਫੀਚਰ ਯੋਗ ਕਰਨ ਅਤੇ ਤੁਰੰਤ ਬਿਨਾਂ ਡਿਪਲੋਏਮੈਂਟ ਦੇ ਸੁਆਪ ਕਰਨ ਦਿੰਦੇ ਹਨ।

ਲਾਂਚ ਮਾਪਦੰਡ ਅਤੇ ਰੋਕਣ ਦੀਆਂ ਸ਼ਰਤਾਂ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ

ਪਹਿਲੀ ਰੋਲਆਊਟ ਤੋਂ ਪਹਿਲਾਂ, “ਜਾਵਾਂ/ਨਹੀਂ ਜਾਵਾਂ” ਥਰੈਸ਼ਹੋਲਡ ਲਿਖੋ: ਗੁਣਵੱਤਾ ਸਕੋਰ, ਗਲਤੀ ਦਰ, ਹੱਲੂਸੀਨੇਸ਼ਨ ਦਰ (LLMs ਲਈ), ਲੈਟੰਸੀ, ਅਤੇ ਪ੍ਰਤੀ ਬੇਨਤੀ ਲਾਗਤ। ਨਾਲ ਹੀ ਰੋਕਣ ਦੀਆਂ ਸ਼ਰਤਾਂ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ ਜੋ ਆਟੋਮੈਟਿਕ ਰੋਕਨ ਵਾਲੀ ਸਕੇ। ਉਦਾਹਰਨ: ਅਸੁਰੱਖਿਅਤ ਆਉਟਪੁੱਟ ਦਾ ਸ਼ਿਕਾਰ ਹੋਣਾ, ਸਪੋਰਟ ਟਿਕਟਾਂ ਵਿੱਚ ਉਛਾਲ, ਜਾਂ p95 ਲੈਟੰਸੀ।

ਰੋਲਬੈਕ ਅਤੇ ਸੁਰੱਖਿਅਤ ਫਾਲਬੈਕ ਯੋਜਨਾ ਬਣਾਓ

ਰੋਲਬੈਕ ਇਕ ਇੱਕ-ਕਦਮ ਕਾਰਵਾਈ ਹੋਵੇ: ਪਹਿਲਾ ਮਾਡਲ/ਪ੍ਰਾਂਪਟ/ਕੰਫਿਗਰਸ ਨੂੰ ਵਾਪਸ ਲਿਆ ਜਾਵੇ। ਯੂਜ਼ਰ-ਰੂਪ ਫਲੋਅ ਲਈ, ਇੱਕ ਫਾਲਬੈਕ ਹੋਵੇ: ਇੱਕ ਸਧਾਰਣ ਨਿਯਮ-ਆਧਾਰਿਤ ਜਵਾਬ, ਮਨੁੱਖੀ-ਸਮੀਖਿਆ ਰਾਹ, ਜਾਂ “ਜਵਾਬ ਨਹੀਂ ਦੇ ਸਕਦੇ” ਵਾਲਾ ਗ੍ਰੇਸਫੁਲ ਸੰਦੇਸ਼—ਅਨੁਮਾਨ ਲੱਗਾਉਣ ਦੀ ਥਾਂ।

ਬਦਲਾਅ ਨੂੰ ਸੰਚਾਰ ਕਰੋ

ਸਪੋਰਟ ਅਤੇ ਸਟੇਕਹੋਲਡਰਾਂ ਨੂੰ ਦੱਸੋ ਕਿ ਕੀ ਬਦਲ ਰਿਹਾ ਹੈ, ਕੌਣ ਪ੍ਰਭਾਵਿਤ ਹੋਵੇਗਾ, ਅਤੇ ਸਮੱਸਿਆ ਦੀ ਪਛਾਣ ਕਿਵੇਂ ਕਰਨੀ ਹੈ। ਇੱਕ ਛੋਟੀ ਰਨਬੁਕ ਅਤੇ ਅੰਦਰੂਨੀ FAQ ਦਿਓ ਤਾਂ ਕਿ ਟੀਮ ਜਦ ਯੂਜ਼ਰ ਪੁੱਛੇ “ਅੱਜ AI ਵੱਖਰਾ ਕਿਵੇਂ ਜਵਾਬ ਦੇ ਰਿਹਾ ਹੈ?” ਤਾਂ ਇਕਸਾਰ ਜਵਾਬ ਦੇ ਸਕੇ।

ਲਾਂਚ ਤੋਂ ਬਾਅਦ ਲਗਾਤਾਰ ਸੁਧਾਰ

ਲਾਂਚ ਇੱਕ ਨਵੀਂ ਪੜਾਅ ਦੀ ਸ਼ੁਰੂਆਤ ਹੈ: ਤੁਹਾਡਾ AI ਸਿਸਟਮ ਹੁਣ ਅਸਲ ਯੂਜ਼ਰਾਂ, ਅਸਲ ਡੇਟਾ, ਅਤੇ ਅਸਲ ਐਜ ਕੇਸ ਨਾਲ ਇੰਟਰੈਕਟ ਕਰ ਰਿਹਾ ਹੈ। ਪਹਿਲੇ ਹਫ਼ਤੇ ਨੂੰ ਸਿੱਖਣ ਦੀ ਖਿੜਕੀ ਵਜੋਂ treat ਕਰੋ, ਅਤੇ “ਸੁਧਾਰ ਕੰਮ” ਨੂੰ ਆਪਰੇਸ਼ਨਾਂ ਦਾ ਹਿੱਸਾ ਬਣਾਓ—ਨ ਕਿ ਇਕ ਇਮਰਜੈਂਸੀ ਪ੍ਰਤੀਕਿਰਿਆ।

ਮੁਲਾਂਕਣ ਨੂੰ ਹਕੀਕਤ ਦੇ ਨਾਲ ਹਮੇਸ਼ਾ ਸੰਰੇਖਿਤ ਰੱਖੋ

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

ਕਦੇ-ਕਦੇ (ਉਦਾਹਰਨ ਲਈ ਮਾਸਿਕ) ਇਹ ਕਰੋ:

• ਨਵੇਂ ਦੇਖੇ ਗਏ ਫੇਲ ਕੇਸਾਂ ਨੂੰ ਟੈਸਟ ਸੂਟ ਵਿੱਚ ਸ਼ਾਮਿਲ ਕਰੋ
• ਉਦਾਹਰਣਾਂ ਨੂੰ ਰੀਬੈਲੈਂਸ ਕਰੋ ਤਾਂ ਕਿ ਤੁਸੀਂ ਪੁਰਾਣੇ ਸੈਨਾਰਿਓਜ਼ 'ਤੇ ਓਵਰਫਿਟ ਨਾ ਹੋਵੋ
• ਉਪਸਟਰੀਮ ਬਦਲਾਅਾਂ (ਡੇਟਾ ਸਰੋਤ, UI, ਨੀਤੀਆਂ) ਦੇ ਬਾਅਦ ਗੁਣਵੱਤਾ ਦੁਬਾਰਾ ਜਾਂਚੋ

ਰੀਟਰੇਨਿੰਗ ਜਾਂ ਪ੍ਰਾਂਪਟ ਇਟਰੇਸ਼ਨ—ਬਦਲਾਅ ਨਿਯੰਤਰਣ ਨਾਲ

ਚਾਹੇ ਤੁਸੀਂ ਮਾਡਲ ਰੀਟਰੇਨ ਕਰ ਰਹੇ ਹੋ ਜਾਂ LLM ਲਈ ਪ੍ਰਾਂਪਟ/ਟੂਲਸ ਬਦਲ ਰਹੇ ਹੋ, ਬਦਲਾਅ ਨੂੰ ਉਹੀ ਨਿਯੰਤਰਣ ਲਗਾਓ ਜੋ ਪ੍ਰੋਡਕਟ ਰਿਲੀਜ਼ਾਂ 'ਤੇ ਹੁੰਦਾ ਹੈ। ਕੀ ਬਦਲਿਆ, ਕਿਉਂ, ਅਤੇ ਤੁਹਾਨੂੰ ਕੀ ਸੁਧਾਰ ਦੀ ਉਮੀਦ ਹੈ—ਇਹ ਸਭ ਰਿਕਾਰਡ ਕਰੋ। ਸਟੇਜਡ ਰੋਲਆਊਟ ਕਰੋ ਅਤੇ ਸੰਸਲਪ-ਤੁਲਨਾਤਮਕ ਅੰਕੜੇ ਲਵੋ ਤਾਂ ਜੋ ਤੁਸੀਂ ਸਾਰੇ ਯੂਜ਼ਰਾਂ ਲਈ ਬਦਲਾਅ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਪ੍ਰਭਾਵ ਸਾਬਿਤ ਕਰ ਸਕੋ।

ਨਵੇਂ ਹੋਣ 'ਤੇ, ਇੱਕ ਹਲਕਾ-ਫੁਲਕਾ ਵਰਕਫਲੋ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ: ਪ੍ਰਸਤਾਵ → ਆਫਲਾਈਨ ਮੁਲਾਂਕਣ → ਸੀਮਤ ਰੋਲਆਊਟ → ਫੁੱਲ ਰੋਲਆਊਟ।

ਲਾਂਚ ਬਾਅਦ ਸਮੀਖਿਆਵਾਂ: ਘਟਨਾਵਾਂ, ਲਾਗਤ, ਫੀਡਬੈਕ

ਨਿਰੰਤਰ ਰਿਵਿਊ ਚਲਾਓ ਜੋ ਤਿੰਨ ਸਿਗਨਲ ਮਿਲਾਕੇ ਚਲੇ: ਘਟਨਾਵਾਂ (ਗੁਣਵੱਤਾ ਜਾਂ ਆਊਟੇਜ), ਲਾਗਤ (API ਖਰਚ, ਕੰਪਿਊਟ, ਮਨੁੱਖੀ ਸਮੀਖਿਆ ਸਮਾਂ), ਅਤੇ ਯੂਜ਼ਰ ਫੀਡਬੈਕ (ਟਿਕਟ, ਰੇਟਿੰਗ, ਛੱਡਣ ਦਾ ਖਤਰਾ)। “ਅਨੁਭਵ ਦੇ ਆਧਾਰ 'ਤੇ ਠੀਕ ਕਰੋ” ਤੋਂ ਬਚੋ—ਹਰ ਪਾਇਆ ਗਿਆ ਨਤੀਜਾ ਇਕ ਮੈਟਰਿਕেল ਫਾਲੋਅਪ ਬਣਾਓ।

v1 → v2 ਰੋਡਮੈਪ ਬਣਾਓ

ਤੁਹਾਡਾ v2 ਯੋਜਨਾ ਵਿਹਾਰਿਕ ਅਪਗਰੇਡਾਂ 'ਤੇ ਧਿਆਨ ਦਿਓ: ਹੋਰ ਆਟੋਮੇਸ਼ਨ, ਵਧੀਆ ਟੈਸਟ ਕਵਰੇਜ, ਸਪੱਸ਼ਟ ਗਵਰਨੈਂਸ, ਅਤੇ ਬਿਹਤਰ ਮਾਨੀਟਰਨਗ/ਅਲਰਟਿੰਗ। ਉਸ ਕੰਮ ਨੂੰ ਪਹਿਲ ਦੇੋ ਜੋ ਦੁਹਰਾਈ ਜੋਖਮ ਨੂੰ ਘਟਾਉਂਦਾ ਹੈ ਅਤੇ ਸਮੇਂ ਦੇ ਨਾਲ ਸੁਧਾਰਾਂ ਨੂੰ ਤੇਜ਼ ਅਤੇ ਸੁਰੱਖਿਅਤ ਬਣਾਉਂਦਾ ਹੈ।

ਜੇ ਤੁਸੀਂ ਆਪਣੇ ਰੋਲਆਊਟ ਦੀਆਂ ਸਿੱਖਿਆਂ ਨੂੰ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ ਆਪਣੇ ਚੈੱਕਲਿਸਟ ਅਤੇ ਪੋਸਟਮਾਰਟਮ ਨੂੰ ਅੰਦਰੂਨੀ ਦਸਤਾਵੇਜ਼ਾਂ ਜਾਂ ਜਨਤਕ ਨੋਟਾਂ ਵਿੱਚ ਬਦਲਣ 'ਤੇ ਵਿਚਾਰ ਕਰੋ—ਕੁਝ ਪਲੇਟਫਾਰਮ (ਜਿਨ੍ਹਾਂ ਵਿੱਚ Koder.ai ਵੀ ਸ਼ਾਮਿਲ ਹੈ) ਪ੍ਰੋਗਰਾਮ ਦਿੰਦੇ ਹਨ ਜਿਥੇ ਟੀਮਾਂ ਸਮੱਗਰੀ ਬਣਾਉਣ ਜਾਂ ਦੂਜਿਆਂ ਨੂੰ ਰੈਫਰ ਕਰਨ 'ਤੇ ਕ੍ਰੈਡਿਟ ਕਮਾ ਸਕਦੀਆਂ ਹਨ, ਜੋ ਤੁਸੀਂ ਇਟਰੇਟ ਕਰਦਿਆਂ ਪ੍ਰਯੋਗਾਤਮਕ ਖਰਚਾ ਘਟਾਉਣ ਵਿੱਚ ਮਦਦ ਕਰ ਸਕਦੇ ਹਨ।