ਐਪ ਲਾਜ਼ਿਕ ਵਿੱਚ ਮਾਡਲਾਂ ਨਾਲ AI-ਪਹਿਲੇ ਉਤਪਾਦ ਕਿਵੇਂ ਬਣਾਏ ਜਾਣ

AI-ਪਹਿਲੇ ਉਤਪਾਦ ਬਣਾਉਣ ਦਾ ਕੀ ਅਰਥ ਹੈ

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

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

ਅਮਲ ਵਿੱਚ: ਹਰ ਫੈਸਲਾ ਰੁਕ-ਰੁਕ ਕੇ ਕੋਡ ਵਿੱਚ ਹਾਰਡ-ਕੋਡ ਕਰਨ ਦੀ ਬਜਾਏ ("ਜੇ X ਤਾਂ Y ਕਰੋ"), ਤੁਸੀਂ ਮਾਡਲ ਨੂੰ ਓਹ ਹੱਦਾਂ ਦਿੱਤੀਆਂ ਗੱਲਾਂ ਨਾਲ ਨਿਪਟਣ ਦਿੰਦੇ ਹੋ—ਭਾਸ਼ਾ, ਇਰਾਦਾ, ਅਸਪਸ਼ਟਤਾ, ਤਰਜੀਹ—ਜਦਕਿ ਤੁਹਾਡਾ ਕੋਡ ਉਹ ਕੰਮ ਸੰਭਾਲਦਾ ਹੈ ਜੋ ਨਿਰਧਾਰਿਤ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ: ਅਨੁਮਤੀਆਂ, ਭੁਗਤਾਨ, ਡੇਟਾਬੇਸ ਲਿਖਤਾਂ, ਅਤੇ ਨੀਤੀ ਲਾਗੂ ਕਰਨੀ।

ਕਦੋਂ AI-ਪਹਿਲਾ ਠੀਕ ਰਹਿੰਦਾ ਹੈ (ਅਤੇ ਕਦੋਂ ਨਹੀਂ)

AI-ਪਹਿਲਾ ਉਸ ਵੇਲੇ ਸਭ ਤੋਂ ਵਧੀਆ ਕੰਮ ਕਰਦਾ ਹੈ ਜਦੋਂ ਸਮੱਸਿਆ ਵਿੱਚ:

• ਬਹੁਤ ਸਾਰੇ ਵੈਧ ਇਨਪੁੱਟ ਹਨ (ਫ੍ਰੀ-ਟੈਕਸਟ, ਗੁੰਝਲਦਾਰ ਦਸਤਾਵੇਜ਼, ਵੱਖ-ਵੱਖ ਉਪਭੋਗਤਾ ਮਕਸਦ)
• ਹੱਥ ਨਾਲ ਨਿਯਮ ਬਣਾਣ ਲਈ ਬਹੁਤ ਜ਼ਿਆਦਾ ਐਜ ਕੇਸ ਹਨ
• ਸੰਪੂਰਣ ਨਿਸ਼ਚਿਤਤਾ ਵਲੋਂ ਵਧੇਰੇ ਕੀਮਤ ਹੈ—ਜੱਜਮੈਂਟ, ਸਾਰ-ਸੰਕਲਨ, ਜਾਂ ਸਿੰਥੇਸਿਸ

ਜਦੋਂ ਲੋੜਾਂ ਸਥਿਰ ਅਤੇ ਸਹੀ ਹੋ—ਟੈਕਸ ਗਣਨਾ, ਇਨਵੈਂਟਰੀ ਲਾਜ਼ਿਕ, ਯੋਗਤਾ ਜਾਂਚ, ਜਾਂ ਅਡਿੱਠੀ ਦੇ ਕਾਰਜ—ਤਾਂ ਰੂਲ-ਅਧਾਰਤ ਆਟੋਮੇਸ਼ਨ ਆਮ ਤੌਰ 'ਤੇ ਵਧੀਆ ਹੁੰਦੀ ਹੈ।

ਆਮ ਉਤਪਾਦ ਲਕੜੀਆਂ ਜਿਨ੍ਹਾਂ ਲਈ AI-ਪਹਿਲਾ ਫਾਇਦਾ ਦੇ ਸਕਦਾ ਹੈ

ਦਲ ਆਮ ਤੌਰ 'ਤੇ ਮਾਡਲ-ਚਲਿਤ ਲਾਜ਼ਿਕ ਇਸ ਲਈ ਅਪਣਾਉਂਦੇ ਹਨ ਤਾਂ ਕਿ:

• ਗਤੀ ਵਧੇ: ਜ਼ਰੂਰੀ ਜਵਾਬ ਬਣਾਓ, ਖੇਤਰਾਂ ਨੂੰ ਨਿਕਾਲੋ, ਅਨੁਰੋਧਾਂ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਰੂਟ ਕਰੋ
• ਨਿੱਜੀਅਤ ਲਿਆਓ: ਵਿਆਖਿਆਵਾਂ, ਯੋਜਨਾਵਾਂ, ਜਾਂ ਸਿਫ਼ਾਰਸ਼ਾਂ ਨੂੰ ਵਿਅਕਤੀਗਤ ਬਣਾਓ
• ਫੈਸਲਾ-ਸਹਾਇਤਾ: ਤਰਜੀਹਾਂ ਝਲਕਾਓ, ਵਿਕਲਪ ਬਣਾਓ, ਸਬੂਤ ਦਾ ਸਾਰ ਦਿਓ

ਵਪਾਰੀਆਂ ਤਰਫਾਂ (ਟਰੇਡਓਫ) ਜਿਨ੍ਹਾਂ ਲਈ ਤੁਹਾਨੂੰ ਤਿਆਰ ਹੋਣਾ ਪਏਗਾ

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

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

ਸਹੀ ਯੂਜ਼ ਕੇਸ ਚੁਣੋ ਅਤੇ ਸਫਲਤਾ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ

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

ਮਾਡਲ ਨਾਲ ਨਹੀਂ, ਕੰਮ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ

ਇੱਕ-ਵਾਕ ਦਾ ਜ਼ੌਬ-ਸਟੋਰੀ ਲਿਖੋ: "ਜਦੋਂ ___, ਮੈਂ ਚਾਹੁੰਦਾ/ਚਾਹੁੰਦੀ ਹਾਂ ___, ਤਾਂ ਜੋ ਮੈਂ ___ ਕਰ ਸਕਾਂ." ਫਿਰ ਨਤੀਜੇ ਨੂੰ ਮਾਪਯੋਗ ਬਣਾਓ।

ਉਦਾਹਰਨ: “ਜਦੋਂ ਮੈਨੂੰ ਇੱਕ ਲੰਬਾ ਗਾਹਕ ਈਮੇਲ ਮਿਲੇ, ਮੈਂ ਚਾਹੁੰਦਾ/ਚਾਹੁੰਦੀ ਹਾਂ ਕਿ ਇੱਕ ਸੁਝਾਇਆ ਗਿਆ ਜਵਾਬ ਹੋਵੇ ਜੋ ਸਾਡੀ ਨੀਤੀ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਹੋਵੇ, ਤਾਂ ਜੋ ਮੈਂ 2 ਮਿੰਟ ਵਿੱਚ ਜਵਾਬ ਦੇ ਸਕਾਂ।” ਇਹ "ਈਮੇਲ ਵਿੱਚ LLM ਜੋੜੋ" ਤੋਂ ਕਾਫ਼ੀ ਜ਼ਿਆਦਾ ਕਾਰਗਰ ਹੈ।

ਫੈਸਲੇ ਬਿੰਦੂਆਂ ਦਾ ਨਕਸ਼ਾ ਬਣਾਓ

ਉਹ ਮੁਹਰਲੇ ਨਿਰਧਾਰਤ ਕਰੋ ਜਿੱਥੇ ਮਾਡਲ ਕਾਰਵਾਈਆਂ ਚੁਣੇਗਾ। ਇਹ ਫੈਸਲਾ-ਬਿੰਦੂ ਖੁਲਾਸਾ ਹੋਣ ਚਾਹੀਦੇ ਹਨ ਤਾਂ ਜੋ ਤੁਸੀਂ ਉਹਨਾਂ ਦੀ ਜਾਂਚ ਕਰ ਸਕੋ।

ਆਮ ਫੈਸਲਾ-ਬਿੰਦੂ ਸ਼ਾਮِل ਹਨ:

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

ਜੇ ਤੁਸੀਂ ਫੈਸਲਿਆਂ ਨੂੰ ਨਾਮ ਨਹੀਂ ਦੇ ਸਕਦੇ, ਤਾਂ ਤੁਸੀਂ ਮਾਡਲ-ਚਲਿਤ ਲਾਜ਼ਿਕ ਨੂੰ ਸ਼ਿਪ ਕਰਨ ਲਈ ਤਿਆਰ ਨਹੀਂ ਹੋ।

ਵਿਹਾਰ ਲਈ ਐਕਸੈਪਟੈਂਸ ਕ੍ਰਾਈਟਰੀਆ ਲਿਖੋ

ਮਾਡਲ ਦੇ ਵਿਹਾਰ ਨੂੰ ਕਿਸੇ ਹੋਰ ਉਤਪਾਦ ਲੋੜ ਵਾਂਗ ਹੀ ਲਵੋ। "ਵਧੀਆ" ਅਤੇ "ਖਰਾਬ" ਦਿਖਾਉਣ ਵਾਲੀ ਭਾਸ਼ਾ ਵਿੱਚ ਪਰਿਭਾਸ਼ਾ ਕਰੋ।

ਉਦਾਹਰਨ ਲਈ:

• ਵਧੀਆ: ਨਵੀਂ ਨੀਤੀ ਵਰਤੇ, ਸਹੀ ਆਰਡਰ ID ਦਰਸਾਏ, ਜੇ ਜਾਣਕਾਰੀ ਘੱਟ ਹੋ ਤਾਂ ਇੱਕ ਸਾਫ਼ ਪ੍ਰਸ਼ਨ ਪੁੱਛੇ
• ਖਰਾਬ: ਛੂਟਾਂ ਬਣਾਉਣਾ, ਅਸਮਰਥਤ ਲੋਕੇਲ ਦਾ ਹਵਾਲਾ ਦੇਣਾ, ਜਰੂਰੀ ਡੇਟਾ ਚੈੱਕ ਕੀਤੇ ਬੱਗੇ ਜਵਾਬ ਦੇਣਾ

ਇਹ ਮਾਪ ਦੋਬਾਰਤ ਤੇ ਤੁਹਾਡੇ ਮੁਲਾਂਕਣ ਸੈੱਟ ਲਈ ਬੁਨਿਆਦ ਬਣਦੇ ਹਨ।

