बिग टेक की हार्नेस इंजीनियरिंग की व्यर्थता से संबंधित एक AI टाइम्स लेख सामने आया है, और इसके बाद कई तकनीकी नेताओं ने अपनी राय दी है। गूगल के बाद, OpenAI ने भी कहा है कि अगली पीढ़ी के मॉडल वर्तमान हार्नेस कार्यक्षमता के एक महत्वपूर्ण हिस्से को अवशोषित कर सकते हैं।
यह लेख भी उस बहस को आगे बढ़ाता है। निष्कर्ष पहले कहा जाए तो, मुझे लगता है कि अधिकांश हार्नेस व्यर्थ हो जाएंगे। मैंने खुद भी हार्नेस इंजीनियरिंग का संपूर्ण विवरण — जन्म, अवधारणा, अंतराल, और भविष्य एक बार में पोस्टिंग में लिखा था कि मॉडल की कमजोरियों को ठीक करने के लिए बनाए गए जटिल हार्नेस को मॉडल के बेहतर होने पर जल्दी ही बदल दिया जाता है।
लेकिन अगर इसके आधार पर कहा जाए कि सभी हार्नेस जल्द ही अनावश्यक हो जाएंगे, तो यह हार्नेस के सार को छोड़ देता है। मॉडल द्वारा कार्यक्षमता को अवशोषित करने की समस्या और मनुष्यों और संगठनों द्वारा AI को कार्य सौंपते समय जिम्मेदारी को प्रबंधित करने की समस्या अलग हैं।
पहले, हमें यह देखना चाहिए कि कीवर्ड कैसे फैलते हैं
लेकिन पहले, तकनीकी कीवर्ड आमतौर पर घरेलू बाजार में विदेशों से अलग तरीके और अर्थ से उपभोग किए जाते हैं, इसलिए मैंने पहले इसका सत्यापन किया। इस बार भी, हमें मूल कथन, वास्तविक तकनीकी चर्चा और घरेलू बाजार में बनाए गए ढांचे को अलग-अलग देखना चाहिए।
हार्नेस इंजीनियरिंग का संपूर्ण विवरण — जन्म, अवधारणा, अंतराल, और भविष्य एक बार में पोस्टिंग से हार्नेस इंजीनियरिंग कीवर्ड की घरेलू और वैश्विक खपत की तुलना।
| तुलना | वैश्विक | कोरिया |
|---|---|---|
| चर्चा का नेतृत्व | इंजीनियर और व्यावहारिक विशेषज्ञों के सार्वजनिक विश्लेषण केंद्र में हैं। Hashimoto, Martin Fowler जैसे व्यावहारिक विशेषज्ञों के लेख और केस स्टडीज इसका आधार बनाते हैं। | मीडिया, शिक्षा मंच और कुछ तकनीकी प्रभावशाली लोगों के लेख, सारांश और व्याख्याएं तेजी से फैलती हैं। |
| मुख्य चैनल | GitHub, तकनीकी ब्लॉग, X (ट्विटर), आधिकारिक केस स्टडीज | YouTube, Brunch, ब्लॉग, लेख |
| गहरी जानकारी | OpenAI केस स्टडीज, Martin Fowler विश्लेषण जैसे मूल पाठ, कोड और परिचालन अनुभव को एक साथ देखता है। | अनुवाद और सारांश-केंद्रित वितरण का एक बड़ा अनुपात है, और प्राथमिक केस उत्पादन अपेक्षाकृत कम है। |
| वास्तविक उपयोग साझा करना | Stripe के सप्ताह में 1,000 से अधिक PR प्रसंस्करण केस, Salesforce जैसी कंपनियां परिचालन संख्याएं और विफलता के अनुभव सार्वजनिक करती हैं। | Toss और Channel Talk जैसी कुछ अग्रणी कंपनियां वास्तविक उपयोग के अनुभव साझा करती हैं, लेकिन पूरे उद्योग में एक सामान्य केस के रूप में सामान्यीकरण अभी भी जल्दबाजी है। |
इस बार भी, इसकी विस्तृत व्याख्या करना सावधानी से करना चाहिए क्योंकि अंग्रेजी बोलने वाले क्षेत्रों में "हार्नेस मर गया" या "हार्नेस व्यर्थ है" एक व्यापक नारा नहीं है। मॉडल की टूल उपयोग क्षमता में सुधार हो रहा है और कुछ स्कैफोल्डिंग मॉडल या प्लेटफॉर्म में अवशोषित हो रहे हैं, और मैन्युअल रूप से निर्मित जटिल समन्वय परतों का जीवनकाल कम हो सकता है, यह अधिक सटीक चर्चा है। नोएम ब्राउन उपाध्यक्ष के बयान को भी, मैंने सीधे मूल स्रोत तक की पुष्टि नहीं की है और घरेलू और अंतर्राष्ट्रीय रिपोर्टों के माध्यम से इसे जाना है। इसलिए मैं घरेलू बाजार में तेजी से सेट किए गए 'हार्नेस व्यर्थता सिद्धांत' के ढांचे को देखूंगा।
जो हार्नेस गायब हो जाएंगे और जो रहने चाहिए वे अलग हैं
जो हार्नेस गायब हो जाएंगे वह स्पष्ट है। प्रॉम्प्ट को कई चरणों में विभाजित करना होता था, विशेष मॉडल की कमजोरियों को दरकिनार करने के लिए अस्थायी नियम, टूल कॉल ऑर्डर को लोगों द्वारा मजबूर करना ये उथले कार्यप्रवाह मॉडल के बेहतर होने पर अवशोषित हो सकते हैं। ये हार्नेस गायब होना सही है।
हालांकि, A2Sys के नेता डोंग्सू ली द्वारा व्यवस्थित तरीके के अनुसार, इसे सभी हार्नेस के लिए विस्तारित व्याख्या करना खतरनाक है। संक्षेप में:
- प्रॉम्प्ट और कार्य प्रवाह हार्नेस मॉडल द्वारा अवशोषित हो सकते हैं। मैं सहमत हूं।
- टूल निष्पादन हार्नेस अनुमति, अनुमोदन, विफलता वसूली से संबंधित है। क्या यह वास्तव में गायब हो जाने वाला हार्नेस है?
- रनटाइम, मेमोरी, बुनियादी ढांचा हार्नेस संदर्भ, कैश, मॉडल राउटिंग, लागत, विलंब, ऑडिट ट्रेल से संबंधित है। मुझे यह भी लगता है कि यह गायब होने वाले हार्नेस के रूप में देखना मुश्किल है।
मैंने 『हार्नेस इंजीनियरिंग: Re:शून्य से शुरुआत करने वाली AI सॉफ़्टवेयर इंजीनियरिंग』 के 7 अध्याय से 11 अध्याय में हार्नेस की मूल बात कही थी। अनुबंध अनुमति की सीमा निर्धारित करता है, संरचना और अलगाव परिवर्तन की सीमा को संकीर्ण करता है, ट्रेसेबिलिटी और सत्यापन मूल लक्ष्य और वास्तविक परिणाम को जोड़ता है। माप और संचालन लागत, अनुमति, विफलता, वसूली को प्रबंधित करता है। इस सीमा के हार्नेस इंजीनियरिंग मॉडल के बेहतर होने से हल नहीं होते हैं।
दूसरी ओर, हार्नेस, लूप, प्रॉम्प्ट इंजीनियरिंग मानवीय अनुमान के बारे में बात करना भी सही है। सभी तरीके अनुमान से शुरू होते हैं। प्रकार, परीक्षण, CI, कोड समीक्षा, अनुमति विभाजन सभी जटिल प्रणालियों से निपटने के लिए मनुष्य द्वारा बनाए गए हैं। लेकिन यहां अधिक महत्वपूर्ण सवाल है: क्या हम पारदर्शिता और जिम्मेदारी को पूरी तरह से फ्लैगशिप मॉडल को सौंप सकते हैं? काम सौंपा गया है तो यह सही तरीके से इरादे के अनुसार किया जा रहा है या नहीं, AI खुद यह नहीं कर सकता। बेशक, AI को निरीक्षण और सुधार करने वाला AI हो सकता है, लेकिन तब यह एक हार्नेस है।
मैंने हान सांग-की प्रोफेसर की पोस्ट पर टिप्पणी में इस स्थिति को इस तरह लिखा था:
हार्नेस इंजीनियरिंग को कहां तक देखते हैं, इस पर यह निर्भर करता है। जब तक संगठन और डेवलपर का इरादा है, तब तक यह गायब होना मुश्किल है।
मॉडल जितना अधिक चतुर होगा, AI उतना ही गलत काम को अधिक सुंदरतापूर्वक पूरा करने की संभावना है। इसलिए हार्नेस मॉडल की कमजोरी को ठीक करने का उपकरण नहीं है, बल्कि दिशा और जिम्मेदारी को ठीक करने का संचालन उपकरण है।
वास्तविक संचालन में, मॉडल क्षमता से पहले जिम्मेदारी सीमा आती है
Nextain विकास अनुरोध करने वाली कंपनियों के साथ Discord पर काम करता है। और आज मैंने यहां एक विशेष समस्या को हल कर रहे Claude Code के एजेंट को जोड़ा। Discord में भाग लेने वाले Nextain एजेंट (वास्तव में सर्वर पर चलने वाला Claude Code) Discord चैनल पढ़ता है और उत्तर देता है।
चैनल में एक साथ गैर-विकास कर्मचारी परिचालन करने वाले ने परीक्षा परिणाम, कमियां और आवश्यकताएं बताईं। और इसके लिए, जो कुछ संभव है उसे प्रक्रिया किया, लेकिन जब महत्वपूर्ण परिनियोजन या संसाधन को छूना है जो नहीं करना चाहिए, तो वह मुझसे अनुमति मांगता है।
साथ ही, शुरुआत में जब इसे शुरू किया गया था, तो आवश्यकताएं सुनकर सीधे काम करना शुरू कर दिया, यह देखते हुए कि काम के लिए जिम्मेदार लोग असंतुष्ट हो रहे थे, मैंने काम की प्रक्रिया बताई। आवश्यकताएं सुनें, उसे स्वीकार करते हुए जवाब दें, विश्लेषण करें, योजना बनाएं, फिर योजना को Discord चैनल में वापस रिपोर्ट करें, और फिर काम आगे बढ़ाएं। और अंत में काम पूरा होने पर अंतिम रिपोर्ट दें, और अगर बीच में कोई समस्या आए तो मुझे (विकास नेता) कॉल करें और निर्णय के लिए Discord पर पूछें।
इस हार्नेस का मूल Nextain की विकास प्रक्रिया और प्रत्येक सदस्य की अनुमति है। अगर यह फ्लैगशिप है तो क्या यह खुद-ब-खुद सबसे अच्छे तरीके से काम करेगा? क्या सबसे अच्छा तरीका वास्तव में एक ही है? संगठन और काम की प्रक्रिया की स्थिरता अंततः एक हार्नेस है। यह जिम्मेदारी सीमा मॉडल की क्षमता से अलग है। मॉडल जितना अधिक काम कर सकता है, उतना ही अधिक कठोरता से यह तय करना चाहिए कि क्या किया जा सकता है और कहां रुकना चाहिए।
वर्तमान समस्या ड्रिफ्ट और लागत है
Codex और Claude का उपयोग करने वाले विकास कर्मचारियों को अभी भी ड्रिफ्ट की समस्या का सामना करना पड़ता है। लक्ष्य को कम करने के बाद भी एक अलग दिशा में बहता है, न करने के लिए कहे गए परिवर्तन करता है, परीक्षा बदलकर पास कहता है, और परिचालन अनुमति की सीमा को भूल जाता है। मॉडल जितना अधिक परिष्कृत होगा, यह समस्या उतनी ही अधिक चिकनाई से छिप सकती है।
तब "अधिक चलाएं तो ठीक है" यह जवाब बिग टेक के लिए संभव है। अनुमान समय बढ़ाएं, अधिक उम्मीदवार बनाएं, विफल पथ को छोड़ दें, बाहरी सत्यापन जोड़ें। लेकिन वर्तमान विकास कर्मचारी और हर पैसे को बचाने वाले छोटे स्टार्टअप ऐसा नहीं कर सकते। कोरियाई कंपनियों की वास्तविकता भी समान है।
ऊपर दिए गए हान सांग-की प्रोफेसर के साथ टिप्पणी में, पूर्व AI भविष्य योजना कार्यकारी सचिव Ha Jeong-woo ने जो "टोकन कुल लागत दक्षता" का उल्लेख किया है, वह ठीक यह मानदंड है। हार्नेस फ्लैगशिप मॉडल को अस्वीकार करने का उपकरण नहीं है। महंगे मॉडल को वास्तव में आवश्यक निर्णय के लिए ही उपयोग करना, और दोहराए जा सकने वाले काम को छोटे मॉडल, स्थानीय उपकरण, स्क्रिप्ट, निर्धारक सत्यापन में विभाजित करने के लिए लागत नियंत्रण उपकरण है।
हाल ही में OpenAI द्वारा जारी गणित संबंधित उपलब्धियों को भी दो समय बिंदुओं में विभाजित करने की आवश्यकता है। मैं Erdős समतल दूरी समस्या के संबंध में पहली उपलब्धि को मौजूदा दृष्टिकोण से अलग गणितीय कनेक्शन खोजने की संभावना के रूप में उच्च दर्जा देता हूं। यह AI ही दे सकता है ऐसी नई खोज की संभावना दिखाता है।
दूसरी ओर, बाद में अधिक प्रकाश डाला गया परीक्षण-समय कंप्यूटिंग अनुमान समय पर अधिक संगणना और उम्मीदवार खोज, सत्यापन, पुनरावृत्ति डालने की दिशा है। यह भी एक महत्वपूर्ण तकनीक है। लेकिन अगर इसे केवल एक मॉडल की शुद्ध बुद्धि सुधार के रूप में कहा जाए तो लागत संरचना गायब हो जाती है। यह मात्रा का संचालन भी है लेकिन बिग टेक के लिए विशेष रूप से अनुकूल तकनीक है।
हार्नेस लागत और डेटा की रक्षा पंक्ति है
"मॉडल हार्नेस को खा जाएगा" यह बयान उत्तेजक है। लेकिन वह मॉडल कौन कितने पर उपयोग करता है, यह अलग समस्या है। मॉडल जितनी अधिक कार्यक्षमता अवशोषित करेगा, उपयोगकर्ता का कोड सरल हो सकता है। साथ ही साथ, भारी और महंगे मॉडल कॉल पर अधिक निर्भरता हो सकती है। जटिलता गायब नहीं होती है, बल्कि उपयोगकर्ता के कार्यक्षेत्र से मॉडल प्रदाता के शुल्क परत में स्थानांतरित हो जाती है।
डेटा भी वैसा ही है। एजेंट वास्तव में उपयोगी होने के लिए दस्तावेज, कोड, अनुसूची, ईमेल, परिचालन लॉग, विफलता इतिहास, अनुमोदन प्रवाह, ग्राहक डेटा को देखना चाहिए। एजेंट कार्यक्षेत्र बन जाता है, उपयोगकर्ता का पूरा काम इनपुट बन जाता है।
अच्छा हार्नेस केवल आवश्यक संदर्भ बाहरी मॉडल को भेजता है और बाकी उपयोगकर्ता के कार्यक्षेत्र में रहता है। मॉडल को राउट करता है, कैश को फिर से उपयोग करता है, अनुमति विभाजित करता है, और दोहराए जा सकने वाले सत्यापन जोड़ता है। इसलिए हार्नेस लागत रक्षा पंक्ति है और डेटा रक्षा पंक्ति है।
इस दृष्टिकोण से देखें तो वैश्विक मॉडल कंपनी शक्तिशाली उपयोगकर्ता-पक्ष हार्नेस को असुविधाजनक पा सकती है। उपयोगकर्ता पहले छोटे मॉडल और स्थानीय उपकरण से संभालता है, केवल आवश्यक क्षण में फ्लैगशिप को बुलाता है तो कॉल की संख्या और भेजे गए संदर्भ कम हो जाते हैं। वास्तव में यह निश्चय नहीं है, लेकिन फ्रंटियर मॉडल विकास, अनुमान, GPU, बिजली की लागत बढ़ते उद्योग संरचना में स्वाभाविक रूप से विचार करने के लिए हित हैं।
OpenAI और Anthropic Codex और Claude Code के माध्यम से हार्नेस प्रतियोगिता के सबसे आगे हैं। दूसरी ओर, Google एक मॉडल कंपनी है और साथ ही एक क्लाउड व्यवसाय भी है। कंपनी के हित बिल्कुल समान नहीं हैं, लेकिन इस बहस को शुद्ध तकनीकी पूर्वानुमान के रूप में सुनना मुश्किल है। अच्छा हार्नेस बिग टेक की 'काम को मॉडल में स्थानांतरित करके डेटा एकत्र करने' और 'फ्लैगशिप उपयोग की निर्भरता को कम करता है।
लूप अगली पीढ़ी का डिफ़ॉल्ट नहीं है
लूप भी वैसा ही है। मैं लूप का उपयोग करता हूं, लेकिन मुझे लगता है कि अधिकांश मिशन के लिए लूप का उपयोग न करना बेहतर है। सामान्य विकास कर्मचारी को सौंपे जाने के बाद भी उपयुक्त परिणाम मिल सकते हैं, तो अच्छे मॉडल को एक बार सही उपयोग करना सस्ता और तेजी से हो सकता है। आश्चर्यजनक रूप से, लूप प्रभावी होने की स्थिति सीमित है।
पहला अनुसंधान और विकास है। कोई सही जवाब नहीं, प्रयोग के परिणाम के अनुसार परिकल्पना बदलती है, अगला प्रयोग पिछले परिणाम को पढ़ता है और सक्रिय रूप से बदलना चाहिए ऐसा काम। आंतरिक रूप से किया जाने वाला ध्वनि और गीत अनुसंधान ऐसा है। इस मामले में, प्रयोग परिणाम और सभी डेटा को कई AI समीक्षा करते हैं, मौजूदा प्रयोग के साथ निरंतरता, ड्रिफ्ट, अगले चक्र की आवश्यकता का फैसला करते हैं। पूर्णता का मानदंड संभावित परिणाम नहीं, बल्कि संकेतक अब और नहीं बढ़ रहे हैं ऐसा निर्णय है। खोज का अभिसरण लक्ष्य है इसलिए लूप सही है।
दूसरा सीमित वातावरण में छोटे मॉडल का उपयोग करना है। छोटा LLM लक्ष्य को कम करता है और "यह काफी है" पर रुकना आसान है। लेकिन इस मामले में आवश्यक है लंबे लूप से अधिक लक्ष्य और समाप्ति की स्थिति को बंद करने का उपकरण। लूप से अधिक Claude Code की goal कार्यक्षमता जैसे हार्नेस। सामान्य उपयोगकर्ता के दैनिक काम में लूप का अत्यधिक उपयोग करना लागत की बर्बादी है। लूप को खोज के अभिसरण के लिए उपयोग करें, हार्नेस को लक्ष्य और जिम्मेदारी को ठीक करने के लिए। दो विनिमय संबंध नहीं हैं।
Naia उपयोगकर्ता पक्ष पर कार्यक्षेत्र को रहने देना चाहता है
Naia फ्लैगशिप मॉडल को अस्वीकार नहीं करता। विकास में क्लाउड फ्लैगशिप मॉडल का सही तरीके से उपयोग करने का इरादा है। अच्छा मॉडल उपयोग करना चाहिए।
लेकिन सभी कार्यक्षेत्र और डेटा को बिग टेक प्लेटफॉर्म को सौंपने का इरादा नहीं है। Naia जो निर्देश दे रहा है वह स्थानीय, P2P, ओपन-वेट, छोटे मॉडल, निर्धारक सत्यापन, स्पष्ट अनुमति हार्नेस को एक साथ उपयोग करने की संरचना है। महंगे फ्लैगशिप का उपयोग आवश्यक निर्णय के लिए करें, लेकिन मौलिक कार्यक्षेत्र उपयोगकर्ता के हाथ में रहना चाहिए।
इस बिंदु से DeepSeek, Qwen, Kimi, GLM जैसे ओपन-वेट मॉडल का विकास महत्वपूर्ण है। उद्देश्य के अनुसार मॉडल को जोड़ें, स्थानीय रूप से डेटा रक्षा करें, आवश्यक क्षण में ही बंद फ्लैगशिप को कॉल करने की संरचना संभव बन सकती है। कोरिया में Upstage और Naver जैसी स्वतंत्र मॉडल रणनीति भी इस प्रवाह में अर्थपूर्ण है। वैश्विक बिग टेक के फ्लैगशिप को सीधे अनुसरण करने से, ओपन-वेट, स्वतंत्र मॉडल, विशेष हार्नेस, घरेलू काम संदर्भ को अच्छी तरह जोड़ने का मार्ग अधिक व्यावहारिक हो सकता है।
मॉडल उधार ले सकते हैं। लेकिन कार्यक्षेत्र और डेटा तक उधार देने की जरूरत नहीं है।
निष्कर्ष: व्यर्थता सिद्धांत से अधिक आवश्यक है तकनीकी स्तर की चर्चा
जो हार्नेस गायब हो जाएगा वह गायब हो जाएगा। मॉडल जो कार्यक्षमता को अवशोषित करेगा वह बढ़ेगी। इस बिंदु को नकारने का कोई कारण नहीं है। लेकिन मॉडल द्वारा अवशोषित कार्यक्षमता, संगठन के इरादे और जिम्मेदारी को ठीक करने वाली निष्पादन व्यवस्था, लागत और डेटा सीमा की रक्षा करने वाली परिचालन व्यवस्था गायब हो जाएगी ऐसा नहीं लगता। AI को काम देने वाला विषय मनुष्य है और परिणाम की जिम्मेदारी भी मनुष्य की है, तो अनुबंध, संरचना, ट्रेसेबिलिटी, सत्यापन, संचालन गायब नहीं होगा।
अब मुझे लगता है कि हार्नेस मर गया या जीवित है जैसे कीवर्ड बहस को देखना बंद कर दें। क्या मॉडल में डालना है, क्या उपयोगकर्ता और संगठन के नियंत्रण में रहना है, ड्रिफ्ट को कैसे सत्यापित और वापस करना है, टोकन लागत और डेटा एक्सपोजर को कौन वहन करेगा जैसे वास्तविक तकनीक केंद्रित चर्चा आगे आएं यह बेहतर होगा।
संदर्भ और स्रोत
मेरे लेख और पुस्तकें
- 『हार्नेस इंजीनियरिंग: Re:शून्य से शुरुआत करने वाली AI सॉफ़्टवेयर इंजीनियरिंग』
- 「हार्नेस इंजीनियरिंग का संपूर्ण विवरण — जन्म, अवधारणा, अंतराल, और भविष्य एक बार में」
- 「हार्नेस इंजीनियरिंग」प्रकाशन समाचार
इस बहस का प्रत्यक्ष कारण
- AI टाइम्स, "गूगल के बाद OpenAI भी 'हार्नेस व्यर्थता सिद्धांत'... अगली पीढ़ी के मॉडल कार्यक्षमता को अवशोषित करेंगे"
- AI टाइम्स, "[25 जून] 'मॉडल हार्नेस को खा जाएगा'..."
- हान सांग-की प्रोफेसर का Facebook पोस्ट और टिप्पणी चर्चा
- A2Sys के नेता डोंग्सू ली, "हार्नेस व्यर्थता सिद्धांत? आधा सही और आधा गलत है"
मूल पाठ और तकनीकी संसाधन
- OpenAI, "Learning to Reason with LLMs"
- OpenAI, "An OpenAI model has disproved a central conjecture in discrete geometry"
- OpenAI, "Introducing Codex"
- OpenAI, "Introducing OpenAI o3 and o4-mini"
- Google, "Gemini 2.0: our new AI model for the agentic era"
- "The Interplay of Harness Design and Post-Training in LLM Agents"
- "More Is Not Always Better: Cross-Component Interference in LLM Agent Scaffolding"
- "AutoHarness"
