મને લાગ્યું કે હું ખૂબ ચતુર બની રહ્યો છું. મેં એક એવું હેલ્પર ફંક્શન લખ્યું હતું જે અમારા AI પાઇપલાઇન માટે કોન્ટેક્સ્ટ વિન્ડોના બરાબર ત્રીસ ટકા ભાગને વિચારવા માટેના બજેટ (thinking budget) તરીકે અનામત રાખતું હતું. તે સ્વચ્છ, અનુમાનિત હતું અને Opus 4.5 પર તે સુંદર રીતે કામ કરતું હતું. પછી મેં Opus 4.8 પર સ્વિચ કર્યું અને દરેક સિંગલ રિક્વેસ્ટ 400 એરર સાથે ફેલ થઈ ગઈ. મારું કાળજીપૂર્વક તૈયાર કરેલું ટોકન મેથ (token math) રાતોરાત કચરો બની ગયું.
જૂની પદ્ધતિ સરળ હતી. તમે budget_tokens ની કિંમત સેટ કરો છો અને મોડેલ તે મર્યાદામાં રહેવા માટે તેના વિચારવાની પ્રક્રિયાને વહેંચી દે છે. જો હું 128K કોન્ટેક્સ્ટ આપું, તો મારું કોડ રિઝનિંગ માટે અંદાજે 38,000 ટોકન્સ અલગ પાડશે અને બાકીના જવાબ માટે છોડી દેશે. તે જવાબદારીપૂર્ણ લાગતું હતું. જેમ કે કારને સ્પીડ લિમિટની અંદર રાખવી.
તે મોડેલ હવે નથી. Opus 4.7 અને 4.8 જેવા નવા રિલીઝ એડેપ્ટિવ થિંકિંગ (adaptive thinking) નો ઉપયોગ કરે છે. હવે તમે કોઈ નંબર પસંદ નથી કરતા. તેના બદલે, તમે એક એફર્ટ નોબ (effort knob) પાસ કરો છો. આ માત્ર નામ બદલવા જેવું લાગે છે, પરંતુ આ બંને કંટ્રોલ્સ એકબીજાથી સાવ અલગ છે. budget_tokens એ મોડેલને કેટલું વિચારવાની મંજૂરી છે તેના પર એક કડક મર્યાદા નક્કી કરતું હતું. એફર્ટ એ મોડેલ કેવી રીતે વિચારે છે અને કેવી રીતે કાર્ય કરે છે તે નિયંત્રિત કરે છે. એક ગેસ પંપ મીટર છે, જ્યારે બીજું એન્જિન મેપ છે.
એફર્ટને વાસ્તવિક કામ સાથે મેપ કરવું
જ્યારે કંટ્રોલ બદલાયો, ત્યારે મારી જૂની સમજણ કામ કરવાનું બંધ કરી દીધી. મારે ફરીથી શીખવું પડ્યું કે દરેક સેટિંગ ખરેખર શું આપે છે. દરેક એફર્ટ લેવલ વ્યવહારમાં ક્યાં પહોંચે છે તે જાણવા માટે મેં અમારા ઇન્ટરનલ ટ્રાફિક પર ટેસ્ટ કર્યા.
Classification and routing માટે લગભગ હંમેશા low એફર્ટનો ઉપયોગ કરવો જોઈએ. આ કામ ઝડપી નિર્ણયો લેવાના છે. શું આ રિફંડ વિનંતી છે કે વેચાણનો પ્રશ્ન? શું આ લોગ એન્ટ્રીમાં એસ્કેલેશનની જરૂર છે? તમારે લાંબા સંવાદની જરૂર નથી. લો એફર્ટ લેટન્સી (latency) ઘટાડે છે અને ખર્ચ પણ નહિવત રાખે છે.
મોટાભાગનું એપ ટ્રાફિક, જે રોજિંદા સમરીઝ, રીરાઈટ્સ, સપોર્ટ રિપ્લાય અને કન્ટેન્ટ એક્સટ્રેક્શનનું કામ છે, તે medium થી high એફર્ટમાં ફિટ થાય છે. આ સંતુલન બિંદુ છે. મોડેલને એવા કામ માટે ટોકન્સ બગાડ્યા વગર વાસ્તવિક અસ્પષ્ટતા ઉકેલવા માટે પૂરતી જગ્યા મળે છે જેને લાંબા વિચાર પ્રવાહની (chain of thought) જરૂર નથી.
Coding and agentic loops માટે xhigh એફર્ટની જરૂર છે. અહીં ભૂલો વધી શકે છે. જો મોડેલ ટૂલ-કોલિંગ લૂપના પ્રથમ રાઉન્ડમાં ખરાબ પ્લાન લખે છે, તો તે પછીના ત્રણ સ્ટેપ્સ નુકસાન સુધારવામાં વિતાવી દેશે. અથવા તો તેનાથી પણ ખરાબ, તે ખોટા ટૂલ્સનો ઉપયોગ કરશે, પેરામીટર્સ હેલ્યુસિનેટ (hallucinate) કરશે, અને યુઝરને બગડેલા વર્કફ્લો સામે જોતા મૂકી દેશે. શરૂઆતમાં સારું રિઝનિંગ તે વિષમ પરિસ્થિતિને અટકાવે છે.
Critical tasks માટે max એફર્ટ હોવું જોઈએ. આનો ઉપયોગ બધી વસ્તુઓ માટે કરશો નહીં. તેને એવા ક્ષણો માટે અનામત રાખો જ્યાં ખોટો જવાબ કોઈપણ ટોકન બિલ કરતા વધુ ખર્ચાળ હોય. ફાઇનાન્શિયલ રિકોન્સિલિયેશન, સેફ્ટી ચેક્સ, આર્કિટેક્ચર નિર્ણયો અને મેડિકલ ટ્રાયજ (medical triage) એ આ માટે યોગ્ય છે. જો ભૂલનો અર્થ એ હોય કે માણસે કલાકો સુધી ગડબડ ઉકેલવી પડે, તો વધારાના વિચારિંગ માટે ચૂકવણી કરો.
ખર્ચનું આશ્ચર્ય
અહીં એ ભાગ છે જેણે મારા માનસિક મોડેલને તોડી નાખ્યું. મેં ધાર્યું હતું કે મેક્સ એફર્ટ હંમેશા મારા ખર્ચમાં વધારો કરશે. એક સિંગલ ટર્ન પર, તે કરે છે. રિઝનિંગ ટ્રેસ (reasoning trace) લાંબો હોય છે. પરંતુ મલ્ટી-સ્ટેપ એજન્ટિક ટાસ્ક પર, કુલ બિલ ઘણીવાર ઘટી ગયું.
મોડેલ પ્રથમ પ્રયાસમાં જ વધુ સારી રીતે પ્લાન બનાવે છે. તે ઓછા ટૂલ કોલ્સ કરે છે. તે પોતાને ખોટા રસ્તે જતાં અટકાવે છે. મેં એક ડેટા એક્સટ્રેક્શન એજન્ટ જોયો જે સામાન્ય રીતે પાંચ વાર આગળ-પાછળના ટર્ન લેતો હતો, તે માત્ર બે ટર્નમાં પૂર્ણ થયો કારણ કે મોડેલ પાસે શરૂઆતમાં જ સ્કીમાને યોગ્ય રીતે પાર્સ કરવા માટે પૂરતું રિઝનિંગ રૂમ હતું. જ્યારે તમે ખર્ચ માપો છો, ત્યારે વિનંતી (request) ને બદલે કામની પૂર્ણાહુતિ (job completion) જુઓ. દરેક સ્ટેપ દીઠ મોટું વિચારિંગ બજેટ એટલે કે કુલ સ્ટેપ્સમાં ઘટાડો થઈ શકે છે.
બાકીની બધી વસ્તુઓ બગાડ્યા વગર કેવી રીતે માઈગ્રેટ કરવું
જો તમારા કોડબેઝમાં હજુ પણ budget_tokens વપરાતું હોય, તો બહાર નીકળવાનો ચોક્કસ રસ્તો અહીં છે. સ્ટેપ ત્રણ અને પાંચ છોડશો નહીં. મેં છોડ્યા હતા, અને તેના કારણે મારો આખું બપોર ડિબગિંગમાં જતો રહ્યો.
તમારા કોડમાં budget_tokens શોધો. દરેક ઇન્સ્ટન્સ દૂર કરવો પડશે. નવા મોડેલ્સમાં આ પેરામીટર હવે કામ કરતું નથી અને તે 400 એરર આપશે.
બજેટ ઓબ્જેક્ટને એડેપ્ટિવ થિંકિંગ બ્લોક સાથે બદલો. thinking: { type: "adaptive" } નો ઉપયોગ કરો.
દરેક કોલ માટે સ્પષ્ટ એફર્ટ લેવલ સાથે output_config ઉમેરો. જો તમારો ટ્રાફિક મિશ્રિત હોય, તો આને ગ્લોબલ ડિફોલ્ટ પર છોડી ન દો. તમારા લાઇટવેઇટ ક્લાસિફિકેશન એન્ડપોઇન્ટને ભૂલથી તમારા કોડિંગ એજન્ટ જેવું જ એફર્ટ સેટિંગ વારસામાં મળવું જોઈએ નહીં. કોલ સાઇટ પર સ્પષ્ટ રહો.
તમારા બજેટ કેલ્ક્યુલેશન હેલ્પરને ડિલીટ કરો. મને ખબર છે. કદાચ તેમાં યુનિટ ટેસ્ટ હશે. મારામાં હતા. પરંતુ તે હવે નકામું છે. પ્લેટફોર્મને તમારા ટોકન મેથની જરૂર નથી. મોડેલ તેની પોતાની ગતિ જાતે સંભાળે છે.
temperature, top_p, અને top_k ને દૂર કરો. Opus 4.7 અને 4.8 પર, આ સેમ્પલિંગ પેરામીટર્સ 400 એરર આપશે. પ્લેટફોર્મે આ જનરેશનમાંથી તેને દૂર કર્યા છે. તમારી જૂની ટેમ્પરેચર-ટ્યુનિંગ ટ્રિક્સ અહીં લાગુ પડશે નહીં, અને તેને રાખવાથી તમારું માઇગ્રેશન શાંતિથી બગડી જશે.
દરેક મોડેલનું વ્યક્તિગત રીતે પરીક્ષણ કરો. Opus 4.5 અને 4.8 એકબીજાથી તદ્દન અલગ છે. એક પર કામ કરે તેવું કોન્ફિગરેશન બીજા પર જરૂરી નથી કે કામ કરે. જો તમે મલ્ટીપલ વર્ઝનને સપોર્ટ કરો છો, તો તમારા લોજિકને અલગ કરો અથવા તેને અલગ બેકએન્ડ્સ તરીકે ગણો.
UI ફ્રીઝ (Freeze) ને ઠીક કરવું
એક સ્ટ્રીમિંગ બિહેવિયર છે જે જો તમે તેને હેન્ડલ નહીં કરો તો તમારા યુઝર્સને મૂંઝવણમાં મૂકી દેશે. નવા મોડેલ્સમાં, thinking blocks સ્ટ્રીમ થાય છે પરંતુ ડિફોલ્ટ રીતે ટેક્સ્ટ ખાલી હોય છે. તમારા ઇન્ટરફેસમાં, આ કોઈ દેખીતી પ્રગતિ વગરના લાંબા, અજીબ વિરામ જેવું લાગશે. યુઝર્સને લાગશે કે એપ હેંગ થઈ ગઈ છે.
તેને ઠીક કરવા માટે, thinking: { type: "adaptive", display: "summarized" } પાસ કરો. આનાથી ચેટ વિન્ડોમાં કાચો thought stream ડમ્પ કર્યા વગર તમને એક દેખીતો પ્રોગ્રેસ ઇન્ડિકેટર મળશે. તમારું ફ્રન્ટએન્ડ રિસ્પોન્સિવ રહેશે અને તમારા યુઝર્સને ખબર પડશે કે અંદર કંઈક પ્રક્રિયા ચાલી રહી છે.
સાચો પાઠ
મેં એક એવા પેરામીટર પર આખું એબ્સ્ટ્રેક્શન લેયર બનાવ્યું હતું જે વેન્ડર ક્યારેય લાંબા સમય સુધી રાખવા માંગતા નહોતા. મેં તેમની સેટિંગ્સને મારા પોતાના લોજિકમાં લપેટી દીધી હતી કારણ કે મને લાગ્યું કે હું પ્લેટફોર્મ કરતા ટ્રેડઓફને વધુ સારી રીતે સમજું છું. પણ હું ખોટો હતો. એડેપ્ટિવ થિંકિંગ વધુ સારો વિકલ્પ છે કારણ કે મોડેલ પોતે નક્કી કરે છે કે તેને ક્યારે વધુ તર્ક કરવાની જરૂર છે અને ક્યારે તે સામાન્ય રીતે કામ કરી શકે છે. હવે મારો કોડબેઝ નાનો છે. પરિણામો વધુ સચોટ બન્યા છે. ક્યારેક સાચું એન્જિનિયરિંગ પગલું એ છે કે ચતુર કોડને ડિલીટ કરી દેવો અને પ્લેટફોર્મને તેનું કામ કરવા દેવું.
જો તમે મૂળ માઇગ્રેશન નોટ્સ વાંચવા માંગતા હોવ, તો તમે તેને અહીં શોધી શકો છો. આ પ્રકારની વધુ પ્રેક્ટિકલ ચર્ચાઓ માટે, Telegram પર GyaanSetu AI કોમ્યુનિટી માં જોડાવો.