ਸੀਮਾਵਾਂ ਨੂੰ ਸ਼ੁਰੂ ਤੋਂ ਹੀ ਪਛਾਣੋ

ਉਹ ਸੀਮਾਵਾਂ ਲਿਸਟ ਕਰੋ ਜੋ ਤੁਹਾਡੀਆਂ ਡਿਜ਼ਾਈਨ ਚੋਣਾਂ ਨੂੰ ਰੂਪ ਦਿੰਦੀਆਂ ਹਨ:

• ਸਮਾਂ (ਜਵਾਬ ਦੀ ਲੈਟੈਂਸੀ ਲਕੜੀ)
• ਬਜਟ (ਪ੍ਰਤੀ ਟਾਸਕ ਲਾਗਤ)
• अनुपਾਲਨ (PII ਹੈਂਡਲਿੰਗ, ਆਡਿਟ ਦੀਆਂ ਲੋੜਾਂ)
• ਸਮਰਥਿਤ ਲੋਕੇਲ (ਭਾਸ਼ਾਵਾਂ, ਟੋਨ, ਸਾਂਸਕਿਰਤਕ ਉਮੀਦਾਂ)

ਅਜਿਹੇ ਸਫਲਤਾ ਮੈਟ੍ਰਿਕ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ ਜੋ ਤੁਸੀਂ ਮਾਨੀਟਰ ਕਰ ਸਕੋ

ਜੋਬ ਨਾਲ ਜੁੜੇ ਕੁਝ ਮੈਟ੍ਰਿਕ ਚੁਣੋ:

• ਟਾਸਕ ਪੂਰਾ ਹੋਣ ਦੀ ਦਰ
• ਨਿਰਧਾਰਿਤ ਕੇਸਾਂ 'ਤੇ ਸ਼ੁੱਧਤਾ (ਜਾਂ ਨੀਤੀ ਅਨੁਕੂਲਤਾ)
• CSAT ਜਾਂ ਗੁਣਵੱਤਾ ਯੂਜ਼ਰ ਰੇਟਿੰਗ
• ਪ੍ਰਤੀ ਟਾਸਕ ਬਚਿਆ ਸਮਾਂ (ਜਾਂ ਸਮਾਂ-ਤੱਕ-ਨਿਰਾਕਰਨ)

ਜੇ ਤੁਸੀਂ ਸਫਲਤਾ ਨੂੰ ਮਾਪ ਨਹੀਂ ਕਰ ਸਕਦੇ, ਤਾਂ ਤੁਸੀਂ ਅਨੁਭੂਤੀਆਂ ਬਾਰੇ ਵਿਚਾਰ-ਵਿਵਾਦ ਵਿੱਚ ਫਸ ਜਾਵੋਗੇ ਨਾ ਕਿ ਉਤਪਾਦ ਨੂੰ ਸੁਧਾਰ ਸਕੋਗੇ।

AI-ਚਲਿਤ ਯੂਜ਼ਰ ਫਲੋ ਅਤੇ ਸਿਸਟਮ ਸੀਮਾਵਾਂ ਡਿਜ਼ਾਈਨ ਕਰੋ

AI-ਪਹਿਲਾ ਫਲੋ "ਇੱਕ ਸਕਰੀਨ ਜੋ LLM ਨੂੰ ਕਾਲ ਕਰਦੀ ਹੈ" ਨਹੀਂ ਹੁੰਦਾ। ਇਹ ਇੱਕ ਅਖੀਰ-ਤੱਕ ਦਾ ਸਫ਼ਰ ਹੈ ਜਿੱਥੇ ਮਾਡਲ ਕੁਝ ਫੈਸਲੇ ਕਰਦਾ ਹੈ, ਉਤਪਾਦ ਉਹਨਾਂ ਨੂੰ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਲਾਗੂ ਕਰਦਾ ਹੈ, ਅਤੇ ਯੂਜ਼ਰ oriented ਰਹਿੰਦਾ ਹੈ।

ਅੰਟ-ਟੁ-ਅੰਟ ਲੂਪ ਦਾ ਨਕਸ਼ਾ ਬਣਾਓ

ਆਮ ਤੌਰ 'ਤੇ ਪਾਈਪਲਾਈਨ ਨੂੰ ਸਧਾਰਨ ਸ਼੍ਰੇਣੀ ਵਜੋਂ ਡਰਾਂ: ਇਨਪੁੱਟ → ਮਾਡਲ → ਕਾਰਵਾਈਆਂ → ਆਊਟਪੁੱਟ।

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

ਇਹ ਨਕਸ਼ਾ ਇਹ ਬਤਾਂਦਾ ਹੈ ਕਿ ਕਿੱਥੇ ਅਸਪਸ਼ਟਤਾ ਮਨਜ਼ੂਰ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ (ਡ੍ਰਾਫਟਿੰਗ) ਅਤੇ ਕਿੱਥੇ ਨਹੀਂ (ਬਿੱਲਿੰਗ ਬਦਲਾਅ)।

ਸਿਸਟਮ ਸੀਮਾਵਾਂ ਚਿੱਤਰਿਤ ਕਰੋ: ਮਾਡਲ ਵਿਰੁੱਧ ਨਿਰਧਾਰਿਤ ਕੋਡ

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

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

ਮਾਡਲ ਕਿੱਥੇ ਚਲੇਗਾ ਫੈਸਲਾ ਕਰੋ

ਸੰਬੰਧਿਤ ਸੀਮਾਵਾਂ ਅਨੁਸਾਰ ਰਨਟਾਈਮ ਚੁਣੋ:

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

ਲੈਟੈਂਸੀ, ਲਾਗਤ ਅਤੇ ਡੇਟਾ ਅਨੁਮਤੀਆਂ ਦਾ ਬਜਟ ਰੱਖੋ

ਪ੍ਰਤੀ-ਬੇਨਤੀ ਲੈਟੈਂਸੀ ਅਤੇ ਲਾਗਤ ਦਾ ਬਜਟ (ਰਿਟ੍ਰਾਇਜ਼ ਅਤੇ ਟੂਲ ਕਾਲਾਂ ਸਮੇਤ) ਤੈਅ ਕਰੋ, ਫਿਰ UX ਨੂੰ ਉਸ ਅਨੁਸਾਰ ਡਿਜ਼ਾਈਨ ਕਰੋ (സ്റ്റ੍ਰੀਮਿੰਗ, ਪ੍ਰੋਗ੍ਰੈਸਿਵ ਨਤੀਜੇ, "ਇਨ-ਬੈਕਗ੍ਰਾਊਂਡ ਜਾਰੀ ਰੱਖੋ")।

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

ਆਰਕੀਟੈਕਚਰ ਪੈਟਰਨ: ਆਰਕੀਸਟ੍ਰੇਸ਼ਨ, ਸਟੇਟ, ਅਤੇ ਟਰੈਸ

ਜਦੋਂ ਮਾਡਲ ਤੁਹਾਡੇ ਐਪ ਦੇ ਲਾਜ਼ਿਕ ਦਾ ਹਿੱਸਾ ਬਣ ਜਾਂਦਾ ਹੈ, ਤਾਂ "ਆਰਕੀਟੈਕਚਰ" ਸਿਰਫ਼ ਸਰਵਰਾਂ ਅਤੇ APIs ਹੀ ਨਹੀਂ ਹੁੰਦੀ—ਇਹ ਇਹ ਵੀ ਹੁੰਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਕਿਵੇਂ ਨਿਰੰਤਰ ਤਰੀਕੇ ਨਾਲ ਮਾਡਲ ਫੈਸਲਿਆਂ ਦੀ ਲੜੀ ਚਲਾਉਂਦੇ ਹੋ ਬਿਨਾਂ ਕੰਟਰੋਲ ਖੋਣ ਦੇ।

ਆਰਕੀਸਟ੍ਰੇਸ਼ਨ: ਮਾਡਲ ਕੰਮ ਦਾ ਕੰਡਕਟਰ

ਆਰਕੀਸਟ੍ਰੇਸ਼ਨ ਉਹ ਲੇਅਰ ਹੈ ਜੋ ਕਿਸੇ AI ਟਾਸਕ ਨੂੰ ਆਖਿਰ ਤੱਕ ਚਲਾਉਂਦਾ ਹੈ: ਪ੍ਰਾਂਪਟ ਅਤੇ ਟੈਂਪਲੇਟ, ਟੂਲ ਕਾਲਾਂ, ਮੈਮੋਰੀ/ਸੰਦਰਭ, ਰਿਟ੍ਰਾਈਜ਼, ਟਾਈਮਆਉਟਸ, ਅਤੇ ਫਾਲਬੈਕ।

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

ਜੇ ਤੁਸੀਂ ਖਿਆਲ ਤੋਂ ਕੰਮ ਕਰਨ ਵਾਲੀ ਆਰਕੀਸਟ੍ਰੇਸ਼ਨ ਤਿਆਰ ਕਰਨਾ ਤੇਜ਼ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ vibe-coding ਵਰਕਫਲੋ ਤੁਹਾਨੂੰ ਐਪ ਸਕੈਫੋਲਡਿੰਗ ਨੂੰ ਮੁੜ ਬਣਾਉਣ ਬਿਨਾਂ ਝਟਪਟ ਪ੍ਰੋਟੋਟਾਈਪ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰ ਸਕਦਾ ਹੈ। ਉਦਾਹਰਨ ਲਈ, Koder.ai ਟੀਮਾਂ ਨੂੰ ਚੈਟ ਰਾਹੀਂ ਵੈੱਬ ਐਪਸ (React), ਬੈਕਐਂਡ (Go + PostgreSQL), ਅਤੇ ਮੋਬਾਇਲ ਐਪਸ (Flutter) ਬਣਾਉਣ ਦੀ ਆਸਾਨੀ ਦਿੰਦਾ ਹੈ—ਫਿਰ "ਇਨਪੁੱਟ → ਮਾਡਲ → ਟੂਲ ਕਾਲਜ਼ → ਵੈਰੀਫਿਕੇਸ਼ਨ → UI" ਵਰਗੇ ਫਲੋਜ਼ 'ਤੇ ਇਤੇਰੈਟ ਕਰਨ ਲਈ ਪਲੈਨਿੰਗ ਮੋਡ, ਸਨੇਪਸ਼ਾਟ, ਅਤੇ ਰੋਲਬੈਕ ਵਰਗੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਦੇ ਨਾਲ।

