Perplexity वर एजंट स्किल्स डिझाइन करणे, रिफायन करणे आणि मेंटेन करणे

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

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

उदाहरणार्थ, जर तुम्ही PEP20 – द झेन ऑफ पायथन मधील काही सूक्ती घेतल्या, तर चांगला Python कोड लिहिणे आणि चांगली कौशल्ये लिहिणे यात किती फरक आहे हे लवकरच स्पष्ट होते. ज्ञानाच्या २० ओळींपैकी, कौशल्ये लिहिताना किमान अर्ध्या ओळी पूर्णपणे चुकीच्या किंवा सक्रियपणे दिशाभूल करणाऱ्या असतात. त्यापैकी पाच येथे दिल्या आहेत:

Python च्या झेन आणि Skills लिहिण्यासाठीच्या लेखाच्या मार्गदर्शनातील पाच भेद.

हे मार्गदर्शक तो दस्तऐवज आहे जो Perplexity मधील इंजिनिअर्स कौशल्ये विकसित आणि पुनरावलोकन करताना वापरतात. आमचे शोध आणि शिकणे व्यापक समुदायाला फायदेशीर ठरावे म्हणून आम्ही हे मार्गदर्शक लोकांसाठी देखील खुले करत आहोत. तुम्ही तुमच्या दैनंदिन कामात प्रोडक्शन कौशल्ये डिझाइन करणारे इंजिनिअर असाल, तुम्हाला सर्वात जास्त माहीत असलेल्या क्षेत्रात स्वतःचे कौशल्य विकसित पाहणारे Computer वापरकर्ते असाल, किंवा दोन्ही असाल, हे मार्गदर्शक तुमच्यासाठी आहे.

कौशल्य म्हणजे काय?

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

कौशल्य हे किमान चार गोष्टींचे बनलेले असते, विशेषतः आपण Perplexity मध्ये ते कसे तयार करतो या संदर्भात.

कौशल्य ही एक डिरेक्ट्री आहे

कौशल्य म्हणजे केवळ एक SKILL.md फाईल नाही. बऱ्याच प्रकरणांमध्ये, कौशल्यामध्ये अनेक फाईल्स समाविष्ट असतात. तुमच्या कौशल्याच्या नावावरून तयार केलेल्या डिरेक्ट्री अंतर्गत, तुमच्याकडे हे असू शकते:

SKILL.md: फ्रंटमॅटर आणि सूचना

scripts/: एजंट चालवणारा कोड, पुन्हा शोधलेला नाही

references/: जड दस्तऐवज, अटीनुसार लोड केले जातात

assets/: टेम्पलेट्स, स्कीमा आणि डेटा

config.json: प्रथम-वापरकर्ता सेटअप

हे हब-अँड-स्पोक पॅटर्न तुम्हाला कौशल्ये अतिशय केंद्रित आणि घट्ट ठेवण्याची परवानगी देतो आणि फोल्डर स्ट्रक्चरचा अतिशय सर्जनशील मार्गाने वापर केला जाऊ शकतो. काहीवेळा, विशेषतः गुंतागुंतीच्या कौशल्यांना मॉडेलला अधिक चांगल्या प्रकारे नेव्हिगेट करण्यात मदत करण्यासाठी श्रेणीबद्धतेच्या अनेक स्तरांचा फायदा होतो. समजा एखाद्या कौशल्यासाठी ३०० विषयांमधील ज्ञानाची आवश्यकता आहे, ज्यांचे २० विषय क्षेत्रामध्ये वर्गीकरण केले जाऊ शकते. आजच्या सर्वोत्तम फ्रंटियर मॉडेल्ससाठी देखील ३०० पैकी योग्य विषय विश्वसनीयपणे निवडणे हे एक न सुटलेले आव्हान आहे. मॉडेलसाठी त्या क्षेत्रातील १५ विषयांपेक्षा २० क्षेत्रांपैकी एकावर लक्ष केंद्रित करणे ही एक खूप सोपी निवड समस्या आहे.

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

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

विस्तृत करा

कौशल्य हा एक फॉरमॅट आहे

