בקצרה

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

מה ההבדל בין סוכן, צ׳אט ותהליך אוטומטי?

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

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

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

איך מגדירים תפקיד שאפשר לבדוק?

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

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

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

איזה מידע וכלים נותנים לסוכן?

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

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

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

איך בודקים לפני חיבור ללקוחות?

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

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

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

מה עושים עם הוראות שמגיעות מבחוץ?

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

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

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

איך עוברים מניסיון להפעלה?

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

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

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

יש תהליך שרוצים להפוך לסוכן?

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

לבדיקת התאמה לשירותי AI