ਬਹੁ-ਕਦਮੀ ਟਾਸਕਾਂ ਲਈ ਸਟੇਟ ਮਸ਼ੀਨਾਂ

ਟ੍ਰਾਇਜੇ → ਜਾਣਕਾਰੀ ਇਕੱਠੀ ਕਰੋ → ਪੁਸ਼ਟੀ ਕਰੋ → ਨਿਭਾਉ → ਸਾਰ—ਜੇਵੇਂ ਬਹੁ-ਕਦਮੀ ਅਨੁਭਵ ਸਟੇਟ ਮਸ਼ੀਨ ਜਾਂ ਵਰਕਫਲੋ ਵਜੋਂ ਸਭ ਤੋਂ ਵਧੀਆ ਕੰਮ ਕਰਦੇ ਹਨ।

ਸਧਾਰਨ ਪੈਟਰਨ: ਹਰ ਕਦਮ ਲਈ (1) ਮਨਜ਼ੂਰਸ਼ੁਦਾ ਇਨਪੁੱਟ, (2) ਉਮੀਦ ਕੀਤੀ ਆਊਟਪੁੱਟ, ਅਤੇ (3) ਟ੍ਰਾਂਜ਼ਿਸ਼ਨ। ਇਹ ਭਟਕਦਾ ਸੰਵਾਦ ਰੋਕਦਾ ਹੈ ਅਤੇ ਐਜ ਕੇਸ ਨੂੰ ਸਪਸ਼ਟ ਬਣਾਉਂਦਾ ਹੈ—ਉਦਾਹਰਨ ਲਈ, ਯੂਜ਼ਰ ਮਨ ਬਦਲ ਲੈਂਦਾ ਹੈ ਜਾਂ ਕਿਸੇ ਨੇ ਅਧੂਰਾ ਡੇਟਾ ਦਿੱਤਾ।

ਇਕੱਲੀ ਕੋਸ਼ਿਸ਼ ਵਿਰੁੱਧ ਬਹੁ-ਟਰੰਸ ਸੋਚ

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

ਬਹੁ-ਟਰੰਸ ਸੋਚ ਉਸ ਵੇਲੇ ਚੰਗੀ ਹੈ ਜਦ ਮਾਡਲ ਨੂੰ ਸਪਸ਼ਟੀਕਰਣ ਪ੍ਰਸ਼ਨ ਪੁੱਛਣੇ ਪੈਂਦੇ ਹਨ ਜਾਂ ਜਦ ਟੂਲਾਂ ਨੂੰ ਇਤਰਾਟਿਵ ਤਰੀਕੇ ਨਾਲ ਵਰਤਿਆ ਜਾਣਾ ਲਾਜ਼ਮੀ ਹੋ (ਉਦਾਹਰਨ: ਯੋਜਨਾ → ਸਰਚ → ਸੁਧਾਰ → ਪੁਸ਼ਟੀ)। ਇਸਦੀ ਵਰਤੋਂ ਇਰਾਦੇ ਨਾਲ ਕਰੋ ਅਤੇ ਲੂਪਾਂ ਨੂੰ ਸਮਾਂ/ਕਦਮ ਸੀਮਿਤ ਰੱਖੋ।

ਆਈਡੈਂਪੋਟੈਂਸੀ: ਦੁਹਰਾਏ ਗਏ ਸਾਈਡ-ਐਫੈਕਟ ਤੋਂ ਬਚੋ

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

ਆਮ ਤਰੀਕੇ: ਹਰ "ਐਕਸੇਕਿਊਟ" ਕਾਰਵਾਈ ਨਾਲ ਇੱਕ idempotency ਕੁੰਜੀ ਜੁੜੋ, ਕਾਰਵਾਈ ਨਤੀਜੇ ਨੂੰ ਸਟੋਰ ਕਰੋ, ਅਤੇ ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਰਿਟ੍ਰਾਈਜ਼ ਇੱਕੋ ਨਤੀਜੇ ਨੂੰ ਹੀ ਵਾਪਸ ਕਰਨ ਤਾਂ ਜੋ ਮੁੜ-ਦੁਹਰਾਈ ਨਾ ਹੋਵੇ।

ਟਰੇਸ: ਹਰ ਕਦਮ ਡੀਬੱਗ ਕਰਨ ਯੋਗ ਬਣਾਓ

ਇਹ ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਤੁਸੀਂ ਪੂਛ ਸਕੋ: ਮਾਡਲ ਨੇ ਕੀ ਦੇਖਿਆ? ਇਸਨੇ ਕੀ ਫੈਸਲਾ ਕੀਤਾ? ਕਿਹੜੇ ਟੂਲ ਚਲਾਏ ਗਏ?

ਇੱਕ ਸੰਰਚਿਤ ਟਰੇਸ ਪਰ ਰਨ ਲੌਗ ਕਰੋ: ਪ੍ਰਾਂਪਟ ਵਰਜਨ, ਇਨਪੁੱਟ, ਰੀਟਰੀਵਡ ਕਾਂਟੈਕਸਟ IDs, ਟੂਲ ਬੇਨਤੀ/ਜਵਾਬ, ਵੈਰੀਫਿਕੇਸ਼ਨ ਐਰਰ, ਰਿਟ੍ਰਾਈਜ਼ ਅਤੇ ਆਖਰੀ ਆਊਟਪੁੱਟ। ਇਹ "AI ਨੇ ਕੁਝ ਅਜਿਹਾ ਕੀਤਾ" ਨੂੰ ਆਡਿਟਯੋਗ, ਠੀਕ ਕਰਨ ਯੋਗ ਟਾਈਮਲਾਈਨ ਵਿੱਚ ਬਦਲ ਦਿੰਦਾ ਹੈ।

ਪ੍ਰਾਂਪਟਿੰਗ ਨੂੰ ਉਤਪਾਦ ਲਾਜ਼ਿਕ ਵਜੋਂ ਵਰਤੋ: ਸਪੱਸ਼ਟ ਠੇਕੇ ਅਤੇ ਫਾਰਮੇਟ

ਜਦੋਂ ਮਾਡਲ ਤੁਹਾਡੇ ਐਪ ਲਾਜ਼ਿਕ ਦਾ ਹਿੱਸਾ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਤੁਹਾਡੇ ਪ੍ਰਾਂਪਟ "ਕਾਪੀ" ਤੋਂ ਬਦਲਕੇ ਐਗਜ਼ੀਕਯੂਟੇਬਲ ਵਿਸ਼ੇਸ਼ਣ ਬਣ ਜਾਂਦੇ ਹਨ। ਉਨ੍ਹਾਂ ਨੂੰ ਉਤਪਾਦ ਲੋੜਾਂ ਵਾਂਗ ਸਲੋਪ ਕਰੋ: ਸਪੱਸ਼ਟ ਸਕੋਪ, ਪੇਸ਼ਗੀ ਡਾਊਟਮਾਈਜ਼ੇਸ਼ਨ, ਅਤੇ ਚੇਂਜ ਕੰਟਰੋਲ।

ਕੰਟ੍ਰੈਕਟ ਨੂੰ ਨਿਰਧਾਰਤ ਕਰਨ ਵਾਲਾ ਸਿਸਟਮ ਪ੍ਰਾਂਪਟ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ

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

ਸ਼ਾਮِل ਕਰੋ:

• ਭੂਮਿਕਾ ਅਤੇ ਲਕਸ਼: ਇਹ ਕੌਣ ਹੈ (ਉਦਾਹਰਨ: "ਸਪੋਰਟ ਟਰਾਇਜ ਅਸਿਸਟੈਂਟ") ਅਤੇ ਸਫਲਤਾ ਕਿਵੇਂ ਦਿੱਸੀ ਜਾਏਗੀ।
• ਸਕੋਪ ਬਾਊਂਡਰੀਜ਼: ਕਿਹੜੇ ਬੇਨਤੀਆਂ ਨੂੰ ਇਨਕਾਰ ਜਾਂ ਐਸਕਲੇਟ ਕਰਨਾ ਹੈ।
• ਸੁਰੱਖਿਆ ਨਿਯਮ: PII ਹੈਂਡਲਿੰਗ, ਮੈਡੀਕਲ/ਕਾਨੂੰਨੀ ਡਿਸਕਲੈਮਰ, ਅਨੁਮਾਨ ਨਾ ਕਰਨਾ।
• ਟੂਲ ਨੀਤੀ: ਕਦੋਂ ਟੂਲ ਕਾਲ करनी ਹੈ ਅਤੇ ਕਦੋਂ ਸਿੱਧਾ ਜਵਾਬ ਦੇਣਾ ਹੈ।

ਇਨਪੁੱਟ/ਆਊਟਪੁੱਟ ਦੇ ਸਪਸ਼ਟ ਫਾਰਮੇਟ ਨਾਲ ਪ੍ਰਾਂਪਟ ਬਣਾਓ

ਪ੍ਰਾਂਪਟਾਂ ਨੂੰ API ਪਰਿਭਾਸ਼ਾਵਾਂ ਵਾਂਗ ਲਿਖੋ: ਉਹ ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ ਦਰਸਾਓ ਕਿ ਤੁਸੀਂ ਕੀ ਇਨਪੁੱਟ ਦੇ ਰਹੇ ਹੋ (ਯੂਜ਼ਰ ਟੈਕਸਟ, ਅਕਾਊਂਟ ਟੀਅਰ, ਲੋਕੇਲ, ਨੀਤੀ ਸਨਿੱਪੇਟ) ਅਤੇ ਤੁਸੀਂ ਠੀਕ ਕੀ ਆਊਟਪੁੱਟ ਉਮੀਦ ਕਰਦੇ ਹੋ। 1–3 ਉਦਾਹਰਨ ਸ਼ਾਮِل ਕਰੋ ਜੋ ਅਸਲੀ ਟ੍ਰੈਫਿਕ ਨਾਲ ਮਿਲਦੇ ਹੋਣ, ਖਾਸ ਕਰਕੇ ਕਠਿਨ ਐਜ ਕੇਸ।

ਇੱਕ ਉਪਯੋਗ ਪੈਟਰਨ: ਕਾਂਟੈਕਸਟ → ਟਾਸਕ → ਸੀਮਾਵਾਂ → ਆਊਟਪੁੱਟ ਫਾਰਮੈਟ → ਉਦਾਹਰਨ।

ਮਸ਼ੀਨ-ਪਾਠਯੋਗ ਨਤੀਜਿਆਂ ਲਈ ਸੀਮਿਤ ਫਾਰਮੇਟ ਵਰਤੋ

