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

ਕੈਸ਼ (cache) ਕਿਉਂ ਮਹੱਤਵਪੂਰਨ ਹੈ

ਪ੍ਰੋਵਾਈਡਰ ਦਾ ਪ੍ਰੋਂਪਟ ਕੈਸ਼ ਤੁਹਾਨੂੰ ਪੈਸੇ ਬਚਾਉਂਦਾ ਹੈ ਕਿਉਂਕਿ ਇਹ ਉਹਨਾਂ ਬੇਨਤੀਆਂ (requests) ਦੀ ਮੁੜ-ਪ੍ਰੋਸੈਸਿੰਗ ਨੂੰ ਛੱਡ ਦਿੰਦਾ ਹੈ ਜੋ ਬਾਈਟ-ਦਰ-ਬਾਈਟ (byte-for-byte) ਇੱਕੋ ਜਿਹੇ ਪ੍ਰੀਫਿਕਸ (prefix) ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦੀਆਂ ਹਨ। ਜੇਕਰ ਪਹਿਲੇ ਟੋਕਨ (tokens) ਪਿਛਲੀ ਕਾਲ ਨਾਲ ਮੇਲ ਖਾਂਦੇ ਹਨ, ਤਾਂ ਪ੍ਰੋਵਾਈਡਰ ਉਹਨਾਂ ਟੋਕਨਾਂ ਦੇ ਪਹਿਲਾਂ ਤੋਂ ਕੰਪਿਊਟ ਕੀਤੇ ਰੂਪ ਦੀ ਮੁੜ ਵਰਤੋਂ ਕਰਦਾ ਹੈ ਅਤੇ ਸਿਰਫ਼ ਨਵੇਂ ਸਫਿਕਸ (suffix) ਲਈ ਚਾਰਜ ਕਰਦਾ ਹੈ। ਨਿਯਮ ਸਖ਼ਤ ਹੈ: ਮੇਲ ਬਿਲਕੁਲ ਸਹੀ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਸਿਰਫ਼ ਸਮਾਨ ਨਹੀਂ। ਸ਼ੁਰੂ ਵਿੱਚ ਇੱਕ ਵੱਖਰਾ ਟੋਕਨ ਵੀ ਪੂਰੇ ਕੈਸ਼ ਹਿੱਟ (cache hit) ਨੂੰ ਖਰਾਬ ਕਰ ਸਕਦਾ ਹੈ।

ਉਹ ਗਲਤੀ ਜਿਸ ਨੇ ਹਿੱਟ ਰੇਟ (hit rate) ਨੂੰ ਖਤਮ ਕਰ ਦਿੱਤਾ

ਸਾਡੇ ਏਜੰਟ (agent) ਵਿੱਚ, ਅਸੀਂ ਮਾਡਲ ਨੂੰ "ਹੁਣ" ਦਾ ਅਹਿਸਾਸ ਕਰਵਾਉਣ ਲਈ ਸਿਸਟਮ ਪ੍ਰੋਂਪਟ ਦੇ ਬਿਲਕੁਲ ਉੱਪਰ ਮੌਜੂਦਾ ਟਾਈਮਸਟੈਂਪ (timestamp) ਰੱਖਿਆ ਸੀ। ਕਿਉਂਕਿ ਟਾਈਮਸਟੈਂਪ ਹਰ ਸੈਕਿੰਡ ਬਦਲਦਾ ਹੈ, ਇਸ ਲਈ ਹਰ ਬੇਨਤੀ ਲਈ ਪਹਿਲਾ ਟੋਕਨ ਸੀਕਵੈਂਸ (token sequence) ਵੱਖਰਾ ਸੀ। ਕੈਸ਼ ਨੂੰ ਕਦੇ ਵੀ ਕੋਈ ਮੇਲ ਨਹੀਂ ਮਿਲੀ, ਇਸ ਲਈ ਹਰ ਕਾਲ ਲਈ ਅਗਲੇ 18,000 ਸਟੈਟਿਕ ਟੋਕਨਾਂ—ਜਿਵੇਂ ਕਿ ਟੂਲ ਸਕੀਮਾ (tool schemas), ਡਾਕੂਮੈਂਟੇਸ਼ਨ ਸਨਿਪੇਟਸ (documentation snippets), ਫਿਊ-ਸ਼ੌਟ ਉਦਾਹਰਣਾਂ (few-shot examples) ਅਤੇ ਫਿਕਸਡ ਇੰਸਟ੍ਰਕਸ਼ਨਾਂ—ਦੀ ਪੂਰੀ ਕੀਮਤ ਚੁਕਾਉਣੀ ਪਈ। ਨਤੀਜਾ ਸੀ 0% ਕੈਸ਼ ਹਿੱਟ ਰੇਟ ਅਤੇ ਤਿੰਨ ਗੁਣਾ ਵਧਿਆ ਹੋਇਆ ਬਿੱਲ।

