ਲਾਗਤ ਅਨੁਕੂਲਨ: ਪ੍ਰੋਂਪਟ ਕੈਚਿੰਗ

ਲਾਭ:

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

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

ਕੈਸ਼ ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ? ਇੱਕ ਅਟੱਲ ਨਿਯਮ

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

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

ਪ੍ਰੋਸੈਸਿੰਗ ਆਰਡਰ ਆਮ ਤੌਰ 'ਤੇ ਹੁੰਦਾ ਹੈ: ਟੂਲ → ਸਿਸਟਮ ਪ੍ਰੋਂਪਟ → ਸੁਨੇਹੇ। ਤੁਸੀਂ ਨਿਸ਼ਚਿਤ ਭਾਗ ਦੇ ਅੰਤ ਵਿੱਚ ਕੈਸ਼ ਪੁਆਇੰਟ (ਬ੍ਰੇਕਪੁਆਇੰਟ) ਰੱਖਦੇ ਹੋ।

ਕੈਸ਼ ਆਰਥਿਕਤਾ

ਕੈਸ਼ ਦੇ ਤਿੰਨ ਮੁੱਲ ਪੱਧਰ ਹਨ:

• ਕੈਸ਼ ਲਿਖੋ: ਪਹਿਲੀ ਵਾਰ ਸਟੋਰ ਕਰਨਾ। ~1.25x ਆਮ ਇਨਪੁਟ ਕੀਮਤ (5 ਮਿੰਟ ਸਟੋਰੇਜ ਲਈ)।
• ਕੈਸ਼ ਰੀਡ: ਅਗਲੀਆਂ ਬੇਨਤੀਆਂ 'ਤੇ ਪੜ੍ਹਨਾ। ਆਮ ਇਨਪੁਟ ਕੀਮਤ ਦਾ ~0.1 ਗੁਣਾ — ਯਾਨੀ ਦਸਵਾਂ ਹਿੱਸਾ।
• ਆਮ ਇਨਪੁਟ: ਉਹ ਹਿੱਸਾ ਜੋ ਕੈਸ਼ ਵਿੱਚ ਦਾਖਲ ਨਹੀਂ ਹੁੰਦਾ ਅਤੇ ਹਰ ਵਾਰ ਪੂਰੀ ਕੀਮਤ 'ਤੇ ਪ੍ਰਕਿਰਿਆ ਕੀਤੀ ਜਾਂਦੀ ਹੈ।

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

ਦ੍ਰਿਸ਼

ਕੀ ਕੈਸ਼ ਕੰਮ ਕਰਦਾ ਹੈ?

ਵੱਡਾ ਸਥਿਰ ਸਿਸਟਮ ਪ੍ਰੋਂਪਟ, ਹਜ਼ਾਰਾਂ ਬੇਨਤੀਆਂ

ਹਾਂ — ਸਭ ਤੋਂ ਵੱਧ ਕਮਾਈਆਂ

ਇੱਕੋ ਹਵਾਲਾ ਦਸਤਾਵੇਜ਼ 'ਤੇ ਬਹੁਤ ਸਾਰੇ ਸਵਾਲ

ਹਾਂ

ਹਰੇਕ ਬੇਨਤੀ ਲਈ ਪੂਰੀ ਤਰ੍ਹਾਂ ਵੱਖਰਾ ਛੋਟਾ ਟੈਕਸਟ

ਨਹੀਂ — ਲਿਖਣ ਦਾ ਬੋਨਸ ਬਰਬਾਦ ਹੋ ਗਿਆ ਹੈ

ਇੱਕ ਵਾਰ ਬੇਨਤੀ

ਨਹੀਂ - ਬਿਲਕੁਲ ਨਹੀਂ ਪੜ੍ਹਨਾ

ਸਿਸਟਮ ਪ੍ਰੋਂਪਟ 'ਤੇ ਹਰੇਕ ਬੇਨਤੀ ਦੇ ਨਾਲ ਮਿਤੀ/ਆਈਡੀ ਬਦਲਣਾ

