खाजगी आणि किफायतशीर ज्ञान-कार्यासाठी (knowledge work) एक लोकल-फर्स्ट एजंट

Perplexity Portable Computer हा एक लोकल-फर्स्ट एजंट आहे.

डीफॉल्टनुसार संपूर्ण स्टॅक स्थानिक पातळीवर चालतो. मॉडेल, हार्नेस, संभाषण आणि ट्रॅजेक्ट्री सर्व काही वापरकर्त्याच्या मशिनवर राहतात. बाहेरील जगाची आवश्यकता असलेले काम, जसे की वेब शोध, कनेक्टर, किंवा क्लाउडवरील मजबूत सल्लागार मॉडेलकडे उच्चाधिकार देणे, हे केवळ आवश्यक असतानाच आणि नेहमी वापरकर्त्याच्या मंजुरीनेच केले जाते. त्यामुळे संवेदनशील डेटा परवानगीशिवाय कधीही डिव्हाइस सोडत नाही आणि स्थानिक मॉडेल्सवर कोणतेही इन्फरन्स शुल्क लागत नाही: रचनानुसारच ही प्रणाली खाजगी आणि किफायतशीर आहे.

प्रभावी लोकल-फर्स्ट एजंटसाठी मॉडेल आणि हार्नेस एकत्र डिझाइन करणे आवश्यक असते. जनरल-पर्पज हार्नेस हे अशा फ्रंटीयर मॉडेल गृहीत धरतात जे लांब संदर्भ स्वीकारू शकतात, विस्तृत टूल पृष्ठभाग नेव्हिगेट करू शकतात आणि लांब क्षितिजांवर योजना आखू शकतात. स्थानिक मॉडेल्स अशा मागण्यांनुसार कमी विश्वासू असतात. मोठ्या मॉडेलसाठी तयार केलेले हार्नेस व्यवस्थापित करण्यास लहान मॉडेलला सांगण्याऐवजी, आम्ही दोन्ही एकमेकांच्या अनुषंगाने आकारले: मॉडेलच्या क्षमता प्रोफाइलनुसार तयार केलेले हार्नेस आणि ते हार्नेस प्रभावीपणे वापरण्यासाठी पोस्ट-ट्रेन केलेले मॉडेल.

परिचय

अनेक ज्ञान-कार्य (knowledge-work) कार्यांमध्ये अलीकडील महिन्यांत एजंटच्या क्षमता वेगाने प्रगत झाल्या आहेत. या प्रगतीमुळे उत्पादकता आणि कार्यक्षमतेत मोठा फायदा होत असला, तरी त्यासोबतच दोन आव्हानेही निर्माण होतात.

टोकनचा वापर झपाट्याने वाढत आहे आणि त्यासोबतच एकूण खर्चही वाढत आहे. रिमोट क्लस्टरवर चालणाऱ्या क्लोज्ड-सोर्स मॉडेलच्या API द्वारे जेव्हा बुद्धिमत्ता ऍक्सेस केली जाते, तेव्हा प्रत्येक विनंतीसोबत खाजगी माहिती आणि बौद्धिक संपदा वापरकर्त्याच्या डिव्हाइसमधून बाहेर पडते. जसे जसे एजंट वैयक्तिक वर्कफ्लो आणि संपूर्ण संस्थांमध्ये स्केल होतात, तसे तसे टोकन खर्च आणि डेटा हलवणे नियंत्रित करणे अधिकाधिक कठीण होत जाते.

याच वेळी, ओपन-सोर्स मॉडेल्स आणखी जलद दराने सुधारली आहेत. NVIDIA Nemotron 3.5 Lightning (एकूण ३० अब्ज पॅरामीटर्स), Qwen 3.6 (३५ अब्ज) आणि Qwen 3.8 (२७ अब्ज) यांसारख्या अत्यंत लहान आणि कार्यक्षम मॉडेल्समध्ये ही प्रगती सर्वाधिक दृश्यमान आहे. ही लहान मॉडेल्स त्यांच्या क्षमतेपेक्षा कैक पटीने चांगली कामगिरी करतात आणि आता जटिल एजंट वर्कफ्लो करण्यास सक्षम आहेत. लोकल-इन्फरन्स हार्डवेअर समांतरपणे प्रगत होत आहे: NVIDIA DGX Spark सारख्या प्रणाली आता ही मॉडेल्स स्थानिक पातळीवर चालवू शकतात. या सर्व गोष्टी एकत्र आल्यामुळे, जेव्हा गरज असेल तेव्हा वेब शोध, कनेक्टर किंवा क्लाउड-मॉडेल एस्केलेशन यांसारख्या बाह्य क्षमता निवडण्याची मुभा वापरकर्त्याला देऊन, पूर्णपणे ऑन-डिव्हाइस ऑपरेशन व्यावहारिक बनते.

हा लोकल-फर्स्ट दृष्टिकोन महत्त्वपूर्ण खर्च बचत सक्षम करतो, कारण स्थानिक इन्फरन्समुळे प्रति-टोकन API शुल्क टाळले जाते. यामुळे गोपनीयतेच्या आणि बौद्धिक संपदेच्या समस्या देखील नैसर्गिकरीत्या सुटतात: खाजगी टोकन्स रिमोट क्लस्टरवर कधीही प्रसारित करण्याची गरज भासत नाही आणि ते सुरक्षितपणे स्थानिक डिव्हाइसच्या मर्यादेत राहतात.

जूनमध्ये, आम्ही पहिले हायब्रिड लोकल-सर्व्हर इन्फरन्स ऑर्केस्ट्रेटर सादर केले जे कोणते कार्य डिव्हाइसवर चालवावे आणि कोणते कार्य क्लाउडमधील एजंट्सकडे पाठवावे हे ठरवते. येथे आम्ही असे स्पष्ट करतो की आम्ही असा लोकल-फर्स्ट एजंट कसा तयार केला, ज्यामध्ये हार्नेस आणि एकमेकांसाठी ऑप्टिमाइझ केलेले मॉडेल्स समाविष्ट आहेत.

आम्ही मुख्य डिझाइन निवडींचा आढावा घेतो, तीन सार्वजनिक बेंचमार्क आणि आमच्या अंतर्गत लोकल नॉलेज वर्क बेंचवर लोकप्रिय ओपन-सोर्स जनरल-पर्पज हार्नेस (Hermes आणि Pi) विरुद्ध Computer चे मूल्यांकन करतो. आमच्या बेंचमार्कवर, NVIDIA DGX Spark वर चालणाऱ्या Qwen 3.8 27B मॉडेलसह, Computer ने सर्व Uच उच्च गुण मिळवले आहेत - Pi साठी ७७.६% आणि Hermes साठी ७४.0% च्या तुलनेत ८२.६%. Qwen 3.8 27B च्या वर पोस्ट-ट्रेन केलेले आमचे मॉडेल PPLX 27B, हा स्कोअर आणखी वाढवून ८५.४% करते.

स्थानिक मॉडेलभोवती हार्नेस डिझाइन करा

कॉम्पॅक्ट ऑन-डिव्हाइस मॉडेल्स आधीच बऱ्यापैकी सक्षम असली, तरी परफॉर्मन्सच्या बाबतीत ती अजूनही मोठ्या फ्रंटीयर मॉडेल्सच्या मागे आहेत. या मॉडेल्सना प्रभावीपणे मार्गदर्शन करण्यासाठी आणि त्यांच्या मर्यादा दूर करण्यासाठी काळजीपूर्वक डिझाइन केलेले हार्नेस आवश्यक आहे.

Pi आणि Hermes सारखे लोकप्रिय ओपन-सोर्स हार्नेस हे जनरल असल्याचे सिद्ध झाले आहेत: ते वेगवेगळ्या आकारांच्या आणि वर्गांच्या विस्तृत मॉडेल्ससह उत्तम प्रकारे कार्य करतात. परंतु ते ऑन-डिव्हाइस मॉडेल्सच्या क्षमतेसाठी ऑप्टिमाइझ केलेले नाहीत. आम्ही या सेटिंगसाठी विशेषतः स्थानिक हार्नेस डिझाइन केला आहे, जो काही मुख्य तत्त्वांवर आधारित आहे.