कौशल्य हा एक फॉरमॅट आहे. मूळ मूळ SKILL.md फाईलमध्ये नाव आणि वर्णन दोन्ही असणे आवश्यक आहे. शिवाय, कौशल्याची डिरेक्ट्री नावाशी अचूक जुळली पाहिजे ज्यामध्ये कौशल्य स्थित आहे. नाव सर्व लोअर-केस वर्णांचे असणे आवश्यक आहे, त्यात स्पेस नसले पाहिजेत आणि हायफन वापरले जाऊ शकतात. वर्णन हे रुटिंग ट्रिगर आहे. हा एक सामान्य अपयशाचा बिंदू आहे: कौशल्य काय करते यासाठी वर्णन अंतर्गत कागदपत्रे नाही. हे मॉडेलसाठी कौशल्य कधी लोड करायचे याबद्दलच्या सूचनांइतके आहे. त्यामुळे, तुम्हाला वारंवार "Load when," असे दिसेल, "This Skill does." हे महत्त्वाचे आहे कारण बहुतेक अंमलबजावणी मॉडेल संदर्भात वर्णन कसे इन्जेक्ट करतात.

फ्रंटमॅटरमध्ये, “depends:” देखील आहे, जे तुम्हाला श्रेणीबद्ध कौशल्य धवलता तयार करण्यास अनुमती देते, आणि “metadata:”, जे पुनरावलोकने आणि मूल्यमापनांसाठी वापरले जाते. भिन्न एजंट सिस्टम्स त्या सिस्टम्ससाठी विशिष्ट पद्धतीने वापरल्या जाणाऱ्या स्वतःच्या फ्रंटमॅटर फील्ड देखील परिभाषित करू शकतात. पर्याय म्हणून, मॉडेलच्या संदर्भाला बारीकसारीक गोष्टींनी दूषित न करता प्रत्येक कौशल्यानुसार वेगवेगळ्या प्रकारच्या रनटाइम वर्तनाला सुलभ करण्याची आवश्यकता असलेल्या एजंट सिस्टम तयार करताना कौशल्य-विशिष्ट मेटाडाटा सहाय्यक JSON किंवा YAML कॉन्फिगरेशन फाइलमध्ये पॅकेज केला जाऊ शकतो. वाचनावर कौशल्य फ्रंटमॅटर काढून टाकून समान वर्तन प्राप्त करता येते. Computer ही पद्धत वापरते, ज्यामुळे मूळ SKILL.md फाइलमध्ये कॉन्फिगरेशन जतन केले जाऊ शकते. पार्सिंग लॉजिकमध्ये तपशीलाकडे लक्ष देणे आवश्यक आहे, आणि मॉडेल संदर्भात असणे उपयुक्त असलेली विशिष्ट फील्ड असल्यास तुम्ही सशर्त स्ट्रिपिंग लागू करू शकता.

कौशल्य हे इनव्होकेबल असते

कौशल्य इनव्होकेबल असते. एजंट रनटाइमवर कौशल्य लोड करतो. महत्त्वाचे म्हणजे, कौशल्ये नेहमी संदर्भात बंडल केली जात नाहीत. डीफॉल्टनुसार, बहुतेक एजंट सिस्टम विशिष्ट आवश्यकतेनुसार कौशल्ये उत्तरोत्तर उलगडतात.

आम्ही Computer मध्ये Skills ज्या पद्धतीने अंमलात आणले आहेत, त्यात किमान तीन स्तरांचे context costs आहेत. प्रक्रिया अशी आहे:

Computer कॉल करतो load_skill(name="...")

Computer कौशल्य डिरेक्ट्री एकात्मिक अंमलबजावणी सँडबॉक्समध्ये कॉपी करतो

Computer “depends:” टॅग मधील धवलता पुनरावृत्तीनुसार स्वयंचलितपणे लोड करतो

Computer नंतर फ्रंटमॅटर काढून टाकतो आणि त्यामुळे एजंटला केवळ मुख्य भाग आणि अतिरिक्त फाईल्स दिसतात

वेगवेगळ्या agent systems Skills content वेगवेगळ्या प्रकारे उघड करण्याचा निर्णय घेऊ शकतात. उदाहरणार्थ, काही systems file hierarchy अजिबात उघड न करण्याचा निर्णय घेऊ शकतात, आणि hierarchy filesystem operations द्वारे model ने शोधावी अशी मुभा देतात. इतर systems model ला एका ठरावीक truncation आणि/किंवा depth limit पर्यंत संपूर्ण filetree चे mapping देण्याचा निर्णय घेऊ शकतात. context स्वच्छ ठेवण्यासाठी, Computer invocation context मधून full file hierarchies वगळते; तथापि, हे प्रति-Skill आधारावर बदलता येते.

