HarnessDev: LLMలు తమ స్వంత మౌలిక సదుపాయాలను (Infrastructure) నిర్మించుకోవడం
ByteDance మరియు కొన్ని విశ్వవిద్యాలయాల బృందం కలిసి HarnessDevను ప్రారంభించాయి. ఇది లార్జ్ లాంగ్వేజ్ మోడల్స్ (LLMs) తమ స్వంత "ఏజెంట్ ఆపరేటింగ్ సిస్టమ్స్"ను వ్రాయడానికి అనుమతించే ఒక ఫ్రేమ్వర్క్, వీటిని Agent Harnesses అని పిలుస్తారు. ఈ బృందం ఒక LLMకి ఒక చిన్న స్టార్టర్ కిట్ను అందిస్తుంది మరియు మిగిలిన భాగాన్ని అది స్వయంగా పూర్తి చేసుకునేలా చేస్తుంది. మనిషి ప్రతి లైన్ను టైప్ చేయకుండానే, AI తన స్వంత టూల్-యూజ్ లూప్లు (tool-use loops), వెరిఫికేషన్ దశలు మరియు ఎర్రర్ హ్యాండ్లింగ్ను నడిపించే కంట్రోల్ లేయర్ను ఎలా నిర్మించగలదో ఇది చూపుతుంది.
స్వయంగా నిర్మించుకున్న హార్నెస్ (harness) ఎందుకు ముఖ్యం
AI ఏజెంట్లు సింగిల్-ప్రాంప్ట్ అసిస్టెంట్ల నుండి, APIలను పిలవడం, డేటాబేస్లను క్వెరీ చేయడం మరియు ఫలితాలను క్రోడీకరించే మల్టీ-స్టెప్ వర్కర్లుగా పరిణామం చెందాయి. ఇప్పటి వరకు, మోడల్ ఎప్పుడు సెర్చ్ టూల్ను పిలవాలి, ఇంటర్మీడియట్ స్టేట్ను ఎలా నిల్వ చేయాలి మరియు తుది సమాధానాన్ని ఎలా వెరిఫై చేయాలి అనే అంశాలను తెలియజేసే ఆర్కెస్ట్రేషన్ కోడ్ను డెవలపర్లు స్వయంగా రూపొందించేవారు. HarnessDev ఈ విధానాన్ని పూర్తిగా మారుస్తుంది: ఒక seed harness కేవలం తగినంత స్క్యాఫోల్డింగ్ను (scaffolding)—అంటే లూపింగ్, టూల్స్ ఎంపిక మరియు స్టేట్ను ట్రాక్ చేయడానికి అవసరమైన ప్రాథమిక ఫంక్షన్లను—అందిస్తుంది, మరియు LLM దానిని పూర్తి స్థాయి రన్టైమ్గా విస్తరిస్తుంది.
ఈ పరిశోధనా పత్రంలోని బెంచ్మార్క్లో, మోడల్ 18 విభిన్న హార్నెస్లను రూపొందించింది, ఇది అసలు సీడ్కు 17,000 కంటే ఎక్కువ లైన్ల కోడ్ను జోడించింది. ప్రతి హార్నెస్ ఒక టాస్క్ యొక్క పూర్తి లైఫ్-సైకిల్ను నిర్వహించింది: లూప్లను అమలు చేయడం, సరైన టూల్ను ఎంచుకోవడం, కాంటెక్స్ట్ను నిర్వహించడం, స్టేట్ను ట్రాక్ చేయడం, ఫలితాలను వెరిఫై చేయడం మరియు ఎర్రర్ల నుండి కోలుకోవడం.
ఈ అధ్యయనం వెల్లడించిన దాగి ఉన్న ఖర్చులు (hidden costs)
ఈ సంఖ్యలు ఆకట్టుకునేలా ఉన్నప్పటికీ, కేవలం కోడ్ అమలు చేయడం మాత్రమే ఆచరణాత్మక వినియోగానికి సమానం కాదని రచయితలు హెచ్చరిస్తున్నారు.
- ఉపయోగించని భాగాలు (Unused components) – రూపొందించబడిన కోడ్లో గణనీయమైన భాగం అసలు టాస్క్ అమలు సమయంలో ఎప్పుడూ రన్ కాలేదు. LLM కొన్ని ఫంక్షన్లను వ్రాసింది కానీ ఏజెంట్ వాటిని ఎప్పుడూ పిలవలేదు, దీనివల్ల ఎటువంటి విలువను అందించకుండా కోడ్ బేస్ పెరిగిపోయింది.
- మోడల్ లాక్-ఇన్ (Model lock-in) – హార్నెస్లు వాటిని సృష్టించిన నిర్దిష్ట LLMకి అనుగుణంగా ఉండేలా రూపొందాయి. అదే హార్నెస్ను వేరే మోడల్కు ఇచ్చినప్పుడు, పనితీరు గణనీయంగా పడిపోయింది. దీనివల్ల ఆటో-జనరేటెడ్ కంట్రోల్ లాజిక్లో మోడల్-నిర్దిష్టమైన ప్రత్యేకతలు (quirks) కలిసి ఉన్నాయని అర్థమవుతోంది.
- వెరిఫికేషన్ లోపాలు (Verification gaps) – ఒక టెస్ట్ హార్నెస్ 99% (100 రన్లలో 99) విజయవంతమైనట్లు నివేదించింది, కానీ అది కేవలం 48% సార్లు మాత్రమే సరైన సమాధానాన్ని ఇచ్చింది. బలమైన వెరిఫికేషన్ లేకపోతే, ఏజెంట్ తప్పు సమాధానాలను కూడా నమ్మకంగా చెప్పవచ్చు.
- టోకెన్ ఓవర్హెడ్ (Token overhead) – టోకెన్ వినియోగం—అంటే కంప్యూట్ ఖర్చుకు ప్రాతినిధ్యం వహించేది—తీవ్రంగా మారుతూ ఉంది. ఒకే ఫలితాన్ని సాధించడానికి ఒక హార్నెస్ మరొక దానికంటే ఏడు రెట్లు ఎక్కువ టోకెన్లను ఉపయోగించాల్సి వచ్చింది, ఇది ప్రొడక్షన్ సెట్టింగ్లలో స్కేలబిలిటీపై ఆందోళనలను కలిగిస్తోంది.
కోడ్ LLM నుండి వచ్చినప్పటికీ, క్రమబద్ధమైన డిజైన్ యొక్క అవసరాన్ని ఈ ఫలితాలు నొక్కి చెబుతున్నాయి.
డెవలపర్లు గుర్తుంచుకోవలసిన విషయాలు
- హార్నెస్ డిజైన్ను ఆర్కిటెక్చర్గా పరిగణించండి – మోడల్ "అంతట అదే పనిచేస్తుంది" అని నమ్మకండి. LLM వాటిని నింపేలా వదిలే ముందు, లూప్ కంట్రోల్, టూల్ ఎంపిక, స్టేట్ హ్యాండ్లింగ్ మరియు వెరిఫికేషన్ కోసం స్పష్టమైన మాడ్యూల్స్ను నిర్వచించండి.
- బలమైన వెరిఫికేషన్ను నిర్మించండి – ఏజెంట్ చెప్పే సమాధానాన్ని గ్రౌండ్ ట్రూత్ (ground truth) లేదా సెకండరీ మోడల్తో పోల్చే స్పష్టమైన తనిఖీలను (checks) చేర్చండి. 99% స్వయంగా నివేదించిన విజయ రేటు ఉన్నప్పటికీ, అధ్యయనంలో 48% ఖచ్చితత్వం మాత్రమే ఉండటం చూస్తే, వెరిఫికేషన్ అనేది చివరి నిమిషంలో చేసే పని కాదని అర్థమవుతుంది.
- టోకెన్ బడ్జెట్లను గమనించండి – క్లిష్టమైన హార్నెస్లు టోకెన్ల సంఖ్యను పెంచవచ్చు. దాగి ఉన్న ఖర్చులను నివారించడానికి, వివిధ హార్నెస్ వేరియంట్లను ముందుగానే పరీక్షించండి (profile).
- వివిధ మోడల్స్పై పరీక్షించండి – ఒకే హార్నెస్ను బహుళ LLM బ్యాక్-ఎండ్లతో రన్ చేయండి. పనితీరు గణనీయంగా పడిపోతే, మీకు మోడల్-అగ్నోస్టిక్ (model-agnostic) డిజైన్ లేదా ప్రతి మోడల్కు విడివిడి హార్నెస్లు అవసరం కావచ్చు.
ముగింపు: LLMలు తమ స్వంత ఆపరేటింగ్ సిస్టమ్ వంటి కంట్రోల్ కోడ్ను స్వయంగా రూపొందించగలవని HarnessDev నిరూపిస్తుంది.