LLMs ਕਿਸ ਤਰ੍ਹਾਂ ਕਾਰੋਬਾਰੀ ਨਿਯਮ ਅਤੇ ਵਰਕਫਲੋ ਤਰਕ ਨੂੰ ਸੰਭਾਲਦੇ ਹਨ

ਕਾਰੋਬਾਰੀ ਨਿਯਮ-ਤਰਕ ਸਿਰਫ਼ ਕੋਡ ਬਣਾਉਣ ਤੋਂ ਵੱਧ ਹੈ

ਜਦੋਂ ਲੋਕ ਪੁੱਛਦੇ ਹਨ ਕਿ ਕੀ ਇੱਕ LLM "ਕਾਰੋਬਾਰੀ ਨਿਯਮਾਂ ਬਾਰੇ ਤਰਕ ਕਰ ਸਕਦਾ ਹੈ," ਉਹ ਆਮ ਤੌਰ 'ਤੇ ਉਦੋਂ ਦੀ ਗੱਲ ਕਰ ਰਹੇ ਹੁੰਦੇ ਹਨ ਜੋ ਸਿਰਫ਼ if/else ਲਿਖਣ ਤੋਂ ਕਾਫ਼ੀ ਜ਼ਿਆਦਾ ਮੰਗੀਦਾ ਹੈ। ਕਾਰੋਬਾਰੀ ਨਿਯਮ-ਤਰਕ ਦਾ ਅਰਥ ਹੈ ਨੀਤੀਆਂ ਨੂੰ ਲਗਾਤਾਰ ਲਾਗੂ ਕਰਨਾ, ਫੈਸਲਿਆਂ ਦੀ ਵਿਆਖਿਆ ਕਰ ਸਕਣਾ, ਐਕਸਪਸ਼ਨਾਂ ਨੂੰ ਸੰਭਾਲਣਾ ਅਤੇ ਮੌਜੂਦਾ ਵਰਕਫਲੋ ਕਦਮ ਦੇ ਨਾਲ ਸੰਰੇਖਿਤ ਰਹਿਣਾ—ਖ਼ਾਸ ਕਰਕੇ ਜਦੋਂ ਇਨਪੁਟ ਅਧੂਰੇ, ਗੰਦੇ ਜਾਂ ਬਦਲ ਰਹੇ ਹੋਣ।

ਤਰਕਬੰਦੀ vs. ਕੋਡ ਨਿਰਮਾਣ

ਕੋਡ ਬਣਾਉਣਾ ਮੁੱਖ ਰੂਪ ਵਿੱਚ ਟਾਰਗਿਟ ਭਾਸ਼ਾ ਵਿੱਚ ਵੈਧ ਸਿੰਟੈਕਸ ਉਤਪਨ ਕਰਨ 'ਤੇ ਧਿਆਨ ਦਿੰਦਾ ਹੈ। ਨਿਯਮ-ਤਰਕ ਦਾ ਮਕਸਦ ਭਾਵਨਾਤਮਕ ਇਰਾਦੇ ਨੂੰ ਬਰਕਰਾਰ ਰੱਖਣਾ ਹੈ।

ਇੱਕ ਮਾਡਲ ਪੂਰੀ ਤਰ੍ਹਾਂ ਵੈਧ ਕੋਡ ਜਨਰੇਟ ਕਰ ਸਕਦਾ ਹੈ ਪਰ ਫਿਰ ਵੀ ਗਲਤ ਕਾਰੋਬਾਰੀ ਨਤੀਜਾ ਦੇ ਸਕਦਾ ਹੈ ਕਿਉਂਕਿ:

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

ਇਸਦਾ ਸਾਰ ਹੈ: ਸਹੀਅਤ ਦੀ ਪਰਿਭਾਸ਼ਾ "ਕਿਆ ਇਹ ਕੰਪਾਇਲ ਹੁੰਦਾ ਹੈ?" ਨਹੀਂ ਹੈ। ਸਹੀਅਤ ਹੈ "ਕੀ ਇਹ ਹਰ ਵਾਰੀ ਕੰਪਨੀ ਦੇ ਫੈਸਲੇ ਦੇ ਮੇਲ ਖਾਂਦੀ ਹੈ, ਅਤੇ ਕੀ ਅਸੀਂ ਇਸ ਦੀ ਪੁਸ਼ਟੀ ਕਰ ਸਕਦੇ ਹਾਂ?"

LLMs ਤੋਂ ਕੀ ਉਮੀਦ ਰੱਖੀ ਜਾ ਸਕਦੀ ਹੈ

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

ਇਸ ਲਈ ਮਕਸਦ ਇਹ ਨਹੀਂ ਕਿ "ਮਾਡਲ ਨੂੰ ਫੈਸਲਾ ਕਰਨ ਦਿਓ," ਬਲਕਿ ਇਹ ਹੈ ਕਿ ਇਸਨੂੰ ਢਾਂਚਾ ਅਤੇ ਚੈਕ ਦਿਓ ਤਾਂ ਜੋ ਇਹ ਭਰੋਸੇਯੋਗ ਮਦਦ ਕਰ ਸਕੇ।

ਬਾਕੀ ਪੋਸਟ ਕਿਵੇਂ ਮਦਦ ਕਰੇਗੀ

ਇਕ ਵਿਹਾਰਕ ਢਾਂਚਾ ਆਮ ਤੌਰ 'ਤੇ ਇੱਕ ਪਾਈਪਲਾਈਨ ਵਰਗਾ ਹੁੰਦਾ ਹੈ:

1. ਨੀਤੀ ਲਿਖਤ ਨੂੰ ਵਰਤਣਯੋਗ ਨਿਯਮ ਪ੍ਰਤੀਨਿਧੀਆਂ ਵਿੱਚ ਬਦਲੋ।
2. ਵਰਕਫਲੋ ਸਥਿਤੀ ਨੂੰ ਟ੍ਰੈਕ ਕਰੋ ਤਾਂ ਕਿ ਫੈਸਲੇ ਕਦਮ-ਕੁਦਰਤੀ ਤੌਰ 'ਤੇ ਲਗਾਤਾਰ ਰਹਿਣ।
3. ਪ੍ਰਾਥਮਿਕਤਾਵਾਂ, ਐਕਸਪਸ਼ਨਾਂ ਅਤੇ ਵਿਆਖਿਆਵਾਂ ਲਾਗੂ ਕਰਨ ਲਈ ਪ੍ਰੰਪਟ ਪੈਟਰਨ ਵਰਤੋ।
4. ਫੈਸਲਿਆਂ ਨੂੰ ਸਬੂਤਾਂ ਨਾਲ ਗ੍ਰਾਊਂਡ ਕਰੋ (ਕੇਵਲ ਮਨਜ਼ੂਰ ਕੀਤੇ ਡੇਟਾ ਦੀ ਵਰਤੋਂ)।
5. ਅਸਪਸ਼ਟਤਾ ਘਟਾਉਣ ਲਈ ਸਕੀਮਾਂ ਨਾਲ ਆਉਟਪੁੱਟ ਸੀਮਿਤ ਕਰੋ।
6. ਵੈਰੀਫਾਈ, ਟੈਸਟ ਅਤੇ ਮਾਨੀਟਰ ਕਰੋ ਤਾਂ ਜੋ ਗਲਤੀਆਂ ਰਿਲੀਜ਼ ਤੋਂ ਪਹਿਲਾਂ ਫੜੀਆਂ ਜਾਣ।

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

ਕਾਰੋਬਾਰੀ ਨਿਯਮ ਅਤੇ ਵਰਕਫਲੋ: ਇੱਕ ਛੋਟਾ, ਸਧਾਰਣ-ਅੰਗਰੇਜ਼ੀ ਰੀਫ੍ਰੇਸ਼ਰ

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

ਕਾਰੋਬਾਰੀ ਨਿਯਮ ਕੀ ਹਨ?

ਕਾਰੋਬਾਰੀ ਨਿਯਮ ਉਹ ਫੈਸਲੇਬਾਜ਼ ਬਿਆਨ ਹਨ ਜੋ ਤੁਹਾਡੀ ਸੰਸਥਾ ਲਗਾਤਾਰ ਲਾਗੂ ਕਰਵਾਉਣਾ ਚਾਹੁੰਦੀ ਹੈ। ਇਹ ਨੀਤੀਆਂ ਅਤੇ ਤਰਕਾਂ ਵਜੋਂ ਨਜ਼ਰ ਆਉਂਦੇ ਹਨ ਜਿਵੇਂ:

• ਯੋਗਤਾ: ਕੌਣ ਫਾਇਦਾ, ਯੋਜਨਾ ਜਾਂ ਫੀਚਰ ਲਈ ਯੋਗ ਹੈ?
• ਮੂਲਯੰਕਨ: ਕਿਹੜੀ ਛੂਟ ਲਾਗੂ ਹੁੰਦੀ ਹੈ, ਅਤੇ ਕਦੋਂ?
• ਮਨਜ਼ੂਰੀਆਂ: ਕਦੋਂ ਮੈਨੇਜਰ ਰਿਵਿਊ ਲਾਜ਼ਮੀ ਹੈ?
• ਅਨੁਕੂਲਤਾ: ਕੀ ਲੌਗ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ, ਰੀਡੈਕਟ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਜਾਂ ਰੋੱਕਿਆ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ?

ਨਿਯਮ ਆਮ ਤੌਰ 'ਤੇ "IF X, THEN Y" ਦੀ ਸ਼ਕਲ ਵਿੱਚ ਹੁੰਦੇ ਹਨ (ਕਈ ਵਾਰੀ ਅਪਵਰਤੀ ਰੂਪ ਵਿੱਚ), ਅਤੇ ਇਹ ਸਪੱਸ਼ਟ ਨਤੀਜਾ ਦੇਣੇ ਚਾਹੀਦੇ ਹਨ: ਮਨਜ਼ੂਰ/ਅਨਮੰਜੂਰ, ਕੀਮਤ A/ਕੀਮਤ B, ਹੋਰ ਜਾਣਕਾਰੀ ਮੰਗੋ ਆਦਿ।

ਵਰਕਫਲੋਜ਼ ਕੀ ਹਨ?

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

• ਸਥਿਤੀਆਂ: submitted → under review → approved/denied → completed
• ਕਦਮ ਅਤੇ ਹੈਂਡਆਫ਼: customer support → finance → customer
• ਸਮੇਂ ਆਧਾਰਿਤ ਘਟਨਾਵਾਂ: ਯਾਦ ਦਿਆਂਵਾਂ, SLA, 14 ਦਿਨਾਂ ਬਾਅਦ ਆਟੋ-ਕੈਂਸਲ
• ਆਰਟੀਫੈਕਟ: ਫਾਰਮ, ਅਟੈਚਮੈਂਟ, ਰੀਜ਼ਨ ਕੋਡ, ਆਡੀਟ ਨੋਟਸ

ਇੱਕ ਛੋਟਾ ਉਦਾਹਰਨ: ਰੀਫੰਡ ਦੀਆਂ ਬੇਨਤੀਆਂ

ਇੱਕ ਰੀਫੰਡ ਬੇਨਤੀ ਦੀ ਕਲਪਨਾ ਕਰੋ।

ਨਿਯਮ ਟੁਕੜਾ: "ਖਰੀਦ ਤੋਂ 30 ਦਿਨਾਂ ਦੇ ਅੰਦਰ ਰੀਫੰਡ ਆਮ ਤੌਰ 'ਤੇ ਈਜ਼ਾਜ਼ਤ ਹੈ। ਛੂਟ: ਡਿਜੀਟਲ ਡਾਊਨਲੋਡ ਇੱਕ ਵਾਰੀ ਐਕਸੈੱਸ ਹੋਣ 'ਤੇ ਨਾਨ-ਰੀਫੰਡੇਬਲ ਹਨ। ਛੂਟ: ਚਾਰਜਬੈਕ ਨੂੰ ਐਸਕਲੇਸ਼ਨ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ।"

ਵਰਕਫਲੋ ਟੁਕੜਾ:

1. ਗ੍ਰਾਹਕ ਬੇਨਤੀ ਦਾਇਰ ਕਰਦਾ ਹੈ (ਸਥਿਤੀ: submitted).
2. ਸਿਸਟਮ ਖਰੀਦ ਦੀ ਮਿਤੀ ਅਤੇ ਉਤਪਾਦ ਕਿਸਮ ਚੈੱਕ ਕਰਦਾ ਹੈ (ਸਥਿਤੀ: under review).
3. ਜੇ ਯੋਗ ਹੈ, ਰੀਫੰਡ ਜਾਰੀ ਕਰੋ ਅਤੇ ਗ੍ਰਾਹਕ ਨੂੰ ਸੂਚਿਤ ਕਰੋ (ਸਥਿਤੀ: completed).
4. ਜੇ ਚਾਰਜਬੈਕ ਹੈ, ਫਾਇਨੈਂਸ ਨੂੰ ਜਾਂਚ ਲਈ ਰੂਟ ਕਰੋ (ਸਥਿਤੀ: escalated).

ਨਿਯਮਾਂ ਮੁਸ਼ਕਿਲ ਕਿਉਂ ਹੁੰਦੇ ਹਨ

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

LLMs ਕਿਵੇਂ "ਤਰਕ" ਕਰਦੇ ਹਨ: ਰਚਨਾਤਮਕ ਪੈਟਰਨ ਅਤੇ ਢਾਂਚਾ

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

ਇਹ ਸੀਮਿਤਤਾ ਵਰਕਫਲੋ ਅਤੇ ਫੈਸਲਾ-ਲਾਜਿਕ ਲਈ ਮਾਇਨੇ ਰੱਖਦੀ ਹੈ। ਮਾਡਲ ਇੱਕ ਐਸਾ ਨਿਯਮ ਲਗਾ ਸਕਦਾ ਹੈ ਜੋ "ਸਹੀ ਲੱਗਦਾ ਹੈ" ("ਕਰਮਚਾਰੀਆਂ ਨੂੰ ਹਮੇਸ਼ਾਂ ਮੈਨੇਜਰ ਮਨਜ਼ੂਰੀ ਚਾਹੀਦੀ ਹੈ") ਪਰ ਹਕੀਕਤ ਵਿੱਚ ਨੀਤੀ ਵਿੱਚ ਛੂਟ ਹੋ ਸਕਦੀ ਹੈ ("ਕੇਵਲ $500 ਤੋਂ ਉੱਪਰ" ਜਾਂ "ਸਿਰਫ਼ ਠੇਕੇਦਾਰਾਂ ਲਈ"). ਇਹ ਆਮ ਫੇਲ-ਮੋਡ ਹੈ: ਯਕੀਨੀ ਪਰ ਗਲਤ ਨਿਯਮ ਲਾਗੂ ਕਰਨਾ।

ਫਿਰ ਵੀ ਉਹ ਕਿਉਂ ਮਦਦਗਾਰ ਹਨ

ਅਸਲੀ "ਸਮਝ" ਨਾ ਹੋਣ ਦੇ ਬਾਵਜੂਦ, ਜਦੋਂ ਤੁਸੀਂ ਮਾਡਲ ਨੂੰ ਇੱਕ ਸੰਰਚਿਤ ਸਹਾਇਕ ਵਜੋਂ ਵਰਤਦੇ ਹੋ ਤਾਂ ਇਹ ਮਦਦ ਕਰ ਸਕਦਾ ਹੈ:

• ਲੰਬੀਆਂ ਨੀਤੀਆਂ ਨੂੰ ਸੰਖੇਪ ਕਰਨ ਲਈ ਤਾਜ਼ਾ ਭਾਸ਼ਾ
• ਗੰਦੇ ਲਿਖਤ ਨੂੰ ਸਤੰਤਰ ਖੇਤਰਾਂ ਵਿੱਚ ਨਕਸ਼ਾਬੱਧ ਕਰਨ (ਕੌਣ, ਕੀ, ਥਰੈਸ਼ਹੋਲਡ, ਛੂਟ, ਪ੍ਰਭਾਵੀ ਤਾਰੀਖ)
• ਪ੍ਰਸਤਾਵਿਤ ਫੈਸਲੇ ਨੂੰ ਨਿਰਧਾਰਤ ਨਿਯਮਾਂ ਦੇ ਖਿਲਾਫ ਚੈੱਕ ਕਰਨ ਲਈ ("ਇਸ ਦਾ ਸਹਾਰਾ ਕਿਹੜੇ ਧਾਰੇ ਤੋਂ ਮਿਲਦਾ ਹੈ?")

ਕੁੰਜੀ ਇਹ ਹੈ ਕਿ ਮਾਡਲ ਨੂੰ ਇਸ ਢਾਂਚੇ ਵਿੱਚ ਰੱਖਿਆ ਜਾਵੇ ਤਾਂ ਜੋ ਇਹ ਆਸਾਨੀ ਨਾਲ ਪ੍ਰਸਤਾਵਾਂ 'ਤੇ ਡ੍ਰਿਫਟ ਨਾ ਕਰੇ।

