Σχεδιασμός, βελτίωση και συντήρηση δεξιοτήτων πρακτόρων στο Perplexity

Τα προϊόντα-πράκτορες αιχμής του Perplexity βασίζονται σε θεμέλια τεχνογνωσίας και εξειδίκευσης σε συγκεκριμένους τομείς, συσκευασμένα σε αρθρωτές Agent Skills. Διατηρούμε μια προσεκτικά επιμελημένη βιβλιοθήκη δεξιοτήτων σε όλα τα τεχνικά μας περιβάλλοντα. Αυτές οι δεξιότητες περιλαμβάνουν πολλές από τις γενικές βοηθητικές λειτουργίες που τροφοδοτούν το Perplexity Computer· δυνατότητες ειδικές για κάθε κλάδο σε τομείς όπως τα οικονομικά, η νομική και η υγεία· και μια τεράστια γκάμα αρθρωτών μονάδων για την κάλυψη των αναγκών των χρηστών. Ορισμένες δεξιότητες χρησιμοποιούνται σπάνια, αλλά είναι κρίσιμες όταν χρησιμοποιούνται. Για να διασφαλιστεί μια σταθερά εξαιρετική εμπειρία χρήστη, η ομάδα Agents του Perplexity δίνει προτεραιότητα στην ποιότητα των δεξιοτήτων εξίσου με την ποιότητα του κώδικα.

Η διαίσθηση και οι βέλτιστες πρακτικές που απαιτούνται για την ανάπτυξη μιας δεξιότητας υψηλής ποιότητας διαφέρουν σημαντικά από εκείνες που απαιτούνται για τη δημιουργία παραδοσιακού λογισμικού. Η ομάδα Agents εξετάζει πολλές αιτήσεις συγχώνευσης (pull requests) από εξαιρετικούς μηχανικούς που αναπτύσσουν δεξιότητες κατά τη διάρκεια της εργασίας τους. Το αποτέλεσμα είναι σχεδόν πάντα πολυάριθμα σχόλια και προτάσεις για αναθεώρηση. Αυτό συμβαίνει επειδή πολλά χρήσιμα πρότυπα για τη συγγραφή κώδικα γίνονται αντιπρότυπα (anti-patterns) κατά τη δημιουργία δεξιοτήτων.

Για παράδειγμα, αν πάρετε μερικά από τα αποφθέγματα από το PEP20 – The Zen of Python, γίνεται γρήγορα σαφές ότι η συγγραφή καλού κώδικα Python δεν μοιάζει με τη συγγραφή καλών δεξιοτήτων. Από τις 20 γραμμές σοφίας, τουλάχιστον οι μισές είναι εντελώς λανθασμένες ή παραπλανητικές όταν γράφετε δεξιότητες. Ακολουθούν πέντε από αυτές:

Πέντε αντιθέσεις μεταξύ του Zen of Python και της καθοδήγησης του άρθρου για τη συγγραφή Δεξιοτήτων.

Αυτός ο οδηγός είναι το έγγραφο που χρησιμοποιούν οι μηχανικοί σε όλη την Perplexity όταν αναπτύσσουν και αξιολογούν δεξιότητες. Επίσης, διαθέτουμε αυτόν τον οδηγό στο κοινό, ώστε οι ανακαλύψεις και τα συμπεράσματά μας να ωφελήσουν την ευρύτερη κοινότητα. Είτε είστε μηχανικός που σχεδιάζει δεξιότητες παραγωγής στην καθημερινή του εργασία, είτε χρήστης του Computer που θέλει να αναπτύξει τη δική του δεξιότητα σε έναν τομέα που γνωρίζει καλύτερα, είτε και τα δύο, αυτός ο οδηγός είναι για εσάς.

Τι είναι μια δεξιότητα;

Όταν γράφετε μια δεξιότητα, δεν γράφετε απλό, παλιό λογισμικό (ακόμη κι αν οι δεξιότητες αποτελούν πλέον μέρος των βασικών λογικών μηχανών για συστήματα πρακτόρων). Αντίθετα, χτίζετε context για τα μοντέλα και τα περιβάλλοντά τους. Μια δεξιότητα έχει διαφορετικούς περιορισμούς και διαφορετικές αρχές σχεδιασμού. Αν γράψετε μια δεξιότητα όπως γράφετε κώδικα, θα αποτύχετε.

Μια δεξιότητα είναι τουλάχιστον τέσσερα πράγματα, ειδικά στο πλαίσιο του πώς τις κατασκευάζουμε στο Perplexity.

Μια δεξιότητα είναι ένας φάκελος

Μια δεξιότητα δεν είναι απλώς ένα μεμονωμένο αρχείο SKILL.md. Στις περισσότερες περιπτώσεις, μια δεξιότητα περιλαμβάνει πολλά αρχεία. Κάτω από τον φάκελο που φέρει το όνομα της δεξιότητάς σας, ενδέχεται να έχετε:

SKILL.md: frontmatter και οδηγίες

scripts/: κώδικας που εκτελεί ο πράκτορας, δεν επανεφευρίσκει

references/: βαριά έγγραφα, που φορτώνονται υπό όρους

assets/: πρότυπα, σχήματα και δεδομένα

config.json: αρχική ρύθμιση χρήστη κατά την πρώτη εκτέλεση