संदर्भ कार्यक्षमता (Context efficiency)

आमचे हार्नेस डिझाइन करताना मुख्य लक्ष मॉडेलच्या संदर्भाचा सर्वोत्तम वापर करण्यावर होते.

जरी Qwen 3.8 27B सारखी ऑन-डिव्हाइस मॉडेल्स २६०k टोकन्सच्या संदर्भ विंडो प्रदान करत असली, तरी आम्हाला असे अनुभवास आले की १००k टोकन्सच्या पुढे जाताना त्यांना संघर्ष करावा लागतो. म्हणूनच आम्ही मुख्य हार्नेस संक्षिप्त ठेवतो: एक किमान प्रणाली प्रॉम्प्ट आणि कोअर टूल्सचा एक छोटा संच.

इतर सर्व क्षमता ऑन-डिमांड कौशल्यांमध्ये (skills) मॉड्यूलर केल्या जातात ज्या संपूर्ण ट्रॅजेक्ट्री दरम्‍यान लोड आणि अनलोड होतात. आम्ही ही कौशल्ये सामान्य ज्ञान-कार्य (knowledge-work) कार्यांसाठी डिझाइन केली आहेत: संशोधन, डेटा विज्ञान, डेटा व्हिज्युअलायझेशन, दस्तऐवज निर्मिती, सॉफ्टवेअर अभियांत्रिकी आणि बरेच काही.

हार्नेस संदर्भ कॉम्पॅक्शनला देखील समर्थन देते, जेव्हा ट्रॅजेक्ट्री मोठी होते तेव्हा जुनाट संदर्भ सारांशित करते जेणेकरून मॉडेल त्याच्या प्रभावी विंडोमध्ये राहू शकेल.

कमांड-लाइन टूल्स म्हणून कनेक्टर

दिवसेंद्राच्या ज्ञान-कार्यासाठी (knowledge work) अनेकदा Gmail, GitHub, Outlook आणि Google Calendar सारख्या कनेक्टरची आवश्यकता असते. हे सहसा हार्नेससमोर MCP सर्व्हर म्हणून उघड केले जातात, ज्यांच्या मोठ्या टूल परिभाषा संदर्भाचा मोठा हिस्सा वापरतात. त्याऐवजी, आम्ही सर्वाधिक वापरल्या जाणाऱ्या MCPs ला कॉम्पॅक्ट, वापरण्यास सोप्या कमांड-लाइन टूल्समध्ये रूपांतरित केले, ज्यांना सानुकूल कौशल्यांसह (skills) पूरक केले गेले जे मर्यादित प्रभावी संदर्भाचा चांगला वापर करतात.

स्वयं-नोंदणी (Self-verification)

एजंट जेव्हा स्वतःचे कार्य सत्यापित करतो तेव्हा कार्यक्षमता देखील सुधारते. पडताळणीमुळे अतिरिक्त पायऱ्या जोडल्या जातात, परंतु यामुळे अंतिम निकाल खूप सुधारतो आणि फ्रंटीयर मॉडेल्समधील अंतर लक्षणीयरीत्या कमी होते. हे मॉडेल स्वतः द्वारे किंवा ट्रॅजेक्ट्रीच्या आरोग्याचे निरीक्षण करणाऱ्या आणि काही चूक झाल्यावर स्वयं-पडताळणीची विनंती करणाऱ्या हुक्सच्या संचाद्वारे ट्रिगर केले जाऊ शकते.

सँडबॉक्स केलेले अंमलबजावणी (Sandboxed execution)

हार्नेस वापरकर्त्याच्या डिव्हाइसवरील OS-स्तरीय सँडबॉक्समध्ये टूल्स कार्यान्वित करते. ही मर्यादा धोरणानुसार प्रक्रिया, फाइलसिस्टम मार्ग आणि नेटवर्क प्रवेश प्रतिबंधित करते. यामुळे चुकीच्या कमांडचा प्रभाव क्षेत्र (blast radius) मर्यादित होतो. सँडबॉक्स अनुपलब्ध असल्यास, हार्नेस अनसँडबॉक्स केलेल्या अंमलबजावणीमध्ये जाण्याऐवजी कोणत्याही टूल कॉलपूर्वी स्वतःला अक्षम करतो.

हे Pi आणि Hermes सारख्या ओपन-सोर्स हार्नेसपेक्षा वेगळे आहे, जे डीफॉल्टनुसार वापरकर्त्याच्या परवानग्यांसह थेट कमांड चालवतात. Computer मध्ये, आयसोलेशन नेहमी चालू असते, त्यासाठी कोणत्याही कॉन्फिगरेशनची आवश्यकता नसते आणि त्याशिवाय टूल्स चालत नाहीत.

खालील आकृती दर्शवते की ही तत्त्वे अंमलबजावणी लूपमध्ये कशी एकत्र येतात. ऑर्केस्ट्रेटर हा डिटरमिनिस्टिक हार्नेस कोड आहे, LLM नाही: तो लूप कायम ठेवतो, संदर्भ एकत्र करतो आणि धोरण लागू करतो. स्थानिक मॉडेलपुढील कृती प्रस्तावित करते; ऑर्केस्ट्रेटर सँडबॉक्समध्ये मंजूर केलेल्या टूल कॉल कार्यान्वित करतो आणि त्यांचे निकाल मॉडेलला परत करतो. वेब शोध, कनेक्टर आणि सल्लागार कॉल केवळ सक्षम आणि मंजूर केल्यावरच डिव्हाइसची मर्यादा ओलांडतात.

स्थानिक हार्नेस त्याच मॉडेलचा अधिक फायदा मिळवून देतो

समान ऑन-डिव्हाइस बेस मॉडेल वापरून, आम्ही वेब संशोधन आणि मल्टीमोडल दस्तऐवज समजून घेण्याबाबत आमच्या स्थानिक हार्नेसची जनरल-पर्पज पर्यायांसोबत तुलना करतो. सर्व हार्नेस NVIDIA DGX Spark वर चालणारे, मध्यम रीझनिंग असलेले Qwen 3.8 27B मॉडेल वापरतात. ही तुलना कोणत्याही मॉडेल पोस्ट-ट्रेनिंगपूर्वी, थेट हार्नेसद्वारे योगदान दिलेल्या क्षमता वेगळ्या करून दाखवते.

आम्ही या दोन क्षमतांवर लक्ष केंद्रित करतो कारण ज्ञान-कार्य (knowledge work) अनेकदा वापरकर्त्याच्या डिव्हाइसवरील खाजगी दस्तऐवजांना वेबवरील सार्वजनिक माहितीशी जोडून एक ग्राउंडेड आर्टिफॅक्ट तयार करते. वेब शोध, परंतु मॉडेल इन्फरन्स आणि खाजगी-दस्तऐवज प्रक्रिया स्थानिक राहतात. स्थानिक फाइल्स अधिकृत स्त्रोत म्हणून काम करतात, सार्वजनिक स्त्रोत संदर्भ जोडतात, आणि वापरकर्ते पूर्णपणे ऑफलाइन कामासाठी वेब शोध पूर्णपणे अक्षम करू शकतात.

वेब संशोधन

स्वतंत्र मूल्यांकनांमध्ये सर्वोच्च रँकिंग मिळवलेल्या Perplexity च्या शोध इंजिनसह आम्ही आमचा स्थानिक हार्नेस तयार करतो. हार्नेस Search as Code इंटरफेसद्वारे त्यात प्रवेश करतो.

आम्ही १,२६६ BrowseComp कार्यांवर संशोधन गुणवत्तेचे मूल्यांकन करतो. Computer Perplexity च्या शोध पायाभूत सुविधांचा आणि आमच्या स्थानिक हार्नेसचा वापर करतो, तर Pi आणि Hermes त्यांच्या शिफारस केलेले शोध प्रदाता असलेल्या Brave वर अवलंबून असतात. Pi साठी ५०.२% आणि Hermes साठी ४३.९% च्या तुलनेत Computer ६६.७% अचूकतेपर्यंत पोहोचतो.

