HarnessDev: LLMs स्वतःची इन्फ्रास्ट्रक्चर तयार करत आहेत
ByteDance आणि काही विद्यापीठांच्या गटाने HarnessDev लाँच केले आहे, जे एक असे फ्रेमवर्क आहे जे लार्ज लँग्वेज मॉडेल्सना (LLMs) त्यांचे स्वतःचे "एजंट ऑपरेटिंग सिस्टम्स" (agent operating systems) लिहिण्याची परवानगी देते, ज्यांना Agent Harnesses म्हटले जाते. ही टीम LLM ला एक प्राथमिक स्टार्टर किट देते आणि उर्वरित काम स्वतः पूर्ण करू देते, ज्यातून हे दिसून येते की AI कशा प्रकारे स्वतःचे टूल-युज लूप्स (tool-use loops), व्हेरिफिकेशन स्टेप्स आणि एरर हँडलिंग चालवणारी कंट्रोल लेयर तयार करू शकते—आणि त्यासाठी मानवाला प्रत्येक ओळ टाईप करण्याची गरज पडत नाही.
स्वतः तयार केलेले हार्नेस (harness) का महत्त्वाचे आहे
AI एजंट्स आता केवळ सिंगल-प्रॉम्प्ट असिस्टंट्स न राहता मल्टी-स्टेप वर्कर्समध्ये विकसित झाले आहेत, जे APIs कॉल करतात, डेटाबेस क्वेरी करतात आणि निकालांना एकत्र जोडतात. आतापर्यंत, डेव्हलपर्स ऑर्केस्ट्रेशन कोड स्वतः हाताने तयार करत असत, जो मॉडेलला सांगतो की सर्च टूल कधी कॉल करायचे, इंटरमीडिएट स्टेट कशी साठवायची आणि अंतिम उत्तर कसे व्हेरिफाय करायचे. HarnessDev हे मॉडेल पूर्णपणे बदलून टाकते: एक seed harness फक्त आवश्यक स्केफोल्डिंग (scaffolding) पुरवते—जसे की लूपिंग, टूल्स निवडणे आणि स्टेट ट्रॅकिंगसाठी मूलभूत फंक्शन्स—आणि त्यानंतर LLM त्याचे एका पूर्ण-वैशिष्ट्यपूर्ण रनटाइममध्ये (full-featured runtime) रूपांतर करते.
या पेपरमधील बेंचमार्कमध्ये, मॉडेलने 18 वेगळे हार्नेसेस तयार केले, ज्यामध्ये मूळ सीडमध्ये 17,000 पेक्षा जास्त ओळींचा कोड जोडला गेला. प्रत्येक हार्नेसने कार्याचे संपूर्ण जीवनचक्र (life-cycle) व्यवस्थापित केले: लूप्स कार्यान्वित करणे, योग्य टूल निवडणे, कॉन्टेक्स्ट राखणे, स्टेट ट्रॅक करणे, निकालांचे व्हेरिफिकेशन करणे आणि त्रुटींमधून (errors) सावरणे.
अभ्यासात समोर आलेले छुपे खर्च (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% अचूकता हे दर्शवते की व्हेरिफिकेशनकडे दुर्लक्ष करून चालणार नाही.
- टोकन बजेटवर लक्ष ठेवा – अधिक क्लिष्ट हार्नेसेसमुळे टोकनची संख्या प्रचंड वाढू शकते. छुपे खर्च टाळण्यासाठी सुरुवातीलाच वेगवेगळ्या हार्नेस व्हेरिएंट्सचे प्रोफाइलिंग करा.
- वेगवेगळ्या मॉडेल्सवर चाचणी करा – तोच हार्नेस अनेक LLM बॅक-एंड्ससह चालवून पहा. जर कामगिरीमध्ये मोठी घट होत असेल, तर तुम्हाला अधिक मॉडेल-अग्नोस्टिक (model-agnostic) डिझाइन किंवा प्रत्येक मॉडेलसाठी स्वतंत्र हार्नेसेसची आवश्यकता असू शकते.
थोडक्यात सांगायचे तर: HarnessDev हे सिद्ध करते की LLMs स्वतःचे ऑपरेटिंग-सिस्टमसारखे कंट्रोल कोड लिहू शकतात.