Αυτό το μοτίβο κόμβου-ακτίνας σάς επιτρέπει να διατηρείτε τις δεξιότητες πολύ εστιασμένες και συμπαγείς, και κάποιος μπορεί να χρησιμοποιήσει τη δομή φακέλων με πολύ δημιουργικό τρόπο. Μερικές φορές, οι ιδιαίτερα περίπλοκες δεξιότητες επωφελούνται από πολλαπλά επίπεδα ιεραρχίας για να βοηθήσουν το μοντέλο να πλοηγηθεί καλύτερα. Ας υποθέσουμε ότι μια δεξιότητα απαιτεί γνώσεις σε 300 θέματα, τα οποία μπορούν να ομαδοποιηθούν σε 20 θεματικές περιοχές. Η αξιόπιστη επιλογή του σωστού θέματος μεταξύ 300 αποτελεί μια ανεπίλυτη πρόκληση ακόμη και για τα καλύτερα σημερινά μοντέλα αιχμής. Είναι πολύ πιο εύκολο πρόβλημα επιλογής για ένα μοντέλο να επικεντρωθεί σε μία από τις 20 περιοχές, παρά ανάμεσα στα 15 θέματα εντός αυτής της περιοχής.

Ως ένα παράδειγμα του πώς η πολυεπίπεδη ιεραρχία προσφέρει αξία, η ομάδα μας αξιοποίησε τρία επίπεδα θεματικής ένθεσης μέσα στις δεξιότητες που τροφοδοτούν τις δυνατότητες φορολογίας εισοδήματος στις ΗΠΑ του Computer αυτή την περασμένη φορολογική περίοδο. Αυτή η ιεραρχία ήταν απολύτως απαραίτητη λόγω της πολυπλοκότητας του φορολογικού δικαίου: στις αρχικές μας δοκιμές, η παρουσίαση στο μοντέλο ενός μόνο φακέλου που περιείχε και τα 1.945 άρθρα του Κώδικα Εσωτερικών Εσόδων των ΗΠΑ είχε ως αποτέλεσμα χειρότερη απόδοση από το να μην φορτωθεί καθόλου η δεξιότητα. Η οργάνωση των πληροφοριών σε λογικές υποδιαιρέσεις ήταν απαραίτητη για τη διασφάλιση αναγνωστικών λειτουργιών υψηλής ακρίβειας.

Ωστόσο, αυτή η ιεραρχία δεν ήρθε χωρίς κόστος. Τα αυξανόμενα επίπεδα ιεραρχίας απαιτούν αυξανόμενα επίπεδα επιμέλειας σε όλη την αρχιτεκτονική πληροφοριών για τη διαχείριση της προκύπτουσας έμμεσης αναφοράς. Αναπτύξαμε γρήγορους οδηγούς αναφοράς, προσαρμοσμένα βοηθητικά εργαλεία αναζήτησης και άλλα εργαλεία για να υποστηρίξουμε το μοντέλο στον εντοπισμό πληροφοριών με ελάχιστη έμμεση αναφορά. Σε αυτή την περίπτωση, η ανάληψη της δύσκολης δουλειάς της επιμέλειας τελικά παρήγαγε ένα θετικό αποτέλεσμα: μια δεξιότητα που επέτρεψε στα μοντέλα να εκτελούν φορολογικά σχετικές εργασίες πολύ πιο αποτελεσματικά από τη χρήση μόνο γενικών εργαλείων.

Μεγέθυνση

Μια δεξιότητα είναι μια μορφή

Μια δεξιότητα είναι μια μορφή. Το βασικό αρχείο ρίζας SKILL.md πρέπει να διαθέτει τόσο όνομα όσο και περιγραφή. Επιπλέον, η δεξιότητα πρέπει να αντιστοιχίζεται επακριβώς στο όνομα του φακέλου στον οποίο βρίσκεται η δεξιότητα. Το όνομα πρέπει να αποτελείται εξ ολοκλήρου από πεζούς χαρακτήρες, να μην έχει κενά και μπορεί να χρησιμοποιεί παύλες. Η περιγραφή αποτελεί το ένασμα δρομολόγησης (routing trigger). Αυτό είναι ένα κοινό σημείο αποτυχίας: η περιγραφή δεν αποτελεί εσωτερική τεκμηρίωση για το τι κάνει η δεξιότητα. Συνιστά οδηγίες για το μοντέλο σχετικά με το πότε πρέπει να φορτώσει τη δεξιότητα. Επομένως, θα βλέπετε συχνά "Load when" (Φόρτωση όταν), και όχι "This Skill does" (Αυτή η δεξιότητα κάνει). Αυτό είναι σημαντικό λόγω του τρόπου με τον οποίο οι περισσότερες υλοποιήσεις εισάγουν την περιγραφή στο context του μοντέλου.