Computer कडे सर्वात कमी सरासरी रेकॉर्ड केलेली वॉल वेळ आणि टोकन वापर देखील आहे: प्रति कार्य ४०२.१ सेकंद आणि ८५२k टोकन्स, Hermes साठी १,०२०.९ सेकंद आणि १.०१ दशलक्ष टोकन्स, आणि Pi साठी ८२६.० सेकंद आणि २.८२ दशलक्ष टोकन्सच्या तुलनेत. त्यामुळे Computer Hermes पेक्षा ६१% कमी वॉल वेळ आणि १६% कमी टोकन्स वापरते, आणि Pi पेक्षा ५१% कमी वॉल वेळ आणि ७०% कमी टोकन्स वापरते.

ऑन-डिव्हाइस मल्टीमोडल दस्तऐवज समजून घेणे

अनेक दस्तऐवज दृष्यस्वरूपात माहिती वाहून नेतात आणि साधे मजकूर म्हणून पार्स करणे कठीण असते: PDF, स्कॅन केलेली पृष्ठे, स्क्रीनशॉट, चार्ट आणि प्रेझेंटेशन. हे वर्कफ्लो OCR आणि प्रतिमा समजून घेण्यावर अवलंबून असतात आणि मूळतः मल्टीमोडल असलेल्या मॉडेलचा सर्वाधिक फायदा घेतात.

हार्नेस दस्तऐवज पृष्ठे आणि प्रतिमा थेट मॉडेलकडे पास करतो, जे त्यांना समजून घेते आणि काढलेल्या मजकुराशी व्हिज्युअल पुराव्याची जोड देते. डिव्हाइसवर या फाइल्स प्रोसेस केल्याने संवेदनशील दस्तऐवज आणि त्यांची काढलेली सामग्री खाजगी राहते.

आम्ही ParseBench-100 वर मल्टीमोडल दस्तऐवज समजून घेण्याचे मूल्यांकन करतो, जे ParseBench बेंचमार्कचा १००-कार्यांचा सबसेट आहे, ज्यामध्ये चार्ट, लेआउट, सारण्या, मजकूर सामग्री आणि फॉरमॅटिंगसाठी प्रत्येकी २० कार्ये आहेत.

Hermes साठी ३४.६% आणि Pi साठी १३.9% च्या तुलनेत Computer ६५.१% च्या सरासरी स्कोअरपर्यंत पोहोचतो. हे सर्वात कमी वेळेत आणि सर्वात कमी टोकन्ससह कार्ये पूर्ण करते: प्रति कार्य सरासरी ६०.६ सेकंद आणि २०.१k टोकन्स, Hermes साठी १०८.3 सेकंद आणि ३२.1k टोकन्सच्या तुलनेत, आणि Pi साठी ४१०.५ सेकंद आणि ८२९.1k टोकन्स. Computer सर्व पाच दस्तऐवज श्रेणींमध्ये आघाडीवर आहे, चार्ट्सवर त्याचा सर्वात मोठा फायदा आहे. लेआउट तिन्ही हार्नेससाठी कठीण राहतो.

तक्ता १. ऑन-डिव्हाइस Qwen 3.8 27B मॉडेलसह Computer, Hermes आणि Pi हार्नेससाठी दस्तऐवज श्रेणीनुसार ParseBench-100 सरासरी स्कोअर. Computer सर्व पाच श्रेणींमध्ये आघाडीवर आहे.

सल्लागार एस्केलेशनसह फ्रंटीयर अंतर कमी करणे

काळजीपूर्वक डिझाइन केलेल्या हार्नेससह देखील, सर्वात कठीण कार्ये अजूनही कॉम्पॅक्ट ऑन-डिव्हाइस मॉडेलच्या क्षमतेपेक्षा जास्त आहेत. अशा कार्यांसाठी, हार्नेस एक सल्लागार टूल उघड करते: जेव्हा स्थानिक मॉडेलला नियोजन, अस्पष्टता दूर करणे, वारंवार होणाऱ्या अपयशांमधून सावरणे किंवा अंतिम निकालाची पडताळणी करणे यात मदतीची आवश्यकता असते तेव्हा ते एका मजबूत फ्रंटीयर मॉडेलचा सल्ला घेऊ शकते.