ਜੇ ਕੋਡ ਨੂੰ ਆਉਟਪੁੱਟ 'ਤੇ ਕਾਰਵਾਈ करनी ਹੈ, ਤਾਂ ਨਾਰਟ ਪ੍ਰੋਸ ਨੂੰ ਉੱਪਰ ਨਿਰਭਰ ਨਾ ਕਰੋ। ਇੱਕ schema ਨਾਲ ਮੇਲ ਖਾਉਂਦੀ JSON ਮੰਗੋ ਅਤੇ ਹੋਰ ਕਿਸੇ ਚੀਜ਼ ਨੂੰ ਰੱਦ ਕਰੋ।

{
  "type": "object",
  "properties": {
    "intent": {"type": "string"},
    "confidence": {"type": "number", "minimum": 0, "maximum": 1},
    "actions": {
      "type": "array",
      "items": {"type": "string"}
    },
    "user_message": {"type": "string"}
  },
  "required": ["intent", "confidence", "actions", "user_message"],
  "additionalProperties": false
}

ਪ੍ਰਾਂਪਟਾਂ ਨੂੰ ਵਰਜਨ ਕਰੋ ਅਤੇ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਰੋਲ ਆਊਟ ਕਰੋ

ਪ੍ਰਾਂਪਟਾਂ ਨੂੰ ਵਰਜਨ ਕੰਟਰੋਲ ਵਿੱਚ ਰੱਖੋ, ਰਿਲੀਜ਼ ਟੈਗ ਕਰੋ, ਅਤੇ ਫੀਚਰ ਦੀ ਤਰ੍ਹਾਂ ਰੋਲ ਆਊਟ ਕਰੋ: ਸਟੇਜਡ ਡਿਪਲੋਇਮੈਂਟ, ਜਿੱਥੇ ਲੋੜੀਂਦਾ ਹੋਏ A/B, ਅਤੇ ਤੇਜ਼ ਰੋਲਬੈਕ। ਹਰ ਜਵਾਬ ਨਾਲ ਪ੍ਰਾਂਪਟ ਵਰਜਨ ਲੌਗ ਕਰੋ ਤਾਂ ਕਿ ਡੀਬੱਗਿੰਗ ਆਸਾਨ ਹੋਵੇ।

ਪ੍ਰਾਂਪਟ ਟੈਸਟ ਸੁੱਟ ਬਣਾਓ

ਛੋਟਾ, ਪ੍ਰਤੀਨਿਧੀ ਕੇਸਾਂ ਦਾ ਸੈੱਟ ਬਣਾਓ (ਹੈਪੀ ਪਾਥ, ਅਸਪਸ਼ਟ ਬੇਨਤੀਆਂ, ਨੀਤੀ ਉਲੰਘਣ, ਲੰਬੇ ਇਨਪੁੱਟ, ਵੱਖ-ਵੱਖ ਲੋਕੇਲ)। ਹਰ ਪ੍ਰਾਂਪਟ ਬਦਲਾਅ 'ਤੇ ਇਹਨਾਂ ਨੂੰ ਆਟੋਮੈਟਿਕ ਤੌਰ 'ਤੇ ਚਲਾਓ, ਅਤੇ ਜੇ ਆਉਟਪੁੱਟ ਕੰਟਰੈਕਟ ਤੋੜੇ ਤਾਂ build fail ਕਰੋ।

ਟੂਲ ਕਾਲਿੰਗ: ਮਾਡਲ ਫੈਸਲਾ ਕਰੇ, ਕੋਡ ਕਾਰਜ ਕਰੇ

ਟੂਲ ਕਾਲਿੰਗ ਇਹ ਵਧੀਆ ਤਰੀਕਾ ਹੈ ਜੋ ਜ਼ਿੰਮੇਵਾਰੀ ਵੰਡਦਾ ਹੈ: ਮਾਡਲ ਨਿਰਧਾਰਿਤ ਕਰਦਾ ਹੈ ਕਿ "ਕੀ" ਕਰਨਾ ਹੈ ਅਤੇ "ਕਿਹੜੀ" ਸਮਰੱਥਾ ਵਰਤਣੀ ਹੈ, ਜਦਕਿ ਤੁਹਾਡਾ ਐਪ ਕੋਡ ਕਾਰਵਾਈ ਕਰਦਾ ਹੈ ਅਤੇ ਜਾਂਚ ਕਰਦਾ ਹੈ।

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

ਇੱਕ ਛੋਟਾ, ਇਰਾਦੇ-ਭਰਪੂਰ ਟੂਲਸੈੱਟ ਡਿਜ਼ਾਈਨ ਕਰੋ

80% ਬੇਨਤੀਆਂ ਕਵਰ ਕਰਨ ਵਾਲੇ ਅਤੇ ਨਾਲ ਹੀ ਸੁਰੱਖਿਅਤ ਰਹਿਣ ਵਾਲੇ ਕੁਝ ਹਥਿਆਰਾਂ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ:

• ਸਰਚ (ਤੁਹਾਡੇ ਡੌਕਸ/ਹੈਲਪ ਸੈਂਟਰ) ਤਾਕਿ ਉਤਪਾਦ-ਸਵਾਲਾਂ ਦਾ ਜਵਾਬ ਦੇ ਸਕੇ
• DB ਲੁੱਕਅੱਪ (ਪਹਿਲਾਂ read-only) ਯੂਜ਼ਰ/ਅਕਾਊਂਟ/ਆਰਡਰ ਸਥਿਤੀ ਲਈ
• ਕੈਲਕੁਲੇਟਰ ਕੀਮਤਾਂ, ਕੁੱਲ, ਰੂਪਾਂਤਰਣ ਅਤੇ ਨਿਯਮ-ਅਧਾਰਿਤ ਗਣਿਤ ਲਈ
• ਟਿਕਟਿੰਗ ਜਦ ਯੂਜ਼ਰ ਨੂੰ ਮਨੁੱਖੀ ਫਾਲੋ-ਅੱਪ ਦੀ ਲੋੜ ਹੋਵੇ

ਹਰ ਟੂਲ ਦੀ ਮਕਸਦ ਨਾਰੋ ਰੱਖੋ। ਇੱਕ "ਕੁਝ ਵੀ" ਕਰਨ ਵਾਲਾ ਟੂਲ ਟੈਸਟ ਕਰਨ ਵਿਚ ਮੁਸ਼ਕਲ ਅਤੇ ਗਲਤ ਵਰਤੋਂ ਲਈ ਆਸਾਨ ਬਣ ਜਾਏਗਾ।

ਇਨਪੁੱਟ ਨੂੰ ਵੈਰੀਫਾਈ ਕਰੋ, ਆਉਟਪੁੱਟ ਨੂੰ ਸੈਨੀਟਾਈਜ਼ ਕਰੋ

ਮਾਡਲ ਨੂੰ ਇੱਕ ਅਣ-ਟਰੱਸਟ ਕੀਤੇ ਯੂਜ਼ਰ ਵਜੋਂ ਸੋਚੋ।

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

ਇਸ ਨਾਲ ਪ੍ਰਾਂਪਟ-ਇੰਜੈਕਸ਼ਨ ਖ਼ਤਰੇ ਘਟਦੇ ਹਨ ਅਤੇ ਅਚਾਨਕ ਡੇਟਾ ਲੀਕ ਹੋਣ ਦੀ ਸੰਭਾਵਨਾ ਘੱਟ ਹੋ ਜਾਂਦੀ ਹੈ।

ਹਰ ਟੂਲ ਲਈ ਅਨੁਮਤੀਆਂ ਅਤੇ ਦਰ-ਹੱਦ ਲਗਾਓ

ਹਰ ਟੂਲ ਨੂੰ ਲਾਗੂ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ:

• ਪ੍ਰਮਿਸ਼ਨ ਚੈੱਕ: ਕੌਣ ਕਿਸ ਰਿਕਾਰਡ ਤੇ ਕਿਹੜਾ ਐਕਸ਼ਨ ਕਰ ਸਕਦਾ ਹੈ
• ਰੇਟ ਲਿਮਿਟਸ: (ਪਰ ਯੂਜ਼ਰ/ਸੈਸ਼ਨ/ਟੂਲ) ਦੁਰੁਪਯੋਗ ਅਤੇ ਰਨਵੇਅ ਗਤੀ ਨੂੰ ਘਟਾਉਣ ਲਈ

ਜੇ ਟੂਲ ਸਟੇਟ ਬਦਲ ਸਕਦਾ ਹੈ (ਟਿਕਟਿੰਗ, ਰੀਫੰਡ), ਤਾਂ ਹੋਰ ਸਖ਼ਤ ਅਥੋਰਿਕੇਸ਼ਨ ਅਤੇ ਆਡਿਟ ਲੌਗ ਲਾਜ਼ਮੀ ਹਨ।

ਹਮੇਸ਼ਾ "ਕੋਈ ਟੂਲ ਨਹੀਂ" ਰਸਤਾ ਸਹਾਇਕ ਰੱਖੋ

ਕਈ ਵਾਰ ਸਭ ਤੋਂ ਵਧੀਆ ਕਾਰਵਾਈ ਕੁਝ ਨਹੀਂ ਕਰਨਾ ਹੁੰਦੀ: ਮੌਜੂਦਾ ਸੰਦਰਭ ਤੋਂ ਜਵਾਬ ਦੇਣਾ, ਸਪਸ਼ਟੀਕਰਣ ਪ੍ਰਸ਼ਨ ਪੁੱਛਣਾ, ਜਾਂ ਸੀਮਾਵਾਂ ਦੱਸ ਕੇ ਜਵਾਬ देना।

"ਬਿਨਾਂ ਟੂਲ" ਨੂੰ ਪਹਿਲ-ਸ਼੍ਰੇਣੀ ਨਤੀਜੇ ਵਜੋਂ ਰੱਖੋ ਤਾਂ ਕਿ ਮਾਡਲ ਫਾਲਸ-ਸਕਾਰਾ ਬਣਨ ਲਈ ਟੂਲ ਕਾਲ ਨਾ ਕਰੇ।

ਡੇਟਾ ਅਤੇ RAG: ਮਾਡਲ ਨੂੰ ਤੁਹਾਡੇ ਹਕੀਕਤ ਨਾਲ ਗ੍ਰਾਉਂਡ ਕਰੋ

