GLM-5.3 “thinking: disabled” ఫ్లాగ్‌ను తొలగించింది, కాబట్టి {"thinking":{"type":"disabled"}}ని ఉపయోగించే ఏ ఇంటిగ్రేషన్ అయినా ఇప్పుడు స్పందనకు బదులుగా ఎర్రర్‌ను రిటర్న్ చేస్తుంది. ఈ మార్పు రాత్రికి రాత్రే డజన్ల కొద్దీ టెస్ట్ సూట్‌లను దెబ్బతీసింది మరియు తమ అప్లికేషన్లు నడవడానికి డెవలపర్లు ఒకే ఒక లైన్ కోడ్‌ను తిరిగి రాయాల్సి వచ్చేలా చేసింది.

ఈ మార్పు ఎందుకు ముఖ్యమైనది

GLM-5.2లో, చిన్న ప్రాంప్ట్‌ల కోసం థింకింగ్ మోడ్‌ను ఆఫ్ చేసుకునే వెసులుబాటు API ఇచ్చింది. ఆప్షన్ అనేది ఆటోమేషన్ స్క్రిప్ట్‌లు, బ్యాచ్-ప్రాసెసింగ్ పైప్‌లైన్‌లు మరియు లో-లేటెన్సీ బాట్‌లలో ఒక సాధారణ పద్ధతిగా ఉండేది. GLM-5.3 ఆ ఫ్లాగ్‌ను పూర్తిగా తొలగించి, low, high మరియు max అనే మూడు ఎఫర్ట్ లెవల్స్‌ను పరిచయం చేసింది—ఇందులో max డిఫాల్ట్‌గా ఉంటుంది. కొత్త మోడల్ ఎల్లప్పుడూ రీజనింగ్ ట్రేస్‌ను జనరేట్ చేస్తుంది; దానిని ఇకపై పూర్తిగా నిశ్శబ్దం చేయలేము.

ఏమి దెబ్బతింది మరియు అది ఎలా వ్యాపిస్తుంది

రిక్వెస్ట్ బాడీలో "type":"disabled" ఉన్నప్పుడు, సర్వర్ పేలోడ్‌ను తిరస్కరించి, ఒక జనరిక్ ఫెయిల్యూర్ రెస్పాన్స్‌ను రిటర్న్ చేస్తుంది. ఎటువంటి అథెంటికేషన్ లేదా సింటాక్స్ ఎర్రర్‌లు కనిపించవు, కాబట్టి ఫుల్ రిగ్రెషన్ రన్ ఫెయిల్ అయ్యే వరకు సమస్యను గుర్తించడం కష్టమవుతుంది. చాలా కోడ్‌బేస్‌లలో ఈ ఫ్లాగ్ ఒకే ఒక రీయూజబుల్ హెల్పర్ ఫంక్షన్‌లో ఉండటం వల్ల, దీని ప్రభావం పెద్ద టెస్ట్ సూట్‌లు మరియు ప్రొడక్షన్ ఎండ్‌పాయింట్లపై కూడా పడింది.

ఖచ్చితమైన కోడ్ మార్పు

పాత పేలోడ్‌ను దీనితో మార్చండి:

extra_body = {"thinking": {"type": "disabled"}}

GLM-5.3-కంప్యాటబుల్ వెర్షన్‌తో:

extra_body = {"thinking": {"type": "enabled", "effort": "low"}}

"type":"enabled" కీ రీజనింగ్ ఇంజిన్‌ను మళ్ళీ యాక్టివేట్ చేస్తుంది, అయితే "effort":"low" అనేది కొత్త మోడల్ అనుమతించినంత వరకు పాత డిసేబుల్డ్ మోడ్ యొక్క వేగాన్ని పోలి ఉంటుంది.

పనితీరుపై ప్రభావం

లో-ఎఫర్ట్ సెట్టింగ్‌తో అదే కోడ్-రివ్యూ ప్రాంప్ట్‌లను రన్ చేస్తే వచ్చే ఫలితాలు “పాత వేగానికి దగ్గరగా” ఉంటాయి కానీ ఖచ్చితంగా ఒకేలా ఉండవు. మోడల్ ఇంకా రీజనింగ్ ట్రేస్‌ను విడుదల చేస్తుంది, ఇది కొన్ని అదనపు టోకెన్లను మరియు స్వల్ప లేటెన్సీ పెరుగుదలను కలిగిస్తుంది. హై-త్రూపుట్ లేదా లేటెన్సీ-క్రిటికల్ వర్క్‌లోడ్‌లలో, ఈ ఓవర్‌హెడ్ ఆమోదయోగ్యమేనా అని నిర్ధారించుకోవడానికి మీరు మీ స్వంత డేటాతో బెంచ్‌మార్క్ చేయాలి.

