22 ਜੁਲਾ 2025·8 ਮਿੰਟ
ਨਵੀਆਂ AI ਐਪ ਬਣਾਉਣ ਵਾਲਿਆਂ ਵੱਲੋਂ ਕੀਤੀਆਂ ਜਾਣ ਵਾਲੀਆਂ ਆਮ ਗਲਤੀਆਂ (ਅਤੇ ਠੀਕ ਕਰਨ ਦੇ ਤਰੀਕੇ)
AI ਨਾਲ ਐਪ ਬਣਾਉਣ ਵੇਲੇ ਆਮ ਗਲਤੀਆਂ—ਅਸਪਸ਼ਟ ਲਕਸ਼, ਕਮਜ਼ੋਰ ਪ੍ਰੌਂਪਟ, ਬੇਸਲਾਈਨ/ਮੁਲਾਂਕਣ ਦੀ ਘਾਟ, ਅਤੇ ਭਰੋਸੇ-ਯੋਗ UX ਦੇ ਖਾਟੇ—ਅਤੇ ਉਨ੍ਹਾਂ ਤੋਂ ਕਿਵੇਂ ਬਚਣਾ ਹੈ।
AI ਨਾਲ ਐਪ ਬਣਾਉਣ ਵੇਲੇ ਆਮ ਗਲਤੀਆਂ—ਅਸਪਸ਼ਟ ਲਕਸ਼, ਕਮਜ਼ੋਰ ਪ੍ਰੌਂਪਟ, ਬੇਸਲਾਈਨ/ਮੁਲਾਂਕਣ ਦੀ ਘਾਟ, ਅਤੇ ਭਰੋਸੇ-ਯੋਗ UX ਦੇ ਖਾਟੇ—ਅਤੇ ਉਨ੍ਹਾਂ ਤੋਂ ਕਿਵੇਂ ਬਚਣਾ ਹੈ।
AI ਐਪ ਪਹਿਲਾਂ ਆਸਾਨ ਲੱਗਦੇ ਹਨ: ਤੁਸੀਂ ਇੱਕ API ਜੁੜਦੇ ਹੋ, ਕੁਝ ਪ੍ਰੌਂਪਟ ਲਿਖਦੇ ਹੋ, ਅਤੇ ਡੈਮੋ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਦਿਖਦਾ ਹੈ। ਫਿਰ ਅਸਲ ਯੂਜ਼ਰ ਆਉਂਦੇ ਹਨ ਸਾਥ ਹੀ ਗੰਦਗੀ ਇਨਪੁੱਟ, ਅਸਪਸ਼ਟ ਲਕਸ਼ ਅਤੇ ਐਡਜ ਕੇਸ ਲੈਂਦੇ ਹਨ — ਅਤੇ ਅਚਾਨਕ ਐਪ inconsistent, ਧੀਮਾ ਜਾਂ ਬੇੜਾ/ਗਲਤ ਹੋ ਜਾਂਦਾ ਹੈ।
ਇੱਕ “ਸ਼ੁਰੂਆਤੀ ਗਲਤੀ” competence ਦੀ ਗੱਲ ਨਹੀਂ। ਇਹ ਇਸ ਗੱਲ ਬਾਰੇ ਹੈ ਕਿ ਤੁਸੀਂ ਇੱਕ ਨਵੀਂ ਕਿਸਮ ਦੇ ਕੰਪੋਨੈਂਟ ਨਾਲ ਬਿਲਡ ਕਰ ਰਹੇ ਹੋ: ਇੱਕ ਮਾਡਲ ਜੋ probabilistic ਹੈ, ਸੰਦਰਭ ਲਈ ਸੰਵੇਦਨਸ਼ੀਲ ਹੈ, ਅਤੇ ਕਦੇ-ਕਦੇ ਯਕੀਨੀ ਤੌਰ 'ਤੇ ਮੰਨਹੋਰ ਜਵਾਬ ਇਜਾਦ ਕਰ ਦਿੰਦਾ ਹੈ। ਬਹੁਤ ਸਾਰੇ ਸ਼ੁਰੂਆਤੀ ਫੇਲੂਰ ਇਸ ਲਈ ਹੁੰਦੇ ਹਨ ਕਿਉਂਕਿ ਟੀਮਾਂ ਉਸ ਕੰਪੋਨੈਂਟ ਨੂੰ ਇੱਕ ਆਮ ਲਾਇਬ੍ਰੇਰੀ ਕਾਲ ਵਾਂਗ ਸਮਝਦੀਆਂ ਹਨ—ਨਿਰਧਾਰਤ, ਪੂਰੀ ਤਰ੍ਹਾਂ ਕਾਬੂਯੋਗ, ਅਤੇ ਬਿਜ਼ਨੈਸ ਨਾਲ ਪਹਿਲਾਂ ਹੀ aligned।
ਇਹ ਗਾਈਡ ਖਤਰਾ ਤੇਜ਼ੀ ਨਾਲ ਘਟਾਉਣ ਲਈ ਬਣਾਈ ਗਈ ਹੈ। ਸਭ ਤੋਂ ਵੱਧ ਪ੍ਰਭਾਵ ਵਾਲੀਆਂ ਮੁਸ਼ਕਲਾਂ ਸਭ ਤੋਂ ਪਹਿਲਾਂ ਠੀਕ ਕਰੋ (ਸਮੱਸਿਆ ਦੀ ਚੋਣ, ਬੇਸਲਾਈਨ, ਮੁਲਾਂਕਣ, ਅਤੇ ਭਰੋਸੇ ਲਈ UX), ਫਿਰ optimize ਕਰਨ ਦੀਆਂ ਚੀਜ਼ਾਂ 'ਤੇ ਜਾਓ (ਲਾਗਤ, latency, ਮੋਨੀਟਰਿੰਗ)। ਜੇ ਤੁਹਾਡੇ ਕੋਲ ਕੁਝ ਹੀ ਵੇਲਾ ਹੈ, ਤਾਂ ਉਹ ਚੁਣੋ ਜੋ ਚੁਪ ਰਿਹਾ ਫੇਲ ਹੋਣ ਤੋਂ ਰੋਕਦੇ ਹਨ।
ਆਪਣੀ AI ਐਪ ਨੂੰ ਇੱਕ ਚੇਨ ਵਾਂਗ ਸੋਚੋ:
ਜਦੋਂ ਪ੍ਰੋਜੈਕਟ ਸ਼ੁਰੂ ਵਿੱਚ ਫੇਲ ਹੁੰਦੇ ਹਨ, ਟੁੱਟਣ ਆਮ ਤੌਰ 'ਤੇ ਇਹ ਨਹੀਂ ਹੁੰਦਾ ਕਿ “ਮਾਡਲ ਖਰਾਬ ਹੈ।” ਬਲਕਿ ਚੇਨ ਦਾ ਕੋਈ ਇੱਕ ਲਿੰਕ undefined, ਅਟੈਸਟਡ, ਜਾਂ ਅਸਲ ਵਰਤੋਂ ਨਾਲ misaligned ਹੁੰਦਾ ਹੈ। ਅਗਲੇ ਭਾਗ ਉਹ ਸਭ ਤੋਂ ਆਮ ਕਮਜ਼ੋਰ ਲਿੰਕ ਦਿਖਾਉਂਦੇ ਹਨ—ਅਤੇ ਉਹ ਪ੍ਰੈਕਟਿਕਲ ਠੀਕੁਆਉਣੀਆਂ ਜੋ ਤੁਸੀਂ ਸਭ ਕੁਝ ਦੁਬਾਰਾ ਬਣਾਏ ਬਿਨਾਂ ਲਾਗੂ ਕਰ ਸਕਦੇ ਹੋ।
ਇੱਕ ਪ੍ਰਾਇਗਮ ਦੇ ਤੌਰ ਤੇ: ਜੇ ਤੁਸੀਂ ਤੇਜ਼ੀ ਨਾਲ ਅੱਗੇ ਵਧ ਰਹੇ ਹੋ, ਤਾਂ ਇੱਕ ਐਸੇ ਮਾਹੌਲ ਦੀ ਵਰਤੋਂ ਕਰੋ ਜਿੱਥੇ ਤੁਸੀਂ ਸੇਫ਼ ਤੌਰ 'ਤੇ iterate ਕਰ ਸਕੋ ਅਤੇ ਤੁਰੰਤ rollback ਕਰ ਸਕੋ। Koder.ai ਵਰਗੇ ਪਲੇਟਫਾਰਮ ਇਸ ਵਿੱਚ ਮਦਦਗਾਰ ਹੋ ਸਕਦੇ ਹਨ ਕਿਉਂਕਿ ਤੁਸੀਂ ਫਲੋਜ਼ ਦਾ ਤੇਜ਼ ਪ੍ਰੋਟੋਟਾਈਪ ਬਣਾ ਸਕਦੇ ਹੋ, ਬਦਲਾਅ ਛੋਟੇ ਰੱਖ ਸਕਦੇ ਹੋ, ਅਤੇ ਕਿ ਤਜਰਬਾ ਗੁਣਵੱਤਾ ਘਟੇ ਤਾਂ snapshots/rollback 'ਤੇ ਨਿਰਭਰ ਰਹਿ ਸਕਦੇ ਹੋ।
ਇੱਕ ਆਮ ਫੇਲ ਦੇ ਢੰਗ ਵਿੱਚ ਇਹ ਹੁੰਦਾ ਹੈ ਕਿ ਪਹਿਲਾਂ “ਆਓ AI ਜੋੜੀਏ” ਕਹਿ ਕੇ ਬਾਅਦ ਵਿੱਚ ਕਿਸੇ ਥਾਂ ਲਈ ਵਰਤੋਂ ਢੂੰਢੀ ਜਾਂਦੀ ਹੈ। ਨਤੀਜਾ ਇੱਕ ਐਸੀ ਫੀਚਰ ਬਣਦੀ ਹੈ ਜੋ ਡੈਮੋ ਵਿੱਚ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਹੋ ਸਕਦੀ ਹੈ ਪਰ ਅਸਲ ਵਰਤੋਂ ਵਿੱਚ ਗੈਰ-ਜ਼ਰੂਰੀ ਜਾਂ ਪਰੇਸ਼ਾਨ ਕਰਨ ਵਾਲੀ ਹੋਵੇ।
ਮਾਡਲ ਚੁਣਨ ਜਾਂ ਪ੍ਰੌਂਪਟ ਡਿਜ਼ਾਈਨ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ, ਯੂਜ਼ਰ ਦਾ ਕੰਮ ਸਧਾਰਨ ਭਾਸ਼ਾ ਵਿੱਚ ਲਿਖੋ: ਉਹ ਕੀ ਹਾਸਲ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਰਹੇ ਹਨ, ਕਿਸ ਸੰਦਰਭ ਵਿੱਚ, ਅਤੇ ਅੱਜ ਕਿੰਝ ਮੁਸ਼ਕਲ ਹੈ?
ਫਿਰ ਸਫਲਤਾ ਮਾਪਦੰਡ ਨਿਰਧਾਰਤ ਕਰੋ ਜੋ ਤੁਸੀਂ ਮਾਪ ਸਕੋ। ਉਦਾਹਰਣ: “reply ਸਰੂਪ ਤਿਆਰ ਕਰਨ ਦਾ ਸਮਾਂ 12 ਮਿੰਟ ਤੋਂ 4 ਤੱਕ ਘਟਾਓ,” “ਪਹਿਲੇ ਜਵਾਬ ਦੀ ਗਲਤੀ 2% ਤੋਂ ਘੱਟ ਕਰੋ,” ਜਾਂ “ਫਾਰਮ ਦੀ ਪੂਰਨਤਾ ਦਰ 10% ਵਧਾਓ।” ਜੇ ਤੁਸੀਂ ਮਾਪ ਨਹੀਂ ਕਰ ਸਕਦੇ ਤਾਂ ਪਤਾ ਨਹੀਂ ਲੱਗੇਗਾ ਕਿ AI ਨੇ ਮਦਦ ਕੀਤੀ।
ਸ਼ੁਰੂਆਤੀ ਅਕਸਰ ਇੱਕ ਸਾਰਥਕ ਸਭ-ਜਾਣਿਆ ਸਹਾਇਕ ਬਣਾਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਹਨ। v1 ਲਈ, ਇੱਕ workflow ਦੇ ਇੱਕ ਹੀ ਕਦਮ ਚੁਣੋ ਜਿੱਥੇ AI ਸਪਸ਼ਟ ਮੁੱਲ ਜੋੜ ਸਕਦਾ ਹੈ।
ਚੰਗੇ v1 ਆਮ ਤੌਰ ਤੇ:
ਇਹਨਾ ਦੇ ਨਾਲ-ਨਾਲ ਸਪਸ਼ਟ ਲਿਖੋ ਕਿ v1 ਵਿੱਚ ਕੀ ਨਹੀਂ ਹੋਵੇਗਾ (ਵਧੇਰੇ ਟੂਲ, ਕਈ ਡੇਟਾ ਸਰੋਤ, ਐਜ਼-ਕੇਸ ਓਟੋਮੇਸ਼ਨ)। ਇਸ ਨਾਲ ਸਕੋਪ ਵਾਸਤਵਿਕ ਰਹਿੰਦਾ ਹੈ ਅਤੇ ਸਿੱਖਣ ਤੇਜ਼ ਹੁੰਦਾ ਹੈ।
ਹਰ ਆਊਟਪੁੱਟ ਲਈ ਇੱਕੋ ਜਿਹੀ ਸਹੀਤਾ ਦੀ ਲੋੜ ਨਹੀਂ ਹੁੰਦੀ।
ਇਹ ਲਕਿਰ ਅੱਗੇ ਤੋਂ ਖਿੱਚੋ। ਇਹ ਨਿਰਧਾਰਿਤ ਕਰਦਾ ਹੈ ਕਿ ਤੁਹਾਨੂੰ ਕਿਨ੍ਹਾਂ ਸਖ਼ਤ guardrails, citations, ਮਨੁੱਖੀ ਮਨਜ਼ੂਰੀ ਦੀ ਲੋੜ ਹੈ ਜਾਂ “ਡ੍ਰਾਫਟ ਸਹਾਇਕ” ਹੀ ਕਾਫ਼ੀ ਹੈ।
ਬਹੁਤ ਸਾਰੇ AI ਐਪ ਪ੍ਰੋਜੈਕਟ ਐਸਾ ਹੀ ਸ਼ੁਰੂ ਹੁੰਦੇ ਹਨ: “ਆਓ LLM ਜੋੜੀਏ” ਪਰ ਬੁਨਿਆਦੀ ਪ੍ਰਸ਼ਨ ਨਹੀਂ ਪੁੱਛਦੇ: ਕਿਸ ਨਾਲ ਤੁਲਨਾ ਕਰ ਰਹੇ ਹੋ?
ਜੇ ਤੁਸੀਂ ਮੌਜੂਦਾ ਵਰਕਫਲੋ ਦਸਤਾਵੇਜ਼ ਨਹੀਂ ਕਰਦੇ (ਜਾਂ non-AI ਵਰਜਨ ਨਹੀਂ ਬਣਾਉਂਦੇ), ਤਾਂ ਪਤਾ ਨਹੀਂ ਲੱਗੇਗਾ ਕਿ ਮਾਡਲ ਮਦਦ ਕਰ ਰਿਹਾ ਹੈ, ਨੁਕਸਾਨ ਪਹੁੰਚਾ ਰਿਹਾ ਹੈ, ਜਾਂ ਕੰਮ ਨੂੰ ਇਕ ਥਾਂ ਤੋਂ ਦੂਜੇ ਥਾਂ ਵਗਾ ਰਹਾ ਹੈ। ਟੀਮਾਂ ਨਤੀਜੇ ਦੀ ਥਾਂ ਵਿਚਾਰਾਂ 'ਤੇ ਬਹਸ ਕਰਦੀਆਂ ਹਨ।
ਸਭ ਤੋਂ ਸਧਾਰਣ ਚੀਜ਼ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ ਜੋ ਕੰਮ ਕਰ ਸਕਦੀ:
ਇਹ ਬੇਸਲਾਈਨ ਤੁਹਾਡਾ yardstick ਬਣ ਜਾਂਦਾ ਹੈ ਸਹੀਤਾ, ਰਫਤਾਰ, ਅਤੇ ਯੂਜ਼ਰ ਸੰਤੋਸ਼ ਲਈ। ਇਹ ਇਹ ਵੀ ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਸਮੱਸਿਆ ਦੇ ਕਿਹੜੇ ਹਿੱਸੇ ਵਾਸਤਵ ਵਿੱਚ “ਭਾਸ਼ਾ-ਕਠਿਨ” ਹਨ ਅਤੇ ਕਿਹੜੇ ਸਿਰਫ਼ ਢਾਂਚਾ ਦੀ ਘਾਟ ਹਨ।
ਕੁਝ ਮਾਪਣਯੋਗ ਨਤੀਜੇ ਚੁਣੋ ਅਤੇ ਉਨ੍ਹਾਂ ਨੂੰ ਬੇਸਲਾਈਨ ਅਤੇ AI ਦੋਹਾਂ ਲਈ ਟ੍ਰੈਕ ਕਰੋ:
ਜੇ ਟਾਸਕ ਨਿਰਧਾਰਿਤ ਹੈ (ਫਾਰਮੈਟਿੰਗ, validations, routing, calculations), ਤਾਂ AI ਨੂੰ ਸਿਰਫ਼ ਛੋਟਾ ਹਿੱਸਾ ਸੰਭਾਲਣਾ ਚਾਹੀਦਾ—ਜਿਵੇਂ ਟੋਨ ਰੀਰਾਈਟ—ਅਤੇ rules ਬਾਕੀ ਰੱਖੋ। ਇਕ ਮਜ਼ਬੂਤ ਬੇਸਲਾਈਨ ਇਹ ਸਪਸ਼ਟ ਕਰ ਦਿੰਦੀ ਹੈ ਅਤੇ ਤੁਹਾਡੇ “AI ਫੀਚਰ” ਨੂੰ ਮਹਿੰਗਾ ਔਖਾ ਢੰਗ ਬਣਨ ਤੋਂ ਬਚਾਉਂਦੀ ਹੈ।
ਸ਼ੁਰੂਆਤੀ ਦਰਸਨ ਇੱਕ ਆਮ ਰੁੱਝਾਨ ਹੈ: “ਜੋ ਤੱਕ ਚੱਲੇ ਉਹ ਤੱਕ ਪ੍ਰੌਂਪਟ ਕਰੋ”: ਇੱਕ ਵਾਕ ਦੀ ਤਬਦੀਲੀ, ਇੱਕ ਵਾਰੀ ਬਿਹਤਰ ਜਵਾਬ ਮਿਲਣਾ, ਅਤੇ ਸੋਚਣਾ ਕਿ ਮਸਲਾ ਹੱਲ ਹੋ ਗਿਆ। ਸਮੱਸਿਆ ਇਹ ਹੈ ਕਿ ਅਣ-ਸੰਰਚਿਤ ਪ੍ਰੌਂਪਟ ਵੱਖ-ਵੱਖ ਯੂਜ਼ਰਾਂ, ਐਡਜ ਕੇਸ, ਅਤੇ ਮਾਡਲ ਅੱਪਡੇਟਸ 'ਤੇ ਵੱਖਰੇ ਤਰੀਕੇ ਨਾਲ ਵਰਤਦੇ ਹਨ। ਜੋ ਇੱਕ ਵਾਰੀ ਚੰਗਾ ਲੱਗਾ, ਸੱਚੇ ਡੇਟਾ ਦੇ ਆਉਂਦੇ ਹੀ ਅਣਪ੍ਰਡਿਕਟੇਬਲ ਹੋ ਸਕਦਾ ਹੈ।
ਉਮੀਦ ਕਰਨ ਦੀ ਥਾਂ ਕਿ ਮਾਡਲ “ਸਮਝ ਲਏਗਾ”, ਕੰਮ ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ ਨਿਰਧਾਰਤ ਕਰੋ:
ਇਸ ਨਾਲ ਇਕ ਅਸਪਸ਼ਟ ਬੇਨਤੀ ਇੱਕ ਟੈਸਟਯੋਗ ਅਤੇ ਨਿਰਧਾਰਤ ਚੀਜ਼ ਬਣ ਜਾਂਦੀ ਹੈ।
ਕਠਨ ਕੇਸਾਂ ਲਈ ਕੁਝ ਚੰਗੇ ਉਦਾਹਰਣ ("ਜਦ ਯੂਜ਼ਰ ਐਸ ਪੁੱਛਦਾ ਹੈ, ਜਵਾਬ ਐਸ ਦੀ ਤਰ੍ਹਾਂ ਹੋਵੇ") ਅਤੇ ਘੱਟੋ-ਘੱਟ ਇੱਕ counter-example ਸ਼ਾਮਲ ਕਰੋ ("ਇਹ ਨਾ ਕਰੋ")। counter-examples ਉਹਨਾਂ ਭਰੋਸੇਯੋਗ ਪਰ ਗਲਤ ਜਵਾਬਾਂ, ਜਿਵੇਂ ਨਾਹ-ਹੋਣ ਵਾਲੇ ਨੰਬਰ ਬਣਾਉਣਾ ਜਾਂ ਗੈਰ-ਮੌਜੂਦ ਦਸਤਾਵੇਜ਼ਾਂ ਦਾ ਹਵਾਲਾ ਦੇਣਾ, ਨੂੰ ਘੱਟ ਕਰਨ ਵਿੱਚ ਖਾਸ ਕਰਕੇ ਮਦਦਗਾਰ ਹਨ।
ਪ੍ਰੌਂਪਟਸ ਨੂੰ ਆਸੈਟ ਵਾਂਗ ਟ੍ਰੀਟ ਕਰੋ: ਉਨ੍ਹਾਂ ਨੂੰ version control ਵਿੱਚ ਰੱਖੋ, ਨਾਂ ਦਿਓ, ਅਤੇ ਛੋਟੀ ਚੇਂਜਲੌਗ ਰੱਖੋ (ਕੀ ਬਦਲਿਆ, ਕਿਉਂ, ਆਸਰ ਦਿਖਾਓ)। ਜਦ ਗੁਣਵੱਤਾ ਘੱਟਦੀ ਹੈ, ਤੁਸੀਂ ਤੇਜ਼ੀ ਨਾਲ rollback ਕਰ ਸਕੋਗੇ—ਅਤੇ ਸਾਡੇ ਯਾਦاشت ਤੋਂ “ਉਹ ਪ੍ਰੌਂਪਟ ਜੋ ਅਖ਼ੀਰਲੇ ਹਫ਼ਤੇ ਵਰਤੀ ਗਈ” ਬਾਰੇ ਜਹਿਰ ਖਤਮ ਹੋ ਜਾਵੇਗਾ।
ਆਮ ਸ਼ੁਰੂਆਤੀ ਗਲਤੀ ਇਹ ਹੈ ਕਿ LLM ਨੂੰ ਕੰਪਨੀ-ਖਾਸ ਤੱਥ ਪੁੱਛੇ ਜਾਣ: ਮੌਜੂਦਾ ਪ੍ਰਾਈਸਿੰਗ ਨਿਯਮ, ਅੰਤਰਿਕ ਨੀਤੀਆਂ, ਤਾਜ਼ਾ ਰੋਡਮੈਪ, ਜਾਂ ਤੁਹਾਡੇ ਸਪੋਰਟ ਟੀਮ ਦੇ ਹਥਿਆਰ। ਮਾਡਲ ਕਈ ਵਾਰੀ ਯਕੀਨੀ ਜਵਾਬ ਦੇਵੇਗਾ—ਅਤੇ ਇੰਜ ਗਲਤ ਸਲਾਹ ਜਨਮ ਲੈਂਦੀ ਹੈ।
LLM ਨੂੰ ਭਾਸ਼ਾਈ ਪੈਟਰਨ, ਦਿੱਤੇ ਸੰਦਰਭ 'ਤੇ ਸੰਖੇਪ ਕਰਨ, ਦੁਬਾਰਾ ਲਿਖਣ ਅਤੇ ਤਰਕ ਕਰਨ ਵਿੱਚ ਮਾਹਿਰ ਸਮਝੋ। ਇਹ ਤੁਹਾਡੀ ਜੀਵੰਤ ਡੇਟਾਬੇਸ ਨਹੀਂ ਹੈ। ਭਾਵੇਂ ਇਹ ਨੇਮਾਂਦਾਜ਼ੀ ਦੌਰਾਨ ਸਮਾਨ ਕਾਰੋਬਾਰ ਵੇਖੇ ਹਨ, ਇਹ ਤੁਹਾਡੀ ਤाज़ਾ ਹਕੀਕਤ ਨਹੀਂ ਜਾਣੇਗਾ।
ਇੱਕ ਲਾਭਕਾਰੀ ਮਾਨਸਿਕ ਮਾਡਲ:
ਜੇ ਜਵਾਬ ਨੂੰ ਤੁਹਾਡੀ ਅੰਤਰਿਕ ਹਕੀਕਤ ਨਾਲ ਮਿਲਣਾ ਲਾਜ਼ਮੀ ਹੈ, ਤਾਂ ਤੁਹਾਨੂੰ ਉਹ ਸੱਚਾਈ ਦੈਣੀ ਪਏਗੀ।
ਜੇ ਤੁਸੀਂ RAG ਜੋੜਦੇ ਹੋ, ਤਾਂ ਇਸਨੂੰ “ਆਪਣਾ ਕੰਮ ਦਿਖਾਓ” ਸਿਸਟਮ ਵਾਂਗ ਸਮਝੋ। ਮਨਜ਼ੂਰ ਕੀਤੇ ਸਰੋਤਾਂ ਤੋਂ ਵਿਸ਼ੇਸ਼ ਪੈਸਾਜ਼ ਪ੍ਰਾਪਤ ਕਰੋ ਅਤੇ ਅਸਿਸਟੈਂਟ ਨੂੰ ਉਹਨਾਂ ਦੀ citation ਕਰਨੀ ਲਾਜ਼ਮੀ ਕਰੋ। ਜੇ ਤੁਸੀਂ ਨੂੰ cite ਨਹੀਂ ਕਰ ਸਕਦੇ, ਤਾਂ ਤੱਥ ਵਜੋਂ ਪੇਸ਼ ਨਾ ਕਰੋ।
ਇਸ ਨਾਲ ਤੁਹਾਡੇ ਪ੍ਰੌਂਪਟ ਦਾ ਤਰੀਕਾ ਵੀ ਬਦਲਦਾ ਹੈ: “ਸਾਡੇ ਰਿਫੰਡ ਪਾਲਿਸੀ ਕੀ ਹੈ?”ਦੀ ਥਾਂ ਪੁੱਛੋ “ਲਗਾਈ ਹੋਈ ਨੀਤੀ ਉਦੇਸ਼ਵਾਕ ਤੋਂ ਰਿਫੰਡ ਨੀਤੀ ਨੂੰ ਸਮਝਾਓ ਅਤੇ ਸੰਬੰਧਿਤ ਲਾਈਨਾਂ quote ਕਰੋ।”
ਅਣਿਸ਼ਚਿੱਤਤਾ ਲਈ ਸਪਸ਼ਟ ਬਿਹੇਵਿਅਰ ਬਣਾਓ: “ਜੇ ਤੁਸੀਂ ਦਿੱਤੇ ਸਰੋਤਾਂ ਵਿੱਚ ਜਵਾਬ ਨਾ ਲੱਭ ਸਕੋ ਤਾਂ ਕਹੋ ਕਿ ਤੁਹਾਨੂੰ ਪਤਾ ਨਹੀਂ ਅਤੇ ਅਗਲੇ ਕਦਮ ਸੁਝਾਓ।” ਚੰਗੇ fallback ਵਿੱਚ ਮਨੁੱਖੀ ਹੇਠਾਂ-ਹਥਿਆਰ ਸੰਦੇਸ਼, ਖੋਜ ਪੰਨਾ, ਜਾਂ ਛੋਟੀ ਸਪਸ਼ਟੀਕਰਨ ਬੇਨਤੀ ਸ਼ਾਮਲ ਹੋ ਸਕਦੀ ਹੈ। ਇਹ ਯੂਜ਼ਰਾਂ ਦੀ ਰੱਖਿਆ ਕਰਦਾ ਹੈ—ਅਤੇ ਤੁਹਾਡੇ ਟੀਮ ਨੂੰ ਬਾਅਦ ਵਿੱਚ confident mistakes ਸਾਫ ਕਰਨ ਤੋਂ ਬਚਾਉਂਦਾ ਹੈ।
RAG (Retrieval-Augmented Generation) AI ਐਪ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ “ਜ਼ਿਆਦਾ ਸਮਝਦਾਰ” ਮਹਿਸੂਸ ਕਰਵਾ ਸਕਦਾ ਹੈ: ਦਸਤਾਵੇਜ਼ ਜੋੜੋ, ਕੁਝ “ਸੰਬੰਧਿਤ” chunks ਪ੍ਰਾਪਤ ਕਰੋ, ਅਤੇ ਮਾਡਲ ਨੂੰ ਜਵਾਬ ਦੇਣ ਦਿਓ। ਸ਼ੁਰੂਆਤੀ ਫੇਲ ਇਹ ਗਲਤੀ ਹੁੰਦੀ ਹੈ ਕਿ retrieval ਆਪੇ accuracy ਦੀ ਗਾਰੰਟੀ ਦਿੰਦਾ ਹੈ।
ਜ਼ਿਆਦਾਤਰ RAG ਫੇਲੂਅਰ ਮਾਡਲ ਦੇ ਖਰਾਬ hallucination ਨਹੀਂ ਹੁੰਦੇ—ਇਹ ਸਿਸਟਮ ਨੂੰ ਗਲਤ ਸੰਦਰਭ ਪਸ ਕੀਤਾ ਗਿਆ ਹੋਂਦਾ ਹੈ।
ਆਮ ਮੁੱਦੇ ਸ਼ਾਮਲ ਹਨ: ਖਰਾਬ chunking (ਟੈਕਸਟ ਨੂੰ ਵਿਚਕਾਰ ਤੋਂ ਵੰਡ ਦੇਣਾ, definitions ਖੋ ਦੇਣਾ), ਗੈਰ-ਸੰਬੰਧਿਤ retrieval (top results ਸਿਰਫ਼ ਕੀਵਰਡ ਮਿਲਦੇ ਹਨ ਪਰ ਅਰਥ ਨਹੀਂ), ਅਤੇ ਪੁਰਾਣੇ ਦਸਤਾਵੇਜ਼ (ਸਿਸਟਮ ਪਿਛਲੇ ਕਵਾਰਟਰ ਦੀ ਨੀਤੀ quote ਕਰ ਰਿਹਾ ਹੈ)। ਜਦ retrieved context ਕਮਜ਼ੋਰ ਹੁੰਦੀ ਹੈ, ਮਾਡਲ ਫਿਰ ਵੀ ਯਕੀਨੀ ਜਵਾਬ ਦਿੰਦਾ—ਸਿਰਫ਼ noise ਤੇ ਅਧਾਰਿਤ।
retrieval ਨੂੰ search ਵਾਂਗ ਸਮਝੋ: ਇਸ ਨੂੰ ਕੁਆਲਟੀ ਕੰਟਰੋਲ ਦੀ ਲੋੜ ਹੈ। ਕੁਝ ਪ੍ਰਯੋਗੀ ਪੈਟਰਨ:
ਜੇ ਤੁਹਾਡੀ ਐਪ ਫੈਸਲਿਆਂ ਲਈ ਵਰਤੀ ਜਾ ਰਹੀ ਹੈ ਤਾਂ ਯੂਜ਼ਰਾਂ ਨੂੰ ਜਾਂਚਣ ਦੀ ਲੋੜ ਹੈ। ਹਰ ਤੱਥੀ ਦਾਅਵੇ ਲਈ ਸਰੋਤ excerpt, ਦਸਤਾਵੇਜ਼ ਦਾ ਨਾਮ, ਅਤੇ last-updated ਤਾਰੀਖ ਦਿਖਾਉਣ ਦੀ ਮੰਗ ਕਰੋ। UI ਵਿੱਚ ਸਰੋਤ ਦਿਖਾਓ ਅਤੇ referenced ਸੈਕਸ਼ਨ ਖੋਲ੍ਹਣਾ ਆਸਾਨ ਬਣਾਓ।
ਦੋ ਤੇਜ਼ ਟੈਸਟ ਬਹੁਤ ਕੁਝ ਫੜ ਲੈਂਦੇ ਹਨ:
ਜੇ ਸਿਸਟਮ ਭਰੋਸੇਯੋਗ ਤਰੀਕੇ ਨਾਲ retrieve ਅਤੇ cite ਨਹੀਂ ਕਰ ਸਕਦਾ, ਤਾਂ RAG ਸਿਰਫ਼ complexity ਜੋੜ ਰਿਹਾ ਹੈ—ਭਰੋਸਾ ਨਹੀਂ।
ਅਨੇਕ ਸ਼ੁਰੂਆਤੀ ਟੀਮ ਇੱਕ-ਦੋ “ਚੰਗੇ ਲੱਗ ਰਹੇ” ਡੈਮੋਜ਼ ਤੋਂ ਬਾਅਦ AI ਫੀਚਰ ਸ਼ਿਪ ਕਰ ਦਿੰਦੀਆਂ ਹਨ। ਨਤੀਜਾ ਪੇਸ਼ਗੋਈਯੋਗ ਹੈ: ਪਹਿਲੇ ਅਸਲ ਯੂਜ਼ਰ ਐਡਜ ਕੇਸ, ਫਾਰਮੈਟਿੰਗ ਦੀਆਂ ਟੁੱਟਾਂ, ਜਾਂ ਮਾਡਲ ਦਾ ਯਕੀਨ ਨਾਲ ਗਲਤ ਜਵਾਬ— ਅਤੇ ਤੁਹਾਡੇ ਕੋਲ ਇਹ ਮਾਪਣ ਲਈ ਕੋਈ ਢਾਂਚਾ ਨਹੀਂ ਰਹਿ ਜਾਂਦਾ ਕਿ ਇਹ ਕਿੰਨਾ ਬੁਰਾ ਹੈ ਜਾਂ ਇਹ ਸੁਧਰ ਰਿਹਾ ਹੈ।
ਜੇ ਤੁਸੀਂ ਇੱਕ ਛੋਟਾ ਟੈਸਟ ਸੈੱਟ ਅਤੇ ਕੁਝ ਮੈਟ੍ਰਿਕਸ ਨਹੀਂ ਪਰਿਭਾਸ਼ਿਤ ਕਰਦੇ, ਤਾਂ ਹਰ ਪ੍ਰੌਂਪਟ ਟਵਿਕ ਜਾਂ ਮਾਡਲ ਅੱਪਗ੍ਰੇਡ ਇੱਕ ਜੁਆ ਬਣ ਜਾਂਦਾ ਹੈ। ਤੁਸੀਂ ਇੱਕ ਸੇਨਰੀਓ ਠੀਕ ਕਰ ਸਕਦੇ ਹੋ ਅਤੇ ਪੰਜ ਹੋਰਾਂ ਨੂੰ ਚੁਪ ਚਾਪ ਖਰਾਬ ਕਰ ਸਕਦੇ ਹੋ।
ਤੁਹਾਨੂੰ ਹਜ਼ਾਰਾਂ ਉਦਾਹਰਣਾਂ ਦੀ ਲੋੜ ਨਹੀਂ। 30–100 ਵਾਸਤਵਿਕ-ਨੁਮਾਇੰਦਗੀ ਕੇਸ ਜੋ ਯੂਜ਼ਰ ਵਾਸਤਵ ਵਿੱਚ ਪੁੱਛਦੇ ਹਨ, ਉਸ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ, ਜਿਸ ਵਿੱਚ:
ਉਮੀਦ ਕੀਤੀ “ਚੰਗੀ” ਵਿਹਾਰ (ਜਵਾਬ + ਲਾਜ਼ਮੀ ਫਾਰਮੈਟ + ਅਣਿਸ਼ਚਿਤ ਹੋਣ 'ਤੇ ਕੀ ਕਰਨਾ) ਸਟੋਰ ਕਰੋ।
ਤਿੰਨ ਚੈਕਸ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ ਜੋ ਯੂਜ਼ਰ ਤਜਰਬੇ ਨਾਲ ਜੁੜੇ ਹਨ:
ਸਧਾਰਨ ਰਿਲੀਜ਼ ਗੇਟ ਸ਼ਾਮਲ ਕਰੋ: ਕੋਈ ਵੀ ਪ੍ਰੌਂਪਟ/ਮਾਡਲ/ਕੰਫਿਗ ਬਦਲਾਅ ਤਦ ਤੱਕ ਲਾਈਵ ਨਹੀਂ ਜਾਵੇ ਜਦ ਤੱਕ ਉਹ ਇਕੋ ਹੀ ਮੁਲਾਂਕਣ ਸੈੱਟ 'ਤੇ ਪਾਸ ਨਾ ਹੋਵੇ। CI ਵਿੱਚ ਇੱਕ ਹਲਕਾ ਸਕ੍ਰਿਪਟ ਵੀ ਕਾਫ਼ੀ ਹੈ ਤਾਂ ਕਿ “ਅਸੀਂ ਇਸਨੂੰ ਠੀਕ ਕੀਤਾ… ਅਤੇ ਟੁੱਟਿਆ” ਲੂਪ ਰੁਕ ਸਕੇ।
ਜੇ ਤੁਹਾਨੂੰ ਇੱਕ ਸ਼ੁਰੂਆਤਿਕ ਬਿੰਦੂ ਚਾਹੀਦਾ ਹੈ, ਤਾਂ ਇੱਕ ਸਧਾਰਨ ਚੈਕਲਿਸਟ ਬਣਾਓ ਅਤੇ ਇਸਨੂੰ ਆਪਣੇ ਡਿਪਲੋਇਮੈਂਟ ਪ੍ਰਕਿਰਿਆ ਦੇ ਕੋਲ ਰੱਖੋ (LLM ਮੁਲਾਂਕਣ ਬੁਨਿਆਦੀ ਸidhਾਂਤਾਂ ਬਾਰੇ ਦੇਖੋ)।
ਬਹੁਤ ਸਾਰੀਆਂ ਸ਼ੁਰੂਆਤੀ AI ਡਿਵੈਲਪਮੈਂਟ ਡੈਮੋ ਵਿੱਚ ਬਹਿਤਰੀਨ ਦਿਖਾਈ ਦਿੰਦੀਆਂ ਹਨ: ਇੱਕ ਸਾਫ ਪ੍ਰੌਂਪਟ, ਇੱਕ ਪੂਰਾ ਉਦਾਹਰਣ, ਇੱਕ ਆਦਰਸ਼ ਆਊਟਪੁੱਟ। ਮੁੱਦਾ ਇਹ ਹੈ ਕਿ ਯੂਜ਼ਰ ਡੈਮੋ ਸਕ੍ਰਿਪਟ ਵਰਗਾ ਵਰਤਦੇ ਨਹੀਂ। ਜੇ ਤੁਸੀਂ ਸਿਰਫ਼ “ਖੁਸ਼ ਰਸਤਾ” ਟੈਸਟ ਕਰੋਗੇ, ਤਾਂ ਅਸਲ ਇਨਪੁੱਟ ਮਿਲਦੇ ਹੀ ਸਿਸਟਮ ਟੁੱਟੇਗਾ।
ਉਤਪਾਦ-ਸਮਾਨ ਸਿੰਨਰੀਓ ਵਿੱਚ ਗੰਦਗੀ ਡੇਟਾ, ਰੁਕਾਵਟਾਂ, ਅਤੇ ਅਣਪ੍ਰਡਿਕਟੇਬਲ ਸਮਾਂ-ਅੰਤਰ ਸ਼ਾਮਲ ਹਨ। ਤੁਹਾਡਾ ਟੈਸਟ ਸੈੱਟ ਅਸਲ ਵਰਤੋਂ ਨੂੰ ਦਰਸਾਉਣਾ ਚਾਹੀਦਾ: ਵਾਸਤਵਿਕ ਯੂਜ਼ਰ ਸਵਾਲ, ਅਸਲ ਦਸਤਾਵੇਜ਼, ਅਤੇ ਅਸਲ ਸੀਮਾਵਾਂ (ਟੋਕਨ ਸੀਮਾਵਾਂ, ਸੰਦਰਭ ਵਿਂਡੋਜ਼, ਨੈੱਟਵਰਕ ਹਿਕਸ)।
ਐਡਜ ਕੇਸ ਉਹ ਹਨ ਜਿੱਥੇ ਹੈਲੂਸੀਨੇਸ਼ਨ ਅਤੇ ਭਰੋਸੇਯੋਗਤਾ ਸਮੱਸਿਆਵਾਂ ਪਹਿਲਾਂ ਦਿਖਾਈ ਦਿੰਦੀਆਂ ਹਨ। ਇਹ ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਤੁਸੀਂ ਟੈਸਟ ਕਰੋ:
ਇੱਕ ਬੇਨਤੀ ਦਾ ਕੰਮ ਕਰ ਜਾਣਾ ਕਾਫ਼ੀ ਨਹੀਂ। ਉੱਚ concurrency, retries, ਅਤੇ ਮਾਡਲ ਦੇ ਧੀਰੇ ਜਵਾਬਾਂ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰੋ। p95 latency ਮਾਪੋ ਅਤੇ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਜਦ ਜਵਾਬ ਲੰਮਾ ਹੋਵੇ ਤਾਂ ਵੀ UX ਸਮਝਦਾਰ ਹੈ।
ਮਾਡਲ ਟਾਈਮਆਊਟ ਹੋ ਸਕਦਾ, retrieval ਕੁਝ ਨਹੀਂ ਲੈਕੇ ਆ ਸਕਦੀ, ਅਤੇ APIs rate limit ਹੋ ਸਕਦੇ ਹਨ। ਹਰ ਹālਤ ਵਿੱਚ ਤੁਹਾਡੀ ਐਪ ਕੀ ਕਰੇਗੀ: “ਜਵਾਬ ਨਹੀਂ ਦੇ ਸਕਦਾ” ਦਰਸਾਓ, ਸਧਾਰਨ ਢੰਗ ਵੱਲ fallback ਕਰੋ, ਇੱਕ ਸਪਸ਼ਟੀਕਰਨ ਪੁੱਛੋ, ਜਾਂ ਜੌਬ ਕਤਾਰ ਵਿੱਚ ਰੱਖੋ। ਜੇ ਫੇਲ ਹālਤਾਂ ਡਿਜ਼ਾਈਨ ਨਹੀਂ ਕੀਤੀਆਂ ਤਾਂ ਯੂਜ਼ਰ ਖਾਮੋਸ਼ੀ ਨੂੰ “AI ਗਲਤ ਹੈ” ਵਜੋਂ ਸਮਝਣਗੇ ਬਜਾਏ “ਸਿਸਟਮ ਵਿੱਚ ਸਮੱਸਿਆ ਆਈ” ਨੂੰ ਸਮਝਣ ਦੇ।
ਬਹੁਤ ਸਾਰੀਆਂ ਸ਼ੁਰੂਆਤੀ AI ਐਪ ਇਸ ਲਈ ਫੇਲ ਹੁੰਦੀਆਂ ਹਨ ਕਿ ਇੰਟਰਫੇਸ ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਆਊਟਪੁੱਟ ਹਰ ਵਾਰੀ ਸਹੀ ਹੈ। ਜਦ UI ਅਣਿਸ਼ਚਿੱਤਤਾ ਅਤੇ ਸੀਮਾਵਾਂ ਛੁਪਾਉਂਦਾ ਹੈ, ਯੂਜ਼ਰ ਜਾਂ ਤਾਂ AI 'ਤੇ ਅਧਿਕ ਭਰੋਸਾ ਕਰ ਲੈਂਦੇ ਹਨ (ਅਤੇ ਨੁਕਸਾਨ ਹੁੰਦਾ ਹੈ) ਜਾਂ ਸਾਰਾ ਭਰੋਸਾ ਖਤਮ ਕਰ ਦਿੰਦੇ ਹਨ।
ਅਨੁਭਵ ਨੂੰ ਇਸ ਤਰ੍ਹਾਂ ਡਿਜ਼ਾਈਨ ਕਰੋ ਕਿ ਜਾਂਚ ਕਰਨੀ ਆਸਾਨ ਅਤੇ ਤੇਜ਼ ਹੋਵੇ। ਉਪਯੋਗੀ ਪੈਟਰਨ ਸ਼ਾਮਲ ਹਨ:
ਜੇ ਤੁਹਾਡੀ ਐਪ ਸਰੋਤ ਨਹੀਂ ਦੇ ਸਕਦੀ, ਤਾਂ ਸਫਾਈ ਨਾਲ ਕਹੋ ਅਤੇ UX ਨੂੰ ਸੁਰੱਖਿਅਤ ਆਊਟਪੁੱਟ ਵੱਲ ਮੋੜੋ (ਜਿਵੇਂ ਡਰਾਫਟ, ਸੁਝਾਅ, ਜਾਂ ਵਿਕਲਪ), ਨਾ ਕਿ authoritative ਬਿਆਨਾਂ ਵੱਲ।
ਇਨਪੁੱਟ ਅਧੂਰਾ ਹੋਣ 'ਤੇ, ਬੇਹਤਰੀਨ ਹੈ ਕਿ ਬੇਧੜਕ ਜਵਾਬ ਨਾ ਦਿਓ। ਇੱਕ-ਦੋ ਸਪਸ਼ਟੀਕਰਨ ਸਵਾਲ ਸ਼ਾਮਲ ਕਰੋ ("ਕਿਹੜਾ ਖੇਤਰ?", "ਕਿੰਨੇ ਸਮੇਂ ਦੀ ਗੱਲ?", "ਕਿਹੜਾ ਟੋਨ?")। ਇਸ ਨਾਲ hallucinations ਘੱਟ ਹੁੰਦੇ ਹਨ ਅਤੇ ਯੂਜ਼ਰ ਮਹਿਸੂਸ ਕਰਦਾ ਹੈ ਕਿ ਸਿਸਟਮ ਉਸ ਨਾਲ ਕੰਮ ਕਰ ਰਿਹਾ ਹੈ, ਨਾਂ ਕਿ ਚਾਲਾਕੀ ਕਰ ਰਿਹਾ ਹੈ।
ਭਰੋਸਾ ਵਧਦਾ ਹੈ ਜਦ ਯੂਜ਼ਰ ਭਵਿੱਖਬਾਣੀ ਕਰ ਸਕਦੇ ਹਨ ਅਤੇ ਗਲਤੀਆਂ ਤੋਂ ਬਚ ਸਕਦੇ ਹਨ:
ਉਦੇਸ਼ ਇਹ ਨਹੀਂ ਕਿ ਉਪਭੋਗਤਾ ਨੂੰ ਥੱਲੇ ਲਿਆਂਣਾ—ਸਗੋਂ ਇਹ ਕਿ ਸਹੀ ਹੋਣਾ ਤੇਜ਼ ਰਸਤਾ ਹੋਵੇ।
ਬਹੁਤ ਸਾਰੀਆਂ ਸ਼ੁਰੂਆਤੀ AI ਐਪ ਫੇਲ ਹੁੰਦੀਆਂ ਹਨ ਨਾਂ ਕਿ ਮਾਡਲ ਖਰਾਬ ਹੈ, ਬਲਕਿ ਇਸ ਲਈ ਕਿ ਕਿਸੇ ਨੇ ਨਿਰਧਾਰਤ ਨਹੀਂ ਕੀਤਾ ਕਿ ਕੀ ਨਹੀਂ ਹੋਣਾ ਚਾਹੀਦਾ। ਜੇ ਤੁਹਾਡੀ ਐਪ ਹਾਨਿਕਾਰਕ ਸਲਾਹ ਦੇ ਸਕਦੀ ਹੈ, ਨਿੱਜੀ ਡੇਟਾ ਪ੍ਰਗਟ ਕਰ ਸਕਦੀ ਹੈ, ਜਾਂ ਸੰਵੇਦਨਸ਼ੀਲ ਦਾਵੇ ਬਣ ਸਕਦੇ ਹਨ, ਤਾਂ ਇਹ ਕੇਵਲ ਕੁਆਲਟੀ ਦੀ ਸਮੱਸਿਆ ਨਹੀਂ—ਇਹ ਭਰੋਸਾ ਅਤੇ ਜ਼ਿੰਮੇਵਾਰੀ ਦੀ ਸਮੱਸਿਆ ਹੈ।
ਸਧਾਰਨ “refuse or escalate” ਨੀਤੀ ਸਧਾਰਨ ਭਾਸ਼ਾ ਵਿੱਚ ਲਿਖੋ। ਐਪ ਨੂੰ ਕੀ ਤਿਆਗਣਾ ਚਾਹੀਦਾ (ਸੁਆਇ-ਹਮਲਿਆਂ ਦੀ ਹਦਾਇਤ, ਗੈਰ-ਕਾਨੂੰਨੀ ਕਿਰਿਆਵਾਂ, ਮੈਡੀਕਲ ਜਾਂ ਕਾਨੂੰਨੀ ਹੁਕਮ, ਹراسਮੈਂਟ) ਅਤੇ ਕੀ ਮਨੁੱਖੀ ਸਮੀਖਿਆ-trigger ਕਰੇ (ਅਕਾਊੰਟ ਬਦਲਾਅ, ਉੱਚ-ਬਦਲਾਅ ਸਿਫਾਰਸ਼ਾਂ, ਨਾਬਾਲਿਕ ਸਬੰਧੀ ਮਾਮਲੇ) — ਇਹ ਨੀਤੀ ਪ੍ਰੋਡਕਟ ਵਿੱਚ ਲਾਗੂ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ, ਕਿਸੇ ਉਮੀਦ ਤੇ ਨਹੀਂ ਛੱਡੀ ਜਾਵੇ।
ਮੰਨੋ ਕਿ ਯੂਜ਼ਰ ਨਿੱਜੀ ਡੇਟਾ ਪੇਸਟ ਕਰਨਗੇ—ਨਾਂ, ਇਨ੍ਹਾਂ ਵਿੱਚ ਨਾਮ, ਈਮੇਲ, ਇਨਵਾਇਸ, ਸਿਹਤ ਵੇਰਵੇ ਆ ਸਕਦੇ ਹਨ।
ਜੋ ਕੁਝ ਤੁਸੀਂ ਇਕੱਤਰ ਕਰਦੇ ਹੋ ਉਹ ਘਟਾਓ, ਅਤੇ ਜੇ ਜਰੂਰੀ ਨਾ ਹੋਵੇ ਤਾਂ ਰਾਉ-ਇਨਪੁੱਟ ਸਟੋਰ ਨਾ ਕਰੋ। ਲੋਗਿੰਗ ਜਾਂ ਅੱਗੇ ਭੇਜਣ ਤੋਂ ਪਹਿਲਾਂ ਸੰਵੇਦਨਸ਼ੀਲ ਫੀਲਡਜ਼ redact ਜਾਂ tokenize ਕਰੋ। ਜੇ ਡੇਟਾ ਸਟੋਰ ਕੀਤਾ ਜਾਂ ਤ੍ਰੇਨਿੰਗ ਲਈ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ ਤਾਂ ਸਪਸ਼ਟ ਸਹਿਮਤੀ ਮੰਗੋ।
ਅਪਵਾਦ ਲਈ ਲੋਗ ਚਾਹੀਦੇ ਹੋਣਗੇ, ਪਰ ਲੋਗ ਵੀ ਲੀਕ ਬਣ ਸਕਦੇ ਹਨ।
ਉੱਚ-ਖਤਰੇ ਐਪ ਲਈ audit trails ਅਤੇ review ਵਰਕਫਲੋਜ਼ ਜੁੜੋ ਤਾਂ ਕਿ ਤੁਸੀਂ ਸਾਬਤ ਕਰ ਸਕੋ ਕਿਸ ਨੇ ਕਿਸ ਹਾਲਤ ਵਿੱਚ ਕੀ ਵੇਖਿਆ।
ਸੁਰੱਖਿਆ, ਗੋਪਨੀਯਤਾ ਅਤੇ ਕਾਮਪਲਾਇੰਸ ਫਾਇਲਾਂ ਨਹੀਂ—ਇਹ ਪ੍ਰੋਡਕਟ ਲੋੜਾਂ ਹਨ।
ਇੱਕ ਆਮ ਸ਼ੁਰੂਆਤੀ ਹੈਰਾਨੀ ਇਹ ਹੁੰਦੀ ਹੈ: ਡੈਮੋ ਤੁਰੰਤ ਤੇ ਸਸਤਾ ਲੱਗਦਾ ਹੈ, ਫਿਰ ਅਸਲ ਵਰਤੋਂ ਧੀਮੀ ਅਤੇ ਮਹਿੰਗੀ ਹੋ ਜਾਂਦੀ ਹੈ। ਇਹ ਆਮ ਤੌਰ ਤੇ ਹੁੰਦਾ ਹੈ ਕਿਉਂਕਿ token ਵਰਤੋਂ, retries, ਅਤੇ “ਸਿੱਧਾ ਵੱਡੇ ਮਾਡਲ 'ਤੇ ਸੁਇਚ ਕਰੋ” ਦੇ ਫੈਸਲੇ ਅਣਕਾਬੂ ਛੱਡੇ ਜਾਂਦੇ ਹਨ।
ਸਭ ਤੋਂ ਵੱਡੇ drivers ਆਮ ਤੌਰ 'ਤੇ:
ਪ੍ਰੋਟੋਟਾਈਪ ਲਈ ਵੀ ਸਪਸ਼ਟ ਬਜਟ ਮੁਕਰਰ ਕਰੋ:
ਸਾਥ ਹੀ prompts ਅਤੇ retrieval ਇਸ ਤਰ੍ਹਾਂ ਤਿਆਰ ਕਰੋ ਕਿ ਤੁਸੀਂ ਬੇਲੋੜੀ ਟੈਕਸਟ ਨਾ ਭੇਜੋ। ਉਦਾਹਰਣ ਲਈ, ਪੁਰਾਣੇ ਗੱਲਾਂ ਦਾ ਸੰਖੇਪ ਭੇਜੋ ਅਤੇ ਸਾਰਥਕ snippets ਹੀ ਅਟੈਚ ਕਰੋ ਨਾਂ ਕਿ ਪੂਰੀ ਫ਼ਾਈਲ।
"cost per request" optimize ਨਾ ਕਰੋ। cost per successful task optimize ਕਰੋ (ਜਿਵੇਂ “ਜਾਰੀ ਕੀਤਾ ਗਿਆ ਮੁੱਦਾ ਹੱਲ ਹੋਇਆ”, “ਡਰਾਫਟ ਮਨਜ਼ੂਰ ਹੋਇਆ”, “ਸਵਾਲ citation ਨਾਲ ਜਵਾਬ ਮਿਲਿਆ”)। ਇੱਕ ਸਸਤਾ ਰਿਕੁਏਸਟ ਜੋ ਦੋ ਵਾਰੀ fail ਹੋ ਰਿਹਾ ਹੈ, ਇੱਕ ਥੋੜ੍ਹਾ ਮਹਿੰਗਾ ਪਰ ਸਹੀ ਰਿਕੁਏਸਟ ਤੋਂ ਬਹੁਤ ਮਹਿੰਗਾ ਹੋ ਸਕਦਾ ਹੈ।
ਜੇ ਤੁਸੀਂ ਪ੍ਰਾਇਸਿੰਗ ਟੀਅਰ ਸੋਚ ਰਹੇ ਹੋ, ਤਾਂ ਸ਼ੁਰੂ ਤੋਂ ਹੀ ਸੀਮਾਵਾਂ ਦਾ ਖਾਕਾ ਬਣਾਓ ਤਾਂ ਕਿ ପਰਫਾਰਮੈਂਸ ਅਤੇ ਯੂਨਿਟ ਅਰਥਸ਼ਾਸਤਰ ਬਾਅਦ ਵਿੱਚ afterthought ਨਾ ਬਣ ਜਾਣ।
ਬਹੁਤ ਸਾਰੇ ਸ਼ੁਰੂਆਤੀ ਲੋਗ ਲੋਗ ਇਕੱਠੇ ਕਰਦੇ ਹਨ—ਫਿਰ ਉਨ੍ਹਾਂ ਨੂੰ ਨਹੀਂ ਵੇਖਦੇ। ਐਪ ਹੌਲੀ-ਹੌਲੀ ਖਰਾਬ ਹੋ ਜਾਂਦਾ ਹੈ, ਯੂਜ਼ਰ ਇਸਦੇ ਸਟੀਕ-ਚਾਲਾਂ ਕੱਢ ਲੈਂਦੇ ਹਨ, ਅਤੇ ਟੀਮ ਅਜੇ ਵੀ ਅਨੁਮਾਨ ਲਾਉਂਦੀ ਰਹਿੰਦੀ ਹੈ ਕਿ ਕੀ ਗਲਤ ਹੈ।
ਮੋਨੀਟਰਿੰਗ ਨੂੰ ਇਹ ਸਵਾਲ ਜਵਾਬ ਦੇਣੇ ਚਾਹੀਦੇ ਹਨ: ਯੂਜ਼ਰ ਕੀ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਰਹੇ ਸਨ, ਕਿੱਥੇ ਫੇਲ ਹੋਇਆ, ਅਤੇ ਉਹ ਕਿਵੇਂ ਠੀਕ ਕਰਦੇ ਹਨ? ਕੁਝ high-signal events ਟ੍ਰੈਕ ਕਰੋ:
ਇਹ signals “tokens used” ਨਾਲੋਂ ਜ਼ਿਆਦਾ actionable ਹੁੰਦੇ ਹਨ।
ਇੱਕ ਆਸਾਨ ਤਰੀਕਾ ਜੁੜੋ ਤਾਕਿ ਬੁਰੇ ਜਵਾਬ ਫਲੈਗ ਕੀਤੇ ਜਾ ਸਕਣ (thumbs down + ਵਿਕਲਪਿਕ ਕਾਰਨ)। ਫਿਰ ਇਸਨੂੰ operational ਬਣਾਓ:
ਬਿਆਪਕ ਸਮੇਂ ਨਾਲ ਤੁਹਾਡਾ eval ਸੈੱਟ ਤੁਹਾਡੇ ਪ੍ਰੋਡਕਟ ਦਾ “ਇਮੀਊਨ ਸਿਸਟਮ” ਬਣ ਜਾਂਦਾ ਹੈ।
ਇੱਕ ਹਲਕਾ-ਫੁੱਲਕਾ triage ਪ੍ਰਭੰਧ ਬਣਾਓ ਤਾਂ ਕਿ ਪੈਟਰਨ ਖੋ ਨਾ ਜਾਏ:
ਮੋਨੀਟਰਿੰਗ ਅਤਿਰਿਕਤ ਕੰਮ ਨਹੀਂ—ਇਹ ਹੈ ਕਿ ਤੁਸੀਂ ਇੱਕੋ ਹੀ bug ਨੂੰ ਨਵੇਂ ਰੂਪਾਂ ਵਿੱਚ ਭੇਜਣਾ ਬੰਦ ਕਰੋ।
ਜੇ ਤੁਸੀਂ ਆਪਣੀ ਪਹਿਲੀ AI ਫੀਚਰ ਬਣਾ ਰਹੇ ਹੋ, ਤਾਂ ਮਾਡਲ ਨੂੰ “ਚਾਲਾਕ” ਬਣਾਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਨਾ ਕਰੋ। ਪ੍ਰੋਡਕਟ ਅਤੇ ਇੰਜੀਨੀਅਰਿੰਗ ਫ਼ੈਸਲੇ ਸੁੱਲਝੇ ਹੋਏ, ਟੈਸਟਯੋਗ, ਅਤੇ ਦੁਹਰਾਏ ਜਾ ਸਕਣ ਵਾਲੇ ਰੱਖੋ।
ਚਾਰ ਚੀਜ਼ਾਂ ਸ਼ਾਮਲ ਕਰੋ:
ਉਹ ਸਭ ਤੋਂ ਛੋਟਾ workflow ਬਣਾਓ ਜੋ ਸਹੀ ਹੋ ਸਕੇ।
ਮੰਜੂਰ ਕੀਤਾ ਹੋਇਆ ਕਾਰਜ ਨਿਰਧਾਰਤ ਕਰੋ, ਜਿੱਥੇ ਸੰਰਚਿਤ ਆਊਟਪੁੱਟ ਦੀ ਲੋੜ ਹੋਵੇ, ਅਤੇ "ਮੈਨੂੰ ਨਹੀਂ ਪਤਾ / ਹੋਰ ਜਾਣਕਾਰੀ ਚਾਹੀਦੀ ਹੈ" ਨੂੰ ਇੱਕ ਵੈਧ ਨਤੀਜਾ ਮੰਨੋ। ਜੇ ਤੁਸੀਂ RAG ਵਰਤ ਰਹੇ ਹੋ, ਤਾਂ ਸਿਸਟਮ ਸੰਕੁਚਿਤ ਰੱਖੋ: ਥੋੜ੍ਹੇ ਸਰੋਤ, ਸਖ਼ਤ ਫਿਲਟਰਿੰਗ, ਅਤੇ ਸਪਸ਼ਟ citations।
ਜੇ ਤੁਸੀਂ Koder.ai ਵਿੱਚ ਬਣਾ ਰਹੇ ਹੋ, ਤਾਂ ਇੱਕ ਉਪਯੋਗੀ ਪੈਟਰਨ ਹੈ Planning Mode 'ਚ ਸ਼ੁਰੂ ਕਰਨਾ (ਤਾਂ ਜੋ ਤੁਹਾਡਾ workflow, ਡੇਟਾ ਸਰੋਤ, ਅਤੇ refuse ਨਿਯਮ ਸਪਸ਼ਟ ਹੋਣ), ਫਿਰ ਛੋਟੇ ਬਦਲਾਅ ਨਾਲ iterate ਕਰੋ ਅਤੇ ਜਦ ਪ੍ਰੌਂਪਟ ਜਾਂ retrieval ਤਬਦੀਲੀ regression ਲਿਆਵੇ ਤਾਂ snapshots + rollback 'ਤੇ ਨਿਰਭਰ ਰਹੋ।
ਸ਼ਿਪ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਪੁਸ਼ਟੀ ਕਰੋ:
ਜਦ ਗੁਣਵੱਤਾ ਘੱਟ ਹੋਵੇ, ਤਰਤੀਬ وار ਇਨ ਸ਼ੈਲੀ ਬਦਲੋ:
ਇਸ ਨਾਲ ਪ੍ਰਗਤੀ ਮਾਪਯੋਗ ਰਹਿੰਦੀ ਹੈ—ਅਤੇ “ਬੇਤਰਤੀਬ ਪ੍ਰੌਂਪਟ ਟਵਿਕਸ” ਤੁਹਾਡੀ ਰਣਨੀਤੀ ਨਾ ਬਣਣ।
ਜੇ ਤੁਸੀਂ ਹਰ ਵਾਰੀ ਤੇਜ਼ੀ ਨਾਲ ਭੇਜਣਾ ਚਾਹੁੰਦੇ ਹੋ ਬਿਨਾਂ ਪੂਰਾ stack ਦੁਬਾਰਾ ਬਣਾਏ, ਤਾਂ ਉਹ ਟੂਲ ਚੁਣੋ ਜੋ ਤੇਜ਼ iteration ਅਤੇ ਪੰਜਾਬੀ-ਕਲੇਅਨ ਹੈਂਡਓਫ਼ ਨੂੰ ਸਮਰਥਿਤ ਕਰਦਾ ਹੋਵੇ। ਉਦਾਹਰਣ ਲਈ, Koder.ai ਚੈਟ ਤੋਂ React frontends, Go backends, ਅਤੇ PostgreSQL ਸਕੀਮਾ ਜਨਰੇਟ ਕਰ ਸਕਦਾ ਹੈ, ਅਤੇ ਤਾਂ ਹੀ ਤੁਹਾਨੂੰ ਸੋਰਸ ਕੋਡ export ਕਰਨ ਅਤੇ custom domains 'ਤੇ deploy ਕਰਨ ਦੀ ਆਜ਼ਾਦੀ ਮਿਲਦੀ ਹੈ—ਜਦ ਤੁਹਾਡੀ AI ਫੀਚਰ ਪ੍ਰੋਟੋਟਾਈਪ ਤੋਂ ਉਸ ਚੀਜ਼ ਵਿੱਚ ਬਦਲਦੀ ਹੈ ਜਿਸ 'ਤੇ ਯੂਜ਼ਰ ਨਿਰਭਰ ਕਰਦੇ ਹਨ।
ਸਧਾਰਨ ਭਾਸ਼ਾ ਵਿੱਚ job-to-be-done ਲਿਖੋ ਅਤੇ ਮਾਪਣਯੋਗ ਸਫਲਤਾ ਨਿਰਧਾਰਤ ਕਰੋ (ਜਿਵੇਂ ਕਿ ਸਮਾਂ ਬਚਤ, ਤਰੁੱਟੀ ਦਰ, ਪੂਰਨਤਾ ਦਰ)। ਫਿਰ ਮੌਜੂਦਾ ਕੰਮ-ਫਲੋ ਵਿੱਚੋਂ ਇੱਕ ਸੀਮਤ v1 ਕਦਮ ਚੁਣੋ ਅਤੇ ਖੁੱਲ੍ਹ ਕੇ ਲਿਖੋ ਕਿ ਤੁਸੀਂ ਹੁਣੇ ਕੀ ਨਹੀਂ ਬਣਾਉਂਦੇ।
ਜੇ ਤੁਸੀਂ “ਬਿਹਤਰ” ਮਾਪ ਨਹੀਂ ਸਕਦੇ, ਤਾਂ ਤੁਸੀਂ ਡੈਮੋਜ਼ ਦੀ ਬਜਾਏ ਨਤੀਜਿਆਂ ਨੂੰ optimize ਕਰ ਰਹੇ ਹੋਵੋਗੇ।
ਬੇਸਲਾਈਨ ਉਹ ਤੁਹਾਡਾ non-AI (ਜਾਂ ਘੱਟ-AI) “ਕੰਟਰੋਲ” ਹੈ ਜਿਸ ਨਾਲ ਤੁਸੀਂ ਸਹੀਤਾ, ਰਫਤਾਰ, ਅਤੇ ਉਪਭੋਗਤਾ ਸੰਤੋਸ਼ ਦੀ ਤੁਲਨਾ ਕਰ ਸਕੋ।
ਉਪਯੋਗੀ ਬੇਸਲਾਈਨ ਵਿੱਚ ਸ਼ਾਮਲ ਹਨ:
ਇਸ ਬਿਨਾਂ ਤੁਸੀਂ ROI ਸਾਬਤ ਨਹੀਂ ਕਰ ਸਕਦੇ—ਅਤੇ ਇਹ ਵੀ ਨਹੀਂ ਬਤਿਆ ਜਾ ਸਕਦਾ ਕਿ AI ਕੰਮ ਨੂੰ ਖਰਾਬ ਕਰ ਰਿਹਾ ਹੈ।
ਪ੍ਰੌਂਪ ਨੂੰ “ਜੱਦੋਂ ਤੱਕ ਚੱਲੇ” ਦੀ ਤਰ੍ਹਾਂ ਵਰਤਣ ਦੀ ਥਾਂ, ਉਨ੍ਹਾਂ ਨੂੰ ਪ੍ਰੋਡਕਟ ਰਿਕੁਆਾਇਰਮੈਂਟ ਵਾਂਗ ਲਿਖੋ:
ਫਿਰ ਕੁਝ ਉਦਾਹਰਣ ਅਤੇ ਘੱਟੋ-ਘੱਟ ਇੱਕ counter-example ਜੋ “ਇਹ ਨਾ ਕਰੋ” ਦਿਖਾਏ। ਇਸ ਨਾਲ ਵਿਵਹਾਰ ਟੈਸਟਬਲ ਬਣ ਜਾਂਦਾ ਹੈ ਨਾਂ ਕਿ vibes-ਅਧਾਰਿਤ।
ਮਾਣੋ ਕਿ ਮਾਡਲ ਤੁਹਾਡੇ ਮੌਜੂਦਾ ਨੀਤੀਆਂ, ਕੀਮਤਾਂ, ਰੋਡਮੈਪ, ਜਾਂ ਗਾਹਕ ਇਤਿਹਾਸ ਨਹੀਂ ਜਾਣਦਾ।
ਜੇ ਜਵਾਬ ਨੂੰ ਤੁਹਾਡੀ ਆੰਤਰੀਕ ਸੱਚਾਈ ਨਾਲ ਮੇਲ ਹੋਣਾ ਜਰੂਰੀ ਹੈ, ਤਾਂ ਉਹ ਸੱਚਾਈ ਪ੍ਰਮਾਣਿਤ ਸੰਦਰਭ (ਦਸਤਾਵੇਜ਼, ਡੇਟਾਬੇਸ ਨਤੀਜੇ, ਜਾਂ ਪ੍ਰਾਪਤ ਪੈਸਾਜ਼) ਰਾਹੀਂ ਦਿਓ ਅਤੇ ਮਾਡਲ ਨੂੰ quote/cite ਕਰਨ ਦੀ ਲੋੜ ਲਗਾਓ। ਨਾਹ ਤਾਂ ਸੁਰੱਖਿਅਤ fallback ਜਿਵੇਂ “ਮੈਂ ਦਿੱਤੇ ਸਰੋਤਾਂ ਦੇ ਆਧਾਰ ਤੇ ਨਹੀਂ ਜਾਣਦਾ—ਇਸਨੂੰ ਕਿਵੇਂ ਵੇਰੀਫਾਈ ਕਰਨਾ ਹੈ” ਬਲੌਕ ਕਰੋ।
ਕਿਉਂਕਿ retrieval relevance ਦੀ ਗਾਰੰਟੀ ਨਹੀਂ ਦਿੰਦਾ। ਆਮ ਨੁਕਸਾਂ ਵਿੱਚ ਖਰਾਬ chunking, ਕੀਵਰਡ-ਮੇਚਿੰਗ ਜਿਸ ਨਾਲ ਅਰਥ ਮੇਲ ਨਹੀਂ ਖਾਂਦਾ, ਪੁਰਾਣੇ ਦਸਤਾਵੇਜ਼, ਅਤੇ ਬਹੁਤ ਸਾਰੇ ਘੱਟ-ਗੁਣਵੱਤਾ ਚੰਕ ਸ਼ਾਮਲ ਹਨ।
ਭਰੋਸਾ ਵਧਾਉਣ ਲਈ:
ਜੇ ਤੁਸੀਂ citation ਨਹੀਂ ਦੇ ਸਕਦੇ, ਤਾਂ ਇਹਨੂੰ ਤੱਥ ਵਜੋਂ ਪੇਸ਼ ਨਾ ਕਰੋ।
ਛੋਟੇ, ਨਮੂਨੇ ਵਾਲੇ ਮੁਲਾਂਕਣ ਸੈੱਟ (30–100 ਕੇਸ) ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ ਜੋ:
ਕੁਝ ਸਥਿਰ ਜਾਂਚਾਂ ਟ੍ਰੈਕ ਕਰੋ:
ਹਰ ਪ੍ਰੌਂਪ/ਮਾਡਲ/ਕੰਫਿਗ ਬਦਲਾਅ ਤੋਂ ਪਹਿਲਾਂ ਇਸ ਨੂੰ ਚਲਾਓ ਤਾਂ ਜੋ ਖਾਮੋਸ਼ੀ ਨਾਲ ਹੋ ਰਹੀਆਂ regressions ਰੁਕੀ ਰਹਿਣ।
ਡੈਮੋਜ਼ ‘ਹੈਪੀ ਪਾਥ’ ਹੀ ਵੇਖਦੇ ਹਨ, ਪਰ ਅਸਲ ਉਪਭੋਗਤਾ ਲਿਆਉਂਦੇ ਹਨ:
ਅਸਲ ਵਰਤੋਂ ਦੀ ਜਾਂਚ ਕਰਨ ਲਈ ਇਹਨਾਂ ਸਭ ਨੂੰ ਟੈਸਟ ਸਰਵੁੱਖ ਚਾਰ ਵਿਚ ਲਿਆਓ ਅਤੇ ਹਾਰਡੇੜ ਹਾਲਤਾਂ ਲਈ graceful fallback ਤਿਆਰ ਕਰੋ।
ਤਸਦੀਕ ਨੂੰ DEFAULT ਬਣਾਓ ਤਾਂ ਕਿ ਯੂਜ਼ਰ جلدੀ ਜਾਂਚ ਸਕਣ:
ਜਦੋਂ ਇਨਪੁਟ ਅਧੂਰਾ ਹੋਵੇ ਤਾਂ ਇੱਕ-ਦੋ ਸਪਸ਼ਟੀਕਰਨ ਸਵਾਲ ਪੁੱਛੋ; ਅਜਿਹਾ ਕਰਨ ਨਾਲ ਹੱਲੋਸੀਨੇਸ਼ਨ ਘੱਟ ਹੁੰਦੇ ਹਨ ਅਤੇ ਯੂਜ਼ਰ ਮਹਿਸੂਸ ਕਰਦੇ ਹਨ ਕਿ ਸਿਸਟਮ ਉਨ੍ਹਾਂ ਨਾਲ ਕੰਮ ਕਰ ਰਿਹਾ ਹੈ।
ਉਦੇਸ਼ ਇਹ ਨਹੀਂ ਕਿ ਉਪਭੋਗਤਾ ਕੋਥੇ ਰੁਕੇ—ਸਗੋਂ ਇਹ ਕਿ ਸਹੀ ਰਸਤਾ ਸਭ ਤੋਂ ਤੇਜ਼ ਹੋਵੇ।
ਸਪਲਾਈ-ਅੱਗੇ ਕੀ ਨਾ ਹੋਵੇ, ਇਹ ਪਹਿਲਾਂ ਨਿਰਧਾਰਤ ਕਰੋ ਅਤੇ ਪ੍ਰੋਡਕਟ ਵਿੱਚ ਲਾਗੂ ਕਰੋ:
PII ਨੂੰ ਖ਼ਤਰਨਾਕ ਸਮਾਨ ਵਾਂਗ ਸਮਝੋ: ਘੱਟ ਤੋਂ ਘੱਟ ਡੇਟਾ ਇਕੱਠਾ ਕਰੋ, ਅਣਲੋੜੀ ਰੌ-ਇੰਪੁੱਟ ਸਟੋਰ ਨਾ ਕਰੋ, ਲੋਗਿੰਗ ਤੋਂ ਪਹਿਲਾਂ ਸੰਵੇਦਨਸ਼ੀਲ ਫੀਲਡਸ ਨੂੰ redact/tokenize ਕਰੋ, ਅਤੇ ਸਪੱਸ਼ਟ ਸਹਿਮਤੀ ਮੰਗੋ ਜੇ ਡੇਟਾ ਟ੍ਰੇਨਿੰਗ ਜਾਂ ਤੀਜੇ-ਪੱਖੀਆਂ ਨੂੰ ਸਾਂਝਾ ਕੀਤਾ ਜਾਵੇ।
ਲੋਗਿੰਗ ਅਤੇ ਐਕਸੈਸ ਕੰਟਰੋਲ debug ਲਈ ਜ਼ਰੂਰੀ ਹਨ ਪਰ ਇਹਨਾਂ ਨੂੰ ਰੋਕਣਾ ਵੀ ਜ਼ਰੂਰੀ ਹੈ: retention limits, ਅਧਿਕਾਰ ਅਤੇ ਵਿਸ਼ੇਸ਼ dev/prod ਵੱਖਰਾ ਕਰੋ।
ਸੁਰੱਖਿਆ, ਗੋਪਨੀਯਤਾ ਅਤੇ ਪਾਲਣਾ paperwork ਨਹੀਂ—ਇਹ ਪ੍ਰੋਡਕਟ ਲੋੜਾਂ ਹਨ।
ਸਭ ਤੋਂ ਵੱਡੇ ਚਾਲਕ ਹੁੰਦੇ ਹਨ: context length, ਟੂਲ ਰਾਊਂਡ-ਟ੍ਰਿਪ, multi-step ਚੇਨ, ਅਤੇ retries/fallbacks.
ਹਾਰਡ ਲਿਮਿਟ ਕੋਡ ਵਿੱਚ ਰੱਖੋ:
ਹਮੇਸ਼ਾਂ “cost per successful task” optimize ਕਰੋ, ਨਾ ਕਿ ਸਿਰਫ਼ cost per request—ਕਈ ਵਾਰੀ ਅਸਫਲ retries ਹੀ ਅਸਲ ਖ਼ਰਚ ਵਧਾਉਂਦੀਆਂ ਹਨ।