Perplexity-യിൽ ഏജന്റ് നൈപുണ്യങ്ങൾ രൂപകൽപ്പന ചെയ്യുക, പരിഷ്കരിക്കുക, പരിപാലിക്കുക

Perplexity-യുടെ മുൻനിര ഏജന്റ് ഉൽപ്പന്നങ്ങൾ, മോഡുലാർ Agent Skills-ൽ പാക്കേജ് ചെയ്ത know-how-യും domain expertise-ഉം അടങ്ങിയ ഒരു അടിത്തറയിൽ നിലകൊള്ളുന്നു. ഞങ്ങളുടെ സാങ്കേതിക പരിതസ്ഥിതികളിലുടനീളം നന്നായി തിരഞ്ഞെടുത്ത Skills ലൈബ്രറി ഞങ്ങൾ നിലനിർത്തുന്നു. ഈ Skills-ിൽ Perplexity Computer-നെ പ്രവർത്തിപ്പിക്കുന്ന പൊതുപ്രയോജന ഉപകരണങ്ങളിൽ പലതും; finance, law, health തുടങ്ങിയ മേഖലകളിലെ vertical-specific capabilities; കൂടാതെ ഉപയോക്തൃ ആവശ്യങ്ങൾ പരിഹരിക്കുന്നതിനുള്ള വളരെ നീണ്ടതാളിലുള്ള modules എന്നിവ ഉൾപ്പെടുന്നു. ചില Skills വളരെ അപൂർവമായി മാത്രമേ വിളിക്കപ്പെടാറുള്ളൂ, പക്ഷേ വിളിക്കപ്പെടുമ്പോൾ നിർണായകമാണ് when. സ്ഥിരമായി ഉന്നതമായ user experience ഉറപ്പാക്കാൻ, Perplexity-യുടെ Agents ടീം code quality-നെപ്പോലെ തന്നെ Skill quality-യ്ക്കും മുൻഗണന നൽകുന്നു.

ഉയർന്ന നിലവാരമുള്ള ഒരു നൈപുണ്യം വികസിപ്പിക്കാൻ ആവശ്യമായ ഉൾക്കാഴ്ചകളും മികച്ച രീതികളും പരമ്പരാഗത സോഫ്റ്റ്‌വെയർ നിർമ്മിക്കുന്നതിന് ആവശ്യമായതിൽ നിന്ന് വളരെ വ്യത്യസ്തമാണ്. തങ്ങളുടെ ജോലിയുടെ ഭാഗമായി നൈപുണ്യങ്ങൾ വികസിപ്പിക്കുന്ന മികച്ച എൻജിനീയർമാരിൽ നിന്നുള്ള നിരവധി പുൾ അഭ്യർത്ഥനകൾ ഏജന്റ്സ് ടീം അവലോകനം ചെയ്യാറുണ്ട്. ഇതിന്റെ ഫലമായി മിക്കവാറും നിരവധി അഭിപ്രായങ്ങളും പുനരവലോകനത്തിനുള്ള നിർദ്ദേശങ്ങളും ഉണ്ടാകാറുണ്ട്. കോഡ് എഴുതുന്നതിനുള്ള പല ഉപയോഗപ്രദമായ പാറ്റേണുകളും നൈപുണ്യം സൃഷ്ടിക്കുന്നതിൽ ആന്റിപാറ്റേണുകളായി മാറുന്നു എന്നതാണ് ഇതിന് കാരണം.

ഉദാഹരണത്തിന്, നിങ്ങൾ PEP20 – The Zen of Python-ൽ നിന്നുള്ള aphorisms ചിലത് എടുത്താൽ, നല്ല Python code എഴുതുന്നതും നല്ല Skills എഴുതുന്നതും തമ്മിൽ വലിയ വ്യത്യാസമുണ്ടെന്ന് പെട്ടെന്ന് വ്യക്തമായി വരുന്നു. ആ 20 wisdom വരികളിൽ കുറഞ്ഞത് പകുതി Skills എഴുതുമ്പോൾ പൂർണ്ണമായും തെറ്റായതോ നേരിട്ട് തെറ്റിദ്ധരിപ്പിക്കുന്നതോ ആണ്. അവയിൽ അഞ്ചെണ്ണം ഇതാ:

Pythonന്റെ സ Zen-നും Skills എഴുതുന്നതിനുള്ള ലേഖനത്തിന്റെ മാർഗ്ഗനിർദ്ദേശത്തിനുമിടയിലെ അഞ്ച് വ്യത്യാസങ്ങൾ.

Perplexity-യിലുടനീളമുള്ള എൻജിനീയർമാർ നൈപുണ്യങ്ങൾ വികസിപ്പിക്കുമ്പോഴും അവലോകനം ചെയ്യുമ്പോഴും ഉപയോഗിക്കുന്ന രേഖയാണ് ഈ ഗൈഡ്. ഞങ്ങളുടെ കണ്ടെത്തലുകളും പഠനങ്ങളും വിശാലമായ സമൂഹത്തിന് പ്രയോജനപ്പെടുത്തുന്നതിനായി ഞങ്ങൾ ഈ ഗൈഡ് പൊതുജനങ്ങൾക്ക് ലഭ്യമാക്കുന്നുണ്ട്. നിങ്ങൾ ദിവസേനയുള്ള ജോലികളിൽ പ്രൊഡക്ഷൻ നൈപുണ്യങ്ങൾ രൂപകൽപ്പന ചെയ്യുന്ന ഒരു എൻജിനീയറോ, നിങ്ങൾക്ക് ഏറ്റവും നന്നായി അറിയാവുന്ന ഒരു മേഖലയിൽ നിങ്ങളുടെ സ്വന്തം നൈപുണ്യം വികസിപ്പിക്കാൻ ആഗ്രഹിക്കുന്ന Computer ഉപയോക്താവോ, അല്ലെങ്കിൽ ഇവ രണ്ടും കൂടിയോ ആകട്ടെ, ഈ ഗൈഡ് നിങ്ങൾക്കുള്ളതാണ്.

എന്താണ് ഒരു നൈപുണ്യം?

നിങ്ങൾ ഒരു നൈപുണ്യം എഴുതുമ്പോൾ, നിങ്ങൾ പഴയ ലളിതമായ സോഫ്റ്റ്‌വെയർ അല്ല എഴുതുന്നത് (നൈപുണ്യങ്ങൾ ഇപ്പോൾ ഏജന്റ് സിസ്റ്റങ്ങൾക്കായുള്ള പ്രധാന ലോജിക്കൽ എൻജിനുകളുടെ ഭാഗമാണെങ്കിൽ പോലും). മറിച്ച്, നിങ്ങൾ മോഡലുകൾക്കും അവയുടെ പരിതസ്ഥിതികൾക്കുമായി സന്ദർഭം നിർമ്മിക്കുകയാണ്. ഒരു നൈപുണ്യത്തിന് വ്യത്യസ്തമായ പരിമിതികളും വ്യത്യസ്തമായ രൂപകൽപ്പന തത്വങ്ങളും ഉണ്ട്. നിങ്ങൾ കോഡ് എഴുതുന്നത് പോലെ ഒരു നൈപുണ്യം എഴുതുകയാണെങ്കിൽ, നിങ്ങൾ പരാജയപ്പെടും.

പ്രത്യേകിച്ച് Perplexity-യിൽ ഞങ്ങൾ അവ നിർമ്മിക്കുന്നതിന്റെ സന്ദർഭത്തിൽ, ഒരു നൈപുണ്യം കുറഞ്ഞത് നാല് കാര്യങ്ങളാണ്.

ഒരു നൈപുണ്യം ഒരു ഡയറക്ടറിയാണ്

ഒരു Skill എന്നത് വെറും ഒറ്റ SKILL.md ഫയൽ മാത്രമല്ല. പല സാഹചര്യങ്ങളിലും, ഒരു Skill-ൽ പല ഫയലുകളും ഉൾപ്പെടും. നിങ്ങളുടെ Skill-ന്റെ പേരിലുള്ള ഡയറക്ടറിയിൽ, നിങ്ങൾക്കുണ്ടാകാമെന്ന് കരുതുക:

SKILL.md: ഫ്രണ്ട്മാറ്ററും നിർദ്ദേശങ്ങളും

scripts/: ഏജന്റ് പ്രവർത്തിപ്പിക്കുന്ന കോഡ്, വീണ്ടും കണ്ടുപിടിക്കുന്നതല്ല

references/: കനത്ത ഡോക്യുമെന്റുകൾ, നിബന്ധനകൾക്ക് വിധേയമായി ലോഡ് ചെയ്യുന്നത്

assets/: ടെംപ്ലേറ്റുകൾ, സ്കീമാറ്റുകൾ, ഡാറ്റ

