04 ਨਵੰ 2025·8 ਮਿੰਟ
ਬਦਲਾਅ ਲਈ AI-ਪਹਿਲਾਂ ਐਪ ਬਣਾਓ: ਪੂਰਨਤਾ ਤੋਂ ਵੱਧ ਤਰੱਕੀ
AI-ਪਹਿਲਾਂ ਉਤਪਾਦਾਂ ਲਈ ਇਕ ਵਰਤੋਂਯੋਗ ਮਨੋਭਾਵ ਸਿੱਖੋ: ਛੋਟੇ ਚੱਲਾਓ, ਨਤੀਜੇ ਮਾਪੋ, ਅਤੇ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਦੁਹਰਾਓ ਤਾਂ ਜੋ ਤੁਹਾਡੀ ਐਪ ਡਾਟਾ, ਉਪਭੋਗਤਿਆਂ, ਅਤੇ ਮਾਡਲਾਂ ਦੇ ਬਦਲਣ ਨਾਲ ਬਿਹਤਰ ਹੁੰਦੀ ਰਹੇ।
AI-ਪਹਿਲਾਂ ਉਤਪਾਦਾਂ ਲਈ ਇਕ ਵਰਤੋਂਯੋਗ ਮਨੋਭਾਵ ਸਿੱਖੋ: ਛੋਟੇ ਚੱਲਾਓ, ਨਤੀਜੇ ਮਾਪੋ, ਅਤੇ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਦੁਹਰਾਓ ਤਾਂ ਜੋ ਤੁਹਾਡੀ ਐਪ ਡਾਟਾ, ਉਪਭੋਗਤਿਆਂ, ਅਤੇ ਮਾਡਲਾਂ ਦੇ ਬਦਲਣ ਨਾਲ ਬਿਹਤਰ ਹੁੰਦੀ ਰਹੇ।
"AI-ਪਹਿਲਾਂ" ਦਾ ਮਤਲਬ ਇਹ ਨਹੀਂ ਕਿ "ਅਸੀਂ ਇੱਕ ਚੈਟਬੋਟ ਜੋੜ ਦਿੱਤਾ।" ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਉਤਪਾਦ ਇਸ ਤਰੀਕੇ ਨਾਲ ਡਿਜ਼ਾਈਨ ਕੀਤਾ ਗਿਆ ਹੈ ਕਿ ਮਸ਼ੀਨ ਲਰਨਿੰਗ ਮੂਲ ਸਮਰੱਥਾ ਹੋਵੇ—ਜਿਵੇਂ ਖੋਜ, ਸਿਫਾਰਸ਼ਾਂ, ਸੰਖੇਪ, ਰਾਊਟਿੰਗ, ਜਾਂ ਫੈਸਲਾ-ਸਹਾਇਤਾ—ਅਤੇ ਬਾਕੀ ਅਨੁਭਵ (UI, ਵਰਕਫਲੋ, ਡਾਟਾ, ਅਤੇ ਓਪਰੇਸ਼ਨ) ਇਸ ਸਮਰੱਥਾ ਨੂੰ ਭਰੋਸੇਯੋਗ ਅਤੇ ਉਪਯੋਗੀ ਬਣਾਉਣ ਲਈ ਬਣਾਇਆ ਗਿਆ ਹੋਵੇ।
ਇੱਕ AI-ਪਹਿਲਾਂ ਐਪਲੀਕੇਸ਼ਨ ਮਾਡਲ ਨੂੰ ਉਤਪਾਦ ਦੇ ਇੰਜਣ ਦਾ ਹਿੱਸਾ ਮੰਨਦੀ ਹੈ, ਨਾ ਕਿ ਸਿਰਫ਼ ਇਕ ਸਜਾਵਟੀ ਫੀਚਰ। ਟੀਮ ਇਹ ਮੰਨਦੀ ਹੈ ਕਿ ਨਤੀਜੇ ਤਬਦੀਲ ਹੋ ਸਕਦੇ ਹਨ, ਇਨਪੁਟ ਗੁੰਝਲਦਾਰ ਹੋਣਗੇ, ਅਤੇ ਗੁਣਵੱਤਾ ਇੱਕ ਇਕੱਲੀ "ਪੂਰਨ" ਰਿਲੀਜ਼ ਨਾਲ ਨਹੀਂ, ਬਲਕਿ ਦੁਹਰਾਅ ਰਾਹੀਂ ਸੁਧਰੇਗੀ।
ਇਹ ਨਹੀਂ ਹੈ:
ਰਵਾਇਤੀ ਸਾਫਟਵੇਅਰ ਅੱਗੇ ਵਰਣਨ ਸਹੀ ਕਰਨ ਲਈ ਇਨਾਮ ਦਿੰਦਾ ਹੈ। AI ਉਤਪਾਦ ਤੇਜ਼ੀ ਨਾਲ ਸਿੱਖਣ ਲਈ ਇਨਾਮ ਦਿੰਦੇ ਹਨ: ਉਪਭੋਗਤਾ ਅਸਲ ਵਿੱਚ ਕੀ ਮੰਗਦੇ ਹਨ, ਮਾਡਲ ਕਿੱਥੇ ਫੇਲ ਹੁੰਦਾ ਹੈ, ਕਿਹੜਾ ਡਾਟਾ ਗੁੰਮ ਹੈ, ਅਤੇ ਤੁਹਾਡੇ ਸੰਦਰਭ ਵਿੱਚ "ਚੰਗਾ" ਕੀ ਹੈ।
ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਤੁਸੀਂ ਪਹਿਲੇ ਦਿਨ ਤੋਂ ਬਦਲਾਅ ਦੀ ਯੋਜਨਾ ਬਣਾਉਂਦੇ ਹੋ—ਕਿਉਂਕਿ ਬਦਲਾਅ ਸਧਾਰਨ ਹੈ। ਮਾਡਲ ਅਪਡੇਟ ਹੁੰਦੇ ਹਨ, ਪ੍ਰੋਵਾਈਡਰਾਂ ਦੇ ਵਰਤਾਰਿਆਂ ਵਿੱਚ ਬਦਲਾਅ ਹੁੰਦਾ ਹੈ, ਨਵਾਂ ਡਾਟਾ ਆਉਂਦਾ ਹੈ, ਅਤੇ ਉਪਭੋਗਤਾ ਦੀਆਂ ਉਮੀਦਾਂ ਵਿਕਸਿਤ ਹੁੰਦੀਆਂ ਹਨ। ਜੇਕਰ ਤੁਸੀਂ ਕਦੇ ਵੀ ਮਾਡਲ ਨਹੀਂ ਬਦਲਦੇ, ਫਿਰ ਵੀ ਮਾਡਲ ਜਿਸ ਦੁਨੀਆ ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ ਉਹ ਹਿਲਦਾ ਰਹੇਗਾ।
ਇਸ ਗਾਈਡ ਦੇ ਬਾਕੀ ਹਿੱਸੇ AI-ਪਹਿਲਾਂ ਅਪ੍ਰੋਚ ਨੂੰ ਪ੍ਰਯੋਗਿਕ, ਦੁਹਰਾਅ ਯੋਗ ਕਦਮਾਂ ਵਿੱਚ ਵੰਡਦਾ ਹੈ: ਨਤੀਜੇ ਪਰਿਭਾਸ਼ਿਤ ਕਰਨ, ਸਭ ਤੋਂ ਜ਼ਿਆਦਾ ਸਿਖਾਉਣ ਵਾਲਾ ਛੋਟਾ MVP ਸ਼ਿਪ ਕਰਨ, AI ਘਟਕਾਂ ਨੂੰ ਬਦਲੇਯੋਗ ਰੱਖਣ, ਅਪਟੀਮਾਈਜ਼ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਮੁਲਾਂਕਣ ਸੈਟਅਪ ਕਰਨ, ਡ੍ਰਿਫਟ ਦੀ ਨਿਗਰਾਨੀ ਕਰਨ, ਸੁਰੱਖਿਆ ਗਾਰਡਰੇਲ ਅਤੇ ਮਨੁੱਖੀ ਸਮੀਖਿਆ ਜੋੜਨ, ਅਤੇ ਵਰਜਨਿੰਗ, ਐਕਸਪੈਰੀਮੈਂਟਸ, ਰੋਲਬੈਕ, ਲਾਗਤ ਅਤੇ ਮਲਕੀਅਤ ਨੂੰ ਸੰਭਾਲਣ।
ਮਕਸਦ ਪੂਰਨਤਾ ਨਹੀਂ — ਇਹ ਇਕ ਐਸਾ ਉਤਪਾਦ ਹੈ ਜੋ ਨਿਯਤ ਤੌਰ 'ਤੇ ਬਿਹਤਰ ਹੁੰਦਾ ਹੈ—ਬਿਨਾ ਹਰ ਵਾਰੀ ਮਾਡਲ ਬਦਲਣ 'ਤੇ ਤੂਟਣ ਦੇ।
ਰਵਾਇਤੀ ਸਾਫਟਵੇਅਰ ਪੂਰਨਤਾ ਨੂੰ ਇਨਾਮ ਦਿੰਦਾ ਹੈ: ਤੁਸੀਂ ਫੀਚਰ ਦਾ ਨਿਰਧਾਰਨ ਕਰੋ, ਨਿਰਧਾਰਤ ਕੋਡ ਲਿਖੋ, ਅਤੇ ਜੇ ਇਨਪੁਟ ਨਹੀਂ ਬਦਲੇ ਤਾਂ ਆਉਟਪੁੱਟ ਵੀ ਨਹੀਂ ਬਦਲੇਗੀ। AI ਉਤਪਾਦ ਇਸ ਤਰੀਕੇ ਨਾਲ ਕੰਮ ਨਹੀਂ ਕਰਦੇ। ਇੱਕੋ ਐਪ ਕੋਡ ਹੋਣ ਦੇ ਬਾਵਜੂਦ, AI ਫੀਚਰ ਦੀ ਵਰਤਾਰਾ ਵੱਖ-ਵੱਖ ਹਿੱਸਿਆਂ ਦੇ ਕਾਰਨ ਹਿਲ ਸਕਦੀ ਹੈ।
ਇੱਕ AI ਫੀਚਰ ਇਕ ਚੇਨ ਹੈ, ਅਤੇ ਕਿਸੇ ਵੀ ਲਿੰਕ ਦਾ ਬਦਲਨਾ ਨਤੀਜੇ بدل ਸਕਦਾ ਹੈ:
ਇੱਕ snapshot ਵਿੱਚ ਪੂਰਨਤਾ ਸਾਰਿਆਂ ਨਾਲ ਰਾਬਤਾ ਠਹਿਰਾ ਨਹੀਂ ਰਹਿੰਦੀ।
AI ਫੀਚਰ ਡ੍ਰਿਫਟ ਕਰ ਸਕਦੇ ਹਨ ਕਿਉਂਕਿ ਉਹਨਾਂ ਦੀਆਂ ਨਿਰਭਰਤਾਵਾਂ ਵਿਕਸਿਤ ਹੁੰਦੀਆਂ ਹਨ। ਇੱਕ ਵੇਂਡਰ ਮਾਡਲ ਅਪਡੇਟ ਕਰ ਸਕਦਾ ਹੈ, ਤੁਹਾਡਾ ਰਿਟਰੀਵਲ ਇੰਡੈਕਸ ਤਾਜ਼ਾ ਹੋ ਸਕਦਾ ਹੈ, ਜਾਂ ਅਸਲ ਉਪਭੋਗਤਾ ਸਵਾਲ ਉਤਪਾਦ ਦੀ ਵਾਧੀ ਦੇ ਨਾਲ ਬਦਲ ਸਕਦੇ ਹਨ। ਨਤੀਜਾ: ਕੱਲ੍ਹ ਦੇ ਵਧੀਆ ਉੱਤਰ ਅਸਮੰਜਸਤ, ਜ਼ਿਆਦਾ ਚਤੁਰ, ਜਾਂ ਸੁੱਖਣੇ ਤਰੀਕੇ ਨਾਲ ਗਲਤ ਹੋ ਸਕਦੇ ਹਨ—ਬਿਨਾ ਕਿਸੇ ਐਪ ਕੋਡ ਦੀ ਇੱਕ ਵੀ ਲਾਈਨ ਬਦਲੇ।
ਸ਼ੁਰੂ 'ਚ ਪ੍ਰਾਂਪਟਾਂ ਨੂੰ ਫਾਈਨ-ਟਿਊਨ ਕਰਨ, ਸਭ ਤੋਂ ਵਧੀਆ ਮਾਡਲ ਚੁਣਨ, ਜਾਂ ਹਰ ਏਜ ਕੇਸ ਨੂੰ ਸਹੀ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਨ ਨਾਲ ਦੋ ਮੁੱਦੇ ਬਣਦੇ ਹਨ: ਧੀਮੀ ਸ਼ਿਪਿੰਗ ਅਤੇ ਬੁੱੱਲੇ ਹੋਏ ਅਨੁਮਾਨ। ਤੁਸੀਂ ਹਫ਼ਤਿਆਂ ਨੂੰ ਲੈਬ ਵਿੱਚ ਪਾਲਿਸ਼ ਕਰਨ ਵਿੱਚ ਗੁਜ਼ਾਰਦੇ ਹੋ ਜਦੋਂ ਉਪਭੋਗਤਾ ਅਤੇ ਸੀਮਾਵਾਂ ਅੱਗੇ ਵਧਦੀਆਂ ਹਨ। ਜਦੋਂ ਤੁਸੀਂ ਅੰਤ ਵਿੱਚ ਰਿਲੀਜ਼ ਕਰਦੇ ਹੋ, ਤਤਕਾਲ ਸਿੱਖਿਆ ਦਿੰਦਾ ਹੈ ਕਿ ਅਸਲ ਫੇਲਿਆਂ ਦਾ ਕਾਰਨ ਹੋਰ ਹੀ ਸਥਾਨਾਂ ਤੇ ਸੀ (ਗੁੰਮ ਡਾਟਾ, ਅਸਪਸ਼ਟ UX, ਗਲਤ ਸਫਲਤਾ ਮਿਪਦੰਡ)।
ਇੱਕ ਪੂਰਨ AI ਫੀਚਰ ਦਾ ਪਿੱਛਾ ਕਰਨ ਦੀ ਬਜਾਏ, ਇੱਕ ਐਸੇ ਸਿਸਟਮ ਦਾ ਲਕਸ਼ ਬਣਾਓ ਜੋ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਬਦਲ ਸਕੇ: ਸਪੱਸ਼ਟ ਨਤੀਜੇ, ਮਾਪਯੋਗ ਗੁਣਵੱਤਾ, ਨਿਯੰਤਰਿਤ ਅੱਪਡੇਟ, ਤੇਜ਼ ਫੀਡਬੈਕ ਲੂਪ—ਤਾਂ ਜੋ ਸੁਧਾਰ ਉਪਭੋਗਤਿਆਂ ਨੂੰ ਹੈਰਾਨ ਨਾ ਕਰਨ ਤੇ ਭਰੋਸਾ ਘਟਾਉਣ ਨਾ ਪਏ।
AI ਉਤਪਾਦਾਂ ਦਾ ਰੋਡਮੇਪ ਗਲਤ ਹੋ ਜਾਂਦਾ ਹੈ ਜਦੋਂ ਸ਼ੁਰੂ ਵਿੱਚ ਪੁੱਛਿਆ ਜਾਂਦਾ ਹੈ "ਕਿਹੜਾ ਮਾਡਲ ਵਰਤਾਂ?" ਨਕਲ ਕੀਤਾ ਜਾਵੇ ਇਲਾਵਾ ਇਹ ਪੁੱਛੋ: "ਉਪਭੋਗਤਾ ਅੰਤ ਵਿੱਚ ਕੀ ਕਰ ਸਕੇਗਾ?" ਮਾਡਲ ਸਮਰੱਥੀਆਂ ਤੇਜ਼ੀ ਨਾਲ ਬਦਲਦੀਆਂ ਹਨ; ਨਤੀਜੇ ਉਹ ਹਨ ਜਿਨ੍ਹਾਂ ਲਈ ਤੁਸੀਂ ਗਾਹਕਾਂ ਤੋਂ ਪੈਸਾ ਲੈਂਦੇ ਹੋ।
ਉਪਭੋਗਤਾ ਨਤੀਜੇ ਅਤੇ ਤੁਸੀਂ ਇਸਨੂੰ ਕਿਵੇਂ ਪਛਾਣੋਗੇ ਉਸਨੂੰ ਵਰਣਨ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ। ਇਹ ਨਾਪਣਯੋਗ ਰੱਖੋ, ਭਾਵੇਂ ਇਹ ਪੂਰੀ ਤਰ੍ਹਾਂ ਦੁਰੁਸਤ ਨਾ ਹੋਵੇ। ਉਦਾਹਰਣ: "ਸਪੋਰਟ ਏਜੰਟ ਪਹਿਲੀ ਜਵਾਬ 'ਤੇ ਜ਼ਿਆਦਾ ਟਿਕਟ ਹੱਲ ਕਰਦੇ ਹਨ" ਇਹ ਉਸੇ ਤਰ੍ਹਾਂ ਨਹੀਂ ਕਿ "ਮਾਡਲ ਵਧੀਆ ਜਵਾਬ ਬਣਾਉਂਦਾ ਹੈ"।
ਇੱਕ ਸਹਾਇਕ ਹੋਕ ਇੱਕ ਸਧਾਰਨ job story ਲਿਖਣੀ ਹੈ:
ਇਹ ਫਾਰਮੈਟ ਸੰਦਰਭ, ਕਾਰਵਾਈ, ਅਤੇ ਅਸਲ ਫਾਇਦੇ ਲਈ ਸਪਸ਼ਟਤਾ ਲਿਆਉਂਦਾ ਹੈ।
ਪਾਬੰਦੀਆਂ ਡਿਜ਼ਾਈਨ ਨੂੰ ਮਾਪ ਦਿੰਦੀਆਂ ਹਨ। ਉਨ੍ਹਾਂ ਨੂੰ ਪਹਿਲਾਂ ਹੀ ਲਿਖੋ ਅਤੇ ਉਨ੍ਹਾਂ ਨੂੰ ਉਤਪਾਦ ਦੀਆਂ ਲੋੜਾਂ ਵਾਂਗ ਮਨੋ:
ਇਹ ਫੈਸਲੇ ਇਹ ਨਿਰਧਾਰਤ ਕਰਨਗੇ ਕਿ ਤੁਹਾਨੂੰ ਰੀਟਰੀਵਲ, ਨਿਯਮ, ਮਨੁੱਖੀ ਸਮੀਖਿਆ, ਜਾਂ ਇਕ ਸਾਦਾ ਵਰਕਫਲੋ ਦੀ ਲੋੜ ਹੈ—ਨਾ ਕਿ ਕੇਵਲ "ਵੱਡੇ ਮਾਡਲ" ਦੀ।
v1 ਨੂੰ ਖਾਸ ਤੌਰ 'ਤੇ ਤੰਗ ਰੱਖੋ। ਦਿਨ ਇਕ ਤੇ ਸਹੀ ਹੋਣ ਵਾਲੀਆਂ ਚੀਜ਼ਾਂ ਨਿਰਧਾਰਤ ਕਰੋ (ਉਦਾਹਰਣ: "ਕਦੇ ਵੀ ਨੀਤੀ ਹਵਾਲੇ ਨਈ ਬਣਾਏ","ਟਾਪ 3 ਟਿਕਟ ਸ਼੍ਰੇਣੀਆਂ ਲਈ ਕੰਮ ਕਰਦਾ ਹੈ") ਅਤੇ ਕਿਹੜੀਆਂ ਗੱਲਾਂ ਬਾਅਦ ਵਿੱਚ ਕੀਤੀਆਂ ਜਾ ਸਕਦੀਆਂ ਹਨ (ਬਹੁ-ਭਾਸ਼ਾ, ਵਿਅਕਤੀਗਤਕরণ, ਅਡਵਾਂਸਡ ਟੋਨ ਕੰਟਰੋਲ)।
ਜੇ ਤੁਸੀਂ v1 ਦਾ ਵਰਣਨ ਮੂੜਿ ਕੇ ਇੱਕ ਮਾਡਲ ਨਾਮ ਲਈ ਬਿਨਾਂ ਨਹੀਂ ਕਰ ਸਕਦੇ, ਤਾਂ ਤੁਸੀਂ ਅਜੇ ਵੀ ਸਮਰੱਥਾਵਾਂ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਡਿਜ਼ਾਈਨ ਕਰ ਰਹੇ ਹੋ।
AI MVP "ਅੰਤਿਮ ਉਤਪਾਦ ਦਾ ਛੋਟਾ ਸੰਸਕਾਰ" ਨਹੀਂ ਹੁੰਦਾ। ਇਹ ਇੱਕ ਸਿੱਖਣ ਵਾਲਾ ਉਪਕਰਨ ਹੈ: ਸਭ ਤੋਂ ਛੋਟਾ ਹਿੱਸਾ ਜੋ ਅਸਲ ਮੁੱਲ ਪੈਦਾ ਕਰਦਾ ਹੈ ਅਤੇ ਜਿਸਨੂੰ ਤੁਸੀਂ ਅਸਲੀ ਉਪਭੋਗਤਿਆਂ ਕੋਲ ਭੇਜ ਸਕਦੇ ਹੋ ਤਾਂ ਕਿ ਤੁਸੀਂ ਦੇਖ ਸਕੋ ਮਾਡਲ ਕਿੱਥੇ ਮਦਦ ਕਰਦਾ ਅਤੇ ਕਿੱਥੇ ਫੇਲ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਅਸਲ ਵਿੱਚ ਕੀ ਬਣਾਉਣਾ ਜ਼ਰੂਰੀ ਹੈ।
ਉਪਭੋਗਤਾ ਦੀ ਇੱਕ ਨੌਕਰੀ ਚੁਣੋ ਜੋ ਪਹਿਲਾਂ ਹੀ ਉਹ ਕਰਵਾਉਂਦੇ ਹਨ ਅਤੇ ਇਸ ਨੂੰ ਕੜੀ ਤਰ੍ਹਾਂ ਸੀਮਿਤ ਕਰੋ। ਇਕ ਚੰਗਾ v1 ਇੰਨਾ ਵਿਸ਼ੇਸ਼ ਹੋਵੇ ਕਿ ਤੁਸੀਂ ਸਫਲਤਾ ਨਿਰਧਾਰਤ ਕਰ ਸਕੋ, ਆਉਟਪੁੱਟ ਤੇਜ਼ੀ ਨਾਲ ਸਮੀਖਿਆ ਕੀਤੀ ਜਾ ਸਕੇ, ਅਤੇ ਬਿਨਾ ਸਾਰੇ ਡਿਜ਼ਾਈਨ ਨੂੰ ਦੁਬਾਰਾ ਬਣਾਏ ਮੁੱਦਿਆਂ ਨੂੰ ਠੀਕ ਕੀਤਾ ਜਾ ਸਕੇ।
ਸੰਕੁਚਿਤ ਸਕੋਪ ਉਦਾਹਰਣ:
ਇਨਪੁਟ ਪੇਸ਼ਗਾਹੀਯੋਗ ਰੱਖੋ, ਆਉਟਪੁੱਟ ਫਾਰਮੈਟ ਸੀਮਤ ਕਰੋ, ਅਤੇ ਡਿਫੌਲਟ ਪਾਥ ਸਾਦਾ ਰੱਖੋ।
v1 ਲਈ, ਉਹ ਨਿਯੂਨਤਮ ਫਲੋਜ਼ ਜਿਨ੍ਹਾਂ ਨਾਲ ਫੀਚਰ ਉਪਯੋਗਯੋਗ ਅਤੇ ਸੁਰੱਖਿਅਤ ਬਣਦਾ ਹੈ 'ਤੇ ਧਿਆਨ ਦਿਓ:
ਇਹ ਵੰਡ ਤੁਹਾਡੇ ਟਾਈਮਲਾਈਨ ਨੂੰ ਰੱਖਦੀ ਹੈ ਅਤੇ ਇਹ ਵੀ ਸਚਾ ਰੱਖਦੀ ਹੈ ਕਿ ਤੁਸੀਂ ਕੀ ਸਿੱਖਣਾ ਚਾਹੁੰਦੇ ਹੋ।
ਲਾਂਚ ਨੂੰ ਸੰਭਾਲੇ ਹੋਏ ਪ੍ਰਕਿਰਿਆ ਵਜੋਂ ਲਵੋ:
ਹਰ ਪੜਾਅ ਲਈ "ਰੁਕੋ" ਮਾਪਦੰਡ ਰੱਖੋ (ਅਣਸਵੀਕਾਰਯੋਗ ਗਲਤੀਆਂ, ਲਾਗਤ ਵਿੱਚ ਉਛਾਲ, ਜਾਂ ਉਪਭੋਗਤਾ ਗੁੰਝਲਦਾਰੀ)।
MVP ਨੂੰ ਇੱਕ ਨਿਸ਼ਚਿਤ ਸਿੱਖਣ ਅਵਧੀ ਦਿਓ—ਆਮ ਤੌਰ 'ਤੇ 2–4 ਹਫ਼ਤੇ—ਅਤੇ ਉਹਨਾਂ ਕੁਝ ਮੈਟਰਿਕਸ ਨੂੰ ਨਿਰਧਾਰਤ ਕਰੋ ਜੋ ਅਗਲੀ ਦੁਹਰਾਈ ਫੈਸਲਾ ਕਰਨਗੇ। ਨਤੀਜਾ-ਅਧਾਰਤ ਰੱਖੋ:
ਜੇ MVP ਤੁਹਾਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਸਿੱਖਾਉਣ ਵਿੱਚ ਅਸਮਰਥ ਹੈ, ਤਾਂ ਇਹ ਸੰਭਵਤ: ਬਹੁਤ ਵੱਡਾ ਹੈ।
AI ਉਤਪਾਦ ਮਾਡਲ ਦੀ ਵਜ੍ਹਾ ਕਰਕੇ ਬਦਲਦੇ ਹਨ। ਜੇ ਤੁਹਾਡੀ ਐਪ "ਮਾਡਲ" ਨੂੰ ਇਕ ਇਕਦਮ ਬੇਕਡ-ਇਨ ਚੋਣ ਮੰਨਦੀ ਹੈ, ਤਾਂ ਹਰੇਕ ਅੱਪਗਰੇਡ ਇੱਕ ਖਤਰਨਾਕ ਰੀਰਾਈਟ ਬਣ ਜਾਂਦਾ ਹੈ। ਬਦਲਣਯੋਗਤਾ ਇਸਦਾ ਦਵਾਈ ਹੈ: ਆਪਣੇ ਸਿਸਟਮ ਨੂੰ ਇਸ ਤਰ੍ਹਾਂ ਡਿਜ਼ਾਈਨ ਕਰੋ ਕਿ ਪ੍ਰਾਂਪਟ, ਪ੍ਰੋਵਾਈਡਰ, ਅਤੇ ਪੂਰੇ ਵਰਕਫਲੋ ਨੂੰ ਬਿਨਾਂ ਬਾਕੀ ਉਤਪਾਦ ਨੂੰ ਤੋੜੇ ਬਦਲਾ ਜਾ ਸਕੇ।
ਵਿਆਵਹਾਰਿਕ ਆਰਕੀਟੈਕਚਰ ਚਾਰ ਪਰਤਾਂ ਵਿੱਚ ਵੇਅਰ ਕਰਦਾ ਹੈ:
ਜਦੋਂ ਇਹ ਪਰਤਾਂ ਸਾਫ਼ ਹੋਣ, ਤੁਸੀਂ UI ਬਦਲੇ ਬਿਨਾਂ ਮਾਡਲ ਪ੍ਰੋਵਾਈਡਰ ਬਦਲ ਸਕਦੇ ਹੋ, ਅਤੇ ਤੁਸੀਂ ਆਰਕੈਸਟਰੈਸ਼ਨ ਨੂੰ ਬਦਲ ਸਕਦੇ ਹੋ ਬਿਨਾਂ ਡਾਟਾ ਐਕਸੈਸ ਨੂੰ ਦੁਬਾਰਾ ਲਿਖੇ।
ਵੇਂਡਰ-ਨਿਰਪેੱਖ ਕਾਲਾਂ ਨੂੰ ਕੋਡਬੇਸ ਵਿੱਚ ਫੈਲਣ ਤੋਂ ਰੋਕੋ। ਇਸਦੀ ਥਾਂ, ਇੱਕ "model adapter" ਇੰਟਰਫੇਸ ਬਣਾਓ ਅਤੇ ਪ੍ਰੋਵਾਈਡਰ ਵਿਸ਼ੇਸ਼ਤਾ ਨੂੰ ਇਸਦੇ ਪਿੱਛੇ ਰੱਖੋ। ਚਾਹੇ ਤੁਸੀਂ ਵੇਂਡਰ ਨਾ ਵੀ ਬਦਲੋ, ਇਹ ਮਾਡਲਾਂ ਨੂੰ ਅਪਗਰੇਡ ਕਰਨ, ਸਸਤਾ ਵਿਕਲਪ ਸ਼ਾਮਿਲ ਕਰਨ ਜਾਂ ਟਾਸਕ ਦੇ ਆਧਾਰ ਤੇ ਰੂਟਿੰਗ ਕਰਨ ਵਿੱਚ ਆਸਾਨੀ ਕਰਦਾ ਹੈ।
// Example: stable interface for any provider/model
export interface TextModel {
generate(input: {
system: string;
user: string;
temperature: number;
maxTokens: number;
}): Promise<{ text: string; usage?: { inputTokens: number; outputTokens: number } }>;
}
(ਉਪਰੋਕਤ ਕੋਡ ਫੈਂਸਡ ਬਲਾਕ ਵਿੱਚ ਜਿਵੇਂ ਹੈ ਉਸੇ ਤਰ੍ਹਾਂ ਰੱਖੋ—ਇਸ ਨੂੰ ਅਨੁਵਾਦ ਨਹੀ ਕੀਤਾ ਗਿਆ)।
ਬਹੁਤ ਸਾਰੇ "ਦੋਹਰਾਅ"Deployments ਬਿਨਾਂ ਡਿਪਲੋਇਮੈਂਟ ਦੇ ਨਾਲ ਹੀ ਹੋ ਸਕਦੇ ਹਨ। ਪ੍ਰਾਂਪਟ/ਟੈਮਪਲੇਟ, ਸੁਰੱਖਿਆ ਨਿਯਮ, ਥ੍ਰੈਸ਼ਹੋਲਡ, ਅਤੇ ਰੂਟਿੰਗ ਫੈਸਲੇ ਕਨਫਿਗਰੇਸ਼ਨ ਵਿੱਚ ਰੱਖੋ (ਵਰਜਨਿੰਗ ਸਮੇਤ)। ਇਹ ਪੈਰੋਡਕ ਟੀਮਾਂ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਬਿਹਹੇਵਿਅਰ ਨੂੰ ਅਡਜਸਟ ਕਰਨ ਦਿੰਦਾ ਹੈ ਜਦਕਿ ਇੰਜ਼ੀਨੀਅਰਿੰਗ ਢਾਂਚਾਗਤ ਸੁਧਾਰਾਂ 'ਤੇ ਧਿਆਨ ਕਰਦੀ ਹੈ।
ਬਾਊਂਡਰੀਜ਼ ਸਪਸ਼ਟ ਬਣਾਓ: ਮਾਡਲ ਨੂੰ ਕੀ ਇਨਪੁੱਟ ਮਿਲਦਾ ਹੈ, ਕੀ ਆਉਟਪੁੱਟ ਦੀ ਆਗਿਆ ਹੈ, ਅਤੇ ਅਸਫਲਤਾ 'ਤੇ ਕੀ ਹੁੰਦਾ ਹੈ। ਜੇ ਤੁਸੀਂ ਆਉਟਪੁੱਟ ਫਾਰਮੈਟ (ਉਦਾਹਰਣ: JSON ਸਕੀਮਾ) ਨੂੰ ਸਟੈਂਡਰਡ ਕਰੋ ਅਤੇ ਬਾਊਂਡਰੀ 'ਤੇ ਵੈਧਤਾ ਕਰਨ, ਤਾਂ ਤੁਸੀਂ ਪ੍ਰਾਂਪਟ/ਮਾਡਲ ਬਦਲਦਿਆਂ ਘੱਟ ਖਤਰੇ ਨਾਲ ਅਤੇ ਗੁਣਵੱਤਾ ਘਟਣ 'ਤੇ ਤੇਜ਼ੀ ਨਾਲ ਰੋਲਬੈਕ ਕਰ ਸਕਦੇ ਹੋ।
ਜੇ ਤੁਸੀਂ Koder.ai ਵਰਗੇ ਪਲੇਟਫਾਰਮ ਨੂੰ ਵਰਤ ਰਹੇ ਹੋ ਤਾਂ MVP ਖੜਾ ਕਰਨ ਲਈ, ਇਸਨੂੰ ਇਕੋ ਤਰੀਕੇ ਨਾਲ ਟਰੀਟ ਕਰੋ: ਮਾਡਲ ਪ੍ਰਾਂਪਟ, ਆਰਕੈਸਟਰੈਸ਼ਨ ਕਦਮ, ਅਤੇ ਇੰਟਿਗ੍ਰੇਸ਼ਨ ਬਾਊਂਡਰੀ ਨੂੰ ਸਪਸ਼ਟ ਰੱਖੋ ਤਾਂ ਜੋ ਤੁਸੀਂ ਘਟਕਾਂ ਨੂੰ ਬਦਲ ਸਕੋ ਬਿਨਾਂ ਪੂਰੇ ਐਪ ਨੂੰ ਦੁਬਾਰਾ ਲਿਖੇ। Koder.ai ਦੀਆਂ snapshots ਅਤੇ rollback ਵਰਕਫਲੋ "ਸੇਫ ਸਵੈਪ ਪੁਆਇੰਟ" ਵਿਚਾਰ ਨਾਲ ਚੰਗੀ ਤਰ੍ਹਾਂ ਮੈਚ ਕਰਦੀਆਂ ਹਨ—ਖ਼ਾਸ ਕਰਕੇ ਜਦੋਂ ਤੁਸੀਂ ਤੇਜ਼ੀ ਨਾਲ ਦੁਹਰਾਅ ਕਰ ਰਹੇ ਹੋ ਅਤੇ ਪ੍ਰਾਂਪਟ ਜਾਂ ਮਾਡਲ ਬਦਲਣ ਤੋਂ ਬਾਅਦ ਵਾਪਸੀ ਦਾ ਸਾਫ਼ ਤਰੀਕਾ ਚਾਹੁੰਦੇ ਹੋ।
ਇੱਕ AI ਫੀਚਰ ਜਿਹੜਾ "ਮੇਰੇ ਪ੍ਰਾਂਪਟ ਤੇ ਚੰਗਾ ਕੰਮ ਕਰਦਾ ਹੈ" ਨੂੰ ਸ਼ਿਪ ਕਰਨਾ, ਉੱਚ ਗੁਣਵੱਤਾ ਸ਼ਿਪ ਕਰਨ ਦੇ ਬਰਾਬਰ ਨਹੀਂ ਹੈ। ਡੈਮੋ ਪ੍ਰਾਂਪਟ ਹਥ-ਚੁਣਿਆ ਹੁੰਦਾ ਹੈ, ਇਨਪੁਟ ਸਾਫ਼ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਉਮੀਦ ਕੀਤਾ ਗਿਆ ਉੱਤਰ ਆਪ ਦੇ ਮਨ ਵਿੱਚ ਹੁੰਦਾ ਹੈ। ਅਸਲ ਉਪਭੋਗਤਾ ਗੁੰਝਲਦਾਰ ਸੰਦਰਭ, ਗੁੰਮ ਵੇਰਵੇ, ਵਿਰੋਧੀ ਲਕੜੀ, ਅਤੇ ਸਮਾਂ ਦਬਾਅ ਨਾਲ ਆਉਂਦੇ ਹਨ।
ਮੁਲਾਂਕਣ ਉਹ ਤਰੀਕਾ ਹੈ ਜੋ ਤੁਹਾਡੀ ਅਨੁਮਾਨ ਨੂੰ ਸਬੂਤ ਵਿੱਚ ਬਦਲਦਾ ਹੈ—ਅਪਟੀਮਾਈਜ਼ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ।
ਸਭ ਤੋਂ ਪਹਿਲਾਂ ਲਿਖੋ ਕਿ ਇਸ ਫੀਚਰ ਲਈ "ਚੰਗਾ" ਕੀ ਮਤਲਬ ਹੈ। ਕੀ ਲਕਸ਼ ਹੈ ਘੱਟ ਸਹੀ ਟਿਕਟਾਂ, ਤੇਜ਼ ਰੀਸਰਚ, ਬਿਹਤਰ ਦਸਤਾਵੇਜ਼ ਡਰਾਫਟ, ਘੱਟ ਗਲਤੀਆਂ, ਜਾਂ ਜ਼ਿਆਦਾ ਕਨਵਰਜ਼ਨ? ਜੇ ਤੁਸੀਂ ਨਤੀਜੇ ਵੇਰਵਾ ਨਹੀਂ ਕਰ ਸਕਦੇ, ਤਾਂ ਤੁਸੀਂ ਮਾਡਲ ਦੇ ਆਉਟਪੁੱਟ ਸਟਾਈਲ ਨੂੰ ਹੀ ਅਪਟੀਮਾਈਜ਼ ਕਰ ਰਹੇ ਹੋਵੋਗੇ, ਨਾਂ ਕਿ ਉਤਪਾਦ ਨਤੀਜੇ ਨੂੰ।
20–50 ਅਸਲ ਉਦਾਹਰਣਾਂ ਵਾਲਾ ਹਲਕਾ ਐਵਲ ਸੈੱਟ ਬਣਾਓ। ਮਿਲਾਇਆ ਹੋਇਆ:
ਹਰ ਉਦਾਹਰਣ ਵਿੱਚ ਇਨਪੁਟ, ਸਿਸਟਮ ਕੋਲ ਕਿਹਾ ਸੰਦਰਭ ਹੈ, ਅਤੇ ਇਕ ਸਧਾਰਨ ਉਮੀਦ ਨਤੀਜਾ ਸ਼ਾਮਲ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ (ਜ਼ਰੂਰਤ ਨਹੀਂ ਕਿ ਹਰ ਵਾਰੀ ਇੱਕ ਪੂਰਨ "ਸੋਨੇ ਦਾ ਜਵਾਬ" ਹੋਵੇ—ਕਈ ਵਾਰ ਇਹ "ਸਪਸ਼ਟੀਕਰਨ ਪ੍ਰਸ਼ਨ ਪੁੱਛੋ" ਜਾਂ "ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਇਨਕਾਰ ਕਰੋ" ਵੀ ਹੋ ਸਕਦਾ ਹੈ)।
ਉਹ ਮੈਟਰਿਕਸ ਚੁਣੋ ਜੋ ਤੁਹਾਡੇ ਉਪਭੋਗਤਿਆਂ ਲਈ ਕੀਮਤੀ ਹਨ:
ਪ.proxy ਮੈਟਰਿਕਸ ਤੋਂ ਬਚੋ ਜੋ ਵਿਗਿਆਨਿਕ ਲੱਗਦੇ ਹਨ ਪਰ ਮਕਸਦ ਨੂੰ ਛੱਡ ਦਿੰਦੇ ਹਨ (ਜਿਵੇਂ ਔਸਤ ਜਵਾਬ ਲੰਬਾਈ)।
ਨੰਬਰ ਤੁਹਾਨੂੰ ਦੱਸਣਗੇ ਕਿ ਕਿਹੜੀ ਗਲਤ ਹੈ, ਪਰ ਨਹੀ ਕਿ ਕਿਉਂ। ਹਫਤਾਵਾਰ ਛੋਟੀ-ਸੀ ਸਮੀਖਿਆ ਸ਼ਾਮਲ ਕਰੋ ਅਤੇ ਹਲਕੀ ਫੀਡਬੈਕ ਇਕੱਤਰ ਕਰੋ ("ਕੀ ਗਲਤ ਸੀ?" "ਤੁਸੀਂ ਕੀ ਉਮੀਦ ਕੀਤੀ ਸੀ?")। ਇਹ ਥਾਂ ਉਹ ਹੈ ਜਿੱਥੇ ਤੁਸੀਂ ਟੋਨ ਦੀ ਅਸਮੰਜਸਤਾ, ਗੁੰਮ ਸੰਦਰਭ, ਅਤੇ ਉਹ ਫੇਲਿਉਰ ਪੈਟਰਨ ਫੜਦੇ ਹੋ ਜੋ ਤੁਹਾਡੇ ਮੈਟਰਿਕਸ ਨਹੀਂ ਦਿਖਾਉਂਦੇ।
ਜਦੋਂ ਤੁਸੀਂ ਨਤੀਜਾ ਮਾਪ ਸਕਦੇ ਹੋ, ਤਦੋਂ ਅਪਟੀਮਾਈਜ਼ੇਸ਼ਨ ਇਕ ਲੌਜਿਕਲ ਟੂਲ ਬਣ ਜਾਂਦੀ ਹੈ—ਅਨੁਮਾਨ ਨਹੀਂ।
AI ਫੀਚਰ "ਥੰਢੇ" ਨਹੀਂ ਹੁੰਦੇ। ਉਹ ਉਪਭੋਗਤਿਆਂ, ਡਾਟਾ, ਅਤੇ ਮਾਡਲਾਂ ਦੇ ਨਾਲ ਖਸਕਦੇ ਰਹਿੰਦੇ ਹਨ। ਜੇ ਤੁਸੀਂ ਪਹਿਲੀ ਵਾਰੀ ਦੇ ਚੰਗੇ ਨਤੀਜੇ ਨੂੰ ਖਤਮ ਹੋ ਗਿਆ ਸਮਝ ਲੈਂਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਇੱਕ ਧੀਰੀ-ਧੀਰੀ ਘਟਾਉ ਨੂੰ ਨਹੀਂ ਦੇਖੋਂਗੇ ਜੋ ਸਿਰਫ਼ ਉਪਭੋਗਤਿਆਂ ਦੀ ਸ਼ਿਕਾਇਤ 'ਤੇ ਹੀ ਸਪਸ਼ਟ ਹੋਏ।
ਰਵਾਇਤੀ ਮਾਨੀਟਰਿੰਗ ਦੱਸਦੀ ਹੈ ਕਿ ਸੇਵਾ ਚੱਲ ਰਹੀ ਹੈ। AI ਮਾਨੀਟਰਿੰਗ ਦੱਸਦੀ ਹੈ ਕਿ ਇਹ ਅਜੇ ਵੀ ਮਦਦਗਾਰ ਹੈ ਕਿ ਨਹੀਂ।
ਮੁੱਖ ਸੰਗੀਤਾਂ ਜੋ ਟਰੈਕ ਕਰੋ:
ਇਹਨਾਂ ਨੂੰ ਸਿਰਫ਼ ਇੰਜੀਨੀਅਰਿੰਗ ਮੈਟਰਿਕਸ ਵਜੋਂ ਨਹੀਂ, ਬਲਕਿ ਉਤਪਾਦ ਸਿਗਨਲ ਵਜੋਂ ਵੀ ਰੱਖੋ। ਇੱਕ-ਸੈਕਿੰਡ ਲੈਟੈਂਸੀ ਵਾਧਾ ਸਵੀਕਾਰਯੋਗ ਹੋ ਸਕਦਾ ਹੈ; 3% ਗਲਤ ਜਵਾਬਾਂ ਵਿੱਚ ਵਾਧਾ ਸਵੀਕਾਰਯੋਗ ਨਹੀਂ ਹੋ ਸਕਦਾ।
ਡ੍ਰਿਫਟ ਉਸ ਗੈਪ ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ ਜੋ ਤੁਹਾਡੇ ਸਿਸਟਮ ਨੂੰ ਟੈਸਟ ਕੀਤਾ ਗਿਆ ਸੀ ਅਤੇ ਹੁਣ ਜੋ ਇਹ ਸਾਮ੍ਹਣਾ ਕਰ ਰਿਹਾ ਹੈ ਵਿਚਕਾਰ ਹੈ। ਇਹ ਕਈ ਕਾਰਨਾਂ ਕਰਕੇ ਹੁੰਦਾ ਹੈ:
ਡ੍ਰਿਫਟ ਅਸਫਲਤਾ ਨਹੀਂ—ਇਹ ਸ਼ਿਪਿੰਗ ਦੀ ਹਕੀਕਤ ਹੈ। ਅਸਲ ਅਸਫਲਤਾ ਦੇਰ ਨਾਲ ਨੋਟਿਸ ਕਰਨਾ ਹੈ।
ਇਸੇ ਪ੍ਰਕਾਰ ਦੇ ਅਲਾਰਮ ਥ੍ਰੈਸ਼ਹੋਲਡ ਨਿਰਧਾਰਤ ਕਰੋ ਜੋ ਕੰਮ ਕੀਤੇ ਜਾਣ 'ਤੇ ਕਾਰਵਾਈ ਹੀ ਟ੍ਰਿਗਰ ਕਰਨ (ਹਰ ਧੁਨ ਤੋਂ ਨਹੀਂ): "refund requests +20%", "hallucination reports > X/day", "cost/request > $Y", "p95 latency > Z ms"। ਇੱਕ ਸਾਫ਼ ਜਵਾਬਦੇਹ ਨਿਯੁਕਤ ਕਰੋ (product + engineering), ਅਤੇ ਇੱਕ ਛੋਟੀ ਰਨਬੁੱਕ ਰੱਖੋ: ਕੀ چੈੱਕ ਕਰਨਾ, ਕੀ ਰੋਲਬੈਕ ਕਰਨਾ, ਕਿਵੇਂ ਸੰਚਾਰ ਕਰਨਾ।
ਹਰ ਮਹਤਵਪੂਰਨ ਬਦਲਾਅ—ਪ੍ਰਾਂਪਟ ਸੋਧ, ਮਾਡਲ/ਵਰਜਨ ਸਵੈਪ, ਰਿਟਰੀਵਲ ਸੈਟਿੰਗ, ਅਤੇ ਕਨਫ਼ਿਗ ਟਵੀਕ—ਨੇ ਇੱਕ ਸਧਾਰਣ ਚੇਂਜਲੌਗ ਵਿੱਚ ਟਰੈਕ ਕਰੋ। ਜਦੋਂ ਗੁਣਵੱਤਾ ਬਦਲਦੀ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਜਾਣ ਲਵੋਗੇ ਕਿ ਇਹ ਦੁਨੀਆ ਵਿੱਚ ਡ੍ਰਿਫਟ ਹੈ ਜਾਂ ਤੁਹਾਡੇ ਸਿਸਟਮ ਵਿੱਚ ਕੀਤੀ ਗਈ ਕੋਈ ਤਬਦੀਲੀ।
AI ਫੀਚਰ ਸਿਰਫ਼ "ਫੇਲ" ਨਹੀਂ ਹੁੰਦੇ—ਉਹ ਤੇਜ਼ੀ ਨਾਲ ਬੁਰੀ ਤਰ੍ਹਾਂ ਫੇਲ ਹੋ ਸਕਦੇ ਹਨ: ਗਲਤ ਈ-ਮੇਲ ਭੇਜਣਾ, ਸੰਵੇਦਨਸ਼ੀਲ ਜਾਣਕਾਰੀ ਲੀਕ ਕਰਨਾ, ਜਾਂ ਪੂਰਨ ਭਰੋਸੇ ਨਾਲ ਗ਼ਲਤ ਜਾਣਕਾਰੀ ਦੇਣਾ। ਭਰੋਸਾ ਉਸ ਵੇਲੇ ਬਣਦਾ ਹੈ ਜਦੋਂ ਉਪਭੋਗਤਾ ਵੇਖਦੇ ਹਨ ਕਿ ਸਿਸਟਮ ਮੂਲ ਤੌਰ 'ਤੇ ਸੁਰੱਖਿਅਤ ਹੈ, ਅਤੇ ਜਦੋਂ ਇਹ ਸੁਰੱਖਿਅਤ ਨਾ ਹੋਵੇ ਤਾਂ ਕਿਸੇ ਦੀ ਜਵਾਬਦੇਹੀ ਹੈ।
ਸਭ ਤੋਂ ਪਹਿਲਾਂ ਇਹ ਨਿਰਧਾਰਤ ਕਰੋ ਕਿ AI ਕਦੇ ਵੀ ਕੀ ਨਹੀਂ ਕਰ ਸਕਦਾ। ਸਮਗਰੀ ਫਿਲਟਰ ਜੋ ਨੀਤੀ ਉਲੰਘਣਾ, ਉਤੇਜਨਾ, ਸਵ-ਹਾਨੀ ਸਲਾਹ, ਜਾਂ ਸੰਵੇਦਨਸ਼ੀਲ ਡੇਟਾ ਲਈ ਨਿਯੰਤਰਣ ਕਰਦੇ ਹਨ ਜੋੜੋ, ਅਤੇ ਖਤਰਨਾਕ ਕਾਰਵਾਈਆਂ ਨੂੰ ਰੋਕੋ ਜੇ ਖ਼ਾਸ ਸ਼ਰਤ ਪੂਰੀ ਨਹੀਂ।
ਉਦਾਹਰਣ ਲਈ, ਜੇ AI ਸੁਝਾਅ ਡਰਾਫਟ ਕਰਦਾ ਹੈ, ਤਾਂ ਡਿਫੌਲਟ ਨੂੰ "ਸੁਝਾਓ" ਰੱਖੋ ਨਾ ਕਿ "ਭੇਜੋ"। ਜੇ ਇਹ ਰਿਕਾਰਡ ਅਪਡੇਟ ਕਰ ਸਕਦਾ ਹੈ, ਤਾਂ ਯੂਜ਼ਰ ਦੀ ਪੁਸ਼ਟੀ ਤੋਂ ਪਹਿਲਾਂ ਇਸਨੂੰ read-only ਰੱਖੋ। ਸੁਰੱਖਿਆ ਡਿਫੌਲਟ ਬਲਾਸਟ ਹੱਦ ਘਟਾਉਂਦੇ ਹਨ ਅਤੇ ਸ਼ੁਰੂਆਤੀ ਰਿਲੀਜ਼ ਨੂੰ ਸਹਿਣਯੋਗ ਬਨਾਉਂਦੇ ਹਨ।
ਉੱਚ ਪ੍ਰਭਾਵ ਵਾਲੇ ਫੈਸਲਿਆਂ ਲਈ ਮਨੁੱਖੀ-ਇਨ-ਦ-ਲੂਪ ਵਰਤੋ: ਮਨਜ਼ੂਰियाँ, ਰਿਫੰਡ, ਖਾਤਾ ਬਦਲਾਅ, ਕਾਨੂੰਨੀ/HR ਨਤੀਜੇ, ਮੈਡੀਕਲ ਜਾਂ ਵਿੱਤੀ ਸਲਾਹ, ਅਤੇ ਗਾਹਕ ਐਸਕਲੇਸ਼ਨ।
ਸੰਪੂਰਕ ਰੂਪ ਇਹ ਇੱਕ ਸੀਧਾ ਪੈਟਰਨ ਹੈ:
ਉਪਭੋਗਤਿਆਂ ਨੂੰ ਮਾਡਲ ਅੰਦਰੂਨੀ ਵਿਵਰਣ ਦੀ ਲੋੜ ਨਹੀਂ—ਉਨ੍ਹਾਂ ਨੂੰ ਇਮਾਨਦਾਰੀ ਅਤੇ ਅਗਲੇ ਕਦਮਾਂ ਦੀ ਲੋੜ ਹੈ। ਅਣਿਸ਼ਚਿਤਤਾ ਨੂੰ ਦਿਖਾਉਣ ਦੇ ਤਰੀਕੇ:
ਜਦੋਂ AI ਜਵਾਬ ਨਹੀਂ ਦੇ ਸਕਦਾ, ਇਹਨਾਂ ਨੂੰ ਅਜਿਹਾ ਦੱਸਣਾ ਚਾਹੀਦਾ ਹੈ ਅਤੇ ਉਪਭੋਗਤਾ ਨੂੰ ਅਗਲਾ ਰਾਸ਼ਤਾ ਦਿਖਾਉਣਾ ਚਾਹੀਦਾ ਹੈ।
ਮਕਸਦ ਰੱਖੋ ਕਿ ਪ੍ਰਾਂਪਟ ਜਾਂ ਮਾਡਲ ਬਦਲਣ ਤੋਂ ਬਾਅਦ ਗੁਣਵੱਤਾ ਘਟ ਸਕਦੀ ਹੈ। ਇੱਕ ਰੋਲਬੈਕ ਰਸਤਾ ਰੱਖੋ: ਪ੍ਰਾਂਪਟ/ਮਾਡਲਾਂ ਨੂੰ ਵਰਜਨ ਕਰੋ, ਹਰ ਆਉਟਪੁੱਟ ਨਾਲ ਕਿਹੜੀ ਵਰਜਨ ਸਰਵ ਕੀਤੀ ਗਈ ਦਰਜ ਕਰੋ, ਅਤੇ ਇੱਕ "ਕਿੱਲ-ਸਵਿੱਚ" ਨਿਰਧਾਰਤ ਕਰੋ ਜੋ ਪਿਛਲੇ ਜਾਣੇ-ਪਛਾਣੇ ਚੰਗੇ ਵਿਵਸਥਾ 'ਤੇ ਵਾਪਸ ਲਿਆ ਜਾ ਸਕੇ। ਰੋਲਬੈਕ ਟ੍ਰਿਗਰਾਂ ਨੂੰ ਅਸੂਲ ਤਰ੍ਹਾਂ (ਉਪਭੋਗਤਾ ਸੰਪਾਦਨ spike, ਨੀਤੀ ਹਿੱਟਸ, ਜਾਂ ਐਵਲੂਏਸ਼ਨ ਫੇਲ) ਨਾਲ ਜੋੜੋ, ਨਾ ਕਿ ਮਨ ਦੀ ਭਾਵਨਾ ਨਾਲ।
AI ਉਤਪਾਦ ਤੁਰੰਤ ਤੇ ਨਿਯੰਤਰਿਤ ਬਦਲਾਵ ਰਾਹੀਂ ਸੁਧਰਦੇ ਹਨ। ਬਿਨਾਂ ਅਨੁਸ਼ਾਸਨ ਦੇ, ਹਰੇਕ "ਛੋਟਾ ਸੁਧਾਰ" ਪ੍ਰਾਂਪਟ, ਮਾਡਲ, ਜਾਂ ਨੀਤੀ ਵਿੱਚ ਗੁਪਤ ਉਤਪਾਦ-ਪੁਨਰਲੇਖਨ ਬਣ ਜਾਂਦਾ ਹੈ—ਅਤੇ ਜਦੋਂ ਕੁਝ ਟੁੱਟਦਾ ਹੈ, ਤੁਹਾਡੇ ਕੋਲ ਸਮਝਾਉਣ ਜਾਂ ਤੇਜ਼ੀ ਨਾਲ ਵਾਪਸ ਜਾਣ ਦਾ ਤਰੀਕਾ ਨਹੀਂ ਰਹਿੰਦਾ।
ਤੁਹਾਡੇ ਪ੍ਰਾਂਪਟ ਟੈਮਪਲੇਟ, ਰਿਟਰੀਵਲ ਸੈਟਿੰਗ, ਸੁਰੱਖਿਆ ਨਿਯਮ, ਅਤੇ ਮਾਡਲ ਪੈਰਾਮੀਟਰ ਉਤਪਾਦ ਦਾ ਹਿੱਸਾ ਹਨ। ਉਨ੍ਹਾਂ ਨੂੰ ਕੋਡ ਦੇ ਤਰੀਕੇ ਨਾਲ ਮੈਨੇਜ ਕਰੋ:
ਪ੍ਰਯੋਗਿਕ ਚਾਲ: prompts/configs ਨੂੰ ਉਹੀ ਰੇਪੋ ਵਿੱਚ ਰੱਖੋ ਜਿੱਥੇ ਐਪ ਹੈ, ਅਤੇ ਹਰ ਰਿਲੀਜ਼ ਨੂੰ ਮਾਡਲ ਵਰਜਨ ਅਤੇ configuration hash ਨਾਲ ਟੈਗ ਕਰੋ। ਇਹ ਹੀ ਘਟਨਾਵਾਂ ਦੀ ਡੀਬੱਗਿੰਗ ਨੂੰ ਆਸਾਨ ਬਣਾਉਂਦਾ ਹੈ।
ਜੇ ਤੁਸੀਂ ਤੁਲਨਾ ਨਹੀਂ ਕਰ ਸਕਦੇ, ਤਾਂ ਤੁਸੀਂ ਸੁਧਾਰ ਨਹੀਂ ਕਰ ਸਕਦੇ। ਹਲਕਾ-ਫੁੱਲਕਾ ਐਕਸਪੈਰੀਮੈਂਟਸ ਵਰਤੋ ਜੋ ਤੇਜ਼ੀ ਨਾਲ ਸਿੱਖਣ ਦਿੰਦ ਹਨ ਅਤੇ ਬਲਾਸਟ ਰੇਡੀਅਸ ਘੱਟ ਰੱਖਦੇ ਹਨ:
ਐਕਸਪੈਰੀਮੈਂਟ ਛੋਟੇ ਰੱਖੋ, ਇੱਕ ਪ੍ਰਾਇਮਰੀ ਮੈਟ੍ਰਿਕ ਨਾਲ।
ਹਰ ਬਦਲਾਅ ਨਾਲ ਇੱਕ ਨਿਕਾਸ ਯੋਜਨਾ ਜੁੜੀ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ। ਰੋਲਬੈਕ ਸਭ ਤੋਂ ਆਸਾਨ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਇੱਕ ਫਲੈਗ ਦਬਾ ਕੇ ਪਿਛਲੇ ਜਾਣੇ-ਪਛਾਣੇ ਚੰਗੇ ਸੰਯੋਜਨ (ਮਾਡਲ, ਪ੍ਰਾਂਪਟ/ਕਨਫ਼ਿਗ, ਸੁਰੱਖਿਆ ਨੀਤੀ) ਤੇ ਵਾਪਸ ਆ ਸਕੋ।
"ਡਨ" ਦੀ ਪਰਿਭਾਸ਼ਾ ਵਿੱਚ ਇਹ ਸ਼ਾਮਲ ਕਰੋ:
AI ਫੀਚਰ "ਸ਼ਿਪ ਅਤੇ ਭੁਲਾ ਦਿਓ" ਨਹੀਂ ਹੁੰਦੇ। ਅਸਲ ਕੰਮ ਇਹ ਹੈ ਕਿ ਉਹਨਾਂ ਨੂੰ ਉਪਯੋਗੀ, ਸੁਰੱਖਿਅਤ, ਅਤੇ ਕਾਬਲੀਅਤ ਵਾਲਾ ਰੱਖਣਾ ਜਦੋਂ ਡਾਟਾ, ਉਪਭੋਗਤਾ, ਅਤੇ ਮਾਡਲ ਬਦਲਦੇ ਹਨ। ਓਪਰੇਸ਼ਨਜ਼ ਨੂੰ ਉਤਪਾਦ ਦਾ ਹਿੱਸਾ ਸਮਝੋ, ਪਿੱਛੋਂ ਨਹੀਂ।
ਤਿੰਨ ਮਿਆਰ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ:
ਵਿਆਵਹਾਰਿਕ ਮਧਅੰਤਰ: ਬੁਨਿਆਦ ਖਰੀਦੋ, ਫਰਕ ਨਿਰਮਾਣ ਕਰੋ: managed models/infrastructure ਵਰਤੋ, ਪਰ ਆਪਣੇ ਪ੍ਰਾਂਪਟ, ਰਿਟ੍ਰੀਵਲ ਲਾਜਿਕ, ਐਵਲੂਏਸ਼ਨ ਸੁੱਟ, ਅਤੇ ਬਿਜ਼ਨਸ ਨਿਯਮ ਘਰ ਵਿੱਚ ਰੱਖੋ।
AI ਖ਼ਰਚ ਆਮ ਤੌਰ 'ਤੇ ਕੇਵਲ "API calls" ਨਹੀਂ ਹੁੰਦਾ। ਯੋਜਨਾ ਵਿੱਚ ਸ਼ਾਮਲ ਕਰੋ:
ਜੇ ਤੁਸੀਂ ਮੁੱਲ ਪ੍ਰਕਾਸ਼ਤ ਕਰਦੇ ਹੋ ਤਾਂ AI ਫੀਚਰ ਨੂੰ ਇਕ ਸਪੱਸ਼ਟ ਖ਼ਰਚ ਮਾਡਲ ਨਾਲ ਜੋੜੋ ਤਾਂ ਟੀਮਾਂ ਬਾਅਦ ਵਿੱਚ ਹੈਰਾਨ ਨਾ ਹੋਣ (ਉਦਾਹਰਣ: "see /pricing").
ਇਹ ਨਿਰਧਾਰਤ ਕਰੋ ਕਿ ਕੌਣ ਜ਼ਿੰਮੇਵਾਰ ਹੈ:
ਇਸਨੂੰ ਦਿਖਾਓ: ਇਕ ਹਲਕੀ "AI ਸਰਵਿਸ ਮਾਲਿਕ" ਭੂਮਿਕਾ (product + engineering) ਅਤੇ ਇਕ ਨਿਯਮਤ ਸਮੀਖਿਆ ਚੱਕਰ। ਜੇ ਤੁਸੀਂ ਅਭਿਆਸ ਦਸਤਾਵੇਜ਼ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ ਆਪਣੀ ਅੰਦਰੂਨੀ /blog ਵਿੱਚ ਇਕ ਜੀਵਿਤ ਰਨਬੁੱਕ ਰੱਖੋ ਤਾਂ ਸਬਕ ਇੱਕ ਸਪ੍ਰਿੰਟ ਤੋਂ ਦੂਜੇ ਤਕ ਗੁਣਾ ਹੋ ਸਕਣ।
ਜੇ ਤੁਹਾਡੀ ਰੁਕਾਵਟ ਇੱਕ ਵਿਚਾਰ ਨੂੰ ਕੰਮ ਕਰਨ ਵਾਲੇ, ਟੈਸਟ ਕਰਨ ਯੋਗ ਉਤਪਾਦ ਲੂਪ ਵਿਚ ਤਬਦੀਲ ਕਰਨ ਦੀ ਹੈ, ਤਾਂ Koder.ai ਤੁਹਾਨੂੰ ਪਹਿਲੀ ਅਸਲ MVP ਤੱਕ ਤੇਜ਼ੀ ਨਾਲ ਪਹੁੰਚਣ ਵਿੱਚ ਮਦਦ ਕਰ ਸਕਦਾ ਹੈ—web apps (React), backends (Go + PostgreSQL), ਅਤੇ mobile apps (Flutter) ਨੂੰ chat-driven workflow ਦੁਆਰਾ ਬਣਾਉਂਦਾ ਹੈ। ਮੁੱਖ ਗੱਲ ਇਹ ਹੈ ਕਿ ਉਸ ਤੇਜ਼ੀ ਨੂੰ ਜ਼ਿੰਮੇਵਾਰੀ ਨਾਲ ਵਰਤੋ: ਤੇਜ਼ ਤਿਆਰ ਕਰਨ ਨੂੰ ਉਹੀ ਐਵਲੂਏਸ਼ਨ ਗੇਟ, ਮਾਨੀਟਰਿੰਗ, ਅਤੇ ਰੋਲਬੈਕ ਡਿਸਿਪਲਿਨ ਨਾਲ ਜੋੜੋ ਜੋ ਤੁਸੀਂ ਇੱਕ ਰਵਾਇਤੀ ਕੋਡਬੇਸ ਵਿੱਚ ਵਰਤਦੇ ਹੋ।
ਜਿਵੇਂ planning mode, source code export, deployment/hosting, custom domains, ਅਤੇ snapshots/rollback ਵਰਗੀਆਂ ਖਾਸੀਯਤਾਂ ਖਾਸ ਤੌਰ 'ਤੇ ਫਾਇਦੇਮੰਦ ਹਨ ਜਦੋਂ ਤੁਸੀਂ ਪ੍ਰਾਂਪਟ ਅਤੇ ਵਰਕਫਲੋ 'ਤੇ ਦੁਹਰਾਅ ਕਰ ਰਹੇ ਹੋ ਅਤੇ ਫਿਰੋਂ-ਬਦਲਾਅ ਲਈ ਨਿਯੰਤਰਿਤ ਰਿਲੀਜ਼ ਚਾਹੁੰਦੇ ਹੋ।
"AI-ਪਹਿਲਾਂ" ਹੋਣਾ ਸਭ ਤੋਂ ਮਹਿੰਗੇ ਮਾਡਲ ਚੁਣਨ ਬਾਰੇ ਨਹੀਂ, ਬਲਕਿ ਇਕ ਦੁਹਰਾਅਯੋਗ ਰੱਧੀ ਅਪਣਾਉਣ ਬਾਰੇ ਹੈ: ship → measure → learn → improve, ਉਹਨਾਂ ਸੁਰੱਖਿਆ ਰੇਲਾਂ ਨਾਲ ਜੋ ਤੁਹਾਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਹਿਲਾਉਣ ਦਿੰਦੀਆਂ ਹਨ ਬਿਨਾਂ ਭਰੋਸਾ ਟੁੱਟਣ ਦੇ।
ਹਰੇਕ AI ਫੀਚਰ ਨੂੰ ਇੱਕ ਅਨੁਮਾਨ ਸਮਝੋ। ਸਭ ਤੋਂ ਛੋਟਾ ਸਂਸਕਰ ਰਿਲੀਜ਼ ਕਰੋ ਜੋ ਅਸਲ ਉਪਭੋਗਤੀ ਮੁੱਲ ਪੈਦਾ ਕਰਦਾ ਹੈ, ਇੱਕ ਪ੍ਰਿਭਾਸ਼ਿਤ ਐਵਲੂਏਸ਼ਨ ਸੈਟ ਨਾਲ ਨਤੀਜੇ ਮਾਪੋ (ਭਾਵੇਂGut ਨਹੀਂ), ਫਿਰ ਨਿਯੰਤਰਿਤ ਐਕਸਪੈਰੀਮੈਂਟਸ ਅਤੇ ਆਸਾਨ ਰੋਲਬੈਕ ਨਾਲ ਦੁਹਰਾਓ। ਮੰਨੋ ਕਿ ਮਾਡਲ, ਪ੍ਰਾਂਪਟ, ਅਤੇ ਉਪਭੋਗਤਾ ਵਰਤਾਰਾ ਬਦਲੇਗਾ—ਇਸ ਲਈ ਆਪਣਾ ਉਤਪਾਦ ਇਸ ਤਰ੍ਹਾਂ ਡਿਜ਼ਾਈਨ ਕਰੋ ਕਿ ਇਹ ਬਦਲਾਅ ਨੂੰ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਅੰਦਰ ਲੈ ਸਕੇ।
ਹਫ਼ਤਾ 1: ਸਭ ਤੋਂ ਛੋਟਾ ਕੀਮਤੀ ਹਿੱਸਾ ਚੁਣੋ। ਉਪਭੋਗਤਾ ਨਤੀਜਾ, ਪਾਬੰਦੀਆਂ, ਅਤੇ v1 ਲਈ "ਡਨ" ਕੀ ਹੈ ਨਿਰਧਾਰਤ ਕਰੋ।
ਹਫ਼ਤਾ 2: ਐਵਲ ਸੈੱਟ ਅਤੇ ਬੇਸਲਾਈਨ ਬਣਾਓ। ਉਦਾਹਰਣ ਇਕੱਤਰ ਕਰੋ, ਲੇਬਲ ਕਰੋ, ਇੱਕ ਬੇਸਲਾਈਨ ਮਾਡਲ/ਪ੍ਰਾਂਪਟ ਚਲਾਓ, ਅਤੇ ਸਕੋਰ ਦਰਜ ਕਰੋ।
ਹਫ਼ਤਾ 3: ਇੱਕ ਛੋਟੇ ਸਮੂਹ 'ਤੇ ਸ਼ਿਪ ਕਰੋ। ਮਾਨੀਟਰਿੰਗ, ਮਨੁੱਖੀ ਫੈਲਬੈਕ, ਅਤੇ ਕਠੋਰ ਅਧਿਕਾਰ ਜੋੜੋ। ਸੀਮਿਤ ਰੋਲਆਊਟ ਜਾਂ ਅੰਦਰੂਨੀ ਬੀਟਾ ਚਲਾਓ।
ਹਫ਼ਤਾ 4: ਸਿੱਖੋ ਅਤੇ ਦੁਹਰਾਓ। ਫੇਲਿਆਂ ਦੀ ਸਮੀਖਿਆ ਕਰੋ, ਪ੍ਰਾਂਪਟ/UX/ਗਾਰਡਰੇਲ ਅਪਡੇਟ ਕਰੋ, ਅਤੇ v1.1 ਰਿਲੀਜ਼ ਕਰੋ ਚੇਂਜਲੌਗ ਅਤੇ ਰੋਲਬੈਕ ਤਿਆਰ ਨਾਲ।
ਜੇ ਤੁਸੀਂ ਕੇਵਲ ਇਕ ਗੱਲ ਕਰੋ: ਮਾਡਲ ਨੂੰ ਅਪਟੀਮਾਈਜ਼ ਨਾ ਕਰੋ ਜਦੋਂ ਤੱਕ ਤੁਸੀਂ ਨਤੀਜਾ ਮਾਪ ਨਹੀਂ ਸਕਦੇ।
"AI-first" ਦਾ ਮਤਲਬ ਇਹ ਹੈ ਕਿ ਉਤਪਾਦ ਇਸ ਤਰ੍ਹਾਂ ਡਿਜ਼ਾਈਨ ਕੀਤਾ ਗਿਆ ਹੈ ਕਿ ML/LLMs ਮੂਲ ਸਮਰੱਥਾ ਹੋਣ (ਉਦਾਹਰਣ ਲਈ: ਖੋਜ, ਸਿਫਾਰਸ਼ਾਂ,ਸੰਖੇਪ, ਰਾਊਟਿੰਗ, ਫੈਸਲੇ ਦੀ ਸਹਾਇਤਾ) ਅਤੇ ਬਾਕੀ ਸਿਸਟਮ (UX, ਵਰਕਫਲੋ, ਡਾਟਾ, ਓਪਰੇਸ਼ਨ) ਇਸ ਸਮਰੱਥਾ ਨੂੰ ਭਰੋਸੇਯੋਗ ਬਣਾਉਣ ਲਈ ਬਣੇ ਹੋਣ।
ਇਹ "ਅਸੀਂ ਇੱਕ ਚੈਟਬੋਟ ਜੋੜ ਦਿੱਤਾ" ਨਹੀਂ ਹੈ। ਇਹ ਹੈ "ਉਤਪਾਦ ਦੀ ਕੀਮਤ ਇਸ ਗੱਲ ਤੇ ਨਿਰਭਰ ਕਰਦੀ ਹੈ ਕਿ AI ਅਸਲ ਵਰਤੋਂ ਵਿੱਚ ਚੰਗਾ ਕੰਮ ਕਰੇ।"
ਆਮ "ਨਹੀਂ AI-first" ਦੇ ਨਮੂਨੇ ਸ਼ਾਮਲ ਹਨ:
ਜੇ ਤੁਸੀਂ ਇੱਕ ਮਾਡਲ ਦਾ ਨਾਮ ਦੱਸੇ ਬਿਨਾਂ ਉਪਭੋਗਤਾ ਨਤੀਜੇ ਨੂੰ ਸਮਝਾ ਨਹੀਂ ਸਕਦੇ, ਤਾਂ ਤੁਹਾਡੀ ਡਿਜ਼ਾਈਨ ਸੰਭਵਤ: ਸਮਰੱਥਾਵਾਂ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਹੈ, ਨਾਂ ਕਿ ਨਤੀਜਿਆਂ ਦੇ।
ਇੱਕ ਉਪਭੋਗਤਾ ਨਤੀਜੇ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ ਅਤੇ ਇਹ ਪਸੰਦ ਕਰੋ ਕਿ ਤੁਸੀਂ ਕਿਵੇਂ ਸਫਲਤਾ ਨੂੰ ਪਛਾਣੋਗੇ। ਸਧਾਰਨ ਭਾਸ਼ਾ ਵਿੱਚ ਲਿਖੋ ਅਤੇ ਆਮ ਤੌਰ 'ਤੇ ਇਕ job story ਵਰਗਾ ਫਾਰਮੈਟ ਵਰਤੋ:\n\n- ਜਦੋਂ …\n- ਮੈਂ ਚਾਹੁੰਦਾ/ਚਾਹੁੰਦੀ ਹਾਂ …\n- ਤਾਂ ਜੋ ਮੈਂ …\n ਫਿਰ 1–3 ਮਾਪਨ ਯੋਗ ਸੰਕੇਤ ਚੁਣੋ (ਜਿਵੇਂ ਸਮਾਂ ਬਚਿਆ, ਟਾਸਕ ਮੁਕੰਮਲ ਦਰ, ਪਹਿਲੀ ਜਵਾਬ ਰੈਜ਼ੋਲੂਸ਼ਨ) ਤਾਂ ਜੋ ਤੁਸੀਂ ਸੁਬੂਤਾਂ ਦੇ ਆਧਾਰ 'ਤੇ ਦੁਹਰਾਓ ਕਰ ਸਕੋ, ਕੇਵਲ ਦਿਖਾਵੇ ਲਈ ਨਹੀਂ।
ਸ਼ੁਰੂ ਵਿੱਚ ਮਿਆਰਾਂ ਨੂੰ ਲਿਖੋ ਅਤੇ ਉਨ੍ਹਾਂ ਨੂੰ ਪ੍ਰੋਡਕਟ ਦੀਆਂ ਲੋੜਾਂ ਵਾਂਗ ਰੱਖੋ:
ਇੱਕ ਚੰਗੀ AI MVP ਇੱਕ ਸਿੱਖਣ ਵਾਲਾ ਉਪਕਰਨ ਹੁੰਦੀ ਹੈ: ਸਭ ਤੋਂ ਛੋਟਾ ਅਸਲ ਮੁੱਲ ਜੋ ਤੁਸੀਂ ਅਸਲੀ ਉਪਭੋਗਤਿਆਂ ਨੂੰ ਦੇ ਸਕਦੇ ਹੋ ਤਾਂ ਜੋ ਤੁਸੀਂ ਦੇਖ ਸਕੋ ਕਿੱਥੇ AI ਮਦਦ ਕਰਦਾ ਹੈ ਅਤੇ ਕਿੱਥੇ ਫੇਲ ਹੁੰਦਾ ਹੈ।
v1 ਨੂੰ ਸੰਕੁਚਿਤ ਰੱਖੋ:\n\n- ਇੱਕ ਕੰਮ (ਉਦਾਹਰਣ: "refund requests ਲਈ ਜਵਾਬ ਡ੍ਰਾਫਟ ਕਰੋ")\n- ਪੇਸ਼ਗੀ ਅਣੁਮਾਨਯੋਗ ਇਨਪੁਟਾਂ ਨੂੰ ਘੱਟ ਰੱਖੋ\n- ਨਿਰਧਾਰਤ ਆਉਟਪੁੱਟ ਫਾਰਮੈਟ
2–4 ਹਫ਼ਤੇ ਦਾ ਸਿੱਖਣ ਵਿੰਡੋ ਨਿਰਧਾਰਤ ਕਰੋ ਅਤੇ ਪਹਿਲਾਂ ਹੀ ਫੈਸਲਾ ਕਰੋ ਕਿ ਕਿਹੜੇ ਮੈਟਰਿਕਸ ਅਗਲੀ ਦੁਹਰਾਈ ਨੂੰ ਨਿਰਧਾਰਤ ਕਰਨਗੇ (ਮੰਨਣ/ਸੰਪਾਦਨ ਦਰ, ਬਚਾਇਆ ਸਮਾਂ, ਮੂਲ ਫੇਲਿਉਰ ਸ਼੍ਰੇਣੀਆਂ, ਪ੍ਰਤੀ ਸਫਲ ਨਤੀਜੇ ਲਾਗਤ)।
ਪਰਤਾਂ ਵਿੱਚ ਰੋਲਆਊਟ ਕਰੋ ਨਾ ਕਿ ਸਭ ਇਕੱਠੇ:\n\n1. ਅੰਦਰੂਨੀ ਟੈਸਟਿੰਗ: ਟੀਮ ਨਾਲ dogfood ਕਰੋ, ਫੇਲਿਊਰ ਕੇਸਾਂ ਨੂੰ ਕੈਪਚਰ ਕਰੋ, ਅਤੇ ਇੱਕ ਸਮੀਖਿਆ ਦੀ ਆਦਤ ਬਣਾਓ।\n2. ਸੀਮਿਤ ਬੀਟਾ: ਮਿੱਤਰ ਉਪਭੋਗਤਿਆਂ ਦਾ ਛੋਟਾ ਸਮੂਹ ਅਤੇ ਸਪੱਸ਼ਟ ਫੀਡਬੈਕ ਚੈਨਲ।\n3. ਵਿਆਪਕ ਰੀਲੀਜ਼: ਸਿਰਫ਼ ਉਸ ਵੇਲੇ ਵਧਾਓ ਜਦੋਂ ਉਪਰੀ ਮੁੱਦੇ ਥੰਢੇ ਹੋ ਜਾਣ।\n ਹਰ ਪੜਾਅ ਲਈ "ਰੁਕੋ" ਮਾਪਦੰਡ ਰੱਖੋ (ਜਿਵੇਂ ਗਲਤੀਆਂ ਦੀਆਂ ਅਣਸਵੀਕਾਰਜੋਗ ਕਿਸਮਾਂ, ਲਾਗਤ ਵਿੱਚ ਤੇਜ਼ ਵਾਧਾ ਜਾਂ ਉਪਭੋਗਤਾ ਗੁੰਝਲਦਾਰੀ)।
ਮਾਡਲ ਦੇ ਬਦਲਣ ਦੀ ਸਥਿਤੀ ਵਿੱਚ ਵੀ ਬਦਲਣ ਯੋਗ ਬਣਾਓ:
ਏਕ provider-agnostic "model adapter" ਬਣਾਓ ਅਤੇ ਆਉਟਪੁੱਟ ਫਾਰਮੈਟ ਨੂੰ ਸਟੈਂਡਰਡ ਰੱਖੋ ਤਾਂ ਜੋ ਤਬਦੀਲੀਆਂ ਘੱਟ ਖਤਰਨਾਕ ਹੋਣ।
ਛੋਟਾ ਇੱਕ ਫਾਇਦਾ ਬੰਨਾਮ ਘੰਟੇ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ ਮਾਪੋ। ਇੱਕ ਛੋਟਾ ਐਵਲ ਸੈਟ ਬਣਾਓ (ਆਮ ਤੌਰ ਤੇ 20–50 ਅਸਲ ਉਦਾਹਰਣ) ਜੋ ਆਮ ਕੇਸਾਂ ਅਤੇ ਐਜ ਕੇਸਾਂ ਨੂੰ ਮਿਲਾਉਂਦਾ ਹੈ।
ਹਰ ਉਦਾਹਰਣ ਵਿੱਚ ਦਰਜ ਕਰੋ:\n\n- ਇਨਪੁਟ\n- ਸਿਸਟਮ ਕੋਲ ਜੋ ਸੰਦਰਭ ਹੈ\n- ਉਮੀਦ ਕੀਤੀ ਨਤੀਜਾ (ਕਦੇ-ਕਦੇ ਇਹ "ਇਸ ਨੂੰ ਸਪੱਸ਼ਟੀਕਰਨ ਸਵਾਲ ਪੁੱਛੋ" ਜਾਂ "ਸੁਰੱਖਿਅਤ ਤੌਰ ਤੇ ਇਨਕਾਰ ਕਰੋ" ਵੀ ਹੋ ਸਕਦਾ ਹੈ)
ਨਤੀਜਾ-ਸੰਰਚਿਤ ਮੈਟਰਿਕਸ ਨੂੰ ਟਰੈਕ ਕਰੋ (ਸਫਲਤਾ ਦਰ, ਬਚਾਇਆ ਸਮਾਂ, ਉਪਭੋਗਤਾ ਸੰਤੁਸ਼ਟੀ) ਅਤੇ ਇੱਕ ਹਫਤਾਵਾਰ ਗੁਣਵੱਤਾ ਸਮੀਖਿਆ ਜੋ ਦੱਸੇ ਕਿ ਫੇਲ ਕਿਉਂ ਹੋ ਰਹੀ ਹੈ।
ਇਹ ਨਿਰੀਖਣ ਤੇ ਧਿਆਨ ਦਿਓ ਕਿ ਸਿਸਟਮ ਅਜੇ ਵੀ "ਮਦਦਗਾਰ" ਹੈ ਕਿ ਨਹੀਂ।
ਪਹਿਲਾਂ ਟਰੈਕ ਕਰੋ:\n\n- ਗੁਣਵੱਤਾ ਵਿੱਚ ਡਿੱਗ (ਘਟਦੀ ਮਨਜ਼ੂਰੀ ਦਰ, ਵੱਧ ਸੰਪਾਦਨ)\n- ਉਪਭੋਗਤਾ ਸ਼ਿਕਾਇਤਾਂ (ਸਪੋਰਟ ਟਿਕਟਾਂ ਵਿੱਚ ਝਟਕੇ)\n- ਲਾਗਤ ਵਾਧਾ (ਰਿਕੁਅਸਟ ਪ੍ਰਤੀ ਟੋਕਨ/ਕਮਪਿਊਟ)\n- ਲੈਟੈਂਸੀ ਵਾਧਾ (ਵਧਦੀ ਪ੍ਰਤੀਸ਼ਤ ਲੈਟੈਂਸੀ)
ਡ੍ਰਿਫਟ ਆਮ ਹੈ: ਡਾਟਾ, ਮਾਡਲ ਅੱਪਡੇਟ ਜਾਂ ਨਵੇਂ ਵਰਤੋਂ ਕੇਸਾਂ ਕਾਰਨ। ਅਲਾਰਮ ਥ੍ਰੈਸ਼ਹੋਲਡ ਅਤੇ ਜਵਾਬਦੇਹ ਤੈਅ ਕਰੋ (ਪ੍ਰੋਡਕਟ + ਇੰਜੀਨੀਅਰਿੰਗ) ਅਤੇ ਛੋਟੀ ਰਨਬੁੱਕ ਰੱਖੋ: ਕੀ ਚੈੱਕ ਕਰਨਾ, ਕਿਵੇਂ ਰੋਲਬੈਕ ਕਰਨਾ, ਅਤੇ ਕਿਵੇਂ ਸੰਚਾਰ ਕਰਨਾ।
ਸੁਰੱਖਿਆ-ਰਖਿਆਵਾਂ ਅਤੇ ਮਨੁੱਖੀ-ਇਨ-ਦ-ਲੂਪ ਉਪਾਅ:
ਪਰਿਵਰਤਨ ਨੂੰ ਨਿਯੰਤਰਿਤ, ਮਿਲੀ-ਜੁਲੀ ਤਰ੍ਹਾਂ ਨਾਲ ਚਲਾਓ:
ਪਰਿਵਰਤਨ ਨਾਲ ਸਬੰਧਿਤ ਹਰ ਰੀਲੀਜ਼ ਲਈ ਇੱਕ ਐਗਜ਼ਿਟ ਪਲਾਨ ਰੱਖੋ: ਮਾਡਲ, ਪ੍ਰਾਂਪਟ/ਕਨਫ਼ਿਗ ਅਤੇ ਸੁਰੱਖਿਆ ਨੀਤੀ ਲਈ ਇੱਕ-ਕਲਿਕ ਰਿਵਰਟ।
AI ਫੀਚਰਾਂ ਨੂੰ ਬਣਾਉਣ ਅਤੇ ਰੱਖ ਰੱਖਾਅ ਦੋਹਾਂ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ।
ਵਿਸ਼ੇਸ਼ ਧਿਆਨ ਰੱਖੋ:\n\n- ਤੇਜ਼ੀ: ਜੇ ਤੁਹਾਨੂੰ ਹਫਤਿਆਂ ਵਿੱਚ ਮੁੱਲ ਚਾਹੀਦਾ ਹੈ ਤਾਂ ਖਰੀਦਣਾ ਆਮ ਤੌਰ 'ਤੇ ਜਿੱਤਦਾ ਹੈ।\n- ਨਿਯੰਤਰਣ: ਜੇ ਤੁਹਾਨੂੰ ਡੇਟਾ ਰਿਹਾਇਸ਼ ਜਾਂ ਗਹਿਰੇ ਇੰਟੇਗ੍ਰੇਸ਼ਨ ਦੀ ਲੋੜ ਹੈ ਤਾਂ ਬਣਾਉਣਾ ਫਾਇਦੇਮੰਦ ਹੋ ਸਕਦਾ ਹੈ।\n- ਜੋਖਮ: ਜੇ ਗਲਤੀਆਂ ਨਾਲ ਕਾਨੂੰਨੀ/ਬ੍ਰਾਂਡ ਪ੍ਰਭਾਵ ਹੋ ਸਕਦਾ ਹੈ, ਤਦੋ ਉਹ ਵਿਕਲਪ ਚੁਣੋ ਜੋ ਵੱਧ ਗਾਰੰਟੀ ਦਿੰਦਾ ਹੈ।
ਵਿਆਵਹਾਰਿਕ ਰਾਹ: ਬੁਨਿਆਦ ਖਰੀਦੋ, ਫਰਕ ਨਿਰਮਾਣ ਕਰੋ—managed models/infrastructure ਵਰਤੋ, ਪਰ ਪ੍ਰਾਂਪਟ, ਰਿਟ੍ਰੀਵਲ ਲਾਜਿਕ, ਐਵਲੂਏਸ਼ਨ ਅਤੇ ਬਿਜ਼ਨਸ ਨਿਯਮ ਘਰ ਵਿੱਚ ਰੱਖੋ।
ਹੇਠਾਂ ਇੱਕ ਸਧਾਰਣ ਚੈਕਲਿਸਟ (v1) ਜੋ ਰਲੀਜ਼ ਤੋਂ ਪਹਿਲਾਂ ਵਰਤੋਂਗੇ: