Hönnun, endurbætur og viðhald umboðs-skills hjá Perplexity

Vörur fyrir landamæraumsjónarmið Perplexity byggja á grunni þekkingar og sérfræðiþekkingar sem pakkað er inn í einingaskiptar Agent Skills. Við höldum úti vandlega völdu safni af Skills í okkar tæknilegu umhverfi. Þessi Skills innihalda mörg almennra tækja sem knýja Perplexity Computer; sértækni í fögum eins og fjármálum, lögfræði og heilbrigðismálum; og gífurlegt magn eininga til að mæta þörfum notenda. Sum Skills eru sjaldan kölluð til en eru mikilvæg þegar þau eru kölluð til. Til að tryggja stöðugt frábæra notendaupplifun setur umboðsteymi Perplexity gæði Skills í jafnhátt sæti og kóðagæði.

Innsæi og bestu starfsvenjur sem þarf til að þróa hágæða Skill eru verulega frábrugðnar því sem þarf til að smíða hefðbundinn hugbúnað. Teymi umboðsmanna fer yfir margar pull request frá frábærum verkfræðingum sem þróa Skills í starfi sínu. Útkoman eru nánast alltaf fjölmargar athugasemdir og tillögur að endurskoðun. Þetta er vegna þess að mörg gagnleg mynstur við skrif á kóða verða andmynstur við gerð Skill.

Til dæmis, ef þið takið nokkrar afspekingar úr PEP20 – The Zen of Python, verður það fljótt ljóst að það er ólíkt því að skrifa góð Skills að skrifa góðan Python kóða. Af þessum 20 línum af visku eru að minnsta kosti helmingurinn algjörlega rangar eða virkilega villandi þegar verið er að skrifa Skills. Hér eru fimm af þeim:

Fimm andstæður milli Zen Python og leiðbeininganna í greininni um að skrifa Skills.

Þessi handbók er skjalið sem verkfræðingar hjá Perplexity nota þegar þeir þróa og fara yfir Skills. Við erum einnig að gefa þessa handbók út opinberlega svo uppgötvanir okkar og lærdómur geti nýst breiðara samfélagi. Hvort sem þst ert verkfræðingur sem hönnun framleiðslu Skills í daglegu starfi, Computer notandi sem leitar að því að þróa þitt eigið Skill á því sviði sem þú þekkir best, eða hvort tveggja, þá er þessi handbók fyrir þig.

Hvað er Skill?

Þegar þú skrifar Skill ertu ekki að skrifa venjulegan gamlan hugbúnað (jafnvel þótt Skills séu nú hluti af helstu rökfræðivélinni fyrir umboðskerfi). Frekar ertu að byggja upp samhengi fyrir líkön og umhverfi þeirra. Skill hefur aðrar takmarkanir og aðrar hönnunarreglur. Ef þú skrifar Skill eins og þú gerir kóða, þá munt þú mistakast.

Skill er að minnsta kosti fjórir hlutir, sérstaklega í samhengi við hvernig við byggjum þá hjá Perplexity.

Skill er mappa

Skill er ekki bara ein SKILL.md skrá. Í mörgum tilfellum inniheldur Skill nokkrar skrár. Undir möppunni sem er nefnd eftir þínu Skill gætirðu verið með:

SKILL.md: forsíða og leiðbeiningar

scripts/: kóði sem umboðsmaðurinn keyrir, enduruppgötvar ekki

references/: þung sköl, hlaðin skilyrðisbundið

assets/: sniðmát, skema og gögn

config.json: uppsetning notanda við fyrstu keyrslu

Þetta miðju- og geiramynstur gerir þér kleift að halda Skills mjög einbeittum og þéttum, og maður getur notað möppuskipulagið á mjög skapandi hátt. Stundum njóta sérstaklega flókin Skills góðs af mörgum stigveldishæðum til að hjálpa líkaninu að sigla betur. Segjum að Skill krefjist þekkingar yfir 300 efnisþætti, sem hægt er að flokka í 20 efnissvæði. Að velja rétt efni áreiðanlega á milli 300 er óleyst áskorun jafnvel fyrir bestu landamæralíkön dagsins í dag. Það er mun auðveldara valvandamál fyrir líkan að þrengja að einu af 20 svæðum, heldur en á milli 15 efnisþátta innan þess svæðis.

Sem eitt dæmi um hvernig stigveldi á mörgum stigum veitir gildi, notaði teymi okkar þrjú stig af efnislegri hreiðrun innan þess Skills sem knýr tekjuskattsmöguleika Computer í Bandaríkjunum á þessu skattatímabili. Þetta stigveldi var algjörlega ómissandi miðað við flókið eðli skattalaga: í fyrstu prófunum okkar leiddi það til lakari árangurs en að hlaða ekki Skillinu yfirleitt að kynna líkaninu eina möppu sem innihélt alla 1.945 hluta bandarísku skattalöggjafarinnar (U.S. Internal Revenue Code). Að skipuleggja upplýsingarnar í rökrétt undirsvæði var ómissandi til að tryggja hárnákvæmar lestraraðgerðir.

Samt sem áður kom þetta stigveldi ekki ókeypis. Vaxandi stigveldisstig krefjast vaxandi stjórnunar á upplýsingaarkitektúr til að stjórna tilheyrandi óbeinum aðgerðum. Við bjuggum til fljótlegar uppflettihandbækur, sérsniðin leitartæki og önnur verkfæri til að styðja líkanið við að finna upplýsingar með lágmarks óbeinum aðgerðum. Í þessu tilviki skilaði það að vinna erfiðu vinnuna við stjórnun að lokum jákvæðum endanlegum árangri: Skill sem gerði líkönum kleift að framkvæma skattatengd verkefni mun færari en með því að nota almenn verkfæri ein sér.

Stækka

Skill er snið

Skill er snið. Kjarnarótarskráin SKILL.md verður að hafa bæði nafn og lýsingu. Ennfremur þarf Skill að passa nákvæmlega við möppunafnið þar sem Skill er staðsett. Nafnið verður að vera með öllum lágstöfum, hafa eng bil og getur notast við bandstrik. Lýsingin er leiðarljósið fyrir beiningu. Þetta er algæfur bilunarstaður: lýsingin er ekki innri skjölun um hvað Skill gerir. Hún jafngildir leiðbeiningum fyrir líkanið um hvenær eigi að hlaða Skillinu. Svo þú munt oft sjá „Load when,“ ekki „This Skill does.“ Þetta er mikilvægt vegna þess hvernig flestar útfærslur sprauta lýsingunni inn í samhengi líkansins.

Innan í frontmatterinu er einnig „depends:“, sem gerir þér kleift að búa til stigskiptar Skill-fylgni, og „metadata:“, sem er notað fyrir umsagnir og mat. Mismunandi gervigreindarfulltrúakerfi geta jafnvel skilgreint eigin frontmatter-reiti sem eru notaðir á þeim kerfissértæka hátt. Sem valkost er hægt að pakka Skill-sértækum lýsigögnum í fylgiskjals-JSON- eða YAML-stillingarskrá. Þetta er æskilegt þegar verið er að byggja gervigreindarfulltrúakerfi sem þurfa að auðvelda mismunandi gerðir af keyrsluhegðun fyrir hvern Skill án þess að menga samhengi líkansins með smáatriðum. Að lokum er hægt að ná fram svipaðri hegðun með því að fjarlægja Skill-frontmatter við lestur. Computer notar þessa aðferð, sem gerir kleift að varðveita stillingar í rótar-skránni SKILL.md. Gæta þarf mikillar nákvæmni í þáttunarlogíkinni, og hugsanlegt er að innleiða skilyrta fjarlægingu ef til eru ákveðnir reitir sem gagnlegt er að hafa innan samhengis líkansins.

Skill er hægt að kalla til

Skill er hægt að kalla til. Umboðsmaðurinn hleður inn Skill við keyrslu. Mikilvægt er að Skills eru ekki alltaf bönduð inn í samhengið. Sjálfgefið er að flest umboðskerfi fella út Skills stigvikið eftir sérstakum þörfum.

Það eru að minnsta kosti þrjú þrep samhengiskostnaðar í því hvernig við höfum útfært Skills í Computer. Hér er ferlið:

Computer kallar á load_skill(name="...")

Computer afritar möppu Skill yfir í einangraða sandkassa keyrslunnar

Computer hleður sjálfkrafa og endurkvæmt inn háðum í „depends:“ taginu

Computer fjarlægir síðan forsíðuna og umboðsmaðurinn sér því aðeins meginmálið og viðbótarskrárnar

Mismunandi umboðskerfi geta valið að birta efni Skill á mismunandi vegu. Sem dæmi gætu sum kerfi valið að birta ekki skráarstigveldið yfir allt, og skilið það eftir fyrir líkanið að uppgötva stigveldið með skráarkerfisaðgerðum. Önnur kerfi gætu valið að gefa líkaninu kortlagningu á öllu skráartrénu upp að ákveðinni stýfingu og/eða dýptarmörkum. Til að halda samhengi hreinu sleppir Computer fullu skráarstigveldi úr kalli samhengisins; Hins vegar er hægt að hnekkja þessu á grundvelli hvers Skill fyrir sig.

Skill er stigvaxandi

Skills eru stigvaxandi. Í Computer eru þrjú mismunandi þrep samhengiskostnaðar, og við tökum á okkur öll þrjú á ýmsum stigum:

Þrjú stig Skill-samhengis: vísir, fullt Skill-hleðsluferli og tilvísunarskrár við keyrslu.

Computer byggir upp vísitölu Skill sem hefur nafnið og lýsinguna fyrir hvert tiltækt Skill. Fjárhagsáætlun fyrir þetta er í kringum 100 tákn á hvert Skill (styttra er jafnvel betra). Þetta er svona þétt vegna þess að þú ert að greiða þennan kostnað í hverju samtali, fyrir hvern notanda. Þessu er sprautað inn í kerfisboðsklofa alveg í upphafi samtalsins. Líkanið hefur aðgang að hópi nefndra Skills og lýsinga þannig að það getur ákveðið hvort það eigi að kalla á „load_skill()“. Þröskuldurinn til að komast inn í þessa vísitölu er ákaflega hár. Þitt Skill þarf að vera mjög gagnlegt og lýsingin þarf að vera afar þétt og hnitmiðuð vegna þess að allir eru að greiða kostnaðinn allan tímann.

Eftir að umboðskerfið hleður inn Skill er fullt SKILL.md meginmál. Helst ætti meginmálstextinn ekki að fara yfir 5.000 tákn. Jafnvel þá vilt þú að hver setning skipti máli því þegar þú hleður inn Skill þarf afgangurinn af samtalinu að greiða það þar til þú nærð samþjöppunarmörkum. Margir þræðir hlaða inn hvar sem er á milli þriggja og fimm mismunandi Skills, sem margfaldar þennan kostnað. Skills með fullt af óþarfa munu nánast örugglega rýra önnur Skills sem og heildargetu umboðsins. Í stuttu máli, ef þitt Skill hleðst inn og það gerir ekki það rétta, þá er það sóun á samhengi.

Lokastig þróunarinnar eru skrár eða sérstök tilvik, eins og undirskills eða snið. Þetta er þar sem þú vilt setja ótakmarkaða skilyrðisbundna greiningarrökfræði. Umboðsmaðurinn mun aðeins nota það þegar þess þarf, sem þýðir að það er mun lægri þröskuldur fyrir því sem þú vilt setja hér inn.

Í vísitölunni er hvert tákn mikilvægt. Hlaðið meginmál Skill er meira afslappað og keyrslutíminn er sá afslappaðasti. Þetta gæti verið 20.000 tákn eða núll tákn. Þetta er það stig þar sem þú gætir hugsað um að stækka samhengi líkansins á stigvaxandi hátt.

Hvenær þarftu Skill?

Umboðsteymið er oft beðið um að gefa álit sitt á því hvort Skill sé sannarlega nauðsynlegt fyrir tiltekið svið eða notkunartilvik. Mjög sjaldan höfum við endanlegt svar frá fyrstu lögmálum einum saman. Ein leiðin til að komast raunverulega að þessu er að byrja með umboðsmann þinn án Skill, keyra nokkrar helstu fyrirspurnir og ákvarða síðan hvort umboðsmaðurinn sé að standa sig vel.

Þegar þú þarft Skill

Það eru mörg verkefni sem eru í dreifingu fyrir þjálfuð líkön. Þú þarft aðeins að nota Skill ef þú vilt breyta þeirri hegðun á einhvern sérstakan hátt sem þú getur ekki gert með t.d. einni setningu í boðsklofa þínum. Svo þú þarft Skill þegar umboðsmaðurinn gerir rangt án sérstaks samhengis, eða ef það er einhver ósamræmi eða óákveðni sem þú þarft að vera ákaflega samræmd yfir keyrslur.

Það gæti verið að þekking þín sé endingargóð en ekki í þjálfunargögnunum. Það gætu verið lokunardagar eða verkflæði sem eru sértæk fyrir fyrirtækið, eða það gæti verið spurning um smekk. Til dæmis erum við með nokkur hönnunartengd Skills í Computer sem eru skrifuð af Henry Modisett (hönnunarstjóra okkar). Ástæðan fyrir því að hvert tákn er til í þessum Skills er sú að Henry hefur mjög góðan smekk þegar kemur að því að hanna vefsíður og PDF skjöl. Henry tilgreinir hvaða leturgerðir á að nota og hvaða leturgerðir ekki að nota, hvernig þessar leturgerðir líða, og önnur dómgreindarmál sem líkanið getur ekki lært af þjálfunargögnum einum saman.

Þegar þú þarft ekki Skill

Við sjáum mörg Skills þar sem verkfræðingar hafa skrifað röð af git skipunum sem þurfa að vera keyrðar í röð. Það er óþarfi vegna þess að líkanið veit þegar hvernig á að gera það, sem þýðir að það gefur af sér frábær skjöl en lélegt Skill.

Við sjáum dæmi þar sem Skills endurtaka leiðbeiningar úr kerfisboðsklofa. Þú þarft ekki Skill fyrir það. Þekking sem skiptir máli fyrir meirihluta beiðni ætti að vera innifalin í alþjóðlegu samhengi, ekki í skilyrðisbundið hlaðnu Skill

Ef það er eitthvað sem breytist hraðar en þú getur viðhaldið því, þarftu ekki Skill. Til dæmis, ef þú ert að ná í einhvern fjartengdan MCP endapunkt og verkfæri hans eða útgáfur af þeim verkfærum breytast oft, ættirðu ekki að sprauta þeim inn í Skill. Ef þú gerir það muntu bara enda með reki og líkanið mun gera mistök.

Hvert Skill er skattur

Hér er gagnlegt próf sem þú getur beitt á hverja setningu í þínu Skill: „Myndi umboðsmaðurinn gera þetta rangt án þessslu leiðbeiningar?“ Ef setningin þarf ekki að vera þar, hefur hún ekki efni á að vera þar vegna þess að allir eru að greiða þennan kostnað í hvert einasta skipti. Þegar þú ert að ákveða hvort þú átt að bæta við Skill eða ekki, skaltu muna þennan skatt þar sem hvert samtal og hver notandi kostar tákn.

Eftirfarandi fræga tilvitnun, sem hljómar mun betur á frönsku, þýðist lauslega sem „Ég hef aðeins gert þetta bréf lengra vegna þess að ég hef ekki haft tíma til að gera það styttra.“

« 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

Rétt eins og Pascal þurfir þú að fjárfesta tíma í hverju Skill. Það er erfitt að skrifa stutt Skill. Ef þitt Skill er auðskrifað er það líklega of langt eða ætti ekki að vera til. Gott Skill er eins stutt og það getur verið.

Ef þú kemst að því að þú ert að reyna að búa til Skill í einni atrennu og setja upp PR-ana á fimm mínútum verða niðurstöðurnar nánast örugglega undir meðaltali. Reyndar hafa snemmbúnar rannsóknir sýnt að ef þú ert að nota LLM til að skrifa Skills mun LLM líklega ekki njóta góðs af því: „Sjálfgerð Skills veita engan ávinning að meðaltali, sem sýnir að líkön geta ekki með áreiðanlegum hætti samið þá málsmeðferðarþekkingu sem þau njóta góðs af að neyta.“

Hvernig á að byggja upp Skill

Sett á annan hátt, þarftu að sprauta áliti þínu inn í hvaða Skill sem þú skrifar. Fylgdu þessum skrefum.

Skref 0: Skrifaðu eval-in

Skrifaðu nokkur eval fyrst. Þú getur sótt matstilvik frá:

Raunverulegar fyrirspurnir notenda: sýnishorn úr framleiðslu eða traustshópnum þínum

Þekktar bilanir: Umboðsmaðurinn brást mert vegna þess að Skill var ekki til staðar

Ruglingur nágranna: Nálægt lénsmarkinu þínu en beinist að öðru Skill

Að minnsta kosti ættir þú að ganga úr skugga um að þú sért að prófa að Skill hlaðist inn þegar þess þarf. Helst tekur þú sýnishorn af þessum, kannski úr framleiðsluumhverfi. Þú gætir líka íhugað þekkt villutilvik: kannski er öll ástæðan fyrir því að þú lagðst í að skrifa Skill vegna tiltekinnar bilunar sem þú tókst eftir eða kannski ertu að endurgera og það er einhver ruglingur á tveimur nálægum lénum sem eru þakin af einu Skill.

Byrjaðu á svipuðum neikvæðum og jákvæðum dæmum. Neikvæð dæmi eru ákaflega öflug og geta skipt meira máli en jákvæð dæmi.

Skref 1: Lýsingin

Þetta er erfiðasta línan í Skill. Það er beiningarkveikja, ekki skjöl. Til að ná nafninu og lýsingunni réttri þá skiptir innihald Skill þig engu máli. Þig varðar eingöngu um hvort Skill sé hlaðið inn og sprautað inn á réttum stöðum og sé laust við hliðaráhrif utan skotmarks, sem er helsta bilunarstillingin. Í hvert skipti sem þú bætir við auka Skill áttu á hættu að gera öll önnur Skills aðeins verri, svo þú þarft að tryggja að þú sért að lágmarka afturför.

Aftur á móti lýsir slæm lýsing því hvað Skill gerir eða hvers vegna það er gagnlegt. Góð lýsing segir hvenær umboðsmaðurinn ætti að hlaða Skillinu. Til dæmis, segjum að þú sért með eitthvað til að fylgjast með pull requests. Ekki skrifa hvað Skill gerir. Skrifaðu hvað verkfræðingar segja þegar þeir eru pirraðir og vilja að þú tryggir að PR-ið þeirra virki, eins og „babysit“ eða „watch CI“ eða „make sure this lands.“

Hér er fljótlegur gátlisti:

Byrjar á „Load when...“

Miðaðu við 50 orð eða færri

Lýsir ásetningi notanda, helst úr raunverulegum fyrirspurnum

Tekur ekki saman verkflæðið

Raunverulegar fyrirspurnir eru það sem þú getur dekkað í 80-20. Venjulega virka tvö eða þrjú dæmi vel. Það er ekki auðvelt að bæta við nákvæmlega og eingöngu eins miklu og þig þarf á að halda.

Skref 2: Skrifaðu meginmálið

Næst skaltu skrifa innihald Skill sjálfs. Taktu eftir að þetta er ekki Skref 0 eða Skref 1.

Að miðla verkflæði til LLM er algjörlega frábrugðið því að miðla verkflæði til samstarfsmanns, eða jafnvel til keyrslukerfisins þíns. Þegar verkfræðingur lærir nýtt hugbúnaðartæki gæti hann þurft að lesa skjölin, fá leiðsögn frá einhverjum með reynslu og læra hvernig á að nota tækið. Á sama tíma, fyrir nánast hvaða hugbúnaðartæki sem hefur verið til í að minnsta kosti ár, þarftu bara að nefna nafnið og LLM hefur allar upplýsingar sem það þarft.

Þegar þú ert að skrifa meginmálið skaltu sleppa augljósum hlutum. Margir verkfræðingar hafa næga reynslu af því að skrifa readme.md skrár sem telja upp hverja einustu skipun sem einhver þarf að keyra. Það er auðvelt að detta til baka í það þegar þú ert að skrifa Skill vegna þess að það líður eins og þú sért að skrifa skjöl, en ef þú gerir það verður þitt Skill rusl. Svo ekki skrifa út röð af skipunum.

Til dæmis þarftu ekki að skrifa, „git log # find the commit; git checkout main; git checkout -b <clean-branch>; git cherry-pick <commit>;“

Skrifaðu í staðinn, „Cherry-pick the commit onto a clean branch. Resolve conflicts preserving intent. If it can't land cleanly, explain why.“