config.json: ആദ്യമായി പ്രവർത്തിപ്പിക്കുമ്പോഴുള്ള ഉപയോക്തൃ സജ്ജീകരണം

ഈ ഹബ്-ആൻഡ്-സ്പോക്ക് പാറ്റേൺ നൈപുണ്യങ്ങളെ വളരെ ശ്രദ്ധ കേന്ദ്രീകരിച്ചതും കൃത്യവുമായ രീതിയിൽ നിലനിർത്താൻ നിങ്ങളെ അനുവദിക്കുന്നു, കൂടാതെ ഒരാൾക്ക് ഫോൾഡർ ഘടന വളരെ ക്രിയാത്മകമായ രീതിയിൽ ഉപയോഗിക്കാൻ കഴിയും. ചിലപ്പോൾ, പ്രത്യേകിച്ച് സങ്കീർണ്ണമായ നൈപുണ്യങ്ങൾക്ക് മികച്ച രീതിയിൽ നാവിഗേറ്റ് ചെയ്യാൻ മോഡലിനെ സഹായിക്കുന്നതിന് ഒന്നിലധികം തലത്തിലുള്ള ശ്രേണി പ്രയോജനപ്പെടും. 20 വിഷയ മേഖലകളായി ഗ്രൂപ്പുചെയ്യാൻ കഴിയുന്ന 300 വിഷയങ്ങളിലുടനീളം ഒരു നൈപുണ്യത്തിന് അറിവ് ആവശ്യമാണെന്ന് കരുതുക. ഇന്നത്തെ ഏറ്റവും മികച്ച ഫ്രോണ്ടിയർ മോഡലുകൾക്ക് പോലും 300-ൽ നിന്ന് ശരിയായ വിഷയം വിശ്വസനീയമായി തിരഞ്ഞെടുക്കുക എന്നത് പരിഹരിക്കപ്പെടാത്ത ഒരു വെല്ലുവിളിയാണ്. ആ പ്രദേശത്തെ 15 വിഷയങ്ങൾക്കിടയിലുള്ളതിനേക്കാൾ, 20 മേഖലകളിൽ ഒരെണ്ണത്തിൽ ശ്രദ്ധ കേന്ദ്രീകരിക്കാൻ ഒരു മോഡലിന് വളരെ എളുപ്പമുള്ള ഒരു തിരഞ്ഞെടുപ്പ് പ്രശ്നമാണിത്.

മൾട്ടിലെവൽ hierarchy എങ്ങനെ value നൽകുന്നു എന്നതിനുള്ള ഒരു ഉദാഹരണമായി, ഈ കഴിഞ്ഞ tax season-ൽ Computer-ന്റെ U.S. income tax capabilities പ്രവർത്തിപ്പിക്കുന്ന Skills-ൽ ഞങ്ങളുടെ ടീം topical nesting-ന്റെ മൂന്ന് തലങ്ങൾ പ്രയോഗിച്ചു. tax law-ന്റെ സങ്കീർണ്ണത കണക്കിലെടുക്കുമ്പോൾ ഈ hierarchy പൂർണ്ണമായും അനിവാര്യമായിരുന്നു: ഞങ്ങളുടെ ആദ്യകാല tests-ൽ, U.S. Internal Revenue Code-ന്റെ 1,945 sections മുഴുവൻ ഉൾക്കൊള്ളുന്ന ഒരൊറ്റ folder model-ന് നൽകിയത്, Skill ഒന്നും ലോഡ് ചെയ്യാതിരുന്ന സാഹചര്യത്തേക്കാൾ മോശം performance ഉണ്ടാക്കി. വിവരങ്ങളെ താർക്കിക subdivisions ആയി ക്രമീകരിക്കുന്നത് high-precision read operations ഉറപ്പാക്കാൻ അനിവാര്യമായിരുന്നു.

എന്നിരുന്നാലും ഈ ശ്രേണി സൗജന്യമായി ലഭിച്ചതല്ല. ഫലമായുണ്ടാകുന്ന ഇൻഡയറക്ഷൻ കൈകാര്യം ചെയ്യുന്നതിനായി ഇൻഫർമേഷൻ ആർക്കിടെക്ചറിലുടനീളം വർദ്ധിച്ചുവരുന്ന തലത്തിലുള്ള ക്യൂറേഷൻ വർദ്ധിച്ചുവരുന്ന തലത്തിലുള്ള ശ്രേണി ആവശ്യപ്പെടുന്നു. കുറഞ്ഞ ഇൻഡയറക്ഷനോടുകൂടി വിവരങ്ങൾ കണ്ടെത്താൻ മോഡലിനെ പിന്തുണയ്ക്കുന്നതിനായി ഞങ്ങൾ ദ്രുത റഫറൻസ് ഗൈഡുകൾ, കസ്റ്റം സെർച്ച് യൂട്ടിലിറ്റികൾ, മറ്റ് ഉപകരണങ്ങൾ എന്നിവ രൂപകൽപ്പന ചെയ്തു. ഈ സാഹചര്യത്തിൽ, ക്യൂറേഷന്റെ കഠിനമായ ജോലി ചെയ്യുന്നത് ആത്യന്തികമായി ഒരു നല്ല അന്തിമ ഫലം നൽകി: പൊതുവായ ഉപകരണങ്ങൾ മാത്രം ഉപയോഗിക്കുന്നതിനേക്കാൾ വളരെ മികച്ച രീതിയിൽ നികുതിയുമായി ബന്ധപ്പെട്ട ടാസ്ക്കുകൾ നിർവഹിക്കാൻ മോഡലുകളെ അനുവദിച്ച ഒരു നൈപുണ്യം.

വലുതാക്കുക

ഒരു നൈപുണ്യം ഒരു ഫോർമാറ്റാണ്

ഒരു നൈപുണ്യം ഒരു ഫോർമാറ്റാണ്. പ്രധാന റൂട്ട് SKILL.md ഫയലിന് പേരും വിവരണവും ഉണ്ടായിരിക്കണം. കൂടാതെ, നൈപുണ്യം സ്ഥിതി ചെയ്യുന്ന ഡയറക്ടറി നാഭവുമായി നൈപുണ്യം കൃത്യമായി പൊരുത്തപ്പെടേണ്ടതുണ്ട്. പേര് പൂർണ്ണമായും ചെറിയ അക്ഷരങ്ങളിൽ ആയിരിക്കണം, സ്പേസുകൾ പാടില്ല, ഹൈഫനുകൾ ഉപയോഗിക്കാം. വിവരണമാണ് റൂട്ടിംഗ് ട്രിഗർ. ഇതൊരു സാധാരണ പരാജയ ബിന്ദുവാണ്: നൈപുണ്യം എന്ത് ചെയ്യുന്നു എന്നതിനായുള്ള ആന്തരിക ഡോക്യുമെന്റേഷൻ അല്ല വിവരണം. നൈപുണ്യം എപ്പോഴാണ് ലോഡ് ചെയ്യേണ്ടത് എന്നതിനെക്കുറിച്ചുള്ള മോഡലിനുള്ള നിർദ്ദേശങ്ങൾ ഇതിൽ അടങ്ങിയിരിക്കുന്നു. അതിനാൽ, “ഈ നൈപുണ്യം ചെയ്യുന്നു” എന്നതിന് പകരം “ഇത് ചെയ്യുമ്പോൾ ലോഡ് ചെയ്യുക” എന്ന് നിങ്ങൾ പതിവായി കാണും. മിക്ക നടപ്പാക്കലുകളും മോഡൽ സന്ദർഭത്തിലേക്ക് വിവരണം കുത്തിവയ്ക്കുന്ന രീതി കാരണം ഇത് പ്രധാനമാണ്.

frontmatter-നകത്ത് കൂടി “depends:” ഉണ്ട്, ഇത് hierarchical Skill dependencies സൃഷ്ടിക്കാൻ നിങ്ങളെ അനുവദിക്കുന്നു, കൂടാതെ “metadata:” ഉണ്ട്, ഇത് reviews-ക്കും evaluations-ക്കും ഉപയോഗിക്കുന്നു. വ്യത്യസ്ത agent systems-ുകൾക്ക് അവയ്ക്കുതന്നെ പ്രത്യേകമായ രീതിയിൽ ഉപയോഗിക്കാവുന്ന സ്വന്തം frontmatter fields പോലും നിർവചിക്കാം. മറ്റൊരു മാർഗമായി, Skill-specific metadata ഒരു auxiliary JSON അല്ലെങ്കിൽ YAML configuration file-ലേക്ക് പാക്കേജ് ചെയ്യാം. വ്യത്യസ്ത Skill-കൾക്കായി runtime behavior-ന്റെ വ്യത്യസ്ത തരങ്ങൾ facilitate ചെയ്യേണ്ട agent systems നിർമ്മിക്കുമ്പോൾ, model-ന്റെ context minutiae-കൊണ്ട് മലിനമാക്കാതെ ഇരിക്കാൻ ഇത് അഭിലഷണീയമാണ്. അവസാനം, read ചെയ്യുമ്പോൾ Skill frontmatter strip ചെയ്‌തു സമാനമായ behavior ലഭ്യമാക്കാം. Computer ഈ methodology ഉപയോഗിക്കുന്നു, ഇതിലൂടെ configuration root SKILL.md file-ൽ സംരക്ഷിക്കപ്പെടാൻ കഴിയും. parsing logic-ൽ വിശദാംശങ്ങളിലേക്കുള്ള സൂക്ഷ്മ ശ്രദ്ധ ആവശ്യമാണ്, കൂടാതെ model context-ിൽ ഉണ്ടായിരിക്കുമ്പോൾ ഉപകാരപ്പെടുന്ന ചില fields ഉണ്ടെങ്കിൽ conditional stripping നടപ്പിലാക്കാൻ ഒരാൾ ആഗ്രഹിച്ചേക്കാം.

ഒരു നൈപുണ്യം വിളിക്കാവുന്നതാണ്

ഒരു നൈപുണ്യം വിളിക്കാവുന്നതാണ്. റൺടൈമിൽ ഏജന്റ് ഒരു നൈപുണ്യം ലോഡ് ചെയ്യുന്നു. പ്രധാനപ്പെട്ട കാര്യം, നൈപുണ്യങ്ങൾ എല്ലായ്പ്പോഴും സന്ദർഭത്തിൽ ഉൾപ്പെടുത്തിയിട്ടില്ല എന്നതാണ്. സ്വയമേവ, മിക്ക ഏജന്റ് സിസ്റ്റങ്ങളും നിർദ്ദിഷ്ട ആവശ്യത്തിനനുസരിച്ച് നൈപുണ്യങ്ങൾ പുരോഗമനപരമായി തുറക്കുന്നു.

Computer-ൽ ഞങ്ങൾ നൈപുണ്യം നടപ്പിലാക്കിയ രീതിയിൽ സന്ദർഭ ചെലവുകളുടെ കുറഞ്ഞത് മൂന്ന് തലങ്ങളെങ്കിലും ഉണ്ട്. പ്രക്രിയ ഇതാ:

Computer load_skill(name="...") വിളിക്കുന്നു

Computer നൈപുണ്യം ഡയറക്ടറി ഒറ്റപ്പെട്ട എക്സിക്യൂഷൻ സാൻഡ്‌ബോക്സിലേക്ക് പകർത്തുന്നു

Computer “depends:” ടാഗിലെ ആശ്രിതത്വങ്ങൾ റെകർസീവായി സ്വയം ലോഡ് ചെയ്യുന്നു

Computer പിന്നീട് ഫ്രണ്ട്മാറ്റർ നീക്കം ചെയ്യുന്നു, അതിനാൽ ഏജന്റ് ബോഡിയും അധിക ഫയലുകളും മാത്രം കാണുന്നു

വ്യത്യസ്ത ഏജന്റ് സിസ്റ്റങ്ങൾക്ക് നൈപുണ്യം ഉള്ളടക്കം വ്യത്യസ്ത രീതികളിൽ തുറന്നുകാട്ടാൻ തിരഞ്ഞെടുക്കാം. ഉദാഹരണത്തിന്, ചില സിസ്റ്റങ്ങൾ ഫയൽ ശ്രേണി പൂർണ്ണമായും തുറന്നുകാട്ടാതിരിക്കാൻ തിരഞ്ഞെടുക്കാം, ഫയൽസിസ്റ്റം പ്രവർത്തനങ്ങളിലൂടെ ശ്രേണി കണ്ടെത്താൻ ഇത് മോഡലിന് വിടുന്നു. ചില പരിമിതികൾക്കും കൂടാതെ/അല്ലെങ്കിൽ ആഴത്തിലുള്ള പരിധിക്കും വിധേയമായി മുഴുവൻ ഫയൽട്രീയുടെയും മാപ്പിംഗ് മോഡലിന് നൽകാൻ മറ്റ് സിസ്റ്റങ്ങൾ തിരഞ്ഞെടുക്കാം. സന്ദർഭം വ്യക്തമായി നിലനിർത്താൻ, Computer ഇൻവോക്കേഷൻ സന്ദർഭത്തിൽ നിന്ന് പൂർണ്ണമായ ഫയൽ ശ്രേണികൾ ഒഴിവാക്കുന്നു; എന്നിരുന്നാലും, ഓരോ നൈപുണ്യത്തിന്റെ അടിസ്ഥാനത്തിൽ ഇത് മാറ്റിയെഴുതാവുന്നതാണ്.

ഒരു നൈപുണ്യം പുരോഗമനപരമാണ്

നൈപുണ്യങ്ങൾ പുരോഗമനപരമാണ്. Computer-ൽ സന്ദർഭ ചെലവുകളുടെ മൂന്ന് വ്യത്യസ്ത തലങ്ങളുണ്ട്, വിവിധ ഘട്ടങ്ങളിൽ ഞങ്ങൾ മൂന്നും വരുത്തുന്നു:

Skill context-ിന്റെ മൂന്ന് പാളികൾ: index, full Skill load, runtime reference files.

ലഭ്യമായ എല്ലാ നൈപുണ്യങ്ങളുടെയും പേരും വിവരണവും ഉള്ള ഒരു നൈപുണ്യം ഇൻഡക്സ് Computer നിർമ്മിക്കുന്നു. ഇതിനായുള്ള ബജറ്റ് ഓരോ നൈപുണ്യത്തിനും ഏകദേശം 100 ടോക്കണുകളാണ് (ചെറുതാണെങ്കിൽ അത് കൂടുതൽ മികച്ചതാണ്). എല്ലാ സെഷനിലും ഓരോ ഉപയോക്താവിനുമായി നിങ്ങൾ ഈ ചെലവ് നൽകുന്നതുകൊണ്ടാണ് ഇത് വളരെ കർശനമായിരിക്കുന്നത്. സംഭാഷണത്തിന്റെ വളരെ തുടക്കത്തിൽ ഇത് സിസ്റ്റം പ്രോംപ്റ്റിലേക്ക് കുത്തിവയ്ക്കപ്പെടുന്നു. “load_skill()” വിളിക്കണോ എന്ന് തീരുമാനിക്കാൻ മോഡലിന് നാമകരണം ചെയ്ത നൈപുണ്യങ്ങളുടെയും വിവരണങ്ങളുടെയും ഒരു കൂട്ടത്തിലേക്ക് പ്രവേശനമുണ്ട്. ഈ ഇൻഡക്സിലേക്ക് പ്രവേശിക്കുന്നതിനുള്ള ബാർ വളരെ ഉയർന്നതാണ്. നിങ്ങളുടെ നൈപുണ്യം വളരെ ഉപയോഗപ്രദമായിരിക്കണം, കൂടാതെ എല്ലാവരും എല്ലാ സമയത്തും ചെലവ് നൽകുന്നതിനാൽ വിവരണം വളരെ സാന്ദ്രവും ഹ്രസ്വവുമായിരിക്കണം.

agent system Skill load ചെയ്തതിനുശേഷം, പൂർണ്ണമായ SKILL.md body ലഭിക്കുന്നു. ഐഡിയലായി, body text 5,000 tokens-നെ കവിയരുത്. അപ്പോഴും, ഓരോ വാക്യവും പ്രാധാന്യമുള്ളതാകണം, കാരണം നിങ്ങൾ ഒരു Skill ലോഡ് ചെയ്തുകഴിഞ്ഞാൽ, compaction boundary എത്തുന്നതുവരെ ബാക്കി conversation അതിന്റെ വില നൽകേണ്ടിവരും. പല threads-ലും മൂന്ന് മുതൽ അഞ്ച് വരെ വ്യത്യസ്ത Skills ലോഡ് ചെയ്യപ്പെടുന്നു, ഇതോടെ ഈ ചെലവ് ഗുണിതമായി വർധിക്കുന്നു. fluff വളരെ കൂടുതലുള്ള Skills മറ്റുള്ള Skills-നെയും മൊത്തത്തിലുള്ള agentic capabilities-നെയും വലിയ സാധ്യതയോടെ ക്ഷയിപ്പിക്കും. ചുരുക്കത്തിൽ, നിങ്ങളുടെ Skill ലോഡ് ചെയ്തിട്ടും അത് ശരിയായ കാര്യം ചെയ്യുന്നില്ലെങ്കിൽ, അത് നഷ്‌ടമായ context ആണ്.