ਜੇ ਤੁਹਾਡੇ ਉਤਪਾਦ ਦੇ ਜਵਾਬਾਂ ਨੂੰ ਤੁਹਾਡੀਆਂ ਨੀਤੀਆਂ, ਇਨਵੈਂਟਰੀ, ਕਰਾਰ ਜਾਂ ਅੰਦਰੂਨੀ ਜਾਣਕਾਰੀ ਨਾਲ ਮਿਲਾਉਣਾ ਲਾਜ਼ਮੀ ਹੈ, ਤਾਂ ਤੁਹਾਨੂੰ ਮਾਡਲ ਨੂੰ ਆਪਣੇ ਡੇਟਾ ਨਾਲ ਗ੍ਰਾਉਂਡ ਕਰਨ ਦਾ ਤਰੀਕਾ ਚਾਹੀਦਾ ਹੈ—ਸਿਰਫ਼ ਉਸ ਦੀ ਜਨਰਲ ਟ੍ਰੇਨਿੰਗ 'ਤੇ ਨਿਰਭਰ ਕਰਨ ਦੀ ਬਜਾਏ।

RAG, ਫਾਈਨ-ਟਿਊਨਿੰਗ ਅਤੇ ਸਧਾਰਨ ਸੰਦਰਭ ਵਿੱਚ ਫਰਕ

• ਸਧਾਰਨ ਸੰਦਰਭ (ਥੋੜੀ ਪੈਰਾਗ੍ਰਾਫ ਪ੍ਰਾਂਪਟ ਵਿੱਚ ਪੇਸਟ) ਉਸ ਵੇਲੇ ਚੰਗਾ ਹੈ ਜਦ ਗਿਆਨ ਥੋੜਾ, ਸਥਿਰ ਹੋ ਅਤੇ ਹਰ ਵਾਰੀ ਭੇਜਣ ਦਾ ਖਰਚ ਠੀਕ ਹੋਵੇ (ਉਦਾਹਰਨ: ਅਲੱਗ ਕੀਮਤ ਟੇਬਲ)।
• RAG (Retrieval-Augmented Generation) ਜ਼ਿਆਦਾ ਚੰਗਾ ਹੈ ਜਦ ਜਾਣਕਾਰੀ ਵੱਡੀ, ਬਾਰ-ਬਾਰ ਬਦਲਣ ਵਾਲੀ ਜਾਂ ਹਵਾਲੇ ਲੋੜਨ ਵਾਲੀ ਹੋਵੇ (ਜਿਵੇਂ: ਹੇਲਪ-ਕੇਂਦਰ ਆਰਟਿੱਕਲ, ਉਤਪਾਦ ਡੌਕਸ, ਖਾਤਾ-ਨਿਰਧਾਰਤ ਡੇਟਾ)।
• ਫਾਈਨ-ਟਿਊਨਿੰਗ ਉਹ ਵੇਲੇ ਚੰਗੀ ਹੈ ਜਦ ਤੁਸੀਂ ਲਗਾਤਾਰ ਢੰਗ/ਫਾਰਮੈਟ ਜਾਂ ਡੋਮੇਨ-ਨਿਸ਼ਚਿਤ ਪੈਟਰਨ ਚਾਹੁੰਦੇ ਹੋ; ਇਸਨੂੰ ਤੱਥ "ਸਟੋਰ" ਕਰਨ ਲਈ ਮੁੱਖ ਤਰੀਕਾ ਨਾ ਬਣਾਓ। ਇਸਨੂੰ ਮਾਡਲ ਦੀ ਲਿਖਤ ਦੀ ਕੁਨੂੰਨੀਅਤ/ਅਨੁਕੂਲਤਾ ਸੁਧਾਰਨ ਲਈ ਵਰਤੋ; ਅਪ-ਟੁ-ਡੇਟ ਸੱਚਾਈ ਲਈ RAG ਨਾਲ ਜੋੜੋ।

ਇਨਜੇਸ਼ਨ ਮੂਲ ਤੱਤ: ਚੰਕਿੰਗ, ਮੈਟਾਡੇਟਾ, ਤਾਜ਼ਗੀ

RAG ਦੀ ਗੁਣਵੱਤਾ ਅਕਸਰ ਇਨਜੇਸ਼ਨ ਦੀ ਸਮੱਸਿਆ ਹੁੰਦੀ ਹੈ।

ਦਸਤਾਵੇਜ਼ਾਂ ਨੂੰ ਮਾਡਲ ਲਈ ਉਪਰਯੁਕਤ ਆਕਾਰ ਦੇ ਚੰਕਾਂ ਵਿੱਚ ਵੰਡੋ (ਅਕਸਰ ਕੁੱਝ ਸੌ ਟੋਕਨ), ਆਮ ਤੌਰ 'ਤੇ ਕੁਦਰਤੀ ਬਾਧਾਵਾਂ (ਹੇਡਿੰਗ, FAQ ਐਨਟਰੀ) ਦੇ ਸਮਰੂਪ। ਮੈਟਾਡੇਟਾ ਰੱਖੋ: ਦਸਤਾਵੇਜ਼ ਦਾ ਸਿਰਲੇਖ, ਸੈਕਸ਼ਨ, ਉਤਪਾਦ/ਵਰਜ਼ਨ, ਦਰਸ਼ਕ, ਲੋਕੇਲ, ਅਤੇ ਅਨੁਮਤੀਆਂ।

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

ਹਵਾਲੇ ਅਤੇ ਪਰਖੀ ਹੋਈਆਂ ਜਵਾਬਾਂ

ਮਾਡਲ ਨੂੰ ਨਿਰਦੇਸ਼ ਦਿਓ ਕਿ ਉਹ ਹਵਾਲੇ ਦੇਵੇ: (1) ਜਵਾਬ, (2) ਸਨੇਪਸ਼ੌਟ ID/URLs ਦੀ ਲਿਸਟ, ਅਤੇ (3) ਇਕ ਭਰੋਸਾ ਬਿਆਨ।

ਜੇ ਰੀਟਰੀਵਲ ਕਮਜ਼ੋਰ ਹੋਵੇ, ਤਾਂ ਮਾਡਲ ਨੂੰ ਦੱਸੋ ਕਿ ਜੋ ਕੁਝ ਉਹ ਪੁષ્ટ ਨਹੀਂ ਕਰ ਸਕਦਾ ਉਹ ਦੱਸੇ ਅਤੇ ਅਗਲੇ ਕਦਮ ਪੇਸ਼ ਕਰੇ ("ਮੈਨੂੰ ਉਹ ਨੀਤੀ ਨਹੀਂ ਮਿਲੀ; ਇਹਾਂ ਸੰਪਰਕ ਕਰੋ")। ਖਾਲੀ ਝਪਕੀਆਂ ਨਾਲ ਖਾਲੀ ਥਾਂ ਭਰਣ ਤੋਂ ਬਚੋ।

ਨਿੱਜੀ ਡੇਟਾ: ਐਕਸੈੱਸ ਕੰਟਰੋਲ ਅਤੇ ਰੈਡੈਕਸ਼ਨ

ਰੀਟਰੀਵਲ ਤੋਂ ਪਹਿਲਾਂ ਐਕਸੈੱਸ ਲਾਗੂ ਕਰੋ (ਯੂਜ਼ਰ/ਆਰਗ ਪਰਮੀਸ਼ਨਾਂ ਦੁਆਰਾ ਫਿਲਟਰ ਕਰੋ) ਅਤੇ ਜਨਰੇਸ਼ਨ ਤੋਂ ਪਹਿਲਾਂ ਫਿਰ ਵੈਰੀਫਾਈ/ਰੈਡੈਕਟ ਕਰੋ (ਸੰਵੇਦਨਸ਼ੀਲ ਖੇਤਰਾਂ ਨੂੰ ਛਾਨੜੋ)।

ਐਂਬੈਡਿੰਗ ਅਤੇ ਇੰਡੈਕਸਾਂ ਨੂੰ ਭੀ ਸੰਵੇਦਨਸ਼ੀਲ ਸਟੋਰ ਵਜੋਂ ਰੱਖੋ ਅਤੇ ਉਨ੍ਹਾਂ 'ਤੇ ਆਡਿਟ ਲੌਗ ਰੱਖੋ।

ਰੀਟਰੀਵਲ ਫੇਲ ਹੋਣ 'ਤੇ: ਨਰਮ ਫਾਲਬੈਕ

ਜੇ ਸਿਖਰ ਨਤੀਜੇ ਅਸੰਬੰਧਤ ਜਾਂ ਖਾਲੀ ਹੋਣ, ਤਾਂ ਵਿਗੜੇ ਹਾਲਾਤ ਵਿੱਚ: ਸਪਸ਼ਟੀਕਰਣ ਪ੍ਰਸ਼ਨ ਪੁੱਛੋ, ਮਨੁੱਖੀ ਸਹਾਇਤਾ ਨੂੰ ਰੂਟ ਕਰੋ, ਜਾਂ ਇੱਕ ਗੈਰ-RAG ਜਵਾਬ ਮੋਡ 'ਤੇ ਬਦਲੋ ਜੋ ਅਨੁਮਾਨ ਕਰਨ ਦੀ ਬਜਾਏ ਸੀਮਾਵਾਂ ਨੂੰ ਸਮਝਾਏ।

ਭਰੋਸੇਯੋਗਤਾ: ਗਾਰਡਰੇਲਜ਼, ਵੈਰੀਫਿਕੇਸ਼ਨ, ਅਤੇ ਕੇਸ਼ਿੰਗ

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

ਫਿਕਸ ਲਗਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਭਰੋਸੇ ਦੇ ਲਕਸ਼ ਨਿਰਧਾਰਿਤ ਕਰੋ

ਫੀਚਰ ਲਈ "ਭਰੋਸੇਯੋਗ" ਕੀ ਮਤਲਬ ਹੈ ਉਹ ਲਿਖੋ:

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

ਇਹ ਲਕਸ਼ ਪ੍ਰਾਂਪਟ ਅਤੇ ਕੋਡ ਲਈ ਐਕਸੈਪਟੈਂਸ ਕਰਾਈਟਰੀਆ ਬਣ ਜਾਂਦੇ ਹਨ।

ਗਾਰਡਰੇਲਜ਼: ਵੈਰੀਫਾਈ, ਛਾਣਣਾ, ਅਤੇ ਨੀਤੀਆਂ ਲਾਗੂ ਕਰੋ

ਮਾਡਲ ਆਉਟਪੁੱਟ ਨੂੰ ਅਣ-ਟਰੱਸਟ ਦਾਖਲਾ ਮੰਨੋ।