Μέσα στο frontmatter, υπάρχει επίσης το “depends:”, το οποίο σας επιτρέπει να δημιουργήσετε ιεραρχικές εξαρτήσεις δεξιοτήτων, και το “metadata:”, το οποίο χρησιμοποιείται για κριτικές και αξιολογήσεις. Τα διαφορετικά συστήματα πρακτόρων μπορούν ακόμη και να ορίσουν τα δικά τους πεδία frontmatter, ώστε να χρησιμοποιούνται με τρόπο ειδικό για αυτά τα συστήματα. Ως εναλλακτική λύση, τα μεταδεδομένα που αφορούν συγκεκριμένη δεξιότητα μπορούν να συσκευαστούν σε ένα βοηθητικό αρχείο διαμόρφωσης JSON ή YAML. Αυτό είναι επιθυμητό κατά τη δημιουργία συστημάτων πρακτόρων που πρέπει να διευκολύνουν διαφορετικούς τύπους συμπεριφοράς χρόνου εκτέλεσης ανά δεξιότητα, χωρίς να επιβαρύνουν το context του μοντέλου με λεπτομέρειες. Τέλος, παρόμοια συμπεριφορά μπορεί να επιτευχθεί μέσω της αφαίρεσης του frontmatter δεξιότητας κατά την ανάγνωση. Το Computer χρησιμοποιεί αυτή τη μεθοδολογία, η οποία επιτρέπει τη διατήρηση της διαμόρφωσης στο βασικό αρχείο SKILL.md. Απαιτείται προσεκτική προσοχή στη λεπτομέρεια στη λογική ανάλυσης (parsing) και ίσως κάποιος επιθυμεί να εφαρμόσει υπό όρους αφαίρεση εάν υπάρχουν ορισμένα πεδία που είναι χρήσιμο να υπάρχουν εντός του context του μοντέλου.

Μια δεξιότητα είναι επικληθήσιμη

Μια δεξιότητα είναι επικληθήσιμη. Ο πράκτορας φορτώνει μια δεξιότητα κατά το χρόνο εκτέλεσης (runtime). Το σημαντικό είναι ότι οι δεξιότητες δεν ομαδοποιούνται πάντα στο context. Από προεπιλογή, τα περισσότερα συστήματα πρακτόρων αναπτύσσουν τις δεξιότητες προοδευτικά ανάλογα με τη συγκεκριμένη ανάγκη.

Υπάρχουν τουλάχιστον τρία επίπεδα κόστους context στον τρόπο με τον οποίο έχουμε υλοποιήσει τις δεξιότητες στο Computer. Ακολουθεί η διαδικασία:

Το Computer καλεί το load_skill(name="...")

Το Computer αντιγράφει τον φάκελο της δεξιότητας στο απομονωμένο sandbox εκτέλεσης

Το Computer φορτώνει αυτόματα και αναδρομικά τις εξαρτήσεις στην ετικέτα “depends:”

Στη συνέχεια, το Computer αφαιρεί το frontmatter και ο πράκτορας βλέπει επομένως μόνο το κυρίως σώμα και τα επιπλέον αρχεία

Τα διαφορετικά συστήματα πρακτόρων μπορούν να επιλέξουν να εκθέσουν το περιεχόμενο δεξιότητας με διαφορετικούς τρόπους. Ως παράδειγμα, ορισμένα συστήματα ενδέχεται να επιλέξουν να μην εκθέσουν καθόλου την ιεραρχία αρχείων, αφήνοντας στο μοντέλο την ανακάλυψη της ιεραρχίας μέσω λειτουργιών του συστήματος αρχείων. Άλλα συστήματα ενδέχεται να επιλέξουν να δώσουν στο μοντέλο μια αντιστοίχιση ολόκληρου του δέντρου αρχείων έως ένα ορισμένο όριο περικοπής και/ή βάθους. Για να διατηρηθεί το context καθαρό, το Computer παραλείπει πλήρεις ιεραρχίες αρχείων από το context κλήσης· ωστόσο, αυτό μπορεί να παρακαμφθεί σε επίπεδο ανά δεξιότητα.

Μια δεξιότητα είναι προοδευτική

Οι δεξιότητες είναι προοδευτικές. Στο Computer, υπάρχουν τρία διαφορετικά επίπεδα κόστους context και επιβαρυνόμαστε και με τα τρία σε διάφορα στάδια:

Τα τρία επίπεδα περιεχομένου Δεξιότητας: ευρετήριο, πλήρης φόρτωση Δεξιότητας και αρχεία αναφοράς χρόνου εκτέλεσης.

Το Computer δημιουργεί ένα ευρετήριο δεξιοτήτων που διαθέτει το όνομα και την περιγραφή για κάθε διαθέσιμη δεξιότητα. Ο προϋπολογισμός για αυτό είναι περίπου 100 tokens ανά δεξιότητα (το μικρότερο είναι ακόμη καλύτερο). Είναι τόσο περιορισμένος επειδή πληρώνετε αυτό το κόστος σε κάθε Συνεδρία, για κάθε χρήστη. Αυτό εισάγεται στο μήνυμα συστήματος (system prompt) στην πολύ αρχή της συνομιλίας. Το μοντέλο έχει πρόσβαση σε μια δέσμη ονοματισμένων δεξιοτήτων και περιγραφών, ώστε να μπορεί να αποφασίσει εάν θα καλέσει το “load_skill()”. Ο πήχης για την είσοδο σε αυτό το ευρετήριο είναι εξαιρετικά υψηλός. Η δεξιότητά σας πρέπει να είναι πολύ χρήσιμη και η περιγραφή πρέπει να είναι εξαιρετικά πυκνή και λακωνική, επειδή ο καθένας πληρώνει το κόστος συνεχώς.

