עיצוב, שכלול ותחזוקה של כישורי סוכן ב-Perplexity

מוצרי סוכני החזית של Perplexity מבוססים על יסודות של ידע ומומחיות בתחום המאוגדים ב-כישורי סוכן מודולריים. אנו מתחזקים ספרייה שנבחרה בקפידה של כישורים בסביבות הטכנולוגיות שלנו. כישורים אלו כוללים רבות מהתשתיות הכלליות המניעות את Perplexity Computer; יכולות ספציפיות לתחומים כמו פיננסים, משפטים ובריאות; ואינסוף מודולים לטיפול בצרכי המשתמש. חלק מהכישורים מופעלים לעתים רחוקות אך קריטיים כשהם מופעלים. כדי להבטיח חוויית משתמש מצוינת בעקביות, צוות הסוכנים של Perplexity מעניק עדיפות לאיכות הכישור בדיוק כמו לאיכות הקוד.

התפיסות והשיטות המומלצות הנדרשות לפיתוח כישור באיכות גבוהה שונות משמעותית מאלו הנדרשות לבניית תוכנה מסורתית. צוות הסוכנים בורר בקשות משיכה רבות מצד מהנדסים מצוינים המפתחים כישורים במהלך עבודתם. התוצאה היא כמעט תמיד הערות והצעות רבות לתיקון. הסיבה לכך היא שדפוסים שימושיים רבים לכתיבת קוד הופכים לדפוסים שליליים ביצירת כישורים.

לדוגמה, אם ניקח כמה מהאמרות מתוך PEP20 – הסגנון של פייתון, יתברר במהירות שכתיבת קוד Python טוב שונה מכתיבת כישורים טובים. מתוך 20 שורות החוכמה, לפחות מחציתן שגויות לחלוטין או מטעות באופן פעיל בעת כתיבת כישורים. הנה חמש מהן:

חמשה ניגודים בין הזן של Python לבין ההנחיות של המאמר לכתיבת Skills.

מדריך זה הוא המסמך שמהנדסים ברחבי Perplexity משתמשים בו בעת פיתוח וסקירה של כישורים. אנו משחררים מדריך זה לציבור כדי שהתגליות והתובנות שלנו יוכלו להביא תועלת לקהילה הרחבה יותר. בין אם אתה מהנדס המעצב כישורי ייצור בעבודה היומיומית שלך, משתמש Computer המבקש לפתח כישור משלך בתחום שאתה מכיר היטב, או שניהם, מדריך זה מיועד לך.

מהו כישור?

כשאתה כותב כישור, אינך כותב תוכנה ישנה ורגילה (למרות שכישורים מהווים כעת חלק ממנועי הליבה הלוגיים עבור מערכות סוכנים). במקום זאת, אתה בונה הקשר עבור מודלים והסביבות שלהם. לכישור יש מגבלות שונות ועקרונות עיצוב שונים. אם תכתוב כישור כמו שאתה כותב קוד, תיכשל.

כישור הוא לפחות ארבעה דברים, במיוחד בהקשר של האופן שבו אנו בונים אותם ב-Perplexity.

כישור הוא ספריה

כישור אינו רק קובץ SKILL.md יחיד. במקרים רבים, כישור כולל מספר קבצים. תחת הספריה הקרויה על שם הכישור שלך, עשויים להיות לך:

SKILL.md: חומר קדמי והוראות

scripts/: קוד שהסוכן מריץ, ולא ממציא מחדש

references/: מסמכים כבדים, נטענים על תנאי

assets/: תבניות, סכמות ונתונים

config.json: הגדרת משתמש בהפעלה ראשונה

דפוס מרכזי-חישורים זה מאפשר לך לשמור על מיקוד והדוקות רבה בכישורים, ואפשר להשתמש במבנה התיקיות בצורה יצירתית ביותר. לעתים, כישורים מורכבים במיוחד מרוויחים ממספר רמות של היררכיה כדי לעזור למודל לנווט טוב יותר. נניח שכישור דורש ידע על פני 300 נושאים, הניתנים לקיבוץ ל-20 תחומי תוכן. בחירה אמינה של הנושא הנכון מתוך 300 היא אתגר לא פתור אפילו עבור מיטב מודלי החזית של ימינו. זוהי בעיית בחירה קלה בהרבה עבור מודל להתמקד באחד מתוך 20 אזורים, מאשר בין 15 הנושאים באותו אזור.

