તમારો LLM-સંચાલિત એજન્ટ ડેમોમાં કદાચ બરાબર ચાલે, પરંતુ થોડા જ ટર્ન પછી તે ધીમો પડી શકે છે અને તેનું બિલ વધારી શકે છે. આ પાછળનું છુપાયેલું કારણ કોઈ નબળું મોડેલ નથી—તે 'ટોકન ડ્રિફ્ટ' (token drift) છે, જે પ્રોમ્પ્ટનું ધીમે ધીમે થતું વધતું કદ છે જેને મોડેલે દર વખતે પ્રોસેસ કરવું પડે છે.

ટોકન ડ્રિફ્ટ ત્યારે થાય છે જ્યારે દરેક ઇન્ટરેક્શન મોડેલના ઇનપુટ કોન્ટેક્સ્ટમાં વધુ ટેક્સ્ટ ઉમેરે છે. વાતચીતનો ઇતિહાસ, ટૂલ સ્કીમા (tool schemas), API પ્રતિસાદો અને મેળવેલા દસ્તાવેજો બધું જ એકઠા થતું જાય છે, તેથી દરેક પછીના કોલ સાથે મોટો પેલોડ (payload) જાય છે. કારણ કે ઇનપુટ ટોકન્સની સંખ્યા સાથે મોડેલનો પ્રોસેસિંગ સમય અને કિંમત વધે છે, તેથી ખર્ચ રેખીય (linearly) ને બદલે ક્વાડ્રેટિકલી (quadratically) વધે છે.

સમસ્યા ડેમોમાં નહીં, પણ પ્રોડક્શનમાં કેમ દેખાય છે

વાસ્તવિક ડિપ્લોયમેન્ટ્સ બધું જ સાચવે છે: વપરાશકર્તાનું દરેક વાક્ય, દરેક ટૂલ આઉટપુટ, મેળવેલી માહિતીનો દરેક ભાગ. જ્યાં સુધી લેટન્સી (latency) વધતી નથી અને ઇનવોઇસ નથી આવતું ત્યાં સુધી આ એકત્રીકરણ છુપાયેલું રહે છે.

ટોકન ડ્રિફ્ટના સામાન્ય સ્ત્રોતો

  • પુનરાવર્તિત ટ્રાન્સક્રિપ્ટ્સ – જૂના સંદેશાઓનો સારાંશ કાઢવા અથવા તેને કાઢી નાખવાને બદલે પ્રોમ્પ્ટમાં દરેક જૂનો સંદેશ રાખવો.
  • ભારે ટૂલ સ્કીમા – દરેક ટર્ન પર ટૂલની ક્ષમતાઓની મોટી JSON વ્યાખ્યાઓ મોકલવી.
  • ભારે ટૂલ પરિણામો – સંપૂર્ણ API પ્રતિસાદો અથવા ડેટાબેઝ રો (rows) શામેલ કરવા જેમાં એજન્ટને ખરેખર જરૂર હોય તેના કરતા વધુ ડેટા હોય.
  • RAG બ્લોટ – રિટ્રીવલ-ઓગમેન્ટેડ જનરેશન (RAG) જે ઘણા દસ્તાવેજોના ટુકડાઓ ઉમેરે છે, જેમાંથી કેટલાક જૂના અથવા અપ્રસ્તુત હોય છે.
  • ડુપ્લીકેટેડ મેમરી – સારાંશ, સ્ટેટ ઓબ્જેક્ટ અને કાચો ટ્રાન્સક્રિપ્ટ એકસાથે પેક કરવો, જે એક જ માહિતી ત્રણ વાર પુનરાવર્તિત કરે છે.

આમાંનું દરેક એવા ટોકન્સ ઉમેરે છે જે નવી તર્કશક્તિ (reasoning power) માં ફાળો આપતા નથી, છતાં તેઓ પ્રોમ્પ્ટનું કદ વધારી દે છે.

ટોકન બજેટને નિયંત્રણમાં કેવી રીતે રાખવું

1. લેયર્ડ કોન્ટેક્સ્ટ ડિઝાઇન અપનાવો

  • સ્થિર સૂચનાઓ – સિસ્ટમ પ્રોમ્પ્ટ્સ અને સુરક્ષા નિયમોને ઉપર રાખો અને દરેક ટર્ન પર તેમને ફરીથી મોકલવાને બદલે તેનો સંદર્ભ (reference) આપો.
  • સ્ટ્રક્ચર્ડ સ્ટેટ – લક્ષ્યો, નિર્ણયો અને ઓળખકર્તાઓની (identifiers) સંક્ષિપ્ત રજૂઆત સ્ટોર કરો જે એજન્ટ ઝડપથી વાંચી શકે.
  • કોમ્પ્રેસ્ડ હિસ્ટ્રી – જૂના ટર્ન્સનો ટૂંકા, માનવ-વાચ્ય ફકરામાં સારાંશ બનાવો, અને જ્યારે કોઈ મર્યાદા (threshold) વટાવી જાય ત્યારે જ તેને અપડેટ કરો.
  • તાજેતરના ટર્ન્સ – સાતત્ય જાળવી રાખવા માટે છેલ્લા કેટલાક સંદેશાઓ શબ્દશઃ (verbatim) શામેલ કરો.

