Red Hat ના 219 વાસ્તવિક સત્રોના વિશ્લેષણ મુજબ, Claude Code તેના ટોકન બજેટનો ત્રણ-ચતુર્થાંશ ભાગ માત્ર કોડબેઝ વાંચવામાં જ ખર્ચ કરે છે. આ શોધ એ સામાન્ય ધારણાને ઉલટાવે છે કે AI-સંચાલિત કોડિંગ એજન્ટ્સ કોડ જનરેટ કરવામાં સમય બગાડે છે, અને તે સૂચવે છે કે ડેવલપર્સે માત્ર મોડેલની ઝડપ પર નહીં, પણ કોન્ટેક્સ્ટ-મેનેજમેન્ટ (સંદર્ભ-સંચાલન) સમસ્યા પર ધ્યાન આપવું જોઈએ.

આ દાવા પાછળનો ડેટા

Red Hat એ Anthropic ના Claude Code સાથેના 219 ઇન્ટરેક્શનનું પરીક્ષણ કર્યું અને દરેક ટર્ન દીઠ ટોકન વપરાશની ગણતરી કરી. આ સેમ્પલના આધારે, મધ્યસ્થ ટર્નમાં 75% ટોકન આસપાસના કોડ અને ડોક્યુમેન્ટેશનને ગ્રહણ કરવામાં વપરાતા હતા, જ્યારે માત્ર 25% ટોકન નવી લાઇન બનાવવા માટે વપરાતા હતા. મોટાભાગના AI પ્રોવાઇડર્સ ઇનપુટ અને આઉટપુટ ટોકન્સ માટે સમાન દરે બિલ કરે છે, તેથી વ્યવહારનો "વાંચવાનો" ભાગ મોટાભાગનો ખર્ચ વધારે છે.

વાંચવાનો ખર્ચ શા માટે મહત્વનો છે

ઓપ્ટિમાઇઝેશન વ્યૂહરચના

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

ખર્ચ નિયંત્રણ

જ્યારે એક AI આસિસ્ટન્ટ દરેક વિનંતી પર સમાન રિપોઝિટરી સ્ટેટને ફરીથી વાંચે છે, ત્યારે ઇનપુટ ટોકન્સમાં મોટો વધારો થાય છે. મોટા કોન્ટેક્સ્ટ વિન્ડોઝ ધરાવતા પ્રોજેક્ટ્સમાં, ભલે જનરેટ થયેલા કોડનું પ્રમાણ મધ્યમ હોય, તેમ છતાં તેમના બિલમાં મોટો વધારો થઈ શકે છે.

એન્જિનિયરિંગ ફોકસ

ટૂલ બનાવનારાઓ ઘણીવાર પ્રોમ્પ્ટ્સ કેવી રીતે બનાવવામાં આવે છે તેના પર ધ્યાન આપવાને બદલે ઉચ્ચ મોડેલ ગુણવત્તા પાછળ દોડે છે. આ વિશ્લેષણ સૂચવે છે કે "કોન્ટેક્સ્ટ એન્જિનિયરિંગ" – એટલે કે મોડેલને આપવામાં આવતા કોડને ટ્રીમ (કાપવો), કેશ (સંગ્રહિત કરવો) અને તેનો સારાંશ બનાવવો – તે મોડેલના ક્રમિક અપગ્રેડ કરતા વધુ મોટો ROI (પરિણામ) આપે છે.

વાંચવાના ઓવરહેડને ઘટાડવા માટેના વ્યવહારિક પગલાં

  • બિનજરૂરી ફાઇલો દૂર કરો – પ્રોમ્પ્ટમાંથી એવી ફાઇલો દૂર કરો જે વર્તમાન કાર્ય માટે જરૂરી નથી. નાના પ્રોમ્પ્ટનો અર્થ છે ઓછા ઇનપુટ ટોકન્સ.
  • વારંવારના રીડ્સને કેશ કરો – કોડબેઝના સ્થિર ભાગોના મોડેલના અર્થઘટનને સંગ્રહિત કરો અને સમાન ટેક્સ્ટ ફરીથી મોકલવાને બદલે તેને દરેક ટર્નમાં ફરીથી ઉપયોગમાં લો.
  • ટૂલ આઉટપુટને કોમ્પ્રેસ કરો – જ્યારે બાહ્ય ટૂલ્સ મોટા બ્લોબ (દા.ત., લિન્ટ રિપોર્ટ્સ) રિટર્ન કરે છે, ત્યારે તેને Claude ને પાછા મોકલતા પહેલા તેનો સારાંશ બનાવો.
  • ઇન્ક્રીમેન્ટલ ડિફ્સનો ઉપયોગ કરો – આખી ફાઇલ સામગ્રી મોકલવાને બદલે છેલ્લા ટર્નથી થયેલા ફેરફારો જ મોકલો.

આ તકનીકોનો હેતુ AI ને દરેક ઇન્ટરેક્શન પર સમાન રિપોઝિટરી સ્નેપશોટ ફરીથી વાંચતા રોકવાનો છે, જેનાથી લેટન્સી (વિલંબ) અને ખર્ચ બંનેમાં ઘટાડો થાય છે.

વિરોધી દલીલ: ઝડપ હજુ પણ મહત્વની છે

કેટલાક ડેવલપર્સ દલીલ કરે છે કે ઝડપી મોડેલ હજુ પણ મહત્વનું છે કારણ કે તે તે 25% ટોકન્સની લેટન્સી ઘટાડે છે જે જનરેટ થાય છે. લેટન્સી-સેન્સિટિવ વાતાવરણમાં—જેમ કે IDE પ્લગિન્સ જે તરત જ પ્રતિસાદ આપવા જોઈએ—દરેક મિલિસેકન્ડ મહત્વની છે. વાંચન-પ્રધાન પ્રોફાઇલ ઝડપી મોડેલના ફાયદાને નાબૂદ કરતી નથી; તે ફક્ત તેની સાપેક્ષ અસર ઘટાડે છે.

આગળ શું જોવું

Red Hat નો અભ્યાસ મર્યાદિત સત્રો પર આધારિત છે, તેથી વ્યાપક સેમ્પલિંગ અન્ય ભાષાઓ અથવા પ્રોજેક્ટના કદ માટે અલગ ટોકન વિતરણ પ્રગટ કરી શકે છે. જો ભવિષ્યનો ડેટા 75% વાંચવાના આંકડાની પુષ્ટિ કરે છે, તો આપણે આપમેળે કોન્ટેક્સ્ટને ટ્રીમ અને કેશ કરતા ટૂલ્સ તરફ, અથવા ઝડપી કોન્ટેક્સ્ટ ઇન્જેસ્ટિયન માટે ટ્યુન કરેલા મોડેલ આર્કિટેક્ચર તરફ ફેરફાર જોઈ શકીએ છીએ.

સારાંશ: AI-સહાયિત કોડિંગ માટે, સૌથી સસ્તો પર્ફોર્મન્સ ગેઇન મોડેલને ઝડપથી લખવા માટે કહેવાથી નહીં, પરંતુ તેને ઓછું ફીડ કરવાથી મળે છે. Red Hat ના આંકડા સ્પષ્ટ કેસ રજૂ કરે છે: તમારા પ્રોમ્પ્ટ્સને ટ્રીમ કરો, કેશ કરો અને તેનો સારાંશ બનાવો, અને તમે સમય અને નાણાં બંનેમાં મૂર્ત બચત જોશો.