Jev वास्तव में क्या कर सकता है? 10 सामुदायिक प्रोजेक्ट्स से इसके उपयोग समझें

वेबसाइट ब्राउज़ करना, किसी Agent का कॉन्टेक्स्ट साफ़ करना, इंटरफ़ेस बनाना, विज्ञापन फ़िल्टर करना, गेम नियंत्रित करना, ईमेल वर्गीकृत करना और YouTube के प्रायोजित हिस्सों को छोड़ना—इन सभी Jev प्रोजेक्ट्स को साथ देखने पर आसानी से लग सकता है कि यह मॉडल लगभग सब कुछ कर सकता है।

लेकिन हर workflow को अलग-अलग देखने पर इसकी भूमिका कहीं अधिक सीमित दिखाई देती है। Jev सामान्यतः केवल एक छोटे चरण का काम करता है: मौजूदा स्थिति के आधार पर एक संरचित निर्णय लेना। पेज को पार्स करना, आवाज़ को टेक्स्ट में बदलना, ऑर्डर भेजना या वीडियो में आगे जाना अब भी सामान्य कोड, विशेष सेवाओं या दूसरे मॉडलों द्वारा किया जाता है।

Jev को समझने की असली कुंजी यही अंतर है। इसका मूल्य पूरी प्रक्रिया में चैट मॉडल की जगह लेने में नहीं, बल्कि उन चरणों को—जहाँ भाषा मॉडल को “सोचना, लिखना और फिर उसके उत्तर को पार्स कराना” पड़ता—ऐसे चुनाव, स्कोर या प्रायिकताओं में बदलने में है जिन्हें सॉफ़्टवेयर सीधे इस्तेमाल कर सके।

Jev सामान्य चैट मॉडल से कैसे अलग है?

TypeSafe, Jev को पहला System One मॉडल कहता है। डेवलपर इसे दो चीज़ें देते हैं: वर्तमान स्थिति बताने वाला state और टाइप के साथ परिभाषित typed questions का एक समूह। लंबा उत्तर लौटाने के बजाय Jev तीन प्रकार के संरचित निर्णय देता है:

प्रकार	किस तरह के प्रश्न के लिए	सामान्य परिणाम
Choice	कौन-सी श्रेणी, कार्रवाई या टूल चुना जाए?	एक विकल्प और हर विकल्प की प्रायिकता
Score	गंभीरता, प्रासंगिकता या गुणवत्ता किस स्तर पर है?	एक स्कोर और हर स्तर की प्रायिकता
Noul	क्या कोई कथन सही है?	0 से 1 तक की प्रायिकता

उदाहरण के लिए, एक ब्राउज़र Agent मौजूदा पेज के DOM, उपयोगकर्ता के लक्ष्य और उपलब्ध कार्रवाइयों को state में व्यवस्थित करके Jev से पूछ सकता है: “अगला क्लिक किस एलिमेंट पर होना चाहिए?” परिणाम मिलने के बाद प्रोग्राम क्लिक करता है। यदि किसी इनपुट फ़ील्ड में टेक्स्ट लिखना हो, तो वह हिस्सा अब भी किसी generative मॉडल को दिया जाता है।

इसलिए सही workflow “Jev पूरी टास्क करता है” नहीं, बल्कि यह है:

मौजूदा स्थिति या घटना
      ↓
Jev: चुनना, स्कोर करना या निर्णय देना
      ↓
सामान्य कोड: निष्पादित करना, क्रम देना, फ़िल्टर करना, रोकना या किसी व्यक्ति को सौंपना

नीचे दिए गए दस प्रोजेक्ट्स परिपक्वता की रैंकिंग नहीं हैं। इन्हें Jev की भूमिका के आधार पर तीन समूहों में समझना अधिक उपयोगी है: कार्रवाई की परत, सूचना की परत और workflow की परत।

1. कार्रवाई की परत: Jev अगला कदम चुनता है, प्रोग्राम उसे निष्पादित करता है

1. Browser Use: वेब इंटरैक्शन को संभावित कार्रवाइयों के चुनाव में बदलना

