12 లార్జ్-లాంగ్వేజ్-మోడల్ (LLM) APIల యొక్క కొత్త బెంచ్మార్క్ ప్రకారం, దాదాపు ప్రతి సర్వీస్ కోరిన స్కీమాకు సరిపోయే JSONను అందిస్తుంది, కానీ గణనీయమైన సంఖ్యలో మోడల్స్ వాస్తవపరంగా తప్పు విలువలను ఇస్తున్నాయి. అదే స్కీమా కోసం టోకెన్ ఖర్చు కొన్ని డజన్ల నుండి దాదాపు ఐదు వేల టోకెన్ల వరకు మారుతూ ఉంది. ఎక్స్ట్రాక్షన్ పైప్లైన్లు లేదా డేటా-డ్రివెన్ ఏజెంట్లను నిర్మిస్తున్న డెవలపర్లు, "స్కీమా-వాలిడ్" (schema-valid) అంటే "సరైనది" (correct) అని ఇకపై నమ్మలేరు.
ఈ పరీక్ష ఎందుకు ముఖ్యం
పార్సింగ్ లోపాలను (parsing errors) నివారించడానికి API ప్రొవైడర్లు "స్ట్రక్చర్డ్ అవుట్పుట్" (structured output)ను ఒక మార్గంగా ప్రచారం చేస్తున్నారు. దీని ప్రామిస్ చాలా సరళమైనది: మోడల్కు ఒక JSON స్కీమాను ఇస్తే, మీరు క్లిష్టమైన పోస్ట్-ప్రాసెసింగ్ కోడ్ను రాయాల్సిన అవసరం లేకుండానే అది ఫీల్డ్లను నింపుతుంది. వాస్తవానికి, చాలా ప్రొడక్షన్ సిస్టమ్లు క్రాష్ అవ్వకుండా ఉండటానికి మరియు డౌన్స్ట్రీమ్ అనలిటిక్స్ పైప్లైన్లను శుభ్రంగా ఉంచడానికి ఇప్పటికే ఈ గ్యారెంటీపై ఆధారపడుతున్నాయి. ఈ గ్యారెంటీ సగం నిజమైనప్పుడు మాత్రమే, బగ్స్ నిశ్శబ్దంగా లోపలికి వస్తాయి మరియు టోకెన్ వినియోగం ఆధారంగా చేసే ఖర్చు లెక్కలు పూర్తిగా తప్పుగా మారుతాయి.
మంచి వార్త: స్కీమాలు ఇప్పుడు ఎక్కువగా అమలు చేయబడుతున్నాయి
- టెస్ట్ సూట్లో ఉన్న చాలా మోడల్స్ కఠినమైన వాలిడేటర్ను పాస్ అయ్యే JSONను ఉత్పత్తి చేశాయి.
- Constrained decoding – డీకోడర్ను స్కీమాకు లాక్ చేసే మోడల్స్ అదనపు అక్షరాలను (stray characters) విడుదల చేయలేవు, కాబట్టి మల్ఫార్మ్డ్ పేలోడ్లు (malformed payloads) దాదాపుగా అంతరించిపోయాయి.
- Parse-error rates – JSON సింటాక్స్ వైఫల్యాల కోసం డెవలపర్లు ఇకపై ప్రతి కాల్ను try-catch బ్లాక్లలో ఉంచాల్సిన అవసరం లేదు.
చెడు వార్త: validity ≠ accuracy
ఒక వాలిడ్ షేప్ (valid shape) వాలిడ్ విలువను (valid value) గ్యారెంటీ చేయదు. పన్నెండు మోడళ్లలో నాలుగు—DeepSeek V4, Qwen, మరియు GLM-5.2 (రిపోర్ట్లో చివరి రెండు వేర్వేరు పేర్లతో కనిపిస్తాయి)—"thinking" (లేదా chain-of-thought) మోడ్ ఆన్ చేసినప్పుడు తప్పు సంఖ్యలతో కూడిన పర్ఫెక్ట్గా ఉన్న JSONను ఉత్పత్తి చేశాయి.
- Qwen మోడల్లో, రీజనింగ్ (reasoning) ఎనేబుల్ చేసినప్పుడు 16లో 1 సరైన సమాధానం మాత్రమే వచ్చినది, కానీ రీజనింగ్ డిసేబుల్ చేసినప్పుడు 8కి 8 సరైన సమాధానాలు వచ్చాయి.
- DeepSeek V4 Pro కూడా ఇలాంటి మార్పునే చూపించింది: మోడల్ తన దశలను వివరించడం ఆపివేసిన తర్వాత, ఎక్స్ట్రాక్షన్ అక్యురసీ 1/8 నుండి 7/8కి పెరిగింది.
అదనపు రీజనింగ్ దశ (reasoning step) కన్స్ట్రెయిన్డ్ డీకోడర్కు అంతరాయం కలిగిస్తుంది, దీనివల్ల మోడల్ అవుటర్ బ్రాకెట్లను (outer brackets) గౌరవిస్తూనే, హాలూసినేషన్ (hallucination) వైపు మళ్లుతుంది.
అసలు సమస్య: టోకెన్-ఖర్చు ఆశ్చర్యాలు మరియు విస్మరించబడిన పారామీటర్లు
- Claude’s response format – OpenAI-కంప్యాటబుల్ ఎండ్పాయింట్ల ద్వారా యాక్సెస్ చేసినప్పుడు, Claude
response_formatఫ్లాగ్ను పూర్తిగా విస్మరించి, 0% స్కీమా-కంప్లయింట్ అవుట్పుట్ను ఇచ్చింది. ఈ మోడల్ స్ట్రక్చర్డ్ కాల్స్కు మద్దతు ఇస్తుంది, కానీ కేవలం Anthropic యొక్క నేటివ్ టూల్-కాల్ ఇంటర్ఫేస్ ద్వారా మాత్రమే. - Schema token inflation – ఒక సాధారణ 12 KB స్కీమా DeepSeekలో 30 టోకెన్ల ఖర్చుతో వస్తే, అదే పేలోడ్ Claudeలో 4,959 టోకెన్లను వినియోగించింది.
- Billing inconsistencies – కొంతమంది ప్రొవైడర్లు స్కీమాను ప్రాంప్ట్లో భాగంగా పరిగణించి, అది వినియోగించే ప్రతి టోకెన్కు ఛార్జ్ చేస్తారు; మరికొందరు దానిని ఉచిత ఓవర్లేగా పరిగణిస్తారు. భారీ స్థాయిలో వాడినప్పుడు, మోడల్ ఉత్పత్తి చేసిన కంటెంట్ ఖర్చు కంటే స్కీమా బిల్లు ఎక్కువగా ఉండవచ్చు.
డెవలపర్లు ఇప్పుడు ఏమి చేయాలి
- వాల్యూస్ను మాత్రమే కాకుండా షేప్స్ను కూడా వాలిడేట్ చేయండి – ఒక స్కీమా వాలిడేటర్, ఆ విలువ ఆశించిన టైప్కు సరిపోయినప్పటికీ, తప్పుగా ఉన్న సంఖ్యా సమాధానాన్ని గుర్తించలేదు. డొమైన్-స్పెసిఫిక్ చెక్లను (range, unit, cross-field consistency) జోడించండి.
- నమ్మదగిన ఫీల్డ్ ఫిల్లింగ్ కావాలనుకున్నప్పుడు DeepSeek, Qwen, మరియు GLM మోడల్స్లో chain-of-thoughtను ఆఫ్ చేయండి. అదనపు రీజనింగ్ దశ అనేది ఐచ్ఛికం మాత్రమే, ఖచ్చితత్వం కోసం అది అవసరం లేదు.
- టోకెన్ వినియోగాన్ని ఆడిట్ చేయండి – ప్రతి రిక్వెస్ట్ స్కీమా భాగాంతో సహా ఎన్ని టోకెన్లను వినియోగిస్తుందో లాగ్ చేయండి మరియు భారీ స్థాయి డిప్లాయ్మెంట్లకు కట్టుబడి ఉండకముందే వివిధ వెండర్ల బిల్లులను పోల్చి చూడండి.
- పోర్టబిలిటీని పరీక్షించండి – OpenAIలో పనిచేసే స్కీమా Gemini లేదా Claudeలో పని చేయకపోవచ్చు. కోడ్ను షిప్ చేసే ముందు ప్రతి టార్గెట్ ప్లాట్ఫామ్పై త్వరితగతిన సానిటీ చెక్ (sanity check) నిర్వహించండి.
వెండర్ల నుండి ప్రతివాదన
వివరణ (explanation) అనేది ఎక్స్ట్రాక్షన్ అక్యురసీ కంటే ముఖ్యమైన పనుల కోసం "thinking" మోడ్ అనేది డెవలపర్ ఎంచుకునే ఆప్షన్ అని కొంతమంది ప్రొవైడర్లు వాదిస్తున్నారు. Claude response_format ఫ్లాగ్ను విస్మరించి, దానికి బదులుగా Anthropic నేటివ్ టూల్ కాల్స్ను ఉపయోగించాలని సూచిస్తుంది. ఆ వివరణలు సాంకేతికంగా సరైనవే అయినప్పటికీ, ఏ మోడ్ను ఎంచుకోవాలి మరియు దాగి ఉన్న టోకెన్ ఫీజుల కోసం బడ్జెట్ను ఎలా రూపొందించుకోవాలి అనే భారాన్ని అవి డెవలపర్లపై వేస్తాయి.
ముగింపు
JSON స్కీమా అనేది ఇకపై సేఫ్టీ నెట్ కాదు; అది కేవలం ఒక షేప్ మాత్రమే. లోపల ఉన్న డేటా వాస్తవానికి సరిపోతుందని నిర్ధారించుకోండి, దాగి ఉన్న టోకెన్ ఖర్చులపై దృష్టి పెట్టండి మరియు మోడల్ యొక్క "thinking" అత్యంత శుభ్రంగా కనిపించే అవుట్పుట్ను కూడా పాడు చేయగలదని గుర్తుంచుకోండి.