कौशल्य हे प्रोग्रेसिव्ह असते

कौशल्ये प्रोग्रेसिव्ह असतात. Computer मध्ये, संदर्भ खर्चाचे तीन वेगवेगळे स्तर आहेत, आणि आम्ही विविध टप्प्यांवर तिन्ही खर्च सहन करतो:

Skill संदर्भाच्या तीन पातळ्या: index, पूर्ण Skill load, आणि runtime reference files.

Computer एक कौशल्य इंडेक्स तयार करतो ज्यामध्ये प्रत्येक उपलब्ध कौशल्यासाठी नाव आणि वर्णन असते. यासाठीचे बजेट प्रति कौशल्य सुमारे १०० टोकन्स आहे (कमी असल्यास आणखी चांगले). हे इतके घट्ट आहे कारण तुम्ही प्रत्येक सत्रात, प्रत्येक वापरकर्त्यासाठी हा खर्च देत आहात. संभाषणाच्या अगदी सुरुवातीला हे सिस्टम प्रॉम्प्टमध्ये इन्जेक्ट केले जाते. मॉडेलकडे नामांकित कौशल्ये आणि वर्णनांचा एक गट असतो जेणेकरून ते “load_skill()” कॉल करायचे की नाही हे ठरवू शकेल. या इंडेक्समध्ये जाण्याची अट अत्यंत उच्च आहे. तुमचे कौशल्य अतिशय उपयुक्त असणे आवश्यक आहे, आणि वर्णन अत्यंत दाट आणि संक्षिप्त असणे आवश्यक आहे कारण प्रत्येकजण नेहमीच खर्च देत असतो.

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

प्रगतीची अंतिम पातळी म्हणजे स्क्रिप्ट्स किंवा विशेष प्रकरणे, जसे की सबस्किल्स किंवा फॉरमॅटिंग. येथे तुम्हाला अमर्याद सशर्त शाखा लॉजिक ठेवायचे आहे. एजंट ते आवश्यक असेल तेव्हाच वापरेल, याचा अर्थ तुम्हाला येथे जे ठेवू इच्छित आहात त्यासाठी खूप कमी बार आहे.

इंडेक्समध्ये, प्रत्येक टोकन महत्त्वाचे आहे. लोड केलेले कौशल्य मुख्य भाग अधिक आरामशीर आहे, आणि रनटाइम सर्वात आरामशीर आहे. हे २०,००० टोकन्स किंवा शून्य टोकन्स असू शकतात. ही ती पातळी आहे ज्यावर तुम्ही प्रोग्रेसिव्ह पद्धतीने मॉडेलचा संदर्भ विस्तृत करण्याचा विचार करू शकता.

तुम्हाला कौशल्याची गरज कधी असते?

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

जेव्हा तुम्हाला कौशल्याची गरज असते

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

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

जेव्हा तुम्हाला कौशल्याची गरज नसते

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

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

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

प्रत्येक कौशल्य हा एक कर आहे

येथे एक उपयुक्त चाचणी आहे जी तुम्ही तुमच्या कौशल्यातील प्रत्येक वाक्यावर लागू करू शकता: “या सूचनेशिवाय एजंट हे चुकीचे करेल का?” वाक्य तिथे असणे आवश्यक नसल्यास, ते तिथे परवडू शकत नाही कारण प्रत्येकजण प्रत्येक वेळी हा खर्च देत आहे. तुम्ही कौशल्य जोडायचे की नाही हे ठरवत असताना, प्रत्येक सत्र आणि प्रत्येक वापरकर्त्याला टोकन्सचा खर्च येतो हा कर लक्षात ठेवा.

खालील प्रसिद्ध कोट, जे फ्रेंचमध्ये बरेच चांगले वाटते, त्याचे अंदाजे भाषांतर असे होते “मी हे पत्र फक्त लांब केले आहे कारण मला ते लहान करण्यासाठी वेळ मिळाला नाही.”

« Je n’ai fait celle-ci plus longue que parce que je n’ai pas eu le loisir de la faire plus courte. » — Blaise Pascal, Lettres Provinciales, 1657

पास्कल प्रमाणेच, तुम्हाला प्रत्येक कौशल्यामध्ये वेळ गुंतवणे आवश्यक आहे. लहान कौशल्य लिहिणे कठीण आहे. तुमचे कौशल्य लिहिणे सोपे असल्यास, ते कदाचित खूप मोठे आहे किंवा अस्तित्वात असावे. चांगले कौशल्य शक्य तितके लहान असते.