Browser Use के jev-ultrafast implementation में प्रोग्राम पहले पेज का DOM पढ़ता है और उस समय उपलब्ध कार्रवाइयों का एक समूह बनाता है—जैसे किसी बटन पर क्लिक करना, कोई विकल्प चुनना या अगले पेज पर जाना। Jev स्वतंत्र रूप से यह नहीं लिखता कि वेबसाइट पर कैसे आगे बढ़ना चाहिए; वह तैयार किए गए विकल्पों में से अगला कदम चुनता है।

यह डिज़ाइन Jev के लिए उपयुक्त है क्योंकि हर निर्णय-चक्र में तीन बातें पहले से तय हैं: स्थिति को प्रोग्राम ने व्यवस्थित कर दिया है, कार्रवाई का समूह सीमित है और कोड जानता है कि चुनी गई कार्रवाई कैसे निष्पादित करनी है। जब प्रस्थान या गंतव्य जैसी जानकारी लिखनी हो, तो सिस्टम अब भी एक छोटे generative मॉडल को बुलाता है; Jev स्वयं वह टेक्स्ट नहीं बनाता।

लेखक ने बताया कि एक फ़्लाइट खोज में लगभग 7 सेकंड लगे और लागत करीब $0.0039 रही, जबकि डेमो वीडियो सामान्य गति पर चलाया गया। ये आँकड़े उस निश्चित workflow के परिणाम बताते हैं, लेकिन यह सिद्ध नहीं करते कि हर वेबसाइट या हर टास्क उसी गति और सफलता दर पर चलेगी। MVP अभी shadow DOM, iframe, canvas और फ़ाइल अपलोड जैसी संरचनाओं को भी कवर नहीं करता।

इस उदाहरण से मुख्य सीख यह नहीं है कि “Jev वेब ब्राउज़ कर सकता है”, बल्कि यह है कि पहले कोड से कार्रवाई का दायरा छोटा किया जाए और फिर मॉडल से सीमित चुनाव कराया जाए।

2. वॉइस ब्राउज़र: Jev, speech recognition और ब्राउज़र निष्पादन के बीच काम करता है

वॉइस से नियंत्रित ब्राउज़र में जिम्मेदारियों का बँटवारा और स्पष्ट हो जाता है। माइक्रोफ़ोन आवाज़ कैप्चर करता है, speech service उसे टेक्स्ट में बदलती है, सिस्टम मौजूदा पेज पढ़कर निष्पादित की जा सकने वाली कार्रवाइयाँ तैयार करता है, Jev एक कार्रवाई चुनता है और ब्राउज़र उसे चलाता है।

लेखक के अनुसार Jev का एक निर्णय लगभग 300 मिलीसेकंड लेता था और उसकी लागत करीब $0.0002 थी। लेकिन यह केवल निर्णय वाले चरण का आँकड़ा है। इसमें ऑडियो कैप्चर, speech transcription, पेज पर एलिमेंट खोजने, नेटवर्क ट्रांसफ़र या ब्राउज़र निष्पादन का समय शामिल नहीं है। इसलिए “Jev तेज़ निर्णय लेता है” का अर्थ यह नहीं कि पूरी वॉइस इंटरैक्शन केवल 300 मिलीसेकंड में हो जाती है।

यह तरीका “यह टैब खोलो”, “submit पर क्लिक करो” या “नीचे स्क्रॉल करो” जैसे आदेशों के लिए अधिक उपयुक्त है, जिन्हें सीमित कार्रवाई-सूची से जोड़ा जा सकता है। यदि उपयोगकर्ता लिखने, सारांश बनाने या समझाने वाला काम चाहता है, तो workflow को अब भी सामान्य प्रयोजन वाले मॉडल की आवश्यकता होगी।

3. Doom और Mario: गेम के पिक्सेल नहीं, संरचित स्थिति पढ़ना

गेम डेमो अक्सर सबसे अधिक ध्यान खींचते हैं। सार्वजनिक Doom प्रोजेक्ट में स्थिति, दुश्मन, हथियार और दूसरी जानकारी को संरचित टेक्स्ट state में बदला जाता है। Jev उसके बाद चलने, हमला करने या दूसरी कार्रवाई का चुनाव करता है और प्रोग्राम वह चुनाव गेम को वापस भेजता है।