പ്രഗതിയുടെ അവസാന തലമാണ് scripts അല്ലെങ്കിൽ special cases, ഉദാഹരണത്തിന് subskills അല്ലെങ്കിൽ formatting. നിയന്ത്രണമില്ലാത്ത conditional branched logic നിങ്ങൾ ഇടേണ്ടത് ഇവിടെയാണ്. agent അതിന് ആവശ്യമുണ്ടാകുമ്പോൾ മാത്രമേ അത് ഉപയോഗിക്കൂ, അതായത് ഇവിടെ ഇടാൻ നിങ്ങൾ ആഗ്രഹിക്കുന്നതിനുള്ള മാനദണ്ഡം വളരെ താഴെയാണ്.

ഇൻഡക്സിൽ, ഓരോ ടോക്കണും പ്രധാനമാണ്. ലോഡ് ചെയ്ത നൈപുണ്യം ബോഡി കൂടുതൽ അയവുള്ളതാണ്, കൂടാതെ റൺടൈം ഏറ്റവും അയവുള്ളതാണ്. ഇത് 20,000 ടോക്കണുകളോ പൂജ്യം ടോക്കണുകളോ ആകാം. പുരോഗമനപരമായ രീതിയിൽ മോഡലിന്റെ സന്ദർഭം വികസിപ്പിക്കുന്നതിനെക്കുറിച്ച് നിങ്ങൾ ചിന്തിച്ചേക്കാവുന്ന തലമാണിത്.

നിങ്ങൾക്ക് എപ്പോഴാണ് ഒരു നൈപുണ്യം ആവശ്യം?

ഒരു നിർദ്ദിഷ്ട ഡൊമെയ്‌നോ ഉപയോഗ കേസനോ നൈപുണ്യം തീർച്ചയായും ആവശ്യമാണോ എന്നതിനെക്കുറിച്ച് അഭിപ്രായം പറയാൻ ഏജന്റ്സ് ടീമിനോട് പലപ്പോഴും ആവശ്യപ്പെടാറുണ്ട്. ആദ്യ തത്വങ്ങളിൽ നിന്ന് മാത്രം കൃത്യമായ ഒരു ഉത്തരം നമുക്ക് വളരെ അപൂർവ്വമായി മാത്രമേ ലഭിക്കാറുള്ളൂ. ഇത് ശരിക്കും കണ്ടെത്തുന്നതിനുള്ള ഒരേയൊരു മാർഗ്ഗം നൈപുണ്യം ഇല്ലാതെ നിങ്ങളുടെ ഏജന്റ് ഉപയോഗിച്ച് ആരംഭിക്കുക, നിരവധി ഹീറോ ക്വറികൾ പ്രവർത്തിപ്പിക്കുക, തുടർന്ന് ഏജന്റ് നല്ല ജോലി ചെയ്യുന്നുണ്ടോ എന്ന് കണ്ടെത്തുക എന്നതാണ്.

നിങ്ങൾക്ക് ഒരു നൈപുണ്യം ആവശ്യമുള്ളപ്പോൾ

പരിശീലനം ലഭിച്ച മോഡലുകൾക്കായി വിതരണത്തിലുള്ള നിരവധി ജോലികളുണ്ട്. നിങ്ങളുടെ പ്രോംപ്റ്റിലെ ഒരു വാക്യം ഉപയോഗിച്ച് നിങ്ങൾക്ക് കഴിയാത്ത ചില നിർദ്ദിഷ്ട രീതിയിൽ ആ പെരുമാറ്റം മാറ്റാൻ നിങ്ങൾ ആഗ്രഹിക്കുന്നുവെങ്കിൽ മാത്രമേ നിങ്ങൾ ഒരു നൈപുണ്യം പ്രയോഗിക്കേണ്ടതുള്ളൂ. അതിനാൽ, പ്രത്യേക സന്ദർഭമില്ലാതെ ഏജന്റിന് തെറ്റ് സംഭവിക്കുമെന്നിരിക്കെ, അല്ലെങ്കിൽ റണ്ണുകളിലുടനീളം നിങ്ങൾ തികച്ചും സ്ഥിരത പുലർത്തേണ്ട ചില പൊരുത്തക്കേടുകളോ നിശ്ചയമില്ലായ്മയോ ഉണ്ടെങ്കിൽ നിങ്ങൾക്ക് ഒരു നൈപുണ്യം ആവശ്യമാണ്.

നിങ്ങളുടെ അറിവ് ശാശ്വതമായിരിക്കാം എന്നാൽ പരിശീലന ഡാറ്റയിൽ ഇല്ലായിരിക്കാം. കട്ട്ഓഫുകളோ എന്റർപ്രൈസ് നിർദ്ദിഷ്ട വർക്ക്ഫ്ലോകളോ ഉണ്ടാകാം, അല്ലെങ്കിൽ ഇത് അഭിരുചിയുടെ കാര്യമായിരിക്കാം. ഉദാഹരണത്തിന്, Henry Modisett (ഞങ്ങളുടെ ഡിസൈൻ മേധാവി) എഴുതിയ ഡിസൈനുമായി ബന്ധപ്പെട്ട നിരവധി നൈപുണ്യങ്ങൾ Computer-ൽ ഞങ്ങൾക്കുണ്ട്. ആ നൈപുണ്യങ്ങളിൽ ഓരോ ടോക്കണും നിലനിൽക്കാനുള്ള കാരണം, വെബ്‌സൈറ്റുകളും പിഡിഎഫുകളും ഡിസൈൻ ചെയ്യുന്ന കാര്യത്തിൽ Henry-ക്ക് വളരെ നല്ല അഭിരുചിയുള്ളതുകൊണ്ടാണ്. ഏത് ഫോണ്ടുകളാണ് ഉപയോഗിക്കേണ്ടത്, ഏത് ഫോണ്ടുകളാണ് ഉപയോഗിക്കരുതാത്തത്, ആ ഫോണ്ടുകൾക്ക് എങ്ങനെ അനുഭവപ്പെടുന്നു എന്നത്, പരിശീലന ഡാറ്റയിൽ നിന്ന് മാത്രം മോഡലിന് പഠിക്കാൻ കഴിയാത്ത മറ്റ് വിധിനിർണ്ണയ കാര്യങ്ങൾ എന്നിവ Henry വ്യക്തമാക്കുന്നു.

നിങ്ങൾക്ക് ഒരു നൈപുണ്യം ആവശ്യമില്ലാത്തപ്പോൾ

ക്രമത്തിൽ നിർവ്വഹിക്കേണ്ട git കമാൻഡുകളുടെ ഒരു പരമ്പര എൻജിനീയർമാർ എഴുതിയിട്ടുള്ള നിരവധി നൈപുണ്യങ്ങൾ ഞങ്ങൾ കാണുന്നു. അത് ആവശ്യമില്ല കാരണം മോഡലിന് അത് എങ്ങനെ ചെയ്യണമെന്ന് ഇതിനകം അറിയാം, അതായത് ഇത് മികച്ച ഡോക്യുമെന്റേഷൻ ഉണ്ടാക്കുന്നു എന്നാൽ മോശമായ നൈപുണ്യം ഉണ്ടാക്കുന്നു.

സിസ്റ്റം പ്രോംപ്റ്റിൽ നിന്നുള്ള നിർദ്ദേശങ്ങൾ നൈപുണ്യങ്ങൾ ആവർത്തിക്കുന്ന ഉദാഹരണങ്ങൾ ഞങ്ങൾ കാണുന്നു. അതിനായി നിങ്ങൾക്ക് ഒരു നൈപുണ്യം ആവശ്യമില്ല. മിക്ക അഭ്യർത്ഥനകൾക്കും പ്രസക്തമായ അറിവ് ആഗോള സന്ദർഭത്തിൽ ഉൾപ്പെടുത്തണം, സോപാധികമായി ലോഡ് ചെയ്ത നൈപുണ്യത്തിലല്ല

നിങ്ങൾ നിലനിർത്താൻ കഴിയുന്നതിലും വേഗത്തിൽ മാറുന്ന എന്തെങ്കിലും ഉണ്ടെങ്കിൽ, നിങ്ങൾക്ക് ഒരു Skill ആവശ്യമില്ല. ഉദാഹരണത്തിന്, നിങ്ങൾ ഏതെങ്കിലും remote MCP endpoint-നെ ആശ്രയിച്ചാണ് പ്രവർത്തിക്കുന്നത്, അതിന്റെ tools അല്ലെങ്കിൽ ആ tools-ന്റെ versions പതിവായി മാറുന്നുവെങ്കിൽ, അവയെ Skill-ലേക്ക് ഉൾപ്പെടുത്തരുത്. അങ്ങനെ ചെയ്താൽ, നിങ്ങള്‍ക്ക് drift മാത്രമേ ഉണ്ടാകൂ, model പിഴവുകൾ വരുത്തും.

ഓരോ നൈപുണ്യവും ഒരു നികുതിയാണ്

