ਯੂਨਿਟ 11 / 11

ਅੰਤ-ਤੋਂ-ਅੰਤ ਉਤਪਾਦਨ: ਤਸਦੀਕ, ਨਿਗਰਾਨੀ ਅਤੇ ਨੈਤਿਕਤਾ

ਲਾਭ:

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

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

ਉਤਪਾਦਨ ਆਰਕੀਟੈਕਚਰ ਦੀਆਂ ਪਰਤਾਂ

ਇੱਕ ਠੋਸ LLM ਯੋਗਤਾ ਵਿੱਚ ਲਗਭਗ ਪੰਜ ਪਰਤਾਂ ਹੁੰਦੀਆਂ ਹਨ:

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

ਇਹ ਪਰਤਾਂ ਇੱਕ ਪਾਈਪਲਾਈਨ ਹਨ; ਹਰ ਇੱਕ ਪਿਛਲੇ ਇੱਕ ਦੇ ਆਉਟਪੁੱਟ ਦੀ ਜਾਂਚ ਕਰਦਾ ਹੈ।

ਪੁਸ਼ਟੀਕਰਨ ਦੀ ਲੋੜ ਕਿਉਂ ਹੈ?

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

ਤਸਦੀਕ ਪਰਤਾਂ (ਪ੍ਰਭਾਵ ਦੁਆਰਾ ਵਧ ਰਹੀਆਂ):

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

ਮਨੁ—ਵਿਚ-ਵਿਚ

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

ਫੈਸਲੇ ਦਾ ਪ੍ਰਭਾਵ

ਪਹੁੰਚ

ਘੱਟ (ਲੇਬਲ ਸੁਝਾਅ, ਡਰਾਫਟ)

ਪੂਰੀ ਆਟੋਮੇਸ਼ਨ; ਗਲਤੀ ਸਸਤੀ ਅਤੇ ਉਲਟ ਹੈ

ਮੱਧਮ (ਰੂਟਿੰਗ, ਤਰਜੀਹ)

ਆਟੋਮੇਸ਼ਨ + ਨਮੂਨਾ ਨਿਯੰਤਰਣ

ਉੱਚ (ਪੈਸਾ, ਇਕਰਾਰਨਾਮਾ, ਸਿਹਤ, ਮਿਟਾਉਣਾ)

ਮਨੁੱਖੀ ਸਹਿਮਤੀ ਲਾਜ਼ਮੀ ਹੈ; ਮਾਡਲ ਸਿਰਫ ਸੁਝਾਅ ਦਿੰਦਾ ਹੈ

ਨਿਗਰਾਨੀ: ਤੁਸੀਂ ਉਹ ਪ੍ਰਬੰਧ ਨਹੀਂ ਕਰ ਸਕਦੇ ਜੋ ਤੁਸੀਂ ਨਹੀਂ ਦੇਖਦੇ

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

  • ਵਰਤੋਂ/ਲਾਗਤ: ਪ੍ਰਤੀ ਬੇਨਤੀ ਅਤੇ ਕੁੱਲ ਟੋਕਨ, ਮਾਡਲ ਵੰਡ, ਰੋਜ਼ਾਨਾ ਖਰਚ।
  • ਲੇਟੈਂਸੀ: ਔਸਤ ਅਤੇ ਸਭ ਤੋਂ ਮਾੜੇ-ਕੇਸ ਜਵਾਬ ਸਮਾਂ।
  • ਗਲਤੀ ਦਰ: 429/500 ਦਰਾਂ, ਮੁੜ ਕੋਸ਼ਿਸ਼ਾਂ, ਤਿਆਗ।
  • ਗੁਣਵੱਤਾ: ਤਸਦੀਕ ਪਰਤ 'ਤੇ ਅਸਵੀਕਾਰ ਕੀਤੀ ਆਉਟਪੁੱਟ ਦਰ, ਮਨੁੱਖੀ ਮਨਜ਼ੂਰੀ 'ਤੇ ਸੁਧਾਰ ਦਰ, ਉਪਭੋਗਤਾ ਫੀਡਬੈਕ।
ਸੰਕੇਤ: ਨਿਗਰਾਨੀ ਲੌਗਸ ਵਿੱਚ ਸੰਵੇਦਨਸ਼ੀਲ ਡੇਟਾ (ਨਿੱਜੀ ਜਾਣਕਾਰੀ, ਕੁੰਜੀਆਂ) ਨਾ ਲਿਖੋ। ਗੁਪਤਤਾ ਦੇ ਦਾਇਰੇ ਦੇ ਅੰਦਰ ਲੌਗਾਂ 'ਤੇ ਵਿਚਾਰ ਕਰੋ; ਜੇ ਲੋੜ ਹੋਵੇ ਤਾਂ ਮਾਸਕ ਦੁਆਰਾ ਰਿਕਾਰਡ ਕਰੋ (ਯੂਨਿਟ 9)।

ਨੈਤਿਕਤਾ ਅਤੇ ਸੀਮਾਵਾਂ

ਨੈਤਿਕ ਜ਼ਿੰਮੇਵਾਰੀ ਉਤਪਾਦਨ ਦੇ ਫੈਸਲੇ ਦਾ ਓਨਾ ਹੀ ਹਿੱਸਾ ਹੈ ਜਿੰਨਾ ਤਕਨੀਕੀ ਸ਼ੁੱਧਤਾ:

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

ਕਾਪੀ ਕਰਨ ਯੋਗ ਟੈਂਪਲੇਟਸ