लेखक ने लगभग 10 calls प्रति सेकंड और करीब $7 प्रति घंटे की लागत बताई। फिर भी इसे “Jev सीधे स्क्रीन समझता है और अपने-आप गेम खेलता है” नहीं कहा जाना चाहिए। TypeSafe के launch materials स्पष्ट रूप से बताते हैं कि Doom डेमो raw pixels के बजाय structured text state का उपयोग करता है। Mario जैसे सामुदायिक प्रोजेक्ट्स भी ऐसे प्रयोगों के अधिक करीब हैं जहाँ state निर्णय-चक्र में जाता है और मॉडल कार्रवाई चुनता है।

ये उदाहरण दिखाते हैं कि तेज़ निर्णय real-time loop में शामिल हो सकते हैं। वे यह नहीं दिखाते कि Jev के पास सामान्य दृश्य समझ या लंबे समय की गेम planning क्षमता है।

4. Real-time trading: तेज़ चुनाव से रणनीति की लाभप्रदता सिद्ध नहीं होती

Trading डेमो भी इसी तरह की संरचना अपनाते हैं। कीमतों, assets और बाज़ार की स्थिति को व्यवस्थित करके Jev को भेजा जाता है; मॉडल buy या sell चुनता है; और प्रोग्राम ऑर्डर भेजता है। एक दूसरे सामुदायिक प्रोजेक्ट ने लगभग 300 मिलीसेकंड की block cadence के साथ चलने का दावा किया।

उपलब्ध सामग्री में return, drawdown, slippage, fees का प्रभाव या पूर्ण risk-control परिणाम प्रकाशित नहीं हैं। इसलिए यह उदाहरण केवल इतना दिखाता है कि Jev को low-latency trading prototype में रखा जा सकता है। इससे रणनीति के लाभदायक होने का प्रमाण नहीं मिलता, और execution speed को investment performance नहीं माना जाना चाहिए।

वास्तविक सिस्टम में position limits, stop-loss, permissions, order validation और exception handling पर deterministic code का नियंत्रण रहना चाहिए। उच्च जोखिम वाले ऑर्डर भी केवल मॉडल के एक चुनाव के आधार पर अपने-आप निष्पादित नहीं होने चाहिए।

2. सूचना की परत: Jev वर्गीकरण, स्कोरिंग और सीमाएँ पहचानता है

5. ईमेल और support-ticket वर्गीकरण: केवल “कौन-सी श्रेणी?” पूछना पर्याप्त नहीं

ईमेल वर्गीकरण Jev के सबसे सहज उपयोगों में से एक है। सिस्टम ईमेल का टेक्स्ट state में रखता है, Jev से sales, billing, technical support या अन्य श्रेणी चुनवाता है और फिर प्रोग्राम संदेशों को समूहित करता, route करता या मानव समीक्षा वाली queue में रखता है।

एक प्रतिनिधि प्रोजेक्ट के लेखक ने बताया कि उसने कुछ सेकंड में 500 ईमेल लगभग $0.035 में प्रोसेस किए। मूल पोस्ट में ईमेल सेट की संरचना, श्रेणियों की परिभाषा, accuracy या confusion matrix प्रकाशित नहीं हुई, इसलिए इसे सामान्य email-classification benchmark नहीं कहा जा सकता।

व्यावहारिक डिज़ाइन में केवल एक बड़ा प्रश्न भी नहीं होना चाहिए। एक ticket में तकनीकी समस्या, refund की माँग और तीव्र नाराज़गी एक साथ हो सकती है। इसे अलग-अलग निर्णयों में बाँटा जा सकता है:

• Choice: इसे मुख्य रूप से किस टीम को भेजना चाहिए?
• Score: इसकी urgency किस स्तर की है?
• Noul: क्या इसमें refund, chargeback, कानूनी जोखिम या मानव escalation की आवश्यकता है?

आसपास का कोड इन परिणामों को जोड़कर handling path तय कर सकता है। इससे मुख्य श्रेणी सही होने पर भी सिस्टम refund या escalation signal को नज़रअंदाज़ करके ticket को अपने-आप प्रोसेस नहीं करेगा।

6. Semantic ad blocking: नियम मिलाने से आगे बढ़कर सामग्री का निर्णय

पारंपरिक ad blockers अक्सर domains, selectors और बनाए रखी गई filter lists पर निर्भर करते हैं। सामुदायिक डेमो में extension हर DOM element और उसकी class की जाँच करता है, Jev से पूछता है कि वह विज्ञापन जैसा अधिक दिखता है या सामान्य पेज सामग्री जैसा, और विज्ञापन माने गए elements को हटा देता है।