Αφού το σύστημα πρακτόρων φορτώσει τη δεξιότητα, υπάρχει το πλήρες σώμα SKILL.md. Ιανικά, το κείμενο του σώματος δεν υπερβαίνει τα 5.000 tokens. Ακόμη και τότε, θέλετε κάθε πρόταση να έχει σημασία, διότι μόλις φορτώσετε μια δεξιότητα, η υπόλοιπη συνομιλία πρέπει να το πληρώνει αυτό μέχρι να φτάσετε στο όριο συμπίεσης. Πολλά νήματα φορτώνουν οπουδήποτε από τρεις έως πέντε διαφορετικές δεξιότητες, πολλαπλασιάζοντας αυτό το κόστος. Οι δεξιότητες με πολλά περιττά στοιχεία είναι σχεδόν βέβαιο ότι θα υποβαθμίσουν άλλες δεξιότητες καθώς και τις συνολικές δυνατότητες πρακτόρων. Εν ολίγοις, εάν η δεξιότητά σας φορτωθεί και δεν κάνει το σωστό πράγμα, αυτό είναι χαμένο context.

Το τελικό επίπεδο πρόοδσης είναι τα scripts ή ειδικές περιπτώσεις, όπως υποδεξιότητες ή μορφοποίηση. Εδώ θέλετε να τοποθετήσετε απεριόριστη λογική διακλάδωσης υπό όρους. Ο πράκτορας θα τη χρησιμοποιήσει μόνο όταν τη χρειαστεί, πράγμα που σημαίνει ότι υπάρχει πολύ χαμηλότερος πήχης για το τι θέλετε να βάλετε εδώ.

Στο ευρετήριο, κάθε token είναι σημαντικό. Το φορτωμένο σώμα δεξιότητας είναι πιο χαλαρό και ο χρόνος εκτέλεσης είναι ο πιο χαλαρός. Αυτό θα μπορούσε να είναι 20.000 tokens ή μηδέν tokens. Αυτό είναι το επίπεδο στο οποίο μπορεί να σκεφτείτε να επεκτείνετε το context του μοντέλου με προοδευτικό τρόπο.

Πότε χρειάζεστε μια δεξιότητα;

Η ομάδα Agents ερωτάται συχνά να εκφέρει γνώμη για το εάν μια δεξιότητα είναι όντως απαραίτητη για έναν δεδομένο τομέα ή περίπτωση χρήσης. Πολύ σπάνια έχουμε μια οριστική απάντηση μόνο από τις πρωταρχικές αρχές. Ο μόνος τρόπος για να το καταλάβετε πραγματικά είναι να ξεκινήσετε με τον πράκτορά σας χωρίς τη δεξιότητα, να εκτελέσετε πολλά ερωτήματα-ορόσημα (hero queries) και στη συνέχεια να διαπιστώσετε εάν ο πράκτορας κάνει καλή δουλειά.

Όταν χρειάζεστε μια δεξιότητα

Υπάρχουν πολλές εργασίες που βρίσκονται εντός κατανομής (in distribution) για εκπαιδευμένα μοντέλα. Πρέπει να εφαρμόσετε μια δεξιότητα μόνο εάν θέλετε να αλλάξετε αυτή τη συμπεριφορά με κάποιον συγκεκριμένο τρόπο που δεν μπορείτε με, ας πούμε, μία πρόταση στο prompt σας. Επομένως, χρειάζεστε μια δεξιότητα όταν ο πράκτορας θα κάνει λάθος χωρίς ειδικό context, ή εάν υπάρχει κάποια ασυνέπεια ή μη ντετερμινισμός που πρέπει να διατηρήσετε εξαιρετικά συνεπή σε όλες τις εκτελέσεις.

Θα μπορούσε να συμβαίνει ότι η γνώση σας είναι ανθεκτική αλλά δεν βρίσκεται στα δεδομένα εκπαίδευσης. Θα μπορούσαν να υπάρχουν χρονικά όρια (cutoffs) ή ροές εργασίας ειδικές για την επιχείρηση, ή θα μπορούσε να είναι ζήτημα αισθητικής. Για παράδειγμα, έχουμε διάφορες δεξιότητες σχετικές με τον σχεδιασμό στο Computer γραμμένες από τον Henry Modisett (επικεφαλής σχεδιασμού μας). Ο λόγος για τον οποίο κάθε token υπάρχει σε αυτές τις δεξιότητες είναι επειδή ο Henry έχει πολύ καλή αισθητική όσον αφορά τον σχεδιασμό ιστοσελίδων και PDF. Ο Henry καθορίζει ποιες γραμματοσειρές να χρησιμοποιηθούν και ποιες όχι, πώς αισθάνονται αυτές οι γραμματοσειρές και άλλα ζήτηματα κρίσης που το μοντέλο δεν μπορεί να μάθει μόνο από τα δεδομένα εκπαίδευσης.

Όταν δεν χρειάζεστε μια δεξιότητα

Βλέπουμε πολλές δεξιότητες στις οποίες οι μηχανικοί έχουν γράψει μια σειρά από εντολές git που πρέπει να εκτελεστούν με σειρά. Αυτό είναι περιττό επειδή το μοντέλο ξέρει ήδη πώς να το κάνει αυτό, πράγμα που σημαίνει ότι αποτελεί εξαιρετική τεκμηρίωση αλλά φτωχή δεξιότητα.

Βλέπουμε παραδείγματα όπου οι δεξιότητες επαναλαμβάνουν οδηγίες από το μήνυμα συστήματος (system prompt). Δεν χρειάζεστε μια δεξιότητα για αυτό. Η γνώση που είναι σχετική για την πλειοψηφία των αιτημάτων θα πρέπει να περιλαμβάνεται στο καθολικό context, και όχι σε μια δεξιότητα που φορτώνεται υπό όρους