# ਪ੍ਰਮਾਣਿਕਤਾ ਚੈਕਲਿਸਟ (ਆਉਟਪੁੱਟ ਬਣਾਉਣ ਤੋਂ ਬਾਅਦ) 1) ਕੀ ਸਕੀਮਾ ਵੈਧ ਹੈ? (ਢਾਂਚਾਗਤ ਆਉਟਪੁੱਟ ਪ੍ਰਮਾਣਿਕਤਾ) 2) ਕੀ ਮੁੱਲ ਅਰਥ ਬਣਾਉਂਦੇ ਹਨ? (ਨਿਯਮ ਜਾਂਚ: ਰੇਂਜ, ਮਿਤੀ, enum)3) ਕੀ ਦਾਅਵਾ ਸਰੋਤ 'ਤੇ ਅਧਾਰਤ ਹੈ? (ਦਸਤਾਵੇਜ਼ ਵਿੱਚ ਨਾ ਹੋਣ 'ਤੇ ਅਸਵੀਕਾਰ ਕਰੋ) 4) ਕੀ ਪ੍ਰਭਾਵ ਜ਼ਿਆਦਾ ਹੈ? → ਮਨੁੱਖੀ ਪ੍ਰਵਾਨਗੀ ਲਈ ਭੇਜੋ5) ਜੇਕਰ ਸਭ ਪਾਸ ਹੋ ਜਾਂਦੇ ਹਨ → ਕਾਰਵਾਈ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦੇ ਹਨ, ਬਚਾਓ

# ਸਿਸਟਮ ਪ੍ਰੋਂਪਟ ਜੋ ਸਰੋਤ 'ਤੇ ਭਰੋਸਾ ਕਰਨ ਲਈ ਮਜਬੂਰ ਕਰਦਾ ਹੈ. ਅਜਿਹੀ ਕੋਈ ਵੀ ਚੀਜ਼ ਨਾ ਜੋੜੋ ਜੋ ਦਸਤਾਵੇਜ਼ ਵਿੱਚ ਨਹੀਂ ਹੈ। ਜੇਕਰ ਕੋਈ ਜਾਣਕਾਰੀ ਦਸਤਾਵੇਜ਼ ਵਿੱਚ ਨਹੀਂ ਹੈ, ਤਾਂ "ਦਸਤਾਵੇਜ਼ ਵਿੱਚ ਨਹੀਂ ਮਿਲਿਆ" ਲਿਖੋ। ਕਦੇ ਵੀ ਚੀਜ਼ਾਂ ਦਾ ਅੰਦਾਜ਼ਾ ਨਾ ਲਗਾਓ ਜਾਂ ਨਾ ਬਣਾਓ।

# ਮਨੁੱਖੀ ਪ੍ਰਵਾਨਗੀ ਥ੍ਰੈਸ਼ਹੋਲਡ (ਫੈਸਲਾ ਨਿਯਮ) IF [ਪੈਸਾ, ਇਕਰਾਰਨਾਮਾ, ਮਿਟਾਓ, ਸਿਹਤ] ਵਿੱਚ ਫੈਸਲਾ_ਟਾਈਪ ਕਰੋ → ਮਨੁੱਖੀ ਮਨਜ਼ੂਰੀ ਲਾਜ਼ਮੀ IF ਮਾਡਲ_ਟਰੱਸਟ < ਥ੍ਰੈਸ਼ਹੋਲਡ ਜਾਂ ਪ੍ਰਮਾਣਿਕਤਾ "ਅਨਿਸ਼ਚਿਤ" → ਮਨੁੱਖੀ ਮਨਜ਼ੂਰੀ ਲਈ ਜਮ੍ਹਾਂ ਕਰੋOTHER → ਆਟੋ ਲਾਗੂ + ਨਮੂਨਾ ਕੰਟਰੋਲ

# ਟਰੇਸ ਲੌਗ ਟੈਮਪਲੇਟ (ਸੰਵੇਦਨਸ਼ੀਲ ਡੇਟਾ ਲਿਖਣਾ) { "ਸਮਾਂ":"...", "ਮਾਡਲ":"...", "ਇਨਪੁਟ_ਟੋਕਨ":..., "ਆਉਟਪੁੱਟ_ਟੋਕਨ":..., "ਦੇਰੀ_ਐਮਐਸ":..., "ਸਟਾਪ_ਕਾਰਨ":"...", "ਪ੍ਰਮਾਣਿਕਤਾ":"ਪਾਸ ਕੀਤਾ ਗਿਆ | ਅਸਵੀਕਾਰ ਕੀਤਾ ਗਿਆ | ਮਨੁੱਖੀ" // NE_ਸਹਿਤ ਡੇਟਾ ਲਿਖਿਆ ਗਿਆ ਹੈ, "ਨਿੱਜੀ ਡਾਟਾ ਹੈ।"

ਕਮਜ਼ੋਰ ਪ੍ਰੋਂਪਟ / ਮਜ਼ਬੂਤ ਪ੍ਰੋਂਪਟ (ਉਤਪਾਦਨ ਭਰੋਸੇਯੋਗਤਾ)

# ਕਮਜ਼ੋਰ (ਕੋਈ ਤਸਦੀਕ ਨਹੀਂ, ਕੋਈ ਸਰੋਤ ਨਹੀਂ, ਆਪਣੇ ਆਪ ਲਾਗੂ ਹੁੰਦਾ ਹੈ) ਇਸ ਬੇਨਤੀ ਦਾ ਮੁਲਾਂਕਣ ਕਰੋ, ਰਿਫੰਡ ਦਾ ਫੈਸਲਾ ਕਰੋ ਅਤੇ ਅਰਜ਼ੀ ਦਿਓ।

# STRONG (ਸਰੋਤ-ਆਧਾਰਿਤ, ਸਿਫ਼ਾਰਸ਼ ਤਿਆਰ ਕਰਦਾ ਹੈ, ਮਨੁੱਖੀ ਪ੍ਰਵਾਨਗੀ ਲਈ ਛੱਡਦਾ ਹੈ) ਸਿਰਫ਼ ਵਾਪਸੀ ਨੀਤੀ ਦਸਤਾਵੇਜ਼ ਦੇ ਆਧਾਰ 'ਤੇ ਇਸ ਵਾਪਸੀ ਦੀ ਬੇਨਤੀ ਦਾ ਮੁਲਾਂਕਣ ਕਰੋ। ਜਾਇਜ਼ਤਾ ਦੇ ਨਾਲ ਫੈਸਲੇ ਦੀ ਸਿਫ਼ਾਰਸ਼ ਕਰੋ ਪਰ ਲਾਗੂ ਨਾ ਕਰੋ: {"ਸਿਫਾਰਿਸ਼":"ਪ੍ਰਵਾਨਗੀ|ਅਸਵੀਕਾਰ","ਕਾਰਨ":"...","policy_clause":"..."}।ਜੇਕਰ ਨੀਤੀ ਦਸਤਾਵੇਜ਼ ਵਿੱਚ ਕੋਈ ਸਪੱਸ਼ਟ ਆਧਾਰ ਨਹੀਂ ਹੈ, ਤਾਂ "ਅਸਪਸ਼ਟ" ਦਿਓ। ਇੱਕ ਪ੍ਰਤੀਨਿਧੀ ਅੰਤਿਮ ਫੈਸਲੇ ਨੂੰ ਮਨਜ਼ੂਰੀ ਦੇਵੇਗਾ।