כדוגמה אחת לאופן שבו היררכיה רב-ממדית מספקת ערך, הצוות שלנו השתמש בשלוש רמות של קינון תחומי בתוך הכישורים שהניעו את יכולות מס הכנסה בארה"ב של Computer בעונת המס האחרונה. היררכיה זו הייתה חיונית בהחלט בהתחשב במורכבות דיני המס: בבדיקות המוקדמות שלנו, הצגת תיקייה יחידה המכילה את כל 1,945 הסעיפים של קוד המס הפנימי של ארה"ב למודל הביאה לביצועים גרועים יותר מאשר אי טעינת הכישור כלל. ארגון המידע לחלוקות משנה לוגיות היה חיוני הבטחת פעולות קריאה בדיוק גבוה.

אבל ההיררכיה הזו לא באה בחינם. רמות גבוהות יותר של היררכיה דורשות רמות גבוהות יותר של עריכה לאורך ארכיטקטורת המידע כדי לנהל את העקיפה הנוצרת. פיתחנו מדריכי עזר מהירים, כלי חיפוש מותאמים אישית וכלים אחרים כדי לתמוך במודל באיתור מידע במינימום עקיפה. במקרה הזה, עשיית עבודת העריכה הקשה יצרה בסופו של דבר תוצאה חיובית: כישור שאפשר למודלים לבצע משימות הקשורות למסים בצורה הרבה יותר טובה מאשר שימוש בכלים כלליים בלבד.

הגדלה

כישור הוא פורמט

כישור הוא פורמט. קובץ השורש המרכזי SKILL.md חייב לכלול גם שם וגם תיאור. יתר על כן, הכישור צריך להתאים בדיוק לשם הספריה שבה הכישור ממוקם. הש שם חייב להיות כולו אותיות קטנות, ללא רווחים, ויכול להשתמש במקפים. התיאור הוא טריגר הניתוב. זוהי נקודת כשל נפוצה: התיאור אינו תיעוד פנימי של מה שהכישור עושה. הוא שקול להוראות עבור המודל לגבי מתי לטעון את הכישור. לכן, תראה תכופות "טען כאשר", ולא "כישור זה עושה". זה חשוב בגלל האופן שבו רוב היישומים מטמיעים את התיאור בהקשר של המודל.

בתוך החומר הקדמי, יש גם "depends:", המאפשר לך ליצור תלויות כישורים היררכיות, ו-"metadata:", המשמש לסקירות והערכות. מערכות סוכנים שונות יכולות אפילו להגדיר שדות חומר קדמי משל עצמן, לשימוש באופן ספציפי למערכות אלו. כחלופה, ניתן לארוז מטא-נתונים ספציפיים לכישור בקובץ תצורה עזר מסוג JSON או YAML. הדבר רצוי בעת בניית מערכות סוכנים שצריכות להקל על סוגים שונים של התנהגות זמן ריצה לכל כישור מבלי לזהם את ההקשר של המודל בפרטים קטנים. לבסוף, התנהגות דומה ניתנת להשגה באמצעות הפשטת חומר קדמי של כישור בעת קריאה. Computer משתמש במתודולוגיה זו, המאפשרת לשמור על התצורה בקובץ השורש SKILL.md. תשומת לב קפדנית לפרטים נדרשת בלוגיקת הניתוח, וייתכן שתרצה ליישם הפשטה מותנית אם ישנם שדות מסוימים ששימושי שיהיו בתוך ההקשר של המודל.

כישור ניתן להפעלה

כישור ניתנת להפעלה. הסוכן טוען כישור בזמן ריצה. חשוב לציין שכישורים אינם מקובצים תמיד בהקשר. כברירת מחדל, רוב מערכות הסוכנים פותחות כישורים באופן הדרגתי לפי צורך ספציפי.