यह विचार दिखाता है कि semantic judgment नियम-आधारित सिस्टम का पूरक कैसे बन सकता है। यदि कोई element किसी ज्ञात filter से मेल न भी खाए, तब भी मॉडल उसके टेक्स्ट और पेज संरचना से विज्ञापन का इरादा पहचान सकता है।

लेकिन सार्वजनिक सामग्री में fixed-version code, गलत हटाने और छूट जाने की दर, वेबसाइट coverage या लंबे समय की testing उपलब्ध नहीं है। इसलिए इसे ऐसा production system कहने के बजाय “semantic ad-blocking prototype” कहना अधिक सही है जो कभी गलत नहीं होता या जिसे bypass नहीं किया जा सकता। Navigation, shopping recommendations या site promotions जैसी सीमांत सामग्री को गलत हटाने से पेज की functionality सीधे टूट सकती है।

7. Intent-driven spreadsheet: प्राकृतिक भाषा के column names को semantic scoring task बनाना

Predictive spreadsheet प्रोजेक्ट column name को ही प्रश्न मानता है। यदि उपयोगकर्ता Urgency नाम का column जोड़ता है, तो सिस्टम हर row का टेक्स्ट पढ़ता है, Jev से उसकी urgency तय कराता है और परिणाम sheet में वापस लिख देता है।

यहाँ Jev Excel formula नहीं बना रहा। इसके बजाय data का एक column दोहराए जाने वाले classification या scoring tasks में बदल जाता है। यही तरीका lead priority, customer sentiment, content risk या feedback themes जैसे मामलों में भी काम कर सकता है जिन्हें fixed formula से व्यक्त करना कठिन है।

लेखक के वीडियो में लगभग 100 मिलीसेकंड processing की रिपोर्ट थी, लेकिन rows की संख्या, timing boundary, cache behavior या score stability प्रकाशित नहीं की गई। इसलिए इससे यह निष्कर्ष नहीं निकाला जा सकता कि कोई भी column name अपने-आप भरोसेमंद “smart formula” बन जाएगा। Production से पहले प्रश्न का अर्थ तय करना, edge cases जाँचना और यह निर्धारित करना आवश्यक है कि किन परिणामों को मानव समीक्षा चाहिए।

8. YouTube प्रायोजित हिस्से छोड़ना: मॉडल सीमा ढूँढता है, कोड वीडियो आगे बढ़ाता है

YouTube Sponsor Detection वीडियो transcript को क्रमांकित टेक्स्ट लाइनों में बाँटता है। Jev तय करता है कि कौन-सी लाइनें प्रायोजित सामग्री का हिस्सा हैं और वह हिस्सा कहाँ शुरू व समाप्त होता है। प्रोग्राम फिर line numbers को timestamps में बदलता है और player को आगे बढ़ाता है।

यदि वीडियो में उपयोगी captions नहीं हैं, तो audio mode पहले Deepgram जैसी सेवा की मदद से transcription बनाता है। यानी Jev सीधे ऑडियो नहीं सुनता और स्वयं player को नियंत्रित भी नहीं करता। उसका काम transcript पर semantic judgment और boundary detection करना है।

लेखक ने इसे लगभग $0.005 प्रति वीडियो वाला open-source BYOK prototype बताया। यह लागत transcript की लंबाई, audio mode और transcription service के अनुसार बदलती है, और सार्वजनिक सामग्री में स्वतंत्र accuracy test भी नहीं है। Automatic skipping में दो व्यावहारिक जोखिम हैं: captions उपलब्ध न हों, या सामान्य बातचीत को गलती से प्रायोजित हिस्सा मान लिया जाए।

यह प्रोजेक्ट जिम्मेदारियों का सामान्य बँटवारा दिखाता है: मॉडल semantic boundary पहचानता है, जबकि deterministic code समय की गणना और playback control करता है।

3. Workflow की परत: Jev बीच का निर्णय घटक बनता है

9. Agent context compaction: सारांश फिर से लिखने के बजाय तय करना कि क्या बचाना है