जर तुम्हाला असे आढळले की तुम्ही वन-शॉट कौशल्य पिढी करण्याचा प्रयत्न करत आहात आणि पाच मिनिटांत PR टाकत आहात, तर परिणाम नक्कीच सुमार असतील. वास्तव्यात, सुरुवातीच्या संशोधनाने दर्शवले आहे की जर तुम्ही कौशल्ये लिहिण्यासाठी LLM वापरत असाल, तर LLM ला कदाचित त्याचा फायदा होणार नाही: “स्वयं-उत्पादित कौशल्ये सरासरी कोणताही फायदा देत नाहीत, हे दर्शविते की मॉडेल्स ते वापरून फायदा मिळवणारे प्रक्रियात्मक ज्ञान विश्वसनीयपणे लिहू शकत नाहीत.”

कौशल्य कसे तयार करावे

दुसऱ्या शब्दांत सांगायचे तर, तुम्ही लिहिलेल्या कोणत्याही कौशल्यामध्ये तुमचे मत इन्जेक्ट करणे आवश्यक आहे. या पायऱ्या फॉलो करा.

पायरी ०: ईव्हाल्स लिहा

पहिले काही ईव्हाल्स लिहा. तुम्ही येथून मूल्यमापन प्रकरणे प्राप्त करू शकता:

वास्तविक वापरकर्ता क्वेरी: प्रोडक्शन किंवा तुमच्या ब्रेन ट्रस्टमधून नमुना घ्या

ज्ञात अपयश: कौशल्य अस्तित्वात नसल्यामुळे एजंट अपयशी ठरला

शेजारी गोंधळ: तुमच्या डोमेन मर्यादेच्या जवळ आहे परंतु दुसऱ्या कौशल्याकडे मार्गक्रमण करतो

सर्वात कमी, तुम्ही हे खात्री करत असले पाहिजे की जेव्हा आवश्यक असेल तेव्हा कौशल्य लोड होते की नाही याची चाचणी घेत आहात. आदर्शपणे, तुम्ही यापैकी काही नमुने घ्या, कदाचित प्रोडक्शन वातावरणा from. तुम्ही ज्ञात त्रुटी प्रकरणांचा देखील विचार करू शकता: कदाचित तुम्ही कौशल्य लिहिण्याचे ठरवले कारण तुम्हाला लक्षात आलेले विशिष्ट अपयश आहे किंवा कदाचित तुम्ही रिफॅक्टरिंग करत आहात आणि एका कौशल्याद्वारे संरक्षित दोन जवळच्या डोमेनमध्ये काही गोंधळ आहे.

समान नकारात्मक आणि सकारात्मक उदाहरणांसह प्रारंभ करा. नकारात्मक उदाहरणे अत्यंत शक्तिशाली असतात आणि सकारात्मक उदाहरणांपेक्षा जास्त महत्त्वाची असू शकतात.

पायरी १: वर्णन

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

पुन्हा, एक वाईट वर्णन कौशल्य काय करते किंवा ते का उपयुक्त आहे याचे वर्णन करते. एक चांगले वर्णन सांगते की एजंटने कौशल्य कधी लोड करावे. उदाहरणार्थ, समजा तुमच्याकडे पुल रिक्वेस्ट्स मॉनिटर करण्यासाठी काहीतरी आहे. कौशल्य काय करते ते लिहू नका. इंजिनिअर्स निराश झाल्यावर आणि त्यांची PR काम करते याची खात्री करायची असते तेव्हा ते काय म्हणतात ते लिहा, जसे की “babysit” किंवा “watch CI” किंवा “make sure this lands.”

येथे एक जलद चेकलिस्ट आहे:

"Load when..." ने सुरू होते

५० शब्द किंवा त्यापेक्षा कमी लक्ष ठेवा

वापरकर्त्याच्या हेतूचे वर्णन करते, आदर्शपणे वास्तविक क्वेरीवरून

वर्कफ्लोचा सारांश देत नाही

वास्तविक क्वेरी अशा आहेत ज्या तुम्ही ८०-२० मध्ये कव्हर करू शकता. सहसा, दोन किंवा तीन उदाहरणे चांगले काम करतात. तुम्हाला आवश्यक तेवढे आणि अचूक जोडणे सोपे नाही.

पायरी २: मुख्य भाग लिहा