Εάν υπάρχει κάτι που αλλάζει πιο γρήγορα από ό,τι μπορείτε να το συντηρήσετε, δεν χρειάζεστε μια δεξιότητα. Για παράδειγμα, εάν αλληλεπιδράτε με κάποιο απομακρυσμένο τελικό σημείο (endpoint) MCP και τα εργαλεία του ή οι εκδόσεις αυτών των εργαλείων αλλάζουν συχνά, δεν πρέπει να τα εισάγετε σε μια δεξιότητα. Αν το κάνετε, θα καταλήξετε απλώς σε απόκλιση (drift) και το μοντέλο θα κάνει λάθη.

Κάθε δεξιότητα είναι ένας φόρος

Ακολουθεί μια χρήσιμη δοκιμή που μπορείτε να εφαρμόσετε σε κάθε πρόταση στη δεξιότητά σας: «Θα έκανε ο πράκτορας λάθος σε αυτό χωρίς αυτή την οδηγία;» Εάν η πρόταση δεν χρειάζεται να βρίσκεται εκεί, δεν έχει την πολυτέλεια να βρίσκεται εκεί, επειδή ο καθένας πληρώνει αυτό το κόστος κάθε φορά. Όταν αποφασίζετε εάν θα προσθέσετε μια δεξιότητα ή όχι, να θυμάστε αυτόν τον φόρο όπου κάθε Συνεδρία και κάθε χρήστης κοστίζει tokens.

Το ακόλουθο διάσημο απόφθεγμα, το οποίο ακούγεται πολύ καλύτερα στα γαλλικά, μεταφράζεται κατά προσέγγιση σε «Έκανα αυτό το γράμμα μεγαλύτερο μόνο επειδή δεν είχα τον χρόνο να το κάνω μικρότερο».

« 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, πρέπει να επενδύσετε χρόνο σε κάθε δεξιότητα. Είναι δύσκολο να γράψετε μια σύντομη δεξιότητα. Εάν η δεξιότητά σας γράφεται εύκολα, είναι πιθανώς πάρα πολύ μεγάλη ή δεν θα έπρεπε να υπάρχει. Μια καλή δεξιότητα είναι όσο πιο σύντομη μπορεί να είναι.

Εάν διαπιστώσετε ότι προσπαθείτε να κάνετε δημιουργία δεξιοτήτων μίας λήψης (one-shot) και να ανεβάζετε PRs σε πέντε λεπτά, τα αποτελέσματα θα είναι σχεδόν βέβαια κατώτερα των προσδοκιών. Στην πραγματικότητα, η πρώιμη έρευνα έχει δείξει ότι εάν χρησιμοποιείτε LLM για τη συγγραφή δεξιοτήτων, το LLM πιθανότατα δεν θα ωφεληθεί από αυτό: «Οι αυτοδημιούργητες δεξιότητες δεν προσφέρουν κανένα όφελος κατά μέσο όρο, δείχνοντας ότι τα μοντέλα δεν μπορούν να δημιουργήσουν με αξιοπιστία τη διαδικαστική γνώση από την οποία ωφελούνται καταναλώνοντας».

Πώς να χτίσετε μια δεξιότητα

Με άλλα λόγια, πρέπει να εισάγετε την άποψή σας σε οποιαδήποτε δεξιότητα γράφετε. Ακολουθήστε αυτά τα βήματα.

Βήμα 0: Γράψτε τα Evals

Γράψτε μερικά από τα evals πρώτα. Μπορείτε να αντλήσετε περιπτώσεις αξιολόγησης από:

Πραγματικά ερωτήματα χρηστών: δείγμα από την παραγωγή ή την έμπιστη ομάδα σας (brain trust)

Γνωστές αποτυχίες: Ο πράκτορας απέτυχε επειδή η δεξιότητα δεν υπήρχε

Σύγχυση γειτόνων: Κοντά στο όριο του τομέα σας αλλά δρομολογείται σε άλλη δεξιότητα

Τουλάχιστον, θα πρέπει να βεβαιώνεστε ότι δοκιμάζετε ότι η δεξιότητα φορτώνεται όταν χρειάζεται. Ιδανικά, παίρνετε δείγματα από αυτά, ίσως από ένα περιβάλλον παραγωγής. Μπορεί επίσης να εξετάσετε γνωστές περιπτώσεις σφαλμάτων: ίσως ολόκληρος ο λόγος για τον οποίο ξεκινήσατε να γράφετε τη δεξιότητα είναι λόγω μιας συγκεκριμένης αποτυχίας που παρατηρήσατε ή ίσως κάνετε refactoring και υπάρχει κάποια σύγχυση σε δύο στενούς τομείς που καλύπτονται από μία δεξιότητα.

Ξεκινήστε με παρόμοια αρνητικά και θετικά παραδείγματα. Τα αρνητικά παραδείγματα είναι εξαιρετικά ισχυρά και μπορούν να έχουν μεγαλύτερη σημασία από τα θετικά παραδείγματα.

Βήμα 1: Η περιγραφή