Líkanið mun standa sig mun betur með það síðarnefnda en með of forskriftarlegri röð af skipunum þess fyrrnefnda, sérstaklega þegar hlutir fara úrskeiðis. Ekki járnbrautartengja eða vera of forskriftarlegur, sem er viðkvæmt, og vera í staðinn sveigjanlegur þar sem margar nálganir geta virkað. Aftur á móti eru góð skjöl fyrir menn oftast slæm skjöl fyrir líkön.

Næst skaltu einbeita þér að gildrunum eða neikvæðum dæmum. Þetta er afar hárra merkja efni vegna þess að það leiðir oft líkanið hvað varðar það sem ekki á að gera. Ef þú bætir við línu í hvert skipti sem umboðsmaðurinn hröflar þá muntu læra með því að keyra það og gildrurnar munu stækka lífrænt.

Að lokum, ef það er einhver hluti sem er skilyrðisbundinn eða mjög þungur í efni, skaltu taka hann út úr SKILL.md, sem er miðjan, og setja hann í eina af geirunum. Settu það í aukaskrá sem hægt er að hlaða inn stigvikið, sem við munum kafa dýpra í næst.

Skref 3: Notaðu stigveldið

Notaðu Skill stigveldið þegar þú ert með forskrift, tilvísanir eða ert að nota eitthvað sérstakt tæki:

Fyrirhuguð notkun fyrir skriftur, tilvísanir, gerviþætti og uppsetningu innan Skill.

Fyrir allt sem er skilyrðisbundið eða greinast frá aðal Skill skaltu brjóta það út í möppu. Mundu einnig að hægt er að nota stigveldi á mörgum stigum fyrir sérstaklega flókin Skills. Fyrir þessi viltu velta því vandlega fyrir þér hvort virknin eigi að vera útfærð í heilu lagi eða sem safn af Skills (kannski með depends: byggðum hleðslutengslum).

Skref 4: Endurtaka

Næst skaltu gera fullt af ítrunum á grein. Byrjaðu á aðalgreininni án Skill, gerðu nokkrar ítranir, byggðu upp helstu fyrirspurnasettið þitt og keyrðu fullt af eval-um. Hver sá sem fer yfir þinn Skill kóða mun þakka þér fyrir að skila einni breytingu ásamt matsetti. Það er mjög erfitt að fara yfir ítrekaðar viðbótarbreytingar (nema nýja gildru), svo reynum að lágmarka það.

Þú munt líklega gera margar litlar orðabreytingar. Litlar orðabreytingar á lýsingum geta haft gríðarleg áhrif á beiningu (þar á meðal yfirflæðisáhrif á önnur Skills), svo gerðu alla þá vinnu fyrir Skref 5.

Skref 5: Sendu

Sendu það.

Hvernig á að viðhalda Skill

Nú þegar þú hefur skrifað Skill þarftu að viðhalda því.

Gildruflugan (The Gotchas Flywheel)

Frá og með þessum punkti hefur listinn þinn yfir gildrur tilhneigingu til að stækka eða breytast mikið. Við sjáum oft verkfræðinga sem búa til PR sem eru ekki eval-uð, til dæmis að breyta lýsingunni. Ef þú ert að breyta lýsingunni eftir að búið er að sameina þitt Skill ertu kominn út af brautinni. Ef þú ert að gera breytingar á því sem ákveður hvort beina eigi þínu Skill þarftu að skrifa nokkur eval sem styðja breytingarnar.

Skills eru aðallega viðbótarhæf. Gildrukaflinn safnar mestu gildi með tímanum:

Umboðsmaður mistakast í einhverju → Bæta við gildru

Umboðsmaður hleður inn Skill utan skotmarks → Þrengja lýsingu og bæta við neikvæðum eval-um

Umboðsmaður hleður ekki inn Skill þegar hann ætti að gera það → Bæta við lykilorðum og jákvæðum eval-um

Kerfisboðsklofi breytist → Athuga hvort um ágreining eða tvítekningu sé að ræða

Það er auðvelt að taka eftir einstöku bilunartilviki í innri prófunum eða í framleiðslu og bæta við gildru. Það er neikvætt dæmi þannig að það er ekki raunverulega að breyta skýrum leiðbeiningum, en það lætur líkanið vita: „Hey, það er þessi þekkta bilun.“

