Copilot Studio או Vertex AI Agent Builder: האקוסיסטם קובע לפני המחיר

כדי לבחור פלטפורמה לסוכן AI עסקי, התחילו במשימה שהסוכן אמור להשלים ובמערכות שבהן נמצאים המידע והמשתמשים. Copilot Studio מתאים לבחינה ראשונה כשהעבודה כבר מתנהלת ב־Microsoft 365 וב־Power Platform; המסלול של Vertex AI Agent Builder מתאים לבחינה כשצוות הפיתוח מנהל נתונים וסוכנים ב־Google Cloud. החיבור לתהליך הקיים חשוב יותר ממחיר הכניסה לבדו.

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

מה מקבלים בכל סביבת עבודה

בעסק שכבר משתמש ב־Microsoft 365, נקודת המוצא היא זהויות המשתמשים, התוכן והעבודה שכבר מתנהלים שם. לפי תמחור Copilot Studio של Microsoft, אפשר לשלב מחברי Power Platform ולפרסם סוכנים בתוך Microsoft 365 או בערוצים חיצוניים באמצעות המסלול העצמאי; חבילת 25,000 Copilot Credits מוצגת ב־200 דולר לחודש, וצריכת הקרדיטים משתנה לפי הפעולה או התגובה. מוצעת גם אפשרות חיוב לפי שימוש. זהו מחיר החבילה המוצג באתר האמריקאי, ולא חישוב של עלות שירות לעסק בישראל.

בצד Google חשוב לדייק בשם המוצר: תיעוד Gemini Enterprise Agent Platform מציג את הפלטפורמה כהתפתחות של Vertex AI וכולל בנייה חזותית באמצעות Agent Studio, פיתוח בקוד באמצעות Agent Development Kit, וכן רכיבי הפעלה, זהות וניטור. לכן הבחירה אינה בין כלי חזותי בלבד לבין כתיבת קוד בלבד. השאלה היא מי בארגון יבנה את הסוכן, מי יתחזק את החיבורים והיכן כבר מנוהלות הרשאות הגישה לנתונים.

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

הרשאות וערוץ הפרסום משנים את גבולות הסוכן

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

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

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

חשבו עלות לפנייה שהושלמה, וגם את מחיר המעבר

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

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

עשר שאלות שממקדות את ההחלטה

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

דוגמה: סוכן שירות לבירור מצב הזמנה

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

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

אם צוות השירות כבר פועל בסביבת Microsoft, אותו תרחיש יבהיר כמה מהחיבורים והניהול שלו אפשר לשלב ב־Copilot Studio. אם מערכת ההזמנות והתחזוקה שלה נמצאות ב־Google Cloud, הוא יבהיר מה נדרש במסלול Agent Builder. ההכרעה מתקבלת כששתי האפשרויות נבחנות מול אותה בקשה, אותן הרשאות, אותו ערוץ ואותה הגדרה של פנייה שהושלמה.

קראו גם:

• Google Workspace או Microsoft 365: המחיר למושב לא מספר הכול
• Google Drive או OneDrive: המהירות כמעט תיקו, האקוסיסטם מכריע
• Metricool או Buffer: מספר הערוצים קובע מתי המחיר מתהפך