ישנן לפחות שלוש רמות של עלויות הקשר באופן שיישמנו כישורים ב-Computer. הנה התהליך:

Computer קורא ל-load_skill(name="...")

Computer מעתיק את ספרית הכישור לתוך ארגז חול הביצוע המבודד

Computer טוען אוטומטית באופן רקורסיבי תלויות בתגית "depends:"

Computer לאחר מכן מפשיט את החומר הקדמי ולכן הסוכן רואה רק את גוף הטקסט ואת הקבצים הנוספים

מערכות סוכנים שונות יכולות לבחור לחשוף תוכן כישור בדרכים שונות. כדוגמה, מערכות מסוימות עשויות לבחור שלא לחשוף את היררכיית הקבצים כלל, ולהשאיר למודל לגלות את ההיררכיה באמצעות פעולות מערכת קבצים. מערכות אחרות עשויות לבחור לתת למודל מיפוי של עץ הקבצים המלא עד לסף קיצוב ו/או עומק מסוים. כדי לשמור על הקשר נקי, Computer משמיט היררכיות קבצים מלאות מהקשר ההפעלה; עם זאת, ניתן לעקוף זאת על בסיס כל כישור בנפרד.

כישור הוא הדרגתי

כישורים הם הדרגתיים. ב-Computer, ישנן שלוש רמות שונות של עלויות הקשר, ואנו נושאים בכל השלוש בשלבים שונים:

שלושת הרמות של הקשר Skill: אינדקס, טעינה מלאה של ה-Skill וקובצי עזר בזמן ריצה.

Computer בונה אינדקס כישורים הכולל את השם והתיאור עבור כל כישור זמין. התקציב לכך הוא סביב 100 אסימונים לכל כישור (קצר יותר טוב אף יותר). זה כל כך הדוק כי אתה משלם עלות זו בכל הפעלה, עבור כל משתמש. זה מוזרק להנחיית המערכת בתחילת השיחה. למודל יש גישה לשורה של כישורים ששמם ידוע ותיאורים כדי שיוכל להחליט האם לקרוא ל-"load_skill()". הסף לכניסה לאינדקס זה גבוה קיצונית. הכישור שלך צריך להיות שימושי מאוד, והתיאור צריך להיות צפוף ותמציתי במיוחד כי כולם משלמים את העלות כל הזמן.

לאחר שמערכת הסוכנים טוענת את הכישור, ישנו גוף ה-SKILL.md המלא. באופן אידיאלי, טקסט הגוף אינו עולה על 5,000 אסימונים. גם אז, אתה רוצה שכל משפט יהיה חשוב כי ברגע שאתה טוען כישור, שאר השיחה חייבת לשלם את העלות הזו עד שתגיע לגבול הדחיסה. שרשורים רבים טוענים בכל מקום בין שלושה לחמישה כישורים שונים, ומשכפלים עלות זו. כישורים עם הרבה תוספות מיותרות יפגעו כמעט בוודאות בכישורים אחרים וכן ביכולות הסוכנות הכוללות. בקיצור, אם הכישור שלך נטען והוא אינו עושה את הדבר הנכון, מדובר בהקשר מבזבז.

רמת ההתקדמות האחרונה היא סקריפטים או מקרים מיוחדים, כמו כישורי משנה או עיצוב. כאן תרצה למקם לוגיקה מסועפת מותנית בלתי מוגבלת. הסוכן ישתמש בה רק כאשר יזדקק לכך, כלומר יש רף נמוך בהרבה עבור מה שתרצה לשים כאן.

באינדקס, כל אסימון הוא חשוב. גוף הכישור הטעון משוחרר יותר, וזמן הריצה הוא המשוחרר ביותר. זה עשוי להיות 20,000 אסימונים או אפס אסימונים. זוהי הרמה שבה תוכל לחשוב על הרחבת ההקשר של המודל בצורה הדרגתית.

מתי אתה צריך כישור?