स्थानिक मॉडेल कधी सल्ला मागवायचा हे ठरवते, तर हार्नेस ऑर्केस्ट्रेटर टूल अधिकार राखून ठेवतो आणि कोणता संदर्भ पाठवला जातो हे नियंत्रित करतो. एस्केलेशन पर्यायी आहे. ते सक्षम करायचे की नाही आणि प्रत्येक सल्लागार कॉल व्यक्तिचलितपणे किंवा आपोआप मंजूर करायचा की नाही हे वापरकर्ता ठरवतो.

सल्लागार कॉल करण्यापूर्वी, हार्नेस संबंधित संदर्भ निवडतो, संवेदनशील माहिती चिन्हांकित करण्यासाठी PII वर्गीकरणकर्ता लागू करतो आणि वापरकर्त्याला दर्शवतो की डिव्हाइसमधून काय बाहेर जाईल. सल्लागार फक्त मंजूर संदर्भ प्राप्त करतो आणि मजकूर मार्गदर्शन परत करतो; त्याला डिव्हाइसच्या फाइल्स, टूल्स किंवा संभाषणांमध्ये थेट प्रवेश नसतो. यामुळे खर्च आणि गोपनीयता दोन्ही सुधारतात, आणि भविष्यातील कामात या दिशेचा आणखी शोध घेण्याची आमची योजना आहे.

आम्ही आव्हानात्मक सॉफ्टवेअर अभियांत्रिकी कार्यांवर या दृष्टिकोनाची चाचणी करतो, ज्यासाठी मजबूत तर्काची आवश्यकता असते आणि जिथे स्थानिक मॉडेल बहुतेक वेळा कमी पडते. यासाठी आम्ही कोडिंग एजंट्ससाठी ८९-कार्यांचा लोकप्रिय बेंचमार्क Terminal Bench 2.1 वापरतो.

आम्हाला दोन प्रश्नांची उत्तरे द्यायची आहेत: सल्लागार एस्केलेशन फ्रंटीयर मॉडेलमधील किती अंतर भरून काढू शकते आणि किती किंमतीत. स्थानिक पातळीवर इन्फरन्स होत असल्यामुळे पूर्णपणे स्थानिक मॉडेल्स चालवण्यासाठी जवळपास काहीही खर्च येत नाही. तथापि, एकदा मॉडेलने सल्लागाराला कॉल करण्यास सुरुवात केली की, त्याला API खर्च येऊ लागतो.

फ्रंटीयर परफॉर्मन्सचा आधार म्हणून, आम्ही स्थानिक हार्नेसमध्ये कार्यरत Claude Opus 5 वापरतो; स्थानिक मॉडेल Qwen 3.8 27B आहे. शेवटी, आम्ही दोन्ही एकत्र जोडतो: Qwen 3.8 27B कार्य कार्यान्वित करते आणि मदतीची आवश्यकता असताना Claude Opus 5 सल्लागाराकडे एस्केलेट करते. आम्ही Pi किंवा Hermes सह सल्लागार एस्केलेशनचे मूल्यांकन करत नाही कारण दोघांपैकी कोणीही समतुल्य सल्लागार टूल प्रदान करत नाही; एक जोडल्यास त्याच्या टूल पृष्ठभागात आणि ऑर्केस्ट्रेशन्स लॉजिकमध्ये बदल करावा लागेल, त्यामुळे परिणाम आता रेडीमेड (off-the-shelf) हार्नेसचे प्रतिनिधित्व करणार नाही.

सल्लागार एस्केलेशनमुळे Computer चा स्कोअर ५९.६% वरून ७३.0% पर्यंत वाढतो, जो प्रति रोलआउट अंदाजे $०.४१५ च्या API खर्चावर १३.5 टक्के गुणांची वाढ आहे. एकटे Claude Opus 5 चालवल्यास प्रति रोलआउट $०.६५ वर ८२.४% पर्यंत पोहोचतो. अशा प्रकारे एस्केलेशन फ्रंटीयरच्या खर्चाच्या अंदाजे दोन-तृतीयांश खर्चात फ्रंटीयरचे सुमारे तीन-पंचमांश अंतर भरून काढते आणि तो व्यवहार करणे योग्य कधी आहे हे वापरकर्ता ठरवतो.

