HarnessDev: LLMs अपना स्वयं का इंफ्रास्ट्रक्चर बना रहे हैं

ByteDance और विश्वविद्यालयों के एक समूह ने HarnessDev लॉन्च किया है, जो एक ऐसा फ्रेमवर्क है जो लार्ज लैंग्वेज मॉडल्स (LLMs) को अपने स्वयं के "एजेंट ऑपरेटिंग सिस्टम" लिखने की अनुमति देता है, जिन्हें Agent Harnesses कहा जाता है। टीम एक LLM को एक छोटा सा स्टार्टर किट देती है और उसे बाकी का काम पूरा करने देती है, जिससे यह पता चलता है कि AI कैसे उस कंट्रोल लेयर का निर्माण कर सकता है जो अपने स्वयं के टूल-यूज़ लूप्स, वेरिफिकेशन स्टेप्स और एरर हैंडलिंग को चलाती है—बिना किसी इंसान द्वारा हर लाइन टाइप किए।

स्वयं-निर्मित हार्नेस (harness) क्यों महत्वपूर्ण है

AI एजेंट सिंगल-प्रॉम्प्ट असिस्टेंट से विकसित होकर मल्टी-स्टेप वर्कर बन गए हैं जो APIs को कॉल करते हैं, डेटाबेस को क्वेरी करते हैं और परिणामों को आपस में जोड़ते हैं। अब तक, डेवलपर्स ऑर्केस्ट्रेशन कोड को खुद तैयार करते थे जो मॉडल को बताता था कि सर्च टूल कब कॉल करना है, इंटरमीडिएट स्टेट को कैसे स्टोर करना है, और अंतिम उत्तर को कैसे सत्यापित (verify) करना है। HarnessDev इस मॉडल को बदल देता है: एक seed harness केवल पर्याप्त स्कैफोल्डिंग (scaffolding) प्रदान करता है—लूपिंग, टूल चुनने और स्टेट को ट्रैक करने के लिए बुनियादी फंक्शन—और LLM इसे एक पूर्ण-सुविधा वाले रनटाइम (runtime) में विस्तारित कर देता है।

पेपर के बेंचमार्क में, मॉडल ने 18 अलग-अलग हार्नेस तैयार किए, जिससे मूल सीड में 17,000 से अधिक लाइनों का कोड जुड़ गया। प्रत्येक हार्नेस ने एक कार्य के पूर्ण जीवन-चक्र (life-cycle) को प्रबंधित किया: लूप्स को निष्पादित करना, सही टूल चुनना, कॉन्टेक्स्ट बनाए रखना, स्टेट को ट्रैक करना, परिणामों को सत्यापित करना और त्रुटियों (errors) से उबरना।

अध्ययन में सामने आए छिपे हुए खर्च

आंकड़े प्रभावशाली दिखते हैं, लेकिन लेखक चेतावनी देते हैं कि केवल कार्यान्वयन (implementation) का अर्थ व्यावहारिक उपयोग नहीं है।

  • अनुपयोगी घटक (Unused components) – जनरेट किए गए कोड का एक बड़ा हिस्सा वास्तविक कार्य निष्पादन के दौरान कभी नहीं चला। LLM ने ऐसे फंक्शन लिखे जिन्हें एजेंट ने कभी कॉल नहीं किया, जिससे बिना किसी मूल्य के कोड बेस अनावश्यक रूप से बढ़ गया।
  • मॉडल लॉक-इन (Model lock-in) – हार्नेस उस विशिष्ट LLM के अनुसार ट्यून होने की प्रवृत्ति रखते थे जिसने उन्हें बनाया था। जब वही हार्नेस किसी अन्य मॉडल को दिया गया, तो प्रदर्शन में उल्लेखनीय गिरावट आई, जिससे पता चलता है कि ऑटो-जेनरेटेड कंट्रोल लॉजिक में मॉडल-विशिष्ट विशेषताएं (quirks) शामिल हो जाती हैं।
  • सत्यापन अंतराल (Verification gaps) – एक टेस्ट हार्नेस ने 99% की सफलता दर (100 में से 99 रन) की रिपोर्ट की, लेकिन वह केवल 48% समय ही सही था। मजबूत सत्यापन के बिना, एक एजेंट आत्मविश्वास के साथ गलत उत्तर दे सकता है।
  • टोकन ओवरहेड (Token overhead) – टोकन का उपयोग—जो कंप्यूट लागत का एक पैमाना है—काफी भिन्न था। एक ही परिणाम प्राप्त करने के लिए एक हार्नेस को दूसरे की तुलना में सात गुना अधिक टोकन की आवश्यकता पड़ी, जिससे प्रोडक्शन सेटिंग्स में स्केलेबिलिटी को लेकर चिंताएं बढ़ गईं।

ये निष्कर्ष अनुशासित डिजाइन की आवश्यकता पर प्रकाश डालते हैं, भले ही कोड किसी LLM से उत्पन्न हुआ हो।

डेवलपर्स को किन बातों का ध्यान रखना चाहिए

  1. हार्नेस डिजाइन को आर्किटेक्चर के रूप में मानें – मॉडल के "बस काम करने" पर भरोसा न करें। LLM को उन्हें भरने देने से पहले लूप कंट्रोल, टूल सिलेक्शन, स्टेट हैंडलिंग और वेरिफिकेशन के लिए स्पष्ट मॉड्यूल परिभाषित करें।
  2. मजबूत सत्यापन (Verification) बनाएं – स्पष्ट चेक शामिल करें जो एजेंट के दावे की तुलना ग्राउंड ट्रुथ (ground truth) या किसी सेकेंडरी मॉडल से करते हों। 99% स्व-रिपोर्ट की गई सफलता दर के बावजूद अध्ययन की 48% सटीकता यह दर्शाती है कि सत्यापन को बाद के विचार के रूप में नहीं छोड़ा जा सकता।
  3. टोकन बजट पर नज़र रखें – अधिक विस्तृत हार्नेस टोकन की संख्या को बहुत बढ़ा सकते हैं। छिपे हुए खर्चों के विस्फोट से बचने के लिए विभिन्न हार्नेस वेरिएंट्स का जल्दी प्रोफाइलिंग करें।
  4. विभिन्न मॉडल्स पर टेस्ट करें – एक ही हार्नेस को कई LLM बैक-एंड के साथ चलाएं। यदि प्रदर्शन में भारी गिरावट आती है, तो आपको अधिक मॉडल-अज्ञेयवादी (model-agnostic) डिजाइन या प्रत्येक मॉडल के लिए अलग हार्नेस की आवश्यकता हो सकती है।

निष्कर्ष: HarnessDev यह साबित करता है कि LLMs अपने स्वयं के ऑपरेटिंग-सिस्टम जैसे कंट्रोल कोड का मसौदा तैयार कर सकते हैं।