ഞാൻ വലിയ ബുദ്ധിമാനാണെന്ന് ഞാൻ കരുതി. നമ്മുടെ AI പൈപ്പ്ലൈനായി കൺടെക്സ്റ്റ് വിൻഡോയുടെ (context window) കൃത്യം മുപ്പത് ശതമാനം ഒരു തിങ്കിംഗ് ബജറ്റായി (thinking budget) മാറ്റിവെക്കുന്ന ഒരു ഹെൽപ്പർ ഫംഗ്ഷൻ ഞാൻ എഴുതിയിരുന്നു. അത് വളരെ വൃത്തിയുള്ളതും പ്രവചിക്കാവുന്നതും Opus 4.5-ൽ മനോഹരമായി പ്രവർത്തിക്കുന്നതുമായിരുന്നു. എന്നാൽ ഞാൻ Opus 4.8-ലേക്ക് മാറിയപ്പോൾ, ഓരോ റിക്വസ്റ്റും 400 എററോടെ പരാജയപ്പെട്ടു. ഞാൻ വളരെ ശ്രദ്ധയോടെ തയ്യാറാക്കിയ ടോക്കൺ കണക്കുകൾ ഒറ്റരാത്രികൊണ്ട് പാഴായിപ്പോയി.
പഴയ രീതി ലളിതമായിരുന്നു. നിങ്ങൾ ഒരു budget_tokens മൂല്യം നിശ്ചയിക്കുന്നു, മോഡൽ ആ പരിധിക്കുള്ളിൽ നിൽക്കാൻ അതിന്റെ ചിന്താപ്രക്രിയയെ (thinking) ക്രമീകരിക്കുന്നു. ഞാൻ ഒരു 128K കൺടെക്സ്റ്റ് നൽകിയാൽ, എന്റെ കോഡ് റീസണിംഗിനായി ഏകദേശം 38,000 ടോക്കണുകൾ മാറ്റിവെക്കുകയും ബാക്കി ഉത്തരത്തിനായി വിട്ടുകൊടുക്കുകയും ചെയ്യും. ഒരു കാർ സ്പീഡ് ലിമിറ്റിന് താഴെയായി ഓടിക്കുന്നത് പോലെ, അത് ഉത്തരവാദിത്തമുള്ള ഒരു രീതിയായിരുന്നു.
ആ മോഡൽ ഇപ്പോൾ പഴയതാണ്. Opus 4.7, 4.8 പോലുള്ള പുതിയ പതിപ്പുകൾ അഡാപ്റ്റീവ് തിങ്കിംഗ് (adaptive thinking) ആണ് ഉപയോഗിക്കുന്നത്. നിങ്ങൾ ഇനി ഒരു നമ്പർ തിരഞ്ഞെടുക്കേണ്ടതില്ല. പകരം, ഒരു 'എഫർട്ട് നോബ്' (effort knob) ആണ് നൽകേണ്ടത്. ഇത് വെറുമൊരു പേര് മാറ്റം മാത്രമാണെന്ന് തോന്നാം, എന്നാൽ ഈ രണ്ട് നിയന്ത്രണങ്ങളും തമ്മിൽ വലിയ വ്യത്യാസമുണ്ട്. budget_tokens എന്നത് മോഡലിന് എത്രത്തോളം ചിന്തിക്കാൻ അനുവാദമുണ്ട് എന്നതിനെക്കുറിച്ച് ഒരു കടുത്ത പരിധി നിശ്ചയിച്ചു. എന്നാൽ 'എഫർട്ട്' എന്നത് മോഡൽ എങ്ങനെ ചിന്തിക്കുന്നു എന്നും പ്രവർത്തിക്കുന്നു എന്നും തീരുമാനിക്കുന്നു. ഒന്ന് ഗ്യാസ് പമ്പ് മീറ്റർ പോലെയാണ്, മറ്റൊന്ന് എഞ്ചിൻ മാപ്പ് പോലെയാണ്.
പ്രയത്നത്തെ (Effort) യഥാർത്ഥ ജോലികളുമായി ബന്ധിപ്പിക്കുമ്പോൾ
നിയന്ത്രണം മാറിയപ്പോൾ, എന്റെ പഴയ ധാരണകൾ ഫലിച്ചില്ല. ഓരോ സെറ്റിംഗും യഥാർത്ഥത്തിൽ എന്ത് ഫലമാണ് നൽകുന്നതെന്ന് എനിക്ക് വീണ്ടും പഠിക്കേണ്ടി വന്നു. ഓരോ എഫർട്ട് ലെവലും പ്രായോഗികമായി എവിടെയാണ് ഉപയോഗിക്കേണ്ടതെന്ന് കണ്ടെത്താൻ ഞങ്ങളുടെ ഇന്റേണൽ ട്രാഫിക്കിലൂടെ ഞാൻ പരീക്ഷണങ്ങൾ നടത്തി.
ക്ലാസിഫിക്കേഷനും റൗട്ടിംഗും (Classification and routing) മിക്കവാറും എപ്പോഴും low എഫർട്ട് ഉപയോഗിക്കണം. ഇവ വേഗത്തിൽ തീരുമാനമെടുക്കേണ്ട ജോലികളാണ്. ഇതൊരു റീഫണ്ട് റിക്വസ്റ്റ് ആണോ അതോ ഒരു സെയിൽസ് ചോദ്യമാണോ? ഈ ലോഗ് എൻട്രി എസ്കലേഷൻ ആവശ്യമാണോ? ഇതിന് വലിയൊരു സംസാരം ആവശ്യമില്ല. low എഫർട്ട് ഉപയോഗിക്കുന്നത് ലേറ്റൻസി കുറയ്ക്കാനും ചെലവ് വളരെ കുറഞ്ഞതാക്കാനും സഹായിക്കുന്നു.
മിക്ക ആപ്പ് ട്രാഫിക്കും (Most app traffic) — അതായത് സംഗ്രഹങ്ങൾ (summaries), പുനരാവിഷ്കാരങ്ങൾ (rewrites), സപ്പോർട്ട് മറുപടികൾ, കണ്ടന്റ് എക്സ്ട്രാക്ഷൻ തുടങ്ങിയ ദൈനംദിന ജോലികൾ — medium മുതൽ high എഫർട്ട് വരെ ഉപയോഗിക്കാം. ഇതാണ് സന്തുലിതാവസ്ഥ നിലനിർത്തുന്ന പോയിന്റ്. അമിതമായി ടോക്കണുകൾ ചിലവാക്കാതെ തന്നെ, സങ്കീർണ്ണമായ കാര്യങ്ങൾ പരിഹരിക്കാൻ ആവശ്യമായ ഇടം മോഡലിന് ഇതിലൂടെ ലഭിക്കുന്നു.
കോഡിംഗും ഏജന്റിക് ലൂപ്പുകളും (Coding and agentic loops) xhigh എഫർട്ട് ആവശ്യപ്പെടുന്നു. ഇവിടെയാണ് തെറ്റുകൾ സംഭവിക്കാൻ സാധ്യത കൂടുതൽ. ഒരു ടൂൾ-കോളിംഗ് ലൂപ്പിന്റെ ആദ്യ ഘട്ടത്തിൽ മോഡൽ ഒരു മോശം പ്ലാൻ തയ്യാറാക്കിയാൽ, അടുത്ത മൂന്ന് ഘട്ടങ്ങൾ ആ തെറ്റ് തിരുത്താൻ തന്നെ അത് ചിലവാക്കും. അല്ലെങ്കിൽ മോഡൽ തെറ്റായ ടൂളുകൾ വിളിച്ചേക്കാം, തെറ്റായ പാരാമീറ്ററുകൾ നൽകിയേക്കാം, ഇത് ഉപയോക്താവിന് തകരാറിലായ ഒരു വർക്ക്ഫ്ലോ നൽകുന്നതിലേക്ക് നയിച്ചേക്കാം. തുടക്കത്തിൽ തന്നെ മികച്ച റീസണിംഗ് ഉണ്ടെങ്കിൽ ഇത്തരം പ്രശ്നങ്ങൾ ഒഴിവാക്കാം.
അതിപ്രധാനമായ ജോലികൾ (Critical tasks) max എഫർട്ട് ഉപയോഗിക്കണം. ഇത് എല്ലാ കാര്യങ്ങൾക്കും ഉപയോഗിക്കരുത്. ഒരു തെറ്റായ ഉത്തരം നൽകുന്നത് ടോക്കൺ ബില്ലിനേക്കാൾ വലിയ നഷ്ടമുണ്ടാക്കുന്ന സാഹചര്യങ്ങളിൽ മാത്രം ഇത് ഉപയോഗിക്കുക. സാമ്പത്തികമായ കണക്കുകൾ ഒത്തുനോക്കൽ (Financial reconciliations), സുരക്ഷാ പരിശോധനകൾ, ആർക്കിടെക്ചർ തീരുമാനങ്ങൾ, മെഡിക്കൽ ട്രയാജ് എന്നിവ ഇതിന് അനുയോജ്യമാണ്. ഒരു തെറ്റ് സംഭവിച്ചാൽ ഒരു മനുഷ്യൻ മണിക്കൂറുകളോളം കഷ്ടപ്പെട്ട് അത് പരിഹരിക്കേണ്ടി വരുമെങ്കിൽ, കൂടുതൽ ചിന്തിക്കുന്നതിനായി പണം ചിലവാക്കുന്നത് ലാഭകരമാണ്.
ചെലവിലെ അപ്രതീക്ഷിത മാറ്റം
എന്റെ ചിന്താഗതിയെ മാറ്റിമറിച്ച ഭാഗം ഇതാണ്. max എഫർട്ട് ഉപയോഗിക്കുമ്പോൾ ചെലവ് എപ്പോഴും കൂടുമെന്നാണ് ഞാൻ കരുതിയത്. ഒരു സിംഗിൾ ടേണിൽ അത് ശരിയാണ്, റീസണിംഗ് ട്രേസ് കൂടുതൽ നീളമുള്ളതായിരിക്കും. എന്നാൽ മൾട്ടി-സ്റ്റെപ്പ് ഏജന്റിക് ടാസ്ക്കുകളിൽ (multi-step agentic tasks), ആകെ വരുന്ന ബില്ല് പലപ്പോഴും കുറയുകയാണ് ചെയ്യുന്നത്.
ആദ്യ ശ്രമത്തിൽ തന്നെ മോഡൽ മികച്ച രീതിയിൽ പ്ലാൻ ചെയ്യുന്നു. ഇത് കുറഞ്ഞ ടൂൾ കോളുകൾ മാത്രമേ നടത്തുന്നുള്ളൂ. തെറ്റായ വഴികളിലേക്ക് പോകുന്നത് ഇത് തടയുന്നു. സാധാരണ അഞ്ച് തവണകളെടുത്ത് തീർക്കുന്ന ഒരു ഡാറ്റാ എക്സ്ട്രാക്ഷൻ ഏജന്റ്, വെറും രണ്ട് തവണയിൽ തന്നെ ജോലി പൂർത്തിയാക്കുന്നത് ഞാൻ കണ്ടു; കാരണം തുടക്കത്തിൽ തന്നെ സ്കീമ കൃത്യമായി മനസ്സിലാക്കാൻ മോഡലിന് ആവശ്യമായ റീസണിംഗ് റൂം ലഭിച്ചിരുന്നു. നിങ്ങൾ ചെലവ് കണക്കാക്കുമ്പോൾ, ഓരോ റിക്വസ്റ്റും നോക്കുന്നതിന് പകരം ജോലി പൂർത്തിയാകുന്നത് എങ്ങനെ എന്ന് നോക്കുക. ഓരോ ഘട്ടത്തിലും വലിയൊരു തിങ്കിംഗ് ബജറ്റ് ഉണ്ടെങ്കിൽ, ആകെ വേണ്ട ഘട്ടങ്ങളുടെ എണ്ണം കുറയുന്നു.
മറ്റുള്ളവയെ ബാധിക്കാതെ എങ്ങനെ മൈഗ്രേറ്റ് ചെയ്യാം
നിങ്ങളുടെ കോഡിൽ ഇപ്പോഴും budget_tokens ഉപയോഗിക്കുന്നുണ്ടെങ്കിൽ, അത് മാറ്റാനുള്ള കൃത്യമായ വഴി ഇതാ. മൂന്നാമത്തെയും അഞ്ചാമത്തെയും ഘട്ടങ്ങൾ ഒഴിവാക്കരുത്. ഞാൻ അവ ഒഴിവാക്കിയിരുന്നു, അത് കാരണം ഒരു വൈകുന്നേരം മുഴുവൻ ഡീബഗ്ഗിംഗിനായി ചിലവഴിക്കേണ്ടി വന്നു.
നിങ്ങളുടെ കോഡിൽ budget_tokens എന്ന് തിരയുക. എല്ലാ ഇൻസ്റ്റൻസുകളും നീക്കം ചെയ്യണം. പുതിയ മോഡലുകളിൽ ഈ പാരാമീറ്റർ നിലവിലില്ല, അത് ഉപയോഗിച്ചാൽ 400 എറർ വരും.
ബജറ്റ് ഒബ്ജക്റ്റിന് പകരം ഒരു അഡാപ്റ്റീവ് തിങ്കിംഗ് ബ്ലോക്ക് ഉപയോഗിക്കുക. thinking: { type: "adaptive" } എന്ന് ഉപയോഗിക്കുക.
ഓരോ കോളിനും വ്യക്തമായ എഫർട്ട് ലെവലോട് കൂടിയ output_config ചേർക്കുക. നിങ്ങളുടെ ട്രാഫിക് പലതരം ആണെങ്കിൽ ഇത് ഒരു ഗ്ലോബൽ ഡിഫോൾട്ടിന് വിട്ടുകൊടുക്കരുത്. നിങ്ങളുടെ ലഘുവായ ക്ലാസിഫിക്കേഷൻ എൻഡ്പോയിന്റ് അബദ്ധവശാൽ കോഡിംഗ് ഏജന്റിന്റെ അതേ എഫർട്ട് സെറ്റിംഗ് സ്വീകരിക്കാൻ പാടില്ല. ഓരോ കോളിനും കൃത്യമായ എഫർട്ട് നൽകുക.
നിങ്ങളുടെ ബജറ്റ് കാൽക്കുലേഷൻ ഹെൽപ്പർ ഡിലീറ്റ് ചെയ്യുക. എനിക്കറിയാം, അതിന് യൂണിറ്റ് ടെസ്റ്റുകൾ ഉണ്ടാകാം. എന്റെ കോഡിലും ഉണ്ടായിരുന്നു. എന്നാൽ ഇപ്പോൾ അത് ആവശ്യമില്ലാത്ത ഭാരമാണ്. പ്ലാറ്റ്ഫോമിന് നിങ്ങളുടെ ടോക്കൺ കണക്കുകൾ ആവശ്യമില്ല. മോഡൽ അതിന്റെ വേഗത സ്വയം നിയന്ത്രിക്കുന്നു.
temperature, top_p, top_k എന്നിവ ഒഴിവാക്കുക. Opus 4.7, 4.8 എന്നിവയിൽ, ഈ sampling parameters ഉപയോഗിക്കുന്നത് 400 errors ഉണ്ടാക്കും. ഈ പുതിയ ജനറേഷനിൽ പ്ലാറ്റ്ഫോം അവ നീക്കം ചെയ്തിട്ടുണ്ട്. നിങ്ങളുടെ പഴയ temperature-tuning രീതികൾ ഇവിടെ പ്രായോഗികമല്ല, അവ നിലനിർത്തുന്നത് നിങ്ങളുടെ migration പ്രക്രിയയെ തടസ്സപ്പെടുത്തിയേക്കാം.
ഓരോ മോഡലും പ്രത്യേകം പരിശോധിക്കുക. Opus 4.5-ഉം 4.8-ഉം തികച്ചും വ്യത്യസ്തമാണ്. ഒരു മോഡലിൽ പ്രവർത്തിക്കുന്ന config മറ്റൊന്നിന് നിർബന്ധമായും പ്രവർത്തിക്കണമെന്നില്ല. നിങ്ങൾ ഒന്നിലധികം വേർഷനുകൾ സപ്പോർട്ട് ചെയ്യുന്നുണ്ടെങ്കിൽ, നിങ്ങളുടെ ലോജിക് ബ്രാഞ്ച് ചെയ്യുകയോ അവയെ വ്യത്യസ്ത backends ആയി പരിഗണിക്കുകയോ ചെയ്യുക.
UI Freeze പരിഹരിക്കുക
നിങ്ങൾ ഇത് ശരിയായി കൈകാര്യം ചെയ്തില്ലെങ്കിൽ ഉപയോക്താക്കളെ ആശയക്കുഴപ്പത്തിലാക്കുന്ന ഒരു streaming behavior ഉണ്ട്. പുതിയ മോഡലുകളിൽ, thinking blocks സ്ട്രീം ചെയ്യുമെങ്കിലും ഡിഫോൾട്ട് ആയി ടെക്സ്റ്റ് ശൂന്യമായിരിക്കും. നിങ്ങളുടെ ഇന്റർഫേസിൽ, ഇത് യാതൊരു പുരോഗതിയും കാണിക്കാത്ത ഒരു നീണ്ട ഇടവേളയായി തോന്നും. ആപ്പ് ഹാങ്ങ് ആയി എന്ന് ഉപയോക്താക്കൾ കരുതിപ്പോകാൻ സാധ്യതയുണ്ട്.
ഇത് പരിഹരിക്കാൻ, thinking: { type: "adaptive", display: "summarized" } എന്ന് പാസ് ചെയ്യുക. ഇത് raw thought stream ചാറ്റ് വിൻഡോയിലേക്ക് നേരിട്ട് കാണിക്കാതെ തന്നെ ഒരു പ്രോഗ്രസ് ഇൻഡിക്കേറ്റർ നൽകുന്നു. നിങ്ങളുടെ frontend റെസ്പോൺസീവ് ആയിരിക്കുകയും, പശ്ചാത്തലത്തിൽ എന്തോ നടക്കുന്നുണ്ടെന്ന് ഉപയോക്താക്കൾക്ക് മനസ്സിലാകുകയും ചെയ്യും.
യഥാർത്ഥ പാഠം
വെണ്ടർ (vendor) ദീർഘകാലം നിലനിർത്താൻ ഉദ്ദേശിക്കാത്ത ഒരു പാരാമീറ്ററിന് മുകളിൽ ഞാൻ ഒരു വലിയ abstraction layer നിർമ്മിച്ചു. പ്ലാറ്റ്ഫോമിനേക്കാൾ മികച്ച രീതിയിൽ എനിക്ക് tradeoff മനസ്സിലാകുമെന്ന് കരുതി ഞാൻ അവരുടെ സെറ്റിംഗുകളെ എന്റെ സ്വന്തം ലോജിക്കിൽ ഉൾപ്പെടുത്തി. എന്നാൽ എനിക്ക് തെറ്റി. Adaptive thinking ആണ് കൂടുതൽ നല്ലത്, കാരണം മോഡലിന് എപ്പോഴാണ് കൂടുതൽ ചിന്തിക്കേണ്ടതെന്നും എപ്പോഴാണ് സാധാരണ രീതിയിൽ മുന്നോട്ട് പോകേണ്ടതെന്നും സ്വയം തീരുമാനിക്കാൻ കഴിയും. ഇപ്പോൾ എന്റെ codebase ചെറുതാണ്, ഫലങ്ങളും കൂടുതൽ കൃത്യമാണ്. ചിലപ്പോൾ, ബുദ്ധിപരമായ കോഡുകൾ നീക്കം ചെയ്യുകയും പ്ലാറ്റ്ഫോമിനെ അതിന്റെ ജോലി ചെയ്യാൻ അനുവദിക്കുകയും ചെയ്യുക എന്നതാണ് ശരിയായ എഞ്ചിനീയറിംഗ് നീക്കം.
യഥാർത്ഥ migration notes വായിക്കാൻ ആഗ്രഹിക്കുന്നുണ്ടെങ്കിൽ, നിങ്ങൾക്ക് അവ ഇവിടെ കാണാം. ഇത്തരത്തിലുള്ള കൂടുതൽ ചർച്ചകൾക്കായി, Telegram-ലെ GyaanSetu AI കമ്മ്യൂണിറ്റിയിൽ ജോയിൻ ചെയ്യുക.