ਸ਼ਕਤੀਸ਼ਾਲੀ ਸੰਸਕਰਣ; ਇਹ ਸਰੋਤ ਨੂੰ ਫੈਸਲੇ ਦਾ ਵਿਸ਼ੇਸ਼ਤਾ ਦਿੰਦਾ ਹੈ, ਮਾਡਲ ਨੂੰ "ਕਰਨ ਵਾਲੇ" ਦੀ ਬਜਾਏ "ਸੁਝਾਅ ਦੇਣ ਵਾਲੇ" ਵਜੋਂ ਰੱਖਦਾ ਹੈ ਅਤੇ ਮਨੁੱਖੀ ਪ੍ਰਵਾਨਗੀ ਦੇ ਪਿੱਛੇ ਉੱਚ-ਪ੍ਰਭਾਵੀ ਕਦਮ ਰੱਖਦਾ ਹੈ। ਇਹ ਉਤਪਾਦਨ ਦੀ ਭਰੋਸੇਯੋਗਤਾ ਦਾ ਸਾਰ ਹੈ.

ਤਿੰਨ ਮਿੰਨੀ ਕੇਸ

ਕੇਸ 1 — ਜਿਸ ਦਿਨ ਪੁਸ਼ਟੀਕਰਨ ਪਰਤ ਨੂੰ ਸੁਰੱਖਿਅਤ ਕੀਤਾ ਗਿਆ ਸੀ। ਇੱਕ ਫਿਨਟੇਕ ਕੋਲ ਮਾਡਲ ਸ਼੍ਰੇਣੀਬੱਧ ਲੈਣ-ਦੇਣ ਦੇ ਵਰਣਨ ਅਤੇ ਆਟੋਮੈਟਿਕ ਲੇਖਾ ਰਿਕਾਰਡ ਬਣਾਉਣਾ ਸੀ। ਉਹਨਾਂ ਨੇ ਨਿਯਮ ਪ੍ਰਮਾਣਿਕਤਾ ਨੂੰ ਜੋੜਿਆ: ਇੱਕ ਵਾਰ ਮਾਡਲ ਨੇ ਰਕਮ ਨੂੰ ਗਲਤ ਤਰੀਕੇ ਨਾਲ ਆਉਟਪੁੱਟ ਕੀਤਾ (ਦਸਤਾਵੇਜ਼ ਵਿੱਚ 1,250 ਦੀ ਬਜਾਏ 12,500), "ਰਮਾਤ ਦਸਤਾਵੇਜ਼ ਨਾਲ ਮੇਲ ਨਹੀਂ ਖਾਂਦੀ" ਨਿਯਮ ਨੇ ਆਉਟਪੁੱਟ ਨੂੰ ਰੱਦ ਕਰ ਦਿੱਤਾ ਅਤੇ ਰਿਕਾਰਡ ਮਨੁੱਖ ਦੇ ਕੋਲ ਡਿੱਗ ਗਿਆ। ਜੇਕਰ ਕੋਈ ਤਸਦੀਕ ਨਹੀਂ ਸੀ, ਤਾਂ ਗਲਤ ਰਿਕਾਰਡ ਚੁੱਪਚਾਪ ਸਿਸਟਮ ਵਿੱਚ ਦਾਖਲ ਹੋ ਜਾਵੇਗਾ।

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

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

ਆਮ ਗਲਤੀਆਂ

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

ਡੂੰਘੇ: ਰੀਲੀਜ਼ ਪ੍ਰਬੰਧਨ, ਰੋਲਬੈਕ, ਅਤੇ ਵਾਧੇ ਵਾਲੀ ਤੈਨਾਤੀ

ਇੱਕ LLM ਵਿਸ਼ੇਸ਼ਤਾ ਨੂੰ ਉਤਪਾਦਨ ਵਿੱਚ ਲੈਣਾ ਇਸ ਨੂੰ ਸਥਾਪਤ ਕਰਨ ਅਤੇ ਇਸ ਬਾਰੇ ਭੁੱਲਣ ਬਾਰੇ ਨਹੀਂ ਹੈ; ਸਮੇਂ ਦੇ ਨਾਲ ਇੱਕ ਲਾਈਵ ਸਿਸਟਮ ਨੂੰ ਸੁਰੱਖਿਅਤ ਢੰਗ ਨਾਲ ਸੋਧਣਾ ਹੈ। ਇਸ ਦੇ ਤਿੰਨ ਥੰਮ ਹਨ।

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

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

ਹੌਲੀ-ਹੌਲੀ ਰੋਲਆਊਟ। ਇੱਕ ਵਾਰ ਵਿੱਚ ਸਾਰੇ ਟ੍ਰੈਫਿਕ ਵਿੱਚ ਇੱਕ ਤਬਦੀਲੀ ਲਾਗੂ ਕਰਨ ਦੀ ਬਜਾਏ, ਤੁਸੀਂ ਇਸਨੂੰ ਪਹਿਲਾਂ ਇੱਕ ਛੋਟੀ ਪ੍ਰਤੀਸ਼ਤਤਾ (ਜਿਵੇਂ ਕਿ 5%) ਵਿੱਚ ਰੋਲ ਆਊਟ ਕਰੋ ਅਤੇ ਮੈਟ੍ਰਿਕਸ (ਗੁਣਵੱਤਾ, ਲਾਗਤ, ਗਲਤੀਆਂ) ਦੀ ਨਿਗਰਾਨੀ ਕਰੋ। ਜੇ ਇਹ ਚੰਗਾ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਪ੍ਰਤੀਸ਼ਤ ਨੂੰ ਵਧਾਉਂਦੇ ਹੋ; ਜੇਕਰ ਇਹ ਮਾੜਾ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਇਸ ਨੂੰ ਸਿਰਫ਼ ਇੱਕ ਛੋਟੇ ਜਿਹੇ ਹਿੱਸੇ ਨਾਲ ਪ੍ਰਭਾਵਿਤ ਕਰਕੇ ਵਾਪਸ ਪ੍ਰਾਪਤ ਕਰੋਗੇ। ਇਹ ਜੋਖਮ ਨੂੰ ਬਹੁਤ ਹੱਦ ਤੱਕ ਸੀਮਤ ਕਰਦਾ ਹੈ।

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