ਨਹੀਂ — ਅਗੇਤਰ ਟੁੱਟ ਗਿਆ ਹੈ, ਹਿੱਟ ਜ਼ੀਰੋ ਹੈ

ਕਦਮ ਦਰ ਕਦਮ: ਹਿੱਟ ਪ੍ਰੋਂਪਟ ਕਿਵੇਂ ਸੈਟ ਅਪ ਕਰੀਏ?

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

{ "ਸਿਸਟਮ": [ { "type": "text", "text": "{{large_constant_system_promptu_and_rules}}", "cache_control": { "type": "ephemeral" } } ], "messages": [ { "role": "user", "content" {current}}}"

ਸੰਕੇਤ: ਕੈਸ਼ ਹਿੱਟ ਦਾ ਅੰਦਾਜ਼ਾ ਨਾ ਲਗਾਓ, ਉਹਨਾਂ ਨੂੰ ਮਾਪੋ। ਜੇਕਰ ਲਗਾਤਾਰ ਬੇਨਤੀਆਂ 'ਤੇ usage.cache_read_input_tokens ਅਜੇ ਵੀ ਜ਼ੀਰੋ ਹੈ, ਤਾਂ ਇੱਕ ਸਾਈਲੈਂਟ ਬ੍ਰੇਕਰ (datetime.now() ਸਿਸਟਮ ਪ੍ਰੋਂਪਟ 'ਤੇ, ਬਿਨਾਂ ਕ੍ਰਮਬੱਧ JSON, ਹਰੇਕ ਬੇਨਤੀ ਨਾਲ ਬਦਲਣ ਵਾਲੇ ਟੂਲਸ ਦੀ ਸੂਚੀ) ਚੱਲ ਰਿਹਾ ਹੈ। ਦੋ ਬੇਨਤੀਆਂ ਦੇ ਕੱਚੇ ਪ੍ਰੋਂਪਟ ਦੀ ਬਾਈਟ ਦੁਆਰਾ ਬਾਈਟ ਦੀ ਤੁਲਨਾ ਕਰੋ ਅਤੇ ਅੰਤਰ ਲੱਭੋ।

ਚੁੱਪ ਵਿਘਨ ਪਾਉਣ ਵਾਲੇ

ਆਮ ਪੈਟਰਨ ਜੋ ਅਣਜਾਣੇ ਵਿੱਚ ਕੈਸ਼ ਨੂੰ ਭ੍ਰਿਸ਼ਟ ਕਰਦੇ ਹਨ:

# BREAKER: ਸਿਸਟਮ ਪ੍ਰੋਂਪਟ ਵਿੱਚ ਏਮਬੈਡਿੰਗ ਜਾਣਕਾਰੀ ਜੋ ਹਰੇਕ ਬੇਨਤੀ ਦੇ ਨਾਲ ਬਦਲਦੀ ਹੈ "ਅੱਜ ਦੀ ਮਿਤੀ: {{ਹੁਣ}}। ਤੁਸੀਂ ਇੱਕ ਸਹਾਇਕ ਹੋ..." ← ਹਰੇਕ ਬੇਨਤੀ ਦੇ ਨਾਲ ਅਗੇਤਰ ਬਦਲਦਾ ਹੈ, ਹਿੱਟ ਜ਼ੀਰੋ ਹੈ ..."}] ← ਅੰਤ ਵਿੱਚ ਵੇਰੀਏਬਲ

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

ਕਮਜ਼ੋਰ ਪ੍ਰੋਂਪਟ / ਮਜ਼ਬੂਤ ​​ਪ੍ਰੋਂਪਟ (ਕੈਸ਼ ਅਨੁਕੂਲ ਬਣਤਰ)