צוות הסוכנים נשאל לעיתים קרובות האם כישור באמת נחוץ עבור תחום או מקרה שימוש מסוים. רק לעיתים נדירות יש לנו תשובה חד-משמעית מעקרונות ראשונים בלבד. הדרך היחידה באמת להבין זאת היא להתחיל עם הסוכן שלכם בלי הכישור, להריץ כמה שאילתות מפתח, ואז להבין אם הסוכן עושה עבודה טובה.

מתי אתה צריך כישור

ישנן משימות רבות המצויות בהפצה עבור מודלים מאומנים. עליך להחיל כישור רק אם ברצונך לשנות התנהגות זו בצורה מסוימת שאינך יכול לעשות, למשל, באמצעות משפט אחד בהנחיה שלך. לכן, אתה זקוק לכישור כאשר הסוכן יטעה בלעדיו ללא הקשר מיוחד, או אם יש אי-עקביות או אי-דטרמיניזם שאתה צריך שיהיו עקביים במיוחד על פני הרצות.

ייתכן שהידע שלך עמיד אך אינו נמצא בנתוני האימון. ייתכן שישנם תאריכי סיום או תהליכי עבודה ספציפיים לארגון, או שזה עניין של טעם. לדוגמה, יש לנו מספר כישורים הקשורים לעיצוב ב-Computer שנכתבו על ידי הנרי מודיסט (ראש מחלקת העיצוב שלנו). הסיבה לכך שכל אסימון קיים בכישורים אלו היא שלנרי יש טעם טוב מאוד בכל הנוגע לעיצוב אתרי אינטרנט וקובצי PDF. הנרי מציין אילו גופנים להשתמש ואילו גופנים לא להשתמש, כיצד הגופנים הללו מרגישים, וענייני שיקול דעת אחרים שהמודל אינו יכול ללמוד מנתוני אימון לבדם.

מתי אינך צריך כישור

אנו רואים כישורים רבים שבהם מהנדסים כתבו שורה של פקודות git שצריך לבצע לפי סדר. זה מיותר כי המודל כבר יודע כיצד לעשות זאת, כלומר זה יוצר תיעוד מצוין אבל כישור גרוע.

אנחנו רואים דוגמאות שבהן כישורים משחזרים הוראות מהפרומפט של המערכת. לא צריך כישור בשביל זה. ידע שרלוונטי לרוב הבקשות צריך להיכלל בהקשר הגלובלי, לא בכישור שניטען בתנאים מסוימים

אם יש משהו שמשתנה מהר יותר ממה שאתה יכול לתחזק אותו, אינך צריך כישור. לדוגמה, אם אתה פוגע בנקודת קצה של MCP מרוחקת והכלים שלה או הגרסאות של כלים אלו משתנים בתדירות גבוהה, אל תזריק אותם לתוך כישור. אם תעשה זאת, פשוט תסיים עם סחיפה והמודל יעשה טעויות.

כל כישור הוא מס

הנה מבחן שימושי שתוכל להחיל על כל משפט בכישור שלך: "האם הסוכן היה טועה לגבי זה ללא הוראה זו?" אם המשפט אינו צריך להיות שם, הוא אינו יכולרשות לעצמו להיות שם כי כולם משלמים עלות זו בכל פעם מחדש. כאשר אתה מחליט האם להוסיף כישור או לא, זכור מס זה שבו כל הפעלה וכל משתמש עולים באסימונים.

הציטוט המפורסם הבא, שנשמע הרבה יותר טוב בצרפתית, מתורגם בקירוב ל־"כתבתי את המכתב הזה ארוך יותר רק משום שלא היה לי זמן לקצר אותו."

« Je n’ai fait celle-ci plus longue que parce que je n’ai pas eu le loisir de la faire plus courte. » — בלז פסקל, מכתבים פרובינציאליים, 1657

בדיוק כמו פסקל, עליך להשקיע זמן בכל כישור. קשה לכתוב כישור קצר. אם הכישור שלך קל לכתיבה, סביר להניח שהוא ארוך מדי או שאינו אמור להתקיים. כישור טוב הוא קצר ככל האפשר.