ਸੰਖੇਪ ਵਿੱਚ

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

ਐਪਲੀਕੇਸ਼ਨ ਦਾ ਕੰਮ

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

ਚੈੱਕਲਿਸਟ

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

ਮੋਡੀਊਲ ਪ੍ਰੀਖਿਆ

1. LLM ਚੈਟ API ਵਿੱਚ 'ਸਿਸਟਮ' ਭੂਮਿਕਾ ਕੀ ਕਰਦੀ ਹੈ?

  • A) ਮਾਡਲ ਨੂੰ ਸਥਾਈ ਹਦਾਇਤਾਂ ਅਤੇ ਵਿਵਹਾਰ ਦੇ ਨਿਯਮ ਦਿੰਦਾ ਹੈ ਜੋ ਸਾਰੀ ਗੱਲਬਾਤ ਦੌਰਾਨ ਲਾਗੂ ਹੁੰਦੇ ਹਨ ✔
  • ਅ) ਉਪਭੋਗਤਾ ਦੁਆਰਾ ਲਿਖੇ ਆਖਰੀ ਸਵਾਲ ਨੂੰ ਰੱਖਦਾ ਹੈ
  • C) ਮਾਡਲ ਦੁਆਰਾ ਪੈਦਾ ਕੀਤੇ ਜਵਾਬ ਨੂੰ ਸਟੋਰ ਕਰਦਾ ਹੈ
  • D) API ਕੁੰਜੀ ਨੂੰ ਐਨਕ੍ਰਿਪਟ ਕਰਦਾ ਹੈ

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

2. ਇੱਕ API ਬੇਨਤੀ ਵਿੱਚ ਹਰ ਵਾਰ ਗੱਲਬਾਤ ਦਾ ਇਤਿਹਾਸ (ਪਿਛਲੇ ਸੁਨੇਹੇ) ਦੁਬਾਰਾ ਕਿਉਂ ਭੇਜੇ ਜਾਂਦੇ ਹਨ?

  • ਏ) ਬੈਕਅੱਪ ਲੈਣਾ ਜ਼ਰੂਰੀ ਹੈ ਕਿਉਂਕਿ ਸਰਵਰ ਇਤਿਹਾਸ ਨੂੰ ਮਿਟਾ ਦਿੰਦਾ ਹੈ
  • ਅ) API ਕਾਲਾਂ ਸਟੇਟਲੈੱਸ ਹਨ; ✔ ਹਰ ਬੇਨਤੀ 'ਤੇ ਸੰਦਰਭ ਭੇਜਿਆ ਜਾਂਦਾ ਹੈ ਕਿਉਂਕਿ ਮਾਡਲ ਇਤਿਹਾਸ ਨੂੰ ਯਾਦ ਨਹੀਂ ਰੱਖਦਾ ਹੈ
  • C) ਸਿਰਫ ਇਨਵੌਇਸਿੰਗ ਲਈ ਲੋੜੀਂਦਾ ਹੈ, ਮਾਡਲ 'ਤੇ ਕੋਈ ਪ੍ਰਭਾਵ ਨਹੀਂ ਹੈ
  • D) ਜਵਾਬ ਨੂੰ ਹੌਲੀ ਕਰਨ ਤੋਂ ਬਚਣ ਲਈ ਇਤਿਹਾਸ ਭੇਜਣਾ ਲਾਜ਼ਮੀ ਹੈ

ਵਿਆਖਿਆ: LLM API ਕਾਲਾਂ ਸਟੇਟਲੈੱਸ ਹਨ; ਮਾਡਲ ਪਿਛਲੇ ਦੌਰ ਨੂੰ ਯਾਦ ਨਹੀਂ ਰੱਖਦਾ ਹੈ, ਇਸਲਈ ਪ੍ਰਸੰਗ ਨੂੰ ਸੁਰੱਖਿਅਤ ਰੱਖਣ ਲਈ ਹਰ ਬੇਨਤੀ 'ਤੇ ਸਾਰੇ ਸੰਬੰਧਿਤ ਇਤਿਹਾਸ ਨੂੰ ਮੁੜ ਭੇਜਿਆ ਜਾਂਦਾ ਹੈ।

3. LLM ਕੀਮਤ ਵਿੱਚ 'ਟੋਕਨ' ਕੀ ਹੈ?

  • ਏ) API ਵਿੱਚ ਲੌਗ ਇਨ ਕਰਨ ਲਈ ਵਰਤਿਆ ਜਾਣ ਵਾਲਾ ਇੱਕ ਵਾਰ ਦਾ ਪਾਸਵਰਡ
  • ਬੀ) ਹਰੇਕ ਬੇਨਤੀ 'ਤੇ ਇੱਕ ਨਿਸ਼ਚਿਤ ਫੀਸ ਅਦਾ ਕੀਤੀ ਜਾਂਦੀ ਹੈ
  • C) ਸਭ ਤੋਂ ਛੋਟੀ ਇਕਾਈ ਜਿਸ ਵਿੱਚ ਮਾਡਲ ਟੈਕਸਟ ਦੀ ਪ੍ਰਕਿਰਿਆ ਕਰਦਾ ਹੈ; ਆਮ ਤੌਰ 'ਤੇ ਸ਼ਬਦ ਭਾਗ ✔ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਹੈ
  • D) ਇੱਕ ਯੂਨਿਟ ਜੋ ਸਿਰਫ ਆਉਟਪੁੱਟ ਦੀ ਲੰਬਾਈ ਨੂੰ ਮਾਪਦੀ ਹੈ

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