पुढे, कौशल्याची सामग्री स्वतः लिहा. लक्षात ठेवा ही पायरी ० किंवा पायरी १ नाही.

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

तुम्ही मुख्य भाग लिहीत असताना, स्पष्ट गोष्टी वगळा. अनेक इंजिनिअर्सना readme.md फाईल्स लिहिण्याचा भरपूर अनुभव आहे ज्या कोणालाही चालवाव्या लागणाऱ्या प्रत्येक कमांडची सूची देतात. तुम्ही कौशल्य लिहीत असताना त्यामध्ये परत येणे सोपे आहे कारण असे वाटते की तुम्ही दस्तऐवजीकरण लिहीत आहात, परंतु तुम्ही ते केल्यास, तुमचे कौशल्य कचरा होईल. त्यामुळे, कमांडची मालिका लिहू नका.

उदाहरणार्थ, तुम्हाला “git log # find the commit; git checkout main; git checkout -b <clean-branch>; git cherry-pick <commit>;” लिहिण्याची गरज नाही

त्याऐवजी, “Cherry-pick the commit onto a clean branch. Resolve conflicts preserving intent. If it can't land cleanly, explain why.” लिहा.

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

पुढे, गॉच्याज किंवा नकारात्मक उदाहरणांवर लक्ष केंद्रित करा. हे अत्यंत उच्च-सिग्नल सामग्री आहेत कारण ते सहसा मॉडेलला काय करू नये या संदर्भात मार्गदर्शन करतात. एजंट अडखळतो तेव्हा तुम्ही प्रत्येक वेळी एक ओळ जोडल्यास, तुम्ही ते चालवून शिकाल आणि गॉच्याज सेंद्रियपणे वाढतील.

शेवटी, जर कोणतीही बाजू सशर्त किंवा सामग्रीमध्ये अत्यंत जड असेल, तर ती SKILL.md मधून काढून टाका, जी हब आहे, आणि ती स्पोकपैकी एका मध्ये ठेवा. ती एका ॲक्सेसरी फाईलमध्ये ठेवा जी प्रोग्रेसिव्ह पद्धतीने लोड केली जाऊ शकते, ज्यामध्ये आपण पुढे डुबकी मारू.

पायरी ३: हायरार्की वापरा

जेव्हा तुमच्याकडे स्क्रिप्ट, संदर्भ असतात किंवा तुम्ही काही विशिष्ट साधन वापरत असता तेव्हा कौशल्य हायरार्कीचा वापर करा:

Skill मध्ये scripts, references, assets, आणि configuration यांसाठी सुचविलेले उपयोग.

मुख्य कौशल्यापासून सशर्त किंवा ब्रँचिंग असलेल्या कोणत्याही गोष्टीसाठी, ती एका फोल्डरमध्ये विभाजित करा. लक्षात ठेवा, विशेषतः गुंतागुंतीच्या कौशल्यांसाठी मल्टीलेव्हल हायरार्की देखील वापरली जाऊ शकते. यांच्यासाठी, कार्यक्षमता एकात्मिक पद्धतीने किंवा कौशल्यांच्या संकलना रूपामध्ये (कदाचित depends: आधारित लोड रिलेशनशिपसह) अंमलात आणली पाहिजे की नाही याबद्दल तुम्ही काळजीपूर्वक विचार करू इच्छिता.

पायरी ४: इटरेट करा

पुढे, एका शाखेवर अनेक पुनरावृत्ती करा. कौशल्याशिवाय मुख्य शाखेपासून सुरुवात करा, काही पुनरावृत्ती करा, तुमचा हिरो क्वेरी संच तयार करा आणि ईव्हाल्सचा एक संच चालवा. तुमच्या कौशल्य कोडचे पुनरावलोकन करणारी कोणतीही व्यक्ती मूल्यमापन संचासह पूर्ण एकच चेंजसेट सबमिट केल्याबद्दल तुमचे आभार मानेल. सलग वृद्धीशील बदलांचे पुनरावलोकन करणे (नवीन गॉच्या वगळता) खूप कठीण आहे, त्यामुळे ते कमी करण्याचा प्रयत्न करा.

तुम्ही कदाचित अनेक छोटे शब्द बदल कराल. वर्णनांमधील लहान शब्दांचे बदल रुटिंगवर मोठा प्रभाव टाकू शकतात (इतर कौशल्यांवर स्पिलओव्हर प्रभावांसह), त्यामुळे पायरी ५ च्या आधी ते सर्व काम करा.