ਮਾਡਲ ਨੂੰ ਭਟਕਣ ਤੋਂ ਰੋਕਣ ਲਈ ਸੀਮਿਤ ਕਰੋ

ਅਸਪਸ਼ਟਤਾ ਘਟਾਉਣ ਦਾ ਇੱਕ ਪ੍ਰਯੋਗਾਤਮਕ ਤਰੀਕਾ ਹੈ ਸੀਮਿਤ ਆਉਟਪੁੱਟ: LLM ਨੂੰ ਇੱਕ ਫਿਕਸਡ ਸਕੀਮਾ ਜਾਂ ਟੈmplੇਟ ਵਿੱਚ ਜਵਾਬ ਦੇਣਾ ਲਾਜ਼ਮੀ ਕਰੋ (ਜਿਵੇਂ ਖਾਸ ਫੀਲਡਾਂ ਵਾਲਾ JSON ਜਾਂ ਲਾਜ਼ਮੀ ਕਾਲਮ ਵਾਲੀ ਟੇਬਲ)। ਜਦੋਂ ਮਾਡਲ ਨੂੰ rule_id, conditions, exceptions, ਅਤੇ decision ਭਰਨਾ ਪੈਂਦਾ ਹੈ, ਉਹ ਖ਼ਾਮੀਆਂ ਨੂੰ ਉੱਠਾਉਣਾ ਅਤੇ ਆਟੋਮੇਟਿਕ ਤਰੀਕੇ ਨਾਲ ਵੈਰੀਫਾਈ ਕਰਨਾ ਆਸਾਨ ਹੋ ਜਾਂਦਾ ਹੈ।

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

ਨਤੀਜਾ: LLM "ਤਰਕ" ਨੂੰ ਪੈਟਰਨ-ਅਧਾਰਤ ਜਨਰੇਸ਼ਨ ਵਜੋਂ ਦੇਖੋ ਜੋ ਢਾਂਚੇ ਨਾਲ ਉਤਰੇ ਹੋਏ ਹੋਵੇ—ਨੀਤੀਆਂ ਨੂੰ ਆਯੋਜਿਤ ਅਤੇ ਕ੍ਰਾਸ-ਚੈੱਕ ਕਰਨ ਲਈ ਲਾਭਦਾਇਕ ਪਰ ਜੇ ਇਸਨੂੰ ਅਖੀਰਲਾ ਅਥਾਰਟੀ ਮੰਨ ਲਈਦਾ ਜਾਵੇ ਤਾਂ ਖਤਰਾ ਹੈ।

ਗੰਦੇ ਨੀਤੀ-ਲਿਖਤ ਨੂੰ ਵਰਤਣਯੋਗ ਨਿਯਮ ਪ੍ਰਤੀਨਿਧੀਆਂ ਵਿੱਚ ਬਦਲਣਾ

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

"ਵਰਤੋਂਯੋਗ" ਨਿਯਮ ਕਿਸ ਤਰ੍ਹਾਂ ਦੇਖਦੇ ਹਨ

ਅਚਛੀਆਂ ਨਿਯਮ ਪ੍ਰਤੀਨਿਧੀਆਂ ਦੋ ਗੁਣ ਸਾਂਝੀਆਂ ਕਰਦੀਆਂ ਹਨ: ਉਹ ਅਸਪਸ਼ਟ ਨਹੀਂ ਹੁੰਦੀਆਂ ਅਤੇ ਉਹ ਚੈੱਕ ਕੀਤੀਆਂ ਜਾ ਸਕਦੀਆਂ ਹਨ।

ਟੈਸਟ ਕਰਨ ਯੋਗ ਬਿਆਨਾਂ ਵਜੋਂ ਨਿਯਮ ਲਿਖੋ:

• IF/THEN ਫੈਸਲਿਆਂ ਲਈ (ਯੋਗਤਾ, ਰੂਟਿੰਗ, ਮਨਜ਼ੂਰੀ)
• MUST / MUST NOT ਹੁਕਮਾਂ ਲਈ (ਕਠੋਰ ਰੋਕ)
• MAY ਲਈ ਮਨਜ਼ੂਰ ਵਿਕਲਪ (ਅਕਸਰ ਟਾਈ-ਬ੍ਰੇਕਰ ਦੀ ਲੋੜ)

ਨੀਯਮ ਮਾਡਲ ਨੂੰ ਕਈ ਰੂਪਾਂ ਵਿੱਚ ਦਿੱਤੇ ਜਾ ਸਕਦੇ ਹਨ:

• ਸਧਾਰਨ-ਭਾਸ਼ਾ ਬੁਲੇਟਸ (ਤੇਜ਼, ਪਰ ਥੋੜੇ ਸਟ੍ਰਕਚਰਡ)
• ਟੇਬਲ (ਥਰੈਸ਼ਹੋਲਡ ਆਧਾਰਿਤ ਨੀਤੀਆਂ ਲਈ ਵਧੀਆ)
• YAML/JSON (ਜਦੋਂ ਤੁਸੀਂ ਸੀਮਿਤ ਆਉਟਪੁੱਟ ਅਤੇ ਆਟੋਮੇਟਿਕ ਵੈਰੀਫਿਕੇਸ਼ਨ ਵੀ ਚਾਹੁੰਦੇ ਹੋ ਤਾਂ ਸਭ ਤੋਂ ਵਧੀਆ)

ਟਕਰਾਅ ਅਤੇ ਪ੍ਰਾਥਮਿਕਤਾ ਸੰਭਾਲਣਾ

ਅਸਲ ਨੀਤੀਆਂ ਟਕਰਾਅ ਕਰਦੀਆਂ ਹਨ। ਜਦੋਂ ਦੋ ਨਿਯਮ ਵਿਰੋਧ ਕਰਦੇ ਹਨ, ਮਾਡਲ ਨੂੰ ਸਪਸ਼ਟ ਪ੍ਰਾਥਮਿਕਤਾ ਸਖਤ ਚਾਹੀਦੀ ਹੈ। ਆਮ ਤਰੀਕੇ:

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

ਟਕਰਾਅ ਨੀਤੀ ਸਿੱਧਾ ਬਿਆਨ ਕਰੋ ਜਾਂ ਇਸਨੂੰ ਕੋਡ ਵਿੱਚ ਐਨਕੋਡ ਕਰੋ (ਜਿਵੇਂ priority: 100)—ਨਹੀਂ ਤਾਂ LLM ਨਿਯਮਾਂ ਨੂੰ "ਅਸਰ-ਜੋੜ" ਕਰ ਸਕਦਾ ਹੈ।

ਉਦਾਹਰਨ: ਪੈਰਾਗ੍ਰਾਫ ਨੂੰ ਨਿਯਮ-ਲਿਸਟ ਵਿੱਚ ਬਦਲਣਾ

ਅਸਲ ਨੀਤੀ ਲਿਖਤ:

"ਸਾਲਾਨਾ ਯੋਜਨਾਵਾਂ ਲਈ 30 ਦਿਨਾਂ ਦੇ ਅੰਦਰ ਰੀਫੰਡ ਉਪਲਬਧ ਹਨ। ਮਹੀਨਾਵਾਰ ਯੋਜਨਾਵਾਂ 7 ਦਿਨਾਂ ਬਾਅਦ ਨਾਨ-ਰੀਫੰਡੇਬਲ ਹਨ। ਜੇ ਖਾਤੇ 'ਤੇ ਧੋਖਾਧੜੀ ਜਾਂ ਵੱਧ ਚਾਰਜਬੈਕ ਹਨ, ਰੀਫੰਡ ਨਾ ਜਾਰੀ ਕਰੋ। ਉੱਘੇ ਗਾਹਕਾਂ ਲਈ $5,000 ਤੋਂ ਵੱਧ ਰੀਫੰਡ ਲਈ ਫਾਇਨੈਂਸ ਦੀ ਮਨਜ਼ੂਰੀ ਲਾਜ਼ਮੀ ਹੈ।"

ਸੰਰਚਿਤ ਨਿਯਮ (YAML):

rules:
  - id: R1
    statement: \"IF plan_type = annual AND days_since_purchase <= 30 THEN refund MAY be issued\"
    priority: 10
  - id: R2
    statement: \"IF plan_type = monthly AND days_since_purchase > 7 THEN refund MUST NOT be issued\"
    priority: 20
  - id: R3
    statement: \"IF fraud_flag = true OR chargeback_rate = excessive THEN refund MUST NOT be issued\"
    priority: 100
  - id: R4
    statement: \"IF customer_tier = enterprise AND refund_amount > 5000 THEN finance_approval MUST be obtained\"
    priority: 50