Αυτή είναι η πιο δύσκολη γραμμή στη δεξιότητα. Είναι ένα ένασμα δρομολόγησης, όχι τεκμηρίωση. Για να πετύχετε το όνομα και την περιγραφή, δεν σας νοιάζει το περιεχόμενο της δεξιότητας. Σας νοιάζει μόνο αν η δεξιότητα φορτώνεται και εισάγεται στα σωστά σημεία και είναι απαλλαγμένη από παρενέργειες εκτός στόχου, η οποία είναι η κύρια λειτουργία αποτυχίας. Κάθε φορά που προσθέτετε μια επιπλέον δεξιότητα, διατρέχετε τον κίνδυνο να κάνετε κάθε άλλη δεξιότητα ελαφρώς χειρότερη, επομένως πρέπει να βεβαιωθείτε ότι ελαχιστοποιείτε την παλινδρόμηση.

Επαναλαμβάνω, μια κακή περιγραφή περιγράφει τι κάνει η δεξιότητα ή γιατί είναι χρήσιμη. Μια καλή περιγραφή λέει πότε ο πράκτορας πρέπει να φορτώσει τη δεξιότητα. Για παράδειγμα, ας υποθέσουμε ότι έχετε κάτι για την παρακολούθηση pull requests. Μην γράφετε τι κάνει η δεξιότητα. Γράψτε τι λένε οι μηχανικοί όταν είναι απογοητευμένοι και θέλουν να βεβαιωθείτε ότι το PR τους λειτουργεί, όπως "babysit" (επίβλεψη), "watch CI" (παρακολούθηση CI) ή "make sure this lands" (βεβαιώσου ότι θα περάσει).

Ακολουθεί μια γρήγορη λίστα ελέγχου:

Ξεκινά με "Load when..." (Φόρτωση όταν...)

Στόχος 50 λέξεις ή λιγότερες

Περιγράφει την πρόθεση του χρήστη, ιδανικά από πραγματικά ερωτήματα

Δεν συνοψίζει τη ροή εργασίας

Τα πραγματικά ερωτήματα είναι αυτά που μπορείτε να καλύψετε με έναν κανόνα 80-20. Συνήθως, δύο ή τρία παραδείγματα λειτουργούν καλά. Δεν είναι εύκολο να προσθέσετε ακριβώς και μόνο όσα χρειάζεστε.

Βήμα 2: Γράψτε το σώμα

Στη συνέχεια, γράψτε το περιεχόμενο της ίδιας της δεξιότητας. Σημειώστε ότι αυτό δεν είναι το Βήμα 0 ή το Βήμα 1.

Η επικοινωνία ροών εργασίας σε ένα LLM είναι εντελώς διαφορετική από την επικοινωνία ροών εργασίας σε έναν συνάδελφο, ή ακόμη και στο σύστημα χρόνου εκτέλεσης (runtime) σας. Κατά την εκμάθηση ενός νέου εργαλείου λογισμικού, ένας μηχανικός μπορεί να χρειαστεί να διαβάσει την τεκμηρίωση, να πάρει μια παρουσίαση (walkthrough) από κάποιον με εμπειρία και να μάθει πώς να χρησιμοποιεί το εργαλείο. Εν τω μεταξύ, για σχεδόν οποιοδήποτε εργαλείο λογισμικού που υπάρχει τουλάχιστον έναν χρόνο, απλώς αναφέρετε το όνομά του και το LLM έχει όλες τις πληροφορίες που χρειάζεται.

Όταν γράφετε το σώμα, παραλείψτε τα προφανή πράγματα. Πολλοί μηχανικοί έχουν άφθονη εμπειρία στη συγγραφή αρχείων readme.md που παραθέτουν κάθε εντολή που πρέπει να εκτελέσει κάποιος. Είναι εύκολο να καταφύγετε ξανά σε αυτό όταν γράφετε μια δεξιότητα επειδή αισθάνεστε ότι γράφετε τεκμηρίωση, αλλά αν το κάνετε αυτό, η δεξιότητά σας θα είναι άχρηστη. Επομένως, μην γράφετε μια σειρά από εντολές.

Για παράδειγμα, δεν χρειάζεται να γράψετε, “git log # find the commit; git checkout main; git checkout -b <clean-branch>; git cherry-pick <commit>;”

Αντίθετα, γράψτε, “Cherry-pick το commit σε έναν καθαρό κλάδο. Επιλύστε τις διενέξεις διατηρώντας την πρόθεση. Εάν δεν μπορεί να περάσει καθαρά, εξηγήστε γιατί.”

Το μοντέλο θα κάνει πολύ καλύτερη δουλειά με το δεύτερο παρά με την υπερβολικά προγραφική σειρά εντολών του πρώτου, ειδικά όταν τα πράγματα πηγαίνουν στραβά. Μην καταφεύγετε σε υπερβολικό έλεγχο ή να είστε υπερβολικά προγραφικοί, κάτι που είναι εύθραυστο, και αντί αυτού να είστε ευέλικτοι όπου μπορούν να λειτουργήσουν πολλαπλές προσεγγίσεις. Και πάλι, η καλή τεκμηρίωση για τους ανθρώπους είναι τις περισσότερες φορές κακή τεκμηρίωση για τα μοντέλα.

Στη συνέχεια, εστιώστε στα gotchas ή στα αρνητικά παραδείγματα. Αυτά αποτελούν περιεχόμενο εξαιρετικά υψηλού σήματος επειδή συχνά καθοδηγούν το μοντέλο ως προς το τι να μην κάνει. Εάν προσθέτετε μια γραμμή κάθε φορά που ο πράκτορας σκοντάφτει, θα μαθαίνετε εκτελώντας το και τα gotchas θα αυξάνονται οργανικά.

