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

ਟੋਕਨ ਡ੍ਰਿਫਟ ਉਦੋਂ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਹਰ ਇੰਟਰੈਕਸ਼ਨ ਮਾਡਲ ਦੇ ਇਨਪੁਟ ਕੰਟੈਕਸਟ (input context) ਵਿੱਚ ਹੋਰ ਟੈਕਸਟ ਜੋੜ ਦਿੰਦੀ ਹੈ। ਗੱਲਬਾਤ ਦਾ ਇਤਿਹਾਸ (conversation history), ਟੂਲ ਸਕੀਮਾ (tool schemas), API ਜਵਾਬ, ਅਤੇ ਪ੍ਰਾਪਤ ਕੀਤੇ ਗਏ ਦਸਤਾਵੇਜ਼ ਸਭ ਇਕੱਠੇ ਹੋ ਜਾਂਦੇ ਹਨ, ਜਿਸ ਕਾਰਨ ਹਰ ਅਗਲੀ ਕਾਲ ਵਿੱਚ ਇੱਕ ਵੱਡਾ ਪੇਲੋਡ (payload) ਹੁੰਦਾ ਹੈ। ਕਿਉਂਕਿ ਇਨਪੁਟ ਟੋਕਨਾਂ ਦੀ ਗਿਣਤੀ ਦੇ ਨਾਲ ਮਾਡਲ ਦਾ ਪ੍ਰੋਸੈਸਿੰਗ ਸਮਾਂ ਅਤੇ ਕੀਮਤ ਵਧਦੀ ਹੈ, ਇਸ ਲਈ ਲਾਗਤ ਲੀਨੀਅਰ (linear) ਦੀ ਬਜਾਏ ਕੁਆਡਰੇਟਿਕਲੀ (quadratically) ਵਧਦੀ ਹੈ।

ਇਹ ਸਮੱਸਿਆ ਡੈਮੋ ਵਿੱਚ ਨਹੀਂ, ਸਗੋਂ ਪ੍ਰੋਡਕਸ਼ਨ ਵਿੱਚ ਕਿਉਂ ਦਿਖਾਈ ਦਿੰਦੀ ਹੈ

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

ਟੋਕਨ ਡ੍ਰਿਫਟ ਦੇ ਆਮ ਸਰੋਤ

  • ਦੁਹਰਾਏ ਗਏ ਟ੍ਰਾਂਸਕ੍ਰਿਪਟਸ (Repeated transcripts) – ਪੁਰਾਣੇ ਸੁਨੇਹਿਆਂ ਨੂੰ ਸੰਖੇਪ ਕਰਨ ਜਾਂ ਹਟਾਉਣ ਦੀ ਬਜਾਏ ਪ੍ਰੋਂਪਟ ਵਿੱਚ ਰੱਖਣਾ।
  • ਭਾਰੀ ਟੂਲ ਸਕੀਮਾ (Heavy tool schemas) – ਹਰ ਵਾਰ ਟੂਲ ਦੀਆਂ ਸਮਰੱਥਾਵਾਂ ਦੀਆਂ ਵੱਡੀਆਂ JSON ਡੈਫੀਨੇਸ਼ਨਾਂ ਭੇਜਣਾ।
  • ਭਾਰੀ ਟੂਲ ਨਤੀਜੇ (Bulky tool results) – ਪੂਰੇ API ਜਵਾਬ ਜਾਂ ਡਾਟਾਬੇਸ ਰੋਅਜ਼ (rows) ਸ਼ਾਮਲ ਕਰਨਾ ਜਿਨ੍ਹਾਂ ਵਿੱਚ ਏਜੰਟ ਦੀ ਲੋੜ ਨਾਲੋਂ ਕਿਤੇ ਜ਼ਿਆਦਾ ਡਾਟਾ ਹੁੰਦਾ ਹੈ।
  • RAG ਬਲੋਟ (RAG bloat) – ਰਿਟ੍ਰੀਵਲ-ਔਗਮੈਂਟਡ ਜਨਰੇਸ਼ਨ (RAG) ਜੋ ਬਹੁਤ ਸਾਰੇ ਦਸਤਾਵੇਜ਼ਾਂ ਦੇ ਹਿੱਸੇ ਜੋੜ ਦਿੰਦਾ ਹੈ, ਜਿਨ੍ਹਾਂ ਵਿੱਚੋਂ ਕੁਝ ਪੁਰਾਣੇ ਜਾਂ ਅਪ੍ਰਸੰਗਿਕ ਹੁੰਦੇ ਹਨ।
  • ਡੁਪਲੀਕੇਟ ਮੈਮੋਰੀ (Duplicated memory) – ਇੱਕ ਸੰਖੇਪ (summary), ਇੱਕ ਸਟੇਟ ਆਬਜੈਕਟ, ਅਤੇ ਰਅਅ ਟ੍ਰਾਂਸਕ੍ਰਿਪਟ ਨੂੰ ਇਕੱਠਾ ਰੱਖਣਾ, ਜੋ ਇੱਕੋ ਜਾਣਕਾਰੀ ਨੂੰ ਤਿੰਨ ਵਾਰ ਦੁਹਰਾਉਂਦਾ ਹੈ।

