ਲਾਭ:
- ਦੱਸ ਸਕਦਾ ਹੈ ਕਿ ਸਟ੍ਰੀਮਿੰਗ ਕੀ ਹੈ, ਇਵੈਂਟ ਦੀਆਂ ਕਿਸਮਾਂ ਅਤੇ ਇਸਦੀ ਲੋੜ ਕਿਉਂ ਹੈ।
- max_tokens ਸਮਾਂ ਸਮਾਪਤੀ ਅਤੇ 128K ਲੰਬੇ ਆਉਟਪੁੱਟ ਸਬੰਧ ਨੂੰ ਸਮਝਦਾ ਹੈ
- ਵਰਕਲੋਡ ਦੇ ਅਨੁਸਾਰ ਸਟ੍ਰੀਮਿੰਗ ਅਤੇ ਗੈਰ-ਸਟ੍ਰੀਮਿੰਗ ਬੇਨਤੀਆਂ ਵਿਚਕਾਰ ਸਹੀ ਚੋਣ ਕਰ ਸਕਦਾ ਹੈ
ਤੁਸੀਂ ਦੇਖਿਆ ਹੋਵੇਗਾ ਕਿ ਇੱਕ ਚੈਟ ਇੰਟਰਫੇਸ ਵਿੱਚ, ਜਵਾਬ ਇੱਕ ਸ਼ਬਦ ਦੁਆਰਾ "ਟਾਈਪ" ਹੁੰਦਾ ਹੈ। ਇਹ ਕੋਈ ਦਿੱਖ ਫੁੱਲਣਾ ਨਹੀਂ ਹੈ; ਇਹ ਇੱਕ ਤਕਨੀਕ ਦਾ ਨਤੀਜਾ ਹੈ ਜਿਸਨੂੰ ਸਟ੍ਰੀਮਿੰਗ ਕਿਹਾ ਜਾਂਦਾ ਹੈ ਅਤੇ ਅਕਸਰ ਉਤਪਾਦਨ-ਗੁਣਵੱਤਾ LLM ਏਕੀਕਰਣ ਲਈ ਲਾਜ਼ਮੀ ਹੁੰਦਾ ਹੈ। ਇਸ ਇਕਾਈ ਵਿੱਚ, ਤੁਸੀਂ ਸਿੱਖੋਗੇ ਕਿ ਪ੍ਰਵਾਹ ਕੀ ਹੈ, ਇਸ ਵਿੱਚ ਕਿਹੜੀਆਂ ਘਟਨਾਵਾਂ ਸ਼ਾਮਲ ਹਨ, ਲੰਬੇ ਆਉਟਪੁੱਟ ਅਤੇ ਸਮਾਂ ਸਮਾਪਤੀ ਨਾਲ ਇਸਦਾ ਸਬੰਧ, ਅਤੇ ਪ੍ਰਵਾਹ ਦੀ ਵਰਤੋਂ ਕਦੋਂ ਕਰਨੀ ਹੈ ਅਤੇ ਕਦੋਂ ਨਹੀਂ। ਅਸੀਂ ਇੱਕ ਪੇਸ਼ੇਵਰ - ਲਾਈਵ ਸਹਾਇਕ, ਲੰਬੀ ਰਿਪੋਰਟ ਬਣਾਉਣ, ਬੈਚ ਪ੍ਰੋਸੈਸਿੰਗ ਦੇ ਅਸਲ ਕੰਮਾਂ ਦੁਆਰਾ ਵਿਸ਼ੇ ਨੂੰ ਕਵਰ ਕਰਾਂਗੇ।
ਪ੍ਰਵਾਹ ਕੀ ਹੈ?
ਇੱਕ ਗੈਰ-ਸਟ੍ਰੀਮਿੰਗ (ਸਿੰਕਰੋਨਸ) ਬੇਨਤੀ ਦੇ ਨਾਲ, ਤੁਸੀਂ ਉਦੋਂ ਤੱਕ ਉਡੀਕ ਕਰਦੇ ਹੋ ਜਦੋਂ ਤੱਕ ਮਾਡਲ ਪੂਰਾ ਜਵਾਬ ਨਹੀਂ ਦਿੰਦਾ; ਜਦੋਂ ਜਵਾਬ ਤਿਆਰ ਹੁੰਦਾ ਹੈ, ਇਹ ਇੱਕ ਟੁਕੜੇ ਵਿੱਚ ਆਉਂਦਾ ਹੈ। ਇੱਕ ਸਟ੍ਰੀਮਿੰਗ ਬੇਨਤੀ ਵਿੱਚ, ਸਰਵਰ ਪ੍ਰਤੀਕਿਰਿਆ ਨੂੰ ਟੁਕੜੇ ਦੁਆਰਾ ਭੇਜਦਾ ਹੈ ਜਿਵੇਂ ਕਿ ਮਾਡਲ ਤਿਆਰ ਕਰਦਾ ਹੈ। ਤਕਨੀਕੀ ਤੌਰ 'ਤੇ, ਇਹ ਸਰਵਰ ਦੁਆਰਾ ਭੇਜੇ ਗਏ ਇਵੈਂਟਸ (SSE — ਸਰਵਰ-ਭੇਜੇ ਗਏ ਇਵੈਂਟਸ, ਇੱਕ ਵਿਧੀ ਜਿਸ ਵਿੱਚ ਸਰਵਰ ਇੱਕ ਖੁੱਲੇ ਕਨੈਕਸ਼ਨ 'ਤੇ ਉਤਰਾਧਿਕਾਰ ਵਿੱਚ ਛੋਟੀਆਂ ਘਟਨਾਵਾਂ ਭੇਜਦਾ ਹੈ) ਨਾਲ ਕੀਤਾ ਜਾਂਦਾ ਹੈ।
ਉਪਭੋਗਤਾ ਅਨੁਭਵ ਵਿੱਚ ਅੰਤਰ ਸਪੱਸ਼ਟ ਹੋ ਜਾਂਦਾ ਹੈ: ਇੱਕ ਜਵਾਬ ਤੇ ਜੋ 8 ਸਕਿੰਟ ਲੈਂਦਾ ਹੈ, ਗੈਰ-ਸਟ੍ਰੀਮ ਉਪਭੋਗਤਾ 8 ਸਕਿੰਟਾਂ ਲਈ ਇੱਕ ਖਾਲੀ ਸਕ੍ਰੀਨ ਵੱਲ ਵੇਖਦਾ ਹੈ; ਸਟ੍ਰੀਮਿੰਗ ਉਪਭੋਗਤਾ ~ 0.5 ਸਕਿੰਟਾਂ ਵਿੱਚ ਪਹਿਲੇ ਸ਼ਬਦਾਂ ਨੂੰ ਦੇਖਦਾ ਹੈ ਅਤੇ ਟੈਕਸਟ ਵਹਿਣਾ ਸ਼ੁਰੂ ਹੋ ਜਾਂਦਾ ਹੈ। ਅਨੁਭਵੀ ਲੇਟੈਂਸੀ—ਉਪਯੋਗਕਰਤਾ ਦੁਆਰਾ ਮਹਿਸੂਸ ਕੀਤਾ ਗਿਆ ਇੰਤਜ਼ਾਰ—ਬਹੁਤ ਘੱਟ ਗਿਆ ਹੈ, ਜਦੋਂ ਕਿ ਕੁੱਲ ਸਮਾਂ ਬਦਲਿਆ ਨਹੀਂ ਹੈ।
ਇਵੈਂਟ ਪ੍ਰਵਾਹ ਦੀਆਂ ਕਿਸਮਾਂ
ਪ੍ਰਵਾਹ ਘਟਨਾਵਾਂ ਦਾ ਇੱਕ ਕ੍ਰਮ ਹੈ। ਸੰਕਲਪ ਅਨੁਸਾਰ, ਇੱਕ ਆਮ ਵਹਾਅ ਇਸ ਤਰ੍ਹਾਂ ਚਲਦਾ ਹੈ:
ਘਟਨਾ
ਭਾਵ
ਸੁਨੇਹਾ_ਸ਼ੁਰੂ ਕਰੋ
ਹੁੰਗਾਰਾ ਸ਼ੁਰੂ ਹੋਇਆ; ਸਿਰਲੇਖ ਦੀ ਜਾਣਕਾਰੀ ਜਿਵੇਂ ਕਿ ਮਾਡਲ ਅਤੇ ID ਆ ਗਈ ਹੈ।
ਸਮੱਗਰੀ_ਬਲਾਕ_ਸ਼ੁਰੂ
ਸਮੱਗਰੀ ਦਾ ਇੱਕ ਬਲਾਕ (ਉਦਾਹਰਨ ਲਈ ਟੈਕਸਟ) ਸ਼ੁਰੂ ਹੋਇਆ
ਸਮੱਗਰੀ_ਬਲਾਕ_ਡੈਲਟਾ
ਟੈਕਸਟ ਦਾ ਇੱਕ ਛੋਟਾ ਜਿਹਾ ਟੁਕੜਾ (ਡੈਲਟਾ) ਆ ਗਿਆ; ਤੁਸੀਂ ਇਹਨਾਂ ਨੂੰ ਇਕੱਠਾ ਕਰੋ
ਸਮੱਗਰੀ_ਬਲਾਕ_ਸਟਾਪ
ਬਲਾਕ ਪੂਰਾ ਹੋਇਆ
ਸੁਨੇਹਾ_ਡੈਲਟਾ
ਅੱਪਡੇਟ ਕੀਤੀ ਸਮਾਪਤੀ ਜਾਣਕਾਰੀ ਜਿਵੇਂ ਕਿ stop_reason ਅਤੇ ਵਰਤੋਂ
ਸੁਨੇਹਾ_ਬੰਦ ਕਰੋ
ਜਵਾਬ ਦਿਓ
ਤੁਹਾਡਾ ਕੋਡ ਕ੍ਰਮਵਾਰ content_block_delta ਇਵੈਂਟਸ ਵਿੱਚ ਟੈਕਸਟ ਦੇ ਟੁਕੜਿਆਂ ਨੂੰ ਜੋੜਦਾ ਹੈ; ਤੁਸੀਂ ਗੈਰ-ਸਟ੍ਰੀਮ ਕੀਤੇ ਜਵਾਬ ਦੇ ਸਮਾਨ ਸਹੀ ਟੈਕਸਟ ਨਾਲ ਖਤਮ ਹੁੰਦੇ ਹੋ। ਵਰਤੋਂ (ਟੋਕਨ ਨੰਬਰ) ਆਮ ਤੌਰ 'ਤੇ ਵਹਾਅ ਦੇ ਅੰਤ 'ਤੇ ਸਪੱਸ਼ਟ ਹੁੰਦੇ ਹਨ - ਤੁਸੀਂ ਪ੍ਰਵਾਹ ਦੇ ਖਤਮ ਹੋਣ ਤੋਂ ਬਾਅਦ ਲਾਗਤਾਂ ਦਾ ਧਿਆਨ ਰੱਖਦੇ ਹੋ।
ਸੁਝਾਅ: ਜ਼ਿਆਦਾਤਰ ਅਧਿਕਾਰਤ SDKs (ਸਾਫਟਵੇਅਰ ਡਿਵੈਲਪਮੈਂਟ ਕਿੱਟ — ਪ੍ਰਦਾਤਾ ਦੀ ਤਿਆਰ ਲਾਇਬ੍ਰੇਰੀ) ਇੱਕ ਸਹਾਇਕ ਪ੍ਰਦਾਨ ਕਰਦੇ ਹਨ ਜੋ ਤੁਹਾਡੇ ਲਈ ਸਟ੍ਰੀਮ ਨੂੰ ਇਕੱਠਾ ਕਰਦਾ ਹੈ (ਉਦਾਹਰਨ ਲਈ stream.get_final_message())। ਤੁਹਾਨੂੰ ਸਾਰੇ ਟਰੈਕਾਂ ਨੂੰ ਹੱਥੀਂ ਪ੍ਰਬੰਧਿਤ ਕਰਨ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ; ਇਸ ਸਹਾਇਕ ਦੀ ਵਰਤੋਂ ਕਰੋ ਜੇਕਰ ਤੁਸੀਂ ਪੂਰਾ ਟੈਕਸਟ ਚਾਹੁੰਦੇ ਹੋ, ਵਿਅਕਤੀਗਤ ਸਮਾਗਮਾਂ ਦੀ ਪ੍ਰਕਿਰਿਆ ਕਰੋ ਪਰ ਲਾਈਵ ਪ੍ਰਿੰਟਿੰਗ ਲਈ।
ਲੰਬੇ ਜਵਾਬ, ਅਧਿਕਤਮ_ਟੋਕਨ ਅਤੇ ਸਮਾਂ ਸਮਾਪਤ
ਸਟ੍ਰੀਮਿੰਗ ਦਾ ਦੂਜਾ ਅਤੇ ਹੋਰ ਤਕਨੀਕੀ ਕਾਰਨ ਸਮਾਂ ਸਮਾਪਤ ਹੈ। ਜੇਕਰ ਇੱਕ HTTP ਬੇਨਤੀ ਇੱਕ ਨਿਸ਼ਚਿਤ ਸਮੇਂ ਦੇ ਅੰਦਰ ਪੂਰੀ ਨਹੀਂ ਹੁੰਦੀ ਹੈ, ਤਾਂ ਕਲਾਇੰਟ ਕੁਨੈਕਸ਼ਨ ਛੱਡ ਦਿੰਦਾ ਹੈ। ਜਦੋਂ ਤੁਸੀਂ ਮਾਡਲ ਤੋਂ ਇੱਕ ਵੱਡੇ ਆਉਟਪੁੱਟ ਦੀ ਬੇਨਤੀ ਕਰਦੇ ਹੋ (ਜਿਵੇਂ ਕਿ 40,000 ਟੋਕਨਾਂ ਦੀ ਰਿਪੋਰਟ), ਗੈਰ-ਪ੍ਰਵਾਹ ਕਾਲ ਇਸ ਸੀਮਾ ਤੋਂ ਵੱਧ ਸਕਦੀ ਹੈ ਅਤੇ ਸਮਾਂ ਸਮਾਪਤ ਹੋ ਸਕਦਾ ਹੈ — ਬੇਨਤੀ ਅਸਫਲ ਹੋ ਜਾਵੇਗੀ, ਅਤੇ ਤੁਹਾਨੂੰ ਤਿਆਰ ਕੀਤੇ ਟੋਕਨਾਂ ਲਈ ਭੁਗਤਾਨ ਕਰਨਾ ਪਵੇਗਾ।
ਆਧੁਨਿਕ ਮਾਡਲ ਇੱਕ ਬੇਨਤੀ ਵਿੱਚ 128,000 ਟੋਕਨਾਂ ਤੱਕ ਆਉਟਪੁੱਟ ਕਰ ਸਕਦੇ ਹਨ। ਪਰ ਅੰਗੂਠੇ ਦਾ ਨਿਯਮ ਸਪੱਸ਼ਟ ਹੈ: ਸਟ੍ਰੀਮ ਦੀ ਵਰਤੋਂ ਕਰੋ ਜੇਕਰ `ਮੈਕਸ_ਟੋਕਨ` ਮੁੱਲ ਉੱਚਾ ਹੈ (ਲਗਭਗ 16,000 ਤੋਂ ਵੱਧ)। ਸਟ੍ਰੀਮਿੰਗ ਕੁਨੈਕਸ਼ਨ ਨੂੰ ਜਿਉਂਦਾ ਰੱਖਦੀ ਹੈ ਅਤੇ ਸਮਾਂ ਸਮਾਪਤ ਹੋਣ ਤੋਂ ਰੋਕਦੀ ਹੈ; ਤੁਸੀਂ ਤੁਰੰਤ ਤਰੱਕੀ ਵੀ ਦੇਖੋਗੇ।
- `max_tokens`: ਅਧਿਕਤਮ ਆਉਟਪੁੱਟ ਟੋਕਨ ਜੋ ਮਾਡਲ ਪੈਦਾ ਕਰ ਸਕਦਾ ਹੈ; ਇੱਕ ਸਖ਼ਤ ਛੱਤ. ਜੇਕਰ ਕੋਈ ਰੁਕਾਵਟ ਆਉਂਦੀ ਹੈ, ਤਾਂ stop_reason max_tokens ਵਾਪਸ ਕੀਤੇ ਜਾਂਦੇ ਹਨ।
- ਸੰਦਰਭ ਵਿੰਡੋ: ਉਹ ਵਿੰਡੋ ਜਿਸ ਵਿੱਚ ਇਨਪੁਟ + ਆਉਟਪੁੱਟ ਦਾ ਜੋੜ ਫਿੱਟ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। max_tokens ਆਉਟਪੁੱਟ ਦੀ ਛੱਤ ਹੈ; ਦੋਵਾਂ ਨੂੰ ਨਾ ਮਿਲਾਓ।
ਸਾਵਧਾਨ: ਵੱਡੇ ਮੈਕਸ_ਟੋਕਨਾਂ ਨਾਲ ਗੈਰ-ਪ੍ਰਵਾਹ ਬੇਨਤੀਆਂ ਨੂੰ ਸੁੱਟਣਾ ਉਤਪਾਦਨ ਵਿੱਚ ਇੱਕ ਸ਼ਾਨਦਾਰ ਗਲਤੀ ਹੈ। ਜਵਾਬ ਦੇ ਬਿਨਾਂ, ਕੁਨੈਕਸ਼ਨ ਘੱਟ ਜਾਂਦਾ ਹੈ, ਉਪਭੋਗਤਾ ਇੱਕ ਗਲਤੀ ਵੇਖਦਾ ਹੈ, ਅਤੇ ਟੋਕਨ ਦੀ ਕੀਮਤ ਬਰਬਾਦ ਹੋ ਜਾਂਦੀ ਹੈ। ਲੰਬੀ ਆਉਟਪੁੱਟ = ਧਾਰਾ।
ਕਦੋਂ ਵਹਿਣਾ ਹੈ ਅਤੇ ਕਦੋਂ ਨਹੀਂ?
ਸਥਿਤੀ
ਤਰਜੀਹ
ਕਿਉਂ
ਲਾਈਵ ਚੈਟ / ਸਹਾਇਕ
ਵਹਾਅ
ਲੇਟੈਂਸੀ ਵਿੱਚ ਕਮੀ ਆਈ, ਉਪਭੋਗਤਾ ਪ੍ਰਗਤੀ ਦੇਖਦਾ ਹੈ
ਲੰਬੀ ਰਿਪੋਰਟ / ਦਸਤਾਵੇਜ਼ ਉਤਪਾਦਨ
ਵਹਾਅ
ਸਮਾਂ ਸਮਾਪਤ ਹੋਣ ਤੋਂ ਰੋਕਦਾ ਹੈ, ਵੱਡੇ ਆਉਟਪੁੱਟ ਨੂੰ ਸੁਰੱਖਿਅਤ ਢੰਗ ਨਾਲ ਚੁੱਕਦਾ ਹੈ
ਛੋਟਾ ਵਰਗੀਕਰਨ (ਜਿਵੇਂ ਕਿ ਸਿੰਗਲ ਸ਼ਬਦ ਟੈਗ)
ਕੋਈ ਪ੍ਰਵਾਹ ਨਹੀਂ
ਆਉਟਪੁੱਟ ਪਹਿਲਾਂ ਹੀ ਛੋਟਾ ਹੈ; ਵਾਧੂ ਜਟਿਲਤਾ ਬੇਲੋੜੀ
ਬੈਚ ਪ੍ਰੋਸੈਸਿੰਗ
ਪ੍ਰਵਾਹ ਰਹਿਤ/ਬੈਚ
ਨਤੀਜੇ ਤੁਰੰਤ ਨਹੀਂ ਦਿਖਾਏ ਜਾਂਦੇ ਹਨ; ਯੂਨਿਟ 7 ਦੇਖੋ
ਆਟੋਮੇਸ਼ਨ ਕਦਮ (ਬੈਕਗ੍ਰਾਉਂਡ ਵਿੱਚ)
ਆਮ ਤੌਰ 'ਤੇ ਕੋਈ ਪ੍ਰਵਾਹ ਨਹੀਂ ਹੁੰਦਾ
ਤੁਸੀਂ ਨਤੀਜੇ ਨੂੰ ਅਗਲੇ ਪੜਾਅ 'ਤੇ ਪਾਸ ਕਰਦੇ ਹੋ, ਕੋਈ ਲਾਈਵ ਡਿਸਪਲੇ ਨਹੀਂ
ਕਾਪੀ ਕਰਨ ਯੋਗ ਪ੍ਰੋਂਪਟ/ਟੈਂਪਲੇਟ
ਸਟ੍ਰੀਮ ਆਪਣੇ ਆਪ ਵਿੱਚ ਇੱਕ ਪ੍ਰੋਂਪਟ ਨਹੀਂ ਹੈ, ਪਰ ਸਟ੍ਰੀਮ ਦੁਆਰਾ ਪੈਦਾ ਕੀਤੇ ਆਉਟਪੁੱਟ ਦੇ ਪ੍ਰਬੰਧਨ ਲਈ ਪ੍ਰੋਂਪਟ ਮਹੱਤਵਪੂਰਨ ਹਨ। ਲੰਬੇ ਅਤੇ ਪ੍ਰਵਾਹਿਤ ਉਤਪਾਦਨਾਂ ਵਿੱਚ, ਫਰੰਟ ਤੋਂ ਬਣਤਰ ਨੂੰ ਲਾਗੂ ਕਰਨ ਨਾਲ ਗੁਣਵੱਤਾ ਅਤੇ ਟਰੇਸੇਬਿਲਟੀ ਦੋਵਾਂ ਵਿੱਚ ਵਾਧਾ ਹੁੰਦਾ ਹੈ।
# ਲੰਬੀ ਰਿਪੋਰਟ ਨੂੰ ਭਾਗਾਂ ਵਿੱਚ ਵੰਡੋ (ਤਾਂ ਜੋ ਪ੍ਰਗਤੀ ਪ੍ਰਵਾਹ ਵਿੱਚ ਦਿਖਾਈ ਦੇਵੇ) ਇਸ ਸਹੀ ਕ੍ਰਮ ਵਿੱਚ, ਹੇਠਾਂ ਦਿੱਤੇ ਸਿਰਲੇਖਾਂ ਨਾਲ ਰਿਪੋਰਟ ਲਿਖੋ। ਹਰੇਕ ਸਿਰਲੇਖ ਨੂੰ '##' ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ:## ਸੰਖੇਪ## ਖੋਜ## ਸਿਫ਼ਾਰਸ਼ਾਂ## ਅਗਲੇ ਕਦਮ
# ਲੰਬੇ ਉਤਪਾਦਨ ਵਿੱਚ ਕਟੌਤੀ ਤੋਂ ਬਚਣ ਲਈ ਟੀਚਾ ਲੰਬਾਈ ਦਿਓ। ਕੁੱਲ ਪਾਠ ਲਗਭਗ 800 ਸ਼ਬਦਾਂ ਦਾ ਹੋਵੇਗਾ। ਭਾਗਾਂ ਨੂੰ ਸੰਤੁਲਿਤ ਰੱਖੋ; ਅੰਤ ਵਿੱਚ ਅੱਧਾ ਵਾਕ ਨਾ ਛੱਡੋ।
# ਸਟ੍ਰੀਮਿੰਗ ਸਹਾਇਕ ਲਈ ਤੁਰੰਤ ਪਹਿਲਾ ਵਾਕ ਦਿਓ। ਪਹਿਲਾਂ ਸਿੱਧਾ ਇੱਕ-ਵਾਕ ਦਾ ਜਵਾਬ ਦਿਓ, ਫਿਰ ਵਿਸਥਾਰ ਵਿੱਚ ਜਾਓ। ਇਸ ਲਈ ਉਪਭੋਗਤਾ ਉਡੀਕ ਕਰਦੇ ਹੋਏ ਤੁਰੰਤ ਨਤੀਜਾ ਵੇਖਦਾ ਹੈ।
# ਲੰਬੇ ਆਉਟਪੁੱਟ ਨੂੰ ਸਟ੍ਰਕਚਰਡ ਰੱਖੋ (ਤਾਂ ਕਿ ਇਸਨੂੰ ਬਾਅਦ ਵਿੱਚ ਪਾਰਸ ਕੀਤਾ ਜਾ ਸਕੇ) ਇਹਨਾਂ ਭਾਗਾਂ ਵਿੱਚ ਆਉਟਪੁੱਟ ਨੂੰ ਆਊਟਪੁੱਟ ਕਰੋ ਅਤੇ ਹਰੇਕ ਭਾਗ ਨੂੰ ਇੱਕ ਵੱਖਰੇ '###' ਸਿਰਲੇਖ ਨਾਲ ਚਿੰਨ੍ਹਿਤ ਕਰੋ ਤਾਂ ਜੋ ਮੈਂ ਇਸਨੂੰ ਪ੍ਰੋਗਰਾਮੇਟਿਕ ਤੌਰ 'ਤੇ ਪਾਰਸ ਕਰ ਸਕਾਂ: ### ਜਾਣ-ਪਛਾਣ ### ਬੌਡੀ ### ਸਰੋਤ
ਕਮਜ਼ੋਰ ਪ੍ਰੋਂਪਟ / ਮਜ਼ਬੂਤ ਪ੍ਰੋਂਪਟ (ਲੰਬਾ ਉਤਪਾਦਨ)
# WEAK ਇਸ ਵਿਸ਼ੇ 'ਤੇ ਇੱਕ ਲੰਮੀ ਅਤੇ ਵਿਸਤ੍ਰਿਤ ਰਿਪੋਰਟ ਲਿਖੋ।
# STRONGਇਸ ਵਿਸ਼ੇ 'ਤੇ ਲਗਭਗ 900 ਸ਼ਬਦਾਂ ਦੀ ਰਿਪੋਰਟ ਲਿਖੋ। ਸਿਰਲੇਖ: ## ਸੰਖੇਪ, ## ਵਿਸ਼ਲੇਸ਼ਣ, ## ਜੋਖਮ, ## ਸਿਫ਼ਾਰਿਸ਼ਾਂ। ਹਰੇਕ ਸਿਰਲੇਖ ਵੱਧ ਤੋਂ ਵੱਧ 3 ਪੈਰੇ ਦਾ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਅੰਤ ਵਿੱਚ ਅੱਧਾ ਵਾਕ ਨਾ ਛੱਡੋ।
ਸ਼ਕਤੀਸ਼ਾਲੀ ਸੰਸਕਰਣ; ਇਹ ਲੰਬਾਈ, ਬਣਤਰ ਅਤੇ ਮੁਕੰਮਲ ਗੁਣਵੱਤਾ ਪਹਿਲਾਂ ਤੋਂ ਨਿਰਧਾਰਤ ਕਰਦਾ ਹੈ। ਜਿਵੇਂ ਕਿ ਭਾਗ ਪ੍ਰਵਾਹ ਵਿੱਚ ਆਉਂਦੇ ਹਨ, ਉਪਭੋਗਤਾ ਪ੍ਰਗਤੀ ਨੂੰ ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ ਦੇਖਦਾ ਹੈ ਅਤੇ ਮਾਡਲ ਰੁਕਾਵਟ ਦੇ ਜੋਖਮ ਦੇ ਵਿਰੁੱਧ ਲੰਬਾਈ ਦਾ ਪ੍ਰਬੰਧਨ ਕਰਦਾ ਹੈ।
ਤਿੰਨ ਮਿੰਨੀ ਕੇਸ
ਕੇਸ 1 - ਖਾਲੀ ਸਕ੍ਰੀਨ ਸ਼ਿਕਾਇਤ। ਇੱਕ ਸਲਾਹਕਾਰ ਟੀਮ ਦਾ ਗਾਹਕ ਸਹਾਇਕ ਬਿਨਾਂ ਵਹਾਅ ਦੇ ਜਵਾਬ ਦੇ ਰਿਹਾ ਸੀ; ਔਸਤ ਜਵਾਬ 7 ਸਕਿੰਟ ਲੈਂਦਾ ਹੈ, ਉਪਭੋਗਤਾ ਪੁੱਛਦੇ ਹਨ "ਕੀ ਇਹ ਜੰਮ ਜਾਂਦਾ ਹੈ?" ਉਸ ਨੇ ਸ਼ਿਕਾਇਤ ਕੀਤੀ। ਇੱਕ ਵਾਰ ਜਦੋਂ ਮੈਂ ਪ੍ਰਵਾਹ ਵਿੱਚ ਆ ਗਿਆ, ਪਹਿਲਾ ਸ਼ਬਦ ~ 0.6 ਸਕਿੰਟਾਂ ਵਿੱਚ ਆਇਆ; ਕੁੱਲ ਸਮਾਂ ਇੱਕੋ ਜਿਹਾ ਰਿਹਾ, ਪਰ "ਹੌਲੀ" ਸ਼ਿਕਾਇਤਾਂ ਲਗਭਗ ਅਲੋਪ ਹੋ ਗਈਆਂ.
ਕੇਸ 2 - ਪੁਰਾਣੀ ਰਿਪੋਰਟ। ਇੱਕ ਵਿੱਤ ਟੀਮ 30 ਪੰਨਿਆਂ ਦੀ ਤਿਮਾਹੀ ਰਿਪੋਰਟ ਤਿਆਰ ਕਰ ਰਹੀ ਸੀ; max_tokens: 30000 ਦੇ ਨਾਲ, ਨੋ-ਫਲੋ ਬੇਨਤੀ 60-ਸਕਿੰਟ ਦੇ ਕਲਾਇੰਟ ਟਾਈਮਆਉਟ ਵਿੱਚ ਫਸ ਜਾਵੇਗੀ, ਬੇਨਤੀ ਅਸਫਲ ਹੋ ਜਾਵੇਗੀ — ਅਤੇ ਤਿਆਰ ਕੀਤੇ ਟੋਕਨਾਂ ਨੂੰ ਇਨਵੌਇਸ ਵਿੱਚ ਲਿਖਿਆ ਜਾਵੇਗਾ। ਉਹ ਵਹਾਅ ਦੇ ਨਾਲ ਚਲੇ ਗਏ; ਕੁਨੈਕਸ਼ਨ ਲਾਈਵ ਰਿਹਾ, ਰਿਪੋਰਟ ਪੂਰੀ ਤਰ੍ਹਾਂ ਡਿਲੀਵਰ ਕੀਤੀ ਗਈ ਸੀ, ਅਤੇ ਬਰਬਾਦ ਖਰਚੇ ਖਤਮ ਹੋ ਗਏ ਸਨ।
ਕੇਸ 3 - ਬੇਲੋੜਾ ਵਹਾਅ। ਇੱਕ ਓਪਰੇਸ਼ਨ ਟੀਮ ਆਉਣ ਵਾਲੀਆਂ ਈਮੇਲਾਂ ਨੂੰ "ਜ਼ਰੂਰੀ/ਰੈਗੂਲਰ" ਵਜੋਂ ਲੇਬਲ ਕਰ ਰਹੀ ਸੀ; ਆਉਟਪੁੱਟ ਇੱਕ ਸ਼ਬਦ ਸੀ, ਪਰ ਉਹ ਆਦਤਨ ਪ੍ਰਵਾਹ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਸਨ। ਪ੍ਰਵਾਹ ਨੇ ਇੱਕ-ਸ਼ਬਦ ਦੇ ਜਵਾਬ ਵਿੱਚ ਕੋਈ ਲਾਭ ਨਹੀਂ ਦਿੱਤਾ, ਕੋਡ ਨੂੰ ਬੇਲੋੜਾ ਗੁੰਝਲਦਾਰ ਬਣਾ ਦਿੱਤਾ। ਜਦੋਂ ਮੈਂ ਪ੍ਰਵਾਹ ਰਹਿਤ ਤੇ ਸਵਿਚ ਕੀਤਾ, ਕੋਡ ਸਰਲ ਹੋ ਗਿਆ ਅਤੇ ਵਿਵਹਾਰ ਉਹੀ ਰਿਹਾ। ਸਬਕ: ਸਟ੍ਰੀਮਿੰਗ ਲੰਬੇ/ਲਾਈਵ ਆਉਟਪੁੱਟ ਵਿੱਚ ਕੀਮਤੀ ਹੈ, ਹਰ ਜਗ੍ਹਾ ਨਹੀਂ।
ਆਮ ਗਲਤੀਆਂ
- ਲੰਬੇ ਆਉਟਪੁੱਟ ਵਿੱਚ ਸਟ੍ਰੀਮਾਂ ਦੀ ਵਰਤੋਂ ਨਹੀਂ ਕਰਨਾ: ਸਮਾਂ ਸਮਾਪਤ ਅਤੇ ਬਰਬਾਦ ਟੋਕਨ ਦੀ ਲਾਗਤ।
- ਛੋਟੇ ਆਉਟਪੁੱਟ ਵਿੱਚ ਸਟ੍ਰੀਮਿੰਗ ਦੀ ਵਰਤੋਂ ਕਰਨਾ: ਬੇਲੋੜੀ ਜਟਿਲਤਾ, ਜ਼ੀਰੋ ਲਾਭ।
- ਸਟ੍ਰੀਮ ਦੇ ਅੰਤ ਵਿੱਚ `ਸਟੌਪ_ਕਾਰਨ` ਦੀ ਜਾਂਚ ਨਹੀਂ ਕੀਤੀ ਜਾ ਰਹੀ ਹੈ: ਅਧਿਕਤਮ_ਟੋਕਨਾਂ ਦੇ ਨਾਲ ਕੱਟੇ ਹੋਏ ਜਵਾਬ ਨੂੰ ਪੂਰਾ ਮੰਨਿਆ ਜਾਂਦਾ ਹੈ।
- ਡੈਲਟਾ ਨੂੰ ਗਲਤ ਢੰਗ ਨਾਲ ਮਿਲਾਉਣਾ: SDK ਸਹਾਇਕ ਦੇ ਨਾਲ ਮੈਨੂਅਲ ਸਮਾਲਟ ਕ੍ਰਮ/ਗੁੰਮ ਹੋਏ ਭਾਗਾਂ ਦੀ ਗੜਬੜ ਪੈਦਾ ਕਰਦਾ ਹੈ।
- `ਵਰਤੋਂ` ਮੱਧ-ਸਟ੍ਰੀਮ ਨੂੰ ਪੜ੍ਹਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਨਾ: ਟੋਕਨ ਨੰਬਰ ਆਮ ਤੌਰ 'ਤੇ ਅੰਤ ਵਿੱਚ ਸਪੱਸ਼ਟ ਹੋ ਜਾਂਦੇ ਹਨ; ਅੰਤ ਵਿੱਚ ਖਰਚਿਆਂ ਦਾ ਧਿਆਨ ਰੱਖੋ।
- ਲਾਗਤ ਵਿੱਚ ਕਟੌਤੀ ਲਈ ਸਟ੍ਰੀਮਿੰਗ ਦੀ ਗਲਤੀ: ਸਟ੍ਰੀਮਿੰਗ ਅਨੁਭਵ ਅਤੇ ਸਹਿਣਸ਼ੀਲਤਾ ਵਿੱਚ ਸੁਧਾਰ ਕਰਦੀ ਹੈ; ਇਹ ਟੋਕਨ ਕੀਮਤ ਨੂੰ ਨਹੀਂ ਬਦਲਦਾ।
ਡੂੰਘਾ: ਵਹਾਅ ਬਰੇਕ ਅਤੇ ਲਚਕੀਲੇਪਨ
ਸਟ੍ਰੀਮਿੰਗ ਇੱਕ ਲਾਈਵ ਕਨੈਕਸ਼ਨ ਹੈ; ਇਹ ਇਸਦੀ ਤਾਕਤ ਅਤੇ ਕਮਜ਼ੋਰੀ ਦੋਵੇਂ ਹੈ। ਜੇਕਰ ਕੁਨੈਕਸ਼ਨ ਮੱਧ ਵਿੱਚ ਘੱਟ ਜਾਂਦਾ ਹੈ (ਨੈੱਟਵਰਕ ਉਤਰਾਅ-ਚੜ੍ਹਾਅ, ਕਲਾਇੰਟ ਟਾਈਮਆਉਟ), ਤਾਂ ਤੁਸੀਂ ਉਸ ਟੈਕਸਟ ਨੂੰ ਬਰਕਰਾਰ ਰੱਖੋਗੇ ਜੋ ਤੁਸੀਂ ਹੁਣ ਤੱਕ ਇਕੱਠਾ ਕੀਤਾ ਹੈ, ਪਰ ਜਵਾਬ ਅਧੂਰਾ ਹੋਵੇਗਾ। ਇੱਕ ਉਤਪਾਦਨ-ਗੁਣਵੱਤਾ ਸਟ੍ਰੀਮਿੰਗ ਕਲਾਇੰਟ ਨੂੰ ਇਸਦੇ ਲਈ ਤਿਆਰ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ: ਇਸਨੂੰ ਅੰਸ਼ਕ ਪਾਠ ਨੂੰ "ਪੂਰਾ ਜਵਾਬ" ਦੇ ਰੂਪ ਵਿੱਚ ਨਹੀਂ ਮੰਨਿਆ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਨਾ ਹੀ ਇਸਨੂੰ ਜਵਾਬ ਨੂੰ ਖਤਮ ਕਰਨ ਲਈ ਵਿਚਾਰ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ ਜਦੋਂ ਤੱਕ ਇਹ ਸੁਨੇਹਾ_ਸਟੌਪ ਇਵੈਂਟ ਨਹੀਂ ਦੇਖਦਾ।
ਦੂਜੀ ਸੂਖਮਤਾ ਇਹ ਹੈ ਕਿ ਪ੍ਰਵਾਹ ਲਾਗਤ ਨੂੰ ਨਹੀਂ ਬਦਲਦਾ. ਭਾਵੇਂ ਤੁਸੀਂ ਸਟ੍ਰੀਮਿੰਗ ਦੇ ਨਾਲ ਜਾਂ ਬਿਨਾਂ ਜਵਾਬ ਪ੍ਰਾਪਤ ਕਰਦੇ ਹੋ, ਟੋਕਨ ਕੀਮਤ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਨਹੀਂ ਕਰਦਾ; ਵਹਾਅ ਸਿਰਫ਼ ਅਨੁਭਵ ਅਤੇ ਸਹਿਣਸ਼ੀਲਤਾ ਵਿੱਚ ਸੁਧਾਰ ਕਰਦਾ ਹੈ। ਇਸ ਲਈ "ਜੇ ਅਸੀਂ ਸਟ੍ਰੀਮਿੰਗ ਕਰਦੇ ਹਾਂ, ਤਾਂ ਕੀ ਉਹ ਸਸਤੇ ਹੋਣਗੇ?" ਸਵਾਲ ਦਾ ਜਵਾਬ ਨਹੀਂ ਹੈ — ਲਾਗਤ ਲਈ, 5ਵੀਂ ਅਤੇ 6ਵੀਂ ਇਕਾਈ (ਮਾਡਲ ਦੀ ਚੋਣ, ਕੈਸ਼) ਨੂੰ ਦੇਖੋ।
ਤੀਸਰਾ ਬਿੰਦੂ ਇੱਕ ਵਿਹਾਰਕ ਸੰਤੁਲਨ ਬਣਾਉਣਾ ਹੈ: ਲਾਈਵ ਸਹਾਇਕਾਂ ਦੇ ਨਾਲ, ਪਹਿਲੇ ਸ਼ਬਦ ਦੀ ਤੇਜ਼ੀ ਨਾਲ ਆਮਦ (ਦੇਰੀ ਸਮਝੀ ਜਾਂਦੀ ਹੈ) ਬਹੁਤ ਕੀਮਤੀ ਹੁੰਦੀ ਹੈ; ਇਸਲਈ, ਮਾਡਲ ਨੂੰ ਸਿੱਧਾ ਜਵਾਬ ਦਰਜ ਕਰਨ ਅਤੇ ਪਹਿਲਾਂ ਇੱਕ ਛੋਟਾ ਨਤੀਜਾ ਦੇਣ ਲਈ ਕਹਿਣਾ (4ਵੀਂ ਯੂਨਿਟ ਵਿੱਚ ਸਿਸਟਮ ਪ੍ਰੋਂਪਟ ਦੁਆਰਾ) ਪ੍ਰਵਾਹ ਦੇ ਲਾਭ ਨੂੰ ਗੁਣਾ ਕਰਦਾ ਹੈ। ਜੇਕਰ ਉਪਭੋਗਤਾ ਪਹਿਲੇ ਸਕਿੰਟ ਵਿੱਚ ਕੁਝ ਅਰਥਪੂਰਨ ਵੇਖਦਾ ਹੈ, ਤਾਂ ਉਹ ਅੱਗੇ ਦਿੱਤੇ ਵੇਰਵੇ ਲਈ ਧੀਰਜ ਨਾਲ ਉਡੀਕ ਕਰਦੇ ਹਨ। ਦੂਜੇ ਪਾਸੇ, ਬੈਕਗ੍ਰਾਉਂਡ ਵਿੱਚ ਚੱਲਣ ਵਾਲੀਆਂ ਨੌਕਰੀਆਂ ਵਿੱਚ ਪ੍ਰਵਾਹ ਦਾ ਕੋਈ ਯੋਗਦਾਨ ਨਹੀਂ ਹੈ, ਜਿਸਦਾ ਆਉਟਪੁੱਟ ਅਗਲੇ ਆਟੋਮੇਸ਼ਨ ਪੜਾਅ 'ਤੇ ਜਾਂਦਾ ਹੈ; ਉੱਥੇ ਸਿਰਫ ਇੱਕ ਮਾਪਦੰਡ ਇਹ ਹੈ ਕਿ ਕੰਮ ਨੂੰ ਸਹੀ ਅਤੇ ਪੂਰੀ ਤਰ੍ਹਾਂ ਪੂਰਾ ਕੀਤਾ ਗਿਆ ਹੈ.
ਸੰਖੇਪ ਵਿੱਚ
ਸਟ੍ਰੀਮਿੰਗ ਪ੍ਰਤੀਕਿਰਿਆ ਦੇ ਟੁਕੜੇ ਨੂੰ ਟੁਕੜੇ-ਟੁਕੜੇ ਤੋਂ ਪ੍ਰਾਪਤ ਕਰਦੀ ਹੈ, ਸਮਝੀ ਗਈ ਲੇਟੈਂਸੀ ਨੂੰ ਘਟਾਉਂਦੀ ਹੈ ਅਤੇ ਵੱਡੇ ਥ੍ਰੋਪੁੱਟਾਂ 'ਤੇ ਸਮਾਂ ਸਮਾਪਤ ਹੋਣ ਤੋਂ ਰੋਕਦੀ ਹੈ। ਲਾਈਵ ਸਹਾਇਕ ਅਤੇ ਲੰਬੇ ਦਸਤਾਵੇਜ਼ ਉਤਪਾਦਨ ਲਈ ਲਗਭਗ ਲਾਜ਼ਮੀ; ਇਹ ਛੋਟੇ/ਬੈਕਗਰਾਊਂਡ ਕੰਮ ਲਈ ਬੇਲੋੜਾ ਹੈ। ਲੰਬੇ ਪ੍ਰੋਡਕਸ਼ਨ ਵਿੱਚ, ਇੱਕ ਪ੍ਰੋਂਪਟ ਦੇ ਨਾਲ ਫਰੰਟ ਤੋਂ ਬਣਤਰ ਅਤੇ ਲੰਬਾਈ ਨੂੰ ਲਗਾਉਣਾ ਗੁਣਵੱਤਾ ਅਤੇ ਟਰੇਸੇਬਿਲਟੀ ਦੋਵਾਂ ਨੂੰ ਵਧਾਉਂਦਾ ਹੈ; ਜਦੋਂ ਪ੍ਰਵਾਹ ਪੂਰਾ ਹੋ ਜਾਂਦਾ ਹੈ, ਤਾਂ stop_reason ਅਤੇ ਵਰਤੋਂ ਦੀ ਨਿਸ਼ਚਤ ਤੌਰ 'ਤੇ ਜਾਂਚ ਕੀਤੀ ਜਾਂਦੀ ਹੈ।
ਐਪਲੀਕੇਸ਼ਨ ਦਾ ਕੰਮ
ਦੋ ਦ੍ਰਿਸ਼ ਚੁਣੋ: ਇੱਕ ਲਾਈਵ/ਲੰਬਾ (ਉਦਾਹਰਨ ਲਈ ਗਾਹਕ ਨੂੰ ਰਿਪੋਰਟ), ਇੱਕ ਛੋਟਾ/ਬੈਕਗ੍ਰਾਊਂਡ (ਉਦਾਹਰਨ ਲਈ ਟੈਗਿੰਗ)। (1) ਫੈਸਲਾ ਕਰੋ ਅਤੇ ਜਾਇਜ਼ ਠਹਿਰਾਓ ਕਿ ਕੀ ਤੁਸੀਂ ਹਰੇਕ ਲਈ ਪ੍ਰਵਾਹ ਦੀ ਵਰਤੋਂ ਕਰੋਗੇ। (2) ਇੱਕ ਪ੍ਰੋਂਪਟ ਲਿਖੋ ਜੋ ਲੰਬੀ ਸਕ੍ਰਿਪਟ (ਸਿਰਲੇਖ + ਟੀਚਾ ਲੰਬਾਈ) ਲਈ ਢਾਂਚਾ ਲਾਗੂ ਕਰਦਾ ਹੈ। (3) ਅਧਿਕਤਮ_ਟੋਕਨ ਮੁੱਲ ਨਿਰਧਾਰਤ ਕਰੋ। (4) ਸੂਚੀ ਬਣਾਓ ਕਿ ਤੁਸੀਂ ਸਟਾਪ_ਕਾਰਨ ਅਤੇ ਪ੍ਰਵਾਹ ਦੇ ਅੰਤ 'ਤੇ ਵਰਤੋਂ ਨਾਲ ਕਿਹੜੀਆਂ ਜਾਂਚਾਂ ਕਰੋਗੇ।
ਚੈੱਕਲਿਸਟ
- [ ] ਮੈਂ ਸਮਝਾ ਸਕਦਾ ਹਾਂ ਕਿ ਸਟ੍ਰੀਮਿੰਗ ਕੀ ਹੈ ਅਤੇ ਇਹ ਸਮਝੀ ਜਾਣ ਵਾਲੀ ਲੇਟੈਂਸੀ ਨੂੰ ਕਿਵੇਂ ਘਟਾਉਂਦੀ ਹੈ।
- [ ] ਮੈਂ ਸਟ੍ਰੀਮ ਅਤੇ ਡੈਲਟਾ ਜੁਆਇਨਿੰਗ ਦੀਆਂ ਬੁਨਿਆਦੀ ਇਵੈਂਟ ਕਿਸਮਾਂ ਨੂੰ ਸਮਝਿਆ।
- [ ] ਮੈਨੂੰ ਵੱਡੇ ਮੈਕਸ_ਟੋਕਨਾਂ ਨਾਲ ਸਟ੍ਰੀਮ ਕਰਨ ਦੀ ਲੋੜ ਅਤੇ ਸਮਾਂ ਸਮਾਪਤੀ ਸਬੰਧਾਂ ਬਾਰੇ ਪਤਾ ਹੈ।
- [ ] ਮੈਂ ਫੈਸਲਾ ਕਰ ਸਕਦਾ ਹਾਂ ਕਿ ਮੈਂ ਕਿਸ ਕੰਮ ਦੇ ਬੋਝ ਵਿੱਚ ਸਟ੍ਰੀਮਿੰਗ ਦੀ ਵਰਤੋਂ ਕਰਾਂਗਾ ਅਤੇ ਕਿਸ ਵਿੱਚ ਨਹੀਂ ਕਰਾਂਗਾ।
- [ ] ਮੈਂ ਸਟ੍ਰੀਮ ਦੇ ਅੰਤ ਵਿੱਚ stop_reason ਅਤੇ ਵਰਤੋਂ ਦੀ ਜਾਂਚ ਕਰ ਸਕਦਾ/ਸਕਦੀ ਹਾਂ।