אם אתם מוצאים את עצמכם מנסים ליצור כישור במכה אחת ולהגיש PR-ים בתוך חמש דקות, התוצאות כמעט בוודאות יהיו נחותות. למעשה, מחקר מוקדם הראה שאם אתם משתמשים ב-LLMs כדי לכתוב כישורים, סביר שה-LLM לא יפיק מזה תועלת: "כישורים שנוצרו על ידי המודל עצמו אינם מספקים תועלת בממוצע, מה שמראה שמודלים אינם יכולים לאחזר באופן אמין את הידע הפרוצדורלי שהם מפיקים ממנו תועלת כשהם צורכים אותו."

כיצד לבנות כישור

במילים אחרות, עליך להזריק את דעתך לתוך כל כישור שאתה כותב. פעל לפי השלבים הבאים.

שלב 0: כתיבת ההערכות (Evals)

כתוב תחילה חלק מההערכות. אתה יכול לקבל מקור למקרי הערכה מתוך:

שאילתות משתמש אמיתיות: דגימה מסביבת הייצור או ממעגל המומחים שלך

כשלים ידועים: הסוכן נכשל מכיוון שהכישור לא היה קיים

בלבול שכנים: קרוב לגבול התחום שלך אך מנותב לכישור אחר

לכל הפחות, כדאי לוודא שאתם בודקים שהכישור נטען כשצריך. עדיף אפילו לדגום כמה כאלה, אולי מסביבת ייצור. אפשר גם לשקול מקרי שגיאה ידועים: אולי כל הסיבה שהתחלתם לכתוב את הכישור היא כשל ספציפי שזיהיתם, או שאולי אתם מבצעים ריפקטורינג ויש בלבול בין שני תחומים קרובים שמכוסים על ידי כישור אחד.

התחל בדוגמאות שליליות וחיוביות דומות. דוגמאות שליליות הן עוצמתיות ביותר ויכולות להיות בעלות חשיבות רבה יותר מדוגמאות חיוביות.

שלב 1: התיאור

זוהי השורה הקשה ביותר בכישור. זהו טריגר ניתוב, לא תיעוד. כדי לדייק בשם ובתיאור, אכפת לך מעט מאוד מתוכן הכישור. אכפת לך רק האם הכישור נטען ומוזרק בנקודות הנכונות והוא נקי מתופעות לוואי חורגות מהיעד, שהן מצב הכשל מספר אחת. בכל פעם שאתה מוסיף כישור נוסף, אתה מסתכן בהפיכת כל כישור אחר לגרוע קלות, כך שעליך לוודא שאתה מצמצם את הרגרסיה ככל האפשר.

שוב, תיאור גרוע מתאר את מה שהכישור עושה או מדוע הוא שימושי. תיאור טוב אומר מתי על הסוכן לטעון את הכישור. לדוגמה, נניח שיש לך משהו לניטור בקשות משיכה. אל תכתוב מה הכישור עושה. כתוב מה מהנדסים אומרים כשהם מתוסכלים והם רוצים שתוודא שבקשת המשיכה (PR) שלהם עובדת, כמו "שמרטף" (babysit) או "צפה ב-CI" או "וודא שזה מגיע ליעדו".

הנה רשימת בדיקה מהירה:

מתחיל ב-"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>;"

במקום זאת, כתוב: "בצע Cherry-pick לקומיט על גבי ענף נקי. פתור קונפליקטים תוך שמירה על הכוונה. אם הוא לא יכול לנחות בצורה נקייה, הסבר מדוע."

המודל יעשה עבודה טובה הרבה יותר עם האחרון מאשר עם רצף הפקודות המרשמי מדי של הראשון, במיוחד כאשר דברים משתובבים. אל תכתיב בקו קשיח, או תהיה מרשמי מדי, מה ששביר, ובמקום זאת היה גמיש כאשר גישות מרובות יכולות לעבוד. שוב, תיעוד טוב לבני אדם הוא לרוב הגדול תיעוד גרוע למודלים.