Þegar þú færist frá 80-20 yfir í að ná 99,9% eða 99,99% árangurshlutfalli er auðvelt að stækka þennan gildrulista. Þegar þú sérð þessi neikvæðu dæmi ættirðu aðallega að vera að bæta við gildrukaflann. Þú ættir ekki að vera að bæta við lengri leiðbeiningum eða breyta lýsingunni.

Matssett (Eval Suites)

Hjá Perplexity keyrum við mörg eval-sett til að athuga með ýmsa hluti. Það eru hleðsla og lestur á skrá Skill, sem athugar nákvæmni, heimt og bönnuð athugun á hleðslu Skill sjálfs. Mun umboðsmaðurinn beina þínu Skill þegar því er ætlað? Þetta tryggir að ný Skills brjóti ekki núverandi mörk.

Það eru líka eval sem geta athugað með rétta stigvaxandi hleðslu. Umboðsmaðurinn gæti hlaðið inn Skill, en les hann aukaskrána eða skrárnar? Til dæmis, ef þú ert með fjármála-Skill fyrir fjármálafyrirspurnir, les það þá sérstöku skrána FORMATTING.md?

Það eru líka eval fyrir Skills sem prófa verkefnalok frá enda til enda innan léna. Við keyrum alla umboðsslaufuna og notum LLM dómara til að gefa niðurstöðunum einkunn út frá reglum um vel skilgreind skilyrði.

Að lokum er mikilvægt að keyra þessi eval gegn mismunandi líkönum. Computer styður að minnsta kosti þrjár mismunandi skipulagningarfjölskyldur líkana: GPT, Claude Opus og Claude Sonnet. Þú vilt keyra hleðslu þíns Skill og lensu-Skills gegn þessum mismunandi umboðsskipuleggjendum til að tryggja að þú fáir ekki mismunandi hegðun. Sonnet and GPT haga sér nokkuð öðruvísi þegar kemur að Skills.

Lokahugsanir og lærdómur

Því fleiri Skills sem þú byggir, því betri verður þú í að byggja þau. Ef þú ert ekki að sjálfvirknivæða eða reyna að gera fleiri endurtekningarhæf verkefni sem þú ert að gera dags daglega með því að nota Skills, skaltu byrja strax.

Aðgerðin við að byggja upp Skills gerir þig betri í að byggja upp fleiri Skills, en einnig eru þau ákaflega góð til að sjálfvirknivæða viðskiptaferla. Ef þú getur lýst einhverju sem þú gerir í hverri viku fyrir uppistandið þitt, í lok hverrar sprettlota, eða hverju sem er sem þú gerir sem verkfræðingur á daglegum, vikulegum eða jafnvel ársfjórðungslegum grunni, ættir þú að vera að skrifa Skill til að endurheimta tíma þinn.

Geturðu sjálfvirknivætt eftirmæli? Geturðu farið yfir pull requests? Hvaða verkefni sem þú getur gert, þá geturðu að minnsta kosti látið fyrstu umferð vera umboðs-Skill. Það mun spara þér umtalsverðan tíma.

Það sagt, mundu að Skill er ekki auðvelt eða jafnvel alltaf nauðsynlegt. Minna er meira. Nokkrir aðrir lærdómar:

Skrifaðu eval áður en Skill er skrifað. Láttu neikvæð dæmi og bannaðar hleðslur fylgja með fyrir nálæg en aðgreind skills.

Lýsingin er erfiði hlutinn. „Load when...“ (hvert orð kostar athygli).

Gildrur eru afar hárra merkja efni. Byrjaðu þunnt, stækkaðu þegar umboðsmaðurinn bregst.

Mundu að það er auðvelt að brjóta önnur fyrirfram tilin Skills með því að bæta við nýju Skill, jafnvel þótt þú hafir ekki snert það (varast fjarlægðaraðgerðir).

Notaðu öll tiltæk tæki í hvert skipti sem þú skrifar og viðheldur Skill. Ef þú vilt vita meira hefur Agent Skills vefsíðan nóg af góðum dæmum, og bæði innra geymsla okkar og opinbera vistkerfið innihalda mörg dæmi um vel hönnuð Skills.

Tilvitnun

@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://www.perplexity.ai/hub/blog/designing-refining-and-maintaining-agent-skills-at-perplexity}
}