• ਸਕੀਮਾ ਵੈਲਿਡੇਸ਼ਨ: ਸਖ਼ਤ ਫਾਰਮੈਟ (ਜੈਸਾ JSON ਨਾਲ ਲਾਜ਼ਮੀ ਕੁੰਜੀਆਂ) ਦੀ ਮੰਗ ਕਰੋ ਅਤੇ ਜੋ ਵੀ ਪਾਰਸ ਨਾ ਹੋਵੇ ਉਹ ਰੱਦ ਕਰੋ।
• ** ਸਮੱਗਰੀ ਫਿਲਟਰ:** ਗਾਲੀ-ਗਲੋਚ, PII ਡਿਰੈਕਟਰ, ਜਾਂ ਨੀਤੀ ਵੇਰੀਫਾਇਰ ਨੂੰ ਯੂਜ਼ਰ ਇਨਪੁੱਟ ਅਤੇ ਮਾਡਲ ਆਉਟਪੁੱਟ ਦੋਹਾਂ 'ਤੇ ਚਲਾਓ।
• ਬਿਜ਼ਨਸ ਰੂਲ: ਕੋਡ ਵਿੱਚ ਸੇਇ ਫਰੇਂਟ-ਅੰਕੜੇ ਲਾਉ (ਕਿਮਤ ਰੇਂਜ, ਯੋਗਤਾ ਨਿਯਮ) ਭਾਵੇਂ ਪ੍ਰਾਂਪਟ ਉਨ੍ਹਾਂ ਦਾ ਜ਼ਿਕਰ ਕਰ ਰਿਹਾ ਹੋਵੇ।

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

ਉਹ ਰਿਟ੍ਰਾਈਜ਼ ਜੋ ਅਸਲ ਵਿੱਚ ਫਾਇਦੇਮੰਦ ਹਨ

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

• "ਸਿਰਫ਼ ਵੈਧ JSON ਵਾਪਸ ਕਰੋ। ਕੋਈ ਮਾਰਕਡਾਉਨ ਨਹੀਂ।"
• "ਜੇ ਪੱਕਾ ਨਾ ਹੋਵੇ ਤਾਂ confidence ਨੂੰ low ਰੱਖੋ ਅਤੇ ਇੱਕ ਪ੍ਰਸ਼ਨ ਪੁੱਛੋ।"

ਰਿਟ੍ਰਾਈਜ਼ ਨੂੰ ਸੀਮਿਤ ਕਰੋ ਅਤੇ ਹਰ ਅਸਫਲਤਾ ਲਈ ਕਾਰਨ ਲੌਗ ਕਰੋ।

ਨਿਰਧਾਰਿਤ ਪੋਸਟ-ਪ੍ਰੋਸੈਸਿੰਗ

ਕੋਡ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਮਾਡਲ ਦ੍ਵਾਰਾ ਪੈਦਾ ਕੀਤੇ ਨਤੀਜਿਆਂ ਨੂੰ ਨਾਰਮਲਾਈਜ਼ ਕਰੋ:

• ਯੂਨਿਟ, ਤਾਰੀਖਾਂ ਅਤੇ ਨਾਮ canonicalize ਕਰੋ
• ਆਈਟਮ ਡਿਊਪਲੀਕੇਟ ਕਰੋ
• ਰੈਂਕਿੰਗ ਨਿਯਮ ਜਾਂ ਥਰੈਸ਼ਹੋਲਡ ਲਗਾਓ

ਇਸ ਨਾਲ ਵੈਰੀਅੰਸ ਘਟਦੀ ਹੈ ਅਤੇ ਆਉਟਪੁੱਟ ਟੇਸਟ ਕਰਨ ਯੋਗ ਬਣ ਜਾਂਦਾ ਹੈ।

ਪ੍ਰਾਈਵੇਸੀ ਸਮੱਸਿਆਵਾਂ ਤੋਂ ਬਿਨਾਂ ਕੇਸ਼ਿੰਗ

ਦੋਹਰਾਏ ਜਾਂਦੇ ਨਤੀਜੇ (ਇਕੋ ਕੁਇਰੀ, ਸਾਂਝੇ ਐਂਬੈਡਿੰਗ, ਟੂਲ ਜਵਾਬ) ਨੂੰ ਕੇਸ਼ ਕਰੋ ਤਾਂ ਕਿ ਖਰਚ ਤੇ ਲੈਟੈਂਸੀ ਘਟੇ।

ਪਸੰਦ:

• ਯੂਜ਼ਰ-ਨਿਰਧਾਰਤ ਡੇਟਾ ਲਈ ਛੋਟੀ TTLs
• ਕੇਸ਼ ਕੁੰਜੀਆਂ ਜੋ ਰਾ PII ਨੂੰ ਸ਼ਾਮਿਲ ਨਾ ਕਰਨ (ਜਾਂ ਧਿਆਨ ਨਾਲ ਹੈਸ਼ ਕਰੋ)
• ਸੰਵੇਦਨਸ਼ੀਲ ਫ਼ਲੋਜ਼ ਲਈ "ਕੇਸ਼ ਨਾ ਕਰੋ" ਫਲੈਗ

ਠੀਕ ਤਰੀਕੇ ਨਾਲ ਕੀਤੇ ਗਿਆ, ਕੇਸ਼ਿੰਗ ਸਥਿਰਤਾ ਤੇ ਭਰੋਸਾ ਦੋਹਾਂ ਵਿੱਚ ਸੁਧਾਰ ਲਿਆਉਂਦੀ ਹੈ।

ਸੁਰੱਖਿਆ ਅਤੇ ਭਰੋਸਾ: UX ਨੂੰ ਮਾਰਨ ਬਿਨਾਂ ਰਿਸਕ ਘਟਾਓ

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

ਮੁੱਖ ਸੁਰੱਖਿਆ ਚਿੰਤਾਵਾਂ ਜਿਨ੍ਹਾਂ ਲਈ ਡਿਜ਼ਾਈਨ ਕਰੋ

ਉਹ ਜੋਖਮ ਨਾਂ ਲਵੋ ਜੋ ਤੁਹਾਡੀ ਐਪ ਨੂੰ ਅਸਲ ਵਿੱਚ ਦਰਪੇਸ਼ ਹਨ, ਫਿਰ ਹਰ ਇੱਕ ਲਈ ਇੱਕ ਨਿਯੰਤਰਣ ਬਣਾਓ:

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

ਆਲਾਊਡ/ਬਲਾਕ ਕੀਟਾਪ + ਐਸਕਲੇਸ਼ਨ ਪਾਥ

ਆਪਣੀ ਉਤਪਾਦ ਨੀਤੀ ਲਿਖੋ ਜੋ ਅਮਲ ਵਿੱਚ ਲਾਈ ਜਾ ਸਕੇ। ਇਸਨੂੰ կոնਕ੍ਰੀਟ ਰੱਖੋ: ਸ਼੍ਰੇਣੀਆਂ, ਉਦਾਹਰਨ ਅਤੇ ਉਮੀਦ ਕੀਤੀ ਜਵਾਬੀ ਰਵਾਇਤ।

ਤਿੰਨ ਪੱਧਰ ਵਰਤੋ:

1. ਆਲਾਊਡ: ਸਧਾਰਨ ਤੌਰ 'ਤੇ ਜਵਾਬ ਦਿਓ।
2. ਰਿਸਟ੍ਰਿਕਟਿਡ: ਸੀਮਤ ਜਵਾਬ (ਜੈਸਾ ਕਿ ਢਾਂਚਾਗਤ ਜਾਣਕਾਰੀ ਹੀ ਦੇਣੀ ਹੈ, ਕੋਈ ਕਦਮ-ਬਾਈ-ਕਦਮ ਨਹੀਂ)।
3. ਬਲੌਕਡ: ਇਨਕਾਰ ਕਰੋ ਅਤੇ ਐਸਕਲੇਟ ਕਰੋ (ਸਹਾਇਤਾ, ਸਰੋਤ, ਜਾਂ ਮਨੁੱਖੀ ਏਜੰਟ)।

ਐਸਕਲੇਸ਼ਨ ਇੱਕ ਉਤਪਾਦ ਫਲੋ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਸਿਰਫ਼ ਇਕ ਇਨਕਾਰ ਸੁਨੇਹਾ ਨਹੀਂ। "ਇਕ ਵਿਅਕਤੀ ਨਾਲ ਗੱਲ ਕਰੋ" ਚੋਣ ਦਿਓ ਅਤੇ ਯਕੀਨ ਬਣਾਓ ਕਿ ਹੱਥੋ-ਹੱਥ ਸੰਦੇਸ਼ ਉਹਨਾਂ ਸਾਂਝੇ ਕੀਤੇ ਸੰਦਰਭ ਨੂੰ ਸ਼ਾਮِل ਕਰਦਾ ਹੈ (ਸਹਿਮਤੀ ਨਾਲ)।

ਉੱਚ-ਪਰੇਨ ਪ੍ਰਭਾਵ ਵਾਲੇ ਕਾਰਵਾਈਆਂ ਲਈ ਮਨੁੱਖੀ ਸਮੀਖਿਆ

ਜੇ ਮਾਡਲ ਅਸਲ ਨਤੀਜੇ ਪੈਦਾ ਕਰ ਸਕਦਾ—ਭੁਗਤਾਨ, ਰੀਫੰਡ, ਖਾਤਾ ਬਦਲਾਅ, ਰੱਦ, ਡੇਟਾ ਮਿਟਾਉਣਾ—ਤਾਂ ਇੱਕ ਚੈਕਪੋਇੰਟ ਸ਼ਾਮِل ਕਰੋ।

ਛੰਗੇ ਪੈਟਰਨ: ਪੁਸ਼ਟੀ ਸਕਰੀਨ, "ਡ੍ਰਾਫਟ ਫਿਰ ਮਨਜ਼ੂਰ" ਮਾਡਲ, ਸੀਮਾਵਾਂ (ਰਕਮ ਕੈਪ), ਅਤੇ ਐਜ-ਕੇਸ ਲਈ ਮਨੁੱਖੀ ਸਮੀਖਿਆ ਕਤਾਰ।

ਖੁਲਾਸੇ, ਸਹਿਮਤੀ ਅਤੇ ਟੈਸਟਯੋਗ ਨੀਤੀਆਂ

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

ਅੰਦਰੂਨੀ ਸੁਰੱਖਿਆ ਨੀਤੀਆਂ ਨੂੰ ਕੋਡ ਵਾਂਗ ਰੱਖੋ: ਵਰਜਨ ਕਰੋ, ਕਾਰਨ ਦਰਜ ਕਰੋ, ਅਤੇ ਟੈਸਟ ਸ਼ਾਮِل ਕਰੋ (ਉਦਾਹਰਨ ਪ੍ਰਾਂਪਟ + ਉਮੀਦ ਕੀਤੀ ਨਤੀਜੇ) ਤਾਂ ਜੋ ਹਰ ਪ੍ਰਾਂਪਟ ਜਾਂ ਮਾਡਲ ਅੱਪਡੇਟ ਨਾਲ ਸੁਰੱਖਿਆ regress ਨਾ ਹੋਵੇ।

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

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