4. ਜ਼ਿਆਦਾਤਰ LLM ਪ੍ਰਦਾਤਾਵਾਂ 'ਤੇ ਆਉਟਪੁੱਟ ਟੋਕਨ ਇਨਪੁਟ ਟੋਕਨਾਂ ਨਾਲੋਂ ਮਹਿੰਗੇ ਕਿਉਂ ਹਨ?

  • ਏ) ਆਉਟਪੁੱਟ ਟੋਕਨ ਹਮੇਸ਼ਾ ਇੰਪੁੱਟ ਤੋਂ ਲੰਬੇ ਹੁੰਦੇ ਹਨ
  • ਅ) ਇਨਪੁਟ ਟੋਕਨ ਮੁਫ਼ਤ ਹਨ
  • C) ਆਉਟਪੁੱਟ ਟੋਕਨ ਇੰਟਰਨੈਟ ਤੇ ਦੋ ਵਾਰ ਭੇਜੇ ਜਾਂਦੇ ਹਨ
  • D) ਯੂਨਿਟ ਦੀ ਲਾਗਤ ਵੱਧ ਹੈ ਕਿਉਂਕਿ ਆਉਟਪੁੱਟ ਬਣਾਉਣ ਲਈ ਹਰੇਕ ਟੋਕਨ ਲਈ ਵਾਧੂ ਗਣਨਾਵਾਂ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ ✔

ਵਰਣਨ: ਹਰੇਕ ਆਉਟਪੁੱਟ ਟੋਕਨ ਲਈ ਮਾਡਲ ਨੂੰ ਕਦਮ-ਦਰ-ਕਦਮ ਜਨਰੇਸ਼ਨ (ਗਣਨਾ) ਕਰਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ; ਇਹ ਉਤਪਾਦਨ ਲਾਗਤ ਇੰਪੁੱਟ ਨੂੰ ਇੱਕ ਵਾਰ ਵਿੱਚ ਪ੍ਰੋਸੈਸ ਕਰਨ ਨਾਲੋਂ ਵੱਧ ਹੈ, ਇਸਲਈ ਆਉਟਪੁੱਟ ਯੂਨਿਟ ਦੀ ਕੀਮਤ ਆਮ ਤੌਰ 'ਤੇ ਵੱਧ ਹੁੰਦੀ ਹੈ।

5. ਕਿਹੜੀ ਸਥਿਤੀ ਵਿੱਚ ਸਟ੍ਰੀਮਿੰਗ ਦੀ ਵਰਤੋਂ ਕਰਨਾ ਸਭ ਤੋਂ ਲਾਭਕਾਰੀ ਹੈ?

  • ਏ) ਲੰਬੇ ਜਵਾਬਾਂ ਵਿੱਚ; ਸਮਝੀ ਗਈ ਦੇਰੀ ਨੂੰ ਘਟਾਉਂਦਾ ਹੈ ਅਤੇ ਸਮਾਂ ਸਮਾਪਤ ਹੋਣ ਤੋਂ ਰੋਕਦਾ ਹੈ ✔
  • ਅ) ਸਿਰਫ਼ ਬਹੁਤ ਹੀ ਛੋਟੇ, ਇੱਕ-ਸ਼ਬਦ ਦੇ ਜਵਾਬਾਂ ਵਿੱਚ
  • ਸੀ) ਲਾਗਤ ਨੂੰ ਜ਼ੀਰੋ ਤੱਕ ਘਟਾਉਣ ਲਈ
  • ਡੀ) API ਕੁੰਜੀ ਨੂੰ ਲੁਕਾਉਣ ਲਈ

ਵਰਣਨ: ਲੰਬੇ ਜਵਾਬਾਂ ਵਿੱਚ, ਸਟ੍ਰੀਮਿੰਗ ਪਹਿਲੇ ਸ਼ਬਦਾਂ ਨੂੰ ਤੁਰੰਤ ਵਿਖਾਉਣ ਦੁਆਰਾ ਸਮਝੀ ਗਈ ਲੇਟੈਂਸੀ ਨੂੰ ਘਟਾਉਂਦੀ ਹੈ ਅਤੇ ਵੱਡੇ max_tokens ਮੁੱਲਾਂ 'ਤੇ HTTP ਸਮਾਂ ਸਮਾਪਤ ਹੋਣ ਤੋਂ ਰੋਕਦੀ ਹੈ।

6. ਆਧੁਨਿਕ ਮਾਡਲਾਂ ਵਿੱਚ 'ਕੋਸ਼ਿਸ਼' ਪੈਰਾਮੀਟਰ ਨੂੰ ਵਧਾਉਣ ਨਾਲ ਆਮ ਤੌਰ 'ਤੇ ਕੀ ਪ੍ਰਭਾਵ ਪੈਂਦਾ ਹੈ?

  • ਏ) ਜਵਾਬ ਨੂੰ ਹਮੇਸ਼ਾ ਛੋਟਾ ਕਰੋ
  • ਅ) API ਕੁੰਜੀ ਨੂੰ ਆਟੋਮੈਟਿਕਲੀ ਘੁੰਮਾਉਂਦਾ ਹੈ
  • C) ਇਹ ਸਿਰਫ ਇਨਪੁਟ ਟੋਕਨ ਕੀਮਤ ਨੂੰ ਘਟਾਉਂਦਾ ਹੈ
  • ਡੀ) ਸੋਚ ਦੀ ਡੂੰਘਾਈ ਅਤੇ ਟੋਕਨ ਖਰਚ ਨੂੰ ਵਧਾਉਂਦਾ ਹੈ; ਇਹ ਗੁਣਵੱਤਾ ਵਿੱਚ ਸੁਧਾਰ ਕਰ ਸਕਦਾ ਹੈ, ਪਰ ਇਹ ਲੇਟੈਂਸੀ ਅਤੇ ਲਾਗਤ ਨੂੰ ਵੀ ਵਧਾਉਂਦਾ ਹੈ ✔

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