# ਕਮਜ਼ੋਰ (ਕੈਸ਼ ਬਸਟਿੰਗ ਬਿਲਡ) ਸਿਸਟਮ: "ਤਾਰੀਖ: 18.07.2026 14:32। ਉਪਭੋਗਤਾ: ਅਹਮੇਟ (ਆਈਡੀ 8842)। ਤੁਸੀਂ ਇੱਕ ਸਹਾਇਤਾ ਬੋਟ ਹੋ। ਨਿਯਮ: ...(2000 ਟੋਕਨ)..."

# STRONG (ਕੈਸ਼-ਅਨੁਕੂਲ ਢਾਂਚਾ) ਸਿਸਟਮ: "ਤੁਸੀਂ ਇੱਕ ਸਹਾਇਤਾ ਬੋਟ ਹੋ। ਨਿਯਮ: ...(2000 ਟੋਕਨ, ਕਦੇ ਨਹੀਂ ਬਦਲਦੇ)..." [ਕੈਸ਼ ਸਾਈਨ] ਸੁਨੇਹੇ: [ { ਭੂਮਿਕਾ: ਉਪਭੋਗਤਾ, ਸਮੱਗਰੀ: "ਤਾਰੀਖ: 18.07.2026 14:32. ਯੂਜ਼ਰ ਆਈਡੀ: 8842. ਸਵਾਲ: ਮੈਂ ਆਪਣੀ ਰਿਫੰਡ ਕਿਵੇਂ ਕਰਾਂ?" }]

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

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

ਕੇਸ 1 - ਨਿਯਮ ਪੁਸਤਕ ਨੂੰ ਕੈਸ਼ ਕਰਨਾ। ਇੱਕ ਅਕਾਊਂਟਿੰਗ ਆਟੋਮੇਸ਼ਨ ਹਰੇਕ ਇਨਵੌਇਸ ਵਿੱਚ 12,000 ਟੋਕਨ ਨਿਯਮਬੁੱਕ ਜੋੜ ਰਿਹਾ ਸੀ; ਪ੍ਰਤੀ ਦਿਨ 5,000 ਬੇਨਤੀਆਂ। ਕੈਸ਼ਲੈਸ ਇਨਪੁਟ ਦੀ ਲਾਗਤ ~$180 ਪ੍ਰਤੀ ਦਿਨ ਹੈ। ਉਹਨਾਂ ਨੇ ਨਿਯਮ ਪੁਸਤਕ ਨੂੰ ਸਥਿਰ ਰੱਖਿਆ ਅਤੇ ਇਸਨੂੰ ਕੈਸ਼ ਕੀਤਾ: ਪਹਿਲੀ ਬੇਨਤੀਆਂ ਨੇ ਇੱਕ ਰਾਈਟ ਪ੍ਰੀਮੀਅਮ ਦਾ ਭੁਗਤਾਨ ਕੀਤਾ, ਬਾਅਦ ਵਿੱਚ 0.1× ਪੜ੍ਹਿਆ। ਇਨਪੁਟ ਲਾਗਤ ~90% ਘਟ ਕੇ ~$18 ਪ੍ਰਤੀ ਦਿਨ ਹੋ ਗਈ।

ਕੇਸ 2 - ਲੁਕਵੀਂ ਮਿਤੀ ਲਾਈਨ ਦੀ ਲਾਗਤ। ਇੱਕ ਟੀਮ ਨੇ ਇੱਕ ਕੈਸ਼ ਸਥਾਪਤ ਕੀਤਾ ਪਰ ਕੋਈ ਹਿੱਟ ਨਹੀਂ ਮਿਲ ਰਿਹਾ ਸੀ; cache_read_input_tokens ਹਮੇਸ਼ਾ ਜ਼ੀਰੋ ਸੀ। ਕਾਰਨ: ਸਿਸਟਮ ਪ੍ਰੋਂਪਟ ਦੀ ਪਹਿਲੀ ਲਾਈਨ ਵਿੱਚ datetime.now() ਸੀ, ਹਰ ਬੇਨਤੀ ਦੇ ਨਾਲ ਅਗੇਤਰ ਬਦਲ ਰਿਹਾ ਸੀ। ਜਦੋਂ ਅਸੀਂ ਮਿਤੀ ਨੂੰ ਉਪਭੋਗਤਾ ਸੰਦੇਸ਼ ਵਿੱਚ ਤਬਦੀਲ ਕੀਤਾ, ਤਾਂ ਹਿੱਟ ਦਰ ਅਚਾਨਕ 0% ਤੋਂ 94% ਤੱਕ ਵਧ ਗਈ।

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