ਕੈਸ਼ ਕਰਨ ਯੋਗਤਾ (cacheability) ਲਈ ਮੁੜ-ਵਿਵਸਥਿਤ ਕਰਨਾ

ਇਸਦਾ ਹੱਲ ਸਧਾਰਨ ਹੈ: ਜੋ ਚੀਜ਼ ਕਦੇ ਨਹੀਂ ਬਦਲਦੀ ਉਸਨੂੰ ਪ੍ਰੋਂਪਟ ਦੇ ਸ਼ੁਰੂ ਵਿੱਚ ਰੱਖੋ ਅਤੇ ਕਿਸੇ ਵੀ ਬਦਲਣਯੋਗ (volatile) ਡੇਟਾ ਨੂੰ ਅੰਤ ਵਿੱਚ ਰੱਖੋ।

ਸਟੈਟਿਕ ਪ੍ਰੀਫਿਕਸ (ਕੈਸ਼ ਕਰਨ ਯੋਗ)

  • ਟੂਲ ਡੈਫੀਨੇਸ਼ਨ (Tool definitions)
  • ਰਿਟ੍ਰੀਵਲ ਡਾਕੂਮੈਂਟਸ (Retrieval documents)
  • ਫਿਊ-ਸ਼ੌਟ ਉਦਾਹਰਣਾਂ (Few-shot examples)
  • ਫਿਕਸਡ ਸਿਸਟਮ ਇੰਸਟ੍ਰਕਸ਼ਨਾਂ (Fixed system instructions)

ਬਦਲਣਯੋਗ ਸਫਿਕਸ (ਕੈਸ਼ ਨਾ ਹੋਣ ਯੋਗ)

  • ਮੌਜੂਦਾ ਸਮਾਂ (Current time)
  • ਸੈਸ਼ਨ ਆਈਡੀ (Session identifiers)
  • ਯੂਜ਼ਰ ਮੈਸੇਜ (User messages)
  • ਲਾਈਵ ਕੰਟੈਕਸਟ (Live context)

ਜੇਕਰ ਮਾਡਲ ਨੂੰ ਸਮੇਂ ਦੀ ਲੋੜ ਹੈ, ਤਾਂ ਇਸਨੂੰ ਸ਼ੁਰੂ ਵਿੱਚ ਜੋੜਨ ਦੀ ਬਜਾਏ ਸਟੈਟਿਕ ਬਲਾਕ ਤੋਂ ਬਾਅਦ ਲਗਾਓ। ਇਸ ਤਰ੍ਹਾਂ ਕੈਸ਼ ਭਾਰੀ ਸਟੈਟਿਕ ਹਿੱਸੇ ਦੀ ਮੁੜ ਵਰਤੋਂ ਕਰ ਸਕਦਾ ਹੈ ਜਦੋਂ ਕਿ ਤੁਸੀਂ ਅੰਤ ਵਿੱਚ ਨਵਾਂ ਕੰਟੈਕਸਟ (context) ਪ੍ਰਦਾਨ ਕਰਦੇ ਰਹਿੰਦੇ ਹੋ।