conflict_resolution: \"Higher priority wins; MUST NOT overrides MAY\"

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

ਵਰਕਫਲੋ ਸਥਿਤੀ ਟ੍ਰੈਕ ਕਰਨਾ ਤਾਂ ਜੋ ਮਾਡਲ ਲਗਾਤਾਰ ਰਹੇ

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

ਸਧਾਰਨ-ਅੰਗਰੇਜ਼ੀ ਵਿੱਚ "ਸਟੇਟ" ਦਾ ਕੀ ਅਰਥ ਹੈ

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

ਮਾਡਲ ਨੂੰ ਸਥਿਤੀ ਕਿਵੇਂ ਦੇਵੋ

ਜਦੋਂ ਤੁਸੀਂ ਮਾਡਲ ਨੂੰ ਕਾਲ ਕਰੋ, ਤਾਂ ਉਨ੍ਹਾਂ ਦੀ ਬੇਨਤੀ ਨਾਲ ਨਾਲ ਇੱਕ ਸੰਖੇਪ ਸਟੇਟ ਪੇਲੋਡ ਸ਼ਾਮਲ ਕਰੋ। ਲਾਭਕਾਰੀ ਫੀਲਡ ਹਨ:

• ਕਦਮ ਨਾਮ ਅਤੇ ਸਥਿਤੀ (ਉਦਾਹਰਨ: manager_review: approved, finance_review: pending)
• ਸਥਿਰ ID (request ID, employee ID) ਤਾਂ ਜੋ ਮਾਡਲ ਕੇਸ ਮਿਲਾ-ਝੁਲਾ ਨਾ ਕਰੇ
• ਟਾਈਮਸਟੈਂਪ (submitted at, last updated) ਤਾਂ ਕਿ "ਨਵਾਂ ਜਿੱਤਦਾ ਹੈ" ਸਥਿਤੀ ਸੁਲਝੇ
• ਫਲੈਗ (ਨੀਤੀ ਛੂਟ, ਗਾਇਬ ਦਸਤਾਵੇਜ਼, ਐਸਕਲੇਸ਼ਨ ਲਾਜ਼ਮੀ)

ਹਰ ਐਤਿਹਾਸਿਕ ਸੁਨੇਹੇ ਨੂੰ dump ਕਰਨ ਤੋਂ ਬਚੋ। ਬਦਲ ਵਿੱਚ ਮੌਜੂਦਾ ਸਟੇਟ ਅਤੇ ਕੁਝ ਚਾਬੀ ਟ੍ਰਾਂਜ਼ੀਸ਼ਨ ਆਡੀਟ ਟਰੇਲ ਦਿਓ।

ਇਕੱਤਰ ਸੱਚਾਈ ਦਾ ਇੱਕ ਸਰੋਤ ਰੱਖੋ

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

ਉਦਾਹਰਨ: ਮਨਜ਼ੂਰੀ-ਫਲੋ ਸਟੇਟ ਸਨੈਪਸ਼ਾਟ

{
  "request_id": "TRV-10482",
  "workflow": "travel_reimbursement_v3",
  "current_step": "finance_review",
  "step_status": {
    "submission": "complete",
    "manager_review": "approved",
    "finance_review": "pending",
    "payment": "not_started"
  },
  "actors": {
    "employee_id": "E-2291",
    "manager_id": "M-104",
    "finance_queue": "FIN-AP"
  },
  "amount": 842.15,
  "currency": "USD",
  "submitted_at": "2025-12-12T14:03:22Z",
  "last_state_update": "2025-12-13T09:18:05Z",
  "flags": {
    "receipt_missing": false,
    "policy_exception_requested": true,
    "needs_escalation": false
  }
}

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

ਪ੍ਰੰਪਟ ਪੈਟਰਨ ਜੋ ਨਿਯਮ-ਅਨੁਸਰਤਾ ਅਤੇ ਫੈਸਲਿਆਂ ਨੂੰ ਸੁਧਾਰਦੇ ਹਨ

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

1) ਰੋਲੇ-ਪ੍ਰੰਪਟਿੰਗ: "ਅਹਿਸਾਸ" ਦੇਵੋ ਨਾ ਕਿ ਸਿਰਫ ਇਕ ਲਹਿਜ਼ਾ

ਮਾਡਲ ਨੂੰ ਇੱਕ ਵਿਸ਼ੇਸ਼ ਭੂਮਿਕਾ ਦਿਓ ਜੋ ਤੁਹਾਡੇ ਪ੍ਰਕਿਰਿਆ ਨਾਲ ਜੁੜੀ ਹੋਵੇ। ਤਿੰਨ ਰੋਲ ਇੱਕਠੇ ਚੰਗੇ ਕੰਮ ਕਰਦੇ ਹਨ:

• Policy analyst: ਨੀਤੀ ਲਿਖਤ ਨੂੰ ਵਿਆਖਿਆ ਕਰਦਾ ਅਤੇ ਮੌਜੂਦਾ ਕੇਸ ਨਾਲ ਮੇਲ ਕਰਦਾ ਹੈ।
• Validator: ਫੈਸਲੇ ਨੂੰ ਲੋੜੀਂਦੇ ਮਾਪਦੰਡਾਂ ਖਿਲਾਫ ਚੈੱਕ ਕਰਦਾ ਅਤੇ ਗਾਇਬ ਇਨਪੁੱਟਾਂ ਨੂੰ ਫਲੈਗ ਕਰਦਾ ਹੈ।
• Agent: ਅਗਲਾ ਵਰਕਫਲੋ ਕਾਰਵਾਈ ਲੈਂਦਾ (ਟਿਕਟ ਬਣਾਓ, ਈਮੇਲ ਦਾ ਮਸੋਦਾ ਤਿਆਰ ਕਰੋ, ਸਥਿਤੀ ਸੈੱਟ ਕਰੋ)।

ਤੁਸੀਂ ਇਨ੍ਹਾਂ ਨੂੰ ਕ੍ਰਮਵਾਰ ਚਲਾ ਸਕਦੇ ਹੋ ("analyst → validator → agent") ਜਾਂ ਇੱਕ ਸੰਰਚਿਤ ਜਵਾਬ ਵਿੱਚ ਸਾਰੇ ਤਿੰਨੇ ਅੰਸ਼ ਮੰਗ ਸਕਦੇ ਹੋ।

2) ਕਦਮ-ਦਰ-ਕਦਮ ਨਿਰਦੇਸ਼ (ਲੁਕਿਆ ਤਰਕ ਮੰਗਣ ਤੋਂ ਬਿਨਾਂ)

"ਚੇਨ-ਆਫ-ਥਾਟ" ਮੰਗਣ ਦੀ ਥਾਂ, ਦਿਖਾਈ ਦੇਣ ਵਾਲੇ ਕਦਮ ਅਤੇ ਆਰਟਿਫੈਕਟ ਨਿਰਧਾਰਤ ਕਰੋ:

1. ਲਾਗੂ ਹੁੰਦੇ ਨਿਯਮ ਪਛਾਣੋ।
2. ਕੇਸ ਤੋਂ ਲੋੜੀਂਦੇ ਇਨਪੁੱਟ ਕੱਢੋ।
3. ਪ੍ਰਾਥਮਿਕਤਾ ਅਨੁਸਾਰ ਨਿਯਮ ਲਗਾਓ।
4. ਇੱਕ ਫੈਸਲਾ ਅਤੇ ਅਗਲਾ ਕਦਮ ਉਤਪੱਦ ਕਰੋ।

ਇਹ ਮਾਡਲ ਨੂੰ ਗਠਿਤ ਰੱਖਦਾ ਹੈ ਅਤੇ ਡਿਲਿਵਰੇਬਲ 'ਤੇ ਧਿਆਨ ਰੱਖਦਾ ਹੈ: ਕਿਸ ਨਿਯਮ ਵਰਤੇ ਗਏ ਅਤੇ ਅਗਲਾ ਨਤੀਜਾ ਕੀ ਹੈ।

3) ਸੰਰਚਿਤ ਵਾਜਬੀ-ਵਿਆਖਿਆ ਮੰਗੋ: rule IDs + ਸਬੂਤ