हार्नेस आणि ज्ञान-कार्यासाठी (knowledge work) पोस्ट-ट्रेनिंग

आतापर्यंत, हार्नेस काय योगदान देते हे वेगळे करण्यासाठी आम्ही स्थानिक मॉडेल अपरिचित ठेवले आहे. हार्नेस डिझाइन जागेवर आल्यावर, उर्वरित सर्वात मोठा फायदा मॉडेल स्वतःमध्ये अनुकूलन केल्यामुळे मिळतो. Perplexity Computer वापर डेटा आम्हाला दाखवतो की लोक ज्ञान-कार्यासाठी प्रत्यक्ष काय करतात, जे आम्ही प्रशिक्षण डेटा सिंथेसाइज करण्यासाठी वापरतो. वापरकर्ते पार पाडत असलेल्या कार्यांच्या वास्तविक वितरणाद्वारे मार्गदर्शित होऊन, आम्ही Computer हार्नेसच्या आत स्थानिक मॉडेलचे पोस्ट-ट्रेनिंग करतो.

विशेषतः, आम्ही विविध मॉडेल क्षमता, टूल्स आणि कनेक्टर वापरणारे विविध युज केसेस ओळखतो. या युज केसेसवरून आम्ही वास्तववादी रिइंफोर्समेंट लर्निंग वातावरण तयार करतो आणि आव्हानात्मक परंतु पडताळणी करण्यायोग्य कार्ये परिभाषित करतो: प्रत्येक कार्यामध्ये एक सूचना, एक वातावरण आणि अंतिम निकालाचे गुणांकन करणारा एक पडताळणीकर्ता (verifier) असतो, जिथे वातावरण एक Docker कंटेनर आहे ज्यामध्ये हार्नेस चालते. महत्त्वाचे म्हणजे, कार्ये कृत्रिम असल्याने, त्यात कोणतेही वास्तविक दस्तऐवज किंवा वापरकर्ता माहिती समाविष्ट नाही.

आम्ही दोन-टप्प्यांच्या प्रशिक्षणासाठी ही वातावरणे वापरतो: रिजेक्शन फाईन-ट्यूनिंग आणि त्यानंतर रिइंफोर्समेंट लर्निंग. पहिल्या टप्प्यात, आम्ही प्रत्येक कार्याविरुद्ध मॉडेल अनेक वेळा रोल आउट करतो, पडताळणीकर्ता स्कोअरनुसार सर्वोत्तम ट्रॅजेक्ट्री निवडतो आणि सुपरवाइज्ड लर्निंगसह त्यावर प्रशिक्षण देतो. हा टप्पा विशिष्ट हार्नेस आणि कार्य वितरणासाठी मॉडेल इनिशिएलाइज करतो. दुसऱ्या टप्प्यात, रिइंफोर्समेंट लर्निंग मॉडेलला आणखी फाईन-ट्यून करते, ज्यामुळे ते अधिक मजबूत बनते.

कार्यांचा एक सबसेट प्रशिक्षणातून बाजूला ठेवला जातो आणि अंतिम मूल्यांकनासाठी वापरला जातो; आम्ही या बाजूला ठेवलेल्या संचाला लोकल नॉलेज वर्क बेंच म्हणतो: सखोल संशोधनापासून ते दस्तऐवज निर्मितीपर्यंत, दररोजच्या ज्ञान-कार्याच्या (knowledge work) सात श्रेणींमध्ये पसरलेली ५३ कार्ये. आम्ही लवकरच मॉडेल प्रशिक्षणाचे तपशीलवार वर्णन करणारा तांत्रिक अहवाल प्रकाशित करू, आणि आमची ही मूल्यांकन बेंचमार्क ओपन-सोर्स करण्याची योजना आहे.