നിങ്ങളുടെ നൈപുണ്യത്തിലെ ഓരോ വാക്യത്തിനും ബാധകമാക്കാൻ കഴിയുന്ന ഒരു ഉപയോഗപ്രദമായ പരിശോധന ഇതാ: “ഈ നിർദ്ദേശം കൂടാതെ ഏജന്റിന് ഇത് തെറ്റ് സംഭവിക്കുമോ?” ആ വാക്യം അവിടെ ഉണ്ടാകേണ്ടതില്ലെങ്കിൽ, എല്ലാവരും എല്ലാ തവണയും ഈ ചെലവ് നൽകുന്നതിനാൽ അവിടെ ഉണ്ടാകാൻ കഴിയില്ല. നിങ്ങൾ ഒരു നൈപുണ്യം ചേർക്കണമോ വേണ്ടയോ എന്ന് തീരുമാനിക്കുമ്പോൾ, ഓരോ സെഷനും ഓരോ ഉപയോക്താവും ടോക്കണുകൾക്ക് വില നൽകുന്ന ഈ നികുതി ഓർക്കുക.

ഫ്രഞ്ചിൽ കേൾക്കാൻ വളരെ മികച്ചതായ താഴെ പറയുന്ന പ്രശസ്തമായ ഉദ്ധരണി, ഏകദേശം വിവർത്തനം ചെയ്തിരിക്കുന്നത് “എനിക്ക് ഇത് ചെറുതാക്കാൻ സമയം ലഭിക്കാത്തതുകൊണ്ട് മാത്രമാണ് ഞാൻ ഈ കത്ത് നീളംകൂടിയതാക്കിയത്” എന്നാണ്.

« 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

Pascal-നെ പോലെ, ഓരോ നൈപുണ്യത്തിലും നിങ്ങൾ സമയം നിക്ഷേപിക്കണം. ഒരു ചെറിയ നൈപുണ്യം എഴുതുക എന്നത് പ്രയാസകരമാണ്. നിങ്ങളുടെ നൈപുണ്യം എഴുതാൻ എളുപ്പമാണെങ്കിൽ, അത് ഒരുപക്ഷേ വളരെ നീളമുള്ളതായിരിക്കാം അല്ലെങ്കിൽ നിലവിലുണ്ടായിരിക്കരുത്. ഒരു നല്ല നൈപുണ്യം എത്ര ചെറുതാക്കാൻ കഴിയുമോ അത്രയും ചെറുതാണ്.

നൈപുണ്യം സൃഷ്ടിക്കുന്നത് ഒറ്റയടിക്ക് ചെയ്യാൻ ശ്രമിക്കുകയും അഞ്ച് മിനിട്ടിനുള്ളിൽ PR-കൾ നൽകുകയും ചെയ്യുകയാണെങ്കിൽ, ഫലങ്ങൾ തീർച്ചയായും മോശമായിരിക്കും. വാസ്തവത്തിൽ, നൈപുണ്യം എഴുതാൻ LLM-കളാണ് ഉപയോഗിക്കുന്നതെങ്കിൽ LLM-ന് അതുകൊണ്ട് പ്രയോജനം ലഭിക്കില്ലെന്ന് ആദ്യകാല ഗവേഷണങ്ങൾ കാണിച്ചിട്ടുണ്ട്: “സ്വയം സൃഷ്ടിച്ച നൈപുണ്യങ്ങൾ ശരാശരി യാതൊരു പ്രയോജനവും നൽകുന്നില്ല, ഉപഭോഗം ചെയ്യുന്നതിലൂടെ പ്രയോജനം ലഭിക്കുന്ന പ്രൊസീജറൽ അറിവ് വിശ്വസനീയമായി രചിക്കാൻ മോഡലുകൾക്ക് കഴിയില്ലെന്ന് ഇത് കാണിക്കുന്നു.”

ഒരു നൈപുണ്യം എങ്ങനെ നിർമ്മിക്കാം

മറ്റൊരു രീതിയിൽ പറഞ്ഞാൽ, നിങ്ങൾ എഴുതുന്ന ഏതൊരു നൈപുണ്യത്തിലും നിങ്ങളുടെ അഭിപ്രായം ഉൾപ്പെടുത്തേണ്ടതുണ്ട്. ഈ ഘട്ടങ്ങൾ പാലിക്കുക.

ഘട്ടം 0: Evals എഴുതുക

ആദ്യം ചില evals എഴുതുക. നിങ്ങൾക്ക് ഇതിൽ നിന്ന് മൂല്യനിർണ്ണയ കേസുകൾ ഉറവിടമാക്കാം:

യഥാർത്ഥ ഉപയോക്തൃ ക്വറികൾ: പ്രൊഡക്ഷനിൽ നിന്നോ നിങ്ങളുടെ ബ്രെയിൻ ട്രസ്റ്റിൽ നിന്നോ ഉള്ള സാമ്പിൾ

അറിയപ്പെടുന്ന പരാജയങ്ങൾ: നൈപുണ്യം നിലവിലില്ലാത്തതിനാൽ ഏജന്റ് പരാജയപ്പെട്ടു

അയൽക്കാരന്റെ ആശയക്കുഴപ്പം: നിങ്ങളുടെ ഡൊമെയ്ൻ അതിർത്തിക്ക് സമീപം എന്നാൽ മറ്റൊരു നൈപുണ്യത്തിലേക്ക് റൂട്ട് ചെയ്യുന്നു

കുറഞ്ഞത് എങ്കിലും, ആവശ്യമായപ്പോൾ Skill load ചെയ്യപ്പെടുന്നുണ്ടോ എന്ന് നിങ്ങൾ testing നടത്തണം. ഐഡിയലായി, production environment-ൽ നിന്നുൾപ്പെടെ ചിലത് നിങ്ങൾ sample ചെയ്യണം. known error cases-ഉം പരിഗണിക്കാം: നിങ്ങൾ Skill എഴുതാൻ തീരുമാനിച്ച മുഴുവൻ കാരണം ഒരു പ്രത്യേക failure നിങ്ങൾ ശ്രദ്ധിച്ചതിനാലായിരിക്കാം, അല്ലെങ്കിൽ നിങ്ങൾ refactor ചെയ്യുന്നതിനിടയിൽ, ഒരു Skill-ൽ ഉൾപ്പെടുന്ന അടുത്ത ബന്ധമുള്ള രണ്ട് domains-ിൽ ചില confusion ഉണ്ടായിരിക്കാം.

സമാനമായ നെഗറ്റീവ്, പോസിറ്റീവ് ഉദാഹരണങ്ങളിൽ നിന്ന് ആരംഭിക്കുക. നെഗറ്റീവ് ഉദാഹരണങ്ങൾ വളരെ ശക്തവും പോസിറ്റീവ് ഉദാഹരണങ്ങളേക്കാൾ പ്രധാനവുമാകാം.

ഘട്ടം 1: വിവരണം

ഇതാണ് Skill-ലുള്ള ഏറ്റവും കഠിനമായ line. ഇത് ഒരു routing trigger ആണ്, documentation അല്ല. name-വും description-വും ശരിയാക്കാൻ, Skill-ന്റെ content നിങ്ങൾക്ക് പരിഗണിക്കേണ്ടതില്ല. നിങ്ങൾക്ക് പ്രസക്തി ഉള്ളത് Skill ശരിയായ points-ൽ load ചെയ്യപ്പെടുകയും inject ചെയ്യപ്പെടുകയും off-target side effects ഒന്നും ഇല്ലാതിരിക്കുകയും ചെയ്യുന്നുണ്ടോ എന്നതാണ്; ഇതാണ് number one failure mode. നിങ്ങൾ ഓരോ തവണ അധികം ഒരു Skill ചേർക്കുമ്പോഴും, എല്ലാ മറ്റുള്ള Skill-കളെയും അല്പം മോശമാക്കാനുള്ള അപകടം നിങ്ങൾ ഏറ്റെടുക്കുന്നു, അതിനാൽ regression പരമാവധി കുറയ്ക്കുന്നുണ്ടെന്ന് ഉറപ്പാക്കണം.

വീണ്ടും, മോശമായ ഒരു വിവരണം നൈപുണ്യം എന്ത് ചെയ്യുന്നു അല്ലെങ്കിൽ അത് എന്തിന് ഉപയോഗപ്രദമാണ് എന്ന് വിവരിക്കുന്നു. നല്ലൊരു വിവരണം ഏജന്റ് എപ്പോഴാണ് നൈപുണ്യം ലോഡ് ചെയ്യേണ്ടത് എന്ന് പറയുന്നു. ഉദാഹരണത്തിന്, പുൾ അഭ്യർത്ഥനകൾ നിരീക്ഷിക്കുന്നതിനായി നിങ്ങൾക്ക് എന്തെങ്കിലും ഉണ്ടെന്ന് കരുതുക. നൈപുണ്യം എന്ത് ചെയ്യുന്നു എന്ന് എഴുതരുത്. എൻജിനീയർമാർ തങ്ങളുടെ PR പ്രവർത്തിക്കുന്നു എന്ന് ഉറപ്പാക്കാൻ ആഗ്രഹിക്കുമ്പോൾ അവർ നിരാശരാകുമ്പോൾ പറയുന്ന കാര്യങ്ങൾ എഴുതുക, അതായത് “babysit” അല്ലെങ്കിൽ “watch CI” അല്ലെങ്കിൽ “make sure this lands.”

