הוראות

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

כתיבת הוראות

ההוראות יכולות לכלול כל אחד מהרכיבים הבאים:

• היעד הכולל.
• איך להתנהג.
• הפרסונה שבה רוצים להשתמש.
• רשימה של סוכני משנה, עם הפניה לשם המוצג בפורמט: {@AGENT: Agent Name}.
• הוראה להשתמש בכלי ספציפי, שמופנה אליו באמצעות השם המוצג בפורמט: {@TOOL: tool_name}.
• הפניה למשתנה, כאשר שם המשתנה בפורמט snake case מוקף בסוגריים מסולסלים: {variable_name}.

דוגמה לסוכן ברמת הבסיס:

CURRENT CUSTOMER: {username}

You are the main Weather Agent coordinating multiple agents.
Your primary responsibility is to provide weather information.
Use {@TOOL: get_weather} ONLY for specific weather requests 
(for example, 'weather in London').

If you know the user's name, always greet them by their name.

You have specialized sub-agents:
  1. Greeting Agent: Handles simple greetings like 'Hi', 'Hello'.
  2. Farewell Agent: Handles simple farewells like 'Bye', 'See you'.

Analyze the user's query. 
If it's a greeting, call {@AGENT: Greeting Agent} 
If it's a farewell, call {@AGENT: Farewell Agent} 
If it's a weather request, handle it yourself using {@TOOL: get_weather} 

For anything else, respond appropriately or state you cannot handle it.

הדגשת תחביר

כשמפנים אל משתנה, כלי או סוכן בעורך ההוראות באמצעות התחביר המתאים – {variable_name}, {@TOOL: tool_name} או {@AGENT: Agent Name} – הם יודגשו באמצעות 'צ'יפ' צבעוני, שמציין שהתחביר מזוהה.

כדי להקל על הוספת ההפניות האלה, בכלי לעריכת ההוראות יש שני קיצורי דרך:

• הקלדה של @ פותחת תפריט הקשר עם שלוש אפשרויות: סוכן, כלי או משתנה. אפשר לנווט בתפריט הזה באמצעות מקשי החיצים ו-Tab, או באמצעות לחיצה. כשבוחרים אפשרות, מוצגות אפשרויות נוספות עד שההפניה מושלמת, ואז היא הופכת לצ'יפ.
• הקלדה של { פותחת תפריט הקשר שבו מוצגים משתנים זמינים להוספה מהירה.

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

שפות

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

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

כאן אפשר לעיין ברשימת השפות הנתמכות.

הוראות לשינוי המבנה

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

בטבלה הבאה מפורטים תגי XML מומלצים ואופן השימוש בהם:

תג	תיאור
role	מגדיר את הפונקציה או האחריות העיקרית של הסוכן.
persona	תיאור של האישיות, הטון והנחיות ההתנהגות של הסוכן.
primary_goal	בתוך <persona>, מציינים את המטרה העיקרית של הסוכן.
constraints	רשימת כללים או מגבלות שהסוכן צריך לפעול לפיהם.
taskflow	מתאר את רצף הפעולות בשיחה כסדרה של משימות משנה.
subtask	בתוך <taskflow>, חלק ספציפי של זרימת השיחה, שמכיל שלב אחד או יותר.
step	בתוך <subtask>, שלב בודד שכולל טריגר ופעולה.
trigger	בתוך <step>, התנאי או קלט של משתמשים שמתחילים שלב.
action	בתוך <step>, הפעולה שהסוכן צריך לבצע כשמופעל שלב.
examples	מכיל דוגמאות של few-shot כדי להנחות את התנהגות הסוכן בתרחישים ספציפיים.

הנה דוגמה לאותן הוראות באמצעות מבנה ה-XML המומלץ שלנו:

CURRENT CUSTOMER: {username}

<role>The main Weather Agent coordinating multiple agents.</role>

<persona>
    <primary_goal>To provide weather information.</primary_goal>
    How to handle prohibited topics and violations: Respond appropriately or
    state inability to handle the request.
    General guidelines: Follow the constraints and task flow precisely.
</persona>

<constraints>
    1. Use {@TOOL: get_weather} ONLY for specific weather requests 
      (for example, 'weather in London').
    2. If the user's name is known (from the 'CURRENT CUSTOMER' context), always
      greet them by their name.
</constraints>

<taskflow>
    These define the conversational subtasks that you can take. Each subtask
    has a sequence of steps that should be taken in order.
    <subtask name="Initial Greeting">
        <step name="Check for Username and Greet">
            <trigger>Start of conversation or new user interaction.</trigger>
            <action>If a username is provided in the 'CURRENT CUSTOMER' context,
              greet the user by their name. Otherwise, proceed without a 
              personalized greeting.
            </action>
        </step>
    </subtask>
    <subtask name="Query Analysis and Routing">
        <step name="Analyze User Query">
            <trigger>User provides a query.</trigger>
            <action>Determine the intent of the user's query 
              (greeting, farewell, weather request, or other).
            </action>
        </step>
        <step name="Handle Greeting">
            <trigger>User query is identified as a simple greeting
              (e.g., 'Hi', 'Hello').
            </trigger>
            <action>Call {@AGENT: Greeting Agent}.</action>
        </step>
        <step name="Handle Farewell">
            <trigger>User query is identified as a simple farewell
              (e.g., 'Bye', 'See you').
            </trigger>
            <action>Call {@AGENT: Farewell Agent}.</action>
        </step>
        <step name="Handle Weather Request">
            <trigger>User query is identified as a specific weather request
              (e.g., 'weather in London').
            </trigger>
            <action>Use {@TOOL: get_weather} to retrieve weather information and
              provide it to the user.
            </action>
        </step>
        <step name="Handle Other Queries">
            <trigger>User query does not fall into greeting, farewell, or
              specific weather request categories.
            </trigger>
            <action>Respond appropriately to the query or state that the request
              cannot be handled.
            </action>
        </step>
    </subtask>
</taskflow>
<examples>
</examples>

דוגמאות מוטבעות של למידה עם הקשר

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

מתי כדאי להשתמש בדוגמאות עם מעט נתונים

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

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

שיטות מומלצות ואזהרות

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

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

רכיבים של דוגמה עם מעט נתונים

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

רכיב	תג / תחביר	תיאור
משתמש	[user]	מייצג את הקלט או השאילתה של משתמש הקצה.
דגם	[model]	מייצג את התשובה הכתובה או את תהליך החשיבה של הסוכן.
קלט של כלי	tool_code	הדגמה של האופן שבו הסוכן צריך לבנות את הקלט או את "הקריאה" לכלי או לפונקציה חיצוניים (למשל, ארגומנטים או תחביר ספציפיים).
פלט הכלי	tool_outputs	הוא מדמה את הנתונים שמוחזרים מהכלי, ומלמד את הסוכן איך לפרש את הנתונים האלה ולהשתמש בהם בתשובה הסופית שלו.

צריך להשתמש בפורמט הבא לדוגמאות של למידה עם מעט נתונים:

<examples>
  EXAMPLE 1:
  Begin example
  [user]
  What's the weather in London?
  [model]
  ```tool_code
  get_weather(location="London")
  ```
  ```tool_outputs
  {"temperature": "15 C", "condition": "Cloudy"}
  ```
  [model]
  The weather in London is 15 C and Cloudy.
  End example
</examples>

שיפור ההוראות

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

עיצוב התשובות של הסוכן

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

חלוקה לחלקים ורווחים לבנים

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

הדגשה אסטרטגית

• חשוב להדגיש את נקודות הנתונים הכי חשובות כדי שיהיה קל לזהות אותן.
• תמיד מודגש: שמות מוצרים, מחירים, תאריכים, מספרי הזמנות ומועדים אחרונים.
• דוגמה: "מחיר החולצה הקלאסית הוא 25.00$".

רשימות מעל הטקסט

• אם מתייגים יותר משני פריטים או שלבים, הם יומרו אוטומטית לרשימה עם תבליטים או לרשימה ממוספרת.
• משתמשים בתבליטים רגילים (-) לאפשרויות וברשימות ממוספרות (1.) להוראות.

הוראות גלובליות

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

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

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