ਫ੍ਰੀ-ਫਾਰਮ ਵਿਆਖਿਆਵਾਂ ਡ੍ਰਿਫਟ ਕਰਦੀਆਂ ਹਨ। ਇੱਕ ਸੰਖੇਪ ਵਾਜਬੀ ਮੰਗੋ ਜੋ ਸਰੋਤਾਂ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰੇ:

• Rule IDs used (ਉਦਾਹਰਨ R-12, R-18)
• Evidence (ਨੀਤੀ ਲਿਖਤ ਤੋਂ ਕੋਟ ਕੀਤੇ ਟੁਕੜੇ ਅਤੇ ਵਿਸ਼ੇਸ਼ ਕੇਸ ਫੀਲਡ)
• Assumptions (ਜੇ ਕੋਈ ਇਨਪੁੱਟ ਗਾਇਬ ਹੈ ਤਾਂ)

ਇਸ ਨਾਲ ਸਮੀਖਿਆ ਤੇ ਡਿਬੱਗਿੰਗ ਤੇਜ਼ ਹੁੰਦੀ ਹੈ।

4) ਚੈਕਲਿਸਟ ਪ੍ਰੰਪਟ ਪੈਟਰਨ: ਇਨਪੁੱਟ, ਫੈਸਲਾ, ਐਕਸਪਸ਼ਨ, ਅਗਲਾ ਕਦਮ

ਹਰ ਵੇਰ ਜਾਂ ਟਾਈਮ 'ਤੇ ਇੱਕ ਫਿਕਸਡ ਟੈਮਪਲੇਟ ਵਰਤੋ:

• Inputs received: …
• Inputs missing: …
• Decision: approve/deny/needs-review
• Rule references: [R-…]
• Exceptions considered: …
• Next workflow step: update status / request info / escalate

ਟੈਮਪਲੇਟ ਅਸਪਸ਼ਟਤਾ ਘਟਾਉਂਦਾ ਹੈ ਅਤੇ ਮਾਡਲ ਨੂੰ ਗੈਰ-ਜਵਾਬੱਦਹ ਪੱਧਰ 'ਤੇ ਜਾਣ ਤੋਂ ਪਹਿਲਾਂ ਗੈਪਾਂ ਸੁਪਰਪਾੜਨ ਲਈ ਉਤਸ਼ਾਹਤ ਕਰਦਾ ਹੈ।

ਫੈਸਲਿਆਂ ਨੂੰ ਹਕੀਕਤ-ਅਧਾਰਿਤ ਬਣਾਉਣ ਲਈ ਟੂਲ ਅਤੇ ਰੀਟਰੀਵਲ ਦੀ ਵਰਤੋਂ

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

ਟੂਲ ਇਹ ਸਮੱਸਿਆ ਨੂੰ ਦੋ ਕਦਮ ਬਣਾਉਂਦੇ ਹਨ: ਪਹਿਲਾਂ ਸਬੂਤ ਲੈਓ, ਫਿਰ ਫੈਸਲਾ ਕਰੋ।

ਉਨ੍ਹਾਂ ਆਮ ਟੂਲਾਂ ਜੋ ਮਾਡਲ ਨੂੰ ਇਮਾਨਦਾਰ ਰੱਖਦੇ ਹਨ

ਨੀਯਮ ਅਤੇ ਵਰਕਫਲੋ-ਭਾਰ ਸਿਸਟਮਾਂ ਵਿੱਚ ਕੁਝ ਸਧਾਰਨ ਟੂਲ ਬਹੁਤ ਕੁਝ ਕਰ ਲੈਂਦੇ ਹਨ:

• ਡੇਟਾਬੇਸ ਲੁੱਕਅੱਪ (ਗ੍ਰਾਹਕ ਪ੍ਰੋਫਾਇਲ, ਖਾਤਾ ਸਥਿਤੀ, ਅਧਿਕਾਰ)
• Policy/rule store (ਮਨਜ਼ੂਰ ਕੀਤੇ ਨਿਯਮ, ਵਰਜ਼ਨ ਕੀਤੇ ਪ੍ਰੋਸੀਜਰ, ਛੂਟ ਲਿਸਟ)
• ਕੈਲਕੂਲੇਟਰ (ਫੀਸ, ਪ੍ਰੋਰੇਟੇਸ਼ਨ, ਟੈਕਸ, ਸਮਾਂ-ਵਿੰਡੋ)
• ਟਿਕਟਿੰਗ / ਵਰਕਫਲੋ API (ਖੁੱਲੇ ਕੇਸ, SLA ਟਾਈਮਰ, ਮਨਜ਼ੂਰੀਆਂ, ਕਦਮ ਪੂਰਾ ਹੋਣਾ)

ਕੰਜੀ ਇਹ ਹੈ ਕਿ ਮਾਡਲ ਕਾਰਯਕਾਰੀ ਤੱਥ "ਪੇਸ਼" ਨਹੀਂ ਕਰ ਰਿਹਾ—ਇਹ ਉਹਨਾਂ ਨੂੰ ਮੰਗ ਰਿਹਾ ਹੈ।

ਰੀਟਰੀਵਲ: ਕੇਵਲ ਉਹ ਨੀਤੀਆਂ ਲਿਆਓ ਜੋ ਮਾਮਲੇ ਲਈ ਮਾਇਨੇ ਰੱਖਦੀਆਂ ਹਨ

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

• ਗ੍ਰਾਹਕ ਦੀ ਯੋਜਨਾ ਲਈ ਰੱਦ ਨੀਤੀ
• ਦੇਸ਼/ਰਾਜ ਅਨੁਸਾਰ ਖੇਤਰੀ ਧਾਰੀਧਾਰਾ
• ਚਾਰਜਬੈਕ ਮੌਜੂਦ ਹੋਣ 'ਤੇ ਲਾਗੂ ਛੂਟ

ਇਸ ਨਾਲ ਵਿਦਵੰਸ ਵਿਰੋਧ ਘਟਦੇ ਹਨ ਅਤੇ ਮਾਡਲ ਪੁਰਾਣੇ ਨੀਯਮ ਦੀ ਅਗਿਆਤਪੂਰਵਕ ਪਾਲਣਾ ਕਰਨ ਤੋਂ ਰੁਕਦਾ ਹੈ।

ਟੂਲ ਆਉਟਪੁੱਟ ਨੂੰ ਫੈਸਲਾ-ਸਬੂਤ ਵਿੱਚ ਬਦਲਣਾ

ਇੱਕ ਭਰੋਸੇਯੋਗ ਪੈਟਰਨ ਇਹ ਹੈ ਕਿ ਟੂਲ ਨਤੀਜੇ ਨੂੰ ਉਹ ਸਬੂਤ ਠਹਿਰਾਓ ਜਿਨ੍ਹਾਂ ਨੂੰ ਮਾਡਲ ਆਪਣੇ ਫੈਸਲੇ ਵਿੱਚ ਉਧਰਣ ਦੇ ਕੇ ਦਰਸਾਏ। ਉਦਾਹਰਨ:

1. Tool: get_account(account_id) → status="past_due", plan="Business", usage_this_month=12000
2. Tool: retrieve_policies(query="overage fee Business plan") → returns rule: “Overage fee applies above 10,000 units at $0.02/unit.”
3. Tool: calculate_overage(usage=12000, threshold=10000, rate=0.02) → $40.00

ਹੁਣ ਫੈਸਲਾ ਅਨੁਮਾਨ ਨਹੀਂ ਰਹਿੰਦਾ: ਇਹ ਖਾਸ ਇਨਪੁੱਟਾਂ 'ਤੇ ਆਧਾਰਿਤ ਨਤੀਜਾ ਹੈ ("past_due", "12,000 units", "$0.02/unit")। ਜੇ ਬਾਅਦ ਵਿਚ ਤੁਸੀਂ ਆਡੀਟ ਕਰੋ, ਤੁਹਾਨੂੰ ਪਤਾ ਚੱਲੇਗਾ ਕਿ ਕਿਹੜੇ ਤੱਥ ਅਤੇ ਕਿਸ ਨੀਤੀ ਵਰਜ਼ਨ ਨੇ ਇਹ ਨਤੀਜਾ ਦਿੱਤਾ—ਅਤੇ ਜੇ ਕੁਝ ਗਲਤ ਹੋਵੇ ਤਾਂ ਤੁਸੀਂ ਠੀਕ ਹਿੱਸਾ ਠੀਕ ਕਰ ਸਕਦੇ ਹੋ।

ਸੀਮਿਤ ਆਉਟਪੁੱਟ: ਅਸਪਸ਼ਟਤਾ ਘਟਾਉਣ ਵਾਲੀਆਂ ਸਕੀਮਾਂ

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