ਇਹਨਾਂ ਵਿੱਚੋਂ ਹਰ ਇੱਕ ਅਜਿਹੇ ਟੋਕਨ ਜੋੜਦਾ ਹੈ ਜੋ ਨਵੀਂ ਤਰਕ ਸ਼ਕਤੀ (reasoning power) ਵਿੱਚ ਯੋਗਦਾਨ ਨਹੀਂ ਪਾਉਂਦੇ, ਫਿਰ ਵੀ ਉਹ ਪ੍ਰੋਂਪਟ ਦੇ ਆਕਾਰ ਨੂੰ ਵਧਾ ਦਿੰਦੇ ਹਨ।

ਟੋਕਨ ਬਜਟ ਨੂੰ ਕੰਟਰੋਲ ਵਿੱਚ ਕਿਵੇਂ ਰੱਖਣਾ ਹੈ

1. ਲੇਅਰਡ ਕੰਟੈਕਸ ਡਿਜ਼ਾਈਨ (Layered context design) ਅਪਣਾਓ

  • ਸਥਿਰ ਨਿਰਦੇਸ਼ (Stable instructions) – ਸਿਸਟਮ ਪ੍ਰੋਂਪਟ ਅਤੇ ਸੁਰੱਖਿਆ ਨਿਯਮਾਂ ਨੂੰ ਸਭ ਤੋਂ ਉੱਪਰ ਰੱਖੋ ਅਤੇ ਹਰ ਵਾਰ ਉਹਨਾਂ ਨੂੰ ਦੁਬਾਰਾ ਭੇਜਣ ਦੀ ਬਜਾਏ ਉਹਨਾਂ ਦਾ ਹਵਾਲਾ ਦਿਓ।
  • ਸਟ੍ਰਕਚਰਡ ਸਟੇਟ (Structured state) – ਟੀਚਿਆਂ, ਫੈਸਲਿਆਂ ਅਤੇ ਆਈਡੈਂਟੀਫਾਇਰਾਂ ਦਾ ਇੱਕ ਸੰਖੇਪ ਰੂਪ ਸਟੋਰ ਕਰੋ ਜਿਸ ਨੂੰ ਏਜੰਟ ਤੇਜ਼ੀ ਨਾਲ ਪੜ੍ਹ ਸਕੇ।
  • ਕੰਪ੍ਰੈੱਸਡ ਇਤਿਹਾਸ (Compressed history) – ਪੁਰਾਣੀਆਂ ਗੱਲਾਂ ਨੂੰ ਇੱਕ ਛੋਟੇ, ਮਨੁੱਖੀ-ਪੜ੍ਹਨਯੋਗ ਪੈਰੇ ਵਿੱਚ ਸੰਖੇਪ ਕਰੋ, ਅਤੇ ਸਿਰਫ ਉਦੋਂ ਅਪਡੇਟ ਕਰੋ ਜਦੋਂ ਕੋਈ ਸੀਮਾ (threshold) ਪੂਰੀ ਹੋ ਜਾਵੇ।
  • ਹਾਲੀਆ ਗੱਲਾਂ (Recent turns) – ਲਗਾਤਾਰਤਾ ਬਣਾਈ ਰੱਖਣ ਲਈ ਆਖਰੀ ਕੁਝ ਸੁਨੇਹਿਆਂ ਨੂੰ ਜਿਵੇਂ ਦੇ ਤਿਵੇਂ ਸ਼ਾਮਲ ਕਰੋ।