לאחר מכן, התמקד במלכודות או בדוגמאות שליליות. אלו הם תכנים בעלי אותות גבוהים במיוחד מפני שהם מנחים לרוב את המודל מבחינת מה לא לעשות. אם תוסיף שורה בכל פעם שהסוכן מועד, תלמד על ידי הרצה שלה והמלכודות יגדלו באופן אורגני.

לבסוף, אם יש חלק כלשהו המותנה או כבד מאוד בתוכן, הוצא אותו מה-SKILL.md, שהוא הרכזת (hub), ושום אותו באחת מהשלוחות (spokes). שום אותו בקובץ עזר שניתן לטעון באופן הדרגתי, שאליו ניכנס לעומק בהמשך.

שלב 3: שימוש בהיררכיה

נצל את היררכיית הכישורים כאשר יש לך סקריפט, הפניות, או שאתה משתמש בכלי מסוים:

שימושים מומלצים בסקריפטים, חומרי עזר, נכסים ותצורה בתוך Skill.

לכל דבר שהוא מותני או מסועף מהכישור הראשי, פרק אותו החוצה לתיקייה. זכור גם שהיררכיה רב-ממדית ניתנת לשימוש עבור כישורים מורכבים במיוחד. עבור אלו, תרצה להקדיש מחשבה מדוקדקת האם הפונקציונליות צריכה להיות מיושמת בצורה מונוליתית או כאוסף של כישורים (אולי עם קשרי טעינה מבוססי depends:).

שלב 4: ביצוע איטרציות

לאחר מכן, בצע שורה של איטרציות על גבי ענף. התחל בענף הראשי ללא כישור, בצע כמה איטרציות, בנה את קבוצת שאילתות הגיבור שלך, והרץ שורה של הערכות. כל מי שיסקור את קוד הכישור שלך יודה לך על הגשת שינוי יחיד (changeset) השלם עם ערכת הערכה. סקירת שינויים עוקבים מצטברים (למעט מלכודת חדשה) היא קשה מאוד, לכן נסה לצמצם זאת.

סביר להניח שתבצע שינויי מילים קטנים רבים. שינויי מילים קטנים בתיאורים עשויים להיות בעלי השפעה חריגה על הניתוב (כולל השפעות זליגה על כישורים אחרים), לכן בצע את כל העבודה הזו לפני שלב 5.

שלב 5: משלוח

שגר את זה.

כיצד לתחזק כישור

עכשיו שכתבת כישור, עליך לתחזק אותו.

גלגל התנופה של המלכודות

מנקודה זו ואילך, רשימת הבעיות האפשריות שלכם נוטה לגדול או להשתנות הרבה. אנחנו רואים לעיתים קרובות מהנדסים שמגישים PR-ים שלא עברו eval, למשל, ומשנים את התיאור. אם אתם משנים את התיאור אחרי שהכישור שלכם מוזג, אתם בדרך הלא נכונה. אם אתם מבצעים שינויים בדבר שקובע אם לנתב את הכישור שלכם, אתם צריכים לכתוב כמה evals שתומכים בשינויים.

כישורים הם ברובם מצורפים (append-mostly). סעיף המלכודות צובר את הערך הרב ביותר לאורך זמן:

הסוכן נכשל במשהו ← הוסף מלכודת

הסוכן טוען את הכישור מחוץ ליעד ← הדק את התיאור והוסף הערכות שליליות

הסוכן אינו טוען את הכישור כאשר עליו לעשות זאת ← הוסף מילות מפתח והערכות חיוביות

הנחיית המערכת משתנה ← בדוק אם יש התנגשות או כפילות

קל לשים לב למקרה כשל יחיד בבדיקות פנימיות או בסביבת ייצור ולהוסיף מלכודת. זוהי דוגמה שלילית כך שהיא אינה משנה באמת הנחיה מפורשת, אך היא מאפשרת למודל לדעת, "היי, ישנו כשל ידוע זה."

כאשר אתה עובר מטווח 80-20 להשגת שיעור הצלחה של 99.9% או 99.99%, קל להצמיח רשימת מלכודות זו. כאשר אתה רואה דוגמאות שליליות אלו, עליך לצרף בעיקר לסעיף המלכודות. אין עליך להוסיף הוראות ארוכות יותר או לשנות את התיאור.