ਫੈਸਲੇ JSON ਵਜੋਂ ਰਿਟਰਨ ਕਰੋ

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

{
  "decision": "needs_review",
  "reasons": [
    "Applicant provided proof of income, but the document is expired"
  ],
  "next_action": "request_updated_document",
  "missing_info": [
    "Income statement dated within the last 90 days"
  ],
  "assumptions": [
    "Applicant name matches across documents"
  ]
}

ਇਹ ਸੰਰਚਨਾ ਉਪਯੋਗੀ ਹੁੰਦੀ ਹੈ ਭਾਵੇਂ ਮਾਡਲ ਪੂਰਾ ਫੈਸਲਾ ਨਾ ਕਰ ਸਕੇ। missing_info ਅਤੇ assumptions ਅਣਇਸ਼ਨਤਾ ਨੂੰ ਕਾਰਵਾਈਯੋਗ ਫਾਲੋਅਪ ਵਿੱਚ ਬਦਲ ਦਿੰਦੀਆਂ ਹਨ, ਓਸ ਛੁਪੇ ਅਨੁਮਾਨ ਨੂੰ ਨਹੀਂ।

ਆਊਟਕਮਜ਼ ਲਈ ਐਨਮਰੇਸ਼ਨ ਵਰਤੋ

ਵੈਰੀਏਬਲਿਟੀ ਘਟਾਉਣ ਲਈ, ਮੁੱਖ ਫੀਲਡਾਂ ਲਈ ਆਗਿਆਸ਼ੁਦਾ ਮੁੱਲ (enums) ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ। ਉਦਾਹਰਨ:

• decision: approved | denied | needs_review
• next_action: approve_case | deny_case | request_more_info | escalate_to_human

ਐਨਮ ਨਾਲ, ਡਾਊਨਸਟ੍ਰੀਮ ਸਿਸਟਮ ਨੂੰ synonyms ਜਾਂ ਲਫ਼ਜ਼ਾਂ ਦੀ ਵਿਆਖਿਆ ਨਹੀਂ ਕਰਨੀ ਪੈਂਦੀ—ਓਹ ਸਿੱਧਾ ਜਾਣ-ਪਹਚਾਨ ਵਾਲੇ ਮੁੱਲਾਂ 'ਤੇ ਸ਼ਾਖਾ ਸਿਰਜਦੇ ਹਨ।

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

ਸਕੀਮਾਂ ਰੱਖੜੀ ਵਾਲੀਆਂ ਰੇਲਾਂ ਵਰਗੀ ਕੰਮ ਕਰਦੀਆਂ ਹਨ। ਇਹ:

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

ਨਤੀਜਾ: ਘੱਟ ਅਸਪਸ਼ਟਤਾ, ਘੱਟ ਐਜ ਕੇਸ ਫੇਲਅਰ ਅਤੇ ਲਗਾਤਾਰ ਵਰਕਫਲੋ ਜਿਆਦਾ ਮੋਹਰਾ ਹੋ ਜਾਂਦਾ ਹੈ।

ਵੈਰੀਫਿਕੇਸ਼ਨ ਰਣਨੀਤੀਆਂ: ਰਿਲੀਜ਼ ਤੱਕ ਗਲਤੀਆਂ ਫੜੋ

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

ਪ੍ਰੀ-ਚੈਕ: ਤਰਕ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਇਨਪੁੱਟ ਵੈਰੀਫਾਈ ਕਰੋ

ਸਭ ਤੋਂ ਪਹਿਲਾਂ ਇਹ ਯਕੀਨੀ ਕਰੋ ਕਿ ਤੁਹਾਡੇ ਕੋਲ ਨਿਯਮ ਲਾਗੂ ਕਰਨ ਲਈ ਘੱਟੋ-ਘੱਟ ਜਾਣਕਾਰੀ ਮੌਜੂਦ ਹੈ। ਪ੍ਰੀ-ਚੈਕ ਮਾਡਲ ਦੇ ਫੈਸਲੇ ਤੋਂ ਪਹਿਲਾਂ ਚਲਾਓ।

ਆਮ ਪ੍ਰੀ-ਚੈਕਾਂ ਵਿੱਚ ਜ਼ਰੂਰੀ ਫੀਲਡ (ਗ੍ਰਾਹਕ ਕਿਸਮ, ਆਰਡਰ ਟੋਟਲ, ਖੇਤਰ), ਮੁਢਲੀ ਫਾਰਮੈਟ (ਤਾਰੀਖਾਂ, ID), ਅਤੇ ਮਨਜ਼ੂਰ-ਸੀਮਾਵਾਂ (ਨਕਾਰਾਤਮਕ ਰਕਮ ਨਹੀਂ, ਪ੍ਰਤੀਸ਼ਤ 100% ਤਕ) ਸ਼ਾਮਲ ਹਨ। ਜੇ ਕੁਝ ਫੇਲ ਹੋ ਜਾਏ, ਇੱਕ ਸਪੱਸ਼ਟ ਤੇ ਕਾਰਵਾਈਯੋਗ ਐਰਰ ਵਾਪਸ ਕਰੋ ("Missing 'region'; cannot choose tax rule set"), ਨਾ ਕਿ ਮਾਡਲ ਨੂੰ ਅਨੁਮਾਨ ਲਗਾ ਕੇ ਛੱਡੋ।

ਪੋਸਟ-ਚੈਕ: ਨਿਯਮਾਂ ਖਿਲਾਫ ਫੈਸਲੇ ਦੀ ਜਾਂਚ

ਮਾਡਲ ਜਦੋਂ ਨਤੀਜਾ ਦਿੰਦਾ ਹੈ, ਉਸਨੂੰ ਤੁਹਾਡੇ ਨਿਯਮ ਸੈੱਟ ਦੇ ਖਿਲਾਫ ਵੈਰੀਫਾਈ ਕਰੋ।

ਧਿਆਨ ਕੇਂਦਰਿਤ ਰੱਖੋ:

• Rule coverage: ਕੀ ਫੈਸਲੇ ਨੇ ਲਾਗੂ ਹੋਣ ਵਾਲੇ ਨਿਯਮਾਂ ਨੂੰ ਦਰਸਾਇਆ ਜਾਂ ਮੈਪ ਕੀਤਾ, ਜਾਂ ਕਿਸੇ ਲਾਜ਼ਮੀ ਨੀਤੀ ਨੂੰ ਛੱਡ ਦਿੱਤਾ?
• Contradiction checks: ਕੀ ਆਉਟਪੁੱਟ ਇਨਪੁੱਟਸ ਨਾਲ ਟਕਰਾਉਂਦਾ ਹੈ (ਉਦਾਹਰਨ: "approved" ਜਦੋਂ ਕੋਈ ਕਠੋਰ-ਰੋਕ ਸੱਚ ਹੈ)?
• Boundary cases: ਥਰੈਸ਼ਹੋਲਡਾਂ ਦੀ ਜਾਂਚ ਕਰੋ ($10,000 ਬਿਲਕੁਲ), ਖਾਲੀ ਸਥਿਤੀਆਂ, ਅਤੇ "ਥੋੜ੍ਹਾ ਉਪਰ" ਸਥਿਤੀਆਂ।

ਦੂਜੀ-ਪਾਸ ਵੈਰੀਫਿਕੇਸ਼ਨ: ਇਰਾਦਾਪੂਰਕ ਸਮੀਖਿਆ

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

ਸਾਦਾ ਪੈਟਰਨ: ਪਹਿਲਾ ਪਾਸ ਫੈਸਲਾ + ਵਾਜਬੀ ਦਿੰਦਾ ਹੈ; ਦੂਜਾ ਪਾਸ valid ਜਾਂ ਫੇਲਿਆ ਹੋਏ ਨੁਕਤੇ (ਗਾਇਬ ਫੀਲਡ, ਉਲੰਘਣ, ਅਸਪਸ਼ਟ ਨੀਤੀ ਵਿਆਖਿਆ) ਵਾਪਸ ਕਰਦਾ ਹੈ।

ਲੌਗਿੰਗ: ਫੈਸਲਿਆਂ ਨੂੰ ਆਡੀਟ ਯੋਗ ਬਣਾਓ

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

ਨੀਤੀਆਂ ਅਤੇ ਵਰਕਫਲੋ ਭਰੋਸੇਯੋਗਤਾ ਲਈ ਟੈਸਟਿੰਗ ਅਤੇ ਮਾਨੀਟੋਰਿੰਗ