ਆਮ ਗਲਤੀਆਂ

• ਸਥਿਰ ਅਤੇ ਵੇਰੀਏਬਲ ਨੂੰ ਮਿਲਾਉਣਾ: ਜਦੋਂ ਵੇਰੀਏਬਲ ਸਮਗਰੀ ਅਗੇਤਰ ਵਿੱਚ ਹੁੰਦੀ ਹੈ, ਤਾਂ ਹਿੱਟ ਰੀਸੈਟ ਹੁੰਦੀ ਹੈ।
• ਸਿਸਟਮ ਪ੍ਰੋਂਪਟ ਵਿੱਚ ਏਮਬੈਡਿੰਗ ਮਿਤੀ/ਆਈਡੀ: ਸਭ ਤੋਂ ਆਮ ਚੁੱਪ ਵਿਘਨਕਾਰ।
• ਹਿੱਟ ਨੂੰ ਨਾ ਮਾਪਣਾ: ਜੇਕਰ ਕੈਸ਼_ਰੀਡ_ਇਨਪੁਟ_ਟੋਕਨਾਂ ਦੀ ਜਾਂਚ ਨਹੀਂ ਕੀਤੀ ਜਾਂਦੀ, ਤਾਂ ਰਹਿੰਦ-ਖੂੰਹਦ ਨੂੰ ਦੇਖਿਆ ਨਹੀਂ ਜਾਵੇਗਾ।
• ਕੋਈ ਜਨਤਕ ਅਗੇਤਰ ਨਾ ਹੋਣ 'ਤੇ ਕੈਸ਼ ਜੋੜਨਾ: ਤੁਸੀਂ ਸਿਰਫ਼ ਰਾਈਟ ਪ੍ਰੀਮੀਅਮ ਦਾ ਭੁਗਤਾਨ ਕਰਦੇ ਹੋ, ਲਾਗਤ ਵਧ ਜਾਂਦੀ ਹੈ।
• ਵਾਹਨ ਸੂਚੀ ਜਾਂ ਮਾਡਲ ਨੂੰ ਬਦਲਣਾ: ਅਗੇਤਰ ਸ਼ੁਰੂ ਤੋਂ ਟੁੱਟ ਗਿਆ ਹੈ; ਸਭ ਕੁਝ ਮੁੜ ਲਿਖਿਆ ਗਿਆ ਹੈ.
• ਨਿਊਨਤਮ ਕੈਸ਼ ਆਕਾਰ ਨੂੰ ਭੁੱਲਣਾ: ਬਹੁਤ ਛੋਟੇ ਕੈਚ (ਮਾਡਲ 'ਤੇ ਨਿਰਭਰ ਕਰਦੇ ਹੋਏ ~1–4k ਟੋਕਨਾਂ ਦੇ ਅਧੀਨ) ਚੁੱਪਚਾਪ ਕੈਸ਼ ਵਿੱਚ ਦਾਖਲ ਨਹੀਂ ਹੋਣਗੇ।

ਡੂੰਘਾ: ਵਰਕਲੋਡ ਦੀ ਕਿਸਮ ਦੁਆਰਾ ਕੈਸ਼ ਡਿਜ਼ਾਈਨ ਕਰਨਾ

ਕੈਚਿੰਗ ਦਾ ਅਸਲ ਭੁਗਤਾਨ ਤੁਹਾਡੇ ਕੰਮ ਦੇ ਬੋਝ ਦੀ ਪ੍ਰਕਿਰਤੀ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ; ਇਸ ਲਈ ਪਹਿਲਾਂ ਆਪਣੇ ਟ੍ਰੈਫਿਕ ਨੂੰ ਜਾਣੋ। ਤਿੰਨ ਆਮ ਪੈਟਰਨ ਅਤੇ ਸਹੀ ਇੰਸਟਾਲੇਸ਼ਨ:

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

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

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

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

ਸੰਖੇਪ ਵਿੱਚ

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

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

ਇੱਕ ਕੰਮ ਦਾ ਬੋਝ ਚੁਣੋ। (1) ਸਮੱਗਰੀ ਨੂੰ ਦੋ ਕਾਲਮਾਂ ਵਿੱਚ ਵੰਡੋ: "ਕਦੇ ਨਹੀਂ ਬਦਲਦਾ" ਅਤੇ "ਹਰ ਬੇਨਤੀ ਨਾਲ ਬਦਲਦਾ ਹੈ"। (2) ਪ੍ਰੋਂਪਟ ਬਣਤਰ ਨੂੰ ਮੁੜ ਖਿੱਚੋ, ਸਥਿਰ ਭਾਗ ਨੂੰ ਸ਼ੁਰੂ ਵਿੱਚ ਅਤੇ ਵੇਰੀਏਬਲ ਭਾਗ ਨੂੰ ਅੰਤ ਵਿੱਚ ਰੱਖੋ। (3) ਨਿਸ਼ਚਿਤ ਹਿੱਸੇ ਦੇ ਟੋਕਨ ਆਕਾਰ ਦਾ ਅੰਦਾਜ਼ਾ ਲਗਾਓ ਅਤੇ ਕੈਸ਼ ਦੇ ਨਾਲ/ਬਿਨਾਂ ਮਾਸਿਕ ਲਾਗਤ ਦੀ ਤੁਲਨਾ ਕਰੋ। (4) ਨੋਟ ਕਰੋ ਕਿ ਤੁਸੀਂ ਕਿਸ ਖੇਤਰ (cache_read_input_tokens) ਤੋਂ ਹਿੱਟ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋਗੇ।

ਚੈੱਕਲਿਸਟ

• [ ] ਮੈਂ ਸਮਝਾ ਸਕਦਾ ਹਾਂ ਕਿ ਕੈਸ਼ ਅਗੇਤਰ ਮੇਲ ਖਾਂਦਾ ਹੈ ਅਤੇ ਇਕੋ ਇਕ ਅਟੱਲ ਨਿਯਮ ਹੈ।
• [ ] ਮੈਂ ਸਥਿਰ ਸਮੱਗਰੀ ਨੂੰ ਸ਼ੁਰੂ ਵਿੱਚ ਅਤੇ ਵੇਰੀਏਬਲ ਨੂੰ ਅੰਤ ਵਿੱਚ ਰੱਖ ਕੇ ਸ਼ੁੱਧਤਾ ਵਧਾ ਸਕਦਾ ਹਾਂ।
• [ ] ਮੈਨੂੰ ਅਰਥ ਸ਼ਾਸਤਰ ਲਿਖਣਾ/ਪੜ੍ਹਨਾ ਅਤੇ ਦੋ-ਬੇਨਤੀ ਬਰੇਕ-ਈਵਨ ਪੁਆਇੰਟ ਪਤਾ ਹੈ।
• [ ] ਮੈਂ ਚੁੱਪ ਵਿਘਨ ਪਾਉਣ ਵਾਲਿਆਂ ਨੂੰ ਪਛਾਣ ਸਕਦਾ ਹਾਂ (ਤਾਰੀਖ, ਬਿਨਾਂ ਕ੍ਰਮਬੱਧ JSON, ਵਾਹਨ ਸੂਚੀ ਨੂੰ ਬਦਲਣਾ)।
• [ ] ਮੈਂ usage.cache_read_input_tokens ਨਾਲ ਹਿੱਟ ਦੀ ਪੁਸ਼ਟੀ ਕਰ ਸਕਦਾ ਹਾਂ।