חבילות הערכה (Eval Suites)

ב-Perplexity, אנו מריצים חבילות הערכה רבות כדי לבדוק דברים שונים. קיימות טעינת כישור וקריאות קובצי כישור, מה שבודק את הדיוק, השליפה (recall) ובדיקות האיסור של טעינת הכישור עצמו. האם הסוכן ינתב את הכישור שלך כאשר הוא אמור לעשות זאת? אלו מבטיחים שכישורים חדשים אינם פוגעים בגבולות קיימים.

ישנן גם הערכות שיכולות לבדוק טעינה הדרגתית נאותה. הסוכן עשוי לטעון את הכישור, אך האם הוא קורא את קובץ או קבצי העזר? לדוגמה, אם יש לך כישור פיננסי עבור שאילתות פיננסיות, האם הוא קורא את קובץ ה-FORMATTING.md המיוחד?

ישנן גם הערכות לכישורים המבודקות השלמת משימות מקצה לקצה בתוך תחומים. אנו מריצים את לולאת הסוכן המלאה ומשתמשים בשופט LLM כדי לדרג את התוצאות בהתססה על מתווה של קריטריונים מוגדרים היטב.

לבסוף, חשוב להריץ הערכות אלו מול מודלים שונים. Computer תומך לפחות בשלוש משפחות מודלי תזמור שונות: GPT, Claude Opus ו-Claude Sonnet. אתה רוצה להריץ את טעינת הכישור ואת כישורי התחום מול מתזמני סוכנים שונים אלו כדי לוודא שאינך מקבל התנהגות שונה. Sonnet ו-GPT מתנהגים באופן שונה למדי בכל הנוגע לכישורים.

מחשבות אחרונות ותובנות מרכזיות

ככל שתבנה יותר כישורים, כך תשתפר בבנייתם. אם אינך ממתין או מנסה להפוך משימות שאתה עושה על בסיס יומי לניתנות לשחזור באמצעות כישורים, התחל מיד.

פעולת בניית הכישורים הופכת אותך לטוב יותר בבניית כישורים נוספים, אך בנוסף, הם טובים במיוחד באוטומציה של תהליכים עסקיים. אם אתה יכול לתאר משהו שאתה עושה מדי שבוע לפני פגישת העדכון (standup), בסוף כל ספרינט, או כל דבר שאתה עושה כמהנדס על בסיס יומי, שבועי או אפילו רבעוני, עליך לכתוב כישור כדי לקנות בחזרה את הזמן שלך.

האם אתה יכול להפוך ניתוחי לאחר מוות (postmortems) לאוטומטיים? האם אתה יכול לסקור בקשות משיכה (PR)? כל משימה שאתה יכול לעשות, אתה יכול לפחות לגרום למעבר הראשון להיות כישור סוכן. זה יחסוך לך זמן ניכר.

עם זאת, זכור שכישור אינו קל או אפילו הכרחי תמיד. פחות זה יותר. עוד כמה תובנות מרכזיות:

כתוב הערכות לפני הכישור. כלול דוגמאות שליליות וטעינות אסורות עבור כישורים סמוכים אך נבדלים.

התיאור הוא החלק הקשה. "Load when..." (כל מילה עולה בתשומת לב).

מלכודות הן תוכן בעל ערך גבוה במיוחד. התחל דק, גדל כשהסוכן נכשל.

זכור שקל לשבור כישורים קודמים קיימים על ידי הוספת כישור חדש, למרות שלא נגעת בו (היזהר מפעולה ממרחק).

השתמש בכל הכלים הזמינים בכל פעם שאתה כותב ומתחזק כישור. אם ברצונך ללמוד עוד, אתר כישורי סוכן כולל שפע של דוגמאות טובות, וגם המאגר הפנימי שלנו וגם האקולוגיה הציבורית מכילים דוגמאות רבות לכישורים מעוצבים היטב.

ציטוט

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