LLM-ਚਾਲਿਤ ਨਿਯਮ ਅਤੇ ਵਰਕਫਲੋ ਫੀਚਰਾਂ ਦੀ ਟੈਸਟਿੰਗ ਇਹ ਨਹੀਂ ਦੇਖਦੀ ਕਿ "ਕੀ ਇਹ ਕੁਝ ਬਣਾਉਂਦਾ ਹੈ?" ਬਲਕਿ ਇਹ ਦੇਖਦੀ ਹੈ ਕਿ "ਕੀ ਇਹ ਉਹੋ ਜਿਹਾ ਫੈਸਲਾ ਕਰਦਾ ਹੈ ਜੋ ਧਿਆਨ ਨਾਲ ਕੰਮ ਕਰਨ ਵਾਲਾ ਮਨੁੱਖ ਕਰੇਗਾ, ਠੀਕ ਕਾਰਨਾਂ ਕਰਕੇ, ਹਰ ਵਾਰੀ?" ਖੁਸ਼ਖਬਰ: ਤੁਸੀਂ ਇਸਨੂੰ ਉਹੀ ਅਨੁਸ਼ਾਸਨ ਨਾਲ ਟੈਸਟ ਕਰ ਸਕਦੇ ਹੋ ਜੋ ਪਰੰਪਰਾਗਤ ਦੇcision logic ਲਈ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ।

ਕਾਰੋਬਾਰੀ ਨਿਯਮਾਂ ਲਈ ਯੂਨਿਟ ਟੈਸਟ (ਛੋਟੇ, ਭਵਿੱਖਵਾਣੀ ਚੈਕ)

ਹਰ ਨਿਯਮ ਨੂੰ ਇੱਕ ਫੰਕਸ਼ਨ ਵਾਂਗ ਸੋਚੋ: ਦਿੱਤੇ ਇਨਪੁੱਟਸ 'ਤੇ ਇਹ ਇੱਕ ਨਤੀਜਾ ਦੇਵੇ ਜੋ ਤੁਸੀਂ assert ਕਰ ਸਕੋ।

ਉਦਾਹਰਨ: ਜੇ ਤੁਹਾਡੇ ਕੋਲ ਇੱਕ ਰੀਫੰਡ ਨਿਯਮ ਹੈ "ਅਨਪੈਕਡ ਆਈਟਮਾਂ ਲਈ 30 ਦਿਨਾਂ ਦੇ ਅੰਦਰ ਰੀਫੰਡ", ਫੋਕਸਡ ਕੇਸ ਲਿਖੋ:

• Order age = 10 days, unopened = true → approve
• Order age = 10 days, unopened = false → deny
• Order age = 45 days, unopened = true → deny
• Edge cases: ਬਿਲਕੁਲ 30 ਦਿਨ, "unopened" ਫੀਲਡ ਗਾਇਬ, ਟਕਰਾਅ ਸੰਕੇਤ

ਇਹ ਯੂਨਿਟ ਟੈਸਟ off-by-one ਗਲਤੀਆਂ, ਗਾਇਬ ਫੀਲਡਾਂ ਅਤੇ ਮਾਡਲ ਦਾ "ਮਦਦਗਾਰ" ਰਵੱਈਆ ਰੁੱਖਣ ਨਹੀਂ ਦਿੰਦੇ—ਜਦੋਂ ਇਹ ਅਣਜਾਣੀਆਂ ਭਰ ਦਿੰਦਾ ਹੈ।

ਵਰਕਫਲੋ ਲਈ ਦ੍ਰਿਸ਼-ਤਰੀਕਾ ਟੈਸਟ (ਕਈ-ਕਦਮੀ, ਸਮਾਂ-ਅਵੇਅਰ)

ਵਰਕਫਲੋ ਉਹਨਾਂ ਸਮੇਂ ਫੇਲ ਹੁੰਦੇ ਹਨ ਜਦੋਂ ਸਟੇਟ ਕਦਮਾਂ 'ਚ ਅਸਮੰਜਸ ਹੋ ਜਾਵੇ। ਦ੍ਰਿਸ਼-ਤਰੀਕਾ ਟੈਸਟ ਹਕੀਕਤੀ ਯਾਤਰਾਵਾਂ ਦੀ ਨਕਲ ਕਰਦੇ ਹਨ:

• ਰਸਤਾ-ਟੈਸਟ: submit claim → request documents → documents received → decision
• ਸਮੇਂ-ਆਧਾਰਿਤ ਐਜ: "7 ਦਿਨਾਂ ਵਿੱਚ ਕੋਈ ਜਵਾਬ ਨਹੀਂ ਆਇਆ ਤਾਂ ਯਾਦ ਦਿਓ", "30 ਦਿਨ ਬੀਤ ਗਏ ਤਾਂ ਕੇਸ ਬੰਦ ਕਰੋ"
• ਸ਼ਾਖਾ: ਗਾਹਕ ਐਸਕਲੇਟ ਕਰਦਾ ਹੈ, ਨੀਤੀ ਛੂਟ ਮੰਗੀ ਜਾਂਦੀ ਹੈ, ਡੁਪਲਿਕੇਟ ਕੇਸ ਮਿਲਦਾ ਹੈ

ਉਦੇਸ਼ ਇਹ ਹੈ ਕਿ ਮਾਡਲ ਮੌਜੂਦਾ ਸਟੇਟ ਦਾ ਸਤਿਕਾਰ ਕਰੇ ਅਤੇ ਕੇਵਲ ਅਨੁਮਤ ਟ੍ਰਾਂਜ਼ੀਸ਼ਨ ਹੀ ਕਰੇ।

"ਗੋਲਡ ਸੈੱਟ" ਬਣਾਓ

ਅਸਲ, ਅਨੇਨੋਨაისਡ ਉਦਾਹਰਨਾਂ ਦਾ ਇੱਕ ਛੋਟਾ ਸੰਭਾਲਾ-ਡੇਟਾਸੈੱਟ ਬਣਾਓ ਜਿਸਦਾ ਨਿਰਣਯ ਤੇ ਸੰਗ੍ਰਹਿਤ ਰਾਜ਼ ਹੈ (ਛੋਟੇ ਰੈਸ਼ਨ ਦਰਜੀਕਰਨ ਅਤੇ ਸੰਖੇਪ ਨਿਆਇਕ ਕਾਰਨ). ਨੀਤੀ ਬਦਲਣ ਤੇ ਇਸਨੂੰ ਰੀਵਿਊ ਕਰੋ। 100–500 ਕੇਸਾਂ ਵਾਲਾ ਇੱਕ ਛੋਟਾ ਗੋਲਡ ਸੈੱਟ ਭਾਰੀ ਮੂਲ-ਯਥਾਰਥ ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ—ਗਾਇਬ ਡੇਟਾ, ਅਜੀਬ ਵਾਕ-ਸਮੂਹ, ਬਾਰਡਰਲਾਈਨ ਫੈਸਲੇ।

ਪ੍ਰੋਡਕਸ਼ਨ ਮਾਨੀਟਰਿੰਗ (ਗ੍ਰਾਹਕਾਂ ਤੋਂ ਪਹਿਲਾਂ ਡ੍ਰਿਫਟ ਫੜੋ)

ਸਮੇਂ-ਸਮੇਂ 'ਤੇ ਫੈਸਲੇ ਦੀਆਂ ਵੰਡਾਂ ਅਤੇ ਗੁਣਵੱਤਾ ਸਿਗਨਲ ਟਰੈਕ ਕਰੋ:

• ਡ੍ਰਿਫਟ: ਮਨਜ਼ੂਰੀ/ਅਨਮਨਜ਼ੂਰੀ ਦਰਾਂ policy ਅਪਡੇਟ ਬਿਨਾਂ ਬਦਲ ਰਹੀਆਂ ਹਨ
• needs_review ਜਾਂ ਮਨੁੱਖੀ ਹੱਥਾਂ 'ਤੇ ਹਵਾਲਾ ਵਧਣਾ (ਅਕਸਰ ਪ੍ਰੰਪਟ, ਰੀਟਰੀਵਲ ਜਾਂ upstream ਡੇਟਾ ਸਮੱਸਿਆ)
• ਉਤਪਾਦ, ਖੇਤਰ ਜਾਂ ਨੀਤੀ ਵਰਗੀ ਕਟੇਗਰੀਆਂ ਵਿੱਚ ਗਲਤੀ ਕਲੱਸਟਰ

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

Koder.ai ਇਸ ਪਾਈਪਲਾਈਨ ਵਿੱਚ ਕਿੱਥੇ ਬੈਠਦਾ ਹੈ

