ਕਿਸਮ ਦੇ ਅਨੁਸਾਰ ਮੈਮੋਰੀ ਨੂੰ ਸੰਗਠਿਤ ਕਰਨ ਨਾਲ ਪ੍ਰਾਪਤ ਕੀਤੇ ਗਏ ਟੋਕਨਾਂ ਵਿੱਚ ਲਗਭਗ 40% ਦੀ ਕਮੀ ਆਉਂਦੀ ਹੈ।
ਇੱਕ ਫਲੈਟ ਮੈਮੋਰੀ ਸਟੋਰ ਕਿਉਂ ਫੇਲ ਹੋ ਜਾਂਦਾ ਹੈ
ਜ਼ਿਆਦਾਤਰ ਸ਼ੁਰੂਆਤੀ ਟਿਊਟੋਰਿਅਲ ਇੱਕ LLM ਐਜੰਟ ਨੂੰ ਹਰ ਨਵੀਂ ਜਾਣਕਾਰੀ ਨੂੰ ਇੱਕ ਸਿੰਗਲ ਲਿਸਟ ਵਿੱਚ ਜੋੜ ਕੇ ਅਤੇ ਹਰ ਵਾਰ ਉਸ ਲਿਸਟ ਨੂੰ ਮਾਡਲ ਨੂੰ ਵਾਪਸ ਭੇਜ ਕੇ "ਯਾਦ ਰੱਖਣਾ" ਸਿਖਾਉਂਦੇ ਹਨ। ਕੋਡ ਲਗਭਗ ਸਿਰਫ਼ ਤਿੰਨ ਲਾਈਨਾਂ ਦਾ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਇਹ ਇੱਕ ਕੰਮ ਕਰਦਾ ਹੋਇਆ ਡੈਮੋ ਤਿਆਰ ਕਰ ਦਿੰਦਾ ਹੈ। ਅਸਲ ਵਿੱਚ, ਇਹ ਲਿਸਟ ਬਿਨਾਂ ਕਿਸੇ ਰੋਕ-ਟੋਕ ਦੇ ਵਧਦੀ ਜਾਂਦੀ ਹੈ। ਦੋ ਲੱਛਣ ਦਿਖਾਈ ਦਿੰਦੇ ਹਨ:
- ਐਜੰਟ ਪੁਰਾਣੇ ਡੇਟਾ ਨੂੰ ਅਜੇ ਵੀ ਸਹੀ ਮੰਨਦਾ ਹੈ, ਉਦਾਹਰਨ ਲਈ ਅਜਿਹਾ ETA ਦੇਣਾ ਜੋ ਕਈ ਘੰਟੇ ਪਹਿਲਾਂ ਹੀ ਖਤਮ ਹੋ ਚੁੱਕਾ ਹੋਵੇ।
- ਕੰਟੈਕਸਟ ਵਿੰਡੋ (context window) ਅਜਿਹੀਆਂ ਫਾਲਤੂ ਜਾਣਕਾਰੀਆਂ ਨਾਲ ਭਰ ਜਾਂਦੀ ਹੈ ਜੋ ਜਵਾਬ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਨਹੀਂ ਕਰਦੀਆਂ, ਜਿਸ ਨਾਲ API ਦੀ ਲਾਗਤ ਵਧ ਜਾਂਦੀ ਹੈ ਅਤੇ ਜਵਾਬ ਦੇਣ ਦਾ ਸਮਾਂ ਵੀ ਲੰਬਾ ਹੋ ਜਾਂਦਾ ਹੈ।
ਇੱਕ ਸਾਧਾਰਨ ਵੈਕਟਰ ਸਟੋਰ ਜਾਂ ਸਧਾਰਨ ਕੀ-ਵੈਲਯੂ (key-value) ਕੈਸ਼, ਯੂਜ਼ਰ ਦੇ ਅਹੁਦੇ ਅਤੇ ਕਿਸੇ ਅਸਥਾਈ ਪ੍ਰੋਜੈਕਟ ਸਟੇਟਸ ਵਿੱਚ ਫਰਕ ਨਹੀਂ ਕਰ ਸਕਦਾ। ਜਦੋਂ ਐਜੰਟ ਸਿਮੈਂਟਿਕ ਸਰਚ (semantic search) ਕਰਦਾ ਹੈ, ਤਾਂ ਸਮਾਨਤਾ ਐਲਗੋਰਿਦਮ (similarity algorithm) ਸਿਰਫ਼ ਇਸ ਲਈ ਇੱਕ ਪੁਰਾਣਾ ETA ਦਿਖਾ ਸਕਦਾ ਹੈ ਕਿਉਂਕਿ ਕੁਐਰੀ (query) ਵਿੱਚ ਉਹੀ ਸ਼ਬਦ ਹਨ, ਭਾਵੇਂ ਕਿ ਉਹ ਜਾਣਕਾਰੀ ਹੁਣ ਪ੍ਰਸੰਗਿਕ ਨਾ ਹੋਵੇ।
ਸੰਗਠਿਤ ਮੈਮੋਰੀ: ਚਾਰ ਬੱਕੇਟ, ਇੱਕ ਉਦੇਸ਼
ਇਸ ਦਾ ਹੱਲ ਇਹ ਹੈ ਕਿ ਮੈਮੋਰੀ ਨੂੰ ਇੱਕ ਇਕਾਈ (monolith) ਵਜੋਂ ਦੇਖਣਾ ਬੰਦ ਕੀਤਾ ਜਾਵੇ ਅਤੇ ਹਰ ਐਂਟਰੀ ਨੂੰ ਚਾਰ ਸ਼੍ਰੇਣੀਆਂ ਵਿੱਚੋਂ ਇੱਕ ਵਿੱਚ ਵੰਡਣਾ ਸ਼ੁਰੂ ਕੀਤਾ ਜਾਵੇ:
- User facts – ਸਥਿਰ ਗੁਣ ਜਿਵੇਂ ਕਿ ਯੂਜ਼ਰ ਦੀ ਭੂਮਿਕਾ, ਪਸੰਦੀਦਾ ਭਾਸ਼ਾ, ਜਾਂ ਸੁਰੱਖਿਆ ਕਲੀਅਰੈਂਸ। ਇਹ ਬਹੁਤ ਘੱਟ ਬਦਲਦੇ ਹਨ ਅਤੇ ਪੂਰੇ ਸੈਸ਼ਨ ਲਈ ਕੈਸ਼ ਕੀਤੇ ਜਾ ਸਕਦੇ ਹਨ।
- Feedback – ਸਪੱਸ਼ਟ ਨਿਯਮ ਜਿਨ੍ਹਾਂ ਦੀ ਪਾਲਣਾ ਐਜੰਟ ਨੂੰ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ, ਜਿਵੇਂ ਕਿ "ਡਾਟਾਬੇਸ ਪਾਸਵਰਡ ਕਦੇ ਵੀ ਪ੍ਰਗਟ ਨਾ ਕਰੋ" ਜਾਂ "ਕੰਪਲਾਇੰਸ ਕੁਐਰੀਆਂ ਵਿੱਚ ਹਾਸਰਸ ਤੋਂ ਬਚੋ।" ਕਿਉਂਕਿ ਇਹ ਵਿਵਹਾਰ ਨੂੰ ਨਿਰਧਾਰਤ ਕਰਦੇ ਹਨ, ਇਸ ਲਈ ਇਹ ਸਰਚਯੋਗ ਪੂਲ ਦੀ ਬਜਾਏ ਸਿਸਟਮ ਪ੍ਰੋਂਪਟ (system prompt) ਵਿੱਚ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ।
- Project state – ਤੇਜ਼ੀ ਨਾਲ ਬਦਲਣ ਵਾਲਾ ਡੇਟਾ ਜਿਵੇਂ ਕਿ ਮੌਜੂਦਾ ETA, ਕੰਮ ਦੀ ਪ੍ਰਗਤੀ, ਜਾਂ ਅਸਥਾਈ ਟੋਕਨ। ਇਸ ਬੱਕੇਟ ਨੂੰ ਐਕਸਪਾਇਰੀ ਚੈੱਕ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ; ਇੱਕ ਵਾਰ ਜਦੋਂ ਟਾਈਮਸਟੈਂਪ ਨਿਰਧਾਰਤ ਸਮੇਂ ਤੋਂ ਬਾਹਰ ਹੋ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਉਸ ਐਂਟਰੀ ਨੂੰ ਹਟਾ ਦਿੱਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ।
- References – ਬਾਹਰੀ ਸੇਵਾਵਾਂ, ਦਸਤਾਵੇਜ਼ IDs, ਜਾਂ API ਐਂਡਪੁਆਇੰਟਸ ਦੇ ਪੁਆਇੰਟਰ। ਇਹ ਦਿਖਾਉਣ ਲਈ ਸਮੱਗਰੀ ਨਹੀਂ ਹਨ, ਸਗੋਂ ਲੋੜ ਪੈਣ 'ਤੇ ਤਾਜ਼ਾ ਡੇਟਾ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ ਰੂਟ ਹਨ।
Mem0 ਡਿਵੈਲਪਰਾਂ ਨੂੰ ਹਰੇਕ ਮੈਮੋਰੀ ਰਿਕਾਰਡ ਨਾਲ ਮੈਟਾਡਾਟਾ ਜੋੜਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ। "kind" ਫੀਲਡ 'ਤੇ ਇੰਡੈਕਸਿੰਗ ਕਰਕੇ, LLM ਦੁਆਰਾ ਨਤੀਜੇ ਦੀ ਵਰਤੋਂ ਕਰਨ ਦਾ ਫੈਸਲਾ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ, ਇੱਕ ਕੁਐਰੀ ਪਹਿਲਾਂ ਸਬੰਧਤ ਬੱਕੇਟ ਲਈ ਫਿਲਟਰ ਕਰ ਸਕਦੀ ਹੈ।
Mem0 ਦੇ ਨਾਲ ਦੋ-ਪੜਾਵੀ ਰਿਟ੍ਰੀਵਲ (retrieval)
- ਕਿੰਡ (kind) ਦੇ ਅਨੁਸਾਰ ਮੈਮੋਰੀਆਂ ਕੱਢੋ – ਇੱਕ ਛੋਟੀ ਫਿਲਟਰ ਕੁਐਰੀ Mem0 ਤੋਂ "ਸਾਰਾ ਫੀਡਬੈਕ" ਜਾਂ "ਘੱਟ ਸਮੇਂ ਦੇ ਅੰਤਰਾਲ ਤੋਂ ਨਵੇਂ ਪ੍ਰੋਜੈਕਟ-ਸਟੇਟ ਐਂਟਰੀਜ਼" ਮੰਗਦੀ ਹੈ। ਨਤੀਜਾ ਸੈੱਟ ਪਹਿਲਾਂ ਹੀ ਉਚਿਤ ਸ਼੍ਰੇਣੀ ਤੱਕ ਸੀਮਤ ਹੁੰਦਾ ਹੈ।
- LLM ਨੂੰ ਫੈਸਲਾ ਕਰਨ ਦਿਓ – ਫਿਲਟਰ ਕੀਤੇ ਗਏ ਟੁਕੜਿਆਂ ਨੂੰ ਯੂਜ਼ਰ ਦੇ ਮੌਜੂਦਾ ਸਵਾਲ ਦੇ ਨਾਲ ਪ੍ਰੋਂਪਟ ਵਿੱਚ ਪਾਇਆ ਜਾਂਦਾ ਹੈ। ਹੁਣ ਮਾਡਲ ਬਿਨਾਂ ਫਾਲਤੂ ਤੱਥਾਂ ਨੂੰ ਛਾਣੇ, ਉਹਨਾਂ ਬਾਰੇ ਵਿਚਾਰ ਕਰ ਸਕਦਾ ਹੈ।
ਇੱਕ ਅਸਲੀ ਉਦਾਹਰਨ: "ਡਾਟਾਬੇਸ ਦਾ ਮਜ਼ਾਕ ਨਾ ਉਡਾਓ" ਨਿਯਮ ਨੂੰ ਦਿਖਾਉਣ ਲਈ ਸਿਮੈਂਟਿਕ ਮੈਚ ਦੀ ਉਡੀਕ ਕਰਨ ਦੀ ਬਜਾਏ, ਡਿਵੈਲਪਰ ਸੈਸ਼ਨ ਸ਼ੁਰੂ ਹੋਣ ਵੇਲੇ ਉਸ ਨਿਯਮ ਨੂੰ ਸਿੱਧਾ ਸਿਸਟਮ ਪ੍ਰੋਂਪਟ ਵਿੱਚ ਪਾ ਦਿੰਦਾ ਹੈ ਅਤੇ ਪੂਰੀ ਗੱਲਬਾਤ ਲਈ ਇਸ ਨੂੰ ਕੈਸ਼ ਕਰ ਲੈਂਦਾ ਹੈ। ਭਾਵੇਂ ਯੂਜ਼ਰ ਦੀ ਕੁਐਰੀ ਵਿੱਚ ਡਾਟਾਬੇਸ ਦਾ ਕੋਈ ਸਪੱਸ਼ਟ ਹਵਾਲਾ ਨਾ ਹੋਵੇ, ਮਾਡਲ ਨੂੰ ਪਹਿਲਾਂ ਹੀ ਇਸ ਪਾਬੰਦੀ ਬਾਰੇ ਪਤਾ ਹੁੰਦਾ ਹੈ।
ਲਾਗਤ ਘਟਾਉਣ ਲਈ ਵਿਵਹਾਰਕ ਤਰੀਕੇ
- ਫੀਡਬੈਕ ਨਿਯਮਾਂ ਨੂੰ ਕੈਸ਼ ਕਰੋ – ਹਰ ਵਾਰ ਦੁਬਾਰਾ ਸਰਚ ਕਰਨ ਦੀ ਬਜਾਏ, ਨਿਯਮਾਂ ਦੇ ਸੈੱਟ ਨੂੰ ਇੱਕ ਵਾਰ ਸੈਸ਼ਨ ਲਈ ਸਟੋਰ ਕਰੋ ਅਤੇ ਇਸ ਦੀ ਦੁਬਾਰਾ ਵਰਤੋਂ ਕਰੋ। ਇਹ ਹਰੇਕ ਰਾਊਂਡ ਵਿੱਚ ਟੋਕਨ ਦੀ ਵਰਤੋਂ ਨੂੰ ਘਟਾਉਂਦਾ ਹੈ।
- ਜਦੋਂ ਅਪ੍ਰਸੰਗਿਕ ਹੋਵੇ ਤਾਂ ਪ੍ਰੋਜੈਕਟ-ਸਟੇਟ ਸਰਚ ਨੂੰ ਛੱਡ ਦਿਓ – ਜੇਕਰ ਯੂਜ਼ਰ ਸਿਰਫ਼ ਇੱਕ ਸੰਕਲਪਤ ਸਵਾਲ ਪੁੱਛਦਾ ਹੈ ("ਸੁਪਰਵਾਈਜ਼ਡ ਅਤੇ ਰੀਇਨਫੋਰਸਮੈਂਟ ਲਰਨਿੰਗ ਵਿੱਚ ਕੀ ਅੰਤਰ ਹੈ?"), ਤਾਂ ਕਿਸੇ ਵੀ ETA ਜਾਂ ਕੰਮ ਦੀ ਪ੍ਰਗਤੀ ਦੇ ਡੇਟਾ ਨੂੰ ਕੱਢਣ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ।
ਇਹਨਾਂ ਦੋ ਆਦਤਾਂ ਨੂੰ ਅਪਣਾ ਕੇ, ਇੱਕ ਸਾਧਾਰਨ ਫਲੈਟ ਮੈਮੋਰੀ ਪਹੁੰਚ ਦੀ ਤੁਲਨਾ ਵਿੱਚ ਟੋਕਨ ਦੀ ਵਰਤੋਂ ਨੂੰ ਲਗਭਗ 40% ਤੱਕ ਘਟਾਇਆ ਜਾ ਸਕਦਾ ਹੈ। ਇਹ ਬਚਤ ਸਿੱਧੇ ਤੌਰ 'ਤੇ ਘੱਟ API ਬਿੱਲਾਂ ਅਤੇ ਤੇਜ਼ ਰਿਸ