पायरी ५: शिप करा

शिप करा.

कौशल्य कसे मेंटेन करावे

आता तुम्ही कौशल्य लिहिले आहे, तुम्हाला ते मेंटेन करावे लागेल.

गॉच्याज फ्लाईव्हील

या बिंदूपासून, तुमच्या गॉच्याजची सूची वाढते किंवा बरीच बदलते. आम्ही अनेकदा असे इंजिनिअर्स पाहतो जे PR बनवतात जे अन-ईव्हाल्ड असतात, उदाहरणार्थ, वर्णन बदलतात. तुमचे कौशल्य मर्ज झाल्यानंतर तुम्ही वर्णन बदलत असल्यास, तुम्ही ट्रॅकबाहेर आहात. तुमचे कौशल्य कुठे रूट करायचे हे ठरवणारी गोष्ट तुम्ही बदलत असल्यास, तुम्हाला बदलांना समर्थन देणारे काही ईव्हाल्स लिहावे लागतील.

कौशल्ये ॲपेंड-मोस्टली असतात. काळाबरोबर गॉच्याज विभाग सर्वाधिक मूल्य जमा करतो:

एजंट कशाततरी अपयशी ठरतो → गॉच्या जोडा

एजंट ऑफ टारगेट कौशल्य लोड करतो → वर्णन कडक करा आणि नकारात्मक ईव्हाल्स जोडा

जेव्हा आवश्यक असते तेव्हा एजंट कौशल्य लोड करत नाही → कीवर्ड आणि सकारात्मक ईव्हाल्स जोडा

सिस्टम प्रॉम्प्ट बदलते → सामग्री किंवा डुप्लिकेशन तपासा

अंतर्गत चाचणीमध्ये किंवा प्रोडक्शनमध्ये एकाच अपयशाचे प्रकरण लक्षात घेणे आणि गॉच्या जोडणे सोपे आहे. हे एक नकारात्मक उदाहरण आहे त्यामुळे ते खरोखर स्पष्ट मार्गदर्शन बदलत नाही, परंतु ते मॉडेलला कळू देते, “अरे, हे ज्ञात अपयश आहे.”

तुम्ही ८०-२० वरून ९९.९% किंवा ९९.९९% यश दरापर्यंत जात असताना, ही गॉच्या सूची वाढवणे सोपे आहे. जसे तुम्ही ही नकारात्मक उदाहरणे पाहता, तुम्ही गॉच्या विभागात बहुतेक जोडले पाहिजे. तुम्ही दीर्घ सूचना जोडत नाही किंवा वर्णन बदलत नाही.

ईव्हॉल स्वीट्स

Perplexity मध्ये, आम्ही वेगवेगळ्या गोष्टी तपासायला अनेक ईव्हॉल स्वीट्स चालवतो. कौशल्य लोड करणे आणि कौशल्य फाईल रीड्स आहेत, जे कौशल्य लोड करण्याच्या अचूकता, रिकॉल आणि प्रतिबंधित तपासण्या तपासतात. जेव्हा तुमचे कौशल्य रूट केले जाणे अपेक्षित असते तेव्हा ते रूट करेल का? नवीन कौशल्ये विद्यमान मर्यादा तोडत नाहीत याची खात्री करतात.

योग्य प्रोग्रेसिव्ह लोड तपासू शकणारे ईव्हाल्स देखील आहेत. एजंट कौशल्य लोड करू शकतो, परंतु ते ॲक्सेसरी फाईल किंवा फाईल्स वाचते का? उदाहरणार्थ, जर तुमच्याकडे वित्त क्वेरींसाठी वित्त कौशल्य असेल, तर ते विशेष FORMATTING.md फाईल वाचते का?

डोमेनमध्ये एंड-टू-एंड कार्य पूर्ण करण्याची चाचणी घेणाऱ्या कौशल्यांसाठी ईव्हाल्स देखील आहेत. आम्ही संपूर्ण एजंट लूप चालवतो आणि चांगल्या प्रकारे परिभाषित निकषांच्या रुब्रिकच्या आधारावर निकालांचे श्रेणीकरण करण्यासाठी LLM न्यायाधीशाचा वापर करतो.