പെട്ടെന്നുള്ള ഒരു ചെക്ക്‌ലിസ്റ്റ് ഇതാ:

"Load when..." എന്ന് ആരംഭിക്കുന്നു

50 വാക്കുകളോ അതിൽ കുറവോ ലക്ഷ്യമിടുക

ഉപയോക്താവിന്റെ ഉദ്ദേശം വിവരിക്കുന്നു, ആദർശപരമായി യഥാർത്ഥ ക്വറികളിൽ നിന്ന്

വർക്ക്ഫ്ലോ സംഗ്രഹിക്കുന്നില്ല

യഥാർത്ഥ ക്വറികൾ നിങ്ങൾക്ക് 80-20-ൽ ഉൾക്കൊള്ളാൻ കഴിയുന്നവയാണ്. സാധാരണയായി, രണ്ടോ മൂന്നോ ഉദാഹരണങ്ങൾ നന്നായി പ്രവർത്തിക്കുന്നു. നിങ്ങൾക്ക് ആവശ്യമുള്ളത് കൃത്യമായും മാത്രമായും ചേർക്കുന്നത് എളുപ്പമല്ല.

ഘട്ടം 2: ബോഡി എഴുതുക

അടുത്തതായി, നൈപുണ്യത്തിന്റെ ഉള്ളടക്കം തന്നെ എഴുതുക. ഇത് ഘട്ടം 0 അല്ലെങ്കിൽ ഘട്ടം 1 അല്ല എന്നത് ശ്രദ്ധിക്കുക.

ഒരു സഹപ്രവർത്തകനോടോ അല്ലെങ്കിൽ നിങ്ങളുടെ റൺടൈം സിസ്റ്റത്തോടോ വർക്ക്ഫ്ലോകൾ ആശയവിനിമയം നടത്തുന്നതിൽ നിന്ന് തികച്ചും വ്യത്യസ്തമാണ് ഒരു LLM-ലേക്ക് വർക്ക്ഫ്ലോകൾ ആശയവിനിമയം നടത്തുന്നത്. ഒരു പുതിയ സോഫ്റ്റ്‌വെയർ ഉപകരണം പഠിക്കുമ്പോൾ, ഒരു എൻജിനീയർക്ക് ഡോക്യുമെന്റേഷൻ വായിക്കേണ്ടി വന്നേക്കാം, പരിചയമുള്ളവരിൽ നിന്ന് ഒരു വാക്ക്ത്രൂ ലഭിക്കുകയും ഉപകരണം എങ്ങനെ ഉപയോഗിക്കാമെന്ന് പഠിക്കുകയും ചെയ്യാം. അതേസമയം, കുറഞ്ഞത് ഒരു വർഷമായി നിലവിലുള്ള മിക്കവാറും ഏത് സോഫ്റ്റ്‌വെയർ ഉപകരണത്തിനും, നിങ്ങൾ അതിന്റെ പേര് സൂചിപ്പിച്ചാൽ മതിയാകും കൂടാതെ LLM-ന് ആവശ്യമായ എല്ലാ വിവരങ്ങളും ഉണ്ട്.

നിങ്ങൾ ബോഡി എഴുതുമ്പോൾ, വ്യക്തമായ കാര്യങ്ങൾ ഒഴിവാക്കുക. പല എൻജിനീയർമാർക്കും ആരെങ്കിലും പ്രവർത്തിപ്പിക്കേണ്ട ഓരോ കമാൻഡും ലിസ്റ്റ് ചെയ്യുന്ന readme.md ഫയലുകൾ എഴുതാൻ ധാരാളം അനുഭവമുണ്ട്. നിങ്ങൾ ഒരു നൈപുണ്യം എഴുതുമ്പോൾ അതിലേക്ക് വീഴുന്നത് എളുപ്പമാണ് കാരണം നിങ്ങൾ ഡോക്യുമെന്റേഷൻ എഴുതുന്നത് പോലെ തോന്നുന്നു, പക്ഷേ നിങ്ങൾ അങ്ങനെ ചെയ്യുകയാണെങ്കിൽ, നിങ്ങളുടെ നൈപുണ്യം ചവറ്റുകുട്ടയായിരിക്കും. അതിനാൽ, കമാൻഡുകളുടെ ഒരു പരമ്പര എഴുതരുത്.

ഉദാഹരണത്തിന്, നിങ്ങൾ എഴുതേണ്ടതില്ല, “git log # find the commit; git checkout main; git checkout -b <clean-branch>; git cherry-pick <commit>;”

പകരം, എഴുതുക, “ഒരു ക്ലീൻ ബ്രാഞ്ചിലേക്ക് കമ്മിറ്റ് ചെറി-പിക്ക് ചെയ്യുക. ഉദ്ദേശം സംരക്ഷിച്ച് വൈരുദ്ധ്യങ്ങൾ പരിഹരിക്കുക. ഇത് വ്യക്തമായി എത്തിച്ചേരാൻ കഴിയുന്നില്ലെങ്കിൽ, കാരണം വിശദീകരിക്കുക.”

മുൻപത്തെ അമിതമായി നിർദ്ദേശിക്കുന്ന കമാൻഡുകളുടെ പരമ്പരയേക്കാൾ മോഡൽ രണ്ടാമത്തേത് ഉപയോഗിച്ച് വളരെ മികച്ച ജോലി ചെയ്യും, പ്രത്യേകിച്ച് കാര്യങ്ങൾ തെറ്റാകുമ്പോൾ. റെയിൽറോഡ് ചെയ്യരുത്, അല്ലെങ്കിൽ അമിതമായി നിർദ്ദേശിക്കരുത്, അത് ദുർബലമാണ്, പകരം ഒന്നിലധികം സമീപനങ്ങൾക്ക് പ്രവർത്തിക്കാൻ കഴിയുന്നിടത്ത് വഴക്കമുള്ളതായിരിക്കുക. വീണ്ടും, മനുഷ്യർക്കുള്ള നല്ല ഡോക്യുമെന്റേഷൻ മിക്കപ്പോഴും മോഡലുകൾക്ക് മോശമായ ഡോക്യുമെന്റേഷനാണ്.

അടുത്തതായി, പ്രശ്നങ്ങളിൽ (gotchas) അല്ലെങ്കിൽ നെഗറ്റീവ് ഉദാഹരണങ്ങളിൽ ശ്രദ്ധ കേന്ദ്രീകരിക്കുക. എന്താണ് ചെയ്യാൻ പാടല്ലാത്തത് എന്ന കാര്യത്തിൽ അവ പലപ്പോഴും മോഡലിനെ നയിക്കുന്നതിനാൽ ഇവ വളരെ ഉയർന്ന സിഗ്നലുള്ള ഉള്ളടക്കമാണ്. ഏജന്റ് തടസ്സപ്പെടുമ്പോഴെല്ലാം നിങ്ങൾ ഒരു വരി ചേർക്കുകയാണെങ്കിൽ, നിങ്ങൾ അത് പ്രവർത്തിപ്പിച്ച് പഠിക്കും കൂടാതെ പ്രശ്നങ്ങൾ സ്വാഭാവികമായി വളരും.

അവസാനമായി, ഏതെങ്കിലും ഭാഗം സോപാധികമോ ഉള്ളടക്കത്തിൽ വളരെ ഭാരമുള്ളതോ ആണെങ്കിൽ, ഹബ്ബായ SKILL.md-ൽ നിന്ന് അത് എടുത്തുമാറ്റി സ്പോക്കുകളിൽ ഒന്നിൽ ഇടുക. പുരോഗമനപരമായി ലോഡ് ചെയ്യാൻ കഴിയുന്ന ഒരു ആക്സസറി ഫയലിൽ ഇത് ഇടുക, അതിലേക്ക് ഞങ്ങൾ അടുത്തതായി കടക്കും.

ഘട്ടം 3: ശ്രേണി ഉപയോഗിക്കുക

നിങ്ങൾക്ക് ഒരു സ്ക്രിപ്റ്റോ റഫറൻസോ ഉള്ളപ്പോഴോ അല്ലെങ്കിൽ ചില നിർദ്ദിഷ്ട ഉപകരണം ഉപയോഗിക്കുമ്പോഴോ നൈപുണ്യം ശ്രേണി പ്രയോജനപ്പെടുത്തുക:

