నేను చాలా తెలివిగా చేస్తున్నానని అనుకున్నాను. మా AI pipeline కోసం context windowలో సరిగ్గా ముప్పై శాతం thinking budgetను రిజర్వ్ చేసేలా ఒక helper functionను నేను రాశాను. అది చాలా క్లీన్గా, ప్రిడిక్టబుల్గా ఉంది మరియు Opus 4.5లో అద్భుతంగా పనిచేసింది. కానీ నేను Opus 4.8కి మారగానే, ప్రతి రిక్వెస్ట్ 400 errorతో ఆగిపోయింది. నేను జాగ్రత్తగా రూపొందించిన token math రాత్రికి రాత్రే పనికిరాకుండా పోయింది.
పాత పద్ధతి చాలా సరళంగా ఉండేది. మీరు ఒక budget_tokens విలువను సెట్ చేస్తే, మోడల్ ఆ పరిమితిలో ఉండటానికి తన ఆలోచనా విధానాన్ని (thinking) సర్దుబాటు చేసుకునేది. నేను 128K contextను ఇస్తే, నా కోడ్ రీజనింగ్ కోసం సుమారు 38,000 tokensను కేటాయించి, మిగిలిన వాటిని సమాధానం కోసం వదిలేసేది. ఇది చాలా బాధ్యతాయుతంగా అనిపించేది. కారును స్పీడ్ లిమిట్ లోపల ఉంచడం లాంటిది.
ఆ మోడల్ ఇప్పుడు లేదు. Opus 4.7 మరియు 4.8 వంటి కొత్త వెర్షన్లు adaptive thinkingని ఉపయోగిస్తున్నాయి. మీరు ఇకపై ఒక నంబర్ను ఎంచుకోలేరు. దానికి బదులుగా, మీరు ఒక effort knobను పంపిస్తారు. ఇది కేవలం పేరు మార్పులా అనిపించవచ్చు, కానీ ఈ రెండు నియంత్రణలు (controls) ఒకదానికొకటి ఏమాత్రం పోలి ఉండవు. budget_tokens మోడల్ ఎంతవరకు ఆలోచించాలో ఒక కఠినమైన పరిమితిని (hard ceiling) విధించేది. Effort అనేది మోడల్ అసలు ఎలా ఆలోచిస్తుంది మరియు ఎలా పనిచేస్తుంది అనేదాన్ని నియంత్రిస్తుంది. ఒకటి గ్యాస్ పంప్ మీటర్ లాంటిది అయితే, మరొకటి ఇంజిన్ మ్యాప్ లాంటిది.
Effortను నిజమైన పనికి మ్యాప్ చేయడం
కంట్రోల్ మారినప్పుడు, నా పాత అంతర్ దృష్టి (intuition) పనిచేయడం ఆగిపోయింది. ప్రతి సెట్టింగ్ వల్ల వాస్తవంగా ఏం జరుగుతుందో నేను మళ్ళీ నేర్చుకోవాల్సి వచ్చింది. ప్రతి effort లెవల్ ప్రాక్టికల్గా ఎక్కడ సరిపోతుందో తెలుసుకోవడానికి మా అంతర్గత ట్రాఫిక్పై నేను పరీక్షలు నిర్వహించాను.
Classification and routing కోసం దాదాపు ఎల్లప్పుడూ low effort ఉపయోగించాలి. ఇవి వేగంగా నిర్ణయాలు తీసుకోవాల్సిన పనులు. ఇది రీఫండ్ రిక్వెస్టా లేక సేల్స్ ప్రశ్ననా? ఈ లాగ్ ఎంట్రీని ఎస్కలేట్ చేయాలా? దీనికి సుదీర్ఘమైన వివరణ అవసరం లేదు. Low effort వల్ల latency తగ్గుతుంది మరియు ఖర్చు కూడా చాలా తక్కువగా ఉంటుంది.
Most app traffic, అంటే సమ్మరీస్, రీరైట్స్, సపోర్ట్ రిప్లైస్ మరియు కంటెంట్ ఎక్స్ట్రాక్షన్ వంటి రోజువారీ పనులు, medium నుండి high effort పరిధిలోకి వస్తాయి. ఇది ఒక సమతుల్య పాయింట్. మోడల్ ఎక్కువ chain of thought అవసరం లేని పనుల కోసం టోకెన్లను వృథా చేయకుండా, నిజమైన సందేహాలను (ambiguity) పరిష్కరించడానికి తగినంత స్థలాన్ని పొందుతుంది.
Coding and agentic loops కు xhigh effort అవసరం. ఇక్కడే తప్పులు పేరుకుపోతాయి. ఒక tool-calling loop యొక్క మొదటి దశలోనే మోడల్ తప్పుడు ప్లాన్ రాస్తే, తదుపరి మూడు దశలను ఆ నష్టాన్ని సరిదిద్దడానికే ఖర్చు చేస్తుంది. లేదా ఇంకా దారుణంగా, అది తప్పుడు టూల్స్ను పిలిచి, పారామీటర్లను ఊహించి (hallucinate), యూజర్ను విచ్ఛిన్నమైన వర్క్ఫ్లోతో వదిలేస్తుంది. ముందుగానే మెరుగైన రీజనింగ్ ఉండటం వల్ల ఆ సమస్యను నివారించవచ్చు.
Critical tasks కు max effort ఇవ్వాలి. దీనిని ప్రతిదానికీ ఉపయోగించకండి. తప్పుడు సమాధానం వల్ల టోకెన్ బిల్లు కంటే ఎక్కువ నష్టం కలిగే సందర్భాల్లో మాత్రమే దీనిని ఉపయోగించండి. ఫైనాన్షియల్ రీకన్సిలియేషన్స్, సేఫ్టీ చెక్స్, ఆర్కిటెక్చర్ నిర్ణయాలు మరియు మెడికల్ ట్రైయాజ్ వంటివి దీనికి సరైనవి. ఒక తప్పు వల్ల మనిషి గంటల తరబడి ఆ గందరగోళాన్ని సరిదిద్దాల్సి వస్తే, అదనపు ఆలోచన (thinking) కోసం ఖర్చు చేయండి.
ఖర్చు విషయంలో కలిగిన ఆశ్చర్యం
నా ఆలోచనా విధానాన్ని మార్చిన విషయం ఇదే. max effort ఎప్పుడూ నా ఖర్చులను పెంచుతుందని నేను అనుకున్నాను. ఒకే ఒక టర్న్లో అది నిజమే. రీజనింగ్ ట్రేస్ (reasoning trace) ఎక్కువగా ఉంటుంది. కానీ మల్టీ-స్టెప్ agentic టాస్క్లలో, మొత్తం బిల్లు తరచుగా తగ్గింది.
మోడల్ మొదటి ప్రయత్నంలోనే మెరుగ్గా ప్లాన్ చేస్తుంది. తక్కువ tool calls చేస్తుంది. తప్పుడు దారిలో వెళ్లకుండా తనను తాను నియంత్రించుకుంటుంది. సాధారణంగా ఐదు సార్లు అటు ఇటుగా (back-and-forth) వెళ్లాల్సిన ఒక data extraction agent, కేవలం రెండు సార్లులోనే పని పూర్తి చేయడాన్ని నేను గమనించాను. ఎందుకంటే మోడల్కు ప్రారంభంలోనే స్కీమాను సరిగ్గా అర్థం చేసుకోవడానికి తగినంత రీజనింగ్ స్పేస్ ఉంది. మీరు ఖర్చును లెక్కించేటప్పుడు, రిక్వెస్ట్ను కాకుండా, పని పూర్తికావడాన్ని (job completion) చూడండి. ప్రతి స్టెప్లో పెద్ద thinking budget ఉండటం అంటే మొత్తం స్టెప్స్ తగ్గడం అని అర్థం.
మిగిలినవి దెబ్బతినకుండా ఎలా మైగ్రేట్ చేయాలి
మీ కోడ్బేస్లో ఇంకా budget_tokens వాడుతుంటే, దాని నుండి బయటపడటానికి ఖచ్చితమైన మార్గం ఇక్కడ ఉంది. మూడు మరియు ఐదవ దశలను వదలకండి. నేను వదిలేశాను, దాని వల్ల ఒక మధ్యాహ్నం అంత సమయం డీబగ్గింగ్లోనే గడిచిపోయింది.
మీ కోడ్లో budget_tokens కోసం వెతకండి. ప్రతి ఇన్స్టెన్స్ను తొలగించాలి. కొత్త మోడల్స్లో ఈ పారామీటర్ పనిచేయదు మరియు ఇది 400 errorను కలిగిస్తుంది.
Budget objectను adaptive thinking blockతో మార్చండి. thinking: { type: "adaptive" } ఉపయోగించండి.
ప్రతి కాల్ కోసం స్పష్టమైన effort levelతో output_configను జోడించండి. మీ ట్రాఫిక్ మిశ్రమంగా ఉన్నట్లయితే, దీనిని గ్లోబల్ డిఫాల్ట్గా వదిలేయకండి. మీ లైట్వెయిట్ క్లాసిఫికేషన్ ఎండ్పాయింట్ పొరపాటున మీ కోడింగ్ ఏజెంట్తో సమానమైన effort సెట్టింగ్ను పొందకూడదు. కాల్ చేసే చోటే స్పష్టంగా పేర్కొనండి.
మీ budget calculation helperను తొలగించండి. నాకు తెలుసు, దానికి యూనిట్ టెస్ట్లు కూడా ఉండవచ్చు. నా కోడ్లో కూడా ఉన్నాయి. కానీ ఇప్పుడు అది అనవసరమైన భారం. ప్లాట్ఫారమ్ మీ token mathను కోరుకోవడం లేదు. మోడల్ తన వేగాన్ని (pacing) తనే నియంత్రించుకుంటుంది.
temperature, top_p, మరియు top_kలను తొలగించండి. Opus 4.7 మరియు 4.8 లలో, ఈ శాంప్లింగ్ పారామీటర్లు 400 ఎర్రర్లను చూపుతాయి. ఈ జనరేషన్లో ప్లాట్ఫారమ్ వాటిని తొలగించింది. మీ పాత టెంపరేచర్-ట్యూనింగ్ ట్రిక్స్ ఇక్కడ వర్తించవు, మరియు వాటిని అలాగే ఉంచడం వల్ల మీ మైగ్రేషన్ నిశ్శబ్దంగా విఫలమవుతుంది.
ప్రతి మోడల్ను విడివిడిగా పరీక్షించండి. Opus 4.5 మరియు 4.8 పూర్తిగా భిన్నమైనవి. ఒకదానిపై పనిచేసే కాన్ఫిగరేషన్ మరొక దానిపై తప్పనిసరిగా పనిచేయకపోవచ్చు. మీరు బహుళ వెర్షన్లను సపోర్ట్ చేస్తుంటే, మీ లాజిక్ను విడదీయండి లేదా వాటిని వేర్వేరు బ్యాకెండ్లుగా పరిగణించండి.
UI ఫ్రీజ్ (Freeze) సమస్యను పరిష్కరించడం
మీరు దీనిని సరిగ్గా హ్యాండిల్ చేయకపోతే, ఒక స్ట్రీమింగ్ ప్రవర్తన మీ వినియోగదారులను అయోమయానికి గురి చేస్తుంది. కొత్త మోడళ్లలో, థింకింగ్ బ్లాక్లు స్ట్రీమ్ అవుతాయి కానీ డిఫాల్ట్గా టెక్స్ట్ ఖాళీగా ఉంటుంది. మీ ఇంటర్ఫేస్లో, ఇది ఎటువంటి పురోగతి కనిపించని ఒక సుదీర్ఘమైన, అసౌకర్యమైన విరామంలా కనిపిస్తుంది. యాప్ హ్యాంగ్ అయిందని వినియోగదారులు భావిస్తారు.
దీనిని పరిష్కరించడానికి, thinking: { type: "adaptive", display: "summarized" } ని పంపండి. ఇది చాట్ విండోలోకి ముడి థాట్ స్ట్రీమ్ను పంపకుండానే, మీకు కనిపించే ప్రోగ్రెస్ ఇండికేటర్ను అందిస్తుంది. మీ ఫ్రంటెండ్ రెస్పాన్సివ్గా ఉంటుంది మరియు లోపల ఏదో జరుగుతోందని మీ వినియోగదారులకు తెలుస్తుంది.
అసలైన పాఠం
వెండర్ ఎప్పటికీ శాశ్వతంగా ఉండాలని అనుకోని ఒక పారామీటర్ పైన నేను ఒక పూర్తి అబ్స్ట్రాక్షన్ లేయర్ను నిర్మించాను. ప్లాట్ఫారమ్ కంటే నాకు ట్రేడ్ఆఫ్ బాగా అర్థమైందని నేను అనుకుని, వారి సెట్టింగ్లను నా స్వంత లాజిక్లో పొందుపరిచాను. కానీ నాకు అర్థం కాలేదు. అడాప్టివ్ థింకింగ్ అనేది మెరుగైన ఎంపిక, ఎందుకంటే మోడల్ ఎప్పుడు లోతుగా ఆలోచించాలో మరియు ఎప్పుడు తక్కువ శ్రమతో ముందుకు వెళ్లాలో స్వయంగా నిర్ణయించుకుంటుంది. ఇప్పుడు నా కోడ్బేస్ చిన్నదిగా మారింది. ఫలితాలు మరింత స్పష్టంగా వచ్చాయి. కొన్నిసార్లు తెలివైన కోడ్ను తొలగించి, ప్లాట్ఫారమ్ను దాని పనిని చేయనివ్వడమే సరైన ఇంజనీరింగ్ నిర్ణయం.
మీరు అసలైన మైగ్రేషన్ నోట్స్ను చదవాలనుకుంటే, వాటిని ఇక్కడ చూడవచ్చు. ఇటువంటి మరిన్ని చర్చల కోసం, Telegramలో GyaanSetu AI కమ్యూనిటీలో చేరండి.