સ્થિર ટેક્સ્ટને સારાંશ આપી શકાય તેવા કન્ટેન્ટથી અલગ રાખવાથી તમે વારંવાર એ જ શબ્દો ફરીથી મોકલવાનું ટાળી શકશો.

2. ટૂલ આઉટપુટને ટ્રીમ કરો

  • એજન્ટ ખરેખર જે ફીલ્ડ્સનો ઉપયોગ કરે છે તે જ કાઢો; લાંબા વર્ણનોને કાઢી નાખો.
  • મોટા પરિણામોને સંક્ષિપ્ત સારાંશ અથવા રેફરન્સ ID સાથે બદલો, અને સંપૂર્ણ પેલોડને ડેટાબેઝ, કેશ અથવા બ્લોબ સ્ટોરમાં સ્ટોર કરો.
  • જ્યારે કોઈ ટૂલ લિસ્ટ રિટર્ન કરે, ત્યારે ફક્ત તે ટોપ-N આઇટમ્સ મોકલો જે વર્તમાન નિર્ણય માટે મહત્વપૂર્ણ હોય.

3. સ્માર્ટ સમરાઇઝેશન લાગુ કરો

  • દરેક ટર્ન પછી સારાંશ બનાવવાનું ટાળો; વધારાની પ્રોસેસિંગથી ઓવરહેડ વધે છે.
  • જ્યારે જૂના ટર્ન્સની એકત્રિત ટોકન સંખ્યા પૂર્વ-નિર્ધારિત મર્યાદા ઓળંગે ત્યારે જ સારાંશને રિફ્રેશ કરો.
  • મહત્વપૂર્ણ તથ્યો—IDs, રકમ, ટાઇમસ્ટેમ્પ—ને ગદ્યમાં (prose) સમાવવાને બદલે સ્ટ્રક્ચર્ડ સ્ટોરમાં રાખો, જેથી સારાંશ ટૂંકો રહે.

4. યોગ્ય મેટ્રિક્સ ટ્રેક કરો

  • ટોકન વપરાશને માત્ર યુઝર રિક્વેસ્ટ દીઠ નહીં, પણ દરેક મોડેલ કોલ દીઠ લોગ કરો. આ ઇનપુટ બાજુએ થતા છુપાયેલા વધારાને દર્શાવે છે.
  • દરેક ટર્નમાં ઉમેરાતા ઇનપુટ ટોકન્સની સંખ્યા પર નજર રાખો; અચાનક વધારો ડ્રિફ્ટના સ્ત્રોત તરફ નિર્દેશ કરે છે.
  • કેશ્ડ ટોકન્સ (અગાઉના કોલ્સમાંથી ફરીથી ઉપયોગમાં લેવાયેલા) ને નવા જનરેટ થયેલા ટોકન્સથી અલગ કરો; માત્ર પહેલા પ્રકારના ટોકન્સ જ ડ્રિફ્ટ માટે જવાબદાર છે.

પ્રોમ્પ્ટને અનંત ટ્રાન્સક્રિપ્ટ તરીકે નહીં, પણ એક મર્યાદિત સંસાધન તરીકે ગણો. જાણીજોઈને માપન કરીને, સારાંશ બનાવીને અને ટ્રીમ કરીને, તમે તમારા LLM એજન્ટને ઝડપી, સસ્તો અને પ્રોડક્શન સ્કેલ માટે તૈયાર રાખી શકો છો.

મુખ્ય વાત: ટોકન ડ્રિફ્ટ છૂપી રીતે ખર્ચ વધારે છે અને એજન્ટ્સને ધીમા પાડે છે. તમારા પ્રોમ્પ્ટના વધતા જતા ભાગોને ઓળખો, તેમને કોમ્પ્રેસ કરો અથવા એક્સટર્નલાઇઝ કરો, અને દરેક કોલ દીઠ ટોકન વપરાશ પર નજર રાખો. એક શિસ્તબદ્ધ અભિગમ અણધાર્યા બિલના આંચકાને વ્યવસ્થિત અને બજેટ-અનુકૂળ કામગીરીમાં બદલી શકે છે.