Τέλος, εάν υπάρχει οποιοδήποτε τμήμα που είναι υπό όρους ή εξαιρετικά βαρύ σε περιεχόμενο, αφαιρέστε το από το SKILL.md, το οποίο είναι ο κόμβος, και τοποθετήστε το σε μία από τις ακτίνες. Τοποθετήστε το σε ένα βοηθητικό αρχείο που μπορεί να φορτωθεί προοδευτικά, στο οποίο θα εμβαθύνουμε στη συνέχεια.

Βήμα 3: Χρησιμοποιήστε την ιεραρχία

Αξιοποιήστε την ιεραρχία δεξιοτήτων όταν έχετε ένα script, αναφορές ή χρησιμοποιείτε κάποιο συγκεκριμένο εργαλείο:

Προτεινόμενες χρήσεις για σενάρια, αναφορές, στοιχεία και ρυθμίσεις μέσα σε μια Δεξιότητα.

Για οτιδήποτε είναι υπό όρους ή διακλαδίζεται από τη βασική δεξιότητα, αποσπάστε το σε έναν φάκελο. Να θυμάστε επίσης ότι η πολυεπίπεδη ιεραρχία μπορεί να χρησιμοποιηθεί για ιδιαίτερα περίπλοκες δεξιότητες. Για αυτές, θα θέλετε να εξετάσετε προσεκτικά εάν η λειτουργικότητα πρέπει να υλοποιηθεί μονολιθικά ή ως συλλογή δεξιοτήτων (ίσως με σχέσεις φόρτωσης που βασίζονται στο depends:).

Βήμα 4: Επανάληψη

Στη συνέχεια, κάντε μια σειρά επαναλήψεων σε έναν κλάδο (branch). Ξεκινήστε στον κύριο κλάδο (main) χωρίς δεξιότητα, κάντε μερικές επαναλήψεις, δημιουργήστε το σύνολο ερωτημάτων-ορόσημων (hero query set) και εκτελέστε μια σειρά από evals. Όποιος επανεξετάζει τον κώδικα της δεξιότητάς σας θα σας ευχαριστήσει για την υποβολή μιας ενιαίας αλλαγής (changeset) πλήρους με ένα σύνολο αξιολόγησης. Η αναθεώρηση διαδοχικών σταδιακών αλλαγών (εκτός από ένα νέο gotcha) είναι πολύ δύσκολη, οπότε προσπαθήστε να την ελαχιστοποιήσετε.

Πιθανότατα θα κάνετε πολλές μικρές αλλαγές λέξεων. Οι μικρές αλλαγές λέξεων στις περιγραφές μπορούν να έχουν τεράστιο αντίκτυπο στη δρομολόγηση (συμπεριλαμβανομένων των επιπτώσεων διαρροής σε άλλες δεξιότητες), οπότε κάντε όλη αυτή τη δουλειά πριν από το Βήμα 5.

Βήμα 5: Αποστολή (Ship)

Στείλτε το.

Πώς να συντηρείτε μια δεξιότητα

Τώρα που γράψατε μια δεξιότητα, πρέπει να τη συντηρείτε.

Το σφόνδυλος των Gotchas (Gotchas Flywheel)

Από αυτό το σημείο και μετά, η λίστα των gotchas σας τείνει να αυξάνεται ή να αλλάζει πολύ. Συχνά βλέπουμε μηχανικούς που κάνουν PRs που δεν έχουν αξιολογηθεί, για παράδειγμα, αλλάζουν την περιγραφή. Εάν αλλάζετε την περιγραφή αφού έχει συγχωνευτεί η δεξιότητά σας, έχετε βγει εκτός πορείας. Εάν κάνετε αλλαγές στο στοιχείο που αποφασίζει αν θα δρομολογήσει τη δεξιότητά σας, πρέπει να γράψετε μερικά evals που υποστηρίζουν τις αλλαγές.

Οι δεξιότητες είναι κυρίως προσθηκτικές (append-mostly). Η ενότητα των gotchas συγκεντρώνει τη μεγαλύτερη αξία με την πάροδο του χρόνου:

Ο πράκτορας αποτυγχάνει σε κάτι → Προσθήκη ενός gotcha

Ο πράκτορας φορτώνει τη δεξιότητα εκτός στόχου → Συσφίξτε την περιγραφή και προσθέστε αρνητικά evals

Ο πράκτορας δεν φορτώνει τη δεξιότητα όταν θα έπρεπε → Προσθήκη λέξεων-κλειδιών και θετικών evals

Αλλαγές στο σύστημα prompt → Έλεγχος για σύγκρουση ή επανάληψη

Είναι εύκολο να εντοπίσετε μια μεμονωμένη περίπτωση αποτυχίας σε εσωτερικές δοκιμές ή στην παραγωγή και να προσθέσετε ένα gotcha. Είναι ένα αρνητικό παράδειγμα, οπότε δεν αλλάζει πραγματικά τη ρητή καθοδήγηση, αλλά επιτρέπει στο μοντέλο να γνωρίζει: «Γεια σου, υπάρχει αυτή η γνωστή αποτυχία».

Καθώς μεταβαίνετε από το 80-20 στην επίτευξη ποσοστού επιτυχίας 99,9% ή 99,99%, είναι εύκολο να μεγαλώσει αυτή η λίστα gotchas. Καθώς βλέπετε αυτά τα αρνητικά παραδείγματα, θα πρέπει να κάνετε προσθήκη κυρίως στην ενότητα των gotchas. Δεν πρέπει να προσθέτετε μεγαλύτερες οδηγίες ή να αλλάζετε την περιγραφή.