ਸਥਿਰ ਟੈਕਸਟ ਨੂੰ ਸੰਖੇਪ ਕੀਤੇ ਜਾ ਸਕਣ ਵਾਲੇ ਕੰਟੈਂਟ ਤੋਂ ਵੱਖ ਕਰਨਾ ਤੁਹਾਨੂੰ ਵਾਰ-ਵਾਰ ਇੱਕੋ ਸ਼ਬਦ ਦੁਬਾਰਾ ਭੇਜਣ ਤੋਂ ਰੋਕਦਾ ਹੈ।

2. ਟੂਲ ਆਉਟਪੁੱਟ ਨੂੰ ਘਟਾਓ (Trim tool outputs)

  • ਸਿਰਫ ਉਹ ਫੀਲਡ ਕੱਢੋ ਜਿਨ੍ਹਾਂ ਦੀ ਏਜੰਟ ਨੂੰ ਅਸਲ ਵਿੱਚ ਲੋੜ ਹੈ; ਵਾਧੂ ਵੇਰਵੇ ਹਟਾ ਦਿਓ।
  • ਵੱਡੇ ਨਤੀਜਿਆਂ ਨੂੰ ਇੱਕ ਸੰਖੇਪ ਸਾਰ ਜਾਂ ਰੈਫਰੈਂਸ ID ਨਾਲ ਬਦਲੋ, ਅਤੇ ਪੂਰੇ ਪੇਲੋਡ ਨੂੰ ਡਾਟਾਬੇਸ, ਕੈਸ਼ (cache), ਜਾਂ ਬਲੌਬ ਸਟੋਰ ਵਿੱਚ ਸਟੋਰ ਕਰੋ।
  • ਜਦੋਂ ਕੋਈ ਟੂਲ ਸੂਚੀ (list) ਵਾਪਸ ਕਰਦਾ ਹੈ, ਤਾਂ ਸਿਰਫ ਉਹਨਾਂ 'Top-N' ਚੀਜ਼ਾਂ ਨੂੰ ਭੇਜੋ ਜੋ ਮੌਜੂਦਾ ਫੈਸਲੇ ਲਈ ਮਹੱਤਵਪੂਰਨ ਹਨ।

3. ਸਮਾਰਟ ਸੰਖੇਪਤਾ (Smart summarization) ਲਾਗੂ ਕਰੋ

  • ਹਰ ਵਾਰ ਸੰਖੇਪ ਕਰਨ ਤੋਂ ਬਚੋ; ਵਾਧੂ ਪ੍ਰੋਸੈਸਿੰਗ ਨਾਲ ਬੋਝ ਵਧਦਾ ਹੈ।
  • ਸਾਰ (summary) ਨੂੰ ਉਦੋਂ ਹੀ ਤਾਜ਼ਾ ਕਰੋ ਜਦੋਂ ਪੁਰਾਣੀਆਂ ਗੱਲਾਂ ਦੀ ਇਕੱਠੀ ਹੋਈ ਟੋਕਨ ਗਿਣਤੀ ਇੱਕ ਨਿਰਧਾਰਤ ਸੀਮਾ ਨੂੰ ਪਾਰ ਕਰ ਜਾਵੇ।
  • ਮਹੱਤਵਪੂਰਨ ਤੱਥਾਂ—ਜਿਵੇਂ ID, ਰਕਮ, ਟਾਈਮਸਟੈਂਪ—ਨੂੰ ਲੇਖ (prose) ਵਿੱਚ ਸ਼ਾਮਲ ਕਰਨ ਦੀ ਬਜਾਏ ਇੱਕ ਸਟ੍ਰਕਚਰਡ ਸਟੋਰ ਵਿੱਚ ਰੱਖੋ, ਤਾਂ ਜੋ ਸੰਖੇਪਤਾ ਛੋਟੀ ਰਹੇ।

4. ਸਹੀ ਮੈਟ੍ਰਿਕਸ (Metrics) ਨੂੰ ਟਰੈਕ ਕਰੋ

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

ਪ੍ਰੋਂਪਟ ਨੂੰ ਇੱਕ ਸੀਮਤ ਸਰੋਤ ਵਜੋਂ ਮੰਨੋ, ਨਾ ਕਿ ਇੱਕ ਅਨੰਤ ਟ੍ਰਾਂਸਕ