ਪ੍ਰਾਂਪਟ, ਮਾਡਲ ਵਰਜ਼ਨ, ਟੂਲ ਸਕੀਮ ਅਤੇ ਰੀਟ੍ਰੀਵਲ ਸੈਟਿੰਗਸ ਨੂੰ ਰਿਲੀਜ਼-ਯੋਗ ਆਰਟੀਫੈਕਟ ਵਜੋਂ ਵਰਤੋ ਜੋ ਟੈਸਟ ਮੰਗਦੇ ਹਨ।

ਅਸਲੀਅਤ ਤੋਂ ਮੁਲਾਂਕਣ ਸੈੱਟ ਬਣਾਓ

ਸਹਿਮਤੀ ਨਾਲ ਸਪੋਰਟ ਟਿਕਟਾਂ, ਸਰਚ ਕੁਇਰੀਜ਼, ਚੈਟ ਲੌਗ (ਜਿੱਥੇ ਲੋੜੀਂਦਾ ਹੋ) ਤੋਂ ਅਸਲੀ ਯੂਜ਼ਰ ਇਰਾਦੇ ਇਕੱਤਰ ਕਰੋ। ਉਨ੍ਹਾਂ ਨੂੰ ਟੈਸਟ ਕੇਸਾਂ ਵਿਚ ਬਦਲੋ ਜੋ ਸ਼ਾਮِل ਕਰਨ:

• ਆਮ ਹੈਪੀ-ਪਾਥ ਬੇਨਤੀਆਂ
• ਅਸਪਸ਼ਟ ਪ੍ਰਾਂਪਟ ਜਿਨ੍ਹਾਂ ਲਈ ਸਪਸ਼ਟੀਕਰਣ ਲੋੜੀਦਾ ਹੈ
• ਐਜ ਕੇਸ (ਘੱਟ ਡੇਟਾ, ਵਿਸ਼ਮਤ ਨਿਯਮ, ਅਜਿਹੇ ਫਾਰਮੇਟ)
• ਨੀਤੀ-ਸੰਵੇਦਨਸ਼ੀਲ ਸਥਿਤੀਆਂ (ਪ੍ਰਾਈਵੇਟ ਡੇਟਾ, ਨਿਰੋਧਿਤ ਸਮੱਗਰੀ)

ਹਰ ਕੇਸ ਵਿਚ ਉਮੀਦ ਕੀਤੀ ਵਿਵਹਾਰ ਸ਼ਾਮِل ਹੋਵੇ: ਜਵਾਬ, ਲਿਆ ਗਿਆ ਫੈਸਲਾ (ਜੈਸਾ "ਟੂਲ A ਨੂੰ ਕਾਲ ਕਰੋ"), ਅਤੇ ਲਾਜ਼ਮੀ ਸੰਗਠਨ (JSON ਖੇਤਰ, ਹਵਾਲੇ)।

ਉਤਪਾਦ ਜੋਖਮ ਨਾਲ ਮਿਲਦੇ ਮੈਟ੍ਰਿਕ ਚੁਣੋ

ਇੱਕ ਸਕੋਰ ਗੁਣਵੱਤਾ ਨਹੀਂ ਦੱਸੇਗਾ। ਛੋਟੇ ਮੈਟ੍ਰਿਕਸ ਲੈੋ ਜੋ ਯੂਜ਼ਰ ਨਤੀਜਿਆਂ ਨਾਲ ਜੁੜੇ ਹੋਣ:

• ਸ਼ੁੱਧਤਾ / ਟਾਸਕ ਸਫਲਤਾ: ਕੀ ਯੂਜ਼ਰ ਦਾ ਲਕਸ਼ ਪੂਰਾ ਹੋਇਆ?
• ਗ੍ਰਾਊਂਡਡਨੈਸ: ਕੱਥੇ ਮਾਡਲ ਦੇ ਦਾਅਵੇ ਸਪੋਰਟ ਕੀਤੇ ਸੰਦਰਭ/ਸਰੋਤਾਂ ਨਾਲ ਹਨ?
• ਫਾਰਮੈਟ ਵੈਧਤਾ: ਕੀ ਆਉਟਪੁੱਟ ਕੰਟਰੈਕਟ ਨੂੰ ਮਿਲਦਾ ਹੈ (JSON, ਟੇਬਲ, ਬੁੱਲੇਟ)?
• ਇਨਕਾਰ ਦਰ: ਜਦੋ ਇਸਨੂੰ ਇਨਕਾਰ ਕਰਨਾ ਚਾਹੀਦਾ ਸੀ, ਕੀਤਾ ਕਿ ਨਹੀਂ—ਅਤੇ ਉਲਟ।

ਲਾਗਤ ਅਤੇ ਲੈਟੈਂਸੀ ਨੂੰ ਵੀ ਟ੍ਰੈਕ ਕਰੋ; ਇਕ "ਬਿਹਤਰ" ਮਾਡਲ ਜੋ ਜਵਾਬ ਦਾ ਸਮਾਂ ਦਗਣਾ ਕਰ ਦੇਵੇ ਉਹ ਰੂਪਾਂਤਰਣ ਨੂੰ ਘਟਾ ਸਕਦਾ ਹੈ।

ਹਰ ਬਦਲਾਵ ਲਈ ਆਫਲਾਈਨ ਮੁਲਾਂਕਣ ਚਲਾਓ

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

ਨਿਗਰਾਨੀ ਨਾਲ ਆਨਲਾਈਨ ਟੈਸਟ ਵੀ ਕਰਾਓ

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

ਪ੍ਰੋਡਕਸ਼ਨ ਵਿੱਚ ਮਾਨੀਟਰਿੰਗ: ਡਰਿਫਟ, ਫੇਲਯੁਰ, ਅਤੇ ਫੀਡਬੈਕ

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

ਗੁਪਤ ਨੁਕਸਾਨ ਬਿਨਾਂ ਜ਼ਰੂਰੀ ਚੀਜ਼ਾਂ ਲੌਗ ਕਰੋ

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

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

ਸਹੀ ਸਿਗਨਲਾਂ 'ਤੇ ਨਜ਼ਰ ਰੱਖੋ

ਏਰਰ ਰੇਟ, ਟੂਲ ਫੇਲਿਯਰ, ਸਕੀਮਾ ਉਲੰਘਣ, ਅਤੇ ਡਰਿਫਟ ਨੂੰ ਮਾਨੀਟਰ ਕਰੋ। ਖਾਸ ਤੌਰ 'ਤੇ ਟਰੇਕ ਕਰੋ:

• ਟੂਲ-ਕਾਲ ਸਫਲਤਾ ਦਰ ਅਤੇ ਟਾਈਮਆਉਟ
• ਆਉਟਪੁੱਟ ਫਾਰਮੈਟ/ਸਕੀਮਾ ਦੀ ਪਾਲਣਾ
• ਫਾਲਬੈਕ ਵਰਤੋਂ ਦੀ ਮਾਤਰਾ
• ਸਮੱਗਰੀ ਸੁਰੱਖਿਆ ਬਲੌਕਸ

ਡਰਿਫਟ ਲਈ, ਮੌਜੂਦਾ ਟ੍ਰੈਫਿਕ ਨੂੰ ਬੇਸਲਾਈਨ ਨਾਲ ਤੁਲਨਾ ਕਰੋ: ਵਿਸ਼ੇ ਵਿੱਚ ਬਦਲਾਅ, ਭਾਸ਼ਾ, ਔਸਤ ਪ੍ਰਾਂਪਟ ਲੰਬਾਈ, ਅਤੇ "ਅਣਜਾਣ" ਇਰਾਦੇ ਵਿੱਚ ਬਦਲਾਅ। ਡਰਿਫਟ ਹਮੇਸ਼ਾ ਮਾੜੀ ਨਹੀਂ ਹੁੰਦੀ—ਪਰ ਇਹ ਮੁੜ-ਪੜਤਾਲ ਕਰਨ ਦਾ ਇਸ਼ਾਰਾ ਹੈ।

ਅਲਰਟਸ, ਰਨਬੁਕਸ, ਅਤੇ ਇੰਸੀਡੈਂਟ ਰਿਸਪਾਂਸ

ਅਲਰਟ ਥ੍ਰੈਸ਼ਹੋਲਡ ਅਤੇ ਆਨ-ਕਾਲ ਰਨਬੁਕ ਤਿਆਰ ਕਰੋ। ਅਲਰਟਾਂ ਨੂੰ ਕਾਰਵਾਈਆਂ ਨਾਲ ਜੋੜੋ: ਪ੍ਰਾਂਪਟ ਵਰਜ਼ਨ ਰੋਲਬੈਕ, ਫਲੇਕੀ ਟੂਲ ਨੂੰ ਅਸਥਾਈ ਤੌਰ 'ਤੇ ਬੰਦ ਕਰਨਾ, ਵੈਰੀਫਿਕੇਸ਼ਨ ਨੂੰ ਕਸ ਕੀਤਾ, ਜਾਂ ਫਾਲਬੈਕ 'ਤੇ ਸਵਿੱਚ ਕਰਨਾ।

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

ਉਪਭੋਗਤਾ ਫੀਡਬੈਕ ਨਾਲ ਲੂਪ ਨੂੰ ਬੰਦ ਕਰੋ

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

ਮਾਡਲ-ਚਲਿਤ ਲਾਜ਼ਿਕ ਲਈ UX: ਪਾਰਦਰਸ਼ਤਾ ਅਤੇ ਨਿਯੰਤਰਣ

ਜਦੋਂ ਉਹ ਕੰਮ ਕਰਦੇ ਹਨ ਤਾਂ ਮਾਡਲ-ਚਲਿਤ ਫੀਚਰ ਜਾਦੂਈ ਮਹਿਸੂਸ ਹੁੰਦੇ ਹਨ—ਤੇ ਜਦੋਂ ਨਹੀਂ ਤਾਂ ਨਾਜ਼ੁਕ। UX ਨੂੰ ਅਸਪਸ਼ਟਤਾ ਮਨ ਕੇ ਵੀ ਯੂਜ਼ਰ ਨੂੰ ਕੰਮ ਪੂਰਾ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਨ ਦੀ ਯੋਜਨਾ ਬਣਾਉਣੀ ਚਾਹੀਦੀ ਹੈ।