Σουίτες αξιολόγησης (Eval Suites)

Στο Perplexity, εκτελούμε πολλές σουίτες αξιολόγησης για να ελέγξουμε για διαφορετικά πράγματα. Υπάρχουν η φόρτωση δεξιοτήτων και η ανάγνωση αρχείων δεξιοτήτων, η οποία ελέγχει την ακρίβεια (precision), την ανάκληση (recall) και τους απαγορευμένους ελέγχους της ίδιας της φόρτωσης δεξιοτήτων. Θα δρομολογήσει ο πράκτορας τη δεξιότητά σας όταν υποτίθεται ότι πρέπει; Αυτά διασφαλίζουν ότι οι νέες δεξιότητες δεν παραβιάζουν τα υφιστάμενα όρια.

Υπάρχουν επίσης evals που μπορούν να ελέγξουν τη σωστή προοδευτική φόρτωση. Ο πράκτορας μπορεί να φορτώσει τη δεξιότητα, αλλά διαβάζει και το βοηθητικό αρχείο ή τα αρχεία; Για παράδειγμα, αν έχετε μια finance δεξιότητα για finance ερωτήματα, διαβάζει το ειδικό αρχείο FORMATTING.md;

Υπάρχουν επίσης evals για δεξιότητες που δοκιμάζουν την ολοκληρωμένη (end-to-end) ολοκλήρωση εργασιών εντός τομέων. Εκτελούμε τον πλήρη βρόχο πράκτορα και χρησιμοποιούμε έναν κριτή LLM για να βαθμολογήσουμε τα αποτελέσματα με βάση ένα σύνολο κριτηρίων (rubric) καλά καθορισμένων.

Τέλος, είναι σημαντικό να εκτελέσετε αυτά τα evals έναντι διαφορετικών μοντέλων. Το Computer υποστηρίζει τουλάχιστον τρεις διαφορετικές οικογένειες μοντέλων ενορχήστρωσης: GPT, Claude Opus και Claude Sonnet. Θέλετε να εκτελέσετε τη φόρτωση της δεξιότητάς σας και τις δεξιότητες τομέα έναντι αυτών των διαφορετικών ενορχηστρωτών πρακτόρων για να βεβαιωθείτε ότι δεν θα έχετε διαφορετική συμπεριφορά. Το Sonnet και το GPT συμπεριφέρονται αρκετά διαφορετικά όσον αφορά τις δεξιότητες.

Τελικές σκέψεις και βασικά συμπεράσματα

Όσο περισσότερες δεξιότητες χτίζετε, τόσο καλύτεροι θα γίνεστε στο να τις χτίζετε. Εάν δεν αυτοματοποιείτε ή δεν προσπαθείτε να κάνετε πιο αναπαραγώγιμες τις εργασίες που κάνετε σε καθημερινή βάση χρησιμοποιώντας δεξιότητες, ξεκινήστε αμέσως.

Η πράξη της κατασκευής δεξιοτήτων σάς κάνει καλύτερους στην κατασκευή περισσότερων δεξιοτήτων, αλλά επίσης, είναι εξαιρετικά καλές στην αυτοματοποίηση επιχειρηματικών διαδικασιών. Εάν μπορείτε να περιγράψετε κάτι που κάνετε κάθε εβδομάδα πριν από το standup σας, στο τέλος κάθε sprint, ή οτιδήποτε κάνετε ως μηχανικός σε καθημερινή, εβδομαδιαία ή ακόμη και τριμηνιαία βάση, θα πρέπει να γράφετε μια δεξιότητα για να κερδίσετε πίσω τον χρόνο σας.

Μπορείτε να αυτοματοποιήσετε τα postmortems; Μπορείτε να ελέγξετε pull requests; Για οποιαδήποτε εργασία μπορείτε να κάνετε, μπορείτε τουλάχιστον να έχετε το πρώτο πέρασμα να είναι ένα Agent Skill. Θα σας εξοικονομήσει σημαντικό χρόνο.

Τούτου λεχθέντος, να θυμάστε ότι μια δεξιότητα δεν είναι εύκολη ούτε καν πάντα απαραίτητη. Το λίγο είναι περισσότερο. Μερικά ακόμη βασικά συμπεράσματα:

Γράψτε evals πριν από τη δεξιότητα. Συμπεριλάβετε αρνητικά παραδείγματα και απαγορευμένες φορτώσεις για γειτονικές αλλά διακριτές δεξιότητες.

Η περιγραφή είναι το δύσκολο κομμάτι. "Load when..." (Φόρτωση όταν...) (κάθε λέξη κοστίζει προσοχή).

Τα gotchas είναι περιεχόμενο εξαιρετικά υψηλς αξίας. Ξεκινήστε λεπτοί, αναπτυχθείτε καθώς ο πράκτορας αποτυγχάνει.

Να θυμάστε ότι είναι εύκολο να σπάσετε άλλες προϋπάρχουσες δεξιότητες προσθέτοντας μια νέα δεξιότητα, παρόλο που δεν την αγγίξατε (προσοχή στη δράση από απόσταση).

Χρησιμοποιήστε όλα τα διαθέσιμα εργαλεία κάθε φορά που γράφετε και συντηρείτε μια δεξιότητα. Αν θέλετε να μάθετε περισσότερα, ο ιστότοπος 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}
}