ਇੱਕ ਹਾਲੀਆ ਬੈਂਚਮਾਰਕ ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਦੋ-ਪੱਧਰੀ ਮੈਮੋਰੀ ਡਿਜ਼ਾਈਨ—RAM-ਅਧਾਰਤ scratchpad ਅਤੇ ਇੱਕ ਸਥਾਨਕ SQLite-vec vault—100 ms ਤੋਂ ਘੱਟ ਮੱਧਮ (median) ਕੁਐਰੀ ਸਮਾਂ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ, ਜਦੋਂ ਕਿ ਇੱਕ ਪ੍ਰਸਿੱਧ ਕਲਾਉਡ ਵੈਕਟਰ ਸਟੋਰ ਨਾਲ ਜੁੜੇ $135 ਪ੍ਰਤੀ ਮਹੀਨਾ ਦੇ ਬਿੱਲ ਨੂੰ ਖਤਮ ਕਰਦਾ ਹੈ। ਖੁਦਮੁਖਤਿਆਰ AI agents ਬਣਾਉਣ ਵਾਲੇ ਡਿਵੈਲਪਰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਆਨ-ਪ੍ਰੇਮਿਸ (on-premise) ਸੈੱਟਅੱਪ ਚਲਾ ਸਕਦੇ ਹਨ ਜੋ, ਬੈਂਚਮਾਰਕ ਵਿੱਚ, ਤੇਜ਼ ਸੀ ਅਤੇ ਇਸ ਵਿੱਚ ਕੋਈ ਮਹੀਨਾਵਾਰ ਲਾਗਤ ਨਹੀਂ ਸੀ।
ਮੌਜੂਦਾ ਮੈਮੋਰੀ ਤਰੀਕੇ ਕਿਉਂ ਅਸਫਲ ਰਹਿੰਦੇ ਹਨ
AI agents ਨੂੰ ਅਕਸਰ ਇੱਕ ਸੀਮਤ ਜਵਾਬ ਦੇ ਸਮੇਂ (response window) ਦੇ ਅੰਦਰ ਹਜ਼ਾਰਾਂ ਪਿਛਲੀਆਂ ਗੱਲਬਾਤਾਂ, ਤੱਥਾਂ ਜਾਂ tool-call ਨਤੀਜਿਆਂ ਨੂੰ ਯਾਦ ਕਰਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਜ਼ਿਆਦਾਤਰ ਟੀਮਾਂ ਹਰ embedding ਨੂੰ ਇੱਕ managed vector database ਵਿੱਚ ਭੇਜ ਦਿੰਦੀਆਂ ਹਨ ਅਤੇ ਹਰ ਲੁੱਕਅੱਪ (lookup) ਲਈ ਰਿਮੋਟ ਵੈਕਟਰ ਸਰਚ 'ਤੇ ਨਿਰਭਰ ਕਰਦੀਆਂ ਹਨ। ਉਹ ਮਾਡਲ ਵਧਦਾ (scales) ਤਾਂ ਹੈ, ਪਰ ਇਹ ਹਰ ਕੁਐਰੀ ਨੂੰ ਨੈੱਟਵਰਕ ਰਾਹੀਂ ਭੇਜਣ ਲਈ ਮਜਬੂਰ ਕਰਦਾ ਹੈ, ਜਿਸ ਨਾਲ round-trip ਸਮੇਂ ਅਤੇ ਮਹੀਨਾਵਾਰ ਖਰਚੇ ਵਿੱਚ ਵਾਧਾ ਹੁੰਦਾ ਹੈ। ਬੈਂਚਮਾਰਕ ਵਿੱਚ, ਕਲਾਉਡ ਸਰਵਿਸ ਦੀ ਮੱਧਮ ਲੇਟੈਂਸੀ (median latency) 127 ms ਸੀ ਅਤੇ ਮਹੀਨੇ ਦਾ ਬਿੱਲ $135 ਤੋਂ ਉੱਪਰ ਸੀ; ਟੈਸਟ ਦੌਰਾਨ ਇੱਕ ਆਊਟੇਜ (outage) ਵੀ ਦਰਜ ਕੀਤੀ ਗਈ ਸੀ।
ਮੈਮੋਰੀ ਨੂੰ ਦੋ ਪੱਧਰਾਂ ਵਿੱਚ ਵੰਡਣਾ
ਦੋ-ਪੱਧਰੀ ਆਰਕੀਟੈਕਚਰ "working memory" ਨੂੰ "long-term storage" ਤੋਂ ਵੱਖ ਕਰਦਾ ਹੈ:
L1 Scratchpad (RAM)
- ਪੂਰੀ ਤਰ੍ਹਾਂ ਪ੍ਰੋਸੈਸ ਮੈਮੋਰੀ ਵਿੱਚ ਰਹਿੰਦਾ ਹੈ।
- ਮੌਜੂਦਾ ਟਾਸਕ ਕੰਟੈਕਸਟ ਅਤੇ ਸਭ ਤੋਂ ਹਾਲੀਆ tool calls ਨੂੰ ਰੱਖਦਾ ਹੈ।
- raw strings ਨੂੰ ਸਟੋਰ ਕਰਦਾ ਹੈ; ਕੋਈ embeddings ਨਹੀਂ ਬਣਾਈਆਂ ਜਾਂਦੀਆਂ।
- 3 ms ਤੋਂ ਘੱਟ ਸਮੇਂ ਵਿੱਚ ਨਤੀਜੇ ਦਿੰਦਾ ਹੈ, ਜੋ CPU cache ਦੇ ਬਰਾਬਰ ਹੈ।
L2 Vault (SQLite-vec)
- ਵੈਕਟਰ ਸਰਚ ਸਮਰੱਥਾਵਾਂ ਨਾਲ ਵਧਾਈ ਗਈ ਇੱਕ ਸਥਾਨਕ SQLite ਡੇਟਾਬੇਸ ਵਿੱਚ ਬਾਕੀ ਸਾਰੀਆਂ embeddings ਨੂੰ ਸਟੋਰ ਕਰਦਾ ਹੈ।
- ਬੈਂਚਮਾਰਕ ਵਿੱਚ ਵਰਤੀਆਂ ਗਈਆਂ 14,726 ਮੈਮੋਰੀਆਂ ਦੇ ਪੂਰੇ ਸੈੱਟ ਨੂੰ ਸੰਭਾਲਦਾ ਹੈ।
- ਲਗਭਗ 94 ms ਵਿੱਚ ਮੈਚ ਦਿੰਦਾ ਹੈ, ਜੋ ਕਿ ਕਈ ਰੀਅਲ-ਟਾਈਮ agents ਲਈ 100 ms ਦੇ ਟੀਚੇ ਤੋਂ ਕਾਫ਼ੀ ਹੇਠਾਂ ਹੈ।
- ਹੋਸਟ ਮਸ਼ੀਨ ਦੇ ਸਟੋਰੇਜ ਤੋਂ ਇਲਾਵਾ ਇਸਦੀ ਕੋਈ ਲਾਗਤ ਨਹੀਂ ਹੈ।
SQLite-vec ਇੱਕ open-source extension ਹੈ ਜੋ ਇੱਕ ਮਿਆਰੀ relational file ਵਿੱਚ approximate nearest-neighbor search ਜੋੜਦਾ ਹੈ। ਕਿਉਂਕਿ ਡੇਟਾਬੇਸ agent ਵਾਲੀ ਹੀ ਮਸ਼ੀਨ 'ਤੇ ਹੁੰਦਾ ਹੈ, ਇਸ ਲਈ ਕੋਈ network hop ਨਹੀਂ ਹੁੰਦਾ, ਅਤੇ ਇੰਜਣ ਲੁੱਕਅੱਪਸ ਨੂੰ ਤੇਜ਼ ਰੱਖਣ ਲਈ ਮੌਜੂਦਾ SQLite indexing ਤਰੀਕਿਆਂ ਦੀ ਮੁੜ ਵਰਤੋਂ ਕਰਦਾ ਹੈ।
ਮਹੱਤਵਪੂਰਨ ਅੰਕੜੇ
| ਸਿਸਟਮ | ਮੱਧਮ ਲੇਟੈਂਸੀ | ਮਹੀਨਾਵਾਰ ਲਾਗਤ | ਦਰਜ ਕੀਤੀ ਭਰੋਸੇਯੋਗਤਾ |
|---|---|---|---|
| Cloud vector store (Pinecone) | 127 ms | ~$135 | ਆਊਟੇਜ ਦੇਖੀਆਂ ਗਈਆਂ |
| Local SQLite-vec vault | 94 ms | $0 | 100% uptime |
ਲਾਗਤ ਦਾ ਅੰਤਰ $0 ਬਨਾਮ ਲਗਭਗ $135 ਪ੍ਰਤੀ ਮਹੀਨਾ ਹੈ।
ਵੌਲਟ (vault) ਨੂੰ ਸਾਫ਼-ਸੁਥਰਾ ਰੱਖਣਾ
ਸਾਰੀਆਂ embeddings ਦਾ raw dump ਪ੍ਰਸੰਗਿਕਤਾ (relevance) ਨੂੰ ਘਟਾ ਸਕਦਾ ਹੈ। ਬੈਂਚਮਾਰਕ ਦੇ ਲੇਖਕ ਨੇ ਇੱਕ decay system ਪੇਸ਼ ਕੀਤਾ ਹੈ ਜੋ ਮੈਮੋਰੀਆਂ ਨੂੰ ਉਹਨਾਂ ਦੀ ਤਾਜ਼ਗੀ (recency) ਅਤੇ ਬਾਰੰਬਾਰਤਾ (frequency) ਦੇ ਅਧਾਰ 'ਤੇ ਸਕੋਰ ਕਰਦਾ ਹੈ:
- ਨਵੀਆਂ ਜਾਂ ਅਕਸਰ ਵਰਤੀਆਂ ਜਾਣ ਵਾਲੀਆਂ ਵਸਤੂਆਂ ਨੂੰ ਉੱਚਾ ਭਾਰ (weight) ਮਿਲਦਾ ਹੈ।
- ਉਹ ਵਸਤੂਆਂ ਜਿਨ੍ਹਾਂ ਨੂੰ ਕੁਝ ਸਮੇਂ ਤੋਂ ਛੂਹਿਆ ਨਹੀਂ ਗਿਆ ਹੈ, ਉਹ ਹੌਲੀ-ਹੌਲੀ ਭਾਰ ਗੁਆ ਲੈਂਦੀਆਂ ਹਨ।
- ਵိတ်ਡ ਡਿਕੇ (weighted decay) "retrieval noise"—ਗੈਰ-ਪ੍ਰਸੰਗਿਕ ਮੈਚ—ਨੂੰ 34% ਤੱਕ ਘਟਾ ਦਿੰਦਾ ਹੈ।
ਘੱਟ ਸਕੋਰ ਵਾਲੀਆਂ ਐਂਟਰੀਆਂ ਨੂੰ ਛਾਂਟ ਕੇ (pruning) ਜਾਂ ਇੰਡੈਕਸ ਵਿੱਚ ਉਹਨਾਂ ਨੂੰ ਹੇਠਲੇ ਪੱਧਰ 'ਤੇ ਰੱਖ ਕੇ, agent ਪੁਰਾਣੇ ਡੇਟਾ ਤੋਂ ਬਚਦਾ ਹੈ ਅਤੇ ਨਾਲ ਹੀ ਵੌਲਟ ਨੂੰ ਲਗਾਤਾਰ ਪ੍ਰਦਰਸ਼ਨ ਲਈ ਲੋੜੀਂਦਾ ਹਲਕਾ ਰੱਖਦਾ ਹੈ।
ਸਿੱਟਾ
ਉਹਨਾਂ AI agents ਲਈ ਜਿਨ੍ਹਾਂ ਨੂੰ ਇੱਕ ਸੀਮਤ ਸਮੇਂ ਦੇ ਅੰਦਰ ਹਜ਼ਾਰਾਂ ਮੈਮੋਰੀਆਂ ਨੂੰ ਸੰਭਾਲਣਾ ਪੈਂਦਾ ਹੈ, RAM-ਪਹਿਲਾਂ scratchpad ਅਤੇ ਇੱਕ ਸਥਾਨਕ SQLite-vec vault ਦਾ ਸੁਮੇਲ ਪੂਰੀ ਤਰ੍ਹਾਂ ਕਲਾਉਡ-ਅਧਾਰਤ ਵੈਕਟਰ ਸਟੋਰਾਂ ਦਾ ਇੱਕ ਵਿਹਾਰਕ (pragmatic) ਵਿਕਲਪ ਪੇਸ਼ ਕਰਦਾ ਹੈ। ਇਹ ਤਰੀਕਾ ਜਵਾਬ ਦੇ ਸਮੇਂ ਨੂੰ ਘਟਾਉਂਦਾ ਹੈ, ਵਾਰ-ਵਾਰ ਲੱਗਣ ਵਾਲੀਆਂ ਕਲਾਉਡ ਫੀਸਾਂ ਨੂੰ ਖਤਮ ਕਰਦਾ ਹੈ ਅਤੇ ਬਿਨਾਂ ਕਿਸੇ ਰੁਕਾਵਟ ਦੇ ਸੇਵਾ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ, ਅਤੇ ਨਾਲ ਹੀ ਗੈਰ-ਪ੍ਰਸੰਗਿਕ ਡੇਟਾ ਨੂੰ ਛਾਂਟਣ ਦੀ ਸਮਰੱਥਾ ਨੂੰ ਬਰਕਰਾਰ ਰੱਖਦਾ ਹੈ। ਇਸ ਲਈ, ਦੋ-ਪੱਧਰੀ ਮਾਡਲ ਨੂੰ ਅਪਣਾਉਣ ਨਾਲ agents ਨੂੰ ਤੇਜ਼, ਸਸਤਾ ਅਤੇ ਵਧੇਰੇ ਭਰੋਸੇਮੰਦ ਬਣਾਇਆ ਜਾ ਸਕਦਾ ਹੈ।