7. ਇੱਕ ਸਧਾਰਨ, ਉੱਚ-ਆਵਾਜ਼ ਵਰਗੀਕਰਣ ਕਾਰਜ ਲਈ ਆਮ ਤੌਰ 'ਤੇ ਸਭ ਤੋਂ ਵੱਧ ਲਾਗਤ-ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਪਹੁੰਚ ਕੀ ਹੈ?

  • ਏ) ਹਮੇਸ਼ਾ ਸਭ ਤੋਂ ਮਹਿੰਗੇ ਅਤੇ ਸਭ ਤੋਂ ਸ਼ਕਤੀਸ਼ਾਲੀ ਮਾਡਲ ਦੀ ਵਰਤੋਂ ਕਰੋ
  • ਅ) ਹਰੇਕ ਬੇਨਤੀ ਲਈ ਸਾਰੇ ਮਾਡਲਾਂ ਨੂੰ ਇੱਕੋ ਸਮੇਂ ਕਾਲ ਕਰਨਾ
  • C) ਸਭ ਤੋਂ ਹਲਕਾ/ਸਸਤਾ ਮਾਡਲ ਚੁਣਨਾ ਜੋ ਕੰਮ ਨੂੰ ਥੋੜ੍ਹੇ ਜਿਹੇ ਈਵਲ ਨਾਲ ਤਸਦੀਕ ਕਰਕੇ ਪੂਰਾ ਕਰਦਾ ਹੈ ✔
  • D) max_tokens ਮੁੱਲ ਨੂੰ ਬੇਲੋੜਾ ਬਹੁਤ ਜ਼ਿਆਦਾ ਰੱਖਣਾ

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

8. ਕਿਸ ਦ੍ਰਿਸ਼ ਵਿੱਚ ਪ੍ਰੋਂਪਟ ਕੈਚਿੰਗ ਸਭ ਤੋਂ ਵੱਧ ਲਾਗਤ ਨੂੰ ਘਟਾਉਂਦੀ ਹੈ?

  • A) ਜਦੋਂ ਬਹੁਤ ਸਾਰੀਆਂ ਬੇਨਤੀਆਂ ਵਿੱਚ ਇੱਕ ਵੱਡਾ ਅਤੇ ਸਥਿਰ ਸੰਦਰਭ ਵਾਰ-ਵਾਰ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ ✔
  • ਅ) ਜਦੋਂ ਹਰੇਕ ਬੇਨਤੀ ਦੇ ਨਾਲ ਇੱਕ ਪੂਰੀ ਤਰ੍ਹਾਂ ਵੱਖਰਾ ਟੈਕਸਟ ਭੇਜਿਆ ਜਾਂਦਾ ਹੈ
  • C) ਜਦੋਂ ਸਿਰਫ਼ ਇੱਕ ਹੀ ਬੇਨਤੀ ਕੀਤੀ ਜਾਂਦੀ ਹੈ
  • ਡੀ) ਆਉਟਪੁੱਟ ਟੋਕਨਾਂ ਨੂੰ ਘਟਾਉਣ ਲਈ

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

9. ਮੈਨੂੰ ਪ੍ਰੋਂਪਟ ਨੂੰ ਕਿਵੇਂ ਸੰਪਾਦਿਤ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ ਤਾਂ ਕਿ ਪ੍ਰੋਂਪਟ ਕੈਸ਼ ਹਿੱਟ ਹੋ ਜਾਵੇ?

  • ਏ) ਵੇਰੀਏਬਲ ਸਮਗਰੀ ਨੂੰ ਸ਼ੁਰੂ ਵਿੱਚ ਅਤੇ ਸਥਿਰ ਸਮੱਗਰੀ ਨੂੰ ਅੰਤ ਵਿੱਚ ਰੱਖਣਾ
  • ਅ) ਹਰੇਕ ਬੇਨਤੀ ਲਈ ਸਿਸਟਮ ਪ੍ਰੋਂਪਟ ਵਿੱਚ ਮੌਜੂਦਾ ਮਿਤੀ ਅਤੇ ਸਮਾਂ ਸ਼ਾਮਲ ਕਰੋ
  • C) ਸਥਿਰ ਸਮੱਗਰੀ (ਸਿਸਟਮ ਪ੍ਰੋਂਪਟ, ਦਸਤਾਵੇਜ਼) ਨੂੰ ਸ਼ੁਰੂ ਵਿੱਚ ਅਤੇ ਵੇਰੀਏਬਲ ਸਮੱਗਰੀ ਨੂੰ ਅੰਤ ਵਿੱਚ ਰੱਖਣਾ ✔
  • ਡੀ) ਹਰੇਕ ਬੇਨਤੀ ਦੇ ਨਾਲ ਟੂਲ ਸੂਚੀ ਦੇ ਕ੍ਰਮ ਨੂੰ ਬਦਲਣਾ

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

10. ਕਿਸ ਕਿਸਮ ਦੇ ਵਰਕਲੋਡ ਲਈ ਬੈਚ ਪ੍ਰੋਸੈਸਿੰਗ ਸਭ ਤੋਂ ਅਨੁਕੂਲ ਹੈ?

  • A) ਲਾਈਵ ਚੈਟ ਜਿੱਥੇ ਉਪਭੋਗਤਾ ਸਕ੍ਰੀਨ 'ਤੇ ਤੁਰੰਤ ਜਵਾਬ ਦੀ ਉਮੀਦ ਕਰਦਾ ਹੈ
  • ਅ) ਸਿਰਫ਼ ਇੱਕ ਛੋਟਾ ਸਵਾਲ
  • C) API ਕੁੰਜੀ ਬਣਾਉਣਾ
  • D) ਨੌਕਰੀਆਂ ਜੋ ਦੇਰੀ ਨੂੰ ਸਹਿਣ ਕਰਨ ਵਾਲੀਆਂ, ਵੱਡੀ ਮਾਤਰਾ ਵਿੱਚ ਹੁੰਦੀਆਂ ਹਨ ਅਤੇ ਤੁਰੰਤ ਨਤੀਜਿਆਂ ਦੀ ਲੋੜ ਨਹੀਂ ਹੁੰਦੀ ✔

