డెవలపర్లు ఇప్పుడు లార్జ్ లాంగ్వేజ్ మోడల్స్ (LLMs) నుండి వచ్చే తప్పుగా ఉన్న (malformed) JSONను సరిచేయడానికి అయ్యే ఖర్చును నియంత్రించవచ్చు. రిపేర్ ప్రయత్నాలను రెండుకి పరిమితం చేయడం ద్వారా ఇది సాధ్యమవుతుందని ఒక సాధారణ పైథాన్ లూప్ చూపుతోంది. ఈ పద్ధతి—generate, parse, validate, retry, ఆపై accept లేదా fail—"బహుశా సరైనదిగా ఉండవచ్చు అనే JSON"ను కొలవదగిన విజయ రేటుగా మారుస్తుంది మరియు టోకెన్ వినియోగం పెరగకుండా నిరోధిస్తుంది.
Why a repair loop matters
LLMs కి తరచుగా "return JSON" అని సూచించినప్పటికీ, అవుట్పుట్లో తరచుగా సింటాక్స్ లోపాలు, మిస్సింగ్ కీలు లేదా బిజినెస్ రూల్స్ను ఉల్లంఘించే విలువలు ఉంటాయి. ఖచ్చితమైన పేలోడ్ కోసం ఎదురుచూసే డౌన్స్ట్రీమ్ సిస్టమ్, ఇటువంటి అవుట్పుట్ను పొందితే క్రాష్ అవ్వడం లేదా తప్పుడు ఫలితాలను ఇవ్వడం జరుగుతుంది. ఈ సమస్యలను గుర్తించి సరిచేయడానికి క్రమబద్ధమైన మార్గం లేకపోతే, టీమ్లు అధిక వైఫల్య రేటును అంగీకరించాల్సి వస్తుంది లేదా మోడల్ సరిగ్గా చేసే వరకు పదేపదే ప్రాంప్ట్ చేస్తూ డబ్బు వృథా చేస్తాయి.
The three validation layers
ఒక నమ్మదగిన లూప్ వాలిడేషన్ను ఈ క్రింది విధంగా విభజిస్తుంది:
- Syntax – స్ట్రింగ్ అసలు JSONగా పార్స్ అవుతుందా?
- Shape – టాప్-లెవల్ ఆబ్జెక్ట్లో ఖచ్చితంగా ఆశించిన కీలు ఉన్నాయా?
- Semantic – విలువలు డొమైన్ పరిమితులను పాటిస్తున్నాయా (ఉదాహరణకు, ఒక “category” ముందుగా నిర్ణయించిన సెట్కు చెందినది అయి ఉండాలి)?
మొదటి వైఫల్యం చెందిన లేయర్లోనే ఆపివేయడం ద్వారా, లూప్ మోడల్కు ఖచ్చితమైన ఎర్రర్ మెసేజ్ను ఇవ్వగలదు, ఇది తదుపరి ప్రయత్నంలో సరైన పరిష్కారం లభించే అవకాశాలను గణనీయంగా పెంచుతుంది.
Minimal Python example
ఈ క్రింది కోడ్ కేవలం స్టాండర్డ్ లైబ్రరీని మాత్రమే ఉపయోగిస్తుంది. ఇది ఒక చిన్న స్కీమాను (category మరియు summary కీలు కలిగిన డిక్షనరీ) మరియు అనుమతించబడిన కేటగిరీల జాబితాను నిర్వచిస్తుంది.
import json
CATEGORIES = {"bug", "feature", "question"}
def validate(raw: str):
try:
value = json.loads(raw)
except json.JSONDecodeError as exc:
return None, f"syntax: {exc.msg}"
if not isinstance(value, dict):
return None, "shape: root must be an object"
if set(value) != {"category", "summary"}:
return None, "shape: expected category and summary"
if value["category"] not in CATEGORIES:
return None, "semantic: invalid category"
if not isinstance(value["summary"], str) or not value["summary"].strip():
return None, "semantic: summary must be text"
return value, None
రిపేర్ లూప్ స్వయంగా ప్రయత్నాలపై ఒక కఠినమైన పరిమితిని విధిస్తుంది:
MAX_ATTEMPTS = 2
raw = model_response # initial LLM output
for attempt in range(MAX_ATTEMPTS + 1):
value, error = validate(raw)
if error is None:
break
if attempt == MAX_ATTEMPTS:
raise RuntimeError(f"failed after {MAX_ATTEMPTS} retries: {error}")
# Send the error and schema back to the model for a fix
raw = ask_model_to_repair(raw, error)
JSON మొదటి ప్రయత్నంలోనే వాలిడేషన్ను పాస్ అయితే, లూప్ వెంటనే ముగుస్తుంది. లేకపోతే, అది మళ్ళీ ప్రయత్నిస్తుంది, మోడల్కు ఒక సంక్షిప్త పేలోడ్ను అందిస్తుంది: అసలు అవుట్పుట్, ఖచ్చితమైన ఎర్రర్ స్ట్రింగ్ మరియు ఆశించిన స్కీమా. రెండు ప్రయత్నాలు విఫలమైన తర్వాత, ప్రక్రియ స్పష్టమైన ఎక్సెప్షన్తో ఆగిపోతుంది.
Two rules for cost-effective repairs
Keep repair prompts tight – కేవలం ముడి JSON, ఎర్రర్ మెసేజ్ మరియు స్కీమాను మాత్రమే చేర్చండి. సుదీర్ఘమైన చాట్ హిస్టరీని జోడించడం వల్ల టోకెన్ వినియోగం పెరుగుతుంది మరియు మోడల్ను అయోమయానికి గురిచేయవచ్చు, దీనివల్ల ఖచ్చితత్వం పెరగకుండా ప్రతి రీట్రైకి అయ్యే ఖర్చు పెరుగుతుంది.
Separate validation from fact-checking – పార్సర్ నిర్మాణపరమైన సమస్యలను గుర్తించగలదు, కానీ “summary” స్టేట్మెంట్ నిజమో కాదో ధృవీకరించలేదు. ఫ్యాక్ట్-చెకింగ్ తదుపరి దశలో ఉండాలి; తప్పుడు వాదనను “repair” చేయడానికి ప్రయత్నించడం వల్ల ఆ అబద్ధం కేవలం చూడటానికి శుభ్రంగా కనిపిస్తుంది అంతే.
Measuring success
ప్రతి ప్రయత్నంలోని ఎర్రర్ రకాన్ని (syntax, shape, semantic) మరియు లూప్ విజయవంతమైందో లేదో లాగ్ చేయడం ద్వారా ఒక స్పష్టమైన మెట్రిక్ లభిస్తుంది: పరిమిత రీట్రైలలో ఉపయోగించదగినవిగా మారే LLM ప్రతిస్పందనల నిష్పత్తి. టీమ్లు దీనిని కాలక్రమేణా ట్రాక్ చేయవచ్చు, ప్రాంప్ట్ శైలులను పోల్చవచ్చు లేదా వివిధ స్కీమా నిర్వచనాలతో ప్రయోగాలు చేయవచ్చు.
Potential downsides
లూప్ను పరిమితం చేయడం అంటే, పరిమితికి చేరుకున్న తర్వాత కొన్ని తప్పుగా ఉన్న అవుట్పుట్లు పక్కన పెట్టబడతాయి, దీనివల్ల మోడల్ యొక్క ప్రాథమిక నాణ్యత తక్కువగా ఉంటే మొత్తం వైఫల్య రేటు పెరగవచ్చు. ప్రతి ప్రతిస్పందన కీలకమైన వాతావరణంలో, డెవలపర్లు అదనపు టోకెన్ల ఖర్చుతో ఎక్కువ రీట్రై పరిమితిని కోరుకోవచ్చు. దీని వెనుక ఉన్న ట్రేడ్-ఆఫ్ స్పష్టంగా ఉంది: ఎక్కువ కవరేజ్ కోసం ఎక్కువ ఖర్చు, లేదా ఊహించదగిన పరిమితితో తక్కువ బడ్జెట్.
What to watch next
- Prompt engineering for repair – ఎర్రర్ మెసేజ్ ఫార్మాట్ను మెరుగుపరచడం ద్వారా అవసరమయ్యే రీట్రైల సంఖ్యను తగ్గించవచ్చు.
- Alternative parsers – కొన్ని లైబ్రరీలు చిన్న చిన్న సమస్యలను ఆటో-కరెక్ట్ చేయగల టాలరెంట్ పార్సింగ్ను అందిస్తాయి; వాటి ఖర్చును పరిమిత లూప్తో పోల్చడం విలువైనది.
- Model updates – కొత్త LLM వెర్షన్లు నేరుగా మెరుగైన JSONను ఉత్పత్తి చేయవచ్చు, దీనివల్ల రీట్రై పరిమితిని ఇంకా తగ్గించే అవకాశం ఉంటుంది.
పరిమితమైన JSON రిపేర్ లూప్ డెవలపర్లకు ఖర్చులను పెంచకుండా, అస్పష్టమైన LLM అవుట్పుట్ను నమ్మదగిన డేటాగా మార్చడానికి ఒక ఆచరణాత్మక సాధనాన్ని అందిస్తుంది. వాలిడేషన్ను ఒక ముఖ్యమైన దశగా పరిగణించడం మరియు రీట్రైలను పరిమితం చేయడం ద్వారా, టీమ్లు బడ్జెట్లను మరియు డౌన్స్ట్రీమ్ సిస్టమ్లను సంతృప్తిగా ఉంచుకోవచ్చు.