ഒരു Skill-ത്തിനുള്ളിൽ scripts, references, assets, configuration എന്നിവയ്ക്കുള്ള നിർദേശിത ഉപയോഗങ്ങൾ.

main Skill-ൽ നിന്ന് conditional അല്ലെങ്കിൽ branching ആയിരിക്കുന്ന ഏതൊന്നിനും, അത് ഒരു folder-ലേക്ക് വേർതിരിക്കുക. കൂടാതെ, multilevel hierarchy പ്രത്യേകിച്ച് intricate ആയ Skills-നായി ഉപയോഗിക്കാമെന്നും ഓർക്കുക. ഇവയ്ക്കായി, functionality monolithically നടപ്പിലാക്കണോ, അതോ Skills-ന്റെ ഒരു collection ആക്കണോ (ഒരുപക്ഷേ depends: അധിഷ്ഠിത loading relationships-ോടെ) എന്നതിനെക്കുറിച്ച് സൂക്ഷ്മമായി ആലോചിക്കേണ്ടതുണ്ട്.

ഘട്ടം 4: ആവർത്തിക്കുക

അടുത്തതായി, ഒരു ബ്രാഞ്ചിൽ നിരവധി ആവർത്തനങ്ങൾ ചെയ്യുക. നൈപുണ്യം ഇല്ലാതെ പ്രധാന ബ്രാഞ്ചിൽ ആരംഭിക്കുക, ചില ആവർത്തനങ്ങൾ ചെയ്യുക, നിങ്ങളുടെ ഹീറോ ക്വറി സെറ്റ് നിർമ്മിക്കുക, ഒരു കൂട്ടം evals പ്രവർത്തിപ്പിക്കുക. മൂല്യനിർണ്ണയ സെറ്റ് പൂർത്തിയായ ഒരൊറ്റ മാറ്റം സമർപ്പിച്ചതിന് നിങ്ങളുടെ നൈപുണ്യം കോഡ് അവലോകനം ചെയ്യുന്ന ആരും നിങ്ങളോട് നന്ദി പറയും. തുടർച്ചയായ വർദ്ധിച്ചുവരുന്ന മാറ്റങ്ങൾ (ഒരു പുതിയ പ്രശ്നം ഒഴികെ) അവലോകനം ചെയ്യുന്നത് വളരെ ബുദ്ധിമുട്ടാണ്, അതിനാൽ അത് കുറയ്ക്കാൻ ശ്രമിക്കുക.

നിങ്ങൾ നിരവധി ചെറിയ വാക്ക് മാറ്റങ്ങൾ വരുത്തിയേക്കാം. വിവരണങ്ങളിലെ ചെറിയ വാക്ക് മാറ്റങ്ങൾക്ക് റൂട്ടിംഗിൽ വലിയ സ്വാധീനം ചെലുത്താൻ കഴിയും (മറ്റ് നൈപുണ്യങ്ങളിൽ സ്പിൽഓവർ ഇഫക്റ്റുകൾ ഉൾപ്പെടെ), അതിനാൽ ഘട്ടം 5-ന് മുമ്പ് ആ ജോലികളെല്ലാം ചെയ്യുക.

ഘട്ടം 5: ഷിപ്പ് ചെയ്യുക

അത് ഷിപ്പ് ചെയ്യുക.

ഒരു നൈപുണ്യം എങ്ങനെ പരിപാലിക്കാം

നിങ്ങൾ ഒരു നൈപുണ്യം എഴുതിക്കഴിഞ്ഞ സ്ഥിതിക്ക്, നിങ്ങൾ അത് പരിപാലിക്കേണ്ടതുണ്ട്.

ഗോച്ചാസ് ഫ്ലൈവീൽ

ഈ ഘട്ടം മുതൽ, നിങ്ങളുടെ gotchas ലിസ്റ്റ് വളരുകയോ വളരെയധികം മാറുകയോ ചെയ്യാൻ തുടങ്ങും. ഉദാഹരണത്തിന്, ഞങ്ങൾ പലപ്പോഴും un-evaled ആയ PRs ചെയ്യുന്ന എഞ്ചിനീയർമാർ description മാറ്റുന്നതായി കാണുന്നു. നിങ്ങളുടെ Skill merge ചെയ്തതിന് ശേഷം നിങ്ങൾ description മാറ്റുകയാണെങ്കിൽ, നിങ്ങൾ തെറ്റായ ദിശയിലാണ്. നിങ്ങളുടെ Skill-ലേക്ക് route ചെയ്യണമോ എന്നത് തീരുമാനിക്കുന്ന കാര്യത്തിൽ നിങ്ങൾ മാറ്റങ്ങൾ വരുത്തുകയാണെങ്കിൽ, ആ മാറ്റങ്ങളെ പിന്തുണയ്ക്കുന്ന ചില evals എഴുതേണ്ടതുണ്ട്.

നൈപുണ്യങ്ങൾ അപ്പെൻഡ്-മോസ്റ്റ് ആണ്. പ്രശ്നങ്ങളുടെ വിഭാഗമാണ് കാലക്രമേണ ഏറ്റവും കൂടുതൽ മൂല്യം ശേഖരിക്കുന്നത്:

ഏജന്റ് എന്തെങ്കിലും പരാജയപ്പെടുന്നു → ഒരു പ്രശ്നം (gotcha) ചേർക്കുക

ഏജന്റ് നൈപുണ്യം തെറ്റായ ലക്ഷ്യത്തിൽ ലോഡ് ചെയ്യുന്നു → വിവരണം കർശനമാക്കുക, നെഗറ്റീവ് evals ചേർക്കുക

ആവശ്യപ്പെടുമ്പോൾ ഏജന്റ് നൈപുണ്യം ലോഡ് ചെയ്യുന്നില്ല → കീവേഡുകളും പോസിറ്റീവ് evals-ഉം ചേർക്കുക

സിസ്റ്റം പ്രോംപ്റ്റ് മാറ്റങ്ങൾ → തർക്കമോ ആവർത്തനമോ പരിശോധിക്കുക

ആന്തരിക പരിശോധനയിലോ പ്രൊഡക്ഷനിലോ ഒരൊറ്റ പരാജയ കേസ് ശ്രദ്ധിക്കുകയും ഒരു പ്രശ്നം (gotcha) ചേർക്കുകയും ചെയ്യുന്നത് എളുപ്പമാണ്. ഇതൊരു നെഗറ്റീവ് ഉദാഹരണമാണ്, അതിനാൽ ഇത് വ്യക്തമായ മാർഗ്ഗനിർദ്ദേശം യഥാർത്ഥത്തിൽ മാറ്റുന്നില്ല, പക്ഷേ ഇത് മോഡലിനെ അറിയിക്കുന്നു, “ഹേയ്, അറിയപ്പെടുന്ന ഈ പരാജയമുണ്ട്.”

80-20-ൽ നിന്ന് 99.9% അല്ലെങ്കിൽ 99.99% വിജയ നിരക്കിലേക്ക് നിങ്ങൾ നീങ്ങുമ്പോൾ, ഈ പ്രശ്നങ്ങളുടെ ലിസ്റ്റ് വളർത്തുന്നത് എളുപ്പമാണ്. ഈ നെഗറ്റീവ് ഉദാഹരണങ്ങൾ കാണുമ്പോൾ, നിങ്ങൾ പ്രശ്നങ്ങളുടെ വിഭാഗത്തിലേക്ക് കൂടുതലായി അപ്പെൻഡ് ചെയ്യണം. നിങ്ങൾ ദൈർഘ്യമേറിയ നിർദ്ദേശങ്ങൾ ചേർക്കുകയോ വിവരണം മാറ്റുകയോ ചെയ്യരുത്.

Eval സ്യൂട്ടുകൾ

Perplexity-യിൽ, ഞങ്ങൾ വിവിധ കാര്യങ്ങൾ പരിശോധിക്കുന്നതിനായി നിരവധി eval സ്യൂട്ടുകൾ പ്രവർത്തിപ്പിക്കുന്നു. നൈപുണ്യം ലോഡിംഗും നൈപുണ്യം ഫയൽ റീഡുകളും ഉണ്ട്, ഇത് നൈപുണ്യം ലോഡിംഗിന്റെ കൃത്യത, വീണ്ടെടുക്കൽ, നിരോധിച്ച പരിശോധനകൾ എന്നിവ പരിശോധിക്കുന്നു. ഏജന്റ് ഉദ്ദേശിക്കുമ്പോൾ നിങ്ങളുടെ നൈപുണ്യം റൂട്ട് ചെയ്യുമോ? പുതിയ നൈപുണ്യങ്ങൾ നിലവിലുള്ള അതിരുകൾ തകർക്കുന്നില്ലെന്ന് ഇവ ഉറപ്പാക്കുന്നു.

