מתי אסור להשתמש בסוכן AI

מה סוכן קונה לכם, ומה הוא גובה בתמורה

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

המדריך ההנדסי של Anthropic לבניית סוכנים מנסח את הפשרה בחדות: ״workflows offer predictability and consistency for well-defined tasks״ - תהליכים מובנים מספקים צפיוּת ועקביות למשימות מוגדרות היטב, וסוכן מתאים כשנדרשות גמישות והחלטה של המודל. ההמלצה שם מפורשת לא פחות: לחפש את הפתרון הפשוט ביותר ולהוסיף מורכבות רק כשהיא משתלמת - גם אם המשמעות היא לא לבנות סוכן כלל.

כשהתהליך דטרמיניסטי, סוכן רק מוסיף רעש

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

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

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

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

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

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

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

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

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

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

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

# הסיווג יושב בקוד, לא בפרומפט
auto:                 # הפיך וזול לתיקון
  - search_knowledge_base
  - create_draft_reply
  - add_internal_note

approve:              # מבוצע רק אחרי אישור אדם
  - send_customer_email
  - issue_refund
  - update_user_permissions

never:                # לא דרך סוכן, בשום מצב
  - delete_records
  - transfer_funds
  - change_billing_plan

limits:
  refund_max: 500              # מעל הסכום - תמיד אדם
  actions_per_run: 5           # חריגה עוצרת את הריצה
  on_repeated_failure: escalate_to_human

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

כשעלות התחזוקה גדולה מהחיסכון

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

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

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

כשזו בעיית נתונים שמתחפשת לבעיית AI

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

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

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

רשימת בדיקה לפני שבונים

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

1. אפשר לצייר את זה כתרשים זרימה?. אם כן, כתבו קוד. סוכן נדרש כשהמסלול אינו ידוע מראש, לא כשהוא ארוך.
2. מה קורה בטעות הגרועה ביותר?. אם התשובה כוללת כסף, נתונים שנמחקו או פגיעה באדם - נדרש שער אנושי בדיוק שם.
3. כמה פעמים בחודש זה קורה?. נפח נמוך לא מחזיר את עלות התחזוקה השוטפת; נפח גבוה מצדיק גם השקעה גדולה מראש.
4. איך נדע שזה נשבר?. אם הדרך היחידה לזהות תשובה שגויה היא תלונה של לקוח, אין בקרה - יש תקווה.
5. מי הבעלים בעוד שנה?. לסוכן בלי בעלים ברור אין מי שיעדכן אותו כשה-API ישתנה, והוא ייכשל בשקט.
6. האם הנתונים קיימים ונגישים?. אם לא, זה פרויקט נתונים ולא פרויקט AI. התחילו שם וחסכו סבב שלם.
7. האם חובה להסביר את ההחלטה?. דרישה להנמקה מחייבת לוגיקה שאפשר להצביע עליה, לא מסלול שנבחר בזמן ריצה.

ומתי כן

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

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

שאלות נפוצות

מה ההבדל בין אוטומציה רגילה לבין סוכן AI?

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

אפשר לגרום לסוכן להתנהג באופן דטרמיניסטי?

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

מותר להפעיל סוכן שמקבל החלטות על לקוחות?

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

מאיזה נפח משתלם לבנות סוכן?

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

מה עושים כשהסוכן מצליח כמעט תמיד?

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

אפשר להתחיל בלי סוכן ולהוסיף אותו בהמשך?

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