ਲੋਕਾਂ ਨੂੰ "ਕਿਉਂ" ਦਿਖਾਓ ਬਿਨਾਂ ਓਹਨਾਂ ਨੂੰ ਥੱਕਾਉਣ ਦੇ

ਜਦੋਂ ਉਪਭੋਗਤਾ ਦੇਖਦੇ ਹਨ ਕਿ ਨਤੀਜਾ ਕਿੱਥੋਂ ਆਇਆ, ਉਹ ਆਉਟਪੁੱਟ 'ਤੇ ਜ਼ਿਆਦਾ ਭਰੋਸਾ ਕਰਦੇ ਹਨ—ਨਾ ਕਿ ਇਕ ਲੈਕਚਰ ਲਈ, ਪਰ ਇਹ ਫੈਸਲਾ ਕਰਨ ਵਿੱਚ ਸਹਾਇਤਾ ਦਿੰਦਾ ਹੈ।

ਪ੍ਰੋਗ੍ਰੈਸੀਵ ਡਿਸਕਲੋਜ਼ਰ ਵਰਤੋ:

• ਨਤੀਜਾ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ (ਜਵਾਬ, ਡ੍ਰਾਫਟ, ਸਿਫਾਰਸ਼)
• ਇੱਕ "ਕਿਉਂ?" ਜਾਂ "ਸ਼ੋ ਵਰਕ" ਟੌਗਲ ਦਿਓ ਜੋ ਮੁੱਖ ਇਨਪੁੱਟ: ਯੂਜ਼ਰ ਦੀ ਬੇਨਤੀ, ਕਿਸੇ ਵੀ ਟੂਲ ਦੀ ਵਰਤੋਂ, ਅਤੇ ਪ੍ਰਵੇਸ਼ ਕੀਤੇ ਸਰੋਤ/ਰੇਕਾਰਡ ਦਿਖਾਏ।
• ਜੇ ਤੁਸੀਂ ਰੀਟ੍ਰੀਵਲ ਵਰਤਦੇ ਹੋ, ਤਾਂ ਹਵਾਲੇ ਦਿਖਾਓ ਜੋ ਸਿੱਧਾ ਸਨਿੱਪੇਟ ਨੂੰ ਖੋਲ੍ਹਦੇ ਹਨ (ਉਦਾਹਰਨ: "ਅਧਾਰ: ਨੀਤੀ §3.2"). ਇਹ skim ਕਰਨ ਯੋਗ ਹੋਵੇ।

ਜੇ ਤੁਹਾਡੇ ਕੋਲ ਡੂੰਘਾ ਵਿਆਖਿਆਕਾਰ ਹੋਵੇ, ਤਾਂ ਉਹਨੂੰ ਅੰਦਰੂਨੀ ਲਿੰਕ ਵਿੱਚ ਰੱਖੋ (ਜਿਵੇਂ blog/rag-grounding) ਨਾ ਕਿ UI ਨੂੰ ਬਹੁਤ ਭਰੋ।

ਦਿਸ਼ਾ-ਅਨਿਸ਼ਚਿਤਤਾ ਲਈ ਡਿਜ਼ਾਈਨ (ਬਿਨਾਂ ਡਰਾਉਣ ਵਾਲੇ ਚੇਤਾਵਨੀ)

ਮਾਡਲ ਗਣਨਾ ਵਾਲਾ ਮੰਸ਼ਾ ਨਹੀਂ ਹੈ। ਇੰਟਰਫੇਸ ਨੂੰ ਭਰੋਸਾ ਦਿੱਸਣ ਅਤੇ ਜਾਂਚ ਕਰਨ ਲਈ ਕਮਿूਨਿਕੇਟ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ।

ਪ੍ਰਯੋਗੀ ਪੈਟਰਨ:

• ਸਧਾਰਨ ਭਾਸ਼ਾ ਵਿੱਚ ਭਰੋਸਾ ਇਸ਼ਾਰੇ ("ਸਭ ਤੋਂ ਸੰਭਵ", "ਸਮੀਖਿਆ ਲੋੜੀਂਦੀ")—ਅਸਲ ਨਿੱਜੀ ਸੰਖਿਆਵਾਂ ਦੀ ਝੂਠੀ ਸ਼ੁੱਧਤਾ ਤੋਂ ਬਚੋ।
• ਵਿਕਲਪ ਦਿਖਾਓ, ਇਕਲੋਤਾ ਜਵਾਬ ਨਹੀਂ: "ਇਹ ਰਹੇ 3 ਜਵਾਬ"। ਇਹ ਪਹਿਲਾ ਗਲਤ ਹੋਣ ਦੀ ਲਾਗਤ ਘਟਾਉਂਦਾ ਹੈ।
• ਉੱਚ-ਪ੍ਰਭਾਵੀ ਕਾਰਵਾਈਆਂ ਲਈ ਪੁਸ਼ਟੀ (ਈਮੇਲ ਭੇਜਣਾ, ਡੇਟਾ ਮਿਟਾਉਣਾ, ਭੁਗਤਾਨ). ਸਪਸ਼ਟ ਪ੍ਰਸ਼ਨ ਪੁੱਛੋ: "ਕੀ ਤੁਸੀਂ 12 ਪ੍ਰਾਪਤਕਰਤਿਆਂ ਨੂੰ ਇਹ ਸੁਨੇਹਾ ਭੇਜਣਾ ਚਾਹੁੰਦੇ ਹੋ?"

ਸੋਧ ਅਤੇ ਬਹਾਲੀ ਆਸਾਨ ਬਣਾਓ

ਯੂਜ਼ਰ ਆਉਟਪੁੱਟ ਨੂੰ ਬਿਨਾਂ ਮੁੜ ਸ਼ੁਰੂ ਕੀਤੇ ਗਤੀਸ਼ੀਲ ਤਰੀਕੇ ਨਾਲ ਸਟੀਅਰ ਕਰ ਸਕਣ:

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

ਇੱਕ ਐਸਕੇਪ ਹੈਚ ਦਿਓ

ਜਦ ਮਾਡਲ ਫੇਲ ਕਰੇ—ਜਾਂ ਯੂਜ਼ਰ ਨਿਸ਼ਚਿਤ ਨਾ ਹੋ—ਦਾ deterministic ਫਲੋ ਜਾਂ ਮਨੁੱਖੀ ਮਦਦ ਦੀ ਚੋਣ ਦਿਓ।

Examples: "ਹੱਥ ਨਾਲ ਫਾਰਮ 'ਤੇ ਸਵਿੱਚ ਕਰੋ", "ਟੈਂਪਲੇਟ ਵਰਤੋ", ਜਾਂ "Contact support" (e.g., /support)। ਇਹ ਕੋਈ ਸ਼ਰਮਨਾਕ ਫਾਲਬੈਕ ਨਹੀਂ; ਇਹ ਕੰਪਲੀਸ਼ਨ ਅਤੇ ਭਰੋਸੇ ਦੀ ਰੱਖਿਆ ਹੈ।

ਪ੍ਰੋਟੋਟਾਈਪ ਤੋਂ ਪ੍ਰੋਡਕਸ਼ਨ ਤੱਕ (ਬਿਨਾਂ ਹਰ ਚੀਜ਼ ਮੁੜ ਬਣਾਏ)

ਜ਼ਿਆਦਾਤਰ ਟੀਮਾਂ ਫੇਲ ਨਹੀਂ ਹੁੰਦੀਆਂ ਕਿਉਂਕਿ LLM ਅਸਮਰੱਥ ਹਨ; ਉਹ ਫੇਲ ਹੁੰਦੀਆਂ ਹਨ ਕਿਉਂਕਿ ਪ੍ਰੋਟੋਟਾਈਪ ਤੋਂ ਭਰੋਸੇਯੋਗ, ਟੈਸਟਯੋਗ ਅਤੇ ਮਾਨੀਟਰਯੋਗ ਫੀਚਰ ਤੱਕ ਰਸਤਾ ਲੰਮਾ ਹੁੰਦਾ ਹੈ।

ਇੱਕ ਪ੍ਰਯੋਗੀ ਤਰੀਕਾ ਰਸਤੇ ਨੂੰ ਛੋਟਾ ਕਰਨ ਦੀ ਇਹ ਹੈ ਕਿ ਜਲਦੀ ਹੀ "ਉਤਪਾਦ ਢਾਂਚਾ" ਨੂੰ ਮਨਿਆ ਜਾਵੇ: ਸਟੇਟ ਮਸ਼ੀਨ, ਟੂਲ ਸਕੀਮਾ, ਵੈਲਿਡੇਸ਼ਨ, ਟਰੇਸ ਅਤੇ ਡਿਪਲੋਏ/ਰੋਲਬੈਕ ਕਹਾਣੀ। ਜਦ ਤੁਸੀਂ ਤੇਜ਼ੀ ਨਾਲ ਇੱਕ AI-ਪਹਿਲਾ ਵਰਕਫਲੋ ਉਤਪਨ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ ਤਾਂ ਪਲੇਟਫਾਰਮਾਂ ਜਿਵੇਂ Koder.ai ਮਦਦਗਾਰ ਹੋ ਸਕਦੇ ਹਨ—ਜਦੋਂ ਤੁਸੀਂ UI, ਬੈਕਐਂਡ, ਅਤੇ ਡੇਟਾਬੇਸ ਇਕੱਠੇ ਤੌਰ 'ਤੇ ਤੇਜ਼ੀ ਨਾਲ ਬਣਾਉਣਾ ਚਾਹੁੰਦੇ ਹੋ—ਫਿਰ ਸਨੇਪਸ਼ਾਟ/ਰੋਲਬੈਕ, ਕਸਟਮ ਡੋਮੇਨਾਂ ਅਤੇ ਹੋਸਟਿੰਗ ਨਾਲ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਇਤਰੈਟ ਕਰੋ। ਜਿਵੇਂ ਤੁਸੀਂ ਆਪਰੇਸ਼ਨਲ ਬਣਨ ਲਈ ਤਿਆਰ ਹੋ, ਤੁਸੀਂ ਸਰੋਤ ਕੋਡ ਐਕਸਪੋਰਟ ਕਰਕੇ ਆਪਣੇ ਮਨਪਸੰਦ CI/CD ਅਤੇ ਮਾਨੀਟਰਿੰਗ ਸਟੈਕ ਨਾਲ ਜਾਰੀ ਰੱਖ ਸਕਦੇ ਹੋ।