जैसे-जैसे Agent टूल्स बुलाता है, terminal logs, search results और file contents तेजी से context window भर सकते हैं। सामान्य तरीका यह है कि generative मॉडल से पूरी history का सारांश बनवाया जाए। fast-jev-compaction अलग तरीका अपनाता है: पहले tool calls को उनके returned results के साथ जोड़ा जाता है, फिर Jev तय करता है कि कौन-सा content पूरी तरह रखना, छोटा करना या हटाना है, और अंत में कोड वास्तविक pruning करता है।

इससे स्वतंत्र rewriting कम होती है और हटाई गई जानकारी को ट्रैक करना आसान होता है। लेकिन “तेज़ी से prune करना” का अर्थ “हर बाद की टास्क बेहतर होना” नहीं है। Hermes port evaluation ने लगभग 1.4 सेकंड compaction time, करीब 115K token retention और 75.5% recall score की रिपोर्ट दी, साथ ही retrieval-recovery baseline भी रखा। परिणाम test set, Token budget, porting method और हटाई गई जानकारी को दोबारा खोज पाने की क्षमता पर निर्भर करते हैं। इससे यह सामान्य निष्कर्ष नहीं निकाला जा सकता कि हर Agent लंबे समय में लागत बचाएगा।

मूल्यांकन पूरी task chain का होना चाहिए। हटाने के बाद क्या Agent फिर से search करता है? क्या वह उपयोगकर्ता की शर्तें भूलता है? क्या पहले की गलती की जानकारी हटने से वही गलती दोहराता है? यदि बाद में recovery अधिक महँगी पड़ती है, तो तेज़ compaction कुल लागत कम नहीं भी कर सकता है।

इसलिए context compaction में recovery path और critical information की allowlist दोनों आवश्यक हैं। उपयोगकर्ता की माँगें, अधूरी टास्क, permission constraints और irreversible actions का रिकॉर्ड केवल एक low-probability result के आधार पर स्थायी रूप से नहीं हटाया जाना चाहिए।

10. json-render: पूरा इंटरफ़ेस स्वतंत्र रूप से बनाने के बजाय components और उनके संबंध चुनना

json-render के Jev implementation notes में interface generation को दो चरणों में बाँटा गया है। पहला चरण तय करता है कि कौन-से components चाहिए और हर component की कितनी संख्या होगी। दूसरा parent-child relationships और क्रम व्यवस्थित करता है। इसके बाद कोड JSON बनाता और validate करता है तथा renderer को interface assemble करने के लिए देता है।

यह सामान्य मॉडल से एक ही बार में पूरा HTML या JSON पेज लिखवाने से स्पष्ट रूप से अलग है। Components, bindings और actions सीमित sets से आते हैं। Jev मुख्यतः structure चुनता है, जबकि code सुनिश्चित करता है कि output rendering protocol के अनुरूप हो।

इससे unparsable free-form output कम हो सकता है, लेकिन “संरचना valid है” का अर्थ “interface सही है” नहीं है। Components गलत चुने जा सकते हैं, hierarchy उपयोगकर्ता के इरादे से मेल न खाए, टेक्स्ट के लिए अब भी generative मॉडल चाहिए हो और अंतिम design सुंदर या उपयोगी न हो। Implementation notes एक batch में जोड़े जाने वाले elements, evaluation count और maximum depth को भी सीमित करते हैं। इसलिए यह तरीका असीमित रूप से कोई भी product page डिज़ाइन करने के बजाय सीमित component library से interface assemble करने के लिए अधिक उपयुक्त है।

इन दस प्रोजेक्ट्स से क्या निष्कर्ष निकलता है?

ये प्रोजेक्ट्स ब्राउज़र, वीडियो, ईमेल, spreadsheet, गेम और UI जैसे अलग-अलग क्षेत्रों में हैं, फिर भी इनकी मूल संरचना बहुत समान है:

1. स्थिति को व्यवस्थित किया जा सकता है। Page DOM, transcript, email, game state या tool log को टेक्स्ट, JSON या array के रूप में दिखाया जा सकता है।
2. उत्तर को सीमित किया जा सकता है। अगली कार्रवाई, श्रेणी, जोखिम स्तर या retention decision को सीमित विकल्पों, scoring rubric या probability judgment के रूप में लिखा जा सकता है।
3. कोड जानता है कि परिणाम के साथ क्या करना है। क्लिक करना, हटाना, वीडियो आगे बढ़ाना, क्रम देना, spreadsheet में लिखना या किसी व्यक्ति को सौंपना—हर एक के लिए स्पष्ट execution logic होती है।
4. गलतियों के fallback path होते हैं। मॉडल अनिश्चित हो, API विफल हो या जोखिम बहुत अधिक हो तो सिस्टम रुक सकता है, दोबारा कोशिश कर सकता है, सामान्य मॉडल बुला सकता है या व्यक्ति को शामिल कर सकता है।

