તાજેતરના બેન્ચમાર્ક દર્શાવે છે કે બે-સ્તરની મેમરી ડિઝાઇન—RAM-આધારિત સ્ક્રેચપેડ પ્લસ લોકલ SQLite-vec વોલ્ટ—100 મિલીસેકન્ડથી ઓછો મધ્યમ ક્વેરી સમય આપે છે અને લોકપ્રિય ક્લાઉડ વેક્ટર સ્ટોર સાથે જોડાયેલ માસિક $135 ના બિલને દૂર કરે છે. સ્વાયત્ત AI એજન્ટ્સ બનાવતા ડેવલપર્સ સંપૂર્ણપણે ઓન-પ્રેમાઇઝ સેટઅપ ચલાવી શકે છે, જે બેન્ચમાર્કમાં વધુ ઝડપી હતું અને તેમાં કોઈ માસિક ખર્ચ થયો ન હતો.
શા માટે હાલના મેમરી અભિગમો અપૂરતા છે
AI એજન્ટ્સને ઘણીવાર પ્રતિસાદ આપવાના ટૂંકા સમયગાળામાં હજારો ભૂતકાળની ક્રિયાપ્રતિક્રિયાઓ, તથ્યો અથવા ટૂલ-કોલ પરિણામો યાદ રાખવાની જરૂર પડે છે. મોટાભાગની ટીમો દરેક એમ્બેડિંગને મેનેજ્ડ વેક્ટર ડેટાબેઝમાં મોકલે છે અને દરેક લુકઅપ માટે રિમોટ વેક્ટર સર્ચ પર આધાર રાખે છે. આ મોડેલ સ્કેલ કરી શકે છે, પરંતુ તે દરેક ક્વેરીને નેટવર્ક દ્વારા પસાર કરવા મજબૂર કરે છે, જેનાથી રાઉન્ડ-ટ્રિપ સમય અને માસિક ખર્ચ વધે છે. બેન્ચમાર્કમાં, ક્લાઉડ સર્વિસનો મધ્યમ લેટન્સી (latency) 127 મિલીસેકન્ડ હતો અને માસિક બિલ $135 થી વધુ હતું; ટેસ્ટ સમયગાળા દરમિયાન આઉટેજ (outage) પણ નોંધાયો હતો.
મેમરીને બે સ્તરોમાં વિભાજિત કરવી
ડ્યુઅલ-ટાયર આર્કિટેક્ચર "વર્કિંગ મેમરી" ને "લોંગ-ટર્મ સ્ટોરેજ" થી અલગ કરે છે:
L1 Scratchpad (RAM)
- સંપૂર્ણપણે પ્રોસેસ મેમરીમાં રહે છે.
- વર્તમાન કાર્યનો સંદર્ભ (context) અને તાજેતરના ટૂલ કોલ્સ ધરાવે છે.
- રો (raw) સ્ટ્રિંગ્સ સ્ટોર કરે છે; કોઈ એમ્બેડિંગ્સ જનરેટ કરવામાં આવતા નથી.
- 3 મિલીસેકન્ડથી ઓછા સમયમાં પરિણામો આપે છે, જે CPU કેશ (cache) ની સમકક્ષ છે.
L2 Vault (SQLite-vec)
- વેક્ટર સર્ચ ક્ષમતાઓ સાથે વિસ્તૃત લોકલ SQLite ડેટાબેઝમાં અન્ય તમામ એમ્બેડિંગ્સ સાચવે છે.
- બેન્ચમાર્કમાં વપરાયેલી 14,726 મેમરીઝના સંપૂર્ણ સેટને હેન્ડલ કરે છે.
- લગભગ 94 મિલીસેકન્ડમાં મેચ આપે છે, જે ઘણા રિયલ-ટાઇમ એજન્ટ્સ માટેના 100 મિલીસેકન્ડના લક્ષ્યથી નોંધપાત્ર રીતે ઓછું છે.
- હોસ્ટ મશીનના સ્ટોરેજ સિવાય અન્ય કોઈ ખર્ચ થતો નથી.
SQLite-vec એ એક ઓપન-સોર્સ એક્સ્ટેંશન છે જે સ્ટાન્ડર્ડ રિલેશનલ ફાઇલમાં એપ્રોક્સિમેટ નિયરસ્ટ-નેબર (approximate nearest-neighbor) સર્ચ ઉમેરે છે. કારણ કે ડેટાબેઝ એજન્ટ જેવી જ મશીન પર હોય છે, તેથી કોઈ નેટવર્ક હોપ (network hop) હોતો નથી, અને એન્જિન લુકઅપ્સને ઝડપી રાખવા માટે હાલના SQLite ઇન્ડેક્સિંગ ટ્રિક્સનો ફરીથી ઉપયોગ કરે છે.
મહત્વના આંકડા
| સિસ્ટમ | મધ્યમ લેટન્સી | માસિક ખર્ચ | નોંધાયેલ વિશ્વસનીયતા |
|---|---|---|---|
| Cloud vector store (Pinecone) | 127 મિલીસેકન્ડ | ~$135 | આઉટેજ જોવા મળ્યા |
| Local SQLite-vec vault | 94 મિલીસેકન્ડ | $0 | 100% અપટાઇમ |
ખર્ચનો તફાવત દર મહિને $0 વિરુદ્ધ અંદાજે $135 છે.
વોલ્ટને વ્યવસ્થિત રાખવો
તમામ એમ્બેડિંગ્સનો કાચો ડમ્પ (raw dump) સુસંગતતા ઘટાડી શકે છે. બેન્ચમાર્કના લેખકે એક ડિકે (decay) સિસ્ટમ રજૂ કરી છે જે તાજગી (recency) અને આવૃત્તિ (frequency) દ્વારા મેમરીઝને સ્કોર કરે છે:
- નવી અથવા વારંવાર ઉપયોગમાં લેવાતી વસ્તુઓને વધુ વજન (weight) આપવામાં આવે છે.
- જે વસ્તુઓ લાંબા સમયથી ઉપયોગમાં લેવામાં આવી નથી તે ધીમે ધીમે વજન ગુમાવે છે.
- વજનયુક્ત ડિકે (weighted decay) "રીટ્રીવલ નોઈઝ" (retrieval noise)—અપ્રસ્તુત મેચ—ને 34% ઘટાડે છે.
ઓછા સ્કોર ધરાવતી એન્ટ્રીઓને દૂર કરીને અથવા ઇન્ડેક્સમાં તેમનું મહત્વ ઘટાડીને, એજન્ટ સતત પ્રદર્શન માટે વોલ્ટને લિન (lean) રાખતા અપ્રચલિત (stale) ડેટાથી બચે છે.
સારાંશ
જે AI એજન્ટ્સને ટૂંકા સમયગાળામાં હજારો મેમરીઝ સાથે કામ કરવું પડતું હોય, તેમના માટે RAM-પ્રથમ સ્ક્રેચપેડ અને લોકલ SQLite-vec વોલ્ટનું જોડાણ સંપૂર્ણપણે ક્લાઉડ-આધારિત વેક્ટર સ્ટોર્સ માટે એક વ્યવહારુ વિકલ્પ છે. આ અભિગમ પ્રતિસાદ સમય ઘટાડે છે, વારંવાર થતા ક્લાઉડ ફીને દૂર કરે છે અને અવિરત સેવા આપે છે, અને સાથે સાથે અપ્રસ્તુત ડેટાને દૂર કરવાની ક્ષમતા પણ જાળવી રાખે છે. તેથી, બે-સ્તરના મોડેલને અપનાવવાથી એજન્ટ્સ વધુ ઝડપી, સસ્તા અને વધુ ભરોસાપાત્ર બની શકે છે.