ਜੇ ਤੁਸੀਂ ਉੱਪਰ ਦਿੱਤੇ ਪੈਟਰਨਾਂ ਨੂੰ ਲਾਗੂ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ ਆਮ ਤੌਰ 'ਤੇ ਤੁਸੀਂ ਮਾਡਲ ਦੇ ਚਾਰੇ-ਪਾਸੇ ਇੱਕ ਛੋਟਾ ਸਿਸਟਮ ਬਣਾਉਂਦੇ ਹੋ: ਸਟੇਟ ਸਟੋਰੇਜ, ਟੂਲ ਕਾਲ, ਰੀਟਰੀਵਲ, ਸਕੀਮਾ ਵੈਲੀਡੇਸ਼ਨ, ਅਤੇ ਵਰਕਫਲੋ ਆਰਕੈਸਟਰੇਸ਼ਨ। Koder.ai ਇੱਕ عملي ਤਰੀਕਾ ਹੈ ਜ਼ਿਆਦਾ ਤੇਜ਼ੀ ਨਾਲ ਐਸੇ ਵਰਕਫਲੋ-ਬੈਕਡ ਸਹਾਇਕ ਦੀ ਪ੍ਰੋਟੋਟਾਈਪ ਅਤੇ ਸ਼ਿਪਿੰਗ ਲਈ: ਤੁਸੀਂ ਚੈਟ ਵਿੱਚ ਵਰਕਫਲੋ ਵਰਣਨ ਕਰ ਸਕਦੇ ਹੋ, ਇੱਕ ਕੰਮ ਕਰਦਾ React ਐਪ + ਬੈਕਐਂਡ ਸਰਵਿਸਿਜ਼ (Go + PostgreSQL) ਜਨਰੇਟ ਕਰ ਸਕਦੇ ਹੋ, ਅਤੇ ਸਨੈਪਸ਼ਾਟ ਅਤੇ ਰੋਲਬੈਕ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਇਟਰਟ ਕਰ ਸਕਦੇ ਹੋ।

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

• Planning mode: ਤੁਸੀਂ ਪ੍ਰਦਾਨ-ਕਦਮ (states), ਮਨਜ਼ੂਰੀਆਂ, ਅਤੇ ਐਸਕਲੇਸ਼ਨ ਪਾਥ ਪਹਿਲਾਂ ਡਿਜ਼ਾਈਨ ਕਰ ਸਕਦੇ ਹੋ।
• Schema-constrained responses: ਇਹ API ਸੀਮਾ 'ਤੇ ਲਾਗੂ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ ਤਾਂ ਕਿ ਤੁਹਾਡੇ ਸਿਰਫ ਪਰਸ ਕਰ ਸਕਣੇ ਯੋਗ ਫੈਸਲੇ ਹੀ ਮਿਲਣ।
• Tooling hooks: DB ਪੜ੍ਹਾਈ, ਨੀਤੀ ਰੀਟਰੀਵਲ, ਕੈਲਕुलेਟਰ ਅਤੇ ਟਿਕਟ ਅਪਡੇਟ ਸਪਸ਼ਟ ਏਂਡਪਾਇੰਟ ਵਜੋਂ ਲਾਗੂ ਕੀਤੇ ਜਾ ਸਕਦੇ ਹਨ, ਅਤੇ ਇਸ ਤਰ੍ਹਾਂ "ਪਹਿਲਾਂ ਸਬੂਤ ਲਿਆਓ, ਫਿਰ ਫੈਸਲਾ ਕਰੋ" ਡਿਫਾਲਟ ਬਣ ਜਾਂਦਾ ਹੈ।
• Source code export: ਜਦੋਂ ਪ੍ਰੋਟੋਟਾਈਪ ਪ੍ਰੋਡਕਸ਼ਨ-ਅਹਿਮ ਹੋ ਜਾਵੇ ਤਾਂ ਤੁਸੀਂ ਲੌਕ-ਇਨ ਤੋਂ ਬਚ ਸਕਦੇ ਹੋ।

ਹੱਦਾਂ, ਸੁਰੱਖਿਅਤ ਵਰਤੋਂ ਅਤੇ ਕਦੋਂ ਮਨੁੱਖੀ ਰੋਲ ਲਾਜ਼ਮੀ ਰੱਖਣਾ

LLMs ਰੋਜ਼ਾਨਾ ਨੀਤੀਆਂ ਨੂੰ ਲਾਗੂ ਕਰਨ ਵਿੱਚ ਹੈਰਾਨ ਕਰਨ ਵਾਲੇ ਤੌਰ 'ਤੇ ਚੰਗੇ ਹੋ ਸਕਦੇ ਹਨ, ਪਰ ਉਹ deterministic rules engine ਦੇ ਬਰਾਬਰ ਨਹੀਂ। ਓਹਨਾਂ ਨੂੰ ਗਾਰਡਰੇਲ, ਨਹੀਂ ਸੰਪੂਰਨ ਅਧਿਕਾਰ ਦੇ ਕੇ ਇਕ ਮੱਦਦਗਾਰ ਮੰਨੋ।

LLMs ਅਕਸਰ ਕਿੱਥੇ ਮੁਸ਼ਕਲ ਕਰਦੇ ਹਨ

ਤਿੰਨ ਫੇਲ-ਮੋਡ ਆਮ ਤੌਰ 'ਤੇ ਨਜ਼ਰ ਆਉਂਦੇ ਹਨ:

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

ਕਦੋਂ ਮਨੁੱਖੀ ਸਮੀਖਿਆ ਲਾਜ਼ਮੀ ਰੱਖੋ

ਮਨੁੱਖੀ ਸਮੀਖਿਆ ਲਾਜ਼ਮੀ ਕਰੋ ਜਦੋਂ:

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

ਐਸਕਲੇਸ਼ਨ ਪਾਥ ਜੋ ਕੰਮ ਨੂੰ ਜਾਰੀ ਰੱਖਦੇ ਹਨ

ਮਾਡਲ "ਕੁਝ ਬਣਾਉਣ" ਦੀ ਥਾਂ, ਸਪੱਸ਼ਟ ਅਗਲਾ ਕਦਮ ਨਿਯਤ ਕਰੋ:

1. ਸਪਸ਼ਟੀਕਰਨ ਸਵਾਲ ਪੁੱਛੋ (ਗਾਇਬ ਤਰੀਕਾਂ, ਗ੍ਰਾਹਕ ਟੀਅਰ, ਇਲਾਕਾ, ਮਨਜ਼ੂਰੀ ਦਰਸਾਏ गए)।
2. ਏਜੰਟ ਨੂੰ ਰੂਟ ਕਰੋ ਜਿੱਥੇ ਤੱਥ, ਪ੍ਰਸਤਾਵਿਤ ਫੈਸਲਾ ਅਤੇ ਸਾਈਟੇਸ਼ਨਸ ਹੋਣ।
3. ਟਿਕਟ ਬਣਾਓ ਜਦੋਂ ਨੀਤੀ ਅਸਪਸ਼ਟ ਜਾਂ ਟਕਰਾਅ ਵਾਲੀ ਹੋ, ਤਾਂ ਕਿ ਇਸਨੂੰ ਸਰੋਤ 'ਤੇ ਠੀਕ ਕੀਤਾ ਜਾ ਸਕੇ (ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਆਟੋਮੈਟਿਕ ਤੌਰ 'ਤੇ ਰੀਟਰੀਵ ਕੀਤਾ ਜਾ ਸਕੇ)।

ਇੱਕ ਸਧਾਰਨ ਅਡੋਪਸ਼ਨ ਚੱਕਰ

LLMs ਨੂੰ ਨਿਯਮ-ਭਾਰੇ ਵਰਕਫਲੋਜ਼ ਵਿੱਚ ਇਸ ਵੇਲੇ ਵਰਤੋ ਜਦੋਂ ਤੁਸੀਂ ਜ਼ਿਆਦਾਤਰ ਸਵਾਲਾਂ ਦੇ 'ਹਾਂ' ਵਿੱਚ ਜਵਾਬ ਦੇ ਸਕੋ:

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

ਜੇ ਨਹੀਂ, ਤਾਂ ਉਨ੍ਹਾਂ ਨਿਯੰਤਰਣਾਂ ਦੇ ਹੋਣ ਤੱਕ LLM ਨੂੰ ਡ੍ਰਾਫਟ/ਸਹਾਇਕ ਭੂਮਿਕਾ ਵਿੱਚ ਰੱਖੋ।