यही Jev और सामान्य-purpose LLM के बीच सबसे उपयोगी काम-विभाजन है। Jev स्पष्ट सीमाओं वाले, बार-बार आने वाले, single-step semantic decisions संभालता है। सामान्य मॉडल टेक्स्ट बनाना, नए plans सुझाना, जटिल reasoning करना और परिणाम समझाना जारी रखता है।

Typed output केवल यह सुनिश्चित करता है कि returned value interface के अनुसार है; वह business decision के सही होने की गारंटी नहीं देता। Third-party evaluations यह भी दिखाते हैं कि Jev की accuracy और probability calibration dataset के अनुसार बदलती है। जब किसी व्यवसाय के पास कुछ सौ उच्च-गुणवत्ता वाले labeled examples हों, तब छोटा classifier या encoder अधिक सटीक, तेज़ और offline operation के लिए बेहतर हो सकता है। इसलिए Jev को cold start और long-tail tasks के लिए general decision component मानना अधिक उचित है, न कि हर classification problem का स्थायी अंतिम समाधान।

Production से पहले इन पाँच बातों को न छोड़ें

पहला, प्रश्न की भाषा की समीक्षा को code review जैसा मानें। Jev का output प्रश्न और criteria से बहुत प्रभावित होता है। अस्पष्ट या विरोधाभासी प्रश्न—या एक ही prompt में छिपे कई निर्णय—सही type वाला लेकिन business के लिए गलत परिणाम दे सकते हैं।

दूसरा, thresholds को अपने data पर calibrate करें। डेमो की probabilities और thresholds सीधे production में नहीं कॉपी की जा सकतीं। अलग भाषाओं, content types और risk levels को अलग-अलग test करना चाहिए।

तीसरा, latency और failure के लिए fallback बनाएँ। Network request timeout या fail हो सकती है। Product को पहले से तय करना चाहिए कि failure का अर्थ allow, block, retry या किसी व्यक्ति को सौंपना है; API error को “नहीं” नहीं माना जाना चाहिए।

चौथा, high-risk action को एक ही model judgment पर आधारित न करें। Trading, data delete करना, account freeze करना या compliance-sensitive content publish करना जैसी irreversible operations में deterministic rules, दूसरी पुष्टि और audit records बने रहने चाहिए।

पाँचवाँ, error cases लगातार रिकॉर्ड करें। Input version, question version, options की probabilities, final action और human correction सुरक्षित रखें। तभी पता चलेगा कि समस्या state construction, question wording, threshold या मॉडल में थी।

निष्कर्ष

Jev का सबसे उपयोगी स्थान चैट मॉडल की जगह लेना नहीं, बल्कि software के उन decision points में बैठना है जिन्हें पहले if/else logic में लिखना कठिन था और हर बार बड़े generative मॉडल को भेजना महँगा पड़ता था।

Browser Use में वह अगली web action चुनता है। Email system उसे routing और escalation signals के लिए उपयोग कर सकता है। YouTube prototype उससे sponsored segment की सीमा पहचानने को कहता है। json-render उसे component relationships चुनने देता है, जबकि context compaction उससे पूछता है कि कौन-सी पुरानी जानकारी context window में बनी रहनी चाहिए। इनमें से कोई application इसलिए सफल नहीं होती कि Jev अकेले पूरी टास्क करता है। वे इसलिए काम करती हैं क्योंकि डेवलपर state, candidate options, execution logic, thresholds और fallback paths को साथ में डिज़ाइन करते हैं।

Jev तब सबसे अधिक मूल्य देता है जब निर्णय की सीमा स्पष्ट हो, output को सीमित किया जा सके और code परिणाम को भरोसेमंद ढंग से इस्तेमाल कर सके। जहाँ लंबा टेक्स्ट बनाना, multi-step reasoning, open-ended planning या explainable conclusion आवश्यक हो, वहाँ general-purpose LLM अब भी अनिवार्य है।