शेवटी, वेगवेगळ्या मॉडेल्सविरुद्ध हे ईव्हाल्स चालवणे महत्त्वाचे आहे. Computer किमान तीन वेगवेगळ्या ऑर्केस्ट्रेशन मॉडेल कुटुंबांना समर्थन देते: GPT, Claude Opus, आणि Claude Sonnet. तुम्हाला वेगळे वर्तन मिळणार नाही याची खात्री करण्यासाठी तुम्ही तुमचे कौशल्य लोड करणे आणि डोमेन कौशल्ये या वेगवेगळ्या एजंट ऑर्केस्ट्रेटरविरुद्ध चालवू इच्छिता. कौशल्यांच्या बाबतीत Sonnet आणि GPT अगदी वेगळे वर्तन करतात.

अंतिम विचार आणि टेकवे

जितकी जास्त कौशल्ये तुम्ही तयार कराल, तितके तुम्ही ती तयार करण्यात चांगले व्हाल. जर तुम्ही कौशल्यांचा वापर करून तुमच्या दैनंदिन जीवनात करत असलेली कामे स्वयंचलित करत नसाल किंवा अधिक पुनरुत्पादक बनवण्याचा प्रयत्न करत नसाल, तर त्वरित सुरुवात करा.

कौशल्ये तयार करण्याची कृती तुम्हाला अधिक कौशल्ये तयार करण्यात चांगली बनवते, परंतु त्याशिवाय, ते व्यवसाय प्रक्रिया स्वयंचलित करण्यात अत्यंत चांगले आहेत. तुमच्या स्टँडअपच्या आधी प्रत्येक आठवड्यात तुम्ही करत असलेली कोणतीही गोष्ट तुम्ही वर्णन करू शकत असल्यास, प्रत्येक स्प्रिंटच्या शेवटी, किंवा इंजिनिअर म्हणून तुम्ही दैनंदिन, साप्ताहिक किंवा अगदी त्रैमासिक आधारावर करत असलेली कोणतीही गोष्ट, तुम्ही तुमचा वेळ परत विकत घेण्यासाठी कौशल्य लिहिले पाहिजे.

तुम्ही पोस्टमॉर्गेम्स स्वयंचलित करू शकता का? तुम्ही पुल रिक्वेस्ट्सचे पुनरावलोकन करू शकता का? तुम्ही करू शकता असे कोणतेही कार्य, तुम्ही किमान पहिली पास एजंट कौशल्य असू शकता. यामुळे तुमचा महत्त्वपूर्ण वेळ वाचेल.

असे म्हटले तरी, लक्षात ठेवा की कौशल्य सोपे किंवा नेहमीच आवश्यक नसते. कमीत कमी अधिक आहे. काही इतर टेकवे:

कौशल्याच्या आधी ईव्हाल्स लिहा. समीप परंतु भिन्न कौशल्यांसाठी नकारात्मक उदाहरणे आणि प्रतिबंधित भार समाविष्ट करा.

वर्णन हा कठीण भाग आहे. "Load when..." (प्रत्येक शब्दाचा लक्ष देण्याचा खर्च येतो).

गॉच्याज ही अत्यंत उच्च-मूल्याची सामग्री आहे. पातळ सुरुवात करा, एजंट अपयशी ठरल्यास वाढवा.

नवीन कौशल्य जोडल्यामुळे इतर पूर्व-विद्यमान कौशल्ये तोडणे सोपे असते, जरी तुम्ही त्याला स्पर्श केला नसला तरीही (अंतरावर कारवाई सावधगिरी बाळगा).

जेव्हा तुम्ही कौशल्य लिहीत आणि मेंटेन करत असता तेव्हा प्रत्येक वेळी उपलब्ध सर्व साधने वापर करा. तुम्हाला अधिक जाणून घ्यायचे असल्यास, Agent Skills वेबसाइटवर अनेक चांगली उदाहरणे आहेत, आणि आमचे अंतर्गत रिपॉजिटरी आणि सार्वजनिक इकोसिस्टम दोन्हीमध्ये सु-डिझाइन केलेल्या कौशल्यांची अनेक उदाहरणे आहेत.

उद्धरण

@online{perplexity2026DesigningRefiningAndMaintainingAgentSkillsAtPerplexity,
  author = {{Perplexity} and Marshall Kiely and Daisy Lee and Jerry Ma and Lauren Kolm},
  title = {{Designing, refining, and maintaining agent skills at Perplexity}},
  date = {2026-05-01},
  url = {https://perplexity.coolkeypoint.com/hub/blog/designing-refining-and-maintaining-agent-skills-at-perplexity}
}