IBM आख़िर एजेंट्स की तरफ़ क्यों मुड़ी
कॉर्पोरेट ग्राहक शायद ही कभी सिर्फ़ सुंदर डेमो के लिए कोई मॉडल ख़रीदता है। उसे चाहिए कि सॉफ़्टवेयर कुछ करे: टिकटें सुलझाए, बिल मिलाए, आंतरिक API को कॉल करे, दस्तावेज़ों की सारांश रिपोर्ट लिखे। यही जगह एजेंटिक लॉजिक भरता है — जब मॉडल सिर्फ़ सवाल का जवाब नहीं देता, बल्कि ख़ुद तय करता है कि अगला टूल कौन-सा बुलाना है।
इस कहानी में Granite 4.2 "एक और बड़ा मॉडल" नहीं है, बल्कि IBM की कोशिश है कि वह अपनी लाइनअप को ऐसे पूरा करे कि वह क्लाउड में और ग्राहक के बंद परिमंडल (closed perimeter) में एक जैसी भरोसेमंद तरीक़े से काम करे। दांव तीन चीज़ों के मेल पर लगाया जा रहा है: खुले वेट्स, हार्डवेयर पर कम मांग, और बाहरी फ़ंक्शन कॉल करते समय अनुमानित व्यवहार।
Granite लाइनअप आख़िर क्या है
IBM कई सालों से Granite नाम के तहत खुले मॉडलों का परिवार चला रही है। इस दौरान एक पहचानी जाने वाली फ़िलॉसफ़ी बनी है: मॉडल कई आकारों में आते हैं, मुख्य रूप से कोड, टेबल्स पर काम, दस्तावेज़ों से डेटा निकालने और कॉर्पोरेट परिदृश्यों पर केंद्रित हैं, न कि सामान्य चैट-बेंचमार्क में मुक़ाबले पर।
आकार मायने रखते हैं
लाइनअप एक सीढ़ी की तरह बनी है — बहुत छोटे विकल्पों से, जो एक ही ग्राफ़िक्स कार्ड पर समा जाते हैं या प्रोसेसर पर भी चलते हैं, लेकिन मध्यम श्रेणी के मॉडलों तक। मतलब यह है कि हर काम के लिए न्यूनतम ज़रूरी आकार चुना जा सके। ऐसे एजेंट के लिए, जो मुख्य रूप से अनुरोध रूट करता है और फ़ंक्शन कॉल करता है, विशाल मॉडल अक्सर ज़रूरत से ज़्यादा होता है: inference में महंगा और जवाब देने में धीमा।
हाइब्रिड आर्किटेक्चर
परिवार की चौथी शाखा में IBM हाइब्रिड स्कीम पर आ गई है, जहाँ कुछ लेयर Mamba पर और कुछ क्लासिक ट्रांसफ़ॉर्मर अटेंशन पर बनी हैं। व्यावहारिक फ़ायदा साधारण है: लंबा कॉन्टेक्स्ट सस्ते में संभाला जाता है, मेमोरी कम खर्च होती है, और उसी हार्डवेयर पर थ्रूपुट ज़्यादा होता है। एजेंटिक परिदृश्यों के लिए यह अहम है, क्योंकि कॉन्टेक्स्ट में लगातार टूल कॉल के नतीजे, दस्तावेज़ों के अंश और चरणों का इतिहास जुड़ते रहते हैं।
बिना किसी झटके वाला लाइसेंस
Granite मॉडल Apache 2.0 लाइसेंस के तहत बाँटे जाते हैं। कॉर्पोरेट वकील के लिए यह उबाऊ ख़बर है, और यही अच्छी ख़बर है: आप फ़ाइन-ट्यून कर सकते हैं, किसी कमर्शियल प्रोडक्ट में शामिल कर सकते हैं, अपने परिमंडल के अंदर तैनात कर सकते हैं, और विक्रेता को यह बताने की ज़रूरत नहीं कि प्रोडक्ट ने कितना कमाया।
मुख्य तर्क: इसे अपने पास रखा जा सकता है
क्लाउड API तभी तक सुविधाजनक हैं, जब तक डेटा नियामकीय पाबंदियों के दायरे में न आ जाए। बैंक, क्लिनिक, औद्योगिक उद्यम या सरकारी संस्था अक्सर शारीरिक रूप से कुछ दस्तावेज़ बाहर नहीं भेज सकती। यहीं "अपने हार्डवेयर" की बात शुरू होती है।
चलाने के लिए असल में क्या चाहिए
यहाँ मुख्य बात टॉप-एंड एक्सेलेरेटर नहीं, बल्कि समझदार न्यूनतम है। Granite के छोटे वर्शन एक कंज़्यूमर कार्ड पर, बिना GPU वाले सर्वर के कंटेनर में या डेवलपर के लैपटॉप पर चल जाते हैं। मध्यम आकारों के लिए कई कार्ड या क्वांटाइज़ेशन चाहिए। लॉन्च आम तौर पर vLLM या Ollama जैसे मानक टूल्स से होता है, जिससे विक्रेता के ख़ास स्टैक से बँधने की समस्या हल हो जाती है।
सुरक्षा और अनुमानित व्यवहार
तर्क की दूसरी परत है — नियंत्रण। जब मॉडल आपके परिमंडल में रहता है, तो आप ख़ुद तय करते हैं कि कौन-से लॉग लिखे जाएँ, कौन-सा डेटा prompt में जाए, क्या कैश हो और कितनी देर रहे। एजेंट्स के लिए यह ख़ास तौर पर अहम है: वे सिर्फ़ टेक्स्ट नहीं बनाते, बल्कि काम भी कर सकते हैं, और हर ऐसे काम को अपने नियमों और ऑडिट से गुज़ारना बेहतर है।
IBM यहाँ सिर्फ़ मॉडल नहीं, बल्कि उसके चारों तरफ़ का ढाँचा भी बेचती है: watsonx प्लेटफ़ॉर्म, अवांछित कॉन्टेंट फ़िल्टर करने के लिए "गार्ड" मॉडलों का सेट, और अपने डेटा पर फ़ाइन-ट्यूनिंग के टूल्स। ऐसी स्कीम में मॉडल एक हिस्सा है, भले ही केंद्रीय हो।
व्यवहार में एजेंटिक परिदृश्य कैसा दिखता है
एजेंट का विचार सरल है: मॉडल को काम मिलता है, वह तय करता है कि उसे कौन-सा डेटा नहीं है, ज़रूरी टूल बुलाता है, जवाब पढ़ता है और तब तक आगे बढ़ता है जब तक नतीजे तक न पहुँच जाए। "सिर्फ़ चैट" और एजेंट के बीच फ़र्क़ है — लूप और अधिकारों का होना।
ऐसे मॉडलों को जिन ख़ास भूमिकाओं के लिए तैयार किया जाता है:
- राउटर। आने वाली बात को समझता है और तय करता है कि किस परिदृश्य को भेजना है।
- निकालने वाला। बिल, अनुबंध, स्टेटमेंट से फ़ील्ड निकालता है और उन्हें संरचना में रखता है।
- निष्पादक। आंतरिक सिस्टम के API बुलाता है: अनुरोध बनाता है, स्टेटस अपडेट करता है, ईमेल भेजता है।
- समीक्षक। पिछले चरण के नतीजे की जाँच करता है और तय करता है कि उसे स्वीकार किया जा सकता है या नहीं।
इनमें से हर चरण पर छोटा मॉडल अक्सर एक बड़े मॉडल से ज़्यादा फ़ायदेमंद होता है: सस्ता, तेज़, टेस्ट करने में आसान और, जो कम अहम नहीं, अगर गुणवत्ता संतोषजनक न रहे तो बदलना आसान।
किन बातों पर ध्यान दें और सीमाएँ कहाँ हैं
खुले मॉडल कोई जादुई गोली नहीं हैं, और सीमाओं पर ईमानदार बातचीत मार्केटिंग से ज़्यादा उपयोगी है।
आकार बनाम तर्क की गुणवत्ता
छोटे मॉडल किफ़ायती हैं, लेकिन जटिल बहु-चरणीय कामों में अब भी बड़े मॉडलों से पीछे हैं। समझौता आम तौर पर आर्किटेक्चर के स्तर पर खोजा जाता है: भूमिकाएँ कई छोटे मॉडलों में बाँटी जाती हैं, कोड पर नियतात्मक जाँचें जोड़ी जाती हैं, और अंतिम फ़ैसले का अधिकार इंसान के पास रखा जाता है।
आसपास का इकोसिस्टम
खुले वेट्स का मतलब है कि मॉडल फ़्रेमवर्क के बीच आसानी से ले जाया जा सकता है — LangChain से लेकर ख़ुद लिखे ऑर्केस्ट्रेटर तक। दूसरी तरफ़: किसी ख़ास उद्योग के लिए तैयार "ऑफ़-द-शेल्फ़" समाधान प्रोप्राइटरी प्लेटफ़ॉर्म से कम हैं, और इंटीग्रेशन का कुछ काम ग्राहक की टीम पर आता है।
हार्डवेयर और स्वामित्व लागत
अपना हार्डवेयर सिर्फ़ API पर बचत नहीं है, बल्कि पूँजीगत ख़र्च, बिजली, कूलिंग और उसे सँभालने वाले लोग भी हैं। छोटी कंपनी के लिए क्लाउड लगभग हमेशा सस्ता पड़ेगा; संवेदनशील डेटा वाली बड़ी कंपनी के लिए इसका उल्टा, और यह सीमा मात्रा के हिसाब से खिसकती रहती है।
गुणवत्ता का मूल्यांकन
सबसे बड़ा जाल सामान्य बेंचमार्क से एजेंट मापना है। काम करने वाले एजेंट की जाँच उसके अपने परिदृश्यों पर होती है: ज्ञात सही जवाब वाले असली कामों के सेट पर, कच्चे इनपुट डेटा के प्रति स्थिरता पर, और तब के व्यवहार पर जब बुलाया गया टूल एरर लौटाए। ऐसे सेट के बिना रिलीज़ नोट का कोई भी आँकड़ा रिलीज़ नोट का आँकड़ा ही रहता है।
इससे क्या निकलता है
बाज़ार के मौजूदा दौर पर IBM की प्रतिक्रिया तर्कसंगत लगती है। जहाँ कुछ लोग क्लाउड में अधिकतम गुणवत्ता के पीछे भाग रहे हैं, वहीं दूसरे उस जगह को भर रहे हैं जहाँ नियंत्रण, प्रति टोकन क़ीमत और सब कुछ अपने परिमंडल में तैनात करने की क्षमता ज़्यादा मायने रखती है। खुले वेट्स के साथ संसाधनों पर कम मांग और टूल कॉलिंग पर ज़ोर — यही वह सेट है जो उस कॉर्पोरेट ग्राहक को चाहिए, जो डेटा बाहर भेजने की मंज़ूरी दिलाने से थक चुका है।
असली सवाल यह नहीं है कि नया वर्शन सामान्य टेस्टों में लीडरों से आगे निकलेगा या नहीं। सवाल यह है कि टीम में इतनी अनुशासन है या नहीं कि मॉडल के चारों तरफ़ एक ठीक-ठाक एजेंटिक परिमंडल बनाया जाए: सीमित अधिकारों, ऑडिट, टेस्ट और स्पष्ट रोलबैक के साथ। अगर हाँ — तो ऐसे एजेंट को अपने हार्डवेयर पर रखना एक बिल्कुल काम का रणनीति बन जाता है, कोई समझौता नहीं।
