ਲਾਭ:
- ਡਿਜ਼ਾਇਨ ਕਰ ਸਕਦਾ ਹੈ ਕਿ ਕਿਵੇਂ ਸਿਸਟਮ ਪ੍ਰੋਂਪਟ ਪੂਰੀ ਗੱਲਬਾਤ ਰਾਹੀਂ ਮਾਡਲ ਦੀ ਅਗਵਾਈ ਕਰਦਾ ਹੈ
- ਅਨੁਕੂਲ ਸੋਚ ਅਤੇ ਕੋਸ਼ਿਸ਼ ਦੇ ਮਾਪਦੰਡਾਂ ਦੀ ਭੂਮਿਕਾ ਅਤੇ ਲਾਗਤ ਪ੍ਰਭਾਵ ਨੂੰ ਸਮਝਦਾ ਹੈ
- ਆਉਟਪੁੱਟ ਨਿਯੰਤਰਣਾਂ ਨੂੰ ਲਾਗੂ ਕਰਦਾ ਹੈ ਜਿਵੇਂ ਕਿ max_tokens, stop sequences, ਅਤੇ structured output
ਇੱਕੋ ਮਾਡਲ ਦੇ ਦੋ ਵੱਖ-ਵੱਖ ਉਤਪਾਦ ਪੂਰੀ ਤਰ੍ਹਾਂ ਵੱਖਰੇ ਢੰਗ ਨਾਲ ਵਿਹਾਰ ਕਰ ਸਕਦੇ ਹਨ। ਫਰਕ ਆਪਣੇ ਆਪ ਮਾਡਲ ਵਿੱਚ ਨਹੀਂ ਹੈ, ਪਰ ਸਿਸਟਮ ਪ੍ਰੋਂਪਟ ਅਤੇ ਇਸ ਨੂੰ ਦਿੱਤੇ ਪੈਰਾਮੀਟਰਾਂ ਵਿੱਚ ਹੈ। ਸਿਸਟਮ ਪ੍ਰੋਂਪਟ ਮਾਡਲ ਦਾ "ਕੰਮ ਦਾ ਇਕਰਾਰਨਾਮਾ" ਹੈ ਅਤੇ ਪੈਰਾਮੀਟਰ "ਵਰਕ ਸੈਟਿੰਗ" ਹਨ। ਇਸ ਯੂਨਿਟ ਵਿੱਚ, ਤੁਸੀਂ ਸਿੱਖੋਗੇ ਕਿ ਇੱਕ ਸ਼ਕਤੀਸ਼ਾਲੀ ਸਿਸਟਮ ਪ੍ਰੋਂਪਟ ਨੂੰ ਕਿਵੇਂ ਡਿਜ਼ਾਈਨ ਕਰਨਾ ਹੈ, ਆਧੁਨਿਕ ਮਾਡਲਾਂ ਵਿੱਚ ਸੋਚ ਅਤੇ ਕੋਸ਼ਿਸ਼ ਸੈਟਿੰਗਾਂ ਕੀ ਕਰਦੀਆਂ ਹਨ, ਅਤੇ ਫਾਰਮੈਟ/ਲੰਬਾਈ ਲਈ ਆਉਟਪੁੱਟ ਨੂੰ ਕਿਵੇਂ ਨਿਯੰਤਰਿਤ ਕਰਨਾ ਹੈ। ਇਹਨਾਂ ਸੈਟਿੰਗਾਂ ਨੂੰ ਸਹੀ ਢੰਗ ਨਾਲ ਸੈੱਟ ਕਰਨਾ ਤੁਹਾਨੂੰ ਇੱਕੋ ਸਮੇਂ 'ਤੇ ਗੁਣਵੱਤਾ ਅਤੇ ਲਾਗਤ ਦੋਵਾਂ ਦਾ ਪ੍ਰਬੰਧਨ ਕਰਨ ਦਿੰਦਾ ਹੈ।
ਸਿਸਟਮ ਪ੍ਰੋਂਪਟ: ਮਾਡਲ ਦਾ ਸਥਾਈ ਨਿਰਦੇਸ਼
ਸਿਸਟਮ ਪ੍ਰੋਂਪਟ ਉੱਚ-ਪੱਧਰੀ ਹਦਾਇਤ ਹੈ ਜੋ ਸਾਰੀ ਗੱਲਬਾਤ ਦੌਰਾਨ ਲਾਗੂ ਹੁੰਦੀ ਹੈ। ਇਹ ਨਿਯਮ ਵੈਧ ਰਹਿੰਦੇ ਹਨ ਭਾਵੇਂ ਉਪਭੋਗਤਾ ਕਿਸ ਕਿਸਮ ਦਾ ਹੋਵੇ। ਇੱਕ ਚੰਗੇ ਸਿਸਟਮ ਪ੍ਰੋਂਪਟ ਵਿੱਚ ਹੇਠਾਂ ਦਿੱਤੇ ਭਾਗ ਸ਼ਾਮਲ ਹੁੰਦੇ ਹਨ:
- ਭੂਮਿਕਾ/ਪਛਾਣ: ਮਾਡਲ ਕੌਣ ਹੈ? ("ਤੁਸੀਂ ਇੱਕ ਕਾਰਪੋਰੇਟ ਸਹਾਇਤਾ ਸਹਾਇਕ ਹੋ।")
- ਸਕੋਪ ਅਤੇ ਸੀਮਾ: ਇਹ ਕੀ ਕਰਦਾ ਹੈ ਅਤੇ ਕੀ ਨਹੀਂ ਕਰਦਾ? ("ਸਿਰਫ਼ ਪ੍ਰਦਾਨ ਕੀਤੇ ਗਏ ਪਾਲਿਸੀ ਦਸਤਾਵੇਜ਼ 'ਤੇ ਆਧਾਰਿਤ।")
- ਫਾਰਮੈਟ ਨਿਯਮ: ਆਉਟਪੁੱਟ ਕਿਹੋ ਜਿਹੀ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ? ("ਵੱਧ ਤੋਂ ਵੱਧ 3 ਲੇਖ, ਸਰਕਾਰੀ ਭਾਸ਼ਾ।")
- ਅਨਿਸ਼ਚਿਤਤਾ ਵਿੱਚ ਵਿਵਹਾਰ: ਅਨਿਸ਼ਚਿਤ ਹੋਣ 'ਤੇ ਕੋਈ ਕੀ ਕਰਦਾ ਹੈ? ("ਜੇਕਰ ਕੋਈ ਜਾਣਕਾਰੀ ਨਹੀਂ ਹੈ, ਤਾਂ ਇਸਨੂੰ ਬਣਾਉ, ਇਸ ਨੂੰ ਸਬੰਧਤ ਯੂਨਿਟ ਨੂੰ ਭੇਜੋ।")
- ਸੁਰੱਖਿਆ/ਗੋਪਨੀਯਤਾ: ਕੀ ਨਹੀਂ ਚਾਹੁੰਦਾ/ਨਹੀਂ ਚਾਹੁੰਦਾ? ("ਨਿੱਜੀ ਡੇਟਾ ਦੀ ਬੇਨਤੀ ਕਰੋ।")
ਸੁਝਾਅ: ਸਿਸਟਮ ਪ੍ਰੋਂਪਟ ਨੂੰ ਸਥਿਰ ਰੱਖੋ। ਹਰੇਕ ਬੇਨਤੀ (ਮੌਜੂਦਾ ਮਿਤੀ, ਉਪਭੋਗਤਾ ਨਾਮ, ਸੈਸ਼ਨ ID) ਨਾਲ ਬਦਲਦੀ ਜਾਣਕਾਰੀ ਨੂੰ ਏਮਬੇਡ ਨਾ ਕਰੋ। ਇਹ ਦੋਵੇਂ ਇਕਸਾਰਤਾ ਨੂੰ ਤੋੜਦਾ ਹੈ ਅਤੇ ਯੂਨਿਟ 6 'ਤੇ ਪ੍ਰੋਂਪਟ ਕੈਸ਼ ਨੂੰ ਅਯੋਗ ਬਣਾਉਂਦਾ ਹੈ। ਉਪਭੋਗਤਾ ਸੰਦੇਸ਼ ਵਿੱਚ ਵੇਰੀਏਬਲ ਜਾਣਕਾਰੀ ਪਾਓ।
ਬਹੁਤ ਜ਼ਿਆਦਾ ਹਮਲਾਵਰ ਹਦਾਇਤਾਂ ਦਾ ਜਾਲ
ਆਧੁਨਿਕ ਮਾਡਲ ਨਿਰਦੇਸ਼ਾਂ ਦੀ ਬਹੁਤ ਧਿਆਨ ਨਾਲ ਪਾਲਣਾ ਕਰਦੇ ਹਨ. "ਮਸਟ", "ਹਮੇਸ਼ਾ", "ਨਿਸ਼ਚਤ ਤੌਰ 'ਤੇ ਇਹ ਕਰੋ", ਆਦਿ ਵਰਗੇ ਹਮਲਾਵਰ ਵਾਕਾਂਸ਼, ਜੋ ਪੁਰਾਣੇ ਮਾਡਲਾਂ ਵਿੱਚ ਕੰਮ ਕਰਦੇ ਸਨ, ਅੱਜ ਓਵਰਟ੍ਰਿਗਰਿੰਗ ਵੱਲ ਲੈ ਜਾਂਦੇ ਹਨ: ਮਾਡਲ ਇੱਕ ਏਜੰਟ ਨੂੰ ਕਾਲ ਕਰਦਾ ਹੈ ਜਦੋਂ ਇਸਦੀ ਲੋੜ ਨਹੀਂ ਹੁੰਦੀ ਹੈ ਜਾਂ ਬੇਲੋੜੇ ਲੰਬੇ ਸਮੇਂ ਲਈ ਚੱਲਦਾ ਹੈ। ਨਿਯਮ ਨੂੰ ਨਰਮ ਕਰੋ: "ਸਰਚ ਟੂਲ ਦੀ ਵਰਤੋਂ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ" ਦੀ ਬਜਾਏ, "ਜੇਕਰ ਜਵਾਬ ਗੱਲਬਾਤ ਵਿੱਚ ਨਹੀਂ ਹੈ, ਤਾਂ ਖੋਜ ਟੂਲ ਦੀ ਵਰਤੋਂ ਕਰੋ" ਵਧੇਰੇ ਸਹੀ ਹੈ।
ਮਾਡਲ ਪੈਰਾਮੀਟਰ: ਸੋਚ ਅਤੇ ਕੋਸ਼ਿਸ਼
ਕਲਾਸੀਕਲ LLM ਦਾ ਇੱਕ ਤਾਪਮਾਨ ਮਾਪਦੰਡ ਹੁੰਦਾ ਹੈ: ਇੱਕ ਘੱਟ ਮੁੱਲ ਵਧੇਰੇ ਖਾਸ/ਇਕਸਾਰ ਆਉਟਪੁੱਟ ਪੈਦਾ ਕਰਦਾ ਹੈ, ਇੱਕ ਉੱਚ ਮੁੱਲ ਹੋਰ ਵਿਭਿੰਨ/ਰਚਨਾਤਮਕ ਆਉਟਪੁੱਟ ਪੈਦਾ ਕਰਦਾ ਹੈ। ਆਧੁਨਿਕ ਪੀੜ੍ਹੀ ਦੇ ਮਾਡਲ (ਜਿਵੇਂ ਕਿ ਓਪਸ 4.8, ਸੋਨੈੱਟ 5) ਇਸ ਪਹੁੰਚ ਨੂੰ ਦੋ ਹੋਰ ਸ਼ਕਤੀਸ਼ਾਲੀ ਵਿਧੀਆਂ ਨਾਲ ਬਦਲਦੇ ਹਨ ਅਤੇ ਹੁਣ ਤਾਪਮਾਨ ਵਰਗੇ ਸੈਂਪਲਿੰਗ ਮਾਪਦੰਡਾਂ ਨੂੰ ਸਵੀਕਾਰ ਨਹੀਂ ਕਰਦੇ ਹਨ।
- ਅਨੁਕੂਲ ਸੋਚ: ਮਾਡਲ ਜਵਾਬ ਦੇਣ ਤੋਂ ਪਹਿਲਾਂ ਆਪਣੇ "ਸਿਰ" ਵਿੱਚ ਕਦਮ ਦਰ ਕਦਮ ਦਰਸਾਉਂਦਾ ਹੈ। ਮਾਡਲ ਫੈਸਲਾ ਕਰਦਾ ਹੈ ਕਿ ਕੰਮ ਦੀ ਮੁਸ਼ਕਲ ਦੇ ਅਧਾਰ 'ਤੇ ਕਿੰਨਾ ਸੋਚਣਾ ਹੈ। ਮਹੱਤਵਪੂਰਨ ਤੌਰ 'ਤੇ ਗੁੰਝਲਦਾਰ, ਬਹੁ-ਪੜਾਵੀ ਸਮੱਸਿਆਵਾਂ 'ਤੇ ਸ਼ੁੱਧਤਾ ਨੂੰ ਸੁਧਾਰਦਾ ਹੈ; ਉਹ ਸਧਾਰਨ ਸਵਾਲਾਂ 'ਤੇ ਬੇਲੋੜੀ ਦੇਰੀ ਤੋਂ ਬਚਣ ਲਈ ਘੱਟ ਸੋਚਦਾ ਹੈ।
- ਕੋਸ਼ਿਸ਼: ਉੱਚ-ਪੱਧਰੀ ਨੋਬ ਜੋ ਵਿਵਸਥਿਤ ਕਰਦੀ ਹੈ ਕਿ ਮਾਡਲ ਇੱਕ ਕੰਮ ਵਿੱਚ ਕਿੰਨੀ ਡੂੰਘਾਈ ਨਾਲ ਡੁੱਬਦਾ ਹੈ ਅਤੇ ਕੁੱਲ ਕਿੰਨੇ ਟੋਕਨ ਖਰਚ ਕਰਦਾ ਹੈ। ਆਮ ਪੱਧਰ: ਨੀਵਾਂ, ਦਰਮਿਆਨਾ, ਉੱਚਾ ਅਤੇ ਉੱਪਰ। ਉੱਚ ਕੋਸ਼ਿਸ਼ ਗੁਣਵੱਤਾ ਵਿੱਚ ਸੁਧਾਰ ਕਰ ਸਕਦੀ ਹੈ, ਪਰ ਇਹ ਦੇਰੀ ਅਤੇ ਲਾਗਤ ਨੂੰ ਵੀ ਵਧਾਉਂਦੀ ਹੈ; ਘੱਟ ਜਤਨ ਗਤੀ ਅਤੇ ਬੱਚਤ ਲਿਆਉਂਦਾ ਹੈ।
ਸੈਟਿੰਗ
ਕੀ ਕਰਦਾ ਹੈ
ਜਦੋਂ
ਸੋਚਣਾ ਬੰਦ/ਘੱਟ ਕੋਸ਼ਿਸ਼
ਤੇਜ਼, ਸਸਤੀ, ਸਤਹੀ
ਸਧਾਰਨ ਵਰਗੀਕਰਨ, ਛੋਟਾ ਜਵਾਬ, ਸੰਵੇਦਨਸ਼ੀਲ ਕਾਰਜਾਂ ਵਿੱਚ ਦੇਰੀ
ਅਨੁਕੂਲ ਸੋਚ + ਦਰਮਿਆਨੀ ਕੋਸ਼ਿਸ਼
ਸੰਤੁਲਿਤ ਗੁਣਵੱਤਾ/ਕੀਮਤ
ਜ਼ਿਆਦਾਤਰ ਆਮ ਉਦੇਸ਼ ਕਾਰਜ
ਅਨੁਕੂਲ ਸੋਚ + ਉੱਚ ਕੋਸ਼ਿਸ਼
ਸਭ ਤੋਂ ਵੱਧ ਸ਼ੁੱਧਤਾ
ਗੁੰਝਲਦਾਰ ਤਰਕ, ਕੋਡਿੰਗ, ਲੰਬੀ-ਸੀਮਾ ਏਜੰਟ ਦਾ ਕੰਮ
ਸਾਵਧਾਨ: "ਵੱਧ ਤੋਂ ਵੱਧ ਕੋਸ਼ਿਸ਼ ਭਾਵੇਂ ਕੋਈ ਵੀ ਹੋਵੇ" ਰਿਫਲੈਕਸ ਲਾਗਤਾਂ ਨੂੰ ਵਧਾਉਂਦਾ ਹੈ। ਕੰਮ ਲਈ ਜਤਨ ਨੂੰ ਵਿਵਸਥਿਤ ਕਰੋ; ਸਧਾਰਣ ਕੰਮਾਂ ਵਿੱਚ, ਘੱਟ ਮਿਹਨਤ ਅਕਸਰ ਬਹੁਤ ਸਸਤੀ ਕੀਮਤ 'ਤੇ ਉਹੀ ਸਹੀ ਨਤੀਜਾ ਦਿੰਦੀ ਹੈ। ਉੱਚੇ ਜਾਓ ਜਿੱਥੇ ਗੰਭੀਰ ਸ਼ੁੱਧਤਾ ਦੀ ਲੋੜ ਹੈ।
ਆਉਟਪੁੱਟ ਕੰਟਰੋਲ: ਫਾਰਮੈਟ, ਲੰਬਾਈ, ਬਣਤਰ
ਪੈਰਾਮੀਟਰਾਂ ਤੋਂ ਇਲਾਵਾ, ਤੁਸੀਂ ਆਉਟਪੁੱਟ ਨੂੰ ਵੀ ਨਿਯੰਤਰਿਤ ਕਰਦੇ ਹੋ:
- max_tokens: ਆਉਟਪੁੱਟ ਦੀ ਸਖ਼ਤ ਛੱਤ (ਪਹਿਲੀ ਅਤੇ ਤੀਜੀ ਇਕਾਈ)।
- ਕ੍ਰਮ ਨੂੰ ਰੋਕੋ: ਮਾਡਲ ਨੂੰ ਰੋਕਣਾ ਜਦੋਂ ਇਹ ਇੱਕ ਖਾਸ ਸਤਰ ਨੂੰ ਵੇਖਦਾ ਹੈ। ਢਾਂਚਾਗਤ ਉਤਪਾਦਨ ਵਿੱਚ ਬਰੇਕਪੁਆਇੰਟ ਸੈੱਟ ਕਰਨ ਲਈ ਉਪਯੋਗੀ।
- ਸਟ੍ਰਕਚਰਡ ਆਉਟਪੁੱਟ: ਤੁਹਾਡੇ ਦੁਆਰਾ ਪ੍ਰਦਾਨ ਕੀਤੀ JSON ਸਕੀਮਾ ਦੇ ਅਨੁਕੂਲ ਹੋਣ ਲਈ ਮਾਡਲ ਦੇ ਜਵਾਬ ਨੂੰ ਮਜਬੂਰ ਕਰੋ। ਇਹ ਯਕੀਨੀ ਬਣਾਉਂਦਾ ਹੈ ਕਿ ਆਉਟਪੁੱਟ ਪ੍ਰੋਗਰਾਮੇਟਿਕ ਤੌਰ 'ਤੇ ਪਾਰਸਯੋਗ ਅਤੇ ਵੈਧ ਹੈ। ਇਹ ਇੱਕ ਪ੍ਰੋਂਪਟ ਨਾਲ "ਸਿਰਫ਼ JSON ਵਾਪਸ ਕਰੋ" ਕਹਿਣ ਨਾਲੋਂ ਵਧੇਰੇ ਭਰੋਸੇਯੋਗ ਹੈ।
{ "output_config": { "format": { "type": "json_schema", "schema": { "type": "object", "additionalProperties": false, "properties": { "category": { "type": "string", "enum": ["ਇਨਵੌਇਸ", "ਤਕਨੀਕੀ", "thereturn": "thereturn"}" "ਸਟ੍ਰਿੰਗ", "ਐਨਮ": ["ਘੱਟ", "ਮੱਧਮ", "ਉੱਚ"] } }, "ਲੋੜੀਂਦਾ": ["ਸ਼੍ਰੇਣੀ", "ਜ਼ਰੂਰੀ"] } }}}
ਕਾਪੀ ਕਰਨ ਯੋਗ ਸਿਸਟਮ ਪ੍ਰੋਂਪਟ ਟੈਂਪਲੇਟਸ
# ਕਾਰਪੋਰੇਟ ਸਹਾਇਤਾ ਸਹਾਇਕ ਤੁਸੀਂ ਇੱਕ ਕਾਰਪੋਰੇਟ ਸਹਾਇਤਾ ਸਹਾਇਕ ਹੋ।- ਪ੍ਰਦਾਨ ਕੀਤੇ ਗਏ ਨੀਤੀ ਦਸਤਾਵੇਜ਼ 'ਤੇ ਪੂਰੀ ਤਰ੍ਹਾਂ ਭਰੋਸਾ ਕਰੋ; ਜੇਕਰ ਇਹ ਦਸਤਾਵੇਜ਼ ਵਿੱਚ ਨਹੀਂ ਹੈ, ਤਾਂ ਕਹੋ "ਮੇਰੇ ਕੋਲ ਇਹ ਜਾਣਕਾਰੀ ਨਹੀਂ ਹੈ।" - ਅਧਿਕਤਮ 3 ਵਾਕਾਂ ਵਿੱਚ ਇੱਕ ਰਸਮੀ ਅਤੇ ਸਪਸ਼ਟ ਜਵਾਬ ਦਿਓ। - ਨਿੱਜੀ ਡੇਟਾ (TC ID ਨੰਬਰ, ਕਾਰਡ ਨੰਬਰ) ਲਈ ਪੁੱਛੋ ਅਤੇ ਇਸਨੂੰ ਆਪਣੇ ਜਵਾਬ ਵਿੱਚ ਨਾ ਦੁਹਰਾਓ। - ਜੇ ਤੁਹਾਨੂੰ ਯਕੀਨ ਨਹੀਂ ਹੈ, ਤਾਂ ਅੰਦਾਜ਼ਾ ਨਾ ਲਗਾਓ.
# ਸਟ੍ਰਕਚਰਡ ਆਉਟਪੁੱਟ ਫੋਰਸਿੰਗ ਕਲਾਸੀਫਾਇਰ ਤੁਸੀਂ ਇੱਕ ਡਿਮਾਂਡ ਕਲਾਸੀਫਾਇਰ ਹੋ। ਇੰਪੁੱਟ ਇੱਕ ਗਾਹਕ ਸੁਨੇਹਾ ਹੈ. ਸਿਰਫ਼ ਬੇਨਤੀ ਕੀਤੇ ਖੇਤਰਾਂ ਨੂੰ ਵਾਪਸ ਕਰੋ, ਟਿੱਪਣੀਆਂ ਨਾ ਲਿਖੋ। ਜੇਕਰ ਤੁਸੀਂ ਯਕੀਨੀ ਨਹੀਂ ਹੋ, ਤਾਂ "ਹੋਰ" ਦੀ ਵਰਤੋਂ ਕਰੋ।
# ਅਨਿਸ਼ਚਿਤਤਾ ਵਿੱਚ ਖੜੇ ਹੋਣ ਦੇ ਪਰਿਭਾਸ਼ਿਤ ਵਿਵਹਾਰ ਵਾਲਾ ਵਿਸ਼ਲੇਸ਼ਕ ਤੁਸੀਂ ਇੱਕ ਡੇਟਾ ਵਿਸ਼ਲੇਸ਼ਕ ਹੋ। ਪ੍ਰਦਾਨ ਕੀਤੀ ਸਾਰਣੀ ਤੋਂ ਸਿਰਫ਼ ਪ੍ਰਮਾਣਿਤ ਅਨੁਮਾਨਾਂ ਨੂੰ ਖਿੱਚੋ। ਕਦੇ ਵੀ ਅਜਿਹਾ ਸਿੱਟਾ ਨਾ ਕੱਢੋ ਜੋ ਡੇਟਾ ਵਿੱਚ ਮੌਜੂਦ ਨਹੀਂ ਹੈ। ਜੇਕਰ ਕੋਈ ਅਨੁਮਾਨ ਅਸਪਸ਼ਟ ਹੈ, ਤਾਂ "ਡਾਟਾ ਨਾਕਾਫ਼ੀ" ਲਿਖੋ।
# ਟੋਨ ਅਤੇ ਲੰਬਾਈ ਨਿਯੰਤਰਣ ਦੇ ਨਾਲ ਸਮਗਰੀ ਲੇਖਕ ਤੁਸੀਂ ਇੱਕ ਸਮਗਰੀ ਲੇਖਕ ਹੋ. ਨਿੱਘੇ ਪਰ ਪੇਸ਼ੇਵਰ ਟੋਨ ਦੀ ਵਰਤੋਂ ਕਰੋ। ਹਰੇਕ ਟੈਕਸਟ ਨੂੰ 120 ਜਾਂ ਘੱਟ ਸ਼ਬਦਾਂ ਤੱਕ ਸੀਮਤ ਕਰੋ। ਕਲੀਚ ਮਾਰਕੀਟਿੰਗ ਭਾਸ਼ਾ ਤੋਂ ਬਚੋ।
ਕਮਜ਼ੋਰ ਪ੍ਰੋਂਪਟ / ਮਜ਼ਬੂਤ ਪ੍ਰੋਂਪਟ
# WEAK ਮਦਦਗਾਰ ਬਣੋ ਅਤੇ ਚੰਗੇ ਜਵਾਬ ਦਿਓ। ਆਪਣੀ ਪੂਰੀ ਕੋਸ਼ਿਸ਼ ਕਰੋ।
# STRONGਰੋਲ: ਤਕਨੀਕੀ ਸਹਾਇਤਾ ਮਾਹਰ। ਸਕੋਪ: ਉਤਪਾਦ ਗਾਈਡ ਸਿਰਫ਼ ਪ੍ਰਦਾਨ ਕੀਤੀ ਗਈ ਹੈ। ਫਾਰਮੈਟ: ਕਦਮ-ਦਰ-ਕਦਮ, ਨੰਬਰ ਸੂਚੀ, 5 ਕਦਮ ਅਧਿਕਤਮ। ਸੀਮਾ: ਗਾਈਡ ਵਿੱਚ ਹੱਲ ਦੀ ਸਿਫਾਰਸ਼ ਨਹੀਂ ਕਰੋ; ਕਹੋ "ਮੈਨੂੰ ਮੈਨੂਅਲ ਵਿੱਚ ਇਹ ਨਹੀਂ ਮਿਲਿਆ।" ਗੋਪਨੀਯਤਾ: ਜਵਾਬ ਵਿੱਚ ਉਪਭੋਗਤਾ ਦੁਆਰਾ ਸਾਂਝੇ ਕੀਤੇ ਗਏ ਸੀਰੀਅਲ ਨੰਬਰ ਨੂੰ ਨਾ ਦੁਹਰਾਓ।
ਸ਼ਕਤੀਸ਼ਾਲੀ ਸੰਸਕਰਣ; ਇਹ ਭੂਮਿਕਾ, ਦਾਇਰੇ, ਫਾਰਮੈਟ, ਸੀਮਾਵਾਂ ਅਤੇ ਗੁਪਤਤਾ ਨੂੰ ਵੱਖਰੇ ਤੌਰ 'ਤੇ ਨਿਰਧਾਰਤ ਕਰਦਾ ਹੈ। ਆਉਟਪੁੱਟ ਇਕਸਾਰਤਾ ਇਸ ਸਪਸ਼ਟਤਾ ਤੋਂ ਸਿੱਧਾ ਆਉਂਦੀ ਹੈ।
ਤਿੰਨ ਮਿੰਨੀ ਕੇਸ
ਕੇਸ 1 - ਕੋਸ਼ਿਸ਼ਾਂ ਦੇ ਸਮਾਯੋਜਨ ਦੁਆਰਾ ਲਾਗਤ ਵਿੱਚ ਕਮੀ। ਇੱਕ ਟੀਮ ਉੱਚ ਕੋਸ਼ਿਸ਼ + ਸੋਚ 'ਤੇ ਆਪਣੇ ਸਾਰੇ ਕਾਲ ਚਲਾ ਰਹੀ ਸੀ; ਇੱਥੋਂ ਤੱਕ ਕਿ ਸਧਾਰਨ ਈਮੇਲ ਡਾਇਜੈਸਟ ਵੀ ਮਹਿੰਗੇ ਅਤੇ ਪੈਦਾ ਕਰਨ ਵਿੱਚ ਹੌਲੀ ਸਨ। ਉਹਨਾਂ ਨੇ ਸਧਾਰਨ ਕਾਰਜਾਂ ਨੂੰ ਨਿਰਧਾਰਤ ਕੀਤਾ ਜਿਵੇਂ ਕਿ ਘੱਟ ਕੋਸ਼ਿਸ਼ਾਂ ਲਈ ਸੰਖੇਪ ਅਤੇ ਉੱਚ ਕੋਸ਼ਿਸ਼ ਲਈ ਇਕਰਾਰਨਾਮੇ ਦਾ ਵਿਸ਼ਲੇਸ਼ਣ। ਸ਼ੁੱਧਤਾ ਬਣਾਈ ਰੱਖੀ ਗਈ ਸੀ, ਔਸਤ ਲੇਟੈਂਸੀ ਅੱਧੀ ਰਹਿ ਗਈ ਸੀ, ਅਤੇ ਮਹੀਨਾਵਾਰ ਲਾਗਤ ਇੱਕ ਤਿਹਾਈ ਤੱਕ ਘਟਾ ਦਿੱਤੀ ਗਈ ਸੀ।
ਕੇਸ 2 — JSON ਗਾਰੰਟੀ। ਇੱਕ ਓਪਰੇਸ਼ਨ ਟੀਮ ਨੇ "ਸਿਰਫ਼ JSON ਦਿਓ" ਕਹਿ ਕੇ ਵਰਗੀਕਰਣ ਆਉਟਪੁੱਟ ਲਈ ਕਿਹਾ, ਪਰ ਮਾਡਲ ਕਦੇ-ਕਦਾਈਂ "ਇੱਥੇ ਨਤੀਜਾ ਹੈ:" ਲਿਖਦਾ ਹੈ ਅਤੇ ਪਾਰਸਰ ਕਰੈਸ਼ ਹੋ ਜਾਵੇਗਾ। ਜਦੋਂ ਮੈਂ ਕੌਂਫਿਗਰ ਕੀਤੀ ਆਉਟਪੁੱਟ ਸਕੀਮਾ ਨੂੰ ਕਨੈਕਟ ਕੀਤਾ, ਤਾਂ ਆਉਟਪੁੱਟ ਨੇ ਹਰ ਵਾਰ ਵੈਧ JSON ਵਾਪਸ ਕੀਤਾ; ਪਾਰਸਿੰਗ ਗਲਤੀਆਂ ਰੀਸੈਟ ਕੀਤੀਆਂ ਗਈਆਂ ਹਨ।
ਕੇਸ 3 - ਹਮਲਾਵਰ ਪ੍ਰੋਂਪਟ ਰੀਕੋਇਲ। ਇੱਕ ਸਹਾਇਕ ਪ੍ਰੋਂਪਟ ਨੇ ਕਿਹਾ, "ਹਰ ਸਵਾਲ ਦੀ ਖੋਜ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ"; ਮਾਡਲ ਨੇ ਸਧਾਰਨ ਸਵਾਲਾਂ ਲਈ ਵੀ ਬੇਲੋੜੀਆਂ ਖੋਜਾਂ ਕੀਤੀਆਂ ਜਿਨ੍ਹਾਂ ਦੇ ਜਵਾਬ ਇਸ ਨੂੰ ਪਹਿਲਾਂ ਹੀ ਪਤਾ ਸੀ, ਹੌਲੀ ਹੋ ਰਹੀ ਹੈ ਅਤੇ ਲਾਗਤਾਂ ਵਧ ਰਹੀਆਂ ਹਨ। ਉਹਨਾਂ ਨੇ "ਜੇ ਜਵਾਬ ਸੰਦਰਭ ਵਿੱਚ ਨਹੀਂ ਹੈ, ਖੋਜ ਕਰੋ" ਦੇ ਨਿਯਮ ਵਿੱਚ ਢਿੱਲ ਦਿੱਤੀ; ਬੇਲੋੜੀਆਂ ਕਾਲਾਂ 70% ਘਟੀਆਂ ਅਤੇ ਜਵਾਬਾਂ ਵਿੱਚ ਤੇਜ਼ੀ ਆਈ।
ਆਮ ਗਲਤੀਆਂ
- ਸਿਸਟਮ ਪ੍ਰੋਂਪਟ ਵਿੱਚ ਵੇਰੀਏਬਲ ਡੇਟਾ ਨੂੰ ਏਮਬੈਡ ਕਰਨਾ: ਇਕਸਾਰਤਾ ਨੂੰ ਤੋੜਦਾ ਹੈ ਅਤੇ ਕੈਸ਼ ਨੂੰ ਅਵੈਧ ਕਰਦਾ ਹੈ।
- ਬਹੁਤ ਜ਼ਿਆਦਾ ਹਮਲਾਵਰ ਹਦਾਇਤ: ਆਧੁਨਿਕ ਮਾਡਲਾਂ ਵਿੱਚ ਬਹੁਤ ਜ਼ਿਆਦਾ ਟਰਿੱਗਰਿੰਗ ਅਤੇ ਬੇਲੋੜੀ ਲਾਗਤ।
- ਹਰ ਕੰਮ ਵਿੱਚ ਉੱਚ ਕੋਸ਼ਿਸ਼: ਸਧਾਰਨ ਕੰਮਾਂ ਵਿੱਚ ਬਰਬਾਦੀ; ਕੰਮ ਲਈ ਕੋਸ਼ਿਸ਼ ਨੂੰ ਵਿਵਸਥਿਤ ਕਰੋ.
- JSON ਨੂੰ ਸਿਰਫ਼ ਪ੍ਰੋਂਪਟ ਰਾਹੀਂ ਬੇਨਤੀ ਕਰਨਾ: ਇਹ ਕਦੇ-ਕਦਾਈਂ ਟੁੱਟ ਜਾਂਦਾ ਹੈ; ਜੇਕਰ ਨਾਜ਼ੁਕ ਹੋਵੇ, ਤਾਂ ਢਾਂਚਾਗਤ ਆਉਟਪੁੱਟ ਦੀ ਵਰਤੋਂ ਕਰੋ।
- ਸੀਮਾ/ਅਸਪਸ਼ਟਤਾ ਦੇ ਵਿਵਹਾਰ ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਨਹੀਂ ਕਰਨਾ: ਮਾਡਲ ਫੈਬਰੀਕੇਸ਼ਨ (ਭਰਮ) ਨਾਲ ਪਾੜੇ ਨੂੰ ਭਰਦਾ ਹੈ।
- ਪੁਰਾਣੀ 'ਤਾਪਮਾਨ' ਆਦਤ: ਆਧੁਨਿਕ ਮਾਡਲ ਇਸ ਨੂੰ ਸਵੀਕਾਰ ਨਹੀਂ ਕਰਦੇ; ਤੁਰੰਤ ਅਤੇ ਕੋਸ਼ਿਸ਼ ਨਾਲ ਵਿਵਹਾਰ ਦੀ ਅਗਵਾਈ ਕਰੋ।
ਡੂੰਘਾ: ਇਕਰਾਰਨਾਮੇ ਵਾਂਗ ਪ੍ਰੋਂਪਟ ਲਿਖਣਾ
ਤਜਰਬੇਕਾਰ ਟੀਮਾਂ ਸਿਸਟਮ ਪ੍ਰੋਂਪਟ ਨੂੰ ਇਕਰਾਰਨਾਮੇ ਵਾਂਗ ਵਰਤਦੀਆਂ ਹਨ, ਨਾ ਕਿ ਸਾਹਿਤਕ ਪਾਠ: ਸਪਸ਼ਟ ਧਾਰਾਵਾਂ, ਮਾਪਣਯੋਗ ਨਿਯਮ, ਅਸਪਸ਼ਟ ਸੀਮਾਵਾਂ। ਇਸ ਪਹੁੰਚ ਦੇ ਤਿੰਨ ਠੋਸ ਲਾਭ ਹਨ। ਪਹਿਲੀ ਇਕਸਾਰਤਾ ਹੈ: ਇੱਕੋ ਇੰਪੁੱਟ ਵੱਖ-ਵੱਖ ਸਮਿਆਂ 'ਤੇ ਸਮਾਨ ਆਉਟਪੁੱਟ ਦਿੰਦਾ ਹੈ। ਦੂਜਾ ਟੈਸਟਯੋਗਤਾ ਹੈ: ਤੁਸੀਂ ਹਰੇਕ ਆਈਟਮ ਨੂੰ ਨਮੂਨੇ ਨਾਲ ਵੱਖਰੇ ਤੌਰ 'ਤੇ ਜਾਂਚ ਸਕਦੇ ਹੋ। ਤੀਸਰਾ ਰੱਖ-ਰਖਾਅ ਦੀ ਸੌਖ ਹੈ: ਜੇਕਰ ਕੋਈ ਵਿਵਹਾਰ ਗਲਤ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਜਾਣਦੇ ਹੋ ਕਿ ਕਿਹੜੀ ਚੀਜ਼ ਨੂੰ ਬਦਲਣਾ ਹੈ।
ਇੱਕ ਚੰਗਾ ਅਭਿਆਸ ਸਕਾਰਾਤਮਕ ਉਦਾਹਰਣਾਂ ਨਾਲ ਅਗਵਾਈ ਕਰਨਾ ਹੈ। "ਇਹ ਨਾ ਕਰੋ" ਦੀ ਇੱਕ ਸੂਚੀ ਪ੍ਰਦਾਨ ਕਰਨ ਦੀ ਬਜਾਏ, ਇਹ ਆਧੁਨਿਕ ਮਾਡਲਾਂ ਵਿੱਚ ਇੱਕ ਉਦਾਹਰਣ ਪ੍ਰਦਾਨ ਕਰਨ ਲਈ ਵਧੇਰੇ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਹੈ ਜੋ ਕਹਿੰਦਾ ਹੈ ਕਿ "ਇਹ ਬਿਲਕੁਲ ਉਹੀ ਹੈ ਜਿਵੇਂ ਲੋੜੀਂਦਾ ਆਉਟਪੁੱਟ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ"। ਉਦਾਹਰਨ ਲਈ, ਇੱਕ ਵਰਗੀਕਰਣ ਵਿੱਚ, ਪ੍ਰੋਂਪਟ ਵਿੱਚ ਸੰਭਾਵਿਤ JSON ਦੇ ਇੱਕ ਜਾਂ ਦੋ ਨਮੂਨੇ ਸ਼ਾਮਲ ਕਰਨ ਨਾਲ ਫਾਰਮੈਟਿੰਗ ਗਲਤੀਆਂ ਨੂੰ ਮਹੱਤਵਪੂਰਣ ਰੂਪ ਵਿੱਚ ਘਟਾਇਆ ਜਾਂਦਾ ਹੈ।
ਇਕ ਹੋਰ ਸ਼ਕਤੀਸ਼ਾਲੀ ਤਕਨੀਕ ਅਨਿਸ਼ਚਿਤਤਾ ਵਿਵਹਾਰ ਨੂੰ ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ ਲਿਖਣਾ ਹੈ। ਇੱਕ ਧਾਰਾ ਜਿਵੇਂ ਕਿ "ਜੇ ਅਨਿਸ਼ਚਿਤ ਹੋ, ਅੰਦਾਜ਼ਾ ਨਾ ਲਗਾਓ; ਕਹੋ 'ਨਾਕਾਫ਼ੀ ਡੇਟਾ'" ਮਾਡਲ ਦੀ ਮਨਘੜਤ (ਭਰਮ) ਨਾਲ ਖਾਲੀ ਥਾਂ ਨੂੰ ਭਰਨ ਦੀ ਪ੍ਰਵਿਰਤੀ ਨੂੰ ਦਬਾਉਂਦੀ ਹੈ। ਇਹ ਇੱਕਲਾ ਵਾਕ ਪੁਸ਼ਟੀਕਰਨ ਪਰਤ ਨੂੰ ਆਫਲੋਡ ਕਰਦਾ ਹੈ, ਜਿਸ ਨੂੰ ਅਸੀਂ ਯੂਨਿਟ 11 ਵਿੱਚ ਕਵਰ ਕਰਾਂਗੇ: ਇੱਕ ਵਾਰ ਜਦੋਂ ਮਾਡਲ ਨੇ ਪਹਿਲਾਂ ਹੀ ਅਨਿਸ਼ਚਿਤਤਾ ਨੂੰ ਫਲੈਗ ਕੀਤਾ ਹੈ, ਤਾਂ ਮਨੁੱਖੀ ਪ੍ਰਮਾਣਿਕਤਾ ਵੱਲ ਲੈ ਜਾਣਾ ਆਸਾਨ ਹੋ ਜਾਂਦਾ ਹੈ।
ਅੰਤ ਵਿੱਚ, ਜਤਨ ਅਤੇ ਤੁਰੰਤ ਇਕੱਠੇ ਵਿਚਾਰ ਕਰੋ। ਉੱਚ ਕੋਸ਼ਿਸ਼ 'ਤੇ, ਮਾਡਲ ਵਧੇਰੇ ਖੋਜ ਕਰਦਾ ਹੈ ਅਤੇ ਕਈ ਵਾਰ ਅਣਚਾਹੇ "ਵਾਧੂ ਕੰਮ" (ਬੇਲੋੜੀ ਵਿਆਖਿਆ, ਵਾਧੂ ਸੁਝਾਅ) ਕਰਦਾ ਹੈ। ਪ੍ਰੋਂਪਟ ਵਿੱਚ "ਸਿਰਫ ਇੱਛਤ ਆਉਟਪੁੱਟ ਦਿਓ, ਵਾਧੂ ਟਿੱਪਣੀਆਂ ਨਾ ਜੋੜੋ" ਕਹਿਣਾ ਉੱਚ ਕੋਸ਼ਿਸ਼ ਦੇ ਇਸ ਮਾੜੇ ਪ੍ਰਭਾਵ ਨੂੰ ਆਫਸੈੱਟ ਕਰਦਾ ਹੈ।
ਸਾਰੰਸ਼ ਵਿੱਚ
ਸਿਸਟਮ ਪ੍ਰੋਂਪਟ ਮਾਡਲ ਦਾ ਸਥਾਈ ਨਿਰਦੇਸ਼ ਹੈ: ਇਹ ਭੂਮਿਕਾ, ਦਾਇਰੇ, ਫਾਰਮੈਟ, ਅਸਪਸ਼ਟਤਾ ਵਿਵਹਾਰ, ਅਤੇ ਗੁਪਤਤਾ ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕਰਦਾ ਹੈ। ਆਧੁਨਿਕ ਮਾਡਲਾਂ ਵਿੱਚ, ਵਿਵਹਾਰ ਤਾਪਮਾਨ ਦੀ ਬਜਾਏ ਅਨੁਕੂਲ ਸੋਚ ਅਤੇ ਕੋਸ਼ਿਸ਼ ਦੇ ਮਾਪਦੰਡਾਂ ਦੁਆਰਾ ਚਲਾਇਆ ਜਾਂਦਾ ਹੈ; ਕੰਮ ਲਈ ਕੋਸ਼ਿਸ਼ਾਂ ਨੂੰ ਇਕਸਾਰ ਕਰਨਾ ਗੁਣਵੱਤਾ ਅਤੇ ਲਾਗਤ ਦਾ ਇੱਕੋ ਸਮੇਂ ਪ੍ਰਬੰਧਨ ਕਰਦਾ ਹੈ। ਤੁਸੀਂ max_tokens, ਸਟਾਪ ਐਰੇ ਅਤੇ ਸਟ੍ਰਕਚਰਡ ਆਉਟਪੁੱਟ ਨਾਲ ਆਉਟਪੁੱਟ ਨੂੰ ਸੁਰੱਖਿਅਤ ਕਰਦੇ ਹੋ।
ਐਪਲੀਕੇਸ਼ਨ ਦਾ ਕੰਮ
ਕੋਈ ਕਾਰਜ ਚੁਣੋ। (1) ਪੰਜ ਭਾਗਾਂ (ਰੋਲ, ਸਕੋਪ, ਫਾਰਮੈਟ, ਅਸਪਸ਼ਟਤਾ, ਗੁਪਤਤਾ) ਦੇ ਨਾਲ ਇੱਕ ਸਿਸਟਮ ਪ੍ਰੋਂਪਟ ਲਿਖੋ। (2) ਦੱਸੋ ਕਿ ਤੁਸੀਂ ਇਸ ਕੰਮ ਲਈ ਕਿਹੜੇ ਪੱਧਰ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰੋਗੇ ਅਤੇ ਕਿਉਂ। (3) ਜੇਕਰ ਆਉਟਪੁੱਟ ਨੂੰ ਢਾਂਚਾ ਬਣਾਇਆ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ, ਤਾਂ ਇੱਕ ਛੋਟਾ JSON ਸਕੀਮਾ ਬਣਾਓ। (4) ਜਾਂਚ ਕਰੋ ਕਿ ਕੀ ਤੁਹਾਡੇ ਪ੍ਰੋਂਪਟ ਵਿੱਚ ਇੱਕ ਬਹੁਤ ਜ਼ਿਆਦਾ ਹਮਲਾਵਰ ਪੈਟਰਨ ਹੈ ਅਤੇ ਇਸਨੂੰ ਨਰਮ ਕਰੋ।
ਚੈੱਕਲਿਸਟ
- [ ] ਮੈਂ ਇੱਕ ਚੰਗੇ ਸਿਸਟਮ ਪ੍ਰੋਂਪਟ ਦੇ ਪੰਜ ਭਾਗਾਂ ਦਾ ਨਾਮ ਦੇ ਸਕਦਾ ਹਾਂ।
- [ ] ਮੈਂ ਵਿਆਖਿਆ ਕਰ ਸਕਦਾ ਹਾਂ ਕਿ ਅਨੁਕੂਲ ਸੋਚ ਅਤੇ ਕੋਸ਼ਿਸ਼ ਮਾਪਦੰਡ ਕੀ ਕਰਦੇ ਹਨ।
- [ ] ਮੈਂ ਕੰਮ ਦੇ ਅਨੁਸਾਰ ਕੋਸ਼ਿਸ਼ਾਂ ਨੂੰ ਵਿਵਸਥਿਤ ਕਰਕੇ ਗੁਣਵੱਤਾ/ਕੀਮਤ ਨੂੰ ਸੰਤੁਲਿਤ ਕਰ ਸਕਦਾ/ਸਕਦੀ ਹਾਂ।
- [ ] ਮੈਨੂੰ ਪਤਾ ਹੈ ਕਿ ਸਟ੍ਰਕਚਰਡ ਆਉਟਪੁੱਟ ਪ੍ਰੋਂਪਟ ਦੁਆਰਾ JSON ਦੀ ਬੇਨਤੀ ਕਰਨ ਨਾਲੋਂ ਸੁਰੱਖਿਅਤ ਕਿਉਂ ਹੈ।
- [ ] ਮੈਂ ਬਹੁਤ ਜ਼ਿਆਦਾ ਹਮਲਾਵਰ ਨਿਰਦੇਸ਼ਾਂ ਦੇ ਆਧੁਨਿਕ ਮਾਡਲਾਂ ਵਿੱਚ ਜੋਖਮ ਨੂੰ ਪਛਾਣ ਸਕਦਾ ਹਾਂ।