ਵਰਣਨ: ਬੈਚ ਪ੍ਰੋਸੈਸਿੰਗ ਵੱਡੀਆਂ ਨੌਕਰੀਆਂ ਲਈ ਢੁਕਵੀਂ ਹੈ ਜਿਨ੍ਹਾਂ ਨੂੰ ਤੁਰੰਤ ਜਵਾਬ ਦੀ ਲੋੜ ਨਹੀਂ ਹੁੰਦੀ ਹੈ ਅਤੇ ਦੇਰੀ ਨੂੰ ਸਹਿਣਸ਼ੀਲ ਹੁੰਦਾ ਹੈ; ਨਤੀਜੇ ਕੁਝ ਸਮੇਂ ਬਾਅਦ ਦਿੱਤੇ ਜਾਂਦੇ ਹਨ, ਪਰ ਯੂਨਿਟ ਦੀ ਲਾਗਤ ਆਮ ਤੌਰ 'ਤੇ ਘੱਟ ਹੁੰਦੀ ਹੈ।

11. ਭਰੋਸੇ ਨਾਲ ਮੇਲ ਕਰਨ ਲਈ ਕੀ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ ਕਿ ਨਤੀਜੇ ਇੱਕ ਬੈਚ ਵਿੱਚ ਕਿਸ ਬੇਨਤੀ ਨਾਲ ਸਬੰਧਤ ਹਨ?

  • ਏ) ਬੇਨਤੀਆਂ ਦਾ ਆਰਡਰ (ਸਥਿਤੀ) ਭੇਜਣਾ
  • ਬੀ) ਜਵਾਬਾਂ ਦੀ ਲੰਬਾਈ
  • C) API ਕੁੰਜੀ ਦੇ ਆਖਰੀ 4 ਅੰਕ
  • D) ਹਰੇਕ ਬੇਨਤੀ ਨੂੰ ਦਿੱਤਾ ਗਿਆ ਇੱਕ ਵਿਲੱਖਣ ਕਸਟਮ_ਆਈਡੀ ✔

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

12. ਜਦੋਂ ਤੁਸੀਂ API ਤੋਂ 429 (ਦਰ ਦੀ ਸੀਮਾ) ਗਲਤੀ ਪ੍ਰਾਪਤ ਕਰਦੇ ਹੋ ਤਾਂ ਸਿਫਾਰਿਸ਼ ਕੀਤਾ ਵਿਹਾਰ ਕੀ ਹੁੰਦਾ ਹੈ?

  • ਏ) ਇੱਕੋ ਸਮੇਂ ਕਈ ਹੋਰ ਬੇਨਤੀਆਂ ਭੇਜ ਕੇ ਮਜਬੂਰ ਕਰਨਾ
  • ਅ) ਮੁੜ-ਕੋਸ਼ਿਸ਼ ਸਿਰਲੇਖ ਤੋਂ ਬਾਅਦ, ਘਾਤਕ ਬੈਕਆਫ ਦੇ ਨਾਲ ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ ਕਰਨਾ ✔
  • C) ਬੇਨਤੀ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਰੱਦ ਕਰੋ ਅਤੇ ਉਪਭੋਗਤਾ ਨੂੰ ਕਰੈਸ਼ ਵਜੋਂ ਗਲਤੀ ਦਿਖਾਓ
  • ਡੀ) API ਕੁੰਜੀ ਨੂੰ ਬਦਲਣਾ

ਵਿਆਖਿਆ: 429 ਇੱਕ ਮੁੜ ਕੋਸ਼ਿਸ਼ ਕਰਨ ਯੋਗ ਗਲਤੀ ਹੈ; ਮੁੜ-ਕੋਸ਼ਿਸ਼-ਬਾਅਦ ਸਿਰਲੇਖ ਦਾ ਆਦਰ ਕਰਦੇ ਹੋਏ, ਘਾਤਕ ਬੈਕਆਫ ਨਾਲ ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ ਕਰਨਾ ਸਹੀ ਪਹੁੰਚ ਹੈ। ਜ਼ਿਆਦਾਤਰ ਅਧਿਕਾਰਤ SDK ਇਹ ਆਪਣੇ ਆਪ ਕਰਦੇ ਹਨ।

13. ਹੇਠਾਂ ਦਿੱਤੇ HTTP ਗਲਤੀ ਕੋਡਾਂ ਵਿੱਚੋਂ ਕਿਹੜੇ ਨੂੰ ਆਮ ਤੌਰ 'ਤੇ ਮੁੜ ਕੋਸ਼ਿਸ਼ ਕਰਨ ਯੋਗ ਮੰਨਿਆ ਜਾਂਦਾ ਹੈ?

  • A) 400 (ਅਵੈਧ ਬੇਨਤੀ)
  • ਬੀ) 401 (ਪ੍ਰਮਾਣਿਕਤਾ ਗਲਤੀ)
  • C) 529 (ਸਰਵਰ ਓਵਰਲੋਡ) ✔
  • ਡੀ) 404 (ਨਹੀਂ ਮਿਲਿਆ)

ਵਿਆਖਿਆ: 429 (ਸਪੀਡ ਸੀਮਾ), 500 (ਸਰਵਰ ਗਲਤੀ) ਅਤੇ 529 (ਓਵਰਲੋਡ) ਅਸਥਾਈ ਤਰੁਟੀਆਂ ਹਨ ਅਤੇ ਬੈਕ ਆਫ ਕਰਕੇ ਮੁੜ ਕੋਸ਼ਿਸ਼ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ। 400 ਅਤੇ 401 ਵਰਗੀਆਂ ਗਲਤੀਆਂ ਬੇਨਤੀ/ਪਛਾਣ ਦੇ ਮੁੱਦੇ ਹਨ; ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ ਕਰਨ ਨਾਲ ਇਸਦਾ ਹੱਲ ਨਹੀਂ ਹੋਵੇਗਾ।

