ניהול מחזור החיים של סוכני בינה מלאכותית בקנה מידה רחב

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

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

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

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

מדוע סוכן אינו עוד יישום תוכנה

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

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

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

ניהול מחזור החיים של סוכני בינה מלאכותית מתחיל בהגדרת הסמכות

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

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

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

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

לפני הארכיטקטורה: האם בכלל צריך סוכן?

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

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

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

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

הרשאות: לא להסתפק בהנחיה למודל

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

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

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

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

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

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

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

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

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

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

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

ניטור שמאפשר לשחזר מה קרה

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

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

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

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

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

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

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

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

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

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

ממשל, זיכרון וסיום מחזור החיים

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

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

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

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

סיכום: מה צריך לנהל בכל שלב

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

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

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