ਸਟੈਕ ਵਿੱਚ ਲੁਕੇ ਹੋਏ ਖ਼ਤਰੇ

ਭਾਵੇਂ ਟੈਂਪਲੇਟ ਸਹੀ ਲੱਗੇ, ਮਿਡਲਵੇਅਰ (middleware) ਜਾਂ SDKs ਪੇਲੋਡ (payload) ਦੇ API ਤੱਕ ਪਹੁੰਚਣ ਤੋਂ ਪਹਿਲਾਂ ਚੁੱਪਚਾਪ ਮੈਟਾਡਾਟਾ—ਜਿਵੇਂ ਕਿ ਰਿਕੁਐਸਟ ID, ਟਾਈਮਸਟੈਂਪ ਜਾਂ ਹੋਰ ਹੈਡਰ—ਸ਼ੁਰੂ ਵਿੱਚ ਜੋੜ ਸਕਦੇ ਹਨ। ਕੁਝ ਡਿਪਲਾਈਮੈਂਟ ਪਾਈਪਲਾਈਨਾਂ ਹਰ ਰੋਲਆਊਟ (rollout) 'ਤੇ ਟੂਲ ਡੈਫੀਨੇਸ਼ਨਾਂ ਨੂੰ ਵੀ ਬਦਲ ਦਿੰਦੀਆਂ ਹਨ। ਉਹ ਅਦਿੱਖ ਤਬਦੀਲੀਆਂ ਬਾਈਟ ਸੀਕਵੈਂਸ ਨੂੰ ਬਦਲ ਦਿੰਦੀਆਂ ਹਨ ਅਤੇ ਤੁਹਾਡੇ ਆਪਣੇ ਪ੍ਰੋਂਪਟ ਬਿਲਡਰ ਵਿੱਚ ਕੋਈ ਕੋਡ ਤਬਦੀਲੀ ਕੀਤੇ ਬਿਨਾਂ ਕੈਸ਼ ਨੂੰ ਖਰਾਬ ਕਰ ਦਿੰਦੀਆਂ ਹਨ।

ਕੈਸ਼ ਹਿੱਟ ਰੇਟ (cache hit rate) 'ਤੇ ਨਜ਼ਰ ਰੱਖੋ

ਕਿਸੇ ਵੀ AI ਏਜੰਟ ਲਈ ਕੈਸ਼ ਹਿੱਟ ਰੇਟ ਨੂੰ ਮੁੱਖ ਸਿਹਤ ਮਾਪਦੰਡ (health metric) ਵਜੋਂ ਲਓ। ਅਚਾਨਕ ਗਿਰਾਵਟ ਇਹ ਸੰਕੇਤ ਦਿੰਦੀ ਹੈ ਕਿ ਰਿਕੁਐਸ ਦੇ ਸ਼ੁਰੂਆਤੀ ਬਾਈਟਸ ਵਿੱਚ ਕੁਝ ਬਦਲਣਯੋਗ ਹੋ ਗਿਆ ਹੈ। ਮਾਨੀਟਰਿੰਗ ਟੂਲਸ ਜੋ ਹਿੱਟ ਪ੍ਰਤੀਸ਼ਤ ਦਿਖਾਉਂਦੇ ਹਨ, ਤੁਹਾਨੂੰ ਲਾਗਤ ਵਿੱਚ ਅਸਧਾਰਨ ਵਾਧੇ ਨੂੰ ਫਟਣ ਤੋਂ ਪਹਿਲਾਂ ਪਛਾਣਨ ਵਿੱਚ ਮਦਦ ਕਰਦੇ ਹਨ।

ਸਿੱਖਿਆ (Takeaway)

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