14. API ਕੁੰਜੀਆਂ ਦਾ ਪ੍ਰਬੰਧਨ ਕਰਨ ਲਈ ਹੇਠਾਂ ਦਿੱਤੇ ਵਿੱਚੋਂ ਕਿਹੜਾ ਸੁਰੱਖਿਅਤ ਤਰੀਕਾ ਹੈ?

  • ਏ) ਵਾਤਾਵਰਣ ਵੇਰੀਏਬਲ/ਲੁਕੇ ਹੋਏ ਮੈਨੇਜਰ ਵਿੱਚ ਸਟੋਰ ਕਰਨਾ, ਇਸਨੂੰ ਕੋਡ ਵਿੱਚ ਏਮਬੈਡ ਨਾ ਕਰਨਾ ਅਤੇ ਨਿਯਮਿਤ ਤੌਰ 'ਤੇ ਘੁੰਮਾਉਣਾ ✔
  • ਅ) ਕੁੰਜੀ ਨੂੰ ਸਿੱਧਾ ਸਰੋਤ ਕੋਡ ਵਿੱਚ ਲਿਖੋ ਅਤੇ ਇਸਨੂੰ ਰਿਪੋਜ਼ਟਰੀ ਵਿੱਚ ਭੇਜੋ
  • C) ਕਲਾਇੰਟ ਸਾਈਡ (ਬ੍ਰਾਊਜ਼ਰ) JavaScript ਵਿੱਚ ਕੁੰਜੀ ਪਾਉਣਾ
  • ਡੀ) ਈਮੇਲ ਰਾਹੀਂ ਪੂਰੀ ਟੀਮ ਨਾਲ ਇੱਕ ਸਿੰਗਲ ਕੁੰਜੀ ਸਾਂਝੀ ਕਰਨਾ

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

15. ਗੋਪਨੀਯਤਾ ਦੇ ਮਾਮਲੇ ਵਿੱਚ ਇੱਕ ਆਟੋਮੇਸ਼ਨ ਟੂਲ (n8n, Zapier, Make) ਦੇ ਨਾਲ LLM ਏਕੀਕਰਣ ਲਈ ਸਭ ਤੋਂ ਵਧੀਆ ਪਹੁੰਚ ਕੀ ਹੈ?

  • ਏ) ਮਾਡਲ ਨੂੰ ਸਾਰਾ ਕੱਚਾ ਡੇਟਾ ਭੇਜਣਾ, ਭਾਵੇਂ ਇਹ ਜ਼ਰੂਰੀ ਨਾ ਹੋਵੇ
  • ਅ) ਪ੍ਰਵਾਹ ਕਦਮ ਦੇ ਅੰਦਰ ਏਪੀਆਈ ਕੁੰਜੀ ਨੂੰ ਪਲੇਨ ਟੈਕਸਟ ਵਿੱਚ ਲਿਖਣਾ
  • C) ਸੰਵੇਦਨਸ਼ੀਲ ਡੇਟਾ ਨੂੰ ਛੋਟਾ ਕਰਨਾ ਅਤੇ ਮਾਸਕ ਕਰਨਾ ਅਤੇ ਕੁੰਜੀ ਨੂੰ ਗੁਪਤ ਪ੍ਰਮਾਣ ਪੱਤਰਾਂ ਵਜੋਂ ਸਟੋਰ ਕਰਨਾ ✔
  • ਡੀ) ਪ੍ਰਵਾਹ ਇਤਿਹਾਸ ਵਿੱਚ ਸਥਾਈ ਤੌਰ 'ਤੇ ਨਿੱਜੀ ਡੇਟਾ ਨੂੰ ਰੱਖਣਾ

ਵਰਣਨ: ਜਿਵੇਂ ਕਿ ਆਟੋਮੇਸ਼ਨ ਵਿੱਚ ਦਾਖਲ ਹੋਣ ਵਾਲਾ ਡੇਟਾ ਤੀਜੀ-ਧਿਰ ਪ੍ਰਣਾਲੀਆਂ ਅਤੇ ਮਾਡਲਾਂ ਵਿੱਚੋਂ ਲੰਘਦਾ ਹੈ, ਸੰਵੇਦਨਸ਼ੀਲ/ਨਿੱਜੀ ਡੇਟਾ ਨੂੰ ਘੱਟ ਤੋਂ ਘੱਟ, ਮਾਸਕ ਅਤੇ ਸਿਰਫ਼ ਲੋੜੀਂਦੇ ਖੇਤਰਾਂ ਨੂੰ ਭੇਜਣ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ; API ਕੁੰਜੀ ਨੂੰ ਟੂਲ ਦੇ ਅੰਦਰ ਗੁਪਤ ਪ੍ਰਮਾਣ ਪੱਤਰਾਂ ਵਜੋਂ ਵੀ ਸਟੋਰ ਕੀਤਾ ਜਾਂਦਾ ਹੈ।

16. ਇੱਕ ਐਲਐਲਐਮ ਅਧਾਰਤ ਉਤਪਾਦਨ ਵਿਸ਼ੇਸ਼ਤਾ ਵਿੱਚ ਆਉਟਪੁੱਟ ਦੀ ਪ੍ਰਮਾਣਿਕਤਾ ਕਿਉਂ ਲਾਜ਼ਮੀ ਹੈ?

  • ਏ) ਸਿਰਫ ਫਾਰਮੈਟਿੰਗ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ ਕਿਉਂਕਿ ਮਾਡਲ ਕਦੇ ਗਲਤੀ ਨਹੀਂ ਕਰਦਾ
  • ਅ) ਕਿਉਂਕਿ ਮਾਡਲ ਤਰਲ ਪੈਦਾ ਕਰ ਸਕਦਾ ਹੈ ਪਰ ਕਈ ਵਾਰ ਗਲਤ; ਸਕੀਮਾ/ਨਿਯਮ ਨੂੰ ਸਰੋਤ ਅਤੇ ਮਨੁੱਖੀ ਪ੍ਰਵਾਨਗੀ ਨਾਲ ਆਡਿਟ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ ✔
  • C) ਪ੍ਰਮਾਣਿਕਤਾ ਤੋਂ ਬਚਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿਉਂਕਿ ਇਹ ਸਿਰਫ ਲਾਗਤ ਵਧਾਉਂਦਾ ਹੈ
  • ਡੀ) ਤਸਦੀਕ ਸਿਰਫ ਟੋਕਨਾਂ ਦੀ ਗਿਣਤੀ ਨੂੰ ਘਟਾਉਣ ਲਈ ਹੈ

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