ఖర్చు ఉన్నప్పటికీ ఎందుకు మారాలి

GLM-5.3 తన పూర్వ మోడల్ యొక్క 744-బిలియన్-పారామీటర్ ఆర్కిటెక్చర్‌ను కలిగి ఉంది, కానీ కోడింగ్ మరియు ఏజెంటిక్ టాస్క్‌లపై దృష్టి సారిస్తుంది. స్వతంత్ర బెంచ్‌మార్క్‌లు (Terminal-Bench 3.0) స్కోర్‌లలో గణనీయమైన పెరుగుదలను చూపుతున్నాయి, మరియు అంతర్గత పరీక్షలు బహుళ ఫైళ్లలో లాజిక్ ఎర్రర్‌లను మెరుగ్గా గుర్తించవచ్చని నివేదించాయి. సంక్లిష్టమైన కోడ్ అనాలిసిస్ కోసం ఈ మోడల్‌పై ఆధారపడే టీమ్‌లకు, పనితీరు మెరుగుదల వల్ల కలిగే ప్రయోజనం టోకెన్ వినియోగంలో వచ్చే స్వల్ప పెరుగుదల కంటే ఎక్కువగా ఉంటుంది.

మీరు విస్మరించలేని లాభనష్టాల సమతుల్యత

ఒక అప్లికేషన్‌కు నిజంగా జీరో-థింకింగ్ రెస్పాన్స్‌లు అవసరమైతే—ఉదాహరణకు, ప్యూర్ టోకెన్-కంప్లీషన్ సర్వీస్—GLM-5.3లో ఇప్పుడు దానికి సహజమైన ఆప్షన్ లేదు. డెవలపర్లు అదనపు రీజనింగ్ అవుట్‌పుట్‌ను అంగీకరించాలి లేదా ఇంకా డిసేబుల్డ్ మోడ్‌ను అందించే వేరే మోడల్‌కు మారాలి.

తదుపరి ఏమి గమనించాలి

  • లేటెన్సీ మానిటరింగ్: పేలోడ్ మార్పు తర్వాత, రిగ్రెషన్లను త్వరగా గుర్తించడానికి రెస్పాన్స్ టైమ్స్ మరియు టోకెన్ కౌంట్‌లను ట్రాక్ చేయండి.
  • ఎఫర్ట్ ట్యూనింగ్: కొన్ని వర్క్‌లోడ్‌లు పూర్తి పెనాల్టీ లేకుండా “high” ఎఫర్ట్ ద్వారా ప్రయోజనం పొందవచ్చు, కాబట్టి లో సెట్టింగ్‌కు మించి ప్రయోగాలు చేయండి.
  • భవిష్యత్తులో తొలగించబడేవి: ఒకే ఒక ఫ్లాగ్‌ను తొలగించడం అనేది APIలో మరిన్ని ఏకీకరణలు జరిగే అవకాశం ఉందని సూచిస్తుంది; రాబోయే రిలీజ్ నోట్స్‌పై దృష్టి పెట్టండి.

సారాంశం: thinking పేలోడ్‌ను {"type":"enabled","effort":"low"}గా అప్‌డేట్ చేయడం ద్వారా GLM-5.3తో అనుకూలతను పునరుద్ధరించవచ్చు. మీ పైప్‌లైన్‌లలో లేటెన్సీ మరియు టోకెన్ వినియోగాన్ని తనిఖీ చేయండి, మరియు మెరుగుపరచబడిన కోడింగ్ సామర్థ్యాలు అనివార్యమైన రీజనింగ్ ట్రేస్‌ను సమర్థించగలవా లేదా అని నిర్ణయించుకోండి.

చర్చ మరియు కమ్యూనిటీ సపోర్ట్ GyaanSetu AI టెలిగ్రామ్ ఛానెల్‌లో అందుబాటులో ఉన్నాయి.