ശരിയായ പുരോഗമനപരമായ ലോഡിംഗ് പരിശോധിക്കാൻ കഴിയുന്ന evals-ഉം ഉണ്ട്. ഏജന്റ് നൈപുണ്യം ലോഡ് ചെയ്തേക്കാം, പക്ഷേ അത് ആക്സസറി ഫയലോ ഫയലുകളോ വായിക്കുന്നുണ്ടോ? ഉദാഹരണത്തിന്, ഫിനാൻസ് ക്വറികൾക്കായി നിങ്ങൾക്ക് ഒരു ഫിനാൻസ് നൈപുണ്യം ഉണ്ടെങ്കിൽ, അത് പ്രത്യേക FORMATTING.md ഫയൽ വായിക്കുന്നുണ്ടോ?

ഡൊമെയ്‌നുകൾക്കുള്ളിൽ എൻഡ്-ടു-എൻഡ് ടാസ്ക് പൂർത്തിയാക്കുന്നത് പരിശോധിക്കുന്ന നൈപുണ്യങ്ങൾക്കായുള്ള evals-ഉം ഉണ്ട്. ഞങ്ങൾ മുഴുവൻ ഏജന്റ് ലൂപ്പും പ്രവർത്തിപ്പിക്കുകയും നന്നായി നിർവചിക്കപ്പെട്ട മാനദണ്ഡങ്ങളുടെ ഒരു റുബ്രിക്കിന്റെ അടിസ്ഥാനത്തിൽ ഫലങ്ങൾ ഗ്രേഡ് ചെയ്യാൻ ഒരു LLM ജഡ്ജിയെ ഉപയോഗിക്കുകയും ചെയ്യുന്നു.

അവസാനമായി, വ്യത്യസ്ത മോഡലുകൾക്കെതിരെ ഈ evals പ്രവർത്തിപ്പിക്കേണ്ടത് പ്രധാനമാണ്. Computer കുറഞ്ഞത് മൂന്ന് വ്യത്യസ്ത ഓർക്കസ്ട്രേഷൻ മോഡൽ കുടുംബങ്ങളെ പിന്തുണയ്ക്കുന്നു: GPT, Claude Opus, Claude Sonnet. വ്യത്യസ്ത പെരുമാറ്റം ലഭിക്കുന്നില്ലെന്ന് ഉറപ്പാക്കാൻ നിങ്ങളുടെ നൈപുണ്യം ലോഡിംഗും ഡൊമെയ്ൻ നൈപുണ്യങ്ങളും ഈ വ്യത്യസ്ത ഏജന്റ് ഓർക്കസ്ട്രേറ്ററുകൾക്കെതിരെ പ്രവർത്തിപ്പിക്കാൻ നിങ്ങൾ ആഗ്രഹിക്കുന്നു. നൈപുണ്യങ്ങളുടെ കാര്യത്തിൽ Sonnet-ഉം GPT-യും തികച്ചും വ്യത്യസ്തമായാണ് പെരുമാറുന്നത്.

അവസാന ചിന്തകളും പ്രധാന പാഠങ്ങളും

നിങ്ങൾ എത്രയധികം നൈപുണ്യങ്ങൾ നിർമ്മിക്കുന്നുവോ, അത്രയധികം അവ നിർമ്മിക്കുന്നതിൽ നിങ്ങൾ വിദഗ്ദ്ധനാകും. നൈപുണ്യങ്ങൾ ഉപയോഗിച്ച് ദിവസേന നിങ്ങൾ ചെയ്യുന്ന ജോലികൾ കൂടുതൽ പുനരുൽപ്പാദിപ്പിക്കാവുന്നതാക്കാൻ നിങ്ങൾ ഓട്ടോമേറ്റ് ചെയ്യുകയോ ശ്രമിക്കുകയോ ചെയ്യുന്നില്ലെങ്കിൽ, ഉടൻ തന്നെ ആരംഭിക്കുക.

നൈപുണ്യങ്ങൾ നിർമ്മിക്കുന്ന പ്രവൃത്തി കൂടുതൽ നൈപുണ്യങ്ങൾ നിർമ്മിക്കുന്നതിൽ നിങ്ങളെ മികച്ചനാക്കുന്നു, കൂടാതെ ബിസിനസ്സ് പ്രക്രിയകൾ ഓട്ടോമേറ്റ് ചെയ്യുന്നതിൽ അവ വളരെ മികച്ചതാണ്. നിങ്ങളുടെ സ്റ്റാൻഡ്അപ്പിന് മുമ്പ്, ഓരോ സ്പ്രിന്റിന്റെയും അവസാനം, അല്ലെങ്കിൽ ഒരു എൻജിനീയർ എന്ന നിലയിൽ നിങ്ങൾ ദിവസേനയോ ആഴ്ചതോറോ അല്ലെങ്കിൽ ത്രൈമാസത്തിലോ ചെയ്യുന്ന ഏതെങ്കിലും കാര്യങ്ങൾ നിങ്ങൾക്ക് വിവരിക്കാൻ കഴിയുമെങ്കിൽ, നിങ്ങളുടെ സമയം തിരികെ വാങ്ങാൻ നിങ്ങൾ ഒരു നൈപുണ്യം എഴുതണം.

പോസ്റ്റ്‌മോർട്ടങ്ങൾ ഓട്ടോമേറ്റ് ചെയ്യാൻ നിങ്ങൾക്ക് കഴിയുമോ? പുൾ അഭ്യർത്ഥനകൾ അവലോകനം ചെയ്യാൻ നിങ്ങൾക്ക് കഴിയുമോ? നിങ്ങൾക്ക് ചെയ്യാൻ കഴിയുന്ന ഏത് ടാസ്കും, ആദ്യ പാസ് ഒരു ഏജന്റ് നൈപുണ്യം ആയിരിക്കാൻ നിങ്ങൾക്ക് കഴിയും. ഇത് നിങ്ങൾക്ക് വലിയ സമയം ലാഭിച്ചു തരും.

അതുകൊണ്ട്, ഒരു നൈപുണ്യം എളുപ്പമുള്ളതോ എല്ലായ്പ്പോഴും ആവശ്യമുള്ളതോ അല്ലെന്ന് ഓർക്കുക. കുറഞ്ഞതാണ് കൂടുതൽ. മറ്റ് ചില പ്രധാന പാഠങ്ങൾ:

നൈപുണ്യത്തിന് മുമ്പ് evals എഴുതുക. അനുബന്ധമായ എന്നാൽ വ്യത്യസ്തമായ നൈപുണ്യങ്ങൾക്കായി നെഗറ്റീവ് ഉദാഹരണങ്ങളും നിരോധിച്ച ലോഡുകളും ഉൾപ്പെടുത്തുക.

വിവരണമാണ് കഠിനമായ ഭാഗം. "Load when..." (ഓരോ വാക്കിനും ശ്രദ്ധ ആവശ്യമാണ്).

പ്രശ്നങ്ങൾ (gotchas) വളരെ ഉയർന്ന മൂല്യമുള്ള ഉള്ളടക്കമാണ്. ചെറുതായി ആരംഭിക്കുക, ഏജന്റ് പരാജയപ്പെടുമ്പോൾ വളർത്തുക.

പുതിയ നൈപുണ്യം ചേർക്കുന്നതിലൂടെ മുമ്പേയുള്ള മറ്റ് നൈപുണ്യങ്ങൾ തകർക്കുന്നത് എളുപ്പമാണെന്ന് ഓർക്കുക, നിങ്ങൾ അത് തൊട്ടിട്ടില്ലെങ്കിൽ പോലും (വിദൂരത്തുള്ള പ്രവർത്തനം ശ്രദ്ധിക്കുക).

നിങ്ങൾ ഒരു നൈപുണ്യം എഴുതുമ്പോഴും പരിപാലിക്കുമ്പോഴും ലഭ്യമായ എല്ലാ ഉപകരണങ്ങളും ഓരോ തവണയും ഉപയോഗിക്കുക. നിങ്ങൾക്ക് കൂടുതൽ അറിയണമെങ്കിൽ, ഏജന്റ് നൈപുണ്യങ്ങളുടെ വെബ്‌സൈറ്റിൽ ധാരാളം നല്ല ഉദാഹരണങ്ങളുണ്ട്, കൂടാതെ ഞങ്ങളുടെ ആന്തരിക റിപ്പോസിറ്ററിയും പൊതു ആവാസവ്യവസ്ഥയും നന്നായി രൂപകൽപ്പന ചെയ്ത നൈപുണ്യങ്ങളുടെ നിരവധി ഉദാഹരണങ്ങൾ ഉൾക്കൊള്ളുന്നു.

ഉദ്ധരണി

@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}
}