आम्ही या दृष्टिकोनासह Qwen 3.8 27B चे पोस्ट-ट्रेनिंग केले, ज्यामुळे PPLX 27B नावाचे मॉडेल तयार झाले आणि लोकल नॉलेज वर्क बेंचवर त्याचे मूल्यांकन केले. बेस Qwen 3.8 27B मॉडेलसह, Computer ने सर्वोच्च स्कोअर प्राप्त केला (८२.६%, Pi साठी ७७.६% आणि Hermes साठी ७४.0% च्या तुलनेत) आणि सर्वात कमी टोकन्स वापरले (५२०k, Pi साठी ६८१k आणि Hermes साठी ६३४k च्या तुलनेत). Pi ने प्रति कार्य १७६ सेकंदांच्या वेगाने सर्वात जलद कार्ये पूर्ण केली, Computer साठी २१८ सेकंद आणि Hermes साठी २९२ सेकंदांच्या तुलनेत. PPLX 27B ने अधिक टोकन्सच्या खर्चावर (५२०k ऐवजी ६७८k) Computer चा स्कोअर ८५.४% पर्यंत वाढवला. याची अंदाजे वॉल वेळ २५० सेकंद आहे.

तक्ता २. लोकल नॉलेज वर्क बेंच कार्य श्रेणी.

निष्कर्ष

आमचे संशोधन दर्शवते की, सक्षम स्थानिक हार्डवेअर आणि त्यांच्यासाठी तयार केलेले हार्नेस असलेले मजबूत ओपन-सोर्स मॉडेल, संवेदनशील डेटा डिव्हाइस सोडल्याशिवाय जवळजवळ-शून्य इन्फरन्स खर्चावर वास्तविक ज्ञान-कार्य (knowledge work) हाताळू शकते.

विविध बेंचमार्कवर, NVIDIA DGX Spark वर Qwen 3.8 27B चालवताना Computer ने अचूकतेमध्ये Hermes आणि Pi शी बरोबरी केली किंवा त्यांना मागे टाकले. लॅटेंसी आणि टोकन वापराची माहिती देणाऱ्या तीन बेंचमार्कपैकी, Computer BrowseComp आणि ParseBench-100 वर सर्वात वेगवान होता आणि तिन्हीवर सर्वात कमी टोकन्स वापरले; Pi लोकल नॉलेज वर्क बेंचवर सर्वात वेगवान होता.

आम्ही घेतलेल्या निवडींमुळे हे फायदे मिळाले. आम्ही मागणीनुसार लोड होणाऱ्या कौशल्यांसह (skills) एक संक्षिप्त स्थानिक हार्नेस तयार केला. आम्ही MCP सर्व्हरऐवजी कनेक्टरना कॉम्पॅक्ट CLI टूल्समध्ये रूपांतरित केले. सुरक्षेसाठी अंमलबजावणी सँडबॉक्स केली गेली.

परिणाम हे देखील दर्शवतात की कॉम्पॅक्ट मॉडेल्समध्ये सुधारणा करण्यासाठी कुठे वाव आहे. उदाहरणार्थ, Terminal Bench 2.1 च्या आव्हानात्मक कोडिंग कार्यांवर, स्थानिक मॉडेल तिन्ही हार्नेसमध्ये फ्रंटीयर मॉडेलच्या मागे पडते. सल्लागार एस्केलेशन अंतर कमी करते पण पूर्णपणे बंद करत नाही; कार्यक्षमता आणखी पुढे नेण्यासाठी मॉडेल क्षमता आणि स्थानिक हार्डवेअरमधील सतत सुधारणा अद्याप आवश्यक आहेत.

स्थानिक मर्यादांसाठी हार्नेस आणि मॉडेल तयार करण्यामागचा उद्देश वापरकर्त्यांना कोणती माहिती त्यांची मशिन सोडते यावर स्पष्ट नियंत्रण देणे हा आहे. वापरकर्त्यासाठी खर्चाचे फायदे देखील आहेत. आम्ही याला एका व्यापक बदलाचा भाग म्हणून पाहतो ज्यामध्ये वाढत्या सक्षम एजंट्स रिमोट इन्फ्रास्ट्रक्चरवरून वैयक्तिक आणि स्थानिक डिव्हाइसवर जात आहेत. आम्हाला अपेक्षा आहे कि चिप्स, मॉडेल्स आणि डिव्हाइसेसमधील प्रगती Portable Computer स्थानिक पातळीवर हाताळत असलेल्या ज्ञान-कार्याची (knowledge work) श्रेणी आणि गुणवत्ता सतत वाढवत राहील.